ほとラボ

It works!

CTF に入門した

f:id:hoto17296:20161218214743p:plain

ISUCON で失われた人権を取り戻すために CTF にチャレンジしようということになり、 id:sota1235 が CTF 練習会を開催してくれた。

sota1235.hatenablog.com

CTF とは

コンピュータセキュリティの分野におけるキャプチャー・ザ・フラッグ(CTF)は、コンピュータセキュリティ技術の競技である。CTFは通常、参加者に対しコンピュータを守る経験に加え、現実の世界で発見されたサイバー攻撃への対処を学ぶ教育手法として企画されている。「ハッカーコンテスト」「ハッキング大会」「ハッキング技術コンテスト」「ハッカー大会」などとも訳される。

キャプチャー・ザ・フラッグ - Wikipedia

セキュリティ版の ISUCON というイメージでだいたい合ってると思う。

結果

  • 用意されていた問題の8割くらい解けた
  • 既知平文攻撃、難しそうというイメージあったけどやってみたら*1普通に解けたので嬉しかった
  • SQL インジェクションが苦手っぽい、経験値が足りない
  • Web 系の問題でも意外と知らないテクニックが多い
    • スペースを入れられない場所に代わりに /**/ を入れて XSS する、とか

懐かしさがある

中学生のときに「隠しページ探し」みたいなのが流行っていて自分も問題を作って公開していたりした。 HTML のソースとか画像の Exif とか暗号化 zip とかにパスワードを仕込んでそれを探させる、という遊び。

CTF をやったらあのときの楽しさを思い出してきた。 あのときの問題より超難しいけど。

まとめ

  • 思ってた以上に楽しい ✌('ω'✌ )三✌('ω')✌三( ✌'ω')✌
  • 来年の SECCON 出てみたくなってきた
  • id:sota1235id:yagihashoo ありがとうございました!!!

*1:PkCrack を使ったら

おうち探しを支える技術

どうも既婚者エンジニア各位です \( 'ω')/

というわけで【その2】妻・夫を愛してるITエンジニア Advent Calendar 2016 16日目を書く @hoto17296 です。 そろそろ結婚して1年になります。 ちなみに 2日目 がウチの嫁です。

15日目は @c5meru さんの フルリモート旦那のすゝめ - めるノート でした。 @polidog さんと結婚されたというのは知っていたんですが、出会ったのが僕が主催する Gotanda.js だったと最近知ってビックリしました。 人生を変えるようなキッカケの場を作ることができて大変光栄です。 おめでとうございます!!

さて、今回は遠距離おうち探しを支えた技術について書きます。

遠距離おうち探しミッション

結婚する前、新卒1年目だった僕は東京で一人暮らしをしていましたが、嫁は愛知の大学に通っていて、嫁が東京に就職するのを機に二人暮らしを始めようという流れでした。

そんな事情から、遠距離でありながら新居を探さないといけないという、地味に大変なミッションをこなさなければなりませんでした。

おうち探しはプロジェクト

はじめに言っておきますが、おうち探しはプロジェクトです。

良い家を見つけるためには「メンバー(嫁)とコミュニケーションをとり」「計画を立て」「情報を収集・分析し」「意思決定する」必要があります。

また、家とは一度決めたらそこで少なくとも1,2年は過ごすことになるため、そこでの意思決定を誤ると大きな損害になりかねません。おうち探しは日常生活における重大なプロジェクトと言えるでしょう。

1. おうち探しチャンネルを作る

おうち探しに限らず、複数人で何かを達成するためにはコミュニケーションが必須です。 遠距離のため会って相談できないとなれば、なにかしらのコミュニケーション基盤が必要になってきます。

ここで大事なのは 普段の会話とは違うチャンネルを用意する ということです。 おうち探しでは物件情報を溜め込んでおいてあとから振り返るという使い方をするので、普段の会話に埋もれないようにしておくと便利です。 僕らの場合はお互いエンジニアということもあり、普段のやりとりには Slack を使っていたのでそこに #rooooooom というチャンネルを新しく作りました。 普段 LINE でやりとりしている場合であれば新しくおうち探し用のグループを作るといいでしょう。

2. 新しい暮らしをイメージする

プロジェクトを進めるためにはまず ゴールイメージを持つ ことが大切です。

「あ〜、二人暮らしってこんなもんかな〜〜〜」とイメージできるようになるまで SUUMO や HOME'S を雑に読み漁りましょう。 この時点ではまだ何かメモをしたり条件を絞ったりする必要はありません。

夢を膨らませてテンションを高めていきましょう。

3. ふたりの希望条件を整理する

「物件の良さ」とは概ね「部屋の条件」と「場所の条件」で決まります。 これらふたつの条件について、ふたりの希望条件をあらかじめ整理してから物件探しをはじめましょう。

ここを疎かにすると後でモメる原因になりますし、これらの条件を明確にしておくことで候補物件を絞り込んでいくことがとても簡単になります。

部屋の条件を整理する

数多ある条件それぞれについて

  • 強く希望する条件
  • できれば満たしていると嬉しい条件
  • どうでもいい条件

に分類しましょう。

f:id:hoto17296:20161214224852p:plain

場所の条件を整理する

部屋そのものの条件も重要ですが、それと同じくらい重要なのが「場所」です。

「治安・雰囲気」「家賃相場」「最寄り駅」「スーパー・コンビニ」など、地理情報に関する変数は多く、整理するのが意外と大変ですが、そんなときは Google マイマップを使うと便利です。

f:id:hoto17296:20161214224203p:plain

4. 内見しにいく

ここでようやく内見です。

可能な限り内見はしましょう。 内見せずに契約するのはだいぶ博打なので「内見できない物件はやめる」ぐらいの勢いでいきましょう。

僕たちの場合は遠距離でしたが、内見のときだけはなんとか東京まで来てもらって二人で内見しまくりました。

内見に行く前に注意すべきポイントは

  • 気になる物件を複数件調べて持っていく
  • 希望条件をちゃんと伝える

です。

気になる物件を複数件持っていくと、不動産屋は似たような物件をいくつか紹介してくれます。

希望条件をちゃんと伝えることは、不動産屋が物件を探しやすいというメリット以外に、ハズレ物件*1を紹介されてにくいというメリットがあります。 希望条件を伝えるために上記のスプレッドシートとマイマップを見せられた不動産屋のお兄さんはだいぶ引いていましたが、むしろそれくらいで良いと思います。

f:id:hoto17296:20161214225659p:plain

内見した物件はこのように特徴をメモしておいてメリデメを整理し、条件に合わない物件はガンガン削っていきます。 スプレッドシート超便利。

5. 最後は感覚

今回の場合では、条件に合わなかった物件を削った結果2件の物件が残っていました。

ここまでちゃんとやれば、あとはどちらを選んでも大外れということはないでしょう。 最後の最後は感覚で決めました。

引っ越してから2年が経ちましたが、満足のいく良い家を見つけたと思っています。

オマケ: 家具配置を考える Tips

お互い一人暮らしから二人暮らしをしはじめると、多くの家具や家電がダブります。

どちらの家具家電を残すのかということを考えなければいけないのですが、遠距離でおうち探しをしているとそれすらも大変です。

そういうときは、内見のときに正確な間取りを測っておくか不動産屋に正確な間取り図を貰っておき、 Cacoo を使って入居する前にあらかじめ家具配置を試行錯誤しておきましょう。

f:id:hoto17296:20161216191350p:plain

この図は模様替えにも使えるので、一度作っておくと使いまわせて便利です。

*1:不動産屋もビジネスなので「売れ残ってる物件を紹介して契約に繋げたい」という思惑があり、条件からだいぶ離れた物件を紹介されることがある

今年買ってよかった合法ハーブ

今年の夏に多摩川の河川敷でウェイウェイした人たちに紛れながらエンジニア仲間で BBQ をやったのだけれど、そのときに id:papix がヤバいハーブを持ってきていて、一瞬でドハマリしてしまった。

香りソルト ガーリック&オニオン

香りソルト ガーリック&オニオン

香りソルト ガーリック&オニオン

これは非常に中毒性の高いハーブ。

本来の用途は調味料だが、単体で摂取するのもヤバい。

その中毒性の高さからか、他の「香りソルト」シリーズ *1と比較して販売されている店が少ない。 見つけたらとりあえず買っておこう。

【特別お題「2016年を買い物で振り返ろう」 sponsored by 三菱東京UFJ-VISAデビット

HD25-1 II のリケーブルとモフモフ化をした

オーディオオタクアドベントカレンダー Advent Calendar 2016 の12日目として書いているが、大してオーディオオタクではない。

HD25-1 II

大学時代から HD25-1 II というヘッドホンを愛用している。

ゼンハイザー 密閉型ヘッドホン HD25-1 II【国内正規品】

ゼンハイザー 密閉型ヘッドホン HD25-1 II【国内正規品】

このヘッドホンは最高で、フラットさなど微塵もない暴力的な重低音を鳴らしてくれる。

DJ 用だからそういう仕様になっているのだと思う。

リケーブル

長年酷使したせいか断線してしまって片耳から音が出なくなってしまったのだけど、このヘッドホンはリケーブル可能なので慌てることはない。

5000円。

「ケーブルが 5000 円てどういうことなの・・・」というのが一般人の感覚だけどもまあこれでヘッドホンが直るなら安いもんである。

モフモフ化

交換イヤーパッドがモフモフで良いとの噂を耳にしていたのでついでに購入。

4500円。

「イヤーパッドが 4500 円てどういうことなの・・・」というのが一般人の感覚だけどもまあこれでヘッドホンがモフモフするなら安いもんである(?)

イヤーパッドの交換ってどうやってやるんだよ、と思ってたけど普通に「外して付ける」だけだった。簡単。

完成 \\\ ٩( ‘ω’ )و ////

このヘッドホン、DJ 用途だからか締め付けが強くて長時間使うと頭が痛くなるというデメリットがあったが、モフモフ化することで長時間の使用にも耐えうるようになった。 装着感が変わったのでなんだか新しいヘッドホンを買ったような気持ちになって楽しい。 最高。

音質が変わったかと言われるとよくわからない。 強いて言えば低音が少しマイルドになったような気がする。

今年 HD25 にリニューアル

前まで HD25-1 II という名前で販売されていたのが、今年になって HD25 という名前の新パッケージになり、だいぶ安くなった模様。

ゼンハイザー 密閉型ヘッドホン  HD 25【国内正規品】

ゼンハイザー 密閉型ヘッドホン HD 25【国内正規品】

断線してもリケーブルできるし、カスタマイズが楽しめるし、良いヘッドホンだぞ。 オススメ。

エンジニアコミュニティのつくりかた

IT勉強会/コミュニティ運営 Advent Calendar 2016 の4日目は Gotanda.js について。

昨年エンジニアコミュニティを作って1年間いい感じに運営できたので、これから新たにコミュニティを立ち上げたいを思っている人の参考になりそうなことを書いていきたい。

Gotanda.js とは

Gotanda.js はその名の通り地域 JavaScript コミュニティのひとつで、僕(@hoto17296) と @pine613 くんを中心に数名のスタッフで運営している。

gotanda.js.org

基本的には Slack での交流がメインで、3ヶ月に1回くらいのペースで勉強会も開催している。 先日 Gotanda.js #6 を開催して、#1 を開催してからだいたい一周年ということになった。

今回のイベントは、 発表も幅広い分野の内容が盛りだくさんですごく良かったし、 懇親会も盛り上がっていて飛び込み LT してくれる人も何人もいたし、 懇親会後まで残ったメンバーでは朝まで居酒屋で技術トークをしまくっていて、 とにかく最高だった。

コミュニティは雑なノリで始めるのがいい

Gotanda.js がどうやって生まれたのかというと、もともと五反田にオフィスを構える Gaiax 社と Mobile Factory 社が合同でエンジニア新人研修*1をやっていて、その打ち上げのときにいた何人かで

「Gotanda.pm*2 はあるのに Gotanda.js はないの???」
「作るかーーー」
「うぇーーーい 🎉」

みたいな雑なノリで始まった。「コミュニティを主催する」というと意識高い話っぽいかもしれないがそんなことはなくて、むしろ Gotanda.js の始まりは極めて意識が低かった。

しかし「ある分野について好きな人達が集まってワイワイしてたらコミュニティになった」というのはむしろ自然なことだと思っていて、別の上手く回っているエンジニアコミュニティの主催者に話を聞いたときも「飲み会のときのノリで作った」などと言っていたので、コミュニティって「そういうもの」なのだと思う。

テーマがちょっと広すぎるくらいでいい

YAPC::Asia というカンファレンスに参加したことがあるのだけど、あれは Perl のカンファレンスを謳っていながらも実際の発表内容はなんでもアリというヤバいカンファレンスだった。 だって 真空調理器が届かないので自作した話 ってなんだよ。俺はなんのカンファレンスに来たんだ。

まあなんか、テーマが幅広すぎるイベントに行くと自分の観測範囲内になかった技術の話が聞けておもしろい。

似たような話で、「JavaScript」というテーマで勉強会をやるとどうなるかというと、

  • Web アーキテクチャの設計や実装の話
  • 言語そのもの (ECMAScript や AltJS) の話
  • WebAudio や WebVR などのブラウザ API の話
  • Electron でデスクトップアプリケーション作る話
  • Node.js や JavaScript 製ツールの話
  • AWS Lambda やサーバレスの話
  • ChatBot や IoT の話

などなど、JavaScript という言語がいたるところで活用されているが故に内容の幅が広がりすぎる。 テーマによる制約はあって無いに等しく、事実上なんでもアリみたいな世界観になる。

テーマが幅広いと「詳しい人」と「詳しくない人」という構図が薄くなる。 例えば、フロントエンドのアーキテクチャに詳しい人でも Electron の話を聞いたら学びがあるし、その逆もまた然り。 「誰々が詳しいからすごい・偉い」ではなく、各々が得意分野を持ち寄ってきてフラットに交流できる。 すると敷居が下がってきて JavaScript 詳しくない人でも参加しやすくなる。

意識してそうしたわけじゃないけど、気がついたらそういう構図になっていた。

だからゆるくコミュニティを盛り上げていきたいのであれば、これくらいの幅広さがあったほうがむしろいいんじゃないかと思う。

勉強会は懇親会がメイン

これはけっこう意識してたことなんだけど、発表はメインコンテンツではない

以前とある勉強会で発表したときに、質疑応答の時間も懇親会もなく解散する、ということがあった。 他の発表者に訊きたかったことがいくつもあったし、自分の発表に対しても参加者からフィードバック貰いたかったのに、一切その余地を与えられずにモヤモヤした気持ちで帰らざるを得なかった。

あれ以来思っているのは、懇親会のない勉強会なんてありえない。 懇親会こそが勉強会のメインコンテンツであり、そこから勉強会がはじまると行っても過言ではない。 発表だけ聞いて帰るなんてもったいなさすぎる。 発表だけ聞いて帰ると「なんか面白かったね」だけで終わってしまう。 「自分の考えたことを言葉に出してみてフィードバックをもらう」ということをやらないと学びにならない。

勉強会を主催するからには参加者全員に何かひとつでも学びを得て帰ってもらいたいし、だからいつも「どうやったら懇親会に残ってもらえるか」を考えてイベントを作っている。

ピザを安く大量に仕入れる Tips

懇親会のときのツマミとしてはやはりピザが安定感がある。片手で食べられて便利だし、寿司のネタだけ食って帰られる事件とかが起きない。

ピザって勉強会の規模によっては相当な枚数を注文するので結構高く付くのだけど、そういうときはドミノ・ピザの「一枚買うともう一枚無料」という狂気じみたキャンペーンを使うととても安く買えて便利。

www.dominos.jp

「お持ち帰り限定じゃん・・・取りに行くの大変すぎるわ・・・」と思うじゃろ?

タクシーで取りに行けばいいんじゃ。

会場から店舗までの距離にもよるけど、イベントをやるような人が集まる街であればだいたい近くにドミノ・ピザはある。 数十人規模の勉強会のピザの枚数であれば、タクシー代を考慮に入れても取りに行ったほうがだいぶ安くあがる。

これ IT 勉強会に限らずあらゆるイベントを開催するときに使えるので知っておくと便利。

謝辞

ごたじぇー運営スタッフおよびいつも参加/発表してくださってる皆さんありがとうございます 🙇

これからもよろしくお願いします!!!

*1:ちなみに僕が JavaScript 講師として pine613 くんや nekobato くんに JavaScript を解説するという、いま思うと明らかにおかしい構図だった。

*2:五反田の Perl コミュニティ http://gotanda.pm.org/

「普通のバンド」日本代表 ASIAN KUNG-FU GENERATION

ロックバンド Advent Calendar 2016 というのを見つけたので一番好きなバンド ASIAN KUNG-FU GENERATION について書く。

アジカンと言えば音楽好きなら少なくとも名前は知っているだろう。
「アジカンの曲といえば?」と質問して「ソラニン」って返ってきたら若者で「リライト」って返ってきたらオッサン。これマメな。

みんなだいたいこういうイメージだと思うし、だいたいあってる。

最近出たアルバム「ソルファ(2016)」

アジカンは中学生の時に「ソルファ」が出ていて、それくらいからアジカンを聴き始めた。 当時は特別好きなバンドというわけではなかったのだけど、いろいろな他のバンドを聴いては飽きを繰り返すなかでいつもアジカンだけは飽きることなく聴き続けていた。 気がつけばアジカンは一番好きなバンドになっていた。

そして先日「ソルファ」の再録版がリリースされて、当時からのファンとしては胸が熱くなる。

ソルファ (2016)(初回生産限定盤)(DVD付)

ソルファ (2016)(初回生産限定盤)(DVD付)

この「ソルファ(2016)」本当に良いアルバムで、コアなファンからすれば過去のソルファと比較して楽しめるし、アジカン入門者からすれば昔のアジカンと今のアジカンを同時に感じられるお得感あるアルバムになっているので、聴いてみたほうが良い。

あと千原ジュニアの落語はすごいので最悪それだけでも観よう。

www.asiankung-fu.com

「普通のバンド」日本代表

アジカンて「普通のバンド」日本代表だと思うっていうか、各邦楽バンドの良いところ全部あつめて平均取ったらアジカンになる気がする。

www.youtube.com

アジカンにはこの「スタンダード」みたいな感じがベースにあって、ここから、曲によって様々な色がつけられていく。

www.youtube.com

例えばこの「迷子犬と雨のビート」、最初聴いたときはこれ本当にアジカンかよ、って思ったくらい色がある。

www.youtube.com

一番好きな曲「新世紀のラブソング」。 これでもかと詰め込まれた情報量に圧倒される。つよい。

毎回違った色を見せてくれながらも、しかしその根底には揺るぎないアジカン臭があり、安心感がある。 だからこそ飽きない。

まとめ

アジカンは一生楽しめるバンドだと思う。
良いぞ。

オレオレ GitHub Issue テンプレートを晒す

Gaiax Advent Calendar 2016 2日目、ギフハブ GitHub のテンプレートについて。

GitHub のテンプレート機能

プロジェクトコードのホスティングサービスとして GitHub を利用している IT 企業は多いと思うし、Gaiax でも活用している。

そんな GitHub に今年の2月に派手ではないがとても便利な機能が追加された。 リポジトリのルートに .github というディレクトリを掘ってその中に ISSUE_TEMPLATE.mdPULL_REQUEST_TEMPLATE.md といったファイルを置いておくと、Issue や Pull request を作成する際にテンプレートを表示することができる。

github.com

この機能すごく便利で、今まで

◯◯が××になっていたので修正した

みたいな1行しか説明ない雑なプルリクエストが投げられると

  • それを直さないと誰がどう困るの
  • 原因はなんだったの
  • なぜその変更で修正されるの

などなど、いちいち聞き返さなければいけなくてレビューしづらいことこの上なかったのが、テンプレートを用意することによって予め書いてもらいやすくなる。

どういうテンプレートにするか

いざテンプレートを用意したとしても、知りたい内容をちゃんと織り込んでおかないと結局また質問する羽目になってしまう。

ちゃんとしたテンプレートを用意したいけど、こういうの毎回考えるの面倒じゃん? ベストプラクティスみたいなのが欲しいなー、と。

今は少ない頭を振り絞って考えたテンプレートで運用しているんだけども、どうもまだ「ベスト」という感じがしない。 もっと改善の余地がある気がする。

つまりこのエントリの趣旨としては、自分のチームのテンプレート晒すから「これだとここ不便じゃない?」「ウチはこうしている」みたいなレスポンス欲しいなーーー |д゚)チラッ という感じです。

各位よろしくお願いします。

Pull request テンプレート

まずはプルリクエストのテンプレートから。

<!-- あくまでテンプレートなので必ずしもすべての項目を埋めなくてよい -->

# 概要
<!-- 変更の目的 もしくは 関連する Issue 番号 -->

# 変更内容
<!-- ビューの変更がある場合はスクショによる比較などがあるとわかりやすい -->

# 影響範囲
<!-- この関数を変更したのでこの機能にも影響がある、など -->

# 動作要件
<!-- 動作に必要な 環境変数 / 依存関係 / DBの更新 など -->

# 補足
<!-- レビューをする際に見てほしい点、ローカル環境で試す際の注意点、など -->

<!-- --> は内容を例示するコメントとして使えて良い。 消し忘れたとしても HTML に変換された際には見えなくなるので便利。

<!-- あくまでテンプレートなので必ずしもすべての項目を埋めなくてよい --> はチーム内で合意が取れてればわざわざテンプレートに書かなくてもいいかなと思う。この一文があるせいで概要以外埋めてないプルリクエストもたまに上がってくるので微妙かもしれない。

Issue テンプレート

続いて Issue のテンプレート。

<!-- あくまでテンプレートなので必ずしもすべての項目を埋めなくてよい -->

<!-- 要望のテンプレート -->
# 概要
# 目的
# 提案内容
# タスク
- [ ] 細かいタスクに分解できているなら書き出す

<!-- 不具合のテンプレート -->
# 概要
# 再現手順
# 修正しないとどう困るか
# 原因
# 修正案

Issue に登録するものってカテゴリに分けられるような気がして。

すごく大雑把に分けて「要望」「不具合」かな、と思った。

これをひとつのテンプレートにまとめてしまうと「知りたいこと」が書ききれずにまた質問しなきゃいけなくなりそうだし、 かといってこれ以上細かくするとテンプレートが巨大になってしまうので、これくらいがいい塩梅なんじゃないだろうか。

このテンプレートを使ってみた感想

  • すべての項目を埋めなくてよい を入れておくとたまに雑な Issue / PullReq が作られちゃう
    • でも Issue とかカジュアルに作って欲しいし、項目埋めるの必須にしたくない
  • Issue を「要望」「不具合」に分けたのいい感じ
    • 作るたびに片方削除するのちょっと手間だけど、そんなに気にならない

三行まとめ

  • GitHub のテンプレート機能便利
  • でもちゃんとしたテンプレート作らないと意味ない
  • 他社の事例とか知りたいなーーー |д゚)チラチラッ