[B! PR] braitomのブックマーク

テックブログを分析して分かった始めるコツ・続けるコツ

DevRel/Japan CONFERENCE 2023の発表資料です https://devrel.tokyo/japan-2023/

braitom 2023/03/11

PR
blog

リンク

リファクタリングの PR、見るのツラい内容になりがち PR(PullReqeust)を作成してレビューを受け、Approve を受けたらマージする..という開発スタイルはよくあるパターンで、新たな機能追加や修正では観点が明確で動作確認も実施しやすいのですが、これがリファクタリングがテーマになると、途端にレビューが大変になることがあります。個人的な経験則もありますが、何も意識せずに PR を作ると、次のような問題が発生しやすいように感じます。１テーマに関する修正が一気に詰め込まれていて物量が多い何を確認したらよいのかわからない複数 PR に分けている場合に、後続の PR だけを見ても理解できないなど... リファクタリングの PR は内容も淡々としたものになることが多く、確認もリグレッションテストが中心で、レビュアーはそこそこ心を削られます。そのうえ上記のような問題を抱えていると、

braitom 2021/03/25

PR

リンク

GitHub - shibayu36/merged-pr-stat

braitom 2020/08/25

特定期間にマージされたPRの統計情報を収集するツール。

リンク

レビューしやすいプルリクエスト | DevelopersIO

普段レビューをしていて、レビューしやすいプルリクエストに対して個人的に感じている特徴をまとめてみました。普段レビューをしていて、レビューしやすいプルリクエストに対して個人的に感じている特徴をまとめてみました。割と大きめなソースコードに対するレビューの話が主となります。ざっくりまとめ本記事では以下のようなトピックについて記載しています。差分の目的が1つレビューをしながら「私はいま何のレビューをしているのか」のコンテキストスイッチが発生しないので嬉しい何を達成したいのかがわかるレビューの多くは「やりたいこと」と「実現方法」のすり合わせなので、前者の精度を上げたい分割されすぎていない他のコードとの関連性や構造についてのレビューがしやすいレビューの強弱をつけるための情報がついている機械的な変換の差分だったりした場合、それが事前にわかると嬉しい検証結果が書いてあるコードだ

braitom 2020/07/16

レビューしやすいPRについて。差分の目的が1つ、分割されすぎていない、ファイル間の関連が分かるなど。

リンク

Engineering Managerとしての技術ブランディングへの取り組み方 - itohiro73’s blog

本記事はEngineering Manager Advent Calendar 2019の23日目の記事です。自己紹介 2019年10月からREADYFORというクラウドファンディングの会社でVP of Engineeringを務めております、伊藤と申します。﹁いとひろ﹂と呼ばれることが多いです。2005年から12年ほど外資系金融の会社でソフトウェアエンジニアを務めたのち、FinTech系のスタートアップ2社を経て現職に就いております。 Engineering Managerと技術ブランディング Engineering Manager︵以降EM︶が取り組むひとつの課題として、エンジニア組織をいかに成長させていくかという課題があると思います。そのためにも採用数を伸ばしていかないといけなかったり、人材流出を防ぐためにリテンション施策をとらないといけないと思います。その中のひとつの施策として技

braitom 2019/12/24

技術ブランディングについて。技術ブランディングを醸成するのに大切なポイント、明確に強みである領域とこうありたいという想いがあるがまだ達していない領域それぞれのブランディング方法について。

技術
PR

リンク

GitHub - ldez/prm: Pull Request Manager for Maintainers

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

braitom 2019/06/24

GitHubのPRを対話的に操作できるCLIツール。Go製。

github
PR

リンク

GitHubのPull Panda連携を(さっそく)導入しました！ - Studyplus Engineering Blog

Androidチームの若宮(id:D_R_1009)です。今朝方、Twitterを眺めていたら下記のツイートが目にとまりました。ここ最近、超絶便利に感じていた Pull Reminders が GitHub に買収されて、誰でも自由に使えるようになったみたいだ。 GitHub + pull request でチーム開発をしていて、Slack も使っているところであれば、とりあえず試してみると良いと思う。https://t.co/xvHdkDu7YR— suzuki (@suzuki) June 17, 2019 ﹁これは便利そうだ！﹂と感じたため社内Slackに投稿し、利用を開始したところ期待以上の便利さだったので、本ブログでも紹介したいと思います。 Pull Pandaとは https://pullpanda.com/ GitHubのリリースでは下記のように紹介されています。W

braitom 2019/06/18

Pull Pandaかなりよさげ

github
PR

リンク

プルリクエストが最速でマージされるための７つの技 - Qiita

わたしはOSSとして公開されているGitHubのリポジトリに貢献することがあるのですがいつも困っていることがあります。私がPRをオープンするとめっちゃコメントがついて、それを修正するのにすごく時間がかかることです。そういえば私の元同僚のピーターは生まれて初めて新しい言語で書いたPRですら一発でマージされていて驚いた覚えがあります。どうやったらプルリクエストが最速でマージされるのか？インターネットを調べても情報がなかったので、自分で調べてみることにしました。ちなみにこのポストは、私自身が書いたHow can you get your PR merged less than 10 comments?の日本語版の記事です。プルリクエストが最速でマージされるための７つの技は次の通りガイドラインに従う静的解析ツールを使うリポジトリのコードスタイルをそっくりまねるプルリクエストを小さくする

braitom 2019/03/31

OSSにPRを送る時に意識した方が良い点について。ガイドラインに従う、コードスタイルを真似る、PRを小さくする、リポジトリオーナーやコントリビュータ間のコミュニケーションや信頼関係を大事にするなど。

PR
oss

リンク

地味に面倒なブランチ作成〜WIPプルリクエストまでをコマンド1つで行う - LCL Engineers' Blog

フロントエンドエンジニアの岡田です。やる気がでない時の最良の方法は、﹁とりあえず始めてみる﹂ことだと聞いたことがあります。今回は、やる気がでないときでもコマンドを1つ叩くだけで、ブランチ作成〜WIPプルリクエストまで作ってくれるように設定をしましたのでご紹介します。 WIPプルリクエストを作るまでにすること WIPプルリクエストを作るまでには、以下のことをしています。 masterをチェックアウト＆プルブランチを作成空のコミットを作成してプッシュプルリクエストの作成ラベルを付ける手順が多い上に、私が普段使っているSourceTreeでは、3. の空のコミットが作れません。そのため、ターミナルで操作しなければならず、面倒でした。そんな時に同じチームの人が教えてくれた以下の記事を試してみました。qiita.com すごく便利です…！これはぜひ使いたいと思い、さらに以下の機能

braitom 2018/07/08

便利そう。

リンク

Pull Reminders has been shut down

A static site to replace the pullreminders app after it is shut down.

braitom 2018/05/21

GitHubのまだ閉じられていないPRをリマインドしてくれるSlackアプリ。

リンク

commit をどう分割すべきか〜コードレビューの観点から〜

普段の開発の中でgit の commit の単位に気を遣っている人もいると思うんですが、どういう単位で commit すべきかみたいな話をあまり見かけない気がします。自分自身 GitHub の Pull Request︵以降PR︶ベースのチーム開発を何年か経験してみて、﹁こうすると良さそう﹂というものが見えてきた気がするのでまとめてみました。なお、小さい単位でPRを出す方針にしている場合は、以降の内容に出てくる commit を適宜PRで読み替えてもらうと良いかもしれません。そもそも commit の単位に気を遣った方が良いのか？コードレビューを行う場合など、他者がコードを読む場合はある程度気を遣った方が良いと思っています。理由は次のとおりです。コードレビューにおいてレビュアーのレビュー時間が短縮できるコードレビューの精度が上がる変更の経緯を追いやすい自分にとって

braitom 2018/01/09

コミットの粒度について。コミットの粒度に気を使った方よい理由、どう分割するとよいのか、アンチパターンがまとめられている。

リンク

ログイン - はてな

パスワードを忘れた方はパスワードの再設定を行ってください。初めての方ははてなID登録 (無料) してください。うまくログインできない方はお問い合わせをご覧いただき、Cookieの設定をご確認ください。

braitom 2017/10/07

レビュワーにやさしいPRの書き方が分かりやすくまとまっている。

PR
review

リンク

prprでGithubのPullRequestレビュー依頼をSlack通知する - hitomedia Tech Blog

最近サーバサイドをやりつつiOSアプリ開発をやったり何でも屋になっている hilotter です。 GithubのPullRequestレビュー機能、便利ですね。チーム開発においては相互レビューが非常に大事です。今回は、レビュー依頼を行った際にSlackに自動通知するようにしたらより便利になったというお話を共有させていただきます。 SlackのGitHub連携の課題 Slack公式のGithub連携がありますが、こちらは以下の2点が課題となっていました。 1. メンション付きのコメントをしても、message-attachmentsの記法になっているため、うまく通知されずコメントを見落としてしまうこのため、コメント後にSlackでも﹁コメントしました！﹂と2重で連絡をする必要がありました。 2. PullRequestのレビュー依頼を行ってもレビュアーへの通知が飛ばないため、レビュー

braitom 2017/08/24

これは便利そう。GitHubのユーザー名とSlackのユーザー名を変換するプラグインもあるのか。

github
PR

リンク

なぜあなたのPull Requestは読まれないのか - Qiita

Pull Requestを出してレビューしてもらってから反映。どこにでもあるありふれた開発フローに付きまとう、どこにでもあるありふれた問題。﹁Pull Requestがレビューされない﹂もちろん開発フローにレビューが含まれている以上、レビューをしないメンバーにも非がないとは言えませんが、多くの場合はレビューされないPRには問題があるものです。デカい兎にも角にもデカいPRは読むのがつらいです。もちろん要件が明記されていないなど、他にもPRが読みにくくなる原因はたくさんありますが、一番はこれです。極端な話、1行変更のPRは他に何も書かれていなくても実装内容を察することができますが、10ファイル100行の差分と箇条書き20点の要件が書かれたPRは内容を把握するだけで一苦労です。しかし、このこと自体は数カ月でもコードを書いていれば自然と勘づくもの。問題はなぜPRが大きくなってしま

braitom 2017/04/01

Pull Requestの粒度の話。Issue、Commitｔの関係性を意識、branch名をしっかりつける、要件をきちんと書くなどを行ってPRのサイズを小さく保つ。 ●github ●PR

リンク

よりよい機能をより早く届けるためにGit/GitHubを使いこなす10の方法 - Qiita

この記事は freee Engineers Advent Calendarの6日目です。こんにちは。freee株式会社でアプリエンジニアをしている @kompiroです。主に会計freeeの開発に携わっています。僕には﹁よりよい機能を、より早くユーザーに届けたい﹂という信念があります。今日はよりよい機能を、より早くユーザーに届けるためのGit/GitHubを活用する10の方法と題してGitやGitHubの便利な使い方や日々のTipsをお届けします。1 PRのレビュー完了までの時間を最速にするための工夫 freeeではGitHub上でレビューをしながら開発を進めています。レビューをするのもされるのも、うまく進めないと結構時間がかかります。もちろんコードをより良くする作業に時間を割いているのであれば時間がかかるのも致し方ないです。しかし、進め方による問題でも数日〜数週間デプロイが延期されれ

braitom 2016/12/10

PRに対するレビューを効率的におこなうためのTipsが書かれている。レビューする側、レビューを出す側両方の視点が書かれていて非常に参考になる。便利ツールの紹介も書かれている。

リンク

The Art of a Pull Request

Writing a great Pull Request takes time. It can be a scary proposition going in. Did I implement something relevant? Will they like my changes? Will the PR meet their expectations? How much scrutiny can I expect? Something that we’ve been discussing recently in Kibana – the open-source analytics dashboard for Elasticsearch I outrageously call my day job – is how to improve the process of contribut

braitom 2016/08/04

KibanaリポジトリのPRが来たときのレビュー方法について

github
PR

リンク

【暫定版】新人エンジニアのプルリクエスト入門 - Qiita

0.はじめに新人さん向けプルリクエスト︵以下‥PR)の送り方・受け方入門をざっと書きます。仕事ではScalaをベースに使っているので、それベースにサンプルコードを書きます。もし、こういうのもあったほうがいいんじゃね？というのがあったら、編集リクエストください。吟味して、取り入れます。また、あえて少し乱暴めに書きます。なぜかというと、この初めてエンジニアになった人にあなたのそのミスはこれくらい上司が呆れたり、イラっとしたりしますよということを伝えるためです。というわけで、新人さんは参考に、上司の方は教育の参考に使ってもらえると幸いです。 1.PRを出す前にチェックすること 1-1.環境編まずは、最低限の話をする。正直、この章の☑が全てとおらないモノを論外と思ってくれていい。 ☑1: ビルドはとおるか？これはホントに最低限。一部の新人エンジニアを除いてグループ作業とかした

braitom 2016/07/29

リンク

HubotにGitHubのプルリクエストを自動でアサインさせる - Qiita

概要 / 目的いつも決まった人がプルリクエストに対するコードレビューを行っていると、以下のようなデメリットがあります。コードレビューの属人化コードレビューする側とされる側がはっきり別れてしまい、フラットな関係でのチーム開発を阻害するコードレビューが特定の人に集中してしまい、他の重要な仕事が進みにくくなるそこで、コードレビューをチーム内のメンバーに割り振るのですが、この割り振りを人力でやるのは非生産的なので、Hubotを使って自動化しました。ここでの説明で前提となっているChatOpsな環境の構築方法や運用方法は以下を参考にしてください。 Slack / Hubot / GitHub / CircleCI によるChatOpsなデプロイ方法 ChatOps時のブランチ運用戦略 Hubotによる自動アサインの概要図設定 / 実装 GitHubチームの作成 GitHubのWEBコン

braitom 2016/07/15

リンク

はてなブックマーク

タグ

関連タグで絞り込む (17)

PRに関するbraitomのブックマーク (18)

お知らせ

今週のはてなブックマーク数ランキング（2024年7月第2週）

はてなブックマーク透明性レポート（2024年 2月-2024年4月）

今週のはてなブックマーク数ランキング（2024年7月第1週）

公式Twitter

キーボードショートカット一覧

はてなブックマーク

公式Twitter

はてなのサービス