ねえぶ

猫好きエンジニアのブログ

先月読んだ本と今月の読書予定(2019年6月)

先月の読書実績

漫画,雑誌は除いています.

実績 Fav
TQMとその進め方 (QC入門講座)
ソフトウェア工学の基礎
▶️ あなたもいままでの10倍速く本が読める
▶️ 技術士第二次試験 合格する技術論文の書き方

今月の読書予定

新規・継続
▶️ あなたもいままでの10倍速く本が読める
▶️ 技術士第二次試験 合格する技術論文の書き方
🆕 ソフトウェア工学の勧め(上)

エンタープライズアジャイル勉強会 2019年5月セミナー レポート

5/16(木)に参加したエンタープライズアジャイル勉強会 2019年5月セミナーのメモです.

イベント概要

エンタープライズアジャイル勉強会の紹介

講演: モノリスなアプリからマイクロサービスへ - クラウドネイティブなアプリ開発における CI/CDプロセスとDevOpsツール -

講演者

講演要旨

  • マイクロサービスとは何か?なぜそう設計・実装する必要があるのか?
  • 実装するにはどんなことを考慮する必要があるのか?
  • など基本的な解説をサンプルアプリを通じてご説明し、DevOps ツールで実際に CI/CD のデモなどをご紹介していきます。

FIXERについて

クラウドサービスの需要が高まる背景

  • DXに対応するための,意思決定の高速化やビジネスプロセスの変革
  • プラットフォーム(win2008とか)のEOLに伴う,オンプレのリプレースやマイグレーション
  • 政府の方針(取り組み)
    • 世界最先端デジタル国家創造宣言
    • 官民データ活用推進基本計画
    • デジタルファースト法案
    • クラウドバイデフォルトの推進
    • ディスカッションペーパー at 政府CIOポータル

マイクロサービス

  • 背景
    • レガシーマイグレーションや新規開発をする際は,責任分界点が明確なのでSaaSを推奨しているが,ビジネス要求とのバランスからサービス開発が必要になる
    • 大規模システムをモノリシックに構成する際の問題を解決する必要性が高まる
    • コンテナ技術などの環境が整ってきた
  • 特徴
    • 疎結合APIベースの結合,責任分割,障害の局所化)
    • 開発チームの小規模化による管理の容易化
    • 個別にサービスを更新できる
  • デメリット
    • 運用管理コストは増大
    • データ整合性担保が難しい
    • 結合テストが難しい
  • MSによる例(ホテルのシステムをマイクロサービスで開発)

マイクロサービスを支える技術

  • Docker
    • 資源効率性が高い
    • 移植性が高い
  • 大量コンテナ化に対し,オーケストレーションが必要→k8s
    • オートスケール
    • blue green deployment
    • rollig update
  • k8sは,実際はマネージドサービス使うのがベター
  • 大規模化すると,データ整合性やk8s上のサービスの通信の統制が問題に→Istioなどのサービスメッシュ
  • Windowsだけで開発できる環境が整っている
    • .Net core
    • Docker for Windows
    • VS2019のコンテナサポート
  • Azure DevOpsでコンテナ・マイクロサービスのDevOpsを簡単に管理できる
    • コンテナリポジトリ
    • プルリク,コードレビュー
    • ビルド,テスト
    • デプロイ
  • 他にもAzureにいっぱい便利なサービスがあるので要チェック

(自分がした)QA

  • Q: 「クラウドバイデフォルトの推進」で民間のパブリッククラウド利用を推進しているとのことだが,医療情報のクラウド保存に関する3省2ガイドラインのようなガイドラインもあるのか?
    • A: 「クラウドバイデフォルトの推進」にはないが,他のガイドラインには入ってる.政府CIOポータルをウォッチしておくと,そのあたりの情報が得られる
  • Q: マイクロサービスの特徴で,開発チームの小規模化と管理の容易化が挙げられていたが,コンウェイの法則的に,マイクロサービスを適用する場合は,組織改革を並行させないと問題が起きやすいか?
    • A: チームがそのサービスを全部知っていることが理想的なので,そうあったほうがよい
  • Q: マイクロサービスは,サービスメッシュなどの適用なしに実現できるものなのか?Istio/Envoyとか使わない選択肢もありえるのか?(データ整合性の担保など)
    • 大規模・複雑化していないシステムはマイクロサービスにする効果が薄い
    • 大規模システムのマイクロサービスにおける各サービスの協調は自前管理が難しい
    • ↑この2つにジレンマを感じるが
    • A: まずは小さな規模でもいいので適用してみるのが有用
      • マイクロサービスの感覚をつかむ
      • 特定サービスに投資を集中できる
      • 大規模なものに対しての適用は,サービスメッシュを考えたほうがよいが,規模の大小については,両方からアプローチするのがよい

先月読んだ本と今月の読書予定(2019年5月)

先月の読書実績

漫画,雑誌は除いています.

実績 Fav
FACTFULNESS(ファクトフルネス)
▶️ あなたもいままでの10倍速く本が読める
▶️ ソフトウェア工学の基礎

今月の読書予定

新規・継続
▶️ あなたもいままでの10倍速く本が読める
▶️ ソフトウェア工学の基礎
🆕 ソフトウェア工学の勧め(上)

iOS Test Night #10 に行ったメモ

今月からソフトウェア品質管理部門で仕事をするようになったこともあって,DeNAさんで行われたiOS Test Night #10に参加してきました.

イベント概要

目的

XCTTestやXCUITestを使ったテストはやったことがあったけど,PJや組織の特性によってそれ以外に選択・組み合わせ可能な要素にどのようなものがあるか学ぶ.

発表

19:35-19:50 15分枠(1) ぎぎにゃん / Azure Pipelines for iOS使ってみた

  • スライド
  • Azure PilelinesでXcodeプロジェクトのビルド(テスト)をする話
  • 小さい型にはまったプロジェクト(ライブラリとか)なら簡単にCIできる
  • パッケージ依存性があったりCDが必要な場合はちょっと面倒
  • カッコイイところ
    • 早い,安い
    • macOS/linux/windowsのコンテナが使える!!
    • GUIでパイプライン設定が作れ,YAMLに吐ける
    • ローカル環境のmacOSをスレーブにできる(セルフホスティング
    • XUITest/Appiumとかも使える
  • 適用プロジェクトは限られそうだけど,試してみたい

19:50-20:05 15分枠(2) susieyy / Snapshot Testing

  • スライド
  • Snapshot Testing
    • 正しいSnapshotとのdiffを取ってテストする
    • テストピラミッドのUTの中で上位に相当するレベルのテスト
    • 状態ごとの画面カタログとしても利用している
  • iOS SnapshotTestCaseを使ってる
  • 通信やアニメーションの途中でSnapshot取らないような工夫はいくつか必要
  • Snapshot Anything
    • 画像だけじゃなくてビューやJSONデータなど,なんでもSnapshotできる
    • ビューのフレームワークと階層など,UIの中でも変更の少ない部分をテストできる
    • よりドメインテストに近いレベルのテストができる
  • iOS SnapshotTestCaseはちょっとおよび腰に感じたけど,SnapshotAnythingはアリだなと感じた

20:05-20:10 5分枠(1) imaizume / iOSアプリのテストを書きたいのに書けないあなたへ

  • スライド
  • まずはすでにテスタブルで書きやすいところから書く
  • 大域変数をリポジトリパターンにするなど,テスタブルにリファクタリングしていく
  • 設計を責務単位にできるようにしていく
  • 良いアプローチだと感じた

20:10-20:15 5分枠(2) AkihisaSengoku / RxSwiftのテスト入門

  • スライド
  • RxSwiftのObservableをテストするために,RxTestTestSchedulerを使った
  • RxSwiftは使ったことがないけど,そんなにObservableに合わせてテストする必要があるんだろうか・・・と疑問に思った
    • @orga_chem さんが言ってのがその解なのかな?(よくわかってない)

20:15-20:20 5分枠(3) kariad / Viewのテストどうやりますか?

  • スライド
  • PresenterのテストでViewのテストを代替することもできる
  • UTならUIControlやSuccinctが便利
  • ROIに応じて適切なテストをしよう
  • ところどころ野菜の絵文字が出てきて美味しそうだった

20:20-20:25 5分枠(4) tobi462 / Swift で ParameterizedTest をやってみた話

  • スライド
  • XCTestではサポートされていないParameterizedTestを自前実装した話
  • 単にリストにテストデータを持たせてforでテストしても,どのテストデータがコケたのかわかりずらい
  • カスタムassertの実装により,テストデータの行を表示できるようにした
  • OSSにした: YusukeHosonuma/SwiftParamTest
  • カスタムassert初めて知った

「思考・論理・分析」を読んだメモ

波頭 亮 著「思考・論理・分析」を読んだメモです.

思考・論理・分析―「正しく考え、正しく分かること」の理論と実践

思考・論理・分析―「正しく考え、正しく分かること」の理論と実践

読む前の考え

  • 人から論理的だと評価してもらうことがままあるが,自分自身が「論理的である」とはどういうことかを言語化できない
  • 「分析」が「調査」という意味程度にしか認識できておらず,何をすれば「分析」と言えるのか理解できていない
  • 本書を読む目標として,「思考,論理,分析とは?」に対して一言で答えられるようになりたい
  • また,今までの論理的思考,分析に足りなかった考えや行動を是正したい

本書の評価

  • 思考,論理,分析の定義を端的に言語化できるようになり,適切な論理,分析のために留意すべき点が理解できた
  • 随所に図解が挿し込まれていて,これが非常に分かりやすかった
  • 個人の知識や特性による思考の違いや,心理が論理の妥当性に及ぼす影響にも触れられていて,単なる理論の解説に終始せず実践的する上での留意を記している点が良い
  • 分析における情報の可視化方法(図解方法)は少々冗長なので読み飛ばしても良い
  • イシューアナリティクスは,おそらく「論理や分析は方法論であって,問題・課題定義を正しく見据えることが大事」という意味として捉えたが,それと論理・分析とのつながりがいまいちよく理解できなかった

活用

  • 他人から「論理的である」と評価されているのは恐らく形式的論理性でという意味合いが強く,自身では客観的妥当性(腹落ち感,本書でいうファクト)はまだ不十分なことが多いのではないかと感じた
    • 因果の強さや直接的連動性(論理展開の距離感)はそんなにズレていないと思う
    • 演繹であれば既呈命題のファクト,帰納であれば観察事象のファクトの根拠をもっとしっかりと用意するようにしていく
  • 今まで「分析=情報収集+構造化(視覚化)」として仕事をしているところがあり,目的設定と合目的的メッセージのアウトプットが欠けていたように思うので,今後は分析にあたっての目的やプロセスの設定を意識する
  • 普段曲がりなりにもディメンションとクライテリアを意識して思考していたが,そのような観点や切り分けの視点を明確に意識していく

先月読んだ本と今月の読書予定(2019年4月)

先月の読書実績

漫画,雑誌は除いています.

実績 Fav
ロウソクの科学
数学ガール
フォーカス・リーディング
思考・論理・分析

今月の読書予定

新規・継続
🆕 あなたもいままでの10倍速く本が読める
🆕 ソフトウェア工学の基礎
🆕 ソフトウェア工学の勧め(上)

先月読んだ本と今月の読書予定(2019年3月)

先月の読書実績

漫画,雑誌は除いています.

実績 Fav
エンジニアの知的生産術
聴く! 技術士二次試験 一発合格のツボ
これからのマーケティングに役立つ、サービス・デザイン入門
Lean UX 第2版
フォーカス・リーディング

今月の読書予定

新規・継続
🆕 思考・論理・分析―「正しく考え、正しく分かること」の理論と実践
🆕 あなたもいままでの10倍速く本が読める