デザインの視覚調整 ― 人間の認知に適合するデザインのために | POSTD
理論対デザイナー 駆け出しのデザイナーの頃は、何が正しくて何が正しくないかということについて、PhotoshopやCSSを信じ切っていました。Photoshopで整列すればそろったことになるし、形の違う2つのオブジェクトが同サイズと言うならサイズは一緒。左右のオブジェクトが同じ16進数値を持っていれば同じ色に 見える 、とそんな具合です。 この考え方は理論的なように思えますが、作業の方法としては誤っています。 画像処理のソフトなどは合理的に計算することはできても、形や色やサイズに対する人間の知覚メカニズムを考慮に入れることはできません。つまり、全体の視覚言語的背景にある複数オブジェクトの配置といった 文脈 や、それらを人がどう視覚的に捉えるかということについて、ソフトは理解できないのです。 従って、対象が視覚的に正しく見えるように、人間の非合理的な感覚で調整をしてやる必要があります。コンピ
Vimの生産性を高める12の方法 | POSTD
1. LeaderをSpaceキーにする Leader は素晴らしい概念です。キーの 組み合わせ ではなく 並び によって、操作を行えるようにするものです。私はこれを使っているので、操作のために” Ctrl -何らかのキー”の組み合わせを押す必要はめったにありません。 私は長い間、 , を Leader キーとして使っていました。ですがある時、キーボードの中で一番目立つキーにマップすることを思い付いたのです。Space（スペース）キーです。 これで私のVim生活は激変しました。今や、私は Leader をどちらの親指でも押すことができ、他の指は常にホームポジションにあります。 Leader がとても使いやすくなったので、私が様々なキーバインドで用いるようになったことは周知の話です。 2. 自分が特によく行う操作をLeaderにマップする 私は、自分がVimで作業を行っている中で、その時間の
分かりやすいWeb入力フォームのための十戒 | POSTD
1. 各々の入力欄に、常に見えて分かりやすいラベルを付けよ 記入する前の入力欄にだけ、フォームのラベルを表示するのがWebデザインの主流になっています。これはユーザネームやパスワードなどを入力する際にはシンプルで使い勝手がいいのですが、それ以上に長い文字列になると少々勝手が悪くなります。 そのため余白があるのであれば、ラベルを表示すべきです 特に、長いフォームの場合では、ユーザは入力したものを見直すでしょう。どのラベルが入力欄と合致するのか分からなければ、間違いがないよう見直すことなどできるはずがありません。 改善前:入力欄中にラベルが記入してあります。今は見やすいかもしれません。 しかしフォームに入力するとラベルが見えなくなってしまい、間違いを見つけにくくなってしまいます。 改善後:それぞれの入力欄に、クリアでいつでも見えるラベルを付けましょう。 2. 十分な大きさのフォントを使用せよ
シンプルの心理学 ― 心地良いデザインのために | POSTD
私たちの誰もが理解する”シンプル”という概念の正体を突き止めることは、難しそうに見えますが、実はそうでもありません。 私たちが製品やWebサイトをシンプルと感じるかどうかの背景には、”見れば分かる”ということだけではなく、単なる直観的な反応にとどまらない何かがあります。 Steve Jobs は次のように述べています。 シンプルであることは、複雑であることより難しい場合がある。物事をシンプルにするためには、思考を整理して懸命に考えなくてはならない。しかし、努力する価値はある。ひとたび達成すれば、山をも動かすことができるのだから。 シンプルにものを作ることにそんなに力があるのであれば、なぜ私たちはそうできないのでしょうか。 なぜシンプルであることは、こうも複雑なのでしょうか。 人生における多くの事柄と同じように、シンプルさには表面的に見えている以上の何かがあります。ここでは、私たちの脳が新し
「型」の定義に挑む | POSTD
科学はその方法論上のイメージよりもはるかに”ぞんざい”かつ”非合理的”なものである。 Paul Feyerabend著『Against Method（方法への挑戦）』（1975年） プログラミング言語は魅力的な分野です。それは、計算機科学（と論理）を 社会学や人間とコンピュータの相互作用 、科学的に定量化できない直感や嗜好、そして（良くも悪くも）政治などを含む分野と結び付けてくれるからです。 プログラミング言語を話題にする場合、たいてい何らかの客観的な真実を追求する科学的議論になってしまいます。科学は完璧のオーラに包まれているため、科学的本質の核心部だけに集中し、他の部分を無視するのが正しいプログラミング言語の考え方だと単純に思ってしまうのも無理ありません。 しかし、これではプログラミング言語を面白くしている多くのものが除外されてしまいます。この隙間を埋める1つの方法は、科学の哲学に目を向
ソフトウェア開発で得た教訓22箇条 | POSTD
1. 小規模なものから徐々に拡張していく。 私は日頃、新たなシステムを作るにせよ既存のシステムに機能を追加するにせよ、必要な機能すら殆ど持たないようなとてもシンプルなバージョンを作るところから始めるようにしています。そこから当初予定していた機能まで、段階的にソリューションを拡張していきます。私は初めから細部にわたって計画をできたことはありませんが、代わりに開発を進めていく中で新しく見つけた情報をソリューションに役立たせます。 私はJohn Gallの、この言葉が好きです。 “複雑なシステムというのは、往々にしてシンプルなシステムから発展したものだ。” 2. 同時に複数のものを変えない。 開発中にテストが失敗したとき、あるいは機能がうまく動作しなかったとき、1つだけ変更すれば、問題発見が格段に容易になるでしょう。言い換えるなら、短いイテレーションを行いなさいということです。1つずつ変更を行い
プログラマ能力指標表 | POSTD
2015年05月27日: 表が見にくいというご意見を頂いたため、原文著者に連絡のうえ体裁を修正しました。 上位のレベルには下位のレベルの知識も蓄積されているということに注意してください。つまり、レベル n であれば n より低いレベルの知識も全てあります。 コンピュータサイエンス データ構造
ケーススタディ: アプリ “OneShot” をデザインした1週間 | POSTD
3月2日の昨日、私たちは OneShot をリリースしました。このアプリは、スクリーンショット内のテキストにハイライトを入れた画像をTwitterに投稿できるというiOSアプリです。アプリがどのように出来上がり、またデザインがどのように決められていったかを皆さんと共有できたら面白いと思い、この記事を投稿しました。その他、アプリの初期段階のイテレーション、採用されなかったアイコン、framer.jpプロトタイプなどについても言及しています。 始まりはダイレクトメッセージ 友人の Ian Ownbey がTwitterのダイレクトメッセージでフリーランスのデザインプロジェクトに関して私にコンタクトしてきたのが、1月14日のことです。彼は、彼の友人の Jason Goldman と小規模なiOSアプリの仕事を請け負っていたのですが、アプリを完成させるためにデザイナーを探しているとのことでした。当
クライアントとデザイナのためのUX/UIデザインの手引き | POSTD
出来の良いUXデザインとUIデザインはプロダクトを全く別の新しいレベルのものにしてくれます。しかし、コミュニケーションがうまくできていなければ、クライアントにとってもデザイナにとってもいい結果は生まれません。 UXデザインとUIデザインのプロセスがうまくいけば、ユーザにとってシンプルで明快な使いやすいプロダクトができ上がります。 DUX はエストニアに事務所を構えるKristian LemberとKevin Crepinの2人が経営しているUX/UIデザインのスタジオです。彼らは使い勝手の良いプロダクトを作るエキスパートです。DUXでの業務は、レストラン予約に 便利なアプリ や自分に合った電気会社の料金プランを検索できる サービス など多岐にわたっています。 現在もてはやされている リーンスタートアップの考え方 にあるように、大企業でさえも今はLemberたちが経営するような小規模のスタジ
開発者の生産性：Noと言える技術 | POSTD
生産性を維持するのは難しいことです。 特に開発者の立場では。 ゾーン（超集中状態）に入るには時間がかかりますが、入ったゾーンから引きずり出されるのは簡単です。 例えば、 * ミーティング * Eメール * 作る予定の機能や、修正すべきバグ などに意識が分散されてしまいます。確認しておかないと、気付いたら何もする時間がなくなっています。 これを解決するための秘策があります： あらゆることに” no “と言うのです。 私たちのやり方をお教えしましょう。 ミーティングは木曜日だけ ミーティングは生産性を奪います。私たちは経験から、いつもミーティングの前後に45分の時間が消えてしまうことに気付きました。さらに、Skypeでのたわいないおしゃべりでも15分間が失われます。 45分後にミーティングがあると思うと、重要なことは始められません。同じように、電話やミーティングが終わってから、即座に大きな問題
JavaScriptのデバッグ方法 – JSを嫌いにならないためのTips | POSTD
この記事のオリジナルは voxxed に投稿されたものです。 JavaScript関連の問題を抱えるチームをサポートする仕事を通じて、いくつか共通の問題点があることに気づきました。もしあなたもJavaScriptに対するイライラを感じているのであれば、この記事は何らかの助けになるかもしれません。おことわり：私がお教えするヒントはすでにご存知のものもあるとは思いますが、うまくいけば、多少なりとも有用な情報があるかもしれません。特にエンタープライズアプリケーションやCMSソリューションを構築する際に有効なヒントです。チームの誰もが話したがらないCMSのコードについてお話しします。いずれも必要に応じて採用できるものです。 debuggerステートメント 大半のブラウザでサポートされているにもかかわらず、JavaScriptを書く際に最も活用しきれていない機能の1つです。debuggerステートメ
プログラマを悩ませること Top 10 | POSTD
10. 「何か」は分かるが「なぜ」が分からないコメント プログラミング入門コースでは、早い段階かつ頻繁にコメントを記述することを生徒に教えます。プログラムを書き始めた初期段階（ごく単純なコードであっても、時に理解し難いことがあります）では、これは実際に役立つことなのですが、習慣にとらわれてしまうプログラマが多くいます。 上記のコードが何をするのか分かりますか？ 私は分かりません。 問題は、多くのコメントがそのコードが 何をする のかを説明していますが、 なぜ そのコードが書かれているかが説明されていません。では、異なるコメントが書かれた同じコードを見てみましょう。 こちらの方が分かりやすいですね。何が起きているのかを完全に理解できるとは言えませんが、最低でもなぜこのコードが必要なのかが文脈から判断することができます。 コメントは、構文を理解してもらうためにではなく、読み手がコードを理解しや
コードは方法を語り、コメントは理由を語る | POSTD
私は コードにコメントを書く際の哲学について書いた投稿 の中で、 必要のないコメントこそが、最も優れたコメントだ と書きました。この点についてもう少し説明させてください。まず、コードはコメントに頼らなくても理解できるようにできるだけ簡潔にする必要があります。コードだけではどうしても分かりにくい箇所のみ、コメントを書き込むようにしましょう。 これを念頭に置いて作業することで、読者を常に意識しながら、コードが書けるようになります。1985年に出版された名著『 計算機プログラムの構造と解釈 』の、「第一版への前文」にも、この点について単刀直入に書かれています。 プログラムは人が読めるように、そしてコンピュータがついでに実行できるように書くべきである。 Donald E. Knuthも1984年に出版したエッセー『 文芸的プログラミング 』（ PDF ）の中で、同様のことを書いています。 これまで
私がコーディングで垂直方向にそろえるインデントをとる理由 | POSTD
先週、 Hacker News上で興味深い議論が行われました 。テーマは Linux Kernelのコーディングスタイル についてです。 議論の中で私は、 コーディングで垂直方向にそろえるインデントをとるべきか というささやかな聖戦を仕掛けました。私は全面的に賛成です。理由を説明しましょう。 垂直方向にそろえるインデントをとるとは？ 簡単な例を挙げてみます。 int robert_age = 32; int annalouise_age = 25; int bob_age = 250; int dorothy_age = 56; ちょっと見ただけで、「bob_age」がおかしいと分かるでしょう。また、目視であちこち探さなくても、全ての値が整数であることが簡単に確認できます。 この考え方は 一般的に 共有 されているわけではありません。ですので、なぜ 多くの 人たち がこれを有効なスタイルガ
多種多様な基準から見るプログラマの市場価値 | POSTD
私は毎日、 Teamed.io で働くことに興味のあるプログラマから何通かメールをもらいます。彼らへの最初の質問は「あなたのレートは？」（ 当社は時給ベースで給与を計算します ）ということです。何より驚かされるのは、2つの方向性で、誤った試算をしているプログラマが多く見られるということです。 時給5ドルから500ドル（600円から60,000円）まで答えはさまざまです。決して否定はしませんが、私自身で代案を出してみます。このブログ記事では、どういった要素を計算に入れるか、または入れないかを述べたいと思います。私の個人的なキャリアもありますが、これが業界のスタンダードとは思わないでください。あくまで客観的で論理的だと思っていますが。それでは説明しましょう。 オープンソースへのコントリビューション ソフトウェア開発者にとってまずポイントとなり、かつ重要となる特性です。あなたはオープンソースプロ
プログラマとして30年以上の経験から得た教訓 | POSTD
私は、プログラマとして30年以上仕事をしてきた中で、学んだことがあります。そのいくつかを以下にご紹介します。もっと挙げることもできますよ。 実物を見せないと、顧客の希望は分からない。 このことは最初の仕事で学びました。顧客は、実物を見るまでは、何が本当に必要なのかがよく分かりません。言葉で長々と説明するよりも、機能検証のためのプロトタイプを提示する方が確実に役立ちます。 十分な時間があれば、あらゆるセキュリティは破られる。 現代社会において、セキュリティを保つことは信じられないほどの難題となっています。プログラマは常に完璧を求められますが、ハッカーは1回でもハッキングができれば成功なのです。 セキュリティが破られた場合、事前にその状況に備えた対策を講じているかどうかで結果が変わってくる。 最終的にセキュリティが破られることを想定する場合、その時に起こることに備えて対策を立てておく必要があり
すべてのプログラマが読むべき記事10選 | POSTD
Javaプログラマやソフトウェア開発者として、私は「プログラマが知っておくべき…」というタイトルが付く記事から、多くのことを学びました。そういった記事は、特定のトピックに関する有益かつ詳細な情報を数多く与えてくれましたが、探し出すのが非常に困難でもあったのです。知識を探求する中でとても役に立つ記事を見つけたら、参考として何度も読み返せるようにブックマークしてきました。こういった記事を読むことは、どのプログラマにとっても有益になると思うので、私が集めた「 すべてのプログラマが知っておくべきこと 」を皆さんと共有する為にこれを書きました。 ここで紹介する記事は私が個人的にブックマークしたものです。「メモリ」、「Unicode」、「浮動小数点演算」、「ネットワーキング」、「オブジェクト指向設計」、「時刻」、「URLエンコード」、「文字列」などといった代表的なトピックについて載っています。このリス
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
