技術書 on tsumari blog

『動かして学ぶ！Flutter開発入門』

Sat, 27 Jan 2024 10:47:32 +0900

モチベーション

iOS、Androidアプリの作り方をあまりイメージできない
- 学生の時にJavaでAndroidアプリ作ったことしかない…
他の言語に触れる機会をつくりたい

メモ

Flutterのプログラミング言語はDart
- Java/Python/JavaScriptの特徴を備える
https://docs.flutter.dev/get-started/install/macos/mobile-ios?tab=vscode
- VSCode Flutter extensions install
  - Download the Flutter SDK
  - Add Flutter to your PATH
  - ~/.zshenv file.:export PATH=$HOME/development/flutter/bin:$PATH
- Configure Xcode
  - sudo sh -c 'xcode-select -s /Applications/Xcode.app/Contents/Developer && xcodebuild -runFirstLaunch'
  - xcodebuild -downloadPlatform iOS
  - sudo xcodebuild -license
- Install CocoaPods
  - brew install cocoapods
- Android Studio install
  - https://developer.android.com/studio?hl=ja
HelloWorld

『モダンJavaScriptの基本から始める React実践の教科書』

Mon, 06 Nov 2023 18:52:25 +0900

モダンJavaScriptの基本から始める React実践の教科書

モチベーション

jQuery全盛期でフロントエンドの知識が止まっている
もともとJavaScriptはWebブラウザ上で複雑な動きを実装する程度のものでしたが、今はフロントエンドだけではなく、バックエンドも実装することができます（Node.jsなど）
スマホアプリ、デスクトップアプリケーション等もJavaScriptで実装できてしまいます
- どうやって？そのイメージができてない…。

メモ

Chapter1 モダンJavaScript の基礎

従来のコードは、手続き的でわかりやすい反面、レンダリングコストの問題が発生しやすかったり、コードが肥大化してくるとどこで何をしているかわからないつらさ→これを解決するのが仮想DOM
- プレーンなJavaScript例
  1
  
  document.getElemenyById("nushida").aapendChild(textElement);
- jQueryの例
  1
  
  $('#nushida).append(textElement);
パッケージマネージャー
- npm
  - npm install [パッケージ名]
  - npm install
- yarn
  - yarn add [パッケージ名]
  - yarn install
- node_modules フォルダが生成される
ECMAScript
- JavaScriptの標準仕様
- 1年に1回更新される「ES2015」「ES2016」
  - ES2015(ES6) が転換期
    - let, constを用いた変数宣言
    - アローファンクション
    - Class構文
    - 分割代入
    - テンプレート文字列
    - スプレッド構文
    - Promise
モジュールハンドラー（webpack）
- jsやcssをひとつのファイルにまとめてくれる
トランスパイラ（Babel）
- JavaScriptの記法をブラウザで実行できる形に変換してくれるもの
- 新しい記法で書かれたJavaScriptを古い記法に変換してくれる
Vite

Chapter2 モダンJavaScript の機能に触れる

let, constを用いた変数宣言

var
- 上書き可能
- 再宣言可能
let
- 上書き可能
- 再宣言不可能
const ※ほとんどの場合で使用
- 上書き不可能
  - オブジェクト型の場合、中の値を変更可能
- 再宣言不可能

テンプレート文字列

従来
- "私の名前は" + name + "です。";
ES2015以降
- `私の名前は${name}です。`

アロー関数

従来

1
2
3


function func1(value) {
 return value;
}

アロー関数（「=> があれば関数」と考える）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


const func2 = (value) => {
 return value;
}

//引数が1つの場合、カッコを省略可能
const func3 = value => {
 return value;
}

//処理が単一行の場合は波括弧とreutnrを省略可能
const func4 = (num1, num2) => num1 + num2;

//カッコで囲んでまとめて省略して返却
const func5 = (val1, val2) => (
 {
 name: val1.
 age: val2
 }
)

分割代入

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23


const myProfile = {
 name: "つまり",
 age: 24,
};
// myProfile.~ が冗長
const message = `私の名前は${myProfile.name}です。年齢は${myProfile.age}歳です。`;

//分割代入を使用。一致するプロパティ名を取り出せる
const { name, age } = myProfile;
const message = `私の名前は${name}です。年齢は${age}歳です。`

//抽出したプロパティ名に別名をつける
const { name: newName, age: newAge } = myProfile;
const message = `私の名前は${newName}です。年齢は${newAge}歳です。`

//デフォルト値指定可能
const { name = "ゲスト" } = myProfile;
const message = `私の名前は${name}です。`

//配列も可。格納順通りに。
const myProfile = ["つまり", 24];
const [ name, age ] = myProfile;
const message = `私の名前は${name}です。年齢は${age}歳です。`

スプレッド構文

要素の展開

1
2
3
4
5
6
7
8


const arr1 = [1, 2];
const summaryFunc = (num1, num2) => console.log(num1 + num2);

//普通に配列の値を渡す場合
summaryFunc(arr1[0], arr1[1]);

//スプレッド構文 内部の要素を順番に展開してくれる
summaryFunc(...arr1);

要素をまとめる

1
2
3
4
5


const arr1 = [1, 2, 3, 4, 5];
const [num1, num2, ...arr2] = arr1;
console.log(num1); //1
console.log(num2); //2
console.log(arr2); //[3,4,5]

要素のコピー、結合

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


const arr4 = [10, 20];
const arr5 = [30, 40];

const arr6 = [...arr4];
console.log(arr4); //[10,20]
console.log(arr6); //[10,20]

//イコールでコピーすると
const arr8 = arr4;
console.log(arr4) //[10,20]
console.log(arr8) //[10,20]
arr4[0] = 100;
console.log(arr4) //[100,20]
console.log(arr8) //[100,20] ←こいつにも影響が出る

map関数

1
2


const nameArr = ["佐藤", "高橋", "つまり"];
nameArr.map((name) => console.log(name));

filter関数

1
2
3
4
5


const numArr = [1,2,3,4,5];
const newNumArr = numArr.filter((num) => {
 return num %2 === 1;
});
console.log(newNumArr); //[1,3,5]

`&&` と `||` について

|| はその左側がfalseなら右側を返す

1
2
3


const num = null;
const fee = num || "金額未設定です";
console.log(fee); //金額未設定です

&& はその左側がtrueなら右側を返す

1
2
3


const num = 100;
const fee = num && "何か設定されました";
console.log(fee); //何か設定されました

Chapter3 JavaScript でのDOM 操作

プレーンなJavaScriptやjQueryでは「この要素を」「高操作する」というように手続き的にDOM操作を行う
- Reactは「宣言的」
HTMLのidやclass、DOMの階層構造とJavaScriptが密接で複雑になりやすく保守が難しかった

Chapter4 React の基本

コンポーネント
- 他のファイルでも使えるように export
- 他のファイルから使う import
- 拡張子は .jsx で作成する
イベント名、CSSプロパティ名すべてキャメルケースになる
- onClickButton
props
- コンポーネントに渡す引数のようなもの
state
- コンポーネントが持つ状態
再レンダリング
- 変更を検知してコンポーネントを再処理する
React Hooks
- useState
- useEffect

Chapter5 React とCSS

CSS Modules

1

import classes from "./CssModules.module.scss";

Styled JSX

1
2
3


<style jsx>{`
/* ここにCSSを書く */
`}</style>

styled components

Emotion

1

/** @jsxImportSource @emotion/react */

Tailwind CSS
コンポーネントライブラリ
- Headless UI
- Chakra UI
- Material-UI
- Semantic UI React

Chapter6 再レンダリングの仕組みと最適化

再レンダリングが起きる条件
- Stateが更新された
- propsが変更された
- 再レンダリングされたコンポーネント配下のコンポーネントすべて
コンポーネントのメモ化（memo）
1

const Component = memo(() => {});

関数のメモ化（useCallback）

1
2
3


const onClickButton = useCallback(() => {
 alert('ボタンが押されました');
}, []);

変数のメモ化（useMemo）

1
2
3


const sum = useMemo(() => {
 return 1 + 3;
},[]);

Chapter7 グローバルなState 管理

バケツリレー
- 下層のコンポーネントで使うために本来不要なpropsを受け渡していくこと
- コードが複雑化
- 再利用しづらいコンポーネントになる
- 不要な再レンダリングが増える
Reactが提供しているContext を使うことでグローバルな値を管理
- React.createContext で Context の器を作成
- Provider で囲む
- コンポーネントで React.useContext を使う
グローバルState管理ライブラリ
- Redux
- Recoil
- Apollo Client

Chapter8 React とTypeScript

TypeScript
- JavaScript で Type(型)を扱えるようにしているもの
1 2 3 4

// : string で指定 let str: string = "A"; str = "10"; //OK str = 10; //NG
- npx create-react-app [プロジェクト名] --template typescript
tsconfig.json にプロジェクトに合わせた設定をおこなうことでルールをカスタマイズ
型を定義することでエラーを防ぐ
コンポーネントにも型を付与する

Chapter9 カスタムフック

任意の処理をまとめて自作のHooks(use〜)を作成する実装
- ロジックをコンポーネントから分離
- 複数コンポーネントでのロジックの再利用
React標準Hooks
- useState
- useEffect
- useCallback
- useMemo
- useContext

『システム運用アンチパターン』

Tue, 24 Oct 2023 18:02:04 +0900

システム運用アンチパターン

モチベーション

「権限を持たない開発者」が私なので、何か出来そうなことがあれば参考にしたい

メモ

1章 DevOpsを構成するもの

1日に30回のデプロイは、あなたの組織の最終目標ではないかもしれません。
変更の内容を理解できない人がたとえ5人承認したとしても,変更の安全性は高まるはずがない
- より多くの承認プロセスといった厳しい制限を増やし続けて安全性を手に入れているつもりになりがち
- このような時に無駄なやり取りこそがDevOpsが解決しようとしているもの
DevOpsはツールについてではなく、チームがどのように一緒に働くかについて考える
- ツールによって可能になることに焦点を当てる
CAMS：cluture（文化）、automation（自動化）、metrics（メトリクス）、sharing（共有）

2章パターナリスト症候群

パターナリスト症候群：ある行動の実行や承認に必要な資格や信頼性を持つのは特定の人物だけである
自動化の価値は何度でも実行できるという点にある
承認プロセスの本当の目的を分析 →自動化で解消する
- 作業が発生していることを必要な人に知らせていること
- 変更を中止する必要があるような、アクションの衝突がないこと
- 変更のリスクが組織にとって許容できるものであること
  - 標準的な変更：すでに確立された変更管理によって事前に承認。やり方や影響を理解している
- レビューが行われていること
- 操作や変更が適切なテストサイクルを経ていること
- 承認者がプロセスの中で何を確認しているか？
  - 承認依頼を即座に却下する原因となるものはなにか？
  - 承認するすべての依頼が満たしているべき条件は何か？
タスクを実行できる人を制限することで、リスクを減らすことができているわけではなく、一部の人にプレッシャーを集中させているだけ
何かが機能していると確認できることは、単にエラーがないと確認できることよりも価値がある
- 知識を共有ことは責任を共有するために必要なこと
  - 責任の拡大に対応するためにはシステムの全体像を一定のレベルで理解する必要がある
電子メールでの通知、通知先のメールアドレスをアプリケーションで管理しない。既存の配信リストを利用
- 通知リストの管理は組織のサービスデスクのプロセスで行うことが出来るはず。
自動化の継続的な改善に取り組む

3章盲目状態での運用

自分たちが開発したシステムが本番でどのように動作するかをより詳細に理解することが求められている
- 本番前の環境で完全かつ徹底的にテストするのは実行不可能になりつつある
- 本番環境で初めてテストされる処理もある
運用の可視化
- メトリクス：システムリソースのある時点での測定値
  - CPU使用率・メモリ使用率など＋アプリケーション用のカスタムメトリクスを開発すること
  - リクエスト数：どのくらいの頻度でこの処理が発生しているか？
  - エラー数：どのくらいの頻度で失敗しているか？
  - レイテンシ：完了するまでにどのくらいの時間がかかるか？
  - 何を測定するか？健全なメトリクスと不健全なメトリクスを分けるものは何か？
- ログ：システムで発生したイベントを記述した、システムが生成するメッセージ
  - 価値あるものとするために
  - 構造化されたログフォーマットにする（JSONのような）
  - 適切なログレベルで記録する
  - エラーメッセージを読む時に生じる疑問を想定する

4章情報ではなくデータ

利用者が値の良し悪しを知ることができるように、ウィジェットに文脈を与える
最も重要な項目が最初に目に入るようにダッシュボードを構成

5章最後の味付けとしての品質

テストピラミッド
- ユニットテスト＞統合テスト＞エンドツーエンドテスト
ユニットテスト
- テスト対象のユニットに含まれないものは、モックやスタブを使用（統合テストで扱うべき）
統合テスト
- 実際のDB接続してデータの書き込みや読み込みを検証

6章アラート疲れ

システムメトリクス（CPU使用率・メモリ使用率など）のアラートを受けても何をしたら良いかわからないことが多い。
- なぜ、どのようにしてその状態になったのかについて何の文脈も与えてくれない
アラートには関連するドキュメントが必要
- アラートを受け取った時に取るべき手順を説明する手順書
- そもそもなぜそれが通知する必要のあるアラートなのかも記載
- アラートメッセージに手順書へのリンクを記載
5分待てば自然に解除されるかもしれない時ではなく、すぐに調査する必要があると確信したときにアラートをトリガする
必ずしも真夜中に誰かを起こす必要はない。発生していることを認知すれば十分なアラートは、メールなどにする

7章空の道具箱

システム全体が自動化を念頭に置いて設計されていないと、自動化の欠如が生じる
運用とは、プロダクトを構築し維持するために必要なすべてのタスクや活動のこと
- サーバの監視
- テストパイプラインの管理
- ローカル開発環境の構築
  - これらが頻繁に繰り返される場合、標準化することが重要
- 自動化によって、権限を与え、スピードを上げ、再現性を高める

8章業務時間外のデプロイ

デプロイのレイヤ
- 機能デプロイ
- フリートデプロイ
- アーティファクトデプロイ
- データベースデプロイ
テストを組織の文化の一部にする
- テストケースのないマージリクエストは不完全なマージリクエストであるという考えを徹底させる
自動化ですべてを確認できるわけではありません。しかし、それは手動のテストも同様です。
- 不確実性を組織が許容できる範囲まで減らすことは可能

9章せっかくのインシデントを無駄にする

人を直接批判してはならない。行動や振る舞いに焦点を当てる。
今となっては明白な事実でも、その場では曖昧だった可能性があることを認識すう
人ではなくシステムを責める

10章情報のため込み：ブレントだけが知っている

組織全体での情報共有が促進されず、あるトピックに関してキーパーソンにすべてを任せるようになったとき
目標は、スタッフが離職しても、組織が活動するために必要な知識を保持すること

11章命じられた文化

「○○を使ったシステムの使用経験が2～3年あること」
- 実際にはどのような経験が必要なのか？

12章多すぎる尺度

組織の目標を意識すると、自分がこれから取り掛かる予定の仕事が違って見えるようになる

感想

後半は飛ばし飛ばし読んだけど…

何を達成したいのか、目的をはっきりさせること

が大事だなってことを改めて感じました。
あとは、エラーメッセージ。「○○処理でエラーが発生しました」…で？どうすればいいの？ の部分を明確化するのも必要ですね。意外とできてない。

『分散システムデザインパターン』

Tue, 17 Oct 2023 10:44:10 +0900

分散システムデザインパターン

モチベーション

コンテナの使い道がわからないから理解を深めるため

メモ

シングルノード
1台のマシン上で動く複数のコンテナについて
- サイドカー
- アンバサダ
- アダプタ
マルチノード
複数のマシンにまたがるコンテナについて
- レプリカがロードバランスされたサービス
- シャーディングされたサービス
- スキャッタ・ギャザー
- ファンクションとイベント駆動処理
- オーナーシップの選出
バッチ処理パターン (MapReduceとは‥？)
- ワークキューシステム
- イベント駆動バッチ処理
- 協調的バッチ処理

感想

ぜんっぜん意味がわからなかった…。
コンテナについての知識不足が一番の原因だと思うけど、翻訳された日本語を読むのが難しいのもあるかもしれない…。
「レプリカがロードバランスされたサービス」だけは辛うじてイメージできた。
いきなりこんな難しいオライリー本を読んで理解しようとするのではなく、いろいろ知らない単語があったのでそれをひとつひとつ調べて理解していくことから始めないとだめかなぁ…。

技術書 on tsumari blog

『動かして学ぶ！Flutter開発入門』

モチベーション

メモ

『モダンJavaScriptの基本から始める React実践の教科書』

モチベーション

メモ

Chapter1 モダンJavaScript の基礎

Chapter2 モダンJavaScript の機能に触れる

let, constを用いた変数宣言

テンプレート文字列

アロー関数

分割代入

スプレッド構文

map関数

filter関数

&& と || について

Chapter3 JavaScript でのDOM 操作

Chapter4 React の基本

Chapter5 React とCSS

Chapter6 再レンダリングの仕組みと最適化

Chapter7 グローバルなState 管理

Chapter8 React とTypeScript

Chapter9 カスタムフック

『システム運用アンチパターン』

モチベーション

メモ

1章 DevOpsを構成するもの

2章 パターナリスト症候群

3章 盲目状態での運用

4章 情報ではなくデータ

5章 最後の味付けとしての品質

6章 アラート疲れ

7章 空の道具箱

8章 業務時間外のデプロイ

9章 せっかくのインシデントを無駄にする

10章 情報のため込み：ブレントだけが知っている

11章 命じられた文化

12章 多すぎる尺度

感想

『分散システムデザインパターン』

モチベーション

メモ

感想

`&&` と `||` について

2章パターナリスト症候群

3章盲目状態での運用

4章情報ではなくデータ

5章最後の味付けとしての品質

6章アラート疲れ

7章空の道具箱

8章業務時間外のデプロイ

9章せっかくのインシデントを無駄にする

10章情報のため込み：ブレントだけが知っている

11章命じられた文化

12章多すぎる尺度