親しみを感じるパターンの書き方
パターンを書くのは、当然自分の知識やノウハウを人に伝えたいという思いから書きます。書いていく中で、より人々に共感や親しみを感じるように書くにはどうしたらよいのかと思うようになります。実際、パターンを読んで自分の業務などに活かしたいと思う人は、そのパターンに書かれている内容に初めて触れて学ぶので、多少なりとも認知的な負荷が生じるわけです。
このような負荷を抑えながら、パターンに記述された知識をいかに人にスムーズに伝えられるか。これをパターンの書き方によって、少しでも実現できないか。発表されているパターンを読みながら、そのようなことを考えています。今のところ、下に挙げるようなポイントがあるかなと考えています。
イラストが書かれている ： パターンの冒頭に象徴する絵が書かれているものをよく見かけます。パターン記述は論理的な左脳を働かせる感じですが、最初にイメージ画像があると、自然と直感的な右脳も刺激されるような気がします。
形式張らない： パターンは、コンテキスト・問題・フォース・解決方法・結果といった項目に則り記述されることが多いです。これは知識を整理する上では有用ですが、形式的すぎて人に伝えるには無機質な印象を与えるかもしれません。形式張らず、パターンの項目を立てているにしているものがいくつかあります。伊庭先生のパターン"ラーニング・パターン"などは、このような印象です。
フランクな記述： 上と似ていますが、パターンは論文で発表されることも多いためか、少々固い文章で書かれることもあります。ただ、人に共感を持って伝えるという観点では、砕けた表現でパターンを書くのも一つの方法に感じます。Fearless Changeの日本語訳はまさにこのような印象。
ストーリーテリング： パターンの中には、項目を立てて形式的に知識を書くものですが、それだけでなくそのパターンを使ってみたときにどんな効果があるのかを物語として書いているものもあります。これも、パターンを読む人が、置かれた状況を追体験でき、イメージをしやすくする効果がありそうです。ストーリーになると、人の感情を揺り動かす効果があるので印象に残るのかも。Fearless Changeでは、いくつかの章を使って現場にパターンを適用していく物語が描かれています。
私自身、パターンをたくさん読み込んでいるわけではないので、他にも「親しみを感じるパターン」のパターンがありそうですね。引き続き、模索して考えていきたいです。
MLFlowとSageMakerのAWSサンプルをデプロイするときの注意点
MLOpsに興味があり、実験管理のためMLFlowを試してみたいと思っています。ちょうど、AWSでMLFlowを動かすサンプルが公開されていたので、これを動かしてみることにしました。サンプルをデプロイするまでに幾つか躓いたので、注意点をまとめたいと思います。
https://github.com/aws-samples/amazon-sagemaker-mlflow-fargate
Prerequisites
サンプルを動かすのに、パッケージをいくつかインストールする必要があります。
- pythonはこの方法でインストールしました(v3.9.7)。
https://www.python.jp/install/ubuntu/index.html - nodeはこの方法でインストールしました(v14.18.1)。
https://qiita.com/seibe/items/36cef7df85fe2cefa3ea - AWS CLIはこの方法でインストールしました。
https://docs.aws.amazon.com/ja_jp/cli/latest/userguide/install-cliv2-linux.html - AWS CDKはこの方法でインストールしました。
https://docs.aws.amazon.com/cdk/latest/guide/getting_started.html
Deploying the stack
コマンドを幾つか実行する必要がありますが、一般ユーザでは権限エラーが発生するのでrootユーザで実行しました。そのため、AWSの認証ファイル(config, credentials)が/root/.awsに格納された状態でコマンドを実行することがポイントです。
ちなみに、このサンプルはDockerfileでコンテナをビルドします。DockerコンテナからDockerは利用できないので、Dockerコンテナ上でこの作業をすることはできません。私は最初Dockerコンテナ上で進めようとしていて、最後のcdk deployで下のようなエラーが発生してハマりました。
Error: write EPIPE
at afterWriteDispatched (internal/stream_base_commons.js:156:25)
at writeGeneric (internal/stream_base_commons.js:147:3)
at Socket._writeGeneric (net.js:798:11)
at Socket._write (net.js:810:8)
at writeOrBuffer (internal/streams/writable.js:358:12)
at Socket.Writable.write (internal/streams/writable.js:303:10)
at /usr/local/lib/node_modules/aws-cdk/node_modules/cdk-assets/lib/private/shell.ts:28:19
at new Promise (<anonymous>)
at Object.shell (/usr/local/lib/node_modules/aws-cdk/node_modules/cdk-assets/lib/private/shell.ts:26:10)
at Docker.execute (/usr/local/lib/node_modules/aws-cdk/node_modules/cdk-assets/lib/private/docker.ts:75:13
【AWS】AWS認定ソリューションアーキテクト－アソシエイトに合格しました
AWSのソリューションアーキテクト(アソシエイト)を受験し、無事合格することができました。巷には、この試験の合格談がいくつもアップされていますが、例にもれず本サイトでも合格にいたるまでのプロセスを一つの例としてまとめてみたいと思います。
点数
794
予備知識
- AWSクラウドプラクティショナーの基礎知識(デジタルコース)を受講
- AWS Architecting on AWSトレーニングを受講
- ルンバの位置監視サービスで少しAWSを触る
- 実務でのAWSの利用経験はなし
勉強方法
勉強期間
1ヶ月半程度(8月中旬～9月下旬)
受験までの流れ
まず、予備知識として無料のセミナーやAWSのトレーニングによって、AWSが提供するサービスについてある程度の概要は掴んでいた感じです。また、以前投稿したルンバの位置監視サービスを作った経験から、LambdaやDynamoDBなどのサーバレスのサービスについては、具体的な使用イメージを持っていました。 そこから、AWSのトレーニングの復習と範囲外の内容を学習するため、問題集を購入し、勉強をはじめました。購入した本は↓になります。AWSのサービスについて網羅的に書かれていて内容も分かりやすかったと思います。寝る前に1時間位読むを毎日繰り返していた感じです。
テキストを大体2周くらいしたタイミングで、実力を測るためAWSの模擬試験を受けました。結果は、52%で芳しくない結果に。振り返ると、参考書でサービスの概念はなんとなく押さえていましたが、少し踏み込んだ仕様を押さえていなかったので、試験の中で問われるサービス構築のために必要な対応を導き出すことができなかったのだと思います。この点、参考書だけで合格するのはかなり難しいと感じました。
そのため、問題を繰り返す解くことで実践力をつけようと考えましたが、これだという問題集が書籍やWebでも見つからなかったというのが正直なところです。結局、こちらのAWS問題集(AWS)で勉強することにしました。こちらの問題集を、結果として受験までに2周しました。問題数もそこそこあり感覚を掴むのに役立ちましたが、書籍というメディアのため、将来的には情報が古くなることが気がかりです。
書籍だけの勉強では、問題数とカバー範囲に不安を感じ、UdemyのAWS模擬試験を解きました。こちらは難易度が高めという紹介があり、試験で出される問題の難易度の上限を確認する意味でも取り組む価値があると考えました。実際に受けたところ、確かに難しい。高難易度の模擬試験は正答率5割程度でした。この模擬試験を受けて、解説内容で復習することで応用力は付いたと思います(その後、書籍の問題集に戻って解いたところ簡単に感じた)。ただ、高難易度の模擬試験⑤を受けたところ、試験範囲から外れた問題が多く出てきたような感じがしたので、そこでこの模擬試験を使った勉強は打ち切りました。
受験した感想
テストセンターで受験しました。受験の感想としては、問題の日本語がわからないことが予想以上に多かったです。英語の原文を読んで問題を理解することを何回もしました。問題の内容としては、参考書や問題集でカバーしていない問題が何問か出ましたが、多くの問題は問題集でカバーされている内容であり、繰り返し問題集を解いてパターンを押さえておけば答えられるという印象でした。
人に伝わるパターンとは
パターンを開発チームに浸透させていくには、どうしたらいいか、ここで仮説として思うのは、分かりやすい言葉でパターンを記述するのはもちろんのこと、文体を読みやすいように工夫することも必要なのではないか、ということです。
上司の部下に対する接し方として、一緒になって課題を考えてあげるいわゆる伴走型の上司が求められていると言われて久しいですが、パターンについても同様のことが言えるのではないか。
というのは、パターンは、ある比較的熟練者が他の人にノウハウを伝達する目的で作ります。そう考えると、パターンを記述する人には技術的あるいは知識的優位に立つという前提が生まれ、そこには意識するしないに関わらず上下関係が生じることになります。
もちろん、学会などの正式な場でパターンを発表するという時には、型に則った形で整理するのが良いと思います。それとは別に、特にチームで一緒に働いているメンバーに対して知識を共有するには、先の伴走型のようにパターンを通じて一緒に分かち合おう、という意思が伝わるものが良いのかなと思うのです。体温の伝わるパターン、でしょうか。
体温の伝わるパターンとは、どのようなものでしょうか。パターン記述の型や文体、色々な観点がありそうです。最近はこんなことを考え始めています。
パターンに関しては、慶應大の伊庭先生が長年研究をされています。伊庭先生の研究室の学生をメンバとしたコラボレーション・パターンを拝見したのですが、人に伝えようという意識が伝わるパターンに感じました。
人に伝わるパターンというのは、どのようなもので、どう書くのか。このあたり、どこかで時間をとって考えてみたいなと思います。
【AWS】【AWS IoT Core】【やってみた】ルンバが本当に掃除しているのか監視するアプリをつくってみた(番外編)
前回の投稿で作成した、「ルンバの位置監視サービス」開発の番外編になります。ルンバの位置をどのように取得するかという課題を解決するまでの紆余曲折を書きます。ここは、開発技術についての説明はありません。ただの苦労話といえば苦労話なのですが、実際の開発ではこういった泥臭い試行錯誤も必要なのだな、という教訓としてここに記録を残しておきます。
前回の投稿はこちら。
ルンバの位置をどう検知するか
サービスの実現にあたっては、ルンバの現在位置をどのように取得するかという問題を解決しなければなりません。ここに関しては、アプリをつくるという目的からは外れたところなので、なるべくさっさと終わらせたい気持ちが強かったのですが、ここでかなり手間取りました。
センサでモノの位置を取得する方法について、Googleで色々と調べてみたのですが、なかなかこれだという方法がみつからない。一番想像しやすいGPSを使う方法は精度の観点で難しく、ビーコンを使う方法も同じく精度の観点で難しい模様。自動運転などで使われているLiDARは、難易度が高く設備も数十万と高すぎる。マップを作成して自己位置を推定する方法(SLAM)もあるようですが、専門的な知識がない人間には敷居が高すぎる。。
最初の有望株：NFCタグ
そんな中、最初の有望株として見つけたのが、NFCタグを使用する方法。日常的には、交通系ICカードなどに利用されている技術ですね。スマートフォンにNFCリーダがあるので、ルンバの上にスマートフォンを取り付けて、天井からぶら下げたNFCタグの下を通過したときに位置情報をクラウドに送信すれば実現できそう。ちょうど、改札でカードをピッとタッチするイメージですね。
実際に、NFCタグを10枚買ってみて実現できそうか試してみたのですが、これがどうやら難しそうであることがわかりました。どこが問題かというと、検知範囲の狭さです。本当にNFCタグの真下をスマートフォンが通過しないと反応しないので、ルンバの現在位置を知ろうとすると大量のNFCタグが必要になります。一つのNFCタグの大きさは3cmほど。これを、ルンバが通りそうな場所に張り巡らせようとするとタグが何百枚、費用的にも数万円かかってしまいます。そして、使い終わったあとのタグを、一体どう処理したらいいのか。。。ということで、NFCタグを使った方法は却下となりました(まあ、なんとなくそんな予感はありましたが)。
QRコードを使った方法を思いつく
手軽な実現方法はないのではないかと、半ばあきらめかけた時もありましたが、ある時QRコードを使った方法を思いつきました。スマートフォンにつけたカメラでQRコードを読み取り、そのデータを送信する方法です。この方法であれば、NFCタグで問題となった検知範囲の問題についても、ある程度の範囲であれば読み取ってくれそう。。
この方法も最初はうまくいきませんでした。スマートフォンのカメラでQRコードを読み取ろうとすると、ルンバの移動スピードが速く読み取れないことがわかりました。どうやら、処理性能が足らないようです。また、読み取れたとしても、読み取ったデータをクラウドに送信する処理を、専用のスマートフォンアプリを開発して実現しなければならないため、目的がもはやスマホアプリ開発になってしまいます。
ということで、カメラを使ってQRコードを読み取る方法も却下。検知性能が問題であれば、ということで、専用のリーダを使ったら良いのではないかと思い、思い切ってQRコードリーダを発注。Amazonで小型でポータブルで比較的安い(何万もしない)ものがあったので、これを使ってみることにしました。
https://www.amazon.co.jp/gp/product/B07T35G1QN/ref=ppx_yo_dt_b_asin_title_o04_s00?ie=UTF8&psc=1
これがうまくいきそうでした。リーダーをルンバの速度で動かして、50cm離れたQRコードを読み取ることができました。リーダーの場合、カメラとは違って検知範囲が狭くなりますが、QRコードを複製してA4の紙に敷き詰めれば、広範囲での検知ができそうです。これは、NFCタグではできない解決方法ですね。
また、読み取ったデータをテキストデータでBluetooth送信してくれることも魅力的でした。これであれば、デバイス依存のアプリを作ることなく、PC側で受け取ったデータを整形してAWSに通信してあげればよく、実装のコストも抑えられそうです。
いろいろと試してみたところ、A4用紙に3×4にQRコードを敷き詰めて印刷すると、検知性能に問題がないことがわかりました。あとは、部屋の領域にID番号を割り振って、そのID番号に対応するQRコードをその場所に置いておけば、ルンバの現在位置を送信することができそうです。
実際に動かしてみる
実際に、部屋にQRコードを張り巡らせたときの写真がこちら。壁に梱包用の紐を付けて、途中にQRコードを印刷した紙を部屋のIDに併せてくっつけています。写真は部屋の一部ですが、実験中部屋はQRコードと紐だらけであり、ルンバは下を通り抜けるので大丈夫ですが、人が移動するのは厳しい状況。実際にルンバを動かしている時も、壁に付けていた紐が何度も取れてしまい、紐をまたぎながら修復しに行く、といったことを続けていたのでとても疲れました。
とはいえ、一応想定通りルンバが下を通るたびにQRコードを読み取ってくれ、ようやくルンバの現在位置を取得することができました。当たり前ですが、この方法ではサービスが動いている間は部屋が使用できなくなってしまうので、実用化するにはこれ以外の方法を採用しないといけませんね。
【AWS】【AWS IoT Core】【やってみた】ルンバが本当に掃除しているのか監視するサービスをつくってみた
最近、クラウドの開発知識を得たくて、AWSの勉強をしています。勉強するにあたって、知識だけではなく、やはり実践的になにかのサービスを作ってみたほうが勉強になるだろう、ということでネタを考えていました。
そこで、目に留まったのがルンバ。ボタンを押しただけで部屋の掃除を勝手にしてくれる優れものなのですが、どうも同じところばかり掃除しているように見える。。うちのルンバはスペックが低くカメラが付いていない機種なので、仕方ないといえば仕方ないのですが。。
ということで、ルンバが実際にどこを掃除しているのかリアルタイムにわかるサービス(Roomba Police)を、AWSを使って作ってみた、というお話になります。
作成したコードはこちらにアップしています。
システム構成
全体のシステム構成は下の図のとおりです。ルンバの現在位置は、部屋の位置IDを書き込んだQRコードを読み取ることで検知します。読み取った位置IDをクラウド側に渡すことで、ルンバの位置を監視する仕組みです。クラウド側は、IoT Coreの初級ハンズオンと同等の構成で実現することができました。
https://aws-iot-core-for-beginners.workshop.aws/
作成期間は、おおよそ4日程度です。AWSの使い方を勉強する目的で始めたのですが、結局ルンバの位置情報の取得方法(QRコード)の検討とブラウザでルンバの位置を表示するプログラムの実装に半分以上の時間を使った結果になりました。AWS側は、lambdaの実装をサンプルから大部分流用できたのが大きいですね。ただ、サービスを実現するための最低限の作業しかしていないので、IAMなどの設定を加えるとなると、もう少し時間がかかると思われます。
ルンバの位置登録
ルンバに取り付けたQRコードリーダは、部屋にあるQRコードから位置IDを読み取ります。読み取ったデータは、BluetoothでPCに送信されます。QRコードリーダから送信されるデータは、標準入力でテキストデータの形式で受け取れるので、簡単に取り扱うことができます。
PCでは、標準入力で位置IDを受け取り、それをMQTTでAWSに送信します。IoT Coreとの接続は、AWS IoT SDKを使う必要があります。Pythonを使用した実装方法は、下のページに詳しく書かれており、この内容を少し書き換えることで実装ができてしまいました。ファイル行数としても、50行強程度です。経験はないのですが、面倒なイメージのある証明書を使ったセキュアな通信を、こんなに簡単に実現できるのかと驚きました。
https://aws.amazon.com/jp/premiumsupport/knowledge-center/iot-core-publish-mqtt-messages-python/
AWSに送られたMQTTのデータは、IoT Coreで時刻と位置IDが解釈され、バッファとなるKinesis Data Streamsに送られます。lambdaは、Kinesisからデータを受け取り、DynamoDBにルンバの位置情報を登録します。この処理は、IoT Coreハンズオンで使用されているPythonコードを改造して実装しました。これで、ルンバの指定時刻の位置をAWSに登録することができました。
ルンバの位置表示
続けて、参照側の実現方法です。大きな流れとしては、WebブラウザからS3に格納したHTMLファイルにアクセスし、API GatewayのREST API経由でDynamoDBに格納されたルンバの位置情報を取得して表示します。
Webブラウザは、静的ウェブサイトホスティングを有効にしたS3にアクセスし、Webページを表示します。Webページは、一定時間おきにJavaScriptでAPI Gatewayに対しHTTP GETを発行し、ルンバの最新の位置情報を問い合わせます。(今回は3秒おきで更新するように実装しましたが、あんまり更新頻度が大きいとたくさん課金されそう。。今回は個人利用なので良しとします)。API Gatewayは、HTTP GETリクエストを受け取ると、lambdaをキックします。lambdaは、DynamoDBから最新の位置IDを取得して、Webブラウザに返します。このlambdaの実装も、IoT Coreハンズオンの内容の多くを流用して作ることができました。
Webブラウザは、受け取った位置IDからルンバの位置を計算し、ルンバの画像を移動させます。なお、画像の移動はCSSアニメーションを利用しています。このあたり、フロントエンドの開発知識があまりなかったので、結構時間を使ってしまいました。
検証結果
このようにして、QRコードリーダから送信された位置情報をもとに、Webブラウザ上にルンバの位置を表示させるサービスを作ることができました。併せて、現在位置の表示だけでなく、過去の動きをトレースするページを作成しました。完成したページは、下の動画のように動きます。リアルタイムにチェックするよりも、後から掃除していたか確認するこちらの方が、ユースケース的には便利そうですね。
肝心のルンバの動きの方はというと、ベージュのエリアを掃除して欲しかったのですが、あまりそちらには向かってくれなかったようです。。うーむ。 youtu.be
Simulinkでタイマをつくる(Part2)
Simulinkでタイマを実現する方法の続きです。こちらのタイマは、一定時間置きに1を出力します。一定時間経過後に1を出力し続けるタイマは、Simulinkでタイマをつくる(Part1) - highitoh’s blog
を参照ください。
また、ここで実装したタイマはelapsedが0の期間が20となるものです。elapsed=1となる間隔が20となるタイマは、少し実装が変わってきます。
繰り返しタイマ
繰り返しリセットタイマ
