OmniAICreator/Qiita-1.07M huggingface dataset:
学生視点でのHoudini Copernicusについて

# はじめに
### 記事の概要
近年様々な3DCGのテクスチャを作成する方法があります。
その中で、この記事では学生が Copernicus を選ぶメリットや学習する必要性について模索していきます。
### 自己紹介
私は28卒の現在学校でCGを学んでいる学生です。私について↓
- 現在大学一年生(浪人なし)
- CGについて学べる学校に通っている
- 高校一年生のころにグラボの入ってるパソコンを買ってちょいちょい創作してる
-  CGは高校2年生からで1年生の頃はAdobeソフトを触っていた
- CG歴3年(ほとんど高校の放課後に少しずつ触っていたため実質ほぼ一年)
- Houdiniは高校２年次に挫折して今年に入って(受験終了後に)再度学習している
- ほかのCGソフトはMaya,Substance painter　をメインで触っていた


まだ初学者であるため、誤った情報などを記載してしまった際はコメント等で指摘していただけると幸いです。
# 学生が3DCGを学ぶ際の障壁
### 学校で授業を受けてみて気づいたこと
時分は学校で授業(Maya)を受ける中で多くの人が、テクスチャの作成の回で多くの人が躓いているように感じた。なぜなら、授業中の質問の回数がほかの回よりも圧倒的に多く感じたからである。
### その理由を自分なりに考察してみた
- 3Dの授業ではじめて2Dを扱ったから
- プロシージャルの概念がむずかしい

主にこの２つが大きな要因だと自分は考える。

具体的な問題点を探るべく


### 同級生に聞いてみた①
具体的な問題点を探る為、同級生にアンケートをとることにした。
Q:プロシージャルのどのような点が難しくかんじるか
- エラー多すぎてそれが仕様なのかエラーなのか分からない
ノードがそもそもよく分からない、細かい設定が何でなんなのかわからん(これはまともにまだ勉強してないってのがでかいけど)
- 英語表記だから分かりにくい
- なにをどう繋げばいいんですか…
- 頭を使ってやらないといけなさそうな部分が難そうだと感じます
- blenderにてプロシージャルの建物や地形をさわったことがあるがとても難しかった。Houdiniでの地形生成のコラムなどを見つけ、気になってブックマークするが過去の記憶もあり少し抵抗がある。
- 3角関数とかの数学が必要な時は難しく感じる
- デザインや見た目に関する直感的な操作ではないところ、ノード系についてまだ自分の知識が浅いとこ
- Blenderのジオメトリノードは英語説明が多く理解するのに時間がかかったので、モデリングなどより難しいイメージがある。

上記のアンケートの内容からプロシージャルの
- 直感的でない点
- 数学が必要な点
- ノードが複雑な点

が大きいと感じた

# 他ソフトでつまずいたらHoudiniを学習するメリット
### 他のソフトじゃなくてHoudiniでプロシージャルを学ぶべき意味
Houdiniは殆どの操作がプロシージャルにできる。
それに対してほかのソフトではプロシージャルにできることの幅が狭い。
おそらく学びのメインとなるチュートリアルでも、他のソフトだとプロシージャルでの理屈について詳しく解説してくれている物が少なく感じる。
それに対して、Houdiniは殆どのチュートリアルが理屈などの解説がメインだとに感じる。
> さらにApprenticeは無料

つまり、学習コストが他のソフトでプロシージャルについて学ぶのに対して圧倒的に低い。
上記の点からHoudiniはプロシージャルの感覚やノードの組み方を学ぶのに最も適しているソフトの一つだと感じた。

### 同級生に聞いてみた②
この記事を書く上で、実際Houdiniを触ったことがない人視点の偏見などについても聞いてみた。
- 数式めっちゃ使いそう、数三とか必須か？？？
- あんまり使える人いなさそう
- なんかきれい
- むずかしそう、あとすぐPC落ちそう(偏見)
- モデリング以外何でもできそう
- モデラーにはあんま必要なさそう
- エフェクト作成がすごそう

### Houdiniで何からやってみればいいか
Houdiniではエフェクトやシュミレーション、HDAの作成など色々なことができる。
その中で、自分が推したいのはCopernicusでのテクスチャ作成だ。
なぜCopernicusを自分が推したいのかは以下の理由がある

# Copernicus
###  応用力
普段Houdiniを使ってない人にもおすすめしたい一番の理由は応用力にあると思う。
エフェクトなどの専門学校や大学では後回しにされちゃいがちな知識がなくてもテクスチャ生成ならとっつきやすいという点がその大きさの一つだ。　さらに、普段のモデリングした作品作成したテクスチャをマッピングするなど幅広いCGユーザーへのウケも考えられる。

https://www.sidefx.com/ja/products/whats-new-in-h205/copernicus/

さらに、上記リンクにあるようにアニメーションなどを2Dに取り込んだりするなどHoudiniらしさを生かした応用などを目指せるのはモチベーションを上げるのにすごくぴったりだと思う！！
###  情報量
Copernicusはver20.5からβ版として配信されている。
自分が普段X(旧Twitter)を観覧しているときも、最新verの機能だからか頻繁にCopernicus関係の情報が流れてくる。それだけでなく、youtubeにもたくさんのチュートリアル動画が投稿されていてどれも面白い。

https://www.sidefx.com/ja/contentlibrary/

さらにコンテンツライブラリからhipファイルをダウンロードして実際にファイルをさわってみることで、検索やチュートリアルの観覧以外の方向からアプローチできるのもすごく便利な点だ。
# 最後に
最後まで読んでいただきありがとうございます。学生の身かつ初心者だからこそ 何か書けるけることがないかなと考えた結果、Houdiniを触ったことがない人への布教を見越して記事を作成してみました。
何か作例を使って書けないかも考えてみたのですが自らの実力不足故に断念してしまいました。
来年はより良い記事を書く為に、まずはMardiniに向けて研鑽していこうと考えています。
この記事が誰かにささってくれたら幸いです。
改めてありがとうございました。
Expo, React Nativeで作成しているアプリを、任意のタイミングでリロードしたい時

# はじめに

タイトル通りに、Expo, React Nativeで作成しているアプリを、任意のタイミングでリロードしたい場合に、使える方法を知ったので公開しておきます。

[公式Doc](https://docs.expo.dev/versions/latest/sdk/expo/#reloadappasyncreason:~:text=reloadAppAsync(reason))に記載されていましたが、見つけにくかったので、記事として残しました。


# 方法

```javascript
import { reloadAppAsync } from "expo";

// 好きな場所で
reloadAppAsync()
```

これだけです！

公式には、アプリのアップデートを踏まえたリロードを行いたい場合は、[expo-update](https://docs.expo.dev/versions/latest/sdk/updates/#updatesreloadasync:~:text=retrieving%20the%20logs.-,Updates.reloadAsync(),-Android)を使用すべきだと書かれていました。

# おわりに
公式Docの読み込みは大切ですね。

もっといい方法がある場合は教えてください！
React　useStateの配列 mapで取得

アプリ開発していて、実装に時間を要したuseStateのmapでの取得方法について共有させていただきます。

useStateの初期値を配列で渡したものの取得方法について様々な取得方法がありました。

```.jsx
  const [content, setContent] = useState(["記録１", "記録２", "記録３"]);
  const [time, setTime] = useState([1, 3, 5]);
```
上記のように初期値をそれぞれのuseStateで定義している場合。

```.jsx
{content.map((contents, index) => {
  return (
  <span>{contents}</span>
  <span>{time[index]} 時間</span>
  )
})}
```
上記のような記述でcontentのデータに対するtimeのデータを取得できます。
time.map((times) => {}) のような記述はしなくても良いということですね。

```.jsx
const [contens, setContens] = useState([
  { title: "記録１", time: 1 },
  { title: "記録２", time: 3 },
  { title: "記録３", time: 5 },
]);
```
上記のように配列オブジェクトで定義した場合は、下記のような記述で取得できます。
```.jsx
{contens.map((content) => {
  return (
    <span>{content.title}</span>
    <span> - {content.time} 時間</span>
  );
 })};
```

# JISOUのメンバー募集中！
プログラミングコーチングJISOUでは、新たなメンバーを募集しています。
日本一のアウトプットコミュニティでキャリアアップしませんか？
興味のある方は、ぜひホームページをのぞいてみてください！
▼▼▼

https://projisou.jp
アーキテクチャ（＝分類ごっこ）を意識しながら開発すると、楽！

# はじめに
初心者のうちは、「とりあえず動くものを作る」ことで頭がいっぱいになりがちだと思います。
自分も今は実務経験が1年ほどなのでまだまだ初心者ですが、
この1年で「右も左も分からない全くの初心者」からは抜け出せた気がしています。

この1年で学んだことは色々ありますが、
特に**アーキテクチャ**を意識しはじめてから、実務の中でもコツが掴めてきた気がします。

そこで今回は「**アーキテクチャを意識しながら開発すると楽だよ～**」ということについて、
「そもそもアーキテクチャって何なの？」というところから書いてみます。


# そもそもアーキテクチャとは？
アーキテクチャとは、
**システム全体の構造や設計、ある視座に基づいて体系的に分類する仕方**
のことです。
一言でアーキテクチャといっても、色々なアーキテクチャがあります。
視点によって捉え方も様々であるためです。

この説明をと聞くとなんだか難しそうに聞こえますが、
アーキテクチャとは要するに **「分類ごっこのルール」** です。
分かりづらいと思うので、簡単な例で示します。
突然ですが、以下の4つを考えてみてください。
>①リンゴ
②バナナ
③キリン
④タコ

これらを色々なアーキテクチャで分類してみましょう。

1.動物-植物アーキテクチャ
>①のリンゴと②のバナナは同じ「植物」に分類されます。
③のキリンと④のタコは同じ「動物」に分類されます。

2.色アーキテクチャ
>①のリンゴと④のタコは同じ「赤」に分類されます。
②のバナナと③のキリンは同じ「黄色」に分類されます。

3.食べられる-食べられないアーキテクチャ
>①のリンゴ、②のバナナ、④のタコは同じ「食べられるもの」に分類されます。
③のキリンは「食べられないもの」に分類されます。

このように、一見バラバラなモノ同士でも、
「動物か植物か」「色」「食べられるかどうか」
といった **分類のルール（＝アーキテクチャ）** によって、様々なまとまりが作られる。

# アーキテクチャを意識すると何が楽？
### ①全体像が把握できる
アーキテクチャに基づいて考えると漏れがないので（＝MECE）、全体像を把握しやすくなります。

全体像が把握できると、以下のようなメリットがあります。
>・自分が全体のどこの箇所に関する作業をしているのかが分かる
・作業の中で考慮すべき事項と考慮しなくてよい事項が明確になる
・どの箇所にどのような変更を入れるのが適切なのかの見当がつく

また何よりも、全体的な対応指針が立てやすくなるので、安心感があります。

### ②どの分野の知識が欠けているのかが分かる
システム全体やソフトウェア全体をアーキクチャに基づいて考えたとき、
「自分がメインで担当しているのはどこに分類されるのか？」
を把握できると、自ずと自分に欠けている知識領域が炙り出されます。
欠けている知識領域は座学で埋めてもいいですし、
参画プロジェクトを変えたり、転職したりして実務を積みながら埋めていくのもありだと思います。

また、実務上で知らない知識が出てきても、
それがアーキテクチャに基づいてどの分類に属するのかを把握できれば、
「これは自分の専門領域に関わるから深く勉強しておこう」
「これは専門外だから軽く概要だけ知っておこう」
など、臨機応変に効果的な対策を取ることができます。

# おわりに
自分は開発エンジニアなのでソフトウェアアーキテクチャの例になりますが、
・三層アーキテクチャ（基本のソフトウェアアーキテクチャ）
・レイヤードアーキテクチャ（三層アーキテクチャをさらに細かく分類したもの）
をあたり意識すると、とても設計・開発がやりやすくなりました。

例えば新しくクラスを作成するときも、
 「*このクラスの役割は○○アーキテクチャだと△△に分類されるから、責務はここまで*」
という風に、設計や実装の指針を立てやすいためです。


自分が今携わっているシステムでは、規約で明確なアーキテクチャが定まっていないため、アーキテクチャを意識しはじめるまでにとても時間がかかりました(笑)
コードレビューを受けても、
「なんでこの処理はこのクラスに書いちゃダメなんだろう？」
というモヤモヤが残り、その場は修正して乗り切れたとしても、次で上手くできる自信がなかったです。

この記事をきっかけに、アーキテクチャを意識することの楽さに早く気づいていただけたら幸いです。
「どんなときも。」の歌詞をUML図式化してみた！



皆さん、こんにちは！
本日は、槇原敬之さんの名曲 「どんなときも。」 の歌詞を UML（Unified Modeling Language） で図式化するという試みをご紹介します。
歌詞が伝える感情やメッセージを 視覚的に整理・分析 することで、
新たな視点や理解を得ることが目的です。
UMLを用いることで、言葉の背後にある ニュアンス が明確になり、これまで気づかなかった歌詞の側面が浮かび上がります。

歌詞のテーマとUML要素分析

「どんなときも。」は、 自己発見 や 個性の尊重 を主題とする楽曲です。
UMLで表現する際、以下の3つのポイントに注目しました：
	1.自己認識の探求
自分が何者であるかを問い、自身の感覚や目標に向き合う過程。
	2.他者との対話と確認
不安を抱えたとき、他者を通じて自分を確かめようとする行為。
	3.日々の模索と成長
迷いや葛藤を通じて成長し、答えに近づいていくプロセス。

UMLシーケンス図
これらのテーマを、UMLの シーケンス図 で表現しました！
![スクリーンショット 2024-12-16 16.59.20.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3956796/c0e1fdfd-6f77-a41e-ba08-72e1ab437923.png)



UML図の要素
	•	アクター（僕）
物語の中心となる存在で、全てのアクションの起点。
	•	背中への問いかけ
自分自身の内面的な疑問や不安を象徴。
	•	夢と過去
教室に置き去りにされた夢や、現実とのギャップ。
	•	現実認識（泥だらけのスニーカー）
理想を追い求める中で直面する現実の厳しさ。
	•	日々の模索
迷いながらも新しい答えを見つけるプロセス。

UMLシーケンス図の詳細解説（1番）
以下は、1番の歌詞をUMLシーケンス図に落とし込んだ解説です。
	1.主人公（僕）と自分自身の関係
	•	僕 → 背中：「自分の感じたことは正しいのか？」と自分に問いかける。
	2.不安が生じたときの他者との関係
	•僕 → 他者：「自分は正しいのか？」と確認を依頼し、他者を通じて自己を確かめる。
	3.夢と現実の関係
	•僕 → 夢：「旅立つための誓い」を立て、理想と向き合う。
	•夢 → 教室：「過去の理想」が取り残され、現実とのギャップが生まれる。
	4.現実との対峙
	•僕 → スニーカー：現実の厳しさを象徴する泥だらけのスニーカーに気づく。
	5.日々の模索と成長
	•僕 → 日々：迷いながらも答えを求め続ける。
	•日々 → 僕：試行錯誤の中で答えが見つかり、成長していく。

まとめ（1番）

UMLを使って歌詞を可視化することで、歌詞に込められた 自己探求 や 成長の流れ が直感的に理解できるようになります。
他者との関わり、不安の克服、現実と理想の狭間での葛藤——
日々の中で答えを見つけ、成長していく主人公の姿がUMLシーケンス図を通じて浮き彫りになります。

2番について
2番についても、1番同様にUMLシーケンス図を用いて関係を整理します。2番では、さらに深まる感情やテーマの重層性が際立ち、UMLによってその相互作用が明確になります。
![スクリーンショット 2024-12-16 17.00.04.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3956796/74f56575-99c6-5d64-c141-c6b17db9d156.png)


UMLシーケンス図の詳細解説（2番）
2番では、より深い感情やテーマが描かれています。
	1.僕と他者の関係
	•無意識に他者を傷つけてしまう可能性を示唆。
	2.僕と譲れない夢
	•譲れない夢を持ち、それが前進する力となる。
	3.過去・未来への視点
	•過去を振り返らず、未来に向けて歩み続ける。
	4.自己認識と内面的調整
	•鏡に映る自分を肯定し、内面的なバランスを保つ。
	5.自然と調和
	•焦りを夕陽が静め、落ち着きを取り戻す。
	6.愛の力
	•愛する存在を守る強さを得ることで、人間的に成長する。
 
まとめ

1番・2番の歌詞をUMLシーケンス図で表現することで、
「どんなときも。」 のテーマや感情の流れが立体的に浮かび上がりました。
皆さんも、お気に入りの歌詞を UMLで図式化 してみませんか？
新しい視点や発見がきっとあるはずです！
次回もお楽しみに！
他の楽曲でもUML図化にチャレンジしていきますので、次回の投稿もお楽しみに！

UML図化したApp Modelerはこちらから↓
https://www.hexabase.com/
Suno AI を使う上で知っておいた方が良いこと

# はじめに
今回は、Suno AIを使用して曲を作成する際のコツについてご紹介します。以前の記事でSuno AIを使った曲の作り方をご紹介しましたが、その後に1,000曲以上作成して、その中で得た知見をお伝えできればと思います。

もしまだ曲の作り方がわからない方は、ぜひこちらの記事をご覧ください。
https://qiita.com/inukai-masanori/items/c817d7803c615379587d


:::note warn
この記事は、V4を前提にお話ししています。一部の機能は無料プランではご利用いただけない場合がありますので、ご注意ください。
:::

# 日本語の歌詞は、ひらがなやローマ字で作成
日本語の歌詞を書くとき、通常は漢字を交えて書くことが多いですが、Suno AIはまだ日本語の処理に完全には対応していない部分があり、読み間違える可能性が高いです。せっかくの良い曲が歌詞の読み間違いで台無しにならないよう、最初から平仮名やローマ字を使用することをお勧めします。

:::note info
`明日は` → `あすは` → `あすわ` または `asuwa`
:::
*※これにより、AIによる読み間違いを減らし、より正確な歌詞を実現できます。*

少し本筋からは外れますが、当て字をすることもできます。

:::note info
`地球(ほし)`
:::

※これにより、`ほし`と歌われます。しかしながら、`()`はメロディをリピートするリフレインとしても利用されることがあるので、表記上の使用に留めて、プロンプトには平仮名だけを入力することをお勧めします。


# 文字数がメロディに与える影響を考える
音楽制作において、歌詞の文字数はメロディに大きな影響を与える要素の一つです。特に、曲調やスタイルを決定する際には、文字数を意識することで、より狙い通りの楽曲を作り出すことができます。

たとえば、ゆったりとしたバラードを作りたいのに、歌詞が多すぎると、どうしても早口になってしまうことがあります。これだと、せっかくのバラード感が失われてしまいますよね。

逆に、ラップのようにテンポの速い曲を作りたいのに、歌詞が少なすぎると、曲がすぐに終わってしまうことも。これでは、勢いを持続させるのが難しくなります。

Suno AIなどのツールを使うと、色々なスタイルで曲を試せますが、スタイルばかりに気を取られて、同じ歌詞で何度も作り直してしまうことがよくあります。（私も結構やってしまいます）

:::note warn
絶対に歌詞は編集したくないという方は、スタイルもしくは後述する時間の関係を意識して頑張るしかないです！
:::


10曲くらい試してもピンとこないときは、いったん歌詞の文字数を見直すのがスタイルの変更よりも近道になるかもしれません！


## 参考プロンプト

下記にテスト用のプロンプトを置いておきますので、ぜひ試してみてください。
おそらく同じスタイルでも大きく印象が変わると思います！

```:スタイル
J-POP,BPM90,Piano,A.Guitar,Male Vocal,Hopeful and nostalgic
```

```:歌詞長め
[intro instrumental]
[Lyrics that don't sing]

[Verse 1]
ページをめくる音が　過ぎ去る日々を歌う  
未来（あした）の景色探して　記憶の隙間漂う  
手帳に書いた約束　色褪せずそこにある  
君と過ごした時間が　今も胸を照らす

[Chorus 1]
カレンダーに刻む想い　君の笑顔映した日々  
何度も繰り返す　君への想い  
消せない記憶の中で（中で）
```

```:歌詞短め
[intro instrumental]
[Lyrics that don't sing]

[Verse 1]
カレンダーの白いページ  
君の名前で染めたくて  
過ぎ去る時　刻む想い  
胸にそっと抱いている

[Chorus 1]
君と過ごした　日々が歌う  
消せない記憶　彩る空  
願い続けた　未来の道  
君がそばにいるなら
```


# 作成する時間帯(日付)を考える
これは感覚ではあるのですが、同じ歌詞やスタイルを使っても、作る時間によって曲の雰囲気が大きく変わることがあります。

例えば、ある日は自分の好きな感じの曲が簡単にできるのに、別の日には全く納得のいくものが作れないこともあります。この差は思ったよりも大きいと感じています。

私だけでなく、数万円をかけてSUNO AIを利用している友人も同様の経験をしています。

このことから、時間や日付が何らかの形で乱数として利用されている可能性が高いと考えています。

そのため、もし短時間で気に入った曲ができた日はラッキーで、逆にしばらく曲作りを試みても好みの曲ができない場合は、次の日を待つか、少し時間を空けるのが良いかもしれません！


:::note warn
ボタン1つで曲ができてしまうので、意外とクレジットはすぐになくなります。
また、画像やテキスト系などの生成AIとは違い、内容の精査にある程度の時間が必要な曲という特性上、時間の消費も激しいです。

時には戦略的撤退も！
:::

# 終わりに
SUNO AIを使った音楽制作は、想像以上にクリエイティブな体験です。

日本語の歌詞の扱いや曲のスタイル、文字数のバランス、そして制作する時間帯まで、ちょっとした工夫が作品のクオリティに大きく影響します。これらのポイントを押さえることで、理想に近い曲がもっと簡単に作れるかもしれません。

音楽制作は試行錯誤の連続ですが、その過程が楽しいところでもあります。
今回のコツを試してみて、ぜひ自分だけの素敵な楽曲を作ってみてください！
.NETを使用したAPIの実装超基礎編

# Controllerベースと最小API
WebAPIを実装していくときには、ControllerベースのAPIと最小APIの2つから選択できます。
### 1. コントローラーAPI
MVCモデルに習って、Modelにロジックを、Viewに画面の情報を、ControllerにはModelとViewとの橋渡しを記述する。
※ 比較的軽量なAPIではControllerにロジックを記入することがある。
例
```
using Microsoft.AspNetCore.Mvc;

namespace APIWithControllers.Controllers;
[ApiController]
[Route("[controller]")]
public class WeatherForecastController : ControllerBase
{
    private static readonly string[] Summaries = new[]
    {
        "Freezing", "Bracing", "Chilly", "Cool", "Mild", "Warm", "Balmy", "Hot", "Sweltering", "Scorching"
    };

    private readonly ILogger<WeatherForecastController> _logger;

    public WeatherForecastController(ILogger<WeatherForecastController> logger)
    {
        _logger = logger;
    }

    [HttpGet(Name = "GetWeatherForecast")]
    public IEnumerable<WeatherForecast> Get()
    {
        return Enumerable.Range(1, 5).Select(index => new WeatherForecast
        {
            Date = DateOnly.FromDateTime(DateTime.Now.AddDays(index)),
            TemperatureC = Random.Shared.Next(-20, 55),
            Summary = Summaries[Random.Shared.Next(Summaries.Length)]
        })
        .ToArray();
    }
}
```
ポイント
・[Route("[controller]")]を使用することで、コントローラー名に記載しているエンドポイントをマッピングさせる
・

### 2. 最小API
規模の小さいAPI・単純な操作のAPIでは、MVCの概念を使わずに1つのクラスだけに完結させることができる。
例
```
namespace MinimalAPI;

public class Program
{
    public static void Main(string[] args)
    {
        var builder = WebApplication.CreateBuilder(args);

        var app = builder.Build();

        app.UseHttpsRedirection();

        var summaries = new[]
        {
            "Freezing", "Bracing", "Chilly", "Cool", "Mild", "Warm", "Balmy", "Hot", "Sweltering", "Scorching"
        };

        app.MapGet("/weatherforecast", (HttpContext httpContext) =>
        {
            var forecast = Enumerable.Range(1, 5).Select(index =>
                new WeatherForecast
                {
                    Date = DateOnly.FromDateTime(DateTime.Now.AddDays(index)),
                    TemperatureC = Random.Shared.Next(-20, 55),
                    Summary = summaries[Random.Shared.Next(summaries.Length)]
                })
                .ToArray();
            return forecast;
        });

        app.Run();
    }
}
```

参考資料
https://learn.microsoft.com/ja-jp/aspnet/core/fundamentals/apis?view=aspnetcore-9.0
API GatewayからLambdaを呼び出す

如何せん資格取得にこだわりすぎて、インプット中心になってしまったので、アウトプットもして行かねばと思い実行。
タイトルにある通りLambdaとAPI Gatewayの連携です。

まずはLambda関数の作成、デフォルトにあるhello worldを使用します。
```
export const handler = async (event, context) => {
    return 'hellow world';
};

```

さて次にAPI Gatewayを作成します。
API GatewayにはHTTP APIとREST APIのどちらを選択するか、という話ですが、<a href="https://dev.classmethod.jp/articles/amazon-api-gateway-http-or-rest/">こちらのページ</a>がわかりやすかったです。
今回はLambdaとの連携が目的なので、HTTP APIで良いでしょう。
画面に従って先に作成したLambdaと関連づけ,ルート設定画面でメソッドとリソースパス、ターゲットを指定、ステージはお試しなので$defaultで良いでしょう。
普段ならdev,test,prodみたいなステージで分けるんでしょうけど。
で、作成したAPI Gatewayをデプロイすれば、urlが発行されるので、それをクリックすれば無事Hello worldと出力される=動作するということが確認できます。
心理的安全性で職場革命！メンバーの創造性を引き出そう！

## 心理的安全性とは？
心理的安全性（Psychological Safety）とは、チームメンバーが意見や質問、不安、失敗について自由に話すことができる雰囲気や環境のことを指します。これは、Googleのプロジェクトアリストテレスの研究によって、効果的なチームの特性として注目されました。

心理的安全性が高いチームでは、メンバーがリスクを恐れずに発言し、互いのアイデアを尊重する文化が形成されます。結果として、創造性や効率性が向上し、組織全体の成功に寄与します。

---

## 心理的安全性がなぜ重要か
心理的安全性は、特に以下の場面で重要です：

1. **イノベーションの促進**
   新しいアイデアや視点を積極的に出せる環境は、創造的なプロセスを支援します。心理的安全性がない場合、メンバーは批判を恐れて新しい提案を控えることがあります。

2. **問題解決能力の向上**
   問題に対して率直に議論し、異なる意見を交わすことで、より良い解決策を見つけることが可能になります。

3. **メンタルヘルスの向上**
   心理的安全性が高い環境では、メンバーがストレスや不安を抱えにくく、健康的に働くことができます。

---

## 心理的安全性を高める具体的なアクション
心理的安全性を高めるために、リーダーやチームメンバーが実践できる具体的なアクションを以下に挙げます。

### 1. リーダーの行動
- **ミスを共有する**: リーダー自身がミスや失敗を率先して共有することで、他のメンバーも発言しやすい雰囲気を作る。
- **オープンな質問を投げかける**: 例えば「このアイデアについて他に意見はありますか？」といった形で、メンバーの発言を促す。
- **行動で示す**: 例えば、全員が平等に発言できるようファシリテーションを行い、全メンバーに発言の機会を与える。

### 2. フィードバックの文化
- **チーム全員が参加する振り返りを実施**: レトロスペクティブ（振り返り）を行い、改善点と成功事例を話し合う。
- **匿名で意見を集める仕組み**: 言いにくいことを匿名で提出できるツールを導入し、安心感を高める。
- **多面的なフィードバック**: 個人だけでなく、プロジェクトやチームの進捗に対する評価を行い、前向きな改善提案を促す。

### 3. 意思決定プロセスの透明化
- **全員の意見を聞いてから決定する**: 発言の多い人だけでなく、全員が意見を述べる時間を確保する。
- **理由を説明する**: 意思決定の背景や理由を共有することで、メンバーの納得感を高める。
- **合意形成を重視する**: 決定後も議論を振り返り、合意形成プロセスを透明化する。

### 4. チームメンバー間の信頼構築
- **1on1ミーティングの実施**: 定期的にメンバーと1対1で話し合い、業務以外の悩みも聞く。
- **感情を受け止めるリアクション**: メンバーの発言に対して否定せず、「そう感じるのですね」と共感を示す。
- **多様性を尊重する**: 異なる文化や価値観を持つメンバーに対しても柔軟に対応し、互いの背景を理解する。

### 5. メンバー主体の活動を促進
- **自主的な勉強会の開催**: メンバーが主導する形でスキル向上や知識共有の場を作る。
- **成功体験の共有**: 過去の成功事例をメンバーと共有し、自信をつけさせる。
- **ロールモデルの活用**: 他のチームや業界での成功事例を参考に、心理的安全性の向上につながる取り組みを実施する。

---

## 心理的安全性がもたらす効果
心理的安全性が高いチームでは、以下のような効果が得られます：

- **生産性の向上**: メンバーが自分の意見を自由に表現できることで、作業効率が向上します。
- **エンゲージメントの向上**: チームに対する信頼感や一体感が強まります。
- **離職率の低下**: 安心して働ける環境は、従業員の満足度を向上させ、離職を防ぎます。
- **多様性の受容**: 異なるバックグラウンドや考え方を持つメンバーが協力しやすくなる。

---

## まとめ
心理的安全性は、効果的なチーム作りの基盤となる要素です。リーダーやメンバー全員がその重要性を理解し、実践することで、チームのパフォーマンスは飛躍的に向上します。

日常のコミュニケーションやフィードバックから心理的安全性を意識して取り入れ、リーダーとメンバーが一丸となって安心感のある職場を作りましょう。

あなたのチームでは、心理的安全性をどのように高めていますか？コメントでぜひ教えてください！
GIHOZでデシジョンテーブルテスト

# はじめに
ソフトウェアテストの概論について学んだので,テスト技法を実践してみます.

Excelでやってみるというのも考えてみたんですが,ツールを使うほうが楽だろうということで
[GIHOZ](https://www.veriserve.co.jp/helloqualityworld/service/gihoz/)を用いて「デシジョンテーブルテスト」をやってみます.

GIHOZはデシジョンテーブルテスト以外にも,以下のようなテストに対応しています.
- ペアワイズテスト
- 状態遷移テスト
- 境界値分析
- クラシフィケーションツリー法
- CFD法

GIHOZはユーザー登録するだけで基本無料で使え,デシジョンテーブルやテストケースの表はCSVとしてダウンロードすることができます.

# デシジョンテーブルについて
デシジョンテーブルとは,
**想定されるすべての条件と、それに対して実行すべき動作を整理した表**のことです.

これを用いることにより,すべての組み合わせをもれなくテストする際に有効です.

組み合わせパターンを視覚的に整理できるので,条件の組み合わせ漏れを防げます.

ただし,すべての組み合わせを網羅するのが大変な場合もあるので,
効率的なやり方でも実践してみます.

# デシジョンテーブル使用例1
以下の映画館の料金設定に対して適用することを考えてみます.

#### 映画館の料金設定
- 基本料金は1800円
- 20時以降に上映開始される作品(レイトショー)は1200円
- 高校生以下は1500円(子供料金)
- 毎月1日は一律1000円(映画の日)
※2つ以上の割引サービスの適用が重なった場合は金額が低いほうを優先
※高校生以下のレイトショーの入場制限は考慮しない

### 条件と動作の抽出
この場合の条件と動作は以下のように考えられます
- 条件
    - 映画の日
    - レイトショー
    - 高校生以下(子供料金)
- 動作
    - 1000円
    - 1200円
    - 1500円
    - 1800円

条件が3つあるので2の3乗の組み合わせがあるので,
YとNのすべての組み合わせで升目を埋めます.("組み合わせを生成"を選択)
![スクリーンショット 2024-12-16 153915.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3586226/11e0946d-633e-c5f9-e111-7109e5dda98c.png)

### 動作の記入
条件を考えたら動作を埋めます.
![スクリーンショット 2024-12-16 154530.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3586226/af2fe848-4cba-359a-46a3-64d085287675.png)

### 表の簡略化
ここで,ルール1~4は最初の条件である「映画の日」が「Y」になった時点で,
動作は必ず1000円となります
したがって,1つのルールにまとめることができます.(「-」はどちらでもよいという意味)
これによりルールを減らすことができ,テストケースを削減できます.
![スクリーンショット 2024-12-16 163326.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3586226/9421d193-c02b-f9a6-0d6a-9de1bcbb1549.png)


# デシジョンテーブル使用例2
以下のDVDレンタルの料金割引に対して適用することを考えてみます.

#### レンタルDVDの料金割引設定
- 年齢が18歳以下は10%オフ
- 年齢が65歳以上は20%オフ
- 旧作(レンタル開始日から6ヶ月以上経過)は半額
※ただし2つ以上の割引の適用条件が重なった場合は,割引率の高いほうを優先

### 条件と動作の抽出
この場合の条件と動作は以下のように考えられます
- 条件
    - 18歳以下
    - 65歳以上
    - 旧作
- 動作
    - 10%オフ
    - 20%オフ
    - 50%オフ
    - 割引なし

条件が3つあるので2の3乗の組み合わせがあるので,
YとNのすべての組み合わせで升目を埋めます.
![スクリーンショット 2024-12-16 161122.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3586226/e98261e2-e94d-3134-d3b3-29be44f24de1.png)

### 矛盾条件の削除
ここで,18歳以上かつ65歳以上の両方を満たすような人は存在しないので
「N/A」を動作に記入して動作を埋めます.
![スクリーンショット 2024-12-16 161652.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3586226/5a69f1ce-5f51-5f28-9ffd-d29e1ae193c8.png)


# 最後に
GIHOZを用いたデシジョンテーブルにより,条件のすべての組み合わせの洗い出しや,
テストケースの作成を簡単に行うことができました.

すべての組み合わせを洗い出すのはよいですが,必要に応じて分割や簡略化などをし,
テスト実施が可能な項目数になるようなテーブルを作成するようにしたいと思いました.

次回以降では状態遷移テストと境界値分析に対してGIHOZを用いていきたいです.


# 参考
[ソフトウェアテストの教科書](https://www.amazon.co.jp/%E3%80%90%E3%81%93%E3%81%AE1%E5%86%8A%E3%81%A7%E3%82%88%E3%81%8F%E3%82%8F%E3%81%8B%E3%82%8B%E3%80%91-%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2%E3%83%86%E3%82%B9%E3%83%88%E3%81%AE%E6%95%99%E7%A7%91%E6%9B%B8-%E5%A2%97%E8%A3%9C%E6%94%B9%E8%A8%82-%E7%AC%AC2%E7%89%88-%E5%B8%83%E6%96%BD/dp/481560875X)
EventBridgeを使ってTransitGatewayに更新があったら通知する

# 目的
TransitGatewayのルートテーブルが更新されたら関係各社に通知したい。

# 設定の背景
TransitGatewayのルートテーブル更新にて誤ったルートが追加されたものの、更新された事実が周知されておらず原因解決までに時間をかけた。あらかじめ設定して通知することで周知漏れをなくす。

# 前提条件
SNSトピックが作成済みであること。
Transitgatewayが作成済みであること。

# 実装方法手順
１．EventBridgでルールを作成し、Eventパターンを設定する。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/398873/3f1b43c5-2229-e56b-3a94-d51158e84a19.png)

eventNameでTransitgatewayのルートテーブル更新に関するイベントを指定する。


２．ターゲットの指定
ターゲットを指定し、事前に用意した通知先のSNSトピックを指定する。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/398873/0f962d6f-216a-e518-39b2-f140d76d4703.png)

トピックのみ指定した場合、読みづらい文章となるため、入力トランフォーマーを使って可読性の高い文章にする。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/398873/453d2bdf-c7a1-9382-ea75-610392328b15.png)

入力パス：定義された情報がsnsトピックに渡される情報。
入力テンプレート：入力パスで定義した変数の情報と日本語を組み合わせて出力するテンプレートを定義する。

以下、入力トランスフォーマーの組み合わせ
```
{
  "TransitGatewayAttachmentId": "$.detail.requestParameters.CreateTransitGatewayRouteRequest.TransitGatewayAttachmentId",
  "UserID": "$.detail.userIdentity.arn",
  "account": "$.detail.userIdentity.accountId",
  "cidrblock": "$.detail.requestParameters.CreateTransitGatewayRouteRequest.DestinationCidrBlock",
  "eventID": "$.detail.eventID",
  "eventname": "$.detail.eventName",
  "region": "$.detail.awsRegion",
  "tgw-routetable-id": "$.detail.requestParameters.CreateTransitGatewayRouteRequest.TransitGatewayRouteTableId",
  "time": "$.detail.eventTime"
}
```
```
"TransitGatewayのルートテーブルが更新されました。"

"イベント名 : <eventname>"
"イベントID : <eventID>"
"アカウントID : <account>"
"発生時刻 : <time>"
"変更作業実施者 : <UserID>"
"発生リージョン : <region>"
"TransitGatewayルートテーブルのID <tgw-routetable-id>"
"宛先CIDR : <cidrblock>"
"NexthopのTransitGatewayアタッチメントID : <TransitGatewayAttachmentId>"
```

メール出力例
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/398873/9418403b-653d-8755-3b25-d44e151e3eae.png)
typeofとkeyofについて

業務でtypeofとkeyofが出てきたので、備忘録として残しておきます。
（typescriptの型関連が難しい......）

## **typeofとは**

 `typeof` を使うことで、オブジェクトや変数の**型そのもの**が取得できます。

### **使用例**

```tsx

const person = {
  name: "Alice",
  age: 30,
};

// `person` と同じ構造の型を定義
type PersonType = typeof person;

const anotherPerson: PersonType = {
  name: "Bob",
  age: 25,
};
```

**ポイント**:

`typeof person` は `person` オブジェクトの型 `{ name: string; age: number }` を取得します。
こうすることで、`person`に新しいプロパティを追加しても、`PersonType`を自動的に更新できるので、変更に強いコードとなります。


## **keyofとは**

`keyof`をつかうことで、オブジェクト型の**キー（プロパティ名）を文字列リテラル型**として取得できます。（型のみで使用可能）


### **使用例**

```tsx

type Example = {
  a: number;
  b: string;
  c: boolean;
};

// keyof を使用
type Keys = keyof Example;
// Keys は "a" | "b" | "c" というリテラル型

const obj: Example = { a: 1, b: "hello", c: true };

// 型安全なプロパティアクセス
const getValue = (key: Keys): Example[Keys] => obj[key];

const valueA = getValue("a"); // OK: number型
const valueB = getValue("b"); // OK: string型
// getValue("d"); // エラー: '"d"' は 'Keys' に割り当てられません

```

**ポイント**:

 `keyof Example` は `Example` 型のすべてのプロパティ名をリテラル型として取得します。
`keyof`を使うと、プロパティ名以外の無効なキーにアクセスしようとするとエラーになるため、型安全な操作が可能となります。

## **typeof と keyof を組み合わせた場合**

以下はオブジェクトのプロパティ名と値を利用した例です。

```tsx

const Status = {
  SUCCESS: "success",
  ERROR: "error",
  LOADING: "loading",
} as const;

// typeof と keyof を使って型を生成
// type StatusValue = (typeof Status)[keyof typeof Status] でも同じ
type StatusKey = keyof typeof Status; // "SUCCESS" | "ERROR" | "LOADING"
type StatusValue = (typeof Status)[StatusKey]; // "success" | "error" | "loading"

// 型安全な関数
function handleStatus(status: StatusValue) {
  if (status === "success") {
    console.log("Operation was successful!");
  } else if (status === "error") {
    console.log("An error occurred.");
  } else if (status === "loading") {
    console.log("Still loading...");
  }
}

// 使用例
handleStatus("success"); // OK
// handleStatus("unknown"); // エラー

```

**ポイント:**

`keyof typeof Status`でキーリテラル型（"SUCCESS" | "ERROR" | "LOADING"）を取得します。
次に、`(typeof Status)[keyof typeof Status]`で値リテラル型（"success" | "error" | "loading"）を取得します。

### **`as const` の補足説明**

```tsx
const Status = {
  SUCCESS: "success",
  ERROR: "error",
  LOADING: "loading",
} as const;
```

 **`as const` の役割**:
- Status を読み取り専用（`readonly`）にする。
- 各プロパティの型を `"success"`, `"error"`, `"loading"` のリテラル型に変換する。
　（`as const` がない場合、Status のプロパティは一般的な `string` 型と解釈されてしまうので、リテラル型の恩恵を受けられない。）


## **まとめ**

- **`typeof`**:
    - 変数やオブジェクトの型を取得して再利用できる
    - 型定義を重複せず、変更に強いコードが書ける
- **`keyof`**:
    - オブジェクト型のすべてのキーをリテラル型として取得する
    - 型安全なプロパティアクセスが可能となる
- **`typeof` と `keyof` の組み合わせ**:
    - typeofで型を取得して、keyofでプロパティ名をリテラル型で取得することで、型安全なキーや値の操作が可能となる
    


使用方法はなんとなくわかったけど、実際に使いこなせるのか:cry:
実務経験をたくさん積みたい。
体系的なエンジニアのスキルマップを考える

エイチームライフデザインで開発グループのアシスタントマネージャーを務める髙木です。

マネージメントされる方々、チームをリードする方々において、悩ましいのはエンジニアのスキルが事業（ビジネス）視点でどのように活かされるかではないでしょうか。この視点が不明確だと、必要な人員数や体制を感覚に基づいて決めざるを得ず、育成面でもどこに注力すべきか判断に迷います。
ということで、この記事ではエンジニアのスキルの表現の難しさと、ビジネスとの接続について具体的な戦略を紹介していきます。

## エンジニアスキルの特徴
ビジネス職の発揮するスキルは目に見えないソフトスキルが多いのに対し、エンジニアは扱える言語やサービスというハードスキルがメインです。私の中では、ビジネス職は魔法使いのイメージで、エンジニアは多種多様な武器を扱う暗器使いのイメージです。

エンジニアのスキルは具体的で、どの程度優れた武器（技術）を持っているかはわかりやすい一方で、それがビジネスにおいて有効かどうかは必ずしも明らかではありません。
ビジネスの現場ではそのスキルが事業にとってどのような価値を生み出すかが見えにくいため、ビジネス視点でのエンジニアのスキルの表現を難しくしています。
そこで、「ビジネスにおいてエンジニアがどのように関与しているか」を紐解くことがこの難しさを打開するキーだと考えます。

## 事業プロセスにエンジニアがどう関わっているか
どんなビジネスもバリューチェーンで考えることができます。弊社のようなWebサービスの場合、以下の流れでエンジニアが全プロセスを支えていることがわかります。

- 集客（SEOや広告）:
    - エンジニアはSEO最適化や広告技術を駆使して、デジタルチャネルの効率を最大化します。
- 獲得（コンバージョンを上げる）: 
    - 顧客獲得に向けた施策を通じ、ユーザーエクスペリエンスを向上させ、コンバージョン率を高めます。
- 接客:
    - 顧客対話を支援するチャットシステムやカスタマーサポート機能を開発します。
- 販売・マーケティング:
    - 販売促進やクライアントへの価値提供を強化する技術基盤を整備し、マーケティング活動を支援します。

事業において、各ビジネス職はプロセスごとの役割を担い、エンジニアはその横断的な支援をしています。
つまり各プロセスへの技術的支援がエンジニアの価値を形成し、どのプロセスでどのように関与できるかが重要なスキルの基準となります。

## 事業プロセスにおけるエンジニアのスキルの基準
事業プロセスにおけるエンジニアのスキル感は作業フェーズごとの習慣づいた行動を基準とします。
一般にエンジニアの作業フェーズは以下の通りです。

- 企画・要件定義
- 設計
- 開発

各フェーズでの行動を5段階などのスキルレベルとした場合
例えば、企画・要件定義ですと私たちのチームでは最大のレベル5では「事業課題を理解し、技術的な視点で解決策を提言できる」こととしています。
このようにスキルの基準を定めることで、プロセスごとの支援する力の過不足がわかり、後の育成方針の策定にも役立ちます。

## 育成に向けて、リポジトリ単位でのスキル網羅度をチェックする
エンジニアの技術力を発揮した成果物はアプリケーションやサービスです。
アプリケーションやサービスを更に細分化するとインフラ・バックエンド・フロントエンドなどのリポジトリとなります。
これらの機能が寄り集まってアプリケーションやサービスを成し、事業を支援していることになり、
エンジニアの技術力 → リポジトリ → 事業プロセスの支援　という体系に整理することができます。

このように整理することで、事業プロセスの支援の状況から、スキル感として課題のあるリポジトリはどこか、そのリポジトリを扱うために必要な技術スキルはなにかと特定することができるようになります。

## 最後に
散々書いてきましたが、結局のところは組織の形によってアプローチは異なると思います。
ただしどのような組織でも会社であり事業を行っている以上は事業としての目的・目標があり、
エンジニアが所属しているのであればそれを何らかの形で支援しているはずです。
全体の目的から技術スキルまで徐々にブレイクダウンしていくことで、本当に必要な・伸ばすべき・得るべき技術がなにかを特定することができます。
そしてそれはマネジメントとしてチーム運営をする面でも、１人のエンジニアとして自分のどのスキルを伸ばしていくかという点でも重要なものと考えています。
参考になれば幸いです。
requirements.txtのバージョン固定について



# システムリリース前のrequirements.txtのバージョン指定について

開発において必ず直面するであろう「requirements.txt」の扱い。特に、システムをリリースする前にパッケージのバージョンをどのように指定するかについて、以下に備忘録として整理します。



## 開発初期：バージョン指定なしで進める

開発初期段階では、最新バージョンを使用するのが一般的？です。そのため、`requirements.txt`にはバージョン指定をしない形で記載します。私が今回経験した小規模な開発（開発メンバー二人のRAGシステム）の場合だと、以下のように記述して進めました。（大規模な開発な場合はどうするか知らないので教えて下さい）

```txt
fastapi
uvicorn
```

この段階では、開発環境で以下のコマンドを使って必要なパッケージをインストールします。

```bash
pip install -r requirements.txt
```

その後、一連の動作確認を行います。開発が進むにつれてここにはどんどん追記していきます。バージョンしてはしない。



## リリース準備段階：バージョン固定

リリース段階に入ると、バージョンの自動更新によるバグ発生を避けるために、パッケージのバージョン固定が必要になります。

1. まず、既存の`requirements.txt`にバージョン指定が含まれている場合は、一度バージョン指定を取り除きます。他の開発メンバーが以下のように追加したと仮定しましょう。

**変更前**
```txt
langchain-core==0.3.11　←これと
langchain-openai==0.1.12　←これが最新版ではないとする
```

**変更後**
```txt
langchain-core
langchain-openai
```

2. その上で、再度以下のコマンドを実行し、動作確認を行います。バージョン指定をしないでpip install -r requirements.txtをすると最新バージョンがインストールされるため。

```bash
pip install -r requirements.txt
```

3. 動作確認で問題がなければ、以下のコマンドを使用して、バージョンを固定した`requirements.txt`を生成します。（pip freezeは現在使用しているバージョンを出力するコマンド。ここではrequirements.txtに書き加える処理を加えている。）

```bash
pip freeze > requirements.txt
```

※確認だけしたい場合は、`pip freeze`コマンドのみを実行して出力結果を確認するのが良いです。

この手順により、最新版での動作確認とバージョン固定を完了させることができます。
例：上記手順に従うと0.3.11→0.3.22の最新版に切り替わります
```txt
langchain-core==0.3.22　←両方とも
langchain-openai==0.2.12　←最新に変わる！
```



## 先輩談：バージョン固定は必須か？

以下は、先輩エンジニアとのやり取りを基にした知見です。

**私の質問**
- お客さんに提供するシステムでは、パッケージのバージョンを指定するのが一般的でしょうか？
- バージョン指定がない場合、最新バージョンがインストールされて急にバグが発生する可能性があるでしょうか？
- 開発初期はバージョンを指定せず、運用に向けて途中から固定するケースもあるのでしょうか？

---

**約10年目の先輩の回答**

- 基本的には**バージョンを固定化するのが一般的。**
→クラウド環境では勝手にバージョンが上がることがあるため、依存関係によるエラー発生の可能性がある。固定できるところは固定しよう。
- 日本企業では、バージョン固定を運用方針に含めている事もある。
（運用方針で定期的に見直すとか記載しますけど、あんまり弄らない。弄りたくない）

**以下、先輩の経験談**
>携わった案件だとAzureのkubetainesが固定運用でスタートと半年一回のリリース（1年程度でそのバージョンは廃止。画面から消える。その中の変更もできなくなる。アップデートもサポート対象外）なので運用チームが更新に頻度に耐えれないとなったケースもあるので固定が正解ではないと考えてます。

**以下、年次の近い別の先輩の経験談**
>バージョン固定せずにリリースをしてしまい、リリース後に大変なことになりました。。。

# 結論
・開発初期： 最新バージョンで進め、柔軟性を重視。
・リリース前： pip freezeでバージョンを固定し、安定性を確保。
・運用： 脆弱性チェックを定期的に実施しつつ、必要最低限の変更で対応。
いたわり充電のバイブがうるさくなった

けっこう時間かかったので備忘録

## 寝る時に充電するようになった

ドラクエウォーク「ゆうべはおたのしみでしたね」機能がリリースされて、夜枕元で充電しながら寝るようになった。
なぜならバッテリー消費が半端ないので。

https://ameblo.jp/kuroisannchi/entry-12867430116.html

https://x.com/musui365/status/1834348022047932796

### しかたない充電しながら寝よう、だが

バッテリーの寿命も気になるのだが、もうひとつ地味に気になることが増えた。
ベッドの隣には私が寝るころには、横に既に寝ている人間がいる。
実はマイXperiaは「いたわり充電」というのを設定しているせいか、よっこらせ、と充電ケーブルに指すと通知音（バイブ設定にしているので正確には通知バイブ）がなるようになっている。
この音は日中は気にならないのだが、就寝時の枕元ではこれが結構うるさい。横で寝ている人間を起こすのは遺憾だ。

### あれ？バイブ消えない

ネットの情報見ながら通知音消したつもりなのだが、消えない。。。
・ぶーっ、ぶーっ
という音だったのが、
・ブー
まではできた。騒音は半減したが、求めているのはそういうことじゃない。

### 奮闘の結果

できた！
- 充電時の音設定
- 「いたわり充電」の通知の音設定
- 「いたわり充電」の通知のバイブ設定

上記３点セットで設定しないとダメだった。
そもそも、「いたわり充電」の通知でサイレントを選択できないことから躓き、さらに音設定で音無しに設定できるのになかなか気づけずだった。。。
→「標準」という音の種類があることを知らず、標準ボリューム？だから無関係よね、と思っちゃった。

↓充電開始音　をまずオフに

<img width=200 src=https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3916302/fad6f007-f3ba-d416-599e-c8080e03c161.png>


↓いたわり充電中の通知（グレーアウトしてるので当初は押せると思わんかった）　→音を無し＋バイブレーションをオフに

<img width=200 src=https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3916302/ffbf7a65-c88a-0108-801d-ba6f957c9390.png>

<img width=200 src=https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3916302/d219ac4e-70c7-6ae2-f56c-cd589455f54c.png>
大学のwebページのスクレイピング＆課題通知

coursepowerの課題通知アプリ！]
[* 目的：]Coursepowerの課題の通知が来ないので、毎日メールを送信し、課題が残っているかを確認できるようになると便利だと考えた。

html
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3938270/a6fa42ec-2bad-ccd4-e8d1-f07bf580a6d7.png)

メールの例
![mail.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3938270/a9f4463a-2ab0-27c0-37e7-231ea34d7bb6.png)


# CPメール通知アプリケーション要求仕様書
[* ## 1. 概要]
CPメール通知アプリケーションは、ユーザーが指定したスケジュールに基づいて、CoursePowerのレポート提出期限通知を自動的に取得し、指定されたメールアドレスに通知するデスクトップアプリケーションです。本アプリケーションはElectronを使用して構築され、Pythonスクリプトを実行して通知を取得します。

[* ## 2. 機能要件]
### 2.1 ユーザーインターフェース
- ユーザーは以下の情報を入力するフォームを提供される
  - ユーザーID (Tora-Net Portal)
  - パスワード (Tora-Net Portal)
  - メールアドレス (通知が送られるアドレス)
  - スケジュール (HH:MM形式)

### 2.2 データ保存
- ユーザーが入力した情報は、`user_data.json` ファイルに保存される

### 2.3 Pythonスクリプトの実行
- ユーザーがフォームを送信すると、`CPmail.py` スクリプトが実行される
- `CPmail.py` スクリプトは、CoursePowerからレポート提出期限通知を取得し、指定されたメールアドレスに通知を送信する

### 2.4 ウィンドウの表示
- アプリケーションを起動すると、ウィンドウは最大化される

[* ## 3. 非機能要件]
### 3.1 パフォーマンス
- アプリケーションはユーザーの入力に対して迅速に応答する
- Pythonスクリプトの実行は、ユーザーが気付かない程度の時間で完了する

### 3.2 ユーザビリティ
- ユーザーインターフェースは直感的で使いやすい
- エラーメッセージはユーザーにわかりやすく表示される

[* ## 4. システム要件]
### 4.1 ソフトウェア要件
- Node.js
- Electron
- Python
- 必要なPythonライブラリ（selenium、schedule、smtplibなど）

### 4.2 ハードウェア要件
- Windows PC

[* ## 5. ファイル構成]
### 5.1 プロジェクトディレクトリ構造
cp-mail-app/
├─main.js
├─renderer.js
├─index.html
├─styles.css
├─CPmail.py
├─app.py
├─user_data.json
├─package.json
└─static/
    ├─styles.css
    └─tyutora1.png

### 5.2 各ファイルの説明
- `main.js`: Electronのメインプロセスを設定するファイル
- `renderer.js`: フォームのデータを保存し、Pythonスクリプトを実行するファイル
- `index.html`: ユーザーインターフェースを提供するHTMLファイル
-style.css: アプリケーションのスタイルを定義するCSSファイル。
- `CPmail.py`: CoursePowerから通知を取得し、メールを送信するPythonスクリプト
- `app.py`: Flaskアプリケーション（必要に応じて使用）
- `user_data.json`: ユーザーの入力データを保存するJSONファイル
- `package.json`: プロジェクトの設定と依存関係を定義するファイル
- `static/`: 静的ファイル（CSS、画像など）を格納するディレクトリ

[* ## 6. 開発手順]
### 6.1 環境設定
1. Node.jsをインストールする
2. Pythonをインストールする
3. 必要なPythonライブラリをインストールする。
   pip install selenium schedule
### 6.2 プロジェクトのセットアップ
1. プロジェクトディレクトリを作成する
2. `package.json` を作成し、Electronをインストールする。
   npm init -y
   npm install electron
### 6.3 アプリケーションの実行
1. 以下のコマンドを実行してアプリケーションを起動する。
   npm start
### 6.4 アプリケーションのビルド
1. `electron-packager` をインストールする。
   npm install electron-packager --save-dev
2. 以下のコマンドを実行してアプリケーションをビルドする。
   npm run package

使用したファイルは、容量が大きいためgooglechromeで送信。

[* 参考URL]
・Seleniumについて　https://yuki.world/python-selenium-chromedriver-auto-update/#t_Selenium_46
・Pythonのログインのスクレイピングについて https://www.miracleave.co.jp/contents/1202/post-1202/
・ChromeDriverについて　https://voicetechno-jp.secure-web.jp/ChromeDriverV115orNewer.html
・chatgpt、githubcopilotを使用
3Dスキャン計測

産業生産や機械工学の分野では、測定は極めて重要な役割を果たします。部品加工から製品の品質検査まで、正確な測定は生産効率や完成品の品質に直接影響を与えます。近年、3Dスキャン技術の普及により、「スキャン計測」という新しい概念が従来の測定手法に取って代わりつつあり、産業測定の新たな基準として注目を集めています。  

### **3Dスキャン計測とは何か？**  
3Dスキャン計測は、3Dスキャン技術と精密測定を組み合わせた手法です。レーザーや構造光スキャンを用いて物体の3次元情報をデジタルモデルに変換し、専用ソフトウェアで寸法分析や誤差評価を行います。従来のノギス、マイクロメータ、三次元測定機（CMM）とは異なり、3Dスキャン計測では大量の点群データを一度に取得し、複雑な物体の幾何学的な細部を迅速かつ正確に捉えることができます。  
![620d57184ca7407994333eaca217e909.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3824290/c6b63ca8-acd0-5518-84c3-83681b21df42.png)


この技術の最大の利点は、スピードと広範囲なデータ収集です。従来の測定方法が1点ずつ接触して測定するのに対し、3Dスキャン計測は非接触で全体のデータを一度に取得できます。これにより、曲面や複雑な形状の測定にも対応し、試料を損傷するリスクを回避できます。  


### **3Dスキャン計測の実際の活用例**  

#### **1. 幾何学的検査の効率化**  
大量生産では、部品の一貫性検査が重要なプロセスです。従来のツールでは一度に1つの寸法しか測定できませんが、3Dスキャン計測では部品全体の形状データを迅速に取得し、設計モデルと比較して詳細な偏差分析図を生成できます。これにより、検査効率が向上し、人的エラーが大幅に削減されます。  
![9cccfdcf683c32b0bce9fe007a4ffd6a.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3824290/a7338850-1b27-8ef6-8421-22648a3ba18c.png)

#### **2. 複雑な部品の品質管理**  
例えばタービンブレードや自動車エンジン外装のように形状が複雑で隠れた部分を持つ部品では、従来の接触式測定ツールでは対応が難しい場合があります。3Dスキャン計測は、こうした部品の幾何学的な細部を正確に捕捉し、重要な寸法の信頼性を保証します。  

#### **3. 金型や鋳物の検査**  
金型製造や鋳造工程では、寸法誤差が後の組み立て問題を引き起こす可能性があります。3Dスキャン計測を使用することで、金型や鋳物の実際の形状と設計図との違いを迅速に検出し、プロセス調整に役立てることができます。  

![9b6e7176609b3d64896f05d5e72e0e46.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3824290/6effee46-3efd-160d-a7c0-28cb7da9c822.png)

### **なぜ3Dスキャン計測を選ぶべきか？**  
従来の測定ツールと比較して、3Dスキャン計測は効率が高く、対応範囲が広いです。一度に大量のデータポイントを収集することで、部品の寸法や形状を包括的に分析できるだけでなく、データを長期間保存して後で分析や追跡することも可能です。また、非接触式測定の特徴により、表面を保護する必要がある部品や接触が困難な部品の検査にも最適です。  

3Dスキャン計測は、測定作業の流れや基準を大きく変えつつあります。生産ラインでのリアルタイム検査や複雑な部品の精密測定において、この技術は他に類を見ない利点を発揮します。機器の精度向上やソフトウェアの継続的な進化に伴い、この技術は産業のスマート化のあらゆる分野でさらに広く活用されることでしょう。効率と競争力を向上させたいと考える企業にとって、今こそこの技術を導入する最適なタイミングです。

計測グレードの 3D スキャナ 

https://www.revopoint3d.jp/products/3d-laser-scanner-metrox

https://www.revopoint3d.com/products/3d-laser-scanner-metrox
AWS ChatbotでSlackのプライベートチャンネルに連携できないとき

AWSのChatbotでSlackのプライベートチャンネルにテスト送信しても何も受信しないので少々はまりました。
調べてみるとSlackの対象チャンネルで以下のコマンドを打ってAWSを招待するとできると書かれていたりしますがなぜか「有効なメンバー名が必要です」とSlackbotから返されるばかりで招待できず。

```
/invite @aws
```

結局、以下のように大文字にするだけということが判明しました。なんでみんな小文字で説明してるの？？

```
/invite @AWS
```
気軽にProxmoxをインストールしてみよう

Proxmoxのインストール手順のページは既にたくさんありますが、2024年12月現在の最新版ということで改めて書かせていただきます。
## Proxmoxをダウンロード
以下のサイトよりProxmoxのISOファイルをダウンロードします。
https://www.proxmox.com/en/
2024年12月16日現在では最新版は8.3でした。
左側の「Proxmox Virtual Environment」をダウンロードします。
![proxmox00.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/101744/4f210ff3-b898-ab39-8874-b6c240a4d6b8.png)

今回は気軽にインストールしてみよう！ということでVMware Fusionを使って仮想マシンとしてProxmox環境を作ります。
通常はこんなことはしないと思いますがProxmoxってどんな感じか体感できると思います。

以下はVMwareFusionの画面です。新規の仮想マシンを作成して赤枠部分にダウンロードしたISOファイルをドラック＆ドロップします。
VMwareFusionが無いとできないわけでは、ありませんのでお使いの環境でISOファイルから起動きる環境を作れればそれで問題ありません。
![proxmox00a.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/101744/65b17faa-e919-4e9e-7ed3-80a87bd1721d.png)
その他のメモリ容量などはお使いの環境に合わせて設定してください。
## Proxmoxインストール
ISOから起動すると以下のような画面が現れます。一番上の「Install Proxmox VE(Graphcal)」を選択します。
![proxmox01.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/101744/bf401a6b-7fa1-5b5e-e8aa-fe927c72a9d9.png)
ライセンスに関しては同意するので「I agree」をクリックします。
![proxmox02.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/101744/b7cb0d3c-e257-18e0-8d61-de367a121d3e.png)
次にインストール先のディスクを選択します。特に変更する必要がなければ確認だけして「Next」をクリックします。
![proxmox03.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/101744/67b4a7d8-68cc-c3df-a83d-38fb89b42238.png)
次にタイムゾーンを選択します。日本で問題ないと思いますので、そのままで「Next」をクリックします。
![proxmox04.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/101744/f6c4058f-4f18-50c6-015f-8fa26ae06b9d.png)
次にrootユーザーのパスワードとメールアドレスを入力します。お使いのメールアドレスを入力してください。
![proxmox05.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/101744/92616bab-1cd2-ec2a-7355-5a5d7e591831.png)
次にProxmoxのホスト名とネットワークの情報を入力します。
これは環境によって異なりますのでお使いの環境に合わせて設定します。
![proxmox06.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/101744/c970b88b-6e66-966e-c4f3-7de72c580770.png)
最後に確認がでますので、問題なけれは「Install」をクリックします・
![proxmox07.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/101744/b4b1968c-4682-386f-7433-943ff60282d6.png)
たったのこれだけです。非常に簡単です。
インストールが終わると自動的に再起動されます。

再起動が環境すると以下のような画面は表示されます。
ご丁寧にブラウザでアクセスするためのURLを表示されますので実際にブラウザでアクセスしてみましょう。
![proxmox08.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/101744/bb2d0c2e-4674-5af3-b111-fa76a709748e.png)

ブラウザでアクセスすると以下のような画面が表示されます。
ユーザーは「root」でパスワードはインストール時に設定したパスワードになります。
![proxmox09.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/101744/5cd33d74-3a20-08e5-2401-b1a401e9ff2a.png)
ログインできると以下のような画面になります。
![proxmox10.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/101744/4fa3501a-de74-d41b-5f8c-6be7e64efea9.png)

以上がインストール手順になります。
非常に簡単でしたね！是非お試しいただければと思います。
「赤黄チェックは、建築業界だけですか？」AI先生に聞きました。

・先生の回答によって、途中私の質問内容を一部変えています。

#### 赤黄チェックは、建築業界だけですか？

# Gemini先生へ
>(回答抜粋)
>・赤黄チェックの特徴
>赤色と黄色のペンを使用: 赤色で間違い箇所を指摘し、黄色で修正箇所を指示することで、視覚的に分かりやすく確認することができます。

ペーパーレスの時代でも、赤黄チェックされていますか。

>(回答抜粋)
>デジタル化が進んでも、これらの規定に沿ったチェックを行う必要があります。

赤黄チェックされた紙は、最終的にどのように扱われますか。

>(回答省略)

# ChatGPT先生へ

>(回答抜粋)
・建築や土木の現場では、施工図や計画図の内容を確認する際に、「赤ペン」で修正箇所を記入し、「黄色」で承認や完了のチェックをする方法です。
・他業界での具体例
医療業界：診療記録やチェックリストで、ミス防止のために修正箇所や承認済み項目を色分けすることがあります。
教育業界：採点やフィードバックで、間違い（赤）と改善済み（黄色）を明示することがある。

教育業界について、詳しく教えて下さい。

>(回答抜粋)
赤ペンで指摘した部分を、黄色マーカーで「改善済み」としてチェックさせることで、自己修正の意識を高めます。
具体例:
漢字練習帳: 間違えた漢字を赤で記入させ、生徒が書き直し、再練習が終わった箇所に黄色でチェックを入れる。
数学の演習問題: 間違いを赤で示し、生徒が正答を導き出せた場合、黄色で達成マークを記入。

＞**自己修正の意識**
＞あらためて。

ペーパーレスの時代でも、赤黄チェックされていますか。

>(回答抜粋)
具体例:
MoodleやCanvas: 課題の提出状況や進捗を、赤（未提出）、黄色（提出済みだが未採点）、緑（採点済み）と色で表示する機能があります。
ClassDojo: 行動管理や学習進捗を色で示し、赤で要改善、黄色で進行中、緑で達成済みを表現。

＞緑...
＞**赤色と黄色の箇所を、鉛筆で(丸く)囲む技があります。**
＞黄色の使い方が、教育業界と建築業界と異なるようです。???

赤黄チェックされた紙は、最終的にどのように扱われますか。

>(回答省略)　

＞教育業界でした。元に戻りまして。
**建築業界の** 赤黄チェックされた紙は、最終的にどのように扱われますか。

>(回答省略)

# Copilot先生へ
未



# 参考

https://www.google.com/search?q=%E8%B5%A4%E9%BB%84%E3%83%81%E3%82%A7%E3%83%83%E3%82%AF&sca_esv=9e9c33286d1c223f&rlz=1CAUHAM_enJP1105&sxsrf=ADLYWIKVYmyJUOdJIcXtaDnUWuYvW4DsKw%3A1734327959463&ei=l75fZ-D3G_Wh1e8P-ui06Ak&ved=0ahUKEwign8qPy6uKAxX1UPUHHXo0DZ0Q4dUDCBA&uact=5&oq=%E8%B5%A4%E9%BB%84%E3%83%81%E3%82%A7%E3%83%83%E3%82%AF&gs_lp=Egxnd3Mtd2l6LXNlcnAiEui1pOm7hOODgeOCp-ODg-OCrzIHECMYsAMYJzIKEAAYsAMY1gQYRzIKEAAYsAMY1gQYRzIKEAAYsAMY1gQYRzIKEAAYsAMY1gQYRzIKEAAYsAMY1gQYRzIKEAAYsAMY1gQYRzIKEAAYsAMY1gQYRzIKEAAYsAMY1gQYRzIKEAAYsAMY1gQYR0j3IFAAWABwAXgBkAEAmAEAoAEAqgEAuAEDyAEAmAIBoAIamAMAiAYBkAYKkgcBMaAHAA&sclient=gws-wiz-serp

https://www.google.com/search?q=%E8%B5%A4%E9%BB%84%E3%83%81%E3%82%A7%E3%83%83%E3%82%AF+%E3%82%BD%E3%83%95%E3%83%88&sca_esv=9e9c33286d1c223f&rlz=1CAUHAM_enJP1105&sxsrf=ADLYWIKVYmyJUOdJIcXtaDnUWuYvW4DsKw%3A1734327959463&ei=l75fZ-D3G_Wh1e8P-ui06Ak&oq=%E8%B5%A4%E9%BB%84%E3%83%81%E3%82%A7%E3%83%83%E3%82%AF&gs_lp=Egxnd3Mtd2l6LXNlcnAiEui1pOm7hOODgeOCp-ODg-OCryoCCAAyChAAGLADGNYEGEcyChAAGLADGNYEGEcyChAAGLADGNYEGEcyChAAGLADGNYEGEcyChAAGLADGNYEGEcyChAAGLADGNYEGEcyChAAGLADGNYEGEcyChAAGLADGNYEGEcyChAAGLADGNYEGEcyChAAGLADGNYEGEdIgB5QAFgAcAF4AZABAJgBAKABAKoBALgBAcgBAJgCAaACJZgDAIgGAZAGCpIHATGgBwA&sclient=gws-wiz-serp

# 参考(別件) おすすめ色鉛筆
・黄色１本。ちょっと値段が高いけど、離れられなくと思います。
・ユニ **消せる色鉛筆** アーテレーズカラー

https://www.monotaro.com/g/04954571/#

https://www.mpuni.co.jp/products/pencils/color/uni_series/arterase_color/uac.html

・フリクション もありました。

# 参考(別件)
・MoodleやCanvas

・学習管理システム（LMS）＜ eラーニング ＜ wikipedia

https://ja.wikipedia.org/wiki/E%E3%83%A9%E3%83%BC%E3%83%8B%E3%83%B3%E3%82%B0#%E5%AD%A6%E7%BF%92%E7%AE%A1%E7%90%86%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0

・ClassDojoのwikipediaの日本語版がありませんでした。

https://en.wikipedia.org/wiki/ClassDojo
2024年よく使用されるGoLandの新機能の紹介


この記事は [Wano Group Advent Calendar 2024](https://qiita.com/advent-calendar/2024/wano-group) の21日目の記事です。


## 概要

Go言語の開発環境（IDE）には様々な選択肢がありますが、自分が一番使っているのはGoLandです。2024年は多くの機能アップデートがあり、この1年間の開発経験を通じて特に印象的だった新機能をいくつかご紹介します。
 
### 行全体コード補完

昨今、開発現場ではAIを活用したコード補完が主流となっていますが、セキュリティ上の懸念も少なくありません。この新機能はオフラインで動作し、開発データを一切外部に送信しないため、機密性の高いプロジェクトでも安心してご利用いただけます。

![FLCC_demo.gif](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/153285/1bcbc32c-e82b-d6fb-397c-46e9b00d92df.gif)


### インスペクションの強化

[データフロー解析](https://blog.jetbrains.com/go/2024/03/26/data-flow-analysis-for-go/)の導入により、以下のような検証が可能になりました：
 - 定数条件の検出
 - 潜在的なnilポインタの参照の特定
 - nilの可能性があるエラー値の検出
 - 循環インポート

これは開発過程で発生しうるロジックエラーの検知に非常に役立ちます。

![スクリーンショット 2024-12-15 16.34.15.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/153285/a83081f3-2d72-4be0-8a69-0490470ade9f.png)

![スクリーンショット 2024-12-15 17.46.43.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/153285/5e51f34e-c9c6-f925-f5ea-702e69b6cda0.png)


### 型の逆推論および型表示機能

この機能の追加により、コードを読みやすくなります。

![スクリーンショット 2024-12-15 16.58.37.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/153285/552acd18-d4b8-d3b7-aaff-17c1c9d2ae4b.png)

![スクリーンショット 2024-12-15 16.58.00.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/153285/f0e3a34c-910b-bf73-ff07-c51f984a3613.png)


### 最後に

その他には、最新Go言語機能のサポート、プラグインのサポート、VS Codeから設定を移行のサポート、有料機能の AI アップデートなど、多くの新機能がありますので、興味のある方は是非[公式ページ](https://www.jetbrains.com/ja-jp/go/whatsnew)を参照してください。


### 参考
[公式ページ](https://www.jetbrains.com/ja-jp/go/whatsnew)

### PR
現在、Wanoグループでは人材募集をしています。興味のある方は下記を参照してください。

https://herp.careers/v1/wano
[golang] スライスを初期化するときには、なるべく容量(or 長さ)を指定しよう

# 目的
スライスの最終的な容量(長さ)がわかっている場合は、スライスの容量(長さ)を指定して定義するべきということを理解する。

# 検証
``` pra_slice_append_test.go
package main

import (
	"testing"
)

var globSlice []int

func BenchmarkPraSliceAppend1(b *testing.B) {
	var tmpSlice []int
	for n := 0; n < b.N; n++ {
		tmpSlice = PraSliceAppend1()
	}
	globSlice = tmpSlice
}

func BenchmarkPraSliceAppend2(b *testing.B) {
	var tmpSlice []int
	for n := 0; n < b.N; n++ {
		tmpSlice = PraSliceAppend2()
	}
	globSlice = tmpSlice
}

func BenchmarkPraSliceAppend3(b *testing.B) {
	var tmpSlice []int
	for n := 0; n < b.N; n++ {
		tmpSlice = PraSliceAppend3()
	}
	globSlice = tmpSlice
}

```
``` pra_slice_append.go
package main

// //////////////////////////////////////////////////////////
// ////////////////////////////////////////////////////////// (1)
// スライスは、append のときに容量が足りない場合、容量が2倍のスライスをコピーして作成する。
// 1024 要素までは、2倍のスライスをコピーして作成するが、それ以降は、1.25倍のスライスをコピーして作成する。
// 事前にメモリを割り当てておくことで、スライスのコピーを作成する余計な処理を省くことができる。
// (2) よりも明らかに速い。
//
//go:noinline
func PraSliceAppend1() []int {
	myslice := make([]int, 0, 10000)
	for i := 0; i < 10000; i++ {
		myslice = append(myslice, i)
	}
	return myslice
}

// //////////////////////////////////////////////////////////
// ////////////////////////////////////////////////////////// (2)
//
//go:noinline
func PraSliceAppend2() []int {
	// 下記のいずれかを使う。
	// var myslice []int
	// myslice := []int(nil)
	// myslice := []int{}
	// myslice := make([]int, 0)
	myslice := []int(nil)
	for i := 0; i < 10000; i++ {
		myslice = append(myslice, i)
	}
	return myslice
}

// //////////////////////////////////////////////////////////
// ////////////////////////////////////////////////////////// (3)
// make([]int, 10000) のようにして、容量ではなくて長さをしていすることで、myslice[i] = i のようにして、スライスに要素を追加することができる。
// (1) の場合に比べて、append の分のオーバーヘッドがないため、(1) よりも少しだけ速い。
//
//go:noinline
func PraSliceAppend3() []int {
	myslice := make([]int, 10000)
	for i := 0; i < 10000; i++ {
		myslice[i] = i
	}
	return myslice
}

```
```
~/praprago$ go test -bench=. -benchmem
goos: linux
goarch: amd64
pkg: github.com/XXX/praprago
cpu: Intel(R) Xeon(R) CPU E5-2686 v4 @ 2.30GHz
BenchmarkPraSliceAppend1-2         49352             24104 ns/op           81920 B/op          1 allocs/op
BenchmarkPraSliceAppend2-2         12708             87070 ns/op          357624 B/op         19 allocs/op
BenchmarkPraSliceAppend3-2         56804             20185 ns/op           81920 B/op          1 allocs/op
PASS
ok      github.com/XXX/praprago 4.870s
```


# 参考

https://www.amazon.co.jp/-/en/Teiva-Harsanyi/dp/4295017531
【ios 18】iPhoneデフォルトキーボードの予測変換がおかしい件（解決策）

:::note warn
2024/12/27 追記
以下の対策だけではまだ治ってなさそう。
これはiosの不具合または改悪の可能性が高そう...
:::

# はじめに
こんにちは。こんばんは。@yato_wisteriaです。
ワタクシ、ios並びにiPhoneを使い続けて10年近く経ちますが、タイトルにもある通り、
最近、予測変換がいつもと違うんです。
最初は我慢していたのですが、もういい加減ストレスになってきたので、解消方法を調べたので、みなさんに共有させて頂けたらと思います。

# ⚠発生している現象
### 予測変換する際の、優先度１番目（一番左にあるやつ）が適切でない
::: note alert
最近の予測変換
`やるきはない`→`やる気じゃない`
:::

::: note info
期待する予測変換（従来）
`やるきはない`→`やる気は無い`／または`やる気はない`
:::

純粋に変換してくれればいいのに、入力ミスかな？直してあげよう！といった感じの変換になるんです。私が体験した例はまだいいですが、他のサイトで見た被験者は、「きのう→可能」であったり、「きてる→見てる」といったように、意味が変わってしまうのは中々辛いと思いました。

# ✔改善方法
![画像1.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3898103/f8a4965b-5a49-560c-95ce-116d4c7c4007.png)

```:設定方法
設定 > アクセシビリティ > スイッチコントロール > 拡張予測変換をOFFにする
```
この設定をすることで、確かに症状は改善されたかなと感じております。
皆様の助けになれたら幸いです！
もし参考になりましたら♡を押して頂けますと、今後のモチベーションになります！
以上、ありがとうございました！

____
#### 参考リンク
https://discussionsjapan.apple.com/thread/255779521?sortBy=rank

https://internet.watch.impress.co.jp/docs/yajiuma/1643156.html
勉強会を根付かせるための「プログラマが知るべき97のこと」のススメ

# はじめに

タイトルの通り、勉強会を根付かせるきっかけとして「プログラマが知るべき97のこと」を紹介します。
- チーム内に勉強や読書の習慣を根付かせたい
- 勉強会やってみたいけど何から始めたら良いかわからない

という思いのある方は参考にしてみてください。


# 「プログラマが知るべき97のこと」とは

この本は、世界中で活躍するプログラマによる97本のエッセイ集です。
各章が1ページくらいの分量で独立しており、短時間で読めるのが特徴です。
そして、無料で公開されているため、コストをかけずに始めることができます。

- [英語版](https://github.com/97-things/97-things-every-programmer-should-know)
- [日本語版](https://プログラマが知るべき97のこと.com)

# 「プログラマが知るべき97のこと」をおすすめする理由

勉強会の題材として、「プログラマが知るべき97のこと」をおすすめする理由を記します。
あくまで、題材に迷っている人へのおすすめなので、やりたい書籍があるのであれば、そちらを優先してください。

## 無料で読める

前述の通り無料で読めるため、人数分の本を用意する必要がありません。
本を買ってもらったり、買ったりしなくても始められます。

## 1章が区切りよく短い

エッセイ集なので、1つが1ページくらいのサイズで短いです。
これは、輪読形式で読んでいくのにやりやすい形式です。

## プログラマ以外にも通じる話が多い

「プログラマが知るべき」とはなっていますが、システム開発全般だったり、ビジネス全般に通じる話も多く、様々な立場の人が参加しやすくなります。

たとえば、ボーイスカウトルールでは、
> ボーイスカウトには大切なルールがあります。それは、「来た時よりも美しく」です。たとえ自分が来た時にキャンプ場が汚くなっていたとしても、そしてたとえ汚したのが自分でなかったとしても、綺麗にしてからその場を去る、というルールです。そうやって、次にキャンプに来る人達が気持ちよく過ごせるようにするのです(このルールは元々、ボーイスカウトの父と呼ばれるロバート・スティーブンソン・スミス・ベーデン=パウエルの「自分が最初に見た時よりも、世界をいい場所にすべく努力しよう」という言葉から来ています)。

というボーイスカウトのルールにならい、

>「モジュールをチェックインする際には、必ずチェックアウト時よりも美しくする」

のを心がけよう。といったことが語られます。
この辺りは、どんな仕事にも言えることですね :wink:

# 勉強会の進め方

実際に以前チームで実施した際に進めたやり方を紹介します。
もちろん、やりやすい・続けやすい形式で実施するのが重要ですので、
アレンジしたり別のやり方で実施しても構いません！

## 時間と担当を決める

夕会があったため、そこで15分ほど時間をとって実施しました。
また、担当の順番も決めます。決めた順番でローテーションしていきますが、都合次第で入れ替えてもらっても構いません。

## 本の共有

全員が無料でアクセスできるため、リンクを共有して各自で読んでもらう形式が適しています。

## 各回の進め方

1. 担当者が好きな章を選び、事前に読んでおきます (頭から読んでいくよりも、興味のあるトピックを探す動作が入るため、効果的だと考えました)
1. 担当者がその章の内容について、勉強会の中で説明します
1. 担当者がその章を読んだ感想、意見、共感した部分などを共有します
1. チーム全員でディスカッションします (意見が出なければ、ファシリテーター(本記事を読んでいるアナタ！)が意見をいったり、水を向けたりしましょう)
1. 次の担当者にバトンタッチして終了

基本的にこれを毎日繰り返していきます。

# 実際に実施しての感想

かなり前ですが、私のチームでもこの本を使った勉強会を実施しました。
当初、勉強の習慣がなかったりモチベーションが低いメンバーもいたため(シツレイ)、不安がありましたが、呼びかけてみると予想以上に多くのメンバーが参加してくれました。
その後も不定期に勉強会を継続できているので、成功したと言えるかと思います。
「うちのチームではきっと無理...」という人も、案外きっかけが無いだけで呼び掛ければ乗ってくれる人も多くいると思います。諦めずに思い切って実施してみましょう。

# まとめ

「プログラマが知るべき97のこと」を活用した勉強会は、コストが低く始めやすいだけでなく、継続もしやすいのが魅力です。特に、勉強会をこれから始めたいと考えているチームにオススメです。
少しでも興味を持っていただけたら、ぜひ試してみてください！
【Docker】Composeファイルの推奨・非推奨

## 始めに

私がcomposeファイルを書いていて、当たり前のように書いていた定義などが推奨されたものではないものがあったため、一部ですがまとめておきます。

## Compose のファイル名の推奨

書き方を調べていると、`docker-compose.yaml`や`docker-compose.yml`を使用している物が多いと思います。そのためか、あまり気が付かれていないと思いますが、`compose.yaml`が推奨されるファイル名だそうです。

> 作業ディレクトリ内での、Compose ファイルのデフォルトのパスは compose.yaml（推奨）か compose.yml です。Compose 実装は、下位互換性のために docker-compose.yaml と docker-compose.yml もサポートすべきです。両方のファイルが存在する場合、Compose 実装は標準である compose.yaml を優先しなければいけません。

https://docs.docker.jp/compose/compose-file/index.html#compose-spec-compose-file

## Version について

書き方を調べていると、`version: 3`などの指定をしていると思いますが、この定義も不要です。

> Compose 実装は、 Compose ファイルの検証にあたり、正確なスキームを選ぶためにこの version を使う べきではありません。そうではなく、 Compose ファイルが設計された時点での最新のスキーマを優先すべきです。

https://docs.docker.jp/compose/compose-file/index.html#version

## 最後に

参考にしているドキュメントを読み込めば、他にもよく「使われている方法だが非推奨」といったものがあるかもしれません。

公式サイトでも昔からあるものでは、古い定義等残っているようです。
対応しなかったからといって、直ちに動かなくなったりしないかもしれませんが、できるだけ新しい書き方、推奨された書き方をすることによって、それを防ぐことができるかと思います。