Designer’s Design Talk Azure / Windows Development 2人のMVPの場合 -c-mitsuba
6歳と3歳の娘がいる山本泰宇(@ymmt2005)です。こんにちは。 いきなりですが、悔しいです。なにがって、@DQNEO さんが最近書かれた記事「必殺!Github導入に向けて上司を説得する時に使える資料まとめ」に載り損ねてしまったからです。 サイボウズでも Git と GitHub Enterprise を導入しています。導入や運用の助けになる資料やツールを作ったりして、とても便利なのでいずれ公開したいなと思っていたんです。忙しさにかまけて後回しにしていたら、出遅れ企業にグルーピングされてしまうなんて(涙) 出遅れてしまった以上、なにかプラスアルファをお見せするしか名誉挽回の方法はありません。何も失っていないんじゃないかというツッコミはよしてください。こうなったら恥も外聞もなく Subversion 時代の恥ずかしい過去をさらけ出し、もちろん資料も出して、さらにノウハウを詰め込んだツー
Accessibility View text version Categories Technology Upload Details Uploaded via SlideShare as Adobe PDF Usage Rights © All Rights Reserved Statistics Favorites 0 Downloads 0 Comments 0 Embed Views 0 Views on SlideShare 0 Total Views 0 アジャイルに対する見方の変化 — Presentation Transcript アジャイルに対する見方の変化- ソーシャルゲーム開発を経験して- 2012/11/17 太田健一郎 @oota_ken 目次 SIerの時のアジャイル感 アジャイルマニフェストの解釈 XPのプラクティスの解釈 自分がアジャイルだと
先日、とちぎテストの会議02に参加。"テストのレシピ"として、テストプロジェクトのプロジェクトマネジメントについて話させていただきました。 「日常、いつもの、ふつう盛りx2、小盛りx1」 - とちぎテストの会議 テストエンジニアへのリスクマネジメントのすすめ from H Iseri 前回に引き続き2回目ですが、異種交流のような雰囲気は相変わらずで、本会・懇親会ともとても楽しめる有意義な1日となりました。 運営者、参加者の方々大変ありがとうございました。 補記 今回はテストエンジニアによるリスクマネジメントについてお話させていただきましたが、理想は当然プロジェクト全体のリスクマネジメントがテストのリスクマネジメントを包含している体制です。それによって、全体最適を考慮しつつ改善策を検討できるようになります。 そして大抵のプロジェクトでは、一般的にプロジェクトリスクのマネジメントを行っていると
継続的デリバリを導入しようとする前に、いくつかの準備が必要です。真っ先に必要なのは、ビルドサーバに合うソースコード管理システムです。ビルドサーバは継続的統合を実施するサーバにもなります。ひとつひとつのチェックインをビルドできるサーバでなければなりません。一般的に言って、この用途では“既成”のビルドサーバが欲しくなります。チェックインを監視して、自動でビルドをする仕組みを構築するのは、想像以上に大変です。利用しているソースコード管理システムにフックできるトリガがあるとしても、ビルド失敗時の通知機能のような他の機能を実装するには割に合いません。 リソースが限られているとしても、継続的デリバリにとってステージングサーバは重要です。ステージングサーバは本運用環境に可能な限り似せておく必要があります。ここで第一の問題は“予算がいくらあるか”ということです。本運用環境のデータベースサーバがとても高価な
必殺!Github導入に向けて上司を説得する時に使える資料まとめ - DQNEO起業日記 でペパボも取り上げて頂いたので、ペパボでの GitHub の使い方について、少し詳しく書いてみます。 開発での利用 これは普通の使い方ですね。なので省略。 GitHub Enterprise は利用していない 金額的な面で GitHub Enterprise の利用は厳しいため、GitHub Enterprise ではなく、ノーマル(?)な GitHub を利用しています。(GitHub Enterprise にすると、現在のコストの 8 〜 9 倍ぐらいになってしまう。) ここはセキュリティ面とのバランスが難しいところではありますが… とはいえ、GitHub に何かあってソースコードが流出した場合に影響の大きさが懸念されるサービスについては、GitHub を利用しない、といった判断もしています。(で
どうもこんにちは。 Aiming で東京開発グループのゼネラルマネージャをやっている小林です。 8月に mobage と Yahoo! モバゲー で ロードオブナイツ というシミュレーション RPG をリリースさせて頂きました。 そして、先週、 Yahoo! モバゲー版の PC ブラウザ専用デザインをリリースさせて頂きました。 今回リリースしたものは元々 Unity で作られていた iOS アプリ版 Lord of Knights を HTML5 で書きなおしたものです。 (今は Android 版 もあります) HTML のポチポチゲーをネイティブに移植したというのはよく聞く話ですね。 ですが、逆にリッチなネイティブアプリを HTML5 に移植し、かつスマフォブラウザと PC ブラウザで同じものを動かすなんてのは前例が見当たりませんでした。 技術的ハードルが高かったことに加えて期日がタイ
アジャイルフィーバーは、一般的に、アジャイルベースのソフトウェア開発アプローチへの移行と関連する時間枠に沿った3つの段階の1つに属するように特徴づけることができる。初期、中期、最終段階である。多くの読者が正しく認識しているように、アジャイルフィーバーの一部は、非常に上手く段階に当てはまるかもしれないし、フィーバーの一部は、ある形で全段階に跨ぐかもしれない、という点で曖昧である。この記事は、 アジャイルフィーバーを完全に分類することにはあまり関心がなく、その症状を識別し、特徴づけることで、できるだけ早くそれらを認識することができ、治療することができるようにすることである。 初期段階のフィーバー 初期段階のアジャイルフィーバーは、集団的で全ての中で最も危険であり、最もかかる人が多く、簡単にかかってしまい、ソフトウェア開発の労力に損害を与える、最高の可能性を秘めている。アジャイルベースの??開発
自動改札機の運賃計算プログラムはいかにデバッグされているのか? 10の40乗という運賃パターンのテスト方法を開発者が解説(前編) ふだん何気なく使っている鉄道。改札を降りるときにICカードを自動改札にかざすと、「ピッ」という音と共に一瞬のうちに運賃を計算してくれます。けれど、複数の路線を乗り継いだり、途中で定期券区間が挟まっていたりと、想像しただけでもそこには膨大な組み合わせがあります。それでも運賃計算プログラムはわずか一瞬で正しい運賃計算が求められ、バグがあったら社会的な一大事にもつながりかねません。 爆発的な計算結果の組み合わせがあるはずの運賃計算プログラムは、どうやってデバッグされ、品質を維持しているのでしょうか? 9月12日から14日のあいだ、東洋大学 白山キャンパスで開催された日本科学技術連盟主催の「ソフトウェア品質シンポジウム 2012」。オムロンソーシアルソリューションズ 幡
デブサミ関西2012での講演内容まとめ はじめに 今月、GOOS日本語版が発売されました。 実践テスト駆動開発 (Object Oriented SELECTION) 作者: Steve Freeman,Nat Pryce,和智右桂,高木正弘出版社/メーカー: 翔泳社発売日: 2012/09/14メディア: 大型本購入: 4人 クリック: 262回この商品を含むブログ (31件) を見る継続的デリバリーに続き、高木さんと一緒にお仕事をするのはこれで二冊目です。今回も多くの人に助けられて、目標としていたデブサミ関西での出版にこぎつけることができました。関係者の皆さま、どうもありがとうございました。 講演では触れませんでしたが、ここで「実践テスト駆動開発」というタイトルの由来について少し書いておきます。原書のタイトルはご存じの通り、"Growing Object-Oriented Softwa
パソナテック Find Your Ability 講演資料 「ディレクターにとってのWeb業界って? 」naoki ando
EngineeringDeploying at GitHubDeploying is a big part of the lives of most GitHub employees. We don't have a release manager and there are no set weekly deploys. Developers and designers are responsible… Deploying is a big part of the lives of most GitHub employees. We don’t have a release manager and there are no set weekly deploys. Developers and designers are responsible for shipping new stuff
GitHubは普通の会社とどう違うのか? リリースマネージャーがいない(いる必要がない) 週次のデプロイセットもありません(この週にこれだけの機能をまとめてリリースとかがない) 開発者とデザイナーは、早く提供できるように自分たちでデプロイする(できる)作った人達が自ら確認できて、サクッとデプロイできるのであれば、さっさと作って、ささと出してしまった方が良いに決まっています。これを実現させるために様々な工夫がされているようです。 GitHubの基本的なワークフロー The basic workflow goes like this: Push changes to a branch Wait for the build to pass on our CI server Tell Hubot to deploy it Verify that the changes work and fix a
"米国人からコーディングについての怒りのメールを頂戴した" の補足 - その手の平は尻もつかめるさ ↑の方で補足いたしました。(2012.09.04 追記) 最近、英語のメールでよく怒られます。moznion です。 海を隔てて共同作業しているアメリカ人から、僕のコーディングについてお叱りのメールを頂いたので、 自戒の念を込めて邦訳して記します。 書いてあることは「当然」とも言うべき内容ですが、僕はその「当然」も守れていなかったのかぁ〜と反省。 以下、邦訳(意訳)です。 1. 郷に入っては郷に従え 既にソースコードが存在しているって事は、そこには同時にコーディングスタイルも存在しているってことだ。 その既存のソースコードに手を加える場合、別のコーディングスタイルを導入してはならない。 もし君がバックエンドのソースコードを弄っているなら、バックエンドのコーディングスタイルで記述するんだ。 フ
オペレーションとかインフラ系のエンジニアリングからは少々離れそうなので、個人的な備忘録がてら、Gitのブランチモデルについて。淡々と書くよ。 見えないチカラ: A successful Git branching model を翻訳しました 基本的に、このA successful Git branching model(上記は翻訳記事)を参考にしています。ですが、完全ではありません。運用しながら都合よく省略していますし、悪く言えば曲解もしています。あくまで、わたしが都合良く解釈して取り回した結果と考えてください。 さて、このようなドッシリとしたブランチモデルが、あらゆる規模のプロジェクトに対して有効であるかといえば、もちろんそうではありません。コツコツ個人で開発しているライブラリなどは、ブランチを使わなくても良いケースがあるでしょうし、作ってもバージョン番号ブランチぐらいのケースだってザラ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く