驚き最小の原則 - Wikipedia
驚き最小の原則（おどろきさいしょうのげんそく、Principle of least astonishment または Rule of least surprise）とは、ユーザインタフェースやプログラミング言語の設計および人間工学において、インタフェースの2つの要素が互いに矛盾あるいは不明瞭だったときに、その動作としては人間のユーザやプログラマが最も自然に思える（驚きが少ない）ものを選択すべきだとする考え方である。 例えば、あるユーザインタフェースでは ⎈ Ctrl+Q を押下することでプログラムを中止させるとする。同じユーザインタフェースにマクロを記録する機能（キーを押下した順序を記録して後で再利用できるようにするもの）があるとする。ユーザは Ctrl+Q を含むキーストロークをマクロとして記録したい場合もあるだろう。驚き最小の原則に従えば、マクロ記録中の Ctrl+Q はプログラムを中
エンジニアよ、ゼネラリストなんて目指すな！―VASILY 金山裕樹のキャリア論［2］ | キャリアハック（CAREER HACK）
イケてる人材は3つの“Ｊ”を持っている ―VASILY 金山裕樹のキャリア論［1］から読む 大手企業とスタートアップとの、決定的な違い。 ― 金山さんは、大手企業とスタートアップの両方を経験されていますよね。両方で求められる能力に違いは感じますか？ まったく違うと感じます。決定的に違うのは、ビジネスとして「成立させる」フェーズ。そこにくると、必要になるスキルが全然違うんです。 大企業の場合は、すでに独自の強いビジネスモデルってものがあるんですね。すごく雑な言い方をすると、“Yahoo! の強み”って「どんなページを作ったとしても、広告が入って、収益があがる」ところなんです。Yahoo! として広告がガンガンまわっているから、極論、あとは“どれだけ低コストで広告が入るようなページを量産できるか”の勝負なんです。あとは、自分がやりたいことをビジネスモデルに“どうはめるか”だけを考えればいい。
エンジニアの不安と壁 - naoyaのはてなダイアリー
このところ、KLab×はてな エンジニア応援ブログコンテストというのを開催していまして、エンジニア人生に関するちょっとした小話をブログに書いていただくと、内容によっては、シリコンバレーに行けたり、iPad が貰えるかもしれない。という企画です。「え、ブログ書くだけでシリコンバレー? 」 なかなか太っ腹な企画です。 よい機会なので、宣伝がてら、自分もちょっと、昔話をしてみたいと思います。 振り返ってみると、自分がエンジニアとして経験を積むなかで、「ここが壁だったな」と思うところがぼちぼちありました。それが何で壁に感じたのかといま改めて考えると、いずれも体系的な知識がなかったために、それを乗り越えるための指針がなかったというのが大きかったように思います。 きれいなコードを書くにはどうしたらいいんだろう? 負荷分散って、どうやるんだろう? 溜め込んだデータをうまく活用するには、どうしたらいいんだ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Studying HTTP
