表題の通りです。ググっても出てこなかったので備忘として残します。
ビルドを通すだけであれば"org.aspectj"のみ取り込めば良いのですが、実際にAOPを動かす（JoinPoint・PointCutの条件を満たした時にAspectクラスのメソッドを実行させる）ためには、"spring-boot-starter-aop"も取り込む必要があります。
TypeScript+Node.jsのHelloWorld
TypeScriptは、JavaScriptを拡張して作られた言語です。
JavaScriptを大規模開発で採用する場合、実行時のエラーが頻発することで生産性や品質が悪化する恐れがあります。
JavaScriptのこの問題を、ビルド時のエラー判定を強化することで解決した言語が、TypeScriptです。
ビルド時のエラー判定を行った上でJavaScriptのコードを生成するため、JavaScriptとの互換性も高いです。
TypeScript独自の代表的な文法の一つが変数の型指定であり、この文法によりビルド時に型相違のエラー判定を行うことができます。
今回の記事は、このTypeScriptを、Node.jsを用いてWindows環境上で試しに動かしてみます。
環境構築の参考になれば幸いです。
「とにかくTypeScriptを動かしてどのような挙動になるのか確認したい」という場合にも参考になると思います。
■前提
・OS
Windows11
・実施日
2022年12月29日
・Node.jsのバージョン
18.12.1
■Node.jsインストール手順
１．Node.jsの公式サイトにアクセスする。
https://nodejs.org/ja/
２．「18.12.1 LTS」をクリックする。
※バージョンはその時々で変化しますが、個人で試すだけなら推奨版で良いです。
３．「node-v18.12.1-x64.msi」を実行する。
４．Node.jsのインストール画面が出てくるので、デフォルト設定でインストールする。
※「Install」押下後、インストールするか尋ねるポップアップが出たら「はい」を押下
■Node.jsコマンドプロンプト起動手順
１．「Node.js command prompt」を探して起動。
■TypeScriptインストール手順
１．「Node.js command prompt」を起動する。
２．下記コマンドを発行し、インストールを実行。
npm install -g typescript
３．インストール処理の進捗状況が表示された後、下記のような表示が出ればOK。
added 1 package, and audited 2 packages in 4s
found 0 vulnerabilities
npm notice
npm notice New major version of npm available! 8.19.2 -> 9.2.0
npm notice Changelog: https://github.com/npm/cli/releases/tag/v9.2.0
npm notice Run npm install -g npm@9.2.0 to update!
npm notice
■実行確認（Hello World）手順
１．「Node.js command prompt」を起動する。
２．下記コマンドを発行し、任意のフォルダ（今回は「C:\tmp\」）に移動する。
cd C:\tmp\
３．下記コマンドを発行し、「hello.ts」という名前のファイルを作成する。
type nul>hello.ts
４．任意のフォルダに作成した「hello.ts」を、エクスプローラ上から開く。
※VS Code、サクラエディタ等の任意のエディタにより開く。
５．「hello.ts」に下記（プロンプト上に文字列を出力する命令）を入力して保存。
let msg: string = 'Hello World!';
console.log(msg);
６．下記コマンドでTypeScriptのインストール先を確認
npm root -g
７．下記コマンドでJavaScriptへ変換。「hello.js」が生成される。
node ６で確認したフォルダパス\typescript\bin\tsc hello.ts
８．下記コマンドで「hello.js」を実行、「Hello World!」と出力されればOK。
node hello.js
■参考
・生成されたhello.jsは以下の通りであり、JavaScriptの文法への置換を確認できます。
var msg = 'Hello World!';
console.log(msg);
ReactのHelloWorld
フロントエンドのSPA（シングルページアプリケーション）向けのJavaScriptのライブラリであるReactを使用して、HelloWorldを書いてみました。
Reactで何かしらの記述の挙動を確認したい時のベースとして使いやすいようにしています。
今回は、下準備無しで動かせるように、CDNサービスを使用しています。
インターネット接続していることが前提となりますが、UNPKGで公開されているパッケージをscriptタグ等で指定することで、ローカルにライブラリを落とすことなくライブラリを使用することができるようになります。
SPAらしいHelloWorldになるように、内部状態の変化に応じてHelloWorld!の文字が出たり消えたりするような実装を試しています。
なお、ブラウザのバージョンが古くても最新のJavaScriptの書き方で動くように、Babelと呼ばれるライブラリも別途取り込んでいます。
■前提
・Reactのバージョン
v17
・Babelのバージョン
v6
■実行確認（Hello World）手順
１．任意のフォルダで"hello.html"という名前のファイルを作成する。
２．「hello.html」に下記を入力してUTF-8で保存。
<!DOCTYPE html>
<html lang="ja">
<head>
<meta charset="UTF-8">
<title>React - Hello world!</title>
<script
crossorigin
src="https://unpkg.com/react@17/umd/react.development.js"
></script>
<script
crossorigin
src="https://unpkg.com/react-dom@17/umd/react-dom.development.js"
></script>
<script
crossorigin
src="https://unpkg.com/babel-standalone@6/babel.min.js"
></script>
</head>
<body>
<div id="helloContainer"></div>
<script type="text/babel">
// useStateの取り込み（CDNサービス使用時の宣言）
const { useState } = React;
const Hello = () => {
// 状態管理する変数の宣言
// const [状態変数, 状態を変更するための関数] = useState(状態の初期値);
const [checkedValues, setCheckedValues] = useState("");
// チェックボックスの状態が変化した場合の処理
// e.target.valueは状態が変化したチェックボックスが持つ値
// （今回はボックスを１つしか定義しないため判定に使用する必要はないが、
// 複数定義する場合はどのボックスの状態が変化したかを判定するのに必要）
// checkedValuesが初期値なら"Hello World!"をセット、そうでなければ初期値
const handleChange = (e) => {
if (e.target.value === "HelloValue") {
if (checkedValues === "") {
setCheckedValues("Hello World!");
} else {
setCheckedValues("");
}
}
};
return (
<label>
{/* チェックボックスの定義 */}
<input
type="checkbox"
value="HelloValue"
onChange={handleChange}
/>
{/* checkedValuesの値を表示 */}
{checkedValues}
</label>
)
};
const domContainer = document.querySelector("#helloContainer");
ReactDOM.render(<Hello />, domContainer);
</script>
</body>
</html>
３．「hello.html」をブラウザから開く。
※今回はChromeで開きます。
初期状態では以下のように何も表示されませんが
チェックボックスをチェックすると「Hello World!」と表示されます。
ボタンをクリックしてイベントを飛ばしたり、リロードしたりすることなく、画面で変更された内部状態をリアルタイムに画面上に反映することができています。
2023年からの更新予定について
来年からこのブログのあり方が変わるため、事前に連絡です。
私情なのですが、来年から私の働き方が変わります。
これまでは、自社の若手を率いて客先に常駐したり仕事を請け負ったりする働き方でした。
その中で、若手に教育を行う機会があったため、教育の一環としてこのブログで私の知識やスキルを共有していました。
来年からは、私が一人で客先に常駐する働き方となります。
私の技術力が向上したこと、また自社の若手を率いることが無くなることにより、これまでよりも高度な仕事を担うことになる予定です。
このブログを開設して以来、定期的にブログを更新する形でアウトプットに努めていましたが、来年からはインプットに使う時間が増えることが予想されます。
そのため、来年からはブログの更新が不定期となる見込みです。
また、これまでは教育のための記事が多かったのですが、今後は自分の思考をまとめるための記事が増える見込みです。
このブログの読者の方々の期待に沿わない決断になってしまったかもしれません。
しかし、来年からは違う形で仕事に邁進していきたいと思いますので、見守っていただけると幸いです。
比喩表現により納得感のある説明をする
仕事を進める中で、誰かを説得しないといけない場面があります。
ここで、社内や社外の事情を話したり、論理立てて説明したりすることで納得してくれれば良いのですが、それだけでは納得されにくいこともあります。
このような場面で有効な手段の一つが、比喩表現の利用です。
比喩表現を用いて、相手が受け入れやすいものに例えることで、納得感のある説明を行うことができます。
----
例えば、自分が個人向けオークションサイトの保守開発の上長であるとします。
ここで、部下の一人が、商品に対して高い値付けがされることを快く思っておらず、それを変えることも適切ではないとします。
この部下の疑問を解消しなければモチベーションの低下を招くので、なんとかして疑問を解消したい所です。
社内外の事情や論理的な説明で疑問を解消するのが難しい場合、比喩表現を用いて
「これは人力によるダイレクトプライジングのようなものである。ダイレクトプライジングは公的な交通機関でも取り入れられており、今では市民権を得つつある。」
という説明をすることで、受け入れられる可能性が高くなります。
なお、今回の記事の趣旨からは外れますが、「自分も昔は同じように思っていた」と部下の疑問に共感を示すことで、より受け入れられやすくなるでしょう。
プログラムリリース時のコンティンジェンシープラン
コンティンジェンシープランとは、想定外の事態が起きた時に備えて事前に定めておく対応策のことです。
この記事では、プログラムのリリース時に定めておくべきコンティンジェンシープランについて、具体的に述べていきます。
----
プログラムのリリース作業は、事前に定められた一定の時間内に、プログラムを入れ替えて稼働確認を行う、という作業です。
例えば、特定の日の22:00-24:00をメンテナンス時間として事前に通知し、メンテナンス時間中はシステムの開放を止めてプログラム入れ替えと稼働確認を行う、という具合です。
リリース作業時における主な想定外の事態は、稼働確認での不具合の発見です。
不具合を発見した時に備えて、以下のようなコンティンジェンシープランを事前に用意しておくべきです。
１．切り戻し作業の手順の用意と実施
新しくリリースしたプログラムに不具合が存在していたとしても、リリース時間内に元のプログラムに戻して稼働可能な状態に戻せば、利用者にはリリース前と変わらない機能を提供することができます。
リリースによるサービス水準の低下を防ぐという意味では、最も確実な対応策となります。
ただし、切り戻し作業自体にリスクが存在する（切り戻し作業を失敗し、戻せなかったり、より自体が悪化したりする可能性がある）ため、切り戻し作業を行う可能性があるのであれば、作業手順を事前に確立させる必要があります。
データの移行を伴う場合は、データの事前のバックアップとその戻しも必要になるので、特に注意が必要です。
２．サービス水準の低下を許容する方針の検討
切り戻し作業を行うのが最も確実ではあるのですが、発見された不具合が軽微なものであれば、その不具合を許容した上で戻さずにリリース作業を完了させる手もあります。
また、法律改正への対応のような、外部の変更に応じた対応の場合は切り戻し作業の実施自体が難しくなる（自社の判断だけでは切り戻し作業ができなくなる）ため、この場合も不具合を許容、最悪の場合は機能制限を加えた上でリリース作業完了させる必要が出てくることが多いです。
不具合を許容するかどうかの判断はその時々で柔軟に判断する必要がありますが、それを誰が判断するのか（作業時の責任者は誰なのか）は事前に決めておくべきです。
また、機能制限のような作業を行う可能性があるのであれば、その作業手順も事前に確認・確立させる必要があります。
３．切り戻し等の作業を開始するタイミングの確認
稼働確認で不具合が発見されたとしても、リリース時間内に修正できるのであれば、修正するに越したことはありません。
また、切り戻しを行うのかサービス水準の低下を許容するのかの判断が必要になる可能性もあります。
このように、不具合が発見されたとしても、切り戻しの行わない、という判断をすることがあります。
しかし、切り戻し作業にも時間が必要なので、その判断をいつまでに行うのか、ということは事前に決める必要があります。
例えば、24:00までにサービスを再開する必要があり、切り戻し作業に（余裕を見て）30分かかる場合、切り戻しを行うかどうかの判断は23:30までに行う必要があります。
23:30までに修正が完了しなかったり、サービス水準低下の許容の判断ができなかったりするのであれば、安全側に倒すために23:30を迎えた瞬間に切り戻し作業を開始するべきです。
統計データを読み取る際に注意するべきこと
物事を定量的に語る上で、統計データは大きな武器になります。
しかし、この統計データが正確に計測されたもの、かつ作為的に計測されていないものであるとしても、解釈次第で誤った結論に至ってしまうことがあります。
この記事では、誤った結論に至ってしまう以下の２点の要因について、説明していきます。
１．前提条件の読み誤り
２．因果関係の読み誤り
----
【前提条件の読み誤り】
これは、統計データを実験で得ている場合に特に注意が必要になります。
例えば、ある画面で検索ボタンを押して結果が表示されるまでの時間が、実験により平均1秒であることがわかったとします。
しかし、実際に運用した際に平均1秒で結果が表示されるとは限りません。
実際の運用では、複数ユーザーによるシステム利用や裏で動いているバッチ処理により、危機に負荷がかかっている可能性があるからです。
この負荷により、2秒や3秒、あるいはそれ以上かかる場合が出てきます。
このような実験を行う際は、実運用に条件を近づけることが肝要になります。
例えば、疑似的に不可をかけるプログラムを裏で動かす、人を集めて同時にシステムを利用してもらう、といった、条件を近づけるための工夫が重要になります。
----
【因果関係の読み誤り】
これは、現実の活動から統計データを得ている場合に特に注意が必要になります。
例えば、交通事故注意の看板がある交差点では交通事故が多い、という統計データが得られたとします。
この統計データをもって、「交通事故を減らすためには交通事故注意の看板を減らすのが良い」という結論を導き出すのは危険です。
交通事故注意の看板の有無と交差点の交通事故の件数が関連している理由として、「交通事故注意の看板があると交通事故が増える」という理由以外にも、「交通事故が多い交差点に交通事故注意の看板を置いているため」という逆の因果関係の理由も考えられるからです。
看板には事故を減らす効果があり、事故を減らしてもなお看板があっても交通事故が多い、ということかもしれません。
（むしろ、そう考える方が自然でしょう）
このように、得られた統計データから因果関係を導き出したい場合は、そのような統計データとなった背景に考えを巡らせる必要があります。
