OmniAICreator/Qiita-1.07M huggingface dataset:
入力候補

```
@section('stylesheet')
    {{-- style here --}}
    <link rel="stylesheet" type="text/css" href="{{ asset('common/css/jquery-ui.css').'?'.time()  }}">
@stop_od2 

<dt>{{ __('名前') }}</dt>
<dd>
<div class="{{ !empty($errors->first('bank_name')) ? 'has-error' : '' }}">
<input type="text" id="bank_name" name="bank_name" maxlength="50" data-api-url="{{ route('api.financial.get-bank-list') }}">
<p class="help-block">{{ !empty($errors->first('bank_name')) ? $errors->first('bank_name') : '' }}</p>
</div>
</dd>
<dt>{{ __('コード') }}<span class="tooltip" title="{{ __('・キャッシュカードまたは通帳記載の店番号を入力してください。<br>・ゆうちょ銀行の場合は、振込用の店番号を入力してください。') }}"></span>（{{ __('半角数字3桁') }}）　</dt>
<dd>
<div class="{{ !empty($errors->first('bank_branch_code')) ? 'has-error' : '' }}">
<input type="text" id="bank_branch_code" name="bank_branch_code" maxlength="3" class="half" data-api-url="{{ route('api.financial.get-branch-list') }}">
<p class="help-block">{{ !empty($errors->first('bank_branch_code')) ? $errors->first('bank_branch_code') : '' }}</p>
</div>
</dd>



@section('script')
<script type="text/javascript" src="{{ asset('common/js/jquery-ui.js').'?'.time() }}"></script>
<script type="text/javascript" src="{{ asset('pages/contract/changeconfirm.js') }}"></script>
@stop
段取り道

# プロローグ
Google「段取り八分（はちぶ）」とは、仕事に取りかかる下準備が完全にできていれば、仕事の8割は終わったようなものという意味です」

Blog A「目的を明確化して～～～ゆえに段取りは大切なのです」

Blog B「歌舞伎の世界で使われていた～段取り八分、仕事二分～WBSをしっかり作ることで～～」

Google「準備が8割、本番が2割」

Amazon「段取り八分の仕事術―頭のいいヤツは、段取りで差をつける! 好評発売中！」

Blog C「段取りを怠るな！」

※段取り八分については様々なBlogやサイトで書かれていることですので説明は省きます。



# はじめに
段取り八分という言葉の意味は解った。
段取りが大事だということも良くわかった。

自分の慣れ親しんだ仕事ならば段取りはうまく出来る。いや出来ているはず。たぶん。

新規案件や新しいクライアント、知らない業務やジャンルだったり、
そういった不慣れな場でも上手に段取りを行うことが出来るようになれば、鬼に金棒ではないか。

じゃあ段取りが上手になるにはどうしたら良いの？

そんなあなたと私に向けた内容です。

※数回に分けて投稿してまいります。


# 段取りが上手な人の特徴
私が「この人は段取り上手だ」と感じる特徴（能力）をリストアップしました。
以下の5つの能力に加え、その仕事が早いというのも特徴です。


- 情報感度が高い
- 整理能力が高い
- 見通し能力が高い
- コミュニケーション能力が高い
- 柔軟性が高い


## 情報感度が高い
取り組む課題に役立つ情報をインプットする能力が高く、
またその中から必要な情報を適切に紐付けることができ、それをアウトプットする能力が高いということ。


## 整理能力が高い
手に入れた情報を、自分とそして他のメンバーが活用しやすい形に残す能力が高いということ。
わかりやすく整理された情報は、メンバーによる情報のアップデートを促すという効果もあります。


## 見通し能力が高い
早い段階でクリティカルパスを特定し、それを踏まえた最適な工程計画を立てる能力が高いということ。
また、ボトルネックとなりそうな箇所を見出し、それを回避・解消できる工程を描ける能力が高いのも特徴です。成功と失敗を分析し、経験を活かした適切な対策を打つことができる。


## コミュニケーション能力が高い
クライアントやメンバー、まわりの人と良好な関係を築ける能力が高いということ。

口頭・文章・表情で状況をうまく伝えられるので、仕事を円滑に進めることができます。


## 柔軟性が高い
変更やトラブルへ対応でき、調整能力が高いということ。




# ひとつずつ着実に鍛える
つまり前述したこれらの能力を高めることが出来れば、
段取り上手とまではいかなくても、なりたい自分に近づけるのは確かだ。

一気に鍛えることは難しそうだが、
ひとつひとつ着実に鍛えて行くことはできるだろう。

※各能力の鍛え方については、別の記事で深堀りしながら具体的に書いていきます。


# まずは段取りの基礎を作る

日々行っている私なりの基礎作り、それは日報です。

今日の業務時間でなにをどこまで進めるのか、今日何をするのか、期限は間に合うのか。
課題の依頼主に確認や質問を行うタイミングはあるか。その人物がMTGに入ってしまう時間はいつなのか。
今日は金曜日、突発的に鳴るSlack電話はいつも夕方だなとか。


その日をイメージし、日報を書き起こします。
慣れてきたら1週間、1ヵ月のスケジュールを意識しながら、その日のスケジュールを立ててみてください。

15分という決められた時間の中で、どれだけイメージしそしてアウトプットできるのか。
また終業時には、日報に沿って課題を遂行できたのかという答え合わせもしてみましょう。

こうやって毎朝日報を起こすだけで、自然と段取りの基礎を鍛えることができます。


追伸
日報ってその日の終わりに書くものでしょう？という疑問の声や、
じゃあ具体的にはどんな日報を書くのよといった声が聞こえてきましたが、
それについては、また別の機会に。


# おわりに

段取り上手になれば、目的をスムーズに成し遂げられるようになり、更にコミュニケーションも円滑になります。
良いこと尽くしな段取りライフ、あなたも朝一の隙間時間にはじめてみませんか。




# おまけ

## あとがき

冒頭でも触れましたが、本題材は数回に分けて投稿してまいります。
最初からそのつもりだった。想定通り。

…と言いたいところですが、
本記事を書いている途中で「これは1度で書ききれない題材だ」と気づいたというのが真実です。

内容が中途半端になっており、起承転結や文章の接続に違和感があるのもその為です。

記事を書く際もしっかり段取りしてから書き出す必要があるなと、
「段取り」の大切さを身をもって痛感しました。


## エンドロール

この記事を書いている最中に降りてきたキーワード。
段取り八兵衛, タンドリーチキン, 段ドリング
FAT32の最大容量は4GBじゃない


# <font color="Red"> A. 4GB-1 バイトです</font> 

なぜか4GBのファイルが入らなかったから不思議に思いました。
[wikipediaには書いてあります](
https://ja.wikipedia.org/wiki/File_Allocation_Table)

|                        | FAT12                  | FAT16                                                                             | FAT32                                                                             | exFAT                      | 
| ---------------------- | ---------------------- | --------------------------------------------------------------------------------- | --------------------------------------------------------------------------------- | -------------------------- | 
| <b>最大ファイルサイズ</b>     | 32MiB                  | 2GiB<br>4GiB (NT)                                                                 | 4GiB - 1 byte                                                                     | 16EiB                      | 
| クラスタサイズ</b> 	 	 	 	 | 512byte 〜 32KiB       | 512byte 〜 32KiB（NT系では64KiB、セクタサイズが512バイトより大きい場合は 256KiB） | 512byte 〜 32KiB（NT系では64KiB、セクタサイズが512バイトより大きい場合は 256KiB） | 512byte 〜 32MiB           | 
| <b>最大ファイル数</b>         | 4,077                  | 65,517                                                                            | 268,435,437                                                                       | ディレクトリ毎に 2,796,202 | 
| <b>最大ボリュームサイズ</b>   | 32MiB                  | 2GiB<br>4GiB (NT)                                                                 | 2TiB<br>8TiB（2KiBセクタ）                                                        | TBU                        | 
| <b>最大ファイル名長</b>       | 8.3形式、または255文字 | 8.3形式、または255文字 | 8.3形式、または255文字 | 255文字                    | 


## 検証

```
dd of=zero if=/dev/zero bs=4294967296
```

4294967295バイトまでしか入りません。

```
dd: error writing 'zero': File too large
0+3 records in
0+2 records out
4294967295 bytes (4.3 GB, 4.0 GiB) copied, 36.0136 s, 119 MB/s
```
複数のカメラキャリブレーションパラメータ設定

「instantNeRFで遊ぶ Advent Calendar 2022」の9日目です。

今日は複数のカメラキャリブレーションパラメータ設定について検証しました。

:::note
業務外の個人的な検討活動です。
:::

#### nerf_loader.cu
焦点距離や歪パラメータの読み込み部分を読んでいると、”see if there is a per-frame override”というコメントを見つけました。
![9-1.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/103446/f470b1fa-3679-cdad-4e5b-fad1edca92d0.png)

#### transform.json
"frames"の中にfl_x, fl_y, k1, k2, p1, p2, cx, cy, w, hを入力しました。
![9-2.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/103446/a9cdc375-aa40-52b1-334e-6c3d47cee425.png)

#### testbed.exe
命令はいつもと同じです。

従来（カメラの内部パラメータを一つしか使わない場合）
![9-4.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/103446/bcbd74df-af60-c38f-a62f-0467e57b44e1.png)
変更（カメラの内部パラメータをフレームごとに変えた場合）
![9-3.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/103446/9cc5536c-f517-4109-7366-7dd2c8a0d349.png)

残念ながら、PSNRの値はほとんど同じで、見え方の違いも明確に分かりませんでした。

画角が違うカメラを混ぜたような分かりやすいデータで試したほうが良かったです。
JetRacerをアクセスポイントにする

JetRacerで遠征に行く場合は、アクセスポイントがない場合が多く、アクセスポイントをJetRacerにしちゃいましょう。

ネットワーク接続ソフトウェアであるNetworkManagerの設定を行います。
コマンドはNetworkManagerのCLIでnmcliコマンドを使います。

```bash
sudo vi /etc/NetworkManager/NetworkManager.conf
```

DNSサーバーとしてdnsmaqを使用するので
dns=dnsmasqの１文をmain内に追記します。（３行目）

iで編集モードにしてdns=dnsmasqを追加します。

```bash
[main]
plugins=ifupdown,keyfile
dns=dnsmasq

[ifupdown]
managed=false

[device]
wifi.scan-rand-mac-address=no
```
ESCキーを押して、:xで保存します。

nmcli con addでコネクション名をJR27としSSID名をjetracer27carとコネクションを追加します。

```bash
sudo nmcli con add type wifi ifname wlan0 mode ap con-name JR27 ssid jetracer27car
```
以下、nmcli con modifyを使用しコネクションの変更いたします。802.11 周波数帯域であるbgを設定

```bash
sudo nmcli con modify JR27 802-11-wireless.band bg
```

使用するWi-Fiチャンネルを１チャンネルとします。（電波環境に合わせて変更します。）

```bash
sudo nmcli con modify JR27 802-11-wireless.channel 1
```

無線暗号をWPA-PSKに設定

```bash
sudo nmcli con modify JR27 802-11-wireless-security.key-mgmt wpa-psk
```

WPAのプロトコルRSNを設定

```bash
sudo nmcli con modify JR27 802-11-wireless-security.proto rsn
```

グループ暗号化リストアルゴリズムCCMPを設定

```bash
sudo nmcli con modify JR27 802-11-wireless-security.group ccmp
```

ペアワイズ暗号化リストアルゴリズムCCMPに設定

```bash
sudo nmcli con modify JR27 802-11-wireless-security.pairwise ccmp
```

パスワードをjetracer_apと設定します（パスワード名は、任意）

```bash
sudo nmcli con modify JR27 802-11-wireless-security.psk jetracer_ap
```

IP4で共有

```bash
sudo nmcli con modify JR27 ipv4.method shared
```
設定をアクティブ化

```bash
sudo nmcli con up JR27
```
IPアドレスを10.0.0.1にする。

```bash
sudo nmcli con modify JR27 ipv4.addr 10.0.0.1/24
```

設定を反映してリスタートする。

```bash
sudo systemctl restart NetworkManager.service
```

SSIDにjetracer27carが発見できるはずです。セキュリティーキーで接続します。
10.0.0.1でアクセス可能となるはずです。これでルータを忘れても安心ですね。
モジュール内の特定のクラスのみインポートする方法(Swift)

## はじめに

本記事は [iOS Advent Calendar 2022 その2](https://qiita.com/advent-calendar/2022/ios) の1日目の記事です。

モジュール内の特定のクラスのみインポートする方法を紹介します。

## 環境

- OS：macOS Ventura 13.0.1
- Xcode：14.1 (14B47b)
- Swift：5.7.1

## 結論

`import class {モジュール名}.{クラス名}` でモジュール内の特定のクラスのみインポートできます。

例えば `UIKit` モジュールの `UIImage` クラスのみインポートする場合、以下のように書きます。

```swift
import class UIKit.UIImage

let image = UIImage(named: "uhooi")
```

`UIKit` モジュール内の他のクラスを呼び出そうとすると、ビルドエラーになります。

```swift
import class UIKit.UIImage

let color: UIColor = .red // ❌: Cannot find type 'UIColor' in scope
```

## 注意

### import kindを忘れずに付ける

`class` などのimport kindを付けずに `import {モジュール名}.{クラス名}` とすると、クラスでなくサブモジュールの指定となり、場合によっては `import {モジュール名}` と同じ動きになるようです。

```
import {import kind} {module}.{symbol name}
import {module}.{submodule}
```

引用: https://docs.swift.org/swift-book/ReferenceManual/Declarations.html

例えば `import UIKit.UIImage` だと、 `UIColor` など他の `UIKit` モジュール内のクラスも呼び出せてしまいます。

私は今までこの書き方をしていたため、急いで修正しました。

https://github.com/uhooi/UhooiPicBook/pull/353

### ビルド時間とバイナリサイズはほぼ変わらない

try! Swift Tokyo Conference 2019のある発表によると、インポートを絞ってもバイナリサイズは変わらず、平均ビルド時間はむしろ増えたようです。

https://www.youtube.com/watch?v=8OMQ2DiS-zA

そのため、ビルド時間の短縮やバイナリサイズの縮小を目的に行うのは意味がなさそうです。

## おわりに

Swiftでは特定のクラスのみインポートしたいユースケースは少ないかもしれません。
私はView層以外でUIKitを使いたいときに、UIKitの他のクラスを呼び出していないことを明確にするために使います。

以上 [iOS Advent Calendar 2022 その2](https://qiita.com/advent-calendar/2022/ios) の1日目の記事でした。
明日はまだ埋まっていません。

## 参考リンク

- [swift/Modules.rst at ef8c34e62223a0c0a13ad40b41213c782955f101 · apple/swift](https://github.com/apple/swift/blob/ef8c34e62223a0c0a13ad40b41213c782955f101/docs/Modules.rst)
- https://twitter.com/the_uhooi/status/1600103396693811200
javascript  splitメソッドの使い方

競プロのサンプル問題にsplitメソッドがあったので忘れないように記事化。

splitメソッドは、文字列をある文字で区切って分割する関数である。

使い方は、<h4>文字列(※変数).split(区切り文字)</h4>
<br>
<br>

例えばこのように記述すると、

![スクリーンショット 2022-12-06 21.13.16.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2982162/1d49f7ec-be60-3469-e24f-667fbc9230a3.png)

↓↓このように出力される。↓↓

![スクリーンショット 2022-12-06 21.14.38.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2982162/319b718e-37f2-80ce-96e1-aad9b3edcb0b.png)
コイントスするだけのクソアプリを作りました！

# はじめに
この記事は「[クソアプリ Advent Calendar 2022](https://qiita.com/advent-calendar/2022/kuso-app)（カレンダー3）」7日目の記事です。

![cointoss.gif](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/95865/93ad7364-ae99-4361-7e3f-79ccfc1a07d7.gif)

# なぜ作ろうと思ったのか？
もともとはポケモンカードゲームなどで先攻・後攻を決める時、手持ちのコインが無くてもWeb上でコイントス出来たら良いな、と考えて作りました。
でもポケカプレーヤーはコインにもこだわるはずなので、持ち歩かないとかあるんですかね？…無いような気がしてきました。でもまあ、それ以外の用途でも、**何か大事なことを決めたい時に、コイントスしたいような稀有な人（？）がいるかも**知れません。

▼完成品はこちら▼

https://cointoss-jp.netlify.app/

# 謎のこだわり
裏表の判定をするだけするなら見た目は2Dで良いかなと思いましたが、敢えて3Dでやってみたくなりました。
物理演算を使って実際にコイントスをシミュレートするため、JavaScript製の3D物理演算エンジンについて調べました。

# 仕組み
3Dの見た目部分は「Three.js」、物理演算には「Cannon.js」というJavaScriptライブラリを使っています。
「Cannon.js」は「Three.js」と相性が良いので一緒に使いやすいらしかったのです。

## 設定について
1. Cannon.jsで物理演算を行うためのワールドを作成
2. Cannon.jsでコインと床作成
3. Three.jsでシーン・カメラ・ライト・レンダラーを設定
4. Three.jsでコインと床作成（Cannon.jsで作成したものと対応するオブジェクトを作成）
5. レンダリング

「Cannon.js」と「Three.js」の連携方法については、下記が分かりやすかったです。

[three.jsとcannon.jsの連携メモ - メモの穴](https://memonoana.hatenablog.com/entry/2017/08/30/152039)

## 指で上にスワイプ
始めは画面上をクリックで、ランダムに力を加えてコイントスさせようとしていましたが、ゲーム的な要素を入れたくなり画面を上にスワイプすることで、実際にコイントスしているかのような仕組みを入れることにしました。
デスクトップでもスマホでも対応したかったので良くある両対応のタッチイベントを使っています。

```javascript
const _touchstart = window.ontouchstart === undefined ? 'mousedown' : 'touchstart';
const _touchend = window.ontouchstart === undefined ? 'mouseup' : 'touchend';
toucharea.addEventListener(_touchstart, touchStart, false);
toucharea.addEventListener(_touchend, touchEnd, false);
```

あとはタッチ開始からタッチ終了までの距離によってランダム値を変えてやり、CSSに反映してゲージを表示するだけです。

# 要るこれ？
ちなみにGoogleで「コイントス」と検索すればその場でコイントスを行ってくれます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/95865/fb4de319-aa1b-966d-07d7-90c0149e77d7.png)

また、「サイコロを振る」などで検索すると、多面体サイコロとかも出せるのでボードゲーマーにも有益ですね。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/95865/f65e3912-d64d-e8bf-d4c8-3f89d096ff19.png)
Google検索、何でもあってすごいですね。。
あんま作る意味なかったかもですが、JavaScript製の3D物理演算エンジンを使ってみたかったのでまあ(๑•̀ㅂ•́)و✧ﾖｼ！としましょう！！！
オンラインDDLの落とし穴

# 0. はじめに
MySQL5.6よりオンラインDDL機能が導入され、その恩恵を受けている方も多いと思います。機能自体はとても便利な反面、詳細な動作をきちんと認識していないと思わぬ落とし穴に嵌ってしまうこともあります。今回はそんなオンラインDDLでの失敗談をお届けします。

オンラインDDLとは (MySQL :: MySQL 5.6 リファレンスマニュアル :: MySQL 用語集より)
> DDL (主に ALTER TABLE) 操作中の InnoDB テーブルのパフォーマンス、並列性、および可用性を改善する機能

# 1. 何をやったか
本番稼働中のDB（Aurora MySQL）に対してDROP INDEXを行いました。

直近のインデックス追加の影響で、意図しないクエリの実行計画が変わりスロークエリが発生していたためです。
（メンテナンス状態でないときのALTER TABLEは怖すぎるので普段はしないですが、その時はサービスへの影響が大きかったので仕方なく対応を行いました。）

自分の認識では、INDEX操作はオンラインDDLのカバー範囲で、操作対象のテーブルはロックされることなくインデックスが削除されると思っていました。

# 2. 何が起きたか
Waiting for Table metadata lockが大量に発生し数分間AuroraへのSELECTその他のクエリが待機状態になり、その後Auroraのフェイルオーバーが発生しました。
フェイルオーバーにより一旦すべての接続が切断され通常通りの動作に復旧しました。

(この間サービスは使えなくなっていたと思われます、焦ってるうちにフェイルオーバーしました笑)

# 3. 何が起きたか（詳細）
もう少し詳しく説明をします。

- オンラインDDLの仕様
今回のメインです。
オンラインDDLの仕様として、**オンラインDDLの開始前、完了前にそれぞれ短時間ではあるものの排他的アクセスが必要**というものがあります。
これによって以下3つのことが発生します。

    ①進行中のトランザクションが完了（コミットorロールバック）するまでDDLが開始されない
    ②DDL開始～完了の間に開始されたトランザクションがすべて完了するまでDDLは完了できない
    ③DDLが完了するまでDMLはメタデータロック待ち状態になる

    少し長めのトランザクションが実行され、且つDMLが大量に流れるような環境では②③が発生しやすくオンラインDDLには向いていないと言えそうです。

- Auroraのフェイルオーバー
結果的にこれに助けられました。
Auroraクラスター内で、リーダーインスタンスがライターインスタンスに昇格します。
フェイルオーバー自体のスピードはかなり速く、一度接続は切れましたがその後すぐに使えるようになりました。
ちなみにこの時点でもともとのDROP INDEXは無事(？)に反映されていました。

# 4. 終わりに
何をするにせよ、浅い知識でそれっぽいことをするのは危険です笑
オンラインDDLはとても便利な反面、なかなか深い落とし穴があるなと感じました。

今回のケースでいえば、もしDBがAuroraでなく例えばオンプレミスだったら、おそらくmax_connectionに抵触してDB自体が使えなくなっていたと思われます。
（その前にサービスが使えないというクレーム電話がじゃんじゃん鳴ったかも）

サービスを運用する身として、日々知識のアップデートをしていかないといけないなと痛感した出来事でした。

# 5. 参考
https://ysk-pro.hatenablog.com/entry/mysql-metadata-lock#%E3%82%AA%E3%83%B3%E3%83%A9%E3%82%A4%E3%83%B3DDL%E3%81%AE%E6%B3%A8%E6%84%8F%E7%82%B9%E3%81%A8Waiting-for-table-metadata-lock-%E3%81%8C%E7%99%BA%E7%94%9F%E3%81%99%E3%82%8B%E3%82%B1%E3%83%BC%E3%82%B9
デイトラ「Web制作コース」　受講内容をアウトプット 9日目

学んだことをアウトプットしています。完全に自己満足ですので悪しからず。
以下の点を確実にアウトプット
①何で学んでるか
②日々の学習内容
③学びのポイント
④制作物
⑤+αで参考にした記事
⑥+αでやってみたこと

①デイトラ「Web制作コース初級編」
② HTML/CSSコーディング復習②
③復習して忘れていたこと
　なし
④練習用サイト
⑤なし
⑥なし
BigQueryで横持ちデータを縦持ちに変換する方法

横持ちのデータを縦持ちに変換して使いたかったので調べらた`UNPIVOT`と呼ばれる演算子が存在することを知りました。
ドキュメント見ても使い方がピンとこなかったので備忘録がてら使い方と考え方を紹介。

# やりたいこと
例えば、動画再生回数を4半期毎に管理する`views`テーブルがあったとします。
このテーブルは動画のタイトルとQ1～Q4までの期間で何度動画が再生されたかを持っています。

|title       |Q1   |Q2   |Q3   |Q4   |
|------------|:---:|:---:|:---:|:---:|
|逆襲のシャア |1200 |2500 |900  |1100 |
|彗星の魔女   |3300 |3000 |2100 |2200 |

それを何らかの要件により1レコードを1クオーターで取得したくなりました。
つまり、「逆襲のシャア」のQ1での再生回数、Q2での再生回数・・・Q4での再生回数といった形です。

|title       |plays|quarter|
|------------|:---:|:-----:|
|逆襲のシャア |1200 |Q1     |
|逆襲のシャア |2500 |Q2     |
|逆襲のシャア |900  |Q3     |
|逆襲のシャア |1100 |Q4     |
|彗星の魔女   |3300 |Q1     |
|彗星の魔女   |3000 |Q2     |
|彗星の魔女   |2100 |Q3     |
|彗星の魔女   |2200 |Q4     |

# クエリ
冒頭で触れた通り`UNPIVOT`（アンピポット）演算子を使うと一発でやりたいことが実現できます。

https://cloud.google.com/bigquery/docs/reference/standard-sql/query-syntax?hl=ja#unpivot_operator

```sql
WITH views AS (
  SELECT '逆襲のシャア' as title, 1200 as Q1, 2500 as Q2, 900 as Q3, 1100 as Q4, UNION ALL
  SELECT '彗星の魔女', 3300, 3000, 2100, 2200)

SELECT * FROM views UNPIVOT(play_count FOR quarter IN (Q1, Q2, Q3, Q4))
```

# 考え方
`UNPIVOT`を使ってめでたく実現したいことはできたのですが、この演算子の使い方を理解するのに頭を悩ませました。
実際に手を動かしクエリを発行しても、構文のどこが結果に掛かってくるのかイメージを持てず？？？だったので、僕なりの解釈をしてみました。

## 構文の日本語化

```sql
SELECT
  * 
FROM 
  [テーブル or サブクエリ] UNPIVOT([縦持ちにしたいカラムのデータを保持するカラム] FOR [縦持ちにしたいカラムのカラム名を保持するカラム] IN (縦持ちにしたいカラム))
```
まずはクエリ構文をこんな感じで日本語化してみます。
この段階で「ほぅ」と理解はできないので上記て使った`views`を題材に段階的に解きほぐしていきます。

### 1. `テーブル or サブクエリ`

これは書いてある通りで、テーブルかサブクエリを指定します。
なので当てはめるのは`views`です。

```sql
SELECT
  * 
FROM views UNPIVOT([縦持ちにしたいカラムのデータを保持するカラム] FOR [縦持ちにしたいカラムのカラム名を保持するカラム] IN (Q1, Q2, Q3, Q4))
```

### 2. `縦持ちにしたいカラム`

ここが重要なんですが、どのデータを縦持ちにしたいのかを指定します。
やりたいことは、「1レコードを1クーターで取得したい」なので、Q1～Q4を当てはめます。

```sql
SELECT
  *
FROM views UNPIVOT([縦持ちにしたいカラムのデータを保持するカラム] FOR [縦持ちにしたいカラムのカラム名を保持するカラム] IN (Q1, Q2, Q3, Q4))
```

### 3. `縦持ちにしたいカラムのカラム名を保持するカラム`
カラムカラムでややこしいんですが、要はQ1、Q2、Q3、Q4を縦持ちにしたいんだよね？
OK、じゃあ変換するときに**元がなんてカラム名だったのか**分かるように新しいカラムを定義してそこに突っ込んどくぜ！
ってのを指定する箇所です。

任意の名称を付けられるので表現にあったカラム名を指定します。

```sql
SELECT
  *
FROM views UNPIVOT([縦持ちにしたいカラムのデータを保持するカラム] FOR quarter IN (Q1, Q2, Q3, Q4))
```

### 4. `縦持ちにしたいカラムのデータを保持するカラム`
最後に元のQ1、Q2、Q3、Q4に入っている値（再生回数）は変換後どこに入れるの？って部分を指定します。


こちらも任意の名称を付けられるので表現にあったカラム名を指定します。

```sql
SELECT
  *
FROM views UNPIVOT(play_count FOR quarter IN (Q1, Q2, Q3, Q4))
```

### 結果
**元データ : `SELECT * FROM views`**
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/410918/6a2c26d8-f1d3-7766-afb2-fa5ea71a40bb.png)

**UNPIVOT : `SELECT * FROM views UNPIVOT(play_count FOR quarter IN (Q1, Q2, Q3, Q4))`**
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/410918/d084a34b-bf93-5f67-dabd-75d200630e94.png)

# 所感

頻繁に利用することはないと思いますが、ハマればとても便利だと思います。
ただ慣れてないと初見でうっとなる気もしますが。。。（僕もそう

# 参考
`UNPIVOT`の名前の通りピボットをアンしている演算子になるので、縦持ちデータを横持ちに変換する`PIVOT`もあります。

https://cloud.google.com/bigquery/docs/reference/standard-sql/query-syntax?hl=ja#pivot_operator
デイトラ「Web制作コース」　受講内容をアウトプット 8日目

学んだことをアウトプットしています。完全に自己満足ですので悪しからず。
以下の点を確実にアウトプット
①何で学んでるか
②日々の学習内容
③学びのポイント
④制作物
⑤+αで参考にした記事
⑥+αでやってみたこと

①デイトラ「Web制作コース初級編」
② HTML/CSSコーディング復習① 
③復習して忘れていたこと
　・li.header-nav-item*3>aという記載方法
　・text-decoration: none;でaタグの下線をなくす
④練習用サイト
⑤なし
⑥なし
レッドチーム演習 とは

## 勉強前イメージ

セキュリティの練習的な？

## 調査

### レッドチーム演習 とは

企業やチームがサイバー攻撃に対処するための演習の一つで
外部のサービスなどと契約を行い、顧客に対して物理や人を組み合わせて
物理・仮想問わず様々な攻撃を仕掛けてセキュリティ対策の実効性を検証するものになります。
元々軍隊で攻撃を仕掛ける側をレッドチーム、防御する側をブルーチームと呼んでたことからつけられました。
他にもレッドチームングオペレーションなどとも言われたりしています。

### レッドチーム演習の内容

- 調査

まずはレッドチームは企業の調査を行うところから始まります。
物理的にビルに入ってみたり電話をかけたりなど行うこともあります。

- デリバリ

調査で確認したターゲットに向けてウイルスが添付されたメールを送るなどして攻撃を行います。
そしてターゲットの情報を入手し、侵入できる状態にします。

- 基礎構築

パソコンやサーバなどの管理権限を入手し、そこから他のネットワークへ攻撃する準備を行います。

- 権限昇格

ドメイン全体の管理権限の取得を進めます。

- 調査

ドメイン全体の管理権限を入手します。
その次に機密情報を取得するという方法で進めます。

- 目的達成

すべて終わったら報告書にまとめて演習完了になります。

### 似たようなもテストもあります。

[ペネトレーションテスト](https://qiita.com/miyuki_samitani/items/61c55869676ba5b6b064) と呼ばれるテストがあり、
これは日本語では侵入テストや侵入実験と呼ばれ
ネットワークに接続されているシステムに対して既知のサイバー攻撃を疑似的に行うなど侵入を試みることで脆弱性があるかのテストを行う手法のことを指します。

レッドチーム演習との大きな違いは、対象の範囲となります。
ペネトレーションテストはあくまでシステム上のテストを行い、脆弱性もシステム上の脆弱性を確認します。
しかし、レッドチーム演習は物理的なオフィスのセキュリティなども含めて評価を行います。
そこが大きな違いとなります。

## 勉強後イメージ

物理的なやつも含まれるのか・・・・

## 参考

- [レッドチーム演習とは？内容やペネトレーションテストとの違い、メリットデメリットについて徹底解説](https://cybersecurity-jp.com/security-measures/34360)
- [レッドチーム演習【red team operations】](https://e-words.jp/w/%E3%83%AC%E3%83%83%E3%83%89%E3%83%81%E3%83%BC%E3%83%A0%E6%BC%94%E7%BF%92.html)
pnpmでstorybookを使用する

`pnpm`は、`npm`や`yarn`よりも基本的に高速かつ小さいサイズでライブラリをインストールしてくれるnode.jsのパッケージマネージャーです。

当然のことながら、pnpmのことを知っている人の多くは可能であればpnpmを使いたいと思っているでしょう。
ですが、pnpmの欠点として、pnpmに対応していないライブラリが多く存在するという点がありました。

特に有名なのが`storybook`です。
昨今のチーム開発において、storybookは準必須といっても過言ではないライブラリであり、特にデザイナーと仕事をするのであれば必須かもしれないライブラリでしょう。そのstorybookはpnpmに対応していませんでした。

おそらく、storybookとpnpmを両立できないために、pnpmを使用してこなかったという方はそこそこいるんじゃ無いでしょうか。

本記事では、その問題を解消してみようと思います。

## どうすれば解決するのか

### 環境

- node: 18.12.1
- @storybook/addon-actions: 6.5.14
- @storybook/addon-essentials: 6.5.14
- @storybook/addon-interactions: 6.5.14
- @storybook/addon-links: 6.5.14
- @storybook/builder-webpack5: 6.5.14
- @storybook/manager-webpack5: 6.5.14
- @storybook/react: 6.5.14
- @storybook/testing-library: 0.0.13
- storybook-css-modules: 1.0.8
- babel-loader: 8.3.0
- sass-loader: 13.2.0

### 解決方法

ざっくり言うと、loaderの参照を`require.resolve`で囲みました。

参考例として、css moduleとsassを使用しているNext.jsのプロジェクトの　設定ファイルを記載します。

```.storybook/main.js
module.exports = {
  "stories": [
    "../**/*.stories.mdx",
    "../**/*.stories.@(js|jsx|ts|tsx)"
  ],
  "addons": [
    "@storybook/addon-links",
    "@storybook/addon-essentials",
    "@storybook/addon-interactions",
  ],
  "framework": "@storybook/react",
  "core": {
    "builder": "@storybook/builder-webpack5"
  },
  webpackFinal: async (baseConfig) => {
    baseConfig.module.rules.push({
      test: /\.scss$/,
      use: [
        require.resolve("style-loader"),
        {
          loader: require.resolve("css-loader"),
          options: {
            importLoaders: 1,
            modules: {
              localIdentName: "[local]___[hash:base64:2]",
            },
          },
        },
        require.resolve("sass-loader"),
      ],
    });
    return { ...baseConfig };
  },
}
```

require.resolveは、対象のライブラリの絶対パスを返す関数です。
これを用いて正しい参照先を渡してあげることで、loaderを読み込めるようにしています。



## そもそもなんでstorybookで使えないの？

昔から色々頑張れば使えなくもなかったらしいのですが、よく検索にヒットする解決策がおま環酷かったので事実上使えないに等しかったと記憶しています。

使えなかった理由は、Webpackでした。
解決策から逆算した推論なのですが、おそらく昔のwebpack4などではpnpm使用時にこれらの参照をうまいこと解決できていなかったのだと思われます。
確かに、pnpmとyarn等の違いってimport時の重複排除等なので、その辺は納得できる理由のような気がしなくもないです。

あまり詳しい実装までは調査の手が回らなかったのですが、調べた感じwebpack5である程度その辺りが改善されたらしく、require.resolveによる解決がうまく働くようになったらしいです。

個人的には、webpackもそろそろ次の世代に世代交代感が出ているので、アドオン等ではなく公式でesbuildに対応してくれるといいんですけども……

記事の作成には、こちらのissueを参考にしました
https://github.com/webpack/webpack/issues/5087
openapi.ymlで開発を効率化しよう！

# はじめに

この記事は[OPENLOGI Advent Calendar 2022](https://qiita.com/advent-calendar/2022/openlogi)7日目の記事です！

私事ですが2022/12月にオープンロジにジョインしました！頑張ります！
まだ入社して間もないので業務にあまり関われてないのですが個人的に最近やったことを紹介させていただきます！

# 開発にコミットするAPIドキュメントを作る
皆さんの現場ではAPIドキュメントは開発にコミットしていますか？
開発にコミットしていないAPIドキュメントの例として、

- Swaggerを誰かが作ったけどメンテナンスされていない
- メンテナンスしているけど誰も見ていない
- メンテナンスしているけど信頼性が担保されていないので使えない

みたいな状態になっていませんか？

# APIドキュメントを書くと何がいいの？
APIドキュメントって何に使うの？と思うエンジニアも意外と多いのではないでしょうか
実際SwaggerやStoplightで生成したopenapi.ymlが開発にコミットして開発の効率やクオリティを上げる事例を紹介します

## APIテストの自動化
Dreddというツールを使ってopenapiのテストを行うことができます。
PHPUnitなどのテストコードを書かずに、openapiで記述されたレスポンスの型が帰ってくるかをテストできます。

Dredd
https://github.com/apiaryio/dredd
事例
https://qiita.com/EightT/items/c0ad00520c011f2d8361

## モックサーバーの生成
openapiで記述した内容を簡単にモックサーバーにしてくれます
本記事では事例としてPrismでモックサーバーを作ってみましょう！

# Prismを使ったモックサーバーの生成

モックサーバーを生成するために適当なopenapi.ymlを作ります。
```openapi.yml
openapi: 3.1.0
info:
  title: openapi
  version: '1.0'
  summary: sample openapi project
servers:
  - url: 'http://localhost:3000'
paths:
  '/users/{user_id}':
    parameters:
      - schema:
          type: string
        name: user_id
        in: path
        required: true
    get:
      summary: get user
      responses:
        '200':
          description: OK
          content:
            application/json:
              schema:
                type: object
                properties:
                  name:
                    type: string
                  description:
                    type: string
                  post_count:
                    type: integer
      operationId: get-users-user_id


```

dockerでprismサーバーを作ってみます

```docker-compose.yml
version: "3"
services:
  mock:
    image: stoplight/prism:3
    container_name: "mock-api"
    ports:
      - "14010:4010"
    command: mock -h 0.0.0.0 /openapi.yaml
    volumes:
      - ./openapi.yaml:/openapi.yaml
```

そしたら、

```
$ docker-compose up
```

あとは、モックサーバーにリクエストを投げてみると、期待するものと同じ型のレスポンスが返ってきます。

リクエスト：
```
http://localhost:14010/users/aaaaaa
```

レスポンス：
```
{"name":"string","description":"string","post_count":0}
```

良さそうですね、

# 終わりに

openapiの整備でクライアント側の型自動生成など他にもできることがあるのですが、入社してすぐアドベントカレンダー書くことになったので時間が足りませんでした。また別の機会に！
私個人がアドベントカレンダーに参加したきっかけ（2022年度版）

# アドベントカレンダーに参加したきっかけ

以下のカレンダーが盛り上がっているのを見たことがきっかけです。
内容というよりは、失敗や反省を公開して将来同じ失敗を繰り返さないようにようにする志に共感しました。
（皆さんもアドベントカレンダー参加のきっかけになったカレンダー教えて下さい！！）
[本番環境でやらかしちゃった人 Advent Calendar 2019](https://qiita.com/advent-calendar/2019/yarakashi-production)

# 過去参加したカレンダーとその反省

以下に参加しました！
アドベントカレンダーに参加してみたい！という一心で記事をひねりだしました。
目的と手段が逆な気もしますが、、アドベントカレンダーに参加するという意味ではモチベーションがボトルネックになる事もあると思うので、そういう点ではよかったと思います。投稿を継続する事が課題です。

### 2021年度
[アドベントカレンダー初参加する人を応援したい、アドベントカレンダーに参加したきっかけアドベントカレンダー Advent Calendar 2021 1日目](https://qiita.com/seigot/items/23f1dfef8338ed604495)
[IT資格取得をテーマに学びをシェアしよう！【PR】Udemy Advent Calendar 2021 3日目](https://qiita.com/seigot/items/3bd3fbf50c75a54c00d5)
[CTF(Capture The Flag) Advent Calendar 2021 17日目](https://qiita.com/seigot/items/5ef19abda295dfff6054)

### 2020年度
[ソフトウェアテストの小ネタ Advent Calendar 2020 5日目](https://qiita.com/seigot/items/f481445b9bd917e21f4a)
[Pythonその2 Advent Calendar 2020 17日目](https://qiita.com/seigot/items/a1a7b80ef6f4142ae602)
[Jetson Advent Calendar 2020 5日目](https://qiita.com/seigot/items/a6eaebccfd427bb315b4)
[Jetson Advent Calendar 2020 6日目](https://qiita.com/seigot/items/80bb409ff2de351ee9fa)

# 2022年度のカレンダー

以下に投稿予定です。

[Python Advent Calendar 2022 1日目](https://qiita.com/seigot/items/0b42a807217dbe636226)
[Python Advent Calendar 2022 2日目](https://qiita.com/seigot/items/e16e9d8f6fc04853855f)
[アドベントカレンダー初参加する人を応援したい、アドベントカレンダーに参加したきっかけ Advent Calendar 2022](https://qiita.com/advent-calendar/2022/sanka-kikkake)

# 感想
情報をオープンに共有する文化がこれからも継続されていくことを望みます。
アドベントカレンダー期間は投稿量が多くなる傾向があると思いますが、イベント期間後も継続して投稿していきたいです。

# 最後に

今年もクリスマスに向けて頑張っていきましょう！
Pythonでサイコロ作ってみた

## サイコロ
Pythonを使ってサイコロを作りたいと思います。

サイコロって大人になると触れる機会ってないですよね。
我が家では先日サイコロを実家で発見して娘と遊んでます。

## サイコロの定義
今回作るサイコロですが、1〜６までの整数の目が出るものとします。

早速コードを見てみましょう。

## 環境
```
macOS Ventura 13.0.1
Google Colaboratory
```

## コード

```python
import random
dice = random.randint(1,6)
print("サイコロの目は" + str(dice) +"です。")
```

これだけでサイコロは作れます。
まず初めに1行目ですが、
```python
import random
```
ここでランダムモジュールをインポートします。
Pythonには標準ライブラリという便利な機能をまとめたものが
たくさん提供されています。
例えば数学の計算などを行う、 mathモジュールや
日付と時刻を扱う、 datetimeモジュールなどです。
詳しくはPythonの公式ドキュメントを参照して下さい。

https://docs.python.org/3/library/index.html

2行目の
```python
dice = random.randint(1,6)
```
diceという変数にrandint関数を使用して1〜6までの数字を入れてます。

randint関数とは、 randint(a,b) のように書き、aからbまでの間のランダムな整数を出力するという意味です。

3行目
```python
print("サイコロの目は" + str(dice) +"です。")
```
print文で結果を出力しています。

サイコロは上記の通りですが、ここからはrandomモジュールでどんな動きを
しているのか見ていきたいと思います。

## 乱数
サイコロの動きの表現で使われるのが乱数です。
乱数とはランダムで適当な数字のことで、規則性のない数字のことです。

コードを実行して乱数を見てみましょう。

```python
import random
for i in range(7):
    print(random.random())
```

上記のコードを実行すると、
```
0.8646879206032319
0.36377500869900947
0.1498868135903768
0.8990674760488528
0.261696093620167
0.8415821457402218
0.8444125985859737
```
０〜１の間の小数が不規則に出力されたのが確認できました。
これが乱数です。

ここからrandint関数を使わずにサイコロに近づけていきます。
まず乱数を6倍して、0〜6未満の小数を作ります。

```python
import random
for i in range(7):
    print(random.random()*6)
```
出力結果
```
4.923039028651419
0.8848141251237571
2.8635824327216897
5.052957695964285
4.461501001097304
4.207258917169705
2.644129541013986
```

次に小数点を切り捨てるためにprint文をint型にします。

```python
import random
for i in range(7):
    print(int(random.random()*6))
```

出力結果
```
3
4
3
1
4
3
1
```

これでサイコロが完成したように見えますが、このままでは6は絶対に出てきません。
このままでは0〜6未満、つまり5以下なのです。

なので、最後に1を足して6まで出るようにします。

```python
import random
for i in range(7):
    print(int(random.random()*6)+1)
```

出力結果
```
1
6
3
1
4
5
1
```

これでrandint()関数を使わずにサイコロを作ることができました。

## まとめ
今回は標準モジュールでサイコロを作ってみました。
今後は複数のサイコロを振ってみて、丁半を予想するものを作ってみたりもいいかなって思ってます。
Write Code Every Dayを習慣化するための3つの方法

自分は未経験で株式会社ニジボックスに入社しました。
周りの先輩たちに早く追いつきたい！という思いからWrite Code Every Dayを始めることにしました。
2021年3月頃から始め、この記事を書いてる時点で650日ほど継続をしています。

2021年
![2021.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/516474/fd8923b6-a51a-1584-0ebe-d7ed58f7b091.png)
2022年
![2022.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/516474/9dfb972b-7bf3-7c71-9e3e-0fc30222d9c7.png)


この記事では、Write Code Every Dayを習慣化するために行ったことを3つ紹介します。

## Write Code Every Dayとは
Write Code Every Dayとは直訳すると毎日コードを書くことを意味しますが、元々はJohn Resig氏が始めた取り組みです。
John Resig氏のWrite Code Every Dayについての投稿にいくつかのルールが記されています。
引用元:

https://johnresig.com/blog/write-code-every-day/

>1.I must write code every day. I can write docs, or blog posts, or other things but it must be in addition to the code that I write.
>2.It must be useful code. No tweaking indentation, no code re-formatting, and if at all possible no refactoring. (All these things are permitted, but not as the exclusive work of the day.)
>3.All code must be written before midnight.
>4.The code must be Open Source and up on Github.

ざっくり訳すとこのようなルールになります。
1. 毎日コードを書かなければならない。ドキュメントやブログはその後にすること。
2. 有益なコードを書かなければならない。
3. 深夜までに書かなければならない。
4. オープンソースとしてGitHubにあげなければならない。

## 1.ルールを優しくする

習慣化のためにまずしたことが、このルールを設定し直すことです。

特にルール2「It must be useful code.（訳：有益なコードを書かなければならない。）」はハードルが高いなと感じました。
冒頭でも書いた通り、Write Code Every Dayを始めることにした理由は技術力向上のためです。なのでその時点でいいコードが書けなくても一旦良しとしました。

まずは継続することを目的とし、毎日コードを書いていく中でいいコードが書けるようになればokというスタンスです。
ただし「改行を追加するだけ」とか「console.logを追加するだけ」のような書いても自分にとって得るものがないようなものはNGとして線引きしていました。

次にルール4「The code must be Open Source and up on Github.（訳：オープンソースとしてGitHubにあげなければならない。）」についてですが、まずは継続を目的にしていましたのでプライベートリポジトリでもokとしました。

最終的にはこのようなルールとしました。

1. 毎日コードを書かなければならない。
2. どんなコードでも良い。ただし、できるだけ有益なコードを目指すこと
3. 深夜までに書かなければならない。
4. GitHubで管理すること。

## 2.公言することで強制力を働かせる

自分1人で進めているとどうしても「今日はやらなくてもいいかな」と思うことがあります。
そこで自分はチームのメンバーにWrite Code Every Dayをしていることを伝えることにしました。また、終業後にコードを書くための時間をカレンダー上で設定し、みんなが見える状態で取り組むことにしました。（カレンダーに設定することで、遅い時間にミーティングを設定されにくくなるという効果もありました。）

**ある週のカレンダー**
![スケジュール.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/516474/be30be52-9cb3-0d2c-b6af-0bd0c75bdc21.png)

公言することで「途中でやめる」＝「一緒に働く人に嘘をつく」となり、続けざるを得ない状況になります。
ちなみにWrite code Every Dayを始めてから半年くらい経つと
カレンダーに設定しなくてもコミットしないと気が済まないようになってきました。

## 3.作りたいものがない場合は競プロがオススメ

毎日コードを書くといっても何を書けばいいのか？と思う方もいらっしゃると思います。
そういう方には競技プログラミングをはじめとする学習サイトがオススメです。

コーディングするための題材が用意されるので、コードを書くことに集中できます。
また、アルゴリズムやデータ構造など普段の業務ではあまり意識しないことを学べるという点でも取り組んでよかったなと感じます。

参考までに利用したことのあるサイトを貼っておきます。

AtCoder

https://atcoder.jp/?lang=ja

LeetCode

https://leetcode.com/

AIZU ONLINE JUDGE

https://judge.u-aizu.ac.jp/onlinejudge/

## おわりに
Write Code Every Dayを始めてから作ったものはこんな感じです。（途中でやめたものもありますが）
- 競プロ
- 本の写経
- SNS
- 画像のスクレイピング
- ポートフォリオ
- マッチングアプリ
- todo管理
- 貯金箱アプリ
などなど

ここまで続けた感想としては、
始める前と比べて実装方法を考えることに慣れてきたかなと思います。あとはコードを読むことに対する抵抗も少なくなった気がします。
業務で使用しないような技術を触ったり、アプリケーションを0から設計したりもするので、以前よりできることの幅は広がったかなと思います。

以上、この記事がWrite Code Every Dayの取り組みに役立ててもらえたら幸いです。
Looker Studio（旧データポータル）を利用したダッシュボード作成の属人化を解消するための Tips

# はじめに
こんにちは。推薦基盤ブロックの宮本です。
この記事では [Looker Studio](https://support.google.com/looker-studio/answer/6283323?hl=JA)（旧データポータル）を利用したダッシュボード作成の属人化を解消するための Tips を紹介します。
 
# 背景
弊チームでは AB テストレポートや KPI の定常モニタリングとして Looker Studio を採用する機会が多いです。
Looker Studio を採用している理由としては BigQuery との親和性が高く、ビジネスチームへの展開が容易といった点などが挙げられます。
Looker Studio は簡単にダッシュボードを作成できるため、これまで開発のスピードを重視してチーム開発を意識せずに個人でサクッと作ってきました。
しかし、運用するダッシュボードが増えるにつれて自分以外のチームメンバーも開発にジョインするようになり、属人化防止に向けての取り組みが必要になってきました。

# やったこと
**Looker Studio 用に Google Cloud サービスアカウントを設定し、Looker Studio に代わってデータにアクセスできるようにしました。**

具体的には以下を実施しました。
- Looker Studio でサービスアカウントを利用できるように設定
- 実際に Looker Studio でサービスアカウントを利用してデータにアクセス

## Looker Studio でサービスアカウントを利用できるように設定
以下のドキュメントに従って設定しました。

https://support.google.com/looker-studio/answer/10835295#zippy=%2C%E3%81%93%E3%81%AE%E8%A8%98%E4%BA%8B%E3%81%AE%E5%86%85%E5%AE%B9

## 実際に Looker Studio でサービスアカウントを利用してデータにアクセス
データソースとして BigQuery を利用例として紹介します。
Looker Studio 内のデータソースの管理の画面の右上にある「**データの認証情報**」をクリックします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/616917/25d20556-db1b-dd25-f540-75471cc71c97.png)

すると以下の画面が出るので、「**サービスアカウント認証情報**」を選択 & 作成したサービスアカウントを入力し、更新して完了です。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/616917/abe6e86e-d770-5cc6-63ff-20b796ea9b4e.png)


# Tips
 ここではサービスアカウント利用するのあたっての Tips を2つ紹介します。
- **基本的にカスタムクエリを使用しない**
- **サービスアカウントが属しているプロジェクトに Looker Studio で参照するデータセットやテーブルを一元管理しておく**

理由は以下です。

* BigQuery と連携するたびにお金がかかるため、クエリが複雑になるとかなりのお金がかかる
* カスタムクエリ内で参照している他プロジェクトのデータセットやテーブルの参照権限をサービスアカウントに都度付与する必要がある

個人的には Looker Studio からアクセスするテーブルは分析用に整形されていることが望ましいと思っています。Looker Studio で必要なデータは整形されたデータだけであるため、不要な権限はできるだけ付与したくありません。また、サービスアカウントにどんどん権限付与していくと権限管理が難しくなるのを避けるためでもあります。



# 今後
Looker Studio 以外にも BigQuery のスケジュールクエリなど GCP の分析用サービスをにおいて、まだまだ個人のアカウントを利用しているケースが多いため、 サービスアカウントに切り替えて属人化を解消していきたいと思います。
GodotでLet'sアニメーション

# GodotでLet'sアニメーション
皆さんこんにちは～　FireDingoです。
今回はAnimationTreeを使ったGodot4でのAnimationTreeを使ったアニメーション方法を解説していきます。

:::note warn
GodotのバージョンはGodot4ベータ版を使用しています。
この記事を書いた時点での正式バージョンはGodot3.5ですが、もうすぐGodot4が実装されることが決まっています。
なのでより多くの人が読んで役に立つようあえてGodot4を使用しています。
ダウンロードはこちらからどうぞ.

[こちらがリンクです](https://downloads.tuxfamily.org/godotengine/4.0/beta7/)
:::

::: note alert
Godotには標準でAnimatedSprite2Dというノードがありますがここでは使いません。
:::

## 初めに
::: note info
こちらからキャラクターのアニメーションに使う素材として下のリンクからItch.ioで**Adventure.zip**をダウンロードしてください。
:::
https://rvros.itch.io/animated-pixel-hero

![tempsnip.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2850578/5f896110-29c3-ab93-be4c-ebc56e7c7cc9.png)

ダウンロードしたら解凍しておいて下さい。

## 本編

### プロジェクトの準備
素材をItch.ioからダウンロードして解凍したら早速プロジェクトを作っていきます。
レンダラーはどちらでも大丈夫です。とりあえず作成して編集を押して作成しましょう。
![2.PNG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2850578/b57f5de0-ec44-28ac-6b21-80bdc2200919.png)
新しいプロジェクトを作成したら解凍したアセットのファイルをドラッグ＆ドロップします。
するとファイルは下の画像の様になると思います。
![4.PNG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2850578/99574289-3125-9aed-8021-870f644b5638.png)

そしたら適当に2Dノードを作成してシーンを作成してください。
シーンを作成したら早速ファイルを開き、
**res://Adventurer/adventurer-Sheet.png**のパスにスプライトシートの画像があるのでメイン画面にドラッグ&ドロップしてください。
![6.PNG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2850578/c57fb741-53e7-edb9-e7bf-37491513782a.png)
すると…
![5.PNG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2850578/8f4434b7-81cd-e8cd-4bc6-d02030e9046e.png)
このようにスプライトシートの本来表示したくないフレームも表示されています。
1フレームずつ表示させるにはSprite2Dノードの設定をします。
Sprite2DノードをクリックしてインスペクターからAnimationと書かれている部分で設定をしていきます。
このAnimationという部分ではSprite2Dを使ってほかのアニメーション用ノードなどと接続できます。
簡単にそれぞれのパラメータを説明すると、
* HFrames　→　Horizontalつまり水平に何フレームあるかの設定
* VFrames　→ Verticleつまり縦方向に何フレームあるかの設定
* Frame → 現在のフレーム(ここをいじればフレームを変えられる)
![8.PNG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2850578/67cc1784-cf18-2f69-c63c-6df5b71eb819.png)
早速設定していきましょう。
このスプライトシートは横に7、縦方向に11フレームあるのでHframeは7、Vframeは11に設定します。
![7.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2850578/2fd23a5d-7cd2-6a25-587f-542a38291e8c.png)
インスペクターからそれぞれ7と11を入力してください。
![10.PNG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2850578/3e9392f5-3ed1-f8e2-de09-007304b4c7ab.png)
入力し終わったら設定はいったん終了です。試しにFrameの値を減らしたり増やしたりしてみてください。
下のGIFの様にアニメーションしているのが分かると思います。

![8unjr-6yv0a.gif](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2850578/da89521e-ae6f-ca55-099c-4b2b53b8becb.gif)

### 修正01

いったんアニメーションの基礎設定が終わったところで作り続ける前に直します。
よく見るとこのキャラクター、**ドット絵になっていません！！**
ドット絵ではなくちょっとぼやけています、なので早急に直しましょう。
Godot3では再インポートという方法を使ってドット絵をしっかり表示させなおしていましたが、Godot4からはより簡単に直すことができるようになっています。
CanvasItemのTextureの部分からFilterとRepeatをNearestに変更して下さい。
![12.PNG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2850578/8b47391c-03b9-4400-e598-83823ba3c498.png)
すると上の画像のように一瞬でドット絵にしっかり描写されたことが確認できます。



![主人公動く.gif](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2850578/7b5da60d-ebcd-0c55-28e3-1a336f0594b3.gif)
新卒エンジニアが中途エンジニアのピアメンターをやってみた 

# はじめに
新卒1年目の私が、中途エンジニアの方のピアメンターを行いました。ピアメンターというのは、年次や技術力が近いもの同士で行うメンタリングです。

本記事は、そのピアメンター活動のまとめです。

- メンター初心者が何を考えて指導に当たったか
- 技術力が近いもの同士でも効果はあるのか
- メンティーはどのような点を難しいと感じているのか

あたりは参考になるのではないかなと思います。

来年は新卒の後輩方も入社されるので、その準備という意味合いもあります。

# 事前調査
今回のメンターに当たって、念頭に置いていた考え方・方法です。
以下の本を参考にしました。

- [自分の頭で考えて動く部下の育て方 上司1年生の教科書](https://www.amazon.co.jp/dp/4905073618)

- [エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング](https://www.amazon.co.jp/dp/4774196053/)

あくまで現時点での仮説なので、これがベストではないと思います。今後メンターを行なっていく中で、より洗練させるための叩き台、といった位置付けです。

### メンターの役割
- 「メンティーの課題を解決する」ことではなく、「"メンティーが自立的に課題解決する状態"に導く｣こと
- 自立的に課題解決する状態とは？ => [「弊社で活躍している人」](https://blog.linkbal.co.jp/5323/)から抜粋
  - 姿勢:他責でなく自責
  - コミュニケーション:自分の意見に対して判断を求める
  - ロジカル・クリティカルシンキング:前提条件が正しいか確認
  - スピリット:思考・コミュニケーション効率

### メンターがやるべきこと: 1. 課題を分解する
- 解けないパズルを、「ひとりでも」解けるパズルに変換する
  - 「ひとりでも」解ける -> 自己効力感
- SMARTのフレームワーク
  - 特にSAR
    - Specific （具体的に）
    - Achievable （達成可能な形で）
    - Relevant （関連性を示す）
  - これを意識してタスクを渡す

### メンターがやるべきこと: 2. 仮説思考を促す
- 自立的な問題解決 = 仮説思考
  - レベル1: （指示があるまで何もしない）
  - レベル2: ｢何をすればいいですか？｣
  - レベル3: ｢こうしようと思うんですけどどうですか？｣
    - -> レベル3になってもらう
- ソクラテスの問答法(産婆術)
  - 「相手の質問や答えに対し、新しい情報を加味して、新たに質問する」ことを繰り返す
    - メンターはあえて正解を教えない
  - 自分で答えに辿り着く -> 自己効力感

# 実際にやってみた
## 背景：レベル感やタスク内容
- お互いのレベル
    - メンター（筆者）：新卒1年目のWebエンジニア。業務内のコードは大まかに理解してきたが、基礎的な知識はキャッチアップ中の段階。
    - メンティー：中途入社数ヶ月目のWebエンジニア。ジュニアレベルでの入社。ソフトウェア工学のバックグラウンドと、少人数でのサービス開発の経験がある。チーム開発の経験に乏しい。
- 扱ったタスク
    - 自社サービス内の、期間限定のキャンペーン機能。
    - メンティーにとっては入社してから最も大きなタスク
- 期間
  - 全体で3週間ほど
    - 仕様の擦り合わせや、設計、既存コードの理解に1週間
    - 実装・レビュー・テストに2週間

## メンターとしてサポートした内容
- 設計全般
    - 企画・仕様の理解
    - DB、バックエンド、フロントエンド
    - どのモデルやコンポーネントが使えそうかのアドバイス
- テスト・レビュー・リリースなどのフロー決め
  - レビューやテストの順序をどうするか
  - リリース順序をどうするか（いくつかのブランチに分けて開発をしていました）
  - ディレクターサイドに伝達すること

細かい実装自体はある程度1人でこなせそうだったため、設計と、チームでの動き方などのサポートを重点的に行いました。

## 感想

### メンティーからのフィードバック
#### 開発する上で
- 勉強になったところ
  - 企画の意図や仕様の擦り合わせのやり方
- 苦労したところ
  - バックエンドの設計
  - スケジュールの見積もり
  - フロントエンド全般
#### メンティーとして
- 助かったところ
  - 必要があったら手伝ってくれるという安心感
  - 適度な進捗確認（頻繁すぎず、放置しすぎず）
  - 設計の段階で、使うコントローラやメソッドまで確認できた
    - デメリット・起こりうるエラーを指摘
  - 「〜さんはどうしますか？」という質問
    - 「まず自分の考えをまとめ、それについて意見を求める」という習慣がついた
- もっとこうして欲しかったところ（メンターへの改善要望）
  - より上位の人に相談すべき高度な問題も2人で悩んでしまっていた

### メンター（筆者）の振り返り
#### Good
全体としては上手くいった部分が多かったように思います。

> 設計の段階で、使うコントローラやメソッドまで確認できた

メンティーがまだサービス全体のコードに慣れていなかったので、設計の段階から、必要に応じてソースの中身まで一緒に読むようにしていました。

最初のうちは、コード全体の構造を掴めていないので、トップダウン・抽象的に考えるよりも、ボトムアップ・実装などの具体例を使う方が、理解が進むのかもしれません。
実は深く意識していた部分ではなかったので、良い気づきになりました。

> 「まず自分の考えをまとめ、それについて意見を求める」という習慣がついた

仮説思考の部分は、今回最も強く意識していた部分だったので、この言葉を聞けて安心しました。

個人的な考えですが、「〜さんならどうしますか？」という聞き方は、相手との関係性によっては「詰められている」と受け取られる場合があります。今回は上手くいきましたが、これは僕の伝え方が良かったというよりは、むしろメンティーに助けられた部分が大きい印象です。今後ここをどうクリアするかは課題の1つです。

#### Bad
根本的な問題点も浮上しました。

> より上位の人に相談すべき高度な問題も2人で悩んでしまっていた

私自身の開発スキル不足が露呈した形です。メンター（筆者）のスキルが不足しているために判断に迷う問題は、一旦切り分け、上司などより詳しい方に相談すべきでした。特に「決め」の問題に関しては、早めにヘルプを求めるべきだったなと感じています。

当たり前ですが、知らないことは教えられません。まずはエンジニアとして十分なスキルを身につけることも、メンターの責務だなと感じました。


# まとめ
他者をサポートする・導くというのは、難しい役回りである一方で、メンター・メンティー双方に得るものがあります。また、1人のエンジニアの方が1日でも早く戦力になってくれるのは、チーム全体としてもメリットです。

来年は新卒の後輩方も入社されるので、さらに試行錯誤を重ね、メンターに関する知見を貯めていきたいです。
学校教育とICT（40代普通の教員の思うこと）

はじめに
　私の本職である学校教育について書いていきたいと思う。これを読んでいる教員は多くないかもしれないが、皆昔は生徒だったと考えるとほぼ全員が関係者とも言える。さらにその印象・評価は各個人や見方によって実に様々に分かれる。学校とは不思議な場所である。これから実状などを書いていこうと思うが、全国には実に様々な学校がある。従って、基本的には「私の務める学校（地方の私立中・高）では」と、という前提で読んで欲しい。

　現状
　　コロナ禍でGIGAスクール構想が前倒しで実施された、というようなニュースを目にされたことがあると思う。学校の状況はこの2年で一気に様変わりした。私の学校では、教員・生徒ともにiPadを支給（教員はpro!!）、全校にwifiを張り巡らせ、教室にはプロジェクターまたは大型スクリーンを設置した。現在のレベルでは十分すぎる設備であると考える。では、肝心の授業での活用、生徒の利用状況はどうだろう。ほとんど使えていない、という報道が多いような気がするが、実際には思った以上に素早く対応し、活用している教員も多い。実際は以前から研究していたが環境がなく実施できなかったが、やっとできる！という意識の高い先生方も多い。当然ここにもグラデーションがあり、これは想像通りであるが、年齢が高くなればなるほど現状維持を好む傾向にある。しかし、実際には報道よりも積極的に前向きに捉えている先生方が多い（本校では）ということは伝えておきたい。

問題点
　最も大きな問題点は、ではICTを導入しましょう！という話になったとき、残念ながら声の大きな先生の意見が強ということだ。会議担当メンバーはどうしても年配の先生方が多くなり、結果「今までこれでやれたんだから変える必要ないだろう！」となりがちであることである。どんなに整備しても良いプロダクトを作っても採用してもらえないのである。

今回感じたこと
　ICTなど新しいこと、技術に関して若い方と年配の方（ここではあえて分かりやすくデジタルネイティブと非ネイティブとさせてもらう）の違いを考えてみたい。現状維持を望む非ネイティブは、導入したくない、ICT嫌い、という人ばかりではない。ただ、導入するなら今まと全く同じことができて、自分にとって全く同じ感覚で扱え、かつ効率は上がるならいいよ。という感覚が強いようだ。自転車は乗れるが、自動車には乗ったことがない人がいたとしよう。例えるならば、時速６０kmまで出る自転車で今までと同じように程よい運動になり、高齢者も子供も乗れる、尚且つ安全に移動できるものならば使うけど、自動車は免許がいるし動かし方も違うから嫌だ。という感じだ。ネイティブは運転を覚えると今まで行けなかったところへ行ける、時間が短縮できる。ではそこで、その時間で新しいことができる、と考える人が多いというところか。
　これが現状である。嘆いていても仕方がない、結局導入してもらうにはほぼ自発的に何も新しいことをしなくて良いプロダクトが必要となってくる。AIなどを使って自動でやってくれるものでないと大きな変革は起こせなさそうなので、まだ少し時間がかかりそうだ。

学校教育について
　少し外れてきたので教育の話に戻したい。様々なデータを見ていると、これからの社会ではICTを活用できる人材へと育てなくてはならない、と切に思うが、教員には危機感がない。やはり学校というものが社会とは隔絶しているせいだと思う。子供達を社会へ出すための訓練として学校があるはずなのに、実際はかなり特殊な状況の場所だと言わざるを得ない。大変な状況を肌で感じている個人事業主の方や経営者の方の話と、教員仲間との話には大きすぎるギャップがある。そんな世の中に送り出していかなくてはならないのに何十年と変わらぬ価値観で構成された今の教育、偏差値重視で良いのだろうかと疑問を持たないのか、と言いたくなるが、そもそも隔絶されていると思えば仕方ないことかとも思う。多くの教員は多忙すぎてそんなことを考える余裕がないということも大きいと思うが。
　私はもっと学校を社会へ開き、教員を社会へ繋げたい。現状でも教員は一生懸命努力をしているが、残念ながら子供のためになっていないことも多いのではないかと思う。教員は広い視野を持ち、子供たちが出ていく社会がどのように変化をしていくのか、想像しながら適切な教育を行っていかなくてはならない。変化の早い今の時代、残念ながら「これまでの慣例」「先輩たちのやってきたこと」といったものが通用しないことも多くなるのは当然である。教員1人ひとりが常に社会とつながりを持ち、勉強し続けなくてはならない。そのために何かできないか、という思いでG'sへ入学した。幸い素晴らしいチューターの方、同期に恵まれ忙しいながら充実した日々を過ごしている。G’sのメンバーのように、自分の意志で新しいことにチャレンジしてみよう！というマインドセットを持った生徒に育てたい！それをサポートするのが学校教育でありたい。その実現のために、何ができるのか、why Meを続けてみたいと思う。
FlowRowを利用したGridViewのようなUIについて

### はじめに
FlowLayoutとはGoogleのAccompanistが提供している中の一つのライブラリです。
画面幅に対して折り返していくようなUIを提供しています。`FlowRow`と`FlowColumn`というComposableが提供されております。この記事では水平方向に折り返していく`FlowRow`を使ったGirdViewのようなUIを表現してみたいと思います。

### やりたいこと
ComposeでGridView的な表現をしたい場合、`LazyVerticalGrid`がありますが、リストの長さが可変の場合や、スクロールの中でリスト表示以外のUIを差し込みたい場合、`LazyVerticalGrid`だと簡単ではなさそうだなと思い、`FlowRow`をつかってみました。イメージとしては以下のような２列の可変長リストとそれ以外のUIが混ざったようなスクロールできるUIを実装してみたいと思います。
![sankou2.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/218011/9dda523b-e973-4550-cfe1-0f5019ac1c17.png)

### 導入
導入自体は非常に簡単でbuild.gradleに以下を指定するだけです。
$flowVersionは現在の最新は0.28.0のようです。
```gradle
repositories {
    mavenCentral()
}

implementation "com.google.accompanist:accompanist-flowlayout:$flowVersion"
```

### 実装
FlowRowを使った実装です。
```kotlin
@Composable
fun FlowSample() {
    FlowRow(
        modifier = Modifier
            .fillMaxSize()
            .padding(horizontal = 18.dp),
        mainAxisSize = SizeMode.Wrap,
        mainAxisSpacing = 7.dp,
        crossAxisAlignment = FlowCrossAxisAlignment.Start,
        crossAxisSpacing = 7.dp,
    ) {
        for (i in 0..9) {
            Card(i)
        }
    }
}
```
FlowRowのスコープ内でforループ分、子要素を追加します。サンプルなので固定ですがViewModelなどからリストを受け取るといったイメージです。
ちなみに`mainAxisSpacing`は主軸のスペース長、`crossAxisSpacing`は横軸のスペース長です。
`crossAxisAlignment`はAlignmentでStartを指定することで折り返さない場合、画面左に子のUIが配置されます。ちなみにCardの部分の実装は固定のサイズをもった適当なUIです。

全体的な実装も至ってシンプルです。`Column`に`verticalScroll`を指定し、このスコープ内でFlowRowやUIを実装していくのみです。
```kotlin
    Column(
        modifier = Modifier
            .fillMaxWidth()
            .verticalScroll(scrollState)
        horizontalAlignment = Alignment.CenterHorizontally,
    ){
        Spacer(modifier = Modifier.height(56.dp))
        FlowSample()
        Spacer(modifier = Modifier.height(10.dp))
        SomeMiddleContent()
        Spacer(modifier = Modifier.height(10.dp))
        FlowSample()
        Spacer(modifier = Modifier.height(80.dp))
    }
```
上記のサンプルは以下のような見た目になります。
![flowsample.gif](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/218011/90586d60-7580-a035-4db8-1d74d0b98ef8.gif)

要素である`Card()`の部分が固定長なのもあり、解像度によっては折り返してしまい１列や３列の見た目になる可能性もあるため、実際には端末のwidthを考慮して幅を決定していく必要などがあります。

### まとめ
FrowRowを使うことで若干複雑なコンテンツがあるGridView的な表現が比較的簡単に実現できました。
ただ、自分が`LazyVerticalGrid`などの知見のあまりないため、もしかするともっと最適なやりかたがあるかもしれません。

### 参考
https://google.github.io/accompanist/flowlayout/

https://stackoverflow.com/questions/61022452/any-ideas-on-the-list-with-fit-wrap-width-on-item-in-jetpack-compose
Ubuntuのキーボード設定

# 【キーボード】JIS/US変換と日本語/英語変換をする方法
確認環境:Ubuntu 20.04

:::note info
動作確認環境はUbuntu20.04ですが、似た手順でUbuntu22.04にも対応しています。
キーボード設定において、22.04では`setxkbmap`のコマンド実行が必要なく、Mozcのインストールと`dpkg-reconfigure`だけでUSキーボードと日本語入力の切り替えができます。詳しくは`Ubuntu22.04`>`Settings`>`Keyboard`を参照ください。入力ソースやキーボードショートカットはここでカスタムできます。
:::
この方法を使えば、
<font color="red">JISキーボードで日本語/英語変換</font>
<font color="red">USキーボードで日本語/英語変換</font>
が毎回少しのコマンド入力と少しのキーボード操作でできるようになります。つまり、日本人が使うすべてのキーボード設定に対応できるということです。
- まず日本語入力用の入力ソース(Mozc)をインストールする。
```
sudo apt install ibus-mozc
sudo reboot
```
- Ubuntuで設定

まず、日本語入力と英語入力が使えるようにする。
右上の記号郡を押して`Settings` > `Region&Language` > `Input Source`の`＋`から`Japanese(Mozc)`と`English(US)`を`Add`で追加する。それ以外は削除する。

次に、キーボードの設定をする。
```
sudo dpkg-reconfigure keyboard-configuration
```
`Generic 105-key PC (intl.)` > `English(US)` > `English(US)` > `The default for the keyboard layout` > `No compose key` > `Yes` と選択する。

:::note info
`Generic 105-key PC (intl.)`の代わりにHHKBなどの特殊なキーボード専用のキーボードレイアウトを選択できる。しかし、私はHHKBを使用していますが、Generic 105-key PC (intl.)で問題なく使えています。
:::

- 英語入力と日本語入力を切り替えるためのショートカットキーを設定する。

`Settings` > `Keyboard Shortcuts` > `Typing` > `Switch to next input source`で`Shift+Super+Space(任意のキー)`を設定する。
SuperキーはWindowsではWindowsキー、MacではCommandキーにあたる。

- 日本語英語変換のためのキーボード操作とJIS/USキーボードの変更コマンド

Ubuntuを立ち上げただけではUSキーボードかつ英語入力のみのままであり、右上が`A🔻`になっている。日本語入力するためにまずJISキーボードに変更する。
以下の`setxkbmap jp`を端末で実行後、ショートカットキーを押して日本語の`あ`に設定し、右上の`en🔻`を押して`Japanese(Mozc)`を選択し`あ🔻`なるように切り替える。もしくはJISキーボードで`半角/全角キー`、USキーボードで`~'キー`を押すことで`あ🔻`なるように切り替える。
この手順を踏むとJISキーボードになり、ショートカットキーで日本語入力と英語入力を切り替えられるようになる。
```
setxkbmap jp
```
JISキーボードからUSキーボードに変更する。ショートカットキーによる日本語英語変換は維持される。

:::note info
日本語入力ができないときは`setxkbmap jp`でJISキーボードに戻して日本語入力する。
:::
```
setxkbmap us
```

# まとめ
1. 日本語入力のためのJapanese(Mozc)をダウンロード
2. 各種設定(Input source,Keyboard configuration,Shortcut key)
3. Ubuntuを立ち上げた毎に行う操作
<font color="red">JISキーボードで日本語英語変換がしたい場合</font>
`setxkbmap jp`でJISキーボードにした後キーボード操作をして日本語英語変換ができるようにする。
<font color="red">USキーボードで日本語英語変換がしたい場合</font>
`setxkbmap jp`でJISキーボードにした後キーボード操作をして日本語英語変換ができるようにし、`setxkbmap us`でUSキーボードにする。

[Ubuntu個人的おすすめセッティングはこちら](https://qiita.com/RENOX/items/84a7d774d88256082cb1)
※この切り替え方法は私の経験に基づいています。


---
<font color="yellowgreen">**QiitaLink**</font>
<font color="black">**Designed by RENOX**</font>
【エンジニアに転職して3ヶ月経過】なんもできないけど、バリューを出すために奮起したことをまとめてみる

# はじめに
こんにちは、mayuと申します。

私は2022年9月に、未経験から自社開発企業にフロントエンドエンジニアとして入社しました。

まだ3ヶ月しか経っていないですが、1~2ヶ月のプチ暗黒期を突破して、良いフィードバックも増えてきたので、ここらで一つの区切りとして書き連ねてみたいと思います！

せっかくなので、これから**エンジニアとしてのキャリアをスタートする方に向けて、参考になれればと嬉しい**のでアドバイスベースで書いてみたいと思います😸

# これからエンジニアになる方に向けてアドバイス（自戒の念を込めて）
## 1.　技術以外のことでバリューが発揮できることを探す
「未経験からエンジニアという専門職に就く」というのは言うまでもなく当たり前なのですが、最初のうちはマジでまっっったく使い物になりません...🙏🙏🙏😭

寧ろわからないことだらけで教えてもらうことしかできなくて、新卒ならまだしも中途入社となると「**何の役にも立てない自分**」にぶち当たるので自己肯定感が爆下がりするんですよね😂

そんなときにおすすめなのが、「**技術以外のところで自分が価値を発揮できそうなことを探す**」です！

例えば私の場合は、
- 新入社員の受け入れ態勢が整っていなかったのでオンボーディングの準備を主導させてもらったり、
- テストのタスクを自分から掴み取りに行くことで、メンバーが他のタスクに時間を割くことができたので喜ばれたり、

といったことで貢献することができ、徐々に自己肯定感を取り戻せていけたかな、と思っています。

モチロン、企業側が未経験転職者に一番期待することは**技術力をつけて貢献してれること**なので、そればっかりに時間を割くのは避けるべきですが、**少しでも良いので自分ができることをやっておくことで精神安定にもなりますし、存在をアピールできるのではないか**と思います😊

## 2.　定期的なフィードバックを求める
私は他者にフィードバックを求めることってちょっと怖いなと思っていましたが、今では「**もっと早くもらっておけば良かったな**」と思っています。

やはり**会社によって「この会社で良しとされる行動」とか「この会社で評価される人物」とかって全が然違ってくる**んですよねぇ。。😅

私の場合は、前職との社内文化が違い過ぎたので、最初は「ルールのわからないゲームをしているような」感じでなかなか会社に馴染むことができず苦労しました。

2ヶ月経ったくらいにフィードバックをもらう機会があったのですが、このときに「**私に期待すること**」や「**どういう行動が求められているか**」が明確になったので、ようやく心の霧が晴れたような気がしました🌈

徐々にルールを知っていくというよりかは、先にルールを聞いておく方が、ゲームに例えるならば「攻略しやすい」と思うので、フィードバックをもらえるように働きかけてみると良いと思います！

## 3.　自己表現、アウトプットを積極的にする
これは私の一番驚いた気付きですが、受け入れ側は「**新参者がどういう人なのかを知りたがっている・知ろうとしてくれている**」んですよね。

自分が思ったことや考えたこと・学んだことを積極的に発信すると、**周りの方々は手を差し伸べやすくなる**し、**新参者の成長度合いも把握できるので安心できる**んだと思います。

私は最初の2ヶ月は社風にも馴染めず、技術力が上がっている実感も得られずで、メンタルがかなり低空飛行だったのもあってなかなか心の内を明かすことができずにいました。きっと周りの方も心配していたのではないかと思っています。😅🙏

エンジニアはチームで開発するので人と人との関係性ってめちゃくちゃ大事だなと実感しています（前職は営業部事務をしていましたが、その時より会話が多いです）。

**自己開示するようになってから距離が縮まった実感がある**ので、自分から発信していくように心掛けると良いと思います！

## 4.　週一で1on1の時間をもらう / 外部メンターも持つ
有難いことに、弊社では上長やメンバーと毎週30分の1on1の時間を設けていただいていました。

チームメンバーがどういう人なのか知れたり、何気ないことも質問できたり、時には悩みを相談できたりもするので新参者にとっては心の支えになると思います。

また、**外部メンターを持つのも安心材料になる**のでとてもおすすめです！

私はプライベートでエンジニアのコミュニティに参加していたのもあって、同時期にエンジニアに転職した人や1年前に転職した人の繋がりに恵まれていたので、**ただ話を聞いてもらったり、近況を伝え合ったりすることがかなり励みになっていました。**

特に入社して1~2ヶ月は精神的に辛かった時期ですが、**双方向から支えてもらえたのでなんとかなったな**と思っています😇

## 5.　なんとなくでコード書かない
（これ当たり前すぎて書いたら怒られるかもしれないけど、）**コードをなんとなくで書かないのとっても大事**です😇滝汗

特に1~2ヶ月目とかは「なんでこう書いたんですか？」と聞かれた時に、「言われてみれば考えてなかったな」と気づくことが多々ありました。

なので最近気をつけているのは、「なぜこう書くのか」という**理由を自分のなかで自問自答する**ことです。

理由を考えると**ちゃんと調べよう**と思うし、自分の中で腹落ちするので**手触り感のある学び**になっているようにも思います。

## 6.　プルリクは完璧じゃなくても良い
私は独学の頃からチームで開発したことがなかったので、「**プルリクって完璧じゃないといけないものなんだ**」と思っていました。

でも自分の中で完璧を目指してしまうと、**永遠に出せない焦り**が出てきたり、**「進んでる感」が得られないので精神的に良くない**ということを学びました😇

なので最近では、**できてるところまで出してコメントで質問してみたり、進捗を報告する意味でも活用できている**ので、良い傾向にあるのではないかと思っています。

未経験者はきっとプルリクのハードルを高く感じていると思ったので、こういう使い方もあるんだよという紹介の意味も込めて書いてみました。

# おわりに
私は全くの未経験から縁あって今の会社でエンジニアとしてのキャリアをスタートさせることができました。
先輩方も優しくて、たくさん質問させていただいていて、恵まれた環境で働けていることにとても感謝しています。

エンジニアに転向してまだたったの3ヶ月。最近ようやく今までの知識の点と点が繋がってきた実感がでてきたかと思えば、同時にまだなんもできないと思ったりで、「はたして一人前になれる日が来るのだろうか...。」と毎日思いますが、ひとつひとつ積み上げていって、胸を張ってエンジニアと名乗れるように、そして会社やチームの役に立てるように頑張りたいと思います！

最後まで読んでいただきありがとうございました😊✨