無職です。はたらいてます。 旧ブログ: 1 Entry per Day

CircleCIのPerformance Pricing Planの料金を計算するツールを作った

この記事は CircleCI Advent Calendar 2018 の12月15日の記事です。


他のAdvent Calenderの記事が気合い入りまくっていてびっくりしているりんご@mstssk です。

CircleCIについてのあれやこれやのゴイスーな記事は他の方にまかせて、私はこんなのを作ってみました。

mstssk.github.io

CircleCI の Performance Pricing Plan の価格を計算するツールです。 UIが残念なのは仕様です。

使用イメージ
Image from Gyazo

CLIでも使えます。npmパッケージとして公開しているので、Node.jsが入っていればnpxコマンドですぐ使えます。結果の単位はUSドルです。 npm version

$ npx @mstssk/ppp 5 large:1500 macos-large:1000
npx: 1個のパッケージを4.342秒でインストールしました。
123

もちろん非公式ツールです。あくまで参考程度でお願いします。 ちなみに、前職で実際Performance Pricing Planを導入しようとした際は、CircleCIのセールスエンジニアが見積もりを出してくれました。

計算の元ネタはどはこちらの記事から。 qiita.com

ソースはGitHubにあります。CircleCI Japanコミュニティのキックオフの最中に小一時間で書いた雑実装です。

github.com

社内勉強会で「Splatoonで考えるチーム論」という発表をした

社内の開発チームで隔週でやってる勉強会で、話す内容は何でもいいってことなので Splatoon の話をしました。

Splatoon で考えるチーム論

チーム論と銘打ってますが、そこまでかっちりとした感じではなく、単にSplatoonをプレイ中にチームとして動くにあたって気をつけてる事をまとめた内容です。 細かいテクニックとかではなく、チームとしてパフォーマンスを発揮するにはどう考えて動くべきかみたいな話。

株式会社 Viibar に入社しました

viibar.com

10月15日から既に働いてたんですが、 blog 書くのサボってました。

これまで

前職のトップゲート社では、Google Cloud Platform はもちろん、 Angular でフロントエンドがっつりやったり、初めてプロジェクトリーダーとかテックリード的なポジションでの経験も積むことができました。自分のキャリアの中で大きく躍進できた期間でした。

実は早めに退職しリフレッシュ期間として最近流行りの無職を謳歌していました。リフレッシュ期間のはずが途中のべ1万人が集まるイベントでスタッフやってくたびれていたような気もしますがたぶん気のせいです。

これから

今は Vync という動画制作などのための制作管理ツールの開発に携わってます。 viibar.com

開発期間が結構長く当たり前ですが技術的負債もあり、がっつり改善していくのが楽しいったらありゃしません。 他方、 Ruby 周辺のエコシステムが個人的にしっくり来ずに苦しんでいたりもします。

プロダクトに関わりながら開発がスケールするよう環境改善していくのを当面の自分のミッションとしてます。

その他

それと、再来週あたりに LEAD SUSHI NIGHT! という何があってそんな名前になったんだという感じのイベントを Wantedly と共同でやるそうです。 当日は後ろの方で見てると思います。 sushinight.connpass.com

ほしい物リスト

あまり贈ってもらったことない1んですが、慣例として一応ほしい物リスト置いておきます。 一応整理したら何故か酒ばっかりになりました。

Amazon.co.jp ほしい物リスト


f:id:mstssk:20181108223152j:plain


  1. T○NGAと一緒に「潤滑剤が必要だと思って」と KURE 5-56 を贈られたのが衝撃的過ぎて他を覚えていない。

mornin' plusを買ってみた

最近QoL上げようとNature Remo買ったりしてスマートホーム化を進めています。

カーテンの開閉も自動化できたらいいなと思い、他の自動カーテンより設置しやすく値段も安めなmornin' plusをとりあえず買ってみました。

mornin.jp

以下は設置してみた写真。既存のカーテンレールにぶら下げるだけです。 写真では見えませんが、カーテンレールを走るようタイヤが付いており、本体が動くことでカーテンを移動させる仕組み

f:id:mstssk:20180917132458j:plain:w320

メリット

  • 設置が楽
    • 他の自動カーテンはもっと大掛かりだったりするんですが、これは既にあるカーテンレールにぶら下げるだけ。
  • 安い
    • 他の製品は1〜2万円が価格の下限です。ニトリのもので9千円台のものがありますが、カーテンレールごと付け替える必要があるみたい。
  • 指定時刻に自動開閉する機能あり
    • 専用アプリで開閉する曜日と時間を決めておけます。例えば、平日の朝7時に自動でカーテンが開くようにしておくことで目を覚ましやすいです。

デメリット

本当は「ok google、カーテン開けて」とかやりたいんですが、基本的にmornin' plusではできません。 これが個人的な一番のマイナス点。

IFTTT + Pushbullet + Taskerを組み合わせてなんとかしている方はいるようです。ここまでやったのはすごい。 Google Home と mornin' を使って声でカーテンを開閉する 私も同じ環境を構築してみようとしたんですが、昔使っていた端末を人身御供にしてやろうとしたところ、Pushbulletの通知周りが上手く飛んでこずに断念しました。 端末自体がガタが来ていたとか、1つのアカウントで複数台Pushbulletログインしていた+IFTTT→Pushbulletの連携が端末を指定できない、とか細かい問題がちょくちょくある上、構築できたとしてもボイスコマンドからmornin' plusが実際に動き始めるまでに20秒くらいかかってしまうなどコストが辛いです。

今後

mornin' plusがGoogle Assistantとかと対応してくれるとありがたいんですが、一筋縄ではいかなさそうです。 スマートスピーカーとの対応は考えていないわけではないですが、今のBLE,乾電池式という設計上本体の拡張が大変なのであまり期待はできないようです。 他のスマートホーム機器のシリーズのようにコンセント直差しの中継機器なんかを出すとかでしょうか…

カーテンを自動開閉するIoT機器の開発秘話とスッキリ起きるコツとは? 株式会社ロビットに聞く。 – SmartHacks Magazine

もうしばらくmornin' plusを使ってみるつもりですが、いずれは他のものに買い換えることも考えてはいます。 単純な話、赤外線リモコンで操作できる他のものを買ってしまえば、既に持っているNature Remoで操作できるのでGoogle Assistant連携も一瞬なんですよね。

赤外線リモコンで操作できるかどうかちゃんと調べたわけではないですが、他にも自動カーテンのラインナップで見かけたものを並べておきます。

mornin' plusの本体の設置のしやすさ取り回しやすさは魅力なので、公式でよいソリューションを提供してくれるとホントは嬉しいんですが。

DevFest 2018 Tokyo 資料まとめ

最終更新 2018/09/06 22:36

GDG DevFest 2018 Tokyoの各セッションの資料まとめです(非公式)。 Twitter#DevFest18 スライド または #DevFest18 資料 で検索して探してます。

タイトルは https://gdg-tokyo.connpass.com/event/95307/ のタイムテーブルから持ってきた仮題なので、実際の資料のタイトルとは食い違っていたりしてます。 公式?の資料リストは https://gdg-tokyo.connpass.com/event/95307/presentation/ を参照。

TBDはまだ資料を見つけられていないものです。 登壇者または登壇者の所属組織の都合で資料非公開だったりする場合もあるようで、完全なリストにはならないと考えています。

10:00-10:30 セッション1

Room A+B 「(仮)実践!!Web パフォーマンス改善!」

TBD 資料非公開?

Room C+D 「Game Development for Firebase Unity SDK

Room G+H 「Quick Start GCP

TBD

Room I 「Android OSは安全なのか?」

Room J 「Flutterアニメーションの実装方法」

Room K 「Kubeflowで何ができて何ができないのか?」

10:40-11:10 セッション2

Room A+B 「Googleアシスタント最新動向」

Room C+D 「Flutter Overview」

Room G+H 「PWAのイマ」

Room I 「Firestore Database Design」

Room J 「Advanced Room」

Room K 「GCP Compute 概要と選定」

11:20-11:50 セッション3

Room A+B 「AndroidX時代のHello world

Room C+D 「Google AIY Vision kitで遊ぼう ~麻雀牌のリアルタイム識別」~

Room G+H 「Firebase Overview for native application」

TBD

Room I 「GCP のデータベース・ストレージ」

Room J 「Goでネットワークプログラミングするためのよもやま話」

Room K 「FlutterPluginの作り方」

12:50-13:20 セッション4

Room A+B 「Angularの最新情報」

Room C+D 「DialogflowとCloud Functions で作る Google アシスタント アクション」

Room G+H 「Cloud Kata」

Room I 「KotlinでFlutterを書けないか色々試してみた(仮」

Room J 「Flutterとの1年」

Room K 「Growing your app with Firebase」

13:30-14:00 セッション5

Room A+B 「TensorFlow Liteで機械学習Androidアプリを超簡単に作る」

Room C+D 「Container」

TBD

Room G+H 「新しいMaterial Design と MDC(仮)」

Room I 「Introduction of Polymer 3.0」

TBD

Room J 「Realtime Database for high traffic production application」

Room K 「Generative Modeling in the Wild」

TBD

14:10-14:40 セッション6

Room A+B 「Goらしいコードを業務でも書くために(仮)」

Room C+D 「TypeScript導入で得られる「変えていく勇気」」

Room G+H 「Transactions APIを使って飲食店の予約が出来るGoogle Assistantアクションが出来るまで」

Room I 「AndroidThings で CO2 を計測し、警告&サーバーに計測値を投げるシステム」

Room J 「GCPでつくるデータ処理パイプライン」

Room K 「"Fan out" to create twitter like timeline with Cloud Firestore and Cloud Functions」

14:50-15:20 セッション7

Room A+B 「Androidパネルディスカッション: AAC実践導入について」

TBD

Room C+D 「Firebase Realtime Database in Production」

Room G+H 「機械学習、どこから手をつける?」

Room I 「非中央集権ウェブ」

Room J 「Auto ML Overview」

TBD

Room K 「GtugGirlsがヤバいんです」


以上!

Google Assistantのルーティン機能が最高だった

もともと、帰宅して「ただいま」と言ったらエアコンやら証明やら一括で電源を入れるようにしたかったんですが、いつの間にか公式でサポートしていてやったぜ!という感じです。

しかし、Nature Remoで制御しているエアコンについてGoogle Assistantの設定画面では「OFFにする」という指定ができないようでした。 ですが、「エアコンを消して」といったボイスコマンドをそのまま指定できるので代替できます。

WEB+DB PRESSの仮想DOM記事を読んでの感想やらなんやら

WEB+DB PRESS Vol.106の「仮想DOM革命」という記事を読んでの感想やらなんやら

gihyo.jp


これまでほぼAngularしか触ってなかったんですが(jQueryとかモダンでない旧世代以前のあれやこれやは除く)、そろそろReact触ることになりそうなので勉強しようとしていたら、WEB+DB PRESS Vol.106に「仮想DOM革命」という記事が載っていたので、早速買って読みました。

以下、著者の意図とは違うだろうけど、自分的に良かった点について。

Reactのよくわからんかった部分がわかった

Reactはほとんど触ったことがなくて、去年のDroidKaigiのサイトがReactベースのGatsbyだったので、少々触ったくらいでした。

仮想DOMがどうやって何を実現してくれるのか、ReactにおいてProps/Stateの立ち位置・使い方は何なのかがわかったのが、この記事を読んでの俺的な一番の収穫でした。

Angularと比較してどう違うのかがわかった(気になった)

(Angularについてはv2の頃に調べた話が元なので今は違うかも)

Reactでは仮想DOMによって差分のみをDOMに適用する一方、Angularでは変更を検知したプロパティを使用しているテンプレート中の該当部のDOM操作を行います。

つまり、コンポーネントが複雑になってもDOMに適用するのはあくまでその差分だけなReactに対して、テンプレートに記述したロジックをDOMにそのまま反映していくAngularの違いがあります。 特にAngularではAOTコンパイルでテンプレートをTypeScriptのコードにすることもあり、テンプレート書くときもJavaScriptとしてのパフォーマンスを考慮しながら書いたりする必要があると思ってます。

Angularの方はコンポーネントCSSカプセル化を最初からやっているとかプロパティの双方向バインディングがあるとかいう違いもありますが、フロントエンドのフレームワークで一番パフォーマンスに影響が出るDOM操作周りの振る舞いの違いは重要です。