  |
はてなキーワード: リポジトリとは
今年の1月からチマチマ作っていたアンテナサイトのジェネレータを公開しました。
お好みのRSSを登録するだけであなただけのアンテナサイトの完成です。
Google Analyticsのコードを使ってアクセス解析もできます。
ダッシュボードにて、アクセスランキング、逆アクセスランキングなんかも見ることができます。
今後はアクセスに応じて調整するような機能などを追加していく予定です。
ぜひ使って感想ください！
この間、某有名なリポジトリがメンテナンスモード(新機能追加よりもバグ等の修正を優先にする)に入っていることを知って独り言を書こうと思った。
また、この間メンテナや開発仲間でいろんなリポジトリの現状共有の話があった。
最近、様々なOSSコミュニティの記事を見るようになったのも理由の１つかもしれない。
はじめに私は複数のリポジトリのメンテナをしており、その目線で書けたらと思う。
私が最初に思ったのは結局、OSSコミュニティというのは社会と構成は変わらないなぁと思った。
大きな違う点として、
だと思う。
私がOSSで活動するのは、志が他の開発者と同じであり楽しいと思えるから。
仕事だとお金を稼ぐためというのは当たり前だし、そのために働いている。
なのでお金を稼ぐためという人もいれば、サービスを使われたいとか、もっと拡大させたいとか様々な意識があると思う。
しかし、OSSコミュニティで活動するのは物を良くしたいという部分が大きくコントリビューターやコミッターがそういう意識で活動していると思う。
メンテナが減るのは当たり前で、飽きもあるだろうし家庭の事情とかもあるだろう。
また、別の興味あるプロジェクトにコントリビュートしたり、自分の開発に専念するといったこともあるだろう。
これは私の中で転職に似ているなって思った。
OSSコミュニティというのは今の時代、多くの会社が普通に使っており、市場の規模は大きいと思う。
しかしメンテナの数というのはとても少なく、著名なリポジトリでも2, 3人しかいないというところもある。
みんなが知っている有名なフレームワークやツールも内部を見ると、少人数で回しているのが現状である。
本当にPull Requestを出してくれる方や、バグ、RFC等のフィードバックをしてくれる方には感謝している。
そういう方が居てこそ成り立っており、このような体験は仕事では得られないと思うので大切にしていきたい。
日本人の方の参入率は自分の観測範囲では結構低く、やはり敷居が高いのかなって思った。
一番最初に壁になるのが英語だと私は思う。 実際、私はそうだった。
日本だと、どうしても日本語のドキュメントや情報が充実していないと流行らないというのも実際そうだ。
この記事は増田Vimアドベントカレンダー2016の27日の記事です。
Vimに興味を持ってるけどtwitterで誰をフォローすべきか分からない・・・
vim-jpで積極的に活動している(していた) 人達を調査してみました。
vim-jp/issuesでは、issue作成数、コメントを投稿したissueの数を見ていきます。
vimdoc-ja-workingとvital.vimでは、コミットすることが重要なリポジトリだと思いますので、コミット数とPR数のみ見ていきましょう。
データは2016/12/27 17:00-19:00の期間にgithubからスクリプトで取得
| name | Open中のissue | Closedしたissue |
|---|---|---|
| DeaR | 1 | 5 |
| Flast | 0 | 0 |
| Kuniwak | 0 | 0 |
| SKAhack | 0 | 1 |
| Shougo | 14 | 57 |
| alpaca-tc | 0 | 1 |
| basyura | 0 | 0 |
| bouzuya | 0 | 0 |
| cocopon | 0 | 0 |
| crazymaster | 4 | 3 |
| deris | 1 | 0 |
| deton | 0 | 3 |
| eagletmt | 0 | 3 |
| h-east | 8 | 42 |
| hattya | 2 | 1 |
| haya14busa | 3 | 11 |
| ichizok | 2 | 17 |
| iyuuya | 0 | 0 |
| k-takata | 8 | 45 |
| koron | 71 | 110 |
| lambdalisue | 0 | 1 |
| mattn | 39 | 129 |
| nocd5 | 2 | 5 |
| presuku | 0 | 1 |
| raa0121 | 2 | 4 |
| rhysd | 0 | 3 |
| ryunix | 0 | 0 |
| saitoha | 1 | 1 |
| splhack | 1 | 5 |
| supermomonga | 0 | 0 |
| syui | 0 | 0 |
| thinca | 28 | 68 |
| tobynet | 0 | 1 |
| todashuta | 0 | 2 |
| tyru | 11 | 23 |
| ujihisa | 1 | 1 |
| withgod | 0 | 0 |
| ynkdir | 6 | 16 |
| zchee | 0 | 0 |
| zoncoen | 0 | 0 |
| name | Open中のissue | Closedしたissue |
|---|---|---|
| DeaR | 3 | 16 |
| Flast | 0 | 1 |
| Kuniwak | 0 | 0 |
| SKAhack | 0 | 1 |
| Shougo | 47 | 168 |
| alpaca-tc | 0 | 3 |
| basyura | 0 | 0 |
| bouzuya | 0 | 0 |
| cocopon | 0 | 0 |
| crazymaster | 13 | 55 |
| deris | 4 | 2 |
| deton | 2 | 4 |
| eagletmt | 0 | 4 |
| h-east | 69 | 372 |
| hattya | 2 | 2 |
| haya14busa | 4 | 22 |
| ichizok | 16 | 52 |
| iyuuya | 0 | 1 |
| k-takata | 78 | 340 |
| koron | 136 | 374 |
| lambdalisue | 0 | 2 |
| mattn | 138 | 489 |
| nocd5 | 3 | 8 |
| presuku | 3 | 8 |
| raa0121 | 4 | 16 |
| rhysd | 1 | 12 |
| ryunix | 1 | 0 |
| saitoha | 7 | 15 |
| splhack | 2 | 6 |
| supermomonga | 0 | 1 |
| syui | 0 | 0 |
| thinca | 58 | 189 |
| tobynet | 1 | 1 |
| todashuta | 1 | 15 |
| tyru | 41 | 88 |
| ujihisa | 6 | 15 |
| withgod | 1 | 0 |
| ynkdir | 48 | 204 |
| zchee | 1 | 0 |
| zoncoen | 0 | 0 |
| name | コミット数 |
|---|---|
| k-takata | 302 |
| ynkdir | 294 |
| crazymaster | 256 |
| koron | 239 |
| nakinor | 95 |
| mattn | 87 |
| thinca | 64 |
| kashewnuts | 47 |
| h-east | 35 |
| tyru | 29 |
| rhysd | 24 |
| cougar-b | 21 |
| rbtnn | 15 |
| deton | 14 |
| sgur | 6 |
| aiya000 | 5 |
| haya14busa | 5 |
| saitoha | 3 |
| Milly | 3 |
| machakann | 2 |
| norisio | 2 |
| todashuta | 2 |
| Shougo | 2 |
| oshow | 1 |
| lamsh | 1 |
| ichizok | 1 |
| miyakogi | 1 |
| natnu | 1 |
| pocke | 1 |
| shiracha | 1 |
| name | Open中のPR | ClosedしたPR |
|---|---|---|
| DeaR | 0 | 0 |
| Flast | 0 | 0 |
| Kuniwak | 0 | 0 |
| SKAhack | 0 | 0 |
| Shougo | 0 | 0 |
| alpaca-tc | 0 | 0 |
| basyura | 0 | 0 |
| bouzuya | 0 | 0 |
| cocopon | 0 | 0 |
| crazymaster | 0 | 5 |
| deris | 0 | 0 |
| deton | 0 | 0 |
| eagletmt | 0 | 0 |
| h-east | 0 | 1 |
| hattya | 0 | 0 |
| haya14busa | 0 | 0 |
| ichizok | 0 | 0 |
| iyuuya | 0 | 0 |
| k-takata | 0 | 4 |
| koron | 0 | 6 |
| lambdalisue | 0 | 0 |
| mattn | 0 | 14 |
| nocd5 | 0 | 0 |
| presuku | 0 | 0 |
| raa0121 | 0 | 0 |
| rhysd | 0 | 1 |
| ryunix | 0 | 0 |
| saitoha | 0 | 0 |
| splhack | 0 | 0 |
| supermomonga | 0 | 0 |
| syui | 0 | 0 |
| thinca | 0 | 0 |
| tobynet | 0 | 0 |
| todashuta | 0 | 0 |
| tyru | 0 | 3 |
| ujihisa | 0 | 0 |
| withgod | 0 | 0 |
| ynkdir | 0 | 0 |
| zchee | 0 | 0 |
| zoncoen | 0 | 0 |
| name | コミット数 |
|---|---|
| thinca | 721 |
| ujihisa | 480 |
| tyru | 414 |
| lambdalisue | 270 |
| haya14busa | 145 |
| rhysd | 118 |
| mattn | 104 |
| Shougo | 83 |
| syngan | 60 |
| rbtnn | 45 |
| crazymaster | 43 |
| kamichidu | 32 |
| aomoriringo | 31 |
| deris | 22 |
| cohama | 10 |
| hattya | 8 |
| itchyny | 8 |
| ichizok | 7 |
| Milly | 5 |
| raa0121 | 5 |
| ryunix | 5 |
| zoncoen | 5 |
| aiya000 | 4 |
| kozo2 | 2 |
| anekos | 2 |
| basyura | 2 |
| kannokanno | 2 |
| suy | 1 |
| deton | 1 |
| koron | 1 |
| m4i | 1 |
| nicoder | 1 |
| pocket7878 | 1 |
| gitter-badger | 1 |
| termoshtt | 1 |
| alpaca-tc | 1 |
| firisu | 1 |
| tacahiroy | 1 |
| y0za | 1 |
| name | Open中のPR | ClosedしたPR |
|---|---|---|
| DeaR | 0 | 0 |
| Flast | 0 | 0 |
| Kuniwak | 0 | 0 |
| SKAhack | 0 | 0 |
| Shougo | 0 | 5 |
| alpaca-tc | 0 | 1 |
| basyura | 0 | 1 |
| bouzuya | 0 | 0 |
| cocopon | 0 | 0 |
| crazymaster | 0 | 23 |
| deris | 0 | 9 |
| deton | 0 | 1 |
| eagletmt | 0 | 0 |
| h-east | 0 | 0 |
| hattya | 0 | 4 |
| haya14busa | 0 | 23 |
| ichizok | 0 | 6 |
| iyuuya | 0 | 0 |
| k-takata | 0 | 0 |
| koron | 0 | 0 |
| lambdalisue | 2 | 35 |
| mattn | 1 | 7 |
| nocd5 | 0 | 0 |
| presuku | 0 | 0 |
| raa0121 | 0 | 6 |
| rhysd | 0 | 13 |
| ryunix | 0 | 3 |
| saitoha | 0 | 0 |
| splhack | 0 | 0 |
| supermomonga | 0 | 0 |
| syui | 0 | 0 |
| thinca | 1 | 54 |
| tobynet | 0 | 0 |
| todashuta | 0 | 0 |
| tyru | 0 | 28 |
| ujihisa | 0 | 11 |
| withgod | 0 | 0 |
| ynkdir | 0 | 0 |
| zchee | 0 | 0 |
| zoncoen | 0 | 2 |
数字で見ると一目瞭然ですね。
綺麗に0が揃っている方々は実力を発揮していないだけなのかもしれません。
人によって話題にするポイントが違っていつつ、これまでの持論？をここぞとばかりに開陳する人が多くて、長引いている感じですね。
一般論としては一理あるんですが、日本マイクロソフト個別論としては、ちょまどはテクニカルエバンジェリストとしての責務を果たしているようなので、なんとも。
それから、一般論として技術力はGitHubだけから判断されるべきかという論点もあるでしょう。個別論としては、ちょまどのGitHubリポジトリにはそんなにすごいコードが置いてあるわけでもないようです。
派生して
エバンジェリストという言葉だけで虫唾が走る、さぶいぼ出るという人もいます。
オタサーの姫が話題になるときと同じで、下の2つのどちらかもしくは両方があります。
とにかく「性だ」と言いたい人も見かけました。
なお「女性エンジニアは〇〇であるべき」「そんなべきなどありません、女性かどうかで区別する時点でおかしい」などさらにジェンダーな方向に向かう話題も見ました。
彼女のこれまでの（主にtwitterでの？）ふるまいを嫌っている人たちというのもいるようです。元彼がどうとか。法務エディションも追加？
「ケーキとかサイン会とかおかしい」という意見の根っこにこれを置いてる人もいれば、ケーキやサイン会はコミュニティ内のヒエラルキーとは別でしょ？の人もいますね。
後者についてはMS系コミュニティの悪習っていうか悪臭として、MS公式発表すごい、MSの中の人すごい、MVP（MSに表彰されたコミュニティリーダー）の人すごい、みたいな雰囲気を感じ取り、そこを嫌う人もいるようです。
MVPの人がコミュニティでアクティブに活動しているのをDisるのはどうなのかなーと思いますが、でもコミュニティリーダーならむしろMVPではない人のトークを盛り立てていくべきなのかもしれませんね。例のスライド出した本人もどうやらMVPとのことで……。
女性エンジニアを集めてた GitHub の ggc リポジトリ で炎上してアカウント削除された話
http://d.hatena.ne.jp/shouh/20161107/1478521182
文章を読む限りでは、このリポジトリの第一発見者は男性のようで、この人物は件のリストにいた女性と友達だったようだ。
何人かGitHubに通報した人がいるようだけど、その中に何人か男もいたらしい。
被害にあった女性たちが自分で通報するのはまだわかるけど、通報した男たちは、この女性たちのなんなのだろうか。
確かにggcの内容は気持ち悪いし、書いた人もキモいが、通報した人のツイートを見るとなんだか良くわからない正義感に満ちあふれてて、それはそれで気持ち悪かった。
それと、スパムと疑われて凍結された場合ならアカウントの復活はできるけど、今回のケースはまっとうな理由で凍結されたわけよ。無理に決まってるでしょう。
後、アカウント凍結経験あるから知ってるんだけど、あれはアカウント凍結されただけでアカウント削除されたわけではないので勘違いしないでもらいたい。
ぶっちゃけリポジトリ自体は女性GitHubアカウント（avatarアイコン、連携SNSのbioから判断）をまとめてGitHubの公開アクティビティを取れるようにしただけ。
正直これだけでハラスメントって言われたらもっと詳細な個人情報を得る事も可能な男性主催の女性向け勉強会とかもアウトになるのではというレベル。
直後はまとめられてた女性本人が削除要請のPull Request出したりして微笑ましさすらあったんだけど、
KTB先生案件と同じで「女性アカウントをまとめてる！コイツは女性をストーキングしてシコる気だ！！！」って言い出す男性アカウントに見つかって通報祭りでまずリポジトリ、その後アカウントまで消された感じ
当該のGitHubアカウントが消されたので事実関係を確認し辛く通報側が大正義みたいになってるけどぶっちゃけフェミニストが騒いでるだけ
ggc っていうリポジトリで GitHub の女性ユーザをリストアップしていた人がストーキングだとか言われてアカウント停止くらったの見てたら
みんな「ストーキングきもい」って言いながら ggc つくった人の過去のブログとかブックマークさらしあげて「過去にこんなこといってたきもい」って
「キモいから」垢BANされたんだとか色々被害者ぶってるけど、件のコード、リポジトリ中のとあるファイルの中にある、この1文だけで完全に差別でアウトだと思うよ。
もちろんtwitterでの普段のtweet見る限りで判断するのが悪いとは言わない。問題は「能力」ってとこな。
これ完全に差別的偏見の垂れ流しでアウトだし、こういう意識で実装されたアプリが差別的と看做されてしまうのも必然。
あとついでに言うと、能力で女性かどうかなんてそれこそ判断できんぞ。
具体名を挙げるのはそれ自体がハラスメントになりかねんので控えるが、優秀な女性プログラマ、パッと思いつく限りでも片手の指では足らんな。
動機の時点でアウトな気はするんだけど、リポジトリはもう見れなくて確認できなくてもやっとしてる。
普通に「リストアップされている人からの通報でこうなった」とかならすんなり落ちるんだよね。
正直、一体何がどの程度悪かったのか知りたい気持ちがある。
動機がアウトなのはわかった気になってるけど、ここまで来ないと判明しないものだった。
たとえばRailsGirlsなどの女性向けエンジニアイベントで知り合った同性をリスティングしている女性もいるだろう。
そしてそれをtwitterの公開リストにしている人もいるだろう。
そういう人がいた場合、その人も同じように炎上したんだろうか。
「女性アカウントである」ことを特定した方法がかかれていないけど、ある程度までならエゴサーチで同じことは実現可能で、
公開するんなら先に本人に許可取ったほうがいいだろうけど、最悪後から言われて対応でもいいような気がするんだ。
エゴサーチで引っかかっているのであれば、間接的に公開されてしまっている情報だしね。隠したかったのであれば隠し方が足りない事案だと思う。
(要はリストアップした人とされた人以外の人が直接口を出してくる事案じゃないように思えてしまう)
大量の一方的な批判による炎上に対応させるということ自体は、いわゆるモンスターペアレントに似たような要素を感じてしまい、
最終的に規約違反になりそうな気配もあるからアカウント削除までされてる事自体は致し方なしなんだけど、
通報した側(被害者の直接の代理人ではない人に限る)もされた側も、行動開始時点の動機だけならどっちもどっちなんじゃないの？という気がする。
コメントする人が増えていっても通報側大勝利な感じの反応が多数なので、自分の反応は「普通」じゃないんだよなー。
http://d.hatena.ne.jp/shouh/20161107/1478521182
ggcについて
ggc とは Github Girls Collection の略で、女性 GitHub アカウントを Markdown でまとめたリポジトリでした。実装としては、Followings(自分がフォローしたユーザ)の中から、あらかじめリストに書いておいた女性アカウント名のみを抽出して、アバター情報などを取得し、リスト化するというものでした。GitHub API を Python で叩いていました。
リポジトリが炎上している中見ましたが、女性を❤️の数でランク付けしているように見えました。(リポジトリが消えてしまっているので曖昧な表現です…)
私はパット見でセクシャルハラスメントに当たるのではと感じました。
しかし、 http://d.hatena.ne.jp/shouh/20161107/1478521182 の記事ではpublicに晒されているデータを扱ったのになにが問題あるのかと書かれているように感じました。
このあたり
ここで思ったのは、ストーキングとは何だろう、ということです。私としては Google 検索やその他リンクなどから簡単に辿れる範囲で女性エンジニアの情報を集め、それをまとめて公開していただけで、ストーキングのつもりは毛頭ありませんでした。ストーキングって何なんでしょうね？
データを集めそれを公開しているだけならその理論も通じたのかもしれないと思いました。
ただ、データを集め、それを加工（自分の目線でランク付け）を行い、その順に並べて、publicにそれを公開していたのはセクシャルハラスメントに当たるように感じます。
じゃあこの人がいけないんですかね、もしかしたら、そういうことを考えることが出来ない環境で育ってきたのが悪いのかもしれないとか個人的には思いましたとさ。
またリポジトリはgithubのstaffにより削除されたようですが、セクシャルハラスメントではないかというgithub issueが立っていたらしいので、
githubが幕を下ろさず、issueでのやり取りを見ていたらもう少し先が見えていたのかもしれないなぁと思いました。
http://d.hatena.ne.jp/shouh/20161107/1478521182
ただこういう、性的だったりルサンチマンなモチベーションの方が
強い制作の動機になることってあるんじゃないのって思ったんですよ。
私が目をつけたのは以下でした。
キモさ（キモイことは（負の意味で）注目される）
IT 界隈は情報発信が活発であること
女性エンジニアが盛り上がり始めていること
受け取られ方は大きく違ったとはいえ、性的なモチベーションがないとは言えないと思います。
たぶん「佐々木希の例とGGCは被害者女性が存在しているかどうかで根本的に違う」というような意見も出ると予想します。
とはいえ写真集で公開しているものの入浴シーンを3D化されて(少なからず)性的なコンテンツとして消費されるということは
佐々木希さんも必ずしもネガティブな印象を受けないとは言い切れないと思います。
リストに掲載されて、コメントをつけられ嫌な気持ちになった方もいることは確かです。
ただこの一件を「キモい」「理解できない」とただ批判するのはなんだか違うのではと思い、
shouhさんがひどく傷ついているとしたらなんだか切ないなあと思って書いてみました。
作って情報発信することは素晴らしい事だし、それを注目されたいという気持ちももっともなことだと思っています。
mattnさんのツイートにあった過激にこだわるなら技術でとがればよかったのにねというのは正論すぎてぐうの音も出ませんでしたが。
GitHubアカウントが停止されたのは辛いだろうと思いますが
Javaを始めとするオブジェクト指向言語による開発になると、設計の手法も従来とは大きく変わる。
詳細設計のことだ。
ここでいう詳細設計とは、本来コードで記述する処理を、逐一日本語で書き下したものを指す。
てか、そんな物を読むくらいなら、現物のソース読めよって話だ。
だいたい、ソースに書くレベルの粒度の記述を、なんでいちいち日本語なんて表記揺れも甚だしいフォーマットで書かにゃならんのだ。
何よりソースに修正が入ると、遡って詳細設計も直さないと整合性が取れなくなるので、言うなれば二重に工数を掛けることになる。
「違うよ、設計を直して実装するんだよ」というが、合理性を重んじるSEやPGという人種が、実質同じ内容を何度も書きたがるわけがない。
それに、単体テストくらいまでの段階ならともかく、開発要員が縮小される結合テスト・システムテスト以降で、そんなことをしている余裕など現場にはない。
でも、そうなることが目に見えているにも関わらず、欲しがる客や元請が後を絶たない。
負担ばっかり増えて、尚且つ無意味な作業をやらせるなって感じ。
なんでそんなに「日本語訳」が欲しいの？
もし客がソースを読めないなら、その時に客が読みたい部分だけを元請が訳して説明すればいい(全部読みたがるヒマな客なんてそうそういないだろうし)。
そして元請はITのプロなんだから、ソースなんてスラスラ読めて当然なわけで。英語読めない英語の専門家が存在しないのと同じ理屈ね。
それこそ読み取り専用でリポジトリのアカウントの一つや二つくらいいつでも作れるので、ソース抜き打ちレビューどうぞって話だ。
とはいえ、別に何も「真実はソースただ一つ！」なんて言うつもりはない。
ソースに行き着くまでにも考えることは色々あって、その考えた結果は全て形に残さなければならない。
ソースもまた考えた結果の成果物の一形態であり、他の形態が、各フェーズで書くドキュメントなのだと思っている。
そしてドキュメントがあるお陰で、システムがトラブった時もいきなりソースの問題箇所を探し回る苦労から解放されるのだ。
ドキュメントを手がかりに「このクラスの、このメソッドが怪しい」まで行き着いてから、そこで初めてソースを確認すればいいと。
Javaだったら、ユースケース図、アクティビティ図、クラス図、シーケンス図、Javadocによるメソッド説明と読み込んでいってアタリを付け、それから当該メソッドのソースを読めばいい。
私はコミットログの書き方に悩む英語の苦手な人間である。実際、似たような人は世の中に結構いるようで、頻出単語を集計したりまとめたものは既にあって役に立つのだけれど、これらはあくまで単語の話であり、具体的な文を構成する過程でやっぱり困る部分がかなりあった。
要するに、どういう時にどういう文が使われているのか、ということを示した例文集が欲しいのである。ググると他にも「例文集があればいいのに」みたいな声はあるくせして、しかし誰も作ろうとしない。何なんだお前ら。それじゃ私が楽できないじゃないか。
ここで挙げているコミットログは全て実際のコミットログからの転載である。当然ながら各コミットログの著作権はそれぞれの書き手にある。いずれも各英文でググれば出てくるし、フェアユースの範囲なら許してくれるだろうと考え名前とプロジェクト名は割愛したが、ここにお詫びと感謝を述べておきたい。
抽出条件だが、参考にできそうなコミットログを多く含んでいそうなリポジトリをGitHubのSTARの多い方からざっと目で見て適当に選び、それぞれ最新コミットから5000件抽出した（あわせて前処理として、コミットログ冒頭のタグ情報は消去した）。
atomのみ5400件抽出していたため、計25400件のコミットログがベースである。このうち、以下の条件に合致するものは参考例にすべきでないとして一律排除した。
こうして残った8540件を眺めながら、適当に切り出したのがこの用例集である。個人的に「うーんこの」と思った表現も、散見される場合は載せた。
ということで、以下用例を羅列していく。
以上の用例をふまえ、今回の参考ログ8540件から先頭の単語を出現回数で並べると次のようになった。
| Add | 1149 |
| Fix | 1014 |
| Update | 584 |
| Remove | 566 |
| Use | 382 |
| Don't | 260 |
| Make | 228 |
| Move | 178 |
| Change | 103 |
| Rename | 85 |
| Improve | 76 |
| Avoid | 68 |
| Allow | 65 |
| Implement | 60 |
| Handle | 58 |
コミットログの基本形はもちろん動詞 + 名詞である。名詞は固有名詞、複数形、不可算名詞が多いが、単数形の場合の冠詞は a が使われるか、あるいは省略される。the はまず使われない。
何かを追加した、という表現では非常に広く Add が使われる。メソッドからテスト、ドキュメントに至るまで大概これでまかなえる。
一方、何かを修正した、という表現では広く Fix が使われる。「何か」は typo や crash といった単語からメソッド名まで幅広い名詞を取るが、動名詞はあまり取らないのと、that節は取らないのでその点は注意が必要である。
Fix は「何かが正しく動くようにした」ことを示し、正しい動作内容が何かを説明しない。そこで正しい動作内容に言及したい場合は Make sure が使われる（こちらはthat節が取れる）。ただし Fix よりもニュアンス的に重い表現と思われ、Fix を使わず Make sure ばかり使うのはちょっとキモいのではないかと思う（Ensure はさらに重い表現っぽい）。
また、Fix は typo 以外でのドキュメント修正に対して使われることは稀である。対して Update はドキュメント、コメント、テストに使われ、本体のコードの修正に対しては使われない。本体コードの修正にあわせてテストも更新したなら Update が使われる。ただ、テスト機構それ自体のバグを修正したなら Fix である。
無駄な何かを単純に除去したなら Remove を使う。これまでのもの(A)から別のもの(B)に切り替えたのであれば Use B instead of A か Change A to B が使われる。新たに何かを利用するようにしたのであれば Use を、利用を取りやめた場合は Don't use を使うことが多い。
何かをしないようにしたなら Don't を、内部実装の効率化なら Make A + 比較級/形容詞 か Improve が使われる。
中身の変更を伴わない単なる名前の変更なら Rename A to B、コードや機能の論理上の場所を移動させたなら Move A to B である。
この辺はリファクタリングと呼ばれる行為と思うが、Refactor というぼんやりした動詞はあまり使われず、このように変更内容の種類に応じて動詞が使い分けられている。
コミットログにはWhyを書くべきだ、というのを何かで見かけたので because とか since を使ったログがどの程度あるかを調べたが、8540件のうち22件だった。基本的に短く、シンプルに、一目で意味が取れるログが好まれる傾向がある。例えば get rid of とか2件しか使われておらず、圧倒的に remove である。
一方で、シンプルな単語だけど開始単語としては使われないものもある。例えば次のような単語である。Expand(9)、Extend(8)、Print(5)、Optimize(5)、Publish(4)、Append(4)、Modify(3)、Manage(2)、Revise(2)、Dump(2)、Insert(2)、Migrate(2)、Enhance(1)、Edit(1) 。いずれもカッコ内は8540件に対する冒頭での登場回数である。結局、より一般的で平易な単語で表せたり、Refactor同様に抽象度が高すぎると使われないのだろう。
8000件もログを見たおかげで、迷いなくコミットメッセージが思いつくようになったのが個人的には今回書いてて最大の収穫だった。たぶんカンニングペーパーを作る行為それ自体が効率のいい学習になるという話と同じだと思う。
このまとめも100以上用例を転載してあるので、それを読むだけでも多少は効果があるんじゃないかと思う。同じようにコミットログ書きたくねぇなぁ英語わっかんねぇなぁと思っている人にとって、何か役に立つところがあれば幸いである。
いままで3回転職したけど、うまく行ったこともあるし行かなかったこともある。いままではわりと気軽に転職先を決めてしまっていたのだけど、そろそろ慎重に行かないと後がないなという危機感を覚えたので、とりあえず今までのことを振り返って気をつけるポイントを書いてみようと思う。
これまで何をしてきたか、これから何をするつもりなのか、会社の強みは何なのか、今後考えられるリスクをどう捉えているのか。上場企業ならばIRという形で外向けに情報を発信しているので、それを読むのはかなり大事。
で、具体的に書いてなくてよくわからないところが絶対あるはずなので、それを面談で聞く。ピンと来なかったらその会社は駄目だ。
公開されているコードがなければリスクは跳ね上がる。もちろん公開していないすばらしい技術というのはあるのだけど、会社の評価という点では使えない。
GitHubに会社のアカウントがあれば分かりやすいが、それ以外でもがんばって探そう。OpenJDK, Ruby, LLVMなど大きなOSSプロジェクトのコミッタがいればちゃんとコミットをいくつか読もう。GitHubも個人リポジトリはなくても別のリポジトリにコミットしているかもしれない。
社長はエンジニアを信頼しているか。CTOがいる場合は、CTOと社長に信頼関係があるか。
技術は手段に過ぎない、ビジネスへのビジョンが大事。確かにその通り。ただしそれは、経営陣の技術者に対する信頼があればの話。
技術を目的にするな。確かにその通り。しかしいまどきSVNを使い続けていたりデプロイを手動でやっているのはさすがにヤバイ。ついでにOSSを利用することへの意見も聞いとけ。
もしそういうダメな状況を変えるために自分を雇うのだということであれば、上層部がそういう技術的なアップデートをどのくらい必要だと考えているかを聞くこと。社長が「エンジニアを君とあと何人か雇って、一年それに全力を注いでいいからバージョン管理やインフラなどの下回りを一新したい、既存の社員にも納得してもらう」というのであればいいかもしれない。権力のある人がそういう強い決意をもってないと改革は難しい。
この話は技術者ならば誰から聞いてもいい。もし面談の過程で技術者がでてこなければ、その会社は諦めよう。
ここでいうデザインは「サービス設計」のことね。デザイナー出身のマネージャーがいれば、その人と面談してデザインをどうやってしているかの具体的な流れを聞けると最高。あるいは、エンジニア・デザイナ・企画の三者がどうデザインに関わるかを聞くのでもいいかもしれない。
企画、デザイン、プロトタイピング、開発、リリース、改善、このサイクルを具体的に聞こう。直近の成功例と失敗例を聞けると最高にいい。
これは現役の技術者から聞こう。実際に自分が体験することになる日常になるのだから。
外注管理することになったらとにかく最悪だ。そうでなくても、君がもし生粋のエンジニアなら、外注にはなるべく関わらないほうが幸せだろうと思う。
以上。
"見出しでエンジニアと書いているのにプログラマの事しか書かれていない。それもソフトハウスへの転職。" という指摘をうけたのでタイトルだけ変えた。
HEAD ~1
HEADの親
HEAD ~2
HEADの親の親
HEAD ^1
HEADの1番目の親
HEAD ^2
HEADの2番目の親
HEAD
ORIG_HEAD
git merge や git reset でHEADが移動してしまう．
ORIG_HEADを使うことで移動前のHEADを指定できる．
FETCH_HEAD
git fetch によってリモートリポジトリから取得した最新のコミットを指定できる．
git log --oneline
logを一行で表示する．
git log --decorate
git log --follow FILENAME
FILENAMEのファイルの変更履歴を，たとえ途中でリネームされたとしてもそれも見る．
git log --author <name>
git log --graph
git log -p
git diff <base commit>...<opposit commit>
git log -S "string"
git bisect start <bug commit> <correct commit>
二分探索の開始
git bisect good
git bisect bad
git bisect reset
二分探索の終了
git checkout <branch name, needs to be rebased> git rebase <base of rebase>
rebase
git pull --rebase
git pull は git fetch + git merge
merge ではなく rebase したい場合に利用するのがよい．
git log --merge
git stash
内容の退避
git stash pop
退避した内容の復活
git stash list
退避した内容の一覧
git worktree
git submodule
git rebase -i HEAD~N
Nは自然数．
編集時にエディタが開くが，編集を終えてエディタを閉じてもrebaseが機能しないことがある．
その場合は次のように， .gitconfig へエディタのパスを書けばよい．
[core] editor = /usr/bin/vim
何か面白いとおもったものは、最初下手だからがんばろうってめっちゃ熱く打ち込む
だけど、ある一定のところまでくると、急にどうでもよくなる
あともう少しがんばっていれば成果がでるというか、何かを残せるところまでくるんだけど、なぜかそこでトーンが落ちる
バンドだったり、資格だったり、スポーツだったり、恋愛だったり
ソフトウェア開発技術者試験とか、受ければ受かるっていうぐらい勉強して、当日やる気なくなってバックレたり
投球練習、部内で一番めちゃめちゃ頑張ったけど、急にキャッチャーやるわって言い出したり、辞めたり
めちゃめちゃ好きだった娘と仲良くなって、付きあおうと思えば付き合えたのに、急に連絡とらなくなったり
めちゃめちゃ頑張って開発してた自分のプロダクトを、あともう少しで世に出せるってところで急にやる気がなくなってリポジトリ消したり
よくわからない、あとすこしなんだよ
もう少しだけ頑張っていれば、何か残せたはずだったし、その成功体験は大事なことだってわかってるんだけど、
気持ちがついていかない
ついていかないというより、全力で逆方向に向かう気持ちがある
perlが出来るのはkent-webのcgiで盛り上がってた時代にperlを書いていた人たちだけ。
perlでコードかける世代はもうおっさんだし、そのおっさんも出世してコードを書かない役職についてたりする。
おばさんプログラマーは結婚して退社してプログラミングすらしてないだろう。
movable typeとか終わってるよな。
開発できる人が減っていけば自然消滅間違い無し。
issueもないしperlで書かれたmovable typeってオワコンでしょ。
wordperssなら10年後も残っているだろうがmovable typeは消えているだろう。
何故movable type消えるか？
若者の成長曲線は半端なく、おじさんエンジニアは日々恐怖を覚えます。
出る杭はちゃんと打っておきましょう。
Emacs, VIM, zsh, tmuxなど…設定のいじりがいのあるツールは理想の環境を追い求めても終わりはなく、コンフィグはどんどん膨れ上がるばかりです。
それらを「一流のプログラマは、一つの道具にこだわりとことん使い尽くすもんだぜ」とでも言って、ずっとDotfilesのリポジトリばかりいじるようになってくれれば、彼らがプログラミングに費やす時間は減るはずです。
いくらアプリケーションが作れても、低レイヤのことが分からないとダメだと刷り込みます。
「プログラムがどうやって起動するか分かってる? えっ、mainを書けばそれが呼ばれる? あのなぁ、_startというのがあってだな…」
無駄に低レイヤに詳しいおじさん力を活かして、あたかも高水準言語でオレすげーしてるのは、お釈迦さまの手のひらの孫悟空みたいなものだと、思わせていくのです。
そうこうして、若者たちバイナリエディタを眺めて、「ふむふむこのファイルは〇〇だなっ」などと口にするようになったら儲けものです。高機能なIDEを使うよりも、バイナリエディタを愛用しそこに時間を使うようになるでしょう。
安定したプロダクトは、あっという間に習得してしまい、我々おじさんたちが安定するまで四苦八苦して身につけたノウハウは、「あっ、いまはそんなことしなくても大丈夫っすよ。昔は大変だったんすねw」と一笑に付される恐れがあります。
Javascript界隈など、安定しないプロダクトを積極的に使わせるように導きましょう。そこでGitHubにIssuesを上げまくるようになれば、時間を費やさせることができるでしょうし、さらには「このプロダクトはいつまでたってもクソだから、オレがもっとイケてるやつを作ることにしましたよー」なんて方向に向かわせることができれば、しめたものです。
若者の作業スピードの向上はかなりのものです。おじさんたちの体力と作業スピードでは到底かないません。
そこで、「若いんだからそんなこと手作業でやるんじゃない。ツール作っておけば、次からは一瞬で済むようになるだろうっ」と言ってやりましょう。若者がツールを作っている間に着々と作業すませてやるのです。
プレゼンというのは慣れてないと、激しく時間を使います。若者にはイベントの登壇機会を積極的にあたえ、そこで時間を使わせてやりましょう。
「ここで、〇〇って質問きたらどうする? えっ、考えてなかった? いやー、じゃあこれも調べておかないとねぇ」
なんて、いいながらレビューしてあげて、どんどん深みにはめてやりましょう。
issueを無効に出来るけどさ・・・pull requestからもコメント貰えるんだよね・・・
google翻訳使っても何言っているのかさっぱりわからないしさ・・・
中学生の頃いじめで不登校になったからあんまり英語の勉強してない・・・
当時はそんな心の余裕はなかったけどさ・・・
同じようにいじめで悩んでいる人がもしもいるなら相談機関に相談したらいいよ・・・
相談先は文部科学省のページに書いてあるから心の片隅にでも置いといて欲しい
http://www.mext.go.jp/a_menu/shotou/seitoshidou/06112210.htm
こんな大人になる前にやり直せるから・・ねっ・・・(´・ω・｀)