OmniAICreator/Qiita-1.07M huggingface dataset:
kotlin入門その１

この記事は、[【完走したい】楽しくいろいろやる Advent Calendar 2023](https://qiita.com/advent-calendar/2023/notbeginner)の16日目の記事になります。
AndroidStudioを使って作りたいものができたので、まずはjavaとkotlinを学んでいきたいと思います。javaとkotlin、そのほかの言語との違いとかも書けたらいいなと思っています。
# kotlin
kotlinは、javaの改良版のようです。
androidアプリを開発するための言語で、javaよりも使いやすくなっているらしいです。kotlinそれ自体はjavaと互換性がないようです。
# 使ってみる
VisualStudioCodeではそのまま動かすことができないので、kotlinが実行できるwebサイトを使います。
https://play.kotlinlang.org/#eyJ2ZXJzaW9uIjoiMS45LjIxIiwicGxhdGZvcm0iOiJqYXZhIiwiYXJncyI6IiIsIm5vbmVNYXJrZXJzIjp0cnVlLCJ0aGVtZSI6ImlkZWEiLCJjb2RlIjoiLyoqXG4gKiBZb3UgY2FuIGVkaXQsIHJ1biwgYW5kIHNoYXJlIHRoaXMgY29kZS5cbiAqIHBsYXkua290bGlubGFuZy5vcmdcbiAqL1xuZnVuIG1haW4oKSB7XG4gICAgcHJpbnRsbihcIkhlbGxvLCB3b3JsZCEhIVwiKVxufSJ9
とりあえず"Helo world"出力します。
とも思っていたら、既に入力されているようです。
このまま動かすと、ちゃんとHello, world!!!と出力されていました。
# 仕組み
```
fun main() {
    println("Hello, world!!!")
}
```
### fum main 
javaのclassみたいなものでしょうか。
{}でくくった中に必要な処理を書いておけば、それが実行されるようです。
### println("Hello, world!!!")
javaでこんな感じのものを見ました。
javaと違うのは、System.out.の部分がないことでしょう。
個人的に、printlnとだけ書かれているこちらのほうが何が行われるか直感的に理解しやすいような気がします。
# その他
### if
kotlinでは、ifはC#と同じように()で条件をくくって、その後実行したい処理を{}で結ぶようです。
試しにAを用意して、Aに10を入れました。
正しければ"正しい",
間違っていれば"正しくない"と出るようにしました。
```
fun main(args: Array<String>) {
   
   	var A=10;
    if(A==10){
        println("正しい");
    }
    else{
        println("正しくない");
    }
 }
```
intが使えないっぽいです。varで代用しました。
それ以外は、C#とほぼ変わりありませんでした。
# for
pythonのように、条件にinを用いるようです。
試しに、10回ランダムな値（1から10）を出します。
ちなみにランダムは、range.random()で整数を出せるようです。
C#は逆でrandom.range()だったはずなので何となく似ています。
```
fun main(args: Array<String>) {
   for(x in 1..10){
       var A=(1..10);
       println(A.random());
   }
 }
```
こうなりました.
varのほかに読み取り専用のvalがあるそうです。
# まとめ
知っている言語とほぼ同じなのは学びやすくて便利だと感じました。
kotlin使ってみると意外と楽しいですね



参考

https://hnavi.co.jp/knowledge/blog/kotlin-development/

https://atmarkit.itmedia.co.jp/ait/articles/1712/08/news010.html

https://www.sejuku.net/blog/101224

https://hirauchi-genta.com/kotlin-for/
Microsoft Edgeの閲覧履歴をエクスポートする(Windows, Mac対応)


## はじめに

インターネットブラウザの閲覧履歴を見返していると自分の人生を振り返ってるみたいで楽しいですよね。
私の場合はChromeの履歴が2013年からのものが残っていましたが、
それ以前はIEやFireFoxなどを使っていたので残念ながら残っていませんでした。


他のブラウザについては以下の記事でまとめています。
- Google Chrome

https://qiita.com/MURAMASA2470/items/d081e71d79c4dc36671e

- Apple Safari

https://qiita.com/MURAMASA2470/items/c29a9209c0d80956d913

## OS毎の履歴データの保存場所

履歴データは以下のディレクトリにあります

```
// Windowsの場合
~\AppData\Local\Microsoft\Edge\User Data\Default\

// Macの場合
~/Library/Application\ Support/Microsoft/Edge/Default/
```

この中に`History`というファイルがあるので、それがEdgeの履歴データになります

## sqlite3のインストール

履歴データの閲覧には、`sqlite3`が必要です。
まだインストールされていない方は、以下の記事を参考にインストールしてください。

https://neko-py.com/sqlite-install

## 履歴データの中身を確認

それでは以下のように進めていきます

```
// Windowsの場合
> cd '~\AppData\Local\Microsoft\Edge\User Data\Default\'

// Macの場合
> cd ~/Library/Application\ Support/Microsoft/Edge/Default/

// sqliteの中に入る
> sqlite3 History

// テーブル一覧の表示
sqlite> .tables
```

`History`の中には以下のようなテーブルがあります

| テーブル名 |
|:--|
| downloads |
| download_url_chains |
| meta |
| urls |
| keyword_search_terms |
| segments |
| segment_usage |
| visits |
| visit_source |

今回は訪問時間も欲しいので`urls`と`visits`を結合して使います
`urls`と`visits`の構造は以下のようになっています

| urls | visits |
|:----|:----|
| id | id |
| url | url |
| title | visit_time |
| visit_count | from_visit |
| typed_count | transition |
| last_visit_time | segment_id |
| hidden | visit_duration |
| favicon_id | |

## 履歴データを抽出してみる

今回は`csv`形式で出力しますが、他にも以下のようなものもあるそうです

|mode  |説明   |
|:-----|:-----|
|csv      |カンマ区切りで出力|
|column   |カラム毎に左揃えで出力|
|html     |HTMLのTABLE形式で出力|
|insert   |INSERT文として出力|
|line     |各カラム毎に行を分けて出力|
|list     |区切り文字でカラムを区切り1行で出力(デフォルト)|
|tabs     |タブ区切りで出力|
|tcl      |TCLのlist形式で出力|

それでは実際に出力していきます
※`visit_time`がUNIXタイムもどき(1601/01/01 0:00 からのマイクロ秒)になっているので一般的な形式に変換しています

```
// .mode [モード名] でモード指定
sqlite> .mode csv

// .output [ファイル名].csv でファイル名指定
// 今回はユーザーのホームディレクトリに保存
sqlite> .output ~/result.csv

// ヘッダーをつける
sqlite> .headers on

// 抽出
sqlite> select urls.id, datetime(visits.visit_time/1000000-11644473600,'unixepoch','localtime') as visit_time, urls.title, urls.url from visits left join urls on visits.url = urls.id order by visits.id desc;
```
抽出で使用したSQLの内容は以下のようになっています

```sql
select 
 urls.id,
 datetime(visits.visit_time/1000000-11644473600,'unixepoch','localtime') as visit_time, 
 urls.title, 
 urls.url 
from visits 
left join urls 
 on visits.url = urls.id 
order by visits.id desc;
```

sqliteを抜けるとホームディレクトリに`result.csv`というファイルができています。

もし`Error: database is locked`と出たら一度Google Chromeを終了してから、もう一度試す、
もしくは、Historyファイルを別名でコピーしたものに対して実施してみてください。

以上です。
１０％の確率でドオーしか表示されないポケモン生成サイトを作った

# 背景

PokeAPIを使ってみた一心から始まり、ポケモンをランダムに6匹表示するサイトを考え始めた。

作成中にランダムでポケモンを表示していると、あまりにもドオーが可愛すぎたので一定の確率でドオーしか表示されないポケモン生成サイトにすることにした。

可愛くないですか？？？
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3351724/792ada1d-8e6f-c016-e326-0db65cc2f079.png)

# 目的
- PokeAPIを使ってみる
- Next.jsの勉強を軽くしたので、AppRouterを使用してAPIを叩く
- なんちゃってレスポンシブデザインを実現する

# できたもの

poketter(https://poketter.vercel.app/)

https://github.com/Suntory-Y-Water/poketter

# 感想と考慮したところ

## ポケモンSVで内定しているポケモンに絞った
なにかのバグで`ランダムでポケモン育成してみようぜ!!!`みたいなことが起きたとき、内定しているポケモンだと決めるのが楽かなと思った。
最新のDLC(12月配信)には対応できていませんが、一個前のDLCには対応できています。

## 10%でドオーは光る

10%引いたあと更に10%引くと嬉しくなりますね！！！！

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3351724/c1f7e2ab-125c-665d-1b1b-de2468652ed3.png)

## 画面デザインとレスポンシブデザイン

画面の色やUIについては事前にFigmaで設計をしました。
検討当初のボタンがそのまま入っていたりしますが...

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3351724/3f86a012-9861-7218-5d3f-8c77518110f3.png)

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3351724/498b5e63-4fdd-17c9-78e3-7790d9026104.png)

ボタンの色や背景色、カラーコードなどはピカチュウ大先生を連想しながら`coolors`で見つけて実装しました。

https://coolors.co/

# 最後に

本当はドオーしか出なかったときにアニメーションをつけようと思ったけど、画面負荷が高くなるとのいい感じのアニメーションが思いつかなかったのでボツになりました。

またなにか思いついたら作ります。
おわり。
PHPでスクレイピングしてみる(Simple HTML DOM Parser 使用)

PHP のスクレイピングで楽に使えそうなライブラリ PHP Simple HTML DOM Parser を使ったときのメモ
PHP Simple HTML DOM Parser だと CSSセレクタで要素指定できるのがありがたい
ライブラリなくてもスクレイピング出来そうだったけどPHPも初心者だったからか xpath が使いづらかった．．．

PHP Simple HTML DOM Parser の公式のドキュメント？、ライブラリとかのリンク先
- ドキュメント [Simple HTML DOM documentation](https://simplehtmldom.sourceforge.io/)
- ライブラリ取得 [SourceForge - PHP Simple HTML DOM Parser](https://sourceforge.net/projects/simplehtmldom/)

実施した環境はこんな感じ
- Windows11
- XAMPP Windows 7.4.27
- PHP Simple HTML DOM Parser v1.9.1

# ライブラリ取得・配置
1. SourceForge よりダウンロード
    https://sourceforge.net/projects/simplehtmldom/
1. ダウンロードしたデータより`simple_html_dom.php` を取得
1. XAMPP の htdocs の下に配置（フォルダ作っておいてもOK）
    ※スクレイピングする実行ファイルから読み込むのでこだわりなければ実行ファイルと同じフォルダが楽そう

# スクレイピングするファイル作成

## `simple_html_dom.php` の読込

```PHP
require_once "simple_html_dom.php"; //ファイルパスは置いた場所にする
```

## html 読込 `file_get_html(url)`
```PHP
$html = file_get_html('https://exampl/sample.html');
```

## 要素取得して情報表示 `$html->find(CSSセレクタ)->取得情報`

```PHP
$html = file_get_html('https://qiita.com/');

// find した1件目の情報表示
$h2text = $html->find('h2')[0]->plaintext;
echo $h2 . '<br>';

// find した全件の情報表示（ループ処理）
foreach($html->find('h2') as $node){
  $value = $node->plaintext;
  echo $value . '<br>';
}

```
## 参考 スクレイピングした結果をJSONで返すAPI

```PHP
<?php
  // simple_html_dom 読込
  require_once "simple_html_dom.php";
  // html 読込
  $html = file_get_html('https://qiita.com/');

  // json にする情報の設定 (h2タグとってテキストとリンク設定)
  $arrays = array();
  foreach($html->find('h2') as $node){
    $h2 = $node->plaintext;
    $href = $node->firstChild()->href;
    array_push($arrays, ['h2'=>$h2, 'href'=>$href]);
  }

  // JSON レスポンス設定
  header("Content-type: application/json; charset=UTF-8; Access-Control-Allow-Origin: *");
  echo json_encode($arrays);
?>
```
ChatGPT製Slackbotを15分で作る

# 使用するサービス

## ChatGPT Assistants API
https://platform.openai.com/playground
Assistants APIとは、独自の知識を持ったGPTを作成できる機能です。
例えばナスの分類に関する論文をAssistants APIに与えれば、ナスの分類について詳しいGPTを作成できます。
同じようなものにGPTsがありますが、GPTsにはGUIが標準で備わっています。
Assistants APIはGPTsのAPI版だと考えてください。

## Make
https://www.make.com/en
Makeは様々な自動化処理をGUIで作ることが出来るサービスです。
私が知る限りでは最もUIが良く使いやすく、月1000リクエストまでは無料で利用可能です。
無料利用の間は会社のクレジットカードの登録が必要ないのも便利です。

## Slack
https://slack.com/intl/ja-jp
説明は不要ですね。業務用のチャットサービスです。

# ChatGPT Assistants APIの作成
1. [Playground](https://platform.openai.com/playground)の右上のCreateボタンを押し、モデルはgpt-3.5-turboを選択してSaveします。

![スクリーンショット 2023-12-22 23.36.00.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3616713/9c73324b-99d7-a4a1-2d04-be372a65f111.png)

2.一覧画面に作成したAssistants APIの名前とIDが表示されるのでメモしておきます。
![スクリーンショット 2023-12-25 12.58.42.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3616713/183f0de6-4a94-203a-94b1-b60c51439b97.png)

# Slackのチャンネルの作成

questionとanswerチャンネルをpublicで作成してください。

# Makeのワークフロー作成

1.[Make](https://www.make.com/en)に登録した後、右上のCreate a new Scenarioボタンを押すと、プラスアイコンが表示されるのでSlackを選択します。

![スクリーンショット 2023-12-22 23.40.17.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3616713/689ec01e-1562-5ea4-c37f-b15d9fd062c3.png)

![スクリーンショット 2023-12-25 13.03.00.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3616713/5fdde293-68c5-c64c-5e54-0eb12eee38c4.png)


2.Watch Public channelを選択しconnectionをクリックすると、先ほど作成したワークスペースが表示されるので選択し、チャンネルは先ほど作成したquestionパブリックチャンネルを指定します。

![スクリーンショット 2023-12-22 23.56.09.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3616713/ceab6ed0-079e-d3c2-28ff-7a4888c46b45.png)

3.右側の半円をクリックし、次の処理を追加します。OpenAIを選択し、画像のように入力してOKを押します。
![スクリーンショット 2023-12-23 0.00.24.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3616713/1ff26826-ddb2-517f-c1b5-78805546b03b.png)

4、さらに右側に、Slackのcreate messageを追加し、先ほどメモした情報を以下の画像のように入力します。
![スクリーンショット 2023-12-23 0.01.29.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3616713/1e6dc9cc-d62d-24cf-84c2-907610a65d32.png)

5.完成です。
左下のRun onceをクリックし、Slackのquestionチャンネルで質問してみましょう。
answerチャンネルに回答が返ってきます。

![スクリーンショット 2023-12-23 0.02.42.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3616713/72b66f31-435b-28ed-9016-24eb22cb1df1.png)

questionチャンネルで質問すると。。。
![スクリーンショット 2023-12-28 14.22.49.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3616713/650a7b42-7af8-becf-65d7-e84054337c9d.png)

answerチャンネルで回答が返ってきました！
![スクリーンショット 2023-12-28 14.22.25.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3616713/6487de64-1eac-e3a3-e803-e51cccacad0f.png)



# さらに加えて
MakeのSlackはスラッシュコマンドに対応していないので、スラッシュコマンドを使いたい場合は、MakeのWebhookの利用がおすすめです。
MySQLのストアドプロシージャで「ERROR 1137： Can't reopen table： 'table_name'」が発生した際の回避策


# はじめに

Mysqlでストアドプロシージャを作成している際に、以下のようなエラーを見たことはありますでしょうか。
少々パワープレイにはなりますが、今回紹介する方法で解決は出来たので、その回避策を3つ紹介します。
それぞれメリット/デメリットを記載しているので、参考にしてください。

```
ERROR 1137: Can't reopen table: 'table_name'
```

## エラーが起こる理由

Mysqlの公式で以下のように記載されています。
> 同じクエリで TEMPORARY テーブルを複数回参照することはできません。

ストアドプロシージャでは、全体が1つのクエリとして扱われる為、1つのストアドプロシージャ中では、一時テーブルは1度しか参照出来ないことになります。
`FETCH CURSOR`などループ中で繰り返し参照する場合については、1回とカウントされるようです。

https://dev.mysql.com/doc/refman/8.0/ja/temporary-table-problems.html


## 一時テーブルとは何か

`CREATE TEMPORARY`で作成されるテーブルのことを一時テーブルと呼びます。
この一時テーブルは、コネクションのセッション毎に保持され、基本的にクエリが終了すれば自動的に削除されます。
また、セッション毎に保持している為、たとえ異なるユーザー間で同時に同名の一時テーブルを作成したとして、別物として扱われます。


# 回避策

## 回避策1. 一時テーブルを永続テーブルで置き換える

同一クエリ内で複数回参照出来ないのは一時テーブル固有の仕様の為、いっそのこと永続テーブルに変えてしまう というものです。
これによってエラー自体は発生しなくなりますが、以下のようなメリット/デメリットがあります。

### メリット

- 今回紹介する中では一番簡潔に書ける

### デメリット

- ゴミデータが残らない様に`DELETE`やトランザクション制御をする必要がある
- 複数ユーザーの同時使用を想定する場合、操作するレコードが被らない様にレコードにユーザーを特定するカラムを増やすなどする必要がある

```sql
CREATE TEMPORARY TABLE `table_name` ();

-- ↓

CREATE TABLE `table_name` ();
```

## 回避策2. 一時テーブルをサブクエリに置き換える

こちらは、一時テーブルを作成することなく、参照の度にサブクエリを書いてしまおう というものです。
この方法でもエラー自体は発生しなくなりますが、以下のようなメリット/デメリットがあります。


### メリット

- 一時テーブルを使わなくて済む

### デメリット

- 呼び出し回数が多ければ多いほどパフォーマンスが悪化する

```sql
CREATE TEMPORARY TABLE `tmp_table` ();

INSERT INTO `tmp_table` VALUES(....);

SELECT * FROM `tmp_table`;

-- ↓

-- 一時テーブルを経由せずに、サブクエリで直接取得
SELECT * FROM (
  SELECT * FROM `sub_query`
) AS tmp_table;

```

## 回避策3. 一時テーブルの複製

こちらは使用する箇所の分、一時テーブルを複製する というものです。



### メリット

- 今回紹介する中では、一番パフォーマンスが良い

### デメリット

- 使用回数が多ければ多いほど、複製個数も増え、SQLが汚くなる


```sql
-- テーブル定義を複製 ※この時点ではレコードは複製されていません
CREATE TEMPORARY TABLE `table_name` LIKE `複製元の一時テーブル`;

-- レコードの複製
INSERT INTO `table_name` SELECT * FROM `複製元の一時テーブル`;

-- 使用する回数分、↑の処理を実施する
```

# 参考

https://stackoverflow.com/questions/47658432/error-1137-cant-reopen-table-when-joining-a-temporary-table
MATLABでscatterを用いてプロットした際に凡例が複数生成されてしまう現象について

## scatterで凡例がめっちゃ生成される問題
例えば以下のコードを実行した際，図1に示すようにすべての点についての凡例が生成されてしまう．

```
%Sample code1
Xdata=0:1:5
scatter(Xdata,1,"red",'Displayname','Data1')
legend()
```
```plantuml
@startuml
<style>
root {
  Padding 0
  Margin 0
}
footer {
  FontColor black
  FontSize 17
}
</style>
footer 図１　Sample code1 実行結果
title <img:https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1021699/21412cd3-226d-5286-36ec-cc88cca38477.png>
@enduml
```
しかし，ほとんどの場合，凡例は一つの系列に対して一つであってほしいと思う．
これを得るためには，以下のようにキチンとYDataについても指定すればよい．
```
%Sample code2
Xdata=0:1:5;
YData=ones([1,6]);
scatter(Xdata,Ydata,"red",'Displayname','Data1')
legend()
```
```plantuml
@startuml
<style>
root {
  Padding 0
  Margin 0
}
footer {
  FontColor black
  FontSize 17
}
</style>
footer 図１　Sample code2 実行結果
title <img:https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1021699/25a613a6-7cae-128a-905f-a63a5f2c247e.png>
@enduml
```
## 凡例がめっちゃ生成される原因
どうやら，Ydataを指定しない場合，XdataのそれぞれについてScatterオブジェクトが生成されることが原因であるようだ．
```
%Ydataを指定しない場合
s1=scatter(Xdata,1,"red",'Displayname','Data1')
```
```
%実行結果:6つのScatterが出来る
s1 = 
  1×6 Scatter 配列:
    Scatter    Scatter    Scatter    Scatter    Scatter    Scatter
```
```
%Ydataを指定する場合
s1=scatter(Xdata,Ydata,"red",'Displayname','Data1')
```
```
%実行結果:単一のScatterが出来る
s1 = 
  Scatter (Data1) のプロパティ:
             Marker: 'o'
    MarkerEdgeColor: 'flat'
    MarkerFaceColor: 'none'
          LineWidth: 0.5000
              XData: [0 1 2 3 4 5]
              YData: [1 1 1 1 1 1]
           SizeData: 36
              CData: [1 0 0]
```
---
MATLABの公式リファレンス(https://jp.mathworks.com/help/matlab/ref/scatter.html) には次のように書かれています．

"すべてのセットが同じ x 座標または y 座標を共有している場合は、共有している座標をベクトルとして、その他の座標を行列として指定します。ベクトルの長さは行列の次元の 1 つと一致していなければなりません"

つまり，今回の場合ではY座標がすべて1で共通であるとして，Xdataのセットについてプロットしたということになります．
Laravel10で制作したWebアプリケーションをLaravel8にダウングレードした話

## はじめに
はじめまして。　　
今回は卒業研究用に制作したWebアプリケーションが本番環境に適合しなかったためにダウングレードを行ったので、その手順周りを説明したいと思います。
転じてこのように開発中にバージョン変更を余儀なくされた方への対応策を提案できればと思います。

## アプリケーション概要
スライダーで日記のスコア管理ができるものを用意しました。
セキュア化できたら一般公開予定です。

## 起こった内容
- 卒業研究にLaravelを利用したアプリケーションを制作
- 手順を確認し、開発用のPCで開発完了
- 本番環境に載せようとしたところエラー発生
- PHPのバージョンを確認すると対応外であることが判明

## 開発バージョン(ローカル)
| 名前 | バージョン |
| ---- | ---- |
|MANP|6.4 |
|Apache|2.4.54|
|PHP|8.2.0|
|MySQL|5.7.39|
|Composer|2.5.8|
|Laravel Framework|10.14.1|

## 本番環境
| カテゴリ | ソフトウェア名 | バージョン |
| ---- | ---- | ---- |
|ソフトウェア|Apache|2.4.54|
|言語|PHP|7.4.33|
|データベース|MySQL|5.7.39|
|フレームワーク|Laravel Framework|8.8*|

## 対応策
### 【共通】
- "{技術名}_{バージョン名}"で検索をかけ、各バージョンでどのようなことが変更点になるのかチェックする。

### 【Laravelの場合】
- Langファイルや記法の変更、PHP8.1以上からPHP7.*にダウングレードすること
    - 従ってPHPも8系と7系で変更された内容を扱う場合には同様に該当部分を書き換える必要あり。
- Viteが使用できずLaravel Mixで書き換える必要あり。
#### 参考コード例
```php:Laravel10:app.blade.php
<head>
    
    `【割愛】`
    
    <!-- Scripts -->
    @vite(['resources/sass/app.scss', 'resources/js/app.js'])
</head>
```

```php:Laravel8:app.blade.php
<head>
    
    `【割愛】`
    
    <!-- Scripts -->
    <link rel="stylesheet" href="{{ asset('css/app.css') }}">
    <script src="{{ asset('js/app.js') }}" defer></script>
</head>
```
- 様々な要素を調査した結果、表示部分に問題が有りエラーが起きることが判明。
- プロジェクトを制作し直して該当コードを書き換えることで本番環境への対応ができました。

## 反省
- イレギュラーが起きた際に、残りの期間からスケジュールを再構成することが必要
- **要件定義で本番環境のバージョンまで確認しましょう。**

## 最後に
この記事を閲覧していただきありがとうございます。  
バージョンは大切です。動かない機能やメソッドなど違いが溢れているので公式ドキュメントや先人の記事などを確認して変更すべき箇所をまとめ、時間を取らずリファクタリングを目指していただければと思います。
~~元からバージョン間違えないのが一番早い~~
Arduino UNO R4 Wifi でできること

## Arduino UNO R4 wifi で何ができる？

### Ⅰ. ArduinoArduino UNO R4 wifi はここが違う
#### ① Renesas 32bitマイコンRA4M1(Arm Cortex-M4)！
国産半導体メーカー ルネサス製マイクロコントローラ搭載
＋ R3と比較してメモリ16倍・クロック速度3倍
↓↓↓
計算速度が圧倒的に向上→単純計算ならば（R3に対して）50倍
より複雑な処理をスムーズに行えるようになった

#### ② Espressif ESP32-S3（技適取得済） 追加！

　→ Wi-Fi Bluetooth(802.11 b/g/n Bluetooth 5)による無線通信可能
     　↑ 専用ヘッダを経由してプログラム可

Wifi,Bluetoothに直に接続できるようになった為Arduino IoT Cloudと連携し遠隔制御が可能

※技適マークは箱に記載されていて、保管していないと電波法に抵触する恐れもある

<img width="500" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3659587/f6d740ed-34ef-3803-d779-e07cffa80d23.jpeg">

#### ③ 12×8 赤色LEDマトリクス VRTC・OFFピン 搭載！
個人的にはUSB-Cコネクタが備わったことが大変ありがたい
最大24Vでの電源供給も可能で、単一電源による高出力プロジェクトでも使用可能
スイッチングレギュレータを使用することにより
R3で40%だった効率を70%まで引き上げることに成功した
（若干のノイズ増加が見られるが許容範囲）

#### 
<img width="500" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3659587/f071b743-15e2-3d9c-f1a2-c756f67536bc.jpeg">


### Ⅱ. RTC(リアルタイムクロック)で性能チェック
#### ① 「めちゃくちゃ楽」
一言で言えば、楽すぎる！
Wi-FiモジュールもBluetoothモジュールも要らないというだけで、こんなにラクだとは…

<img width="500" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3659587/764c45c0-0082-5b00-389c-a15ada5c1959.gif">

#### ② パソコン接続ナシ・Arduino単体での制御も可能に
電源供給のみで運用できる、IoTへの活用が容易に

## Ⅲやってみたいこと

今までは上記のように面倒な作業が多かったためあまり手を出せていなかったが
ブラウザ上に表示したボタンからLEDを光らせることもできたので、ブラウザ経由で
遠隔操作ができるマシンを何かしら作ってみたい。
【GitHub】クエリパラメータを使用してIssueを作成する方法

以下のようにURLのクエリパラメータを使用してIssueを作成できます。

```
https://github.com/sample/example/issues/new?title=TEST&body=test
```

上記のようにした場合にはタイトルが`TEST`で本文が`test`のIssueが作成されます。


他にも`label`などをクエリパラメータを使用して設定することができます。

https://docs.github.com/ja/issues/tracking-your-work-with-issues/creating-an-issue#creating-an-issue-from-a-url-query
VSCode+Copilotにコミットメッセージも任せられるように

この記事は[ディップ Advent Calendar 2023](https://qiita.com/advent-calendar/2023/dip-dev)の24日目の投稿です。


## はじめに
メリークリスマス！ディップ システム基盤課のまちながです。

さて、少し前からVSCodeで**AIにコミットメッセージを生成させる事が出来るようになった**ようです。
Copilotの拡張機能が有効になっていて、Copilotが使えれば使えるようです。

コミットメッセージの欄にきらきらボタン(これなんて言うの？？)が登場してました。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3638052/164ed952-8ca6-54f4-6904-3c45c0e76ab1.png)

## 試してみた
きらきらボタンを押すとCopilotがメッセージ欄を埋めてくれます。


- READMEの追加
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3638052/da651718-7b16-8685-9d1e-d983fba2e12d.png)
こんなんだったら自分で書けって話ですね...
<br>

- TerraformのVPCmoduleをまるっとコミット
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3638052/2244dc36-277c-b3d5-10f1-ae7451184ee9.png)
いいですね。
<br>

- クイックソート関数
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3638052/393a78a0-4c26-3f7f-f730-bc5ebc9d5e5b.png)
ちなみにクイックソートのプログラムもCopilotに書いてもらいました。
コードの中も見てコミットメッセージを生成しているようですね。

## まとめ(というほどでもないが？)
コミットメッセージのフォーマットが決まっていたり、日本語で書く決まりだったりする場合、多少手直しが必要ですが、メッセージを考える時間はかなり削減されそうです。

コミットメッセージを書くのが苦手な自分は泣いて喜ぶ機能です。
[Udemy網羅系]ドキュメント一読後におすすめJavaScript講座


## はじめに
とある工業大学1年生の@ko_y0205です。
現在Webアプリケーションメインで学習しており、まとめるついでに皆様に私的おすすめUdemy講座を共有できたらと思います。
基本的に私は、ドキュメントを読んでから動画で内容を確認する勉強法が合っていたため、初学者からでも入りやすく、また復習したい方におすすめとなっています。


Qiita様もこれが初投稿で勝手が分からず読みにくいところがございますが温かい目でご覧ください。

:::note warn
あくまで私個人的なおすすめ講義となっております。
:::

## 講義概要
| 項目 |概要| 
|:-----------:|:------------:|
| タイトル | はじめてのJavaScriptプログラミング入門    | 
| レクチャー数    | 88     | 
| 総動画時間  | 6.5時間      | 
| 学習環境    | macOS または Windows          |   
| ツール    | Google ChromeとVisual Studio Code    |
| 学習時間   | 合計12時間（メモをとりながら）    | 
|価格　|セール時￥1,800-|

動画リンク
https://www.udemy.com/share/101BA23@ZMK-ggi3i_gs5A_G6YWK0Sc4rk9z3ppkVSzv7z9tuWaN6tZy_5M4bErycfZAl35p4g==/

## おすすめ理由
JavaScriptの内容が細かく短い動画に分かれており、全て順番に受けるのもいいし、ドキュメントで理解した気になっている項目をピンポイントで受講する事ができる点。
また、シンプルにまとめられいて視聴者が理解しやすいことに重点がおかれているため、JavaScript初学者だけでなくプログラミングに初めて触る方でも世界観を理解する事ができます。

## 勉強法
私は講義とvscodeとメモ帳を開き、自分のビビッとした内容だけメモしていました。
しかし、メモしすぎて400行超えていましたが（笑）
アウトプット大事にしているので、自分の言葉でまとめるのはとても大事だと感じます。

## まとめ
今回は簡単に私的おすすめJavaScript Udemy講座を紹介しました。
是非動画で勉強したいけど迷っている未来の希望の方々は是非参考にしてみてください。
機会があれば次はReactのおすすめ講座を紹介したいと思います。
世界一流エンジニアの思考法 感想

[世界一流エンジニアの思考法](www.amazon.co.jp/dp/4163917683)を読みました。

## 全体的な感想
一流のエンジニアでも理解に時間がかかることであったり、単に記憶力が良いというわけではなく深く理解した結果の記憶なんだということがわかって安心しました。
また7章は特に牛尾さんが言いたいことが書いてある章だと感じました。

単に一流のエンジニア個人について書いてあるだけでなく、チームビルディングや文化についても触れられていて、エンジニアとして生産性を上げるための様々な観点が書かれている本です。

特に目を引いたところの抜粋と、感想を書いていきます。

## 第1章 世界一流エンジニアは何が違うのだろう？

- 試行錯誤は悪
    - 手を先に動かさず、仮説を立ててアプローチを選定してから動く
- 頭が良くても「理解」には時間がかかる
    - 頭のいい人が理解が早いように見えるのは時間を書けて基礎を積み重ねているから。
    - 理解とはその構造をつかんで人に説明できて、いつでもどこでも即座に取り出して使えて、知見を踏まえて応用が効くこと。


### 感想

「試行錯誤は悪」は誤解を招きそうな表現だが、牛尾さんが言いたいのは仮説を立ててから行動したほうがよいということ。データ分析にせよ施策を打つにせよ、いくつかの仮説を用意してその中で筋の良さそうなものから検証していくというアプローチが有効で腹に落ちる内容だった。

理解が早いように見えるのは基礎を積み重ねているから。これにはコピペエンジニアになることのだめなところが端的に現れていると思う。短期的に成果が出せるように思えても積み重ねが浅いから長期的に見て生産性が下がってしまう。
自分は仕事が忙しい時でもドキュメントをよく読み込むのでそれで良かったんだと思えた。（ものすごく忙しいときはあまり読めてないけれども）
生成 AI のコードを使うとしても、あくまできっかけ程度に考えて自分で調べて理解を深めていきたい。

## 第2章 アメリカで見つけたマインドセット

- 怠惰であれ。
    - つまりより少ない時間で価値を最大化すること。
    - いかにやることを減らすか。
- リスクや失敗を快く受け入れる。
    - やらないことのほうがリスク。
- 納期は絶対ではない。

### 感想
この章はエンジニア個人よりもむしろマネジメント層が読むべきかもしれない。
開発をしていると無駄な報告、無駄な打ち合わせ、無駄なドキュメント、無理なスケジュールなど、無駄・無理を感じる瞬間がある。
日本人の傾向としてどうしてもリスクを避けたり納期は絶対という意識が強いように思えるが、かえって価値に繋がりにくくなる面があると思う。
価値に繋がらないのなら積極的に No と言いたいと思った。


## 第3章 脳に余裕を生む情報整理・記憶術
- 「アウトカム至上主義」が上達を阻害する
    - 成果を出すことを目標に働くのはコンサルタントにはマッチするがプログラマにはマッチしない。プログラマは細かい技術の積み重ねが勝負。
- 優秀なエンジニアの記憶力が良いのはよく理解しているから。
    - 自分がやったことをクリアに説明できるよう時間をかけて言語化すると理解が増す。
    - ブログを書いてみるなどのアウトプットがよい。

### 感想
1章の内容に通じるが、技術の積み重ねが大事なことがここでも書かれている。うちの会社はコンサルティングの会社なのでこのようなことが書いてあるとちょっと安心する。
自分は記憶力には自信がないものの、経験上自分の興味のあることに対してはよく記憶できる。これは興味の強さが直接の理由というよりは理解の深さの問題なのかもしれないと思った。

## 第4章 コミュニケーションの極意
- 情報量を減らすコミュニケーションが重要。
    - 質問が来たら追加説明すれば良い。
- 気軽に聞ける空気が大事。
    - 気軽に断れる空気とセット。

### 感想
コードの量は少ないほうが良いのと同じで、同じ情報を持つなら量は少ないほうがいいので共感できる内容だった。

## 第5章 生産性を高めるチームビルディング
- 現場のメンバーがどのように動くか考えて意思決定していくチームがソフトウェア開発に向いている。

### 感想
エンジニア個人の話というよりかはチームの話。個人的には他の本でも読める内容であんまり興味がわかなかった。

## 第6章 仕事と人生の質を高める生活習慣術
- 良い習慣を持つ
    - 瞑想する
    - 睡眠を取る
    - 筋トレするなど

### 感想
これも一般論なのであまりエンジニアには関係ないと思う。

## 第7章 AI時代をどう生き残るのか？
- 日本の批判文化によって開発者の心が折れてしまう。それがすべてをぶち壊しにする。

### 感想
ほんとうにそう。
牛尾さんの思いが一番こもっている章に思えた。
UiPath StudioでZoomの会議を予約してみた（プロパティ編）

## はじめに
①本記事は、2023年12月開催の「UiPath (produced with UiPath Friends) Advent Calendar 2023」の22日目のブログです。
ブログはまだまだ募集中:santa:以下よりぜひ登録してくださいね！

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

②このブログ情報は、2023/12時点の情報です。
③UiPathはCommunity Edition、Versionは2023.12を使用しています。

## 前回のあらすじ
アドベントカレンダー1日目の記事で、Studio版でZoonを予約するというものをやってみました。(以下記事参照)

https://qiita.com/saosao885/items/9f7f469445165e3553a1

その中で、この記事で紹介した「Schedule One-Time Meeting」アクティビティでプロパティが多いな～と思ったので、こちらを調べてみることにしました。

## Studioでプロパティを見てみると...
「Schedule One-Time Meeting」アクティビティのOutput(出力)側を見ると、以下のようになっています。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/502614/74621531-dcde-c20a-2536-f9214d4f9e1e.png)
1つひとつ見ていきましょう。

### パスワード
型：String
ミーティングのパスワード(Zoomだと6桁)が出力されます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/502614/87e9d489-d036-8b32-3088-ffaac684318a.png)
パスワードはお見せできませんが、ちゃんと6桁の英数字が出てきます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/502614/45c4bb07-113e-784c-6dc1-71584608bfa4.png)


### ミーティングID
型：Nullable(Int64)

ミーティングで使う11桁のIDが出力されます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/502614/9b7453c1-dda1-ddb8-7a5e-c087aac5f845.png)

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/502614/b3deb2c9-cfa5-b997-b775-e1d08654c020.png)
※個人情報等の観点で、一部マスキングしています。

### 暗号化されたパスワード

型：String
上記パスワードよりもっと複雑なパスワードが取得できます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/502614/0bd28989-850f-063a-ba65-793bcf886c99.png)
※個人情報等の観点で、一部マスキングしています。

### 開始URL
型：String
開始URLを取得できます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/502614/ec1dbcc9-19a6-7845-53aa-c15b61983c90.png)
※個人情報等の観点で、一部マスキングしています。

### 参加URL
型：String
対象の会議に参加する人向けの参加URLを取得できます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/502614/9d10f43b-0014-48cb-647e-237d7349e153.png)
※個人情報等の観点で、一部マスキングしています。

### ミーティング
型：me_sub_meetings_Create型
ミーティング情報を配列っぽい感じ？にまとめたものです。
(こちらは情報が少なく、もっと調査が必要です)

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/502614/4179a8c3-38a8-76bf-af2b-a8a3424dcfff.png)
※個人情報等の観点で、一部マスキングしています。
## まとめ

「me_sub_meetings_Create型」は初めて見る変数(引数)の型なので、調べてみても情報が発見できず...もう少し深堀りする必要がありますね。
次回はここで解説が漏れてしまった「追加フィールド」について解説していきます。
最後までお読みいただきありがとうございました。
AWS Backupの復元テストを試してみる

2023年11月27日にAWS Backupで復元テストの機能がリリースされたので触ってみました。

https://aws.amazon.com/jp/about-aws/whats-new/2023/11/aws-backup-restore-testing/

# AWS Backupとは
AWS内のリソースのバックアップ、リストアを一元管理できるサービスです。

https://docs.aws.amazon.com/ja_jp/aws-backup/latest/devguide/whatisbackup.html

EC2,RDS,S3,DynamoDBなどの様々なサービスに対応しており、これらのサービスのバックアップデータをAWS Backupで管理することによってバックアップ、リストアの運用負荷を軽減することが可能となっています。


# 復元テストプランの作成
既にAWS Backupで取得されているEC2のAMIを使用して復元テストを実施します。

復元テストを実施するにはまず復元テストプランを作成する必要があります。
AWSマネジメントコンソールのAWS Backupの画面左メニューから「復元テスト」を選択して「復元テストプランを作成」を選択します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/268065/36afec85-47af-f865-03c7-ee846f48b746.png)

「全般」で復元テストプランの名前やテストの実行頻度、開始時間を設定します。
開始時間に関してはバックアッププランと同じく設定した時刻に実行されない可能性もありますので御注意下さい。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/268065/00da7255-9354-132a-1d7d-9c1e06f8a7ab.png)

「回復ポイントの選択」でバックアップデータが格納されているボールトや復元テストに使用する復旧ポイント(=バックアップデータ)を選択します。
PITRでの復元テストを実行する場合は「PITR対応のリソースタイプをテストする際には～」のチェックボックスにチェックを入れます。
但しAWS BackupでPITRに対応しているのはS3,RDS,Aurora,SAP HANA on EC2のみとなるためこれ以外のサービスではPITRでの復元テストは実行できません。
設定が完了したら最下部の「復元テストプランを作成」を選択します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/268065/0c1f6073-61dc-771b-6790-09f36278e18b.png)


続いて復元テストを実行するリソースの設定を行います。
「全般」でリソース割り当て名、AWS Backupが復元テストを実行するためのIAMロール、復元したリソースを削除するまでの時間を設定します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/268065/a1e23ba7-0f37-4be0-9d36-d1c3a62da80b.png)

「保護されたリソース」で復元対象のAWSリソースを選択します。
今回はEC2を選択しました。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/268065/524c640a-f6ab-b98e-2bc2-236df681b2d8.png)

EC2を復元する場合はインスタンスタイプ、復元先のVPCとサブネット、セキュリティグループなどが選択できます。
設定可能なパラメーターが少々少ない気がするので、ここのパラメータは今後増えていくことに期待したいです。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/268065/905951f2-56d8-0ed7-599c-c8d4d18cb54d.png)

EC2の終了保護はデフォルトで無効化されていて有効化はできません。
各種設定完了後、最下部の「リソースを割り当てる」を選択すると復元テストプランの作成は完了です。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/268065/4883a2c4-b182-cdaf-9031-e7dbeef03dfd.png)


# 復元テストの実行確認
AWS Backupのジョブ画面から復元ジョブを選択すると実行履歴が確認できます。
「復元時刻」で復元(リストア)に要した時間も確認できますがこの時間はAWSとして保証しているリストア時間ではないためあくまで参考値として扱う必要があります。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/268065/3d006a36-ae80-fbf8-9be4-f3e9cefcc0a0.png)


簡単ではありますがAWS Backupの復元テストを試してみました。
この機能を使ってリストアとリストア先環境でアプリケーションの正常性確認を定期的に行うことにより実際に障害が発生した際にも自信を持ってバックアップからの復旧を行うことができそうです。
display:contens 要素にscroll-snap-typeが使えなかったので調べてみた

## これはなに

2022年ぐらいに、使えるようになったばかりの `display: contents;` を試してみたくて安易に指定したことがあります。
すると `scroll-snap-type` が思ったような挙動をしてくれなくなりました。
当時は実装を優先していたので、振り返りをまとめなかったのですが、原因を改めてまとめてみようと思います。

## `scroll-snap-type` とは

MDNによると下記の説明があります。

>`scroll-snap-type` はCSSのプロパティで、スナップ点が存在する場合にスクロールコンテナーにどれだけ厳密にスナップ点を強制するかを設定します。

https://developer.mozilla.org/ja/docs/Web/CSS/scroll-snap-type

## デモ

まずはデモをご覧ください。

<p class="codepen" data-height="300" data-default-tab="html,result" data-slug-hash="mdodBoE" data-user="gilly135" style="height: 300px; box-sizing: border-box; display: flex; align-items: center; justify-content: center; border: 2px solid; margin: 1em 0; padding: 1em;">
  <span>See the Pen <a href="https://codepen.io/gilly135/pen/mdodBoE">
  Untitled</a> by gilly135 (<a href="https://codepen.io/gilly135">@gilly135</a>)
  on <a href="https://codepen.io">CodePen</a>.</span>
</p>
<script async src="https://cpwebassets.codepen.io/assets/embed/ei.js"></script>

## やりたかったこと

`scroll-snap-type` を使って、横軸方向にスナップし、特定の位置にスナップが止まるようなUIをコーディングしようとしました。
UIはデモ01を参照してください。

なので、デモの `.scrollContents` に下記の記述をしました。

```css
.scrollContents {
  scroll-snap-type: x mandatory;
}
```

## やらかしたこと

実際にCSSスクロールスナップをしたかったUIは画像だったのですが、このときにデモの`.card` に `display: contents;` を指定しました。
冒頭にも述べましたが、当時使えるようになったばかりの `display: contents;` を試してみたくて、実験で使ってみた記憶があります。
すると `scroll-snap-type` が思ったような挙動をしてくれなくなりました。

## `display: contens;` とは

MDNによると下記の説明があります。

>これらの要素は自身のために特定のボックスを生成しません。擬似ボックスやその子ボックスで置き換えられます。

https://developer.mozilla.org/ja/docs/Web/CSS/display

ChromeのDevtoolのUIを借りて説明すると、 `display: contents;` は青い要素の部分だけになります。

![ChromeのDevtoolのスクリーンショット](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/215239/d881ff5c-c183-ebb0-f391-44b18dab60c9.png)

`margin`、 `border`、 `padding`がなくなります。
あと `background-color` もなくなります。

なので、`.card` の中身の数字だけが表示される要素となってしまいます。

## 考察

CSSスクロールスナップでは、 `scroll-padding` や　`scroll-margin` などのプロパティも存在します。
このことから、コンテンツのボックスが存在しなければ利用できないと考えられます。

`display: contents;` を指定したことで、コンテンツのボックスが存在しなくなったため、CSSスクロールスナップが機能しなくなったのだと思われます。

## まとめ

- `display: contents;` はコンテンツのボックスを生成しない
- CSSスクロールスナップするためには、コンテンツのボックスが必要

---
この記事が誰かのお役に立てると幸いです。



## 参考

- [scroll-snap-type - CSS: カスケーディングスタイルシート | MDN](https://developer.mozilla.org/ja/docs/Web/CSS/scroll-snap-type)
- [CSS スクロールスナップの基本概念 - CSS: カスケーディングスタイルシート | MDN](https://developer.mozilla.org/ja/docs/Web/CSS/CSS_scroll_snap/Basic_concepts)
- [display - CSS: カスケーディングスタイルシート | MDN](https://developer.mozilla.org/ja/docs/Web/CSS/display)
話すときに意識をしてみると少し気が楽になる話。

[Ateam LifeDesign Advent Calendar 2023](https://qiita.com/advent-calendar/2023/ateam-life-design) 23日目を担当するTakehiroです！

アドベントカレンダーもいよいよ大詰め、残りもあと少しとなってきましたね！
暖かかった12月のスタートも気づいたら年末を感じる季節になってきました。


# 話をする時に気を付けていることはありますか？

突然ですが、、、
皆様は(主に外部の方と) **お話をされる際に気を付けていること** はありますか？

自分自身、お仕事柄外部の方と話すことも多く、話をするときに気を付けていることがあります。

今回の記事では僕自身気を付けていることを少しだけご紹介をしようと思います。

:::note info
**▼こんなお悩みをお持ちの方に参考になるかも**
- 外部の方と話をするとき、何を意識していいのかわからない
- 話をする時に緊張してうまく話せない
- どういう話の組み立て方をしていいかわからない
:::

というお悩みを持っている方には参考になる記事かと思います。

拙い文章かと思いますが、ぜひお付き合いください。


# 今日の記事ではお話ししないこと

まず初めに本日の記事内では触れないことだけお伝えさせてください！

ここまで書き始めてしまうととんでもない量になってしまいそうですので、またの機会にしたいと思います！

本日の記事内ではできるだけ明日から使えるテクニカルなお話をしようと思います。
**提案資料の作り方**や、**言葉遣いのお話**などはしませんのでご了承くださいmm

# 色々なことを学んできて使えるなと思った会話のテクニック

新卒で自分は営業に配属をしていただき、
当時の上長の皆様から沢山のことを学びました。

その後も社会人をしている中で、沢山のことを経験し学ぶことがありましたが、この新卒のころに学んだことがずっと使えるテクニックだなと感じています。

まだまだペーペーの6年目ですが、一番効果があったなというのを紹介していきます。

大きく、4つです。

:::note warn
1. **数字で語る**
1. **話す順番を工夫する**
1. **見せるビジョンを使い分ける**
1. **大きい提案の後に小さい提案を**
:::

一つずつかいつまんでお話をしてみます。

### 1. 数字で語る

とっても当たり前ですが、最も大事なことです。
とにかく**すべて数字で説明できるよう**にしておきましょう。

ありとあらゆる数字を準備して持っていくようにしています。

数字は何よりも強い武器ですし、**唯一解釈の入らない誰が見ても変わらない事実**です。

この数字をどう調理するかは自分がどのような話をして、着地をさせたいか次第です。

グラフ化をするためにも、改善案を見せるためにも、何よりも数字が大事です。

逆に数字があれば、自信をもって話ができるはずです。


**とにかく数字を準備しましょう。**



### 2. 話す順番を工夫しましょう

俗に言うストーリーというものです。

自分自身、よく使うストーリーの展開は下記です。

1. 現状の把握と整理（相手と共通認識を取る）
2. 現状と理想とのギャップを整理（相手の課題を確認・共通認識を取る）
3. 課題に対する解決策の提案
4. これまでのサマリと上記の提案に対するギャップを埋める

この順番は比較的どんなことにも使えて汎用性が高いストーリー展開だと実感しています。

これを上記の**数字で準備することと掛け合わせ**て、**穴埋めをするように情報収集をしていく**ととてもいい会話になるはずです。


### 3. 見せるビジョンを使い分けてみましょう

会話をする際に、相手方にビジョンを見せるように話を展開していくかと思います。

上記の、課題の共通認識の部分やそれに対する課題解決もその一例です。

その中で、僕は見せるビジョンを選ぶようにしています。

主に2つです。
1. Goodな未来を見せる
1. Badな未来を見せる

**Goodな未来**というのは、
「〇〇なことをすれば、こんな良い数字になって、いい未来が待ってます！」という話の展開の仕方。

**Badな未来**というのは、
「〇〇をしないと、数字がこうなってしまって、こんな悪い未来が待ってます」という話の展開です。

この2つを相手方の特徴や立場を考えて使い分けて話をしています。

どんな方と話をするときにも相手を動かすきっかけとしてはいい手段になるはずです。


### 4. 大きい提案の後に小さい提案を

最後はよく聞く話かなと思います。

人はハードルの高い提案をされた後に、低い提案をされると、受け入れてしまう確率が高いといわれています。

[ドアインザフェイス（door in the face ）](https://mba.globis.ac.jp/about_mba/glossary/detail-11884.html)と呼ばれるものです。（参考：グロービス経営大学院より）

例えば、デートで例えると、本命としてランチやお茶に誘いたいとなった時には、一旦ディナーに誘ってみるというものです。

（※ランチとディナーでハードルが違うかどうかの問題は一旦おいておきますw）

本命となる通したい話に対して、少し高めのハードルの話を先に持ってくると、次点として出す本命の提案が通りやすくなる場合があります。

これは僕自身実感のあることが多かった事例です。

# おわりに

いかがだったでしょうか？
当然、世の中にはもっと沢山の会話のテクニックになるものがあると思います。

これらを活用すると、会話の準備や引き出しが多くなりますし、自分の話を組み立てやすくもなると思います。

準備ができれば、冒頭にお話ししたような下記の不安も少しは軽減できるかもしれません。

:::note info
**▼こんなお悩みをお持ちの方に参考になるかも**
- 外部の方と話をするとき、何を意識していいのかわからない
- 話をする時に緊張してうまく話せない
- どういう話の組み立て方をしていいかわからない
:::

自分自身、まだまだ勉強中の身ですし、できていないこともありますが引き続き学んでいければと思います。
【JointJS】Elementにクリック以外のイベントを処理させる

[以前の記事](https://qiita.com/acnaman/items/ba8a1dcb0a3cf812b7d9#element%E3%81%AB%E8%A8%AD%E5%AE%9A%E3%81%A7%E3%81%8D%E3%82%8B%E3%82%A4%E3%83%99%E3%83%B3%E3%83%88)で、Elementに対するイベントの設定方法をご紹介しました。
その中で、`event`属性をつけるとカスタムイベントを発行できることを紹介しました。

```js
joint.shapes.standard.Rectangle.define('example.MyRectangle', {
  size : { width: 100, height: 40 },
  attrs: {
    body: {
      stroke: "#999",
      fill: "#999",
      event: 'myrect:click',
    }, 
    label: {
      stroke: "#EEE",
      fill: "#EEE",
      'font-size': 4
    }
  }
});

paper.on('myrect:click', function() {
  console.log("クリックされました");
});
```

この`event`属性に設定したイベントはクリックイベント(正確には`mousedown` / `touchstart`イベント)のときにのみ発行されます。では、クリックイベント以外のイベントを処理させるにはどうすればよいのか、について紹介します。

## カスタム要素を作成してclassをつける

イベントを処理したい要素に対してclassを付与しておきます。

```js
joint.shapes.standard.Rectangle.define('example.MyRectangle', {
  size : { width: 100, height: 40 },
  attrs: {
    body: {
      stroke: "#999",
      fill: "#999",
      class: "myrect-body" // ←追加
    }, 
    label: {
      stroke: "#EEE",
      fill: "#EEE",
      'font-size': 4
    }
  }
}
```

## `addEventListener`を使用する

JointJSのElementであっても、`addEventListener`でイベントリスナーを追加することができます。JointJSの描画が終わった後であれば要素にアクセスできますので、前述のclassを利用してJavaScriptでイベントリスナーを追加していきます。

```js
const mouseoverFunc = function() {
  console.log("mouseover")
}

const myrects = document.getElementsByClassName("myrect-body");

for (i = 0; i < myrects.length; i++) {
  myrects[i].addEventListener("mouseover", mouseoverFunc);
}
```

## 条件等がある場合は`attr`に設定しておく

`addEventListener`を使用する方法だと、標準のJavaScriptのためJointJSの用意しているmodelにアクセスすることができません。これが`event`で発生させたイベントのイベント処理との差異となります。
これはデータ属性を設定することである程度の回避策を立てられます。
イベントの発生後に条件文などを扱う場合は、`attr()`メソッドを使用して条件に使用するデータをデータ属性に入れておくと、

```js
// データ属性に値を設定
const rect1 = joint.shapes.example.MyRectangle.create('四角形１', 10, 10);
rect1.attr('root/data-price', 300);

const rect2 = joint.shapes.example.MyRectangle.create('四角形2', 150, 10);
rect2.attr('root/data-price', 500);

// マウスオーバー時の処理
const mouseoverFunc = function(evt) {
  // データ属性を参照して条件を判定できる
  if(Number(evt.target.dataset["price"]) < 500) {
    console.log("セール中");  
  }
}

for (i = 0; i < myrects.length; i++) {
  myrects[i].addEventListener("mouseover", mouseoverFunc);
}
```

## まとめ

今回は`event`以外のイベントを処理するための小技を紹介しました。JointJSのAPI経由で処理できるイベントは他にもありますが、HTMLのイベントをそのまま使えるようにはなっておりません。HTMLから図を以降する際にJointJSのイベント処理でまかないきれないイベントが出てきてしまう場合は、今回のような方法での回避を検討してみてください。

※この記事は [JointJS Advent Calendar 2023](https://qiita.com/advent-calendar/2023/jointjs) の記事です。他の記事を読む場合はカレンダーのページを参照してください。

https://qiita.com/advent-calendar/2023/jointjs
スケジュール設定機能のための備忘録

 ## スケジュール設定機能をつくる
機能設計の話をします。
スケジュール設定機能を作ることになりました。
これで予実管理から報告書作成までできる優れもの（予定）です。

基本的には2つのことができれば、最低限の要件になるようです。
・情報の保存
・予定の繰り返し

 ## 最初の壁
予定の繰り返し機能を考えると、「無限」という壁に直面します。
「毎週」の予定を全てレコードとして作成すると、無限にデータをインサートしなければならないという問題です。
これにはざっくりと二つの解決法があります。

1. 2100年以降はレコードを作成しないなど、常識的な範囲に限る
2. 設計で何とかする

前者はシンプルで、実装も容易そうです。手元のスケジュールアプリを見てみると、2120年までしかデータが登録できないようになっていました。わりと常套的な手段のように思われます。

ここでは後者の方法を考えます。気持ちの問題です。システムの寿命を自分で決めるようなことはしたくないので、1万年経っても使えるような方法を考えます。

## スケジュールと実際の予定を親子関係にする案
スケジュール（例：毎月の第一日曜日に歯医者に行く）と、実際の予定（例：2024-01-07に歯医者に行く）を切り分け、前者を親・後者を子としてレコードを作成するという案です。

カレンダー上には親のスケジュールを元に表示し、各予定の詳細を保存して初めて、子レコードが作成されるようなイメージです。恐らくこういう設計だろうなというカレンダーアプリも結構見たことがあります。

子レコードは、日付をずらしたタイミングで親レコードから独立します（2024-01-14 に歯医者を一週ずらすなど）。親のスケジュールの表示ロジックから外れるためです。

基本的には問題なさそうですが、これから追加される要件を聞くと、暗雲が立ち込めてきました。

### ①途中でスケジュールが変わる
来年の5月からは、歯医者に行くのは3か月に1度だけで良くなるそうです。「スケジュール変更テーブル」を作れば対応できそうですが、既に独立した子レコードたちはどうすべきでしょうか。また、過去のデータにスケジュールの変更は反映すべきでしょうか。

### ②独立した子レコードに変更が反映されるのか分からない
次月から、別の歯医者に行くことになりました。この変更を未来の予定すべてに反映させたいのですが、せっかく独立させた子レコードに反映してよいものでしょうか。また、ユーザーは反映される方とされない方、どちらを期待するでしょうか。
<br>
これらの問題は、親子関係の複雑さに起因します。つまり、今後の予定が
1. 親のスケジュールのみに存在している
2. 親のスケジュールに紐づく子レコードとして存在している
3. 親のスケジュールから独立した子レコードとして存在している

の3つの形態をとり、それらが同様にカレンダー上に存在していることが、問題の原因になっています。

## 子レコード（実際の予定）を複製する案
こういった手もあります。
前段での子レコードに、スケジュール情報も保持しているようなイメージです（2024-01-07に歯医者に行く + これは毎月第一日曜日の予定である）。
予定の繰り返し登録は、該当の子レコードを複製する形で行います。未来に予定がある場合は、再作成します。

メリットは、未来のスケジュール変更が容易で直感的な点です。未来の予定のみを変更する形で繰り返しの登録を行うため、変更の影響の及ぶ範囲が直感的になります。特にこのメリットは、過去の履歴をかえてはならない予実管理において有効です。

一方で、デメリットも大きいです。
無期限で複製することは結局できないため、スケジュールが登録された子レコードを定時で自動複製することで、疑似的に無期限の予定を表示しています。過去に及ぶような変更も、実現できないわけではないですが直感的ではありません。


## 考えをまとめ直して気づいたこと
スケジュール機能というものを考えたとき、設計上難しいというよりも、直感的に操作させるのが難しいというところにネックがありそうです。

実際に開発したときは、子レコードを複製する案で作りました。予実管理がそちらの方が分かりやすくなるというのが決め手でした。

それに加えて、個人的に後者の手法を気に入っている点が一つあります。尺取虫が進むように、自己複製しながら無期限のスケジュールを表現しているところです。気持ちの問題ですが、気持ちも大事です。
からあげ帝国の国歌（メロディ）を作ろうとして止まった話

# からあげ帝国の国歌（メロディ）を作りたかった
※技術的要素は今回なしです、期待していた方、すみません

翡翠です。

毎年、この時期になると Qiita のアドベントカレンダーを読んでは、楽しくて盛り上がる一方、自分も書きたいがそんなネタがない、と指を加えて読んでました。

からあげさんとは、一回お会いしたのみですが、「からあげ帝国のアドベントカレンダー楽しみ！」とポストしたところ、入国許可を得ました👏

帝国について調査したところ、国歌のテキストを作成している民がいて、
「僕はそれをメロディにしてみたい！」と思い、音楽生成 AI のインプットを始めました。

## 結論、作れなかった

僕は撃沈しました。
音楽生成モデルを探していたところ、「プロンプトで音楽生成できるじゃん！」で、翡翠のやる気は撃沈してしまったのです。

## ここまで進んだか、生成AI

つい、一年前くらいはプロンプトだけでこんなにも自由なことを実現できなかったはず、一年でここまで進んだか、という激動な時代に自分がいることに驚きです。

ガラケーからスマホまで、浸透するのにどれくらいの時間を要したか、メールから LINE にみんなが移行するまでにどれだけ時間がかかったか。

## 生成AI といえば、著作権やら倫理やら、検討の余地がたくさんある

ヨーロッパでは法的な規制が入っているところだと僕の中で記憶しています。
反対に生成　AI を肯定的に導入しようという国もあります。
* それは人間や人間の創造物を守ることになるのか
* 技術の進歩を止めることになるのか

そのあたりは全く僕には見えません。

**「からあげにレモンをかけてはいけない」くらいわかりやすいものだと、使用する側（食べる側）も安心なのですが...**

## 音楽生成の確率を知りたい

人間が聞き取ることができる音の周波数範囲は、通常 20 ヘルツから 20,000 ヘルツと言われています。
これは健康な成人の平均だそうです。
僕の耳はモスキート音を聞き取れないくらい耳が悪いので、高域範囲は聞こえませんが、かなりの音を拾うことができるようです。

しかし、楽器により表現できる音程は変わるものなので、今回はピアノの 88のキーにフォーカスして、生成できるパターンをもう少し絞ります。

不協和音もいれたり、複数のキーを同時に弾くケースを考慮すると、88 キーだけでもいろんな表現ができます。
更に、音楽は曲によって音の色も変動します（ハ長調やト長調など）。
上記のパターンより、かなりのパターンを生成できるわけなので、僕の中では、組み合わせが算出できなくなりました。

## 確率によっては、似ている音楽を生成するのでは
これは画像やイラスト生成でも同じことが言えるのかと思いますが、人間が作曲した場合も、同様に似ている曲ができあがりますよね、というケースはいくつかあると思います。

誰々の曲のパクリなのでは？みたいなケースです。
誰のどの曲が...は、ここに記載しませんが、みなさんもどこかで一度は聞いたことがあるのではないでしょうか？

今までの音楽の世界はこのような状況だったかと思います。

しかし、生成AI が音楽も詩も、声も生成できるようになって、それが世の中に出回ったら。

誰が何を作成したかわからない世界になっていしまい、著作権問題もどこに訴えてよいのかわからなくなってしまうのではないでしょうか？

僕も多少歌うので、「歌ってみた」を密かにやっているのですが、使用する音源など、ルールを守って投稿してます。

しかし、生成AI が歌い始めてしまったら、もう何もかも「わからん状態」になりそうです。

**「声は個人情報」** というワードを今日、たまたま見かけて「そうだよな、勝手に学習されたら嫌だよな」と感じましたが、そのあたりはふんわりとわからなくなってしまうのでしょうか。


## 結局何が言いたいのか

**生成AI 使ったらこんなの作成できたよ！！** が今の段階で、これから生成物が増えるとして、当たり前のように SNS やネット上で見かけることになるでしょう。

そのときに「誰が作成したもの？」って、どこかで重要になる気がするのです。

からあげさんだから、からあげ帝国を築き上げたのであって（そう思っている）、AI だったらからあげ帝国を築き上げていないんじゃないかなという、僕なりの考えです。

もし、からあげさんがAI だったら、僕はこのアドベントカレンダーに参加することも、からあげ帝国に入国することもなかったでしょう。

**今まで簡単にできなかったことができるようになり、自由を手に入れた反面、失われていく何かを僕は追求していきたいと思ってます。**


## 最後に
Qiita でなく note に書くべき内容だったなと反省しております。
こちらは技術系がよかった...

からあげさん、今度関東へいらしたら、からあげ食べに行きましょう。
ガバメントクラウドのコスト課題を業務目線で考えてみた【ガバクラ】


## ■はじめに
こちらは**Japan AWS Jr.Championsアドベントカレンダー2023**の22日目の記事です！

https://qiita.com/advent-calendar/2023/jr-champions

この記事では、公共案件で絶賛もがき中の私が独断と偏見でガバメントクラウドのコスト課題について考えてみたので、その内容を共有します。

ガバメントクラウドってあまり馴染みがないなという方に読んでいただきたい基礎的な内容になっております！
（テクニカルな要素といよりも、実際に公共機関の現場で感じたより業務的な観点で書いてます）

## ■そもそもガバメントクラウドって何？
ガバメントクラウドとは、**国の行政機関や地方自治体が行政システムをクラウドサービスとして利用できるようにした政府共通のクラウド基盤**のことです。

これまで国の行政機関や地方自治体は独自の基準、ルールのもとで、業務システムの調達から開発、運用を実施しています。
このような背景のもと行政手続きの複雑化や運用方法がブラックボックス化する等の課題が発生していました。

ガバメントクラウドの利活用により、各行政機関や地方自治体が扱っている業務システムをクラウド基盤で一括管理することができ、組織間の連携・行政手続きの負担削減・運用の標準化を図っています。

（デジタル庁っていうPayerAccountがあって、その配下に各行政機関・地方自治体のメンバーアカウントが払い出される、民間企業のOrganizationsの設定が大きく広がって国を単位にしたというふわっとしたイメージを最初に持ちました）

各地方自治体への接続方式をどうするか、セキュリティ要件をどうするか、事業者や職員へのリスキリングなどなど課題は山積みです。


![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3626407/321150fa-406e-cfc3-c49a-05b384860378.png)
※[日経BPの記事](https://project.nikkeibp.co.jp/jpgciof/atcl/19/00003/00013/)から引用


※ガバメントクラウドには5つのクラウドサービスが採択されています(今年度初めて国内事業者であるさくらインターネットの「さくらのクラウド」が採択されました)

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3626407/6589ac21-91e0-3f51-d450-a5bf71bfef29.png)


## ガバメントクラウドのコスト課題

### ▼移行期間の短さ▼
ガバメントクラウドの移行期間は2023年度から移行を開始して、2025年度に完了させる計画となっています。
（一応、システム移行の難易度が高いシステム等は期限の超過することは容認されるなど緩和条件はあります）

この期間を長いと見るか、短いと見るか。
実際に公共系案件に携わった身からすると、**短い**と感じます。

一番懸念されることは**リソースの逼迫**です。
限られた期間の中で、全ての行政機関・自治体がガバメントクラウドへの移行を実施します。
期限である2025年末、そして2026年初めにシステム移行が集中してくると考えると、ITベンダーのリソース逼迫が見込まれると言われています。

懸念されるのは、**ITベンダーのリソースだけではありません**

**自治体の職員のリソースも不足する**ことが容易に想像できます。
自治体の職員は業務システムだけでなく、県民や市民向けのサービスの運用や改善、また現在独自に稼働している業務システムの運用保守、その他の業務に日々追われている現状があります。

このようにリソースが逼迫していると、最適化された状態での構築が難しくなるでしょう。
最適化されていない状態で運用を始めると、ランニング費用がかさんでしまいます。
**クラウド移行したのに、現状よりコストがかさんでしまうことが起きかねないのです。**

2026年以降に**ガバメントクラウド最適化に向けた活動**が必要になってくるでしょう。

### ▼コストの正当性が担保できない▼
国の行政機関や各自治体の職員はITの専門家ではありません。

- **クラウドのコストの正当性が分かる職員がいるのかどうか**
- **クラウドのコスト最適化に関する知見を持っているITベンダーなのかどうか**
- **そもそも契約時の見積の正当性が担保されているか**

等々、ガバメントクラウドにかかる費用が妥当な範囲なのか確認することができない場合、
コストの透明性も低下していき、ランニング費用が増大してしまう可能性があるでしょう。

クラウドのコスト構造が分かる職員や専門家の配置、必要に応じたITベンダーのリスキリング等が必要になってくると考えています。


### ▼ステークホルダーの調整コストや業務負担▼
ガバメントクラウドは国の行政機関や地方自治体のシステムの標準化を目指しているものです。

契約形態（単独利用方式・共同利用方式）によっては調整コストが大幅に増加するでしょう。

形態を簡単に説明すると、以下のようなイメージです。
- **単独利用方式:自治体が取り仕切る**
- **共同利用方式：ITベンダーが取り仕切る**
（今度のブログのテーマにしようと思います）

**単独利用方式**
- 標準化に向けた動きとしてベンダー間調整や最適化に向けた動きを自治体が主導して実施する必要があります。
- 業務負荷の増加だけでなく、自治体職員のITリテラシー向上が必要となり、間接的なコストが増えるでしょう。

**共同利用方式**
- 運用をベンダーに任せるため自治体職員の業務負荷は軽減するでしょう。（デジタル庁も共同利用方式を推奨しています。）
- ただし、ベンダーに全て任せる形態をとると、再度運用がブラックボックス化しかねません。ベンダーを変更する必要がある場合等、運用引継ぎをどこまで既存の事業者が行ってくれるのか。契約時点でブラックボックス化しないような仕様にする必要があるでしょう。


## ■最後に
今回はガバメントクラウドにおける課題になるであろうコスト課題を業務よりの目線で考えてみました。

私が紹介した課題以外にも、様々な課題が発生し、ガバメントクラウドへの移行の壁となるでしょう。
ただガバメントクラウドに移行することにコストをかけるだけでなく、クラウドの最適化に知見を持ったコンサル業者を配置する等の対策が必要になるでしょう。

次回は、ガバメントクラウドについてよりテック目線で記載しようと思います。
【SCS-C02】SCS合格体験記

## はじめに
先日AWS Certified Security - Specialtyを受検し、合格しました。

## 受検時の状態
- 入社2年
- 業務でAWSを触る環境
- AWS CLF, SAA, SOA, DVA取得済み

## 勉強期間
2か月

## 勉強時間

平日：就業後0.5~1時間 休日：直前の日曜日に4時間

## 使ったもの

:::note
AWS Certified Security - Specialty Official Practice Question Set (SCS-C02 - Japanese)
:::
:::note
 AWS Certified Security - Specialty Official Practice Exam (SCS-C02 - Japanese)
:::
:::note
[Cloud Licence](https://cloud-license.com/)
:::

- アソシエイトを受けていて知識があったので問題演習を中心に行いました。Cloud Licenceでの学習と復習に一番時間をかけました。
- 具体的には、一日10~20問を目安に問題を解いて、分からないところを調べて、自作のノートに書きこんでいきました。そのノートを寝る前や朝に見て暗記しました。
- 今回の受検対策期間はまとまった時間が取れなかったので、平日は1問でもいいから必ず問題を解くことを意識し、勉強を継続しました。
- AWSが出している、AWS Certified Security - Specialty Official Practice Question Set (SCS-C02 - Japanese)は、無料でできるのでぜひやることをお勧めします。これも問題を解いて念入りに復習しました。
- AWS Certified Security - Specialty Official Practice Exam (SCS-C02 - Japanese)は、有料の模擬試験なのですが、会社がAWS Skill Builderの有償プランを契約しており、無料で受検することができました。本試験とおなじように1点刻みのスコアレポートが出て、良いリハーサルが出来ました。


## 本番のスケジュール
9:30 会場着　本人確認や写真撮影を済ませる　
テスト前の受付は30分前からとのことで、10時予約で9時半から受付し始めしました

9:45-12:30ごろ　受検

20:04にバッジ認定メール
→この段階でAWSのサイト行ったらスコアレポート見れました。
2日後の明け方5時にスコアレポートのメールが来ました。（結果：768点）

## どうすれば高得点を狙えたか
今回結構ギリギリの合格だったので、実際受けてみてどうしたら高得点を狙えたか反省点を2つ書いていきます。

- Cloud Licenceの周回数を増やす
    - 2周くらいして試験に臨んだのですが、3周できてたら万全だったかもと思います。また直前にまとまった勉強時間が取れなかったのも反省点です。
- リソースを触る回数を増やす
    - 実際にサービスに触って対策した部分が前回受検時より少なかったので、そこを増やせたらよかったかもしれないです。

なにはともあれ、初めてSpecialtyに合格できて嬉しかったです😊
今後も資格取得と実務を通じて、スキル向上に励んでいきたいと思います。

以上です。ありがとうございました。
Arduino Uno R4と互換ボードを比較してみる

Arduinoにルネサスマイコン搭載のArduino Uno R4 Minimaが発売されました。
Arduino Uno R4 MinimaはRenesas RA4M1が搭載されています。
早速、互換ボードが出ていたので購入してみました。
# 互換ボードの例
Aliexpressにおける互換ボードの例です。
8ドル~15ドル程度で販売されているようです。
日本円にして1300~2000円程度。

### 正規品に近いモデル
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/285344/9baae509-e81a-0580-fd88-30d1b42c376d.png)
### Servo等で使える拡張端子がついているモデル
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/285344/1b0cf8c3-8572-7bf3-265f-2ae387014ffe.png)
# 正規品と互換ボードを比較する
当然ともいえますが、大きな違いはありません。
![ArduinoUnoR4-1.JPG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/285344/c872e14c-7843-87c0-3360-3f9dc85556a1.jpeg)
左：正規品　右：互換ボード

# 価格の違い
正規品：￥3,190
互換ボード：1500円程度（ただし、送料別の為2000円以下）
正規品と、互換ボードの価格差は約1000円程度。
# 仕様の違い
入力電圧に違いがあります。
正規品は24Vまで入力可能ですが、今回の互換ボードは6~16Vです。
いくつかの製品を比較したところ、微妙に最大電圧が異なり12vや18vのものがありました。
DCDCの作りが正規品と互換ボードの大きな差といえます。
また、今回の互換ボードは、クリスタルが付いています。
本来、クリスタルレスで動作するだけになぜついているか、気になります。
# アクリルボードの有無
正規品には、アクリルのベースボードが付属しています。
互換ボードは、ボード単品であり、今回は、袋に無造作に入っていました。
# スルーホール
互換ボードにはピンヘッダーの内側にスルーホールがあります。
互換ボードの唯一ともいえるメリットの一つといえます。

# 正直買いか？
正規品との価格差が1000円程度の為、あえて購入する必要はないといえます。
いずれ安くなるとともに、国内においても販売されると思われます。
ArduinoUnoR3の互換ボードが500円程度で購入できることからも
R4の互換ボードが1000円以下になれば、選択肢となるのではないでしょうか？
Qiita CLIを使う

https://qiita.com/Qiita/items/32c79014509987541130

Qiitaの記事をGitHubリポジトリで管理する方法があるということで、試してみました。
MacでQiita CLIをセットアップするまでの流れを書いておきます。
実行環境：MacBook Air M1, 2020

# Node.jsのインストール
Qiita CLIを使うには、Node.js 18.0.0以上が必要ということで、Node.jsをインストールします。
Homebrewのインストール、nodebrewのインストール、Node.jsのインストールの順に行っていきます。

Homebrewのサイトにアクセスし、インストールの下に記載されたコードをターミナルで実行します。
https://brew.sh/ja/
![スクリーンショット 2023-12-22 22.37.24.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3569835/0a6b8ac7-8633-8b5d-22d8-7403e38fde46.png)

ターミナルで以下のコマンドを実行します。
```zsh
% /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
% brew -v
Homebrew 4.2.0
```

次に、nodebrewをインストールします。
ターミナルで以下のコマンドを実行します。
```zsh
% brew install nodebrew
% nodebrew setup
% echo 'export PATH=$HOME/.nodebrew/current/bin:$PATH' >> ~/.zshrc
% source ~/.zshrc
```

Node.jsをインストールします。
以下のコマンドを実行します。
```zsh
% nodebrew ls-remote
% nodebrew install v21.5.0
% nodebrew list
v21.5.0
% nodebrew use v21.5.0
% node -v
v20.6.0
% npm -v
9.8.1
```
Node.jsをインストールすることができました。

# GitHubのリポジトリの作成
以下の記事にも書いてあることに重複しますが、書いておきます。

https://qiita.com/Qiita/items/32c79014509987541130

GitHubのリポジトリを作成します。
私はqiita-cliという名前のリポジトリを作成しました。

![スクリーンショット 2023-12-22 1.34.47.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3569835/93476fc0-8bd1-31bd-3894-2ab5ad5c0e7a.png)

リポジトリを作成した後、README.mdを作成しました。

# Qiitaの個人用アクセストークンの発行
Qiitaの設定、アプリケーション、新しくトークンを発行するから、個人用アクセストークンを発行します。

![スクリーンショット 2023-12-22 1.35.44.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3569835/1d589cc4-f82c-bff5-bd5e-1a1396f84760.png)

read_qiita、write_qiitaにチェックを入れます。
発行するをクリックすると、個人用アクセストークンが表示されます。
個人用アクセストークンは、再表示されないため、各自保存しておく必要があります。

GitHubで作成したqiita-cliリポジトリのSettings、Secrets and variables、Actions、New repository secretに移動します。
NameにQIITA_TOKENを、Secretに個人用アクセストークンを入力します。

![スクリーンショット 2023-12-22 1.38.09.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3569835/24b34ce1-b4c6-107a-baf3-1f1c8dbd0341.png)

# Qiita CLIのセットアップ
作成したGitHubリポジトリをgit cloneします。
```zsh
% git clone https://github.com/wanana12/qiita-cli.git
```
qiita-cliディレクトリに移動します。
```zsh
% cd qiita-cli
```
ターミナルで以下のコマンドを実行し、Qiita CLIをインストールします。
```zsh
% npm install @qiita/qiita-cli --save-dev
% npx qiita version
1.3.0
```
バージョンが表示されました。
以下のコマンドを実行し、.gitignore、GitHub Actionsのワークフローファイル、ユーザー設定ファイルを生成します。
```zsh
% npx qiita init
```
生成されたファイルを、GitHubにpushしました。
以下のコマンドを実行、発行したトークンを入力することで、Qiita CLIにログインすることができます。
```zsh
% npx qiita login
```

Qiita CLIを使うことができました。
Qiitaの記事をGitHubに保存しておけるのはありがたいです。

# 参考文献
https://qiita.com/Qiita/items/32c79014509987541130
https://github.com/increments/qiita-cli
https://fromscratch-y.work/blog/programming/mac-nodejs-install/
https://brew.sh/ja/
Springで作るWebアプリ作成の流れ（０）前提知識

## 目的
　この記事シリーズではSpringで簡単なTODOアプリを作ってWeb作成の流れを整理と復習していくものです。本記事では、Springなど具体的な話に入る前に必要なWebでのデータのやりとりの仕方がどのようになっているかなどを書いていきます。
<br>
## サイトにつながるまで
![Spitz.gif](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2850098/418d49ab-3290-004c-c268-1d044af71c60.gif)
　私たちが普段使っているWebサイトはブラウザを介して接続しています。
　私たちが何か調べたいとき、ワードで検索してそれに合ったサイトをクリックしてページを表示させます。（写真はスピッツを検索したとき）


#### この時に何が起こっているのか
　この時、リンクをクリックしてからサイトが表示されるまでにどのような処理がされているのでしょうか。

　結論としてはＵＲＬ（リンク）をサーバーに送り、そのＵＲＬに合わせた返しをプログラムによって決めています。

 ![スライド3.PNG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2850098/e82fb578-0493-80e6-6383-5a3cd5ece188.png)
　スピッツの例だと、クリックすると「<b>https(:)//spitz-web.com/himitsu/album/</b>」がサーバーに送信され、それに合わせたページ、今回では開いたページが返されているということになっています。

### まとめ
　このようにWebサイトはリンクをベースにサーバーと連携し、それによりプログラムが動き、やり取りをしていることがわかりました。

## インフラとソフトウェア開発
　先ほどはユーザ目線で考えましたが、今度はアプリ作成者の立場になって考えてみます。

　アプリ作成者側に必要なのは、ユーザからのリクエストを受け取り、それを返すネットワーク関係とリクエストを処理するプログラムが必要です。

![スライド4.PNG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2850098/ccb61b42-640d-2f33-78ee-ae9afa85e066.png)
　ここでネットワーク関係を担当するのがいわゆる<b>インフラ</b>でプログラムを作る方がいわゆる<b>プログラミング</b>で解決するところです。

### Web開発での動き(MVCモデル)
　Web開発においてユーザのリクエストをどのように処理しているのでしょうか。
　それは『URL（リンク）を合言葉』のようにしてやり取りしています。

　そのやり取りのデザインパターンの１つとしてMVCモデルというものがあります。

　MVCモデルとはModel、View、Controllerの３つの役割に分け、Modelはデータを管理し、Viewはサイト、フロントエンドの部分を管理し、ControllerはModelとViewを管理するというモデルです。
![スライド5.PNG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2850098/e801556a-8c7e-e817-7596-50dd4cc733d1.png)

　流れとしてはControllerがユーザのリクエストを受け取り、そのリクエストに応じた処理を行います。データを動かすことが必要なときは、Modelを動かし、Viewを返します。