インスタントコーヒー＋塩
これは何？
非技術の話。
仕事のお供のインスタントコーヒーについて。
インスタントコーヒー
仕事中、よく飲みます。
リモート(自宅)で仕事していると特に。
コーヒーマシンでのドリップなんかもしますが、
やっぱり、インスタントコーヒーが手早くて、楽。
インスタントコーヒーに塩？？
そんな中、塩コーヒーなるものを発見。
ひとつまみの塩が、コーヒーの酸味を旨味に変える、とかなんとか。
ということでやってみました。
- 通常量のインスタントコーヒー
- 塩をひとつまみ。入れすぎない。ごく少量
- 砂糖もひとつまみ。塩と同量くらい
上記をカップに入れて、まずは、小さじ1杯くらいの水でインスタントコーヒー粉を溶かし、 その後、お湯を注ぐ。
おいしい、気がします。
結論
手間をかけると愛着が湧く。
つまり、気の持ちよう
1日1杯はこれをやるのが日課になりました。
家族旅行の出発前にちょっとした話題でした。
vue3でMaterialUIを含むCSSフレームワークを導入する：Quasarの利用
使用するUIFramework
導入
今回は上記をViteプラグインとして導入する
インストール
$ yarn add quasar @quasar/extras $ yarn add -D @quasar/vite-plugin sass@1.32.12
main.tsの修正
変更前
vueアプリを作成するのみだった
import { createApp } from 'vue' import App from './App.vue' createApp(App).mount('#app')
変更後
Quasarを追加した
import { createApp } from 'vue' // Import UI Framework import { Quasar} from 'quasar' // Import icon libraries import '@quasar/extras/material-icons/material-icons.css' // Import Quasar css import 'quasar/src/css/index.sass' import App from './App.vue' const app = createApp(App) // Quasarの組み込み app.use(Quasar,{ plugins: {}, // import Quasar plugins and add here }) app.mount('#app')
ViteConfig(vite.config.ts)の修正
変更前
Createしたときから変更なし
import { fileURLToPath, URL } from 'node:url' import { defineConfig } from 'vite' import vue from '@vitejs/plugin-vue' // https://vitejs.dev/config/ export default defineConfig({ plugins: [ vue(), ], resolve: { alias: { '@': fileURLToPath(new URL('./src', import.meta.url)) } } })
変更後
Quasarプラグインの設定を実施
import { fileURLToPath, URL } from 'node:url' import { defineConfig } from 'vite' import vue from '@vitejs/plugin-vue' // import vite-plugin import { quasar, transformAssetUrls } from '@quasar/vite-plugin' export default defineConfig({ plugins: [ vue({ template: { transformAssetUrls } // quaser }), quasar({ sassVariables: 'src/quasar-variables.sass' // quasar }) ], resolve: { alias: { '@': fileURLToPath(new URL('./src', import.meta.url)) } } })
Layoutの導入
https://quasar.dev/layout/layout
LayoutBuillderでレイアウトを作成する
ViewRouterの定義を修正し、Quasarレイアウトで使用するルーティングを作成する
Node.jsでのマルチプロセスについて
この記事は？
Node.jsで大量のデータを扱う必要がある場合に、マルチプロセスでの動作を検討する必要があった。
その時に調べたことのメモ。
実装例などはまた改めて。
調べたこと
そもそもNode.jsでハードウェアリソースを使い切れるのか
No。
Node.jsはシングルスレッドモデルで動作するので、
1つのNode.jsプロセスは1つのCPUコアを最大限に利用することができる。
しかし、マルチコアCPUシステムにおいて、すべてのCPUコアお使用率を上げるには
複数のNode.jsプロセスを並行に動作させる必要がある。
そこでマルチプロセス。
なお、マルチスレッドでは、Node.jsプロセスが複数のスレッドを用いても、
単一のプロセス上での動作なのでマルチコア化での状況は変わらない。
どうやってマルチプロセスを動作させるか。
child_processモジュールやclusterモジュールを使用してマルチプロセスを実現することができる。
Clusterモジュール
特性
Node.jsアプリケーションがシステム上の複数のコアを利用することを可能にする。
これはClusterモジュールにより、プロセスの複製を作成する(forkする)ことで実現する。
その結果、同じポートで複数のワーカープロセスをリスニングさせることが可能となる。
メリット
設定が容易であり、HTTPやTCPサーバのロードバランシングに適している。
また、ワーカープロセスがクラッシュした場合に自動的に新しいプロセスを生成する機能がある。
デメリット
マスタープロセスとワーカープロセス間のコミュニケーションは比較的単純なため、
複雑なタスクの実行には向いていない。また、各ワーカーが独立して動作するため、
プロセス間での状態共有が難しい。
採用されるシチュエーション(使い所)
Webサーバー（例：Express.js）を複数のプロセスで実行し、
各プロセスがシステムの異なるCPUコアを利用するようにすることで、
1つのサーバーで効率的にリクエストを処理する。
これにより、シングルプロセスのサーバーがボトルネックになることを防ぐことがでる。
Child Processモジュール
特性
Child Processモジュールを使用すると、
新しいプロセスを生成し、そのプロセスで任意のシステムコマンドを実行したり、
他のNode.jsプログラムを実行したりすることができる。
また、標準入力（stdin）、標準出力（stdout）、標準エラー出力（stderr）などを通じて
親プロセスと通信することが可能である。
メリット
プロセス間でデータを直接やり取りすることが可能であるため、
複雑なタスクを実行するのに適している。
また、任意のシステムコマンドを実行できるので、他のプログラムやスクリプトを呼び出すことが容易である。
デメリット
エラーハンドリングやプロセスの管理（例：新しいプロセスの生成、終了、通信など）を手動で行う必要があるため、
設定や管理が複雑である。また、Clusterモジュールのような自動ロードバランシング機能は提供していない。
採用されるシチュエーション(使い所)
一連のタスクを並列化して処理するバッチ処理や、
Node.jsからシステムコマンドを実行するために使用する。
たとえば、大量のデータを分割して同時に処理するバッチジョブや、
HTTP Headerについて
この記事は？
経験の浅いチームメンバーから、HTTP Headerについて質問されたときに答えたことをメモ。 REST APIのリファレンスを見ながら、ちょっと困っていた様子。
回答した内容
以下の通り、回答したところ、雰囲気は掴めたようだった。よかった。
外観として
よくある例で、HTTPでの通信(リクエスト/レスポンス)を手紙として表現してみる。 ブウラウザからウェブサイトにアクセスするとき、 ブラウザは実際にはWebサーバーに手紙を書いて送り(GETリクエストを送り)、Webサーバーから手紙（レスポンス）を受け取る。
この手紙には大きく分けて2つの部分がある。
「封筒」と「手紙の中身」。
「手紙の中身」は、実際にWebサイトのコンテンツ（テキストや画像、音声など）です。これはHTTP Bodyと呼ばれる。
一方、「封筒」の部分がHTTP Headerと呼ばれる。 現実では、封筒には送り先の住所や差出人の住所、切手（料金）などが書かれている。 これと同じように、HTTP Headerには、送り先や差出人（どのWebサイトからきたのか、どのブラウザを使っているのかなど）、 どんな形式のデータが含まれているのか（HTML, JSONなど）、データのサイズ、キャッシュの設定など、実際のデータ以外の情報が書かれている。
このようにHTTP Headerは、インターネット通信の際にブラウザとウェブサーバー間で送られる情報の一部であり、 具体的なデータの内容ではなく、データの送り手や形式、設定等の情報を含んでいる部分といえる。
例えば、REST APIでよく登場するのはAuthorizationとContent-Typeなどだと思われる。
これも上記の手紙のコンテキストで解説してみる。
Authorizationについて
これは、その名の通り、認証情報を送るための項目。 特定の情報に対するリクエストに対して、レスポンスを返していいのか、を判断する鍵情報となる。 basic XXXX とか、bearer XXXXX. とか、様々な書き方をするが、これが「認証スキーム」と呼ばれている。
よく使うものだと以下のような物がある。
Basic認証スキーム
Bearer認証スキーム:
Content-Typeについて
このヘッダーは、手紙の中身（HTTPボディ）がどのような形式で書かれているかを伝える Webサイトの情報がどのような形式（HTML, JSON, XMLなど）で書かれているかをブラウザに伝える。 ブラウザはこの情報を基に、正しくデータを解釈して表示する。 その逆で、REST APIの利用者がエンドポイントに対し、リクエストボディを送る場合、どのような形式のリクエストなのか、を Content-Typeとして記述する必要がある
締め
その他にも様々な HTTP Headerがある。 また、独自のヘッダーが定義されているケースもあるので、 利用者側は提供者が求める仕様を確認してリクエストする必要がある。 逆に提供する側の場合は、セキュリティに関連するヘッダー等を付加する必要があるなど、確認・設計する必要がある。
とかなんとか、そんな感じで回答しました。
Vueについて
過去の案件で使用していたものの、なんとなく、でこなしていた間のあるVueについて改めて整理する。 案件対応当時はVue2系だったので、Vue3系を改めてチュートリアルから確認する。 今回の個人開発ではVue3系を使用する想定。
APIスタイル
Vueコンポーネントの作成には2種類のスタイルが利用できる。
Options API
data、methods、mounted といった数々のオプションからなる 1 つのオブジェクトを用いてコンポーネントのロジックを定義する。
<script>
export default {
// data() で返すプロパティはリアクティブな状態になり、
// `this` 経由でアクセスすることができます。
data() {
return {
count: 0
}
},
// メソッドの中身は、状態を変化させ、更新をトリガーさせる関数です。
// 各メソッドは、テンプレート内のイベントハンドラーにバインドすることができます。
methods: {
increment() {
this.count++
}
},
// ライフサイクルフックは、コンポーネントのライフサイクルの
// 特定のステージで呼び出されます。
// 以下の関数は、コンポーネントが「マウント」されたときに呼び出されます。
mounted() {
console.log(`The initial count is ${this.count}.`)
}
}
</script>
<template>
<button @click="increment">Count is: {{ count }}</button>
</template>
Vue2系で使用していた感じ。
Options API の考え方は、「コンポーネントのインスタンス」(サンプルに見られる this) を中心とするもの。
Composition API
Vue3.0から導入された。 ReactのHooksにいた概念で、コンポーネント内のロジックをComposableな関数に抽出し、再利用可能としている。
通常、<script setup> と組み合わせて使用する。
setup という属性を付けることで、Vue にコンパイル時の変形操作を実行してほしいというヒントが伝えられる。
<script setup>
import { ref, onMounted } from 'vue'
// リアクティブな状態
const count = ref(0)
// 状態を変更し、更新をトリガーする関数。
function increment() {
count.value++
}
// ライフサイクルフック
onMounted(() => {
console.log(`The initial count is ${count.value}.`)
})
</script>
<template>
<button @click="increment">Count is: {{ count }}</button>
</template>
リアクティブな状態変数を関数のスコープ内で直接宣言し、複数の関数の組み合わせによって状態を組み立てて複雑な処理を扱おう、という考え方が中心にある。
はじめに
エンジニアとしてのキャリアを積み重ねるにつれて、私の役割は年齢と共に変化してきました。 具体的な実装や環境構築から一歩引いた位置で、プロジェクトの管理や進行に重点を置くようになり、 さらに抽象度の高い情報を扱うことも増えてきました。
また、アサインされるプロジェクトにおいて選択される技術スタックは必ずしも魅力的なものばかりではなく、 プロダクトの仕様についても、売り込みの観点での推進優先度などの影響を受けることが多くあります。
上記をストレスと感じながら、こなす仕事として、エンジニアリングを捉えている自分自身を さらにストレスと感じる、という悪循環に陥っている感覚がありました。
この状況を変えたいと思い立ち、継続的にINPUT・OUTPUTする習慣を意識するため、 個人的なプロジェクトを開始することにしました。
これから、こんなようなことをしていきたいと思っています。
- 個人開発
- 具体的なプロダクトをリリースする
- 収益化についてはいったん検討しない(作ることが目的と割り切る）
- ナレッジの蓄積
- 上記の個人開発の記録を本ブログに蓄積する
- 検討したことや困ったことを記録することで「やったこと」を見えるかする
- 「なにもやっていなかったなー」という後悔の感情への対策
- 誰かの役に立てばという情報共有
- 上記の個人開発の記録を本ブログに蓄積する
・・・といろいろ書きましたが、まずは継続する、ということが重要と思ってます。 ひとりごと・自分用のメモから始めていきます
２０２３年７月１２日追記
なんか、いろいろと小難しく書いてしまいましたが、 その後の更新のハードルを挙げてしまいました。
継続する、が目的ということを前面に押し出さなければ、ということで、 気楽に書いていくことにしました。
誰のためにもならないような内容でもいいから、継続、継続。
