Voxeo Prophecyで遊ぼう！ その2

前回＜＞次回

良いプログラマーの第一条件を教えて。経験？

「いや、インスピレーションだ。」

時刻の読み上げって実はあいまい

Voxeo Prophecy講座の合間にちょっとした小話でも。

Windows Live Writerを試してみた

今まで名前だけは聞き及んでいたのですが、
なんだかんだでBlogger標準のエディターに慣れて使っていませんでした。

Voxeo Prophecyで遊ぼう！ その1

＞次回

はじめに

今までちらほらとIVRについて話題にしてきましたが、
コールセンターのような業界にいない人には全然なんのことやらだと思います。

ということでIVRについての簡単な説明と、
個人でもIVRを体験できるVoxeo Prophecyの利用方法について記事にしたいと思います。


IVRとは？

とりあえずはIVRのwikipediaを読んでみましょう。

日本語で言えば"音声自動応答装置"となり、
英語で言えば"Interactive Voice Response"が正式名称となります。

要は自動的に声で受け答えしてくれる機械は、
何であれIVRと言えます。

ただ実用化されている中で一番よく使われているのが電話であり、
IVRと言えば電話の自動応答を連想する方が多いのではないでしょうか。

さらにぶっちゃけて言ってしまえば、
録音以外にも色々できる高性能な留守電です。

IVR＝スーパー留守電だと思っていれば、
この章の理解は十分と言えます。


Voxeo Prophecyとは

IVRは色んな企業が開発していて、
Voxeo ProphecyはVoxeo社が開発したIVRです。(最近Aspect社に買収されましたが)

残念ながら私達がよく使っている電話へ直接つなぐことはできませんが、
IP電話と呼ばれる電話機にはSIPと呼ばれるプロトコルで接続することができます。

情報系の資格を勉強した方であれば
VoIPというキーワードで聞き及んでいるかもしれません。

まあ色々デジタルなんですよ！(頭が悪い言い方ですいません…)

そしてVoxeo Prophecyの凄いところは、
2回線まで無料で使えるというところです。

ちょっと調べると分かるのですが、
他の企業の製品はこんなに簡単には使わせてくれないのです。

だから個人でお手軽に試すのであれば、
Voxeo Prophecyは数少ない選択肢のひとつとなるのです。

…今のところはね。

そしてVoxeo Prophecyに色々と命令を下してやれば、
自分が思ったとおりに電話の受け答えをしてくれるようになります。

ひと昔前まではこの命令が製品ごとに違っていて混沌としていたのですが、
新しい製品になるとVoiceXMLという規格に合わせてくれています。

だから他の製品に乗り換えることになったとしても、
その経験は無駄にはなりません。

そうですね、
VoiceXML Forumでは審査を通過した製品の一覧を閲覧することができます。

Voxeo Prophecyもその中のひとつなのですが、
他にも様々な製品が通過していることが分かると思います。

これ以外にも審査を通過していないものもたくさんあります。

Vポータルダイレクトはその中の代表例です。

英語にアレルギー反応がある方でしたら、
Voxeo Prophecyではなくこちらを試してみるのも良いでしょう。

そこで覚えたことも、
後でVoxeo Prophecyを使う際に役立つわけですから。


Voxeo Prophecyの入手

さっそくVoxeo Prophecyを入手してみましょう。

入手するだけであれば、
特別な審査や登録は必要ありません。

http://voxeo.com/prophecy/

上記のURLを適当なWebブラウザで開き、
Voxeo ProphecyのバージョンとインストールするOSを選びます。

 

後は[Download Prophecy Now!]ボタンをクリックすれば、

インストーラーをダウンロードすることができます。

 

結構サイズが大きいので、

ナローバンドの回線の方は気長に待ってください。

 

ともあれ、

これでVoxeo Prophecyを入手することができました。

 

次はインストールです。

 

次回をおたのしみに！

 

＞次回



部下の報告を密にするには、上司の情報展開を密にするべき…という仮説

報連相をまめに行うように部下へ指示する上司を見かけることはありませんか？

別に統計なんて取っていませんが、
日本中のいたるところで観測されるのではないでしょうか。

そして、そういった方たちの評価を聞いていると面白いことが分かります。

その人が情報を抱え込んでいて、
必要な情報が伝わってこないと言うのです。


その逆…かは微妙ですが、
報告を待たずに情報が欲しければ自分から聞きに来る上司もいます。

そこまで部下からの報告には執着していません。

まああんまり頻繁に来られるとコンテクストスイッチングの問題が発生しますが、
ここでは無視して先へ進みます。

そういった方たちの場合、
情報が何らかの形で展開されていることが多いように思えるのです。

そしてその情報に疑問があった場合、
自然と報告や連絡が入るのです。


もしかしてコミュニケーションの情報量って、
お互いの送信量の平均に均衡する力が働くんじゃないでしょうか？

つまり相手に情報を吐いて欲しければ、
自分から出力する情報量を増やすのです。

そうすると情報量の総和が増えるので、
その平均値に近づこうと相手からの情報量が自然と増えるわけです。

逆に位置する自分に対しては、
情報量が減るよう力学が働きます。

そのまま減らしては相手の情報量が増える前に均衡してしまうかもしれません。

何らかの形で、
出力を維持し続ける仕組みを構築する必要があります。


いやいや、
逆に部下から情報量が増えた場合はどうでしょう？

それは平均値で均衡するのでしょうか？

直感でしかありませんが、
これは上手くいかない気がします。

役職に差がある場合は、
別のパラメーターを考えないといけない気がします。


どうも立脚点としては悪く無いと思うのですが、
他にも必要なパラメーターが存在するようです。

まだ練り込みが必要ということでしょうか。


NGワード：その上司はピーターの法則で生まれた、無能レベルに達した人物では？

緊急性のないタスクは２個以上こなそうとしない

ゼークトの組織論ではないのですが、
自分は相当な怠け者体質です。

夏休みの宿題なんてまるでやる気にもならないですし、
あれをやろうこれをやろうと思い立っても、
メモだけとってやらない企画書が山のように転がっています。

でも塵も積もればMt.Fuji、
少しずつでもやり続けなければ意味がありません。
(iKnowは本当によく続いているな～奇跡だよ)

そこで考えたのは、
１日に手をつける非緊急なタスクを１個に絞るって手法です。

今までは１日にあれもやろうこれもやろうといつも考えて、
タスクの山にやる気を失っていました。

いえ、今までも１個ではあったのですが、
もし早く終わったら次はこれ…と妄想するのを辞めたいのです。

つまりタスクが１個終わったらもう寝る！

もしくはelonaして寝る！

とサボることに積極的になることでサボらなくしたいのです。(意味不明)


さあ皆さんご一緒に！

「タスクは１個！
終わったら寝る！
欲張りません、怠惰だから！
目指すは有能な怠け者！」

CAREER2.0の招待コード欲しい？

たま～にプロフィールを更新したり、
日本の求人を読んてネタにしているCAREERS2.0ですが、
招待コードを全然使っていないことを思い出しました。

というわけで、
突然ですが欲しい人はメールで連絡ください。
(先着5 4 名)

日本で登録している人は多分少ないので、
積極的に活用すれば思わぬ収穫があるやもしれません。[要出典]

ただし、
英語で履歴書を書ける人である必要があると思います。

全部埋めるのは結構たいへんなので、
そのあたりはお覚悟ください。

…そんなことが出来る人はStackOverflowのスコアも高いでしょうし、
招待なんていらないって人が大半のよかーん。

質問などはブログのコメントでどうぞ。

名言は不可逆圧縮形式

この世には、
数多くの*名言*と呼ばれるものが残されています。

本人が本当にいったかどうか怪しいものも数多くありますが、
簡潔で力強いその言霊は、
私達の心を、魂を、捉えて離しません。

人によってはその名言のうちのひとつを胸に秘め、
心の支えとして生きていく人だっていることでしょう。


でも待ってください。

名言ってその背景に対して、
あまりに簡潔すぎやしないでしょうか。

名言はその言葉を放った人物の、
経緯・情勢・信念の様々な要素が詰められています。

名言の真意を詳しく知ろうとすると、
ものすご～く長い文章を読むことになったりしたことはありませんか？

それはまさに正しくて、
名言はその背景をまとめた要旨ってわけです。


ここから何が言いたいかというと、
つまり名言だけを鵜呑みにするのは危険を伴うと主張したいのです。

その背景を理解していないわけなので、
大きな勘違いをしているかもしれません。

ちょうど故事のことわざの意味を覚え違えるように。

これを無自覚にやっていないでしょうか。


もし好きな名言をお持ちでしたら、
今一度その名言の背景をよく調べてみてください。

実は思っていたことと全然違っていた…
なんてことがあるやもしれません。


そう、名言は不可逆の圧縮形式なのです。

たまには元のデータを参照してみましょう。

もっと色彩鮮やかかもしれませんよ？

銀行のシステムは負債まみれで信用できない

SIer系の仕事でも特に(技術力がある人ほど)嫌われる仕事に、
銀行系ってものがあります。

誰も理解していない仕様、
ゴミ屋敷を見事に再現した設計、
変更履歴で半分が埋まっているソースコード、
手作業とエビデンスを要求する膨大なテスト、
朝令暮改の指示に労働基準法を無視する風調、
などなど、
数え上げればキリがありません。

そんなことが、
誰もが聞いたことのありそうな大きな銀行で起こっているのです。


プログラマーはこのような状態を、
"技術的負債が返済不能に陥った"などと表現することがあります。

もうどんな簡単な修正でもリスクがつきまとい、
システムを一新しようにもどこから手をつければいいかも分からない。

お金と時間だけは浪費され、
肥えるのは一次請けのSIerくらいのもの。

そんなことが、
問題が起こって訴訟されるまで続きます。

SIerから見れば、
訴訟されないギリギリのラインまで品質を下げる行為によって利益が最大化されるわけです。

無自覚な悪徳商法なんですねぇ…


お金を貸すプロフェッショナルの銀行が、
技術的負債を返済不能な状態になっている…なんという皮肉でしょうか。

銀行の幹部の皆さんは、
自分たちのシステムがゴミでデコレーションされたジャングルジムだとは夢にも思っていません。

ちなみにこれからシステムを買おうとしている銀行も問題なんです。

SIerが提案するソリューションというのは、
過去に別の銀行へ納品したシステムが基となっていることが多いからです。

それは既に技術的負債をたんまりと抱えこんでいて、
銀行は負債を背負うことに対してお金を払うという謎の取引が成立します。

でも買うしかないのです。

銀行の担当者の選択肢に正解が無いのですから。

どれを買っても借金まみれ。

ならばどれを買っても大差ありません。

だから値段の一番安いところが勝つわけです。

銀行のシステムが障害を引き起こして事件となることがありますが、
言ってしまえば運が悪かったに過ぎません。

他の銀行も大なり小なりひどいもので、
何かきっかけさえあれば負債が大爆発することに変わりないのですから。

おっと銀行に限らない話題ではあるのですけど、
その筆頭ってことで。


…ではどうやって解決するか？

この手の話は結局SIerもお客も双方が悪くて、
問題も様々な箇所が絡み合っています。

いわゆる複雑なデッドロック状態なのが曲者です。

どこか一箇所を改善しても効果が無くて、
かなり大きなブロックをまとめて交換するような作業になるはずです。

こんな大規模な改革は大規模な反感を生み、
大多数の反対派によって抑えこまれます。

かなり勝手な推測ですが、
日本人は増分の成長はできても飛び石の成長は自力ではできないようなのです。

そしてこれは飛び石の成長に属するもので、
やろうとした人達は次の石へ飛び移る前に撃墜されています。

そこに救いの手はありません。


せめてお互いに改善する意欲があれば良いのですけど…

Windows8.1 migration problem

I updated Windows8 to Windows8.1.

Unfortunately few software was not start.
They required reinstall.

• Cisco VPN Client
• VMWare Player
• Voxeo Prophecy (and regenerate license key)

If you planning update, you should check your software action.



[Japanese]
Windows8からWindows8.1にアップグレードしたら、
いくつかのソフトが再インストールを必要としちゃったよ！

やるならちゃんと動くか調べた方がいいよ！

One point of Installing Voxeo Prophecy

A few month ago, I installed Voxeo Prophecy 13 in Windows8 64bit.

But I faced a small problem.


Installer stopped, when install was almost finished.

Maybe it was working to stop own services.

What is service to stop installer?

I thought long hours and found doubtful point.

Windows task tray showed plural icon of Prophecy.

When I was stopped both icon, Installer was start again.


I didn't understand its cause, but the story is already past.

I satisfy to have a solution.

プログラマーは霊感を信じている

プログラマーは極めて論理的です。

感情によって物事が左右されない世界で仕事をしています。

他の職業の方々から見れば、
冷徹で無機質な人間に見えるかもしれません。

かと言って、
プログラマーの全てが論理的なのかと言うとそれは違います。

プログラマーにだって表には出にくいかもしれませんが感情はあります。

理屈を抜きにして成し得たい事だってあります。

そして、
非論理的なことを信じていることだってあるのです。



その代表的な例が"霊感"です。

日本語で言うともの凄くうさんくさいですが、
英語で言うとinspiredです。

カタカナ語で言えばインスパイアかな？

理屈抜きで降りてくる天啓とも言える感覚、
それを"霊感"と呼んで大事にしているのです。

「これを理解するには霊感を必要とする。」

「これを思いつくには霊感を必要とする。」

「このバグに気がついたのは霊感がうずいたとしか言えない。」

などと言った使い方でもするでしょうか。



え？こんなの霊感って言わない？

どっちかと言うと直感？

でもinspiredの直訳は霊感を受けてとかですしおすし～

待ちぼうけを助ける手を自分は持たない

よくビジネスの場を眺めていると、
「何か良いアイデアがあったら教えてくれない？」
と言い回っている人をよくみかけます。

しかしその人が何かしら努力しているかというとそうでもなく、
単に自分が手を動かしたくないので聞いていることが多いです。[要出典]

一緒に考えてくれというわけでもなく、
ただただ鯉が餌を求めて口を開いたままにするが如し。

故事というか日本なら歌に倣えば、
こういうのを"待ちぼうけ"というのではないでしょうか。

そしてこの歌が教えてくれる結末は、
そんな人に何かが舞い降りる事は奇跡でも起こらないとないってことです。

「負の連鎖、正の連鎖」では歩み寄ろうとはあるのですが、
間抜けな鯉口を見ているとどうにもその気は起きないのです。
※記事そのものは凄く同意したいんですけどね…

仮に助けたところで、
それを癖にされても困りますしね。

私は足掻く者の方に味方します。

例えそれが自分にとっては当たり前のことでも、
パソコンの操作に苦しんでいる初心者が居ればそちらを助けます。

…一般的じゃないのかな？

DLCが流行るわけ(*´ω｀*)

現在メタルマックス４のプレイ時間が90時間を突破したわけなんですが、
最近流行りのダウンロードコンテンツはこいつにも実装されています。

う～ん、戦車はともかく仲間や賞金首は気になります。

まあ自分の場合はそうそうダウンロードコンテンツには手を出しませんけどね。

これも販売戦略ってやつだと思い、
割り切るとしましょう。


でも昔は追加料金を払わなくてもゲームを１００％楽しめたのに…

と嘆きと怒りを露わにしている方はいらっしゃいませんか？

まぁまぁ、落ち着いてください。

ダウンロードコンテンツが発展するのは必然と言っても良いのです。

経済的に考えれば、ですけど。


まずはこの記事、
「ラクダとおもちゃのアヒル」を読んでください。

読みましたか？

では話を再開します。

と言っても、
もうほとんど答えを言ってしまったでしょうか。

要はダウンロードコンテンツでお金を払う人達は、
ゲームの定価以上にお金を支払う気がある人達ってことです。

よくフリーの名作には振り込めない詐欺なんて異名が付きますが、
まさにその心理です。

このゲームは定価だと安すぎる！もっと価値があるはずだ！

という層に対して、
ダウンロードコンテンツという形で支払い先を用意しているだけなのです。

こういう視点で考えると、
ちょっとはやらないと損であるかのように感じてきませんか？


ではダウンロードコンテンツ以外にも応用してみましょう。

例えば初回限定版なんてどうでしょう。

これも一種のプレミアム価格と言えませんか？

通常版よりも高い初回限定版の値段で買ってくれるんですから、
これもより多くのお金を払ってくれる層へ訴えかけています。

また通常版との値段の差が無かったとしても、
中古ではなく新品を買ってくれる可能性が高まります。

今度は中古でいいや層に特典を与えることで、
その一部を新品買うか層に変換しているのです。

中古だと収入にならないので、
ちょっとした特典で新品を買ってくれるのであれば儲けものってわけです。


あ、こう考えると、
いわゆるBest版と呼ばれる販売手法も説明できそうです。

Best版はだいぶ前に発売されたゲームを安い値段で再販するものですが、
これは時期を待って中古で買えれば良い層への訴えかけです。

中古と大差ない値段で新品のBest版が買えるのであれば、
そちらを選ぶ人は一定数いるはずです。

発売当初よりも収入が減りますが、
メーカー希望小売価格では拾いきれなかったユーザーを獲得できたわけです。

収入もありますし、
ファンになってもらえれば次の作品からは発売日に買ってもらえるかも！？

なんて期待を持つことだってできるわけです。

…既に高い評価を得ていることが前提ですけどね。


こうして考えると、
今のゲームソフトの販売戦略はちゃんと考えられていることが分かります。

まあ中にはえげつないのもありますけど、
経済学的に正当な進化を続けてきた結果と言えるのではないでしょうか。


だがタイトルの顔文字は流行らないし流行らせない。

手に入れし無線の力

手持ちのスマートフォンの充電端子がダメになったくさいので、
買い換えることにしました。

ただせっかくなので、
以前から注目していたQi対応機にしてみました。

auではまだこの一機種(iPhoneを除く)のみなのが悲しいですが、
今後普及することを祈って買うことにしました。

ちなみに、
普通に買うよりも1万円ちょい高くなります。

専用バッテリー、専用カバー、Qi対応充電機の3点セットですね。

さらにもう1台充電機を買って、
もう少しカッコよくしてみました。

あ、写真の黒い方ですよ。

黒のスマートフォンと相性抜群です。

これなら充電端子がダメになることもありません。

もっと流行れ♪(*´ω｀*)

githubのTシャツを購入しました

いや、買ったのはもう結構前なんですが、
そういえば記事にしてなかったとネタに上げてみました。

このシャツのデザインが一番気に入ったので、
とりあえず一点買いです。

やっぱりあんまりロゴが出しゃばらないのがいいですね。

ただやっぱり送料が痛いので、
今後は何かのカンファレンスに出向いて購入したいです。

社内でまでお客様のフォーマットに付き合う義理はない

だいぶ前からExcel方眼紙の撲滅…

ゴホン！

Excelの適切な目的での利用を推進している自分ですが、
相手がお客様だったりするとそうも言えません。

印刷したら3桁になりそうな文書であっても、
一切の疑問も持たずにExcelで渡されたり、または要求されます。

編集しているうちに印刷範囲が狂っていき、
画像は印刷プレビューで違う位置に表示される…

匠の技に見えるバッドノウハウが横行し、
作業効率はがくっと下がることでしょう。


効率の低下は免れないにしても、
せめてその軽減には努めなければなりません。

せめて自分たちが扱う範囲では、
Excelという枷から解き放ってあげましょう。

具体的にはお客様から受け取る、
または提出する瞬間のみExcelであれば良いのです。

そのためには、
自分たちにとって都合のよいフォーマットへの変換プログラムが必要です。

だいたいは自作する必要があるかと思います。

ですが一般企業はともかく、
ことソフトウェアを専門に扱っている企業にできないはずはありません。

最初は逆に効率が下がることでしょうが、
いずれは逆転し、
企業全体の生産性向上に貢献してくれることでしょう。


その為のノウハウであれば、
それは決してバッドノウハウなどではないはずです。

社内のフォーマットを決めるのは、
社内の人間であるべきなのです。

日本語のソースコード、データベースのテーブル名について

結構大きな企業のデータベースを覗いてみると、
意外にも日本語のテーブル名、列名であることが多々あります。

さすがにソースコードで見かけることは少ないのですが、
日本語のファイル名やクラス名、メソッド名を付ける障壁は昔より減りました。

これらを良しとするのか、
それともバッドノウハウとして駆逐するのか。

この決着は未だについていないのですが、
自分はどうなのかを自問自答してみました。


その結果、
条件付きで日本語を使っても構わないというのが自分の結論でした。

その条件というのは、
システム内で頭から尻尾まで文字コードを統一しておくことです。

もし混在しているのであれば、
余計な問題に頭を悩ませることになるかもしれません。

ああ、UTF-8であればなお良しです。

XMLが最低限サポートする必要があるのがUTF-8(だったはず)なので、
最近のシステムならとりあえず選んどけレベルです。

後は海外製のソフトウェアやライブラリを入れないことです。

書式がXMLのUTF-8だからと安心していると、
日本語のためだけにエラーを吐くことなんて日常茶飯事です。

まあ普段使ってないとテストの項目にも上がりにくいものなのでしょう。

でも有名なオープンソースの大半は海外の作品なので、
この条件を入れるとかなり適用出来るシステムが絞られてしまったりします。


え～と結論としましては、
かなり限定的ですが日本語もありってことで。

限定の強さは…自分なら英語を勉強しておくレベルってくらい。

そんな感じ。

常識は疑ってかかった方が良い理由

「こんなのは常識だよ。」

おそらく日本中の、
いたるところで聞かれる言葉ではないでしょうか。

日本人は"常識"という尺度によって、
まったく明文化されていない様々なルールを共有しています。

"空気を読む"に該当する能力が低い人達から見れば、
お互いがテレパシーでもしているのではと錯覚さえ覚えます。

ですがこれがコミュニケーションの省力化を促進し、
高度成長期を支えてきたのではないかと言われています。


まあそれはさておき、
今日の話はそんな常識は疑ってかかれという話です。

とりあえず一例をスラッシュドット・ジャパンのコメントからでも…

"商習慣という糞"というのを引っ張ってみました。

これがどこまで真実なのかは定かではありませんが、
習慣や常識から悪いと思わない事例なんて枚挙にいとまがないのではないでしょうか。

ではなぜこんな事が起こりうるのか？

それは"常識"という時点で思考放棄しているからではないでしょうか。

プログラミングっぽく言えば、
action.isCommonSense(time, place)の結果のみに着目している状態でしょうか。

でもこの関数って前例主義で特にテストもされていないわけでして、
結果が正しいかどうかはかなり怪しいものです。
(何が正しい事なのかというのはとりあえず置いときます。)

他の方がテストしたら正しいのか？

いえ、
isCommonSense関数の中身なんて十人十色でしょうし、
結果が同じなのはたまたま価値観が同じってだけでしょう。

なのでこの関数の利用はどうしても判断するのに困ったときだけにして、
普段は自分の頭脳で正しい事なのかどうかを検証するべきではありませんか？


…う～ん、
これを万人に求めるには負荷が高すぎるでしょうか。

ではせめて、
isCommonSense関数の結果が間違っていることもあると認識していただけないでしょうか。


たったそれだけで、
日本はもう少しだけ良くなる気がします。
(常識に依存している人から見れば発狂する内容…なのかなぁ。)

学習速度を上げる学習をしよう

プログラミング言語には、
実に様々な種類があります。

プログラミングを学び始めた人間から見れば、
そのうちのひとつを習得するだけでも大変なことです。

まるでフルマラソンでもしてきたかのようです。

そんな人達に新しいプログラミング言語の学習を迫っても、
まあ無茶な話です。


しかしその一方、
上級者にもなるとプログラミング言語の変更はそこまで大事では無くなります。

iPhoneが気に入ればObjective Cが初めてでも気にせず開発を始めます。

Google App Engineでクラウドの練習を始めるのであれば、
軽い気持ちでPythonを始めようという気になります。


これは、
いくらなんでも差がありすぎやしないでしょうか。


自分のささやかな経験から語らせてもらうと、
学習速度を上げる学習をしているからではないでしょうか。

簡単な言葉に言い換えれば、
*基礎*ってやつです。

プログラミング言語の背景には、
その骨格を成す共通の要素があります。（例えばλ計算とか）

上級者たちはその一見役に立たなそうな*基礎*の重要性を悟り、
逃げずに立ち向かった結果成長したのです。

それは今すぐ役立つものではないのですが、
長期的な視点に立つと極めてハイリターンな投資です。

この投資を終えた頃には、
新しいプログラミング言語を習得するのはご近所の散歩レベルになっています。
(まあ極めるとなると話はまた違うんですけどね。)


最近は様々な面でプログラミングのハードルが下がっていますが、
*基礎*の重要性を崩すには至っていません。

少なくともプログラミングを仕事にするのであれば、
学習速度を上げる学習をして然るべきではないでしょうか。

自分の偏りを自覚する

人間、
中庸であれとよく言われます。

盲信すぎてもいけませんし、
疑心すぎてもいけません。

不衛生では健康に悪いですが、
衛生的すぎても免疫が損なわれます。

簡単に言えば、
何事もほどほどにしなさいよって事です。


とは言っても、
完全に中庸であることは不可能なのではないでしょうか。

どうやったところで、
どこかしらに偏りが生じてしまいます。

強い嗜好や強い思想は、
それそのものが偏りと言えます。

かと言って主体性が無ければ良いかというとそうでもなく、
それも偏りの一種と言えます。

この世は偏りだらけというわけです。


そして自分も例外ではありません。

色んな所に偏りがあります。

それを改善するかどうかはともかく、
今回はその偏りのいくつかを自覚してみたいと思います。

自分がどのような方向に偏っているのかを知るのは大事なことです。

その反対側に居る人間を、
少しは甘受できるようになるかもしれません。


とりあえず、
自分の思想についての偏りを考えてみます。


う～ん、
自分はかなり論理的であり、
感情的な判断や行動を嫌っている気がします。

少なくとも、
論理的な事と非論理的なことを曖昧にはしたくありません。

自分が非論理的な思考をしているようであれば、
それを自覚して自身を制御しようと試みます。

いつも自分に言い聞かせている言葉は、
「感情は振りかざすものではない、込めるものだ。」です。
(たぶん原典はない…はず。)


あとはかなり個人主義に偏っているでしょうか。

THE WAVEはすごく身近なものであると捉え、
一致団結の先にあるものをとても警戒しています。

そして個人主義の思想を以って、
自分と他人が違うことを許容するように努めています。

それが多様性につながり、
ひいては寛容さに発展すると信じています。

逆に同じであることを強要しようとする動きには、
どうしても強く反発してしまいます。

「空気を読め」とか「常識で考えろ」とかのような、
日本のハイコンテクスト文化から一歩引いてしまうのです。

平均的な日本人より、
空気や常識に対して相当に懐疑的な立場と言えます。


…おっと、
このあたりを語りだしたらきりがありません。

というわけで、
たまには自分の偏りを自覚してみた次第です。

今度は感覚とか生活でも同じことを考えてみましょうかね？

自分はクッキーを焼き続ける

あ、あと3000兆枚くらいで反物質コンデンサの100個目が買えるんだ…

※エフェクトは全部切っています

え？
バージョンアップでさらなるラスボスが登場？

もうそれは2週目ですな。

ここまで来たら付き合ってやる…！



あ～リアルでもクッキーを焼きたくなってきた。

自分のオーブンで焼くかな～

クッキー用のオーブントレーあったかな～


そんな深夜。

ページビューが20000を超えました

あ、今日統計を見たらとっくに20000を超えていました。

もっと丁度超えた辺りで記事にするつもりで狙っていたのに、
そのこと自体を忘れてしまっていました。

どうにも過去の記事の参照が安定したページビューを確保していて、
地味に増えているようです。

また新しい記事にもそれなりにアクセスが入るようになりました。

もっと対外的な活動を増やして、
「○○の人のブログが気になるから読みに来た」
って人が出現するようになりたいものです。

ああ！？
このクッキーを焼く右手が憎らしい！

ネット活動用の名刺を作成した

今のところ仕事で外へ出ることが滅多にないので、
まだ新しい名刺を持っていなかったりします。

と言っても、
なんだかんだでプライベートの場では渡したい機会がちらほらあります。

ゆるい会社なのでちょうだいと言えば貰えるでしょうが、
せっかくなのでハンドルネームの名刺を作成することにしました。

これからはこの名前での活動も活発になりたいですしね。

作成はVistaprintで行いました。

インターネット上でデザインを決められる点はすごく評価しますが、
他の商品のプッシュのしつこさと退会しにくさがそれを潰してくる…

肝心の名刺は特に品質に問題なかったので、
デメリットと相談して利用してください。

まあこれからその名刺をもらった人は、
生暖かい目で見守ってやってくださいな。

ラストクロニクルオンラインを始めたんだけど…

NPC戦で多少は慣れたのでプレイヤー同士の対戦に入ったら、
初戦の途中からフリーズ…

それ以降ログインできない…あれ？

う〜ん、
Lubuntu + Chromlumはさすがに特殊すぎたでしょうか。

まあこの環境で動かなくてもさすがにクレームは入れられません。

とりあえず数日後にメイン機のWindows7に戻るので、　　
そっちでまた試してみることにしましょう。

追記：
片っ端からキャッシュをクリアしたら、いつの間にか復旧しました。
何回も再現するようならまた記事にしますが、多分レアケースでしょう。

どこからが障害でどこからが才能なんだろう

自分はよくセブンイレブンに寄るのですが、
最近はATARUのキャンペーンをやっていました。

自分は1話を少しだけしか見ただけなのですが、
どうもサヴァン症候群の方のお話みたいです。

しかし不思議な話です。

障害を持つが故に、
常人には持ち得ない能力を発揮できるのですから。

何か今まで使っていた言葉に違和感を感じます。



この違和感の正体を探るために、
障害という定義を自分なりに一般化してみましょう。

うう～ん。

“ほとんどの人が持っている能力を持っていない”

でしょうか。

なら逆に才能という定義を一般化したら、

“ほとんどの人が持っていない能力を持っている”

になるんでしょうか。



…これではまるで、
能力の希少度で言葉を変えているだけに見えます。

結局は正規分布の中央に普通が存在して、
そこから外れた者をそう呼んでいるにすぎないわけです。

普通に振り回されているだけ。

普通から見た“個性”の正体。

なんだか、
何かとてもおぞましいものの鱗片が見えた気がします。

意外な伏兵

自分はBloggerでブログを作成しているわけですが、
自宅のChromeでのみ統計情報が突然表示されなくなる事象が発生しました。

同じパソコンのFirefoxでは動作するので、
ブラウザ固有の何かではあるようです。

ちょっと調べたところ、
大抵はプラグインが悪さをしているようです。

が、入っているプラグインを全部無効にしてもダメ…

もしかして、
拡張機能の方でしょうか？

でも拡張機能なんてほとんど使って…
いや、まさか…

RSS拡張だけ入れているんでした。

でもそれで？

無効にしてみると…うお！動きました！

別のRSS拡張に切り替えて、
トラブルシューティングは完了っと。

しかし、
何が影響するかなんてまったく分からないものです。

それを思い知らされました。

まる

IEが使いこなせない

自分は普段、
FirefoxとChromeのブラウザを二刀流で使っています。

ですが仕事では、
IEのみを使うことになります。

まあ最近のバージョンならタブブラウザになっていますし、
基本操作でそこまで違いはないでしょう。

…そう考えていた時期が、
自分にもありました。

中クリックの挙動がどうにもおかしいのです。

リンクを中クリックで開くと、
しばしば同じリンクのタブが二重に起動してしまいます。

逆にタブを中クリックで閉じようとすると、
またしばしば周囲のタブを巻き込んで閉じてしまいます。

特に検索で似た事例が引っかかる感じも今のところなし…

え？自分の操作に問題があるの？

な、中クリックを使わせてくだしあ…

暑い中熱くて辛いものを食べる

ローソンでゴーゴーカレー監修のカレーが販売されていたので試してみました。

ゴーゴーカレーのイメージで食べると…、
辛い！でも旨い！…って感じでした。

まあさすがにカツの品質には差がありましたけど、
今は通勤ルートにゴーゴーカレーがないので充分ありがたいです。

ただ辛さが結構尾を引くので、
食べた後に休憩する時間が欲しいところです。

最近はどこもクーラーが効いてますし、
たまには汗をかきませんか？

ブログが更新しにくい…

ついにタイピングの音まで注意されてしまいました…

ブログを書くときは特に筆が乗るので、
もう昼休みや仕事終わりに書けない…

いや、集中が必要な作業が全てダメだと言っても良いでしょう。

ストレスで本当に鬱が見えてきたかもしれなくて不安です。

(それで席替えを申請しても、それはそれでギスギスすると思いませんか？)

あ、ちなみにこの記事は外で書いてます。

身体のコマンドキャンセルが難しい

iKnowで英語を学習していることは何度かお話ししましたが、
問題を解いているときによくやらかすミスがあります。

単語入力を行う問題なのですが、
タイポをやらかしてしまったり、
入力文字数が指定されているのに文字数が足りなかったりという感じです。

それだけならただのせっかちさんなのですが、
答えを入力して確定となるエンターキーを押す直前でミスに気がつくのが歯がゆいです。

「(あ、間違っている！？)」

と思った直後ぐらいに、
エンターキーを押してしまっているのです。

反応から行動までのタイムラグ問題だと思われます。

対策としてはゆっくり解くことですが、
さっさと終わらせてニコニコ動画を見たいときは大抵急ぎます。

もうその気持ちが無意識のうちに、
エンターキーを押すまでをコマンド入力してしまっているようです。

そして思考が戻るタイミングは、
英単語を入力し終えてからエンターキーを押すまでの間なのです。

この刹那、
コマンドキャンセルすることができれば…
(いや、実は成功している時があるのに気がついていない可能性も微レ存)

iKnowを始めて一周年

いつの間にやら、
iKnowを始めてから1年が過ぎていました。

とりあえず概要レポートはこちらになります。

学習を完了したアイテムは今日までで961個…

1000個には届かなかったようです。

学習時間は76時間くらいです。

週1時間を超えることを目標にしていたので、
まあこんなものでしょう。



で、これから勉強量を増やすかという話です。

結論から言えば、
まだ増やすのは難しそうです。

今の量でも結構あっぷあっぷしてます。

これ以上増やしたらやらなくなってしまいます。

…でも1年で1000アイテムのペースくらいにはしたいなぁ…

10分増やせば、あるいは？

顔の見分けがつくのだって才能

自分は会ってそんなに経ってない人の顔はほとんど覚えていません。

いえ、結構会っている人でも、
なかなか顔が出てこないことも多いです。

自分の場合はちょっと苦手レベルなので実害は(多分)ないのですが、
覚えのある人はいるんじゃないでしょうか。

インターフェースデザインの心理学によると、
顔の認識は風景などの認識とは別に扱われているそうです。

紡錘状顔領域とか言ったでしょうか。

これにより人の顔の微細な違いにだって気がつけるようです。

ただ自閉症の人は、
この部分の働きが極めて弱いとのことです。

そのため風景などと同じ扱いで処理するのですが、
専用チップを持った一般人に敵うはずがありません。

逆に言えば、
顔の見分けがつくのは(大多数が身に着けているとはいえ)才能なのです。

一度会った人のことは忘れないなんて方は、
この才能が極めて高いのかもしれません。

本当に、
人間は意外なところで先天性な部分がひょっこり顔を出すんですね。

…ジョークではありませんよ？

TDD適当講座

仕事中のお話しです。

周りの声から、
ソースコードが単体テストを行うのに不向きとなっているという言葉が聞こえました。

ただの推測でしかありませんが、
ここでいう単体テストはJUnitのようなライブラリを使ったテストだと思われます。

なるほど、
確かに意識して書かないとテスト可能な実装になんてまずなりません。

ならないからこそテストを先に書く必要性があり、
TDDが生きてくるわけです。

でもまぁ、
先にテストを書けを言われて簡単に書ける人はそうは居ないでしょう。

なのでテストを多少後回しにしても大丈夫な指針でも出してみます。

別に難しいお話しではありません。

JavaならCheckStyleを使って良いスコアを叩き出せば良いだけです。

クラス・メソッドの行数、
引数の数、
入れ子の深さ、
サイクロマチック数、
結合度、
このあたりに閾値を設定しておいて、
警告が出ないようなコーディングを行えばかなり良くなります。

問題があるとすれば、
下手な人はいつまで経っても警告を消せないということです。

テストを前提としたコーディングでは、
今までごまかしてきたコーディングのレベル差が出やすいのです。

それも早い・遅いではなく、
できる・できないレベルに達するほどです。

自分はTDDが必ずしも必要だとは思いませんが、
こういったふるい分けができるという点では大好きです。

まあ管理的には顔面蒼白ものかもしれませんが…

もしも自分のチームでTDDを導入するのであれば、
・元から全員レベルが高い
・TDDを教えるプロフェッショナルが居る
・出来ない人を切り捨てて構わない
のいずれかを満たしてないと辛いのではないでしょうか。



結局何が言いたいかというと、
不相応なレベルで導入しようとすると痛い目をみますよってことです。

レベルが不足しているのであれば、
テストが不能なソースコードが生成されることを甘受するしかありません。

とりあえずTDDは考えず、
CheckStyleを守れるか守れないかで測定してみては？
※JavaではないならSourceMonitorとかでどうぞ。

創造とは何か

よく技術が高いと言われるSEを紹介されることがあるのですが、
確かに技術があるようなのですけど…という感想を抱くことが多いです。

何と言いますか…クリエイターの匂いがしないのです。

クリエイター独特の何か…あぁ、上手く言語化できません。

匂いの正体を探るよりも、
自分にとっての*創造*について考えた方が近道なのかもしれません。

そのヒントになりそうなのが、
何度も紹介したような気がする"スタートアップを殺す18の誤り"です。

今日はその4に着目します。

その中の一文にある、
「解くべき最良の問題は、自分が個人的に抱えている問題であると思える。」
に注目します。

自分にとっては当たり前すぎて気にもならない話なんですけど、
これを感覚的に理解している人があまりに少ないことに驚くことがあります。

何かを生み出すということに対して、
"人類の為に"とか、
"世界を変える"とか、
"常識を塗り替える"とか…

…ああ、面倒くさい！

とにかく、ご大層な大義名分があって生み出されると思っているようなのです。

それはもっとフェーズが随分と進んだ後の話ではないでしょうか。

もっと根源的な要因として、
利己的か利他的かはともかく"自分"が無いのです。

*創造*とは、
「自分が直面した問題に対し、世界を変えることで対応する」ことを指すのです。

逆に創造的ではないということは、
「自分が直面した問題に対し、自分を変えることで対応する」ことになります。

世間は甘くないとか、
こんなんじゃ世の中を渡っていけないとか、
そういう台詞の根源がここだと思っています。

一言で言えば、
*常識*なんじゃないでしょうか。

それは確かに正しいのですけど、
それが全てでは無いのです。

クリエイターであれば、
*創造*によって少しだけ自分の望む方に世界を変化させることができるのですから。

あんまり自分を変える方の選択ばかりしていると、
世界を変化させる方法を忘れてしまうのです。

よって自分は、
*創造*の対義語として*常識*を勝手に持ってきています。

それが自分にとっての、
*創造*の定義です。

だから*創造*ができるクリエイターは*常識*が希薄になりがちであり、
そこにクリエイターとしての匂いを感じるのです。

あ、答えが出た！

補足：
高校や大学の同級生には居るのに、
なぜSIerの人間からは嗅ぎ取れないのか…
きっと自分の創造レベルが低いから、
巡りあう事もできないのでしょう。
精進あるのみです。

Twitterに感謝した瞬間

暇なので連投してみるテスト。

自分のブログなので連投したって文句を言われないのは良いですね。


というわけでさっと本題です。

今までTwitterはOpenIDとかの用途ぐらいでしか使って無かったのですが、
も～れつに感謝しなければならない事態が発生しました。

IOCCCの22回大会の開催に気がつけたからです。

IOCCCをフォローしていてよかった～


今まで情報の更新チェックはRSSでしたが、
RSSで全てをカバーできるわけではありません。

Twitterのツイートを見張っておくのも立派な更新チェックです。

RSSとは対象とする範囲が違うと思っておけばいいでしょうか。


まあ、情報収集手段(早口言葉っぽいな)を複数確保しておくに越したことはないですね。

誰に似てる？と聞かれたら

ついこの間のお話しですが、
アゴに手を当てる仕草がスラムダンクの安西先生にそっくりだと言われました。

そういえば高校の頃に、
「おいおやじ～」と言われながらアゴをたぷたぷされた記憶があります。

そこまで太っているかな～？と当時は思っていましたが、
何気ない仕草が似ていたからなのかもしれません。

これは一般人の定番ネタである、
「誰に似てるって言われたことがある。」
の回答にできるのではないでしょうか。

今までいまいちメジャーなところで似ていると言われたことがないため、
今回の安西先生が一番メジャーなのです。

似ているのが仕草だけなのはちょっと辛いですが、
もうこれで行くことにしましょう。

…って、
忘れた頃に聞かれるのが定番な気がします。

翻訳はどうして大変なのか

自分が英文を読むときは、
単語を日本語に置き換え、
文脈で繋ぎあわせて読むような形を取ります。

これはとても効率が悪く、
数行読むだけでも疲労困憊となってしまいます。

よって日本語版が出ている書籍は大変ありがたい状態です。

今のコストを比較すると、

日本語版の誤差・誤訳に苦労する　＜　英語版を直接読む

なので日本語版を購入するのは合理的と言えます。


でも世の中には、
このコスト差が逆転している日本人だって大勢います。

その人たちが立ち上がれば、
日本語版はもっと充実…とはいかないのではないでしょうか。


ここまで英語のレベルが上がっていると、
日本語に置き換えずに英語のまま読んでいる節があるからです。

考えてみれば当たり前の話です。

日本語に翻訳しない分、
コストが低いだけの話なのです。

ある英会話を学習した人の伝記か何かで、
自分の思考が英語でできるようになって何かが変わったと読んだ記憶があります。
(要出典)

自分はそのレベルに到達していませんが、
この仮説はそこまで間違ってはいないと思います。


なので翻訳を行う際には、
省略できていた英語→日本語の変換に再度立ち向かわなければいけません。

それが大変な作業であることに変わりはなく、
どうしたって重要度の低い記事や書籍の翻訳は行われないわけです。

他の言語の情報を本気で収集したいのであれば、
横着せずにその言語を習得するべきなのでしょう。


結局のところ、
それが一番コストが低く済むのだと思います。

押下の歴史 その2

随分前の前回では、
押下の誕生についてお話ししました。

最近"押下"という言葉に触れてゲシュタルト崩壊を起こしそうになったので、
再度取り上げてみることにした次第です。

とりあえず"押下"の読み方ですけど、
「おうか」が主流のようです。(元々造語なので正しいという表現は避けました。)

そして意味についてですが、
キーボードのボタンを押し込む動作を指す名詞です。

その後キーボードのボタンをすぐに離すか離さないかは、
押下単体では表現できません。

「押下してすぐに離す」とか、
「押下し続ける」とか表現すれば正確ではないでしょうか。

使い方は主にマウスのクリックとの対比として使われているようですが、
1984年説が正しいのであればそこまで深い意味はなさそうです。

まあでも、クリックは"押す"と"離す"がセットの言葉なので、
対比する対象として適切なのは納得です。



ここまでが復習的なお話しで、
ここからが本題となります。

では最近の押下の使われ方を見てみると、
元が造語だけあってブレにブレている印象をうけます。

かなり適当な予測ですが、
以下のような派閥が居るように思えてなりません。

派閥	マウス	キーボード
押下は使わない派	クリックする	押す
押下を使う派	クリックする	押下する
逆転派	押下する	押す
両刀派	押下する	押下する
どれでもいい派	クリックする、押下する	押す、押下する

※マウスの列はマウスを使ってGUIのボタンを押す操作を指していると思ってください。

これらが入り乱れていて、
もうどこからツッコミを入れればいいのか分かりません。

自分が押下を使いたく無いのは、
言葉そのものが悪いからではないのです。

押下を使う人の解釈が玉虫色なのが悪いのです。

…もうこの勢いを止めることはできないのでしょうか？

SQLはチューリング完全なんだけど…

Wikipediaでチューリング完全について調べると、
SQLはチューリング完全ではないという一文が見つかります。

しかしこれは誤記だと言われていて、
SQLでBrainf*ckを実装することで証明した事例を見つけることができます。

ん～、ではなんで間違えたのでしょうか。

当てずっぽうの推理ですけど、
ストアドプロシージャ無しではチューリング完全ではないって話でしょうか。

つまりチューリング完全ではないと書いた人は、
「DMLの範囲ではチューリング完全ではないよね」って言いたかったのではないでしょうか。

先に言っておきますと、
ストアドプロシージャは1996年に標準規格へ盛り込まれているそうです。

よって標準規格ではないというツッコミは(多分)使えません。

なのでDMLの範囲ではと補足すれば正しくなるのでしょうか？

それともDMLの範囲でも再帰的な書き方ができて、
チューリング完全にできるのでしょうか？

どちらにしても修正した方が良いのは確かなんですが、
このあたりの決着は着けておきたい気がします。

ソフトウェアの製造など、一瞬だ！！(誇張)

ソフトウェア設計とは何か？をななめ読みしていたのですが、
自分がいつの間にかSIerに毒されていることに気がつきました。

それはソフトウェアの製造とはどの部分かについてです。

SIer的な見地から言ってしまいますと、
ソースコードを書くコーディング作業は製造にあたります。

そしてよく自分は、
設計と製造は分割できないものであるから分けるなという議論に持っていきます。

でもよく考えてみてください。

分割できないものなのに、
用語では分割して定義している状態は変じゃないでしょうか。

本質的に同じものであるならば、
同じ用語で表現するべきです。

つまりコーディングは本質的に設計なのです。

そして製造とは、
ビルドを実行してからビルドが完了するまでを指すべきなのです。
(インタプリタであれば、毎回製造しているイメージでしょうか。)

これなら明確に設計と製造を分割できます。

実に清々しい、
目からうろこが落ち、
視界が晴れ渡る気分です。

…って、まだ本文をろくに読んでなかったんでした。

では読み進めるとしますかね。

加害妄想の世界へようこそ？

被害妄想という言葉は有名だと思いますが、
加害妄想という言葉もあることを最近知りました。

そして自分の精神を振り返ってみると、
思い当たる事が結構あります。

もしかしたら、
軽い加害妄想を持っているのかもしれません。

(他人が聞いたらドン引きかもしれませんけど)
そこまで致命的な症状でもないので、
ちょっと晒してみようかと思います。

あ、これが加害妄想だっていう確証はありませんよ？

あくまでもそれっぽい事例としてお伝えするだけなので、
「ふ～ん」程度の気持ちでお読みください。



よく発生するのは、
無防備(に見えるよう)な人とすれ違う場合です。

具体的には、
椅子に座って何か考え事をしている時などだと思います。

対象は最低でも顔見知りであることが多いでしょうか。

もうちょっとですれ違うようなタイミングで発生して、
脳内では実際の行動とは違う行動を行う自分の姿が再生されます。

加害の方法は様々ですけど、
すれ違いざまに無理なく行動できる内容に限られます。

思いっきりラリアットしたり、飛び蹴りしたり、
物を持っていたらそれを叩きつけるetc…

映像は実際に行動を起こす直前で止まることが多いですが、
たまに*事*を起こした後の映像も垂れ流されます。

自分で生み出した映像に嫌悪感を覚えていると、
もう現実ではすれ違った後です。

直前に起こった映像に身震いしながらも、
また日常に戻っていきます。



とまあ、加害妄想って言葉を知らなければ狂気と疑う内容です。

自分は狂気持ちなのかなとも思っていましたが、
やはり自分は普通の人間のようです。

そう言えばあまり好きではない人では起こってない気がするので、
その人を傷つけたくないという意識の裏返しなのかもしれません。

ちょっと過激ではありますけどね…



好きな人を傷つけてしまう映像が頭の中で再生されてしまう人がいたら、
どうか不安がらないでください。

それは多分、
あなたがその人を大切に思っている証拠なのですから。

その映像が現実の物とならないよう、
生きていけば良いのだと思いますよ。

(余談：もしその意識がシャドウとして現れるような事になっても、
自分だと認めてあげましょう。)

自我消耗について適当に考える

困ったときはWIREDからネタを引っ張ればいいか…

ということで、
今回は自我消耗について考えてみることにしました。

これより先の文章は、
素人が適当に考えを述べているにすぎません。

こんな考え方もあるのか～程度にお読みください。


まあ自分のイメージを言ってしまえば、
RPGなどでよく登場するMPの概念に近いと思っています。

何らかの決断を行うたびに減っていき、
0に近いときはろくな決断ができなくなってしまい、
寝たりおいしい食べ物を食べると回復するものです。

ここから得られる教訓があるとすれば、
ゲームと同じでMP管理は大事ってことです。


ふ～む、
ではこの自我消耗の最大値には個人差があるのでしょうか？

何らかの精神的成長があれば、
最大値が上昇したりするのでしょうか？

それを確かめるには最大値を測定できれば良いのですけど、
実現は相当難しい気がします。


なぜなら同じ物事での決断あったとしても、
どれだけ自我を消耗するかに個人差が生じてしまうからです。

例えば何度も同じ決断をしていれば慣れが来ます。

最初は全身全霊を掛ける必要があったかもしれませんが、
慣れてしまえば機械的にこなせる作業などは結構ありそうです。

また個人の適正によって、
得意なものなら消費が少ないでしょうし、
苦手なものなら消費は多いことでしょう。

つまりは全てが相対的であり、
客観的に使えそうな絶対値が見当たらないのです。

実用的にある程度数値化するのであれば、
人類の自我消耗の最大値は一律100%としてしまえば良いでしょう。

そしてある行動に対してのその人の消費量を間接的ながらも計測し、
どんな行動や決断で多く消耗するかを調べていくのは有効そうです。

ほとんどの行動に対して消費量が高い人は、
実際に最大値が低いのかもしれません。

しかしその人の得意なものが見つかってないだけかもしれませんし、
経験を積んだ行動は一気に消費量が減って化ける可能性だってあります。

もしかしたら、
誰もが発狂するレベルの事象には踏みとどまれる才能を隠しているかもしれません。

最大値の違いという要素を用意したとこで、
これらについての個性を上手く表現することに成功していません。

実用面に限って言えば、
最大値の差を比べることにあまり意味は無いってことです。


…本当に、
リアルというゲームの分析しているような気分になります。

自分がリアリティ重視のRPGを開発するのであれば、
MPに相当する項目は百分率表記にしてやるとしましょうかね？
(※今暖めているアイデアでは別の項目が百分率のため却下するでしょうけど。)

音が人間に与える影響

Wiredの"超音波を脳にあてて気分を操作"を読みました。

簡単に言ってしまえば、
脳のある場所にある超音波を当てると気分が良くなるというものです。

確かに名曲などを聞けば感情が揺さぶられることはありますが、
これは耳に聞こえない超音波です。

目に全く見えない超音波でここまで劇的な効果が出るなんて、
実はかなり驚くべきことなんじゃないでしょうか。

もしかしたら昔から特別な場所とされていたものの中には、
この超音波のような何かがあったりするかもしれません。
(別に超音波に限らず、目に見えない何かという意味で)


いや、ああなるほど、
携帯電話の電波についての影響が懸念されるのもこういう感じなのかな？

電磁波なら音波よりも脳への影響が強そうですし。

目に見えない*波*によって変わっていく人類…
う～ん、中二病テイストな響きがします。


おっと、話題が逸れました。

あるかもしれない未来に限らず、
今現実にあるものでも既に恐ろしい領域と言えます。

いわゆる音響兵器ってやつです。

研究室の中で完結しているお話ではありません。

こっちはとっくに配備が終わっていて、
使用された実績だってあるのです。

しかもそれなりの効果を上げたという報告付きです。

まあ超音波ではないので、
音は聞こえるそうですけどね。


まだまだ音波ひとつでも色々な可能性が眠っていそうです。

怒りは愛情かもしれないが、それが伝わるとは限らない

特に場所は問いませんが、
誰かが誰かに対して怒っているいるシーンを見たことが無い人はいないと思います。


町中で見かけるようなタイプは、
クレームによる怒りが多いでしょうか。

コンビニでタバコの購入にボタンを押す必要が出てきてから、
それに対してアルバイトの方に怒っているシーンを見かけたことがあります。


オフィスで見かけるパターンは、
何らかの失敗に対して上司や先輩が怒るパターンでしょうか。

怖い上司にビクついたことがさらなる失敗につながり、
さらに怒られるというマッチポンプを見たことがあります。
(この例では上司の方が移動となりました。)


どちらにも共通しているのは、
"何らかの希望や期待を裏切られたことによる失望から発露した感情＝怒り"でしょうか？

強い怒りの背景には強い希望や期待が込められているため、
これらの怒りは愛情表現として見ることができるのだと自分は思います。


まあそれはいいです。

怒りを向けられたことで成長した事例なんてたくさん出るでしょうし、
そこに異論はありません。

問題はその成長の事例の影に隠れた、
マイナスとなった事例はどれだけあるのかという話です。


学生の頃読んだきりなのでちょっと曖昧ですが、
ブラックジャックに紹介したい話がありました。

生徒をやたら厳しく怒り、叱る教師が登場するのですが、
その教師は単に血の気が多いというわけではありません。

その教師はその叱責をバネに一生懸命勉強欲しいという、
いわゆる生徒への*愛情*でそのような態度をわざととっていたのです。

でも生徒の一人が叱責に耐えられなくなってしまい、
自殺を図ろうとしてしまうというお話です。


フィクションの話ではありますが、
これを起こり得ないと言い切れるでしょうか。

自分にはそう思えません。

例え愛情が根源にあったとしても、
それが伝わらない例なんてたくさんあるのではないでしょうか。


このような一方通行の愛情を何と言うか、
私達は"ストーカー"と呼んでいなかったでしょうか。

自分はこれも、
ストーカーの変種だと捉えています。

ストーカー行為を続けていくと、
結果はどうなるでしょうか。

少なくとも、
ハッピーエンドにはならないのではないでしょうか。



まとめます。

怒りは愛情から発露することはあり得ます。

ですがそれでストーカー行為を働くのはやめましょう。

危険な無意識の制御 その3

前回までの話とカクテルパーティー効果の話は最近の記事ですが、
これはリンクしているのではという考えに至りました。

つまりカクテルパーティー効果が薄いことにより、
自分の出している声・音が自分が出しているものだと気がついていないのです。

音を発生させた当事者であるにも関わらず、
当人には雑音のひとつとして処理されてしまいます。

指摘を受けたときは、
自分が出した音に気がついたりしているわけじゃありません。

自分の直前の記憶を引っ張りだして、
音を出しそうな行動をしていなかったか思い返しているだけなのです。

ただそれがどんな音でどれくらいの音量だったのか、
その時の雑音の大きさぐらいしか判断材料がなく困ってしまいます。

そこで雑音が発生しないよう高級レストラン並の行動基準で動くわけですが、
これを長時間行えるような訓練もしてなければ訓練方法も分かりません。

結局静かにできないか、
身体に悪影響を及ぼすことでしょう。

まあ人間の*間*を近づけすぎると、
こうなりやすいってことです。

音は距離の2乗で減衰したはず(うろおぼえ)なので、
ちょっと遠くなるだけでもだいぶ違うんですけどねぇ…

よし、総集編っぽくなりました。

IVRは嫌われ者なのか

かなり古い話題です。

WIRED読者が選んだ「もっとも迷惑なテクノロジー12選」には、
トップバッターとして電話の自動応答システム(IVR)が挙げられています。

日本では大半の自動応答が電話機のボタンで操作しますが、
海外では音声認識が導入されている事が多いようです。

日本語よりもずっと認識率が高いのではと勝手に思っていましたが、
利用者の視点から見た感じでは芳しくないようです。

では電話機のボタンだけなら良いかと言われるとそんなことはなく、
慣れた利用者ほどオペレーターに繋ごうとするなんて事例はよく見かけます。

引きこもり体質の自分としては、
人間を介さずに済むならそれで良いかとついつい思ってしまいます。

ですが世間は逆です。

さっさと柔軟な対応ができる人間と会話を行い、
人間を介したサポートを望んでいるようなのです。
(統計データ上はね)

その邪魔をするIVRは、
"迷惑なテクノロジー"となってしまうわけです。



比較的音声系にいる自分としては何とかならないものかとも思うわけですが、
これに関してはかなり難しいかもしれません。

もしもこの先を目指すのであれば、
より人間的な対応を可能にする必要があります。

でもこの先には"不気味の谷"が待ち構えています。

IVRが迷惑と思われないようにするにはこれを乗り越えればならないでしょう。

…誰が谷を越えようなんて思うでしょうか？

今IVRを売っている企業で、
本気で谷を越えようと思っている企業が居るようには見えません。



もしもこの谷を超えることがあるとすれば、
電話業界とは離れたところからやってくる技術かもしれません。

そのとき、IVRにイノベーションが起こるのでしょう。

その日が来るまで、
IVRは今しばらく嫌われ者であるようです。

試験仕様書からチケットにしてしまった方が楽なのでは

ただいま試験の真っ最中なのですが、
試験項目の分割に頭を悩ませています。

複数人で試験しているのですが、
なかなか綺麗に分割できないのです。

仕方がないので同じ試験仕様書のExcelファイルを複数用意して、
口約束で項目を分担してから最後にマージするような運用を取っています。

さも当たり前のように行われていますが、
これって相当、非効率的な作業ではないでしょうか。



SIerや(担当者にとっての)厳格な品質が求められるソフトウェアの場合、
(ほとんどExcelの)試験仕様書なるものを書いて試験を行うことが普通です。

危うくスルーしかけてしまったのですが、
これも一種の帳票と言えます。

帳票になにかを出力用であって入力用するのはよろしくないと思う自分にとって、
これは改善を考えなければならないポイントに映ります。

つまりは試験仕様書という形に縛られていることが非効率なことであって、
本質的でない部分がたくさんついて回っているのです。


ではどうするのか。

試験を"バグがあるかもしれないから調べておいて欲しい箇所"の束だとすると、
タスクの一種としてバグトラッキングシステムに入れてしまってはどうでしょうか。

手順はこうです。

テキストでもXMLでもJSONでもなんでも良いので、
試験項目の一覧を作成します。

次に作成した試験項目をバグトラッキングシステムにインポートします。

そして通常通り試験を行い、
インポートしたチケットをこなしていくわけです。

新たに追加したい試験項目、
試験で見つかったバグ、
再試験したい項目あれば、
チケットの状態を変化させるなり新規に発行してしまって構いません。

まあただ付け加えるとすれば、
後でエクスポートするのでタグか何かの属性を付与することをオススメします。

試験が完了したら、
エクスポートしてExcelにまとめます。

バグトラッキングシステムのデフォルトの書式が気に入らないなら、
自分でプラグインなりアドオンなり書けばいいんです。

これで帳票を入力に使うという事態は回避され、
より柔軟な試験の対処が行えるようになります。



まあ問題があるとすれば、
バグトラッキングシステムを使っていないような環境では馬に念仏ってことと、
インポートとエクスポートのスクリプトを書くこと自体を許容して貰えるかってことです。

良い案だと思うのですが、
ダメですかねぇ？

簡単になったとしても、素人に任せるべきじゃない

よくソフトウェア開発においては、
「◯◯を使えば素人でも簡単に開発できるようになる。」
なんて文句を聞くことがあります。

実際に使ってみると、
10必要だった手順が3～4くらい省略できたりして、
確かに簡単に開発することができるようになっています。

しかし*素人でも*という部分はどうなんでしょうか。

ユーザーに対して必要な前提知識が減るのは素直に喜べるのですが、
開発者に対しては話が別です。

それは病院に最新の機器が入ったからという理由で、
素人でも簡単に診断ができるようになると言っているようなものです。

医者は医師免許のおかげでそんな事態にはならないのですけど、
プログラマーにはそんなものが無いためホイホイ引っかかってしまいます。

そして素人はその◯◯でスパゲティコードを書いてしまい、
やっぱりダメだったということが繰り返されてしまうわけです。

大抵この手の◯◯は、
用途を限定化させるか抽象化レイヤーを１層作ることによって効率化しています。

しかしそれは、
別に開発者の無能さを隠せるわけではありません。

依然として開発者自身の抽象化技法は要求されています。

ただそれに気がつくまでのタイミングが限定化・抽象化によって遅くなったに過ぎません。

だからちゃんとしたソフトウェア会社は面接時にコードを見るのであり、
それはプログラミングの本質が覆らない限り続くのです。

残業があるかもしれないということ

興味本位でFogCreekの募集要項を覗いてみたのですが、
その中の項目に面白い一文を見つけました。

May involve work after normal business hours, and being on-call

意訳すると、
「残業が出来て、営業時間外の呼びかけに応じられること 」でしょうか。

日本ではあまりに普通すぎてスルーしてしまいそうになりますが、
わざわざ記載が必要だという点が非常に興味深いです。

つまり海外(まあ少なくともニューヨーク)では、
日本と同じ社員の運用をするには要件に載せる必要があるってわけです。

日本の非常識を垣間見えたと思う人も居るかもしれませんし、
よそはよそ、うちはうちと思う人も居るかもしれません。

自分としてはちゃんと記載していることに大変好感が持てるのですが、
皆さんはどのような感想を抱いたでしょうか。

危険な無意識の制御 その2

自分が無意識にやっている行動が、
何やらうるさいらしい。

しかし自分には自覚症状が無いため、
タイミングを見て自制することも難しい。

前回は呼吸量を意識的に半分に落とすことで、
自分が無意識にやっている動作を意識できる領域に戻そうとしました。

しかし慢性的な酸素不足は非常に危険なものなので、
代案を探していました。
(実際にどんどん頭が痛くなってきました。これは本当に危険です。)


要は意識の分配を極力外に出せればいいわけです。

道具を使わずに、
意識を外に向け続ける方法は無いものでしょうか…


そこで新たに考えたのは、
「常に腹筋へ力を入れ続ける」です。

意識が自分の身体に対して向け続けられるので、
自分の身体の制御の大部分を意識下に置くことができるのではないでしょうか。

酸欠よりも、
腹筋が筋肉痛になるほうが幾分ましというものです。


今日それを試しているわけなんですが、
やはり欠点がありました。

呼吸量の制御以上に苦しく、
作業効率そのものが無視できないレベルまで低下しています。

それに加え、
必ずしなければならない呼吸よりも継続に意思が必要になります。

ちょっと気を抜けば力が抜けてしまうので、
精神力の消耗も早いようです。

自分はお腹周りが気になる体型なので、
力を入れている間はベルトに腹が締め付けられるようにしてそれを軽減しています。


それでも辛いですが…


自分のようなタイプの人間は、
人間の"間"に必要な間隔が長めの人間なのかもしれません。

これも個性…なのか…

カクテルパーティー効果の個人差

ある大人数での飲み会での話です。

自分もそこに参加することになったのですが、
乾杯の挨拶から耳を突き抜ける歓声に思わず耳を塞いでしまいました。

その後も各所でものすごいトークの嵐です。

自分も知人に引っ張られて適当なグループの輪に入りましたが、
ほとんど話を聞き取ることができませんでした。

自分が返答を要するものだと感じたときは、
尋ね返して耳をかなりそばに立てて聞かなければなりません。

居ることそのものはそこまで問題ではありませんが、
現状ではこの場で会話を成立させるのは難しいという感想でした。



通常、こういった場ではカクテルパーティー効果が働きます。

無意識のうちに雑多な音の中から必要な音声を聞き分けるのです。

しかしこの効果はどうにも個人差があるようで、
聞き分けがまるでできない人間も中には居るようです。

こういったタイプの人間には、
賑やかな会場は雑音の洪水のように感じられます。

聴覚から意識を逸らして全部カットすることはできても、
話相手との会話の声だけを聞くのは大きな苦痛です。

なぜなら、
その他全部の音声も拾ってしまっているからです。

濁流の中で探しものをしろと言われても、
こちらとしては対処のしようすらないわけです。

対策としてトレーニングしようにもトレーニング方法も不明ですし、
そもそも先天性の問題でどうにもならない可能性もあります。

結論を言うなら、*雑音の中での会話は諦めろ*です。
(処世術として雑談はほとんど聞き流している方もいるそうです。)



結構強烈なハンデキャップに思えるのですが、
認知障害系の記事でそこまで読んだ記憶がありません。
(掲示板のコメントではちらほら)

この件に関してはある程度測定が出来そうな気がしますし、
実験データとか論文とかは無いものでしょうか。

「聴力は問題ないんですけど…」と言うのにはもううんざりなんです。

新しい言葉を使いたがるのは許してやってくれないか

よく新しい言葉を覚えると、
会話の中に積極的に使おうとする方がいます。

まあ何と言いますか、
よほどドヤ顔で無い限りは許してやってくれないでしょうか。

言葉というのは実際に使って身につくところもあるので、
覚えた言葉を身につける為には有効な行為だと思うのです。

その人のトレンドワードということで、
温かい目で見守ってあげてください。(学生は特に)


自分の場合は最近LLVMが熱いので話して回りたいですが、
使いたいのに相手がいなくて困っています。

というわけでこの場で使ってしまうことにしました。


…それだけ。

※LLVMはいつかgccの完全な代替になるんですかねぇ？

抽象化の最終的なボトルネックは人間ではないか

抽象化について考察を重ねるほど、
抽象化技法は人を選ぶということから目を背けなくなる気がします。


これを保守性に置き換えるとよくわからなくなっていきます。

保守性の高い、
つまり正しく抽象化されたソフトウェアであればあるほど、
保守できる人間が限られてしまうのです。

抽象化が嫌われるのはまさにここで、
一番上の方の抽象化は人類の数%しか理解できないと言っても過言ではありません。

保守しやすいのに保守できる人間が限られる…

でも抽象度を下げると、
(言語のせいってわけじゃないですが)COBOLで作られたソフトウェアと同じです。

属技能性ではなく属人性によって構築されてしまい、
遠くない将来に数%どころか直接関わった数人しか分からなくなってしまいます。


問題をさらにややこしくしているのは、
ソフトウェアが完成した当初は抽象度が低い方が内容を理解している人が多いのです。
(管理者や経営者も含めます。)

まだ技術的負債も膨らんでいないので、
改修にも大きな係数はかかりません。

でも時間が経過していくと技術的負債は大きくなります。

そしてソフトウェア開発に関わっていた人物も徐々に離れていきます。

このあたりで抽象度が高いソフトウェアの保守性が理論上は逆転します。

理論上という表現にしたのは、
まだ長い期間運用されている抽象度の高いソフトウェアが少ないからです。

昔は抽象化技法がまだ発達していなかったので、
これが分かるのは最近開発されたソフトウェアの数十年後の結果となります。

まあ少なくとも、
抽象度の低いソフトウェアの結末は最近のニュースを見ればだいたい分かるでしょう。

それが未来の姿ってわけですね。


たぶんプログラマー的には自明のような話なんですけど、
理解した上で取捨選択しているとはとても思えないのはなぜでしょう。

小ネタは読者のハードルを下げるのか

http://blog.livedoor.jp/dankogai/archives/51870361.htmlより、

"～が添削しといてくだしあ。" 

http://blog.livedoor.jp/dankogai/archives/51876805.htmlより

"脱立体機動がもたらす、～"

後者は微妙かもしれませんが、
引用部分は記事の本質から離れた、
いわば小ネタに相当する部分です。

自分も似たようなことは頻繁に書いているのですが、
これは「読者ホイホイ」なんでしょうか、
それとも「読者バイバイ」なんでしょうか、
はたまた特に影響は無いのでしょうか。

実は使っていながらそこら辺が分かっていないのです。

統計が取れるとも思えないので、
とりあえず自分の考えをまとめてよしとしておきましょう。



記事中のこのような小ネタは、
なんというか、
料理の添え物…いやそれよりも扱いの小さい何かです。

ただそれを知る人(というか書いている本人)にとっては、
少しだけ彩りが豊かになります。

砕けた調子になって真面目な内容も肩の力を抜いたように話せますし、
表現の選択肢の増加は何であれ表現の幅を広げます。

だったら日本語をもっと学べと言われればそれまでですが…



う～ん、それとも一種のフィルタリングなんでしょうか。

小ネタ(自分の趣味)に近いかどうかを判別するための。

ネタが分かる人は集まって、
ネタが分からない人は去っていく。

でもそれを期待してる？いやしてない。



結論：よくわからない

危険な無意識の制御

こころのどこかでありうるんじゃないかとは思っていたのかもしれません。

来たるべき日が来たとも言えます。

私の仕事中の声や物音が、
怒鳴られる事態になるという日がです。
(ちなみにその時の指摘は聞き耳ロールに失敗しているので、直前の行動からの推測です。)

基本的に動けば何かにぶつかるタイプなので、
机や椅子にぶつかるのは日常茶飯事。

体調が悪い時は思いっきり呑気症の症状が出るうえ、
体調が悪いとゲップを出していることに気がつけないおまけ付き。

あくびもかなり大きな声を上げるのが標準なので、
注意を向けるのに失敗すると悲惨なことに。


そこで普通に指摘されるだけならそこから注意はできるのですが、
基本的に効果はその日限りです。

発生したら怒られるのであれば、
発生させない方法にするしかありません。

予防するとなるとこれはかなり厳しい手段を取らざるを得なくなります。


この手の症状に悩まされる方の多くは、
「そんな方法があるなら教えてくれ！」
という方じゃないでしょうか。

でもこの方法はオススメできません。

なぜなら*呼吸量を意識的に半分にする*方法だからです。

これは通常の２呼吸のうちを１回を止めるのでも構いませんし、
呼吸のテンポを半分にしても構いませんし、
呼吸量を半分にしても構いません。

とにかく呼吸を半分にして生命活動を下げ、
さらに息苦しさで自分の身体に意識を向けさせます。

これで普段は無意識で操っている身体のコントロールの一部を、
マニュアルで動かすわけです。

問題となる絶対的な酸素の不足は、
呼吸から意識が逸れるタイミングで呼吸が増えることを期待します。

自分の場合には、
多少の作業効率と多大な精神力との引き換えで成功しているようです。

ただ冗談抜きにつらいです。


これは本来ならば伝家の宝刀(つまり使わない手段)にするべきでしょう。

いざとなれば静かに生活できるという手段を持つことで、
精神を安定させる方に使ってもらいたいです。


自分も病院送りになる前に次の手を考えなければ…

設定ファイルとデータベースの境界

ある程度ソフトウェアの規模が大きくなってくると、
設定ファイルだけではなくデータベースを使うようになります。

しかしデータベースのみを使うかと聞かれればそうではなく、
設定ファイルも継続して使われます。

まあデータベースの接続設定を書くために設定ファイルが必要なんですけど、
実際に見てみるとそれ以外も書かれているような気がします。

またデータベースの中身を覗いてみると、
これをデータベースに保持させるのはないわ～というデータも結構あります。

WebフレームワークのDIなんかは設定ファイル一択ですね。

つまりソフトウェアの規模以外にもどちらを選択するかの判断基準があるわけです。

個々に判断することはできるのですが、
その境界は一体どこにあるのでしょうか？

…って思いましたが、
よく考えればデータベースと設定ファイルには決定的な違いがありました。

データベースはデータを挿入したり、更新したり、削除したりするのでした。

それもソフトウェアが起動している最中に、頻繁に。

対して設定ファイルは基本的に起動時に読み込んでそれっきりです。
※キャッシュしないような設計にしない限りはですけど。

ならこう言い換えればいいのかな？

• 設定ファイルはソフトウェアの起動時に使うデータを置いておく。
• データベースはソフトウェアの起動後に使うデータを置いておく。

もちろん例外はあるでしょうけど、
これを基本方針としていいの…かな？

帳票は出力であって入力には不利なのではないか

仕事上、何らかの帳票との連携を行うソフトウェアを見ることがあります。

そのたびにいかにも使いにくそうなGUIに顔をしかめてしまうのですが、
それがどうにも帳票の発想から来ているのではないかと感じるようになりました。

一番顕著だと思うのは、
固定サイズのウインドウにこれでもかとボタンやテキストボックスを詰め込むデザインです。

その見た目は背景色さえ変えればいかにも帳票そのものです。

確かに、
画面の大きさに対しての情報量はこの方が多いと言えます。

しかしそれは読むときの話であって、
何か入力しなければならないときは逆に窮屈に感じます。

例えば可変の件数でデータ入力する必要があったとしたら、
画面枠の都合で3件までしか入力できないなんてことが起こります。

そして4件以降も入力可能にする必要が発生したとき、
画面をぐちゃぐちゃにいじってねじ込まなければいけません。

ここら辺はExcelでも同じでしょうか。

画面の枠ではなくてページの枠に切り替わりはしますけどね。

まあ何が言いたいかといいますと、
帳票はPDFとかあまり編集が効きにくい形式で出力することにして、
その他の部分で帳票を匂わせる設計はあまり行わない方が良いということです。

入力と出力(帳票)は別！
切り離して考えろ！
※帳票の要件が極めてシンプルな場合を除く

構造化プログラミングを購入しました

日本語版は品質をちょっと上げただけで値段が2万近くに達するので、
英語版で良いかとアメリカのAmazonで購入しました。

配送代で数千円飛びましたが、
5000円以下で済みました。

まあ内容はおおよそEWD249なわけですけど、
pdfで読むよりかはやる気もでるでしょう。

それに、3部構成の残り2部がありますしね。

…あれ？これもネットで公開されていたりするのかな？

な、ないよ！きっと！
探してないけどないよ！

 

追記：記事書いた後の10分で見つけたよ…読みたい人はこちらでどうぞ。

http://www.cs.utexas.edu/users/EWD/ewd02xx/EWD249.PDF

http://www.cs.cornell.edu/courses/CS4860/2012fa/Supplemental%20Notes%20lec-26-3.pdf

http://isi.uni-bremen.de/agbkb/lehre/programmiersprachen/artikel/dahl-hoare-hierarchical.pdf

 

クォーターパウンダーゴールドリングのレポ

ネタのひとつとして食べに行ってきました。

まず購入のときなんですが、
渡される際に説明を受けました。

食べるときに使う持ち手用の紙があって、
それを使わないと崩れてしまうかもしれないからご注意くださいとのこと。

なるほど、あれだけの具材を入れたら確かに不安定にもなります。

そして渡されたのは何とも大層な紙袋。

1000円分のうちのどれだけがこの包装に回っているんでしょうね。

でまあ家に帰って食べてみた訳ですけど、
パイナップルはやっぱり人を選びそうですね。

自分は好きでしたけど、
嫌いな人も相当数でそうかな。

値段通りの価値かと言われると…
まあ同じ値段以下で佐世保バーガーに手が届きますからね～

マクドナルドの設備で、
ちゃんとしたグルメバーガーに勝つのは難しいでしょう。

個人的には、
どれだけグルメバーガーに迫れるかの勝負ではないかと思っています。

その辺りを基準にご判断いただければと、
ではでは。

・専用の紙袋

 

・中身の箱、バーガーを持つ用の紙、バーガーのパンフ(!?) 



 

・ゴマがたっぷりのバンズ

 

 

・色々とはみ出している中身



 

今のSIerはファーストフード店のメタファーが一番合う…気がする

この説明は…いける！？

つい最近、今のSIerの現状を説明する機会がありました。

そのときにSIerの組織形態をファーストフード店に例えると、
今まで自分がSIerについて発言したことを見事に説明できました。

これは使えるかもと思い、
文章として整理してみる運びとなった次第です。

オーダーメイド型のファーストフード店

ただ一点だけファーストフード店のメタファーでは馴染まない店があります。

それは提供する商品です。

ファーストフード店ではいくつかのメニューを大量生産して売りさばくわけですが、
SIerではそうもいきません。

現状では全てが一品物のオーダーメイドです。

ハンバーガーに例えるなら、
どのバンズにして、どのパティにして、トマトを入れたりレタスを入れたり、
あ、チーズを挟むのも全て自由に選択できます。

ただ自由に選択できるがゆえに、
お客様が具材に餡やシメサバを指定したらその通りとなってしまいます。

それで幽体離脱する事態になったとしても、
それはお客様が望んだことなのです。

気の効いたアルバイターは注意してくれるかもしれませんが、
お客様がその忠告を聞いてくれることは少ないようです。

その上でオーダーメイドの分料金がかさみます。

まあだから色んな方が文句の一つも言いたくなるんです。

パッケージ型ソフトウェア会社は高級レストラン(でも安い！)

SIerに対して、
メニュー通りに作ったものを大量に売って収益を得るソフトウェア会社も存在します。

よくパッケージ型とか言われていたと思うのですが、
こちらには高級レストランのメタファーを適用します。

実際の高級レストランと違うのは、
逆にオーダーメイド率が下がっていく点です。

そして高級レストランであるにも関わらず、
その値段は手頃です。

ここが面白いところで、
会社の組織形態が高級レストランに近づいていけばいくほど、
販売する商品の形態はむしろファーストフード店に近づいていくのです。

その店に目をつぶれば色々と符号する点が見えてきます。

一度ソフトウェアの品質を向上させると、
その後は(いやそれ以前に買ったお客様も)ずっとその恩恵を受けることができます。

これはソフトウェアには変動費がほとんど無いことが原因です。

真の意味で売れば売るだけ得なのです。

ならばとソフトウェアの品質を向上させて、
大量に売れるように努力するように力が働きます。

その為に、
一流のシェフ(プログラマー)を雇って品質の向上を行うわけです。

評論家が料理(ソフトウェア)の品評をしているので、
買う前からある程度味(品質)が分かるのも特徴でしょうか。

ファーストフード店にシェフはいない(いらない)！

対して、SIerはそうもいきません。

こちらは全てがオーダーメイドなので、
たまたま品質が良いハンバーガーが出来上がっても次がそうとは限りません。

シェフを雇っても毎回レシピを考えさせたら回転が止まってしまいます。

よってアルバイトを大量に雇って、
大した経験が無くてもハンバーガーが作れるように手順を整備します。

シェフはフライパンや鍋や包丁や鉄板やオーブンで様々な料理を作ることが可能ですが、
アルバイトはハンバーガー専用の機器が必要となります。

というかそれしか店には置いてないので、
アルバイトの中にシェフが混じっていても同じ機器を使わざるを得ません。

「料理(プログラミング)の腕を振るえると思ったのに…」

シェフ(プログラマー)は現実を悟り、
SIerから離脱していきます。

それでも難しいオーダーメイドが成立することがあるのは、
シェフの個人的な調理器具を置いておける程度には寛容な店もあるからです。

調理難度が高い注文が来たときは、
手持ちのフライパンと包丁で片付けてしまいます。

ただこれが評価されることは少ないです。

ファーストフード店(SIer)の評価基準は、
店の器具(SIerの手法)を上手く使えたかどうかの評価です。

フライパンや包丁を上手く扱えるようになることは、
始めから評価項目に入っていないのです。

店の機器を使った場合は平均的なのであれば、
きっと平均的な評価となるでしょう。

ここでもシェフ(プログラマー)は現実を悟り、
SIerから離脱していきます。

調理難度が高いオーダーメイドが成功するかどうかは、
運良くシェフが居残っている幸運にかけるしか無いのです。

こんだけ文句言いつつも

でもそれでSIerが潰れることは無いでしょう。

高級レストランはオーダーメイドには消極的なので、
対決する相手は同じSIer同士なのです。

結局値段も質も五十歩百歩、
お客は損をしている実感もないまま購入を続けることでしょう。

どこで買っても*大差ない*んですから。

今までのSIerが潰れる日があるとすれば、
ファーストフード店のメタファーが通用しないSIerが、
世間一般(大口の顧客)に認知されるようになってからでしょう。

InternetDateFormat for RFC3339

Java isn't supported RFC3339.

Because I made InternetDateFormat class.

But it hasn't tested very much.

If you use this class, you need a few test.


FYI:Japanese Edition

2013/07/31: Update detail.
2013/12/16: Bug fix "parseFractionalSeconds".
2017/09/18: Bug fix "parse" (Thanka comment!)

どうでもいいリスク回避

お仕事で朝から現地集合なんてことはまれによくあります。

それが行き慣れた場所なら良いですが、
初めて行く場所は少しだけ厄介です。

迷う可能性もありますし、
集合場所を間違うかもしれません。

かと言って、
あんまり早く来てもしょうがありません。

ならば朝食を現地で食べればリスクを吸収できるのでは？

…あ、当たり前すぎる。

寝ぼけているからこんな記事を書くんでしょう。

まあ寝ぼけているので、
このまま投稿してしまいます。

なぜ抽象化しなければならないのか

とにかく抽象化は大事なんだよJK

プログラマーにとって、
"抽象化技法を身につけた方が良い"というのは自明の話です。

構造化プログラミングしかり、
オブジェクト指向プログラミングしかり、
◯◯(好きな用語を入れよう)プログラミングしかりです。

あまりにも自明すぎて、
この事実の重要性を伝える段階になって困ってしまいます。

重要とだけ叫んでも理解されないのはこれまた自明なのですが、
でも実例を紹介してもやっぱり理解されない気がします。

自分の経験と照らしあわせて実例を噛み砕いて理解しようとするでしょうけど、
理解していなければ自分の経験に適用させることができません。

つまり「自分は使うことはないだろう」という結論に陥ってしまい、
それ以上の学習が止まってしまうのです。

結局、今まで抽象化技法を身につけることができた人達は、
学習の情熱が冷める前に理解できたのだと思います。

n分間待ってやる

今回のお話は、
その情熱が冷めるまでの時間を伸ばすための説明です。

少しでも良いので、
「理解できれば今までよりも少しは良くなるかもしれない」と思わせるのです。

そうして学習を続けてさえもらえれば、
より多くの人が新しい抽象化技法に目覚めてくれる…かもしれません。

抽象化すると何を"ゲットだぜ"できるか

ぶっちゃけた話をしてしまいますと、
レベルの高い抽象化技法を身につけていればこんなことができるようになります。

• 大きなソフトウェアが開発できる
• 中～大くらいのソフトウェアの開発速度が向上する
• 小～大くらいのソフトウェアの保守性が向上する

大きなソフトウェアになると、
もう開発できるかできないかに関わってきます。

色んなブログで、
「優秀なプログラマー少数でやればあのプロジェクトは成功したかもしれないのに…」
的な記事が読めるとおもいます。

これは赤字とかではなくて、
何かの事情でプロジェクト自体が破綻したパターンです。

プロジェクトチームは足並みを揃えるために、
一番レベルの低い人に合わせる傾向があります。

つまり抽象化技法が最低のものしか採用できず、
チーム編成の時点で詰んでいることも珍しくないわけです。


プロジェクトの破綻とまでいかないにしても、
赤字だったプロジェクトが黒字になる可能性は大幅に上がるでしょう。

同じ期間を少数の人数で完成させてしまうことができますから。

つまり一時的とはいえ、
レベルの低いプログラマーを使うこと自体が損失と言えます。

…あ、しまった。

少人数だとしてもプロジェクトの値段が変わらないことが前提です。

これは人月計算の見積もりによる矛盾の話なのでスルーするとしましょう。


そしてソフトウェアは完成した後の方が大変です。

使っているうちにバグが見つかるかもしれませんし、
機能を追加したり差し替えたりしたくなるかもしれません。

その時に適切な抽象化を行ったソフトウェアは簡単に対処することができます。

ちょっとした修正でもえらく時間がかかるソフトウェアがあれば、
それはレベルの低い抽象化しか行なっていないわけです。

利点は認めるけど、自分のプロジェクトには関係ないから…

と説明して分かってもらえれば、
世の中のプロジェクトはもっと成功していることでしょう。

抽象化技法を理解していなければ現行との比較ができないからです。

評価できない、よく分からないものをプッシュされても詐欺師と思われるだけでしょう。

なのでもう一歩引いてみることにします。

「抽象化技法を学ばないなんてありえない！」

ではなく

「抽象化技法を学ぶ価値はあるんじゃないかなぁ？」

くらいを目標に据えて考えなおしてみましょう。

それくらいなら話を聞いてもらえるかもしれませんから。

複雑度が違うのだよ！複雑度が！

目標を決めたところで、
抽象化技法の利点についてもう少し深く掘り下げてみましょう。

そもそも抽象化技法を実施することで、
なぜ様々な利点が生じるのでしょうか。

それは抽象化技法がなぜ生まれたかを知れば簡単です。

抽象化技法は、
ソフトウェアの複雑さに対処するために生み出されたのです。

つまり抽象化技法がもたらす利点とは、
ソフトウェアの複雑さを軽減することによって生じているのです。

ちょっとイメージを表にしてみました。

横軸がソフトウェアの開発規模です。

対数表記なので、
目盛の上昇幅は1、10、100、1000、10000…みたいな増え方をしています。

といってもイメージなので、
具体的な数値は表記されていません。

縦軸はそれに対するソフトウェアの複雑度です。

こちらも対数表記です。

仮に表の上限を突き抜けたら、
保守不能レベルということにしておきましょう。

各色の線は、
採用した抽象化技法の違いを表現しています。

濃いオレンジ色の線は、
ろくに抽象化技法を使っていない状態です。

ループすら使わず、
もうただひたすらに保守不能に向けて一直線です。

構造化プログラミングを採用したあたりが、
薄いオレンジ色の方でしょうか。

ループや関数を記述しなければならない分、
ちょっぴり初期コストが掛かっています。

でもすぐに交点を迎え、
あっという間に構造化プログラミングを採用した方がよくなります。

まあどれだけ使いこなせるかでこの線は簡単に上下してしまうのですが、
それなりに使いこなせていると思ってください。

次の黄色は…オブジェクト指向プログラミングにでもしましょうか。
※実際には構造化プログラミング＋オブジェクト指向プログラミングかな。

クラスを作ったりしなければならないので、
初期コストは構造化プログラミングのみより大きくなります。

でもやっぱりすぐに追いぬいて、
オブジェクト指向プログラミングを採用した方がよくなります。

次は…何だか面倒くさくなってきましたが、
緑色はデザインパターンを使いこなしているあたりにでもしましょうか。

さらにさらにぃ！
初期コストはかさみますけどやっぱりすぐに追い抜きます。

たださすがに初期コストが無視できなくなってきました。

状況を見ての取捨選択も必要になってくるあたりでしょうか。

エメラルドグリーンは…
もう何でもいいですがさらなる抽象化技法です。

初期コストはもっともっとかかるでしょうけど、
やっぱりどこかで逆転します。

ものすごーく大きなソフトウェアが開発できるようになりますが、
初期コストも大き～いので、
価値を見出す人も価値を見出す場所もごくわずかかもしれません。

複雑度の交点を探せ！

この話で重要なポイントは、
抽象化技法を選択したことによる複雑度の変化、及びその交点です。

抽象化技法は、
上位のものほど記述的な意味で初期コストが発生します。

その面倒さが報われるのは、
ある程度の大きさのソフトウェアを開発したときになります。

これが一種の初心者殺しで、
例えばオブジェクト指向プログラミングの利点を説明しようにも、
その利点が体感できる規模は参考書のサンプルにするには大きすぎてしまうのです。

そしてもう一つ、
抽象化技法を会得するまで、
複雑度の交点がどこにあるのかは分からないのです。

今までの記述よりも量が増えるにも関わらず、
サンプルで利点も分からず、
目標もよく見えない、
なのでごく短期間に理解できる人間でないと諦めてしまうことが多い。
※もしくは直感的に利点があることまでは理解できるか、かな。

それが抽象化技法の特徴なのではないでしょうか。

結局何が言いたいわけ？

会得しないと利点が分からない性質のものだから、
有名な抽象化技法くらいは頑張ってみたら？

少なくとも、
複雑度の交点が見えるようなるまでは。

え、何が言いたいか分からない？

自分も分からないんです…

CalcがExcelより優れている点を見つけた

表題がすごい煽った表現ですが、
実際は大した事はありません。



自分用の勤務表入力シートでも作ろうかとしていた時のことです。

出勤と退勤の時間は毎回入力するとしても、
休憩時間をどうするかについて困っていました。

ほとんどの日は固定値と変わらないのに、
たまに入力が必要となってしまうタイプのデータなのです。

しかも休憩時間は、
数値1個の入力では済まないのです。

深夜に休憩したとした場合、
深夜労働の時間から控除する必要が発生します。

深夜だけならまだいいんです。

休憩は複数回あるわけですから、
通常の休憩と深夜の休憩が混在してしまうことが普通なのです。

これをわざわざ入力者に計算させますか？

いえ、自分ならさせません。

いつからいつまで休憩したかだけ入力すれば、
後は勝手に計算してくれるのが理想です。

だって*表計算*ですし。

ということで、
休憩時間は最大3回分の開始時刻と終了時刻を入力できる設計にしました。

ただそうすると、
休憩時間の入力のためだけに6行奪われることになります。

普段は出勤と退勤の2行しか使わないのに、
滅多に使わない機能へ6行使うのは犯罪的です。

ならばとグループ化を使って普段は隠してしまうことにしました。

これで必要なときだけ休憩時間の入力欄を表示させることができます。

後はシートの保護をして計算しているセルを守ってやれば…あぁ！！

シートの保護をしているとグループ化の操作が引っかかる！

しかも突破するにはマクロを使わないといけないらしいです。

せっかく非マクロでここまで来たのに、
グループ化とシートの保護の両立のためだけにマクロを使うことはやりたくありません。

うう～ん、
休憩時間の入力のときだけシートの保護を外させる？

いやいや、
それならシートの保護をしない方がましでしょう。

なら、なら…



これがExcelの限界だっていうのなら、
Calcはその限界を超えてやる！

ってことがあるのではないかと思い、
LibreOfficeのCalcで同じことを試してみました。

…できてしまいました。

同じことをやりたかったら、
ExcelよりCalcを使った方がよさそうです。

以上、終わり！

何が学者に似ていて、何が画家に似ているのか

プログラマー談義をしていたときのことです。

プログラマーは学者の性質と画家の性質を持っているという話題が出ました。

そのときは「うんうん、そうですね」で済ませてしまいましたが、
具体的にはどのあたりが当てはまるのでしょうか？

まあ挙げればたくさんあるでしょうけど、
一番大きそうなのをそれぞれひとつずつ挙げてみることにします。



まずは学者です。

これは"言葉を厳密に定義している"が一番大きいと思っています。

さすがに概念的な用語に関しては意見が割れたままだったりしますが、
一度決まった用語に関してはかなり厳しいです。

一般の方の知識であれをやりたいこれをやりたいと言われると、
その理解の食い違いでひどい目に合うことが多々あります。

実際はADSLでインターネットに接続したいという要望なのに、
「LANを構築したい」なんて説明された例があるとか。
(まあこれはネットワーク話ですが、プログラマーなら特に苦戦しないですしおすし。)

プログラマーはチューリング機械とお話する関係上、
学者並の言葉の厳密さが発生してしまいがちです。

日常レベルに食い込んでいる学者、
それがプログラマーなのかもしれません。

やっぱり、*ソフトウェア工学*だってことです。



では画家はどうでしょう。

こっちは思いあたる節が多すぎて絞りにくいのですが、
あえて挙げるなら"作り上げたものに美を見出す"でしょうか。

これは別に画家に限ったことではないですけど、
画家というメタファーを使うときはクリエイター全般としての扱いが多かったもので。

…経営者と対峙しやすい部分とも言えるかもしれません。

ソースコードの美しさを理解するには相当の技量を要求します。

そして、美しさの価値は美しさが分かるものにしか意味がないのです。

画家に対して美しさはどうでも良いから大量生産しろと言う人は少なそうですが、
プログラマーに対しては美しさはどうでも良いから大量生産しろと言う人はたくさんいます。

画家に言うそれと同じくらいの侮辱の言葉なんですがねぇ。

もしそれが鬱陶しいを思うのであれば、
ソースコードに美を見出すプログラマーを全員クビにしてみてください。

プロジェクトが技術面で炎上するのが確定すると思いますけどね。

プログラマーのレベルが高いということは、
それだけソースコードに美を見出していることと等価なんじゃないでしょうか。

このあたりのお話は、
「ビューティフルコード」でも読んで、どうぞ。



…書けば書くほど理解してもらえなさそうな現実に絶望してしまいそうです。

ピザトースト

ひさびさに料理ネタで記事を書いてみました。

今回はスタンダードなピザトーストです。

具はベーコンに玉ねぎにピーマン…
ちょっと寂しいでしょうか？

それなりにこだわったのはピザソースです。

一応手作りのソースで、
ケチャップをベースにウスターソースやコショウ、
それに少しだけガラムマサラを加えています。

お好みで隠し味に醤油を加えると香ばしさが増すかも…と思いました。

簡単な料理ですし、
各家庭の微妙な違いを楽しむのもおもしろそうです。

さあみなさんも、いざぁ！

管理者が管理するほど生産性が下がる

Excel方眼紙で作られた各種文書(!?)を眺めてみると、
なんでこんな些細なことまで管理したがるのか疑問に思えてきます。

文書からは相当な神経質さが伺えるのに、
これらの資料を入力する時間については無頓着という不思議。

ただ自分が管理している気分を味わいたいがために、
何十、何百、何千万の金額をドブに捨てているようにさえ思えます。

彼らは何を管理したいんでしょうか？



まずソフトウェア開発における管理者の役割は、
*生産性の最大化*に尽きるのではないでしょうか。

そして管理者は、
生産性を向上させるのに必要な環境を整え、
生産性を低下させる要因を排除することが求められます。

ピープルウェアなんかを読めば出てくる話だったかな？

それを忘れて必要以上に管理者が干渉を行うと、
生産性の低下を招きかねません。

生産性が最大化する管理の度合いを考えるのも、
管理者の仕事ではないでしょうか。

多重派遣を無くす方法を考えてみた

ちょっと前の仕事の話ですが、
開発体制がお客様から自分の会社に到達するまで長いこと長いこと。

もう何段階あったのかすら覚えられませんでした。

途中が破線で省略されていましたし。

そして案の定、
お客様に対して顔を合わせることがあれば、
その中のどれかの社名を使わなければなりません。

嘘を極力避けたい自分としては、
これが一番の苦痛です。

これって詐称かなにかで罪にならないんでしょうか？



いや、罪にするべきという方が正確なのかもしれません。

派遣であったとしても、
自分の所属している派遣会社を名乗らなければいけないことにしてしまうのです。

こうすることで、
どれだけの人員が間接的な雇われ方をしているのか実感させることができます。

多重派遣は色々と問題が指摘されていますが、
一番の問題は政府から依頼された仕事でも堂々と行われる事です。

そんな人達に現実を教える方法として、
社名を偽らないというのは有効ではないでしょうか。

…抜け道探される方が早いかな？

おまじないとカーゴカルトプログラミング

よく初心者へプログラミングを教えるときは、
"おまじない"として決まり事のように教えることがあります。

"おまじない"として"#include <stdio.h>"をタイプしろと、
一体どれだけの人が説明したことでしょう。



一方で、
"カーゴカルトプログラミング"というアンチパターンが存在します。

これを簡単に言ってしまえば、
意味も分からず"おまじない"を盲目的に使っていると、
関係ない部分や余計な部分に記述してしまって問題となることを指します。

言っている意味としては、
"おまじない"≒"カードカルトプログラミング"でだいたい合っています。



つまりプログラミング初心者に対して、
私たちは最初からアンチパターンを教えていたことになるのです。

しかし"おまじない"を避けて説明しようとするなら、
初心者は誰もついてこれないことでしょう。

最初に習ったことは無意識に引っ張られやすいものですし、
できることなら間違ったことを教える内容から極力除外したいものです。

本当にプログラミングを上達して貰いたいのであれば、
この"おまじない"は避けるべきではないでしょうか。



さいわいなことに、
最近のプログラミング言語は"おまじない"が昔よりずっと少なくなりました。

アンチパターンを教えないという方針に則るのであれば、
Rubyなんかを使って教えた方が良いでしょう。

まあ"簡単過ぎる"という欠点もあるのですが、
アンチパターンを踏むよりかはマシだと判断しました。

もし本物のプログラマーを求めるのであれば、
SICPでふるい分けでもすれば良いのですから。

見えなくても、百聞は一見にしかず

よく、分かりやすく説明できない方が悪いという風潮があります。

(被害妄想ですけど)特にプログラマーが技術について話すときは顕著で、
難しい事を長々と話されても訳が分からないと言われます。



まあその指摘は一理あります。

プログラマーという人種そのものが説明ベタの傾向がある気がしないでもありません。
(というより、学者全般かもしれませんけどね。)

簡単なものなら図式を使えば何とかなるかもしれませんが、
抽象化のレイヤーが上の方になると図解ですらややこしくなります。

「百聞は一見にしかず」とは言いますが、
ソフトウェア工学はその一見を見せる方法を見出していないようです。



でもプログラマーには、
確かに見せられなくても見えているものが確かにあるのです。

それは*境地*なのかもしれません。

私達にはプログラミングの境地が見えているのです。

お金でかいけつすることはできない。

コンコルドを使っても見つけることはできない。

誰かに頼み込んでも連れて行ってくれることはない。

手助けすることはできても、
最後には自分の力で到達することでしか行くことはできない。

そんな昔話に出てくるような、
幻想の土地が見えているのです。



ソフトウェア会社の社長が元プログラマーであった方が良い理由はここにあります。

どれだけ言葉を並べても、
どれだけ図解を並べても、
その*境地*は決して見せられるものではないからです。

しかしその差は、
開発するソフトウェアへ確かに反映されるのです。



どれだけ言葉や図を並べても伝えられない物、
見えなくても百聞は一見にしかずな物、
そのひとつが*境地*なのではないでしょうか。

USBテザリングを試してみた

ポケットWiFiを使うほどではないにしろ、
外でネットに接続したいことはよくある話です。

最近はノートパソコンを持ち歩く機会が増えてきたのでなおさらです。



そこでUSBテザリングとしてPdaNetを試してみることにしました。
※標準機能？そりゃあんた(ry

インストールさえ突破すれば、
使う事自体はそこまで難しくありません。

Android側で有効→ノートパソコン側で有効にするって感じかな？

インストールそのものも、
翻訳をサボらなければ簡単な操作であることが分かります。



後は3Gの速度の勝負です。

この投稿はPdaNet経由なのですが、
ちゃんと電波環境が良いところであれば実用に耐えてくれるようです。

まあブログの投稿だけであれば、
外付けのキーボードを挿した方が良いとは思いますけどね。

Webサイトの閲覧については、
少なくとも/.Jは実用に耐える速度に見えました。



あとこの方式の最大の利点は、
Androidのバッテリーを心配しなくても良いことです。

常に充電状態にあるので、
ノートパソコン側のバッテリーのみを気にすれば大丈夫…なはずです。



別にPdaNetである必要はありませんが、
月額支払うほどじゃ無いけど外で使いたいときもある人にはオススメです。

同じような境遇の方は、
まあチャレンジしてみればいいんじゃないでしょうか。

半世紀前より稚拙なセキュリティ

もうすぐ今やっているプロジェクトが終了するのですが、
このプロジェクトにはひとつ面白い点が存在しました。

それはプロジェクトの名前がまったく関係の無い単語で、
いわゆるコードネームになっていたところです。

まあ全く使われていなかったんですけど、
もっと流行って使われるようになって欲しいとは思います。



その理由をお話しする前に、
皆さんは"大脱走"という映画をご存知でしょうか。

捕虜収容所からトンネルを掘って脱出を図るお話しなのですが、
トンネルに人物の名前でコードネームを付けていたのです。

人物名なので、
怪しまれることなく堂々と話すことができます。

これにより秘密を保ちながらも、
円滑に作戦について話し合うことができたのです。



これと同じことを、
現代でも応用することができるわけです。

プロジェクト名を全く関係のない名前にしてそれを共通認識にすれば、
いちいちX社の案件などと気をつけて話すよりずっと効果的です。

今回のプロジェクトは外で話す機会が無かったので効果が薄かったですが、
おおよそのプロジェクトでは役に立ってくれるでしょう。

いつも何で実施しないのかと不思議に思っている次第です。



セキュリティは人間側の対策も重要なんて言われていますが、
だったら精神論だけではなくこうした具体的な対策を立てて欲しいものです。

人間側の対策は半世紀前より退化しているなんて、
そんなの絶対おかしいよ！

間違い探しはやる気だけでは難しい

よくバラエティ番組とかで、
"間違い探し"クイズがあったりします。

大抵は比較的早いグループとそこそこのグループ、
そして、
結局答えを見るまで気が付かないグループに別れます。

毎回必ず同じ結果になるわけではないですが、
同じ人が同じグループに属する確率は相当高いように感じられます。

気が付かないグループの人達は血眼になって間違いを探すのですが、
やっぱり見つけられるのは稀な事のようです。

バラエティ番組を視聴している人であれば、
だいたいの方は同じ感想だと思います。



一方で、
仕事で資料の校正を行ったときのことです。

もう10回は見直しをしたのですが、
それでも他の方の平均と比べるとボロボロと誤字・脱字が発見されました。

そのとき呆れ顔をされながらこう言われたのです。

「やる気があるの？」と。



その人がバラエティ番組をよく見ているのかは知りませんが、
どちらも"間違い探し"という点では酷似しています。

"間違い探し"にはやる気では覆しにくい個人差があることを、
何とか理解していただけないものなのでしょうか。



まあ"間違い探し"に限らず、
人間の個人差は普段思っているよりも遥かにばらつきがあります。

自分にはできて他の人ができないからと言って、
それをやる気のせいにしていませんか？

それは個人差であるかもしれませんよ。

Japanese Bloggers Infoに登録しました

トラックバックが無いことのディスアドバンテージが想定より大きいのではないかと思い、
Japanese Bloggers Infoに登録してトラックバックを利用してみることにしました。

クリボウさんの記事にはBlogger関連で大変お世話になっており、
もはや足を向けて眠ることはできません。(方角はわかりませんけど)

しばらくはテンプレートがちょこちょこ変わるかと思いますが、
登録直後のごたごただと思ってください。

別に人気ブロガーになるつもりはありませんけど、
相手に伝えず一方的に記事にするよりかは行儀よく…と言えるのかな？

まずは様子を見てみることにしましょう。

詐欺の定義(再考)

以前に詐欺の定義について考えたのですが、
まるで駄目だったのでもう一度考えてみました。

以前は、

「情報の不平等を利用した取引」

と定義しました。

ですが全然ダメです。

例えば料亭の秘伝の味なんかは顧客が知らない情報と言えますが、
そこに文句を言う人はいるでしょうか。

職人の真似できない匠の技なんかも、
暗黙知の情報と言えるかもしれません。

もちろんこれらは詐欺ではありません。

詐欺は情報の非対称性から来るという仮定はそこまで外れてないのですが、
それだけだと詐欺ではない取引まで含んでしまうので修正が必要です。



顧客が不利益を被ったら？

う～む、価値なんて視点によっていくらでも変わるから難しそうです。

顧客満足度？

ならクレーマーを相手にしたら全ての店が詐欺になってしまいます。

いえ、考え方を変えましょう。

情報の非対称性がどこに発生すれば詐欺になるのか？

商品の欠陥を伝えてないのは詐欺くさいですが、
企業機密の仕組みを使った性能向上なんかは詐欺ではない…

そう嘘を付かなくても致命的な問題を隠していれば詐欺と同じ。
だから嘘では詐欺の範囲をカバーしきれない。

ん、もしかして…

「商品(サービス)の価値に対して情報の非対称性がある取引」

ということでしょうか。

どうやって高品質の商品を提供できるのかについてなら、
情報の非対称性は問題となりません。

でも商品の価値で隠し事や嘘があるのであれば、
それは詐欺だと糾弾されるのではないでしょうか。



おもしろいのは、
これは物によっては売り手ではなく買い手が詐欺師になる可能性もあることです。

オーダーメイドなんかがまさにそれです。

値段を決めてから顧客が必要な情報を後出ししてねじこむなんて、
まさにそれではないですか？

確かに顧客にとっても後から判明した情報なのかもしれませんが、
それならば値段を変更しなければ適正な契約とは言えません。



なるほど、
既に出来上がっている商品を取引するのと、
まだ出来上がってない商品を取引するのとでは、
詐欺の形も変わってくるのかもしれません。

あれ？

これって経営者の間では常識だったり？

SIerが技術力を求めない理由

今イノベーションのジレンマを読んでいるのですが、
その中に興味深い一文を発見しました。

特徴と機能が市場の需要を超えてしまうと、その違いは意味を失う。

これは実体験でもよくある話です。

一人暮らしを始めた頃に電子レンジを買ったのですが、
申し訳程度にオーブン機能がついたかなり安いものを買いました。

自分に取って余分な油をカットできたり、
カロリーを測定できたりする機能までは必要無かったのです。

最低ラインさえキープしていれば、
後は値段しか見るところはありません。



これをSIer所属のプログラマーで例えてみるわけです。

ここでいう特徴や機能を、
プログラマーの技術力に置き換えて考えてみてください。

最低ラインの技術力さえキープしていれば、
後は値段しか見るところはありません。

…と言い換えられませんか？

つまり一定以上の技術力は市場の需要を超えていて、
その価値は一切見向きもされなくなってしまうわけです。

だから他の需要であるコミュニケーション能力などが推奨されてしまうわけです。

市場的にはその方が価値があるわけですから。



しかし電子レンジと大きくことなる点は、
顧客は自分の要望を電子レンジほどに明確化していないことです。

要望(≒需要)が明確化していないなら、
要求されるプログラマーの技術力も明確化していないはずなのです。

これは顧客かSIerが市場の需要を過小評価しているのではないでしょうか。

もしくは両方なのかもしれません。

SIerという市場に技術力という価値を認めさせるには、
この認識を改めてもらう必要があるのだと思います。



そしてこれは技術力だけで解決できる話ではなくて、
多分に経済のお話が絡んできます。

経済の知識とは負の相関がありそうなプログラマーには、
少々辛い話のように思えます。

餅は餅屋、
経済や市場の話は経営者が解決すべきスコープではないでしょうか。

値段だけの競争が不毛なことは何よりもご存知のはずです。

値段以外の価値があることを、
市場に認知してもらうように働きかけてもらえないでしょうか。



もしそこまでプログラマーに任せてしまった場合、
経営者は何の為に存在しているのでしょうか？

SEにも種類がある

自分はよくSE(笑)と言っていますが、
(笑)が付かない場合があるのをすっかり忘れていました。

略さずに表記しますと、

「システムエンジニア(笑)」

「ソフトウェアエンジニア」

と(笑)が付かないSEがあるのです。


まあ後者の意味でSEと呼ばれるなら良いかと聞かれると、
自分はやっぱり「プログラマー」と呼ばれたいです。

単純に「ソフトウェアエンジニア」の定義をよく分かってないだけなんですけどね。


はぁ…なんで設計と実装を分けられると勘違いしてしまったんでしょう。

一旦分けてしまうと、分けられるほど簡単なことしかできなくなってしまうというのに。

あ、人月が余計にかかって保守性も落ちるからSIerは利益がでるのか…

気が重くなる…

YAGNIと拡張性の原則

YAGNIでは、
必要になるまで新しい機能は追加しないとあります。

つまり今必要なものだけを実装しろということです。



UNIX哲学の拡張性の原則では、
拡張性に備えた実装をするべきだとあります。

つまり未来を見据えて実装しろということです。



このふたつは時勢においては矛盾しているように見えますが、
その内容はまったく相対するものではありません。

このふたつのお話しをつなぎ合わせると、
「今必要な機能だけを実装しよう、でも後に拡張するときの準備だけはしておこう。」
という感じでしょうか。

よくこの拡張性を機能と捉えられることがあるのですが、
並のプログラマーなら拡張性は常にある程度考慮しながら実装しています。

拡張性を用意するのに時間がかかると思っている人は、
経験が無いか実力の低いのではと疑ってしまいます。

よほど抽象化のレベルを上げない限りは、
拡張性は実装と同時進行で実現されるべきものなのでYAGNIに引っかからないのです。



むしろここで過剰に反応する人たちは、
意味もなく拡張性を狭める設計をするような気がします。

log4jのロガー名は階層構造が取れるのに、
階層構造ではないロガー設計をして後で泣いていたSEを見たことがあります。

SIerは上流だとか下流だとか言っていますが、
こういうことを考えて実装するには邪魔な区切りではないでしょうか。



まとめます。

YAGNIとUNIX哲学の拡張性の原則は同居できます。

しかし技術力が低かったり、
設計者と実装者が分けられているとその恩恵を享受することは難しいです。

少しでも同居した実装ができる範囲を広げられるように、
もっともっと努力していかなければなりません。

統計でﾆﾔﾆﾔ(・∀・)パート11

久しぶりにブログのアクセス統計ネタをひとつ見つけました。

参照元のURLを見てみると、
googleの画像検索でひっかかった例があったのです。

ひっかかった画像のある記事はこちらなのですけど、
よりにもよってこのチラシの裏に描いたような落書きを…

画像の数で言えば料理の写真がダントツのトップなはずなのですが、
他にも載せている人があまりに多くて引っかからないということなんだと思います。

別にオリジナリティあふれるすごい料理ってわけでもないですし。

よし、これからはもっと料理を…ってそれよりも部屋の掃除がもっと大事です。

インストールでも導入でもなければ

「アプリを『取る』」って何？を読んで、
確かに『取る』って言う表現は何かがおかしいということに気がつきました。



何がおかしいのでしょう？

この場合『取る』という意味は、

　『取る』　＝　『ダウンロード』　＋　『インストール』

として使われています。

どうにも意味が『ダウンロード』の方に引っ張られていて、
『インストール』がおざなりになっているように感じます。



う～ん、では『入れる』なんてどうでしょう？

これで『インストール』の方は…と思ったら『ダウンロード』の意味が薄いですね。

どっちの意味も連想させるような言い回しにした方がよさそうです。



…

……

………

なら『詰める』なら！

アプリケーションに手を伸ばし(ダウンロード)、

袋に入れる(インストール)するようなイメージです。

袋(容量)がいっぱいになったらもう入らない点でも一致します。

おろ？

何か余計遠ざかったような…

抽象化は現代の魔術と言えたり言えなかったり

どこまで抽象化して物事を考えられるかという点において、
人間には相当な個人差があるということが経験則的に分かっています。

単純に言ってしまえば、
できる人とできない人が居るということです。

プログラミングの技法としてこれだけ体系化されてもなお、
できない人にはできないというのは違和感を覚えます。

高校くらいまでの理数教科で、
多少なりとも先天性を求められるものがあったでしょうか。

実際はどうなのかはともかく、
地力と学習量次第で習得可能だと思われているんじゃないでしょうか。

言い方を変えると、
学習の*再現性*が薄いのです。

科学の領域ではないのです。

学んでできるようになるとは限らないのです。

しかも、経験則では先天性であることが疑われています。



これではまるでファンタジーに登場する魔術です。

魔術理論という体系化された学問がありながら、
それを修めることができるかに才能が絡んでくるのです。

“ウィザード級のハッカー”が、
どれだけ気の利いたメタファーであるかを思い知らされます。

外見の効果も魔法に見えるなら、
そこに至るまでの道筋すら魔術的なのですから。

そういう意味では、
この世界に魔術は確かに存在するのかもしれません。



ただファンタジーと違うのは、
抽象化は人間の優劣を決定づけるほどの要因ではないということです。

絵が描ける、描けないと同レベルと思っていいかもしれません。

現実に魔術が当たり前になった世界でも、
案外それくらいの影響しかないような気がします。
(時勢にもよるとは思いますけどね。)



現実に魔術はありませんが、
魔術と同じようなものは確かにあるようです。



さあ、今日もMPの使いすぎには注意しながら頑張りますかね。

上質な記事が少ない訳

自分は/.Jをよく読んでいるのですが、
記事以外にも気になる点がいくつかあります。

その中のひとつなんですが、
画面下部にどこぞから引用された名言が表示されるのです。

ある日のこと、
その欄にこんな言葉が表示されていました。

「にわかな奴ほど語りたがる -- あるハッカー」

この言葉は、
自分に対して理屈ではなく心に訴えかけるような納得感を与えました。



なんと言いますか…

ある道について学べば学ぶほど、
自分の矮小さに気がつくのでおいそれと発言できなくなります。

もちろん慎重にデータを集め、
根拠を揃えてからなら何かしらを発表することもあるでしょう。

しかし、
勢いにまかせた発言はだんだんと減っていくように思えます。



逆ににわかさんは、
まだ矮小さに気がついていない状態です。

その優越感に身を任せ、
何も気にせずどんどん発言します。

ただでさえにわかさんの人数は道を極めつつある人よりずっと多いので、
悪質な発言や記事、論文や書籍が数多く出回ることになります。

これは発言の為のハードルが低い媒体であるほど顕著だと思います。

つまりはインターネットの情報が玉石混交なのは必然となるのです。



でもその中のどこかに、
素晴らしい情報は確かに紛れているのです。

それを抽出することだってインターネットはできるはずです。

インターネットの情報が玉石混交であったとしても、
その中の玉が見つかりやすいようにはしていきたいものです。

学習コストは初心者税の一種なのかもしれない

よく新しい技術に触れるときは、
学習コストを大きな要素として導入が検討されます。

この業界では、
どうもむやみやたらに学習コストが高く見積もられているような気がします。

本当に書籍すら出ていない最新技術ならかなり高いとは思いますが、
マニュアルが整備され終えた技術なんて大したことないでしょうに。

落とし穴も大抵は誰かがブログで愚痴っているので、
検索すれば対処法を学ぶことができます。

未だにSubversionすら学習コストが高いと言う人達は、
真面目に働いているのか疑問に投げかけずにはいられません。



おそらくこの認識の差は、
初心者税の一種なのではないでしょうか。

彼らの税率を下げるためには、
さぼっていた数百時間、数千時間の基礎学習が必要となります。

でも彼らは初心者税が高くて払えないので、
全力で払わずに済む方法をごり押ししているのではないでしょうか。

こんな人たちの存在自体は許容できるのですが、
一緒の仕事をしようものなら彼らに合わせるだけでこちらも税金を払う必要が出てしまいます。

自分は初心者税なんて極力払いたくないので、
一緒に仕事をしないように努めなければなりません。



こういう意味で、
少数の高レベル技術者と多数の低レベル技術者の編成は信用できません。

少なくとも、
同じプロジェクトでも完全に仕事を分けないとまずいのではないでしょうか。

高レベルの特権は、
初心者税の低さにあるのですから。

自分がFizzBuzzを採用に使うなら

FizzBuzzを入社試験に出したらどこを見るかを読んで、
自分ならどんな風に使うのかちょっと考えてみました。

こちらの想定は、
新入社員や中途採用の方向けを想定しています。
(分けて言わなきゃいけないことに違和感が…)

元の記事と前提が違うので、
違う結果になっていますが…まあそんな感じです。



まずは問題を２部構成ぐらいにしたいです。

1. FizzBuzz相当の問題を解かせる。
2. そこから何らかのお題を出してソースコードを変形させる。

でしょうか。

基本的にFizzBuzzは機械的にできなきゃ来るなと言って差し支えないレベルです。

採用したいレベルはさらにその上にあるので、

もう少しひねってやる必要があります。

じゃあなんで最初から難しい問題にしないのかというと、

ウォーミングアップとか、

頭をプログラミング用に切り替えるまでの準備とかです。

ではお題を出しましょう。

すぐに思いつくのは、

1. ここから抽象化してみてください。
2. ここからを高速化してみてください。
3. ここからを省メモリ化してみてください。

でしょうか。

通常は1ですが、

シビアなスペックを要求するなら2や3もありでしょう。

このときのポイントは、

考え方を説明してもらいながら変形してもらうことです。

その人のコーディングに対する姿勢の鱗片が見えると思います。

1として考えてみましょう。

とりあえず、

関数化なりクラス化なりしないのはかなりまずいです。

1～100の部分をRangeクラスにしようと考える人は、

相当にオブジェクト指向が至高の思考にどっぷりな人でしょうか。

そもそも数値が連続していないかもと考え、

コレクションで用意してやるような人もいるでしょう。

倍数の判定もn個あるかもしれないと考えた人は、

判定もループさせなければならないことに気がつくのかな？

そもそも倍数の判定以外も入れたくなるだろうから、

倍数判定の関数を引数で渡そうと考え出せば、

この人は関数型の考えに足を踏み入れたことになるでしょう。

ここらへんは、

その会社が求めたい人材に合わせて評価してあげてください。

大事なのは、

自分の会社に近いレベルを選ぶということです。

高すぎるのもアウトだと思ってください。

あまりにハイレベルな人にExcel方眼紙を書かせたりしてみなさい。

すぐに去ってしまうことでしょう。

それに一人だけ関数型を完璧に使いこなせたとしても、

回りがついてこられなければ同様に去られてしまうでしょう。

※例え仕事で使われることが無かったとしても。知っているだけで違うことが、確かにあります。

このレベルを要求するのが、

ごく少数の企業でありませんように。