SuperPopCamとか作ったときに、体系的な資料欲しいなぁーとか思ってたことのまとめ。 色々と自分の中の考えをまとめるためのメモ。世の中のアプリは機能を半分にして、減った予算分をUIの練り込みにつぎ込んだ方が絶対よいアプリになると思う。 書いてる作業が一番考えまとまるので、ちょぼちょぼあげていこうかと、まずはボタンから。 指の大きさの制約を受ける ・Webとスマホを比較した場合、最大の違い。 ・ピクセル単位でクリック位置を制御できるマウスポインタと違い、指は大雑把にしかタップ位置を指定できない。 ・このためAppleはボタンの最小サイズとして44pxというガイドラインを作っている。 ・視覚的に44px以下のボタンも実際のヒットエリアは大きめにする。 ・またこれに留まらず、ボタンとボタンの間のマージンは空けられるだけ空けた方が安全。 ・つまるところ「カッチリ」つめたボタンレイアウトのグラ
「プログラマが知るべき97のこと」の49個目のエピソードは、見積りに関する話です。見積に関するこのエピソードは日頃よく思う部分です。しかし、残念な事に本当に読んで理解して欲しいのはプロジェクトマネージャです。そして、プロジェクトをリードしていく事になるプログラマも知るべき内容です。 このエピソードではあるプロジェクトマネージャとプログラマとのありがちな会話を例にして、見積りの定義を再確認しています。大辞林で「見積もり（る）」を調べると次のように書かれています。 1. 目分量や心づもりではかっておおよその見当をつける。目算する。「入場者数を―○る」 2. 工事や製品などの、原価・日数・経費などを前もって計算して出す。「経費を―○る」「工事を―○る」 ソフトウェア開発では、現実として1の「おおよそ見当をつける」事しかできません。工業製品などと異なり、プログラマのスキルに依存する部分が多いこと、
株式会社ジーワンシステムの代表取締役。 新しいものを生み出して世の中をあっといわせたい。イノベーションってやつ起こせたらいいな。 「みんなが言ってる」は技術者が口にする言葉じゃないと書いてきました。 私が言ってることで、「みんな」とはおそらく真逆のことがあります。 それは「テーブル設計を（ユーザーインターフェイスの）実装の後に！」ということです。 「そんなことができるわけがない」とバカにされますが、そういう決め付けは思考停止ですよね？ ともかく、眉に唾塗っていただいてけっこうですので、続きを読んでください。 一般的なシステムにおいて、一番手戻りが大きい（波及する箇所が多い）仕様変更はテーブル変更を伴うものです。下手糞な設計で、他に悪影響を与えるのもテーブル設計です。 逆に、テーブル設計が美しく合理的にできていれば、他の工程は非常に楽になります。 では、仕様変更を防ぎ、美しく合理的なテーブル
はっきり言おう。大規模プロジェクトは存在自体が悪。 続けて同氏は、ケーパース・ジョーンズ氏の著書「Patterns of Software System Failure and Success」から調査結果を引用し、大規模プロジェクトになればばるほど、当初の見積もりとは大きくかい離したものになり、かつ失敗する可能性が高いことを示した。「（一般的なプロジェクトも含めた調査結果でさえこれなのだから）デスマーチについては推して知るべし」とヨードン氏。 エドワード・ヨードン、デスマーチを成功に導く対症療法を説く - ITmedia エンタープライズ (強調は筆者による) うむ。言っていることはごくあたりまえのことではあるが、ヨードン氏が言うと説得力がある。 調査結果の抜粋。FP（ファンクションポイント）はジョーンズ氏が定義している単位で、1FPが100行程度のコードであるという。1FPであればほぼ
Subversion 1.5 よりマージ追跡機能がついたので、svk ではなく Subversion (TortoiseSVN) 単体での個人開発用ブランチを作成してみた。 個人開発用ブランチ作成までは以下の手順 (Subversion コマンド表現) svn mkdir /branches/work svn cp /trunk /branches/work/自分のアカウント名 作業フォルダのところで svn switch /trunk /branches/work/自分のアカウント名 個人開発用ブランチのディレクトリ名については、OpenPNE開発のSubversion活用法 の流儀を参考にした。 最終的にメインライン(trunk) に対してコミットしたい場合は、手順としては以下のようになる。 個人開発用ブランチで作業して機能を実装する。適当なタイミングでコミット /trunk のHEA
昨日、大手SIerの方々と話をする機会があって、そこで出てきたのが、「誰が書いても同じコード」になることが重要で、それを実現するために、ドキュメントをいっぱい書かなくてはいけないという話。大手SIerは、大体同じことを考えていると思います。 でも、「誰が書いても同じコード」にするってのは、そもそも無理だと思うんだよね。そうやって、わざわざドキュメントをたくさん書かせても、めためたなコードを書くやつはいて、総合テストするときに、現場は燃え上がるもの。ある程度の規模以上のプロジェクトなら、どこでもそんな感じじゃないかと思います。 重要なのは、「誰でもメンテナンスできるコード」にすること。そのために、コーディング規約は、きちんと決めてみんなで守る、それ以上は、がちがちに縛る必要はない。 がちがちに縛るために、設定ファイルをたくさん書かせたり、必要以上のドキュメントを書かせるのは、一定の品質を確保
最近知人からもらったメールで，こんなケースがあります。「システムで使用するJDKのバージョンを最新版にしたい」と社内の開発チームに提案したところ，ちょっとした言い争いが起きたというのです。提案したエンジニアは，最新版のJDKでは従来のバグが修正されており，新機能も搭載されているのでそれを使いたいと考えたわけです。 だがこの企業では，開発に使用するJDKのバージョンについての厳しい規約があり，JDKの安定性を重視すべき（＝規定しているJDKを使うべき）だという指摘を受けたそうです。最新版のJDKを使えば，新機能に新たなバグが含まれている可能性があり，従来版と異なる点の理解に時間を取られてしまう，という理由だったそうです。 これは言ってみれば，山のエンジニアが集まっているチームに，火のエンジニアが飛び込んで火消しをされてしまった例です。 別の例では，開発環境やツールの新バージョンがアナウンスさ
技術は会社のものではない。みんなのものだ。 プロプライエタリな世界に長くいると、上のようなことを言うと、こいつおかしいんじゃないかと思われてしまうが、オープンソースの世界にどっぷりつかっていると、「技術は会社のものではない。みんなのものだ。」というのはおかしくともなんともない。至極普通のことと思う。 企業がオープンソースに関わるとき「技術は会社のものではない。みんなのものだ。」ということを理解できているかどうかというのが成功のポイントになるような気がする。理屈の上では理解していても企業、組織として理解できているかは別の話である。 例えば、オープンソースソフトウェアを共同して改善する場合、そのプロセスそのものを公開できるか。密室で改善するのではなく、公開のメーリングリストなどでオープンに議論しながらパッチを作るとかを、最初っから実践できるか。そもそも開発を公開のメーリングリストでするという発
PCブラウザでケータイサイトをテストするためのプロキシソフト、MoxyというのがYAPCのライトニングトークで紹介された。 さっそくダウンロードして使ってみた。 コンセプトはすごいなあと思う。 というか、ちょっと前も「ケータイ絵文字をPCで表示する方法」とかたくさんブクマされてたり、私も仕事でNULLGWほにゃららをダミーIDに変換するGreasemonkey作ってたり、みんな困っているところは同じ（簡易な確認レベルでは、できる限り実機を使わずテストしたい！）なわけですね。 でも私とかfirefoxでクライアントサイドで何とかする発想しかなくて、拡張とか何度か作ろうとしては挫折していたんですけど、なるほどサーバサイドで全部やってしまえばOKですよね。 単にリクエストでの環境変数を付与/置換と、レスポンスでの絵文字変換だけではなく、ブラウザ画像上からUAを切り替えられたり、ちゃんと横
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く