クラウド的なアレ

結構読みづらい印象の書籍だった。 ただ、読むと、近年では突然となっているキーフレーズ、例えば、CDやMVPなどは、この書籍の後押しもあって爆発的に普及したのかも、と思った。 成長の型として、粘着型、ウイルス型、支出型、どれがマッチするかを判断して、また、ピボット（＝成長の型を変えること）が必要になっていないかを定期的に見極める必要がある、という点はよく伝わってきた。 少ないながらも下記はメモに残した。 学生がその戦術に目を奪われがちになる点だ。できの悪いプロトタイプの段階で製品としてリリースする、最初から料金を徴収する、売上目標を低くおさえて結果責任を負えるようにするなどの戦術だ。いずれも有用なテクニックだがそこが肝ではない。 いわゆるアーリーアダプター（earlyadopter）──製品をもっとも強く欲している顧客をみつけること 最初に顧客と接するとき求めるのは、最終的な回答ではない。どういう人が見込み客なのか、また、彼らがどういう問題を抱えているのかを大まかに理解するのが目的だ。これさえ理解できれば、ターゲットとする顧客の人間性を記した文書という形で顧客の原型（customerarchetype）が作れる。 質が低いＭＶＰとすべき理由は、アーリーアダプターが求める以上の機能を作っても無駄だからだった。しかし、この論理が正しいのはそこまでだ。アーリーアダプターで成功すれば、次はメインストリームの顧客に売らなければならない。メインストリームの顧客は求めるものが異なるし、要求が厳しい。 大事なところであればあるほど、５回のなぜが５回のだれになりやすい。まずはプロセスの使い方を学び、その後、重要性の高い分野に適用していくほうが安全だ。 リーン・スタートアップに関連する商品一覧 - honto本の通販ストア  

Design it!を読んでいて、Pub/Subパターンの記載があった。 ふと、Pub/Subの概念は知っているけど、実装をしたことは一度もないし、どうやって実装すればいいか知らない。 このパターンに登場する人物紹介はこの記事が分かりやすかった。PublisherとSubscriber、そしてEvent Channnel（他に読んだやつでMessage Hubって表現していたものがあって、そっちの方が個人的には好み）。 Observer vs Pub-Sub pattern | Hacker Noon  https://hackernoon.com/observer-vs-pub-sub-pattern-50d3b27f838c PublisherがEvent ChannelにTopicを放流して、SubscriberはそれをSubscribe。PublisherはEvent ChannelにTopicを増やしていけばいいし、Subscriberは好きなTopicをSubscribeすればいいから、スケールさせやすいアーキテクチャーなんだと。 あまり多くは見つからなかったけど、Pythonのライブラリだとこのpypubsubあたりがスターの数が多かった。 GitHub - schollii/pypubsub: A Python publish-subcribe library  https://github.com/schollii/pypubsub 早速使ってみたのだけど、サンプルはとりあえず動いたとはいえ、結局使い方とライブラリの挙動を自分の中で結びつけられなかった。 Observerパターンと違ってSubscriberはPublisherのことを知らなくてもOKだという話だったし、その逆も然り。 そうなると、PublisherはTopicを登録したいだろうし、SubscriberはTopicの一覧を見て購読したいだろうなあと思う。（RSSをイメージしてる） そこでこのライブラリを使っていて沸いた疑問としては、次のあたり。 - どうやってPublisherはTopicを登録するのか？（あるいはPublisherは登録自体はできなくて、Topic Managerに依頼する？） - どうやってTopic ManagerはPublisherから見てSubscriber

今日の記事の中にある引用はこの書籍の5章後半〜6章。 まずは要求を知るための話として、アクティブリスニングが紹介されていた。 会社でも度々話には上がっていたのだけど、正確には理解していなかったことが読んでわかった。その上、自分はできていない。これを機に試してみたいと思う。 日本語でアクティブリスニングは積極的傾聴、なんだけど、積極的に聞くこと＝傾聴で、これは重ね言葉じゃないかしら。（どうでもいいか） 人物Aが人物Bに達成度や自分が解決した問題について話をしているとする。コツは、人物Aが発言を終えたことを示すまで、人物Bは口を挟むのを許されていないということだ。人物Aが発言を終えたことを示したときだけ、人物Bは人物Aの発言への理解を深めるために問いかけることを許される。質問をフィードバックや批評に変えることはできない。人物Bの目標は、理解を深めることだ。それが終わったら、今度は役割を逆にして、同様の訓練を体験しよう。 それから、アーキテクチャードキュメントの話も出てきた。会社でもアウトラインは聞いていたけど、こういった紹介はありがたい。 これがあれば、いざ実際にアーキテクチャーを設計するぞ、と思った時に、それをどうアウトプットにすればいいかのイメージがしやすくなる。 目的とスコープ 対象者 ビジネスのコンテキスト 　ステークホルダー 　ビジネス目標 ASR 　技術的な制約 　ビジネス上の制約 　品質特性の要求 　　トップシナリオ 　影響力のある機能要求 　　トップユーザーまたはユーザーのペルソナ 　　ユースケースまたはユーザーストーリー 付録A：用語集 付録B：品質特性の分類 それから、アーキテクチャー v.s. デザインはよく語られることだと思う。 会社の研修で学んだものだと、要求(作ってほしいもの)と設計(作るもの)の間にあるものがアーキテクチャーだってことで、何を作ろうとしているかでアーキテクチャーの対象は変わると聞いた。それなりに納得感があると思ってる。 とはいえ、アーキテクチャーを設計する、って表現もよく聞く。そうすると、結局アーキテクチャーとデザイン(設計)との違いはなんだろう、という話になるなあ。 すべてのアーキテクチャは設計だが、すべての設計がアーキテクチャではない この記述と自分の理解を合わせていくと、設計には広義と狭義があり、広義の設計にはアーキテ

Visual Localizationは画像で位置推定する方法。 あるカメラが認識した画像と事前に取得した画像、さらに進んだ地点でカメラが認識した画像と事前に取得した画像、を比較していくことで該当地点の可能性をどんどんと絞っていく。 この方法の良い点は、画像を事前に容易に入手可能なこと。この方法の弱い点は、3Dマップの情報がなく3Dマップに依拠できない点。 GNSSとInertial Navigationで現在地を、LiDARで向かっている方向を特定するのがKalman filterのアプローチ。 UdacityではIntro to Self-Driving Cars, Self-Driving Car Engineer Nanodegree Programが用意されている。 - Intro to Self-Driving Cars Nanodegree | Udacity  https://www.udacity.com/course/intro-to-self-driving-cars--nd113 - Become a Self-Driving Car Engineer | Udacity  https://www.udacity.com/course/self-driving-car-engineer-nanodegree--nd013 Perception、要は認識。Recognitionのイメージが強かったけど、このコースではPerceptionって言葉を使ってた。 人間は目で見てどれだけの速度を出すか、どこで曲がるか、どこがレーンかなどを認識する。 自動運転車はそれがないが、その代わりにカメラ画像やセンサーを使える。 Computer VisionとはComputerがどのように世界を認識し理解しているかのことで、最も使われているアプローチはCNN(Convolutional Neural Networks)。 Computer Vision自体だと、Udemyの次のコースとか良さそう。 - The Complete Self-Driving Car Course - Applied Deep Learning | Udemy  https://www.udemy.com/course/applied-deep-learningtm-the-compl

比較的読みやすい英語だったこともあってここまでは英語で読んできたけど、 本格的に時間がないしかといって読むものを減らしたくないのでやむなく日本語で読むことにした。 今日の記事の中にある引用は全てこの書籍の5章から。 要求といえば、機能要求と非機能要求。 これは広く一般的に知られていることだと思う。 ただ、読み進めていくと、もう少し違う分類の仕方をしよう、と提案している。 アーキテクチャ上重要な要求（Architecturally Significant Requirement：ASR）とは、アーキテクチャ構造の選択に強く影響する要求のことをいう。ASRを明らかにするのは、ソフトウェアアーキテクトの責任だ。これを行うには、次の4つの要求分類について考える必要がある。 制約 変更できない設計判断。通常は与えられるものだが、選択することもある品質特性 システムが特定の状況でどのように動作するかを特徴付ける、外部から観察できる性質。 影響を与える機能要求 アーキテクチャにおいて特別な注意を必要とするフィーチャーや機能。 その他の影響を及ぼすもの 時間、知識、経験、スキル、社内政治、あなた自身の余計なバイアス、そして意思決定を左右するその他すべてのもの。 制約は、一旦決定されてしまうと100%交渉不可能となる。制約を受け入れることに慎重になろう。「やらなければならない」と「やらないという正当な理由がない限りこれをやる」の間には大きな違いがある。 整理してみるとこんな感じ。言いたいこと自体を大きく変えているわけではないけど、少しわかりやすくなってる。 その上で、品質特性は次の3つに分けて考えると良いと言っている。 設計時の性質 修正容易性、保守性、再利用性、テスト容易性、製造容易性・製品化までの時間 実行時の性質 可用性、信頼性、パフォーマンス、スケーラビリティ、セキュリティ 概念上の性質 管理容易性、サポート容易性、簡潔さ、学習容易性 日本語だとピンとこないこともあるので、ここは原著を確認した。 次のように分けている。性質は原著ではPropertiesだったらしい。少し後にも繰り返しで、次のように書いてあった。 Design Time Properties Runtime Properties Conceptual Properties Modifiability Maint