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

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

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

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

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

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

ブログが更新しにくい…

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

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

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

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

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

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

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

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の範囲でも再帰的な書き方ができて、
チューリング完全にできるのでしょうか？

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