JavaScript：値渡し？参照渡し？
コンポーネントを純粋に保つ – Reactのチャレンジ問題の最後でハマってしまいました😅ハマったのは下記コード：
export default function StoryTray({ stories }) {
let storiesTray = stories;
storiesTray.push({
id: "create",
label: "Create Story",
});
return (
<ul>
{storiesTray.map((story) => (
<li key={story.id}>{story.label}</li>
))}
</ul>
);
}
問題なのは let storiesTray = stories; の部分で、ここが値渡しでやっていると勘違いして、結構詰まりました、、、
JavaScript ではプリミティブは値渡しで、オブジェクトは参照渡しになるということなので、上記は storiesTray.push で意図せず呼び出し元のオブジェクトを更新するようになってしまっていました😅
回避するには StoryTray コンポーネント内にローカルインスタンスを用意してあげればいいので、let storiesTray = stories.slice() として配列をコピーしてあげれば良い。
export default function StoryTray({ stories }) {
let storiesTray = stories.slice();
...
}
配列操作では、使用するメソッドが破壊的かどうかを覚えておくことが有効とのこと。
破壊的かどうかについては、[JavaScript] Arrayメソッド破壊・非破壊チートシート - Qiitaの記事がとても参考になりました👀
React：純関数とは
純関数
純関数とは『計算だけを行い、他には何もしない関数のこと』で次の特徴がある。
- 呼び出される前に存在していたオブジェクトや変数を変更しない
- 同じ入力を与えると、純関数は常に同じ結果を返す
純関数は数学で言うところの f(x) = x と同じで入力が同じであれば常に同じ出力となるものと言える。
コンポーネントを常に厳密に純関数として書くことで、コードが大きくなるにつれて起きがちな、あらゆる種類の不可解なバグ、予測不可能な挙動を回避することができるようになるらしい。
React はコンポーネントが純関数であると仮定しているため、入力が同じであれば常に同じ JSX を返す必要がある。
なぜ純関数が重要なのか？
- 入力値が同じなら同じ結果を返すので、一つのコンポーネントが多数のユーザリクエストを処理できる
- 入力値が変化しない場合、レンダーをスキップできるためパフォーマンスを向上できる
- 深いコンポーネントツリーのレンダーと途中に入力値の変化を検知したら、そのタイミングで新しいレンダーを始めることができる
レンダー更新とコンポーネントを使う側へのメリットが多いと理解🤔
当該コンポーネントを利用する側のメリットとしては、入力値のみを気にしておけば、使用する際に変な影響を受けないということなのかと思った。
参考
React：配列のアイテムに key が必要な理由
アロー関数は直後の式を返す
あまりちゃんと意識できていなかったんですが、アロー関数は直後の式を自動的に返す。{} で囲まれる場合は、ブロック形式の関数とみなされるので return を書く必要がある。
// {} がない場合は自動的に返されるので return は不要
const listItems = chemists.map((person) => <li>...</li>);
//{} で囲む場合は関数となされるので return が必要
const listItems = chemists.map((person) => {
return <li>...</li>;
});
配列のアイテムに key が必要な理由
React が配列のどの要素がどのコンポーネントに対応するかを判断するために key は必要。それにより各アイテムを正しく更新できる。
具体的なシーンとしてはソートや削除といったときで、配列内の構成が変わっても key により React は何が起こったかを推測でき、DOM ツリーに正しい反映ができる。
const listItems = people.map((person) => (
<li key={person.id}>
<h1>{person.name}</h1>
<p>{person.bio}</p>
</li>
));
複数の DOM ノードをレンダーするときには、<div> でグループ化するか、<Fragment> を使用する。フラグメントは DOM から消えるので <h1>, <p> というふうにフラットなリストを生成できる。
import { Fragment } from "react";
// ...
const listItems = people.map((person) => (
<Fragment key={person.id}>
<h1>{person.name}</h1>
<p>{person.bio}</p>
</Fragment>
));
キーのルール
- キーは兄弟間で一意（区別つかなくなる）
- キーを変更してはいけない（
keyの目的を失う）
参考
暗号と認証の基礎
暗号と認証のしくみと理論がこれ1冊でしっかりわかる教科書を読んで重要だと思ったことのまとめです。
本全体への所感
- 絵が多めでイメージしやすく理解しやすい
印象に残った点
情報セキュリティとは
- 情報セキュリティとは機密性・完全性・可用性を満たすことである
- 情報の重要性に応じて真正性・責任追跡性・否認防止性・信頼性などの要件を考慮する
- 暗号技術は主に機密性・完全性・真正性や否認防止性を満たすために利用される
各要件と暗号技術がどう関連付けられているかを意識していなかったので、上記の内容で暗号技術と情報セキュリティの関わりを認識できました。
可用性（認可された人が必要な時にアクセスできる）や信頼性（システムが不具合なく正確に動作していること）といったインフラ的なところ以外のところに関わると覚えておけばよさそうと思いました。
リバースブルートフォース攻撃
パスワードを固定して ID を順に試す攻撃があります。リバースブルートフォース攻撃と言います。
全パターンのパスワードを試すブルートフォース攻撃は知っていましたが、ID を固定するパターンは知らなかったので勉強になりました。
リバースブルートフォース攻撃の一種の パスワードスプレー攻撃 では、ユーザIDリストに対して、同じパスワードを順次試していき、ユーザリスト一巡したら、次のパスワードを試す攻撃のこと。パスワードを再度試す際に連続的に攻撃するわけではないので、対策しにくい攻撃らしい。
参考
React：JSX でのマークアップ概要
React がマークアップとレンダリングロジックを混在する理由
ウェブサイトは、コンテンツを HTML、デザインを CSS、ロジックを JavaScript で書くというのが一般的で、通常は下記のように別ファイルで管理していた：
| HTML | JavaScript |
|---|---|
 |
 |
上記は静的な情報を扱うだけであれば良かったが、近年ではロジックがコンテンツの中身を決めるようになったため（動的に情報が変わる）、JavaScript が HTML の領分も担当するようになった。そういった背景から、React ではロジックとマークアップをコンポーネントに書くようになっているらしい。
レンダリングロジックとマークアップをコンポーネントに書くことで、編集時の同期が保証され、関係のないコンポーネントの影響も受けずに更新できるようになる。
JSXのルール
単一のルート要素を返す
複数の要素を返す場合には、単一の親タグで囲んで返す。タグには、
<div></div>や<></>(フラグメント) が使える。
単一要素しか返せないのは JSX の裏では JavaScript オブジェクトへの変換が動いており、関数から複数のオブジェクトを返す時は配列等でラップする必要があるのと同様、JSX では別タグでラップする。全てのタグを閉じる
明示的にタグを閉じる
（ほぼ）すべてキャメルケース
JSX は JavaScript へ変換され、JSX の属性は JavaScript オブジェクトのキーになる。一方で JavaScript の変数名の制約を受ける（
-を含めなかったりやclassのような予約語は使えない）
それを回避するために React では属性名をキャメルケースで書く。
コンバータの利用
HTML から JSXへのコンバータ もあるので、ぱっとやる時にはそれも活用可能。
参考
衛星測位について学ぶ
衛星測位について発見のあった内容をつらつらと書いていきます。
キーワード
RTK による位置測位の仕組み
RTK(Real Time Kinematic) 測位は、座標値がわかっている点に1台の受信機とアンテナを固定設置しておき（基準局）、位置を計測したい側（移動局）と合わせて２箇所で得られた観測データからリアルタイムに即位する手法。 搬送波を観測できる受信機と、基準局の観測データを移動局まで送る伝送手段（無線か、モバイルルータによるIP通信）を組み合わせます。
RTK では基準局と移動局で同じ衛星の搬送波を受信し、互いの距離が『何波長＋何度の位相』離れているかで相対距離を算出する。基準局の正確な位置がもとまっている前提のため、相対距離を求めることで移動局の位置も求められる。
イメージ的には次のような感じ。
衛星測位には４機以上が必要
衛星測位を利用した測位では、一般に４機以上の衛星を必要とします。その理由は、自身の位置である (x, y, z) の３つの未知数以外に受信機の時間誤差を推定しなければならないため
位置測位には複数の衛星が必要と聞いたことがあったけど、きちんとした背景を知っていなかったので勉強になった🧐自身の座標系の位置と時間補正を調整するために４機以上が必要ということらしい。
自分で基準局を設置する方法
基準局を自分で設置する場合のアンテナの座標を求める方法 アンテナの座標を求めるためには、次のような方法があります。
- 国土地理院から提供される電子基準点情報を使う
- 最寄りの基準局の情報を使う
- 自己測量を行う
自己測量は、長時間にわたって単独即位を行い、その平均値を取る方法です。正しい数値を得るためには、最低でも24時間は測位を継続します。
Google Map で、なんとなくの緯度経度を設定していたけど、精度的な意味で『結構アバウトだよね』と感じてましたが、長時間測位で平均から求めるのがベターということを学べました。
Google Map から設定する方法だとそもそも高さ情報がないという問題もあるとのことでした。そりゃそうだなと、、、😅
『干渉』や『なりすまし』に問題あり
地上で受信する衛星からの信号レベルは極端に低いです。これは衛星測位の弱点ともいえます。干渉やなりすましといた問題があります。
衛星測位も『干渉』や『なりすまし』が可能らしい🤔実際に GPS 専用電波妨害機や GNSS シミュレータといったものもあるが、こうした電波を飛ばすことは電波法に抵触するため公共空間では使ってはいけないとのこと。
標高はジオイドからの高さ
高さは次のように構成されるらしい。
参考
チームをアジャイルにしていくために
カイゼンジャーニーを読んで、心に響いた内容をつらつらと書いていきます。
キーワード
小さく試みる
『許可を求めるな謝罪せよ』という言葉を胸に、まずは”小さく試みる”ことだ。許可が下りるまで待っていたら機会を失ってしまう。失敗してしまったら謝ればいいんだ。
現職においても『半ば諦め』のようなことを感じることが多いですが、変化を起こすには『まずは自分でやってみる』という精神が大事で、その際に上記の言葉はとても勇気づけられるなと思いました☺️
Start with why(目的から始めよ)
『Start with why(目的から始めよ)』
『なぜ（Why）』から始めて、それを『どうやって（How）』実現するのか。そのために『何を（What）』やるのか
プロジェクトやプロダクト作りを始める場合には、WHYから問い直して始める。スクラムのインセプションデッキの一つ『われわれはなぜここにいるのか』は、チームにミッションや目的の共有を明確にすることができる。ここが定まっていないと、何のために開発するのかがわからず、思考や行動に迷いが生じる。
『Start with why』 を表現した有名な図に ゴールデンサークル があり、サークルの中心から考える。
むきなおりで現在を正す
- ふりかえりは、過去を顧みて現在を正す
- むきなおりは、進むべき先を捉えて現在を正す
ふりかえりは、それまでの行動に対するふりかえり。よって進むべき方向が正しいかどうかの見直しをしていない。ビジネスのゴールが時々で変化するものに対しては、ゴールを見直す必要がある。それが『むきなおり』らしい。
将来を見据えて、今何をすべきかを思考する活動であり、重要な活動と言えそう。
星取表でチームスキルの見える化
ビームビルディング三種の神器
星取表（スキルマップ）は聞いたことがなかったけど、チームメンバーがどんなスキルを持っているかを見える化する道具で、チームの弱みや強みを把握し、スキルアップの方向性等を定めるのに役立つ。
言われてみれば会社標準のものが現職でもあることを思い出した。ただ、プロジェクトごとに成果へ直結するスキルは異なるので、プロジェクトごとに設定することが重要とのこと🤔そりゃそうだと思いました👀
ヒーローはチーム
スクラムに一人のヒーローはいらない。ヒーローはチームなんだ。
いつまでもスクラムマスターに頼ってはいけない。
アジャイル開発は『自律的な組織』の状態を指しているので、もっともだなと思いました。チームが成長していって自己組織的に開発を進められるようになっていくのが目指す姿のため、ずっとスクラムマスターにおんぶに抱っこじゃダメなんだなと。一人のヒーローではなく、『ヒーローはチーム』胸に刻んでおこうと思いました。
カンバンで問題をみえる化する
仕事の流れに注目するのがカンバンと言えます。たくさんの開発するべき機能が、あるステージでつっかえていて、流れが滞っていたり、やり方や手戻りがあったら、それは何かのボトルネックが起きているサインなんです。
確かにカンバンで進めている時に、レビューステージにIssueがたくさん溜まってしまった時があったんですが、それが見える化されていることで『ふりかえり』の時にどうすればいいかをチームで話し合うことができました。まだまだ完璧ではないけれど、なんとなくアジャイルな進め方ができつつあるのかなと思い、少し嬉しくなりました☺️
リーダーズインテグレーション
リーダーズインテグレーションとは、リーダーとメンバーの間の信頼感を醸成するためのワークショップ
現職においてもリーダーがちょくちょく変わるんですが、その度に信頼関係がゼロからはじまり、いつも『出だしが悪いよな』と感じていました。今回紹介のあったリーダーズインテグレーションは、リーダーやチームとしての一体感が欠落している場合に有効な手と言えるので、今後提言してみようかなと思います💪
バッファマネジメント
プロジェクトというのは非常にたくさんの種類の不確定要素を持っています。その不確かさに対するバッファなので、いくら時間をかけて精度を上げようとしたところで限界があります。
パーキンソンの法則『仕事の量は完成のために与えられた時間を満たすまで膨張する』で言われているように、精密に見積もったとしても結局のところ、時間を使い果たすように仕事は進められてしまうことが多い。
そこで CCPM（CriticalChainProjectManagement）という考え方がある。これは各タスクに対してバッファ期間を設けるのではなく、各タスクにバッファとして考えていたものを全てまとめた時間の半分をプロジェクト全体でのバッファとして利用するというもの。
各タスクで遅れが出そうな場合は、全体のバッファを使用していく。ここのバッファを持たないことで各タスクの期限が早くやってくる。それにより先延ばしという現象を回避しやすくなる。
CCPM をうまく回すにはバッファを使ってもいいという空気感と効率的に使えているかをチームで確認するという点にある。
ジョブ理論
ジョブ理論では、顧客はやり遂げたい何かがあり、そのためにプロダクトやサービスを「雇用」していると考えます
本当に顧客にとって価値あるものを提供するためには、顧客から言われたものを、ただ言われた通りに作るのではなく、課題や目的を明らかにし、適用可能な課題解決策を提案することが求められる。
例えば、『仕事のリフレッシュ』は、『タバコ休憩』を雇用している状況もあれば、『同僚とのコーヒーブレーク』を雇用するといった様々な手段がある。顧客にとって本当に価値あるものをユーザ背景に従って提供する必要がある。
