はてなダイアリーは死んだ
はてなブログはじめたのでそっち見てね http://lyrical-logical.hatenablog.com/
お仕事を探しています 2
追記：もろもろ状況が変わって 15/12/03 現在真面目に求職中です
前職をやめて療養に専念し始めてから一年経ちました。体感として病状は軽快しているような感じがしています。そろそろ現状の病状の度合いを知りたい、知るためには実際に働いてみるしかないということで、お仕事を探しています。
暇つぶし
皆さん元気にしていますか。健康ほど大事なものはありませんよ。
病気のほうは、まあぼちぼちです。復職の目処は立っていません。あと明日ベッドが新しくなります。やったー。
ところでインターネットには様々な文書があり、暇をつぶすにはちょうど良い。
具体的にはこのような大変面白い記事があって、まあそれを読んで何か書いてみようということなのです。
2015年現在、日本国内、あるいは少なくとも日本国内のSNS界隈には、ある一定数の人数が集う【自称】「関数型コミュニティ」なるものが存在しています。
【自称】「イスラム国」が、国際社会からは国家として認められていない物騒な存在であるのと同様に、国内SNSで今特に巷で騒がしい自称「関数型コミュニティ」の言説については。国際的なプログラミング界隈の言説とはまったく異なる特異な主張であることに十分に留意しておく必要があります。
qiita の件に関わった人間のうち、「関数型コミュニティ」に属していると主張する人間も、また彼らの誰かをそれに属していると主張する人間も、知る限りでは存在しなかった。個々人を知らない第三者が、まとめて「関数型コミュニティ」のような表現で関わった人間を括った、ということはあったかもしれない。
このようなレッテル貼りは典型的な詭弁であり問題である。それが ISIL のような問題のある集まりに属している、などというものならば、なおさらである。
自分たちの私見や独自見解、あるいは単なるより好みの「特異な主張」こそが正しく、その意向に沿わない見解、主張、意見を封じようと試みる行為が正当化されて当然という風潮が醸成されると、これはもう言語道断です。
qiita の件に関わった人間の多くは、私見や独自解釈の主張ではなく、岡部氏の記事に含まれていた誤りの指摘を行おうとしていた。間違った知識、知見が広まることを、各位が恐れたためである。結果として、住井先生がこのような記事を書くことになったのも、前述のようなことを未然に防ごうという目的あってのことと思われる。ちなみに住井先生は既に様々な文書をウェブで公開されており…まあ有体にいって泣ける。
そしてこれが今、日本国内の関数型プログラミングの言論界隈で起こっていることです。
【自称】関数型コミュニティの横暴な振る舞いによって、関数型プログラミングに取り組む数多くの識者、学習者、初心者は、恐れおののき、この辺のトピックについては腫れ物に触るように口を閉ざしてしまいました。
確かに初学者にとって、様々な関数型言語ないしプログラミングのコミュニティに対するイメージは、難しそう、モナド、なんかヤバイ、そういったアレがあるが、まあ昔からのことであるし、昔に比べればよい書籍も増えた。いい時代になったものですね…この記事はそもそも発売前に記述しているのだが間違いがあると困るのでいちおう断っておくと、岡部氏の書籍のことではない。
兎も角、「口を閉ざす」という観測しようもないことを、事実であるかのように主張するのは妥当とはいえない。何やらメールがあったということですが、それをもってサイレントマジョリティがどうみたいな話を始めるのも下らないので、割愛する。
ここで「一般的」な国際的な論調と異なる、日本国内の【自称】関数型コミュニティによる独特な特徴とは以下のようなものです。
1. オブジェクト指向に傾倒しており、関数型プログラミングとオブジェクト指向を「マルチパラダイム」というように差異を曖昧にすることでパラダイムの違いを処理し、そもそものパラダイムの差異については認めようとしない。より好みを正当化するために根底の世界観の差異を曖昧にしようとする。
2. 関数型プログラミングの根幹である、宣言的プログラミングでなく、命令形プログラミングに何故か執着している。
3. 関数型プログラミングの根幹である、宣言的プログラミングと不可分である「遅延評価」でなく「先行評価」のほうを何故か好む。
前述したように「関数型コミュニティ」と呼ばれるようなコミュニティは存在しない。仮に qiita の件に関わった人間の大多数と置き換えても、上記のような事実はない。それを示すことは、関わった人間がそれぞれにそれぞれの考えを持っているため、非常に難しいが、まあ何を書いたところで岡部氏は読解力がないか、理解するつもりがないか、まあなんにせよ個人攻撃だ！といったレッテル貼りを行うと思うので、省かせていただく。ちなみに前述の岡部氏に対する主張は個人攻撃である。氏はその精神に何らかの問題を抱えており、病院で適切な診断と治療を受けるべきだというのが私の見解であり、これは今後も曲げることはない。
しばらく特に引用することもない文字列が並ぶので省略。
関数型言語は宣言型であり、宣言型ならば、当然遅延評価がデフォルトであるべきである（事実Haskellはそうなっている）という常識を信じることはいけないということなのでしょうか？
Haskell の開発者の一人である SPJ によれば "The next Haskell will be strict, but still pure." とのことです。本気半分ジョーク半分って感じだと思いますが。そも Haskell こそが関数型言語であるというような言説は、それこそ初学者に対し適切ではない…
デフォルトで遅延評価で、完全に宣言型のコードになるのは、それ相応の理由があってのことです。
これはそんなに自明でなくそこそこ難しいことだと認識しているのですが、是非説明していただきたいですね。
まず、マイクロソフトのサイトから見てみましょう。
飽きたので以上です。
上記の文書には特に価値がなく、暇つぶしであり、兎に角ボクは岡部氏に早く病院に行って欲しいと思っている。以上です。
ところで open recursion で検索するとボクが書いた記事がひっかかるのは、あってはならないことだと思うので、誰かなんか書いて下さい。
久しぶりにコード読んだりした記
chrome 拡張で提供されている notifications api の create メソッドに渡す dictionary には iconUrl という項目があり、以前は空文字列でも問題なく動いていたのですが、いつの間にやらエラーが出てしかられるようになってしまいました。
どの変更でそういう仕様に変わったのか調べていたのですが、疲れたので皆さんの宿題とします。プログラマって大変だなあ…？
それは兎も角そういう大事なことはコメントじゃなくてドキュメントに書け。
一つ前の記事見て、お仕事やめて療養初めてから三ヶ月以上たったんだなあとぼんやり思いました。特に良くも悪くもなっていません。最近は ADSL 回線が少し天気が優れないとかだけで物凄い頻度で切断されまくるおかげで、とてもストレスフルな生活を送っています。あまりにも腹立たしいのでアンドロイドさんの WiFi はオフになってしまった。今後引っ越す可能性も若干あるので今更 FTTH に乗り換えというのも難しいし、なんともかんとも。
まあなんというか、今まで色々あったのにプログラミング未だにそんなに嫌いになってないし、人間学習しないもんだなあと思いました。早く病気治して社会復帰したいですね。
何書いたらいいか分からなくてつらい
この記事はつらぽよ Advent Calendar の二日目の記事です。おくすり Advent Calendar じゃないよ。
先週月曜から一週間以上体調が悪い日が続いていて、二日遅れてしまいました。三日目の人も書いてないみたいなので、まあいいかなあ…と思っています。今日は比較的元気なほうなので頑張って書きます。なんとかプラスプラスのアドベントカレンダーにはもう一年以上書いていない人もいるらしいし。
頸肩腕症候群については、既に一年程前に求職活動をするにあたって、病気についての理解を得るために記事を書いていますのでそちらを参照してください。（唐突に病名が出てきますがこれ書き始めはタイトル「頸肩腕症候群の病状と具体的な事例について」だったんですよ）
カレンダーに登録したときは、今年あった具体的なつらぽよを列挙する感じにしようと思っていたのですが、何か日々がつらぽよ過ぎて忘れちゃってるんですよねえ…まあ忘れられるから生きていけるのかも知れませんね。つらぽよ。
まずこちらをごらんいただきたい。見てて辛くなりますね。うーん、なんか本当につらいな…
何書けばいいんだ。何書いても不幸自慢にしかならない感じがする。つらぽよ。
あー。
まあ今も両腕痛いです。原稿も仕事もあるのに、なんでこんな記事書かないといけないんだ。普段は右腕、というか右半身が痛くなることはそんなにないのですが、今日は早くに目が覚めてしまって、ダンボールでも片付けようかなあと思ってしまった結果、大きいダンボール持ち上げようとしたときに倒れそうになって、壁におもいきり右腕をついてしまったので、それで痛いのです。この類の痛みは安静にしていれば直に治まることが分かっているので、精神的つらぽよ感はあんまりなくて、単に痛いだけですね。単に痛いだけ、みたいな表現が出てくることが辛い感じしますね。つらぽよ。
寝てろっていわれそうですが病人だって暇なときにゲームやったり漫画読んだりぐらいはしたい。寝てるのが一番体にはいいことぐらい分かっているわけですが、退屈は精神を蝕んでいくので実際よくないですよ。それで友人が「遊び相手欲しいーーーー」っていうので 3DS のモンスターハンターを購入しました。健常者には絶対伝わらないと思いますが、3DS って重いんですよね。遊んでるとプレイヤーの腕が部位破壊されます。つらぽよ。体調悪かったりでしばらく遊んでないうちに、友人皆やりこんでてついていけない感じになってるのでもうやらないと思います。買うんじゃなかった。つらぽよ。ところであのゲームボイスチャットなしでやるの無理だと思う。
あとお金ないですねお金。お金ないです。全くない。ほんとモンハンとか買うんじゃなかった。ボクの予想ではもっと早くにお金なくなるだろうなあと思っていたのですが、外出する機会が減りまくってる分、お金使う機会も減ってるんですね…つらぽよ。その割には今月のカードの引き落とし額が五万とかになってて、いやいやいやまてまてまて…と困惑することがあったんですが、この前転んだ拍子に眼鏡のフレーム折っちゃって、フレーム取り寄せてもらったりレンズもついでに換えてもらったりしたのに三万程かかったのでした。つらぽよ。あと割りと日常的に転んでます。これは引きこもり寝たきり生活が長く続いていて、筋力体力が落ちてることも関係している気がします。でも運動とかすると体調悪くなるので運動できない。つらぽよ。
十月くらいに一度体調が好転したことがありました。痛みもほとんどおさまって、若干の痺れがあるくらいでした。このまま治ってくれないかなあと淡い期待を抱いていたのですが、その後台風が連続でやってきて、圧倒的低気圧コンボでボクの体をボッコボコにしていきました。つらぽよ。あれなんだったんだろうなあ…あの頃に戻りたい…
あーーー無限につら案件が沸いてくる。もう腕痛いしここで終わろうか。一年前は職を探してましたが、今度は看病してくれる人を探したい。冗談ですけど…体調悪い日は本当に一人では人間的な生活ができないのは事実ですね。つらぽよ。
大体なーにがぽよだ、馬鹿にして…
16 時から仕事なのでそれまで横になってます。そもそもお前なんでそんな状態なのに仕事なんてしてるんだって言われそうですが、まあ色々あるんです。人生色々だよ。ありていにいうと実家に帰りづらくかつお金がない。
お金欲しい。看病してくれる美少女も募集しています。
疲れた。もういいですか。そうですか。おわり。
MultiStateTarget と getState の罠
sikuli という大変便利なライブラリがあります。なんか画像認識とかしてくれます。java 用の api もあります、やったね。
「複数の Target のうち何かひとつ見つかればいいな」みたいなときには MultiStateTarget を使います。何が見つかったかは通常 getState で判別するわけなんですが。
getState の実装は、その名前からは全くかけ離れたものになっていて、「見つかった ScreenRegion の中で、複数の Target をもう一度 find しなおして、一番 score の良かった Target の状態を返す」という実装になっています。get とかいいつつなんかするのはよせ…。
そりゃまあ名前のとおり ScreenRegion はただの範囲であって、ある瞬間の状態をあらわすものじゃないわけですから、順当といえば順当です。
しかし MultiStateTarget を使っている時は、基本的には find した結果何が見つかったのか、が知りたいわけです。find してから getState するまでの間に、ScreenRegion 内に動きがあると、find したときに最も score の良かった Target とは違う Target の score が良くなってるかもしれない。厳密に何が見つかったかを判別してやるには、ある瞬間の状態を表すものとして、ScreenRegion の capture を呼び出してやる必要があるわけです。はて…
一番の問題は「見つかった ScreenRegion の中で find し直す」という部分です。登録されている、たとえば ImageTarget の画像サイズがそれぞれ異なっており、運悪く小さい画像が見つかった場合には、小さい ScreenRegion の中で大きな ImageTarget を見つけようとして、「opencv のレイヤで」ROI がおかしいぞ、としかられます。酷い。上述のリンク先のコードが動いているのは、たまたま大きいほうの画像が見つかったからで、locked.jpg が見つかっていたら getState の呼び出しで例外が飛ばされるはずです。酷すぎ。これは Target に大きさを持たないものがあることによる実装上の都合…ではなく、普通にバグだと思います。
追記：見つかった ROI を少し大きくする dirty な処理が書いてあったので、locked.jpg の場合は見つかってても動くかもしれません…なんにせよ酷い話ですね。
素直に ScreenRegion と一緒に、見つかった（score の良かった）Target の状態も返すような API があればとも思うのですが、ないです。残念でしたね。
addStateChangeEventListener 使えということなのかなあ。実行コンテキストの不明確なコールバックだらけのコードなんて書きたくないんですけど（現在の実装だと別スレッドでなんか一元管理されてます）…というか find, wait 使ってたコード回り全部書き直しになっちゃうしなあ…
まともな wrapper を書きたいものですが、病人なので我慢します。疲れました。
