街のレコ屋という場所

※正確にはCDショップの話です。

※DJの人たちの話ではなくて、ただのリスナーの話です。

今の時代、音楽はインターネット上でいくらでも得ることができて、様々なプレイリストがあるし、あの手この手でレコメンドがされます。

ただ、自分はおそらく古い人間で、誰かが万人のために企画したプレイリストなんかよりDJが自分のスタイルを詰め込んで作ったMIXCDのほうが最高だと思うし、機械がするレコメンドよりも街のレコ屋の中の人のオススメのほうが信用できます。

ところで、自分はいつも「ここぞという仕事の頑張り時」に、いつものレコ屋に直接行ってCDを買う癖があります。

「なんで今CDを買うのか」というと「インターネットにない音がCDにあるから」であって、別にiTunesで音楽を買わないわけではないです（調べたら、一番最近に購入したデジタル音源は Nai Palm / Needle Paw でした）。

もしかしたら自分の音の趣味が偏っているからかもしれませんが、「インターネットにない音楽」というか「自分の好きな音の世界の最新」を求めるときにレコ屋に行って中の人に聞くのが最適解だと思っています。

何度かCDを購入していると、好みを覚えていてくれたりしてさらにいろんな音を教えてくれるので最高です。しかも、現場のいろいろな情報付きで。本当にときどきハズレもあったりしてそれも良いです。

「あ、○○の新譜が出たよ」「最近来てなかったけど、○○のCDあるよ」「○○知ってる？CD出したよ」って。

ちなみに、自分は福岡に住んでいますがいつもここに行きます。

TROOP RECORDS

街のレコ屋、いいですよ。

@troop_records でGET!!!聴いて気合をいれる

git cloneしているソースコードからGitHubやGH:EのWebページを開く

前にも書いたとおり、マネージドクラウドチームで開発に関わっているのですが、今までと違って

• まだ全てを追いきれていない
• ある程度の規模のアーキテクチャなので複数のリポジトリに分かれている
• 多くのOSSを活用している（もしくはOSSを自分たちで作って活用している）
• GitHubだけでなくGH:Eも使っている
• 何から何までGH:Eの上に書く文化
• Slack活用がすごい

という状況です。

そうすると

• 実装について具体的なコードを指して質問したい
• リポジトリをまたいだ実装の議論がある
• 日々の検討内容や進行ログをコードを指して記録したい

ということが多くあります。

そのたびに、手元のEmacsではそのソースコードを開いているのに、GH:EやSlackで質問や会話をするためにGitHubやGH:Eのページを開くのがかなり面倒でした。

やりたいことはEmacs上のカーソルの位置から該当ソースコードのページを開くことです（行のハッシュ付きで）。

「確かそんな.elがあったような気がする」と思ったのですが、せっかくなので自分で久しぶりにEmacs Lispを書いていました。

昨日作った.elが最高に便利だ

— k1LoW (@k1LoW) 2018年3月15日

が、だいたいできたあとで調べたら、やはりもっと良さそうなのがあったのでそっちを使うことになりました。

他の.elが良さそうだったので早くも自分が作った.elが開発終了となった

— k1LoW (@k1LoW) 2018年3月18日

github.com

自分は以下のような設定をしています。

(require 'git-link)

(defun git-link-gocode (hostname dirname filename branch commit start end)
  (format "https://%s/%s/+/%s/%s"
    hostname
    dirname
    (or branch commit)
    (concat filename
            (when start
              (format "#%s" start)))))

(with-eval-after-load 'git-link
  (custom-set-variables '(git-link-open-in-browser t))
  (add-to-list 'git-link-remote-alist
               '("ghe\\.example\\.com" git-link-github)) ;; GH:Eのホストも対象に
  (add-to-list 'git-link-remote-alist
               '("go\\.googlesource\\.com" git-link-gocode))) ;; go get で取得したgoのコードも表示できるように

これでカーソルやリージョンを見てブラウザでソースコードのURLを開いてくれます。

便利。

GMOペパボに入社していました

入社エントリ頑張ろうと思ったのですが、余裕がゼロなので、ロリポップ！マネージドクラウドのJOINエントリをもって入社エントリとさせていただきます。

note.mu

ちなみに今どんな感じなのか

昼休みに「たぶんP山さんにabみたいにベンチマークかけられているかもしれない」ということを言われてなぜか理解した

— k1LoW (@k1LoW) 2018年3月6日

というのは半分冗談で、入社したばかりなのにいろいろ触らせてもらっています。本当いろいろです。

人間本気になると$GOPATHも変わる

— k1LoW (@k1LoW) 2018年3月2日

GoとかTypeScriptとかChefとか（今日はmruby）そういう今まで触っていない新しい技術スタックもですが、中だから見える細かい設計とか大きなアーキテクチャとかが面白いし勉強になります。まだ全然追えていないですけど。

開発合宿とか

入社前から誘ってもらっていた開発合宿も楽しく参加できました。

HTTPプロキシサーバを作りたかったのに作っていたのはリバースプロキシだった件

— k1LoW (@k1LoW) 2018年3月10日

Instagram post by 101000LAB • Mar 11, 2018 at 2:59am UTC

なぜか丘に登ったりもしていました。

社内TechMTGとか

ホスティング事業部で本格的なTechMTGがあったので「自己紹介したらいいじゃん」ということでLTをさせてもらったりとか（本発表はチームレビューとかあったりして本気）

今日も新しいことをします

正直、ひとまわりくらい年下の優秀なチームメンバーにもフロントエンドやバックエンドやインフラのアレコレを教えてもらったりレビューもらったりして楽しいし感謝しかない。
あと、当然焦りもあるので頑張る。

— k1LoW (@k1LoW) 2018年3月8日

まだ全然追いつけない。

落ち着いたらまた感想とか書いていきたいです。

「半分冗談」ということは、つまりそういうことですね。

ダーマの神殿に行った気持ちで頑張る

2月末で株式会社Fusicを退職します。現在有給消化中になります。

気づけば11年目に突入していた

長いように思えますが、特に不満なくやってきていつの間にか勤続2桁に突入していました。

これがどれくらい長いかというと

• バージョン管理のツール（サービス）でいうと、svn -> SVK -> GitHub (Git)
• PHPでいうと、（使ったもので）5.1 -> 5.2 -> 5.3 -> 5.4 -> 5.5 -> 5.6 -> 7.1
• PHPフレームワークでいうと、HTMLとPHPが一体 -> オレオレ+Smarty -> CakePHP1.2 -> CakePHP2 -> CakePHP3
• サーバでいうと、レンサバ+DCメイン -> VPSメイン -> AWSメイン
• エディタはずっとEmacs

というくらい長いです。

11年間、いろいろ思い出はありますが多すぎるので割愛。

（どうしても知りたい方は社内情報共有サービスに社内向け退職エントリを書いているので、Fusicに入社したら見れます。

なぜ辞めるのか

いろいろキッカケや理由はありますが、一番の理由は

エンジニアとしての成長を加速させたかったから

です。

（自分の）成長度が足りない

10年以上同じ場所に居座って今、社内外を見渡すといろいろなことに目がつきます。

• 全く新しい技術スタックをもったエンジニアがJOINしてきた
• もともと自分が一番と思っていた技術スタックに対して、他のメンバーが台頭してきた
• 自分と同じ方向で技術スタックを伸ばそうとしているエンジニアがいなくなった。理由は技術要素が多様化してきたから
• 自分のレベルがあがるにつれて社内外のエンジニアとの差が少しづつわかるようになってきた

など。

Fusicに技術を伸ばそうとするエンジニア（特に若い人達）が多くなったことは喜ばしいのですが、

それよりも自分のなかで強かったのは「このままの自分の成長度だと確実にエンジニアとして死んでいく」という思いです。

100年の人生をエンジニアとして生きたい

今の自分のエンジニアとしての特性は「日々の業務を繰り返して何かを思いつくエンジニア」だと自己分析しています。

それは、GitHubのリポジトリや個人で作ったサービスを振り返ってみてもそんな感じです。

一方で、LIFE SHIFT という本にもあるように、これからは下手したら100年の人生設計をする必要があります。

LIFE SHIFT(ライフ・シフト)

よくセカンドキャリアなどと言いますが、今のところ自分はエンジニアというワンキャリア( by 大杉漣 )で生き続けたいと考えています。

そういった意味で、「100年の人生をエンジニアとして生きたい」という条件で、今のまま（今の日々の業務）を続けていたら「成長度がぜんぜん足りない」と感じていました。

結局どうすればいいのかわかりませんでしたが、いろいろ考えた末「環境を変える」という選択肢をとりました。

ダーマの神殿

というわけで、

pepabo.com

3月からGMOペパボ株式会社にエンジニアとしてお世話になります。

技術スタック的にも、本当にほぼレベル1からのスタートになると思っています。もうダーマの神殿に行って転職した気分です。

そして、周りは追いかける対象となるエンジニアばかりです。

「もう伸びしろしかない」

そう言っていないと精神的にやってられないです。自分で飛び込んだとはいえヤバい。

GMOペパボ株式会社の皆様どうぞよろしくお願いします。

（もし、自分にヒトとしてダメなところがありましたら、文句はこの人かこの人までお願いします。）

これから

生息地

今まで通り、福岡です。

サーバーレスおじさん業とか

サーバーレスアーキテクチャについて、正直まだ興味はつきないので、趣味でやっていきたいです。

むしろ「サーバーレスつくるおじさん業」になったりしそうでドキドキしています。

ex-fusic として

自分のエンジニアとしてのキャリアは今のところ全てFusicでできています。

これは、本当に、全てです。

PHPもCakePHPもAWSもawspecもサーバーレスも、全てです。PHPはFusicに入社してから覚えました。

ちなみにいうと、「Fusic 20の信条」のGoogle検索結果も自分のGistです。

井の中の蛙だったのかどうなのか。

これからの活動が「Fusicのメンバーからも見られる」と考えると気が引き締まる思いです。

入社したら

余裕ができたら入社エントリも書きたいです。ただ、余裕なんてない気がしてならないです。

最後に謝辞というか

やりたい放題やらせてもらって約11年、本当にお世話になりました。ありがとうございました。

が、

ちょっと言いたいことが。

まだ退社日前なので社内Slackが見えるのですが、なんか自分がいるときより面白いこといろいろやっていませんか？？

なんか悔しいので、次の職場でも絶対面白いことやってやる。

後はよろしくおねがいします。

faultline v1.0.0 をリリースした

今年のうちにfaultlineをv1にしたい

— k1LoW (@k1LoW) 2017年12月18日

残念ながら2018年に入りましたが、リリースできました。

github.com

v1になって何が変わったのか？

基本的に機能追加などはありませんが、v0からいくつかBREAKING CHANGEが入りました。

BREAKING - レスポンスフォーマットを変更した

faultline v1で絶対にやりたかったところがコレでした。

RubyKaigi2017でonkさんの発表を聞いてとても勉強になりました。

RubyKaigi 2017 でどんな発表をしたか - onk.ninja

そして、fautlineのレスポンスフォーマットにしっくりきていなかったので、懇親会で質問させてもらってアドバイスをもらいました。ありがとうございました。

質問内容としては「レスポンスフォーマットを決める際に、何か参考になる情報もしくは標準的な仕様はありますか？」で、「あまりない、けど例えばGraphQLではResponseのフォーマットが定義されているよ」とアドバイスをもらっていろいろ調べた上でこれにしようということになりました。

BREAKING - FAULTLINE_* なenvを追加/デフォルト値を変更した

https://github.com/faultline/faultline/blob/master/docs/env.md に詳細を書いていますが、いくつかenvに手をいれました。

大きいのは

• FAULTLINE_STAGE のデフォルト値を dev にした
• FAULTLINE_DYNAMODB_TABLE_SUFFIX ( DynamoDBのテーブル名のサフィックス値）
• FAULTLINE_ERROR_DATA_RETENTION_IN_DAYS ( fautlineに保存するエラー情報のTTL設定 ) を追加
• FAULTLINE_DYNAMODB_READ_CAPACITY_UNITS
• FAULTLINE_DYNAMODB_WRITE_CAPACITY_UNITS

などです。

これによりv0からv1にマイグレーションをしたい場合にはいくつか気をつけることがあります。

各ハンドラを middy でラップした

github.com

faultlineにmiddyを適用しようと思ったら、ハンドラになる関数をテスタブルにする必要がでてきて、結果localstack環境が必要になって、やっとmiddlewareを1つ適用できたのが今。

— k1LoW (@k1LoW) 2018年1月30日

PrivateなSlackで @horike37 さんが紹介していたので見てみて、良さそうだったので採用してみました。

実際にはこんな感じ で、1つのハンドラでもミドルウェア層ができるだけでいろいろスッキリしました。

v0からv1へのマイグレーション方法

v0から使っている方は、APIエンドポイントのURLや蓄積したエラーデータなどをそのままにアップデートしたい方もいると思います。

Migration Guide: from v0.x to v1.x

a. 新しいfautlineスタックを作成してデータを移行する場合

新しいfautlineスタックを作る場合は、APIエンドポイントのURLは変わってしまいます。 S3のデータ構造やDynamoDBのデータ構造はv0と変わりませんので、awscliなどを利用してデータを移行してください。

b. v0のスタックをそのまま利用する場合

v0のスタックをそのまま利用する場合はAPIエンドポイントのURLも蓄積したエラーデータもそのままにできます。

v0のスタックをそのままにv1にマイグレーションしたい場合は、FAULTLINE_STAGE と FAULTLINE_DYNAMODB_TABLE_SUFFIX を設定する必要があります（config.ymlで設定している場合は stage と dynamodbTableSuffix になります）。

FAULTLINE_STAGE はv0と同様に（デフォルト値であれば v0 ）に、 FAULTLINE_DYNAMODB_TABLE_SUFFIX は空値 ( '' ) にすればOKです。

fautlineのエンドポイントを同じにできれば、各アプリケーションに組み込んだfautlineのSDKの設定は更新する必要はありません。

fautline-webuiを使っている場合

v1ではレスポンスフォーマットが変更になっているので、fautline-webuiもv1にアップデートしてください

fautlineのこれから

機能面については最低限運用に耐えうるものができて一段落と思っています。

今回のアップデートで内部実装も結構リファクタリングできたので、機能追加もしやすくなりました。

もし次何か機能を追加するとしたらfautline自体をモニタリングする何かかなとか考えています。

というか、CloudWatchのダッシュボードの共有機能まだかな。。。

utsusemiという静的サイト生成用クローラを作った（作っていた）

github.com

昨年からサーバーレスな勉強会で何回か紹介していましたが、ちゃんとエントリを書いていなかったので書いておきます。

これは何？

1つのオリジナルサイトをクロールしてS3上に（S3の静的ウェブサイトホスティング機能で）静的サイトを構築してしまうServerlessなツールです。

さらに、構築したS3上の静的ページを任意のタイミングで更新できるようになります。

どんな時に使えるの？

以下の2つの要件を実現したいときに使えると思っています。

1. コンテンツはCMSなど便利なWebアプリケーションで更新をし続けたい。
2. 実際にアクセスされる公開側は（可用性、信頼性やセキュリティを理由に）S3の静的ウェブサイトホスティングで実現したい。

utsusemiのアーキテクチャ

utsusemiはAWS上で実現される、いわばサーバーレスアプリケーションです。

utsusemiをデプロイすると、オリジナルサイトをクロールするクローラ（AWS Lambda + Amazon SQS）と、クロールした結果の静的コンテンツを置くS3をAWS上に展開します。

クローラにはAPI（API Gateway）を通じて命令を送ることができ、クロールした結果は「リンクなどが切れないように書き換えた上で（ここが泥臭い）」S3に設置されます。

CMSでコンテンツを更新したタイミングでutsusemiのAPIを叩くようにすれば、「CMSから更新可能なS3静的ウェブサイトホスティング」の出来上がりというわけです。

あとはS3側だけを公開するような形にしておけば、CMSの可用性を考える必要もないですし、S3ならセキュリティ的にも安心です。

URLの問題だけですのでDNSいじることができるのあれば、既に運用しているCMSにも適用できるかもしれないという良さもあります。

静的ウェブサイトホスティングのためにURLを書き換えるという仕組み

utsusemiはクロールしたコンテンツをただ保存することを目的にしているのではなく、クロールした結果を静的サイトとしてリンク切れなくホスティングすることを目的としているので、主にURLをガンガン書き換えています。

例えば、

• aタグやlinkタグの href 属性
• scriptタグやimgタグなどの src 属性
• CSS内の url()
• タグに直接書かれた style 属性内の url()
• CSS内の @import

などを泥臭く、パス解決だけでなくクエリストリングやハッシュも良い感じに書き換えています。

というわけで

なかなか使いどころあると思っているのですがいかがでしょうか？

ちなみに

utsusemiという名前の命名は奥さんです（ヒント: FFXIユーザ）。

Serverless Frameworkで静的サイトをBASIC認証付きでホスティングするためのボイラープレートを作った

※注意 2018/1/18時点ではCloudFrontに紐付けたLambda@Edgeを削除することができなくなります（結果Serverless Framework内で動いているCFnスタックの削除などにも失敗します）。 https://forums.aws.amazon.com/thread.jspa?threadID=260242&tstart=0#jive-message-824818

ときどきページデザインなどの確認のためにモックサイトを作成することがあったりします。

動くモックが必要なのであれば（PHPやRubyを動かすために）サーバの用意が必要ですが、静的サイトなのであればS3の静的ウェブサイトホスティングの機能を使いたいところです。

ただ、確認用ページをパブリックに公開するのもアレなので、BASIC認証くらいは欲しいです。

というわけで

1. S3静的ウェブサイトホスティング環境
2. 1のS3バケットにコンテンツを同期アップロードするためのコマンド
3. 1の環境にBASIC認証を付与

という環境を一撃で構築するためのServerless Frameworkのボイラープレートを作りました

github.com

使い方

インストール

serverlessコマンドを利用するか、git cloneでインストールします

$ serverless install --url https://github.com/k1LoW/serverless-static-hosting-with-basic-auth --name my-static-page
or
$ git clone https://github.com/k1LoW/serverless-static-hosting-with-basic-auth.git ./my-static-page

BASIC認証のUSERNAMEとPASSWORDを設定する

handler.js 内のBASIC_AUTH_USERSにBASIC認証のUSERNAMEとPASSWORDを設定します。

const BASIC_AUTH_USERS = {
    k1low: 'passpass'
};

認証ユーザは複数設定できます。

デプロイ

S3のバケット名を環境変数で指定しつつ（ WEBSITE_S3_BUCKET_NAME ）静的ウェブサイトホスティング環境をデプロイします。

$ npm install
$ AWS_PROFILE=XxxxxXXX WEBSITE_S3_BUCKET_NAME=sls-static-basic npm run deploy

CloudFrontの設定やLamda@Edgeの設定も含まれるので少し時間がかかります。

デプロイが完了すると src/ 内のコンテンツがS3バケットに同期されて、CloudFront経由でBASIC認証付きの静的サイトの確認をすることができるようになります。

コンテンツの再同期

コンテンツを再度同期したいときは npm run sync コマンドで同期します（ WEBSITE_S3_BUCKET_NAME の指定は忘れずに ）。

$ AWS_PROFILE=XxxxxXXX WEBSITE_S3_BUCKET_NAME=sls-static-basic npm run sync

まとめ

Lambda@Edge面白いですね。