「数値的なホスト名を getaddrinfo に渡した場合には ai_canonname はセットされないのが仕様であるように見える」んですか。実はそれを確認するのが恐くてFreeBSDのソースに当たれないでいるのです。
とすると、RubyのSocket#gethostbynameのような、通常のホスト名からも数値的なホスト名からも、 区別なくホスト情報を得たい場合にはどうするのが正統なんでしょうねえ、FreeBSDにおいて。
素直にgethostbyname(3)を使うのはsocket.cにあるitojunさんがIPv6対応した時の
/* * NOTE: using gethostbyname() against AF_INET6 is a bad idea, as it * does not initialize sin_flowinfo nor sin_scope_id properly. */
というコメントを見る限り避けた方が良さそうな気がするし。
NokiaがケータイにPerlを載せてしまおうと計画しているという話。
組み込みにはPythonかLuaくらいがせいぜいと考えていたのだが、Perlが載るならなんだって載るぞ。 それこそRubyでも。
「getnaminfo(3)を使えば良いのでは?」というツッコミをもらったが、 私がやりたいのは別に逆引きがやりたいわけではないのだが。 繰り返しになるが、私がしたいのは、 「通常のホスト名からも数値的なホスト名からも、区別なくホスト情報(hostent)を得たい」ことである。 これくらいgetaddrinfo(3)がやってくれてもバチは当たらないと思うんだけどなあ。
これをgetnameinfo(3)を使って実現するためにはどうすればよいのは私にはいまいちわからない。 どういう手順を想定しているのかな。
「それを現状に甘んじているから搾取されるんだ。」とありますが、このあたりについて声を上げられるかどうかは当人の資質もあるんでなんとも言えない気も…。 今いる会社を離れて果たして食っていけるか？ということを気にする人も（たぶん）多いでしょうし、自分の資質や市場価値を過小評価している人も多い気がするんですが（汗）。 クチをあけてまってるだけの人は放置してOKだと思うんですが、自分の存在証明（そして価値証明）を何らかの形で実施している人のところには、そういう向きの会社が積極的にアプローチしてもよいと思います。
まあ気持ちはわかるんですが、
ことを考えると、最初の一歩を踏み出すのは本人以外にはあり得ないように思います。 結果的に「現状に甘んじている」人を第三者が助けることはできないでしょう。
はっきり言えば、 オープンソース技術者は、ヘッドハンティングしなければならないほどには売手市場ではない現実を考えると、 「そういう向きの会社からの積極的にアプローチ」を期待するのは、 現時点では「クチをあけてまってるだけ」とほぼ同じだと思います。
GuidoのBlog、第4段。
「Redux」は(後置して)「帰ってきた」という意味だから、訳すと 『帰ってきたPythonのオプショナルタイプチェック』というところだろうか。
要旨は、以下の通り。
Pythonの型指定の新文法
def foo(a: t1, b: t2) -> t3: "your code here"の意味を
def foo__(a, b): # The original function "your code here" def foo(a, b): # Typechecking wrapper a = __typecheck__(a, t1) b = __typecheck__(b, t2) r = foo__(a, b) r = __typecheck__(r, t3) return rにしてはどうか。この場合、__typecheck__()はモジュール作者が自分で定義できる。
うーん、第一弾、 第二弾に比べて、 ずいぶんおとなしくなってしまった感はぬぐえない。
なんか、がっかり。
特に良くないと思うのは、「新文法」の持つ「意味」が、 __typecheck__()関数の定義によってさまざまに変化することだ。 あるモジュールではisinstanceof()チェックが行われ、 別のモジュールではまったく同じ外見でadapt()が行われ、 また別のモジュールではsignatureによるDuckTypingチェックが行われるかもしれない。
このような「多様性/柔軟性」は私の視点からは悪である。 「文法の意味は変化しちゃいけない」というのが私の信念である。
他人を批判するばかりでは生産的でない。 もし仮に将来のRubyに型チェックを導入するとしたら、 どのようなものにするか、と問われると、今すぐに具体的な答えは出ないのだが、 現在Cエクテンションが使っているようなものに近いものになるのではないだろうか。
RubyのCエクテンションでは、構造体の型が一致している必要があるため、 DuckTypingではすまないケースが多々ある。そのような場合、
という手順で型チェックを行っている。RubyでTypeErrorを見かけるのはだいたいこのような状況である。 ところがRubyレベルでは(DuckTypingが容易なので)このような仕組みがないので、 型の違いはメソッドがない(NoMethodError)によって検出される。 この辺を統一する「なにか」がほしいなあ、とはずっと思っているのだ。
具体的なアイディアはないんだけど。
ソフトウェア開発の生産性の話。
しかし、不思議なことにソフトウェア産業では、この「怠け者」に一人前の報酬を支払っていることが多い。場合によっては「怠け者」の言い分を真に受けて、「怠け者」の方が報酬が多くなることもある。なぜなら、他の人より長時間働くことになり残業手当が多くなるからである。この業界を知らない人にとっては信じられないことかもしれないが、これは事実である。
そうそう。時間で働くのは間違っているよね。 だから、8年前、うちの会社ができる時、 「残業手当はなしにしましょう」と提案した。 おかげでうちの会社は今でも残業手当がない(正確には「みなし残業手当て」が全員に支給されている)。 おまけに完全裁量労働制だから、仕事をこなしている限り、 何時間働こうが自由である。厳密には労働基準法がどうこうとかあるけど、 少なくとも運用上は完全に自由である。
じゃあ、従業員は怠けるか、というとそうでもなくて、 むしろ一生懸命働いている。時には私生活まで犠牲にして。 かえって上司が止めないといけないくらい。
つまり、本当のプログラマは面白い仕事には寝食を(忘れて)没頭するということなのだろう。 良い環境と良い仕事を提供することこそが鍵であると思う。
共有可能なTodoを実現するWebアプリケーション。 まだ使ってないんだが、便利だという声も聞く。
しかし、もっと驚くべきことはRubyOnRailsを使って実装された、 このWebアプリケーションは、わずか579行しかないという点だ。
ちょっとRails勉強してみようかなあ。
「オブジェクト指向神話」という言葉があるらしい。 こことか、 こことかで見受けられる。
要するに「オブジェクト指向は万能ではない」 または「適材適所」という話なので、一般論としては異論はない。 私がいくらオブジェクト指向プログラミングの長年のファンだからといって、 「万能」だとか「魔法の薬」、「銀の弾丸」のようになんでも解決すると主張するつもりはない。
だが、実際にこれらのブログエントリにおいて 「オブジェクト指向に向いていない」とされているのはなんなのだろうか。
読み進めているとこういう記述にぶち当たる
ふむ、「モデリング」ね。いつから「オブジェクト指向＝モデリング」になったのだろうか。 この辺が「神話」なのかな。 この日記に引用されているように、ナップザック問題を解くのに、ナップザックやら缶詰やらのクラスを作るだけでは、問題は解決しないだろう。 しかし、逆にプログラム中でナップザックやら缶詰やらを表現する「なにか」を用意しなければ、 問題を解決することはできないだろう。オブジェクト指向はその部分を支援するものであり、 それ以上ではない。
よって、これは「オブジェクト指向の問題」ではない。
では、これが「神話」と呼ばれるということは、 「オブジェクト指向で問題解決」というイメージがいまだに存在しているということなんだろう、たぶん。
実際には、オブジェクト指向プログラミングは、構造化プログラミングの「次」と 認識されるべきものだと思う(OOAやOODのことは知らんけど)。
プログラムの開発に構造化プログラミング(乱暴な言い方をするなら、gotoを使わない、データ構造を意識する、など)を導入することと、問題の解決を混同する人はいないだろう。構造化しようとしまいとプログラムが必要なことには変わりないのだ。
オブジェクト指向プログラミングもそれと同じレベルである。 (インテリジェントな)データを用意し、それを中心にプログラムを構成する。 あくまでもプログラムの構成方法だということを認識すれば、 どんな構成をするかでわかりやすさや保守しやすさ、あるいは開発効率に影響が出るにしても、 できないことができるようになるわけではないということを認識するのはそんなに苦ではないのではないか。
正直なところ、20世紀によく見かけた「オブジェクト指向幻想」はもうそろそろ収まっているのではないかと 認識していたのだが、まだ「オブジェクト指向神話」なんて表現を目にする現状では あらためて強調しておいた方が良いのかもしれない。
そして、21世紀の今、わざわざ構造化プログラミング重要と叫ぶ必要がないのと同じように 近い将来、わざわざオブジェクト指向プログラミングがどうこうと言わなくても 当たり前になるのだと思う。一部の特殊な状況を除いて。
もうとっくになっててほしかったんだけど。
言語デザイナーはもうそのことに気づいている。 だいぶ前から新しく登場する言語は(一部の例外を除いて)みんなオブジェクト指向言語だ。 この「常識」がすみずみにまで到達するのに何年掛かるだろうか。
朝一番の便で東京に移動。有楽町の適職フェア会場へ。
若干の打ち合わせの後、パネル会場に。 立ち見が出るほど人が集まっていた。恥ずかしい。
鵜飼さんはちゃんとスライドを用意してきていた。 私も(実は飛行機の中で仕上げした)スライドを持っていたのだが、 いちいちマシンを切り替えるのは難しいので 私の分を表示することは断念。
鵜飼さんのメインテーマは「深追い」。 私のは「自由」。まあ、立ち位置が近いのでわりと共通したメッセージだったように思う。
あまり「激論」とか「対決」とか「熱く語る」とかいう感じでは無かったのだが、 聴衆のお役に立てたのだろうか。
皆さんにも見せなかったスライドを公開しておく。
そういえば、前日の夜実家から電話がかかってきて、 「リクルートのイベントに出るんだって」とのことだった。 なんでも父親がネットでたまたま見つけたらしい。 リクルートのリーチ力は侮りがたし。
「対談」終了後、そのままTech総研の『我らクレイジーエンジニア主義！』の取材に。
えーと、正直、クレイジーエンジニアってのとはだいぶ違うと思って、 「私なんか取材しても面白くないですよ」とだいぶ伝えたのだが、 ライターの人を説得しきれなかったので、そのまま取材ということになってしまった。
だいたい並んでいる人がMITの石井教授とか筑波の山海先生とか、 ヒトカドの人ばかりで、私みたいな人の出番じゃないと思うんだけどなあ。 まあ、かえって読者に身近に感じてもらいやすいというのはあるかもしれない。
そのうち、載るんじゃないかと。
せっかく東京に来たので笹田くんと打ち合わせようと思ったのだが、 時間が合わずすれちがい。私たち、そういう運命なのね...。