Flutter環境構築メモ（Androidライセンスエラーの解消）

環境

OS: Windows 10

IDE: AndroidStudio

Android StudioはJetBrainsのToolBoxでインストールをした

特別な設定

上記2つともAndroidStudioの言うがままに登録

エミュレータ起動時にエラー

Flutterプロジェクトを作成し、エミュレータ起動時にAndroidのライセンス云々でエラー発生 （エラーのログ取り忘れて消えてしまった。。反省）

おそらくこの記事の事象と同じ

当環境ではflutterにパスが通ってなかったので直接実行した

C:\flutter\bin\flutter.bat doctor --android-licenses

それ以外は特にハマることなくHello world的なアプリがエミュレータで起動した

AWSのSPAアプリケーションにおけるダイナミックレンダリングの実装（アーキテクチャ編）

AWS Lambda CloudFront ダイナミックレンダリング AWS

SPAでサービスを作ったのですが、SEO関連で課題があり、ダイナミックレンダリングの対応をした話です。

インフラは全てAWSで固めたので、AWSを利用していない場合、参考にならないかも知れません。

また、サンプルのソースコードはGitHubにあります。 https://github.com/snicmakino/dynamic-rendering-lambda

※ これは2020/07/16時点では有効な話なので、今後の動向次第では有効な対応ではなくなるかも知れません。

ダイナミックレンダリング実装の効果

良い点

イマイチな点

所感としては、SSRを利用するほどコストかけられないが、SEO対策はある程度やりたいといったケースに適しています。

レスポンスタイムがSEOで滅茶苦茶不利になっているような感覚も無いので、十分SSRに対抗する選択肢になり得るかと思います。

ダイナミックレンダリングについて

ダイナミックレンダリングとは

Googleさんのガイドを参考にするとわかりやすいです。 ダイナミックレンダリング

SPAでは通常、ブラウザに真っ白なHTMLが最初に返却され、JSが動いて描写されるという動きをします。

特にSEOを意識しない場合は問題ないのですが、検索エンジンのBotなどは、このJSを動かした後の画面を読み込んでくれないことも多く（Googleは結構頑張ってますけど）、コンテンツページなどもデフォルトで設定してあるタイトルを読んでしまったりします。

これではまずいので、ボットに返却するhtmlは、JSを動かして、ちゃんとコンテンツがある状態にしてしまおう（レンダリングする）というのがダイナミックレンダリングです。

サーバサイドレンダリング（SSR）との違い

SSRは、全てのアクセスに対して、レンダリングを行います。 対してダイナミックレンダリングでは、bot等の一部のアクセスに対してのみレンダリングをするという違いがあります。

検索エンジン向けのコンテンツと中身を分けるという事なので、あまりSEOに良く無さそうと心配されるかもしれませんが、Googleさんも推奨している方法なので、安心して使って良いかと思います。

インフラ構成

ダイナミックレンダリングシステム構成図
システム構成図
インフラはAWSで固めており、CloudFront、S3、Lambda@Edgeを利用した構成です。 それぞれのサービスを軽く説明します

S3

みんな大好きS3、SPAのhtmlやjs等のリソースの置き場所です。 静的ウェブサイトのホスティング機能を利用します。

CloudFront

みんな大好きCDN、AWSサービスとの親和性は素晴らしいです。
ハンドリングの設定をもうちょっと柔軟にしたいですお願いします

Lambda@Edge

CloudFrontでのアクセス時に、なんとAWS Lambdaを動かすことが出来ます。 動かすタイミングは4種類設定でき、今回は以下の2つを使います。

  • Viewer Request CloudFrontがユーザーからリクエストを受信したときに動きます。
    Botかどうかを判断する処理を行います。
  • Origin Request CloudFrontからS3へのリクエスト時に動きます。
    Botだった場合のレンダリング処理を行います。

設計のポイント

Lambda@Edgeの使い方について疑問に思った方も多いかと思うので解説します。

Viewer RequestとOrigin Requestの2つを利用している理由

Viewer Requestだけで全部処理したほうが良いと感じるかも知れませんが、Lambda@Edgeの制限により、この構成を取っています。

ダイナミックレンダリングでは、Lambda上でブラウザを動作させて、レンダリングされたHTMLを返すのですが、ブラウザを動作させるには大きなメモリサイズと、そこそこの時間がかかります。

これがViewer Requestだとメモリ128MB、タイムアウト5秒と制限されてしまうため、動作させることが出来ませんでした。

そのため、重い処理の部分は屈強なLambdaを用意できるOrigin Requestにまかせています。

Lambda@Edgeの実装

次回、Lambda@Edgeの実装周りについて書きます。とりあえずソースさえあれば十分という方はGitHubを参考にしてみてください。
https://github.com/snicmakino/dynamic-rendering-lambda
（未検証だけど多分動作するはず）

@material-ui/iconsをインストールする際のESOCKETTIMEDOUTエラーの解決方法

React yarn

yarnを使って@material-ui/iconsをインストールする際にエラーが発生した。

対応方法

.yarnrcをプロジェクトのルートディレクトリ（package.jsonとかあるところ）に作成し、ファイルの中身を以下のように設定する。
（設定内容は、タイムアウトを10分にするというもの）

network-timeout 600000

ファイルの作成が終わったら通常通り、yarn add @material-ui/iconsでインストール出来る。
※ インストールには数分時間がかかる事があるので、キャンセルせずにちゃんと待つ

現象と調査方法

エラー発生時のログは以下の通り

> yarn add @material-ui/icons
yarn add v1.16.0
[1/4] Resolving packages...
[2/4] Fetching packages...
info There appears to be trouble with your network connection. Retrying...
info There appears to be trouble with your network connection. Retrying...
info There appears to be trouble with your network connection. Retrying...
info There appears to be trouble with your network connection. Retrying...
error An unexpected error occurred: "https://registry.yarnpkg.com/@material-ui/icons/-/icons-4.9.1.tgz: ESOCKETTIMEDOUT".
info If you think this is a bug, please open a bug report with the information provided in "C:\\Users\\hogehogehoge\\yarn-error.log".
info Visit https://yarnpkg.com/en/docs/cli/add for documentation about this command.

ググったら割とすぐに出てくる github.com

where the number is milliseconds to wait (600000ms = 10min) Please note that even if it doesn't timeout during the download, it's still probably going to take several minutes to un-tar the archive, since it has somewhere close to 90,000 files in it 😞

ざっくり訳すと、ダウンロード中にタイムアウトしなくても、9万近くのファイルが入っているので、アーカイブを解凍するのに数分かかるっぽい。
この解決方法は結構すぐ見つけられるんだけど、あまりにも待ち時間が長いからキャンセルしたりしていたので、備忘録に残す。

時間かかっても安心して待とうねという話

スマートコントラクトについてのメモ

ブロックチェーン スマートコントラクト

スマートコントラクトの活用の提案をされるかもしれない。
ネット記事とか読んでいても「とにかく契約のコストが下がるし画期的！！」みたいな説明しか見ないので、自分の言葉でメモする。

スマートコントラクトとはなにか

ブロックチェーン上でコントラクト（契約）を行う仕組みで、イーサリアムで実装されている事でも有名。

つまりどういうことか

スマートコントラクトとは事前条件を満たした時に取引が行われる仕組みのことである。
事前条件とは、ブロックチェーン上に登録されているデータが〇〇になった場合というような条件のこと、具体的に「友達登録が完了したら」、「集まったお金が1万以上 」といった条件をブロックチェーン上に登録し、条件を満たした時に取引が履行される。

勘違いしやすそうな場所

契約の条件はデータである
世の中すべての契約に対して簡単に対応出来るかのように語られているが、基本はブロックチェーン上のデータなので、データとして管理できるものである。
契約が成立したかどうかは結局ブロックチェーン上のデータに乗せる必要があるので、「病気になったら」という条件であれば、誰かがその内容を登録する仕組みが必要となる。

取引はブロックチェーンの通貨
条件が満たされた時に契約が履行されるが、その取引に使われるものは仮想通貨である。
イーサリアムのコントラクトであれば、イーサリアムが契約内容に沿って支払われる。
これは、現状の価値が大きく変動するような通貨の場合、正直お遊びの範疇を超えないし、かといってエコシステム全体をコントロールするような仕組みを作る（日本円と換金可能みたいな）としたら、ブロックチェーンの意味って。。。ってなりそうで難しい問題。

ブロックチェーンに対する所感

相互にデータの整合性を保証し合うという仕組みとしては面白い部分はある。
しかい、正直ブロックチェーンじゃないといけないというものが今の所存在しないのが厳しい。
基本的にユーザーから見ると、利用しているサービスが非中央集権なのか、Googleのようなビッグプレイヤーなのかを気にすることは殆どない。

ただ、破壊的イノベーションである可能性も秘めているので、今前線で頑張っている人たちを否定するつもりはない。
（破壊的イノベーションは、発生時の性能面等は既存の仕組みより劣っていて、その後の研究や実用の中で既存の仕組みを超えるようになる）

今後学習すべき技術領域

エンジニア 学習

今まで、Webのエンジニアをしてきました
これからも、きっとWebを中心にITのエンジニアを続けていきますが、これから学ぶべき技術について、自分の思いをまとめて記事にします（マサカリ歓迎……弱めにね）

早く作って早く壊すサーバサイド

これからの時代、早く作って早く壊す、つまり開発のリードタイムを短くしていく事が重要です そのための技術として、サーバーレスを本命に据えたい

クラウドサービスを上手く関連させあって、より早く動くものを作れる力が需要を高めていきます
（APIをスクラッチで書いてる時代じゃない！！）

サーバーレスの導入をすすめるメリットは開発スピードだけではなくて、インフラを自分で管理する必要が無くなるので、メンテナンスコストやサービス停止のリスク低下が期待されます
一番の懸念はベンダーロックインであったり、各サービスの信頼性ですが、自分で設計して作るより圧倒的に早く信頼性が高いものになると思っているので、まず作って、困った部分を独自で実装したりといった方針が良いのではないでしょうか
動くものを最速で仕上げ、そこから改善していくのが重要です

クライアントサイドの技術

APIを構築するのが簡単になってくると相性が良いのはフロントエンドの技術です
VueやReactを使って、ファイルストレージにリソースを置くだけで、Webサービスが動かせてしまうわけです（サーバーレスシングルページアプリケーションってやつです）

クライアントサイドといえばスマホも外せない
SwiftやKotlinを使った開発を覚えるのか、各OSの機能を隅々まで使わないのであれば、ある程度共通で開発できるXamarinやReact-native等を学習するのも良いかもしれません（個人的にはflutterが気になる）

また、最近はPWAも注目を集めていますね
サーバサイドな人間の私からすると、ネイティブアプリ等を学ぶより学習コストが少ないように見えて、「フロントちゃんと学ぶの流石にしんどいから、簡単なPWAでも作れるようになったら良いんじゃないかな」って感じで一人で何か作る時に良い感じに脱力できるものとして期待しています（こんな捉え方だと怒られるかも）

複雑なものをしっかりと作る

今までさんざん簡単にものを作る時代！！といっていましたが、ビジネス要件の複雑さは変わらないので、複雑なものをしっかりとロジックに落として作る力も重要です（DDDとか勉強しましょう）

個人的には二極化が進むと思っていて、複雑なロジックだけが乗ってるアプリケーションをコンテナ等で動かし、他の部分を外部サービスに切り出していくような構成がメインストリームになっていく事が想定されます

で、せっかくコンテナという言葉が出てきたのでちょっと言及すると、コンテナ超大事です
言わずもがなもう既に大コンテナ時代は到来していて、ビジネス要件が乗った小さいアプリケーションをコンテナに乗せて、関連し合うように作るには、k8s等の技術領域は必須です

気になるブロックチェーン

最近ちょこっと学習しているのですが、既存の概念とは全く違う技術だなという印象、まさに破壊的イノベーション！！

現状だと課題も沢山ある（スケーラビリティ、即時性、匿名性等）技術ではあるものの、今後もっともっと用途は広がり、当たり前の技術になっていくでしょう
その時に勉強を始めても、ちょっとついていけない自信があるので、この領域は使わないとしても積極的にキャッチアップしたいです

AI、IoT、VR/AR

流行ってるし、ハイカラだよね（鼻くそほじー）
このあたりは、間違いなく今後伸びてくるんですけど、ちょっと専門外と言うか、多く言及できる領域じゃないです

IoTはビッグワード過ぎて具体性がない言葉ですよね。やるならもうちょっと細かく落とし込んで考えたい
（ハードの世界が入ってきたり、大量データ処理が入ってきたり、IoTって言葉だけだと広すぎる）

AIは、機械学習がものすごい進歩してるんですが、言葉が独り歩きしている部分も多くて、世の中がAIって言っている8割くらいはAIじゃなくても良かったり、ただのロジックをそう言ってるだけだと思ってます。んで、残りの2割は本当に凄いイメージ
自分が機械学習を学ばないとしても、機械学習で何が出来て、何が出来ないのかは把握しておきたいですね

ビジネススキル・マネジメントスキル

問題の設定方法や、問題解決の手法、コミュニケーション、チームビルディング等の非テクニカルなスキルですね
開発する際に、明後日の方向を目指さないためにも、チームがバラバラな方向を向かないためにも、しっかりとした目標設定と、それをチームとしてまとまって進んでいく推進力が必要です

チームリーダーが持っていれば良いって噂もありますが、今求められるのは自走できる人材。自走できる人材は、こういうスキルをしっかりと持っているに違いないです

自分が取っていく行動

今後自分の武器としたい

  • サーバーレス

得意領域にしていく

  • ビジネススキル・マネジメントスキル
  • コンテナ

書ける、扱えるくらいにはする

  • フロントエンド（Vueかな）
  • PWA

継続的に学習する

現在は、JavaやPHPを使ったWebの開発や、RDBなんかが得意ですが、今後はスクラッチを極力減らしてPaasの比率をあげたり、サーバーレスを使えるようにしていきます
ちなみにブロックチェーンは半分趣味です

英語の勉強もしないと。。。

「強いエンジニアリング組織をつくる vol.2」というセミナーに参加しました

エンジニア 評価 育成

株式会社クライス＆カンパニーが運営する汐留アカデミーというイベントで、
強いエンジニアリング組織をつくる vol.2というセミナーに行ってきた

以下のメンバーが講師として呼ばれており、パネルディスカッション、質疑応答や、交流会を行った

及川卓也氏
BASE 取締役CTO 藤川真一（えふしん）氏
ビットジャーニー 代表取締役 井原正博氏

数々のイベントやインタビュー記事でアウトプットをしている方々だが、実際にお会いするのは初めてだったので、ちょっとしたライブに行くような浮足立った感覚はあったかもしれない 笑
この記事では、その中であった話を中心に、エンジニアの評価と育成について軽くまとめたものを書く。「この人たちが言っていた」ではなく、ざっくばらんなパネルディスカッションや質疑応答の中で、自分のバイアスを通して引っかかったものをまとめただけの記事として読んでほしい

OKRについて

今回のセミナーでは、OKRという手法が中心に話が展開されることが多かったので紹介しておく、以下のリンクがわかりやすくまとまっている careerhack.en-japan.com

また、日本語としては初めてのOKR本が発売されると及川さんより宣伝があった
前半はストーリー仕立てでOKRが紹介されていて、後半は解説という形式の本で、なかなか良いらしい https://www.amazon.co.jp/gp/4822255646

評価について

評価と言うと上から目線で価値を判断するようなイメージとなってしまうが、改善と、より成長するために本人に対しての気付き、フィードバックの場として機能させるべき
個人は何かしらの成果を出すために仕事をしているので、その行動が組織の目標（意図）とギャップがあるのであれば、評価の際に気づかせる。そのため、頻度はなるべくリアルタイム性をもたせるべきである

能力は定量化出来ない

能力は定量化出来るものではない、組織が何を重要視しているかをしっかりと決め、それらがどのくらい出来ているのかではかる（エンジニアリングにおけるコアバリュー評価と言うべきか）

例えば、動くシステムをとにかく早く作る力（A）と、丁寧で柔軟なシステムが作れる力（B）は、トレードオフの関係にある（とする）
どちらも突き詰めれば技術力のレベルは上がっているが、組織では、（B）に重点を置いている前提のもと運営すれば、定量化出来ないにせよ、（B）が出来る技術者の評価が相対的に上がる。気をつけなければいけないのは、（A）に強みがある技術者を評価しないというわけではない

また、定量化した場合に、数字だけのための行動になってしまっては本末転倒なので、そこは考慮する必要がある

能力評価は職位連動に

能力に対する評価は、給料連動ではなく、職位連動にする（職位を能力の期待値に対して上がる） 達成した結果に関しては、ボーナス連動にする

OKRと評価を結びつけてはいけない

OKRの達成度と評価を結びつけると、OKRで出す目標が小さくなってしまう。目標はしっかりとしたものを出させて、それの達成度は評価軸にせず、その目標に対してどのくらいフォーカス出来たかという軸で評価する

育成について

やる気がある人を集め、その人達の邪魔をしないこと
向いていないことはなるべくやらせないで、向いていることをさせる
出来ない人のためのルールを作らないこと

評価者の育成

大切なのは評価者の教育で、評価者毎に軸がぶれていると、組織にダメージを与える結果となってしまう
座学（知識）の教育も大切で、例えば、評価時にアンコンシャスバイアスという概念の影響を減らすため、評価者が評価時の注意点を見ながら評価するといった対策をする

何かをするわけではない

育成に関しては、基本的に何をするということは無い、採用段階で組織の目標をブレイクダウンして自走できる人を見極めて採用することが重要

まとめ

どこの会社も評価や育成は苦労しているようだった
その中でも、以下の要素は共通して重要視されていたように感じる

  • 組織の目的、価値をはっきりさせ、下部組織、メンバーに落とすこと
  • 個人個人の考えや取り組みを大切にすること
  • 組織と個人の行動とギャップは、面談でリアルタイムに拾って解消すること
  • 自走できる（ようになる）メンバーを採用する

エンジニアの育成や評価に対して今まで考えてきて、答えが出ない悩ましい問題ではあったが、今回のセミナーは自分よりも高い目線で、長い期間同じ命題について考え、実践してきた内容を聞くことが出来たので非常に勉強になった。今後の組織をより良くする活動に活かせるようにしたい。

NEMのハッカソンの入賞したソリューションのまとめ

NEM ブロックチェーン ハッカソン

NEM GLOBAL HACKATHON

公式ページ コインチェック盗難事件ので世間の認知度を上げたNEMが、ひっそりとハッカソンを開催し、ひっそりと勝者が決まったので、どんなチームが優勝したのか確認してみる

個人的な考えだと、ブロックチェーンで何かを作るには、エコシステム全体のデザインをしなければならないと思っていて、導入している人たちが相互に協力しながらシステムのコミュニティを育てていけるようなものが出てくることを期待している

※ この記事ではハッカソンの情報をかなり乱暴に訳して載せているので、できれば本家の情報を見てください

NEMについて

以下のサイトが詳しい
ネム（NEM）/ XEMとは？概要と最新情報

NEMを利用する時は、NIS（NEM Infrastructure Server）という管理サーバを通して取引等が行われている。また、NISはAPIを提供しており、そのAPIはかなり開発者に扱いやすいものになっている（ドキュメント読んだだけで触ってないけど）

個人的にエンジニアがブロックチェーンでなにかしたいってなった時は、NEMを利用するとハードルはかなり低くなる印象がある

ルール

ルールはここに英語で書いてある
ざっくり言うと、「NEMの機能（mosaicとか）を使ってイカしたソリューションを考えて、アプリを作って競い合え、優勝チームには1万ドル（相当のXEM）を与えよう！」といった感じ

審査基準は以下の6点

  1. NEMプラットフォームとの統合(20%)
    　NEMのプラットフォームをいかに有効に使っているか

  2. ユーザインタフェース(10%)
    　アプリの見た目

  3. ユーザエクスペリエンス(10%)
    　アプリの使いやすさや得られる体験、 人間工学に基づいてスコアリングされるらしい（ほんまかいな）

  4. 用途(20%)
    　ソリューションが主要な産業においてどのような用途で使われるのか

  5. 適合性(20%)
    　既存のアプリケーションとの適合度が高いほど良い

  6. OSS(20%)
    　アプリをOSSで公開したチームにボーナスポイント！

優勝チーム

SOW (SOCIALWALLET)
（特別賞の「Best Solution to Real World Problem」も受賞）

ノルウェーのチームが開発したXEMの送金ハードルを下げるウォレットアプリ

Facebookでサインインをし、NEMのアドレスではなく、Facebookの名前で送金を行える（Facebookアカウントが無い人に対しても、手動で追加して対応可能）
インタフェースはBotとのチャット形式で行うっぽい、LineBotとか、SlackBotのようなイメージかな
よく出来ているし、まだまだ取引所で仮想通貨を眠らせておく人が多いので、XEMのやり取りをより簡単に、活発にするアイデアが評価されたのかな

2位

NEM Supernodes Crowdfunding
（特別賞の「Ease of Implementation」も受賞）

NEMのスーパーノードを支援者で運営する仕組み（？）
ちょっとわからないことが多いんだけど、スーパーノードの一口馬主的な感じかな・・・・・・
スーパーノードは結構たくさんのXEMが必要だったり、一般人だと難しいから、少額な支援者をたくさん集めて運営するアイデアかな

スーパーノードについては以下のブログ記事にまとまっている
NEMのスーパーノードとは｜初心者でもわかる解説【完全版】 | はじめてのビットコイン

3位

SocialCake

デジタルデータのコンテンツ販売プラットフォーム
アーティストやクリエイターが、購入者に対して直接販売が出来るようにする仕組み
NEMのブロックチェーン上でデジタルコンテンツを載せることができ、料金を受け取ったら、ダウンロード用URLを購入者に発行して、売買を行う

特別賞

NEMgo
「Most Innovative」、「Community's Choice」を受賞

日本のチームのソリューション

プロバイダーとコレクターが利用するアプリケーションで、プロバイダーは地図上にコインを設置し、コレクターは地図上のコインがある場所に行くとコインを取得することができる
プロバイダーはたくさんのコインを設置することで、宣伝や集客することが可能
ものにする

感想

今回のハッカソンでは、NEMという仮想通貨を、より様々な方法で利用できるアイデアが多かったように感じた
仮想通貨は現在、法定通貨との交換を前提とした投資が利用方法の大部分を占めるが、やり取りが出来る経済圏を広めることが当面やるべきことなのかもしれない

限られた期間で、アイデアをしっかりと形に出来るのは素晴らしい、刺激をもらったので自分もアイデアを形にしていこう

※ 各プロダクトはYoutubeの動画や、Githubへのリンクがあるので、興味がある人は覗いて見ると良いと思う