[ Programming ] tab と space とインデント

annDamianセンセのPerl Best Practiceの影響なのか、 最近のPerl界隈では「タブは使うな、スペース使え」と盛んに言われていますが、 あえて断言しときます。こんなモンはバッドノウハウなんであって、 ベストプラクティスでもなんでもない

わたしもその通りだと思う。よほどできの悪いエディタでもない限り、 tab 幅は変更できる。tab 幅は固定ではなくて変更できるものと考えるべきだ。

たぶん、tab 幅 = 8固定なんて考えた奴らは Windows 標準付属のメモ帳みたいな そーとーお粗末なエディタしか使ったことがないか、エディタのマニュアルもろくに 読んでいない間抜けなんだろう。そんな奴らが決めたインデントルールなんて 見るに耐えない。実践するなんてもってのほかだ。

最初のインデントはスペース4個で、次のインデントはタブ1個、 その次はタブ1個にスペース4個……って、なんでこんな面倒なルール覚えなきゃならないのさ。 こんなもん覚えるくらいなら Win32 API の仕様を覚える方がまだましさ。 いうまでもないことだと思うけど、ルールは少なければ少ないほど良い。 できるだけ単純で、必要最低限にするべきだ。

tab をポンと押せばいいだけのところを、 なんで Space をガチャガチャと 4 回も押さなきゃいけないのさ。 それに Space で決め打ちしてしまうと柔軟性が失われるじゃない。 こんなダメルールが最近の流行らしいけど、率直に言って馬鹿としか思えない。 わたしはこんなルール実践する気にはならないね。

ちなみにわたしは自分のコードを見ると行頭のインデントは tab を使って、 そのほかでは Space を使っているみたい。tab 幅は状況によって変更。 通常は 4 だけど HTML の Table を書いていてインデントが深くなってしまったときとかは タブ幅 2 に変えてる。こうやって、状況に合わせてインデント幅を変えられることが tab の利点だと思うのだ。

"There are more than one way to do it."
tab が使われているコードを見ると狂ったように「スペースを使え」と叫ぶ人たちは もう一度この言葉を頭に叩き込みなおした方がいいよ。

Web メールユーザはなぜ増える？

友人と MUA ( Mail User Agents ) について話しているときに、 Web メールサービスについて話が及んだのだけど、そのときに

ブラウザは限界浅すぎなのでブラウザベースのメーラーとかは そのうちに飽きられるよ

という意見が出た。確かに Web ブラウザでできることは限られている。見た目も操作性も、可能性もデスクトップアプリケーションには遠く及ばない。 Ajax などを駆使することでだいぶ操作性は向上したが、それでも操作に対する遅延というのは無視できないものがある。

しかし、わたしは Web メールサービス は衰退しないだろうと思う。 Web メールの使用者が増加している理由は、見た目が綺麗になったからとか Ajax などの最新技術が使われているからだけではないと思うのだ。むしろ、これらよりも優先度の高い理由があると思う。

「どこからでも、どの OS からでもメールを確認できること」
これが Web メールを選択する最大の理由ではないだろうか？

わたしが Web メールサービスを、メールコミュニケーションの主軸に添えたのは 2002 年からだ。当時は大学生だったのだが、大学から送られてきたメールは大学の情報処理センターか研究室からでしか読むことができなかった。講義が入っていない空いている時間を使って、メールを読むためだけに情報処理センターに出向かなくてはならなかったのだ。空席がなくてメールの確認もできなかったときもある。
「電子メールなんて一日中机の前に座っていない限り、たいして役に立たないじゃない」
正直いって、そのときは電子メールはそれほど便利な情報手段ではないと思っていた。

しかし、Web メールサービスを使うようになってから先の評価は逆転する。どこからでも、どの OS からでも、それこそ携帯電話からでもメールが確認できるし相手に返信して連絡を取ることもできる。たとえば、家にいても大学の連絡を確認できるし、大学にいても宅配サービスのお知らせを受け取れて再配達までお願いできる。
「ああ、なんて便利なんだろう。これは就職してからも役に立つに違いない。」
そう思ったわたしは Web メールサービスをメール通信手段の中心にしたのだ。

たぶん出張などで会社の外を回る方になら、Web メールサービスの便利さがわかるのではないだろうか？外を回っているときに、取引先からメールが来ていないかどうか確認するために本社に電話して部下に確認させたりしたことはないだろうか( わたしは確認させられたことがある )。あるいは夜遅くに本社に戻って、その日にたまりにたまったメールを日付が変わるまで処理したりしたことはないだろうか( しかも緊急の要件が入っていたりする )。 Web メールサービスを使えばこんな馬鹿らしいことはしなくてすむのだ。メールの確認は昼食や移動中に ( 携帯電話で喚いて回りに迷惑をかけることなく ) 行える。もちろん返信だってOK だ。緊急の要件があれば、すぐに駆けつけることだってできるだろう。相手にとっても自分にとってもプラスになる素晴らしいサービスだ。

さらに最近では、スケジュール帳サービスも提供してくれるところがある。たとえば Windows Live Mail サービス。これは Office Outlook をそのまま Web サービスに持ってきたようなものだ。Public beta が始まった当初は酷かったものの、今ではずいぶん使いやすくなっている。共有スケジュール機能も実装され、これによって友人やチームメンバーのスケジュールを確認できるようにもなった。うまく使えばとても便利。

メールやスケジュール帳に限らず、「いつでもどこからでもどの端末からも確認できると便利」なサービスというのは見栄えがいいからだとか最先端の技術が使われているから今があるのではなくて、必要とするユーザがいて彼らの要望をかなえるために存在しているのだと思う。だから、流行廃りではなくて、彼らの要求を満たすより優れた手段が考え出されるまではなくなることはないと思うのだ。

[ Python ] IronPython β6 released

IronPython β6 が公開されました。ダウンロードは こちら から。

We have just released IronPython 1.0 Beta 6. This release focuses primarily on fixing bugs and improving compatibility with CPython. Major cleanups includes supporting __metaclass__ at the module level, using __mro__ for new-style class method resolution, and a massive cleanup to make sure all of our comparisons are identical to CPython. With this release we’ve also improved the performance of calls to arbitrary .NET assemblies by enabling our call-optimization for all assemblies and updated the tutorial for beta 6. One change that has the potential to break people in beta 6 is that we are deprecating clr.Path and instead suggesting everyone switch over to using sys.path instead. This is more inline with how CPython searches for .pyd extension files and we believe will simplify the loading story. This also means that the current working directory will be included in the search path by default which seems to have been an issue that caused many problems.

バグ修正と CPython との互換性向上が主な変更点で、__metaclass__ のモジュールレベルでのサポートや __mro__ の変更などが行われて、CPython との互換性が高められています。 また、clr.path を廃止する 可能性があるので clr.path の替わりに sys.path を使うことが推奨されています。

モジュールサーチパスの変更は大きな影響がありそう。

Reference

IronPython Workspace

[ Publishing ] Effective C++ 第三版 / LDAP Super Expert

Effective C++ 第三版 の翻訳本が 4/29 に出版されます。
現在 Amazon で予約受付中。 こちら からどうぞ。

肝心の内容ですが、Amazon.com で原著のサンプルが読めます。

改訂2版 の 50項目 から、5項目増やされて 55項目になったようです。購入するかどうかは翻訳の質で決めようと思います。

2006.04.18 追記
技術評論社からLDAP Super Expertという書籍がでています。 運用に関する解説が多く、LDAP 実装についてもひとつだけに偏るのではなく、 OpenLDAP, Fedora Directory Server, Active Directry について書かれているほか LDAP クライアントのプログラミング入門まであります。プログラミング入門では 定番の C, Java だけではなく Ruby, PHP, Python, Perl までそろってます。

少し前までネットワークを触っていたし、家でも LDAP ネットワークを使っているので 読みたい本。

[ Web application, Ajax ] ajaxXLS

ajaxlaunch で新しいサービスが公開された。今回は ajaxXLS という Microsoft Excel のビューワのようだ。

The majority of Microsoft Word, Microsoft Excel and Microsoft PowerPoint users are casual home users who, like the mom in the above scenario, need to simply open a file that's been sent to them and then print it, or maybe make minor edits and pass it along. The only way to get Microsoft Excel is to buy Microsoft Office, which costs $400+. Using OpenOffice is another option, but few people know about this product, so they end up pirating a copy of Microsoft Office or trekking to their local computer store and spending a lot of money to solve a simple computing task. Starting today, the world has another option - ajaxXLS 0.5. This program, like ajaxWrite and ajaxSketch, is an AJAX program that loads in seconds directly over the Internet. One click on ajaxXLS.com and you have a spreadsheet program to open any .xls file. Nothing to buy. Nothing to install. No need to register.

確かにファイルを開くためだけに MS-Office を購入するというのは コストがかかりすぎる選択だ。しかし、ただ単にファイルを開くだけというのは 必要な機能を備えているとはいえない。 VBA を使ってデータ処理をするとまでは 行かなくても、簡単な編集や入力なら多くのユーザが行うはずだ。 このことは Michael も認めており、現在は編集機能をつけた ajaxXLS 0.51 を開発しているそうだ。

We're making two versions of ajaxXLS available. ajaxXLS 0.5 viewer is suitable for viewing and printing existing Microsoft Excel documents, but it does not support editing. It's the first free .xls web viewer program, but that's only half the problem. People need to edit .xls documents too and we're working on that. We're also making an ajaxXLS 0.51 editor pre-release available which does allow editing, but is not reliable. We wanted to show you the latest products from our lab and what is possible so you'll see the direction we're moving. We'll be making constant improvements to this version which will happen seamlessly on the ajaxXLS web site (which is one of the major benefits of Internet delivered software - you always get the latest version).
以下、大雑把な訳
13日に公開された ajaxXLS は単なる viewer 、つまりファイルを開いて印刷することくらいにしか 使えないけど、プログラムの半分でしかない。ユーザは編集機能も必要としているから、いまは そのための作業を行っているよ。編集機能もつけた ajaxXLS 0.51 プレリリース版も作ったんだけど、 信頼性が低いんだ。プログラムの改良は継ぎ目なく行われているよ。

ajaxXLS に編集機能がつけば、とても便利なサービスになると思う。 出先でエクセルファイルを編集する必要が出ても Firefox で ajaxXLS にアクセスするだけでいいのだから、いつでもどこからでも エクセルファイルの編集ができる。MS-Office は購入するためにかなりのお金が必要で 自分が使うだけでもインストールする PC の台数が制限される。 OpenOffice は巨大なファイルを DL するためにかなりの時間がかかる。 ajaxXLS 0.5 はだいたい 5 秒くらいで起動するから、"Plug and Play" といっていいんじゃないかな。 編集機能が加わるのが待ち遠しい。

それと、リンク先に指定したエクセルファイルを、リンクをクリックしたら自動的に ajaxXLS で開くためのコードも紹介されている。ajaxXLS を提供するサーバは 2 つあるので 自分の好きなほうを使ってほしい。コード中にあるエクセルファイルへの URL と、 リンクさせる文字列や画像などのオブジェクトは自分で設定してくださいね。

アメリカのサーバを利用する場合
<a href="www.ajaxlaunch.com/misc/nojscript.html" onclick="window.open ('http://usa.ajaxxls.com/apps/calc/content/index.xul? doc=エクセルファイルの URL を指定', 'ajax13','scrollbars,resizeable,width=800,height=600'); return false;"> リンクさせるオブジェクト </a>

EU のサーバを利用する場合
<a href="www.ajaxlaunch.com/misc/nojscript.html" onclick="window.open ('http://eu.ajaxxls.com/apps/calc/content/index.xul? doc=エクセルファイルの URL を指定',' ajax13','scrollbars,resizeable,width=800,height=600'); return false;"> リンクさせるオブジェクト </a>

Reference

ajaxLaunch

ajaxXLS

ajaxXLS Forum

[.NET] Charactor encoding with .NET Framework class library.

IronPython と CPython のエンコーディング宣言とかの挙動 のコメントより。PHP とかだと文字コード 周りで苦労することが多いので、メモっておくことにしました。

.NET では、文字コードは .NET Framework class library の encoding クラスが担当する。 MSDN Library for VS2005 ( March 2006 )だと

ms-help://MS.MSDNQTR.v80.en/MS.MSDN.v80/MS.NETDEVFX.v20.en/
cpref12/html/T_System_Text_Encoding.htm

ms-help://MS.MSDNQTR.v80.en/MS.MSDN.v80/MS.NETDEVFX.v20.en/
cpref12/html/T_System_Text_Encoding_Members.htm
*Microsoft Document Explore を起動して URL に上記を指定します

が参考になります。.NET 系では言語に関係なく encoding クラスを呼べばいいので 他の言語に比べて楽にコードが書けそう。

[ Publishing ] 書籍メモ

Ruby レシピブック

実際なんか書くときには役に立つ
らしいですよ。

Perl Cookbook(原著)
日本語版 Perlクックブック volume1 / volume 2

ないと困るらしいです。
ちなみに、原著では1冊。邦訳版は上下巻です。

MySQL Cookbook(原著) / 日本語版 vol.1 日本語版 vol.2

あるとものすごく便利だとか。
これも原著だと1冊。翻訳版では上下2冊です。

C++ in a nutshell(原著)
C++ ランゲージリファレンス / C++ ライブラリクイックリファレンス

ランゲージリファレンスでは C++ の細かな言語仕様が書かれています。 ライブラリクイックリファレンスでは、標準ライブラリが網羅されています。 どちらも学習書としては使えません。一通り C++ を学習して、実際にコードを書くようになってから、 この関数はどんな仕様だったかな、あるいは書いたコードを動作させたら不可解な結果に なってしまったけどなんでだろう というときに確認する形で使用することになるでしょう。 ライブラリリファレンスは常に手元においておきたい一冊です。

Python Essential Reference

python.org にあるリファレンスはどうも使いづらい。 でも、リファレンスがないとコードを書きにくい。 Safari にもまだ入りそうにないので 書籍で購入することにしました。

Programming Ruby Second Edition(原著)
プログラミング Ruby 第二版 言語編 / ライブラリ編

日本語版の出版予定が 5月に延期されています。がっくり＿|￣|○

アンビエントファインダビリティ

キターーーーーーー
と思ったものの 4/11 朝でも Amazon にない。
4/12 18:00 にチェックしてみたら在庫切れ・・・（；´Д｀）

配慮と理解が欠けているのは「こちら側」の企業じゃないの？

Web2.0のあっち側の企業はこっち側の企業から稼げるか？　特に『はてな』や『mixi』は？

理解しようとする強い姿勢が無いと稼ぎそびれると考えられる点です。楽しい倶楽部のような雰囲気だけではこっち側からあっち側にお金は流れません。

やれやれ、勘違いさんがいるから日本は IT 先進国から脱落したんだよ。こちらとあちらでは、 コスト構造とかいろんなことが全く違う。だから、こちら側の伝統はあちら側では通用しないんだよ。

、『あっち側に住むはてなは、こっち側のメーカーとの付き合い、文化の違いにほとほと嫌気が差したのだろう』と判断しています。

というのは、こちら側の企業が、こちら側のやり方を無理やり押し付けようとしたから。 わたしも経験したことだけど、こちら側の企業は「こっちのほうがでかいんだから」とか 「こっちのほうが伝統があるんだから」とかいって、差異を理解しようともしない。 そりゃ、「ほとほと嫌気が差し」たりもするさ。

あっち側に住む彼らはこっち側との付き合いをあまり大切にしていません。まあ、ベンチャーキャピタルは別でしょうが。

何を勘違いしているのか。dan 氏が Our door is open 24/7 で述べているように、あちら側のドアは いつでも開いている。そもそも、あちら側の世界は「無限大の不特定多数」が主体である。 企業が製品やサービスを開発したとして、ユーザがそれを気に入ったなら、それを自分のサイトや Weblog に紹介することでどんどん広まっていく。こちら側の世界のようにごく少数の権威に 莫大な広告費を払える一部の企業の商品だけが広く知れ渡ってそれが消費活動の中心になるような 文化ではないのだ。だから、企業の大小に関わらず、たとえ個人であっても商品 ( サービスとかね ) を公開することができる。Google や Amazon は自社の API を公開している。Amazon の API を使えば 実店舗なしで、商品情報・管理システムを開発すること無しで、決済システムも自分で開発することなく 商用サイトを作れるのだ ( 例: amazlet.com )。Google Map を使えば地図情報を自分で集めなくても自分の持っている情報 あるいは技術と組み合わせた新しいサービスを公開することができる ( 例: はてなマップ )。CNET でも権威も名声もない一般ユーザから 同サイトのブログの執筆者を募集している。

今となっては、さまざまなサイトがさまざまな形で「無限大の不特定多数」の参加を促しているのだ。 これだけお膳立てされていて「こちら側との付き合いをあまり大切にしていない」とか 「ギークとしての彼らとはまともにビジネスの話が出来ない」と評するのはどうしたものか。 ただ単に開いているドアを見てみぬ振りをしているだけではないか。

Geek だとか Hacker と呼ばれる人たちは、多くの場合はとても聡明だ。彼らが「こちら側のルール」を「あちら側」に 適用することを拒否するのだとしたら、それには必ず理由がある。「あちら側」で拒否されたと思い込んでふてくさている「こちら側」の方たちがまずするべきことは、なぜ「こちら側のルール」を 「あちら側」に持っていけないのかを考えることではないでしょうか？もしかしたら、 貴方たちはドアから入るのではなくて、家の壁を破壊して中に入り込もうとしていたのかもしれない。

[ASP.NET] Atlas March 2006 CTP Released

Atlas March 2006 CTP
Atlas は Ajax をサポートする ASP.NET2.0 の拡張セット。
クライアントサイドに記述するスクリプトの Framework とサーバサイドに作成するコントロールが中心となっているそうな。

わたしはまだ ASP.NET は使えないんだけどね。
Joel 氏とかの Essay をみるととても楽しそう。
以下は Overview からの転載。

This new Web development technology from Microsoft integrates client script libraries with the ASP.NET 2.0 server-based development framework. In addition, 'Atlas' offers you the same type of development platform for client-based Web pages that ASP.NET offers for server-based pages. And because 'Atlas' is an extension of ASP.NET, it is fully integrated with server-based services. “Atlas” makes it possible to easily take advantage of AJAX techniques on the Web and enables you to create ASP.NET pages with a rich, responsive UI and server communication. However, ‘Atlas’ isn’t just for ASP.NET. You can take advantage of the rich client framework to easily build client-centric Web applications that integrate with any backend data provider.

• “Atlas” enables you to take full advantage of the capabilities of the browser to deliver richer web experiences that work on any modern browser
• “Atlas” enables ASP.NET developers to enrich their web applications with incredible ease
• “Atlas” includes a rich client-side Javascript framework that enables easy creation and reuse of script components and rich client-side behaviors.
• “Atlas” makes it super easy to consume services from ASP.NET, and to build composite applications from services on the programmable web.

大雑把に訳してみた。誤訳などのご指摘がありましたら遠慮なくコメントをくださいませ。

Atlas はサーバサイドの開発を主とするフレームワーク ASP.NET 2.0 にクライアントサイドのスクリプト開発に使うライブラリを追加統合するもの。Atlas を使うとサーバサイドプログラムの開発と同じようにしてクライアントサイドを開発することができる。それは、Atlas が ASP.NET の拡張だからで、サーバーサイドのサービスと完全に一体化するからだ。Atlas は Ajax を使った開発を簡単にするし、Web ページの操作性をよりいいものにする。しかし、Atlas は ASP.NET そのものではなく、クライアントを中心とした Web アプリの開発をより簡単にするものだ。

• Atlas はより優れたユーザエクスペリエンスを提供するためのブラウザが持つ可能性を最大限に引き出だす。
• Atlas は Web アプリの開発を信じられないほど簡単にする。
• Atlas は スクリプトコンポーネントの作成や再利用を簡単にしたり、 クライアントにおける表現をより豊かにする Javascript のフレームワークを持っている。
• ASP.NET の提供するサービスを簡単に利用できるようにして、そのWeb API を使ったアプリの作成をできるようにする。

リストの最後はかなりテキトーな訳です。なんにしても面白そう。

[Python] IronPython beta 5 released

Python の .NET 実装である IronPython の beta 5 が公開されています。 ダウンロードはこちら。

We have just released IronPython 1.0 Beta 5. This release focuses primarily on improving IronPython’s performance. In this area we’ve reduced working set and startup type by optimizing methods on-demand, improved the speed of attribute access, reduced the overhead in many basic operations (e.g. equality checks and uninitialized checks for local variables), and done other various fine tuning. As usual there are also a good number of bug fixes (primarily focused on community reported bugs). There was also one significant API change in the .NET <-> Python interoperability area:

今回の修正はパフォーマンスの改善がメインのようです。他に、.NET と Python をつなぐ API にも変更が加えられたようです。

参考：
IronPython Workspace

April Fool

本エントリは April fool に参加しているページを紹介しています。
本エントリのリンクは 2005.04.01 のみ有効となっている場合もありますので、 リンク切れなどの苦情の送信はご遠慮ください。

今日は April fool. いままでは一部のニュースサイトとかが お遊びネタを披露してくれるくらいだったのだけど、今年は 今までとちょっと違うみたい。ニュースサイトだけじゃなくて 個人のブログとかでも April fool ネタが披露されています。

まずは、毎年恒例の Impress うぉっち。偽造ホリエモンメールを皮肉ったジョーク記事のほか、 エラーメッセージにもユーモアが埋め込まれています。今年もとても楽しい内容。

そして、 Wikipedia の April fool 祭り

今年一番楽しませてもらったのは、UIEvolution CEO の Satoshi 氏のブログ Life is beautiful のエントリ「UIE Japan は大変な会社になってしまったようだ」だ。毎日チェックしているのだけど、今日は画像を見てかなり驚いた。 だってメイドさんの格好をしたおねーさんが一緒にプログラミングしているんだもの（笑
同エントリにある trackback 先では・・・

今朝になって(日本時間の４月１日)・・・

という部分を読んで納得。あ、そうか今日は April fool だったんだ。 でも、これが実現したらがんばる人が増えそう。

さてさて、他に面白いジョークはないのかな、っと探し中(´･ω･` )

追記
Perlish Magazine: Ruby の会の人が Perl の人の振りをして発行したらしいです。( havana さん、情報 thanks! )