うそのアジャイル、まことのアジャイル 公開用
1. うそのアジャイル、まことのアジャイル ～アジャイル開発はこうして形骸化する～ 2016/1/22 12002-2016 Eiwa System Management, Inc. 株式会社永和システムマネジメント コンサルティングセンター センター長 天野勝 http://www.esm.co.jp/service/consulting/ 2. 2001年に「アジャイルソフトウェア開発宣言」がされ てから、15年が経ちました。 「アジャイル」という考え方は、ソフトウェア開発の枠 を飛び越え、ビジネス領域へと拡張されており、多く の支持を得ることができています。 しかしその一方で、アジャイル開発に取り組み、失 敗をしている例も増えてきています。 このような事例から、皆さんがアジャイル開発とど のように付き合うべきかを考えるきっかけになれば と考えております。 22002-
スケールする開発組織の作り方 #jawsug
フロントエンドのパラダイムを参考にバックエンド開発を再考する / TypeScript による GraphQL バックエンド開発
複数プロジェクトを抱えるチームでのデプロイ自動化
複数プロジェクトを抱えるチームでのデプロイ自動化 1つのチームで，10以上のプロジェクト，コードベースを抱える場合にどのようにデプロイの自動化を進めたか，工夫したこと，考慮したことなどをまとめておく． デプロイツールには，Python製のfabricを採用しているが，他のツールでも同様のことはできそう．なお，fabricの基本的な使い方などは既にインターネット上に良い記事がたくさんあるので書かない（最後の参考の項を見てください）． fabricの選択 シェルスクリプトとCapistranoを考慮した． まず，シェルスクリプトは人によって書き方が違うため，統一が難しくメンテナンスコストも高い．また共通化も難しい． 次に，Capistranoは，裏でやってくれることが多く，学習コストも高い．プロジェクトによってはかなり特殊な環境へのデプロイも抱えているため，Capistranoの前提から外れる
下から目線のコードレビュー - steps to phantasien
WEB+DB の新しいやつがちょっと前にでてます. コードレビュー特集だそうな. 時が経つのは早い. まだ次の原稿書いてないのに… そういえば前にコードレビューの話を書いた気がして, 見なおしたところ かきかけ だった. せっかくなので続きを書いてみることにします. といっても何書くつもりだったか覚えてないのでだらだらと. WEB+DB PRESS の特集は, 主にこれからコードレビューを導入したい人に向けて書かれている. 幸か不幸か私はコードレビューを義務付けれたプロジェクトで働いているため, 導入には苦労していない. かわりにレビューをちょろまかせない面倒はある. ある意味でコードレビューを <やらされている>. もちろんこの言い分は大げさだ. 必要性に異議を唱える気はない. ただ異議はさておき自分の意向とは無関係にコードレビューに参加している気分を書いた話は あまり目にしないので,
インフラ系技術の流れ - Gosuke Miyashita
ここ最近のインフラ系技術の流れがおもしろいなー、と思ったので、Puppet が出た辺りぐらいから、振り返って整理してみる。殴り書きなので、後から修正したり書き加えたりするかも。特に後半の方は、あまり考えが整理できてない。 最近のウェブ界隈での「インフラ」という用語の使われ方には、色々異論もあるようだけど、ここではごく最近使われるようになってきた、OS からミドルウェアといったソフトウェアレイヤーを指す言葉としてのインフラについて触れる。（英語圏でも同様の意味で使われているようなので、ある程度市民権を得たと言っても良さそうだし。） プロビジョニングレイヤー まず、前提知識としてプロビジョニングレイヤーと自分が勝手に呼んでるものについて整理。 Chef や Puppet は「プロビジョニングフレームワーク」とも呼ばれているが、以下の議論をより厳密にするために、Lee Thompson 氏による
大きなリリースの際にチェックすべき34のこと
アジャイル開発に取り組むチーム向けのコーチングや、技術顧問、認定スクラムマスター研修などの各種トレーニングを提供しています。ぜひお気軽にご相談ください（初回相談無料） 以前に作っておいた大きめなリリースをする際にチェックしておくべきことのリストが役に立ちそうなので公開しておきます。 僕の場合は普段はワンクリックデプロイが多いんだけど、かなり大掛かりな変更をするケースが年に数回あったりするので、その際にこういうリストを使ってリリース計画をチェックしています。(もちろん大掛かりなリリースでもワンクリックでできるのに越したことはないし、そもそもビッグバンリリースにならないようにできるだけ小さい単位で頻繁にリリースできるに越したこともない) 体制当日の体制は決まっているか夜間立会いの場合、日中の営業時間の対応体制は決まっているか翌営業日以降の体制は決まっているか連絡担当と作業担当は分離されているか
ロードマップ指向とエコシステム指向 - アンカテ
IT業界の世代間ギャップを「ロードマップ指向 VS エコシステム指向」という図式でまとめるとうまく整理できるような気がしてきた。 他の業界でも、常に勉強してないと仕事にならない所では、似たような問題があるかもしれない。普通の人は「ロードマップ」の中では真ん中を進むべきで、「エコシステム」の中では真ん中を避けるべきだ、という話。 私は、80年代からずっとプログラマをしていて、今でも現場でコードを書く仕事をしているので、同世代の人から、彼らと現場の若い人との仲裁役というか通訳のようなことを期待されることが多い。 確かにそこには微妙なギャップがあって、自分はどちらの言い分にも共感する所があるので、なんとかそれを言葉にしたいのだが、なかなかうまく言えなかった。 プログラマという仕事は、今も昔も勉強をしてないと普通の仕事も成立しないのだが、その勉強の仕方というか意味づけが、違ってきていると思うのだ。
packageごとのメモリ使用量(と増分)を確認できる Plack::Middleware::MemoryUsage - （ひ）メモ
packageごとのメモリ使用量とリクエストを処理する前後の増分を確認できるPlack::Middlewareを作りました。 時間が経つとぶくぶく太るプロセスがいるときに、犯人特定の助けになると思います。 https://github.com/hirose31/Plack-Middleware-MemoryUsage 要、B::TerseSizeB::Size2::Terse, Devel::Symdumpです。 新しめ(5.10以降？)のPerlでB::TerseSize (B::Size)がエラーになってインストールできないときは、 https://github.com/gfx/p5-B-Size-patched のを入れてください。 https://metacpan.org/module/B::Size2 を入れてください。 使い方は、 use Plack::Builder; bui
高速にWeb開発をするために便利ないくつかのTIPS - KAYAC Engineers' Blog
outputz でいまだに1位になれたことがない村瀬です。 社内で開発をスムーズにするための tips 集を紹介したので、まとめておきます。 記事ではデモができないので便利さが伝わらない物も多いですが参考になれば幸いです。 screenとかzshとか便利だよ！と言う話は社内ではさんざんしているのでありません。 また、OSX 限定の内容もあります。 でははじめましょう。 keychain keychain と言っても OSX の KeyChain ではなく、コマンドラインのツールです。 これは ssh-agent をより便利にするためのラッパーです。これを使用すると ssh の秘密鍵のパスワードを一度入力するとあとはパスワードなしで ssh 接続できるようになります。 「同じこと二回も言わせんな！」といつも切れているような人は導入すると良いでしょう。 使い方は $ keychain ~/.s
ぼくが実際に運用していたGitブランチモデルについて
オペレーションとかインフラ系のエンジニアリングからは少々離れそうなので、個人的な備忘録がてら、Gitのブランチモデルについて。淡々と書くよ。 見えないチカラ: A successful Git branching model を翻訳しました 基本的に、このA successful Git branching model（上記は翻訳記事）を参考にしています。ですが、完全ではありません。運用しながら都合よく省略していますし、悪く言えば曲解もしています。あくまで、わたしが都合良く解釈して取り回した結果と考えてください。 さて、このようなドッシリとしたブランチモデルが、あらゆる規模のプロジェクトに対して有効であるかといえば、もちろんそうではありません。コツコツ個人で開発しているライブラリなどは、ブランチを使わなくても良いケースがあるでしょうし、作ってもバージョン番号ブランチぐらいのケースだってザラ
「開発者のためのリーン・スタートアップ」「リーン・キャンバス入門」の資料を公開します - Kentaro Kuribayashi's blog
隣席のるびりすと氏(@hsbt)と僕とで、この半月ほど、東京・福岡で合計3回にわたって勉強会ツアーをやっていました(その他のこともたくさんやっていたので、それだけではもちろんないのですが)。今日でそれもひと通り終わったので、どのようなことをやっていたのかについて、ここで公開したいと思います。 我々の話はどの回も以下の順番で行われており、いわば三題噺みたいな構成となってます。 リーンスタートアップ インセプションデッキ Scrum それは、我々が議論している模様を撮った以下に掲げた写真に見られるように、開発プロセスというものが階層的な構造を持っているからです。 www.instagram.com ここでは、その最初の話「開発者のためのリーン・スタートアップ」および「リーン・キャンバス入門」のスライドを紹介します。 開発者のためのリーン・スタートアップ 僕は技術者です。また、技術者としてさらな
炭坑の庭師 - steps to phantasien
Chromium と WebKit は二つの独立したプロジェクトだ。 ソースツリーはそれぞれ別で、そこにはインテグレーションの苦労がある。 WebKit 以外にも V8 や Skia など Chromium が依存している外部のプロジェクトは山ほどあるけれど, WebKit とは特にぴったりくっついている。 そのぶん二つの足並みをあわせる手間も際立つ。 以前、書籍 ”アジャイル開発の本質とスケールアップ” で リリーストレイン という大規模プロジェクトのインテグレーション手法を読んだ。 プロジェクトの内部で一段細かい時限リリースを設け、そのタイミングでインテグレーションする方法。 内部リリースにあわせてプロジェクト同士が依存している相手のバージョンを上げ、 壊れたところをなおすわけ。 Chromium と WebKit もこまめに相手のバージョンを新しくする。 主たる依存の向きは Chro
テスト戦略、設計、手法、技法などなどのリンクをまとめてみた - うさぎ組
WACATE 2011 夏に申し込んだので、おさらいしましょう。ということでテスト手法、テスト技法を中心としたリンクをまとめてみました。 なので今回はTDDとかテストツールとかはあまり含まれていません。 いくつかかぶっているものもありますが、多面的な表現って大切だと思うので、多少のかぶりは気にせずに選択しました。 これを読めば良いソフトウェアエンジニアとして一歩階段を上れる気がしています。 他にも参考になるものがあったら、コメントやTwitterで@kyon_mmまで教えてくださるととっても嬉しいです！ 次の形式で書いています。 WEBサイト名、資料名：発表者（敬称略）：URL カテゴリー分けしたんですが、不適切であるかもしれません。間違い等あればご指摘ください。 また、ここでのリンクに問題がある場合は削除致しますので、その場合もご指摘ください。 TwitterID:kyon_mm mai
テスト駆動開発チートシート - やさしいデスマーチ
TDD（テスト駆動開発）のチートシートを作ってみた。 TDDBCでid:t-wadaさんが話している内容とかテスト駆動開発入門から引っ張ってきています。 ダウンロードはこちらからどうぞ。 PNGイメージ: http://dl.dropbox.com/u/1393956/tdd_cheatsheet.png PDFファイル: http://dl.dropbox.com/u/1393956/tdd_cheatsheet.pdf 追記 印刷・再配布などはご自由にどうぞ。 もし、元データ（OmniGraffle）が欲しいという人は、コメント欄かTwitter経由で教えていただければ差し上げます。 追記２ このチートシートは、OmniGraffleで作りました。他に使えそうなツールとしては、イラレとか。Visioでもたぶん作れると思います。
プログラミングと設計は本来切り離せないものなのでは - 達人プログラマーを目指して
最近はアーキテクトという役割で客先に常駐し、フレームワークの選定をしたり、事前に共通部品を設計したりする役割を担う仕事を引き受けることが結構あります。そこで運よくお客様のマネージャーがオブジェクト指向開発の経験が十分にある方だと、IDEなどの開発環境やインターネット接続環境を当然のように用意してくれるので最初から仕事がスムーズにできるのですが、そうでないとMS Officeしか入っていないロースペックのノートPCを渡されて、要件定義フェーズの期間中、フレームワークの設計をお願いしますとか、私としてはちょっと首をかしげてしまうような困ったことを言われてしまう場合があります。開発フェーズが始まる半年後まではコーディングは基本的に不要という考え方です。アプリケーションのアーキテクトという役割では少なくともコーディング規約を考えたり、ツールやフレームワークの選定をしたりする必要がありますし、プロジ
最近興味深いと思ったWeb記事のリンク集 - give IT a try
社内のメンバーに紹介しようと思ってためてきた各種Web記事へのリンクが大量に溜まっちゃいました。 ついでにここでも紹介しておきます。 一部の記事は会員登録が必要かもしれません。あしからず。。。 プログラミング/プログラム設計 プログラミングについてあまり知られていない７つのこと http://www.tommyjp.com/2010/08/blog-post_1710.html => どれも超重要。知らなかった人はこれを機に覚えておきましょう。 ソースコードの質 http://el.jibun.atmarkit.co.jp/genmaicha/2010/11/post-5c3e.html => 保守性、可読性、拡張性の重要性について。 技術的負債 http://d.hatena.ne.jp/asakichy/20101210/1291936604 => 技術的負債の原因や解決策について(そ
Googleエンジニアから学ぶ、ハッカーになるための勉強法 - 久保清隆のブログ
Debian Project／Google ソフトウェアエンジニア鵜飼文敏さんの講演動画を見たのでまとめ。 内容は、フリーソフトウェア、オープンソフトウェアのハッカー、Google内のハッカーがどのようにソフトウェアを作っているか。 少し前の講演だけど、ハッカーを目指す上で非常に参考になった。 ハッカーの特徴 ハッカーとは Hacker ethic ハッカーのソフトウェアの作り方 ハッカーの開発スタイル 手順 要求仕様 設計 実装 テスト デバッグ チューニング ハッカーに近づくには 必要な知識 知識の習得の仕方 ハッカーと仕事をするときの問題点 その他に紹介されていた書籍 感想 参考 ハッカーの特徴 普通の人をはるかに上回る高い生産性 高品質のソフトウェアを作りだす ハッカーとは ハッカーズ大辞典によると、 プログラム可能なシステムの細かい部分を探ったり、その機能を拡張する方法を探求した
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
はてなブログチームの開発フローとGitHub
クックパッドはなぜ開発しやすいのか // Speaker Deck
とあるアプリの開発運用(トラブルシュート)
