Masteries

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

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

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

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

仕事について

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

エンジニアのレベル

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

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

「知らない」を知る

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

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

最近の悩み

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

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

まとめ

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

www.amazon.co.jp

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

デバッグ用のコードが残っているとGitでコミットできないようにする

PerlでWebサービスやライブラリを開発している際, 「今, この変数の中には何が入っているんだろう?」となった時にはよくData::Printerを使っています. Data::Printerは非常に便利なのですが, 先日誤って勢い良くData::Printerを使って変数をダンプするコードを混入したままにcommit/pushをしてしまって, いろいろと大変なことになったので, これを防げるようにしようという気持ちになりました.

Data::Printerを使う時は, 大抵Vimのスニペットで「DDP」をuseして使うようにしています. なので, Gitでcommitする際に, Perlのコードの中に「DDP」という文字列が含まれていれば, commitに失敗するようにすれば良さそうです.

「commit時に処理を走らせる」, となればGitのpre-commitのhookを使ってやればよさそう*1, ということで次のようなpre-commitスクリプトが出来上がりました.

#!/bin/sh

if ag --perl DDP $(git rev-parse --show-toplevel) >/dev/null ; then
    echo "some file contains code for debugging: DDP"
    exit 1;
fi

grepなどで頑張っても良かったのですが, いつも使っていて必ずインストールしているagコマンドを使いました. agコマンドに対して--perlオプションを与えて, 検索対象をPerl系のファイルのみに制限*2した上で, git rev-parse --show-toplevelで取得したGitリポジトリのルートディレクトリを対象に, DDPという文言を探します. その結果, もしDDPという文言が含まれていた場合, 警告を表示した上でexit 1して, Gitのcommit処理を停止します.

まとめ

Gitのpre-commitスクリプトと, agコマンドを組み合わせて, Perl用のデバッグコードが残っている時にGitでコミットできないようにする仕組みを作りました.

agコマンドでは, 他にも--rubyとか--jsとか--phpのオプションが使えて, それぞれRuby/JavaScript/PHPに関連するファイルのみを対象にして検索をすることも出来るので, Perl以外の言語でもこのような仕組みを作ることができそうです.

*1:Gitのフックシステムについては, Git - Git フック のページなどが参考になります.

*2:拡張子が, .pl .pm .pm6 .pod .t であるファイルのみ検索対象にします

lessでファイルを開いている時に「v」キーを押すと, そのファイルをエディタで開ける!!!

…というのを知っている方はこの記事を読む必要はありません. タイトルに書いてあることが全てなので.

実際, lessのmanにも, このように書かれております:

       v      Invokes an editor to edit the current file being viewed.
              The editor is taken from the environment variable VISUAL
              if defined, or EDITOR if VISUAL is not defined, or defaults
              to "vi" if neither VISUAL nor EDITOR is defined.
              See also the discussion of LESSEDIT under the section on
              PROMPTS below.

ありがとうございました.

あわせてよみたい

blog.kazuhooku.com

plenvでインストールしたPerl環境を固定(?)できる「plenv-lock」書いた

以前, 「最近のplenv/Cartonの運用」というエントリで, plenvで管理しているPerl環境について, App::cpanminusとCartonをインストールした段階で書き込み禁止にしてしまって, それ以降余計なモジュールをインストールすることを防ぐ, みたいな話をしました.

papix.hatenablog.com

このへん, いい感じに操作したい! という気持ちが高まったので, plenv-lockというplenvのプラグインを書いてみました.

github.com

使い方

$ mkdir -p $PLENV_ROOT/plugins
$ git clone git@github.com:papix/plenv-lock.git $PLENV_ROOT/plugins/plenv-lock

こんな感じでインストールしてあげて...

$ plenv lock 5.24.1

とすれば, plenvでインストールした5.24.1の環境がロックされます. 解除するときは,

$ plenv unlock 5.24.1

という感じです.

仕組み

内部的には, ロック/アンロックの対象となるPerl環境がインストールされているディレクトリに対して, findで全てのディレクトリを見つけ出し, その全てにchmodを使って書き込み権限を落とす/付与する, という形で実装しています. 以前はchflagsで実装していましたが, find + chmodにすることで, MacだけでなくLinuxなどでも使えるようになった, と思います(試してはいない).

ちなみにこのアイデアは id:aereal さんから頂きました. ありがとうございました.

まとめ

plenv-lockという, plenvのプラグインを書きました. かなりニッチなプラグインではありますが, 興味があれば(Perl環境をロックする, という運用? とあわせて)試してみて頂けると嬉しいです.

YAPC::Kansai, お疲れ様でした!

YAPC::Kansai, お疲れ様でした. YAPC::Hokkaidoに引き続き, 今回も非常に良いYAPC::Japanでしたね! 大阪と言えば, 自分が生まれ育ち, そしてPerlを学んだ思い入れの深い地元です. ここでYAPC::Japanが開催されるというのは, 本当に感慨深いものがありました.

前回のYAPC::Hokkaidoに引き続き, 一応スタッフということで参加はしていたのですが, 実際のところ座談会にトークに... と慌ただしくてそこまでスタッフとして働けなかったのは心残りでありました. その代わり(?), 今回は本当にいろいろなイベントに絡むことができたので, そのへん紹介しつつ, YAPC::Kansaiの感想エントリにしたいと思います.

前夜祭に出ました

前夜祭のコンテンツである, 「突撃!隣の開発環境!」のトップバッターをやりました.

とにかくzshのaliasは改めて設定ファイル眺めてみると自分自身「ひどいな!!!」と言わざるをえない... というわけで, 近々あまり使ってない/覚えてないaliasはサッパリ整理していこうと心に刻みました. あと記憶に残っているのは弾さんのツッコミ(Dan the interruption)で, 初体験(?)だったので, とにかくリズムを崩されっぱなしでした. 精進しないといけませんね...

割と(大阪らしい!?)ハチャメチャな部分もあった前夜祭ですが, いろいろと印象に残ったというか, 勉強になったことも多かったです. 例えば@songmuさんが紹介していた.tigrcとかもそうで, ここ最近なるべくtigを使っていこうと試みていたので, めっちゃ参考になりました. というかtigって設定ファイルあったのか...

座談会をしました

Perl入学式座談会 〜これまでの軌跡を振り返り, そして未来へ〜」という座談会に登壇しました. 今回は自分に加えて, 古参枠(Perl入学式の始まりを知っている, 初期メンバーの1人)であるところの@azumakuniyukiさん, そして受講者からスタッフ/サポーターになった枠として@gomaaburamaxの3人で, Perl入学式についてのアレコレを語りました.

ちなみにこの座談会, 当初は自分が司会をするつもりだったのですが, 「papixが司会をすると, 延々とpapixが喋って座談会ではなくなってしまう」などの懸念が登壇者の一部から出た為, 急遽@crazygirl_loverさんに司会をお願いすることと相成りました. 結果としてこの選択は大正解だったと思っていて, 2年前のYAPC::Asiaにおける若手座談会でも発揮された定評のある司会力で, 5年目の終わりを間近に迎えていよいよ6年目(!?)を迎えるPerl入学式にとって, 「過去を, 今を, 未来 繋げる」良い節目になったのではないかな, と思っています.

トークをしました

PerlのWebアプリケーションをデプロイする時に僕達が考えたこと」というタイトルでトークをしました. 今回はちょっと反省点が多かったと思っていて, 特に20分だとどうしてもデプロイについての概論的な部分でいっぱいいっぱいになってしまって, 具体的な内容に踏み込めなかったのは悔いが残るところでした...

とはいえ, 発表資料をまとめている中で自分自身の経験も整理することができたので非常に有意義でしたし, 特に学生さんや, 趣味でプログラミングをしている方にとって, 「Webアプリケーションのデプロイ」は小さくない壁だと思っていて, そういった所にチャレンジする際の指針を考える資料としては役立てるのではないかと期待しています.

次にこういった内容で発表をする時は, 勇気を持って40分で応募して, 20分で概論を語り, 残り20分で概論を踏まえた実践的な(実務的な)内容に触れられるような構成に出来たらいいなーと思います.

トークを聞きました

利用しているBaaSが終了するときにすべきこと または Parse.com の終了と私たちの取り組み by @side_tana

とにかく壮絶といった感じで, MBaaS(Parse.com)に依存したサービスが, MBaaSのクローズに伴ってどのようにMBaaS依存から脱却していったか, その実態が語られていてとても興味深かったです.

トークの中で「MBaaSの利用は借金」と仰っていて, まさにその通りだと思うし, 利率は違えど(?), IaaSやPaaSの利用もノーリスクではなく, ある種の借金であることには違いないと思うので, そういった観点を持った技術選定って大事だなあ, と改めて思いました.

カヤックのゲーム開発・運用の「今」 力技と効率化の先に我々が目にしたものとは by @mackee_w

めっちゃ良かった. 特にトークの順番が良かったと思っていて(?), 自分のトークで自分自身がデプロイのついての概論を語って振り返った後で, こういった実際の風景を見れると, より深く理解出来た気持ちになって良かったと思います.

あとは質疑応答で, 「こういった自動化や効率化は属人化しがちだけれど, どう対処している?」という感じの質問に対して, 「少し穴を残しておいて, そこを突っ込まれたら"じゃあやってみて!"と丸投げする, そうやって自動化や効率化のためのコードに触れてもらって, 慣れていってもらう」みたいな答えをしていて, これはまさに目から鱗, 逆転の発想という感じで, 非常に感銘を受けました.

Webエンジニアに知ってほしいRDBアンチパターン by @Soudai

RDBのアンチパターンに関して, 具体的な例も織り交ぜながら解説していくという感じのトークで, 非常にタメになりました. ファントムリードやダーティリードは「りろんはしってる」という感じで, きちんと理解出来てる自信がないので, 改めて理解に努めようと思いました...

それからなんといっても, ベストトーク賞おめでとうございました! 参加者による投票形式で, B部屋というキャパシティが少ない会場だったにも関わらず, ベストトーク賞を受賞するというのは本当に凄いことだと思っていて, とにかく凄く凄いです!

なんと同じ会社の一員になることができたので, この辺りのRDBの話題, いろいろと伺えたらいいなーと改めて思いました.

そしてYAPC::Fukuokaへ...

無事YAPC::Kansaiが終わり, 次はいよいよYAPC::Fukuokaです. 既にティザーサイトが公開され, チケットの販売やトークの募集も開始しています.

yapcjapan.org

YAPC::Fukuokaは現地のFukuoka.pmとJPAの協力のもと開催される訳ですが, 実はYAPC::FukuokaについてはJPA側の代表が自分という事になっていて, Hokkaidoからスタートして, Kansaiに渡ったバトンを私達が受け取り, Fukuokaの次であるOkinawaへと繋ぐ, 重要な役割を担うことになりました. まだまだ至らぬ点も多いですが, 実行委員長である@debilityさん, そしてFukuoka.pmの皆さんやJPAのスタッフと協力しながら, YAPC::Fukuokaの開催に向けて, 頑張っていきたいと思っています.

...それではまた, 7月に福岡でお会いしましょう!!!