数日前のはてブで、HTML/CSSベタ打ちしていた人の今日はどうなる？ていう記事がありましたが、 最近とみに思うのは、PHP/Ruby/Java/Pythonどれでもいいんですけど、いわゆるサーバープログラマーというか、クライアント側のコード書かないプログラマーって死亡の日が近いなーという背筋の寒さがあって、いや、サーバーがなくなるわけではないと思うんですが、最終的にはCRUDだけやっとけよお前みたいな扱いになるわけですよ。で、そうなったら、別にGoogle AppEngineのDataStoreでよくね？なんでサーバー立てる必要あるんだっけ？という時代が近いのか遠いのか来ないのか。要するにFlash/JS/Ajax等のクライアントコードがロクに書けないおっさんは将来が心配なのです。まる。 だってさ、最近のFlashってクリップの表示内容というかBitmapをJPEGにできて、でもFlas

求人サイトに広告を出して３週間。 実に応募者はたくさん来たものです。40～50人はいました。ゾンビのごとくわらわらと集まってきたよ。 今回は、手っ取り早くふるいにかけるために、最初にプログラミングの実技試験をやりました。都合のよい日時を申告してもらい、その時刻になったら問題を送信(それも僕はcronで仕込むだけ)、応募者は時間内に回答のソースコードをメールで提出、という形式。 これなら定型的なメールのやりとりでほとんどの作業が済むし、僕の時間の節約になる。 これから試験を受ける人もいるので問題の内容は非公開だけども、ちょっとしたパズルを解くアルゴリズムを考えて実装する、というタイプの問題です。 プログラム言語は自由（受験者が得意なものを使ってよい）、標準入出力を使うだけなのでOSも自由、制限時間３時間としました。 ちなみに僕がこれを自分で解いてみたときは、C#を使って25分でできた。 とこ

タイラー・コーエンがMarginal Revolutionの12/23エントリで引用している文章が興味深い。以下がその引用部。 Software output cannot be measured as easily as dollars or bricks. The best programmers do not write 10x as many lines of code and they certainly do not work 10x longer hours. Programmers are most effective when they avoid writing code. They may realize the problem they’re being asked to solve doesn’t need to be solved, that the clien

プログラムやコマンドの使い方を言葉で、たとえば電話越しで説明しないといけない状況に陥ったときにハタと困ったんですよ。「これ、どう発音すれば相手はわかってくれるのか‥？」と。プログラムと言えば、{}だの、^だの、なんとも言い表しがたい記号があちこちに散在しています。調べてみたら、こんなブログがありました。英語のネイティブスピーカでもけっこう困っているんですねぇ。 » Coding Horror 冒頭には "I responded with a single line of Ruby to do the same, and a single line of Lisp." "He wrote back: "Underscores, pipes, octothorpes, curly braces -- "、、、"What the heck is an octothorpe?" とあり、笑えます。

を Python Hack-a-thon #2 のために作りました。単なるまとめなので、間違いがあったらぜひ指摘してください。 10〜30分で何となく分かるGoView more documents from ... .... 追記: サンプルコードの zip はこちら

「スーパープログラマー」という単語に過敏に反応する人がいたのをきっかけに、プログラマーとして一流であるための条件というのを考えてみたんだけど、難しくてわからんかった。しかし一流じゃない条件ならいろいろ思いつく。 たとえば、今なら「テストを書かないプログラマーは一流でない」ということは言えるだろう。これはどんな凄腕プログラマーだとしても当てはまる条件だ。 そして、これだけテストの重要性が叫ばれている中でもやっぱりテストを書かないプログラマーというのは存在する。これは初心者だろうが上級者だろうが関係なく一定数存在する*1。 で、なぜテストを書かないかということだが、いちばんの大きな理由は、テストを書かないのではなくて、テストが書けないだけなんじゃないかと思ってる。 テストを書いた方がいいなんてのは、誰だって分かっている。でも実際には書かない人が結構な数いて、その人たちは「ロジックは書けるけどテ

タイトルは、まあ、半分釣り。TDDな人もそうでない人も、肩の力を抜いてお気楽にどうぞ。 本題に入る前に まずお礼 ここで書くことは、前の記事 TDDはYAGNIに矛盾する？ - カタチづくり から派生して色んな方と意見を交わした経験が元になっています。この場を借りて、色々とアドバイスを頂いた方に心から感謝の意を表します。 特にコメント欄にお寄せいただいた きしだ さんのコメントは、コメントと言うよりももはや一つの素晴らしい記事となっていて、もう必読といってもいいレベルじゃないでしょうか。本当にありがとうございます。特にBDDについて大きなヒントを頂きました。 押し付けではなく、交換 タイトルから想像がつくとおり、ここにはどうしてもTDDに対して否定的な意見ばかりが並んでしまう。でも、だからといって僕がTDDを完全に否定しているとは思わないで欲しい。 僕が今一番恐れていることは、TDDに対し

C++版のOpenCVを使ってカラーヒストグラムを用いた類似画像検索を実験してみました。バッチ処理などのスクリプトはPythonを使ってますが、PerlでもRubyでも似たような感じでできます。 指定した画像と類似した画像を検索するシステムは類似画像検索システムと言います。GoogleやYahoo!のイメージ検索は、クエリにキーワードを入れてキーワードに関連した画像を検索しますが、類似画像検索ではクエリに画像を与えるのが特徴的です。この分野は、Content-Based Image Retrieval (CBIR)と呼ばれており、最新のサーベイ論文（Datta,2008）を読むと1990年代前半とけっこう昔から研究されてます。 最新の手法では、色、形状、テクスチャ、特徴点などさまざまな特徴量を用いて類似度を判定するそうですが、今回は、もっとも簡単な「色」を用いた類似画像検索を実験してみます

家庭用ゲーム機の劇的な進化がゲーム開発をより困難にしている？ 1983年に任天堂の「ファミリーコンピュータ」が登場し、社会現象を巻き起こしてから約26年。家庭用ゲーム機は飛躍的に進化を遂げ、現在の最新機であるソニーの「プレイステーション 3」（以下、PS3）、マイクロソフトの「Xbox 360」などでは、CGを駆使してまるで実写のようなリアルな映像が楽しめるゲームタイトルが次々と生み出されている。 こうした家庭用ゲーム機の進化に伴い、ゲームソフトの開発を手掛けるメーカーにとっては「より高品質なゲームタイトルを、より短納期に開発する」ことが求められるようになった。そのため、その開発プロジェクトも従来とは比べものにならないくらい規模が大きくなった。これが「開発工数とプログラムコード行数の増大によるバグの大量発生」など、さまざまな問題を引き起こしており、ゲーム業界全体の重大な課題となっている。

ゲームのシステムを語るならゲームのシステムとはどんなものかについて多少は理解しておいた方がいい。 2009-08-22 ゲーム内時間とリアル時間の差に文句を言っているけど、ゲーム内では通常フレーム数で時間をカウントする。だからリアル時間で何分だったとしても、ゲーム内時間はひとしく平等に与えられる。一般的にゲームは1秒間に60回画面を書き換える。モニタがそういう仕様だからそれに合わせて描き換える。*1この1回の書き換えの間にやれる操作は一緒。まぁボタンを押すか離すかだ。1/60秒以内でのボタンの操作はゲームが感知できない。だから連射速度の限界は秒間30連射。画面の描画タイミングに合わせてON/OFFをするシンクロ連射装置というのがソレ。 スーパーマリオをエミュレータで1/2の速度でプレイしたとしても、2倍速でプレイしたとしても、ゲーム内の絶対時間は変わらない。TIMEが100でクリアできるス

めずらしく釣りっぽいタイトルだけど、ちゃんと主張しておきたいので。 きっかけはこちらの記事。 極論すると、コメントが無いと読めないコードはダメ - かおるんダイアリー ここから色々リンクを辿ってみたけど、ほとんどの人が コメントを書かなくてもいいよう、十分明確なコードを書く 関数やメソッド名として切り出せば、その名称で示すことができるからコメントは要らない 処理からでは読み取れない情報（意図）や、複雑な処理のみ例外的にコメントを書く あたりに結論づけているのにちょっと危機感を覚えました。もちろん「コメントを書かなくても読み取れるようなコードを書く」というのはコーディングする上で大切なことだけど、じゃあ実際にコメントを書かなくてもいいのか、というと別問題でしょう。 私のスタンスは表題のとおり「いいから黙ってコメント書け」というもの。結論としては、 コードコメントに書くべきは「意図」 - プロ

良品計画は独自の開発手法を採用することで、システム開発の短期化とコスト削減を図った。2006年12月に再構築したMD（マーチャンダイジング）システムを皮切りに、08年12月までに約130のアプリケーションを社内で開発。一方で、IT 投資の売上高比率は04年の1.8％から0.9％に半減させた。「7割主義」と「スピード対応」を方針に掲げ、利用部門の要望に最速1日、遅くとも1～2週間で対応する。開発手法の独創性と、経営に資するシステム部門の姿が評価された。 「無印良品」ブランドの小売店を展開する良品計画は、1週間に1本という猛スピードで新しいアプリケーションを開発したり、機能を強化したりしている。「思い立ったら即実行。合格最低ラインの7割主義で素早くシステムを開発し、検証と改善を繰り返す」。IT戦略を統括する小森孝取締役 情報システム担当部長兼流通推進担当管掌は強調する。 同社は独自の開発方法論

こんにちはこんにちは！！ プログラミング言語とかマスターしてると、なんかかっこいい感じですよね！ 就職とか転職にもバッチリ有利そうだし…！ だけど難しいよね、言語とか…。 入門書とかどれだけ買ってみても毎回 Hello world どまりだし…。 なんでなんだろう？ なんでうまく覚えることができないんだろうね。 世の中には、ちゃんとプログラミングできる人がたくさんいるのに…！ うーん。 たぶんこれかな… なにか作りたいものがある または なにかを作る必要がある なんて状況以外で、マトモにプログラミング言語を習得してる人って ぼくほとんど見たことないんだけど、みなさんはどうでしょう…！ たしかに、コンピュータを教えてくれる学校に通って、ちゃんと教えてもらえればJavaだってなんだってしっかりと、その時だけは身に付くんだけど、 でもそういうのって、ほんとに「その時だけ」なんだよね…。ほとんどの

＃釣りっぽいタイトルですが大まじめです via. PHP 逆引きレシピ - 肉とご飯と甘いもの @ sotarok で、 @ （エラー制御演算子といいます！）はねーよ的な話をしましたが、著者の方から、「@に対して批判的になる理由が記載されていない」とのメールをいただきました。確かにその通りでした。実は理由を下書きのときには書いたのですが、長くなってしまったので削ってポストしたのですが、かえってわかりづらくなってしまいましたね．すみません。 ということで、PHPプログラマが、エラー制御演算子「@」使うべきでない 5 つの理由を述べます． 始める前に、本質的なところ 色々理由はつけようと、やっぱり前回述べた、 終的に$qに入るものが同じであることと、コードとして同じ意味であるかは、別じゃないでしょうか。 が一番本質的な話で、それ以上の話ではありません。 つまり、発生する可能性があるとわかってい

フレームワークとか使ってるともはや隠蔽されすぎて自分で実装しようなんて思わないのが普通である。 ましてや車輪の再開発などもってのほか、バグを生み出す温床にしかならない。 だが、どういう仕組みになっているのかを紐解くのに自分で再実装するのはそれはそれで有意義だろう。 君は今まで食したパンの枚数を覚えていなくてもいい。しかしそのパンがどのように作られているかを知ることは決して間違いじゃぁない。 自分で実装してみてわかることもある。あぁ、このライブラリって凄かったんだなと。 なんでこんなにコード長いの？もっと短く書けそうなのに。そう思って自分で再実装してみると、あれが足りないこれが足りない。あ、バグってた。ダメだこりゃ。元のライブラリより長くなっちゃった・・・あれ？しかもベンチ遅！！ みたいなことになる。 例えばPerlのCGI.pm。 CGIモジュールはもともとある種のフレームワークのようなも

まじめな話に切り替えて、Java屋さんJava信者さんに質問したいと思います。 質問: Java における、本質的でない冗長な記述は、どのように大規模開発に役立つのでしょうか。 質問の背景を説明すると、以前の晒されエントリで、Java における本質的でない記述の数々について話題にしました。それに対する反応で、『Java は大規模開発向けだから記述が長くてもいいんだ (または長くなくてはいけない)』という意見が多くあります。 たとえば、ブックマークコメントより: エンタプライズ分野であの大伽藍が求められたのだから仕方ないですよ。 エンタープライズ分野のような大規模開発こそ、必要な情報を簡潔にわかりやすく記述する必要があると思ってたんですが、世の中は違うようです。 同じくブックマークコメントより: Java屋の怠慢は高層ビル建築をどうサボるかであって、犬小屋を作る時にどうサボるかという視点とは

Java屋Java信者とスクリプト言語屋の間には、「めんどくさい」と感じるセンスについて超えられない壁が存在している。 本質的でない事柄に関する記述があったときに、スクリプト言語屋は「めんどくさい」と感じ、Java屋Java信者はそれを感じないか、または「これは必要な冗長性だ」と本気で思い込んでいる。 前にとり上げたけど、アクセッサの記述がその典型例。本質的でない記述がずらっと並んでいることに、Java屋Java信者はホントに何も感じないのだそうだ。あれがどれだけ readability を下げているか、まったく分かっていない。 また System.out.print() もそう。たかが print 文のくせして、なんで System.out.print() と書かないといけないのか。本来であれば、Java1.5 のタイミングで package java.util; public clas

UKTKKNSHINF こういう名前の変数が出てくるのだが、意味わかる？ 答え：受付禁止情報 今読んでいるPL/SQLコードは本当にひどい出来なのだが、その中でもネーミングが群を抜いてひどすぎてむしろ笑えてくるので、ここでさらしてみたい。 先ほどの例でわかると思うが、悪しきネーミング習慣である子音母音抜きの嵐である。変数名だろうが関数名だろうがこのルールで命名されているので、暗号文を読んでいるような気分になる。 他には、例えばこんなのがある。 SKSI 作成 HNKN 変換 KKT 確定 CHKN 中間 DTM Datetime DTA Data こうして見ると、ktkrやwktkとなんら違いがない。 "作成"のような、比較的簡単に対応する英単語が見つかるものまで日本語子音母音抜きで書くという徹底ぶり。でも"情報"はINFだったりする統一感のなさ。そしてこれらが単独ならまだしも、複合して出