はてなダイアリーは新規募集を停止したそうだしはてなブックマークのホットエントリーに上がってくる頻度も減ってきた気がするし、ということで、はてなブログを開設しました。
http://kmaebashi.hatenablog.com/
K.Maebashi's はてなブログ
今後は原則として新規記事はそちらに上げます。
よろしくお願いいたします。
はてなダイアリーは新規募集を停止したそうだしはてなブックマークのホットエントリーに上がってくる頻度も減ってきた気がするし、ということで、はてなブログを開設しました。
http://kmaebashi.hatenablog.com/
K.Maebashi's はてなブログ
今後は原則として新規記事はそちらに上げます。
よろしくお願いいたします。
名古屋近辺の自転車乗りにとって、京都というのは割と定番の行き先だと思います。
私も過去5回ほど行っています。他に行くところはないのか、と言われそうですが、150kmくらいで1日で走るのにはちょうどよいのと、新しいルートを調べるのがめんどうで、なんだか長期休暇のたびに京都に行ってしまいます。
1回目 | 2015年5月 | 一宮経由で行きだけ。帰りは輪行。 |
2回目 | 2016年5月 | 一宮経由で往復。雨が降って稲沢でリタイア。 |
3回目 | 2016年8月 | 行きは一宮経由。帰りは養老経由。 |
4回目 | 2017年5月 | 養老経由で往復。 |
5回目 | 2017年8月 | 行きは養老経由。天気が持たず帰りは輪行。 |
コースは基本関ヶ原から21号に乗って琵琶湖に突き当たったら南下して近江大橋を渡り、あとは1号線に乗る、というものです。関ヶ原までのルートとして一宮経由と養老経由があり、一宮経由の方が平坦なので最初はそちらを使っていたのですが、養老経由で関ヶ原に行くというのは私が週末にちょくちょく走るコースであり、道を知っているので最近はそちらです。交差点のたびにスマホ見て地図を確認するのも面倒なので。
午前6:00過ぎぐらいに名古屋を出て、到着が午後6:00頃になったりするレベルのヘタレですが、同じように京都に行こうという人の参考になりましたら。
ルート全体:
起点は便宜上名古屋駅にしています。豊公橋で庄内川を越え、県道79号に乗ります。
出発! 時刻は06:35。
以下、ルートは2017/08/13に行ったときのものですが、写真はそれ以外の日に撮ったものも含まれます。
途中、陸橋がありますが、軽車両進入禁止なので左の側道に入って踏切を渡ること。
このファミマのある交差点(町方新田新西馬)で右折。
藤ケ瀬のミニストップのある交差点で左折。ここのミニストップは、サイクルスタンドなんかもあったりして、なかなか自転車フレンドリーです。
サイクルスタンド。やや低い。
福岡大橋で揖斐川も越える。
ここから、養老山脈を越えることになります。途中、コンビニ絶滅地帯で、自販機はあるものの財布には5000円札からしかなく、当然こんな山道の自販機がマナカとかに対応しているはずもなく、ということでようやくコンビニに辿り着いたの図。
養老ランドの近くのカフェでモーニング。朝ごはんも食べてきているんですけどね。
その後、広瀬橋南の交差点で川を渡って、関ヶ原西町のサークルKのある交差点で21号に乗ります。
2019/05/02追記:
このサークルKは、2019年4月末現在、更地になっています。
21号を走っているところ。こういう、コントラストの強い夏の風景ってぐっと来ませんか。
21号線沿いのローソンで補給。補給といえばハンガーノックを恐れて甘いものを主体とすることが多いと思うのですが、この時期、塩分の補給もいるかな、とこんなものを。
「西円寺」の交差点で21号を降ります。
その後、米原警察署の交差点で陸橋に乗ってJRをまたぎます。この陸橋、軽車両進入禁止ではないはずですが、2段階右折で乗ろうとすると信号が車両感応式で、車が来ないと渡れない…… ちょっと越えてから左折で乗るのが正しいのかしら。
で、その後「喫茶エイト」とファミマがある交差点で左折。
そのファミマのトイレにて。なんだこれは。
女子トイレはこう。
その後1回左折して、「お食事処つるつる」へ。ほぼ毎回ここで昼ごはんを食べてます。
天ぷらざるそば。
このお店のすぐ裏が琵琶湖。
昼飯食べて再出発。湖岸道路を南下します
湖岸道路南下中。
そのまま湖岸道路を走り続けてもよいのですが、一部道が曲がりくねっているので、田舎道を走ってショートカットします。名古屋からで計測すると109kmくらいのところにあるローソンの角で左折。
「堤」の交差点で右折、大水口神社を越えたところで左折、あとはGoogle mapsか何かで適当に見てみてください。
途中、風車が見える。
湖岸道路に合流した直後に見える、怪しげな宗教施設。調べてみたら、天聖真美会なる手かざし系の新興宗教の施
イオンモール草津に寄って銀だこのたこ焼きを食べます。本場大阪のたこ焼きは「外はカリッ」としてなくて、私は期待して行った大阪でたいそうがっかりしたことです。大阪の人からしたら邪道かもしれませんが、私は「外はカリッ」が好きですね。
近江大橋には右折では乗れないので、ちょっとぐるぐる回る必要があります。
近江大橋。
この後、ちょっと住宅街のようなところを抜けて1号線に乗ります。Google地図に導かれてこのルートになったのですが、本当に生活道路なので、自転車とはいえ遠慮して走った方がよさそうです。
まず近江大橋を降りるところで車道に降りて、直進(?)して生活道路に入って、「カット&パーマ クレヨン」の角で左折して、片道交互通行の陸橋でJR東海道本線を越えます。
これで1号線に乗ったら、あとは1本道です。
京都は盆地なので、坂はそこそこありますし、最後の上り坂の後にはトンネルがあったりもしますが。
1号線は京都でいうところの五条通なので、適当に南下して七条通りに入ると京都タワーとか京都駅とかに着きます。
到着! (18:01)
5月に来たときは、06:19に出発して16:55着でした。結局すべては風向き次第でこれぐらいの時間差は出るようです。
というわけで、風呂で汗を流してからビール。
名古屋から京都まで約150km、これぐらいなら誰でも1日で来られる距離だと思います。私など、初心者なので、足の筋肉痛とかより、お尻の痛さがボトルネックになります。
1日がかりで京都に行くとして、2日目を観光に当てて3日目に帰ってこようとすると、3日連続で晴れの日が必要になります(まあ、2日目は多少天気が悪くてもよいですが)。この夏休みはどうにも天候不順で、3日連続で晴れる日がなかったので、今回は輪行で帰りました。いやあ新幹線って早いですね(当たり前)。
下は自転車を輪行袋に詰めた図。逆さに立ててあり、ハンドルとサドルで接地しています。この状態を保つなら、エンド金具って要らないんじゃないかなあ(私は念のため付けていますけれども……)。
ブログを開設したのでまずは自著の宣伝から。
Amazonで見ていただくとわかるように、私は6冊ほどプログラミング関連の書籍を書いていますが、
現状での最新の本は(とはいえ1年以上前ですが……)、「Webサーバを作りながら学ぶ 基礎からのWebアプリケーション開発入門」です。
この本は、Webアプリケーション開発者向けの入門書です。
Webアプリケーション開発について、基礎の基礎から説明します。その手段として、本書では、Webサーバを作ります。
Webサーバを作るといっても、PCを買ってきてLinuxとApacheをインストールして、という意味ではありません。ApacheのようなWebサーバのプログラムを自作するということです。
基礎の基礎とは言ってもそれはいくらなんでも基礎に戻りすぎではないのか、そもそもWebサーバなんてそんな簡単に作れるものなのか、とツッコミを入れたくなる人がいるかもしれません。しかし、簡単なものであれば、Webサーバを作ることはさほど難しくはありません。本書で作成するWebサーバの初期バージョンは、Javaで140行程度のプログラムです。
また、Webサーバを作るというと、「OSを作る」とか「プログラミング言語を作る」といったような、ちょっとマニアックな行為に思えるかもしれません。しかし、本書で扱う程度のWebサーバを作る知識は、マニアックでもなんでもなく、普通のWebアプリケーション開発者が、当然の常識として知っていなければならないことです。
本書は、TCPソケットによる通信のサンプルプログラムから始まって、次に静的なHTMLを表示できるWebサーバを作り、最終的にはTomcatのへなちょこ版であるサーブレットコンテナ「Henacat」を作るという構成になっています。Henacatには、Cookie、セッション、ファイルアップロードといった機能も搭載します。
こういった機能は、なにも自分で作らなくても、いまどき何らかのフレームワーク等が面倒を見てくれるものです。そうやって生産性を上げるのはおおいに結構なのですが、フレームワークの使い方だけ知っていても、いざ何らかのトラブルが起きた時、手の打ちようがない、というのでは困ります。結局、Webアプリケーションを作ろうと思ったら、Webの基礎であるHTTPを知っている必要があるのです。
こう言っては何ですが、今時、日々Webアプリケーションを書いているプログラマでも、このあたりの基礎的な知識が欠けていて、コピペプログラミングを一歩越えようとすると行き詰まったり、バグが出ても原因究明ができなかったり、セキュリティーホールの説明とかが理解できなかったりする、という人は結構いるように思います。
このような趣旨の本ですので、本書の内容はかなり「古臭い」ものになっています。本書の内容の大半は、15年以上前の本に書いてあってもおかしくありません。というより、15年くらい前にこんな本があったら、私自身がもっと実感を持ってWebアプリケーションを理解できたのに、という思いが本書の出発点です。
プログラミング言語は普通にわかるけれど、Webアプリケーションを勉強しようとしたら、HTTPリクエストヘッダだのレスポンスヘッダだのContent-Typeだのよくわからない言葉がでてきて困っている、という(当時の私のような)人に、この本をおすすめします。
なお、本書は、以前より私のWebサイトで公開していた「本当の基礎からのWebアプリケーション入門――Webサーバを作ってみよう」の書籍版となります。
相当の修正、加筆がありますので、Webでタダで読めるなら本なんて買わなくていいやとか言わず、ぜひともお買い上げくださいませ。
シン・ゴジラ、公開2日目7/30にIMAXで観てきました。
Twitterでもはてな界隈でもかなり話題になっていて、なんか書くなら今しかないか、ということで書きますよ。
私は、エヴァも観てるしトップをねらえに至っては特に5話6話なんてだいたいセリフ暗記してるような人間なので、シン・ゴジラも、ああ庵野監督の映画だね、ということでおおむね楽しめましたが、あまり一般受けする映画ではないのではないかなあと思った。なにせ視点のほとんどは現場でなくて会議室ですし、おっさんの顔のアップばかりで、なんというか、暑苦しい。
ただ、私が観てて気になったのはそんなことではなくて。
以下、ネタバレ注意!!
ゴジラには、通常兵器が効いたわけですよ。大型貫通弾MOP IIで背中の外皮に穴を開けて出血させるところまではできていた。もちろん、この攻撃のあと、ゴジラのビーム攻撃で手痛い反撃を食うわけですが、このビーム攻撃にはエネルギー制限があって、そう連続して撃ち続けられるわけではないことは劇中で語られている。だったら、血液凝固剤作戦の序盤で実際にやったように、在来線爆弾とかで連続攻撃を加えてビームを使いきらせた状態でMOPを大量にぶち込んでいたら、何も核を使わなくても殺せたのではないか。いや、それで殺せるかはともかく、あんなの街中に2週間も放置するか?
こういうことが気になってくると、普通なら「まあ娯楽映画だしな」で流せることも気になってしょうがない。血液凝固剤、あんなものを口からホースで流し込んだとして、普通、飲むか? 酔いつぶれた酔っ払いに水を飲ませようったってそううまく飲んでくれるもんじゃない。微量でも喉を通れば殺せるようなものならともかく、製造が間に合わなくてフランス経由で核使用を1日待ってもらったぐらいだから、製造した量の大部分(劇中では70%と言ってたっけ)が飲み込まれなければいけないんだろう。到底可能とは思えないし、だいたい敵は口からビームを吐くのに口元に悠長にクレーン車集合させてどうしようって感じだし(実際ビーム吐かれてたし)、だいたい口を閉じただけで終わりではないか(実際口閉じてたし)。
それにあれ、一貫して「血液凝固剤」と呼ばれてたと思うんだけど、なんで最後は凍るんだよ。
そもそもの話として、ゴジラは何しに東京に来たんだっけ。別に目的はなく迷い込んだだけかもしれないけど、途中で冷却のために海に戻って、それからまた上陸してきたんだから何かしらの目的があるはずだよね。たとえば、原発の核燃料でも食いに来たのなら、うまいこと撒き餌して海に戻ってもらう、という方法も取れたのではないか。そういうことを劇中でだれも言いださないのも不思議であった(海に戻った理由は気にしたくせに)。
こういうことが気になってくると、なかなか素直に楽しめないものです。
なお、公開2日目7/30 18:00〜の回(109シネマズ名古屋IMAX)では、上映後、特に拍手は上がりませんでした。エヴァ破の時には拍手があった*1から別に名古屋人がノリが悪いというわけではないと思いますが。
さて、最近のブログ記事では、何かしらかこつけて拙著「Webサーバを作りながら学ぶ 基礎からのWebアプリケーション開発入門」の宣伝をしてきたのですが、今回ばかりはかこつけるネタも見当たらないけど宣伝はするよ!
よろしくお願いいたします。
*1:Qの時は困惑したようなどよめきだけであった。
常に話題には乗り遅れる私ですが、ちょっと前、「変数を箱にたとえる」ことについて議論がありました。
プログラミングの変数を教えるときの「箱の説明」の是非について。 - Togetter
実のところこの話題は昔から何度も出てきた話で、「何周目だ」という話ではあります。私自身、「センス・オブ・プログラミング!」に書いたことがあります。
変数は「箱」か? - the code to rock
そして、上記の「the code to rock」の文章にもありますが、「箱モデル」の代わりとしてよく提唱されるのが「名札モデル」です。
こういうことは文章で書いてもわかりにくいので、それぞれ、絵にしてみましょうか。
■「a = 5;」という代入
「aという名前が付いた箱に、5という値を格納する」プログラミング言語の入門書によく出てくる説明ですね。
■それに続いて、「b = a;」という代入
ここで、以下のような、「aの箱から値を取り出してbの箱に入れる」というイメージをしてしまうと、
「この代入のあと、aの箱は空っぽになってしまうのでは?」という疑問が出るかもしれません。これが箱モデルの(欠点といえば)欠点です。
しかし、それ以前の話として、「5が代入されたaという変数は、5という値が書けるところなら基本どこにでも書け*1、5と同じ意味を持つ」、という原則からすれば、「b = a;」という代入は、結局「b = 5;」と変わりません。
こう考えれば、そう難しい話でもないのではないでしょうか。
さて、名札モデルです。名札というと、小学生が胸につけてるアレのイメージでしょうか。だとすると絵にするとこうでしょうか。
しかし、名札モデルの人のイメージでは、どうも名札モデルが重要なのは参照型の場合であるようなので、
■「a = 5;」という代入
「5というオブジェクトに、aという名札を付ける」と言えばよいでしょうか。
■それに続いて、「b = a;」という代入
「aという名札の先にあるオブジェクトに、bの名札を付ける」でしょうか。
しかし、先ほどの「5が代入されたaという変数は、5という値が書けるところなら基本どこにでも書け、5と同じ意味を持つ」という原則からすれば、「b = a;」は「b = 5;」と等しいので、以下のようにならないでしょうか。
いやそんなの前者に決まってるだろう何因縁つけてんだ、と思う人は、それに続いて、「c = 5;」という代入を行った際には、こちらをイメージするのでしょうか。
それともこちらでしょうか。
実のところこんなことは、クラスみたいな参照型を使うときには疑問の余地なく決まることです。Pointクラスがあったとして、「p1 = p2;」なら、p1とp2は同じオブジェクトを指しますし、「p1 = new Point(10, 20); p2 = new Point(10, 20);」なら、(たとえ座標が同じでも)違うオブジェクトを指します。
しかし、プログラミング言語の入門で、最初に例に出すのは、intみたいな基本型でしょ? 違いますか?
まず、少なくともJavaなら、intはプリミティブであり、参照型ではないので、箱モデルの方が直接的でしょう。
Rubyなら……「Rubyはあらゆるものがオブジェクトだ!」という声が聞こえてきそうですが、Fixnumの実装云々を持ち出すまでもなく、FixnumもBignumもimmutableなので、実質、値型と同様に使えます。
と教えるよりは、最初は「箱モデル」で教えるほうがなんぼか無難ではないでしょうか(別に断言はしませんが)。
この手の「変数は箱か名札か」的な話は、変数の挙動について「既にわかっている人達」が、「どっちが自然か」ということでケンケンゴウゴウするもので、実際にその議論が初心者のためになっているかというと、全然なっていない気がするんですよ。
経験的に、ですが、たとえば私と一緒に会社の新人研修を受けた人達(のうち本当の初心者)の中で、「変数」がわからなくて数日レベルで悩んでいる人はいませんでした。たぶん最初の説明は「箱モデル」で受けたと思うのですが、それでそこが突破できるなら別にそれでいい。それに、実のところ初心者にとって「あらゆるものがオブジェクトだ!」みたいな「統一性」は、言語を学ぶ際にはそれほど大きな助けにならない。あまりにもばらばらなのは考えものですが、整数型なんてのは、最初は値として考えておいて、「あらゆるものがオブジェクト」言語なら、後から「ああこれもオブジェクトなんだ」と理解(感動?)しても特に問題にならないと思います。ていうか、たいていの人は、この順序で理解したんじゃないかなあ。
そして、学習を進めるうちには、「変数は、スタックとかstaticとか、あるいはオブジェクトのメンバとして保持され、オブジェクトそのものはヒープに確保される」「オブジェクトを指し示す値が参照である」「参照値は、(実装により間接参照になってたりするかもしれないが)まあ要するにアドレスのことだ」ぐらいには、物理的な実装に近いところまで理解できるでしょうし、その知識は無駄にはならないでしょう(メンタルモデルとして有用ですし、パフォーマンス等を考えるならなおのこと)。
「センス・オブ・プログラミング」に以下のように書いたのは、そういう意味です。
しかし――変数が「箱」であるのか「メモ用紙」であるのか、そんなくだらない話を真剣に議論してもしょうがないでしょう。たとえ話は所詮たとえ話です。「変数」が実際にどのようなものかを知りたければ、結局、「メモリ」の話を抜きにすることはできないと思います。
というわけで、プログラミングする上では、ある程度低レベルの概念を知る必要が常にある、という意味で、宣伝につなげますよ。
「変数」を知りたければ結局「メモリ」を知らなければいけないように、WebアプリケーションプログラマならHTTPを知らなければいけません。そこでこの本ですよ。
ApacheのようなWebサーバを、自分で作ることにより、Webアプリケーション開発を真に納得して行うことができるようになります。
もちろん、最初に「箱モデル」で変数を学ぶことが悪いことではないように、最初に、HTTPをわかりもせずフレームワークを使ってWebアプリを作ってみることは悪いことではありません。しかし、いずれにしても、どうせすぐ必要になる知識です。「Webサーバを作るなんてマニアックな!」と思わず、読んでみてくださいませ。
なぜ日本人はオブジェクト指向をなかなか理解できないのか?:新刊ピックアップ|技術評論社
くうだらない、じいつにくうだらない。
てかさ、
オブジェクト指向では,「データ」を「オブジェクト」として扱いますので,「変数」もまた「オブジェクト」と同じものだと言えます(※2)。
これからオブジェクト指向言語を学ぶ方は,ここで紹介した「変数とはオブジェクトのこと」というイメージを胸に,学習に臨んでみてください。
「変数とはオブジェクトのこと」って、はっきり間違いだろうよ。
*1:「3a」と書いたからといって「35」(さんじゅうご)にはならないので、この原則にも説明は必要ですが……
http://qiita.com/kantomi/items/747aef968d37b5ebeced
■ 中間言語方式 Java・.Net
(バイトコードなど)中間言語に変換してから、JavaVMなどがネイティブコードで実行する。
■ インタープリタ言語 PHP/Ruby/JavaScriptなど
1行ずつ、コンパイルしながら実行する。
コンパイラ(コンパイル作業)すら必要ないようにした。
……うへえ。今時こんな文章を読むことになろうとは。
当たり前ですが、JVMを含め、インタプリタはネイティブコードへの変換は行いません*1。
今から文章書くにはもう眠いので、昔、拙著「センス・オブ・プログラミング」に書いた文章を貼っておきます。
センス・オブ・プログラミング p.83の補足『インタープリタは「翻訳」しない』より
『インタープリタは「翻訳」しない』
どうも、入門書によっては、コンパイラとインタープリタについて、以下のような説明をしているものがあるようです。コンパイラは、ソースプログラム全体を一気に機械語に翻訳して、オブジェクトプログラムを作成する。
それに対し、インタープリタは、事前に一括翻訳するのではなく、実行と同時に、1行づつ部分的に機械語に翻訳する。はっきりさせましょう。この説明は、完璧に間違っています。
インタープリタでは、ソース(または中間形式)を、インタープリタというプログラム自身が解釈しながら実行します。インタープリタが、ソースから機械語への変換を行なうことはありません。
最近のJava仮想マシンは、バイトコードを機械語に変換する機能を持っています。しかしこれは「JIT(Just In Time)コンパイラ 」と呼ばれる技術であり、この部分を指してインタープリタとは呼びません。
この間違いは、私が8ビットパソコンのBASICで遊んでいた頃(もう20年近くも前になりますか---遠い目)にはあちこちで見掛けたものですが、さすがに最近は絶滅したものだと思っていました。
しかし、本書の執筆のため、本屋で各種入門書を見てみると、最近の入門書にも、上のような嘘が書かれているものがちょくちょくあるようです。これが驚異のべすとせらあ?――困ったものです。
ここで、「これが驚異のべすとせらあ?」と書いている本は、「プログラムはなぜ動くのか 知っておきたいプログラミングの基礎知識」(矢沢久雄著)です*2。当時、「これが驚異のベストセラー!」というアオリが帯に書かれていたのです……
上記の補足を書いた「センス・オブ・プログラミング」が出版されたのが、2004年ですよもう12年も前ですよ。
だいたいプログラマーなら、インタプリタのひとつやふたつみんな作るものだろうに一度でも作ったらこんな勘違いすぐに解消されるだろうに。
はい宣伝。プログラミング言語の作り方に興味が出てきた方はこちら。
関係ないけど今一番売れてほしいのはこの本なので、これも宣伝しておきます。
Webアプリケーション開発を学ぶのに、「Webサーバを作る」という低レベルなところから攻めていこうという本です。低レベルなところから攻めるという点で、プログラミング言語の動く仕組みとかを考えるのと、関係なくはないですね。
ところで、Qittaにはトラックバックとかは飛ばせないようですが、元記事書いた方には、いったいどの本を読んで、インタプリタが「1行ずつ、コンパイルしながら実行する」という(誤った)知識を得たのか、ぜひ教えていただきたいところです。