そういえばモバイル端末からのアクセスってどんなもんだろう。ログはほとんど見ていなかった……で、ちょっと見てみたら大半のアクセスがロボットとクローラで少し凹む。まあ、世の中というのはそういうものだ、きっと。
WordPressのスマートフォン対応についてはWPtouchというのを使えばいいらしい。スマートフォンというが、設定にはスマートフォンではない携帯端末(ガラケー?)にもなんかできるようなことが書いてある。ただ、試していない。設定項目はいろいろあるが、細かいカスタマイズは若干面倒臭く、ひとまずお試し、動けば良いということで、テーマを変えたぐらい。でまあ動いているっぽい。
ところでモバイル端末からのアクセスは割と残念な状況な気がした(1%ぐらい)。まあ今後は増えるかもしれないが……。あとHonycombタブレットとかでもスマートフォンUIになっちゃうっぽいんだよね。どうしたものかなあ。というかそれはどっちがいいのかなあ。
Made by Hand ―ポンコツDIYで自分を取り戻す (Make: Japan Books)
Makeの編集長、マーク・フラウエンフェルダーによるDIY体験記エッセイ。芝生を家庭菜園にしてみたり、エスプレッソマシンを改造してみたり、にわとり小屋を作ってみたり、発酵食品にチャレンジしてみたり、楽器を作ってみたり、９章からなるエッセイ集。DIYの読み物ってーと、絵図面がバンバンあるようなガイドが多いけど、この本は完全にエッセイ集だ。読んでも何かの参考になりはしないけど、こういう生き方もいいかもな、というのも気分にさせてくれる。
著者は実に様々なことに挑戦しているけれど、なにより語り口が常に楽しげなのがいい。何か自分もこういうことをやってみたい、そんな気分にすらさせられる。にわとりを買ったりなんて、東京の都市部ではありえないわけだけど、それすら楽しそうだ。
だが、同時に強調されるのは、常に失敗と隣り合わせだということだ。著者は楽しげに語るが、失敗は必ずある。やばい瞬間はいつもある。DIYはコストと成果物の質を考えれば見合わない。むしろDIYは、したいからしているという意味合いが強いようにも読める。例えば、
私がアマチュアの冒険に踏み出したとき、DIY仲間からこう忠告された。失敗は必ずするが、それに負けてはいけないと。私はよくわかっていたつもりだったが、自分がやらかす失敗の数については見積もりが甘すぎた。実際、失敗をしないことがない。どんなに簡単で小さなプロジェクトでも、失敗はキノコのように次々と顔を出す。
とか、
ワゴンの製作に午後いっぱいの時間がかかった。その時間を使って原稿を書けば、工場で生産されたピカピカのワゴンか二台や三台は買えただろうが、私はなにも、時間やお金を節約するためにワゴンを自作したわけではない。大切なのはスローダウンすることだ。DIYは、二〇年前にイタリアで始まったスローフードのムーブメントに似ている。計画、道具と材料の選択、作業場所の確保、作り方、資材、そして最終的なDIY作品、これら全てによって味が出る。労力は出費は二の次だ。
とか。
読んでいて、Makeのバックボーンにはこういう文化があったのだと思った。日本のMakeには、こういう文化的背景がかけているのかもしれない。去年、たまたまいい時期にベイエリアに行って本場のMaker Faireを眺めて、雰囲気が違うなと思ったのだ。もちろん根本的に違うというのではなく、スペクトラムの差でしかないのだが、その違いをうまく言語化できなかった。その違いというのが、アメリカのDIY文化なのかも……と思ったりする。ずぶの素人がこういうことに手を染めるというのは、日本では嫌われる気がするし。そういう意味で極めてアメリカンな本だ。
面白いのは、著者があくまでも素人芸の域を出ないでいることだ。というと悪い言い方みたいだが、著者はわざとこの位置にとどまっているのがいい。各エピソードでは、いろんな専門家が顔と口を出す。エスプレッソの専門家は、家庭にあるようなしょぼいマシンではいいエスプレッソは作れないという。著者はちゃんと稿を割いて専門家の言い分を説明する。なぜそうなのか。何が問題なのか。すべてが明らかになったところで、でも著者はその先には行かない。その道の人の目的は完璧なエスプレッソを作ることであって、そのためにはまず例えば高い機械を買うのが必須だ。それはわかった。でも、と著者は一歩引く。やりたいのは、家庭用のエスプレッソを改造して、そこそこいいエスプレッソを作ることだ。専門家の話を聞くことで、なぜ高い機械が家庭用のしょぼい奴よりいいものができるのかがわかったから、そのエッセンスを汲めば家庭用のをうまく改造できるかもしれないし、できたら嬉しい。そういうスタンスが本書では貫かれている。
そういう思想に共感できる人なら、この本はとても楽しく読めると思う。
半年ほど前に少し書いたSKY配列だが、あの時にはしばらくして使うのをやめてしまっていた。が、この5月にSKY++配列の作者とあって話したことで、また少し気分が舞い上がり、SKY配列に再挑戦することにした。で、それから2ヶ月たち、かなりSKY配列に慣れてしまった。今は使っているマシンは基本的にすべてSKY配列を少し改造した独自配列で書いている。
SKY配列とは何か。詳しくは「SKY配列について」のページを参考にして欲しいが、ルールはかなり単純で、左手のキーに子音、右手のキーに母音を割り振る変則ローマ字配列だ。こうした配列の利点はいくつかあるが、基本的に日本語の一文字というのは子音ひとつと母音ひとつで成り立っているわけで、こういう配列にすることで自然と両手の指を交互に打鍵することになり、効率的な入力が可能になるという次第だ。
また、よくある母音の並びである、あい、うう、えい、おう、あん、いん、うん、えん、おん、などが1打鍵で入れられるため、打鍵数を減らせるという利点もある。また、SKY配列はとても単純な配列なので習得が容易であるということもあると思う。
そもそも、日本語を入力するにあたって、別に既存の英語のキーときちんと対応している必然性はないと思う。台湾の注音記号や韓国のハングルなどは、音素の部品が各キーに割り当てられているけれど、同じように左右で母音と子音を切り分けていて交互に打鍵しやすくなっている。それでもいいんじゃないか、と思うんだよね。
—
前回のチャレンジでは、須藤玲司氏のSKY++配列を試してみた。SKY++配列のポイントはシフトキーを使うということにある。jが「あ」を意味するが、Jは「や」のようになる。dがさ行なので、djが「さ」だが、dJなら「しゃ」というわけ。子音の方は「っ」が前置される。Sjが「った」なわけ。
幸いにして(?)、Google日本語入力ではローマ字変換テーブルでこうした大文字に対応できる。設定から「入力補助」タブの「シフトキーでの入力切替」をオフにしておけば、あとはローマ字変換テーブルに大文字を書いておくとちゃんと動作する。ということなので、実地試験も含めてやってみたのだが、どうも違和感がある。やっぱりそれなりに文中に英単語を書くことがあり、そういう時にシフトキーの動作がこれだとやっぱりどうも不自然だと思って、そこで一旦使うのをやめてしまった。
今回、再挑戦するにあたって、このシフト方式に代わる手段はないかと考えた。GOTO方式は中指プレフィクスだが、これには違和感がある(Sの代わりにks、Jのかわりにdjとする方式)。中指はそれなりに利用頻度の高いキーだという気がするので、そこをプレフィクスにしてしまうのはもったいない。どうしたものかなと思っていたのだが、同じようにプレフィクス方式にするにせよ、中指のような便利でよく使うところではなく、小指のキーを割り当てればいいと気づいた。具体的には、右小指の右隣のキー(“、英語配列の場合は’)をプレフィクスにする。’sがSの扱いになる。’jのように母音パターンは右手の連続になるので打ちづらいということで割り当てず、代わりにや行のキーであるgを混ぜてつかう(dgjが「しゃ」になる)。二回打鍵で「っ」が入り、シフトで「ん」になる(このキーはシフトを押しても大文字小文字の変化じゃなく、違う記号になるだけなので、シフトキーでの入力切替の問題とかち合わない)。そうすると、もともとこのキーに割り当てられていたオンビキ(ー)が打てないのだが、これは普通のローマ字テーブルと同様のハイフンを使うことで妥協した。
言葉で書くとややこしいが、小指プレフィクスということなのでそれなりに単純だし、シフトキーだって小指プレフィクスみたいなものだ、と自分を説得して使ってみたところ、案外良い塩梅なので満足した。なかなか使い心地がいいと思う(自分で考えたからというバイアスがかかってそうだけど)。Google日本語入力のローマ字変換テーブルの設定をGoogle Docsにアップロードしておいたので、興味のある人はどうぞ(英語配列用ですが)。
会社の人数名と一緒に先週に見に行ってきたけど、そうして正解だったかも(笑)。
なんか、既視感で構成されている映画だとか、そういう方面の悪評があることは知ってたのだけど、いやいーじゃんこれ。私は楽しめましたよ。
確かに既視感のあるシーンも多いし、話はご都合主義的なツッコミどころも多く、話の筋は読めます。わかります。だが、これはそれでいいのだ。こういう映画なのだ、と思う。なんともB級な怪獣映画を撮りたかったのねえ、という気持ちはよく伝わってくる。第一、みんなでゾンビ映画を作ってて、特殊メイク役で鉄道模型とかに夢中な主人公が、ヒロイン役で出てきた女の子と仲良くなる話が話しの軸ですからね。彼女にゾンビメイクを施して、演技指導をしながらじゃれあうシーンの微笑ましくもボンクラの妄想としか言い用のないところがイイ、そういう映画ではないかと思います。
ときは1979年、スリーマイル島事故がニュースで流れる頃、秘密を隠蔽する軍部、といった設定は今の日本と重なる部分もあり、見ながら「もしやそういう深い展開が……」と一瞬だけ期待しましたがただの気のせいでしたーという感じ。これも「よくある映画の設定」というぐらいの背景情報に過ぎず、1979年という時代が選ばれたのはむしろ監督(J.J.エイブラムス、1966年生まれ)がこの主人公たちと同じ年頃の頃ってだけじゃね、という気がします。
そういうボンクラ映画ですから、友達とみんなで見に行って、ポップコーンでもかじりながら「キター」とか言いつつ見るのが正しい映画であり、その目的には完璧に沿った映画であろうと。なんか大作だと思って見に行くからがっかりするのですね。そういうのではない、全然。
あとエンドクレジットが最高(笑)。この映画を見に行ってエンドクレジットを見ずに帰るのは全く損をしてますよ! マスト見るべし。むしろそこが本編。
ふとなんとなく足してみた。だんだん派手めになっていく……。
この手のサービスは、まあいいんだけど、どのみちここのような辺境の地ではたいした影響はないだろうと思う。ほぼすべてのページはどうせゼロだし、こういうボタンに強い影響があるとも思えない。が、あろうがなかろうが影響がないなら、置いといてもさしたる問題はないのかもしれない。まあ、気が向いたら押してやってください。
そういえば、2ヶ月ほど前にほぼ単純な好奇心でアドセンスも導入してみたのだが、その後、月あたりの収入は、まあいいとこ数百円といったところのようだ(それでも事前に思っていたよりは収入がある)。もう少し色々頑張れば効率化はできるだろうと思うが、そこはあまりがんばらないでいこう、と今のところは考えている。ちなみに、amazonのアフィリエイトも収入源としては似たような感じ。
だからどうだというのではないけれど、特に有名でもない普通の人のブログというのは、まあその程度なわけだ。
ただまあ、アドセンスやアフィリエイトというのは、半分はそれ自体が娯楽なのではないかと思うことがある。クリックのデータなんかを眺めると、なんとなく傾向がわかるようでわからない(データがスパース過ぎて人間にもよくわからない)。その絶妙な所をあれこれ眺めるのは、なんとなく楽しいものだ。+1ボタンとかにも、そういう面白さがあるだろうか。
うちの近所の本屋では、どうも好きな書店員がいるようでずーっと本屋のどこかしらに置かれていて、それなりにじわじわ売れていたというポップがあったりする、一部に大人気の『がらくたストリート』が2年半ぶりぐらいに続刊が出た。待ちぼうけるというより、どこかで作者が書くのをやめちゃって打ち切りとかだったんじゃないかと思ってた。
この漫画は抜群に面白いと思うけど、その面白さをどう伝えたらいいか……。とある山間の田舎の、子供たちと少年少女と、宇宙人と時々神様の日常。そんな感じ。淡々とした日常、時に非日常みたいな、ダラっとした生活を描くという意味では、昨今よくある日常系な漫画という括りになるかもしれないけれど、そんな括りからは逸脱するような不思議さがある。日常と非日常の境目がひどく曖昧で、区別されないファンタスティックな面もあって、そんで時にオタクネタやうんちくが混ざってたりして(今回だと「1話に金田いるらしいぞ」ってのに「かなだ」というルビがふられるとかそういうね……)、話が進んでいるんだかそうでないんだか、進めるような話がそもそもないようであるようで、いかにも不思議でワンアンドオンリーなのかもしれない。
そんななんだかよくわからないような漫画が面白いのかというと、これが面白い。
この漫画の面白さは「語り口」だと思う。この漫画は語り口が抜群だ。語り口というのは、話の持って行き方とか、掛け合いの面白さといったもので、ヒトコマをバーンと貼ってわかるような面白さとは違う。だから説明はしづらいけれど、読めばわかる。2巻冒頭の、海に行くのに駐車場に集合してうだうだしている所がすでにいい、と私なんかは思ってしまう。
おすすめです。
git commitにある–amendというフラグをご存知だろうか。
gitでは、commitは手元のレポジトリに保存される。多人数で開発するときの中央レポジトリに反映させるには、commitしたものをpushする必要がある。……で、大抵の多人数で開発するプロジェクトの場合、commitした変更を(gerritとかの手段によって)レビューしたりしつつ、すべてが整ってから、pushするというのが一般的な流れかと思う。
だけど人間というのはうかつなことをするものだから、commitした直後に下らない間違いを犯しがちなわけだ。例えば、編集したのにChangeLogを追加してないとか。ファイル足したのにビルドファイルの変更を加え忘れたとか。そういうやつ。そういうしょうもない変更でコミットを汚したくない時のために–amendがある。–amendすると、新しいコミットを作る代わりに最新版のコミットを更新する。
実は、Darcsにもamend-recordというそのための専用コマンドがある(普通のcommitに当たるコマンドはrecordという名前になっている)。これはつまり、こういううかつなコミットはよくあって避けづらいということだ。だが、Mercurialには、この種の操作のための便利なコマンドがない。
もちろん、同じ事もできるといえばできる。hg rollbackというコマンドを実行すると最新のコミットを消してしまう。で、その後にhg commitし直せばいい(Gitユーザ向けのMercurialガイドにもそのまんま載っている)。そういうextensionを書くという手も残されていて、もちろんmqを使うという手もなくはない。
だが、なんで–amendがないんだろうね、というのを、ここではうだうだ考えたい。
すぐ思いつくのは、「非推奨の操作は面倒くさくする」の原理だ。普段良く使ってほしいオペレーションは簡単にできるようにし、あんまり使って欲しくないやつはよくわからない複雑なオペレーションにする。ちゃんとわかってない人には使わせないようにするというわけだ(この観点からすると、git reset –hardとかは最低ではないかとおもう……)。Mercurialはわりとこの原則を採用していて、hg helpでは出てこないような特殊なコマンドが実は山ほどあり、詳しい人だけが内部的なデータをうかがい知ることができるようになっている。つまり、–amendは「やればできるけど積極的にはサポートしたくない」という開発者の意思が介在していると見るべきだ。
そもそもバージョン管理システムにおいて、変更履歴というのは不変であり、勝手に消したりするべきではない。バージョンの管理というのはそういうことだ。また、am
