OmniAICreator/Qiita-1.07M huggingface dataset:
Ruby on Railsを触ってみた

# はじめに

この記事は、Qiita Advent Calendar 23日目の記事です。
以下の記事より、すべての記事をご覧になれます。

https://qiita.com/0_terarin_0/items/0f367210e2465f7772c9

# 筆者について

- 現在高校２年生
- 水泳部マネージャー
- 生徒会長
- とある団体の代表

# 本編

僕自身普段からRubyを触ることは全くないんですが、これを機会に触ってみることにしました。

https://guides.rubyonrails.org/getting_started.html

## ①インストール

```zsh:shell
ruby --version
#ruby 3.2.2 (2023-03-30 revision e51014f9c0) [arm64-darwin23]

gem install rails
```

さて、「よし、これでやっと触れる！」と思ってみたのですが…。

```shell:zsh
rails
#Rails is not currently installed on this system. To get the latest version, simply type:
#
#    $ sudo gem install rails

#You can then rerun your "rails" command.
```

ということで、とりあえずQiitaで調べてみると、hashが原因らしく、以下のコードを実行すると直すことができました！

```zsh:shell
hash -r
rails -v
#Rails 7.1.2
```

さて、続きをやっていきましょう！

## ②プロジェクトの作成

プロジェクトの名前はあまり気にしないでください。とりあえず、実行してみましょう！

```zsh:shell
rails new prv_pg_ruby-on-rails
#長いので割愛

cd prv_pg_ru*
bin/rails server
```

見事下のような画面が出てきたら成功です。

![Screenshot 2023-12-24 at 05.27.34.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/583428/71533c13-d6b6-5136-6501-343b139a6101.png)

続きをやっていきましょうか。

## ③Helloを表示できるようにする。

Routeを追記します。

```diff_ruby:/config/routes.rb
Rails.application.routes.draw do
  # Define your application routes per the DSL in https://guides.rubyonrails.org/routing.html

  # Reveal health status on /up that returns 200 if the app boots with no exceptions, otherwise 500.
  # Can be used by load balancers and uptime monitors to verify that the app is live.
  get "up" => "rails/health#show", as: :rails_health_check
+  get "/articles", to: "articles#index"

  # Defines the root path route ("/")
  # root "posts#index"
end

```

Contlolerを作成します。

```zsh:shell
bin/rails generate controller Articles index --skip-routes
```

続いて、/app/views/articles/index.html/erbを編集します。

```diff_ruby:index.html.erb
- <h1>Articles#index</h1>
- <p>Find me in app/views/articles/index.html.erb</p>
+ <h1>Hello, Rails!</h1>
```

これで、[http://[::1]:3000/articles](http://[::1]:3000/articles)にアクセスしてみましょう、見事にHello Railsが表示されています。

![Screenshot 2023-12-24 at 05.37.04.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/583428/cfc48167-6f44-46df-7dda-498e96fea065.png)

## ここまでやってみて好きだったところ

まず、個人的に/config/routes.rbの書き方がとても好きでした。DjangoだとメソッドはViewのデコーレーターで表現するものですから、それに比べるととても直感的です。

```python:django
@api_view(['POST'])
def postMet(request):
  return JsonResponse({test:test})
```

ルートの書き方が直感的でかなりこれは好印象でした。

## なぜやってみたのか。

これは簡単な理由で、Rubyがまつもとゆきひろさんによって作られた言語だったからです。日本人が作った言語であるRubyはどのような使い方をするのががとても気になり、今後使う可能性が一番でかいRuby on Railsの挙動を確かめてみることしました。

ただ、これを今後使うことはおそらくないです。というのも、僕はバックグラウンドの多くをGoogle系のサービスで固めており、これにRubyが対応していることはまあまあ稀だからです。ということで、それらに僕一人の開発で対応するのは非常にコストが高いため、おそらくRubyを採用することはないでしょう。とはいえ、日本人開発者としては知っておかなければいけない言語ですので、これを機に触れてみた次第です。

# 最後に

本日は技術系最後の記事で、Ruby on Railsに挑戦してみました。正直、Flutterを触っているときにRubyのCocoapods関係で苦労した記憶しかなかったので怖かったのですが、使ってみるととても使いやすいものでした。明日以降は僕の高校生での開発まとめと来年以降に何をしたいかなどについてまとめたいと思います。それでは残り少ないアドカレ 23 の記事をお楽しみにしてください。

https://qiita.com/0_terarin_0/items/0f367210e2465f7772c9
🍣 そろそろ寿司を降らさないと〇ぜ！

この記事は、クソアプリアドベントカレンダーの２４日目の記事です。

エル、知ってるか？夜明けまでが今日（２３日）なんだ。
つまり、夜明けまでの投稿すれば、24日のアドベンドカレンダーは遅れたことにはならない。
~~だって、みんな寝てるじゃん(23日29時の発言)~~

今年のアプリは寿司だ。ソウルフードの寿司だ。
日本人の叡智が詰まった究極のご飯、寿司だ。
いまや、日本と言えば、SUSHIってくらい寿司だ。

これ以降の文章は、GPT-4に丸投げした。(ちょっと弄ったけど)
「私は好きにした、君らはいいねしろ」

ビジター、アプリはここからアクセスできる。
用件はそれだけだ。じゃあな。
https://sushilyrain.netlify.app/

🚀 プロジェクトの概要

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/83578/18795b2d-0c38-fe8f-72e1-b25dd5e6638f.png)

このアプリは、ユーザーがボタンを押すか、一定時間待機すると、画面上のランダムなX座標から寿司の絵文字が出現し、画面の右端に向かって横断します。アニメーションの終了後、寿司は消えます。
今の時代に、アクティブデスクトップ壁紙があれば、壁紙にして、楽しんでいたことでしょう。

💻 コードの解説

プロジェクトのコアはVue 3のComposition APIを使用しています。以下に主要な部分を簡単に紹介します。
テンプレート部分

```vue

<template>
  <!-- ヘッダー部分 -->
  <div class="header">
    <h1>sushilyRain</h1>
    <h2>The rain will turn into sushi after midnight...</h2>
    <!-- 寿司を追加するボタン -->
    <div>
      <label>sushi:</label>
      <button @click="addSushi">Add</button>
    </div>
    <!-- 自動追加のオンオフ切り替え -->
    <div>
      <label>autoAdd:</label>
      <button @click="isAutoAdd = !isAutoAdd">{{ isAutoAdd ? 'stop' : 'start' }}</button>
    </div>
  </div>
  <!-- 寿司の絵文字が出現する部分 -->
  <div>
    <div v-for="rain in rains" :key="rain.id" class="box" :class="`box${rain.id}`" :style="rain.style"
      @animationend="rain.show = false" v-show="rain.show">
      🍣
    </div>
  </div>
</template>
```

addでボタンで、寿司を追加できます。
autoAddボタンを操作することで寿司の自動追加をオンオフ切り替えます。

スクリプト部分

```javascript

<script setup>
import { ref, watch } from 'vue';

let nextId = 0;
let intervalId = null;
const isAutoAdd = ref(true);
const rains = ref([]);
const addSushi = () => {
  const randomLeft = Math.random() * (window.innerWidth - 50); // 50はボックスの幅
  const newItem = {
    id: nextId++,
    show: true,
    style: {
      left: `${randomLeft}px`,
      animation: `moveDiagonally ${Math.random() * 10}s forwards`
    }
  };
  rains.value.push(newItem);
}

intervalId = setInterval(addSushi, 800)
const manageAutoAdd = () => {
  if (isAutoAdd.value) {
    intervalId = setInterval(addSushi, 800)
  } else {
    clearInterval(intervalId);
  }
}

watch(isAutoAdd, manageAutoAdd);

</script>
```

addSushi 関数で新しい寿司の絵文字を追加し、
watch で isAutoAdd の状態変化を監視しています。
ポイントは、移動速度をランダムで設定することで、寿司の移動が単調になることを防いでいます。

スタイル部分

```css

<style>
/* 基本スタイルとアニメーションキーフレーム */
button {
  margin-left: 5px;
}

.box {
  position: absolute;
  top: 0px;
  z-index: 1;
  font-size: 50px;
}

.header {
  text-align: center;
  z-index: 999;
  position: relative;
}

body {
  background-color: #121212;
  color: rgb(205, 204, 204);
  overflow: hidden;
}

@keyframes moveDiagonally {

  to {
    transform: translate(calc(100vw - -50px), calc(100vh - 50px)) rotate(300deg);
  }
}
</style>
```
CSSアニメーションで寿司が画面を横切る動きを実現しています。

🌟 ハイライト
- ランダムな出現位置: 寿司が出現するX座標はランダムで、画面の幅に依存します。これにより、アプリに予測不可能性と面白みを加えています。
- アニメーションのカスタマイズ: CSSアニメーションはカスタマイズ可能で、異なる速度や動きを簡単に実装できます。
- ユーザーインタラクション: ボタンを押すことでアニメーションを即座に開始できるため、ユーザーのインタラクションを取り入れています。

📚 結論

この小さなプロジェクトを通じて、Vue.jsとCSSアニメーションの強力な組み合わせを楽しく学ぶことができました。初心者にも分かりやすいように、コードの全体像と重要な部分を紹介しています。ぜひチェックして、あなたのプロジェクトにも応用してみてください！
Pythonで「タプルを作成する」の動作を確認してみた

# 概要

Pythonで「タプルを作成する」の動作を確認してみました。以下のページを参考にしました。

https://www.javadrive.jp/python/tuple/index1.html

# 実装

以下のファイルを作成しました。
```sample.py
x = 9
y = 18
numtuple = (x, y)
print(numtuple)

numlist = (9, 18)
print(numlist)

x = 9
y = 18
numtuple = (x, y)
print(numtuple)

x = 20
print(numtuple)

numtuple = (0,) * 10
print(numtuple)

numtuple = (10, 20, 30) * 3
print(numtuple)
```

以下のコマンドを実行しました。
```
$ python3 sample.py 
(9, 18)
(9, 18)
(9, 18)
(9, 18)
(0, 0, 0, 0, 0, 0, 0, 0, 0, 0)
(10, 20, 30, 10, 20, 30, 10, 20, 30)
```

# まとめ

何かの役に立てばと。
XAIについて説明可能な人材になる

# XAIについて

## 1 XAIとは何か

### 1.1 はじめに

近年、AI（Artificial Intelligence）技術は私たちの生活とビジネスに急速に浸透し、自動運転車、医療診断、金融予測など、さまざまな分野で活用されています。しかし、AIがより深く複雑な意思決定を行う場面では、その動作や根拠が不透明であることが問題視されています。ここで登場するのが「XAI」、つまり「Explainable Artificial Intelligence」です。

### 1.2 XAIの定義

XAIは、その名の通り、人工知能の意思決定プロセスを説明可能にするための技術およびアプローチを指します。XAIは、AIシステムが「なぜそのような結論に至ったのか」を明確に説明し、その根拠を提供することを目的としています。これにより、AIの動作がブラックボックスでなくなり、ユーザーやステークホルダーにより透明性の高い意思決定を提供します。

### 1.3 XAIの背景

AIの成果は非常に素晴らしいものですが、透明性の不足から派生する問題も存在します。特に高度な機械学習モデルや深層学習モデルは、何百万ものパラメータを持ち、その複雑な関係を理解することが難しいため、予測や判断の根拠を説明するのが難しいのです。

例えば、金融機関がAIモデルを使用して信用スコアを決定する場合、そのスコアが低かった場合、顧客に説明するのが難しいかもしれません。同様に、医療診断にAIを利用する場合、なぜある診断が行われたのか、その根拠を説明する必要があります。

XAIの重要性は、これらの分野での透明性の確保に関連しています。また、XAIは倫理的な側面においても重要な役割を果たし、不当な差別やバイアスの問題を防ぐためにも活用されています。

### 1.4 XAIの目的

XAIの主要な目的は次の通りです：

- **信頼性の向上**: XAIを使用することで、AIの意思決定が理解しやすくなり、ユーザーとステークホルダーに対する信頼性が向上します。

- **透明性の確保**: XAIはAIモデルやシステムの動作を説明するため、ブラックボックスでの予測や判断をクリアにします。

## 2章 XAIがなぜ必要か

XAI（Explainable Artificial Intelligence）がなぜ必要か、その理由は多岐にわたります。以下では、2.1 透明性、2.2 信頼性、2.3 必要な場面と不要な場面の観点からその必要性を論理的に説明します。

### 2.1 透明性

AIの透明性に欠ける点は、多くの分野で問題となっています。特に、深層学習モデルや複雑な機械学習アルゴリズムは、その動作原理がブラックボックスのように不透明であることがあります。この不透明性は、AIの意思決定プロセスが理解できないことを意味します。例えば、なぜある診断が行われたのか、なぜ特定の信用スコアが与えられたのか、その根拠が分かりにくいことが挙げられます。

透明性が不足すると、意思決定の信頼性が低下し、個人や組織にとって不確実性をもたらします。特に、AIが人々の生命や安全に関わる場面では、その透明性が求められます。

### 2.2 信頼性

ユーザーはAIシステムに対して信頼性を求めます。高度な意思決定を行うAI（自動運車、医療診断、金融予測など）において、ユーザーはその判断基準を理解し、その予測が信頼性のあるものであることを期待します。XAIはこの信頼性向上に貢献し、ユーザーがAIの意思決定を疑問視することなく利用できるようにします。

### 2.3 必要な場面と不要な場面

XAIがすべてのAIシステムに必要かというと、そうではありません。例えば、天候予報などの単純なタスクにおいては、XAIは必要ないかもしれません。しかし、医療診断、金融取引、自動運転車など、人々の生命や重要な意思決定に関わる場面では、XAIは不可欠です。

必要性はコンテキストに依存し、XAIの導入は吟味されるべきです。透明性と説明可能性を確保するためにXAIを使用することは、今後のAI技術の発展において重要な一歩と言えるでしょう。


## ３．ＸＡＩの種類

XAIにはさまざまなアプローチやテクニックが存在します。いくつかの主要なXAIの種類には以下が含まれます。

### ルールベースの説明

ルールベースの説明は、AIの意思決定プロセスを特定のルールや条件に基づいて説明します。たとえば、医療診断AIが特定の病気の診断を行う際、どのルールが適用されたかを示すことができます。

### 局所的な説明

局所的な説明は、AIの予測や判断が特定のデータインスタンスにどのように影響を与えるかを示します。これは、特定の予測を説明するのに役立ちます。

### グローバルな説明

グローバルな説明は、モデル全体の動作を説明し、特定の特徴が予測にどのように影響を与えるかを示します。モデルの全体的なトレンドと振る舞いを理解するのに役立ちます。

## ４．今後の展望

XAIの分野は急速に進化しており、将来的には以下のような展望が考えられています。

- より洗練されたアルゴリズムとツールの開発
- XAIの実装が法的要件や規制と調和する
- 倫理的な側面に関する研究と実施

## ５．まとめ

XAIはAIの透明性と信頼性を向上させ、意思決定プロセスを理解しやすくする重要な要素です。透明性、倫理、信頼性の観点から、XAIの研究と実装は今後ますます重要になるでしょう。
仲良くやろうよ！～人間関係構築の5つの術(すべ)～

# はじめに
　仲良くやろうよというと友達か！って感じですが
　仕事において人間関係が構築できると仕事で協力関係ができたり、
　ビジネスを広げられたりといろいろ良いことがあります。
　私自身は順風満帆でオールOKですべて完璧というわけではないですが、
　人間関係の構築において、この行動が関係構築に繋がったなーと思えることがあるので
　そんな経験則を記事にできたらと思います。

# 0.人物面
　以下のような人間です。
　・ 陽キャではないです
　　 どちらかというとのび太君に似ています
　・インドア、絵が好き
　・しゃべりは得意でない
　・人に話をするとき、気にしすぎて抵抗を覚えることがある
　・舎弟感はあります（学生時代の部活の影響）
　関係構築にマイナス面もけっこうありますが、
　次のことから始めると人により関係構築の抵抗がなくなるかと思います。
　営業職だと当たり前に思うこともあるかと思いますが、
　コミュニケーションが苦手な方が、私みたいな陰キャでもできることがあるんだなと
　思ってもらえるとうれしいです。
 
# 1.相手との接触時間を増やす
　このご時世ですができたら対面で会うのが一番いいかもしれません。
　気づいたらいるみたいな。
　仕事終わりに一緒に帰るとかもいいです。　
　あとは社内のイベントとか、お客様なら出社日を合わせるとか、
　ランチするとかとか・・・
　とにかく接触時間を増やすと親しみやすくなる感覚がありますよね。
　調べてみたら「ザイアンスの法則」というので提唱されてました。
　ただデメリットもあるようで、最初の印象が悪いとずっとうざいみたいな感じになるので
　その場合は挽回とかしないとアカンみたいです。。 
　<引用>
　https://biz-shinri.com/dictionary/the-law-of-zajonc

# 2.相手の尊敬できる部分を探す
　接触時間が増えて警戒心がお互い薄くなったら、
　相手の尊敬できる部分を探してみましょう。
　単純に自分ができないことができると尊敬に値するかと思います！
　技術力とかに限らず、喋り方や仕事のやり方、考え方、意識などなど、
　すごいなっと思えたら益々心の壁も薄くなると思います！
　ついでに良いやり方を真似して吸収できると、自身のレベルも上がります笑

# 3.相手の趣味をやってみる
　お金も掛かったりするので無理にではないですが、
　自分も興味あるものなら一緒にやってみたり、僕もやってみました！
　で話のネタにするのもいいかと思います。
　土日にゴルフに付き合う…昔ながらの営業みたいな感覚ですが
　自分の興味あることなら、そこまでハードルは高くないかなと思います。
　イベントやスポーツとかでなくても、相手が好きなものを買ってみるとか
　話を深堀したり、その趣味がどういうものか教えてもらったりしてもいいですね。
　興味がなくても意外と付き合って体験してみると割と良くて
　ネタの幅が広がるときもあるかと思います！

# 4.礼節
　私はやらかすことがありますが、礼節を気をつけるのは大前提なところがあります。。
　身だしなみとかもそうですが、ちゃんとお礼が言えたりとか、
　相談した結果がどうなったかの報告や、感謝の気持ちも大事だったりします。
　だいぶ当たり前のことを言ってますが、
　日々過ごしているとおざなりになることがあるのでご留意ください。。

# 5.相手に突っ込んでみる
　よくない感じのタイトルですが、一歩その人に突っ込んでみると関係性が深くなります。
　3.と関連してきますが、話題を深堀したり、お家にお邪魔するとか、
　なにかを上げたり、逆にいただいたり、プライベートで会ってみたりとかとか・・・
　相手が嫌がってたら良くないですが、相手側からもリアクションがあれば
　けっこういい関係が築けてると思います！

# おわりに
　常に関係各所全員に同じ行動ができるかというと無理な話なので、
　要所で試してみたり、苦手な人には無理をしないことが続けられるコツかと思います。
　やってみたけど人間関係構築できなかった！ということがあるかもしれませんが、
　参照程度に見ていただいて、もし上記の行動で仕事がやりやすさの向上や、
　ビジネスが広がるとうれしいです。
　あんまりやりすぎると病むことがあるのでご注意ください！
【gRPC】リクエストやレスポンスでプリミティブ型を使いたい場合

## 概要
あまりユースケースはないかもしれませんが、gRPCのリクエストやレスポンスでプリミティブ型を使いたい場合、どうすればいいんだろうとふと気になりました。少し調べてみた内容をメモ書きしたいと思います。

## 調べた結果
[Can protobuf service method return primitive type?](https://stackoverflow.com/questions/28876725/can-protobuf-service-method-return-primitive-type)のstackoverflowの記事にある通り、基本的にgRPCでプリミティブ型をそのまま返すことはできず、何かしらのmessageで包む必要があります。ただ、この記事の回答にある`wrappers.proto`を使用すれば、プリミティブ型をmessage型でラップされてるものが用意されているので、プリミティブ型っぽい感じで定義することはできそうです。
また、golangではラップされている型が[wrapperspb](https://pkg.go.dev/google.golang.org/protobuf/types/known/wrapperspb)が用意されていて、コード出力後はこの型を使用すれば良さそうです。

## 実装サンプル
せっかくなので、wrappersを使用した実装サンプルのprotoとgolangでの実装を記載します。
なお、goの実装でconnect-goを使用していますが、使用する必要は特にありません。

```sample.proto
syntax = "proto3";

option go_package = "sample/src/gen/proto;placeNote";

import "google/protobuf/wrappers.proto";

package placeNote;

service SampleService {
    rpc GetBoolFromString(google.protobuf.StringValue) returns (google.protobuf.BoolValue) {}
}

```


```sample.go
package server

import (
	"context"

	"github.com/bufbuild/connect-go"
	"google.golang.org/protobuf/types/known/wrapperspb"
)

type SampleServer struct{}

func (s *SampleServer) GetBoolFromString(
	ctx context.Context,
	req *connect.Request[wrapperspb.StringValue],
) (*connect.Response[wrapperspb.BoolValue], error) {
	// リクエストから文字列を取得
	_, err := sampleFunction(req.Msg.Value) // 関数の処理内容は記載割愛
	if err != nil {
		return nil, err
	}
	return connect.NewResponse(&wrapperspb.BoolValue{Value: true}), nil
}
```
Web WorkerをPromiseで処理する

# Web Workerとは
JavaScriptはシングルスレッド。
シングルスレッドで重たい処理をさせると、処理が終わるまでブラウザの操作や描画が止まる。
でも、ウェブワーカーという仕組みを使うとバックグラウンドで処理できる。

つまり、重たい処理をしたいときにいいかんじになるっぽい。

[詳細はMDNへ](https://developer.mozilla.org/ja/docs/Web/API/Web_Workers_API)

# こうした
```typescript
export const webWorkerAsync = <T, S>(task: (arg: MessageEvent<T>) => S, arg: T): Promise<S> => {
    return new Promise((resolve, reject) => {
        const taskString = `
            const task = ${task.toString()};
            this.onmessage = (arg) => {
                postMessage(task(arg));
            }
        `;

        const blob = new Blob([taskString], { type: 'application/javascript' });
        const worker = new Worker(URL.createObjectURL(blob));

        worker.addEventListener('message', (m: MessageEvent<S>) => {
            resolve(m.data);
        });
        worker.postMessage(arg);
    });
};
```

# 使い方
```typescript

// WebWorkerに登録する、重たい関数を書く
const task = (arg) => {
    // 重たい処理
    return arg;
}

// ↑に渡る変数
let arg = 'hoge';

webWorkerAsync(task, arg).then(done => {
  console.log(done)
  // 'hoge'
});
```

# 補足
## webWorkerAsync() の引数
`Web Worker` は、`メッセージ` と呼ばれるシステムでメインスレッドとバックグラウンドスレッドのやりとりを行う。
そのため、大まかな段取りとしては、次のようになる。

1. 処理の登録
2. メインスレッドからバックグラウンドにメッセージを送信
3. バックグラウンドがメッセージを受け取り、登録された処理を開始
4. バックグランドの処理が終わったら、メインスレッドへメッセージを送信
5. メインスレッドがメッセージを受け取る

故に実行する関数と、その関数に渡す変数は別々に持たせたい。
webWorkerAsyncの第一引数が実行する関数(1)で、第二引数が関数に渡される変数(2)になっている。

## T,S
Tは関数に渡す引数の型
SはPromiseがresolveしたら帰ってくる値の型

# 工夫したこと
## Blob
`Web Worker` は通常こんなかんじで、外部ファイルを読み込ませて使うらしい。

```js
const myWorker = new Worker("worker.js");
```

そんなことを言われても、大体Reactやらなんやらnode.jsでトランスパイルする形でコードを書くわけで、ファイルを分割するのは面倒臭い。
ので、テキストをBlob URLを使った。

## task.toString()
というころで、Blobに渡す処理は文字列にしたい
（文字列にしなくてもいいのかもしれんが、Blobは雰囲気で使っておりわからん）

文字列としてJSを書いても動くが、TSの恩恵も預かりたいので、普通に関数を書いて、toStringで関数の中身を文字列に変換する形を取った。

## Promise
とにかくPromiseにしたかった。

# その他
ジェネリクス、どう・・・？
最近勉強しはじめたのだが、もっといい書き方がある気がしてならない・・・。

ちなみにこれをReactでそのまま使うと、処理が複数回呼ばれてしまうので、その辺は別途一度しか呼ばれないようにする工夫が必要なので注意。
コードレビューについて思うこと


## そもそもコードレビューとは何か

> ソースコードやテストが不十分な場合、潜在的なバグやセキュリティホールなどの問題が発生しやすい。
コードには直接の不具合だけでなく、命名規則や構造設計の不備など、可読性やメンテナンス性に関する問題も存在することがある。
最適化が不足していると、リソースの無駄遣いによる性能低下が発生する可能性もある。
これらの問題を解決し、ソフトウェア品質を向上させるためには、コードレビューが重要である。
コードレビューは、開発者のスキルに依存するが、不具合や問題を発見し修正する手段の一つとして活用されている。

とWikipediaはおっしゃっています。

https://ja.wikipedia.org/wiki/%E3%82%B3%E3%83%BC%E3%83%89%E3%83%AC%E3%83%93%E3%83%A5%E3%83%BC

## コードレビューの目的とは

### 品質向上
- クラス設計などが適切か
- 可読性、保守性は担保されているか

### 属人化の防止
- 他の人が理解できるコードであるか
- ソースコードはドキュメントでもあるという考え方がある

### スキル向上
- 開発者の実装レベル向上させる
- 相互レビューなどをすることによりお互いの知らない知識を共有しあえる。また相乗効果なども期待できる

### バグの早期発見
- チーム全体でコードを検証することで、バグや潜在的な問題を早期に発見できる

## ちなみに

レビューする側を

　　　「**レビュアー(レビューア)**」

レビューされる側を

　　　「**レビューイ**」

といいます。(どうでもいいですね🤪)


この記事ではレビューする側を「レビュー実施者」、される側を「レビュー依頼者」と表現します。

## 効率の悪いコードレビューの例

### レビュー形態

- レビュー依頼者
  - まず、開発を完了したレビュー依頼者がレビュー依頼を投げます。
  - この時、開発したコードの差分をZipでまとめて渡したり、GitやSVNにPUSHしたので○○のコミットを確認してください。などと依頼します。


- レビュー実施者
  - 受け取ったソースを目視で順番に確認し、コーディング規約などに照らし合わせて確認する。
  - 本当にレビューが必要なロジックの組み方や、他機能との整合性などの担保は厳密に規約に明文化されているわけではなく、レビュー実施者の裁量に任せられる。


### フィードバック方法

- 指摘事項が見つかれば、ファイル名、行数、スクショ、内容などを1つずつExcelにまとめて、最後にレビュー依頼者に送付する。
- 指摘事項をまとめたExcelを受け取ったレビュー依頼者は、その資料を元に修正を行う。修正後に再度レビュー依頼を行う。

## コードレビュー時によくある問題点や指摘点

### よくある問題点

- コーディング規約レベルの指摘が多いと、本来見るべき観点に時間を割けていない
- 目視での確認がほとんどで、見落としも多い
- レビュー実施者は同じような指摘の繰り返しで時間も体力も浪費してしまう
- 既存機能からコードをコピーしてきた際に、コピー元に問題があると指摘まみれのコードが量産されてしまう
- 既存機能を修正しようにも、リリース後の機能である為、無暗に修正が出来ない

### レビューでよくある指摘点

- 冗長的なコードが多い
- 条件分岐の入れ子が深い
- 不必要なループ処理が多い
- 処理コストをあまり理解せず書いている(配列やリストなどを総舐めする関数など)
- そもそもコーディング規約を守れていない

## 問題に対する対策と課題

### コーディング規約の確認を改めて徹底する
規約の内容は最低限確認することになっているが、十分にできていない
目視での確認をしている以上、必ず見落としがある

### そもそもの既存機能の問題部箇所を洗い出して修正する
修正内容によっては再テストも必要になり、良いタイミングでないとプロジェクト全体に影響を及ぼす

### 解析ツールや整形ツールなどの利用
導入時に手間がかかるが、導入後は負担軽減など改善が見込める
ただし、問題を多く含む既存機能に対して解析を実施した場合、大量のエラーや警告が出る可能性がある
既存機能はそのままで、新規開発分だけを修正するような事もよくある為、注意が必要

## 結局、コードレビューって必要？

これは「プロジェクトによる」としか答えようがありません。
しないよりした方が良いのは確実ですが、プロジェクト内容によって大きく左右されます。

### コードレビューが向かないプロジェクト

たとえば、大きく遅延している状況下で尚且つ 納期のデッドラインが近いのであれば、コードレビューを実施するより、テストで動作を担保して納品する方が多くの場合において優先されるべきです。
また小規模で単発の案件や、定期的なメンテナンスを必要としないシステムなどについても、丁寧にコードレビューをするより数を回した方が良い場合が多いです。

### コードレビューをした方が良いプロジェクト

パッケージ製品や自社サービス、長期間永続して運用する必要があるシステムなどにおいては、少し無理をしててでもコードレビューは実施するべきです。
コードの品質が悪いと、開発自体は無事に終わったとしても、保守や改修などにしわ寄せが来ることが多いです。
また、スケジュールが押しているからと言って、「この機能はいいや」と例外を作ってしまうと、例外が例外を呼び全体が崩れてしまいます。
RFC2322のすゝめ


[本番環境などでやらかしちゃった人 Advent Calendar 2023](https://qiita.com/advent-calendar/2023/yarakashi) 2日目として，遡って書かせていただきます。
「本番環境でやらかしちゃった」というほどの大したことではなく休日が1時間くらい潰れただけの軽い事故ですが，アドカレが空き枠というのも悲しいかと思いますので軽く読んでいただければ幸いです。

## Abstract

研究室内で前任者から引き継いだネットワーク管理を信用してプリンターなどの一部機器を触れなくなってしまったという感じです。
RFC2322だったらこんなことにはならなかったのに…

## Introduction

筆者は理系大学院生(M1)で，研究室内のPCなどの管理を任されています。
今までは教員が担当していたのですが，PC周りが分かる人が栄転されたため，私が後任を拝命しました。

研究室内のネットワークでは，ルーターの下にプリンター数台やスキャナなどと学生たちのPC複数台が存在しています。
プリンターなどの共通の機器は固定IPアドレスで，個人のPCにはDHCPで配っています。(タイトルの伏線)

私が諸々の管理を引き継いでしばらくたったころ，キャンパス全体の停電が行われるという連絡が来ました。
実験装置などはシャットダウンがめんどくさいのですが，私の管轄はせいぜいNASを落とすくらいのもので各自のPCはそれぞれ切っておいてねと通達するくらいでした。
そんなわけで余裕で対応していたつもりでしたが，事件は停電復旧後に起きました。

※ この記事で例示してあるIPアドレスはすべて実在しないものです[^1]。

[^1]: [IPv4 Address Blocks Reserved for Documentation](https://www.rfc-editor.org/rfc/rfc5737.html)

## Experimental section

IPアドレスが固定の機器と動的な機器が混在した状態で一度すべてシャットダウンし，その後適当な順番で起動します。
このとき，動的な奴らの方が起動が速いものとします。

## Results and discussion

復旧後にプリンター(固定IPアドレス，本記事では`192.0.2.2`とします)が使えるかテストしようとしたところ，プリンターがオフラインと言う旨のエラーが出ました。
ところがpingを打ってみるとちゃんと返事が返ってきます。
誰が返事しているのかMACアドレスのベンダーから確認すると，どうもプリンターではない別人(個人PC)が`192.0.2.2`を使っているようです。
このアドレスは固定でプリンターに渡しているのにどうして勝手にそんなことをするのか，どんな実装なんだよ……
と文句を言いながら，とりあえずIPアドレスを解放させてプリンターに返すためにDHCPサーバーの設定を開くと，なんとDHCPの設定としては`192.0.2.2`が固定だとは認識していない(DHCPで配っていい範囲に入っている)ことが明らかになりました。ひどい。
その後は手動でIPアドレスを振りながら固定アドレスの範囲は配らないように設定して解決しました。

以上の情報から推測される機構は以下の通りです。

1. 個人PCがいち早く起動してIPアドレスを取得しようとする。
1. DHCPサーバーは若い番号から順番に配ろうとして，`192.0.2.2`が未使用であることを確認して渡す。
1. プリンターが遅れて起動する。
1. プリンターは自分のアドレスが`192.0.2.2`だと思っているので使おうとするが，既に使用中であることが発覚する。
1. 使えるIPアドレスがないのでプリンターがオフライン状態になる。

## Conclusion

(前任者のやらかし)
固定IPアドレスの機器があるときは，そのアドレスはDHCPで配らないように設定しましょう。
常時起動であれば普段は問題になりませんが，いつ何が起きるかわかりません。

(私のやらかし)
また，ネットワークなど(それに限りませんが)の管理を任されたら，とりあえずどんな設定になっているのか軽くでいいので確認しましょう。

(ネタ枠)
今回のようなやらかしを起こさないようにするためには，[RFC2322](https://datatracker.ietf.org/doc/html/rfc2322)が有効であると考えられます。
Salesforce Bulk APIで関連項目データを入れる時の列名 Tips  4選

# はじめに

BulkAPIやデータローダーで〇〇てどうやって入れるんだろ？となったことありませんか？
特に最初の頃は参照関係項目をどうやっていれるのかわからず困りました。
今回は、今まで自分がヘルプで確認したりドキュメント読んで調べたものをいくつか書きます。

# 記事内で利用するデータのイメージ

:::note warn
記事内で記述する外部ID項目はすべて`ExternalId__c`で記述します。
:::

データ挿入をするCSVをマークダウンの表形式で表現します。

## 取引先

|Name|ExternalId__c|
|---|---|
|株式会社〇〇|1|

## 取引先責任者

|LastName|ExternalId__c|
|---|---|
|ほげ|1|

# 1. 参照関係項目・主従項目

https://help.salesforce.com/s/articleView?id=000383207&type=1

例）取引先に紐づけて、取引先責任者を入れる

`Account.ExternalId__c`に紐づけたい取引先の`ExternalId__c`の値を入れて挿入すると
`Account.ExternalId__c`と等しい`ExternalId__c`をもつ`Account`のIdが`AccountId`に項目入ります。



**取引先責任者**
|LastName|Account.ExternalId__c|
|---|---|
|ほげ|1|

# 2. 所有者をユーザー名で割り当てる

例）所有者を割り当てた状態で取引先を入れる

`Owner.Username`にメールアドレス形式のユーザー名を入れてデータ挿入をすると
Salesforce内の`Owner.Username`と等しいユーザ名をもつUserオブジェクトのIdが`OwnerId`項目に入ります。

**取引先**
|Name|Owner.Username|
|---|---|
|株式会社〇〇|ユーザ名(メールアドレス形式)|

# 3. 所有者をキュー名で割り当てる

例）キューを所有者として割り当てた状態でTODOを入れる

`group:Owner.Name`にキュー名を入れてデータ挿入をすると
Salesforce内の`group:Owner.Name`と等しいキュー名をもつGroupオブジェクトのIdが`OwnerId`項目に入ります。

**TODO**
|Name|group:Owner.Name|
|---|---|
|TODOテスト|キュー名|

# 4. WhatId項目を外部IDで挿入

`関連させたいオブジェクト名:What.外部ID項目`の書き方で表現します。

例）TODOオブジェクトのWhatIdに取引先を紐づけて入れる

`Account:What.ExternalId__c`に紐づけたい取引先の`ExternalId__c`の値を入れて挿入すると
`Account:What.ExternalId__c`と等しい値をもつAccountオブジェクトのIdが`WhatId`項目に入ります。

**TODO**
|Name|Account:What.ExternalId__c|
|---|---|
|TODOテスト|1|

# 最後に

慣れているとサクッと紐づけたいオブジェクトとの関連項目IDを埋めるための書き方がサクッとかけるのですが、
慣れていないと最初は分かりにくいです。
特に`OwnerId`や`WhatId`といった多態的な項目は書き方がややこしいです。
ややこしいですが、Bulk APIで関連レコードを入れることができるようになるとデータ連携がかなりシンプルに書けるのでおすすめです。

https://developer.salesforce.com/docs/atlas.ja-jp.soql_sosl.meta/soql_sosl/sforce_api_calls_soql_relationships_and_polymorph_keys.htm
kintone にある取引先リストからインボイス番号検索をUiPathで自動化するまで2023

#### はじめに
本投稿はUiPath Friends Festival2023にて発表、しようと思っていた内容を少し細かいところまで砕いて解説するためのものになります。
https://www.slideshare.net/takashihashimoto14/kintonepdf

#### 自動化しようと思った経緯
UiPathの勉強を再びしようと決意して、「何を自動化したいか？」を考えた結果、インボイス制度が始まるにあたり、必要かどうかは別として「業者名リストからインボイス番号を検索する」を自分自身の教材としてやってみることにしました。のちに本当に手作業でやっている話を聞くまでは私自身の中で収めるつもりでいました。

#### 手作業での手順
1.kintoneアプリからリストをCSVダウンロード
2.CSVをExcelで開く
3．会社名をコピー
4．[インボイス登録番号逆引き検索](https://www.smartocr.jp/invoice-id/)でペーストして検索
5．結果を目検チェックしてインボイス番号をコピー
6．2のExcelにペースト
7．全社完了するまで3～6までを繰り返す
8.Excelに保存
9.kintoneアプリへインポート

#### UiPathで自動化
こちらが、今回のRPAの全貌です。下部の閉じているところはkintoneへの手動インポート部分になります。上部の閉じているところはインポート時にログインが必要なのでその操作を自動化しています。このQiita作りながら下に移動して、セットにすれば良いと反省中です。ダウンロード部分は本RPAの目玉となる「kintoneアクティビティ」を使ってAPIにてダウンロードしているため、カーソル操作でログインする必要はありません。
![Main.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3622597/3f5355fa-46f2-19fa-d24e-e2c890344b04.jpeg)

#### kintoneアクティビティについて
今年登場した[kintoneアクティビティ](https://marketplace.uipath.com/listings/kintoneconnectoractivities)により、カーソル操作ではなく、APIにて直接抽出することが可能になりました。今回はトライアルを使ったため、インポートは未対応ですが、有料版は対応していますので本投稿では割愛しました。（登壇資料から抜粋）

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3622597/c3185fda-0c85-254d-9892-fbcee7eed8f7.png)

#### 本RPA作成を完走した感想
　正直、私自身が未熟すぎてアクティビティ以外のところで苦戦しました。アクティビティを使えるようにする設定はマニュアルにあって、API設定は一度別のもので体験して理屈がわかっているのと資料の通り、見ればわかるものなのでアッサリ終わりました。
　ただ、他の経験者の方ならすぐわかるUiPathの設定にかなり苦戦しました。もくもく会で画面共有しながらサポートいただきなんとか形になりました。助けてくださった方、この場を借りて改めてお礼申し上げます。
　それから、実は成功したと思っても翌日同様にテストしたらエラー出たことが何回もありました。3年前より画面の画像による掴み方が向上したとはいえ、手順を細分化・動きを細かい一動作まで解析しきらないと成立しないところは非エンジニアにはかなり厳しいものがありました。
 　ただ、やはり、細分化した後コーディングに落とし込まずに直感でシステム化できる、というのは私にとってかなり大きいです。大昔「通産省第2種情報処理技術者試験」の勉強していた頃もコーディングは超苦手です。

#### 今後の課題
　本RPAは「検索結果が１社」であるときのみ反映するものにしました。複数出た時に判断するのは現時点では「人の目」が必要なので一旦割愛して、「検索結果が出たのか、出なかったのか」を判断するために件数はRPAで残してます。
 　おそらく技術的には可能なので検索結果複数社をkintoneのテーブルに書き込むようにして、複数社のレコードを再検索することなく目検チェックして判断する、だけでもかなり楽になります。

#### 最後に
　いかがだったでしょうか？本投稿が私にとってQiitaデビュー作になります。このRPAを作り始めた時からQiitaで公開することが一つの目標でした。「ここの設定を知りたい」などありましたら遠慮なくご連絡ください。
技術面から見るAIセーフティ(AI Safety Fundamentals Alignment Course)

学際科学科（B群）総合情報学コース3年の堀です。

この記事は2023年のアドベントカレンダー学際科学科B群のカレンダーの17日目の記事にします。(アドベントカレンダーやりたいと思いつつ、24日になってしまったのですが、24, 25日の分は他の方が書くかなと思ってます)

### 技術面から見るAIセーフティ

AI Safety Fundamentals Alignment Course
(https://course.aisafetyfundamentals.com/alignment) のSESSION 0〜4を参照し作成したスライドです。2023年9月に作成したスライドを一部編集したものになります。情報の誤り等ございましたら教えていただけますと幸いです。

<script defer class="speakerdeck-embed" data-id="4d1bb90a01ec45c1891eba9b3fea9075" data-ratio="1.7777777777777777" src="//speakerdeck.com/assets/embed.js"></script>

後ほどこちらの記事をもう少し編集しようと考えています。
まだ経験2年なので今でもプログラミングスクールに通ってます

## これは何？

これは「[Happiness Chain Advent Calendar 2023](https://adventar.org/calendars/9414/)」の24日目の記事です

経験2年のエンジニアが Happiness Chain に入会して9ヶ月経過の振り返り記事です

入会理由や、これまで学んできたこと等を紹介します


## 自己紹介

経験2年程度のソフトウェアエンジニアです

受託開発企業のバックエンドを2年経験し、現在は自社開発企業でバックエンド（ときどきフロントエンド）に従事しています

前職時代には、業務以外での勉強をほとんどやらない意識低めなエンジニアでした


## なぜスクールに通ってるの？

### 入会理由

プログラミングスクールに入ろう思ったきっかけは、現在の所属企業が Rails と React を使用しており、何も分からなくてキャッチアップしないとヤバイってなったからです

そんなとき、Twitter で Happiness Chain を知りました

Happiness Chain のカリキュラムは Rails と React だけでなく、AWS や Terraform 等のその他技術も学べるので、入会を決めました

### 現在も続けている理由

Rails と React のカリキュラムは少し前に修了していますが、現在もスクールを続けている理由は以下です 

* 業務で触らない技術がいくつかあり、せっかくなら全部学びたいから
	* フロントエンドを業務で触ることが少ないので、課題が実務経験の代わりになる
* 業務外で勉強するモチベーションが上がるから
	* コミュニティに属してることで、業務終了後に学習する習慣がついています
* カリキュラムが明確で目標が立てやすい
	* スクールに入る前だと「何すればいいんだろう」ってなりがちだったのでカリキュラムがあるのは助かります


## 何を学んでいるの？

Happiness Chain では、これまで以下を学んできました

* Linux
* Git
* Docker
* SQL
* Ruby
* Rails
* Rspec
* JavaScript
* TypeScript
* React
* Next.js
* AWS
* NoSQL
* Github Actions
* Terraform

この他にも、GraphQL や gRPC などの課題もあります

React と Rails でTwitterクローンを実装する課題

![twitter.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1060463/28fdadba-51e7-d048-5003-91e0e6674b52.png)


AWS ECS Fargate にデプロイする課題（ネタバレしないよう画像荒いです）

<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1060463/2e498580-b24e-6384-fdda-80011d8353fa.png" width="700px">


## 課題の難易度は？

### 現役エンジニア目線だと

個人的には、通常の業務と同じかそれ以下くらいで、「難しくてどうにもならない」みたいなことはないです

とはいえ、結構考えさせられる課題もあったりして、想像以上に時間がかかるかもしれません

### 未経験者目線だと

エンジニア未経験者には難しく感じている人が多いようです

しかし、実務レベルで学べるので、簡単なことしか教えてくれないプログラミングスクールに入るよりは全然良いと思います

課題が難しくても長期間継続して学習することで転職できている人が多くいます

## 現役エンジニアでも学びある？

業務で色々と触ってる人なら、新しく学べることは多くないかもしれませんが、私にとっては初めての技術が結構あったので、多くのことを学びました

適度なアウトプット課題があるので、学んだことがしっかりと身についている感もあります

特に学べて良かったのは以下です
* React, Next.js
	* アウトプット課題として結構な実装量のものを作るので、実務でもやっていけそうな力がつきました
* Terraform
	* 業務であまり触わる機会はないが知っておいた方が良い技術なので、この機会に学べて良かった


## 現役エンジニアにもオススメできる？

先ほどあげた技術に学びたいものがあればオススメできます！

業務外でのスキルアップができるので、ジュニアエンジニアでスキルが伸び悩んでる人にも合ってそうです！

現役エンジニアの人も結構いて情報交換したりもできます

気になる方はぜひ
[Happiness Chain](https://happiness-chain.com/)

## 今後は？

カリキュラムの完走を目指して日々頑張っています

現在ではカリキュラムの終盤に差し掛かり、自作アプリを作成中です

ソフトウェアエンジニアとしてスキルアップするために、これからも学習を続けていきます！！！
[Python][Julia]Project euler1 (プロジェクトオイラー1)

### Project euler Ploblem 1 (プロジェクトオイラー1)
#### Multiples of 3 or 5

備忘のために残しておく。

#### 問題文
10未満の自然数のうち、3または5の倍数をリストアップすると、3,5,6,9となる。
これら倍数の和は23である。
1000未満の3または5の倍数の和を求めよ。

(原文)
If we list all the natural numbers below 10 that are multiples of 3 or 5, we get 3,5,6 and 9.
The sum of these multiples is 23.
Find the sum of all the multiples of 3 or 5 below 1000.
 
#### 答え
233168

#### pythonのコード
```Python:Ploblem1(Python)
def sum_multiples(limit):
    ans = 0
    for i in range(1,limit):
        if i % 3 == 0:
            ans += i
        elif i % 5 == 0:
            ans += i
    return ans

print(sum_multiples(1000))
```
#### Juliaのコード
```Julia:Ploblem1(Julia)
function sum_multiples(limit)
    ans = 0
    for i in 1:limit - 1
        if i % 3 == 0
            ans += i
        elseif i % 5 == 0
            ans += i
        end
    end
    return ans
end

println(sum_multiples(1000))
```
YouTube LiveでChatGPTと雑談したい！

## 概要

こんにちは！らっしーねです！まずはこちらをご覧ください！！

https://youtu.be/PFcK5oUV4a8

このツールは、配信者が喋った内容に対して、ChatGPTが音声で返答してくれるというものです！以下に仕組みを解説します！


![スクリーンショット 2023-12-24 0.54.10.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/722141/7cf59039-ed27-4ac9-978a-8e62d335ab2a.png)

## 音声の入力

配信者の方が喋る際に、スマホでGoogle Docsを開き音声入力モードにすることで、トークの内容が文字起こしされます！この入力の部分でwisperなどの書き起こしAIを使用することも検討しましたが、有料であり、かつ手軽ではないため断念しました。

## データの読み取り

Google Docsには、ドキュメントの内容を閲覧・変更できるAPIが存在します。これを用いて、 Pythonのコードから文章を取得することができます！

```python
def get_latest_content():
    # ドキュメントの最新の内容を取得
    document = docs_service.documents().get(documentId=DOCUMENT_ID).execute()

    # ドキュメントの内容をテキストとして抽出
    content = read_strucutural_elements(document['body']['content'])
    return content
```

## ChatGPTへ文章を送信・返答を取得

取得した文章をChatGPTへ送信することによって、ChatGPTから返答を引き出します！

このようなプロンプト（behaviour）を事前に記載し、それと同時に文章を送信することによって、ChatGPTからフレンドリーな回答が返ってきます！

```python
#文章を読みとって質問を返してもらうbehaviour
question_behaviour =  
"あなたは私の先輩です。以下の文章を読んで、それに対する質問を出力してください。
敬語は使わず、フレンドリーにお願いします。
（例）私：昨日美味しいラーメンを食べたんだ！　
あなた：そうなんだ！どこのラーメン屋さん？ ##　私："
```

また、以下のようにコードを記述することによって、メッセージの送信と受信を一挙に行うことができます！PythonはC言語と違い、async / awaitなどを使わずとも外部での非常に時間のかかる処理を待機してくれる性質を持っているので、string型を返す関数をこのように記述するだけで、ChatGPTからの返答を取得することができます！

```python
def chatgpt_response(head, behaviour, chat):

    messages = [
        {"role": "system", "content": behaviour
        },
        {"role": "user", "content": chat},
    ]

    response = client.chat.completions.create(
        model="gpt-3.5-turbo",
        messages=messages,
        temperature=0
    )
    resp = response.choices[0].message.content

    return head + resp
```

## YouTube APIを介したチャット欄への送信

世の中の大きなサービスには、大抵の場合APIが存在します。YouTubeも例外ではなく、外部ツールからYouTube LiveにコメントをすることができるYouTube APIが存在します（無料）！

ただし、このYouTubeAPIは自分の動画にのみチャットを送信することができます。機械的に他の人のライブにコメントを送信できてしまっては、当然荒らされてしまうため、その対策ですね。

```python
# メッセージをYouTube Liveチャットに投稿する関数
def send_message(message):
    global service, live_chat_id
    livechat_line = service.liveChatMessages().insert(
      part="snippet",
      body=dict(
        snippet=dict(
          liveChatId=live_chat_id,
          type='textMessageEvent',
          textMessageDetails=dict(messageText=message)
        ),
      ),
    ).execute()
```

## コメントの内容を読み上げてもらう

以上の手順を踏むことで、ChatGPTがチャット欄に記事を投稿することができました！最後に、この文章をbotに読み上げてもらいます！

VOICEVOXとOBSを連携させる方法もあるみたいなのですが、残念ながらMacには対応していないみたいだったので、今回は簡潔に、Chromeの拡張機能「コメント読み上げオバケ」を使用しました！

この拡張機能は、ライブ配信を始め次第、流れてきたコメントを自動的に読み上げてくれるものとなっています。

## 最後に

実際に使ってみて、音声がうまく入力されなかったり、ChatGPTの性能に限界があったりなど、まだまだ改善できそうな部分は多くあります！あと数ヶ月の間だけですが、少しでも改善できればと思います！
軽深演習 #18 説明か探求か？

### 軽深（かるしん　なんちゃって圏論） Advent Calendar 2023 18日目の記事です。

演習形式をとっているので、ぜひ　回答を試みてください。


### 前提知識　説明か探求か？

説明（評論）を軽深（かるしん　なんちゃって圏論）的に考察するとどうなるかと言う話です。評論は役に立たないと言われてますが、実際には延々と行なわれています。テレビの評論番組を見れば分かるでしょう。なんでなのでしょうか？　多くの人が求めているのは何もしたくない、何も考えたくないからでしょう。評論の本質はあなたは何もしなくてよい、何も考えなくてよいという情報伝達ではないでしょうか？
図式で書くと、こんな感じですね。
```mermaid
flowchart LR
A[評論]-->B[何もしない考えない]
```
会議の場で延々と単なる説明をされたところでしょうがないと思いませんか？　探求から提案をして行動を促すのがいいのではないでしょうか？　探求は正解を求める説明とは異なり、もともと新たな可能性を開くものです。一方、説明と探求の図式は異なるように見えますが、説明は　何もしない考えないでよい　と提案をしているとも取れるのが面白いところです

```mermaid
flowchart LR
A[探求]-->B[提案]-->C[行動]
```

さて[軽深演習 #11 山本五十六](https://qiita.com/zanjibar/items/61cb0e2fa218a5a1fcc9)の図式になんとなく少し似ていますね。

```mermaid
flowchart LR
A[やってみせ]-->B[言って聞かせて]-->C[ほめてやらねば]-->D[人は動かじ]
```

似ていることを数学的に厳密に行うことは、私には到底不可能ですが、[意識変容の現象学──哲学・数学・神経科学・ロボティクスによる学際的アプローチ](https://kaken.nii.ac.jp/ja/grant/KAKENHI-PROJECT-20H00001/)という科研費をもらった研究が思った以上の成果をだしています。今後広い学問の分野で圏論がつかわれるのに期待が持てます。

### 演習 テレビの解説や、評論番組に意味がないなと思ったことはありませんか？　では、どんな番組にしたらいいでしょうか？

テレビなどのメディアに限らず学問の世界でも、説明に終始することはごく普通にあります。そしてなんの行動の提案を行わないことがほとんどです。単なる図式を見ただけですけど、説明だけでは意味がないと明確に認識した気になりませんか？
そして、意味ある番組にするのはどうしたらいいかを、探求の図式をつかって考えてみませんか？
linuxコマンドでファイルの内容を確認する！(個人的備忘録)

# はじめに
この記事では、よく使うけど忘れがちなファイルをの中身を表示するコマンドについて自分用にまとめます。

# 備忘録

## cat
ファイルの中身全てを閲覧できる

```
cat hoge.fuga

cat -n hoge.fuga
```
## head
ファイルの先頭から指定行数を表示する

```
head -n<数字> hoge.fuga
```

## tail
ファイルの末尾から指定行数を表示する

```
tail -n<数字> hoge.fuga
```
ﾑｽｯﾒのおしっこやうんちの頻度を記録して機械学習にぶち込むのは法律的にどうなのか


※私は法律の専門家ではないこと。こんなことを調べる人もすくないこと。この2点から情報が誤っている可能性に留意願います。

## 結論：まあ大丈夫やろ

- 育児記録に関しては最大手アプリ「ぴよログ」が『第11回 キッズデザイン賞』を受賞している
- 親権の中の様々な権利の中に、育児記録も親の権利として内包されていそう
- プライバシーの侵害を判定する3つの基準に該当しなさそう
- 微妙そうなところ

## 調査結果

### 「ぴよログ」大丈夫だから大丈夫理論

「ぴよログ」は授乳回数、眠った時間、おしっこ、うんちなど赤ちゃんに関するあらゆる情報を記録できるアプリです。

赤ちゃんの傾向をデータで把握できるという点がとても素晴らしいです。おかげさまで育児初心者だった私も「そろそろ起きる」「オムツだ」「おなか減ってるかも」「これは眠いやつ」と反応できるようになり育児を楽しんでいます。

「ぴよログ」はAndroidアプリのダウンロード数だけでも50万ダウンロードを超えています。
また、『第11回 キッズデザイン賞』を受賞しています。（同コンテストで内閣総理大臣賞とかもあるので信頼度が高い賞と思われます）

そんなぴよログにはPDF形式で赤ちゃんのデータをエクスポートする機能が付いています。
赤ちゃんのデータを記録してもいいし、データを書き出してもいいよ。→書き出せるってことはいろんな風に利用してもいいってことじゃない？

よって、ぴよログが大丈夫だから大丈夫理論が生まれました。

### 親権の中の様々な権利の中に、親の権利として内包されていそう

例えば親権の中に「身上監護権」というものがあります。以下引用。
>親権者が未成年の子の身体的・精神的な成長を図るために監護・教育を行う権利。民法では、子の居所を定めること、懲戒すること、職業を営むことを許可する権利を規定している。未成年後見人も被後見人である未成年者に対して親権者と同一の身上監護権を有する。→財産管理権

https://kotobank.jp/word/%E8%BA%AB%E4%B8%8A%E7%9B%A3%E8%AD%B7%E6%A8%A9-671825

ぴよログをつけることで、例えばオムツ替えを忘れてしまってお尻が荒れるということがなくなったり、パパ、ママで2人でミルクを上げてしまって大量に吐き戻しが起きたということを防いでいます。

赤ちゃんのデータを記録したり分析することは、むしろ推奨されることですらありそうです。

### プライバシーの侵害を判定する3つの基準に該当しなさそう

以下引用します。

>プライバシー権侵害の判断基準
損害賠償請求が認められるプライバシー権侵害にあたるか否かの判断基準は、上記に示した私事性・秘匿性・非公知性のあるプライバシー情報を正当な理由なく公開・公表したか否かです。
私事性については、例えば、政治家や公務員の「公人」としての活動に関するものについては、「私事性」がありません。
秘匿性については、例えば、「ユリよりも桜が好き」といった、一般人の基準からして、他者に知られても心理的負担がないと思われるような事実は、「秘匿性」がありません。
非公知性については、すでに何らかの形で公となっている事実を再度公表した場合、「非公知性」がありません。

https://keiyaku-watch.jp/media/kisochishiki/privacy

この秘匿性を満たしていない可能性があります。
赤ちゃんの頃、オムツを毎日4回変えていたというのをばらされて訴えられた話は聞いたことがありません。

また、名前や生年月日などの情報を用いず、単におしっこやうんちの情報だけで個人を特定できるとは考えにくいです。なので、適切に個人情報をマスクした上で利用すれば、親権の範囲内に収まるのでは？と推測しました。

### 微妙そうなところ

ものごころついて「つけないで」と言葉で言われた場合、親権の範囲に収まるのかわからないです。事例が見つかりませんでした。

うかつにデータを公開するのもやめておきましょう。

### まとめ

将来子供が嫌がらない程度に分析するのはたぶんありです。

子供の意思が絡むとどうなるかわかりません。

分析だけでなく公開するとどういう判定かわかりません。

### 最後に

迷惑かと思いますが、後日ぴよログ問い合わせ窓口にどうして大丈夫なのか聞いてみたいと思います。
【ポエム】来年10年目を迎えるエンジニアの思うこと

クリスマスイブですね✨
みなさん、いかがお過ごしですか？

さて、来年エンジニアに転職して10年目を迎えるわけですが
その10年間の経験を通して感じたことだったりをお伝えできればと思います！

## はじめに
この記事は、株式会社スピードリンクジャパン Advent Calendar 2023 の24日目の記事です。

https://qiita.com/advent-calendar/2023/slj

## イントロダクションと経歴紹介
私は新卒1年目に営業の会社から転職して株式会社スピードリンクジャパンに入社しました。
これまでに以下のような業務に携わってきました。
* 社内研修の講師
* テスト設計・実行
* テスト自動化
* Android、iOSでのスマホアプリ開発
* Webアプリケーション開発
* プロジェクトマネジメント

## エンジニアの多様性
転職して初めてわかったことですが、一口にエンジニアって言ってもホントにたくさんの種類があるということです。

　
私が大学時代（一応工学部）に想像していたエンジニアはこれ一択でした。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2748416/1058d850-2423-b1f0-573f-c016b832be37.png)

エンジニアと聞くと、プログラムを書いてシステムを作っているというイメージがありますが
実際のところ、以下のように様々なエンジニアがいます。
* プログラムを書くエンジニア
* 書くための設計をするエンジニア
* 設計のためにお客さんと要件を調整するエンジニア
* つくったシステムのテストをやるエンジニア
* リリース後に監視をするエンジニア

すべてのエンジニアがプログラムを書いているわけではないですし
それぞれの**職種によって求められる資質**も変わってきます。

## 結局、何が言いたいの？
私が言いたいのは、**誰にでも自分にあったエンジニアという職種**があるんじゃないかということです。
（もちろん最低限のシステムに関する知識や技術への興味と言ったところは一定数必要だとは思いますが。。。）

## 経験の重要性
ただ、自分にあったエンジニアに出会うためには、色々経験してみることがとても重要です。

例えば、QAエンジニアを経験する前のイメージは「単純作業の連続。画面ポチポチの繰り返し。」とものすごくマイナスイメージでした。
実際経験して思ったことは、

* 全網羅のテストはシステムが大きくなればなるほどパターン数は天文学的な数字になり難しい。
* テスト自動化で人力で行う部分を最小限に。
* 人力で進めるところもパターン数を抑えるために、似たようなパターンを省いたり。


　
経験したからこそ、テスト設計の奥深さに気づくことができた。
**経験してみないとわからない魅力はあるし、自分に合ってるかどうかも判断できない。**
　

周りを見ていると、「開発できないから転職する！」とか「（一つのエンジニア職種だけ経験して）エンジニア向いてないかも」という人をよく見かけます。

そんな人に私は言いたい、「つべこべ言わずに**もう2,3個経験してみろ**」と。

## 終わりに
とまあ、色々あーだこーだと言ってきましたが
この内容を読んで誰かが気楽になってくれたらいいなーと思っています。

🎄🎅🎁メリークリスマス🎄🎅🎁
SplunkとF1の関連情報を調べてみた

Splunk Advent Calendar 2023 24日目です！
[ykoeさんの記事](https://qiita.com/ykoe/items/47482d6537c43a2999ef)に反応してSplunkとF1に関連する情報を調べてみました。

まずはクリスマスの話から始まるTED2022のセッションから。

# Esports, virtual Formula 1 and the new era of play

https://www.ted.com/talks/james_hodge_esports_virtual_formula_1_and_the_new_era_of_play

Splunkに勤めているJamesさんは、クリスマスプレゼントにもらったFIFA'96がきっかけでゲームにはまって以来、現実世界とそっくりなF1ゲームが大のお気に入りだとか。データドリブンな世界のおかげでF1ドライバーになるチャンスが誰にでも訪れるという話をされてました。内容はざっくり次のような感じです。

> - マクラーレンのF1ドライバーであるランド・ノリス選手に言わせると、F1ゲームは本当にリアル。路面の凹凸も感じることができる。違いは走行中の風を感じられないことくらい。
> - カートの世界で無敵だったルディ・ファン・ビューレン（Rudy Van Buren）は資金不足のためF1ドライバーになる夢をあきらめた。
> - 数年後、ルディはドライビングシミュレーターの大会で優勝、マクラーレンのシミュレーターチームとプロ契約を結んだ。これがきっかけで、後に本物のレーシングドライバーになった。（マクラーレンではなかったのが残念）
> - テクノロジーの進化によって、地理的・社会的・経済的な壁を越えることもできる時代になった。F1ドライバーになることだって夢ではない。

Splunkと関係ありそうな話は少しだけで、「勝つためにはデータを集めて分析する必要があるんだよ」という次のような内容でした。

> - 現実のレースでは約300個のセンサーを使って走行中のテレメトリデータを集めている。
> - 集めたデータをリアルタイム分析してドライバーにフィードバック。
> - ゲームでも処理してるデータ数は同じくらい。
> - 現実もゲームも優勝するにはデータを分析して改善を行うサイクルが必須。
>   - どのタイミングでブレーキを踏めばコーナーを最速で曲がれるか、などなど、改善していくにはデータの分析が必要不可欠。

これだけだとよく分からないので探してみたところ、いろいろ見つかりました↓

# Art of Data ~データ活用術：マクラーレンの「第3のF1マシン」

[日本語の翻訳ブログ](https://www.splunk.com/ja_jp/blog/partners/art-of-data-the-mclaren-formula-1-third-car.html) があります。マクラーレンチームは会場にSplunkなどが稼働するサーバーをラックまるごと持ち込んでるようです。F1マシンが2台あるから、このラックは3番目ということらしいです。ブログに埋め込まれていた[Youtubeの動画](https://www.youtube.com/watch?v=JCSldzcKQ7E)から3つほどピックアップしました。

- 大変そうなラック搬入作業
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/197953/1e884613-c871-81c8-d7c9-96499dfecc88.png)
- Splunkのダッシュボード
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/197953/4b43b773-bfd5-755f-5fd9-c34accab6c43.png)
- データを分析する管制塔
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/197953/984a997b-2057-16dd-2015-d2fc460aebf2.png)

個人的にはデータを分析するコントロールセンターのインパクトが強かったです。動画の3分45秒あたりから紹介が始まります。
こちらのリンクカードからどうぞ。

https://youtu.be/JCSldzcKQ7E?si=w7QOp034DTQiEuI0&t=225


# その他のダッシュボード

マクラーレンのサイトにもSplunkのダッシュボードを紹介しているページがありました。

https://www.mclaren.com/racing/partners/splunk/bringing-data-virtual-grand-prix/

これらのダッシュボードがどう使われているのかについては、Splunkのページにある[日本語字幕付きビデオ](https://www.splunk.com/ja_jp/resources/videos/mclaren-driven-by-data.html)が参考になりそうです。

F1でもHappy Splunking!
自作キーボード レポ：Keyball44

# 自作キーボード レポ：Keyball44

# はじめに

こんにちは、ガラパゴスの岡崎です。
普段は、AIR Design サービスの統合ソリューション統括をやっているのですが、なぜか今回エンジニア有志のアドベントカレンダーにお招きいただきました。
非エンジニアの自分がこんな場をいただいてよいのかという、一抹の不安はあるのですが、せっかく機会をいただいたので、普段自分が親しんでいる自作キーボードについて一筆啓上したいと思います。

# 自作キーボードとの出会い

当時、2019年の初頭くらいだったと思うのですが、起業していたタイミングだったので、シェアオフィスで仕事をしていました。
その時はHHKBの墨を使ってたんですが、2点悩みがありました。

1. 首のハリ
2. 数字キーのタイポ

自分は、小指が極端に短いので特に端の方はタイポが激しく、当時から悩んでました…

![IMG_4827.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/197479/984c668b-4937-ca4b-78e7-b48a97c5e64c.jpeg)

そんな中たまたまTwitterで左右分離型キーボードを発見し、興味が湧いてきて調べていました。

当時は家にハンダも何も無かったですし、そもそも無知だったので、とりあえず秋葉原の遊舎工房さんにお邪魔し、いろいろと店員さんい話しを伺いました。

すると、どうやら工房で作業ができるとのことで、日を改めて作業をし、初めて作ったのが、以下の Corne Chocolateです。

![IMG_B42362A85CEF-1.jpeg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/197479/d0223b39-b19a-823e-6652-e19c2ea07c15.jpeg)

薄型で持ち運びも容易という点と、ミニマルデザインが気に入って愛用していました。

ただ、使っていくうちに打鍵感が気になりはじめたのですが、ロープロファイルの Corne Chocolate は選べるキースイッチが少なかったのです。そこで同系統のCorne Cherry に変えることにしました。

# 二代目 Corne Cherry

またまた遊舎工房さんにおもむき、いろんなキースイッチを試させていただきました。（おそらくお店のキースイッチすべて試したと思う）その中で、[Zielent V2 67g](https://shop.yushakobo.jp/products/a02zi?_pos=1&_sid=07e90cec0&_ss=r) というまぁまぁ重めの静音タクタイルがしっくりきたので、それを購入することにしました。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/197479/1e4e3964-7329-389a-c515-cc9b87423e7e.png)


そのとき作ったのが以下です。ちょっとキートップも奮発してかっこいいやつを買ってましたｗ

![IMG_3C495A98D161-1.jpeg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/197479/9ad19c8c-8bb1-b0ae-0699-794ad60fc461.jpeg)

この機はすごく気に入っていたのですが、半年も使い出すと、段々と67gが重く感じるようになってきました。

そこで、同じ Corne Cherry に Zilent V2 の 62g を試してみました。たかだか5gの違いかと思ったのですが、全然使用感が違い、しっくりきたので、今でもずっとZilent V2 の62g を使っています。（先日[本家](https://zealpc.net/products/zilent?variant=5894817710118)のサイトから100個追加購入しました。今なら21％ OFF!! 12/24現在）

## 現在は Keyball 44

その後、Claw 44 のフォルムに惹かれて利用していたのですが、追加の親指側ボタンを活かしきれず、もやもやしていました。

当時からKeyballシリーズは興味があったのですが、なかなか販売にならず、諦めかけていたところ、なんと先日[白銀ラボ](https://shirogane-lab.net/about)さんで販売が再開されたので、早速組み上げて使っております。

![IMG_4839.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/197479/eda0f36d-0d91-f613-d7a8-c1e051527f9a.jpeg)

まだ、レイヤーのキー配置とかはFIXできていないのですが、いろいろ試行錯誤しながらイジっていくのが自作キーボードの醍醐味だと思っているので、日々楽しいキーボードライフを送っています。

ぜひ、お読みいただいた方にも素敵なキーボードライフが訪れるよう、聖夜に心からお祈りしております。

## おまけ
Keyball 44 の作業風景をいくつか置いておきます。

![IMG_4787_2.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/197479/098890f9-f7d4-e20b-c69a-64ce34fc7a6c.jpeg)
個人的には、ダイオードのはんだ付けをしているときが一番楽しいです。

![IMG_4788_2.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/197479/c8d5cb5d-d050-9e1b-4ab5-1dc93a0c3743.jpeg)
今回は久しぶり（おそらく一台目の Corne Cherry ぶり）にLED実装も行いました。

![IMG_4790.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/197479/d9af8f8f-75f4-2246-f79b-9329a6d333bb.jpeg)
が、盛大にやらかしてしまいました。まだまだ精進が足りません…orz

![IMG_4791.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/197479/f5e66d69-5a57-1548-16b6-03bedbdf00f2.jpeg)
はんだ付けはここまで、ここからはキースイッチはめてキー配置決めていく感じです。
12/23にクリスマスツリーを作った話

メリークリスマス！

![MicrosoftTeams-image (23).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/31758/2226b955-de2e-32bd-b7cc-f9ea5aee4fd9.png)

みなさま、クリスマスをいかがお過ごしでしょうか？    
寒いので、私は部屋にこもって電子工作です。（この記事は公開日の前日の12/23に書いてます）    

よく考えたら界隈ド定番ネタのツリー基板を作ったことがなかったので作ってみました。

[つくったもの (github)](https://github.com/tadfmac/xmas-tree2023)

> WS2812B が 大量に余ってたから！ 

### 概要

- フルカラーLED x 16個
- Seeed XIAO RP2040 搭載。LEDのパターンをプログラミング可能！
- 背面にモード切り替えスイッチ付き (2モードだけだけど)
- M3のネジ1本でスタンドに取り付け。スタンドの3Dデータもあるよ！

基板用のgerberデータもスタンド用の3Dデータも部品リストも全部公開していますので、みなさんも作れます！

... ん？ 作れないって?

### 今日は12/24！！！

作ったのは 12/23つまり昨日。明日までしか飾れないよ......    

この記事見た人が作ってくれるにしても、飾るの最短で **来年だよ** 。 

   

### なぜ間に合わなかったか?!?!

→ 期限設定ミス !!!!!

アドベントカレンダーが **12/24当番** だったので「クリスマスネタだろ！」と、12/24までに作ろうと考えたのが大間違いの始まり。    

今日記事公開できてるので、 **アドベントカレンダーの締切には間に合った** 。    

しかし、こういう物理的なモノは **飾るためにつくるんじゃ!!**

本来 **1ヶ月前に期限を設定しないとダメ** な案件でした。   

来年使うことにします。。。。    
みなさまも来年使ってください。    

### WIPなところ （もはや些事w）

#### 1. USBデバイスファームウエア

本来USBデバイスにする予定でしたが、現在公開中のファームにまだその機能はありません。    

> 昨日の夜書き始めたから....

ファームウエアはアップデート予定です。    
来年11月くらいまでにやればいいので余裕なはず！（←これだいたい余裕なくなるやつ）

#### 2. 星形のLEDキャップ

一応試作したんだけど、小さい。サイズ合ってない。    
作り直す予定。    

### 反省→目標設定の大切さ

目標設定の大切さは [3日前に書いた記事](https://qiita.com/tadfmac/items/842c57f019347f75384d) で大いに語ったはずだけど、自らダメな目標設定の典型をやってしまった。
[Unity]UnityAdsを導入する

# 概要
UnityAdsはUnityが提供している広告サービスです。バナー広告、インタースティシャル広告、リワード広告を使うことができます。
UnityAdsを導入する基本的な手順をここにまとめます。
# 本文
Window > General > Servicesを選びます。
![スクリーンショット 2023-12-23 23.14.18.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/617265/bf09f800-2d63-05ef-53e6-5205308b1b82.png)

UnityGamingServicesが表示されます。Adsを選択します。
![スクリーンショット 2023-12-23 23.14.29.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/617265/770a0115-e61d-0227-2efa-179a1cb4f053.png)

ProjectSettingsのAdsが表示されるので「OFF」のボタンを押すとONに切り替わります。
![スクリーンショット 2023-12-23 23.14.57.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/617265/d29e92fa-1819-f134-6e9b-23ab1a06bde8.png)

Current Versionが古いので「Install Latest Version」を押して最新バージョンにアップデートします（最新バージョンに不都合がある時は押さない方がいい場合もあります）
最初は広告の動作テストをすることになると思いますので「Enable test mode」にチェックをつけておくのが良いと思います。（アプリをリリースする時にはチェックを外してください）
![スクリーンショット 2023-12-23 23.15.32.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/617265/ae947b35-5af6-3c6c-29d0-fed2b2c3a1ad.png)

:::note warn
この流れ以外にPackageManagerからUnityAdsをインポートする手順もありますが、正常に動作しなくなるらしいです。ここにある「Open Package Manager」もできれば押さない方が良さそうです。
:::

ProjectSettingsを閉じて、UnityGamingServicesにある「Dashboard」を押すとUnityのWebページに飛びます。
![スクリーンショット 2023-12-23 23.33.32.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/617265/bc6cc09d-41d9-a9da-300c-0fdf2b1a1fb8.png)

製品 > Unity Ads Monetizationを選択します。
![スクリーンショット 2023-12-23 23.45.04.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/617265/8c263823-ae15-0990-c654-a87eafcebf6a.png)

「Set Mediation Partner」を押します。
![スクリーンショット 2023-12-23 23.45.47.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/617265/680aa5ce-e319-17ff-d034-7ba079779f63.png)

表示されるポップアップには選択項目が二つありますが、メディエーション（UnityAds以外の広告も併用する）にする場合は「I plan to use Mediation」使用する広告がUnityAdsだけの場合は「I only plan to use Unity Ads」を選んでOKを押します（OKが押せない場合は選択項目を一度切り替えて元に戻すと押せるようになると思います）
![スクリーンショット 2023-12-23 23.45.32.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/617265/ce5afc9b-93c1-80b3-a4c8-5de7da440785.png)

AdUnitsの一覧画面が表示されます。ここから先は実際にUnityでコードを組んでいくことになりますが、上にあるGameIDと下にあるUnitごとのIDを使用することになります。必要になるタイミングでここからコピーして貼り付けていきます。
![スクリーンショット 2023-12-23 23.46.50.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/617265/99e197b3-c67a-0d6e-327c-09198323e8c5.png)

実装手順については設定ガイド > Read integration guide
を押すと飛べるWebページに詳しく書かれています。そちらを参照してみてください（バージョンによって記述方法は変わりますので最新の情報を確認するのが良いと思います）
https://docs.unity.com/ads/en-us/manual/UnityDeveloperIntegrations
![スクリーンショット 2023-12-24 0.15.33.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/617265/5f222612-95e7-aa1b-4961-98f37b3cfe43.png)

赤枠で囲った所だけ確認すれば十分です。「Initializing the SDK in Unity」で初期設定をして、その下の３項目でそれぞれの広告の種類ごとの実装方法が解説されています。
![スクリーンショット 2023-12-24 0.16.26.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/617265/079a3856-a83b-14fb-f4ee-815ef57dfbb1.png)
Goのジェネリクス

# ジェネリクスとは
Golang1.18で導入された機能。
型の安全性は保ちつつ、異なる型を引数で取りうるといったものです。
コードの再利用性の向上が期待できます。

```go:main.go
package main

import "fmt"

// 型パラメータを持つ関数
func Print[T any](s []T) {
    for _, v := range s {
        fmt.Println(v)
    }
}

func main() {
    Print([]int{1, 2, 3})
    Print([]string{"a", "b", "c"})
}
```

型パラメータとして`T`を利用しています。
ifxに備えよう

君らが愛してくれたifortは**非推奨**になった．何故だ！？

# 概要
この記事は，Intelコミュニティに投稿された[記事](https://community.intel.com/t5/Blogs/Tech-Innovation/Tools/Deprecation-of-The-Intel-Fortran-Compiler-Classic-ifort/post/1541699)の要約です．

# 要約
- Intel Fortran Classic (通称ifort)は，2023年11月20日に非推奨となり，最終的には廃止さると発表されました．
- 廃止は2024年末に行われます．バージョン2025は提供されず，ifortのダウンロードもできなくなります．サポートに入っていれば2025年後半まではダウンロードできますが，2025年後半には完全にダウンロードできなくなります．
- 廃止されるまでの間，セキュリティアップデート等の重要な修正のみが提供される可能性はあります．
- ifxは，ifortのフロントエンドとランタイムライブラリに基づいていますが，バックエンドがLLVMベースに変更されています．
    - コンパイル時間が最大18%短縮されます．
    - 最新のIntelプロセッサ向けの最適化を提供します．
    - `do concurrent`やOpenMPの`target`によるIntel GPUへのオフロードを提供します．
    - LLVMコミュニティツールにより，メモリやスレッド化の問題を発見し，修正できるようになります．
- ifxのバグを発見した場合は，Intel Communityの[Fortran Compilerのフォーラム](https://community.intel.com/t5/Intel-Fortran-Compiler/bd-p/fortran-compiler)から報告してください．（サポートを購入していない場合）
- ifortからifxに移行する場合，[開発者ガイド＆リファレンス](https://www.intel.com/content/www/us/en/docs/fortran-compiler/developer-guide-reference/2024-0/overview.html)と，[移行ガイド](https://www.intel.com/content/www/us/en/developer/articles/guide/porting-guide-for-ifort-to-ifx.html)を参照してください．
【エンジニアの基本】汚いコードを書く人の末路


## 導入:
初めまして、Flutterエンジニアのトマトです。
この秋に転職し、コードの綺麗さが開発に与える影響について多くを学びました。
この記事では、綺麗なコードを書く意味と、汚いコードがもたらす問題点を共有します。

尚この記事はflutterエンジニア初心者やエンジニア初心者向けに作成しております。
すでにWEB・アプリエンジニアとして働かれている先輩方には不要な記事かもしれませんのでその点をご了承ください。

## 綺麗なコード vs 汚いコード:
まず初めに皆さんは綺麗なコードと汚いコードの違いとは何だと思いますか？
変数名の命名規則？？
コメントアウトでコードの意味が明確になっているかどうか？？
リファクタリングを考えているかどうか？？
正直どれも正解です。
それ以外にも綺麗なコードと汚いコードというのは色々と差があります。
しかしどれにも共通するものがあります。
それは相手のことを考えてコードを書くか書かないかの差です。
本当にそれを実感しました。
転職してまだ一ヶ月ちょっとしか経っていないジュニアのエンジニアですが会社のコードを見て唖然としました。

## 綺麗なコードへの無関心
過去を振り返ると、私自身、綺麗なコードを書くことの重要性を軽視していたことを認めざるを得ません。
可茂IT塾インターン時代、綺麗なコードについて度々指摘を受けましたが、当時の私はタスクの完了に集中しており、コードの可読性や保守性にはほとんど注意を払っていませんでした。

## 過去の自分への謝罪
今、こうして振り返ると、私がどれほど多くの先輩エンジニアに迷惑をかけていたかを痛感しています。
私の未熟さと無知が彼らの負担を増やしていたことを深く反省し、心から謝罪したいと思います。
そして、今後はレビュワーをはじめとする他のエンジニアのことを常に考え、より読みやすく、理解しやすいコードを書くことを心掛けます。

## 汚いコードとの格闘
実際に直面したコードは以下のようなものでした。

未使用の謎の変数が散乱
dynamic型の乱用と、Lintエラーを無視する文化
極端なネストと、一つのファイルに500行近くもある膨大なコード
これらのコードは、読むこと自体が一苦労。
転職後、早々にリファクタリングの任を負った私は、この「脳筋コード」との戦いに多くの時間と労力を費やしました。


## 教訓としての反省
この経験を通じて、私は自分自身の過去のコードを振り返る機会を得ました。
そして、ある衝撃的な真実に気付かされたのです。
私の書いたコードも、他人にとって読みづらく、理解しにくいものだったという事実です。
過去に私が書いたコードを見返すと、その複雑さに自分でさえ頭を抱えてしまいます。
目先のリリースに追われ、コードの質よりも速さを優先してしまった結果、無秩序で理解しづらいコードが生まれていたのです。
その当時の私は、リリースを最終目標と捉え、そのためには手段を選ばない状況でした。
その結果、コピペされたコードの断片が乱雑に組み合わされ、それらがどのように機能しているのか、後から振り返っても理解するのが困難でした。
今思えば、このような状態でコードを書いたことに深く後悔しています。
コードは単なる文字列の羅列ではなく、未来の自分や他のエンジニアが読み解き、利用するためのもの。
その重要性を痛感しています。
このような過去の経験から、私は今後はより慎重に、そして他人が読んで理解しやすい「綺麗なコード」を書くことを心掛けています。
開発プロセスの中でリリースは確かに大切ですが、それに至る過程の品質も同様に重要だということを、私はこの経験を通じて学びました。


## まとめ
汚いコードは、開発の意欲を削ぎ、バグの温床となり、プロジェクト全体を停滞させます。
私は今、コードをただ書くのではなく、読みやすく、理解しやすく、そして保守しやすい「綺麗なコード」を心がけています。
これは単なる技術的な問題ではなく、共同作業者への思いやりでもあるのです。
【Flutter】TextFieldがなぜか表示されない

# 起こったこと
タイトル通りですが、TextFieldがなぜか表示されない現象に悩まされました。
以下にそのコードを示します。
```dart:
class Test extends StatelessWidget {

  Test();

  @override
  Widget build(BuildContext context) {
    return Scaffold(
        appBar: AppBar(
          backgroundColor: Theme.of(context).colorScheme.inversePrimary,
          title: Text("テストウィジット"),
        ),
        body: Center(child:
        Row(
          children: [
            TextField()
          ]
        ))
      );
  }
}
```
このウィジットを表示しようとするとVisual Studio CodeのCALL STACKに関数の呼び出し履歴が表示されて、エラーが発生しているっぽいんだけど、何が原因なのか表示されていないので詰んでました。が、なんとなく、レイアウトの配置系でエラーが出ているっぽいことは雰囲気から分かりました。

# 解決策
レイアウト関連でエラーをあさっていたらジャストヒットな[コメント](https://stackoverflow.com/questions/51809451/how-to-solve-renderbox-was-not-laid-out-in-flutter-in-a-card-widget)を見つけました。
簡単に説明するとRowは水平方向に無限に広がり, TextFieldも無限に水平方向に広がる。そのため、TextFieldのwidth方向に制約を与えないとだめということらしいです。ということで、下のようにContainerを使って、widthを制限したらうまく動きました。Flutterムズカシイ...。
```dart

class Test extends StatelessWidget {

  Test();

  @override
  Widget build(BuildContext context) {
    return Scaffold(
        appBar: AppBar(
          backgroundColor: Theme.of(context).colorScheme.inversePrimary,
          title: Text("テストウィジット"),
        ),
        body: Center(child:
        Row(
          children: [
            Container(width:100, child:TextField())
          ]
        ))
      );
  }
}
```