コの世界には「銀の弾丸」はまずない。だから、ほとんどの技術に関する単語はbuzz wordであり、その技術は一過性のものでしかない。単なる「流行りもの」がほとんどだ。だから、どんなに素晴しい技術であっても、眉に唾つけて見るべきだ。その技術が本当に花開くかどうかの判断はなかなか難しいのだが、単なる流行りものに時間を取られるのは馬鹿げている。

とにかくプロジェクトを小さくするのが理想になっています。10名以下じゃないと意思決定できない，というような。

作った人が最後まで面倒を見るのが一番効率がいい。考えた人が自分で作って，リリースして，ケア（保守）していく。一段落したらまた次のプロジェクトに取り掛かるというサイクルです。 次の人に渡して「じゃぁ，よろしく」だとつまらないし，みんな責任を持たなくなっちゃうじゃないですか。

納得できるアーキテクチャに到達したところで、後は流す（コードをきれいにする、UIの細部を詰める、徹底的にテストをする、コメントを入れる、など）。

大切なことは、 書いたプログラムを捨てることを恐れないことこの段階で仕様書を書くことは時間の無駄と認識すること細かなことを無視して、一番難しい部分を最初に作ることできるだけ早く、一気に「見極めが出来るところ」まで持って行くことコードは多少汚くても良いが、モジュール間のインターフェイスだけはキチンと設計すること

「仕様がころころ変更になる」のはソフトウェアの宿命。どんなに頭の良い人が設計しても、「作ってみなければ分からない」「使ってみなければ分からない」ことはどうしてもあるので、「アーキテクチャの大幅な変更」「ユーザーインターフェイスの大幅な変更」があるのはあたりまえ。 ぜひとも認識して欲しいのは、「だからこそスタートダッシュで肝となる部分を一気に作って、早めに（仕様変更が必用かどうかの）見極めをする必用がある」という点。特に「作って見なければ分からない」部分の見極めのためのコーディングの時間を惜しんでいては、良いものは作れない。紙の上での設計・仕様書作り・会議に時間をかければかけるほど、そのかけた時間そのものが足かせになって柔軟な発想ができなくなる。それよりも、発想が浮かんだ時点で実際にコードを書いてみて「これで行けるかどうか」の実感をつかむことが大切。

For example, style properties for a theme can hide the application title, hide the status bar, or change the window's background.

Perlはスコープの実装がとてもよいのでレキシカル変数のスコープをできるだけ小さくするような保守性の高いコードを書くことができます。

オブジェクト指向の言語を使う場合には、機能を分割するのに、どのようなオブジェクトが必要なのかを設計する必要がありますけどね。いずれにせよ、機能単位まで分割して、はじめて言語選択に入ることになるんです。

要件を機能まで、落として、機能を関数まで落とす。

SmalltalkがMVCでまともにターゲットにしているのはGUIのようなインタラクティブなもので、かつ、Smalltalkは伝統的にVMが環境として保存されるので永続化は考えてないんだろうなぁ・・・ RT @yugui: SmalltalkでのMVCは永続化にちゃんと言及してない、その必要もなかったから、ってどこで読んだんだっけ。これが今に至る不幸をもたらしている気がする

アルゴリズムをデータとして扱うために、Smalltalkではブロックを使います。Lispではクロージャと呼ばれているものに相当します。

とりあえず何が出来るか、知らないやり方があるとか、だいたいの名前を知っておくとか、その程度でいいじゃんみたいな。 というかそれが大事だよねとか。 必要な所だけ、使うときに見ればいいんだ。 その必要な物があるかどうかを知っておけばいいんだと。

今までの経験則で、自分が直感で思ったのと実際の工数というか時間を計算してみるとこうなりました。直感 ×1 = 無ゲー直感 ×2 = ややデスマ直感 ×3 = 余裕をもったスケジュール

すごい完璧主義だったんですよ。とりあえず動くものを作るっていう感じではなくて、動くものになってないのに、ここは気に入らないから書き直すとか、本を途中まで読んでしばらく放置していたときに、また最初から読むような感じだったんですよ。貝畑とかは、とりあえず動くものをすごいスピードで作っていく感じなんです。僕らの中の用語で「不必要な最適化」っていう「必要になったら最適化すればいい」っていう考え方があるんですけど、そういう開発におけるスピードの大切さを貝畑から学んでいますね。 川井 バランスと言えばバランスですよね。 村瀬 そうですね。本当にどうしようもないコードを作って早くてもしょうがないですからね。

「早く読むための技術」として「コードはお尻から読む」ことを挙げた。コードが修正される際、関数やメソッドの追加は、ファイルの末尾に追加される場合が多い。そのため、末尾に追加された関数だけ、それまでのコードとは異なる書式になっている場合がある。 これについて細川氏は、「これはそのコードの元々の担当者とは違う人が、過去の経緯や、元のコードの意図を十分に理解せずに関数を追加したことに起因する例が多い。そして、得てしてそうした個所には、拙速なコード修正が入り込みやすい。よってコードを読む際は、まず“お尻”に注目することで、あらゆる問題を発見しやすくなる」のだという。

吉岡氏はコードを読む際、4つの視点を基準にしているという。細部から内容を理解する「ミクロの視点」と、規模や仕組みから理解する「マクロの視点」、文字列を読み込んで理解する「スタティックな視点」と、ソースコードによって生じる動作で理解する「ダイナミックな視点」の4つだ。特に、「コードが大規模化している近年、まずマクロの視点でコードの全体像を理解すると効率的だ」という。

楽天の吉岡氏は「ソースコード理解と勉強会」と題して、コードを効率的に読む際のテクニックを紹介した。氏は「コードは読むものではなく、理解するもの――単に文字を追うだけではなく、それが意味する内容を理解するスタンスが大切だ」と指摘

3分の１ 計画 6分の1 コーティング 4分の1 単体テスト初期システムテスト 4分の１ すべてのコンポーネントを統合して行うシステムテスト（『人月の神話』P.17より） これらの数字は、筆者が実際にシステムを構築する際に感じている感覚と非常に近い。30数年も前から、この時間軸の感覚は、あまり変わっていないのかもしれない。 そして一言付け加えるとすれば、例えば「プログラム」をいかに早く「プログラミングシステム」に進化させられるかどうかは、やはりプログラマのスキルに依存するのである。プログラマのスキルは、過去に携わった仕事の経験にかなり依存すると筆者は考えている。

クラウドの利用を自信を持ってお勧めするためには、永続的な安定性の保証や代替手段の確保が最低ラインだと思っていますが、現時点ではそれを期待するのは難しい

デザインドキュメント（コーディングの前に設計情報を文書化するプロセス）、コードレビュー（他のチームメンバーがソースコードの変更を検証し、不具合などを指摘するプロセス）、単体テスト（システム全体ではなく、関数やクラス単位での自動テスト）を必須としている。

iモードIDを用いた「かんたんログイン」にはDNS Rebinding脆弱性があるそうです。 Webサイト提供者側の具体的な対策は以下は、以下の３つ。 認証には、パスワード認証（推奨）あるいはFOMAカード製造番号によるかんたんログインを使用する セッションIDをURL埋め込みあるいはCookieに保持するセッション管理方式を用いる HTTPリクエストヘッダのHOSTフィールドの正当性をチェックする

「要件定義には十分な時間をかけるべき」ということだ。実際，日本IBMで請け負った近年の大規模プロジェクトでは，20～25％のコスト・期間を要件定義に当てている。小規模・短納期開発であれば，30％以上を要件定義にかけてもよいだろう。

ファイルベースの実装よりも、データベースに全部置いた方が（セキュリティとかまで考えれば）楽なのではと思います

データの永続性がある（サーバがダウンしてもデータは残っている）

C::D::Inheritable の良さは、継承可能で writable な点

言語の進化はベストプラクティスをサポートするためにあるんじゃなかろうか。

不況といわれるご時世でも手に職のある人間は強いが、その手に持つ技術も日進月歩で進化をしていく。その変化の中、身につける技術を的確に見極め自分の中に取り込んでゆく事を続けなければ、明日を生き残る事は厳しいだろう。 IT業界で働く以上、その適応能力とスピード感は重要視される。モバイルならなおさら。 嗅覚を鍛え、技術も磨く事。 IT業界でエンジニア、デザイナーとして生きる残るための大切な技術です。

length の方が速いだろうとは思っていましたが、ここまで差が出たのが予想外でした。以後も積極的に length でチェックしようと思います。

taintperlおよび-Tオプション（以下-T）はWebプログラムの脆弱性においてはほとんどの場合無力である。また、-Tは、あんまりにも脆弱なコードに対し、何か悪いことが起きる前に死を以ってそれを訴えるだけの存在であり、普通にプログラムを書いていれば発動することはない。