homebrewでphpのimap環境を構築
開発環境はMac OS Xでパッケージ管理にはhomebrewを使用した。
homebrewでimapのオプションを利用するには先にimapも入れておく必要があるらしい。
brew install php55 --with-imap
でOKだった。
勝手にSSLのサポートもONになっていた。
ただ、imap-uwを先に入れなければならないということが最初は分からず、自分でimap.tar.Zをソースからコンパイルしたものを使おうとしたり、だいぶ骨を折ったが、brewだけでできることが分かった。
分かるまでは試行錯誤の末、最終的にはbrewのFormulaの中身を覗いて、imap-uwを利用していることに気づいた。
Formulaの中身は下記の場所にあった。
/usr/local/Library/Formula/abstract-php.rb
最初はMAMPで環境を作ろうと思ったが、IMAPのSSLサポートがなくて、phpを再コンパイルしようかと思ったが、homebrewを導入してよかったと思う。
portやyumのパッケージ管理ツールの裏側の仕組みは正直よく分かっておらず、ツールが何をやっているのかよくわからないまま利用していた。
brewはどこにソースがダウンロードされていて、コンパイルされたものはどこに展開され、また、Formulaはどこに配置されているかなどがよく解った。
IMapで詰まったのが、brewの仕組みを調べるきっかけとなり、かえって良かったと思う。
Ruby On Rails系統のフレームワークの選定
フレームワーク選定するにあたって、軽量フレームワークで、素早い開発ができるかどうかが、今のトレンドのように思える。
一般論とは言えないかもしれないが、プロジェクトがうまくいくカギは２つあるように思える。
１つは要件が確定していること。一括請負で一括納入することが前提だが、プロジェクトの期間の中盤を超えている状態で、要件が1割すら確定していない状態でプロジェクトの成功に希望を持てるだろうか？
もう１つは、実装コードが軽量で、ＤＲＹな状態が保たれており、素早い開発がおこなえること。非常に重くて、カスタマイズの手の施しようのないソースを抱えていて、プロジェクト終盤の混乱の中で発生する仕様変更や、品質問題に耐えうる自信をプログラマは持てるだろうか？
この両輪を揃わないと、プロジェクトの収束は難しい様に思われる。
そこで収束の為の1輪として期待されるのが軽量なフレームワークであること。代表的なものに規約により従来よりもコード量を削減することができるRuby on Railsがある。
ＰＨＰならＣａｋｅフレームワークがあり、ＪａｖａならＳＡＳｔｒｕｔｓや、Ｐｌａｙフレームワークがある。
正直どれでもいい。プロジェクトを完遂するためのコントロールを握ることができるなら。
フレームワークの選定はだいたいが、いつも政治活動になる。みんなやりたいものが違う。フレームワークなんて使いたくないという人もいる。トップダウンで決められてしまう場合もあるし、既に決まっていて、開発も始まっている状態が多い。
すでに決まったフレームワークをひっくり返すのは、難問だ。でも、やらなければいけないときはあると感じている。
必要なのは「本当に今のフレームワークである必要があるのですか？」という前提を疑う問いを起すことと、「今のフレームワークを最後まで使い続けるのと、それをやめて新しいやつで1からやりなおすのと、どっちが早い？」という問いに明確に答えることが出来ること。
どっちが早いかという問いに答える為の材料が必要だ。チェックポイントを検討してみよう。なお、プロジェクト完遂のための両輪のうちの1つは整ったことにして、ここではその事には言及しない。
例えば、政治的な理由からＣａｋeＰＨＰが一番、異論が少なく、協力者も得られそうだとして、それを候補にあげるとする。
チェックポイントとして次のような点があげられる。こっからは技術の話。
１、フレームワークは軽いか？コードを書くときに少ないコードで書けるか？学習コストは低いか？
２、フレームワークに変な癖がないか？
３、画面回りの作りこみは楽か？テンプレートエンジンなどは利用できるか？
４、データベース周りの実装はややこしくないか？ＳＱＬクエリ自由に書くことができるか？
５、スキャフォールドでどこまでできるか、むしろ、どこまではできないか？
６、ライブラリは使えるものが多いか？
７、技術的な資料や情報は多くあるか？日本語で情報があるか？
８、周りで、既にプロジェクトに使っている事例があるか、できればソースコードが共同所有されているか
このあたりで引っかかるところがなければ、混乱の中でコントロールを握りやすい。
「本当に今のフレームワークである必要があるのですか？」という問いの答えを相手の頭の中に考えさせることさえができたら、後は「どっちでやった方が早いか」という問いに明確に答えるだけで、すべて成る。
それと「そのフレームワークを使ったら納期に本当に間に合うのか？」という問いには答えてはいけない。たとえ「はい」といえば、本当にフレームワークを変えることができるとしても。
AmazonWebServiceのEC2を利用する上での費用
ＡＷＳを提案に入れようとすると費用は顧客にどう説明しようかと思い悩みます。
ＡＷＳの料金表を見ても、細かくてよく分からない。ドル建てになるし、どういうことをすると、どれぐらい掛かるのか？
ある程度、リスクを積んだ上で、プラン別の価格表をつくり提案するしかない。為替変動があったら価格表を改定したりとかする必要がある。
いっそ、ユーザーが直接ＡＷＳと契約して、間に入っていかない方が話が早いんだが、受け入れられるかどうか？
どちらにせよ費用感を持つにはやってみたほうが早い。
たまたま、今の仕事でＡＷＳにデモサイトを構築してほしいという依頼がありましたので、手を挙げてやりましたとも。
ＥＣ２＋ＲＤＳを利用した構成が理想なのですが、とりあえずＥＣ２の１インスタンスのみでＷｅｂサーバー、ＤＢサーバーをすべてを兼ねるという構成となります。
仮想ＯＳはＡｍａｚｏｎＬｉｎｕｘを使いました。
となるとたくさんの料金メニューがならんだ価格表から見るべき個所は限られてきます。
いろいろ、はしょってしまうと。
いくつかプランがあって、t1.microというのが一番安いのですが、メモリが６００ＭＢ相当しかありまん。あるオープンソースを入れたのですが、ＭｙＳＱＬサーバーが落ちて起動しなくなってしました。
これはキャッシュを割り当てを１ＧＢに設定することで、ある程度持つのですが、オープンソースが重すぎたため、やむなくプランを１つ高いm1.smallに上げることになります。これはメモリは１．７ＧＢ相当です。
普通ならデモサイト程度ならt1.microで十分のハズだと思います。
では計算してみましょう。
（単価）ＡｍａｚｏｎＬｉｎｕｘの場合 アジアパシフィック価格
t1.micro $0.027/1h
m1.small $0.088/1h
１日２４時間起動しぱなっしで、１か月放っておいたとすると、
t1.micro $0.027 × 24h × 30日 × １米ドル １００円 ≒ ２０００円
m1.small $0.088 × 24h × 30日 × １米ドル １００円 ≒ ６０００円
机上で計算すると上記が目安となるのですが、実際は違うと思う。
お客様に費用感を説明できるようになるには、実際にやってみるしかない。
ＡＷＳでビジネスをしたい人は、さっさとＡＷＳをサインアップして使ってみるべきだ。１年間の無料利用枠なんて正直いらない。でもお客さんには１年間の無料枠でどこまでできるか説明できなくてはならない。
なお、デモサイトぐらいにしか使えないが、必要な時だけ起動すれば安く上げることもできます。ただし、ＩＰアドレスが、つまりＵＲＬが起動するたび変わってしまいます。
ＵＲＬが毎回変わるのが困る場合はＥｌａｓｔｉｃＩＰという、固定ＩＰを割り当てる別のオプションサービスがあり、オプション費用がかかります。
１割り当てはまでは無料かと思ったら適用条件があり必ずしもそうでない。
これもお客様に説明できるようにならないといけない。
他にもリザーブドプランなどお得なプランがあるようです。
これもお客様に説明できるようにならないといけない。
あれ、なんか敷居高いな。
複雑な携帯電話の料金プランを頭にたたきこまなければならない、携帯電話の販売代理店の販売員の気分だ。
要するに自分自身がユーザーになってサービスを体験した上で、お客様にとって一番お得なの方法をわかりやすく提案できる能力が求められている。
辛。
参考：Amazon EC2 料金表 | アマゾン ウェブ サービス（AWS 日本語）
「納品のない受託開発」を語る会 - DevLOVE関西 | Doorkeeper
11/15に「納品のない受託開発」を語る会のキャンセル待ちに登録していたところ、当日の開始1時間前ぐらいになってやっとキャンセル待ちの順番が来たので、タクシーで十三へ走った。
おもしろいと思ったことは３つあって、１つ目は「アウトバウンドの営業をやっていない」ということ。ソニックガーデンの主なクライアントはホームページやブログを見てやってくる人が大半の様で、問い合わせが来た時点で既に、ソニックガーデン流の仕事の進め方に理解を持ってくれている可能性が高い。
なるほど、自分でもホームページを拝見する。メッセージが練られていて、ビジネスモデルも面白い。「開発会社、フリーランスの方へ」というリンクがあるが、問い合わせをしてみる前に、Ｗｅｂで発信されている情報をよく理解しておこうという気になってしまう。
倉貫さん曰く、営業する人がいなかったから苦肉の策でこうなったということでしたが、営業に時間を割けないフリーランスのプログラマは等しくマネするべきだと思った。
さて、自分はホームページを開設して語るほどの立派なビジネスプランやメッセージはない。とりあえず、ブログから始めてみようと、早速はてなブログを開設することにした。すぐにマネはできなくても、1日1記事、日記のように書き続ければ、なにかきっかけをつかめるハズだ。
面白いと思ったことの2つ目は、コードレビューの基準はＤＲＹコードかどうかをみるということ。これには「やっぱりそうなんだ！！」という衝撃を受けた。
プログラマとしてやってきて10年、自分はずっとこのことを突き詰めて考えてきたように思える。どれだけ重複ないコードを書くかという命題と、あまりソースコードの綺麗さにこだわり過ぎずにどれだけ早くコードを完成して納品できるかという命題同士のせめぎ合いでずっと悩んできた。
どちらかというとスピード重視で、綺麗にコードを書き過ぎることにこだわらないようにしていた。自分が表現可能な綺麗なコードから、あえて一歩完成させないように自戒もしていたぐらいだ。
直近では、オープンソースのカスタマイズ案件にかかわり、どうにもリファクタリングしようのないスパゲッティコードを料理していて、完全にＤＲＹでないコードに毒されていたようだ。
どうやらＤＲＹであるかないかで悩むことを忘れてしまっていたようだ。ＤＲＹなコードを書きあげることが正解だとは思わない、そこは本当にＤＲＹなコードをに直す必要があるのか？と考えつづけることが今の事態を収拾するカギになるはずだ。
最後の3つ目は「本当に○○する必要があるのですか？」と考えている事です。クライアントが一括納品をすることを望んでいたとする、そういう時は「本当に一括納品する必要があるのですか？」と考えるらしい、前提を疑うことは大切だと思う。
納期だけが決まっていて、やらなければいけない要件がなんとなく、ぼんやり決まっている、いや決まっていない。そんな状態で始まっている案件があり、要件の優先順位とかはなく、全部やらなきゃいけなくて、でも納期は絶対という契約。
どこまでやらなければいけないかを相談しにいくと、どうすれば納期を守れるか考えようと返される。
前提を疑う余地なんて挟めそうにない状況。挟めば弱音を吐いているとレッテルを張られ、モチベーションを疑われかねない。そんな状況で「本当に一括納品する必要があるのですか？」なんで、口を挟めるか？いや、挟めない。よくある話。一般論です。
さて、この前提を疑うということは、人生を変えるぐらい大切なことだと思う。それは弱音や逃げじゃない。現状を突破するために、考え抜く前向きな姿勢だと思う。思考停止して埋もれていくプログラマは少なくないはず。本当に後ろ向きになって消えていくプログラマも少なくないだろうけど。
ソニックガーデンの「納品のない受託開発」のビジネスモデルにはとても興味がある。今の案件を乗り切ったらぜひ詳しいお話を聞きに行ってみたい。
あと4つ目、もう一つあった。会食が終わった後、倉貫さんと名刺交換をした際に伺ったことによると、ソニックガーデンではプログラマ35歳定年説の年ぐらいになったら、独立を進めているらしい。ソニックガーデンの平均年齢は30歳ぐらい。
自分も来年で３５歳。三十にして立つ、四十にして惑わず。迷い多く、立ってもおらず。時間が惜しい。残業をするのはカッコ悪いという文化は、文化ではなく必然となってくる。
