「リポジトリ」を含む日記 RSS

はてなキーワード: リポジトリとは

2017-06-14

Golang勉強3日目ぐらいで疑問に思っている事

これは将来Golangに慣れて来た頃に読み返すメモです

学習してから3日目ぐらいだけど連続3日でやったとは言っていない。

学習時間は24時間にも満たないと思う。

モチベーションが上がった時に学習する程度。

公式チュートリアルをやってるけどやった箇所は忘れた。

英語版日本語版があるけど日本語版情報が古くないか不安

まだ半分ぐらいしかやってないけど良チュートリアルだと思う。

他のプログラミング言語と違ってチュートリアルの内容が足りないってこともなさそうだし、Golangチュートリアルだけは繰り返しやったほうが良さそう。

からGolangを学ぶならGoogleリポジトリにあるパッケージ管理depを使うほうが安心する。

まだ公式ツールじゃないけど将来なるかもしれないしならないかもしれない。

Googleのことだからgxuiみたいに更新されなくなる危険もあるよな・・・

でもプロジェクト新規作成するときrails new helloに相当するコマンドがないので不便。

スケルトン生成ツールが別途必要だけどフォルダ作るだけだからbatファイル用意するだけで良さそう。

あとGOPATHの設定もか。今のところは手動でやってるけどそのうちbatファイルにしたい。

Golang自体シンプル言語だと思う。

でもやりたいことができないのがつらい。

Rubyみたいにcursesが標準で使えない。

RubyみたいにTKも標準で使えない。

cursesぐらいは標準で出来て欲しいよ。

から他の言語はいらないのにGolangではそんなことでもライブラリを探してきてインストールしないといけない。

開発環境にはGoglandかVimがいい。

Goglandだとそのままでも十分だけどVim場合vim-goを入れるのが良い。

勉強会に参加するときは軽量ノートを持っていくので動作が軽いVimがいい。

でもryzen搭載ノートが来たらIDEに乗り換えるかもしれない。

コマンドラインツールを作るならGolangが一番簡単

cliってライブラリもあるみたいだけど標準機能flagだけで十分便利。

学習3日目でもflagの使い方は楽勝だった。

今の所もあんまりコマンドラインツールに興味ないので難しいことはしない。

とりあえず2ちゃん質問するのが良さそうだけど過疎だった。

過疎ってことはあんまり人気がない?

まだ質問するぐらい基礎的なもの学習してないけど。

やりたいことをぐぐってコピペしてる程度なのでdeferとかgo funcとかグローバル変数とか基礎的な部分はまだ知らない。

インストールが楽だけどWindows作ったらMacでも動くかは謎。

Mac mini買ってから試したい。

でもMacって高いから多分買わないと思う。

MacハードウェアしかMacOSインストールできないライセンスからWindows PCMacインストールできないかapple嫌い。

初心者だけどMac持ってる奴apple信者キモ杉と言わせてくれ

2017-05-02

マストドンAPI

マストドンリポジトリ

ttps://github.com/tootsuite/mastodon

マストドンAPIリファレンスAPI実装済みのライブラリ(サードティ)の紹介

ttps://github.com/tootsuite/documentation/blob/master/Using-the-API/API.md

マストドンAPIに関するドキュメントが置いてあるディレクトリ(色々ある)

ttps://github.com/tootsuite/documentation/tree/master/Using-the-API

マストドンアプリ認証にdoorkeeperを使ってるので認証APIはこっちを参照する必要がある

ttps://github.com/doorkeeper-gem/doorkeeper/wiki

マストドンドキュメントで紹介されてるAPI実装済みのライブラリ(サードティ)を使うのが一番ってっとり早い

以上

=====

わざわざ自前でAPIを叩くコードを書く

step1

アプリマストドンサーバー登録する

ttps://github.com/tootsuite/documentation/blob/master/Using-the-API/API.md#apps

POST /api/v1/apps

必要データをPOSTするだけ、難しくない

アプリ登録をわざわざコーディングする場合ライブラリとして作って提供する場合くらい(?)

(アプリ複数インスタンス対応させる場合はやはりコード書くしかないけど)

(登録したIDを自前サーバーで持って同一アプリで共有するとか?)

別にhtmlフォーム作って送信するだけでも登録できる

(ローカルhtmlファイル作ってブラウザ表示して必要入力してsubmit送信するだけ簡単)

<form name="regsterapp" method="POST" action="http://SERVERNAME/api/v1/apps">

<input name="client_name" type="text" value="">

<input name="redirect_uris" type="text" value="urn:ietf:wg:oauth:2.0:oob">

<input name="scopes" type="text" value="read write follow">

<input name="website" type="text" value="">

<input type="submit"></form>

step2

ユーザに対してのアプリ認証

doorkeeperについて知る必要がある

ttps://github.com/tootsuite/documentation/blob/master/Using-the-API/Testing-with-cURL.md

このページに書いてあるgrant_type=password認証法ではread権限しか貰えないぽい

grant_type=authorization_codeで認証する必要がある、これ読めば早い

ttps://github.com/doorkeeper-gem/doorkeeper/wiki/Authorization-Code-Flow

GET /oauth/authorize

必要パラメータ(※1)つけたリンクアプリ認証したいユーザに踏んでもらい許可を押してもらった上でそこで表示されるコード(RETURNED_CODE)を使う必要がある

(自前サーバーなどでリダイレクトで受け取ることもできるけど)

その表示されたコード(RETURNED_CODE)を使って次のAPIを叩くと認証完了する(アクセストークンをゲットできる)

POST /oauth/token

これもただのPOSTになるのでそんなに難しくない

さっきのアプリ登録みたいにhtmlとかで簡易にもできるけどアプリ秘密キーを使うので公開はダメでしょうな

※1

ttp://SEVERNAME/oauth/authorize?client_id=YOUR_CLIENT_ID&redirect_uri=urn:ietf:wg:oauth:2.0:oob&response_type=code&scope=read+write+follow

scopeというパラメータで取得したい権限指定する必要がある

step3

認証終わってアクセストークンをゲットしたらもうAPI使えるので

ttps://github.com/tootsuite/documentation/blob/master/Using-the-API/Testing-with-cURL.md

これの2番目に書いてあるようにHTTPのヘッダに Authorization: Bearer ACCESS_TOKEN を加えてから

APIの叩けばよい

toot(トゥート)はAPIドキュメントではstatusという表現になってる

ttps://github.com/tootsuite/documentation/blob/master/Using-the-API/API.md#statuses

POST /api/v1/statuses

がtootするためのAPI

2017-03-19

ファイル隠すのにバージョン管理ソフト良いんじゃないかと思った

gitとか

一番最初ルート部分を別にしてコミットしておいて、別ブランチに変えたら普通気づかれない。

エクスプローラ検索ツールファイル検索しても出てこない。

わざわざリポジトリログまで探すことはないだろうけどたまたま見たときにわかることがないように、大きなリポジトリクローンしてきてそこにいれるとかありかも。

Chromium みたいな大規模ならログ一覧をざっとスクロールしてもまずみつからないはず

ブランチ消して reflog だけに残すという手もありかも。

さらファイルを resources.zip にまとめておいて「圧縮した」みたいなコメントだと一覧の中から目に止まらない気がする。

念のためパスワードもつけておく。

見られたくない人にパソコン使わせたときに、ピンポイントリポジトリをみつけて reflog の中から見られたくないものコミットを見つけてパス付き zip解凍するとかまずないでしょ。

はいっても、そこまでして隠すものも見られる可能性ある人もいないけどね

2017-03-09

Docker盲信してる皆様へ

そもそも便利なのかちゃんと考えてる?

「日々Dockerfileをメンテして開発環境がこんなに楽になります!」

Dockerなので本番とも開発者同士でも同じになります!」

馬鹿じゃねーのかw?

Dockerfileメンテなんて手順書メンテとかシェルスクリプトメンテしてんのと大して変わらねーよw

そのDockerfileから作ったものが本番と同一だなんて保証はねーって気づけボケ

本番と同じものを作りたかったら本番からコンテナ作れよ

なんでビルド始めちゃうの?無駄じゃん馬鹿じゃん

それと「同じDockerfileから作ったものから環境差異はありません」なんて寝言まだ言ってるの?

yumaptリポジトリセキュリティアップデートやらで変化する以上

いつも同じ結果になるわけじゃねーだろが、(バージョンロックする方法はあるけどめんどいだろ)

本番でもコンテナを使ってますってやつら以外無理してDocker使う必要ないんじゃねーか?

お前らが欲しいのは軽いVMであって細切れのコンテナじゃねーだろ?

initを潰して,supervisor入れてプロセス管理して・・・ってどう考えてもお前らが望む世界じゃないんじゃねーか?

流行りのコンテナぽくしたいならLXDやらsystemd-nspawnの方がよっぽど筋がいい

というわけでよく考えなおせ

みんながDocker言ってるから無理やり使うって運用やめろ

2017/04/22 追記

続き書いた

http://anond.hatelabo.jp/20170422000230

2017-02-01

ホワイトリスト形式プロキシ建てるのやめてほしい

大手SE会社作業することになったけどさあ・・・

mavenもnpmもpipもgemdocker hubもつながらないような環境で開発しろとか言われてもムリだよ

CentOS公式リポジトリだけ開けてれば問題ないとか思ってんじゃねーぞ

プロキシ建てるのはいいけど、リストメンテする気がないなら、せめてブラックリスト形式にしてくれよ。仕事できないよ

2017-01-31

【開発】アンテナサイトのジェネレーターを作った

しがないWebエンジニアをしています

今年の1月からチマチマ作っていたアンテナサイトのジェネレータを公開しました

アンテナサイトメーカー

http://antena-mk.com/home

サービス説明

お好みのRSS登録するだけであなただけのアンテナサイトの完成です。

自身広告掲載できるので、お小遣い稼ぎもできます

Google Analyticsコードを使ってアクセス解析もできます

ダッシュボードにて、アクセスランキング、逆アクセスランキングなんかも見ることができます

今後はアクセスに応じて調整するような機能などを追加していく予定です。

使用技術

作ってみた感想


ぜひ使って感想ください!

2017-01-26

とあるFのFなSIer現場

他を知らないからひどいのかひどくないのか分からない。教えて

受託開発だよ編
環境
  • 会議用の長机に2人。仕切りなし、狭い
  • 引き出しは2人で1つ。共用
コンピュータ
開発環境
バージョン管理システム
ソースコード
規約
構成管理

2017-01-24

OSSコミュニティについて思ったこと

この間、某有名なリポジトリメンテナンスモード(新機能追加よりもバグ等の修正を優先にする)に入っていることを知って独り言を書こうと思った。

また、この間メンテナや開発仲間でいろんなリポジトリの現状共有の話があった。

最近、様々なOSSコミュニティ記事を見るようになったのも理由の1つかもしれない。

はじめに私は複数リポジトリメンテナをしており、その目線で書けたらと思う。

私が最初に思ったのは結局、OSSコミュニティというのは社会構成は変わらないなぁと思った。

大きな違う点として、

だと思う。

私がOSS活動するのは、志が他の開発者と同じであり楽しいと思えるから

仕事だとお金を稼ぐためというのは当たり前だし、そのために働いている。

なのでお金を稼ぐためという人もいれば、サービスを使われたいとか、もっと拡大させたいとか様々な意識があると思う。

しかし、OSSコミュニティ活動するのは物を良くしたいという部分が大きくコントリビューターやコミッターがそういう意識活動していると思う。

メンテナが減るのは当たり前で、飽きもあるだろうし家庭の事情とかもあるだろう。

また、別の興味あるプロジェクトコントビュートしたり、自分の開発に専念するといったこともあるだろう。

これは私の中で転職に似ているなって思った。

自分のペースで活動できるのでブラックではない。

OSSコミュニティというのは今の時代、多くの会社普通に使っており、市場の規模は大きいと思う。

しかメンテナの数というのはとても少なく、著名なリポジトリでも2, 3人しかいないというところもある。

みんなが知っている有名なフレームワークツールも内部を見ると、少人数で回しているのが現状である

本当にPull Requestを出してくれる方や、バグRFC等のフィードバックをしてくれる方には感謝している。

そういう方が居てこそ成り立っており、このような体験仕事では得られないと思うので大切にしていきたい。

日本人の方の参入率は自分観測範囲では結構低く、やはり敷居が高いのかなって思った。

一番最初に壁になるのが英語だと私は思う。 実際、私はそうだった。

日本だと、どうしても日本語ドキュメント情報が充実していないと流行らないというのも実際そうだ。

新規の方が参入しやすいように考え直す時期なのかもしれない。

いかコミュニティを拡大させつつ維持していくのかが難しいかというのがメンバと話していて自分の中でわかった気がする。

2016-12-27

活躍しているVimmerを教えるよ

この記事増田Vimアドベントカレンダー2016の27日の記事です。




Vimに興味を持ってるけどtwitterで誰をフォローすべきか分からない・・・

そんな迷える羊たちにデータ提供します。

vim-jp積極的活動している(していた) 人達調査してみました。

vim-jpの3つのリポジトリを見ればだいたい分かります


vim-jp/issuesでは、issue作成数、コメント投稿したissueの数を見ていきます

vimdoc-ja-workingとvital.vimでは、コミットすることが重要リポジトリだと思いますので、コミット数とPR数のみ見ていきましょう。

データは2016/12/27 17:00-19:00の期間にgithubからスクリプトで取得

vim-jp/issues issueを作成した数 (only member)


nameOpen中のissueClosedしたissue
DeaR15
Flast00
Kuniwak00
SKAhack01
Shougo1457
alpaca-tc01
basyura00
bouzuya00
cocopon00
crazymaster43
deris10
deton03
eagletmt03
h-east842
hattya21
haya14busa311
ichizok217
iyuuya00
k-takata845
koron71110
lambdalisue01
mattn39129
nocd525
presuku01
raa012124
rhysd03
ryunix00
saitoha11
splhack15
supermomonga00
syui00
thinca2868
tobynet01
todashuta02
tyru1123
ujihisa11
withgod00
ynkdir616
zchee00
zoncoen00

vim-jp/issues コメント投稿したissueの数 (only member)

nameOpen中のissueClosedしたissue
DeaR316
Flast01
Kuniwak00
SKAhack01
Shougo47168
alpaca-tc03
basyura00
bouzuya00
cocopon00
crazymaster1355
deris42
deton24
eagletmt04
h-east69372
hattya22
haya14busa422
ichizok1652
iyuuya01
k-takata78340
koron136374
lambdalisue02
mattn138489
nocd538
presuku38
raa0121416
rhysd112
ryunix10
saitoha715
splhack26
supermomonga01
syui00
thinca58189
tobynet11
todashuta115
tyru4188
ujihisa615
withgod10
ynkdir48204
zchee10
zoncoen00

vim-jp/vimdoc-ja-working Commitした回数 (all user))

nameコミット
k-takata302
ynkdir294
crazymaster256
koron239
nakinor95
mattn87
thinca64
kashewnuts47
h-east35
tyru29
rhysd24
cougar-b21
rbtnn15
deton14
sgur6
aiya0005
haya14busa5
saitoha3
Milly3
machakann2
norisio2
todashuta2
Shougo2
oshow1
lamsh1
ichizok1
miyakogi1
natnu1
pocke1
shiracha1

vim-jp/vimdoc-ja-working PRした回数 (only member)

nameOpen中のPRClosedしたPR
DeaR00
Flast00
Kuniwak00
SKAhack00
Shougo00
alpaca-tc00
basyura00
bouzuya00
cocopon00
crazymaster05
deris00
deton00
eagletmt00
h-east01
hattya00
haya14busa00
ichizok00
iyuuya00
k-takata04
koron06
lambdalisue00
mattn014
nocd500
presuku00
raa012100
rhysd01
ryunix00
saitoha00
splhack00
supermomonga00
syui00
thinca00
tobynet00
todashuta00
tyru03
ujihisa00
withgod00
ynkdir00
zchee00
zoncoen00

vim-jp/vital.vim Commitした回数 (all user)

nameコミット
thinca721
ujihisa480
tyru414
lambdalisue270
haya14busa145
rhysd118
mattn104
Shougo83
syngan60
rbtnn45
crazymaster43
kamichidu32
aomoriringo31
deris22
cohama10
hattya8
itchyny8
ichizok7
Milly5
raa01215
ryunix5
zoncoen5
aiya0004
kozo22
anekos2
basyura2
kannokanno2
suy1
deton1
koron1
m4i1
nicoder1
pocket78781
gitter-badger1
termoshtt1
alpaca-tc1
firisu1
tacahiroy1
y0za1

vim-jp/vital.vim PRした回数 (only member)

nameOpen中のPRClosedしたPR
DeaR00
Flast00
Kuniwak00
SKAhack00
Shougo05
alpaca-tc01
basyura01
bouzuya00
cocopon00
crazymaster023
deris09
deton01
eagletmt00
h-east00
hattya04
haya14busa023
ichizok06
iyuuya00
k-takata00
koron00
lambdalisue235
mattn17
nocd500
presuku00
raa012106
rhysd013
ryunix03
saitoha00
splhack00
supermomonga00
syui00
thinca154
tobynet00
todashuta00
tyru028
ujihisa011
withgod00
ynkdir00
zchee00
zoncoen02

数字で見ると一目瞭然ですね。

数字裏切りません。

数字が2桁ある人はほぼ活躍しているとみなしてよいでしょう。

綺麗に0が揃っている方々は実力を発揮していないだけなのかもしれません。

評価されるべき人が評価される世の中にしましょう。

2016-12-02

コボラーの嘆き

僕も華麗にGitHubリポジトリコミットしたやつをプッシュしたい

2016-12-01

http://anond.hatelabo.jp/20161129234656

人によって話題にするポイントが違っていつつ、これまでの持論?をここぞとばかりに開陳する人が多くて、長引いている感じですね。

エバンジェリストって名乗るのなら技術的にすごいやつじゃないとだめだろ派

一般論としては一理あるんですが、日本マイクロソフト個別論としては、ちょまどはテクニカルエバンジェリストとしての責務を果たしているようなので、なんとも。

それから一般論として技術力はGitHubだけから判断されるべきかという論点もあるでしょう。個別論としては、ちょまどのGitHubリポジトリにはそんなにすごいコードが置いてあるわけでもないようです。

派生して

エバンジェリスト嫌い派

エバンジェリストという言葉だけで虫唾が走るさぶいぼ出るという人もいます

ちょまど「オタサーの姫」派

オタサーの姫話題になるときと同じで、下の2つのどちらかもしくは両方があります

とにかく「性だ」と言いたい人も見かけました。

なお「女性エンジニアは〇〇であるべき」「そんなべきなどありません、女性かどうかで区別する時点でおかしい」などさらジェンダーな方向に向かう話題も見ました。

ちょまど嫌い派

彼女のこれまでの(主にtwitterでの?)ふるまいを嫌っている人たちというのもいるようです。元彼がどうとか。法務エディションも追加?

技術コミュニティ内にヒエラルキーを作るべきではない派

ケーキとかサイン会とかおかしい」という意見の根っこにこれを置いてる人もいれば、ケーキサイン会コミュニティ内のヒエラルキーとは別でしょ?の人もいますね。

後者についてはMSコミュニティの悪習っていうか悪臭として、MS公式発表すごい、MS中の人すごい、MVPMS表彰されたコミュニティリーダー)の人すごい、みたいな雰囲気を感じ取り、そこを嫌う人もいるようです。

MVPの人がコミュニティアクティブ活動しているのをDisるのはどうなのかなーと思いますが、でもコミュニティリーダーならむしろMVPではない人のトークを盛り立てていくべきなのかもしれませんね。例のスライド出した本人もどうやらMVPとのことで……。

コミュニティ嫌い派

もっと殺伐としてるべきなんだよ。とか、ヒューッ!見ろよやつの筋肉を!とか。

2016-11-11

ggcの件でなんで男が通報したのか

女性エンジニアを集めてた GitHub の ggc リポジトリ炎上してアカウント削除された話

http://d.hatena.ne.jp/shouh/20161107/1478521182

文章を読む限りでは、このリポジトリ第一発見者男性のようで、この人物は件のリストにいた女性友達だったようだ。

何人かGitHub通報した人がいるようだけど、その中に何人か男もいたらしい。

被害にあった女性たちが自分通報するのはまだわかるけど、通報した男たちは、この女性たちのなんなのだろうか。

確かにggcの内容は気持ち悪いし、書いた人もキモいが、通報した人のツイートを見るとなんだか良くわからない正義感に満ちあふれてて、それはそれで気持ち悪かった。

通報したらワンチャンあるのか。

2016-11-08

ggcの件でgithub謝罪してアカウント復活してもらえよとか言ってる奴

あんまり無責任発言しないほうがいいよ

復活させたら第三者による訴訟が待っている

それと、スパムと疑われて凍結された場合ならアカウントの復活はできるけど、今回のケースはまっとうな理由で凍結されたわけよ。無理に決まってるでしょう。

後、アカウント凍結経験あるから知ってるんだけど、あれはアカウント凍結されただけでアカウント削除されたわけではないので勘違いしないでもらいたい。

他人からあいつのページ見ても404になるけど、本人は自分リポジトリを閲覧できる。

http://anond.hatelabo.jp/20161108081709

ぶっちゃけリポジトリ自体女性GitHubアカウントavatarアイコン連携SNSのbioから判断)をまとめてGitHubの公開アクティティを取れるようにしただけ。

正直これだけでハラスメントって言われたらもっと詳細な個人情報を得る事も可能男性主催女性向け勉強会とかもアウトになるのではというレベル

直後はまとめられてた女性本人が削除要請のPull Request出したりして微笑ましさすらあったんだけど、

KTB先生案件と同じで「女性アカウントをまとめてる!コイツ女性ストーキングしてシコる気だ!!!」って言い出す男性アカウントに見つかって通報祭りでまずリポジトリ、その後アカウントまで消された感じ

当該のGitHubアカウントが消されたので事実関係確認し辛く通報側が大正義みたいになってるけどぶっちゃけフェミニストが騒いでるだけ

ggc っていうリポジトリGitHub女性ユーザリストアップしていた人がストーキングだとか言われてアカウント停止くらったの見てたら

みんな「ストーキングきもい」って言いながら ggc つくった人の過去ブログとかブックマークさらしあげて「過去にこんなこといってたきもい」って

集団ストーキングしててきもいなっておもった

http://d.hatena.ne.jp/shouh/20161107/1478521182

キモいから垢BANされたんだとか色々被害者ぶってるけど、件のコードリポジトリ中のとあるファイルの中にある、この1文だけで完全に差別でアウトだと思うよ。

twitter能力見る限り男性のそれなのでとりあえず除外。

もちろんtwitterでの普段tweet見る限りで判断するのが悪いとは言わない。問題は「能力」ってとこな。

これ完全に差別的偏見の垂れ流しでアウトだし、こういう意識実装されたアプリ差別的と看做されてしまうのも必然

あとついでに言うと、能力女性かどうかなんてそれこそ判断できんぞ。

具体名を挙げるのはそれ自体ハラスメントになりかねんので控えるが、優秀な女性プログラマ、パッと思いつく限りでも片手の指では足らんな。

とりあえず作者氏は、もう少し「差別全般について学んだ方が良いよ。

http://anond.hatelabo.jp/20161108000835

動機の時点でアウトな気はするんだけど、リポジトリはもう見れなくて確認できなくてもやっとしてる。

普通にリストアップされている人から通報でこうなった」とかならすんなり落ちるんだよね。

正直、一体何がどの程度悪かったのか知りたい気持ちがある。

動機がアウトなのはわかった気になってるけど、ここまで来ないと判明しないものだった。

たとえばRailsGirlsなどの女性向けエンジニアイベントで知り合った同性をリスティングしている女性もいるだろう。

そしてそれをtwitterの公開リストにしている人もいるだろう。

そういう人がいた場合、その人も同じように炎上したんだろうか。

女性アカウントである」ことを特定した方法がかかれていないけど、ある程度までならエゴサーチで同じことは実現可能で、

公開するんなら先に本人に許可取ったほうがいいだろうけど、最悪後から言われて対応でもいいような気がするんだ。

エゴサーチで引っかかっているのであれば、間接的に公開されてしまっている情報だしね。隠したかったのであれば隠し方が足りない事案だと思う。

(要はリストアップした人とされた人以外の人が直接口を出してくる事案じゃないように思えてしまう)


大量の一方的批判による炎上対応させるということ自体は、いわゆるモンスターペアレントに似たような要素を感じてしまい、

最終的に規約違反になりそうな気配もあるからアカウント削除までされてる事自体は致し方なしなんだけど、

通報した側(被害者の直接の代理人ではない人に限る)もされた側も、行動開始時点の動機だけならどっちもどっちなんじゃないの?という気がする。

コメントする人が増えていっても通報側大勝利な感じの反応が多数なので、自分の反応は「普通」じゃないんだよなー。

普通」がわからなすぎて対人恐怖症になりそうなのでダレカタスケテ

ggcリポジトリの騒ぎは誰がいけなかったのか

http://d.hatena.ne.jp/shouh/20161107/1478521182

ggcについて

ggc とは Github Girls Collection の略で、女性 GitHub アカウントMarkdown でまとめたリポジトリでした。実装としては、Followings(自分フォローしたユーザ)の中から、あらかじめリストに書いておいた女性アカウント名のみを抽出して、アバター情報などを取得し、リスト化するというものでした。GitHub APIPython で叩いていました。

リポジトリ炎上している中見ましたが、女性を❤️の数でランク付けしているように見えました。(リポジトリが消えてしまっているので曖昧表現です…)

私はパット見でセクシャルハラスメントに当たるのではと感じました。

しかし、 http://d.hatena.ne.jp/shouh/20161107/1478521182記事ではpublicに晒されているデータを扱ったのになにが問題あるのかと書かれているように感じました。

このあたり

ここで思ったのは、ストーキングとは何だろう、ということです。私としては Google 検索やその他リンクなどから簡単に辿れる範囲女性エンジニア情報を集め、それをまとめて公開していただけで、ストーキングのつもりは毛頭ありませんでした。ストーキングって何なんでしょうね?

データを集めそれを公開しているだけならその理論も通じたのかもしれないと思いました。

ただ、データを集め、それを加工(自分目線ランク付け)を行い、その順に並べて、publicにそれを公開していたのはセクシャルハラスメントに当たるように感じます

じゃあこの人がいけないんですかね、もしかしたら、そういうことを考えることが出来ない環境で育ってきたのが悪いのかもしれないとか個人的には思いましたとさ。

またリポジトリgithubのstaffにより削除されたようですが、セクシャルハラスメントではないかというgithub issueが立っていたらしいので、

githubが幕を下ろさず、issueでのやり取りを見ていたらもう少し先が見えていたのかもしれないなぁと思いました。

GGC(Github Girls Collection)の人について思ったこと

http://d.hatena.ne.jp/shouh/20161107/1478521182

こちらの記事で本人の方が経緯などについてまとめてあります

はじめリポジトリを見たときは抵抗感がありました。

ただこういう、性的だったりルサンチマンモチベーションの方が

強い制作動機になることってあるんじゃないのって思ったんですよ。

私が目をつけたのは以下でした。
キモさ(キモイことは(負の意味で)注目される)
IT 界隈は情報発信が活発であること
女性エンジニアが盛り上がり始めていること

たとえば人工知能佐々木希とお風呂に入りたかった人も

受け取られ方は大きく違ったとはいえ、性的モチベーションがないとは言えないと思います


たぶん「佐々木希の例とGGCは被害者女性存在しているかどうかで根本的に違う」というような意見も出ると予想します。

はい写真集で公開しているもの入浴シーン3D化されて(少なからず)性的コンテンツとして消費されるということは

佐々木希さんも必ずしもネガティブな印象を受けないとは言い切れないと思います


GGCに関して、全面的肯定するつもりはありません。

リスト掲載されて、コメントをつけられ嫌な気持ちになった方もいることは確かです。


ただこの一件を「キモい」「理解できない」とただ批判するのはなんだか違うのではと思い、

shouhさんがひどく傷ついているとしたらなんだか切ないなあと思って書いてみました。


作って情報発信することは素晴らしい事だし、それを注目されたいという気持ちももっともなことだと思っています

mattnさんのツイートにあった過激にこだわるなら技術でとがればよかったのにねというのは正論すぎてぐうの音も出ませんでしたが。

GitHubアカウントが停止されたのは辛いだろうと思います

これにめげず技術アイデアで素敵なもの(そして誰も不快にならないもの)を作っていってほしいなあと思っています

2016-11-05

なぜソースじゃなく詳細設計を欲しがるのか

Javaを始めとするオブジェクト指向言語による開発になると、設計手法も従来とは大きく変わる。

その結果、不要になるドキュメントが出てくる。

詳細設計のことだ。

ここでいう詳細設計とは、本来コード記述する処理を、逐一日本語で書き下したものを指す。

てか、そんな物を読むくらいなら、現物ソース読めよって話だ。

だいたい、ソースに書くレベル粒度記述を、なんでいちいち日本語なんて表記揺れも甚だしいフォーマットで書かにゃならんのだ。

何よりソース修正が入ると、遡って詳細設計も直さないと整合性が取れなくなるので、言うなれば二重に工数を掛けることになる。

「違うよ、設計を直して実装するんだよ」というが、合理性を重んじるSEPGという人種が、実質同じ内容を何度も書きたがるわけがない。

それに、単体テストくらいまでの段階ならともかく、開発要員が縮小される結合テストシステムテスト以降で、そんなことをしている余裕など現場にはない。

結果、実装と合ってないドキュメントけが放置されてしまう。


でも、そうなることが目に見えているにも関わらず、欲しがる客や元請が後を絶たない。

負担ばっかり増えて、尚且つ無意味作業やらせるなって感じ。

なんでそんなに「日本語訳」が欲しいの?

ぶっちゃけソースコードレビューでいいじゃん。

もし客がソースを読めないなら、その時に客が読みたい部分だけを元請が訳して説明すればいい(全部読みたがるヒマな客なんてそうそういないだろうし)。

そして元請はITプロなんだからソースなんてスラスラ読めて当然なわけで。英語読めない英語専門家存在しないのと同じ理屈ね。

それこそ読み取り専用でリポジトリアカウントの一つや二つくらいいつでも作れるので、ソース抜き打ちレビューどうぞって話だ。


はいえ、別に何も「真実ソースただ一つ!」なんて言うつもりはない。

ソースに行き着くまでにも考えることは色々あって、その考えた結果は全て形に残さなければならない。

ソースもまた考えた結果の成果物の一形態であり、他の形態が、各フェーズで書くドキュメントなのだと思っている。

そしてドキュメントがあるお陰で、システムがトラブった時もいきなりソース問題箇所を探し回る苦労から解放されるのだ。

ドキュメントを手がかりに「このクラスの、このメソッドが怪しい」まで行き着いてから、そこで初めてソース確認すればいいと。

Javaだったら、ユースケース図、アクティティ図、クラス図、シーケンス図、Javadocによるメソッド説明と読み込んでいってアタリを付け、それから当該メソッドソースを読めばいい。

逆に言えば、記述粒度が同じ成果物は2種類以上も要らない。整合性を保つための手間が増えるだけなので。

詳細設計書は不要というのはそういうことだ。

つーか「ソースが読めないか日本語訳を渡せ」とか甘えんな

2016-09-25

Git より Subversion のほうがいいと言っている人、老害率高い

その発言をする背景として Git が使いこなせていない、新しく勉強する気がない年配の方が多い

もちろん SVN の方が得意な処理や使い方もあって、ケースによって使い分けるまたはその使い方が好みという意図だったら問題ない

ただ、リアル世界でそれを言っている人は前者しか会ったこと無い、後者ツイッターとかはてなではたまに見かける


きょうびチーム開発するなかで分散リポジトリ使えないとかアンチパターンすぎるよね

2016-07-25

gitにおけるコミットログ/メッセージ例文集100

私はコミットログの書き方に悩む英語の苦手な人間である。実際、似たような人は世の中に結構いるようで、頻出単語を集計したりまとめたものは既にあって役に立つのだけれど、これらはあくま単語の話であり、具体的な文を構成する過程でやっぱり困る部分がかなりあった。

要するに、どういう時にどういう文が使われているのか、ということを示した例文集が欲しいのであるググると他にも「例文集があればいいのに」みたいな声はあるくせして、しかし誰も作ろうとしない。何なんだお前ら。それじゃ私が楽できないじゃないか

仕方なく自分でまとめたので、増田に垂れ流しておく。

はじめに

ここで挙げているコミットログは全て実際のコミットログから転載である。当然ながら各コミットログ著作権はそれぞれの書き手にある。いずれも各英文でググれば出てくるし、フェアユース範囲なら許してくれるだろうと考え名前プロジェクト名は割愛したが、ここにお詫びと感謝を述べておきたい。

抽出条件だが、参考にできそうなコミットログを多く含んでいそうなリポジトリGitHubSTARの多い方からざっと目で見て適当に選び、それぞれ最新コミットから5000件抽出した(あわせて前処理として、コミットログ冒頭のタグ情報は消去した)。

結果として対象としたリポジトリは以下の通り。

atomのみ5400件抽出していたため、計25400件のコミットログベースである。このうち、以下の条件に合致するものは参考例にすべきでないとして一律排除した。

こうして残った8540件を眺めながら、適当に切り出したのがこの用例集である個人的に「うーんこの」と思った表現も、散見される場合は載せた。

ということで、以下用例を羅列していく。

用例集

オプションフラグメニューを追加した
ファイルを追加した
メソッド機能を追加した
実装を別のものへ切り替えた
  • Use args.resourcePath instead of args.devResourcePath
  • Use arrays instead of while loops
  • Use auto instead of repeating explicit class names
  • Use weak pointer instead of manual bookkeeping
  • Change all uses of 'CInt' to 'Int32' in the SDK overlay
  • Change Integer#year to return a Fixnum instead of a Float to improve consistency
新しく何かに対応した/機能上の制約を取り払った
何かを使うようにした
より好ましい実装に改良した
何かを出来ない/しないようにした
  • Don't bail reading a metadata instance if swift_isaMask isn't available
  • Don't exit until the parent asks for an instance
  • Don't include Parent pointer in Nominal/BoundGeneric TypeRef uniquing
  • Don't use MatchesExtension for matching filters
  • Don't use ES6 class for AutoUpdater windows class
  • Don't use MatchesExtension for matching filters
  • Avoid `distinct` if a subquery has already materialized
  • Avoid infinite recursion when bad values are passed to tz aware fields
オブジェクトの内容や挙動確認やすくした
Assertを追加した
不要コードを除去した
コードを移動した
名前修正した
さなバグタイポ修正した, 警告を潰した
バグや好ましくない挙動修正した
テストコメントドキュメントを追加した
テストを削除した
テストコメント修正した
ドキュメント修正した

表現傾向とまとめ

以上の用例をふまえ、今回の参考ログ8540件から先頭の単語を出現回数で並べると次のようになった。

Add1149
Fix1014
Update584
Remove566
Use382
Don't260
Make228
Move178
Change103
Rename85
Improve76
Avoid68
Allow65
Implement60
Handle58

コミットログの基本形はもちろん動詞 + 名詞である名詞固有名詞複数形、不可算名詞が多いが、単数形場合冠詞は a が使われるか、あるいは省略される。the はまず使われない。

何かを追加した、という表現では非常に広く Add が使われる。メソッドからテストドキュメントに至るまで大概これでまかなえる。

一方、何かを修正した、という表現では広く Fix が使われる。「何か」は typocrash といった単語からメソッド名まで幅広い名詞を取るが、動名詞はあまり取らないのと、that節は取らないのでその点は注意が必要である

Fix は「何かが正しく動くようにした」ことを示し、正しい動作内容が何かを説明しない。そこで正しい動作内容に言及したい場合Make sure が使われる(こちらはthat節が取れる)。ただし Fix よりもニュアンス的に重い表現と思われ、Fix を使わず Make sure ばかり使うのはちょっとキモいのではないかと思う(Ensure はさらに重い表現っぽい)。

また、Fixtypo 以外でのドキュメント修正に対して使われることは稀である。対して 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以上用例を転載してあるので、それを読むだけでも多少は効果があるんじゃないかと思う。同じようにコミットログ書きたくねぇなぁ英語わっかんねぇなぁと思っている人にとって、何か役に立つところがあれば幸いである。

2016-06-29

ソフトウェアエンジニア転職するときに気をつけること

いままで3回転職したけど、うまく行ったこともあるし行かなかったこともある。いままではわりと気軽に転職先を決めてしまっていたのだけど、そろそろ慎重に行かないと後がないなという危機感を覚えたので、とりあえず今までのことを振り返って気をつけるポイントを書いてみようと思う。

自分はこんな感じのエンジニアです。

  1. 技術的には広く浅くタイプ
  2. デザインインフラは不得意
  3. マネージメントは不得意
  4. いままで所属していたのは上場企業が多かったが、スタートアップ経験済み
情報収集
IRを読め、短信だけでいいか

これまで何をしてきたか、これから何をするつもりなのか、会社の強みは何なのか、今後考えられるリスクをどう捉えているのか。上場企業ならばIRという形で外向けに情報を発信しているので、それを読むのはかなり大事

で、具体的に書いてなくてよくわからないところが絶対あるはずなので、それを面談で聞く。ピンと来なかったらその会社は駄目だ。

公開されているコードを読め

公開されているコードがなければリスクは跳ね上がる。もちろん公開していないすばらしい技術というのはあるのだけど、会社評価という点では使えない。

GitHub会社アカウントがあれば分かりやすいが、それ以外でもがんばって探そう。OpenJDK, Ruby, LLVMなど大きなOSSプロジェクトコミッタがいればちゃんとコミットをいくつか読もう。GitHubも個人リポジトリはなくても別のリポジトリコミットしているかもしれない。

面談
経営陣や部長クラス技術に対する考えを聞け

社長エンジニアを信頼しているかCTOがいる場合は、CTO社長信頼関係があるか。

技術手段に過ぎない、ビジネスへのビジョン大事。確かにその通り。ただしそれは、経営陣の技術者に対する信頼があればの話。

これはできれば上層部と平社員両方の考えを聞こう。

使っている技術スタックや将来への展望を聞け

技術目的にするな。確かにその通り。しかしいまどきSVNを使い続けていたりデプロイを手動でやっているのはさすがにヤバイ。ついでにOSSを利用することへの意見も聞いとけ。

もしそういうダメな状況を変えるために自分を雇うのだということであれば、上層部がそういう技術的なアップデートをどのくらい必要だと考えているかを聞くこと。社長が「エンジニアを君とあと何人か雇って、一年それに全力を注いでいいかバージョン管理インフラなどの下回りを一新したい、既存社員にも納得してもらう」というのであればいいかもしれない。権力のある人がそういう強い決意をもってないと改革は難しい。

この話は技術者ならば誰から聞いてもいい。もし面談過程技術者がでてこなければ、その会社は諦めよう。

デザインについてのどう考えているかを聞け

ここでいうデザインは「サービス設計」のことね。デザイナー出身マネージャーがいれば、その人と面談してデザインをどうやってしているかの具体的な流れを聞けると最高。あるいは、エンジニア・デザイナ・企画の三者がどうデザインに関わるかを聞くのでもいいかもしれない。

サービス開発手法については納得するまで聞け

企画デザインプロトタイピング、開発、リリース改善、このサイクルを具体的に聞こう。直近の成功例と失敗例を聞けると最高にいい。

これは現役の技術者から聞こう。実際に自分体験することになる日常になるのだから

外注と内製の比率とどういうとき外注するのかを聞け

外注管理することになったらとにかく最悪だ。そうでなくても、君がもし生粋エンジニアなら、外注にはなるべく関わらないほうが幸せだろうと思う。

以上。

願わくば、次の転職がうまくいかんことを。

追記

"見出しエンジニアと書いているのにプログラマの事しか書かれていない。それもソフトハウスへの転職。" という指摘をうけたのでタイトルだけ変えた。

2016-05-18

Vimが重いと思ったら_vimrcを疑うといいらしい。

コピペしまくってたせいで12000行ぐらい書いてあった。

ほとんど理解してないけどとりあえずコピペしたのばかり。

ダイエットしようと思うんだけどどこを削除していいのか分からない。

ググってみたけどサクラエディタみたいに簡単に設定できるGUIみたいなのVimに付いてないみたい。

https://github.com/marijnh/tern_for_vimリポジトリをNeoBundleでインストールしてるのに

ブラウザアクセスするとhttps://github.com/ternjs/tern_for_vim転送されるしなんかいろいろウィルス感染してるっぽい。

Windows 10だしインストールCD持ってないしどうやるのかわからないしエロ動画バックアップだけは済んだし今日はもう諦めよう。

2016-05-12

memo

Web + DBより

Git

コミットを遡る指定
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

tag名前ブランチマージ履歴を表示する.

git log --follow FILENAME

FILENAMEファイルの変更履歴を,たとえ途中でリネームされたとしてもそれも見る.

git log --author <name>

nameログ検索できる.

git log --graph

ブランチコミットグラフを表示する.

git log -p

コミット差分を表示する.

差分を見る
git diff <base commit>...<opposit commit>

コミット差分を表示する.

トリプルドット指定する必要がある点に注意しましょう.

問題のあるコミットを探す
git log -S "string"

履歴string検索する.

git bisect start <bug commit> <correct commit>

二分探索の開始

git bisect good

提示されたコミットが正しい挙動を示すとき

git bisect bad

提示されたコミットが正しくない挙動を示すとき

git bisect reset

二分探索の終了

rebase
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は自然数

過去コミットを消したり編集したりする.

最新からN個まえのコミットまでを対象編集できる.

編集時にエディタが開くが,編集を終えてエディタを閉じてもrebase機能しないことがある.

その場合は次のように, .gitconfig へエディタパスを書けばよい.

   [core]
     editor = /usr/bin/vim
フック
アーカイブ ヘルプ
ログイン ユーザー登録
ようこそ ゲスト さん