CubicLouve

RSS
shoji:


羽生くんにサインを送る荒川静香姉さんがカッコよすぎるwwwwww : 無題のドキュメント

shoji:

羽生くんにサインを送る荒川静香姉さんがカッコよすぎるwwwwww : 無題のドキュメント

shyouhei:

前回の続き。

前回の時点では「git blameが密になっているところはきっと活発に編集されていたに違いない」という仮説があったわけですが、これは本当のところは、よくわからない。なぜかというと、blameというのは地層のように降り積もったコミットの表面に露頭してるところしか見せてくれないわけです。本当に活発に更新されていたかを知るには、ようするに地質平面図じゃなくて地質断面図が必要なわけ。分かりますよね。

で、それはどうやって作ればいいかというと、gitには便利なgit log -pという、こういうとき便利だけど普段は使い道のなさそーなコマンドがあって、これは生のdiffをすべてだらだらと表示してくれるわけですよ。で、diffからblameを再構成するにはdiffの+行をひたすら集めてくればいいわけだけど、その時-行も一緒に覚えておいて、あるコミットでどのコミットが上書きされたかを覚えておくことができる。そのようにすると、blameっぽいけど地層の底の方を見通すことができるコマンドというものが作成できる。

たとえばこういう出力が得られます:

いかにも更新頻度の高そうな行がどのへんかがちゃんと可視化されているのが分かりますね。

で、これだけでも結構興味深くて、たとえばeval.cで結局どこが一番ホットな箇所だったかといえばすばりここということがわかって、これはとても納得感が高い。つまり、作ってる我々からしてみても「ここは大変だった」と思える箇所なわけで、けっこうな妥当性があるんじゃないかと思いますね。なのでこれはこれで便利に使えるツールに仕上がるのではないかという気がする。

ただまあ、やっぱ図にしてみたいですよね。前回同様に。で、やってみるとこうなる。明るいほど高頻度の編集です

これ、ぱっと見で画像が暗いと感じると思うのですが、ヒストグラムがひじょうに興味深くて、全体の50パーセンタイルが一回しか更新されてないのですよ。二回以下だと76パーセンタイル。まあこれだけで絵づらは決まったようなもんです。

なので実はrubyの実装においては実は、だいたい半分はいっぱつ書きで動いてるといえる。もちろん、コメントとかも含んでるから、実際はもう少し精査しないといけないだろうけれど、それでもかなり予想より多いですね。びっくりです。

逆に言うと、八回以上も編集してる箇所が1パーセンタイル弱くらいあるわけですけども、これはあやしいー。明らかに他と傾向が違うので、こういった部分では何かまずいことが起きていたのではないか? ということが推察されるわけです。たとえば上でも例にあげたeval.cの一番熱かった部分などは、これは二転三転した部分でとても困難だった。他にもそういう所があったのではないか? と思われるわけです。これを利用することで、更新頻度からのバグ探しといったことも可能ではないかと思わせますね。

shyouhei:

前回の続き。

前回の時点では「git blameが密になっているところはきっと活発に編集されていたに違いない」という仮説があったわけですが、これは本当のところは、よくわからない。なぜかというと、blameというのは地層のように降り積もったコミットの表面に露頭してるところしか見せてくれないわけです。本当に活発に更新されていたかを知るには、ようするに地質平面図じゃなくて地質断面図が必要なわけ。分かりますよね。

で、それはどうやって作ればいいかというと、gitには便利なgit log -pという、こういうとき便利だけど普段は使い道のなさそーなコマンドがあって、これは生のdiffをすべてだらだらと表示してくれるわけですよ。で、diffからblameを再構成するにはdiffの+行をひたすら集めてくればいいわけだけど、その時-行も一緒に覚えておいて、あるコミットでどのコミットが上書きされたかを覚えておくことができる。そのようにすると、blameっぽいけど地層の底の方を見通すことができるコマンドというものが作成できる。

たとえばこういう出力が得られます:

いかにも更新頻度の高そうな行がどのへんかがちゃんと可視化されているのが分かりますね。

で、これだけでも結構興味深くて、たとえばeval.cで結局どこが一番ホットな箇所だったかといえばすばりここということがわかって、これはとても納得感が高い。つまり、作ってる我々からしてみても「ここは大変だった」と思える箇所なわけで、けっこうな妥当性があるんじゃないかと思いますね。なのでこれはこれで便利に使えるツールに仕上がるのではないかという気がする。

ただまあ、やっぱ図にしてみたいですよね。前回同様に。で、やってみるとこうなる。明るいほど高頻度の編集です

これ、ぱっと見で画像が暗いと感じると思うのですが、ヒストグラムがひじょうに興味深くて、全体の50パーセンタイルが一回しか更新されてないのですよ。二回以下だと76パーセンタイル。まあこれだけで絵づらは決まったようなもんです。

なので実はrubyの実装においては実は、だいたい半分はいっぱつ書きで動いてるといえる。もちろん、コメントとかも含んでるから、実際はもう少し精査しないといけないだろうけれど、それでもかなり予想より多いですね。びっくりです。

逆に言うと、八回以上も編集してる箇所が1パーセンタイル弱くらいあるわけですけども、これはあやしいー。明らかに他と傾向が違うので、こういった部分では何かまずいことが起きていたのではないか? ということが推察されるわけです。たとえば上でも例にあげたeval.cの一番熱かった部分などは、これは二転三転した部分でとても困難だった。他にもそういう所があったのではないか? と思われるわけです。これを利用することで、更新頻度からのバグ探しといったことも可能ではないかと思わせますね。

TDDBC Fukuoka 2013を開催しました!

2013/6/15 〜 2013/6/16でTDDBC Fukuoka 2013を開催しました。

23人参加のうち5人が学生という、自分が開催した勉強会では珍しい会となりました!

まとめ

今回は主催者ということで、コード殆ど書いてないですが振り返りを。

主催者としての振り返り

KPTで出てきた部分は除いており、個人的な振り返りです。

  • 立地、電源やネット環境等も鑑みると、会場は大分いいところを用意できたかなと思ってます。
  • 色々なところで和田さんに頼りすぎてしまった感はあります。
  • 受付、会場設営とか手順をあまり決めずになんとかなるで進めてしまって当日バタバタしてしまった。
  • デモのときはマイクを用意する。(声が聞こえないとのご指摘がありました)
  • デモのとき、見えにくいと突っ込まれてテンパリ過ぎた。(予めチェックするべきでした)
  • LT用意しておけばよかった。。。
  • 学生の参加者がそれなりにいてよかった。どういう経緯で参加したかちゃんとヒアリングしておけばよかったな、、、
  • 会としては概ね良かった気がしています

自分の中のファインプレーは、懇親会の会費を3000円/人に抑えられたことですね。(参加費も頂いた上での懇親会の会費もかかってなんか申し訳なかったです。。。)

今後

今回のTDDBCで書いたコードを復習する会は希望者がいればやってみようかと考えてます。

今回のTDDBCでは結構な数のペアがgithubを使っていて、それがレビューするときに便利なのは改めて感じました。
まだgithubに使い慣れていなかった人もいたので、福岡でgithubのハンズオンはまた開催しようかなと思ってます。
やりたい人は声かけてください。

あと、自動化についても今のプロジェクトでJenkins使って色々やっているお話とかは出来るので、これもやりたい方いればご連絡ください。

そして

次は参加者としてTDDBCに参加する

これは絶対だな。。。

最後に

@t_wadaさん
基調講演有難うございました!
またTDDBC Fukuokaが開催される時はどうぞ宜しくお願いします。

@sue445さん、@a_suenamiさん
TAとして福岡まで来てくださり本当に有難うございました!

@kisさん
お忙しい中、TAでお手伝い頂き本当に有難うございました!
あのLTはホント面白かったです。
これからもよろしくお願いします。

@kuronekomichaelさん、@koichi222さん
スタッフとしてお手伝い頂き本当に有り難うございます!

AIPさん、@murajunnさん
AIPさんのご協力で準備等がスムーズにできました!!
本当に有り難うございました!

参加者の皆様
ご参加頂き本当に有難うございました!
今回のTDDBCで質問等あれば、Twitterで#tddbcのハッシュタグをつけてつぶやくもしくは、FBのTDDBC Fukuokaのグループ(TAの方も入れちゃいました)で質問して頂ければと思います!

色々な人と話ができて、やっぱりまだまだ自分の勉強不足を痛感しました。。。
@kisに鍛えてもらおう

リンク

参加者のblog(順不同)

参加者のrepos(順不同)

TDDBC Fukuoka 2013で紹介されたページ等々(順不同)

随時追加していきますが、もれがあれば@Spring_MTまでご連絡ください

這い寄るゆろよろ日記: 残業代未払い求めるエンジニア「人間不信に陥る」

yuroyoro-blog:

 「人間不信に陥るよ」。それまで不平不満も言わず、まじめに働いていたエンジニアがある時、急に態度を変える。IT業界における労使トラブルでよく耳にする話だ。決して労働環境が整備されているとはいえない業界にあって、こうしたトラブルはいま、現場で頻繁に起きている。今回、当事者となってしまった東京都内の事業者も、「話に聞いていたが、まさか自分がという思いだ」と打ち明ける。

リモートブランチ 消すリスト

$ git branch -a —merged | grep -v master | grep remotes/origin| sed -e ‘s% *remotes/origin/%%’

unicorn_process_managerってのをGitHubに公開しました

社内で使ってるunicornのプロセス管理するスクリプトを公開してみました。
testとかほとんどないんでrubygemsには登録してないです。

restartしたときはこんな感じになります。

unicorn

依存関係がないんで、どこでも使えるはずです(多分)。。。 こういうプロセス管理のモジュールってどうやってテスト書けばいいのかなあ。

うちの会社は大丈夫だよね。。。

fluent-plugin-ses書きました

fluentdからアラートメールを送りたかったのですが、メールサーバー立てるのが面倒だったので、AWS SESのoutput pluginを作ってそれから送るようにしました。

使い方

  • confの書き方
conf 説明
aws_key_id Access Key Id
aws_sec_key Secret Access Key
from fromアドレス(SESでverifiedされているアドレス)
to 送信先(少なくとも一つは指定、カンマ区切りで複数指定できます)
cc ccのアドレス(オプション カンマ区切りで複数指定できます)
bcc bccのアドレス(オプション カンマ区切りで複数指定できます)
reply_to_addresses 返信先のアドレス(オプション カンマ区切りで複数指定できます)
subject メールのタイトル


メールの本文は、plaintextformatterで整形されたログがそのまま貼り付けてあります。

その他

AWSのモック欲しい。。。。
テスト書く時いつも悩ましい。

とある大学生の話を聞いて

テクニカルなネタをここには書いてきたけど、今回は違う感じで。

とある大学生と話してたら、”頭下げてまで日本の企業に就職したくない”と言ったので(ちょっと誇張したかな。。。)大分イラっとした。

日本ナメんなよ

海外の企業でちゃんと利益を出している企業がどれだけあるのだろうか。
(もちろんAmazonとかGoogleとかあるけれど、総体としてってことで)
まあ、まだ就活前の人だしあんまり深くは突っ込まなかったけど、何でこんなに日本の企業を低く見てしまうのか。。。

あと、”海外に行ってみたい”って言ってた。
海外に行って何が得られるのだろう。。。
少なくとも日本の大学で”学ぶ”ということをするべきではないのだろうか 。
(良い成績を取るってことではなく)
英語を勉強したいってのはわかるけど、大学生活を費やしてまでやることなのかな。。。
大学ではもっと自分から学ぶことを学ぶのが必要なのではないか。
(自分が卒業した大学は少なくともそういうことを教えてくれた。)

折角、義務教育から開放され、自分の学びたいことを学びに行っているのになぜそれをしないのか。

まあ、日本の大学の限界って言われればそれまでなんだけど。。。

海外ってそんなにいいとこなんですかね?

勢いにまかせて書いたけど、まあちょっと気になったので。

Tatsuhiko Miyagawa's Podcast: ep6 ゲスト: Naoya Ito

bulknews:

bulknews-podcast:

収録時間 41:20 | Download MP3 (23.5MB)

第6回は伊藤直也さん (@naoya_ito) をゲストに迎えて、Kindle 出版、GitHub、Google Reader などについて話しました。

第1回に続き、naoyaさんに出てもらいました。

「非公式なAPI」

後半で出てくる Google Reader APIの話で、「野良API」って言葉を使ってますが、紛らわしい表現だったかもなので、ちょっと補足。

「野良API」というと第三者が無断でつくったAPI、のように聞こえるかもですが、そうではなく、「非公式なプライベートAPI」という方が正しいかも。

ここでいう非公式なAPI、というのは、Google Reader のウェブサイトが Ajax で使っているエンドポイントや、Google公式の Reader アプリが使っているプライベートAPIをリバースエンジニアリングしたAPI、という意味で使っています。仕様についても Google は一度も公開したことはなく、有志がリバースエンジニアリングした仕様をGoogle Code上で公開 してるもので、これを feedly などは使っていた、という話です。

ゲストの人選

naoyaさんが2回めということもあって、「もう2周目」?とかTwitter で意見をもらったりしてます。

もともと、ゲストを週替りにしてインタビューする、という発想ではなくて、その時話したい「ネタ」があって、それに最適な人をキャスティングする、という発想をベースにしていました。MessagePack のissueの話、Ruby 2.0 のリリースの話、その開発者に聞くのが一番いいですよね :)

とはいえ、ネタにとらわれずに「いいとも」あるいは「徹子の部屋」的に人にフォーカスした回もあってもいいかなと思っていますし、ep4の高林さん の回なんかはそういう感じですね。

その辺もいろいろバランスをとってやって行きたいと思いますが、まだまだいろいろ試行錯誤ですので、フィードバックもらえるとうれしいです!

(出典: bulknews-podcast)

TDDBC Tokyoに参加して来ました

2013/03/16に開催されたTDDBC Tokyoに参加してきました。

主催の@katzchangさん、会場を提供してくださったVOYAGE GROUPさん 本当にありがとうございました!

作業

お題はこちら

当日自分が書いたソースはgithubにあげてあります。

ruby2.0+rspecで書いています。
一応travisにも対応しています。

振り返り

今回の課題はLtsvを扱うモジュールの実装でした。

この課題では”テストが、実装するメソッドに依存してもいいのか”ということに悩みました。
メソッドAのテストを書くためにはメソッドBを使うと簡単に書ける、逆も同様。
自分はテストは実装する他のメソッドに依存しないようにテストを書くようにしているのですが、今回はペアプロしていてそこを突っ込まれてどうしたものか悩みました。。。

今回は、テストするメソッドがインスタンス変数へアクセスするメソッドだったので、インスタンス変数を直接確認する方法を取りました(instance_variable_getとinstance_variable_setを使いました)
でも、結局はっきりとこうしたほうがいいって自信がないまま終了してしまったので、後で相談したところ、

  • テストが実装する他のメソッドに依存するのは大丈夫
  • テストのために一時的にメソッドはやしたり、アクセッサを定義する方法もある(あとでちゃんと消すのが前提)

と教わったので、今回であれば実装順はこうしてもよかったなあと反省しています。

  1. インスタンス変数のアクセッサーを作っちゃう
  2. get(or set)のテストを記述
  3. getが実装完了したらset書く
  4. setのテストはgetに依存してもOK
  5. setのテストが完了したらアクセサ消す
  6. getのテストが落ちるのでgetのテストを書きなおし

まあでも、なるべく依存したくはないですね。

その他

TODOを作る時間に前半の時間のほとんどを割いてしまった。。。
適度に考えて適度に手を動かすことが重要ですね!

あと色々な人のテストの経過が見えるのは良かったです。
大抵ライブラリとかみても綺麗な状態になって出てくるので、TDDBCではテストを書く経過が色々見れて参考になりました。

普段テストは書いているのですが、もっとテストを効率よく書くためにテストについてもうちょっと勉強しないとなあって痛感しました。(テスト駆動開発入門とかリファクタリングとか読まないと。。。)

TDDBC Fukuoka

TDDBC Fukuokaを6月中旬頃に開催する予定です。
まだ、詳細を詰めている段階ですが、2日間でガッツリ行う予定です。
詳細が決まりお知らせします。

あと、TDDBC Fukuokaを開催する前に、github workshopをする予定です。
TDDBCではペアプロをするのですが、その際一台のマシンを使ってるとキーバインドやエディターの違いでペアプロしにくいだけでなく戦争が起こる可能性があるので、githubでソースを共有して自分のマシンでソースが書けると効率が上がりそうだからです。
特にIDEがそこまで浸透していない言語(rubyとか)でよく起こるのでTDDBCに参加する前に一度githubの使い方workshopを開催してgithubを使ったコードのシェアに慣れてもらおうと思います。
(もちろんTDDBC参加しない人でも参加できるようにします!)

TDDBC Fukuokaの情報は下記FBグループにも流します。
興味が有る方は是非ご参加ください(公開グループなので参加しなくても閲覧できます)。

最期に

2013/5/13にTDDBC 長岡が開催されます!
詳細はこちらから

リンク