時計を壊せ

駆け出してからそこそこ経ったWebプログラマーの雑記

2017年のK

Keep

良かったこと、続けたいこと。

YAPC::Kansai 2017 OSAKAを主催できた

JPA再編後に実施されているYAPC::JapanはJPAと各地域PMが連携して主催する日本のPerlカンファレンスですが、 3月にやったYAPC::KansaiではJPA側のリーダーとしていろいろやらせてもらいました。 自分なりに出来る範囲で良いカンファレンスには出来たのかなと思う反面、各方面にだいぶ迷惑掛けてしまったなというのもあり、学びが多くありました。 カンファレンスを作る大変さと楽しさを身をもって知れたのはとても良かったです。

興味のあるひとはぜひ1度やってみると良いと思います。大変だけど。 持ち回り製を採用していることもあり、会を重ねる毎に経験者が増えていっているので、バックアップが年々強力になっています。 もし、ちょっとでも興味があればお気軽にご相談ください。

Perl Hackers Hub にまた書かせてもらった

雑誌に書かせてもらうの、プレッシャーすごいし、大変だけど、前回と比較してより良い記事が書けたと思うので、成長が実感できてよかった。

インフラやれた

お仕事で、新しいインフラを作れるチャンスがあったので、頼んでやらせてもらいました。 PaaSが増えてきた昨今だとあまりOSまわりをいじる機会が少なくなりましたが、とあるIaaSを使ってイチからImmutable InfrastructureでAuto Scalingな構成を組んだりできて楽しかったです。キャパシティプランニングや監視設計、負荷試験とかも含めていろいろできて楽しかった。

Perl/Goがっつり書けた

今年もPerlやらGoやらでいろいろお仕事のコードが書けてよかった。 趣味でもぼちぼち書いていたっぽい。あと、YAPC::FukuokaでAnikiのトークもできた。

ワークライフバランスが良かった

給与明細に実労働時間と勤務日数が出ていたので計算してみたところ、慣らすと年間平均で7.8時間/日くらいのペースで労働をしていたらしい。 時間で見る限りは、働きすぎずサボりすぎず、良い塩梅でバランスよく仕事ができていたようだ。

バンドのレコーディング素材のミックス作業をやってた時期とかは月平均で6時間/日くらいだったり、逆に時間に追われてた時期は月平均でも10時間/日になっていたり。とはいえ普段は良いペースで勤務できていたようだ。

もちろん、勤務時間がそのまま成果に直結するわけではないが、少なくとも裁量労働制をうっかり悪用してサボりすぎてないかという心配が解消してほっとした。

バンドが去年より活動できた

レコーディングしてデモCDを配布しました:

前と比較して完全に新しい環境でのMixとなってしまったので比較はできないけど、チャレンジができたこと自体は良かった。 前回と比較すると、一番大きな違いがドラムのレコーディングで、前回バスドラ、スネア、フロア+ライド、アンビエントのモノラル感のつよい4chだったものを、バスドラ、スネア表、スネア裏、ハイハット、ライド(+フロアタム)、ハイタム、ロータム、アンビエントの9chでやったこと。 ミックスの下処理が一気に大変になって大変だったりして、いろいろと反省が多かった。

ライブもできて、池袋Adm、山梨ボデガー東スタジオなどでライブができた。 曲も作ったり、ホームページも作ってそこで予定を公開したりできた:

www.monzllis.info

メンバーの入れ替わりもあり、一歩戻って二歩前進という感じで進んでいきたい。

来年

ソロで活動する機会がなかったので作っていきたい。

WEB+DB Press Vol.101のPerl Hackers HubにAnikiに関する記事を寄稿しました

このブログを読む方にはご存知の人が多いと思いますが、ぼくはAnikiというO/Rマッパを2015年に初めてリリースしました。ふざけた名前ですが実装と機能は真面目です。 イメージとしてはTengを自分なりにブラッシュアップしつつ少し高機能にして拡張性を高めたモノという感じです。 2016年に安定版となる1.00をリリースし、この記事を書いている今現在の最新版は2017/07/20にリリースした1.06になります。

metacpan.org

今の時代にO/Rマッパはとてもありふれており、枯れています。 安定したO/RマッパとしてはPerlだとTengやDBICが挙げられるでしょう。 では、そんな時代にO/Rを新しくつくる意義ってあるの?どうやってつくるの?Anikiはどうなってるの?という疑問は当然湧いてくることでしょう。 その問いに対する自分なりの答えとして「Anikiで学ぶ実践的なO/Rマッパの作り方」というタイトルで書かせて頂きました。

f:id:karupanerura:20171005113240j:plain

サポートサイトからダウンロードできるサンプルコードやAnikiのコードと併せて読んで頂くことでより深く理解することが出来る内容となっていますので、ぜひぜひコードを見ながら読み進めてみてください。 以前書かせて頂いたデータベースプログラミング入門の記事と併せて読んで頂くのも良いかと思います。 gihyo.jp

WEB+DB Press Vol.101は今月10月24日に全国の書店にて発売です。 ほかにも興味深い特集が沢山あるのでぜひぜひお手にとってみてください。

WEB+DB PRESS Vol.101

WEB+DB PRESS Vol.101

  • 作者: 森本利博,武井優己,SPY,久保田祐史,大倉香織,石川雅之,袴田類,山下和彦,牧大輔,穴井宏幸,加藤隆一郎,加藤佑典,金昌熙,佐藤健太,のざきひろふみ,うらがみ,久田真寛,ひげぽん,池田拓司,はまちや2,竹原,牟田裕太郎,粕谷大輔,陶山嶺,長谷川智希,石田和太郎,小林純一,WEB+DB PRESS編集部
  • 出版社/メーカー: 技術評論社
  • 発売日: 2017/10/24
  • メディア: 大型本
  • この商品を含むブログを見る

謝辞

編集を担当して頂いた技術評論社の稲尾さんをはじめ、直接監修頂いた牧さん、同僚やバンドメンバーなど各方面の関係者の方々にも様々な面で協力してもらい助けて頂きました。この場を借りて改めて御礼申し上げます。ありがとうございました。

宣伝

来年の3/3にYAPC::Okinawa 2018 ONNASONが開催されます。 現在スポンサーメニューのみ公開されていますが続々と新情報が公開される予定ですのでウォッチ頂けると幸いです。 90日以上前であれば航空券も高くはないので是非是非ご検討ください。長めに宿を取って観光や食も楽しんでもらえると良いかと思います。

yapcjapan.org

Aniki関連スライド情報

Anikiに関してはこれらも参考になるかもしれません。

www.slideshare.net

www.slideshare.net

speakerdeck.com

www.slideshare.net

Okinawa.pm #5 に参加した

最近とても活発なPerlコミュニティのひとつにOkinawa.pmがあります。

Okinawa.pmは @masakist さんをはじめに琉球大学の学生のほか、沖縄の技術者が集まるPerlコミュニティです。 有志でPerl入学式の開催も行っており、Slack Teamでのコミュニケーションも活発なので、その元気さは海を越えて日本全国のPerl Mongerにも届いていることと思われます。

話は変わりますが、ぼくはいまJPA*1の理事を務めており、JPAではPerlコミュニティへの講師派遣制度を行なっています。 これは、各コミュニティが遠方のPerl Mongerをゲストとして呼びたいときにその費用をJPAが一部ないし全額を支援する。という制度です。 JPAには「日本におけるPerlコミュニティを脈々と続くものとして盛り上げる」ことをミッションとして掲げており、その一環としてこの制度があるということになります。 もちろん、全ての要望に答えられるとは限らないのですが、各地域のPerlコミュニティにおいては是非とも活用して欲しいJPAの機能のひとつです。

さて、今回ぼくはありがたくもこの制度でOkinawa.pmに来て話してほしいというオファーを頂きました。 前述の通り、Okinawa.pmは非常に活発なコミュニティのひとつであり、それを知ってからずっと参加してみたいと思っていたのでもちろん快諾して、実際に参加したのです。

前置きが長くなりましたが、ぼくはAnikiの内部実装の話をしました。スライドはこちら。

www.slideshare.net

スライドはあんまり意味なくて、ソースをみんなで追っていくみたいなトークをやってました。

github.com

聴講者層的には初学者の方も多かったのでもう少しわかりやすさに寄ったトークをすべきだったかなと少し反省しました。

懇親会では @sela さんや @codehex さんほか琉球大の人も含めてたくさんの人と泡盛を飲みながら話してました。

琉球王朝おいしかった。

Okinawa.pm最高だったのでまた行きたい。

*1:Japan Perl Association

ISUCON6で敗北した感想

ぼくはISUCONに初回から毎年参加しているので6年参加しているということになる。
予選ができたのが4年前のISUCON3で、そのときは決勝に行けたが、それ以降の3年間は決勝に行けていないので、そろそろ人権が剥奪されそう。

様子

当日はこんなかんじだった。

なんかもうちょっとなんか書こうと思ってたはずなんだけど、だいぶ漬けてしまったし、このまま公開してしまおう。

DeNAに入社して半年経った

実は去年の9/1からDeNAで働いている。 たまに聞かれるけど、別にいまさら隠すようなものでもないので、公開しておこうかとおもう。

気づいたらもう半年くらい経ってたので感想とかを。 なお、相変わらずPerl5を中心にコードを書いている。 (知人に余計な心配をさせないためにいちおう書いておくと、例の事件があったところとは違う事業部です。)

入社していきなりモジュール管理まわりをほげほげしたり、静的解析したり、 桁がおかしい(当事者比)トラフィックを正常に捌くための負荷対策をしていったり、いろいろやってた。 最近はYAPC::Kansaiの準備と本業をいったりきたりしていたきがする。

素直な感想としては、基本的に技術レベルの高い人が多い現場ですごいなーってよくなっている。(部署にもよるのかもしれないけど) たとえばMySQLつかったアプリケーションを書いているチームなら、B+Tree Indexの特性なんて当然分かってるでしょ?みたいな、高いレベルでの当たり前を持って仕事できている感じ。HTTPやOAuthの仕様とかもけっこう高いレベルで理解している人が多い。 ほか、前職だとQA部門とかはなかったけど、ちゃんとQAやってたりとか、パートナーさんとのやりとりがあったりとか、関係する部署の人が別フロアにいたりとか、これまで出来なかったいろんな経験ができている。 リリースフローもがっちりしてたり、規模が違うとここまでやるんだと思うものもあれば、ここは楽になったなと思う面もあり、違いを楽しめていてまだまだ飽きない。

というかんじで、思ってたより忙しいですが、やりたいこともある程度できているし、いまのところ楽しく働けている。

ということで、近況報告でした。

ISUCON6のために準備していたあれこれ

気持ちが収まりきってないので感想とは別にひとまず準備していたあれこれを紹介しようとおもいます。

Anislbe

いわゆる秘伝のタレというやつです。

以下のことを事前に自動化していました。
使わなかった/役に立たなかったものもありましたが、このあたりを用意しておいたおかげで無心でansible-playbookを打てば反映出来るという感じの世界観にできてよかったとおもいます。 反省としてはコードの反映は git pull でええやろという感じだったのですが、やはりdeployスクリプトがあったほうが良いという結論になったのでそのあたりは反省の余地があったなという気持ちです。

  • 初期構築
    • percona/mackerelのdeb repositoryを追加
    • hostnameをazure上のVM名と合わせて分かりやすくする
    • 調査やライブラリの依存などで高い確率で必要になりそうなものをインストール
    • 各メンバーのユーザーを作って鍵を通す
    • passなしでsudoできるようにする
  • 各ミドルウェアの設定のデプロイ

https://github.com/karupanerura/isucon6-qualifier/tree/master/ansible

設定ファイル類

まあみてってください。

https://github.com/karupanerura/isucon6-qualifier/tree/master/config

SSH configの自動生成

https://github.com/karupanerura/isucon6-qualifier/blob/master/tools/make-ssh-config.pl

開発環境作成スクリプト

ベースのイメージをコピーして諸々のリソースを分割したVMを立ててくれるスクリプト。 こっちは id:ar_tama がやってくれたのでたぶん書いてくれるはず。

https://github.com/karupanerura/isucon6-qualifier/tree/master/tools/azure

便利情報リンク集

開始前の微妙に空いた時間とか行き詰まったときとかに読み返したりとかできて個人的にはよかった。

https://github.com/karupanerura/isucon6-qualifier#便利情報リンク集

練習

去年のISUCON5予選の後から数えて、計6回集まって過去問への再挑戦などの素振りを行いました。

この練習の成果として、チームとしての動きが板に付いてきて、昨年と比べてかなり効率的に動けた気がします。 また、オペレーションの効率化のために何が必要かもこの過程で理解が高まったとおもいます。

まとめ

来年はより効率的に動けるよう精進していきます。