LINEが開発体制、グローバル対応の秘策、サービス基盤の変遷を解説
唐突な Diff に負ける - @kyanny's blog
目的はわかったけどどうしてこの変更で達成できるの？がわからない、文脈が抜け落ちている Diff というのがある。唐突な Diff、と呼ぼう。 唐突な Diff との戦いには二種類ある。 一つは自分が唐突な Diff を作らない、という戦いで、ちょっと込み入ったバグ修正など、変更する箇所は少ないがそのぶん意図がわかりづらくなる場合。自分はバグの原因を解明する過程で関連するコードを読み込んでいるので「流れ」を把握できているが、レビュアーが Diff そのものから全体像を思い描くのは難しい。リグレッションテストを追加してもやはり文脈なしでは説明不足だ。そういうときはコメントを丁寧に書き、場合によっては関連コードのリンクを添えつつステップを順に説明したりする。これにはそれなりに手間と時間がかかる。 もう一つは唐突な Diff に出会ったときちゃんと質問する、という戦いで、「なんだこれは？」と言いた
クックパッドモバイルアプリの開発体制とリリースフロー - クックパッド開発者ブログ
こんにちは、技術部モバイル基盤グループの @slightair です。 今回は、クックパッドのモバイルアプリをどのような流れで開発しているか説明したいと思います。 この記事では技術的な話ではなく、どのようにして、どのようなことを考えて僕らがモバイルアプリを開発しているかに触れたいと思います。 開発体制 クックパッドにはモバイルアプリを専門で開発するようなチームはありません。 必要に応じて、誰でもモバイルアプリ開発に取り組みます。 機能追加・修正を行ったらリポジトリにプルリクエストを送ります。 プルリクエストが来たら、アプリ開発を行うエンジニア同士でレビューします。 様々な修正をひとつのバージョンにまとめるのは、僕が所属する技術部と後述するリリースマネージャーで行います。 リリースマネージャー バージョンごとに、そのリリースの責任をもつリリースマネージャーをひとり選びます。 リリースマネージ
開発組織のマネジメント
フロントエンドのパラダイムを参考にバックエンド開発を再考する / TypeScript による GraphQL バックエンド開発
GitHub Kaigiへ行ってきた - ただのにっき(2014-06-01)
■ GitHub Kaigiへ行ってきた GitHub Kaigiの開催案内をTwitterで見かけてなんの気なしに申し込んだら、その後あっという間に300席がうまって、その後500人へ拡大してもなおキャンセル待ちがあったとか。東京のエンジニアの勉強欲は異常や。いつものようにRubyist時間に到着したらもうすっかり席が埋まっていて、最後方入り口近くの椅子をなんとか確保*1。会場になったサイバーエージェントのセミナールームには何度か行っているけど、こんなに人が詰まっているのを見たのは初めてだ。 最初は「GitHub実践入門 ─ Pull Request による開発の変革」だったのだけど、のっけから「あれれれれ?」って感じだった。GitHubでもたらされたとされている「変革」が、どれも(GitHub登場前からの)ごく当たり前のプラクティスに見えたからだ。おかしな変数名に対してレビューアが対案
スケールする開発組織の作り方 #jawsug
フロントエンドのパラダイムを参考にバックエンド開発を再考する / TypeScript による GraphQL バックエンド開発
GitHub 時代のデプロイ戦略 - naoyaのはてなダイアリー
少し前までアプリケーションのデプロイと言えば capistrano などをコマンドラインから叩いてデプロイ、みたいなことをやっていたが、最近は少し様子が違うのでそのやり方、KAIZEN platform Inc. での事例を紹介する。 GitHub のイベントを契機に CI as a Service にデプロイを担当させる GitHub で Pull Request を送って開発するのが前提になっているのは以前にも紹介した。 最近は Travis CI や CircleCI などに代表される CI (Continuous Integration) as a Service があって、CI も自分たちで環境を構築しなくてもクラウドに任せることができる。KAIZEN では CircleCI を積極的に使っている。 これらの CI as a Service は基本的に GitHub と連携するこ
コードレビュー - hitode909の日記
コードレビュー，慣れるとできるけど，いきなりdiffを渡されて，どうぞ見てくださいと言われてもよくわからないと思う． やりましょうというのはいいけど，ただむやみに読んでもうまくいかない．変更がある程度大きくなるとdiffだけ見てもよくわからないので，いろいろ見ることになる． 僕はいつも以下のようなことを無意識にやってて，うまくいってる気がしてる．GitHubのPull Requestの仕組みを使ってる前提で． Discussionをさらっと眺めてどういう問題を解決したいのか見る Commit Statusを見て，テスト通ってることを確認する Commitsタブで1コミットずつブラウザの新しいタブに開く 全部クリックし終わったら古い順に1コミットずつ読む 気になる点があったらエディタとかにメモしておく．あとで書き直されるかもしれないので，まだコメントしない 全コミット見終わったらFiles
プルリクエストに対するすごいレスポンス
プルリクエストへのすごい返信が話題になっていました。 ファンクショナルテスト用にSQLiteのサポートを追加 後でみます。というかだいぶ後になりそう。僕はウクライナ人なんだけど、今革命が起きているので。 気をつけて！ 良い革命を！ GitHub上のコミュニケーションなので軽い内容ですが、ウクライナでは本当に武力衝突が起きておりオープンソースの広がりと同時に世界の広さも感じます。 追記: 問題のプルリクエストのコメント欄はちょっとしたお祭り状態です。 https://github.com/fre5h/DoctrineEnumBundle/pull/12 via:https://twitter.com/andrey_butov/status/426018565561401344
はてなやクックパッドの開発現場で、CIやテストはどう行われているのか？（前編）。CROSS 2014 － Publickey
Web技術について横断的に語り合うイベント「CROSS 2014」が1月17日、都内で行われました。 そのセッションの1つ「現場に聞く！テスト/CI/DevOps、実際のところどうなの」では、フリーランスエンジニアの伊藤直也氏がセッションオーナーとして司会を担当し、クックパッドで開発まわりのエンジニアをしている舘野祐一氏、はてなでアプリケーションエンジニアをしている伏井洋平氏、KAIZEN platform Inc.の石橋利真氏らがスピーカーとして登壇。 先進的な現場でテストやCIがどのように行われ、エンジニアのチームがどのように情報共有をしているか、本音で語るという注目すべき内容でした。本記事ではそのダイジェストを紹介しましょう。 現場に聞く！テスト/CI/DevOps、実際のところどうなの 伊藤 今日のテーマとしてはCI（Continuous Integration、継続的インテグレー
コードレビューを円滑に行いたい (#cross2014 のお話) - $shibayu36->blog;
id:antipopさんやid:studio3104さんに機会をもらえて、CROSS 2021に参加させてもらい、はてなでのレビューの話を軽くさせてもらった。はてなからは僕とid:hakobe932さんとで参加した。 http://blog.kentarok.org/entry/2014/01/18/204552 2014/1/17 #cross2014 コードレビューCROSS 〜ぶつかり稽古 2014初場所〜 - Togetter それで、今回参加して他の会社の人のレビューの話も聞いて、あーそれはあるあるとか、そういう問題解決するためにこういうことしてますとか、他の会社ではこういう時どうしているんだろとか、幾つかおもうところがあったので、もう少しレビューのことについて書いてみる。 レビューと関係性問題 レビュアーとレビュイーの関係に関して - 職質アンチパターン コードレビューと関係性
はてなブログチーム エンジニア座談会 - 株式会社はてな
2013年11月20日アプリケーションエンジニアはどのように仕事をし、どんなことを大切にしているのでしょうか。はてなでは、さまざまなサービスの開発を、複数のチームに分かれて行っています。サービス開発の現場で、はてなブログやはてなダイアリーを開発する「はてなブログチーム」から、id:onishi、id:hitode909、id:shiba_yu36、id:cockscombの4人に話を聞きました。 左からid:shiba_yu36、id:hitode909、id:cockscomb、id:onishi はじめに─本日は、はてなブログチームからプロデューサー兼ディレクターのonishiさん、そしてアプリケーションエンジニア3名にお集りいただきました。はてな社内にはいろいろなチームがありますが、特にブログチームではこのように開発している、という話をお聞きしたいと思います。よろしくお願いします。
Webサービス開発現場から / 近頃の開発のやり方 ･･･ Github と Pull Request とコードレビュー - naoyaのはてなダイアリー
先日プレスリリースが出たのですが、KAIZEN platform という会社で技術顧問などをやっています。それから、一昨日自分も出たWebアプリケーション開発に関する勉強会 (資料) を開いたじげんという会社でも少し前から同じように顧問のような形で携わっています。 自分が関わっている会社のPRも含めて、すこし、2013年現在のWebサービス開発の現場感、やり方みたいなものを書いてみたいと思う。ただ、自分の利益があるところの話だけではフェアではないので、Webエンジニアならよく知っているであろう Qiita を運営しているインクリメンツの様子も合わせて紹介する。 KAIZEN platform KAIZEN platform が提供しているサービスは planBCD という A/B テストの SaaS で、Webサイトのコンバージョンだとかを画面の構成要素を変えて効果測定したいとか、そういう
「GitHubでつくる、たのしい開発現場」YAPC:ASIA Tokyo2013 | Act as Professional
YAPC::ASIA Tokyo 2013（2日目）で「GitHubでつくる、たのしい開発現場」というトークをしてきました。 まず、利用した資料を公開します。 伝えたいことコードレビューを習慣化させたいのであれば、GitHubは最適なツールです。 コードレビューを習慣化させたい コードは書いた人以外の目にふれさせるべきと考えている人には特にオススメのツールです。 ですが、GitHubはあくまでツールです。このツールを利用することで、コードレビューの機会や良いコードを書くためのノウハウを学習する機会を生み出すことができます。 その結果、人やチームが行動を起こすことでチームが成長したり、結果として良いソフトウェアができていくはずです。 レビューをすると増えるコスト、減るコストレビューはすべきだけど、現在レビューを習慣化できていないチームにとって、新たにコードレビューをしていくのは単に時間的なコ
自分のいるブランチが他の人によってforce-pushされたとき，カレントブランチを削除せずに変更を取り込む - Qiita
自分のいるブランチが他の人によってforce-pushされたとき，カレントブランチを削除せずに変更を取り込むGit 例えばレビュー中に小さなバグを見付けたので，レビュイーにpush -fしてもらった後にその変更を手元に持ってくるにはどうすればよいか．歴史が変わっているのでgit pullはできない． 今までは以下のように別ブランチに移動&削除&再度ブランチ作成していた． # someone force-pushed to `topic` branch git co master git branch -D topic git fetch git co topic # creates `topic` branch from `origin/topic`
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Reviewable - GitHub Code Reviews Done Right
はてなブログチームの開発フローとGitHub
Cookpad's deployment and auto scaling
「何故クックパッドのサービス開発は日々進化しているのか」という発表をしました。 - yoshiori.github.io
GitHub - shimobayashi/pull-req-label: pull-reqにレビュー中とかラベルを設定する。
