| @Mac/iPhone

なんか一個前の記事でTextMateマンセーみたいな記事を書いてますけど、Coda悪くはないです。というか素晴らしいです。

特に良いと思うのが、FTPクライアント機能を内蔵してるところ。普通のFTPクライアントでちまちまファイルを上げる作業は結構面倒くさいです。特にサーバーのタイムゾーンの設定がローカルのタイムゾーンと異なってたりすると、FTPクライアント上で表示される最終更新時刻が全然あてにならなくてどのファイルをアップロードすればよいのか分からなくなります。こういうとき、Codaでファイルを編集していると非常に幸せになれます。

Codaには「サイト」という機能があって、ここにFTPの情報を登録しておくとグラフィカルな感じで一覧表示してくれて、非常にシャレオツです。

1120_Coda_1.png

例えばいまサイトからportal shit!を開いたとします。するとこんな感じになる。

1120_Coda_2.png

www.portalshit.net にFTP接続しています。サイドバーに「ローカル」と「リモート」とあるのが分かるかと思います。「ローカル」を選ぶとローカルのファイルを編集でき、「リモート」を選ぶとリモートのファイルを直接編集できます。

1120_Coda_3.png

ローカルの index.php を適当に編集してみましょう。

1120_Coda_4.png

するとこんな感じで編集中のファイルには印がつく。でもまぁこんなのはよくある機能です。Codaが便利なのはここからで、ここでローカルのファイルを保存するとファイル名の横に矢印がつきます。

1120_Coda_5.png

index.php の横に矢印がついています。この矢印をクリックするとローカルで編集したファイルをリモートにアップロードしてくれるのです。これが便利。どのファイルがローカルで更新済みでどのファイルをリモートにアップロードすべきかが一目瞭然です。

加えて、「削除」「すべてを公開」なんてのが index.php の下部にありますが、こいつもすこぶる便利なんです。例えば index.php の他に複数のファイルをローカルで更新したとする。全部アップロードしなければならないのですが、ディレクトリを複数またいでいると面倒くさかったりする。しかしCodaの「すべてを公開」という機能は、矢印付きのファイルをアップロードしてくれるのです(「削除」を押すとすべての「矢印」を削除します)。非常に賢いですね。

こんなに便利なのになぜRails書くときはTextMateを使うのか。Bundles機能が便利だとかいろいろ理由はあるんですけど、このFTPクライアント機能はRails向きじゃないんですよね。Ruby on RailsはWEBrickという開発サーバーをローカルで起動してそこを見ながら開発していくので、HTMLなどの静的ファイルをぽんぽんサーバーにアップロードしていくのとは事情が異なる。CakePHPはPHPが動くなら素のApacheでテストできるので(Passengerとかいらない)、Codaで作業しながらぽんぽんアップロードしていっても問題ないわけです。だからCodaがベストマッチだった。BakeするときくらいしかTerminal.appは使わないし。

まとめると、Codaは非常に素晴らしいテキストエディターだとは思いますが、HTMLのマークアップやJavaScript、PHPなどのプログラミングには向いているものの、ハードにごりごりプログラムを書く用途には現状あんまり向いていないと感じます。もうちょいプログラマー向けに進化したら(Terminal機能を内蔵するのではなく、Terminal.appとの連携やフレームワーク特有のコマンドのサポートなど)、とても良いのではないかと思います。

しかしHTMLやCSS書くのがメインで、ときどきPHPも触るみたいな方には打って付けのエディターだと思います。$99の価値はあると個人的には感じます。

| @Mac/iPhone

CakePHPとかRailsでサイトを作るときはModel View Controllerを頻繁に行ったり来たりします。Vimは確かに素晴らしいのですが、複数のファイルを一括で開いてあちこち編集するのはさすがに苦行に近いものがあります。CodaとかTextMateはサイドにDrawerがあってファイルをブラウズしながらタブでじゃんじゃんファイルを開いていけるのでかなり便利です。Codaの例ですが、こんな感じ。

1119_coda_1.png

CakePHPでなんか作ってるときはCoda一辺倒でした。とにかく使いやすい。タブ機能だけじゃなく、ファイルを「分割ウィンドウで開く」という機能があって、例えばModelを左に、Controllerを真ん中に、Viewを右に開いて各々を突き合わせながらコードを書くことができます。

1119_coda_3.png

この機能は重宝しました。こんな感じ。

1119_coda_2.png

RailsもCodaで書こうかと思ったんだけど、弱点がある。それはRuby on Railsのシンタックスに弱いことです。まったく対応してない訳じゃないけど、.html.erb形式のファイルの色分けがいけてない。メソッドの補完とかは結構やってくれるんだけど、それよか他にやることあるんじゃね? って感じですね。

結局、RailsはTextMateで書くことにしました。

TextMateのなんとも素晴らしいところはBundles機能。これすごいですね。いま開いてるファイルのViewやModelにBundlesメニューから一発で飛んでけたり。

あとTermina.appとの連携とかKey Bindingsとか。これでマルチバイト文字にネイティブで対応してくれてたら言うことなしなんだけど。

| @読書

Ruby on Railsの生みの親、デイヴィッド・ハイネマイヤー・ハンソンの勤務先37シグナルズの本。CEOのジェイソン・フリードとデイヴィッドの共著です。とても共感しながら読むことが出来ました。個人的に響いた部分を箇条書き。

計画をやめる

  • 計画を予想に言い換える。誰にも未来のことを計画するなんて不可能。
  • 計画はあらかじめ立てるのではなく、やりながら立てる。やっていないと情報が集まってこない。

最適な規模

  • 無意味に拡張しない。規模の拡大はコストも増やす。
  • 働きすぎるのは馬鹿。ヒーローになるな。

自分たちが必要なものをつくる

  • 37シグナルズの Highrise は自分たちが必要性に駆られて作った。

まずつくる

  • アイディアは実行しなかったらアイディアのまま。
  • 金がないとか時間がないとか言い訳にならない。ベストな状態で始められることなんてない。本当に実現したいことだったら金や時間は自分で工面をつけるもの。

金を借りない

  • ウェブサービスとかは特に金が必要ない。
  • 他人の金が入ると感覚がおかしくなるし、長期的な視野を持てない。

なんでもまず自分たちでやる

  • 会社の規模はコンパクトに維持し続けるべき。
  • まずなんでも自分たちでやってみる。できなかったら人を雇う。

スタートアップという意識を捨てる

  • スタートアップには甘えがある。
  • 他人の金で好きなことをやるなんて幻想。
  • 最初から利益の出せる企業を目指すべき。
  • exitのことを考えるとユーザー本意のサービスが作れなくなる。

制約を利用する

  • 優れた作家は制約のもとで創作していた。シェイクスピア、ヘミングウェイ、カーヴァー。
  • 一度にサービスに携わる人間は一人か二人に限定し、機能は絞る。
  • 芯から作り、本質的でない細かい部分は後回しにする。

副産物

  • 企業は自分たちが気づかないうちに副産物を生産している。木工所はおがくずを売った。37signalsはGetting Realという本を副産物として売った。

すぐリリース

  • 不完全な状態でも最低限な条件をクリアしたらすぐにリリース。

会議をやるやつは馬鹿

  • 会議は時間の無駄。やっても7分。
  • 会議には準備が必要だが、十分に準備することは不可能。
  • 1時間の会議に10人が参加したら、10時間の生産性が犠牲になる。会議にそんな価値はない。
  • 会議は新たな会議を生み出すだけなので不毛。

一人で作業する時間をつくる

  • 電話とかメールとかシャットアウトする時間を作らないと生産性は上がらない。
  • せめて一日の前半か後半のどちらかは一人作業モードに設定すべき。
  • 連絡手段は電話やチャットなど即時対応式のもではなくなるべくメールにする。

そこそこの解決策

  • 完璧な解決を求めようとしない。そこそこの手段で済む問題にはそこそこの解決策を。問題があれば後から良くすればいい。

タスクは分割する

  • 長大なタスクリストは気が滅入るだけ。
  • 100のタスクを10ずつに分解すれば心理的に楽になる。

はまったら人に見てもらう

  • 意固地になって無駄に時間を費やすとコストに見合わなくなる。
  • はまったら他の人に冷静な視点でレビューしてもらう。

寝る

  • 睡眠不足は創造性を損なうし、士気が低下する。間違いも犯しやすくなり、他人に不寛容になる。いいことは一つもない。

真似ない

  • コピペコードは理解が伴わないから、いつまで経ってもオリジナル作者にかなわない。

社員が一緒の国に住んでる必要はない(デイヴィッドは入社当初はまだデンマークにいたらしいです)とか他にも面白いところもあるんだけど、英語がしゃべれないとこの辺は僕らには当てはまらないですよね。あと会議を極力しないってのは理想だと思うけど、受託開発というかホームページ制作みたいなお客さんがいる仕事してたら打ち合わせはしないといけないわけで、なかなか難しいでしょう。

でも電話や会議などは確かに生産性を損ねていると思う。電話なんていきなり日常業務に割り込んでくるわけだから。電話は予約制にして欲しい。何日の何時に電話したいのでお願いしますみたいな感じでメールしろや。

雑談の排除とかも大事ですよね。僕はなるべく仕事中は雑談しないようにしてる。だからといって生産性が高いかと問われれば疑問なんだけど。でも雑談とか会議とか打ち合わせとかやって仕事した気になってる人は多いと思う。例えばこの本では人の雇い方のパートで、仕切り屋を雇うなみたいなことが書いてある。仕切り屋は会議好きで、自分の仕事を作り出すために会議を開きたがる。まったく何の価値も生み出さないのに、会議に参加することで会社に貢献しているふりをするわけですね。こういうのは本当に最悪。

37シグナルズの発想は、ピュアに作り手だけで会社を動かそうという風に読めました。広告とか営業とか意味ないというか、頼りにしないという考え方。本当に良いものを作って自分たちのファンになってもらえたらサービスを使ってもらえるようになる。特にウェブサービスとかはそうですよね。広告とかPRとかは金ばかりかかって効果がないということに気づかないと。有名な雑誌や新聞に取材してもらうことも否定していますが、折角ユーザーと直接結びつけるのがウェビサービスを提供する企業のメリットなんだから、そこにいちいち旧メディアや広告屋を介在させる必要はないですよね。またセールスマンを省きサポートも極力エンジニアが行うことで顧客の要望が直に作り手のところに伝わる(とはいえ本書では逆に顧客の要望には応えすぎるなとも書かれてはいます。その辺は買って読んでみてください)。

シンプルに、極力自分たちで会社を動かそうとすることで、大企業が抱えるいろんな問題が回避できるというのがこの本のエッセンスでしょう。Railsはお触り程度のことしかやってないですが、CakePHP(RailsのPHP移植版)越しにそのすさまじさというかすごさは実感しています。こういうすごいフレームワークがあるいまは、本書で掲げられていることは単なる理想や夢物語ではなく十分実行可能なものであると感じます。自分たちだけでなにかをやることが十分に可能。

とにかくなにかつくってみよう、と思わせられる本でした。Ruby on Railsの勉強を本格的に始めてみたいと思います。

| @ブログ

可能な範囲でデータを元に戻しました。記事の過去ログは11月末までのやつのSQLファイルをエクスポートしてたのでそれで対応。コメントの過去ログはXREAのサーバーに中途半端にデータが残ってたのでそれをインポートしました。ここ10ヶ月間くらいのコメントはサルベージできませんでした。MySQLのバックアップもせめて週一くらいでやらないとダメだな。

jQueryのスクリプトがいくつか動かなくなってたのがあってそれもだいたい直したつもりだけど、いっぺん作ったプラモデルがぶっ壊れて最初からやり直しな感じで疲れた。

いまんとこAmazonのISBNプラグインが動かないです。DreamHost、SOAPがインストールされてないらしい。使いたいならPHPをカスタムインストールしろってさ。昨夜、何回か試してみたけど途中でこける。

でも良いですね、DreamHost。SSHでつなぐとさすがにとろい感じはしますが、コマンドラインでMySQLにもアクセスできるし、いろいろ勉強させてもらえそうです。

ただ国内のレンタルサーバーと違ってサーバーのTimezoneがPSTなので、SQL文とかでMySQLの now() 関数とかを使っちゃうと支障が出ます。

一年目は年額27ドルくらいで使えるけど、来年から120ドル弱になっちゃうのがネックかな。容量も転送料も無制限だから、機能を考えたらそれでも十分安いと思いますけどね。

| @技術/プログラミング

結局CakePHPを触ってます。Railsはサーバー側の準備するのが無理っぽかったのであきらめました。CakePHPはPHP 4だろうがPHP 5だろうが、普通にサーバーにPHPがインストールされていれば、とりあえずファイルを落としてきて自分の開発機でBake(あるいは開発)し、ちょこちょこ設定をしてサーバーにアップロードするだけで(DBの準備とかは別に必要だけど)CMSが出来上がるのですごく良いと思いました。MySQLでもSQLiteでもPostgreSQLでも、DBに何を使おうとも記述内容は変わらないところとかすごく良いと思います。

オブジェクト指向の醍醐味みたいのはアホなので僕にはあまり分かりません。CakePHPを始める前に『たのしいRuby』を途中まで読んでたんですけど、僕はそれまでPHPとC言語をほんの少しだけ触っていて、そのとき感じた「なんかこれまで触ってきた言語と全然発想が違うなー」という驚きのようなものは感じられなかったです。ただCakePHPのMVCの考え方はRailsそのまんまみたいなのでRailsを勉強する足がかりにはなるかなと思いました。

最初はCakePHPの公式ガイドみたいのをチラ読みしてたんですけど、こういうのは本で持ってた方が使いやすいので『CakePHP1.2ガイドブック』を買いました。まだChapter 7までしか読んでないんだけど、誤植や記述の間違いが多くて困る。わりと最初の、「とりあえずBakeしてみよう」みたいなところで間違いがあるので、根気強くない人は本に書いてあるとおりにBakeできないことに絶望してCakePHP使わなくなるんじゃないかな。僕は公式フォーラムを読んだので間違いに気づきましたけど。“CakePHP1.2でモデルのアソシエーションの設定がビューに反映されない” フォーラム - CakePHP Users in Japan

CakePHP1.2ガイドブック、悪い本じゃないと思うんだけど、1.3対応版とかでは単純な誤植とか記述場所の間違いとかで読者を混乱させないようにして欲しいです。

| @Mac/iPhone

Ruby on RailsかCakePHPかどちらかをぼちぼち触ることにしたので、MacPortsで一通り環境を整えてました。いつまでもMAMPの世話になるのはやめようと思い、一個一個必要なものをインストールしていきました。Rails自体は簡単に入ったんだけど、MySQLのインストールがうまくいかない。

なんかを参考にインストールを試みたんですけど、ごちゃごちゃエラーが出ます。まず最初は

--->  Computing dependencies for wiresharkError: Unable to execute port: can't read "build.cmd": Failed to locate 'make' in path: '/opt/local/bin:/opt/local/sbin:/bin:/sbin:/usr/bin:/usr/sbin' or at its MacPorts configuration time location, did you move it?

というエラーが出てました。とりあえずこれは #21062 (Snow Leopard, fresh install, can’t install any ports) MacPorts を参考にしてSnow Leopardのインストールディスクに含まれてる “UNIX dev tools” をインストール。しかしまだ解決しない。MySQLだけじゃなくて

$ sudo port update outdated

とかも失敗する。rsyncがうまくいってないのかなと、ルーターの873のポートを開放したりして半日つぶしたんですけど改善せず。

万策尽きたので一回上書きインストールしたMacPorts 1.8.1を消して入れ直してみました。

$ sudo port deactivate active

してから

$ sudo rm -rf /opt/

その後パッケージ版のMacPorts 1.8.1をダウンロードしてインストールしてみたところ、すべてうまくいきました。

MacPortsはLeopardのときに初めてインストールして、Snow LeopardにしてからはSnow Leopard対応版のMacPorts 1.8.1を上書きインストールしてました。これがどうも良くなかったみたい。

OSのアップグレードとかはやっぱクリーンインストールした方が良いのかな。きちゃないファイルの断片とかをごちゃごちゃため込んでそうです。

| @技術/プログラミング

静的サイトをCMSを導入して動的にする、という仕事を担当することになり、Ruby on RailsかCakePHPを使ってみようかな、と思っています。

現在の状況

僕は仕事を探し始めたときからウェブデザイナーっぽいのになりたいなー、と思っていました。でも実際仕事をしてみると、デザインというのはなかなかむずかしい。ネットが好きな素人においそれとできるものではありません。どうも僕はデザインより、コーディングの方が良いみたい。それもただHTML書くんじゃなくて、JavaScriptでサイトに動きをつけたり、PHPでちょっとしたプログラミングをする方が向いてるような気がする。もちろん20代後半でプログラミング始めたところで先は見えてるんですけど、経済学で言うところの比較優位が僕の場合はプログラミングにあるのではないか、と感じるのです。少なくともいま働いてるところでは僕はデザインやるよりプログラミングやってた方が生産性の向上に寄与できそうな感じ。

しかしながら僕が働いてるところは一日コードばっかり書いていられるようなところではないので、業務でプログラミングできる時間は一日1, 2時間くらいしかありません。それで高速に開発ができるという触れ込みのRuby on RailsとCakePHPに注目しました。

現時点での理解

Ruby on Railsはオブジェクト指向のフレームワークで、とにかく短時間で、初心者でも大規模なサイトをつくることができる、ということは分かりました。Model View Controllerとかもおぼろげながらに理解したつもり。HTMLとCSSでコンテンツと見栄えを分離させるみたいな感じのことをプログラミング言語でやろうとしているのがRailsだ、みたいなイメージをもってます。そしてそのRailsに大きな影響を受けて開発されたPHP版のオブジェクト指向フレームワークがCakePHPであるということも分かりました。

当初はRailsを身につけようと思っていたものの、PHPがある程度分かるためにCakePHPの方が素早く学べるかなー、という気もするし、CakePHPはルート権限のないサーバーでもファイルをFTPでアップロードするだけで使える、というのがなんだか良さそうです。

その一方で、PHPはすごくネットでたたかれるし、多くの人がたたくのはそれなりに理由があるはずで、PHPだけやってるとPHPのネガティブな側面がわかりにくい。だからできれば一度ほかの言語を本腰を入れて勉強してPHPを客観視してみたいとも思うのです。

これから先どういう風に飯食っていくか

コーダーとして生きていくのか、プログラマーになるのか、あるいはディレクターを目指すのかで、何をすべきか決まっていく気がします。HTMLコーディングの片手間でちょこちょこサーバーサイドのプログラミングをするんだったらPHPだけで十分な気がするし、本気でプログラマーを目指すんだったらRubyとかPerlにも手を伸ばした方がよさそう。ディレクターを目指すんだったらプログラミングはほどほどに、ディレクションを勉強すべきでしょうね。

病気とかいろいろあったとはいえ、20代半ばの人間としての方向性が固まる時期を無為に過ごしていたことが悔やまれます。RailsかCakeか、悩ましいなー。