komagataのブログ

フレームワークで分析するのを本当にやめて欲しい: 切込隊長BLOG（ブログ） Lead‐off man's Blog

まあ、何を言いたいかというと、現場で頑張る人、現場を仕切る管理職、組織を率いる経営者と、立場によって知っておくべき枠組みや、価値観・優先順位は違うんだよ、ということ。4象限程度のフレームワークで仕事していいのは、現場や物理を相手にする物づくりの人たちだけ。

「問題を構成する最小限の要素の性質と関係を詳しく調べていけば全ての問題が解決するはず」というボトムアップ式の思考では対応できる問題の複雑度が低く、市場予測や経営といった複雑な問題を解決する手法として適さない。（できるとしても計算量が多すぎて現実的な時間無いに終わらない。）

それが理解されないというイラつきでしょうか。

こちらのブログの方はおそらく話したり書き殴ったりするより考えるスピードの方が速くて終わる頃には自分の中で結論はまとまっていて、既に次のことを考えているといった感じの人なんじゃないでしょうか。頭の回転が速い人を見ていてそうなのかな、と思うことがあります。

僕は頭の回転が遅く、話すのもゆっくりなので、風呂入ったり、誰かに話したり、ブログに書いたりしないと考えがまとまりません。

上記の点を相手に説明するとしたらこういう感じでしょうか。

線形代数に対して非線形科学があるように、ボトムアップだけが問題解決の手法ではない。ブラックボックスの群れの動きのパターンから法則を見つけだして予測し、制御する手法が市場予測や経営などには有効である。

メンドイのでSpidermonkeyで実行。

#!/usr/bin/env js                                                             

var human = function() {                                                      
  var that = {}                                                               
  that.say = function() {
    print('Hello!')
    return that
  }
  return that
}

var employee = function() {
  var that = human()
  that.has_work = true
  return that
}

var neet = function() {
  var that = human()
  that.has_work = false
  that.say = function() {
    print('絶対に働きたくないでござる！')
    return that
  }
  return that
}

human().say()
employee().say()
neet().say()

Hello!
Hello!
絶対に働きたくないでござる！

簡単。

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

プログラマーの力量を見極める--面接官になったら尋ねるべき質問実例集 - 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を指定するのがコツみたい。

ticket_alert.rb:

#!/usr/bin/env ruby
require 'rubygems'
require 'rb-skypemac'

class TicketAlert
  def self.run!(chat_id, msg)
    SkypeMac::Skype.send_(:command => "CHATMESSAGE #{chat_id} #{msg}")
  end
end

if __FILE__ == $0
  TicketAlert.run!('#komagata1111/$xxxxxxxxxxxx', <<-EOS)
お疲れ様です。駒形です。
チケット確認の時間が近いので各自、自分のチケットの期限の確認をお願い致します。

また、期限が過ぎた方に「理由」と「対策」を求めるメールをお送りしていますが、必ず返信していただくようお願い致します。
  EOS
end

毎週火曜日・金曜日の18時にRedmineのタスク期限オーバーチェックを行っています。30分前にこのメッセージが全員参加Skypeチャットにこのメッセージを贈るのが上記のcronの設定です。（ここに書いてある「期限が過ぎた方にメールを送る」というのも別のcronジョブで自動化しています。（MechanizeでRedmineをスクレイプしている。）

これだけでタスクの期限オーバーは激減しました。

もう何がなにやら・・・

関連：俺の酷い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

移行する時。

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

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

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。少し見つけ辛いのでリンク置いておきます。