OmniAICreator/Qiita-1.07M huggingface dataset:
Milk-v duoのpythonでpinpongライブラリを使用してLチカ、探索と成功編

## はじめに
秋葉原ロボット部の有志で、milk-v duoを購入し、個々人が様々な実験を行って、勉強会内で報告しています。

Milk-v duoは9ドルのrisc-vコンピュータとして知られています。
ハードウェアは以下の通りです。

1. CPUはCVITEKのCV1800B (C906@1Ghz + C906@700MHz)
1. 最高1 GHzで動作するデュアルRV64コア
1. 64 MBのラム
1. オプションのアドオンボードを接続すると10/100Mbpsの速度でイーサーネットに接続可能

12月12日の記事、「Milk-v duoのpythonでpinpongライブラリを使用してLチカ、導入と失敗編」でpinpongライブラリを使用できる環境を導入しました。
Milk-v duo上の「pip」の動作はハラハラします。
その後、例に従ってpythonスクリプトを作成しましたが、Lチカの成功に至っていません。

この記事では、pinpongでのGPIOのピンの指定を確認し、Lチカに成功までの話を紹介します。
SDカードイメージは、v1.0.5です。

## PinpongライブラリでのGPIOの設定
Milk-v duoコミュニティでもうまくいかないとの書き込みがありました。
「Does pinpong work yet? Yes!（ https://community.milkv.io/t/does-pinpong-work-yet-yes/827 ）」では、青色LEDのピン番号はD1と記載しています。
この書き込み通り行っても、LEDは点滅しません。

答えは、Milk-v duoのドキュメントにありました。
https://milkv.io/docs/duo/application-development/pinpong
に、ピン番号の表が掲載されています。
ここにも転記しておきます。
| pinpong | ピン名 | ピン番号 |ピン番号|ピン名|pinpong|
| :-: | :-: | :-: | :-: | :-: | :-: |
|0 |GP0|1 |40|VBUS| |	
|1 |GP1|2 |39|VSYS| |	
|  |GND|3 |38|GND| |	
|2 |GP2|4 |37|3V3_EN| |	
|3 |GP3|5 |36|3V3(OUT)| |	
|4 |GP4|6 |35|      
|5 |GP5|7 |34|
|  |GND|8 |33|GND|	
|6 |GP6|9 |32|GP27|27|
|7 |GP7|10|31|GP26|26|
|8 |GP8|11|30|RUN|
|9 |GP9|12|29|GP22|22|
|  |GND|13|28|GND|	
|10|GP10|14|27|GP21|21|
|11|GP11|15|26|GP20|20|
|12|GP12|16|25|GP19|19|
|13|GP13|17|24|GP18|18|
|  |GND|18|23|GND||
|14|GP14|19|22|GP17|17|
|15|GP15|20|21|GP16|16|
| 　 |    |  |  |    |  | 
|25|GP25|LED|

この表に従うと、青色LEDの接続されている場所は、pinpongでは、25となります。
## Lチカに成功しました。
「led = Pin(Pin.D0, Pin.OUT)」を「led = Pin(Pin.D25, Pin.OUT)」に修正します。
```blinkpinpong2.py
# -*- coding: utf-8 -*-

#Experimental effect: Control the UNIHIKER onboard LED light to flash once a second
#Wiring: Use a computer to connect a UNIHIKER main control board

import time
from pinpong.board import Board,Pin

Board("MILKV-DUO").begin() 		#Initialize, select the board type, if you do not enter the board type, it will be automatically recognized.

led = Pin(Pin.D25, Pin.OUT) 		#The pin is initialized as level output

while True:
  led.value(1) 					#Output high level
  print("1") 					#Terminal print information
  time.sleep(1) 				#Wait for 1 second to maintain the state

  led.value(0) 					#Output low level
  print("0") 					#Terminal print information
  time.sleep(1) 				#Wait for 1 second to maintain the state
```
「1」の表示の時に点灯、「0」の表示の時に消灯します。
```
[root@milkv-duo]~# python3 blinkpinpong2.py
milkv-duo

  __________________________________________
 |    ____  _       ____                    |
 |   / __ \(_)___  / __ \____  ____  ____ _ |
 |  / /_/ / / __ \/ /_/ / __ \/ __ \/ __ `/ |
 | / ____/ / / / / ____/ /_/ / / / / /_/ /  |
 |/_/   /_/_/ /_/_/    \____/_/ /_/\__, /   |
 |   v0.5.2  Designed by DFRobot  /____/    |
 |__________________________________________|

1
0
1
0
1
0
1
0
1
0
1
^Cexit_handler
[root@milkv-duo]~#
```
他のGPIOを使ったLチカにも、今後挑戦します。
ブックマークレットを使ってからあげ帝国を転覆させたい

## ブックマークレットを使ってからあげ帝国を転覆させたい

からあげ帝国の弱点は、搾ったレモンをからあげにかけることらしい。
このAdvent Calendarにレモンをかければいいではないか？

ChromeでF12キー押してそれぞれの日付の要素は divタグで class名は style-1dctyxxだった。

ブックマークレット機能を使って、閲覧中の画面内のHTMLを書き換える。
どこかのページをブックマークに追加する。
ブックマークの編集機能でURL欄に以下のJavaScriptを貼り付ける
```javascript:bookmarklet.js
javascript: (() => {
  const elements = document.querySelectorAll("div.style-1dctyxx");
  for (const element of elements) {
    const anchor = element.querySelector("a");
    if (anchor) {
      anchor.textContent = "(🍋レモンをかけた)" + anchor.textContent;
    } else {
      element.textContent = "(🍋レモンをかけた)" + element.textContent;
    }
  }
})();
```
からあげ帝国のAdvent Calendarの記事一覧画面で、設定したブックマークを選択する。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/46247/69f94d34-9dc0-98c7-1d29-eaeb687cf4f4.png)
量子コンピュータと関わるいくつかの行列

### 量子コンピュータは「行列」の世界
- 「Unitary Matrix」（ユニタリ行列）
- 「Adjoint Matrix」(随伴行列)
- 「Complex Conjugate」(複素共役)

:::note info
複素共役、転置した行列が随伴行列、その随伴行列の逆行列がユニタリ行列。
:::

###  Unitary Matrix（ユニタリ行列）
量子演算ゲートの正体は「Unitary Matrix」（ユニタリ行列）。
Unitary Matrixは「Adjoint Matrix」(随伴行列)の逆行列。

```math
U^{\dagger}U = I,  UU^{\dagger} = I,  U^{\dagger} = U^{-1}
```

<details><summary>latex</summary>

```
U^{\dagger}U = I,  UU^{\dagger} = I,  U^{\dagger} = U^{-1}
```
</details>

---

### Ajoint Matrix(随伴行列)
Ajoint MatrixはComplex Conjugate(複素共役)して転置した行列。
転置してから複素共役しても同じ。
```math
A^{\dagger} = (A^*)^{\top}, A^{\dagger} = (A^{\top})^*
```

<details><summary>latex</summary>

```
A^{\dagger} = (A^*)^{\top}, A^{\dagger} = (A^{\top})^*
```
</details>

---
### Complext Conjugate(複素共役)
Complex Conjugateは、yの符号を変更する
例：
```math
Z^* = x - yi
```
の複素共役は

```math
Z^* = x + yi
```
業務アプリケーションにおけるUIデザインについて

# はじめに

最近のインターネット記事・各種のデザインってすごくかっこいいですよね! 業務アプリケーションもこんなかっこよく作りたいなぁと思ったりもしますが、そうもできないもどかしさを記事にしたいと思います。

# そもそもデザインに対する知識がない

業務アプリケーションばかり見てきたせいか、絵心がないのです。

どうすればかっこいいデザインとなるのかの術がないのです。 
こういった心得というのはやはり専門家じゃないと難しいものです。 
ただ、我々にも一般的なモダンデザイン、視線の流れの意識等々できることはありますので、そのくらいは心がけますが・・・

# 時間が限られている

業務アプリケーションを作る上ではもちろん機能実装が優先されます。 
かっこいいデザインでやる気を出してもらいたい!というのは作り手としてはありますが、コストはかかってしまいます。 
そこに費用が追加されてしまうのであればモダンなデザインで・・・となるのは致し方ないのかと。 
では裁量の中で・・・と言えるほどデザインは甘いものではないとも思います。
結局はロジカルな部分にいっぱいいっぱいになりがちです。

# 入力は最小限に・・・できねぇ!

離脱率という観点から入力 を少なくする! 自動入力する!というのは昨今では一般的な考え方だと思います。

ではよし業務アプリケーションに取り入れよう! としたとき、そもそも入れ込む要求とする必要項目が多いためそれができません。

ここにはアプリケーション屋さんとしてではなくDX推進として客先の業務の効率化という側面から変えていかないとこういった考えを取り込むことはできないところとなります。

客先によってこういった考えは受け入れられもするでしょうし、おせっかいだと思われるところもあるでしょう。 
全てが思うように進まないものです。

# 見た目が紙

特に電子化を進めた場合、一定数反対勢力がいるものです。

こういった反対派を説得するなり無理に押し切るといったこともできるでしょうが、折衷案として紙っぽい見た目にすることも一つの方法としてはあります。 
なんなら画面を印刷してハンコをつき始める! なんてことも・・・

印刷しなければペーパーレス化そのものにはなるのでしょうが、働き方としての改善にはあまりなりません。

# 結局それぞれ苦悩のポイントがあるということ

一般大衆に向けたページ、特定の人に向けたページそれぞれで苦悩がありそうですね。

あるべきデザインにもっていかなければならない前者。 
あるべきデザインにもっていきたいがそれがなかなかできない後者
どちらがいいとは言いませんが、お互いにそれぞれの理由で苦悩しいるのでしょう。
DockerでDataikuを最速で始める

この記事は[KDDI Engineer & Designer Advent Calendar 2023](https://qiita.com/advent-calendar/2023/kddi)の5日目として投稿されたものです。  
このアドベントカレンダーは「KDDIのみんなでTechな記事を書こう！お仕事に関係しても関係なくてもOK！」という企画となっています。  
ちなみに、本記事は私自身のお仕事とは関係ないものです。  

# Dataikuとは

DataikuはAI/MLワークフローをGUIで構築できるプラットフォームです。  
自分で用意したPCやサーバやクラウドにインストールして使える無料版、マネージドでも使える(SaaSとして利用できる)有償版があります。  
有償版ではSnowflake/BigQueryへの接続やSpark対応など様々な機能が解禁されますが、無料版でもかなりのことができます。  
また、有償版は14日間の無料トライアルもあるので、サーバなんて持ってないよ！という方でもすぐにDataikuを体験することができます。  

![Dataiku Screenshot](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2917580/0e889b2b-31b0-1ad4-80ac-e2702fc2d7db.png)

ちなみにDataikuは「ダタイクゥ」あるいは「データイクゥ」と発音するようです。初期からのユーザは「ダタイク」、最近のユーザは「データイク」と呼んでいることが多い印象。  
参考：[Dataikuのカンファレンス「Everyday AI」におけるCROの発音](https://youtu.be/iJj2UvilOJ0?t=53)  

https://youtu.be/iJj2UvilOJ0?t=53

## Dockerで導入しよう

:::note warn
以下の手順で導入されるDataikuは最新版ではないのでご注意ください。(2023年12月時点)  
:::

本記事では、Dataikuの無料版を導入していきます。  
実は本当に最速なのは[Windows版](https://www.dataiku.com/ja/%E8%A3%BD%E5%93%81/%E5%A7%8B%E3%82%81%E3%82%8B/windows/)の導入らしいのですが、まだ公式にサポートされていないので、Dockerで試してみましょう。  

リポジトリは今回は[こちら](https://hub.docker.com/r/dataiku/dss)を使っていきましょう。  
ユーザ名はそれっぽいんですが残念ながらなんだか公式のものではなさそう。  

https://hub.docker.com/r/dataiku/dss

```sh
sudo docker pull dataiku/dss:latest
sudo docker run -p 10000:10000 -d dataiku/dss
```

これで起動したはずなので、```docker ps```コマンドで確認してみます。  

```raw
> sudo docker ps
CONTAINER ID   IMAGE         COMMAND                  CREATED        STATUS        PORTS                                           NAMES
2c53180041ea   dataiku/dss   "/home/dataiku/run.sh"   1 hours ago    Up 1 hours    0.0.0.0:10000->10000/tcp, :::10000->10000/tcp   modest_dubinsky
```

起動していますね。  
ポート10000にコンテナのポートを公開しているので、Webブラウザで```localhost:10000```にアクセスすればOK！  
最初にユーザ登録が必要なので回答していきましょう。  

![Dataiku Initial Setup 1/4](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2917580/2fe17eb8-a25d-0b5b-8af6-7a2e0dfcd49b.png)

![Dataiku Initial Setup 2/4](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2917580/a6631d26-a681-0a66-12d6-00ab0de1ada8.png)

![Dataiku Initial Setup 3/4](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2917580/a1bac2e0-b4cf-982b-a2a2-5dace9e5191f.png)

![Dataiku Initial Setup 4/4](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2917580/53ff87ff-a897-05e7-2b2f-cb6e886e8a35.png)

## インストールしたけど次にどうしよう

ぜひ[Dataiku Academy](https://academy.dataiku.com/page/ja)のコンテンツにチャレンジしてみてください！  
かなり丁寧なチュートリアルコンテンツが掲載されています。しかも日本語対応！  

https://academy.dataiku.com/page/ja

AI/MLを初めてみたいけどプログラミングはハードルが高いな…という方、ぜひDataikuを触ってみませんか？
【統計学】期待値・推定・信頼度

# ０.はじめに
大学で統計学の講義を受講している者です。
用語や概念をまとめて以下の項目に分類しています。

##### 統計学学習全体像
[【統計学】概要](https://qiita.com/AkihideKato/items/084ace871bb867635f1d)
[【統計学】度数・偏差・分散](https://qiita.com/AkihideKato/items/dd06906886521a27bb39)
[【統計学】係数・回帰](https://qiita.com/AkihideKato/items/ea4b64a8a69b21ff25ac)
[【統計学】集計表](https://qiita.com/AkihideKato/items/3c139087ec6f5462e2b4)
[【統計学】集団・標本](https://qiita.com/AkihideKato/items/dae23d8d09a764e158aa)
[【統計学】分布](https://qiita.com/AkihideKato/items/6daf349eef4e98b38a91)
[【統計学】期待値・推定・信頼度](https://qiita.com/AkihideKato/items/43672f6d69af9cebc5e6)
[【統計学】統計的検定](https://qiita.com/AkihideKato/items/6b8eff70b66ee3513141)

# １．期待値（E(x),μ）
確率的に得られる値の平均値
起こりうる事象で得られる値とそれが起こる確率の積を足し合わせる
```math
計算式
```
```math
{x個数 × 確率p(x) }の総和
```
```math
\sum_{k=1}^{n} x_kP_k 
```

### 平均値との関係			
- **``平均値``**：回数試行した場合の値の合計を試行回数で割ったもの
- **``期待値E(x)``**：値(xi)×確率(pi)を全て足して得られる結果の期待される値		
```math
E(x) = \sum_{i = 1}^n{}x_ip_i
```
### 母平均μ = 標本平均の期待値E(x)
``大数の法則``により母平均と標本平均の期待値は等しい

# ２．点推定・区間推定
### 点推定			
標本より``600世帯``に調査を行ったところ``240世帯``が視聴している番組がある		
この場合の母集団の視聴率は``240/600 ×100 = 40%``		
おおよそ母集団は``40%``と判断できる		

### 区間			
母数がここから～ここら辺にあるのではないかという範囲		
区間の幅は信頼度という指標により誤差範囲が異なる		

### 区間推定			
標本より``600世帯``に調査を行ったところ``240世帯``が視聴している番組がある		
この場合の母集団の視聴率は``240/600 ×100 = 40%``		
±4誤差として考えると、``36~44%程``に収まる範囲となる	

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/581998/604541f3-3c49-4a8d-9c0a-d6ab03ef8d5f.png)


# ３．信頼度
**母数を含んでいるか信頼できる度合い**

＜標本3と11は母集団から外れている＞
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/581998/123a81f5-4eb3-b295-7d87-cdec3902ec05.png)


### 信頼度95%について
``95%``に母数が含まれているような区間の作りのこと
**母数が入っている確率が``95%``というわけではない**
``100回``のうち``95回``は真、``5回``は偽である範囲
**``→全体のうち95%程度の回数で信頼区間の中に母数が含まれているような区間の作り``**

### 信頼区間
範囲のこと
先述でもしたが``100回中5回``は外れるが``95回``は母数が含まれるような区間のこと

```math
関数
```
```math
=NORM.INV(上側/下側の確率,平均,標準偏差)
```

### 例題
日本人の``20~24歳男性``の平均身長を知りたいので標本として``1516人``を無作為抽出し
身長を測定した結果、平均``171,95cm``だった。また母集団は正規分布に従い
標準偏差は経験的に``5.59cm``であるとする。
母平均の点推定値及び``95%``信頼区間を求める
``＜全体n = 1516、標本平均期待値 = 171.95、標準偏差 = 5.59＞``

### A.
#### １．母平均μは標本平均の期待値である
よって``171.95``が平均となる

#### ２．95%信頼区間を関数NORVで求める
上側と下側と確率を分けて考える
- ``上側確率は100-95 = 2.5%``
- ``下側確率は100-2.5 = 97.5%``

#### ３．標本平均の標準偏差を求める
問題文より母集団の標準偏差（σ）は``5.59``
``V(x̄)``の標準偏差は``σ / √n``で求めらえる
``5.59/ √1516 = 0,144``
この値を関数に使用する

#### ４．計算
``=NORMINV(0.025,171.95,0.144) = 171.67``
``=NORMINV(0.975,171.95,0.144) = 172.23``

よって母平均の``95%``信頼区間``171.67~172.23cm``となる
Kaggleでチュートリアルコンペ以外のコンペに参加した

Kaggleでチュートリアルコンペ以外のコンペに参加しました。
Titanic以外のコンペを探すところからコンペ参加までの流れを書いておきます。

# Titanic以外のコンペを探す
Titanic以外のコンペを探します。
下記の記事を参考にしました。

https://atmarkit.itmedia.co.jp/ait/articles/2108/30/news033.html

コンペが、Kaggle初心者向けにわかりやすくまとめられています。
この記事では、Titanicと同じ二値分類のコンペとして、[Tabular Playground Series - Apr 2021](https://www.kaggle.com/c/tabular-playground-series-apr-2021)、[Home Credit Default Risk](https://www.kaggle.com/c/home-credit-default-risk)、[Porto Seguro’s Safe Driver Prediction](https://www.kaggle.com/c/porto-seguro-safe-driver-prediction)が紹介されていました。

今回は、Tabular Playground Series - Apr 2021に参加することにしました。

# Tabular Playground Series - Apr 2021

https://www.kaggle.com/c/tabular-playground-series-apr-2021

Overviewタブには、このコンペのデータセットは、Titanicに基づいて生成されたことが書いてあります。
Titanicではtrainデータが891行、testデータが418行であるのに対し、このコンペではtrainデータが100000行、testデータが100000行と、このコンペのほうがデータサイズが大きいようです。

CodeタブからNew Notebookボタンをクリックし、新しいノートブックを作成しました。
[upuraさんのTitanicのノートブック](https://www.kaggle.com/code/sishihara/upura-kaggle-tutorial-01-first-submission/notebook)を参考にしました。
コードを以下に記載します。

```Python
# NumPyとpandasのインポート
import numpy as np
import pandas as pd
```
```Python
# データの読み込み
train = pd.read_csv("/kaggle/input/tabular-playground-series-apr-2021/train.csv")
test = pd.read_csv("/kaggle/input/tabular-playground-series-apr-2021/test.csv")
sample_submission = pd.read_csv("/kaggle/input/tabular-playground-series-apr-2021/sample_submission.csv")
```
```Python
# trainとtestの連結
data = pd.concat([train, test], sort=False)
```
```Python
# 欠損値の確認
data.isnull().sum()
```
```Python
# データ前処理
# Sex
data['Sex'].replace(['male','female'], [0, 1], inplace=True)

# Fare
data['Fare'].fillna(np.mean(data['Fare']), inplace=True)

# Embarked
data['Embarked'].fillna(('S'), inplace=True)
data['Embarked'] = data['Embarked'].map( {'S': 0, 'C': 1, 'Q': 2} ).astype(int)

# age
data['Age'].fillna(data['Age'].median(), inplace=True)

# Age、PassengerId、Name、Ticket、Cabinの削除
delete_columns = ['Age', 'PassengerId', 'Name', 'Ticket', 'Cabin']
data.drop(delete_columns, axis=1, inplace=True)
```
```Python
# 学習データとテストデータの抽出
train = data[:len(train)]
test = data[len(train):]

y_train = train['Survived']
X_train = train.drop('Survived', axis = 1)
X_test = test.drop('Survived', axis = 1)
```
```Python
# 機械学習
from sklearn.linear_model import LogisticRegression

clf = LogisticRegression(max_iter=1000)
clf.fit(X_train, y_train)
y_pred = clf.predict(X_test)
clf.score(X_train, y_train)
```
スコアは0.75825でした。
```Python
# 提出
sub = sample_submission
sub['Survived'] = list(map(int, y_pred))
sub.to_csv("submission.csv", index=False)
```

Public Scoreが0.79817になりました。

このコンペは、2021年に終了しているためLeaderboardタブに順位は載りませんが、Titanicの次のコンペを探している方にちょうどよいと思います。

次はTitanicやTabular Playground Series - Apr 2021のスコアを上げたいです。
また、他のコンペに参加したいです。
コンポーネント設計書に必要なものってなんだろう

# はじめに

前々回「ため息が出るDB設計書」、前回「画面設計ってどんな要素が必要だろう」の最後としまして今度はコンポーネント設計について記載します。
https://qiita.com/jun2/items/f4be237fed04c88dc1f5
https://qiita.com/jun2/items/5e0c0090cba9b05ab5ee

大きな内容は画面設計と共通なので、共通モジュールとして開発した場合のコンポーネントについて、もう少し詳細に「書いた方がいいと思うもの」を書きたいと思います。 
設計する規模も小さいので短めです。
nuxt.jsペースとなります。

# 書いた方がいいと思うもの

* 概要

どんなコンポーネントなのか?このコンポーネントを使うとどんなことができるのか?
* 見た目
* props
プロパティ名、型と説明
* defineExpose 
何が公開されている変数関数なのか
* emit
何が発生するとどんな通知が来るのか。引数があるのであればその型
* event
概要の詳細として、発生イベントに対する詳細説明
* dependency
依存している他のコンポーネント、他のプロジェクトファイルなど

ここでも何をテストすべきなのか?と考えながら書くことが重要と考えます。 
また、利用する側が実装を見ることなく実装できるような説明となっているか?という点も考慮が必要です。

上記はatoms - moleculesくらいの設計内容だと思います。 
これよりも大きな規模だと画面設計書のエッセンスも入れながら記載した方が良さそうです。

# 終わりに

全3回で設計について考えていることをアウトプットしてまいりました。

昔先輩に「良い設計書はそのままテスト仕様書になる」と教えられ感銘を受けたことからずーーっと後輩指導にも同じことを言い続けております。

少しでも賛同いただける方がいらっしゃれば幸いです。
画面設計書ってどんな要素が必要だろう（nuxt）

# はじめに

前回「ため息が出るDB設計書」について触れてきましたが今度は画面です。
https://qiita.com/jun2/items/f4be237fed04c88dc1f5
皆さんは画面設計書は作っていますか?

なんとなく画面が貼ってあるだけの設計書や表示する項目の説明をこれでもか!と記載した設計書がありますが、何をどこまで書くとよいのでしょう。 
正解はないのかもしれませんが、こういった観点ではどうでしょう?という提案です。

# 書いた方がいいと思うもの

* テストするときに確認が必要な項目（以下例）
  * 検索はorで検索される。
  * 更新が重複した場合はリロードする 
* バリデーションされる種類・内容
* ユーザー操作により考えられるエラーパターン
* (VueやReactのようなものの場合) 利用しているコンポーネント
* 更新が重複しうる場合など
* 設計意図とそのエビデンス

全部詳細を書きたいことですが今回は最後をピックアップしたいです。
なんでこうなってるの?誰がこの動きを決めたの?客先からの指示など後から引き継がれたものは思いがちです。

頭の中にだけ入っているこのようなノウハウこそ設計書に記載されていると、意味のある設計書になると思います。

よって、設計意図とそのエビデンスというのは特にも重要と考えます。

# 別に書かなくてもいいと思うもの

* ある程度常識として捉えてほしいこと
* 通貨項目は右揃えである、カンマ区切りである
* 認証失敗時には認証エラーを表示する
* 登録ボタンを押したら登録を行う
* 特に表など表示項目のただの列挙 (ただし意味の説明が必要なものはあった方がよい) 
* 「XXメニューというボタンを押下するとXXメニューに遷移する」

見てわかるものは書かなくてもいいよねということです。

# 何の媒体で作成するとよいか

個人的にはマークダウンなりテキストでの記載が良いと思います。 
理由としてはテキストは変更点の追従がしやすいからです。 
Officeでも変更点の追跡は可能ですが、個人的にはGit + マークダウンでの記載を行うことでいつからこうなったんだろう?などの追跡がやりやすいと感じております。
ため息が出るDB設計書

# はじめに

私自身、データベースというものを触り始めてから10年程度しかたっていないものでまだまだ未熟者です。
そんな私でもため息が出てしまうDB設計に出会ってしまうものです。

最初は特になにも思わなかったのにこんなことを思うようになったのは心が汚くなったか、成長したかのどちらかでしょう。

# エクセルの項目そのままになっている

エクセルも確かに見た目がなのでそのままにしたい気持ちはわかります。

システム化する対象の元がLOOKUP系でリレーショナルに使いこなしているものをデータベース化したものであればまだよいのですが、大体はそのようにはなっていないでしょう。

よくある例がこんな感じでしょうか。

| id | 名前 | 商品1 | 商品2 | 商品3 |
| ----- | ----- |  -----| ----- |-----  |
|1|太郎 |0|0|0|

商品追加されたらカラム増やすのか・・・? 要は正規化という考え方がうまくできていなかった時代があった、ということなのだろう。

# 型が適当

* なんでも文字列にしているパターン。

日付など20000101 というようにcharにしてしまっている。

大小比較などまぁできてしまうのだが、日付としての正当性の検証ができなくなってしまう。

* char varcharの使い分け

桁数が完全に固定でcharを使っているのはわかる。
欲を言えば検査制約がつけばよりよいだろう。
一方桁数が固定ではないのにcharを使っている、未設定に空白を使っている。
これはしんどい。

␣␣␣␣1などアプリケーションからすると何だこれという値が返ってくることは経験ないだろうか? 型が固定ではないならvarchar、未設定なのであればnullなど適切な型制約をつけるべきだろう。

# 外部キー制約がない

正規化の話にもやや関係するが、例えば商品コードなどといったものはシステムで一意であるものだろう。 
それなのに各テーブルで独立した商品コードが存在してしまうと、データの整合性が取れなくなってしまうのは想像にたやすいだろう。

# カラム名が独特すぎる

実例ではないがこんな感じ
顧客氏名→kkysmi (kokyakusimei)
わからない。
カラム名に名詞がついていない(もしくは省略されすぎていて想像力が必要)である場合のことである。

name とか customer_nameでいいだろう。。。

# おわりに

色々書きましたが、当時制約などといった機能そのものがなかったりするかもしれないので致し方ない部分はあるでしょう。

大事なのは、こういった使い方に対して、「なんだこれ」と思うことだと思います。 
そう思うということは今現在のRDBMSにおいてある程度適切な使い方をわかっているということなのでしょうから。
jQueryをやめようとしたが断念した話

# はじめに

こちらの記事
https://qiita.com/jun2/items/2e3d8ec30664058567f6
にてjQueryをやめようと試みたのですが、できなかったという話を記事にしたと思います。

ここではもう少し詳細に記載したいと思います。

# 紙形式のUIに弱い

業務系アプリケーションを手掛けている方のあるあるだと思うのですが、印刷を意識する必要が出てきます。 
ActiveReportといった帳票系のツールを使っていれば簡単に解決できるのですが、cssだけで頑張ろうとするとどうしてもjQueryに頼らざるを得ない部分が出てきます

通常のWeb画面ですと、画面の区切りはあまり気にしません。
あえて言えばなるべくスクロールしないように・・・などといったところでしょうか?

しかし、紙形式を意識する場合ページ区切りをどうしても意識する必要があり、改行が入ってしまったりするとレイアウトが崩れはみ出したりするなどの現象が発生してしまいます。 
完全なSSRの形式だとここが厄介となります。

# 何とかなる場合もある

何とかなる場合として、「見切れてもいい」「文字数が絶対的に限られている」 「ページ数が固定」である場合です。 
この場合折り返しも発生しませんのでレイアウトを固定化することができるため、SSRでも実装が可能となります。

# なんともならない場合

問題は「見切れるのはNG」 「折り返しも許容する」 「不特定の繰り返し行がある」といった場合です。
こうなってくるとページ区切りをする上で必要となるのは実際に描画されているオブジェクトの高さです。
SSRですと描画されていないため、この計算ができずどこで改ページすればいいかわかりません。

そもそも ページ数が不特定であるため、 何ページ用意すればよいのか(特定の場合では解消できますが)というのすらわかりません。 
こういった問題は描画された後に表示されている且つ、オブジェクトを直接参照できるjQueryはとても頼りになります。

# おわりに

・・・まずもう紙をやめてくれ。..

これに限るのですが、提案はできますが決定権は作る側にはなかなかありません。。ただし、有用性を訴える事はできます。

それでも印刷を求めるのであれば当然実現させるしかありませんので、何とかする次第です。
初めてQiitaアドベントカレンダー作成・参加しました。構造化された日本語って意味わかります？

# はじめに

初めてQiitaに記事投稿したのが今年2023年の1月22日ですので、今回のアドベントカレンダーが初参加となります。

# 初めて作成したアドベントカレンダー

初めて作成したアドベントカレンダーは日本語プログラミング言語関連のテーマにしたものです。

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

Qiitaでは主要な日本語プログラミング言語の開発者の方がアカウントを持たれて、各言語ユーザーの方々が活発に記事投稿されていますが、著名な外国製（英文字系一部日本発あり）プログラミング言語に慣れているQiita参加者の一部の方々からその有用性について疑問を投げかける心無いコメントもなくはないようです。


確かにシステムやアプリケーションの職業的な開発実装に使われている言語は、数えきれない言語の中でも数えれる程度には収れんするので、英文字勢ですらしのぎを削っている状況に日本語プログラミング言語が大々的に一般的に使用されるようになる余地はまだなさそうです。

そこでわたしの方では、実装開発用途の日本語プログラミング言語とは別に、設計要件定義用の日本語プログラミング言語の可能性について話題とするカレンダーを作成してみました。

# テーマの補足
以下はカレンダーに記載内容の再掲です。

:shinto_shrine:システムの開発現場:pick:
:no_entry_sign:実装言語のソースコードとしてコメント以外で日本語:flag_jp:を導入することに抵抗がある
:shinto_shrine:システムの設計現場:triangular_ruler:
:no_entry_sign:自然言語の日本語:flag_jp:であいまいな表記が多用されており、数学的形式言語は上流工程の予算が潤沢または使用が必須に近い案件に限られている
:o:英語:flag_gb::flag_us:由来の数学的形式言語:flag_at:では日本語識別子:flag_jp:を多用して、構造化日本語仕様書としている場合がある
　　　　　:arrow_down:
:shinto_shrine:ドメスティックなシステム開発案件の共通言語として構造化されている日本語:flag_jp:すなわち日本語プログラミング言語:flag_jp:が導入できないか　:arrow_right:　検討


# おわりに
Qiitaに投稿される記事の内容は圧倒的に実装にまつわる内容が多く、システムエンジニアなどの設計に携わる方の記事は比較的少数派のような印象があります。統計をとったわけではないので、あくまで印象です。

実装がメインの職種の方には不要に見える日本語プログラミング言語ですが、れっきとした構造化されたコンピュータ言語ですので、いろいろあいまいさの残る設計フェーズでこれらを活用できないかと頭の体操をするカレンダーです。

いろいろな立場からのご参加をお待ちしております。
変更点に対するテストの考え方

# はじめに

テストってどうしても抜けが出てきてしまうものですよね。

抜けもれなく!網羅的に! などとよく言うものですが完璧な人間でない限りは難しいです。
(それでも経験から精度はあがっていくものではありますが。)
特にも作成中のテストよりも、稼働中システムに対する変更というのには非常に気を使う必要があります。
この変更点に対してのテストの考え方について記載したいと思います。

# 変更点をテストするのは当然である

簡単な例を取り上げます。

例えばフォーカスアウトしたときにカンマ編集するようにしてほしい。 こういった要求を受け、(以下例)

```
focusoutイベント((obj) => {
 obj. value = obj. value. replace(/, /g,"")
}) 

focusinイベント((obj)=> {
 obj. value = obj. value. toLocaleString();
})
```


こんな感じのコードを組んだ時にこの2つのイベントについてテストしますよね。 これは新人だろうが、アルバイトだろうがこれはやると思います。

そんな中で例えば
```
focusinイベント( (obj) => {
 obj. value = obj. value. replace (",","")
})
```

こんなコードを作っていて、100万単位が入力されたときにうまく動かない! というのはテストの中で検知されるのかなと思います。

# 大事なのは変化点

見落としがちなのは変化点です。 
上記例にてobjのvalueを参照しようとしていたメソッドなどではこれまで数値として取り扱いできていたものが、文字列になってしまう変化がうまれます。 
こうなってしまうと例えば加算を行っていた場合、文字列結合になってしまうなどの弊害が発生します。

これは変化点をちゃんと検討して、参照しているメソッドの検証をすべて行っていないといけませんよね? こういった変化点の検討・検証を行うというのは経験不足なエンジニアは見落としがちなものとなります。

# 終わりに

ここでは簡単な例を取り上げましたが、レビューアはこういった変化点の検討ができているのか? という観点でレビューしてあげなければいけないなと思います。
デグレードが多くて困っている! などの技術者の方、後輩をお持ちの方の参考になれば幸いです。
サブモジュールを使ってのコンポーネント開発

# はじめに

コンポーネント開発を行う上で資産の共通化をしたいと思うのは自然なことだと思います。

GitLab上でどのような管理することでこれを実現できるのかを考えましたので記事にしたいと思います。

コンポーネント用のプロジェクト

例としてcommon_component プロジェクトであったとします。

GitLab上にcommon_componentを立ち上げ、その中にコンポーネント開発を行っていきます。 Atomic Designで作成するプロジェクトであれば以下のような形でしょうか
```
root/
 - atoms
 - molecules
 - organism
 - template
```
pageは個別のプロジェクトでの開となると考えていますが、必要であれば追加すればよいと思います。 
また、ここにリファレンス集がおかれるとよいでしょう。 目次を作成し、マークダウン形式でリファレンスを作成するなど良いかと思います。

ここでポイントがあります。

①テストはバージョンごとにコンポーネント単位で完結させておく
②命名規則、公開関数、通知などは画一的に行う。
③プロジェクトの依存はルールを設ける
ことです。

## ①テストはバージョンごとにコンポーネント単位で完結させておく

これは普通何かしらのライブラリを使用する際に、ライブラリ内部のテストはしませんよね? というだけになります。

単純にフォーカスアウトしたらカンマ区切りにするようなコンポーネントであれば、それを保証しましょうというだけです。 
このテストは利用者側のプロジェクトで行われるべきではないという主張になります。

## ②命名規則、公開関数、通知などは画一的に行う

これも一般的なお話しです。

が、コンポーネント・開発において社内にその地位が確立されていればよいのですが、有志による活動になってしまう企業様もあるのではないでしょうか? こういった場合に有志による活動に対する画一的なルールが設けられているというのは少ないと思われ、個人の量によるところが強くなってしまうと思います。 
このような効率化の為の活動において後々属人化につながっていきますので、気を付けるべきことであると考えます。

## ③プロジェクトへの依存はルールを設ける

これは私も頭を悩ませたのですが、できればプロジェクト(共通関数を定義しているなど)はあまり設けたくありません。
が、utilityな関数はコンポーネントとは別に定義したい関係上、複数同じような関数を設けることはしたくなく致し方なく依存を設けました。

ルールといっても、依存しているプロジェクトが存在していなければエラーが出るのですぐ気づくようなものですが、ドキュメントに記載するなどの措置で我慢しています。

場合によっては構成毎のブランチでもいいかもしれません。
が、マージが・・・というところがあり今のところはあまり取り組みたくない方です。

# プロジェクト構成

上記、「他プロジェクト・・・」 の例も含めて以下の構成管理を案といたします。

例)
```
project
 - common_component (submodule)
 - atoms
  - XXinput. vue (utilの関数を使用したい)
 - util (submodule)
 - common_function, ts
 - 他プロジェクトファイル
```

# おまけ submoduleの追加・ submoduleを含んだプロジェクトのclone

プロジェクトへのsubmoduleの追加

```
git submodule add http://iccgit01/XXXX. git 追加したいディレクトリ
```
submoduleを含んだプロジェクトのcloneはリカーシブに行う必要があります。
```
git clone --recursive http://iccgit01/XXXXXXXXX. git
```
Macで Apache の mod_auth_openidc を使う

mod_auth_openidc のMac用バイナリは提供されていないので、自力でコンパイルして組み込んだのですが、紆余曲折してやっと使えるようになったので記録しておこうと思います。

Macのローカルブラウザアプリをインターネットからアクセスできるようにしたくて、閲覧許可にOpenIDConnectを使いたかったのですよね。

# 環境

* macOS Monterey
* Apache 2.4.55 (Homebrew)
* mod_auth_openidc 2.4.9.4

# 手順

Homebrew版のApacheを使うので、デフォルトでインストールされているApacheを停止しておきます。

(デフォルトのApacheでもいいのですが、コード署名が必要なので、その場合はコンパイルした mod_auth_openidc.so に署名して使うことになります)

```
$ sudo apachectl stop
$ sudo launchctl unload -w /System/Library/LaunchDaemons/org.apache.httpd.plist
```

Homebrewをインストールしていない場合はインストールします。

```
$ /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
```

ビルドに必要なパッケージをインストールします。

( openssl も cjose のビルドに必要ですが、2023年2月現在OpenSSL3系だとビルド中にエラーが起きてしまうようなので、 curl が依存している openssl@1.1 を使いました)

```
$ brew install curl jansson pcre apr-util apr httpd autoconf automake pkg-config libtool
```

cjoseをビルドしてインストールします。

```
$ mkdir ~/Documents/src
$ cd ~/Documents/src/
$ git clone https://github.com/cisco/cjose.git
$ cd cjose
$ ./configure CFLAGS="-I/usr/local/include" --with-openssl=/usr/local/opt/openssl@1.1 --with-jansson=/usr/local/opt/jansson --prefix /usr/local/opt/cjose
$ make
$ make install
```

mod_auth_openidc をビルドします。

(v2.4.10以降だとなかなかコンパイルが通らなくてv2.4.9系で妥協しています)

```
$ cd ~/Documents/src/
$ git clone https://github.com/zmartzone/mod_auth_openidc.git
$ cd mod_auth_openidc
$ git checkout refs/tags/v2.4.9.4
$ ./autogen.sh
$ ./configure CJOSE_LIBS=-L/usr/local/opt/cjose/lib CJOSE_CFLAGS=-I/usr/local/opt/cjose/include OPENSSL_LIBS=-L/usr/local/opt/openssl@1.1/lib OPENSSL_CFLAGS=-I/usr/local/opt/openssl@1.1/include
$ make
$ make install
```

モジュールを読み込みできることを確認します。

```
$ vi /usr/local/etc/httpd/httpd.conf
  :
LoadModule auth_openidc_module lib/httpd/modules/mod_auth_openidc.so
  :
$ sudo apachectl configtest
```

モジュールがうまく組み込めたら、ウェブ上で散見される手順に従って設定すれば動作するでしょう。

## 参考サイト

https://lifewithcode.blogspot.com/2016/10/securing-apache-on-osx-using.html
mruby/cでLチカ

初めて使うマイコンで最初にやることはLチカですね。
縁があって、mruby/c(エムルビースラッシュシー)に触れることになりました。
ラズパイPicoやESP32にも書き込みできるようですが、今回はRBoard_PIC32を使いました。

RBoard｜株式会社島根情報処理センター
https://www.sjc-inc.co.jp/service/rboard

RBoard公式ドキュメント
https://yoshihiroogura.github.io/RBoardDocument/

本記事では、RBoard_PIC32に組み込まれているLEDに対して、Lチカを実装してみます。

RBoard公式ドキュメントにmruby/cのIDEの使い方がありますので、RBoardをPCにUSBケーブルでつないで、下記のプログラムを書き込むだけです。

```ruby:main.rb
PIN = 6
pinMode(PIN, 0)
while true
  digitalWrite(PIN, 1)
  sleep(0.5) 
  digitalWrite(PIN, 0) 
  sleep(0.5) 
end
```

pin0,1,5,6が組み込みLEDです。今回は6を指定しました。
<img width="600" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/195542/b17839d6-f5c1-8958-d505-549622740da7.png">

ボードに内臓されているLEDが0.5秒おきに点滅します😄
<img width="600" src="https://esusan.s3.amazonaws.com/mruby_l_chika.gif">
Milk-v duoのpythonでpinpongライブラリを使用してLチカ、導入と失敗編

## はじめに
秋葉原ロボット部の有志で、milk-v duoを購入し、個々人が様々な実験を行って、勉強会内で報告しています。

Milk-v duoは9ドルのrisc-vコンピュータとして知られています。
ハードウェアは以下の通りです。

1. CPUはCVITEKのCV1800B (C906@1Ghz + C906@700MHz)
1. 最高1 GHzで動作するデュアルRV64コア
1. 64 MBのラム
1. オプションのアドオンボードを接続すると10/100Mbpsの速度でイーサーネットに接続可能

Milk-v duoの1.0.5のディスクイメージでは、pythonでpinpongライブラリを使用可能になっています。
Milk-v duo communityで公開されている例に従って、Lチカに挑戦します。

## スクリプト例
「参考」のサイトにスクリプト例が掲載されています。
中国語のコメント部分を、英語に変更して転記しています。
```
# -*- coding: utf-8 -*-

#Experimental effect: Control the UNIHIKER onboard LED light to flash once a second
#Wiring: Use a computer to connect a UNIHIKER main control board

import time
from pinpong.board import Board,Pin

Board("MILKV-DUO").begin() #Initialize, select the board type, if you do not enter the board type, it will be automatically recognized.

led = Pin(Pin.D0, Pin.OUT) #The pin is initialized as level output

while True:
  led.value(1) #Output high level
  print("1") #Terminal print information
  time.sleep(1) #Wait for 1 second to maintain the state

  led.value(0) #Output low level
  print("0") #Terminal print information
  time.sleep(1) #Wait for 1 second to maintain the state
  ```
動作させてみます。
  ```
  [root@milkv-duo]~# python3 blinkpinpong.py
milkv-duo

  __________________________________________
 |    ____  _       ____                    |
 |   / __ \(_)___  / __ \____  ____  ____ _ |
 |  / /_/ / / __ \/ /_/ / __ \/ __ \/ __ `/ |
 | / ____/ / / / / ____/ /_/ / / / / /_/ /  |
 |/_/   /_/_/ /_/_/    \____/_/ /_/\__, /   |
 |   v0.5.2  Designed by DFRobot  /____/    |
 |__________________________________________|

1
0
1
0
1
0
1
0
1
0
1
0
1
0
1
  ```
ん！LEDは点滅しない？
エラーが出ていないので、LEDの指定が間違っているようです。
PinpongでGPIOがどのように設定されているか探索します。

参考　https://community.milkv.io/t/milkv-duo-pinpong-python-led-python-3-9/615
React&Node.jsでアプリ作ってみた

# 概要
現在地から1km圏内の飲食店をランダムで選んでくれるアプリ

Node.jsでGoogleMapsAPIのPlacesにあるNearbySearchでレストラン探してフロントに投げる

# 背景
友人と遊んでいるときに飲食店選びで困ったので作ってみようと思って作ったアプリ

# 使ったもの
* React
* Node.js
* ChatGPT
* github copilot(educationで無料)
* GoogleMapsAPI

# 実装

https://github.com/sushi404/choice_shop


## 現在地取得
フロント
``` jsx
export function getUserLocation() {
  return new Promise((resolve, reject) => {
    navigator.geolocation.getCurrentPosition(
      position => {
        resolve({
          lat: position.coords.latitude,
          lng: position.coords.longitude
        });
      },
      error => {
        reject(error);
      }
    );
  });
}
```


## API叩く
バック
apikeyはconfig.jsに保存しmodule.exportsした
(.env使いたかったけど使えなかった...)

``` js
const axios = require('axios');
const config = require('./config.js');

module.exports.fetchRestraunt = async function(lat, lng) {
    const apiKey = config.apiKey;
    console.log(apiKey);  // デバッグ出力
    const url = `https://maps.googleapis.com/maps/api/place/nearbysearch/json?location=${lat},${lng}&radius=1000&type=restaurant&language=ja&key=${apiKey}`;
    try {
        const response = await axios.get(url);
        console.log(response);  // デバッグ出力
        const data = response.data;
        const nearbyRestaurants = data.results;
        return nearbyRestaurants;
    } catch (error) {
        console.error(error);  // エラーハンドリング
    }
}
```
lat=緯度
lng=経度
radius=距離(m)

使ったgooglemapのapi
- Maps JavaScript API
- Places API

## 飲食店をランダムで選ぶ
バック
 ``` js
 function choiceRestraunt(nearbyRestaurants) {
    const randomIndex = Math.floor(Math.random() * nearbyRestaurants.length);
    const selectedRestraunt = nearbyRestaurants[randomIndex];
    return selectedRestraunt;
}

module.exports.choiceRestraunt = choiceRestraunt;
```

## 表示
フロント
``` jsx 

export function printRestraunt(selectedRestraunt) {
    // Get the restaurant details
    const name = selectedRestraunt.name;
    const address = selectedRestraunt.vicinity;
    const rating = selectedRestraunt.rating;
    const place_id = selectedRestraunt.place_id;

    // Update the UI to display the details of the selected restaurant
    // ...
    return(
        <div>
            <h1>店名:{name}</h1>
            <h2>住所:{address}</h2>
            <h2>評価:{rating}</h2>
        </div>
    )
  }
```


#今後の事とか
chatGPTとcopilotすげーってなりました
じつはこれまだ完成してなくて
- dockerに移行したい
- reactnativeとかでモバイルアプリとして動かしたい
- UI完成してない
- 店のurlとか貼ってない(まだ名前、住所、評価しか表示してない)
とかいろいろあります。
qiitaで初めて記事書いたんですけどこんなんでいいんですかね
postgresqlに変えてから困ったこと

# はじめに

昨今RDBMSをOSS化する動きは多いのではないだろうか?

当然ながら金銭面での苦労がなくなった分、OSSDBを利用する上で苦労する点はいくつかあるのでご紹介したいと思います。

これから導入を検討しようと考えている方 の参考にでもなればと思います。

# 同じクエリなのに・・・

最初に戸惑ったのは実行するクエリは一緒なのに実行時間が大きく異なる点となる。 


異なるDBMSであるため、実行プランの組み立てや、内部キャッシュの仕組みは全然異なるという点に起因しているものと思われる。
実際、商用DBではすごく早く終了する処理がOSSDBで流すといつまでたっても終わらないということはざらにあるため、商用なりにこのあたりを 「いい感じ」 に処理するようになっているのかもしれない。 
OSSDBを扱う上ではこれまで気にしなかった、プランナ/オプティマイザの理解や、実行プラン の見方など学習する必要がある。

# Vacuum? なにそれ?

これもpostgreSQL特有の考え方であろう。
細かくは公式文書を見ていただきたいが、UpdateやDelete時にゴミが残るためそれを凍結・回収する仕組みが必要となる。 
最近ではあまり気にせずともauto vacuumがデフォルトでonになっているが、vacuumの頻発は性能劣化につながるためパラメータチューニングが必要となる。

もちろんただいじればいいというものではなく、それぞれの パラメータがどのような意味で変更するとどこに影響するのか?というのを理解した上でデータ量や更新頻度に応じて適切な値を設定する必要がある。 
一方、データ量・更新量が大きくなく、パフォーマンスについてもある程度は許容されるのであればそこまで気にする必要はないと思う。 
また、拡張機能によりこういったわずらわしさから解放するような動きもあるので、情報収集が必要である。

# 使ったことある人ーー! シーン

同社内に先駆者がいればいいのだが、おそらくこの記事を興味深く見ている人こそその企業様の先駆者なのだろう。
困ることといえば大体のことを自分で公式文書をなめるように見渡し切り開く必要があることである。 
そういった場合ユーザ会への参加していくなどコミュニティの一員となってみると相談相手がいていいかもしれない。

# 運用系の機能が

高級な商用DBでは月に一度インデックス再作成して〜レプリケーションして~とか保守・運用の機能がついていたりする。
もちろんのことながらそう言ったものは存在しない (拡張の中にあるのかもしれないが知識にはない) レプリケーションは構成すれば自動で走るため少し考え方が異なるが、REINDEXなど定期実行する場合はスケジューラと組み合わせて実行させる必要がある。

# あれ? データベース跨ぎできないの?

DBMSの種類にもよりますが、クエリにデータベース指定を行うことができません。

データベース跨ぎでクエリを組むのに慣れてしまっている方は非常に厄介です。
ただしpostgres_fdwというDB跨ぎを可能とする拡張機能がありますので、それを利用することで可能となります。 が、ひと手間必要となるため使い方の学習が必要です。

# 終わりに

今では大分慣れましたが、切り替わった当初は多少苦労しました。

色々調べていくうちにもっと詳しくなりたいと思うようになり、ある程度の知識は得られたと思います。 
先日postgreSQL Conferenceにも出席しましたが、より深い使い込みをしている事例が多数ありまだまだ勉強することがたくさんあるなと思った次第です。
[チート対策] ガチャサイトの抽選ロジックを実装しようとした時に気をつけたこと


これは[no plan inc.の Advent Calendar 2023](https://qiita.com/advent-calendar/2023/noplan_inc)の9日目の記事です。


どもー、皆さん。no plan inc.の[おかむー](https://twitter.com/okamu_ro)です。
最近ガチャ系の実装を設計から実装までやったのですが、その際に
ガチャのロジックについて結構ディスカッションしたことがあるので、
このガチャロジックについて知見を共有できたらと思っています。

# 前提条件
- Firebase firestoreとCloud Functions for Firebase のサーバーレス構成
- SSR, SR, R, N のガチャが用意されている
- クレカやPayPayなどのオンライン決済で購入を想定
    - もし決済がキャンセル、失敗した場合も考慮したい
- SSR、SRの残り枚数を動的に表示したい(SSR, SRにはさらにその中に種類という概念があります)
- 基本的には重複を防ぐためトランザクションを張ります

# この記事でわかること
- ガチャサイトを実装しようとした時に気をつけたほうがよさそうなことがわかります
- 同時に引かれた時
- リアルタイムが故のなやみ


がわかります

# 結論
- ①抽選方式は何がいいか
    - あらかじめ在庫を生成し、抽選時に在庫を減らしてそこからランダムで当選する


# ①抽選方式は何がいいか
ひとえに言ってもガチャの抽選方法はいくつかあります

## 抽選方式A案: 完全確率の場合 ○
これは SSR:1% SR:29% R:70%などのような抽選確率を簡単に定めることができます

### 完全確率のメリット
- 排出のパーセントがわかりやすい
- 比較的実装が簡単なのでコストは安い
- 決済が失敗キャンされるされても問題ない

### デメリット
- 限定枚数が存在するとダルい
    - 例えば500枚限定で完全確率ガチャを導入してしまうと起こりうるリスクとしては
        - SSRが絶対に1枚出ないかもしれないし、SSRが500枚出てしまうかもしれない
=> これは運営にとっていろいろリスクがあります
- 数量が限られているモノとの交換だったりすると多く出た場合は返金対応などになってしまいます
- 残り枚数が表示できない(bizでこの仕様を切り捨てれるなら最適)

## 抽選方式B案: 完全確率+限定数制御 ▲
A案にSSR,SRに関しては設定上限が過ぎたら抽選しない(設定上限を超えたら抽選しない)

### メリット
- 排出のパーセントがわかりやすい
- ちょっと実装大変かもしれない

### デメリット
- まだ限定枚数が存在するとダルい
    - 例えば500枚限定で完全確率ガチャ+限定数制御を導入してしまうと起こりうるリスクとしては
        - 500枚引かれたとしても、SSRが絶対に1枚出ないかもしれない
=> これはまだ運営にとって、天井したのに！！何で出ないんだ！！

- 決済が失敗キャンセルされると、また制限数を戻す、もしくは仮予約状態などを考慮しないといけない
=> SSRの残り枚数が0だったり、1だったり最後決済しなかった人がいた場合数字が上下する
=> SSR残り枚数が出ると、仮予約で在庫数をディクリメンとすると当選したかわかってしまいSRなどで注文キャンセルされることが想定される

などのリスクがあります
さあややこしくなってきました


## 抽選方式C案: 順序配分方式 ×
別口の案ですが参考として、
抽選を行わずに当選の順番を定義しておいて、先頭から当選を割り当てていく

### メリット
- あんまりフェアじゃない

### デメリット
- 当たりを最後とか任意のタイミングで仕込まれてしまう可能性がある
    - サイトの信用が落ちる可能性がある


## 抽選方式D案: あらかじめ在庫を生成し、抽選時に在庫を減らしてそこからランダムで当選する ○
いわゆる一番くじの要領で、最初から箱の中にものが入っています
決済前に、あらかじめ当選数を予約して、決済が完了したcallbackを元にその予約済み当選を確定します
10分程度決済がなかったら決済のタイムアウトとし在庫に戻します

### 注意
- もし、予約済みをフロントの数字反映させてしまうと、決済画面まで飛んで、SSRの在庫が減ったか確認して決済を取り止めれば確実にSSRを当てることができます

- 今回firestoreを使っています。DBにだれでもgetの権限があると予約中かどうかもみられてしまいます、なのでこの辺の抽選のDBはget listで見られないようにfirebase ruleをしっかり設定しましょう

### メリット
- 実装が大変
- 残り枚数も表示できる
    - 残り枚数は、予約済み枚数は表に表示せず、決済済みの数字を表示することとしました

### デメリット
- 実装工数がかかる


# まとめ
- 「抽選方式D案: あらかじめ在庫を生成し、抽選時に在庫を減らしてそこからランダムで当選する」を今回は採用しました

# まさかり受け付けます
- この手のロジック周りは炎上することが予想されます。もし誤字脱字、不可解なことがあれば、優しくご指摘いただけますと幸いですww(おかむーはガラスのハートです！！)

# no plan inc.で扱っているTechに関する様々なジャンルをアウトプットします!!


[![top.gif](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/62822/41177709-516f-0174-7cc4-c3052a311ac8.gif)](https://noplan-inc.com)



# no plan株式会社について

- no plan株式会社は **「テクノロジーの力でZEROから未来を創造する、精鋭クリエイター集団」** です。
- ブロックチェーン/AI技術をはじめとした、Webサイト開発、ネイティブアプリ開発、チーム育成、などWebサービス全般の開発から運用や教育、支援なども行っています。よくわからない、ふわふわしたノープラン状態でも大丈夫！ご一緒にプランを立てていきましょう！
- [no plan株式会社について](https://noplan-inc.com)
- [no plan株式会社 | web3実績](https://noplan-inc.com/web3)
- [no plan株式会社 | ブログ一覧](https://noplan-inc.com/blog)
エンジニアの採用も積極的に行なっていますので、興味がある方は是非ご連絡ください！
- [CTOのDMはこちら](https://twitter.com/_serinuntius)
VSCodeを使ってリモートサーバー上で開発しての所感

# はじめに

muxtに取り組むべく、サーバーサイドのデバッグ手段を探していたところ VSCodeで・・・という記事が多数でありました。
SSHでリモートアクセスして開発を行うことが多く、これまではeclipseを使っていましたが、VSCodeでも同等のことが可能であるため切り替えてみました。

# コーディングがすっごく楽

プラグインの使い方になってしまいますが、適切なプラグインを導入することでコーディングが恐ろしく楽です。
タグの予測にとどまらず、コンポーネントのプロパティなどについても設定可能な項目を勝手に出してくれます。 
(良し悪しは別として) 例えばプロパティの変数にプレフィックスをつけてあげると。
入力の時点で設定可能なプロパティを挙げてくれますのでコピべよりもむしろ早いです。

# リモート開発は少しストレス

Remote Development をここでは利用しているのですがとにかくよく切れます。
少し階席しようものなら「切断されました。」と出ますし、リモート側にパスワードが必要であればパスワードを入力する頻度はかなり多いです。
セキュリティ的な面としてはよいのでしょうが、少しストレスを感じました。

# ターミナルは良好

eclipseにもターミナルはありましたが、あまり動きがよくありませんでした。

VSCode上での動作は良好であるため、いちいちTeraTermなど開いておく必要もありませんし、ターミナルの動きとしては満足できました。 一方、gitなどで認証を行う際は最初戸惑いました。

通常こういったターミナルでgit pullなど行った場合には

```
$ git pull

Username for "http://xxxxx:

```
このような形でターミナル上での対話になろうかと思いますが、VSCode上で行う場合はVSCodeのダイアログを通して認証を行います。 その為、「認証入力がまだこないなぁ〜」なんて思っていたわけです。

で、よくよく見ると画面上部で認証求められているじゃないか!と無駄な時間を過ごしてしまいました。

# 終わりに

総合的にGoodです。

Web系の開発を行う場合にはもってこいではないでしょうか?

一方JavaWeb系はデバッグに準備が必要となりますので、eclipseを使った方が無難なと思います。 今のところサーバーサイドJavascriptが非常に開発しやすいのでJavaを触ることはなくなるかも・・・と思っていますのでVSCode中心での開発になりそうです。
分岐カバレッジ（C1/C2）とgcovのカバレッジの違い

プログラムを開発していると、テストが十分かどうかを確認するためにコードカバレッジに関する品質目標が設定される場合があります。その際、日本の会社だと多くの場合に基準としてC0/C1/C2などの用語が使われていて、C1/C2がいわゆる分岐カバレッジになるのですが、これらの定義と gcov の考え方が少し異なるので違いについてシェアしようと思います。

## C1カバレッジ・C2カバレッジの定義について

この用語は広く使われている割に定義を定めた標準規格がなさそうです[^1]。そのためか、経験上様々な定義が行われているようなのですが、今回は一番簡単な以下の定義を採用します。
[^1]:C1/C2カバレッジの定義に関する標準についてご存じの方いらっしゃいましたらコメントお願いします。

これらの定義では、ソースコードの分岐を基準に考えられているのが特徴です。

説明には以下の疑似コードを利用します（C言語風）。
```C
statement1;
if (condition1 || condition2) {
  statement2;
}
if (condition3) {
  statement3;
}
```

### C1カバレッジ

**この記事における** C1カバレッジは以下の定義です：
1. サンプルコードにおける if 文のあとの括弧の中身を _条件文_ と呼ぶことにします。各 _条件文_ はTRUE or FALSEの結果を持ち、その結果が命令文（statement1 〜 3）の実行順序の分岐を起こします。
1. C1カバレッジではすべての _条件文_ において、分岐の双方をカバーしたかを計測します。
1. この際、_条件文_ 間の組み合わせなどは考慮しません。

サンプルコードの場合、以下の分岐をカバーすれば良いことになります：
|枝番|条件文 = 値|
|---|--------|
|1|`(condition1 \|\| condition2) = TRUE`|
|2|`(condition1 \|\| condition2) = FALSE`|
|3|`condition3 = TRUE`|
|4|`condition3 = FALSE`|

枝番1〜2と、枝番3〜４の相互の関係は考慮しなくても良いため、上記のすべての枝をカバーできる最小のテストケースの数は2です。


### C2カバレッジ

**この記事における** C2カバレッジは以下の定義です：
1. サンプルコードにおける condition1 〜 condition3 はC言語で言う単文の式と考えてください。この式は TRUE or FALSE の値を持ちます。これをここでは _条件式_ と呼びます。
1. C2カバレッジでは、すべての _条件式_ に対して、双方の分岐をカバーしたかを計測します。

サンプルコードの場合、以下の分岐をカバーすれば良いことになります：
|枝番|条件式 = 値|
|---|--------|
|1|`condition1 = TRUE`|
|2|`condition1 = FALSE`|
|3|`condition2 = TRUE`|
|4|`condition2 = FALSE`|
|5|`condition3 = TRUE`|
|6|`condition3 = FALSE`|

こちらの場合も、最小のテストケース数は2になります。
この際、_条件文_ の単位で値が何になっているかは考慮しなくて良いので、例えば以下の組み合わせはC2カバレッジ100%になりますが、C1/C0カバレッジは100%にならないので注意が必要です。
- `condition1 = TRUE, condition2 = FALSE, condition3 = TRUE`
- `condition1 = FALSE, condition2 = TRUE, condition3 = TRUE`

## gcov の Branch Coverage の考え方

一方、gcov における Branch Coverage の考え方は根本的に異なっていて、そもそもソースコードの分岐を基準にしていません。

gcov が Branch Coverage と呼んでいるのは、_制御フローグラフ（Control Flow Graph:CFG）_ における分岐の網羅です。
_CFG_ は、大まかに言うとコンパイルの結果生成される機械語に近いレベルでの制御のフローを表したものです。

このページで使っている疑似コードの場合、_CFG_ は下以のようなイメージになります。

```mermaid
flowchart TB
A((start))
B(((end)))
stat1[statement1]
stat2[statement2]
stat3[statement3]
cond1{{condition1}}
cond2{{condition2}}
cond3{{condition3}}
A --> stat1
stat1 --> cond1
cond1 -->|A:true| stat2
cond1 -->|B:false| cond2
cond2 -->|C:true| stat2
stat2 --> cond3
cond2 -->|D:false| cond3
cond3 -->|E:true| stat3
cond3 -->|F:false| B
stat3 --> B
```

gcov ではこの _CFG_ の分岐の枝である A〜F のすべてを通ったかを Branch Coverage として計測します。

図からもわかりますが、上記のサンプルコードの場合に gcov の Branch Coverage を100%にするための最小の経路数は3で、前述のC1/C2よりも多くなっています。

このため、一般的に言って gcov の Branch Coverage は前述の C1, C2 カバレッジよりも厳しい基準になり、gcov の Branch Coverage が 100% の場合にはC1とC2のカバレッジは100%になりますが、C1カバレッジ100%やC2カバレッジ100%は gcov の Branch Coverage 100% にはならない場合が大半です。

以上から、プロジェクトの品質要件で C1 カバレッジ100%が品質要件に上がっている場合、<ins>テストの工数が増大することを厭わないのであれば</ins> gcov の Branch Coverage 100%をもって証拠とすることは可能です。

一般にC1/C2のカバレッジ計測ができるツールは高額なものが多いため、すでに導入されたツールがない場合は工数との比較で gcov を利用するかどうかを決めると良いでしょう。

## 参考文献

https://gcovr.com/en/stable/faq.html#why-does-c-code-have-so-many-uncovered-branches
テスト仕様書.xlsx ツッコミまとめ


# 注意書き

[mohikanz Advent Calendar 2023](https://adventar.org/calendars/9415) の 12月3日担当記事です｡
リモワについて書きたかったんですけど､スプラも新シーズン始まって時間が足りないため､1年の総括として転職先で経験したテスト仕様書へ突っ込んでいきます｡

明日は､ゆいなさんの記事です｡

# 前提

実務であったツッコミどころの多いテスト仕様書.xlsx へ突っ込んでいきます

テスト仕様書がエクセル?という部分には突っ込まないことを前提としています｡


## おかしい日付を入力する というテスト項目

- ｢おかしい｣という現象はコンテキストによって変化するためテスト項目として不適切である
  - 例えば､誕生日という文脈において､未来の日付は｢おかしい｣といえるため､テスト者によって適切なテストを行えないことが明白である

- 修正例
  - エラーと表示される見込みの具体的な日付をテスト値に設定する
  - 9999/12/31 システムの寿命として､まず存在し得ないため仕様側で考慮されているかどうかを通すためのテスト値
  - 2023/11/40 日付としておかしい文字列

## 絵文字不可 のインプット

絵文字 と指した場合､以下のテスト項目についてパスするかどうか､わからないため明確にエラーと予期される値を設定するべき

- 環境依存文字
  - ㍾㍽㍼㍻㋿ 他
- 4バイト文字
  - 髙﨑 など氏名で使われる可能性のある文字
- 絵文字
  - 🐯🐱🐶🐵 他
- 他､状況によって問題となる可能性のある文字
  - <>?;& 他

## 未満､以内､以降 などの混同

- 日付等で紛らわしいですが､こちらも明確なテスト値を記載することで問題なし

9 は 10 未満である ◯
10 は 10 未満である x

9 は 10 以内である ◯
10 は 10 以内である ◯

9 は 10 以降である x
10 は 10 以降である ◯

## 一つのシートに､テスト前提の違う似たようで違うテスト項目を並べない

- 例､管理者権限を持つユーザのテストと一般ユーザ権限を持つユーザのテストが同じシートに縦に並んでいる
  - かつ､テスト内容が微妙に違う場合など､テスト者の認知能力への負荷試験ですかね?
- テスト者が間違える可能性が高く正常にテストが実行されない可能性が高くなる
### 解決
- テスト項番を揃えてユーザごとにテストを行うことで明確に権限テストができていることを担保できます｡


## 1000パターンに近いテスト項目を一つのシートにまとめる

- テスト者に対する負担､および保守性の低下を招くので適切な粒度でテストを分割する
  - 例 更新機能
    - ユーザ権限､管理者権限
    - テスト条件､対象データ 自分､他人などでシートを分ける
- そもそもパターンが多ければいいという話ではないので､テスト対象と条件は適切に設定すること
- 分けておくことで､条件追加時に修正が容易になることが明らか
- かつ項番ごとに行うテストを整理することで機能がどういった権限で整理するべきかを明確にできます｡


## 操作後の確認対象となるテスト結果を一つのセルに詰める

- 保守出来ないこと､網羅性が明確にならない点から明らかに悪い
  - 想定例(bad)
    - ユーザ区分 編集､担当､作家
    - テスト結果(編集) a,b,c,d,e,f ができること
    - テスト結果(担当) c,d,f ができること
    - テスト結果(作家) b,d,f ができること

- 以下のように書くことで､追加や変更および把握が容易になります｡
    - 縦､横は状況次第で選んでください

|テスト対象|編集|担当|作家|
|-|-|-|-|
|a|◯|x|x|
|b|◯|x|◯|
|c|◯|◯|x|
|d|◯|◯|◯|
|e|◯|x|x|
|f|◯|◯|◯|

凡例:◯ 処理が正常に完了すること
凡例:x 処理が完了せず､エラーページへ遷移すること

## テスト対象がリリース単位で1ファイルになっている

- テスト仕様書は最低限機能ごとに整理すること
    - 今後､機能が追加される場合､同一のテスト仕様書を使い回せるはずです｡
- アジャイルでもウォーターフォールでも考え方は同様


## たった1枚のシートを共有するために､1ファイルになっている｡

- テストに入った時点で仕様確定しといて･･･？(理想論)
- 神テスト仕様書を作る前に､テスト仕様書に書くべきこと書くべきでないことを整理すること
    - 参照する必要のあるシートがあっても､別ファイルなどシートの値を参照するようなテスト仕様書.xlsx は bad です｡


## 仕様を把握している人間にしかできないテスト

- 前提となるデータについて解説をしていない(条件を確認できない)､仕様を開示しないなど
  - 限度はありますが､最低限のことは書く必要があります｡
  - 例 一般ユーザが作成したデータ(4件分)など


## エクセルを使っているのにテスト達成率が手動集計
  - エクセル使う意味ー

### まとめ

- テスト仕様書はやはりテストコードを書くことに気をつけることや､リーダブルコードで学んだ内容を転用できると思います｡
    - 一つのファイルに全仕様を詰めたロジックを書くことはまず無いと思います｡
    - テスト実行する環境で変わるビジネスロジックへテストコードを書くこともないでしょう
- エンジニアとしての転職は初めてなので､今後もネタには尽きないでしょう｡良いお年を
エンジニア教育について

# はじめに

これまでも
https://qiita.com/jun2/items/496b492d3bbc95ceaf4c
などでエンジニア教育について触れてきましたが、数年たち私も少し大人になったところで改めてどのように教育すべきかを考えてみましたのでアウトプットしたいと思います。

# ロードマップの必要性

こちらの記事
https://qiita.com/jun2/items/74560ce0c5cb7e9ef1fb
でも記載しましたが、やはりロードマップを作成しどのような役割として活躍してほしいか?
については重要であろうと考えます。
 育った後どんな感じになったか?で役割を決めることはできるでしょうが、それは大所帯であれば現実的ですが、中小企業の人数では使い物にならなかった・・・ではその後どうしようもありません。 
おそらくはできる人が大きな荷物を抱えていくことになろうかと思いますので、そうならないためにも例えば人の適性を見て、この人を支えられる人になってほしい。 
リードする立場として育ってほしい、と定めていくことは大事であろうと思います。

これについては上記記事で思うことをもう少し深く記載してますので、こちらではここまでにしたいと思います。

# せっかく育っても・・・

昨今良くも悪くも働き方についての多様性が広がり、若年層~非管理職の中間層についてはフットワークが軽くなってきたと思います。(簡単に転職を考えられる) 技術者の需要も売り手市場が続いているため、ずば抜けて技術力が伴っていなくとも初期教育が不要である場合は簡単に転職先は見つかるでしょう。

そうなってくると人の入れ替わりも激しく、教え切れていない・・・せっかく教えたのに・・・と教育に対するモチベーションもどんどん下がっていきます。

私たちにできることは、教育を通して相手との関係性を築くことでしょうか。

離職の問題は直接のエンジニア教育ではありませんが、企業として取り組むべきものとして検討する必要があると思います。

信頼を得る。親しみを持ってもらう。など教えてによってやり方は様々だと思います。

# プロ意識

正直、動くプログラムを作るのは学生もできますし、なんなら最近ではAIが作ってくれます。 ただただプログラムを作ればよいのであれば、生業としている我々でなくともいいわけです。

ですが、実際はコスト・納期・人同士の関係・品質など作る以外にも色々と気にすることは沢山あります。

次に記載する弊害にも関わってくるのですが、どうしても最初は作ることに没頭してしまいます。そして作って満足してしまうのです。 やはり職業とするならば、そもそもこれは作るべきなのか?作り終えたときにこれは最適なのか?というのは考えなければいけません。

・・・というのを教えないといけませんね。

# ある程度育つと発生する弊害

よくあることとして、ここがこうだったので直しておきました!!こういったことがあるわけです。

これが開発中であれば全然問題ありません。(できればテスト前・中が望ましいですが)

が、既に稼働しある程度の安定を見せているところであれば、ちょっと待った!です。 
不良個所はどういったユースケースで発生するのか?そのユースケースはそもそもありうるのか?あり得るとしてどのくらい発生しうるのか?発生したとして相手への影響はあるのか?その影響に対して保守・運用でリカバリするコストと修正するコストはどの程度など稼働のものに手を加えるにはそれなりに分析・理由が必要です。
 正しいことをしているわけですから何の問題もなさそうではありますが、やはりコスト面・デグレードのリスクも含まれるので何でもかんでも正しいことをすれば良いではないということだと「私は」思います。

いずれにしても何かするなら判断する権限を持っていないならちゃんと事前に報告・相談してねってことなんですよね。

# 発信力

多種SNSやそれこそQiitaのようなサービスが昨今では多く、発信の場が多くなってきました。

これにより承認されるという喜びはこれまでよりも感じやすい世になったと思います。

一方でこれが好きな人もいればそうでない人もいます。

華々しいインフルエンサーの陰には自己表現が苦手・したくない人が多数います。 人の属性にも依存しますが、こういった属性の人は成果をアピールすることも苦手です。

何か成し遂げたときもっとアピールしてほしいものなのですが、発信がなく成果を認めてあげられないということが多いと思います。 
今もやっているところはあるでしょうが、朝会や月一のミーティングなど順番でヒトネタ!なんてことも最近では少なくなってきたのでしょうか? ハラスメント・コンプライアンスに抵触しない範囲で、こういった場に立たせるというのも一つのトレーニングであったのですが・・・

# 終わりに

前回の記事から数年たって教えていく角度も変わってきたと思います。

また 数年たつと別な角度で教育する立場にもなってくるでしょうから、その時はその立場としての視点でエンジニア教育について触れていきたいと思います。
Windows10を監視して、動いているプログラムがあったらkillしたい

RPAでWindows10パソコンを自動操作しますが、その自動操作ができる条件は、パソコン側で何も起動されていない状態であることです。つまり電源を入れてログインした直後の状態であることです。

定期的に電源再起動をタスクスケジューラーで設定して、かつログインパスワードも無効にしてしまうのがアイデアの1つなのですが、RPAの稼働スケジュールを考えると、これをやらせるには30分おきに再起動をさせることになり、あまり現実的ではありません。

定期的にパソコンのタスク等を監視して、ExcelやChromeやファイルエクスプローラなどが動いていたらtaskkillをする、といった仕掛けは作れないものでしょうか。
動いている可能性のあるアプリをすべてtaskkillしないと意味がないので、これは万能ではないことはわかっていますが、他に考え付く方法が無いので。
【Android】AndroidStudioでCrashlyticsの詳細を参照する

# はじめに
Crashlyticsはアプリを作っていたら欠かすことのできないサービスの一つですよね。
アプリのクラッシュ箇所や最近ではANRも拾えるようになり、より一層便利になっているように感じます。
以前はWebでFirebaseを開き、エラーログとコードを照らし合わせながら不具合解消に努めていましたが、バージョンElectric EelからはAndroidStudioから直接Crashlyticsを参照できるようになりました。
今回は上記に関して簡単に導入方法などまとめておこうと思います。

# 導入方法
参照方法は非常に簡単です。
LogCatなどが並んでいるタブの中にApp Quality Insightsというのがあると思いますので、こちらを表示します。

![スクリーンショット 2023-12-03 13.42.27.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/354522/a3395da6-8dda-6fdb-2ef0-5b767e8e7bd5.png)

上記タブを表示すると、未ログイン状態では以下が表示されているかと思いますので、loginからFirebaseへログインすることでクラッシュの詳細を参照可能です。

![スクリーンショット 2023-12-03 13.47.40.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/354522/7eb574ca-a947-94b3-a9ae-4c67b905a16c.png)

ログインすると、以下枠内にクラッシュの詳細が表示されます。

![スクリーンショット 2023-12-03 13.52.53.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/354522/a56225b0-2d13-0235-2477-9fecaedf931d.png)

上記枠内に表示されているクラッシュの詳細に関しては、エディター上にも表示されるようになります。
クラッシュの該当箇所には以下アイコンが表示されるようになるので、一目でクラッシュの関連箇所を把握することが可能です。

![スクリーンショット 2023-12-03 13.55.48.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/354522/3f526e64-4606-4997-8e1b-1b7e6d45cd76.png)

説明としては以上です、他にもクラッシュログのクローズやアカウントの追加など便利な機能があったりするので色々触ってみると良いと思います。

# さいごに
Firebaseのクラッシュ確認は手間に感じていたので、こういう形で手軽に参照できるようになるととてもありがたいですね。
AndroidStudioはバージョンが上がるごとにどんどん便利になっているという実感があるので、新機能は積極的に試していこうと思います。
プログラマの休憩ってなんだろう

# はじめに

以下休憩時間 = 昼食休憩など法律上必ず取らなければいけないものを除くという前提で記載します。 
また、表題の通りプログラマについてです。体を使われる方は休憩に対する重要性・価値観は全く別であるものと思います。

皆さんは休憩時間は何をしておられますでしょうか?

会社によって異なるでしょうが、プログラマ含めデスクワークの方は特に休憩時間というのは設定がない方が多いのではないでしょうか?
プログラマは基本納期・品質を守れば休憩は各々の判断にゆだねられるものだと思います。(休みすぎて時間外過多は困りますが)
こういった場合何をすればよい休憩になるのか?というのを考えてみました。

# ただ10分くらい休んでもあまり集中力が戻ってこない

個人的な意見がすごく入ってしまいますが、集中力がぷつっと切れた時は離席・休憩したくなります。

実際この時コーヒーでも飲みながら10分くらい新聞を読み、個人的なメールをチェックしてなどやっていたりするのですが、着席時さぁリフレッシュした! やるぞ!という気持ちになかなかなりません。 
つまり仕事をする上での適切な休憩になっていないのものと思われます。

# 適度な会議は実はリフレッシュしたりする

これも完全に個人的になのですが、1日に1回くらい何かしらの会議があり、その日やらなければいけないことに対して時間に追われるような日にはものすごく一日中集中できている気がします。 
会議は通常30~2時間とられるようなものもありますが、これが案外リフレッシュになっているのかもしれません。

なので自分都合ではなんともならないのですが、一日に会議を詰め込まれるよりはある程度分散して開催されていると仕事への集中力が増すのになと思います。

一日のスケジュールを確認し、1日中席での作業が見えたときは結構げんなりします。
これは人によると思いますし、繰り返しになりますが個人的な意見です。

# 相当なゆとりがあると逆に疲れる

勤め先に依存すると思いますが、極たまに納期に追われない期間が生まれた時って、最初はラッキーと思いますが徐々に定刻までの時間が苦痛に思えます。
何もしないわけではなく、これを機にこれをやってみよう! ということももちろん進めるのですが、プログラマは期日に追われないとピリッとしない気質なのかもしれません。

逆にめちゃくちゃ忙しく、休む暇もないくらいに働くと実はあまり疲れません。

もちろん長時間の勤務によるものは別なのですが、集中して取り組んでいる状態ではあまり疲れないことが多いです。

# 総合的に何をすれば疲れないのか? 休憩になるのか?

上記、ある程度共通しているのは一つのことをずーっと続けていると疲れてしまうということです。
疲れたな・・集中力が途切れたな・・というときには気分転換に他の仕事をやってみると良いと思います。

時にはそちらに没頭しすぎて本来の仕事に戻れないときもありますが、心の中で戻りたくないという気持ちがあるのだと思います。
そういう時ってあまり高い成果は期待できないのではないかなとも思います。

もちろん納期に対して遅滞の発生が見込まれる場合は別です。
少しゆとりがあるときにはこういった休憩の仕方もいいのではないでしょうか?
[CDI] 図解：よく使うCDI変換部品 - まとめ 10つの解説

# はじめに

[インフォマティカ](https://www.informatica.com/jp/)が提供する、 [CDI](https://www.informatica.com/jp/products/cloud-integration/cloud-data-integration.html)(Cloud Data Integration)では、トランスフォーメーション(Tx)と呼ばれる変換部品を使って、ノーコードでデータの変換・連携を行うことができます。

例えば、下記のような変換部品を利用することできます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/110338/9dc98646-1240-f1fb-aa2e-1cf596ad602c.png)


以下、10つのよく使われるCDI用変換部品(上の図でハイライトされているもの)を、一つ一つの記事として図解していますので、利用ユースケースの参考にして下さい。


# 各解説記事の一覧

https://qiita.com/masatoshimada-max/items/9c559670d7ea8224561c

https://qiita.com/masatoshimada-max/items/78d51a27b01a97e86960

https://qiita.com/masatoshimada-max/items/ace3e189e8fdf5d5e7cd

https://qiita.com/masatoshimada-max/items/e97fae4d436d2c728315

https://qiita.com/masatoshimada-max/items/e0f3a2af4baa068fb77a

https://qiita.com/masatoshimada-max/items/f4cef89a6aab35a46ad1

https://qiita.com/masatoshimada-max/items/abcb0a830d80515913c4

https://qiita.com/masatoshimada-max/items/146fe15c8bde0a2e54f0

https://qiita.com/masatoshimada-max/items/bfa96d169b590720d5ac

https://qiita.com/masatoshimada-max/items/00ad033faef093730a76


# 参考文献

[トランスフォーメーション マニュアル](
https://docs.informatica.com/ja_jp/integration-cloud/data-integration/current-version/_transformations_cloud-data-integration_current-version_ditamap/GUID-1F3375E8-0571-40E7-888F-C7DFD4F331C0.html)
JSDocについて理解する

# 1.背景
最近業務でjsdocを記述するようになりました。
改めてメリット、用法等について理解したいと思った為です。

# 2.JSDocとは
https://jsdoc.app/
- JavaScript 用の API ドキュメントジェネレータで、Javadoc や phpDocumentor に似ています。
- ソースコードに直接、コードそのものと一緒にドキュメンテーションのコメントを追加します。
- JSDoc ツールはソースコードをスキャンし、HTML ドキュメントウェブサイトを生成します。

# 3.JSDocの書き方
一般的に、ドキュメント化されるコードの直前に書かれます。
各コメントは /** で始まらなければなりません。
```js
/** This is a description of the foo function. */
function foo() {
}
```
## 4.JSDocタグ
「JSDocタグ」を使えば、より詳細な情報を与えることができます。

以下が例です。

```js
/**
* @description JSDocという文字列を出力します。
* @function 
*/
function printOut() {
    console.log('JSDoc');
}
```
### ```@description```タグ
文書化する対象の一般的な説明を提供することができます。
JSDocコメントの一番最初に記述する場合、```@description```タグを省略することができます。

### ```@function```タグ
オブジェクトを関数としてマークします。
[tags-function](https://jsdoc.app/tags-function)

### TypeScriptではJSDocコメントに型情報を記述する必要はないです。
型注釈（アノテーション）がありますので。
```js:js
/**
 * Helloを付与する関数です。
 * @param {string} message メッセージ
 * @return {string} 加工された文字列
 */
function sayHello(message) {
  return `Hello ${message}`;
}
```

```ts:ts
/**
 * Helloを付与する関数です。
 * @param message メッセージ
 * @return 加工された文字列
 */
function sayHello(message: string): string {
  return `Hello ${message}`;
}
```


# 5.JSDocを書くメリット
## コードヒント/コード補完の表示
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/405182/c7775ba8-3465-0081-f1dd-020d58bf8e17.png)
呼び出し元でカーソルを当てるとツールチップでコードヒントが表示されます。
これによりその関数、クラス等に遷移する必要もなく概要を掴むことができます。

## APIリファレンスの生成
[TypeDoc](https://www.npmjs.com/package/typedoc)等のツールを使うことでコードのリファレンスドキュメントを作成できます。

# 6.TypeDocとは
JSDocで書かれたTypeScriptプロジェクトのためのドキュメント生成ツールです。

## インストール
```terminal
npm install typedoc --save-dev
```
補足）jsdocもnpmにあります。

https://www.npmjs.com/package/jsdoc

## 使い方
```
typedoc src/index.ts
```
TypeDocは自動的にtsconfig.jsonファイルを見つけようとするので、ライブラリのエントリポイントを指定するだけでよいです。

# 参考
- [jsdoc](https://jsdoc.app/)
- [JavaScriptでJSDocコメントを書くメリットとは](https://ics.media/entry/6789/)
- [JSDocコメントの有効活用。JavaScriptやTypeScriptのドキュメントを生成する方法](https://ics.media/entry/6819/)