OmniAICreator/Qiita-1.07M huggingface dataset:
【Laravel】プロジェクト事前準備②～Composerインストール

# Composerとは
Laravelのパッケージ・ライブラリ管理ツールです。
依存関係にあるパッケージを不足なくインストールしたり、バージョン管理なども容易に
行うことができます。
# 前提条件
PHP（XAMPP）のインストールが完了していること。
以下の記事の続きです。

https://qiita.com/moko_san/items/b3b7d6000db68735aa14

# 1. Composerのインストール
### ① インストーラのダウンロード
**(1) 以下サイトにアクセスします。**
　　https://getcomposer.org/download/
**(2) [Composer-Setup.exe]をクリックします。**
![Composer02.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2846445/a6babaa3-dde8-252b-d061-6f3811fde4df.png)
**(3) エクスプローラーが開くので、インストーラの保存先を選択し保存します。**
        ※私は「ダウンロード」ディレクトリに保存しました。
### ② インストール
**(1) ①(3)で保存したインストーラを起動します。**
**(2) 手順に従い、インストールを進めます。**
　**・インストールモードの選択：[Install for all users(recommended)] を選択**
 　　→Composerがシステム全体にインストールされることで、全ユーザアカウントから
　　　利用可能になります。
 　　→これにより、同じマシンを利用するユーザが各自Composerをインストールする
　　　必要がなくなり、設定なども一か所に集約できることで管理しやすくなります。
 ![Composer03.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2846445/326884c4-1b22-cd79-da11-ec0debdae41c.png)
　**・インストールオプションの選択：[Next] を選択**
　　→Composer関連ツール一式（アンインストーラ含む）をインストールします。
  　　　Composerのみをインストールしたい場合に「Developer mode」を有効化します。
![Composer04.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2846445/ba109a98-1841-6633-4804-a30b9de2ef3d.png)
　**・インストール先のディレクトリを選択：[Next] を選択**
　　※今回はデフォルトの保存先で進めましたが、適宜変更してください。
   ![Composer05.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2846445/c60307ab-bab9-eac6-9589-6036d9fd7941.png)
  **・プロキシサーバ利用設定：[Next] を選択**
　　※プロキシサーバを経由してインターネット接続する場合は適宜変更してください。
  ![Composer06.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2846445/fb0ef3ae-b1ae-5e98-826e-3a96eddd740d.png)
  **・インストール内容確認：[Install] を選択**
 ![Composer07.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2846445/97365724-076e-8ee3-18ff-1349059f0364.png)
  **・インストール実施前のお知らせ：[Next] を選択**
　　→環境変数が変更されたため、コマンドプロンプトを再起動してcomposerコマンドを
　　　実行する旨が記述されています。
  ![Composer08.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2846445/4da3d4e2-2c28-abf9-c419-1dd716543046.png)
  **・インストール完了：[Finish] を選択**
![Composer09.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2846445/0e9e405f-478e-5ada-9059-925b0408fb46.png)
### ③ インストール後確認（コマンド実行）
　Composerが正しくインストールされたかどうかを、コマンドプロンプトで```composer -V```
　コマンドを実行することで確認します。
　※composerのパスを通す必要がない理由：
　　前記事の手順でPHP（XAMPP）のパスを手動で通しましたが、Composerのインストール
　　先ディレクトリはパスを通したディレクトリの配下のため既にパスが通っている
　　状態です。
**(1) コマンドプロンプトを開きます。**
　※私は[Winsows] キー＋ [R] で[ファイル名を指定して実行] → ```cmd```入力 →
 　　[OK] ボタンクリック の手順で開いています。
**(2) コマンド``` composer -V ```を実行し、インストール済みのComposerバージョン情報が**
　　**返ってきたら確認終了です。**
![Composer10.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2846445/c01f307e-da32-bd19-cda7-63f2811dbc8a.png)
# 参考
### パッケージ管理ツールについて
https://qiita.com/s_taki/items/1d94e5e9544ebbf32778
### Composerについて
https://info.winschool.jp/detail87/
### インストール手順について
https://zenn.dev/hainare/articles/792c07f76cb005

https://magazine.techacademy.jp/magazine/11521

http://www.y2sunlight.com/ground/doku.php?id=composer:1.9:install
ubuntuですぐにシャットダウンする方法

お疲れ様です。秋並です。

ubuntuでは、`shutdown`コマンドでシャットダウンできますが、オプションがないとコマンドが実行されてから実際にシャットダウンされるまで一定時間かかります。

<br>

以下のコマンドを実行すると、時間を待たずにシャットダウンが実行されます。

```bash
sudo shutdown -h now
```
特定のファイルをGitの管理対象から外したい時に使う、git rm --cachedと.gitignoreの違い

# この記事を書いたきっかけ
Gitで管理していた余計なファイルを.gitignoreに追記してコミットしたのに、なぜかGitの管理に残ったままだったことがありました。おかしいな〜と思っていろいろ調べてみました。すると、なんでも.gitignoreに書けばGitが無視してくれるというわけではなく、初めから.gitignoreに書いておくか、あとからGitの管理から外すコマンドを実行する必要があると知りました。
今回は特定のファイルをGitの管理対象から外したい時に使う２つの操作について簡単に勉強します。

# git rm --cachedと.gitignoreの共通点と相違点
### 共通点
**Gitの管理対象から外す**
`git rm --cached`コマンドと.gitignoreファイルは、
どちらもファイルをGitの管理対象から外すために使用します。これにより、そのファイルの変更は追跡されなくなります。

### 相違点
**git rm --cachedコマンドの場合**

既にGitの管理下にあるファイルをGitの管理対象から外すコマンドです。つまり、過去にコミットされたファイルをリポジトリから削除し、以降のコミットでは追跡されないようにするために使用されます。
このコマンドを実行すると、ファイルは次回のコミット時にリポジトリから削除されますが、ワーキングディレクトリには残ります。
一度、Gitの管理対象に入れてしまったけど、ただ管理対象から外したいだけの時はこのコマンドを使います。

**.gitignoreファイルの場合**

まだGitの管理下にないファイルを追跡しないように指定するときに使用します。既にコミットされているファイルに対しては効果がありません。
.gitignore に記載されたパターンに一致するファイルやディレクトリは、新規に追加された場合にGitによって無視されますが、既にコミットされているファイルは引き続き追跡されます。


### 具体例
1. 既にコミットされているファイルをGitの管理対象から外す場合
`git rm --cached <ファイル名>`
`git commit -m "Remove <ファイル名> from version control"`

2. 初めから追跡したくないファイルを指定する場合
`echo "build/" >> .gitignore`
`echo "*.log" >> .gitignore`

# まとめ
**git rm --cached**コマンドは既にコミットされたファイルをGitの管理対象から外すためのコマンドであり、 **.gitignoreファイル**はこれからコミットされるファイルを無視するための設定ファイルです。
既にリポジトリに含まれている不要なファイルを管理対象から外したい場合は、 git rm --cached を使用し、今後追加される不要なファイルを無視したい場合は .gitignore に記載すればオッケーです。
[Dify]DifyでHyDEを作成してみた

## HyDEとは？

HyDEは簡単にいうと、**質問を一回LLMに回答させて、その内容でベクトル検索し、結果をコンテキストとして再度LLMに回答させる手法**である。

元論文の図だとこんな感じ。
![](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/376115/a30e20cd-d0e2-2628-cdfb-e601b4a660c5.png)
https://arxiv.org/pdf/2212.10496

1. まずは一番左の黄色と緑のボックスの内容でGPTに問い合わせます
1. 次にGPTの回答であるオレンジのボックスの内容をContrieverでベクトルにエンコードし、その内容で検索する。そうすることで青色ボックスの中身であるドキュメントを取得する
1. それを用いて回答する

### HyDEの精度
赤枠部分だけ解説すると、HyDEの方がBM25や生のContrieverだけより精度高いですね。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/376115/df08ee08-5d56-4935-59b7-785986234c84.png)
https://arxiv.org/pdf/2212.10496

### HyDEを使う上で気をつけること
これだけ見るとすごいのですが、気をつけるべき時もあります。
以下の表を見てください。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/376115/8a7eceab-4be1-5614-aa8c-809cc31e7111.png)
https://arxiv.org/pdf/2212.10496

気づきましたか？　実はベンガル語ではHyDEで大きく精度が変わってないのです。
論文中にも書かれていますが、
LLMがベンガル語自体の学習があまりできてなく仮想回答の精度が悪いことで、ドキュメント検索がうまくいかないことで精度があがらないのです。
つまり、ある程度の学習がうまく行っているパターンではHyDEは有効ですが、そうでないときはあまり有効でないのだと思います。
有効でない場合にHyDEを使ってしまうとただ単に回答が遅くなったり、最悪精度が悪くなる可能性があります。
使うときは慎重に使いましょう！

## Difyで構築

### 全体像

全体像はこんな感じです。
![スクリーンショット 2024-06-20 23.18.55.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/376115/0fd00fe3-0722-d0b7-e35c-a0c3c6dde728.png)

流れは簡単です。
1. まずは質問を仮想回答用LLMに問い合わせます
1. １の結果を使ってベクトル検索し知識を集めます。
1. それを用いて回答します。

### 仮想回答　& 知識取得

仮想回答プロンプト:
```
Please write a passage to answer the question 
Answer in English.
```
検索ドキュメントに英語が多い場合はここは英語で出力してた方がいい感じになります。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/376115/3b65a82d-6b64-b300-592d-e8d74eeb5cc5.png)

### 本回答

本回答プロンプト:
```
 Please answer the following questions according to the instructions on the following information.Answer in Japanese.
{{#context#}}
    Question: {{#sys.query#}}
```

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/376115/6deb5e37-a953-7703-c891-b37d818e6e72.png)


### 最後に

Xやってるので気になる方はフォローお願いします。
https://x.com/hudebakonosoto
有意差とは

# 有意差とは
有意差とは統計の文脈である事柄の起こる確率が本当に意味のある確率なのかを判断する指標のことです

また、有意差は数値で表されるわけではなく、`有意差がある` or `有意差がない`の二択で表現されます

...？？？

## 具体例
コーラの製造会社を例を挙げてみましょう

この会社は一本あたり500mlのコーラを10000本製造しています
あるとき一人の社員が一本あたり500ml入ってなくね？と言い始めました
今からこの社員が言っていることが正しいかを検証していきましょう

このとき、帰無仮説と対立仮説は以下のようになります


> 帰無仮説：コーラ一本あたりは500mlに設定されている
> 対立仮説：コーラ一本あたりは500mlに設定されていない

製造するコーラ全ての量を測るのは現実的でないです
標本として100本のコーラを調べてみると、平均505mlでした

このとき、帰無仮説との差5mlは大きいのでしょうか、小さいのでしょうか

この**5mlをどう捉えたらいいのかを判断を定量的に判断する**のが有意差です

## 有意水準とP値
有意差を判断するため出てくる値が有意水準とP値です

ちなみに有意水準とP値と有意差は以下のような関係になります

<img width="720" alt="image.png (49.6 kB)" src="https://img.esa.io/uploads/production/attachments/13979/2024/06/20/137443/4c87edec-5911-4dda-b231-7033ff63c07a.png">




### 有意水準とは
有意水準とはP値と比較するための基準のことです

もっというと有意水準とは有意差がある or 有意差がないと判断するためのP値の境界線となる、閾値的な値のことです

有意水準が高ければ高いほど標本が母集団から離れている可能性を許容することになります

有意水準 > P値が成り立つとき、有意差ありと判断できます

### P値とは
P値とは帰無仮説が正しいとした場合、サンプルとした**標本が帰無仮説からなる母集団からどれくらい離れているかを確率で表現した値**のことです

先ほどの例で言うと、`100本のコーラを調べて平均505mlとなる標本をとってくる確率`のことです

P値と有意水準を比較して有意差を求めていきます

例えばP値が0.03だとして有意水準は一般的使用される5％としましょう
このとき有意水準 > P値が成り立つ、つまり取ってきた標本95％でよっぽど母集団からはずれていないだろうとできるため、「帰無仮説：コーラ一本あたりは500mlに設定されている」は棄却できます



# 参考記事
https://www.youtube.com/watch?v=10xFYKnCt34&ab_channel=%E3%82%B9%E3%82%BF%E3%83%93%E3%82%B8%E3%80%90%E8%AA%B0%E3%81%A7%E3%82%82AI%E3%83%87%E3%83%BC%E3%82%BF%E3%82%B5%E3%82%A4%E3%82%A8%E3%83%B3%E3%82%B9%E3%80%91by%E3%82%A6%E3%83%9E%E3%81%9F%E3%82%93
Node.jsで標準入力から情報を取得するコードについて

## アジェンダ
以下のコードは、Node.jsを使って標準入力（キーボードなどからの入力）を読み取るために使用されるコードです。

```js
const input = require("fs").readFileSync("/dev/stdin", "utf8");
```

このNode.jsの標準入力の書き方について分解してまとめます。

## `require("fs")`
`require` は、Node.jsでモジュール（追加の機能）を読み込むための関数です。
`"fs"` は、ファイルシステム（File System）の略で、ファイルやディレクトリを操作するためのモジュールです。

## `readFileSync("/dev/stdin", "utf8")`
### `readFileSync`
`readFileSync` は、ファイルを同期的（プログラムが次に進む前に、完全に読み取る）に読み取る関数です。つまり、ファイルの読み取りが完了するまで他の処理はブロックされます。

### `"/dev/stdin"`
`"/dev/stdin"` は、UNIX系のシステム（LinuxやMacなど）で使われる特別なファイルで、標準入力を指します。つまり、ここからデータを読み取ることになります。Windows環境では、通常 `process.stdin` を使用します。

### `"utf8"`
`"utf8"` は、読み取るデータの文字エンコーディングを指定します。UTF-8は多くの文字（日本語を含む）を扱えるエンコーディング方式です。

## 全体を合わせると
```js
const input = require("fs").readFileSync("/dev/stdin", "utf8");
```
このコードは、`fs` モジュールを使って、標準入力からUTF-8形式でデータを読み取り、その内容を `input` という変数に格納しています。

## まとめ
- `require("fs")`: ファイルシステムモジュールを読み込む
- `readFileSync`: ファイルを同期的に読み取る関数
- `"/dev/stdin"`: 標準入力を指すファイルパス
- `"utf8"`: 文字エンコーディング方式

## 参考
- [標準入力（stdin）とは - 意味をわかりやすく - IT用語辞典 e-Words](https://e-words.jp/w/%E6%A8%99%E6%BA%96%E5%85%A5%E5%8A%9B.html)
FreeBSD 14.1 + KDE5, Plasma インストール手順(2024年6月)

#### そもそものきっかけ
13.2 で使用していたのだが、doas freebsd-update -r 14.1-RELEASE upgrade なるコマンドで、14.1にメジャーバージョンを上げたら、Xが起動しなくなった。それではと原因を探ることなく、クリーンインストールすることにした。という軟弱な理由です。一年に1回くらい、インストールしても良いかなと考えています。
もう一つの理由は、120GBのSSD が一つ余ったので、合計3つのSSDを一体化してセットしてみよう。250+250+120 の3台を使用してのセットアップを行ってみた。

### FreeBSDのインストールイメージ
USBメモリーから起動したいので、下記名称のUSBメモリー起動用イメージをダウンロードしてWindows の rufus で書き込みして作成
FreeBSD-14.1-RELEASE-amd64-memstick.img

### コンソールモードのインストール
は、ものの10分もしないうちに完了してしまう。これはいつものこと。以下のパッケージを、pkg install コマンドでインストールする。
nano : これが一番最初
 doas: sudo の代わり、doas.conf は、permit :wheel の一行でOK 編集を nano で行える。
 neofetch: お遊び
 lftp: 自宅ftpサーバーに接続するため。過去の設定ファイルをget するため。
 kde5 を先にインストールすれば、xorg-serverもインストールされるので、xorgを別途インストールすることは不要。plasma も一緒にインストールされていました。
 sddm: Xディスプレイマネージャー　
 ja-font-mplus-ipa: 入れておいた方が良いフォント。Xでの日本語表示、firefox もこのフォントで綺麗です。
 ja-font-vlgothicというフォントも見えましたので入れてみましたが、これはもしかして Vine Linux で採用されていたフォントかな?　少し細面のフォントでメニュー表示はこちらの方が好みかな。懐かしいフォントです。  
 nvidia-driver-470:　メインマシンのINTEL Core i5-10400 に内蔵の UHD graphics 630 では、ディスプレイ標準の解像度が得られず、古いグラフィックカード nVidia GT710 を代わりに使う。nvidia-driver の最新版は、550 という表示であったが、GT710 では動かず、昨年の事例を参考に 470 を使うことにして入れ替えた。pkg install nvidia-driver-470 で入る。
　firefox: ウェブブラウザー。日本語フォントを入れていないと文字化けします。
```
$ cat /usr/local/etc/X11/xorg.conf.d/driver-nvidia.conf
Section "Device"
　　　　        Identifier "NVIDIA Card"
        　　　　VendorName "NVIDIA Corporation"
        　　　　Driver     "nvidia"
EndSection
```

を記述する。
```
$ cat /etc/rc.conf
hostname="○○○○"
keymap="jp.kbd"
ifconfig_re0="DHCP"
sshd_enable="YES"
dumpdev="AUTO"
kld_list="nvidia.ko nvidia-modeset.ko"
linux_enable="YES"
dbus_enable="YES"
hald_enable="YES"
sddm_enable="YES" <--- X環境を入れてから(kde5, sddm & plasma等インストール後)追加する
```

### 次は、X　に何を入れるか?
pkg install コマンドで、
ja-fcitx5-anthy: 日本語入力変換
fcitx5-configtool: 日本語入力の設定ツール
```
$ cat .xprofile
export LANG=ja_JP.UTF-8
export LC_ALL=ja_JP.UTF-8
export LC_CTYPE=ja_JP.UTF-8
export GTK_IM_MODULE=fcitx5
export QT_IM_MODULE=fcitx5
export XMODIFIERS=@im=fcitx5
export DefaultIMModule=fcitx5
```
これで日本語入力ができます。anthy と mozcの比較ですが、なぜmozcでないのか?　バーに表示されるmozcのアイコンに色が着いていて好きでない。というそれだけの理由です。anthyのクラウン型のおとなしいアイコンが好き。変換効率に関しては、あまり差が無いような気がします。実用上は、どちらも使えると思います。

#### そして、LibreOffice を入れよう
さあて、14.1 もリリースされてから日が経っており、pkg群に libreoffice が、含まれています。インターフェースの日本語化は、おいおい進めることにします。

#### python3.9
ここまでインストールすると、python3.9 がインストールされています。私は、idle という環境で使うのが好みなので探すと、idle3.9 というパッケージがインストールされていますが、それだけでは起動しません。毎回なのですが、tkinter も入れてくれよメッセージが表示されるので、pkg search しますと、py39-tkinter-3.9.18_7　というパッケージが見つかりましたので、   # pkg install py39-tkinter で、tkinter をインストールすれば、idle3.9 が起動し、pythonスクリプトを記述して実行する環境が得られます。

#### NAS中の音楽ファイルの再生<解決!>
NASに保管してある音楽ファイルの再生は、VLCから可能でした。NASサーバーで、minidlna が稼働していることを思い出しまして、VLCで、ローカルネットワーク --> ユニバーサル　プラグ&プレイを選択しますと、minidlnaサーバーが見えるようになります。そこから再生でOKでした。

以上
いまさらdockerを始めてみる⑥

# 前回まで
what is nextのUsing the build cacheとMulti-stage buildsを読んだ。cacheを使うことでbuildが早くなるよ、containerのステージ？段階？を複数に分けることで最終的なコンテナサイズが小さくなるよとのことだったが両方とも深く理解するには至らなかった。また、昨日は家系ラーメンを晩御飯に食べて、かえってすぐちょっとねるつもりが起きたら朝だったという地獄であったため投稿できなかった

# Pubulishing ports
dockerは孤立した環境であるためポートを開けないと通信することができない
```docker run -d -p HOST_PORT:CONTAINER_PORT nginx```

はnginxというimageに対して、バックグラウンドで(-d)実行かつ、HOST_PORTへのリクエストをCONTAINER_PORTへ向ける(be forwarde)という意味になる。

ホストのポートはなんでもいいよという場合は
```docker run -p 80 nginx```
となり、ephemeral portとして開放するホストのポートが適当に選ばれる。
それは```docker ps```で確認が可能

try it out
```docker run -d -p 8080:80 docker/welcome-to-docker```
というコマンドは
```
services:
  app:
    image: docker/welcome-to-docker
    ports:
      - 8080:80
```
というyamlファイルを'docker compose up'するのと一緒だよと。
特に追体験する必要もなさそうなのでスキップ

# Overriding container defaults
Explanation
dockerを起動するときのdefaultのコマンドを変更？追加？することができますと。
portを開放したり、環境変数を設定したり。利用するリソース(メモリ, CPU)を制限したり。

try it out
dockerはby defaultではbridge networkと呼ばれるnetworkに接続される。
特定のシナリオにおいてより高度なネットワークのconfigを制御した場合は自分で定義できる
mynetworkdでdockerを起動するには以下のコマンド
```docker network create mynetwork```
```docker run -p 5432:5432 --network mynetwork postgres```
beidgeとcustom networkの違い
- bridgeはIPアドレスのみで互いにcommunicateする。custom networkではnameやaliasが使える
- bridgeは中に入ってるもの同士全部が通信できる

環境変数とかentrypoint(起動時に絶対実行されるプログラム？コマンド)←docker runで上書きできないのyamlの書き方
```
services:
    postgres:
        image: postgres
        entrypoint: ["docker-entrypoint.sh", "postgres"]
        command: ["-h", "localhost", "-p", "5432"]
        environment:
            POSTGRES_PASSWORD: secret
```

以上！コマンド押して追体験する気にならない。そろそろドキュメントの後追いじゃなくて、
自分で何かアウトプットを作ったほうがいいかも。明日リモートで時間あるから頑張ろうかな。
今日はここまで
【アイディア】草が生える目覚まし時計


## 前書き

これはアイディアです。
コードはありません。

## どんなの？

* スマホアプリ
* 基本的には目覚まし時計と同じ機能
* 夜寝る前にﾎﾟﾁｯと押してアラームをセットする
* 朝にアラームが鳴るのでﾎﾟﾁｯと押して止める
* ﾎﾟﾁｯとした瞬間にその時間がファイルに書き込まれ、GitHubにコミット&プッシュされる
* 睡眠/起床時間がGitHubでも確認出来て便利（適当）
* つまらんのでメモ機能も付けておく
  * もちろんコミット&プッシュされる
  * メモとアラームを関連付けられると尚よい（3時におやつを食べる。みたいな）
* ほぼ毎日使うアプリなので毎日草が生えて優越感に浸れる（適当）
* 個人情報が漏れそうなのでプライベートリポジトリを使う
  * ちなみにプライベートリポジトリでもちゃんと草は生えるらしい
* おまけで大草原不可避機能と称して草偽造機能をつけておく

## 別案

なんならアラーム機能はいらん。スマホのスリープのON/OFFのイベントをキャッチできるなら、その時にコミット&プッシュをするスマホの使用時間管理アプリとしてもいい。

こっちのほうが草が稼げそうだ。

## ターゲット層

* 偽造せずに草を楽に生やしたい人
* 今までの睡眠/起床時間を知りたい人

## インスパイア元

https://qiita.com/topi_log/items/d362fefb9e006773eac0

## チラ裏

パッと見の草の量で人を評価する人がいなくなるといいね。
Google Colaboratory Pro+でNotebookをバックグラウンド実行する

# 1.背景
Colab Pro+に課金して使いたかった機能の一つ、バックグラウンド実行機能の使い方をメモします。
最初に申し上げると記事にするほどでもないほどチョーカンタンでした。

# 2.方法
### 処理実行してブラウザ閉じる。
たったこれだけ。（使いやすい！！）

再びNotebookを起動すると下記表示が現れます。しばらくするとバックグラウンドで実行してくれていたセッションに接続されます。
![スクリーンショット 2024-06-20 22.51.38.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3820324/015bc2e7-152e-c3b2-300d-257da9de661f.png)

# 3.終わりに
以上、記事にするほどでもないメモ書きでした☺️
React NativeでMetroのキャッシュをクリアする方法

## はじめに
React Nativeで開発中に、書いてあるコード通りにビルドできていないかも？と思われる挙動がありました。
先輩に質問したところ、「Metroのキャッシュを消した方がいいかもね」とアドバイスをいただきました。
初めて使うコマンドだったので備忘録として残します。

## React NativeでMetroのキャッシュをクリアする方法
結論からいきましょう！！
ターミナルで以下のコマンドを打てばOK🎉
```bash
npx react-native start --reset-cache
```

## Metro Bundlerとは
React Nativeのアプリケーションをビルドするためのツールです。
以下、Metroと呼びます。

https://metrobundler.dev/

## なぜキャッシュをクリアする？？
Metroはビルドを高速化するために、以前のビルド情報をキャッシュしています。
このキャッシュが、新しくライブラリを導入したときやソースコードに大規模な変更が入ったときなどに、問題を起こしてしまうことがあります。キャッシュしている古い情報を元に、ビルドしてしまうことがあるということですね😱

```bash
npm start -- --reset-cache
```
このコマンドを実行すると、Metroが保持しているキャッシュデータが削除され、次のビルド時にすべてのファイルが再解析されます。

## いつキャッシュをクリアするか？？
キャッシュをクリアするのはエラーの原因が全くわからないときの最終手段だと思って良さそうです。
ソースコードやファイルに変更を加えたにもかかわらず、それがアプリケーションに反映されない場合は、キャッシュをクリアしても良いかもしれませんね🎉

## 終わりに
実際にコマンドを実行し、キャッシュをクリアしてから再度ビルドしてみたところ、「キャッシュないけどいいの？」的なエラーが出ましたが、問題なくビルドできました。
結局書いてあるコード通りにビルドできていなかったわけではなく、別のエラーだったのですが、学んだ方法は覚えておこうと思います！
[Rails] エラーメッセージを日本語で設定する

# はじめに
フォームの入力で、バリデーションで失敗した際に、エラーメッセージを表示させると思います。
その場合、デフォルトだと英語になります。

日本語で表示させるためには、設定が必要なのと、メッセージも自由に記載することができます。
今回はその内容をアウトプットいたします。

# 設定

`config/application.rb`に、以下を記載いたします。

```rb:config / application.rb
config.i18n.default_locale = :ja
```

続いて、`config/locales/ja.yml`に記載いたします。

```yml:config / locales / ja.yml
ja:
  activerecord:
    attributes:
      hoge_model:
        fuga_column: 'fugaカラム'
    errors:
      models:
        hoge_model:
          blank: '%{attribute}は必須項目です'
          attributes:
            fuga_column:
              taken: '重複しています'
              invalid: '不正です'
```

`activerecord:`に続く、`attributes:`配下に、モデルとカラム名を記載します。
そうすると、記載の通りのカラム名が返ってくるようになります。

これで、モデルのカラム名を日本語化することができるようになりました。

また、`errors:`に続くよう、モデルとエラー内容を記載すれば、そのバリデーションエラーになった際、記載のメッセージが表示されるようになります。

- blank: `presence: true`
- taken: `uniqueness: true`
- invalid: `format: { with:...`

上記のようなバリデーションがあった際に、ja.ymlで設定していると、該当のメッセージを返してくれます。
ここで、設定したいオリジナルを設定しましょう。

バリデーションのメッセージは、モデル自体にも設定できますし、カラムごとに設定することもできます。


# まとめ
`ja.yml`は、かなり汎用性が高いです。
ここでアプリケーションに沿った内容を設定して、適切なメッセージを表示するようにしましょう。

最後までご覧いただき、ありがとうございました。
正規表現メモーその2

個人的「質はともかく継続する」１３日目です

## 正規表現メモーその２

### 基本

__or__
"文字１|文字２"で表す
いずれかの文字が対象になる

a|b|c
とすると
a,b,cのいずれか１文字にマッチ

__範囲指定__
"¥[0-4¥]"で表す
範囲内の文字が対象になる

[0-4]
とすると
0,1,2,3,4のいずれか１文字にマッチ
0|1|2|3|4
と同じ結果になる

__量指定（繰り返し）__
"{繰り返し数}"で表す
指定した繰り返し数の文字が対象になる

t{2}
とすると
tt
となっている文字にマッチ

¥[0-4¥]
とすると
0-4のいずれかが３回続く文字にマッチ
対象が以下ならば
1325592366499
132のみがマッチする、23、4は３回続いてないのでマッチしない

__否定__
"^"で表す

¥[A-Z¥]
とすると
アルファベット大文字を除く事ができる

### 量指定

#### 欲張り量指定

最長の文字にマッチしようとすること。
この例では一番最後のxが終端になってマッチする。

```txt
----------------------
文字  0aaYYxddx8bdx99
----------------------
検索  Y.+x
----------------------
結果  YYxddx8bdx
----------------------
```

#### 控えめな量指定・最小量指定

最短の文字にマッチしようとすること。
この例では一番最初のxが終端になってマッチする。

```txt
----------------------
文字  0aaYYxddx8bdx99
----------------------
検索  Y.+?x
----------------------
結果  YYx
----------------------
```

#### 範囲量指定

繰り返しの繰り返し。
n回からm回の繰り返し。

x{2,3}
とすると
xx|xxx|xxxx|
と同等の意味になる。

最大回数をなくすと無限大になる。
x{0,}
とすると
x*
とおなじになる。

|exp|count|equal pattern|
|---|-----|-------------|
|x{0,}| 0 >= | x* |
|x{1,}| 1 >= | x+ |
|x{0,1}| 0 or 1 |x?|
|x{2}| 2 = | 22 |
|x{1,3}| 1 >= and 3 <= | x¥|xx¥|xxx|

### 先読み・後読み

()[https://abicky.net/2010/05/30/135112/]

#### 先読み

指定した文字の直後に
指定した文字があるパターンにマッチする。
たとえば
d(?=ay)
ならば、dの直後にayがある文字(ayは含まない)にマッチする。


文字列
abracadabra

検索値
a(?=..a)

結果
**a**bracad**a**bra

便宜的に最初のaをa1,次をa2として
**a1**br**a2**
a1から初めて３文字目がa2なのでマッチする。

#### 否定先読み

先読みの否定。
指定した文字の直後に
指定した文字が__ない__パターンにマッチする。

たとえば
(?!0120)¥d{4}
ならば、直後に0120がこない４桁の数字にマッチする。

#### 後読み

指定した文字の__直前__に
指定した文字があるパターンにマッチする。
たとえば
(?<=no)more
ならば、直前にnoがある(noは含まない)にマッチする。

例
aamoreaaano**more**aaa

#### 否定後読み

指定した文字の直前に
指定した文字が__ない__パターンにマッチする。
たとえば
(?<!no)more
ならば、直前にnoがない(noは含まない)にマッチする。

例
aa**more**aaanomoreaaa
プログラマーがデザイナーと仕事をするときに気をつけたいこと

# はじめに

「美大式ビジネスパーソンのデザイン入門」が素晴らしかったので、
デザイナーの方たちと仕事する時に気をつけたいことを自分なりに言語化したものになります。

https://www.shoeisha.co.jp/book/detail/9784798183183


なお、書籍からの感化だけではなく
自分が携わっているプロジェクト(PJ）を通して感じていることを合わせた２章でまとめています。
1. PJを通して感じていること
2. 書籍「美大式ビジネスパーソンのデザイン入門」を読み終えて


## PJを通して感じていること


### HRTの精神を忘れない

こちらの書籍で有名なHRTです。
HRT = 「Humility（謙虚）」、「Respect（尊敬）」、「Trust（信頼）」

https://www.oreilly.co.jp/books/9784873116303/



私たちが1行のコードを書くのに1日かけたことがあるように、
出来上がってきたデザインが（我々からみて）シンプルだったとしても、我々からは見えない多様なプロセスを得て出来上がってきたものです。

成果物に対して敬意を払い、建設的に議論をするように心がけたいです。

### お手並み拝見しない

HRTの精神も、過度になると相手に対して「お手並み拝見」モードになる危険があると思っています。

https://qiita.com/developer-kikikaikai/items/9e08fe0f8ee0eebaccab

プログラマーに得意不得意があるように、デザイナーだって同じはずです。

もし我々が一緒に仕事をしているデザイナーがネイティブアプリのデザイン経験が浅かった場合、
普段からネイティブアプリの開発をしているプログラマーの方が
デザインのTipsやユーザがつまづきやすいポイントなどを過去事例から知っていることがあるかもしれません。


HRTが間違った方向にいって
「自分はデザインのことは門外漢だから(Humility)、デザイナーの腕前見せてもらおうか(Trust)」

なんてスタンスでいたら対等な議論ができませんし、
もしかしたら普段からネイティブアプリを開発しているあなたなら、
いいレスポンスができるかもしれません。


「プログラマーからこんな指摘するのは失礼かな」
「上がってきたデザインはデザイナーの考えたものだから、完璧なはずだ」
と感じて建設的な議論ができなくなっては勿体無いです。

議論をしていた未来ではより良いプロダクトが生まれていたとしたら、悲しいですね。

プロダクトの成功を考えて、プログラマーとデザイナーが対等に同じ方向を向いて議論できる、HAPPYなチームを目指していきたいです。



## 書籍「美大式ビジネスパーソンのデザイン入門」を読み終えて
今年読んだ本の中で上位に面白かったです。

「デザインはあいまいなもの」
「デザインは主観的で議論なんて出来ない」
こんな考えを払拭してくれる本でした。

全ての章が面白かったのですが
デザイナーとコミュニケーションをとる上で気をつけたいな　と思った点は以下３点です。
1. 目的から話す
1. 漠然とした言葉遣いをしない
1. 具体的すぎる指示をしない

### 目的から話す
例えばダイエットでお腹を凹ましたくてジムに行っていきなりインストラクターに
「腹筋を鍛えるトレーニングを教えてください。」と伝えたら、
いくつかのバリエーションのトレーニングを教えてくれるかもしれません。
しかし、そもそもお腹が出ている原因が姿勢の悪さや腹筋以外にあった場合、根本解決にはなりません。
ジムにきた目的からトレーナーに話せば、
姿勢を良くするためのトレーニング方法など自分では思い浮かばなかった打ち手が返ってきたかもしれません。

デザイナーの方とコミュニケーションをとるときも同じで、
自分が見つけたデザインをベースに「こういうものを作りたい」といきなり伝えるのではなく、
目的を伝えた上で一緒に打ち手を考えてもらうようにしていきたいです。

### 漠然とした言葉遣いをしない
「かっこいい感じ」「かわいい感じ」などの言葉は便利ですが、
かっこいいにもストリート系のかっこよさや、モード系のかっこよさなどがあります。
人によって認識の違う言葉を使わずに、
一歩踏み込んで詳細に伝えて自分の意図が正しく伝わるようにしましょう。

私も、できるだけ詳細な解像度の高い言葉で伝えるよう努力していきたいです。
（その時が来た時に出来るかどうかは、自信がありません。）

### 具体的すぎる指示をしない

目立たせたい文字があったとして
「この文字を太くしてください」
と伝えるのではなく、
「ここをもっと強調させたいのですが、どんな方法がありますか」
と打ち手を教えてもらう（一緒に考える）ようにしましょう。

文字を目立たせる方法は太字にする以外も、色を変える/下線を引く/周りの文字を薄くする/配置を変える
など色々な方法があります。
自分で思い浮かんだ打ち手をそのまま伝えるのではなく、
目的ベースで会話をしていくよう心がけていきたいです。




## 書籍「美大式ビジネスパーソンのデザイン入門」の紹介
筆者の稲葉さんはデザインの役割を次の３つに定義し、
それぞれの役割をわかりやすく掘り下げてくれました。
1. 視覚から情報を伝える
1. 感性的価値を作る
1. 人間中心で考える

また、これらを経営の川上から意識していくことが大切だと説いています。
気になった方はぜひ書籍を手に取ってみてください。


私にっとてのデザイン入門最初の1冊だったので
今は偏りがあるかもしれませんが、少しづつでもデザインに関する知識を広げていけたらいいなと
思うきっかけになりました。
また、人とコミュニケーションをとるときの気づきもたくさんありましたので、
読んでよかったです。
1 on 1の効果的なやり方

# はじめに
この記事は部下側の目線で、どうすればより良い1on1が出来るようになるか記載した記事です。

**・背景**
・月一で1 on 1をやっている
　SIer で普段は客先常駐

・子供の世話とかなんやかんやで、自宅での社内作業は21:00以降が多い
　なので、1 on 1 MTGは21:00とか21:30とかからが多い
　　※ホント上司の方々にはご迷惑をお掛けしておりまする。。

・基本オンラインMTG

# 1on1の目的
基本的には以下３つの目的があると思っています。
①部下の成長を促す
②コミュニケーションの活発化
③退職防止の一環

# 1on1の性質

1on1は、上司はあくまで答えを教える場ではなく、答えを導き部下自身で答えを捻り出す場だと言う認識です。

そのため、課題など話したい内容や相談したい内容を予め部下側で用意しておく必要があります。

例) 事前に準備しておくべきものリスト
・話したい内容(課題や相談事項など)をまとめる
・アジェンダ
・MTGの日時の相談(2-3つくらい用意して上司に相談

# もっと効果的に
私の場合、特に変な時間帯に実施してもらっているのでもっと意味のあるものにしたいと思ってます。
そうじゃないと上司に申し訳ナス🍆🍆🍆。

効果的に行うためのポイントを自分なりに考えてみました。
・事前に課題について可能な限り深掘りする
・限られた時間で何を話すか時間配分を考える
・課題だけでなく、前回の課題に対するフィードバックや今回の課題に対する行動計画をメモする

## 深掘り
限られた時間でのMTGなので、事前に課題の深掘りを自分で行なっておくことが重要かと
(じゃあお前は出来てんのかい？ってなるとあんま出来てない気がするので改善しないと。。)
ナゼナゼ分析とかね

## 時間配分について。
ついつい時間オーバーしがちですが、はっきり言ってリーダーポジにいる人は大体皆んな時間ないです。
その時間をもらっているので、時間オーバーせずに濃ゆいMTGにしたい。

そうしたい場合、事前に話す項目の時間配分について検討しておく。
アジェンダに時間配分について書いても良いと思う。

## フィードバックと行動計画について。
一番話したいのは課題だと思いますが、それ以上に大事なのが前回の課題のフィードバックと、今回の課題対する行動計画だと思います。

どう改善できたか？改善するためにどう行動すべきか？という点ですね。

# まとめ：1on1の部下のやることリスト
まとめると部下側は以下を実施しておく必要があります。結構多いw

**・事前準備**
　課題を見つけ、可能な限り深掘りし、まとめる
　前回の課題の改善行動をしてどうだったかについてまとめる
　MTGの調整
　時間配分の検討
　アジェンダの展開

**・MTG中**
　主役は部下なので、進行役は部下
　書記も部下(画面共有しながら、フィードバックをメモれば良いと思うよ)

**・MTG後**
　課題に対する改善活動案をまとめ、上司に共有
 
↑あとはこれを繰り返す

# 最後に
1on1の性質上、やらされている状態だとまずうまくいかない気がする。
そのため、毎回1on1の資料展開されてないんだけど！？って指摘されてるのは明らかに不味いよね。

とどのつまり、1on1は部下のほうから主体的に動かないとあんまり意味が無いと思うので自ら動きましょー、というお話でした。

# 2024/06/25追記: MTGしなくても意味はある
上司と自分の予定が合わず、流れることもあるでしょうよ。
でも、それでも意味はあると思っています。

これまで書いたように部下側の事前準備が大半です。
事前準備がちゃんと終わっていれば課題が(ある程度)明確になっているだろうし、深掘りもできているはずです。

そのため、**MTG自体実施できていなかったとしても、その時点で意味はある**と思っています。


以上
失敗するアジャイル開発

# はじめに
個人的に失敗するアジャイル開発あるあるだと思っていることを記載していきます。

# 原則
まず、アジャイル開発の原則の一つとして、以下があります。
　<font color="Red">計画に従うことよりも変化への対応を</font>
　引用: https://agilemanifesto.org/iso/ja/manifesto.html

開発中により良い品質のための仕様変更は歓迎すべきで、スコープや期日を都度調整する、という意味だと捉えています。

# 失敗する原因
上記原則があるにも関わらず、なんちゃってアジャイル開発の典型的なパターンって以下じゃないだろうかと思う。

・仕様変更は開発途中でもガンガン入れるね♪
・あっ、でも元々のスコープは変わらないよ♪♪
・あっ、もちろん期日なんて変わらないから♪♪♪
・あっ、もちろん要員も今のままで宜しくね♪♪♪♪

ゲロ吐きそう。。:joy:

肝入りの案件だから、とか、期日を変えるためには上を説得しなきゃいけなくて難しんだよ〜、とかそういうのも分かりますよ？

でも、これって失敗するの当たり前ですよね？

# 紐解いていく
まず、これは正しい真のアジャイル開発ではないです。
仕様変更は歓迎すべきであるならば、<font color="Red">当然スコープや期日を都度調整すべき</font>です。

調整しないとアジャイル開発の原則に反し、
且つそれってただのブラックな案件ですよね。。

# 経験談
私の経験で、以下のような案件に遭遇したことがありました（だいぶぼやかして書いてます）

①１ミリも見積もっていないのに期日は決まっていて、且つ厳守の案件
　→もはやここからおかしくて、リーダーが勝手に上が求めている期日に当てはめただけっぽい。
　→**つまり、何の根拠もないスケジューリング**🔥🔥🔥

②案件が始まる前にリーダーに理論立てて"期日に間に合わせるのは難しい"ことを報告し、以下を提案
　→スコープを狭める、要員の追加、期日を延ばす、仕様変更を極力無くすといった調整をして欲しい
　→結果的に仕様変更が少しだけ減るだけでした。。

③当然のように開発中に入る仕様変更、、

④しかも仕様通りに作って触ってもらったら、
　"デザインが間違ってました、直しておいてねｰ(⁎˃ ꇴ ˂⁎)"とこれまた当然のように言ってくる

⑤リーダー自身がメンバーのタスクを巻き取るから！というものの、一番簡単な１画面をバグ付きで上がってくる始末（バグ修正は私が行い、なんなら私がやったら30分で出来る簡単な画面作成）

案件始まる前からやばそうだなーと思っていたので、案件始まる前から私自身のタスクを前倒しで進めるようと思い、バッファを捻り出しました。
このバッファを遅れている要員のタスク巻き取りに当てて、結果的に無事期日までに間に合うことが出来ました。

# 対策
・開発メンバだけでなく、このヤバい状況を関係者全員に共有する
・なんならリーダーだけじゃなく、もっと上の層まで巻き込んで共有する
　→巻き込むタイミングは早ければ早いほど良い（例えばPJ開始前とかに分かるのであれば即リスクとして挙げてみる、とかね）、
 　逆に遅ければ遅い程リカバリができなくなる可能性があるので良くない:innocent:



以上！
IT業界で一生メシを食っていく方法

# はじめに
一部の天才とかではなく、普通のエンジニアがIT業界で一生メシを食っていく方法は何か？
言ってしまえば、継続して学ぶ、目標を持って行動しましょう、というお話になります。

※具体的な行動についてはあんまり記載しません。
　<font color="Red">目標を持つ意味</font>、<font color="Red">継続して学ぶことの重要性</font>の２点について記載していきます。

 # そもそもなんでこんな記事を書くのよ？
 癖のある人間の多い業界で、なんなら土日に喜んでモノづくりをする人がいたりする業界です。

そんな人たちに立ち向かわなければいけない、または比較されちゃうこともあリマス。
まあ、他の業界も往々にしてこうなのかもしれませんが。

で、何にも目標を持たず、常日頃学びの時間を作らない人間が一生IT業界でメシを食えるのか？
Noとは言いませんが、、上を目指しづらいし、一生メシを食う確率は低くなるんじゃ無いかと思う。

一生メシを食う、っていうと大それたタイトルつけましたが、
一番言いたいことはどうせ仕事するなら1%でも楽しくやりたいし、前向きに仕事したい、なんなら周りに認められて仕事したいよね、っていうことを言いたい。
じゃあどうすれば良いのか？ということを少しだけ語っていきます。

# 目標を持つ意味
目標を持つことで、エンジニアとしての目線が決まっていくと思っています。
目標を持つことで、逆算して成長のための日々の行動指針が決まっていきます。

逆に目標を持たないと、成長のためのカンフル剤が無い状態になるのでは？と。
そのため、目標を持つことは重要ですよ、というお話を先に記載します。

# 継続的な学び
完璧なスキルを持っている人なんていないので、みんななんらかの面で未熟なスキルの状態だと思います(稀に完璧超人もいますが)。

未熟なままでは生き残れないし、常に知識をアップデートする必要がある。
とりわけ、スマートフォン、Web系は非常に早いスピードで進化しており、知識をアップデートしないとあっという間においてかれます。

そのため、継続して"今"の最新の知識・技術を自分の血と肉にしなければいけない。
そうしないと周りに置いてかれるし、もっと具体的に言えば現場で周りの人間と対等以上に話せなくなります。

で、こういうことが出来ないと何が起こるかというと、**仕事が楽しくない**:frowning2::frowning2:ということに繋がります。
非常に良くない。

# 行動について
それでは何をすべきかというと、学ぶための行動を起こす必要gああります。
最初は効率悪くても良いので、　
<font color="Red">『すぐ行動に起す（学ぶ）　→　実践(現場やアウトプット)　→　改善』</font>
の繰り返しをすべき。
いつでも”今”が一番若いので、思い立ったら吉日、すぐに行動すべき、ということですね。

やる意味あるの？意味なく無い？と思うかもしれませんが、兎に角行動してから判断してましょう。
時間かけて考えてる暇があれば行動すれば良いと思う派閥です。

:::note info
余計な行動して痛い目にあったこともたくさんあります。
私自身、学んだ時や実践しているときは「意味ないんじゃね？」と思うこともたくさんありました。
しかし、今後ろを振り返ってみると何らかの経験になっているし割と意味の無いことはない気がしています。
:::


# 最後に
飽きっぽい性格の私が19年エンジニアやっていけてるのも、新しい技術が凄いスピードで進化していて、オモロいと思えるから。

正直IT業界いつか飽きるだろうなーと思い、飽きないために気軽に参加できるIT系のイベントは参加していた時期がありましたが、今思うと参加していて良かったと思っています。

なので、IT系のイベントはいまだに何かしら参加しています。
IT系のイベントで知見を得られるだけでなく、すんげーエンジニアがたくさん登壇してたりするので、良い刺激になりますし。

あと最後に、この業界は一生メシを食っていくに値するオモロい業界ですよ、ということを言いたい。

客から毎日のように怒鳴られたり、いっぱい~~数値は正直書けない:joy:ー~~残業したり、使い捨てにされることもありました（私の経験談）。
酷い目にいっぱい合いましたが、コーディング中に脳汁全開になる瞬間もあリ、やっぱり続けたい業種だと思います。
必ずしも相手の要求を100%満たす必要は無い話

# はじめに
もちろん内容や状況によっても変わるとは思いますが、、
要求されているアウトプット（成果物）が相手から求められている100%満たしている必要は無い話をします。

# 早速結論
スピード重視で80%の出来で報告するのもアリアリ:ant::ant:

# どういうことだってばよ
振られたタスクの70-80%の状況まで持っていったとして、
残りの20%を埋めるのにだいぶ時間を持っていかれることが多いです。
（極端に言えば体感的に　<font color="Red">70-80%に掛かった時間 = 残りの20%に掛かる時間</font>　くらいかも？）

そのため、ある程度達成できた段階で相手に成果物を渡して見てもらうのも一つの手だと考えています。

# メリット
**・スケジュールの範囲内でより意味のある成果物が出来るようになる。**
　→相手が求めている方向性や細かい仕様などについて、早めにフィードバックをもらうことが出来る。

　※最悪のケースで考えると、報告する側と報告を受ける側とで認識が大きくずれていて、蓋を開けたら全く要求していたものとは異なる、、ということを避けることが出来る。

**・相手の真の要求に気づきやすい**
　報告される側が80%の成果物を見る/触ることによって、報告される側も気づいていなかった要求や仕様の不備に気づくことが出来る。
  　結果的に、元々の要求が達成しようとしている目的を達成できない可能性があることにも気づくかもしれないし、この辺りに早めに気づく可能性を生む。

# デメリット
**・相手との調整ごとが増える。**
　場合によっては仕様追加、仕様変更が発生する。
 　でも往々にしてスケジュールは簡単に変わらないんだよなー
  （このスケジュールの期日にフォーカスを当てて別記事で作成しようと思っています）

# 最後に
残り20%を埋めて100%に持っていくのに時間かけてもしょうがない
なんなら、本質的には完成度は自分では決めることはできない。
報告相手(アウトプットの展開相手)が決めることなので、途中のものでも良いので生活物を早めに展開するのもアリアリ:ant::ant:

100%まで時間ギリギリまでやって認識間違っていたら目も当てられん。
そもそも、納期ギリギリに出すもんじゃないけどね。

あらかじめ期日内に何をやるのか認識を合わせるべきだが、
可能であれば相手のチェック → 指摘事項などの修正も含め、最終的に相手からOKをもらうことも考慮すべき。
スマフォ向けのアプリのテスト観点

# はじめに
iOS Android のスマフォ向けのテストについての記事となります。
テストの種別としてはITをターゲットとします。

# 観点 
**・固有の操作**
　機能、スワイプとか固有の操作

**・実施端末**
　シミュレータ or 実機のどちらでやるべきか？（実機でテストできるのであれば実機でやったほうが良い気がするが）
　→良くあるのが、リリースビルドとデバッグビルドで設定が異なるのであれば、両方とも確認できる環境にあるか？
　※これは、サーバの向き先によって動きが変わる場合も考え方は同じ

**・依存観点**
　端末依存、OS依存、OSVersion依存、

**・エラー系**
　エラー系のイリーガルな試験項目は網羅されているか？
　例) 圏外の場合、ルート取られてる端末、エラー系の影響のあるユースケースなど

**・回転**
　画面の回転をサポートしているのであれば、UI修正時にチェック

**・タブレット対応**
　スマフォ対応だけでなく、タブレットの両方に対応している場合であれば両方で確認

**・ネットワーク種別**
　例）4G 5G 弱電波、Wifiなど

**・復帰確認**
　バックグラウンド、スリープ復帰での動作確認

**・更新確認**
　古いバージョンから新バージョンに更新した場合の動作確認
　→特にアプリ内DBやアプリ内に永続的な情報の保存している場合、暗号化されている場合、されていな場合も含めてチェックが必要
 
**・多言語**
　サポートしている言語はすべて問題ないか？
　→日本語だけでなく多言語対応している場合は、文言やアイコン含めチェックが必要

**・解像度依存**
　→サポートしている最小、最大の解像度をターゲットとして考える。
　→iPhoneの場合は、ノッチあり、ノッチなしのiPhone8系、ノッチなしのPlus系で問題ないか？　の観点が必要

**・他アプリ連携**
　他アプリと連携する機能があれば、この辺りもチェックが必要

**・ライブラリ更新**
　新規追加している場合は、著作権表示されている画面は更新されているか？　の観点が必要

# 最後に
アプリの仕様に依存する部分が多いので、アプリの仕様をまず把握して
変更した箇所のテストをする上で影響確認の観点も非常に重要となリマス。

こうしてみると考えなきゃいけない部分が多いですね。。
git checkoutの注意点と安全なブランチ切り替え方法

現在オンラインスクールにてプログラムの勉強をしているMiyaki（[@Miyaki](https://x.com/Miyaki2323)）と申します。
初学者ゆえに、記事の内容に誤りや分かりにくい点があるかもしれませんがお許しください🙇‍♂️
今回は私がチーム開発で直面した「git checkout」についてお話しし、より安全なブランチ切り替え方法を紹介します。

# 個人開発での習慣

個人開発の際、私は頻繁に「git checkout」コマンドを使ってブランチを切り替えていました。例えば、新しい機能を開発するために作業ブランチを作成し、その後「develop」ブランチに戻るときに「git checkout develop」と入力するだけで簡単に切り替えられます。

# チーム開発でのトラブルと原因
ところが、チーム開発で同じように「git checkout」を使用して「develop」ブランチに移動したところ、思わぬトラブルが発生しました。私が作業していた内容がそのまま「develop」ブランチに反映されてしまったのです。このミスによって、共通のブランチに影響を与えてしまいました。

この問題の原因は、「git checkout」コマンドの使い方にありました。個人開発の習慣が染みついていたため、チーム開発でも同じように使用してしまいました。しかし、チーム開発では、他のメンバーとの調整が必要であり、「develop」ブランチに変更を直接反映させることは避けるべきです。

# 解決策

#### 1. git switch コマンドを使用する
「git checkout」の代わりに「git switch」コマンドを使用することをお勧めします。
「git switch」はブランチの切り替えのみを行うため、誤操作を防ぐことができます。

```
$ git switch develop
```

#### 2. 作業内容を一時的に保存する (git stash)
ブランチを切り替える前に、作業中の変更を一時的に保存するために「git stash」コマンドを使用します。これにより、作業内容を一時的に退避させ、安全にブランチを切り替えることができます。


```
$ git stash push -m "メッセージ"
```


#### 3. 保存した作業内容を適用する (git stash apply)
一時保存した作業内容を元のブランチに適用します。

```
$ git stash apply stash@{0}
```
stash@{0}の部分は、git stash listコマンドで確認できるスタッシュのリストから保存したスタッシュを選択する必要があるため、状況によって異なる場合があります。

# まとめ
チーム開発では、個人開発とは異なる注意点が存在します。「git switch」や「git stash」コマンドを適切に使用することで、作業内容を安全に管理し、スムーズな開発を進めることができます。以下は、今回紹介した一連のコマンドの流れです。

```
$ git stash push -m "メッセージ"

$ git switch develop

#developブランチで必要な作業を行う

$ git switch 作業ブランチ

$ git stash apply stash@{0}

```

このようにして、誤操作を防ぎつつ、効率的にブランチを切り替えることができます。皆さんも、同じようなミスを避けるために、ぜひ参考にしてみてください。
課題（018）と課題（022）

お疲れ様です。

先日提出した課題（018）は一部合格基準から外れていたため、再提出となりましたが、指摘された箇所を訂正するだけでしたので、そのあと合格をいただきました:relaxed:
指摘があった個所で、個人的に学びがあったのでメモを残します。

![訂正.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3810013/e4f9190c-fba5-4058-d306-72a899680b0f.png)
![訂正図.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3810013/5c593f46-ba46-88bb-1ac1-5569954d37c4.png)

課題（018）の一番始めの問題で、見本と比べると、近いけどなんか違うなーと思っていました。
訂正前は display:flex; を使って横並びにし、中央ぞろえ…とコードを書き足していましたが、どうやら inline-block を使うとのことでした:point_up:

そして inline-block に書き換えたのですが、今度は要素の中央ぞろえができず、沼にはまっておりましたが、 inline-block について調べてみたところ、
<br>
**inline、inline-block要素を中央ぞろえにする時は、「親要素」に text-align や vertical-align を指定しなければならない。子要素に指定しても反映されない。**
<br>
ということでした！
その情報を得て、コードを書き直したところ、本当にちゃんと中央ぞろえになりました:sob:

marginの相殺しかり、コードや要素によって、細かくルールがある場合があるんだなと痛感したので、今後にコードを書いていく中で、思ったようにならない時は、その要素の決まり事についてよく調べてみようと思います:computer:

そして現在は新しい課題（022）を始めているところです。
内容としては、メディアクエリを実装するものです。
数か月前にメディアクエリの復習をしましたが、まだ苦手意識のあるところですので、今課題で理解を深められたらと思います。
OpenWrtでgretap on WireGuardして途中でうまいこと動かなくなったときの対処法

# 現象
1. WireGuard同士→つながる
1. gretap→作れる
1. ブリッジする→WireGuardもgreも同時に死ぬ
となったときの備忘録です。

このとき、ログを見るとuci側でパースに失敗しているようなエラーが出ています。
(ログを保存するのを忘れました)

# 対策
1. `gre`、`kmod-gre`、`kmod-gre6`、`luci-proto-gre`を全部アンインストールする
このとき![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3314743/ead64790-5ec6-3f94-9f64-99d7514b4f8c.png)にチェックを入れておくと良い気がする。
1. 削除したパッケージと同じものを再インストールする
このとき![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3314743/1b012162-cf53-d84c-0f4b-e07510ea65fe.png)に必ずチェックを入れて実行する。
これをしないと解決しませんでした。

# 結果
普通にgretapを立てられるようになった。2ヶ月くらい詰まってました。
ハリーポッターに出てくる組み分け帽子を作成する

ハリーポッターと言えば誰もが知っている有名な映画だと思います。

ハリーポッターに出てくる組み分け帽子に組み分けられたいと思った事はございませんか？

今回はPowerAutomateとTeamsを活用し組み分け帽子を作成致します。

## 組み分け帽子とは？

組み分け帽子は『ハリー・ポッター』シリーズに登場する魔法の帽子となります。

ホグワーツに入学した新入生を4つの寮に組み分ける役割を持ちます。

以下4つの寮となります。

* グリフィンドール
* ハッフルパフ
* レイブンクロー
* スリザリン

## 1.「特定のキーワードを検知する」

![hp001.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3668800/a8a64ed8-20dd-b612-4661-77ee7e094c56.png)

それではPowerAutomateを使用し組み分け帽子を作成していきます。

今回利用するトリガーは「キーワードが言及された場合」となります。

上記トリガーではTeamsにて指定した「チャンネル」や「グループ」で特定のキーワードが発信された場合に発動する仕様となります。

ただし「日本語」や「スペース」といった単語は使用できません。

そこで今回は「HarryPotter」を送信した際に発動させる条件とします。

大文字、小文字は判定しませんので「HarryPotter」でも「harrypotter」でも大丈夫です。

## 2.「変数を定義する」

![hp002.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3668800/c4532c13-d2c8-e290-9d22-e21c27b44b15.png)

次にプログラムで使用する変数を定義します。

今回は組み分け処理に使用する乱数を格納する為の変数と、寮名を格納する為の変数、2つを作成します。


### 乱数を格納する変数

![hp003.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3668800/f3e132a7-1b93-7f88-1216-e56d8d824d76.png)


乱数を格納する変数は「rand」と名前を付ける事にしました。

```
rand
```

また、使用する型は「整数」を指定します。

今回は4つの寮に組み分けたいので初期値には1～4のランダムな整数を格納します。

下記コードを指定する事でランダムな整数を格納する事が出来ます。
```
rand(1,4)
```

### 乱数を格納する変数

次に寮名を格納する為の変数を作成します。

寮名を格納する変数は「dormitory」と名前を付ける事にしました。

```
dormitory
```

また、使用する型は「文字列」を指定します。

初期値は不要の為、空白で作成致します。


## 3.「条件分岐」

![hp004.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3668800/e6cff853-9b4e-e632-aaf3-02bf06603203.png)

次に先程生成したランダムな乱数に基づいて条件分岐を行います。

今回は以下の条件で割り振ることにしました。

1\. グリフィンドール
2\. ハッフルパフ
3\. レイブンクロー
4\. スリザリン

### 4.「条件分岐内で寮名を変数に格納する」

![hp005.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3668800/23a03efd-de7d-65fe-8f0d-842acb915ac1.png)

条件分岐が終わりましたら寮名を変数に格納します。

「変数の設定」機能を利用し先程作成した「dormitory」変数に寮名を格納します。

![hp006.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3668800/5ba27a07-fe14-50ba-7b19-fcd799c37f84.png)

また1～4に該当しない場合はエラーして終了を指定します。

### 5.「Teamsに返信する」

![hp007.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3668800/5d0140f7-441d-1bfc-3eb5-039fb7d41521.png)

最後に割り当てた寮名をTeamsに返信する機能を作成します。

投稿者は「フローボット」か「個人アカウント」が選択できます。

今回は特にこだわりが無い為、「フローボット」を選択しました。

「Message ID」にはトリガーとなったコメントのIDを指定します。


また「Message」には悩んでる風な前置きを付け下記の様に指定しました。

```
ああ、そうだな…ん～、よろしい、決まった。@{variables('dormitory')}！
```

以上でフロー作成は完成となります。

### 6.「動作確認」

それでは実際に動作するか確認してみます。

![hp008.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3668800/7a209b7d-f4d5-2dc5-f4ed-9c8315d80d41.png)

指定したチャンネルに「HarryPotter」と投稿してみます。

![hp009.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3668800/c5548504-9cf2-2e99-3f7b-785ec306a9b1.png)


数秒すると組み分け帽子フローが作動し寮を組み分けてくれます。

私は「レイブンクロー」となりました!

以上、誰得記事でした!!
Amazon ElastiCache for Redis Serverlessについてまとめてみた

## はじめに
こんにちは、今回の記事では、私が業務でAmazon ElastiCache for Redis Serverlessを
導入する際に調査した内容をまとめてみました。non-serverlessと比較してのメリットやコストの観点からまとめてますので、是非最後まで呼んでくださると嬉しいです。

## Redis(Remote Dictionaly Server)とは
よくキャッシュやセッション管理で利用されるオープンソースのNoSQLデータベースで以下のような特徴を持ちます。
- Key-Value形式でのデータ
- インメモリに保存するので高速に読み書きができる
- 豊富なデータ型をサポートしている(String/List/Set/Hash/...etc)
- データの永続化が可能

## Amazon ElastiCache for Redis
![Screenshot 2024-06-20 at 21.18.32.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/956457/baa47657-90f4-4454-0570-74e5f46dc482.png)

### 用語
- ノード(Node)
    キャッシュサーバー/ElastiCacheの最小単位
    選択したノードタイプによって性能(メモリやCPU)が異なる
- シャード(Shard)
    ノードをまとめるグループ
    1つのシャードにプライマリノード(読み書き可能)1個とリードレプリカノード(読み込み専用)0~5個を持つ
- クラスタ(Cluster)
    シャードをまとめるグループ
    クラスタ毎にキャッシュエンジンを選択可能
    シャード数は1~15で増減

### データの永続化(バックアップ)
- スナップショット
-> 定期的にデータベースの内容をスナップショットでとり、s3へ保存する
- AOF (Append-Only File)
-> 全ての書き込み操作をログに記録し、そこからデータを復元することができる

上記2つの方法がデータのバックアップ方法としてあるが、AWS公式としては、Multi AZ構成にして可用性を担保することを推奨している。

### システム構成
![Screenshot 2024-06-20 at 21.41.22.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/956457/b903a446-ddd3-23fc-4823-71810a8f62ba.png)
全体のシステム構成としては上記のような形(簡略化のためMulti AZは考慮していません)
運用にあたって、ノードサイズのスケールアップやシャードの増減は、CPUやメモリの使用率を監視してスケーリングする必要がある

## Amazon ElastiCache for Redis Serverless
2023年11月にGAされたサービス
### システム構成
以下のように、non-serverlessと比較して、プロキシという概念がアプリケーションとRedis間に存在している。
![Screenshot 2024-06-20 at 21.41.05.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/956457/07627ddd-be33-63d9-b188-33676f186b77.png)
### 特徴
- プロキシは複数のプロキシノードで構成されており、これらがリクエストを処理する
- プロキシノードはリクエストを適切なキャッシュノードにルーティングする
- キャッシュノードの数は動的に調整され、その都度プロキシがルーティングを再構築する

### サーバーレスのメリット
- キャッシュ容量の計画・管理をする必要がなくなる
-> メモリ・コンピューティング・ネットワーク帯域等の使用率をモニタリングし、垂直・水平方向に自動でスケーリングする
- 高可用性
-> 複数のAZ間でデータを自動的にレプリケートする。これらにより、SLAが99.99%になった(従来は99.9%)
- ソフトウェアの自動アップグレード
-> キャッシュを最新のマイナーおよびパッチバージョンであれば自動でアップグレードする。メジャーバージョンはElastiCacheから通知が送信される

### コスト(東京リージョンの場合)
サーバーレスのコストは大きく以下の2つがある
1. データ保存料: 1時間毎Redisに保存されているデータ量を計測し、課金される。1GB以下の保存料であれば1GBとして料金計算される
`$0.151 / GB-hour`
2. ECPU: 1キロバイトの送受信で1ECPUとして計算され、100万ECUP毎に以下の料金がかかる。1キロバイト以下のデータであれば1キロバイトとして計算される
`$0.0041 / million ECPUs`

## 感想
- サーバーレスになったことで運用・管理がかなり楽になった上、SLAとしても10倍になっているので、メリットとしては大きい
- コスト試算は少し計算が面倒ではあるが、従来の手法と比較してRIがないといった点から高額になる
- サーバーレスのモニタリングとしては、コストやデータの送受信量を計測する意味でも`ElastiCacheProcessingUnits`メトリクスが有効
discordを名言botでちょっと楽しくする

# はじめに

discordに名言を流すだけのbotを作りました．

名言がぱっと出てくると日常会話が楽しいと思うので，暇な時に名言でも見て覚えようかと．

名言をランダムに返す無料のAPIがあるんですね．それが今回一番の驚きでした．

# 実装

## 基本設定

見たい人もいるかもしれないので一応

``` py
import discord
import random
import json
import http.client

with open('Secret.txt', 'r') as file:
    lines = file.readlines()
    secret_token = lines[0].strip().split(':')[1]

intents = discord.Intents.all()
client = discord.Client(intents=intents)
```

## 名言を取得

今回使用させていただいたAPIは以下の2つ．

英語の名言のAPI: quotable

https://docs.quotable.io/

日本語の名言のAPI: 「名言教えるよ！」のサイト

https://meigen.doodlenote.net/

英語版もそうですが，まさか日本語版まで名言のAPIがあるとは……

どちらもシンプルな実装で大変使いやすいです．

「名言教えるよ！」のサイトはAPIもそうですが，webサイトの実装が面白かったです．

``` py
def get_quote(lang='jp'):

    if lang == 'jp':
        conn = http.client.HTTPSConnection("meigen.doodlenote.net")
        conn.request("GET", "/api/json.php")
        res = conn.getresponse()
        data = res.read()
        quote_data = json.loads(data.decode("utf-8"))[0]
        return f"{quote_data['meigen']} - {quote_data['auther']}"
    
    elif lang == 'en':
        conn = http.client.HTTPSConnection("api.quotable.io")
        conn.request("GET", "/random")
        res = conn.getresponse()
        data = res.read()
        quote_data = json.loads(data.decode("utf-8"))
        return f"{quote_data['content']} - {quote_data['author']}"
```

## 残りの実装

!quoteと送信すると明言が返ってきます．それだけ．

``` py
@client.event
async def on_message(message):
    if message.author == client.user:
        return

    if message.content.startswith('!quote'):
        if message.content.startswith('!quoteen'):
            quote = get_quote('en')
            print(quote)
            await message.channel.send(quote)
        else:
            quote = get_quote()
            print(quote)
            await message.channel.send(quote)

client.run(secret_token)
```

# 結果

```
!quote

与えてください。あなたの心が痛むほどに。 - マザー・テレサ

!quoteen

But I'll tell you what hermits realize. If you go off into a far, far forest and get very quiet, you'll come to understand that you're connected with everything. - Alan Watts
```

いい感じ．

毎回 !quote と打つのも面倒なので，定期的に自動で名言を流すようにしてもいいかもしれません．
AWS SUMMITに参加してきました！

今日から開催されているAWS SUMMITに参加してきました！
朝から幕張に大勢の方が終結していました...！

![PXL_20240620_002827770.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/273072/1546832c-ee3f-3d2a-b241-c322e2d46eec.jpeg)

今回はその感想記事になります。
私自身、AWSの超初心者ですがどれだけ楽しめるのか、初心者の人の助けになればと思います...！

# 結論！
早速ですが結論です！初心者レベルでも楽しめましたが、来年は勉強して参加しようと思いました！
初心者の人でも楽しめるよう、様々なセッションがあるので、AWSの知識が低くとも、楽しめる・学べることは多いのですが、もっとこのあたり知っていれば...と思う場面が多々ありました。

# 参加したセッション

## 10時～11時30分 基調講演　AWS と創る次の時代
やはり、近年話題が尽きない分野ということもあり、今回のSUMMITは生成AIがテーマでしたね。
個人的にこのセッションで一番響いた言葉は「AIが普及されればそれはAIとは呼ばれなくなる」ということです。
確かに、人物判定や予測変換などもAIの技術が使われていますがそれはAIとは呼ばれていません。
生成AIも今は「AI」とついていますが、そのうちこれもAIという単語が取れる未来が来るのでしょうか...？
いづれにせよ、将来何が起こるかを考えるより、今どうするかを考える。大事なことは10年後も変わらないものという言葉は非常に心に残っています。

## ~13時まで 企業ブース散策とお昼ご飯
様々企業の方が出展されていました。

![20240620_120506059.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/273072/7bb4a1fe-85f9-d0a8-a418-46cb7132370f.jpeg)

見知った企業から、ここにきて初めて知った企業まで、いづれもAWSを主軸に事業をされている企業の方で、AWSの強さを実感しました。

お昼ご飯は2種類から選べたのですが無料でもらえるお弁当とは思えない豪華なものでした！

![20240620_115149580.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/273072/2d8937aa-559b-4c91-0f04-12324373448a.jpeg)


## 13時~ AWS Villageを散策

こちらは企業の方の実演やAWSの公式ブースなどがある場所です。
海外のAWSスタッフの方がカタコトな日本語「ガチャ、AWSガチャあるよ」と言いながらガチャガチャ式のおみくじができるブースや生成AIを体験できるブース、AWSについてなんでも質問できるブースなど様々なブースがありました。

![20240620_133849870.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/273072/af89fc01-1288-0feb-8d0d-3779981610d5.jpeg)

AWSの公式が出展しているブースなだけあって、とても勉強になりました！初心者であったため、なかなかセッションの内容は理解が追いつきませんでしたが、ここはざっくばらんに話をしやすかったです。特に、

- 初心者はどういうところから初めていくのがいいのか？
- 今こういうことを試していますが詰まってます💦

などをAWSの方に直接質問することができたので勉強のモチベーションUPにつながりました。

また、サーバーレスコーヒーという、コーヒーの注文サイトをサーバーレスで作成し、実際にその場でコーヒーを注文できるブースがありました。電話番号認証から注文までとてもスムーズで、多くの方が注文されていました。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/273072/892b6ca5-e11b-39c8-6e23-852ecfc0001c.png)
![PXL_20240620_035600407.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/273072/244dd498-64fb-a016-72d9-ad64bd83906a.jpeg)


そのブースの隣で開催されていたセッション、AWS BuilderCardsの日本語訳をされた方のセッションを聞くことができました。
どう翻訳することが一番楽しく、学びにつながるのかを考えて翻訳されたと聞き、増々気になっています。
残念ながらSUMMITでは体験会はなかったのでJAWS関西の方、関西での体験会お待ちています...!！

# 終わりに
AWS SUMMITに参加しようか悩んでいた方、初心者だけど行っていいのかわからなかった方、初心者なりの学びもたくさんあるのでこういう機会は年に何度もある場ではないのでぜひ参加しましょ！
IBM i Services Directory : QSYS2.Software_Product_Info ビュー

これもライセンスプログラム関連の情報ですが、WRKLICINFコマンドに類似の情報を返します。

## 概要
■ビュー名：QSYS2.SOFTWARE_PRODUCT_INFOビュー
■カテゴリ：プロダクトサービス
■サポート：IBM i 7.3 SF99703 Level 22以降
■参照URL（IBM i 7.5）：https://www.ibm.com/docs/ja/i/7.5?topic=services-software-product-info-view

WRKLICINFコマンドと類似の導入済みライセンスプログラムの情報を返します。
***導入が*ERR エラーになっているライセンスプログラムだけを取得もできます。***

※・・とライセンスキー切れを取得できるIBM i サービスは3つ(も）あることになりますね。そういう要求がユーザー一般（ベンダー側も？）に多いのかもしれません。

## 使用例

```
SELECT *
  FROM QSYS2.SOFTWARE_PRODUCT_INFO
  WHERE LOAD_ERROR = 'NO';
```

上記ではロードエラー *NO なので正常に導入されたライセンスプログラムを返します。私の環境に無かったのですが、もし導入エラーのライセンスがあれば *YES指定すれば返してくれます。

結果例はこちら
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1011394/dcfc714f-c358-e7ad-4238-d272266c77d3.png)

これはまるでWRKLICINFコマンド画面そのものですね。


***ライセンスプログラムのバージョンを V5R3M0に限定してみました。***
```
 SELECT *
  FROM QSYS2.SOFTWARE_PRODUCT_INFO
  WHERE LOAD_ERROR = 'NO' and RELEASE_LEVEL='V5R3M0' ;
```
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1011394/39cef84a-5bf4-0dd0-a043-8698cf4922c4.png)

***ライセンスの導入ライブラリーを指定してみました。***

```
SELECT *
  FROM QSYS2.SOFTWARE_PRODUCT_INFO
  WHERE LOAD_ERROR = 'NO' and PRODUCT_LIBRARIES='QWEBQRYX' ;
```

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1011394/fd1f6e07-9c65-3d54-277d-7e05c29cb0c3.png)


状況に応じて色々活用できそうです♪

## 追記：WRKLICINFコマンドの画面サンプル

guriguriさんからリクエスト頂きましたので貼りたいと思います^^

以下のコマンドで取得した一覧形式のリストです。
```
WRKLICINF OUTPUT(*PRINT)
```

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1011394/18e35210-ae3b-b67a-b269-8534926b85bf.png)

カラム切れてしまっているのと、順番が多少異なりますが、取得している情報はほぼ同様かなと思います。

ちなみに5250画面だと機能的に１画面１ライセンスの明細でしか見れないのでちょっと比較しづらいとは思いますが、こちらもご参考に貼っておきます。

```
WRKLICINF
```

実行結果は、、、

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1011394/31399c92-2b05-2f44-7f84-502c60f688dd.png)

ここからオプション欄に 5 を入れると下記の明細が表示されます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1011394/aafe149e-511f-c531-5f59-0619d944363a.png)

次ページキーでスクロールします

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1011394/613f8430-f174-d6e7-9746-6ef1a5bdd961.png)
GASのデータをAjaxで動的に表示するサイトを作るあなたへ 検索エンジンに見てもらうために

今回はこのタイトル通り、
これからこういったサイトを作って検索エンジンに登録しようと思っているあなたや、Ajaxで取得して表示しているのに、検索エンジンのウェブマスターツールから内容が見られず困っているあなたへの情報です。

情報収集中の方にぜひお役に立てれば嬉しいです！
# 原因は何なのか
GASは応答形式にもよりますが、
```javascript
ContentService.createTextOutput(); 
```
を使用することが多いと思います。
それを``` Ajax(); ```などで取得し、エスケープしたりして、内容を表示するサイトを作るとします。
その場合、サーチコンソールを使うと
![0EoxmdQfJMviq3G1718883457_1718883577.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3819700/a7fa6ae1-9198-3f79-a947-4dafc19a231d.png)
と、
### robots.txtでブロックされとるやないかーい
結論としては、こういったGASのデータをAjaxを用いて直接表示するサイトで、検索エンジンに登録目的の製作は推奨されない可能性が考えられるということです。
ということは、robots.txtに影響を受けないようにするしかないですが、その方法をここに書くのは控えたいと思います。

:::note info
つまり、そういう仕様です。
:::


## なんで原因わかったのに解決法教えてくれないの？
それは、公式に確認できていないからです。robots.txtが設定されている意味を確認できないと、もろもろ大惨事になるかもしれないからです。あくまでも憶測ですが、多くのスクリプトを管理するドメインのため(script.google.com)、利用者(スクリプトを作成するユーザ)の万が一の設定ミスで重要情報をクロールされたりなどに対応できるようにされているとも考えられます。そこから考えると、その個スクリプト単位であれば、各サイト運営者の判断にもなりそうですが。。。


### こういった記事で適当なことを言うとよろしくないので結論をお読みください、


### という知識記事でした。
私個人としては、公式からこのrobots.txtの意義が開示されるまでは、

:::note alert
### この目的で作ることは控える方がいいかなと思います。
:::

:::note info
作るとしても、
普通に人が見る分(普通のブラウザ)には見えるので、
検索エンジンから見えるようにする必要のないサイトに使うのは良いと思います。(データベース検索画面など)
:::



これについて公式の情報や、ほかの情報がある場合はコメントよりお知らせいただければと思います。
2023年7月25日から今年5月までのHTMLやCSSに関するW3Cのニュースをまとめてみた

ここ1年ぐらいでW3Cから発表されたニュースを読みました。
サクッと概要をまとめましたのでよろしければ活用してください！

https://www.w3.org/news/

:::note warn
個人の解釈が多く含まれるのであくまでも参考に留めておいてもらえると幸いです…。
:::

## W3CのHTMLやCSSに関するニュース一覧
発表があった内要はタイトルにDraftと表記されたものがほとんどの印象です。
決定事項ではないものがほとんどなのでそれを前提にご一読くださいませ。

### 2023年7月25日　W3Cのビジョン

W3Cの使命、価値観、目的、原則の草案です。
W3Cが重要視していることや意思決定ができるように枠組みの提供などを盛り込んだものになるそうです。

W3Cの運営原則を抑えておけば一旦大丈夫そうな印象です。

https://www.w3.org/TR/w3c-vision/#op-principles

### 2023年9月5日 CSSビュートランジションモジュール レベル1の実装を募集

ページ内のビジュアル要素のトランジションやアニメーションを簡単に制御できるようにする仕組みに関する実装募集のニュース。

https://www.w3.org/TR/css-view-transitions-1/

ページのロード時やナビゲーションリンクのクリックなど視覚的変化を提供する仕組みがそのうちパワーアップするよーってことですかね…

### 2023年9月5日 最初の公開ワーキングドラフト:CSSトランジション レベル2

CSSの`transition`プロパティに関する変更点の草案の公開です。
レベル1からの変更点は下記にまとまっています。
また、以前のレベルでの問題についても続けて言及があるので興味のある方は確認してみてください！

https://www.w3.org/TR/2023/WD-css-transitions-2-20230905/#changes-fpwd

### 2023年12月5日 W3C Web of Things 1.1仕様はW3C勧告である

「Web of Things」の範囲を改善・拡大し、重要な新機能を追加のニュースです。

:::note
「Web of Things(WoT)」は、物理デバイスがインターネットに接続し、ウェブ技術(HTTP, WebSocket, RESTful API)を使用して相互作用できるようにする概念。IoTの拡張で、さまざまなデバイス間での平滑な互換性の実現を目的とした考え方だそうです！
:::

https://www.w3.org/ja/press-releases/2023/enhanced-web-of-things-connects-diverse-iot-ecosystems/

### 2024年1月25日 最初の公開ワーキングドラフト:CSSビューポートモジュール レベル1

ビューポートのサイズやズームなど表示に関わる部分の定義に見直しがかかるようです。

:::note
多くのデバイスに柔軟に対応する必要が出てきたこともあってビューポートの制御をより詳細にできるようにすることでユーザーにどんなデバイスでも一貫した表示を提供できるようにというところかと思います！
:::

https://www.w3.org/TR/2024/WD-css-viewport-1-20240125/

### 2024年3月18日 W3Cが新しい行動規範(Code)を採用

めちゃくちゃ長いので気になる人は読んでください！
私も全て読めてないので、読んで別の記事にしようと思います…。

https://www.w3.org/policies/code-of-conduct/20240318/

### 2024年5月8日 HTML Ruby マークアップ拡張のワーキングドラフトが公開されました
文字のふりがなに関するマークアップの拡張に関するニュースです。
日本語を含めた東南アジアのルビの表現が拡張されるようです！

https://www.w3.org/TR/html-ruby-extensions/

### 2024年5月16日 最初の公開ワーキングドラフト:CSSビュートランジションモジュール レベル2
- クロスドキュメントビュートランジション
    - ユーザーがページ間をナビゲートする際に、画面遷移がスムーズにする
- 選択的なビュートランジション
    - 特定のタイプのビュートランジションがアクティブであるかどうかに基づいてスタイルを選択できる
- ビュートランジション擬似要素間でスタイルを共有
    - 複数のビュートランジション擬似要素に共通のスタイルを効率的に適用できる

の機能更新に関するニュースのようです。
全てを完全に理解できてませんが、ページ間の遷移についてユーザー体験を改善するための機能のようです。

https://www.w3.org/TR/2024/WD-css-view-transitions-2-20240516/

### 2024年5月16日 更新された候補推奨事項:CSSマルチカラムレイアウトモジュール レベル1

CSSでのマルチカラムレイアウトについての変更についてです。
要素の内容を複数の列に流れ込み、列間のギャップやルールを設定できるものです。

:::note warn
`columns`、`column-width`といったプロパティがあることを知りませんでした…
:::

https://www.w3.org/TR/2024/CR-css-multicol-1-20240516/

### 2024年5月21日 更新されたW3C勧告:メディアクエリ レベル3
メディア依存スタイルシートの柔軟性が向上し、異なるメディアタイプに対応したスタイルシートをHTMLとCSSでサポートすることが可能になったとのことです。

https://www.w3.org/TR/2024/REC-mediaqueries-3-20240521/

## 【まとめ】W3Cが発表したHTMやCSSに関するニュース
初めてぐらいに真面目に読んでみましたが、「CSSビュートランジションモジュールレベル2」と言われても正直ピンときませんでした…。
なんのことを言っているのかは非常にわかりにくいと感じました…。

:::note
一次情報になるので理解するのに時間がかかります…。

全てを理解するのではなく、なんとなく知っているだけで利用したい時に「そおいえば…」となれば良いのではないかと思っています！
:::

「知っておく」を大切にこれからもサボらず情報をキャッチしたいと思います！