OmniAICreator/Qiita-1.07M huggingface dataset:
市民開発者を育てる上で気を付けないといけないことPart2

## 1,はじめに
下記の企画に参加しています！

https://t.co/56WibbNlvz


下記の記事を出した後にUiPathを教えていて気付いたこと、私が教える上で大事にしていることがあったので、また書きました！

https://qiita.com/thxUVER2012/items/7705d45029ae89b9bc7b

## 2,教育上配慮すること

:::note info
受講者はどのようなスタイルで講義を聞いているか確認すること。
:::

:::note warn
具体的には、パソコンのみでメモをしているかどうか。
:::
手帳やノートに書き込んでいる人もいます。
このような人がいる時には、メモを取れる時間とゆっくりと話すこと。

:::note info
講義者が説明するフェーズを共有する。
:::

:::note warn
具体的には、アクティビティの説明をしているとUiPathで動かしてしまう人がいます。
:::

その行動をされると重大な部分を聞き逃してしまいます。
そのため、例として下記のようにするといいです。
**1,アクティビティの説明をするので、動かないでください。
2,一緒に動かしてみましょうと言ったら動かしましょう。**

:::note info
具体化は人によって異なり、具体化とは誰しもが理解できるもの。
:::

:::note warn
変数とは箱のものと教えるのではなく、**私はゴミ袋**でいいかなと思いました。
:::

何故なら誰しもが1度以上はゴミの分類をしているから。
変数も分類するため、 **分類すると視点で統合できます。**
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3327229/3812d81d-4ac6-f536-0d66-40704d8e7669.png)

:::note info
講義は**数学的な考え方**に基づいて展開する。
:::

数学的な考え方とは、「帰納的な考え方」、「類推的な考え方」、「統合の考え方」、「発展的な考え方」、「拡張的な考え方」、「演繹的な考え方」などの解く手法や物事の本質を見るための考え方です。
**Gポリアの「How to Solve It(いかにして問題をとくか)」** という本が有名かと思います。

わかりやすい例が「類推的な考え方」です。
これは **「前に似たような問題を解いたことがあるな」** という感覚から今回の問題を解く考え方です。

私はこの考え方を利用できるように資料と講義を展開しています。
理由は、**小～高等学校の算数・数学の教科書は「類推的な考え方」をベースに作成されていて、この考え方には馴染みがあるためです。**
実際にこれをベースにしたことで理解ができていると受講後の理解度チェックや講義中の受講者の質問から感じています。

もちろん、他の考え方を用いています。
それは別の機会にします。

## 3.おわりに
今回は実際に講義をしていて、気づいたこと、私が教えるときに大事にしていることをまとめました。
教える仕事は常に受講者から学ぶことが多く、私が気づかなかった視点をくれることに感謝しています。
継続的にこれは投稿していこうかなと思っています。
SSH接続してみよう

# SSH接続してみよう
SSHしてみる

## sshコマンド
~~~
PC C:\Users> ssh
~~~
ssh叩いてみてエラーが出たら入れよう。調べて。最近のWindowsは標準で入ってるらしい
~~~
PC C:\Users> ssh
usage: ssh [-46AaCfGgKkMNnqsTtVvXxYy] [-B bind_interface] [-b bind_address]
           [-c cipher_spec] [-D [bind_address:]port] [-E log_file]
           [-e escape_char] [-F configfile] [-I pkcs11] [-i identity_file]
           [-J destination] [-L address] [-l login_name] [-m mac_spec]
           [-O ctl_cmd] [-o option] [-P tag] [-p port] [-Q query_option]
           [-R address] [-S ctl_path] [-W host:port] [-w local_tun[:remote_tun]]
           destination [command [argument ...]]
~~~
これはOKな例

~~~
ssh [ホスト名]@[IPアドレス]
~~~
でアクセスできます。

## SSHのポート
デフォルトは22番ポートですが変えておくとセキュリティ的にGOODです。
【TIPS】Elixirでループのbreak

この記事は、[Elixir Advent Calendar 2023 シリーズ14](https://qiita.com/advent-calendar/2023/elixir) の20日目です

---

【本コラムは、5分で読め、2分で試せます】

[piacere](https://twitter.com/piacere_ex) です、ご覧いただいてありがとございます :bow:

Elixirの `Enum` モジュールって、データ処理をスマートに書ける、Elixirの強力な標準ライブラリなのですが、他言語における `break` のようなことをするのに悩むことありませんか？

実は、2通りの方法で `break` が可能なこと、ご存知ですか？ … 今回、それをTIPSとしてまとめておきました

# 小さなデータ向けの `break`

1～100をループする処理が、5番目で `break` されていることがお分かりかと思います

```elixir
1..10
|> Enum.reduce_while([], fn i, acc ->
    if i == 5 do
      {:halt, acc}
    else
      {:cont, acc ++ [i]}
    end
  end)
|> Enum.to_list
```

```elixir:結果
[1, 2, 3, 4]
```

# 巨大なデータ向けの `break`

`Stream` モジュールを使うと、データ全体を読み込まずに実行対象のみ評価するので、巨大なデータの前半で `break` するときは、`Enum.reduce_while` よりも有利になります

```elixir
1..100000000000
|> Stream.transform(0, fn i, acc ->
    if i == 5 do
      {:halt, acc}
    else
      {[i], acc + i}
    end
  end)
|> Enum.to_list
```

```elixir:結果
[1, 2, 3, 4]
```

# p.s.

ぶっちゃけ、この7年のプロダクション開発で、`break` を求められたシーンって無かったから、地味に競プロでしか使わないのでわｗ :sweat_smile: 

ビッグデータで単純なフィルタリングする際は、DB側で処理しちゃいますしね

ちな、私は下記で使いました … 「ズンドコキヨシ」問題なので、やはりプロダクション開発では無いですね

https://qiita.com/piacerex/items/4670f59d9f6d601fe2a8
2023 Japan AWS Jr. Championsになってからを振り返る

## この記事を書こうと考えた背景
Japan AWS Jr.Championsに選出して頂いてからはや8ヶ月、社内外問わず様々なイベントに参加してきました。その中で自分が感じたことや考えたこと、今後どうしていきたいのかを文章として残しておきたいなと考えた次第です。

## 選ばれた直後の話
自分の好きな漫画の一つに「湾岸ミッドナイト」という作品があり、
その第18巻 P.56にこのようなセリフがあります。

![ガソリン.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3425323/8c9b2152-d684-d26b-8576-a4ed5eb0f5d4.jpeg)

> 昔からよく言うだろクルマ好きの2つのタイプ
> 血液にガソリンが流れてるタイプとオイルが流れてるタイプ---
> つまり走り系とイジリ系てトコか

エンジニアについても同じようなことが言えると思います。

> **①技術対する深い知見を持つことが好きなエンジニア**
> **②技術を使って新しいことを始めるのが好きなエンジニア**

大雑把ですが、上記2つのタイプに大別できると考えています。
今回の話では、前者が「オイル」で後者が「ガソリン」となります。

Jr.Championsに選出された方の中には①と②を両立できている超人のような方もいれば、
一方に特化しているつよつよエンジニアもいらっしゃいます。

正直な話をしてしまうと初めて顔を合わせた時に 
**「同い年でこんなすごい人いるんだ…本当に自分はここにいていいのか？」** 
と思っていた時期がありました。

せっかくJr.Championsになったのに大した結果を出さずに終わるのはとにかくもったいないと思い、 **「この人達と戦える武器をどうやって作るか」** ということを次第に考えるようになりました。

## 手応えから確信へ
きっかけは些細なことでした。新人向けイベントに登壇した際のフィードバックを受けた時です。

> ・今まで聞いてきたイベントの中でもかなり記憶に残るような発表だった。
> ・観客を巻き込んで話すのが非常に上手で、思わず聞き入ってしまった。

正直意外なフィードバックだなと感じたのを覚えています。

確かに今まで発表を褒めてもらうことは何度かあったのですが、
なぜ評価されているかまでは深く考えていませんでしたし、言語化もしていませんでした。

ただ、そんな時にもらったフィードバックが初めて手応えを与えてくれました。

その後、勉強会・インターンなど様々なシーンで登壇し反応を確かめる作業を繰り返しました。
結果的にあの時感じた手応えは間違っておらず、それは徐々に確信に変わりました。

最終的に「エモーショナルと論理性を両立させながら発表する」能力が人よりも高いという結論に至りました。

## 今後どうしていきたいのか

自分は「ガソリン」側のエンジニアで、それは変わらないと思っています。
ただ、今後は人に技術の面白さ・楽しさを伝える方にシフトしていきたいなと考えています。

具体的には社内外のコミュニティ活動がそれに当たるのではないかと考えていて、
来年以降はそこに精を出していこうと思っております。

いつか「AWS Community Builders」の称号を手にいれることを目指して努力していきます。

### あとがき

> 「この熱狂を、外へ」

話は少し変わるのですが、多くの方に愛されているコンテンツにはこの言葉を体現している方が多いように感じます。過去自分もこのような方に助けていただきながら様々なイベントに参加させて頂き非常に嬉しかったのを覚えています。

今度は自分がその役目を務められるようになれたらいいなと考えています。
ノーリスクなことから始めてみたら仕事が楽しくなった

:::note info
この記事は「[Infocom Advent Calendar 2023](https://qiita.com/advent-calendar/2023/infocom)」カレンダーの20日目の記事です
:::
コロナ禍で入社した私は、今年初めて社外のオフラインカンファレンスに参加してみました。もちろんそこでは登壇者の発表を聞くのですが、登壇者はすごく楽しそうで生き生きしていて、参加者・ブースの方たちも活気にあふれていたことがすごく印象的でした。何百人もの同じ興味を持つ人々が集う場なので、「何か」が起こりそうな気がするのがリアルイベントのワクワクなのでしょうね。

常日頃から継続的に学習・発信している方ってほんとにすごいなぁと感心します。めちゃくちゃ尊敬します。

、、、え、私は？私は今、力を振り絞ってこの記事を書いているところです。

ただ、冒頭のカンファレンスへの参加をきっかけに、小さなことでも良いから自分でも何か行動を起こしたい！と考え、まずは時間もお金もさほどかからない（0ではないです）ノーリスクなことから始めてみました。

これらの行動を1年間継続したことで、少しずつですが自分の中の普通のレベルが上がっていくのを感じ、仕事が楽しくなりました。

## 社内チャットにリアクションする

これは私の中で最強のノーリスク行動です。ノーリスクなのにやらない人が多いのが勿体無い。。。誰も反応しない社内チャットは本当に悲しいです。（もしかしたらそれが普通の景色かもしれません）。いろんな人がいろんなリアクションを付けているチームは、心理的安全性が高くチームの結束力が強く感じます。

なぜでしょうか？

リアルで行うコミュニケーションが文字だけになるとかなりの情報がそぎ落とされます。（これはリアル会議とオンライン会議でも同じですよね。）チャットで、メールでのフォーマルな言葉遣いがそのまま適用されてしまうと、堅苦しい印象だったり、怒ってる印象だったりを与えやすいです。特に若手が配属されている部署でそのような環境だと、若手が発言しにくくなり、チームの一員になれていない、大切にされていないなど、マイナスな感覚を抱いてしまうのも無理はないです。

まずは、「見ましたよ」の意で「:thumbsup:」を付けてみることをオススメします。
5秒でチームの雰囲気が変わる可能性があるのです。ノーリスクハイリターン。

## 本を買う

これまであまり読書をしてこなかった人間ですが、この1年で本を読むのが趣味になりました。最初は和田卓人さん（@t_wada）の講演で参照されていた「[LeanとDevOpsの科学](https://amzn.asia/d/bFsZ0O1)」です。もともとDevOpsには興味がありましたが、和田さんが参照しているし間違いないだろうから買ってみるか～という軽いノリでした。

あまり読書をしてこなかった身としては、本を読み進めるには少しパワーが必要でした。

ただ、最後まで読む必要はないのです。見えるところに積んでおくだけで、そこから発せられる非科学的な「何か」が、あなたのモチベーションを高めてくれます。

あとこれは余談ですが、オンライン会議の背景に写る本棚にぎっしり本が並んでいるのってカッコいい。（「それについてはこの本がオススメだよ」なんて言ってみたい。）

読んだ本の感想は別途記事にしたいと思います。

## SNSでエンジニアアカウントを作る

これも今年から始めました。冒頭で話したカンファレンスの昼食中に隣の方と会話した際に「何かSNSとかやってます？」と聞かれたことがきっかけでエンジニア用のアカウントを作りました。（事後なので、その時の方とは繋がれず、、）

まずは手あたり次第、講演で話していた方や、社内で話題に上がった方をフォローしていきます。そのような方たちは常に何かを発信している方ばかりなので、毎日新しい発見や考えていることなどを目にすることができます。生活の中にエンジニアの呟きが入ってくるイメージです。

「常に最新の情報をキャッチアップしよう、話題の技術を調べてみよう」など頑張る必要は無いです。自分の代わりに、誰かが学んだことをポストしてくれるので、ありがたく見せてもらいましょう。シャワーのように情報を浴びることができます。

そして「🧡」を押すのです。

## 社外のリアルイベントに参加する

冒頭で話したカンファレンスは、Findyさん主催の「[開発生産性Conference](https://dev-productivity-con.findy-code.io/)」でした。大げさですが、このイベントは私のエンジニア人生の大きな転機になったと思います。

「今までの俺は井の中の蛙だった」と強く感じました。

社内にとどまっていると、社内の基準に確証バイアスがかかり、それが正しいと思いこんでしまいます（言い方を悪くすると洗脳状態）。社外のイベントに参加することでこの洗脳を解いてくれます。正しいと思っていたことが正しくなかったり、逆にイマイチだなと思っていたことがそうでもなかったり。自身の環境を俯瞰して考えるきっかけを与えてくれるので、いろんな発見があります。

そして自分のチームにどう還元できるか考えるのです。

[connpass](https://connpass.com/)でさまざまなイベントが開催されているので、興味があるイベントを探してみてください。

開発生産性やDevOpsなどが興味のある方は、[Findyさん主催のイベント](https://findy.connpass.com/)がオススメです。

## まとめ

私が実践しているノーリスクな行動をまとめてみました。これらは一度きりでは大きな変化はもたらしませんが、継続することで、ある時ふと振り返ったときに、自分の「普通」のレベルが上がっていることに気づくと思います。

私がこの記事を投稿できたのも、周りの積まれた本たちの「何か」のおかげかもしれませんね。
ダイソーで買ったスイッチ付Type-Aケーブルを手持ちのアイテムと組み合わせて試す【完走賞ゲット-21】

:::note info
※ [Qiita の完走賞をゲットするための条件は「単一／複数のカレンダーに投稿した記事が合計25」です](https://twitter.com/Qiita/status/1593441648796524545)
:::

この記事は、「[完走賞ゲットのため小ネタ 25記事を投稿しようとチャレンジ v2 Advent Calendar 2023](https://qiita.com/advent-calendar/2023/youtoy)」の 21日目の記事です。

## 今回の内容
今回の内容は、以下のポストの写真右上にある「USB接続の人感センサーケーブル」に関する内容です。

https://twitter.com/youtoy/status/1736543676279742679

以下の記事で書いた「USB接続の人感センサーケーブル」の隣に置かれていて、合わせて 1つ買ってみていたものでした。

●ダイソーで買った USB接続の人感センサーケーブルを軽く試してみる【完走賞ゲット-19】 - Qiita
　https://qiita.com/youtoy/items/2daf4ce37a1bfe498286

X のポストで情報を見かけて気になっていた品でもあったので、まずは 1つ買ったのですが、その後にもう 1つ買い足しました（USB接続の人感センサーケーブルのほうは 3つも買い足したのですが 笑）。

https://twitter.com/youtoy/status/1736593815597953089

## 使ってみた事例 2つ
それでは、自宅にあったアイテム 2つと組み合わせてみた事例を、それぞれ紹介してみます。

### ON/OFF する仕組みがない USB給電の LEDテープ
1つはこちらの「ON/OFF する仕組みがない USB給電の LEDテープ」との組み合わせです。
スイッチ付Type-Aケーブルと組み合わせることで、手動で ON/OFF ができるようになりました。

<iframe width="560" height="315" src="https://www.youtube.com/embed/-b9uiUPaML8?si=jRd8MN4s2rHBWKSM" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen></iframe>

例えば何かの展示用に、ずっと点灯し続ける用途なら不要かもしれないですが、自宅で ON/OFF ができるようにして使いたいという場合は、安価に手動 ON/OFF の機能をつけられて便利です。

以前も、機能が同じ似た製品があったと思いますが、それがダイソーで手軽かつ安価にゲットできるのは良いかな、と思いました。

1つ注意点があり、USB給電が「5V/1Aまで」のもので使うようにと書かれていました。
自分が今回組み合わせた USB給電の LEDテープは、5V/1Aちょうどで動作する長さ（LED の個数）のものを買っていたので、そのまま使うことができました。

### ノートパソコン冷却台
次は、自宅で使っているノートパソコン冷却台との組み合わせです。

この製品は、冷却用のファンがついていて、そのファンの ON/OFF　がスライド式のスイッチで行えます。
しかし、その ON/OFF に使うスイッチが背面にあって、そこに手を伸ばして操作するのが地味に面倒でした。

それを、以下のように給電部分で ON/OFF できるようにしました（製品についているスライド式のスイッチは常に ON にした状態）。

https://twitter.com/youtoy/status/1737052111819710520

ON/OFF用のスイッチが、手に届く範囲にきた形になり、とても便利になりました。

## おわりに
今回は、ダイソーで買ったスイッチ付Type-Aケーブルを手持ちのアイテム 2つと組み合わせてみた話を書きました。

ひとまず試してみたのは上記の 2つでしたが、他にも便利そうな事例があると思うので、引き続き活用してみようと思います（そんな事例がいくつか出てきたら、また買い足してしまいそうです 笑）。
Ubuntu22.04でROS 2をビルドするときにlibssl.so.1.1がないと怒られた話

# libssl.so.1.1がない...?

環境
ubuntu 22.04
ROS 2 humble

において、ROSをビルドする際に出会ったエラーについてです。

> /usr/local/bin/cmake: error while loading shared libraries: libssl.so.1.1: cannot open shared object file: No such file or directory

というエラーが出ました。
<blockquote class="twitter-tweet"><p lang="ja" dir="ltr">ubuntu22.04でros2のrealsense-rosをビルドするときに<a href="https://t.co/oJAB1zuy3C">https://t.co/oJAB1zuy3C</a>.1.1 がないと言われる感じです<br>多分realsense関係ないです</p>&mdash; basalte(ばざると) (@basalte1199) <a href="https://twitter.com/basalte1199/status/1737076603799421302?ref_src=twsrc%5Etfw">December 19, 2023</a></blockquote> <script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script> 

# やったこと(うまく行かなかった)
解決方法は下にあります。適宜飛ばしてください。

https://note.com/onaonakinkin/n/n3fb818027d2b

このリンクを参考にopenssl自体をインストールし直します。

`openssl version` ---> 3.0

以下のリンクから古めのopensslをダウンロード
https://www.openssl.org/source/

`tar -xf <ダウンロードしたファイル名>`
`cd <展開されたディレクトリ名>`
`sudo apt install build-essential`
`./config`
`make`
`sudo make install`

これにより、opensslのバージョンは1.1.1fになりましたが、求められていたものと違ったようで結果はかわりませんでした。(知識不足のためうまく言っていない理由がわからないです。補足あればお願いします)




# 解決方法

<blockquote class="twitter-tweet"><p lang="ja" dir="ltr">Ubuntu 22.04で同じ問題に遭遇したことないので直るかわかりませんがこちらが参考になりそうです。<a href="https://t.co/umROL39xR5">https://t.co/umROL39xR5</a><a href="https://t.co/pEytxou1mG">https://t.co/pEytxou1mG</a><a href="https://t.co/LmrZN9yyUM">https://t.co/LmrZN9yyUM</a></p>&mdash; dandelion (@dandelion1124) <a href="https://twitter.com/dandelion1124/status/1737082150409879761?ref_src=twsrc%5Etfw">December 19, 2023</a></blockquote> <script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script> 

このような助言をいただき、
https://stackoverflow.com/questions/72133316/libssl-so-1-1-cannot-open-shared-object-file-no-such-file-or-directory

このリンクの回答を参考に、

http://nz2.archive.ubuntu.com/ubuntu/pool/main/o/openssl/

このリンクの中から自分の環境にあったバージョンのlibssl.so.1.1を見つけてインストールします。
以下自分の環境の場合に治った手順です。

`wget http://nz2.archive.ubuntu.com/ubuntu/pool/main/o/openssl/libssl1.1-udeb_1.1.1f-1ubuntu2.20_amd64.udeb`
`sudo dpkg -i libssl1.1_1.1.1f-1ubuntu2.20_amd64.deb`


<blockquote class="twitter-tweet"><p lang="ja" dir="ltr">正常にビルドできました！ <a href="https://t.co/FlPMoK437b">pic.twitter.com/FlPMoK437b</a></p>&mdash; basalte(ばざると) (@basalte1199) <a href="https://twitter.com/basalte1199/status/1737090003963134218?ref_src=twsrc%5Etfw">December 19, 2023</a></blockquote> <script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script> 

はい。これでうまく行きました。めでたしめでたし。

同じ問題にハマった方の助けになれば幸いです。
次は3DSLAMをやってみたいです！(沼の予感が...)
【Go言語】メモリ起因のパフォーマンス低下を解消する

Goでパフォーマンスに差があらわれがちなポイントに**スライスとマップのメモリ確保**がある。
メモリ確保を高速化する方法を説明する。

### スライスのメモリ確保を高速化する
スライスの拡張`append()`は以下のプロセスになっている
1. すでに確保済みのメモリが不足した場合は、OSに要求
1. 確保済みのものから新しい配列用にメモリを割り当て
1. 新しい配列に古い配列の内容をコピー
1. 古い配列にアクセスするスライスや変数がなくなったらメモリを解放

上記のようにメモリ不足が発生するつどOSにメモリ追加の確保を依頼しているので、あらかじめ必要な要素数が分かっている場合はサイズを指定してスライスを宣言するのが望ましい。

#### サンプル
実際にパフォーマンス計測も行った
```go
package main

import (
	"fmt"
	"time"
)

func main() {
	// パフォーマンス計測開始
	start := time.Now()

	// スライスの動的拡張
	dynamicSlice := make([]int, 0)
	for i := 0; i < 1000000000; i++ {
		dynamicSlice = append(dynamicSlice, i)
	}

	// パフォーマンス計測終了
	dynamicDuration := time.Since(start)
	fmt.Println("動的拡張スライスの処理時間:", dynamicDuration)
    // 動的拡張スライスの処理時間: 1m10.7608742s

	// 再度パフォーマンス計測開始
	start = time.Now()

	// スライスの事前確保
	preAllocatedSlice := make([]int, 0, 1000000000)
	for i := 0; i < 1000000000; i++ {
		preAllocatedSlice = append(preAllocatedSlice, i)
	}

	// パフォーマンス計測終了
	preAllocatedDuration := time.Since(start)
	fmt.Println("事前確保スライスの処理時間:", preAllocatedDuration)
     // 事前確保スライスの処理時間: 30.4573957s
}

```


### マップのメモリ確保を高速化する
マップの背後には「バケット」と呼ばれるデータ構造がある。
マップの場合も、事前にメモリを確保することでパフォーマンスが向上します。

#### サンプル
```go
package main

import (
	"fmt"
	"time"
)

func main() {
	// マップの動的確保
	dynamicMap := make(map[int]int)
	start := time.Now()
	for i := 0; i < 100000000; i++ {
		dynamicMap[i] = i
	}
	dynamicDuration := time.Since(start)
	fmt.Println("動的確保マップの処理時間:", dynamicDuration)
	// 動的確保マップの処理時間: 18.3244288s

	// マップの事前確保
	preAllocatedMap := make(map[int]int, 100000000)
	start = time.Now()
	for i := 0; i < 100000000; i++ {
		preAllocatedMap[i] = i
	}
	preAllocatedDuration := time.Since(start)
	fmt.Println("事前確保マップの処理時間:", preAllocatedDuration)
 	// 事前確保マップの処理時間: 12.1498153s
}

```

## 参考
https://www.oreilly.co.jp/books/9784873119694/
【Ruby Gold3.1詰まったシリーズ】includedメソッドについて

# はじめに
今回はincludedに関する内容です。Ruby Goldの試験でincludedに関して自信を持って回答できなかったため、簡単にまとめてみます。

# irbで確認してみた
環境はruby 3.1.4です。
[こちら](https://pikawaka.com/ruby/include)によると、クラスでモジュールがincludeされた際に呼び出されるメソッドらしいです。
実際に、クラスに対してモジュールをincludeし実行
~~~ruby
module Mod
    def self.included(base)
        p "#{base} include #{self}"
    end
end

class Hoge
    include Mod
end
~~~
~~~
irb(main):001* module Mod
irb(main):002*     def self.included(base)
irb(main):003*       p "#{base} include #{self}"
irb(main):004*     end
irb(main):005> end
=> :included
irb(main):006> 
irb(main):007* class Hoge
irb(main):008*     include Mod
irb(main):009> end
"Hoge include Mod"
=> Hoge
~~~
すると、includedメソッドが呼び出されて"Hoge include Mod"が表示されていました。

# おわりに
確認した結果、includedメソッドはクラスでモジュールがincludeされた際に呼び出されるメソッドだということが分かりました。includeされた時に裏でどんなメソッドが関連して動いているのか普段気にすることがあまりなかったので、今回知れて良かったです！誤り等ありましたらご指摘いただけますと助かります！

# 参考
https://pikawaka.com/ruby/include
【SSH】sshコマンドのオプションで生存確認(ServerAliveInterval)の間隔を指定する

# 概要
sshはセキュアシェル（Secure Shell）プロトコルを使ってリモートマシンにログインするためのツール。本記事では、ssh構成ファイル、もしくはsshコマンド実行時のオプションにて、サーバへの生存確認を行う設定について紹介します。

# `ServerAliveInterval`オプションとは
ssh接続をしていると、いつの間にかタイムアウトしていることがあります。そんなタイムアウト（コネクション切れ）を防止する手段として、`ServerAliveInterval`パラメータがあります。

ssh構成ファイルである`/etc/ssh/ssh_config`（もしくは`~/.ssh/config`）に以下のように追記することで、60秒ごとにサーバにメッセージを送り、サーバへの応答を確認してくれます。

```
ServerAliveInterval 60
```

また、`ServerAliveCountMax`というパラメータもあります。
ここでは、サーバから応答を受け取らなかった場合に、クライアントが接続を終了するまでの試行回数を指定できます。

```
ServerAliveCountMax 3
```

上記の場合、クライアントは60秒ごとにサーバに生存確認を送り、サーバからの応答がない場合、最大3回まで再試行を行います。
サーバからの応答が3回続けてない場合、クライアントは諦めて接続を閉じる、という意味になります。


## SSHログインする際にオプション指定できる

上記のことは調べるとすぐに出てきますが、sshコマンドを使用してリモートサーバに接続する際に、オプションとして指定することもできることを知りました。以下で可能です。

```
ssh -i sample_ecs.pem ec2-user@XXXX
```

↓↓↓ 生存確認をオプション指定　↓↓↓

```
ssh -o ServerAliveInterval=120 -i sample_ecs.pem ec2-user@XXXX
```

`-o ServerAliveInterval=120`というオプションを指定することで、SSH接続がアイドル状態になった際に、指定した秒数ごとにサーバに対して生存確認のパケットを送信する間隔を設定できます。
これにより、接続が途切れないように保つことができます。

他にもオプションは色々あります。代表的なものとその説明は以下記事に記載ありました。configファイルについても説明があります。

参考：[~/.ssh/configを使ってSSH接続を楽にする](https://tech-blog.rakus.co.jp/entry/20210512/ssh#%E3%83%91%E3%83%A9%E3%83%A1%E3%83%BC%E3%82%BF%E4%B8%80%E8%A6%A7)

## デフォルト値は？
`ServerAliveInterval`のデフォルト値は`0`で、何も設定をしない場合は応答確認しないようになっています。

また、`ServerAliveCountMax`のデフォルト値は`3`です。クライアントが再試行する最大回数は`3`回になります。
localhost環境でOGPを確認する Facebook, Xに未ログイン可

# はじめに
Open Graph Protocol（OGP）は、ウェブページがソーシャルメディアで共有される際にどのように表示されるかを定義する技術です。このプロトコルを活用することで、共有リンクのタイトル、説明、画像などを自在にコントロールできます。
これにより、ソーシャルメディア上でのクリック率やエンゲージメントを大幅に向上させることが可能です。

https://www.e-webseisaku.com/column/marketing/3947/

# 背景
通常、OGPの確認はウェブサイトが公開された後に行われます。
しかし、開発中のlocalhost環境では外部からアクセスできず、OGPの確認が困難です。
この問題を解決するために、開発中でもOGPを確認できる方法を紹介します。

# ハンズオン
## 環境生成(React, Vue)
まず、ReactやVueなどのフロントエンドフレームワークを使用して、開発環境を構築します。
若干は記述しますが、「React OGP設定」や、「Vue OGP設定」と検索したほうがより詳しく設定できるかと思います。

### React環境の例
#### プロジェクトの作成
```zsh
npx create-react-app {なんでも}
```

#### OGPの設定
public/index.htmlに追記してください。
```react
<meta property="og:title" content="サイトのタイトル" />
<meta property="og:description" content="サイトの説明" />
<meta property="og:image" content="画像のURL" />
<meta property="og:url" content="ウェブサイトのURL" />
```

#### 実行
```zsh
npm start
```

### Vue環境の例
#### プロジェクトの作成
```zsh
npm create vue@latest
```

#### OGPの設定
index.htmlに追記してください。(環境によって調整してください)

```vue
<meta property="og:title" content="サイトのタイトル" />
<meta property="og:description" content="サイトの説明" />
<meta property="og:image" content="画像のURL" />
<meta property="og:url" content="ウェブサイトのURL" />
```
#### 実行
```zsh
npm install
npm run dev
```

## URL発行
### 使用する拡張機能
localhostではOGPを確認することはできないので、Googleの拡張機能を使い、疑似URLのようなものを生成します。

- Localhost Open Graph Debugger

https://chromewebstore.google.com/detail/localhost-open-graph-debu/kckjjmiilgndeaohcljonedmledlnkij

[Localhost OGP チェッカー](https://chromewebstore.google.com/detail/localhost-ogp-%E3%83%81%E3%82%A7%E3%83%83%E3%82%AB%E3%83%BC/gcbnmkhkglonipggglncobhklaegphgn)という有名なツールがあるのですが、生成してくれないことが多くあったので、[Localhost Open Graph Debugger](https://chromewebstore.google.com/detail/localhost-open-graph-debu/kckjjmiilgndeaohcljonedmledlnkij)というツールを使います。
各自でインストールしてください。

### 実践
サイト上で拡張機能を使用してください。

「Open debug page」と出るので、そのままクリックしてください。
![スクリーンショット 2023-12-19 21.44.11.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/433195/29dce35b-9b09-f342-fec0-c4f9cebd96f7.png)

URLが生成されるので、コピーしてください。
![スクリーンショット 2023-12-19 21.44.21.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/433195/86bfe24d-085d-82b7-687d-ce725fb96226.png)





## 一括で確認
### 使用するサイト
X(旧Twitter)や、Facebookにてはデベロッパーツールがあり確認することができますが、ログインしていないと使うことができないので、一括で確認できるサイトを使用します。

- ラッコツールズ

https://rakko.tools/tools/9/

注意 : 開きっぱなしにしておくと確認できなくなるので、ページ更新をしてください。

### 実践
サイトにアクセスし、先程生成したURLを入力すると一括で確認することができます。

![スクリーンショット 2023-12-19 21.54.40.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/433195/bf56c0c6-9fdd-d6a4-c1cb-e9fb9201acce.png)



![スクリーンショット 2023-12-19 21.52.25.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/433195/cf1e45a2-9ef9-2bc2-a600-b18ef01c672f.png)

フリー画像がなくてXのアイコンを使っていますが、ローカルの画像でも確認できます。


# 最後に
OGPはソーシャルメディアでのウェブサイトの印象を大きく左右します。
開発中からこれらのタグを適切に管理し、テストすることで、公開時にスムーズなソーシャルメディア統合を実現できます。
今回紹介したツールと手順を活用して、効果的なOGP設定を行ってください。
やっぱり大事なのは『思いやり』というなの『調整力』

# 本記事について
社会人8年目を迎えるに差し掛かり、今までの個人の経験からの見解となります。
参考になる点、言われなくても知っているよ！っていうことも多々あること、悪しからず。

＜漠然と読んだら、得られることが多そうな対象＞
社会人1年目、2年目とかなんとなく、
* 「上手く立ち回りたいな～。」
* 「何気ない信頼感の得方が知りたいな」
なんて人には参考になるかもです！

## 会社生活で今までやってきたこと
1. THE! 運用業務（いわゆる設定変更などのお仕事）
1. お客さんとの報連相
1. チーム飲みの幹事（メンバー時代・マネージャー時代）
1. 社内ゴルフコンペの幹事・企画

などなど、振り返ると色々やってきました。

### 1. THE! 運用業務（いわゆる設定変更などのお仕事）
* どんなことやってたの？
    * SaaSシステム上の利用上限の開放など数十種類ある運用依頼をさばく！
* 苦労したこと
    * 営業さんが各自各々好きな書き方で依頼が上がるもので、認識齟齬が大変！
    * 毎回変更前後を記載してくれる人、ありがとう！
* 改善に思い立った
    * みんな好き勝手記載するが、やりたいこととしては○○➡△△に変更する（これだけ！）
    * 認識齟齬を生まないようにフローとフォーマットを作成で解決！（社内Wikiの命名は負の遺産に、、、）
* 業務の中での思いやり
    * 戦略的にコミュニケーション取れる機会だと、依頼者に対応開始前後で連絡を入れていた。
* 得られたもの
    * 丁寧な仕事と思われるキッカケ
    * こまめに報連相ができる人認定が生まれる
    * 業務上の何気ない報連相から、話しかけやすくなる

### 2. お客さんとの報連相
* どんなことやってたの？
    * オリジナル開発対応に伴い、お客さんとも毎日電話連絡していた
* 苦労したこと
    * 電話のし過ぎで手が進んでいない悩みもあった
* 得られたこと
    * とはいえ、言葉で会話をしているので安心感と認識齟齬が少なかったと感じる
* オンラインとの良し悪し
    * 電話よりもZOOMなどのWEB会議の方が便利！（画面共有はやはり認識合わせやすい）
    * オフラインの方が圧倒的親近感が湧く
        * Backlogなどのツール上のみでのやり取りも時にはあるが、顔合わせをすることで安心感が湧くことが多い。
* 思いやり
    * 緊急時以外は、休みタイミングの連絡を極力避ける
    * 悪いことこそ早く連絡する

### 3. チーム飲みの幹事（メンバー時代・マネージャー時代）
* どんなことやってたの？
    * 実施したい会の参加者・趣旨に合わせた場所選び
* 気を付けていたこと
    * 周りを気にせず場を盛り上げたいとき：貸し切れるお店をチョイス！
    * アラカルトでもいい場面もあるが、話に集中していきたいためコースをチョイス
    * 予算は事前に上席と相談！
    * 参加者によっては、帰路も視野に入れたチョイス！
* 余談
    * 2次会の企画が必要になる場面もあると思うのであらかじめ2，3件候補を見繕っておく！

### 4. 社内ゴルフコンペの幹事・企画
* どんなことやってたの？
    * はじめは20人ちょっとの規模の幹事
    * 今では80人規模の幹事
* 苦労したこと
    * パーティーできる場所の確保！
    * 予約が3ヶ月前！
    * 参加者集客！
    * 初心者多めの大型コンペ！
    * タイムスケジュールの調整！　（などなど多岐にわたり）
* 気を付けていたこと
    * とにかく参加者が楽しんでもらえること
    * 現地の会場にご迷惑をおかけしないこと
    * 紳士たる振る舞いを教えていくこと
* 思いやり
    * ゴルフは日曜日を●っと使ってしまうため、景品にも一工夫
        * 本人がもらって嬉しいものだけでなく、奥様へのお土産効果も演出
    * 組み合わせの一工夫
        * 普段はなさない人を敢えてくっつけてみたり、密連携したほうが盛り上がりそうなつながり
    * 会場への気遣いとして、進行ルールを独自のローカルルール策定（進行最優先）
    * 進行役として、経験者との連絡網を構築。お尻を叩きまくる

## 総括
とまぁ、色々とイベントごとをやってきましたが、総じて言えることは各回を楽しくする。ないしは、気持ちよく仕事をするためにはコミュニケーション量を増やしていくことが大事です。

新人である人であれば、部署の飲み会などの幹事を引き受けてみるといいでしょう！
小さな企画からの経験が最終的に大きな機会をもらえるきっかけになりますので、是非、お試しあれ！
How-to-Use-Python-in-Docker

target: use Python in container

## make Dockerfile
python-on-docker/Dockerfile
```
FROM ubuntu:22.04

RUN apt update
RUN apt install -y python3.10
RUN apt install -y python3-pip
```
## build Docker image
```
docker build -t python-on-docker .
```
if you mistake building doker image, you can delete it
```
docker rmi [image name]
```
## confirm making Docker image correctly
```
docker images
```
## run Dockerfile
```
docker run -it --shm-size 16g python-on-docker
```
<details>
<summary>
if you want to use GPU, run this command instead.
</summary>

```
docker run -it --gpus all --shm-size 16g python-on-docker
```

</details>

## Python
```
python3
quit()
```
<details>
<summary>
GPU
</summary>

```
python3
import torch
torch.cuda.device_count()
quit()
```

</details>

## copy file
if you want to copy file from container outside.
```
docker cp path-to-file [CONTAINER-ID]:/abs/dir 
```
if you want to copy file for container outside.
```
docker cp [CONTAINER-ID]:/abs-file-path to-file-dir
```
机の上にUnityChan

# ARマーカーの上にUnityChanを表示させてみた
![Screenshot from 2023-12-19 18-37-07.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2320370/7f3f6eee-1061-2945-6e08-73940b0b7283.png)

OpenCVのChARUcoを使うと，簡単にマーカーの位置姿勢を推定することができます．
今回はこれを使って，位置が推定されたマーカーの上にUnityChanを表示させるプログラムを作ってみました．

テクスチャを張り付けたメッシュを画面に表示させるため、自分でOpenGLのシェーダーを書いて、表示させました。ライティングは特に考えていません。単にテクスチャを貼っただけです。

この記事ではOpenCVとOpenGLの連携にかかわることに絞って書いていきます。連携さえできればあとはOpenGLのプログラミングになるので、その辺はlearn openglなどを見ていただければいいんじゃないかなと思います。

なお、Mesh fileの読み込みなどは、Assimpを使用しました。クロスプラットフォームで使用でき、いろいろな形式の3Dモデルを読み込むことができます。

https://github.com/assimp/assimp
# ソースコード
https://github.com/GodRyosuke/opencv_ar_object

# cv::MatをOpenGLのtextureにする
こちらの記事を参考にさせていただきました。

https://stmind.hatenablog.com/entry/2014/03/14/024333

以下のコードでは、cv::Matの画像からOpenGLのテクスチャを作成しています。"texture_data"が作られたやつです。
```c++
	cv::Mat src_img = src_img_data.clone();
	cv::flip(src_img, src_img, 0);
	cv::cvtColor(src_img, src_img, cv::COLOR_BGR2RGB);
	
	glGenTextures(1, &texture_data);
	glActiveTexture(GL_TEXTURE0);
	glBindTexture(GL_TEXTURE_2D, texture_data);

	glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR);
	glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR);
	glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP_TO_EDGE);
	glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_CLAMP_TO_EDGE);

	width = src_img.cols;
	height = src_img.rows;
	glTexImage2D(GL_TEXTURE_2D, 0, GL_RGB, src_img.cols, src_img.rows, 0, GL_RGB, GL_UNSIGNED_BYTE, src_img.data);
	// Generates MipMaps
	glGenerateMipmap(GL_TEXTURE_2D);
	glBindTexture(texture_data, 0);		// unbind
 ```

 # カメラの内部パラメータを踏まえた投影行列
 こちらの記事を参考にさせていただきました。

 https://qiita.com/maiueo/items/7c0c039a92102c7b7fe8

まず、何らかの方法で使用するカメラの内部パラメータを取得します。ここではcv::calibrateCamera()を使用しました。そのパラメータを以下の変数に格納します。
 ```c++
    cv::Mat cameraMat = (cv::Mat_<double>(3,3) << 852.8839555848483, 0, 639.5, 0, 852.215118770151, 359.5, 0, 0, 1);
    cv::Mat distCoeffs = (cv::Mat_<double>(1,5) << 0.08005910250868746, -0.3113160415419927, 0, 0, 0.196456176823346);
```
投影行列は次のようになります。上のQiitaの記事で書かれていた行列をそのままプログラムに落とし込んだ形になります。
```c++
        glm::vec2 screenSize(848, 480);
        const double nearP = 0.1f;
        const double farP = 200;
        glm::mat4 camProj = glm::mat4(
            2*cameraMat.at<double>(0, 0)/screenSize.x, 0.0, 0.0, 0.0,
            0.0, 2.0*cameraMat.at<double>(1, 1)/screenSize.y, 0.0, 0.0,
            -2*cameraMat.at<double>(0, 2)/screenSize.x + 1, 2.0*cameraMat.at<double>(1, 2)/screenSize.y - 1,  -(farP + nearP)/(farP - nearP), -1.0,
            0.0, 0.0, -2*farP*nearP/(farP - nearP), 0.0
        );
```
 OpenCVでは、カメラのz軸が撮影方向、y軸が下、x軸が撮影方向に対して右向きとなっているので、View行列は次のようになります。
 ```c++
        glm::mat4 camView = glm::lookAt(glm::vec3(0.f), glm::vec3(0.f, 0.f, 1.f), glm::vec3(0.f, -1.f, 0.f));
```
+z方向を見て、-yが上ベクトルとなっています。
なので、頂点シェーダーでは次のような雰囲気のコードになります。
```glsl
gl_Position = camProj * camView * ModelTransform * vec4(Position, 1.0);
```

 # 参考文献
 OGLdev https://ogldev.org/
 UnityChan https://unity-chan.com/
木こりのジレンマにまんまとハマった話と対策方法

Ateam LifeDesign Advent Calendar 2023 19日目を担当する田中です
本日は僕の実体験「木こりのジレンマ」にハマった話＆自分なりの対策方法を紹介します。

## 木こりのジレンマとは？
> ある日の朝、旅人は山の中を歩いていました。
奥深い森の中、汗を流しながら一生懸命に木を伐っているきこりを見かけました。
そして夕方、同じ道を戻ってみると・・・、朝と同じ場所で、玉の汗をかきながら一生懸命木を伐り続けているきこりがいました。
でも、あんまり作業は進んでいないようでした。
旅人は足を止めてよくよく見ると、きこりが使っている斧の刃は、ボロボロでした。
そこで、きこりに声をかけました。
旅人：「きこりさん、精がでますなぁ。でもあんまり作業は進んでないみたいですね、一旦手を止めて、斧の刃を研いだらどうですか？」
きこり：「旅人さんよ、なに言ってるんだよ、刃を研ぐ時間なんておいらには無いんだよ、木を伐るのが忙しくてさ・・・。」

引用：[一般社団法人日本経営コーチ協会](http://www.keieicoach.jp/news/418/)

ビジネスでもたまに使われる話で、目の前の業務に忙殺されて自身の成長のための時間や乱雑な情報の整理などに時間を使えないことの例え話として利用されます。

今回は、この木こりのジレンマを例に「自分の斧を研ぐことの重要性」と「ジレンマにハマったときの僕なりの対処法」を紹介します。

## 斧を研ぐことの重要性
斧を研ぐことの重要性を考えるため、下記2パターンの人の行動を比較してみましょう。
①刃を研がずに眼の前の木を伐る人
②刃を研いでから木を伐り始めた人

ここからは上記それぞれの人を①と②として表現します。

### 条件
・両者の斧の初期値を50（最大値100）とします。
・100になると木が1本切れるとします。
　・例えば、初期値50の斧で2日間伐り続けると1本の木が切れます。
・1年間（365日）毎日木を伐り続けるとします。
・斧研ぎを1日すると斧の初期値が＋1になるとします。

### 計算
①の人が1年間木を伐り続けた場合
（50（斧の初期値）✕365日）÷100＝183本（四捨五入）
①の人は、1年間で183本の木を伐ることができます。

②の人が1ヶ月斧を研いでから木を伐り続けた場合
（50＋30）✕（365−30）÷100＝268本
②の人は、1年間で268本の木を伐ることができます。

### 結果
②の最初の1ヶ月を斧研ぎに費やした人のほうが、
②−①＝85本　も多く木を伐れる事がわかりました。

あくまでも1年で計算をしていきましたが、②が定期的に斧を研ぎ続けながら5年10年と時間が過ぎていくと指数関数的に差が開いていくことがわかります。

計算をしてみると至極当たり前のことのように感じますが、実際に業務が切迫すると余裕がなくなり自分で気づいたときには「木こり」と同じ状況になっていました。

まんまとハマっている自分が悔しく、対策方法を考えてみました。
今はその方法を使いながら、木こりにならないように意識をしています。

## 木こりのジレンマに対する対策方法
僕は対策方法として大きく2つのことを意識しています。
1.自分が「木こり」になっているということを認識する
2.認識したら反射的になにかの”アクション”を起こす

### 自分が「木こり」になっているということを認識する
まず大事なのは、自分が「木こり」の状態になっていることを認識することです。

例えば、業務をするなかでなにかに”悩んでいる”とします。
悩んでもやもやした頭のまま業務をすることは、斧の切れ味が悪い状態と一緒の状態です。

では、悩んでいることを認識するにはどうすればいいのでしょうか。
僕は自分が悩んでいることに気付く方法は、「5分以上考えても何も出てこない場合」と決めています。
[5分で出した結論は5日考えたものと変わらない](https://president.jp/articles/-/75918)という結果もあるほどです。

そのため、僕は”5分”という時間で自分が”悩んでいるか否か”の認識を反射的に行うようにしています。
うまくできないこともありますが、まずはこの意識を強く持つようにしています。

### 認識したら反射的になにかの”アクション”を起こす
認識ができたら、認識をした瞬間に反射的に次の”アクション”を起こすようにします。

ここで重要なのは、アクションをかなり簡単な動作にすることです。
・机から立ち上がる
・ボールペンを持つ
・深呼吸をする　 などでしょうか。

最初から難しいアクションにしてしまうと、反射的にアクションを起こすことが難しくなり、僕は続かなくなってしまいました。

第1のアクションが取れたら、次のアクションに進みます。
例えば「ボールペンを持つ」を最初のアクションにした場合の行動を書いてみましょう。
1．悩んだらボールペンを持つ
2．今考えたいことと悩んでいることを紙に書く
3．2の差分（悩みのタネ）を紙に書く
4．悩みのタネを自覚する
5．改善方法を考える
まで落とし込めると、Doが大きく進みます。

「悩んだらボールペンを持つ」をすっとばしてできる人もいるかも知れませんが、僕は誰でもできるような簡単なアクションを最初に置くことでアクションに対するハードルを下げています。

これが認識と自分なりの対処法（アクション）です。

## 最後に
かくいう自分もまだまだ上手くできないことも多くあります。

目先の成果だけでなく、長い目で見たときに「斧の切れ味を上げておくこと」はとても重要で大きな意味を持ちます。
忙しいときこそ、落ち着いて整理をすることで早く進められることもあるので、ぜひ1度やってみてください。
エンジニアの為ではないけどエンジニアの為になる技術広報とは

IT企業の皆様、自社のPR・広報に悩んでませんか？
そんな仕事に直接は関係ないエンジニアの皆様も、自分たちの面白さが伝わらず、楽しくなくなっていませんか？（せめてもとQiitaアドカレに必死に吐き出してませんか？）
処方箋となり得る"技術広報"をご存知ですか？

:::note info
※この記事はNTTコムウェア Advent Calendar 2023 25日目の記事です。
メリークリスマス https://qiita.com/advent-calendar/2023/nttcomware
:::
NTTコムウェアのKoDAMAと申します。スクラムマスターや巨大システム開発のエンジニアから、広報や最近は生成AI利用促進など色々やってきた中堅サラリーマンです。
エンジニアと技術広報を結びつけたく本記事を書きました。

さて、技術広報とはその名の通り技術、エンジニアを起点とした広報とも言えます。
この技術広報は一般の企業広報と何が違うのか？ただの技術のプロモーションなのか？
もちろん違います。
それではまず、技術広報の主な目的と施策から説明します。
### １．技術広報が行われる目的は大きく2つ
**◆採用**
<font color="00B6AB">技術広報は"経験者採用"の側面から多くは行われます。</font>
新卒も経験者もエンジニアの採用は難易度が増しています。待遇以外にも、エンジニアは同じような仲間と思いを分かち合える組織に惹かれます。
こんな技術者の居る会社、こんな風に技術者が情報発信する会社、
**"居心地が良さそう"** というイメージは大きなPRになります。

**◆マーケティング**
<font color="00B6AB">技術広報は"サービス・プロダクトのマーケティング"の側面からも多くは行われます。</font>
サービス・プロダクトの認知を広めるのは一筋縄ではいきません。直接PRする以外にも、違う角度からPRする手段になり得ます。
こんな面白い技術が使われているなら、こんな技術者が支えるサービスなら、
**"今後も更に期待できそう"** というイメージも大きなPRになります。

当然どちらも結果的には、企業PRにもつながります。
### ２．技術広報の施策も大きく2つ
**◆イベントやコミュニティ支援**
エンジニア向け主催イベントから、有識者のイベント登壇、やっぱり人が話せば伝わります。
分かりやすいものでは、AWSやGoogleもエンジニア向けイベントを全体のイベントとは別に行っていますよね。
connpassなどのイベント管理サービス上にも沢山のイベント開催情報があります。
更にはこれらイベントを行える技術者コミュニティ、カンファレンスへの支援・協賛も含まれるでしょう。
**◆ブログや記事のWeb制作**
ある種の技術や手順を検索すると出てきやすい[クラスメソッドさん](https://dev.classmethod.jp/)を始め、技術ブログを多数Web公開している企業もあります。このようなQiitaのアドカレへの参加にしても、エンジニアにとっても会社の資料ではなくインターネット向けにアウトプットするのも大事ですよね。
記事広告でもエンジニアへのインタビューなどもこれにあたるでしょう。

### ３．企業の広報ともサービスの宣伝とも異なる営み、どうやって始めるか？
目的も施策も調べればもっと色々な情報は出てきます。しかし、どうすれば始められるのでしょうか？
実は技術広報は始めるための壁、継続のための壁が存在します。
この壁があるために、広く行われていないと私は思っています。
**壁１**
どこの誰がやるべきなのか？１で述べた目的に紐づけると採用とマーケではKPIが全く異なる物になります。ただでさえ悩ましい広報のKPI設定、ここが難しい壁①です。
個人的な私見ですが、企業の色合いにもよりますが採用との方が紐づけやすい印象があります。採用目的に見える技術広報の方が継続されている印象もあります。（そう見えているだけで実際に各技術広報さんに聞いたわけではありません）
IT業界、特に専門分野を持ったエンジニアの人手不足が進むいま、こうした差別化から始めるのも有益な選択肢になるでしょう。
（IT知識を世の中に提供する企業の社会的貢献の座組も考えられますが、尚更KPIが設けにくいので除外しました）
**壁２**
壁①を乗り越え技術広報を始める座組を設けられたとしても、継続するための難しい壁②があります。
もしも、技術に愛があり、エンジニアに気持ちよく協力して貰う事ができて、かつ広報・マーケティング的なスキルもあるAさんが技術広報を担当したとしましょう。その場合はAさんが異動や転職すると継続できなくなります。技術広報が立ち消えがちな要因の１つです。
このような事態を防ぐためにも、技術広報の理想的な姿はエンジニア側のコミュニティ的な輪がエンジンとなり、Aさんは入れ変わっても成立する状態だと言えるでしょう。
エンジニアは技術愛の無い依頼が嫌いです（私自身調べ）技術広報に関する業務がただの作業にならないように、コミュニティで愛を補完しあえる状態は1つの理想郷になるでしょう。

### ４．まずできること
ここまで大枠を述べてきましたが、さて、エンジニアの人は何ができるのでしょうか？
それは**協力**です。登壇したり記事を書いたりするのは上述のAさんではなく、エンジニアです。技術広報に関わる時間を絞り出して、技術を提供する。
どんな施策を行うにしても、見せ方や段取りは上述Aさんのような技術広報担当者が支えてくれます。
エンジニアの技術への愛を見せつけるだけでいいのです。
リアルに人前に出るのは躊躇する方もWeb上に是非何かを出してみて下さい。インターネット上に出て人に認められるのは、悪い気持ちではないはずですし、そもそもインターネットは集合知のツールだったはずです。

### ５．まとめ。エンジニアの為になる技術広報。
技術広報ポエムを何故私は突然Qiitaに書いたのか？
それは、技術広報でスポットライトを浴びたり、組織が面白くなったり、利点を得るのが（そのために実際に頑張るのも）まさにQiitaのアドカレに投稿するようなエンジニアの人たちだと思うからです。
多くの会社で技術広報に関わる人が増えれば、ITがもっと世の中に伝わりやすくなるはず、そしたらもう少し私たち、ITが好きでたまらない(ITリテラシーが低いニュースを見ると悲しくなる)人たちにとっても、過ごしやすい幸せな世界になるのではないでしょうか。
明確に技術広報の旗印でなくても、そんな色のする企画には、ちょっと面倒でもぜひ協力してください。
それでは、また。

※記載されている会社名、製品名、サービス名は、各社の商標または登録商標です。
ディレクター歴10+n年が考える 受託案件のおもしろさ

制作のディレクターをしているきたざわです。
早いものでもう年末…、そして早いもので私自身の社会人歴が10+n年になりました。

私はずっとディレクターをやってきて、受託ばかりやってきている人間です。
受託開発会社はよく事業会社と比較されることがあり、エンジニアの世界だと事業会社が人気だったりするみたいですが、デザイナーやディレクターにとっては受託のお仕事は魅力的であると感じている方も多いのではないかなと思います。

私自身、昔から受託案件をやってきていますが、ZYYXに入社してからさらに「受託案件おもしろい」と感じています。
今回はそんな私が「受託案件っておもしろい」と感じる点についてお話ししたいと思います。


## ざっくりとした自分の経歴
今まで3社ほど渡りあるいてきました。

1社目は小さなWeb制作会社。
不動産関係のお仕事がメインで、ディレクターしかいない会社。実制作は外部パートナーさん。

2社目は地方の開発会社。
コンピュータサイエンスの学科がある某大学の近くにあったため、エンジニアがたくさんいる会社に制作メンバー数名。ディレクターでしたがデザインやコーディングも担当していました。

3社目は現職(ZYYX)。
ディレクターとして提案、情報設計、UI設計、進行管理などなど多岐に渡る業務に関わっています。

転職をするたびに会社の規模は少しずつ大きくなっていて、関わる職種や人や業種が多くなり、できることの幅が広がってるので、だからこそより「受託面白い」と感じるのかもしれません。

## 受託案件が面白いと感じるポイント

### 1.いろいろな業界のことを知れる
特にZYYXに入社をしてからですが、本当に色々な業界のお客様の案件を担当しており、
自分の今まで触れてこなかった業界について知るきっかけになり、知見が広がったように思います。
腰を据えてじっくりやるより、幅広くいろいろなものに触れていきたいという性格の人には非常に合っていると思います。


### 2. 上流から関わることができ、ビジネスの一端を担える
いろいろな業界のことを知りつつ、提案などの上流工程から関わることができる、というのも魅力の一つです。
具体的なイメージを持ってご依頼いただくこともありますが、一緒に考えながら作ることができる案件もあり、こういったことができるのは大きな強みだと思います。
そのお客様のビジネスの一部を担うようなサービスやシステムをご依頼いただことも多々あるので、責任も重さもありますが同時に楽しさもあります。

1社目ではお客様とは会話できずにすでに決まったことが代理店からおりてきて作るだけ…ということをよくやっていました。お客様と話せても一方的な要望を聞いてそれを実現するというようなことも多く、様々な制約が苦しかったです。
直接お客様と話してものを作っていくというプロセスは、関係性だけではなく最終的なプロダクトにかなり大きな影響を与えると感じています。

いまは顧客と一緒に作り上げていく、という経験をZYYXでたくさん積めているので非常にやりがいがあり楽しいです。


### 3. 自分の関わったプロダクトがわりと短いスパンで世の中に発表されて、フィードバックをもらえる
これはデザイナーやディレクターに特に言えることだと思います。
1案件におけるデザイナーやディレクターはそれぞれ1〜2名程度であることが多く、また1案件に関わる期間が短いので抱えている案件が多くなる傾向があります。
UIやデザインなど少ないメンバーで対応しているので責任範囲が大きいですが、打つ球が多いのでその分フィードバックをもらうチャンスが多いです。
もちろんエンジニアの皆さまのおかげできちんと動くプロダクトができあがっています！（ありがとうございます！)

BtoBの案件が多いので直接のユーザーさまからの声を聞くことは叶わないことも多いですが、担当者の方からの反応をいただけるとはとてもありがたいですし、やりがいの一つになっています。

さらに期間が短く・関わる案件が多いので、フィードバックをもとに「次回はこうしてみよう」という新しい挑戦がしやすいというのも良い点だなと思います。
試行回数が多くなるので、技術の上達もそこそこの速度で出来ると感じています。


### 4. エンジニアと密に協力できることで、検討の幅が格段に広がる
エンジニアのいる会社、いない会社で本当に大きく違います。
制作畑の人間だけだと考えられることに限界があったり、実現性が乏しいことを考えてしまうことがあります。
逆にエンジニアだけだと、UIやデザインが苦手…というところも多いのではないでしょうか。

制作メンバー、開発メンバー双方が協力することでできること・できないことの判断がスムーズに行えますし、シナジーで新しいアイディアが生まれることもあります。
メンバーが近くにいる、いつでも話ができる環境というのは結構大事で、これが案件のスピード感や「安心して全部任せられる」という信頼に繋がっています。

全部任せられる、となると当然担当できる範囲が増えるということなので、
そこから経験値もたくさん得ることができる…という良いループができていると思います。


## まとめ
弊社ageなことばかり書いてしまったように思いますが、実際に受託案件がとても面白いな〜と感じているそのままを書きました。
エンジニアは一つの案件にかかる時間は増えるのでまた違った意見もあると思うのですが、様々なお客さまのビジネスに関わることができて経験を積めるというのは本当に面白いです。

また来年も良い出会い、良い仕事ができますようにと祈りを込めて、この文章を締めたいと思います。
ありがとうございました！
【inshellisense】ModuleNotFoundError: No module named 'distutils' の対処法

# TL;DR
各種OSのシェルでコマンド補完をしてくれるMicrosoftのOSS「inshellisense」。少し前に発表され使ってみようとしたら `ModuleNotFoundError: No module named 'distutils'` というエラーで詰まったため、原因と解消を残す。

:::note info
結論だけまとめると、Python 3.12以降`distutils`というモジュールが廃止されたせい。代わりに`setuptools`を入れればOK。
:::

# 本題
近頃はAIで補完するものもあるが、古き良き IntelliSense のコマンド版である「inshellisence」が今年発表されました。

https://github.com/microsoft/inshellisense

少し出遅れたが使ってみようと思いインストールしたら、いくつか権限系のWarnと一緒に `ModuleNotFoundError: No module named 'distutils'` のエラー。

```sh
npm install -g @microsoft/inshellisense
```

あー、`distutils` がないのか。じゃあ入れようと思って、`pip install` するとそんなものは見つからないと怒られる。どうやら <font color="red">Python 3.12 から `distutils` が廃止された</font>らしい。

https://docs.python.org/3.12/whatsnew/3.12.html#summary-release-highlights

仕方ないと言えばそうだが、結構あちこちに影響が出てるようで([issue](https://github.com/nodejs/node-gyp/issues/2869))「大丈夫？」とか思いながらおとなしくPythonの古いバージョンを入れないといけないかなぁと半ば諦めていたとき、ふらっとXを徘徊していたら一筋の光明。

https://x.com/jun66j5/status/1662094759853436928?s=20

鵜呑みで `setuptools` をインストールしたら、無事 `inshellisence` もインストールできました🎉🎉

```sh
pip install setuptools
```
タスクの解像度を上げる大切さ

# **前提**

エンジニア一年目の経験談ということで、タスクの解像度を高めることの重要性を改めて感じたので、体験談も踏まえて共有させていただきます！

どなたかの参考になれば幸いです！

:::note info
この記事は、現場に入って間もない方や初心者の方々に向けて書いています！！
:::


# **タスクを細分化し解像度を上げておかないと・・・**
タスクを振られた際、ほとんどの場合、工数の見積もりを行ってから開発に入ると思います。
例えば、「この機能の工数見積もっておいて！」「このプロジェクトの全体のスケジュール感見積もっておいて！」などを振られるかと思います！

**この工数を出す際の解像度が低いと、以下のようなことが発生します、、**　
- 実装の不安とミスの増加：解像度が不十分だと、実装の可否に不安を感じ、焦りが生まれ、ミスが発生しやすくなる
- 他の案件への対応困難：工数が正確に見積もれていない、スケジュールを引けていないと、他の案件の差し込み対応ができなくなる。（スケジュール的に対応できるかわからない）
- 作業の焦り：別案件での緊急対応が必要になった際、作業に時間を割けず、さらに焦りが生まれ悪循環になる（バッファがない場合）

# **解決策**
上記に対する解決策として、
- タスク分解の解像度を高めること
- もっと言うと実装内容の言語化


がかなり重要だなと感じています。



# **実際にどのように改善したか**
**以下のようにタスク分解の改善を行いました。**
※わかりやすいようにHTMLでの例（ホームページのフロントデザイン）を示します。

**Before**

```
HTMLマークアップ：8時間
- 基本構造のマークアップ（ヘッダー、フッター、ナビゲーションなど）
- ニュース、概要、スピーカー、タイムテーブル、スポンサーなどの主要セクションの基本的なマークアップ。
```
これで見積もりと言っていた自分が恐ろしいです。。。。w


---

**After**
```
HTMLマークアップ：8時間
- 基本構造のマークアップ（ヘッダー、フッター、ナビゲーションなど）
- ニュース、概要、スピーカー、タイムテーブル、スポンサーなどの主要セクションの基本的なマークアップ。

ヘッダー、フッター、ナビゲーションのマークアップ (約2時間)
ヘッダー (<header> タグ)

ロゴ: <img> タグを使用して、サイトのロゴを配置します。alt 属性を用いて、ロゴの説明を追加
サイト名: <h1> タグを使用して、サイト名を強調表示
主要ナビゲーションリンク: <nav> タグを使用してナビゲーション領域を定義し、<ul>、<li>、<a> タグを使用してリンクのリストを作成
フッター (<footer> タグ)

著作権情報: <p> タグを使用して著作権情報を表示
追加リンク: <ul> と <li> タグを使用してリンクのリストを作成
お問い合わせ情報: <address> タグを使用して連絡先情報をマークアップ
ナビゲーション (<nav> タグ)

ドロップダウンメニュー: <select> と <option> タグを使用して、選択可能なメニュー項目を作成
レスポンシブデザイン: メディアクエリを使用して、異なるデバイスサイズに合わせてナビゲーションのスタイルを調整
主要セクションの基本的なマークアップ (約4時間)
ニュースセクション (<section> タグ)

画像: <img> タグを使用して、ニュース関連の画像を配置
テキスト: <p> タグを使用して、ニュースの説明を追加
リンク: <a> タグを使用して、詳細ページへのリンクを提供
概要セクション (<section> タグ)

概要テキスト: <p> タグを使用して、サイトやイベントの概要を説明
スピーカーセクション (<section> タグ)

写真: <img> タグを使用して、スピーカーの写真を表示
バイオグラフィー: <p> タグを使用して、スピーカーの簡単なプロフィールを記述
タイムテーブルセクション (<section> タグ)

スケジュール: <table> タグを使用して、セッションのスケジュールを表形式で表示
スポンサーセクション (<section> タグ)

スポンサーロゴ: <img> タグを使用して、スポンサー企業のロゴを表示
スポンサーリンク: <a> タグを使用して、スポンサー企業のウェブサイトへのリンクを提供
```



この例は、HTMLタグの記述に特化しているため容易にイメージできる内容ですが、
重要なのは**どこまで詳細に書いているか**です。
**動詞を使って具体的にアクションを定義すること**＆**細分化すること**が大切です。

# **まとめ**
見積もりにおいて、細かなタスク分解と明確な言語化を行うことで、工数の見積もり精度が向上します。
これは、実装における不安やミスの減少、他の案件への柔軟な対応、
作業の焦りの軽減につながり、結果として品質の高いプロダクトの開発に貢献します。

人間は見えないものに対して恐怖心・焦りを感じると思います。
今回は実装という小さいスコープでの話でしたが、見えないものを見えるようにすること（努力すること）は遠回りしているようで結果として近道なんだなと思いました！

タスク分解については下記記事を参考にしてます！

ここまで、読んでいただきありがとうございました！！




# **参考記事**
https://qiita.com/jnchito/items/017487cd882091494298



https://zenn.dev/tbpgr/books/8562293d519b8b/viewer/becdc4


https://qiita.com/nakampany/items/b043b9ea52ea0d80f29e
宣言型プログラミングのススメ

宣言型（Declarative）でプログラムを書けると良いですね！
と指摘を受けたことはありますでしょうか？

:::note info
この記事では宣言型プログラミングとは何か？メリットについて伝えたいと思います！
:::

## 宣言型プログラミングとは？
何をするかを明確に宣言した記述方法です。
コードが最終的にどうなってほしいかの結論から書く考え方です。

対比として例に上がる手続型プログラミングは、どのように実行されるか？の具体的な手順にフォーカスした書き方です。

## なぜ宣言型プログラミングをオススメするのか？

宣言型プログラミングをすすめる理由は、コードの可読性や保守性を向上させることができます。

:::note warn
手続き型は、処理を順番におって最終行を読み終えるまでその処理が何を結果として返すのかわからないため可読性が宣言型と比較して劣るのだと考えています…
:::

宣言型と手続き型どちらが正解とかはないと思っています。
ただ、後から読む人が読みやすいのは、宣言型だと考えているのでオススメしてます！

いくつか具体的な例を挙げてみます！

### 配列の数字を合計する関数
#### 手続き型
```javascript
function sumArray(array) {
  let total = 0;
  for (let i = 0; i < array.length; i++) {
    total += array[i]
  }
  return tatal;
}

const numbers = [1, 2, 3, 4, 5];
const result = sumArray(numbers);
```

#### 宣言型
```javascript
function sumArray(array) {
  return array.reduce((total, num) => total + num, 0);
}

const numbers = [1, 2, 3, 4, 5];
const result = sumArray(numbers);
```

宣言的なプログラミングでは、結果を得る処理だけが記述されています。
手続き型の書き方は、どのように結果が得られるか？の手順を明記しています。

### フィルタリングする関数

#### 手続き型
```javascript
function filterEvenNumbers(array) {
  const result = [];
  for (let i = 0; i < array.length; i++) {
    if (array[i] % 2 === 0) {
      result.push(array[i]);
    }
  }
  return result;
}

const numbers = [1, 2, 3, 4, 5, 6];
const result = filterEvenNumbers(numbers);
```

#### 宣言型
```javascript
function filterEvenNumbers(array) {
  return array.filter(num => num % 2 === 0);
}

const numbers = [1, 2, 3, 4, 5, 6];
const result = filterEvenNumbers(numbers);
```

手続き型のプログラミングはfor文と分岐処理で結果を返すのに対して、
宣言型のプログラミングでは`filter`メソッドを利用して結果を返す方法で記述しています。

:::note alert
分岐処理が追加されたことで可読性が悪いと感じた方もいると思います。
関数の場合であれば何が結果として返されるのか？をシンプルにかけると読みやすコードが保てるのではないかと考えています。
:::

## 【宣言型プログラミングのススメ】まとめ
特定の問題や状況に対する最適な解決策を提供します。
どちらのアプローチを採用するかは、具体的な問題によって決まることが多いと思います。

全てを宣言的に記述するのも難しいかもしれませんが、読む人のことを考えて読みやすいコードを書く考え方として知っておけると良いと考えています。
オブジェクト指向設計の学習に苦戦した話【つまずきポイント紹介】

# はじめに

*「わたしは新卒エンジニアだから設計のことがよくわからなくて、“よい設計を知る”ために旅をしているんだ。」*

*「その途中で“オブジェクト指向設計”を知ったんだよ。」*

https://gihyo.jp/book/2016/978-4-7741-8361-9

というわけで、書籍「オブジェクト指向設計実践ガイド」を読んで設計の勉強をしようと試みたのですが、当時の自分では途中で挫折してしまいました。それか設計の基礎からやり直し、ようやくオブジェクト指向設計の気持ちがわかるようになってきたので、何が原因で躓いたのかを改めて考えてみました。

https://qiita.com/wataru86/items/a9d15d0cb047092d942b

この記事では、そんなオブジェクト指向設計の学習に苦戦したエンジニアがつまずきポイントを紹介する記事です。僕と同様にオブジェクト指向設計に立ち向かおうとしているエンジニアの助けになれば幸いです。

# つまずいたポイント

つまずいた原因はいくつかありました。主に以下が原因でした。

- オブジェクト指向言語を用いた開発経験が浅かった
- 大規模アプリケーションを開発する経験が不足していた
- 本が書かれた時代と現代の差を考慮していなかった
- 本を読むのが苦手だった

それぞれについて、紹介していきます。

## オブジェクト指向言語を用いた開発経験が浅かった

当然ですが、オブジェクト指向設計はオブジェクト指向のプログラミング言語で役に立つ設計思想です。僕のプログラミング言語の経歴としては純粋関数型言語の Haskell が一番長く、オブジェクト指向言語は Java を大学の授業で習ったことがある程度でした。

知識としてオブジェクト指向のカプセル化や継承などは知っていましたが、実際にその恩恵をちゃんと受けた経験がありませんでした。そんな状態でオブジェクト指向設計を学ぼうとしても、どんなメリットがあるのか理解しづらく、本を読んでも身につきませんでした。

## 大規模アプリケーションを開発する経験が不足していた

もう一つ足りなかった経験として、大規模アプリケーションの開発経験が少なかったのも原因の一つだったと思います。

個人開発など、小さなアプリケーションを作る場合、雑に実装してもそこまで読みにくくならないですが、大規模なアプリケーションは設計を注意しないと読みづらくなることが多いと思います。当時の僕はまだ経験が浅く、設計を気をつけないと問題が発生するような場面にあまり遭遇してこなかったため、そもそも設計の必要性を十分に理解できていなかったのだと思います。

その結果、本を読んでSOLID原則を知っても、それがどんな場面で役に立つのかを想像することができず、身に付かなかったのだと思います。その後、大規模アプリケーションの開発をしていくうちに、レビューで「これは読みにくくなるから、このパターンで実装するといいよ」などの指摘を何度も受け、ようやくオブジェクト指向設計の必要性を身を持って感じることができるようになってきました。

## 本が書かれた時代と現代の差

「オブジェクト指向設計実践ガイド」 は 「Practical Object-Oriented Design in Ruby」 を日本語訳した本です。「Practical Object-Oriented Design in Ruby」 は今から10年以上前に初版が発行された本です。10年も経てばプログラミング言語のトレンドも変化しますし、研究も進んでいきます。

「オブジェクト指向設計実践ガイド」 では、静的型付けでも結局予期せぬエラーは防げないから動的型付けでダックタイピングした方がマシ、みたいな記述がありました。（若干僕が曲解しているかもしれないです）先述の通り、僕はこれまで強い静的型付け言語である Haskell を使うことが多かったのですが、型システムがしっかりしている Haskell でそんなエラーに遭遇したことはなかったので、「何を言っているんだこいつは :thinking: 」 とこの本に対して懐疑的になってしまい、それ以降この本から離れてしまいました。

ですが、改めて考えてみると、この本は10年以上前に初版が発行された本です。当時の静的型付けと比較すると、現代の TypeScript や Haskell などの型システムは明らかに進化していると思います。なので、本に書かれている全ての内容が現在も正しいとは限らないので、それを理解した上で読む必要がありました。

## 本を読むのが苦手だった

これは僕自身の完全な個人的な要因ですが、本を読むのが苦手なのも、学習に苦戦した要因の一つだと思います。
本を読むとすぐ眠くなってしまうので、睡魔と戦いながらの学習になるのですが、先述の通りオブジェクト指向の開発経験も浅く、これまで Haskell ばかり書いてきた自分がいきなりこの本でオブジェクト指向設計を学ぶのは少し早かったと今では感じています。

# おわりに

*新卒エンジニアの挫折から1年後。*

その後、オブジェクト指向言語を用いた大規模なアプリケーションの開発経験を積み、また、設計の基礎を学んだ結果、ようやくオブジェクト指向設計実践ガイドをまともに読めるようになってきました。まだ本を読むのは苦手ですが、久しぶりに本を開いて軽くよんでみたのですが、書かれている内容がスーッと頭に入ってきて驚きました。

まだ「オブジェクト指向設計実践ガイド」すらちゃんと読み切れていないですが、それを読み終わったらその先の「ドメイン駆動設計」や「クリーンアーキテクチャ」も学んでいき、最強の設計使いになりたいと思います。
計算力学技術者(振動2級)向け　音響工学の知識まとめ

計算力学技術者(振動2級)で問われる音響工学の問題を解くための知識をまとめる。



## 音速
音の速さ $c$ [m/s]、温度 $T$ [degC] とする。
$$c = 331.5 + 0.6T$$

計算問題では、常温でおおよそ $c=340$ [m/s]として計算すればよい。



## 基本式
音の速さ $c$ [m/s]、周波数 $f$ [Hz]、波長 $λ$ [m] とする。
$$c = f × λ$$

波数とは、単位長さ当たりの波の数に$2\pi$を乗じたものである。
波長 $λ$ [m] であるので、単位長さ当たりの波の数は $1/λ$ となるので、波数 $k$ [rad/m] は以下の式となる。
$$ k = \frac{1}{λ} ×2\pi $$

また、波数$k$ [rad/m] は、以下の式変形により周波数(角周波数$\omega$ [rad/s])に依存した物理量である。
```math
\begin{align}
k &= \frac{1}{λ} ×2\pi \\
&= \frac{2\pi f}{c} = \frac{\omega}{c}
\end{align}
```



## 音の伝搬の性質
音速の式より、温度が高いほど音速が速い。スネルの法則(温度の低い層から高い層へ伝搬する音の入射角は大きくなる)により、点音源から放射された音は曲がりながら伝搬していく。



## 音圧レベルの計算
音圧レベル $L$ [dB]は、人間の聴覚特性に合わせた音の大きさを基準とする。
基準とする音圧 $p_0$ [Pa] は、$1$kHzの調和音が人間に聞こえる限界の音圧の実効値とする。
音圧の実効値 $p$ [Pa] の音圧レベル $L$ は以下の式となる。
```math
\begin{align}
L &= 20×\log_{10}(\frac{p}{p_0}) \\
p_0 &= 2 × 10^{-5}
\end{align}
```

#### 計算例
音圧の実効値 $1$ [Pa] の音圧レベル $L$ [dB]
```math
\begin{align}
L &= 20×\log_{10}(\frac{1}{2 × 10^{-5}}) \\
 &= 20×\bigl( \log_{10}1-\log_{10}(2 × 10^{-5}) \bigr) \\
 &= 20×\bigl( 5-\log_{10}2 \bigr) \\
 &= 94
\end{align}
```



## 共鳴
両端が開いた全長 $L$ [m] の音響管内で音波が共鳴する条件は、波の腹の頂点が音響管の端にくる(半波長の整数倍が長さLに一致する)時である。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3655676/5140c463-4e8b-ac0b-d2eb-73113fb77a96.png)

以降 $n$ を整数として、$nλ/2$ とする。また、波数 $k (=2\pi/\lambda)$ を用いて関係式を示すと以下となる。
```math
\begin{align}
\frac{n}{2}\lambda &= L \\
kL &= n\pi \\
\end{align}
```



## 音響フィルタ
A特性：一般的な騒音レベルの評価
C特性：衝撃性の騒音の評価



## オクターブバンド
オクターブとは $2$ 倍の周波数を意味する。
オクターブバンドとは、ある周波数 $f_c$ [Hz]を中心として、上限周波数 $f_h$ [Hz]と下限周波数 $f_l$ [Hz] の周波数比が1オクターブとなる周波数帯域のことである。
```math
\begin{align}
f_h &= 2×f_l \\
f_c &= \sqrt{f_l × f_h} \\
\end{align}
```
中心周波数を用いて上限と下限周波数は以下の計算となる。
```math
\begin{align}
f_h &= \sqrt{2}×f_c \\
f_l &= \frac{1}{\sqrt{2}}×f_c \\
\end{align}
```

1/3オクターブバンドの関係式は以下となる。
```math
\begin{align}
f_h &= 2^{\frac{1}{3}}×f_l \\
\end{align}
```
中心周波数の定義は上記同様。よって、中心周波数を用いた上限と下限周波数の計算は以下となる。
```math
\begin{align}
f_h &= 2^{\frac{1}{6}}×f_c \\
f_l &= \frac{1}{2^{\frac{1}{6}}}×f_c \\
\end{align}
```

#### 計算例
中心周波数が$800$ [Hz] の1/3オクターブバンドは以下の周波数範囲となる。
```math
\begin{align}
f_h &= 2^{\frac{1}{6}}×800 = 897.98 \\
f_l &= \frac{1}{2^{\frac{1}{6}}}×800 = 712.72 \\
\end{align}
```
Jmeter ツールで負荷テスト・シナリオテストをする

## Apache Jmeter

### Jmeterとは
- オープンソース性能テストツール
    - https://jmeter.apache.org/
- 目的: ウェブアプリケーションやサービスの性能と耐久性を評価

### Jmeterの特徴
- 性能テスト: 負荷試験やストレステストを実施
- プロトコルのサポート: HTTP、HTTPS、FTP、JMS、LDAP、JDBC など
- 柔軟なテスト計画: シナリオに基づいたアクションやリクエストの定義

## テストの設定

### リクエストの設定
- ヘッダーマネージャー
- リクエスト（GET、POST、PUT、。。。）
- データコンフィグ（csvファイルなど）

### テスト結果設定
1. グラフィカルなレポート
    - 応答時間のグラフ
    - スループットの可視化
    - エラーレートの推移
2. テーブル形式の結果
    - 各リクエストの詳細なデータ
    - 応答時間、スループット、エラー率など
3. HTMLレポート
    - グラフや数値の詳細な表示
    - 共有やドキュメンテーションに便利
5. ログファイル
    - 実行時の詳細な情報
    - エラーのトラッキングとデバッグ

#### 集計グラフ
![03.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3657064/63f08e86-a785-43a3-a887-387386249638.png)


#### グラフ結果
![02.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3657064/c7d9c352-3143-030d-f6e8-913788f43937.png)


## 負荷テスト
スレッドグループ（ThreadGroup）に主な設定が必要です。
- Number of Threads(users)：ユーザー数 
    - 同時に実行されるユーザー（スレッド）の数を指定します。
    - 例えば、「10ユーザー」ならば、同時に10のスレッドが動作します。
- Ramp-Up Period： ランプアップ時間（スレッドグループ内の各スレッドの開始時間の間隔を指定する）
    - スレッドグループの中の各スレッドが開始されるまでの時間です。
    - 例えば、「5秒」ならば、全体のスレッド数が5秒かけて起動されます。
- Loop Count： 反復
    - 各ユーザーがテスト計画を何回繰り返すかを指定します。
    - 回数設定または無限

## シナリオテスト
複数なAPIの合わせてテストができます。
例えば、下記に2つリクエストが有り、リクエスト２のインプットはリクエスト１のレスポンスを使用する
（実際はログインしてjwt_tokenを取得しつぎのリクエストするケースなどと同様）
```text
・リクエスト１
    - Input: x, y
    - Response: x + y
　↓
・リクエスト２
    - Input: x + y
    - Response: (x+y)²

※csvファイルにリクエスト１のインプットとリクエスト２のレスポンス
例：
x,y,(x+y)²
1,2,9
2,3,25
3,4,49
...

```

### コマンドラインモード＋HTMLレポート
```sh
jmeter -n -t ./sample_test.jmx -l ./result/results.jtl -e -o ./result/html/
```

#### HTMLレポート
![01.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3657064/5ae8652b-8c3a-7932-577b-b9d8f69a9c2e.png)



## サマリー
### メリット
- 使いやすいユーザーインターフェース
    - グラフィカルな設定: 直感的な操作でテストプランを構築
    - 柔軟性: 異なるユースケースに対応可能

- テスト結果の分析
    - リアルタイムレポート: テスト実行後に詳細な結果を取得
    - グラフ表示: パフォーマンスメトリクスの視覚的な分析

- サポートとコミュニティ
    - 無料: オープンソースで誰でも利用可能
    - 広範なコミュニティ: サポートと改善のための豊富なリソース

### デメリット
- 機能が多いので
- 単純テストしてもいろな設定が必要
（フロントエンドの監視が不要の場合 `loadtest`のツールで負荷テストが早いかもしれない ）
Update等の毎フレームコールされる関数内で、一定間隔毎に何かしたいときの判定処理

# 背景
Unityで、一定間隔毎に何か処理を実行したいときがあります。
例えば、接続デバイスの監視とか、デバッグログの出力とか。
そういうことがしたいとき、よく下記のようにしていました。

```c#
float _time;
void Update()
{
    // 1秒ごとに実行
    if (_time < Time.unscaledTime) {
        _time = Time.unscaledTime + 1;
        Debug.Log("kita");
    }
}
```

問題ないのですが、メンバ変数を定義する必要があったりタイピング量が多いです。また、やりたいときに毎回この処理を書かないといけない。本番を想定した処理ではなく、開発中はテスト処理として確実に〇秒ごとではなくてもいいからもっと少ないコード量で書きたい。

ぱっと思いつくコードはあったのですが、まずはChatGPTに聞いてみました。

### 方法1: InvokeRepeatingを使用する方法
```c#
// 開始時に呼び出されるメソッド
void Start()
{
    // 2秒ごとにMyMethodを呼び出す
    InvokeRepeating("MyMethod", 0f, 2f);
}
void MyMethod()
{
    // ここに一定間隔で実行したいコードを書く
    Debug.Log("実行されました！");
}
```

InvokeRepeatingが提案されました。Invokeとか懐かしい…あまり使われないですよね。
この場合、キャンセル処理なども必要ですが提案はされませんでした。
余談ですが、SendMessage系関数やコルーチンも同じく、関数名文字列からコールするというのは特別な状況でない限りあまり利用することはないように思います。

### 方法2: Coroutineを使用する方法
```c#
void Start()
{
    // StartCoroutineを使用してCoroutineを実行
    StartCoroutine(MyCoroutine());
}
IEnumerator MyCoroutine()
{
    while (true)
    {
        // ここに一定間隔で実行したいコードを書く
        Debug.Log("実行されました！");

        // 2秒待つ
        yield return new WaitForSeconds(2f);
    }
}
```
Coroutineが提案されました。UniTaskで書き始めてからCoroutineアレルギー🐛です。
WaitForSecondsをストアせず、毎回newしてるところが気になります。classを毎フレームnewするのは避けましょう。
しかしChatGPTはすごい！コメントまで入れてくれて優秀だ！
だけどコードが長いので、短くしてとお願いしてみましたが、僕の最初のコードと似たような形が出力され、良い案は得られず。

# 一番短いのはこれだ！
```c#
void Update()
{
    if (Time.unscaledTime % 1f < Time.unscaledDeltaTime)
    {
        Debug.Log("kita");
    }
}
```
くるのかな？と思ってたのですが割と正確にきていました。重い処理の場面では頻繁にすっ飛ぶと思います。記事を書いててもう一つ思い浮かびました。
```c#
void Update()
{
    if (Time.frameCount % 60 == 0) // 60FPS固定なら、
    {
        Debug.Log("kita");
    }
}
```
こっちの方が確実そう。フレームカウンタはどんなに重くてもすっ飛ばないはずだから確実にコールされる。だけど可変長フレームレート設定のプロジェクトでは一定間隔とは呼べなくなってしまうかもしれません。が、そもそも確実性を気にしない処理が対象なので問題なし。
以上。