kozawa のたまに気になること

<< May 2012 >>

リンクの少ないでもぶろぐ・・・にせぶろぐ？

2012.05.17 Thursday

OSC Nagoya 2012

オープンソースカンファレンス2012 Nagoya - オープンソースの文化祭！に少しだけ行ってきました。

まぁ、色々他の予定との都合があってあんまり居られなかったんですけど。あと、あちこち体を痛めていてたちっぱがつらかったのもある＞＜。
時間の都合その他で聞けたセミナーはオープンソースカンファレンス2012 Nagoya - イベント案内 | 2012-05-12 (土): 全てのエンジニアのためのWeb標準技術とのつきあい方だけでした。

講演の50分の中で講師が「こんなことを言うとMozilla Japanの浅井さん（dynamis）にお壊れるけど」とかざっと数えて7回ぐらいは浅井さんがどーのって言ってたと思う。満席すぎて座れなくって足が痛かったの…。

その他ブース感想とか。OSC浜松やる予定なんだー。浜松ぐらいの都市でやるのはそれはそれで地元へ広がりやすくていいかもね、とか。Mozilla Japanブースは人が多くって、昼過ぎ浅井さんが休む暇がなさそうだった…。LibreOfficeのアンケートに答えたり。毎年恒例スタンプラリーやってきたり。それにしても萌えキャラを全面に出したブースの多さが。増えましたねぇ。傾向として中小企業でわざわざOSCに出展する企業により目立つ気がしたのは気のせいなのかなんなのか。コミュニティ系でもわんくまさんも同人誌かわいいし（本の中身もコミュニティも勿論いいですよ！）、プロ生さんもいいキャラしてるし。まぁいろいろで思い出したらまだ書く事はいっぱいありそうだけどさっさとアップしてしまおう。

Check

2012.05.12 Saturday

plug and pray

plug and prayというのはITスラングで、PnPとは【Plug and Play】（プラグアンドプレイ） - 意味/解説/説明/定義： IT用語辞典を皮肉って、「指したら祈れ」（動くかどうかは神のみぞ知る）というまぁ、ITエンジニア系の人なら有名なネタというアレですが、そういうタイトルの映画が2010年制作で、存在します。ネタではないエンジニアリングに関するドキュメンタリーのようです。

…っていうか昨日存在を知ったので見たいなぁと思っただけですが。日本の研究者へのインタビュー（日本語）も出てくるようです。

公式サイト（ドイツ語）　Plug ] Pray – Ab 11. November 2010 im Kino – offizielle Seite
英語での公式サイト　Plug & Pray - Documentary film - Artificial Intelligence - [[[maschafilm]]]
映画情報（英語）　IMDb - Plug & Pray (2010)
予告編（英語）　Joseph Weizenbaum: Plug & Pray (movie trailer) - YouTube
日本語で書かれた紹介　2011-10-04 - ./configure --with-blog=nakazawa　(中沢実)
日本語で書かれた言及例　Twitter / @getrobo: ドイツでロボットに関するドキュメンタリー映画「Plu ...
映画祭で賞を取ったようだ　バイエルン映画賞2011 発表！海から始まる!?/ウェブリブログ
英語版のDVDはamazonで買えそうだけど。見てみたいなー。

Check

2012.05.10 Thursday

GeekBar 名古屋 5/7参加

疲れました。
死んでました。

とりあえず@dominion525ちゃんに依頼された著作権に関する与太話をしました。
後から「専門的な細かいところはいいからもっとわかりやすくはっきり言えばいいんだよ！」って言われたけど、著作権の専門的な所は本質的に断言しづらいとか説明が素人向けには難しいというのは勿論理由の一つだけど、ちょっとまぁ自分の立場上、間違ってるとわかってることを大声で断定するのはちょっとやりたくない事情があるのです、この手のテーマに関しては…。ごめんよーどみちゃんと聴衆のみなさん。

この日の他の登壇者はあきらX (akirax052) は Twitter を利用していますさんによる、コワーキングスペースArt Factory アートファクトリーの紹介！

今後が期待ですね。いいスペースが各地に増えるのはいいことです。

次は@miyauchiさんの自己紹介とdddav - フリーなWebDAVクライアント for Windows紹介。熱いですねねー。

次はniccolliさんの名古屋Node予備校 vol.1 : ATND紹介でよかったのかしら。行きたいよー＞＜

次はゲームメーカー「株式会社ドラス」でインターン中の名古屋の専門学校生ゲーム婦グラマー安藤琢磨さん。過去にサイバーコネクトツーでもインターン経験あり。アグレッシブ。今までの彼のゲーム一覧ってどっか余所で見れないんですかね。。。楽しみだよ！何かのアカウントでリンクしたかったけどよくわからんかったごめんなさい。ダウンロードしてそのゲームやりたいの…無料のってないのかしらん。

私がいた中で最後はP.I.akura[就活中] (akuraru) は Twitter を利用していますさんのなごやかScala #1 - [PARTAKE]紹介。面白そうです。Discussions - 名古屋Scala勉強会 | Google Groupsがレベル高すぎるから別途始めたという割にメンバーが似てるじゃないかって話は私は別にいいじゃんと思いますが、安藤琢磨さんに「scalaって何ですか？」って聞かれたときのakuraruさんの答えが微妙というか怪しかったのが一番心配でしたけど、きっとすぐになごやかscalaの中でレベルアップされると思います。あ、いえ、私は、うん関数型言語とかもっと勉強しなきゃの素人さんですのでいぢめないでね！

Check

2012.05.06 Sunday

理系文系学メモ

これはネタです。

理系文系学といえば[理系文系] - 思索の海、はてなブックマーク - 思索の種 - 理系文系は前提だと思いますが（まてこら）。

以下、整理してまた後日どっかに何か書くためのブレインストーミング的メモ。

・理系文系の歴史は後で調べるかもしれない
・まともな研究はそれはもちろんあるはずだからそれを先に調べろって話だけど後で調べるかもしれない

・理系/文系
現代日本では大学受験のための高校の分類が一番の土台と言ってよいのでは？
大学受験で理数と国社のどっちを重視するか、とそもそも理数と国社のどっちが落第せずに卒業出来るか、の２点が土台？
理科と数学、国語と社会には得意不得意の相関が多分ある…でも当然人によってねじれもあるよね（数学得意でも理科はダメとか、国語と社会の間のねじれの方がもっと大きい気がするけど気がするだけなのでそのうち調べるかもしれない）
・大学受験でどうしてそういうのが必要なのかの最大理由は大学で学ぶ内容であるはずで、その理由であるはずの学ぶ学問そのものに傾向を指して理系学問、文系学問という分類があるので世間的にはこっちが定義っぽいけど、自分的には「高校のクラス分け」の方が本質だと決めつけている（逃）
→この大学以後で学ぶ学問の理系文系分類を含む社会での理系・文系の意義はある程度理由は調べて書けばそれらしいものが書けるはず。お題目としてのそれすら書けないとしたら日本って一体どうなっているのって話になってしまうような気がしないでもない。

・理系/文系にまつわるあれこれ
・学問としての理系/文系。どちらともつかないものがある。また二つに割って違和感のないものだけを取り上げたとしても、その先の学問は多様すぎる。工学部と農学部と医学部の学問の様子は似ているか？経済学と言語学はどれほど似ているか？（学部レベル的分割と学科レベル的分割でも見え方が随分違うのが分かるような例を敢えて挙げてみた）
・理系/文系と人の性格との相関。疑似相関が多すぎないか。理系は文系より男性比率が高い（男女比問題は戦前の日本の大学とかを持ち出すとどっちも女性少ないので比率は言うほど違わんじゃんとかなりそうだが）etc。
・理系/文系と類型の影響。理系というと人数では多分工学部が学部レベルでは最大派閥なので工学部のイメージで勝手に理系を代表していないか（工学部の中の多様性も勿論色々だが）。数学科の理工系と二つ合わせただけでかなりまとめてしまって農学部を無視してないか？工学部と理学部数学科ってそんなに近いか？　→所詮便宜的な分類なので例外ケースはどうでもいいって言い切られると、この類型の問題は一部終わってしまう気もするのだが。
・受験の都合で理数、国社とわけたが、数学と国語を脇に置くとして、物理、化学、地学、生物ってそんなに似ているか？日本史、世界史、倫理、政治・経済ってそんなに似てるか？（得意不得意や隣接内容の程度が今挙げた二つのグループの間より中の方が強いであろうことはあえて検証するまでもないと思われるが、それだけで終わる話なのか）　関連話題だと理科の中では地学や生物の方が文系寄りの扱いをされているとは思う
・理数と国社には定義上（？）入らないけど受験で大抵使われる英語（orその他外国語）は、時に理系からも文系からも「あっち側」呼ばわりされることがある（もちろん同じ頻度ではないんだけど、見た限り、理系が理数の一部を、文系が国社の一部を相手呼ばわりするよりは多いのでは？）
・自称理系や自称文系が社会に存在する「理系はこうだ」「文系はこうだ」の影響を受けて自らそれに近づいて行っている面はあるのでは？（自分にはデータ的根拠はない）
・理系/文系「学問」と理数/国社の関連が相対的に強いのはきっとそうであろうし、理系/文系の学問の「現状記述」としての傾向は調べればその他にも抽出・記述は可能であろうけれど、それらが理系/文系にとって今後も本質的特徴であるのかどうかはいったい誰が決めるのか。

・理系/文系のその他の弊害
理系だから国語が出来なくてもいい的風潮、文系だから数学が出来なくてもいい的風潮を助長することは社会にとってマイナスではないのか？
（個人の選択として得意分野や進路が理系/文系で逆の科目が不得意だから一方側の科目だけで生きる道を選ぶ、というのを否定するわけではない。社会で助長することを問題視している）

・理系/文系から広がるほとんど誤解？
・科学といえば理系　…ちょっと待て感があるけど、これはまだ記述的な話をするとまぁ、あれだ。
・理系が論理的　…こういう物言いはどちらかというと自称理系に目立つのだけど言いたいことが山ほどあるとかなんとか
→デムパ的言論に所属が文系の研究者が目立っていたりはしないか（目立つのと多いのとは違うのに注意）。国語は非論理のイメージ、国語教育に感性・感情も勿論含まれてはいるのだが、「作者が言いたいことは何か」という単に文書読解の問題すら感性という誤解が結構あるのでそういった事と関連があるのではないか等
（この他にも挙げたらきりがないけど、最初に挙げたブクマに色々あるからまぁ後はいいや）

・その他
今の日本のシステムの問題や海外との比較とかこそニーズがありそうだけど、私がぐだぐだ余計なことを言う所ではないので逃げる。

もしかすると後で気付いたことを直したり加筆したりするかもしれないけど、ネタなのであまり期待しないで下さいましな。

Check

| - | 09:49 | comments(0) | trackbacks(0) |

2012.04.26 Thursday

Excel方眼紙つづき

Excel方眼紙について以前書いた所なんか検索エンジンでたどり着く方も増えて私の書いた内容に失望された方とかいらっしゃるようなので、もうちょっとましなことを書いてみましょうか。

これは、決して、名古屋アジャイル勉強会の次回のネタとして話題になっていたからではありません。偶然です。

せっかく書くので、これは公開したら終わりじゃなくて、後で思いついたらとか、フィードバックをもらったら加筆や訂正とかそういうのをするつもりでいきます。

Excel方眼紙というテーマで考える時、一つ考えやすいのがWordとの対比です。

ExcelとWordという比較で、Excelが望ましい場合とか双方の利点・欠点を考えてみましょうか。
もちろん、そもそもが目的の違うソフトウェアを勝手に同列に並べているので本質的な比較ではありませんが、今回のテーマにとって都合のいいように特徴を解釈します。

例１）表形式で計算のあるものが主体の文書
これはまぁ、表計算の本来の由来に比較的近いものなので、Wordでもできますが、これをExcelでやったからってそこまで責められる筋合いはないと思います。

例２）表が主体で表の集計等のある文書
これも、表計算ソフトの発祥ではないですが、DB的機能も増えていった現在の表計算では当然みたいな機能なので、Wordでもできないことはないにしろこっちでいいんでないでしょうか。

例３）自由記入回答項目が複数あるようなアンケート用紙のような文書で、回答者達から集めたあと機械集計したい文書
まぁ、これもWordでできないってことはないんですけど、VBA for Excelやらcsv等の形式にしてからスクリプト加工とか考える気持ちはわかりますので、少なくともこれがExcelだからって腹が立ったりはしません。
※まぁ、Accessじゃだめなのか、WebアプリでバックにDBつんじゃいかんのかとか色々別の方面で気になることはありますが、まぁExcelの利点が上回るケースも多々あるのではないかと。

例４）いずれにも該当しない文書
…ってExcelでやる必要があるんでしょうか。

Excelが好まれる理由って…。
Excel方眼紙に限ると

Excel方眼紙は表等の罫線の幅を揃えやすい Excelの技：すべてのセルを正方形にして方眼紙のように！：PC Online　
Excel方眼紙で文書を書くと、段落とかインデントを揃えるのが楽（等幅フォントでない場合に、空白文字でレイアウトとかしようとするとよくずれます。これはWordでも勿論対応可能なのですが、Wordのインデント機能を使いこなせてない人が多いということはあるのではないかと）
表の中身の文字数が増えた時とかに罫線（レイアウト）を維持しやすい　→はみ出したらExcelだろうがWordだろうがどのみちなんとかしないといけないんですが、特定のセルだけ文字サイズを縮めて罫線をピクセル単位で維持すること自体はExcelの方が楽な気はします。表が下に伸びてもいい、改頁が発生してもいいと思うなら、Excelの優位性はだいぶ下がります。
複数シートを使った頁切り替えが可能。
- シートのメリット１）あるシートでの作業は別ページに影響を及ぼさない　→頁改行とか使えばWordでも影響は分断できるんですが
- シートのメリット２）シートの切り替えで頁の移動が楽　→Wordでも章ごとのジャンプを可能にする機能自体はあるんですが、定義しないといけないのは面倒な人には面倒かも
- シートのメリット３）図を書くときに、書き終わってからそのシートだけサイズを決めたり、書いてる最中に後続頁の再レイアウトに悩まされたりしない

逆にWordにデメリットは？上記以外だと

ファイルが巨大になると不安定になりやすい　→Excelもならないわけじゃないんですけど、同じ文書量だと体感的にExcelのがはやく不安定になりやすいかも…。
表が必要な時罫線を揃えるのが難しい　→方眼紙式レイアウト調整が大前提ならWordよりExcelが楽って言われるとそうかも。方眼紙でなければ、両方をちゃんと使いこなしている限りその差はそこまで多くないような気がしますが、「差がない」という自信は全然ありません。

じゃあ、Excelの欠点はなんでしょう。

WYSIWYGのようでいて、印刷すると画面で見えていたものが切れたり###になったりする　→　Wordでは起きえないとまでは言わないですが（プリンタとドライバ関係の都合で）、Excelほど頻出する心配はありません。Wordでもできて、Excelプレビューでもできることなのですから、印刷との差異がないように計算して表示することは技術的に不可能というほどではないはずなのですが、その部分がいつまでたっても変わらないのは、修正すると内部や他の機能への影響が大きいので手が出せないのか、表計算でセルがやまほどあるアプリだと速度等の面で無理なのかどっちかなのでは、などと推測はできます。ここの対策としては、事前に切れそうなものを調べてセルの中身の大きさをいい感じに変えてくれるようなソフトはあるようなので（100%成功するとは限らないようですが）併用すると少し幸せになれるかもしれません。ちなみに、LibreOffice.orgのCalcも同じ問題を抱えてはいますが、例えばセルの文字数が多すぎて全部表示しきれない時には、デフォルトでは文の最後ではなく先頭が見かけ上切れて表示されたりするので、うっかりミスが発生しにくくなっていたりします。
章構造や参照の通番を完全に手管理しなければならない。インデントも同様。　→　文書を直して１章丸ごと消した時に通番が全部直るとか、章立てを変えた時に段落の深さを変えるとか、そういうことをしても、Wordなら機械的にやってくれる部分がありますが、Excelだと手作業が増えます。しかし、実際問題Wordの参照や連番の機能がいまいちなので、そういうのにこだわるならさっさとTeXでも使えって話もあって、どうせwordのそれを使いこなせないならExcelでもいいやって話は現実に起きているのかなぁなどと思ったりはします。
セルの結合でうまくコピペできない場合がある　→　これはこれで対応するアドオンとかVBAとかあるようですが…。表に限ればセル結合のコピペがWordなら楽かと言われるとまぁそうでもないですが、セル結合のExcelと表組みをしないでWordでやった場合とでは後者ではセル結合コピペ問題は発生しません。

まぁ、どっちにしろ、WordかExcelか決める前の時点で「WordもExcelも機能を使いこなしてない」のをよく見かけます。前に書いたことですが、本とか買って色々な機能を覚えたり、文書作成の観点で書かれた本も買って読んだり、どのみち使わされるなら便利化するための.exeも内部資料を各位に展開しましょう。

ちなみに、日本人の原稿用紙文化と親和性が高いと思われるExcel方眼紙、言い換えると欧文文化では和文文化ほどにはExcel方眼紙の親和性は高くないんじゃないかと思っています。 Excelを方眼紙代わりに使う日本人、クレイジーと米国人が驚愕 | スラッシュドット・ジャパンでは中国では欧文よりは親和性が高いのではないかという推測が成り立ったりします。ちなみに、ちゃんとは調べてませんが、文字サイズ文化が日本と近い韓国でもExcel方眼紙自体は存在するようです（程度や使用されるジャンル等は未調査です）。

「Excel方眼紙を撲滅したい」と思うなら、「なぜExcel方眼紙が好まれるか」は研究必須だと思います。もちろん、挙がった理由のすべてが本質的であるとか解消必須とかいうわけではありませんが。

余談）方眼紙と日本の電子文書について
方眼紙文化について、欧文でも等幅文字文化がまったくなかったわけでもなく、またコンピュータ初期では当然プロポーショナルフォントを扱うのが難しかったのでそこでも等幅は存在はしたのですが、「ワープロ専用機」や「パソコン用ワープロソフト」が日本で広まっていた頃、欧米ではプロポーショナル的なものが広まっていた中で日本の「ワープロのレイアウトが等幅文字、ページレイアウトは縦何文字掛ける横何文字、が主流だった頃がありました（1980年代から1990年代最初の頃？）。「全角文字」「半角文字」といった単語がが市民権を得たのはその頃の影響があったと思われます（市民権への影響であって発祥の話ではありません。ちなみに、ソフトやメーカー毎に名前に差はありましたが倍角文字、横倍角文字とか色々ありました）。
日本語ワープロで一太郎の天下からMS-Wordへのシェアの移り変わりが日本でのプロポーショナル普及へ影響が大きかったのかなと思ってます。その頃一太郎も「縦何文字掛ける横何文字」中心だったものからプロポーショナルなWord的なものに移り変わって行きました。
「縦何文字掛ける横何文字」から抜けられない人はその後も「全角空白文字レイアウト」を好んだ傾向があったのではと思っていますが、ちゃんとした論証があるかは知りません。この辺を研究して文章にしたらそれはそれで面白い話になりそうです。既にあったらすいません。

Check

2012.04.04 Wednesday

Making Software エビデンスが変えるソフトウェア開発

『Making Software ―エビデンスが変えるソフトウェア開発』Andy Oram, Greg Wilson, 久野禎子, 久野靖いい本なのでまぁお勧めですが、FLOSSやFirefox関係者にも面白そうなネタもあったりしたので、そこを敢えてご紹介。

本書自体良書で、ソフトウェアの生産性や品質等に関して業界なり世間では色々な手法が言われ良いの悪いのと言われるわけですが、その議論らしきものの少なくないものが経験則だけで語られていたり、データを持ち出していても、母数が少ない、条件が均一でない等分析として不十分だったりするわけで、本書は第１章で測定と分析全般に関わる話をし、第２章で個別のテーマでできるだけ分析らしい分析を試みた論を集めるという形を取っている。業界人なら全員読んでおけぐらいの気分ですが。

O'Reilly Japan - Making Softwareに目次がありますが、その中で、

第Ⅱ部ソフトウェア工学における個別の話題

11章コンウェイの法則の系（クリスチャン・バード）
の中に、
・マイクロソフト内部の組織上の複雑さ
・オープンソースソフトウェアのバザールにおけるチャペル
と、マイクロソフトの事例とFLOSS界隈の事例を引き合いに出してます（どっちがよいのかとかそういう話ではありません）。

15章品質戦争：オープンソース対有償ソフト（ディオミディス・スピネリス）
もろにFLOSSネタです。OSのコードの話が中心です。

21章モジュール化はどれくらい効果的か？（ニール・トーマス、ゲイル・マーフィー）
ここの分析にFirefox等のプロダクトを分析してます。

24章バグレポート収集の技芸（ラーフル・プリムラージ、トーマス・ジマーマン）
バグレポートのあり方についてFirefox等のプロダクト開発者にアンケートを取った結果などを分析してます。

辺りがまぁFLOSSをもろに取り上げています。FLOSSの質を見るのにもいい論ではないでしょうかという感じで、是非読まれてほしいものだと思います。

Check

| 言語 | 01:45 | comments(0) | trackbacks(0) |

2012.03.23 Friday

読みやすいソースコード？

読みやすいソースコードとはって一部にやたら好きな人がいて、まぁでも宗教論争にもなり得て、色々あれですね。

個人的には「ロジックと書式において書き方の思想が一貫しているコード」が汎用的に読みやすいのルールになりますね。
プログラミング言語によっても読みやすさは変わってくるとか色々条件がありますが、ある一連のコードの中で前述のが一貫しているコードは慣れないスタイルは最初とまどっても慣れれば読めるようになったりします（まぁ例外はありますが細かいことをいうときりがない…）。

CとかJavaとかの例で以下ずっと話をしますが、書式の一貫性って、まぁわかりやすいところで言えば

if ( )
{

と

if ( ) {

が何の法則もなく無秩序に混じっていると読みにくいですよねって話です。インデントしかり。１行何文字を超えたら改行するのかetc。
※それはもちろん、例えば、１行の文字数の最大を考えるのにはディスプレイサイズとか解像度とか、場合によっては印刷した時に１行に入る文字数を考慮するのはありだと思います。コードの上の方と下の方途で改行位置が無秩序に違うと読みにくいかと思います。

読む方がルールを読み取りやすければ読み取りやすい程、読み手にとって読みやすいです。ただ、これは読み手の力量や習熟度によっても違うことなのでどれが正解というのと一概に決めるのがいいとは言いませんが、でも例えば同じ関数の中でとかっていう一定の範囲においてその範囲の中の全体の中での一貫性を考えずに書いたコードよりは考えた方が読みやすさは上がるという一般的法則はあるとは言ってよいかと思います。それが「どの程度か」「考える時間を投じるだけ価値があるか」という話になるとケースバイケースで、まじめに測定しようと思うとそれこそ大がかりな実験が必要になって、まぁそういう実験はそれはそれで興味深いですが、（測定という意味における）素人目に勝手に断言しても何もおいしくないなぁと思ってます。

ロジックにおいて一貫している、の例
コード例 A-1

int calc(int input)
{
    if (input == 1) {
        return 253;
    }

    if (input == 2) {
        return 24;
    }

    if (input == 3) {
        return 783;
    }

}

と
コード例 A-2

int calc(int input)
{
    int returnValue;
    if (input == 1) {
        returnValue = 253;
    }

    if (input == 2) {
        returnValue = 24;
    }

    if (input == 3) {
        returnValue = 783;
    }
    
    return returnValue;
}

とではどっちが読みやすいでしょうか。switchにしろとかって話はもあるでしょうそもそもどっちも突っ込みどころがあるのですが、ここでは二択で考えてください。まぁ私はA-1が好みですが、この例ではぶっちゃげどっちでもいいです。ちなみに私がA-1が好みな理由は「(1)変数が少ない(2)全部を読めばわかるけれど上から読んでいて二つ目のif文に着た時にはまだ一つ目のif文の結果trueの場合もfalseの場合も覚えていなければいけないけど、returnしていればそれは忘れていい」みたいなものです。まぁ反論もあるかと思いますがそれは今回書こうとしている内容と関係がないからいいです。

問題は、
コード例 A-3

int calc(int input)
{
    int returnValue;
    if (input == 1) {
        return 253;
    }

    if (input == 2) {
        returnValue = 24;
    }

    if (input == 3) {
        returnValue = 783;
    }
    
    return returnValue;
}

こういうのです。私はこれはやめてほしい。A-1かA-2にしてほしい。私がいう「ロジックの一貫性」は例えばこういうのです。もちろん、こんな簡単なのはぶっちゃげどうにでもなって、もっと複雑な例になるとA-1かA-2かどっちかに簡単には寄せられない場合もあるので、仕方がない場合はあろうかと思いますが、A-3よりはA-1やA-2を選ぶ。これがロジックの一貫性の考え方です。もちろんこういう一貫性を考える条件は色々あるわけで、複数のifの中に共通ロジックがあったときの共通化とか考えると、結果的にA-1、A-2式に無理に倒すよりA-3式の方が読みやすいこともあるかもしれませんが、考えた結果であることが重要だと思ってます。もちろん、結果的に大差がないことはあります。大差がないことに考える時間を費やすことにたいした意味がないことももちろんあります。それでも、考えないよりは考えた方が保守性があがる、という一般則はあろうかと思っています。

各種コーディング規約や読みやすさに言及した書籍やブログとかの内容を色々読んで考える練習をするのは糧になるかもしれません。

Check

| 言語 | 20:03 | comments(0) | trackbacks(0) |

2012.03.15 Thursday

Firefoxという名前と略称ff/fx

ウェブブラウザのFirefoxの名前とff/fxといった略称について、なんか知られていないことが多そうなので、私のわかる範囲でちょっくら整理してみる。

ウェブブラウザFirefoxの名前は、2002年にPhoenixという名前でリリースされたブラウザが、Phoenix Technologies 社の商標権の問題で一度Firebirdに改名、それがOSSのRDBMSのFirebirdと名前がかぶると苦情があり（法的に問題があったわけではないが、OSSとしてそれを受け入れた結果）、2004年8月リリース版より取り入れた名前である。

Mozilla Firefox - ブランド名に関する良くある質問（Mozilla Firefox - Brand Name Frequently Asked Questions）、Firefox 1.5.0.12 リリースノート、Firefox 1.0 リリースノートにあるとおり（原文リンクしてないものもすべてMozillaの公式英語ドキュメントがかつてあったものの公式和訳です）、

引用１）

"Firefox" はレッサーパンダの別名です。

引用２）

Firefox? それとも Mozilla Firefox?

正式名称は Mozilla Firefox です。略して Firefox と呼ぶこともあります。

引用３）

Firefox のスペルは? 短縮形は?

Firefox のスペルは F-i-r-e-f-o-x です。最初の文字だけが大文字になります (例えば、FireFox や FireFOX、FIRE FOX など、多くの人がそうだと思い込んでいるものはすべて間違いです)。好ましい短縮形は「Fx」か「fx」です。

引用４）

Firefox のスペルは? 短縮形は?

Firefox のスペルは最初の F だけが大文字になります (FireFox は間違いです)。好ましい短縮形は「Fx」か「fx」です。

とアナウンスされました。ついでにいうと、レッサーパンダといいつつ、実際にはロゴは狐っぽいのがたくさん使われています。Firefoxという名前を決めるのに主導権を持ったであろうアメリカにおいてレッサーパンダがそもそもどれほど著名であったかはよくわかりませんが（これはまともに調べずに言っている感想です）。Firefoxはちなみに商標上当時何の懸念もなかったというわけでもなく、イギリスのある企業とは事前にやりとりがあったと聞いています（やり取りがあったというのが即ちやりとりしなければ違法だったとは限りません）。では、それぞれこれについてちょっと一つずつみていきましょう。引用１について。Firefoxはレッサーパンダの意味であると。しかし、これについてRed panda - Wikipedia, the free encyclopediaをみると

The English name firefox is often claimed by English sources to be a literal translation of the Chinese name for the red panda.[75][76][77][78][79] But the Chinese word 火狐 huǒhú refers to the Firefox web browser.[80][81][82]

となって複数の出典が挙げられています（同記事には引用部以外にもまだ関連言及ありますのでご覧ください）。「ブラウザ以前にそんな用法があったのか疑わしいのだ」と。これがどれほど正しいのか調査は私の手に負えないのですが、出典を見るに少なくともレッサーパンダの別名としてのFirefoxという名前が、ブラウザ以前から著名であったと考えるのは難しいと思われます（私の持ってるいくつかの辞書にはないです。もっと由緒あるすごい辞書を調べていただける方がいらしたら是非どうぞ）。ちなみに、ブラウザ以前に英語圏でfirefoxと言えば、第一義にはクレイグ・トーマスの小説（最初は1978年）のシリーズとその映画化といってほぼ間違いないです。じゃあ、それ以前がどうなんだと言いだすと、Googleブックサーチで1977/12/31以前という条件で「Firefox」でひっかけてみましたが、多少はあったようです（決して多くはありません）。ただ、それぞれがどういう意味で使われてるかまでは私はチェックしてないのでご興味のある方どうぞ。引用２は特に調べてどうのっていうわけでもないのですが（イギリスとの商標の問題でそういう正式名称としたとかいう話があったような気がするのと（記憶いい加減）、Firebirdという名前を一時は「Mozilla Firebird」にして切り抜けようとしたという話の名残もあるかな（この辺も記憶いい加減。調べて追記は気が向いたらするかも）、などと。

引用３と引用４に入ります。Firefoxは「一単語」であり、（少なくとも建前上は）ブラウザが採用する前からあった名前ですから、foxの部分を切り離したり、Foxと書いたりするのが間違いだというのは割と明確だと思います（間違いだからといって他人にしつこく言うことがいいのかは脇に置いておきます）。また、商標でもあるので、それはFirefoxと書くのが正確に決まっています。しかし、商標を盾にするならUnixは商標はUNIXでしょとかいう話も関係したりするわけで（Unixの場合に同一視できない事情があるという考え方もあると思うのですがそこまでは深入りしません）。商標であることを盾にするだけではなく本来1単語であるということのも持ち出す方が不当表記を批判する説得力があると思います。まぁ後者だけでいうなら、firefoxとかFIREFOXは間違いとは言いづらいとは思いますが。

そして、略称の話に入ると、これがやっかいです。まず、この略称の推奨文言は、Firefox1.5とかいう古いリリースノート関連には載ってますが、その後新しいバージョンのリリースノートに乗らなくなってから何年も経っているばかりか、Mozilla関係者の資料にすらffっていう単語が少なからず見受けられます。もはやこれを「Mozillaがそう望んでいる」と主張するのは説得力に欠けていると思われます（fxを好むのを否定する理由ではありませんが）。まぁ、基本的にこれは一単語であって、fxどころかffも頭字語ですらない。そもそも2文字に略す必然性もないです。実用的に2文字ぐらいが都合がいいという話はあるでしょうが、どっから取るかはある意味任意です。それでも、語源的な意味でfireとfoxに切れるよねって考えてffって略する人がいるのはよく理解できるし、間違いだという理由も、公式がfxの積極的推奨を取り下げた今となってはないと言っていいんでないでしょうか。といっても「これは1単語だから」論は、「もともとFirefoxなんて単語はほとんどなかったわけだしほとんど新しい造語だろ」って言われると1語論を強気でいうのはちょっと弱気になりがちだったりします。それを言い出して語結合 - Wikipedia 結合辞 - Wikipedia 複合語 - Wikipediaみたいな考えを持ち出すともう私は手に負えるので逃げるしかありませぬ。ちなみに、当初ffではなくfxが公式に推奨された理由は知りません。素人考えて思いつくのはFireFoxと勘違いしてほしくなかったのではって感じです。あとは、たぶん関係ないですけど、英語圏においてもfxよりはffの方が別の意味の言葉が多いように見受けられることぐらいでしょうか（英辞朗とen.wikipedia調べ…って信憑性の薄い簡易的調査にすぎませんが…）

というわけで、上記の一部は以前書いたといっても以前に書いたほのうのきつね | kozawa のたまに気になることとかなりかぶってますけど、こちらにはまた違うネタも入ってます。

Check

2012.02.22 Wednesday

年末年始連載された@ITの瀧田さん特集

Mozilla Japan代表理事の瀧田佐登子氏の半生がスゲー面白い - YAMDAS現更新履歴ここでも絶賛されているけど、確かに色々面白い。@ITの「連載：挑戦者たちの履歴書　挑戦者やリーダーたちはどのような人生を送ってきたのか」。2011/11/7から2012/1/25までの24回連載でした。まぁここを読みに来るような方なら大概読んでますよね？まだだった是非どうぞ。

瀧田さんには色々お世話になってきました。応援してます。過去に瀧田さんの過去の活動をさらしてみる | kozawa のたまに気になることとか瀧田さん略歴 | kozawa のたまに気になることとか書いてしまっている私です。はいすいません。第122回に出てくる鳥取赤十字病院。地元の大病院ですね。（現在は平成の大合併でエリアが広がっていますが）当時の鳥取市の、また鳥取県東部の中核医療施設４つの一つで、ベッド数ではその中で最大ですね。県東部っていうくくりは、JRも未電化区間の多い（県庁所在地に走っているのは電車ではなく機関車付きの「汽車」です）鳥取県では県内の移動も時間がかかるのでそんなもので…。第123回の話題。スキーと言えば、一番近くはあそこからだと多分氷ノ山（ひょうのせん）、県内にはもっと大きい大山（だいせん）もありますが、鳥取砂丘と言えば、雪がなくても砂で滑れるような所なのでまぁ遊べますよね。第124回の鳥取西高校のとても古い校舎の話は、今では現物は見られないと思うので図書館かどっかで写真資料をあさってくるしかないと思いますが、今でもそれなりに古い校舎(1963年頃のもの)で困ってるようですね参考：教育カウンセラーの独り言: 鳥取西高は城跡から移転を…文化庁が見解鳥取城跡も手軽な山登りすぽっと…。第125回の「さあ、“宇宙科学”を勉強するぞ！」と思ったところ、何とそんな学科は存在しなかった！実際にあったのは宇宙科学どころか、同じ“カガク”でも“化学”の方だったのである。」って所だけはどうもよくわからなくて、まぁ目的の研究をやってなかったから別のところにするのは普通のことだからなにもおかしくないんですけど、明星大学理工学部には当時今でいう物理学系（理学部寄りでは宇宙に近いところは物理系とかにあることはよくあります、今の明星大学でもあることはあるようです）や機械工学系（工学部寄りでは航空とか宇宙に近いのはこの辺に分類されたりすることも。明星大学のこの機械工学系に現在宇宙に関する研究が今あるかはわかりません）はなかったんでしょうか。多少近いのがあったとしても自分の目指してたのと違えば選ばないとか普通ですけど、「あったのは化学」って文章だとあれ？っと。

とかいうペースでやってるとほとんどストーカーなので、この辺にしましょう。第132回のSE時代からネスケ初期の当たりJavaは、前述の瀧田さん名義本とかにその空気は残っているかもしれませんね。で、さっさとブラウザ時代に話を持っていきましょう。時代がシンクロするなー。というわけで、ブラウザ黎明期からブラウザ戦争までについてはO'Reilly Japan - ブラウザ選択の時代を読み解くを買って読んでください…と言いたいところですが既に絶版です。流通でも注文ストップなところが増えてきました。ウェブ通販系で買えるところがどこかしら残っている可能性は否定できないのでご興味あれば是非。「ブラウザ選択の時代を読み解く」の第1章を読み解くのによい10冊程度 | kozawa のたまに気になることなどもどうぞ。といってもワールドワイドな話だと日本の話があんま出てこないんですけどね…。

第135回のMOJIBAKEの件、今ではMojibake - Wikipedia, the free encyclopediaという具合に英語版ウィキペディアに記事が立派にあります。瀧田さんがネットスケープ社内に広めようとした1996年。文字化け - Wikipedia日本語版ウィキペディアの「Mojibake」節を見ると、久保芳之さんが広めたとなっていて、どうもリンク先とか見る限り1996年に瀧田さんが頑張ったより数年前のようだ。といっても現在の広まりとそれぞれの頑張りがどのようにつながってたかは私にはわかりかねるが、久保芳之さんが頑張ったにも関わらず、ネットスケープメンバーは1996年時点で概念もわからなかったということ。現在でも英語圏でわかる人がどれだけいるかは怪しいが、今なら英語資料で「これを読んでおいて」って言っておけばなんとかならないでもない。

第140回あたり、コミュニティメンバーからMozilla Japanとのかかわり。まぁ今となってはだいぶ離れてしまった私があんまりどうこう言うのも老害状態でよくないんですが、まぁ許される範囲だろうと思って回顧すると、色々私自身も当時悩んで、その時に決断に後悔してることも多いけど、今のように、一つの時代を作れたプロジェクトのある一時期に立ち会えたことは今でも喜びです。

瀧田さんの言葉

「学生でいられる内に、オープンソースの世界を踏み台にしろ！」

いいですねー。

ご参考

Check

2011.12.15 Thursday

エスカレータ立ち止まるのは右か左か問題

大阪では右に歩かない人が乗って、左は「歩いて先に行く人」用に、東京は左が立って、右がショートカット。
ある程度の規模の都市では今ではだいたいどちらかによる暗黙のルールがあるようです。ただ、日本では大阪とその近郊以外は左立ちが多いのですね（神戸は左立ちっぽい、京都はネットで見ると両方みかけますが…）。
海外でも調べると国と土地によって違うのですが、若干大阪ルールの方が多いように見えます（印象）

で、なんでそんな差が出来たのかについては諸説あって、「議論の余地のない決定打」ってないようです。
まぁ私は「そんなにはっきりした理由はない」っていう印象を持っています。
いくつかある説には
「大阪では　１９７０年に開催された万博のときに欧米にならって　右に立つことが定着したといわれています。」
（エスカレータ・右左どちらに立つ！？ - Yahoo!知恵袋)、刀を持つ側との関連を指摘する意見右を歩くか左を歩くか　エスカレーターの文化紛争 - 飛耳長目国際紛争の心理 - Yahoo!ブログ、私が一番信用している説は、ネットではあまりみかけませんけど、「駅の作りなどの偶然が生んだ差が広まった」というもの。
この説は何を言っているかと言うと、簡略化すると、「エレベータを降りた後、例えば行き先の改札が左側だったとすると初めから左側に乗る人が多くなるとは考えられませんか？」ということです。この説明ではその左に乗る人が「立つ」なのか「歩く」なのかわからないのですが、一端「乗る前や降りた後にどちら側へ行くかが寄る方向に影響して、それは駅によって違うはずだけど、大げさにいえばバタフライ理論的に広まった」的に説明します。まぁもしかすると、駅の構造や人の流動（駅から出る時に人が進む向き）を調べると大阪に何らかの特徴が発見されるかもしれないなぁとは思っています。

しかしでも、どうやってそれを論証出来るでしょうか。「実態」調査という意味ではどの時期にどの駅ではどうだったかの情報を蓄積すればいいんですけど、まぁ誰もいつ頃からどの駅でどっちに寄ってたかとかろくに覚えてないですので、聞き取り調査は、多少の参考にはなってもそれ以上の信ぴょう性がない…。その点は、まだ、「当時の記録」の文献や写真といったものの方が信頼性は高いけど、集めるのが難しい上に、「断片」を集めてもなかなか過去情報を再現するのは難しそうです。けど、そういう研究誰かやらないかなぁというばかばかしい妄想はしています。

「ある都市では右/左に寄る」というルールはどのように発生しうるのか。「歩く人と立ち止まる人のどちらも一定割合を超えていてどちらかに寄らないと効率が悪くなる」というのが一つの条件であろうことはおおむね類推できます。「同じ人が何度も利用する駅でそれが発生する」これも一つの条件と推測出来て、ルールが空港などでは比較的出来にくいらしいことなどからみても、言えそうです。少なくとも初期に現象が発生した駅は「同じ人が何度も利用する」場所であった可能性は高いのではと推測しています。でないと今日と明日で同じ方向に人が寄るとは限らないと言えそうだからです。あとは「特に幅が二人分のエスカレータで発生しやすい」と想定されます。一人乗りでは寄れないし、横幅が広いエスカレータでは寄る必然性が少ないので。
初期状態（？）では、左に立つ人も右に立つ人も一定割合要るはずです（偏りは考えられますので、割合が50:50というわけではありませんが1:99とかってことはないと思うのです）。それが、何かしらの理由で「自分の自然な方」ではない方に「ルールだから合わせる」ようになる。途中段階として「みんながそっちに寄ってるからそっちに寄る」とかあると思いますが。

ある程度確率的動きがそこにあったと思われるので、モデリングしてシミュレーションすること自体は可能なのではないかと思います。ただ、何をパラメータにしてその値をどこに置くかはかなり難しそうです。でも、「一部のパラメータをちょっと変えるだけで結果が不安定」みたいな現象が観測できるかもしれません。
初期状態に関するパラメータと値、色々考えられます。まずは「自然状態で左に乗る人と右に乗る人のどちらが多いのか？」について。
「（前述の）構内構造によるバイアス」「歩行者右側通行等のくせによる偏り（この値はあまり地域差は大きくないと思いますが、もしかすると日本の通行ルールを守る傾向の強い人と弱い人の割合には案外と偏りはあるかもしれません）」「歩行者を追い越す時に右を抜けるか左を抜けるか（これも地域差小を想定）」「荷物の有無でどちらの手すりによるかの違い（これもそれほどの地域差はないような気がしますが、真中に立ったりしないとか、手すりを理由に積極的に一方に寄りたがるかどうかは年齢別利用者割合比率の地域ごとの差などと相関があるかもしれません）、これには利き手の偏りといったものとの相関もあるかもしれません」。これらの初期値を正確に求めることは難しいですが、人を集めて誰も乗ってないエスカレータに乗せるなどして初期値のための参考値を収集すること自体はまったく不可能ではないと思われます。
どれだけの駅なりエスカレータなりがあり、その利用者がどれくらいいて、どれくらいがリピータであるか、そして「立つ際に周囲が一方に寄ったからとそれに従いやすい人がどれくらいいるのか、とか、どれくらいみんなが寄っていると従うのか」あたりをうまいことモデル化してシミュレーションを流すと、何か面白い実験が出来るかもしれないなぁなどと思ったり思わなかったり。
まぁこの辺のパラメータ想定の情報収集の一環としては、「過去が実際どうだったか」という前述の「過去実態調査」も一つの重要な情報になりえるのですけどなんかやっぱり難しそうです。
地域単位で統一されるまでに、同じ地域でも「個別のエレベータでルールが出来て、近い地域でもばらばら」という状態もあったかもしれない、そういう場合にどういう条件で統一されていくのか（より利用者の多いエレベータのルールが持ち込まれやすいとかあるかもしれません）…いやぁ、面白そうな研究だと思いますけどねぇ。これがわかっても商業的にすぐにつなげられそうな気はぜーんぜんしないんですけど。
ただ、まぁ強いて屁理屈をこねれば、建物と人の動線の設計をする上での何らかの法則やデータの一つにはなるかもしれませんね。人の行動の心理に関する研究の関連分野とも言えなくもない。

上述の私が一人で妄想したものだけでは色々突っ込み所があるはずなので、煮るなり焼くなりして研究につながるような「研究テーマが決まってなくて困っている」ような人がいたら…うれしいけど、たぶんいないよね:P

ちなみに、別の問題として「エレベータは歩くことを考えて設計してないので歩いてほしくない」「設計を考えるとエレベータは左右に寄らずなるべく真中に乗ってほしい」「狭い中で歩く人がいると止まっている人があぶない」等の問題もでてますし、とはいっても設計起因の指摘はメーカーにもよるので「別に歩いても構造上大丈夫」という意見も見たことがないでもないのと、「止まると邪魔って声の方が大きいのであるいてください」ってアナウンスしてるところもないこともなかったり、話は簡単じゃないようです。

2011/12/26追記）この問題に関連があるかもしれない「別の場所のエスカレータ」というのもちょっと頭をよぎった。他の人どおりの多いところのエスカレータも影響したかもしれないな、と。シミュレートなり調査にはそういったものも入れた方がよいかも、と。特にデパートとかのエスカレータは、螺旋状に設置してある所が多いと思われ、その回転の向きは上述の議論に大いにかかわるのではないか、などと。

Check

| - | 19:07 | comments(0) | trackbacks(0) |

レビュープラス

+ NEW ENTRIES

+ CATEGORIES

Mozilla (278)
pc/net (251)
言語 (11)

+ ARCHIVES

+ LINKS

+ PROFILE

kozawa