OmniAICreator/Qiita-1.07M huggingface dataset:
GHCのFFI&ForeignPtrに関するパフォーマンスの調査（C++編）

この記事は、[Haskell Advent Calendar 2022](https://qiita.com/advent-calendar/2022/haskell)の22日目の記事です。

GHCのFFIとForeignPtrに関するパフォーマンスの調査をしました。
至らぬところがあるかと思いますが、よろしくおねがいします。


# 概要

Hasktorchというプロジェクトで行列の演算にpytorchのc++のライブラリ(libtorch)を使っています。
10x10の行列積の計算のベンチマークで、Hmatrixが1.03usに対して、Hasktorchでは3.21usかかりました。
２つのライブラリは構造がよく似ていて、オブジェクトの管理はどちらもForeignPtrを使っていますし、計算はCのライブラリのblasを使っています。違いはHmatrixがC言語のライブラリを扱っているのに対して、HasktorchはC++言語のライブラリを扱っているというところです。2usの違いがパフォーマンスに現れました。

CないしC++関数を使うにはFFIが必要です。Cの関数のパフォーマンスはよく調べられていて、
例えば[こちらに行列計算のライブラリの一覧](https://github.com/Magalame/fastest-matrices)があり、FFIを使っているのがHmatrixで、Haskellだけで書かれているのがdense-linear-algebra(DLA)です。
CのFFI単体のベンチマークは[こちら](https://qiita.com/mod_poppo/items/793fdb08e62591d6f3fb)です。

これらのベンチマークからいえることは、実装の違いで数100ns程度の速度の差がでるということです。
数usの違いは出てこないように見えましたので、C++を使っているHasktorchが遅い原因を調べることにしました。

遅い原因は次の複合的なものでした。

* C++のライブラリ(libtorch)が遅い
* FFIのSafe Callを使っていた
* C++の例外の補足のため
* Inline展開されてない
* ForeignPtrのc finalizerが遅い

# C++のライブラリのベンチマーク

行列の計算以外のオーバーヘッドを調べるため、2x2の行列足し算についてベンチマークをしました。
https://discuss.pytorch.org/t/too-much-c-api-overhead/164381
C言語で書いたプログラムは0.309nsに対して、C++のライブラリ(libtorch)は894ns程度かかりました。

下記のリンクから、小さなテンソルの生成コスト、DeviceGuard、カーネル関数を選択するコストが高いそうです。

* 関連するリンク
    * https://github.com/pytorch/pytorch/issues/45139
    * https://github.com/pytorch/pytorch/issues/13049
    * https://discuss.pytorch.org/t/why-libtorch-tensor-indexing-much-slower-than-c-vector/95138


# inline-c-cppのベンチマーク

inline-c-cppはC++の例外をHaskell側に返すために、例外の種類、例外のメッセージ、例外の型、例外の種類ごとのポインタといったデータが必要で、それぞれallocを使って領域を確保していました。
また、inline-c-cppはFFIのUnsafe Callに対応しておらず、結果一回の呼び出しに250ns程度かかっていました。

次のPRでinline-c-cppは改良済みです。
https://github.com/fpco/inline-c/pull/140

# Inline展開

Inline展開が行われてないコードがあったので削除しました。
一つ一つは数十ns程度のオーバーヘッドですが、複数あって百ns程度のオーバーヘッドになっていました。

# ForeignPtrのc finalizerのベンチマーク

GHCはC/C++のオブジェクトをGCで処理できるように削除されるときに呼ばれるc finalizerを設定できます。
c finalizerはweak pointerのリストで管理されています。c finalizer自身もリストになっています。
[ezyangさんのblog](http://blog.ezyang.com/2014/05/the-cost-of-weak-pointers-and-finalizers-in-ghc/)にその説明があります。実際のベンチマークがなかったので、調べてみました。

単にメモリの確保を行うだけのベンチマークですが、
c finalizerを使うと146nsかかり、使わないと43.4nsと100ns程度の違いがあります。
https://github.com/junjihashimoto/ffi-benchmark

c finalizerが遅い原因は次のようなものでした。

* weak pointerのリストで管理されている。(メモリのレイアウト的な問題)
* weak pointerにあるc finalizerがリストで管理されている。(メモリのレイアウト的な問題)
  * つまりc finalizerはリストのリストで管理されている。（これで数十nsは失われます。）
* c finalizerのセットに無駄が多い。
  * newForeignPtrを呼び出し、IORefで領域を確保、atomicなロックを使って、c finalizerをセット
  * 初期構築なのでlockを使わないで設定できるはず。
* minor gcのたびにすべてのc finalizerのチェックが行われる。
  * copy gcの良さが台無しになり、gcの処理時間が増加。

Hmatrixはメモリの確保をGHCにまかせていて、c finalizerを使わないのでパフォーマンスがよいです。

# まとめ

* HmatrixとHasktorchを比較してc++のFFIが遅い原因を調べました。
* 遅い原因は次の5つ(C++特有の問題は例外とc finalizerのところだけです。)
  * C++のライブラリ(libtorch)が遅い
  * C++の例外の補足のため
  * FFIのSafe Callを使っていた
  * Inline展開されてない
  * ForeignPtrのc finalizerが遅い
* Hmatrixは上記の問題を回避しているからすごい。
OpenWrt を自宅検証環境用に便利に使う(2)

# OpenWrt を自宅検証環境用に便利に使う(2)

## [前回](https://qiita.com/JUNKER_TOMATO/items/e81c3a616f3dab4beeb2)まで
OpenWrtについてのご紹介と、私の自宅ネットワークをさらしました。

## 自宅検証環境用に便利に使う

実は何も考えなくても便利に使えます…

OpenWrtは 標準で家庭用無線LANルーターとして動作するための基本レベルの機能を持っています。
* DHCPサーバ
* DNSフォワーダー
* NAPT(IPマスカレード)
* PPPoEクライアント
* 管理用Web-UI

OpenWrtは、IPv4のDHCPサーバとDNSフォワーダーとして dnsmasq を利用しています。
DHCPリクエストの中で受信したクライアントのホスト名をキャッシュして名前解決に使えます。

このため、DHCPでIPの割り当てを行いつつも、OSに設定したホスト名で名前解決できてしまいます。

検証用仮想マシンにLinuxやWindowsなど適当にガシガシインストールしても、IPv4アドレスをDHCP割り当てにしておけば、インストール時に設定した任意のhostnameで SSHやRDPできてしまいます。
これが想像以上に便利で快適です。

dnsmasq 自体は buffaloのルータの標準ファームウェアなどでも利用しているはずなのですが、セキュリティ対策のためか、この機能は有効になっていないようです。

逆に、例えばVCSAなど、IPv4アドレスを固定で割り当てを行う場合は自動でホスト名登録はできません。ただ、OpenWrt の場合、Web-UIから DNSmasqのレコード登録が行えるので、簡単な操作で名前解決ができるようになります。
DNSmasq のDHCPでMACアドレスに対して固有のIPアドレスの払い出しを行えるようも、Web-UIでできるため、DHCP運用をしつつ、常に同じIPアドレスを使うこともできます。

加えて、OpenWrt の opkg コマンドで　ルータ上に tcpdump などの CLIベースのネットワークユーリティティをインストール可能です。検証用機器からインターネットへ抜けていくパケットをOpenWrt ルーター上でキャプチャして解析などに役に立ちます。

OpenWrtは　初期状態で Web-UIを持ったDHCP+DNSフォワーダー設定がされており、追加設定がいらないのは大きなメリットです。
OpenWrt自体のインストールが難易度が高いといえますが、ぜひ挑戦してみてください。

## まとめ
自宅検証環境でOpenWrtを使った時の利点についてご紹介しました。

## 次回
未定。。。。
22. CNN

# Convolutional Neural Network
　MLPの次はCNNについて習うと思います。畳み込みニューラルネットワークと書くとなんだか語感があれなのですが、パーセプトロンと同じく人間の視野から思想を得ていたと思います。

　画像を主に対象とするものです。画像データ（WidthｘHightｘChannel）を入力し、画像より小さいフィルターをスライドさせながら適用し、再度「画像」を出力とします。この時出力される「画像」は、フィルターのサイズにもよりますが、一般的には入力された画像のより小さく（WidthｘHightが小さい）、Channelは多くなります。フィルターを繰り返し適用すればするほど、きちんと学習ができたモデルであれば、何らかの抽象的な表現空間を得ているはずです。

　視覚的に非常にわかりやすい[例](https://stanford.edu/~shervine/l/ja/teaching/cs-230/cheatsheet-convolutional-neural-networks)が作成されています。

　過去に一度畳み込みは実装しましたが、今のFortLearnerには入っていません。

# Convolution
　初めて学術的な用語として畳み込みを使ったのは、関数の畳み込みでした。画像を例えばWｘHｘC(WidthｘHightｘChannelの並びです。フレームワークにより並びが異なるので、気を付ける必要があります。[RGBの並びが違う](https://note.nkmk.me/python-opencv-bgr-rgb-cvtcolor/#:~:text=OpenCV%E3%81%AE%E9%96%A2%E6%95%B0imread()%E3%81%A7%E7%94%BB%E5%83%8F%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB%E3%82%92%E8%AA%AD%E3%81%BF%E8%BE%BC%E3%82%80%E3%81%A8%E8%89%B2%E3%81%AE%E9%A0%86%E7%95%AA%E3%81%8CBGR%EF%BC%88%E9%9D%92%E3%80%81%E7%B7%91%E3%80%81%E8%B5%A4%EF%BC%89%E3%81%AB%E3%81%AA%E3%82%8B%E3%80%82%E4%B8%80%E6%96%B9%E3%80%81Pillow%E3%81%A7%E3%81%AF%E8%89%B2%E3%81%AE%E9%A0%86%E7%95%AA%E3%81%AFRGB%EF%BC%88%E8%B5%A4%E3%80%81%E7%B7%91%E3%80%81%E9%9D%92%EF%BC%89%E3%82%92%E5%89%8D%E6%8F%90%E3%81%A8%E3%81%97%E3%81%A6%E3%81%84%E3%82%8B%E3%80%82)よりはましな気がします）を入力として、フィルターをWｘHｘCｘ$N_F$とすると、出力される画像は、$W_F$ｘ$H_F$ｘ$N_F$となります。ここで、$W_F$と$H_F$は以下で与えられます。
```math
W_F(H_F) = \frac{W(H) - W_F(H_F)}{S}
```
$S$はストライドの大きさで、フィルターをいずれかの位置で適用した後、次に適用する位置は何ピクセルずれた位置であるかを指定します。大きくすればするほど出力画像は小さくなります。小さいままでは、出力画像から十分に小さい（～抽象的な表現？）が得られるまで時間がかかり、あまり大きな値では、畳み込みごとの各ピクセルの依存関係がなくなってしまいます。

　単純に実装してしまうと4重ループになってしまいます。深層学習ではミニバッチ学習（CNNでは一度に複数枚の画像を投入する）を行うので、CNNの入力は WidthxHightxChannelxBatch の並びで（PytorchやTensorflowではBatchが一番最初に来ます。多分RowMajorだからだと思います。Batchのループは独立に適用できるので、最も内側に配置すべきです。FortranはColumnMajorのため最も外です。初めてPytorchの並びを見たときにはRowMajor/ColumnMajorは知らなかったのですが、なんてわかりにくいんだと思いました）、フィルターを$W_F$ｘ$H_F$ｘ$C$ｘ$N_F$です。ループ構造としては（並びは最適でないと思います）、
1. ミニバッチループ（Batch）
1. フィルターループ（$C_F$）
1. Widthループ（$W_F$）
1. Hightループ（$H_F$）

のようになります。これは当然非常に重いですが、3重ループに軽減する方法があります。[ゼロからつくるDeepLearningの1巻](https://www.oreilly.co.jp/books/9784873117584/)に解説があります。im2colという変換で、画像とフィルタを画像の形式に変換し、畳み込み処理を行列積に変えてしまいます。Kmeansなどでもふれたとおり行列積は非常に高度に最適化が施されているので、相性が良いのですが、元のデータに加え行列化したデータを作成されるため、メモリの消費が激しくなります。

　ちなみにConvolutionは画像だけでなく、時系列データに使われることもあります。時系列を1行しかない画像とみなせばそのまま適用できます。

　画像に関しては長らくCNNのみが用いられてきましたが、[MLPMixer](https://arxiv.org/abs/2105.01601)や[ViT](https://arxiv.org/abs/2010.11929)などのモデルも出てきて、少なくともほかの選択肢も出てきたようです。



以上
Excel VBAってなに？

IT化や業務効率化の中でツールを使われる機会が増えてきて
「Excel VBA」や「マクロ」「RPA」に目を触れる機会が多くなってきました。

今回は、**Excel VBA**にフォーカスして記事を書いていきます。

## はじめに

VBAと検索すると「VBAマクロ」や「VBAとマクロの違い」という検索結果が出てくることもあります。
私自身、調べれば調べるほど混乱していきました。
そのため曖昧なまま独学でコーディングをし、不完全燃焼な状態になってました。
そんな中で独学のままでは。。。。と思い、VBAエキスパート（Excel VBA ベーシックとスタンダード）を取得する機会があり、
勉強を通じて曖昧な点をクリアできました。
その経験と備忘を兼ねて、書いていきたいと思います。

## VBAとマクロの違い

### VBAとは
Microsoft社が提供しているプログラム言語のこと。
そのためMicrosoft提供の Word、Outlook、Excel、Accessで使える。
Excel VBAの利用人口が多いため、VBAというと Excel VBAを指すことがほとんどである。

### マクロとは
マクロはコンピューターの操作を自動化する機能のそのもののことを言います。いわゆる「便利な機能」というものです。
そのため、Excelには「マクロの記録」という機能があります。

【補足】
マクロ言語（マクロげんご）もあります。
マクロを記述するコンピュータ言語である（キー操作をそのまま記録・再現する、いわゆるキーマクロ等のように、言語を持たないマクロ機能もある）。プログラミング言語的な機能を持つものもあれば、持たないものもある。ソフトウェアの制御や自動化にとどまらず、普通のプログラミング言語のような汎用的な処理をすることが可能なものも存在する。また他に、テキスト変換などを記述する変換言語もマクロと呼ばれることが多い。

参考：テキストエディタ内にもマクロがある。

## Excel VBAでできること
・文字列操作、変換：ドキュメント作成やデータ整理を効率化することができます
・Web API連携：Webサイト・アプリ上の処理をローカルのVBAプログラム内で実行できます
・手動作業の自動化：マクロによって入力や印刷などの作業を自動化することができます
・

## Excel VBAでできないこと（難しいこと）
・ワークシートの容量以上の大容量データ処理
・VBAをサポートするアプリケーション群の範囲外との連携
・文字イメージ認識など
・同一画面内において他アプリケーションの相対位置を認識できない
　→異なるアプリケーション同士の操作はRPAが得意とする機能である。

## Excel VBA以外のVBAでできること
VBAはMicrosoftOfficeの各アプリケーションでも使用できます。
そのため、本項では事例を挙げます

Outlook
・予定の自動登録
・開いているメールの添付ファイルを自動保存

Access
・簡易なデータベースの開発
・在庫管理システム、発注予約システム、検索機能を伴うシステムなどの構築

Powerpoint
・テキストボックスのサイズ設定
・テキストボックスを複数スライドにまとめて作成など

## まとめ
VBAは、Micorsoft社のオフィスシリーズに搭載されているプログラミング言語です。
Excel内での業務効率化・小規模なツール開発などのほかに、Office製品全般で活用できます。
汎用性の高いスキルでありますが、アルファベット表記での開発になっていくため
知見のない方は抵抗感もってしまう、そして属人化やブラックボックス化の温床にもなりやすいです。
使用する際は業務手順書やフロー図に書き起こす・開発画面内にメモを分かりやすく残すのも運用していくためのポイントとなります。
iOSアプリのデータ保存場所

## 保存場所
- メモリ
  - NSCache：メモリが足りなくなれば自動的にアイテムが消される
  - Dictionary や Array
- ファイルシステム
  - ディレクトリ：基本的に iCloud へバックアップされる
  - UserDefaults：プリミティブ型のユーザ設定を保存する、起動時にメモリに展開される、iCloud へバックアップされる
  - データベース：Core Data、Realm、SQLite など
  - KeyChain
<!--more-->

## ファイルシステムの構造
```
/
    Applications/ （大事）
    Developer/
    Library/
    System/
    User/
    bin/
    dev/
    etc/
    lib/
    mnt/
    private/
    sbin/
    tmp/
    usr/
    var/ （大事）
```
## /Applications
```
/
    Applications/
        {$appname}.app/: pre-installed apps
```

## /var
```
var/
    containers/
        Bundle/
            Application/
                {$uuid}/: App Store app/
                    BundleMetadata.plist
                    {$appname}.app/
    mobile/
        Containers/
            Data/
                Application/
                    {$uuid}/: App Store app's data、アプリが削除されると消える
                        Documents/ - ユーザデータ、ユーザに見せてもいいファイル
                        Library/ - ユーザへ見せないファイル
                            Caches/ - iCloudへバックアップされない
                            Preferences/
                                {$bundle ID}.plist - UserDefaults、セキュアではない
                            xxx/
                        SystemData/
                        tmp/
```

## Keychain
アプリが削除されても消えない
```
/
    var/
        Keychains/
            keychain-2.db: iOS Keychain (SQLite DB file)
```
Rails 自分用


controllerに処理を書く
```ruby:controller.rb
def "html.erbとつなげる名前" ⇒ここに書いたものがhtml.erbとつながる(?)
    #処理を書く
end

#通常の処理
def 〇〇〇
    senaka = "タヌキのせなか"
   @html.erbで使う名前 = "タヌキのおなか"（変数など）
   @html.erbで使う名前２ = senaka
#html.erbで<%= @以下 %>で上記の文を出力できる
end

#select文
def □□□
    @html.erbで使う名前(html.erbと書く) = SQLの名前.all ⇒ 全検索
                                  .find(params[:検索したいデータのメンバ名]) ⇒ SQLなどのWHERE id = #{id} データ名で検索してそれに該当するカラムを取り出す。
end

#カラムを新規作成する際に呼ぶメソッド
def new
    @html.erb = SQLの名前.new

#新規作成文
def create
    @(html.erb) = @名前.new(データの名前)　⇒　新しいカラム作成(?)
    if @(html.erb).save ⇒　登録が保存、反映される(?)
    else
        render (templete):new, status: :unprocessable_entity
    end
end
=begin
→renderとは、HTTPレスポンスを作るためのメソッド。「erbファイル」を使ってHTMLなどのレスポンスを作る。
    #templete: 指定したいerbファイル名(今回ではnew.html.erbファイルを指定)
              "templete:"は省略できる

    status: エラーが起きた時、どのエラーが引き起こるかを設定することができる(?)
            今回ではunprocessable_entity 422のエラーが引き起こったとしている
参照：http://railman.net/railsguides/6.1/layouts_and_rendering.html
=end
#⇒新規作成ができる。


#update文
def update
    @(html.erb) = @名前.find(params[:データメンバ名])
       if  @(html.erb).update(データの名前, 上記newで作った名前)
     redirect_to @html.erbで使う名前
       else   render :new, status: :unprocessable_entity
    end
end
    #⇒ 更新(update)ができる。

#delete文
def destroy
    @book = Book.find(params[:データメンバ名])
    @book.destroy ⇒これで削除できる
    //[routes.rbで指定している('/名前')] 名前_pathでそのページにroutes.rbの設定しているページに飛ぶ
    redirect_to books_path
end

    private
        def データの名前
           #Aの名前を要求して、それでSQLからAが見つかった場合、データB, データCに介入することができる(?)
           params.require(:A).permit(:B, :C)
        end
end
```





routes.rbにURLの設定を書く


resource :SQLの名前
get⇒リソース（操作対象となるデータ）取得
例）LoginUserモデルなら
        id, name, email
        1   Yoshi  Yoshi@example.com
これらのデータがリソースとなる。

get '/practice', to: 'home#practice', as: :practice
⇒URLに/practiceを入力すると'app/views/home/practice.erb'が表示されるようになる。

post⇒リソースへのデータ追加、子リソースの作成

put⇒リソースの全更新、作成

patch⇒リソースの部分更新

root ⇒全て共通のHTMLページ, 'OO#△△' で指定する
       'OO#△△' = 'app/views/OO/△△.erb'である。

delete⇒リソースの削除
UDHI-Labアドベントカレンダーについて

# このアドベントカレンダーについて
このアドベントカレンダーはうちの構成員の某こばさんが突然思いついた企画です
すでにクリスマス3日前なのにもかかわらずカレンダーを埋めようというかなりの無茶ぶり企画です
巻き込まれてしまった皆さんには代表者としてここで謝罪します

## 本当に申し訳ありませんでした
承認を通したのは僕なので責任をもって経緯を書いていきます

## 経緯
クリスマスが近いね
↓
アドベントカレンダーだね
↓
書いてみたいよね
↓
いろんな人を巻き込もう

## とは言っても
せっかく作ったので記事をかける方は書いて
多くの人が楽しめるものにしていけたらと思ってます
巻き込み事故にあわれてしまった人たちには申し訳ないですが
楽しんでいただけると幸いです

## 最後に
この文章は査読としてUDHI-Labの過半数の人に確認を取らせてるので
大体事実通りのはずです
テンソルと行列は何が違うのか

$$\def\bm{\boldsymbol}$$

理工系出身者の誰もが使ったことがあるけれど、意味がよくわからない（であろう）テンソルについて学んだ。テンソルと行列は何が違うのだろうか。

## 概要
- 行列は　2次元配列だが、テンソルは多次元配列の一種。0階のスカラー、1階のベクトル、2階の行列として表現可能なテンソル、そして3階以上のテンソルが存在する。
- 全ての2階テンソルは行列として表記可能だが、全ての行列がテンソルの要件を満たすわけではない。
- 【一番大事】テンソルは事実を表すもので座標系に依存しない。視点が変わっても事実は同じ。テンソルの要素はテンソルの数値的な表現手段であり、座標系が変われば値も適切に変わる。
<!--more-->

## はじめに
重力加速度は、地球上であればどこでも大体、下向きに $9.8m/s^2$ である。これを座標系上の成分で表すならば、東を $x$軸プラスの方向、北を $y$軸プラスの方向、そして空方面を $z$軸プラスの方向とするなら、$(0, 0, -9.8)$ となる。単位は $m/s^2$。

いま「下向きに」と書き、読者も疑問を持つことなくそれを受け入れたと思うが、重力の向きを下とするかどうかは完全に任意である。樹にとまっているセミが樹の幹方向を下と考えても良いし、天井にぶらさがっているコウモリが天井方向を下と考えてもいい。コウモリ座標系で重力加速度を表すと $(0, 0, 9.8)$ になり、正負が逆転する。

このように、重力加速度という事実は不変ながらも、視点の取り方、すなわち座標系の設定の仕方によって重力加速度の成分は変わる。重力加速度は 3次元ベクトル、つまり 2階3次元のテンソルであり座標系の取り方によらず不変だが、ベクトルの成分は人間座標系とコウモリ座標系では異なる。異なるが同じ事実を指しており、座標変換に伴う成分変換にはルールがある。

## 教科書の定義
そもそも何故この稿を書こうと思ったのか。物理数学を勉強する上で出会った以下の定義が理解できなかったことに端を発する。

### 座標変換に対する変換性による2階のテンソルの定義

直行行列で表現される座標変換 $\bm{R}$ によってその要素が
```math
A'_{ij} = \sum_{k=1}^{n} \sum_{l=1}^n R_{ik} A_{kl} R_{jl}
```
のように変換される行列は 2階のテンソルと呼ばれる。これはベクトルを別のベクトルへ移す行列 $\bm{A}$ が座標変換の際に満たす関係 $\bm{R}\bm{A}\bm{R}^{-1}$ ($= \bm{R}\bm{A} ^t\bm{R}$) に等価である。

上記における「ベクトルを別のベクトルに移す行列 $\bm{A}$ が座標変換の際に満たす関係 $\bm{R}\bm{A}\bm{R}^{-1}$」という記述は、$\bm{c} = \bm{A}\bm{b}$ の両辺に左から $\bm{R}$ を掛け、$\bm{A}$ と $\bm{b}$ の間に $\bm{I} = \bm{R}^{-1}\bm{R}$ を挟んで得られる次の関係式
```math
\bm{R}\bm{c} = \bm{R}\bm{A}\bm{b} = (\bm{R}\bm{A}\bm{R}^{-1})\bm{R}\bm{b}
```
において、変換後のベクトルが $\bm{c}' = \bm{R}\bm{c}$$、$$\bm{b}' = \bm{R}\bm{b}$ であることから $\bm{R}\bm{A}\bm{R}^{-1}$ が変換後の $\bm{A}'$ と対応づけられることを指している。

## 何がわからなかったのか
「直行行列で表現される座標変換 $\bm{R}$ によってその要素が〜〜〜のように変換される行列」という記述から、$\bm{A}$に何らかの制約が加わっていると解釈したのだが、これが間違え。この誤解は、直行行列、単位行列、三角行列などの、行列単体でその要素が取りうる値に制約が加わっているのではないかという類推から生じた。

## 正しい解釈は何か
$\bm{A}$を表す成分は任意でいいのだが、座標変換時に座標に従って適切に行列の値が変わることそのものがテンソルだった。テンソルという、世界のある真実を表現するものがあって、それが座標の取り方によって見え方が適切に変わる、つまり要素の値が適切に変わるという性質そのものがテンソル。
Power BI - データモデリングの悩み

最近、実際に仕事で手にするデータをもとにPower BIでレポート作成しようとするとほぼ必ずモデリングで躓きます。Power BIについて学んでいると、データモデリングのベストプラクティスはスタースキーマで、そのスタースキーマのベストプラクティスは一つのFactテーブルと、一つ以上のDimensionテーブルに分類すべき、というような文言をよく耳にします。が、FactテーブルとDimensionテーブルの見分け方などよく悩むので、自分への備忘録がてら学んだ記録をここに記してみました。（が、結局悩みを披露しただけで、Advent calendarの期日までに理解が間に合わなかったものもあるのですが、すみません！！）

## 私がよく悩むこと
私がよく悩むポイントは以下の通りです。

①そもそも手元のテーブルがFactテーブルなのかDimensionテーブルなのか迷う
②Dimensionテーブルがない
③Dimensionテーブルが少しずつ増えている

Microsoft Learnや色々な記事などを読んでもわかったようでわからないな～思っていたのですが、先日のPower BI勉強会でのPeter Myersさんのお話やYouTubeの動画やQiitaの記事で少し腹落ちしたことがあったので、その事を記載します。

#### 悩み①：そもそも手元のテーブルがFact tableなのかDimension tableなのか迷う
数値で集計したいデータがあるのがFactテーブル、そうでないものはDimension テーブルと見分けるのがよいそうです。
たまにDimensionテーブルでもデータが増えていくものがあるので、Factテーブルか？と思ってしまうこともあったのですが、私はこの説明で腹落ちしました！

#### 悩み②：Dimensionテーブルがない
Dimensionテーブルが毎回整った形で用意されているわけではない現実があります。Dimensionテーブル、用意しないままレポート作っていた時がありましたが、Yugoさんの記事などを読むとデータモデリングとしてはフィルターしたいデータをFactテーブルから抜き出し、ちゃんとDimensionテーブルとしてテーブルを作るのがよさそうです。

https://qiita.com/yugoes1021/items/12a40a5089fc5b5167c5

#### 悩み③：Dimensionテーブルの値が少しずつ増えている
でもやっぱり製品マスターや人事マスターなど、少しずつ値が増えていくDimensionテーブルがあり、扱いに困ることがよくあります。まだ腹落ちできていないのですが、下記の動画などで説明されていそうなので、冬休みの宿題にすることにしました！

https://guyinacube.com/2021/02/17/working-with-slowly-changing-dimensions-in-power-bi/

間に合わなくてすみません！いつか更新します！
IntuneでWindows共有デバイスを構成する

この記事は [corp-engr 情シスSlack（コーポレートエンジニア x 情シス）#1 Advent Calendar 2022](https://adventar.org/calendars/7756)  21日目の記事です。

# はじめに
通常、業務で使うPCは1人1台で使うことが多いと思いますが、要件によっては1台のPCを複数人で共有して使う場合もあると思います。本記事では AzureAD Join してIntuneで管理しているWindowsPCを共有デバイスとして構成する方法を紹介します。

# 初期設定
ここで言う初期設定とはAzureAD Join と Intune への登録のことを示します。
AzureAD Join および Intune の登録はデバイス登録マネージャアカウントを利用して行うのが良いでしょう。
Intune登録後はプライマリユーザーの情報を削除します。プライマリユーザーが割当がないデバイスが「共有デバイス」として扱われます。
https://learn.microsoft.com/ja-jp/mem/intune/remote-actions/find-primary-user
![スクリーンショット 2022-12-22 1.06.02.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/140000/adc9afa8-6965-694e-15c6-8fd85466402e.png)


# 共有デバイス用の構成プロファイルを配布する
次に共有デバイス用の構成プロファイルを作成して配布します。
個々の項目はMicrosoftのドキュメントが詳しいので参照してください。
https://learn.microsoft.com/ja-jp/mem/intune/configuration/shared-user-device-settings-windows

と書くとこれだけでこの記事は終わってしまうので、ポイントになる設定項目をピックアップしてみます。

### Guestアカウント
ログインできるアカウントを指定できます。
組織アカウント（AzureADアカウント） or ローカルゲストアカウント もしくはその両方が選択できます。
ローカルゲストアカウントでのログインを許可した場合、いわゆる共有アカウントになるので「誰がログインしたか」をbyNameで追跡することはできません。ローカルゲストアカウントを許可する場合はその点の留意が必要です。
例えば、VDI環境アクセスのためのシンクライアントのように利用し、かつ端末へのログイン管理は不要な場合はローカルゲストアカウント運用でも問題ありません。

組織アカウントの場合も、ローカルゲストアカウントの場合も、権限は一般権限です。
管理者権限が必要な操作はできません。

### アカウント管理
有効にするとアカウント情報（データ）を自動的に削除できるようになります。
アカウントを削除するタイミング（条件）は
* ストレージ領域のしきい値
* 記憶域領域のしきい値と非アクティブなしきい値
* ログアウト直後

から選択できますが、共有デバイスとしてよくあるパターンとしては「利用が終わったらデータは削除する」という要件が多いと思うので、その場合は「ログアウト直後」を選択しておくと良いと思います。

ここで削除されるアカウント情報（データ）はC:¥User 直下のフォルダ・データのみです。
後述のローカルストレージ設定を「有効」にした場合に、Cドライブ直下にフォルダを作成して、任意のファイルを保存することが可能になりますが、このデータは削除の対象にはなりませんので留意しましょう。

### ローカルストレージ
この設定項目を「有効」にすると、ログインしたユーザーはローカルストレージに読み書きができるようになります。（ただし管理者権限が必要なディレクトリにはアクセスできません）

「無効」にした場合、ユーザーは「ダウンロードフォルダ」のみアクセスができるようになります。必要以上にローカルストレージにデータを保存させたくない、最低限ブラウジングしてダウンロードしたファイルだけ閲覧・編集できれば良い、といった要件の場合は「無効」しておくのも良いと思います。
![スクリーンショット 2022-12-22 011510.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/140000/52bf0b30-e1dd-9c5e-cf55-10b8a9fea1d7.png)
ローカルストレージを無効にしてエクスプローラーを開くとこんな感じです。
ダウンロードフォルダしか表示されません。



「共有のマルチユーザーのデバイス」構成プロファイルは他にも設定できる項目はありますが、共有デバイスとしては最低限上記項目だけ要件に合わせて設定しておけば良いと思います。

# 構成プロファイルの割当
「共有のマルチユーザーのデバイス」構成プロファイルは必ず「デバイスグループ」で割り当てることが必要です。
ユーザーグループで割り当ててしまうと正しく動作しません。
Bitlockerによるディスクの暗号化や、Wi-Fiの設定等の他の構成プロファイルも基本的にはデバイスグループに割り当てる方が良いでしょう。

# まとめ
以上がIntuneで共有デバイスを構成する場合のポイントになります。簡単ですね。
* 従業員が普段利用しているPCが故障してしまったので、修理している間に一時的に代替機を貸与したい
* 普段Macを使っているユーザーが一時的にWindowsPCを利用したい
 
そんなときこういった共有デバイスを用意しておくと、わざわざ新しいPCをセットアップする手間はいらなくなるので便利ですよ。
複雑指数(ポエム)

# 複雑とは
複雑とは一つの事柄や物に対して、人間が認知できる件数を超えた要素を理解しようとした場合に人間が感じる認知の一種だと考える。

# 事柄や物
どんな事柄や物は以下のような構成をしている。
・Aを構成する要素はA-1,A-2...である。
・A-1を構成する要素はA-1-1,A-1-2...である。
・A-1-1を構成する要素はA-1-1-1,A-1-1-2...である。
各構成内の要素数を構成要素数とする。
最小粒度まで要素としていた場合、単純なものとなる。
つまり、単純なものの集合体なのだから複雑ではないと言える。

# 例えば
Aをみそ汁とするならば、
①みそ汁を構成する要素は具と味噌と出汁である。
②出汁を構成する要素は水と昆布のエキスである。
③水を構成する要素は、水素と酸素である。

みそ汁で考えると構成要素数は1件
①で考えると構成要素数は3件
②で考えると構成要素数は2件
③で考えると構成要素数は2件

となる。

# 同時に認知できるものが2件の人間だった場合
みそ汁は1件なので単純に感じる
①は3件なので複雑に感じる
②と③は2件なので単純ではないが複雑にも感じない

※実際の人間はもっと多くの件数を認知できると思うが分かりやすいように2件としている

# 複雑指数
この考えを数値化するため以下の計算式とする。
複雑指数 ＝　構成要素数　÷　認知可能数

この数値が1以上であれば複雑であり大きければ大きいほど複雑に感じることになる。
逆に0に近づけば単純に感じることになる。

# 要素を意識しない
要素を意識しなければ、複雑指数が高いものでも1つの要素としてとらえることで上位の構成の複雑指数が下がる。

数種類のスパイスを混ぜた料理の味は、数種類のスパイスが混じった味は、スパイスの種類÷認知可能数な味、これをカレーと認識した場合、カレーの味は、カレー味になるは、1÷認知可能数な味となる。

つまり、人間がどのレベルの要素を認識しようとしているかによって複雑であるかは変動する。

# 意識しなくても
要素を意識しなければ、複雑にはならない。しかし、内部的に要素は存在しているので実際には隠蔽されているだけで複雑指数は存在している。

注意しなければいけないのは、粒度の違う要素で構成されている場合である。
この場合、人間は細かい粒度のものに合わせて認知しようとしてしまう。
そのため粒度の大きいものは要素に分解され複雑指数が跳ね上がってしまう。

このため、なるべく同じものを構成する要素は同じ粒度となるように意識した方がいい。

**これはポエムであり複雑とは何なのか考えてみたものである。**
Log Analyticsについて

●Log Analytics
クラウド環境だけではなくオンプレミス環境(物理マシンやHyper-V仮想マシンなど)の監視もできる。
有料サービス。ワークスペースに保存したデータ量に基づいて課金される。

使用するには最初に「LogAnalyticsワークスペース」を作成する必要がある。
ワークスペースとは分析するデータの保存場所となるリソース。

●Log Analyticsエージェント
使用することでOSによって生成されるデータもワークスペースに送信できる。
Log Analyticsエージェントは、監視対象のOSとワークロードから監視データを収集してワークスペースに送信するためのエージェント。
Windows用は「Microsoft Monitoring」、Linux版は「OMSえージェント」

Log Analyticsを使用してデータを分析するにはLog Analyticsワークスペースにデータを収集する必要があり、そのためにはデータソースとしてLog Analyticsワークスペースの接続が必要。

●Azureのアクティビティログ
アクティビティリグをLog Analyticsワークスペースに送信するには、診断設定を構成する。

●Azure仮想マシン
Azure仮想マシンのOSとワークロードの監視データをLog Analyticsワークスペースへ送信したい場合は、Log Analyticsエージェントを監視対象のマシンにインストールする必要がある。

※オンプレミス環境やAzure以外のクラウド上で実行されるマシンのOSとワークロードの監視データをLogAnalyticsワークスペースへ送信したい場合も同様だが、Azure仮想マシンのようにAzureポータルから直接インストールすることができないため、Log Analyticsエージェントのセットアッププログラムを使用して個別にインストールする必要がある。

●Log Analyticsエージェントの構成
Log Analyticsワークスペースとの接続が完了しても、それとは別にLog Analyticエージェントの構成を行う必要がある。
構成とは、エージェントを使用して収集する監視データの選択。
ミニ吸引機制作

**「やばい!!　早くアドカレあげなきゃ居場所が・・・!」**
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/873754/1c9bb6e7-251b-6537-9ef0-76ced6a1d7a8.png)
引用:https://twitter.com/mangatimekirara/status/1604130058452406272?s=20&t=YptnIJnKt3XLmBdVihGQJg   

今回はミニ吸引機(今回はモノを吸って集めるというよりは、紙や本のページを持ち上げることを目的としています)を制作したときのことをざっくり書きます。（半年前ぐらいに作ったやつなので記憶をたどりながら書いてます。）下記のリンク先のものを参考にしました。
https://www.yumeginga.jp/910_support/jikken_kousaku/jiyuukenkyuu/09handycleaner.html 。

### 必要なもの
- ３Dプリンタ
- モータ（TAMIYAの小型DC）
- 電池（単3）2本　
- ねじ、ナット（M2とかM3）
- ドライバ
- やる気と元気
**あると便利なもの**
- 電池ボックス

CAD素人がモデリングしたものがこちら。（ファンとモータはアセンブリしてない）  
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/873754/d4313ccb-a379-58cf-14ae-409f321525bf.png)
これだけだとよくわからないと思うので、出来上がったものが下記の画像になります。stlデータは気が向いたらupする予定ないですが、要望があれば（無いはず）うｐします。  
空気の吸込み口（ファンの横には小型のサーボモータ(SG90)やリミットスイッチを取り付けられるようにしました）
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/873754/51cc3aea-0133-5ccb-deab-eac620ddd487.png)
空気のはき出し口
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/873754/bcca7f05-b98e-fcc6-ab23-5720dcf5c34c.png)
側面
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/873754/f0c52175-fd60-cfe9-89d5-aff54d1df982.png)
電池をつなぐと、ティッシュや本のページを持ち上げることができます。

以上、会員からの報告でした。
#### P.S  
**聖書** をようやく全巻購入できました。（アンソロジーは売り切れでした..）
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/873754/e038c574-842a-c707-31e1-a1d3528b8d36.png)
HTTPステータスコードについて

# はじめに

この記事は[Webの基礎をおさらいカレンダー Advent Calendar 2022](https://qiita.com/advent-calendar/2022/basic_review)の記事です。
このカレンダーでは、なんとなくわかった気になっている、Webの知識をおさらいします。
興味をもし持ってくださった方は、購読いただけると嬉しいです！

今回はHTTPステータスコードについて説明します！

## HTTPステータスコードとは
Webサイトにアクセスした際に、http通信が行われます。
http通信が行われた後、サーバーからのレスポンスが返されます。
HTTPレスポンスは3つのパートで構成されています。

* HTTPステータスライン
* HTTPレスポンスヘッダ
* HTTPレスポンスボディ

このHTTPレスポンスの最初の1行目にある、HTTPステータスラインに、リクエストした結果どうなったか？
という情報が簡易的に書かれています。

ステータスラインの例: `HTTP/1.1 200 OK\r\n`

HTTP/1.1で200 OKが返却された。というような感じで、1行目を見ると、リクエストが成功したのか、失敗したのかなどどうなったのかを簡易的に理解することができます。

この200のような、3桁のコードの部分がHTTPステータスコードです。
つまり、簡易的なリクエスト結果を知らせるためのステータスを表すコードです。

### 種類

| ステータス種別 | 桁 | 説明|
| ----- | --- | ---|
| 情報レスポンス |100-199| リクエストが処理されている状態。ほとんど一瞬で処理が完了するため、通常意識することはない|
| 成功レスポンス |200-299|クライアントからリクエストが正常に送られ、受付された状態|
| リダイレクトメッセージ |300-399|リクエストに追加処理が必要な状態。|
| クライアントエラーレスポンス |400-499|クライアントサイド(ユーザー側)で何か意図せぬ操作が行われた場合に発生する|
| サーバーエラーレスポンス |500-599|サーバー側で何か問題が起きている状態。このステータスコードを見つけたら、管理者にお知らせしましょう。|

#### 代表的なHTTPステータスコード
全部紹介しているとキリがないので、よく使われるものに絞って紹介します。(全部見たい方は参考文献を参照してください)

* 200 OK
    * 定番なステータスコード。
    * リクエストが成功したことを指す。
* 301 Moved Permanently
    * リダイレクトが自動的に行われる。
    * リクエストしたURLが一時的なものではなく、完全に変更されたことを指す。
* 302 Found
    * 一時的なリダイレクト。
* 304 Not Modified
    * キャッシュで使用。レスポンスが変更されていないことを指す。
    * このコードを見かけたら、キャッシュされているので、ブラウザ側で更新をかけても表示は変わらない。
    * 記事などを更新したときに304が出ていないか確認しよう。
* 307 Temporary Redirect, 308 Permanent Redirect
    * 302, 301と意味合い的には同じだが、HTTPメソッドが変更されない点が異なる。
        * 例えば、302,301だとPOSTのリダイレクトが古いクライアントだとGETに変更されてしまう可能性がある。
        * GETだけにリダイレクトを使う場合は特に意識する必要はないが、違いを理解して間違えないようにしましょう。
* 403 Forbidden
    * コンテンツのアクセス権がなく、見られない時に使用される。
* 404 Not Found
    * コンテンツが見つからない時に使用される。一番目にする機会が多いはず
* 500 Internal Server Error
    * サーバー側で処理方法がわからないエラーが発生した際に使用される。
* 502 Bad Gateway
    * ゲートウェイまたはプロキシ用のサーバーが無効なレスポンスを受け取った際に使用される。
* 503 Service Unavailable
    * サーバー側のリクエストの準備ができていない状態を指す。
    * メンテナンスや高負荷時でのダウンなどの際に使用される。


### ネタステータスコード

上記が代表的なコードですが、一つ面白いステータスコードを紹介します。

`418 I'm a teampot`

エイプリルフールのジョークとして使用されたネタで、サーバーが「私はティーポットなので、コーヒーは入れられません。」というエラーだそうです。

* googleにもジョークページが存在しています。
  * https://www.google.com/teapot

小粋な方がいらっしゃいましたら、使ってみてはいかがでしょう。

## 終わりに
以上、httpステータスコードについてまとめてみました。
普段、何気なく見ているステータスコードの意味を知ると、より状況が理解しやすくなると思います！
ぜひ、心に留めておいてください！

[Webの基礎をおさらいカレンダー Advent Calendar 2022](https://qiita.com/advent-calendar/2022/basic_review)でした。
興味をもし持ってくださった方は、購読いただけると嬉しいです！


## 参考文献
[MDN HTTP レスポンスステータスコード](https://developer.mozilla.org/ja/docs/Web/HTTP/Status)
[「分かりそう」で「分からない」でも「分かった」気になれるIT用語辞典 HTTPヘッダとは](https://wa3.i-3-i.info/word16648.html)
今日学んだことと

初めての記事がこのようなメモ感覚でいいのかはわかりませんが。
今日は学んだことをアウトプットして明日インプットすることを書いていこうと思います。
自分はあまり文章力に自信がないため温かい目で見てください。
# 今日は学んだこと
累積和について学んだ。
# 学んだことの大まかな説明
一言でいうと、数列を始めに下処理することにより、配列間の総和をすぐにもとめることが
できるようになるものである。
コード
```javascript:qiita.js
let N = 4;
let arr = [1,4,5,6];
let sums = Array(N + 1).fill(0);
for(let i = 0; i < N; i++) {
    sums[i + 1] = sums[i] + arr[i];
}
```
# 明日学ぶこと
あしたは学ぶというよりなにかゲームを作ってみたいと考えています。
Automatic1111導入メモ

アウトソーシングテクノロジー株式会社　神谷です。
普段はRHELのトラブルシューティング的な事を下っ端としてバリバリ解決しています。

今日はAutomatic1111を導入中にフンガーとなったのでメモ。

（１）pythonは自分で3.10.xを入れる。
　　[windows版python](https://pythonlinks.python.jp/ja/index.html)
　　上記、分かりにくいですが3.11は入れないで3.10を入れましょう。自分は3.10.8とか3.10.9とか入れました。3.11.xは動かなくなるらしいので入れないように。

（２）gitは自分で入れる
　　[Windows版git](https://gitforwindows.org/)
　　上記からインストーラを手に入れてインストール。

（３）魔法のコトバを入れておく
　　PowerShellで以下を１回だけ実行
　　```
Set-ExecutionPolicy RemoteSigned -Scope CurrentUser -Force
    ```
　　[参考](https://www.python.jp/install/windows/install.html)

（４）torchとかも自分で入れる
　　インストールが上手く行ってるならコマンドプロンプトで以下入力。
    ```
    pip3 install torchvision gfpgan
    ```
　　これをやってもあんまし変わらないかも。結局のところ初回起動時にかなーり待つ。clipとかxformarsとかはpip3で入れられない。

（５）webui_user.batの編集
　　結局コレ。多くの人がここでつまずくんでしょう。
　　--no-half付けないと起動すらしなかったし、エラーメッセージを元にネットを探したけど載ってなかったので、これを見つけるのにはえらい苦労をした。
　　git pullは、automatic1111を最新化するための呪文。起動するたびに最新化。
　　VENY_DIR=-は、自分はこれで安定したのでコレで。python普段使わないので環境が汚れるとか気にしない気にしない(逆にプライベートPCにpython入れてる層はVENY_DIRはブランクで良さそう)。
　　下記「username」は適宜書き換え。というかコマンドプロンプトでwhere pythonの結果の方が良さそう。
```　　
@echo off
set PYTHON=C:\Users\username\AppData\Local\Programs\Python\Python310\python.exe
set GIT=C:\Program Files\Git\cmd\git.exe
set VENV_DIR=-
set COMMANDLINE_ARGS=--skip-torch-cuda-test --medvram --no-half --xformars
git pull
call webui.bat
```
　　ウチはコレで動くようになりました。VRAM4Gしか無いですが一応動きます。
　　--medvramは、もっとpoorな人は--lowvramandとか指定するといいらしいです。
コマンドラインでMAMPのPHPを使う方法

Symfony3の案件でPHP8だとbin/consoleコマンドが動かなくて詰みました。

MAMPのPHPは7.4が入っているのでWEBブラウザでは開けるけど、artisan や bin/consoleのようなコマンドラインツールはMAC本体のPHPに向いているので動かない。

M1macだからかasdfパッケージマネージャで古いPHP7系を入れようとしてもエラーでコケてインストールできない。

そこでウルトラCを思いついた。

MAMPのPHPだって本体があるんだから必要な時だけフルパスでMAMPに入っている古いPHP呼び出せばいいのでは！？

つまりこう。

```
/Applications/MAMP/bin/php/php7.4.16/bin/php -v
/Applications/MAMP/bin/php/php7.4.16/bin/php bin/console list
```

動いた！！

まあ、MAMP経由するからかなんかちょっともっさりしてる気がするけど死んでるよりいいので、最終手段として覚えておくといいと思います。


PHPコマンド自体のリンク先を上記へ振り向ければフルパスは書かなくてもよくなるけど、mac本体のさしているPHPがなんだったかわからなくなるしこういう感じで別にしておいた方がいい気がします。

とはいえこれではコマンドが長すぎるのでMakefile作って
こんな感じにしておけば、 make list とか make php-v　で動くので一緒に用意しておくのがおすすめ。


```:Makefile
php-v:
	/Applications/MAMP/bin/php/php7.4.16/bin/php -v

list:
	/Applications/MAMP/bin/php/php7.4.16/bin/php bin/console list
```
RSGT・スクラムフェスの出会いから始まる連鎖

[スクラムギャザリング＆スクラムフェス Advent Calendar 2022](https://adventar.org/calendars/8002) の22日目の記事です。
アドカレにエントリしたものの、個人的なブログを書く先がないことに気付いたので、数年ぶりにここで書きます。

# 目次
1. [RSGTとの出会い](#RSGTとの出会い)
1. [スクラムフェスとの出会い](#スクラムフェスとの出会い)
1. [そしてスクラムフェス三河のスタッフへ](#そしてスクラムフェス三河のスタッフへ)
1. [これから](#これから)
1. [さいごに](#さいごに)

# RSGTとの出会い
RSGTへの初参加は [RSGT 2019](https://2019.scrumgatheringtokyo.org/) でした。20年在籍した会社を退社して心機一転数日後のことです。
それまで参加してきたカンファレンスは、Developer Summit や pmconf だったり AWS Summit などは参加していましたが、RSGT の存在は実は知らなかったのです。
当時の転職先(現在退社済み)で、kyon_mm さん達と一緒に仕事することになり、当時の専務から入社数日目にも関わらず RSGT2019 のチケットを頂いて参加したのが自分の中でターニングポイントとなりました。
初参加の RSGT はホント凄くて… 何が凄いのかは、とにかく参加者の圧倒的な熱量です。
今まで参加していたイベントでは簡単な交流会はあっても、参加者同士がとにかく語り合う・熱く語り合うということはありませんでした。
でも、RSGTはとにかくギャザリング。すぐギャザる。ちょっとした場所があればギャザる感じで、**"こんなにも話すんかい！"** って衝撃を受けました。
この衝撃が無かったら、この後出てくるスクラムフェスにも興味を示さなかったかも知れませんね。
そんな出会いのきっかけをくれた前職の専務と kyon_mm さん達には感謝しかありません。
<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/211866/cf6ab463-0d09-c921-1796-617602c82d40.jpeg" width=70%>

# スクラムフェスとの出会い
RSGTの興奮も冷めやらぬ中、次の出会いのきっかけが生まれました。そう、スクラムフェスです。
スクラムフェス を知ったのは [スクラムフェス大阪2019](https://www.scrumosaka.org/2019) です。
kyon_mm さんが基調講演、そして基盤チームの bleis-tift さんと dico_leque さんが [登壇する](https://confengine.com/conferences/scrum-fest-osaka-2019/proposal/8715/kpt-5000-) ということで、隣で発表練習を見ていたからか、すごく身近の感じるイベントに思えました。

その後、退職し現会社に転職します。
そして、自分もチャレンジとして登壇したい！と思った時に真っ先に浮かんだのが **スクラムフェス大阪** でした。
人生45年生きてきての初登壇は [スクラムフェス大阪2021](https://www.scrumosaka.org/scrum-fest-osaka-2021) で 「[ゼロからのスクラムチャレンジ](https://eng-blog.iij.ad.jp/archives/10083)」 という内容で現会社でスクラムを取り組み始めたきっかけと躓き・学びを話させてもらいました。
そして、ここでスクラムフェス三河の代表である まつしゅー さんと出会います。
2021年9月に開催するスクラムフェス三河にも是非！と誘ってくれたのが、この後のスクラムフェス三河との出会いとなります。

# そしてスクラムフェス三河のスタッフへ
スクラムフェス三河は地元だけに強い思い入れがあります。
20年在籍していた前々職で名古屋の地図会社時代に、いろいろな技術カンファレンスが名古屋飛ばしすることに対して強い悲しみを覚えていました。
当時、DAD(Disciplined Agile Delivery) でアジャイルを実践しており、チーム開発に強い魅力と可能性を感じていました。
そして、「いつか名古屋でカンファレンスを開きたい！その為には強いチームが欲しい。ベンダーではなく内製チームで作りたい！」とトップに相談したところ「うちはそういう会社じゃないから」と一蹴され、絶望を希望に変えるために40代で転職を決意した訳です。
なので、地元三河でスクラムフェスを開催するって知った時はテンションが爆上がりしましたね。
その後、[スクラムフェス三河2021](https://www.scrumfestmikawa.org/2021) で 「[スクフェス大阪2021で発表というアウトプットを出したら会社的インパクトが起きた話](https://eng-blog.iij.ad.jp/archives/10960)」 という内容で現地登壇させてもらった経緯は既に話した通りです。

そして連鎖はまだ続きます。
打ち上げで気分が良くなっている所に、まつしゅーさんから「三河のスタッフにならない？」と声をかけてもらいました。
当然、名古屋や地元でカンファレンスを開催したいと飛び出してきた身としては、二つ返事以外の選択肢はありませんでした。
ということで、2022からスタッフとしても経験させてもらい、新たな出会いも生まれ、とにかく楽しい1年となりました。
その時の記事を会社のブログに書いてあるのでよかったら読んでください！
- [IIJ Engineers Blog: スクラムフェス三河2022にスポンサー・運営側・登壇者の立場で参加しました！](https://eng-blog.iij.ad.jp/archives/14997)

# これから
RSGT・スクラムフェス関係では大きく2つの目標があります。
- RSGTのプロポーザルでAcceptをもらう！ (現在2連敗中)
- スクラムフェス三河のキーノートで三遠ネオフェニックス(地元プロバスケチーム)を呼んで、勝つためのチーム作りについて熱く語ってもらう

なぜバスケ？なのですが、バスケはコートに立つ5名が自律して動かないとチームとして成り立ちません。
そしてコートにはプレイヤーしかいません。プレイヤー自身が試合に勝つために、自ら考え・動いて・声を掛け合っていく必要があります。
なんかスクラムチームに似ていませんか？
なのでバスケのチーム作りの話は絶対にスクラムチームのヒントになると思う訳です。

# さいごに
40代で思い切って会社を飛び出し、ちょっとした出会いの連鎖からスクラムフェス三河のスタッフになりました。
あの時「チーム作りは諦めるかー」と引き下がっていたら今の自分や出会いもなかったと思います。
そして、そんなきっかけを作ってくれたRSGT・スクラムフェスには感謝しかありません。
こんな素敵なイベントが長く愛され続けれるように、自分も出来ることを精一杯やっていきたいと思います！


※記事に掲載の写真は、自分が撮影した写真です
書籍『現代暗号技術入門』の紹介

この記事は [EAGLYS Advent Calendar 2022](https://qiita.com/advent-calendar/2022/eaglys_adcal) の14日目の記事です

# はじめに
昨年のアドカレでは，↓の書評記事を書きました

[書籍『耐量子計算機暗号』の紹介](https://qiita.com/0917laplace/items/7c1535c3236c259e07ea)
[書籍『データ解析におけるプライバシー保護』の紹介](https://qiita.com/0917laplace/items/babf31440efe255e9e7d)
[書籍『セキュリティエンジニアのための機械学習』の紹介](https://qiita.com/0917laplace/items/7f20ef077967b44f9760)

~~書評記事は書くのが楽なので~~今年も書こうと思います

Q. それってあなたの感想ですよね？
A. はい

ということですので，あくまで個人の感想となります

# 今回紹介する本

[現代暗号技術入門](https://bookplus.nikkei.com/atcl/catalog/22/06/08/00221/)

[詳しい目次](https://web-cache.stream.ne.jp/www11/nikkeibpw/com/sp/08019/mokuji.pdf)

内容に深く入らない程度で気になった章を↓で紹介します

# 第14章
耐量子暗号ということで，ウッキウキでこの章から読み始めたのですが，~~当然の如く~~符号ベース暗号は紹介程度に終わっていました・・・

ブロックチェーンに触れる以上，ハッシュベースを紹介するのは分かります
耐量子暗号の中で一番「性能がいい」格子暗号を紹介するのも分かります

符号ベース暗号もやってくれって・・・

~~ということでもうこの章に関してこれ以上書くことはありません（過激派）~~

# 第12章
おそらくこの本の一番のメインです，ブロックチェーンの話ですね

マークルツリーを使って，ハッシュでぐちゃぐちゃみたいな話もちゃんと書かれていました

ディエムのことがしれっと書かれているんですが，そういえば撤退したのって今年でしたね・・・

# 第13章
~~基本的にハードウェアっていうかアプリケーションには興味がない筆者なのですが，~~
constant-time implmentation に触れられていたのは驚きでした

constant-time implmentation とは，例えば，与えられた正整数 $n$ が偶数かどうかを判定する関数を↓で作ったとします

```
def decide_even(n : int):
    flag = False
    if (n % 2 == 0):
        flag = True
    return flag
```

これで動くっちゃ動くんですが，例えば，偶数だったら，サブルーチンAを呼び出して，その中で別のサブルーチンを呼び出して・・・みたいな処理を途中で挟むなら，
$n$が偶数のときの decide_even （たぶんこの間数名でなくなると思いますが）の処理時間と奇数のときの処理時間は大きく異なります

実はプログラムの中身を全く見ずとも，ランダムに正整数を与え続けてその処理時間や消費電力などを測定することで，部分的にプログラムの情報を得ることができます（サイドチャネル攻撃の一種）

このような攻撃に対する実装上の工夫が constant-time implementation です
＊上の関数を修正するなら，if文を消せばOKです

＊全然関係ないんですが，この前の [Asiacrypt2022](https://asiacrypt.iacr.org/2022/) で constant-time implementation のツールがあることを初めて知ったのですが，かなりいろいろなツールがあるそうですね・・・

[Constant-timeness verification tools](https://crocs-muni.github.io/ct-tools/)

TEE の話にも触れられていたのが，現代って感じでした

# 第15章

雑多な章ですね，MPCとFHEとZKPについてです

MPC
もうChromeで使われてるんですね知らなかった

８章を前提にすると分かりやすいと思います

FHE
~~聖杯ってなに？~~
概要のみならず，ブートストラップにも触れらています~~その図がめちゃわかりづらいんですが~~

LWE問題をもとにしたFHEも触れられていて驚きでした

ZKP
なんか最近すごく話題ですよね（他人事）
この中だと（少なくともFHEと比較して）かなり古参なのに・・・

# まとめ
「数式はできるだけ使わず、代わりに図解をふんだんに使った本」ですので，「暗号理論」ではなく「暗号技術」の本です

それが良いか悪いかという話ではなく，個人的にそのような類の本は需要があるのかなと思いますし，流行りに合わせて定期的に出版されるべきだと思います

数式はできるだけ使わない代わりにめちゃくちゃ読みづらい部分もあるため，結局しっかり勉強するなら，個別でやるのが良いかなと

------------------------------------
今回の内容はここまでです．ここまでご覧になってくださった方々ありがとうございます！
パチンコ及びプログラミング演習1

# はじめに

こんにちは.STECHとシステム工学研究会の松田です.

本記事は[STECH / 愛知工業大学 システム工学研究会 共同企画 Advent Calendar 2022](https://qiita.com/advent-calendar/2022/stech-ait-advent)の25日目,最終日の記事です．

# 記事投稿のきっかけ
皆さん,お金に困ってはいませんか？僕はめちゃくちゃ困っています.
本記事の投稿が2022/12/25ということもあり自分や恋人,家族へのクリスマスプレゼントで出費が増えたのではないでしょうか.
翌週にはお正月なので自分だけのお年玉を**パチンコ**で獲得したいという思いから本記事を投稿しました.

# パチンコとは
パチンコを知らない人のために少し解説します.
パチンコとは簡単に説明すると玉を増やす遊戯です.具体的な遊戯方法等は粗品さんが紹介している[パチンコ解説動画](https://www.youtube.com/watch?v=S41di2tKU8M&ab_channel=%E3%81%97%E3%82%82%E3%81%B5%E3%82%8A%E3%83%81%E3%83%A5%E3%83%BC%E3%83%96)を見ていただけるとわかりやすいかと思います.

極論,カジノみたいなものです.違いは法律上の定めであり,**パチンコは賭博ではなく遊戯である**ことです.

そうして増やした玉を交換すると変な四角形の棒みたいなのが貰えます.
お店を出ると近くに変な四角形の棒を買い取ってくれるらしい買取店があるので買取依頼をするとお金が増える仕組みになります.

しかし,パチンコ店は利益を出さないと潰れてしまうのでお金が増える確率より減る確率の方が高いと言えるでしょう.
そこで,プログラミングや正規分布の力を使ってお金が増える確率を上げようと思います.

# 95%信頼区間とは
母集団から標本を取ってきて,その平均から95%信頼区間を求める.という作業を100回やったとき,95回はその区間の中に母平均が含まれるというものです.

この95%区間推定を用いて0~N回転の間に95%で当たるパチンコ台を探していきたいと思います.

## 95%信頼区間の算出方法
95%信頼区間の算出方法は以下のような数式で表すことができます.
$$ 標本平均 ± t × 標本標準偏差 ÷ √標本の大きさ $$

# コードを書いてみる

実際に95%信頼区間を求めるPythonスクリプトを書いていきます.以下のような架空パチンコデータのCSVがあります.パチンコデータの取得については本記事でサポートしないため,自分で収集するか色々な方法で取得してください.

| 当たり | 回転数 |
| ---  | ----- |
|1|100|
|2|200|
|3|100|
|4|400|
|5|700|
|6|100|
|7|200|
|8|300|
|9|400|
|10|500|⏎ 

## ライブラリのインポート
本記事で使用したライブラリをインポートしていきます.
```py
import numpy as np
from scipy import stats
import pandas as pd
```

台データのCSVを読み込み表示していきます.JSONや生のデータで扱いたい方は適宜書き換えて使用してください.
```py
pachinko = pd.read_csv('./pachinko.csv')
pachinko_length=pachinko.iloc[:,1]
print(pachinko_length)
```

## 母平均を算出する
統計学的にはデータがかなり少ないですが,pachinko_lengthの母平均を算出します.
```py
pachinko = pd.read_csv('./pachinko.csv')
pachinko_length=pachinko.iloc[:,1]

sample_mean = np.mean(pachinko_length)
print(sample_mean)
# 300.0
```
母集団の平均は「300.0」であることがわかりました.

## 標本の作成
pachinko_lengthの全体の件数から半分のデータをランダムで抽出した標本を使用します.

```py
pachinko = pd.read_csv('./pachinko.csv')
pachinko_length=pachinko.iloc[:,1]
n=int(len(pachinko_length)*0.5)
sample_df = pachinko_length.sample(n=n)
print(sample_df.mean())
# 260.0
```
母集団の平均は300.0
標本の平均は260.0
という結果になりました.

## 全体のコード
```sample.py
import numpy as np
from scipy import stats
import pandas as pd

pachinko = pd.read_csv('./pachinko.csv')
pachinko_length=pachinko.iloc[:,1]
n=int(len(pachinko_length)*0.5)
sample_df = pachinko_length.sample(n=n)

sample_mean = np.mean(pachinko_length)
print(sample_mean)
# 300.0
sample_var = stats.tvar(pachinko_length)
print(sample_var)
# 40000.0
print(stats.norm.interval(alpha=0.95, loc=sample_mean, scale=np.sqrt(sample_var/n)))
# (124.69549188468369, 475.3045081153163)
```

上記のコードを実行すると124.6...,475.3...という結果が出ます.
パチンコに置き換えると124回転〜475回転は95%の確率で当たる台ということがわかります.
この結果から例えば現在400回転ぐらい回っている台は残り75回転の間は95%で当たる狙い目の台であるといえます.


# おわりに
本記事の知識を蓄え実践といきましょう.

二度とパチンコなんて行くもんか！！

それでは,良いクリスマス.良いお年を.
現代風デザインの明治時代の地図を作った話

:::note info
こちらは2021年に制作した地図の解説記事です。
:::

## はじめに
近年、古地図や旧街道巡りがブームとなっているとされ、関連したさまざまな書籍等が多く存在します。
今年夏に逝去された（謹んでご冥福をお祈りします）埼玉大学・谷謙二氏の「今昔マップ」や日本地図センターの「東京時層地図」など、古地図と現代の地図を比較・重ね合わせるウェブサイト・アプリケーションをご存知の方は多いかと思います。
これらの昔の地図は、（自分を含めて）地図好きにとっては垂涎もので、それこそ何時間も眺めていられるものでしょう。
しかし、地図にそこまで興味がない方々にとってはどうでしょうか。
古地図や絵図の記号・整飾は、現代の地図に慣れ親しんだ方にとって少し難解なもので、理解するまでに少し時間を要するケースもあるかと思います。
これは地図の「情報を一目でわかりやすく伝える」という目的の達成を難しくしてしまっています。
そこで、古地図や絵図を誰にとってもわかりやすく伝えるためにはどうすればよいか？と考えた結果、現代風のフォーマットに当てはめた古地図を制作するという手法にたどり着きました。

## 作成方法
### 元にした地図
今回は、明治時代の東京・横浜間に鉄道が開通した当時の地図を作りたかったので、農研機構さんが歴史的農業環境閲覧システムにて配信している「第一軍管区地方2万分1迅速測図原図」（以下、迅速測図とします）を利用しました。
迅速測図についての詳しい説明は省きますが、およそ1880年ごろの地図です。

https://habs.rad.naro.go.jp/

### 道路
QGISに農研機構さんのタイルを読み込み、ひたすらトレースする作業を行なっていきます。
トレースした道路は道幅に従って分類。道路の太さや色を変えます。
今回はほとんどの人が使ったことのあるであろうGoogleマップ風のデザインとしました。
![スクリーンショット 2022-12-21 23.49.54.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2705702/f6da2136-6bb2-544f-6aaa-b3932158381b.png)


### POI
迅速測図上に記された村名・町名などの市町村名や、役場・官公庁・橋梁・寺社・砲台・灯台などをPOIとしてプロット。
1884年に出版された岡部啓五郎『東京名勝図会』に記載された名所も参考にしました。
![スクリーンショット 2022-12-21 23.52.31.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2705702/5dbc7d93-d140-1689-d78a-90380f4c4708.png)

https://dl.ndl.go.jp/info:ndljp/pid/764223

### アイコン
POIのアイコンはGoogleのものをそのまま使用すると権利上の問題があると思われたので、似せて書き起こしつつ、新しいアイコンを制作しました。
例えば、当時水上交通として主流だった「渡し」や、明治初年から建設され各地で多く用いられるようになったトラス橋をモチーフにした「橋」、そして陸蒸気と呼ばれ親しまれた蒸気機関車をモチーフにした「鉄道」のアイコンです。
![スクリーンショット 2022-12-21 23.56.24.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2705702/962e98b3-5042-1b07-c380-a8599d103a50.png)

## 完成
ズームレベルに応じて表示されるアイコンやラベルの表示される方向を手動でいい感じに調整します。
![スクリーンショット 2022-12-22 0.00.30.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2705702/fd669e5f-0899-60d8-e76d-1b31076c42f5.png)

さらに細かく調整したい方は、PDFにエクスポート→illustrator等（FOSS4Gなのにオープンじゃないソフトを使ってスミマセン🙇‍♂️）のドロー系ソフトで読み込んだ上で細かい調整をして完成です！
![FBgBv2NVIA4ZYEn.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2705702/264c6c92-b1df-498a-90ea-183dd8a4e355.jpeg)
![FBgBwq3VIAYsqY2.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2705702/ee096c35-8d75-3f70-1022-eeeba29bb694.jpeg)

### 参考文献
ここに掲載した文献以外にも、さまざまな文献や書籍等を参考に制作しました。文献一覧は下記になります。
タイルを提供してくださっている農研機構さんを含めまして、感謝の意を表します。
![FBgCCQvVUAQlfVw.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2705702/97461aff-da5e-9b6a-7230-e577a186ba70.png)

## 今後の展望
以前より「江戸時代の現代風地図」をTwitter上に投稿し、ありがたいことに多くの反響を頂いてきました。この地図を全国に拡大し、さらに今回制作した明治時代を含めた古代〜現代までを一気通貫で俯瞰できる、そんな地図を作りたいと考えています。
祝！ jig.​jp 上場！

IPOの情報を見ていたら、「jig.jp」という項目がありました。

* [jig.jp\[ジグジェイピー\]（5244）のIPO上場情報](https://www.ipokiso.com/company/2022/jig.html)
* [jig.jp（5244）：IPO上場情報と初値予想 | 庶民のIPO](https://ipokabu.net/ipo/5244)
* [「jig.jp（ジグジェイピー）」のIPO情報総まとめ！スケジュールから幹事証券、注目度、銘柄分析、他のライブ配信サービス企業との比較や予想まで解説！｜IPO株の銘柄分析＆予想｜ザイ・オンライン](https://diamond.jp/zai/articles/-/1009081)
* [jig.jp(5244)：IPO（株式上場）情報 - 東京IPO](http://www.tokyoipo.com/ipo/detail.php?id=pre&seqid=2958)
* [jig.jp〔ジグジェイピー〕（5244）【IPO上場企業紹介・初値予想】 | いろはに投資](https://www.bridge-salon.jp/toushi/2022december-ipo-5244/#back)
* [ｊｉｇ．ｊｐ (5244) : 新規上場（IPO）情報 \[jig.jp\] - みんかぶ（旧みんなの株式）](https://minkabu.jp/stock/5244/ipo)
* [【IPO評価と初値予想】jig.jp\[ジグジェイピー\](5244)の上場日、主幹事構成、時価総額まとめ](https://ipomechanic.com/jig/)
* [jig.jp（5244）IPO上場承認発表と初値予想！ライブ配信を中心としたソフトウェア・アプリの開発！ ｜ IPO初値予想主観 IPOゲッターの投資日記](https://ipoget.com/ipo-jigjp/)
* [ｊｉｇ.ｊｐ<5244> | IPO銘柄詳細 | IPO | トレーダーズ・ウェブ](https://www.traders.co.jp/ipo/5244)
* [jig.jp | IPO(新規公開株)取扱銘柄 | 松井証券](https://www.matsui.co.jp/stock/ipo/list/2022/details/5244.html)

jig.jp といえば、[IchigoJam](https://ichigojam.net/) に言及する時の例のおまじないでおなじみですね！※個人の感想です
さらに、大株主1位が「福野 泰介」となっています。
[福野泰介の一日一創 / create every day](https://fukuno.jig.jp/) でおなじみの名前ですね！

IPOの需要申告もしましたが、無事落選しました。

さて、そんな jig.jp の上場日は、本日12月22日となっています。
上場おめでとうございます！
ささやかながら、IchigoJam のプログラムでお祝いしてみました。

```
10 ' jig.jp ｼﾞｮｳｼﾞｮｳ ｲﾜｲ
20 D=#900:S="CAAAAAAEAAAACMzAAAoAAAoAzMAABQAABQrM4A4768AjtVCgAAUAADcazOChgZCkCHDc4AANzAAFDMzEppCDRY+w6gAABQAADRrMxCCgqCEqCFoEAAUAADCHqgUooKCACgoKxYzNzMAAIGoFBKziAAAAAAAAAAAAAAIBIAAAAAAA":GOSUB60
30 S="AAAAAAAAAAAAAAAAAAAAAAEAAQAAAAAAAAAAIAAAAAAEAAQACDNAAAAAAIAAYzQABQAFAAoAUAAAAACgAFAFAAUABQACzFAAAAAAoADcwQAFAAUAAABQAPAAAKAAUACkhQABAApIUAAAANDgAFAAAzAAAAAAMwAAAAAjEAAQAAAA":GOSUB60
40 S="AAAAAAAAAAAAAAAAAAAAAAjMwADMAAgAAAQAAAAAAAAKAAAGAlAOAACBgAAAAAAACswAAABQBQUAoKAAAAAAAAACtAAOAKChAFBgAAAAAAAAAAUA4QAjcxAzcwAAAAAACECFCFAACFAAChAAAAAAAAAzMAMzMAIAAAIAAAAA":GOSUB60
50 IFINKEY()=0GOTO50ELSEEND
60 GOSUB80:IFC>=0X=C:GOSUB80:IFC>=0B=X<<2|C>>4:GOSUB100:X=C:GOSUB80:IFC>=0B=X<<4|C>>2:GOSUB100:X=C:GOSUB80:IFC>=0B=X<<6|C:GOSUB100:GOTO60
70 RETURN
80 C=PEEK(S):S=S+1:IF64<CANDC<91C=C-65ELSEIF96<CANDC<123C=C-71ELSEIF47<CANDC<58C=C+4ELSEIFC=43C=62ELSEIFC=47C=63ELSEC=-1
90 RETURN
100 POKED,#80|B>>4&#F,#80|B&#F:D=D+2:RETURN
```

![祝 jig.jp 上場](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/99656/07e83849-1aa4-1d1e-8a90-8d31a46b6f07.png)

では、最後に例のおまじないを。

※IchigoJamはjig.jpの登録商標です。
Remixについて調べてみた

数ヶ月前に「Remixはいい」という話を聞いたことがきっかけでRemixについて調べてみました。備忘録的にまとめておきます。一部推測なども含みます。

## Reactの概要
まずRemixとはどんな技術なのか調べてみました。

RemixはReactベースのフルスタックフレームワークらしいです。
Next.jsと似ているようで、公式ブログの「Remix vs Next.js」をはじめ両者を比較している記事がいくつか見つかりました。
https://remix.run/blog/remix-vs-next

また、下記のようなことが書かれていたり、色々な記事で「DX(開発者体験)」・「UX」などの単語を目にするので、これはRemixの1つの特徴なのかなと思いました。
> Use JavaScript to augment the user experience by emulating browser behavior.
> https://remix.run/docs/en/v1/pages/philosophy

## Remixの特徴
まずは公式ドキュメントなどを読んでNext.jsと比較しながら特徴を調べてみました。
1. Remixは静的コンテンツの場合、Next.jsと同じかどうか、それ以上に高速・動的コンテンツの場合、Next.jsより高速
下記ブログにはNext.jsと表示速度を比較したgifが添付されてました。
https://remix.run/blog/remix-vs-next

2. RemixはSSGが利用できない
Next.jsと異なり、RemixはSSGが利用できないようです。現在は動的コンテンツを持ったwebサイトが増えており、SSGが配布できるwebサイトは少ないという考えのもとSSGが利用できないような気がします。
また、Remixではエッジで分散サーバー・データベースを扱うことやhttp cache controlヘッダーを利用することによりSSGに匹敵する速さを実現しているようです。

3. データミューテーションの違い
Next.jsでPost処理をする場合、next apiでエンドポイントを作成・利用するのが一般的です。
しかし、Remixの場合はサーバー上でのみ実行されるaction関数を使用してページコンポーネントと同じ箇所にロジックを集約することができます。
https://remix.run/blog/remix-vs-next#data-mutations

## RemixがShopifyによって買収される
2022年10月31日にShopifyがRemixを買収したと声明が発表されました。
どのような影響・変更がありそうか調べてみました。

Remixの声明の一部を読むと「Remixは長期的な支援とサポートを受けて、より速く成長していく」ようです。
> Remix receives long-term backing and support from an established leader in commerce. This move allows us to grow faster and sharpen our focus on performance and scalability.
> https://remix.run/blog/remixing-shopify

Shopifyの声明の一部を読むと、ShopifyのRemixチームにより、Hydrogen※1が改善されることによって、Hydrogenでwebサイトを構築する開発者も、merchantsも改善により、恩恵を受けられるそうです。

> With the Remix team at Shopify, developers building on Shopify will benefit from new tools that they will love, and merchants will see custom storefronts that are faster than ever with an improved Hydrogen product.
> https://shopify.engineering/remix-joins-shopify

また、Hydrogenに関して以下のような発表がありました。特に下記4点の機能に関して言及があり、買収による変化が出ていそうです。
> The February ‘23 release of Hydrogen will bring significant advancements in developer experience and performance, and a suite of new tools specific to Shopify storefronts. Much of what’s unlocked is thanks to leveraging Remix (now a part of Shopify!) as a foundation to our stack.
> https://hydrogen.shopify.dev/roadmap/

1. データ読み込み
詳しくは下記リンクを参照ください。filterを入れたり、下記のように必要なデータだけを返したりすることができるようになったようです。

```js
// 一部抜粋
// You can also shape your data here prior to returning it to the route.
const formattedData = json({
  product: await productQuery,
});
return formattedData;
```

2. ルーティング
ファイルベースルーティングであることは同じようですが、より簡潔にわかりやすく記述できるように改善されているようです。

3. エラー処理
下記で説明されているNested Route error boundaryの機能が利用可能になったようです。
https://remix.run/docs/en/v1/guides/errors#nested-error-boundaries

4. ミューテーション
Optimistic UIがサポートされたようです。
https://remix.run/docs/en/v1/guides/optimistic-ui

## 最後に
今回Remixについて(途中でShopify, Hydrogenに脱線しましたが)調べてきました。
「ShopifyとRemixには、多くの共通の哲学とデザイン原則があり、開発者がユーザーを第一に考えられることが重要」という旨の記述がありました。
今後、両者がより良いものへ発展していくことを願っていきます。

※1 Hydrogenとはカスタムストアフロントの構築を簡素化するReactフレームワーク(https://www.shopify.com/jp/blog/unite-2021)
GoogleAppEngineしか使ってなかったのに急に請求が来たので理由を探る


## 導入

以前、こちらの記事でHeadlessCMSであるStrapiをGAEにデプロイしたのですが、無料枠の範囲内で運用していたはずが急に請求が飛んできました。

https://qiita.com/ikea_shark_jk/items/02e64d3712f847fb5368

GAEのインスタンスサイズはF1、max_instancesは1としていたので請求が発生するはずがありません。
なぜ請求が発生してしまったのでしょうか。

## 犯人

犯人は GoogleCloudStrage (GCS) でした。
GAEはデプロイ時にCloud Buildを使用するのですが、その際の生成物をGCSの適当 (誤用でない意味の方の適当) なバケットに保存します。
この際、GAEのデプロイ先によってバケットの生成されるリージョンが変化します。

ではここでGCSの無料枠を見てみましょう。・

https://cloud.google.com/free/docs/free-cloud-features?hl=ja#storage

> 5 GB 月の Regional Storage（米国リージョンのみ）
> 5,000 回のクラス A オペレーション（1 か月あたり）
> 50,000 回のクラス B オペレーション（1 か月あたり）
> 1 GB の北米から全リージョン宛ての下りネットワーク（1 か月あたり、中国とオーストラリアを除く）
> 
> 無料枠を利用できるのは us-east1、us-west1、us-central1 リージョンのみです。使用量の計算は、これらのリージョンすべての合計が集計されます。

はい。
ここで重要なのは、無料枠はこれらのリージョンの場合のみだということです。

GAEの設定時に調子に乗って東京を選択すると、当然のごとくバケットは東京リージョンに設定されます。
これが、課金された理由です。

  　
  　
  　
  　
  　
  

**嘘です。**
GAEのリージョンによって生成先のバケットが変化するのは確かですし、GCSの課金が米国リージョンのみとドキュメントに記載されているのも確かですが、それによって東京リージョンに生成されたバケットの料金が (少なくとも一両日中に) 請求されることはありません。


では、なぜ課金が発生したのでしょうか。
答えは、コンソール画面を見た瞬間一目で察することができるかと思います。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/532032/816df584-ec56-fe07-d4bc-414257ed3895.png)

はい。
謎のマルチリージョンバケットが生えてますね。こいつが犯人です。

実際、中身を見たり検索して調べたりして特に問題なさそうだと思い消してみたのですが、以降現状の課金額の若干上に設定したアラートから課金の連絡は来ていません。

理由は定かではありませんが、GAEはデプロイを繰り返すとマルチリージョンのバケットをなぜか生成するようです。
こちらのバケットですが、消してもデプロイ済みのアプリケーションに問題は生じません。
ただし、再度デプロイする際の時間が若干長くなります。
毎日何度も更新するようであれば、消さなくてもいいかもしれませんが、そうでないなら消してしまった方がよいかもしれません。

ちなみに、公式ドキュメントからその文面を見つけることはできなかったのですが、ネットを探っているとGAEにデプロイして発生した単一リージョンのバケットは課金がされないといった記述をよく見ます。
事実、マルチリージョンのバケットを消してからは通知が来ていません。
GCSの課金が月次の課金だったらわかりませんが、マルチリージョンと単一リージョンと異なるとはいえ、普通に考えて課金のタイミングが異なるとは考えにくいので大丈夫でしょう。


## 余談

この際に生じた課金額は、一晩で16円でした。
一晩で気が付いたのでそこまでではないですが、一か月間気が付かなかったとかになるとランチ一食分くらいにはなるので気を付けたいですね。
【Git】fatal: detected dubious ownership in repository 解消法  

## 状況
`git pull`を実行した際に次のエラーが発生しました。

```terminal
$ git pull origin main
fatal: detected dubious ownership in repository at '/workspaces'
To add an exception for this directory, call:

        git config --global --add safe.directory /workspaces
```

## 対処法

### リポジトリのファイル等の所有者を変更する

次のコマンドを実行してリポジトリのファイル等の所有者を変更します。

```terminal
sudo chown -R user /workspaces
```

### safe.directoryに追加

上記を実行しても改善しない場合には次のコマンドを実行してsafe.directoryに追加します。

```terminal
git config --global --add safe.directory /workspaces
```
今年もクリスマスプレゼントにCardboardでゲームを作ろう。


.NET MAUIアドベントカレンダー2022の21日目です。


ここは.NET MAUIのアドベントカレンダーですが、内容はXamarin.Androidに関するものです。XamarinはMAUIの先祖ですので、ここに投稿することをお許しください。

# OpenGLは文字描画できない。

私は、Xamarin.Androidを利用して、OpenGLを利用した3Dアプリを開発しています。
Androidに限りませんが、OpenGLで3Dアプリを作成するときに問題になるのが、画面に文字を表示する方法が無い事です。アプリ作成時、変数をデバッグしたり、FPSの値などを表示するために、画面に文字を表示したくなることはありませんか？OpenGLは、ポリゴンを組み合わせて美しいモデリングデータを描画できますが、実は、文字を描画することができません。

じゃあどうするのかというと、文字をテクスチャに画像として描画し、それをポリゴンに貼り付けて画面に表示します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/245196/5dc79445-6b05-0bf4-1488-c429b023d82f.png)

もちろんこのやり方でいいのですが、画面に「Tap Screen to Start!」と表示するためだけにテクスチャでいちいち描画するのが、ちょっと面倒くさいんですよね。。。

# OpenGLは直線は描画できる。

ところでWindowsやMacでOpenGLプログラミングをする際には、OpenGLの補助ユーティリティである「GLUT」（OpenGL Utility Toolkit）を利用することができます。
このGLUTには、文字を描画するための関数があります。どうやって表示しているのかというと、実はOpenGLには直線を描画する機能があり、それを利用して描画しています。ただし、日本語は表示できません。アルファベットと記号のみです。

今回、これと同じやり方で、自作のXamarin.Androidアプリでも、文字を描画できるようにしてみましょう。ただし、GLUTは内部にフォントデータを持っているのですが、ライセンス的に自由に使用してよいかわからなかったので、フォントデータも自分で作成することにしました。

エクセルを方眼紙にして、画面を見ながら、ああでもないこうでもない、といいながら直線を引きました。そして、完成したフォントが、これです！

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/245196/80090c21-84d0-2ab9-8174-fa9cdc51e8dd.png)

。。。正直微妙ですが、許してください。私にはこれが限界です。

# フォントデータ

たとえば「A」の文字を描画するためのフォントデータは以下のようになっています。直線の始点と終点の(X, Y)座標の配列となっており、例えばオレンジ枠で囲った部分が、オレンジ線を引く部分に対応します。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/245196/f485c848-b771-af30-04fb-39df2cace3ab.png)

このように、大文字ABC...、小文字abc...、記号などのフォントデータを準備します。そしてOpenGLの直線を引く機能で、画面に描画することで、文字を表示しています。

# 今年も、Cardboardでゲームを作ろう。

この機能を利用して、クリスマスプレゼントにゲームを一つ作ろうと思います。
昨年、私は、このアドベントカレンダーで、Cardboardを利用したゲームを開発しました。

https://qiita.com/secile/items/4ba98e6d963a3fba808e

Cardboardというのは、スマホで手軽にVRを楽しむことができる、Googleが開発したライブラリです。以前はXamarinからCardboardを利用するのは難しかったのですが、おととしのアドベントカレンダーで、私は、デコンパイルされたCardboardをC#で書き直し、簡単に利用できるようにしていました。

https://qiita.com/secile/items/147acc872f63a7cffa49

今年は、去年作ったゲームをちょっと手直しして、新しいゲームを作ってみようと思います。

# こんなゲームができました。

![Screenshot_1671628159.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/245196/a2df09d6-0cf3-4970-3aa1-fd4a07be4292.png)

* たくさんのアルファベットがかかれたパネルが地面に立っています。

![Screenshot_1671627718.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/245196/d39cd796-69b2-c0c1-8f7e-76665cb6179e.png)

* Aから順番に、パネルを倒していきましょう。

![Screenshot_1671627766.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/245196/98155176-96d3-6d49-3027-1d173bc8efc9.png)

* パネルを倒すには、スマートフォンの加速度センサーを利用します。おすすめは、腕をのばしてパネルをたたくイメージです。または、スクリーンタッチでも倒すことができます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/245196/fa6a2ab6-638b-7fe1-c44b-d812c6ef0424.png)


* すべてのパネルを倒すと、ゲーム終了です。倒すまでのタイムを競いましょう。

![Screenshot_1671627907.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/245196/5949fcc7-bcc2-49e6-429e-e735f9e1c943.png)


# ソースコードを公開しています。

ゲームのソースコードはgithubで公開しています。

https://github.com/secile/ShootAtoZ

完成したゲームはGoogle Playからダウンロードして遊ぶことができます。

https://play.google.com/store/apps/details?id=net.secile.shoot

# まとめ

それでは、メリークリスマス！