* 日々のメモ2012

あけましておめでとうございます。

一昨年から昨年と、個人的ないくつかのことについて(例えば 気力・体力・実力の)「ギアがかみ合っていない」状態が続いており、厳しい状態です。
まだしばらくは混乱もあるかと思いますが、ひとつひとつ問題の解消に取り組んでいます。
苦しいときが伸びているときだと信じて、また自信は努力から生まれると信じて、コツコツとやっていきます。

よろしくお願いします。

龍のイラストでも描こうかとおもいましたが、絵心もないので、控えめに

6 2 3 小パンチ

この辺でどうでしょうか。

龍のイラストっていうか落書きしました。
今年もよろしくお願いします。

---

勢いで去年の干支のうさぎも描いてみました。
1年間ありがとう。

全く関係ないですが、ピーターラビットの著作権が切れたそうですね。
私はネズミどしなのですが例のネズミはまだ切れてないらしいです。ハハッ

---

全く別の話。
未整理なのですが、以下3つの話題に触れて、改めて思うことがありました。

(1)「言霊」
年始に池上彰さんの現代史の講義の番組を少し見ました。大変面白かった。その中で、「日本には言霊信仰の概念がある」という言葉がありました。(以下池上さんの話は、言霊信仰の概念、つまり悪い予想をクチにするとそのとおりになってしまうため縁起の悪い言葉を口にするべきでない、などという考え方があるが、原発の故障予想等にはそんな概念をもちだすべきでない、と続きましたがそれは私にとっては別の話)

日本人は昔から、言葉には霊が宿ると考えるほど、言葉を大事にしてきたのです。

(2)「ツイッターの日本語シェア」
年末にジブリの映画「天空の城ラピュタ」が地上波で放送されましたが、その際、有名な、城を破滅させる呪文を唱える台詞「バルス」を、たくさんのひとがツイッター上で映画と同時につぶやく、という「祭り現象」が起きました。また、日本のインターネット上では、年の切り替えのときに「あけおめ」(short for あけましておめでとうございます)「ことよろ」(short for ことしもよろしくおねがいします)を、友達同士で電信し、回線の通信性能やサーバ性能を上回る通信量となってトラブルとなる、という現象が起きます。
それら話題の中で、「ツイッターの通信のうち、相当な量を日本語が占めている」という話題を聞きました。

→Twitterのツイートの半分が英語―英語以外では日本語がトップで14%

日本語の、電気通信上のシェアは割合に高いということです。

(3)「読めるけど、マジ漢字書けない」
「ダンス☆マン」というファンクミュージシャンの方がいます（→wikipedia:ダンス☆マン）。彼の曲で、「読めるけど書けない漢字」をテーマにした曲があります。RAY PARKER JR. & RAYDIO の曲をアレンジした、ノリよく、楽しい曲です。そうそう、読めるけど書けないよね、などと思っていたところで、Wikipediaで「失読症」のページを読んだところ、興味深い記述がありました。

→ wikipedia:ディスレクシア

以下引用

読むことはできるが書くことはできない（「薔薇」は「バラ」と、「憂鬱・憂欝」は「ゆううつ」と読むことができるが書けないことなど）は、一般的な言語学習段階上の経験として覚えのある向きもあろう。ただ、これを学習障害の一種とするかは、日本語においては見解が分かれている。

人間が日本語や漢字を認識するメカニズムは、英語に対するそれとは根本的な違いがあるかもしれない、のです。


これらを聞いて、ますます思ったのは、日本人なら日本語でコンピュータを扱おう、日本語プログラミングをしよう、ということです。ことさらに、研究分野等でなく、ITドカタと揶揄されるぼくら末端のシステム開発現場では、です。

+ 日本語コーディングしようぜ

上記ページ、私の持論です。初出に対して、末尾に追記などしています。ご拝読お読みいただけるとうれしいです。

訂正：丁寧語だとおもってたら、謙譲語で、使い方間違ってました。お恥ずかしい。

意匠というか、マークというか、模様のデザインに興味を持った時期があり、自分の家には家紋があるのか、と両親に聞いたところ、

三つ剣菱だよ

と聞かされていたのですが、実物を今日見せてもらいました。すると...



うーむ。こりゃ多分、

丸に剣三つ星

ではないか？

「夢をかなえる３つのア」
という、私の大好きな言葉があります。

あせらない、あわてない、あきらめない

夢をかなえるだけじゃなくていろんな場面に当てはまると思います。
何度も自分に言い聞かせています。

武道の必修化、いいじゃないですか。
戦後、アメリカの占領政策で武道の稽古が禁止され、「これは健康体操であって武道ではない」なんて言って必死に自国の文化を守ったところから、やっとここまでたどり着いたのかと思いますよ。

私の出身高校の校長、田村氏は、私達によく言っていました。「国際化時代である今こそ、国際浪人になるな。国際人になれ」と。国際浪人とは、自国人のアイデンティティを身に付けぬまま海外へ出て行き、一体何処の国の人間なのか分からない人物だそうです。
海外(日本)に出て自国の事を尋ねられ、答えられなかった事をきっかけに、日本で自国の事を勉強している、という留学生のスピーチを聞いたことがあります。あり得る話だと思います。
日本人が、剣道、弓道、柔術(柔道)、合気道、空手道など、日本の武道を学ぶのは良いことだと思います。

以前、自衛隊関係のシステムの仕事で市ヶ谷にて作業した事がありますが、そのとき驚いたと同時に感動した事があります。
それは、自衛隊の高級職の方々が、実務は事務職なのに、毎週、あるいは毎月、決められた時間の運動を懸命に消化されていた事です。
彼等は体力の維持が仕事の一部なのです。もちろん、忙しい中で時間を作り出して運動をするのです。
教員に、生涯運動実践の手本となることを求めるのは良いことだと思います。ただし教員も人間ですから、その時間を正規の就業時間として加算してあげないと、倒れてしまうでしょう。

武道の世界では上には上がいるので、そこいらの中学校教員が習っても、到底「センセイ」にはなれないでしょう。それがいいと思います。職場の同僚をセンセイと呼び合う異常な環境では、感覚が世間の常識とずれてしまうこともあるでしょう。しかし教員が武道を定期的に習い、稽古すると言うことは、週に数時間、あるいは数十分は、正座して師範の言葉にじっと耳を傾ける時間を持つことになるでしょう。それが、おごりや非常識を洗ってくれると思います。

海部さんや亀井さん、ほかにも、武道の段持ちの政治家の方がおられると思いますが、私は武道必修化の方向に賛成ですので、その方向で進めて頂きたいです。

ルンバという掃除機ロボットの製品があります。
高さの低い円柱に車輪が生えていて、底面に掃除機の吸込口があります。
こいつの、掃除機なしの研究用キットが iRobotCreate という名前で販売されています。最近これをいじっていますが、なかなか面白い&奥深いです。

移動しながら周囲にある物の配置をレーザーセンサーで取得し、車輪の回転数もセンサーで取得、環境地図の作成と自己位置の推定を同時に行い、さらには移動したいゴールまでの経路を計算し、移動制御を行うと。

これはもう立派なロボットです。
ロボットというと、われわれ素人は鉄腕アトムやガンダム、あるいはホンダのアシモやソニーのアイボを想像します。そしてまだまだ夢の世界の話だと思っていたのですが、現実の生活で日常的に触れるような家電製品を見てしまうと、頭の中で夢と現実の境目が曖昧になってクラクラします。

というか本当の所はこうです。SLAMとかクォータニオンとか共分散とかエントロピーとか、むかーし昔に習ったような習わなかったような、ITドカタをやっていると耳にしないコトバがドキュメントにたくさん出てくるもんで、その言葉たちにやや怖気づいている。

歳とって頭が固くなったなぁなどと感じながら、久しぶりの変な汗をかきながら、人生はずっと勉強だと自分自身に言い聞かせながら、頑張っています。

twitterで、全然コンピュータと関係なさそうな（綺麗な女性のアイコンの）方がフォローしてくださることがあるのだが、なんのハニーポットなのだろう？と思ってしまう。

いや、ただそれだけです。とくに広がりません。


なのだけど、それだけだとあんまりなので人工無能の話を。

80年代、「これからはコンピュータの高度利用が進むぞ」と誰もが考え、人工知能の研究がはやりました。人工知能とは、俗っぽくわかりやすく言えば、人間のように賢く考えるコンピュータ、なのですが、現実にはそんなものはできなくて、どこの研究者も難儀していました。なんだけども、「チャットでかわいい女の子風の書き込みをするだけのプログラム」なんていうのは、割といい感じで作られたのです。

コンピュータ物の映画でも漫画でも、コンピュータプログラミングに熱中しているモテない男の子が、彼女のプログラムを作って、雷が落ちて女の子が実体化して... なんていう話がはやりました。あれです（余談の余談ですが初音ミクのブームにもちょっとその気配を感じます）。

で、先ほどのような「チャットで人間（特に女の子）風の書き込みをする」プログラム、通称チャットボットのことを、「人工知能ほど高度なことはしてないけど」という、自虐的なギャグのセンスをもって「人工無能」と呼んだようです。
「ようです」というのは、私もあとで、伝聞で知ったからです。実は、私はパソコン通信が流行した時代は、空手部の稽古でヘトヘトでコンピュータから離れていました。高い通信費を出してもらえる環境でもなかったし。

で、人工無能ですが、最初は出来も悪かったので、すぐにチャットボットであると見破られていたようなのですが、「分からない単語が出てきたら顔文字や嬌声でキャーキャー言ってごまかす」「機嫌を損ねたことを装う」などという「ニセモノをそれっぽく見せる」ための技が、あさっての方向へ高度に進化していった結果、真面目にチャットボットの女の子に好意を持って、口説き始めてしまう者が現れたとのこと。
そんな可哀想な男の子を、当初はおもしろおかしく観察していた側も、それはあんまりだとなって、ボットは行頭に#など決まった記号をつける、など、自治ルールを決めていったりしたとか。

そんな人工無能について、真面目な考察をじっくり読めるサイトが以下です。

リンク	備考
人工無能は考える

このサイト、おもしろい、というか大変興味深いのですが、ちょこっとだけ読み流すにはボリュームが多いので、休日に心して読んでいく必要があります。


まとめると、「ツイッターで、綺麗な女の子風だけど、実在の人物なのかちょっと怪しい感じのアカウントからフォローがあった」それで「人工無能のサイトを思い出した」ということでした。

おしまい。

---

2012/1/25 追記

やっぱりbotだった。
あーあ。

弱音を吐いて独り言を書いてみるテスト。武道の話。


ここの技を習いたい！と思ってしばらく教わった合気道の道場があるのですが、稽古日が平日のみであり、仕事の状況(勤務場所や勤務時間、勤務形態)が様変わりしたことから、このところカナーリさぼっています。
これではいかん、と思って家に近いところで合気道を稽古しているところを探したところ、キノケン(気の研究会)系の道場を発見。一度見学に行きたいですが、はて。

この十数年、仕事現場や住むところがコロコロ変わり、そのたびに道場を変えていたところ、どこの系統の技も中途半端になってしまっています。合気道は、流派間の仲はいいのですが、やはり技は相当違います。
新宿の本部白帯クラス → 東北系(のガッチリ系)道場 → 茨城パワー系と本部流動系の統合された近代系道場 → 戦前の合気道を幹として剣道・居合・空手(和同流)も修めた先生の現代武道系の道場 と、あっちへこっちへフラフラしてきました。そしてまたサボり中。その結果、まだ白帯。

これからまた系統の違う道場に通うのはやめたほうがいい気もします。んでも何もせず腐っているより、とにかくやらないと、という思いもあります。

しかし考えてみれば、中学では「科学部」というオタクの巣窟に所属したもやしっ子の私が、高校に入ってから始めた空手で、2年で黒帯を取れたのは奇跡だったのかもしれない。
そんな私でも、現役のときはそれなりに体も動いていましたし、団体型では県で常勝でした。得意型は雲手でした。雲手、当時と今とでは、緩急と立ち方が大きく変わった部分があります。最北から南東に向かって下段の受けをする部分。まぁ、だからどうした、なんですが。
南関東で、道着の袖を内側に折るか外側に折るかの違いで、最低点0.1点で負けて全国に行けなかったことを今でも思い出します。
「そんな些細なことで負けて悔しがるくらいなら、圧倒的に稽古して圧倒的に強くなり、圧倒的に勝てばいいのだ」とは恩師のお言葉。はい。そうです。うう。いつもそこまで記憶をリプレイして苦しくなるのが1セット。
武道を習って、つくづく「日本の社会とは武道の段持ちがうようよいる、怖い世界であることだよ」などと思いました。


帯ギュの準ヒロイン(?)で、くるままり さんというキャラクターがいます。漢字が違うのですが、名字が同じことからすごく親近感があって、好きでした(#@_@#)。しかし彼女は強い。とても強い。私は型の点数はそこそこ良かったものの、組み手ヨワヨワの根性なしだったので、すごく遠い世界の人物でした。
帯ギュは、私が全巻をそろえて再読三読した漫画の一つです。ほかに全巻そろえたのはAKIRAとナウシカ。引越しのときに処分してしまいましたが、また読みたいなぁ。ストーリーでは粉川と斉藤が反目するあたりが好きでした。身に覚えがあるような無い様な話なので。

あと、武士道エイティーンが、そろそろ文庫化されると予想して、待ち構えています。早く読みたい。


実は空手部の同期が一人、若くして亡くなっています。ときどき不安で仕方なくなります。私はアイツに恥ずかしくない生き方が出来ているだろうか。数十年後にまた会ったとき、笑って話を聞いてもらえるようなネタを仕込めているだろうか。ツマンナイやつ、と思われてしまうのではないか。


今日は酒を全く飲んでいないのに、酔っ払っているようで、なんだか気分が妙です。
明日はまた仕事、頑張りましょう。

仕事場で、ロボットの車輪がよく外れてコケてました。

結論から言うと、車輪のつけ方が間違っていました。そうです、私のバグだゴルァ


なんですが、

• 正しい方向に車輪をつけて、
• かつ、簡単に外れないようにゴムシートを加工して貼り付け、
• さらに、そのゴムシートに赤ペンで

挫折禁止

と書いておまじないとしました。

もうコケるんじゃないぞ。


でも、それでもお前が倒れそうになったときは、オレがそばにいて支えてやるぜ。(キリッ

Ubuntu始めました

自宅の Linux 環境は Fedora を使うことが多いです。なぜかというと、Linux を扱う案件に就きたくて、有利となるように、そして仕事でLinuxを扱うことが多いのが RedHat(RHEL) であるので、その先取りの意味で RedHat系 の Fedora なのです。

が、今回は仕事で Ubuntu を扱っています。最近の Ubuntu の発展はすごいです。私は実は Debian 系はあまり触っていなかったのですが、「私はLinuxが得意です」と堂々と言うためには、Debian系である Ubuntu も避けられなくなってきた、ようです。

ということで、自宅でも Ubuntu を飼い始めました。
多頭飼いはそれなりに大変ですが、苦労もまた面白いものです。


でもまだ Gentoo には行かないです。えぇ、行かないですよ。

ギターの4弦て...

ちょっと悲しいことがあって、コピーノートから悲しい歌を引っ張りだして弾いていました。

で、前から薄々思ってたんだけど、ギターで歌の伴奏弾くのに、

4弦て要らないっすよね？

外してみたらなんかすがすがしい楽器になったことです。

そして自分は時々、

V7 -> I

を

V7#5 -> I

にして弾くのですが、
4弦がないギターだと、V7#5は、3ポジションで全く同じ指の形になることを発見。
(dimが4ポジションで同じ型、みたいな)

新鮮な驚きを感じたことでした。

4弦を外したギター、面白いですよ。

しっかしオイラのWACOMタブレットは、なんでGimpに認識されないんだろう。ソース見ないとだめかな…

そりゃ初期のGD型だし、シリアル接続だし、うーむ。
独立したてのころに気合入れて買ったので思い入れがあって、できるならちゃんと使いたい。
動いてるひともいるっぽいんだけどな。

最近のマザーボードってもう、DSub25ピンパラレルどころか9ピンシリアルもないんだよね…。
このタブレット買った当時、商品としてはUSB接続のものがあったんだけど、あえてシリアルにしたんだよなー。Windows95はUSB怪しかったし、Linuxでも使える確率が高いんじゃないかと期待しての選択だったんだけど、まさかUSBがこんなに幅を利かせるとは、当時思ってなかったよ。

うーん、もしかしてACアダプタじゃなくてATX電源から12Vとってるから？ちょっとアダプタ試してみよう。

突然で、全く脈絡ないですが、

私は1991年から1994年に京都産業大学に在籍したわけですが、勝矢 淳雄 先生（→このかた）の確率・統計の講義、私はとっても好きでした。先生の話し方も飄々として面白かった。

そして、教科書として使用していた小針先生の「確率・統計入門」、今でも大事に取ってあります。

勝矢先生の、あの飄々とした講義の仕方、もしかして小針先生もこんな話し方をされていたのでは？と、勝手にイメージを重ねていました。


しかし

最近ちょっと確率的な話を考えようとしたのですが、


あれ？

確率変数ってマイナス無限大からプラス無限大まで積分して1になればいいんだったよね？


と、すでにそこからあいまいになり、先の教科書を開いてみたものの、先頭数ページの「先輩がアハハと」かます部分を過ぎると、

汗がでるほど全くわからない。


やばいです。超ヤバイ。脳を使わないとどんどんバカになります。


よーっく覚えているのが、冒頭のアハハの部分と、「チェビチェフの不等式」という言葉が出てきたこと。しかしチェビチェフの不等式を今Wikipediaで見ても、あれ？こんな難しい式だった？としか...


まぁ、何がいいたかったかというと、私は勝矢先生のファンでしたよ、ということです。

竹内富士雄先生や八杉満利子先生、黒田先生ももちろんですが、あともちろん工学部の謝先生はオブジェクト指向で非常に影響を受けたし永遠の師匠です。
それから、もう京都産業にはおられないと思いますが、"「2+2」を5にする発想 " を翻訳された 上出 先生ももちろん尊敬しています。千葉県の高校生だった私が、再読・三読した本でした。直接講義を受けたこともあったのですが、成績が悪いこともあり、照れがあって、本にサインもらうことが出来ませんでした。


千葉から京都に出た理由

• 伝統のあるコンピュータの学科が、工学部や理工学部でなく理学部にある大学であること
• 受験科目に社会科がないこと
• ジョブズの伝記本を読んで、大学に行くなら実家から遠くないと意味が無いと思っていた
• 自分の成績で確実に入れる(絶対浪人しない)
• 学園祭の見学に行ったとき、バスの中で京都弁で日常会話する女の子に萌えた
• 上出先生が翻訳された本 "「2+2」を5にする発想" に、高校3年のとき非常に影響を受けた

話を戻しますと…生涯勉強、です。頑張ります。

「定時マッハ」と
「定時マッパ」では
ずいぶん意味が違います。

「子はかすがい」と
「子はタフガイ」くらい違います。

---

だれかスイートマジックの替え歌で作ってみてほしい、

マッパッパラッパマッパッパラッパ...

gumroadが話題っぽいので私もコメント。

コンテンツURLをコピペされたらオワタか？について。完全なコピペなら、gumroad側で「そのコンテンツURLは既に他のユーザが登録済みです」とブロックできるだろう。
問題は、URL末尾に無意味なGET変数を付ければ同一コンテンツを指すURLを幾らでも生成できてしまうこと。

なので、gumroadは、URLを登録するだけでなく、そのURLから得られるコンテンツ自体を比較して、同一性を検証するハメになる。
それはつまり、世界中で電信されるデータを、 gumroad 自身もダウンロードする必要があるということ。そんなトラヒックに耐えられるの？
GET変数を付けるだけでなく、全く別の場所にコピーされた場合も同様に検証が必要。コンテンツの同一性検証をやってもなお、音声ピッチを変えたり、定期的にノイズ画像を挟んで回避するヤツが出てくる。

それから、gumroadは不当な商行為に加担して告訴されるリスクをどう見積もっているのか。

さらに、議論の末、カスラックモドキが必要になってから、「だけどあれ、なんか違うかも？」と気づくかも知れない。

一瞬で消えてしまうサービスである気がするが、デジタルコンテンツの流通について、「新しい利害関係者」が次々に登場し、議論が高まるのはいい事だと思う。


ナップスターとフェイスブックの関係を思い出す。例のフェイスブックの映画の内容がどれだけ真実かは、分からないけど、ナップスターみたいに最初はつぶされるんじゃないかな。

金曜日から、外から見えない状態だった模様です。もしアクセスしてくださった人間の方がこの世におられたなら、申し訳ありませんでした。

それからいつもいつもいつもジャカジャカとアクセスしてくれる各検索エンジンのスパイダーロボット各位さま、リファラスパムロボットさまも、どうもすみませんでした。

原因はダイナミックDNSの更新不良でした。ddclient さんと dyndns.org (dyn.com) さんにはよくお願いしておきました。しばらく稼働状況に注意します。




とかまぁ冗談半分で卑屈になって書いていますが、...


今日もちょっと反省したことを書きます。



自分は昔から、ヨワい人間だ、小さい人間だと自分を卑下するクセがあります。
藍坊主の曲で

劣等感の塊がずっと、
息をしてもパンを食べても、
飲み込めないところにつまってんだ、
バケツ３杯分じゃたりないくらい

てな歌詞があります。
まさにそんな感じで、いつもいつも、過去の自分の痛い行動を思い出してはまた痛い思いをしてすごしているわけですが、今日、現場に出勤しながらふと、

自分は、自分が思ってるほど、図体も小さくないし、腕力も弱くないし、誰かに守ってもらえる立場じゃなくて、誰かを守らなければならない立場なのかもしれない

とか思ったわけです。
負け犬気質...


話がうまくつながらなくて申し訳ないのですが。



自分の駄文を /dev/null に echo してるようなこんなサイトですが、なぜか年末あたりから月間ページビューが 10万件超とかワケワカラン状態になっています。
私はそのほとんどが、検索スパイダーのアクセスであって、自分のサイトを見てくれる人間なんていやしないだろうと思っているのですが、もしかしたら、本物の人間がアクセスしてくれているのかもしれない。
仮に、もし、そうだとしたら、やはりHTTPサーバがダウンしてるっていうのは、プロトコルの責任上、まずいな、と思い至るわけです。


そして、自分を卑下するのも、いい加減にやめないといけない、のかな？
もしかしてもう「自分は弱い」と言って責任を逃れられない立場なのかな、
と、40目前のいいオッサンになって中二みたいなことで悩んでいます。

しかし実際のところ、誰か人間の方がアクセスしてくれているのでしょうか。


よく分かりません。



孤独や不安に慣れているつもりでいますが、数年ごとに、やりきれなくなって行動がおかしくなります。
そういうときに迷惑をかける、周りにいる方々には、本当に申し訳ないです。

うぐぅ…

今年の確定申告は給与があるわ、報酬の源泉徴収もあるわでややこしい…

売上も散々だし、家庭内もトラブルあるし、泣きたいよ。

ワンワン。


ま、自分が選んだ人生なので、不平を言っても仕方が無い。リスクを負う人生ってのはこういうことだ。


明日も頑張ろう。

理想のプログラミング言語についてのヨタ文書。多分、何を言いたいのか、オレにしか通じない。

でも、あさってのオレに伝わればいい。


# GCなし、コルーチン、node.js、Lindaを合体
PARA(){# GCなし、コルーチン、node.js、Lindaを合体}

リンク先を読んで感銘を受けました。

リンク	備考
自衛隊の体験入隊に行ったら大変なことになった。	東大生さんによる、togetterまとめ

"新兵にまず行う教育とは何か。
「日本は守る価値のある国である、 このことを教える。」 
そう語られた。"

"自衛隊とは何か。
警察や消防士も自衛隊と近しい職業ではある。
大きな違いは、危険な場面で警察と消防は「危ない下がれ」となる。 
自衛隊は「危ない、前へ」"

私は縁あって、守る武器のプログラムをやらせていただいたことがあります。あの仕事は、複数の意味で、私の生涯の誇りです。
実用されることがないことを祈りますが、いざと言うときにはどうか不具合なく、お役に立って欲しいと思います。

別の機会に内勤の方が使うシステムにも関わらせていただき、市ヶ谷に入場させていただいたこともありました。ひいき目かも知れませんが、食堂にいても、ランニングしていても、官の皆さんは態度がきちっとされていたという印象を持っています。

切れるけど切らない。倒せるけど倒さない。壊せるけど壊さない。手加減したことを相手に気づかせる。
古来日本の武の心はそこにあり、それを体現されているのが自衛官の方だと思っています。

私も頑張らねば。


余談ですが、市ヶ谷ラーメンおいしかったです。玉ネギの甘辛炒め＋α をしょうゆラーメンに載せたもの、と記憶していますが、どうだったでしょうか。

ROS

turtlebot

turtlebot_simulator

gazebo

Link	memo
Challenges with headless turtlebot_gazebo on remote machine	ROS answers.ros.org
ticket #132

---

I found "using variables without initialize" bug in "simulator_gazebo_plugins".
That cause the corrupted very large value of odometry {x, y}.

[problem]
When you try to use turtlebot simulator (gazebo),
sometimes the node "/gazebo" publishes the topic "/odom" with very large
initial position {x, y} like 1e+31 or so.

[cause]
In turtlebot_gazebo_plugins/src/gazebo_ros_create.cpp,
variables below are used without being initialized.

• prev_update_time
• odom_pose[0]
• odom_pose[1]
• odom_pose[2]

I know that recentry turtlebot_gazebo_plugins/src/gazebo_ros_create.cpp was patched
about NaN value (in GazeboRosCreate::UpdateChild()) .
The patch didn't fix the problem I found.

I don't know how to report bug-report and patch, so I'm glad if someone does.

[environment]

• ubuntu 11.10 32bit
• ros-electric (updated with apt-get)

[how to reproduce]
(not 100%. because that is caused with "using uninitialized variable" in C++.)

Start 3 terminals separately and type it.

$ roscore
$ roslaunch turtlebot_gazebo turtlebot_empty_world.launch
$ rostopic echo /odom

Check values of pose.pose.position.x and y.
If it shows like below, you successed to reproduce.

pose:
  pose:
    position:
      x: 1.86493744726e+31
      y: 4.86171422416e+30

[how to fix]
initialize variables.

[patch]

keizo@soi:~/ros_workspace/turtlebot_gazebo_plugins.keizo/src$ diff -c /opt/ros/electric/stacks/turtlebot_simulator/turtlebot_gazebo_plugins/src/gazebo_ros_create.cpp .
*** /opt/ros/electric/stacks/turtlebot_simulator/turtlebot_gazebo_plugins/src/gazebo_ros_create.cpp 2012-02-29 07:52:33.000000000 +0900
--- ./gazebo_ros_create.cpp 2012-03-11 22:59:59.026536682 +0900
***************
*** 153,158 ****
--- 153,159 ----
    js_.velocity.push_back(0);
    js_.effort.push_back(0);

+   prev_update_time_ = 0;
    last_cmd_vel_time_ = 0;
  }

***************
*** 172,177 ****
--- 173,184 ----
    if (joints_[FRONT]) set_joints_[FRONT] = true;
    if (joints_[REAR]) set_joints_[REAR] = true;

+   //initialize time and odometry position
+   prev_update_time_ = last_cmd_vel_time_ =
+     Simulator::Instance()->GetSimTime();
+   odom_pose_[0] = 0.0;
+   odom_pose_[1] = 0.0;
+   odom_pose_[2] = 0.0;
  }

  void GazeboRosCreate::FiniChild()

---

[ Unnecessary additional information ]
[indirect problem]
When you try to use turtlebot simulator (gazebo) and slam_gmapping,
the node slam_gmapping dies with a message "bad_alloc" exception.

[cause]
Ordinary, the initial value of odometory's {x, y} should be nearly equal to zero.
but it shows sometimes very large like 1e+31 or so.

When the node "slam_gmapping" receives that large value, it try to enlarge map too much.
And it cause a "not enough memory" situation and "bad_alloc" exception.

If you want to reproduce, you need to add "output_frame" param described blelow
to turtlebot_gazebo/launch/robot.launch .

<node pkg="robot_pose_ekf parameter" .... >
   ....
   <param name="output_frame" value="odom"/>
</node>

[comment]
I'm not good at English, I apologize about my poor English.
I hope this information helps you. and also me.

---

ROS の gazebo

タートルボットのシミュレータ(gazebo)で、トピック /odom の x, y の初期値が不正に巨大な値になっています。

マップを作成するため slam_gmapping を起動すると、オドメトリの x, y が巨大であるため、マップを拡張しようとしてたくさんのメモリを確保しようとし、bad_alloc 例外を吐いて落ちます。

原因は、turtlebot_gazebo_plugins/src/gazebo_ros_create.cpp にて、
以下の変数を未初期化で使ってるから。なんとまぁ。

• prev_update_time
• odom_pose[0]
• odom_pose[1]
• odom_pose[2]

対処は、初期化すること。

で、バグレポート出したいのですが出し方分かりませんorz...
チケット出してみました。

リンク	備考
matplotlib	Pythonで高品位の2Dプロットを行うライブラリ
IPython	matplotlibを内包するインタラクティブ計算シェル。Mathematicaみたいなことができる。

格好いい!
Mathematicaみたいっていうか、そっくり。

公式のチュートリアルがわからなかったのでYouTubeで検索したらいいのが出ました。

リンク	備考
1_getting started with ipython	YouTube

ipython -pylab

linspace?
linspace(1,100,100)
linspace(0,1,200)
p = linspace(-pi,pi,100)
len(p)
plot(p,cos(p))
clf()
plot(p,sin(p))

自分もシンプルな例を考えてみた

x = [1.1, 1.2, 1.5]
y = [2.1, 2.0, 0.5]
plot(x,y)

quit()

うむ。これはいい。

---

リンク	備考
matplotlib pyplot tutorial
matplotlib.pyplot.plot
Matplotlibサンプル集

だれかGoogle+で猫画像をブロックする方法を知りませんか？
たまにならいいけど続けてやられるとちょっとチクチクするのです。

実は:
実家で飼ってた鳥を2回も猫に殺されてるため、猫にあんまりいい印象ないのです。しかも、そのうち1回は庭に内臓がぶちまけられて、庭が血だらけで、卵になる前の器官（子宮でしょうか）が転がっていたのを鮮明に覚えていて、... ということで、自分にとって黒記憶なのです。

庭先であんな騒動が起こっていたのになぜ気付いて助けてやれなかったか、今でも痛い。

別に全ての猫が悪いわけではないのは分かるけどね。
それに自分固有の話だから、他人が「かわいいな」と思うのは別にいいです。
ブロックできるならブロックしたい。

google+ で話題になっていたサイトを見ました。

リンク	備考
良いネーミングをするために覚えておきたい英語のルール5つ	うーむ

いいエントリー...と思いたかったのだが、

最初の表からして、私にはムズカシイ。
empty が名詞とはどういう理解をすればいい？ empty は形容詞として使うことが圧倒的に多いのでは？ isEmptyとか。

1節目の本文、「一般的な英語辞書のルールでは」と英語の話を始めるように見えて、英語の search を論じていない。明らかに、日本語の サ変 を、つまり「検索」と「検索する」の違いを論じてるよね。また「一般的な英語辞書のルールでは「検索」は動詞ではありません」と言ってるのに、その下の表では search を動詞の中に入れてる。結局関数名やメソッド名をどうつけろと主張したいのかな。
彼が言いたいのはやっぱり「日本語のサ変に注意しろ」ということ？

確かに、
日本語の仕様書だと「する」を除いて体言でメソッド名とすることが多い。例:エントリ名検索。
それに英語でメソッド名つけようとしたときアレ？となる。例:直訳でEntryNameSearch とするとおかしいな、となって SearchEntryName にする、など。
それに注意して、元の日本語仕様書のメソッド名を「エントリ名を検索する」にしろってことを言いたいの？
なんか変だよね。

脱線かもだけど

オブジェクト1 . メソッド( オブジェクト2 )

と書くときに、オブジェクト1と2の、どちらがどちらに作用するのか、日本語の仕様書と英語の名称で混乱したことないですか？

ブログサイト . エントリ名検索( エントリ名 )
メッセージ管理 . メッセージ登録( メッセージ )

はいいとして、

データ構造A . 子構造追加( データ構造B )
dataStructureA . addChild( dataStructureB )

はどうか。あるいは、

ウィジェットA . 描画( グラフィックコンテキスト )
wA . draw( gc )

はどっちだろうね。結局 wA の内部で

gc.drawLine( self.point1, self.point2 )

とかになって主語と目的語が逆転するよね。



ここで、一つ気付いた。

私が + 日本語コーディングしようぜ と主張する理由の一つに、「日本語と英語の名前付けに齟齬が生じて卵と鶏の問題に陥るから、日本語で仕様書を書いてヘンチクリンな英語のコードにするのをヤメレ」ということがあるのです。
英語の識別子でコーディングするなら仕様書も英語で書けばいいし、設計も英語で考えればいい。

日本語で設計して仕様書書いて、英語でコーディングするようなことをするから、必然的に「バイリンガルで意味の通じるプログラム」にする必要がでてくる。1レベル難しいことをやろうとしてるんですよ。
で、往々にしてそれが破綻する。
結果、後で人が交代すると「何だこのクソネーミングは」となる。

私もあなたも、彼女も彼氏も「自分はそこそこ英語ができる」「だから英語でネーミングできる」とか思ってるよね。
できてないからね。実際。全然できてない。
「できる」ってのは、1年に10k以上書くスピードで、後で他人が読んだときに「いいコードだ」と思ってもらえるものを書けるってこと。

上記のとおり、英語の知識があって意味が理解できるだけじゃ、日本語の仕様書に対する英語のいい名付けをして、プロ品質のプログラムを書くことはできないですよ。
日本語で仕様書書いて英語でいい名づけをするには、二ヶ国語で意味が成立するように作る必要があります。
言語そのものに対するかなり高度なセンスが必要になってしまうと。

そこが問題なんだな。

自分用メモ。

リンク	備考
ロボットアームの運動学	明治大学 kobayasi 先生
クォータニオン逆運動学
四元数(クォータニオン)でモデルを回転

---

産業用ロボットアーム（マニュピレータ）ていうのは6軸あればだいたいどんなところにも手を動かせるんだそうな。

      J1 J2   J3 J4   J5 J6
付け根◇-○---○-◇---○-◇-ハンド
◇: ねじるところ
○: ひじ開閉

で、

    アーム先端の三次元座標

逆運動学↓  ↑運動学

    各関節の角度

で（たぶん）、

• 運動学(kinematics)の解は、唯一になる
• 逆運動学(IK:inverse kinematics)の解はないことも、複数になることもあるっぽい

要は、どうすれば任意の場所にお気楽にアームを移動できるのかっていう話なんだけど...難しいのよね。

複数になるのはこういう状況。
問題

     _[ アーム先端
  
 |
[] 台座
------

解1

     _[ アーム先端
    /
 |\/ 
[] 台座
------

解2

  ___[ アーム先端
 |
 |
[] 台座
------

この関節の曲がり具合を「形態」というらしいんだけど、この形態の選択をどうするかってのがいやらしい。

軸が360度クルクルまわせるモデルの場合ならよくても、現実のマニュピレータには配線とかついてるから、無限回転はできないものが多い。んで、どのタイミングかで「形態」を切り替えないといけないんだが、これが難しい、と。

あと、オイラー角を用いた回転演算には「ジンバルロック」っていう問題があってたまにイヤーンなことになる。
これ、MikuMikuDanceとかの、ボーンモデルの3DCGをやってる人たちにも認知されてるような、有名な問題なんだそうで。

で、3DCGの世界では、座標変換に、昔ながらの3x3行列を使う方法でなくて、"4元数"(クォータニオン)を使う方法が今は主流らしい。
ということで、逆運動学の解を求めるのも4元数でやればなんとかならんかなぁ、と思っているんだけどやっぱり難しくてよくわからない。

とりあえずリンク先をメモしたかっただけなんだけど、あとで絶対わからなくので自分用メモ！てことで。


余談なんだけど、マニュピレータ移動の勉強をしてると、たまに空手や合気道の知識が役立ったりするです。
いきなり回転しようとしないで、
(1)ちじこまってから
(2)向きを変えて
(3)伸びる
ほうが速いなんてのは、武道をやってると初歩の初歩の初歩だったりする。
そういうのがロボット制御の世界でも同じ、とか。
(しかし、最適パスを通る制御プログラムを求めよって言われるとうぐぅとなる、という)


ていうかアレだ。
合気道とは、自分と相手が「物理的な可動範囲、およびそのうちでも力を発揮できる範囲」の制限を持つアームを持つことを前提として、自分と相手のアーム先端がつながった状態で、自分のアームのポーズ(各軸の角度)にムリがなく、相手のアームのポーズにムリを強いるような体制を、腕だけでなく足腰も使って実現するための、逆運動学のノウハウ集である
ともいえますな。

余談の余談。
知らないかたに一応言っておくと、「合気道は相手の力を利用して」という説をまことしやかに唱えるひとがたまーにいますけど、そんなのウソですよ。ウソとは言い過ぎかもしれないけど、いややっぱりウソです。
「まずは自分自身の筋力を鍛える」「自分の力量と、相手の力のベクトルを見極めて、その制限の中でかけられる技をかける」のほうが、より合気道の本質に近いと思います。合気道は相手が力を出さなければ投げられないのか、っていうと、そんなことない。自分のパワーにモノを言わせる、えげつないブン投げ技も、合気道にはたくさんあります。

仕事場では、お客様方針により頑張って英語の識別子を考えてコーディングしています。
が...

つらいです。

位置予測を行う、現在時刻に対する差分時間[秒]（何秒後の自位置を予測するのか）

とか

衝突回避行動の角速度の加減値[rad/秒]

とかについて、あとで見た人が「何じゃこりゃ」とならないようなネーミングを考えるのが、非常につらい。

(上記について、あなたならどんな英語の識別子をつけますか？いいのができたら教えてください。なお上記を含むプログラム部分の名称は simple_collision_avoidance です)


改めて、英語の識別子でいいコーディングをできるひとって、さぞ優秀なのだろうなと思う。

今の現場にはなんだか優秀な方が多くおられまして、非常にビビります。
私は初めてプログラムを書いてから30年、プロになってから13年ほど経つのですが、恥ずかしながら、日本人の方が書いた英語識別子のソースで「おー、こりゃ分かりやすい」と思ったのは、今の現場が初めてです。
普通のITプロジェクトにはまずいません、そういうコードを書いてくださる方は。

リンク	備考
Kosaka laboratory Interactive System　tips	神奈川工科大学 小坂先生のページ

WiiリモコンやKinectをC#で扱う、わかりやすいサンプルがたくさんあります。

Kinectの調査をしていて見つけました。
ほかのページを少し見てみましたが、小坂先生って、インタラクティブ性について面白い研究をされている方みたいです。
うまくいえないんですが、「明後日の方向」の楽しいにおいがします。

「口臭を用いた吹き矢型デバイス」とか。

おおっ

しばらく放っておいたらLinuxのAMDグラボドライバ、よくなってる。

バグっぽい動作がだいたい治ったかも。

[keizo@suzuki ~]$ uname -a
Linux suzuki.flat7th.org 3.3.1-3.fc16.x86_64 #1 SMP Wed Apr 4 18:08:51 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

[keizo@suzuki ~]$ rpm -qa |grep -i catalyst
kmod-catalyst-3.2.9-2.fc16.x86_64-12.3-2.fc16.x86_64
xorg-x11-drv-catalyst-12.3-1.fc16.x86_64
xorg-x11-drv-catalyst-libs-12.3-1.fc16.x86_64
kmod-catalyst-3.3.1-3.fc16.x86_64-12.3-2.fc16.x86_64
kmod-catalyst-3.2.6-3.fc16.x86_64-12.1-1.fc16.2.x86_64
akmod-catalyst-12.3-2.fc16.x86_64
[keizo@suzuki ~]$ 

UMLのお絵描きツールで知らない子がいたので、Fedora16上でちょっと試してみました。Gaphorというソフトです。

リンク	備考
Gaphor	version 0.17.1

• ほぼPythonで実装されているらしいです。
• 日本語は入力できませんでした。
• 起動もとのterminalにたくさん警告メッセージが出ました。完成度はまだアレな感じです。
• やっぱツールキットまわりは新しいものほどかっこいいね。

スクリーンショットはこんな感じです。





箱を結ぶ線に、集約の記号（♢、♦マーク）をつける方法が分かりませんでした。

箱に対する矢印の端点のくっつきかたは：箱の外周上のどこにでも張り付きますが、2つの箱の位置関係を変えたときには、その辺上の点がそのまま なのが特徴的です。ってわかりにくいですね。スクショをはります。

これで、

箱を移動すると

こうなる、と。


今後に期待します。UMLツール Gaphor のレポートでした。

話題ものなので買ってみました。



ザクとうふ。

裏はこんな感じです。



以前の職場で、ザクとザクⅡをちゃんと呼び分けろ、と熱く語っていたサーファーかつソフトエンジニアな方がいました。そのとおりだと思います。

肝心の味についてですが、風味が強くてなかなかおいしかったです。

ただ、次からはこの形じゃなくていいから、もう少し小さい四角型で、あるいは2個がくっついてて切り取りできるパックで、いつでも買えるようにして欲しい。

そしたらまた買いますよ。味はおいしいもん。

最近、酔ってる時間て無駄だなと思うようになった。

ちょっと飲むのはいいんだけど、酔っ払うのはもうイイや。

むかーし、ブランキージェットシティーの浅井さんが、ギターマガジンのインタビューで「お酒飲むのも飽きちゃったし(また音楽つくるよ)」て言ってた。読んだ当時は意味不明だったけど、今は当時とはまた違う気持ちで解釈している。

まぁ歳とったな、てのと、環境からいい刺激を受けると人間はこうもやる気になるのか、とも思う。

---

一部のかたに定期報告ですが、最近、ボカロ始めました。ボーカロイドって、実は商品名なので、正確には UTAU を始めました、です。

あとギターも練習してます。タックアンドレス奏法(ベースと和音バッキングとリズムカッティングをギターひとりでやる)の劣化コピーで、 Do It Again とかやってます。

やっぱ音楽趣味って、たのしいね。

+ Excel選択範囲のテキストをテキストボックスに
PARA(){\+ Excel選択範囲のテキストをテキストボックスに}

cairoでギターフォームの図、とりあえずできた。



後述のソースのうち、重要なのは

    frets = 4
    leftmost_fret = 3
    pos = [2, 2, 1, None, 2, None]

の部分だけなので、この部分だけを指定すれば、上記のような図をWikiに埋め込めるようにしたい訳です。それをこれから考えて行きます。


Python ソースコード
↓4/24 英語のつづり間違ってるかも！

#!/usr/bin/env python
#coding:utf-8

import cairo
import math


def main():
    sf_w = 200
    sf_h = 150
    margin_x = 20
    margin_y = 20
    margin_fb_and_num = 20
    margin_fret_num_h = 5
    strings = 6

    frets = 4
    leftmost_fret = 3
    pos = [2, 2, 1, None, 2, None]


     
    #下地
    surface = cairo.ImageSurface(cairo.FORMAT_ARGB32, sf_w, sf_h)
    cx = cairo.Context(surface)

    cx.set_source_rgb(1.0, 1.0, 1.0)
    cx.rectangle(0, 0,  sf_w, sf_h) #左上 x y と 幅 高さ
    cx.fill()

    #マス
    cx.set_source_rgb(0.0, 0.0, 0.0)

    fb_x0 = margin_x
    fb_y0 = margin_y
    fb_x1 = sf_w - margin_x
    fb_y1 = sf_h - margin_y - margin_fret_num_h - margin_fb_and_num

    frets_interval_x = (fb_x1 - fb_x0) / frets
    strings_interval_y = (fb_y1 - fb_y0) / (strings-1)

    fb_x_seq = range(fb_x0, fb_x1, frets_interval_x)
    fb_x_seq.append(fb_x1)
    fb_y_seq = range(fb_y0, fb_y1, strings_interval_y)
    fb_y_seq.append(fb_y1)
    
    for px in fb_x_seq:
        cx.move_to(px, fb_y0)
        cx.line_to(px, fb_y1)

    for py in fb_y_seq:
        cx.move_to(fb_x0, py)
        cx.line_to(fb_x1, py)

    cx.stroke()

    #抑えるところマーク
    for i in range(6):
        if not pos[i] is None:
            pos_x = (pos[i] - 0.5) * frets_interval_x + fb_x0
            pos_y = fb_y_seq[i]
            pos_r = strings_interval_y * 0.4
            cx.arc(pos_x, pos_y, pos_r, 0, 2*math.pi)
            cx.fill()

    #フレット番号
    cx.select_font_face(
        "monospace", cairo.FONT_SLANT_NORMAL, cairo.FONT_WEIGHT_BOLD)
    cx.set_font_size(14)
    font_x_bearing, font_y_bearing, font_width, font_height = \
        cx.text_extents("8")[:4]
    fretnum_y = sf_h - margin_y - margin_fret_num_h
    fret_nums = range(leftmost_fret + 1, leftmost_fret + 1 + frets)
    for i in range(frets):
        fretnum_x = (i + 0.5) * frets_interval_x + fb_x0
        cx.move_to(fretnum_x - font_width/2 - font_x_bearing, 
                   fretnum_y - font_height/2 - font_y_bearing)
        cx.show_text("%d" % fret_nums[i])

    surface.write_to_png("test2-line.png")
    return

main()

---

下記、参考にさせていただきました。ありがとうございます。

リンク	備考
画像処理についてあれこれ - pycairoのまとめ
Cairo Tutorial for Python Programmers

---

2012 4/20
あああっ margine じゃなくて ！！margin だろが俺のバカ。

だから嫌なんだよ！

→なおしました...

---

そしてさらに
flet じゃなくて fret です。OTL

→なおしました...

music/20120423
PARA(){music/20120423}

リンク	備考
パッケージ管理コマンド対応表

すばらしい！ yum系とapt系のコマンドが一覧になっています。
ありがとう、そしてありがとう。

---

そして、数日前の日記ですが、リュート楽器のフレットのつづりは
fletじゃなくてfretですな。
あほですみません。

放送大学の「データマイニング」の講義で、実習言語として R言語 を取り上げていたのでおもしろそうだなぁと思い、勝手に聴講中です。

リンク	備考
データからの知識発見（'12）	秋光 淳生 センセイ

今週の話は行列の演算と、固有値・固有ベクトル、対角化をやりました。うーむ。現役のときに絶対やったのだろうと思うけど、全く記憶にないなぁ…。

で、さっそくFedoraに R をインスコして、講義のとおり実習してみました。

講義では

> A <- matrix( c(1,2,3,4),ncol=2,nrow=2,byrow=T )
> B <- matrix( c(1,2,3,4),ncol=2,nrow=2 )

とやってたんですが、ncol=2 と nrow=2 って無駄では？と思って片方省略してみたら、OKでした。

> A <- matrix( c(1,2,3,4),ncol=2,nrow=2,byrow=T )
> A
     [,1] [,2]
[1,]    1    2
[2,]    3    4
> A <- matrix( c(1,2,3,4),ncol=2,byrow=T )
> A
     [,1] [,2]
[1,]    1    2
[2,]    3    4
> B <- matrix( c(1,2,3,4),ncol=2 )
> B
     [,1] [,2]
[1,]    1    3
[2,]    2    4
> A %*% B
     [,1] [,2]
[1,]    5   11
[2,]   11   25
> 

代入が左矢印 <- とか、独特ですねぇ。ほとんどのプログラム言語では代入がイコールで、
もうそれで慣れてしまったから、逆に違和感あります。#そういえばPascal系は代入が := だったかな。
そして行列の積は

%*%

記号を使う、と。

> C <- solve(A)
> C
     [,1] [,2]
[1,] -2.0  1.0
[2,]  1.5 -0.5
> A %*% C
     [,1]         [,2]
[1,]    1 1.110223e-16
[2,]    0 1.000000e+00
> 

solve()は、本来は連立方程式を解くものなのだけど、行列に適用すると
逆行列を求めてくれるのだそうで。そして、もとの行列と逆行列とで積を求めて、
浮動小数の誤差があるけどほぼ単位行列になるでしょ、と。

> D <- eigen(A)
> D
$values
[1]  5.3722813 -0.3722813

$vectors
           [,1]       [,2]
[1,] -0.4159736 -0.8245648
[2,] -0.9093767  0.5657675

そして、eigen()でAの固有値と固有ベクトルを求める...
と、この辺から自分の理解が怪しくなってきます。
前半で、行列に対する固有値・固有ベクトルの説明があったので
なんとかこの辺はついて行ってました。

その後「対角化」するところで訳ワカメ。
対角化すると固有値が並んだ行列が求められて、それによって
Aの性質が読み取れる...？

うーむ、もう一回見ないとだ...


んでも、まぁ、

「Enter押すと走り出す」ものは、なんでもおもしろい。

です。


Mathematicaも、iPythonも、Rも。octaveもかな？

tips:Gnome3左上アクティビティ マウス ホットコーナー無効
PARA(){tips:Gnome3左上アクティビティ マウス ホットコーナー無効}

---

で…

どうでもいいことなんだけど、PythonでGtkアプリを作ってみようかと思って数年寝かせていたら、もうブームが去っていて、すでにJavascriptになっていたでござる。

中年老いやすく学成り難し
一寸の光陰軽んずべからず
ｱﾋｬﾋｬﾋｬ(ﾟ∀ﾟ)ﾋｬﾋｬ( ﾟ∀)ﾋｬﾋｬﾋｬ( ﾟ)ﾋｬﾋｬ( )ﾋｬﾋｬ(ﾟ )ﾋｬﾋｬ(∀ﾟ )ﾋｬ.

昨日、コンピュータ音声による世論調査電話がかかって来ました。

「消費税増税に賛成か反対か」「消費税に関する論点は投票に影響するか」等聞かれて(プッシュボタンで)答えたけど、コンピュータ音声に向かって「なんかあんた大事なこと忘れてないか？」と言いたくなった。

民主党が政権とったらガソリン税の暫定税率止めるっていうから投票したのに。目先の話の前に今後どうしていくのか全く分からん。
竹中さんだかが言ってた「大きな政府を目指すのか、小さな政府を目指すのか」どっちなのかね。大きな政府はもうダメポなんじゃないの？どっち目指すのか不統一なのが一番悪い。

「コンクリートから人へ」って、でも結局ばらまいてるのは一緒だし。子供手当ての支給額すごかったよ。そりゃ今苦しいから助かったけど、だから支持しようとは思わんよ。

---

消費税あげてもいいか？と聞かれたら、ガソリンの暫定税率止めて自動車税を欧米並にしたら、あげていいよ、と答えたい。ちょっと話題変わるけど、自動車の所有・維持にかかる税金は高すぎる。これで消費税が10%になったら日本の自動車産業オワットルだ。

『クルマの取得や保有にかかる税負担は下の図を見てわかるとおり、欧米諸国の約2.4～49倍にもなります』

リンク	備考
みんなで考えよう　クルマの税金

「若者の自動車離れ」っていうけど、あれ違うよね。若者だって車欲しがってる。買えるならね。
若者が離れてるんじゃないよね。
海外生産拠点への移行や、若者向けでないラインナップの設定などの自動車メーカの企業行動や、根拠のない高額のガソリン税、高額の自動車税、センスの悪い安全基準の制定、現実にそぐわない速度制限等交通法規、...などの自動車政策こそが若者を遠ざけてるのに。
自分から「あっち行け」しといてよく言うわと思う。

ボブソン倒産の話。

リンク	備考
大型倒産情報 ボブソン
Wikipedia:ボブソン

ファストファッションの台頭で体力を失い、オーナー会社を替えてブランド再生計画を実行していたところ、震災でとどめを刺されたということでしょうかね…


私、母親が、新宿の文化服装学院→伊勢丹の出身です。
彼女いわく、ファストファッション等、安いことがいいことだという風潮はよくない、と言ってました。
（関係ないけど祖父はオーダーメイドの紳士服テーラーでした）
で、血筋の割に、自分は服装にさほど興味ないのですが、母の言葉が妙に引っかかっています。
安売りジーンズ、一回買いましたけど、その後買っていないです。

他のジーンズメーカーは大丈夫かなぁ。心配です。

---

オイラは学生時のあるときからリーバイスのストレート、505ばかり履いています。20年前と同じインチが履けることがちょっと自慢。なのですが、流行り廃りで品揃えにないこともあって、そういうときは苦労します。

ジーンズショップさんが定番の型をいつでも置いてくれる社会だとうれしいです、個人的に。

正しいCRC計算アルゴリズムがわかりません、ていう話。

リンク	備考
おおもとの仕様？
CRC16-CCITT
BOOST CRC	BOOSTの「16ビットCRC-CCITT」は、上記サイト(www.JoeGeluso.com)が「間違っている」と主張する値を返します。
通信用語の基礎知識 CRC	キャリーフラグを使ったレジスタ間ビット移動(ローテート)とか、マシン語前提の説明になってるけど、日本語で正しそうなサイトってここしか見つからなかった

連休に検証しようかと思ったけど遊んでたから未完アヒャヒャ(汗


CRCの計算というのはいろんなとこに出てくる。イーサネットとか。

んで、あるハードの制御に16ビットのCRC値計算(初期値(FFFF)h、多項式が X16+X12+X5+X0 = 0x11021 ≒ CRC計算上は 0x1021 でも可)が必要になったんだけど、

正しいアルゴリズムがどれなのか、よくわからん、という話。

上記リンクの2番目の人は、「正しい」アルゴリズムと「間違った」アルゴリズムの2つを示している。

で、試行錯誤の結果、今いじってるハードは、上記サイトの「間違った」アルゴリズムを使ってることがわかった、のです。


で、Boost にも CRC計算のライブラリ があるみたいなんだけど、これもどうやら上記サイトの言う「間違った」アルゴリズムの値になる。

("123456789"という文字列に対して、www.JoeGeluso.com は正しいCRC値は 0xE5CC だと言っている。BOOSTのCRCライブラリは 0x29B1 を返す。)



まぁ、今回は目的のハードが動けばいいんだけど、自分が仕様を書くときには 16ビットCRC CCITT方式、というだけだと（間違ったアルゴリズムだけど世に多く出回っているから主導権を握っているほうをつかっているのか、否か）混乱のもとだから、サンプルソースまでつけて明確にしよう、と思った、という話。

サンプルソースつけなくても、"123456789"に対し何を返すアルゴリズムなのか、を示せばだいぶ助かるね...。

NHK スーパープレゼンテーション 2012年5月21日放送

デブ・ロイ「はじめて言えたとき」
Deb Roy: The birth of a word

先日21日放送の、NHKの番組「スーパープレゼンテーション」を見ました。
MITのデブ・ロイさんの発表で、9つの魚眼レンズで自宅内を録画した200テラバイトの
データ（いわゆるライフログ）を解析して得られる知見について の発表でした。




・自宅内の過去の状況を3Dで再現したり

・お子さんが初めて覚えた1語「水」の発音が "gaga" から "water" に推移する、その移り変わりを聞けたり

・お子さんが獲得したいくつかの単語について、
自宅内で家族やシッターがその言葉を発した、位置、時刻、頻度を結びつけて
ビジュアライズできたり

・その手法を、全米のテレビ放送とソーシャルネットワークでの人々の発言内容の
分析に応用してビジュアライズしたり

とても示唆に富む映像が多かったです。


最後は
・お子さんが初めて3歩歩いた状況を動画で再現する
内容で締めくくりでした。

実は私、学生時は一時期チョムスキーの生成文法論やLR構文解析にハマっていたこともあり

「将来子供ができたら、自分の子供がどうやって言語を獲得するか観察してみたい」

などと思っていたのでした。

実際には私には力が足りず何もできぬままに子供は大きくなり、さらに私のポカもあって自分の手を離れてしまった訳ですが、彼の発表は、私ができなかったことを現実の映像にして見せてくれたという意味で、とてもtouchingでした。


再放送は28日(27日深夜)だそうです。
ぜひ、見ていただきたいです。

なお、英語が問題なく聞ける方でしたら

で見れるようです。

本屋さんが1日1件潰れるという件

街の本屋を襲う “倒産ラッシュ”！ １日１店が店じまい

痛いニュース

について思ったこと。

ネットで注文して店で受け取るって意味ないよね。

反対に、書店で注文して支払い済ませて自宅に届けて欲しいよ。


店に行ってもどうせあるわけなくて買えなくて、あぁ、また無駄な時間を使ってしまった、とマイナスの行動学習をする訳ですが、既存書店は、なかった時のすくい取り処理がイマイチ。注文して数日後にまた取りにいくってどうよ。またその店に取りにいくくらいなら、ネット書店で注文するだろ常識的に考えて。

ただねぇ

専門書で8000円位するのもあるよね。書店に行くってことは、財布持って、金使う気充分なのよね。当然、無駄なお金なんか誰も使いたくない。だけど高くても、よし買おう、と思ったときは、「実物があれば今日その場で買いたい」マインドなのです。

そのための現金を、すでに口座から引き出してることもある。
そういうとき、やっぱりネット注文か、となってネットでの振込だと、なんだかなぁ、と思うことがある。
そうじゃなくて、今手元にある現金で払いたんだよね。

なので、

店で探して、なければ、情報端末で入力して、レジでお金払って、そんで自宅に届けてほしい。

誰でもそう思ってるはずなんだが、なぜそうしないんだろう...

こんなに過ごしやすい気候なのになんで電車に冷房入れてるの？バカなの？死ぬの？

飲んでもいないのに、定期的に中二病の発作を起こす。そして周りに迷惑をかけてしまう。そして反省する。

何なんだ、この自分の中にある制御できないものは。

orz

ODE

リンク	備考
ODE	Open Dynamics Engine
ODE-Wiki
Slide	作者による手書きスライド14ページ。

リンク	備考
ode4j	ODEのJava移植(ラッパーではなく移植)
ode4j javadoc

ODEとは、オープンソースの

• 剛体の運動シミュレータエンジンです。
• コリジョン(衝突)検出エンジンです。

ロープや布はアプリで実装すべきという立場らしいです。
コリジョン検出は、「近い2つのオブジェクトをコールバックで知らせてくれるので、利用者がコードで衝突してるか最終判定する」というつくりのようです。


描画エンジンには、外部のものを利用せず、内製の"drawstuff"というものを使っています。そのさらに内部は、OpenGLです。

 ユーザアプリ
       |____ ODE (C風だがコンパイラはC++)
               |______ drawstuff
                         OpenGL

ode4j

ode4jは、ラッパーではなく移植です。

そのode4j、先週末に最新のODEに対応した版が出たようです。

Eclipse使って、ボールが弾むサンプルを作って見ました。Javaだからか、さすがに200個とかオブジェクト出すと遅くなりますが、

オリジナルのC++版よりもAPIの作りがオブジェクトライクで、わかりやすくできています。

ODEの、Cっぽい(平たい)APIに挫折ぎみだった方がおられたら、ode4jのオブジェクトっぽい(立体的な?)APIでやってみるとよいのではないでしょうか。

なお、ode4jは、内部にLWJGL(Light Weight Java Game Library) を利用しています。その先がOpenGLであるのは、オリジナルのODEと同じ。

 ユーザアプリ
       |____ ode4j (ODEのJava移植)
               |______ drawstuff (のJava移植)
                         LWJGL
                         OpenGL

リンク	備考
LWJGL Light Weight Java Game Library

プログラミング言語研究者にも比較対象としておすすめ

私は言語としてはCのほうがJavaより好きなのですが、この二者については Java 版の優秀さを褒めない訳にはいきません。
この例は、プログラミング言語文法の研究者にも、貴重なサンプルになると思います。
サンプルを実行しながら、クソッ、Javaのくせに、Javaのくせに、とか思ってました。

ode4jの作者さんの言から自分なりに解釈すると：
例えば、あるAPIのパラメータにオブジェクト(構造体)を渡す場合、それが rvalue でよいところで ODEでは lvalue を使うようになっているが、これは (1)ソースが分かりにくくなる原因となる (2)言語系による最適化の可能性を阻害する わけです。

とまぁこんな感じで、計算機科学屋にも非常に興味深いライブラリなので、ODEとode4j、ぜひ見てみてください。

難点

褒めてばっかりだとアレなんで、悪いところも指摘。

ODE も、ode4j も、サンプルプログラムで「モデル」と「ビュー」の分離ができてなくて、初学者にやさしくない。

まぁ、それを差し引いてもよくできていますよ。

今日もまた、電車の中でプログラミングについて妄想してました。

# プログラミング言語「残心」

PARA(){# プログラミング言語「残心」}

なんかさー、電車に乗るのに並んで乗るけど、後ろから押してくるバカがたまにいるね。あぶねーっつの。
今日のはなんか若くて太目の女だった。

帰ったらなんか楽しいメールが来ていて自分の時間台無し。

安定剤欲しい。

ノートの写しをウェブ経由で自宅サーバに上げてみるテスト。



意外に使えるかも。

うーむ。

• 自作プログラムのほんのアイデアとか、
• 営業(面談)のメモとか、

ノートの内容は、

• 記載内容カテゴリや、
• 保存の重要度がまちまち。

その対策として、

• ルーズリーフを使う。

としていたのですが、

• 普通のノートを使う。
• 大事な内容は画像とってフォルダに放り込む

でいいのかも。

突然思い立って PySide (Qt の Python バインド) をいじっています。

test2.py

#!/usr/bin/python
#coding:UTF-8

import sys
from PySide.QtGui import *

def main():
   app = QApplication(sys.argv)
   label = QLabel("hogefuga")
   label.show()
   app.exec_()
   return

if __name__ == "__main__":
   main()

test2j.py

#!/usr/bin/python
#coding:UTF-8

import sys
from PySide.QtCore import *
from PySide.QtGui import *

def main():
   QTextCodec.setCodecForTr(QTextCodec.codecForLocale())

   app = QApplication(sys.argv)
   label = QLabel(app.tr("ほげ"))
   label.show()
   app.exec_()
   return

if __name__ == "__main__":
   main()

test4j.py

#!/usr/bin/python
#coding:UTF-8

import sys
from PySide.QtCore import *
from PySide.QtGui import *

def main():
   QTextCodec.setCodecForTr(QTextCodec.codecForLocale())

   app = QApplication(sys.argv)
   btn = QPushButton(app.tr("ほげふが"))
   btn.clicked.connect(app.quit)
   btn.show()
   app.exec_()
   return

if __name__ == "__main__":
   main()

日本語出すのにやたら手間取りました。

Qt の「シグナルとスロットをつなぐ」という考え方、いいですね。

---

ところで：思い起こせばもう15年近く、

Windows上に擬似Unix環境を作るのに血眼になっていました。

Meadow、NTEmacs、Cygwin、CygwinX、CygwinXでMS-IME、その他... の設定調査にかけた時間は相当なものがあります。Meadow や NTEmacs でX風のフォントセット定義することに、20代の何時間を使ったことか。

また、ディレクトリの区切り文字が スラッシュ か バックスラッシュ かで、一体、人生の何時間を無駄に費やしたことでしょうか。

改行文字が CR LF か LF かで、何時間費やしたことでしょう。

もうね、アホかと。

そろそろ卒業したいな、と思っている訳です。MacもUnix系になって落ち着いてることだしね。


最近、MinGW がまた中途半端に動くようになってきたもんだから、仕事で、何かのソフトを MinGW で動かす調査とかもするハメになっている訳ですが。

ぼくらはですね、Cygwin がまだ GNU Win32 のバージョン16とか18とか言ってたあの頃から、ものすごい時間を、無駄に使ってきたわけです。いい加減うんざりなんですよね。

クロスプラットフォームクソくらえ。特定のソフトつかいたきゃぁ、開発者が想定したOSを用意すりゃあいいんですよ。どうせネット上で通信する構成になるんでしょ、どこかのレイヤで。


で、ソフトウェアを開発するっていう観点からすると、Windowsって無駄に敷居が高いんですよね。
現在わたくし、自宅のPC利用環境は

• 基本 Linux で emacs、gcc、flex、bison、php、python、...
• VirtualBox の上に WindowsXP
• その上に MS-Office

となっております。


...

とか言って、相も変わらずクロスPFであることに最大の意味がある Qt なんか調べてたりすると。

バカですね。ため息出ますな。IT屋。というか、自分自身のアホさ加減に。

うぅ、先週末から体調悪く回復しない…

自律神経がエラー起こしておかしな状態にハマってる気がする。


とりあえずアレルゲンを減らす努力をしてみるか。

今朝は息が止まって苦しくて起きました。

だれかロボット鼻を開発してください。仕事の集中力、その他QOLに大変影響します。

ロック岩崎さん（元自衛隊の戦闘機パイロット、故人）は、入隊時の身体検査で鼻腔の壁が曲がっているのを指摘され、手術で修正した、とか読んだ記憶があります。

自分は体を改造することになんとなく抵抗がありますが、毎日息が苦しいのは、なんとかしたいです。うーむ。鼻と皮膚の医者は、どこへ行ってもまったく当てにならんしなぁ。

人間は、シンプルにバイクや自転車の絵を描いてだれかに伝えようとしたとき、横から見た絵を描くと思う。

これって、実はすごいこと。どの方角から見た絵を描けば、そのものの特徴を一番分かりやすく表現できるかを瞬間的にぐるっと検索して、よし、ここだ、と決めて、イメージを紙に投影する。

---

プログラミング言語の、字面表現について思うところがたくさんあるのだが、今そういう分野ってあまり発展していない気がする。

飛躍するけど、Qtのサンプルで

layout->addWidget(spinbox);
layout->addWidget(slider);
window->addLayout(layout);

ってのがあって、率直に言って言語として読みにくくね？と思った。


パラメータ型によるメソッドの区別で

layout->add(spinbox);
layout->add(slider);
window->add(layout);

でもいいわけだ。
(でもそれがメンテ性いいか悪いかは検討が必要だ。)
add っていう単語を選ぶこと自体についても議論できる余地がたくさんある。他の言葉だとどうか、と。


次に矢印について。まあC++でポインタだから "->" なのも分かる。けど、上のサンプルを、前提知識が薄い状態で読んだ人は混乱すると思うんだ。


矢印を図解表現で用いるとき、「どっちがどっちを指すのか」で混乱することが、よくある。で、みんなが合意しやすいのは、「情報や物が流れていく」さまをイメージして、「ブツが流れる方向に矢印を描く」ことだと思う。そうすると、上記はむしろ

         幅・高さの情報
spinbox ----------------> layout計算をするひと

         幅・高さの情報
spinbox ----------------> layout計算をするひと

                      幅・高さの情報
layout計算をするひと ----------------> window

であって、矢印の向きが逆なのよね。まぁこれはC言語の罪のひとつかな。


じゃあ、ポインタじゃなくてauto変数で . にしたらどうなるか。

layout.add(spinbox);
layout.add(slider);
window.add(layout);

ふむ。

使役っていう考え方で、このほうがまともだと思う。

layout.内包する(spinbox);
layout.内包する(slider);
window.使用する(layout);

主語と目的語が入れ替わるとどうか。

spinbox .所属する layout
slider .所属する layout
layout .情報を提供する window

とか。

字面の問題って、実は重要だと思うんだよなぁ。


さらに飛躍。今オブジェクト指向って、クラスがプロパティとメソッドを持ってる、ていう考え方で、そこは20年くらい変わってないけど、そろそろ yet another が出てもいいよね。

プログラム言語は、ソースコード上で以下のような事柄を記述できる必要がある。

• アルゴリズムだけじゃなくて、
• オブジェクトの所有関係とか、
• ライフサイクル（いつ生まれていつ消えるか）とか、
• 同時処理の区切り（スレッド分割）とか。

プログラムという多次元の塊を、どの次元に焦点を当ててソースリスト＝文字の並びに投影するか、なんだけど、今ってスレッド分割とかは非常に分かりずらいところに追いやられてるよね。

(相当飛躍するけど、統一場理論は10次元で考えると5通りあって混乱してて、11次元にしたら全部同じものだったんだそうな。11人いる！てなもんですな)


また飛躍。「メソッド」って、元は非オブジェクト指向言語の「関数」で、ソースコードの文字列では、パラメータを括弧でくくって表現するけど、そのパラメータのうち

• どこが in パラメータで
• どこが out パラメータなのか

も、「ソースコードで表現しずらい角度で投影」されていると思う。

SVOC的な考え方で、APIのメソッドをどう構成するかは、
それぞれのライブラリの「流儀」である、として、ソフトウェア工学がプログラマに丸投げしてしまっている。それって、混乱の一因なのよね。

つまり、ソフトウェア工学の専門家が、世の中に「解の案」を提示すべき問題として、以下の問題があるってことだ。

• 2つのオブジェクトがかかわる、というソースコードで、主語と述語をどう選択すべきか
• メソッドの述語をどう選択すべきか
• パラメータのうち、どこがinパラメータでどこがoutパラメータなのかを、どう分かりやすくするか(分かりやすくするとメンテナンス性の高いプログラムの蓄積で人類に貢献できる)

そもそも、パラメータっていう考え方がもう時代遅れなのかも。ロボット関係の開発環境だと、

        伝達情報
送信者 ----------> 受信者

ていう、有向グラフ構造を、GUIで作成できる環境がほぼ標準になりつつある。これって、テキストでのプログラム表現にフィードバックできるよね。

---

思えば、ぼくら世代は英語を学ぶ前にBASICを読んでいた。つまり、自分にとって英語は第二外国語なんだな。

石田先生の「パソコン言語学」を読んだのは、小学生のときだったのか、中学生になってからだったのか。なんか、それがすごく重要なことのような気がしてきた。

独り言だけど

• HTMLの単語頻度分布判定のアレとか
• pktsendとか

自分が lex/yacc で作ったものを公開できていないわけだが、頑張って公開できるものを用意してみようかな。

自分が、「昔からプログラム言語の字面に興味を持っていて、そこについて思うことをたくさん持っている」ことを、他の誰かに分かってもらえるきっかけになるかもしれないから。

---

まつもとゆきひろさんみたいな言語マニアの方が、石田先生の「パソコン言語学」を継ぐ、21世紀版を書いてくれないかなぁ、と半分あきらめ、半分本気で期待。そんな本、誰が買うのかって？僕は買います。でも一般的には売れないだろうなぁ(w

えっ？ 無名の共用体って、C++の仕様になったの？
昔はMicrosoftの独自拡張だったと思うんだけど？

リンク	備考
PCL(Point Cloud Library)のチュートリアルページ	で、無名共用体が出てきてあれ？っと思って調べたら...
共用体	Wikipedia。なんか仕様になったっぽい
私の昔の日記	まぁ、無名の共用体って、継承と近いのよね。C++によるオブジェクト指向実現手法のメモリ配置解釈として。
無名共用体	Borland C および C++

なんだよ誰か教えてくれよう。(お前が調べろって？はい。)


でも、そしたらますます「多重継承って要らない」じゃんね。


... うーむ。

---

C/C++では、構造体とか共用体とかって、メンバーへのアクセスは結局インデックスレジスタ ベースレジスタ を使ったアドレッシングみたいなもんだ、っていう感覚を理解できると１つ「ストン」と腑に落ちるわけですよね。
C++のクラスもその延長なんだっていうことがわかるとまた「ストン」と腑に落ちるわけです。

Javaもしかり。大昔のJavaだと、複数の階層の深いメンバにアクセスする場合は事前にローカルオブジェクト(ポインタ)に代入すると速くなったりしたんですよね(遠い目)。


そこが、perl、javascript、その他たぶんrubyもpythonも…の、連想配列でのクラス実装と大きく違うとこなんですが、
まぁその話はまた。

Fedora17インストール中です。

普通にアップグレードしたほうが良かったかな？とちょっと不安に思いながらも、仕掛けたので今日は寝るべし。

しっかし、Slackwareインストールしてた頃の知識が、まだ現役で役に立つってのは、いいのか、悪いのか。



DVD の iso を live usb creator で作る前に、既存のファイルをまっさらにしたくて、結局新しいツールが見つからずにコマンドラインの fdisk と mkfs で対処。

多分また忘れるので、自分のためにメモ。

su -

tail -f /var/log/messages で USBメモリが /dev/sdb であることを確認して

fdisk /dev/sdb
メニュー見ながら vfat のパーティション作成、
d で削除
n で作成
t でパーティションIDを 0xc に設定。

mkfs.vfat /dev/sdb1

ブート可能マークは、live usb creator がつけてくれた。


で、最初やったときに Boot error と出て起動しなくて少し悩んだのだが、fdisk の t でパーティションIDをつけるのを忘れていたため、初期状態の 0x82 になっていたのでしたとさ。

0xc でやり直したら起動しました。


で、今アナコンダ仕掛けて一晩寝かせてるところ、と。

---

うわー、

…

近年まれに見るダメさ加減でワロタ。
Xの画面が薄くてちらついてて2/3ほど右にズレとる。

まだ、ここからなのか…。(苦笑


古いほう（F16）も起動しなくなった。さすがFedoraだ、歪みねぇな。
やっぱりFedoraは新しいHDDに付け替えてからインスコしないとダメなのかな。

orz

---

boost::shared_ptrの前に日本語コメントを書くとコンパイルエラー

別件。Windows。Visual Studio 2010 64ビット。

リンク	備考
pcl_visualizer	Point Cloud Library

boost::shared_ptr<pcl::visualization::PCLVisualizer> viewer;

のまえに日本語で終わるコメント行をおくとコンパイルエラーになる、という事案が発生。

//あ
boost::shared_ptr<pcl::visualization::PCLVisualizer> viewer;

だと、

エラー	2	error C2065: 'viewer' : 定義されていない識別子です。

となり、

//あ

boost::shared_ptr<pcl::visualization::PCLVisualizer> viewer;

または

//あ.
boost::shared_ptr<pcl::visualization::PCLVisualizer> viewer;

ならOK。

文字コードはUTF-8。

チューリングマシン、マルチコアCPU、SSD

今、思うこと。

ノイマン型コンピュータなんだけど、一皮脱皮して

スタックじゃなくてリングバッファベースの計算機をいじってみたい

発想の元ネタ

• そろそろハードディスクがSSDに変わりそうですよね。SSDは同じところに何度も書くのよくない。リングバッファのほうがSSDにやさしい。
• チューリング生誕100年だとか。ノイマン型コンピュータはチューリングマシン...。で、チューリングマシンの紙テープがリングになってたら（もしくはねじって、メビウスの輪）、戻さないでどんどん先へ進んでいく計算機になる。
• マシン語レベルで関数呼び出しってのは、スタックにパラメータつんで、関数おわりでスタック巻き戻す訳ですが、それって、1CPUコアではいいけど、マルチコアだと意味ない。むしろ、スタックじゃなくてリングバッファを使って、先へ先へ進んでいく計算機だと、マルチCPUを有効に使えるかも。
• outパラメータを使うとおかしな話になるので、どんどんデータをフォワードしていく構造で計算を設計する...このへん未整理だけど、友人がなんかおもしろいこと言ってたので

Forthっていう、スタックマシンタイプのプログラミング言語があるけど、あれをリングバッファにしたらどうなるんだろ？

---

数学や物理、化学は「科学的な手法で」世の中に役立っているというのに、計算機科学は、相変わらず発見手法と人足でやってる訳ですが、

計算機科学というのは、こういうの(チューリングマシンの次、とか、GCの次、とか、RDBの次、とか...)を考えることだとおもうことです。

がんばろうぜ。計算機屋。

頭痛いのが収まらん…

なんか悪いもの食ったかな…

有言実行：
パソコン言語学の自由研究のサイトを作りたい。作ろう。作るぞ。

プログラミング言語自体もそうだけど、むしろライブラリごとの「書き方の流儀」「流派」から書き始めよう。最初のネタはODEとode4j、PCLの基本スタイルとか。

そんで実例がいくつかまとまったら、主語と目的語の話とかも考えていきたい。

inパラとoutパラの混乱が、Pythonでは左辺にタプルを書けるためにすっきりする、とか。

それから、「高級言語」未満というか、データ定義のタイニー言語とかも、ゆくゆくは。

欄外囲み的に、自然言語風に読めるプログラム、Smalltalk のアレとか 日本語Forthとか。
あと、初期の簡易BASIC風の、変数名は8文字まで許すけど最初の1文字しか区別しない、とか。

---

よく考えたら、それって今やってる事だった。
短期間で高品質の文書をたくさん書くなんて無理だから、コツコツやる、で正解だし。
現状足りないのは、

• 玉石混交過ぎるので品質上げよう
• 整理されてなくて役に立たないので、カテゴリごとに閲覧できるようにしよう

だな。
カテゴリ機能の件は今あるタグで出来る気がする。

あー

うるう秒の時報聞き逃した...

最近プログラムつくるときのお気に入り構成。

いわゆる普通のアプリケーションの場合

main()               Mainつくってメインループ呼ぶ

Main                 全部を所有。メインループはここに書く
◆
|
|__Configure         プロセスの設定、コマンドラインオプション等
|
|__EventStore        アプリ内のイベント保持。キー状態保持とか
|
|______Algorithm     ユーティリティ関数群。出力は戻り値かoutパラメータにする
|        |
|        ◇
|____Action          アプリの行動。箇条書き風のメソッド実装を目指す
|       ◇
|       |
|____DataMgr         データ管理
      ◇
      |
      |__*_DataEntry    アプリ実行に沿って増減するデータ

データ入出力が大事な場合

Main
◆
|
|__Configure         プロセスの設定、コマンドラインオプション等
|
|
|__IOMgr                   会社で言うと営業部
|    |__TransactionPool
|    |   |__Transaction            受けたもの、送るものの1セットを保持。トヨタでいうカンバン
|    |       |__RecvPacket         外部とのやり取りフォーマット
|    |       |__SendPacket
|    |       |__RecvData           内部処理フォーマット。パケットごとにたくさんつくる
|    |       |__SendData
|    |  
|    |__Layer1Decoder
|    |__Layer1Encoder
|    |__Layer2Decoder
|    |__Layer2Encoder
|    |  
|    |__PeerAHandler                あるお客さんAの営業担当者
|    |    |__PeerAReceiver          受信 (連番管理、...)
|    |    |__PeerASender            送信 (連番管理、...)
|    |__PeerBHandler
|    |    |__PeerBReceiver
|    |    |__PeerBSender
|    |__PeerCHandler
|    |    |__PeerCReceiver
|    |    |__PeerCSender
|    |
|    |__Timer
|
|__ActionMgr       会社で言うと内勤部署。Transactionは、ActionMgrというベルトコンベアを通って、1件終了。
|    |
|    |__State1Action           状態ごとに違う動きするならステートパターン使う。
|    |__State2Action
|    |__State3Action
|
|__DataMgr         データ管理。会社で言うと経理、倉庫、金庫、資料室。
    ◇
    |
    |__*_DataEntry    アプリ実行に沿って増減するデータ
    |
    |__*_ReservedTransaction  社内で保留されてるトランザクション

RecvData
 △
 |__CommandAAARequest      PeerA からの要求 とか
 |__CommandBBBRequest      PeerB からの要求 とか
 |__CommandCCCResponse     PeerC からの応答 とか

SendData
 △
 |__CommandAAAResponse
 |__CommandBBBResponse
 |__CommandCCCRequest

---

は！しまった、ポリシーに反してアルファベットで書いてしまった...

凡例
持ち主 ◆---- もたれるひと
参照するひと ◇-- 参照されるひと
基底クラス
  △
  |__派生クラス

この本、楽しいです。

書名	著者
リーダブルコード より良いコードを書くためのシンプルで実践的なテクニック	Dustin Boswell/Trevor Foucher

昨日、Android関係の最新日本語情報が欲しくて、Amazonで下調べして書店に行ったのですが、残念ながら求めていたような本はありませんでした。

で、ふらりと一周しているときに目に入ったこの装丁。手に取って少し読んで、「ですよねー」と思って吹いてしまい、購入しました。

電車での往き帰りで読むのによさそうです。

---

あと、これも買いました。



何かの名著が有名になると、書名ではなく表紙の絵柄で○○本とか呼ばれることがありますが、この本だと何て呼ばれるんだろう…

ズビシ本

とか？

ペンギン。

【教訓】この季節は、週末の夜にうっかりドライブに出かけると、意図しない花火大会に遭遇します。
偶然花火が見えたらラッキーだけど、たいていは花火は見えずリア充の渋滞に巻き込まれるだけです。
ぉぃ前の車、後ろから見えてんだよ、と。きれいなシルエットになってんじゃねぇよ、と。

リンク	備考
分散システムのためのメッセージ表現手法に関する研究	古橋さんの 2012-04-02 のエントリ。MessagePackの説明

論文pdf公開、ありがたいです。ありがとうございます。
読ませていただき、MessagePack利用させていただきます。m(_ _)m

USBコネクタ仕様、3種。

運命共同体の意識がいいのか、きっぱり他社意識がいいのか。

私はある案件で、基本はきっぱり他社意識でないとダメなのだと、痛感しました。

見積もりを示しお客様に決めてもらう、できないことはできると言わない、やると言ったらやる、できる代案を出す、など大事ですよね。

でも断るときはいつも、悩みます。

英語より日本語の方が主語の省略に寛容と思う。
そこから連想。

ある意見があったとして、「誰が」そう主張しているのか、に対する厳しさが、日本人は薄くて、日本人は正しい意見は誰が言っても正しいと思ってるかも。

比較して西欧人は、意見には必ず「主語」が必要で、誰がその意見を言ってるかで意味なんか全く違うと思ってるかも。

つまりこうかも？

日本人の脳内
  主張者 ◇-- 意見

西欧人の脳内
  主張者 ◆-- 意見

---

別の話。

哲学っぽい話をするとき、説得力を増そうとしてたとえ話をすることはよくある。
しかし自分の経験が浅いことをたとえ話にすると、却って嘘っぽくなり、説教くさくなるのだなぁ。

気をつけよう。

スタックとキュー

ベストキッド：

「ワックス塗る。ワックスふき取る」
「ねぇコレ何の意味があるの？」
「これがすべての基本なんじゃよ」

PCキッド（旧時代）：

「スタックにつむ。スタックからおろす」
以下同

PCキッド（これから）：

「キューに入れる。キューから出す」
以下同

...ノイマン型コンピュータの基本の仕組みを変えなくていいけど、スタック方式じゃなくてキュー方式に変えようよ。

スタック方式ってのは、関数を呼び出して、戻ってくるっていう抽象化方式。シングルコア時代にはこれでよかった。

キュー方式ってのは、ベルトコンベア上のデータを加工するっていう抽象化方式。Unixパイプライン風、とも言う。マルチコア時代にはこれだ。


キューの実装はリングバッファでよい。

---

Indigo Girls の Ghost という曲の歌詞で、

I go follow to the river
 play your memory like the piper 

という一節があります。これ、コンピュータプログラミングにも発想応用できると思う。

---

Stack and Queue

The Karate Kid (1984):

"Wax the wall. Wipe the wall."
"What does it mean ?"
"That is the BASIC of all."

The PC Kid (old era):

"Pushing to the stack. Poping from the stack."
(same)

The PC Kid (new era):

"Pushing to the queue. Poping from the queue."
(same)

... We don't need change the Neumann architecture, but I prefer not a stack, but a queue.

Stack Method is the abstraction of a function call and return.
In the times of Single Core, it was enough.

Queue Method is the abstraction of processing a data on a belt conveyor.
It is just like a Unix Pipe Lining.
In the times of Multi Core, that's it.

The ring buffer may be good for implementation.

---

There is a song called "Ghost", Indigo Girls sing like that:

I go follow to the river
 play your memory like the piper

I think it can be applied in Computer Programmings.

---

Thank you for your attention for my poor English. chao.

ウソあり注意

C++ の 参照型って一体何なのさ？

void func(Hoge& hoge) { ... }

C++の 参照型 とは何なのか：

• 内部動作はポインタ
• ただしNullが入らない
• 字面上はポインタじゃない変数のように扱う

という認識で大体OK。


参照型ではポリモーフィズムはできない。

→なんで？

→C++言語の設計ポリシーに
> C++は、コストがかかることは、するのかしないのか、いつするのか、プログラマが選べる言語とする
があり、
> ポリモーフィズムは仮想関数テーブルを引くというコストがかかる。
> やりたい場合はポインタ表記のシンタックスを使う(ことでプログラマが明示可能とする)
と、決めたから。

変数.メンバ関数(); //単なるデータ抽象プログラミング
参照型変数.メンバ関数(); //単なるデータ抽象プログラミング(ただしメモリ実体の場所は外部から指定可能)
ポインタ変数->メンバ関数(); //ポリモーフィズム(=必ず仮想関数テーブルを引け、というプログラマからC++言語系への指示)

と、認識しています。私は。

根拠はスタンレーリップマン氏「C++オブジェクトモデル」。

(C++ では「メソッド」というのはなくて「メンバ関数」「静的メンバ関数」と呼ぶのが正しいです)

---

で、C++11 では

右辺値参照

というのが増えて

Hoge&& hoge;

と書くそうな。

現実的な使い方をお勉強中＆脳ミソ再構築中です。

---

と、書いたのですが、「ポリモーフィズムできます」と突っ込みを頂きました。

もちょっと確認します。orz

---

確認しました！

参照は、多相性に関してはポインタと同じです！

すいません。ウソつきました。

ということで正しいことを書くと...

---

C++言語の設計ポリシーに

C++は、コストがかかることは、するのかしないのか、いつするのか、プログラマが選べる言語とする

があり、

ポリモーフィズムは仮想関数テーブルを引くというコストがかかる。
やりたい場合はポインタ表記 または参照表記 のシンタックスを使う(ことでプログラマが明示可能とする)

と、決めた。

変数.メンバ関数();           //多相性をサポートしない
参照型の変数.メンバ関数();   //多相性をサポートする
ポインタ変数->メンバ関数();  //多相性をサポートする

---

ならウソではないですね。
多相性に関してはポインタによる表記と参照による表記は同じですね。


以下、私が間違って記憶していた情報を正確な情報で訂正するために必要な範囲で引用。
スタンレーリップマン氏「C++オブジェクトモデル」














19ページ、21ページ、26ページに明記されています。
一体なぜ勘違いしてしまったのか謎ですが…


ということで。ごめんなさい。

// AKIRAさん、タイムリーツッコミ（適時指摘）ありがとうございました。

えーと、すいませんなんか最近おかしくなってます。自分が。

なんとなく、イーストウッドが主演のタイトロープっていう映画のことを思い出しています。

リンク	備考
Howto for fglrx / catalyst (Ati driver)

亜鉛アレルギーの対策で、歯につめていた金属を取り除くことにしました。セラミックと樹脂の素材のものに変えます。

目下、一発目を削って型どりし、発注していますです。来週にはジャキーンと合体する予定です。

気分は改造人間。

大物一ヶ所につき

• セラミックのみ = 3万円
• セラミック＋樹脂 = 2.5万円

とのこと。あっしは2.5万円を選択。

そして全部で10万弱かかる予定。トホホ…

今年は医療控除の対象になるのがほぼ決定です。

最近、うちのサーバが外から見えない事がよくあります。ご迷惑をお掛けしてしまったらすみません。

どうやらダイナミックDNSの更新で失敗している様です。何とかしてみます。

gihyo.jpの美崎薫さんの連載記事。

リンク	備考
Lifelog～毎日保存したログから見えてくる個性	gihyo.jp

コンピュータを使って，日常のさまざまなことの記録（ログ）をとり，
それを分析して活用することで，もう一段階上の「楽な生活」をめざす日々の研究報告です。

だそうです。

「ボタンを減らせ」の記事にて、ジョブズのポリシーを引き合いに出して、でもジョブズとは別の解を見出しているとの言葉があり、興味深い。

バックナンバーも読めるようになっているので、今度ちゃんと読もう。

---

ところで、今日 月曜日のテレビ東京 WBS (23:00～) で、「ライフログ」特集ありとの事。

フラッシュ映像はなんだか面白そうだった。今日は寄り道せず帰ってオンエアで見たい。

誰か読んでくれてるのか？

おーい！


わーーー！

中学生高校生ぐらいから、ずーっと独り言ばっかり言ってる気がするんだぜ。

言いたいことが
誰にも通じてない気がするんだぜ。


うちに来るのはリファラスパムロボットばっかりか。

ヤエー!

虫歯治療の金属をセラミックに変えたった！


ここまで10万円ちょっと！
もうすこしかかる！(T_T

真横に向かって生えていた親知らずを抜きました。

先生が「これ抜くときは次の日は仕事休みのほうがいいです」って言った意味がわかる気がする。

今日の分は歯科の範囲ではなく、口腔外科の範囲だそうです。少し縫ったので、一週間後に抜糸です。

親知らず、続き。

抜いた側の下顎が、まだ腫れています。

痛み止めが切れると痛いです。
そして痛み止めを飲むと眠くなって何もやる気がしなくなる。

こんなに時間かかるとは、正直思ってなかった。きついです。

---

小林選手がF1鈴鹿で3位。おめでとうございます。

なんだけど、フジTVのモータースポーツ実況は相変わらず酷すぎる。

特定選手をひいきする視点からの実況は副音声でやれよと言いたい。
カメラスイッチもひどい。いくら一人旅のレースでも、ファイナルラップは1周通して1位を追うのが常識なのに、映すのは3位争いばかり。
挙句の果ては表彰式。優勝選手の国歌が流れた直後に1位にも2位にも触れずひいき選手の話。

SuperGTが1年フジだった時も酷かった。SuperGTに関してはテレ東に戻って本当によかった。

フジは視聴者がスポーツ中継に何を求めているのか全く考えておらず、旧来の「俺が世論を作る」理論で動いているとしか思えない。

まるで、変化に対応できず絶滅に向かう恐竜のようだ。


人のふりみて我がふりなおせ、だな。

体壊しました...
東京駅のトイレで吐きながら、帰り着いたらこれからの生き方を真剣に変えようと思いました。
昼前に家についてひっくり返っております。

病院のセンセイ曰く食中毒(の疑い)とのこと。
でしたが…検査結果の連絡がまだこない。

ワタシ、体調がいいときの体重は58kg以上で、そこから1kg減っても疲れやすくなります。
今回は5kgほど減ってしまいました。

意図せず増えてしまうひとも大変だと思うけど、
意図せず減ってしまうのも大変なのです。

なんとかしたい。

警察官てバカしかいないのかね。

最近の、ネット上の行動に対する誤認逮捕の件です。
「IPアドレスで犯人を特定できる」とか、
「VisualStudioは特殊なソフトだ」とか、
どんなバカものなんだよ。
海外に伝わると思うと恥ずかしくて悶え死ぬレベルだわ。

警察官って基本的に変なひと多いよね。
第一、現代社会で警察官という職業を選択する事自体が、普通のビジネスマンとは全く違う。
自衛官とも違う。
個人事業主として働くのも普通じゃないけどね。

警察官について、過去に「大人の頭で冷静に考えて、どう考えてもおかしいだろ」という実体験が3つほどある。
そのこともあって、私は警察官を利用しようとは思うが、信用することはできない。

勤務地から遠いマイホームってのは、家族が待っているからこそがんばって通える≒帰ることが出来るのだねぇ。

なんだろうか、この拷問は。

おかしなエラーメッセージ

仕事で、また「おかしな英語風の言語」にイライラ。

いい加減にしてくれ、通じる言語で書いてくれよと思う。

その意味不明なエラーメッセージは、誰に何を伝えようとしてるんだゴルァ

おかしなルーチン名

ルーチンの名前もおかしい。（今、誤変換で ルー珍名 と出て思わずワロタ）

プログラミングのパラダイムは時代とともに発展し、転換していきます。
けども。ある時代で止まってるプログラム設計会社があるんですよ。おそらくたくさん。

日本語で設計書を書くとき、ルーチンやメソッドに体言止め風の名前つけるの、いい加減に止めようよ。

「設定ファイル読み込み」とか。
「設定ファイルチェック」とか。

和名でそういう、80年代みたいな、構造化プログラミング全盛時代みたいな処理名つけてるから、英名を

ConfigFileRead
ConfigFileCheck

とかつけちゃう子が出る。そりゃそうだろ。
そんで、ベテランもそれをレビューで指摘・修正できない。

英名を

ReadConfigFile
CheckConfigFile

てつけるんだったら、和名も

処理名：[設定ファイルを読む]
処理名：[設定ファイルをチェックする]

てつけなきゃダメなのよ。（する までつけるのが大事）

ありえないと思った？ なんで？ あなたが感じる違和感を、明確に説明できますか？

その違和感を、英語圏のひとたちは90年代にはもう飛び越えたんだよ。

今は00年代もすぎて10年代だってのに。

この、{プログラミング|自然}言語の感覚わかりますかね？

家を建てるならまず土地を平らにするでしょ

自分の母語を通じて言語そのものを考えられない人が、プログラム言語という記号言語を使って働いているのは滑稽だ。
ソースと同じ内容を書いて（書きすぎて）ハマってる設計書。
ソースを読めない人が見る設計書を書くことに、何の意味があるのだろう。
マシン語で作るならまだしも、高級言語だよ？
人間が普通に仕様をざっと見ることができるレベルのソースと、細かいプログラミングロジックを書くソースとでレイヤを書き分けできるだろ。そうすりゃソースと二重管理のフローチャートなんて、書かないで済むんだよ。
できないのは、プログラミング言語の問題じゃなくて、書き手の言語感覚に問題があるんだよ。
名前づけが悪いのは、病状の中でも本当にたちが悪い。

おかしな名付けでプログラムを作るのは、歪んだ土地を平らにしないで家を建てる事のように見える。
あるいは、とのこやサーフェーサーを吹かないで荒い面に塗料を塗っているような。
プログラミング言語の前に、自然言語で箇条書きする研修をやらないと、まっすぐの家を作れないんじゃないのかね。

今日分かりました。なんでフローチャートが必要か。

多分、お仕事風に書いても1.0kstepに満たないくらいのところなんですけど、フローチャートの時点でバグがあるのを見つけました。

で…邪推すると、

いや…、はい。黙ります。



私も今でこそそれなりに白い紙からプログラムを書けますが、昔は全然書けなかったものです。
誰しも最初からできるわけではない。
おごりはいかん。

「今自分が立っている場所が、今の自分の実力にふさわしい場所だ。それ以上でも、それ以下でもない。」

と、頭の中で誰かが私に繰り返します。


事業継続性っていうか、サスティナビリティっていうか、子供が育って世代をつないでいくこととか、なんか大変ですよね。




最近…に始まったことでもないんですけども、電車に揺られて、隣のひとに押されたり足を踏まれたりと、ちょっとしたことがきっかけでキューっと思考が迷子になり、自己否定で身の置き場のないような気分と、自己肯定で酔っ払ったような気分が、サイン波のように交互にやってきます。
ある人がこういうような現象を、自分だけで勝手に"飲食店の昼ピークになってるようだ"ってことで「一人ピーク」と呼んでて、なるほどなぁと思いましたよ。
その波なんですけど、なんだか少しずつ、波長が短く、振幅が広くなっているように思うけど、まぁ気のせいかもしれない。

---

うーむ。冷静に考え直したけど、やはり、JISフローチャートを描いてる現場は、正規分布の真ん中ではないし、むしろアウトライヤーだろう。

この件に自分が何をすべきかが見えた。確信した。

何かにつけて子供たちの事を思い出す。
そして、してやれなかった事、優しくできなかった事をを思い、中二病を思い出した時のように苦しくなる。

• 自動販売機でコーヒーを買う
• 街でベビーカーを見かける

今日は仕事場の昼休みで食事に出かけたら七五三参りの母娘とすれ違った。

七五三てのは、…昔は子供の生存率がよくなかったため、ある程度育つまでの子供は神様のものという風に考えていた(そして悲しみを抑制した)のだとか。
それで、ここまで無事に育ちました、と神様に報告するのが七五三なのだそうな。

と、そんな話を思い出して、また中二病を思い出したようにモヤモヤしておりました。

ぬおおお
そば食ってる間にアンドロイドが3回もリブートしやがった

昨日は信号のない横断歩道で車に轢かれて逃げられるし

気の持ちようなんすかね

ギターの弦は、テンションが高すぎるとポソポソでサスティーン（継続性）がなくなるんだよね。

仕事も同じじゃないだろうか。どうだろうか。


別の話。
自動車社会と言われるアメリカでは、日本と比べて「急発進・急ブレーキ」の運転が多いのだとか。

仕事で「急発進・急ブレーキ」を繰り返してはいないだろうか。それを臨機応変だとか、機転がきくとか言っていないだろうか。



また別の話。
ふと、自分の問いの答は自分の中にしかないのではないかと、思う。

コロコロと変わるルールによって競技していても、運営者に踊らされるだけだ。そんなルールには乗らず、淡々と信じる方向へ進みたいと思う。

自分が何をしたいのか、て実は難しいんだよねぇ。
そもそも目的があって生まれてきたわけじゃない。


数週間前だったか、ある人が、ふらりと愛車のジープ・チェロキーに乗って旅行に出かけた、という話を聞かせてくれた。
話し方が上手いのか、その旅自体が良かったのか、とてもおもしろい話だった。

目的もなくふらりと旅行に出かける。旅人は、しばらく気ままに進んだあとに「この旅のテーマを何か決めて、テーマにしたがって行動してみよう」などと思い始める。

テーマを決めたら、一体どうなんだ、ということは、特にない。けど、テーマにそった事をたくさんすることで何が得られるかというと、旅から帰って、その旅を振り返ったとき、そしてその旅の話をだれかに面白おかしく話して聞かせるときに、

こんな行動テーマにそって、一つの事をいろんなところでやってみたよ

と、披露できるネタになる。


例えば、夕日の写真を必ず撮る、とか。例えば、おいしい食べ物を食べた記録をつける、とか。



楽しいことなんて、自分で無理やり作り出すものなんだよねぇ。

数年前、千葉の妙典に住んでいたとき、僕はそこから神奈川の戸塚に片道1.5時間かけて通っていた。8:30始業だったかな。今思えば辛かった。でも、何か楽しい事をしてやろうと思って、こんなゲームをし始めた。

東西線の大手町から、JRの東京駅に乗り換えるとき、ガード下の数十メートルの路地を通る。
この路地を歩いている間に、赤いネクタイの人とすれ違う数と、青いネクタイの人とすれ違う数で、どちらが多いか、
その日の朝、自分で勝手に賭けて、自分で数えて、よし今日は勝ち、今日は負け、とかやる。

黄色やら紫が多くて今日は勝ち負けわからん、なんていう日もあった。
でもそうやって、つまらない通勤を何とか楽しくしようとしてみた時期があった。

何をどう間違ったのか、今はその同じ路地を反対向きに通って、片道1:50かかって仕事場に行っているのだけど、まぁそれはまた別の話。



人生も、もしかしたら「目的を決めずにふらりと出た旅」のようなものかもしれない。

最初は右も左も分からず、歩けるあたりをウロウロする。

そのうち様子が分かってきたら、「テーマを決めて行動してみよう」などと思う。
それは自転車で世界を一周してみよう、なんてことかもしれない。あるいは、自分で作った歌をギター弾いて歌って1000人に聞いてもらおう、なんてことかもしれない。

テーマを決めて何がうれしいかっていうと、別にどうってことはないんだけど、旅から帰ったとき、その旅の話を誰かに面白おかしく聞かせる時に、ネタになる。



人生で何をするか、なんて、そんなものかもしれない。

宣言します。

今後、納品ドキュメントにフローチャートを書かせる開発案件は、二度と請けません。

誓います。


教育なら有り得るかもですが、それにしたってフローチャートは、無いです。

こんな事をしてたら、日本からソフトウェア産業が消滅してしまう。半導体産業が絶滅したのと同じ様に。



好き嫌いとか、わがままとか、そう言う話ではありません。
そんな事にお金をかけても、ソフトウェアの品質向上になんか、全く貢献しない。それどころか悪影響が多過ぎる。








とても悲しいです。

唐突ですが

UMLの一番いいところは何？と聞かれたら何と答えますか

私は、(ソフトウェアの図解において)

データ構造の親子関係に引く矢印の向きが、統一されたこと

だと思います。

親と子ってどっちがどっちよ？ってなりますが、ここでは

親＝よりシンプルなデータ構造
子＝より枝葉がついたデータ構造

とします。

昔は、矢印が 親->子 だったり 親<-子 だったりしたんですよ。それが統一されて 親 ◁-- 子 になりました。これはUMLの、大きな功績だと思います。

矢印と言えば、箱と矢印を描くときに、どっちからどっちに矢印を引くかってのも「語れるテーマ」で、UMLコラボ図の「結ぶ線には矢印を描かずに、注釈的に矢印を描く」やりかたは、一つの発明であると言っても過言ではないと思います。
けど、それはまた今度。

みなさんは冒頭の問いに、何をあげますか？

Android版Firefoxがまた新しくなったとのことでまたインスコしてみたけど、安定の使いにくさだった。

毎回、試すの面倒だから、どこを目指してるのかを明示して欲しいわ。

# メッセージキュー
PARA(){# メッセージキュー}

リンク	備考
UTF-8 Everywhere

後で読む。最初と最後しか読んでないけど、最後に出てくる real-world programmers という表現になんかぐっと来た。

実世界のプログラマとして、象牙の塔のプログラマさんにはいつもいつもいつもいつもご迷惑をおかけしております、えぇ。

いやまぁ皮肉はさておき、サイトの趣旨に賛同できそうです。


実は私は、某お茶の名前のプログラミング言語のように、あらゆるプログラミング言語処理系はUTF-8の識別子を受理して欲しい、という希望を持っています。
その前段として、プログラムが扱う文字列バッファが全世界でUTF-8に統一されるのは好ましいことだと考えています。

公正取引委員会からの調査（親事業者との取引に関する調査）に対する回答を作成しました。

久しぶりです。



まぁこういうのって言いふらすものじゃないですけど、うちらのところにも、たまにこういう調査は来てますよ、ということを公開するのは、悪いことではないと考えます。

私は、コードを書くときにこんな事を心がけます。

• 本質を見抜く
• 名付けを真剣に考える
• リズムを揃える
• 読んでくれる誰かに敬意と優しさを表す
• 同じ事は同じ様に、違う事は違う様に
• 一つの事は一つで、複数の事は複数で
• コードを書く事は一期一会

馬鹿丁寧なコメントは、読み手に敬意を払っていない。コメントをつらつら書いてあるコードよりも、本質をついたコードの方が分かり易い。

幾ら分かり易くと言っても、ITプロジェクトは、壮大なバンド演奏の様な物。小さなミスでいちいち録り直してたら、スタジオ料金で赤字になってしまう。その瞬間は今そこにあって、他にはない。
次はもっと上手にやろうと心に留めて、先の小節に進む事も大事。

---

一生のうちで、あと何キロ書けるだろう。
一年に5から15キロ書くとしたら、それに就労年数をかけるとおおよその数字が出る。
そして、お前はそれで満足なのか？と言う誰かの声と対話する。

モヤモヤしているものが、少しずつ晴れていく様な錯覚をする。

明日も頑張ろう。

がんばれ俺、超がんばれ、負けてんじゃねぇぞチキショー

ここに問題をボヤきましたが、ボヤいて済む問題じゃないので正式ルートで処理中です。

この週末は、色んな事が有り過ぎて目まぐるしかった。

5年前の自分だったら、「あんな事をするべきだったろうか」と頭を抱えてしまうような事が

仕事で1つ
親しい人間関係で3つ
お店との関係で1つあって、

でも、ある意味、流石にオレも年取ったなぁと思う位、「あの行動で間違ってなかったぞ」と思っています。


過去に、自分のやりたいようにやり過ぎて「なんであんな事言ってしまったんだろう」と後悔する事もあった。反対に、主張するべき事を主張できなくて、「あの時こう言うべきだった」と後から怒りに震える事もあった。

でもこの週末の出来事は、自分の中で納得できる。

間違ってないぞ、と。

---

そのうち、お店の話。

• タイヤの発注したのを忘れてすっぽかしてしまった
• けど、ちゃんと解決したので大丈夫だ

という話を、さっき一生懸命ここに書き込んだのだけど、

スマフォの操作ミスで(書きかけページのPOSTを再送してしまって)

消してしまった...。


もう一度書く気力がないので...


orz

先日、エントリをPOSTの再送で上書きしてデータを失ってしまった件の考察。
実は過去にも1回やったんですよね。その時もスマートフォンからのアクセスでの操作ミスでした。


このWikiって、データベースが「ファイル」なんです。
RDBじゃなくて。

種々の条件でRDBにするのは無駄だと思ってるんですが、あまりにも上書きミスに弱いので、妥当なコストの良策はないかと考えてしまいます。

ファイルシステムだけに基づくバージョン管理システム、例えば CVS 等をWikiのデータベースにしてみようか、と思ったり。

まあ今なら git とか マーキュリー とかの分散型なんだろうけど、依存システムが増えるとその分面倒になる。
理想は切り替えが容易になるような抽象化レイヤを作っておくことなのかな。


運用はどうだろう。

あと、データレイヤじゃなくてHTTPの動きでなんとかできるのかも。
RESTful 化も保留になってるし、久しぶりにWebシステムを触るかなぁ。

突然ですがタバコの話。

私はタバコを吸いません。

新鮮なタバコはいいんだけど、吸殻とか、古くなったタバコの匂いが、とても苦手です。
自分の衣類や髪の毛にタバコの匂いがつくのも苦手。
できれば自分の部屋では誰にもタバコを吸ってほしくない。


んだけど、自分の知り合いで、この人はおもしろいなぁと思う人は、大抵タバコ吸います。
ソフトウェア関係の知り合いも、音楽関係の知り合いも。

// あー、合気道関係の知り合いではタバコ吸わないけどおもしろい（知的で興味深い）ひとはたくさんいたなぁ…。


タバコ吸ってるひとと友達付き合いはしたいけど、古くなったタバコの匂いは嫌い。

この矛盾をどうするか。


んで思考が迷路にハマった挙句「自分もタバコ吸おうか」なんて考えたりしますが…

いや…違うな…


自分が「タバコ吸わないおもしろいひと」を目指せばいいのかな。

人生我慢も必要だよね、などといろいろ考えたけど。

色々と要素はあるのだが、2012年現在、C++のnew失敗をNULL比較で行う事を正式に決定してしまうチームには、どう頑張っても僕の居心地のいい場所は作り出せないな。

という事で、納得。


全てを得ようとする事は、何も得ようとしない事と同じだ。人生を能動的に選択していこう。それだけが独立したメリットなのだから。

久しぶりに黒田硫黄さん原作のジブリの自転車映画を見たくなって、借りて、見た。

難点は色々ある。いくら地元とは言え、あんな手前から一人で逃げて、最後のスプリントで勝てる道理がない。
大集団からの逃げに加わるような実力ある選手が、下りで落車する動きが稚拙すぎる。

だけど、改めて、名作だと思った。
いい所は、本、つまりその元はあの独特の黒田さんの味、に尽きると思う。

ただ悲しいのでも辛いのでもなくて、切ないんだよね。

2003年て事は、もう10年前の作品なんだなぁ。

---

ワタシは、実は大学の1年だけ、体育会の自転車競技部に所属して、週に250キロくらい走ってました。先頭交代とかしながら。

当時のシマノ105は、まだダウンチューブにレバーを付ける形だったんですよ。何て言うと、若い子から急に異次元のジジイを見る目を向けられるんだよね。

今、日常の足としてバイクか自転車を買い直そうかと思うのだけど、はて、と。

そんな話です。

もう年末になってしまいましたが、喪中につき新年のご挨拶をご遠慮申し上げます。
叔父が10月に亡くなりました。
本年お世話になった方々に深く感謝いたします。
今後ともよろしくお願いいたします。

---

厄年というのは、ちょうどそのくらいの年齢で人生の転機が訪れる、ということだと言われます。
自分にもまさに様々なことが起こっていますが、一つ一つ、噛み締めて向き合っていきたいと思います。