Masteries

技術的なことや仕事に関することを書いていきます.

YAPC::Fukuokaを終えて

YAPC::Fukuoka 2017 HAKATA, お疲れ様でした. スタッフの1人としては, とにかく当日右往左往していたら, アッという間に終わっていた… というのが正直な所でしたが, 当日ご参加頂けた皆様は楽しんで頂けたでしょうか.

今回のYAPC::Fukuokaは, 本当に素晴らしい会場と, 優秀なボランティアスタッフに恵まれたものの, それでも予期せぬ出来事が巻き起こるのが, イベント運営の怖いところです. 参加者の皆様にご迷惑をおかけした場面もあったかとは思いますが… それでも楽しかった, 得るものが多かった, 次のYAPC::Okinawa 2018 ONNNASONも是非行きたい! …などと感じて頂けたのであれば, 本当に幸いです.

YAPC::Fukuokaの終了後, スタッフは会場を片付ける手はずになっていたのですが, とにかく1日動き続けて元気がなかったので, 先に懇親会に参加させてもらっておりました. 懇親会の会場を眺めると, とにかく皆さん笑顔, 笑顔で楽しそうに会話をされていて, 思わず自分も笑顔になりましたし, なんというか, 「やってよかった…」と実感しましたね. まあお陰でビールが美味しすぎて, とにかくひたすら飲みすぎて, ひどい状態になっていた件については… 大変申し訳ございませんでした…

あとはそうですね, 今回のYAPC::Fukuokaの個人的な裏目標(?)は, 毎回YAPC::Japanに対してスポンサーとしてご協力頂いている株式会社ネコトーストラボさんのノベルティのサイリウムを有効活用したい! というもので, クロージングでそれを果たすことが出来て大変満足しています. ネコトーストラボさん, 毎回ノベルティとしてサイリウムをご用意して下さっているにも関わらず, 毎回使われずに終わっているので, 今回は是非何かしらの形で活用するぞ! と思ったりしていたのでした.

YAPC::Fukuokaでの役割

今回は, Fukuoka.pmの id:debility さんを実行委員長に迎え, Japan Perl Association側の代表を私が務める形で準備をしていきました. 自分の役割には特に肩書はありませんが, まあ言うなれば「実行副委員長」といったポジションと言えそうです.

カレンダーを見ると, 打ち合わせの為に初めて福岡に行ったのが2016年9月末頃だったので, おおよそ9ヶ月ほどYAPC::Fukuokaの準備をしていたという感じでしょうか. とはいえ, 4月〜5月くらいまでは定期的に打ち合わせをしつつ, 手が空いた時にタスクを消化していく… 程度でかなり平和ではありました. 5月に入ってくると結構忙しくなってきて, 開催が近づいてきた6月末辺りは, 結構しっちゃかめっちゃかになっていた気がします.

詳しくは, 実行委員長である id:debility さんの振り返りエントリに, 開催までのタイムラインなどなどまとめられているので, そちらを見て頂けると良さそうです.

blog.yapcjapan.org

また, YAPC::Fukuoka当日の様子は, この記事でアレコレ余計に語るより, 参加者の感想エントリなどを見るのが良さそうです.

blog.yapcjapan.org

終わった時に思ったこと

クロージングが終わって, YAPC::Fukuokaが無事に完結して, その時に思ったのが, 「あ, きっと今夢が叶ったな…」ということでした. 折角なので, その辺の話をしようかと思います. 多少エモいかもしれませんが, そのへんはご了承下さい. そういうのが苦手/嫌いな人は, きっとこの先の文章を読まない方がいいでしょう.

夢の話, 或いはバトンを繋ぐということ

自分が"Yet Another Perl Conference"というイベントに参加したのは, 2011年のYAPC::Asia 2011のときでした. 当時は大学生で, Perlを勉強し始めたばかりの時期でしたが, たまたまスカイアークの遠方からの参加者支援制度という制度を知って応募したところ何故か採択頂き, 参加したのでした.

…余談ではありますが, 当時ご支援頂いたスカイアークとスカイアークの小林社長は, 今でもファームノートとして学生支援スポンサーを継続して頂いています. 個人的には, この「学生支援スポンサー」は地味かもしれなけれど, 未来ある若者にカンファレンスを体験して頂くという意味ではものすごく重要なスポンサーメニューだと思っていて, 本当に感謝の気持ちでいっぱいです.

で, YAPC::Asia 2011の話に戻ると, 当時はまだ本当にPerlを勉強し始めたという状態で, 右も左もわからない! という状態だったけれど, 技術について熱く語るエンジニアの姿を見て感銘を受けたり, 技術力の無駄遣いとしか言えないけれどもとにかく超絶な発表(特にPerlで8ビットゲームを作る話とかは本当にエキサイティングでしたね…)に感動したり, とにかく最初から最後まで興奮しっぱなしだったことを, 今でもずっと憶えています. そしてその時に, 「この人達と, 肩を並べて働けるエンジニアになるぞ!」という夢を持ったのでした.

今は2017年, あれから6年が経ちました. 思えばその間, いろいろなことをやってきた気がします. 全国各地のPerlコミュニティに足を運んだり, Perl入学式を始めてみたり, ブログに技術ネタを書いたり, 勉強会で発表したり, Webサービスを作ってみたり… その途中で, 明らかに遠回りしていた所もあったりしましたが, 今思えばその遠回りもきっと必要な糧だったのでしょう.

いろいろな積み重ねを経て, お陰様で就活もうまく進めることができて, そこから更にいろいろなことがあり, 今ではなんと, はてなという会社で最高の仲間と最高のサービスの開発に携わることができている(もし5年くらい前の自分に, 「5年後の君は, はてなに入って id:hitode909 さん達と一緒に仕事をしているんだヨ!」と言ったら, 間違いなく「冗談を言うなら, もっと面白い冗談を言ってくれヨ!!!」と笑って返していたことでしょう)訳で, そこだけ見れば, とっくに「あの日の夢は叶っていた」と言えそうです.

ではなぜ, YAPC::Fukuokaが終わった時になって, ようやく「夢が叶った」と実感できたのか? なんとなくですが, きっとあのYAPC::Asia 2011で夢を抱くと同時に受け取っていた"バトン"を, ようやく次に渡しきれたということに, 実感が持てたから… かもしれません.

…そういえば, 「バトンを渡す」という話は, id:tomcha0079 さんの感想ブログにも書かれていましたね.

tomcha.hatenablog.jp

懇親会ではPerl入学式の @papix 校長と、今回の自分のトークは若い人たちにバトンが繋がるトークを心がけた事と、自分は @papix さんから5年前にPerl入学式に参加してバトンを受け取ったからこそ、今この場に居るといった事を話しました。 @papix さん自身も、ファームノートさんからYAPC参加の旅費支援というバトンを受けたから今があると言ってられたので、Perlのコミュニティは次から次へとバトンを繋げていく素晴らしいコミュニティだなぁと、参加する機会があって良かったと改めて感じました。

まさにこの通りなのかなー, と思っていて, 自分がYAPC::Asia 2011で受け取ったバトンを, いろいろな形で手渡していって, その結果として, 今回YAPC::FukuokaではPerl入学式卒業生として初めて id:tomcha0079 さんのトークが採択されて登壇されたり, Okinawa.pmの id:codehexid:shimitakax といった, 勢いのある若者が登場してきたり, その他いろいろなイベントが起きていったのかも? と思っています. …まあ, 沖縄の若者たちについては, 僕がバトンを渡そうが渡すまいが, 今のように勢いある活躍をしていたのは, 間違いないと思いますが.

その集大成として, 自分がバトンを受け取った場所である"Yet Another Perl Conference"というカンファレンスを, 今度は自分たちの手で作り上げて, YAPC::Fukuokaとして開催して, 次のYAPC::Okinawaに繋げることができました. 「あの日憧れた場所を自分たちの手で作り上げ, それを次に繋げる」, それがYAPC::Asia 2011で受け取ったバトンの中で, 最後まで残っていたものだったのかもしれません. だからこそ, YAPC::Fukuokaが終わった時に, 「夢が叶った」というか, 「夢を叶えきった」と思ったのでしょう.

…このバトンが, これからも繋がり続けると良いですね.

これからのこと

…まあ, アニメで言えば最終回的な展開を迎えた訳ですが, とはいえまだまだやることはたくさんあります. はてなで働くということはとにかくエキサイティングで, まだまだやりたい事は尽きないし, Perl入学式はもちろん, JPAのスタッフとしてやっていかないといけないこともたくさんあります(まずは, YAPC::Okinawaが成功するように尽力するところですね…!).

最近沼に片足を突っ込んでいる(?)アイドルマスターシンデレラガールズの楽曲に, EVERMOREという曲があり, その中にこのような歌詞があります:

先へ先へ 夢の先へ 進んでゆくと誓うよ

今まさに, そういう状態なんだろうなーと思っていて, あの日憧れた夢にようやく追いつくことができた! という所で満足せず, 更にその夢の先を目指して, これからも引き続きやっていくぞ!!! という感じです.

いろいろあるかとは思いますが, 引き続き, ご指導ご鞭撻の程, よろしくお願いいたします.

まとめ

EVERMOREめちゃくちゃ良い曲なので皆さん聞いて下さい.

www.youtube.com

購入する時はコチラ!!!

THE IDOLM@STER CINDERELLA MASTER EVERMORE

THE IDOLM@STER CINDERELLA MASTER EVERMORE

direnvは環境変数の上書きもよしなにやってくれる!

direnv, 常日頃から愛用していて, これまでは「新しい環境変数のセット(export TEST=test)」しかできないと思っていたんですけど, 今日試していたらなんと

export PATH=/path/to/tool:$PATH

みたいな, 環境変数の上書きもいい感じにやってくれる事が判明したので, 忘備録的にメモしておきます.

解説

こういうディレクトリ構成があるとして,

parent
|-- child
    |-- .envrc

childディレクトリの.envrcの中身は次のようになっているとします.

export TEST=this_is_$TEST

このとき, parentディレクトリで, 次のようにして環境変数TESTをセットします.

$ export TEST=test
$ echo $TEST
test

この状態で, cdchildディレクトリに移動すると…

$ cd child
direnv: loading .envrc
direnv: export ~TEST

こうなり, echoコマンドで環境変数TESTの中身を表示すると…

$ echo $TEST
this_is_test

.envrcで指定したように, this_is_が先頭に付くように上書きされます. さらにここから, cd ..childディレクトリを抜け…

$ cd ..
direnv: unloading

echoコマンドで環境変数TESTの中身を確認すると, なんと環境変数TESTの中身は元通りに戻っています.

$ echo $TEST
test

ユースケース

諸事情あって, 複数のバージョンのMySQLをHomebrewで管理して使い分けている時, 例えばあるアプリケーションではMySQL 5.6を使うようにしたいのであれば, そのアプリケーションのルートに.envrcを置いて,

export PATH=/usr/local/opt/mysql@5.6/bin:$PATH

と書いておけば良さそうで, こうすればこのアプリケーションの開発環境ではmysqlコマンドなどで5.6のものを優先して使ってくれるようになります. brew linkbrew unlinkを駆使して, Homebrewで利用するMySQLのバージョンを切り替える必要がなくなって, 楽そうな感じがします.

加えて, MySQLのサーバはDockerを利用して立ち上げるようにすれば, ミドルウェアの管理がかなり楽に, かつ柔軟に(アプリケーションごとに最適なものを選べるように)なりそうです.

chrome-GitHub-Issue-BadgesにPull Request送った話

chrome-GitHub-Issue-Badgesという最高のChrome拡張があります.

github.com

これはとにかく最高のChrome拡張で, GitHubに#1のようにイシューやPull Requestの番号を書いたり, 或いはhttps://github.com/motemen/chrome-GitHub-Issue-Badges/pull/9のようにIssueやPull RequestのURLを書くと, こういう感じで展開してくれてめちゃくちゃ便利, というやつです.

f:id:papix:20170518111839p:plain

最近幾つかPull Requestを送ったので, そのへんの紹介をします.

エスケープする

github.com

そのまんまで, IssueやPull RequestのタイトルにHTMLが含まれていたらそのまま表示される, ということでなんとかしてみた.

function escapeHTML(str: string) {
    return str.replace(/&/g, '&')
              .replace(/</g, '&lt;')
              .replace(/>/g, '&gt;')
              .replace(/"/g, '&quot;')
              .replace(/'/g, '&#039;');
}

素朴にこういうの実装してやっつけたのだけれど, もっと良い方法あったりするのだろうか…

Assignees全員のアイコンを出す

github.com

最近GitHubが複数人をアサインできるようになったけれど, それに対応していなかった(アサインされた人のGitHub IDを辞書順にしたときに, 先頭になる人が表示されていたっぽい. …多分)ので, 「できないかなー?」と試行錯誤していたら, なんかいい感じに出来たのでPull Requestを送ってみました.

無事マージされて(途中でPull Request出した事忘れてレビューコメントを放置してた… 本当にすいませんでした…), 多分使えるようになっているはずです. 個人的にはめっちゃ便利! と思っているので, 是非体験してみてください.

まとめ

とにかく言いたいのは, chrome-GitHub-Issue-Badges, めっちゃ便利なので皆さん是非使ってみて下さい…

このエクステンションはTypeScriptで作られているので, 「オオッTypeScript… なんか難しそう…」と最初は感じてしまうかもしれませんが(自分も最初そう思っていた), 「俺はJavaScriptを雰囲気でやっている」という感じの自分でも, 試行錯誤しながらやっていたらPull Request送れる程度には素朴だし, 規模も大きくないので, 「こういうのあったら便利では?」というアイデアがあれば, 是非実装してPull Requestを送ってみると良いと思います!!!

「オブジェクト指向のこころ」読んでた

最近, 「アプリケーションの設計」というところへの興味が湧いていて, その領域の学習をちょっとずつ取り組んでいます.

きっかけとしては, はてなに入社して, はてなブログの開発チームに配属されたというのがあり, 6年近く開発が続く, そこそこの規模のサービスを素早く進化させ続けていく為には, 良い設計を取り入れていくのは非常に重要だなあ, と痛感したというのがあります.

はてなブログというサービスを, 素早く進化させる為の施策については, 既に先達の方々がいろいろな取り組みをしていて, 例えば id:hitode909 さんのYAPC::Asia 2015の資料, 「Perlの上にも三年 〜 ずっとイケてるサービスを作り続ける技術 〜」などから, その様子を感じることができます:

speakerdeck.com

その結果として, はてなブログというサービスは「オブジェクト指向やDDD気にしなくてもシンプルに書ける」ようになっています. この辺り, 入社するまでは「本当に…?」と思っていたりもしましたが, 実際に開発に携わってみると「その通りだった…!」と実感しています.

だからといって, 「アプリケーションの設計」についての学習は後回しで… という訳ではなく, チームメンバーとサービスの開発について相談する際, この辺りの知識を増やしておくのは間違いなく役に立ちますし, 何より"特定の言語に依存しない"知識なので, (即効性はないかもしれませんが)エンジニアとしての一つの武器に成り得るのではないか, と思っています(思えば, これまでは即効性はあるけれど, 特定の技術領域に依存している学習ばっかりやってきたような気がする…).

まあ, そういう経緯があり, その第一歩として「オブジェクト指向のこころ」を読んでいました:

オブジェクト指向のこころ (SOFTWARE PATTERNS SERIES)

オブジェクト指向のこころ (SOFTWARE PATTERNS SERIES)

  • 作者: アラン・シャロウェイ,ジェームズ・R・トロット,村上雅章
  • 出版社/メーカー: 丸善出版
  • 発売日: 2014/03/11
  • メディア: 単行本(ソフトカバー)
  • この商品を含むブログ (5件) を見る

半分くらいは知っていたり, 過去に経験したりしていて(「あれってこういうパターンの名前があったのか…」みたいな)理解が進んだけれど, 残り半分くらいは結構ゆるふわな理解という感じでした.

「アプリケーションの設計」, その中にもいろいろな領域があり, それぞれの領域にまたいろいろな本があるので, 1冊の本をじっくり読むより, 幾つかの本をハシゴして, その中で理解が深まったら, 一度読んだ本をもう一度読んでゆるふわに理解していたところを固めていく, みたいな進め方の方が良さそうという気持ちがあって, 今回はいつも以上にサクサク読み進めていくことを意識してみた… ものの, 350ページくらいあって, 結局2〜3週間くらいかかってしまいました…

ゆるふわ理解ではあるものの, アプリケーションの設計に関するいろいろなキーワードがインデックス化(?)できたので, これをスタート地点に理解を深めていきたいですね.

これからの方針

とりあえず, 手元にあって薄そうだったので(理由が酷い), 次はさっくりとこれを読んでみようという気持ちです:

インターフェイス指向設計 ―アジャイル手法によるオブジェクト指向設計の実践

インターフェイス指向設計 ―アジャイル手法によるオブジェクト指向設計の実践

デザインパターン周りも, もう少ししっかり抑えておきたい気持ちがあって, GoFの本を買おうか… と思ったのですが, 結構難しいぞ! という意見もあり, まずは「増補改訂番Java言語で学ぶデザインパターン入門」から入るか…? みたいな気持ちがあります.

オブジェクト指向における再利用のためのデザインパターン

オブジェクト指向における再利用のためのデザインパターン

  • 作者: エリックガンマ,ラルフジョンソン,リチャードヘルム,ジョンブリシディース,Erich Gamma,Ralph Johnson,Richard Helm,John Vlissides,本位田真一,吉田和樹
  • 出版社/メーカー: ソフトバンククリエイティブ
  • 発売日: 1999/10
  • メディア: 単行本
  • 購入: 21人 クリック: 711回
  • この商品を含むブログ (209件) を見る
増補改訂版Java言語で学ぶデザインパターン入門

増補改訂版Java言語で学ぶデザインパターン入門

「実践ドメイン駆動設計」も, 本棚で眠っているのでちゃんと読みたい…

実践ドメイン駆動設計 (Object Oriented SELECTION)

実践ドメイン駆動設計 (Object Oriented SELECTION)

最終的には「オブジェクト指向入門」とか行けたら良さそう…

オブジェクト指向入門 第2版 原則・コンセプト (IT Architect’Archive クラシックモダン・コンピューティング)

オブジェクト指向入門 第2版 原則・コンセプト (IT Architect’Archive クラシックモダン・コンピューティング)

オブジェクト指向入門 第2版 方法論・実践 (IT Architects' Archiveクラシックモダン・コンピューティング)

オブジェクト指向入門 第2版 方法論・実践 (IT Architects' Archiveクラシックモダン・コンピューティング)

他, オススメの本などあれば是非情報を下さい. よろしくお願いします.

株式会社はてなに入社して3ヶ月が経ち, 試用期間が終わりました

さて, 2月1日に株式会社はてなに入社してから3ヶ月が経ちました. 就業規則によると, はてなにおける試用期間は3ヶ月ということで, 5月1日をもって晴れて試用期間が終わった… ハズです(特に何も言われていない).

良い節目ですし, まあ改めてこのタイミングで, この3ヶ月の感想など綴ってみましょう.

仕事について

以前の記事にも書いた通り, はてなブログの開発をしています. 既に(小規模なものが多いですが)幾つか機能追加とかもやっていて, 自分が作った機能を自分のブログで使える, というのはなかなか得難い経験だなあ… と思ったりしています.

エンジニアのレベル

エンジニアのレベルは, 入社前に「高いよな…」と思っていた以上に高くて, 特に自分が過去に応募して落選したはてなのインターンの卒業生は, 大学生のアルバイトですら凄まじい技術力と行動力を持っていて, 「マジか…」という気持ちになったりすることもありました.

とはいえ, 割とメンタル面は(思っていたよりは)安定している気がしていて, いつも通り波はあるものの, そこまで荒れていない感じがします. これまでは, 割と「自分はエンジニアとして, どこを目指せばいいのかわからない…」ということで, 精神的にも実際の行動も右往左往していた感じがしていますが, はてなに入ってからは社内に模範となるエンジニアが多数いるので, そういった方々の背中を追いながら, 作戦を立てて(?)日々の学習に取り組めている, ような気がします.

「知らない」を知る

ちょっとこう, 言葉にしにくいところがあるのですが, 「ある知見(技術, スキル, ノウハウ, 定石…)を知らない」というのは, 単に"その知見"について理解が出来ていないだけではなくて, その知見がどのように役立ち, それを習得する為にはどのようなルートが考えられるか, というところを含めて"知らない"んだなあ, という気持ちになりました.

最近は社内のエンジニアの方々の活動を見ていて, 「ナルホド, この知見があれば, こういった事ができて, ああいうメリットがあるのか. これは非常に良いし, 是非自分もやっていきたい. その為には, こういうワードが頻出するし, このへんから学習をやっていけばよさそう…?」みたいな感じで, 「ある知見を知らない」ということを, 自分なりに「知っている」状態になれている気がして, そこまで理解できれば「ヨシ! その気付きに沿って学習していこう!」と前向きに進んでいけるので, 精神的に迷わずに済んでいるのかなあ, という気がします.

最近の悩み

社内に流れる技術情報の濃度がだいぶ濃厚なのと, 入社したばかりで仕事に集中していた部分もあったりして, そこまで積極的に社外の勉強会に行くモチベーションが湧いていないのは, あんまり良くないですね.

社内の情報を発信するのも, 社外の情報を社内に取り込むのも, はてなで働くエンジニアとして大事なことだし, そこはエンジニアとしての自分の強みの1つだと思っているので, 次の3ヶ月は社外へのアウトプットやコミュニケーションという部分については力を入れていきたいと思っていますね.

まとめ

とりあえずさっくりと近況をまとめました. 他にもいろいろ「はてなに入社してびっくりした!」という話題があるので, そのへんも追々アウトプットしていきたいです. ところで最後になりましたが, こちらAmazonのウィッシュリストになります. ご査収ください.

www.amazon.co.jp

引き続き, 5月も頑張っていきましょう. よろしくお願いします.