モダンな現場にするために実践したことDevLove現場甲子園2014東日本大会での発表内容です。
B2Bサービス開発の現場から #devsumi
フロントエンドのパラダイムを参考にバックエンド開発を再考する / TypeScript による GraphQL バックエンド開発
伊藤直也が語る「仕事の流儀」第3回──OSSプロジェクトのように組織をつくる｜CodeIQ MAGAZINE
伊藤直也氏が語る「仕事の流儀」の第3回は、暗黙知を作らない組織の作り方。オープンソースのスタイルで組織を作ればいいという直也氏は、KAIZEN platform Inc.において、どのような行動をとっていたのか。 ある取り組みによって、KAIZEN流の行動哲学が生まれたという事例をもとに語っていただいた。 by 馬場美由紀 （CodeIQ中の人） 暗黙知を作るな、すべてを形式知に変えよ 前回は、Sqwiggleを活用したリモートワークやGitHubを活用した開発について述べました。 開発プロセスは、まあアジャイル開発っぽいですね。アジャイル開発というか、スクラムで求められている他のプラクティスについて、KAIZENのリモートワークではどのようにやっているかをもう少し説明すると、まずデイリースタンドアップ、いわゆる朝会です。リモートでやってるので、スタンドアップといいつつ立ってはいないんです
Webサービス開発の変遷と現在
フロントエンドのパラダイムを参考にバックエンド開発を再考する / TypeScript による GraphQL バックエンド開発
KAIZEN platform Inc. の開発マネジメント
フロントエンドのパラダイムを参考にバックエンド開発を再考する / TypeScript による GraphQL バックエンド開発
SmartNewsにおける開発の考えかた
【StartupWeekendTokyo x DevLOVE】イケてるスタートアップの開発現場の話が聞きたい！ http://swtokyo.doorkeeper.jp/events/12769
KAIZEN platform Inc. における運用自動化
フロントエンドのパラダイムを参考にバックエンド開発を再考する / TypeScript による GraphQL バックエンド開発
Hubotを導入したらレビューの敷居が下がった話 - yo_waka's blog
ウチの会社ではHipchatとGitHubを開発のコミュニケーションの中心にしている。 だんだん人も増えてくると、以前よりプルリクの数がそれだけ増えて、レビューで1日終わってしまう人がでてきた。 昔から仕様を知っている人にレビューが投げられがちで集中しやすいとかは他の会社でもよくある話しだと思う。 レビューは自分のタスクと同様に大事だけど、それで自分のタスクが全くできなくなったり、新しく入ってきた人がレビューする機会を失うのはあまりよくない。 というのもあって、Hubotを立ててみてプルリクのレビュアーをランダムで振れるようにしてみた。 Hubotというのはご存知Hipchatのbotとして動くプログラムで、botにコマンドを指定してリモート実行させたり、特定の文字列に反応させたりということがHipchat上でできる。 CoffeeScriptでスクリプト書けるのでとてもお手軽。 sush
情報共有おじさん - ローファイ日記
「プロジェクト全体のMLにエラー通知メール飛ばすのうざい」、「〜についてはみんながいるチャンネルで相談すべきことではない」みたいな指摘がある。 個人的には情報は可能な限り広いスコープで公開してほしいし、自分でもそうしようとしている。まだ未熟なので霊力に負けることもあります...。 というのも、「情報が届いていない」ことによる不利は仕事上非常に大きいし、場合によって致命的になるので、むしろ冗長化して届けられているべきなのである。 あと、情報が多ければ多いほど普通は判断が適切になると思うので、情報が広く共有されていると言うことは、チームメンバー一人一人が自分で判断できる材料を持ちやすくなると言うことにもつながる。スクラムとか色々言われているけど「一人一人が自分で判断できる」ということはどういう開発スタイルでも大事だと思う。 なのでむしろみんながいる場で議論していたり、細かい情報をどんどん流して
開発環境の情報共有会でDash,SourceTree,Alfredの話をした - Glide Note
社内で開発環境についての情報を共有する会を開催した。 参加者全員が発表のスタイルで、ただ聞いてるだけの人がいないようにしたら いろいろな情報を共有出来て大変参考になった。 私は1日のほとんどをターミナル上で過ごすので、ここ数年GUIアプリにはあんまり関心が 無かったんですが、最近導入して便利だったやつを共有したら好評だったのでまとめておく。 Dash Dash - Documentation Browser, Snippet Manager - Kapeli ドキュメントブラウザ、スニペット管理ツール。ドキュメントをローカルにダウンロードして 利用するので高速。今日(2014/03/29)時点で130以上のドキュメントとAPIに対応していて、 プログラミング言語に加えて、MySQL、MongoDB、Puppet、Vagrantなどのドキュメントもある。 自作ドキュメントを追加することも可能
なぜ開発で見積り失敗して忙しくなりがちなのか(アジャイルな見積りと計画づくり読んだ) - $shibayu36->blog;
最近タスクがどのくらいで終わるか見積もることが多いんだけど、そのたびにうまく見積もりができてなかったり、思ったより長引いてしまってすごく忙しくなってしまったり、といったことが何度かあった。このままじゃ良くないなーと思って、「アジャイルな見積りと計画づくり」を読んだ。 アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~ 作者:Mike Cohn,マイク コーン毎日コミュニケーションズAmazon 実際読んでみると今の状況に非常にぴったりで良い本だった。この本を読んでいくと、最初から正確な見積りをするのは不可能で、作業をしながら見積りの精度をあげるといったり、変更やリスクに強いスケジュールをうまく作るということをしていく必要があるということが分かる。なんとなく自分がタスク管理をしないといけなくなったけど、なんかうまくいかないと思っている人には非常に参考になると思う。あと
ホーム - CloneTracker
当社はCookieを使用して、お客様が当社のWebサイトでより良い体験を得られるようにしています。引き続き閲覧する場合は、プライバシーポリシーに同意したことになります。
レビュータイムの導入・消滅・再導入 - $shibayu36->blog;
今日こんなかんじの会話があって、レビュータイム導入した時のことを思い出したので、適当に書こうと思う。 ひさいちレビュー、必ず通すみたいなの良いのか悪いのか— ひさいち (@hisaichi5518) 2014年3月13日 @hisaichi5518 マジレスすると、そのような体制にしておくとスケールしないので、最初の段階では必ず通すというルールにしつつ、他の人がレビューしても大丈夫に出来るように、レビューの練習を同時にしていってもらうとしないといけなさそう— 柴崎優季 (@shiba_yu36) 2014年3月13日 @hisaichi5518 今のチームで新人が入った時は、レビュータイムというのを必ず設けてその時間には最低限どれか一つレビューするというのをやってもらってる。でも慣れるまではこれまでチームにいる人がレビューしないとmergeしないということにしてる。— 柴崎優季 (@shi
デブサミ2014【14-C-4】 DeNAにおけるゲーム以外の新規事業の立ち上げ方
デブサミ2014発表資料です。 http://event.shoeisha.jp/devsumi/20140213/session/421/ 現在DeNAでは、エンターテイメント事業本部という非ゲームの新規事業開発に特化した部署を新設し、新しく会社の柱となるサービスの開発に鋭意取り組んでいます。本年度は、大小合わせてすでに8本のサービスをリリースしており、年度内には10本以上のリリースを目標としております。iOS/Android/ブラウザベース等、多種多様なプラットフォーム向けのサービスを複数並行で開発してきました。早いスピードで、かつ高スケーラビリティなサービスを複数開発する上で苦労した点や工夫した点を、iOS/Android等のフロントエンドからインフラを含むバックエンドまで幅広くご紹介したいと思います。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
nanapiにおける継続的インテグレーション
nanapiの開発現場をどのようにして回しているか
ニコニコ動画（Re:仮）
はてなブログチームの開発フローとGitHub
Cookpad's deployment and auto scaling
What is and isn't lean startup
