OmniAICreator/Qiita-1.07M huggingface dataset:
service ECS_SERVICE_NAME port 3000 is unhealthy in target-group TARGET_GROUP  due to (reason Health checks failed).の対応方法

ECS Serviceをデプロイすると、ALBのヘルスチェックに引っかかって無限ループすることがあります。
ヘルスのパスを設定してなかったりするとそうなったりしますが、今回はパスも設定しているし、アプリケーションも起動されていたので初めは原因がわかりませんでした。

異常を検知してもコンテナのログは
```
 LOG [NestApplication] Nest application successfully started
```
でした。(正しく起動できている)

ECSのサービスのイベントタブのイベントメッセージを確認すると
```
service <service名> port 3001 is unhealthy in target-group <ターゲットグループ名> due to (reason Health checks failed).
```
とありました。

ネット検索すると[こちら](https://repost.aws/ja/knowledge-center/fargate-alb-health-checks)を発見しました
`ヘルスチェックがエラーコードなしで失敗した`という項目があります。今回のALBの無限ループはこれが原因でした。

cdkの方では下記のようにコードを作成していたのでそこに`healthCheckGracePeriod`を追加して修正しました。
```typescript
    const fargateService = new ApplicationLoadBalancedFargateService(
      scope,
    'ecs-fargate'
      {
        ...(引数省略),
        ...
        healthCheckGracePeriod: cdk.Duration.seconds(60), // <-- ここ
      },
    );
```

追加してやることでヘルスチェックのエラーは治まるようになりました
学校で友達と喋るために今更CGIチャットを導入してみた話


![hs0pf2KCs8By1u21734055268_1734055289.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3950288/8382b1cf-bf05-973d-421c-15f5b01e347d.png)

さて、皆さんこんにちは。Miggoです。
今回はタイトルにもある通り、友達と喋る用にCGIチャットを導入した話をします。
# ロマン
ID、パスを作成してIDごとに友人に教えて授業中にチャットで喋ったり、Line持ってない友達と放課後話したり・・・うん、僕からするとロマンですね。
# いにしえのスクリプト、なぜわざわざCGI？
まずなんですけど、その手のチャットスクリプトって、ものすごく古いんですよね。なので、PHPとかだとバージョンが古すぎて動かないんです。その点、CGIはそのままサーバーにぶちこむだけでいけるので、僕はそうしました。CGIのほうがチャットスクリプトは多そうだしね。
・・まあどっちにしろ10年、20年ものなのである程度の機能は妥協しないといけないです（）
# 時代の流れ
ということでCGIのチャットで、IDつきってなると、kent-webさんの[Midnightfox Chat](https://www.kent-web.com/chat/fox.html)
ぐらいしかないです。（断定）
いろいろ調べましたが、ログイン機能を搭載したやつはこの時代はめったにないので、これを使うのが一番だと思います。この時代は、ログイン機能をつけるほうが珍しかったのかもしれないですね。~~知らんけど~~
# 導入・個人的にしておくと良いと思うこと
まあ、導入は簡単で、CGIが使えるレンタルサーバーとかにファイルをぶち込むだけです。詳しくはKentWebさんのところに全部乗ってます。レンタルサーバーとか持ってない人で、マネしてえって人は、家Tサーバーとかから借りるのがおすすめです。

## 絶対やらんと後悔する
認証のID、パスは、めんどいかもしれませんが**絶対一人ひとりに発行する形**にしたほうがいいです。全員同じパスの場合、荒らされたりされたら誰がやったか非常にわかりにくくなります。また、BANなどもしやすくなります。その該当のIDを抹消したらその人は入れなくなるはずです。
個別にIDを発行するメリットはほかにもあって、名前、それが誰か、というのが分かりやすくなります。![LDtjZzvJf3VvvmV1734054548_1734054697.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3950288/4a056dd0-ae27-fbf1-7ac7-f1630dcbffe4.png)
こういう感じで、管理画面からメッセージ、どのIDでログインされてるか、が見えます。なりすましとかにも有効ですね。まあ、その一人用IDが全員で使われると、意味を成さないですが・・・
## しておくと良いこと1
おすすめしておくことは、本来だとある、Eメール欄を消すことですね。![chrome_1eL7sdEIWq.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3950288/cd106918-fedc-0117-5166-d733ef0a6729.png)
いまどき、わざわざEメールをこういうのに入れる人は少ないと思う・・・ので消した方が個人的に良いと思います。まあこれは管理人の好みですね。
![chrome_Cz888BS2Bq.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3950288/9cf1a515-93ca-f0ed-2a1c-30d2ce6819d1.png) ←こんな感じで
消し方は、テンプレのHTMLからEメール欄を抹殺でいいと思います。少なくともそれで動くんで。
## しておくと良いこと...?
![chrome_jMylwmU7yf.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3950288/3f20fac5-5ede-2a74-3901-ce06120853bf.png)
こういうルール的なやつや
![chrome_MyxijLW4qj.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3950288/b703389b-8348-87db-8bf6-0493febfc420.png)
緊急ボタン（）とかもつけてみてはいかがでしょうか
まあめんどいのでコードはここには書きません。
# で、結局どうなん？
悪くないと思います。でも、絵文字はほぼ使えないと思ったほうがいいです。そこが最大のデメリットかもしれないですね。
友人からは好評で、もう８人ぐらいいると思います。まあ過疎だけどね
まだ教師にも３か月バレてないので、まだまだCGIチャットはつづく・・・・のか？
ふぉっふぉっふぉっ（終わり）
# もしリア友がここ見てるなら
こんなとこまで見てくるん頭おかしいんかお前
IstioのwarmupDurationSecsのweight値について

# 概要
IstioのwarmupDurationSecsを利用する機会がありましたが，どういったweightの変更を行っているのかが気になったので本記事でまとめます。

# warmupDurationSecsとは
warmupDurationSecsは，Istioで新しいPodがデプロイされた際にwarmup期間を指定するパラメータです．このパラメータはDestinationRuleのLoadBalancerSettingsで行います．

https://istio.io/latest/docs/reference/config/networking/destination-rule/#LoadBalancerSettings

弊社ではFlaggerを用いているので，canaryリソースでは以下のような設定で行います
```yaml
apiVersion: flagger.app/v1beta1
kind: Canary
metadata:
  name: tmp
spec:
  service:
    trafficPolicy:
      loadBalancer:
        simple: LEAST_REQUEST
        warmupDurationSecs: 60s
```

# warmupDurationSecsのweight変更
warmupDurationSecsはEnvoyのSlow Start Modeの仕組みをラッピングした機能です．

https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/upstream/load_balancing/slow_start


ちゃんとした数式を元にweightが求められており、それが以下になります。

```math
NewWeight = Weight * max(MinWeightPercent, TimeFactor^{1/Aggregation})
```
さらにTimeFactorは以下のように求められます．

```math
TimeFactor = max(TimeSinceStartInSeconds, 1) / SlowStartWindowInSeconds
```

パラメータ | 説明 | 備考
--- | --- | ---
SlowStartWindowInSeconds | warmup期間(秒) | 
TimeSinceStartInSeconds	| 開始からの経過時間(秒) | 
TimeFactor | 経過時間の割合 | 
MinWeightPercent | 最小重み付け | デフォルト値は0.1
Aggregation | 重み付け曲線の調整パラメータ | デフォルト値は1.0
NewWeight | 新しい重み付け | 

デフォルト値のみで計算し、warmupDurationSecsを60sと設定すると、以下のように線形的にNewWeightが増えていき、最終的に100%になります。最初の7秒ほどはTimeFactorが0.1を下回るので、MinWeightPercentが最大値となるため10%固定です。
これによりHPA等で作られたPodは安全に暖気をしてからユーザのリクエストを受け入れる準備ができます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/469304/64df31a0-47fe-5b7d-fc84-522f02249d79.png)



# まとめ
本記事ではwarmupDurationSecsのweight値の変更について調べました。
ちゃんとした式を用いられていることにびっくりしましたが、もっとEnvoyがどのようなネットワークでリクエストをうまく振り分けているのかも調べたいと思いました。
Deep Searchを試してみた

# Deep Search とは
- ユーザに変わって調査しレポートを作成する機能
- 作成したレポートはGoogle Documentに変換できる。
- 2024年12月12日現在では英語版・Gemini有料ユーザーのみ使える
    - Google アカウントの言語設定を英語にしたら日本でも利用可能


# つかってみた
サイドバーでモデルを選択できるのでクリックする
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/698823/9da598df-8a9f-63cd-1e5d-de735c69bac6.png)

”Ask Gemini”バーに調べたいワードを入れると調査の計画を表示してくれる。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/698823/ad545a21-bd82-1d0c-1e75-60421bd18b1d.png)

Edit planをおすとこのように実行計画を表示してくれる。恐らく対話で計画を変更することができる。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/698823/4fc4e309-8d6f-8c52-818d-f8f72d59ed37.png)

実行するように命じるとスタート。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/698823/6007653a-33a4-7cd7-899e-a89637abaac5.png)

今回は5分くらいで終了しました。以前GenSparkで類似の機能を使ったときは数十分はかかっていたと思うのでかなり早いです。右上の「Open in Docs」を押すと結果をGoogle Documentに吐き出してくれます。これもすぐに作成してくれました。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/698823/718aed7c-0057-c57e-a6e9-fe22d64ef745.png)

左下のチャットバーで翻訳するように指示を出すと，対話結果のほうに出してくれました。（結構時間はかかります。） 翻訳したものをドキュメントに吐き出せないか聞いてみましたがダメと回答しました。以下は英語ですがどんなものか見たい方のご参考になれば幸いです。

https://docs.google.com/document/d/1NK38bgpBcXyAnXXU-8ek8cBAPdQd8kaCqNcO_PCEoVI/edit?tab=t.0
LeetCodeを1日1題解いてみる (day41)

41日目に取り組んだ問題はこちら！

# 584. Find Customer Referee

https://leetcode.com/problems/find-customer-referee/description/?lang=pythondata

## 問題文
Table: `Customer`
```
+-------------+---------+
| Column Name | Type    |
+-------------+---------+
| id          | int     |
| name        | varchar |
| referee_id  | int     |
+-------------+---------+
```
id is the primary key column for this table.
Each row of this table indicates the id of a customer, their name, and the id of the customer who referred them.

Find the names of the customer that are not referred by the customer with id = 2.

Return the result table in any order.

## 僕の回答
```py
import pandas as pd

def find_customer_referee(customer: pd.DataFrame) -> pd.DataFrame:
    df = customer[(customer["referee_id"]!=2) | (customer["referee_id"].isnull())]
    return df[["name"]]
```

## より効率の良い回答例
特になし

## 学んだこと
特になし。今までの知識でできた。

## コメント
今回の問題は簡単だった。

## 次の問題はこちら!
https://qiita.com/h_y_s_d/items/75330333d0227ecd13e2
Copilot Studioでチャットボットをつくろう ~SharePoint編~

# はじめに Copilot Studioって？
Copilot Studioは、Microsoftが提供しているローコード製品です。
自分だけのCopilotを作成したり、既にあるCopilotをカスタマイズしたりすることができます。
今回は、Copilot Studioを使って社内用チャットボットを作る方法を書いてみます。

# Copilot Studio作成の手順
1. データソースを用意
1. Copilot Studioにデータソースを登録
1. (必要に応じて条件分岐などを設定して)完成

すごく簡単です。
使えるデータソースはこんな感じです。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2217543/8a483398-ed79-daec-c5ee-b4ff6f2c5571.png)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2217543/7a0d7ca7-5394-7854-82f7-56898f840f86.png)
設定が必要ですが、AzureやSalesforce、Dynamic 365との接続も可能です。
今回は、SharePointをデータソースにして作成してみようと思います。
以前、WebサイトをデータソースにしたBotも作成したので、そちらもよければ併せてご覧ください！

https://cloudsteady.jp/blog/2024/10/31/94116/

## SharePointリストをデータソースにする
SharePointサイトのURLを入力します。
![スクリーンショット 2024-12-13 092238.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2217543/7393cce6-d5b3-c7d5-cce6-1b6d99b3eb4e.png)
ちなみに、Copilot Studioではデフォルトで「AIが備えるナレッジの使用」がオンになっています。
データソースに存在していない質問(≒Bot作成者が意図していない質問)がきたときに答えてくれるのはものすごくありがたいのですが、今回はSharePointのデータのみを使用したいので、オフにします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2217543/391c51a4-a7e8-33ed-e4be-258f3c4bb033.png)

# SharePointサイト上のファイルを検索しよう
「あれ、あのファイルどこにいったっけ……？」や、「前も似たようなプロジェクトやったな、あのときの提案資料みたいな……」など、ファイルを探すのに時間がかかることはありませんか？私はよくやります。
SharePointサイトをデータソースに設定すると、Copilotに「この資料出して！」と言うだけで「どんなことが書いてあるのか」と、そのファイルを一緒に返してくれます。
![スクリーンショット 2024-12-13 104243.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2217543/67bbef73-e19f-b7e9-9781-5696be7dedca.png)

![スクリーンショット 2024-12-13 104415.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2217543/fa333d76-5b40-ab06-efc1-6c7cdfd10673.png)
参照になっているところをクリックすると、ファイルのダウンロードができます。
ただ、例えば「このファイルの格納場所をおしえて」と投げかけても上記のファイルパスを教えてくれるわけではありませんでした。別のファイルの中身に反応してしまうようです。

# おわり
今回はSharePointサイト上のコンテンツを取ってきてくれるCopilotを作成してみました。
本当はSharePointサイトの「リスト」項目を参照したかったのですが、そちらはなぜかうまくいかず……。
今度リベンジしようと思います。なにか知っている方がいたら教えてください！！
色々あってUbuntuにOpenSearchをインストールしてみた

# はじめに

以前、ElasticSearchを使ってやっていたことがあったのですが、しばらく使ってなくて一度環境設定をやり直そうと思ったらOpenSearchを見つけたのでこちらをインストールしてみることにしました。

# 環境

- DeepLearningBOX
- Ubuntu 22.x
- OpenSearch 2.18

# ダウンロード

以下のURLからダウンロードができます。

https://opensearch.org/downloads.html

でもターミナルから作業をするので以下のコマンドでダウンロードしました。

```shell:
curl -OL https://artifacts.opensearch.org/releases/bundle/opensearch/2.18.0/opensearch-2.18.0-linux-x64.deb
```

# インストール

以下のコマンドでインストール。
ただし「*****」の部分は自分で使うパスワードを入力して下さい。

```shell:
sudo env OPENSEARCH_INITIAL_ADMIN_PASSWORD=***** dpkg -i opensearch-2.18.0-linux-x64.deb
```

## メモリー割当の設定

以下のとおり「1g」の部分を「4g」に変更

```
sudo nano /etc/opensearch/jvm.options
```
以下の文字列を探します。
```
-Xms1g
-Xmx1g
```
↓ 以下のとおり変更
```
-Xms4g
-Xmx4g
```

# 起動

以下のコマンドにてデーモンとして起動

```
sudo systemctl enable opensearch
sudo systemctl start opensearch
sudo systemctl status opensearch
```

# 動作テスト

以下のコマンドで応答を確認

```shell:
curl https://localhost:9200 -u admin:***** -k
```

# プラグインのインストール

日本語全文検索ができるように以下のコマンドでkuromojiプラグインをインストール

```shell:
cd /usr/share/opensearch/bin/
sudo ./opensearch-plugin install analysis-kuromoji
sudo ./opensearch-plugin install analysis-icu
sudo systemctl restart opensearch
```

## 動作テスト

以下のコマンドでインデックスを作成

```shell:
curl -X PUT -H "Content-Type: application/json"  "localhost:9200/books?pretty" -d'
{
    "settings":{
        "analysis":{
            "analyzer": {
                "default": {
                    "type": "custom",
                    "tokenizer": "kuromoji_tokenizer",
                    "filter": ["kuromoji_part_of_speech"]
                }
            }
        }
    }
}'
```

以下のコマンドで分ち書きできていることを確認

```shell:
curl -H "Content-Type: application/json" "localhost:9200/books/_analyze?pretty" -d '{"text": "桐島部活やめるってよ"}'
```

できた！
提案資料は恋人へのクリスマスプレゼントだと思って作れ

:::note warn
警告
恋人へのプレゼントを適当に選んでる人は読まないでください。
頭パンクして卒倒します。
:::

考えてみてください。恋人にプレゼントを渡すとき、何を意識しますか？

**「何を贈れば喜ぶだろう」「どんな風に渡せば心に響くだろう」**

――そんなことを考え抜きますよね。(よね？）

実は、提案資料を作るときも同じなんです。
相手（クライアントやユーザー）が何を求めているのか徹底的に考え、喜ばれる形で「価値」を届ける。それが優れた資料の条件です。

**恋人を喜ばせるために選ぶプレゼントと、提案資料の構成には驚くほど共通点があります。**
恋人へのプレゼントを準備するプロセスをマスターすれば、きっと仕様書や提案資料が相手に伝わる認められるものとなるはずです。


## 1. リサーチ：ユーザーを知り尽くせ

🎯 恋人の好みを徹底的に調査しなさい

恋人にプレゼントを渡すなら、相手の好きなものをリサーチしますよね？
普段の会話やSNS、過去のプレゼントの反応をヒントに「何が喜ばれるのか」を考えます。

**提案資料も同じです**

:::note info
プロジェクトの対象ユーザーやクライアントを深く理解する。
具体的なペルソナ設定を通じて、相手のニーズや課題を明確化する。
リサーチで得た情報を基に、目的を定義します。
時には直接相手に聞くことも大切です。（生の声大事）
:::

## 2. 解決策を考える：どんなプロダクトを贈る？
🎁 恋人が喜ぶプレゼントを選ぶ

リサーチの結果、「相手が最も喜ぶもの」を選びます。
ここで重要なのは、「相手の視点で考える」こと。

**提案資料も同じです**

:::note info
ユーザーが抱える課題を解決するためのプロダクトや機能を具体化。
**「価値提案 (Value Proposition)」**　を考え、相手にどう喜ばれるかを明確に示す。
技術的なソリューションだけでなく、UXやビジネス的なメリットも検討する。
目の前のことを考えるのではなく、長期的な目線も必要です。
:::

## 3. 見せ方にこだわる：プロダクトのUX
🎀 ラッピングにも心を込める

プレゼントの包装が雑だと、中身が良くても印象は悪くなりますよね？
見た目にこだわることで、相手への気持ちを伝えることができます。

**提案資料も同じです**

:::note info
視覚的な整合性を重視する。例：シンプルなデザイン、統一感のあるフォント、見やすい図解。
必要な情報を一目で伝えられるレイアウトを設計。
提案書自体を「良いプロダクトのUX」に見立てる視点を持つ。
実際に説明する時に、順序良く意図が伝わるように説明できる資料であることも重要です。
:::

## 4. 最後に：情熱を込める
🔥 「これを渡したい！」という想いを込める

どれだけリサーチや準備が完璧でも、「自分の気持ち」が欠けていると、相手には伝わりません。恋人へのプレゼントも、企画や提案資料も同じです。

**なんやかんや大事なのはパッション！**

:::note info
「このプロジェクトに取り組みたい！」「こうすることでこんな価値を届けられるのです！」という熱意を資料に込める。
技術だけでなく、「このプロダクトがどう社会を変えるか」を考える大きな視点（役職が2つ以上↑の視点）が重要。
:::

----------------------------------
### まとめ
|🎯 ステップ|📋 内容 |
|---|---|
|リサーチ|相手（ユーザー）を徹底的に知る|
|選定|相手が喜ぶプレゼント（解決策）を考える|
|見せ方|丁寧にラッピング（レイアウトやデザイン）|
|情熱|自分の気持ちを込めて作る|

提案資料を作るプロセスは、恋人へのクリスマスプレゼントを選ぶのとほぼ同じです。

* リサーチで相手（ユーザー）のニーズを深く理解し、
* 最適な解決策を提供することで喜ばれる、
* 見せ方にこだわり、最後に情熱を込める。

これらを実践すれば、あなたの提案資料は単なる書類ではなく、相手の心に響く「最高のプレゼント」になるでしょう。

あなたの情熱とアイデアを込めた提案で、プロジェクトを成功に導きましょう！

あなたの提案書が、**相手の心に届く最高のプレゼントになりますように…**
Alpine.jsのx-dataの中身を見る

## はじめに
LaravelのbladeファイルでAlpine.jsを使った開発をしており、書いた処理がうまく動かないときに「x-dataの中身をみたい」という場面がありました。

そんなときにデバック用で便利なツールがあったのでご紹介です。

## 結論
以下のChromeの拡張機能を入れる。

https://chromewebstore.google.com/detail/alpinejs-devtools/fopaemeedckajflibkpifppcankfmbhk?hl=JA&pli=1

## 使い方
いつも通り開発者ツールを立ち上げると、ネットワークやアプリケーションの他に「Alpine.js」が追加されていると思います。

![スクリーンショット 2024-12-13 10.32.49.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3783222/83b561d9-5329-f140-fb92-c30c17a10338.png)

例えばbladeファイルで`<div x-data="{ activeTab: 'buttonA' }">`のようにx-dataを定義しているとします。

ボタンをクリックするとx-on:clickでx-dataを操作するようにしており、開発者ツールで見るとx-dataの中身が変化していることがわかります。

![画面収録 2024-12-13 10.31.38.gif](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3783222/3cc59251-beb3-4ab1-8a70-f1a9af1cd883.gif)

こんな感じでサクッと確認できますし、手軽に導入できるのでオススメです:metal_tone2:
LWCの基本的な使用方法（Salesforce)

# はじめに
今回は普段の業務で使用しているLightning Web Components (LWC)の基本的な使用方法についてご紹介していきたいと思います。

# 概要
SalesforceのLightning Web Components（LWC）は、Web開発の最新技術をSalesforceに組み合わせる方法として非常に注目されています。

LWCコンポーネントは、以下の3つから構成されます。

・a.html - コンポーネントのマークアップ
・b.css - スタイルシート
・c.js - ロジック（データ取得や処理）
# コンポーネント作成の流れ
以下のコマンドでコンポーネントを作成。

```bash
sfdx force:lightning:component:create --type lwc --componentname test
```
a.htmlにコンポーネントのHTMLを記述していきます。
```
<template>
  <h1>テスト</h1>
  <p>TESTです</p>
</template>
```
b.jsファイルにコンポーネントのロジックを記述します。例えば、ボタンがクリックされたときにメッセージを表示するロジックを追加します。
```
import { LightningElement } from 'lwc';

export default class test extends LightningElement {
  message = 'テスト！！';

  handleClick() {
    alert(this.message);
  }
}
```
c.cssでコンポーネントにスタイルを追加します。タイトルの文字色を変更する。
```
h1 {
  color: red;
}
```
作成したLWCコンポーネントは、SalesforceのLightning App BuilderやVisualforceページに追加して表示できます。

# 最後に
LWCは、Salesforceアプリケーションのユーザーインターフェースを効率的に構築するためのツールでした。基本を抑えた後は、Apexとの連携などさらに深い知識を学んでいけたらと思います。
【クラウドエンジニアになって半年経過しました】

# IT業界完全未経験でクラウドエンジニアへ転職してからの半年を振り返る

この記事はデジタルキューブグループ アドベントカレンダー2024 12月17日の記事です。

https://qiita.com/advent-calendar/2024/digitalcube-heptagon

# はじめに
株式会社ヘプタゴンへクラウドエンジニアとして転職しましたtomokiです！

前職は自動車工場でライン作業や、ボイラーや変電所など物理インフラの保守運用管理をしていました。

そんなワタシが転職から現在に至るまでを一旦振り返ります。

# 転職前のワタシ
業界経験も無ければ資格もない状態で「この仕事がしたいので、ここで働かせてください！」は流石に通じないと思っていたので、独学でAWSの勉強を始め、EC2とRDSを組み合わせたWebアーキテクチャを作ってみたり、CloudFormationに軽く触れたりしました。 

また、勉強を通じて AWS認定 ソリューションアーキテクト - アソシエイト (SAA) の資格取得もしました。

# 実際に業務に携わってみて
## 難しい！けど楽しい！
IT業界未経験で入ったので「ん？これなんだ？」と、分からないことだらけです。分からないことが分かっていないことも少なくありません。

分からないなりにも調べたり聞いたりして突破できた時は「よっしゃー！」となり、より一層仕事の楽しさを感じます。

何よりも会社の方々がとても暖かいことに救われています。

## 伝えるって重要だけど難しい！
対面・テキスト問わず、伝えたい内容を整理してから話をするってとても大事だけど、実践するのは意外と難しいですよね。

いかに物事を分かりやすく伝え、読み手の負担を軽減し、効率のよいコミュニケーションができるか。

ワタシ自身もまず伝えることに必死過ぎて内容が整理できておらず、迷惑をかけてしまうことが多いので、最近は5W1Hに3つの要素を加えた派生系「8W3H」を意識して伝えるよう心がけています。

参考記事：https://swingroot.com/5w1h-8w3h/

## 慎重になりすぎるくらいで良いかも！
お客様から示された作業内容や手順、納期、加えてこちらから連絡する内容の確認を他の方と一緒に行うことで、事故やトラブルを未然に回避できると学びました。

「イケイケ」で進んで失敗するときほど辛いものはないです。

# やっておいた方が良かった！と思うこと
ヘプタゴンに入社してから「やっておいた方が良かった！」と思うのはLinuxの勉強です！

実際の業務に触れてAWSの知識だけでなく、Linuxの知識も同じくらいに大事だと感じたので少しずつ勉強中です。

コマンドや基本的な構造の理解が浅すぎて絶賛苦しんでおります。。。

# おわりに
入社から半年経過して感じたことは「先回りして未来を想像することの大切さ」です。

この言葉はワタシが失敗した時に弊社代表の立花さんから頂いたものですが、とても大事なことだと思いました。

これができれば、物事の一歩先を想像して起こり得るインシデントに対する予防ができたり、対策に必要なことが先に準備できたりと考えてます。

クラウドエンジニアとしてのキャリアが始まってまだまだですが、失敗しながら、日々少しずつ成長すべく足掻いていきます。
エンジニア組織マネジメントのリアル 〜外部交流会から見えた課題と実践的な学び〜

この記事は[OPENLOGI Advent Calendar 2024](https://qiita.com/advent-calendar/2024/openlogi)の記事です。

## はじめに
先日、エンジニア組織のマネジメント層が集まる交流会に参加しました。参加者は主に、EM（Engineering Manager）やGM（General Manager）、VPoE（VP of Engineering）といったエンジニアリング組織の責任者をやっておられる方々でした。
BtoB、BtoC問わず多くの日本のSaaS自社開発企業が集まり、**開発組織のROI最大化**、**経営層/Biz側との意思疎通**、**チームトポロジー**、**開発生産性**、**エンジニア採用**、**エンジニアの評価と目標設定**、**育成とオンボーディング**、**セキュリティ対策**など、幅広いテーマについて情報交換・議論を行ってきました。

本記事では、その中でも印象的だったトピックやマネジメントの悩みをお伝えできればと思います。

## 1. 開発生産性の「見える化」とその先の壁

### Four Keysの導入と運用の悩み

デプロイ頻度、変更リードタイム、変更障害率、サービス復元時間、というソフトウェア開発チームのパフォーマンスを測る4つの指標が**Four Keys**です。
この言わずと知れたFour Keysですが、多くの企業が（全ての指標とまでは言いませんが）導入していることが分かりました。一方で、ほぼ全員が同じ悩みを持っていました。

**「数値は取れるけれど、どう活用すればよいか分からない」**  

導入の動機までは話として出てきませんでしたが、経営層や事業サイドからの要望もしくは、開発組織である自分達自身からの能動的な行動である可能性が高いと考えており、「**数値を出すこと自体が目的化してしまう**」という問題が発生しやすいものと推察できます。

以前、知り合いのテックリードは「Four Keysの指標は自分達の健全性を測定するためのもので、それ自体を自組織外に共有したり、数値目標にするのはおかしい」と言っていたのですが、まさにその通りだなと思う内容でした。

### SPACEフレームワークの課題

Four Keysとは別の視点で開発者の生産性を計測するための下記5つの指標の頭文字を取ったのがSPACEです。
- **S**atisfaction and well-being
- **P**erformance
- **A**ctivity
- **C**ommunication and collaboration
- **E**fficiency and flow

それぞれの指標を自社の合う指標に置き換える必要があります。例えば、「Activity」についてはPR数、コミット数、コード行数などがありそうです。

今回情報交換した企業では「Satisfaction and well-being」のみ計測しているところがほとんどでした。計測方法はアンケート形式が主流だったのも関係しているのか、次のような悩みを聞くことが多かったです。

- **人事部等が主導している組織サーベイが別にあって、その違いが分からない**
- **社員から「やる意味あるの？」と言われる**

### 指標導入の本質
- **トップダウンの限界**
指標導入は「上から与えられたもの」ではなく、チームや現場の当事者意識が伴わなければ、形骸化しやすいです。
- **熱量のあるリーダーシップ**
勉強会では、「指標導入を推進する熱意を持った人がチームにいること」が成功のカギだと何度も語られていました。熱意を持っているということは、それだけ導入する必要性を語ることができるという考えです。

## 2. 経営層との意思疎通

開発生産性の指標と並び、企業のVPoEやEMが共通して直面しているのが、経営層との意思疎通です。

### 合意形成の難しさ

なんといっても、経営層と「**開発の成果とは何か？**」の合意を取る必要があります。しかし、実際には「**成果の定義が曖昧**」であるケースが多く、前述の開発生産性指標も『**やれる範囲で**』になりがちだと感じました。

### 改善へのヒント

「成果の定義」について、ビジネス側とエンジニア側で継続的な対話が必要で、成果指標に対する「**経営層の納得感**」を高める仕組みが求められていると感じました。
開発組織だけで決めてしまわないように注意が必要ですね。

## 3. セキュリティ対策と経営層へのアプローチ
セキュリティ対策においては、経営層の理解度がある一方で、**費用面での壁**が多く議論されました。

### 現状のセキュリティ対策
**年に1回の大規模な脆弱性診断**を実施し、その後は開発案件のボリュームに応じて対策の判断をしているケースが多かったです。しかし、経営が厳しくなった時のコスト削減対象として一番最初に挙げられるのが**年1回の診断費用**という話も多かったです。

### 経営層との交渉ポイント
「**やらないと起こるリスク**」というネガティブな訴えより、「**やることで得られるポジティブな効果**」を伝える方が話が通りやすいという意見が多くありました。
例：「セキュリティ対策を行うことで、顧客からの信頼を得られ、ビジネスの競争力が高まる」など。

経営層も人なので、マイナス面による危機感よりプラス面の方が聞いてもらいやすいというのもありそうです。

## まとめ
今回の交流会はトピックありきでの交流会だったため、そこに課題を持っている人が集まっていました。主催者側の狙いとしては「うちはこうやっているんだけど、そちらはどうやってます？」というのがあったような気もしますが、実際は「どうすれば良いか分からなくて悩んでいる」人が多く、主催者側の狙い通りだったのかは気になりました。

さて、今回の交流会を通じて、エンジニア組織のマネジメントに共通する課題が見えました。

- 開発生産性指標は**導入後の活用**が大きな壁
- 経営陣との合意形成には、**成果の定義**と**納得感**が欠かせない
- セキュリティ対策は**ポジティブなアプローチでの交渉が効果的**

私自身も今回の学びを自社組織に活かしつつ、こういったリアルな課題に向き合う仲間たちと引き続き知見を共有していきたいと思います。

## 終わりに
同じ課題に直面している方や、うまく乗り越えた事例をお持ちの方は、ぜひ情報交換させてください！エンジニア組織の成長を支える取り組みを一緒に進めていきましょう。
Rust TUI

# Rust TUI

## GitHub
https://github.com/mniyk/rust-tui

## スクリーンショット
![スクリーンショット 2024-12-13 101519.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/498946/3cad57d4-7297-9be2-f6c5-91a6e4c8dc38.png)

## アプリ
- ブックマークアプリ
追加・修正・削除・ブラウザで開くの機能があります。
- スケジュールアプリ
Google Calendarを利用して、追加・修正・削除・ブラウザで開くの機能があります。
- タスクアプリ
Google Taskを利用して、追加・修正・完了・削除・ブラウザで開くの機能があります。
- VirtulBoxアプリ
VBoxManageコマンドを利用して、仮想マシンを開く機能があります。

## コメント
Rustを使用したTUIツールです。
TUIのライブラリには、ratatuiを使用しました。
最初は、公式ドキュメントを見ながら作成していましたが、ウィジェットやフォーム入力で詰まったりしていました。
ChatGPTも利用して、まだ未完成ですが、なんとか動くものは作成できました！
UIのモジュール化は、苦労しましたが、モジュール化もできました。
ChatGPTがあれば、Rustも書けてしまいますねー

## 最後に
今後は、以下を予定しています。
- GitHub Actionsを勉強して、実行ファイルを作成できるようする
- 設定画面を作成してBROWSER_PATHを変更できるようにする
セキュリティ関連の便利サイトまとめ

## 不審なurlの調査したい時

### FQDNに対する情報を得られるサイト

- [Abuse IPDB](https://www.abuseipdb.com/)
- [ReserchDomain Tools](https://www.domaintools.com/): Whois，DNS情報など
- [PassiveTotal](https://community.riskiq.com/registration)
- [the daily whois](https://dailywhois.com/): ドメインがいつ登録されたかわかる。最近登録されていると攻撃者が立てた怪しいサイトかも。
- [Sucuri siteCheck](https://sitecheck.sucuri.net/): webサイトにマルウェアがないか確認してくれる
- ~~[threatcrowd org](https://www.threatcrowd.org/)~~ 動かないので削除

### 閲覧代行ができるサイト

- [aguse.jp](https://www.aguse.jp/): urlやメールヘッダー等を分析し，関連情報を表示するサイト。
- [gw.aguse.jp](https://gw.aguse.jp/): 日本のIPアドレスをソースIPにして調査できるので国内のみにアクセス制限しているサイトに使う。
- ~~[Grab a web screenshot online](https://shrinktheweb.com/)~~: 現在使えないがaguseの類似サイト。
- [urlscan.io](https://urlscan.io/): Aguseよりも軽くて便利かも。
- [Rex SWains HTTP Viewer](https://www.rexswain.com/httpview.html): 応答画面やHTTPレスポンスを表示したりできる。
- [urlQuery](https://urlquery.net/): urlにアクセスしてレポートを作ってくれる
- [check-host](https://check-host.net/check-dns): 各国のIPアドレスからアクセスした時の接続状況を教えてくれる(国単位でのアクセス制限をしているか確認できる)。
- [Brosering](https://www.browserling.com/): Browseringが提供する仮想マシンにブラウザ経由でアクセスできるので実際にアクセスして動作を確かめられる。
- [PDF Viwer](https://www.pdfescape.com/open/): PDFを開くのに使う。

---

## Osint系

### crtsh

- 発行した証明書のログが公開されている。
- 公開されたwebサイトの一覧を作るのに使える。
  - ドメイン名にsslとかvpnとか入っていたらどういうサービスかわかる。
- 未発表のサービスのurlがわかるかも。新しいサービスには穴があるかも。

### have i been pwned?

- [have i been pwned](https://haveibeenpwned.com/)
- メールアドレスの流出情報がわかる。
- リサーチャーがサイトをクロールして作っているらしい。
- 認証基盤でリスト型攻撃かどうかを判定する材料の一つにしたりする。
- 月3ドルでAPIが叩けるようになる。

### shodan

- [shodan](https://www.shodan.io/)

- インターネットに接続されているデバイスについての機器・サービス情報を検索できる検索エンジン
- 対象: Webカメラ、ルータ、ファイルサーバ、メールサーバ等
- IPから推定した位置情報，ホスト情報，脆弱性，開いているport，古いバージョンのアプリを使っているサーバ等を探せる。
  - product:Apache # apacheを使っているサイトを探す
  - http.html:hoge # htmlからhogeを探す
  - port:22 # portでサーチ

#### メンバーシップがあるとできること

- CVEでの検索
- jsonファイルでダウンロード可能になる

---

## 文字列調査系

- [CyberSheff](https://gchq.github.io/CyberChef/): あらゆるエンコードデコードが可能。複数のエンコードデコードをレシピとして登録して一括で実行できるのが便利。
- [hashtoolkit.com](https://hashtoolkit.com/): ハッシュを入力するとデコードした文字列が登録されていないか検索できる

---

## マルウェア調査系

- [Virustotal](https://www.virustotal.com/gui/): 怪しいファイル投げると登録されているマルウェアか調べられる等
- ~~[malwares.com](https://www.malwares.com/)~~: Virustotalに近いサービスだが現在つながらない
- [HybridAnalysis](https://www.hybrid-analysis.com/)
- [Automated Malware Analysis- Joe Sandbox](https://www.joesandbox.com/#windows): Sandbox
- [TCP/UDP Port Finder](https://www.adminsub.net/tcp-udp-port-finder): そのポート番号を利用するマルウェア情報が見られる。

## 難読化解除

- [js-beautify](https://beautifier.io/): jsを読みやすくしてくれる。

---
viteのdev serverのdefaultで127.0.0.1が使えなく狼狽えた話

# vite.config.(js|ts)のhostが設定できる
- defaultはlocalhost
- 127.0.0.1では待ちうけしない(大事なのはここだけ)
- DNS解決は内部でするので /etc/hostsのエントリーしたドメインを記述するか127.0.0.1を設定すれば望み通りに動く
以上、解散


# 開発時にドメインをlocalhostにむけたい
開発時に本番でつかうドメインを自分のマシンにむけたい時があります
サーバからのredirectがブラウザにもどってくるときとか、GoogleのAPI Keyにドメイン制限がかかっていたりする時などです

こういう時、よくあるのは /etc/hostsとかにエントリーを書いてDNSの名前解決します

# viteのserver.hostのデフォルトはlocalhost
viteのdev serverはデフォルトでhostはlocalhostで待ちます
この設定のとき、127.0.0.1では待ちません(なんと)

# vite.config.jsを編集する
server.hostに127.0.0.1を設定します
(抜粋)
```typescript
  server: {
    port: 8080,
    host: '127.0.0.1',
    },
```
hostのところはlocalでアクセスしたいドメイン名でも構いません

```typescript
  server: {
    port: 8080,
    host: 'hogehoge',
    },
```

その上で /etc/hostsにエントリを書きます
- /etc/hosts
```
127.0.0.1       localhost
127.0.0.1       hogehoge
255.255.255.255 broadcasthost
```
これで、hogehogeがたちあがります
![スクリーンショット 2024-12-13 10.09.27.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2730381/1bd1f664-b557-7d2f-c323-4c15d53511c2.png)
/etc/hostsにドメインの記載をしないで立ちあげると、dev server起動時のドメインチェックで失敗するのでサーバはたちあがらないので注意してください


# まとめ
viteのdev serverで特定のドメインを使う方法でした
port 80使うならport設定を80にしてrootで起動するとか
SSLは認証鍵を他のところで取得して使うとかすればできますが、それはまたの機会で
最初localhostなんだから、/etc/hosts普通にいじればいけるでしょ、と考えてたら127.0.0.1でアクセスできなくて狼狽えた、ということでした
DRP-AI日記その2 Kakipを起動してみた

Kakipを起動してみました．

DRP-AIシリーズ・Kakip

- [DRP-AI日記その1 なぜDRP-AIシリーズに取り組むのか](https://qiita.com/zacky1972/items/3ebf021cab1e972890f8)

## 用意するもの

https://yds-kakip-team.github.io/techdoc/jp/2/

* Kakip本体
* 電源
    * DC12V/25W以上の出力
    * DCジャック（外形：φ5.5mm、ピン：φ2.1mm、センタープラス）形状のもの
* USB TypeA Hub (本体には2つしかないのでセットアップには足りません)
* マウス・キーボード(USB Type Aの有線接続のもの)
* USB Type A 接続のディスプレイアダプタ．次の2つが動作確認済とのこと
    * Buffalo GX-HDMI/U2
    * Wavlink WL-UG17D1 (私はこちらを購入しました)
* ディスプレイ
* micro SDカード
* イーサケーブル・有線LAN
* micro SDを読み書きできるPC

## macOSの場合のmicroSDカード書き込み

https://yds-kakip-team.github.io/techdoc/jp/2/2-1/

インストールのいらないこちらの手順にしました．

* [MacでOSイメージをSDカードに焼く](https://qiita.com/ishihamat/items/f1fb1f30327373dffac7)

`dd` コマンドの進捗を出すために，`status=progress` を末尾につけます．

* [ddコマンドの進捗を出力する方法](https://armadillo.atmark-techno.com/blog/15288/10423)

## 起動

https://yds-kakip-team.github.io/techdoc/jp/2/2-2/


[Kakipを使いはじめてみた](https://wasa-labo.com/wp/?p=1228#%25e8%25b5%25b7%25e5%258b%2595%25e3%2581%25ab%25e6%2599%2582%25e9%2596%2593%25e3%2581%258c%25e3%2581%258b%25e3%2581%258b%25e3%2582%258b%25e3%2581%25ae%25e3%2581%25a7%25e6%25b3%25a8%25e6%2584%258f)にあるように，起動には結構時間がかかります．

注意点として，2024年12月現在，次のIssueがありました(私が報告しました)．

https://github.com/Kakip-ai/kakip_linux/issues/1

## まとめ

今日のところは動作確認のためにただ起動しただけですが，別の整った場所に設置し直して環境を整えて，SSHでリモートログインできるように設定しようと思います．
Rの作図における色の取り扱いメモ


# はじめに
- 統計ソフトウェアRの色パレットの取り扱いのメモです。
- ggplotで作図をする際に色で悩むことが多いのでメモ書きします。

# 動作環境
- Windows10 64bit
- R (バージョン 4.0.5)
- RStudio (バージョン 2022.12.0)

# Rのカラーパレット
## 論文で使えるカラーコード

論文などで使える豊富なカラーパレットを備えたパッケージ"ggsci"が優秀。
カラーパレット一覧は[ここ](https://cran.r-project.org/web/packages/ggsci/vignettes/ggsci.html)を参照。

```r:R
# パッケージを取得
library(ggsci)
# 特定のテーマのカラーコードを取得（例：nejm）
pal = pal_nejm(alpha = 1)(9)
pal

# 取得したカラーコードを図で表示
library("scales")
show_col(pal)
```
![pal.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2708422/5909d34f-603c-7a75-159c-4ddc75b174da.png)



## デフォルトのテーマのカラーコード
デフォルトカラーを取得する関数を作ってくれている、[ここ](https://qiita.com/hoxo_b/items/c569da6dbf568032e04a)のサイトが参考になる。
```r:R
# 色テーマ(hue：ggplotデフォルトカラー)の関数作成
ggColorHue <- function(n, l=65) {
  hues <- seq(15, 375, length=n+1)
  hcl(h=hues, l=l, c=100)[1:n]
}
# 色サンプル（カラーコード）の作成
n <- 4 # 何分割の色にしたいかを決める
cols       <- ggColorHue(n=n) # 標準　n：色の数
cols_dark  <- ggColorHue(n=n, l=45) # 暗め
cols_light <- ggColorHue(n=n, l=85) # 明るめ
# 色サンプルのコード
cols
# 色サンプルのRGB値
col2rgb(cols)
# 色サンプルの表示
scales::show_col(cols)
```
![hue.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2708422/1bee28a4-5f52-216a-b2f0-c54cd073d69c.png)


- 手動で色の凡例を作成
色の種類が多い時など、標準の作図の凡例だときれいに表示しにくいときは手動で作ってしまえばよいこともある。
```r:R
# 例：都道府県番号（n=47）の場合
cols <- ggColorHue(n=47)
scales::show_col(cols,labels = NA, ncol = 47) # 横向きに図表示
```
![hue47.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2708422/df90c061-e2b3-0695-b072-7cbabffdfc87.png)


## カラーブラインド（色覚異常）を考慮したカラーコード
科学論文などでは色盲の読者を意識したグローバルカラーの使用が推奨されている。Ｒにはそれを考慮したカラーパレットのパッケージ"[colorBlindness](https://cran.r-project.org/web/packages/colorBlindness/vignettes/colorBlindness.html)"が存在する。
```r:R
# パッケージを取得
library(colorBlindness)

# パッケージを読み込むだけで様々なカラーパレットが使える
# 色サンプルの表示 例：paletteMartin
scales::show_col(paletteMartin)
```
![blindness.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2708422/57b60748-8296-d35e-3dba-1be26c01a5f1.png)



# カラーコードの参考になるサイト（Rとは関係ない）
- 様々なカラーコードを参照できる。

https://www.tagindex.com/color/color_gradation2.html

- 2色間の中間のカラーコードを調べるに役立つ。

https://photokit.com/colors/color-gradient/?lang=ja



# おわりに
Rでの作図における色選択の参考になる情報を載せました。
ほとんど、既存のサイトからの転載になっています。

# 参考文献
https://okumuralab.org/~okumura/stat/colors.html

https://qiita.com/hoxo_b/items/c569da6dbf568032e04a

https://cran.r-project.org/web/packages/ggsci/vignettes/ggsci.html

https://cran.r-project.org/web/packages/colorBlindness/vignettes/colorBlindness.html
テスト項目作成の課題と改善への取り組み

この記事は [**セゾンテクノロジー Advent Calendar 2024**](https://qiita.com/advent-calendar/2024/saison-tech) 14日目の記事です。
シリーズ2は [**HULFT10**](https://www.hulft.com/software/hulft-10) のエンジニアによる投稿をお届けします。

# はじめに
私はHULFT10プロジェクトでWindows版やLinux版などを開発するオープン系のチームリーダー(TL)を務めました。役割としましては、チームマネジメントに加え、設計書やソースコード、テスト項目のレビューを主に担当しました。プログラミングに関わる業務は多くありませんでしたので、今回はプログラミングに直接関わるようなものではなく、私自身が課題に感じている「テスト項目作成」に焦点を当ててみようと思います。なお、本記事は自動テストではなく手動テストについての内容になります。

# テスト項目作成にて発生する問題点
テスト項目の作成は意外に大変な業務だと感じています。観点を洗い出して、それを手順に落とし込んで、期待値を明確にする。こう書くとシンプルなのですが、実際にはいろんな壁にぶつかります。そこで、どんな問題があるかを振り返ってみようと思います。

##### 1つ目は「観点はしっかり書かれているけど、手順が曖昧」であるパターン
「こういうケースをテストする」という観点はきちんと書いてありますが、具体的にどうやってテストするかの情報が不足していることが多々ありました。結果、テスト実施者が「これはどうやって確認するの？」と迷う場面が出てしまい、作成者に確認が戻ってきてしまいました。

##### 2つ目は「手順は細かく書いているけど、観点が不明瞭」であるパターン
具体的な手順がきちんと書かれていますが、それがどんな観点を検証しているかが読み取れないものがありました。この場合、テスト項目をレビューする人が観点を一つ一つ洗い出す必要が出てきて、効率が悪くなりました。

##### 3つ目は「確認する期待値が曖昧」であるパターン
例えば「エラーメッセージが表示される」とだけ書いてあっても、それが具体的にどんなメッセージなのか分かりません。これだと実施者が結果を判断できず、作成者に確認が戻ってきてしまいました。

これらの問題は、スケジュールを理由にして細かく見直す時間を取らなかったことが原因にあります。「もっと丁寧にやりたかった」と思いつつ、特に手順と明確な期待値が用意できていない場合が多くて、テスト実施工程の負担にしてしまっている感がありました。

# 理想
本当はどうしたいかというと、以下の3つをしっかり整えたいと思っています。

##### テスト観点を明確にする
テスト観点に漏れがあるとバグの検出漏れに直結するため、テスト項目作成において最も重要なことだと思います。まず、観点とすべきポイントはどれで理由はなんなのか？洗い出されたポイントの組み合わせから本当に必要なパターンはどれなのか？を明確にすることで、レビュアが「漏れがないか」を簡単に確認できるようしたいです。

##### テスト手順を詳細に書く
観点から展開されたテストケースそれぞれに手順をしっかり書き込むことで、テスト実施者が迷わず進められるようにしたいです。但し、この件については悩ましいところがあって、どのレベルのテスト実施者に合わせた手順とすべきかは考える余地があります。本件でいえば理想はHULFT初心者でも困らないほど明確に書くのが良いですが、ではIT初心者でも困らないほど明確に書くのかと言うとそれはやりすぎだと思いますし、バランスが難しいところです。

##### 期待値を具体的に記載する
判定基準を誰が見ても分かるレベルで明確化したいです。曖昧な内容はなるべく避けたい。例えば、「処理が正常に終了すること」ではなく、「コマンドの終了ステータスが0であること」とか「『処理が正常に終了しました』というメッセージボックスが表示されること」のように。他にも「ファイルに出力される」とかもどのファイルに何が出力されるのか具体的に書くのが望ましいです。

# 今後の取り組み
では次回以降どうするのか。時間が無いなりに改善できるポイントを考えてみました。

##### テンプレートの改善
現在使用しているテンプレートはテスト観点と手順が混在して記載されることが多く、項目の構造が分かりづらい状態です。これを改善し、観点・手順・期待値の3要素を明確に分けて記載できるテンプレートに改善できれば、記載の統一性が向上し、作成者・レビュア・実施者それぞれの作業効率を高められると考えています。

##### ルールの周知
これまで、テスト項目が各個人の裁量が委ねられ、ルールが特に設けられていない状況でした。今後は観点と手順、期待値に関するルールを明文化し事前に周知することで、作成段階からルールを意識させます。この取り組みによりレビュー時点でのテスト項目の質を向上させることで、レビュー時の指摘箇所を減らし、且つ、妥協を余儀なくされるポイントを抑えられると考えております。

# まとめ
テスト項目作成は一見地味ですが重要な作業です。観点・手順・期待値、この3つを意識するだけで、みんなに優しいテスト項目が作れるのではと思います。今回のプロジェクトでは課題が残りましたが、それを次に生かしていくのが開発者として必要なことなので、限られた時間の中でも少しずつ改善していければと感じています。
読んでくださってありがとうございました。皆さんのテスト項目作成の一助になれば幸いです。
秋田に新拠点を作りました！

ジョブカン事業部のアドベントカレンダー17日目の記事です。

https://qiita.com/advent-calendar/2024/jobcan

今日は技術的な話ではなく、地方拠点のお話をします。（本当は技術的な話もしたいのですがまた今度！）


## はじめに
DONUTSでは、2024年3月より秋田県秋田市にエンジニアの拠点を新しく開設しました:clap:

私は車通勤ですが、駅・バス停が近く利便性の高い場所です！


## 秋田オフィスは何をする拠点？
秋田オフィスは、2022年に開設された札幌オフィス同様に、バックオフィス支援クラウドERPサービス「ジョブカン」、ライブ配信＆動画アプリ「ミクチャ」の開発を行う拠点です。

2025年1月に今の場所よりも広い場所にお引っ越しします！

## 誰がいるの？
現在は社員2名、インターン1名の計3名です。
これから入社される方も3名います。

始まったばかりの拠点で、まだまだ少ないですがこれから増えます。いや、増やします！


## ここで自己紹介タイム
ジョブカン勤怠管理の開発を担当している、@kazu1023です。

秋田オフィス1人目のエンジニアです。
Web、アプリ関係無く何でも作ります。

2024年3月は私しかいませんでしたが、気づいたら3人になっていました:open_hands:

そして、社内の流行には早めに乗りたいタイプですので、もちろん私も[新・RPGジョブ診断](https://rpg-shindan.wantedly.com/)やりました。

https://rpg-shindan.wantedly.com/result/gfkkk/

だそうです。


## 誰かっ...来てくれ...
とはいえ、3人はさみしいです。
何かあれば、他の拠点の方とチャットやWebミーティングで会話ができますが、やっぱり顔を見て会話したい...

そのため、私は採用担当ではありませんが、採用活動があれば積極的に参加しています。(呼ばれてもいないのに突撃することもしばしば...w)

実際に働く人の話を聞くことでもっと興味を持って貰えると思っています。


また、DONUTSは技術イベント「DONUTS Engineer Meeting」を定期的に開催しており、社会人向けの技術LTや学生向けの就活アドバイス等を発信しています。

https://waffles.donuts.ne.jp/2024/11/05/1019_engineermeeting/

第7回からは秋田拠点でも開催され、大盛況でした。
次回も秋田拠点で開催予定となります！

他にも、秋田オフィス独自のイベントをしております！
先日は当社の代表が秋田へ来て、学生さんに今後やりたいこと等をお話しするイベントを行いました。

## 今後何をしていくか
 - 地方を出た方が戻ってきても、高いレベルの仕事をできる環境(土台)を作る。 
 - 秋田に来た学生を秋田に留める。 
 - そのために学生インターンを増やし、地方での知名度を上げていく。 

DONUTSでは、エンジニアを目指す学生インターンに新規事業の開発を積極的に行ってもらっています。

学生のうちに、たくさんのユーザーが使うシステムを企画・開発することのできる環境はあまりないと思います。
ものすごくレアな体験になるはずです。

今後もこのような活動を行い、秋田に人を留める・人を呼び込む活動をしてまいります。


## 仲間を大募集中！
DONUTSでは、新卒中途を問わず積極的に採用活動を行っています！
自社プロダクトの開発で腕を奮いたい方、顧客への価値提供にやりがいを感じたい方、ぜひご応募ください！

地方で働きたい方、逆に都会で働きたい方、DONUTSはたくさんの拠点がありますので、住んでみたいところに応募するのもアリです！

https://www.donuts.ne.jp/recruit/

ジョブカン事業部のエンジニア募集はこちらです！

https://recruit.jobcan.jp/donuts/show/B001/1396297

秋田オフィスの詳細については、こちらもご覧ください:grin:

https://waffles.donuts.ne.jp/2024/09/02/localoffice_akita/
DiRTによる障害対応訓練のすすめ


この記事は[Hacobu Advent Calendar 2024](https://qiita.com/advent-calendar/2024/hacobu)の13日目の記事です。

## **はじめに**

2023年2月に株式会社Hacobuへ入社して、「MOVO Vista」というプロダクトのQAエンジニアを担当している村上です。

今回はDiRTというアクティビティを取り入れ、障害に備えた訓練を行ったので興味あれば読んでみてください！


## **DiRTとは**

DiRTは 「Disaster in Recovery Training」の略。

障害対応訓練と捉えてもらえれば大丈夫です。

意図的にシステムに障害を起こし、対応者がいかに早く障害を復旧させるかのプロセスを学習するプログラムとなっています。

## **取り組んだ背景**

Hacobuのサービスは下記記事にもありますが高い品質を保ち続けています。

https://hacobu.jp/news/11078/


それ故に本番障害の機会が少なく、インシデント対応のフローは存在するが実践したことのある人は少ないです。

このままではいざ本番障害が発生した時に、普段対応しているメンバーが不在だと対応や意思決定をすることができず復旧に時間を要してしまうと危機感を感じ、DiRTを取り入れました。


## **やったこと** 

今回は障害の直接的な対応よりも障害時のフローに注力したいため、本番障害が発生した体でDiRTに取り組みました。


#### 【DiRT準備～実施の流れ】

**事前準備**
- チーム分け（人数が多いため2チームに分けています）
- シナリオ作成（今回は2パターンのケースを作成しました）
    - インシデントリーダー(PdM/EM)が**いるときに障害が発生**し、インシデントになるケース
    - インシデントリーダー(PdM/EM)の**不在時に障害が発生**し、インシデントになるケース

**DiRT実施**
1. チーム、シナリオを割り振る
1. 下記の役割を担当する人を決める
    - 演習記録係　　　　　：DiRTの様子を第三者目線で記録する人
    - 本番障害検知者　　　：最初に障害を発見する人
    - インシデントリーダー：インシデント時の判断、旗振り等する人
    - インシデントログ記録：インシデントの作業、時間のログを取る人
    - 障害対応エンジニア　：原因追及、修正対応する人
1. シナリオに沿って実施

**DiRTふりかえり**
- 演習記録係が記録した内容を見返し、良かったところイマイチだったところをみんなでふりかえる



## **取り組んだ結果**
- インシデントリーダーの不在時のケースだと、旗振り、判断がなかなかできずに困っていた
    - 緊急時の判断に迷わないように、こういう時はこうすればいいよがわかるフローチャートも作成
- 普段対応してくれているとそうでない人で判断、行動の速度が明らかに異なっていた
    - インシデント対応は属人化しやすいよなーと思ったのと同時に、教える機会もあまりないのでDiRTいいなと感じた
- 1から準備～実施までやってみたが、避難訓練の大切さを改めて感じた(次に避難訓練の機会があったら真面目にやろ…)


## **さいごに**
メンバーからも「インシデントのフローを事前に知っておける良い機会になった」、「自分ごととしてインシデントに対して意識することができた」などやってよかったの声を聞いています。
問題が発生した時はできる人だけが対応するのではなく、みんなで解決していけるチームにしていきたいです。

また今回はフローだけの訓練でしたが、例えばQAの検証中に障害が見つかったらそれ起点でDiRTを開始しても面白そうだなーと思いました。（急に来るのでより緊張感がでそう）


本番障害時や緊急時に対して不安や懸念がある方はぜひDiRTを取り入れてみてはいかがでしょうか？
初投稿

# 初投稿

ポートフォリオをHTML/CSS/JavaScriptから、Reactを使用するように変更したついでに、アウトプットをコードにも行おうかと思い、Qiitaに記事を書くようにしてみます。

[ポートフォリオサイト](https://mniyk.com "MNIYK")

初投稿ですので、自己紹介から。

## Profile
### 誕生年
1987
### 出身地
鹿児島県
### 居住地
大阪
### コメント
現在は、離職し転職活動中です。
今のところ、カジュアル面談で全滅です！
プログラミングは、すべて独学です。

###　スキル
スキルは、ポートフォリオサイトを、ご確認ください。

## 最後に
プログラミングの実務経験も少なく、セキュリティの実務経験は0ですが、セキュリティ関連に進んでいきたいなと考えていますが、カジュアル面談で全滅では、難しいでしょう！とりあえず、頑張ってみますか！
【Android】アプリをGooglePlayにリリースする時の署名について整理してみた

## はじめに
自作のアプリをGoogle Play Consoleに登録して、内部テストをしようとしていましたが、その時に、Googleがアプリに署名してくれる「 Play アプリ署名」とGoogle Play Consoleにか自PCからアプリをアップロードする際に使用する「キーストアの署名」の違いがよくわかっておらず、大変な目にあったので、美貌の意味を込めて記事に残します

## 違いを理解しておらず困ったこと
自作アプリの特徴としては以下です。
1.  DBはfirebaseを使用
2.  自作アプリのログインはGoggleアカウント認証を利用

下の画像の対応関係を理解していなかったが故に
AndroidStudioのエミュレータでは問題なく動作していましたが、
GooglePlayConsoleから実機に自作アプリをインストールした際に、
**2のGoogleアカウントを利用したログインができない。** という事象にぶち当たりました。
![アプリ.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3760174/14982374-3743-f43f-15b8-a3a0434d2eec.jpeg)


## アプリからGoogle認証でログインする際の流れ

![アプリ (3).jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3760174/4394ebfa-b590-2211-04db-b130ce48d6ce.jpeg)

1. アプリでGoogleでログインボタンを押す
2. アカウントを選択すると、Googleのバックグランドで認証が実施
3. Googleが認証結果をトークンで返却
4. 受け取ったトークンをfirebaseに送付
5. firebaseでトークン結果を検証
6. firebaseが検証結果を返す
7. アプリ側で6の結果を元にログイン画面からホーム画面に遷移  


という感じだと思います。
この認証フローの時にもう一つ理解しておきたいのがアプリの**フィンガープリント**です

## Androidにおけるフィンガープリント
フィンガープリントはAPIプロバイダ（今回はfirebase）が接続してくるアプリの身分を確認するために使用されます（下の図でいうと、吹き出しに登録された内容とアプリが提示する内容が一致していれば通信を許可）

![アプリ (4).jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3760174/7e03cc53-e3f2-7604-e5c0-5d1f25d31649.jpeg)


firebaseにアプリ名とフィンガープリントを登録する画面
![アプリ (2).jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3760174/fbe0fe17-1888-d4f5-3bae-94d789a4cbb1.jpeg)

## リリース時にはフィンガープリントは２種類生まれる
それでは、AndroidStudioのエミュレータでは問題なく動作していたが、GooglePlayConsoleから実機にアプリをインストールした際に、**Googleアカウントを利用したログインができない。** という事象について、原因を考えてみました。

雑な図ですが、以下を見てください

![アプリ (5).jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3760174/9c2f5b4d-2ba8-e01d-9da3-48a1addcfa72.jpeg)

何となくお分かりでしょうか？？
そうです。GooglePlayConsoleからアプリをインストールすると、Google側がアプリに署名するため、firebaseにGoogleが署名するキー情報（フィンガープリント）を登録しなければいけないのです


> Play アプリ署名を使用すると、アプリ署名鍵の管理と保護、APK 配信時の署名を Google に委託することができます。App Bundle では、APK のビルドおよび署名が Google Play ストアで行われるため、App Bundle をアップロードする前に Play アプリ署名を設定する必要があります。

[Androidアプリの署名](https://developer.android.com/studio/publish/app-signing?hl=ja)


なので、GooglePlayConsoleのApp siginingからSH1のフィンガープリントを確認して、firebaseに登録してあげれば事象が解消しました！
![アプリ (6).jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3760174/b146cb22-ada6-5220-d7a1-fdfc1837b2ce.jpeg)

## おわりに
誰かの役に立てば嬉しいです。
誤り等あれば、ご指摘ください。
023 AI屋さんの　LLMに２００万トークン全文入力　GEMINI2.0



023 AI屋さんの　LLMに２００万トークン全文入力　GEMINI2.0



またまた、新しい大規模言語モデルが出ましたね。
ついて行くのも大変ですが、
早速使ってみましょう。
　Gemini 2.0 flash　と
　Gemini 1.5 flash　の
比較サイトです。
プロンプト少なめの　スッピン状態で　比較できます。

大規模言語モデルに　「覚りの境地」　を解説してもらいます。
いかがですかね。



https://st.bono0.com/gemini2


![スクリーンショット 2024-12-13 8.50.17.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/237930/b2d9c77b-5325-91cd-0f39-6ce87abf6b0f.png)


新しい機能など　盛りだくさんの
Gemini2.0ですが、
強化されたマルチモーダルなど　アプリケーション寄りの開発が充実していそうです。

公式純正アプリで　メジャーどころは全部やってくれそうです。
英会話教室くらいなら　デフォルト機能だけで
そのまま完成しています。

ますます、AI屋さんは　特定分野特化のニッチでスポット用途に
深く潜る方向かもしれませんね。





https://blog.google/intl/ja-jp/company-news/technology/google-gemini-ai-update-december-2024/


![スクリーンショット 2024-12-13 8.49.24.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/237930/fd0c8077-98c9-1dad-4ccd-24f104d665a8.png)


目次

https://qiita.com/bono0/items/dc1d000c98af7e07c9a7


今回も無事に
人工知能に　語ってもらえました。
新機能満載で　おめでとうございます。


ー続くー
未経験から始めたGitHub活用の基本と学び

## はじめに
今回下記アドベントカレンダーに参加したので、GitHubについて記事を書きたいと思います。

https://qiita.com/advent-calendar/2024/github

## あらためて私について
私は未経験からプログラミングスクールで学び始め、Ruby on Railsを中心に9か月間学習してきました。その間、Webアプリの開発を進める中で GitHub を使用する機会がありました。初めてGitHubに触れたときは、言葉の意味すら分からず、混乱することも多かったですが、今では基本的な使い方を理解し、プロジェクト管理に役立てています。

今回は、初心者目線でGitHubの基本的な使い方や学んだことを記事にまとめます。同じようにプログラミングを始めたばかりの方にとって、少しでも役立つ情報になれば嬉しいです。

## GitHubとは？
**GitHub** とは、ソースコードを管理するためのプラットフォームです。プロジェクトのコードをインターネット上に保存し、複数人で共同開発を行うための便利なツールです。  

初心者の私が最初に理解した重要なポイントを以下に挙げます

1. **バージョン管理**  
   過去のコード履歴を記録し、変更を追跡できる。
   
2. **共同作業**  
   他の開発者とコードを共有し、共同作業ができる。

3. **クラウドストレージ**  
   自分のコードを安全に保存しておける。

---

## 初心者が覚えておくべきGitHubの基本操作

### 1. リポジトリを作成する
リポジトリ（Repository）とは、プロジェクトを保存する場所です。GitHubでは以下の手順で作成します

- **GitHubにサインアップ**: GitHubの公式サイトにアクセスしてアカウントを作成します。
- **New Repositoryをクリック**: 自分のプロジェクトに合った名前をつけてリポジトリを作成します。

### 2. Gitコマンドの基本
リポジトリを作った後、ローカル（自分のPC）からGitを使って操作します。私が初めに覚えたコマンドは以下の通りです：

```bash
git init             # ローカルリポジトリを初期化
git add .            # 変更をステージング（記録の準備）
git commit -m "メッセージ" # 変更を確定
git push origin main # GitHubにアップロード
```

### 3.ブランチを使った開発
ブランチ（Branch）とは、プロジェクトの分岐です。本流（main）を変更せずに、独自の修正を加えるために使用します。
```bash
git branch feature-branch  # 新しいブランチを作成
git checkout feature-branch # 作成したブランチに切り替え
git merge feature-branch   # 完成したらmainに統合
```

## 実際に使ってみて感じたこと
### 1. ミスを恐れなくていい！

私は初め、間違った操作をしてコードを壊してしまうのではないかと不安でした。しかし、GitHubでは過去のバージョンに戻せるため、安心して作業できました。
ただ戻す作業は、場合によって意外と面倒だったりもします；；😢

### 2. プルリクエストの大切さ

他の人にコードをレビューしてもらう「プルリクエスト（Pull Request）」の仕組みを学んでから、自分のコードに自信を持てるようになりました。

### 3. コードが整理される

変更履歴がしっかり記録されるため、何をどのように修正したかを簡単に振り返ることができます。
変更履歴の存在を知る前までは毎回毎回一度作成したコードをメモにコピペして残していましたが、そんな必要はなかったことに気づきました:sweat_smile:


## GitHubを学ぶためのおすすめリソース（参考記事とか）
- **公式ドキュメント**
    [GitHub Docs](https://docs.github.com/)
    
- **初心者向けチュートリアル**
    [Progate Git学習コース](https://prog-8.com/)
    私が最初にGitHubを学ぶきっかけになったサイトです。
    
- **動画で学ぶ**
    YouTubeで「GitHub 初心者」と検索するとわかりやすい解説動画がたくさん見つかります。


https://qiita.com/wwacky/items/2f110ee76fc1cb681c3b

https://qiita.com/b150005/items/508009234bf9813b230f

https://qiita.com/SNQ-2001/items/0467aa99fb9430353e1b

https://qiita.com/peaceiris/items/d401f2e5724fdcb0759d



## さいごに
　私はGitHubを通じて「コードを管理する」という意識を学びました。最初は難しく感じましたが、何度も繰り返すことで自然に使えるようになってきました。この記事が、同じように未経験からプログラミングを学び始めた方にとって、GitHubの第一歩を踏み出すきっかけになれば嬉しいです！

これからもGitHubの機能を深く理解し、チーム開発にも挑戦していきたいと思います。
今一度基礎からアウトプットしていこう。ソフトウェア業界市場編

### 今やっているサービスは、一体何年前からあるものなのだろう？

・ソフトウェア業界の需要変遷
　1960年代～1970年代：メインフレームと業務アプリケーション
　1980年代：パーソナルコンピュータとオフィスソフトウェア
　1990年代：インターネットとクライアントサーバシステム
　2000年代：クラウドコンピューティングとSaaS
　2010年代：モバイルアプリとデータ分析
　2020年代：クラウドネイティブとAI、自動化、エッジコンピューティング


これらの単語について、ざっくり紹介。
##### メインフレーム
大型で高性能なコンピュータ。大量データと信頼性を必要とする業務で利用。
政府・銀行など。
##### クライアントサーバシステム
クライアント（ユーザ端末）とサーバ（リソースを提供する端末）で構成されたシステムアーキテクチャ。現代の主流ともいえる。
##### クラウドコンピューティング
サーバ、ストレージ、ネットワーク等のコンピュータ資源を、全てインターネットを介して利用できる仕組み。物理的な所有を必要としない。
##### SaaS
Soft as a Service。アプリケーションソフトウェアをインターネットを通じて提供するモデル。Slackとか。
##### クラウドネイティブ
クラウド環境を最大限に活用するために設計されたシステム。
##### エッジコンピューティング
データ処理を中央のサーバではなく、データが発生するデバイスやその近くで行う分散型コンピューティングモデル。IoTやネットワーク遅延の低減に役立つ。



##### 所感：
思ったよりクラウドコンピューティングが昔で驚いた。
調べるとAWSサービスの開始が2006年。
ちなみに私が直感で好きだと感じたのはエッジコンピューティング。
なんだか日本っぽい技術。
さあ、あなたが支えるサービスは何年目？
異なるタイムボックスを使い分けるモチベーションについて

この記事は、[適応型ソフトウェア開発 アドベントカレンダー 2024](https://qiita.com/advent-calendar/2024/adaptive-software-development) の 15日目です。

## day, week の使い分けの理由

適応型ソフトウェア開発において、もっとも重要なことは「最新状態」に常に追従することである。

そのため、あらゆる場面・さまざまな粒度での情報収集と「状態」の観測を徹底すること。

それこそが適応型ソフトウェア開発の肝心な部分である、マルチタスクを実現させるために大切なことだ。


## 状態の観測

PDSを適切に記載することは重要でない。

何度も記述している通り、最新の情報・状態を常に観測しつづけることが大切なことだ。

それが実現できるなら、正直PDSすら使用する必要はない。

適応型ソフトウェア開発には、「簡単なルール」しかないのだから。


### チームで適応活動をする
簡単なルールしかない状態で、自分たちにとって最適な方法を導き出す必要がある。

それはなかなか難しいことだ。

だから決まり手やセオリー・定石のあるスクラムフレームワークを採用することも多いと思うが、適応型ソフトウェア開発においては定石などない。

だからこそどうにでもなるし、どうすることもできる余地が残されている伸び代の多いフレームワークである。


### 大切なこと

自分たちの状態変化を徹底的に炙り出すためなら、どんな手段でも使っていく。

それが適応型ソフトウェア開発を進めるために大切なことだ。

この状態変化の数がチームの進捗度を示したり、案件進行を見える化することができる透明性につながっていく。

これが筆者の解釈した適応型ソフトウェア開発である。
プログラミング言語のキャッチアップで意識していること


# はじめに

この記事は「RUNTEQ Advent Calendar 2024」の 15 日目を担当しています。
今年のテーマは『プログラミングでの"ワクワク"』です。

私が『ワクワク』するときは学習経験のないプログラミング言語に初めて触れた時です。
今回の記事では私が触れたことのない言語の学習する際に心がけていることを語っていこうと思います。

# 前提

- メインとなる学習コンテンツについては特に言及しません。（書籍や動画、Web コンテンツなど）
- あくまで筆者個人の主観です、「この方法が一番！」というわけではございません。
- 学習効率や習熟度に関しては個人差があると思いますので、一つの意見として捉えていただければ幸いです。

# 一次情報のブックマーク

まず第一に信頼度の高い一次情報を取得できるサイト（公式ドキュメントやリファレンス）をブックマークしておきます。
私はプログラミング学習において一次情報の取得は不可欠だと考えています。
一次情報は読み慣れるまで時間がかかるものが多いので、見る習慣をつけることによって徐々に慣れていきましょう。

# 細かなアウトプット

天才などの一部の人を除いて、人類は一度書いただけでは覚えられません。
また覚えたことも反復しなければ忘れていきます。

私の場合は初めて使用するメソッドや概念、処理の流れなどを Notion にまとめています。
人の脳内ストレージには限りがあるので、インデックスだけを覚えておき中身はどこかに保存しておきましょう。
Notion などのデジタルでなくても情報がすぐに引き出せる状態であればなんでもよいと思います。

# 既存の知識との比較

私がよくやる方法の一つとして「この概念って〇〇だとどうしてたっけ？」という疑問を持つことです。
これをよく知る言語で例えることで、とても理解の助けになります。

そこで例として私が経験のある言語のうち、C 言語、Ruby、Java での NULL チェックを比較してみました。
C 言語 → Ruby → Java の順番で学習してきたので、その流れで説明していきます。

## NULL チェックとは

そもそも NULL チェックとは何のためにするのでしょうか。
「関数やメソッドを安全に呼び出すため？」
「ヌルポインタへのアクセスを防ぐため？」

色々理由はあると思いますが、この記事では「 `NULL` によって発生する例外を防ぐため」と仮定して進めていきます。

### C 言語

```c
if (name == NULL) {
  printf("name は NULLです\n");
}
```

一番オーソドックスな NULL チェックの仕方ですね。
変数 `name` が `NULL` であるかを比較演算子で確かめています。

### Ruby

```ruby
if name.nil?
  puts "name は nil です"
end
```

C 言語とは少し違いますね。
Ruby で扱える全ての値はオブジェクトなので NULL というものは存在しなく、代わりに `nil` が存在します。
また全てのオブジェクトは自身が `nil` かどうかをチェックしてくれる `nil?` メソッドを使用できます。

https://docs.ruby-lang.org/ja/latest/method/Object/i/nil=3f.html

#### ぼっち演算子

```ruby
# name が nil の時、 NoMethodError が発生
puts name&.size

# name が nil の時、nil を返す
puts name&.size
```

Ruby では `nil?` メソッド以外にも**ぼっち演算子**というものがあります。
これはレシーバ（メソッドの呼び出し元）が `nil` 以外の場合はそのままメソッドを呼び出し、 `nil` である場合は `nil` を返してくれるといういものです。
こちらを使えば `if` 文で条件分岐することなく実装できそうですね。

https://docs.ruby-lang.org/ja/latest/doc/symref.html#and

### Java

```java
if (name == null) {
  System.out.println("name は null です");
}
```

こちらは C 言語と似たような形ですね。

#### Optinal クラス

```java
Optional<String> name = "ほげほげ";

// 値が存在しなければ例外をスローする
System.out.println(name.orElseThrow());

// 値が存在する場合のみ処理を実行する
name.ifPresent(n -> System.out.println(n + "は存在します"));
```

Java には null を安全に扱うための型として `Optional` クラスが存在します。
サンプルコードの他にも `Optional#isPresent` で値の存在チェックができたりもします。

このように NULL チェックの方法ひとつをとっても言語の特徴などによって様々な違いがありますが、「NULL チェック」という概念を一度学んでいると「この言語ではこんなやり方ができるんだ」と認識するだけで理解の促進に繋げることができると思います。
パッと思い浮かばない時は AI に例えていただくのもよいと思います。

# おわりに

新しい技術を学ぶ際は「強くてニューゲーム」とまではいきませんが、今までの知識が役に立つことが大いにあると思います。
ぜひ今まで学んできた言語があれば、その言語との比較を行ってみてください。
これにより、リソースを言語特有の概念や仕組みに当てることができます。

また筆者は 1 月から実務で Python を使用するのでキャッチアップを楽しんでいきます！！
Pythonの標準出力をもう少し簡潔に綺麗に出力する方法

# はじめに
単純に`print()`を使うだけでもに十分のケースもありですが、少し工夫を加えることでより読みやすく、簡潔にコードを書くことができます。
この記事では、**`print`の便利なオプション**や**フォーマット方法**などわかりやすくまとめました。

## 1. `print()`の基本と`sep`・`end`の活用

### 複数の値を区切る文字列を指定する: `sep`
`print()`では、複数の値を指定したときにデフォルトで空白(スペース)で区切られますが、`sep`引数でこれを変更できます。

```python
print("Python", "Java", "C++", sep=", ")
# 出力: Python, Java, C++
```

### **出力の最後に追加する文字を指定する: `end`**
`print()`はデフォルトで出力の最後に**改行**を追加しますが、改行の代わりに`end`引数でカスタマイズできます。

```python
print("Hello", end=" ")
print("World")
# 出力: Hello World
```

## 2. f文字列で簡単フォーマット

### 変数名と値を同時に表示する: `変数=`
Python 3.8以降では、f文字列で変数名とその値を一緒に表示することができます。デバッグ時にも便利です。

```python
x = 42
y = 3.14
print(f"{x=}, {y=}")
# 出力: x=42, y=3.14
```

### オブジェクトの状態や特殊文字を表示する: `変数!r`
f文字列で!rを使うと、`repr()`による表現を簡単に挿入できます。
`repr()`は、オブジェクトを文字列として表現するための標準メソッドです。
repr()を使うことで、オブジェクトの状態や特殊文字を確認できます。

```python
# 文字列変数に特殊文字を含めた例
text = "Hello\nWorld"

# 通常の表示
print(f"通常の表示: {text}")
# 出力:
# 通常の表示: Hello
# World

# repr()による表示
print(f"repr表示: {text!r}")
# 出力:
# repr表示: 'Hello\nWorld'
```

### 数値のフォーマット
f文字列を使うと、数値を整形して表示することも簡単です。

#### **小数点以下の桁数を指定**
```python
pi = 3.14159
print(f"{pi:.2f}")  # 小数点以下2桁
# 出力: 3.14
```

#### **整数を特定の桁数に揃える**
```python
num = 7
print(f"{num:03d}")  # 3桁でゼロ埋め
# 出力: 007
```

#### **文字列の幅を揃える**
```python
table = {'John Smith': 10, 'Taro Tanaka': 20, 'J': 30}
for name, age in table.items():
    print(f'{name:15} ==> {age}')  # 名前は10文字分の幅を確保

# 出力結果
# John Smith      ==> 10
# Taro Tanaka     ==> 20
# J               ==> 30
```

## 3. まとめて複数行を出力

一度に複数行のデータを整形して出力したい場合、`join()`を使うのが便利です。

```python
lines = ["Line 1", "Line 2", "Line 3"]
print("\n".join(lines))
# 出力:
# Line 1
# Line 2
# Line 3
```

## 4. pprintで複雑なデータ構造を見やすく表示
標準の`pprint`モジュールを使うと、ネストされた辞書やリストなどの複雑なデータ構造を整形して見やすく表示できます。

```python
from pprint import pprint
data = {
    "users": [
        {"name": "John Smith", "age": 25},
        {"name": "Taro Tanaka", "age": 30},
        {"name": "Takeru Yamada", "age": 35}
    ]
}
pprint(data)
# 出力:
# {'users': [{'age': 25, 'name': 'John Smith'},
#            {'age': 30, 'name': 'Taro Tanaka'},
#            {'age': 35, 'name': 'Takeru Yamada'}]}
```
pprintを使わない場合だと一行で表示されてしまう。
```python
print(data)
# 出力:
# {'users': [{'name': 'John Smith', 'age': 25}, {'name': 'Taro Tanaka', 'age': 30}, {'name': 'Takeru Yamada', 'age': 35}]}
```

## まとめ
標準出力を少し工夫するだけで、コードがより読みやすく、保守性も向上します！ぜひ試してみてください。
スプリントレビューに変わるWeekly PDS

この記事は、[適応型ソフトウェア開発 アドベントカレンダー 2024](https://qiita.com/advent-calendar/2024/adaptive-software-development) の 14日目です。

## １週間で変化する「状態」を観測する

スクラムフレームワークでは、１週間の結果をスプリントレビューという方法で、透明性を持たせる。

それでは、適応型ソフトウェア開発においては、どうするのが良いか。

これもまた実はとてもシンプルである。それは、タイムボックスを１週間に合わせたプロジェクトデータシートを俯瞰する時間を作ることだ。

デイリーPDSのタイムボックスを変化させるだけである。

## プロジェクトデータシート

プロジェクトデータシートやタイムボックスについては、以下の記事を参照。

https://qiita.com/h-kinocoboy/items/c759e2cc47b3d5070a6a

https://qiita.com/h-kinocoboy/items/cd9ad55c1131198469e0


## チームでの取り組み方の事例

毎日観測し続けるデイリーPDSの結果をまとめるプロジェクトデータシートを新しく作り、整理する。

### 記載例
週間単位になるので、ある程度大きな粒度で会話する。


|タスク名|状態|現在の状態|次に目指したい状態|目指したい背景|
|-------|---|--------|---------------|------------|
|XXXについて学ぶ|学習|XXXのことをあまり知らない|XXXの提供方法を思案できる|XXXを顧客に提供したい|
|YYYについて思案する|思案|YYYのことを学び、調査した|YYYを協調して作れる|XXXを顧客に提供したい|
|ZZZについて協調する|協調|ZZZの方針が決定した|ZZZをリリースする|ZZZを顧客に提供したい|



またこのタイミングで、実際に動いているプロダクトやインタビューの結果など各自集めてきた情報をまとめて次の思案に向かうための方法を考える。

#### 頻度
このウィークリーPDSを眺める時間は、毎週30分実施し、集中して臨む。

その結果、意思決定が高速になり、案件進行が円滑になっていった。
Funding a Testnet Account

[Previous << Account Staking Info](https://qiita.com/flowcadence/items/f375c66dca0349f6b31f)
[Next >> Generate Keys](https://qiita.com/flowcadence/items/31669ba30375cd713c54)

https://qiita.com/flowcadence/items/3073d69c6e9895e68b5a#flow-cli-と-fcl

:::note warn
INFO
[Flow Testnet Faucet](https://testnet-faucet.onflow.org/fund-account)では、ユーザーはアカウントを作成し、テストおよび開発目的で1,000 Testnet FLOWトークンを受け取ることができます。また、このサイトやCLIを通じてアカウントを作成することなく、既存のTestnetアカウントに資金を供給することもできます。
:::

Flow CLI を使用して、有効な Testnet Flow アカウントに資金を供給します。
```ruby
flow accounts fund <address>
```

<h1>Example Usage</h1>

```ruby
> flow accounts fund 8e94eaa81771313a

Opening the faucet to fund 0x8e94eaa81771313a on your native browser.

If there is an issue, please use this link instead: https://testnet-faucet.onflow.org/fund-account?address=8e94eaa81771313a
```

<h1>Arguments</h1>

<h3>Address</h3>

* Name: `address`
* Valid Input: Flow Testnet account address.

Flow [account address](https://qiita.com/flowcadence/items/83d778f84f462cb43318) (prefixed with `0x` or not).

*Last updated on **Dec 17, 2024** by **j pimmel***

翻訳元

https://developers.flow.com/tools/flow-cli/accounts/account-fund

***



<b>Flow BlockchainのCadence version1.0ドキュメント (Funding a Testnet Account)</b>




***
<b>[Previous << Account Staking Info](https://qiita.com/flowcadence/items/f375c66dca0349f6b31f)
</b>

[Flow blockchain / Cadence version1.0ドキュメント](https://qiita.com/flowcadence/items/3073d69c6e9895e68b5a) (Funding a Testnet Account)

<b>[Next >> Generate Keys](https://qiita.com/flowcadence/items/31669ba30375cd713c54)</b>