OmniAICreator/Qiita-1.07M huggingface dataset:
Windows11 PC 初期化の際にインストールして引っかかるもの

# この記事について
Windows PCは何回か初期化することがあるので、初期化が終わったあと種々の調整で引っかかるところを記録しておく
# 入力の方法について
- キーボードのレイアウトが日本語になっている時の変更の仕方
下図の部分を変更する。
![qiita_keyboard layout.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/513172/c598239f-2795-081f-c271-c6f80525d071.png)

- Google日本語入力において、ctrl + spaceで日本語英語を変更する方法
https://raspi.ryo.sc/google_ime_ctrl_space_onoff/

# gitの環境設定
下記のサイトを参考
https://qiita.com/T-H9703EnAc/items/4fbe6593d42f9a844b1c

# pythonのインストール
https://sukkiri.jp/technologies/processors/python/python%E3%81%AE%E3%82%A4%E3%83%B3%E3%82%B9%E3%83%88%E3%83%BC%E3%83%AB%E6%96%B9%E6%B3%95windows%E7%B7%A8.html

# pyenvのインストール
pyenvをインストールした後、pyenvコマンドが認識されないエラーが発生した。その際下記の記事を参考にした。
https://qiita.com/probabilityhill/items/9a22f395a1e93206c846
またWindowsによる実行ポリシーのエラーが発生したので、chatGPTによる提案により修正を行った。

# PowerShellによるスクリプト実行ポリシー
エラーの原因はエラーメッセージの内容から、Windows における PowerShell のスクリプト実行ポリシーが 「Restricted」 または 「AllSigned」 に設定されていることによって発生しているらしい。この設定では、未署名のスクリプト（pyenv.ps1など）の実行が禁止されるようだ。

### 解決方法
#### 実行ポリシーの変更
PowerShell の実行ポリシーを変更することで解決。

手順:

- 管理者として PowerShell を開く。
次のコマンドを入力し、実行ポリシーを変更:

```shell:powershell
$ Set-ExecutionPolicy -Scope CurrentUser -ExecutionPolicy RemoteSigned
```
このコマンドは、現在のユーザーのスコープで、未署名のローカルスクリプトを許可する設定。

確認のプロンプトが表示された場合は、「Y」を入力して実行を許可。

- 確認
実行ポリシーが正しく設定されたか確認するには、以下を実行:

```shell:powershell
Copy code
Get-ExecutionPolicy -Scope CurrentUser
```
結果が RemoteSigned であれば設定は成功。

- 設定を反映する
PowerShell を閉じて再度開き、再び pyenv を試す。これで成功しているはず。

# PowerShellでAnacondaを使えるようにする
https://hisuiblog.com/python-anaconda-powershell/
女性エンジニアへのエール

![women.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3942018/58269c02-d3a8-ccac-de8e-97510722ee36.png)
### 技術に性別はなく、能力こそが力です
IT業界では、技術力こそがエンジニアの価値を測る重要な基準であり、性別は決してその判断基準ではありません。以前、私は女性エンジニアの方と共にリアルタイムデータ処理システムの開発に取り組みました。当時、プロジェクトは「高い同時接続数の下で、データ処理の安定性と正確性をどのように確保するか」という大きな課題に直面していました。

チーム全体で様々な方法を試みましたが、なかなか良い結果が得られませんでした。その時、彼女がイベント駆動型アーキテクチャに基づく新しいアイデアを提案しました。分散キューを使用してシステムのタスクスケジューリングを最適化するというものでした。当初、このアイデアは比較的複雑で前例の少ないものであったため、チーム内で一部のメンバーが慎重な姿勢を見せました。しかし、彼女は明確な論理と詳細な説明を通じてチーム全体を説得しました。

最終的に、このアイデアが問題を解決し、システムの性能を40%向上させるとともに、処理の遅延も削減することができました。この成果により、チーム全員が彼女の技術力に感服しました。

この経験を通じて、私は改めて実感しました。コードの世界は平等であり、書き手が男性であるか女性であるかで差が生じることはありません。女性エンジニアは独自の視点を提供するだけでなく、卓越した技術力によって性別に対する偏見を打ち破ることができるのです。どうか自分の能力を信じ、勇気を持って挑戦し続けてください。あなたの技術は、必ずや周囲を感嘆させることでしょう。

### 多様性がチームをより強くする
私が参加しているチームでは、女性エンジニアの参加によってもたらされる大きな変化を深く実感しています。彼女たちは、繊細な思考、優れたコミュニケーション能力、そして独自の問題解決方法を持ち込み、チームに新たな活力を注いでくれます。IT業界には多様な視点が必要であり、女性エンジニアの参加は、チームをより効率的にするだけでなく、技術的なソリューションをより包括的で人間味のあるものにします。同僚として、彼女たちと一緒に働けることを幸運に思っています。
私が参加したあるプロジェクトでは、シンプルなユーザーインターフェイスでありながら、強力な機能を備えた医療管理システムの開発を目指していました。初期の設計段階では、男性メンバーが中心だった私たちのチームは、技術機能を重視したいくつかの解決策を提案し、複雑なロジックで多様なユーザーのニーズに対応しようとしました。しかしそのとき、一人の女性エンジニアが重要な視点を提案してくれました。
「医師や看護師のようなユーザーは、複雑なシステムを学ぶ時間を費やすのではなく、患者情報を迅速に記録したいと考えています。」
この指摘により、私たちはユーザーエクスペリエンスの重要性を見落としていたことに気づきました。その後、彼女はインターフェイスの最適化を主導し、より直感的で使いやすいプロセスを設計しました。その結果、製品の使いやすさが大幅に向上し、ユーザーから高い評価を得ることができました。この経験を通じて、女性エンジニアの独自の視点と洞察力が、技術的なソリューションをより現実のニーズに近づける力を持っていると強く感じました。
ですから、私は女性エンジニアの皆さんに伝えたいです。「あなたたちの参加は、単にチームの技術力を豊かにするだけではなく、私たちのソリューションをより包括的で人間味のあるものにします。同僚として、あなたたちと一緒に働けることを本当に幸運に思っています。」

### 夢を追い続けてください
IT業界に足を踏み入れることは簡単なことではありません。特に女性にとっては、より多くの疑念や偏見に直面することもあるでしょう。しかし、忘れないでください。あなたの努力と粘り強さは価値あるものです。男性エンジニアとして、私は皆さんにこう伝えたいです：「私たちはあなたのサポーターであり、同じ道を歩む仲間です。」
一緒に力を合わせて業界の固定観念を取り払い、より多くの女性エンジニアが自分の技術的な夢を勇敢に追い求められるようにしましょう。そして、世界があなたたちの輝きをしっかりと見ることができるようにしたいと願っています。
Githubの使い方と各用語

# 前書き
Gitの使い方をおさらいしておこうと思ったので記事を書きます。


# Gitとは
ソースコードなどのファイルやフォルダの変更履歴を記録・追跡するためのバージョン管理システムのこと
開発を進める中でセーブポイントのように記録をつけることで時系列に沿って管理することができる

# Github
Gitの仕組みを用いて、複数人での開発ができるようにしてくれるWebサービスのこと
全世界に自分の作品を保存公開できる

https://github.com/

## Github Desktop
GUIで操作できるデスクトップ用のアプリケーションのこと

https://central.github.com/deployments/desktop/desktop/latest/win32

# Gitを用いたバージョン管理の手法と各用語
## リポジトリ
Gitの管理下にあるファイルやディレクトリの変更履歴を保管しておく箱のようなもの
管理したいアプリケーションのディレクトリをバージョン管理の範囲として指定する
また、リポジトリには二種類あり以下でそれらについれ解説する

### ローカルリポジトリ
自信のPC上で管理するリポジトリのこと
作成したリポジトリは自身のPC上にあるため、ファイルやディレクトリを変更、修正した際に好きなタイミングで記録できる

### リモートリポジトリ
外部サーバー上に置くリポジトリのこと
作成した箱が、インターネットを介した別の場所にも作られるイメージ
リモートリポジトリは直接変更修正せず、ローカルリポジトリの変更修正を同期して反映させることで更新できる

## リポジトリの作成方法
1.作成したファイルをローカルリポジトリとして作成する
①画像の「File」から「Add local repository」を選択する

![5d40cb8b321a1e0778c8137c5381d0b2.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3864659/9e17f439-1d72-ab12-c8ab-b98bddf322d2.png)

②「Chose...」からGitで取り扱いたいファイルを選択する

![2432259486f379f2f778a9d2e6b08d59.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3864659/4423fadc-0a1e-b3d3-a6b9-08eaa898274e.png)

③「create a repository.」と書かれた青字の部分をクリックし、「Add repository」をクリック

![cf237fde0e28bafa810358750217bdf1.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3864659/ff36ef1a-fcbc-eb1b-52a2-5f315b0bac5a.png)

④リモートリポジトリ完成後の画面

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3864659/8cc3b5cf-7eb8-442d-b92e-494fc4dd1370.png)

## Githubで作成したアプリを扱えるようにする
### Commit
ファイルやディレクトリの変更修正を、リポジトリに記録すること
commitをすることで、変更修正の寺家列の管理が行いやすくなり、変更修正をさかのぼることもできる

### コミットメッセージ
ファイルの変更修正の内容をわかりやすくするための記述

## Gitの設定
.DS_Storeという隠しファイルがあるのでこれをGitで管理されないようにする
1.VSCodeで「Ctrl + O」でホームディレクトリを開く
2.「新しいファイルを作成」をクリック
3.「.gitgnore_global」を作成
4.作成したファイルに「.DS_Store」と記述し設定完了
5.ターミナルにて以下のコマンドを実行
```
% cd ~
% git config --global core.excludesfile ~/.gitignore_global
```

## First Commit
### 最初のcommitを行う
1.画像の「Summary(required)」に保存したい名称を入力
2.「Commit to main」をクリック


![e6057e08cb39aee8d91fdc0a046837b6.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3864659/266e548c-3fe9-2bda-837f-33891040ea74.png)

### リモートリポジトリの作成
1.画像の「Publish branch」をクリック

![e02e3cad60bb39f95d9e29d11222af81.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3864659/40ffaab1-ad8b-e63c-1b19-991a9dad44a8.png)

2.「Keep this code private」にチェックが入っていると非公開になってしまうので、チェックを外して、「Publish Repository」をクリック

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3864659/ed9fadc2-10a8-75c8-99a7-c1e0b9348eed.png)

## 変更内容ののcommitとpush
1.内容の変更後Commitを行う
「Summary(required)」に保存したい名称を入力し、「Commit to main」をクリック

2.pushを行う
commitを行うと画面が画像のように切り替わるので、「Push origin」をクリックしpushする
### pushとは
ローカルリポジトリでのコミットをリモートリポジトリに反映すること

![0d3c2a238e64c55a28126dd599c7a44a.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3864659/506f0580-0222-5496-ffa1-fe97d71172c4.png)

3.Githubで反映されたことを確認したら完了
このはぴば2024　登壇した資料

投稿するネタが！ネタが！ない！！

そうだ、このはぴばで利用した資料を一般公開しよう。登壇視点です。

登壇者の控え場所の景色は、このは一色。
![メディア (20).jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/212894/f6c9d2ae-acc5-08b4-ee29-be3091ddce1e.jpeg)


![スライド1.PNG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/212894/d4d405b6-fabe-843e-1fa1-45d40e3f397d.png)
![スライド3.PNG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/212894/bb60d00a-ab71-aadb-2334-c4b8f8a28a86.png)
![スライド4.PNG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/212894/b61e9ba0-3482-9d61-c73f-78c394a32e4f.png)
![スライド5.PNG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/212894/46553a59-a574-0045-e0db-a77bb09719d4.png)

当時の私は、教育大学に在学。アルバイトでどこかの学校で先生をしていました。
![スライド6.PNG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/212894/8da5ebef-2252-392d-a716-9f3c1cde00ed.png)

![スライド7.PNG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/212894/579d2de0-c290-b61a-e4a2-d8cac7eef605.png)
![スライド8.PNG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/212894/4f4b4288-b2d2-b40c-ebdb-910d9b7f5050.png)
![スライド9.PNG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/212894/324d710e-cb6d-b5ce-58da-a4f8839e966b.png)
![スライド12.PNG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/212894/81ebb9dc-4e05-7ed7-5136-9414ede22321.png)
![スライド13.PNG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/212894/5f2a7f1a-74f2-9fee-3dc3-2c7ad4a749df.png)
![スライド14.PNG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/212894/27e3ef7f-11e4-3e54-dc57-5e37d1c1c257.png)
![スライド15.PNG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/212894/7a5fb151-9d9a-8bfb-aeb7-1f2d5d3ffafb.png)
![スライド16.PNG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/212894/7ae47c40-d896-3c13-6446-88046c6d3480.png)
![スライド17.PNG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/212894/60fac04d-24a5-f62c-2b09-cdd586950cc2.png)

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/212894/91bb6264-e9a2-29bf-442c-198a80ee2fbe.png)


次回の「このはぴば」も行きたいな。行けたらいいな。
今年は、勤務先上司の寛大な理解のうえ、奇跡的に休暇を取れたので登壇しました。ありがとう上司！

だけど、できるものならGMOに転職してみたいかも。って思っていたり。
【Yubikeyで二要素認証】Authenticatorアプリよりも高速で二要素認証を使用する

## これは何?

Yubikeyというセキュリティキーを使って二要素認証を設定して使ってみます。
~~Google Authenticatorでよくない?~~
セキュリティキーを使うとGoogle Authenticatorのように毎回pinを打たなくていいので二要素認証のストレスが軽減されつつ，セキュアな認証を行うことができます。

---

## セキュリティキーとは

> セキュリティキーとは、MFA(多要素認証) に用いられる外付けのハードウェアセキュリティデバイスです。パスワードに代わる新たな認証技術「FIDO (Fast Identity Online)」(*1)がベースとなっており、フィッシング攻撃や中間者攻撃に耐性があり、アカウントの乗っ取りを防止することが可能です。[Yubion](https://www.yubion.com/post/about-securitykey#viewer-z84xb898)

### セキュリティキーのイメージ

イメージが湧きやすいようにTwitterの二要素認証の設定を見てみます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3718390/30f81ff9-2b47-7d70-c154-7771234273fb.png)

- Text message: 電話番号のSMSでワンタイムコードを送信するやつ
- Authentication app: Google Authenticator等の画面に表示されるpinを使う
- **Security kye: 今回の記事で扱うYubikey(ハードウェア)等を使う**

---

## 買ってきた

- Yubikey社のYubiKeyシリーズ(高価だがOpenPGP対応)とSecurityKeyシリーズ(安価)が有名そう
- [Amazon url](https://www.amazon.co.jp/Yubico-%E3%82%BB%E3%82%AD%E3%83%A5%E3%83%AA%E3%83%86%E3%82%A3%E3%82%AD%E3%83%BC-NFC-USB-2%E3%81%A4%E3%81%AE%E3%83%95%E3%82%A1%E3%82%AF%E3%82%BF%E3%83%BC%E8%AA%8D%E8%A8%BC%E3%82%BB%E3%82%AD%E3%83%A5%E3%83%AA%E3%83%86%E3%82%A3%E3%82%AD%E3%83%BC/dp/B07M8YBWQZ/ref=sr_1_4?crid=1K4W0FFDDVSTN&dchild=1&keywords=security+key+nfc+by+yubico&qid=1634278513&sr=8-4)安い方にしたのに結構高い...

認証時に光るのが結構カッコいい!

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3718390/6ac3c295-443d-5eef-dd3f-1c5042ae1b7c.png)


---

## さっそく使ってみる

### 環境

Ubuntu 20.04 LTS

### 初期セットアップ

```shell
sudo apt install libpam-u2f
mkdir .config/Yubico
pamu2fcfg >> ~/.config/Yubico/u2f_keys
```

### 使用例1: yubikeyをsudoパスワードの代わりに使う

[参考](https://keens.github.io/blog/2021/03/28/yubikeywolinuxno_kagi_nisuru/)

1. /etc/pam.d/u2f-sufficientに以下を記載

    ```
    auth sufficient pam_u2f.so debug_file=/var/log/pam_u2f.log
    ```
2. ログファイル作製
  
    ```shell
    sudo touch /var/log/pam_u2f.log
    ```
3. sudoの設定ファイルに1の設定ファイルをincludeするように設定
  
    ```
    @include u2f-sufficient
    ```

これで`sudo`打鍵時にYubikeyを指しているとパスワード認証がスキップできます。

ちなみに，`sudo`打鍵時にパスワード+Yubikeyの二要素認証にしたい場合には，`sufficient`を`required`に変更すれば良いです。

```
auth required pam_u2f.so debug_file=/var/log/pam_u2f.log
```

### 使用例2: twitter等のSNSログイン時の二要素認証として

自分はUSB版の安い方を買ったので携帯だとYubikeyが刺さらない...
Google Authenticatorと併用してます。

### その他の使用例(気が向いたら書く)

- sshログイン時
- Ubuntuへのログイン

---

## 感想

Yubikeyを使うと面倒なpin入力がなくなるので便利でストレスがないのですが，ノートパソコンに指すのが面倒なのでデスクトップで挿しっぱなしとかが一番楽そう。
watsonx.aiStudioとのwatsonx.aiRuntimeのICOSバケット

ICOSの中にXXXX-donotdelete-xxxxという見慣れない名前のバケットを見つけることがあるかもしれません。これはwatsonx.aiStudio（旧Watson Studio)のプロジェクトです。
またwatsonx.aiRuntime（旧Watson Machine Learning)のデプロイメント・スペースも8caa5803-9976-4919-ae68-d48fc415d8f0というようなユニークIDのバケットを作ります。
これはNotebookやモデルなどの保管庫として使用されています。ICOSから削除してしまうと不整合が起きますので、不要になったプロジェクトやデプロイメント・スペースはwatsonx.aiStudioやwatsonx.aiRuntimeから削除してください。


# watsonx.aiStudioのプロジェクトの保管庫
試しにwatsonx.aiStudioのプロジェクトを作ってみます。
この際ICOSのインスタンスを指定しています。このインスタンス内にバケットが作られます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/223763/b9296666-0def-c878-a3b0-7ccb3eb17c7f.png)


ICOSのバケットとして＜プロジェクト名＞-donotdelete-xxxxという名前でバケットができています。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/223763/a1c3c743-8ecd-637c-79f8-06e6d5d98953.png)

プロジェクトを削除してみます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/223763/89cfce3a-8c88-73fb-f32e-1f931db3810d.png)

ストレージも削除されるというメッセージが出ます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/223763/57d2e049-1f8e-a685-6925-aff9984651f9.png)

ICOSのバケットも削除されました。
![{B661DB38-E392-40D3-9D63-3FAD6FCDDB98}.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/223763/638cae20-c607-71aa-88ac-c9684a2a08a3.png)


# watsonx.aiRuntimeのデプロイメント・スペースの保管庫
watsonx.aiRuntimeのデプロイメント・スペースも作ってみます。
この際もICOSのインスタンスを指定しています。このインスタンス内にバケットが作られます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/223763/83d6f91c-0549-d37d-8540-f1f0b3d089ce.png)

デプロイメント・スペースのバケットの名前は自動IDで生成されます。管理タブで確認ができます。自動IDだけでは元のデプロイメント・スペース名はわかりません。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/223763/2606cf4a-d45e-4f44-5739-e2b5a9e17603.png)

ICOSのバケットとして管理タブで確認した名前でバケットができています。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/223763/d381d05e-bb7c-f195-edfc-950acfd1f1f6.png)

デプロイメント・スペースを削除してみます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/223763/440952c6-31a9-841a-a081-bcb448c5679e.png)

全ての資産が削除されるというメッセージが出ます。
![{3A9C1078-570E-4FE3-9E4D-910D6A5F3E73}.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/223763/1554c9a1-7b23-2ade-5a43-8d322be56e91.png)

ICOSのバケットも削除されました。
![{5C5DAF80-8E68-487C-BB93-DEB0F5861DDB}.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/223763/4e854bc0-3caa-3401-1a07-453f44ac6963.png)


# 参考

#### プロジェクトの作成 - Docs | IBM Cloud Pak for Data as a Service 
https://dataplatform.cloud.ibm.com/docs/content/wsj/getting-started/projects.html?locale=ja&audience=wdp&context=cpdaas


#### デプロイメント・スペースの作成 - Docs | IBM Cloud Pak for Data as a Service 
https://dataplatform.cloud.ibm.com/docs/content/wsj/analyze-data/ml-space-create.html?context=cpdaas&locale=ja&audience=wdp
「年収の壁」103万円から178万円に引き上げたら稼ぎ方はどう変わる？

Yahooニュースの記事でこう取り上げられていたので気になりました！
>　「年収の壁」引き上げについては、自公が物価上昇率に基づく案を示す一方で、国民民主は1995年からの最低賃金の上昇率に基づき、課税水準を103万円から178万円に引き上げるべきだと主張している。

以下メモです！
# 住民税の壁
> 住民税: 住民税は基礎控除が43万円です。給与所得者の場合、給与所得控除が55万円あるため、合計で約100万円（43万円 + 55万円）を超えると課税対象となります。
# 所得税の壁
> 所得税: 所得税では基礎控除が48万円あります。給与所得者の場合、給与所得控除が55万円あるため、合計で103万円（48万円 + 55万円）を超えると所得税が発生します。

# 年収の壁の意義
これらの壁を超えると、それまで非課税だった所得税や住民税がかかるようになり、手取り額が減少します。年収を増やしたい気持ちは誰しもが持つものですが、年収の壁を考慮しないと手取り額が思ったように増えないことがあります。


# 時給いくらで、週どれくらい働くのか

## 年収103万
>月換算：8万円

```
月8万円を稼ぐ場合

時給1000円
* 合計労働時間: 80時間
    * 週3日: 約6.67時間/日
    * 週4日: 約5.00時間/日
    * 週5日: 約4.00時間/日

時給1100円
* 合計労働時間: 約72.73時間
    * 週3日: 約6.06時間/日
    * 週4日: 約4.55時間/日
    * 週5日: 約3.64時間/日

時給1200円
* 合計労働時間: 約66.67時間
    * 週3日: 約5.56時間/日
    * 週4日: 約4.17時間/日
    * 週5日: 約3.33時間/日

時給1300円
* 合計労働時間: 約61.54時間
    * 週3日: 約5.13時間/日
    * 週4日: 約3.85時間/日
    * 週5日: 約3.08時間/日

時給1400円
* 合計労働時間: 約57.14時間
    * 週3日: 約4.76時間/日
    * 週4日: 約3.57時間/日
    * 週5日: 約2.86時間/日

時給1500円
* 合計労働時間: 約53.33時間
    * 週3日: 約4.44時間/日
    * 週4日: 約3.33時間/日
    * 週5日: 約2.67時間/日
```

## 年収178万
>月換算：14万円  
```
月14万円を稼ぐ場合

時給1000円
* 合計労働時間: 140時間
    * 週3日: 約11.67時間/日
    * 週4日: 約8.75時間/日
    * 週5日: 約7.00時間/日

時給1100円
* 合計労働時間: 約127.27時間
    * 週3日: 約10.61時間/日
    * 週4日: 約7.95時間/日
    * 週5日: 約6.36時間/日

時給1200円
* 合計労働時間: 約116.67時間
    * 週3日: 約9.72時間/日
    * 週4日: 約7.29時間/日
    * 週5日: 約5.83時間/日

時給1300円
* 合計労働時間: 約107.69時間
    * 週3日: 約8.97時間/日
    * 週4日: 約6.73時間/日
    * 週5日: 約5.38時間/日

時給1400円
* 合計労働時間: 100時間
    * 週3日: 約8.33時間/日
    * 週4日: 約6.25時間/日
    * 週5日: 約5.00時間/日

時給1500円
* 合計労働時間: 約93.33時間
    * 週3日: 約7.78時間/日
    * 週4日: 約5.83時間/日
    * 週5日: 約4.67時間/日
```

## 休憩もらえる6時間で働いた場合の手取りと額面
```

*週3日働く場合
時給1000円: 額面72,000円、手取り57,600円
時給1100円: 額面79,200円、手取り63,360円
時給1200円: 額面86,400円、手取り69,120円
時給1300円: 額面93,600円、手取り74,880円
時給1400円: 額面100,800円、手取り80,640円
時給1500円: 額面108,000円、手取り86,400円

*週4日働く場合
時給1000円: 額面96,000円、手取り76,800円
時給1100円: 額面105,600円、手取り84,480円
時給1200円: 額面115,200円、手取り92,160円
時給1300円: 額面124,800円、手取り99,840円
時給1400円: 額面134,400円、手取り107,520円
時給1500円: 額面144,000円、手取り115,200円

*週5日働く場合
時給1000円: 額面120,000円、手取り96,000円
時給1100円: 額面132,000円、手取り105,600円
時給1200円: 額面144,000円、手取り115,200円
時給1300円: 額面156,000円、手取り124,800円
時給1400円: 額面168,000円、手取り134,400円
時給1500円: 額面180,000円、手取り144,000円
```

## フリーで働く場合払う必要のある他のお金
> ①国民年金保険料
保険料を納めることで、将来年金を受け取ることができる制度

平成30年度の国民年金保険料は、月額16,340円
<br>

> ②国民健康保険料
保険料を納めることで、医療機関への自己負担料を一定の割合におさえる制度

年間保険料
```
1カ月あたりの保険料
【年収100万】
40歳〜64歳以外:9,564円
40歳〜64歳:11,745円

【年収150万円】
40歳〜64歳以外:13,559円
40歳〜64歳:16,470円
```


https://www.cr.mufg.jp/mycard/knowledge/23121/index.html

## 毎月固定の金額をNISAから引き落とすために必要な元本

```
毎月10万円引き落とし:
年利4%: 3000万円
年利5%: 2400万円
年利6%: 2000万円
年利7%: 約1714.29万円

毎月15万円引き落とし:
年利4%: 4500万円
年利5%: 3600万円
年利6%: 3000万円
年利7%: 約2571.43万円
```
これらの元本を維持することで、利息のみで毎月の引き落としを賄うことができます!
Elixirでraylibを使ってグラフィック描画してみる その２ 〜 円を描く 〜

# 今回の目標
Rayexに円を描く関数がなかった
raw_pixelを使って点で円を描く

# 前提知識

https://qiita.com/t-yamanashi/items/d02c12f33fc18c585a4b

# 仕様
- 1秒に5個円を描く
- 半径は100px
- x,yはランダム

# ソース

```elixir
defmodule RayexPixel do
  use Rayex

  def main() do
    init_window(800, 800, "window name")
    main_loop(true)
  end

  defp main_loop(true) do
    begin_drawing()

    1..5
    |> Enum.each(fn _ ->
      draw()
    end)

    end_drawing()

    Process.sleep(1000)
    main_loop(!window_should_close())
  end

  defp main_loop(_), do: nil

  defp draw() do
    x1 = Enum.random(1..800)
    y1 = Enum.random(1..800)

    1..360
    |> Enum.each(fn r ->
      point(r, x1, y1)
      |> then(fn [x, y] ->
        draw_pixel(x, y, %{r: 255, g: 161, b: 0, a: 255})
      end)
    end)
  end

  def point(r, x, y) do
    c = :math.pi() / 180
    px = :math.cos(c * r) * 100 + x
    py = :math.sin(c * r) * 100 + y
    [trunc(px), trunc(py)]
  end
end
```

# 実行結果

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/295814/c5c225d2-2567-342b-c2b1-fd05365c373f.png)

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/295814/6cbb3d10-c72a-a285-53d7-57f02adb0384.png)
【超導入編】CI/CDってなに？

# CI/CDとは

多くのサイトで、以下のように説明されています。


>*「 Continuous Integration（継続的インテグレーション）/ Continuous Delivery（継続的デリバリー）」の略称。CI/CDは、何か特定の技術を指すものではなく、ソフトウェアの変更を常にテストし、自動で本番環境にへ適用できるような状態にしておく開発手法のこと。*



・・・・・つまり？？？？（╹◡╹;）

いろんな解説を一周して、自分なりにわかりやすい捉え方はこちらになりました。


:::note
CI/CDとは、**「リポジトリでの開発完了〜本番リリースのあいだに必要な、テストやらデプロイやらを自動化するもの」** 
:::


こう言われると、何者なのかは理解できそうです。


## CIとCDの棲み分けは？

「CI/CDとは」は何となく理解できたのですが、「CIとCDは何が違うの？」という疑問が残ります。それぞれの説明を見てみると、


> ***CIとは...** 
継続的インテグレーションという名の通り、開発者にとっては自動化のプロセスを指す。アプリケーション開発で言えば、バラバラに稼働している複数エンジニアのソースコードを継続的に統合（インテグレーション）し、正常に動作することを確認するために検証する取り組みのことである。新たなソースコードの変更を、定期的に、あるいは毎日でもビルドおよびテストし、共通のリポジトリに統合する。*
> 

> ***CDとは...** 
継続的デリバリーという名の通り、ユーザーに継続的にアプリケーションを提供することを指す。提供とはすなわち、本番環境にアプリケーションを載せ、顧客がいつでも新たなアプリケーションを利用できるようにすることである。CDでは、検証済みコードのリポジトリへのリリースを自動化する。コード変更のマージから本番環境に対応するためのビルドのデリバリーまで、すべての段階でテストとコードリリースを自動化する。これにより、運用チームは本番環境にアプリケーションをすぐにデプロイできる。
引用：https://www.sbbit.jp/article/cont1/81640*
> 

とあります（╹◡╹;）何となーくわかりそうですが、まだぼんやりしています。
具体的な状態で考えてみます。

#### CIのみ導入していたら
開発者がコードをプッシュ → テスト・解析を実行（CI） → 問題なければ「テスト成功」の通知 → デプロイとリリースは開発者が手動で行う

![cicd.001.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3798901/e608cf49-006f-f24d-50b9-a600ef7351a1.png)

    
    
#### CI/CDの両方を導入していたら
開発者がコードをプッシュ → テスト・解析を実行（CI） → ステージングや本番環境へデプロイ（CD） → 自動リリース（CD）

![cicd.001のコピー.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3798901/59b9ab8a-89c8-0cf9-11a9-1222544a365a.png)


といった感じになります。


CI（継続的インテグレーション）は、マージ～テストまでに重点を置き、変更を合体しても正常に動作することを確認する。
CD（継続的デリバリー）は、デプロイ〜リリースに重点を置き、より提供に近い箇所を自動化する。


つまり **「どこまで自動化するか」** というのが、CIとCDを分ける要素なのです。


:::note warn
 **CIはCDに含まれるという捉え方もある** 

CDはCIを拡張したものであり、CDがCIを含んでいるという捉え方もあります（デリバリーという概念に全てのフローを含むことができるため）。どちらの考え方が間違っているとかではないみたいです。いずれにしても、CIはマージ～テストまでに重きを置いた概念で、CDはデプロイ～リリースに重きを置いた概念であるという考え方は同じです。

![cicd.001.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3798901/b50973ba-a316-0353-e87c-27c3cb4a5073.png)
参考：https://aws.amazon.com/jp/devops/continuous-delivery/

:::

## CI/CD導入のメリット

- 正確なテストを行える。人間じゃないので設定さえ合っていればミスらない！
- 開発完了〜リリースまでのスピード大幅アップ。しかも人間の時間を使わない！

## ツール

- Github Actions
- CircleCI
- Jenkins
- Bitrise

など。CI/CDを導入するためのツールは色々あるみたいです。

うちではGitHub Actionsを使っていて、実際のワークフローの書き方の一例がこちらの記事で解説されています↓↓

https://qiita.com/maabow/items/25b0d6febcf5e56db30c



詳しいワークフロー構文はGitHub Docsがとても親切でわかりやすいです↓↓

https://docs.github.com/ja/actions/writing-workflows/workflow-syntax-for-github-actions


#### 参考
https://www.ctc-g.co.jp/solutions/cloud/column/article/104.html
https://www.sbbit.jp/article/cont1/81640
進捗報告 (2024-12-10 10:39:15)

# 音声自動介護記録ソフトの進捗報告

## 概要
現在、音声を解析し、介護記録を自動で生成するソフトウェアの開発を進めています。本記事では、現在の進捗と技術的な課題について詳しく説明します。

## 進捗状況
### 音声解析とデータベース登録
音声データをAIが解析し、データベースの対象テーブルおよびカラムを特定する機能は実装済みです。解析した結果は、データベースの指定シートにレコードとして自動登録される仕組みが整っています。

### データ参照の課題
お客様の日報シートにデータを反映させる際、特定の日付およびテーブルに基づいてDBからの記録を取得することはできます。しかし、手動でお客様日報を編集したい場合、セルに色を付けて参照する手法では編集ができないという問題に直面しています。

## 技術的課題と解決策
1. **DB参照の制限**  
   セルに色を入れる参照方法では、ユーザーが手動で編集することができず、またその編集結果をDBに逆にインサートすることもできません。この制約が、ユーザーの操作性を制限していました。

2. **スクリプトによる監視機能の実装**  
   現在、スクリプトを用いてデータシートの対象セルを監視する仕組みを構築中です。このスクリプトでは、DBに新たにインサートされたデータと、ユーザーによって編集されたデータを同期させることを目的としています。

## 今後の展望
この監視機能が正常に機能すれば、ユーザーはお客様日報を自由に編集できるようになり、編集結果をデータベースに逆インサートすることも可能になると考えています。これにより、より柔軟で使いやすい介護記録ソフトの実現が期待されます。

以上が、音声自動介護記録ソフトの現在の進捗と技術的課題に関する報告です。引き続き開発を進めていきます。
茶色コーダーによるAHC040振り返り

# 初めに
寒いですね。僕は、二次予選前、雪が、少し残っている中、普通の長袖+ビーサンで、散歩したら、歩いてたおじさんにドン引きされました。(そりゃそーだ、その日最低マイナス4度だったからな)

そして、二次予選、脱落決定しました。 ボーダーがだいたい290点、僕は219点、僕は中部ブロックの望み(少ないから)もありましたが、ボーダーがだいたい決定した瞬間消え去りました。
まあ、また来年もあるし(あと4年分ある)そろそろatcoderはアルゴ部門　もうそろ入緑だし、切り替えてがんばります。

えーとはい、初めてのrated長期コンテストでしたが、結果は最悪でした。(2日ぐらいしか、手をつけてない)
最終絶対スコアが、69714968点でした(sqrt解法思いつけば、もうちょっといけた)
僕は、短期のほうが、得意なのかな

まあその2日の、結果を話します

# 1日目
手を付け始めたのは、19:30分頃とりあえず、サンプルコードを投げます。
その後c++で、出力形式の確認のため、横並べの解法を提出、サンプルより悪いです。
今回そこまで自分ができる領域では、計算量があまり気にしなくてもいい、事に気づき、pythonにします。

その後、各クエリで、山登り風のコードを書くものの、スコアは、悪化しました。

# 2日目
6:30頃目が覚めて、いい感じのコードを思いつき色々書きます。
ですが改善せず、親に起きてコード書いてたのと言われ気づいたら9時でした。
朝飯食って、思いついたのは、一段に、置くブロックの数を$\sqrt N$にする劣化版です。
具体的には、
ブロックはすべて使うため$p_i=i$
$r_i$は、ランダムにします
$d_i$も、ランダムにします
$b_i$は、$i-1$にします

で先程の山登りの初期解に設定して提出すると、スコアは良くなりました。
ですが僕は、いい初期解+山登りで、いい感じになっているかと、思いきや、そんなはずもなく初期解が強かったのでした。

その日の16時ごろ、先程の初期解を何回もランダムにやれば、いいのではと思いつき、やったら先述のスコアになりました

で同学年でも結構いい順位だしいいやと思って、そのまま最終日になりました(最終的に同学年の中でも結構低い方でしたw)

# 最終日
英会話に出かける前、そういえばAHC終了直前だなーと思ってあとで解説見ようと、思いそのまま、英会話行って、晩飯食ったあと、解説を見ました。

各段に置くブロックの数を$floor(\sqrt N)$にすると良いらしく、試してみると、僕が最後に提出したスコアより$9000000$点改善しました。

そっか正方形を面積から一辺の長さを求めるには、面積のsqrtを取ればいいのかと思い、少し自分が悔しくなりました。

# 最後に
やっぱり数学的考察は大事ですね。
ついに、僕の、暫定のヒューリスティックのレートが、アルゴリズムのレートより上がってしまいました。(文章力がゴミですいません)
少し悔しいです。

まあ、本職はアルゴなので頑張ります。
エンジニアとして成長しない人の特徴４選

# はじめに

強気なタイトルしました。すいません。

私事ですがエンジニアとして仕事を始め6年経ちました。
未経験でこの業界に飛び込み、最初は大変でしたが気付けばずっとプログラミングを教える側です。

新卒採用の責任者もやっており、長期インターンシップなどでも学生にプログラミングを教えたりしています。
そういった経験もあり、人に教える機会、初心者が成長していく過程をかなり見てきました。

そんな中で成長する人としない人の違いが自分の中で明確になったので書き記しておきます。

体感ですが今まで会った8割のエンジニアがこの特徴に当てはまっている気がします。

# 毎日のインプットができていない

みなさんインプットしてますか？
Qiitaを見ている方々はインプットを行っている人だと思います。  
  
  
**エンジニアってインプットが全てだなと思います。**
技術の移り変わりが早く、プログラミング言語自体のアップデートもあり、気づけばいつも書いていた書き方が非推奨になっていたりするのは日常茶飯事ですよね。


**なんならエンジニアじゃない、企画側の人やPO（プロダクトオーナー）、SM（スクラムマスター）の人達がやたら技術に詳しいということがあるあるです。**

- 日頃インプットを行い、良いアーキテクチャはなんなのか提案、検討する。
- 日頃インプットしたことを日々のコーディングでアウトプットしてより良い品質のシステムを作る。

この辺ができないエンジニアは意外と多いです。
いわゆるできるエンジニアはみんな技術のキャッチアップが早くすぐに実践で使います。
インプットしていないエンジニアはずっと同じ記述、同じ技術しか使わず、差がついていきます。

自分の開発している言語のバージョンぐらいは最低限おっかけて、毎日何かしらの記事やニュースを見ましょう。

**技術者として、いや社会人としてマストだと思います。**

# WhatよりWhyを意識できない
日々の業務が忙しいとプログラミングに慣れてない人は内部の処理を完全に追うことができない場合もあると思います。

変数名や関数名をみて「あーこれは〇〇を取得しているんだな」みたいに処理を詳しく見ず、勝手に判断しています。

何をしているかというは簡単に情報として手に入りますが「**なぜその処理をしているのか？**」というのを意識しないと、まっさらなファイルから作ることができなくなります。

開発案件に長くいると
- あのファイルの真似しよう
- 先輩から「この処理真似すればいいよ」って言われたからとりあえず真似して作ってみる

みたいなことが多くあると思います。

そして渡された処理をみて何をしているかだけ理解してわかった気になり、なぜその処理をしているかを気にせず書き続けてしまう。

その開発現場ではもしかすると戦力になるかもしれないですが、書き方が全く変わった案件になった場合戦力にならないというのはあるあるです。


**常日頃、インプットを行い「why」を意識しましょう。**

# クリティカル・シンキング（批判的思考）ができない
書かれているコードに対して何も疑問を持たない。
- このコードこれでいいの？
- この実装だと動かないよね？
- なぜこの書き方をしているんだろう？
- これって何をしているんだろう？
- これ共通化すればかなりシンプルになるような？
- このUI/UXおかしくない？
など

**既存のコードや実装、動きに疑問を持ちましょう**
疑問を持つためにはインプットがないとできないのでインプットは怠らず
自身のチームのコード、実装、挙動を神とせず疑問を持ち続けましょう。


# コードレビューをされていない
ここでいうコードレビューは動いているかを第三者に確認してもらうことではないです。

実装に対して
- ここは冗長だからこのように書くと無駄がなくなるよ
- 最近はこういった書き方をするのが主流だよ
 
みたいなアドバイスをもらえるレビューです。


しかし、悲しいことにレビュアーもそこまでプログラミングを理解している人って少ないです（僕の周りだけかも）
現場レベルの知識しかなく、動けばOKみたいな人も多いのが現実です。

レビュー文化がない場合は身近にいる、「この人プログラミング詳しいよなー」っていう先輩や同僚にみてもらいましょう。

**レビュー（指摘）というのは最も早く成長する手段だと思います。**

動くものを作るのは最低限で、その上より良い品質のものを作る。
- 保守性が優れている
- 可読性が高い
- シンプルな作りになっている
- 推奨されている書き方をしている

などいろんな観点があります。
レビューを通していわゆるできる先輩から知識を盗みましょう。

チーム内で議論ができる状態だとすごくいいなって思います。

以前のスクラムチームは開発者どうしで、技術の意見交換が積極的に行われており、エンジニア1年目だった私はものすごく成長したと思います。

言われたことをメモして、業務時間外に復習する
というのが私のルーティンでした。

# 最後に
プログラミング未経験だと焦る気持ちからか、ついつい近道を探しがちですが、そんなものはないです。

一番もったいないのは開発チーム内で年数だけ重ね、仕様に詳くなり修正箇所を暗記して、本質を理解せず、技術力が無くても仕事になっている状態です。

別の会社や案件に言った場合に痛い目にあいます。
そのようなエンジニアを多く見てきました。

日頃のインプットを行い、常日頃「why」を意識して現場の常識を常識と思わず、不安であればレビューをしてもらい適切なインプットを得る。
ということを繰り返してください。

そうすれば最初は苦労しますが、1年もしたら自信がかなり付くと思います。
**Pressure makes diamonds!** です！
キャリアブレイク中にやっている勉強⑥ 仏教

今日もキャリアブレイク中に具体的にやっている勉強について書きます。その⑥は「仏教」です。

# 仏教
ここまで紹介した5つはわりと必然性があって選びました。プログラマとして役に立ちそうなこと、自分の健康にとって役に立ちそうなこと。今回キャリアブレイクして自由な時間を得たので、あえて必然性がないこと、自分と全く関係ないことも1つ学びたいなと思っていました。候補で考えていたのは、心理学、哲学、漢詩、そして仏教でした。この中でも特に一度も学ぼうと思ったことがない仏教を敢えて今回勉強の候補に選びました。

# きっかけ
きっかけの一つは、コテンラジオで[仏教2.0 ！ アップデートを繰り返す釈迦の思想【COTEN RADIO 最澄と空海編2】](https://podcasts.apple.com/us/podcast/19-2-%E4%BB%8F%E6%95%992-0-%E3%82%A2%E3%83%83%E3%83%97%E3%83%87%E3%83%BC%E3%83%88%E3%82%92%E7%B9%B0%E3%82%8A%E8%BF%94%E3%81%99%E9%87%88%E8%BF%A6%E3%81%AE%E6%80%9D%E6%83%B3-coten-radio-%E6%9C%80%E6%BE%84%E3%81%A8%E7%A9%BA%E6%B5%B7%E7%B7%A82/id1450522865?i=1000492294673)を聞いたことです。宗教がアップデートするなんて予想もしていなかったのでこれでまず興味を持ちました。ただ、その時点では他の勉強候補もあったので、図書館で本を色々流し見したり、借りたりもしていたのですが、一番のきっかけとなったのはジュンク堂書店で仏教コーナーを見たことでした。

# ジュンク堂の仏教コーナー
本棚をみてまずその書籍の多さにビックリしました。仏教だけで一列ありました。さらに一番端を見たら仏典がありました。結構分厚い本です。中を見ると全て漢文で書かれています。内容など一つも分かりません。値段も高く1冊1万円ぐらいする本もありました。これが多分数百冊ありました。おそらく日本人の99%は一生読まない本です。それがこれだけの量、おそらく大昔から綿々と紡がれているです。なんだこの世界はと思いました。多分これがきっかけです。

# 仏教の勉強法
ただ仏教をちゃんと学ぶ方法は結構困りました。実際自分は、仏教について知っていることは殆どないです。本は兎に角いっぱいある。でも何から勉強すれば良いのかよく分からない。そこでまずはChatGPTに対して仏教に関する質問をして、より知りたい内容はWikipediaを併用して読んだり、Youtubeを見たりしながら気になったことはGitHubに[メモ](https://github.com/binnmti/Study/blob/main/Notes/%E4%BB%8F%E6%95%99.md)するようにしました。ある意味一番ダメな勉強法ですが、現時点ではこれで良いと思っています。

# ChatGPTとの会話
特に今回の色んな勉強の中で一番ChatGPTを使っています。他の勉強は良いテキストを読んだり、良い動画を見たりしていますが、仏教は他の勉強とは全く異なるアプローチで、ChatGPTと1時間まるまる会話することもあります。これは数年前なら出来なかった方法だと思います。これでもどんどん考えは広がっていき、例えば「最も古い宗教は何だろう」とか「仏教とキリスト教の類似性」とか「神という概念がない宗教」とかいろいろ気になることは出てきています。

# 仏教に対する大きな疑問
会話や調べ物などで仏陀が仏教の祖であることは分かりました。ここでわりと一つ大きな疑問が出てきました。ブッダは神については殆ど語っていません。にもかかわらず仏教には神が沢山出てきます。これは何故だろう？。キーワードとしては大乗仏教だと思いますが、それまでの歴史や発展した経緯なども知らないと分からなそうなので、今はこれを学んでいるところです。

# まとめ
仏教も栄養学と同じで、週2回ぐらい1日1時間程度学んでいます。図書館で借りた本を寝る前に30分ぐらい読むこともありますが、まあ眠くなりますｗ。今出た疑問は中々面白いと思っているので、これが明らかになっていくのは楽しみです。後は他にもブッダダルマとか気になるキーワードもあるし、それ以降の発展や日本でどうなっていったなどもこれから学んでいくつもりです。
未経験から始めるiOS開発：学び方とモチベーション維持のコツ

# 未経験から始めるiOS開発：学び方とモチベーション維持のコツ

[Commune Advent Calendar 2024 シリーズ２](https://qiita.com/advent-calendar/2024/commune)の１０日目の記事は『未経験から始めるiOS開発：学び方とモチベーション維持のコツ』です！


こんにちは！この記事では、3年ほど前に私がiOS開発を学んでモバイルエンジニアとして初めて仕事を得た時の経験をもとに、効率的な学び方やモチベーション維持のコツについて書こうと思います。
現在はiOS開発の経験を経て、CommuneではFlutter開発をメインで行っていますが、あの時はモバイル開発の経験がまったくない状態から、ゼロから学びました。その時の経験が、同じように「これからiOS開発を1から学びたい」という方の参考になればと思っています。

私はもともとWeb開発のブートキャンプに通ったり、データエンジニアとしてインターンをしたりと、プログラミングに触れる機会はありましたが、iOS開発は全くの未経験。新しい分野への挑戦だったので、「独学でちゃんと知識を身につけられるのかな？」「このスキルで仕事を得られるのかな？」と、最初はすごく不安でした。

特に、当時は海外に住んでいて、日本語ではなく英語のリソースを中心に学ぶ必要がありました。どのリソースを選べば良いか迷うし、独学だと進み方がこれで正しいのか分からなくなる。そんな状況で、やっと自分に合う方法を見つけていきました。


## リソース選び

初心者向けのリソースはたくさんありますが、個人的にオススメだったものをいくつか紹介します。

### **Hacking with Swift**
- [Hacking with Swift](https://www.hackingwithswift.com/100)  
      Swift、UIKit、Swift UIをゼロから学べる初心者向けの教材です。無料で使えますし、短いレッスンに分かれているので取り組みやすいです。

### **YouTubeチャンネル**  
いくつかのチャンネルがとても役立ちました：  
- [Sean Allen](https://www.youtube.com/@seanallen)  
 基礎から最新技術まで、幅広く学べるチャンネル。初心者向けの解説が分かりやすいです。面接対策動画もおすすめです。
- [Swiftful Thinking](https://www.youtube.com/@SwiftfulThinking)  
SwiftUIに特化した内容が豊富で、アプリ開発に直接役立つ情報が詰まっています。
- [London App Brewery](https://www.youtube.com/watch?v=UNH0bE4zPtY&list=PLSzsOkUDsvdu5Mm67aBYs2YPu2OM4mFzt)  
Udemyの人気講座「iOS App Development」の無料サンプル。最初の一歩に最適です。ツールの使い方やインストールの仕方まで教えてくれます。

### **Apple Developer Program**
- 加入するとWWDCのチュートリアルや最新情報が見られます。内容は高度ですが、ワクワク感がモチベーションになります。


## 手を動かして学ぶ

ただチュートリアルを眺めるだけでなく、実際にアプリを作ることが力になると思います。私は以下のようなアプリをiOS開発で作ってみました：：

1. **英単語アプリ**：ランダムな単語を表示したり、意味を調べたり、好きな単語を保存できるシンプルなアプリ。
2. **就活用メモアプリ**：面接準備やタスク管理用に作りました。 
3. **子供向け算数練習アプリ**：子供が楽しみながら学べるような簡単なクイズ形式。

小さいアプリを作ることで達成感を得られ、自信にも繋がります。
また、小さいアプリでもApp Storeに提出することができるので、提出することも勉強の一環だと思ってやって良かったことの一つです。会社にもよりますが、現場で役立つと思います。


## モチベーションを保つコツ

### **勉強のペースを作る**  
なんでもそうかもしれませんが、毎日5分でもいいので、コツコツと続けることが大切だと感じました。私の場合、最初はLondon App BreweryのUdemy講座で学び、1日5-7セクション進めるペースを守りました。

### **コミュニティやメンターを活用する**  
私はHanko Academyというアメリカのオンラインプログラムを受講しました。週に2回、(時差があったので)夜中の2時から授業があったので大変でしたが、仲間との進捗共有やメンターへの質問が大きな助けになりました。メンターは全員シニアiOSエンジニアで、現場のリアルな話を聞けたのも良かったです。
ちなみに、いい(自分にあった)メンターの存在はとても重要だと感じました。質問することで自分の理解が深まり、やる気の出るフィードバックをくれたのでとても良かったです。


## SNSで発信する

学習の進捗をXなどで共有するのもオススメです。私もHacking with Swiftの進行状況をツイートしていた時期がありました。フィードバックをもらえたり、同じ目標を持つ人とつながれることで、モチベーション維持に繋がります。


## 最後に
iOS開発を始めた頃、私も不安や迷いがたくさんありました。でも、小さな目標をクリアしながら進めていくと、自分ができることが増えていくのが実感できます。この記事が、これからiOSエンジニアを目指す方にとって、少しでも道しるべになれば嬉しいです！
「時間がない」問題と心理的に向き合い、開発生産性を高める

![jiyeon-park-OshG1lLSNa4-unsplash.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/315525/c9a70267-587b-6e63-b30f-a6ad9f423922.jpeg)

皆さんは「時間がない」と感じることはないでしょうか？僕はたびたび感じることがあります。

そう感じる原因にはタスク整理ができていないとか、自動化すべき作業を手動で行っているとか色々あると思いますが、人は認知バイアスによっても「時間がない」と感じてしまうそうです。

そんな「時間がない」という問題に対して心理的に向き合ってみて、メンタル面でも開発生産性を向上させていこうという試みをしてみました。

---

**目次**

1. [「時間がない」という認知の歪み](#時間がないという認知の歪み)
1. [デジタル機器の影響](#デジタル機器の影響)
1. [デジタルデトックス](#デジタルデトックス)
1. [メンタルを整える](#メンタルを整える)
1. [まとめ](#まとめ)

## 「時間がない」という認知の歪み

YouTubeのサトマイチャンネルというチャンネルで面白い動画を観ました。
「時間がない」というのは認知の歪みであるという動画です。

https://youtu.be/2PiCW7BFJug

動画の冒頭は次のように始まります。

- 小学生の頃には授業と授業の間に20分くらいの休み時間があり、校庭に出て遊んでいた
- 大人になると、20分じゃ何もできないと感じてしまうようになる
- つまり大人になると時間に対する認知が歪んでいくのだ

確かに小学生の頃は僕もたった20分の休み時間で校庭に出ていってドッジボールをしたことがありました。

でも大人になると、ミーティングが終わって次のミーティングまでに30分時間が空いていても

```
「30分でできることなんてないから、ミーティングをくっつけてほしいなぁ」
```

などと思うことがあります。

大人になると捉え方が変わってしまうというのは不思議なものです。
どうして大人になるとこのような認知の歪みが起こってしまうのでしょうか。

## デジタル機器の影響

原因の1つとしてデジタル機器の影響があると動画では語られていました。

私たちは少しの合間があるときにもスマホを手にとってSNSや動画などを観てしまいます。
電車の中でも多くの人がスマホを見ている光景を目にします。

また通知が見境なく来てしまい、仕事とプライベートの境界が曖昧になっていることも影響しているそうです。退勤後にもSlack通知が来てしまい、気になってSlackを見てしまうという人もいるのではないでしょうか。

このように、スマホを見境なく見てしまったり、頻繁な通知が来ることで自由時間が上手に活用されず、「なんとなく時間がない」と感じてしまうそうです。

僕もベッドに入りながらスマホで動画を観続けてしまうクセがあり、それが原因で寝不足になっていることもあります。
（本当によくない）

スマホばかりを見続ける生活は自由時間を有効活用できているとは言えないです。

## デジタルデトックス

デジタル機器の影響はテレビでもよく取り上げられているなぁと感じており、最近は意識してスマホを見ない時間を作るようにしています。

- リビングに居るときは自分の部屋にスマホをしまっておく
- 家で仕事をするときも、机の上にスマホを置かない
- 電車の中にいるときもスマホをバッグにしまっておく

スマホを触っていなくても視界に入るだけで悪影響を及ぼすらしいので、目に見えないところへしまうようにしています。

電車の中で何もしてないと時間がもったいないように感じ、電子書籍を読んだりもするのですが、気がつくとSNSを眺めていたりしています。スマホだと誘惑が多すぎるので、紙の本か電子書籍用の専用端末を使うほうが読書は捗るかも知れません。

## メンタルを整える

上記の動画によると、そういった「時間がない」という感覚を改善するには、マインドフルネスや認知行動療法が有効だそうです。

僕は特定の日までに準備をしておかないといけない作業があると、気持ちがソワソワして落ち着かないことがあります。飲み会の予約とか結構苦手だったりします。

そんな気持ちを落ち着かせるために以前から下記の書籍を読んでマインドフルネスを始めています。

https://www.amazon.co.jp/dp/B08D94RBN6/

メンタルの改善方法は書籍にいろいろ書かれているのですが、個人的に一番効果があったのは散歩をすることでした。散歩をして陽の光を浴びながら、公園の木々など緑色のものを眺めることで気持ちを和らげる効果があります。

またデジタルデトックスをすると家ですることがなくなるため、結果的に外出しているという側面もあります。

日曜日は次の日が仕事ということもあり、ゆっくりしようと家にいることが多かったのですが、次の日が仕事だと思うと、どうしても仕事モードに陥ることがあるため、あえて日曜日に外出をすることもしばしばありました。

最近は休日に仕事のことを考えだしたら外出するというのをルーチンにしています。

## まとめ
デジタルデトックスとマインドフルネスをするようになって、仕事とプライベートのメリハリを付けられるようになり、今年1年は結構ストレスを感じない年になりました。

開発生産性の向上には自動化やタスク整理などテクニカルな解決策も有効だと思いますが、メンタル面でも改善すると気持ちに余裕が生まれて仕事に取り組みやすくなるかも知れません。

開発生産性フレームワークの SPACE に Satisfaction and well being（満足度と幸福度）という項目があるのも分かるような気がします。
プロキシ環境下のWindowsマシンでWSL2上のVSCodeが起動できない事象について

## はじめに

みなさん、こんにちは。久しぶりにプロキシ環境下のWindowsマシンを入れ替えたところ、WSL2上のVSCodeが起動処理の最初に行われるアップデートに失敗し、起動できないという事象に遭遇しました。

環境変数のHTTP_PROXYやHTTPS_PROXYは設定しているし、VSCodeのsettings.jsonの設定も問題なさそうなのになんでかな…と一瞬迷ったので自らの備忘のため、記事という形に残しておこうと思った次第です。

## VSCodeがアップデートに失敗する原因

結論としては「`wget`のプロキシ設定が漏れていたため」でした。

なぜ`wget`のプロキシ設定が必要かというとVSCodeを起動する`code`コマンドを実行すると、最初にアップデートをインターネットへ入手しに行く挙動をするのですが、その際に内部的には`wget`を使っているというオチでした。

分かってしまえば単純ですが、直感的にはVSCodeのsettings.jsonなどでプロキシ設定箇所もあったりするので、`wget`という思わぬ伏兵が隠れていることにパッと気づけませんでした^^;

## wgetのプロキシ設定方法

個別のユーザーごとに設定するなら `~/.wgetrc`、すべてのユーザーに一括で設定するなら `/etc/wgetrc` を修正します。使い分けとしてはプロキシ認証にユーザーとパスワード情報が必要なら前者、それ以外は後者と考えるとよいでしょう。

**例）ユーザー認証が必要なケース**

```txt:~/.wgetrc
https_proxy = http://<user>:<password>@<host>:<port>/
http_proxy = http://<user>:<password>@<host>:<port>/
ftp_proxy = http://<user>:<password>@<host>:<port>/
```

**例）ユーザー認証が不要なケース**

```txt:/etc/wgetrc
https_proxy = http://<host>:<port>/
http_proxy = http://<host>:<port>/
ftp_proxy = http://<host>:<port>/
```

この設定追加により、無事にWSL2上のVSCodeのアップデートに成功し、VSCodeが起動できるようになりましたとさ。めでたし、めでたし。

## 最後に

ということで、今回はプロキシ環境下のWindowsマシンでWSL2上のVSCodeが起動できない事象の原因と解決方法の紹介でした。いまさらかよ、といった内容ですがこんな記事でも誰かの助けになってくれれば幸いです。

---

- Visual Studio Code、Windowsは、Microsoft Corporation の商標または登録商標です。
- その他、本記事に記述してある会社名、製品名は、各社の登録商品または商標です。
【PostgreSQL】pgAdmin4のアップデート催促メッセージの消し方

# 環境
|Os|pgAdmin|
|-|-|
|Windows10|8.12|

# 現象
![Updatesuggest.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3898103/b2ad7f37-c3fd-1bef-156c-036da0d3594c.png)
```hack:Message
You are currently runnning Version 8.12 of pgAdmin 4,
however the current version is 8.13.
Please click here for more information.
```
```:メッセージ
現在、pgAdmin 4 のバージョン 8.12 を実行しています。
ただし、現在のバージョンは 8.13 です。
詳細については、ここをクリックしてください。
```

# 消し方
### 結論
**config.py**の`CHECK_SUPPORTED_BROWSER`を**False**に変更する。

### config.pyのパス

```:パス（参考）
%AppData%\Local\Programs\pgAdmin 4\web
```
### conffig.pyの内容
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3898103/1e2f48a2-7b5f-910e-93fc-b3a799bfc19a.png)

# 消えた事を確認
![pgadmin消えた画面.PNG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3898103/36837839-f7eb-08c2-e137-f0cfcbf81cdb.png)

# コメント
右下に出てくるので、他のメッセージと被る事が多々あったので、消す方法を調べました！
何故か、あまり日本の記事が見当たらなかったので投稿してみました。
忘備録として置いておきます。同じ現象で困っている方がいましたら、本記事を参考にして頂けますと幸いです。
よければ、「いいね」を押して頂けると嬉しいです！
x86 Linux 上の MQ V9.4 のパフォーマンス レポート

# x86 Linux 上の MQ V9.4 のパフォーマンス レポートが公開されています

x86 Linux 上の MQ V9.4 のパフォーマンス レポートが公開されました。
x86 Linux 上の MQ V9.4 長期サービス リリースのパフォーマンス レポートが、GitHub の mqperf サイトから入手可能になりました。[こちら](https://ibm-messaging.github.io/mqperf/MQ_V9.4_Performance_Report_xLinux_v1.0.pdf)から参照できます。

このレポートには、現在 MQ チャネルでサポートされている新しい LZ4 圧縮アルゴリズムを使用したパフォーマンス テストが含まれています。

圧縮は、低帯域幅ネットワークでのパフォーマンスを最適化するのに役立ちます。以下の表は、新しい LZ4 アルゴリズム (LZ4FAST) の 1 つを使用した場合と、以前のアルゴリズム (ZLIBFAST) を使用した場合、または圧縮しない場合のメリットを示しています。メリットは、メッセージのサイズや圧縮のしやすさ (以下のテストに使用されたメッセージは JSON でした) など、いくつかの要因によって異なります。詳細については、レポートをご覧ください。 

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3928184/577cd6ca-f893-48ec-d9fa-9f737bb4d94c.png)

現在の MQ パフォーマンス レポートの一覧については、GitHub のメイン ページをご覧ください。
[https://ibm-messaging.github.io/mqperf/](https://ibm-messaging.github.io/mqperf/)
[Opensearch x Glue] AWS GlueからOpensearch ServiceにドキュメントIDを指定して格納する方法

## 概要

GlueからOpenSearch Serviceのドメインにドキュメントを格納する際に、ドキュメントIDを指定する方法が見当たらなかったため、記事を作成。

※なお、記事作成時点（2024/12）ではOpensearch Serverlessに対しては、Glue Connectionからは接続できない。
※誤りがある場合はご指摘いただけますと大変助かります。

## 前提
- Glue Connection作成済み
- Data source作成済み
- Opensearch service作成済み
- ドキュメントIDに指定したい値を持ったカラムが存在している（以下データ例の`doc_id`参照）

データ例
id|text|doc_id
------|------|------
1|私は元気です|0001
2|公園に散歩に行きます|0002
3|平日は仕事です|0003


## 操作

### Glue Visual Studioから実行する場合

1. Data targetにOpensearch Serviceを選択する。
1. Custom Amazon OpenSearch Service PropertiesのKeyに`opensearch.mapping.id`、Valueに「前提」で記載した、ドキュメントIDに指定したい値を持ったカラム名(今回だと`doc_id`)を入力する。
1. ジョブ実行すると、格納されたデータの`_id`に、指定したドキュメントIDが設定されていることが確認できる。
※ID指定で上書きも可能

### スクリプトエディタから実行する場合(dynamicFrame使用)

from_options内のconnection_optionsに`"opensearch.mapping.id": "doc_id"`を入力する

```python
XXX_node = glueContext.write_dynamic_frame.from_options(
    frame=YYY_node, 
    connection_type="opensearch", 
    connection_options={
        "opensearch.mapping.id": "doc_id", 
        その他の設定
    }
)
```
標準出力と標準エラー出力をファイル保存

標準出力と標準エラー出力をテキストファイルに保存したいことがある。

そのときのコマンドを忘れがちでググりがち。

自分で記事にすると忘れにくいかと思って書いておく。

Command >log.txt 2>&1

↓の記事を参照しました。
https://qiita.com/TomohiroSaito/items/1393ce5a01b75adcbf30
記録の力を活かした転職活動 ～未経験エンジニアの挑戦～

## はじめに
この記事は下記アドベントカレンダーのためにかいた記事になります。

https://qiita.com/advent-calendar/2024/engineering-careers-2

## 私について（執筆時点）

- **2024年3月からプログラミングスクールRUNTEQでRuby on Railsを中心に学習中**
- **ミニアプリを含めたWebアプリを5つ以上作成**
- 卒業制作のアプリについては[こちらの記事](https://qiita.com/wa-chan222/items/30e0e160d43347dc6725)をご参照ください
- **未経験からエンジニアを目指し転職活動中**


## 記録を活かした具体例

記録を習慣化することで、過去の振り返りや自己成長、そして転職活動におけるスムーズな準備につながりました。以下、詳細を記載していきます。

### 1. 1社目：キャリアエージェントとの面談を活用
契約社員として働いていた1社目では、月に1回キャリアエージェントとの面談がありました。その中で以下の振り返りを行っていました
- 今できていること
- まだできていないこと
- 次の目標

これを繰り返すことで、「次に何を頑張るべきか」が具体化し、仕事へのモチベーションが向上しました。

---

### 2. 2社目：プロジェクトごとの記録
2社目では、プロジェクト終了ごとに以下の内容をExcelにまとめていました
- **プロジェクトの概要**：どんな内容の仕事だったか
- **自分の役割**：どんな部分を担当したか
- **具体的な実績**：どんな成果を出したか

さらに、小さなことでも「できたこと・頑張ったこと」を書き出していました。例えば、
- 「資料をスムーズに作成」
- 「チーム内の情報共有を積極的にサポート」
- 「届いた材料に違和感。すぐにメーカー担当者に連絡を入れ確認した」

これらを記録することで、「自分はこんなことができている」という実感が得られ、自己肯定感が向上しました。小さな成功体験を積み重ねることで、日々のモチベーション維持に役立ちました。

---

### 3. 転職活動で役立った記録
これまでの記録は、転職活動を始める際に非常に役立ちました。特に職務経歴書の作成時に過去の業務内容や成果をすぐに確認できたことが大きかったです。

一般的に、職務経歴書の作成には時間がかかると言われていますが、記録があったことでよかったと感じた点が何点か挙げられます。
- **時間の短縮**：過去の業務内容や成果をすぐに確認可能
- **精度の向上**：具体的なエピソードを簡単に盛り込める
- **自己PRの強化**：「自分が何をしてきたか」を客観的に整理可能


## 記録の効果を実感した瞬間

記録を続けた結果、以下のような効果を実感しました

1. **自己理解の深化**  
   記録を見返すことで、自分の得意分野や改善点が明確になりました。「自分はこれが得意」と自信を持てるようになったことは、大きな成長だと感じています。

2. **目標設定の具体化**  
   改善すべきポイントや目指すべき方向性が明確になり、日々の行動に一貫性が生まれました。

3. **自己肯定感の向上**  
   記録した「できたこと」を見返すことで、自分の成長を実感。小さな成功がモチベーションの源となりました。


## 記録を始めるには

記録は誰でも簡単に始められます。以下のステップを参考にしてみてください。

1. **日々のタスクや成果をメモする**  
   簡単な箇条書きでもOK。「今日やったこと」「できたこと」を記録しましょう！

2. **月に1回振り返りを行う**  
   記録を見返して「次に何をするか」を考える時間を作りましょう！

3. **ツールを活用する**  
   Excelやメモアプリを使い、自分が使いやすい形式でまとめると続けやすいです！
   私は現在プログラミングスクールに入学してから「Notion」というものを初めて知り、こちらを活用しています！使い方にはついては下記も参考になります
   
https://notion.notion.site/Notion-Japan-da307fc67d144413989ca3dc48b6e2de

## まとめ

記録を習慣化することで、転職活動はもちろん、日々の仕事や自己成長にもつながります。自分の行動を振り返り、小さな成功を認めることで、モチベーションが向上し、自信を持って次のステップに進むことができます。

未経験からエンジニアを目指す道のりは簡単ではありませんが、過去を記録し、それを活かすことで着実に前進できると実感しています。これから転職活動を始める方の参考になれば幸いです！:relaxed:
cronとcrontab

cronはデーモンでcrontabはユーザーごとのスケジュールファイルかつそれを管理するコマンドでもある
# crontabコマンド
- 定義内容の確認
```sh
crontab -l
```
- 定義内容の編集
エディタが起動するので、編集して保存すれば定義した内容が反映される
```sh
crontab -e
```
[jQuery]ドラッグで要素の幅を変えるUIを作ってみる

# はじめに
要素の幅をドラッグして調整できるUI、SlackやNotionなどの様々なサービスでよく見かけますよね。
今回はこれをjQueryで実現してみたいと思います。

# 作成開始

### 1. 要素を用意する
まずは、幅を調整したい要素を用意し、ドラッグできるスペースを準備します。
今回は、青い部分を左右にドラッグすることで要素の幅を調整する仕組みを試みます。
(知らなかったのですが、cursor: col-resize;というスタイルを適用すると、カーソルがいかにも「幅を調節できそう」な見た目になります( ͡° ͜ʖ ͡°))
<p class="codepen" data-height="300" data-default-tab="html,result" data-slug-hash="wBwWBxz" data-pen-title="prepare_block" data-user="miyashu" style="height: 300px; box-sizing: border-box; display: flex; align-items: center; justify-content: center; border: 2px solid; margin: 1em 0; padding: 1em;">
  <span>See the Pen <a href="https://codepen.io/miyashu/pen/wBwWBxz">
  prepare_block</a> by miyashu (<a href="https://codepen.io/miyashu">@miyashu</a>)
  on <a href="https://codepen.io">CodePen</a>.</span>
</p>
<script async src="https://cpwebassets.codepen.io/assets/embed/ei.js"></script>

### 2. jQueryで幅を調節する処理を追加する
<p class="codepen" data-height="300" data-default-tab="html,result" data-slug-hash="WbexNPb" data-pen-title="change_block_width" data-user="miyashu" style="height: 300px; box-sizing: border-box; display: flex; align-items: center; justify-content: center; border: 2px solid; margin: 1em 0; padding: 1em;">
  <span>See the Pen <a href="https://codepen.io/miyashu/pen/WbexNPb">
  change_block_width</a> by miyashu (<a href="https://codepen.io/miyashu">@miyashu</a>)
  on <a href="https://codepen.io">CodePen</a>.</span>
</p>
<script async src="https://cpwebassets.codepen.io/assets/embed/ei.js"></script>


ヌルヌル動いて非常に気持ちいですね。では、実際の処理を見てみましょう。
```javascript
let isResizing = false;
let startX, startWidth;
const $box = $(".box");
const $drugBar = $(".drug-bar");

$drugBar.on("mousedown", function (e) {
  isResizing = true;
  startX = e.clientX;
  startWidth = $box.width();

  e.preventDefault();
});

$(document).on("mousemove", function (e) {
  if (isResizing) {
    const newWidth = startWidth + (e.clientX - startX);
    $box.css("width", newWidth + "px");
  }
});

$(document).on("mouseup", function () {
  isResizing = false;
});
```
処理は大きく分けて3つのイベントで行われています。

mousedown: 初期値（startXとstartWidth）を記録し、ドラッグ状態を開始。
mousemove: マウスの移動距離を計算して幅を更新。
mouseup: ドラッグ状態を終了。

ここで重要な役割を果たしているのが**clientX**というプロパティです。
clientXは、**マウスの X 座標（水平位置）を取得するプロパティ**で、ビューポート内の水平座標を表します。
このプロパティを利用し、マウスの現在位置（clientX）とドラッグ開始位置（startX）の差を計算することで、要素の幅を自在に調整できる仕組みになっています。

https://developer.mozilla.org/ja/docs/Web/API/MouseEvent/clientX

# 最後に
実際に書いてみると案外シンプルな処理だったので驚きました。
このようなUIは、ユーザー自身が要素の大きさを調整できるため、利用状況や画面サイズに応じてレイアウトを最適化できるという大きなメリットがあるので、UIデザインの選択肢として取り入れたいなあと思いました。
【必見】新卒1年目が読んで役に立ったドキュメントまとめ

# はじめに
こんにちは！
アイレット株式会社で、新卒エンジニアとして働いている森田です。
今回は、新卒1年目の私が今年読んで役に立ったドキュメントを紹介したいと思います。
皆さんが今年読んで役に立ったドキュメントも教えてください！:yum:

:::note
プログラミング初心者向けのドキュメントを紹介しています！
:::

# 新卒1年目に読んで役に立ったドキュメント
## 実践！ユニットテスト入門

https://speakerdeck.com/panda_program/shi-jian-yunitutotesutoru-men

プログラマなら誰しもが行う単体テストについてパンダくんと仙人との掛け合いを通じて、わかりやすく学ぶことができます！

単体テストのテストコードの書き方としてPHPUnitでのサンプルコードが豊富に紹介されており、PHP使いとしては大変ありがたい資料です。
PHPに触れたことがない人でも、この資料には**単体テストで重要な考え方が詰まっている**ので、是非読んで欲しいと思います。

## サクッと始めるデータベース構築【SQL / NoSQL / newSQL】

https://zenn.dev/umi_mori/books/331c0c9ef9e5f0/viewer/992632

以下の内容を学ぶことができます。
- SQLの基本文法
- データの絞り込み
- データ加工
- テーブル処理・分析
- 複数テーブルの処理
- トランザクション処理

入門編、初級編、中級編、上級編という風にレベル分けされていますが、中級編・上級編であっても業務で使う機会のある文法も多く、**かなり実践的な内容が盛り込まれている**と思いました。
これを読んで皆さんもSQLマスターになりましょう！

## HTTPを手で書いて学ぶ ファイルアップロードの仕組み

https://speakerdeck.com/ikumatadokoro/httpwoshou-deshu-itexue-bu-huairuatupurodonoshi-zu-mi

配属後の課題として画像投稿Webアプリケーションを作成しました。その一機能として「S3への画像アップロード機能」がありました。
その際に、そもそも**ファイルアップロードにはどのような処理が必要なのか**がわからなかったので、これを参考に作成しました！

**ファイルアップロードの仕組みといった概要的な内容から具体的な実装まで**が満遍なくかつわかりやすく説明されている資料です。
ファイルアップロードについては、アプリケーション開発をする上では避けられないトピックかと思うので、是非ご一読ください！


## サル先生のGit入門〜バージョン管理を使いこなそう〜
https://backlog.com/ja/git-tutorial/

チーム開発に欠かせないGitですが、はじめて触る場合はコマンド1つ実行するにしてもかなり緊張します。
上手くいけば問題ないのですが、下手なことをして元の状態に戻せなくなると大変です。
そのような状態に陥るのを避けるには正しい知識が必要です。
この資料では、各Gitコマンドの動きについて、図解でわかりやすく学ぶことができます。

よく使うコマンドは下記のようにSlackにまとめています。（一部）
![スクリーンショット 2024-12-09 21.05.10.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3936033/79e4bb51-5d87-999b-628f-8b64802dfa58.png)

## Blackbelt
https://aws.amazon.com/jp/events/aws-event-resource/archive/?cards.sort-by=item.additionalFields.SortDate&cards.sort-order=desc&awsf.tech-category=*all

各AWSサービスの概要が公式ドキュメントよりもわかりやすくまとめられているので、業務でAWSを使う際やAWS資格の勉強の際に非常に重宝しています。
クラウドサービスが専門領域に関わらずシステム開発に無くてはならないものになってきている今日、読んでおいて損はないはずです！

# おわりに
ここまで読んでいただきまして、ありがとうございました！
この記事が皆さんの学習の一助になれば幸いです。
CSSが反映されるのに半日かかる　解決法

web開発を進めていたところある日突然CSSが反映されるのに半日ほどかかるようになりました。
これでは全く開発を進めることができないので困り、先輩エンジニアに相談した結果、驚くほど簡単な解決策を教えていただきました。

それは
### 「shiftを押しながら更新する」
ということです!!


githubを使って共同開発をはじめると、CSSのキャッシュがたまり、なかなか新たな変更が反映されなかったようです。
先輩エンジニアも、一度同じ状態になりメンバー全員で話し合った結果この結論にたどり着いたそうです。


:::note info
CSSで困ったときは一度「shift+更新」を試してみましょう。ちなみに、notionの未反映は「ctrl+R」でうまくいくことが多いです。
:::

それでもダメな場合は、より強いスーパーリロードを試す、検証を閉じてリロードする、もう一度ランサーバーする、PCを再起動するなどが考えられます。




:::note alert
※キャッシュを減らすためにアンインストールをするという選択肢もありますが、その場合はアンインストールする前によく考えてください。
:::
Goodnotesのバグを解消するために誤ってアンインストールしてしまった知り合いがいました。不幸にもバックアップをとっておらず、、、（想像するだけでも恐ろしいですね）
更新されておらず、作成された背景がわからないドキュメントにどう向き合うか

## はじめに
皆さんは「更新されておらず、作成された背景がわからないドキュメント」に遭遇したことはありますか？
遭遇した時、どのように対処していますか？

最新情報に更新しますか？
それとも更新せずに放置しますか？
古い情報だから削除するという手段もあるかもしれません。

私は、新卒１年目の駆け出しエンジニアなのですが、新卒で初めにアサインされたプロジェクトでまさに「更新されておらず、作成された背景がわからないドキュメント」に出会いました。
この記事では、私がそのようなドキュメントにどう向き合ったかをまとめていきます。
拙い文章ではありますが、最後まで読んでいただけると幸いです。

## ドキュメントの情報を分類する
「更新されていない」と言っても、その情報が現状と一致しているのか、一致していないのかで対応方法が変わると思います。
そのため、まずは情報と現状が一致しているのかを泥臭く調査しました。
ここの調査は、特筆すべき点はありません。ひたすらドキュメントに書いてある内容を見ながらコードを見たり、システムを検証したりするだけです（結構つらい）。

その上で、それらのドキュメントの中にある情報が、有効期限が短く、更新頻度が高い情報（**フロー情報**）なのか、有効期限が長く、更新頻度の低い情報（**ストック情報**）なのかを分析しました。
フロー情報とストック情報は、以下の記事から知り、とても有用な考え方だと思い、採用しました。

https://kakehashi-dev.hatenablog.com/entry/2023/10/16/100000

一部、上記記事から抜粋します：

> フロー情報は、詳細な議事録やフィードバック、思考ログなど、情報の有効期限が短く、更新頻度が高い情報を指します。例えば、あるミーティングのアジェンダを参加者に共有した場合、そのミーティングの前後ではアジェンダは参加者にとって価値のある情報ですが、時間が経つにつれてその価値は失われていきます。
> 一方で、ストック情報は、PRDやDesign Docsなど、有効期限が長く、更新頻度の低い情報を指します。

今思うと、「作成日が１か月前にもかかわらず現状と合っていない」のように、分類の際に基準を設ければよかったのですが、当時は「このドキュメントあまり更新されていないな」という**感覚**で分類していきました。

## フロー情報を整理する
こうして、ドキュメントの中の情報をフロー情報とストック情報に分類することができました。
ストック情報は、現状と合っている情報ですので、そのままで構いません。しかし、フロー情報の方は現状と合っていないので対応を考えなければなりません。
ここで、考えられる対応は次の２通りでした：

- 現在の情報に更新する
- 情報を削除する

ここの情報の判断は上長に確認をし、これからも運用していかなければいけない情報なのかをすり合わせました。
しかし、上長もプロジェクトにアサインしていなかった時に作成されたドキュメントは判断が難しいものもありました。

そういったドキュメントの場合、「削除する」はかなりリスクがありました。
例えば、私の勝手な判断で削除し、その情報が後ほど参照したい情報だった時に大変なことになるのが想像できます。
そのため、私は「完全に削除する」のではなく、「アーカイブ済み」というディレクトリを作ってそこに削除したい情報を入れることにしました。
これにより、リスクを避けることができました。

## ドキュメントの分類方法をドキュメント化する
最後に、これまで行ったドキュメントの分類方法をドキュメント化しました。
ドキュメント化することで、今後も「その分類方法にしたがってドキュメントを作成する文化」ができ、継続的に運用することを期待しています。
今回の記事で行ったことが、どのくらいの効果があったのかも将来的に記事にしようと思います。
（何事も継続することが大事ですからね。継続は力なり。）

## まとめ
私は「更新されておらず、作成された背景がわからないドキュメント」に以下のような工夫をして向き合いました：

1. ドキュメントの情報を分類する
2. フロー情報を整理する
3. ドキュメントの分類方法をドキュメント化する

また、今回私はConfluenceというドキュメント管理ツールでこの記事に記載していることを実施しましたが、この知見はConfluence以外にも様々なところで活かせると思います。

他にも、ドキュメント管理のノウハウ等あればコメントしていただけますと幸いです :pray: 

## 参考
- [社内ドキュメントはなぜ更新されないのか？情報の鮮度を最小限の運用負荷で維持する「イミュータブルドキュメントモデル」のススメ](https://kakehashi-dev.hatenablog.com/entry/2023/10/16/100000)
転職活動で分かった市場価値と課題

この記事は、[転職活動して気づいた「これをやっていれば.../やってよかった」をシェアしよう by 転職ドラフト Advent Calendar 2024](https://qiita.com/advent-calendar/2024/engineering-careers-2) の 12日目の記事です。

こんにちは！:angel:

私はITエンジニアとして、約5カ月間の転職活動を経て、2024年6月に新しい職場へ転職しました。同じ職種（C#エンジニア）への転職でしたが、この経験を通じて、多くの気づきを得られました。本記事では、転職活動を通じて得られたメリットや、気付いたことを振り返ります。

## 転職活動は「大変」だけど「価値がある」

転職活動は正直、大変でした。特に、面接準備やスキル整理、自分の市場価値を再確認する作業はエネルギーを使います。しかし、それらのプロセスを通じて、以下のような大きなメリットを得られたと感じています。

### 1. 自己分析が深まった

転職活動では、「自分がこれまでどんな経験を積み、何が得意で、何が不足しているのか」を改めて整理する必要がありました。このプロセスを通じて得られたことは以下の通りです：

◆ スキルセットの棚卸し:
私の場合、C#やJavaScript、MVCフレームワークを使った開発経験はありましたが、Linux環境やクラウド技術の経験が不足していることに気付きました。

◆ 市場が求めるスキルとのギャップの確認:
面接では、「〇〇の経験はありますか？:man_tone3:」といった具体的な質問も多く、企業が中途エンジニアに即戦力を求めていることを実感。特に、API開発やGit、バッチ処理、パフォーマンスチューニングなど、実務でどのような経験をしたかについて聞かれることが多かったです。

◆ 課題の発見:
年齢やキャリアに見合った「マネジメント経験」の不足が課題であると感じました。

この自己分析を通じて、自分に足りない部分を補強するための学習計画を立てるきっかけとなりました。

### 2. スキルアップの必要性を実感

転職活動を通じて、「自分が強みとしているスキル」と「今後伸ばすべきスキル」を明確にすることができました。

◆ 既存スキルの深掘り:
例えば、C#を中心としたAPI開発経験を具体例（プロジェクトの成果や問題解決エピソード）として整理しました。これにより、自信を持って自分の得意分野をアピールできるようになりました。

◆ 新しい分野への挑戦:
転職活動を通じて、まだまだスキルが不足していることを実感しました。これらは今後の学習テーマに設定しました。

### 市場価値を知ることができた

正直、転職活動を始めるまでは自分が他社でも通用するか不安でした。
しかし、39歳、7社目の転職:skull:でしたが年齢よりも実務経験やJoinして「どのようなバリューが出せるか？」についてのほうが重要視されている分、年齢や転職回数は多少の足かせにはなりましたが、内定もいくつか貰うことが出来ました。

### 自分をアップデートするきっかけになった

転職活動を通じて、「何を学ぶべきか」「どう成長すべきか」を具体的に考えるきっかけとなりました。
面接では、将来のキャリアプランについても聞かれることが多いため、「自分がどうなりたいのか？」を見つめなおす機会になったと思います。

#### 短期目標 :dart::
コーディングのスキルをさらに磨きつつ、Linuxやクラウド技術、設計など不足している部分を強化する。

#### 中期目標 :dart::
プロジェクトリーダーや小規模なチームのマネジメントに挑戦し、リーダーシップを育む。

#### 長期目標 :dart::
技術的なスキルとマネジメントスキルを兼ね備えたエンジニアとして、開発チームを率いる。

## 最後に

転職活動は確かに大変でしたが、それ以上に多くの学びと成長を得ることができました。この経験を通じて、自分のキャリアの方向性がより明確になり、次のステップに進むための準備が整いました。

同じように転職活動を考えている方にとって、本記事が少しでも参考になれば幸いです。皆さんもぜひ、自分のスキルや経験を振り返り、キャリアの可能性を広げてみてください！