マイクロチームでの高速な新規開発を支える開発・分析基盤 by @__timakin__ Builderscon2017でのプレゼン内容です。
マイクロチームでの高速な新規開発を支える開発・分析基盤
マイクロチームでの高速な新規開発を支える開発・分析基盤 by @__timakin__ Builderscon2017でのプレゼン内容です。
bliki: Feature Flag
One of the most common arguments in favor of FeatureBranch is that it provides a mechanism for pending features that take longer than a single release cycle. Imagine you are releasing into production every two weeks, but need to build a feature that's going to take three months to complete. How do you use Continuous Integration to keep everyone working on the mainline without revealing a half-impl
KPTで粘り強く品質改善に取り組んだ話 - クックパッド開発者ブログ
はじめに こんにちは、モバイルファースト室の@y_310です。 部署名からもお分かりの通りクックパッドでは今年からスマートフォンアプリの開発に特に力を入れて取り組んできました。 実際に昨年と比べて開発体制が大きく変化しています。以前はアプリ開発専門のエンジニアのみで開発していたものを、サーバサイドエンジニアもアプリ開発を学び、自分が所属する部署に必要な機能をアプリに実装するようになりました。 そのため、以前は2、3人のチームでの開発だったものが、現在は多い時には複数の部署にまたがって10人ほどのエンジニアが1つのアプリにコミットする状況になりました。 そのような環境の変化によりアプリの品質維持が大きな課題となり、この半年間継続的に品質改善に取り組んできました。今回はその改善プロセスについてご紹介したいと思います。 課題 取り組みを始める前は、様々な部分で課題がありました。 具体例を上げると
徹底討論！社内の技術情報共有ツール - GitHub Wiki, Qiita:Team, esa.io （特別編：トップエンジニアたちの夜 『シドニアの騎士』観賞会＆座談会 ～Part4～） | Tokyo Otaku Mode Blog
こんにちは、ライターの岡田大です。 お待たせしました。特別編「トップエンジニアたちの夜」のPart4をお届けします。 ※Part1～3未読の方＆内容を忘れてしまった方は、Part1・Part2・Part3を一読してからお楽しみください！ リモートワークを成功させるために必要なモノとコトについては前回お伝えした通り。ルールとマナーなくして成り立たないことは言うまでもなく、そのことをメンバー（とくに新人）に徹底させるために、リモートワークを積極的に導入している伊藤氏は、ガイドラインをドキュメント化することにより意識の共有を図っているという。その際に活用しているのが、技術情報共有サービスQiita:Teamである。堀木氏の口から「Qiita:Team」という言葉が発せられるやいなや、参加メンバー一同がこれに食いつき、座談会はチーム内における情報共有に関する話題で持ち切りになっていった……。なお、
Rails3で作り始めたアプリケーションをちょっとずつ改善してゆく道のり
#rubyhiroba の生活発表会で話した内容です
わかりやすいREADME.mdを書く
GitHubなどに自分のツールやライブラリを公開するとき，README.mdは重要な役割を担っている．レポジトリを訪れたユーザが自分のツールを使ってくれるか否かの第一歩はREADME.mdにかかっている，と言っても過言ではない．実際自分が使う側になったときも，まずREADME.mdを読んで判断していると思う． 成功しているプロジェクトを参考にしつつ，自分が実践していることをまとめておく．ここに書いていることはあくまで（自分の中で）最低限的なものである．プロジェクトが成長していくにつれてREADMEはあるべき姿に成長していくべきだと思う． READMEの役割 README.mdには大きく2つの役割がある． プロジェクト，ツールの使い方，インストール方法 プロジェクト，ツールの宣伝 元々READMEは前者の役割しかなかったが，GitHubの仕組み上，後者の役割も徐々に重要になっている． さらに
伊藤直也が語る「仕事の流儀」第3回──OSSプロジェクトのように組織をつくる｜CodeIQ MAGAZINE
伊藤直也氏が語る「仕事の流儀」の第3回は、暗黙知を作らない組織の作り方。オープンソースのスタイルで組織を作ればいいという直也氏は、KAIZEN platform Inc.において、どのような行動をとっていたのか。 ある取り組みによって、KAIZEN流の行動哲学が生まれたという事例をもとに語っていただいた。 by 馬場美由紀 （CodeIQ中の人） 暗黙知を作るな、すべてを形式知に変えよ 前回は、Sqwiggleを活用したリモートワークやGitHubを活用した開発について述べました。 開発プロセスは、まあアジャイル開発っぽいですね。アジャイル開発というか、スクラムで求められている他のプラクティスについて、KAIZENのリモートワークではどのようにやっているかをもう少し説明すると、まずデイリースタンドアップ、いわゆる朝会です。リモートでやってるので、スタンドアップといいつつ立ってはいないんです
今のコードレビューのやり方 - $shibayu36->blog;
コードレビュー - hitode909の日記 この話。 大体こういう風なやり方をしてる。Diffだけを見るんじゃなくて手元でもコードチェックアウトしてて、それとDiffを行ったり来たりしながらレビューすることが多い。こういう方法のほうがかっこいいよねみたいなのは書くけどその通りにしてもらうことを強制はしないというのも賛同。 逆にcommitの中身*1はあえて見ないようにしてる。僕はレビューする時に、そのコードについての学習が行われていない状態で見たほうが良いなと思っている。commitの中身を１つずつ見ていくと学習が進んでしまって、少しわかりづらいコードもあっても、学習が進んでいるせいで無意識に目からすり抜けてしまうという経験があったので、あえてcommitみないということをしてる。 例外もあって、少し大きめなリファクタリングが行われた時はcommitを１つずつ読んでいくことが多い。少し大
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
