perlの変数のデータ量を測定する

perlの変数のデータ量を調べたいということがあって、何を使ったらいいか調べたんだけど、Devel::Sizeというのが便利そうだった。

こんなかんじで使える。

use Devel::Size qw(size total_size);
 
my $size = size([1, 2, 3, 4, 5]);
warn $size;

my $total_size = total_size({
    a => [1, 2, 3],
    b => {
        c => [1, 3, 5],
    },
});
warn $total_size;

sizeというのは構造のために使われている容量を出してくれるやつ。

The size function returns the amount of memory the variable returns. If the variable is a hash or an array, it only reports the amount used by the structure, not the contents.

ちゃんと容量を知りたかったらtotal_sizeというのを使わないといけない。

The total_size function will traverse the variable and look at the sizes of contents. Any references contained in the variable will also be followed, so this function can be used to get the total size of a multidimensional data structure. At the moment there is no way to get the size of an array or a hash and its elements without using this function.

ひとまずバイト単位で簡単に出してくれるので便利。ただやってみると意外とPerlメモリ使うなあという気持ちになる。

はてなで開催されたGitHub勉強会に行きました

はてなで開催された、GitHub勉強会に参加しました。

今回は勉強会自体が目標というより、GitHubの人と交流するためにいった。GitHub Kaigiでは人も多くてあんまり話せなかったので。

最近英語をちょっとずつ勉強しているのだけれど、これは実は前回のGitHubのイベントで、全く英語が話せなくて悔しい思いをして、そこから英語の勉強をし始めたという経緯があった。そこで、今回は前回のリベンジということでひとまずGitHubの人に英語で会話を仕掛けていった。

実際に聞いたこととしては

• リモートワークしてるけど、開発フローを整えるチームがあるの?
• issueとpull requestを紐付ける機能なくなるって言ってるのどうして
• pull requestを再レビューする時どうしてるの、二つのcommitのcompareビューでレビューしたいんだけど

らへん。

開発フローを整えるチームというのはあるらしい。でもそれはそんなに人数がいないらしい。250人今は働いているらしいけど、その中で数人と言ってた気がする。あとはみんな気が向いたときにいろいろ作り始めるんだよっていってて、そのへんはまあ一緒だなと思った。

issueとpull requestを紐付ける機能の質問は実はあんまり聞き取れなくてよく分からなかった。issueはpull requestと一対一対応してないこともあってわかりづらいという話をしていた気もする。とはいえなくさないでほしいな。

pull requestをレビューしてもらって、更にそれを修正した後、その修正をレビューしたいことがある。しかし現状はpull request全体のFiles Changesを見るか、修正commitを１つずつ見ていくしか無い。これ困るからcompare viewでなんとかコメント付けられないかなって要望出したら、ああそれは機能開発チームにフィードバックしておくよって言われた。前回も同じ質問したのであうたびに質問を繰り返したい。

ひとまず英語を流暢に会話したり、相手の言っていることを大体理解するということはかなわなかったものの、前回のように喋りかけることも出来ないし、伝えることも出来ないという状態からは脱した気がする。もうちょっと会話を成り立たせたいので、さらに英会話なんとかしたい。

github kaigi感想

github kaigiに参加して、発表したりとかした。発表内容についてはまた別で紹介するとして、感想だけ書く。

今回かなり印象に残ったのは「How GitHub Works」、「GitHubで
雑誌・書籍を作る」、「pplog.net の作り方( ˘ω˘) 」の三本。

　「How GitHub Works」では、GitHubではどうやって良い仕事環境とかやりがいのある仕事を作っていっているか、みたいな話だった。その中でどうやってモチベーションを保ってもらうかみたいな話があって、外的要因と内的要因があって、給料とか設備とかの外的要因も大事だけど、それと同様に仕事の柔軟性とかやりがいみたいな内的要因も大事だよねと言っているのが面白かった。
　柔軟性という話題でリモートワークについて触れていたけど、受けた印象として、やはりリモートワークを達成するために、リモートワークを潤滑にするための仕組みづくりにかなり力を入れているなあという印象を持った。今のところはようやくリモートワークを導入できるくらいのツールは揃ってきたけど、自然にリモートワークを達成できるところまではいけてなくて、リモートワークは良い反面、コストをかけるのは仕方ないという意識を持たないとまだうまく行かなそうだなーと思った。
　とは言え、リモートワークだと柔軟性も高くて、仕事以外の部分で非常に良いというのはそのとおりなので、なにかうまく出来ると嬉しい。

　「GitHubで
雑誌・書籍を作る」も良かった。本を書くにしても何にしても、一番最初にやる時ってあんまりノウハウがなくて、とにかく一人で悩み続けるということになりがちなので、それをうまくGitHubを利用して早めにフィードバックするというのは素晴らしいと思った。まだ書籍とか書いたこと無いけど、ぜひ何かしら書きたいので、書くことになったらこういう感じで回してもらえると非常に書きやすそうだなと思った。

　「pplog.net の作り方( ˘ω˘) 」も印象に残ってる。Poem Driven Development、本当に良いこと言ってて、最初にPoemありきみたいなこと言ってたけど、結局何かを作る時はどういう世界にしたいかとか、こういうことに困ってるからそこを解決したいんだとか、なぜそれを作るかをはっきりさせる必要があって、かつそれをずっと持ち続けられるようにどこかに書いておくべきとかいう話してたと思ってて、すごく印象に残った。えてして、状況の変化によりサービスの方向性がぶれぶれになって、みんな何作ってるか分からないことになることが多いので、きちんと最初にPoem作ってどっかに書こうとか言ってるのは良い。

　github kaigi、個人的には面白い発表ばっかりで、満足度高かった。自分も500人の前で発表する機会とかこれまで無くて、非常に良い体験が出来た。発表緊張してなさそうとか言われたけど、発表前は結構緊張してて、けどなんか500人の前に立ったら、ああなんか500人ってこんなに人いる感じなのか面白いな、って感じになって、逆に落ち着いてきて、安定して発表できた。

　良い経験でした。運営の皆様お疲れ様でした。