産業でガチ利用されるRaspberry Piの話
- OS => Debian(ラズビアン)
プロトタイピングとかに便利
実際にどう利用しているか
手順
ainsibleでやってること
- 最初のLinaxイメージ作成
- アップデート、検査、後片付け
- 任意のコマンド
- APIに怨嗟情報送信
- 組み立て後検査用の自壊プログラム送信よう
- 検査できる状態はainsibleとの接続が出来る状態なので、その設定削除
IoT用途
- BLT
- 距離が５m離れると旧Verとの差が２５％
- BLT
ソフト構成
ラズパイが利用できない場合は以下
ラズパイは同類製品の中で品質が図抜けている
質問１ ラズパイ利用で気をつけていること
- 濡れるとかがなければいける
- SDは変なの使うと壊れるのでいいやつを使おう
質問２ 物理セキュリティ（こっそりSD抜きワーム仕込みとか）
- 室内に置いて置くからまあ大丈夫のはず。。。
質問３ 次のバージョン（Ver4）での希望
- 値段安く
- ソフトはLinaxなんで改善できる
- IO
- Bluetoothは近くないと
- apwaならビル一棟をカバーできるのでそういうのを利用したい
質問４ 5Ghz対応
- 顧客の無線のポリシーに合わせる
質問５ テンソルフローで何してる
- 利用できるよってだけで実際に利用はしてない。。。
質問６ SDの剪定 どういう耐久テストをしてる
- 連続でIO 何分か程度
- ユーザーの手元に行かなければOK(テストで弾じけてればOK)
ラズベリーパイZERO とSDのおすすめは何ですか
- 品質きになる
- T社
開発現場で役立たせるための設計原則とパターン
- 設計が問題に対して最適であるかどうかの判断基準
- 責務とか抽象化とか
- ある問題に対して解決策となるような構造を与えるアクティビティ
- ここ聞き逃したorz
- 闇雲に分割するのは良くない
- デザインパターンを闇雲に適用するのは良くない
- じゃあどうする。どういうつぶ度で分割する
- 色々な減速とかから選び出す力
- 設計原則とは
- その分割構造が良い構造かどうかを判断する指針
- 構造を作る（コードを書く）＜＝＞レビュー観点として、設計原則を利用する
- 設計原則
- 単一責任原則
- （知ってるので省略）これが満たされている場合はクラスがしごとしすぎ
- 解放閉鎖原則
- 拡張に開いている、修正に対して閉じている
- 拡張=>他クラスに影響がない
- 閉鎖=>修正するときに、他クラスに依存している（一緒に直さなきゃいけない）のはNG
- 拡張に開いている、修正に対して閉じている
凝集度と結合度
- 凝集度は高く
- 関連するものは一つにまとめる
- 一個の仕様変更でいろんなクラスに影響するのは凝集度が低い
結合度は低く
- 単一責任原則
- ★★★設計原則があれば、コードの良し悪しを議論の場に展開できる★★★
- 単一責任原則
- サービスのどこが変更される可能性があるかどうかがわからないと単一責任原則を利用して判断できない
- いつでも使える構造はない。
- 問題をよく吟味すれば、設計原則を適用できる
そもそもオブザーバパターンを利用した時は、コメントされたときにコメントオブザーバ- クラスも高確率変更されること（凝集度が低い）を見落としていたため
kiss
- yagni
どこが変わるかわからない時は、現在の範囲のみで極力シンプルにしておけ
EnterpriseQualityCoding/FizzBuzzEnterpriseEdition
質問１ 設計原則の適用をフェーズに分けられないか
設計原則を学ぶ時は、いつ使えるのかをいつも考える必要がある
質問２ レベルの低いチームメンバに対する風土共有
- 事例欲しいです
質問３ 単一責任原則でのわからなかったところ
- 通知のタイトルを作るという修正が入った場合
- もう一回イテレーション
事前知識なしで理解する、静的検査のいろは
感想
buildersconは初参加です。セッションを聞くだけで普段触れないことについて具体的な例を掘り下げてもらえるので、とっつきやすいです。
今日は３つしか聞けなかったけど、明日はもっと聞きたいです。
産業でガチ利用されるRaspberry Piの話
- 今はとにかくラズパイを買いたいと思ってる（何をするかは決めていない）
- 産業で利用していることから来る、実際のセキュリティ事情（物理含む）の話がエモかった。
開発現場で役立たせるための設計原則とパターン
- 全体的に分かりみが深い
- 中途半端に覚えているデザインパターンしっかり学び直したい
- 「レビュー指摘で言語化できない部分（何かやばいという感覚）は暗黙知」というのは目が覚めるような表現だと感じる
- （レビュー文化のある環境が欲しい・・・）
- チームメンバー全員で設計原則についての知識を共有し、レビューも設計原則を元に議論し、レビュイーが納得した上で修正し、再度レビューするサイクルを繰り返せる状態を目指したい
- 学習コスト。。。
- 設計原則ってみんなはどこで学んでいるんだろう。
- 自分は「オブジェクト指向でなぜつくるのか」という本から入って、落ち穂拾いをしてきた感じな気がする
- そもそも設計原則の単語が話に登場するような人は全方面に強いような印象がある
事前知識なしで理解する、静的検査のいろは
- 一年ぐらい前にコードを解析して、クラス図などをoutputするツールの改修案件に携わったことがあって、そのときに既に誰かが作成済みだった解析そのもののロジックをしっかり理解できていなかった。
- セッションの展開が早くて、全て理解できたか怪しいけど、なんとなく↑の案件でやっていたとこがわかったような気がする。。。
- このセッションはハンズオン形式でやってみたい感。ちょっとずつ解析できるのが楽しくなるような気がする。
- 一年ぐらい前にコードを解析して、クラス図などをoutputするツールの改修案件に携わったことがあって、そのときに既に誰かが作成済みだった解析そのもののロジックをしっかり理解できていなかった。
