クックパッドにおけるScalable Deploymentsのスライドが興味深い - GeekFactory
クックパッドにおけるアプリのデプロイの資料が非常に興味深いので紹介します．これは @sora_hさんがRubyKaigi 2014で発表 された資料で，100台以上のサーバに短時間でアプリをデプロイする仕組みをどうやって作り上げたのかが説明されています． 以前，スライドの内容を箇条書きにまとめていたのでシェアします．最近では，Jenkins User Coferenceの発表（How We Use Jenkins? // Speaker Deck）でほんの少し引用されていたりします． 内容のまとめ スライドは90枚あります．ざっくりまとめた内容を以下に示します． 概況 140サーバに1日10回のデプロイを実施している（ピーク時） コードベースが大きい モデルだけで約 69K LOC プロダクトコードとテストコードを合わせると約 319K LOC デプロイのルール CIのビルドが成功したリビ
Webアプリの実行時にJavaScriptを圧縮する - GeekFactory
Webアプリの公開にあたっては、データ転送量や実行効率の点からJavaScriptを圧縮（minify）して配信することが推奨されています。ここでは実行時に圧縮する方法を説明します。 JavaScriptの圧縮にはGoogle Closure Compilerを利用します。Maven pom.xmlに以下を追記するか、zipアーカイブをダウンロードして配置します。 <dependencies> <dependency> <groupId>com.google.javascript</groupId> <artifactId>closure-compiler</artifactId> <version>r1592</version> <exclusions> <!-- 実行時はAntなくても動く --> <exclusion> <artifactId>ant</artifactId> <gr
今日から始めるサーバ構築の省力化 - GeekFactory
SSHクライアントたくさん並べてペーストしまくるのが許されるのは小学生までだよね と言ってみたかっただけです。こんにちは。 Capistranoでサーバ構築を省力化する方法を紹介します。サーバ構築の自動化といえばChefやPuppetが有名ですが、CapistranoはサーバにSSH接続さえできれば利用できるメリットがあります。データセンタに持ち込むノートPCにCapistranoを仕込んでおけば便利なツールになるし、短期間に検証用のサーバを構築する場合も有用なツールになるでしょう。Capistranoはデプロイツールとして使われることが多いですが、サーバ構築にも有用です。 CapistranoはRubyで書かれたツールで、複数のサーバにSSH接続してコマンドを実行できます。同様のツールとしてexpectがありますが、CapistranoのスクリプトはRubyの内部DSLなので書きやすく拡
Team Foundation Serverの運用事例と雑感 - GeekFactory
ある案件でTeam Foundation Server（TFS）を使った時の雑感をまとめてみました。昨日のワンクリックデプロイ勉強会にインスパイヤされて書きました。参考になりましたら幸いです。アンチパターンも含まれていますので反面教師にして頂ければと思います。ああ恥ずかしい。 プロジェクトの性質 6ヶ月で要件定義から試験までやってリリース。開発チームは最大8名で年度末に解散。 R&D的な取り組みなので要件はほとんど見えておらず、最初の1ヶ月でプロトタイプを提供して本当にやりたいことを検討した。（これ以上は割愛） アジャイルではない。一括請負契約のウォーターフォール。 顧客にはリッチクライアントアプリを提供した。 開発環境 サーバ Windows Server 2008 R2 Visual Studio Team Foundation Server 2010 短時間でCI環境を構築できるメリ
AjaxによるFederated Loginの待ち時間の短縮 - GeekFactory
App Engine上のアプリでは利用者の体感待ち時間を短くするため、JSPを使わずにAjaxで実装することがあります。この方法はOpenID認証（Federated Login）でも有効です。 web.xmlのsecurity-constraintで認証をチェックする方法を以前紹介しましたが、この方法ではサーブレットを経由してログイン画面に遷移するまでに待ち時間が発生してしまいます。 代わりにクライアント側で認証をチェックすることで、ログイン画面に遷移するまでの待ち時間を省けます。クライアント側で認証をチェックするには、JavaScriptで ACSID というクッキー*1の有無を確認します。 （図の1） JavaScriptは認証Cookieの有無を確認します。初期状態では認証Cookieを持っていないので、ログインフォームを表示します。 $.extend({ /** * ログイン済み
受託開発のコスト意識 - GeekFactory
システム開発では、開発を担当する会社と運用を担当する会社は異なることが多く、場合によってはユーザ企業内でも部門が違ったりします。一般に、開発コストをケチると運用コストは増加する傾向にあります。例えば、リファクタリングによりソースコードの保守性を高めると開発コストはかさみますが、保守コストは下がります（下がることが期待される）。冗長化により耐障害性を高めると運用コストは下がりますが、構築コストはかさみます。 保証すべきことを明文化したものが要件定義書やSLAですが、どこまでリファクタリングすればよいか、どこまで冗長化すればよいかといった微妙なさじ加減は、最後は現場の判断になっていると思います。エンジニアはここまでやるべきという心を持って仕事しているところはいつも感心します。日本人は真面目なのでしょうね。 ところが、プロジェクトが炎上したり工数削減圧力が高くなったりすると、現場の判断はすぐに逆
直営社員にプログラミング能力が必要なたった一つの理由 - GeekFactory
大きなSIerでは社員はプロジェクト管理だけを行い、実作業の大半を外部に委託するところがほとんどです。直営比率が低いところは管理作業しか行わないため、入社してから設計書もプログラムも書いたことがない人は割といます。感覚的には、直営比率が1/3を超えるプロジェクトは社員が自ら現場で作業することが可能で、若手社員にも実作業を経験する場が与えられる気がします。 大きなSIerの小さなプロジェクトはたいてい同じ構造をしていて、ソフトウェア開発自体を丸ごと外注していることが多いです。一括請負契約ですね。この場合、委託元と委託先の責任境界は明確で、委託業務に社員が深く関わることはあり得ません。それでコストが増えたら喧嘩になります。残念ながら、このような構造では社員がソフトウェア開発の実作業を経験することは不可能です。 私は、直営社員もコーディングやテストを自ら行える能力が必要と考えます。その理由は、現
世間が不景気になったらSIerはどうなるか - GeekFactory
不景気の波がSIerを直撃しています。世間より半年ぐらい遅れている気がします。回復するのも半年ずれるでしょう。 世間が不景気になったらSIerはどうなるか考えてみます。まずは売上の変化。 ユーザ企業からの受注高が減る。 稼働している社員が減る。 余剰人員が生まれる。 外注より直営を優先する。 パートナーの売上が減る。 次に、プロジェクトへの影響を考えてみます。 プロジェクトで使える費用が減る。 プロジェクトの人件費を削る。 一人当たりの仕事量が増える。 スポットの外注が増えて、一貫した仕事ができなくなる。 デスマ化する。 問題プロジェクトが発生する。 プロジェクト外で余剰人員をかき集める。 プロジェクトの人件費が増加するが、全社的には余剰人員の活用で相殺される。 まとめると、 一人当たりの仕事量が増える。 部門間の人材流動性が一時的に高まる。 直営社員は問題プロジェクトに投入される可能性が
90年代と21世紀の越えられない壁 - GeekFactory
実質的な仕様承認者となることが多いであろう30代後半の人は、1990年代のクライアントサーバの経験で生きている。業務トランザクションやGUIの考え方は、VBに代表されるクライアントプログラムがベースになっている。業務データが入力されてからコミットされるまでプログラムは動いているし、画面の操作はイベントでやってくる。 これに対して、Webを当たり前のように使っている人たちはステートレスな世界に慣れているし、画面の操作はページ遷移を伴うことを前提にしている。HTMLで書かれたページに対してMouseOverだの再描画だの言っても噛み合わない。両者の間には越えられない壁が存在する。 まとめると、世代の違う人がレビューすると前提が違いすぎて話が噛み合わないケースがある。そんなことを感じた今日この頃。企業内システムはまるで時計が止まった世界にあるようだ。
今やれることをやる、後で困らないことは後でやる - GeekFactory
見積もり工数は、あくまでも個人的にざっくりベース（SI用語）で出した数字なので、ズレがあるわけで。事前にタスクを割り振る場合は見積もり時間を基準にする必要があると思うけど、見積もりのズレや個々人の状態によってかなりブレるのが普通で、途中でタスクの振り直しが発生する。絶対に。ということで、全体を事前に決めず、「今からどれをやろうか」を決めながら進めるようにした。 http://d.hatena.ne.jp/katzchang/20090924/p1 SIで不毛なのは完全なスケジュールの作成だと思います。不確定な要件から引いたスケジュールで「計画と実績の乖離」とか言われてもなぁ、というのは同感。 いま私が持ってるチームも同じような進め方をしていますが、インフラまわり*1を担当していることが大きな違いです。基本的にアプリ開発チームからの要望や苦情で50%以上の工数を使い切ってしまうので、「今やれ
夢見るSIerと虚構 - GeekFactory
たまには実情を書いてみる。愚痴大会なので読み飛ばしてくだしあ。 SIer の経営方針としては、｢どんなカタチにせよ、生産性を高めるのである｣という方向に行くと思います。生産性を高める要因は２つしかなくて、｢開発プロセスの改善｣と｢ソフト生成の自動化｣です。要するにワンタッチでポンでシステムが出来ればすげぇじゃんっていう発想。でも、そもそも要件定義が終わると全部終わるので、どうにかして改善されたプロセスを最大限に働かせるアジャイル的プロセスへの移行は不可避だと思う。 http://d.hatena.ne.jp/gothedistance/20090723/1248331426 「開発プロセスの改善」はどこのSIerでも施策に挙げていると思いますが、成果を上げているところはあるのですかねぇ。要件定義と開発はまったく別の仕事だから、両者で改善方法はまったく異なるはず。まずは後者のウォーターフォー
公共事業が日本の○○業界を延命している - GeekFactory
タイトルに深い意味はないです。 id:ysakata先生をお誘いして、新橋に飲みにいってきました。新しいアイディアや発想の転換は「飲み」から生まれるものですね。充実したお話ができてよかったです。ありがとうございました。 いまの仕事が修行だとすれば、どこまでやれば卒業（修了？）になるのか。修了条件が曖昧なままナアナアで日々の仕事に取り組んでいるのが現状ですが、ここで何を得るかを考えなきゃ。まあトレーナーをやれば卒業とか考えてはいたんですけどね。今までやってきた仕事を棚卸しするとよいヒントになりそうです。 LDAPはもっと注目されてもよい技術なんだけどなぁ。LDAPに限らず認証管理は地味ですね。OpenIDも記事が多い割には全然使われてないし。そういった意味では、認証管理は狙い目かもしれません。 ちょっと遅いですが、今年度の目標は「1つのことを最後まで丁寧にやり遂げて公開する」ことにします。
受託案件と企画案件の違いを感じる - GeekFactory
受託開発の最たる問題は受け身であること。例えば、試験項目書は必ずWordで書かなきゃいけないとか、証跡はPowerPointにまとめて表紙を付けなきゃいけないとか、誰が決めたか不明なルールがたくさんあると思います。ルールがガチガチに決まった開発現場にずっといると、非効率なルールが当たり前に染みついてしまい、思考停止に陥る危険性があります。 お客様が作れといったから作りました。 という思考停止は危ない。 企画案件は自分らが意志決定していく必要があります。自分らが投資をするので、どこまで設計書を作るとか、リファクタリングをするかといったことも経営判断の1つになります。文字色を少し変えるだけで売上が変わる可能性もあるのです。 日本のSI業界が受け身の姿勢に染まっているのは問題ではないでしょうか。
3/19に金沢で突発オフやります - GeekFactory
突然ですが、18きっぷの旅に出ます。 とりあえず3/19は金沢に行きます。id:katzchangに連絡してみたらOKをもらったので、突発オフを開催します！金沢市内にオヌヌメの飲み屋があれば教えてください。そして、参加してください！ 日時 2009/3/19（木）20時ぐらい 場所 石川県金沢市のどこか 前回議事録 http://d.hatena.ne.jp/katzchang/20081104/p2 今回はリアルタイム更新しながら移動してみようと思います。 東京から金沢までは高崎・上越・信越・北陸本線経由にするつもりですが、はくたかでワープしないと時間通りに着きませんね。直江津で乗り継ぎがかみ合わないのが悩みです。 金沢から先の予定は未定ですが、とりあえず大阪方面かな。さて明日はどこに泊まろうかな。
ソフトウェア工業化と職人化が待ち受ける世界 - GeekFactory
生産性が 30 倍違うのであれば、バカプログラマー 30 人を雇うより、スーパープログラマー 1 人にサポートスタッフ 5 人つけたほうが安くていいものができるだろう。Ruby の開発でいえば、まつもとさんやささだ先生にサポートスタッフ (あるいは秘書とか内弟子とか) をつけて、極力彼らが雑用をせずに Ruby 開発に専念できるような環境を整えるべきではなかったか。 http://d.hatena.ne.jp/kwatch/20090204/1233769288 基本に立ち返って、ソフトウェア工学の目的とはなんだろう。それは「ソフトウェア開発が産業として安定成立する事」だろう。そこでこれを、大目的とする。 では、さらに考えて「産業として安定成立」するにはどうしたらいいだろうか。 大目的を成立させる為の、最低限の条件として考えられるのが、 ・条件１：成果物の品質安定 ・条件２：関連人材の安定
パッケージソリューションの仕事をSIerの中でやること - GeekFactory
コトあって同期で集合研修を受けています。これまでやってきた仕事の棚卸しとか、これからの目標とか、そういった話なので、お互いの仕事内容を知る良い機会です。そこでまわりとのギャップを感じたので書きます。 私はパッケージソリューションの企画手伝い and 開発 and 保守というお仕事をやっているので、お客様はいろんな業界に渡ります。官公庁であったり、銀行であったり、製造業であったりするわけです。得意分野のノウハウを価値として売っているため、お客様の業務内容に深く入り込むことはあまりありません。 ソリューションで何がよくなるのか、どんな仕組みかを説明できる必要があるため、最低限のコア技術を知らなければなりません。例えばシングルサインオンにするとこういうメリットがあるとか、サービスの認証連携で新しいユーザを取り込めます、といった話です*1。 一方で、特定のお客様との仕事をしている人もいます。むしろ
自分で手を動かさずに方式を決めること - GeekFactory
ここ数日、自宅サーバの仮想化方式を決めるためにkqemu, Xen, Linux-VServer, jailやらを試していました。Webで評価記事がたくさんありますが、正直なところどれも実際に使ってみないとわからんなと思います。 自分で手を動かさずに方式を決められるか？ サービスを作っていく上でどの技術（方式）を採用するか分かれ道があります。早い話が、Windows ServerにするかLinuxにするか、Javaにするか.NETにするか。方式を決めるには、必要な条件を洗い出し、どれがどう優れているかを評価します。 グラスと煎茶碗 ここに面白い喩えがあります。 方式としてどちらが優れているのかを、わかっていない人に説明するのって大変だよね。説明しないことはないけど手間はかかるし、そもそもなんでそんな上司が以下略。 例えば、グラスと煎茶碗、どちらも飲み物を給仕することは出来る。では、コーラを
明日から金沢に行きます - GeekFactory
11/3のお昼ぐらいに野田屋に行こうと思います。id:amachangが書いてたお茶屋さんです。よかったら会いませんか？＞id:katzchang 突発オフで集まると面白そう。旅行中はちゃんとtwitter見るようにします。 11/2は、朝から鶴来〜野々市〜157号の探索に出ます。今回はすべてグリーン車の贅沢な旅です*1。 野田屋 http://maps.google.co.jp/maps?f=q&hl=ja&geocode=&q=%E7%AB%AA%E7%94%BA+%E9%87%8E%E7%94%B0%E5%B1%8B&layer=c&ie=UTF8&ll=36.55791,136.65543&spn=0.001058,0.002307&z=19&iwloc=A http://d.hatena.ne.jp/amachang/20081012/1223833191 *1:北陸フリーきっぷ
外注化が必要な理由と社員の役割 - GeekFactory
正直なところ、マネージャ兼プログラマで仕事を進めるのは、自分+メンバー4人程度までが限度でしょう。4人に加え、顧客とのコミュニケーションコストでプログラムはほとんどできないはずです。物分りの良いお客様なら運が良い方です。 それ以上のチーム編成で仕事を進めるとしたら、必要なのはスーパーマンではなく、適切な権限委譲だと思います。 http://d.hatena.ne.jp/yamkazu/20081021/1224613822#c1224641572 上記のコメントがすべてを物語っていると思います。 が、私の話も少し読んでくださいね。 外注化が必要な理由 5人の社員がソフトウェアを作っているチームがあるとします。社員が働くと、給料や保険料といった労務費が発生します。話を単純にするため、1人が1ヶ月働くと100万円かかるとします。このチームが3ヶ月でソフトウェアを作ると、原価は1,500万円にな
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
情報を検索する世代と整理する世代 - GeekFactory
