あなたにとって重要なトピックや同僚の最新情報を入手しましょう最新の洞察とトレンドに関する最新情報を即座に受け取りましょう。 継続的な学習のために、無料のリソースに手軽にアクセスしましょうミニブック、トランスクリプト付き動画、およびトレーニング教材。 記事を保存して、いつでも読むことができます記事をブックマークして、準備ができたらいつでも読めます。

小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le

さくらのVPS+Jenkins+github+rails3の続編。 ゴールは、githubにpushすると、さくらのVPSで動いているJenkinsがgithubから最新ソースひっぱってRobolectricのテストかけた上に、apkを作るところまで。 プロジェクトの作成 mavenプロジェクトにしてみた。 ユーザーの作成 以前作ったやつで兼用。 SSH key コレも兼用しようと思ったらダメだった。１リポジトリにつき１keyだそうで。 https://help.github.com/articles/error-key-already-in-use Once a key has been attached to one repo as a deploy key, it cannot be used on another repo. If you're running into this

社内勉強会向けに作ったプロジェクト管理の発表資料です。 会社ブログ記事 http://www.infiniteloop.co.jp/blog/2012/12/happygamedevelop/

こんにちは. 先日水道を止められて水のありがたみを再確認したgoccyこと五嶋@たんぽぽグループです. 今回は, 先日q_zouさんから紹介のあった技術的負債を減らす取り組みの一環で, 僕が開発したビジュアライザについてご紹介させて頂きます. はじめに 弊社では主な開発言語としてPerlを採用しており, そのソースコード量は数十万行単位に上ります. 自社で開発したライブラリ群はプロジェクトルート下のlib/Mixi/配下に設置されており, 更にその下でサービスや用途毎にNamespaceが分かれています(lib/Mixi/APIやlib/Mixi/Photo, lib/Mixi/Voiceなど). ※以降, 文章中のNamespaceという表現は, これら(lib/Mixi/APIなど)を指すものとします. 本来であればNamespace単位で疎結合化されているべきですが, なかなかうまく

Exchange Server OnLineやOffice 365など、マイクロソフトはパッケージソフトウェアとして開発した製品を、次々にオンラインサービスとしても並行して提供を始めています。そのオンラインサービスの開発について、マイクロソフトは先日買収したYammerが実践している手法を学ぼうとしていると、Network Worldの記事「Yammer impacting Microsoft's software development process」（マイクロソフトの開発プロセスに対するYammerのインパクト）が報じています。記事から引用します。 Specifically, Microsoft sees great value in the way Yammer introduces weekly changes and new features to its cloud-host

ブランチングモデルとしてgit-flowを使っていて、メインラインとして、本番適用中のmasterブランチと、次期リリース用のrelease/9999ブランチと、メイン開発ブランチのdevelopがある。 ところが、開発中は頻繁にブランチを移動するし、ブランチによってDBのスキーマが異なるなんてザラにあるし、ブランチ切り替える度にconfig/database.ymlを書き換えるのもタルいので、こんな風に書いた。 development: adapter: postgresql database: my_app_<%= case `git symbolic-ref --short HEAD` when 'master' then 'master' when 'develop' then 'develop' when /release\/.*/ then 'release' when /ho

どうもこんにちは。 Aiming で東京開発グループのゼネラルマネージャをやっている小林です。 8月に mobage と Yahoo! モバゲー で ロードオブナイツ というシミュレーション RPG をリリースさせて頂きました。 そして、先週、 Yahoo! モバゲー版の PC ブラウザ専用デザインをリリースさせて頂きました。 今回リリースしたものは元々 Unity で作られていた iOS アプリ版 Lord of Knights を HTML5 で書きなおしたものです。 （今は Android 版 もあります） HTML のポチポチゲーをネイティブに移植したというのはよく聞く話ですね。 ですが、逆にリッチなネイティブアプリを HTML5 に移植し、かつスマフォブラウザと PC ブラウザで同じものを動かすなんてのは前例が見当たりませんでした。 技術的ハードルが高かったことに加えて期日がタイ

hrysd心を折られるチンカスプログラマーことhrysdがバイトで来てくれることになったので一緒に大門に出社。 初出社前に既にバグを一個潰してコミットしているという荒業を見せたhrysdだが、3000行を超えるcontrollerに早くも心を折られる。 俺「actionのメソッドが5行を超えたら危険印、なんていうrailsのぬるま湯に使ってたんだよ！これがサバンナだ。」 Github Organization契約出社後早速、社長にGithub Organization Bronzeプランを契約してもらう。技術的なことはわからないというが、リスクを背負って立てなおそうという気持ちが伝わって来ました。 9月30日の直近の締め切りに間に合わないのでsvn + redmineからの移行は10月にお預けだ。 svnがよくわかってないまずはsvnでもトップにぶち撒けられてるというのは辛いのでtrunk

"米国人からコーディングについての怒りのメールを頂戴した" の補足 - その手の平は尻もつかめるさ ↑の方で補足いたしました。(2012.09.04 追記) 最近、英語のメールでよく怒られます。moznion です。 海を隔てて共同作業しているアメリカ人から、僕のコーディングについてお叱りのメールを頂いたので、 自戒の念を込めて邦訳して記します。 書いてあることは「当然」とも言うべき内容ですが、僕はその「当然」も守れていなかったのかぁ〜と反省。 以下、邦訳(意訳)です。 1. 郷に入っては郷に従え 既にソースコードが存在しているって事は、そこには同時にコーディングスタイルも存在しているってことだ。 その既存のソースコードに手を加える場合、別のコーディングスタイルを導入してはならない。 もし君がバックエンドのソースコードを弄っているなら、バックエンドのコーディングスタイルで記述するんだ。 フ

楽観的排他制御を利用する非同期的なトランザクション実行であればスケーラビリティを損ねることなく2phase commitが可能である。これは、分散KVSにおけるスケーラビリティと一貫性の両立について で主張したように、同期的な2phase commitは密結合に誘導することになるため、矛盾するように思えるかもしれない。だがそんなことはない。 前半はまずこの話から入るが、後半ではRESTに関する間違いについて、３つほど思うところを述べたい。 楽観的排他制御と2phase commit reflexworksではFeedやEntry単位でatomicなトランザクション処理を行えるが2phase commitはサポートしていない。これを許すと密結合になってスケールしないからである。だが、これはあくまで同期的な処理の話であって、ネットワーク障害への耐性を考慮され、非同期処理やオフラインで使えるので

コードと構成管理の取扱いについて。ソフトウェア開発プロジェクトで自分がプログラミングすることは基本的に無いのだけれども、プロジェクトマネージャとしてはかなりコードに触れるほうだと思っている。最近コードにまつわる興味深いブログ記事をいくつか見たので、これに対して自分の考えを少しまとめてみる。 コードレビューについて ここで紹介されている、構成管理システム(VCS)でのレビューコントロールがとてもエレガントだと思う。 レビューのために bug tracker や task management system を使うのはあまり良いとは思いません。 レビューでは非常に細かい点が議論されることがあり、これが仕事のタスクの一チケットに相当するとはとても思えないからです。 例えば、この変数名は短すぎて良くわからない、といったことのために bug tracker をブラウザで開き、チケットを切る、やってら

デブサミで、ご希望の方にプランニングポーカーを有償でお分けしました。一個単位で輸入すると送料がばかにならないのですが、弊社で多めに買ったものをお分けしており、少量でもコスト安く手に入ります。 (2014年現在は行っておりません。アギレルゴコンサルティング社にお問い合わせください。) Mountain Goat 社製プランニングポーカーカード を一個単位でお分けします。 - アギレルゴコンサルティング株式会社 残念ながら在庫が十分に足りず、ご興味を持っていただきながら手に入らなかった方がたくさんいらっしゃると聞きました。弊社の方でもほそぼそとお分けしておりますので、ご興味のある方は、ご検討いただければ幸いです。ほとんど原価販売です*1。 ※2012/2/20追記: 日本マイクロソフトの長沢さんがノベルティとしてプランニングポーカーを配布されていますので、そちらもご参照ください。 使い方の説明

ウォンテッド株式会社社長の仲暁子さん（元Facebook）が、セミナーで以下のような話をされたそうです。 「Facebookにはテスト用サーバーが無いんです。エンジニアはすべて本番環境の上で開発をしていて、リリースとなったらそれを一般ユーザーに見えるように公開するだけ。エンジニアにすごい権限が与えられている。」 これに対してコメント欄でUmihiko Namekawa氏が次のような捕捉をしています。 これは環境や金の問題じゃありません。Facebookという会社の文化なんですね。Facebookの社是がHack!　「フェイスブック　若き天才の野望」にマークが寝そべって雑談しながらノートパソコンにコードをばしばし打ってEnter!でいきなり機能を公開しちゃうのを見てVCが肝を冷やす、というシーンが出てきます。当時でもユーザー500万というスケール。 なるほど、Facebookの企業文化なので

http://www.yamdas.org/column/technique/hatenablog.html なお、タイトルに PART I とあるが、このネーミングはメル・ブルックスの『珍説世界史 PART I』にちなんだもので、PART II 以降は存在しない。つまり、あなた（ソフトウェア企業）が絶対すべきでないことは、Joel Spolsky にとってこの文章に書かれることだけなのだ。それは何か？ プログラムをスクラッチから書き直すことに決めることだ。 まぁ、そんなわけないんだけどね。 「最近のはてなの体たらくへの失望感に名前を付けたい」というだけの文章にマジレスするのも我ながらどうかと思うし、気持ちは分からなくもないんだが、最近は「はてブ」以外全く使ってない俺でも、長年お世話になってきたはてなに対してそれなりに愛着というものがあるわけで、ディスられるばかりの流れに少しばかり反抗を試