AWS IoTの後ろにKinesisって必要？
昨日AWS無料アカウントを開設したばかりのヒヨっ子ですが、よく分からない点が一つ。
AWS IoTの後ろのKinesisっていんの？
- KinesisFirehose はS3に直接入れたい時とかに使え
- KinesisStream はデータ加工したい時はこっち入れて、Lambdaと連携しろ
みたいな感じ。
一種のとりあえずのデータキューだ、らしいです。
で、AWS IoTの公式に書いてある内容には、下記のような説明も。
• 受信メッセージのフィルタリングおよび変換、DynamoDB へ時系列データとして保存。
何か、この説明を鵜呑みにすると、AWS IoTから直接DynamoDBに捌けそうな気がするし、
Kinesis (+Lambda)挟む必要あるんかな。。。
どっちでも出来るんでしょうけど、コスト＋負荷の面でどちらをチョイスすべきか。
誰か教えてくれないかな(小声)
ソラコムさんの製品から何かビジネスが浮かんだ件
とりあえず、先にオチを言いますと、どんなビジネスかは言いません。
まぁ言ったところで、その方面の人からは、‘’何それ？うまく行くわけないやん‘’、って普通に言われる可能性もあるわけで、世間知らずがドヤってイタいみたいになるのが嫌なのが半分。後の半分は、ホント良いアイデアな気がしてて、他の人に先越されたら嫌やな、という勘違い的な発想が半分、と言ったところです。
まずは、大まかな試算をして、開発（製造）コストや、運用コストがそもそも破綻しないかを検討しよう。
なるべく長く夢が見れたら良いな
Innovation EGG 行ってきた
昨日、Innovation EGGというイベントに行ってきました
きっかけ
今まで社外のイベント的なものに行った事なく、自分自身にも何か刺激が必要な気がしたため、とりあえず、何かに行ってみようという軽いノリです。で、下記で色々調べる事にしました。
eventdots.jp
で、今回のInnovation EGGというのが、大阪で開催されるし、初心者でも大丈夫そうだったし、最近流行りのIoTがテーマという事だったので、参加する事にしました。
Innovation EGG <IT系コミュニティ合同•未経験者向け勉強会> | Doorkeeper
で、発表の内容で印象に残った内容は、若干要約しますが、
モノ(Thing)だけ繋げても大した事ない。モノ→データ→プロセス→人、と繋がる領域が増えてこそ意味がある
との事。
自分自身、IoTって組み込み機器がインターネットに繋がるだけの事やん、っていう認識だったので、まさに"モノ(Thing)だけ繋げても大した事ない"という話は、ふむふむという感じ。
あとは、ソラコムさんのお話とか。ソラコムの社長さん、何か見た事あるなーと思ったら、AWSの本の人だったんですね。知らんかった。ソラコム自体は事前に存じ上げてなかったんですが(自分がただ情報をキャッチ出来ていなかっただけ。。。)、今後IoT市場のインフラとしてデファクトスタンダードになる事を狙われてるようです。今後恐らく触れる機会も出てくると思います。
あとは、温度をIoT基盤(確かラズパイ)で温度測定して、サーバまで上げて配信するデモ、とか。データの反映とか、割と即時反映というか、タイムラグみたいの無いんで少し驚きました。
あと、結構、名刺交換したりと、新たなビジネスチャンスの場としての利用もありそうですね。今後も、旬な情報をキャッチするためにもこういう場にはなるべく参加していこうと思います。
単体テストは限りなく無駄
無駄と完全否定するのも、ソフトウェアに携わる人間として、如何なものか、と思ったため、限りなく無駄と、オブラートに包む事にしました。
まず、単体テストは一般的にどういうものか、ググって最初に出てきた下記を引用。
単体テスト（ユニットテストと呼ばれることもあります）は、プログラムを構成する比較的小さな単位（ユニット）が個々の機能を正しく果たしているかどうかを検証するテストです。 通常、関数やメソッドが単体テストの単位（ユニット）となります。
単体テスト(ユニットテスト)とは｜検証の種類－単体テスト(ユニットテスト)｜テクマトリックス株式会社
上記の通り、単体テスト≒関数テストをイメージしている人が多いと思いますので、その認識で話を進めます。
まず、”個々の機能を正しく果たしているかどうかを検証する”とありますが、より噛み砕くと、”詳細設計書で書いている機能を正しく果たしているかどうかを検証する”となります。なので単体評価書の項目作成におけるインプットは詳細設計書であり、単体テストで関数レベルのテストがしたければ、関数レベルの詳細設計書が必要になります。これ重要です。
さて、それを踏まえて、単体テストの現実を見ていきましょう。
関数レベルの詳細設計書を書こうとすると死ねる問題
実際の開発では、下記のようなケースが多いです。
- 詳細設計書をそもそも書いていない
- 一応詳細設計書という肩書のモノがあるが、関数レベルで全部書くと死ねるため、詳細設計書の対象コンポーネントをザックリ抽象的に説明した位置づけのモノになっている
まず関数レベルの詳細設計書を書こうとすると、工数が超大になるケースが多いため、潔く詳細設計書なんて書かない、という1のケースもありますが、実際は2のケースが多いです。何故かというと、会社の開発プロセスの制約上、次の実装フェーズに移行するため手続きに"詳細設計書"という名のアウトプットが必須なケースが多いからです。作っとけば特に文句は言われないが、無いとそれはちょっと・・・ってやつですね。ただ関数レベルで書くと、工数が膨れ上がるため、そんな粒度では書きたくない。なら、ある程度抽象的にコンポーネントをパターン的に説明する資料にしよう、みたいな感じになります。で、これはこれで後のメンテする上では有用な情報になり得るので無駄では無いのですが、単体テストを関数テストの粒度と捉えると、上記1,2どちらも評価書のインプットにはなり得ないため、この状況では単体テストが出来ません(正確には関数レベルの項目が作れない)
じゃあ、単体テストは無しで、、、、と言うほど、世の中は柔軟に対応してくれません。
とりあえず、単体テストやれ(品質のために)
ひとまずやれと言われるとやるしかありません。さて、では、どうやって評価項目をおこしましょう？詳細設計書はインプットになりません。となると、もう残された道はただ一つ。
せやっ！コードをインプットにおこしたろ！
これで、関数単位でのテスト結果はアウトプットは出来るのですが、何の意味もありません。更なる深みに嵌ります。実装そのものがインプットなので、理論上、"誤り"が見つかるはずがありません。言い換えると、どんな実装してても、理論上全て"正"です。なので、このような単体評価は品質の向上に何ら繋がりません。
それでは、律儀に関数レベルの詳細設計書を書いたパターンはどうでしょう。
まず、この作業をしていると、‘’もうコード書いた方が良くね‘’症候群に襲われますし、仕様変更の追従対応とかも鬼です。また、純粋なC言語レベルでしたら、そうでもないのですが、スマホのようにフレームワークが縦横無尽に暴れ廻る戦国時代のようなところになると、もう机上での設計が非常に難しくなります。特にUIとの連携部分はどれもフレームワークに委譲されている部分が大きく、
どこまでをアプリ開発者が自前で実装する必要があるかなど、事前に正確に把握するのも厳しく、もう実装して動かして確認したほうが早くね？、という結論に至るケースも多いです。
で、案の定、もう息切れしてきたため、適当に切り上げます。
- 詳細設計はメンテ用途で作る（関数レベルで書かない）
- 単体テストはアウトプットに徹する（察し）
散々ディスってた内容を推奨する理由ですが、
Mac book Pro の修理がやはり面倒な件
結局、例のキートップが外れてから、まだ修理に出していません。
理由としては、結構日常的に使っているし、何より、修理出す前に”バックアップしとけよ、都合によってはデータ消すぞ”とApple様に脅されるもんですから、バックアップしないといけないんですが、
ポータブルHDD無いし。。。
おおよそ1万ぐらいは懸りそうですね。タダでさえ、来月からMac Book のローン返済が始まるというのに、そんなお金無いしなぁ。。。
嫁に交渉するのも正直気を使うし、リアルに無駄な出費になるし、消えるの覚悟で修理出すという手もあるけど、今までセットアップした環境が消えるのも何か受け入れられんし。。。
ご、ゴネたい。。。
完全なる証拠が無い＋証明が出来ないからアレやけど、9割方初期不良だった(はず)なのに、ここまでせんと解決しないというのがどうも納得がいかない。今まで潜めていたクレーマー精神がフツフツと込みあがってきております。
- Genius Barで無料で直してもらえる
- 修理センターに出す(データ消えない)
↓====受け入れられない壁=========↓
- 修理センターに出す(データ消える)
- 修理センターに出す(バックアップHDD自己負担)
↓====絶対に受け入れられない壁====↓
- 修理センターに出す(バックアップHDD自己負担+保証対象外として修理代金請求)
もう最後のケースになったりしようもんなら、発狂間違い無しです。
運良く部品がある事を願って、またGenius Barに行くしかないですな
Apple心斎橋店Genius Barに行った
Apple心斎橋店2FのGenius Barに行きましたが、結局、すぐには直せないという事でしたので、そのまま引き上げました。にしても
めちゃ混みやん…
予約してたけど、予定時間より、約30分後でした。予約してなかったら恐ろしいですな。
あと、お節介かもしれませんが、もう少し‘’待ちの見える化‘’をしたほうが良いのではないでしょうか。店員さんはタブレットで予約の順番管理をしてたみたいですが、待ってる側は見れないですし、あとどれくらい待たないのか分からず、正直不安です。銀行みたいに待ち番号みたいに分かるようにしたほうが良いのかと（予約が混ざるとどう扱うかなど課題はありますが）。
mac book proの修理がすんなりいきそうにない件
先日、Apple オンラインで購入した整備済み品Mac book proの"←"キーが浮く問題が発覚した件の続きです。ひとまず、Appleに電話で聞く事に。Appleのサイトで電話番号入力したら、すぐにAppleから電話が掛かってきました。こういう部分は、かなりスピーディーですね。世の中、お問い合わせ窓口に電話すると、散々自動ガイダンスで振り回され、挙句の果てに、今混み合ってるからこの状態で待て、とか割と多いんでね。ほんでやり取りした内容をまとめるとこんな感じ。
- 修理となれば、キーボードの取り替えになり、且つ、今回のケースは保証の対象外のため、8万ぐらい自己負担掛かるかも
- 整備済品なので、交換の概念は無い
- 上記理由から、修理ではなく、一旦、返品(+返金)して、再度別のmacを購入してはどうか？
うーん。結構めんどいパターン
今回のケースは保証の対象にならない可能性が高いってのが、うーん。そうなんだろうか。。
たかが、一つのキーとは言え、されどの部分もあり、やっぱり打ってて、気になるんですよね。もう自分でボンドでくっつけるという暴挙に出ようかな、と心が揺らぎます。で、とりあえず、genius barという何かお酒でも出てきそうなApple の修理コーナー的なとこに持ってくと、ひとまず、状況を見てくれるらしいので、持っていこうと思います。もしかしたら、チャチャッと直る問題かもしれないし。
