OmniAICreator/Qiita-1.07M huggingface dataset:
jsp・htmlでよく使うタグ一覧【備忘録】

# 目次
 *[はじめに](#はじめに)
 *[コメントアウト](#コメントアウト)
 *[\<input>の型で使用できるタグ](#<input>の型で使用できるタグ)
 *[最後に](#最後に)
 *[参考サイト](#参考サイト)

 ## はじめに
 現在、htmlやjspを使った業務をしているため備忘録として基本的なタグをざっとまとめました。

 ## コメントアウト
 | タグ | 説明 |
 |:----:|:----:|
 | \<!-- コメント文 --> | htmlのコメントアウト |
 | <%-- コメント文 --%> | jspファイルのコメントアウト |

 ## \<input>の型で使用できるタグ
| 型 | 説明 |
|:----:|:----:|
| checkbox | チェックボックスで、選択または未選択のうちひとつの値をとることができます。|
| date | 日付（時刻を除いた年、月、日）を入力するためのコントロールです。対応しているブラウザーでは、アクティブになったときに日付ピッカーまたは年月日の数値のホイールが開きます。 |
| email | 電子メールアドレスを編集するための欄です。text 入力欄のように見えますが、対応しているブラウザーや動的なキーボードのある端末では、入力値を検証したり、関連するキーボードを表示したりします。 |
| file | ユーザーがファイルを選択するコントロールです。accept 属性を使用して、コントロールが選択することができるファイル形式を定義することができます。 |
| number | 数値を入力するためのコントロールです。スピナーを表示し、既定の検証を追加します。動的キーボードを持つ一部の端末では、テンキーを表示します。 |
| password | 入力値を隠す単一行テキストフィールド。サイトが安全ではない場合はユーザーに警告します。 |
| radio | ラジオボタンで、同じ name の値を持つ複数の選択肢から一つの値を選択することができます。 |
| submit | フォームを送信するボタンです。 |
| text | 既定値です。単一行のテキスト入力欄です。改行は自動的に入力値から取り除かれます。 |

## 最後に
まだまだタグは調べればありますが、ひとまず使用頻度が高そうなものをまとめました。
少しでも参考になれば幸いです。
最後まで閲覧いただきありがとうございました。

## 参考サイト
https://zez.ninja-web.net/java/javajsptag.html
https://developer.mozilla.org/ja/docs/Web/HTML/Element/input
M5Stack CoreMP135にさわる（その３：LCD表示するまで）

# LCD表示するまでの紆余曲折
大したことではないかもしれないが、M5Stack CoreMP135のLCDに何かしらを表示するのに多少時間がかかったので、その顛末の記録。なお、[その２](https://qiita.com/infinite1oop/items/97b7f276111e4d62ebb4)で作成した、debianのイメージを利用。

## 対象としたサイト
基本的に、「[Display terminal (tty) on CoreMP135 buildin display](https://community.m5stack.com/topic/6678/display-terminal-tty-on-coremp135-buildin-display/6)」の内容を実施するのみ。

## その前に、、ssh設定
rootによるリモートアクセスを行うため、下記設定実施。
```shell:/etc/ssh/sshd_config
PermitRootLogin yes
```
```
# systemctl restart sshd.service
```

## つまづき
上記サイトにしたがって、「fbterm」というLCD表示のためのモジュールをインストールしようとしたところ、エラー発生。
```
# apt install fbterm

E: Package 'fbterm' has no installation candidate
```
これは、
```
# apt update
```
にて解消。ところが、再度実施すると、エラー発生。
```
# apt install fbterm

E: You don't have enough free space in /var/cache/apt/archives/.
```
ディスク容量を調べる。
```
# df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/root       975M  934M     0 100% /
devtmpfs        157M     0  157M   0% /dev
tmpfs           221M     0  221M   0% /dev/shm
tmpfs            89M  772K   88M   1% /run
tmpfs           5.0M     0  5.0M   0% /run/lock
tmpfs            45M     0   45M   0% /run/user/0
```
SDカードサイズは32GBなのに、空きがない（100% Use）。調べると、
```
# ls /usr/local/m5stack/
bashrc	bin  init.sh  lib  logo.jpg  logo.wav  lt8618sxb_mcu_config  resize_mmc.sh
```
「resize_mmc.sh」を実施してみる。
```
# /usr/local/m5stack/resize_mmc.sh 
Disk /dev/mmcblk0: 60477440 sectors, 28.8 GiB

...

Last sector: 60477406 (at 28.8 GiB)
Partition size: 60469925 sectors (28.8 GiB)

...

Please restart! 
```
拡張されたようだ。リブート後、
```
# df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/root        29G  934M   27G   4% /
devtmpfs        157M     0  157M   0% /dev
tmpfs           221M     0  221M   0% /dev/shm
tmpfs            89M  772K   88M   1% /run
tmpfs           5.0M     0  5.0M   0% /run/lock
tmpfs            45M     0   45M   0% /run/user/0
```
空きがある（4% Use）。この後、
```
# apt install fbterm
```
は、正常にインストールされる。

## 検証
上記サイトの内容に従って確認。

### その１
イメージファイルをLCD表示。「fbv」というプログラムを使う。
```
# . /usr/local/m5stack/bashrc
# /usr/local/m5stack/bin/fbv ./test.jpeg
fbv - The Framebuffer Viewer
./test.jpeg
320 x 240
```
<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/634816/4ce796d1-1cb5-8344-4fe0-75608c41349b.png", width=60%>
イメージが表示される。

### その２
USBキーボードを接続し、ターミナルプログラム「fbterm」起動。
```
# export FRAMEBUFFER=/dev/fb1
# fbterm -s 20 < /dev/tty1 &
[1] 514
```
<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/634816/058808de-2863-cad4-fa66-88a6bbf56274.jpeg", width=60%>
シェルが使える。

## おまけ
起動時の「うるさい」音を削除。
```
# cd /usr/local/m5stack/
# cat init.sh
#!/bin/bash
/sbin/modprobe fb_ili9342c
. /usr/local/m5stack/bashrc
printf "q\r\n" | fbv /usr/local/m5stack/logo.jpg 2>&1 > /dev/null &
/usr/local/m5stack/lt8618sxb_mcu_config 2>&1 > /dev/null &
echo 1 4 1 7 > /proc/sys/kernel/printk
# tinyplay /usr/local/m5stack/logo.wav 2>&1 > /dev/null &
```
最終行をコメント化する（tinyplayでうるさい音を再生しているようだ）。

EOF
XServer ssh 設定方法 接続方法

## SSH設定方法

### 1. サーバーパネルにログイン

### 2. SSH設定を開く

SSH設定 -> ON[国内からのアクセスのみ許可]

または

SSH設定 -> ON と 国外アクセス制限 -> ON


### 3. 公開鍵の登録

パスフレーズを設定(推奨) -> 秘密鍵をダウンロード

### 4. 公開鍵登録の確認(してもしなくてもOK)

登録済み公開鍵を表示 をクリック

または

登録済み公開鍵 -> 表示する をクリック

## SSH接続方法

下記コマンドで接続

```bash
ssh -i ~/Download/xs〇〇〇〇〇〇.key -p 10022 xs〇〇〇〇〇〇@sv〇〇〇〇〇.xserver.jp
```

`-i ~/Download/xs〇〇〇〇〇〇.key` ... さきほど**公開鍵の登録**でダウンロードした秘密鍵のパスを指定

`-p 10022` ... 10022 ポートを指定(SSHでは通常のウェルノウンポート22ではなく、XServerでは10022)

`xs〇〇〇〇〇〇` ... Xserver のアカウント名(サーバーID)

`sv〇〇〇〇〇.xserver.jp` ... Xserver サーバーのドメイン(サーバーのホスト名)

## おまけ

- 上記の設定 + FTP情報を参照することでSFTP接続もできるようになる

↓ SSHエージェント (~/.ssh/config)の設定
```
Host my.sample.server
Hostname sv〇〇〇〇〇.xserver.jp
User xs〇〇〇〇〇〇
Port 10022
IdentityFile ~/.ssh/xs〇〇〇〇〇〇.key
```
初学者のUEFN前知識

# はじめに
２０２４年１２月１日目 シーズン２の記事です。
今回は、UEFNを中心に初学者が学習する資料として役に立てればと思い全開同様に記事にしてみました。ちなみに昨年は、技術者向けの学習方法の要点みたな記事を投稿しています。
https://qiita.com/SatoruNoda/items/4b11a46f1c6246384373

# 開発環境

最低推奨動作環境としてエピックゲームズランチャーより、FORTNITEストアページの下の[フォートナイトシステム要件](https://store.epicgames.com/ja/p/fortnite)を見ると、Windowsのみでスペックの低いPCでも動きそうな記載ですが低スぺの為、遊ぶことは出来ても開発には不向きです。その時の最高スペックが可能なら最高性能のPCで開発した方がストレスは溜まりません。それでもUnreal Engineは重いのですが...
![doc2.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/25895/50e2fc9f-082d-1385-b38e-d990a0a59b05.png)


# Epic Games Lanncherにインストールする
初めに最近知った動画で良いのがあったので共有いたします。[(EpiacGamesの歴史)](https://youtu.be/JDNvwXCE3b4?si=fFeNSacCXWG9fFPy)
普段PCにてFORTNITEをプレイしてうる方なら、Epiac Games Launcherと言うじゃまなのがインストールされていると思います。Unreal Engine(以下UE）でゲーム開発をする場合このじゃまなアイコンから一日が始まることになります。
ライブラリーより、UNREAL EDITOR FOR FORTNITE（以下UEFN）をインストールしていれば、以下のような感じになります。![doc1.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/25895/3bf9ba9a-118f-5b4e-193f-fb1237fa9ba5.png)

Epic Gamesは、2023年3月にUEFNをリリースしました。UEFNのイメージは、エディターでプロジェクトをコンパイルするとFORTNITEを作ることが出来ると言った感じになります。
![Screenshot 2024-11-17 at 6.21.36 PM.jpeg.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/25895/51a35fde-9e34-1678-30cf-5fe53545863f.png)

# 作成方法
学習方法などは、[標準ドキュメント](https://dev.epicgames.com/documentation/ja-jp/uefn/unreal-editor-for-fortnite-documentation)を参照していただくとして、UEFNはプロジェクトを作成する段階で個人で作成するのかチームで作成するのかを選びます。プロジェクトの削除もアーカイブするのでプロジェクト名など安易な物はなるべく避けた方が良いと思います。

簡易的な作成イメージとして[エピック社内ゲームジャム](https://youtu.be/qk4FVYUUgSg?si=APbl_M2R9QPs0mUt)で、UEFNのロケットレーサー用のゲームジャムの様子を動画化しています。ホワイトボードにアイデアを書きだして作成しているようで参考になります。

どんなゲームを作ったら面白そうなのか。こんなゲームなら世の中の役にも立ちそうだし作ってみる価値がありそうだ、などいろいろ考えながら作るのも勉強になると思います。

最終的に、私はこんなゲームが作りたいと言う情熱がすべてな気がします。
https://dev.epicgames.com/community/learning/courses/9DG/fortnite-uefn/2bVB/fortnite-uefn
![doc3.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/25895/351e02be-3f04-bf52-55dc-7233a407a0b4.png)
https://dev.epicgames.com/documentation/en-us/uefn/unreal-editor-for-fortnite-documentation


# 先人の意見
ゲーム開発現場で良くあるのが２個いちと言うお話で。具体的なゲームの流れやアニメで言うレイアウトなどは、概ね提示されなく、むしろそれを作るのがあなたの仕事ですまであります。この[方](https://www.youtube.com/@sora_sakurai_jp/videos)は、９千万円ほど掛けて私たちへ自分の知識共有をされている為、動画をご覧になってからゲーム作成に携わる事をお勧めします。


# 最後に
Epic Gamesは、[UEFNをメタバース](https://youtu.be/EqQ84b-v1DE?si=6fniOfCD7vgnvnhW)のきっかけにしてほしいと明言しています。作成したゲームは公開しその人気によって収益化もできるようになっています。ゲームだけでなく個人で作成したゲーム用のアセット販売もストアをFabへ移行しているので、ここから初めるのも悪くない選択だと思います。
無料でできる GraphAI 入門

## ここで得られること
APIキーを持っていないという方でも、GraphAIを触れます。
（Geminiの無料APIを利用しています。）

## 結論
#### 以下の実行手順でHello Worldを試せます。

1. `npm i -g  @receptron/graphai_cli`で、GraphAIをインストール
1. [GeminiのAPIキー](https://aistudio.google.com/)を発行する
1. 以下の`hello.yml`と`.env`ファイルを作成
1. `graphai hello.yml`を実行
    ```yaml:hello.yml
    version: 0.5
    nodes:
      llm:
        agent: geminiAgent
        inputs:
          prompt: Say Hello World.
      output:
        agent: copyAgent
        params:
          namedKey: text
        console:
          after: true
        inputs:
          text: :llm.text
    ```
    
    ```env:.env
    GOOGLE_GENAI_API_KEY="ここにAPIキーを貼り付け"
    ```

## 解説
:::note warn
更新予定
:::

## 応用するために
:::note warn
更新予定
:::
ハッカソン中にdockerでよく使用したコマンド

私はITスクールRareTECHで学習している実務未経験者のハル申します。
RareTECHのハッカソンは秋の陣が10月からスタートして11月末までアプリを完成させることを目標にしているRareTECHの名物コースになります。

初学者となります、間違いなどございましたら、ご指摘いただけると幸いです。


## この記事を書くに至った経緯

10月からRareTECHに入会をしてすぐにハッカソンがあることをしり、できなくても何かしら力がつくと思い、参加しました。

今回参加したのは、入門コースで、使用する言語などは指定がありました。
その中で私自身初めてDockerを使用しました。

RareTECHの学習内容を進めるステップが５００ある状況である程度進めると多くのことが理解でき、入門コースならある程度理解できる内容を網羅しているものではありますが、私は入会してまもないため、下記のコマンドすら知りませんでした。

# 起動で使用するコマンド

```
 docker compose up
```
サービス用のコンテナを構築、作成、起動、アタッチします。リンクされているサービスがまだ起動していない場合は、それらも起動します。

## 全てを消したい時の魔法のコマンド
```
docker compose down --rmi all --volumes --remove-orphans
```
```
docker compose down
```
docker-compose.yml ファイルで定義されたサービスを停止し、関連するリソースを削除するコマンドです。
docker compose down は基本的に停止中のコンテナを削除し、作成したネットワークやボリューム（--volumes オプションで指定した場合）も削除します。

オプション
```
--rmi all
```
--rmi オプションは「イメージを削除」するオプションです。
all を指定すると、docker-compose.yml で定義されたすべてのサービスに関連するイメージを削除します。
デフォルトでは、docker compose down は不要なイメージ（使われていないイメージ）のみ削除しますが、all を指定すると、使用中のイメージも含めて全て削除されます。
```
--volumes
```
このオプションは、Compose プロジェクトに関連付けられているボリュームを削除します。
ボリュームは、コンテナのデータを永続化するために使用されるため、このオプションを指定すると、サービスの停止後に関連するボリュームが削除されます。

```
--remove-orphans
```

Docker Compose で定義されたサービスの中で、現在のプロジェクトに関連しない不要なコンテナ（オーケストレーション外のコンテナ）を削除します。
例えば、docker-compose.yml の設定からサービスが削除された場合、そのサービスのコンテナが「孤立した（orphan）」状態になります。このオプションを使うことで、それらの孤立したコンテナも削除します。

## 未使用のデータを削除する
```
docker system prune -a
```
Docker が管理しているシステム全体の未使用リソースをクリーンアップします。具体的には、次のリソースが削除対象となります。
・停止中のコンテナ
・使用されていないネットワーク
・未使用のボリューム


オプション
-a

現在どのコンテナにも使用されていない全てのイメージ


こちらのコマンドを使用すると確認のY/Nが出てくるのでめんどくさいんです、ハッカソン終盤でさらに便利になるコマンドを教えてもらいました。

```
docker system prune -af
```
オプション
f

force オプション
ユーザー確認プロンプトをスキップします。


ハッカソンを通じて、多くのことが学習できましたので、学びを記事にしてまいりたいと思います。


初めての記事作成となります、誤字脱字、コマンドの意味が違うなどあれば、コメントで訂正など入れていただけますと幸いです。

 引用
 https://docs.docker.jp/compose/reference/up.html
社内勉強会に人を集めるための tips

ちゅらデータアドベントカレンダーの1日目です！

技術ネタは普段からちょいちょい書いているので、会社のアドベントカレンダーでは毎年だいたいポエムっぽいもの (？) を書いています。

だいぶ昔の話になってしまいますが、ちゅらデータ社内で「社内勉強会運営」という活動をしていたことがあります。名前の通りさまざまな社内勉強会を企画して運営していくという活動ですが、今回はここで得られた知見について書いていきます。

::: note warn
この記事では以下のような状況を想定して書いています。

- 社内でチャットツールやカレンダーツールを利用している IT 企業を想定
- 数名〜最大でも20名くらいの小規模な社内勉強会 (有志を対象としたイベント) を主催する想定
:::

## 先にまとめ
社内勉強会に人を集めるためのポイントは以下3つです。

1. 告知するときは「興味を持ってくれた人が秒で意思表示できる方法」を用意せよ
2. 興味を持ってくれた人の予定をおさえよ
3. 個別メンションでリマインドせよ

## 社内勉強会に人が集まらない
こういう経験はないでしょうか？

> あなたは或るトピックに興味のある人を集めて社内勉強会を開きたいと思い、社内のチャットツールに告知をします。
> 
> ```
> @channel
> 12月19日の16時にXXX勉強会をやります！ 初心者大歓迎！
> 興味ある人はぜひご参加ください！
> ```
> 
> 告知すると、社内からは「良さそう」「気になる」といった肯定的なリアクションがちらほらついたりします。
> 
> しかし当日になってみると期待していたほどには人が集まらず、イマイチ盛り上がりに欠ける会となってしまいました...。

もし本当に魅力のないイベントで誰も興味がなかったのであれば、仕方ありません。しかしよくあるのは **「えっ、あの勉強会って今日だったの？参加したかったんだけど打ち合わせの予定入れちゃった」** などと言われるやつです。実は興味を持ってくれている人がいるのに参加してもらえないというのは大変にもったいないです。

このような悲劇は、ちょっとした工夫で回避できます。

## ポイント3点

### 1. 意思表示させる
社内チャットツールに告知を書くとすると例えば以下のような内容でしょう。

```
@channel *「XXX 勉強会」を開催します！*

日時: 12月10日(金) 16:00 - 17:00
場所: オンライン (当日に会議 URL を共有します)
対象者: XXX に興味ある人 (未経験者歓迎)
やること: XXX のチュートリアルを流しつつ簡単に動くものを作っていきます
事前準備: 特になし

希望者はこのメッセージに ✋ リアクションをください！
```

重要なのは最後の行です。誰が興味を持ってくれたのかを主催者側で把握することは、次で紹介する「予定をおさえる」へ繋げるために必ず必要です。

また、この告知メッセージを送信したら直ぐに自分で ✋ リアクションをつけます。こうすることで、 **「興味を持った人は1クリックで意思表示できる」** という状況を作ります。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/16369/1a98cdd9-dfac-eba8-8fb1-efb672c29785.png)
(↑ 実際の様子)

当然ですが、意思表示するためのハードルを高くすればするほど意思表示してくれる人は減ります。例えば意思表示の方法が「このフォーム URL にアクセスして名前と所属を入力して送信してください」だと、その一手間が面倒で諦めてしまう人がいるかもしれません。告知を見て「あっ、これちょっと気になるな」と思ってくれた人が秒で意思表示できる方法を用意しましょう。

### 2. 予定をおさえる
人間はおろかなので、「来週の金曜日に社内勉強会がある」ということを来週の金曜日まで覚えていてくれる人はいません。人間は忘れる生き物だから「スケジュール帳にメモする」といった工夫をしてきたわけです。ましてやカレンダーツールで他人の予定を抑えられるのであればこれを使わない手はないです。

つまりやることは **意思表示してくれた人全員をカレンダー予定に招待します。** 予定に招待することで、その人がカレンダーを見るたびに「そういえば来週の金曜に社内勉強会があるのだったな」と思い出してもらうことができます。

チャットツールで告知する場合は1日待てば興味ある人はだいたいリアクションしてくれると思うので、告知メッセージを投下したら翌日の自分宛てにリマインダーを設定します。主催者がこの作業を忘れてしまったら元も子もないので...。そして翌日にカレンダー登録作業をします。20人とかいた場合はちょっと大変ですが、まぁそこは気合いです。がんばりましょう。

### 3. リマインドする
人間はおろかなので、予定を抑えてもなお忘れたりします。気が変わって「やっぱ面倒くせぇな」なって不参加になるならまだ仕方ないですが、素で「カレンダー見てなくて失念した」みたいな人がいたりします。社内勉強会に限らず、イベント直前に「明日ですよ！」「今日の16時ですよ！」などとリマインドすることは非常に重要です。

このとき重要なのは **グループメンションを使わない** ことです。Slack でいう `@channel` とか `@here` とかは使いません。有志の勉強会という対象者が限られる連絡を幅広いグループメンションでしてしまうと、受け取った側は自分に関係あるのかどうかを適切に判断できずにスルーします。 **「お前に連絡しているのだ」ということを明らかにする** ために、招待している人全員に対して個別メンションをつけてリマインドするのがいいです。

**[2024-12-02 追記]**
Twitter ですげー良いコメントがあったので紹介させてください...。

> 最終的には「あなたに参加して欲しいんですよ」が一番効く。なので個別リマインドは首がもげる程同意
> &mdash; しんや (@shinyaa31) [December 1, 2024](https://twitter.com/shinyaa31/status/1863100853944799367)

リマインドするときのスタンスというか気持ちは「あなたに参加して欲しいんですよ」です、本当にそう。
**[追記ここまで]**

## おわり
「細かい話ばかりしてんな」と思いましたか？ しかしこういう細かいことをちょっとやるだけで参加者が増えてくれるなら儲けもんです。

有志のイベント (= やらなくてもいいこと) のために行動してもらうのは大変なことです。特に初回の開催で参加者のモチベーションも低い状態だと、ほんのちょっとした要因で人は「参加しなくていいや」になります。この「ちょっとした要因」を排除していくことで機会損失を減らすことができます。

そして人間は「やり始めればやる気が出てくる」ものなので、イベントに来てもらってコンテンツをぶつけることができればあとはこちらのものです。そこからはコンテンツ勝負の話なので、この記事で語ることではありません。
データ型とサイズを出力するプログラム

学習用にデータ型とサイズを出力するプログラムを作ってみました。

```c: print_size_of_data_types.c
#include <stdio.h>
#include <stdlib.h>
#include <stdbool.h>

// main()に置いたハッシュテーブルのための構造体
typedef struct dataType
{
    char    *data_name;
    size_t  data_size;
    size_t  data_align;
} DT;

int print_size_of_data_types(DT *types)
{
    int ret;

    for (int i = 0; types[i].data_name != NULL; i++)
    {
        ret = printf("%s: %zu bytes, alignment: %zu bytes\n",\
        types[i].data_name, types[i].data_size, types[i].data_align);
        // printf()にエラーが起きた場合
        if (ret < 0)
            return -1;
    }
    return 0;
}

int main()
{
    // データ型の名前とサイズとアライメント（照準、配置）を収納したハッシュテーブル
    DT types[] = {
        {"\t int", sizeof(int), _Alignof(int)},
        {"unsigned int", sizeof(unsigned), _Alignof(unsigned)},
        {"\t long", sizeof(long), _Alignof(long)},
        {"unsigned long", sizeof(unsigned long), _Alignof(unsigned long)},
        {"\t long long", sizeof(long long), _Alignof(long long)},
        {"unsigned long long", sizeof(unsigned long long), _Alignof(unsigned long long)},
        {" short", sizeof(short), _Alignof(short)},
        {" float", sizeof(float), _Alignof(float)},
        {"double", sizeof(double), _Alignof(double)},
        {"  bool", sizeof(bool), _Alignof(bool)},
        {"char  ", sizeof(char), _Alignof(char)},
        {"char* ", sizeof(char*), _Alignof(char*)},
        {"char**", sizeof(char**), _Alignof(char**)},
        {" size_t", sizeof(size_t), _Alignof(size_t)},
        {"ssize_t", sizeof(ssize_t), _Alignof(ssize_t)},
        {NULL, 0, 0} // Sentinel value 番兵ノードとして機能
    };

    return print_size_of_data_types(types);
}

```

同じくC言語学習中の方々に役立ててもらえたら。
Azure Functionsの不具合発生時のログの見方とChatGPTの活用法

# Azure Functionsの不具合発生時のログの見方とChatGPTの活用法

Azure Functionsを利用していると、思わぬ不具合に遭遇することがあります。不具合の原因を特定し、迅速に解決するためには、ログを正しく読み取るスキルが必要です。また、ChatGPTのようなAIツールを活用することで、調査作業を効率化することも可能です。本記事では、以下のポイントに基づいて解説します。

1. Azure Functionsのログの基本的な見方  
2. ChatGPTを活用したログ解析
3. AIに頼りすぎない重要性と適切な役割分担  

---

## 1. Azure Functionsのログの基本的な見方

Azure Functionsの不具合解析では、ログを確認するスキルが重要です。以下に、ログを見る際の基本的な手順を示します。

### 基本的な手順

1. **問題の発生を確認**  
   - Azureポータルで対象のFunction Appを開き、トリガーの実行状況を確認します。  
   - エラー発生時のタイムスタンプを記録しておくと調査がスムーズになります。

2. **ログを取得**  
   - Azureポータルの「Log Stream」を利用してリアルタイムログを確認します。  
   - 「Application Insights」では、実行ログの詳細やエラー情報が検索可能です。

3. **エラーメッセージを探す**  
   - `Exception` や `Error` のキーワードを含むログを見つけます。  
   - 例:  
     - 関数名: エラーが発生したFunctionの名前  
     - タイムスタンプ: エラーが発生した時刻  
     - スタックトレース: プログラム内でエラーが発生した位置を示す情報  

4. **メトリクスを確認**  
   - Azure MonitorやApplication Insightsを使用して、CPU使用率やメモリ使用量などのメトリクスを確認します。不具合がリソース不足に関連している場合があります。

5. **トレース情報を分析**  
   - Application Insightsでトレースログを確認し、実行中のステップやデータの流れを追跡します。  
   - カスタムログ（必要に応じて実装）を使うと、重要な箇所を特定しやすくなります。

---

## 2. ChatGPTを活用したログ解析

### ChatGPTの役割

ChatGPTは、ログの内容を解釈し、可能性のある原因や解決策を提示するサポートツールとして役立ちます。以下のように活用することがあります。

1. **ログをそのままChatGPTに入力**  
   - エラーメッセージやスタックトレースを貼り付けることで、原因候補を提案してもらいます。  
   - 例: `System.NullReferenceException` が発生した箇所を解説してもらう。

2. **エラーの背景情報を提供**  
   - 「このエラーは特定のライブラリや設定が原因の可能性が高い」などの情報を確認できます。

3. **調査の補助的な利用**  
   - AIは問題を特定するプロセスの補助として活用します。すべてを任せるのではなく、自身の調査と併用することが重要です。

---

## 3. AIに頼りすぎない重要性と適切な役割分担

### AIの限界

ChatGPTは強力なツールですが、提示する原因や解決策が必ずしも正しいとは限りません。例えば、以下のような場合に注意が必要です。

- **誤った原因を提示する可能性**  
  - ChatGPTはログから推測するだけなので、実際の原因と異なる場合があります。
- **複雑なシステムの全体像を理解できない**  
  - システム設計や設定を熟知している人間でなければ分からない情報も多いです。

### 適切な役割分担

プログラムのどこで不具合が発生しているかを最終的に確認するのは、やはり人の役割です。ChatGPTは以下のような場面で活躍します。

#### ChatGPTで確認するポイント
1. **ログの内容を迅速に解釈する**  
2. **可能性のある原因を広げる**  
3. **解決策のヒントを得る**  

しかし、提示された内容が正しいかどうかを検証するのは人間の責任です。ログの基本的な見方を基に内部の挙動の把握や原因の予測を行った上で、補足的に活用することをお勧めします。

---

## まとめ

Azure Functionsの不具合発生時には、まずログを正しく読み解くスキルを磨くことが重要です。そのうえで、ChatGPTのようなAIツールにを補助的に活用することで、効率的な問題解決が可能になります。ただし、AIに依存しすぎると原因特定に時間がかかることもあるので、自身の調査や検証を大切にしましょう。

---
Sequence Makerでメッセージボックスを表示する「#MSG」コマンドについて

## はじめに
Sequence MakerはExcelから測定器を制御可能にするアドインです。Sequence Makerは様々なシーケンスを自由に組むことができますが、Sequence Maker専用コマンドを組み合わせるとより複雑な処理を行うことができます。この記事ではメッセージボックスを表示する「#MSG」コマンドについて解説していきます。なお、Sequence Makerについての詳細は以下の記事を参照ください。

https://qiita.com/sequencemaker/items/8e6a370ab0a793a06a3b

:::note warn
***お断り***
本記事の内容はSequence Maker開発元の公式見解ではなく、あくまでも個人が趣味の範囲内で執筆しているものです。記事の内容について開発元へ問い合わせることはお控えください。ご質問・要望などは各記事のコメント欄へお願いいたします。
:::

## 「#MSG」コマンド

| 専用コマンド | 機能 |
|:-|:-|
| #MSG(文字列)	 | 指定された文字列をメッセージボックスで表示します。<br>コマンド送受信の処理は一時停止し、メッセージボックスを閉じた後に再開します。|

（https://sequencemaker.hioki.com/manual/ja/#command　より引用）

#MSGコマンドは（文字列）に好きな文字列を指定して、メッセージボックスを表示させることができます。例えば、Excelのシートに
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3821782/ba391c9c-5d27-d7d0-1c96-49c7b0e2ce7e.png)
このように記載してシーケンスを開始すると、
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3821782/cc47c471-fdeb-7910-959f-2a15817031dc.png)
このようなメッセージボックスが表示されます。この状態でシーケンス処理は一旦停止中なので、一時的に処理を止めておきたい時にも使用できます。
「OK」ボタンを押すと、シーケンス処理を再開します。
「キャンセル」ボタンを押すと、シーケンス処理を中断します。

:::note warn
注意
#や括弧()はすべて半角記号です。ついつい全角で記入してしまうと機能しないので注意してください。
:::

## Excel関数と組み合わせる
#MSGコマンドはExcelの数式と組み合わせて使用することもできます。例えば文字列連結と今日の日付を取得する関数を組み合わせて書くとこんな感じです。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3821782/a68fc687-7422-3df0-5533-f94ce677928d.png)

シーケンスを実行すると、メッセージの内容を動的に変えることができます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3821782/4e82789e-71de-3655-eb77-2660afa15a71.png)

これを利用して、測定器から取得した測定値を表示したり、FAIL/PASS判定などの判定結果を表示することもできます。

## メッセージを改行する
メッセージはちょっとした工夫をすると改行することができます。先ほど説明したExcelの関数と組み合わせ、改行したい位置にCHAR(13)を入れて文字列を連結します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3821782/79a1f4dd-29a4-2f9b-8c1e-7f2f2e0e06ab.png)

すると、こんな感じにメッセージが表示されます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3821782/28c6b939-c2a3-3c14-3eba-b7090d157815.png)

::: note
CHAR(13)は改行コードのCRの意味になります。
:::

## メッセージを改行する　その2
Sequence Maker V1.70からはセル内で改行するだけでOKです。セル内での改行は「Alt」+「Enter」です。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3821782/228a2803-de23-e213-8924-f4add3607e53.png)

## まとめ
今回はメッセージボックスを表示する「#MSG」コマンドについて解説しました。#MSGコマンドはとても簡単に使えるので、ぜひいろいろなメッセージの表示を試してみてください。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3821782/42efd48a-ecb6-ba0a-741b-453d62da045a.png)
Python並列処理 Lockについて


## マルチスレッドの競合

マルチスレッド環境だと、１つのリソースや変数などに複数のスレッドから同時にアクセスすると、その変数がおかしな値になってしまいます。

### 競合が起きるプログラム

1 から 100 万をカウントするプログラムです。
３つのスレッドで動かすので期待する値は 3000000 です.

```python
import threading


class Counter:
    def __init__(self):
        self.count = 0

    def count_up_million(self):
        for _ in range(1000000):
            self.count += 1


def worker(counter):
    counter.count_up_million()


def main():
    counter = Counter()
    threads = []
    for _ in range(3):
        thread = threading.Thread(target=worker, args=(counter,))
        threads.append(thread)
        thread.start()

    for thread in threads:
        thread.join()

    print(counter.count)


if __name__ == '__main__':
    main()
```

#### 結果

```
1539515
```

変な数字になる



## 排他制御(Lock)

同時にアクセスしてもデータの整合性を保つために行う制御が排他制御(Lock)です。

### 先ほどのプログラムに Lock を用いる

先ほど期待した結果が出なかったプログラムに Lock をするように修正しました。

```python
import threading


class Counter:
    def __init__(self):
        self.count = 0
        self.lock = threading.Lock()

    def count_up_million(self):
        for _ in range(1000000):
            with self.lock:
                self.count += 1


def worker(counter):
    counter.count_up_million()


def main():
    counter = Counter()
    threads = []
    for _ in range(3):
        thread = threading.Thread(target=worker, args=(counter,))
        threads.append(thread)
        thread.start()

    for thread in threads:
        thread.join()

    print(counter.count)


if __name__ == '__main__':
    main()
```

#### 結果

```
3000000
```

無事に 3000000 が出力されました 👏
『○○駆動開発』を浅く理解する

ドメイン駆動開発とか、テスト駆動開発とか良く聞く機会があるけれども、正直あまり理解できていないので『○○駆動開発』について浅くまとめておこうと思う

### そもそも『○○駆動開発』ってどんな考え方？

駆動は動力を伝えて動かすこと。つまり、〇〇の中には「動力となるもの」が入る

例えばテスト駆動開発なら、テストを動力、つまり軸にして開発を進めていくこと。

チケット駆動開発なら、チケットを軸にして開発を進めていくこと。

### **色々な『〇〇駆動開発』についてみていこう**



**ドメイン駆動開発(DDD)**
そもそもドメイン(ドメイン知識)は業務知識の事。

例えば医療ソフトのドメイン知識は医療の知識の事だし、ヤフオクなら商品カテゴリの知識とか古物の売買に関する知識とか

『ドメイン駆動』なので、ドメイン知識(業務知識)を軸にしっかり理解したうえで開発を進めていこうぜってスタンスの開発。


**テスト駆動開発**
コードを書く前にテストケースを書いてから始める開発手法の事

手順としては

1. テストを書く
2. テストを通すためのコードを最短で書く
3. コードを整理して改善する(リファクタリング)

最初にテストを書いてしまうから、簡単にバグ発見できるし、コードの品質が安定する

**ビヘイビア駆動開発**
テスト駆動開発にとても似ているが、より行動に焦点を当てた開発手法。

テスト駆動開発は『テストを作る事』自体に焦点を当てているが、ビヘイビア駆動開発は『システムがどのように動くべきか』に焦点てテストを書いている。

これによってただ動くだけではなくて、ユーザーが求めているような振る舞いができるような開発。

**チケット駆動開発**
作業をタスクに分割して、そのチケットに担当者を割り当てて開発するようなスタイル

アジャイル開発との親和性が高く、色々な会社で当たり前のように使われているイメージがある。

**コンポーネント駆動開発**

Reactみたいな感じでコンポーネントを組み合わせて作っていくような開発スタイル。

メンテナンスも簡単になるし、再利用性が上がる事から大規模開発に向いている

**ユースケース駆動開発**
システムの機能の要件を明確にするためにユースケース(使われ方)を考えた上で動作を定義して開発していくような開発手法。

ユーザー視点でのコード開発ができる

**データ駆動開発**
経験だったり、勘だけではなく、データを基に意思決定をして、製品の品質だったり改善をする開発手法。

ユーザーの行動をデータによって客観的に把握するところで製品の改善点を見つけたりできる

**機能駆動開発**
小さな機能ごとに設計から開発までを短期間で繰り返すことで開発を進めていく手法
アジャイル開発的な感じ
フリーランスエンジニアがポートフォリオ作ってみた その１

# フリーランスエンジニアがポートフォリオ作ってみた その１
## 作成する経緯

現在はフリーランスになってようやく3年が経過しました。

エージェントを利用して仕事を頂いていますが、
今後のことを考え、ポートフォリオを作成しようと考えています。
自分自身で営業活動や発信をしていくべきではないかと思いましたので、そこで作成しています。

## ポートフォリオを作成するべき点での注意事項
- 誰にむけて作るべきかを考える
- 見てもらう人になるを伝えるべきかを整理する
- 今までの経歴や経験した技術が今後の考え方が明確に伝わること


## 項目の洗い出し
何の項目があるかを下記で整理

- 自分自身の自己紹介、今後していきたいとことや学習している
- 経験したスキルセットの明確化、視覚的に分かりやすくする <br> ※視覚的とは図や表等を用いる
- 技術発信しているツールなどを載せる(X、Qitta、Github)

## まとめ
自分自身ではフリーランスエージェント様やクライアント様が分かるようなにすること、そして自分自身が整理することができる。

## 参考にしているポートフォリオ
[Hoda's Portfolio](https://hodalab.com/portfolio/)
day6 『人月の神話』

## はじめに
　この書籍はシステム開発の業界で極めて有名です。『人月の神話』（１９７５年初版）は、工数として「**１人**✕**３ヶ月**」と「**３人**✕**１ヶ月**」は異なるものだと伝えています。しかし、未だに**人月**を単位として見積るプロジェクトは多数存在し、顧客と意味のない数字遊びを続けている営業も多数存在します。それがソフトウェア後進国の現実の姿です。
　また増補版で追加された『銀の弾丸などない』は、ソフトウェア実装の複雑性を一気に解決する方法はない、という主張です。
 （なお、本書は１９９５年に大規模改定されています。今回はそちらを見ながらポイント解説します。）

![人月の神話 目次2.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/533414/543e3958-fb4b-eb9b-0a00-ae1396f0238d.png)




## ポイント
### 第２章『人月の神話』
- 人月とは、**人**と**月**が相互に交換可能だという意味を表す。これが成り立つ前提の１つは作業者間でコミュニケーションが不要な場合（完全分散可能のケース）のみ。
- 波及：スケジュールの遅延が発覚した場合に、**期間の追加ではなく、要員を追加してしまう**。しかし、…
- **ブルックスの法則：遅れているソフトウェアプロジェクトへの要員追加は、さらにプロジェクトを遅らせるだけだ。**

### 第３章『外科医チーム』
- プログラマの生産性は１０倍違う。
- 調整を必要とする人の数が、労力コストに絶対的な影響を及ぼす。コストの大部分がコミュニケーションとなり、うまくコミュニケーションできなかったことにより発生するマイナス面の修復のコストとなる。
- 少数精鋭チームは１０人を超えてはならない。
- 大規模チームの構成は外科手術チームのように編成すべき。一人が執刀医（チーフプログラマ）、副、事務係、ツール制作者、テスト担当者、ｘｘｘエキスパート、管理者、編集者、秘書

### 第１６章『銀の弾などない』
- **銀の弾丸**：狼人間を退治するには、銀の弾丸を使うしかない。
- 本質的作業：抽象的なソフトウェアを構成する複雑な構造体を作り上げること。（設計のことか？）
- 偶有的作業：それをプログラミング言語で実装すること。

## 書誌情報
- 書籍名：人月の神話
- 著者：フレデリック・P・ブルックス,Jr.
- 出版社：丸善出版
- ISBN：978-4-621-06608-9

## 参考
-
WebSocketについて完全に理解した

:::note warn
わかりやすくするためざっくりとした概念を記載しています。
一部、一部正確性を欠く可能性があります。
:::

# WebSocketとは

WebSocketは、クライアント（例: ブラウザ）とサーバーの間で、双方向かつリアルタイムにデータをやり取りできる通信技術です。

通常のHTTP通信では、クライアントからリクエストを送信して初めてサーバーが応答を返します。しかし、WebSocketでは最初に一度だけ接続を確立すると、その後はクライアントとサーバーの間で自由にメッセージを送り合うことができます。

# WebSocketの仕組み

### ハンドシェイク
最初にクライアントがサーバーに「WebSocket接続を開始したい」というリクエストを送ります。サーバーがこれを承認すると、接続が確立されます。

### データの双方向通信
接続が確立されると、クライアントとサーバーは互いに自由にデータを送受信できます。これにより、リアルタイム性が求められるアプリケーションで高いパフォーマンスを発揮します。

# HTTPとWebSocketの違い

### HTTP通信の仕組み
HTTP通信では、クライアントが必要なときにリクエストを送信し、その都度サーバーからデータを受け取ります。この方式はシンプルで、通常のウェブサイトに適しています。しかし、以下の制約があります。

毎回リクエストを送らないと情報が取得できない。
リアルタイム性が低い。

例
ブラウザでページを更新するたびに最新データが取得される。
チャットアプリの場合、何度もリクエストを送らないと新しいメッセージが表示されない。

### WebSocket通信の仕組み
WebSocketでは、最初に接続を確立すれば、その後はクライアントとサーバーが自由にデータを送り合えます。これにより、リアルタイムなデータ更新が求められるシステムで高い効率を実現します。

例
サーバーが新しいデータを検知すると、自動でクライアントに通知を送る。
チャットアプリで新しいメッセージが即座に反映される。

| **特徴**             | **HTTP通信**                    | **WebSocket通信**                     |
|----------------------|---------------------------------|---------------------------------------|
| **通信方向**         | クライアント → サーバーのみ     | クライアント ↔ サーバー（双方向）     |
| **データ送受信の仕組み** | リクエスト・レスポンスのセット   | 接続後、自由にデータ送信可能          |
| **リアルタイム性**    | 低い                           | 高い                                  |
| **接続の効率**       | リクエストごとに接続を作る       | 最初の接続を維持し続ける              |

# WebSocket通信の全体像

```mermaid
graph TD;
    Client[クライアント] -->|HTTPリクエスト| HTTPServer[HTTPサーバー];
    HTTPServer -->|HTTPレスポンス| Client;

    Client -->|WebSocket接続リクエスト| WSServer[WebSocketサーバー];
    WSServer -->|プロトコル切り替え| Client;

    Client <-->|リアルタイムデータ通信| WSServer;

    WSServer -.->|データ取得| HTTPServer;
    HTTPServer -.->|データ送信| WSServer;
```

# まとめ
WebSocketを活用することで、チャットアプリやリアルタイム通知のような高パフォーマンスが求められるアプリケーションの効率が飛躍的に向上します。
実録❗️📸入社翌月に新参者が初導入したペアプログラミングはあれからどうなったか⁉️

この記事は [ex-crowdworks Advent Calendar 2024](https://qiita.com/advent-calendar/2024/ex-cw)の3日目の記事です。

# はじめに

今年、株式会社クラウドワークスを退職した@nisyuuです。ホームサウナは[トーセイホテルココネ築地銀座プレミアム](https://tosei-hotel.co.jp/tsukijiginzapremier/bath/)です。
エンジニアとしてクラウドワークステック（旧クラウドテック）というフリーランスと企業をマッチングするエージェントサービスを開発していました。

クラウドワークスに入社後、エンジニアブログにこちらの記事を投稿しました。

https://engineer.crowdworks.jp/entry/2022/05/09/170000

今回は、ペアプロがその後どうなったかを紹介しようと思います。

# ペアプロ導入のきっかけ
きかっけは既にエンジニアブログに記している通りですが、簡単に説明すると既存メンバーが持っている業務知識と自分の技術知識のトレードが目的でした。

# その後
ブログの投稿後も、ペアプロはチームの文化として根付きブラッシュアップしながら継続していました。
頻度は週2回で1回30分での実施です。
ブログ投稿後からチームの人数が一気に拡大したため、[ペアプロの良いところ](https://engineer.crowdworks.jp/entry/2022/05/09/170000#%E3%83%9A%E3%82%A2%E3%83%97%E3%83%AD%E3%81%AE%E8%89%AF%E3%81%84%E3%81%A8%E3%81%93%E3%82%8D)でも紹介したこちらの3つの効力がしっかり生きたのではないかと思います。

- 技術スキルや業務知識などのノウハウが共有できる
- コードレビューの前にアドバイスが受けられる
- チームの醸成になる

マネージャーから、面談などでペアプロの取り組みについて話をすると、相手からの印象が良かったというのを聞いたので、結果として会社全体にもプラスだったのではないでしょうか。

さらに、文化として根付いたペアプロは、定期で予定に入れている時間だけでなく各々が必要なときに他メンバーへ声をかけて自律的に実施するまでに至りました。

***これこそペアプロのあるべき姿です。*** 🥸😎🤓

# ペアプロの進化
チームが大きくなり、これまで以上にタスクができるようになるとレビューが溜まりがちになる問題が出てきました。
エンジニアに成り立てのメンバーもおり、レビューにハードルがあったことからレビュワーに偏りがあったことも問題の要因でした。
そのため、各エンジニアとチーム全体で実装の時間よりレビューに使う時間を増やしていく必要があり、その打開策としてペアプロをペアレビューに進化させました。
ペアレビューは造語かもしれないので意味を一応意味を説明すると、ペアで1つのPRなどをレビューすることです。
既にペアプロは各々が自発的に取り組むフェーズに達していたので、定期実施しているペアプロを問題なくペアレビューに変更できました。

ペアレビューもペアプロと同じように、レビューのノウハウを共有ができ、話し合いをしながらレビューすることができるためチームの醸成になります。
2人以上でレビューすることにもなるため、レビュー精度の向上にも繋がります。

# おわりに
ペアレビューをすることで、少しでもレビューの解消につながった他、レビューをすることへの意識付にもなったのではないかと思います。

本記事で紹介した取り組みは、マネージャーやリーダーが決定して導入したものでなく、メンバーやチームが自己修正してできたものです。もちろん、マネージャーに相談などはしましたがトップダウンでなくボトムアップに意思決定をしました。
***まさにティール組織***
現在も将来有望な未来ある優秀な若者たちがペアプロ、ペアレビューを継続してくれているだろうと思います🤘🏻😎🤘🏻
モブプロ・ベストプラクティスを読んでみた感想

# この記事で伝えたいこと
モブプログラミングの良書「モブプログラミング・ベストプラクティス」を読んでみました。どんなところが参考になったか、どんなところに疑問を感じているかなどをメモしたので、みなさんがモブプロをやる時の一助になればと思います。

# はじめに
ペアプロ・モブプロをちゃんとやってみたいなと最近感じていて、なにか体系化されている情報があれば先に勉強しておきたいと思い、まとまっている本がないか探してみました。
最初はペアプロから調べてみたのですが、ペアプロに関する本っていうのが本当に見つからなくて、モブプロというテーマで評価の高いこの書籍を買って読んでみることにしました。

# 今までの自分のペアプロ・モブプロ経験
「ペアプロをする」「モブプロをする」という意識で取り組んだことは、今までありませんでした。PRを出す前にちょっと不安なことがあったら対面で確認してもらったり、必要に応じて同じコードを見て同期的に確認することはあり、それが結果として「ペアプロっぽくなってる」くらいです。

# 印象に残った箇所
### リソース効率とフロー効率
> モブプログラミングの考え方は、本質的にフロー重視であり、機能を安く作るのではなく、早く完成させることを目標としている。言い換えれば、リソース効率ではなくフロー効率を上げようという考え方だ。

リソース効率というのは各リソース(ここでは人)の稼働率や利用率を最大化する考え方で、**どれだけ人が効率よく働けているか**を重視します。

一方、フロー効率は**実際に価値を生み出すまでのリードタイムを早くする考え方**です。

モブプロをすると、「3人でやると効率が悪いんじゃないの？」という疑問が(主に管理職から)挙げられるのではないでしょうか。1人でやることをわざわざ3人で取り組むことになるので、当然の疑問だと思います。実際、リソース効率の観点では効率が下がります。

しかし、フロー効率を上げる方法としてはモブプロはいくつかの面で大きな効果があります。

例えば、属人性を減らすことができます。並行して作業すると各タスクは基本的に担当した人がコードやタスクの内容を把握していますが、**モブプロで仕事を進めることで個人への依存を減らすことができます**。これは特に、重要度や影響範囲の大きいタスクでメリットを感じやすいと思います。

また、チームメンバーがお互いのアイデアや知見を頻繁に共有できるようになり**技術力の底上げやスキルアップ**にも繋がります。

他にも、レビューの効率が上がったり、品質が向上するというメリットもあります。3人分のリソースを割くという点で非効率な部分はあると思いますが、**全員で認識を揃えながら開発を進めることで、将来的な開発の速さにつながったり、アイデアを共有することで得られるスピード感は体感できると思います。**

### モビングを実験として位置付ける
> 初めてモブプログラミングをしてみようというときには、実験として位置付けることが大切だ。そういう位置付けだと、期待が高くなりすぎず、参加者も心理的なセーフティネットを張ることができる。

これは直感的にもすごく大事だと思いました。新しい開発手法を導入する時って「こんなメリットがあるから」ってところに熱が入りすぎちゃうこともありますが、上手く噛み合わなかった時に「ダメだったね、やめようか」となってしまいかねません。

正直、新しい取り組みなんて最初はたいてい失敗するので、**それを振り返ってカイゼンのサイクルに乗せていくことこそ大事だと思います**。上司などを説得する時も「最初は上手くいかないかもしれないけど、こういったメリットがあるので継続的に取り組みたい」という合意をちゃんと取っておくべきかなと感じます。

### モブタイマーを用意する
> モビングインターバルは、10分間のタイマーをセットして始まる。10分にすると、モブのメンバー全員に数回ずつタイピストの版が回ってくるのでモブセッションが上手く回る。

話は飛びますが、モブプログラミングをやる時の話です。

少しややこしいのですが、モビングセッションというのが準備やふりかえりを含めたモブプロ全体のことで、実際にプログラミングを行う時間がモビングインターバルです。

タイマーで時間を測って交換するのはすごく良いなと思いました。時間の制限がないと交換のタイミングも難しいですし、短い時間で区切ることで、集中力も保てるようになる気がします。

ただ、10分っていうのは少し短すぎる印象もあるので、タスクの難易度や内容によって15分や20分くらいでもいいんじゃないかと感じています。大事なのは時間で区切ることかなと。

### 経験からの学習
> セッションの最後の20分は、モビングを締めくくるためのレトロスペクティブ(反省会)に充てる。ここでは、モビングに参加したメンバーが感じたことを述べ合い、次回に軌道修正すべきこと提案する。

モブプロの一連の流れにふりかえりを入れるという発想がなかったので、少し驚きつつも非常に効果的ではないかと思います。モブプロに慣れていないチームだと細かいところで詰まったり上手くいかないことが多いので、ふりかえりがないと「なんか上手くいかないな」「モブプロってやり方自体が失敗だったかな」と考えてしまい、モブプロやめちゃう例もあるのではないかと思います。

もちろん、モブプロをやること自体が目的ではないのでチームやタスクの進め方に合わないのであれば無理に続ける必要はないと思いますが、やり方を工夫して効果を発揮するケースもあると思うので、最後に意識的に振り返りの時間を設けることは大事だと思います。

スクラムで開発を進めている方だと、スクラムイベントレトロスペクティブがあるのでこういう文化は当たり前だと感じる人も多いかもしれませんが、ふりかえりって意識しないと意外とできないんですよね。忙しい時ほどスキップしがちだと思います。

# 全体を通しての感想
この本を読んでみて、モブプロでありがちな失敗や、ベースとなる進め方を学ぶことができて非常に大きな学びとなりました。モブプロをこれから始める人にも、やったことがある人にもおすすめできる一冊です。

また、書籍の中で「モブプログラミングを直接の対象とする研究はまだ多くない」とも述べられていて、意識してモブプロに取り組むことは、まだまだメジャーな開発の手法ではない気がしています。大学の研究でモブプロを扱っておけばよかったな、と少しもったいない気持ちも感じています。いやー、当時は関心が全然違っていて仕方なかった。

直感的にもフロー効率を上げるのにモブプロが有効だと感じていて、ここ最近実践をしています。詳しい内容についてLTや記事でそのうち話せる機会を作りたいなと思っているので、よかったらその時も読んでいただけると嬉しいです。

# 参考
[モブプログラミング・ベストプラクティス ソフトウェアの品質と生産性をチームで高める](https://amzn.asia/d/8tX5vPx)
【競技プログラミング】AtCoder Beginner Contest 336_D問題

# 問題
https://atcoder.jp/contests/abc336/tasks/abc336_d

# 既存投稿一覧ページへのリンク
[一覧ページ](https://qiita.com/o_chan_t/items/fc759695acfaef8df2cc)


# アプローチ
数列Aの各要素に対して、その位置から左側と右側それぞれで作れるピラミッド数列の最大サイズを求め、その中で最も大きな値を答えとする。


# 解法手順

1. 入力された数列Aを受け取る。

2. 左側からのピラミッド数列の最大サイズを求める：
   - 数列bを用意し、左から順に走査する。
   - 各位置iにおいて、min(Ai, i+1)の値をbiに格納する。
   - これにより、各位置から左側で作れるピラミッド数列の最大サイズが得られる。

3. 右側からのピラミッド数列の最大サイズを求める：
   - 数列cを用意し、右から順に走査する。
   - 各位置iにおいて、min(Ai, N-i)の値をciに格納する。
   - これにより、各位置から右側で作れるピラミッド数列の最大サイズが得られる。

4. 各位置iにおいて、min(bi, ci)を計算する：
   - これは、位置iを中心とするピラミッド数列の最大サイズを表す。

5. 手順4で得られた値の最大値を求める：
   - この最大値が、問題の答えとなる。

6. 最大値を出力する。


# ACコード
```python:ac.py
# 1. 入力された数列Aを受け取る
n = int(input())  # 数列の長さを入力
a = list(map(int, input().split()))  # 数列Aを入力

# 2. 左側からのピラミッド数列の最大サイズを求める
b = []  # 左側のピラミッド数列の最大サイズを格納するリスト
cnt = 1  # カウンター（位置）
for x in a:
    cnt = min(cnt, x)  # min(Ai, i+1)の値を計算
    b.append(cnt)  # 計算結果をbに追加
    cnt += 1  # カウンターを増やす

# 3. 右側からのピラミッド数列の最大サイズを求める
c = []  # 右側のピラミッド数列の最大サイズを格納するリスト
cnt = 1  # カウンター（位置）
for x in a[::-1]:  # 数列Aを逆順に走査
    cnt = min(cnt, x)  # min(Ai, N-i)の値を計算
    c.append(cnt)  # 計算結果をcに追加
    cnt += 1  # カウンターを増やす

# 4. 各位置iにおいて、min(bi, ci)を計算し、5. 最大値を求める
ans = 1  # 最大のピラミッド数列サイズを格納する変数
for x, y in zip(b, c[::-1]):  # bとcを同時に走査（cは逆順）
    t = min(x, y)  # 各位置でのmin(bi, ci)を計算
    ans = max(t, ans)  # 最大値を更新

# 6. 最大値を出力する
print(ans)  # 結果を出力

```

# ピラミッド復元コード
```python:ac.py
# 1. 入力された数列Aを受け取る
n = int(input())  # 数列の長さを入力
a = list(map(int, input().split()))  # 数列Aを入力

# 2. 左側からのピラミッド数列の最大サイズを求める
b = []  # 左側のピラミッド数列の最大サイズを格納するリスト
cnt = 1  # カウンター（位置）
for x in a:
    cnt = min(cnt, x)  # min(Ai, i+1)の値を計算
    b.append(cnt)  # 計算結果をbに追加
    cnt += 1  # カウンターを増やす

# 3. 右側からのピラミッド数列の最大サイズを求める
c = []  # 右側のピラミッド数列の最大サイズを格納するリスト
cnt = 1  # カウンター（位置）
for x in a[::-1]:  # 数列Aを逆順に走査
    cnt = min(cnt, x)  # min(Ai, N-i)の値を計算
    c.append(cnt)  # 計算結果をcに追加
    cnt += 1  # カウンターを増やす
c = c[::-1]  # cを元の順序に戻す

# 4. 各位置iにおいて、min(bi, ci)を計算し、5. 最大値とその位置を求める
ans = 1  # 最大のピラミッド数列サイズを格納する変数
max_pos = 0  # 最大のピラミッド数列の中心位置
for i, (x, y) in enumerate(zip(b, c)):  # bとcを同時に走査
    t = min(x, y)  # 各位置でのmin(bi, ci)を計算
    if t > ans:
        ans = t  # 最大値を更新
        max_pos = i  # 最大値の位置を記録

# 6. 最大のピラミッド数列を生成
pyramid = []
for i in range(1, ans + 1):
    pyramid.append(i)
for i in range(ans - 1, 0, -1):
    pyramid.append(i)

# 7. 結果を出力
print(f"最大のピラミッド数列のサイズ: {ans}")
print(f"最大のピラミッド数列の中心位置: {max_pos + 1}")
print(f"最大のピラミッド数列: {' '.join(map(str, pyramid))}")
```
day4 『デスマーチ』なぜソフトウェア・プロジェクトは混乱するのか

## はじめに
　「デスマーチ（死の行進）」は長い間、多くのプロジェクト関係者を悩ませています。某サクラダファミリアと呼ばれる銀行システムでも続いているでしょうか。
 　私は、その最も合理的な回避策について私はトリアージを自然に組み込んだアジャイル開発への移行だと思ってますが、ウォーターフォール開発に突入する際には、覚悟をしなければいけません。

![デスマーチ 目次2.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/533414/ac4ce831-b816-ac91-c5dd-48cffeb07230.png)


## ポイント

### デスマーチ（死の行進）の定義
- プロジェクトのパラメータが正常値を５０％以上超過しているもの。
- **or** 公正かつ客観的にプロジェクトのリスク分析（技術要因の分析、人員の解析、法的分析、政治的要因の分析も含む）をした場合、失敗する確率が５０％を超えるもの。

### 発生要因
- いろいろ。

### 知るべきはトリアージ(triage)
- 開発システムの要求項目を**３つ**に分類する。
    - **やらねばならぬ。must-do**
    - **やった方が良い。should-do**
    - **やれればやる。could-do**
- ４つ以上に分類してはいけない。優先度３か優先度４か、という不毛な議論は避ける。
- トリアージは、戦場や災害が起きた場所で、割り当てなければならない医療資源に限りがある場合に用いられる手法として有名。

### 残念な現実
- プロジェクト開始時からトリアージできれば事態は悪化しない。しかし、プロジェクト開始時にプロジェクト・マネージャから幹部への進言に対し、幹部はそれを理解しない。
- 納期に間に合わないことが現実的になってきて、初めて幹部が騒ぎ始める。そして、プロジェクト・マネージャの責任とされて退職する。
- 新たな後任のプロジェクト・マネージャ（火消し）が納期延伸や要求項目の精査を実施する。チームがその酷い危機に陥った理由が幹部にあったことがわかるので、今度は強く幹部と交渉できる。

### デスマーチ・プロジェクトは常態であって例外ではない。

## 書誌情報
- 書籍名：『デスマーチ』なぜソフトウェア・プロジェクトは混乱するのか
- 著者：エドワード。ヨードン
- 出版社：トッパン
- ISBN：4-8101-8982-1

## 参考
- 「みずほ システム障害」でYouTube検索すると、・・・
24/11/30 読書記録 ~ソフトウェアテストの教科書~

# 書籍
[【この1冊でよくわかる】 ソフトウェアテストの教科書](https://amzn.asia/d/6jSYRVM)

# 書籍を読む目的

 - [ ] 「品質」を理解する
 - [ ] 品質を担保できるテストを理解する


## Chap06. 状態遷移テスト

### 学び 📝

開発仕様書から状態遷移の全体像を把握するために行われる。
ハードウェア開発で用いられるイメージが強く、ソフトウェア開発ではあまりないイメージ。

### Chap6 感想 :writing_hand_tone5:

ソフトウェア開発であまり用いられるイメージではなく、ザッと流し読みした。
必要性を感じ次第、また見返す。

## Chap07. 組合せテスト技法

### 学び 📝

組合せテスト：複数の条件を組み合わせてソフトウェアの動作を確認するテスト
〜続く〜
Rubyのフレームワーク特集 🎄～Rails以外の選択肢を知ろう～



こんにちは！[Schoo Advent Calendar2024](https://qiita.com/advent-calendar/2024/schoo)の8日目の記事を担当します @ftakizawa です。
最近のマイブームは[んぽちゃむ](https://www.youtube.com/watch?v=isiRBJ-wTsQ)です。
今回は、Ruby界隈で「Rails以外のフレームワーク」について取り上げます。
RubyといえばRailsのイメージが強いですが、実は他にも素晴らしいフレームワークがたくさんあるんです。
Railsが強力すぎるせいで「他のフレームワークを知らない」という方も多いのではないでしょうか？
この記事では、用途別にRubyのフレームワークを紹介していきます。**Sinatra**や**Hanami**などの軽量フレームワークから、特定のユースケースに特化したものまで、幅広く取り上げます！

※GitHubのスター数は2024年11月時点のものです。

---

## **1. Sinatra - 軽量でシンプルなフレームワーク** (⭐️12.2k)
まずはRubyで最も有名な軽量フレームワーク **Sinatra** から。
リポジトリ：https://github.com/sinatra/sinatra

```ruby
require 'sinatra'

get '/' do
  'Hello, world!'
end
```

Sinatraはとにかくシンプル！こんな感じで、ほんの数行のコードでWebアプリが動きます。  
ちょっとしたツールやAPIを作りたいときには最適ですね。軽量さと柔軟性が魅力です。
Railsと比べても公式ドキュメントの量が少なく、Ruby初心者でも簡単にWebアプリケーション開発に取りかかれると思います。

---

## **2. Hanami - アーキテクチャ重視派にオススメ**(⭐️6.2k)
**Hanami** は「堅牢なアプリケーションを作りたい」という人向けのフルスタックフレームワークです。
リポジトリ：https://github.com/hanami/hanami

```ruby
module Web
  class Application < Hanami::App
  end
end
```

アプリケーションをコンポーネントに分割する設計が特徴です。
RailsはMVCパターンをベースにした設計に対して、HanamiはDDDをベースにしています。 
つまりRailsはサービスを素早くローンチすることに向いていて、Hanamiは長期的にメンテナンスすることに向いており、保守性の高いコードを書けることが特徴です。
一歩進んだアプリ設計を学びたい方は、ぜひ試してみてください。


---

## **3. Grape - API構築に特化**(⭐️9.9k)
RESTfulなAPIを手軽に作りたいなら、 **Grape** 一択！
リポジトリ: https://github.com/ruby-grape/grape

```ruby
require 'grape'

class API < Grape::API
  version 'v1', using: :path
  format :json

  get :ping do
    { ping: 'pong' }
  end
end
```
Grapeは、Ruby用のRESTライクな APIフレームワークです。Rack上で実行したり、RailsやSinatra などの既存の Webアプリケーションフレームワークを補完したりするために設計されており、RESTful API を簡単に開発できるシンプルなDSLを提供しています。
APIバージョニングやリクエストのバリデーションが簡単に書けたりします。  
RailsでAPI専用アプリを作るのが大げさに感じたら、Grapeを使ってみましょう。

---

## **4. Roda - 高速で柔軟**(⭐️2.1k)
軽量かつ柔軟なフレームワークなら **Roda** がおすすめ。
リポジトリ：https://github.com/jeremyevans/roda

```ruby
require 'roda'

class App < Roda
  route do |r|
    r.root do
      'Welcome to Roda!'
    end
  end
end
```

Rodaは非同期処理やスレッドセーフな設計が特徴で、とにかく高速。  
必要な機能をプラグインで追加していくスタイルが新鮮です。

---

## **5. Camping - 超軽量！**(⭐️0.9k)
驚くほど小さなコードベースで動作する **Camping**。  
学習用や趣味のプロジェクトにぴったり。
リポジトリ：https://github.com/camping/camping
```ruby
require 'camping'

Camping.goes :MyApp

module MyApp::Controllers
  class Index
    def get
      'Hello Camping!'
    end
  end
end
```

ちょっとしたデモアプリを作りたいときに試してみてください。

---

## **6. Cuba - 最小限のコードでWebアプリ**(⭐️1.4k)
**Cuba** はシンプルなルーティングとパフォーマンスが魅力。
リポジトリ：https://github.com/soveran/cuba

```ruby
require 'cuba'

Cuba.define do
  on get do
    on root do
      res.write 'Hello, Cuba!'
    end
  end
end
```

「コードの最小化」を追求する開発者にはピッタリです。

---

## **まとめ - 自分の用途に合ったフレームワークを選ぼう**
Rails以外の各フレームワークにも独自の強みがあります。
以下を参考に選んでみてください：

- **小規模なツールやAPI**: Sinatra, Grape, Roda
- **堅牢な設計を目指す**: Hanami
- **パフォーマンス重視**: Cuba, Roda

**Rubyの可能性はRailsだけじゃない！**  
このアドベントカレンダーを機に、他のフレームワークにも挑戦してみてはいかがでしょうか？ 🎉


## 参考
https://magazine.rubyist.net/articles/0056/0056-hanami.html#hanami-%E3%81%AF-rails-%E3%81%98%E3%82%83%E3%81%AA%E3%81%84

https://qiita.com/tyanakaz/items/2340a7205a041ff75d47

---
Schooでは一緒に働く仲間を募集しています！
https://corp.schoo.jp/careers/graduates
https://corp.schoo.jp/careers
（イベントレポート・ハンズオンの例）PowerBIセミナー

:::note warn
当時のメモを無編集で公開する
ハンズオンのため、書きながらやりながら、は大変だった！という話を文面から感じてほしい
:::

---

## 本日のセミナー・イベント
デモデータだとは思うが、特定できる情報を書いているので非公開としたい。

### 凡例
筆者注による

:::note
講師から口頭による補足・ポイントなど
:::

:::note warn
考察・理解したこと
:::

## ハンズオン
かなり丁寧にご説明いただいていたため、手順をまとめる

### PowerBIを起動
事前に配布された資料を開く

### データが読み込めているか確認する
カラム：データ・画面右側
（このタイミングで保存作業もやってる）

:::note
PowerBIは自動保存機能がないため、こまめに保存しよう
:::

### データを閲覧する
ボタン：テーブルビュー・画面左側

### データ項目を追加する
リボン：「テーブルツール」より新しい列を追加

### 作成した列に関数を入力
```
滞在時間 = MINUTE([退店時刻] - [入店時刻])
```

:::note warn
凡例： `列名 = MINUTE([列名] - [列名])`かな？
:::

:::note
Excelだとわざわざヘッダー列を作って列名を作り、以下関数を書いていくが、上記コードのように書くと列全体に対して適用できる。列名もこのタイミングで設定している
:::

### 項目を追加（上の手順を再度）
```
利益 = [販売価格] - [仕入価格]
```

### 新しいメジャーを作成
リボン：「ホーム」より新しいメジャーをクリック
入力欄に以下を入力

```
平均滞在時間 = AVERAGE('売上データ管理'[滞在時間])
```

列ではなく、メジャーとして作成される。

:::note warn
変数（列名）を指定する場合、`'テーブル名'[列名]`で別テーブルを参照できる。テーブルに
:::

### 更に新しいメジャーを作成
```
売上利益 = SUM('売上データ管理'[利益])
```

### 同じく
```
COUNTROWS(FILTER('売上管理テーブル',[分類] == 'おにぎり'
```

:::note warn
レポートビューで表示させるために、分析したいデータ列とメジャーを作成したのかな？
:::

### レポートビューに戻る
ボタン：レポートビュー・画面左側

## ハンズオン・ダッシュボードを作る
Webサイトを作るのと同じ要領でできそう

:::note warn
表示項目についてはあらかじめテーブルビューの項目名から表示できるように指定しておく必要がありそう
:::

### ページ設定
レポートページの書式設定
キャンバスの背景から背景を変えてみよう。透過性は０％に（デフォルトで100%？）

:::note
Webサイトをノーコードで作成できるツール（ブロックエディタ）のような要領で作っていくのがいいかも
画面をみながらGUIでいじれる
:::

### 画面にチェックボックスを作る
視覚化カラム・ビジュアルのビルド→スライサー

ここでは年齢のみ指定

### 画面に表示項目を作る
視覚化カラム・ビジュアルのビルド→カード

ここでは売上利益のみ指定

### （書き損じ）
視覚化カラム・ビジュアルのビルド→円グラフ

ここでは滞在時間を指定

### （書き損じ）
視覚化カラム・ビジュアルのビルド→折れ線グラフ

ここではおにぎり・ホットスナック・弁当列名を指定

---

この辺りでついていけなくなった痕跡がみられる。

ハンズオンの場合「後から振り返って学ぶ」という行動を起こすのが大変難しいため、資料を公開する・アーカイブを残すことの重要性が非常に大きくなることに留意したい。
今後の自分への戒めとしつつ、今後ハンズオンを開講される方向けに「参加者の復習の機会をどうするか？」を課題としていただくことを期待する。
【失敗談】Google NotebookLMのソースを自動更新できないか色々やってみた【考察】

:::note
本稿は失敗談としてはいるが、可能性は感じているので継続していきたい
:::

## TL;DR
やりたかったことは以下。

- NotebookLMのデータソースを自動で取得したい
  - ダメらしい。以下URLに試行錯誤の痕跡を残す
- フォルダ以下をまとめて取得したかった
  - これもダメ。ファイル単位で指定が必要のこと

https://docs.google.com/document/d/14D_19MK3bAH-zoeGho_fdbOTO8-V5ntVzdIlURBD9_I/edit?usp=sharing

## 発端
https://omoshiroai.connpass.com/event/323123/

やなしまさんのLTでGoogleNotebookLMの話があり、めちゃくちゃ便利じゃん！ってなった。
で、自分でも使ってみようと思ってガチャガチャやってみた所感をまとめておく。

## Google NotebookLMが使えると何が嬉しいか？
詳細は語らないが、ナレッジ管理ツールにAIが入った版
予めデータソースを突っ込んでおいて、ChatGPTとかを使う感覚でデータ検索ができる

## 所感
### イケてる！…のか？
書いてない内容とGeminiが連携しているらしい！
→自力検証してみたものの、あまりそういう印象は受けない。データソースがないから回答を返せない、という結果がGemini連携の部分だとしたら期待している回答は得られていないことになる
今の所、通常のGPTsサービスを使った方がまだ便利な感じはする

データソースの数を手動でも増やしながらどうなるかは様子見したい

### データソースに限定した範囲での検索システムとしては優秀
外部検索に頼らないということは、データソースに特化した検索サービスを作りやすいという事でもある
同様のサービスはesa、Notionのようなナレッジ管理ツールから勉強用に作ったブログなど色々あるが、

### AIにカンニングノートを作らせる
たとえば、学習ノートの内容をテキスト化してNotebookLMに食わせておけば、テスト時に堂々カンニングできるやん！というのが真っ先に閃いた使い方だ。
もちろん、普段からしっかりノートを執っていることが前提になるので、カンニングのためにノートを執ることで学習効率を高められるなら、勉強法としては良いのではないだろうか？
（私も講師という立場であるためこのような目的自体はいただけないが、学習効果が上がる取り組みとしては評価している、の意）

一応、プロンプトエンジニアリングの練習にもなるし、プロンプトを意識したなんちゃってRAGを作成するわけだから、そういった意味でも知見は得られる。
まるで思春期時代のあの頃を思い出すような話でむず痒さはあるが、いつの時代も自発性・積極性を発揮できるのはこういった裏技発見的なところが大きいのだろうと思う。

### AI活用を前提にしたナレッジ管理手法が身に付く
私が感じたのはこれが大きい。
人間の情報管理とは結構雑なもので、微妙な表記揺れは多く発生したものだ。
で、AIが入ることでこのような表記揺れを気にせずナレッジを溜めることができるようになった。

しかし、AIは万能ではない。
人間の分かりやすさを損なうことなく、AIがまとめやすいように書くことがどういう事なのかを考える事ができる。
極端な表現をすれば、自分用のノートであっても、必ずAIという第三者が介入する事である程度のフォーマットを考えるようになる。
そして、整理された有用なフォーマットとは何かを考えることになり、結果的にノート自体の品質が高まっていく。
ノートの品質が高まると読みやすさに直結するため、結果的に品質の高いナレッジ管理が実現できる。
もちろん、ナレッジ自体の品質もあるのだが、ナレッジ管理の品質が低いせいでナレッジが活かされないという状況は防ぎやすくなることを期待する。

## 結論：NotebookLMの改善とともに、自身のナレッジマネジメントスキルの向上を図ろう
NotebookLMというサービスを通じて、自身のスキルアップができるのであれば万々歳だ。
できればNotebookLM自体をサイトを超えたナレッジ管理ツールのスーパーアプリとして活用しやすい状況になることを期待する。
「連続投稿 Weeklyを完走（50個）する」をTodoリストに入れて管理＋投稿し続ける仕組みの考察

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/122800/91053713-a855-593d-636d-5bf94348093a.png)

Qiitaエンジニアフェスタで38記事？だったっけ、埋めようと思って頑張っていたので、デイリーで38記事（少なくともアドベントカレンダーで25記事）埋めれるならWeeklyで50なんて楽勝でしょ！
というので始めたセルフ企画の話をします。

（追記）なお、投稿時点では24週まで継続できているので信頼性はそこそこある方法、だと思っています。
当然ですが、あくまでも本稿の手順は記事投稿のサポートという位置づけであり、この方法を使えば必ず継続性が生じるというものではありません。

## やったこと
QDD(Qiita Driven Development)を提唱します。Qiitaに記事を書くためだけにやる。
Zennを使っている人はZDDですね。noteならNDD。好きなxDDを作りましょう。

今回はQiitaの記事を書く事を目的にせず、Qiitaの連続投稿Weeklyバッジをもらう事を目的に、しかたなーく記事を毎週投稿します

### 1. 【モチベーション管理】公開リポジトリにIssueとProjectsのタイムラインで可視化する
https://github.com/shimajima-eiji/shimajima-eiji/issues

https://github.com/users/shimajima-eiji/projects/8/views/1

口で言うのは簡単ですが、なんでも「続けるぞ」という強い意志がないとどこかで飽きますし、ダレます。
誰も見てないかもしれないけど、誰でも見える場所に置いておく事は自分を奮い立たせられます

### 2. 【記事管理】下書きをいくつかストックする
重要なのは記事を公開することではなく、毎週１記事以上を書く事です。
必要があって先出しすることはありますが、１記事以上を継続して書き続けられるなら問題ないです。
どうせアドベントカレンダーもある（見送ればだいぶ楽になるのですが、Qiitaのアメニティが欲しいのでがんばります）ので、記事のストックはあればあるほど良い！

なお、記事のネタに困ったら生成AIがアツいので、色々なユースケースを考えて実践しましょう。
記事自体をAIに書かせるには？というテーマで試行錯誤するだけで記事が書けます。まさにQDD！

### 3. 【スケジュール管理】投稿日を見える化する
下書きを書いても、毎週投稿しないと意味がありません。
一番いいのは予約投稿をすることですが、残念ながらQiitaのWebエディタにはそんな機能はありません。
アドベントカレンダーの時期なら予約投稿を限定公開を使うと実現するのですが、平時は残念ながらないので別の方法を使うしかないです。

これを解決する方法を考えてみましょう。

#### 一番楽に対応するならカレンダーアプリ
私の場合は、運用として必ずGitHubプロジェクトをTODOにするというやり方をしています。最初はGoogleカレンダーに書いていたのですが、スケジュールがビッシリ埋まって逆に見づらくなったので廃止しました。GitHub Issueの日付を取ってきてGoogleカレンダーにも登録する、という仕組みを考えたのですが、Issueを書いたら容赦なくバンバンGoogleカレンダーに登録するようになってしまったのも設計ミスです。
特定のタグをIssueに設定しておき、それらを判別してカレンダーに登録する方法もありますが、もう面倒くさくなって廃止しました。

#### QiitaCLI＋Cronを使う
※Windowsでもできます。

https://qiita.com/t1k2a/items/d219514e7ddab821fe5b

https://qiita.com/nomurasan/items/dba72d1ec1d194b74a33

これらを組み合わせる方法です。
なお、WindowsユーザーでもWSLが使えるならそちらでやっても良いです。

要は、予約投稿したい記事をいつ投稿するか日付管理しておき（日付管理のルールは任意で作りましょう）投稿予定日を判別しながらpublicフォルダに移動して `npx qiita push` するようにしておくだけです。コンフリクトが起こると面倒なので、 `npx qiita pull` も同時に実施できると良いでしょう。

### 4. 【投稿管理】投稿が確実にされたことを確認する
QiitaCLIが使えるなら `npx qiita pull` の結果を追いかければ良いです。全ての記事から当日ないし前日の投稿を探して、見つかればOKフラグを立てるようにテストプログラムを書けば確認の手間すら省けます。

#### QiitaCLIは投稿キャンペーンに対応できない
Webエディタを使えば投稿した直後に投稿ページに飛んで内容が確認できるため、投稿方法によってはCLIを使うより素直にWebエディタを使う方が楽かもしれません。
特にキャンペーン情報はQiitaCLIからは設定できないため、どうしても投稿キャンペーンとの紐付けはWebエディタを使用する前提になってしまいます。

色々考えると、毎週一回はQiitaの投稿画面を開いて記事をコピペした方が（期日忘れのリスクはあれど）楽な気がしてきます。

## このやり方でもなんとなく続いてます
お察しかと思いますが、本稿も記事を書いている日と投稿日はズレるはずです。
というかズレます。
作成日と投稿日のズレがイコールストックの量と考えることもできますが、重要なのはそこじゃない。
ちゃんと目的やいくつかの運用上で対処可能な気付きを作って習慣化すれば続くよ！という事が言いたい事でした。システム屋としては「なんでそんなリスクを背負ってやってるの？」と思わなくもないのですが、業務ではなく個人目標なので時間と目的がブレなければ色々やっていいと思うんですね。
ということで、仕組みを考える事はやってみて、既に私はQiitaに投稿するという習慣がしっかり根付いているのでそこまでやらなくても出来るな、という確信のようなものを持っているのですが、なかなかアウトプットの習慣がつかないのであれば、本稿のやり方は一つの気付きにできそうな気がしました。

今まさに運用中であるため「この方法でうまくいきました！」と断言するのが難しいのですが、この方法でうまく行っているので大きくは外れないんじゃないかと思っています。
そろそろマークダウンに慣れてきた？Qiitaでアウトプットの質を高めるなら他にもできることはあるよ！

## 本稿は続き物です
https://qiita.com/nomurasan/items/1d1a54fcf7e3087b22f3

アウトプット時のマークダウン記法について、よりステップアップにフォーカスした内容です。

## バッジの獲得ではなく、アウトプットを目的にする場合
アウトプットするのが目的ならスケジュールに縛られる必要はなく、書きたいことや忘れてもいいことをいつでも忘れられるように細かい事を気にせず書き殴っておくのがいいと思います。
正直、記事を下書きにして寝かせる事ほど勿体無い事はないので、下書きで置いておくぐらいなら未完成でも公開しておくべき、という意見です。
なので、私に取ってはある意味「敗北宣言」として本稿を残しました。

## ステップアップ・マークダウンからMermaidへ
記事は書ける時に書く。特に勉強会の記事は後から振り返ってまとめるのが苦痛でしかないです。
勉強会（ハンズオンを含む）に参加し、その場で学んだ内容をまとめ、また普段から良質なナレッジにするためにマークダウンに慣れておくと良いです。
さらにステップアップするなら、Mermaid記法も書けるようにしておくと良いです。

https://qiita.com/Qiita/items/c07f3262d8f3b25f06c9

もっとしっかりしたUMLも書けるようになるとベスト！
このレベルまでいくならVSCodeかなぁ、QiitaのWebエディタだけでは完結が難しそうです。
対応されたらやっていきたいところ。

## チートシートを用意しておこう
私が好んで多用するのは、

:::note
これ。:::noteで書けます。Zennにも似たような書き方があります
:::

と注釈[^注釈]です。

[^注釈]: 【注釈】注釈は書きまくると分かりにくいので、注釈したい文字（注釈コメント）のような書き方をする方法を採用しがちです。あくまでQiitaオリジナルの書き方なので、Zennに移行したい場合がちょっと大変。

使えるものはなんでも使うべきですが、一般のマークダウン以外のオリジナル拡張マークダウン記法を積極的に使うのはプラットフォームを移行したい時に不便なので正直おすすめはしませんが、使いこなせると便利なので手放せなくなるんですよね。
先ほどのMermaidなりUMLなりはVSCode上でスクリーンショットもソースコードも残せるのでやりようはあります。QiitaもCLIを使うなら悪くはないですね。
QiitaCLIを使ってQiitaの記事をGitHubにバックアップすることもできます。

なお、チートシートというほど網羅できてはいないですが、どのように書くかの例を置いておきます。

https://qiita.com/nomurasan/items/3e6c9be9c5ea1578ec59

## 【コラム】QiitaCLIでQiitaの記事をバックアップする
長くなったので別記事にしました。

記事URL（QiitaCLIを使ってQiitaのWebエディタで書いた記事も丸ごとGitHubでバックアップ・管理したい）

ポイントだけ抜粋しますと、以下コマンドを実行できるCIを用意してデイリーバッチにすればいいです。

```
npx qiita pull
git add -A
git commit -m "qiitaバックアップ"
git push
```

これをGitHub Actionsに定期実行させればOK。

### 注釈
（リマインド・イベントレポート） エンジニアに“アウトプット”がなぜ重要なのか

## 本稿のセミナーイベント
https://type.jp/s/fair/e/

（URLが共通っぽいので変わるかも）

2024/10/12版です。
本を書いている人たちのトークセッション風でした。

## エンジニアにとってのアウトプットとは？
### アウトプットをはじめたきっかけとは？
- OSSが楽しい！

#### 筆者の話
なんだっけなぁ、元々エンジニアになる前からアウトプット（広報を目的としない個人活動）をやっていた事もあって、アウトプットに抵抗がなかった
その延長で同人活動の宣伝を書いてみたり、学習メモを外だししてマサカリもらいながら強くなっていったりしたのがあった。
最初に書いた記事もネクストアクションとかを全く考えない、そもそも読まれる想定もせずに発信をしていたオチのない日常ネタだった気がする
当時はブログもなかったので、いわゆるBBS（掲示板）をレンタルできるCGIサービス（今でいうSaaS）を使ってコミュニケーションをしていたのだが、よく考えたらこれが最初のアウトプットかもしれない。
この後にブログが出てきたので、古い話を考えるとブログの前の頃のアウトプットのイメージが強い

### なぜアウトプットをするのか？
誰かの役に立てばいいな、ぐらい（自分も誰かの記事に救われた部分があった）
マサカリが飛んでくるとやっぱり怖いので匿名から始めてみる

### フィードバックをもらうと？
記事内の間違いの指摘があったぐらい。思想などに火をつけるような過激なネタは扱ってない。
↑なるべく気を遣うようにしてる
が、出した本が燃えたりとか。納得できる指摘は対応するけど、やっかみは相手にしないようにした。

（筆者註：良いと思う人もいる。叩く人は読んでる？自分ならやれる？叩くのは楽だよね）
記事が炎上したら凹むよね→気になるけど、なるべく気にしない

### アウトプットをする意義
活動証明、自分のやっていることの説明が楽になるね。自分の課題を解決した話とかを書くと受け入れられがち
→Q. 人に見られることを気にするか？： A. 気にする（ウケを狙ったり）
書いた記事がバズるという環境を作るのが大事そう

視点がやや集客気味へ。

### アウトプットを通して得られるもの
成果を生み出す力。アウトプットとの関連性は？→問題解決スキル
問題解決スキルは、どれぐらいアウトプットすれば身につくか？→数打てば当たる、ということはない。丁寧な対応（内容）を書くべき
（筆者註：外向きにいいことを言っているが、おそらくその人や組織に紐づいたブランド力の要素は無視できないと思う。いい記事を書いてもみられなければバズらない）
アウトプットを通じて恩返しできた感。アウトプット量が多いと成長速度も早い（フィードバックを得られやすい）し、外部評価も高い
なお、評価がない、というフィードバックもある

なお、アウトプットをする事自体が目的になるのではなくて、思考を整理しながら書いた結果がアウトプットになる。
アウトプットのコツは「どんな課題があって、どんな解決方法を考えるか（筆者註：これはメモ書きを残すという視点かな）」を考えるのがよい

アウトプットを続けるなら月報的なものとか、Tipsとかがやりやすいか

### アウトプットの第一歩：ネクストアクション
アウトプットするものがない問題（ネタがない）

普段からアウトプットする人の「ネタがない」と、アウトプットしない人の「ネタがない」は意味が違うのでは？
同じような記事を量産する事に意味があるか、と考えがちだが、アウトプットをする事自体に意味があるので、ネタが被ることは問題ない
同じネタでも書き手やスキルが違うと書き味（オリジナリティ）が違うし、陳腐化したと思っていても継続的に発信され続ける

ニッチなネタ（誰も見てないよね）ほど書いていくべき。
ネタ＝目の前にある問題を解決する。たとえばなぜ転職フェアにきたのか？とか。現場に満足していないので変えようとしている意志の現れと考えることができる。
あるいは、目の前にある問題が何なのかわからない。これを言語化する方法としてアウトプット（簡単なものだと言葉・会話）がある

## 所感（実況）
登壇者がやりにくそう。登壇者モニターがないと大モニターに全員（登壇者を含む）が見ながら話す・聞くという環境はつらい。会場の雰囲気を見ながら話す内容を変えている場合は特に。
クソコード回！どっかの勉強会でハンズオンやって笑ったなぁ
アウトプットをやってない人が結構多いの驚いた、どうやって学習できたと自己判断されているのか気になる

聞いてみて、やっぱり立場とかは関係なく得られるものとか考え方って似通っているよね、感。
結論っぽく言えば「やらないよりやった方がいい」けど「やるなら意味のあることをしよう」がポイントになるだろうか。
トークセッションだったけど何気に面接っぽい印象。最初の質問なんでしたっけ？とか出てくるの。これ結構大事。
面接官も１問１答で質問できない事もあるので、うまいことフォローしてあげる必要もあるか

書いていて思ったけど、マーメイド使おう。使えない＝アウトプットが出てこないということは、インプットが足りないか噛み砕けてない・飲み込めていないか。

## いろいろなところでアウトプットの重要性を説かれている！
実はこの記事も供養のためアドベントカレンダー送りにしたものだが、公開を決めるちょっと前ぐらいに、別の環境でアウトプットの重要性を説いた勉強会があったばかりである。
アドベントカレンダーの時期が当時迫っていたから、という事もあるが、アウトプットがエンジニアを救い、また自分自身を助けるということで良いことしかないので、全員がアウトプットをしやすい環境を作ることもやはり我々に求められている事なのだろう、と再認識する機会になった。のだろうと、編集追記時点で感じている。