p0t

プログラマーの力量を見極める--面接官になったら尋ねるべき質問実例集 - IT業界を生き抜く秘密10箇条 - ZDNet Japan

ソフトウェア開発者を採用する面接の場においては、応募者の専門家としての力量を見極めることが最も困難な作業の1つである。

現時点でプログラマーの面接についての自分の考えをまとめておきます。

結論：

• プログラマー採用にあたって応募者の力量を見極めることは困難ではない。（面接で見極めることは困難である。）

前提：

• 短時間の面接（対面して話す事）でプログラマーの力量を実用的な精度で見極めることは不可能である。
• 中途採用において、PCやネットと切り離した無菌室状態での力量と現実世界での成果には大きな差がある。
• 専門技能（プログラミング）の高低と人間性の良し悪しは無関係である。

採用方法：

1. ソースを見る。（githubのアカウント名を教えてもらえれば十分である）
2. 会って世間話する。

プログラマーの力量を見極めるにはソースを見れば良い。公開できるソースが無い場合は業務で作っているもの（たとえばブログ）を作ってソースを見せてもらえば良い。会う必要は無い。（ブログを見せてもらえば精度があがる）

プログラマーのとしての力量が十分であれば、それとは全く別に「自分たちと楽しく仕事ができるかどうか」を実際に会って確かめる。（要は人間性＝良い人かどうかを確かめる）世間話をすればいい。（大抵プログラマー同士の世間話はプログラミングに関することになるが。）

この２番目のプロセスは応募者にとって会社側を精査する場でもある。なるべく良い印象を持ってもらえるようにおもてなししよう。また退職はコスト的に非常に大きな損失なので入社後にお互いのミスマッチが起きないようになるべく現状を正直に話そう。（ミスマッチに気づくのが早ければ早いほど損失は小さくなる）

実際に会う面接は高コストなのでこの順番を逆にしてはいけない。

たったこれだけで採用コストは減り、精度は格段に上がる。採用する側がスーパープログラマーである必要もない。（ソースが読めれば普通のプログラマーで問題無い）

プログラマーの専門職としての社会的価値は成果物である動くプログラムである。PCやネットと隔離せず、それをなるべく自由な状態で作って見せてもらおう。プログラマーの力量を見るのにソースより雄弁なものがあるだろうか？

イチローがどんなに人格者だろうが内野安打が打てなければ偏屈糞バッターだ。キム・ヨナがどんなに（もしもね）アバズレでもトップクラスのアイススケーターであることは疑いようが無い。

管理職としての技能が知りたいなら別のプロセスが必要だろう。

何故このやり方を皆がとらないのかについての組織論は、このやり方を自分が取れない組織に入った時にまた考えます。

% crontab -l
30 17 * * 2,5 GEM_HOME=/opt/local/lib/ruby/gems/1.8 /Users/komagata/bin/ticket_alert.rb

cronで実行するときはGEM_HOMEを指定するのがコツみたい。

もう何がなにやら・・・

関連：俺の酷いMac - p0t

JavaScript: The Good Parts ―「良いパーツ」によるベストプラクティス オライリージャパン(2008-12-22) オライリージャパン (翻訳)水野 貴明 定価：￥ 1,890 新品価格：￥ 1,890 中古価格：￥ 2,180 ASIN：4873113911

javascriptでシンプルな差分プログラミングのやり方が知りたかったのでJavaScript: The Good Partsを立ち読みしに行ってきました。正に俺のような中途半端に書いてる野郎に最適な本だったんですが、薄い本だけど立ち読みだけで理解出来なかったので買って読みました。

とりあえず今まではよくあるプロトタイプ型の継承で書いていたんですが、小クラスから親クラスのメソッド（コンストラクタ含む）を呼ぶやり方がわからず困ってました。（コードが重複したり、コンストラクタに処理を書くのを避けたりして効率が悪かった。）

たとえばこんな感じです。（面倒なのでSpidermonkeyで実行）

#!/usr/bin/env js

function Human() {
  this.name = 'human'
}
Human.prototype.greeting = function() {
  print('Im ' + this.name)
}

function Fukumoto() {}
Fukumoto.prototype = new Human
Fukumoto.prototype.greeting = function() {
  this.parent.greeting() // super()的なことがしたい
  print('Im ' + this.name + '........!!??')
}

var kaiji = new Fukumoto
kaiji.greeting()

/users/komagata/code/proto.js:13: TypeError: this.parent has no properties

この本の「5章 継承 5.4 関数型」に載ってた関数型の継承を使ってみました。（本に載っているのはプライベート変数・プライベートメソッドを導入した更に優れたやり方でしたが、ユルイ代わりにもっと簡単な実装にしてみました。）

#!/usr/bin/env js

var human = function() {
  this.name = 'human'
  this.greeting = function() {
    print('Im ' + this.name)
  }
  return this
}

var fukumoto = function() {
  var superior = human(),
      superior_greeting = superior.greeting,
      that = superior
  that.greeting = function() {
    superior_greeting()
    print('Im ' + superior.name + ' .......!!??')
  }
  return that
}

var kaiji = fukumoto()
kaiji.greeting()

Im human
Im human .......!!??

擬似クラス型やプロトタイプ型はどうも自分のやりたい事にとってオーバー過ぎる気がしてたのでシンプルなやり方に出来てとても嬉しいです。

Twitter / tekitouotoko: 十字キーはUI史に残る歴史的発明。RPGにおける移動 ...

十字キーはUI史に残る歴史的発明。RPGにおける移動は、移動先のタッチよりも十字キーの方がインタラクションとして優れている、という判断では。 http://docs.komagata.org/4465

FF1を買って遊んでみました。

しばらくやってみて意外だったのは、ソフトウェア十字キーの移動よりもタッチインターフェースに合わせて変更が加えられたはずの戦闘の方がストレスを感じるということです。

「４人いるキャラクターのコマンドとその対象を順番に選び、その後に順番に行動するのを眺める」というシステム自体が十字キーを前提としたものだということに気付かされました。

タッチインターフェースは膨大な選択肢の中から目的を選ぶのに適したインターフェースで、決められた数個の選択肢から一つを選ぶことに関しては十字キーより面倒なんですね・・・。

コマンド選択式RPGではその「決められた数個の選択肢の中から一つを選ぶ」ということのコストが非常に低いため、それを束ねることで複雑な決定をしています。（移動も上下左右の４つの内、次に進む方向を一つ選ぶということを繰り返すシステム）

タッチで移動を行う擬似的なプログラム（iPhoneでアクセスしてみて！）を作ってみましたが、正直移動に関してはソフトウェア十字キーよりタッチだと思いました。（ハードウェア十字キーがあればコマンド選択式RPGはそちらの方が良いことはPSPやDSを見れば分かる）

しかしトータルで見ればFF1、ひいてはコマンド選択式RPGという成功したゲームジャンルの面白さ自体が十字キーという大発明とは切り離せないということがわかりました。（RTSがマウスインターフェースと切り離せないように）

結論としては「FF1はiPhoneで出すなら全く新しいUIの方がマッチするはずだが、十字キーあってのものなので十字キーでなくなるとFF1ではなくなってしまう。FF1でありたいならハードウェア十字キーより劣るとしてもソフトウェア十字キーを採用するしかない。」ということです。

前回のエントリー（何故ソフトウェア十字キーを採用するのか - p0t）への回答はこうなります。

俺A：「何故FF1 touchは十字キーなのですか？」

俺A'：「十字キーだからFF1なのです。」

「そんなもんはじめからわかってるよ！」という結論ですが、過程でそれぞれのUIの利点と欠点が明確になりました。

例えば、タッチインターフェースは１アクションのコスト（面倒臭さ）は大きく、触覚へのフィードバックも少ないので他のインターフェースのものよりアクション時のリアクション（エフェクトとか効果音）は大げさにする必要があるように思います。逆にそれが気持ちの良いものになれば、他のインターフェースより大きい快感が得られる。

３つのオブジェクトが動いていて、それのうちどれかを選択するという動作があるとして、派手なリアクションを用意すればタッチ、マウス、十字キーのインターフェースの内で一番楽しいのはタッチのような気がします。

関連：何故ソフトウェア十字キーを採用するのか - p0t

Lingrのログ。

# Y-Mat: Haskell!!レフリー！え”“ぇ～！！

# komagata: はぁぁあすける！

# kawadu: Haskell えぇぇ！I am champion….

# Y-Mat: 「高階関数使えば一発じゃん。」みたいなことが言いたい。

# Y-Mat: 例１.「りんごとハチミツでカリー化しようぜ」

# komagata: ↑カリー化の誤った使用例

# Y-Mat: マジでか・・・

全員、普通のHaskell勉強会で何も学んでない。

移行する時。

update wp_options set option_value = 'http://example.com' where option_name in ('siteurl', 'home');

URLがDBの中に入っているので移行が面倒。

slowlog

[mysqld]
log-slow-queries=/var/log/mysqld-slow.log
long-query-time=1

slowlogをメール

dailyでlogrotateしておいて、下記。

% crontab -l
50 3 * * * mysqldumpslow -s t /var/log/mysqld-slow.log | mail -s "mysql slowlog" foo@bar.com

CSVにエクスポート

SELECT * FROM employees INTO OUTFILE "/tmp/employees.csv" FIELDS TERMINATED BY ',' optionally enclosed by '"';

CSVからインポート

load data infile "item.csv" into table item fields terminated by ',' optionally enclosed by '"';

CSVからインポート（１行目を無視）

load data infile "item.csv" into table item fields terminated by ',' OPTIONALLY ENCLOSED BY '"' ignore 1 lines;

auto_incrementの値を設定

ALTER TABLE test AUTO_INCREMENT = 1;

ユーザー追加

grant all on *.* to `foo-bar`@localhost identified by 'hoehope';

バッククォートで囲えばハイフンも使える。

rootのパスワード削除

set password for root@localhost=password('');

DBバックアップ

% crontab -e
0 5 * * * mysqldump -uproject -pxxxxxxx project_production | bzip2 > /var/www/html/project/backups/project_production.`date +\%Y\%m\%d\%H\%M\%S`.dmp.bz2

カラム追加

ALTER TABLE `foos` ADD COLUMN `foo_id` int(11) NOT NULL DEFAULT 123 AFTER `title`;

Macにインストール

% sudo port install mysql5 +server
% sudo -u mysql mysql_install_db5
% sudo cp /opt/local/share/mysql5/mysql/my-small.cnf /etc/my.cnf

Macで起動

% sudo /opt/local/share/mysql5/mysql/mysql.server start

Macでlaunchdで再起動

% sudo launchctl stop org.macports.mysql5
% sudo launchctl start org.macports.mysql5

文字化け

# my.cnf
default-character-set = utf8
skip-character-set-client-handshake

外部からの接続禁止

# my.cnf
skip-networking

Webデザインがつまらなく見えてしまう理由 : could

今、私たちがしている仕事は Web をデザインしているというより「この要件を満たすためには A と B と C がいる」という組み合わせを探して組み立てているだけに過ぎないのではないかと感じることがあります。紙デザインへの憧れとノスタルジーを感じながら、どうにかして Web へそのまま移行しようと努力していることもあります。そうした試行錯誤をデザインプロセスと呼ぶことはありますが、これらの仕事をする人が Web デザイナーであるとするのは少し寂しいことだと思います。

こちらのエントリーを読んでつい最近感じた疑問が整理された気がしました。

この間、会社で同僚が他の紙媒体出身のデザイナーの方と共同作業したときに、こちらのユーザービリティやアクセシビリティの考えと、先方のデザインが尽く噛みあわなかったということが起こったそうです。同僚の感覚からすると、一般的なディスプレイで上から画面の８０％近くをコンテンツ本文ではなく、ロゴが占めていることや、検索機能や最終目的であるはずの資料請求フォームへの動線が分かり辛いこと、テキストを斜めに配置する必要があるデザインはまったく理解できなかったそうです。

先方はそれに対して「Webを紙のレベルにまで引き上げたいのです。」という主張をされたそうです。

この話しについて僕はそのモチベーションやストレスが理解出来なく、何故そう思うのか、また同僚と先方の意識のズレはどういう構造になっているのかとても気になっていました。

結論を言うと、Webデザインが示す領域が広すぎることから来る齟齬だと思いました。

AJAXが登場したときにも「デザイナーはどの程度エンジニアリングに踏み込むべきか」や「アーティストとデザイナーの定義の違い」などが話題になりましたが、Webデザインが対象とする領域はあまりに広過ぎます。

要は、Webデザインは「絵画」、「椅子」、「映画」、「音楽」、「ゲーム」、「広告」、「ネットワークを利用した未知のコミュニケーションツール」などの全てを含み、何を作るのかによって目的や方法論が全く違うために、上記のような齟齬が発生するのだと思います。

僕は「化粧品ブランドのデザインを主にする会社」と「ビジネスツールを作る会社」と「広告・集客手段としてのWeb」を作る会社にそれぞれシステム担当としてですが、在籍したことがあります。それぞれの会社でのデザイナーの方の目的や方法論、適性は明らかに全く別のものでした。（たとえば、高級な化粧品ブランドのサイトでは何よりもブランドイメージやプレミアム感などがアクセスビリティやWeb標準への準拠より収益に貢献していたように思います。一方、ビジネスツールでは何よりも分かり易さや機能美が求められるでしょう。）現実には「画家」と「（例えば椅子の）インダストリアルデザイナー」は全く違う仕事のやり方をしているのではないでしょうか？それがWebでは「Webデザイナー」という一言でまとめられてしまいます。（システムの言葉で言えば、クラスの粒度が荒いのでしょう）

完全に僕の予想ですが、そういった、実際には畑違いであるはずの理屈を押し付けられるストレスが、現状のWebデザインにおける不全感につながるのではないでしょうか。（例えば上記のブログのデザイナーの方はアーティスティックなデザインやインタラクティブなコンテンツなどを得意とされているところにママチャリのような「汎用部品でどれだけ無駄なく最低限の機能を満たすか」というようなデザインを求められても楽しくないかもしれません。個人的にはママチャリやスーパーカブなどを見て「よくこんなプリミティブな作りでまともに走るよなあ、といった機能美的なものを感じることがありますｗ）

上記のようなWebデザインの中でももっと粒度の細かいカテゴリーを意識し、自分のやり方を押し通すのではなく、対象とするWebサイトの目的に合わせた方法論を選択することが大事なのではないかと思います。

ダウンロードの詳細 : Windows XP 向け Windows Internet Explorer 7

Windows XP SP2〜3用のIE7。少し見つけ辛いのでリンク置いておきます。