今一度、事故を振り返る
はじめに
久しぶりの更新＆駄文です。
この記事は、大都会岡山 Advent Calendar 2020の20日目になります。
adventar.org
生まれて28年と少し、バイクに乗るようになってからは8年ほど経過しました。
ウインカー搭載してなくても車検通る大都会岡山ですが、僕は30m手前からちゃんと出す程度には一般優良ライダーです。
そんな僕ですが、バイクでの事故経験は何度かあります。
最近、久しぶりに事故をしてしまったので、ここいらでこれまでの事故を振り返っとくかなーと思い、記事にしてみました。
最初の事故: 後ろから掘られる
- 場所: 福山市大門町のとある交差点
- 相手: 軽四(若い女性2人)
- 状況: 停止線で止まってたら後ろからドカン(60km/h)
- 被害: 廃車(グランドマジェスティ250)、足首を擦った
- 責任: 相手10 ぼく0
大学2年生の終わり頃、バイク乗り始めて3,4ヶ月くらいの頃だったと思います。
当時、中型免許はとったものの、まだ本体を買うほどに貯金が溜まっておらず、父親のビグスク(グランドマジェスティ250)を借りてちょこちょこ走ってました。
で、いつも通り福山方面遊びに行くかー、とビグスク借りて2号線を西に。
途中、先の交差点の信号が黄色→赤に変わるのが見えたので、減速して停止。
その直後でした。
―青い空が、見えたんです。
後ろからノーブレーキで追突された僕は、ビグスクに跨った(と言うより座った)姿勢のまま仰向けに投げ出され、2,3m飛んで交差点手前に落ちてました。
追突の衝撃はグランドマジェスティのニーハンとは思えない重厚な車体がほとんど吸収してくれたので、僕は足首らへんを少し擦ったくらいでした。
相手も逃げるような人ではなかったので、警察呼んで粛々と事後処理も完了。補償は全額相手になりました。
ただ、父親のビグスクはフレーム歪んで廃車扱いで手放すことになりました。本当に父親には申し訳ないことをしました・・・。
（いつか復帰させてあげたいと思ってるのですが、その後うさぎ跳び世代の父親は足と腰にガタが来始めていて難しいかもしれません）
(在りし日のGマジェ)
こう言った事故、長年バイク乗ってるライダーさんなら経験ある方も多いようですが、大小あれど避けようがないってのは共通なんですよね。
ミラーで確認できたところで、対ショック姿勢をとるくらいが限界です。
2度目の事故: 右折に巻き込まれる
- 場所: 職場10m手前の交差点
- 相手: SUV(30前半くらいの男の人)
- 状況: 停止線で止まってたら右折に巻き込まれてドカン
- 被害: 廃車(GROM)
- 責任: 相手10 ぼく0
しばらく事故はなく、社会人になって1年ほどたった頃。
その日は生憎の雨。バイク通勤の僕は合羽着込んでいつもの道を走ってました。
で、職場10m手前。しかしこの日は駐輪場に入ることは叶いませんでした。
一旦停止で止まっていたところ、左から来た右折車がこちらを確認することなく、対向車線をえぐるように内側をグルン。
突然、前から急に迫ってきた車に反応できるはずもなく、正面から跳ね飛ばされました。
乗っていたバイク(ホンダGROM)は、フロントフェンダー、ウインカーなど、外装をあちこちやられました。
加えて、結構な速度で衝突されたので、フレームまで歪んでしまってました。
修理するくらいなら新車買ったほうがいいくらいのお金がかかりそうだったので、廃車にして、相手からの補償額+ちょい足しして新車買うことに。
また、相手の方が丁寧に応じてくれたのは幸いでした。
こういったケースの場合、「直進して突っ込んできた」と反論されてモメることが多いそうですが、そう言ったこともありませんでした。
（その後の警察の現場検証見てると、衝突位置やその後の車体の動きまで路面から読み取ってたので、どのみち真実は明らかになるでしょうが）
小型バイクに乗る方は経験あるかもしれませんが、車に気づいてもらえない場面、割と多いんですよね。雨で見通し悪いと尚更。
クラクションはさすがにですが、アクセル吹かすとかで存在アピールする場面も時には必要かなと学んだ事故でした。
3度目の事故: 自滅
- 場所: 小豆島のとあるカーブ
- 相手: 自然
- 状況: 水+砂利+落ち葉+団栗の殺意マックストラップ踏んで転倒
- 被害: 廃車(GROM2代目)、足を擦った
- 責任: ぼく10
社会人2年目の冬でした。
仕事で小豆島に行ったので、翌日有給をもらって島を一周してました。
前日までは雨が降ってましたが、当日は晴れていい感じ！
山間の道を走ってる時でした。
前方にカーブが見えたので、余裕を持って少し速度を落としとこうとブレーキ。
路面がぬかるんでいたみたいで、後輪がロックしました。
まだ、カーブまで距離あるしエンブレと軽い前ブレーキで立て直せる、と思って路面を見て絶望。
水 + 砂利 + 落ち葉 + 団栗 という、バイク絶対殺すカルテット。
あっという間に前輪を持っていかれ、カーブを曲がれず転倒。
僕は間一髪脱出、バイクは子供の頃遊んだミニカーのようになめらかに側溝に滑り落ちていきました。
通りかかった人に協力してもらって何とか引きあげましたが、まぁ外装はボロボロになりました。すり減ったハンドルバーエンドがハードラックとダンスったのを物語っています。
あ、廃車です。
これはもう、自分が速度出しすぎたのが原因です。
山間の道は前日の雨から回復してないってのは想像できたはず。それに見合った運転をしていればこんなことにはならなかったはずです。
幸いなのは、右折だったこと。左折カーブで同じような事故を起こした場合、反対車線に飛び出すので別の事故を誘発することになります。
これ以降、雨の日や翌日の運転はかなり意識するようになりました。
（余談ですが、GROM初期装備のVeeRubberのタイヤは購入後即交換推奨です。本国タイでの利用を想定して耐久力全振りで作られたタイヤなのか、ドライ路面でもグリップめちゃ弱いです。雨の日のブレーキングはヒヤヒヤします。）
4度目の事故: バックしてドーン
- 場所: 職場付近の交差点
- 相手: ※非公開
- 状況: 追い抜きしようとした車がバックしてきてドカン
- 被害: フロントフェンダー破損(GROM3代目)
最後は、つい4日前、会社からの帰路でした。
交差する道路が停滞しており、一番前の車が左折待ちしてました（僕は前から3番目）。
その後ろにいた車は直進したかったようで、前の車を追い越して行きました。
この時、僕は対向車線が見えてなかったので、(直進車は)交差点に入ってるしこのまま行くだろうと思い、少し前に詰めました。
すると、対向車が来たのか、直進車が停止、直後元の位置へバックし始めました。
そのまま下がられるとぶつかる位置。
咄嗟にとった行動は地面を蹴って僕もバックするでした。
が、車のそれとじゃ速度が全然違う上、僕の後ろにも車がいました。
そこで意識がクラクションに行き、押そうとするも空振り。
慌ててもう一回クラクションを押し、鳴ったのと同時くらいにガシャンしました・・・。
幸い、これまでの事故ほど相手車の速度が出てなかったこと、咄嗟にハンドルを左に切ってたこととで、破損はフロントフェンダーの角っこが割れたくらいでした。パーツ代にして7,8kほどで済みそうです。
今回の件に関しては、詰めた僕にも責任があるような気がします。完全に行き切るまでまって詰めるようにしてれば防げたかもしれません。
とはいえ、こう言った状況では詰めちゃいますよね・・・。
また、バイクで普段クラクションを鳴らす場面が滅多にないからか、咄嗟の場面でクラクションは押せないと言うのも学びでした。
危ないと少しでも思ったらクラクションの前に親指持ってくる練習はしといたほうがいいですね。8年目にして学びです。
最後に
「あれ、大都会岡山関係なくない？」
ご存知とは思いますが、岡山の交通治安は日本1,2と言っても過言でない位悪いです。
そんな中で、僕がこれまで経験した事故が少しでも晴れの国ライダーさん＆ドライバーさんの参考になればと思い、記事にしてみました。
・・・という建前にしておきます。
MacBookPro(Late2013)のSSD交換＆Catalinaにアップデート
はじめに
僕が普段使っているMacBookProは、Retina15インチのLate2013モデルです。
大学4年生の頃から実に6年間使っていますが、僕の扱いがよかったからかハードウェア的な不具合も特になく、今でも問題なく使えてます。
（壊れるor最新OSサポート切られたら最新に買い換えようかと思ってますが、まだしばらく大丈夫そうです）
そんな現役バリバリの7年目MacBookですが、「ストレージ不足」がちょっと気になり始めました。
写真や動画などはNASに移してますが、ParallelsやVirtualboxのVMイメージなどは流石にそういうわけにもいかず…
SDカードスロットに埋め込むタイプの外部ストレージ(中身は普通のmicroSD)を用意し、そっちにイメージを移すのも試しました。が、SSDに比べて読み書き速度がガタ落ちした影響か、VMの動作が全体的にもっさりするようになったので止めました。
そんな「ストレージ不足」を根本的に解決するため、SSDをより大容量の物に換装しました。
（ついでにMojaveからCatalinaにアップデート）
用意したもの
SSD変換アダプターは以下を購入しました。
ドライバーは、MacBookの底ケースを留めているペンタローブネジ用にP5(1.2mm)、SSDを留めているヘックスローブネジ用にT5(1.4mm)が必要です。
ヘラ状のものですが、バッテリーコネクター外す時にあると便利です。マイナスドライバーなどの導体はショートの可能性があるのでNG。僕は余ってた厚紙を三つ折りしてセロハンテープ巻いて作りました。
作業
作業前にTimeMachineでバックアップとっておきました。
もう使わないであろう純正SSDは、ディスクユーティリティ使ってフォーマット。
当然ですが、OSインストール用のメディアは用意しとく必要があります（本記事ではその辺は触れないです）。
1. 底ケースを外す
丸付けてる10箇所のネジを外します。
ヒンジ付近にある緑丸のネジ2本は、他のネジより若干短いので混ざらないよう注意です。
小さなネジなので、しっかり押し付けながら回します。ここでネジ頭を潰すと外せなくなりますからね…
ネジを全部外したら、底ケースを持ち上げて外します。
6年分の埃が詰まっていたので、エアダスターで掃除しました。
2. バッテリーコネクタを外す
安全に作業するため、バッテリーの接続を解除します。
バッテリーコネクタ上に貼られている注意書きシールを剥がし、コネクタを外します。
ヘラ状のものでこじるようにすると外しやすかったです。
外したコネクタが作業中に接触してしまわないよう、絶縁しておきます。
僕はヘラを挟み込んどきました。
3. 純正SSDを外す
SSDを留めてるネジを外します。
あとは、SSDを画像左側に引っ張りつつ、上に持ち上げれば外れます。
4. SSD変換アダプター＆M.2 SSDを装着する
変換アダプターを差し込みます。
参考にした記事だと先にアダプターを差し込んでいたのですが、パーツが小さく力を加え辛かったため、奥まで入れられませんでした。
（画像の状態は差し込みが甘いです）
僕の場合、画像の状態からM.2SSDを使ってグッと押し込んでやると、一緒に「パチン」と収まりました。
あとは、ネジ留めしてSSDを固定、バッテリーコネクタを接続し直し、底カバーを元どおりネジ留めしたら交換作業は完了です。
底カバーを取り付ける前に、ネジ溝は要確認です。僕の場合、錆のような物体が固着して残ってました（ネジ止め材かも）。ネジ山を潰す原因にもなりますので、精密ドライバーの角で取り除きました。
5. 動作確認＆OSインストール
差し込んだSSDが認識されてるか確認します。
インストール用USBから起動して、ディスクユーティリティを開きます。
無事認識されてることを確認したら、SSDをフォーマットします。
※こっから先は、クリーンインストールするときの手順と同じです。
フォーマットは「APFS」、方式は「GUIDパーティションマップ」を選択しとけばOKでしょう。
名前は、とりあえず元のSSDと同じものを引き継いどきました。
フォーマット完了したら、Catalinaをインストールし、TimeMachineから必要なものを復元して完了です。
SSD交換後
当たり前ですが、ストレージが4倍に増えました！
これだけあれば、VMをバカスカ積んでも当面は問題なさそうです。
交換ついでにCatalinaにアップデートしましたが、今のところ特に問題は起こってないですね。
（シャットダウンできないなどの不具合を聞いてましたが、幸い僕の個体では発生しなかったです）
また、ストレージへの読み書き速度が向上しました。
シーケンシャルRWの伸びがすごい…。
クリーンインストール相当の手順を踏んでCatalinaにアップデートしてることもあるので、純粋にストレージ交換のみの効果ではないでしょうけど。
アプリの起動は明らかに早くなりました。基本動作も気持ち早くなったような気がします。
おわりに
Late2013モデルを使っていて、ストレージ不足に悩まされている方は検討されても良いのでは。
1TBへのアプデならアダプター込みで費用15,000円ほど。読み書き速度アップの副次効果付きです。
あとはSidecar対応させたい…
（Late2013だと対応してないですが、無理やり対応させる方法があるらしいので試してみます）
参考
MacBook Pro 15インチ RetinaディスプレイLate 2013 SSDの交換 - iFixit リペアガイド
「テスト駆動開発(TDD)オンライン勉強会」にオンライン参加してきました。
はじめに
久しぶりの更新です。
5/4(月)、テスト駆動開発(TDD)オンライン勉強会 #1 「ライブコーディングで体感するTDD基礎」にオンライン参加してきました。
参加動機とか
今僕が携わってるプロジェクトでは、コードを追加した際はそのユニットテスト用コードも添えてPRを出す、という原則で開発が進められてます。
が、具体的な進め方まで明示されたわけではないので、その辺は各人任せな感じです。
僕自身も、コードを作り切ってからテストを書くのがメインで、その段階になってテストのしづらい(=切り出すべき)箇所に気づく…といった苦い経験をしてきました。
また、先述した原則もレビューなどで徹底されているわけではなく、期日に間に合わないなどで省略したり、メインコードを修正してもテストコードを修正し忘れたりといったことが頻発してます。
誰かが気づいても修正コストの大きさから手を出しづらく修正されないまま、徐々にユニットテストがきちんと回されなくなり・・・結果、今となってはユニットテストが形骸化している感が否めません。
僕自身も不慣れだったので、進め方の雛形をある程度決めておくべきだったなぁと反省してます。 で、次はそうしたいという思いと、「そもそもどう実装を進めるとメリットを得やすいのか」というあたりが気になっていました。
そんな中、「ライブコーディングを含むTDDのオンライン勉強会が開催される」という情報を得たので、早速申し込みました。
新型コロナは早く収束して欲しいですが、その影響でオンライン開催の勉強会が増え、大都会岡山在住の僕でも日本全国あちこちの勉強会に参加できるようになったのは嬉しいところです。
いざ勉強会
勉強会はYouTube Liveにて、松岡さん(@little_hand_s)による講義形式で行われました。
初学者でもわかりやすいFizzBuzzコードの作成を題材に、レッド・グリーン・リファクタリングの3ステップを踏みながら徐々にメインコードとテストコードを作っていく様子を実演されていました。
入力値が1の場合にテストが転ぶところ(レッド)からスタートし、
- 入力値1の時のテストが通るよう、メインコードを書く (グリーン)
- 入力値2の時のテストを書く(まだ対応するメインコードがないので転ぶ) (レッド)
- 入力値2の時のテストが通るよう、メインコードを書く (グリーン)
- 入力値3の時のテストを書く(まだ対応するメインコードがないので転ぶ) (レッド) ・・・
といった感じ。
（あくまでもTDDの進め方を掴んでもらうための刻み方なので、1ステップのサイズはケースバイケースのようです）
コードを追加後すぐに失敗がわかるので、原因箇所の特定・修正がしやすいことが実装の様子からも分かりました。
なお、レッドとグリーンの繰り返しでは、テストを通すことを目的としているので、コードが多少汚いのは気にしなくて良いようです。ある程度出来たところで行うリファクタリングでその辺は綺麗にします。
2つ目のライブコーディング(peingへ届いた質問をGitHubのissueに登録する際の本文作成プログラム)では、レッド・グリーンでは文字列連結でゴリゴリに戻り値を作成していましたが、リファクタリングでそこをテンプレート構文に直して読みやすくしていました。
設計はリファクタリングで。レッド・グリーンでは、多少汚くてもいいからテストを通るコードを優先する。 #tdd_online
— コバえもん (@koba_emon) May 4, 2020
途中のYouTube視聴者コメントで出ていましたが、TDDで進めていると仕様の考慮漏れに気づけるタイミングが多くある、というメリットもあるようですね。
TDDしてると仕様の抜け漏れを見つけやすくなる。FizzBuzzなら、「-1の時に何を返すかの仕様が定まってない」など #tdd_online
— コバえもん (@koba_emon) May 4, 2020
また、スライドでは、「自動テスト」と「TDD」の違いについても言及されてました。
以下自分メモ
- 自動テスト
- TDD
- メインコードとテストコードがセットで増えていくので、十分なテストが書かれやすい
- テストを書こうとした段階で、テストを書きにくい設計であることに気づける
- 最初からクラスの呼び出しを意識できるので、自然と高凝集・低結合なクラスを作れる
- TDDは自動テストを含むが、その逆は必須ではない（自動テストを進める手法自体はTDDでなくても良い）
- Clean(綺麗なコード)とWorks(きちんと動作するコード)は自動テストだけでも頑張ればできるが、TDDはその実現を加速させる
（こうしてみると、今携わってるプロジェクトは「自称：自動テスト」なんだなぁと。本当に反省です・・・）
参加してみて
TDDはワード程度にしか知らなかったので、進め方などの思想を知ることができたのは大きいです。ライブコーディングがあるのも理解の助けになりますね。
まずは自分担当分の開発で取り入れて行きたいと思います。手応えあれば、チーム全体としても取り入れて行きたいところです。
また、オンライン勉強会初参加でしたが、何かしながらでも話は聞けるのは良いですね。
ワイヤレスヘッドホンで聴講していたので、そのままお手洗いに行っても、軽く家事してても聞いてられます。
もし聞き逃しても、シークバーを戻せば聞きなおせます。
YouTube Liveだと、他人のコメントが参考になる、理解の助けになるというあたりもメリットです。
（TDDで有名？なサバンナの人こと和田さん(@t_wada)も参加されており、コメントが非常に参考になりました）
岡山界隈だとハッシュタグつきでTwitterにツイートする文化が強い印象ですが、それに近いものを感じました。
逆に、リアル勉強会のような「会場の空気」が形成されないので、自分が登壇者だとしたらその辺り少し不安になるかなと感じました。ボケがスベった時のダメージは抑えられるかも
今日の話を見越して実は買ってあったのじゃ
— コバえもん (@koba_emon) May 4, 2020
読むで#tdd_online pic.twitter.com/vKCIQ31b0X
「okayama-js 2020/02 Ionicもくもく会」に参加してもくもくしてきました。
はじめに
2/15(土)、okayama-js 2020/02 Ionicもくもく会に参加してきました。
モバイルアプリ開発も少し手を出してみたいと思っていた今日この頃。
「Webの技術でモバイルアプリが作れる」フレームワークであるIonicのもくもく会が開催されるとのことで、良い機会と思い参加してきました。
(マルチなプラットフォームにデプロイできるものとして最近Flutterというのも知りました。機会あればそっちも触ってみたい。)
Ionicとは
始まった！
— Tomoaki Takamoto (@shigureanko) February 15, 2020
#okajs pic.twitter.com/kNNWRBLlJs
まずは、岸野さん(@kishisuke)によるIonicの紹介からです。
岸野さんのスライドにもある通り、「Web技術でモバイルアプリ作るための統合開発環境」的なのがIonicです。
SwiftやKotlinｾﾞﾝｾﾞﾝﾜｶﾗﾅｲな私のような人でも、html・javascriptなどWebアプリ開発のノウハウを転用して開発ができます。
当日のメモも合わせて改めて自分なりにまとめると
- ボタンや各種入力要素といった豊富なUIコンポーネントが提供されている
- 開発フレームワークにはAngular/React/Vue.jsを選択可能
- ただし、Vue.jsは現時点ではベータ版。
- 元々Angular依存だったので、情報はAngularが豊富。
- URLルーティングもこれらフレームワークのものを利用可能。
- Ionic CLIでプロジェクトの雛形作成からビルド〜デプロイまで可能
- Capacitorという、Ionicチームが開発したクロスプラットフォームフレームワークが使える
- Cordovaも使えるが、公式にはこっちを推してる空気ありとのこと。
- Electronにも対応しているとのこと。つまり、デスクトップアプリ化もいける。
- PWA対応可能(テンプレートあり)
- 学習コストは高め(フレームワーク、機能の多さ、高いリリース頻度)
ちなみに、「アイオニック」と読みます。「イオニック」ではないです。
もくもくタイム
岸野さんによるイントロダクションが終わり、Let'sもくもく。
Angularでフォトギャラリー実装する公式チュートリアルがあったので、それを進めることにしました。
日頃仕事でAngularを使ってるので、コーディング自体は特に詰まる所ナシです(まぁ、チュートリアルということでコピペで進められるようになってたのですが)。解説を読みながらちまちま進めました。
Web実行時とランタイム実行時(Capacitor、Cordova)で、画像ファイルの永続化/ロード周りの操作が違うようでした(まだよく分かってませんが、ランタイム実行時はWeb実行時のようにアップロードファイルをIndexedDBにbase64エンコードして保存、それを読み出してimgタグのsrc属性に指定、みたいなことをしない様子)。
どちらの形式でもデプロイ予定ならきっちりロジック分岐が必要みたいです。
とりあえず、それっぽく動くものができました(まだ実機ではないですが)。
※以下、ばっちいおっさんが出てきます。
ここに沿ってチュートリアルっぽいことやってますhttps://t.co/lEFHBB6IP5
— コバえもん (@koba_emon) February 15, 2020
ただいまここまで
ネイティブのカメラにアクセスして写真取れました
(なぜか左右反転してる)#okajs pic.twitter.com/iQN18jMRth
この後、Xcode経由でiPhone実機にデプロイする工程があったのですが、しばらく更新していなかったXcodeさんエラーで起動せず…。
続きは宿題です。
面白かった！続きは帰ってやる！
— コバえもん (@koba_emon) February 15, 2020
せめて自分のiPhone上では動かしてみたいよね #okajs
他の方々の成果
これあれでしょ。実質完成って奴。#okajs pic.twitter.com/LdbxA0wsaZ
— イルカ＠JPUG & 岡山swift (@ikkitang) February 15, 2020
#婚活といえばオミカレ #okajs pic.twitter.com/yszB2uceLu
— 前川 昌幸@オミ岡 (@maepon) February 15, 2020
実機で動いたじゃーん #okajs pic.twitter.com/UDKsRhe0hx
— ᓬᐓᔒᐓᓳᐓᔙᐓᓙᐓᓠᐓ (@razon) February 15, 2020
みんな、Angularで写真撮ってるから、Vueでやってみた。Ionicというか、Capacitorすげえ #okajs pic.twitter.com/yC34Iw6VIa
— 🐤🐤🐤 (@kishisuke) February 15, 2020
個性が強いですね…
もくもくしてみて
UIコンポーネントやテンプレートをはじめとした手厚いサポートを受けながら、Web技術でモバイルアプリ開発ができるところは魅力ですね。学習コスト高そうではありますが、(Webアプリエンジニアなら)ネイティブアプリ開発のために1から勉強し始めるよりは気軽に始められるのではないでしょうか。
カメラなどのリソース制御は色々面倒なのかなと思ってたのですが、割とあっさりできてしまったあたりもCapacitorのおかげですね。
今後、新規にAngular案件があれば、最初からIonicでプロジェクト始めるのもアリかなと思いました。
その後…
とりあえず実機で動きました。
実機で動かせた！ #okajs pic.twitter.com/xhIHy9ctNL
— コバえもん (@koba_emon) February 15, 2020
Xcode、起動すらほとんどしたことなかったのでビルド周りでエラー吐いて色々調べまわってました…。
やはりスマホで実際に動かすと感動も違いますね！
チュートリアルなので大したものではないですが、Webアプリとはまた違う「成果が形になった」感覚を味わいました。
その後…Part2
翌日、環境キレイキレイする過程でせっかくだからとiOSも最新(13.3.1)にアプデしたところ、ビルドエラー吐くようになりました(dyld: Library not loadedとかどうとか)。
エラー内容で調べても絞り込めなかったため、Ionic(Capacitor)側かと思ってIssue調べたところ、ヒットしました。
どうも、「無料のAppleIDアカウントかつiOS 13.3.1で起こってるバグ」のようです。
上記回答の通りですね。
有料アカウントはちょっとまだ手が出ないので、シミュレーターで一旦我慢ですかね…。
実家に戻れば昔使ってたAndroid端末があるはずですが、動いたとしてもバージョン古すぎてダメな予感…。
「第4回 IoT勉強会 in 岡山」に参加してきました。
はじめに
2/8(土)、第4回 IoT勉強会 in 岡山 (共催 SORACOM-UG Okayama vol.2)に参加してきました。
ハードウェア系の勉強会は初参加です(おそらく)。
参加まで
IoTというワードが随分浸透したと感じる今日この頃。
僕の部署も今年「IoTチャレンジ」なるものに取り組むとのことで、その要員として選出していただきました。
とはいうものの、ほとんど知識も経験もない状態です。
学生時代にちょっと電子工作っぽいのに触れたことはありますが、当時はそれほど興味が湧かず、続きませんでした。
(工作目的で買ったRaspberryPiも、気づけばNASや実験用おもちゃサーバとして使ってたり)
既存システムとの連携を考えつつ、やれそうなことに合わせたモノをとりあえずいくつか部署で購入してはみましたが…
もう少し自分の中での選択肢を広げたいなと思っていたところでした。
そんなところで、勉強会の開催を知ったので参加です。
いざ勉強会
(ブランチ北長瀬、合同勉強会の時よりもテナントが増えてたような気がしました)
今回の勉強会は、SORACOM-UG共催とのことで、SORACOMというIoT向けプラットフォームを体験できるハンズオンとなってました。
まずは、SORACOMのテクノロジー・エバンジェリストである松下さん(Max)によるSORACOMの紹介です。
「モノ(センサーやデバイス)」「ネットワーク」「クラウド」を繋げるIoTを簡単に・リーズナブルに実現させたいというSORACOMのビジョンと、これまでの変遷についてでした。
やはり登壇経験の多い方の発表は分かりやすいですね。話題の順番なども綿密に練られている様子が感じ取れました。
(ちなみに、Maxさんはオーバーランの常習犯を自称されていました)
SORACOMについて知ったところで、ハンズオンへ…
…の前に、株式会社リゾームの下山さん＆カズさんによるLTです。
LTE-M Button 活用の箱罠動作検知システムのLT！ #soracomug #iotokayama #ひげボタン pic.twitter.com/r0DlLEVSEV
— 松下享平 《IoTの事例や技術紹介してます》(Max@ソラコム) (@ma2shita) February 8, 2020
離れたらONになる磁気スイッチを使って箱罠の罠扉の閉鎖を検知し、それをSORACOM LTE-M Button Plus経由でクラウド(AWS)に送って処理し、メールと電話で設置者に知らせるという仕組みを作ってみたという内容でした。
センサーONから電話が来るまでの実演を目の前で見せられると「これがIoTか！」って気分になりましたね。
設置後の猟果はまだとのことでした。早く獲物が掛かるといいですね。
ハンズオン！
ハンズオンに入ります。
複数のセンサーがセットになったハンズオン用キットを受け取り、早速組み立てていきます。
(今回は初級なので、ほんの一部しか使ってませんが)
まずはSORACOM Air(通信サービス)用のSIMカードをもらってセット。スマホ以外にSIMカード入れたのなんて初めてです。
これで電源オンしたら、マイコンモジュール(Wio LTE)にセットされたプログラムが動作し、キットがオンラインになります。LANケーブル繋いでIPアドレス振って…みたいな煩雑な手順はなし！超手軽です！
そしたら、ハンズオン用テキストサイトを見ながら、順番に進めていきます。
まずは、SORACOMのコンソールでちょっとだけSIM設定ごにょごにょして、温度センサーを繋いでマイコンの電源を入れ直します。すると…
SORACOMの管理コンソール上に温度＆湿度グラフが表示されました。
これ、SORACOM Harvestというサービスが稼働しており、IoTデバイスから送られてくるデータを蓄積・可視化してくれているのです。
こういったコンソールがすでにあるのは良いですね！
続いて、SORACOM Lagoonというサービスを使ってダッシュボードを作成し、閾値などの設定を加えてよりデータを活かせるようにしてやります。
ダッシュボードは上図のような感じです。
写真忘れましたが、デバイスから送られてくるデータ(温度)に閾値を設けてやり、その前後で画像の表示が変わるような設定も試せました。
ここまでのSORACOMサービスだけでも、データの見せ方、データに応じたアクションをWebコンソールからポチポチと簡単に設定できて便利です！
個人的に面白いなと思ったのが、SORACOM Air メタデータサービスという、SIM に紐づいた情報を設定・読み出しできるサービスでした。
変数名と値のような形で、IoTデバイスの動作に使う値をWebコンソール上で設定しておき、IoTデバイス起動時にその値を読み込むことでデバイス側の処理に利用できるというもの。ハンズオンでは、プログラムの動作モードフラグとループ間隔(ms)にこのサービスを用いていました。
IoTデバイスのプログラムの動作を変えようと思ったら、そのデバイスに直接接続して値を書き換えるものと思っていましたが、このサービスを使うとそれがWebコンソール上で完結出来てしまうわけです。これには驚きました。
ハンズオン初級編、一通りできました！#soracomug #iotokayama pic.twitter.com/KuoOco4qhz
— コバえもん (@koba_emon) February 8, 2020
懇親会へ
懇親会は、ハッシュタグの斜め向かいにあるSUNNY PIZZAというお店で、ピザとパスタです。
岡山産生醤油のカルボナーラがめちゃ美味かった！(写真忘れた)
ここでテーブルご一緒させていただいた方がバリバリのハードウェアエンジニアで、僕のようなソフトウェアエンジニアでは至りづらい「IoTを考える上でのハードウェア的な視点」を知ることができました(この設置場所で電波は通るか、隣の機器と干渉し合わないか、など)。
こういった異業種交流、もっとやってみたいと感じました。
おわりに
かなりリーズナブルにIoTプラットフォームを整えられるようになったと知れたことは大きな収穫でした。
今回使ったサービスでも、1日あたり約16円程度(SORACOM Air 10円/SIM、SORACOM Harvest 5円/SIM、通信料切り上げで +1円)とのこと。
自分でも色々触ってみようという気になりました。趣味のバイクに絡めて何かやってみたいなぁ。
おつかれさまでしたー！#soracomug #iotokayama pic.twitter.com/jEVgvr9tBj
— takeshi.furusato (@t_furusato) February 8, 2020
「第28回 中国地方DB勉強会 in 岡山」に参加してきました。
はじめに
私生活で色々バタバタしていたのもあって遅くなってしまいましたが…
1/25(土)、第28回 中国地方DB勉強会 in 岡山に参加してきました。
岡山で開催された第23回、第26回以来、3度目の参加でした。
どんなイベント？
データベースに関する勉強会です。
これまでに中国地方の都市(岡山、広島、松江、山口など)で開催されています。
なぜ参加したか
1年半ほど前に今の部署に異動してから、PostgreSQLを触るようになりました。
とはいえ、普段は一般的なSQLを書いてたら事足りることが多く、PostgreSQLであることを活かした開発が出来ていないなーと感じていたところでした。
そんな折、岡山でのDB勉強会の開催を知りました。
丁度、PGroongaを試してみようと環境を作っていたところにクリーンヒットしそうなセッションもあったので、参加することにしました。
いざ勉強会
日本PostgreSQLユーザー会 中国支部長の高橋さん(@ikkitang)による「PostgreSQL12の新機能紹介」からスタート。
HowDoYouLikePostgreSQL12https://t.co/TI7mLGBdw7
— イルカ＠JPUG & 岡山swift (@ikkitang) January 25, 2020
本日のセッションの資料です。
既存機能でも知らないものが多すぎた(JSON型とJSONB型の違いすらよく知らなかった…)。
続々とセッションが進んでいきます。
LTを2回する@patorashさんの姿も(PostgreSQLのインデックスについてと、Start-SQLの紹介) 。Start-SQL、買い切り5,000円、Web実行環境＆練習問題108問と初学者が一通り学習するのに向いてそうでした。
統計学(標準偏差とか不偏分散とか)のお話(@razon取締役LT)もありましたが、学生時代真面目にやってなかったのであんまりﾜｶﾝﾅｶｯﾀ…
RDSにおけるSSL/TLS証明書更新の話もありました(@kazuhisa1976さんLT)。sslmodeなるものがあるとは知りませんでした(以前、自前構築したPostgreSQLにpsql接続した時にそれっぽいメッセージ出てたのは気づいてましたが、スルーしてた)。
最後は、株式会社クリアコード 堀本泰弘さんによる「Amazon RDS + Amazon EC2 + ロジカルレプリケーションを使った低コスト高速全文検索」のセッション。
PGroonga、触ってみようとしてたのでざっくりとは知ってましたが、改めて機能豊富だと感じされられました。
後半は、タイトルにもある構成の紹介でした。
RDSにはPGroongaがインストールできないため、EC2にPostgreSQLをインストールして検索用のロジカルレプリケーションとし、そこにPGroongaをインストールすることで、RDSではできなかったPGroongaを使った検索を可能にしたとのことでした。
ちなみに、PGroonga(ぴーじーるんが)と読むようです。小さなことですが、ちょっと気になってたので。
PGroonga(ぴーじーるーんが)
— コバえもん (@koba_emon) January 25, 2020
ぴーぐるーんがとどっちだろうと思ってた #ChugokuDB
そして懇親会へ
懇親会はカラアゲバル フリット！グリルと！で、美味しい唐揚げとハイボールです。
3枚目、焦げてる訳ではないですよ。
「黒カラ」という、このお店の名物唐揚げです。
懇親会でも、PostgreSQLのバージョンアップについてや、MySQLとのちょっとした違いなど色々得るものがありました。
Wikipedia記事を使ったPGroonga検証の環境構築用スクリプトがGroongaのリポジトリにて公開されている、ということを堀本さんに教えていただいたので、早速試してみる予定です。
また、(どういう経緯だったか忘れましたが)婚活について色々アドバイスをいただきました。
某婚活サイトを手がける会社の方々からも、ちょっとした裏話を聞けたりしました。
正直なところ、自分のやりたいことが制限されるんじゃないかと結婚にはマイナスイメージが強かったですが、そういう制限が付くかどうかはやり方次第なんだなと思いました(※DB勉強会の懇親会です)。
おわりに
参加を通じて、DBに対する自身の知識・経験がまだまだ浅く、実務へ活かし切れていないと再認識できました。
それほど複雑な要件に当たる機会がなく、自身の知りうる知識の範囲内で何とかなってたりするのも一因かなと思っています。
当然それは悪ではないと思いますが、その範囲内で何とかなってるうちは大きな成長が望めないと感じてます。
ならば、その範囲外を自己学習するしかないなと。
また、発表内容の他に、スライドの構成や配色といったあたりも参考になる部分が多くありました。
「黒背景に赤は良くない」 そらそうよ #ChugokuDB
— ゆいな (@yuina1056) January 25, 2020
堀本さんが使っていたRabbitというプレゼンテーションツールも面白そうでした。
スライド下部にうさぎ(現在のペース)とカメ(理想的なペース)が追いかけっこしているイラストが表示されて、発表がまいてるのか押しているのかを視覚的に把握できるものになってました。
とりあえずPGroonga使ってみようと思います。
公式のベンチマークスクリプトを使うことでサクッと環境を作れるようなので、まずはそこから。
ぼくがかんがえたさいきょうのCookie
この生地は？
こんにちは。
この記事は、大都会岡山 Advent Calendar 2019の14日目になります。
adventar.org
最近、生まれて初めてクッキー(食べるほうの)を作りました。
生地こねて型とってオーブンでブンするだけなので、普段料理をほとんどしない僕でも簡単に作れました。
基本ができたら、ちょっとアレンジしたくなりますよね。
というわけで、ちょっとだけアレンジしました。
れっつあれんじ
一般的なクッキーには、ビタミンと動物性タンパク質が不足していると考えました。
そこで、今回はそれらを取り入れた栄養バランスの良いクッキーを目指します。
【材料】
- バター 60g
- 薄力粉 120g
- 粉糖 50g
- 卵黄 1つ
- 塩 少々
- バニラエッセンス 少々
- ？？？その1 少々
- ？？？その2 12g
まずは、普通にクッキーの生地を作ります。
まぁ、「？？？」以外の材料をボウルに入れて混ぜるだけなので簡単です。
そしたら、？？？その1「レーズン」を投入します。
最初はドライフルーツにしようと思ってましたが、僕の苦手なパイナップルがどうしても入ってやがるので、隣にあったこれにしました。
ビタミン不足は、こいつで解決します。
次は、？？？その2を投入します。
先ほどビタミン不足へのアプローチはしたので、動物性タンパク質不足をどうにかします。
ブラウザバックしようとした方、大丈夫です。
今回実体は登場しません。
我が家にたまたま「クリケットパウダー」がありました。
タンパク質含有率69%と言われるスーパーフードです。
ソース: http://takeo.tokyo/note/health/work-out/
これを、薄力粉の10分の1ほど投入します。
そしたら、混ぜます。
満遍なく混ざったら、生地をラップで包んで冷蔵庫で1時間ほど寝かせます。
クリケットパウダーを入れると、結構色が変わります。
(下図は以前作ったときのやつ。左がプレーン、右がクリケットプレーン)
1時間経ったら、生地を冷蔵庫から出して、麺棒で伸ばして型抜きして…
180℃のオーブン(きちんと予熱しておく)で、12分ほどブンして完成です。
で、味は？
はい、普通に美味しいです。
クッキーの優しい甘みの中に、レーズンの甘酸っぱさとクリケットの香ばしさが同居しています。
反省点ですが、レーズンは生地練ってるときに入れるのではなく、型抜きした後に上から軽く押し込むべきだったと言うのが1点目。
写真見ていただければわかりますが、生地に練り込んでると焼き上がった時にレーズンが隆起した感じになってボロッとした見た目になってしまいます。
そして、後から知ったことですが、レーズンはそれほどビタミンを含有していない(ソース:Wikipedia)と言うのが2点目。
ミネラルやポリフェノールは含んでいるので、健康的であることに間違いはないですが…。
おわりに
何はともあれ、美味しくてそこそこ健康的なクッキーができました。
淹れたてのコーヒーと共に、朝食にでもしようかと思います。
興味を持たれた方はお試しあれ。
余談
そういえば、こんな発表がありました。 ryohin-keikaku.jp
日本ではまだまだ浸透してませんが、海外ではベンチャーが立ち上がったりと、ちょっとしたムーヴメントになってたりするようです。
国連機関が推進に向けた報告を出したりもしてるようですね。
競争が起きれば価格も下がるでしょう。
今後の動向から目が離せませんね。
