君は牛を二頭持っている

渋谷あたりのエンジニアのブログ。OSからウェッブなフロントエンドまでとか色々。

YAPC Asia 2015 のはなし

色々あってブログ書くどころでもなかったので1ヶ月とちょっと遅れましたが、ブログ書くまでがYAPC、ということでYAPC Asia 2015行ってきた話を書きます。

続きを読む

人と人とのつながりの話

めっちゃポエム書きます。

今日(というか昨日)は普段会わない方々と合同で交流会をさせていただく機会があって行ってきました。LTとか懇親会とかの場で度々「人と人とのつながり」とかいう感じの技術とは違う側面な話を聞いて、結構意識が高まったので意識が高まっているうちにエモい話を書いておこうという感じのポストです。

文脈

「人と人とのつながり」ってワードだけ話してると全く意味不明なので一応記憶に残ってるところからコンテキストを補足しておくと、まず最初に「みんな最初はビビるかもしれないけどそんなニュービー達によちよち.rbという素晴らしいコミュニティがあるよ!」*1みたいな話を聞いたあたりから、僕個人が「そういうのもあるのか!」という感じで意識が高まり始めて、その後もLTや懇親会などで「既に所属しているコミュニティの外に出ていく姿勢!」みたいな話とか「コミュニティへの参入怖くないよ!」みたいな話を聞いて意識が高まりまくっているという状態です。

コミュニティについて

ある程度仲の良い人がある程度集まってワイワイやってコミュニティを形成してると、だんだんその内、中の人とつながりのある人が集まってきて少しずつコミュニティが大きくなって同志が連鎖的に集まって最高!みたいなのが理想かなと思いますが、実際に今まで見たり聞いたりした中では運営の問題とか色々あるようです。まあでもそのあたりは時代の流れと一緒に必要とされるコミュニティの形態や方針も変わってくるので、上手いことみんなが納得してなおかつワイワイできる場が続いていく方法を都度見つけていくしかないのかなあとか色々考えてます。ただ、人が集まらない問題に関しては今までに何回か目の当たりにしましたが、未だに「こうすればいいと思いますよ!」みたいな答えを自分の中で持てていません。

思ったこと

実際に、今までに話した人や今回話した人は、皆さん「初心者が新たに入って来るときのハードルを下げる」ようなあたりに注力してくれてて、初心者としてはすありがたいなと思うと同時に、「自分も習熟した暁には初心者を優しく歓迎してくれるポジションなりたい!!!意識高まる!!!!!」みたいな感じで意識が高まりました。素直な気持ちとして、今までに既存のコミュニティから得たもの自体は結構多いので今度はそれを新しく参加する人とかに還元したいなあと思いました。

最後に

ここまで「コミュニティに参加して人と人とのつながりを築いてワイワイやりたい!!!」みたいな話を書いておいてなんですが、とある方がおっしゃっていた「楽しいと思えることが大事」みたいな話が大前提だと思うのでみなさんも楽しいと思えることやりましょう。「これ楽しいよ!一緒にやろうぜ!」みたいなことがあったら誘っていただけると幸いです。

*1:かなり脚色が加わっているかもしれないですが記憶違いがあったらご指摘ください

2014年やり残したことリスト

2014年にやりたいとか言いつつやってこなかった悔いの多いリスト

  • Dockerで既存の環境をコンテナ化
  • CPANモジュール何か作る
  • Haskell
  • Devel::KYTProfへのpull-req(bug-fixじゃなくて追加機能、テストを書いたら提案してみる)

あと、ちょっと触ってみて今後もう少し触ってみても良いかもと思ったものリスト

  • golang
  • XS
  • Pythonのドキュメントの翻訳(これは去年からやってるけどあまり本格的にやってはない)

#Gotanda.pm #3に参加してきました

下書きのまま放置してたら年末になりましたが、Gotanda.pm #3に観客として参加してきた話です。
多分アカウント名をokazu_dmに変更する前に登録したので ”mAKudoz"で登録されてるんじゃないかなと思います。


Gotanda.pm

はじめに

id:karupanerura さん、トーク、LTの発表者の皆様、
モバイルファクトリー様ありがとうございます!

発表の感想

たよりがいのあるORM "Aniki" 構想

id:karupanerura さんの発表

Aniki - The ORM as our great brother.

  • ORM便利だけど、現存するPerlのORMは機能少なかったり、複雑過ぎたりするお...
    • だから、丁度いいのを作るお!! みたいな印象
  • シュッとしていらっしゃいました

APIのテストの話

id:ar_tama さんの発表

  • 発表資料ふっ飛ばして大変だなあと思いました(小並感
  • 他にも色々感想はあるけど内容的にあんまり書かない方向で

App-RemoteCommand

便利そう


App-RemoteCommand - SSSSLIDE

さいごに

他にも色々書きたいこととかはありますが、ひとまずこのあたりで。
みなさま良いお年をお迎えください.

Plackアプリをパフォーマンスチューニングする話

これはPerl Advent Calendar 2014の22日目のために書かれたエントリです。 前日のエントリは @ytnobody さんによる『MeCab? それDockerでできるよ』でした。

このエントリでは、ひどく遅いPlackアプリケーションをシュッと高速化しちゃおうという話のつもりでしたが、なんやらかんやらの事情が働いて時間がなくなったのでシュッとさせるために便利なCPANモジュールの紹介をさせて頂こうと思います。

今回紹介するモジュール

Devel::NYTProf - search.cpan.org

Plack::Middleware::Profiler::NYTProf - search.cpan.org

Plack::Middleware::Debug - search.cpan.org

シュッとさせる前に

「うわっ…私のアプリ、遅すぎ....?」となった時に人が取るべき行動としては、次のようになるかと思います

  1. 全体的にどれぐらい遅いかを見る
  2. 各処理の部分別にパフォーマンスを確認する
  3. 支配的に遅い箇所があればそこから直す

今回話をするモジュールはこの中で、特に2のステップで処理別にパフォーマンスを確認したい時に非常に便利です。コードに手を加えるにもまずは計測しましょう。

Devel::NYTProf

相当あちこちで紹介されつくされたDevel::NYTProfですが、まあ今回のAdventCalendarでは紹介されてないので改めて.

Devel::NYTProfはソースコードの行単位でプロファイリングしてくれるモジュールです。 ごく一部ですが、以下のような情報が記録できます - 呼び出し回数 - 平均スループット(1回の呼び出しあたりの所要時間) - 呼び出し元 このモジュール自体は汎用的なプロファイラなので、Plackアプリ以外でも利用できます。

Plack::Middleware::Profiler::NYTProf

上で紹介したDevel::NYTProfをPlackアプリケーションで使いやすい形にしてくれたものです。 この時点で残り10分のため、詳細は後日改めてリベンジ版で述べさせて頂きますが - PIDごとにレポートが出力される - レポ―トを出力する条件が指定できる などなど便利機能が付いています。

Plack::Midleware::Debug

すみません、あと3分しかないので後日に述べさせて下さい。お願いします。

その他

最近はこんなのもあるよと紹介してもらって、ここで書こうとして全く書けなかったネタ stevan/p5-plack-debugger · GitHub

まとめ

後日、実践版を書きます。 1分後に迫った明日ですが、id:papix さんが、お母上のお誕生日とのことですので何か書いてくださるとのことです。おめでとうございます。

AOJのAPI叩くスクリプト書いた

きっかけ

後輩がこんなの作って「お、ええな」と思ったので
部内AOJ進捗比較

つかいかた

``` bundle exec ruby get_aoj.rb user_id ```

その他

今回はRubyの入門として作ったのでこれを使ってもうちょっとちゃんとしたもの作りたい

ISUCON 2014予選に参加して恥を晒してきました

大分遅れましたがISUCON4に参加してボコボコにされてきました。
ISUCONってなんなの?って人はこの記事読むと良いです。
ISUCON4 オンライン予選の参加登録を開始しました : ISUCON公式Blog

すごく大雑把に言うと「Webサービスをいい感じにパフォーマンスチューニングしてスピードアップさせちゃう」*1大会です。

3人でLINE本社に行ってオンサイト予選行ってきました。ちなみに日曜日の方です。
LINE株式会社様、会場をお貸しいただきありがとうございました。

流れ

レギュレーション : ISUCON公式Blog

基本的には公式サイト見ればわかるので特徴的なところを

  • 開始したら参加者はAmazon EC2で競技に使うイメージ(AMI)を使ってインスタンスを立ち上げることができる
    • m3.xlarge(練習で付けて一日消し忘れてたら15$ぐらい持って行かれた。)
    • 提出するインスタンス以外には特に縛りはない
  • CentOSベースのLAMP環境が入っており、色々な言語で実装されたアプリケーションの中から一つを選んでパフォーマンスチューニングする
  • リクエストをたくさん捌ければ捌けるほどスコアが上がる
    • デフォルトだと2000点ぐらいのものが、DB(MySQL)のテーブルのインデックスをしっかり張ったり、ベンチマークのリクエスト数をアプリケーションの許す限り限界まで上げてみたりする
    • Memcached入れたりNginxの設定書いたり
    • DOM要素弄ったりするとベンチマークに通らなかったりする
  • ベンチマークを走らせて良いスコアが出たら、そのスコアを提出することができる
    • 何回でも提出することができるが、最後に提出したスコアが採用される
  • そんなこんなで終了したら、時間中に最後に提出したスコアを出したインスタンスを提出する

事前にやったこと


高度な情報戦の図

  • 過去の資料とかGotanda.pm(http://gotanda-pm.github.io/about.html)とかの発表資料を見つつ、チームメンバーで集まったり、各自で戦略練ったりしてた。
  • 最初は頑張ってローカル環境でVM使って練習環境立てようとしてたけど、Rubyのバージョンとかで引っかかって結構時間かかってしかも全員統一感ない感じの環境が出来上がってしまいそうだったので諦めてEC2に
  • 環境構築周りはある程度シェルスクリプトにしたものの、全然足りてなかった
  • 個人的感想だとホストは「提出用(絶対に壊さない)」+個人に1台ずつぐらいはあると嬉しい。
    • 特に今回はAmazon Web Services様のご厚意により利用可能クーポン(たしか25$分ぐらい?)をご提供いただけることとなったとのことなので豪快に使えた。ありがとうございます。
    • 逆に検証用とか言ってポンポン立てていくとだんだん把握できなくなるので面倒
  • 役割分担としてはかなりざっくりと分けるとこんな感じが良いかと思う。
    • インフラ担当:環境構築全般、ミドルウェアの導入、設定
    • アプリケーション:発行するSQLの最適化、テーブル定義の見直しなど。3人チームの場合、こちらが2人

当日

つらかった。

反省


調子にのったツイートしてすみませんでした

  • 素振りをもっと真剣に回数を重ねるべき
  • メンバー間で1週間ぐらい前にディレクトリ構成とかの標準を決めておくべきだった。直前に決めると絶対ミスる
  • 当日でも、「みんなこれは分かってるだろう」みたいなことでも意外と誰か一人しか分かってないこととかあるので、小刻みに確認していくのが大事
  • 他人の話に耳を傾けましょう
  • なんにせよこういう機会は一年に何回もあるわけではないのでもっと大事に活用するべきだった。

その他

Rubyで、PerlのNYTProfみたいなメソッド呼出単位で出力してくれるプロファイラあったら教えて下さいお願いします

*1:個人の見解であり、所属する組織の公式見解ではありません