Document Actions
WordPress検証中
検証中と言っても、今日(ほぼ)はじめて1時間ほど触っただけですが。
やりたい事はおおよそできそうな感じです。
くやしいですがWordPressは良くできていると感じました。ブログシステム/CMSとして本当に小さな機能セットだけ提供しています。思っていたよりずっと単機能です。ぼくがブログシステム/CMSに求めるのは単純な機能だけなので問題ありません。むしろソフトに余計なことをされる方が嫌です。シンプルで内部が隠蔽されていないソフトが好みです。
WordPressには偏見がありました。メジャーなソフトなので、もっとエンドユーザに媚びた着飾ったソフトだと思っていました。こういう偏見を持っていたので素直に感嘆しました。なぜならソフトウェアがシンプルであり続けるのは本当に難しいからです。特に商用ソフトだと、あまりに機能が少ないと、買ってくれた人に申し訳ない気持ちになるので、これも機能肥大のひとつの要因になります。
WordPressはよほど強い信念で機能要望を蹴っているのでしょうか。それとも、開発者がこれ以上PHPのコードを書きたくない、が理由だったら面白いですが。去年(http://dev.ariel-networks.com/Members/inoue/lisp-generation/view)、今後は新しい世代に開発言語の選択を任せるつもりだと書きました。この信念は変わっていません。好きな開発言語を使うのが良いと思うからです。逆説的ですが、機能肥大を止めるには開発者が嫌いな言語で開発するのもありなのかもしれません。最初からそうすると開発そのものが進まないので、途中で開発メンバーを入れ替えて、開発言語を嫌いな人たちにスイッチするのがいいかもしれません。
- Category(s)
- カテゴリなし
さよならPlone
ありえるえりあのシステムをPloneからWordPressに移行します。RSSのURLは変わるので、アナウンスも兼ねて書いておきます。
移行予定は今月末か来月頭です。今までのコンテンツは同じURLでアクセスできるようにします。コンテンツのコンバートはせず、スタティックファイルとしてアクセスできるようにします。
最近、世の中でWordPressの寡占が進んでいる気がして、果たしてありえるえりあが寡占の一端を担っていいのかと自問することもありましたが、ごめんなさい、もう面倒なことは嫌です、世間に流されることにします。
Ploneに移行したのは、2005年12月23日です。
移行当時の印象を書いた記事が次のふたつです。
- http://dev.ariel-networks.com/Members/inoue/plone-impression1
- http://dev.ariel-networks.com/Members/inoue/plone-impression2
5年間Ploneを使いました。使い始めた当初は使い慣れないというだけでソフトウェアを貶めるのは良くないと思い、記事も遠慮がありました。5年間も使ったのだからもう言ってもいいと思います。はっきり言います。Ploneは他人には勧められません。
まず動作が重いです。文書の更新が重いだけならともかく参照も重いです。少しアクセスが集中しただけでCPUが100%近くに張り付きました。
ただ最も他人に勧められないと思う点はユーザビリティです。たとえば下の操作画面で、一覧選択にチェックを入れて、画面右上のアクションメニューから"delete"を選択すると何が起きるでしょう。
一覧の選択とは無関係に、画面で今見ているフォルダ相当のものが消えるのが答えです。
これでも内部アーキテクチャに狂いはありません。RESTの用語を使うと、アクションメニューの操作対象はコレクションリソースです。右上のアクションメニューの操作は一貫して、今画面に現れているリソースへの操作です。動作は合理的で一貫しています。美しいとすら言えます。ぼくがPloneの作り手だったら、何の問題がありますか?、と開き直りそうです。
要はPloneのユーザビリティを考えている人はぼくみたいな人間です。悲しいことにだからダメです。
ユーザビリティには合理性や一貫性よりも慣習が大事なことがあるようです。一覧選択から選択操作をして"delete"を選べば、選択対象の削除を期待するのが人情です。
- Category(s)
- カテゴリなし
Apache2.4のリリース予定は来年(2011年)初め(あくまで予定)
以下のメールによれば
- http://mail-archives.apache.org/mod_mbox/httpd-dev/201012.mbox/<A418DE49-617A-45E2-9F6E-68642611773B@apache.org>
a 2.4.0 GA release around the beginning of 2011
です。GAはGeneral Availabilityで、いわゆる正式リリースです。
2011年初めに出るかは不明ですが、2011年には流石にリリースされると思います。
デフォルトMPMがsimpleになったと思っていたのですが(http://dev.ariel-networks.com/Members/inoue/apache2.4-going)、手元で2.3.10をビルドするとevent、worker、preforkの順でチェックします。最近のGNU/Linuxでビルドするとevent MPMになります。
コミットログを見てみると
Revision 758597 でsimpleがデフォルトになりましたが、Revision 759129 でeventがデフォルトの位置を奪い取りました。
- Category(s)
- カテゴリなし
Herokuの発音
Linuxという名前が日本で知られ始めた時、Linuxの読み方および日本語表記がちょっとした論争になりました。
記憶する限り、当時、リナックス、リヌクス、ライナックスの3派あったと思います。もうひとつ、外国語の発音を完全に日本語表記することは不可能だから日本語表記はすべきでない、というメタな主張をする派もありました。当時Linus自身がLinuxを発声した音声ファイルが出回っていました。これで早々にライナックス派は消えた気がします(Linus自身はLinuxをどう呼んでも構わないと言っていたようで、それがライナックス派の心の拠り所でしたが、Linus自身の発音は誰がどう聞いてもライナックスには聞こえませんでした)。
リナックス派とリヌクス派の対立は、今となってはリナックス派の圧勝のようです。個人的には、リナックスが残った理由は語感がリヌクスより可愛いからだと思っています。本気です。
この業界、読み方の分からない新語が現れます。昔はそういう読み方を本や雑誌のふりがなで知っていました。なので、本のふりがなが間違っているとそのまま間違った読み方を覚えたりました。
しかし、最近はyoutubeなどでネイティブの発音を聞けばいいので、本のふりがなに頼る必要がなくなりました。いい時代になりました。
さて表題のHerokuです。WEB+DB PRESSのある記事で「はおく」とふりがなが振ってありました。Herokuの会社ページ(http://about.heroku.com/)を見ると次のように書いてあります。確かにこれをそのまま日本語に当てはめると「はーおーくー」になりそうです。
Heroku (pronounced her-OH-koo) is a cloud application platform for Ruby – a new way of building and deploying web apps.
先日、salesforce.comの偉い人に会ったら、発音は「ヘロク」だよ、ネイティブの人も「ヘロク」と読んでいたといいます。
気になったのでyoutubeで確認してみました。マーク・ベニオフがHeroku買収を発表したプレゼンがあるのでこれを聞きます。
聞いた結論。2番目の音節にアクセントがあり、Rの音は確実に聞こえるので、後ろのふたつの音節は日本人耳には「ロク」に聞こえます。最初の音節はアクセントがないので「へ」でも「ハ」でもどちらでも大差ありません。そんなわけで「へロク」か「ハロク」と読むのが適切で「ハオク」は外している感じです。
と言っても、個人的にはLinuxをLinuxとしか表記しないように、HerokuもHerokuとしか表記しませんが。
- Category(s)
- カテゴリなし
雑誌記事「ソフトウェア・テストPRESS Vol.9」の原稿公開
雑誌の発売が1年前ですが、「ソフトウェア・テストPRESS Vol.9 (2009年10月)」の原稿を公開しました。
Part1は井上の真面目な話です。Part2は佐藤さんの笑える話です。これ以降、佐藤さんはアリエル雑誌執筆陣のお笑い担当になりました。Part3は花城さんの泣ける話です。雑誌の挿絵イラストも花城さんが描きました。一枚を公開しておきます。
あまりに主観的すぎる記事のため、どうかと思う人もいるかもしれません。技術書の雑誌記事は、もっと汎用性なことが書かれるべきだと思う人もいるかもしれません。そういう人にはごめんなさい。完全なる経験談です。ありがたい話ではありません。
一般論として、ぼくはアーキテクチャ宇宙飛行士の話を聞いたり記事を読むことに肯定的です。現場で何の役に立たなくても発想を広げるという意味で価値があると思うからです。ただ、ソフトウェアテストに関する世の中の記事には宇宙飛行士が多すぎます。現場のテストは地上戦です。地に足のついたテスト戦略が必要です。他の会社のソフトウェアテストに関する具体的な取り組みが表に出てくることを期待して、アリエルの地上戦を書きました。
以下はいくつか参考ページです。
「ソフトウェア・テストPRESS Vol.9」のページ。
雑誌が発売された頃の書き込み。
当時、社内のテストチームに向けた講義資料。
- Category(s)
- カテゴリなし
IPA未踏のニュース
微妙すぎるタイミングで、松山さんのIPA未踏天才プログラマ認定のニュース記事をアリエルのサイトでリリースしました。マーケの米村さんがプレスリリースも出したいと言っていますが、止めた方がいいのでしょうか...
結局、今後のIPA未踏がどうなるのかはまだよく分かりません。以前、IPA未踏廃止かと思われた時がありましたが、IPA未踏の目的は未踏プロジェクトの支援ではなく人材育成だと看板をすげ替えて延命した前科があります。今回も逃げ切るかもしれません。
IPA未踏が税金の無駄遣いかと言われれば否定はしません。しかしIPA未踏程度の無駄遣いはいいだろう、というのが昔からの自分の見解です。IPAの近くに居ついて仕事を請けている会社に流れる金の方がはるかに無駄です。IPA未踏で個人に流れる金なんてかわいいものです。若者に夢と希望を与える名目だけでも充分お釣りがでるレベルです。
去年の大山さんのニュース記事は以下です。
なお3年連続はありません。なぜなら今年はアリエルから誰も応募していないからです。
# タイトルはちょっと釣りです。ごめんなさい。
- Category(s)
- カテゴリなし
労基法とチキンゲーム
「 トップミドルのための採用から退職までの法律知識 」を半年かけてようやく読み通しました。
なお、上記のリンク先は十三訂版で、読んだのは七訂版です。
労務関連の法律は変化する上に解釈の違いも変わるので、本の記載を鵜呑みにするのは危険と本を貸してくれた人が言っていました。そういうものなのでしょう。七訂版を読んでいても、時代の変化で解釈が変わる様が至る所に現れます。
一例ですが「社員の自発的な残業を知りながら放置しておいた場合」という節があります。伝統的解釈をすると、残業の黙認は時間外労働を暗黙に命じたことになるので、会社は残業代を支払う必要があります。しかし、近年のホワイトカラーの働き方にこの解釈が適当かどうかは疑問がある、と本の著者は続けます。そして、ホワイトカラーの労働は(伝統的な)工場労働のように成果が労働時間に比例するものではないだろうと続きます。会社にいる時間をどう使うかの裁量を労働者に相当任せている以上、自発的な残業も本人の自己管理の範囲内だろうと主張します。結果、自発的な残業の放置に残業代は不要と結論づけています。この本の解釈が正解という保証はありませんが、長年、どうなんだろうと感じていた残業の解釈に納得できる解釈を専門家の書いた本で得られたのは収穫です。
そうは言っても法律はやはり窮屈です。通底するのは、曖昧な部分があると労働者は会社から搾取されるもの、という考えです。上記のようにホワイトカラー的な働きを考慮して法律や解釈が変わりつつあるとは言え、原則は、労働者の労務の提供は時間ベースです。時間管理に曖昧さがあると、労働者は時間外労働でただ働きさせられるので明文化して労働者を守ろうとする思想が見え隠れします。ただ、労働者に優しそうで意外に厳しい面もあります。たとえば「遅刻は法的には労働契約の債務不履行」であり「ノーワーク・ノーペイの原則により賃金を払う必要はない」と書いてあります。更に、遅刻や欠勤を有給休暇で振り替えるのは有休休暇の趣旨に反するとあります。マスター浜岸もびっくりの厳しさです。
個人的に本書でもっとも興味深かったのは「タイムレコーダの打刻忘れは欠勤となるか」の節です。
労働者に優しいのか厳しいのかよくわからなくなってくる中でのこの問いかけ、本書での解釈は「欠勤にならない」です。
もしこれを聞いて労基法は労働者の味方だ、万歳と思ったとしたら、残念ながら少し浅はかな反応かもしれません。
タイムレコーダの打刻忘れが欠勤とならない理由は、会社(使用者)には労働者の労働時間の把握義務があるから(労働基準法108条)です。これが意味するのは、もしタイムレコーダの打刻忘れは欠勤ではないと声高に主張する労働者が現れると、会社が次にすることは労働時間をより正確に把握するための努力になります。これは防衛上当然の措置です。裏切りには裏切りをです。ちなみに、法律的には労働時間の把握手段は会社の自由で、正確性と公平性があればシステムに縛りはないようです。使用者と労働者の間の信頼関係があれば柔軟に運営できる、と本書にも書いてあります。
協調していれば双方が幸せなのに、裏切りに裏切りで応えると双方が不幸になる様が囚人のジレンマを思わせます。いやむしろ、双方の裏切りが一番不幸になる点で、チキンゲームの方が近いかもしれません。
- 囚人のジレンマやチキンゲームについては http://dev.ariel-networks.com/blog/inoue.php?blogid=2&archive=2004-7-25
元々、自由な働き方をするための理論補強の意図で本書を読みました。企業と社員が非協力ゲームをしている限りそれは難しい、というのが感想です。
結論は協調には協調で応えるのがいいという実に道徳的な教えです。しかし物事には二面性があります。これ以上は危険トークになるので別のところでやります。
- Category(s)
- カテゴリなし
フロントエンドエンジニア
「フロントエンドエンジニア」の募集を今日からFind Job!に出し始めました。
フロントエンドエンジニアという職種が通じるかなと思い、社内で少しインタビューしてみると、若者には問題なく通じ、おっさんからは怪訝な顔をされました。適切な用語だと確信しました。
応募が芳しくなければ、WebエンジニアやUIエンジニアに職種名を変えるかもしれません。
面接ではHTML5とCSS3について聞くつもりです。
- Category(s)
- カテゴリなし
ASCII.technologies誌にMapReduceの記事を書きました
ASCII.technologies ( アスキードットテクノロジーズ ) 2011年1月号のMapReduceの特集の記事のひとつを書きました。以下のパートです。
MapReduceプログラミングを助ける言語たち Part2： PigとHiveとデータ構造
PigやHiveなどの周辺ツールというお題をもらいましたが、好きに書いてくださいと言われたのでかなり自由に書きました。と言っても、記事の中でHadoopを全否定するほど自由奔放ではないですが。
最近、MapReduceやNoSQL周辺のイベントに行くと、「クラウドやっているんですか」や「井上さん、クラウドの人なんですか」と聞かれます。こう聞かれてしまうとムキになって「なんですか、クラウドの人って」と反論します。「そう、最近、クラウドの人になりました」とさらりと答えるのが大人になることなのか、果たしてそれは成長なのか、自分の中でも答えがでていません。
個人的には、移り変わる表層的なモノより変わらないモノ、普遍的なモノに触れていたいと思っています。しかし、普遍性の名の下で、単なる変化への拒絶になる懸念もあるのが難しい部分です。
- Category(s)
- カテゴリなし
技術評論社パーフェクトシリーズ絶賛発売中
パーフェクトシリーズ第3弾の「パーフェクトPHP」の売れ行きが好調のようです。関係者のみなさんお疲れさまでした。PHPを学んだ後は「パーフェクトJava」でJavaも学んでください。現代プログラマは動的型言語と静的型言語は両方やっておく必要があります。
p.s. ちなみにシャープを#や＃にするとリンクにできないので仕方なく「シャープ」と表記しています。Ploneの自由度の低さは絶望的です。
- Category(s)
- カテゴリなし
雑誌連載「Emacsのトラノマキ」の原稿(part8)公開
今月の「Emacsのトラノマキ」は 深町さん による「YASnippetですべての言語に"マクロ"を」です。マクロ好きな深町さんには、次にm4-modeでも語ってもらいますか。
さて恒例のバックナンバーの原稿公開です。連載第八回「EmacsでChangeSetベースのVCSと仲良くする」(Software Design 2009年12月号)の原稿です。
- Category(s)
- カテゴリなし
RESTの当惑
以前(かなり前ですが)、柴田さんから「 アプレンティスシップパターン 」を献本してもらいました。
先月ようやく読みました。章を忘れましたが「Web系のソフトを開発するならHTTPのRFCぐらい読め(意訳)」とあり、そうだそうだHTTPのRFCを読んでいないような開発者はWebを語る資格はない、と心の中で喝采をあげました。が、すぐその後に「RESTの論文も読んで当然(意訳)」とあり、心の中でまずい前言撤回となりました。
普段、なるべく一次情報に当たろうとは思っていますが、現実的には困難です。「HTTPのRFCを読んでいないような開発者はWebを語る資格はない」と偉そうなことを言いましたが、TCP/IP関係の全RFCを読まないとHTTPについて語る資格なしと言われたら、黙るしかありません。ちなみに、TCP関連だけでも http://www.networksorcery.com/enp/protocol/tcp.htm ぐらいあります。もっとも、このリストが正しいのかすら確証がありません。知らないことは多くあると思う、謙虚な姿勢が重要です。
「 アプレンティスシップパターン 」にRESTの論文ぐらい読めと喧嘩(?)を売られたので読んでみました。以下から読めます。
読んだ感想は、当惑です。
RESTとは何か、については5章の節タイトルと図を眺めるだけで一応分かります。上記リンクのクリックが面倒な人のために節タイトルだけ列挙しておきます。RESTとは何かと聞かれた時の回答にこれらを挙げれば教科書的には正解になります。
5.1.2 Client-Server 5.1.3 Stateless 5.1.4 Cache 5.1.5 Uniform Interface 5.1.6 Layered System 5.1.7 Code-On-Demand
なぜRESTかについては、読んでも腑に落ちません。1章は導入、2章は用語説明なので、なぜRESTかに答える鍵は3章と4章かと思うのですが読んでも理解できません。そもそも3章の比較(以下のリンク先にまとめの表があります)に直交性をまったく感じません。直交性がなくてもいいのか、と自問しつつも全体に腑に落ちません。
ぼくを最も当惑させるのは、この論文を先入観なしに与えられた時に正しく評価できる自信がないことです。RESTが概念として広まっている事実や、著者がApacheの有名人であることや、この論文がHTTP1.1の思想的バックボーンで著者自身がHTTP1.1の主要エディタであること、これらの背景知識がなかったとします。論文を読んだ自分の反応は、おそらく「つまらない。読む価値なし」です。こうなると、普段、自分が先入観なしに他の技術を評価できているのか怪しくなります。たぶんできていないのでしょう。こんな事実を突きつけてくる点で、実に困った論文です。
当惑の話は別にして、論文で興味深かったのが「6.3.4.2 Cookies」です。次のようにクッキー完全否定です。
cookie-based applications on the Web will never be reliable.
一部否定(クッキーに色々と状態を持たせるな)ならともかく、クッキーにセッションIDのような状態を持つことも否定しているように読めます。ここは同意できません。使える仕組みは使えばいいと思います。
- Category(s)
- カテゴリなし