message.txt

今日はプログラミング日和だじょ
今日はバグ危険日だじょ
@akayaman がばぐった！
開発者は"アーティスト" 。ソフトウェアはその"作品"
組織ではなく、自分のプログラミングを楽しむ
心はいつもオープンソース
エースエンジニアに求める気質は「無精で短気で傲慢」
失敗を恐れない文化 - 産み落とした多くのバグへの鎮魂歌 -
ハードボイルド vs. 悲劇の主人公
エンジニアのモチベーションについて考えたこと
スーパークリエイタとスーパーエンジニア
誠に愚かしい事に、かつての自分は最新の技術のみを理解して満足する人間であった
技術がただそこに佇むだけで、そこに存在するだけの対して、人は自ら自分の位置と情報発信する存在だからである。
師の大きな背中を見ながら、自分は知識を付けた上で、師に感化され、師の技を盗み、大きくなりたい。
語らなければ伝わらない『知』
扱うことが難しいコンピュータ・ネットワークを空気のように意識せずに使えるシステムを開発したい
「ありえるたん」は10分で生まれました
世界をわが手に！
蛇がにょろ～っと顔を出している
Aquaの開発はわたしの手中にある。
家庭が何より大事だった...
バニー部は、愛地球博を応援します！
emacs ラブ! Eclipse? 何それ？
アクアに萌え～!
風に乗って飛ぶ
･･･
Stealth Geek
オーシャンパシフィックピース
Jリーグも応援しようよ！
社会人とは。
お金で買えない価値がある。Master Hamagishi(日本人)
1を聞いて10を知る見た目は20歳の女ですが、何か文句ありますか？
If you put your mind to it, you can accomplish anything.  Doc, 1985
戦うベトナム人。かかって来なさい。
I am Sodex. Do you Sodex?
副作用はダメなんじゃないですか。
本物の女子大生ですが、何か文句ありますか？
突撃！となりの晩テスト★ きょうのおかずはこんがり香ばしいスモークテストです。
ベトナムへようこそ!
to programming or not to programming
最後まで生き残るのはコボラーです
色気より食い気
へちまよりひょうたん
アリエル征服画策中。給料よりも睡眠。寝る子は育つ。有休?そんなの関係ねー。
将来はバングラデシュで悠々自適生活
誠に愚かしい事に、かつての自分は最新の技術のみを理解して満足する人間であった。
言い替えれば、かつての技術を学ぶ必要性を理解出来ていなかった。
皮肉にも、否定していた行動をとることで、その必要性を理解できた。
この世は萌えで回ってる！2次元以外認めません。
小田原は北条早雲のものだ！だから天下はとれない。
つかもとさんが喋ってくれない・・・・。彼が喋っているところを見た人がいるんだろうか?
えー、どうしよう？
こっち生２つ追加―。
あと、タン塩と上ロースとはらみにチシャ菜4人前ずつお願いしまーす。あ、あとカルビもー。
ゆっくりしすぎた この結果　はたらきだしたら 一生損　夕方過ぎまでまた寝てた また寝てた  －『ゆっくりでいいさ』より
コネコ
やっぱりうぃんどうずがせかいさいきょうなのでみんなもっとうぃんどうずをあいせばいいとおもうよ。
Presto
体重が・・・。でもお酒はやめられん。いつか杜氏になります。
おのれ....謀ったな、孔明！！！
I am real Unix. Sodex is just an imitation.
上京して早10年。 訛りをとるにはどうすれば・・・。
ピエロ 世の中に100％は存在しない 相手の態度や反応が気になる
仮面 世の中で一番大切なものは親 しっかり者というよりはやんちゃで甘えたがり
食いしん坊
マイウェイ こうと決めた場合には相手の意見は雑音 比較的さっぱり
くつ下は穴があいてからが勝負
ピエロ 超・臨機応変型。一貫性にこだわらない 警戒心が強い。情に流されがち 理想主義
仮面 非常に頑固でとても寂しがり 秘密は墓まで持っていく
ピュア 単純で難しいことが面倒 あらゆる物事をシンプルに解釈する
マイウェイ 自分は自分、他人は他人 非常にまっすぐで「正々堂々」
マイウェイ 気品ある、しっかり者 自己責任でまっすぐ突き進むバイタリティ
ERPシステムとの連携により、安全かつ迅速な情報共有を実現し、人財の有効活用を目指すじょ
営業活動の効率化と迅速化のために何ができるんだじょ？
拠点を結ぶ情報共有ネットワークとして活用してほしんだじょ
新たな組織体制・改革を後押しするじょ
利用者に向けて有益な情報への「気づき」が重要だじょ
情報からビジネス活動に結びつけるための「行動」を支援するじょ
コミュニケーションおよびコラボレーションを促進するじょ
情報共有に関する様々な問題解決に柔軟に対応するんだじょ
ありえるたんは「Activity Assistance」というコンセプトだじょ
クリティカルワークに必要な情報へのアクセス・発信するじょ
社員一人ひとりの業務効率の向上を実現するじょ
共有すべき情報の有益性・優先順位付けをシステムが行なうんだじょ
利用者に必要な情報を的確に「Push」してあげるんだじょ
個人の活動を支援することで結果的に組織全体のパフォーマンスを最大化することを志向できるのか？
膨大な情報の有益性・優先順位付けをシステムが担当するんだじょ
携帯電話は嫌いだじょ。
Lotus Notesをやっつけるんだじょ
あきらめない!Notes移行!
これから「プログラミング」の話をしよう
正しいことをするんだじょ
私は私のものか？
どっちが正しいの？
重要なのは同期
重要なのは動機?
自由とは?
人生は不公平か？
誰が何に値するの?
互いに追うものは何?
@akayaman こわい・・・
スーパー牛さんパワー
もー!
数千件のオーダーのコメントスパムがあったので最近のコメントを削除しました。
過去のスパムの場合、タイトルだけでスパム判定できない時は中を確認してから消していました。
今回は無理です。
数が多すぎます。
問答無用で消しました。
非コメントスパムを消していたらごめんなさい。
ありえるえりあのコメントを書くときのCAPTCHAは、人間には解析が難しいのに(かなりわかりづらい)、スパムのロボットには簡単に抜けられるのですから始末に終えません。
メールは、スパムのためにシステムとして終わっていると感じていますが、blogも終わったかもしれません。
と言いながら、メールもblogも続けていますが。
世間から周回遅れですが事情によりWebSocketのことを調べてみました。
まだプロトコルとして枯れていません。
プロトコル仕様の日本語訳もありますが情報が古いので最新版と互換性がありません。
情報がいつまで有効かは不明なので読むときは気をつけてください。
昔、なんでもHTTPという風潮が嫌いでした。
通信プロトコルは適材適所であるべきだと思ったからです。
HTTPに向いていない用途にまで無理矢理HTTPでラップするのが嫌いでした。
いつしか、まあいいかHTTPで、と思うようになりました。
文字コードはUTF8でいいか、と思い始めた時と同じ時期かもしれません。
多様性は善というお題目を素直に信じられなくなった頃です。
とは言え、HTTPでプッシュ技術をするためにlong pollingをするのはいかがなものか、と思う程度の良識は持ち合わせています。
別にlong pollingを全否定したいわけではありません。
ハックとしてはありです。
しかし、あくまでハックであって、表舞台で堂々と使う技法ではありません。
TCP上の通信プロトコルの定石はTLV(type,length,value)の三つ組によるデータ送信です。
最初に型情報、次にデータ長、最後にデータを送ります。
TCP接続を張ったままデータをだらだらと送り続けるプロトコルではこのスタイルが一般的です。
データ長を最初に送ってその長さ分のデータを送るスタイルは受信側に優しいプロトコルです。
最初にどのぐらいのデータを読めばいいかわかるのでプログラミング(特にメモリ確保)が簡単になります。
読み取りの終端処理もデータの中身をパースすることなく行えます。
ただし、送信側は、データの全長がわかるまで送信を開始できない欠点があります。
ちなみに、HTTP1.1では、全長がわかる前にデータ送信したい要求のためにChunked Transfer Codingを使えます。
WebSocketの一般的なデータ送信は0x00で始まり0xffで終端するUTF8文字列です。
一見、TLVっぽくありません。
ただ、プロトコル上はTLVです。
0x00はUTF8(0xff終端)のデータ型(frame type)を示すバイトという扱いです。
先頭バイトのhigh-orderビットが立っている場合、後続に長さ情報が続くframe typeを意味します。
high-orderビットが立っているバイトが続く限り、それらはデータ長を示します。
データ長を示すバイト(high-orderビットを除く7ビットずつ)の終端はhigh-orderビットの立たないバイトです。
データ長の後にはデータが続きます。
受信側はデータ長だけバイト列を読み込みます。
プロトコル上、ただのバイト列なのでバイナリデータも送れます。
通常用途では0x00(frame type)でUTF8文字列を送ることが多いと思います。
文字列のフォーマットはJSONが良いでしょう。
JSONであれば型情報も含めて構造データを送受信できるからです。
これは一体何なんでしょうか?
普通のchallenge-responseは共有する秘密情報(普通はユーザのパスワード)を使って認証をします。
WebSocketのchallenge-responseにそんなものはありません。
処理はムダに複雑です(空白の数を数えるとか)。
アルゴリズム的に計算量が爆発するという意味での複雑さには意味がありますが、単に計算が面倒という意味の複雑さはセキュリティ的な強度には無関係です。
手作業の計算がいくら面倒だろうと、計算するコードを書いてしまえばおしまいだからです。
結局、これは何を守っているのでしょう。
社会ルールと書いていますが、国のルールでも会社内のルールでも学校内のルールでも何でもよく、ある種のコミュニティにおけるルールの総称としての「社会ルール」と思ってください。
とかくルールと言うと合理性に欠けると思えるものが世の中には多くあります。
考えた人間が頭が悪いのか、あるいは何かの悪意で制定されたのか、あるいは作られた時から現実が変化したのにルールが追随せず形骸化したのか、等々、邪推をしたくなるほど変なルールが満ちあふれています。
一部には前記の邪推に当たるルールもあるかもしれません。
しかし、一定規模の集団に適用するルールは、それ単体での合理性を考えるだけでは不十分です。
運用の経済合理性も一緒に考えるべきだからです。
たとえば、集団内にグループAとグループBがあったとします。
グループAの人には意味があってグループBの人には意味のないルールがあったとします。
ルールの合理性だけを考えるとグループAの人にだけ適用して、グループBの人には適用すべきではありません。
ただこうするとルールの運用時に適用するか否かの条件判定が必要になります。
この条件判定のコストが高い場合、全員に同じルールを適用するのはひとつの合理的判断です。
条件判定自体が面倒という側面もありますが、条件判定が増えるとエラーが増えるという事実もコストに効きます。
エラーが起きうることにはエラー処理が必要です。
エラー予防のためにルール制定、と言い出すと泥沼です。
集団の規模が拡大するとグループA,B,C,...と分類数も増えますし、分類の基準も増える傾向にあります。
それぞれに条件判定を入れていくと条件判定のコストも上がります。
いくつかまとめて同じルールを適用した場合との経済合理性を考慮して、特定の人たちには意味がないけど同じルールを守ってもらう、ということが多々あります。
こうして、個々の人を取り出してみると、非合理、非効率、無意味、理不尽なルールが押し付けられたりします。
似たような話はプログラミングの世界にもあります。
何と呼んでもいいですが、ここでは抽象化層と呼ぶことにします。
抽象化層を通すことで、呼び出し時に余計な手間が増えたり、実行効率が悪くなることは多々あります。
個別に取り出すと、抽象化層をすっとばした方が速くていいと思えるような時もあります。
しかし、全体を見ることなく各論で思いつくままに抽象化層に穴を開けていくとプログラムは崩壊します。
ここで話を終わらせると、ああ、かつては非合理なルールなんて片っ端から変えてしまえと過激な発言をしていた(本当はしていないけど)アリエルCTOも、理不尽に見えるルールも受け入れろと大人の発言をするようになったものだ、と思われるかもしれません。
で、話は終わりません。
プログラミングで抽象化層の設計は実に難しい点です。
どういう切り口でどういう粒度で設計するかがプログラミングそのものと言えるぐらいです。
抽象化層という言葉がピンとこなければ、API設計でもクラス設計でもモジュール設計でも何と呼んでも構いません。
呼び出しの手間(ルールで言えば運用の経済合理性)と効率性(ルールで言えばルール自体の合理性)のバランスを取るのは本当に難しいのです(少なくともある一定以上の複雑さのあるソフトウェアでは)。
どれぐらい難しいかと言うと、誰がやっても最初から完璧にはできない、と断言できるぐらいの難しさです。
抽象化層は時間とともに分厚くなるのが世の常です。
各論で見れば非効率になりがちです。
非効率だけならまだマシな方で予期せぬ副作用が起きるようになると事態の悪化は止まりません。
社会ルールも分厚くなりがちです。
時間とともに合理性(運用の経済合理性も含めた合理性)を失うこともあります。
プログラムと同じでルールがおかしければ正すべきです。
運用の経済合理性は見えにくいので、正すのは容易ではありません。
でも最適解を考え続けようと思います。
私が考えるのを諦めた時、面倒なので全員同じ適用でいい、理不尽でもみんな受け入れればいい、と考えるユニフォーム論者になる時です。
あまり歴史を深く勉強する質ではありませんが、歴史書の多くは栄華がいかに脆いものかを教えてくれます。
どんな文明も最初は何もありません。運が良ければ、帝国に繁栄が訪れることがあります。
歴史書の多くで、帝国の終焉のきっかけは小さなことから始まります。
何もなかった時代や帝国以前の記憶が風化して、まるでその繁栄が最初から空気のように与えられると考えられ、その繁栄は永遠であるかのように勘違いするところから始まります。
部分的にはフィクションもあるかもしれませんが、何か示唆的なものはあるのでしょう。
その点、ビル・ゲイツは偉大でした。合掌。あ、まだ死んでないか。