kumainu-devの備忘録

調べてわかったこと、困ったこと、勉強したことを書く場所

開発中のシステムがリリースされた

ブログの更新が滞って早くも半年が経過していた。 実はこの記事を書き始めたのは、4ヶ月前で、ようやく投稿することができた。

更新しなかった理由は、忙しかったからに他ならない。残しておきたい話のネタはいくらでもあるのだが、肝心の書く時間がない。しかし、現在ぶつかっている壁を解決するために、時系列として記録を残すべく、開発中のシステムをリリースするまでの流れを書いておく。

開発中のシステムとは

以前、知人からWebサイトの開発(HP+システム)を請け負った。このうち、1月の段階でホームページは完成していたのだが、システム開発については、当時まだ未着手の状態だった。

詳しい話は、以前投稿した「フリーランスとして初めてのお仕事」を参照されたい。

kumainu-dev.hatenablog.com

具体的なシステムとは、事業で行う予約システムだ。つまりReservaやStoresなどのようなサービス。普通であれば、そういったサービスに(規模によるが)月額料金を支払い、運用するわけだが、今回はそのシステムの開発も任せていただいた。

この2ヶ月何をしていたか

結論から言えば、次の3行に集約できる。

・新年~年度末で仕事がとても忙しかった ・予約システムの開発が難航した ・新型コロナウィルスを患った

3つ目のウィルス感染については、別の機会に振り返ろうと思うが、ここで敢えてそれを取り上げた理由としては、このウィルス感染で自宅療養をしたから、予約システムの完成に大きな進捗を与えたと言える。

開発を振り返る

スタート地点は0から

今思えば、当時Webの開発スキルがほとんどない状態で、よくもこんな見切り発車ができたなと、自分に言いたい。依頼を請け負った直後は、これから開発に利用するサービスの名前を知っている程度で、「これらのサービスを駆使して使い方を覚えれば完成するよねー」ぐらいの軽い気持ちでいた。こんな見切り発車ができた理由として、依頼人である知人がとても寛容で、私にとって学習を含めた開発になることや、仕事をしながら開発するから期間がある程度長くなることについて理解が得られていたことであろう。本当に感謝したい。

ホームページの開設は容易だった

まずはデザインとコンテンツのヒアリング、事業についてのインタビューなどを行い、HPのモックアップを作る。この段階で9割ぐらいの決めが必要になり、ここから先の作業は変更した場合に大きなコストが発生することについて了承を得ることが必要だ。 例えば、Yahooのトップページのようなデザインのページ案で作り込んでいき、終盤で要件が転向し、Bingのようなデザインにしたいと言われた場合、レイアウトを作成が1からになってしまうため、それまでの作業が全て水の泡になってしまう。モックアップから仕上げに入っていくに対しては、デザインの微調整やテキスト・素材の変更などにとどめておく必要がある。このあたりの進め方に関しては、幸いなことに本業で嫌というほど経験したので難なく完成まで進められた。 ホームページは1月末で完成し、調整を2月末まで行った。

予約システム開発は学習から始まった

Web開発はあまり自信がなかった。前職でRailsを用いたBackofficeの開発を担当した経験がある他は、ASP.Netを用いたWebアプリケーション開発を少しした程度。最近話題になっているサーバーレスアーキテクチャやNoSQL思考など、言葉自体は知っていたが触ったことがないという「エンジニアとしてどうなの?」的な人間だった。

サーバーレスアーキテクチャに苦戦

まず、AWSチュートリアルをやってみた。

aws.amazon.com

aws.amazon.com

最初、チュートリアルを見た時に「コマンドを打つ」から始まっており「そのコマンドはどこに打ち込むの?」という疑問から始まったのだ。

調べていくうちに、まずは開発環境を作る必要があることがわかった。幸いなことにLinuxWindowsもサーバーの立て方はわかっており、数年間運用していたので問題なくできる。

しかし思うのだ。今更ローカル環境にサーバーアプリケーションや仮想マシンをいれるのか?と。 現代ならば、開発環境ですら仮想化されているのではないだろうかと調べてみた。

あった。Cloud9。

とにかく一つずつ紐解いていき、なんとか開発環境を手に入れ、最初の「npm install -g @aws-amplify/cli」を実行できた。 ここまでおよそ3時間。 自分でも思う。これは先が思いやられる。

チュートリアルを進めて関係図を見たりしても、どうもしっくりこない。クラサバ構造でフルスクラッチ開発していた人間からすると、なんで動くの?と思うことが多々あるのだ。他にも「Qiita」や「はてブロ」で公開してくれている有志の方々のチュートリアルメモを片っ端から試した結果、何度も何度も挫折した。

挫折の大きな理由としては、(公式チュートリアルですら)「記事の鮮度」が古かったりして、期待どおりに動作せずエラーの内容を調べても解決できなかったり、チュートリアルで説明されている機能の名称やサービス自体が終了していたりなど、様々な壁にぶち当たった。

もちろん、時間をかければ解決できる問題もあるだろう。やり方がいずれわかっていくと思う。しかし、とにかく解決するための情報収集に困難を極めるため、このまま続けていくとせっかくスマートに(楽に)開発しようとしているのに、スムーズに開発できないのでは本末転倒になってしまう。

幸いなことに、チュートリアルを繰り返していくうち、サーバーレスアーキテクチャというものがどういう構造で、AWSとそうでない部分がどういった成り立ちなのかがわかってきた。 ここまでおよそ1日かかった。

まずは簡単なサーバーレスアプリケーションを作ること

チュートリアルで大苦戦して得られたのは、知識だけではない。完成には程遠いという現実もわかったのだ。しかし、請け負った限りは最後まで完成させたい。相方の励ましやエールをもらい、くじけずに頑張っていこうと決心した。

そこで、まずはリリースまでの最低限必要なものを洗い出してみた。

・開発環境 ・バージョン管理システム ・バックエンドフレームワークの選定 ・UIフレームワークの選定 ・UIライブラリの選定 ・データベースの選定 ・ユーザー認証 ・アクセス制限 ・公開

まず、開発環境はCloud9でやっていくことにした。どの環境からでも作業を再開できるので、会社やカフェ・自宅のどこからでもアクセス可能なのは非常にアドバンテージとなる。バージョン管理システムは、本業でも散々使っているGit一択。GithubのPrivateリポジトリで十分使える。バックエンドフレームワークについては、サーバーレスアプリケーションを運用したいのでLaravelやRoR、Node.jsなどが選択肢となる。Ruby on Railsは開発経験があるので選択肢の一つだったが、ここでは、敢えてNode.jsを選定した。せっかくなので新しいものを覚えたいのと、Web上の情報がかなり多く、開発しやすそうだったから。

UIフレームワークについて、最初はReact.jsやAngularを使おうとしていたが、断念した。今となっては、基本がわかっているので、React.jsでもAngularでもいいのだが、当時良いチュートリアルに恵まれず、最もシンプルさと汎用性を感じたのがVue.jsだった。Vue以外のフレームワークについては、機会があれば使ってみたい。

Vuetify導入~日本語公式マニュアルに感動

Node.jsが動いている環境なら(Cloud9なら最初からセットアップ済みの環境が手に入る)、npm install vueなどと打てば環境構築は完了する。そして、スタンドアローンでWebアプリケーションが動くまで、何もつまづかず、10分程度でHello worldが表示できた。私は英語ができないドメスティックWebエンジニアなので、日本語の公式マニュアルが充実していると嬉しく感じる。しかも、Vuetifyは非常にシンプルなので、とっつきやすく、違和感なくシームレスにコードが書けることがすごいと思う。

Router周りは少し苦労した。チュートリアルがあまりないので手探りだったが、一旦コードが動いてしまえば調べるのは容易である。

本業の仕事があるため、1日あたり1時間~2時間程度しか時間が割けないのがもどかしく感じる。 また、できれば2月中にシステムを開始できないかという相談を受けた。 現在の進捗からすると2月中のシステムアップはかなり難しそうだが、機能を制限すればなんとかできるかもしれない。

DynamoDBは断念、直感的なFirestoreに

AWSのNoSQLといえば、DynamoDB。業界でも有名だが、RDBMSにどっぷり使った自分としては、DynamoDBは少し使い勝手が良くない。クエリ条件式に使うAttributeはいちいちインデックスを指定する必要があったり(他の同じだがFirestoreは便利(後述))、スキーマの修正ができない(作り直しになる)このあたりは、開発のやり方次第では有るのだが、自分にはあっていない。 いろいろ調べているうちに、Firebaseというサービスにたどり着いた。どうやらGoogleが提供しているモバイル向けのプラットフォームで、NoSQLだけでなく、StorageやAuthまわりなどのサービスも提供してくれるらしい。しかも永年無料枠があるのが素晴らしい。

私がFirebaseのNoSQL(Firestore)を使うようになったのは、呼び出し方や使い方がRDBMSっぽいのと、まともな日本語公式マニュアルがちゃんと用意されている点である。もちろん、コントロールパネルも全て日本語表示で直感的。 DBとのデータの入出力ができるようになり、開発速度は加速度的に上昇した。 この段階で開発開始から5日程度だったが、仕事が忙しくなりあまり開発が進まなくなったのもこの頃である。

新型コロナに感染、自宅療養開始

2月中旬ごろ、喉が痛くなり微熱が出て、味覚が鈍くなった。これはもしかして…と思って病院に行ったら、案の定、感染していた。保健所から自宅療養を命じられたが、今勤めている会社はリモートワーク環境が整っている(なお、これはFortigateを使って私が整備し、緊急対応などで活用できている) しかし、実際にリモートワークが認められているわけではなく、会社に来られないなら休みとして扱われるという旧態依然とした考え方であったが、逆にこれが今回の大きなポイントとなるのである。

自宅療養期間でシステム開発ができる

自覚症状があり、体調は芳しくなかったものの、全く動けないわけではなかった。そのため、滞っていたシステム開発を大きく進める絶好のチャンスであった。 自宅療養期間は10日間、1日8時間作業ができれば80時間分の工数が消化できるわけである。ただし、療養が最優先なので調子が悪くなれば、適度に休憩をとったり仮眠したりすることも必要である。 開発においては、Firestoreでデータが入出力できるようになり、ようやくシステムの作り方のピースが揃ってきたところであった。ここからが本番である。

まずは管理者画面から

管理者画面は、ざっくり言えばそのシステムのあらゆるデータを見たり変更したり、システム設定などを変更できる画面である。管理者にも権限レベルが有るわけだが、ブログで言えば、ブログを書くことのできる人は管理者にあたる。 今回のシステムでは、管理者は一人なので、システム上の管理者権限は特別な区分けをすることなく、あとは一般のユーザーという2種類のユーザー種別を用意することとした。 管理者画面を先に作るメリットは、あらゆる必要な機能のモジュールを先に作ることができること。例えば、今回は予約システムだが、管理者はユーザーの予約を作成・変更・取り消し(削除)ができる。これを先に作っておけば、一般ユーザー側のシステムを作るときに、すでにある機能を制限的に呼び出すだけで良いということになる。UIにも依るが、まとめて機能を作るメリットは、作業が効率的になるだけでなく、構想が頭の中にあるうちに機能を形にできることで、変な不具合を生みにくいというのもある。 まずは、ユーザー情報として最低限必要な要素(ユーザーIDや名前など)と予約に必要な要素(予約IDや予約日時など)をDBに仮登録し、それらを読み出して表示するところから取り組んだ

実質50時間

最初の2日間と最後の1日は療養・調整期間として費やしたので作業ができたのは7日間である。1日8時間弱、作業をすることとした。 その7日間のうちで、管理者画面の殆どが出来上がった。プログラマーとは言え、知識0から初めて短期間で形になるというのは、最近の開発手法やフレームワークがいかに優れているかというのがわかる。 1~4日目で、ユーザー登録・ログイン/ログアウト・予約管理が出来上がった。 5~7日目で、ユーザー管理・予約メニュー設定・システム設定などが出来上がった。 残すところは、エンドユーザー側のシステムと画面の作成である。

残り2日

3月スタートにむけて進めていたが、残り2日となってしまった。 本来であれば、リスケジュールの相談を行いたいところだが、ここまでいろんなことに協力してもらっているため、なんとか最低限運用できる状態に仕上げて、後々要望に合わせたアップデートをするという体制を取りたい。 それについて、念のため相談したところ、問題ないとのことだったので、エンドユーザー側の画面を取り急ぎ作成し、Githubにコミット、そこから新しいプロジェクトをクローンしてfirebaseにパブリッシュした。

無事に3月からサービス開始

最後の仕上げでかなりバタバタはしたが、Firebaseの優れたサービスで問題なくサービスを開始することができた。実際にサービスを開始するにあたって、DBの初期値を入れるためのバッチを作ることを省いたりするなど、ある程度手作業になってしまったことが課題として残るが、ひとまず運用段階に入り、運用権限を譲渡することができた。足りない機能などは随時対応を進めている。

振り返ってみて

従来ではWebアプリケーションを作るとなると、サバクラ方式が殆どでアプリケーション側とサーバー側のソースを書かなければならなかった。そしてそれにあったデザインを制作し、作り込んでいくというのが定番だったが、最近ではサーバーレスという考え方が増えてきて、さらにUIフレームワークも充実しているので、アプリケーションの開発に専念できる。たとえるならば、WPFC#)とSQLServerでアプリケーションを作っているような感覚である。 自分の計画性のなさと見通しの甘さが露呈し、まるで夏休み終盤の学生が宿題に追われているような状態だった。エンジニアをやっているとあるあるなのかもしれないが、実際に尻に火がつかないと本来のパフォーマンスが発揮できないのは不便に思う。コツコツと計画的にできる人が羨ましい。

これから

まずは引き続き要望に答え続けていこうと思う。その後、そのサービスから汎用的に使えそうな部分をブラッシュアップし、いつかは一般開放ができるようになりたい。こういった一つ一つの積み重ねが自分のスキルになっていくのだと改めて実感できた。

天気の様々な情報を視覚的にみたいならWindyでいろいろと遊べる

最近、すごく情報量の多い天気予報サイトを見つけた。

Windyというサイトで、世界中に提供するチェコの企業が運営している。 例えば大阪市の天気予報を見るならこちら。 www.windy.com

画面には様々な情報がのっているが、上から直感的によく使うものが並んでいる。 f:id:kumainu-dev:20220204171313p:plain

通常であれば、時間帯の天気、気温、そして降水量である。 このサイトの一番のメリットは、リアルタイムの様々な情報が見られることではなく、雨・雪や風や気温の予報を地図上で把握することができることである。

f:id:kumainu-dev:20220204171954p:plain 天気予報を表示した状態で、時刻のスライダーを動かすと、天気以外に降水量や風、気温などの予測が表示される。これは特にバイク乗りにはありがたいのである。バイクでツーリングに行くときのルート取りを考えてみよう。楽しいワインディングをしたり絶景ロードを走りたいのはもちろんだが、雨が降るルートも避けたい。全国的に晴れる日でも、地域によってはにわか雨が降ったりする。一般的な天気予報では、地点を指定して予報を見るが、この天気予報では地図上で時間帯別の雨予報などが見れるため、ルート上の天気を予測しやすいのである。さらに、付近のライブカメラ情報にもアクセスできるため、路面の状況などより詳細に情報収集をすることも可能だ。

バイク乗りじゃなくても、ただ単に明日寒いのかなーと自分の通勤経路の気温の推移を見たり、星空が見たい人は、指定した時間にどの当たりが雲が少ないかなどを見ることができる。釣りをする人は風を見ればよい。 もちろん、タイトルの通りただ単に遊ぶのも楽しい。

IKEAのTRÅDFRI トロードフリ ゲートウェイキットを使ってみた

以前、自宅にPhilipsのHueを導入した話をした。

kumainu-dev.hatenablog.com

この後、HueBridgeを買い足して無事に使うことができた。 そのまとめの話は今度また書こうと思う。

今回は、私の自宅ではなく、相方の自宅をスマートライトにしようということで、以前から気になっていたIKEAのトロードフリを試すこととした。

きっかけ

自分の部屋をHueライトにしてから、部屋の間接照明に凝るようになり、安価なLEDテープライトが欲しくなった。 少し前に、IKEAの近くをたまたま通ったとき、IKEAにもIoT対応のLEDテープライトが売っていることを思い出し、立ち寄ることにした。 結果的に、あまり安価に導入できないことがわかって一旦諦めたのだが、そのときにトロードフリのセットが安価に売られているのを見つけた。

www.ikea.com

E26電球が1本、E17電球が2本、ゲートウェイとリモコンがセットになって通常販売価格が9,490円。 このセットはもう販売終了品らしく、売り切りのセールで40%OFFになり、5,694円で売られていたのだ。 相方も、私が自宅のライトをスマートライト化して、自分の部屋もしてみたいと少し興味があったようで、このセールが背中を押す形となり、購入を決定した。

設置~セットアップ

私の部屋をスマートライトにする際、シーリングライトを半透明のグレーにしたことにより、10畳間には合わず部屋全体が暗くなってしまったので、IKEAで999円というかなり安いシーリングライトを購入した。 それで、以前購入したグレーのシーリングライトを相方にあげて、そのシーリングライトにE26を取りつけ、テレビ裏に使うE17のライトは家にあった適当なものを使うようにした。 リモコンとのペアリングは、ニトリのネクト、PhilipsのHueのどちらとも違うやり方だった。

ニトリのネクトではリモコンが無いため、スマートフォンと直接ペアリングすることとなる。ペアリングモードは、主電源を3回ON/OFFすることによりライトが点滅し、ペアリング待受状態になる。このトロードフリも、リモコンとペアリングする際には3回ON/OFFを繰り返す必要がある。この点Hueは何もしなくてもペアリングできたのが素晴らしい。 次に、ペアリングの手順だが、Hueの場合は一旦すべてのライトとリモコンを同期して、最後にリモコンをブリッジとペアリングすることで自動的にすべてのライトがブリッジに登録されたが、このトロードフリに関しては逆で、一旦ブリッジとリモコンをペアリングした後に、リモコンと電球をペアリングすることで、ブリッジ側に登録されていくという仕組みのようだ。 いちいち裏のボタンを押したりしなければならなく、非常に面倒だと感じた。

Alexaとの互換性はいまいち

相方の家にはEcho Show5があり(自分が買ったけど相方に取られた)、トロードフリはもちろんAlexaに対応している。Alexa側に電球を登録するまでは問題なくできたのだが、Alexaの定型アクションから操作しようとすると、うまく行かないことが多い。 具体的には、色温度が変わらない、輝度が変わらない、OFFにできないなどである。ほぼ全てじゃないかと思うかもしれないが、ある点にさえ気をつければ問題なく動く場合が多いのである。それはズバリ「色温度を変えないこと」である。何のためにグラデーションカラーの電球を使っているのかとツッコミが出てしまうかもしれないが、実際問題、定型アクションで色温度の変更をアクションに加えて、輝度の調整やON/OFFがうまく動いた試しが無いのである。その店、色温度さえ変更しなければ、輝度もON/OFFも正しく動く。IKEAスキルのレビューを見たところ、どうもこの問題は私以外にも起こっているようだ。もしかしたらFWのバグや電波干渉があるのかもしれない。 また、シーンを登録してもそのシーンをAlexaから呼び出すことができないのも残念な点である。これらの問題はアップデートにより解決されることを期待したい。

色温度が低めでリモコンでの階調が少ない

Hueやネクトに比べて、白色の色域がいささか低く感じる。スマホでの表示色は白なのに黄色がかっている。スマホからならまだマシだが、リモコンから暖色系にしようと思っても黄色やオレンジなど、低すぎる色を温度が選ばれる。どの電球でも同じ色なので個体差ではないのだろうが、リモコン操作で色温度を変えると、4段階でしか色が変わらないのは盲点であった。まぁ、シーンで登録するから大した問題にはならないのだが、昼白色まで白くならないのは少し残念だった。

スイッチの使い勝手が残念

トロードフリの最大のメリットは安価でリモコン付きになることなのだが、このリモコンの動きが曲者なのである。3つの電球があるとしよう。普段は全点灯で寝るときには1つの電球だけ薄暗く照らし、もう2つの電球を消灯するとしよう。 そのまま就寝し、朝起きたらカーテンを開けて、電気を消したい。このとき、リモコンの電源ボタンを押したときに期待される動きは、次のうちのどちらかである。「全照明がOFFになる」もしくは「全照明がON」になる。

f:id:kumainu-dev:20220204121620p:plainf:id:kumainu-dev:20220204121625p:plain
左:全部消える 右:全部点く

前者なら1回押せばいい、後者なら一度全部つくが、もう一度押して全部消せばいい。普通はそうなると想像する。

しかしこのトロードフリはそのどちらでもない挙動をする、具体的には「OFFの電球はONにし、ONの電球はOFFにする」という動きだ。つまり、先程の就寝時のシーンから言うと、薄暗くついていた電球はOFFになり、消していた2つの電球はONになるのだ。

f:id:kumainu-dev:20220204121440p:plain
ON/OFFの状態が入れ替わるというパターン

おそらく、電源ボタンを押したら、各電球の電源状態のビットが反転するような仕組みになっているのだろう。つまり電源ボタンは、一括で電源をON/OFFさせるのではなく、一括で個々の電球のON/OFFの状態を切り替えるのである。果たしてこの動き、誰が得をするだろうか?殆どの場合、リモコンでの操作は全点灯・全消灯への切り替えであろう。

一部の電球がついた状態で、一括操作したい場合、リモコンだけでできないことはないことがわかった。それは、一度リモコンで輝度を明るくすると、すべての電球が点灯状態になるので、その状態で電源ボタンを押せば一括でOFFにできる。 我が家ではこの問題について、Alexaを使って回避している。起床時に「アレクサ、おはよう」と話すことで、全照明を最高輝度にすることで、すべての照明をONにする。そして、出かける前に壁に設置したリモコンでOFFにすることで、帰宅時に再度ボタンを押せば明るい部屋になるという寸法だ。 ちなみに「アレクサ、行ってきます」もやってみたのだが、どうやら「電源OFF」と「輝度100%」は同時にできないらしく、一旦「電源ON・輝度100%」のあとウェイトタイムを設けて「電源OFF」にする必要があるようだ。しかし不具合などでちゃんと動かなければ電気つけっぱなしになってしまう。毎朝これがちゃんと動くかみはらなければならないことを考えたら、現実的ではないとして「アレクサおはよう」にすることにしたのだ。

アプリの作りがいまいち

アプリの作り自体は、ニトリのネクトに近い。電球の各種パラメーターはスライダーを操作中リアルアリムに変更されるわけではなく、スライダーを離して値を確定した後に反映される。つまり、色温度や輝度を調整するときにスライダーを操作する際、いちいち指を離さないと反映されないのである。ホテルなどにある明るさ調整ができる照明を想像してほしい。あれはノブを回すとリアルタイムに明るさが変化する。だから調整がしやすいのである。もしあのノブが、手を離してから反映される仕組みだったらどうだろうか、とても調整がしづらいのが容易に想像できるであろう。ニトリのネクトも似たような問題を抱えていたので、その点リアルタイムに反映されるHueはよくできていると思う。

更に文句を言えば、アプリ内のシーンを作るとき、各電球の輝度や色温度を決めるときに、いちいちプレビューボタンを押さなければ状態がわからないのもクソである。プレビューボタンを押すために数回ボタンを押さなければならないのもクソである。せめて、設定している画面内にプレビューボタンがほしい。

ブリッジと電球感の接続が不安定

割と致命的な内容として、時折ブリッジと電球の通信が切れることがある。その場合主電源をつけ直す必要があり、シーリングはまだ壁スイッチがあるからいいものの、間接照明はケーブルを隠すために、コンセントやスイッチにアクセスするのが面倒なのである。主電源を入れ直したら接続が復活するが、悪いときはブリッジ自体にアクセスできなくなるケースもあった。その場合はブリッジの電源ケーブルを一度抜いて再度差し込むことで解決するのだが、こちらもケーブルを隠しているため、裏蓋を開ける苦労などがある。原因がわからないが、集合住宅なので電波干渉などを受け続けると不安定になるのかもしれない。

これから買う人はHueを選ぼう

ニトリのネクトもIKEAのトロードフリも、製品のクオリティとしては似たようなもので、どちらも固有の問題を抱えている。 電球単体の性能として考えれば、ニトリのほうが豊かな階調なのだが、リモコンが使えない。トロードフリを選べば、リモコンを使えるが、動作が不安定である。 たくさん電球を買ったとき、他と比較すれば確かにHueは高いかもしれない。余計な機能がついているようにも思えるかもしれない。しかし、せっかく便利にするためにスマートライトを導入にしたのに、不具合や使いにくい仕様で苦労しているようでは本末転倒である。もしこれを見ている人が、これからスマートライトを導入したいと考えているならば、PhilipsのHueをおすすめしたい。

Philips Hueを導入してみた!…がAlexaが機器を検出できなかった話

これまでの経緯

以前の記事で、ニトリの電球を買ってスイッチが(容易に)使えない未来になり、絶望した話をした。

kumainu-dev.hatenablog.com

そして、PhilipsHueに買い換える機会に恵まれ(無理やり作った)、購入した。

kumainu-dev.hatenablog.com

Hueとニトリとの電球の比較

ニトリのスマート電球とPhilips HueのE26電球(60Wモデル)を比較すると、数字上の明るさは、ニトリのほうが高い。Hueは800mlでニトリは810lm。しかし、実際に設置して照明をつけてみると、Hueのほうが広範囲に照らしてくれるので、体感としてHueのほうが明るく見える。そして、どちらの製品もホワイトグラデーションで暖色~寒色に調整可能だが、オレンジ色に関してはHueのほうが明らかに発色が強く、はっきりした色が出ている。明るさのダイナミックレンジもHueが圧倒的に広く、Hueは最小にすれば点灯しているのかどうか、わからないぐらいまで暗くなる。

Dimmerスイッチは便利でレスポンス最高

Dimmerスイッチと電球間は、Zigbeeプロトコルで通信しているため、低電力でかつレスポンスが高速だ。これはスイッチを押した時の応答速度に顕著に現れる。ボタンを押してほとんどラグがないのが素晴らしい。また、ペアリングに関しても電球を点灯させた状態でスイッチを近づけ、電源ボタンを3秒長押しすればペアリングが完了する。スイッチは土台とリモコン部分が磁石でくっついているので、土台を壁に設置後でもリモコンを持ち出せるという素晴らしい設計となっている。

Hue BTアプリから操作可能

Hue製品とBluetoothで接続してコントロールする用のHue BTアプリを使ってスマホとペアリングすることで、スマホからも電球をコントロールできるようになる。また、わかりやすい名前をつけることも可能だ。さらに、カラーホイールを使って電球の色を設定したり、全体・個別に輝度調整することもできる。シーンという機能を使うと、各電球の設定値を覚えさせることができ、テンプレート的に呼び出すことができるようになるのだ。例えば、映画を見るときには、部屋全体を暖色系にし、シーリングをOFF、間接照明だけをONにした状態で、「シネマ」というシーンを作っておくことで、映画を見るときにシネマのシーンを呼び出すことで、いつでもその状態にすることができる。また、Alexaとの連携部分では、このアプリに登録している端末情報をAlexaに送信することでペアリングができるらしく、かつシーンの呼び出しも音声コマンドでできるという至れり尽くせりな設計となっている

我が家のAlexaはYAMAHA

Alexa Built-in Devicesという規格があり、これはいわゆる、サードパーティ製のスマートスピーカーなどで、Alexaを呼び出すことができるようになっている。ざっくばらんに言えば、スマートスピーカーAmazon認定機器のようなものである。Alexa Built-in Devicesの製品でAlexaを使うことができるので、我が家では、ダイキンのエアコンやSwitchBotを使って、テレビなどのコントロールが行えている。今回、PhilipsのHueはハブがなくてもAlexaが使える環境であれば音声コントロールができると言う情報を得たので、導入を決意したのだ。

スマートホームハブの仕組み

スマートホームハブがどのような動作をするか、ざっくりと説明すると、ECHO端末はスマート電球などのBluetooth対応のスマートデバイスと直接ペアリングを行う。Alexaの音声コマンドをやり取りしているのははHTTP通信なので、スマート電球をペアリングしたECHO端末で、HTTPコマンドを受信し、接続している電球に対してコマンドをリレーするような構造になっている。また、Bluetoothは双方向で通信を行うため、電球の状態(点灯状態、輝度、色温度など)を接続しているECHO端末経由で受け取ることができるので、複数のAlexaが使える端末の何れからでもコマンドを送信することができるのである。この仕組みを、スマートホームハブやブリッジ、ゲートウェイなどと言うのである。

直接続できるのは一部を除くECHO端末のみ

結果的に言えば、我が家のヤマハスマートスピーカーでは、HueのBluetoothとペアリングができなかった。原因はおそらく、ECHO端末に搭載されているBluetooth方式の「スマートホームハブ機能」が、私の使っているAlexa端末には搭載されていないのであろう。

冷静に考えてみればそうかもしれない。公式のヘルプを良く見てみると、互換性のあるECHO端末と書いてあるので、すべてのAlexa搭載端末で使えるとはどこにも書いていないのである。もっと言えば、YAS-109にはECHOの機能はなく、ただ単にAlexaのコマンドをやり取りしているだけで、ある種のターミナル(端末)に過ぎないのである。 しかし、これは私にとって大きな痛手である。実家にいる時のルーチンとしては、寝る前に「アレクサ、おやすみ」と言って部屋の照明を落としたり、お出かけ前に「アレクサ、行ってきます」と部屋の電気やエアコンを消したりしているのだが、その定型アクションの中に照明を組み込めないということになる。お出かけ時は壁スイッチを操作すればいいが、寝るときはわざわざスマホを取り出さなければならず、大変面倒なのである。

1日だけスマホとDimmerスイッチで運用してみたが…

寝る前にはスマホからシーンを呼び出して暗くした。そして、朝起きて「明るい」シーンを呼び出して、最も明るい状態にし、準備をしてDimmerスイッチで照明をOFFにし、でかけた。導入直後なので、まだ新鮮だから面倒ではないが、寝るときにアレクサに頼めないのは少しがっかりだ。寝る前はできるだけスマホを見ないようにしているため、このためだけにスマホを見るのはもったいない。そして、朝起きてわざわざ「明るい」のシーンを呼び出すには理由がある。

Dimmerスイッチで照明の電源をONにした場合、最後の電球の設定状態が呼び出されるため、「就寝」のシーンで電源をOFFにすると、次にDimmerスイッチでONにしたとき、就寝のシーンの状態になってしまうのである。これでは、私が不在の状態で家族が部屋に来たとき、スイッチを押しても暗くて困ってしまうのである。それを防止するため、「明るい」を呼び出してからOFFにする工夫が必要になる。 こちらも、Alexaならば、照明の状態を最も明るい状態にしてからOFFにするということができるので、今まで運用してきた「行ってきます」が使えないのは痛手なのである。

結局Hueブリッジの検討が必要

Hue電球なら2~3個、IKEA電球3~4個買えるほどの値段のため、ブリッジの導入をしなくていい方式を選んだのにも関わらず、結局ブリッジが必要になってしまう事態となった。ブリッジならば、スキルをインストールすることで、Alexa→ブリッジをHTTP通信、ブリッジ→電球をZigbee通信でできることになり、ウチの環境にも適した状態になる。悔しいがそれを検討するしかなさそうだ。

フリーランスとして初めてのお仕事

知り合いから、個人事業(教室系)を始めたいのでホームページを作りたいという話が挙がった。 これはフリーランスになるために実績を積む、またとないチャンス!教室の紹介ホームページならCMSでも十分作れるし、Azureのクラウドサーバーを使ってWordpress でWebサイトを構築した経験は何度もある。 それに、会社の業務でSSL証明書ドメインを新規取得・運用した経験もあるため、それらの経験も活かせば、構築して公開すること自体は問題ない。 後はSEO対策とデザインスキルだけが問題になる。こればかりは専門じゃないと難しい。

それについて依頼者に相談し、ページのデザインについては既存の同業他社のデザインを参考にアレンジし、依頼者の要望通りに作る。またロゴや素材のデザインは依頼者が別途デザイナーに依頼して準備し、デザイナーとのやり取りはこちらで行い、受け取ったの素材を用いてページを作るという流れで、依頼を受けることとなった。 また、SEO対策についてはできる範囲で実施し、広告などを行う際にはSEO業者に依頼する必要があることも了解を得た。

依頼者にそういった人脈があり、柔軟な対応をして頂けて、1発目の仕事としては、自分の経験がフル活かせる+経験を積むことができるので、これ以上無い条件で受けることができた。

構築はすべてAWSで完結させた

以前、Microsoft Azureで仮想サーバーをレンタルし、Wordpress のサイトを個人で構築・運用したことが何度かある。しかし、今回は仕事でも利用しているAWS(AmazonWebService)で構築してみようと思った。現在のWeb業界では最もよく使われるサービスであり、現在の仕事で使っているためだ。

色んな情報を仕入れた結果、以下のサービスを使ってWebサイトを構築することとなった。

AWSをつかってWebサービスを構築するにはEC2が主流だが、個人のサイトで運用費を節約したいという要望に答えて、今回はスピード開発・公開が可能なLightsailを使って構築することとした。 また、ドメインについてもAWSのサービスで購入することで、複数のサイトのサービスに登録することなく集中管理できるため、コスト管理が容易になるのである。

構築~テストまで

1つ1つ調べながら学習し、テスト用のサイトが出来上がるまでには30分もかからなかった。Wordpressを構築してしまえばあとは今までの経験でサイトが作れるのである。 必要なプラグインを入れ、ランディングページを作成し、デザインのサンプルを作る。必要な素材はフリー素材を使用したり、実際に撮影に出向いたりした。

システムの開発も依頼された

こんな機会はめったに無いのだが、さらに予約システムの開発を依頼された。一般的に予約システムとは既存のサービスを利用するものだが、使い勝手のカスタマイズ性など、かゆいところにまで手が届くサービスはまだあまり存在しない。あっても高価なのだ。 そこで、月額の利用が安価なシステムを作れないかということで話があった。開発期間は1ヶ月ほどもらえるので、これもWebシステム開発の経験を積むのにいいと思い、引き受けた。

ホームページはほぼ完成

現在、ホームページは最後の調整段階に入っており、それが完了したら公開へ向けて設定を行えば完成となる。しかし、前述のシステム開発が完了しないと、本当の完成とはいえない。EC2サーバーとCloud9環境を構築し、Node.jsとVue(Vuetify)、Firebaseを使って学習中だ。やり方さえ分かれば開発は難しくない。

ともかく完成させる

形にならない限り、意見をもらうことはできない。1ヶ月でのシステム開発は、物にもよるが習熟した開発環境でないと難しいと考えている。しかし、せっかくもらえたチャンスをしっかりものにしたいと考えている。

鎮静剤を用いた経口胃カメラを経験したがトラウマになった話

先日、人生二度目の胃カメラを経験し、鎮静剤を用いた経口胃カメラであったのにも関わらず二度と受けたくないと感じた。いわゆるトラウマになってしまった話をしようと思う。

きっかけ

食事の前後に胃が胸焼けをおこし、肋骨あたりに違和感が発生することが2年ほど続き、去年末頃から特にひどくなってきたので、12月の下旬に大きめの病院へ行った。その病院には別の病気で去年末に入院しており、その時肝臓の造影剤CTを撮影した履歴が残っていたので、その時のデータと照らし合わせながら診察をしてもらった。

当日は血液検査と尿検査を行ったのだが、どうも肝臓の数値(特にALT/AST)が悪く、このまま放置すると将来、慢性肝炎になるリスクが非常に高いとのことだった。原因は重度の脂肪肝のため、この日から糖質制限のダイエットを行う事となったのだが、これは腹痛とは直接関係がなさそうだとのこと。

原因は胃腸?

診察の結果、主な原因は肥満のために腹圧が上がり、胃腸が圧迫されて痛みが発生している可能性があるとのことだった。胸焼けに関しては、私は逆流性食道炎持ちなので、それが悪化してきている可能性が高い。しかし、もし痛みとの関係も捨てきれず、胃腸に何らかの別の異常がある可能性も高いので、胃カメラをやることになった。大きな病院のため、その場でやってもらうことはできない。予約をとって実施する形となり、その検査が先日だったわけだ。

胃カメラは経験したことがある

胃カメラは今から6年ほど前に経験している。その時は経鼻胃カメラと言って、口ではなく鼻からカメラを通す、比較的 嘔吐反射(※)が少なく、患者の負担が少ないやり方で実施された。しかし、前述の通り嘔吐反射がまったくないわけではなく、あくまで「口からに比べたら鼻は幾分か楽である」と言った程度で、何度も反射が起こり苦しい思いをした(粘膜が擦れて鼻血も出た)

※嘔吐反射とは、いわゆる「えずき」のことで、喉の奥に異物を感じると吐き気をもよおすことを言う

今回は鎮静剤を試してみたい

経鼻胃カメラよりも、鎮静剤を用いた経口胃カメラのほうが楽だというネットの情報を見つけた。詳しく調べてみると鎮静剤を使うと次のようなメリットがあるとのこと

胃カメラで嘔吐反射が発生するのは、喉の奥にカメラのケーブルが当たってしまうためである

リラックスしているときに比べ、緊張状態になると喉の奥が狭くなってしまい余計に反射を促進してしまう

鎮静剤を使うことで、意識が朦朧としている状態で実施するため、リラックスしている状態を作ることができる

人によっては眠ってしまうこともあり、その場合は気がついたら終わっていたということもある

経鼻胃カメラで痛い目にあった私としては、かなりの朗報である。もちろん鎮静剤に依る生命への危険性が0ではないため、同意書への記入が必要だったり、検査後丸一日は乗り物の運転が一切禁止だったりなど、制約はあるが、相方が付き添いできてくれるとのことだったので、迷いなく実施することとした。

当日(リラックス~喉の麻酔)

検査当日は、受付を済ませリカバリルームと言う場所に案内された。歯医者の椅子とエステサロンの椅子を足して2で割ったような「無骨なリクライニングチェア」が設置されており、そこに座らされた。座り心地は歯医者の椅子よりも少し柔らかい程度で、足を伸ばせる。明るい室内にはオルゴールBGMが流れており、異様な雰囲気が余計に不安を煽る。

間もなく看護師がやってきて血圧計測やら検温やらを行った。血圧は正常値(110/80)で問題なかったので、引き続き説明を受ける。

「これから麻酔入りの氷をお召し上がりいただきます。お味は、りんごとコーヒーがございます。どちらをご用意いたしましょうか。」

えらく丁寧な説明で、ファミレスかなにかかと思ったが、麻酔入りの氷とはとんでもないパワーワードである。これからあなたを襲いますが、甘いのか苦いのかどちらがいいですか?と言われているようなものだが、ついつい「おすすめはどちらですか」と聞いてしまい、失笑をかってしまった。しかし「りんご」か「コーヒー」とは、かなり極端に差があるものだ。うーむ、これはどちらがいいだろうか。私の経験上、食品のフレーバーとしてコーヒーが美味しかったのは雪印のコーヒー(牛乳)か、チロルチョコのコーヒーヌガーぐらいでありそれ以外のコーヒーフレーバーではあまりいい味だと思ったことが無い。りんごであれば、ジュースでもグミでもある程度おいしい。むしろまずく作るほうが難しいであろう。

ということで、りんごを選んだ。

すぐに注文の「麻酔薬入り りんごアイス」が届いた。まず、氷は無色透明でなぜか「ハート型」なのである。それはいいとしても、チロルチョコよりもやや大きく、しかも噛んではだめで、なめて溶かす必要があるとのこと。私は普段、氷を口に含まないのでこれがとてもつらかった。

そして肝心の味だが、これがものすごくまずい。本当にクソ不味い。りんごの風味や味が薄いのは仕方ないとして、麻酔薬の味なのか、ものすごく苦いのだ。これは地雷を引いてしまったのかもしれない。もしかしたらコーヒー味ならこの苦味が良いスパイスになったのではないだろうか。ともかく、なめていくうちに麻酔が効いてきて、少しずつ小さくなっていった。10分ほど苦痛に耐えながら完食した。

当日(移動~予診)

リカバリルームの隣の部屋にある部屋に案内され、何やら手術室みたいな場所に連れて行かれた。そこで仰向けに寝かされて、腕に血圧計やパルスオキシメーター(血中酸素濃度を測る装置)などが取り付けられた。その時の血圧が150ぐらいまで上がったそうで「緊張されていますね」と看護師。そりゃそうだ。以前に経鼻胃カメラで痛い目にあってトラウマになっているのに、こんな仰々しい場所に連れてこられて「はいこれから口にケーブル突っ込んで胃の中見ますね」って言われたら緊張しても仕方ないであろう。 程なくして、胃カメラ担当医がやってきて、寝たままで予診(最後の確認)が行われた。鼻からの胃カメラでも苦痛があったので、可能であれば楽に受けたい旨を伝えると「朝、歯磨きで嘔吐反射起きる?」と聞かれたので、「はい、毎回起きますし、何度か嘔吐したこともあります」と返すと「あーそれなら確実にカメラ辛いわ」と笑いながら脅かされながら、局所麻酔のスプレーを何度も追加で足してもらった。

当日(検査開始)

追加の麻酔スプレーのおかげで口と喉の中がわけわからない状態になったところで、ドクターが「さぁ始めよう」と一声。アシスタントや看護師が一斉に「はい」と返事し、一気に現場の空気がピリッとしたのが伝わり、私の緊張はピークに達した。既に注射針は腕に刺さっており、「鎮静剤入れます」という声が聞こえが2~3秒後、突然見えている景色のピントが合わなくなり、聞こえてくる音が小さくなった。これがドラマや映画で鎮静剤や麻薬を打たれたときの演出に似ており、少し感動した。その状態で横向きに動かされた。ここで気づいたのだが、意識は少し朦朧としているのにも関わらず、肌に触れる感覚や痛覚に関してはかなり鮮明である。嫌な予感がしてきたのだ。

当日(検査中)

口にホースが通る用のマウスピースのようなものが取り付けれた。唇に指が触れる感覚など、かなり鮮明だ。もう嫌な予感しかしない。検査開始前に「死んだ魚のように口をぽかんと開けておいてください」と言われたので、だらんとして口を開けていた。いよいよケーブルの挿入だ。舌にケーブルが何度か接触し、入ってくるのがわかる。

すると!きた、反射だ!

もはや、鎮静剤を使わなくても同じなのではないかと思うほど、何度も嘔吐反射が起こり、ついに手が動いてしまったので、医者がケーブルを抜いた。これではだめだ、看護師(たぶん)が背中を擦ってくれてもう一度挑戦。すると今度はいくらか反射がマシになった。ここからは記憶が曖昧で何も聞こえなかったのだが、胃の中と十二指腸内を一通り見たようだ。はい、ケーブル抜けましたよという声を唯一覚えており、もこもこのタオルを添えていたにも関わらず、自分の肩が唾液でビシャビシャになっており、その感覚だけは鮮明に覚えていた。

当日(検査後)

ドクターは「胃はきれいでピロリ菌もいない、食道炎は重度だが、潰瘍はなく健康な胃だった」という言葉をかけられた。私は感謝の言葉を言った(はず)、その後車椅子に乗せられて別の部屋に移動させられた。そこから約1時間安静にと、ベッドで横になり、相方に車を運転してもらって家に帰った。

鎮静剤を使った胃カメラの感想

「二度としたくない」という言葉に尽きる。鎮静剤の効果は人によるだろうし、病院の方針で半覚醒にさせるか眠らせるかは違うであろう。しかし、いくら意識が朦朧としていても、嘔吐反射は辛く、思い出すだけで気持ち悪くなるいわゆる「トラウマ」になってしまった。 これなら鼻からのほうがいくらかマシなので、万が一、次に胃カメラを受けなければならない状況に陥ったならば、鼻から受けたい。いっそのこと意識をなくしてくれると私にとっては一番ラクなのだが、、、、

これから胃カメラを受ける方へ

鎮静剤の種類や体質にも夜が、一説には「お酒に強い人は眠くなりにくい」ということらしい。しかしこれはあくまで一説であり、確実な情報ではない。これから受けられる方が、自分が鼻からか鎮静剤を使った口からか、どちらが一番楽なのかについては一度ドクターや看護師に相談してみてはいかがだろうか。胃カメラはいかにリラックス状態でうけるかというのが負担のない検査で最も大事らしいので、つらい思いをすることの一番のデメリットは「トラウマになってしまったらリラックスすることが難しくなる」ということである。 是非一度、どのやり方が自分に適しているか、病院に相談してみてはいかがだろうか。

新型Philips Hueについて調べてみた

昨日ニトリでスマート電球を買ったら痛い目にあったというような記事を投稿した。

kumainu-dev.hatenablog.com

 

どうしても壁スイッチが諦められないので、新しいバージョンのHueについて調べてみた。すると次のようなことがわかった。

 

新型のHueでできること

  • 新型のHueはZigbeeに加えてBluetoothが搭載
  • 電球のラインナップにホワイトグラデーションが追加
  • 新型のDimmerスイッチはZigbeeに加えてBluetoothが搭載
  • Bluetooth搭載モデルのHueはブリッジがなくても次のことができる
    • 専用アプリからスマホでコントロール可能(個別・一括)
    • Echo端末があればAlexaに登録してコントロール可能
    • Bluetooth対応のDimmerスイッチから一括操作可能(ON/OFF・照度・4パターンのシーン)

うーむ、Hueブリッジがなくてもアプリから操作できるようになったのは知っていたが、新型のDimmerスイッチならBluetooth対応のHueを一括操作できるのはかなりでかい。しかもAlexaに登録すれば、通り音声コントロールも使えるということは、定形アクションも作れるということだ。

 

買い換えるかどうか迷う

では、実際に購入するといくらになるのだろうか。ここで試算をしてみる。

合計すると11,312円となる。

電球一個あたりでは約2,933円、先日ニトリで購入した電球は2,392円だったので、ニトリのほうが541円安くなる。3個の場合その差は1,623円となる。

 

今思うと実に悔しい。ひとつあたりたった541円+2500円程度の追加を払うことでスイッチが付けられることを知っていれば、確実にHueを選んでいたと後悔する。

人生の中で「知識のアップデート」がいかに重要かということを強く感じた。

※価格はいずれも2022/1/13時点

 

しかし、ニトリで既に買ってしまったので、ここで買い換えるとなるとニトリで買った分が使わなくなってしまう。確かにリモコンがあると便利(というかほぼ必須)だが、まぁ我慢ができない性質のものなので買い替えを躊躇していた。

 

Amazonの商売上手にやられた

今まで「アレが欲しいな」というタイミングでAmazonからその商品の商品リンクがついた販促メールが届いたり、Amazonにアクセスしたら今必要なものが何故かトップに表示されるなど、ターゲッティング技術・トラッキング技術の進歩のおかげで大変便利に使っている。

一応、腐ってもソフトウェアエンジニアなので、霊的あるいは非科学的なことや迷信、都市伝説などの類を真顔で言うのは憚れる。

しかし声を大にして言いたい。

Amazon.co.jpを開いているブラウザの向こうには

  性根の腐った腹黒い妖精が住んでいる

               (kumainu)

 

というのも、値段を調べているときにPhilipsの公式サイトから新型HueのAmazon商品ページを開いたら

このタイミングでまさかの15%OFFクーポン配布!

 

計算してみると 8,800円7,480円 となり

一個あたりでは、2,493円となる

 

さっそく購入

私はきっと自分が思っているよりも遥かに多くAmazonに搾取されており、実に「良いカモ」なのだと思う。しかしそれは互いに得をしていることになるのでWin-Winではないかとポジティブな思考で乗り切ることにしている。

(そしてこの一件で一番笑っているのはニトリである)

 

買ったものは次の2つ

電球は15%OFFクーポンが適用されたので7,480円。スイッチは2,531円だったので、締めて10,011円となる。

先日購入したニトリのスマート電球は、また別の機会・場所で活用することとした。

商品は今日届くのだが、取り付けるのは実家で帰るのは少し先になる。

 

他のHue製品にも興味あり

フルカラーの電球やライトリボン(テープ式)、バーライトなどいろんなプロダクトがあるので、必要に応じて追加していきたい。特にライトリボンは2mと長いため、1.5mや1mのモデルが出たら購入を検討しようと思う。

 

最後に

スマート電球を使うことで、生活レベルが一気に上昇する。俗に言うカウチポテト族ならば絶対に手に入れたい製品だ。もちろんカウチポテト族ではない人たちも、その便利さは一度使うと手放せなくなる。

新技術に触れてみようという気軽な気持ちでAlexa対応のスマートスピーカーを購入しうたのが始まりだったが、ついに部屋のライティングにまで手を出してしまった。

しかし、Webエンジニアの世界もIoTの世界も知識が最も重要で、以下に知識のアップデートを頻繁に行えるかというのが生きていく上で大事なのかと思い知らされた。

 

この記事を見た人も、購入前にもう一度、その商品に対する知識が最新かどうか、改めて確認されたい。

そして、スマート電球に興味を持った方は、以下のリンクから確認できるので一度ご覧あれ。