OmniAICreator/Qiita-1.07M huggingface dataset:
paizaラーニングレベルアップ問題集の「代入演算2」をやってみた。

paizaラーニングレベルアップ問題集の[代入演算2](https://paiza.jp/works/mondai/d_rank_level_up_problems/d_rank_level_up_problems__accompanied_by_stdin_3)をやってみました。
- - -
###### 問題
https://paiza.jp/works/mondai/d_rank_level_up_problems/d_rank_level_up_problems__accompanied_by_stdin_3
- - -
###### C
```c
#include <stdio.h>

int main() {
	int a, b, c;
	scanf("%d %d %d", &a, &b, &c);
	int n = 0;
	n += a;
	n *= b;
	n %= c;
	printf("%d\n", n);
	return 0;
}
```
- - -
###### C++
```cpp
#include <iostream>
using namespace std;

int main() {
	int a, b, c;
	cin >> a >> b >> c;
	int n = 0;
	n += a;
	n *= b;
	n %= c;
	cout << n << endl;
	return 0;
}
```
- - -
###### C#
```cs
using System;

class Program
{
	public static void Main()
	{
		int[] abc = Array.ConvertAll(Console.ReadLine().Split(), int.Parse);
		int n = 0;
		n += abc[0];
		n *= abc[1];
		n %= abc[2];
		Console.WriteLine(n);
	}
}
```
- - -
###### Go
```go
package main
import "fmt"

func main() {
	var a, b, c int
	fmt.Scanf("%d %d %d", &a, &b, &c)
	n := 0
	n += a
	n *= b
	n %= c
	fmt.Println(n)
}
```
- - -
###### Java
```java
import java.util.*;

public class Main {
	public static void main(String[] args) {
		Scanner sc = new Scanner(System.in);
		int n = 0;
		n += sc.nextInt();
		n *= sc.nextInt();
		n %= sc.nextInt();
		System.out.println(n);
		sc.close();
	}
}
```
- - -
###### JavaScript
```js
const [a, b, c] = require("fs").readFileSync("/dev/stdin", "utf8").trim().split(' ').map(Number);
let n = 0;
n += a;
n *= b;
n %= c;
console.log(n);
```
- - -
###### Kotlin
```kotlin
import java.util.*

fun main() {
	val sc = Scanner(System.`in`)
	var n = 0
	n += sc.nextInt()
	n *= sc.nextInt()
	n %= sc.nextInt()
	println(n)
	sc.close()
}
```
- - -
###### PHP
```php
<?php
	[$a, $b, $c] = explode(" ", trim(fgets(STDIN)));
	$n = 0;
	$n += $a;
	$n *= $b;
	$n %= $c;
	echo $n, PHP_EOL;
?>
```
- - -
###### Perl
```pl
my ($a, $b, $c) = map { int($_) } split ' ', <STDIN>;
my $n = 0;
$n += $a;
$n *= $b;
$n %= $c;
print "$n$/";
```
- - -
###### Python3
```py
a, b, c = map(int, input().split())
n = 0
n += a
n *= b
n %= c
print(n)
```
- - -
###### Ruby
```rb
a, b, c = gets.split.map(&:to_i)
n = 0
n += a
n *= b
n %= c
p n
```
- - -
###### Scala
```scala
import scala.io.StdIn._

object Main extends App{
	val Array(a, b, c) = readLine().split(' ').map(_.toInt)
	var n = 0
	n += a
	n *= b
	n %= c
	println(n)
}
```
- - -
###### Swift
```swift
let abc = readLine()!.split(separator: " ").map { Int($0)! }
var n = 0
n += abc[0]
n *= abc[1]
n %= abc[2]
print(n)
```
【中古PC冒険記】第1回：1万円のデスクトップを買ったら電源が死んでた話

こんにちは。べんと申します。

家にLinux環境がほしいなぁと、年末中古ショップをふらついていたところ、とてもお手頃なマシンを見つけました。いろいろトラブルに遭いつつも、ようやく開発環境として最低限の働きをしてくれるようになったので、これまでの苦労話を残しておこうと思います。


### 1万円の高コスパ中古PCとの出会い
2024年12月、年末商戦が落ち着いた頃、偶然立ち寄った中古パソコンショップで、1万円のデスクトップPCを見つけました。スペックは以下のとおりです。

- CPU: Intel core i5-6400
- メモリ: 8GB
- GPU: GeForce GTX950

もともと、[Dify](https://github.com/langgenius/dify)がオンプレで動けばいいスペック、くらいに思っていたので、GPUまで付いてこの値段はお得だと思い、即購入。


### 電源が入らないトラブル

いい買い物をしてとてもいい気分で帰宅後、電源ケーブルを接続してスイッチを入れましたが、反応がありません（うすうす感づいてはいた）。ファンも回らず。

まず、電源まわりが原因だろうと思い、電源ケーブルを交換してみるもダメ。次は電源ユニットかと思いつつ、パーツを一つずつ購入していては安く購入した意味がないとも思う。結局、切り分けの方法がわからず、自作PCのプロである知人に助けを求めることに。


### 電源ユニットの交換で解決

テスターを使って電源が動作しているかを確認するも、よくわからず。知人がもっていた予備の電源ユニットと交換したところ、無事に動作。どうやらこのPCはソフマップのバーガーパソコンというものらしい。

トラブルはあったものの、自分でパーツ交換をしたこともなかったので、1万円でこの経験を込みで手に入れたと考えると、妥当な線と思います。


### 今回のポイント

**ジャンク品じゃなくても不具合はある**
「起動チェック済」とされていても、ショップが把握しきれない不具合がある場合もある（電源がつかないのも気づかないことがある？）。

**疑いのあるパーツはとりあえず取り替えてみるのが早い**
予備のパーツをもっていることは少ないと思いますが、知人などを頼り、とりあえず変えて動作するか確認するのが早いです。


---
以上、今回は中古PCとの出会いからとりあえず起動するところまでを共有させていただきました。中古PCの購入を検討されている方の参考になれば幸いです。

べん
ワイヤレスキーボードEWINのファンクションキーがMacで正しく動作しないときの対処

# Macでワイヤレスキーボードのファンクションキーが機能しない時の対処
MacBookProとWindowsパソコン両方で使える①テンキー，②パッドの付いたワイヤレスキーボードを購入しました． **EWIN EW-K19202**
![EWINワイヤレスキーボードEW-〜 19202.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1979979/1ce983b0-b5c2-1d0f-2385-2c8297482b30.jpeg)
Fnキー＋Ａ／Ｓ／Ｄ同時押しによって，３つのコンピュータとのBluetooth接続を切り替えることができる．

でも困ったことがあります．
Macで何らかの資料を作成（LibreOfficeなどのアプリで）している時に，F2キーでテキスト挿入できるはずが，　Spotlight検索ダイアログボックスが開いてしまう現象が起きてしまうことです．
つまりワイヤレスキーボードのファンクションキー（F1〜F12）が正しく認識されていない．

Macでファンクションキー（F1〜F12）を正しく動作させるためのシステム設定方法を記しておきます．

![ファンクションキーが使えない時の設定①.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1979979/36598e87-f671-98c8-ce06-bf61ea6ae5b2.jpeg)

![ファンクションキーが使えない時の設定②.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1979979/2c63b3ee-b2b5-560b-5e30-2a0651117cdd.jpeg)

**F1, F2などのキーを標準のファンクションキーとして使用のチェックがオフになっている．
これをオンにすれば，ファンクションキーが正常に動作する．**
読書感想文「巨人の星」

# 書籍名「巨人の星」
著：梶原一騎　川崎のぼる

週刊少年マガジンコミックス
Kindle版
全19巻

# 読もうと思った動機
梶原一騎作品に興味を持ち始めたため

あしたのジョーは既読済み

読書前はクリボッチの回と、ちゃぶ台返しと重いコンダラ程度の知識


# 印象に残った部分
たまに見返したいシーンが多いので、記録に残しておきますー


## 11巻　契約更改
オズマ「オレハ野球以外ノ夢ヲ抱イタコトガナイ　オマエハ？」
オズマ「特ロボット同士ノ性能比ベニハナ！」

・オズマと飛雄馬の会話が印象的でしたね
・オズマから自分と同類のや野球ロボットと告げられたのにショック受けてたのが良かった
・実姉からも似てると言われる始末
・飛雄馬がディスコで踊ってるときも楽しめずに　こんなものが青春か？と自身に問いかけているのもポイント高いですね。

この回から面白くなってきましたね！


## 13巻　男の友情
一徹「人間が人間に頭を下げることはない。しかし仕事に頭を下げい、徹底的にすべてを捧げ尽くせ」


一徹とオズマが打倒飛雄馬のためにトレーニングを初めた場面ですね。
シンプルに良い言葉だからメモっとこう
ここでのやり取り大好きなんだが、NGワードも多いから、全部は転記できんけれども。

## 14巻　奇跡の新魔球
一徹「オズマよ！お前は運動神経にかけては天才じゃが　なんともはやオツムのほうは可愛そうなほど単純じゃのう」
一徹「単純でも一見馬鹿げたことでも、自分になりに精一杯追求してみる試みることが次の段階への踏み台になる！！」
明子「お父さん…やっぱり、時々いいことをいうわ」

一徹とオズマが一緒に大リーグボールの謎を解明してる時の場面です。
オズマなりに大リーグボールを解明したのですが、一徹はそれ一蹴してからのフォローを入れているセリフですね。

部分的に良いこと言ってるとメモっておきます。

明子の「時々」いいことをいうわ　はちょっと面白いと思いました。

## 15巻　判のトレード
一徹「振り向くな。見る前に飛べ。ただ前進と問あるのみ。それが青春じゃよ」

オズマが帰国したので、代わりに判を引き抜こうとする一徹
高校時代に伴と飛雄馬をくっつけた一徹が、今度はその逆をするという…
一徹の恐ろしさを再認識した回でしたね


## 16巻 刺客志願
判「◯人に消える魔球を打ち込ませるくらいならこの俺が…うぐぐぐ」
判「伴宙太が刺客となってこの手で星にトドメを刺しますわい！！」



## 17巻　ふりかかる火の粉
飛雄馬「左門さんのような立派な男が間違っても頭を下げる相手ではない！俺が許さん」

左門がスケバンたちに痴漢冤罪で脅迫されている中、飛雄馬が左門を庇っている場面ですね。
自分を見失っている中で強敵（とも）のために戦う姿は素敵ですね。
飛雄馬は良い人間性してますね！！
（あの一徹からなんで　こんな良い奴が生まれるんだ？？？）





# 実践できること or 感想
## 感想
・今読んでも自分は楽しめました。普通に名作ですね。
　絵は時代を感じるがそれは大して重要ではないです。

・一徹が中日コーチに就任してから以降の展開が好きですね。
　
・アームストロングオズマと判が好きなキャラですね。
　アームストロングオズマは飛雄馬と生い立ちで似ていて、同族嫌悪感で戦っているのが良かった。
　判は高校来の友人で大リーグボールの頼もしい協力者だったが、終盤では大リーグボールに挑む刺客として役割が変わる。
　２者との戦いは　一徹との代理戦争の側面もあるから　そこもポイント高い　
　多分巨人の星は一徹と飛雄馬の親子の物語なんだろうな


・巨人の星に近づくための努力を続けた結果、親しい者が離れて行く展開は中々酷ですね。
　鬱展開の漫画だと思いました。

・一徹の心理状態がよくわからんですね。特中日コーチに就いてからの行動が全く読めない。
　判を引き抜いて　飛雄馬にけしかけるのは流石にひどいなと思いました。これはいけない。
　行動の読めなさはあしたのジョーの白木葉子を思い出しましたね。

・作品通して　”青春”って単語が多用されているのも気になりました。

## 実践できること
・あしたのジョーの読書感想文を書く
・本「梶原一騎の作品世界　残された謎」を読む
「エラー即時解決社会」エラーの世界標準フォーマットがほしい

(ポエム)

# 世の中のエラーを統一フォーマットにしてエラーをすぐにAIが理解して解決する世界は可能か？ エラーのMIDI化

## **エラーの統一フォーマット化とAIによる即時解決の可能性**  
「エラーのMIDI化」、つまり、**どんなシステム・言語・環境のエラーも統一されたフォーマットで表現し、AIが即座に理解 & 解決できるようにする**

## **実現可能性**
実はすでに「エラーの標準化」に近い試みはいくつかある：
- **HTTPステータスコード（4xx, 5xx）** → Webのエラーはある程度統一されている。
- **POSIXエラーコード（errno）** → UNIX系のエラーコードは統一されている。
- **WindowsのHRESULT** → COMのエラーコードは一応統一されている。
- **セグフォ（SIGSEGV）やSIGKILLなどのシグナル** → OSレベルでのエラー分類。

ただ、これらは部分的に統一されているだけで、  
- **プログラミング言語ごとにエラーがバラバラ**
- **アプリケーションによってログフォーマットが違う**
- **エラーメッセージが自然言語（英語・日本語・中国語など）で書かれている**

という問題がある。

## **「エラーのMIDI化（統一フォーマット化）」のアプローチ**
「MIDI」的にエラーを統一するなら、以下のような方法が考えられる。

1. **ユニバーサルエラーコード（UEC: Universal Error Code）**
   - すべてのエラーに**グローバルなエラーIDを付与**（例: `UEC-0001` は「ネットワークタイムアウト」）。
   - どのプログラミング言語やシステムでもこのコードを共通で使用。

2. **エラーの構造化データ化**
   - JSONやProtobufで統一的なフォーマットを作る。
   - 例：
     ```json
     {
       "uec_code": "UEC-0001",
       "message": "Network timeout",
       "details": {
         "http_status": 408,
         "retry_after": 30
       },
       "context": {
         "language": "Python",
         "framework": "Django",
         "file": "views.py",
         "line": 42
       }
     }
     ```
   - こうすれば、どんな環境でも統一的に解析可能。

3. **エラーの分類 & 音楽的MIDI化**
   - エラーを **「原因」「影響範囲」「推奨解決策」** で分類する。
   - MIDIのノート番号みたいに、特定の「エラーパターン」にIDを振る（例: `E1001: メモリ不足`, `E2003: DB接続失敗`）。
   - **エラーの「階層構造」も定義**（例: `E2003` は `E2000: データベースエラー` の一部）。

4. **AIによるリアルタイム解決**
   - エラーコードと対応策を機械可読にし、AIが自動で修正する。
   - 例えば：
     - `UEC-1003: NullPointerException` → 「適切なnullチェックを追加」
     - `UEC-2003: データベース接続失敗` → 「リトライ処理を追加 & タイムアウトを調整」
   - つまり、**エラーをAIが即時に解決可能なパターンに落とし込む**。

5. **エラー解決の「MIDIシーケンサー」**
   - 各エラーの発生・解決プロセスを**時系列で記録**し、再現可能な「修正パターン」を構築。
   - 例えば、エラーの「発生 → 検出 → 修正 → 検証」を、MIDIのノート情報のようにログ化。
   - これにより、「このエラーの最適解決手順」がAIで学習されていく。

## **メリット**
- **あらゆるプログラミング言語・フレームワークで統一的にエラーを扱える。**
- **AIが即座にエラーを理解し、適切な修正を提案 or 自動修正できる。**
- **エラーの修正履歴が蓄積され、どんどん最適化される。**
- **エラー対応の「音楽的シーケンス」が作られ、問題解決が加速。**

## **課題**
- **エラーのMIDIフォーマットを世界標準にするのが難しい。**
  - 業界全体で統一規格を作る必要がある（ISOとか？）。
- **「意味のあるエラーコード」にするための整理が必要。**
  - `E3001: Something went wrong` みたいな雑な定義では意味がない。
- **AIがエラー修正を100%自動化するのは難しい。**
  - コード修正の文脈によっては、人間の判断が必要な場合もある。

## **未来の展望**
「エラーのMIDI化」が実現すれば、こんな世界が来る：

1. **エラー即時解決社会**
   - 「エラーを見て悩む」ことがなくなる。
   - 「E1023だな、AIが勝手に直してくれる」みたいな感じ。

2. **AIスタンドとの協力**
   - AIスタンドが「エラーのコード進行（シーケンス）」を学習し、最適な修正を即座に実行。
   - まるで音楽のように、エラーと修正のパターンが流れる。

3. **「バグ修正」ではなく「創造」に集中できる世界**
   - 人間は「エラー解決」ではなく、「新しい機能を考えること」に集中できる。

## **結論**

エラーのMIDI化、やる価値はある。  

**「エラーの世界共通フォーマット化 + AI修正」** が進めば、バグ修正の手間はほぼゼロになる未来が来る。
【Jest】JestのテストがVSCodeのテストエクスプローラーに表示されない


## 忙しい方のためへ 1 行で結論

VSCode に入れている Jest の拡張機能を再起動する。

## 発生状況

プロジェクトの環境構築の一巻でフロントエンドのテスト環境を Jest で構築していました。 以前にも構築したことがあり、VSCode には一式の拡張機能が入っている状態です。

必要なライブラリーをインストールして確認用の簡単なテストを記述ししてコマンドライン上で問題ないことを確認しました。その状態でテストエクスプローラーを開いて見たところ表示されませんでした。

## 解決までの道のり

設定ファイルやインストールしているライブラリを確認してみたのですが問題なくかなり動揺しました。

ひとまず一縷の望みをかけて Jest の拡張機能を一度無効化して再起動したところ正常に表示されるようになりました。

## おわりに

解決法自体はありふれた物ですが、解決までにちょっと時間がかかってしまったため他の方のために記事として残します。

この記事が皆様のコーディングライフの助けになれば幸いです。
ヒヤリハット体験：CloudWatchの課金額増加の原因はLambda関数の再試行だったので、体系的にまとめてみました

## はじめに
AWS Lambda関数は、処理が失敗した際に **自動的に再試行（再起問い合わせ）** される場合があります。

:::note info
**この再試行の仕組みは、Lambdaをどのイベントソースから実行するかによって異なります。**
:::

今回の問題をきっかけに、Lambda関数の再試行について体系的に整理する必要があると感じたため、この記事でまとめていきます。

## 困っていたこと
今月は特にAWSを使用する作業をしていなかったのですが、気づいたら **CloudWatchの課金額が増えている** ことが判明しました。

![Screenshot 2025-02-04 at 5.39.39.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3662571/a0f22224-08bf-1e26-62f3-584f0b1d6523.png)

調査したところ、現在Lambda関数が常にエラーを発生しており、そのたびにCloudWatchLogsにログが記録され、課金が発生していることがわかりました。

![Screenshot 2025-02-04 at 5.13.44.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3662571/f3d60fe5-faf5-4cee-aff0-3c9e9a3d1962.png)

原因を特定したところ、DatadogとAWSアカウントのインテグレーション連携時に作成したLambda関数が、バックグラウンドで70回以上実行されていることが確認できました。

![Screenshot 2025-02-04 at 5.17.08.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3662571/30fc1cff-d00a-b3dd-74f1-570adebcfa39.png)

今回はこの失敗を機に、Lambda関数の再試行の仕組みを正しく理解する必要があると感じたため、記事としてまとめていきます。

## Lambda関数の再起問い合わせ（再試行）について

AWS Lambdaでは、関数の実行が失敗した際に 自動的に再試行（再起問い合わせ） が行われることがあります。

![Screenshot 2025-02-04 at 5.35.56.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3662571/328fa852-21ff-a4c6-ffdc-f3d025c5e2c1.png)
引用画像：https://dev.classmethod.jp/articles/detecting-and-stopping-recursive-loops-in-aws-lambda-functions/

再試行の回数や動作は、Lambda関数の実行方法（同期・非同期・ストリームベース・SQS）によって異なります。

## Lambdaの再試行（再起問い合わせ）が発生するケース

Lambdaは、主に以下のイベントソースからトリガーされる場合に再試行されます。

**同期実行（Synchronous Invocation）**
- **対象:** API Gateway、AWS SDK、CLI など
- **動作:** 
  - 失敗しても自動的に再試行されない
  - 呼び出し元（クライアントやAPI Gatewayなど）がエラーを受け取り、手動で再試行する必要がある

**対策**
- エラー処理をLambda関数内に実装する（例：エラーハンドリングやリトライ処理）
- API Gateway側で再試行ロジックを追加する

**非同期実行（Asynchronous Invocation）**
- **対象:** SNS、S3、EventBridge など
- **動作:** 
  - 最大2回まで自動再試行
  - 失敗すると1分後に1回目の再試行、さらに2分後に2回目の再試行
  - 3回失敗するとDead Letter Queue（DLQ）やLambdaのエラーメトリクスに記録

**対策**
- エラー処理をLambda関数内に実装する
- DLQを設定し、エラー発生時の対応を明確にする

**イベントストリーム（Kinesis, DynamoDB Streams）**
- **対象:** Kinesis Data Streams、DynamoDB Streams
- **動作:** 
  - 処理が失敗すると、一定の間隔で最大2回の再試行
  - それでも失敗すると、データのシャードが停止し、新しいデータも処理されなくなる

**対策**
- エラーハンドリングを強化し、リトライ可能なエラーとそうでないエラーを区別
- データをDLQやS3に保存し、失敗したデータを後から再処理できるようにする

**SQS（Amazon Simple Queue Service）**
- **対象:** SQSキュー
- **動作:** 
  - メッセージの処理が失敗すると、自動的に再試行
  - 既定の可視性タイムアウト（visibility timeout）が経過すると、再びメッセージがLambdaに渡される
  - 最大回数を超えると、DLQ（Dead Letter Queue）へ移動

**対策**
- SQSの最大受信回数（MaxReceiveCount）を適切に設定
- Lambdaの実行時間を調整し、タイムアウトを防ぐ
- DLQを設定し、失敗したメッセージを確認する

Lambdaの処理が失敗すると、イベントソースごとに異なる再試行ルールが適用されます。  

適切なエラーハンドリングとDLQの設定を行い、信頼性の高いシステムを構築しましょう。

## 今回の一時回避策
私の環境では、今回AWSアカウントとDatadogという海外のクラウドに特化したサードパーティ製品を紐付けるために、このLambda関数を作成していました。

しかしながら、現状設定がうまくいっていないこともあり、一度Lambda関数自体を削除し、不要なCloudWatchLogsも削除することで課金を抑えることにしました。

## まとめ
今回は、私自身も原因調査をする中で初めて遭遇する事象だったため、正直焦りました。***しかしながら、早期に発見できたことで、大幅なコスト増加を防ぐことができました。***

:::note warn
**やはりこのような仕組みを事前に理解しておくことの重要性を改めて実感しました。**
:::

今回の失敗談が、誰かのコスト削減の支えになれば幸いです。
はじめまして。Hello,World!Qiita

はじめまして、こんにちは。

借金プログラマーとして名を馳せたいSue103というものです。

複利的に借金が増えるのならば、複利的に学習するのみ。
ということ掲げ、Qiitaに投稿してみました。

GitHubと使い勝手的に迷っていますが、使ってみてという感じですが、御指南を下されば幸いです。

2024年12月から2か月ほどプログラミングの学んだことややっていることを日記、blog的に書いていけたらなぁと思ってます。

学ぶこと好きです。ある程度、人と話したり、交流するのも好きなので、好きなだけ絡んでください。
ポートフォワーディングの設定（TeraTerm）

## はじめに
こんにちは。こんばんは。長谷川と申します。
今回は現場で使用しているTeraTermを使用したポートフォワーディングの設定について
備忘も兼ねて記載します。

## TeraTermとは
自分のPCからリモートのホストへSSH接続などする際に使用するターミナルツールです。
↓画面はこんな感じ。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3780649/884c35b2-72d7-0f8d-7d30-733e3f65e389.png)

## ポートフォワーディングとは
ある特定のポートにアクセスされた場合に設定されたホストのポートに転送することです。
参考：https://ja.wikipedia.org/wiki/%E3%83%9D%E3%83%BC%E3%83%88%E8%BB%A2%E9%80%81

開発の現場においては踏み台やリレー機と呼ばれる中継専用のホストから目当てのサーバーにアクセスすることが多いです。
その時にいちいち踏み台にアクセスして、目当てのサーバーにSSH接続してとやるのはめんどくさい！！

そんな時、予めポートフォワーディングの設定をしておけば、起動しておくTeraTermのウィンドウは1つであとは設定に合わせてlocahost接続すれば目当てのサーバーにアクセスできます！！

それではTeraTermの設定方法を見ていきましょう。

### １．Setupメニューから「SSH Forwarding...」を選択
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3780649/8419dd89-69c7-9070-c4e7-6f2f5b741778.png)

### ２．Addボタンを押下
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3780649/5684614c-4ed5-0ba1-7b26-659f6e4d6e60.png)

### ３．必要な設定をしてOKボタンを押下
図ではlocalhostのポート13389にアクセスすることで、192.168.0.239:3389に転送する設定となっています。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3780649/81893e40-024e-c6d1-ed54-42fb01c250cf.png)

### ４．Setupメニューから「Save setup...」を選択し保存
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3780649/c26ee89a-6191-70b6-979c-f5dc8b9a0c72.png)

:::note warn
ここで設定を保存しておかないと次回TeraTerm起動時に設定は消えます！！
デフォルトの設定ファイルに上書きすることで次回起動時に自動で読み込まれます。
別のファイルとして保存して次回起動してから読み込むことも出来ます。
:::

## 終わりに
一度設定してしまえば踏み台サーバーに1回接続するだけで複数のサーバーにポートフォワーディングで接続できるようになります。ウィンドウも少なく済みますし、手間も少なくなります。結果的に画面上がすっきりして誤操作もしづらくなると思います。機会があればぜひ。

以上、長谷川でした。
スライド生成AI Gammaを使ってみた

こんにちは。
東です。

今回はスライドを作ってくれるAI「Gamma」を使ってみました。
仕事の成果物発表がかなり楽になったので、記事にてやり方をまとめてみました。
良ければ最後までご覧ください。

# Gammaとは？
Gammaは主にプレゼンテーション用の資料を __ドキュメント__ からビジュアル的に作成してくれます。
パワポのような __スライド__ はもちろん、 __ウェブページ__ や Word文章のような校正のしっかりした __ドキュメント__ にしてくれる便利なAIです。
プランは以下のように3つ用意されていてました。


| プラン名 | 値段 | 使用可能範囲 |
|:-|:-|:-|
|Free|$0／月（無料）|・400クレジット（生成に必要なコインのようなもの）がもらえる。<br>・様々な媒体にエクスポートできる（下部にGammaのロゴ付き）。<br>・スライド数は最大10まで。|
|Plus|$10／月（約1500円ほど）|・追加の400クレジット（生成に必要なコインのようなもの）がもらえる。<br>・ロゴなしのエクスポート<br>・スライド数は最大20まで増加。<br>・AI画像の精度が向上|
|Pro|$20／月（約3000円ほど）|・クレジット無しで無限に生成が可能。<br>・スライド数は最大50まで<br>・AIの精度 及び生成物に対しての細かい分析も可能|

今回は1番ライトなFreeプランを利用しました。
登録だけで（クレジットカードは必要）基本機能利用できるので、是非。

# スライドの作成方法

今回はスライドをpptxファイルとして発表したので、そちらの作成手順を軽く紹介します。

### 1,発表内容が記載されているドキュメントを用意する
今回は同じくQiitaの下書きされているマークダウンの文章を拝借しました。

参考元の記事も是非！
[生成AIを活用した作業効率化](https://qiita.com/pesysyon/items/35b36de408553fd78b91)

![Gamma操作履歴1.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3780649/2da0b1d3-6864-c7cc-2d42-f3b947f73545.png)

### 2,Gammaのホーム画面で「新規作成」
AIに任せるには「新規作成」ボタンだけでできるのですが、他にも生成の種類があるみたいですね。
1,__新規作成__ （今回はこれ！）→プロンプトや命令、ファイルやURLを基に新規作成できる。
2,__空白のGammaから新規作成__ →Gammaのレイアウト機能を使いながら1から自分で作る機能。
3,__インポート__ →PDFやWord、Googleドキュメントなどファイルを読み込ませる方法。

極めれば、文字の配置などレイアウトの工夫はしがいあるのでこれでスライドをつくるのも良いですね。

![Gamma操作履歴2 - コピー.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3780649/b5dd940f-45a8-0449-085f-8b82d4828185.png)
### 3,作成方法を選択
AIで作成する画面は見ての通りとてもシンプルでした。
今回は「テキストを貼り付ける」機能である程度ある文章から作成しました。

![Gamma操作履歴3.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3780649/a6fedfaf-9da0-6d46-2081-5bb93e53c6a6.png)

### 4,プロンプトとなる文章を貼り付け
本当にやることは単純で、Qiitaの下書きの文章をコピペで貼り付けただけです。
普通の機械であればなんのこっちゃの形式だと思いますが、Gammaはそこを上手く汲み取ってくれるみたい。
この時点で様々な設定ができます。
例としては
・1スライドの情報量の増減
・画像の典拠元（AI画像か、WEB上の画像か）
・スライド数（Gamma上では”カード”と呼称されるみたい）

などなど...
自分の作りたい目標に近づけていけます。

![Gamma操作履歴4.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3780649/f1345036-5d70-f602-83d8-5871cb6e01df.png)

### 5,デザインを選択

デザインは元々あるテンプレートがいっぱいあったので、そこから好きなものを選ぶだけ。
とても楽。

![Gamma操作履歴5.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3780649/5b7fe1c0-ff70-21ce-ec8b-46b478978498.png)

### 6,出力して完成！
これだけで楽にスライドができます。
文章は多少自動生成味があるので、発表前にはいくつか添削しました。
ただそんな直さなければいけない文章もなく、もとになったプロンプトがしっかりしていたおかげか生成してからの手直しはとても楽できました。（ありがとう！）

![Gamma操作履歴6 - コピー.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3780649/cbe8699b-f95b-ec4d-3195-9fc5dc509c82.png)

### 7,出力して完成！
あとはエクスポートするだけ！
PDF、pptx（パワポ）、PNGなどに対応しているようです。

![Gamma操作履歴7こぴー.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3780649/83e1b446-524c-29e4-95c7-bf447a60fe87.png)

# まとめ
今回の成果物は時間内でどこまでのものが作れるかという課題でもあったので、
十数分でここまでの情報量のスライドが作れて満足でした。
楽したい方、おしゃれなスライドを作りたい方！
Gamma、是非お試しあれ！
初めて参画するプロジェクトPM(PMO) 構築の工程

こんにちは、小磯と申します。
プロジェクトの中にいくつかの工程があります。
その中にある構築について纏めようと思います。
初めて業務を行うPM(PMO)の方へ参考になればと思います。

### 1.構築
構築は決められた基準をもとにプログラミング・テストをすることで質の高いシステムの提供が可能です。
工程における期限はシステムの規模感によって異なり、小規模のシステムなら3ヶ月程度を期日とすることも珍しくありません。
一方で大規模なシステムになれば、長期間1つの案件に着手することになるため、システムの規模に比例して各工程の期限を決めていくことが困難になります。
構築工程は他の（実装・プログラミング・製造・開発）呼び方もあります。


### 2.システム開発とシステム構築の違い
「開発」と「構築」では言葉の意味が異なります。
開発は新しいものを作り実用化することを指します。
システム開発はプログラムの設計と実際のプログラミング、完成したシステムのテスト作業までの一連の作業のことを指します。
構築はすでにあるモノ（材料や部品）を組み立て築き上げることを指します。


### 3.構築作業
内部設計でプログラミングの型が完成したら、それに基づきプログラミングを行います。
作成するシステムにより使用するプログラミング言語が異なるため、システムごとにプログラミング言語を使い分けます。
プログラミング言語は、作るシステムの種類や開発者のスキルに応じて使い分けるのが一般的です。
どの言語にも共通して言えるのは、誰が見てもわかるようにソースコードを整理しながら記述することが大切だということです。
システムは開発して終わりではなく、安定的な運用が求められます。
開発者しか理解できないソースコードの書き方でプログラミングしてしまうと、トラブルが発生した際に運用者の対応が遅れてしまう可能性があります。


### まとめ
構築工程は、基本設計や詳細設計で決めた仕様通りに動作させるために重要な工程です。
プログラマーやエンジニアのスキルレベルによりソースコードの作成方法が違いますので、コミュニケーションを密に取り修正し易さの認識を合わせていくとよいと思います。

他にもプロジェクトに関する記事を投稿しておりますのでお役に立てればと思います。
[プロジェクト ウォーターフォールとアジャイルの違い](https://qiita.com/pesysyon/items/e77b869b5c90b667680b)

[プロジェクト アジャイル開発の流れ（PMO）](https://qiita.com/pesysyon/items/81209de2a2fdc8c294d4)

[初めてプロジェクトに参画する方へプロジェクトとタスクの意味について](https://qiita.com/pesysyon/items/a7da021a7d596df5e5fd)

[初めて参画するプロジェクトPM(PMO) 要件定義の工程](https://qiita.com/pesysyon/items/cf40037f484b99e16621)

[初めて参画するプロジェクトPM(PMO) 基本設計の工程](https://qiita.com/pesysyon/items/c0b936f325244be7688d)

[初めて参画するプロジェクトPM(PMO) 詳細設計の工程](https://qiita.com/pesysyon/items/8e1182673b611414cb38)

[ChatGPTへ自分の認識や対応が間違っていないか相談してみた（PMO・リリース工程）](https://qiita.com/pesysyon/items/bd54d1f74390df7f2e04)


以上、小磯でした。
【🔰初心者】あれだよ、つかってみた 【Tool紹介】

## 対象

- 情シスの端くれ
- え？あーし？？？？
- あなたですよ。ふふふ

## なにするん
RSS管理 すごいらくちーん

## 何したん？
IFTTTの代替でつこーとよ。

※ これでは出禁 ※

---

## 解説編
大きく深呼吸 恋のから騒ぎ
それは違いますねぇ。

## 結局？
あれだよ、名前のわからないTool

## 《人類学》
ファンブル！！！！
メールチェック中。
PHPで「文字列リテラルを作成する」の動作を確認してみた。

# 概要

PHPで「文字列リテラルを作成する」の動作を確認してみました。
以下のページを参考にしました。

https://www.javadrive.jp/php/string/index1.html

# 実装

以下のファイルを作成しました。

```sample.php
<!DOCTYPE html>
<html lang="ja">
<head>
<meta charset="UTF-8">
<title>PHPテスト</title>
</head>
<body>

<p>
<?php echo "こんにちは<br>"; ?>
<?php echo 'お元気ですか？'; ?>
</p>

</body>
</html>
```

以下のコマンドを実行しました。

```
$ php sample.php 
<!DOCTYPE html>
<html lang="ja">
<head>
<meta charset="UTF-8">
<title>PHPテスト</title>
</head>
<body>

<p>
こんにちは<br>お元気ですか？</p>

</body>
</html>
```

# まとめ

何かの役に立てばと。
Tidy First?から学ぶ内部ドキュメントの書き方 #保守

## これは何?

長年保守しているソフトウェアの保守/開発を引き継いだのだが，背景やシステム全体を理解するのに苦労した。
そのため，自分は内部ドキュメントを積極的に作成すべきという思想を持っている。
だが，やみくもにドキュメントを書いてしまい，あちこちに情報が散らばってしまうとドキュメントが読まれない/更新されない/読み手を混乱させるという自体を招いてしまう。

本記事ではKent Bech氏の書籍Tidy First?にでてくるリファクタリングの考え方をドキュメント作成に応用することで，読者にドキュメント作成に前向きな気持ちになってもらうこと，よりよりドキュメントを書けるようになってもらうことの手助けができればと思っている。

https://www.oreilly.co.jp/books/9784814400911/

---

## そもそもドキュメントはいつ/どのくらい書くべきか?

この本を読む前の自分はエンジニア的な視点でしかリファクタリングを見れておらず，スパゲティコードを見つけたらすぐに修正したい衝動にかられていた。

しかし，Kent Beckはリファクタリングにコスト意識を持つこと，可能なら先にお金を稼いでそのお金でリファクタリングするほうが良いと述べている。

これはドキュメント作成においても同じであろう。

自分の場合はドキュメントを書く前に以下の2つを意識して，ドキュメントの粒度を決めるようにしている。

- 想定読者は誰か?
- 同様の作業を再度実施する可能性はどれくらいあるか?
- 自分が詰まったのはどこか?

また，リファクタリング同様，**最低限振り替えりができるだけのメモ**は当日のうちに作ってしまい，**整頓**は時間のある時に行う形にすると良い

---

## 伝えたい内容に合わせて適切なドキュメントの種類を選ぶ

ざっくり以下のようにわけて最低限のテンプレ例を示す

- 仕様書: ※内部ドキュメントではあまり仕様書を書くことはないのでテンプレは本記事では割愛する
- 単発の手順書
    - トラブルシューティング系
    - 作業手順書
- オンボーディング資料

### 手順書

#### トラブルシューティング系

- どんな事象が起きたのか: エラー文などあるなら書いておくと検索しやすくなるのでgood
- トラブルが起きた原因: 不明な場合には予想でもよいので書いておく
- 解決方法

#### 作業手順書

- なぜ、その作業を実施するのか、背景
- 事前準備: メンバーが共通で実施する環境構築手順以外でやることがあれば
- 作業の流れ: 以下は他の人も同じ轍を踏む可能性が高いのであれば書いておくことを推奨する
  - 人に聞かないとわからなかったこと
  - 勘違いしていたこと
  - うまくいかなかったこと

### オンボーディング系

以下を別々のドキュメントにわけて書いておくとよい

- どういうプロジェクトなのか: 使用言語、ライブラリ等
- 全体構成図など(あれば)
- 環境構築手順
- 最初に読むべきもののリンクなど

---

## 適切にドキュメントを配置する

※階層構造でドキュメントを配置する前提

自分は以下の順で評価してドキュメントをどこに配置するかを決めている

1. 特定の案件、リリース等に関連して複数のドキュメントを作成した場合は案件名、リリースバージョンなどでまとめておく(※よく使用する手順などが追加された場合には、抜き出すなりリンクを張るなりして対応する)
2. ドキュメントの種類でわける。
3. よく使うものはなるべく上位に配置する
4. 似た内容のものは同じディレクトリに集める

あくまでイメージだが、こういう感じ

```shell
オンボーディング資料
│   └── はじめに
│   └── 全体構成図
│   └── 環境構築
│   └── 最低限読むべきもののリンク集
│     
手順書
└── トラブルシューティング系
    ├── トラブル1
    ├── トラブル2
└── 作業手順書
    ├── よくある作業1
    ├── よくある作業2
    ├── あんまり使わないやつまとめ
過去リリース
└── リリースA
    ├── 事前準備
    ├── 要件定義
    ├── ハマりポイント
    ├──実装メモ
```
---

## 読みやすいドキュメントにするための工夫例

### 目次の粒度をそろえる

意識するだけしか現状思いつかないので説明は割愛

### 主語と目的語を明確に書く

×認証失敗した際に認証失敗カウントを増やす
〇ユーザが認証失敗した際にMySQLのUserテーブルのfailed_cntを+1する

### 記載内容の要約を見出しにする

```
## 環境構築

### リポジトリのクローン

### ライブラリのインストール
```

### 意図や説明コメントをいれる

プログラムのコメントを書く時と同じような観点でnoteやwarnなどを入れておくとよい

- なぜそれが必要かわかりにくい時
- なるほどと思った部分や、役に立ったリンクなど
- 自分が失敗したポイント、誤解していたこと等

---

## 後書

- 良く言われているように、読みやすいコードを書くことと読みやすいドキュメントを書くことは似ていると思う。より良いコードを書くためのトレーニングと思えば、多少抵抗感が減るかも
- 誰かから質問された時にリンク渡すだけで済めば、自分の本質的な業務に割ける時間が増やせる。(なんなら、ドキュメントな見つけやすい形に配置できていれば勝手に見つけてくれるかも)
- 自分も色々模索中なので一旦整理してみた。意見やアドバイス待ってます！
2025/2/4主にITとかセキュリティの記事

Windows 10サポート終了と新関税政策に備える：今こそWindows 11への移行を(2/2)
https://reinforz.co.jp/bizmedia/69430/

2024年に急増するランサムウェア脅威と情報システム部門の対策(2/1)
https://topics.smt.docomo.ne.jp/article/manegy/business/manegy-10883

Google Playストアでシステムアプリ更新が表示されない問題が継続中(2/2)
https://tech-gadget.reinforz.co.jp/16009

2025 年のルーター向けベスト VPN: 究極ガイド(1/31)
https://www.geeksforgeeks.org/best-vpns-for-routers/

派盾：2025年1月に28件の暗号ハッキング事件が発生し、総損失は8700万ドルを超えました。(2/1)
https://www.chaincatcher.com/ja/article/2165412

説明できる？「SMS」と「MMS」の違いとそれぞれの特徴(2/2)
https://dime.jp/genre/1900033/

【朗報】サムスン、ついに三つ折りスマホ投入か。Mate XTとは異なる「意外」な折り畳み方、20万台製造との報告(2/2)
https://smhn.info/202502-samsung-tri-fold-rumors

【イギリス】政府、「AIサイバーセキュリティ行動規範」発表。日本も人材連合ICCSWに加盟(2/2)
https://sustainablejapan.jp/2025/02/02/uk-ai-cyber-security-code-of-practice/110396

サイバー防御、何もしないリスク懸念　英監視機関トップ(2/2)
https://www.nikkei.com/article/DGXZQOCB302S60Q5A130C2000000/

【生成AI×営業支援】トップ営業マンになるための活用事例10選！(2/2)
https://weel.co.jp/media/sales/

報告書によると、若者は大手テクノロジー企業への信頼を失っている(2/1)
https://www.drivingeco.com/ja/informe-revela-adolescentes-han-perdido-confianza-grandes-empresas-tecnologicas/

防衛省サイバーセキュリティコンテスト2025が開催(2/2)
https://innovatopia.jp/cyber-security/cyber-security-news/47469/

電子機器による気晴らし：なぜ増えるのか、そして自分を守る方法(2/1)
https://ja.futuroprossimo.it/2025/02/distrazioni-elettroniche-perche-aumenteranno-e-come-salvarsi/

奈良県警が「サイバーセキュリティ競技会」　警官らが知識と技能競う(2/2)
https://www.nara-np.co.jp/news/20250202221225.html

経済データの改ざんをテレビで告白する共産党幹部【澁谷司──中国包囲網の現在地】(2/1)
https://the-liberty.com/article/21940/
区画モデルの基礎 ①

## 区画モデルとは
区画モデル (Compartmental models) は感染症が人や動物、その他生物の集団の中で伝播していく力学をモデル化するために用いられる一般的な数理モデルの総称である。

> 区画モデルは感染症モデリングの分野で最もよく使われているが、情報の伝播をモデリングするためにも使用することができる。

区画モデルでは、集団内の個体に対して感染状態に応じて「区画」と呼ばれるラベルを割り当てられる。例えば区画モデルの中でも最もシンプルなSIRモデルは個体を感受性保持者 (**S**usceptible)、感染性保持者 (**I**nfectious)、免疫保持者 (**R**ecovered) の3つの区画に分ける。SIRの他にSEIR、SIS、SVI等と様々なバージョンが存在する。

## SIRモデル
区画モデルの概念を理解するために、ここではSIRモデルに着目する。まず表記を定義する:

- $S$: 感受性保持者 (まだ感染したことがなくこれから感染し得る人) の人口 (単位: 人)
- $I$: 感染性保持者 (感染している人) の人口 (単位: 人)
- $R$: 免疫保持者 (感染した後に回復した人) の人口 (単位: 人)

### 仮定
モデルを簡略化させるために次の仮定をおく。まず、感染性保持者は一定の率 $\gamma$ で回復する=免疫保持者になる。また一般的にはある個体が感染してから他の固定を感染させる程の感染力を獲得するまで、しばらく時間を要するが、一旦時間のラグがないとする。さらに、人口動態、すなわち自然出生率と死亡率は無視する。

### 感染力 Force of infection
伝播プロセスへの理解を深めるため、各区画に所属する人口の変化を表現する常微分方程式系 (System of ordinary differential equations (ODEs)) を考える。感染性保持者が一人あたり感染させる感受性個体の割合は感染力 (force of infection) と呼ばれここでは $\lambda(I)$　と表記する。留意すべき点として、$\lambda(I)$ は定数ではなく感染性保持者の人口 $I$ の関数である。

$\lambda(I)$ は個人間の接触の性質に関する仮定に依存するため定義が厄介になることが多い。しかし、ここでは難しく考えすぎず、感染力を感染率 $\beta$ と感染性保持者の積としてモデリングできるとする。$N = S + I + R$ を総人口とすると、感染力は
$$
\lambda(I) = \beta \frac{I}{N}
$$
と書ける。するとSIRモデルの微分方程式系は次のように書くことができる:
$$
\frac{dS}{dt} = -\lambda(I)S, \quad \frac{dI}{dt} = \lambda(I)S - \gamma I, \quad \frac{dR}{dt} = \gamma I. 
$$

![SIR.drawio.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4001536/fc763e0a-f656-33a8-c220-731d5ff71e44.png)

着目すべき点として、我々は今人口が「閉じている」、すなわち総人口 ($N=S+I+R$) は時間と共に変化しない ($dN_dt = 0$) と仮定していることである。このように仮定する利点は、系が三つの方程式ではなく二つの方程式で決定されることである。例えば免疫保持者の人口は $R = N - S - I$ であるため、感受性保持者人口と感染性保持者人口を求めればよい。

次回は人口動態も考慮し、SIRモデルの解析について学んでいく。

## 参考文献
1. Julie C. Blackwood & Lauren M. Childs (2018) An introduction to compartmental modeling for the budding infectious disease modeler, Letters in Biomathematics, 5:1, 195-221, DOI: 10.1080/23737867.2018.1509026

[次の記事 >>](https://qiita.com/ShozenD/items/b089488cfe9e6a6788a8)
「ゲームで学ぶPython！Pyxelではじめるレトロゲームプログラミング」を、ゲームを作りたくてプログラミングをはじめた人・現役エンジニア・プログラミング講師の視点で紹介 

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/60052/fb5a4b9a-b300-7d7d-e2fe-d09f9339f8ff.png)

2025年1月27日発刊の書籍「ゲームで学ぶPython！Pyxelではじめるレトロゲームプログラミング」を、私「ゲームを作りたくてプログラミングをはじめた人」「現役エンジニア」「プログラミング講師」の視点で紹介します！
# 結論：オススメです！
- ゲームを作りたくてプログラミングをはじめたい人
- ゲームを作りたくてプログラミングをやってみたいと思った人
- ゲームを作りたくてプログラミングをやってみたけど、一度は挫折したけど、やっぱりやってみたい人
- ゲームを作りたくてプログラミング(Scratch)をはじめて、でもテキストプログラミングに踏み出せない人
- プログラミングの勉強・・・文法ばっかりでつまんない・・・おもしろくない・・・と思っている人

https://amzn.to/40LIW58

# ポイント1:常々「環境構築と黒い画面は経験しておこうよ。」と思っていたら、ちゃんと経験できるようになっていた。

- CHAPTER 1　プログラミングをはじめよう
- CHAPTER 2　プログラムを動かしてみよう

プログラミングに挑戦しよう！と一歩踏み出して、最初に挫折するポイントと言われるのが「開発環境の構築」ですが、Win/Mac両対応で書かれています。
そして、さらなる恐怖ポイント「黒い画面(コマンドプロンプト、ターミナル)」での操作もていねいに書かれています。

現代はネット上でプログラミング学習ができる環境が整っていますね。
パソコン操作に慣れていないキッズ向けのScratchなどのブロックプログラミングや、テキストプログラミングの初学者向けとして最適です。
一方で「ネット上の環境が整い過ぎている」弊害として、テキストプログラミングの初学者段階を終えたにも関わらず、ずっとWeb上のIDEで学習してしまい・・・いざ自分でアプリケーションを作ろうとした時に動作環境はおろか、プログラミング環境の作り方がわからない人も多いのではないでしょうか？

「自分で環境インストール、黒い画面に慣れておいて欲しい」という想いを抱いているのですが、いい感じで実現されていて、「お、いいね！」っと思いました！

# ポイント2: 常々「入門のところで”フレームワークウェイ”は必要ない。」と思っていたら、しっかり基礎だった。

- CHAPTER 3　お絵描きプログラムを作ろう
- CHAPTER 4　アニメーションを作ろう

初学者向けのプログラミング学習によくある「裏で暗黙のゲームループ」があったり、「実行や関数呼び出しを意識できない」のは、よろしくないと思っています。
お気軽に感じてもらいたいが故に意図的に意識しないようにされているのは理解できますが・・・いざ自分でアプリケーションを作った時に「いわゆるmain関数の存在を知らない」「勝手に何度もされるものと思っていた」なんて勘違いをしている人が多いのではないでしょうか？

でも、本書では、ちゃんと最初は「基礎」だけで構成されています。実行は「１回こっきり」「ループさせたきゃ、繰り返し」「画面の更新は、プログラムで意識して実施するもの」と。

**「手続き」としての関数**も「なぜ関数化するとよいのか？」と説明があり、何より「繰り返しや分岐より先に説明している」のが素晴らしいと思いました。
（関数を後回しに学習させる教材は多いですが、そもそも最初に習うprintとかの命令自体が関数ですもんね。）

**繰り返し**について、これはPythonのすごく良いところで「条件式不要で繰り返しを表現」できるので、シンプルに先に「繰り返し」を学べるようになっているのは良いですね。
（いわゆるC言語系の for文やwhile文が条件と結び付き過ぎているので、よく「繰り返し・分岐、どちらを先に学ぶべきなのか問題」が勃発しますよね・・・）
（思えば、自分が最初に学びはじめたBASICも FOR I = 0 TO 10 STEP 2 と条件を意識せずに書けるので、右も左もわからず、プログラミングをできる人が周りにいない独学環境でも悩むことがなかったのかも。）

そして、**条件分岐**。
「あれをするにも判断」「これをするにも判断」と、ここからグーっと「プログラムで操る」を実感していく流れになっていくのが、ここまでの基礎学習の流れとして、良いですね！

# ポイント3: 常々「入門って１ファイルに完結するように押し込め過ぎ・・・」と思っていたら、オブジェクト指向、モジュール分割まで、しっかりと。

- CHAPTER 5　ワンキーゲームを作ろう
- CHAPTER 6　シューティングゲームを作ろう
- CHAPTER 7　アクションゲームを作ろう

実践をしていくフェーズでは、よくあるゲーム作りの入門書は「ミニマムでできること」で終わっていることが多く、学んだ後に「いざ大きなゲームや作品を作ろう！」と思った時に頓挫することが多いですね。実は Pyxel 付属のサンプルも基本的に１ファイル完結でしたので、本書の内容はどうなるのだろう？と心配しておりました。
ですが、その心配は見事に払拭されました！

これだ！と思ったのは、**シーンの管理**の話まであったことですね。
技術面では、やはり現代においては**オブジェクト指向**に触れないわけにはいけませんが、しっかりとそこも解説があります。
そして、**複数ファイルでのプログラム構成**まで・・・ここまで解説されたものはなかなか見かけないんじゃないでしょうか。
ここまで書いていただけたら、ゲームを作り込めます！

# ポイント4: 常々「プログラムは使う人のことを想いながら作ろう。たくさん使ってもらおうよ。」と思っていたら、しっかり公開のことまで言及。

- CHAPTER 8　作ったゲームで遊んでもらおう

大事ですよね！
この辺りはWebの開発環境の方が公開の場・コミュニティも兼ねていることも多いですね。そこまでとは言わないですが、せっかく作ったものを公開することをきっちりお伝えいただいていて、いいですね！

# 最後に

キッズ向けプログラミング教室の教材として、本気で採用しようかと検討中です。
私は「ファミコンにハマり、ゲームを作りたくて兄のMSXで独学でプログラミングを学びはじめたけど、結局ゲーム会社さんに入るのは夢のことだと思い込んでしまって、フツーにシステム開発界隈に入ってしまった人間」なのですが、現代のキッズにそんな思いをさせたくなくて、夢を現実にできる手助けをしたい・・・

Pyxel はちょうど良いさじ加減のゲームフレームワークであり、そして本書はプログラミングの基礎＋それがしっかり伝わる「手元に置いておきたい一冊」だと感じています！

https://amzn.to/40LIW58

最後まで読んでくださり、ありがとうございました！
React + tailwindCSSで簡単にアコーディオン開閉アニメーションを実装

簡単なtailwindとJSでアコーディオンの開閉アニメーションの実装記事がなかなか見つからなかったので、自分なりに実装してみました。

## 実装

```React
const [isOpen, setIsOpen] = useState<boolean>(false);

return (
  <>
    <div onClick={() => setIsOpen(!isOpen)}>
      <p>タイトル</p>
    </div>
    
    <div className="grid duration-300 ease-in-out ${isOpen ? 'grid-rows-[1fr]' : 'grid-rows-[0fr]'}">
      <div className="overflow-hidden">
        <p>本文本文本文本文本文本文本文</p>
      </div>
    </div>
  </>
)
```

## 実装結果

GIF画像だとちょっと速く見えますが、実際はもうちょっとぬるっと開いて閉じます。

![ダウンロード.gif](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/952495/1b64d57a-c5d3-c646-d389-1f810e1163e9.gif)

durationの秒数を増やせば遅くなるし、減らせば速くなります。

https://tailwindcss.com/docs/transition-duration

## まとめ
アコーディオンの開閉アニメーションは、jQueryやjavascriptで高さを取得して...といった手法はやったことはあるけど、CSSだけで実装できるのは初めてでした。
tailwindは便利で好きだけど、アニメーションになってくるとどのクラスを適用したらいいのか自分は少し分かりづらい（苦手）かもと思いました。

## 参考記事
https://coliss.com/articles/build-websites/operation/css/css-transition-from-height-0-to-auto.html
【Git実践】mainブランチ以外からブランチを切る方法 - チームメンバーの開発ブランチをベースにする手順を解説

## はじめに

チーム開発において、他のメンバーが作成した開発ブランチをベースに新しい機能を開発するケースは珍しくありません。例えば、大規模な機能開発の途中で修正が必要になったり、休暇中のメンバーの作業を引き継いだりする場合です。

この記事では、`main`ブランチ以外から作業ブランチを作成する方法を、実践的な例を交えて解説します。

## 実践的なシナリオ

### 1. 大規模機能の分割開発
複数人で大規模な機能開発を行う場合、メインとなる機能ブランチ（例：`feature/hoge`）から各メンバーが作業ブランチを作成して開発を進めます。

### 2. 巻き取り作業のケース
チームメンバーが長期休暇中の場合や、急な修正が必要な場合に、既存の開発ブランチ（`feature/fuga`）から新しいブランチを作成して作業を進めます。

### 3. 並行開発での活用
現行バージョンとは別に、次期バージョンの開発を`feature/piyo`で進めているケース。この場合、新機能の追加は全て`feature/piyo`をベースに行います。

## 具体的な手順

### Step 1: 現在の状態を確認
まず、自分が現在どのブランチにいるかを確認します。
```bash
$ git branch
* fix/fuga
  main
```

### Step 2: リモートの最新状態を取得
他メンバーの変更を含む最新の状態を取得します。
```bash
$ git fetch origin
```

### Step 3: 開発ブランチの作成
他メンバーのブランチをベースに、新しい作業ブランチを作成します。
```bash
$ git checkout -b feature/hoge origin/feature/hoge
```

## 開発時の注意点

### ブランチの最新状態の維持
- 作業開始前に必ずベースブランチの最新状態を取得
- 定期的に`git pull`を実行して同期を維持

### コンフリクト対策
- 早めに最新化することでコンフリクトのリスクを軽減
- コンフリクトが発生した場合は、ベースブランチの開発者と相談

### コミュニケーション
- ベースブランチの担当者に作業内容を事前に共有
- 変更内容が大きい場合は、チーム全体に共有することを推奨

## まとめ

他メンバーのブランチをベースにした開発は、チーム開発では一般的な手法です。基本的なGitの操作は`main`ブランチからの派生と変わりませんが、以下の点に注意が必要です：

1. ベースブランチの最新状態を維持する
2. チーム内でのコミュニケーションを密に取る
3. コンフリクトに備えて早めの同期を心がける

## この手法が特に有効なケース

- 大規模な機能開発での分業
- チームメンバーの一時不在時の対応
- 並行開発における機能追加
- 段階的なリリースを計画している場合

## 参考資料

- [Git公式ドキュメント](https://git-scm.com/doc)
- [Pro Git Book](https://git-scm.com/book/ja/v2)
【React】文字列を配列に変換して一文字ずつ表示する方法

# 概要
React にて文字列を配列に変換して一文字ずつ表示する方法を紹介します。

# 背景
自社の忘年会に使うビンゴアプリを開発しています。
筆者は BE（TypeScript）、同期が FE（React）で分担してます。

FE のレビューをしていたら、ビンゴカードのヘッダーラベルを以下のような実装をしていました（同期は FE 初心者）
```jsx
export default function App() {
  const headerChars = ["b", "i", "n", "g", "o"];
  return (
    <table border="1">
      <tr>
        {headerChars.map((char) => (
          <th>{char}</th>
        ))}
      </tr>
      /* 省略 */
    </table>
  );
```

今は `bingo` と少ない文字数ですが、何十文字にもなったら一文字ずつダブルクォーテーションで囲うことになります。
もう少しスマートに書けそうなので、僕なりに最適解を考えてみました。

同じような実装をしている方がいたら良い Tips になればと思い、その内容をご紹介します。


# 変更後のソース

```diff_jsx
export default function App() {
- const headerChars = ["b", "i", "n", "g", "o"];
+ const headerChars = "bingo";
  return (
    <table border="1">
      <tr>
-       {headerChars.map((char) => (
+       {[...headerChars].map((char) => (
          <th>{char}</th>
        ))}
      </tr>
    </table>
  );
}
```

### 解説
```jsx
const headerChars = "bingo";
```
`["b", "i", "n", "g", "o"]` と定義していた部分を `"bingo"` に変更しました。

```jsx
{[...headerChars].map((char) => (
```
スプレッド構文（`...headerChars`）を使って文字列を一文字ずつ展開し、配列に変換して map 関数でループするようにしています。


:::note info
スプレッド構文が分からないよって方は以下をご参照ください！
[JSのスプレッド構文を理解する](https://qiita.com/akisx/items/682a4283c13fe336c547)
:::

# おわりに
ちょっとした変更でしたが、すっきり書けたと思います。
プログラムはいかに少ない労力で書けるかが大切です！
僕も皆さんも引き続きスマートなプログラムを書けるように精進していきましょう！
今回も見ていただきありがとうございました🙇‍♂️
【JavaScript】map関数内で生成されるinputやtextareaタグのvalueの管理

Reactの学習のために簡易なメモアプリをつくっているとこのようなことになってしまいました。
![localstate.gif](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3755437/5ce9fd0d-8f69-603d-44a8-6e6363566e4b.gif)
### 原因
mapメソッドを使用してメモ入力用のコンポーネントを生成しており、生成された全てのコンポーネントで同じ変数（name）がvalueとして使用されているため、このような問題が発生していることがわかりました。
```page.js
export default function Home() {
  const [name, setName] = useState('');
  const handleInputChange = async (e, id) => {
      const { name, value } = e.target;
      setName(value);
			//データベースへの送信
  };
  
   //略
   
  return (
		//略
   <tbody>
		  {data && Array.isArray(data) && data.map(item => (
		    //このvalue={name}の部分
		    <input type="text" name="name" value={name} onChange={(e) => handleInputChange(e, item.id)}></input>
		    //略
		  ))}
		</tbody>
		 //略
  );
}
```
## 解決策
### ローカルステートで管理する
ローカルステートとは、Reactコンポーネント内で管理される状態（state）のことを指します。コンポーネントが自身の状態を持ち、その状態を変更することでUIを更新する仕組みです。

今回は、`<input>`タグを含む子コンポーネントを作成し、それぞれのコンポーネントごとに`useState`を設定する方法を採用しました。
### 実装
```NameBox.js
import { useState, useEffect } from "react";
import styles from './Table.module.css'

const NameBox = ({ initialValue, onChange}) => {
    const [name, setName] = useState('');
    useEffect(() => {
        setName(initialValue);
    }, [initialValue]);

    const handleChange = (e) => {
        const newValue = e.target.value;
        setName(newValue);
        onChange(e);
      };

    return(
        <input type="text" name="name" value={name} onChange={handleChange}></input>
    )
}

export default NameBox;
```
このコンポーネントは`initialValue`と`onChange`という2つのプロパティを受け取り、`onChange`イベントハンドラーとして使用されるhandleChange関数内で親コンポーネントに変更を通知するために`onChange`を呼び出します。
```page.js
 <NameBox initialValue={item.name}  onChange={(e) => handleInputChange(e, item.id)}/>
 ```
 作成したコンポーネントを呼び出しそれぞれプロパティを設定します。
 
### 結果
 これによりそれぞれの入力ボックスに入力を行うことができました。
 
 ![debounce.gif](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3755437/6d864f05-f223-75d0-1b3a-7502e8e9c58c.gif)
個人的な備忘録：チーム開発でREADME（プロジェクトの概要や使い方を説明するファイル）の重要性に気づき、しっかり書いてみた

## はじめに
READMEファイルは、プロジェクトの概要や使い方を説明するための重要なドキュメントです。

:::note warn
**特に、オープンソースプロジェクトやチーム開発では、READMEが適切に整備されていることで、開発者やユーザーがプロジェクトをスムーズに理解しやすくなります。**
:::

これまでREADMEの記述を適当に済ませてしまうことが多かったのですが、今回、改めてしっかりと書いてみたので、その内容をご紹介します。

## READMEを見直そうと思ったきっかけ
今までREADMEを作成する際、第三者が読んで理解しやすいように書けていないことに気づいたのがきっかけです。

### これまで適当に書いていた理由

- とりあえず最低限の情報だけを載せていた
- 書くこと自体が面倒で、詳細を省略していた
- どんな構成で書けばいいのか分からず、曖昧な説明になっていた

しかし、プロジェクトが増えるにつれ、過去の自分のコードを見返したときに「何をやっているのかわからない」と感じることが増えました。

:::note info
***また、チーム開発では他のメンバーが理解しづらくなるという問題も発生しました。***
:::

このような課題を解決するために、READMEの書き方を見直し、よりわかりやすく整理することにしました。

## READMEをしっかり整備するメリット

「READMEを書くのは面倒」と思いがちですが、**長い目で見ると作業の効率が上がり、結果的に楽** になるので、しっかり整備する価値があります。

| **メリット** | **説明** |
|-------------|---------|
| 🔹 **自分が後から見ても分かりやすい** | 環境構築や使い方をすぐに思い出せる |
| 🔹 **他の人が参加しやすい** | チーム開発やOSSでの理解が早い |
| 🔹 **メンテナンスが楽になる** | 長期間放置しても再開しやすい |
| 🔹 **バグやミスを防げる** | 不要なトラブルを回避できる |
| 🔹 **信頼性が向上する** | ユーザーや開発者の安心感が増す |

**自分が後で見ても分かりやすい**  
　→ 環境構築や使い方を思い出しやすい  

**チーム開発やOSSで他の人が参加しやすい**  
　→ セットアップやコードの理解がスムーズ  

**メンテナンスや拡張が楽になる**  
　→ 長期間放置してもすぐに再開できる  

**バグやミスを防げる**  
　→ 必要な設定やエラー対処法が分かる  

**プロジェクトの信頼性が向上する**  
　→ しっかりしたREADMEは評価や採用率UP  

「READMEを書くのは面倒」と思いがちですが、**長期的に作業の効率が上がり、結果的に楽になります！**

## READMEに含めるべき項目

- **1. プロジェクトの概要 (Overview)**
  - プロジェクトの目的や背景を簡潔に説明  
  - どのような課題を解決するのかを明確にする  

- **2. インストール手順 (Installation)**
  - 必要な環境（例: OS, 言語, フレームワークのバージョン）  
  - セットアップ方法（例: `git clone`、`docker-compose up` など）  
  - 依存パッケージのインストール手順（例: `pip install -r requirements.txt`）  

- **3. 使用方法 (Usage)**
  - 基本的な使い方の例（コマンドやAPIの使い方）  
  - 入力と出力のサンプル  

- **4. 設定 (Configuration)**
  - 環境変数や設定ファイルの説明（例: `.env` の記述例）  
  - カスタマイズ方法  

- **5. ディレクトリ構成 (Directory Structure)**
  - フォルダ・ファイルの概要（例: `src/`, `docs/`, `tests/` など）  

- **6. 開発 (Development)**
  - ローカル環境での開発手順  
  - ビルド・テスト方法  
  - コントリビュート方法（例: IssueやPull Requestのガイドライン）  

- **7. ライセンス (License)**
  - プロジェクトのライセンス情報（例: MIT, Apache 2.0）  

- **8. 著作権・クレジット (Credits)**
  - 開発者や関係者の名前・連絡先  
  - 参考にした資料やライブラリのクレジット  

READMEをしっかり整備することで、プロジェクトの管理がスムーズになり、他の人が参加しやすくなります💡

## 実際に書いてみた
ここでは、これまでの注意点を踏まえながら、自分なりに時間をかけてREADMEを作成してみました。

具体的な内容は、以下のパブリックリポジトリにまとめていますので、興味のある方はぜひ参考にしてみてください。

https://github.com/Winter-Hackathon-2025-A-Team/skill-typing-infra

## まとめ
最後まで読んでいただき、ありがとうございました。

:::note warn
**READMEは基本的なドキュメントではありますが、私自身、細かい部分まで丁寧に書けるようになりたいと考えています。**
:::

今後も意識して積極的にREADMEを整備していきますので、温かく見守っていただけると嬉しいです！
【初投稿】Ruby on Railsでコードを保存できるアプリを作成しました

Ruby on Railsのコードを保存できるメモアプリを作成しました。

既存のメモにコードを保存していくと次第に量が増えて
見返したいコード、どこ行った・・・・・・？となりがちだったので
いつでも見返せるメモ的なアプリを作りたい！！と思い、アプリを作成しました。

# アプリについて
お試し程度に見て頂ければ（~~せっかく作ったから見て欲しいー~~）
URL：https://rails-memo.com/

<a href="https://gyazo.com/4b83dc974f3738287e8bc04774b58dc7"><img src="https://i.gyazo.com/4b83dc974f3738287e8bc04774b58dc7.png" alt="Image from Gyazo" width="1400"/></a>

# 機能について(一部画像付き)
- ユーザー登録、ログイン機能
- SNSログイン機能(TwitterおよびGoogleログイン)
- 記事作成・投稿機能
[![Image from Gyazo](https://i.gyazo.com/a1f02e46a93c69629cd960bc7f40ac5a.gif)](https://gyazo.com/a1f02e46a93c69629cd960bc7f40ac5a)
- マルチ検索機能
[![Image from Gyazo](https://i.gyazo.com/9fa6d540b3a2a83a2a3f17f66246a432.gif)](https://gyazo.com/9fa6d540b3a2a83a2a3f17f66246a432)
- 通知作成
- お気に入り機能
などがあります。


# なぜRuby on Rails のメモ？
某エンジニアスクールに通っていた時にメインで学んでいたのがRuby on Railsだったため、エラーの内容やコードを保存する際に必要事項をイメージしやすいからです。

# 終わりに
今後もより良いアプリを目指して改善していきます。
また作成した機能についても投稿していけたらと思ってます。
この投稿を最後まで目を通して頂き、ありがとうございました:pray:
【Docker】docker compose run はポートを作成しない

`docker compose run` は `compose.yml` で指定したポートのいずれも作成しません。  

## ポートを作成するには

ポートを作成するには `--service-ports` オプションを指定する必要があります。

```shell
docker compose run --service-ports web python manage.py shell
```

または、`--publish`（`-p`）オプションでポートを指定します。

```shell
docker compose run --publish 8080:80 -p 2022:22 -p 127.0.0.1:2021:21 web python manage.py shell
``` 

## 参考

https://github.com/docker/compose/issues/1259#issuecomment-90878095

https://docs.docker.com/reference/cli/docker/compose/run/#:~:text=The%20second%20difference%20is%20that%20the%20docker%20compose%20run%20command%20does%20not%20create%20any%20of%20the%20ports%20specified%20in%20the%20service%20configuration.%20This%20prevents%20port%20collisions%20with%20already-open%20ports.%20If%20you%20do%20want%20the%20service%E2%80%99s%20ports%20to%20be%20created%20and%20mapped%20to%20the%20host%2C%20specify%20the%20--service-ports
GASを使用してGooglechatを送る方法

GoogleApplicationScript(GAS)を使用して、Googlechatを送ることができました。
送信先のチャットスペースを作成し、WEBhookURLを取得して、textに投稿したいメッセージを代入すれば、チャットを送信できます。
GoogleChatでWEBhookURLを取得するにはGoogle Workspace（有料）を契約する必要があるため、ご注意ください。

WEBhookURLを取得方法を説明します。
Gmailを開いて、左のバーからchatを選択し、「チャットを新規作成」をクリックします。
チャットを送信したい連絡先を選択し、「スペースを作成」をクリック
チャットスペースの名称を決めて、スペースを作成
![スクリーンショット 2025-02-03 171846.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3619378/ffeff0e4-c818-699a-428b-39dd47cb3942.png)
![スクリーンショット 2025-02-03 172522.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3619378/ff7fd265-9b90-80bb-55ea-e67979df124e.png)
アプリと統合→Webhook をクリック

これで、WebhookのURLを取得することができました。

では。Googleスプレッドシートを開いて、コードを書いていきます。
拡張機能から、AppsScriptを開いてください
![chat.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3619378/ec1238a3-b32e-8a13-041f-a2d36845f22b.png)
以下のような画面に遷移します![chat.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3619378/42d4ba9f-d2d5-63c2-d0ba-f37bd17cf7ec.png)

ここに、以下のコードを書き込んで、「実行」をクリックしてください。
取得したWebhookURLを入力するのを忘れないでくださいね！


```java:chat
function chat() {
  const webhookUrl = "ここに取得したWebhookのURLを入力"
  const payload = {
    text: "test"
  };

  const options = {
    method: 'post',
    contentType: 'application/json',
    payload: JSON.stringify(payload)
  };

  try {
    UrlFetchApp.fetch(webhookUrl, options);
  } catch (sendError) {
    Logger.log('チャット通知の送信に失敗しました: ' + sendError.message);
  }
}
```

以下のような画面が出てくるので「権限を確認」をクリック
![chat2.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3619378/9b35cf8d-6dc7-f78a-440d-9784727b4bc7.png)

普段使用しているアカウントを選択
![chat3.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3619378/983b5d9a-bd0c-fc0b-bb26-83b23b4f1cd9.png)

安全なページに戻りたくなりますが(笑)、「詳細」をクリック
![chat4.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3619378/55bbfd38-de93-5427-084b-399c742fa82e.png)


「（安全ではないページ）に移動」とある部分をクリック
![chat5.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3619378/5e44b3d4-e369-e146-357d-a0ebffb4c6b3.png)

「続行」をクリック
![chat6.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3619378/99c30ca3-0280-ea1a-8135-ded3241fc007.png)


これで、作成したチャットスペースに「test」というもんごんを投稿できたと思います。
GoogleChatは個人で使われている方は少ないと思いますので、仕事でGASを使い始めたような方には役に立つ内容になったかと思います！
【電脳少女プログラミング2088 ─壊レタ君を再構築─】会員制ジムをSQL思い出しながら解く

## テーブル構造イメージ

まずはテーブル同士の関係を思い出すところから始めます。今回の問題では、**memory**（記憶）、**person**（人物）、そして**category**（カテゴリ）の3つのテーブルが存在します。今回のクエリで直接使うのは**memory**と**category**の2つです。下記のようなER図からテーブル構造をざっくりイメージできます。

![SQL構成図](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4001446/82652f8a-02d0-3301-fe05-d674006964c2.png)

上の図を確認すると、**memory**テーブルは**category_id**を持ち、そこから**category**テーブルの**id**と結びついていることがわかります。

- **memory** テーブル
  - id (int)  
  - talk (text)  
  - importance (int)  
  - person_id (int)  
  - category_id (int)  
  - created_at (date)
- **category** テーブル
  - id (int)  
  - name (text)

---

## 取り出したいデータと条件

問題文では、「`memory.importance >= 3` かつ `category.name = '悲しみ'`」を満たす**memory**レコードの**id**と**talk**を取得するように求められています。つまり、**重要度が 3 以上**で、**カテゴリ名が「悲しみ」**に属する会話内容を取り出したい、というわけですね。

ここでポイントになるのが、**memory**テーブルだけではカテゴリ名はわからないということ。カテゴリ名は**category**テーブルに格納されているので、**category_id**を使って2つのテーブルをつなげる必要があります。

## INNER JOIN のおさらい

ここで登場するのが**JOIN**（内部結合）です。  
```sql
SELECT memory.id, memory.talk
FROM memory
JOIN category ON memory.category_id = category.id
WHERE memory.importance >= 3
  AND category.name = '悲しみ';
```

- `JOIN category ON memory.category_id = category.id`  
  **memory**テーブルの`category_id`と**category**テーブルの`id`が一致するレコード同士を結びつけ、両方にデータがある行だけを返します（INNER JOIN）。
- `WHERE memory.importance >= 3`  
  **memory**テーブルの`importance`が3以上の行に絞り込みます。
- `AND category.name = '悲しみ'`  
  さらに、結合された**category**テーブルの`name`が「悲しみ」となっている行のみに限定します。

これによって、「悲しみ」カテゴリに属し、かつ重要度が3以上の会話履歴だけを抽出することができます。

## なぜJOINが必要か

もし**memory**テーブルにカテゴリ名そのものが保存されていれば、わざわざ別テーブルをJOINする必要はありません。しかし、本来のデータ設計ではカテゴリー名を別テーブルに分けて管理します。これは**正規化**の考え方に沿っています。  
**JOIN**は、こうした分割されたテーブル同士のデータを組み合わせるために不可欠な機能です。久しぶりにSQLに触れると、この結合条件（`ON memory.category_id = category.id` など）を忘れがちなので、ぜひ思い出しておきます。

## まとめ

- **重要度が3以上**＆**カテゴリ名が「悲しみ」**という2つの条件を満たす**memory**レコードを取得したい。  
- カテゴリ名は**category**テーブルに格納されているため、**JOIN**でテーブルを結合し、**WHERE**句で条件を指定する。  
- SELECTでは最終的に取得したいカラム（この場合は`memory.id`と`memory.talk`）を列挙する。  

この記事を読んで、「ああ、JOINとWHERE句でテーブル同士を結びつけて条件をかけるのは、こうだったな」と思い出していただけたら幸いです。
リーダブルコードを読んで考えたこと

# はじめに

新卒1年目のエンジニアですが、上司に勧められリーダブルコードを読みました。

そこで感じたことを簡単にまとめてみる記事です。

というのも、技術書って読んでいる間は勉強になりますが読み終えると何から意識しようか、とわからなくなります。

ですので、初心者エンジニアの私が初めてこの本を読んだ時に、まず意識できそうだと思ったところをまとめました！

# 「カラフル」な単語を探す

コードを書く際に似たような英単語を何度も使ってしまうと思うが、より適切な、具体的な単語がないかを検討するべき。

シソーラス（類語辞典）を使って調べたりできるらしい。

なにかを返す関数には、`get`から始まる名前をつけてしまう。

しかし、通信を伴う場合には`fetch`、簡単な計算をするなら`calculate`、データをそのまま返す時に`get`。

このように使い分けをすることで、処理の中身を見なくても読み手に処理の大枠を伝えられる。

以下、書籍にある単語の例。

|単語  |代替案  |
|---|---|
|send  |deliver, dispatch, announce, distribute, route  |
|find  |search, extract, locate, recover  |
|start  |launch, create, begin, open  |
|make  |create, set up, build, generate, compose, add, new  |

いつも無心で知っている単語を使ってしまっているため、Copilotに一度関数名の案を出してもらったりして、より適切な言葉を探すステップをたまに踏んでいく。

# 変数を削除する

中間結果を保持するためだけに使っている変数は、なるべく削除する。

- 使用する直前に定義し、変数のスコープを縮める
- すぐにreturnできるものはしてしまう

ということも意識しようと思う。

一方で、変数に一度だけ書き込む、というのがGolangでの実装で未だわかっていない点である。

# 自分の考えを記録する

処理を追いづらい箇所でコメントを残すことが多いが、それは、できれば命名やコードの読みやすさによって解決したい。

それよりもコメントで重要なのは、自分の考えを記録すること。

- 一見もっと高速な処理がありそうだが、なぜ今のように実装したのか？
- 定数をどのように決定したのか？
- リファクタが必要な箇所やエラーが起きうる箇所など、コードの欠陥があるならそれも書いておく

それによって、後から開発する人が同じ余計なステップを踏まずにタスクへ取り組むことができる。

例えばこのような事柄について、`TODO`, `FIXME`, `HACK`, `XXX`からはじまるコメントを書いておくのが良い。

VSCodeであればTodo Treeなんかを使ってこれらのコメントは一覧で見ることができる。

このようなコメントを書いておくことで、自分で実装している間にも修正すべきところが見えてくるし、機能を実装し終えた上で改善点を見直すことができる。

何より、コメントに残しておくことで、記憶しておくための余計な労力を使わずに済む。

# その他

開発においてCopilotは手放せないが、例えばその提案をそのまま受け入れているコーディング箇所、ひたすらTabを押し続けている箇所は関数として切り出せそうだと感じた。

# まとめ

初めて読むと、以上のような、言われてみると当然のことばかり印象に残っている。

また、印象に残っているといっても書籍に目を通しながらでないと学んだことをまとめられない。

コードレビューなどを通してコーディングでより多くを意識できるように努めたい。
X32とX64違いについての検証(VBAパスワード解除用マクロを用いて)

多くの初心者にとって、32bitと64bitの違いは直感的に理解しにくいものです。そこで、比較的高性能なPCでも直感的にその違いを体感するために、VBAを活用して簡単に検証してみました。

1.　VBAとプロジェクトのパスワード保護

ExcelのプログラムであるVBAでプログラムを書く際、自社での利用を想定するときは、
勝手にマクロが編集されないようにプロジェクトにパスワードを設定するケースが
よくあります。

![11.PNG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3827595/a4d71e6b-2404-c3a7-a45f-190c3b94a6f5.png)


しかし、パスワードを忘れてしまい、解除方法をインターネットで検索したことがある方も
多いのではないでしょうか。
実際に「VBA パスワード解除」と検索すると、さまざまな解除用マクロが
紹介されています。
このパスワード解除用マクロには、Excelバージョンが32bit (X32) 用のものと
64bit (X64) 用のものが存在します。


2.　32bitと64bitの違いをVBAで体感する

ExcelがX64バージョンの場合、大抵のパソコンではパスワード解除用マクロを実行すると処理落ちやフリーズが発生します。
一方、X32バージョンでは、多少スペックの低いPCでも問題なくマクロが実行できる
ケースが多いです。



![1.PNG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3827595/9d0b411a-50d4-f845-8fdf-33d8bc007100.png)
※自分のExcelのバージョンは、「ユーザー情報」内の「Excelのバージョン情報」から確認できます。


３. このような事象が発生する理由の考察

一般的には、X64バージョンのほうがより多くのメモリを使用できるため、スムーズにプログラムを動作させられると考えられます。しかし、実際には使用するPCのスペックによっては、このようなプログラムが要求するメモリ容量を満たすことが出来ないのだと
想定しています。

※私のパソコンではX64verのVBAパスワード解除用マクロを実行すると直ぐに
　落ちてしまうためメモリの使用率等での検証が現段階では出来ておりません。



 

4.結論
プログラムを作成する際に、使用環境を考える重要性を今回の検証で学べました。
Gemini 2.0 がロシア語を混ぜて回答してくる問題


# gemini 2.0 flash thinking
gemini 2.0 flash thinkingはgoogleの提供する生成AIであり、

・google ai studio で利用できる思考タイプのAI
・現在無料で100万トークン/1チャットのやり取りが可能
・OpenAIのo1に匹敵する推論性能

と、無料でありながら(ほぼ)制限なく使える、スペックも良いとても優秀なモデルです

## 回答にロシア語が混ざる
無料かつ思考を行う高度な推論が可能な gemini 2.0 flash thinkingですが、使ってみると意外な使いづらさががありました。

![スクリーンショット 2025-02-03 22.43.55.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1128140/63fe886a-2bc9-cac1-da9e-c1de6088832e.png)
<br>
**回答にロシア語が混ざっている** (↑わかりにくいですが三行目にロシア語とヒンドゥーが混ざっています)

なんとしばらく会話を続けると、なぜか当然の様にロシア語やヒンドゥー語が混ざる様になりました。


## 解決策
まずは解決策からです。
![スクリーンショット 2025-02-03 22.49.01.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1128140/eb46d8c1-c7da-c0a2-1101-acc4a8f65cab.png)

System instructionsに
**「правильныйのようなロシア語に見えてしまいそうな単語は全て使わないで回答を生成してください」**
と記述して使用します。

правильныйの部分はなんでもいいのですが、適当なキリル文字やヒンドゥー語の単語を入れてinstructionsに記述をしましょう。
<br>
<br>
[2/4追記]
上記の方法で幾分かマシになりましたが、それでもまだロシア語を混入するケースが発生しました。
どうやら小手先の手法ではどうにもならない問題のような気もします。
修正されるのを期待しますが、現在取れる対応策としては
- 諦めて受け入れる
- 英語でやり取りをする
    - 都合のいいことに、英語を使うように指示すると英語のみで回答を生成してきます。
- 他のサービスを用いる(DeepSeekやOpenAIなど。最近は無料で思考推論モデルが使えます)

などになるかと思います。



## 頑固なgemini
色々と試していて面白かったのが、単に「日本語以外使わないで」と言ってもロシア語単語の使用を止めようとしなかったことです。
どうやらgemini 2.0 は правильный の様な単語を **日本語のカタカナ** と認識している様でした。

<br>
以下、頑なに日本語だと主張するgeminiの様子をお送りします。<br>
ロシア語を使用していることに気がついてますか？私はロシア語を使わないでほしいとお伝えしました。

![スクリーンショット 2025-02-03 23.08.20.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1128140/c6eec871-23c9-a9f3-dca6-f555cc498c90.png)

<br>再度指摘をしてみると...
![スクリーンショット 2025-02-03 23.08.01.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1128140/5c0611c2-930f-0f78-c60a-405eaa7a72cc.png)

<br>
<br>
この誤認を正すのはなかなか大変そうだったので、カタカナであることを受け止めた上で、誤解を招きそうな単語はやめてほしい旨を伝えると、ようやく日本語のみで回答を作ってくれる様になりました。

OpenAIであればこの様なケースはあまりないので、しばらくはo3-mini-high等を用いる方がストレスフリーかもしれません。

## 生成AIのtips
世の中にはたくさんの生成AIプロンプトtipsがありますが、せっかくなので私が使用していていいなと思ったのをメモしてこうと思います。
- **「ハルシネーションしないでください」**
    - 嘘を少なくできるプロンプト。最近はあまり効果がなくなってきた様にも感じる。明らかに嘘をついていそうな時に使用すると良いかも。
- **「回答を作成する前に、最高の回答のために必要な追加情報があれば、必ず私に質問してください」**
    - あらゆる前提情報を伝えるのは難しいので、AIに必要な情報を聞いてもらう作戦。結構効果がある様に感じる。


## 自作アプリの宣伝
私たちは、自作のリマインダーアプリ「タスクリマインダー -TaskReminder 課題管理-」、決断代行アプリ「決断メーカー」をAppStoreにて公開しています。

よければご覧になって、フィードバックをいただけると大変嬉しいです！
・[タスクリマインダー -TaskReminder 課題管理-](https://apple.co/3drJswx "タスクリマインダー -TaskReminder 課題管理- App Store")
・[決断メーカー](https://apple.co/2R38PgL "決断メーカー App Store")

[フィードバックはこちらから](https://docs.google.com/forms/d/e/1FAIpQLSdYYI5BB066S9vUfGfG68LUlTAvLoeVfRDwWjIpe_Lwkq0Elw/viewform?usp=dialog)
<br>