Archive for the ‘ Uncategorized ’ Category

Google Form を古いガラケーからも使えるようにする

Google Form 大変便利で重宝しているのだが、古いガラケーからはページが大幅に崩れてしまうという問題があったので、古いガラケーが認識出来ない script 要素と style 要素を全て削り取る Web サービスを作った。

google form に入力してもらうための URL を広める際に、
http://mobile-gform.herokuapp.com/?url=[google form の url]
という URL にすると、古いガラケーからでもフォームを正常に表示、入力できるようになる。
PCやスマートフォンからのアクセスは元URLへ自動的にリダイレクトする。

それだけです。

URLがたいへん長くなるので、 inf.to をご利用ください。

Mac OS X Lion にて、第4種オレオレ証明書を発行する

cd ~/.ssh
/System/Library/OpenSSL/misc/CA.sh -newca
/System/Library/OpenSSL/misc/CA.sh -newreq
/System/Library/OpenSSL/misc/CA.sh -sign

-newca で作られた ~/.ssh/demoCA/cacert.pem を安全な経路でクライアントマシンにインストール。
Macの場合は「開く」でキーチェーンアクセスに取り込まれればOK. Winの場合はインターネットオプション>コンテンツ>証明書>証明書>インポート で、立ち上がるウィザード上で、「信頼されたルート証明機関」へインストール。
-newreq の common name 以外の質問はすべてデフォルトで良い。
最終的に newcert.pem と newkey.pem という2つのファイルが出来るので、それを http サーバに設定する。
ちなみに、stunnelで使う場合はこの2ファイルを繋げたファイルが必要となる。具体的には以下のようにする。

cat newcert.pem >> stunnel.pem
echo >> stunnel.pem
cat newkey.pem >> stunnel.pem
chmod 400 stunnel.pem

(finkでstunnelを入れた場合) sudo /sw/bin/stunnel3 -f -d 443 -r 127.0.0.1:80 -p ~/.ssh/stunnel.pem

一度自分で自由になるCAを立ち上げてその証明書をインストールしておけば、別のサーバでサーバ証明書が必要になったときに再びCAを立ち上げる必要は無い。っていうか Common Name だけを該当ホスト名にして手元で証明書を作成してサインし、それをサーバに転送して apache なり stunnel なりに読ませればOK.

リファクタリングの必要性を数値で訴えるには

コーディングを進める上で、以下のような指標を考える。

  • コードを書き足す時、ぎりぎりの時間で実装すると増えるが、充分に時間が与えられれば増えない。
  • 仕様の変更があると増える。
  • 仕様が確定しない状態で開発を進めると増える。
  • リファクタリングの工数をとると減る。
  • 開発を始める段階ではゼロで、ゼロより小さくはならない。

直接的なイメージとしては、「削減可能なコード量」である。便宜的に、「冗長量」と呼ぶ事にする。

ビジネス的観点から見た冗長量の意味は以下のようになる。

  • 機能を追加する際のコストは、冗長量に比例する。
  • プロダクトの納品時に、冗長量を低く抑える事は必ずしも求められない。
  • 冗長量が多いと、バグの発生率が高まる場合がある。

開発担当者が冗長量を日々の報告に付け加える事で、ビジネス担当者は仕様変更や緊急開発のリスク、リファクタリング工数のベネフィットを定量的に考える事が出来る。

緊急開発と呼んだのは、たとえばこんなシーンだ。

上司「ねえ君、大至急この機能Aを実装してくれないか」
開発「とりあえず動くだけなら1日で出来ますが、ちゃんと作ろうと思ったら3日は欲しいですね」

こう答えれば、上司は間違い無く、「動けばいいよ、今日中でよろしく!」と言うだろう。(あなたの上司がここで「じゃあ3日で」と言うのであれば、このコラムを読む必要は無い)

冗長量を考慮して、このように答えたらどうだろう。

開発「動くだけのものは1日で作れますが、冗長量は200上がります。冗長量を100下げるのには1日のリファクタリング時間が必要です」

まあ、こう言っても、上司は「1日で」というかもしれない。
開発担当者は、冗長量が200上がった事を報告書にあげておく。

後日、別の緊急依頼が来た。

上司「ねえ君、この前保留にした機能Bね、必要になったから、よろしく頼むよ。」
開発「3日かかります」
上司「以前、2日で作れると言ったじゃないか」
開発「先日冗長量が上がったので。早めのリファクタリングをしないと非効率ですよ?」
上司「ぐぬぬ。。」

数値は必ずしも客観的である必要はなく、開発担当者の主観で適当な値を報告してもらえば良いだろう。
(ただし、減らすのに必要なリファクタリング時間に比例した量であった方が分かりやすいと思う)

もちろん、冗長量に関するデータは給料の査定に響くようにすべきだ。
どのように評価すべきかは、別途議論の余地があるテーマだが。