がるの健忘録 このページをアンテナに追加 RSSフィード

2011-03-31

[]ちょっと気になるので突っ込んでみる

元ネタ

典型的PHPerの13の悪癖

http://anlyznews.blogspot.com/2011/03/phper13.html


これの元ネタの「典型的PHPerの13の悪癖 http://anond.hatelabo.jp/20110329150439 」のほうも見ていたんだけど…ちょっと気になったので、突っ込み。

いつもながら当然ながら、以下、すべて「私見」です。


序文。

…おいちゃんは、はたしてPHPerなのだらうか?

仮説1:Yes

最近扱っている(っつか書いている)言語としては、PHPが一番多い。したがってこの瞬間という時間軸において、PHPerであると考えられる。

仮説2:No

PHPerとは「PHP言語のみを扱うプログラマ」のことである(要出典)。C、C++PerlJavaC#VBJavaScriptActionScriptObjective-CCOBOL については少なくとも業務経験があり、それ以外にもZ80aアセンブラ、N88-BASIC、ファミリーベーシック、rubyPythonSmalltalkLISPHaskellなでしこ、Brainfackなどについて、多少なり経験があるようなてめーが「単一言語を扱う」とかってピュアな世界に踏み込んでくるんぢゃねぇ。


…なんていうどうでもいい考察で頭をならしつつ。start。


1. パスワード認証sshサーバーログインし、vimemacsで開発をする。

PHPerは、生産性が低く、セキュリティ的に問題のある開発環境を愛用しているケースが多々ある。セキュリティ向上の為にはsshは公開鍵認証で使うべきだし、生産性向上のためには、一般的にはローカルに開発環境を用意して、Eclipse/PDT等の統合開発環境を使うべきであろう。

そもそもとして「IDEって本当に生産性が高いの?」って部分で色々懸念はあるのだけど、「開発環境でセキュリティ的に問題がある」って、なんだろう?

sshの話であるのなら、それは「接続環境」って言わない? 「パスワード認証 ダメ! ゼッタイ!!」は、特に違和感もなく賛同するけど。

IDEは…「IDEを使わない開発で相応の腕を磨いたあとで」使うならともかく。見ている限り「いきなりIDEから始める」と、九分九厘「IDEに使われ、振り回されてる」からなぁ。おいちゃんはわりと反対派。

生産性の向上云々いいますが。おいちゃんの開発は、概ね

PuTTYで公開鍵認証

SVNコマンドライン

viコマンドライン

または

・WinSPで公開鍵認証

SVNは亀さん

・てけとうなテキストエディタ(最近はTeraPadかなぁ。Windows環境で、いいviエディタが見つけられてなくて orz)

で、大体5〜10倍くらいの生産性をはじき出してますがなにか?

IDEを使えば生産性が向上するの!!」なんていう銀の弾丸信仰やめて、「本当にボトルネックになってる場所」を一度、きちんと考察してみたらどないでしょ?


2. SVNなどのバージョン管理システムで、使い方が分からないのでブランチを切った事が無い。

開発ツールの学習に無頓着なPHPerは少なくない。例えば、バージョン管理システムを単なるファイル共有・履歴閲覧システムとして利用しているケースがある。リリースをしてもブランチを切らないプロジェクトは多々見かけるし、驚くべきことにソースコードを巻き戻すときに、履歴を閲覧してプログラマがコードを修正するケースさえある。

ブランチを「なぜ切るのか」をまずちゃんと明確にしてから、じゃないかなぁ?

実際問題、管理とかか引継ぎとかのことを考えると「わざわざ切るメリットも少ないねぇ」ってケースも少なくないので。


3. ウェブしか開発したことが無いのに、ソフトウェア技術全般を語る。

世の中には多種多様なソフトウェアあるので、PHPの常識が通用するとは限らないが、PHPerはPHPの常識に固執するときがある。デスクトップケータイアプリケーションデバイスドライバOSミドルウェアの開発は、ウェブアプリケーションの開発とは大きく異なる面もある。また、 Javaや.NETによるウェブ開発は、PHPによるそれとは大きく様相が異なる。

「PHPerはPHPの常識に固執するときがある」は、どの「単一言語er」でも一緒。

で、ほぼまったく同様のことがJavaerにも言えるのだが、彼らにこのことを話すると、大抵、烈火のごとく怒る(いやまぁその辺PHPerも似てるのだけど…PHPerは虐待されることになれてるからw)。

んで、真面目な話。例えば「Linuxで動かすdaemon系のブツ」を作る時は、PHPはもってのほかとして、Jaavだって使いたいとは1ミクロンたりとも思わないしなぁ、正直。

「きっちり」いきたいんならC、「ちょっとインテリジェンスなところがあるから効率は多少犠牲」にするならC++、が、おいちゃん的には選択肢の範囲内、かなぁ。


4. RDBは難しいからと言って、簡単なSQLしか、もしくは簡単なSQLも書かない。

RDBは、原則として正規形のテーブル設計で利用するものだ。RDBは、データの寿命がアプリケーションの寿命より長い事が前提となっており(DOA)、アプリケーションにあわせてテーブル設計をしてはいけない。ただし、速度的に問題が出るケースは、結合回数を減らすために正規形を崩すときはある。

そもそもとして「RDB語るなら、ちゃんと"リレーショナルデータベース、という数学(集合論)"を学んでからどうぞ」って思うんですがどうでしょ?

厳密に言うなら「そもそも、RDBに"テーブル"なんてないよ? あるのはリレーション(関係)だよ?」

RDBは概論としてはさほど難しくないと思うし、そもそも「RDBが難しいから簡単なSQLしか書かない」って、それ、日本語として成り立ってない。


5. PHPなどのスクリプト言語しか知らないのに、プログラミング言語の優劣を語る。

PHPは手続き型、もしくはオブジェクト指向型に分類される言語で、世の中にはLispErlangのような関数型言語も存在する。PerlPHPPythonRubyを比較しても、オブジェクトが使えるスクリプト言語の範囲は出ないので、狭い範囲の比較にしかならない。

そもそも「何をもって優れてるのか」っていう判断基準が意味不明だしねぇ。


6. PHPの遅さを知らないのに「最近のマシンは速いからプログラミング言語に速度は求められていない」と言い切る。

PHPはビルトインAPIの速度は高速だが、PHPコード自体の実行速度は速くない。他のスクリプト言語と比較しても遅い方だ(Computer Language Benchmarks Game)。CやC++Javaと比較すると処理によっては100倍以上も遅くなるので、最近の計算機を用いていてもPHPはパフォーマンスに注意しないといけない時がある。

まず「速度が求められていない」は、状況によってはtrueなので、そのあたりは真摯に向かい合うことが必要。

次に、速度以上にもうちょっとみんな「メモリ」を気にしようよ orz

サーバ管理してて、マジできついから orz


7. クソ重いPHPLightweight Languageと言ってしまう。

LLと言ってPerlRubyPython使いも友達だと主張しているように感じるが、LLという形容は不適切だ。PHPの実行速度は遅く、メモリ消費量も少なく無いので、手軽(easygoing)であっても軽量(lightweight)であることはない。LLと言う単語を使うたびに、軽薄な印象を周囲のソフトウェアエンジニアに与えるかも知れないので注意が必要だ。

そもそもとして、LLの「Lightweight」って「マシンリソースに対する重量」ではなくて「開発者の開発負荷に対する重量」だったのでは?

http://ja.wikipedia.org/wiki/%E8%BB%BD%E9%87%8F%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0%E8%A8%80%E8%AA%9E

> 取り回しに優れ、コードの作成や修正が容易と見なされるプログラミング言語のことを指す

まぁ正直、あんまり興味ないしど〜でもいいっちゃぁど〜でもいいのだが。

おいちゃん的言語きり分けとしては「キッシュ系言語」だしw

> LLと言う単語を使うたびに、軽薄な印象を周囲のソフトウェアエンジニアに与えるかも知れないので

…んな阿呆なエンジニア、いるのだろうか? いや書いてあるからにはいるんだろうけど……… orz


8. クソ重いPHPで、デザパタとか言い出す。

PHPコードの実行速度は遅いので、その中でも他のプログラミング言語と比較して遅いメソッド呼び出しが増えるGoFデザインパターンは、本質的にはPHPに向かない。一つのソースコードの整理手段としてはあり得るが、無闇にデザインパターンを推奨できるプログラミング言語ではない。

なんていうか…見解が違いすぎて(苦笑

そんなに実行速度を重要視するなら「全部CかC++にすればいいのに(でもいやまぁ実際そうなると、今よりは楽園だなぁとは真剣に思う B-p)」。

そもそも、OOPにする時点である程度「実行速度とメモリなどの、ようはマシンリソースを犠牲にしてでもほしい何かがある」んでしょ?


9. クソ重いPHPで、クソ重いフレームワークCakePHPsymfonyZend Framework)にこだわる。

PHPコードの実行速度は遅いので、メソッド呼び出しが増え、実行コード量が肥大するフレームワークは、本質的にはPHPには向かない。ライブラリがセットになっているため生産性が向上し、ソースコードの整理にもなるためフレームワークの採用が一般化しているが、オーバーヘッドも認識しておくべきであろう。

8番と一緒。


10. クソ重いconcrete 5やWordPressMovableTypeで何でも書き出す、ショッピングサイトも作り出す。

PHPコードの実行速度は遅いので、PHPで書かれたミドルウェアは速度的に問題が出やすい。OpenPNEのパフォーマンスに苦しんだ人は少なく無いはずだ。しかし、なぜかPHPで書かれたミドルウェアは増加の一途であり、そしてそれらを拡張するコードも氾濫している。

あぁ…まぁ「ひどいの」多いよねぇ。とはいえ、別段PHPに限ったことではなくて。例えばJavaで書かれたいくつかのブツで、同じくらい「重くて遅い」のに、散々いやな思いはさせられましたが(苦笑

VBは………それ以前な気もする(苦笑


11. 仕様が曖昧で急激に変化するPHPで、テストファーストとか言い出す。

TDDは有効な開発手法だし、PHPでも用いられている。しかし、PHP自体の仕様が曖昧な面もあり、PHPバージョンアップ後方互換性が失われるケースが多々ある。PHPは古くからあるビルトイン関数の挙動・仕様が変化することもあり、テスト・ケースを充実させても、将来のバージョンのPHPでは挙動を保証できない。

PHP自体の仕様が曖昧」については…落ち着いてきた部分もあるけど、でも、まだねぇ(苦笑)。まぁ、厳密には「言語」ではなくて「提供されているライブラリ」だと思うんだけど…そういう意味では、ひとつ疑問。別のほかの言語だってそれなりに「仕様変更」はあるんだけど、実際のところ「言語そのものの仕様変更」の量ってどれくらい違うんだろ?

あと。TDDは「将来のバージョンのPHPでは挙動を保証できない」からこそむしろ重要なんじゃないか、って思う。新幹線だったのが飛行機に「仕様変更」されたとしても、結果的に「大阪に到着できる」んなら、対象クラスは「問題なく動く」っていえるんだし。



12. 勉強会リファレンスに書いてあるような、分かりきった事を発表する。もしくは理解できていない事、誤った内容を発表する。

特にPHPerに限った話ではないが、試行錯誤でアプリケーションが書けるPHP育ちのプログラマは、何か誤解したまま突っ走しる傾向はあるような気はする。若さなのだと思うが、彼らのPCが赤く無いので大目に見るのは難しい。

普通に面白い話"も"聞けると思う。っつか、上述を言い切るなら、相応の期間の調査とその結果が必要じゃない?

> 試行錯誤でアプリケーションが書けるPHP育ちのプログラマは、何か誤解したまま突っ走しる傾向はあるような気はする

これも別にPHPによらない。他の言語でもまったく一緒だと思う。


13. ブログで自らの無知をさらけ出す。

PHPの事が書いてある分にはそうではないが、独善的で主観的なPHPerのブログは多々あるように感じられる。典型例として、自分が使うツールの重要性や利便性を強調し、必須ツールとしているケースが思い浮かぶが、そういう場合に同種ツールとの比較検証が詳細にされる事はほとんど無い。

これは…Javaerのほうが多く見えるんだけど気のせい?


なんだろ…うん全体的にみて、なんとなく「違和感と嫌悪感」を、山盛りで感じる。

多分、その根幹の一つは、ここ。

叩き上げPHPプログラマで、PHPを愛してやまない一方で、他のプログラミング言語や開発ツールには興味関心が無い人々が、上にあげられた人物像にあてはまる気がする。道具に愛着を持つ事は良いことだが、視野が狭くなると周囲には煙たがられるので注意が必要だ。

いやべつに「おいちゃんがPHPを愛しているか」ってのはおいといて。

おいちゃんの場合は少なくとも

・他のプログラミング言語を、業務で使う程度のレベルまではやった上で

いくつかの言語については切り捨てているし(具体的にはVBC#Java)、

・開発ツールをある程度つかって、検証した上で

使わないっていうかむしろ使えないなぁ、って思ってる(Eclipseとか)。いや「好みにカスタマイズすると」なんとかはなるんだけど、そこまでの労力をはらうメリットが見出せない(苦笑)。

あぁちなみにEclipseを「他人が使う分」には「いいんじゃない?」って思ってる。おいちゃんの肌と思想に合わないだけだから。


…なんだけど、まぁ典型的にはJava屋さんの若いあたりに上述のような話をすると大抵、面白いくらい否定的な反応をしてくれる。

ちなみに「古くからのJava屋さん」で一人「…そうなんだよねぇ昔はメモ帳でもいけるような言語だったのにねぇ」と、しみじみ嘆いてた人がいたなぁ、ってのは余談。


んと…つまり。

「無知を改めましょう」という知識の啓蒙に見えてその実「自分の見解を相手に押し付けようとする」雰囲気が見て取れるのが、あるいは少なくとも「自分が是と思えないものはすべて非なんだ」っていう感覚の押し付けが見て取れるのが、イヤなんだと思う。


という感想。


あんど余談。

………もしかして、これが「竹の花が咲くと襲ってくる」 と言い伝えられている、PHP"dis"er、なのかしらん?w

[][]設計の学習方法草案

ふとこないだ気づいたのですが。

んと…


今までに、大小あわせて、多分600〜700以上、くらいのシステムの設計をしてるです。設計してるってことは「DBどうやって切って大まかにこんなコード書いて」くらいまでは妄想してるです。

100弱(多分60〜80)くらいは、実際に実装をしているです。つまり「設計では見えなかった、実装タイミングで気づくミステイク」を、それくらい見ているです。


多分、この量があるから、ある程度までの要望に対しては「あぁあのときのこれが使えるなぁ」という、引き出しの多さにつながっているような気がするです。


んで。


まぁ10数年くらいかけて「毎週1案件以上、お客様からヒアリングしてお見積もり」し続けていればそれくらいの経験はつめるわけなのですが(理論的には、週1で10年やって520経験ほど)。

そこまでヒアリングし続けるのも、若干しんどい部分や時間的に厳しい部分などもあろうかと思うので。


…ドリルにしてみたらどうだろう? と。

おいちゃん的にも、よい備忘録になるし。


っちゅわけで、うまいこと時間を捻出して「設計ドリル」作ってみようかなぁ、と思ってるです。

興味がある方いらっさいましたら「はよ作れや」「なにちんたらしてんねん」などの生暖かいご声援をいただければと思いますw

[][]ふと気づいた言葉尻

ある事象に対する可否を。


「**は出来る」「**は出来ない」って話をする人と。

「**はやる」「**はやらない」って話をする人と。

二種類いることに気づいた。


んと…「神と本音は細部に宿る」ので、噛み砕いて。


loop 出来パターン

「**は出来ますね。やりましょう。」「**、やっぱり出来なかった。出来ると思ったんだけどなぁ」

pool


loop やパターン

「**をやろう。」「**、出来なかったなぁ orz なんで出来なかったんだろう? 次はやるぞ!!」

pool


やっぱり見え隠れしている、成長とか克服とかトレーニングとか教育とか、そーゆー、一連の「なにか」。

2011-03-29

[]寿命と年齢とかに果敢に挑んでみる

元ネタ

(翻訳)開発者の寿命について思うことCommentsAdd Star

http://d.hatena.ne.jp/ymotongpoo/20110307/1299499797


なんか興味深かったので。えぇ毎度おなじみな理由ですともさw


40歳以上の開発者をどれだけ知ってますか?かなり多くの人が0人と答えるでしょう。では、40歳以上の開発者を1人以上知っていると答えた方にさらに質問。その内何人が素晴らしい開発者ですか?

とりあえずおいちゃんは「アラウンドの要らない」フォーティーである。つまり条件を満たしている(でも20進数なら20代だぞ?w)

「素晴らしい開発者」かどうかは、わからない。そうありたいとは思ってるんだけどな〜。どうなんだろ?

「素晴らしくない」だと会話がここで終了してしまうので、仮定法として「素晴らしいとあるいはいえるのかもしれない」程度に、まろやかに仮定してみるw


多くの開発者が数年経つとマネージャになってしまうからです。

ん…基本「全力で回避」w

マネジメントするときは「全力の半分でマネジメント、残り半分で現場作業」を死守します。コードを一ヶ月書かないと禁断症状が出ることが、実験の結果明らかになったのでw

とりあえず…こないだ「8人の開発者を抱えた状態で、彼らの設計レビューとソースコードレビューと質問を捌きつつ、他のメンバーの2倍程度の生産性」は確保できていたので、とりあえず「処理を捌ける」程度には、無能なのではないのではなかろうか、と…多分。

もっとも、それくらいは「ちょっと訓練すれば誰にでもできる」ような気もするが。


2つ目の理由として、長い期間開発をしてきた人の多くが知るべき事はもうほとんど知っていると思いはじめて、新しい問題解決方法を学ばなくなったり、開発者コミュニティで他の人が学んでいることを追いかけなくなったりするからです。

あぁそんな腰掛は「ありえない」なぁ(苦笑

どっちかっていうと、学べば学ぶほど「到達地点が遠くに逃げていく」んですが orz


「なんでうまくいってる方法を変える必要があるんだ?」

については…こちらをどんぞ、って感じ。 http://d.hatena.ne.jp/gallu/20100122/p2


一方で実装自体は古くさかったり無駄が多かったりします。この点において、開発者の価値は減り始めて、(どんな理由でも)スキルが時代に追いつけなくなるまで価値は下がりつづけます。

ほのかに微妙。

「古いからよいわけでも悪いわけでも」ない。だから、もし「古臭い」というだけで批判の対象になるのであれば、それはおかしいと思う。

無駄だって場合は問答無用。

ちなみに「新しい」のはとりあえず「危ない」。検証が落ち着いていない可能性があるから。

まぁ技術者たるもの、一定の確率と割合で「人柱になる」のは義務だよね?w

# まぁ「毎度」はいやだから、ある程度「人が使うまで待つ」ことも増えるんだけどさ(苦笑


自分はバカと意識し続ける

っつか。とりあえず「無知ではない」というのであれば、最低限「ITの業界の全ジャンルでTop、ないし少なくとも明らかにTopクラスである」程度は必要条件だと思う(十分条件ではないので念のため)。

ついでにいうと「自力で対象技術を編み出した」と「対象技術を学んで使いこなしている」と「対象技術を使っている」と「対象技術に使われ、ふりまわされている」との間には、それぞれ、分厚い壁があることを忘れずに B-p

んで。

実際問題として、ストレスにならない程度に「自分は低スキルだ」って思ってるほうが、多分伸びはいいんじゃないかなぁ、と。


自分が知っていること考えていることを常に問い続ける

そもそも「本当に知っているのかどうか」すら怪しいんだし B-p


…で、寿命の話は?w


なさそうなので…おいちゃんが自力ででっち上げてみる。

んと………


プログラミングは「年をとった」には出来ない。

この場合の「年をとった」とは、肉体や戸籍上のお話ではなく、精神の部分。つまり「学習意欲が硬直し、腰掛け、己に満足してしまった」ら、その時点で終わり。

なお、成熟/円熟している人の場合、「年をとった」ではなくて「年を重ねた」といいましょう (C)ケイちゃんw


なので。「腰掛けて頭が硬直した」ら、そこが寿命。

こんなんでどでしょ?

2011-03-28

[]「わかりやすさに潜む罠」の根っこにあったもの

先日の http://d.hatena.ne.jp/gallu/20110324/p2 なのですが。その根っこに、こんなものを見て取っていたことに、いまさらながらに気づいたので、メモを。


わかりやすいコード云々の発言って。

その根っこに「成長とか学習とか教育とかトレーニングとか」の全否定が見えるから、なんだ。


自分が育つことも自分を育てることも。

他人が育つことも他人を育てることも。


「誰にでもわかるコード」って発言は、そのすべてを「否定」してるんだ。

だからいやなんだ。


納得。

[]勘弁してくれ orz

元ネタ

原発がどんなものか知ってほしい(全)

http://www.iam-t.jp/HIRAI/pageall.html

>>

29日追記

コメントでいただいたのですが、上記は怪文書の類だそうです。


妖精現実

http://www.faireal.net/dat/d2/d20903.xml

「妖精現実-原発がどんなものか知ってほしい」

<<

すみません元ネタとちょっと違う観点から見ております(苦笑


その根本は、余りにも机上の設計ばかりに重点を置いていて、現場の施工、管理を怠ったためです。それが直接の原因ではなくても、このような事故が起きてしまうのです。

原発でも、原子炉の中に針金が入っていたり、配管の中に道具や工具を入れたまま配管をつないでしまったり、いわゆる人が間違える事故、ヒューマンエラーがあまりにも多すぎます。それは現場にブロの職人が少なく、いくら設計が立派でも、設計通りには造られていないからです。机上の設計の議論は、最高の技量を持った職人が施工することが絶対条件です。しかし、原発を造る人がどんな技量を持った人であるのか、現場がどうなっているのかという議論は1度もされたことがありません。

それが十年くらい前から、現場に職人がいなくなりました。全くの素人を経験不問という形で募集しています。素人の人は事故の怖さを知らない、なにが不正工事やら手抜きかも、全く知らないで作業しています。

現場に職人が少なくなってから、素人でも造れるように、工事がマニュアル化されるようになりました。マニュアル化というのは図面を見て作るのではなく、工場である程度組み立てた物を持ってきて、現場で1番と1番、2番と2番というように、ただ積木を積み重ねるようにして合わせていくんです。そうすると、今、自分が何をしているのか、どれほど重要なことをしているのか、全く分からないままに造っていくことになるのです。こういうことも、事故や故障がひんぱんに起こるようになった原因のひとつです。

原発を造る職人がいなくなっても、検査をきっちりやればいいという人がいます。しかし、その検査体制が問題なのです。出来上がったものを見るのが日本の検査ですから、それではダメなのです。検査は施工の過程を見ることが重要なのです。

検査官が溶接なら溶接を、「そうではない。よく見ていなさい。このようにするんだ」と自分でやって見せる技量がないと本当の検査にはなりません。そういう技量の無い検査官にまともな検査が出来るわけがないのです。メーカーや施主の説明を聞き、書類さえ整っていれば合格とする、これが今の官庁検査の実態です。

私自身が二〇年近く、現場の責任者として、働く人にオウムの麻原以上のマインド・コントロール、「洗脳教育」をやって来ました。何人殺したかわかりません。みなさんから現場で働く人は不安に思っていないのかとよく聞かれますが、放射能の危険や被曝のことは一切知らされていませんから、不安だとは大半の人は思っていません。体の具合が悪くなっても、それが原発のせいだとは全然考えもしないのです。作業者全員が毎日被曝をする。それをいかに本人や外部に知られないように処理するかが責任者の仕事です。本人や外部に被曝の問題が漏れるようでは、現場責任者は失格なのです。これが原発の現場です。


えと…えぇもちろん「原子力発電所の酷い状況」としても大切な文章だと思うのですが。

ただ、それと同じくらいに…なぜか既視感ががががが orz

2011-03-27

[][]老害

老害ってたぶん。

「老いた人(たち)による害」じゃなくて、「腰掛けてしまった人たちによる害」なんじゃなかろうか、って思う今日この頃。

http://d.hatena.ne.jp/gallu/20090928/p1


20代30代で老害になってしまう人もいれば、70代80代になっても「全然そんなことはない」人もいる。

[]日本語で例えてみる「習熟度」

たとえば「迫り来るような小説」を書く御仁がいる。馳星周池波正太郎菊地秀行夢枕獏あたりがおいちゃん好きだけどまぁ好みは置いておくとして。

馳星周菊地秀行については割と「ストーリーテイリング」が上手な印象があるんだけど、そのストーリーに対して「違和感を感じさせない文章力」って、やっぱりすごいと思う。

夢枕獏池波正太郎の場合、ストーリーと言うよりは「その場の空気」が好きかな。で、その「空気」を文章で出せるというのは、やはり半端なことではないんだろうと思う。


歌詞で好きなものも多い。

「これ」と一つ二つだすのは少し難しいんだけど、折々に「このメロディー+この歌詞が好き」で、ヘビーローテする楽曲はたぶん三桁(苦笑


名前を出してどうなるわけではないんだけど、いわゆる「明文」を書くのがうまい人が時々いて。

彼らが書く「誤解のない文章」は、本当に誤解がない。

ちなみに、明文に関しては「俺だってかける」とかいう自惚れた半可通が一定の割合でいるので、とりあえず2冊ほど本を紹介。

明文術 伝わる日本語の書きかた

明文術 伝わる日本語の書きかた

ザ・テクニカルライティング―ビジネス・技術文章を書くためのツール

ザ・テクニカルライティング―ビジネス・技術文章を書くためのツール


たとえば。

「日本語以外を母国語にしている」人が「日本語でとりあえずやりとりができる」程度に習熟したとして、彼らが「じゃぁ自分だって上の人たちと同じレベルの日本語が操れる」とは、たぶん思わないと思う。あるいは思っても周りが全力で否定して終わり、だと思う。

もし彼らが「日本語を飯の種にする」のであれば、日本語が一通り操れるようになるってのは「start line」でしかなくて。そこからの、それこそ「百尺竿頭進一歩」がごとき不断の努力があって、初めて進めていくことができるじゃなかろうか、って思う。


日本語を「プログラミング言語」に置き換えてみてくださいませ。


[その他技術][一言]プログラミングが「出来る」って何だろう?

http://d.hatena.ne.jp/gallu/20101215/p1


「とりあえず一通り」書ける時点までは、仕事上必要なので皆さん確実にたどり着くのですが。その「先」への歩みが…色々な理由*1で、止まるんですよねぇ。

よく耳にするのは「今のままで問題ない/必要ない」「仕事が忙しいからいつか」。

「問題がない」んじゃなくて「問題点が認識できていない/問題点を認識する能力にすら欠けている」だけだし、「忙しいから」って後回しにしたら間違いなく100%「いつまでたってもやらない」。


ちょっと一回「しんどくても気合い入れて学習して」「日々学習する癖を身につけて、毎月1mmでも積み上げることが出来るように」なれば、ずいぶんと楽になると思うんですがねぇ。

[]マネジメント考察に向けての準備

近々、がっつり考察したいのですが。

とりあえずその準備としてのメモ。

宮大工の人育て (祥伝社新書 104)

宮大工の人育て (祥伝社新書 104)

いい面だけでなしに、短所や欠点も生かして、初めて人は生きる

-中略-

木は、雨に打たれ、冬には雪で押しつぶされ、春になると雪が溶け、傾いた木は起き上がり、毎年右に倒れたり左に倒れたりして、上へ上へと少しずつ伸び、成長し、やがて一本の大木になります。最初からまっすぐな木などありません。

-中略-

その際、大事になるのは、「木の癖」を読み、上手に組み合わせて使うことです。

-中略-

木癖を読み切り、適材を適所にあてがうことで、建物のゆがみを防ぐとともに、長年月の風雪に耐えうる堅牢な寺社建築を実現するわけです。

-中略-

これは「人」を育て、使うことにも通じます。木がそうであるように、人もまた一人として同じ者はおりません。

-中略-

それをどうやって育て、使うかと言ったら、やはり木と同じように癖を読み、得手だけでなく、不得手な部分も上手に生かしてやる、ということだろうと思います。


たぶん、マネジメントって本来的に「世話係」だと思うのですが http://d.hatena.ne.jp/gallu/20070215/p2

実際には、結構な数の会社さんで「全く下を見ない」マネージャさんが量産されていて…まぁ理由は想像つくのですが。


そのあたりを込みで、一度しっかりと「苦手な(言い切ったw)」マネジメントについて、考察などしてみたいかなぁ、と。

*1:いいわけ B-p

2011-03-25

[][]「やってはならないことを知っている」大切さ

ちと別件でふらりくらりぬらりとしていて、 http://d.hatena.ne.jp/gallu/20090228/p1#c のコメントをいただいたところで見つけた、目から鱗な名言。


レジデント初期研修用資料

やりかたは無数にある

http://medt00lz.s59.xrea.com/wp/archives/200

「理解」の深度には、たぶん「正しいやりかたを知っている」のレベルのもっと深いところに、「やってはならないことを知っている」という段階があって

まったくの異業種のはずなのに、異様なほどに腑に落ちる。


あまりにも素晴らしいので、メモ。

2011-03-24

[][]似て非なるもの

よい感じのソフトウェアエンジニアプログラムは「レゴ」です。

下手糞なソフトウェアエンジニアプログラムは「ジェンガ」です。


どちらも、ぱっと見は「同じ形」のものが、初めは、出来上がります。


時間の経過と共に、修正や追加が入ります。

レゴは組み立てなおします。

ジェンガは崩壊に向かいます。


レゴジェンガになることはあっても、ジェンガレゴになることはありません orz

[]「わかりやすさ」に潜む罠、あるいは本音

職業プログラマを前提として。

なんだかんだ、やっぱり「誰にでもわかる」ような書き方をすることは大切です。「今は」あなたがメンテナンスをするとしても、いつかはそれを「引き継ぐ」必要があるし、その引き継ぐ人が必ずしも「高スキルである」とは限らないわけですから。

そういったことを考えると「優れた技術力で書かれた難易度の高いコード」よりも「平均的な技術力で書かれたわかりやすくて平坦なコード」のほうがよりよい、ということは、すぐにでも理解できるんじゃないかと思います。

趣味ならいざ知らず、お仕事でプログラムを組むのであれば、できるだけ「難易度の低い、平坦でわかりやすいコード」を書くようにしましょう。





続きを読む

[]さらしものw

重要なお知らせ


担当の秋山と申します。

この度、サイト運営会社から再三の支払いを求める催促のメールがあったにも関わらず、お客様からのご連絡、ご返答がないということで弊社が依頼を受けまして、ご連絡をさせていただきました。


お客様がご使用中の携帯端末認証記録により、(有料総合サイト)の利用《着メロ・天気・占い・ニュース・待受画面・出会い・動画》等のコンテンツの登録があり、利用料金等の長期滞納が続いてるとの事です。


今後も不当に未払いを続ける悪質なサイト登録者には[利用規約]に基づき携帯個体選別番号から追跡し、お客様の身元調査をおこない登録料金等、損害賠償を求める即刻民事裁判民事訴訟)となります。

通信記録という証拠を提出したうえの裁判であるため利用規約に同意して登録されてる以上は、誤っての登録であっても支払い命令が下されます。

サイト運営会社は状況に応じ和解しても構わないとの事です。

訴訟差し止め、退会処理、和解希望の方は本日中に大至急ご連絡下さい。


(株)東日本通信サービス

TEl 03-3400-8677

担当 秋山

受け付け時間

平日 9時〜19時迄

土曜日 10時〜15時

日曜 祝日は休日となります。

※営業時間外は受け付けておりません。

メールでの返答にも対応できませんので、ご了承下さい。

なんだか2通ほど、ほぼ連続でやってきました。mailアドレスのdomain-partはdocomoでしたねぇ。

久しぶりにこんなきっちりした「詐欺系スパム」をちょうだいしましたw

2011-03-23

[][]技術メモ:認証変

認証系を作り直しているので、備忘録兼ねて。


とりあえず

パスワードの持ち方を変えつつ

セッションIDにmcryptを使わないように

してみやう。…いやmcryptは捨てがたいのだが(苦笑)、オプションとして。


パスワードの持ち方

以前はsha1ハッシュしていたのですが(何がしかの暗号ロジックを使うことも考えたのですが。… http://d.hatena.ne.jp/gallu/20060731/p3 うわぁ2006年って何年前よw)

ちょいと「一意じゃないお塩で味付け」しつつ「柔軟体操」をしてみようか、と。


・・明日に向かってその1:お塩

ソルト(salt)っていいますねぇ普通。

対象文字列の前後どっちかに(普通前かなぁ? あんまり後ろって見ないような…なんで?)、いらん文字列を付けます。この文字列が「お塩」。

うちでは「ユーザさんは固有のID持ってる」んで(普通そうか)、ユーザIDをお塩につかいます。

お塩で味付けをすると

レインボーアタックが出来ない http://d.hatena.ne.jp/gallu/20071211/p1

というメリットがあり、またユーザごとに違うお塩にすると

→「同一パスワード」でも出力(保存される文字列)が異なるので、より推測がしにくい

なんてメリットもあります。


・・明日に向かってその2:柔軟体操

ストレッチいいます。上述の「お塩大作戦」だと、いわゆる「ブルートフォース(Brute Force:総当り/力ずく)」な攻撃には無力です。

なので、ストレッチっていう方法を使って「クラック時間を少し延ばします」。あくまで「少し延ばすだけ」なので、そんなに過信されてもまぁ困るのですが。

参考は…わかりやすいあたりですとこちら。

ハワイより 〜 Mikeのプログラミング・メモ

http://blog.makotoishida.com/2011/03/blog-post.html

頑張って英文読むなら(…頑張らずに読めるようになりたいっていうかまず「ちゃんと読める」ようになりたい orz )

Key stretching

http://en.wikipedia.org/wiki/Key_strengthening


んで…ざっくりググってみたのですが…数千回程度から数万回程度まで、ちょいと幅がある感じですねぇ…どしよ?

とりあえずMagicWeaponでは、きりよく「65536」という数値にしてみます。…でも、ふつ〜のサーバでこれやって、150ms程度で処理がおわる orz 10倍くらいにしたほうがよいのかしらん?

ちょっとデフォルトの数値については、もう少し悩んでみまふ。


とまぁこんな思考過程を経て、「DBに保存するパスワード文字列」は、概ねこんな感じになります。

コードっぽい書き方してますが限りなく「嘘言語」なので、適当に脳内で補完してください。

なお、事前に、idとpassを、文字列で入手していると仮定します。

注:ストレッチ回数を微妙に「ぶらしている」理由は。記憶が定かではない「ストレッチ回数もユーザごとに可変なほうがより好ましいって誰かが言ってたような気がする」的記憶によります。理由が定かではないので削除ってもよいのですが、とりあえず書いてみると、是非のどちらに拠らず、なにか突っ込んでいただけるんじゃかなろうか、的な甘くて淡い期待を元に、残しておきます(笑

stretching_num = ( hash_md5(id) % 0xff ) + config(stretching_num, default:65536);

loop stretching_num
 pass = hash_sha512(id + pass);
pool

hashed_pass = pass;

後は、ここで書く内容でもないのですが「パスワード固定、IDをぶん回す系総当り攻撃」用のギミックも用意しておきたいなぁ、っと。

アラート鳴るだけでもなにか違うっしょ。たぶん。


おちゅぎ。セッションID。

セッションIDのベースになるのは、MagicWeaponの中にある「トークナイザ」ってやつです。

この子は

・現在のエポック秒

・現在のミリ秒

・現在のプロセスID

乱数

から、概ね「一意な文字列」を作り出します。その気になると「自分のIP」も足せるので、並列させてもまずもって一意なんじゃなかろうか、と。

推測不能性については概ね「乱数」部分に頼ってる気がするので、今度この辺を「暗号学的に安全性の高い擬似乱数」に差し替える予定です。

…いつにしよう?


で。

いやまぁトークン自身が丈夫ならそれでいい気もするのですが、現在は

セッションID(の前後にソルトぶち込んだ文字列)を暗号化(具体的にはRijndael 256)した文字列

を使ってます。

これだと、まず「Rijndael 256の解析コスト」があるので&セッションIDのデフォルト寿命が10分なので、比較的安全性は担保されるんじゃなかろうか、と。少し重いけど。


ただまぁ、PHPだとmcryptライブラリいれなきゃいけなくて、その辺で微妙に不評だったりもしたので。

ちと考えているのが

セッションIDのベース(トークン)をsha512でハッシュした文字列

にしようかなぁ、とかも考えてます。

うちのトークナイザのトークンは多分レインボーテーブルには入れにくいのですが、一応「お塩&ストレッチ」は「オプション的に考慮」してみようかなぁ、とかなんとか。


こっちもなんか「ブルートフォース系」への対策をしておきたいような気がするのですが…DDoSまでを視野に入れたときに…どうしようかなぁ? と。

とりあえず「いい手があったらやる」程度に備忘録。


まぁ基本的に「ガチャコン構成(気に食わなかったら、インタフェースあわせた「別クラス」に差し替えられる構成)」にするつもりなので。

「まずいってわかったらその時点で改修すりゃいいや」的に楽観視はしているのですが。

# きっと親切な おもひかね が突っ込んでくれるって信じてる。


以上、明らかにメモ(笑

2011-03-21

[]おいちゃん好みのPHPのための20Tips

インスパイアもと群。


より良いPHPerになるための20Tips

http://1-byte.jp/2011/03/20/20_tips_you_need_to_learn_to_become_a_better_php_programmer/

もっとより良いPHPerになるためのTips

http://suin.asia/2011/03/20/20_tips_you_need_to_learn_to_become_a_better_php_programmer

より良いPHPerにならないための20Tips

http://anond.hatelabo.jp/20110320223445


以下、純粋に私見です(いつものことじゃん)。

立ち位置としては…「いわゆる手続き型はある程度の種類やってる、でも最近は割合とPHP比率が多くて嘆いているプログラマ」ってあたりかしらん?


1. <?phpと?>

まず「<?ぢゃなくて<?phpを使え」については賛成。

次に「?>を書くな」も賛成。

# …あれ? 半角で<?phpを書くと…消える? エスケープ処理されてない?

# テスト。


2.設定ファイルは?

そもそもとして、普段、PHPコード「ぢゃない」設定ファイル使うから、includeできねぇしなぁw

この辺は「ならないため」の方におおむね全面的賛同。

ただ、おいちゃんは : ぢゃなくて = を使うけどw


3.コメントは?

いらんコメント多数。それでも書け。

参照: http://d.hatena.ne.jp/gallu/20101116/p1


4. インデントとスペース

宗教論争、だねぇ(苦笑

おいちゃんは2スペース派。他人が何を使おうと、原則、とやかくはいわないし、現場の流儀には従う。


5. 変数

基本的には「熟考すべし」。時間をかけるのもあり。

ただし「変数の型を持たせるハンガリアン」は、そもそもハンガリアンって単語に対してちょいと勉強不足。 http://d.hatena.ne.jp/gallu/20070520/p1

なお「ごく狭いスコープ」の変数で、おいちゃんは割と「1文字の変数」を多用したりはする。その辺は、どこかでちゃんとまとめて「流儀」として書いてみたいなぁ。


6. 変数初期化

ちゃんと初期化するのは、よいしつけだと思われます。


7. 戻り値は?

例外は、個人的なスタイルとしてあんまり使わない。以前に結構なトリッキー例外を多々みているトラウマが未だに残ってる(苦笑

returnのデフォルトfalseは、その方が基本安全だとは思う。


8. 配列へのアクセス

vector配列なのかhashな配列なのか、を意識するほうかなぁ。いやまぁ「PHPって全部hash+listの変な配列ぢゃん」とかいう事実はおいといて。

vectorは「数値」を意識したいので、クォートなし。

hashは「文字」を意識したいので、クォートあり。


9. echo

…使わないなぁ(苦笑

普段は、printが多いかな?

printfは…昔の「案外に重いんだよ(C言語)」なイメージが結構つきまとって(苦笑:ちなみに「今」を基準にすると、ンなもん気にするほどじゃありませぬ。

使うときには使う、かなぁ。

割と、c++

std::cout << hoge << std::endl;

のイメージがあって、それっぽいように書くことが多いような気がする〜


10. 三項演算子

…読めない、っていわれたことあるからなぁ(苦笑

まぁ普通に使いますが。

あ、「ネストさせる三項演算子」はアウト。言語ごとに微妙に解決順番の差異とかがあって、面倒なので。


11. 真偽値のチェック

===の話は、さんざんっぱら「2a問題」で書いているので略。 http://d.hatena.ne.jp/gallu/20061108/p1

「ならないため」の

if ( $flag ) {
}

には、割とはっきりと反対。「後で仕様変更が発生して」面倒が起きたり、あるいは「理解して書いているのか、怠惰の結果として書いちゃったのか」とかがわかりにくいから。

一方で、書いたってたかだか数キーストローク程度、それを「やらない」積極的な理由が思い浮かばない。

ちなみにおいちゃんは

if ( true === $flag ) {
}

って書く。NTT記法とかいうんだったかなぁ? できるだけ「定数を左辺に」するの。万が一が防げるので、おいちゃん的に好み。


12. インクリ/デクリ演算子

いろいろやるけど…「他人がメンテナンスする可能性」があるコードだと、前置換と後置換の差異がでないように「単行」で使うようにはしているかなぁ。

説明すんのめんどい(苦笑


13. 代入演算子

ん…ぶっちゃけ「どっちでも」(苦笑

使う使わないのどっちも、そんなに「高い優位性」を感じていない(苦笑


14. print_rとvar_dump

関数、いる?

まぁ「var_dumpの結果を文字列としてほしい」時があるので、それようの関数っつかメソッドは作ったが。

たぶん、デバッグのやり方が「少しだけ」違うのかも。


15. 定数

何を「設定ファイル」にして、何を「定数」にするのか、ってのは割と深い問題。

そのうち書くけど、雑にいうと

プログラマ以外触らせたくなくてかつ変更が少ないなら:定数

プログラマ以外触らせたくなくてでもそこそこの頻度の変更が見込まれるなら:定数または「触るな」設定ファイル

・ユーザが触ってもよいものは:「触ってもよい」設定ファイル

って切り分けかなぁ。


16. $_GETと$_POST

「ならない」さんところの「ラップしろ」に全面的に賛成。その方が後々、デバッグとかで便利。


17. 関数とクラス

そもそも「むき出しの関数」とか最近滅多に書かないしなぁ(苦笑

引数20個は「ダメ! ゼッタイ!!」なんだけど、一方で「引数連想配列に」ってのもまた「ダメ! ゼッタイ!!」。

基本、どちらも根本的に「インタフェース設計でしくじってる」。


18. メソッドチェイン

ん…微妙。

setter程度で「ど〜してもチェインしたい」理由が今ひとつわからじ。


19. コードの繰り返し

共通化は口を酸っぱくしていつもいう通り。

「同じ処理」じゃなくて「同じ意味」を共通化、が基本(別の角度で「同じ処理」の共通化もあるけど、それは一つ上のお話)。

で、共通化するのは「二度目」。


20. 結合度

加減…かねぇ。数やって「何となく見えてきた」んだけど、文字にできるほどは習熟できていない orz

一緒に「設計をする」チャンスがあったらお見せいたします、って感じかなぁ。

たぶん、そこのあたりが「OJTによるスキルの伝授」部分の一つなんじゃないかなぁ、って思う。


総括

立場によって違うので。おいちゃんは「PHP"も"やる、職業プログラマ」って観点。

えと…「必要なところに必要なだけこだわる」のが、おいちゃんの基本かな。言い方を変えると「不必要なところにはこだわらない」。

その「必要/不必要」を見極めるあたりが、(いらんものを含む)経験のたまもの、かなぁ。

[]cakePHPについて

こんなのを見つけたので。


CakePHP開発者が知るべき10のこと

http://1-byte.jp/2011/03/09/10_things_you_must_know_about_cakephp/


1. CakePHPで良いのか

とりあえず聞いてみたいのが「cakeのソースをちゃんとある程度(コア部分くらいは隅から隅まで)読んだ」上で使ってるのかなぁ? っと。

おいちゃんは、とりあえず(お仕事で使うことがあったので)一回読んだです。えと…うん正直、どっちかってぇと「きしょい」って感じた(苦笑

もうちょっと言葉をきれいにすると「過保護すぎ」って思ったかなぁ。


2. CakePHPの癖を知る

うん思う。おいちゃんの認識が十全にあってるかはわからないけど。

イメージとしては「シンプルな業務系には使いやすい一方で、おかしな要求を片付けるにはちょいとしんどい」なぁ、っと。

ちなみにおいちゃんの周りのお仕事は、大抵の場合「何割か"奇妙な要求"がある」です。


3. 高速開発手法を知る

2番と一緒。「想定されているルートを走る」時には便利だと思う。


4. 学習方法を知る

cakePHPを「なぜ作ったのか」を一回聞いてみたいかなぁ。

フレームワークって、たぶん「思想」だと思うので。


5. サイトを高速化する

高速化を考えるには、cakePHPって少し重すぎない?

ちょっとメモリ食う量が多すぎ orz


6. デプロイを自動化する

これは…cakePHPによらない話、なような…


7. 継続的インテグレーションを取り入れる

後日考察。


8. バリデーションを活用する

え? これって「普通にある機能」ぢゃないの?

MWだと、data_clumpがこの機能を持っているかなぁ。


9. エディタを活用する

えと…viとかvimとか?(笑


10. 最新の情報を得る

まぁ大切かなぁ、と。


以上、備忘録兼ねて。

2011-03-14

[][]おいちゃんは「違う」と思う

元ネタ群


「大震災は天罰」「津波で我欲洗い落とせ」石原都知事

http://www.asahi.com/national/update/0314/TKY201103140356.html

石原慎太郎東京都知事は14日、東日本大震災に関して、「日本人のアイデンティティーは我欲。この津波をうまく利用して我欲を1回洗い落とす必要がある。やっぱり天罰だと思う」と述べた。都内で報道陣に、大震災への国民の対応について感想を問われて答えた。

発言の中で石原知事は「アメリカアイデンティティーは自由。フランスは自由と博愛と平等。日本はそんなものはない。我欲だよ。物欲、金銭欲」と指摘した上で、「我欲に縛られて政治もポピュリズムでやっている。それを(津波で)一気に押し流す必要がある。積年たまった日本人の心のあかを」と話した。一方で「被災者の方々はかわいそうですよ」とも述べた。

石原知事は最近、日本人の「我欲」が横行しているとの批判を繰り返している。


東日本大震災:石原知事津波は天罰」

http://mainichi.jp/select/weathernews/news/20110315k0000m040043000c.html

東京都石原慎太郎知事は14日、東日本大震災に関連し「この津波をうまく利用してだね(日本人の)『我欲』を一回洗い落とす必要がある。積年たまった日本人の心のあかをね。これはやっぱり天罰だと思う」と発言した。蓮舫節電啓発担当相から節電への協力要請を東京都内で受けた後、記者団に語った。

その発言直後に石原氏は「被災者の方々、かわいそうですよ」と付け加えたが、「天罰」と表現したことが被災者や国民の神経を逆なでするのは確実だ。

石原氏は「天罰」発言の前段として「去年1番ショックだったのは、おじいさんが30年前に死んだのを隠して年金詐取する、こんな国民は世界中に日本人しかいない」と述べていた。【青木純】


「大震災は天罰」「津波で我欲洗い落とせ」石原都知事

http://www.asahi.com/national/update/0314/TKY201103140356.html

石原慎太郎東京都知事は14日、東日本大震災に関して、「日本人のアイデンティティーは我欲。この津波をうまく利用して我欲を1回洗い落とす必要がある。やっぱり天罰だと思う」と述べた。都内で報道陣に、大震災への国民の対応について感想を問われて答えた。

発言の中で石原知事は「アメリカアイデンティティーは自由。フランスは自由と博愛と平等。日本はそんなものはない。我欲だよ。物欲、金銭欲」と指摘した上で、「我欲に縛られて政治もポピュリズムでやっている。それを(津波で)一気に押し流す必要がある。積年たまった日本人の心のあかを」と話した。一方で「被災者の方々はかわいそうですよ」とも述べた。

石原知事は最近、日本人の「我欲」が横行しているとの批判を繰り返している。


http://twitter.com/asahi_kantei/status/47220894023692288

副長官番A)節電の要請に訪れた蓮舫・節電啓発担当相と会談した石原都知事。会談後に「震災への日本国民の対応をどう評価するか」と質問したところ、石原さんは「日本人のアイデンティティーは我欲。この津波をうまく利用して我欲を1回洗い落とす必要がある。やっぱり天罰だと思う」と述べました


「大震災は天罰」「津波で我欲洗い落とせ」石原都知事

http://news.goo.ne.jp/article/asahi/nation/K2011031403560.html

石原慎太郎東京都知事は14日、東日本大震災に関して、「日本人のアイデンティティーは我欲。この津波をうまく利用して我欲を1回洗い落とす必要がある。やっぱり天罰だと思う」と述べた。都内で報道陣に、大震災への国民の対応について感想を問われて答えた。

発言の中で石原知事は「アメリカアイデンティティーは自由。フランスは自由と博愛と平等。日本はそんなものはない。我欲だよ。物欲、金銭欲」と指摘した上で、「我欲に縛られて政治もポピュリズムでやっている。それを(津波で)一気に押し流す必要がある。積年たまった日本人の心のあかを」と話した。一方で「被災者の方々はかわいそうですよ」とも述べた。


この台詞がもしtrueだとすると。

東北地方を中心に、万人単位の人命が失われるほどの我欲があり、ゆえに、津波でそれだけの人命を失う必要がある」という意味だと、おいちゃんには見て取れます。


とてもではないですが。

おいちゃんには、原子の一欠片たりとて「理のある」言葉には、見えません。


石原都知事にお願いをいたします。

まず、あなた自身の家族をこの天災によって数名失って下さい。

その上で、その台詞を「ご家族を、この天災によって失ってしまった方々の目の前」で、肉声で、述べてみて下さい。

それができるのであれば、ご自身の台詞もあるいは「あり」なのかもしれません。


なんていうか…都民として「反吐が出る」と、心の底から思いました。


都知事選は、もう目前ですね。

2011-03-08

[][][15|20|50]%ルールについて考えてみた

まぁ色々と思うおいちゃんがありをりはべりいまそかり…って、自分で自分を丁寧にしてど〜すんの。

おいといて。


ちょいとまぁ、調べつつ考察。

相変わらずの「考察途中」なんで色々と荒削りなドラフト感が未熟々ですが気にしないように。


んで、いきなりの本題。

んと…まずは検索してみる。


3Mでは「15%で好きな研究をしてもよい(should)」。

物理学のところでは「若手の研究者は仕事時間の20%を自由に使って好きな研究を」。これが「mustなのかshouldなのか」はよくわからない。

Googleは「20%、自分の業務とは異なる研究を」。これはmsut。

サイボウズは「設定する研究開発領域の範囲内において、自分で設定した研究開発テーマに業務時間の最低50%を割くことができる」。たぶんshouldだと思われる。


えと…いくつかの切り口で分解。


まずビジネスという観点。

物理学Googleはないっぽい。物理学は「見地を広げるため」的な雰囲気があるし(おいちゃんが感じ取ったニュアンスなのでもしかしたら違うかも)、Googleはもうちょっと「ビジネスはビジネスの人間がやるから、技術の人間は技術を極めろ。余計な事考えるな」ってはっきり言ってるみたい。

3Mとサイボウズはある。3Mは「評価でビジネスにつながっているかどうかをチェックしている」し、サイボウズはそもそもとして「ビジネスに結びつけること」をはっきりと明言しているみたい。


人事評価的には「評価対象である」で一致。たぶんここ重要。


で…根底に見えるのは、たぶん、これ。


上述の企業たちは、企業として「正しい努力をしている」だけの怖さに、たぶん多少なり気づいているんじゃなかろうか、と思う。

後は、それに対するアプローチの違い。


3Mとサイボウズがある程度似ていてGoogleが違うのがビジネスの観点。そういう意味で「強気だなぁ」って思うのはGoogle

Googleの「技術だけやってればいいよ」の裏側には「明らかに抜きん出たものを作ってくれるんだよね?」っていうプレッシャーと「餅は餅屋。ビジネスはビジネスレイヤーの人間がどうとでもしちゃる」っていう圧倒的な、相互のプロ意識を感じる。

3Mと比較してサイボウズがちょっとだけ甘いなぁって思うのが「設定する研究開発領域の範囲内において」っていう縛り。ただその分、サイボウズは「50%以上」とかいう、かなりずば抜けた融通を与えているあたりがすごい。


Googleで極めて顕著に、3Mで顕著に見て取れるのが「新しいものひとつ生み出せないようなヤツは高評価の対象外だよね」っていう、割合に怖い無言のプレッシャー。

特にGoogleは「20%ルール」が義務なので、より一層。

いわゆる「ニッポンのふつ〜のさらりまん」なエンジニアには、ちょっと重過ぎるプレッシャーなのかなぁ、と。

でもたぶん「言われたものを言われたとおりに唯々諾々と右から左」なエンジニアって…正直あんまり存在意義を感じない(苦笑

そういう意味で「ふるいにかける」意味でも、割と大切なのかも。


さらにちょっと視点を変えて。

んじゃ導入するとして「日常業務をどうするか」。おいちゃん的には「減らさない、増やさない」。

元々としての「オーバーワーク」はマネジメントの欠落である、で片付けるとして。

マネジメントが行われた結果として「週40時間で片付く業務がアサインされている」場合、それを頑張って32時間で終わるようにするのは多分エンジニアの努力で、「どこに無駄があってそれをどうやったら32時間に縮められるのか」を教えるのは上司の役目。20時間に減らすのは…うんまぁでもチャレンジャブルなので、よし。


…うんたしかにこの辺を一通り考えると、導入に二の足を踏むのも、安易に導入して失敗しまくるのも、よくわかるかなぁ、と。

それを踏まえた上で、やってみたいかなぁ。相当に目の荒いふるいがかかりそうだけど(苦笑

2011-03-04

[][]急激なものは急激に

無理な力で急激に成長させたものは、どこかで反動を食らって急激に沈む。

Breakthroughは、はたからみると「急激」に見えるが、あれは「地味で長い蓄積の積み重ねの結果」だ。

急激な成長を「そのままとどめたい」のなら、急激に成長したときに用いた労力に倍する労力を、常にはらい続ける必要がある。


一次目標をちゃんと見据えた上でなら。コツコツした努力も、一気呵成な変化も、お天道様にちゃんとお出しできる真っ当な努力であれば、ありだと思う。

二次目標を一次目標と見間違えて派手に動かすと、後で驚くほどの反動を食らう。

ましてやそれが「とても口に出来ないような」品性下劣な行為であれば、なおのこと。

http://d.hatena.ne.jp/gallu/20101101/p1


以上、例えば、以下の2つのニュースとかを見て思った感想。


半額クーポンサービス『グルーポン』の横暴な手法 勝手に特典を付けて店舗側困惑 その胸中を激白

http://getnews.jp/archives/101365

グルーポン側の言い分としては「利益ゼロの考えではなく、ゼロ円でお客さんを呼ぶ宣伝広告だと思ってくれ。常に満席ではなかったら、空いてる席を宣伝の為に使え」というものだったそうだ。

- 中略 -

掲載後に問題が発生。上記の取り分の件ではなく、なんと約束になかった飲み放題の特典が付けられていたというのだ。それを知った店側はグルーポン側に訂正するように訴えたのだが、訂正されたのは22時15分。クーポン購入者にはメールで伝えるので問題ないということだったが、実際には届いていない購入者も多く、来店してから飲み放題の特典を使いたいと言う人が当然現れた。


グルーポン』が店に断らずに半額掲載強行! メモを契約書と言い張る

http://getnews.jp/archives/102058

このケーキショップさんは昨年末のクリスマスシーズンにチーズケーキが半額で販売されているのを『グルーポン』からのダイレクトメールで知ることになり、驚いたという。お店にとっては寝耳に水。確認のため社員に「契約したのか」と確認を取ったが誰も『グルーポン』とは契約していないという。

- 中略 -

お店側は事情を知るために『グルーポン』の担当者に連絡を付けたところ以下の様な回答だったという。まず『グルーポン』側はケーキショップ『ストロベリーファーマーズマーケット』の担当にメールを送ったとのこと。そのメールの内容は「先日のチーズケーキの掲載日が近付いてます。いかが致しましょうか。お返事がなければ提案日通りに掲載します」という内容だったそうだ。しかしクリスマス直前のケーキ屋さんといえばメールなど見る暇も無く忙しい日々。しかしメールへの返事がないことをもって『グルーポン』側は了承したと判断し半額クーポンの掲載に踏み切ったのだ。

- 中略 -

お店側が『グルーポン』に確認してみると『グルーポン』側は「契約しています」の一点張り。それでは契約書を見せて欲しいと言っても見せてもらえないとう状態が続いた。そしてその後よくよく話を聞いてみると、担当者が契約書と言っていたのはケーキショップの店長に「写真掲載のチーズケーキの写真はこれにしましょう!」と打ち合わせをした時のただの“メモ”だったとか。

結局はすべてのお客様へお詫びのメールと取り消しのメールを出し被害は表向きなかったという形になっているものの、実際は怒って帰った客も居たとのことだ。

2011-03-03

[][]TRPGの成功判定で学ぶオブジェクトの切り方への一案

とりあえずきれいごとな建前として「クラスをどう設計していくのかの一例を示してみたい」っていうあたりの要望がある、ってことにしといて。


ネタ的にものすごくニッチな気もするのだが。

書きたくなったんだからしゃ〜ないw

# っていうか「実装する気満々だったりする」ので単純に「ちょ〜どいいから記事にして備忘録にしちゃえ〜」って感じです B-p


まず、大雑把に「TRPGにおける成功判定(ダイスを使うもの)」について「最アバウトレイヤー」で考える。

・ダイスを振る

・成功したり失敗したりする:結果とか呼んでみる


うんこんなもんだ。

プログラムっぽく書くとこんな感じ。

結果 = ダイスを振る();

素晴らしい。

見もふたもない、とも言う。


さて。結果とダイスを振る、のどっちから考察してもいいんだけど…とりあえず結果から。

基本的には「成功」か「失敗」の2択なので。2択ならbooleanでいいんぢゃね? ってことで考えてみる。

この辺の考えの甘さとそれに伴う修正の仕方とかは後でやるから、気づいてたら一端失念してw

boolean = ダイスを振る();

さて、処理への考察。

一般的に「さいころを振って」「ある数値基準に、それより大きかったり小さかったりすると、成功したり失敗したりする」もんです。

boolean = ダイスを振る(振るダイスのタイプと数, 目標値);

そうだなぁとりあえず「D&D 4thのST判定」とか局所なところから。

1d20ふって(20面ダイスを1回振って)10以上なら成功、9以下なら失敗。

この場合要素としては「1d20」「10(以上なら成功)」なので。その辺をてけとうにパラメタっぽくすると…こう?

boolean = ダイスを振る("1d20", 10);

ここいらあたりまではぶっちゃけオブジェクトとかいらない。別にぺたんとしたfunctionで十分。

問題はここから。

「ダイスによる判定」は、実際のところそれはそれはバラエティに富んでたりする。


まずは「上方判定」と「下方判定」。さいころの目が「小さいほうがいい感じ」と「大きいほうがいい感じ」ってのがある。D&Dとかは上方だし(昔は上下ばらんばらんだったんだけどねぇ)。GURPSなんてのは典型的な下方。

さらに。さいころの目を足すのではなくて「個々のさいころと目標値を比較して、目標値を上回ったダイスの数で判定(シャドウラン/WoD)」とかっていうのもあります。

さらにさらに、ごく一部のシステム(具体的には央華封神)には「裏成功」というびみょ〜な成功もあります。

ついでに。結果も「成功と失敗」だけではなくて、一般的には「クリティカルファンブル」ってのがあります。改心の一撃&痛恨の一撃とかまぁ色々表現がありますが。ないものもあります。


まずとりあえず「結果、ってのは2種類とは限らない」らしいことが骨身にしみてわかったので、一端boolean説を取り下げます。

毎度のごとく「結果、というよくわからんモヤモヤしたもの」に戻します。

この辺のフットワークのよさとかケツの軽さとかは重要なのでチェック。試験に出るよ。

結果 = ダイスを振る();

先に結果のほうから再考察。

色々なシステムを大まかに統合して、「結果」というカテゴリに入る状態や情報は

・成功

・失敗

クリティカル

ファンブル

・裏成功かどうか

・成功数

・失敗数(ボッチ数)

あたり。数を聞くものを除いて、基本的には「個々にis関数を作って問い合わせる」のが楽なので。

極めて大まかに、この子をクラスにします。

class 結果
{
  public abstract boolean is成功();
  public abstract boolean is失敗();
  public abstract boolean isクリティカル();
  public abstract boolean isファンブル();
  public abstract boolean is裏成功かどうか();
  public abstract int get成功数();
  public abstract int get失敗数();
}

となるわけですな。結果の状態が増えたら適当に増やしといて、っていう気軽さがオブジェクトの身上。

なので、一端、戻り値である「結果」については考察終了。


次に「ダイスを振る」ほう。

結局のところ「ある目標値に対してダイスを振ってどうだったか」を聞くので、本質的な部分である

結果 = ダイスを振る(振るダイスのタイプと数, 目標値);

の部分には差異がない。ここ重要。


差異がないからんじゃってんで、割とすぐに思いつくのはこーゆーインタフェース

結果 = ダイスを振る(判定種別, 振るダイスのタイプと数, 目標値);

い〜んだけどっていうかぜんぜんよくないんだけど。

上述の実装は、やらせてみると、大体こんな感じ。


結果 function ダイスを振る(判定種別, 振るダイスのタイプと数, 目標値)
{
  switch(判定種別)
  {
  case 'D&DのST':
   処理;
   処理;
   処理;
   break;

  case 'ソードワールド':
   処理;
   処理;
   処理;
   break;

  case 'シャドウラン':
   処理;
   処理;
   処理;
   break;

  }

 - 以下略 -

で、保守性の観点などから、はっきりいって「ンベ B-p」な感じです。

これをみて「きしょい」って思える程度の感性は、もっていて損ないと思う。

こゆ時に、GoFの「工場(Factory)」をつかうであるざんす。


んと…イメージを大まかに書くと、こう。

ダイス処理インスタンス = 工場::作成依頼(システム名);
結果 = ダイス処理インスタンス->処理よろ〜(振るダイスのタイプと数、目標値);

ずぼらな人的には、こう。

結果 = 工場::作成依頼(システム名)->処理よろ〜(振るダイスのタイプと数、目標値);

これをやると「システムが増えたとき」に有利なほかに「とあるシステム(用のダイス処理)への修正」が「ほかのシステム(用のダイス処理)に影響しない」ので、その辺がなんていうか「気軽」です。


まぁ、こうやっておいちゃんはクラスを切っていくわけですね。

「上から下に」落とすんじゃなくて、もっとこう…なんていうか…あぢゃいるでいんたらくてぶな感じ?(いってみたかっただけ)

こまめに作って、ちょこちょこと修正しながら、時々は大本に立ち戻りながら、ゆっくりと「荒削りから仕上げに向けて」進めていく感じ。


このほうが楽なんじゃないかなぁ、って思う、おいちゃんからの一案でした。