バリ島に行ってきました(その3)

バリ島に行ってからかれこれ1年半経過していて、いまさら続きを書くのもどうかという状態ですが、1年半前の記事の続きです。

3/21

2015年は、3/21がニュピでした。ニュピというのはヒンドゥー教のお正月で、市民は外出禁止、熱心な教徒は食事もせず1日を静かに過ごします。外国人旅行客も、ホテルから出られません。
で、ホテルの部屋にも注意書きが配られて、外出禁止はもちろん、あまりうるさくするなとか音楽をかけるなとかできれば電気を使うなとか(ローソクは貸すから)とか、いろいろ言われたのですが、当日になってみれば、確かに外出禁止ではあるものの、清掃のサービスはやってくるし洗濯もしてくれるし、ホテル内はうろつけるし、ということで、うろうろ。
ホテルと直結している海岸です。

昼ごはんだったかな、ミーゴレン。

これにフィッシュアンドチップスを付けてビール飲んだんだっけ。

ニュピの看板。

その他、ホテル内の写真色々。













ホテル内のプールでは子どもが歓声上げてるし、スパの施設も営業しているし(頼もうかと思ったら予約でいっぱいで断られた)、なんだホテル内は治外法権か、と思っていました。
レストランが18:00で閉まり、その後食事の手段がないというのは気になりましたけど。最後に食べたナシゴレン

で、たらふく食べて部屋にいたら、19:00頃、見回りの人がやってきて、バスルーム以外の照明を消せと。夜はまじめに(?)ニュピをやるみたいです。プールも無人なのだと思います。外は真っ暗で、風の音しかしない。

バリ島に行ってきました(その2)

先日の記事の続きです。

3/20

3/20のレギャン通りは、朝から閉鎖されていまして、

準備中のオゴオゴがたくさん。







材質が気になったので接写しました。3/19に案内してもらったガイドさんは、「竹で枠組み作って新聞紙貼って表面はペンキだよ」と言っていたのですが、とてもそうは見えません。発泡スチロールか何か?

オゴオゴは日本で言えば節分のようなもので、像は鬼をかたどったものです。
これに悪霊が乗り移るので、パレードが終わったら燃やしてしまう、といったようなことがWebでぐぐった範囲でもあちこちに書かれていますが、まともに燃える気がしません。燃やしたら黒い煙が出そうです。
というか、夜になってわかったのですが、オゴオゴには電飾も装備されており、発電機まで入っています(ブババババと音がしていました)。燃やせるようなものには見えません。

昼ごはんは近所のワルン*1で。

で、パレードが何時から始まるのか、前日のガイドさんは「15:00頃じゃない?」と言っていたのでとりあえずそのちょっと前からレギャン通りの外が見えるカフェでビール飲みながら待ってたんですが、

その店の店員さんに聞いてみたら、19:00からとのこと。それならいくらなんでも時間がありすぎなので、いったんホテルに戻って、念のためフロントでも聞いてみたら17:00からと言われ、またレギャン通りに行って今度はそこのコンビニの店員さんに聞いてみたらやっぱり19:00からと言われて。

で、結局始まったのは19:00すぎでした。暗かったのと私の腕が悪いとで、あまりよい写真はないのですが。

オゴオゴが電線にひっかかったので、それ用の棒を使って電線をどかしている図。


最終的に、広めの交差点でオゴオゴが集結して、何かこう、アピール(?)か対決(?)的なことをしていたようなのですが、何しろ言葉がわからないのと、よく見えないこともあって、途中でホテルに撤収しました。途中、いつものバーは開いているかな、と覗いてみたのですが、いつもより早く閉まっていました。日本で言えば大晦日ですからねえ。

続きはまた後日。

*1:地元の人が使っているような小さな食堂

バリ島に行ってきました(その1)

先日、休暇を取りまして、インドネシアのバリ島に行ってきました。
出発前に、ガイドブックを買いに行って、うっかり間違ってパリのガイドブックを買ってきてしまったのは内緒だ。

3/17

初日はほぼ移動でつぶれましたね。
セントレアから出発。出発時、日焼け止めとドライバーが検査に引っかかりました。日焼け止め(液体だからひっかかる)を手荷物に入れてしまったのは私のうっかりですし、ドライバーについては、自転車のバックミラーの増し締め用にリュックに入れっぱなしになっていたのをすっかり忘れていました…… セントレアで別の箱に詰めてもらい、バリでコンベアーに流れてくる、はずだったのですが、待てど暮らせど流れてこないので諦めました。その結果、初日は日焼け止めなしで行動することになり、かなり日焼けしてしまいました……

機内食(昼食)。まあ、エコノミーじゃこんなもんだ。

シンガポールで乗り換え。この時、時差(1時間)ぶん私の腕時計はずれていたわけですが、そしてそれを考慮してまだ時間があるなと待っていたわけですが、ふと腕時計を見て、うわもう出発直前じゃんでもなぜかゲート閉まってる! と焦ったのも内緒だ。
機内食(夕食)。ブレているのは飛行機が揺れていたからです。ときどき気流の悪いところを飛んで揺れるのはしょうがないですが、食事中に揺れるとあまり嬉しくないですな。

ホテル着ー。

初日は、ホテルのプールサイドのバーでビール飲んで終了。

3/18

ホテルのフロントの建物。昼間見るとこう見えます。

こういうところで朝ごはん。ビュッフェ形式。

こんな感じで。

ホテル内にそれなりのプールがあります。

ホテルのすぐ裏がビーチで、水着のまま行けるのですが、波が強くて泳ぐというよりサーファー御用達の浜らしい。ホテルの客はたいていプールで泳いでました。

この日は、レギャン通りをぶらぶらと。レギャン通りというのは、「レストランや土産物店、ホテルが密集する観光客で賑わう一大繁華街」(Wikipediaより)です。まあなんだ。観光客がぶらぶらしてるとあれ買えこれ買えとうるさいのなんの。

サークルKがいっぱい。本当にいたるところにありました。

とにかく暑くて喉がかわくので、ビールと一緒にフィッシュアンドチップスとか食べたり。このバーは、このあと滞在中ほぼ毎日通ってました。

こんな交通量でも信号はなし。それにしてもバイク多い。
バリ島には鉄道もなく、バスの類もあまりない(あっても定刻に来ない)ので、まずはバイクがないと生活できないとのこと。

こういうお供え(チャナンというそうです)が道端の至る所にありました。うっかり踏んでしまいそう(いやさ、杖をついた目が悪そうな白人のおっさんが、大量のお供えのあるところを通りがかった時には思わず声かけた)。

ベモ・コーナーという交差点ですが、こういったお地蔵さんのような宗教施設は本当にいたるところにあります。

ミーバッソ(とビール)

少し歩いて、クタのビーチ。

「ウミガメを守れ!」という看板が。

3/19

3/19は、ひまわりバリツアーというところで、日本語が堪能なガイドさんをクルマと運転込みで1日お願いし、ウブド方面を回ってきました。
ゴアガジャ遺跡。




テガラランのライステラス(棚田)を見ながらランチ。

サテ・アラム(焼き鳥)とナシゴレン

デザートはピサンゴレン。バナナを揚げたものですが、日本のバナナより小さく、酸味があります。

その後、ウブドの町中をうろうろと。



EDAMAMEつまみながらビール飲んだり。

ばんごはん。イブオカというお店のバビグリン(豚の丸焼き(の切れ端)をのっけたごはん)。ウブドではかなり有名なお店のようです。

その後、サレン・アグン宮殿でバリ舞踊。




ところで、3/21*1ヒンズー教のお正月(ニュピ)で、その前日は、オゴオゴというお神輿的なものが通りを練り歩きます。この造詣がすごい。3/19のウブドで見かけた準備中のオゴオゴがこちら。

オゴオゴの写真はたくさん撮ったのですが、続きはまた今度。

*1:太陰暦で閏月的な調整もないので日付は毎年変わります。

「本当の基礎からのWebアプリケーション入門――Webサーバを作ってみよう」いちおう完結しました。

正月休み明けの話を今頃はてなダイアリーに書くのも何ですが、開始時にここで紹介しましたので終了についても書きます。
本当の基礎からのWebアプリケーション入門――Webサーバを作ってみよう
http://kmaebashi.com/programmer/webserver/index.html
1年半ほどかかりましたが、一応完結いたしました。1年半のうち1年ほどは放置状態でしたけれども。
上記のリンクを見ていただければわかるように、この記事は、以下のような構成になっています。

  • TCPサーバ/クライアントを作る
  • Webサーバを作る
  • 落ち穂拾い(その1)
  • 落ち穂拾い(その2)
  • POSTメソッド
  • へなちょこサーブレットコンテナもどき「Henacat」を作る
  • Cookieに対応する
  • セッションに対応する

最初は簡易的なWebサーバを作っていますが、最終的にはへなちょこなサーブレットコンテナHenacat(Tomcatのへなちょこ版、という意味で命名しています)を作成し、Cookieとセッションにも対応しています。
とはいえ、ここまで書いても、プログラムソースは1000行にもなりません(特に圧縮した書き方をしているわけでもありません。まあ、コメントはほとんど入れていませんが)。
今どきサーブレットガリガリコードを書いている人がいるとも思えませんが、どのような言語やフレームワークを使うにせよ、Webアプリケーションを作るなら、ここで挙げたような知識は必須です。そして、何かを理解するときに極めて有効な手段は、実際にそれを作ってみることです(私自身、たいへん勉強になりました)。

「本当の基礎から」Webアプリケーションを理解するには役に立つ記事になっているという自負はあります。よければ読んでやってください。

また、記事中の間違いやミス(特にセキュリティに関するもの)がありましたらご指摘いただけると幸いです。

「本当の基礎からのWebアプリケーション入門――Webサーバを作ってみよう」始めました

以前から「誰か書いてくれませんかね」とか言っていた「本当の基礎からのWebアプリケーション入門――Webサーバを作ってみよう」ですが、誰も書いてくれないので自分で書きました。

本当の基礎からのWebアプリケーション入門――Webサーバを作ってみよう
http://kmaebashi.com/programmer/webserver/index.html

現状、合計で140行くらいのJavaプログラムで、普通に画像やCSSを含むWebページが表示できています。こちらのページの下のほうにも画像を貼っていますが、こんな感じで、ローカルのファイルシステムに置いてある私のWebサイトのトップページが表示できていますし、もちろんリンクをクリックして遷移することもできます。

「えっ? Webサーバってこんなに簡単に書けるの?」と思う人も多いのではないでしょうか。
もちろんこんなのは「わかっている人」からすれば、しごくあたりまえのプログラムに過ぎません。
「おいおい、実際にWebサーバを作るかどうかはともかく、こんなことも知らないでWebアプリを書いている奴いるのかよ」と思うベテランの方もいると思います。正しい感覚です。
でも、そういうベテランの人は、HTTPの「正体」をどこでどんな形で学んだのでしょうか。私自身はと言うと、Perl4でおそるおそるCGIを書いていた頃、そのものずばりの情報がなかなかなくて、CGI自体はサンプルを見れば書けるものの、すっきりしない思いを抱えていた記憶があります。
さすがに昔の話なのでいろいろ記憶は曖昧ですが、私にとって、そこの霧を晴らしてくれたのは、ASCIIの256倍シリーズの「インターネットを256倍使うための本」に載っていた40行くらいのシェルスクリプトによるWebサーバでした。「こんな簡単な仕組みだったんだ」と感動したものです。手元に本がないので記憶で書きますが、「こんなものに世界中が踊っているのを見ると、笑えるのを通り越して背中に冷たいものを感じずにはいられない」というようなことが書いてあったかと思います*1

とはいえいまどきinetdとシェルスクリプトは全プログラマの共通知識でもないでしょうし、ここはひとつJavaあたりで*2同じようにサーバを作る記事があれば役に立つ人もいるのではないか、ということで書いてみました。

ところで、最初に挙げたリンク先を見てもらえばわかるように、こういう記事を「誰か書いてくれませんかね」と言っていたのは5年も6年も前のことです。
なぜ今になって改めて書く気になったかというと、仕事がヒマになったとかそんなことは全然なく*3先日はてブで話題になった以下のページおよびそのブコメが発端です。
今すぐ辞めて欲しい、「Ruby on Rails勉強してます」「CakePHP勉強してます」 – sumyapp
この記事には、「だったらみんなアセンブラから勉強しろっていうのかよ!!」的なブコメやコメントがたくさん付きました。
でも、Joel Spolskyが「漏れのある抽象化」と呼んだようにあらゆる抽象化には漏れがあるものですが、Webアプリケーションにおける水の漏れっぷりは、たとえば高級言語アセンブラを抽象化しているレベルの比ではない。上の記事の著者の方はむしろDB周り(ORマッパー)を心配されていますが*4HTTP側もだだ漏れであり、到底それを知らずにアプリケーションが書けるレベルにはないと思っています。このへんの「漏れの程度の差」を無視して「アセンブラから勉強しろっていうのかよ!」ってのはぶっちゃけ因縁つけてるレベルに見えます。

あのバトルに対する、私なりの返歌として。

ヒマなわけではないので今後の進め方は保証できませんが、よければ読んでみてくださいませ。

*1:追記:お盆で実家に行ってきたので256倍本を回収してきました。正確には『世間がこんなモノに踊っているのかと思うと、悲しいのを通り越して、薄ら寒いものを感じずにはいられない』でした。

*2:いやもちろんJavaが全プログラマの共通知識というわけでもないでしょうが、たぶんシェルスクリプトよりはマシでは?

*3:勘弁して欲しい…

*4:もちろんそちらも心配ですが

SoftwareDesign2012年9月号に記事を書かせていただきました & erattaのお詫び

遅い報告になってしまいましたが、タイトルのとおり、SoftwareDesign 2012年9月号に記事を書かせていただきました。

SoftwareDesignトップページ
該当号もくじ

特集「C言語のポインタは必要ですか?」の2番目の記事「Part2:ポインタの壁の克服の仕方」を書かせていただいております。
テーマがテーマだけに、「C言語 ポインタ完全制覇」のダイジェスト的なものになっている面はありますが、はてなブックマークでも定期的にCのポインタが話題になるようですから、今こういう記事を書くことにも相応の価値はあるのではないかと思っています。
また、ISO C99についても多少言及しました。

そして、早々にミスが見つかってしまいました。申しわけありません。

p.30 「空の[]について」の上の章、下から6行目
誤)
「intの配列(要素数3)の配列(要素数5)」と読めます。
正)
「intの配列(要素数5)の配列(要素数3)」と読めます。

p.31 図1
誤)
int a[5][3]という配列において
正)
int a[3][5]という配列において

多次元配列の読み方のところですので、今回の記事において、かなり重大なミスかと思います。
大変申しわけありませんでした。

Cの宣言は英語順で読もう、という話

Cでのポインタの読み方

上記のページ、現時点ではてなブックマークが1241ついています。同趣旨のことを私は1998年に以下のページに書きました。
配列とポインタの完全制覇
こちらのはてブ数は212…… きいいっ! 悔しい!!

などという話はさておき。

上記ページに関連してだと思うのですが、Twitterで@kinabaさんが以下のようにつぶやかれておりました。



『という方針のCの入門記事』ということであれば、WebではないのでURLは貼れませんが、たとえば柴田望洋先生の「秘伝 C言語問答 ポインタ編」*1には以下の記述があります(p.22)。

ここで、下のように考えると、int x;の部分が*ptrに相当すると考えられますね。


int x ;
int *ptr ;
――*ptrはint型変数であると言っているように解釈できますね。

で、実のところこれを意識した上で、私は「C言語 ポインタ完全制覇」にこう書きました(p.38)。

別の考え方として、


int *hoge_p;
という宣言について、hoge_pがhogeを指しているとき、*hoge_pはhogeと同じように使えますから、

ほらほらhoge_pに*を付けると、int型の変数hogeと同じように使えるんだよね。この宣言はつまり、hoge_pに*を付けたものがint型だという意味なんだよ

という説明をする人もいます。
この考え方は、確かにそれなりに通用するのですが(たとえば配列でも同じようにいえる)、では、


int *&hoge;
と書くと、int型の変数としてhogeが宣言できるのでしょうか?*2――やってみるとわかりますが、これはシンタックスエラーです。
それに、この考え方は、宣言の中にconstが割り込んでくると破綻しますし(式の中じゃconstは書けない)、関数へのポインタの宣言でも問題が発生します。

『関数へのポインタの宣言でも問題が発生します』について補足します。上記のような説明は、『使う時の構文と宣言の構文が似るようにという方針で設計されてる』という前提に従うわけですから、たとえばint *a;という宣言があったとき、これを『使う時』に*aと書くとint型になるよね、ということを前提としています。では関数へのポインタのときにはどうか。int (*func)(void);という宣言があったとき、これを『使う時』、みなさん(*func)()のように書くかというと*3、たいていfunc()と書くのではないでしょうか。少なくともこのケースでは、「使う時」の書き方と宣言がずれています。

実のところ関数へのポインタを持ち出すまでもなく、int *a;と宣言した変数を使うときにはa[i]と書くことなどは普通にあるのですから、『使う時の構文と宣言の構文が似るようにという方針』がさして役に立つとは思えません。『使う時』というのは式の中で使うということでしょうが、その式の中では配列がポインタに読み替えられるとか、関数が関数へのポインタに読み替えられるとか、関数定義の仮引数の宣言においてのみ最外周のはポインタを意味するとか、謎の規則がいっぱいある以上、結局、"a ptr to func returning ptr to func returning char"のような『コンパイラの内部表現っぽい表示』を経由しない限り、理解には至らないと私は思います。

最初に紹介したページのブクマコメントには、『実際にこんなコード書かれたらキレタ方ががいいと思う』とか『おとなしく typedef 使おうず』といったコメントがつきました。確かにsignal()みたいな関数はちょっと特殊な例かと思いますし、適切にtypedefを使ったり構造体をかませたりするほうがよいのは確かです。ただし、typedefは結局『コンパイラの内部表現っぽい表示』の一部に名前を付けてコピペする機能でしかないわけで、まずは宣言をきちんと読めていないと結局使いこなせないのではないでしょうか((そしてtypedefは構文上「記憶クラス指定子」なので、typedef自体を理解するのもたぶん結構難しい))。

さて。最後は宣伝しますよ。

「Cの宣言は英語で読め」とか、「配列は式の中ではポインタに読み変えられる」とか、「添字演算子は配列とは無関係だ」とか、「Cには多次元配列は存在しない」とか、役に立つ記述でいっぱいですよ!!

10年前の本ですが、今回「Cでのポインタの読み方」というページがホットエントリに上がってきたということは、たぶんまだこういう本の需要はあるのでしょう。そして上記ページとかこういう本とかに需要があるということ自体が、「結局のところコンパイラの内部表現っぽいレベルまで理解しないとCを使いこなせない」ということを意味しているのだと思います*4

*1:この本は何度も改版されています。「秘伝C言語問答 ポインタ編 第2版」→「図解C言語 ポインタの極意」→「詳解 C言語 ポインタ完全攻略」でいいのかな。ただし、私が持っているのは「新版 秘伝 C言語問答 ポインタ編」のみです。

*2:実はCを学び始めた頃、試したことがあります。私。

*3:書けますし動きますが

*4:「ポインタ完全制覇」では、Cの型について連結リストの図で説明しています。まさにコンパイラの内部表現ですが、それが必要だと私は判断しました。