OmniAICreator/Qiita-1.07M huggingface dataset:
【Django REST Framework】idをリクエストボディのパラメータに含めて送りたい

# はじめに
｀"ID"`をパラメータとして送りたかったが、なぜか欠落してしまったので備忘録として残しておきます。


# 問題
以下のようなjsonをリクエストで送信する場合
※こんなリクエストや以下の定義は送らないと思いますが、ご容赦を。。。
```json
{
    "title": "言って",
    "artist":{
        "id": 1
    }
}
```

**シリアライザ定義**
```python:serializers.py
class ArtistForSongRequestSerializer(serializers.ModelSerializer):
    class Meta:
        model = Artist
        fields = ["id"]

class SongRegistRequestSerializers(serializers.Serializer):
    artist = ArtistForSongRequestSerializer()
    title = serializers.CharField()
```

**エンドポイント定義**
```python
@extend_schema(
    request=SongRegistRequestSerializers,
    tags=["song"],
)
def post(self: Self, request: Request, *args: Any, **kwargs: Any) -> Response:
    """songs Regist API"""
    serializer = SongRegistRequestSerializers(data=request.data)
    serializer.is_valid(raise_exception=True)
    print(serializer.validated_data)
    # 省略
```

出力結果は以下の通りとなる。
```shell
OrderedDict([('artist', OrderedDict()), ('title', '言って')])
```
idが欠落してしまう



# 解決
### 原因：
シリアライザでは`id`を`ModelSerializer`では受け取れない。


### 対応：
シリアライザの定義を以下に変更する。
```diff_python:serializers.py
- class ArtistForSongRequestSerializer(serializers.ModelSerializer):
-    class Meta:
-        model = Artist
-        fields = ["id"]

+ class ArtistForSongRequestSerializer(serializers.Serializer):
+   id = serializers.IntegerField()
```
* `ModelSerializer`から`Serializer`に変更
* `id`を`serializers.IntegerField`で定義

この修正により出力は以下のようになる
```bash
OrderedDict([('artist', OrderedDict([('id', 1)])), ('title', '言って')])
```

IDが含まれました！
社内勉強会主催継続2年以上の経験者が語る❗️組織を圧倒的に成長させる社内勉強会の作り方

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

# はじめに
今年、株式会社クラウドワークスを退職した@nisyuuです。好きな戦闘機は[MiG-25](https://ja.wikipedia.org/wiki/MiG-25_(%E8%88%AA%E7%A9%BA%E6%A9%9F))です。
エンジニアとしてクラウドワークステック（旧クラウドテック）というフリーランスと企業をマッチングするエージェントサービスを開発していました。

クラウドワークステック開発チームの所属する部署では、チームの垣根を超えた勉強会を継続開催しており、アーキテクチャーやスクラム開発、開発生産性など多岐にわたるテーマを取り扱っています。
今回は、クラウドワークステック開発グループで行っている勉強会の取り組み方法について紹介します。
社内勉強会の取り組み方に悩んでいる方の参考になればと思います。

# 勉強会の立ち上げ方
どのようなイベントも同じだと思いますが、まずは主催者を募ることが必要です。
勉強会にはコンテンツ決めや、進め方の構成作り、司会者決めなど当日までに様々な作業が発生します。
主催者の人数が少なすぎると作業が多く負荷になる可能性があるため、ある程度人数が確保できていると開催しやすいです。
経験談になりますが、4人程度の主催者がいると進めやすかったです。
例えば、勉強会の司会進行、議事録係、勉強会お知らせ担当、アンケート作成者（アンケートについては下記で紹介）など役割を分担していました。

# コンテンツ作り
社内勉強会は輪読会だけでなく、動画視聴やハンズオン、ワークショップなど様々な取り組み方があります。
コンテンツが作りやすいものは輪読会や動画視聴で、Qiitaの記事やYouTube動画を教材として使用する方法があります。
ハンズオンやワークショップは、輪読会や動画視聴に比べて事前の準備にコストがかかりやすいですが、手を動かしながら学べるため理解度が深めやすいことと、取り組み方によってはチームビルディングに繋げられます。

## 輪読会について
輪読会では書籍を使用する手段もありますが、場合によっては参加者全員が書籍を購入する必要があります。
そのため、輪読会をするのであればQiitaやZenn、公式ドキュメントを教材にすると進めやすいのではないかと思います。

## 動画視聴について
YouTubeにはアーキテクチャの解説動画や、レコーディングされた外部の勉強会が公開されていたりします。
ただし、動画全てを流すと勉強会が長くなりすぎる可能性もあるため、必要なところを事前に選定しておくとスムーズに勉強会を進められます。

動画は画面共有で流す方法もありますが、ミーティングツールによっては上手くいかないこともあるため、その場合[SyncTube](https://sync-tube.de/)をおすすめします。

## ハンズオンについて
過去にチームでReactを正式採用したことがあるのですが、React経験者が一人しかいないということがありました。
良い機会であったため、ハンズオン式のReact勉強会を開催することでチーム全体のキャッチアップに繋げることができました。
新しいことに取り組む際は、ハンズオンが有効なキャッチアップの手立てになるのではなかと思います。
ちなみに、Reactのハンズオンでは[公式Reactチュートリアル](https://ja.react.dev/learn/tutorial-tic-tac-toe)を使を教材にしようしました。
codesandboxで動かせるため、ハンズオンにはもってこいのチュートリアルです。

## ワークショップについて
ワークショップは、スクラム開発でポイントの消化率を上げるために何ができるかをテーマに開催したことがあります。
準備に時間がかかるため一度だけの開催でしたが、エンジニアだけでなくデザイナーやPOも参加してディベートをすることができました。
日々の業務の中にある問題をワークショップのテーマにすると、ワークショップを通じて問題に対しチームで考えることができるのではないかと思います。

# 勉強会開催の仕方

## 当日まで
勉強会実施前に、対象者へお知らせをしましょう。
1週間前と実施前日にリマインダーでお知らせしておくと良いと思います。

## 当日
勉強会は30分程度で、長くても1時間以内が望ましいです。長時間になってしまうと対象者の予定が取りづらい他、定常業務に影響が出てくる可能性もあるためです。どうしても長時間になりそうであれば、数回に分けてシリーズ編として開催しても良いかもしれません。

# 工夫していたこと
勉強会では参加者全員が発言できることを意識していました。そのため、全員が意見や感想を共有できる時間を確保していたことと、人数が多くなりすぎないように参加者は同じ部署のメンバーに絞っていました。

参加者はエンジニアだけでなく、デザイナーやPO、業務委託の方にも参加してもらえるほどオープンにしていました。
あえてオープンにすることで、エンジニアだけでなくデザイナーやPO目線での意見を知ることができる他、チーム運用に関わるようなテーマだとチーム全体の良い学びの場となります。

勉強会は継続的に開催していたため、毎回アンケートを作成して感想や勉強会で扱いたいテーマを収集していました。
勉強会は様々なことに挑戦しブラッシュアップしながら進めていたため、アンケート回収は勉強会を継続開催するうえで大変参考にしていました。
また、アンケートの回収は勉強会の中で時間を確保して記入してもらっていました。時間を確保して記入してもらうことで、勉強会後にアンケートを提出してもらうより回収率が高い傾向にあったためです。

主催者については、参加するチームから一人以上募っておくと、チームごとに興味があるテーマや得意なテーマを知ることができる他、他チームで上手くいっている事例を学ぶことができます。

# おわりに
継続的に勉強会が開催できているチームは、それほどないのではないでしょうか。
これまで、受託企業にもいたため複数現場を経験していますが、勉強会を積極的に継続実施しているチームはありませんでした。
自律的に新しいことへ積極的に取り組む文化が根付いているため、アジャイルに挑戦できる方、挑戦したい方は楽しめる組織だと実感しています。
Be Ajile
【Amazon Athena】クエリ実行結果を探しても見つからなくて焦った話【AWS初心者】

# はじめに

Amazon Athena の実行結果は S3 に保存されます。

Settings から、クエリ結果が保存される S3 バケットを確認することができます。

![スクリーンショット 2024-11-29 12.12.35.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/325392/79a10aa7-de38-f727-e4c9-3a1008ec5de1.png)

バケットの中を見てみましょう。

![https___qiita-image-store.s3.ap-northeast-1.amazonaws.com_0_325392_c105c995-c061-7d7a-6370-b626fb15b41e.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/325392/bb1b0646-6639-e34a-7976-8673e3c97a15.png)

csv ファイルが大量に保存されていますね...

このように、何年も AWS を使っている企業などの場合、これまで様々な用途で使用されてきた Athena の実行結果が積み重なり、バケットの実行結果が溜まっていることがあります。

この記事は、このような状態でコンソールからクエリを実行したときに、実行結果を探すのに苦戦した話です。

# 実行結果を探した話 ~出題編~

先日、 AWS のコンソールから Athena でクエリを実行したときの話です。クエリの結果が S3 のどこに保存されているか気になったので探してみることにしました。

先述の通り、保存先の S3 バケットはこれまでの実行結果が大量に保存されているので、絞り込む必要があります。また、それぞれの実行結果のファイル名はクエリのIDになっていそうなので、クエリの ID が必要です。

![https___qiita-image-store.s3.ap-northeast-1.amazonaws.com_0_325392_c105c995-c061-7d7a-6370-b626fb15b41e.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/325392/bb1b0646-6639-e34a-7976-8673e3c97a15.png)

クエリを実行すると結果が表示され、URL が以下のようになりました。

```
https://ap-northeast-1.console.aws.amazon.com/athena/home?region=ap-northeast-1#/query-editor/history/4042xxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
```

このURLの末尾の `4042xxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx` の部分がクエリのID になります。

クエリのIDがわかったので、検索してみます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/325392/e827a495-5a3e-ccfc-850b-3c48ff1e99a3.png)

No matches... というわけで見つかりませんでした。

S3 バケットの直下にたくさんファイルがあったので、今回実行したファイルもそこにあるのかとおもっていたので、めちゃめちゃ焦りました。

# 実行結果を探した話 ~解答編~

ドキュメントをちゃんと読んだら、保存場所について記載がありました。

[Amazon S3 でクエリ出力ファイルを検索する - Amazon Athena](https://docs.aws.amazon.com/ja_jp/athena/latest/ug/querying-finding-output-files.html)

> ```
> QueryResultsLocationInS3/[QueryName|Unsaved/yyyy/mm/dd/]
> ```
> (略) クエリが実行されたものの、保存されなかった場合は、Unsaved が使用されます。

どうやら Unsaved フォルダがあるらしいです。

探したら見つかりました。ファイルが多すぎて、 `Unsaved` フォルダが見えなかっただけでした。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/325392/f82536bf-b58c-7718-b70a-550221ae8a1b.png)

Unsaved の中はこんな感じになっています。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/325392/bd26bf74-d6d3-8fc6-163e-c3618b74a2dc.png)

`Unsaved` ＋ 実行した日付 (今回だと `2024/11/28`) で検索したら、クエリIDが一致するファイルが見つかりました。

![9b8977.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/325392/a98c8cb0-ceef-3454-48df-2c3a73dcd1ad.png)

めでたしめでたし。

# おわりに

というわけで、ドキュメントをちゃんと読みましょう。

Amazon のドキュメントは多く、内容も初心者にとって難しいことが多いので読むのが大変ですが、慣れてきたら意外と便利だと思います。

Athena は AWS 関連のログ解析など様々な場面で活躍するので、AWSを扱っていく人は使い方を抑えておくとかなり便利だとおもいました。

この記事が、僕と同様にクエリの実行結果をうまく見つけられずに困った人に届いたら幸いです。
領域内のルーター

# 主な働き
>ルーター自身からAS内にあるすべてのルーターやネットワークへの最短経路を計算することである。

>領域境界ルーターは、そのルーターにつながっているすべての領域のデータベースを必要とする。

>領域ごとの最短経路アルゴリズムを別々に実行しなければならない

# 最短距離のバックボーンを通る
### 最短経路を選択される
>あるホストから宛先のホストへのルートを考える際は、領域内最短経路が選択される。

### バックボーンルーターを通らなければ宛先へは行けない
>領域を跨いで、あるホストから宛先のホストへのルートを考える際は、領域間経路はスタート地点となるホストからバックボーン・ルーターへと向かい、そのルーターを通って宛先を含む領域へ、そしてそこから宛先のホストへと向かわなければならない。

# バックボーンを中心にスター型になる
>バックボーンがOSPF上の中心に位置し、他の領域がその周辺に位置するようなスター型の形状を作る。

# 隣接ルーターの状況を確認できる
### ルーターはブートされると隣接しているルーターを調べる
>ルーターはブートされたとき、すべてのポイント・ツー・ポイントで接続された回線上にHELLOメッセージを送り、他のすべてのルーターからなるグループへLAN上で`HELLOメッセージ`をマルチキャストする。応答を受け取ることにより、`各ルーターは自分に隣接しているのが誰なのかを知る`。`同じLANに属するルーターはすべて隣接関係`にある。

### ルーター情報をまとめている指名ルーター
>隣接しているすべてのルーター間というわけではない。特に、LAN上のすべてのルーターがそのLAN上の他のすべてのルーターと通信するというのは効率が悪い。このような状況を避けるため、一つのルーターが指名ルーター(designated router)として選ばれる。このルーターは、そのLAN上ですべての他のルーターに対して隣接(adjacent)となるように選ばれており、それらのルーターと情報交換する。

### 指名ルーターにはバックアップルーターもある
>指名ルーターのバックアップ・ルーターが常に用意されており、指名ルーターがクラッシュした場合にすぐに対処できるようになる。

# 各ルーターが最新の状態を常に更新される
### 各ルーターは隣接ルーターに対して情報更新をする
>各ルーターは周期的にリンク状態更新(LINK STATE UPDATE)メッセージを各近隣ルーターへ送っている。このメッセージはルーターの状態を伝え、データベース内で使われるコスト情報を提供している。各メッセージは順序番号を持つので、あるルーターは送られてきたリンク状態更新情報がそれまで持っていたものよりも古いか新しいかを確かめることができる。ルーターは、`回線が開設されたり、切断されたり、そのコストが変化するたびに、これらのメッセージを送信`する

### 回線が開設された時にデータベース記述メッセージを送る
>データベース記述（DATABASE DESCRIPTION)メッセージは、`送信側が現在持っているすべてのリンク状態エントリの順序番号`を与える。受信側は、自分と送信側それぞれの順序番号を比べることで、誰が最も新しい値を持っているかを決定することができる。`これらのメッセージは回線が開設された時に使われる`。

https://bookplus.nikkei.com/atcl/catalog/23/03/16/00728/
API仕様書をレガシーなエクセル管理からOpenAPIに移行した話

## 概要
今回、2024年のアドベントカレンダーに投稿しようと思いこの記事を書いています。

https://qiita.com/advent-calendar/2024/works-hi-2?utm_source=Qiita+Advent+Calendar+2024+WHI%E7%99%BB%E9%8C%B2%E4%BF%83%E9%80%B2%E3%83%AA%E3%82%B9%E3%83%88&utm_campaign=e6b76b46fd-EMAIL_CAMPAIGN_2024_11_28_WHI&utm_medium=email&utm_term=0_641d36c151-e6b76b46fd-211412775&ct=t(EMAIL_CAMPAIGN_2024_11_28_WHI)

レガシーなシステムやツールに苦しめられているエンジニアはたくさんいると思います。
この記事ではAPI仕様書をエクセルからOpenAPIに移行した際、どのような観点を持って取り組んだかを書いていきます。参考になれば幸いです。

## 取り組むきっかけ
モダンなAPI仕様書の管理ではOpenAPIを使うことが多いかと思います。
しかしながら、色々な経緯で未だにエクセルによってAPI仕様書を管理してるケースもあります。OpenAPIを使うメリットとして以下が挙げられます

- フォーマットを揃えることが出来る
- モックを簡単に用意することが出来て開発効率があがる
- API仕様書通りに実装されているかtestで自動検知できる

私のナレッジとしてこれらのメリットを十分に理解しており、これを使って組織やチームに貢献したいという思いが取り組みの始まりでした。


## チームや組織としての視点と問題点
取り組みのバッドケースして、チームや組織という観点を見落としがちです。個人の経験談ではこれがベストと思っていても、チームとしての括りではどうか。チームではなぜ未だにエクセルでAPI仕様書を管理しているのか。
最初にAPI仕様書が作られたのは今から何十年も前でした。もちろんその頃はその方法がベストだったわけです。
まずはチーム内の色々な人にヒアリングをする事から始めました。

結果としては
- ドキュメント＝ワードorエクセルという既定路線があった
- 誰も改善する人がいないからなんとなくそのまま運用していた

という意見でした。え、意外とそんなものなの？！と驚くかと思いますが、レガシー問題の真相はここにあります。
結局のところチームの誰も手をつけたがらない＝他人事というのが真意なのです。

## 会社視点ではどうか
次に会社視点としてを考えてみます。会社の一員である以上、勝手に改善活動に動くわけには行きません（もしかしたらそんなフレキシブルな会社もあるかもしれないですが、、、）

- 移行スケジュールを建てる
- 必ずコストを比較する
- 事実をベースに提案をする

この3つは会社目線としてすごく大切になります。
特に既存のAPI仕様書の数が膨大な場合、移行にどのくらいかかるのか適正に会社に対して示す必要があります。
また提案には、個人的な感情は含めず、事実としてメリットやデメリットを示す必要があります。

今回のケースではAPI仕様書の数が多かったので、外部委託を利用する事にコスト削除する取り組みをしました。


## 移行手順の話
実際どのようにエクセルのAPIからOpenAPIに移行した手順です。

- エクセルのAPI仕様書からOpenAPI形式にツールを使って書き直す
- testを書きOpenAPIと連携し正しい形式が検証する
- お手本のPullRequestを作り外部委託と連携して数をこなす
- リプレイスが終わったものをEOLし告知する

### エクセルのAPI仕様書からOpenAPI形式にツールを使って書き直す
まず一旦、エクセルのAPIを見ながらOpenAPIに変換していく作業を行いました。[Stoplight Studio](https://stoplight.io/)というツールを用いてOpenAPIの実装を行いました。こちらのツールはUIで直感的にAPI仕様書の記載ができます。
![OpenAPI.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/174291/82d7df94-10d9-f464-d236-1cd37280a4dc.png)

### testを書きOpenAPIと連携し正しい形式が検証する
つぎにAPI仕様書が正しいかtestを使って検知するための仕組みを導入しました。
私の場合はRuby on Railsを使っていたので　[committee](https://github.com/interagent/committee) を使いました。
これにより、OpenAPI仕様書と実際のレスポンスが一致しているか検証できます。
RSpecに組み込む形で導入でき、一致していない場合RSpecが失敗するようになります。

### お手本のPullRequestを作り外部委託と連携して数をこなす
また大量にリプレイスが必要になるので手戻りが発生した場合大変な事になります。そこで、お手本となるプルリクエストを作成し、一旦チーム内レビューを行い、後はそれと同じように単純作業で進められるように外部委託に協力していただきました。

### リプレイスが終わったものをEOLし告知する
最後に、リプレイスが終わったエクセルに対しては何かしらでもうここには追記しないで欲しいという旨を示すことが大事です。またチームに対して告知する事も重要です。
これをしておかないと知らない人たちが無駄にエクセルにAPI定義を追加してしまうという元も子もない事が起こります。


## まとめ
このケースではAPI仕様書の話になりましたが、誰しもが働いていて「自分が知っている知識だったらこうするのに」という違和感を感じた事はあると思います。
もちろんレガシーな環境に文句を言うだけなら簡単です。（もちろん、このクソシステムは、、、とか愚痴は言いますよね。笑）
その次のステップとして、いかに行動に移すか、組織としての課題をいかに自分ごととして捉えていくか。
また自分だけでなく、チームをうまく巻き込んで問題の解消に動けるか。
レガシーな問題に取り組むにおいてはその視点がすごく大切になってくると思います。
レガシーな問題に取り組むのは勇気がいりますが、むしろ、この経験をもとに個人からチームや組織、会社視点を持つことによってステップアップできる。また貢献できる喜びを知るというところが大きいと感じています。
Nuxt + Vuetify + GitHub Pagesの爆速環境構築

https://github.com/GitHub30/nuxt-vuetify-github-pages-starter

<iframe width="560" height="315" src="https://www.youtube.com/embed/vrkbt1L4VJI?si=JaJnDjrOaPFN-1Cl" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" referrerpolicy="strict-origin-when-cross-origin" allowfullscreen></iframe>

NuxtとVuetify環境を構築するときに毎回調べてるので、簡単に開発環境を作れるようにしてみました。特に、個人開発では、開発から本番環境へデプロイするのに数週間、数ヶ月かかり挫折することが多いです。
これを使えば数クリックで本番環境へデプロイできモチベーションを維持することができます。

# 含まれている物

- Nuxt: `npx --yes nuxi@latest init --packageManager npm --gitInit .`
- Vuetify: `npx nuxi@latest module add vuetify-nuxt-module`
- GitHub Actions: https://nuxt.com/deploy/github-pages
- GitHub Codespaces: https://github.com/GitHub30/nuxt-vuetify-github-pages-starter/blob/main/.devcontainer/devcontainer.json

# 使い方

https://github.com/GitHub30/nuxt-vuetify-github-pages-starter にアクセス

## デプロイ

### 1. `Create a new repository`をクリック

![image](https://github.com/user-attachments/assets/8c55d303-c2f0-4ede-b83e-0f078fa49b98)


### 2. `Create repository`をクリック

![image](https://github.com/user-attachments/assets/24706f61-9e47-4783-b4e9-ddd80e0ba66f)


### 3. `Settings` > `Pages`に行く。`GitHub Pages`をクリック

![image](https://github.com/user-attachments/assets/79abdc10-104f-4af2-aaa1-ef619d2c3545)


### 4. `Actions` > `Deploy to GitHub Pages`に行く。`Run workflow`をクリック

![image](https://github.com/user-attachments/assets/9c133641-b2b9-4cd2-a076-0f8f4613c175)

`https://<username>.github.io/<repository>/`にアクセス

![image](https://github.com/user-attachments/assets/98211736-a675-4911-b7db-94800508ddfd)


## 開発

### 1. `Create codespace on main`をクリック

![image](https://github.com/user-attachments/assets/11c50783-cdf0-463e-9574-a805161beaa2)


### 2. `Open in browser`をクリック
  
![image](https://github.com/user-attachments/assets/1185559a-a202-4cd8-b482-d41983443ad5)
PHPで文字列を指定バイト数で切り出す方法

## はじめに

文字列を指定のバイト数で切り出す必要があり作成していたのですが、AIに聞いても想定する回答が返ってこずに苦労したため、備忘録として残します。

## コード

切り出す文字列は１文字ずつ削除しています。文字列が長い場合はパフォーマンスが悪くなるためご注意ください。

```php
// 文字列のバイト数を取得する
function getTextByte(string $text): int
{
    $textByteArray = unpack('C*', $text);
    $textByte = count($textByteArray);

    return $textByte;
}

/**
  * 文字列の先頭から、指定バイト数の文字列を切り出す
  *
  * @param string $text 切り出す文字列
  * @param int $byte バイト数。デフォルトは0
  * @param string $encoding 切り出す文字列の文字コード。デフォルトはUTF-8
  *
  * @return string 切り出した文字列
  */
function truncateByBytes(string $text, int $byte = 0, ?string $encoding = 'UTF-8'): string
{
    if ($byte < 0) {
        return '';
    }

    $truncatedText = $text;
    $truncatedTextByte = getTextByte($truncatedText);

    // 切り出すバイト数以下になるまで、最後の１文字を削除する
    while ($truncatedTextByte > $byte) {
        $truncatedText = mb_substr($truncatedText, 0, -1, $encoding);
        $truncatedTextByte = getTextByte($truncatedText);
    }

    return $truncatedText;
}
```

## まとめ

単純な文字数の切り出しは簡単ですが、バイト数での切り出しは少し面倒でした。バイト数は文字コードによって変わるため、その辺りも注意が必要です。

## 参考記事

バイト数チェックのサイト

https://sundryst.com/convenienttool/strcount.html


## 最後に

### GoQSystemでは一緒に働いてくれる仲間を募集中です！

ご興味がある方は以下リンクよりご確認ください。

https://goqsystem.recruit.site?qiita=7741744524981e830fe3
MQC (Modular QoS CLI) Overview

一般的に以下のような要件を実現するためにMQCを利用する。

- 音声 : IP 電話の遅延をなくすため絶対優先を行い、同時に帯域幅を埋め尽くさないようにポリシングを行う
- 映像 : 音声の次に優先すし、同時に帯域幅を埋め尽くさないようにポリシングを行う
- 管理 : ルーティングプロトコルなど、ネットワークの維持に使用する
- その他 : インターネットアクセスなど、OA 系のトラフィックのバッファリングを多く割り当てドロップが起きにくくする

## 入力方向の動作
### 信頼
Catlyst9kではデフォルトでDSCPが信頼され、特に明示的にマーキングをしない場合は着信時のDSCP値を保持してパケットを転送する
インターフェースを条件付き信頼ポートに設定することで、特定のデバイスからのパケットに付与されたDSCP値を信頼し、他のデバイスからのパケットに付与されたDSCP,IPP,CoSは0にリマークする
```
Catalyst9200(config-if)#trust device ?
  cisco-phone   Cisco IP Phone
  cts           CTS
  ip-camera     IPVSC
  media-player  DMP
  ```
※条件付き信頼ポートは1つのみ有効にできるため、ハブが接続されるポートでは注意が必要

### 分類
ACL,DSCP,ToS,CoS等を使用してパケットを識別する

### ポリシング
入力方向で帯域を制限可能。閾値を設定し、超過したトラフィックをドロップする。
バッファを使用しない為VoiPなどのトラフィックに対して有効で、逆にバーストトラフィックが発生するまたはTCP再送でレートが落ちるトラフィックに対しては設定が非推奨

### マーキング
Cos→DSCP、ToSへの値の書き込みまたは書き換え、Table-mapを使用したDSCP値の書き換えが可能
RFCでAFとEFについて定義されているため、これを参考に値をセットする

https://www.ietf.org/rfc/rfc2598.txt
https://www.ietf.org/rfc/rfc2597.txt

Cisco公式ドキュメントはこれ
https://www.cisco.com/c/ja_jp/support/docs/quality-of-service-qos/qos-packet-marking/10103-dscpvalues.html

## 出力方向の動作
### キュー構造

UADP ASICにてEQS (Egress Queue System) ブロックを使用

> UADPは有線LANと無線LANの機能を統合した初のチップということで、従来はそれぞれ別個に処理されていた有線LANと無線LANを統合的に扱えるようになることで効率が向上する
> 

EQSのコンポーネントは以下

- ポートキュー : パケットを同じ方法でグループ化して処理する、複数のキューがある場合はASICは次のパケットを取得し、送信するキューを選択できる
- ポートを物理キューに分割
- 全てのキューはパケットを保持するバッファとメモリを持つ
- ポートごとのキューは1~8個を可変で持つことができる

パケットがキューに割り当てられるとスケジューリングによりキューで送信順を管理する

Priority / express キューを優先し、非優先キューは輻輳を避けるためにWRR (weighted Round Robin)方式で送信される

### スケジューリング
WRRにより自動で実施される
CosやTos等の値が高いものが基本的に優先して送信され、値が低いトラフィックはドロップされやすい

### priority queue (優先キュー)

パケットが絶対優先キューにある時、WRRに割り込んで最優先で絶対優先キューのパケットを送信する
Cat3850/9000では2つのキューをPQとして設定可能

絶対優先キューが空になったらWRR方式によるパケットの送信を再開する

尚、WRR(の重み付けを設定することが可能で、それぞれのキューがどれだけの帯域幅でアクセスできるかを定義できる

### 分類
通常は入力方向で信頼、または書き換えたCoS,ToS,DSCP値で分類する
※出力方向ではACLによる分類は不可

### ポリシング
入力方向で帯域を制限可能。閾値を設定し、超過したトラフィックをドロップする

### シェーピング
キュー全体の帯域幅を制限する
ポリシングと異なり、閾値を超えたパケットをバッファリングしてバーストがなくなった時にパケットを送信する
CoS,ToS,DSCP等の値でドロップするパケットを選定するため、0（通常のデータトラフィックで使用される値）からドロップされる
今年合格した資格たち

# はじめに
Qiita Advent Calendar12日目らしいです。
記事の管理が難しくなってきている中盤です。
多分ですけど、時系列が右往左往している気もします。
ご了承ください。

# 資格勉強の必要性
今年の8月までは、資格取得の必要性はないと考えていました。
実力がない人がとるものだ、実務でなんの違和感もない状態で使えていたら、よい。と思っていました。

しかし、今年のキャリアコンサルタントの方の面談で、自分ははっきりとわかりました。
インプットすることが、アウトプットにつながるということです。

これは以前の記事でも触れたかもしれませんが、人にものを教えるとなると、何回も復習をする傾向があります。それは、人にものを教える立場の人間はその根本を本当に理解していないと、自信がなくなってくるからです。
復習は再学習のような形で、普段何の違和感もなく捜査しているQiitaの記事の画面でも
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3296700/4635f46a-2da1-2333-cdcf-93b7d55861e6.png)
これはなんですか。と聞かれてしまったら、自分は答えられなかったと思います。
そのように万全な体制を整えることが、資格試験ととても似ている部分だと思います。


# 取得した資格
・Tablau Desktop Specialist
・Smartsheet Core APP
・PL-900

# 来年取りたい資格
・サーバー系の資格
・基本情報
化野備「暴」録　第1回　消却の彼方

# 化野備「暴」録　第1回　消却の彼方

![biboroku.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3917696/15a77755-5ac1-c243-7bad-bc0ad857377b.png)


記念すべき第１回の投稿です！！
</br>
</br>

……が今回は**とある事件**が起きてしまい悲しかったので自分への戒め、またはこの記事を見てくださった初心者の方が同じ目に合わないようにと投稿をさせていただきます。
本来書こうと思っていた「**私のディレクトリやファイルの権限の変更方法**」は次回に書こうと思っています。

参考にさせていただいた記事は、当記事の下部に記載いたします。
この記事は初心者が初心者の方に送るための記事です。経験者の方は温かい目で見守ってください。
 </br>
 </br>

## 何が起きたか
私はただいまPHPやLaravelの勉強をオンラインスクールにてやっていまして、アプリ制作での流れを一通り学んだところです。
</br>
</br>
しかし、学習している途中で上述した「ディレクトリまたはファイルの権限の変更方法」を自分の判断で**管理者であるroot**で行った結果ディレクトリ内のファイルのすべてにロックがかかってしまい（大変申し訳ありませんがこの際にどのようなコマンドをどこでうったかの記録がございません）、その後root（sudoコマンド）でコマンドをうつとエラーが起きるようになり実行不可能になってしまいました。

そこでいろいろと調べまして、
</br>
</br>
1.su コマンドでrootのユーザーになる。
2.Ubuntuのリカバリーモードを起動し、パスワードを再設定する。
3.Ubuntuのすべてをアンインストールし最初からやり直す。
</br>
</br>

1.の方法をまず試してみようと思いましたが、
```:エラー
$ su
Password: 
su: Authentication failure
```
というエラーが出てしまいこれは「**ルートユーザー用のパスワードが設定されていません**」というエラーだそうです。rootのパスワードを設定するにはsudoコマンドをsuコマンドの頭に打ってくださいと様々な記事に書いてあったのですがそもそもsudoコマンドが使えなくなってしまったので本末転倒でした。
</br>
</br>
2．の方法も試してみましたが（再起動時にESCキーを連打しスタートアップメニューに入りそこから**GRUBメニュー**に入る方法）何度やっても私のPCではGRUBメニューを表示することができませんでした。
</br>
</br>
泣く泣く3.の方法ですべてを最初からやり直すすべしか私にはありませんでした:cry:
私はゲームオタクなので「**ゲームのデータがある拍子に消えてしまい最初からやり直す**」という身に覚えのある行動を思い出しました（技術の進んだ今現在でもバックアップデータが消えていたりして最初からやり直すことはあります…）
</br>
</br>
そして、私はもうこのようなことが起きないようあらかじめ1.で求められたrootユーザー用のパスワードを決めてしまおうという結論に至りました。
</br>
</br>
```:パスワード決定コマンド
$ sudo su -
Enter new UNIX password:      <= rootに設定するパスワード
Retype new UNIX password:Y    <= rootに設定するパスワードの再入力
passwd: password updated successfully
```
でパスワードを登録しました。
公式的には自己責任みたいなことが書いてありましたが、データが飛ぶくらいならやった方がいいです。

単元がもっと進んでいたり重要な時に起きたらと思うとぞっとします。まだ初学者の序盤の方でよかったです。
コードはGitHubにあげておくのもいいかもしれません。GitとGitHubの備忘録もまた今度書く予定です。

以下主な参考サイト様です。

https://qiita.com/YGocho/items/bcf5563bdfa971a1c0ef

https://gihyo.jp/admin/serial/01/ubuntu-recipe/0639

https://ameblo.jp/l-yotarou/entry-12707553598.html
Dockerのプランに変更に伴い、pull rate limit 制限が変更になるよ！って話

AWSで docker pull を利用していた際にこのエラーについて調べたところ
2024年12月のプラン内容変更でレート制限も変わるようなのでまとめてみました。
 
```
- Server message: toomanyrequests: You have reached your pull rate limit.
-  You may increase the limit by authenticating and upgrading: https://www.docker.com/increase-rate-limit
```

## エラー解説
Docker pullには6時間あたりの制限が設定されており、
特に無料で利用できるこの制限に引っかかっている人が多いと思います
（有料プランのユーザ制限はこの後に記載しています）
| 匿名ユーザ  | ログインユーザ  |
|:-:| :-: |
| 6時間あたり100回  | 6時間あたり200回  |

https://www.docker.com/increase-rate-limits/
 
## どうして制限が必要なのか
Docker公式の記事を引用すると
「1%のユーザが全体の30%のリクエストを利用している。残りの98~99%のユーザのパフォーマンスを下げる要因となっているため制限を設ける」という趣旨のことが書かれています

本文が気になる人はこちらの記事を見て下さい

https://www.docker.com/ja-jp/blog/rate-limiting-by-the-numbers/

## レート制限について
2020年から適用されているレート制限なのですが
2024年12月09日 のプラン内容の更新でレート制限も変更されるようです。
　
　
公式のURLはこちら

https://docs.docker.com/docker-hub/download-rate-limit/#public-pulls

https://www.docker.com/pricing/december-2024-subscription-changes/


実際に下記に書き出してみました


## まずは料金について

#### 現在
|   | 無料ユーザ  | Docker Pro  | Docker Team  | Docker Business  |
|:-:|:-:|:-:|:-:|:-:|
| ユーザー1人あたりの<br>月額料金（年間プラン）| $0  | $5  | $9  | $24*  |
| ユーザー1人あたりの<br>月額料金（月額プラン）  | $0  | $7  | $11  | $24*  |

#### 新プラン
|   | 無料ユーザ  | Docker Pro  | Docker Team  | Docker Business  |
|:-:|:-:|:-:|:-:|:-:|
| ユーザー1人あたりの<br>月額料金（年間プラン）| $0  | $11  | $16  | $24*  |
| ユーザー1人あたりの<br>月額料金（月額プラン）| $0  | $9  | $15  | $24*  |

*Businessプランは人数によって料金が変わる

## レート制限 & pull制限について
#### 現在
| ユーザタイプ | レート制限 | ダウンロード制限 |
|:-:|:-:|:-:|
| 匿名ユーザ  | - | 6時間あたり100回  |
| 無料ユーザ  | - | 6時間あたり200回  |
| Docker Pro  | レート制限なし  | 1日あたり5000回  |
| Docker Team  | レート制限なし  | 1日あたり5000回  |
| Docker Business  | レート制限なし  | 1日あたり5000回  |

#### 新プラン
| ユーザタイプ | レート制限 | ダウンロード制限 |
|:-:|:-:|:-:|
| 匿名ユーザ  | IP アドレスごとに 1 時間あたり 10 回  | -  |
| 無料ユーザ  | 1時間あたり40回  | -  |
| Docker Pro  | レート制限なし  | 1日あたり5000回(月2.5万回)  |
| Docker Team  | レート制限なし  | 1日あたり5000回(月10万回)  |
| Docker Business  | レート制限なし  | 1日あたり5000回(月100万回)  |

## レート制限 & pull制限の回避策
### 1\. プランをアップグレードする
匿名アカウントで利用している人はDockerのアカウント作成＆ログインすることでpullできる回数が2倍になります！

### 2\. コンテナイメージを同じ環境に保存する
AWSの場合はECR、GCPの場合はContainer Registryなどコンテナイメージを格納できる場所に公式からpullしてきて保存しましょう

https://repost.aws/knowledge-center/ecs-pull-container-error-rate-limit

https://cloud.google.com/blog/ja/products/containers-kubernetes/mitigating-the-impact-of-new-docker-hub-pull-request-limits

https://learn.microsoft.com/ja-jp/azure/container-registry/buffer-gate-public-content?tabs=azure-cli

## まとめ
実際に環境によってPHPやNginx Go etc...
とDockerイメージをPULLする回数と時間はマチマチなのでエラーが起きてからこの記事、このエラーを知る人は多いはずです

ローカル環境やクラウドサービス上での構築、リリースなどでこのようなエラーが起きると

**「今すぐ反映したいのに出来ない！」**
**「よくわからないけれどエラーが出た！」**

といったことが起こり得るのでこの機会にみなさん気をつけましょう！

ここまで見て頂き ありがとうございました！
[PL-900]Microsoft Fundamentalの勉強方法について理解したかもしれない。

# はじめに
Advent Calendar 2024 12日目
本日は、Powerautomate PL-900の資格を受験しようと思い、記事をためていたら、受かりました。
その勉強方法を書いていきます。

# Power Automateとは？

Power Automateは、Microsoftが提供するローコードの自動化ツールです。
これにより、プログラミングの知識がなくても、業務プロセスを自動化することができます。

便利なツールだったので、個人的なツールとしても導入可能です。
会社でMicrosoftアカウントを使用している場合は、一部機能を除き、使用することができます。

# 脳筋学習トレーニング
私が行っている勉強方法はMicrosoftのここのスコアを100%にするまでひたすらやり続けることです。
この方法を**脳筋手法**と呼びます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3296700/156035a8-ce5e-b0af-adf1-76f23bd31bc9.png)

この勉強方法の良いところは**キーワードとキーワードを一致させること**に意味があります。

例えばPower Automateでは、dataVerseという単語が出たら、モデル駆動型アプリという選択肢が9割以上正解になります。
単語と単語を紐づけることが、資格取得のコツだと思います。

# そんな学習法でいいわけがない

この勉強法が自分のためによくないと思う方もいらっしゃるかもしれません。
例えば、「そんな勉強方法では、覚えることができないだろう」、「そんな方法で実際にツールを作成することができるようになるのか。」などです。

# 結論
結論から言うと、この学習方法が時間効率が良いし、ツールは作れるようになる。

そもそもFuundamentalの試験には開発に必要な最低限のことを覚えることができればよいのです。
このような基礎的な問題では、わざわざひっかけて落とそうという問題ではないし、企業としてPowerautomateを使用する際に、このテストに出てくるのは、覚えていて当たり前だよということを教えてくれているのです。

# 数学をやるとき、公式を定義から導いていますか？
そういうことじゃないでしょうか。
PHPのUnitテストで、現在日時を自由に設定する

プロダクションコード側で、`new DateTime()` の代わりに `Chronos` を使って日付を生成すると、テストの中で、 `Chronos::setTestNow('2020-03-21');` を使って、テストの現在日時を設定できると教えてもらいました。これは便利！

https://zenn.dev/ttskch/articles/44d30281a8eee0

例：
- プロダクションコード
```php
function isInPeriod(){
        // 期間内判定
        return Chronos::now()->between(
            Chronos::parse(START_DATE), 
            Chronos::parse(END_DATE),
            true
        );
    }
``` 

- テストコード

```php
public function testIsInPeriod($testName, $testInput, $runOption, $expectedResult)
    {
        
        // 現在日時をテストケースに合わせて変更
        Chronos::setTestNow('2024-12-20 08:59:59');

        // テスト実行
       
        // テスト結果検証
      }  

```

### 余談
Chronosには、日付比較や日付の差分を求めるメソッドも色々あるようです。言語によって日付の計算は面倒な時があるので、助かります。

https://qiita.com/Gro/items/96f268a46c09136ba4dc
カジュアル面談で聞くこと10選(個人的)

# はじめに
Qiita advent calendar 14日目ですね。
本日は、実際に最近カジュアル面談を受けることになったので、
転職の前にやっておいた方が良いこと、やってよかったことについて記載していきたいと思います。

# 転職におけるカジュアル面談の位置づけ
カジュアル面談を行うIT企業が増えている理由は、リラックスした雰囲気の中で志願者の本質を見抜くことができるからです。
企業は緊張を和らげる環境を提供し、自由に質問に答えたり、褒めたりします。
その結果、志願者はリラックスしすぎて余計なことを話してしまうことがあり、これにより企業は適した人材とそうでない人材を見極めることができます。

   <h2>企業の視点から</h2>
    <ul>
        <li><strong>文化的適合性の確認</strong>: 志願者が企業文化に合うかどうかを早期に確認できます。</li>
        <li><strong>リラックスした環境</strong>: フォーマルな面接よりもリラックスした環境で、志願者の本来の姿を見やすくなります。</li>
        <li><strong>早期の関係構築</strong>: 志願者との信頼関係を早期に築くことで、採用プロセス全体がスムーズになります。</li>
        <li><strong>ブランドイメージの向上</strong>: カジュアル面談を行うことで、企業がフレンドリーでオープンな職場であることをアピールできます。</li>
        <li><strong>柔軟な評価</strong>: 志願者のスキルや経験だけでなく、性格や価値観も評価しやすくなります。</li>
    </ul>
    <h2>志願者の視点から</h2>
    <ul>
        <li><strong>企業文化の理解</strong>: 企業の雰囲気や働き方を直接感じることができ、自分に合うかどうかを判断しやすくなります。</li>
        <li><strong>リラックスした環境</strong>: フォーマルな面接よりも緊張が少なく、自分の強みを自然にアピールしやすくなります。</li>
        <li><strong>質問の機会</strong>: 企業について詳しく知るための質問を気軽にできる場として活用できます。</li>
        <li><strong>ネットワーキング</strong>: 企業の担当者と直接話すことで、ネットワークを広げる機会になります。</li>
        <li><strong>フィードバックの獲得</strong>: 面談を通じて、自分のスキルや経験に対するフィードバックを得ることができます。</li>
    </ul>
    

# 聞くことを決めたほうが良い理由
<strong>
・面接は準備が無限にできるため、競争が激しく、面接が上手な人が採用されやすい。<br>

・質問を考える過程で、自分が本当にやりたいことが見えてくる。<br>

・企業のマッチ度は会社説明である程度理解できるが、細かい条件の反映は遅い
</strong>

# 準備した逆質問
・この企業で働く上で一番魅力的な点は何ですか？
・どのようにして新しいスキルや知識を習得していますか？
・DX推進や社内IT化はどこが主導してやっていますか。
・規模が大きいとどのようなIT体制をとるのですか。
・社内SEとアプリケーション開発はどのくらい違いますか。
・どのような人材が不足していますか。

# 実際にできた逆質問
・どのような案件がありますか？
・〇〇管理とはどのような仕事なのでしょうか。
・貴社の強みはどこですか？
・この技術に興味があるのですが、どのような体制をとっていますか。

# 準備してカジュアル面談に挑んだ結果
1社目：しゃべりなれておらず、面接のときに、何を話せばよいかわからなくなってしまった。
2社目：しゃべり方・落ち着き方について理解をしたため、ゆっくりとお話しすることができた。

質問を考えていっても、実際に新しい情報や知らない情報を出されてしまうとわからないことも多かった。
そのため、逆質問は持っていくべきだが、カジュアル面談では情報の収集をメインにして行っていくことも大切なのだと感じた。
PhysiKyuの活動ってどんなの？ サークルメンバーの1週間に密着してみた！①

:::note warn
このカレンダーのどの記事の内容も学生個人の見解であり、所属する学科組織を代表するものではありません。
:::

# こんにちは！👋
九州大学物理学自主ゼミサークルPhysiKyuの2024アドベントカレンダー、1日目です！今日のテーマはPhysiKyuのメンバーの大学生活についてです！PhysiKyuメンバーの皆さんが普段どんな生活を送っているのか、気になりますよね 👀
というわけで今回は九大物理学科1年生の安成さんに密着させてもらい、普段の学校生活について伺いました！（取材日：11月27日）
ぜひ最後までお楽しみください！🎄

## 安成さんプロフィール
- 名前：安成温也（やすなりはるや）
- 所属：理学部物理学科1年
- PhysiKyu入会：2024年4月
- 参加中のゼミ：理論電磁気学、量子力学、解析力学
- 趣味：数学、物理、バドミントン

## 1日のスケジュール
その日によって変わりますが、大体の1日の流れはこんな感じだそうです！（忙しめバージョン）
| 時間帯      | 活動内容                                       |
|-------------|-----------------------------------------------|
| 朝7時頃     | 起床                                          |
| 1、2限      | 講義 or 実験                                       |
| 昼ごはん    | 学科の友達と食堂で食べる（おすすめメニューは理食の豚の角煮） |
| 3、4限      | 講義 or 自習（好きな自主スポットは中央図書館4階）         |
| 放課後      | 自主ゼミ or 英語ディベート                           |
| ゼミの後遅くなった時 | みんなで夜ご飯を食べたりすることも！                      
## インタビューしてみた！

#### ・自主ゼミの予習は大変ですか？
>楽しいですけど、大変でもありますね（笑）
僕は元々、数学が一番好きで得意な科目なのですが、1年生初期は数学的な部分でかなり苦労しました。
物理の本って、数学的論理（必要条件や十分条件など）を行間に任せながら議論を進めていく場合が多いんですよ。だから、ゼミの予習の時は、ゼミがある日までに、それらをすべて自分で証明しないと！っていう使命感に駆られて、ひたすら証明していました。でも、数学が好きな僕にとってはめちゃくちゃ予習楽しかったです！
でも、これが一番伝えたいことなんですが、ここが踏ん張りどころで、数学的にある程度大丈夫だなって思えるようになったら、1年の後期くらいから数学的議論に詰まらなくなってくるので、どんどん勉強が早く進むようになります！　だから、自主ゼミは1年生初期よりも今の方がたくさんしていますが、今の方が予習楽かもしれません（笑）
あと、僕はあまり質問したことないですが、PhysiKyuは学部生から院生まで、たくさん先輩がいるので、質問したら凄まじい速さでいろいろ答えてくれるので、かなり心強いですよ！

#### ・PhysiKyuに入ってよかったことは？
>入会前は、高校生のとき、一人で勉強をひたすらしていたのもあって、「これからも1人で周りをシャットダウンして勉強していかなければ！」と思っていました。なんか、これって天才感ありますし（笑）
でも、実はそうでないとPhysiKyuに入って実感しました。自主ゼミで仲間と議論すること自体、とても楽しいうえに、自分の考えを人にしゃべることで生まれる疑問などもあったりして、深い学びもできるんですよね。僕の中では、割と革命的でした（笑）
また、理学部物理学科の先輩たちとも、自主ゼミなどを通して仲良くなれて、いろいろ参考になる話も1年生ながら、たくさん知ることができたことも良かったです！
PhysiKyuにいたからこそ、自分と共通の興味を持った仲間にたくさん出会うことができて幸せです！

#### ・よろしければ、PhysiKyu以外の活動も教えてください。
>数学が好きなので、PhysiKyuとは別に火曜日の放課後に数学科の友達と数学の自主ゼミをしていて、そこでは集合論や代数学など完全に純粋数学をやっています。好きだからという理由だけで始めましたが、量子力学勉強しているときに数学的な考え方は意外と役にたってます！　
あと、僕は高校時代からずっと英語が苦手で、克服したいという気持ちで、英語ディベートをする部活に入っていたり、留学生のチューターをしたりしています。こちらでも、先輩や周りの人に恵まれて楽しく活動しています！

#### ・普段のやりがいや勉強のモチベーションはなんですか？
> 自主ゼミで仲間と議論することがとにかく楽しいですし、自分の担当の発表でみんなに自分の考えを伝えられることが、一番のやりがいかなって思います！
物理や数学は、大学になるとよりいっそう面白くなるので、それ自体が勉強の大きなモチベーションです！

#### ・最後に新入生や読者に向けて一言お願いします！
> 九州大学はとっても良い大学ですよ！

## 最後に
カレンダー1日目を読んでいただき、ありがとうございました！
PhysiKyuには、今回取材させていただいた安成さんのように、勉強熱心でとてもフレンドリー方々が集まっています！
これから１ヶ月間、PhysiKyuメンバーによる記事をお楽しみください！🎁
Raspberry Pi 5でPyTorchを動かす

## はじめに
Raspberry Pi 5で機械学習モデルを動かす際、特にPyTorchの導入の記事がなく苦労したのでPytorchを入れることができた方法を共有します。

## なぜMinicondaが必要なのか

Raspberry Pi 5は従来のRaspberry Pi 4と比べて、pipを使用したライブラリのインストールは、piwheelによるサポートの制限があります。
MinicondaをインストールすることでPyTorchがインストールできました。

## Minicondaのインストール手順

### 前提条件
- OS: 64bit版 Raspberry Pi OS

### インストール手順

1. インストールディレクトリの作成
```bash
mkdir -p ~/miniconda3
```

2. Minicondaインストーラーのダウンロード
```bash
wget https://repo.anaconda.com/miniconda/Miniconda3-latest-Linux-aarch64.sh -O ~/miniconda3/miniconda.sh
```

3. インストーラーの実行
```bash
bash ~/miniconda3/miniconda.sh -u
```

4. 環境の有効化
```bash
source ~/miniconda3/bin/activate
```

これでMiniconda環境の中で、pipをするだけでインストールができました。
## 重要な注意点

- condaとpipには互換性がなく混在させると環境が破壊される可能性があるため、どちらか一方を使う必要があります。私はpipのみを使用しました。

- NumpyとScipyをpipした後にPytorchをインストールしてください

## 参考情報

この記事の情報は2024年11月時点のものです。Raspberry PiやPyTorchの開発状況により、インストール方法が変更される可能性があります。最新の情報は公式ドキュメントを参照することをお勧めします。
TypeScript入門④Arrayオブジェクトのメソッド達

Arrayオブジェクトにはたくさんのメソッドが実装されている。
要は配列に対して、色んな操作を手軽に行えるということ。
毎回、配列に対してこんな操作したいなと思ってごちゃごちゃ調べてしまうことがあるので、
せめてイメージできるように一度しっかり網羅しておく。

# そのメソッドは配列を破壊する
破壊的、非破壊的という言葉がある。
破壊的なメソッドでは配列の中身が破壊・変化する。
元の配列ではなくなってしまう。

# これから使っていく配列
毎回これに対して操作を行う。
（それぞれの操作ごとに、配列をこの形に戻してやりなおす）
```typescript
let soldiers:string[] = [
    'ビッグボス',
    'オセロット',
    'クワイエット',
    'ヴェノム・スネーク',
    '和平',
];
```


# push
後ろから一つ追加する。スタックのイメージ。
```typescript
soldiers.push('イーライ') // イーライが追加
```


# pop
後ろから一つ出す。スタックのイメージ。
```typescript
soldiers.pop() //和平
```

# shift,unshift
shiftで先頭から取り出す
unshiftで先頭から入れる

```typescript
soldiers.shift() // ビッグボスを取り出し
soldiers.unshift('グレイ・フォックス')　//先頭がグレイフォックス
```

# slice
指定した範囲の要素を取り出して、新しい配列を作る
```typescript
soldiers.slice(開始位置、終了位置);
list: string[] = soldiers.slice(1、3); //オセロット～和平まで

```
書いていて思ったこととして、終了位置の要素は含まれないのか！ということ。
ややこしい。
つまりこの場合なら1番目から始まり、3番目は含まない。
ここは要注意点だと感じた。

# join
指定した文字で配列の中身を区切って連結。
```typescript
const kugiri: string[] = soldiers.join('!')
// ビッグボス！オセロット！・・・みたいに連結
```

# includes
指定した値が配列の中の指定したインデックスよりも後にあるかどうかの結果を返す。
```typescript
soldiers.includes('オセロット', 1); //true
soldiers.includes('オセロット', 2); //false
```

# some
配列の中に指定した要素があるかどうか。少なくともひとつあればtrue
```typescript
let result : boolean = soldiers.some(function(e) {
    return e === '愛国者達'
});

console.log(result); //false
```

# find, findIndex
findは配列の各要素に対して判定を行い、一番最初に合格した要素を返す
合格する要素がない時はundifinedを返すので、結果を入れる変数の型には注意。
```typescript
let result :string|undefined = soldiers.find(function(e){
    return e.includes('ヴ');
})

// ヴェノムスネークが返ってくる
```

findIndexは上記の値じゃなくて、値が入っている配列の番号を返す。
どちらも一番最初に合格した者。

# filter
条件に合格した要素で配列を作る
```typescript
let result:string[] = soldiers.filter(function(e){
    return e.includes('ト')
})
// ['オセロット', 'クワイエット']
```
非破壊的。
既存の配列自体には影響を与えず、新しい配列を作る。

# sort
破壊的。既存の配列に対して、その中身を入れ替える。

# map
各要素に対して加工用の関数を呼び出し、その実行結果で新しい配列を作る
```typescript
let result: boolean[] = soldiers.map((e)=>e.includes('ト')) 
// [false, true, true, false, false]
```


# indexOf
指定した条件の要素が配列の中にあれば、そのインデックスを返す。
なければマイナス１を返す。
```typescript
let result: number  = soldiers.indexOf('ヴェノム・スネーク');
// 3
```
ジャーナル破損したfsからデータを救出した話

## とりあえずそれっぽく前書き
前兆はあったんですけどね...
**ちゃんとバックアップは取りましょう**(自戒)

この記事はOSごと再構築することを決めたうえで逝かれてしまったファイルシステムからデータの回収に苦戦した話です
調べても同様のケースの記事が出てこなくて大変だったので備忘録がてら公開してみようと思います

またこの記事で発生した損害等の責任は一切負えません
全て自己責任で行ってください

環境はubuntu 22.04
ライブ起動に使ったのは debian11
vpsはcontaboを使ってます(コスパ最強)

カーネルバージョンは起動不可になってどう見ればいいかわからなかったので許してください
起動不可の状態でも読み取れる方法あれば優しい人教えてください....

## 一旦結論から
ファイルシステムのジャーナルがいかれてました
起動時にfsckが毎回走りますよね
その時に残っていた壊れたジャーナルを復元しようとしたせいでそこから進まなかったみたいです
```bash:bash
sudo mount -o ro,noload /dev/<device>
```
`<device>`にはそれぞれの環境のデバイスファイルを指定してください

これで読み込み専用かつ`noload`オプションを使うことでジャーナルを無視してマウントすることができます
これで内部のデータが吸い出せたのでデータを回収、そのデータを使いつつOSを入れなおして再構築して終わりました

ログは吸い出せていたんですがぱっと見めぼしい情報がなかったので突然サーバーが死んだ真相は謎のままです

## 簡単に状況
ある日突然サーバーが死んだというアラートが来ました
個人でしか使っていないサーバーだったのでのんびりどんなもんかなと確認するとブートログ？にrecovering journalという表示で固まっているようでした

## 試したこと

まずはvpsを契約してるサービスからdebian11のライブ環境で再起動

```bash:bash
sudo fsck.ext4 -v /dev/<device>
```
これで万事解決
と思いきやここでもrecovering journalの表示がでてOSごとフリーズ
どれだけ待ってもfsckが進まない状況に陥りました
そのまま待ち続けているとsshのコネクションも切れて新しい接続も受け付けないみたいだったのでライブ環境で再起動

手間かけさせやがってと思いながら今度は-f オプションもつけてやってみると
またまたOSごとフリーズ

```bash:bash
sudo fsck -v -n /dev/<device>
```

-nオプションを付けて実際には修復処理を行わないことでスーパー ブロックが壊れていることがわかりました
作業後に書き始めてしまったせいでどのようなエラーが出ていたか忘れてしまったのですが`super block checksum miss match`のようなエラーだったと思います

バックアップのスーパーブロックだとかを見つけ出してそれを使って修復しようとしたりもしたはしたんですが何も変わらず....

最終的に状況は違うものでしたが、ジャーナルを無効化して内容の読み取りができたという海外の記事を見かけたので試してみたら成功しました

## 終わりに
もともと知識のアウトプットとしてブログを書いたり成果物を作りたいと思っていたのですが先日とある方に背中を押されたので気楽にやって行こうと思います

かなり前の話をまとめたものなのでその時に参照した記事、実行結果の画像などが無くて申し訳ないです
私の場合はバックアップが一切なかったので、なんとか最初に上げたマウント方法でデータを回収し、サーバーを再構築して事なきを得ました
皆さんは**こうならないようにしっかりとバックアップを取りましょう**
Drone Birdの活動と二等無人航空機操縦者証明

##DroneBirdについて
　NPOクライシスマッパーズジャパンが行うドローンを用いて大規模災害時に迅速な状況把握等を目的として、現地の空撮を２時間以内に行うことを目標として現地の情報を取得し、それぞれの写真をつなげ合わせたオルソ写真を作成してCCB4.0で著作権フリーなオープンデータとしてな公開するというボランティア活動です。

##航空局の許可と免許
　ドローンを国内で飛行させるのに際して、航空法で定められているのは、許可を取ることと免許を取るということになります。（いちいち正式名称で言いません）許可と免許の違いについては、この記事を読んでいる人はそれなりに見ているか、見てない人で知りたい方はYouTubeで漁ってみてください。丁寧に解説しています。

##被災地の活動と許可・免許
　被災地でドローンを飛ばすという方は操縦者の方の中でも、かなり数に制限がかかるのではないでしょうか。
災害規模にも依存しますが、今年２０２４年に起きた能登大震災に関して、被災地の救助活動が行われるして区域では、ドローン飛行制限が期間を区切って実施されました。その場合免許や許可があったとしても、制限を受けますし、免許や許可を取るときに大規模災害があった場合は、飛行が制限される旨を注意されるのが一般的です。
　国土交通省から飛行制限に関しての発令がされる場合、「航空法第132条の92の適応をうけて飛行される場合を除き...」のくだりから飛行制限が発せられますが、いわゆる、国または地方団体もしくはそれに類する団体から公的な活動としてドローンの飛行による情報収取やその他目的に該当する業務として飛行を行うといった場合であります。

##災害協定の重要性
  DroneBirdの活動としては、許可・免許の視点からは被災地において２種類の活動パターンがあり、端的にいうと、被災地の自治体との災害協定を締結している上での活動が否かということです。つまり、冒頭に説明した活動を地元自治体との話合いにより、「被災地でこのような活動を行いますよ。はいわかりました。」となっている場合、航空法第132条の92に適応した活動となり、被災地でのドローン空撮が自治体の要請もされずにDroneBirdの隊員は空撮の作業が行えるということになります。
  他方で、自治体の災害協定が結ばれていない場合は、民間の業者と同じ条件となるために、許可・免許の範囲で市街化区域は飛行するといったことになります。よって、迅速に動くことができるか否かは、許可・免許の取得状況だけではなく、初動の速さでも大いに違うといったことになります。

　なら早く結べばいいじゃん
 となりますが、自治体の中には、上空から撮影した情報が町の状態を正確にわかり過ぎることに対して抵抗を持つ考えがある方もいらっしゃいますし、それは地域のプライバシーを配慮してほしい、または情報を出し過ぎない方が良いという考えからか、非常に気にしていることもあります。
 　DroneBirdで災害協定の締結をする場合にで写真の解像度を絶妙なわかりやすく人は判別しにくいクオリティとしているので、十分な説明を心がけています。

##免許が必要か否か
　YouTubeをご覧になっている方は、「免許は特段に必要なく許可で飛ばせるけど...」とご覧になっていると思いますが、空撮をチームで同じ機体を複数人がケースによって使用して飛行を行うには、許可申請が非常に便利です。１許可に登録機体１つまたは複数登録して、操縦者の登録を複数行えば、その許可の範囲ないで、全国で許可申請を行っていた場合に、その許可内容について尊寿しつつ飛行ができます。免許の場合は、一個人に対しての免許制度となっている為、ドローンの登録をその個人の免許に登録しておかなければ、その免許に基づく飛行可能は範囲での飛行とはならないという具合です。
 二等無人航空機操縦者証明を取得し、一等を取っても、先程述べた航空法の132条の93に適応された場合、許可申請が不要な飛行となりますので、免許があろうがなかろうが必要となっている飛行撮影業務となりますから無免許であれ無許可でも問題ありません。がしかし、災害協定を結ぶ際に実務として、どのような操縦車が登録・隊員となっているのかということは、当然として伝える情報であるので、まったくの素人が被災地で好き勝手に飛ばすと言ったことはDroneBirdの活動内で行われることはないでしょう。また、航空法第132条の92の適応を受ける際に、必ずその請け負っている団体の指揮命令管理下にいなければ、第132条の92は適応されません。
 総じて、結局いるかいらないかはYouTubeやネットで言っていることと変わりませんが、信頼という意味で様々な技能があるってことは素晴らしいよね。慣れてる人に飛行してもらいたいよってことは変わりません。
asdf の設定ファイル .asdfrc をつかってみた


[asdf]: https://asdf-vm.com/

## はじめに

[asdf] は、複数のプログラミング言語やツールのバージョンを統一的に管理できる便利なツールです。

[asdf] を利用する中で、設定ファイルである `.asdfrc` の便利さに氣づきました。

この記事では、`.asdfrc` の基本的な設定内容を整理し、学んだことを共有します。誰かの参考になれば幸いです。

https://qiita.com/torifukukaiou/items/9009191de6873664bb58

## `.asdfrc` の基本

[asdf] の設定ファイル `.asdfrc` は、デフォルトでホームディレクトリに配置する設定ファイルです。このファイルを作成し編集することで、[asdf] の動作を細かくカスタマイズし、自分の開発環境に最適化した使い方を実現できます。

以下はデフォルトの設定内容です。

```bash
legacy_version_file = no
use_release_candidates = no
always_keep_download = no
plugin_repository_last_check_duration = 60
disable_plugin_short_name_repository = no
concurrency = auto
```

詳しくは[公式ドキュメントの `.asdfrc` 設定セクション](https://asdf-vm.com/manage/configuration.html#asdfrc)を参照してください。

### 各設定項目の説明

- **[`legacy_version_file`](https://asdf-vm.com/manage/configuration.html#legacy-version-file)**  
  既存のバージョン管理ツールのファイル（例: `.ruby-version`, `.node-version` など）を参照するかどうかを制御します。`yes` にすると互換性を持たせられます。

- **[`use_release_candidates`](https://asdf-vm.com/manage/configuration.html#use-release-candidates)**  
  リリース候補（RC）のバージョンを使用するかどうかを設定します。

- **[`always_keep_download`](https://asdf-vm.com/manage/configuration.html#always-keep-download)**  
  ダウンロードしたアーカイブを削除せず保持するかどうかを指定します。

- **[`plugin_repository_last_check_duration`](https://asdf-vm.com/manage/configuration.html#plugin-repository-last-check-duration)**  
  プラグインリポジトリの更新頻度（分単位）を指定します。デフォルトは 60 分です。

- **[`disable_plugin_short_name_repository`](https://asdf-vm.com/manage/configuration.html#disable-plugin-short-name-repository)**  
  プラグインの短縮名を使ったリポジトリを無効化します。

- **[`concurrency`](https://asdf-vm.com/manage/configuration.html#concurrency)**  
  並列処理の設定を行います。`auto` にすると環境に応じた適切な値が設定されます。

## 既存のバージョン管理ファイルを活用する

これらの設定項目を理解した上で、次に僕が特に便利だと感じている `legacy_version_file` 設定について詳しく見ていきます。

プロジェクト内に `.node-version` や `.ruby-version` などの既存のバージョン管理ツール用ファイルがある場合、それらをそのまま活用できる便利な設定です。この機能は、`.asdfrc` 内で `legacy_version_file` を `yes` に設定することで有効になります。

以下のように `.asdfrc` を設定します。

```bash
legacy_version_file = yes
```

**ユースケース**:

- プロジェクト内で `rbenv` や `nvm` など他のバージョン管理ツールと [asdf] を併用している場合。
- 古いプロジェクトのファイルを `.tool-versions` に変換せずに活用したい場合。

ただし、[asdf] では `.tool-versions` を使用することが推奨されています。この設定は、既存プロジェクトでの一時的な対応策として活用するのが最適です。

詳細は[レガシーファイル設定](https://asdf-vm.com/manage/configuration.html#legacy-version-file)をご確認ください。

## 僕の `.asdfrc`

僕の `.asdfrc` 設定では、`legacy_version_file` のみを設定しています。この一つの設定項目で、既存のツールから [asdf] へのスムーズな移行が可能になり、プロジェクトごとの特性に合わせた柔軟な運用も実現できます。

これを設定することで、`.ruby-version` や `.node-version` といった既存のバージョン管理ツール用ファイルをそのまま活用できました。特に、古いプロジェクトをメンテナンスする際や、他のツールから [asdf] への移行作業を行う際に大きな助けとなりました。

## おわりに

`.asdfrc` は、[asdf] を使いこなすための重要なカスタマイズツールです。この記事を参考に、ぜひ自分の開発環境に合った設定を試してみてください！
僕の場合、特に `legacy_version_file` の設定が役立ちました。既存のプロジェクトをスムーズに移行したり、古いバージョン管理ツール用ファイルをそのまま活用できたりする点は、非常に強力で便利です。

この記事が少しでも参考になれば嬉しいです。また、皆さんの `.asdfrc` 設定やおすすめの工夫があれば、ぜひコメントで共有してください。
結局、OAuthってなにがいいの？

OAuth 2.0 について実装しながら仕様を学んできました。

https://qiita.com/k-koga/items/15a713184b300995976c

https://qiita.com/k-koga/items/b158f83c473b875a7d80

OAuth 2.0 の仕様理解はだいぶ深まったかなと思いつつ「結局、OAuthってなにがいいの？」という点について整理している情報があまりなかったので、OAuth 2.0 のメリットについてまとめてみました。

## 前提
説明するにあたり、例としてOAuth構成要素を下記とします。
- リソースサーバー：Googleカレンダー
- 保護対象リソース：カレンダー取得API、カレンダー更新API、カレンダークリアAPI
- リソースオーナー：自分
- クライアント：カレンダーアプリ（TimeTreeなどの3rdParty製アプリ）

## OAuth 2.0 のメリット
### 【メリット①】限定的なリソースへのアクセス許可ができる
クライアントへ限定的なリソースへのアクセス許可が可能な点がメリットの1つとなります。

例えば、カレンダーアプリをGoogleカレンダーと同期させる場合に「カレンダー取得API」へのアクセスだけを許可することができます。

そのため、カレンダーアプリが勝手にGoogleカレンダーの情報を更新したり、クリアしたりすることはできず、情報の取得のみができるように制限することができます。

### 【メリット②】クレデンシャル情報を渡す必要がない
クライアントへクレデンシャル情報（ID/PWなどの認証に必要な情報）を渡す必要がない点もメリットとなります。

例えば、カレンダーアプリへGoogleアカウントのID/PWを教えていないのに、カレンダーアプリはGoogleカレンダーへアクセスすることができます。

カレンダーアプリにクレデンシャル情報を渡す必要がある場合、もしカレンダーアプリが悪意のある攻撃者から不正アクセスされ自身のクレデンシャル情報を盗まれてしまうと攻撃者はその情報からGoogleアカウントへも不正アクセスができてしまいます。

OAuth 2.0 ではクライアントへリソースサーバーのクレデンシャル情報を渡さずに権限委譲が行えるため、クライアントが不正アクセスを受けたとしても、リソースサーバーへの被害を防ぐことができます。

### 【メリット③】一時的なアクセス許可ができる
クライアントへアクセス権を一時的に付与できる点もメリットとなります。

例えば、カレンダーアプリへカレンダー取得APIへのアクセスを許可した場合、カレンダーアプリはそれ以降ずっとGoogleカレンダーへアクセスし情報を取得することができるかというとそうではありません。

アクセス権には有効期限を設定することができ、その有効期限を迎えると、カレンダーアプリはGoogleカレンダーへのアクセス権が無効になります。

有効期限を迎えた場合は、再度リソースオーナーからアクセス許可をしてもらう必要があります。

### 【メリット④】アクセス権の剥奪が容易
クライアントへアクセスを許可した後、そのアクセス権の剥奪が容易に行えるのもメリットとなります。

例えば、カレンダーアプリへGoogleカレンダーへのアクセスを許可した後、やっぱり許可を取り下げたい、、となった場合は、いつでもアクセス権を剥奪することができます。

Googleアカウントの場合、管理画面でこのようにGoogleアカウントへアクセスを許可しているクライアントの一覧を確認することができ、ここからいつでも個別にアクセス権を削除することができます。

![Googleアカウント管理画面.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3733390/91345035-c9ee-13bb-2a6d-6cfc9cabc459.png)

### 【メリット⑤】リソースオーナーがその場にいなくても認可を継続できる
クライアントがリソースへのアクセスを行なう度にリソースオーナーによる認可操作の必要がない点もメリットの一つです。

例えば、カレンダーアプリにGoogleカレンダーへのアクセスを一度許可した後は、カレンダーアプリは一定期間自由なタイミングでGoogleカレンダー情報へアクセスすることができます。

カレンダーアプリがGoogleカレンダーの情報を毎ログインのたびに取得する仕様になっている場合、アプリへログインするたびに「カレンダーアプリがGoogleカレンダーへアクセスしようとしています、許可しますか？」なんて、確認してきたらめんどくさいですよね？

そのため、一度アクセス許可をしたクライアントについては、その後の一定期間は再度アクセスを認可する操作は必要ないようになっています。

---
以上です。

## 参考
- [OAuth徹底入門 セキュアな認可システムを適用するための原則と実践](https://www.amazon.co.jp/OAuth%E5%BE%B9%E5%BA%95%E5%85%A5%E9%96%80-%E3%82%BB%E3%82%AD%E3%83%A5%E3%82%A2%E3%81%AA%E8%AA%8D%E5%8F%AF%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0%E3%82%92%E9%81%A9%E7%94%A8%E3%81%99%E3%82%8B%E3%81%9F%E3%82%81%E3%81%AE%E5%8E%9F%E5%89%87%E3%81%A8%E5%AE%9F%E8%B7%B5-Justin-Riche-ebook/dp/B07L5M7DXS/ref=sr_1_1?crid=DMYM5QFVF1ES&dib=eyJ2IjoiMSJ9.l0ppouSWqjONIZHqQNq9D3vjt78yFuHdOPEstPf_O2vRF_EPfzb9ZyJ8rgzyi_f2_X1GkYO9OgQDe30x82ICHNKZFZg5sOvPM7o068YuW7A.fuYtAa4ECIVwJx6y10U2UbwUA7IO4fdCv3e4tVbjcAo&dib_tag=se&keywords=oauth%E5%BE%B9%E5%BA%95%E5%85%A5%E9%96%80&qid=1732958311&sprefix=OAuth+%2Caps%2C184&sr=8-1)
IT初学者に向けたマインドのお話

## はじめに
初めまして！ITスクールRareTECHにてCS（Customer Support）を担当している池村です！

今回のテーマは、「プログラミングを学習してIT企業に転職！稼ぎたい！リモートしたい！」という方向けに書いています。私の主観バリバリの記事ですので、全ての人に当てはまるものではありません。

:::note info
初学者に向けたマインドのお話で、技術の話ではありません。
:::



## なぜこの記事を書こうと思ったか
私はRareTECHというITスクールの運営責任者をしています。日々様々なお客様がカウンセリングに来てくれたり、スクールに入ってくれたばかりの受講生の方とお話することも多い役職です。その中で、少々気になる方が多かったのでこの記事を書こうと思いました。

今回のテーマは以下になります。
- 学習が続くか不安という方に向けて
- リモートワークで働きたいです！という方に向けて
- 簡単に稼げるんですよね？という方に向けて

## 学習が続くか不安という方に向けて
はい。そりゃ不安でしょう。
不安はどうにもなりません。ただ、不安を薄めるには行動するしかないというのは先人たちが何度も言っていることです。行動してください。勉強してください。私もいつどうなるかわからないので勉強はやめません。

今までかなりのエンジニア志望の方々を見てきて思っているのは、覚悟が決まっている人ほど結果を出すということです。

#### 覚悟の強さについて
私自身元々は他業種でしたが、IT業界に行くため元の仕事を辞めました。半年ほど仕事をせず、実家に土下座してしばらく勉強させてくれと言って安く住まわせてもらっていました。（親に感謝🙏）
辞める前に全く貯金がなかったので、退職までにとりあえず半年分生き残れる資金も作りました。

元の業種に絶対戻りたくないという意思はとてつもなく強かったです。今でも戻るつもりはさらさらありません。

全く違う業種に行くんです。念入りに計画をして損はありません。私は石橋を叩いて渡るタイプですが、世の中にはとりあえず飛び込んでみる！と言った超行動タイプの人もいます。これはどちらが良いというわけではなく、覚悟して飛び込むならどちらでも構いません。大半の挫折する人は、その業種で一生食っていってやるという覚悟が足りないんです。覚悟が決まっている人は不安があっても行動で解消していきます。

:::note warn
### 結論、腹を括ってください。
:::


![pose_kesshin_man.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3798971/1ea72db8-8b01-a6c1-cd62-d40a41169b60.png)


## リモートワークで働きたいです！という方に向けて
はい。リモートワークいいですよね！残念ながら自分は家で仕事するの嫌いです（笑）自分にとって家はリラックスする場所という認識が何十年も刷り込まれています。無理すればいけますが、わざわざ無理する必要はないので、基本的にはカフェとコワーキングで仕事と勉強をしています。

リモートワーク希望の人に聞きたいのですが、なぜリモートワークをやりたいんですか？

- 会社の人と余計なコミュニケーションをとりたくない
- 家族との時間を確保したい
- 満員電車に乗りたくない
- 自由な時間が多い

理由はこのあたりでしょうか？
まあ全て理解はできます。ただ、最初からリモートワークをしたいからという理由でIT業界に来るのはおすすめできません。そもそも企業目線からすると、社員にリモートをさせるメリットなんてほぼないです。本当に仕事をしているかどうかわかりませんし、コミュニケーション不足にもなりますしね。

#### リモートを希望します！
と面接で最初からいう方は、私だったら落とします。特に業界未経験かつ初学者の方ならもってのほかです。
リモートワークというのは、一つ働き方の柔軟性であって、会社にその制度を作る義務なんてないんです。セキュリティのリスク、社員が仕事をしていないリスク諸々あるんです。私はリモートワーク廃止論者ではないですが、リモートが持て囃されているのも謎だと思っています。本当に家で集中して何時間も仕事できますか？

まず0から1を達成する必要がある未経験初学者は、未経験を拾ってくれた会社に一生懸命貢献するべきです。その後辞める辞めないはその本人のキャリア形成ですから自由です。

:::note warn
### 結論、最初からリモートを希望するのはやめましょう。
:::


## 簡単に稼げるんですよね？という方に向けて
はい。違います。勘違いです。その認識がある時点でIT業界に来るのはやめましょう。
そもそもIT業界の知識習得は難しいです。インフラ、フロント、バック、セキュリティ等複雑な仕組みがさらに複雑にキメラ結合しています。基本を習得するだけでも年単位でしょうし、それを応用して様々なシステムやアプリを作るのはさらに時間がかかります。

:::note warn
### 結論、簡単に稼げるとは思わないでください。
:::


## 覚悟について再度
私はスクールの運営責任者をしていますが、ITの学習は独学でもスクールのどちらでもいいと考えています。ただ独学で学習するのは難易度がかなり高いです。そもそも全体像が見えにくい技術分野なので。だからと言って大金を支払ってスクール入った方が良いよとも言いません。

何度も言いますが、独学だろうとスクールだろうと、**覚悟**があればどっちでも良いんです。腹を括った人はなんでもできます。

#### 独学の方へ
初心者から独学でIT業界に入るにはかなりの努力が必要です。腹を括ってください。

#### スクールに入った方へ
お金を支払ったからと言って成功できると思わないでください。スクールは環境を用意してくれる場所であり、結局勉強するのは自分です。腹を括ってください。


## 終わりに
今回の記事では結構強いこと書いちゃったな〜と思いつつも、自分なりの経験から割と真理だと思っている内容です。結論、覚悟を決めた人は強いです。
家族がいるとか、仕事が忙しいとか、全部言い訳だと思っています。家族がいる人は説得してください。学習の先にある未来をうまく説明してあげてください。仕事が忙しい人、減らすか辞めるかいくらでも選択肢はあります。選択してください。

私が言いたいことは以上です。
最後に、我々のスクールのCREDOの一つをご紹介して終わりにします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3798971/4d0684da-abeb-bfe9-873f-d61bd06fe4c1.png)
M5StampS3、フィボナッチ数列で遊ぶ


参考


https://ichiken-engineering.com/arduino-uno-r4-minima_keisan/


x 過去ログを見よ
x ICHIKEN様のホームページの内容を非営利、研究調査目的で引用しました。


目的
整数のベンチマークする

結果

![o_coq665.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/840352/a272fe6b-783c-753e-f016-64e79be9d7d5.jpeg)

![o_coq667.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/840352/01ca614b-eed6-4b46-33f1-e17ca9cd2717.jpeg)



プログラム



```c++


//値が100,000を超えるまでのフィボナッチ数列を生成する作業を500,000回繰り返すのに要した時間を計測する。
#define DEBUG 0
void setup() {
  Serial.begin(9600);
  Serial.println();
  Serial.print("START");
  for(int i = 0;i < 9;i++){
    Serial.print('.');
    delay(500);
  }
  Serial.println();
}
void loop() {
  unsigned long x;
  unsigned long prevx;
  unsigned long temp;
  unsigned long start_time, end_time;
  unsigned long time;
  start_time = millis();
  for (unsigned long a = 0; a < 500000; a++) {
    x = 1;
    prevx = 0;
    while (x < 100000) {
      temp = x;
      x = prevx + x;
      prevx = temp;
#if DEBUG
      Serial.println(x);
#endif
    }
  }
  end_time = millis();
  time = end_time - start_time;
  Serial.print("END Value:");
  Serial.println(x); //最後の値の出力
  Serial.print("StartTime:");
  Serial.print(start_time);
  Serial.print(" EndTime:");
  Serial.print(end_time);
  Serial.print(" Time:");
  Serial.println(time);
  delay(1000);  //1秒待機
}



```
コメントと共にQiitaを楽しんでいます

# 概要
みなさんQiitaを楽しんでいますか？

Qiitaでは様々な記事が投稿されており、チュートリアル, ノウハウ, 失敗談など.. 内容は多岐にわたります 

私は調べ物をするときはもちろんですが、
暇な時間に適当な記事を読んでは「こんなこともできるんだなあ」とか「こっちの言語ではこう書くんだなあ」と、インプットにも満たないぐらいのエンタメといて楽しんでいます
<br>
最近は記事についているコメントも一緒に楽しんでいます。
むしろ最近はコメントを見るのが楽しくてしょうがありません。

そこで、この記事ではコメントに比重を置いた記事の楽しみ方を紹介したいと思います。

# コメント先行の楽しみ方
<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/100503/4ef471ac-881e-cd78-3740-7c058a3ff3eb.png" width=45%>

大まかにこんな感じです
自分の中である程度考えるポイントがあり、これも楽しみに深みを出してくれます
 - その記事が面白かったか, 役に立ったか
 - 自分で手を動かして再現できるか
 - 足りていない or 間違っている内容はないか

ただただこれだけなのですが、いろんな考えを知れる楽しさというか, 8番出口のような楽しさというか、流し読みしていた時とは違った楽しさがあります

# 記事の探し方
### 検索から探す式
1. 自分の好きなジャンルで検索
(なるべく多くの記事が引っ掛かるようにする)
![スクリーンショット 2024-11-28 20.30.05.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/100503/101bd154-0bad-c7eb-ebdd-02b66bbcf4ad.png)

2. 検索結果からコメントがついている記事を探す
![スクリーンショット 2024-11-28 20.36.19.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/100503/03764228-7237-7a59-720b-e365a6c193df.png)

### コメントをよく投稿している人から探す式
1. 対象ユーザーのページを開く
<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/100503/68bd839d-1244-a7c3-a16e-dada4ff973e4.png" width=60%>

2. `コメントした記事`タブを開く
![スクリーンショット 2024-11-28 21.33.38.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/100503/c4408186-a839-c890-8301-4a1232e7e8af.png)

3. 良さげな記事を開く

##### 素晴らしいコメントを残しているユーザーの皆様
自分がたまに覗いているユーザーさん達です
 - `@albireo`
https://qiita.com/albireo
 - `@scivola`
https://qiita.com/scivola
 - `@shiracamus`
https://qiita.com/shiracamus
....etc
***
***

それではみなさん良いQiitaライフを！
起業するならElixirシリーズSTEP1. 狼煙をあげろ

## 起業で失敗しないために知っておいてほしい3つのこと

「いつか起業したいんです」
「起業してお金を稼ぎたい」
「起業はかっこいい」
「週末起業を始めて、中国から仕入れた物を転売しているんです」
「起業したけど、失敗して借金160万円を抱えています」
「そろそろ、一旗揚げようと思って」

これらは、私がこれまでに様々な場所で聞いてきた「起業」に関するリアルな声です。

教材開発に携わってから「起業」に関わる人々と多く接し、成功者も失敗者も数多く見てきました。その経験から、成功と失敗を分ける大きな要因は、私なりに分析すると以下の3つに集約されます：

1. 売るものを先に仕入れる（または作る）
2. お客さんを探さない
3. すぐに諦める

細かな話は多岐にわたりますが、これらさえ避ければ失敗は防げます。よほどの不運や特別な事態が起きない限り、この3つを避ければ失敗することの方が難しいのです。

ただし、人間は認知の生き物です。あなたの認知パターンを変えない限り、この重要な話を100回、200回、いや1万回伝えたとしても、同じ過ちを繰り返してしまいます。

私は教育を専門としてきましたが、教育だけではどうにもならないと諦めるほどの事例がつい先日もありました。一度起業に失敗した人が再び起業すると言うのですが、すでに最初から同じ過ちを繰り返そうとしていたのです。

認知を変えることは非常に難しい課題です。素直な人は認知を変えやすいのですが、そうでない人は無意識でできるまでトレーニングする必要があります。

## 狼煙を上げろ

私は正直に言うと、中学生くらいから漠然と起業しようと考えていたタイプで、特に具体的にやりたいことがあったわけではありません。起業のきっかけは、三人目の娘が生まれたばかりの時に妻が病気になり、看病しながら子育てする必要から、会社員を続けることができなくなったことでした。

当時、EdTech系のスタートアップで2回目の資金調達も成功し、ストックオプションもそれなりにもらっていた矢先の出来事でした。

始発で出社し、終電で帰宅する毎日だったため、妻に大きな負担がかかっていたのでしょう。会社を辞めて家族の面倒を見ながら働く選択をしたのです。

全くの無計画な退職でした。管理職として働いていたため、プロジェクトマネジメントやディレクションはできましたが、IT技術は持っていませんでした。しかし幸いにも、eラーニングコンテンツのディレクション、カメラ撮影、映像編集などの経験があったため、eラーニング企業に助けていただき仕事を得ることができました。

それから数年、子育てをしながら会社を運営し、仕事と家庭の両立を図ってきました。9年ほど経過し、子供たちが自立し始めたのを機に、合同会社から株式会社に組織変更し、起業から9年目にして新たな挑戦の狼煙を上げることにしました。

これは、私が再び起業の狼煙を上げると共に、これから起業を志す人々への応援を込めた物語です。