チーム開発を始める時に決めること - GeekFactory
頭の中を整理するために、新たにチーム開発を始める時に決めることをリストアップしてみました。すべて書き出すと大量になるので、プロセスや開発基盤を中心に書いています。 プロジェクト計画 ゴール マイルストン スコープ リリース計画 プロセス チーム構成 リスクと対策 プロセス スプリントスケジュール（例：月曜開始の1週間スプリント） 会議体の設定（例：スプリント計画、スプリントレビュー、レトロスペクティブ） 複数チームのワークフロー（例：プロダクトオーナー、UXデザイナー、開発チーム、QAチーム） 仮説検証サイクル（例：仮説設定、リリース、分析） 進捗管理方法（例：リリースバーンダウン） 品質管理方法 障害対応のワークフロー プロセス改善の仕組み（例：レトロスペクティブ結果のバックログ化） プロダクトデザイン（略） ソフトウェアアーキテクチャ（略） インフラアーキテクチャ（略） テスト計画（略
クックパッドにおける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のビルドが成功したリビ
家計を支える技術 - GeekFactory
家庭を支える技術 Advent Calendar 2014 - Adventarの12日目です。 本記事では、我が家の「家計」を支える技術と運用を紹介します。これから同棲を計画しているカップルや家計の見直しを検討している方のお役に立てば幸いです。 独立採算制のメリット 我が家では、夫婦が各自の裁量で収支と資産（貯蓄）を管理するルールにしています。これには以下の3つの目的があります。 まず、利益を最大化するモチベーションが生まれることです。収入から支出を引いた利益がそのまま各自の資産になるというルールにすることで、無駄な支出を抑えて利益を確保するモチベーションが生まれます。もし、資産を合算で管理してしまうと、相手が使った分だけ自分も使わないと損することになります。ただし、これはお互いの信頼関係があって初めて成立するものです。 もう一つは、透明性を確保できることです。収支を各自で管理することで
@DelegateでJavaバージョンの差異が顕在化するケース - GeekFactory
JDK 8でビルドしたクラスファイルをJDK 7で実行するとClassNotFoundExceptionが発生する事象でハマったのでメモ。結論からいうと、ソースコードでJava 8に固有のクラスを直接参照していなくても、@Delegateによって間接的に参照されるケースがあります。 前提 JDK 8でのコンパイル時にsource, targetのバージョンを指定しているものとします。 そうしないと、JDK 7でクラスファイルを読み込んだ時に以下のエラーが発生します。 Exception in thread "main" java.lang.UnsupportedClassVersionError: Main : Unsupported major.minor version 52.0 Gradleでは以下の2行を書くだけでOKです。 sourceCompatibility = JavaVe
認証付きプロキシの内側で共用サーバを運用する - GeekFactory
多くの企業や教育機関ではインターネットアクセス用のプロキシサーバが導入されています。プロキシサーバの中にはユーザ認証を必要とするもの（認証付きプロキシ）があり、組織やチームの共用サーバを運用する上でしばしば問題を引き起こします。 例えば、共用サーバで以下のオペレーションを実行する時、認証付きプロキシを越える必要が生じます。 OSやミドルウェアのアップデート（yum, apt-get等） パッケージマネージャが外部リポジトリからパッケージをダウンロードする時（npm, RubyGems, EasyInstall, Jenkins plugins等） ビルドツールが依存ライブラリをダウンロードする時（Maven, Gradle, sbt等） 共用サーバから認証付きプロキシを経由してインターネットにアクセスするには、個人の認証情報を共用サーバに設定する必要があります。 認証情報は本来その人しか知
keepalivedとハードウェアルータでVRRPを構成する - GeekFactory
VRRPはデフォルトゲートウェイの冗長化で多く使われています。LinuxのクラスタミドルであるkeepalivedもVRRPに対応しており、ハードウェアルータと組み合わせることができます。 今回はkeepalivedとIX2015でVRRPを構成してみました。といっても特殊な使い方をしているので、ネットワーク構成は参考にならないと思いますｗ 正常時はLinux Routerをデフォルトゲートウェイにします。Linux Routerに障害が発生した場合はIX2015がデフォルトゲートウェイになります。 本来はIX2015にルートをまとめる方が運用が簡単です。Gigabitでないことや内部トラフィックをIX2015に流さないことが理由でLinux Routerを経由させています。行き帰りのルートが違う時点でダメダメなんですが、今の持ち駒ではこれ以上難しい。。。余剰のノートPCをL3スイッチ代わ
ビルドツールによる開発プロセスの改善と効果 - GeekFactory
世の中にいくら便利なツールがあっても、それを使うのは人です。ツールを導入するだけでは開発プロセスは変わりません。開発プロセスを変えるには、前例や慣習にしがみつく人や組織のリテラシーを変えていく必要があります。そういうレガシーな人たちと闘うための論理が必要だと思います。それはどの現場でも*1通用する力になると思います。 前置きが長くなりましたが、ビルドツールを導入して開発プロセスを改善するにあたって嬉しいことを挙げてみました。想定問答集です。コメントいただけると嬉しいです。 ソースコード管理ツール Subversion, Git, Mercurial, Team Foundation Serverなど。 導入してうれしいこと 開発者はソースコードを変更したらソースコード管理システムにコミットする。ソースコード管理システムは変更の差分を反映する。他人の変更と競合した場合は通知される。 ソースコ
自宅サーバのインフラ設計書を公開します - @int128
自宅サーバのインフラ設計書を公開します。 Design paper of the home server（抜粋） 昨夜にTwitterで公開したら予想外に反響があったので、ちゃんとエントリに残すことにしました。クラックされるおそれがあるので、細かい部分は公開できないことをご了承ください。 内容はこんな感じ。 要件概要 機器仕様 ネットワーク設計 ソフトウェアスタック設計 共通基盤設計 サーバ詳細設計 上記にバックアップ設計や運用管理まわり*1を加えれば、インフラの設計書はだいたいこんな感じではないかと思います。 インフラの要件定義は難しい 一方で、インフラの要件定義は十分に標準化が進んでおらず、会社やチームによって文化がかなり違います。特に受託開発（SI）の場合は、お客様の中にインフラに詳しい人がいなくて調整に苦労することも多いと思います。費用と可用性のトレードオフの部分はなかなか伝わりづ
アジャイル開発向け顧客チェックリスト - GeekFactory
大企業, SIerただ僕が顧客ならば動くソフトウェアを確認しながらウチの業務プロセスにフィットするかを確かめながら進めたいと強く思うので、そのメリットを価値に変えるストーリーがあればいいと思うんだけど、自分たちの手でシステムを進化させる文化が根付いていない所には｢なにそれ？おいしいの？｣という響かない提案になると非常に思うので、やっぱ内製だろって思ってしまう今日この頃です。http://d.hatena.ne.jp/gothedistance/20100212/1265907956id:gothedistanceさんの釣り力には本当に感嘆します。タイトルにアジャイル開発とか入れておきながら、結論は内製で締めています。読者を流行語でget()して自分の論説にforward()するとは、実に素晴らしいエンターテイメントです。と、無茶いってごめんなさい。アジャイル開発の本質は顧客が主体性を持つこ
パフォーマンステスト自動化の取り組み - GeekFactory
このところ、Webアプリやバッチのパフォーマンステストを自動化するために四苦八苦してるので書いてみます。 パフォーマンステストは泥臭い作業です。毎回似たような感じで待ち時間の長い単調作業と、ボトルネックを解析して実装やミドルウェア設定を見直すような神経を使う作業が入り混じって疲れます。このうち前者を自動化してしまえば、本質的な部分に力を注げるだけでなく、夜間や休日を活用して多くのバリエーションを試すことができます。 パフォーマンステストの流れはWebアプリとバッチで以下のように整理できると思います。 Webアプリ デプロイメント クライアントサイド（負荷生成側）で必要なデータセットの準備 サーバサイドで必要なデータセットの準備 アプリケーションの設定 負荷生成 クライアントサイドのログ収集 サーバサイドのログ収集 分析 バッチ デプロイメント サーバサイドで必要なデータセットの準備 アプリ
今日から始めるサーバ構築の省力化 - GeekFactory
SSHクライアントたくさん並べてペーストしまくるのが許されるのは小学生までだよね と言ってみたかっただけです。こんにちは。 Capistranoでサーバ構築を省力化する方法を紹介します。サーバ構築の自動化といえばChefやPuppetが有名ですが、CapistranoはサーバにSSH接続さえできれば利用できるメリットがあります。データセンタに持ち込むノートPCにCapistranoを仕込んでおけば便利なツールになるし、短期間に検証用のサーバを構築する場合も有用なツールになるでしょう。Capistranoはデプロイツールとして使われることが多いですが、サーバ構築にも有用です。 CapistranoはRubyで書かれたツールで、複数のサーバにSSH接続してコマンドを実行できます。同様のツールとしてexpectがありますが、CapistranoのスクリプトはRubyの内部DSLなので書きやすく拡
AjaxによるFederated Loginの待ち時間の短縮 - GeekFactory
App Engine上のアプリでは利用者の体感待ち時間を短くするため、JSPを使わずにAjaxで実装することがあります。この方法はOpenID認証（Federated Login）でも有効です。 web.xmlのsecurity-constraintで認証をチェックする方法を以前紹介しましたが、この方法ではサーブレットを経由してログイン画面に遷移するまでに待ち時間が発生してしまいます。 代わりにクライアント側で認証をチェックすることで、ログイン画面に遷移するまでの待ち時間を省けます。クライアント側で認証をチェックするには、JavaScriptで ACSID というクッキー*1の有無を確認します。 （図の1） JavaScriptは認証Cookieの有無を確認します。初期状態では認証Cookieを持っていないので、ログインフォームを表示します。 $.extend({ /** * ログイン済み
直営社員にプログラミング能力が必要なたった一つの理由 - GeekFactory
大きなSIerでは社員はプロジェクト管理だけを行い、実作業の大半を外部に委託するところがほとんどです。直営比率が低いところは管理作業しか行わないため、入社してから設計書もプログラムも書いたことがない人は割といます。感覚的には、直営比率が1/3を超えるプロジェクトは社員が自ら現場で作業することが可能で、若手社員にも実作業を経験する場が与えられる気がします。 大きなSIerの小さなプロジェクトはたいてい同じ構造をしていて、ソフトウェア開発自体を丸ごと外注していることが多いです。一括請負契約ですね。この場合、委託元と委託先の責任境界は明確で、委託業務に社員が深く関わることはあり得ません。それでコストが増えたら喧嘩になります。残念ながら、このような構造では社員がソフトウェア開発の実作業を経験することは不可能です。 私は、直営社員もコーディングやテストを自ら行える能力が必要と考えます。その理由は、現
これから18きっぷ旅行を始める人に贈る3つのコツ - GeekFactory
自称18きっぷ旅行コンサルの僕がid:gothedistance先生にうさんくさいエントリを贈ります。 僕は東京在住で、今回は名古屋と福岡には行かなくてはならないので、東京から西へ下り九州まで行って、そこから先は何も考えていないです。明日は明日の風が吹く。 なお、「泊めても・・・いいんだからね＞＜」っていう愛フルな方、大歓迎です。漫画喫茶とかで寝る気にはなれないので、ビジネスホテルを泊まり歩く予定です。泊めて頂けるとめっちゃコストが浮くので、単純にありがたいというだけのお話です。 http://d.hatena.ne.jp/gothedistance/20090227/1235718189 行先が名古屋、福岡なので、経由は東海道本線、山陽本線、鹿児島本線ですね。いずれも本数が多いので詳しい時刻は調べて行かなくても大丈夫です。むしろ臨機応変に時刻表を調べたり、ホテルを予約できるようにしておけ
ソフトウェア工業化と職人化が待ち受ける世界 - GeekFactory
生産性が 30 倍違うのであれば、バカプログラマー 30 人を雇うより、スーパープログラマー 1 人にサポートスタッフ 5 人つけたほうが安くていいものができるだろう。Ruby の開発でいえば、まつもとさんやささだ先生にサポートスタッフ (あるいは秘書とか内弟子とか) をつけて、極力彼らが雑用をせずに Ruby 開発に専念できるような環境を整えるべきではなかったか。 http://d.hatena.ne.jp/kwatch/20090204/1233769288 基本に立ち返って、ソフトウェア工学の目的とはなんだろう。それは「ソフトウェア開発が産業として安定成立する事」だろう。そこでこれを、大目的とする。 では、さらに考えて「産業として安定成立」するにはどうしたらいいだろうか。 大目的を成立させる為の、最低限の条件として考えられるのが、 ・条件１：成果物の品質安定 ・条件２：関連人材の安定
ソフトウェアメトリクスによる品質分析の実案件への適用 - GeekFactory
ソフトウェアの品質を分析する指標の1つにソフトウェアメトリクスがあります。現在、実案件の品質分析に適用しているのですが、開発者へのヒアリング内容とメトリクスの傾向が合致していて、非常に面白いです。 ソフトウェアのメトリクスとは、ソフトウェアを計測する方法およびその尺度のことを意味します。（中略）メトリクスを計測し、複雑過ぎるロジックや洗練されないパッケージ構成を見直すことで、バグが少なく保守性が高いソースコードを維持できるようになります。 （中略） メトリクスを用いると、特に以下の品質にかかわる問題を検出し、信頼性と保守性を高めることができます。 複雑なソースコードにはバグが潜在する可能性が高くなる 複雑なソースコードは読みづらく、テストもしにくくなる 複雑なクラス構造は理解するのが困難で、拡張性にも乏しくなる http://www.atmarkit.co.jp/fjava/rensai3
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
