２０１９年振り返り

もう年末なので書いた記事を見直しながら今年一年の振り返りを書いておきます。

このブログを２０１９年２月に再開し、一年に目標１００記事を目標にしてましたが、今時点で書いた今年の記事数は..

３５件!!

でした。全然足りてないですね。６月から１０月にかけてほとんどかけてなかったです。

そんななかで今年一年の振り返りを記事を見ながらやってみます。主に開発の話ですが、現状の業務や個人的活動、その他私生活的なものごちゃまぜです。

2019年の草

今年はまあまあコード書いていたような気がします。githubは主に業務、gitlabはそれ以外という感じですね。

GitHub

GitLab

振り返り

１月

社内システム改善の一環でRedmineのプラグインを開発。また初めてAWS ECSでコンテナ運用をトライ。Dockerもまともに使ったことがなかったので、単にやってみたかったモチベーションのみで開始。

その他の活動として、My crypto heros というイーサリアムベースのブロックチェーンゲームを始めてみました。イーサリアムの仕組みが少しでも分かれば良いなという動機。

２月

４年間眠っていたこのブログをを再開しました。アウトプットの習慣化のため年間１００記事を目標にして開始。デザインもちょっとだけ修正しました。

AWS ECSで初めて社内システムの運用を開始。リリース初期はトラブルあったものの粛々と運用開始。

３月

社内で今後の方向性を議論していた時期。作るものとその体制をどうするかの議論が長引いている時期。議論が多くアウトプットは少なめ。

友人とMy Crypto herosのツール開発を実施。 息子が１歳の誕生日をむかえる。

４月

息子連れて家内の実家のパリに滞在。１歳児連れて１２時間飛行機乗るという苦行を乗り越える。社内で開発するプロダクトの方向性がやや決まり、それに向けてプロトタイプを作り始める。

My crypto herosのハッカソンに参加してみる。イーサリアムのスマートコントラクトについて何もわかってないくせに参加して、何もできなさ過ぎて愕然とする。ハッカソンにたまたま同じチームになった人に色々と教えてもらう。

５月

SECCON CTF beginners に友人と初めて参加。 ほとんどWarｍUp問題しか解けずに終わる。

新規開発するプロダクト開発で初めて真面目にNuxt.jsを使ってみる。 合わせて、Netlify + Heroku + Auth0 の構成でプロトタイプ構築を始める。Auth0を使って認証を作るも想定以上に手こずる。

６月

Netlify + Auto0でいろいろなアプリを作り始める。コンポーネント設計とかこのあたりでようやく真面目に考え始める。フロントの開発頻度が上がってきて、いままでコピペでごまかしていたCSSに苦しむ。

７月

開発したプロダクトをリフォーム産業フェアに出展。ポスター、ビラOnlyで臨んだが、興味を引いてもらうのにすげー苦労することを実感。

Amazon Connectを試しに使ってみたけど、標準の機能が少なすぎてトライアルまで至らず。

８月

家内がフランスにしばらく滞在するので独身モードになる。

９月

前職の会社が主催する非公式の開発合宿(ハッカソン)に友人と参加する。イーサリアムのスマートコントラクトを使ったプロトタイプ作って見たが、スマートコントラクトでできることが低レイヤ過ぎてなかなか面白い感じまで持っていけなかった。ISUCONの日程とだだ被りだったので、今年はこちらを優先。

１０月

開発プロダクトで、HerokuだとDBがどうしてもインターネットに見えてしまい、セキュリティ上の懸念があったため、急遽AWS VPCにバックエンドを移行する。 ついでにインフラは Kubernetesで管理するようにする。これも興味本位ドリブンで採用した。

１１月

Kubernetesの勉強しつつ粛々とインフラ構築。ついでにGithub Actionsで簡単なCIできるように色々作る。

１２月

諸事情により年末は再度フランスで過ごすことに。１歳半の息子連れて再び 12時間飛行機の苦行を乗り越える。 Auth0のソーシャルログイン機能を使っていろいろ試す。

総括

新規プロダクト開発の過程で、Nuxt.js, Rails, ECS, Kubernetes, Github Actionsなどフロントからバックエンドまで幅広く薄く広く関わることができたと思う。今年はとりあえず作ってみるレベルのプロダクト開発がメインだったので、個々の技術要素の掘り下げと本番システム運用の洗練を行っていきたい。

Github Action で 前のstepの結果を使う

Github Action で 前のstepの結果を使う

Github Actionで色々試行錯誤していたのですが、その中で １つのstepの実行結果を後続のstepで使いたいときにちょっと苦労したので、その内容をメモしておきます。

Github Actionでは１つのjobをランナーと呼ばれる実行環境で動かして、そのなかで複数のstepを順次実行します。 このstepは個々のプロセスに分かれており、個々のstepでシェルを実行したりDockerイメージを指定して起動することができます。ただし、個々のプロセスは環境変数やその他の実行環境も独立しているため、１つ目のstepの実行結果をそのまま渡せません。

例えば以下のようにしても、step2には結果は引き継げません。

    - name: step1
      id: step1
      # コマンドの実行結果を格納
      run: |
        export RESULT=`echo "command result"`

    - name: step2
      id: step2        
      # step1の結果を参照したいけどできない！
      run: echo $RESULT

そこでタイトルに書いている前のstepの実行結果を後続のstepで使用するにはどうするかを、多少試行錯誤したのですが、どうやら以下の２つの方法があるようです。

• ファイルに吐き出す
• outputs.<output_id> で参照する

ファイルに吐き出す

リファレンスを見ると、以下のような記述がありました。

help.github.com

ワークフローの各ジョブは、仮想マシンの新しいインスタンスで実行されます。 ジョブ実行のステップはすべて、仮想マシンの同 じインスタンスで実行されるため、そのジョブのアクションはフ ァイルシステムを使用して情報を共有できます。

とのことで、ランナー上の各stepはファイルは共有されている環境で動くので、単純に実行結果をファイルに吐いてしまえば、それを後続のstepで使うことができます。

ファイルに吐き出す方式だと、例えば以下のようになります。

    - name: step1
      id: step1
      # コマンドの実行結果をファイルに格納
      run: |
        echo "command result" > ./RESULT

    - name: step2
      id: step2        
      # step2の結果を参照！
      run: |
        cat ./RESULT

これでstep間で実行結果を受け渡しできました！ が、しかし、この方法だと、コマンド実行時には参照できるのですが、step1の実行結果を step2のyamlに記載するパラメータとして使いたい場合に対応できません。

outputs.<output_id> で参照する

どうやらGithub Actionのメタデータ構文で出力内容の参照ができるようです。

help.github.com

オプション outputsパラメーターを使うと、これらのoutputsを定義しているアクションが実行された後に、ワークフロー内のそれ以降のアクションが利用できるデータを指定できます。 たとえば、2つの入力を加算(x + y = z)するアクションがあれば、そのアクションは他のアクションが入力として利用できる合計値(z)を出力できます。

... いまいちこれだけ読んでも何ができるかわかりませんが、 どうやら ${{ steps.<step_id>.outputs.<output_id>}} で出力結果が参照できるようです。step_idは yamlのstepで定義したidを使用すればいいのですが、output_idは何を入れれば良いかわかりません。この辺りの内容が記載されているリファレンスを見つけられなかったのですが、その辺に公開されているコードを見ると以下のようにやればいけるようです。

    - name: step1
      id: step1
      # コマンドの実行結果をoutputs.resultに格納
      run: |
        echo "##[set-output name=result;]command result" 

    - name: step2
      id: step2        
      # step2の結果を参照！
      env:
        RESULT: ${{steps.step1.outputs.result}}
      run: |
        echo $RESULT

まとめ

今回は掲題の Github Actionで 前のStepの内容を取得する方法を調べたのでその内容をまとめました。 実は今回自分は現在時刻を文字列でstep1で取得して、step2, step3でそれを使用したかったので掲題の方法を探ったのですが、思ったより情報が少なくて時間がかかりました.. stepが個々のプロセスに分かれており、好きなDockerイメージを使用できるという作りはすごく汎用性が高い反面、こういった些細な作業でつまづいてしまうのはちょっと辛いかなという印象を受けました。これも慣れてしまえばもう大丈夫なのですが、出回っている情報が少ないうち、慣れないうちは思わぬハマりポイントがあるかもしれないので、小さいタスクから始めた方が無難かもしれません。

Github Action 触ってみた感想

最近正式サービスとして公開された Github Action触っていくつかワークフロー作ってみたので、 その感想をメモしておきます。

help.github.com

Github Action とは

Githubが提供するCI/CDの仕組み。 今まではCircle CI とか外部のサービスと連携しなければできなかったところが、Githubだけで完結できるようになりました。

試した動機

今までCircle CIを使用しており、特に不満があったわけでないですが、Github で管理しているから CIも別にGithubでいいかなと思ってとりあえずやってみました。

作ったワークフロー

• develop/masterブランチにPushされたらDockerイメージをビルドしてAmazon ECRにPushするジョブ
• Kubernetesの設定ファイルが更新されたら、 kubectl apply -f xxx を実行するジョブ

所感

• Dockerイメージのビルドのジョブ作成はすごく簡単でした。提供されているサンプルのyamlをちょっといじるだけで作成できました。リファレンス読まなくてもいけるレベル。
• HCLからyamlへの移行の影響が結構辛い。ググって出てきたexampleの過半がHCLで書かれているので、入門する人にはちょっと面倒だと思います。これは時間がたてばどんどんyamlになっていくと思います。またAWSへ接続するためのサンプルコードの多くがDeprecated のリポジトリのコードを参照していて、どうしたらいいの？と言う感じになるケースもありました。

github.com

• ちょっとGithub Actionの動作が不安定。あれ、動いてないな？と思って調べたら、Github status 見ると Degrated になっていた 、と言うのが何回かありました。これも時間が経てばもっと安定するのかなと思っています。
• 外部からワークフローを起動できる repository_dispatch が便利(まだpreview period ですが)。 APIサーバのコードを更新したら、Kubernetesのconf 用のリポジトリのワークフローを呼び出してジョブ起動みたいなことができます。リポジトリ間の連携がやりやすいのかなと思いました。
• いろんなActionが公開されていて、再利用できます。 自分も新たなアクションを作って、公開できます。他の人の作ったActionを再利用したりFolkできるのは、Githubならではかと思いました。
• (キャッシュのきかし具合など、ジョブの実行速度に関しては今回比較できず。)

まとめ

正式サービスインしてまだ時間も短いため、動作が不安定だったり情報が少なかったり、やりづらい点もあるかと思いますが、Githubにメインでコード管理していれば、試すのはアリだと思います。

勉強会メモ Firebase Startup #2 ー Pitch & Demo Day

以下にオーディエンス枠として参加してみました。 すげーメモレベルですが話を聞いた内容を書いておきます。

勉強会の概要は以下を参照してください。

firebase-community.connpass.com

以下メモ

対談

..途中から参加 これからのクロスプラットフォームのフロントエンドは Flutterがおすすめ UIはiOSモAndroidも同じように見える。

リアルタイムWebがまだまだ浸透していない。 今までとは違う体験をしてほしい Firebaseの機能が足りていないというより、UXがこなれていない。

ARプラットフォーム「ARaddin」 ZEPPELIN

ARで新たな広告モデル スマホにかざしたら広告が３次元でみれる。ビルなどにAR写せば広告見える。ビル所有者に負担小さいのが売り。

夜泣き対応中のママ・パパが集うアプリ シンプルメーカー

銀座ITラボというメディアをやっている。

夜泣きした人同士での共有チャンネル。 夜泣きの履歴を記録できる。

Activeユーザ数の表現に、RealtimeDBを使っている。異常終了したときでもコネクション数を把握するのが楽だった。

SUGAO

自分の情報を友人の目線から紹介してもらう。 自分で書いた情報には誇大表現が混じるので、知人からの評価を残し公正に。

Flutter for webウェブ版も作ってみた！ジンの記録・共有アプリ

お酒のジンの投稿・管理できるアプリ ジンで使われている素材情報(ボタニカル)もDBに揃っている。 日本酒、ビールは競合アプリ多いけど、ジンは国内でまだない。 Web版をFlutterで作っている。

Firebase Extensions Translate Textを使った翻訳webサービス

メモや日記ついでに英語学習 Google翻訳の精度が上がってきたので、Google翻訳の内容から人間が学習できるのではという逆転の発想。

激辛グルメSNS「カライイネ」

辛い食べ物好きのためのSNS。 辛さを相対的に評価ができる。

SlideLive

スライドのコメントを動的にシェアできる。 スライドの移動も共有できるので、リアルタイムに画面が共有できる。

スマホですぐ遊べる「ボードゲームオンライン」

オンラインでボードゲームが遊べる。リアルタイムWebの実装がとても簡単になった。

AJSを使ったフロントエンドデザイン

JSは進化しているけどコンパイルが必要になったり、学習コストが高い。昔のFlashライクな描画ができるA(JS) というライブラリを開発した。

所感

アイデアソンからの実装なので、firebaseの実装に関する話題は少なく、実装の話やつまづきポイントなど聞ければよかったが、それでもリアルタイムをうまく使っている事例を知れてよかった。

結果発表だけでなく、アイデアソンの段階から参加できればよかったなと思いました。

Netlifyをしばらく使ったので所感を書いておきます。

前回は kintone について 所感を書きましたが、今回はNetlifyについて書きます。

rso.hateblo.jp

Netlifyとは

静的ファイルホスティングサービスの部類に属し、いわゆるHTML/Javascript/CSSで完結するサイトをサクッと公開でき、それに関連する様々な機能を提供しています。提供している機能としては、例えば、

• HTTPS化、SSL証明書の発行(Let's Encrypt)
• githubなどのリポジトリ連携、ビルド、デプロイなどのCI機能
• デプロイプレビュー環境の自動作成
• サーバサイドサポート(Lambda Function)
• 入力フォーム
• 認証
• A/Bテスト, アクセス分析

などがあります。

静的ファイルサイトなので、サーバサイドの動作が必要になるアプリケーション(PHP, Rails)などは対応できません。

自社の業務や個人的なツールやハッカソンなどでNetlifyを使用することがそこそこ多く、そこで得られた良いところ、つらいところを書いておきます。

Netlifyの良いところ

デプロイまでの設定がとにかく早い。手軽。

初めてNetlifyを使用したのはNuxt.jsだったのですが、リポジトリと連携してビルドコマンド(nuxt generate) を設定したら、そのままもうデプロイされるようになりました。これだけでmasterの内容が常にデプロイされる簡易的なCD環境が出来上がります。さらにHTTPS化やカスタムドメインの設定もできます。

以前、実際にNetlifyで設定してみたときのメモを書きましたので、こちらにも書いておきます。 rso.hateblo.jp

デプロイプレビュー(feature環境)が自動でデプロイされる

開発時にfeatureブランチ(masterでないブランチ)をpushするとそのブランチの内容がdeploy-preview環境としてデプロイされます。この機能は、修正内容をユーザや他の人にレビューしてもらう時にとても便利です。この辺りの機能がリポジトリと連携するだけですぐに使えるので、これもとても手軽です。

無料枠の機能が豊富

Netlifyは各機能ごとにプランが設定されていて、ある一定枠までは無料で使用でき、それ以上使いたいときは機能ごとに課金するスタイルになっています。ハッカソンやプロトタイプ開発レベルでは無料枠でほぼ対応できるぐらい使用できます。

ちょっとしたサーバサイド側の機能を実装できる

静的サイトの内容だけで完結できない場合、例えば、CORSの制約によりAjax通信ができない場合、通常ならその部分をAWS Lambda + API Gateway などを用意しないといけないという場合でも、Netlify の Functions を使えば上記のことをNetlifyだけで完結することができます。さらにFunctionのコードも同一のリポジトリに含めて管理できるので、プロジェクトの規模が小さいうちはコードが別々にならずに管理できて良いです。

Netlifyのつらいところ

静的ファイルのダウンロードが遅い

結構大きめのSingle Page ApplicationをNetlifyにデプロイした場合、初回ダウンロードにかなりの待ち時間がかかってしまいます。特にモバイル用のSingle Page Applicationの場合、初回アクセスがネックになります。 検証できている訳ではないですが、ネットの評判によるとダウンロードにかかる時間は同様のサービスであるFirebase に軍配が上がっているようです。

ビルドがたまにこける

masterへpushした内容が反映されるのを待っていると、ビルドが失敗していることがあります。production環境へのビルドが失敗すると、ちょっと心配になる場合があります。

Functionの実行時間に制約がある

とあるプロジェクトでNetlify Functionで簡易的なサーバサイドの処理を実行していたのですが、Function(実態はLambda)の実行時間が最大１０秒までしか実行できず、実行したい処理がたまに10秒を超えるようなものだったので、結局このケースではAPI Gateway + Lambdaの構成に変更しました。

devploy preview環境がpublicになる

良いところで挙げたdeploy-preview機能ですが、１つ欠点があり、パブリックでアクセス可能になってしまいます。開発中の内容をpublicに公開したくない場合には向いていないかもしれません。自分の場合、Auth0 による認証を入れるようにして対策しています。

まとめ

今回自分が使った中で良いところつらいところを書きましたが、かなり良いサービスであり、 LPなどはもちろん、簡易的なツールやプロトタイプ作成に向いていると感じています。