OmniAICreator/Qiita-1.07M huggingface dataset:
Python3でCGIチャレンジ1　フォーム送信

#はじめに

学んだことをもう一回調べ直さなくて済むよう記録することにした。

#前提

- VisualStudioCodeがインストール済み
- Python3インストール済み

参考までに現在のVisualStudioCodeのバージョンは、1.62.3。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/401158/5fbb317f-b7c9-a8ec-e7a5-0a93b03f7a11.png)

#下準備

VisualStudioCodeのファイルからフォルダーを開くで、サンプル用の作業フォルダを作成する。
適当にps1（PythonSample1の意）で作成。


#作業

##index.htmlを作成する。

```html:index.html
<html>
<head><meta http-equiv="content-type" charset="UTF-8"></head>
<body>
  <form action="/cgi-bin/sample.py" method="POST">
   入力1<input type="text" name="foo">
   入力2<input type="text" name="bar">
   <input type="submit">
  </form>
 </body>
</html>
```

##ディレクトリを作成する。
名前はcgi-bin。

##sample.pyをcgi-bin配下で作成

```python:sample.py
import cgi
import cgitb
cgitb.enable()

print("Content-Type: text/html")
print()   

form = cgi.FieldStorage()

for key in form:
    value = form[key].value
    print('<p>%s: %s</p>' % (key, value))
```

##現時点の状況
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/401158/4f4d5dc6-b9a8-ee42-ceec-07645301c5ca.png)

##ターミナルから新しいターミナルを開く
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/401158/6300832f-46a8-e0a0-22ca-2869fef89ac4.png)

##ターミナルでコマンド実行
```
python -m http.server --cgi 8000
```

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/401158/2d6bf676-5525-bf01-563c-79336483350b.png)

##ブラウザで確認

[http://localhost:8000]

#結果

初期画面
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/401158/75c394f3-b3dd-19e6-fdf7-c169bf40ead7.png)

文字入力
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/401158/33db45b4-f74f-b20a-9ad0-1f2b8498b2aa.png)

送信後
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/401158/56c01788-7384-a7e7-e600-cf8b0c770252.png)

#理解したこと
- htmlのhead部に文字コードセットをしていないと文字化けする。
- ~~formに送信した内容をforで回して取得すると、文字コード順に取得されるらしい。~~
- 文字コード順に取得されるとは限らないらしい。

# 情報源
Googleで「Python3 CGI」で検索し、出てきたサイトを上から順に試してみた。
Web業界2年目のWebディレクション試験合格記

##この記事について
ちょっとした備忘録。
Webディレクション試験を受ける人に少しでもハードルを下げるために書きます。

##私のスペック
専門卒。社会人2年目。専門学校ではwebデザインを学ぶ。
Web系だとWebリテラシー、Webライティング能力検定2級、Webクリエイター能力認定試験スタンダード持ち。IT系に広げると基本情報技術者試験、セキュリティマネジメント試験も合格。

##勉強内容・時間
- 公式問題集1巡
- 公式Youtube解説動画2巡（URLは後述）
- 公式テキスト流し読み1巡

Webリテラシー試験（記事は<a href="https://qiita.com/freedom_mine/items/b6caee988ddc7bd19a31">これ</a>）を受けてそんなに経っていなかったため、あまり忘れていない状態の勉強量としてこんな感じでした。解説動画1巡→公式問題集を解く→公式テキスト流し読み＆解説動画もう1巡の流れで勉強しています。少し前に同期が受けていたのでアドバイスもいただいていました。というか同期からのアドバイスを載せたほうが参考になると思うので載せます。

###同期からのアドバイス（原文ママ）
参考書を買う、問題集買う　までは必須です！
※問題集の内容ほぼまんま出ます

■勉強法
①参考書ざっと読む
②問題集全部解く
③さすがに出来なさすぎることが発覚するのでヤバいと感じる
④ミスった問題部分の参考書を熟読
→全部読むと思わずに「ここ問題にしやすそうだな…」という気持ちを常に持ちつつ読む
⑤②でミスったところ解く
⑥前よりは良くなったけど正直心配な気持ちになる
⑦問題集やっててミスが多かった範囲の参考書を読みまくる
⑧やることなくなってきたら参考書の各ページ下部の語彙の解説を読み確実に定着させる
※ここ↑超重要
⑨参考書最後らへんにある問題解く
⑩成長を感じつつ受かると信じて当日まで暇な時参考書パラパラ見る生活を送る

##実際受験してみて
試験時間1時間半を30分くらいで解いて合格しました。
内訳としては、以下の通りです。

- 総合スコア**75.3%**（合格総合スコアは70.0%）
- セクション別正答率
    - Webリテラシー **85.7%**
    - インターネットビジネス **87.5%**
    - プロジェクトマネジメント **64.7%**
    - Webサイトの企画 **60.0%**
    - Webサイトの設計 **76.9%**
    - Webマーケティング **90.0%**

問題数は65問と前レベルのWebリテラシーから20問減っており、Webリテラシーで時間がいっぱいいっぱいだった人も時間が足りないことはないと思います。
私は公式問題集を1巡した時点での総合スコアが72.5%だったので、結果として受かったけども勉強する前から身についていた知識で勝負した感じの結果になりました。
この記事を読んでいる方はWebディレクション試験を受けようか考えている方だと思いますが、ぜひ私の同期のアドバイスに従って勉強してほしいです。私のような出たとこ勝負で戦うとWebリテラシーと違い合格が危なくなると思います…

##終わりに
Webリテラシー取った直後ぐらいが取りやすい試験だと思います。
実務をしている方もそうですが、実務をまだしたことがない方でこれから実務をするようになるだろう方におすすめです。私もディレクターとして働く予定が立ってからこの試験を受験しました。働く前に知識として入れておくとよいと思います。

##リンク
- Webディレクションについて(https://webken.jp/direction/ )
- 公式Youtube解説動画（https://youtube.com/playlist?list=PL-fVqKWLQQr611pszWNSdF3UiV4RmkwzU )
【Qlikview】分離されたチャートでは行えないアクションです

##分離されたチャートでは行えないアクションです 
タイトルの文言が故に変更処理が行えなかった場合の対処方法

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1076905/e33955b9-6694-ff63-f4e9-00d746d484b2.png)
タイトル横に**（分離）**という文言があれば対象のチャートプロパティは現在分離の状態にある。

###>分離状態とは？
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1076905/ee75965c-2278-1ae2-5971-48766972c3bc.png)
オフィシャルの回答によると分離状態に入れることで選択を行った場合も更新が行われなくなるようです。 
つまり、ほかのチャートと連動している場合などでもクリックしても現状の表示から変更・更新されないとのこと。

###>分離の解除
分離の解除手順はシンプルです。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1076905/2968e01f-a64f-97de-1315-cd4429c35a35.png)
➀対象のチャートを右クリックして分離解除の項目をクリックする

以上で完了です。
これを行えば様々な編集や軸の変更などが行えるようになります。
###>例：
**通常**
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1076905/38db2019-f5ff-394a-e473-1b941c77d753.png)
↓
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1076905/02c371a4-8878-9659-39f7-ce2024fc9580.png)
選択すると変更されるお互いに同時に連動して変更される

**分離の適用**
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1076905/415a8110-2893-7b3a-ddb8-eed7e70f1414.png)
右側の円グラフを分離適用すると初期の状態から変更されていないが、左のグラフはドリルダウンされている。
サーバサイドエンジニアにOxygenNotIncludeというゲームをおすすめする

# はじめに
プログラマのスキル向上に役に立つゲーム、と言われて思い浮かぶものはあるでしょうか。
古くはカルネージハート（ロボットをビジュアルプログラミングして対戦する）とか
Factorio(工場を作りロケットの射出を目指す。設計・モジュール化・デバッグを適切に行わないと大変なことになる)とか言われていたと思います。

今回はその流れでOxygenNotIncludedというゲームをサーバサイドエンジニアに約だとと無理やり強弁してみます。

# Oxygen Not Included というゲーム
細かいゲーム内容自体は公式を見ていただくとして
https://store.steampowered.com/app/457140/Oxygen_Not_Included/?l=japanese

OxygenNotIncludeはいきなり惑星の地下に飛ばされてしまったデュプリカント(複製人間)たちを導いて生き延びるコロニーシムというジャンルのゲームです。
基本的には生存のための酸素・食料を毎日用意しながら、酸素や食料を手に入れるための資源・設備を構築し、研究を進め宇宙への脱出や提示された目標をクリアしていきます。

この設備の構築と自動化についてお話をします

# 設備の構築
設備には稼働に必要な電力、入力する資源、発生する熱量、出力される資源が定められています。
設備で生成されたものを更に別の設備で使う、というケースも非常に多く、最終的に必要な資源の量から用意すべき設備の数を検討する必要があります。

そう、パフォーマンスチューニングですね。
最終的に必要なスペックはどの程度なのか、ボトルネックになりうる箇所はないか、単一障害点はないか、といった基本的なアレソレを学ぶことができます。

# 論理回路による自動化
研究を進めていくと、自動化が解禁されます。
これは、自動化可能な設備にグリーンシグナルを送ると設備が稼働し、レッドシグナルを送ると設備を止める、というような制御が可能になります。
つまり、箱に入った資源が不足したらその資源を生成するように設備を動かしたり、発電設備を必要なとき・必要なだけ動かす制御が可能になります。

そして、このゲーム論理回路がやたら充実しています。
基本のAND，OR，NOTはもちろんのこと、XORやFILTER，BUFFER、メモリスイッチなどのちょっと応用的な回路まで存在します。
論理回路はもちろんエンジニアの基礎基本ですし、自動化をうまく使ってコロニーを効率よく運営するのはツール類を活用したり作ったりしてインフラを適切に運用できる素敵エンジニアになることうけあい（適当）

# そしてコロニー全体の効率よく安全な運用
設備は様々な要因で機能不全を起こしたり、作った自動化や輸送ルートに不具合があって止まったりします。
そういうときにすぐに修復可能な状態になっているか、とか、主環境との切り離しが容易な状態か、とか
トラブルに対応している間生存に問題がない（サービス提供に問題がおきない）か、とか
ゲーム内で直面する様々な問題はサーバエンジニアが直面する課題とよく似ています。

きっと楽しくお勉強できるとおもいます

# 免責事項
- コロニーシムとしてみても高難易度の部類です。強く生きてください
- コロニーシムというジャンル自体が好みが強めにでます。
- ハマるとプレイ時間が恐ろしいことになります。責任は一切取りません。
GitHub Actions での環境変数の使い方

# はじめに
GitHub Actions では環境変数を利用することができますが、ホストする環境によって環境変数の使い方が変わります。

環境変数を使うときには、ここが意外とハマりやすいポイントですので覚えておいた方が良いです。

[環境変数のサンプルプログラム](https://github.com/cloud-creative-studios/GitHub-Actions-Environment)

## Windows ホストランナー
```yaml
- name: Echo
  run: echo ${{ env.CONFIGURATION }}
```
## ubuntu/macOS ホストランナー
```yaml
- name: Echo
  run: echo $CONFIGURATION
```
上記を見ても分かりますが Windows 環境の場合、env コンテキストを介して環境変数にアクセスする必要があります。

ただし、ubuntu や macOS でも以下のような場合は env コンテキストを介してアクセスする必要があります。

```yaml
- name Echo
  env:
    TEMP_CONFIGURATION: ${{ env.CONFIGURATION }}
  run: echo $TEMP_CONFIGURATION
```

スクリプトを実行する場合は ```$ENV``` 形式でアクセスできますが、ステップの設定値を設定する際に環境変数のアクセスする場合は ```${{ env.???? }}``` 形式にする必要があります。
Chakra UI をアップデートしたら props が補完されなくなった

2021/12/14追記
v1.7.3 で修正されたのでこの対応は不要になった

---


`@chakra-ui/react` を v1.6.12 から v1.7.2 にアップデートしたら、 `width` や `boxShadow` など一部のプロパティが補完されなくなってしまった（新規インストールでも同様）
以下は VSCode で `width` プロパティを入力しているときの様子

v1.6.8
![2.gif](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/217275/26063eba-0f72-e57e-4b41-23966f813177.gif
)

v1.7.2
![1.gif](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/217275/a6ac322b-e5fb-6838-58a9-bd85fd069793.gif)

issue にもあがっている
https://github.com/chakra-ui/chakra-ui/issues/5153



### 型定義を覗く

v1.6.8 ではこうなっているのが

![スクリーンショット 2021-11-22 14.53.48.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/217275/45fbb3ff-0501-1418-7f64-9aaaf5674142.png)

v1.7.2 だとこうなっている

![スクリーンショット 2021-11-22 14.56.31.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/217275/811239b4-674b-4f93-0f11-f73c451ae73a.png)

色々用意されていたリテラル型が全部 string にされてしまっている



### 解決策

[公式ドキュメント](https://chakra-ui.com/docs/theming/advanced#theme-typings) を参考にテーマファイルから型定義ファイルを生成する
ポイントは出力先を `/node_modules/@chakra-ui/styled-system/dist/declarations/src/theming.types.d.ts` に変更すること

```shell
$ yarn add -D @chakra-ui/cli
$ yarn chakra-cli tokens /theme/index.ts --out node_modules/@chakra-ui/styled-system/dist/declarations/src/theming.types.d.ts
```
OSSにファイルをアップロードしてLogServiceで通知する

この記事は [Alibaba Cloud アドベントカレンダー2021](https://qiita.com/advent-calendar/2021/alibabacloud) 3日目の記事です。

とある案件で「OSSにファイルがアップロードされたことを通知してほしい」という依頼がありました。
そこでOSSのログ機能であるLogServiceを使ったという話です。

---

# 背景
OSSにはイベント通知機能があります。
[OSSのドキュメント Event notification Overview](https://www.alibabacloud.com/help/en/doc-detail/122379.html)
これはOSSで発生したイベント（ファイルのuploadとかdownloadとか）をMNSに通知する機能です。
便利な機能なのですが、MNSからは直接ユーザーへ通知ができません。
MNSからユーザーへのそれらしい通知を行うには、OSS→MNS→別のプロダクト(FunctionComputeやらECSやら)経由でユーザーに送信しないといけないです。
特に今回はメールで通知がほしいとのことだったので、少し面倒だなと感じました。

例えばこんな感じになります。（有償のチュートリアルです）
[Labex - OSS File Download Triggers Email Sending](https://labex.io/courses/315)

そこでもっとシンプルな方法として、OSSのログをLogServiceで検出して、LogServiceのアラート機能で通知することにしました。


# 概要
ファイルがOSSの特定ディレクトリにアップロードされたことをメールで通知する

## ファイルの検出クエリ

OSSにファイルをアップロードしたさいに、ログから operation　をキーとして検出する。

**operationの値**

 - PostObject ・・・Alibaba Cloudコンソールからの通常のファイルアップロード。これは検知する。 
 - PutObject ・・・OSSブラウザなどのAPIからの通常のファイルアップロード。これは検知する。
 - UploadPart ・・・マルチアップロードパートで分割されたファイルアップロード。これは検知したくない。
 - CompleteUploadPart ・・・マルチアップロードパートが完了したファイルアップロード。これは検知する。


例えば、OSSの 2021-yoshimura バケットに test.jpeg ファイルをアップロードすると
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/308973/4b94f874-d8d0-3a2e-be0c-872e0e173e87.png)

OSSのログには以下のように operation : PostObject が記録されます
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/308973/18a652f6-5bbf-ff87-72e0-14882d1b28e7.png)




更に念の為に、OSSにファイルをアップロードしたさいに、ログから http_status　をキーとして検出する。


**http_statusの値**

 - 204  ・・・　Alibaba Cloudコンソールからのファイルをアップロードした際のステータスコード
 - 200  ・・・　OSSブラウザなどのAPIからファイルをアップロードした際のステータスコード



例えば先程同様に、OSSの 2021-yoshimura バケットに test.jpeg ファイルをアップロードするとこんな感じです。
Alibaba Cloudコンソールからアップロードすると204
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/308973/36fb7b77-f33d-fefa-5df4-606afab6062a.png)

APIからアップロードすると200
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/308973/22209817-590e-47ec-e7e0-dd267ac9d701.png)



ここまで分かれば、あとはLogServiceで検出クエリを以下のように作ります。



### 2021-yoshimura バケットのすべてのフォルダにアップロードした場合の検出クエリ
```sql
* AND bucket: 2021-yoshimura AND (operation:CompleteUploadPart OR PostObject) AND http_status: 204
```

```sql
* AND bucket: 2021-yoshimura AND (operation:CompleteUploadPart OR PutObject) AND http_status: 200
```

---

## クエリの保存とアラート通知
先ほどのクエリを保存して、LogServiceのアラートルールを作ります。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/308973/b8dc2416-a607-9b0f-cb63-b38c386e276f.png)



### アラート条件
 - Log Search 期間 ・・・過去15分
 - Log Search 頻度 ・・・15分に1度
 - Trigger 条件 ・・・  contains(http_status, '200') ※204は別途アラートルールを作成
 - 通知方法 ・・・メール

これでOSSにファイルがアップロードされると15分間隔で検知＆通知してくれます。

ちなみにLogServiceのアラート機能は今年バージョンアップして、様々な機能が使えるようになりました。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/308973/0e980107-39fa-6fca-9807-754b5b4f3b94.png)

[画像の参考URL : The alerting feature of Log Service](https://www.alibabacloud.com/help/en/doc-detail/209951.html)

カレンダーで休日を指定してアラートを停止したり、メール以外にもSMSや電話通知など様々な通知方法が使えたりでするので、興味ある方はそちらも見てみてください。

それでは、明日の４日目にパス。
初めてのChisel - テスト、制約、エラー

## コードのテスト

- iotesterを使ってターミナル上でのテストする場合は次のコマンドを実行します
```sbt 'test:runMain ProjectNameMain'```

``ProjectNameMain``の部分は先に説明したとおりです。複数のテストを行い時は次のようにテストを指示します。
```sbt test```

``TestClassNameMain``でクラスを指定してテストもできます。

``sbt 'testOnly TestClassNameMain'``




## VCDのダンプ
VCDファイルをダンプできますので波形を確認できます。全てのプリミティブをダンプしてしまうので、規模や時間が長い場合はファイルサイズに注意が必要です。
```-- -DwriteVcd=1```

VCDは```test_run_dir```ディレクトリにあります。

## Chiselの制約

- **符号付き整数がデフォルト**  
  Java系言語は符号付き整数のみ対応しています。32bit **符号なし**整数を使う場合、テスト上、最上ビットは符号ビットとして扱われます。また代入捜査においてもエラーとして扱われます。 32ビット符号無し```UInt```のプリミティブ (eg. I/O, wire) に最上位ビットを立てたい場合、

``Primitive := 0x80000000L.U``

が簡単な方法です。リテラル ```L``` は *signed long*、で リテラル *U* で符号無し整数(UInt)へキャストしています。

## 代表的なエラーとその対処方法
- [error] "*OutOfMemory* (memory space)"

**原因**: SBT (Java Virtual Machine; JVM) はメモリを必要としています。
**対処**: SBTにさらにメモリを割り当てます。SBT実行時に次のオプションをしています。
```-mem 4096```

これで4GiB割り当てることができます（MiB単位です）.

- [error] "*OutOfMemory* (heap space)"

**原因**: SBT (Java Virtual Machine; JVM) はヒープメモリを必要としています。
**対処**: 環境変数を設定します。ターミナルで下記を実行するかシェル設定ファイルへ記述します。
```export _JAVA_OPTIONS=-Xmx2048m```

これによりヒープスペースとして2GiB割り当てます（MiB単位）。```Xmx```は最大割り当てサイズで、JVMは```Xms```で定義されているサイズから必要に応じてこの最大サイズまで動的に確保します。
  
- [error] "*java.lang.ClassNotFoundException: ProjectName*"

**原因**: ProjectNameのトップクラス（モジュール）がプロジェクトファイルに記述されていないときに発生します。あるいはプロジェクトのディレクトリ構造が先に説明した構造になっていない場合も発生します。
**対処**: トップクラス（モジュール）の名前を確認してください。あるいはディレクトリ構造も併せて確認してください。
不為也、非不能也（為（な）さざるなり、能（あた）わざるに非（あら）ざるなり）

# はじめに
足立久美さんから、孟子の言葉「不為也、非不能也」を教えていただいたことがあった。非常に印象に残っている。
また、この言葉に関連する記事・動画をいくつか目にしてきている。非常に刺激的であった。
今後も自分の行動を見直すきっかけにするために、刺激的な記事・動画をまとめて記録しておく。

# 孟子の言葉
不為也、非不能也
為（な）さざるなり、能（あた）わざるに非（あら）ざるなり

> できないのは、やろうとしないからであって、できないからではない。
> する前から「できない」と言って、しようとしなければ、いつまでたってもできない。

http://www.narupara.com/modules/blog/2016-07-13-todays-word/


# 刺激的な記事・動画

## 「思うは招く」
植松努氏の講演の動画

https://www.youtube.com/watch?v=gBumdOWWMhY

## 誰でも挑戦できる、みんな挑戦されている
宮城采生氏の記事

https://logmi.jp/tech/articles/321684

@sharp_NEKO氏の記事

https://qiita.com/sharp_NEKO/items/f07c67938c609b363854

@kaizen_nagoya氏の記事

https://qiita.com/kaizen_nagoya/items/1561f910c275b22d7c9f

若宮正子氏の記事

https://logmi.jp/business/articles/312567

## 好きなことを勉強する
@kaizen_nagoya氏の記事

https://qiita.com/kaizen_nagoya/items/a68063d040c81d29927a

@motoki4917氏の【まつもとゆきひろ氏　特別講演】に関する記事

https://qiita.com/motoki4917/items/40386dd7fbd70987cc1d

## 「ちょっとやってみるか」
mineo_matsuya氏の記事

https://speakerdeck.com/mineo_matsuya/fa-xin-deren-sheng-gadong-kichu-sita-fa-xin-toji-sok-falseji-shu-the-art-of-output-and-how-output-changed-my-life

## 最初から凄いのではない、地道な積み重ね
牛尾剛氏の記事

https://note.com/simplearchitect/n/n388201603a28

kyon_mm氏の記事

https://kyon-mm.hatenablog.com/entry/20120521/1337570172

@mnmandahalf氏の記事

https://qiita.com/mnmandahalf/items/ced310dfdca7b827b37d


## 「おわらない旅」
hiroshitakeda氏の記事

https://speakerdeck.com/hiroshitakeda/kaizenziyanikanhuarensu-puroguramafalseziyani

# 「モチベーションに気づかせる7つの質問」
SPI Japan 2018 で、ピョートル・フェリクス・グチバチ氏から、教えていただいた「モチベーションに気づかせる7つの質問」。

http://www.jaspic.org/events/sj/spi_japan_2018/

> モチベーションに気づかせる7つの質問
> 
> 1. あなたは仕事を通じて何を得たいのか？
> 2. どうしてそれを得ることが大切なのか？（3回問う）
> 3. 何をもって「いい仕事をした」と言えるだろうか？
> 4. どうして今の仕事を選んだ（選んでいる）のか？
> 5. 去年の仕事は、今年の仕事にどう繋がっているだろうか？
> 6. あなたの一番の強みは何だろう？
> 7. 私（たち）はあなたをどう支援できますか？

## おまけ
「私たちは、なぜ後回しにするのか（バタ男なのか）」について言及している論文があった。

松尾豊，「なぜ私たちはいつも締め切りに追われるのか」，2006
http://ymatsuo.com/papers/neru.pdf

# おわりに
私が「やればできる」というのを明確にはじめて実感したのは、名古屋工業大学在学中に「工大祭」という大学祭でステージ企画の司会をしたときかもしれない。高校時代は司会をするようなタイプではなかったので、かなり”嫌々””恐々”挑戦した思い出がある。大学時代の経験に本当に感謝している。

https://qiita.com/kazuo_reve/items/e9443e51b6ccd9d52db8

# 謝辞
刺激を与えていただいた皆様に感謝を申し上げます。
PhpStormでCodeShinifferを利用し、カスタムルールを読ませる。

# CodeShiniffer追加まで
https://qiita.com/reflet/items/3ddf3cab030a80af4d2a

# カスタムルールの適用
下図の青いPHP_CodeShiniffer inspectionを押す
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/272812/f91d6a0c-34ba-ceac-155e-9ebd76b8e30d.png)

Config standardをカスタムに変更する。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/272812/f1d20108-6399-947b-2536-c604657b476e.png)

config standard横の三点リーダを押し、ファイルを指定する。
適用すると、PhpStormがルールを読み込んでくれます。
【UiPath】品質の高いコードとは（中編）

# はじめに
この投稿は、RPAツール「UiPath」の 実装ポイントをまとめたものです。
量が多いので、記事を数回に分けます。今回は、中編 として「安定性・効率性」について書きます。

UiPath Adventカレンダーの 3日目 の記事でもあります。

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

前編の記事はこちら

https://qiita.com/miya_gis/items/3b4ca91ed5ad4bd50503

# UiPath公式の「品質の良いコード」とは？

UiPathには、公式のコーディング規約があり、その目的は以下のように書かれています。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/154139/e2d35812-460e-66b3-9429-623ce23785d9.png)

https://www.uipath.com/ja/blog/corporate/uipath-coding-standard

これを以下のように分類し「コーディング規約に書かれている事」と「自分が見聞き、経験、実践している事」をミックスして、紹介します。

```
ルール仕組み
　◆ 一貫性 　(命名規則や処理の構造などが複数のワークフローで統一されている)
　◆ 可読性　 (読みやすく、処理の意図が把握しやすい)
　◆ 再利用性 (作成済・テスト済のワークフローをそのままの形で再利用しやすい)
安定性 効率性
　◆ 効率性 　(少ないリソースで高速に動作する)
　◆ 安定性 　(安定して動作する)
保守
　◆ 保守性 　(どこを修正すべきか分かりやすく、また修正による影響が予測しやすい)
　◆ 信頼性 　(エラーが発生しにくく、また発生した場合でも回復が容易である)
　◆ 安全性 　(機密情報を不正アクセスから守る)
```

# 効率性

`⚫ 効率性 　(少ないリソースで高速に動作する)`

最初は「処理の効率性」の話です。実現するには
「効率性」のために出来る、具体策としては以下があげられます。

```
- 1）処理に時間がかかる部分・リソースを食う処理を把握する
- 2）繰り返しの中では処理を極限まで効率化する
- 3）処理を2段階に分けて実行する（データを絞って読み込むとか）
- 4）並列処理で待機時間を減らす
```

まず、非効率＝「処理に時間がかかる箇所」または「リソース（CPU／メモリ）」を特定する必要があります。ログ出力を小刻みに入れて、処理に時間がかかっている部分を特定したり、タスクマネージャーで「リソース使用状況」をチェックをしたり。

https://atmarkit.itmedia.co.jp/ait/articles/1901/17/news032.html

また、良くあるのが「繰り返し処理」の中で、無駄な処理（例：不要なログ出力／不要な代入など）があり、数十回、数百回のループなら大した事無いのですが、数千、数万回のループだと気になってしまうほど遅くなることがあります。（1回1秒なら、10000回で10000秒＝166分）

https://www.mitsue.co.jp/knowledge/blog/rpa/201908/23_1513.html

大きめの処理で時間がかかっている場合、2つに分けて実行すると効率的になることがあります。例えば、DataTableのSelect条件を複数書くよりも、1つの条件でSelect実行を繰り返すほうが早いこともあります。

https://www.cresco.co.jp/blog/entry/6016/

UiPathには並列処理のアクティビティがあり、処理のアイドル時間を有効活用することが出来ます。ただし、非同期な処理を行うことは難しく、仮に出来たとしてもメリットが少ない（早くない）事もあるので、事情がない限り、非同期処理は諦めたほうが良さそうです。（チャレンジするのは良いことですが）

https://www.uipath.com/ja/blog/developer/about-parallel-activities


# 安定性

`⚫ 安定性 　(安定して動作する)`

続いて、安定性の話。不安定になりがちなRPAでは、非常に大事な要素です。
実現するには、例えば以下のような具体策があります。

```
- 1）セレクター認識を安定させる
- 2）リトライをうまく使う
- 3）画像認識を避ける
- 4）環境差異を減らす
```

セレクター認識を安定させるには、いろいろなアプローチがあります。
UiPathが公式に纏めてくれているテクニックがあるので、ココでの言及は割愛します。

https://www.uipath.com/ja/resources/whitepaper/workflow-stabilization

一時的エラーがある処理で、繰り返せば成功する場合は「リトライで自動チャレンジ」する事できますが、エラーをよく分析して、フローを実装する必要があります。大事なことは「繰り返し実行しても良い処理なのか」という事です。登録処理などは「実は成功している」事もありえるので、リトライする前にデータ登録済みかをチェックするなどの考慮が必要になることも。

https://qiita.com/Davoi/items/a503aa8b444b98fb698b

また、要素の有無をチェックする際に「画像認識」を使うことはオススメできません。
解像度や位置のズレなど、画像認識単体では、安定性を保つのが難しいからです。

https://forum.uipath.com/t/topic/251738

開発環境と本番環境の違いは「RPAあるある」ですが「差異を無くす努力」はするとして、本番試験を手厚く行うことが一番有効です。Studioバージョン21.10からは「リモートデバッグ実行」という機能があり、リモート端末でお試し実行もできます。また、スペックなどの情報をログに出力することで、エラー時の初動調査を加速する事も大事です。

https://twitter.com/miya_gis/status/1446472672787845120


# 終わりに

いかがでしたでしょうか？今回は中編として「安定性・効率性」について書きました。

この記事が参考になったら、 LGTMをお願いします。閲覧ありがとうございました。
【JavaScript】Reflectの使い方


#はじめに

Udemyの[【JS】ガチで学びたい人のためのJavaScriptメカニズム](https://www.udemy.com/course/javascript-essence/)の講座の振り返りです。

前回の記事


https://qiita.com/nao0725/items/61d117169d68369af474


#目的

* Reflectについての理解を深める

#本題
###1.Reflect

ReflectとはJSエンジンの内部の汎用的な関数を呼び出すメソッドが格納されているオブジェクト

| 内部メソッド | Reflect |
|:-:|:-:|
|  [[Get]] |  get |
|  [[Set]] |  set |
| [[Delete]]  |  deleteProperty |
|  [[Construct]] | construct  |

JSエンジンの内部のメソッドをReflectで呼び出せる

**Reflectの使用目的**

* 内部メソッドを呼び出す関数の格納場所
* Proxyと合わせて使用するため


####例1

**前提**

クラスを定義している

````main.js
class C {
  constructor(a, b) {
    this.a = a;
    this.b = b;
  }
}
``````

今までのやり方通り、new演算子を用いてインスタンス化を行う

`````main.js
class C {
  constructor(a, b) {
    this.a = a;
    this.b = b;
  }
}

// インスタンス化したものを変数に格納
const obj1 = new C(1,2)
// C {a: 1, b: 2}と出力される
console.log(obj1);
``````

これをReflectを使用してインスタンス化

````main.js
class C {
  constructor(a, b) {
    this.a = a;
    this.b = b;
  }
}

// new演算子は内部的にReflectのConstructと同様に内部メソッドとして呼んでいる
// 下記のようにメソッドを使用してインスタンス化できる
// 第一引数にコンストラクタ関数を、第二引数に配列として値を設定する
const obj2 = Reflect.construct(C, [1,2]);
// obj1と同様にC {a: 1, b: 2}と出力される
console.log(obj2);
``````

演算子を用いていたものを関数表記にできるというのがReflectの特徴


####例2

in演算子もReflectを用いて関数表記にできる

````main.js
class C {
  constructor(a, b) {
    this.a = a;
    this.b = b;
  }
}

const obj2 = Reflect.construct(C, [1,2]);
console.log(obj2);
// aという値がobj2に含まれているかどうか確認できる（true or falseで出力）
console.log("a" in obj2);
// 上記は Reflectのhasというメソッドと同様の内部メソッドを呼んでいる
// 第一引数にはオブジェクト、第二引数には判定する値（ここではfalse）を入れる
console.log(Reflect.has(obj2, "c"))
``````

####例3

静的メソッド（インスタンス化しなくても使えるメソッド）もReflectで使える

````main.js
// 従来の書き方
Object.defineProperty
// 下記のように書くことも可
Reflect.defineProperty
``````

Objectではエラーを返すが、Reflectではfalseを返す

````main.js
// try...catch構文でエラー出力
try{
  Object.defineProperty
} catch(e) {

}

// 上記のように書くのは面倒
if(Reflect.defineProperty){
  // trueであればここのブロック結果が出力
} else {
  // falseであればここのブロック結果が出力
}
```````

####例4

**前提**

二つのオブジェクトを用意

````main.js
const bob = {
  name: 'Bob',
  _hello: function () {
    console.log(`hello ${this.name}`);
  }
}

const tom = {
  name: 'Tom',
  _hello: function () {
    console.log(`hello ${this.name}`);
  },
  get hello() {
    return this._hello();
  },
}
````

getをReflectを用いて使う

````main.js
const bob = {
  name: 'Bob',
  _hello: function () {
    console.log(`hello ${this.name}`);
  }
}

const tom = {
  name: 'Tom',
  _hello: function () {
    console.log(`hello ${this.name}`);
  },
  get hello() {
    return this._hello();
  },
}
// 一般的なオブジェクトの呼び方
// hello Tom と出力される
tom.hello;
// これは内部的にはReflectのgetを呼んでいるのと同じ意味になる
// 第一引数にはオブジェクト、第二引数には値を入れる
Reflect.get(tom, "hello")
// 第三引数にはreceiverを入れることも可能
// receiverに登録されたオブジェクトがgetメソッドの中で使用されるthisに束縛される = bind
// 下記のようにbobを渡すとhello Bobと出力される
Reflect.get(tom, "hello", bob)
// 第三引数を書かなければ第一引数と同じになる
```````


今日はここまで！

#参考にさせて頂いた記事

* [【JS】ガチで学びたい人のためのJavaScriptメカニズム](https://www.udemy.com/course/javascript-essence/)
* [Let'sプログラミング JavaScript入門](https://www.javadrive.jp/javascript/)
Github Actionsを用いてAPI定義書のコード管理をしたらちょっと幸せになった話

## はじめに

- プロジェクトによりけりではあるのですが、最近、段々とAPI定義書をコード管理する習慣ができてきました！
- 簡易なシステムではあるのですがご紹介だけ！

## 全体のフロー

1. 特定ブランチへのマージ
1. openapi.jsonの生成
1. Redocドキュメントの生成(html)
1. S3へのアップロード


![Untitled Diagram (1).jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/46053/53438183-0d27-f2ca-4781-2ae663d11b12.jpeg)

### Github Actionsワークフロー

- Github Actionsを用いてOpenAPIフォーマットの生成〜アップロードを実現しています。
- ワークフロー自体は必要なライブラリのインストールであったりと長々つらつらと書いてますが、実ステップは以下3つでかなり手軽です！
- ※ 実際にはyarnで実行する為にスクリプト化してるので、実際に実行してるコマンドだけ記載

①コードのアノテーションからopenapi.jsonを生成

```
$ node dist/script/export-openapi.js
```

②生成したopenapi.jsonを元にRedocドキュメントを生成

```
$ redoc-cli bundle openapi.json
```

③S3へのアップロード

```
$ aws s3 cp ./redoc-static.html s3://$S3_BUCKET_NAME/index.html
```

※ こちら↓はRedocの[デモ版](https://redocly.github.io/redoc/)のイメージを拝借いたしました。

![スクリーンショット 2021-12-03 9.45.37.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/46053/ae14e7c3-b9a6-717f-fb13-afdc5978cb82.png)


### おまけ

- ついでにAPI定義変更の実施＆完了をチームメンバーに伝える目的でデプロイ実施後に成功/失敗をSlackに通知しています。

（ワークフロー定義ファイル一部抜粋）

```
      - name: Slack Notification on Success
        if: success()
        uses: rtCamp/action-slack-notify@v2.0.2
        env:
          SLACK_WEBHOOK: ${{ secrets.SLACK_WEBHOOK }}
          SLACK_USERNAME: Github Actions
          SLACK_ICON_EMOJI: ':github:'
          SLACK_COLOR: good
          SLACK_TITLE: API定義生成
          SLACK_MESSAGE: 成功しました

      - name: Slack Notification on Failure
        if: failure()
        uses: rtCamp/action-slack-notify@v2.0.2
        env:
          SLACK_WEBHOOK: ${{ secrets.SLACK_WEBHOOK }}
          SLACK_USERNAME: Github Actions
          SLACK_ICON_EMOJI: ':github:'
          SLACK_COLOR: danger
          SLACK_TITLE: API定義生成
          SLACK_MESSAGE: 失敗しました
```

![68747470733a2f2f71696974612d696d6167652d73746f72652e73332e61702d6e6f727468656173742d312e616d617a6f6e6177732e636f6d2f302f34363035332f63646638366338642d643339652d363565312d623036622d3564363734306464323166642e706e67.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/46053/9cf84601-d8c5-2533-5a2b-a2f56b2470fb.png)

## おわりに

- Github Actions使ってみたいなぁという軽い気持ちで臨んだのですが、わりと簡単に作れるのでおすすめです！
- ただ、既存のコード側にOpenAPI用のアノテーションを記述していくのはなかなか大変だったので、あとから導入するのはもうコリゴリですw
- あと運用面で弊社の場合、フロントチームにAPI定義書をバックエンド実装前に渡す必要があるので、実装の前にAPI定義書作成用のコミットが必要になってしまいます。そこの運用方法については微妙だなと思ってるので改善案考えて取り組んでいきたいと考えています
Rustで競プロに挑戦

こんにちは、今年は一念発起して、Rustで競プロに取り組みました。

# きっかけ
Rustはもともと興味があって勉強していました。
[カニ本](https://www.oreilly.co.jp/books/9784873118550/)や[Rust By Example](https://doc.rust-lang.org/rust-by-example/)は終えていて、基本はおさえたつもりですが、そのあと特に書きたい題材もなくどうしようかと思っていました。

そんなとき、競プロから始めるといいというLTがあり、競プロにも興味があったので取り組むことにしました。

https://speakerdeck.com/fnwiya/competitive-programming-by-rust

# 競プロ、というよりもアルゴリズム基礎

とはいえ、直接AtCoderなどに参加したわけでもなく、アルゴリズムを一度基礎から学んでみたかったので、[問題解決力を鍛える！アルゴリズムとデータ構造](https://bookclub.kodansha.co.jp/product?item=0000275430)を進めることにしました。

ググればRustでAtCoderに挑戦する記事はたくさん出てくるので、実際のコンペなどが知りたい方はそちらを参照してください。

# 学び

## 変数で、値をもらうのか、参照をもらうのか、可変にするのか

単一のi32やf64なら、コピーが渡されるので、そのまま引数で受け取っても大丈夫ですが、

`fn some(x: i32, y: f64) -> i32 { 1i32 }`

文字列やベクターを受け取る場合は、大体の場合、変数自体ではなく、変数が持つ値を知りたいので、参照型で渡すだけで十分ですね。
逆に可変にしたいときは、ちゃんとmutを指定する必要があります。
Rustはここらへんの使い方が厳しいので、最初は大変でしたが、慣れてくるとメモリをどう扱っているのか意識できるので、便利&安全だと思います。

```Rust
fn q04_6(i: usize, w: i32, a: &[i32], mem: &mut Vec<bool>) -> bool {
    /* do something */
    return true
}

```

## 計算時間
雑に下記のコードで時間を算出できて便利でした

```Rust
use std::time::Instant;

let start = Instant::now();
// some calculations
let duration = start.elapsed();
println!("{:?}", duration);
```

## Vectorとイテレータ

ベクターを受け取ってループ処理したり、ベクターを一括で処理したり、割とモダンに書けるのでやりやすいです。

```Rust
fn do_some(a: &Vec<i32>) {
    for x in a.iter() {
        println!("{}", x);
    }
}

let b: Vec<i32> = vec![1, 2, 3];
let c = b.iter().map(|x| x / 2).collect();
```

# アルゴリズムに関する理解
今のところ5章の動的計画法までしかすすんでいませんが、
再帰だったり、分割統治法だったり、なんとなくの理解だったものを自分で実装すると、理解がすすんでよかったです。

# リポジトリ

取り組んでいるコードなどはこちらです。
https://github.com/ieiriyuki/algo_datastr/tree/dev

正解のコード例もC++ですが公開されているので、参考にしつつRustで実装しなおすのも勉強になります。
https://github.com/drken1215/book_algorithm_solution

# 今後やりたいこと

今のところ、文字列操作ができていないので、文字列も扱えるようになりたいですね。
Rustの文字列はString型とstr型となれるまで使い方がわかりにくいのと、
スライスしても日本語のようにマルチバイト文字だとうまくスライスできないのがやっかいですね。

外部クレートも使いこなせていないので、可能な限り使ってみたいです。
データ分析のクレートは[ばんくしさんがまとめてくれています](https://vaaaaaanquish.hatenablog.com/entry/2021/01/23/233113)ね。

# 終わり

現場からは以上です。
みなさんもRust&競プロやりましょう!
Twilioで受け取ったSMSをTeamsに投稿する

TwilioでSMS受信用に作成した番号に届くメッセージをチームで対応する場合，受け取ったメッセージをチームで共有できるようにすると便利です。今回はPowerAutomateを使用してTeamsのチャンネルに投稿してみます。
※PowerAutomate（Premium）が必要です。

## トリガー作成

トリガーには「HTTP要求の受信時」を使用します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/102503/6ffc27f1-02ae-4884-bd0d-6ceb0582eead.png)

まず保存する必要があるため，Teamsの「チャットまたはチャネルでメッセージを投稿する」を追加し投稿先を設定して保存します。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/102503/16ffd613-90de-3b15-2d40-3141d73a5363.png)

保存すると「HTTP要求の受信時」のURLが生成されるのでコピーします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/102503/a056bc13-742c-ac7c-b63c-470bc846b947.png)


コピーしたURLはTwilioの電話番号を開いて以下の場所にペーストします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/102503/0ca4be91-f667-ca71-72b8-18afc0ec5db5.png)

## メッセージ作成
PowerAutomateのフロー編集画面でテスト（手動）を実行し，Twilioの電話番号にSMSを送信します。実行結果の出力にTwilio側から受け取ったメッセージが表示されるのでコピーします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/102503/606d1d4c-592d-9a78-8e29-b650adc7f50c.png)

フロー編集画面の「HTTP要求の受信時」にある「サンプルのペイロードを使用してスキーマを作成する」で先ほどのメッセージをペーストするとJSONスキーマが表示されます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/102503/4839bb95-d938-a7aa-a720-6e9f80c213f0.png)

Teamsに投稿するメッセージに使用する変数を作成します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/102503/296ea299-1cbd-42a1-ee57-a1d2061e86a2.png)

変数初期化の後，「Apply to each」を使って $formdata を繰り返し処理します。そのうち Key が一致するものを変数に設定します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/102503/491205f6-7f57-1748-55b6-cebe64d0e78a.png)

最後に，Teamsのメッセージを作成して完了です。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/102503/0e2ea141-c1fb-dda9-185f-840d2db3804f.png)

Twilioの番号にSMSを送信すると，Teamsに投稿されました。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/102503/7773f3ba-7f24-9dd0-ccbf-cd916bafc0d1.png)
TiDB 検証ライフ(2-製品構成を理解)

# 検証前に基本アーキテクチャーの理解から

分散データベース、NewSQL、可用性、柔軟性、伸縮性。。。
TiDBを表現するこれらのキーワードを並べても、ピント来ませんね。

知りたいのは、可用性ならMySQL Clusterなどあるのに、なぜTiDB?

## TiDBのアーキテクチャー
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/61975/f8350de8-01dd-8d7c-c03b-6c3d40da5343.png)

※ PingCAP社のドキュメントから引用(https://docs.pingcap.com/tidb/stable/tidb-architecture)

いくつかコンポーネントから構成されているようです。

### TiDBクラスタを構成するTiDBサーバ
外部からのSQLリクエスト(MySQLプロトコル)を受け付ける部品で、スケールアウト可能。
SQL解析、最適化、分散実行計画の生成をここでやっているイメージか。

### PD(Placement Driver)クラスタを構成するPDサーバ
ここが司令塔のようで、メタデータを管理し、クラスタ全般(TiDBクラスタ、Storageクラスタなど)を司っている。
PDサーバは可用性を持ち、少なくとも3ノード必要、ノード数は奇数が良い(Apache Zookeeperの匂いが)

### Storageクラスタを構成するStorageサーバ
２種類のサーバがあるようです。

#### TiKVサーバ
データ保存用で、分散キーバリューストアエンジン。
データ保存単位はRegionで、一つのTiKVノードに複数存在する。
分離レベルは、スナップショット分離をサポートし、これがTiDBがSQLレベルで分散トランザクションをサポート可能な要因となる。
TiKVに格納されたデータは、複数レプリカにより自動メンテされる(デフォルトはレプリカ三つ)。
ネイティブの高可用性を持ち、自動フェールオーバーも可能か。

#### TiFlashサーバ
特殊ストレージで、データを列指向(カラムナー)で保存し、主に分析処理を加速するために使用される。

## 終わりに
一旦、アーキテクチャと用語は抑えておきました。
各コンポーネントの機能と特徴もなんとなく理解できました。

次回は検証に入りたいと思います、お楽しみに。
コマンドでdetektをかける

https://detekt.github.io/detekt/cli.html

gradleで入れるのが面倒だったのでとりあえずCLI版を入れてしまう

```　bash
curl -sSLO https://github.com/detekt/detekt/releases/download/v1.18.1/detekt-cli-1.18.1-all.jar
```

以下のコマンドでテキスト形式で結果を出力できる

```
java -jar detekt-cli-1.18.1-all.jar -r txt:detekt.txt
```
コマンドでcheckstyleをかける

https://github.com/checkstyle/checkstyle/releases/

上からcheckstyleのjarをダウンロードする

循環複雑度をシュッとかけるためのxml

``` xml
<?xml version="1.0"?>
<!DOCTYPE module PUBLIC
          "-//Checkstyle//DTD Checkstyle Configuration 1.3//EN"
          "https://checkstyle.org/dtds/configuration_1_3.dtd">
<module name = "Checker">
    <module name="TreeWalker">
        <module name="CyclomaticComplexity">
            <property name="max" value="7"/>
        </module>
    </module>
</module>
```

おもむろに実行してみる

``` bash
java -jar <PATH>/checkstyle-9.0.1-all.jar -c <上のXML>.xml -o checkstyle_result.txt **/*.java
```
えを描こう

# えを描こう

この記事は

[レコチョク Advent Calendar 2021](https://qiita.com/advent-calendar/2021/recochoku)

の03日目の記事となります。

## はじめに
会社やチームに所属して何らかのシステムを管理運用する事になった時、引き継がれたり引き継いだりしてシステムを継続して回していきます。
一人で開発、運用しているときはまあ何とかなるかと思いますが、いざ引継ぎとなった時にドキュメント群が充実していない時に、
<br>
「あ、これは大変かもなぁ…」
<br>
と思う事は無いですか？
<br>
ドキュメントがしっかりしていた場合でも、パラメーターシートが主で具体的な全容が見え辛いという事があります。
<br>
それは何でだろう？
<br>
一つは、視覚から入る情報が少ないから、では無いでしょうか。

## 視覚から入る情報のインパクト
初めて見るシステム、分野が異なるエンジニアやエンジニアではない方とシステムについて会話する時など、色々と情報を共有する場面があるかと思います。
<br>
情報共有の際に文字だけで伝える、もしくは管理者権限付与したから勝手に環境見といてね、という感じだとなかなか辛いものがあります。
<br>
だって、全体が分からない(見えてない)から。
<br>
システムに関わる際には、まず全体の概要を把握してから細かい部分(自分が担当する部分など)に入っていくと、理解しやすい事が多いです。
もちろん、細かい部分から辿って行ってもいいのですが、より短い時間に全体を把握するには、俯瞰した状態からの方が圧倒的に早いですね。
<br>
そういった時に何があると良いかとなった時に、**え** の有無が重要になります。
<br>
そういえば視覚からという意味で、わたしはDTM(SC-88)で耳コピして遊んでた世代なので、スコアがあるとだいぶ楽できるなぁと思っていました。
レコポンを使っていましたので、なおさら知らない方が見ただけだったら何か分からないだろうし…。

## え
**え** には色々なものがあります。
今回はシステムに関する事なので絵画とかそういうのは触れません。
<br>
わたしはオンプレミス時代からのネットワーク屋さんなので、散々 **え** を~~描かされて~~描いてきました。

- 物理構成図
- 論理構成図

※参考
レコチョクオンプレミス時代の物理と論理構成図

![物理構成図](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/130403/d1dc5502-16d4-caa4-03f0-8e4975a48380.png)

![論理構成図](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/130403/3f45fddb-6873-9b92-8b68-6ff7f00bf843.png)


この辺りはネットワーク屋さんは延々とVisioで描いて、ステンシルにこだわったりする職人さんもいらっしゃいますね。
<br>
レコチョクだとAWSに完全移行しても、全体基盤として可視化するために同じく概要図や論理図は描いてきています。

※参考
AWS環境に移行してからの構成図の一部

![AWS環境構成図の一部](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/130403/ca70c3ef-9e79-2d58-8975-251f6331d625.png)



開発目線でも、所謂UMLといったお作法を使って、フローや関連性を可視化しますね。
<br>
描き方は様々でも、こういった **え** で表された情報は、パッと見るだけでも色々分かることがあります。

- あー、とりあえずここが情報集約するところねー
- このフローだと整合性どうなんの？
- 今の処理能力だとここがボトルネックにならない？


考えてみてください。
<br>
最近はコロナ禍で難しい場合もありますが、ディスカッションする時ホワイトボードにどんなこと描いてますかね？

## 更新する事が大変
**え** は最初は結構描きます。アイデアをまとめる時とか設計の時とか。
<br>
ただ、システムがリリースされちょっとした改修が行われ…
<br>
みなさん、描いた **え** はちゃんと更新していますか？
<br>
「ちょっと古い図で申し訳ないんですが…」
<br>
言ってませんか？
<br>
世の中にはこういったことを防ぐために、自動で情報取得して可視化してくれる便利なツールが多いです。
みんな同じようなところがめんどくさいと思って、それを解消するためのツールがある。いい世の中ですね。
<br>
ネットワークトポロジも自動で出来ればなぁと考えながら、#sh cdpしなくて良いんです。
YAMAHA機器で揃えたら可視化自動でしてくれるって！みたいな事を考えなくて良いんです。

参考

- [CloudMapper](https://github.com/duo-labs/cloudmapper)

　ノード数が多くなりすぎると重かった…つらい

- [Ilograph](https://www.ilograph.com/)

　今これがおもしろい

## おわりに
**え** を描けるという事は、理解しているとも言えると思います。
自分のためでもあるのですが、描いたものがあれば共有や引継ぎの時にすごくスムーズに出来る事が多いです。
<br>
手動でがんばる、自動で可視化などなど手法は何でもできる時代ですので、**え** を使った伝え方が出来ているか、見直してみてはいかがでしょう。

明日の[レコチョク Advent Calendar 2021](https://qiita.com/advent-calendar/2021/recochoku)は04日目、 「AWS re:Invent 今年はハイブリット開催」 です。

---
この記事はレコチョクのエンジニアブログの記事を転載したものとなります。

https://techblog.recochoku.jp/7890
大学時代に学んだこと・経験したこと

# はじめに
私は、名古屋工業大学 工学部 知能情報システム学科 出身です。
1996年に入学しています。

大学時代に学んだこと・経験したことを振り返り、考察を述べてみたいと思います。

# 大学時代の環境
* UNIXのPC
* ブラウザはNetscape
* OHPを使って発表

# 大学時代に学んだプログラミング言語
大学時代に以下の言語でプログラムを書いた（写経した）記憶がある。
最初に学んだ言語はPascalだったと記憶している。

* Pascal
* Lisp
* Prolog
* Java
* C

社会人になってから書いたことがある言語と比較をしてみる。
大学時代に使ったことがある言語は、社会人になってからほぼ使っていいないことがわかる。

|言語|大学|社会人（業務）|社会人（改善・趣味）|
|:----|:----|:----|:----|
|Pascal|〇| | |
|Lisp|〇| | |
|Prolog|〇| | |
|Java|〇| | |
|C|〇|〇| |
|C++| |〇| |
|C#| | |〇|
|VBA| | |〇|
|Perl| | |〇|
|R| | |〇|
|Python| | |〇|

# 大学時代の成果
大学時代の唯一の成果は以下の論文。
ただし、論文も論文のために書いたコードも手元にはない。
最近、久々に見たいなと思ったが見れないという状態である。
当時は、gitなどのシステムに成果をアップするような文化はなかったと思う。

https://jglobal.jst.go.jp/detail?JGLOBAL_ID=200902180463560480

# 大学時代の共通科目
大学時代の共通科目があったと記憶している。

* 体育実技  
* 心理学
* 線形代数
* 微分積分
* 英語
* 第2外国語（私の場合は、ドイツ語）

## 現在のカリキュラム
現在のカリキュラムは以下に公開されている。

http://syllabus.ict.nitech.ac.jp/

現在は第2外国語という科目は存在していない模様。

現在のカリキュラムの共通科目を見て、今一度学びたいと思う科目は以下である。
この2つは大学時代に学ぶのではなく、社会人になってからも学び続ける必要があるように思う。
残念ながら大学時代は、興味もなく、必要性を感じなかった。

* 産業・経営リテラシー（経営戦略、会計学、企業経営）
* グローバルコミュニケーション（English）

# 大学時代の学科のカリキュラム
大学時代の学科のカリキュラムは記憶がない。
楽しい科目はなかったと記憶している。楽しい科目がなかったから記憶がないのかもしれない。

## 現在のカリキュラム
現在のカリキュラムは以下に公開されている。
科目の関係性・順序が良く考えられているように感じた。

http://gkm.web.nitech.ac.jp/e-model/20141_E.pdf

プログラミングの楽しさ・作品を作る楽しさを感じるための科目があってもいいように感じた。
（あるのかもしれないが・・・）
楽しさがわかると自分で必要に応じて学ぶ行動が生まれるように思う。

# 大学時代の経験
「工大祭」という大学祭で、ステージ企画の司会をした。
これが、私にとってもっとも貴重な経験だった。自分の人生に大きな影響を与えた経験だった。
「大勢の前でしゃべる」という経験を初めて積んだ。
この経験により、社会人になってから社内外で発表することの”怖さ”が軽減され”勇気”が持てた。「何事もやってみよう」という考え方も身についた。

https://www.koudaisai.com/about/

# 考察
* 大学時代に1つのプログラミング言語だけをしっかり学ぶ価値は低いかもしれない。業務によって使用するプログラミング言語は異なる。プログラミング言語は独学でも学べる。
* 大学時代の成果はgitなどにアップしておくとよいかもしれない。
* 「産業・経営リテラシー（経営戦略、会計学、企業経営）」については、社会人になってから学びたくなった。共通科目には、社会人になってから、必要性を感じる科目がありそう。
* 英語については、本当に真剣に学んでおけばよかったと後悔。英語を使う能力が低いと、獲得できる情報が本当に少ない。学生時代から現在まで継続的に英語を勉強していれば、もっとスキルが伸びていたかもしれない。
* 自由にプログラミングをする（作品を作る）科目があってもよいかもしれない。大学時代にプログラミング楽しいと思えていれば、もっとスキルが伸びていたかもしれない。
* 大学において授業以外の時間・経験も重要かもしれない。

# おわりに
過去をふりかえるだけでは、何も始まらないので、これもいろいろ”やってみる”。

https://qiita.com/kazuo_reve/items/a2e15627f0eff62e6af6

過去をふりかえると、いろいろとアクションを思いつくこともあるので、ふりかえりも継続する。

https://qiita.com/kazuo_reve/items/7b5c8f4cb82b6c005716
初心者こそTDDを始めるべき理由

# 概要
エンジニア1年目の駆け出しのものです。
チームでTDDを推進していくことになり、TDDを勉強、実践していくうちに初心者こそTDDを始めるべきだと思ったのでまとめました。
TDDを始めようと思っている方の一助になれば幸いです。

# 目次
- 結論
- TDDって何？
- TDDのメリットは？
- TDDをどうやって始める？
- まとめ
- 余談

# 【結論】なぜ初心者こそTDDを始めるべきか
- レッド、グリーン、リファクタリングのサイクルを小さく、素早く回す事により、__問題を小さく分解して確実に進む__ことができるから
- なおかつ、コードにバグがないと__自信を持ちながら進む__ことができるから


TDDについての説明となぜ上記の結論のように思ったのかを書く↓。
# TDDって何？

>テスト駆動開発 (てすとくどうかいはつ、英: test-driven development; TDD) とは、プログラム開発手法の一種で、プログラムに必要な各機能について、最初にテストを書き（これをテストファーストと言う）、そのテストが動作する必要最低限な実装をとりあえず行なった後、コードを洗練させる、という短い工程を繰り返すスタイルである。
[wikipedia参照](https://ja.wikipedia.org/wiki/%E3%83%86%E3%82%B9%E3%83%88%E9%A7%86%E5%8B%95%E9%96%8B%E7%99%BA)

![スクリーンショット 2021-11-29 20.43.41.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/495868/485100dd-aa60-e281-0abd-cf70a843520d.png)
[t_wadaさんの資料参照](https://www.slideshare.net/t_wada/osh2014-sprit-of-tdd)

ある機能を実装する際、TDDでは以下のサイクルを回す。
①その実装が満たすべき挙動のテストを書く（レッド）
②最低限の実装でテストを通す（グリーン）
③リファクタリングする（リファクタリング）


TDDはただテストを始めにかけばいいのか？というとそうゆうことではない。
TDDのテストは以下のような意味を持つと書かれている。
>TDDはテスト技法ではない。TDDは設計技法である。
TDDのテストはいわばプログラミングの設計の補助線、治具である。
[テスト駆動開発](https://www.amazon.co.jp/dp/B077D2L69C/ref=dp-kindle-redirect?_encoding=UTF8&btkr=1)

テストとはその機能が最終的にあってほしい姿（設計）であり、テストを先に書くことでゴールを明確にできる。
また、テストが書きづらいのであれば、考えている設計を考え直すきっかけにもなる。

# TDDのメリットは？
- 「動作するコードを書く」と「きれいなコードを書く」のフェーズを分離することで、__小さく確実に進む__ことができる
- 今書いたコードにバグがないと自信を持てる
- これから書くコードが既存コードを破壊していない自信を持てる

# TDDをどうやって始める？
TDDの手順は大まかに以下の通り
①　実装したい機能をリストアップする
②　リストアップした中から機能の中から1つ選び、最終的にあるべき挙動のテスト書く
③　②のテストがレッドであることを確かめる
④　仮実装でテストをグリーンにする
⑤　④を一般化したコードに置き換える（[テスト駆動開発](https://www.amazon.co.jp/dp/B077D2L69C/ref=dp-kindle-redirect?_encoding=UTF8&btkr=1)で言う明白な実装）
⑥　④のコードをリファクタリングする
⑦　②に戻る


先程の図に当てはめるとこんなイメージ
![スクリーンショット 2021-11-29 20.43.17.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/495868/62662b7a-8333-515a-eb9c-34133290169f.png)

仮実装など行わずともはじめから一般化したコード、きれいなを書けるのであれば書けば良い。
ただし、問題が複雑で混乱してきたときは__小さなステップに立ち返る__。
つまり、まずは仮実装を行い、次に動作するコード、次にリファクタリングを行う。

###初心者にすすめる理由
ベテランエンジニアであれば、一気にきれいで動作するコードを書くことができるだろう。
しかし、初心者はそうは行かない。（少なくとも私は）
そこで、TDD使うことでプログラミングの補助輪をつけることができ、小さなステップで着実にコードを書くことができる。

# まとめ
- TDDはレッド、グリーン、リファクタリングの__サイクルを小さく、素早く回す__
- これにより問題を__小さく分解して確実に進む__ことができる
- なおかつ、コードにバグがないと__自信を持ちながら進む__ことができる

# 余談
###TDDで書くテストはソフトウェアテストの世界の一部
ソフトウェアテストは下の図のように分類でき、TDDで書くテストはその一部である。
TDDはチームや個人を支援する、つまり、より確実に安心してコードを書けるテストを提供する。
一方でセキュリティパフォーマンステストなど「製品を批評する」テストも必要である。

![スクリーンショット 2021-11-30 8.48.48.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/495868/a5a87648-a616-6d38-91fe-4b5273c644af.png)
[テスト駆動開発 参照](https://www.amazon.co.jp/dp/B077D2L69C/ref=dp-kindle-redirect?_encoding=UTF8&btkr=1)
Apexでカスタム通知を実装

#はじめに
今回はApexでカスタム通知をやってみます。標準機能でも通知は来ますが(承認申請されたときなど)、特定の状況でユーザに通知をしたいときにはApexで通知を出来ます。

#カスタム通知を作成
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/407598/a8ed72ca-bef8-a0c3-8200-3c8bbc042034.png)
設定の「カスタム通知」からカスタム通知を作成します。通知を行う媒体を選択できます。

#Apexからカスタム通知を呼び出し
CustomNotificationTypeから先ほど作成したカスタム通知を取得します。
setTitle()とsetBodyで通知の内容を指定します。setTargetIdに対象のレコードのIdを入れます。
最後にTry-catchのなかのsend()で通知をしたいユーザのIdを入れて通知を送信します。

```Apex
            CustomNotificationType notificationType = 
                   [SELECT Id, DeveloperName 
                    FROM CustomNotificationType 
                    WHERE DeveloperName='MyCustomNotification'];
            
            // Create a new custom notification
            Messaging.CustomNotification notification = new Messaging.CustomNotification();
    
            // Set the contents for the notification
            notification.setTitle('レコードが更新されました');
            notification.setBody('The notifications are coming from INSIDE the Apex!');
    
            // Set the notification type and target
            notification.setNotificationTypeId(notificationType.Id);
            notification.setTargetId(newRec.Id);
            
            // Actually send the notification
            try {
                notification.send(new Set<String> { Userinfo.getUserId() });
            }
            catch (Exception e) {
                System.debug('Problem sending notification: ' + e.getMessage());
            }
```

ものの数分で実装が完了しました。このくらいであればプロセスビルダーでも実現できますが、より複雑な条件で通知をしたい場合はApexでもできるので選択肢の幅は広がりますね。
［2021年版］EC-CUBEのユーザーグループに参加してみよう

# ユーザーグループに参加してみよう
EC-CUBEに興味がある方や、情報交換したい方におすすめしたい、全国各地の「EC-CUBEユーザーグループ」。
現在はコロナの影響でオンライン開催が増え、全国どこにいても参加できるユーザーグループの活動が多くなりました。一方で、感染対策に気を付けながらリアルで交流できる機会を大切にしているユーザーグループもあります。
この記事が「EC-CUBEのことを知りたい」「EC-CUBEの仲間がほしい」という方にとって、気になるユーザーグループを見つけるきっかけになれば幸いです。

# どんなユーザーグループがあるの？
EC-CUBEのユーザーグループは、2021年12月現在で、北海道、千葉、東京、名古屋、関西、岡山、中国/四国・九州に存在しています。
それぞれにfacebookページがあり、[EC-CUBEイベント情報](https://www.ec-cube.net/news/#events_information)に一覧が掲載されています。
ここでは、直近で予定されているユーザーグループ勉強会3つをピックアップしてご紹介していきます。

# 12月4日（土）名古屋ユーザーグループ勉強会
リアルでの交流を大切にしている名古屋ユーザーグループの、久しぶりの勉強会です。
12月4日（土）13:30～17:30に、[「EC-CUBE近況報告&ネットショップ何でも相談会」](https://ec-cube-nagoya.doorkeeper.jp/events/130127)と題して、アロマフォレスト今池で開催。
EC-CUBEエバンジェリストの大河内さんはじめ、皆さん話しやすく、初めての方も安心して発言できる雰囲気です。
尚、名古屋ユーザーグループに興味を持たれた方には、2006年にEC-CUBEアドベントカレンダーに投稿された、@ryo-endoさんの[「EC-CUBEの勉強会に参加してみよう」](https://qiita.com/ryo-endo/items/17e8839a34e354081fdb)というエントリーにて、名古屋のユーザーグループに実際に参加した体験談が掲載されていますので、こちらもおすすめさせてください。

# 12月10日（金）関西ユーザーグループ忘年会
12月10日（金）18:00～18:50に、[「関西ユーザーグループ忘年会」](https://ec-cube-kansai.doorkeeper.jp/events/130040)がオンラインで開催です。
現在は、オンライン開催が中心となっており、全国各地のユーザーと交流できる関西ユーザーグループ。
従来の勉強会では、毎回、参加者同士の自己紹介で始まり、EC-CUBEの最新情報の紹介やテーマでの発表・情報交換を実施しているほか、「悩みや疑問を持ち寄り、参加者同士で解決する【助け合いの場】」というコンセプトを持ち、登壇やLTをしたい方を常に歓迎しています。
今回は2021年も暮れに近づいてきたということで、勉強会ではなくGoogleMeetを使った「忘年会」となります。今年あったことをみんなで振り返りましょう。

# 12月10日（金）岡山UGリアル開催 オンラインで関西UG忘年会にお邪魔する
12月10日（金）18:00～19:00に、[「岡山ユーザーグループ忘年会」](https://eccube-okayamaug.connpass.com/event/232311/)がオンラインで開催です。
2021年に発足し、オンラインを中心に、PurchaseFlow やWebAPI×Laravel8 WebHookなど、技術的なトピックをテーマに取り上げて勉強会を開催されている岡山ユーザーグループ。
今回は、岡山市内のコワーキングスペースの会場から、関西UGのオンライン会場につなぎ、ユーザーグループ同士の交流を交えて、イベントを開催されます。
オンライン・オフラインの壁を超えた交流の機会となります。岡山近郊の方は是非、参加されてみてはいかがでしょうか？

#直近のユーザーグループの思い出
以上、12月に開催が決まっているユーザーグループの勉強会のご紹介でした。
ちなみに私自身が、一番最近で参加したユーザーグループのイベントは、11月4日に、東京・名古屋・関西・岡山・九州の5つのユーザーグループの会場を中継して開催された [EC-CUBE 15周年を祝う会](https://www.ec-cube.net/event/detail.php?event_id=311) でした。
コロナ禍でリモート勤務となり、自宅で働くという新しい体験にワクワクしていましたが、ユーザーグループの会場で、名刺交換したり、参加者同士で近況を話し合ったりと、久しぶりの交流にほっこりしました。また、コロナの影響での案件の変化や、今後挑戦したいことなどお聞きできたのも刺激をもらい、参加できてよかったです。
お話いただいた方、ありがとうございました！
来年は、全国どこからでも参加できるオンライン開催も、リアルで交流できるオフライン開催も安心して楽しめる1年となりますように。

#最後に
EC-CUBEのユーザーグループでは、他にも、[東京ユーザーグループ](https://www.facebook.com/groups/283598911686452)、[千葉ユーザーグループ](https://www.facebook.com/groups/239213763657177)、[九州ユーザーグループ](https://www.facebook.com/groups/493909040638938/)などで勉強会が開催されています（[一覧はこちら](https://www.ec-cube.net/news/#events_information)）
Twitterの[EC-CUBE公式アカウント](https://twitter.com/ec_cube)や、[ハッシュタグ#eccube](https://twitter.com/search?q=%23eccube&src=typed_query&f=live)もチェックすると、最新情報がわかると思いますので、ご活用ください。
ARをさわる【コンピュータ・ビジョン＊AR】

ARオブジェクトにさわれたらいいと思いませんか？

<img src="https://user-images.githubusercontent.com/23278992/125152071-59e4d100-e185-11eb-8f4c-e14a825ada09.gif" width=150>
【ARをさわる】

VisionとRealityKitで指が触れたARオブジェクトを反応させられます。

まずはVisionで指先の位置を取得します。

```swift
import Vision
import RealityKit

...

var handPoseRequest = VNDetectHumanHandPoseRequest(completionHandler: handDetectionCompletionHandler)
 // 手のポイントを取得してくれるリクエスト
 // CompletionHandler内で結果を処理します

...

func session(_ session: ARSession, didUpdate frame: ARFrame) {
    let pixelBuffer = frame.capturedImage
    // ARSessionで取得したフレームでVisionリクエストを実行
    DispatchQueue.global(qos: .userInitiated).async { [weak self] in
        let handler = VNImageRequestHandler(cvPixelBuffer:pixelBuffer, orientation: .up, options: [:])
        do {
            try handler.perform([(self?.request)!])        
        } catch let error {
            print(error)
        }
    }
}
```

取得した指先の位置でヒットテストをし、ARオブジェクトを検出します。
ARViewはView上のポイントの延長線上にあるエンティティを検出できます。

```swift
func handDetectionCompletionHandler(request: VNRequest?, error: Error?) {
    // リクエストの結果から、人差し指の先の位置を取得する
    guard let observation = request?.results?.first as? VNHumanHandPoseObservation else { return }
    guard let indexFingerTip = try? observation.recognizedPoints(.all)[.indexTip],
          indexFingerTip.confidence > 0.3 else {return}　
    
    //  Visionの結果は0~1に正規化されているので、ARViewの座標に変換する
    let normalizedIndexPoint = VNImagePointForNormalizedPoint(CGPoint(x: indexFingerTip.location.y, y: indexFingerTip.location.x), viewWidth,  viewHeight)
    
    // 取得した指先の座標でヒットテストを実施
    if let entity = arView.entity(at: normalizedIndexPoint) as? ModelEntity  {
        // 見つけたボックス・オブジェクトに物理的な力を加える
        entity.addForce([0,40,0], relativeTo: nil)
        // addForceするには、対象のエンティティにPhysicsBodyComponentを与えてください
    }
}
```

ヒットテストで検出するエンティティにはコリジョン（衝突）シェイプが必要です。

```swift
let box = ModelEntity(mesh: .generateBox(size: 0.05), materials: [SimpleMaterial(color: .white, isMetallic: true)])
box.generateCollisionShapes(recursive: false)

```

<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/235259/e394ca3c-0576-eb1e-911a-62162dfbc146.png" width=300>

**[GitHubのサンプルコード：RealityKit-Sampler](https://github.com/john-rocky/RealityKit-Sampler)**

手のポイントの取得について:**[VisionでHand Pose Detection 手のトラッキング:　MLBoyだいすけ](https://qiita.com/john-rocky/items/29c2cf791051c7205302)**

ARオブジェクトの作り方など、RealityKitの取り扱いについて：**[RealityKitの参考書](https://qiita.com/john-rocky/items/77dd077a5778c7ca9369)**
VSCodeのターミナルのデフォルト表示位置を右に変更する方法

VSCodeを使用する際、ターミナルの表示位置を右に変更したいことがありますね、その場合はツールバーのターミナルを右クリックして「パネルを右に移動」を選択すると変更できます。
![キャプチャ.PNG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/694810/b8e8188f-a730-2072-7cb7-6726e81627d7.png)
しかしながら、エディタ起動の際、いつもこの操作をするのは少し面倒なので、デフォルトの表示位置を変更したいと思いました

結論としてはsetting.jsonに`"workbench.panel.defaultLocation": "right"`と追加するのみでデフォルト設定を変更できます。

自分の環境で試しただけなので、もしできなかったら申し訳ないです。


## 参考にしたサイト
stackoverflow "How do I move the panel in Visual Studio Code to the right side?"
https://stackoverflow.com/questions/41874426/how-do-i-move-the-panel-in-visual-studio-code-to-the-right-side
Amazon S3 新ストレージクラスが追加されたので比較してみた

AWS re:Invent 2021にて、S3の新たなストレージクラスの追加が発表されました。

# Amazon S3 新規ストレージクラス
* **Glacier Instant Retrieval** ストレージクラスが追加
* S3 Glacier → S3 Glacier Flexible Retrieval に名称変更

https://aws.amazon.com/jp/blogs/aws/amazon-s3-glacier-is-the-best-place-to-archive-your-data-introducing-the-s3-glacier-instant-retrieval-storage-class/

# 新規ストレージクラス（Glacier Instant Retrieval）の特徴
* アーカイブ向け（四半期に一度程度のアクセス頻度）
* スタンダードや標準-IAと同様ミリ秒単位のアクセス
* 標準-IAと比べ最大68％のストレージコスト削減

# ストレージクラス比較
今回追加されたストレージは、標準 - IA と Glacier Flexible Retrieval （旧 Glacier）の間に位置しています。
下表のストレージクラスのうち、下に行くほど以下特徴があります。

* ストレージ料金（月額データ料金）が安い
* データ取得料金が高い
* 取得時間が長い
* 想定アクセス頻度が低い

|ストレージクラス|ストレージ料金 [^1]|データ取得料金 [^2]|取得時間|想定アクセス頻度|
|:---|:---|:--|:--|:--|
|標準|$0.025|$0.0047|ミリ秒単位|1か月に1回以上|
|標準 - IA（標準 - 低頻度アクセス）|$0.0138|$0.01|ミリ秒単位|1か月に1回|
|**Glacier Instant Retrieval**|**$0.005**|**$0.02**|**ミリ秒単位**|**四半期に1回**|
|Glacier Flexible Retrieval （旧 Glacier）|$0.0045|$0.0343|数分～数時間|1年に1回|
|Glacier Deep Archive|$0.002|$0.065|数時間|1年に1回未満|

※ストレージクラスの比較を目的とした表です。
　料金はデータ量やリージョンで変わってきますが、ここでは代表値を載せてます。
※Intelligent-Tiering、1 ゾーン – IA、Outposts ストレージクラスはアクセス頻度以外の
　要素も入ってくるので対象外としています。

（2021/12/03現在）
　　S3の料金ページなど、日本語版のサイトは上記内容が更新されていないので注意です。
　　言語を英語に変えるとGlacier Instant Retrievalが載ってます。

# 参考サイト

* https://dev.classmethod.jp/articles/reinvent2021-amazon-s3-glacier-instant-retrieval-storage-class/

[^1]: 東京リージョン、最初の50TB/月の料金を記載。GB単位。
[^2]: 東京リージョン、PUT・COPY・POST・LISTリクエストの料金を記載。1,000リクエスト単位。
【基礎知識】アジャイル開発とは？

## 記事の目的

エンジニア・プログラミングを学ぶ中でよく聞く、実際の現場でよく用いられているアジャイル開発について理解を深める

## アジャイル開発とは？

開発手法の一つ。スピーディーな開発と、開発中の変更や追加機能など、柔軟に対応しやすいのが特徴。

アジャイル開発の他にウォーターフォールモデルという開発が主流だったが、2000年代付近でアジャイル開発が登場。

**※ウォーターフォールモデルとは？**

最初に決定させた全体の機能設計・計画に基づいて開発を進めていく手法。機械製造や造船業など、さまざまな開発に応用できる手法

従来ウォーターフォールモデルによる開発が主流でしたが、2000年代以降、新たな手法としてアジャイル開発が登場しました