OmniAICreator/Qiita-1.07M huggingface dataset:
mtr で｢おう､X11 入れなくていいってぇ!!!｣ってなったので(小手先で)なんとかした話

# 3秒でなんとなくわかる(小手先で)なんとかした箇所
```config:/etc/make.conf
.if ${.CURDIR:M*/net/mtr}
FLAVOR=nox11
.endif
```

# 概要
この記事は net/mtr を nox11 でビルドしようとしてぶち当たったことをまとめた記事になります｡

# きっかけ
```
スマホの Chrome でおすすめ記事に｢CVE-2024-43102｣に関するニュースを見る
↓
ちょうど 13 系を使ってるマシンがあったことを思い出す｡
↓
(^_^；)｢しょうがない､重い腰を上げてアップグレードすっか｣
↓
(^_^；)｢さて 14.1 にあげたことだし､パッケージアップグレードでもやっか｣
↓
(^_^；)｢(mtr に新しいバージョンがあったので make したら)おう､ X11 入れなくていいってぇ!!!｣ ← ｺｺ
```

# FLAVOR? 君はナニモンだ???
｢何事だ､どういうことだ｣と思い Makefile を覗いてみると x11 の文字列を探したら｢FLAVOR｣という謎の文字列を見つけます｡~~｢あぁ､キミのせいかぁ･･･｣と本気で思ったのは(真顔~~ FLAVOR が追加されたときの[コミットログ](https://cgit.freebsd.org/ports/commit/?id=4aeef9e30aca4af6377166b26fc99430f6a7db7b)に｢X11 option to x11 and nox11 flavors｣と書いているので｢パッケージを作るときに x11 用と nox11 用のパッケージが同時に出来るとか???｣と深読みしそうになったのは(いまいちよくわかってない顔

# ちょっと困ったのでなんとかした
流石に GUI で使う予定のない実環境でビルドしてる関係上それはそれでちょっと困ったので make.conf に追記しました｡
```config:/etc/make.conf
.if ${.CURDIR:M*/net/mtr}
FLAVOR=nox11
.endif
```
とりあえず make.conf へ FLAVOR に何をセットしていいか(nox11 の他に**別の値を含めていいのか**)などいまいちよくわからなかったので今は mtr 限定で設定を入れています｡

# と､ここまで書き終わってアドベントカレンダーに参加登録したあとの話
なんとなく過去の懇親会資料を漁りながら｢おぉ､[FreeBSD Ports Flavors](https://www.slideshare.net/slideshow/freebsd-ports-flavors/84695722) ってあるんですなー｣と思って見つけてから一言｡
```
＿人人人人人人人人人人人人人人人人人人人人人人人人人人人人人人＿
＞　え､7年前のネタだったんですか(記憶にあるようでなさそうな顔　＜
￣Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^￣
```

## スライド読みつつふとこう思う
普段から```make pretty-flavors-package-names```や```make FLAVOR=nox11```をやらない人からしたら｢おう､入れんでいい入れんでいい｣ってなったときぐらいしか Makefile を見る習慣がないので｢これも慣れていかなきゃいけないんだろうなぁ｣とは思いました｡
ちなみにスライドには｢portupgrade は未対応のようです｣と書かれていますが｢make.conf に入れておけば portupgrade でもビルドしてくれたりしてなー｣とか思ってみたり｡｡｡w(ちなみにまだアップデートが来てないので試すに試せない状況)

# まとめ
まだまだどんな値をセット出来るかいまいちわかっていない FLAVOR､ いろんなサイトで設定例とか入れてるところがあったらクリーンインストールするときに使おうと心に誓ったのは(ry
Workato：Pythonコネクタの制限事項

# はじめに
WorkatoにはPython, JavaScript, Rubyといった様々なローコードコネクタが提供されています。これらのコネクタを利用することで、Workatoコネクタのアクションとして提供されていない処理を、ユーザーサイドで使い慣れた言語を利用して実装することができます。

なお、これらのコネクタで実装したコードを実行する際は、次の制限事項に注意する必要があります。以下では、Pythonコネクタの制限について、補足を含めた形で記載します。

なお、Pythonに依存するライブラリ（モジュール）以外の内容について（特にメモリ周り）は、他のコネクタでも同様の制限は生じる可能性があります。このため、他のコネクタを利用する際もこれらの点を意識しながら開発を進められることをお勧めします。

# 制限事項

- **PDF files processed with the pypdf library must not exceed 35MB.**<br>pypdfでPDFを処理する場合は、35MBを超えてはならない。これを超えた場合はメモリ不足によるエラーで処理は中断する可能性がある。<br><br>
- **Scripts must not exceed 1MB. Larger scripts may cause memory issues.**<br>スクリプトは1MBを超えてはならない、超えた場合はメモリの問題が発生する可能性がある。<br><br>なお、Workatoに限らず1MBを超えるコードをWebブラウザ上のフォームフィールドにセットするとWebブラウザがクラッシュしたり動作が不安定となる恐れがあるため、あまり長すぎるコードの処理は推奨しない。もしコードの規模が大きい場合は、AWS Lambdaの利用を推奨したい。（PythonやRubyではこの上限を超える可能性は低いと思われるが、JavaScriptの場合はWebpackなどのバンドラーで1ファイルにまとめた際はこの上限に達する可能性があるため、特にJavaScriptで開発する際は注意が必要）<br><br>
- **Python snippets are limited to 256MB of total memory, including libraries, temporary memory, and inputs.**<br>Pythonコネクタは256MBのメモリ上限がある（コード以外も含めて）。<br><br>
- **CSV files processed with the Pandas library must not exceed 20MB. This limit accounts for Pandas’ temporary storage requirements.**<br>CSVファイルをPandasで処理する場合のファイルサイズの上限は20MB（これを超えてはならない）。これを超えた場合はメモリ不足によりエラーで処理が中断する可能性がある。<br><br>
- **Excel files processed with the Pandas library must not exceed 5MB. Uncompressing Excel files requires additional memory.** <br>ExcelファイルをPandasで処理する場合のファイルサイズの上限は5MB（これを超えてはならない）。これを超えた場合はメモリ不足によりエラーで処理が中断する可能性がある。<br><br>なお、PandasはExcelファイルを処理する際にopenpyxlを利用するため、openpyxlを利用する際も同様の制限が発生する。<br><br>特に、openpyxlは[ファイルサイズに対して50倍のメモリを消費する](https://openpyxl.readthedocs.io/en/stable/performance.html)点に注意が必要<br>※以下openpyxlのドキュメントより<br>*Memory use is fairly high in comparison with other libraries and applications and is **approximately 50 times the original file size, e.g. 2.5 GB for a 50 MB Excel file.** As many use cases involve either only reading or writing files, the Optimised Modes modes mean this is less of a problem.*<br><br>
- **Actions time out after 90 seconds.**<br>アクションの実行時間は最大90秒、これを超えた場合処理は中断（タイムアウト）する。<br><br>
- **User-provided libraries are not supported.**<br>ユーザー側でライブラリを追加することはできない。<br>（非公式ではあるが、以下の手順でユーザー側でライブラリを追加することは可能、しかし公式にはサポートしていないのと、今後利用不可となる可能性もあるため注意が必要）

https://qiita.com/tabimoba/items/e3dc2529248a90eaac8e

# 参考
https://docs.workato.com/connectors/python.html#usage-inspiration
VSCode ファイル選択の度に新しいタブで開く設定

新しい環境でVSCodeをインストールしたら、
ファイルを開いても同じタブに表示してしまって複数のファイルを見るのが面倒になった。

これまで使ってるVSCodeでは大丈夫だったのに。。

## 設定方法

1. `Ctrl + ,`で設定を開く
1. `Workbench > Editor: Enable Preview`設定をオフにする

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/224453/d5eb45a8-8e22-4a01-ddc1-0ac50b74c781.png)
非機能レビュー観点を作ってみた

イオンスマートテクノロジー CTO室QA の [show_chan](https://x.com/show_chan) です。
この記事は、[AEON Advent Calendar 2024](https://qiita.com/advent-calendar/2024/aeon)の8日目です。
# はじめに
皆様のプロジェクトにおいて非機能要件を定義できてますか？
非機能要件といえば、やはりIPA[非機能要件グレード2018](https://www.ipa.go.jp/archive/digital/iot-en-ci/jyouryuu/hikinou/ent03-b.html)ですよね。
これには可用性、機能・拡張性、運用・保守性、移行性、セキュリティ、システム環境・エコロジーの項目でチェックすべき、機能以外の側面を定義する要素が記載されています。

イオンスマートテクノロジーではこの非機能要件グレードを参考に、非機能レビュー観点を再編したのでその作成方針をご紹介します。

:::note
非機能要求グレードとは
「非機能要求グレード」は、「非機能要求」についてのユーザと開発者との認識の行き違いや、互いの意図とは異なる理解を防止することを目的とし、非機能要求項目を網羅的にリストアップして分類するとともに、それぞれの要求レベルを段階的に示したものです。重要な項目から順に要求レベルを設定しながら、両者で非機能要求の確認を行うことができるツール群です。
:::

# なぜ？
さすがIPA！。活用シートの内容は非機能要件の完全版です。
さて、これを既に安定稼働しているシステムやサービスに改めてチェックを行いインフラ構成から見直すか？と言われるとプロダクトオーナー、エンジニア、ベンダーのみならず、総務やその他いろんな部署を巻き込んで埋めていくこととになります。ちょっと大変。
内製化開発というお題を持つ弊社で非機能要件としてこの活用シートを全てのプロダクトに導入していきたいと思っています。が、まず要件定義を行うタイミングで機能要件と対になるチェックとして利用できるものを作成することにしました。

# 必須の非機能要求６項目
非機能要求グレードで分類される6つの項目は非機能の根幹です、ここを外してしまうと何をやってるんだっけ？という感じになってしまいますので、改めてこれらの項目について何を必要とするのか？を確認しておきます。

### 可用性
システムを継続利用するため稼働時間や停止運用の要件。IT-BCPも含まれています。大部分をAzureで運用しており機器関連に関しては不要にできます。

### 性能・拡張性
システムの処理性能や拡張の要件。構築するシステムの利用ユーザー数、アクセス負荷を定義します。通常時、業務量増大時などでも確認が必要です。イオンではお客様感謝デーという業務量増大時があるため非常にわかりやすいです。

### 運用・保守性
システムの運用・保守に関する要件です。システムの監視方法やバックアップ方法、問題発生時の体制などを決めておきます。これらは既存で存在しているものを利用します。

### 移行性
現行システムからの移行に関する要件です。新システムへ移行が直近にない場合は優先度としては高くないです。

### セキュリティ
システムのセキュリティ確保について定義します。これらは社内規定、ルールが存在してるためにそれらの洗い出しが必要となります。また規定などがないものは独自に確認を行うようにします。

### 環境・エコロジー
システムを設置する環境・エコロジーに関する要件を定義します。環境負荷を低減する構成や、電気設備・規格の適合性について定義します。ここは会社方針だったり各種法令順守に関連するため、専門の方々に入っていただく必要があります。

# 社内の既存ルール洗い出し
非機能要求６項目をチェックすると共に社内規定や運用状況を確認し、既に存在しているもので要件に合っているのかの確認を行います。また作成するプロダクトの方向性が、会社が掲げる方針やビジョンと異なっていないか。という事もチェック項目に追加します。

# 非機能レビュー観点シート
再構成した結果約100項目のレビュー観点シートにまとめました。
これは要件定義実施時に非機能要件の確認としてプロジェクト内でプロダクトオーナーなどとレビュー観点として活用を推進していくものとなります。
全ては記載できませんが分類と観点の一部を抜粋してご紹介します。

| 分類 | 観点 | 補足 |
|:-|:-|:-|
|機能適合性|システム機能の正当性確認||
|性能効率性|対向先、連携システムのキャパシティーの考慮|サーキットブレーカー制限|
|セキュリティー|関連部署、関連法令の確認の実施||
|セキュリティー|不正アクセスやアタックへの対策|WAF設定、DDoS対策、脆弱性診断実施|
|使用性|想定ユーザーに適した性能・機能であるかの確認||
|保守・移植性|使用するOSSやライブラリの確認|アーキテクチャレビュー実施|
|移行|サービス停止、閉塞を確認|影響するステークホルダーへの通知|
|リリース|強制アップデートの有無||
|サポート|サポートOS、動作保障環境|
|分析|SEO要件、分析連携情報の確認||
|制約|ビジネス制約、業界ルールの準拠||
|満足性|要求元の目的達成、費用対効果|ステークホルダーとの認識確認|
|CSR|フェアトレード、ダイバーシティ||

# おわりに
改めて詳細に確認するほど非機能要件グレードが非常によくできているな。と思いました。
これからレビュー観点の見直しなどに向けて、非機能要件項目の内容の理解を深め、機能品質とともに非機能の品質を向上させていきたいと思います！
to_s

# 何がsuperなのか
```rb
irb(main):001* module A
irb(main):002*   def to_s
irb(main):003*     "<A> #{super}"
irb(main):004*   end
irb(main):005> end
=> :to_s
irb(main):006* module B
irb(main):007*   def to_s
irb(main):008*     "<B> #{super}"
irb(main):009*   end
irb(main):010> end
=> :to_s
irb(main):011* class Product
irb(main):012*   prepend A
irb(main):013*   prepend B
irb(main):014*   def to_s
irb(main):015*     "<Product> #{super}"
irb(main):016*   end
irb(main):017> end
=> :to_s
irb(main):018> product = Product.new
=> #<Product:0x000000010cbc7d68>
irb(main):019> product.to_s
=> "<B> <A> <Product> #<Product:0x000000010cbc7d68>"
```
# メソッド名も色々変更してみた
```rb
irb(main):002* module A
irb(main):003*   def hihi
irb(main):004*     "#{super}"
irb(main):005*   end
irb(main):006> end
=> :hihi
irb(main):007* class B
irb(main):008*   include A
irb(main):009*   def hihi
irb(main):010*     "#{super} #{super}"
irb(main):011*   end
irb(main):012> end
=> :hihi
irb(main):013> b = B.new
=> #<B:0x0000000104f5ec68>
irb(main):014> b.hihi
(irb):4:in `hihi': super: no superclass method `hihi' for #<B:0x0000000104f5ec68> (NoMethodError)
```

# no superclass method
>super [bug]
`Kernelのメソッド内でsuperを呼んだ時に、存在しないsuperclass にアクセスしようとするバグ`の修正。
>
>module Kernel def foo super end end
>
>foo
>
>`# => ruby 1.8.3 (2005-09-21) [i686-linux] -:3:in `foo': method `foo' called on terminated object (0xb7e06970) (NotImplementedError) from -:7 # => ruby 1.8.4 (2005-12-22) [i686-linux] -:3:in `foo'-:3: warning: too many arguments for format string : super: no superclass method foo' (NoMethodError) from -:7

https://docs.ruby-lang.org/ja/latest/doc/news=2f1=2e8=2e4.html#:~:text=preserve%20external%20%23%20information.-,super%20%5Bbug%5D,for%20format%20string%20%3A%20super%3A%20no%20superclass%20method%20%60foo%27%20(NoMethodError)%20from%20%2D%3A7,-%E6%AD%A3%E8%A6%8F%E8%A1%A8%E7%8F%BE%20%5Bbug

```rb
irb(main):001* module A
irb(main):002*   def to_s
irb(main):003*     "#{super}"
irb(main):004*   end
irb(main):005> end
=> :to_s
irb(main):006* class B
irb(main):007*   include A
irb(main):008*   def to_s
irb(main):009*     "#{super} #{super}"
irb(main):010*   end
irb(main):011> end
=> :to_s
irb(main):012> b = B.new
=> #<B:0x000000011029f750>
irb(main):013> b.to_s
=> "#<B:0x000000011029f750> #<B:0x000000011029f750>"
```

# to_sとは？
>to_s -> String
オブジェクトの文字列表現を返します。

https://docs.ruby-lang.org/ja/latest/method/Object/i/to_s.html#:~:text=to_s%20%2D%3E%20String,%E3%82%92%E8%BF%94%E3%81%97%E3%81%BE%E3%81%99%E3%80%82
SynchronizationContext越えの呼び出し

# 0. はじめに
[Freeradical](https://www.freeradical.jp)の中の人、[yamarah](https://qiita.com/yamarah)です。
以前の記事([Autodesk Inventor API Hacking (NET環境での別スレッドUI)](https://qiita.com/yamarah/items/505054bca9780e138c7f))の続きというか、その後の経過です。

# 1. SynchronizationContext越えの呼び出し
不幸にも複数のUIスレッドを持つ場合に、
```c#
// 待たない。投げっぱなし。
context.Post(_ => action(), null);
// 完了するまでロックする。
context.Send(_ => action(), null);
```
だと、不便です。具体的には`await`したい。
もっと言えば、呼び出し先の例外も受けたい。
ということで、標準化しました。

```c#
using System;
using System.Threading;
using System.Threading.Tasks;

public static class CallOverSynhronizationContextHelper
{
    public static async Task InvokeActionAsync(Action action, SynchronizationContext context)
    {
        Exception? exception = null;
        var sem = new SemaphoreSlim(0, 1);
        context.Post(_ =>
        {
            try
            {
                action();
            }
            catch (Exception ex)
            {
                exception = ex;
            }
            finally
            {
                _ = sem.Release();
            }
        }, null);
        await sem.WaitAsync();
        if (exception is not null) throw exception;
    }
    public static async Task InvokeAsyncActionAsync(Func<Task> actionAsync, SynchronizationContext context)
    {
        Exception? exception = null;
        var sem = new SemaphoreSlim(0, 1);
        context.Post(async _ =>
        {
            try
            {
                await actionAsync();
            }
            catch (Exception ex)
            {
                exception = ex;
            }
            finally
            {
                _ = sem.Release();
            }
        }, null);
        await sem.WaitAsync();
        if (exception is not null) throw exception;
    }
    public static async Task<T> InvokeFunctionAsync<T>(Func<T> func, SynchronizationContext context)
    {
        Exception? exception = null;
        var sem = new SemaphoreSlim(0, 1);
        T? result = default;
        context.Post(_ =>
        {
            try
            {
                result = func();
            }
            catch (Exception ex)
            {
                exception = ex;
            }
            finally
            {
                _ = sem.Release();
            }
        }, null);
        await sem.WaitAsync();
        return exception is null ? result! : throw exception;
    }
    public static async Task<T> InvokeAsyncFunctionAsync<T>(Func<Task<T>> funcAsync, SynchronizationContext context)
    {
        Exception? exception = null;
        var sem = new SemaphoreSlim(0, 1);
        T? result = default;
        context.Post(async _ =>
        {
            try
            {
                result = await funcAsync();
            }
            catch (Exception ex)
            {
                exception = ex;
            }
            finally
            {
                _ = sem.Release();
            }
        }, null);
        await sem.WaitAsync();
        return exception is null ? result! : throw exception;
    }
}
```
戻り値も取れるし、とても幸せ。
Powershellで連番のフォルダを大量に作成する。

## 概要
試験のエビデンス格納などで大量にフォルダが必要な際に一括で作成するPowershellコマンドです。

## 手順
1. フォルダを作成する場所で右クリックをして、「ターミナルで開く」を選択 
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/298070/a1f88819-a3bd-b4af-38df-862a81f8ff83.png)
2. 以下のコマンドを貼り付け
FCOUNT：作成するフォルダ数
FNAME：作成するフォルダの名前。"TEST_"とするとTEST_001から作成され、空白の場合は数字のみのフォルダとなる
4桁が必要な場合は「0:000」を「0:0000」にする
```poewrshell
$FCOUNF = 100
$FNAME = "TEST_"
New-Item (1..${FCOUNF} | % { "${FNAME}{0:000}" -f $_} ) -ItemType Directory
```
警告が表示された場合は「強制的に貼り付け」を選択
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/298070/b379b17b-2133-7bed-cd29-9606ac92454a.png)

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/298070/7a9bd9a0-913d-e681-e57e-f06f80457455.png)

以上
量子コンピュータのハードウェア

# はじめに
　量子コンピュータは素因数分解や大規模データ探索などを古典コンピュータに比較して高速に解くことが理論的に示されている。一方で、これらの高速性を実証するにはハードウェア上の制約が多く、実用的な問題を高速に解くことのできる大規模量子コンピュータは未だ実現されていない。大規模量子コンピュータを実現するために、世界中の大学や企業で様々なハードウェアの研究開発が行われている。本稿では、現在よく考えられている量子コンピュータの実現方式をレビューする。

# ハードウェアに求められる要素
　個別事例の紹介に入る前に、量子コンピュータのハードウェアに求められる一般的な要件を紹介したい。実用的な問題を解ける量子コンピュータを実現するためには、これから挙げる3要素が満たされる必要がある。

・計算に必要な各種操作(ユニバーサルゲートセット・測定・状態の初期化)を行える
　量子アルゴリズムの理論研究では、量子コンピュータの動作原理である量子力学の範囲内でどんな操作も行えることが大抵の場合に仮定される。古典コンピュータでの計算に用いられる論理回路がAND, OR, NOT演算を組み合わせれば任意の計算を行えたように、量子コンピュータでも何種類かの操作(ゲート)を組み合わせることで任意の量子計算を行うことができる。これらの操作の組はユニバーサルゲートセットと呼ばれ、実用的な量子コンピュータでは実現が必須となる。併せて、量子ビットの値の測定と、量子ビットの値をリセットする操作である初期化も行える必要がある。

・量子状態をノイズから保護できる
　大規模量子コンピュータの実現を妨げる最大の要因がノイズである。ノイズから量子ビットを保護する技術として、量子誤り訂正符号がある。詳細は別記事に譲るが、量子誤り訂正符号では複数の量子ビットを用いた冗長化を行うことで、量子ビットの情報をノイズから保護する。大規模量子コンピュータの実現には量子誤り訂正符号の実装が不可欠であり、そのためにも多数の量子ビットの実装や、ある程度誤り率の低いゲート操作や測定の実装が求められる。

・スケーラビリティ
　現在の量子コンピュータで実装されている量子ビット数は最大でも1000程度だが、量子誤り訂正を行いながら実用的な量子計算をするためには100万量子ビット程度が必要と試算されており、量子ビット数の増加が求められている。量子ビット数を増加させることは勿論、量子ビットの操作や測定を行う装置の規模も量子ビット数の増大に対応して拡張できる必要がある。

# 具体的なハードウェア
　上記の要件を満たすために、様々な物理系を用いた量子コンピュータが提案されている。現在のコンピュータの殆どが集積回路で実装されているのに対し、量子コンピュータではまだ実装方式は定まっておらず、様々な方式が考えられている。以降、現在有力視されている量子コンピュータの実装方式とその利点・欠点を紹介する。

・超伝導型量子コンピュータ
　まず初めに紹介するのは超伝導体を用いた量子コンピュータである。超伝導体を含む微小な回路が1個の量子ビットを構成する。量子ビットへの操作はマイクロ波パルスを回路に印加することで行う。
　超伝導量子ビットは量子情報が保たれる時間(コヒーレンス時間)が長い利点がある。超伝導型の量子コンピュータはGoogleやIBMなど様々な機関により研究開発が行われており、IBMが1121量子ビットの量子コンピュータを発表した他、Google等により量子誤り訂正符号の実装も着実に進んでいる。一方で超伝導型量子コンピュータは量子ビット数を増やした際の回路や装置の拡張性に課題があり、100万量子ビットの実現にはブレイクスルーが必要とみられる。

・中性原子型量子コンピュータ
　数年前までは超伝導型量子コンピュータが最も性能が良いとされていたが、近年それに匹敵する性能を達成しているのが中性原子を用いた量子コンピュータである。量子ビットはその名の通り中性原子が担い、中性原子はレーザー光により配列される。量子ビットへの操作も、中性原子に特定の波長のレーザー光を照射することにより行われる。
　中性原子型量子コンピュータはレーザー光を用いて一度に大量の中性原子を配列できるため、スケーラビリティに優れている他、レーザー光を調節することで原子の位置を移動させられるため、量子ビット同士の結合性にも優れている。一方で、超伝導型と比較すると量子ビットへの操作に時間がかかる点や、操作精度が劣っている点が課題となる。中性原子型は昨年以降の進展が目覚ましく、Atom Computingが1180量子ビットを達成した他、ハーバード大とQuEraが48個の論理量子ビットを実装した。

・光量子コンピュータ
　最後に紹介するのは光を用いた量子コンピュータである。これまで紹介した量子コンピュータでは原子のエネルギー準位などの離散量を量子ビットに利用していたのに対し、光量子コンピュータでは光の振幅や位相といった連続的な量に量子情報を埋め込む。適切な光学素子に光を通すことで振幅や位相を操作し、演算を行う。連続量はノイズに弱い性質があるが、連続量を離散化するような量子誤り訂正符号を考えることで、高いノイズ耐性を持つ量子ビットをエンコードできる。
　超伝導型ではノイズを低減するために量子コンピュータを極低温に冷却する必要があったが、光量子コンピュータではその必要がなく、室温で動作することができる。また、量子通信や量子暗号は光を用いた研究が多いため、各種量子技術との相性も良い。欠点としては、光損失などのノイズの影響が大きい他、ユニバーサルゲートセットの実装が他方式と比べて難しいことが挙げられる。上述した2方式と比較すると大規模な実装は行われていないが、Xanaduが光量子コンピュータで量子超越性を達成した他、日本でも東大を中心に誤り訂正符号の実装など最先端の技術開発が行われている。

# まとめ
　本記事では量子コンピュータのハードウェアに求められる要件や、開発が進んでいるハードウェアの紹介を行った。これまでは超伝導型が優位とされていたが、現在ではどの方式による実装が優れているか分かっておらず、各研究機関により様々な方式での実装が研究されている。
量子技術について研究している組織体制のまとめ

# はじめに
本記事は、これから量子コンピュータをはじめとした、量子技術について勉強したい人や調べ物をしたい人に向けて執筆いたしました。筆者自身が、量子技術に関連した研究内容や取り組みについて調べる際、以下の様な困り事があったためです。
ある量子コンピュータの研究紹介として“高崎量子技術基盤研究所の○○研究室”が登場、また“量子コンピュータ開発を企業と連携して進めているとのニュース記事には理化学研究所”が登場、更には“量子通信に関する記事として量子ICT協創センターの方のインタビュー”を発見、という感じで、次から次へと馴染みのない研究機関や研究所の名前に出会う事が頻繫にありました。
所属している研究機関が大学であれば、聞いた事のない研究室であっても「○○大学の研究室のことか」と情報を咀嚼できるのですが、上記のような研究機関は馴染みの薄い方が多く、量子技術をこれから調べようと考えている人にとっては意外と情報負荷が高いのではないかと思います。
そこで、大学ではない公的研究機関で量子技術の研究を行っているグループを抜き出し、研究組織体制をまとめてみることにしました。今回は、量子技術イノベーション拠点に設定されている５つの機関を対象にしました。

# 量子技術イノベーション拠点とは
本章では「量子技術イノベーション拠点とは何か」について簡単に説明いたします。
誰が推進しているかについては、内閣が制定した「量子技術イノベーション戦略」に基づいているため「国」となります。
また、「大学・企業間の有機的な連携・協力体制を構築し、同時に複数の大学・大学院等と連携・接続し、将来を担う量子技術分野の人材育成を行いたい」という目的のもと、「技術の特性に応じて人材・技術等を結集し、基礎研究から技術実証、オープンイノベーション、知的財産管理、人材育成等に至るまで産学官で一気通貫に取り組む拠点を形成する」という方針で進めているようです。
（参考資料：https://www8.cao.go.jp/cstp/ryoshigijutsu/8kai/siryo2.pdf）
上記を簡単に言うと、「産学官を連携させて量子人材の育成を促進したい！」ということかと思います。以下のように各対象に応じた拠点が設定されています。
![rsp_vol5_figure1.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3947801/e0e9411e-a851-9c64-9249-3a17a7dab941.png)
引用：QIH量子技術イノベーション拠点　https://qih.riken.jp/

# 量子技術の研究体制まとめ
量子技術イノベーション拠点の中から、大学ではない５つの機関に限定し、量子技術の研究を行っている研究組織体制を以下の表にまとめてみました。
![rsp_vol5_table1-650x1024.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3947801/19452fa9-b6b0-d9af-7ca4-507b4ddc441f.png)
![rsp_vol5_table2-653x1024.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3947801/afe6177f-eacb-530a-32ca-12edefbb064b.png)
![rsp_vol5_table3.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3947801/5859fb2b-af2b-75f0-8c77-37bcada01d80.png)
![rsp_vol5_table4.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3947801/f92ff032-648c-cafb-7fe4-214953de6787.png)
![rsp_vol5_table5.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3947801/a30ad01e-98a3-5eaf-bcfd-9346f6b2633d.png)


# まとめ
量子技術の調べものをしている最中に何だかよく知らない研究所や研究センターが出てきた際は、上記の表から探していただき、母体の組織や配下の組織、横の繋がりを整理しながら、効率の良い情報収集にお役立てていただけましたら嬉しいです！

筆者：DX事業部　中津野 侃貴
【ChatGPT】“ジップの法則”をPromptに組み込んでみます。


　どうも、カーブミラーです。

　今回は、“ジップの法則”をPromptに組み込んでみます。

:::note info
本記事は、ChatGPT（有料版）
で行なっております。画像は
ありません。　あしからず。
:::
　ChatGPT等の動作状況を知らせる
　　OpenAIのステータスページ。
　　　[OpenAIステータス](https://status.openai.com/)

***
　ニュースがありませんので、
　　さっそく、本題です。

　今回は、
　　“ジップの法則”を
　　　Promptに組み込んでみます。

　こちらの記事を
　　読んでやってみました。
　　　[全物理方程式に"裏ルール"か](https://news.nifty.com/article/item/neta/12363-3598128/)

　ChatGPTに尋ねてみました。
***
***●user***
“ジップの法則”について教えてください。
箇条書きでお願いします。

***ChatGPT***
ジップの法則について

・概要
ジップの法則（Zipf's Law）は、自然言語や社会現象、経済データなど、多くの分野で観察される統計的な分布の法則。

・命名
アメリカの言語学者ジョージ・ジップ（George Zipf）によって提唱された。

・法則の内容
頻度が順位に反比例する形で分布する。具体的には、

　・順位と頻度の間には関係性がある。

　・つまり、最も頻繁に使用される単語の出現頻度は2位の単語の約2倍、3位の単語の約3倍になる。


・適用される分野

　・自然言語処理: 単語の出現頻度分布。

　・都市の人口分布: 各都市の人口がジップ分布に従うことが多い。

　・経済学: 企業の規模分布や富の分布。

　・インターネット: ウェブサイトのアクセス頻度、検索クエリの分布など。


・具体例
英語の単語頻度:

　・"the" (最頻出) の頻度が最も高い。

　・2番目に多い "of" は "the" の約半分の頻度。


・背景理論
人々の選択や行動が最適化される傾向にある場合、このような分布が自然に形成されると考えられている。

・応用
　・自然言語処理では、頻出単語のフィルタリングや効率的なテキスト処理に利用。

　・経済学では、都市や市場の成長モデルを分析する際に応用。


・注意点
ジップの法則は統計的な傾向を示すものであり、すべてのデータセットが厳密に従うわけではない。
***

　“最も頻繁に使用される単語の出現頻度は2位の単語の約2倍、3位の単語の約3倍になる。”
　　という部分が
　　　一番しっくり来るでしょうか。

　英語で一番多いのが“the”ですが
　　日本語では“の”になるそうです。

　単語に限らず、
　　地震もそうなのだとか。
　　　大きな地震は少なく、
　　　　小さな地震は頻繁に発生する。
　　　　　確かにそうですね。

　それはともかく、
　　ジップの法則を
　　　Promptに組み込んで、
　　　　思考を重ねて
　　　　　正しい回答に
　　　　　　たどり着くためのPromptを
　　　　　　　作成してみました。

　＊＊＊に
　　問題を書き入れて
　　　送信してください。

　回答が
　　常に正しいとは
　　　限りません。
　　　　ご注意を。

```Text:思考を重ねて正しい回答にたどり着くためのPrompt
問題「＊＊＊」

目的を明確にする質問：
1. この問題に対して、解決すべき具体的な課題は何か？
2. 問題の背景や前提条件を明確にするために、どの情報が不足しているか？
3. この問題に取り組む最終的な目標は何か？

仮説を立てる質問：
4. この問題を解決するための仮説を3つ挙げてみよう。それぞれの仮説の根拠は何か？
5. 仮説を検証するために、どのデータや事実が必要か？
6. 仮説が正しい場合、どのような結果が得られるか？

視点を広げる質問：
7. 自分の視点とは異なる立場（反対意見や中立的な視点）から考えると、どのような可能性があるか？
8. 過去の成功事例や類似する問題での解決策には、どのようなものがあるか？
9. 問題を別の角度やスケールで考えると、新たな洞察が得られるか？

結論を導く質問：
10. 複数の選択肢の中で、最も合理的で実現可能な解決策はどれか？
11. 選択した解決策には、どのようなリスクや限界があるか？それを克服する方法は？
12. 最終的な結論を出すために、次に取るべき具体的な行動は何か？

総合的な回答：
上記の質問に基づいて得られた情報をすべて統合し、明確かつ実行可能な結論を導き出してください。この結論には、次に取るべき具体的な行動計画を含めるようにしてください。
```

　下記をやってみました。
　・ChatGPTを越えるには
　・宇宙の果ては、どこにあるのか
　・幸せになる方法

　回答というよりは、
　　“解決に至るためには
　　　何をすべきか？”という感じの
　　　　内容になりました。

　でも、その途中の出力は
　　なかなかの的を得た文言が
　　　出てきます。
　　　　それだけでも
　　　　　休憩時間にやってみても
　　　　　　知見を得られるかも。

　みなさんの
　　作品制作の糧に
　　　なれば、幸いです。

　今回は、ここまで。
本番環境でDjangoのAdminサイトの表示が崩れてしまう件

# 本番環境のAdmin画面の崩れ
NginxでDjangoアプリをクラウドにデプロイしたら、なぜかローカルで綺麗に表示された管理画面（AdminSite）のレイアウトが下記の図のように崩れてしまいました。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2784500/b703eb4e-615c-0785-df36-911147e662f1.png)
いつもローカルでpython manage.py runserverで開発サーバーを立ち上げるとき、何もせずとも管理画面が綺麗に表示してくれたので、困ったもんですね。。

そこで、Chatgptと先人たちの知恵をかりながらこの問題を無事に解消したので、その解消法をご紹介いたします。

### Djangoの静的ファイル設定

Djangoプロジェクトでは、静的ファイルの設定は主に`STATIC_URL`と`STATIC_ROOT`に関係します。

#### 設定例

DjangoProjectの`settings.py`で：
```python:settings.py
STATIC_URL = '/static/'
STATIC_ROOT = os.path.join(BASE_DIR, 'staticfiles')
```

- **`STATIC_URL`**：テンプレートで静的ファイルを参照するためのURLプレフィックス。
- **`STATIC_ROOT`**：collectstatic`コマンドで全ての静的ファイルを集めるディレクトリ。


#### 静的ファイルの収集

本番環境では、以下のコマンドを実行して静的ファイルを収集します：

```bash:bash.
python manage.py collectstatic
```

これにより、全ての静的ファイルが`STATIC_ROOT`に指定されたディレクトリに集められます。

### Nginxの設定

Nginxでは、静的ファイルのパスを正しく設定する必要があり、今回の問題はまさにNginxの設定によるものでした。

#### Nginx設定例
```nginx:nginx.conf
server {
listen 80;
server_name your_server_ip;
location = /favicon.ico { access_log off; log_not_found off; }
location /static/ {
alias /path/to/your/project/staticfiles/;
# 問題があった設定↓
# root /path/to/your/project/staticfiles/;
}
location / {
include proxy_params;
proxy_pass http://unix:/path/to/your/project/your_project.sock;
}
}


- **`alias`**：リクエストパスを指定されたディレクトリに直接マッピングし、
- 静的ファイルディレクトリへの正しいマッピングを保証します。
```

#### Nginxの再起動

設定を完了したら、Nginxサービスを再起動して変更を適用していきます。

```bash:bash.
sudo systemctl restart nginx
```

再度管理画面にアクセスすると、、正常に表示されるようになりました！!

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2784500/0f357820-9801-084d-1697-13f6e0a01ca0.png)

#### Nginxでの`root`と`alias`の違い

Nginxで静的ファイルを提供する際、`root`と`alias`の使い方には重要な違いがあります。

### `root`

- **説明**：`root`はリクエストパスのプレフィックスを保持します。


- **使用例**：
```nginx:nginx.conf
  location /static/ {
      root  /path/to/your/project/staticfiles/;
  }
```

  - リクエストパスが`/static/css/style.css`の場合、rootは/static/をプレフィックスとして保持する：`/path/to/your/project/staticfiles/static/css/style.css`

  
### `alias`

- **説明**：`alias`はリクエストされたURIを指定されたディレクトリに直接マッピングします。
- **使用例**：

```nginx:ngixn.conf
  location /static/ {
      alias /path/to/your/project/staticfiles/;
  }
```

  - リクエストパスが`/static/css/style.css`の場合、
  - `alias`は/static/をプレフィックスとして保持せず、指定のパスに直接にマッピングする：`path/to/your/project/staticfiles/css/style.css`　　


### 違いの説明：

- **パスの処理**：`root`はURIのプレフィックス(パスや文字列の先頭部分)を保持し、`alias`はそれを置き換えます。
- **適用シナリオ**：静的ファイルのディレクトリを直接指定する場合は`alias`が適しています。




### まとめ

ローカル環境ではDjangoが自動的に静的ファイルび解析をしてくれるので特段気にしていなかったのですが、本番環境ではDjangoとNginxの静的ファイルパスをきちんと設定を行ないとAdmin画面だけでなくアプリのコンテンツ画面も正常に表示されない可能性がありますので、今後は新しい確認視点として意識していこうと思います！

本記事がDjangoプロジェクトでの静的ファイル設定にお役立つことを願っています。
ご質問があれば、ぜひコメントしてください！
大西配列を導入する（キー配列を自由に変える方法）

## 大西配列とは
* 大西配列とは、大西拓磨氏によって開発された日本語の入力に特化したキー配列です
  * [詳しくはこちら](https://o24.works/layout/)
* 一般的な配列ではないため、大西配列を導入する際はキー配列を自由に変えられる必要があります。

## キー配列を自由に変える方法

### PowerToys
* PCに導入する際は、「PowerToys」というアプリを利用すると良いでしょう。
* PowerToysはMicrosoftが開発するオープンソースのユーティリティソフトウェアです。
  * [インストールはこちら](https://learn.microsoft.com/ja-jp/windows/powertoys/install)
* 様々な機能を搭載しており、その中の「Keyboard Manager」に「キーの再マップ」機能があります。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3507443/4c085529-58d1-493e-6f8e-263451977868.png)

* 実際に大西配列の通りに設定すると、このようになります。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3507443/0d4aded3-f107-fdde-7f94-01ebdee1bfe7.png)


### azuukey
* スマホで導入する際は、「azuukey」というアプリを利用すると良いでしょう。
* azuukeyは、細かいキーボードの設定が可能なスマホアプリです。SimejiのPro版みたいなところでしょうか。
* [こちらのツイート](https://x.com/9dpbQ/status/1763688505962864745)から、キー配列のjsonファイルをDLできますので、こちらをアプリに設定します。

## 大西配列の習得
* 自分の場合、まずはスマホに大西配列を導入しました。
* 普段の連絡や調べものなど、時間が多少かかっても問題ないところから導入していくのが良いでしょう。
  * 慣れないうちは、自身の入力の遅さにイラついてました笑
* スマホである程度スムーズに入力できるようになってから、PCにも導入したという流れです。
  * まだ慣れないうちは、実際にキーキャップを大西配列の通りに変えることを強くオススメします。
prepend

# ミックスインされたモジュールの方が先に同名メソッドが呼ばれる
```rb
irb(main):001* module A
irb(main):002*   def to_s
irb(main):003*     "<A> #{super}"
irb(main):004*   end
irb(main):005> end
=> :to_s
irb(main):006* class Product
irb(main):007*   prepend A
irb(main):008*
irb(main):009*   def to_s
irb(main):010*     "<Product> #{super}"
irb(main):011*   end
irb(main):012> end
=> :to_s

irb(main):014> product = Product.new
=> #<Product:0x000000010c4b2410>
irb(main):015> product.to_s
=> "<A> <Product> #<Product:0x000000010c4b2410>"
```
https://gihyo.jp/book/2017/978-4-7741-9397-7

# prependすると優先的に下からモジュールを読み込んで最後にクラスメソッドを呼び出せる
```rb
irb(main):001* module A
irb(main):002*   def to_s
irb(main):003*     "<A> #{super}"
irb(main):004*   end
irb(main):005> end
=> :to_s
irb(main):006* module B
irb(main):007*   def to_s
irb(main):008*     "<B> #{super}"
irb(main):009*   end
irb(main):010> end
=> :to_s
irb(main):011* class Product
irb(main):012*   prepend A
irb(main):013*   prepend B
irb(main):014*   def to_s
irb(main):015*     "<Product> #{super}"
irb(main):016*   end
irb(main):017> end
=> :to_s
irb(main):018> product = Product.new
=> #<Product:0x000000010cbc7d68>
irb(main):019> product.to_s
=> "<B> <A> <Product> #<Product:0x000000010cbc7d68>"
```
# 基本的には下から上にミックスインされた順で読み込まれる
https://qiita.com/masatom86650860/items/d8085bbbfbc2ab5ddc6d
【TryHackMe】Geolocating Images：Walkthrough

# 概要

TryHackMe「Geolocating Images」のWalkthroughです。

https://tryhackme.com/r/room/geolocatingimages

# Task2

## **Q1**.*Where in the world is image 1? The answer is the country name.*

`Yandex`で画像検索をします。

https://yandex.com/images/?utm_source=yandex&utm_medium=com&utm_campaign=morda

`1.jpg`の画像候補が見つかりました。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3005822/eab1a010-18b2-05d6-3b70-3a4e0ce2414d.png)

**A**.**China**

# Task4

## **Q**.*Where was image 2 taken?*

画像の道路標識から`SHEFFIELD`,`ADDISON`の文字が見え、`SPORTS CORNER`の看板も見えます。

![2.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3005822/6d77ca69-9854-4fac-a02d-12c06ba8b8e1.png)

これらワードで場所を検索し、特定に成功しました。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3005822/ca9109b1-a671-703f-95dc-8754b7ceae43.png)

`2.png`の画角から、道路を挟んだ`Wrigleyville Sports`からのカメラだと推測できます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3005822/ab47d15f-6d3f-f0b3-98d6-1707c804be5c.png)

**A**.**Wrigleyville Sports**

# Task6

## **Q1**.*Where was image 3 taken?*

**Hint**.*Is that the eiffel tower? And what's that white building?*

この画像から下記のことを推測出来ました。

- セーヌ川向かって右側にエッフェル塔がある
- 樹が多いので公園などの場所
- ドーム型の建物なので公共の建物の可能性が高い
- エッフェル塔と川を沿ったほぼ直線上にある

![3.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3005822/d2b88900-ea31-abec-5814-514845a6fdfa.png)

上記のことを踏まえて下記の場所を特定できました。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3005822/ed9b8a76-cd9b-a6c7-3f5b-b6b02afa8034.png)

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3005822/dda3d088-5e89-cb41-e098-1b15304d8ccc.png)

画角を踏まえるとこのエリアの右下の高い建物から撮られた写真だと推測できます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3005822/71f30ae9-d6ca-bac7-25ce-568f9ab72f2a.png)

このエリアの建物は天文関係の物らしいので`paris meudon observatorio`などで検索するとそれらしき写真に辿り着きました。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3005822/98a3f266-83ac-2645-82eb-bfc088b26c8b.png)

**A**.**Meudon Observatory**

# Task7

## **Q1**.*Where is image 4 taken?*

![4.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3005822/1a2a708b-e960-b907-2a45-3573dd8dfe49.png)

左手前のシルバーの車ナンバーに注目し、`L 010 PNE 車 ナンバー`で検索すると下記サイトを発見しました。

https://car-check.co.uk/check/LO10PNE

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3005822/0b8031a4-ffbf-344c-2960-293baf319f0c.png)

このことから場所はロンドンだと推測できます。
さらに、交差点の中央に小さい塔の様なオブジェクトを確認できます。

`ロンドン　交差点　有名`で検索すると同じオブジェクトの写真を発見できました。
ビートルズのあの有名なジャケ写の場所らしいです。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3005822/9e7e926e-946f-da0d-4694-e8bd28525327.png)

**A**.**Abbey Road**
育休中に転職活動をした話

## はじめに

本記事は [転職活動して気づいた「これをやっていれば.../やってよかった」をシェアしよう by 転職ドラフト Advent Calendar 2024 シリーズ2](https://qiita.com/advent-calendar/2024/engineering-careers-2)の9日目の記事になります

今回の記事では育休中に転職活動をし、実際に内定を頂いた話について書いていきます。

育休中以外の方にも共通する部分もあるかと思います。

## なぜ育休中に転職活動をしようと思ったのか
育休中の転職活動は、正直自分でもハードルが高いと思いました。
しかし、会社の経営が悪化してしまい、復帰のタイミングで転職せざるを得なくなりました。

## 育休中に転職活動をするメリット
・仕事をしていないので時間はたっぷりある

## 育休中に転職活動をするデメリット
・面接中は子供を家族に見てもらう必要があるので、自分のペースでは面接を受けられない
・家族に迷惑がかかる
・復帰時期が半年以上先のため、企業によってはすぐに面接してもらえない(私の場合です。すぐに復帰する場合はこの限りではないはずです)


## 登録したサイトやエージェント
職を失うかもしれないため、とにかくたくさん登録しました。

・ビズリーチ
・転職ドラフト
・findy
・dodaX
・リクルートエージェント
・アデコLHH転職エージェント
・LIBZ

アデコさんとLIBZさんはビズリーチ経由で連絡をいただいて登録しました。


## 育休中の転職活動で苦戦したこと

#### 初めて受けた企業では言語化できず失敗
これは育休中だからという訳ではありませんが、フルリモートワークであまり会話することがなかったり、子供とばかり会話していたため、言語化することが苦手になっていたようです。面接後に振り返りを行って、次の企業の面接を受けた際は問題なく受け答えできました。
  
#### すぐに面接してもらえない
復帰が年度を跨ぐため、年始など、来年の予算が決まってから面接をしたいと言われた企業が何社かありました。
育休中で急いで転職しなければいけないという訳ではなかったのですが、早めに決めておきたいという心理があり、すぐには選考してもらえないケースもありました


## 育休中にやっておいてよかったこと
私はバックエンドエンジニアなのですが、フロントエンドの勉強をしていました。
そのことを面接中に伝えると印象が良かった（と自分で思っています）


 ## 各転職サイト・エージェントの良かった点

育休関係なく、今回利用した転職サイトやエージェントの良かった点を記載します。
あくまで個人的感想です。

### 転職サイト
#### ビズリーチ
たくさんの企業やエージェントからスカウトを頂けました。
今回内定を頂くことになったエージェントもビズリーチ経由でで会いました。


#### 転職ドラフト
企業側が年収を提示してオファーをくれるので、自分の市場価値がわかって良かったです。
また、今回初めて登録してドラフトに参加したため、オライリーの本をプレゼントでいただきました！

新しく登録される方はぜひ私の紹介コード「XPSZ」を使ってください。一緒にオライリーの本を読みましょう。

[転職ドラフトで1000万円オファーを頂いた話](
https://qiita.com/t_mapico/items/cc1e5ff584a6c856a294)という記事も書きました。ご興味がある方はこちらもご覧いただけると幸いです。



#### findy
ユーザーサクセス面談を利用して本当に良かったです。
転職活動に関する悩み以外にも、面接の壁打ちをしてくれたりします。

#### Forkwell
企業からのスカウトのみで、ヘッドハンターからのスカウトがないのでストレスがない。

### 転職エージェント

#### アデコLHH転職エージェント
面接対策として、想定質問を詳細に教えていただけるので、面接前の不安が軽減されます。

#### LIBZ
元々は働く女性のための転職エージェントだったため、子育てに理解がある会社からのオファーが多かった。



リクルートエージェントとdodaXは、年末年始くらいから活動しましょうと提案されたため、今回は面談のみで終わりましたが、案件が多そうな感じがしました。



## 育休中の転職活動でやって良かったこと

#### カジュアル面談は子連れ
オファーやスカウトをしてくれた企業とはカジュアル面談を受けました。

最初は子供を家族に見てもらいながら面談をしていたのですが

予定を調整してもらうのが大変になり、findyさんとのユーザーサクセス面談で、

「カジュアル面談は子供抱っこしたまま受けてもいいものでしょうか？」と相談したところ

「全然問題ないと思います。むしろ嫌な顔されるような企業とは今後働く上でも相性が悪いと思いますよ」と言っていただけたため、途中から子連れで面談を受けていました。（事前にに相談して許可を得てから）

## 今回の転職活動での後悔ポイント
これは育休中だからという訳ではなく、今回の転職活動についての後悔ポイントです。

#### 転職ドラフトをもっと活用すべきだったかも
というのも、転職ドラフトを使い始めたのが、転職活動の後半くらいだったため、他社と足並みが揃わず、カジュアル面談しか受けなかったのです。
高額オファーを提示され、事業内容も興味がある企業だったのですが、内定も決まっていたため、辞退しました。

#### 転職サイトの登録は同時期が良い
転職ドラフトもそうですが、findyも後半に登録しました。
後からオファーをもらう企業の方がよく見えてしまい、キリがなかったです。
サイトの登録は同時期に行うのが良さそうです。

## 内定承諾した企業
ありがたいことに、今回の転職活動では、何社か内定を頂きました。

実際に内定を承諾するにあたり、どの企業にするか、本当に悩みました。

しかし、転職直後、子供が保育園に入りたてで、発熱する頻度がかなり高いことを予想し、フルリモート・フルリモートで働ける会社。

さらに、現職が、業績悪化したこともあったので、業績が安定してそうな企業に決めました。

## おわりに
転職活動をする前は、育休中ということがネックになるかと思っていました。
しかし、そんなことはありません。
ですが、実際に働く時期があまりにも先だと少し難しくなるようです。



もし、同じように育休中だったり子育てをしながら転職活動を考えている方がいましたら、この記事がお役に立てれば幸いです。
【設計】コードの良い依存と悪い依存

# はじめに

この記事では、**良い依存と悪い依存を見分ける方法**と、設計に役立つ**依存性の逆転の原則**について解説します。

---

## この記事でわかること

- **良い依存と悪い依存**の区別ができる  
- **依存性の逆転の原則**を理解し、柔軟で保守性の高い設計ができる  

---

## 対象読者

- 設計をこれから学びたい人  
- 「依存は良くない」と言われてもピンと来ない人  

---

## **依存とは？**

### **クラス間の依存**

「依存」とは、クラスが他のクラスを直接参照している状態を指します。以下のコードを例に説明します。

```csharp
public class ObjectA
{
    public void Client()
    {
        ObjectB objectB = new ObjectB(); // ここが依存
        objectB.Log();
    }
}

public class ObjectB
{
    public void Log()
    {
        Console.WriteLine("Hello, World!");
    }
}
```

**このコードのポイント**:
- `ObjectA`が`ObjectB`を直接参照し、`Log`メソッドを呼び出しています。
- この依存によって、**`ObjectB`の変更が`ObjectA`に影響を与えます**。

---

## **依存の安定度と柔軟性**

### **安定度とは？**

依存には**安定度**と**柔軟性**がトレードオフの関係で存在します。

以下の例を見てみましょう。

```csharp
public class ObjectA
{
    public void Client()
    {
        ObjectB objectB = new ObjectB(); // ここが依存
        objectB.Log(); // ここでエラーが発生
    }
}

public class ObjectB
{
    public void Log(string name) // ここでメソッド定義を変更
    {
        Console.WriteLine($"{name}さんこんにちは。");
    }
}
```

### **変更が引き起こす影響**

- **`ObjectB`を変更すると、`ObjectA`が影響を受けます**。このように、依存先が変化すると依存元にも影響が波及します。  
- 一方で、`ObjectA`が変更されても、`ObjectB`には影響がありません。

### **安定度の指針**

変更されにくいもの（＝安定しているもの）に依存するのが基本です。しかし、依存方向を常に変更されにくいものに向けるのは難しい場合もあります。そこで登場するのが**依存性の逆転の原則**です。

---

## **依存性の逆転の原則**

### **原則の概要**

**依存性の逆転の原則**（DIP: Dependency Inversion Principle）とは、  
> 「**変化しやすい具象クラスではなく、抽象に依存する設計にすることで、変更の影響を最小限に抑える**」  

という考え方です。

以下のコードで、依存性の逆転を適用した例を見てみましょう。

```csharp
public class ObjectA
{
    public void Client()
    {
        IAdapter adapter = new ObjectB(); // 抽象に依存
        adapter.Log("山田");
    }
}

public class ObjectB : IAdapter
{
    public void Log(string name)
    {
        Console.WriteLine($"{name}さんこんにちは。");
    }
}

public interface IAdapter
{
    void Log(string name);
}
```

### **この設計のメリット**

- `ObjectA`は`IAdapter`（抽象）に依存しているため、`ObjectB`の具体的な実装変更に影響を受けません。  
- もし他の`ObjectC`を新たに追加した場合でも、`IAdapter`を実装するだけで`ObjectA`のコードに変更は不要です。

---

## **クラス図で理解する**

この構造をクラス図に表すと、次のようになります：

```
ObjectA → IAdapter ← ObjectB
```

- **依存の方向性が「抽象」に向いている**ため、柔軟性が高く、変更に強い設計です。

---

## **まとめ**

### **依存性の逆転の原則のポイント**

1. **具象ではなく抽象に依存する**ことで、変更に強い設計を実現する。  
2. **変更しやすい部分を隠蔽**し、クラス間の独立性を高める。
転職ドラフトで1000万円オファーを頂いた話

## はじめに

本記事は [はじめてのアドベントカレンダー Advent Calendar 2024 シリーズ5](https://qiita.com/advent-calendar/2024/first-time)の8日目の記事になります

今回の記事では転職ドラフトで1000万円のオファーを頂いた話について書いていきます。


## 転職ドラフト参加時点でのスペック
- サーバーサイドエンジニア(約20年弱)
- ゲーム開発の企業に勤務(育休中)
- 経験技術
    - サーバーサイド : PHP, Ruby, Rails, Go
    - フロントエンド : JavaScript,Jquery,HTML
    - インフラ : AWS, GCP, Docker, Terraform
- 経験業務
    - 基本設計, 詳細設計, 業務システム開発, Webサービス開発, テストコード実装, DB設計, インフラ構築, 保守運用, その他ドキュメント作成
    - エンジニア採用面談
    - エンジニアリーダー(工数管理,業務割り当てなど)

## 転職ドラフトに登録したきっかけ
- 育休中に会社の業績が悪化したため
- 自分の市場価値が知りたいと思ったため

## 転職ドラフトに参加するまでの道のり
### 登録したプロジェクトは2つのみ
久しぶりの転職活動だったため、過去のプロジェクトを思い出すのが大変でした。
転職ドラフトでは、レジュメが審査に通らないと、ドラフトに参加できないので、詳細にレジュメを記載する必要があります。
過去の業務内容の詳細を思い出せず、結局登録したプロジェクトは2つのみでした。

### 審査に落ちたのは2回
2回落ちたものの、フィードバックがあるため、それを元に修正することで、3度目の正直で審査に通りました。

## 初めてのドラフト
- 指名7件
- 700〜820万

初めての参加でも指名を頂けました。
いくつかカジュアル面談は受けましたが、事業内容にあまりピンと来なかったので面接を受けるには至りませんでした。

## 2回目のドラフト
- 指名7件
- 682〜1000万

2回目で、まさかの1000万円。
事業内容も興味があり、働き方もマッチしている企業でした。
しかし、すでに他の企業で内定を承諾していたため、今回は辞退しました。

![31b6f560-33c5-4718-834a-016d119cd444.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/25785/09282c2d-269e-a77b-ef7f-5848336f9da9.png)



## 転職ドラフトを登録して良かった点
- 自分の市場価値がわかった
- ドラフトに初参加でオライリーの本もらえた

新しく登録される方はぜひ私の紹介コード「XPSZ」を使ってください。一緒にオライリーの本を読みましょう。


## おわりに
転職しようか悩んでいる方や、自分の市場価値が知りたい方には転職ドラフトはおすすめです。
プロジェクトを2つしか登録していない私でも、1000万円の指名を頂けました。
たくさん登録できる方にはもっと高額の指名が来るのではないでしょうか。
【AWS re:Invent2024】早速AWS BuilderCards ゲットしてみた

# はじめに

今年もAWS re:Invent2024が始まりますね！弊社は今年も現地参加しています！✨

今日は会期前日ですが、既に大盛り上がりでユーザーのAWS熱を肌で感じています🌺

# チェックイン後BuilderCards会場に直行

以下の記事を発見し、プレイしてみたいと思っていたBuilderCardsが先着1000名にプレゼントされることを知りました！

https://aws.amazon.com/blogs/aws/aws-buildercards-second-edition-available-at-reinvent-2024-and-online/

これはまたとないチャンスと感じ、時差ボケの身体にムチを打ち午前中のうちに向かった所無事ゲットすることができました✨

![IMG_3771.jpeg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3550351/c0eaf567-ae20-97de-5e59-878f76fa7dd2.jpeg)


しかも、その場でプレイ方法をレクチャーして頂けるとのことで早速やってみました！

![IMG_3662.jpeg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3550351/a720d058-cee6-e1f6-7cfa-39a959101580.jpeg)

あまり英語は話せないですが、スタッフの方が優しい英語で話してくれるので初めてでも楽しくプレイできました！

アーキテクチャの構築のあまり経験がない私ですが、AWSを楽しく学ぶことができるなと感じました！

# さらに特別なカードも！

ゲーム終了後、サプライズでイベント限定カードと認定者限定カードも頂きました！

![IMG_3772.jpeg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3550351/83bd3fee-4c1e-3271-c6ee-de850cdad9fc.jpeg)

嬉しいプレゼントに前日からテンションが上がりました！

帰国後、会社のメンバーともプレイして更なるレベルアップを目指したいです！💪

# さいごに
現場のリアルな熱量を届けられるように参加メンバーで記事を公開予定ですのでぜひ引き続きチェックしていただけますと嬉しいです🌼
zimfwで自分好みのプロンプトを試しに作ってみた!

## :santa: はじめに

この記事は、[スタンバイ Advent Calendar 2024](https://qiita.com/advent-calendar/2024/stanby)の記事として書いております!
ついに6日目の記事となりました! :tada: 

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

今回は、私が好きで使っている Zsh のフレームワークである Zim のプロンプトを試しに作ってみたので、作成方法や作成物についてご紹介したいと思います!

:no_good: この記事では話さないこと :no_good: 

- Zsh とはなにか？という話は長くなるので割愛します  
- Zim のインストール方法については、公式ドキュメントに記載があるため触れません

## :rocket: Zimとは

Zim とは、Zsh をより便利にするための以下の機能を提供してくれます。

https://github.com/zimfw/zimfw

1. プラグインマネージャー機能  
2. 機能を拡張するモジュールの提供  
3. プロンプトをおしゃれにするテーマ 

有名どころでいうと、oh-my-zsh が有名かなと思います。

https://ohmyz.sh/

oh-my-zsh と比べて Zim の良い点は、特に何もしなくてもデフォルトで起動速度が速いことです!  
普段は Tmux を使って複数ウィンドウを立ち上げて作業することが多いので、「速さは正義」ということで長く愛用しています。  
また、開発も継続されており、開発者の方には頭が上がりません :bow:

## :shamrock: プロンプトを作りたいと思ったきっかけ

Zim には公式が提供するテーマがあり、すぐにおしゃれなテーマを使えます。  
しかし、「こういうデザインがいい!」や「この情報を表示したい!」といった複雑な要望がある場合、既存のテーマでは叶えられないことがあります。

https://zimfw.sh/docs/themes/

今回、私がテーマを作るきっかけとなったのは、Kubernetes の context や namespace をプロンプトに表示したいと思ったことです。  
業務で Kubernetes を触っていると、選択している context や namespace をさっと確認したくなる場面が多く、毎回コマンドを打つのが面倒でした。  
そこで、プロンプトに表示させようと思い立ちました。しかし、既存のテーマには Kubernetes の情報を表示するものがなかったため、自分で作ることにしました!

## :wrench: Zimのプロンプトの作り方について

Zim のプロンプトを作るのは初めてだったので、まず調べましたが、公式ドキュメントには作成方法がありませんでした…。

ただ、公式テーマは `zmodule` という Zim のモジュール管理機能と同じ形で設定できます。  
独自に作ったものも `zmodule` で読み込ませれば良さそうだと分かりました。

`zmodule` の読み込み方法は、README にまとまっており、以下が参考になりました。

https://github.com/zimfw/zimfw?tab=readme-ov-file#zmodule

実際のテーマも OSS で公開されており、とても参考になります。  
以下のリンクは `asciiship` というテーマのコードです。50行程度で簡単に作れることがわかります。  
Git の情報は別モジュールとして提供されているため、簡単に表示できます。

https://github.com/zimfw/asciiship/blob/master/asciiship.zsh-theme

## :sparkles: 作成したプロンプトの紹介

今回は下記のようなプロンプトを作成しました!
表示したかった下記の情報を盛り込んだプロンプトにしています。

- kubernetesの関連情報
- Gitの情報 ← 今まで使っていたので、作ったやつにも表示できるようにしました
- 時刻表示 ← 時刻表示はあると便利なので、表示できるようにしました

```
2024-12-02 11:18:36 (⎈|kube-context:namespace) main [!] $
```

Kubernetes の情報は `kube-ps1` という OSS を `zmodule` で読み込ませることで問題なく動作しました。

https://github.com/jonmosco/kube-ps1

時刻表示は 1 秒ごとに更新するようにし、常に最新の時刻を表示できるようにしています。

作成したプロンプトは以下に公開しています。ご利用は自己責任でお願いします :bow:
30分ほどで作成したので、粗がありますのでご了承ください :bow:

https://github.com/0ta2/chronoship

## :star: まとめ

当初欲しかったプロンプトを作成できました!  
30行程度のスクリプトで作れるため、とてもお手軽でした。  
今後もこのプロンプトを育てていきたいと思います。
ファイルの更新日時はいつどうやって変わるか

# はじめに
少し前からXでファイルに更新日時が全部同じだから〇〇だという主旨の投稿が増えました。その背景についてはこの記事では触れませんが、ファイルの更新日時を含めたWindowsにおけるタイムスタンプについて改めてまとめてみたいと思います。

# タイムスタンプ
まず、ファイルのタイムスタンプとは、それぞれのファイルに付与される時刻情報です。

以下はC:\test.txtを作成した直後のプロパティです。作成日時、更新日時、アクセス日時の3つが表示されています。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/549537/7736af0e-88ae-1d6c-a307-424d5e12d3cb.png)

そして同じファイルをFTK Imagerで確認すると、もう一つタイムスタンプがあることがわかります。
プロパティにはなかったChange timeというものが追加されています。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/549537/15de6272-879d-26dc-3721-e480f6802c84.png)

# タイムスタンプの変化
次に別のファイルtest2.txtを作成し、今度はこのファイルを作成した後に追記してみます。すると以下のようになります。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/549537/ef46c5da-8a73-c2da-d0e8-528368870d1f.png)

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/549537/deca1e90-214a-fe3a-6800-86dc6bfab466.png)

作成日時はそのままで、それ以外の日時は追記した時点で更新されていることがわかります。

このようにファイルの操作によってタイムスタンプが変化するため、タイムスタンプによってファイル操作がどのように行われたかわかるようになっています。

これらの変化についてはSANSのポスターにまとまっています。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/549537/c1c57231-2dbc-feff-40aa-6454b4ea467a.png)

https://www.sans.org/posters/windows-forensic-analysis/

さらに厄介なことに、あと4つもタイムスタンプがあります。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/549537/9ad9ec8e-82d2-cf22-f96e-75c4ca61fcc3.png)

これはFile_Nameと呼ばれる上記とは別の情報です。これらも作成、更新、アクセス、変更という4種類がありますが、単純にファイルが変更されたから更新されるというものではありません。
File_Nameの変化のルールは以前はSANSのポスターに記載されていましたが、いつの間にか消えていました。

# 更新日時がすべて一致するケース
それではXで話題になっていた更新日時がすべてのファイルで一致するケースとはどのようなケースでしょうか。思いつく限りで挙げてみました。
1. すべてのファイルが同じタイミングで作成された
可能性としてはあり得ますが、プログラムを使って一気に作成する必要があり、通常の利用では考えにくいです。
2. すべてのファイルが同じタイミングで更新された
こちらも同様にあり得ますが、プログラムを使って一気に更新する必要があるため考えにくいです。
3. 別のマシン上で作成されたファイルがコピーされた
これは可能性としてはあり得ますが、別のマシンからコピーされた場合、更新日時はコピー元のファイルのタイムスタンプを引き継ぐことが多いです。ただし転送方法によっては引き継がない場合もあるので可能性としてはあり得ます。なお、ローカルでコピーした場合は引き継がれます。
4. その他の可能性
例えばブラウザでダウンロードした場合はダウンロードの方法によっては更新日時がすべて一致するかもしれません。ブラウザでzipファイルをダウンロードし、ローカルで解凍した場合、ファイルの更新日時はzipファイル内に含まれているものを引き継ぐ場合とそうではない場合があります。後者であればすべてのファイルの更新日時が一致してもおかしくはありません。

# 結論
結論としてはこれだけで何かを断定できるものではありません。そのファイルがどこから来たものかはブラウザの履歴、LNKファイル、Shellbagsなどのアーティファクトを調べることで調査できる可能性があります。

もし今回の話題でファイルの更新日時に興味を持たれた方がいれば、ぜひフォレンジックについても調べていただけると引退したフォレンジッカーとしては大変うれしく思います。
なお、調査する際には正しい手順で証拠保全しなければ証拠として認められない可能性が高いです。特に裁判になりそうな事案ではお近くのフォレンジックベンダーにご相談ください。
モジュールに他のモジュールをincludeする

# モジュールがモジュールをincludeして、それをincludeしたクラスはそれらのモジュールのメソッドを使うことができる。
```rb
irb(main):001* module Greeting
irb(main):002*   def hello
irb(main):003*     'hello'
irb(main):004*   end
irb(main):005> end
=> :hello
irb(main):006* module Aisatsu
irb(main):007*   include Greeting
irb(main):008*
irb(main):009*   def konnichiwa
irb(main):010*     "こんにちは。"
irb(main):011*   end
irb(main):012> end
=> :konnichiwa
irb(main):013* class User
irb(main):014*   include Aisatsu
irb(main):015> end
=> User
irb(main):016> user = User.new
=> #<User:0x000000010bd2ce70>
irb(main):017> user.konnichiwa
=> "こんにちは。"
irb(main):018> user.hello
=> "hello"
```

```rb
irb(main):019> User.ancestors
=> [User, Aisatsu, Greeting, Object, PP::ObjectMixin, Kernel, BasicObject]
```

https://gihyo.jp/book/2017/978-4-7741-9397-7
PMOが実践する！Backlogを活用した実践的プロジェクト可視化術

## はじめに

皆さん、こんにちは。
PMO・開発管理を担当している@hbyen0605です。
Backlogで実現する、今すぐ使える実践的なプロジェクト可視化テクニックを徹底解説します。

## なぜこの記事を書いたのか

多くのチームでBacklogを使用していますが、その機能の10%程度しか活用できていないと感じています。実は、Backlogには**プロジェクトの健全性を可視化する驚くべき使い方**があるのです。

## 従来の使い方の限界

一般的なBacklogの使用方法：
- チケット管理
- ガントチャート
- Wiki管理
- Gitリポジトリ連携

これだけでは、以下の課題が残ります：
1. プロジェクトの健全性が見えない
2. チーム間の連携状況が把握できない
3. リスクの早期発見が難しい

## 実践！Backlogの隠れた活用術

### 1. 「複合的な進捗指標」の設定

Backlogのカスタム属性を活用した、新しい進捗管理方法です：

```
カスタム属性の設定例：
- 技術的難易度（1-5）
- ビジネスインパクト（High/Middle/Low）
- 依存タスク数（数値）
- レビュー回数（数値）
- 工数予測精度（予測/実績の比率）
```

これにより：
- 単純な進捗率ではない、質を考慮した進捗把握
- リスクの早期発見
- リソース配分の最適化
- 見積もり精度の向上

が可能になります。

### 2. 「タスク品質モニタリング」の構築

Backlogの課題の状態遷移を利用した品質管理システム：

```
監視ポイント：
1. レビュー差し戻し率
2. 課題ステータスの戻り率
3. 追加課題の発生率
4. 質問・コメント数の推移
```

効果：
- 品質リスクの早期発見
- チーム内コミュニケーションの改善
- レビュー効率の向上

### 3. 「プロジェクトヘルスチェック」の実装

Backlogのデータを基にした、健全性評価システム：

```
評価指標：
1. チケット滞留時間
2. マイルストーン達成率
3. 担当者別の作業負荷バランス
```

これにより：
- 問題の早期発見と対処
- リソースの最適配分
- プロジェクトの健全性維持

## 具体的な導入ステップ

### Step 1: カスタム属性の設定（所要時間：2時間）
1. プロジェクト設定画面でカスタム属性を追加
2. チームと属性の定義を合意
3. 既存チケットへの適用

### Step 2: 品質モニタリングの構築（所要時間：1日）
1. 状態遷移のワークフロー設定
2. チェックポイントの定義
3. レポーティングテンプレートの作成

### Step 3: ヘルスチェック体制の確立（所要時間：2日）
1. 評価基準の設定
2. チェックリストの作成
3. 定期レビューの仕組み化

## 具体的な事例

### Case 1: 依存関係の複雑化を早期発見
```
現象：特定機能の依存タスク数が急増
対応：アーキテクチャの見直しを早期に実施
結果：リリース遅延を防止
```

### Case 2: レビュー効率の改善
```
現象：特定カテゴリのレビュー差し戻しが多発
対応：レビューチェックリストの整備
結果：差し戻し率を30%削減
```

## Tips集

1.Backlog活用のコツ
   - カスタム属性は最大5つまでに抑える
   - ワークフローは必要最小限にする
   - 定期的なデータクリーニングを忘れずに


2.失敗しないための注意点
   - チーム全体での合意形成を忘れずに
   - 段階的な導入を心がける
   - 定期的な振り返りと改善を実施

## まとめ
Backlogの隠れた機能を活用することで、プロジェクトの「見える化」は劇的に改善できます。本記事で紹介した手法は、明日から実践可能なものばかりです。

## 一緒に働く仲間を募集しています！
株式会社コネクター・ジャパンでは一緒に働いてくれる仲間を募集しています！

事業拡大に伴い、エンジニアを大募集しています。
興味のある方は下記リンクから弊社のことをぜひ知っていただき応募してもらえると嬉しいです。
▼会社について
https://www.wantedly.com/companies/cnctor/about
▼代表メッセージ
https://cnctor.jp/10years-anniversary/
▼応募はこちら
https://www.wantedly.com/companies/cnctor/projects
CH32X035でBVE対応マスコン操作用基板を作る

__ATSex__ 等でボタンからのキーボード入力を行う必要が出てきました。
キーボード入力は __USB-HID__ ができるマイコンが必要になります。
__USBーHID__ 対応の安価なSoCとして __RP2040__ があげられます。
__RP2040__ はマイコン単体では1ドルですが、フラッシュメモリが別体のため、どうしても2ドル以上となり、割高となります。
さらに安価なチップとして __CH32X035__ や __CH552__ 等があります。
__CH552__ は __CDC（シリアル）__ と __HID__ が共存可能ですが、GPIOのピン数が少ないことがデメリットです。
今回は、1個５０円の格安マイコン __CH32X035__ を使用してHID基板を作ってみました。
![ch32X035-HID-1.JPG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/285344/d9d20f83-f9ab-f13c-0f03-ed8d16b3c547.jpeg)
# CH32X035の特徴
- 安い
- ピン数が多い
- USB対応
- USB PD対応
- ArduinoIDE対応
# GPIO数
CH32X035はGPIOのピン数が多いことが特徴です。（型番にもよりますが）
CC1/CC2を使用しない場合、最大、25ピン使用可能な __CH32X035G8U6__ を選定しました。
# USB HID/CDC対応
今回の目標はCH552の代わりといて __HID__ と __CDC__ が使用できるようにしたいと考えていました。
しかし、私の能力的にCDCが使用できず、__UART__ で __USB-シリアルボード__ に接続する形で落ち着きました。
このため、売りであるはずの安さが失われてしまいました。
# USB PD対応
__CH32X035__ は __USB PD__ が特徴です。
一応、使用可能にしており、PDから５Vの生成も可能としました。
# ボード形状
__ArduinoUno__ のプラットフォームを採用しました。
# 回路図
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/285344/a706a829-b9eb-8359-2c8f-a9849197937c.png)
# プログラム
東京電機大学　鉄道研究部において使用した横浜市営地下鉄のワンハンドルマスコンのプログラムになります。
https://github.com/taisirou/ch32x035-HID
横浜市営地下鉄のワンハンドルマスコンはワンマン対応改造を施されており、ドア開閉に使う車掌スイッチの機能も有しています。
今回、制作したプログラムにはまだそれらが入っていないものになります。
# デメリット
当初の目論見だったCH32X035単体でのCDCとHIDの共存が出来ませんでした。
ただし、プログラムの動作上、共存する方が良いかは悩みどころです。
HIDにおいてキー保持が存在するため、プログラムが若干難しくなるということが挙げられます。
このため、HIDとUARTを専用のマイコンボードにするかRP2040のようなデュアルコアのSoCを使う方が好ましいのかもしれません。
【Rails】scssとは

## SCSSとは
Sass（Syntactically Awesome Stylesheets）の拡張構文の一つ。
SassはCSSを拡張したプリプロセッサであり、SCSSはその中で特にCSSに近い記法を採用した形式。
CSSの互換性を保ちながら、次のような便利な機能を提供します。

### SCSSの特徴
- **ネスト構造**：コードの親子関係を簡単に記述できる。
- **変数の使用**：スタイル全体で使い回し可能な変数が定義できる。
- **再利用可能なパーツ**：ミックスインや関数で、コードを再利用できる。
- **演算**：スタイルの数値や色を動的に計算可能。

#### CSS
```css
.container {
  color: black;
}
.container .item {
  color: red;
}
```

#### SCSS
```scss
.container {
  color: black;
  .item {
    color: red;
  }
}
```

## SCSSにコードを書くのはどんな時？
間違ってcssにコードを書いてしまい、コード自体は合ってるのに変更されないという問題が起きたため、この記事を作成しました。
scssに書く必要があるのはどんな場合なのでしょうか？

CSSとSCSSの記法は似ていますが、下記の場合はSCSSを使用する方が便利です。

### 1. Bootstrapを使用しているとき
Bootstrap自体はSCSSで構築されており、SCSSを使うことで次のようなメリットがあります：
- **カスタマイズが容易**：テーマカラーや間隔、フォントなどをSCSS変数で一括設定できる。
- **必要な機能のみをインポート**：未使用の機能を除外することでファイルサイズを削減可能。

#### 例: 必要な機能のみをインポート
```scss
@import '~bootstrap/scss/functions';
@import '~bootstrap/scss/variables';
@import '~bootstrap/scss/buttons';
```

### 2. Webpackerを使用しているとき
Webpackerを使用している場合、CSSやJavaScriptなどのフロントエンド資産を app/javascript にまとめて管理している。
WebpackerはSCSSをネイティブにサポートしているため、SCSSファイルをそのまま使う。
.yamlと.ymlは何が違うの？


## はじめに

プログラミングや設定管理の世界で、YAML形式のファイルを扱う際に `.yaml` と `.yml` の2つの拡張子に出会うことがあります。一見、同じように見えるこれらの拡張子について、解説していきます。

## 拡張子の本質的な同一性

### 技術的な互換性
まず、最も重要なポイントは、`.yaml` と `.yml` が**完全に同一の内容と構造を持つファイルを表している**ということです。どちらの拡張子を使用しても、YAMLパーサーは全く同じようにファイルを読み取り、解析します。

### 内部構造の同一性
```yaml
# .yml でも .yaml でも、この設定は全く同じように解釈されます
database:
  host: localhost
  port: 5432
  username: admin
  password: secret
```

## 歴史的な背景と進化

### YAMLの誕生
- 2001年にYAMLが仕様として最初に提案された当初は、`.yaml`が推奨される拡張子でした。
- 当初は「YAML Ain't Markup Language」という名前の通り、XMLの代替として考えられていました。

### 実践的な使用の広がり
時間の経過とともに、開発者たちはより短く入力しやすい `.yml` を好むようになりました。これは、多くのコマンドラインツールやCI/CDプラットフォームでの実際の使用パターンに大きく影響されています。

## 実際の使用状況

### .yml が優勢なケース
1. **コンテナ技術**
   - Docker Compose
   - Kubernetes設定ファイル
   ```yaml
   version: '3'
   services:
     web:
       image: nginx
       ports:
         - "8080:80"
   ```

2. **CI/CDパイプライン**
   - GitHub Actions
   - CircleCI
   - Travis CI

### .yaml が使用されるケース
1. 学術的な文書
2. 正式な仕様書
3. 一部の言語固有の設定ファイル（特にPythonエコシステム）

## 選択する際の実践的なガイドライン

### 推奨される選択方法
1. **プロジェクトの既存の慣習に従う**
   - 既に `.yml` を使用しているプロジェクトなら、その慣習を継続する
   - 新規プロジェクトの場合は `.yml` を推奨

2. **チーム内の一貫性**
   - 拡張子は統一することが最も重要
   - 混在させると可読性と管理性が低下する可能性がある

3. **ツールとの互換性**
   - ほとんどのモダンなツールは両方の拡張子を完全にサポート

## 注意点と落とし穴

### 避けるべき罠
- 拡張子の違いを理由にファイルの互換性を疑わない
- 不必要に拡張子を気にしすぎない
- チーム内で統一性を失わない

## 実践的なヒント

### 拡張子選択のチートシート

|サービス|拡張子|
|-|-|
|**Docker/Kubernetes**|`.yml`|
|**Python プロジェクト**|どちらでも可|
|**厳密な仕様書**|`.yaml`|
|**個人プロジェクト**|お好みで選択|

## まとめ

`.yaml` と `.yml` は本質的に同一のファイル形式を指します。重要なのは、拡張子ではなく、ファイルの内容と一貫性です。プロジェクトの文脈や既存の慣習に合わせて、適切に選択してください。

## 参考資料

https://prograshi.com/language/json/defference-between-yml-and-yaml/