Twitterのお気に入りをインクリメンタルサーチするサービスfavsearchを作った

はじめに

作った！バーン！

http://favsearch.chaspy.me

リポジトリ

github.com

今回もqsと同じく仲良し@kamontiaと作りました。

なぜ作ったのか

favってひとによって使い方違うと思う、ラフにハート送るために使ってるひともいれば、ブックマークがわりに（まぁ今ブックマークって機能あるっぽいけど）つかってる人もいると思う。で、あー過去のfavでなんかあったなーって思い出せないとか、検索したいなーっていうシーンが何度かあって、作った。

ただの検索じゃ面白くない、みんな大好きpecoよろしくインクリメンタルサーチしたいよね。

技術スタック

ってほど重厚なものはなくて、Twitter API使ってfav取得して絞るだけの薄いアプリです。

sinatraのappをherokuに載せています。webアプリ作るのにsinatraは最高便利。frontendはVue.jsを使ってみました。herokuのreview app機能でPRごとに環境できるの最高便利ですね。Quipperで今も昔もやっていることですね。

productionへのdeployだけCircleCIでやってるけど、これもherokuの方だけにしちゃっていいかもなーって思ってる。

herokuは最高便利。hobby web appでEC2なんていらんのだ。

運用まわり

これまたherokuのadd-onで無料枠で使えるものを使っています。

• Application Monitoring New Relic APM - Add-ons - Heroku Elements
• Logging Papertrail - Add-ons - Heroku Elements

あとadd-onじゃなくて別でpingdomでSynthetic Monitoringをしています。1ドメインまでならfree planが実はある。

Free Website Monitoring | Pingdom

Metrics MonitoringがDatadog。 Heroku Buildpack

全部Quipperで使ってるものですね。

インクリメンタルサーチの実装

Vue.jsのデータバインディングを使った。フロントエンド（というかjavascript）さっぱりわからないマンなのにさらにフレームワークまで使って「Rails勉強してます」状態になってて非常にダメだなぁと思いつつ、まぁ一箇所だけだしシュっと使ってみるかぁってかんじでやった。非常に楽でしたね。

この本をめちゃくちゃサラっと読んだ。何事も語彙がわからんと理解がどうにもならんのでそういう意味で役に立った。

基礎から学ぶ Vue.js

具体的にはTwitter認証後、favoriteを取得してarrayに格納したあと、arrayに対して、入力formにいれたwordでfileterかけることで実現してます。

favsearch/favorite.erb at 4e70bdb999cd15139f402a28e39ff7ce20ff0eb7 · chaspy/favsearch · GitHub

制限事項

重大な制限がありまして！最新200件のfavしか取得できません！今後改善予定です！

今後

とりあえずMVP実装した！という段階で、まだまだ改良点はあると思います。（英語で大文字小文字区別しちゃってるところとか。）

使ってみて気軽に「こんな検索したいなー」「こんな表示できたらいいなー」っていうフィードバックもらえると嬉しいです。よろしくお願いします。

2018年10月目標

なんか9月張り切ったので少し休むというかパワーバランスを変える。

特に10月はイベントの予定もないので、登壇とかイベントはおやすみで、自主主催のクローズド勉強会でも発表はなし。

で、OSS活動の割合も減らす。ちょっとずつはやるつもりだけど、先月よりは稼働を落とす。

4ヶ月目に入る。振り返りもした。ちょっと切り替えて仕事のパワーを増そうと思うのと、健康の方にコストをかけたい。どうしても体型管理には1日1,2hのコストを割かないといけないので後回しにしていた。しかしそろそろやばいのでちょいと痩せます。筋トレとジョギング再開して、体重マイナス3kg落とすぐらいで。数値目標はあとで。

んーそんなもんかなー。音楽活動も増やしたいので、こんな感じで。

あと月末は母親が全国大会でくるので応援に行くのも楽しみだー。

2018年9月振り返り

なんかいろいろあったな、

blog.chaspy.me

概ねここに書いたことはできたと思う。書籍で進化的アーキテクチャとクリーンアーキテクチャは読めていない。その代わりに以下が読みかけって感じ。

Kubernetes完全ガイド (impress top gear)

実践Vim　思考のスピードで編集しよう！ (アスキー書籍)

技術書翻訳レビュー

前半はこれにかなりのコストをかけた。だいたい20hぐらい稼働かかってるんじゃないかな。早めにシメたかったので一番に終わらせた。

レビューでも結構大変なのに、翻訳するのはもっと大変ですね。来月は何か1つ自分でも翻訳に挑戦したい。

思想として、広く初学者を助ける、ということをやりたいと思っているので、翻訳もその一部だなと思う。英語の学習がてら、何かした貢献できたらな、と思っていたので、いいタイミングだった。ありがとうございます。

まだスケジュール的なものは未定なので、待ちましょう。

ISUCON

ぶっちゃけ特段事前準備はしていないのでアレですが、いい経験になりました。

blog.chaspy.me

OSS活動

@kamontiaとの趣味開発でツール作れたのはよかった。結構ここにコストを割いた気がする。

blog.chaspy.me

登壇

2本した。qsについてと、Merugo.rbでもう1つ。

blog.chaspy.me

おわりに

とりあえず、なんかわりと常に何かしていた感じで、あっという間の9月だった。よく頑張りました。読み残しの本があるぐらいで、やっぱりイベント駆動は強いな、いやでも達成しちゃうので。

仕事も3ヶ月経った。来月からはパワーバランスをまた考え直したい。

Pull RequestがMergeされたらBranchを削除するGitHub AppをAWS API GagewayとLambdaで作った

はじめに

作った。

github.com

appのinstallはこっち

github.com

めっちゃ単純な図。最近噂のdraw.ioで書きました。良い。

あと一緒に作った@kamontiaがQiitaに記事書いてくれました。

qiita.com

めんどくさいの認証まわりぐらいだと思うので、その辺はこの記事読むと良いと思います。

きっかけ

なかなかあのmerge後のbranchを消すボタンを@kamontiaが押してくれないのでつくった。

やりかた

GitHub app自体作ったことがなかったので、最初は公式のサンプルをやった。

developer.github.com

これでsinatraのアプリを使ってlocal環境を使って試せる。GitHubからどういうリクエストが飛んでいるかがわかる。

AWS

休日に日曜大工でオラっとやったらできてしまった感じ。何気にAPI GatewayとLambdaを自分で触るのははじめてだったので良い機会になりました。

GitHub Appの方でどのEvent契機に動くかと、CallBack URLを設定できるので、PullRequest Eventに対して、LambdaのAPIを入れると、PRに何か起きるたびにPOST / のリクエストが飛ぶ。

Lambdaのlogicも至極シンプルで、PullRequestEventがclosed or mergedの時に、対象リポジトリのbranchを削除する。それだけ。

嬉しいの？

個人的に別に押せばいいじゃんって思うのでこれにありがたみを感じるのは@kamontiaぐらいだと思うんだけど、どうしても自分の運用するリポジトリでなかなかbranchが削除されずリモートにbranchが溜まってしまう人は導入してみてもいいかもしれません。

今後

大した設定内容じゃないけど、一応Terraform管理はしておきたい。

おわりに

おわり。

ISUCON8反省会

いろいろと考えないといけないこと、アウトプットしないといけないことが溜まってるわりに、やっていきがあふれていたので月末の日曜にがっつり消化している感じ。

ISUCON8に出た。

見ての通り、まぁ準備不足（過去問を解いていない）なのに何を言うかという感じではあるが、せっかくなので書いておく。

@sat0yuがQuiper Product Blogにいい感じの記事を書いてくれている。

quipper.hatenablog.com

反省と学び

今回、CentOS7とMariaDBということで、個人的にかなり馴染みのあるOSとDBであった。にもかかわらず。

ちなみにH2Oははじめましてでした。

大きな学びはこんなところ。

• その場で学んで行く時間はない。手慣れたもので勝負すべき。そのためにはインフラ構成変更も辞さない。
  • ただし"手慣れた"ものを増やすために、普段からのキャッチアップがここで生きる。
• 変更を容易にRevertできるようにすべき。
  • 今回はソースコードとconfigに関しては前回参加した@ujihisaがgit管理下においてdeployを容易にしてくれた
  • MariaDBのvup、使ってないサーバであげたんだけど、このDBに対してアプリの書き込みを向けることができなかった
• 敵を知れ。ベンチマークの理解。
  • 優先度をあやまった。DBやWebのloadbalanceより、ベンチマークで何が走るのか。すなわちinitでDBの初期化が何が走るのかまず見るべきだった
  • このDBやwebの構成変更ができなかった＝ベンチマークの初期化処理とアプリの挙動を理解していなかったことが主な敗因

前職でちょうどMariaDBのvupをして、性能があがった経験からやろうと思ったんですけど、ダメですね、それはそうかもしれないけど、優先順位が違う。

来年に向けて

じゃあどんなアクションをとるかということ。

たぶん、過去問を数年分といて、ベンチマークツールの使い方、一般的な対策、そういう準備をしても、予選通過はできないと思う。このぐらいはどのチームもやっているからだ。

個人の取り組みとしては、大きく以下を1年間で身に付けたい

• 計測 - 観察 - 改善のサイクルをいろんなミドルウェアで行う
• SQL / メジャーなDatabaseの性能/基本操作の学習
  • MySQL系はまぁまぁ触れたがPostgresやMongoはあんまり。(Qで使ってるのに！）

多分来年参加するとしてもインフラ担当で出たいので、シェアの高いWeb/DBに関しては余暇を作って抑えておきたい。

その走りとしてWeb serverのベンチ環境を作ったので月イチぐらいで遊んでいきたいと思う。

それと同時に実運用するアプリが作れたらいいんだと思うけど、まぁそれは@kamontiaとなにかやれればいいね。

おわりに

しかし参加してよかったしかない、無力さを感じることは、成長につながる。機会をくれたお2人に感謝。

入社して3ヶ月

前回

blog.chaspy.me

3ヶ月経って書くと過去の僕が言っているので書くが、正直この頃期待していた課題は解消できていない。また、周囲の期待を明確に話した訳でもないが、期待以下となっている。

問題は新しいことの学び方より、既存システムの理解だ。

これが満足にできていないので、雑用も、メインのタスクも、チームメンバーのPRレビューも時間がかかる。そして失敗もする。（した）

これをじっくりやるべきなのが最初の3ヶ月だったはずだが、情けない。

とある個別の（なぜか他とは違う）サービスに関しては、検証環境構築タスクを通じて、1日じっくり時間をかけたおかげで理解できた。これが早い遅いかはともかく、既存のドキュメントやコードをとにかく時間をかけさえすれば理解はできるので、他でもそうすべきである。

1ヶ月時点で振り返って、2Q(6-9月)のgoal設定を個人的にしたんだが、課題が明確に見えていなかったなぁと思う、あってはいるんだけど、ふわっとしている。

さっき一人反省会をしたが、Perfect Understanding Fridayを作って、何か1つ「完全に理解した」を作って、アウトプットする取り組みをしたい。今の課題の末端としてはタイムマネジメントで、集中タイムを意図的に作り出せていないというのもあるので、その解消も兼ねる。

そのアウトプットは個人的に作ったQuipper SRE Handbookかもしれないし、単に雑多なメモを書き下しissueかもしれない。が、アウトプットをして自分の理解内容をメンバーに見てもらうことと、他チームや今後入ってくるひとに有益なものになるようにしたい。

スペシャリティを発揮し、「お前にしかできないことは何よ？」に答えられるようになるまではもう少し時間がかかりそうで、そのためにはまず既存の理解をしっかりしたい。

次は「入社して半年」。既存のことなら任せろ、さらにこのことは俺に任せろ、となっていることを願う。

Ubuntu18.04でH2OとNginxをベンチマークする環境構築

ベンチマークした、とまで胸張って言えないのがアレなんですが。

エントリとしてまとめてないのですが、先日ISUCON8に参加しまして、見事に役に立たなかったという話がありまして。

クローズドの勉強会でISUCONってのがあるんだよーってシェアしました。

で、何で何もできなかったってそもそも性能を計測した経験ないよねとなり。

H2Oもはじめましてだったので少し興味わいたのもあって、戦わせてみるかぁ、という安易な考え。

それをMeguro.rbでLTしてきました。

特に知見らしい知見もないんですが、H2Oのほうが特にいじらずともいい感じ、という世間の感覚値とは近いと思いました。

終わった後無駄に頑張ってplaybook化したりしたんですが別にbashのままでよかったな、install script...

github.com

とはいえ、Ubuntu18.04のVPSでこの2つをベンチマークしたいよーって人には割と役立つスクリプトだと思うので、何かの縁でたどり着いた方はどうぞ。

個人的には今回はまだまだ序章で、来年に向けてじっくりweb serverのパフォーマンスと向き合うための砂場づくりができてよかったーって感じです。

続編はどこで発表しようかなー。