コードレビューとPull Request、そしてその承認機能の副作用について考える - 時計を壊せ
用語 レビュアー 対象となるコードをレビューする人のことを指します。 レビュイー レビューを受ける人、つまりレビューする対象のコードを書いた人のことを指します。 tl;dr アプリケーション開発業務におけるコードレビューはコードの正しさや質そして一貫性を保ち、それらと同時にコードに対するチームとしての共有知を作り上げる良いプラクティスだと思います アプリケーション開発チーム内でのコードレビューにおいてPull Requestを使ったレビューのスタイルは一般的ですが、Pull Requestの承認は実際にはほとんど意味がないのではないでしょうか？ ほとんど意味がないにも関わらず、承認の有無によって業務フローが左右されることでそれが権威的に扱われてしまいオーナーシップを希薄化させ、結果的にコードレビューのコストが増加したりそれを行う目的を見失ってしまっていることはないでしょうか？ Pull R
Podcastのやっていきかた - ✘╹◡╹✘
9mとsoramugiから、やっていきエフエム という名前でPodcastをやりませんかという話を承け、Podcastをやることになった。既にサイトが公開されていて、https://yatteiki.fm からアクセスできる。昨日できたばかりで準備中なところが幾つかあるが、サイトを開いて音を聴けるという点では最低限の体験は保証されている。 10月25日にSlackチームを立ち上げ 10月28日に練習でSkypeで通話 10月29日に1回目を収録 10月30日に公開用のサイトを作成 という流れで、発足から企画、収録、公開まで進み、この順調さには当の我々ですら驚かされた。 個人的には、雑談レベルの会話が淡々と展開されていくような、例えばカンファレンスの懇親会での会話を隣で聴いているような、あるいは飯屋での雑談を隣で聴いているような、更に言えばマックで隣の女子高生のガールズトークを聴いているよう
Markdown原稿をGitHubで管理して本にする仕組みが出版社で導入されないわけ
これ、FAQっぽいんで、ちょっと私見を書いておこうと思います。 とくに技術書に関しては、Markdownで原稿を書きたいとか、修正はPull Requestでもらえると楽とか、そういう便利な世界を知っている人たちが執筆者なので、 「MS Wordで書いてもらった原稿を、こちらでDTPの担当者に組版してもらいます。修正は紙に赤字か、PDFをメールで送るので、そこにコメントを入れてください」という古き良き時代の出版社のやり方を目にすると、 「出版社って遅れてるよなー」という感想を抱かれることが多いのだと思います。 その結果、「自分たちはITのプロとして出版のためのプラットフォームを作れるだろうから、それを使ってもらえないものか」という方向の考え方に至るのはよくわかります。 しかし、これには、二つの面から「ちょっと認識が違うから待って」と言いたい。 まず「認識が違う」と思うのは、プレインオールド
各企業ノベルティシール剥がし選手権 - 僕のYak Shavingは終わらない
退職したので社用PCを返すときに僕は固まりました。 私物のステッカー等は、はがして返却すること ((((；ﾟДﾟ))))ｶﾞｸｶﾞｸﾌﾞﾙﾌﾞﾙ (((((((( ；ﾟДﾟ))))))))ｶﾞｸｶﾞｸﾌﾞﾙﾌﾞﾙｶﾞﾀｶﾞﾀﾌﾞﾙﾌﾞﾙ ちょっと控えめに貼っていたにしろこれはつらい・・・。 曇りなき眼で剥がし始める 一番はがしやすいやつから行きましょう。 まずはコロプラ え！？ えぇ！？ そういうタイプなの！？ 綺麗に残ってる。 うん、綺麗だ。 いきなりこれでは先が思いやられる。。。 あとまわしだ、次はNiigata.pm うえーい！はがしやすい良いシール！これは再利用できそうなので取っておこう。 お次はtwelvesouthさん あ、これは…これはだめなやつだ…爪をやられたので次… 次はgithubと見せかけたcakeのシールです。 これは！思った通りだ！小さい時にタンスに貼っちゃうシー
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - wenyan-lang/wenyan: 文言文編程語言 A programming language for the ancient Chinese.
