先ほどのエントリーにも関連する、というかそこから導出されるおまけエントリーです。 私が思う良いプログラマーに最低限必要なモノはこの３つです。 的確なコメントをつけられる日本語力 自分自身を疑い、自分以外が自分の書いたコードを見た場合を想像するだけの視点 ド・モルガンの法則等、基本情報処理者レベルの知識 なぜこういうことをわざわざ書くかというと、このような超当たり前とも言えることを考慮せず、オブジェクト指向やリファクタリングやデザインパターンの適用といった目先の器用な技術にばかり傾倒する人をたくさん見てきたからです。結果生み出されるのは、微妙に読みづらいトリッキーなコードばかりです。 メンテナンスコストは開発時には馬鹿にならないものです。二次開発で既存のコードが読めなくて読解に四苦八苦してる時間の為に実際の開発が遅れて終電徹夜コースなんてこともあるでしょう。 誰かが生み出すそのコードの、生み

久しぶりにシステムエンジニアっぽい話題。 良いコードというのはケース・バイ・ケースであり案件によって異なるものですので、あくまで『私が思う良いコード』についてです。 私がコードに対して持ってる座右の銘は、これです。 動く汚いコードより、動かない綺麗なコード 動く汚いコードはトラブルが発生して動かなくなったときに「なぜ動かないか」が解らず修正が困難ですが、動かない綺麗なコードは誰かが動くように直せば動き、修正が簡単です。故に、トラブルが発生したときのメンテナンス工数に差が出ます。トラブルは必ず発生するものですからね。動く汚いコードを綺麗にするには多大なるコストが掛かりますが、動かない綺麗なコードを動くようにするのはそれほど難しいことではないでしょう。一切トラブルも追加開発も発生しないと仮定するならば動く汚いコードでも問題ありませんが、果たしてそんなことがありうるでしょうか？　むしろ、トラブル

鮎麻呂 @aymro 『eat kanazawa 2012』名物の夜塾から帰ってきて爆睡して目が覚めました。『福屋旅館』のモデルになった宿に投宿。飯ウマ、量多い。 『eat kanazawa 2012』 1997年より石川県金沢市が継続開催しているメディアアートとクリエイターの祭典のこと。[Wikipedia] http://eatx.bp-musashi.jp/eat12guide/eat12_program.html http://ja.wikipedia.org/wiki/イート金沢 毎回指名を受けた個人クリエイターがイベント全体を統括プロデュースするので回によってテーマやゲスト層がだいぶ変わる。ここ数年ポップカルチャー的なノリが続いたが今回は震災やソーシャルメディアが焦点になってた。 とはいえこのイベントの本命はゲストと一般参加者が温泉宿の大広間で車座になって酒盛りしつつ夜通し語り

タイトルにはスタバと書いたのだが別にスタバである必然性はなく、実はタリーズでもエクセルシオールでも何でもいい。ただ、少し一般化して喫茶店と書くと、それこそ兜町にあるようなトラディショナルなやつが大量に含まれる気がするし、カフェと書くとハウスミュージックがかかるなかでホットワインを飲むみたいな変なお洒落スポットが混入してくる気がしてイマイチしっくり来なかったので、いっそのこと固有名詞にした。そういうわけで以降もスタバとは書くが、要するにカウンターのような所で商品を注文して、受け取った商品は自分で席まで運んで飲食するスタイルの店全般を指す概念として利用するので、そのつもりで適当に読んでいただきたい。 2種類の客 スタバには、２種類の客がいる。注文を済ませてから席に着く客と、注文する前に席を取る客だ。 私の知るほとんどのスタバは、入るとまず注文カウンターがあって、座席があるのはその奥であったり別

仕事としてコードを書くようになって３週間が経ったので ここらで所感をまとめてみたいと思う。 ベンチャーと大手企業の違いみたいなことを書いてもいいんだけど、 正直今のところ「あまり変わらない」印象。 それもそのはず、現職もエンプラ向けの仕事。 SIと仕事のやり方はかなり似ている。 ので、純粋にプログラマとして思ったことを。 スパゲッティコードとの出会い この３週間で触ったのはウチの会社で改修・保守をやっているシステムの バッチや管理画面の細かい修正など。 コードは全てPHPだった。 この辺は一番経験のある言語だったので助かった・・・と思った。 が、意気揚々とソースを見て愕然とした。 処理ベタ書きのずらずら続く手続き型の処理は序の口。 関数を定義する代わりにベタ書きスクリプトを外出しにしてrequire 意味不明な変数名 同じ処理をしているはずなのに名前だけ違う関数達 無計画なテーブル定義 業

三宅陽一郎MiyakeYouichiro @miyayou 人工知能がプログラマーから見て難しいのは、人工知能をあまりにプログラミングと結びつけて考え過ぎるからです。AIはレンダリングと同じように、一つの原理であって実装の法則ではありません。プログラミングから入るとAIのある特定の部分を切り取りやすいですが概念的な部分が欠落してしまいます 三宅陽一郎MiyakeYouichiro @miyayou 人工知能は深い階層を持つシステムであり、知能として現れる部分は、その最後の上層にあたります。実装は一番基本的な最下層の部分です。「プログラミング実装されたものが、複数の層を通して最終的に知能として現れる」というデジタル空間の不思議な現象を司る原理こそが、人工知能なのです。 三宅陽一郎MiyakeYouichiro @miyayou 「知能を直接的に記述する」という方法論は古典的な人工知能の取り組