有限会社　高梨IT製作所

たかだか地方のFラン大学を、しかも卒業滑って1年余計に通うことになった低学歴者の私が、自分のことを棚に上げて上から目線で語ってみます。ので、いつものですます調ではなく、口語体で書いてみます。想定読者は、中学・高校生。

まず、タイトルに挙げた「勉強って何の役に立つの？」という問いかけについて。正直なところ、俺はそういう疑問を持ったことがない。「ああ、学校の勉強が完璧にできれば、ものすごく役に立つだろうなぁ。なんで俺そうできないんだろ」とは思ったけど。「役に立つ」というのは、学歴があるからいい仕事につけるとか、成績がいいから自慢できるとかじゃなくて、英語ができたら(ほぼ)世界中の人と話ができるだろうし、理科なんかは宇宙がどういう仕組みで動いているのかを教えてくれるし、文章を読めてうまく書くことができたら、ペン一本で食っていけるだろうし、日本や世界がどうやって成り立っていて、これからどうなるかを予測できれば大金持ちになれるだろうし、数学なんてこれ以上エレガントなパズルはないよね。

もちろん、学校の授業で教わることだけが全てじゃない。人間はどうしたって人と関わらなきゃ生きていけないから、友達と遊んだり、恋人を作るのだって大事。何の仕事でも体が資本だから、部活で運動して体を作っておくのも、俺は最近になって身に染みたけど、これも超大事。

あなたたちがかわいそうだなぁ、と思うのは、受験やらテストやらに「追われながら」勉強しないといけないってことです。あと何年後かには高校受験・大学受験が迫っているし、その前にもテストやら試験が沢山ある。それはすごく苦しいよね。俺だって試験前に一夜漬けやって、その後電車で寝過ごしたこと何回もあるし、受験勉強だって夜中に眠りそうになりながらやって、ノートが意味不明の文字で埋められたことがありましたよ。まあ普段から少しずつやっときゃいいんだろうけど、そういう計画性はまるで無かった。ｗ

本題に戻るけど、じゃあそうやって勉強したことが現実に役に立つのか？ とてもいい疑問だと思う。即答すると、「これ以上役に立つことはない」だね。

「えー、じゃあ毎日連立方程式解いてるんですかー？」とか「世界史の年号どれだけ覚えてるんですかー？」とかいう声が聞こえてきそうだけど、ここで言いたいのはそういうことじゃないんだな。

要するに、何でもいいけど、「何かを理解する力」ってのは、こりゃもう世の中に出てから超絶役に立つんですよ。

例えば、今深刻な問題になっている原発事故。あれを怖い怖いという人は多いけど、俺なんかは、じゃあなんで怖いんだ？と思うんだよね。もちろん、福島の現場に行って、「マイクロ」や「ミリ」がつかない「シーベルト」がダダ漏れしてるところで作業して来いと言われたら、そりゃ考える。だいたい労働環境もよくなさそうだし。

ただ、東北産の牛肉や三陸沖の魚を食べたりとか、関東で普通に出歩くとかは、ほとんど心配してない。なぜならセシウムが体に取り込まれることがないのを「知って」いるし、ヨウ素は普段から十分取っているし、外を出歩いて浴びるかもしれない放射線の量なんてお話にならない程度であることが「わかって」いるから。それで心配なら太陽風を避けることだって考えなきゃいけない。

少量だって良くないものは良くないだろう、と思ったら、醤油をビンで一気飲みしたり岩塩を丸かじりしたらきっと内臓おかしくなるだろうけど、でも塩分は体に「必須」であることを思い出して欲しい。食塩(塩化ナトリウム)を全く取らなかったら人は死ぬ。

原発があろうがなかろうが、原発の近くに住んでいようが山奥に住んでいようが、放射線は地球のどこにいても毎日浴びるもんなんです。関東圏内は普段よりちょっと高めのところもあるみたいだけど、まあ問題ない範囲。

正直なところ、俺も「シーベルト」っていう単位はこの原発事故で初めて知ったんだけど、「ミリ」が1000分の1、「マイクロ」がそのまた1000分の1を表すことは知っていたし、原子が崩壊するとα・β・Γ線が出て、それぞれの正体がヘリウムの核子、電子、超短波長の電磁波、であることも高校の物理で習って知っていた。

「勉強しても話せるようにならない」とさんざんけなされていることの多い読解中心の英語教育だって捨てたもんじゃないよ。俺の仕事は英語読めなきゃやっていけないし、むしろ英語が読めるだけで70%くらいの問題は解決できる、と思う。だいたい、中学で3年、高校で3年、人によっては大学でさらに4年と、6〜10年、第一外国語として英語を勉強してて、なんでみんな喋れるようにならないのかが不思議だね。俺だって条件は同じだった。多少は自習したし、喋れるようになりたいと熱烈に思ってはいたけど。

かくエラそうに語ってるけど、実は高校以来数学が苦手でね。やっとこさ簡単な微分積分ができるくらいで、虚数なんて心の底ではまだ存在を信じきれてない。ただ、最近その苦手意識を克服すべく、この世で一番美しい数式といわれているオイラーの等式

e^iπ = -1

の証明を勉強し始めた。きっと何の役にも立たないだろうけど、まあ自己満足のために。ｗ

だいぶ脇道にそれたけれども、要するに、若い時に勉強しとくと、大人になったとき、たとえそれが初めて見聞きすることであってもパッと理解できる助けになります。「ああこれはこういうことだな」ってのが心に閃く。その感覚を磨くために、もしかしたらその知識自体は役に立たないかもしれないけれども、運動で基礎体力をつけておくのと同じくらい勉強って大事なんだよ、ってことを言いたくてこんなエントリを書いてみました。35のオッサンはお化けと同じで試験なんかないから、あなたたちと同じように苦しむことはできないけど、それでもまだ知識欲とか学習欲はバリバリあります。一緒にがんばりましょう!

ほんとにひさびさの更新になってしまいました。

タイトルの数式、もちろん数学的には間違っています。では何がいいたいか、というと・・・

弊社もついに、「人」を雇うようになりました！＼(^o^)／

一人社長として呻吟しながら、あるいは連絡さえ取れなくなりお客様にご迷惑をおかけしながら、なんとか5年あきらめず頑張ってきましたが、これで弊社の抱える問題の一つが解消されました！今、本当に気が軽いです。

いずれ、このブログにもその方に投稿していただくようになるかもしれませんので、お読みの皆様におかれてはよろしくお付き合いのほどお願い致します。m(__)m

いつだったか「弊社ホームページを見て仕事依頼は、今のところない」ようなことを書きましたが、その方は、なんと「弊社ホームページを見て」エントリーメールを送ってきました。すでに何件かお仕事を依頼し、働いていただいております。

正直な話、仕事の依頼などより、優れた人材を呼び寄せられるほうがどのくらいありがたいかわかりません。特に、当市のような地域においては。

人柄・職歴については申し分なく、技術的にもちょうど私の詳しくないところをよくご存じなので、まさに願ったりかなったりです。

ちょっとこのところすでに請け負っていた仕事でバタバタしていたので、体制は整備中なのですが、まあ少なくとも「一人社長」と卑下しなくてよくなったのかな、と思っています。ｗ

あとは、ちゃんと給料を支払えるよう定常的に仕事を獲得できるか、が問題ですね。今までなら私がガマンすればよかったのですが、これからはそうもいかなくなります。ただ、この点については、最近私自身が多忙だったこともあり、その繋がりはもちろん維持しているので、あまり心配していません。むしろ、「スタッフが増えました」と言えば、より安心しておつきあいいただけるのではないかと思っています。

１人を雇う体制を整えれば、２人、３人と増やしていくのは、たぶん最初のときよりも苦労はないはずで、その準備に取り組んでいます。

世の中は、3.11震災の影響で風評被害やら倒産やらと不景気な話ばかりで、もしかしたらこんな話は不謹慎なのかもしれませんが、弊社としてぜひアナウンスしておきたく、今回の記事を書かせていただきました。

今までは、機械を動かすことを考えていればよかったですが、これからは人を動かすことも勉強もしなければなりませんね。なんて、生意気なことを言っていますが、皆様からのご指導・ご鞭撻をよろしくお願い致します。m(__)m

[2011年4月12日 09:55 追記] リトル・チャロ2にも対応した Ver.0.13 を公開しました。

コメント・メールなどで不具合をお知らせいただきました皆様、また、対応方法をコメントにお寄せいただいた皆様に感謝申し上げます。

キャプチャツール Ver 0.12 Ver 0.13(2011年度&リトル・チャロ2対応バージョン)を下記のリンクよりリリースさせていただきます。

nhk-rtmp-capture-ver0.13

使い方は今までと変わりありません。リトル・チャロ２にも対応しようと思いましたが、今のところ対応できていません。ご了承ください。 リトル・チャロ2のストリーミングダウンロードにも対応しました。また、ダウンロード中にウィンドウを操作しても表示が固まらなくなりました。

2011年度からはFlashの再生プログラム(streaming.swf)に変更が加えられ、毎週、14桁のマジックワード(0077PTLP2BX71C, 0109BSNQVLFRF1など)が埋め込まれるようになり、これを抽出しないとダウンロードできない状態になっておりました。これを解析する方法を探っていたのと、弊社業務、また私自身の体調不良などが重なってしまい、リリースが遅くなりました。申し訳ございません。

このマジックワードの解析方法は人の手を介さず、自動的に解析できる方法を確立ずみです。毎週月曜日に最新のものに更新し、それを本ツールで読みに行く形を取っています。

また、今回は公開方針・および寄付のあり方について、ご指摘をいただきました。

公開方針について

このプログラムは多くのオープンソースソフトウェアを使って構成されています。そのプログラムをクローズド・ソースにして公開しておりましたのは、改変が加えられた場合、私が責任をもてなくなってしまうことを危惧したためです。しかしながら、今回、対応方法など、ユーザー様から多くのご協力をいただきました。この状況を鑑み、Google Project Hosting に全コードと使用バイナリを公開することに致しました。

寄付について

当初、自宅サーバで公開していましたところ、予想を大幅に超えるアクセス数をいただき、とても自前サーバでは対応しきれず、やむなく外部ホスティングサービス(さくらインターネット)を利用することになりました。サーバ代自体は月数百円程度ですので、自前でお支払いしてもよかったのですが、「もしかしたら月1回くらいは寄付があるかもしれない」という予想のもと、任意の寄付をお願いしておりました。が、こちらも予想を大幅に超える善意の寄付をいただくことになりました。

おかげさまで寄付ベースのビジネス(?)に関して充分な経験を積むことができました。コメントなどでご意見もいただいているところですし、これを機に弊社あての寄付は受付を終了とさせていただきたいと存じます。今までご寄付いただきました皆様、誠にありがとうございました。

ただし、皆様ご存じの通り、3月11日に発した東日本大震災には今後も多額の援助が必要となりそうです。日本赤十字社のサイトからは銀行振込・クレジットカード・コンビニ決済など多様な義援金の受付を行っています。

もし、本ソフトが皆様のお役に立ち、その謝意を示すことをご希望される方は、上記リンクより、任意の額の義援金をお申し出いただければと存じます。

今後のTODOなど

先にも書きましたとおり、リトル・チャロ２への対応ができておりません。また、Windowsでの利用を前提としており、Mac対応のリクエストもいただいております。ですので、

• リトル・チャロ対応
• Adobe Airアプリとして作り直し、Mac&Win両方で動作するものにする

を今後の課題とさせていただければと存じます。

今後とも、本ツールへのご理解・ご協力をよろしくお願い申し上げます。

facebookのウォールやTwitterのタイムラインが気になってしかたがないソーシャルモンキーの皆さまこんばんは。無料で使えるAPIやPaaSを日々探索中の高梨です。

さて、私事ですが、以前からこういうのできたらいいなーと思っていたことのひとつに「SNSを通じて知り合った人と本やCD, DVDを貸合えたら」ってのがありました。さすがにP2Pでデータをやりとりとなると著作権法的にアレでしょうけど、現物を貸し借りする分には問題ない、はず。一言で言えば「P2P図書館」です。ちょっと前までは日本でSNSといえばmixiでしたが、ガラケーアプリ開発が必須だったり、時代の流れ的にfacebookかな、と。何より商用利用も可ってのがいいですよね。

まあ実際に貸し借りをしなくても、個人の蔵書データベースをネット上に持てるだけでも、ちょっとステキです。「へー、この人の読んだこの本、面白そう」とかね。中には持ってることを公開したくない物もあるでしょうけど、それは非公開にするか、そもそも登録しなければいいわけで。

実際すでに、似たようなサービスはいくつかありますが、私がやりたかったのは

1. USBカメラに書籍のISBNバーコードを見せて登録 (いちいち検索&登録という2段階の作業をしない)。
2. バルク登録(ISBN一覧データで)も可能。
3. 本を登録したりコメント書くと同時にウォールに書き込まれる。
4. データはいつでもエクスポート可能。
5. 「借りたい」申請が「いいね!」くらい簡単にできる。
6. 本棚でカテゴリ分けできて、RSSで取得できる。

といったものです。ブクログさんなんかはかなり上に近いです。特に、4.の機能は地味だけど大切で、いくら提供側が「クラウドだから大丈夫」といってもユーザさんの安心度が違ってきます。実際、読書メーターさんの機能リクエストを見ても、データのインポート・エクスポートは需要が高いようです。APIを切りだして実装はユーザさんに任せるというのも手ですね。

で、いろいろ調査して以下のようなサービスを材料にすることにしました。

• Amazon Product Advertising API (書籍&商品データ取得。海外の商品も検索できるようにする)
• Google App Engine (Webインターフェース、ビジネスロジック。言語はPython)
• Amazon SimpleDB (いわゆるNoSQLだが、LIKE 検索も可能。GAEのDataStoreではそれができない)

また、使用するライブラリは以下。

• jQuery (AjaxおよびXMLパース)
• ZXing (Flashでバーコード読み取り)
• boto (AWSを使うためのPythonライブラリ)
• Kay (GAE専用？のフレームワーク)

ソースコードのレポジトリはSubversionホスティングをしてくれる unfuddle.com に置くことにしました。

というわけで、材料の調査はだいたい目処がつきました。後はこれを組み合わせてコーディングしていきます。

私はGoogleの回し者ではありませんが、ｗ 昨日のGmailサービス障害について、公式なアナウンスが出ていましたので、意訳してお知らせしたいと思います。

Gmail back soon for everyone (Gmailはもうすぐ全員分が復旧します)

Monday, February 28, 2011 | 6:30 PMPosted by Ben Treynor, VP Engineering and Site Reliability Czar (24×7)

Imagine the sinking feeling of logging in to your Gmail account and finding it empty. That’s what happened to 0.02% of Gmail users yesterday, and we’re very sorry. The good news is that email was never lost and we’ve restored access for many of those affected. Though it may take longer than we originally expected, we’re making good progress and things should be back to normal for everyone soon.

Gmailアカウントにログインしたら、空っぽだった、なんて、落胆させるような感じを想像してみてください。それが昨日0.02%のGmailユーザに起こったことです。大変申し訳ありません。不幸中の幸いとしては、メールは失われておらず、影響のあった多くの人たちにはアクセスを復旧できたことです。当初に予想していたよりも長くはなってしまいましたが、作業は順調に進んでおり、もうすぐ全ての人にとって通常通りになるでしょう。

I know what some of you are thinking: how could this happen if we have multiple copies of your data, in multiple data centers? Well, in some rare instances software bugs can affect several copies of the data. That’s what happened here. Some copies of mail were deleted, and we’ve been hard at work over the last 30 hours getting it back for the people affected by this issue.

こう考えている人もいるでしょう。「複数のデータセンターに複数のデータのコピーを取っているなら、なぜこんなことが起こりうるうんだ？」と。珍しいケースでは、ソフトウェアのバグがいくつかのコピーに影響することがあります。それがこの場合で起こったことです。メールデータのコピーのいくつかは削除されてしまい、我々はこの30時間に渡り、この問題で影響を受けた人々を元に戻すため、作業を懸命に続けています。

To protect your information from these unusual bugs, we also back it up to tape. Since the tapes are offline, they’re protected from such software bugs. But restoring data from them also takes longer than transferring your requests to another data center, which is why it’s taken us hours to get the email back instead of milliseconds.

これらの異常なバグからお客様の情報を保護するために、我々はテープにもバックアップを取っています。テープはオフラインであるため、そのようなソフトウェアのバグからは保護されます。ただ、それらからデータを復旧することは、リクエストを他のデータセンターに転送するよりも時間がかかります。それがメールを元にもどすのに、ミリセカンド以上の時間がかかっている理由なのです。

So what caused this problem? We released a storage software update that introduced the unexpected bug, which caused 0.02% of Gmail users to temporarily lose access to their email. When we discovered the problem, we immediately stopped the deployment of the new software and reverted to the old version.

それで、何がこの問題を引き起こしたのか？ 我々は、0.02%のGmailユーザに一時的なアクセス障害を引き起こすという予期しなかったバグを発現したストレージソフトウェアの更新をリリースしてしまいました。問題を発見した際には、新しいソフトウェアの適用を即時中止し、古いバージョンに変更します。(読み間違いにより、誤訳していたので修正。)問題を発見した際、我々は新しいソフトウェアの適用を即時中止し、古いバージョンに戻しました。

As always, we’ll post a detailed incident report outlining what happened to the Apps Status Dashboard, as well as the corrective actions we’re taking to help prevent it from occurring again. If you were affected by this issue, it’s important to note that email sent to you between 6:00 PM PST on February 27 and 2:00 PM PST on February 28 was likely not delivered to your mailbox, and the senders would have received a notification that their messages weren’t delivered.

いつものように、何が起こったか略説する詳細な障害報告とともに、再び発生することを防止するための修正事項を App Status Dashboad に投稿します。もしあなたがこの問題に影響を受けていたら、2月28日11:00(JST)から3月1日07:00(JST)までに送られたメールはあなたのメールボックスに届いていないことがあるかもしれないこと、そして、送り手は不達の通知を受け取っているかもしれないことを心に留めておくことは重要です。

Thanks for bearing with us as we fix this, and sorry again for the scare.

改善中の我々とともに、ご辛抱いただいていることに感謝申し上げます。そして、ご迷惑をおかけし、重ね重ね申し訳ありません。

順調に復旧が進められているようで何よりです。私自身、先日のエントリにも書いたようにメールデータはGoogleのクラウドに入れていますし、お客様にもお勧めしようかと思っていたところですから。幸い、私のアカウントは99.98%の内に入っていたようで(笑)これといった障害はないのですが、障害が起こった際に迅速かつ的確にこのような声明をアナウンスすることは、私自身の経験から言っても非常に重要なことです。そして、それを実行しているGoogleは素晴らしい。

和訳については、私が慣れていないため、読みにくい点もあるかもしれません。こなれた訳になっていない箇所も多々あります。が、緊急性が求められる内容のため、ざっと推敲して投稿しました。悪しからずご了承ください。

約２ヶ月ぶりの投稿になります。実は7月末の祭りのときに親とゴタゴタがあり、その後体調を崩したりなどちょっと大変な時期でした。幸い、差し迫った仕事はなかったのでよかったのですが。

とはいえ、ただゴロゴロしていたわけではなく、いろいろ仕事に関係する勉強をしておりました。おかげで技術的な面ではやっと世界の最新動向に追いつくことができた気がします。技術的な表現バリバリのエントリですが、ご勘弁を。

Google App Engine が使えるようになりました

Ruby信者としてはPythonなんていうイケてない言語に手を出したくはなかったのですが、GAEを使いたいがために手を染めてしまいました。これで Ruby, PHP, Perl, Python の4大LL全てを一応使えることになります。まあ LLなんて機能は大概似たようなものなので、あとは自分のしたいことをWebで調べながら覚えていけばいいと思ってます。

GAEで引っかかるのはロジックの書き方よりもむしろ、NoSQL的なデータの持ち方かなぁと思います。例えばこのAPIを作るのに、最初は郵便番号・都道府県・市区町村・町名…というように小さなカラムを沢山作ってデータをアップロードしたのですが、それだと非常に時間が取られ、かつCPUタイムのリミットもすぐ上限に達してしまいます。なので、検索したいカラム(ここでは7桁の郵便番号)をキー(重複可)に、出力するJSONテキストをまるごと一つのデータカラムとして持った方が、アップロードもすんなり通りますし、ストレージ全体の使用量も少なくすみます。小さなカラムを沢山作ると各々にインデックスが作られるので、データストア領域も結構消費してしまいます。あと用語として「エンティティ」が、RDBMSで言うところの「行(またはRow)」に相当するというのは面くらいました。

最近はJRubyによるRubyコード実行も手軽にできるようになったようです。

一度慣れてしまうと、今まで個人や中小規模の企業では実現不可能だったスケーラビリティの効く実行環境を無料で始めることができ、お金がかかるとしても消費したリソースの分だけ払えばいいので、いろいろ面白いことができそうです。

Rubinius いいじゃん

Scaffold に度肝を抜かれた猿プログラマたちが大量にRailsにハマっているようですが、Rubyはいまいち性能(=速度)の面で劣っているのが実状です。Ruby自体は速くなりつつあるんですが、それにしても一度ソーススクリプトをコンパイルして、VM(YARV)上で走らせてからの話です。PHPには APCという、割合イケてる実装があって、これはバイトコードを共有メモリ上にキャッシュし、次に実行するときにはソースを読み込むのではなく、直接メモリ上のバイトコードを実行します。

Rubyでこれに近いことできないかなぁ、と思っていたら Rubinius という LLVM 上で動くRuby VM実装を見つけました。これのいいのは、実行に至るまでの各段階(Rubyインタープリタに渡すもの、構文木(S式ライク)、LLVMコード、そしてなんとアセンブリコード!)の中間コードを取り出せることで、最後のアセンブラを、できればバイナリの形で共有メモリにキャッシュすれば、かなり性能が出せるようになるのではないかと思っています。

Apacheの mpm-worker で動かせればステキなんですが、Rubinius のスレッドはMRI1.8ベースのグリーンスレッドらしく、その辺相性どうなんだろ。mpm-preforkだと24MBもあるrubinius VMはちょっとなぁ、という感じです。

OpenSkypeR(仮称)

Skypeの出始めの頃は「頭いいなぁ、こいつら」と思っていました。ダークなイメージのつきまとうファイル共有ソフト開発で培った技術をインターネット電話というクリーンなビジネスに転用していますし、P2Pなので初期インフラ投資が要らない。私が知る限りではNATの壁も難なく越えています。

ただ、難があるとすれば仕様が比較的クローズドなこと。SILKコーデックは非商用用途に限り無料かつオープンソースになりましたが、肝心のSkypeネットワークに接続する部分が非公開なんですよね。fringはその辺ハックしたんでしょうが、訴訟沙汰になっているようです。

もっとも、Skypeが世に出た当時から時代は移り、上のGAEのようにスケーラブルなインフラが比較的容易に手に入るようになってきました。となると、仕様を難解にし、開発者の人的リソースを著しく消費する複雑極まりないP2P技術(UDP Hole Punching, 分散ハッシュ, etc…)は要らなくなってきます。ハードウェアの性能が幾何級数的に向上し、性能あたりのコストもどんどん下がりつつある昨今、最もコスト視しなければならないのはソフト開発者のリソース。なら単純でオープンな仕様の方がいいですよね。

GAEのスケーラビリティとSILKコーデックの音質を生かしたオープンな仕様のオルタナティブを作れたらいいよね、という妄想のお話でした。

バイナリ or マシン語ハック

最近、布団の上に寝転がると、のび太君顔負けの速さで眠りについてしまうのですが、枕元の積ん読に「はじめての486」があります。486と言ってももう知ってる人は少ないでしょうが、私が中学生くらいのときにIntelが出したCPUで、今時のPCに載ってるCPUの5～7世代くらい前のご先祖様です。PC-9801/MS-DOS全盛だった当時、このCPUが載って、かつ価格が安いPC-AT互換機(DOS/Vは出ていなかった)の仕様を雑誌で眺めては「いいなぁ、アメリカ人は…」と溜め息をついたものでした。

時代は変わって、NECでさえ何の臆面もなくDOS/Vマシン(って今言うのか?)を出すようになりましたが、処理速度は桁違いに向上し、いくつかの命令は追加されたものの、CPUの動かし方自体は実はあまり変わっていなかったりします。古い仕様を引きずっているのは、取りも直さずソフトウェアの過去互換性のためで、要は全く違ったものを作ってしまうと今までのソフトが動かなくなるから、です。

で、今問題だと私は思っているのは、いくつかの秀逸なソフトのソースコードが手に入らず、手を加えようにも非常に苦労する羽目になることです。まあ、そういうソフトのWebページの背景色は大抵黒いんですが(笑。

であればバイナリ読解しか道はありません。元々人間の作ったものですし、暗号化さえされていなければバイナリだって読めるはず！という信念に基づいて始めています。CPUの言葉を理解できるようになれば、人間が読める形にも直せるはず、なんです・・・が、まあご想像の通り、決して易しいことではありません。

私の知人に「Fortranコンパイラの吐いたバイナリを手直しして最適化してるんだ♪」とのたまう、極めつけのスゴ腕プログラマがいらっしゃるのですが、その方の足元にやっと手が届いた感じです。何事も道は長く深く続いているものです。orz

・・・というわけで、計算機の勉強をするならシリコンバレーにも秋葉原にもいる必要はないな、と感じつつある今日この頃です。MITやUCBなら行ってもいいけど、うまい魚は食えないだろうしなぁ。

こういう仕事をしているせいか、ほぼ断定的に「学校は理系だったんですよね」とよく言われます。とんでもない！私は高校のころ数学の素養に恵まれず、情報工学系の学部への進学を泣く泣くあきらめ、ガチ文系の外国語学部に進学したという過去を持っています。数学は私にとって片思いの恋人のようなものでした。いくら勉強しても成績が上がらなかったんですから。

でも、今、かえってそれでよかったのかもしれないと思うことがあります。

理系特に工学系学部出身の人たちを見ていて思うのは「図やグラフや表、写真で表せば相手に伝わる、あるいは文章よりも伝わりやすい」という大いに間違った観念を持っている、ということです。

確かに図や写真といった右脳型のデータは有用です。百聞は一見に如かず、という言葉もあります。

が、しかし。

彼らの「言葉足らず」には本当にいらいらさせられます。よしんば文章が書かれていても、よくて事実の羅列ばかりで、書いた本人の情とか人柄とか考えとかが浮かび上がって来ない。流麗なる美辞を弄する必要はありませんが、簡潔明瞭に自分の意図を表す努力が感じられないのです。

これはもちろん学生時代に書かせられる各種レポートの弊害だと思われます。そこでは客観的事実を述べ、そこから引き出される結論を淡々と記述する形の文章を強制されます。書き手の感情の入り込む余地は皆無という能面のようなレポートを書かされた結果がそれなのでしょう。

だけど、それだけじゃああんまりだ、と思うのです。読んでくれた人のことを思うならユーモアや洒落っ気のある、クスッと微苦笑を誘うような文を認められたい。特にブログや日記ではね。

ただ、中には「ほほぅ」と思わせられる文章を書く理系出身者もいて、失礼を承知で「あまり理系の方が書く文章には思えませんが」と尋ねると、たいてい趣味で本を読んでいらっしゃいます。やっぱり文章が上手くなるには下手な細工を弄するよりも、他人の書いたものを沢山読むしかないのかなぁ、と思ったりするのですがどうでしょうか。

私のブログを読んでくださっている方には申し訳ありませんが、私は自分でこの場を文章を書く、あるいは公にコメントする「練習の場」として考えています。30過ぎたいい大人が幼稚なことをやっていると思われる向きもあるかもしれませんが、そのつもりでおつきあいいただければと思います。

今日、所さんの笑ってこらえてという番組にMOS(Microsoft Office Specialist)の世界大会に出場した慶応法学部の女性が出場していました。MOSというのはマイクロソフト公認の、ワード・エクセル検定と考えていただければいいでしょう。それらのソフトをどれだけ使いこなせるかを図る試験です。

でね、前に何かの足しになるかと思って問題集を本屋で立ち読みしたことがあるんですが、あまりのレベルの低さに正直めまいがしましたよ。SEが「MOS持ってます」って胸張るのは恥だと思ったので受験しないことにしました。

最近はそんなことも少なくなりましたが、一昔前までブラインドタッチでキーボードを打っていると「すげー」って目線で見られたものです。エクセルでグラフなど作ろうものならネ申でしたね。

ただ、その頃から思ってるんですが、本当に大切なのはキーボードをいかに早く打てるか、とか、データをグラフにまとめるか、ではなく、いかに人をうならせる文章を書けるか、グラフなんかにしなくても勘でデータを読み取れるか、じゃないかなぁ、と。

ネットにある文章をコピペして資料にするなんてのは、人間として「私は思考することを止めます」と宣言しているようなもので、一種の知的自殺だと思うんです。そりゃ見栄えはいいかもしれません。自分には到底真似できないと思うからそうするのかもしれません。でも、そこに自分がいなければ、他の誰でもないあなたがいなければ、何の意味もない。

Wikipediaによると

著作権（ちょさくけん）とは、言語、音楽、絵画、建築、図形、映画、写真、コンピュータプログラムなどの表現形式によって自らの思想・感情を創作的に表現した者に認められる、それらの創作物の利用を支配することを目的とする権利をいう。

だそうです。「自らの思想・感情を創作的に表現した」という部分にお目を止められたい。

翻って言えば、

• 単なる事実の列挙
• 思想・感情を表現していても、創作的と認められない場合

には著作権は発生しない、とも読めます。実際、テレビで知ったことですが、料理のレシピに著作権はないんだそうです。あの有名一流シェフが１０年かかって考え出したレシピをパクって本にしても、お咎めなしってことです。

私が十年一日の如く青年の主張みたいなことを書いているのも一にかかって「どうせ書くなら著作権の発生するような文章を書きたい」と思うからです。毎回毎回これでもかってくらい「思想・感情」を表現していますし、まあそれが「創作的」かどうかは意見の分かれるところでしょうけれども、すくなくとも

今日◯◯に行った。△△に会った。一緒に飲んだ。気持ちよく酔った。明日からもがんばるぞ。

と、蓮舫議員にかかったらばっさり仕分けされそうなネット資源の無駄使いはしていないつもりです。

だいぶ脱線しちゃいましたが、要は、「文章は文字列の集合ではなく、ましてや情報という名の味も素っ気もない無味無臭のソフトウェアでもなく、書き手の魂が込められた、ある意味ではその人自身の分身のような存在」なのだということを申し上げたい。

それだけの覚悟をした上で、皆さんブログを書いていますか？メールを書いていますか？恋するあの子にラブレターを書いていますか？

話を聞かない男、地図が読めない女

以前のエントリでも取り上げた本です。市の図書館で借りました。真偽のほどは別にしても、なかなか示唆に富む内容でした。ただ、私の場合は結構「女性脳」なのかもしれないですね。50の設問があるテストが載っているのですが、それはすっ飛ばしました。やってから返却すればよかった。

三銃士(上・中・下)

NHKで人形劇が始まったようなので、いい機会と思って購入。基本的にフランス嫌いなもので、アレクサンドル・デュマの作品を読むのもこれが初めてだったりします。

いや、これが滅法面白い。子供向けの絵本の原作が、結構大人でも楽しめる(ガリバー旅行記もそうでした)のはよくあるパターンですが、さすが文豪として名高いデュマだけあります。フランス文学も悪くないかも。

かのセルバンテスの名作「ドン・キホーテ」を意識して書かれていることは明白ですね。フランス中世末期の時事風俗が窺えるのも勉強になります。

笑うカイチュウ

これも図書館で借りたんですが、こんな本まで図書館にあるとは・・・。前に目黒寄生虫館の亀谷 了先生の「おはよう奇声中さん」という本を読んで以来、サナダムシ、カイチュウの類には興味を持っています。幸い、私は花粉症ではないのですが、花粉症でお悩みの方はぜひお腹に一匹虫を飼うことをお勧めします。

オペレーティングシステム

情報処理学科の学生向けテキスト。ベイシア併設のスバル書店で購入しました。内容としてはいささか旧聞に属するかもしれませんが、教科書としてならありなのかな。自分の知識が間違っていないか、チェックするために読んでます。

その「エコ常識」が環境を破壊する

もはや商業化されつくしてしまった感のある「エコ」ですが、リサイクルすることが返って環境負荷を高めるかもしれない、というお話。まだ中身は読んでいませんが、同級生のK田君がJCの広報誌で取り上げていたので読んでみようと思い、購入しました。

それにしてもわからないのが、ペットボトルのキャップを集めることがなぜ環境活動につながるのか、です。キャップよりも本体のほうが効果大きいんじゃないのかと思うのですが・・・。