今週はMBAの授業の一環でインドのいくつかの企業を訪ねてまわっているのだが、今日行ったのはInfoSys。 InfoSysは、Fortuneマガジンが"Top Companies for Leaders 2007' list"の１０位に選んだ、インドの「IT産業」の花形。

上の三つの絵は、私がiPhone/iPod touch向けのお絵描きソフトSmallCanvasで描いた絵だが、パッと見てどう感じるだろう。「結構絵が上手な絵じゃないか」と思った人も多いかもしれない。 実は上の三つの絵は、SmallCanvasの発売に合わせて、私自身がサンプルとして書いたもの。絵心のない私が苦肉の策で作り出したのが、SmallCanvasのundo/redo機能を駆使して写真のトレーシングをするという裏技（アプリの作者が「裏技」を発明してどうするんだ、とうツッコミはなしで^^;）。下に置いた写真をトレースするために、基本的なデッサンがしっかりとし、これだけで「そこそこ見られる絵」になってしまうから不思議だ。 これで再認識したのは、「絵の上手さ」は、「ちゃんとした構図でデッサンが描けるか」という「テクニック」の部分と、「描き手オリジナルの表現ができるか」という「センス」の部

ずいぶん前に、「マルチスレッド・プログラミングの落とし穴、その１（かもしれない）」というエントリーを書いたが、今回はPhotoShareサーバーを運営していて、まさにこのあたりの深い考察が必要になって来たので、良い機会なので続編エントリー。 PhotoShareのバックエンドのようにCRUD（Create/Read/Update/Delete）のAPIをサポートするバックエンドを作る場合、Create/Update/Deleteのリクエストに対してはクライアントからのAPIコール時にすぐに（HTTP Requestに返事をする前に）データベースに変更を加え、Readの際にも（キャッシュを使う・使わないを別にして）データベースの最新の状況を反映するデータを返すように設計するのが普通である。 このアーキテクチャの問題は、ユーザーのアクティビティが増えた時に、データベースやI/Oがボトルネックと

iPhone用の「はてな人気エントリーリーダー」、そろそろ形になってきたのだが、作ってみていろいろと発見した部分もあったので、全面的にクラス構成を見直し、大幅に書き直した。 HTTPで通信をしているコードが二カ所に分かれていたので、それをDataOverHTTP/XMLOverHTTPという二つのクラスにまとめ（XMLOverHTTPはDataOverHTTPのサブクラス）、はてな独自のRSSフィードを読んでいるコードから一般的なRSSフィードを扱うコードをくくりだしてRSSFeed/RSSFeedLoaderという二つのクラスにまとめて、あとで別のアプリケーションで再利用することを可能にした。それに加えて、各種ローダーに非同期通信をさせる主体をController（HotEntryViewController）からModel側（HateneHotEntry）に移すことにより、難解になりが

大手電機メーカーのSEとして就職して一年。うちの職場は、なんというか、生ぬるい。 ... きっと自分の成長の為には職を変えたほうがいいんじゃないかと思う。でも、自分の向学心の強さにはっきりとした自信が持てない。 ... 24年間優等生をやってきて、さらに新卒という切符を使って手に入った貴重な（？）大企業への就職を、簡単に手放してしまっていいのだろうか。 ... 【新卒で入社して一年より引用】 なんだか昔の自分を見るようで心を動かされてしまったので一言。 私自身、「せっかく理系の大学院をそれなりの成績で出ることができたのに（そうでない人が簡単には入れない）大企業へ行かないのはもったいない」というさもしい気持ちがあったからこそ、ベンチャー企業には行かずにNTTの研究所に入ったのは事実。「新卒という切符を使って手に入った貴重な（？）大企業への就職を、簡単に手放してしまっていいのだろうか」という気