コードレビューにラベルを付けるだけでチームの心理的安全性を高めた話
ハコベルシステム開発部のおおいし (@bicstone) です。普段はフロントエンドエンジニアとして物流DX SaaSプロダクトの開発を行なっています。 この記事ではハコベルの開発チームが心理的安全性の向上を目的に採用した、プルリクエスト (マージリクエスト) コメントにラベルを付ける手法についてご紹介します。 背景 プルリクエストをレビューする時、レビュアーとして上から目線になってしまい相手を傷つけないか緊張したり、ちょっとした確認のつもりで書いたコメントが修正必須と捉えられてしまったりした経験はないでしょうか。 本来、ピアレビューは対等な関係であるはずなのに、レビューする側の方が上になってしまいお互いに恐縮してしまいがちです。「勘だと怪しいけど間違っていたら怖いから言えないな」や、「将来的に辛くなりそうな実装だけどわざわざ指摘するほどでもないな」など荒波を立てずにApproveしてしま
GitHub Projects勉強会を開催しました - ROUTE06 Tech Blog
こんにちは！ROUTE06 Software Engineerの@yoshida-m-3です。 GitHub Projectsがアップデートを続けていることは知っていましたが、実際のプロジェクトで使用できるかは確証がありませんでした。そこでチーム内でGitHub Projectsの勉強会を開催し、実際に検証することにしました。 見るべき人に見るべき情報を確実に届けたい プロジェクト情報の管理において、「各関係者に適切な粒度で情報を確実に届けること」が重要だと考えています。 情報の可視化にはカンバンを使うことが多いですが、情報が多いと重要な情報が隠れてしまう可能性があります。 情報の粒度は見るべき人の立場によって異なります。エンジニアはIssue単位の情報が必要ですが、プロダクトオーナー・マネージャーはEpic単位の情報が必要であり、時系列の進捗情報も必要な場合があります。 GitHub P
Gitを実践的に使うために参考にすべき記事20選
チームで開発を行うときにGitのスキルは必要不可欠なものとなってきています。以前、Git初心者向けにスライドをまとめたものを紹介しましたが、今回はGit（GitHub）をさらに活用するために参考にしたい記事を紹介します。 この記事は以下のような方におすすめです！ ・ブランチをどのように運用すれば良いのかわからない。 ・コミットメッセージの書き方にいつも悩んでしまう。 ・issueやPull Requestをもっとうまく活用したい。 ・Git�やGitHubに関する便利なテクニックを知りたい。 ・間違ってコミットしてしまったけど対処法がわからない。 今回は、運用編、コミットメッセージ編、issue編、Pull Request編、テクニック編、問題解決編と５つの内容で分類してみました。実践的な読み応えのある記事ばかりなので、ぜひ参考にしてみてください。 運用編 中の人に聞いたGitHub fl
Excelなテスト仕様書をMarkdown/GitHub/CircleCIに移行した話 - トレタ開発者ブログ
こんにちは、QAエンジニアの井上恵一です。好きな飲み物は一番搾りと韃靼そば茶です。 初回からニッチなネタではありますが、昨年入社した直後に行った、 iPad アプリのテスト仕様書の管理方法を見直したときの話を紹介しようと思います。 見直しのきっかけ トレタは飲食店向けの予約/顧客台帳アプリです。だれでもかんたんに使いこなせるシンプルさを追求してはいますが、製品の進化に伴ってそのテストケース数はすでに数千という単位にまで膨れあがっています。 製品の品質を安定させるためには、テストの内容自体をブラッシュアップすることが重要なのは言うまでもありません。ただ、安定した製品を永続的に提供していくためには、それに加えて、膨大なテストケースを効率よくメンテナンスし続けるためのプロセス作りも欠かせません。 入社のタイミングでトレタのテスト設計を担当することになったので、テストケースの管理方法についてもいち
自動文書検査ツールRedPenをRubyから使えるredpen-rubyを書いてみました - Fuzoku実践入門ブログ
最近、RedPenという技術文書向け校正ツールを知りました。RedPenについては、RedPenを使って技術文書を手軽に校正しよう：連載｜gihyo.jp … 技術評論社に詳しい説明があります。 本格的に文章を書くようになり、こういったツールを求めていたため、早速試してみることにしたのですが、epubcheckをepub_validatorを使っている身としては、RedPenもRubyから使いたいなぁと思ったので、折角なので最近覚えたRubyを使ってepub_validatorのコードを参考にラッパーツールを作ってみることにしました。 RedPenRuby is a Ruby wrapper for redpen: a text inspection tool. akinomurasame/redpen_ruby redpen_ruby | RubyGems.org とりあえず、希望する動
【旧版】Atom入門 (全13回) - プログラミングならドットインストール
文字列の検索・置換（Command+f） 次の検索結果へ（Command+g/Command+Shift+g） 全体からの検索・置換（Command+Shift+f） シンボルの検索（Command+r）
Vue.js - The Progressive JavaScript Framework | Vue.js
The Progressive JavaScript Framework An approachable, performant and versatile framework for building web user interfaces. Why Vue Get Started Install Get Security Updates for Vue 2 Approachable Builds on top of standard HTML, CSS and JavaScript with intuitive API and world-class documentation. Performant Truly reactive, compiler-optimized rendering system that rarely requires manual optimization.
わかりやすいREADME.mdを書く
GitHubなどに自分のツールやライブラリを公開するとき，README.mdは重要な役割を担っている．レポジトリを訪れたユーザが自分のツールを使ってくれるか否かの第一歩はREADME.mdにかかっている，と言っても過言ではない．実際自分が使う側になったときも，まずREADME.mdを読んで判断していると思う． 成功しているプロジェクトを参考にしつつ，自分が実践していることをまとめておく．ここに書いていることはあくまで（自分の中で）最低限的なものである．プロジェクトが成長していくにつれてREADMEはあるべき姿に成長していくべきだと思う． READMEの役割 README.mdには大きく2つの役割がある． プロジェクト，ツールの使い方，インストール方法 プロジェクト，ツールの宣伝 元々READMEは前者の役割しかなかったが，GitHubの仕組み上，後者の役割も徐々に重要になっている． さらに
GitHubで雑誌・書籍を作る
シリコンバレーのスタートアップを数多く取材する中で気付いた「シリコンバレーにおけるディシプリン（規律）の存在」や「General Electric（GE）やIBM、SAPといった老舗企業が必死になってシリコンバレーのスタートアップを真似している理由」、そして「日本企業がイノベーションを実現するための処方箋」について解説します 詳しく知りたい場合は「GE 巨人の復活」をご覧下さい。 http://www.nikkeibp.co.jp/atclpubmkt/book/17/P55110/ 今後の記事は「シリコンバレーNext」をご覧下さい。 http://itpro.nikkeibp.co.jp/siliconvalley/
OSSのバグを直して賞金がゲットできる Bountysource
オープンソースソフトウェアの開発だけで生活していくという夢を現実に近づけるサービスが現れました。その名も「BountySource(賞金ソース)」という事で、GitHub上などで公開されているプロジェクトのバグや機能改善に対して賞金が設定され、修正を行った人に支払う仕組みを提供しているサイトです。公式ブログによると、2004年から運営されていたbountysourceは2012年末にリニューアルして、現在のサービスがスタートしたとのことです。 例えばLESSプロジェクトの「ソースマップを生成する」というバグに対しては3人の開発者の修正が採択され、合計で75ドルの賞金が決定されました。また、このBountysourceのサイトのフロントエンド自身の開発もオープンソース化されており、多数の賞金が設定されています。 このサイトは上記のような賞金をベースにしたクラウドソーシング的な側面を持つだけで
Travis CIとCoverallsとCode Climateを使ってGitHubリポジトリにバッジを付ける - アインシュタインの電話番号
先月に公開した超ニッチなツールFont Awesome Workflow for Alfred 2が意外と好評で、そこにオクラホマ州からこれOS X Mavericksで動いとらんよとお便りが届いたりした。 そんなわけで少々テストを書いた上で、Mountain Lion以前に入っているRuby 1.8.7と、Mavericks以降に入るRuby 2.0.0の両方で常に動作確認しておくようにしたいと考えて、まずTravis CIを、その後CoverallsとCode Climateを導入した。この記事はその備忘録。 {: .ArtcleBody-inlineImage .u-textCenter } それらを導入すると、こんなかんじのバッジを表示できる。GitHubでよく見かけるやつ。今回使ったサービスはどれも、オープンソースなら無料で使わせてもらえる。 Travis CIは名前の通り継続的
Travis CI 入門：GitHub + Travis CI で継続的インテグレーション « をぶろぐ
1. Travis CI とはTravis CI はオープンソースコミュニティのためにホストされた CI（継続的インテグレーション）サービスです。 継続的インテグレーションってなんだ？ 継続的インテグレーション、CI（英: continuous integration）とは、主にプログラマーのアプリケーション作成時の品質改善や納期の短縮のための習慣のことである。エクストリーム・プログラミング (XP) のプラクティスの一つで、狭義にはビルドやテスト、インスペクションなどを継続的に実行していくことを意味する。特に、近年の開発においては、継続的インテグレーションをサポートするソフトウェアを使用することがある。 引用: 継続的インテグレーション - Wikipedia Travis CI は GitHub と連携しており、CI したいリポジトリーを接続しておくと、Travis CI がコミットを
Webサービス開発現場から / 近頃の開発のやり方 ･･･ Github と Pull Request とコードレビュー - naoyaのはてなダイアリー
先日プレスリリースが出たのですが、KAIZEN platform という会社で技術顧問などをやっています。それから、一昨日自分も出たWebアプリケーション開発に関する勉強会 (資料) を開いたじげんという会社でも少し前から同じように顧問のような形で携わっています。 自分が関わっている会社のPRも含めて、すこし、2013年現在のWebサービス開発の現場感、やり方みたいなものを書いてみたいと思う。ただ、自分の利益があるところの話だけではフェアではないので、Webエンジニアならよく知っているであろう Qiita を運営しているインクリメンツの様子も合わせて紹介する。 KAIZEN platform KAIZEN platform が提供しているサービスは planBCD という A/B テストの SaaS で、Webサイトのコンバージョンだとかを画面の構成要素を変えて効果測定したいとか、そういう
可視化周辺の進化がヤヴァイ～rChartsを中心として～
TDD bootcamp 札幌2.0 http://atnd.org/events/15811 の自己紹介で使った資料です。
Learn Git Branching
A interactive Git visualization tool to educate and challenge!
githubはじめました - それなりにマジメなメモ
新年、一発目の記事なのでいまさら感満載ですが、明けましておめでとうございます。 「情報系のくせにgithubアカウントももってないの？」というようなことを何人かに言われて、「実はあるんですけど一個もリポジトリ作ってないんですよね、あははは〜」と言って逃れて早数年・・・。 いい加減始めよう！って意気込んで使い始めました。 ユーザー名は「shu65」で作りました。 右も左もわからない状態でいきなりすごいものを！なんてことはせず、githubのHelpを見ながら、「HalloWorld」というリポジトリを作り、これじゃなにもしてないのと同じなので、文字列処理の基本のHamming Distanceを計算するプログラムを組みました。 これからはちょくちょく上げても問題ないものについては上げて行こうと思います。
世界一簡単なGithub入門（githubは無料で使用する場合、全てのファイルが公開されていることにご注意ください）
世界一簡単なGithub入門（githubは無料で使用する場合、全てのファイルが公開されていることにご注意ください） ややこしいコマンドを全スルーして個人用バックアップとして使ってみる 2013.01.26 LDD13 LT 【概要】 次々と新しい技術やサービスが公開され、いろいろ挑戦してみたい・・・とは思うのですが、それが複雑なものだったり高機能であったりすると、どうしても最初のハードルが高く、なかなか踏み出せないと感じます。 そんな時、私の場合は、とりあえず、できるだけ簡単なマニュアルを探してきて、良く分からないところは全部無視して無理やり使ってみることにしています。訳が分からないままでも、使っていることで、ちょっとずつイメージが湧いてきて、画面が見慣れたものになってきます。そして、それから改めて入門書を読み始めます。そうすることで、最初のハードルが、少しは下がるのではと考えています。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
入門書には載ってない Git & GitHub Tips
はてなブログチームの開発フローとGitHub
Log in with Atlassian account