Masteries

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

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月も頑張っていきましょう. よろしくお願いします.

デバッグ用のコードが残っていると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