SSHクライアントたくさん並べてペーストしまくるのが許されるのは小学生までだよね と言ってみたかっただけです。こんにちは。 Capistranoでサーバ構築を省力化する方法を紹介します。サーバ構築の自動化といえばChefやPuppetが有名ですが、CapistranoはサーバにSSH接続さえできれば利用できるメリットがあります。データセンタに持ち込むノートPCにCapistranoを仕込んでおけば便利なツールになるし、短期間に検証用のサーバを構築する場合も有用なツールになるでしょう。Capistranoはデプロイツールとして使われることが多いですが、サーバ構築にも有用です。 CapistranoはRubyで書かれたツールで、複数のサーバにSSH接続してコマンドを実行できます。同様のツールとしてexpectがありますが、CapistranoのスクリプトはRubyの内部DSLなので書きやすく拡

Google Tasks APIはタスクにアクセスするためのAPIです。GoogleカレンダーにTo Doリストが付いていますよね、あれです。 WebアプリからGoogle Tasks APIにアクセスするにはクライアントサイド（JavaScript）とサーバサイドの2つの方法がありますが、今回はサーバサイドを説明します。 必要なもの。 HTTPSをサポートするWebサーバ アプリを実行するAPサーバ ここではJava ServletベースのWebアプリで説明します。 ところどころGoogle App Engine+Slim3なコードが出てきますがご了承ください。 google-api-services-tasks クライアントライブラリ 依存関係が複雑なのでMavenを使うと便利です。 事前準備として、Google API ConsoleのTasks APIにアクセスしてClient I

int128殿の会社では、 >プログラミングは誰でもできる、頭を使わない作業 と思う方が多くいるのかしら？ http://d.hatena.ne.jp/int128/20080414/1208181589 うちに限らず、多くの大企業SIerではプログラミングを単純労働と捉えています。その理由は3つあります。 （1）プログラミングは業務をプログラムに落とし込む単純労働 SIの開発手法（の考え方）は30年前から進化していません。業務をプログラムに落とし込む作業は誰がどうやっても同じようになるという思想に基づいています。現在のように高品質なフレームワークやライブラリが溢れる時代では、いかにそれらを組み合わせて作るかが効率化の鍵になります。組織のトップが進化した設計思想を理解しようとしないのは問題です。 30年前の設計思想であれば、プログラミングは業務をプログラムに落とし込む単純労働です。 （2）

インフラを設計する上で冗長化による信頼性向上は避けて通れない道です。サーバとL2スイッチの接続を冗長化する設計については意外と情報が少ないのでまとめてみました。変なこと書いてたらご指摘ください。 インフラ設計の基本は単一障害点（SPOF）を取り除くことです。構成要素のうち1つが故障してもサービスを維持できるように設計します。構成要素は以下のものが挙げられます： CPU マザーボード メモリ ローカルディスク 電源 FC-HBA NIC LANケーブル L2スイッチ ・・・ ただし、これらすべての故障に備えようとすると費用対効果が割に合わないので、ローカルディスクから下を冗長化する構成が一般的と思います。絶対に止まってはいけないサービスは別ですけどね。 冗長化の種類 サーバを冗長化するにはクラスタを組みます。クラスタはActive-ActiveとActive-Standby（HA）の二種類に

App Engineでは実行時間に制限があるため、長時間にわたる処理を行う場合は複数のタスクに分割する必要があります。この手法は一般にタスクチェーンと呼ばれています（たぶん）。 タスクチェーンを抽象化してフレームワークにできるか考えてみました。 タスクチェーンを実現するには、タスク間のデータの受け渡し、タスクの一意性保証を実装する必要があります。 Driver タスクチェーンを開始するためのサーブレットです。Driverを経由せず、Webブラウザやcronからタスクチェーンを開始することも可能です。 Task タスクチェーンにおけるタスクを抽象化したものです。 Taskは入力として Map を受け取り、出力として次のTaskに Map を渡します。 public interface Task { /** * Process of the task. * @param input data

私も流行のムーヴメントに乗ってみます。 ソフトウェア業界（特に受託開発業界）は、基本的に正直者が馬鹿を見る世界である。顧客(あるいは経営者)が、保守性というソフトウェアの最も重要な品質を正しく評価できないという、情報の非対称性が存在するからだ。ソフトウェアの品質が、本当にいいか悪いかではなく、いかにまともであるかのように見せかけて、手を抜くかが経営者の腕の見せ所になった（売り手と買い手の間の情報の非対称性を是正する手段を持たない産業では、どこでも同様であろう）。 私がソフトウェア技術者をやめた理由 - elm200 のノマドで行こう！ 何も間違ったことは書かれていない。ただ、ソフトウェア業界を語るには世界が広すぎます。受託開発のプライム、下請け、パッケージベンダ、研究開発、Webサービス、情シス部門・・・。まったく違います。社内転職した私ですら一日の過ごし方が全然違うのだから。 elm20

App Engine上のアプリでは利用者の体感待ち時間を短くするため、JSPを使わずにAjaxで実装することがあります。この方法はOpenID認証（Federated Login）でも有効です。 web.xmlのsecurity-constraintで認証をチェックする方法を以前紹介しましたが、この方法ではサーブレットを経由してログイン画面に遷移するまでに待ち時間が発生してしまいます。 代わりにクライアント側で認証をチェックすることで、ログイン画面に遷移するまでの待ち時間を省けます。クライアント側で認証をチェックするには、JavaScriptで ACSID というクッキー*1の有無を確認します。 （図の1） JavaScriptは認証Cookieの有無を確認します。初期状態では認証Cookieを持っていないので、ログインフォームを表示します。 $.extend({ /** * ログイン済み

受託開発が抱える本質的な非効率性について考えました。ここで挙げたことはどの開発プロセスでも発生しうる問題と思います。 外注のオーバーヘッド 契約に係るコスト。 限られた場所や時間で質疑応答を行うことによる損失 情報の伝達コストは「機会」により決まる。拠点の違い、限られた時間、組織の壁により機会は減り、伝達コストは高くなる。 打合せや質問票を中心に質疑応答を行うため、情報の伝達コストが高くなる。 発注側の縦割り部門、受託側の下請け構造により、情報の伝達コストが高くなる。 決定に要する時間が長くなる。 開発者が業務プロセスを学習するコスト 前提として、どんな要件でも学習コストは必ず発生する。 過去に学習した知識を再利用できるとは限らない。受託側に業務スペシャリストが存在するとは限らない。 発注側から業務に関する説明を受ける機会（＝教育）が十分にないため、極めて非効率な学習にならざるを得ない。

異動を決意した原点を振り返ってみようと思います。 私には「直営社員にもプログラミング能力が必要であり、自ら問題解決に臨む文化を形成していきたい」という一貫した想いがあります。 現場で正しい判断が行われず、後になってコストがかさんで炎上する場面を何度も見てきました。事前にすべてのリスクを考えることは不可能ですが、丸投げではなく、自ら調査して理解する姿勢があれば分かったことはたくさんあると思います。 なぜ自ら手を動かして問題解決に臨む文化が必要なのかは、過去のエントリで書いています。 直営社員にプログラミング能力が必要なたった一つの理由 - GeekFactory 自分で手を動かさずに方式を決めること - GeekFactory 私が配属になった頃の組織はそういう文化は薄く、リソースの割き方は明らかにマネジメントサイドに偏っていたと思います。優秀な方は多かったですが、 上司との面談では、社員が

App EngineでOpenIDシングルサインオンを利用した場合のシーケンス図を書いてみました。OpenID Providerが「はてな」の例です。 開発者が用意するページは黄色の部分に示したログインページだけです。設定内容は OpenID認証によるシングルサインオン - GeekFactory で説明しています。 シーケンスを説明します。 リクエストパスがsecurity-constraintにより保護されている場合、App Engineは認証状態をチェックする。 認証済みの場合は、本来のリクエスト処理を実行する。 未認証の場合は、ログインページ（/_ah/login_required）にリダイレクトする。 ユーザはログインページでIdentifierを入力し、ログインサーブレット（/login）にPOSTする。 ログインページは開発者が用意する。 フォームの隠し属性にcontinue

システム開発では、開発を担当する会社と運用を担当する会社は異なることが多く、場合によってはユーザ企業内でも部門が違ったりします。一般に、開発コストをケチると運用コストは増加する傾向にあります。例えば、リファクタリングによりソースコードの保守性を高めると開発コストはかさみますが、保守コストは下がります（下がることが期待される）。冗長化により耐障害性を高めると運用コストは下がりますが、構築コストはかさみます。 保証すべきことを明文化したものが要件定義書やSLAですが、どこまでリファクタリングすればよいか、どこまで冗長化すればよいかといった微妙なさじ加減は、最後は現場の判断になっていると思います。エンジニアはここまでやるべきという心を持って仕事しているところはいつも感心します。日本人は真面目なのでしょうね。 ところが、プロジェクトが炎上したり工数削減圧力が高くなったりすると、現場の判断はすぐに逆

大きなSIerでは社員はプロジェクト管理だけを行い、実作業の大半を外部に委託するところがほとんどです。直営比率が低いところは管理作業しか行わないため、入社してから設計書もプログラムも書いたことがない人は割といます。感覚的には、直営比率が1/3を超えるプロジェクトは社員が自ら現場で作業することが可能で、若手社員にも実作業を経験する場が与えられる気がします。 大きなSIerの小さなプロジェクトはたいてい同じ構造をしていて、ソフトウェア開発自体を丸ごと外注していることが多いです。一括請負契約ですね。この場合、委託元と委託先の責任境界は明確で、委託業務に社員が深く関わることはあり得ません。それでコストが増えたら喧嘩になります。残念ながら、このような構造では社員がソフトウェア開発の実作業を経験することは不可能です。 私は、直営社員もコーディングやテストを自ら行える能力が必要と考えます。その理由は、現

Apache Tomcat 5.5.26（6.0.16も同じ）で、HTTPクッキーの取り扱いについて大きな仕様変更が行われました。ここでは仕様変更の内容と影響範囲を考察します。 HTTPクッキー 簡単に復習しましょう。WebブラウザがWebサーバから以下のHTTPヘッダを受信したとき、Webブラウザは test というクッキーを記憶します。 Set-Cookie: test=nullpo; Expires=Wed, 08-Oct-2008 14:03:16 GMT; Path=/クッキーは NAME=VALUE という形で表現されます。連想配列と同じ。 NAME VALUE test nullpo 一度クッキーを受信すると、ブラウザは当該URLにアクセスする度に、以下のHTTPヘッダを送信するようになります。 Cookie: test=nullpoこのように、クッキーはWebサーバがブラウ

User-Agentに応じてコンテンツの内容を変えるにはmod_rewriteが便利です。ただし、書き方を気を付けないと可読性が低くメンテしにくい設定になってしまいます。 普通に書くとこんな感じです。User-Agentパターンは実際はかなりあります。 RewriteCond %{HTTP_USER_AGENT} DoCoMo [OR] RewriteCond %{HTTP_USER_AGENT} SoftBank [OR] RewriteCond %{HTTP_USER_AGENT} Vodafone [OR] RewriteCond %{HTTP_USER_AGENT} KDDI RewriteRule ^.*$ http://example.com/m/ [R,L] ここで、リダイレクトはトップページだけに限定してみます。最近はテレビにもWebブラウザが搭載されていますので、テレビ向