OmniAICreator/Qiita-1.07M huggingface dataset:
私的Goで作るアプリのコード設計

## 前置き

- あくまで、個人でやっていてやりやすい私的の設計である。仕事においては、業務の内容/フェーズに合ったコード設計を採用するべし
- CleanArchitectureを意識してはいるが、あくまで意識しているだけであるため原理からは異なっている可能性がある （原理主義者様からの意見/指摘は大歓迎です）

## 対象コード

- Discord上から対象のホストに対してpprofをとって結果をS3に上げるBot
- 将来的にはDBをSQLiteではなく別サーバーにしたい
- 将来的にはWebAPIとしても提供したい

https://gitlab.com/RenonT1805/kyuuteiprofiler

## 前提に置く思想

- アプリケーションのビジネスロジックを副作用から守り、テストしやすい状態を維持する
- インフラ（DBや、DiscordBotの基盤そのもの）を置換可能な物とし、移植性を高める

CleanArchitectureに関する議論でよく「DBやフレームワークなんてそうそう変える物じゃないんだから、インフラの抽象化は過剰である」という話が上がるが、今回のアプリは将来的にWebAPIとしても提供したいし、DBもSQLiteから他のDBに移行したいのでインフラの抽象化は必要である。

## ディレクトリ構成解説

```
.
├── application
├── cmd
├── config
├── contexts
├── controllers
│   ├── params
│   └── validators
├── db
├── handlers
├── infrastructures
├── models
├── presenters
├── repositories
└── services
```

アプリケーションのエントリポイントから近い順に解説していく

### cmd

- アプリケーションのエントリポイント
- アプリケーション全体の初期化もここで行う
    - DBオブジェクトの生成
    - DiscordBotの初期化
    - Webサーバーの立ち上げ

### config

- アプリケーションの設定を管理
- 環境変数の値取得とかもここ

### contexts

- アプリ内で使用する共通の値などを管理する (DiscordBotのSessionやWebAPIのcontextなど)
- これが参照されるのはcontrollerまでで、以降のアプリ部分では使用されない

### handlers

- アプリケーションへの生リクエストを受け取り、パラメータへの変換および各機能へのハンドリングを行う
- DiscordBotなら、"DiscordHandler"、WebAPIなら"WebAPIHandler"のように動作基盤によって複数のハンドラーを作成する
    - 動作基盤によってパラメータの渡し方が異なるので、複数作成する必要がある (例: WebAPIならパラメータを渡す時はパスパラメータやBodyだが、DiscordBotはOptionからパラメータを取得する)
- controllers/pramsが提供するパラメータの変換関数を用いてパラメータを呼び出すコントローラーに合った形に変換する

### controllers

- アプリケーションの各機能を呼び出す
    - パラメータに応じて呼び出す順序や条件などを制御する
- 動作基盤の差を吸収して、アプリケーションに純粋なパラメータを渡す
    - DiscordBot用のコントローラーやWebAPI用のコントローラーを作成する
- パラメータのバリデーションを行う
- applicationの具体に依存する

正直controllerからもcontextの依存を抜いて移植可能な状態にするかどうか迷っている。
しかし、流石にHandlerの責務が重くなりすぎる気がする。

### presenters

- アプリケーションの結果を動作基盤に基づいて変換しレスポンスを作成する
    - WebAPIならHTMLを返し、DiscordBotなら返信を作成する

### application (アプリケーション内部に閉じている)

- アプリのビジネスロジック
    - Domainにおけるロジック
- これ単体では副作用が発生しないように、repositories/servicesよりも外の世界には依存しない
- controllerには具体を提供する (usecaseで抽象化されない)

### models (アプリケーション内部に閉じている)

- アプリ内で使用する値の定義
    - 必ずしもDBのテーブルと１対１になる必要はなく、あくまでアプリケーションの内部で使用する値の定義をおこなう
    - Domainにおけるモデル

### repositories/services (アプリケーション内部に閉じている)

- アプリケーション内で使用する外部への操作のinterface
    - DB操作や、API呼び出し等
- アプリケーションはinterfaceに依存することで、外の世界への依存を避けることができる
- repositoriesは値の永続化系、servicesはそれ以外のものを詰め込んでいる

### infrastructures

- アプリケーション内で使用する外部への操作の具体的実装
- repositoriesとservicesで区別していないが、膨らんできたら分割するかも

## 上記コード設計の工夫

- 上記の中で、application、models、repositories/servicesはアプリケーション内部の世界に閉じており、外部への依存は存在しない。
そのため、動作基盤やDBを変更する際はhandler、controllers、presenters、infrastructuresのみを変更すればよく、アプリケーションのビジネスロジックそのものは同じ動作が保証される。
- controllersはapplicationの具体に依存している(usecaseで抽象化されていない)が、これはビジネスロジックが置換されることについてアプリケーション内で差を吸収する必要がないと判断したためである (ビジネスロジックが変わるならそれはもう全部変えた方がいいため)

## おわり

アプリを作っていると抽象化中毒になってきてどんどん抽象化しまくりたくなってくる。
実際は無限に抽象化すればいいわけではなく、ある程度具体に依存しなければアプリケーションの意味が希薄化してしまう（OS等のプラットフォームならまだいいが、業務アプリでは避けた方がいい）上に、とにかく書く量が増えてきて大変になる。
開発プロジェクトはギャルマインドで乗り切ろ🤟💫

## ご挨拶
本記事は[リンクアンドモチベーション Advent Calendar 2023](https://qiita.com/advent-calendar/2023/lmi)の6日目です。

こんにちは、市原と申します。
開発をしていて見通しが立たないことって多いですよね。
今までやったことのある開発をすることの方が少なくて、大体は初めてのこと、初めてのメンバー、初めてのシチュエーションだと思います。
ある種の不確実性を抱えた仕事がほとんどではないでしょうか。

そんな見通しが立たない状況を偉大にも日々開拓してきた先人がいます。
<br>
**ギャルです。**
<br>

ギャルはいつの世も変化を当然のように受け入れ、適応し、さらに大きな変化を生み出してきました。
その上ギャルは楽しそうです。

プロジェクト乗り越えるためにギャルマインドを憑依させればうまくいくんじゃね？と思っちゃったので、
**日常のプロジェクトで使えるギャルマインド3選**を紹介していきます🫰👗✨

※この記事は筆者のイマジナリーギャルに基づいて書かれており、実在のギャルとはあまり関係がありません

# はじまりはじまり
あるところに、1つの開発チームがありました。
開発チームでは既存プロダクトの新しい機能を作っており、
3人のメンバーABC、1人のプロダクトオーナー（PO）、1人のギャルからなるチームでした。

## ケース1：お前の仕事だろ？
プロジェクトは意気揚々と走り始めました。
みんなでタスクを進めてやっていくぞという時…
<br>
朝会にて
A「このタスクの進捗ってどうなってる？」
B「あとちょっとで終わるんで大丈夫っす！」
<br>

次の日
A  「このタスクの進捗ってどうなってる？流石に今日進んでないとまずい」
B  「いやーちょっと詰まってるっすけど大丈夫っす！」
A  「何やってんだよ〜頑張れよ〜〜お前の仕事だろ〜」
<br>
ギャル「え、ちょっと待って」
　　　「うちら同じプロジェクトじゃん？」
　　　「普通にうちBの仕事興味あるわ、教えてくんない？」
　　　「プロダクトオーナーさんの仕事でこの前Bのタスクの仕様っぽい考慮してなかった？」
　　　「2人一緒にやったら即解決じゃん」
<br>
B  「ギャル…ありがとう。実はここの仕様が理解できなくて…でもなんだか相談できなくて…」
<br>
### ギャルマインド：ギャルにはセクショナリズムがない
Aが「何やってんだよ〜頑張れよ〜〜お前の仕事だろ〜」と言った時点で確認せず、Bに任せて次の次の日に終わらずに炎上、みたいなことってあると思います。
こういう時って「なんでもっと早く気づけなかったんだ」となるものなんですが、
人と人、役割と役割で区切るのではなく、
一つのチームとしてやった方が課題発見と解決ってスムーズにいきますよね。
その点ギャルは友達の友達まで友達なので、教えて教えて〜ってすることでチームのコミュニケーションが活発になります🙆‍♀️

## ケース2：そのぐらいわかってるだろ？
<br>
タスクも回るようになってきた頃

B　「このタスクってなんでしたっけ？」
PO 「あーこれはこうやってやればOKだから」
B　「いやそうじゃなくて目的なんなんでしたっけ？」
PO 「いやこの機能から考えたらわかるでしょ」
B 　「…」
PO 「あー大丈夫、これやっときゃいいから！」
<br>
ギャル「ちょま！」
　　　「うちもわかんないし教えてよ〜」
　　　「うちらが何作ってるかわかったほうがきっとPOもハピハピだよ〜」
　　　「頑張って考えられるようになっからさ〜」
<br>
PO 「ごめん…」
　　「目的がこうだからこうでしょ、だからこういう機能が必要なのよ」
B 「なるほど、ありがとうございます」
　「だったらこんな感じで実現してもいいんじゃないでしょうか？こっちの方が開発もリーズナブルだしお客さんにも良さそうです」
PO＆ギャル「😮。天才です。」
<br>
### ギャルマインド：ギャルは正直
なんでこのタスクやってるんだろう？と疑問に思うことってあるし、それをそのまま表出せずに終わってしまうこともあると思います。
別に自分がわかんなくたってPOがわかってるしいいや〜となっちゃいがちなんですが、
バックグラウンドの違う職種が同じプロジェクトで働くことはいろんな方向から思考の光を当てることができる点でとっても有用なのです。
ギャルは正直なのでそういうところを見逃しません。
いや自分がわかんなきゃ意味ないっしょくらいのマインドです。
そうして新しい提案が生まれることもとっても良くあることなので、ピュアに聞いていきたいですね🙈

## ケース３：今の自分たち失敗だらけ…
<br>
プロジェクトも佳境になってきたある日の振り返り

A　 「今週はこれとこれとこれがうまくいかなかったな…」
B　 「そうですね…」
C　 「来週はそれとそれをネクストアクションにしましょうか…」
全員「はあ…毎週毎週うまくいかないな…」
<br>
ギャル「いや暗くね？」
　　　「めっちゃいいことしてるはずなのにめっちゃ暗くね？」
　　　「改善活動まじ尊くね？学んだことで昨日のうちらより強くなるくね？最強じゃね？」
　　　「うちら最強！」
<br>
A＆B＆C「ほっ」
<br>
### ギャルマインド：ギャルは引きずらない
プロジェクトが佳境になってくると向き合い疲れというか、真面目な人ほど暗い気持ちになることがあると思います。
そこで前を向けたらいいんですが、考えすぎると逆にどんどんダメな点ばっかり見えてきちゃいますよね。
最後までプロジェクトを走り切るためには、こういう時にあんまり考えすぎずにポジティブな気持ちをみんなの前で発言することが大事だったりします。
ギャルはポジティブどころか自己肯定感をさらにあげてくれます。
ノリに全振りしましょう🤟

## おわり
こんな感じのことみんなが言ってたら楽しそう
つまりギャルは最強🤷‍♀️💅
GCP PCNE合格記

この記事は[BeeX Advent Calendar 2023](https://qiita.com/advent-calendar/2023/beex)の9日目の記事です。

# はじめに
この度GCP認定のGoogle Cloud Certified - Professional Cloud Network Engineerを受験してきましたので、勉強した内容と受験した感想を書いておきます。
多分年内最後の合格記になるはず...？

# 前提
* Google CloudはSkill Boostなどで少し触った程度
* AZ-900/AZ-104/AZ-700/AZ-305/AZ-204/DP-900/AZ-500/DP-203は取得済み
* AWS認定は全て取っています(詳細は[こちら](https://qiita.com/handy-dd18/items/d21d914bf1c475d777f2))
    * [SAP on AWS認定](https://qiita.com/handy-dd18/items/18e8a856906f97bbb964)も取ってます
* AWSの実務経験あり(一部Azureも)
* Google Cloud認定は6つ目になります。

# 学習内容
今回は以下の順番で勉強を進めました。

* ①[公式模擬問題](https://cloud.google.com/learn/certification/cloud-network-engineer?hl=ja)
* ②練習問題([Udemy](https://www.udemy.com/share/1094PY3@uIiphy6SNcb0bUnhYP7kXAanLOq6aeiO1zdWvn3p-DuI4gk4rf-UPYbsgJXLnoCx/)

## 公式模擬問題
まずはPCD試験の時と同じように公式の[模擬問題](https://cloud.google.com/learn/certification/cloud-network-engineer?hl=ja)を解くようにしました。
AWSのANS認定に合格するぐらいの知識は事前に合ったので、無勉強状態で3分の1ぐらいは正答してました。
あとはGoogle Cloudのサービス特有の設定内容などの知識が足りていなかったので、問題の解説に貼っている参考の公式ドキュメントのページはすべて確認して、どのような観点でどんな内容が出題されているのかを確認しました。

Google CloudはAWSやAzureとはまた違ったネットワーク構成をしているので、その違いを理解するのが少し時間がかかりましたが、BGPやルーティング等の基礎的な知識があれば基本的な動きはイメージできました。

## 練習問題
模擬問題のあとはUdemyで公開されている[練習問題](https://www.udemy.com/share/1094PY3@uIiphy6SNcb0bUnhYP7kXAanLOq6aeiO1zdWvn3p-DuI4gk4rf-UPYbsgJXLnoCx/)を購入して勉強しました。

30問×5セットあったので、試験前日と当日で3セット解いて解説を読み込むところまで実施しました。
Udemyで検索して一番上に出た評価が高いコースを選びましたが、正直そこまで内容は良いとは言えませんでした。
基本的に問題文が文字足らずなので、記載されていない内容を読み取れないとそもそも回答ができない問題もあり、解説も公式のドキュメントリンクを張っている問題が少なったので、わざわざ調べる必要がありました。

公式の模擬問題の方が役に立った気がします。

もし同じ試験を受験される方は別のUdemyコースのほうが良いかと思います。

# 受験した感想
前回と同じくまずは全問回答することを優先して、回答が不安な問題にはフラグつけて、残り時間が5分前になるまで時間をかけて解きました。
勉強不足だったのもありそうですが、思ったよりは難しかったです。

あと試験内容ではないのですが、
自分は基本テストセンターで受験するようにしているのですが、Google Cloudだけペンとホワイトボードが渡されないので、書きながら進められないのは毎回苦労してます。
AWSやAzureだと10問ごとにかかった時間をホワイトボードに書き込んで、大体の解き終わる時間を出して解くスピードを調整しているのですが、Google Cloudでは書けないので常に時間を気にして解くようにしてます。

# 受験結果
無事に合格することができました。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/440403/653c5b59-0deb-a28a-3a18-566d7cfeaef8.png)


# おわりに
今回この試験を受験したのは、今年の7月に日本語に対応したことが理由です。
Google Cloudの日本語試験は取り終わったので、残りはタイミング見て英語でチャレンジしてみようとは思いますが、英語力ゴミなので合格できる気はしません。。
日本語試験の提供開始を待ちわびてます。
https://qiita.com/yutakon/items/0c11922b63a494ac7b3f

この記事がどなたかの参考になれば幸いです。
エンジニアのjob interviewについて簡単なまとめ

## 前提条件
そもそもUSなどの海外就職・転職では、必須条件として、コンピュータサイエンスなどの関連性のある学位が含まれていることが一般的である。そして、日本のエンジニア採用よりもジョブ型の採用という面が強い。
そのため、採用面接（job interview）には、最低限の専門性があるか確かめる役割がある。
また、日本の採用におけるSPIなどの能力テストに近い部分もある。
技術に関する単純な内容だけを質問して、その質問に的確かつスピーディに回答できるか。
コミュニケーションや単純作業など、実際にチームに入った時に活躍できそうな人材の素養を持っているかどうか。
そんな側面もあるだろう。


※参考(YouTube 新R25チャンネル：「アメリカの転職では、年齢は関係ない」厚切りジェイソンが“日本とアメリカのビジネスパーソンの違い“を教えてくれました)

https://youtu.be/XgtJRLCS8-s?si=ema8jvKpe1WsAc07

## インタビューで気をつけること
- 丁寧な英語で話す
- カジュアルになり過ぎないようにする
- 自分の経験を話に絡めてアピールする
- インタビュアーに気配りする
- 分からなくても動じない、インタビュアーのヘルプを活用して解く
- 回答プロセスやその説明などコミュニケーションに重きをおく

## インタビューの種類の例

### interview questions
### coding
### whiteboard
### system design interview

## 参考動画

https://youtu.be/-LVmKNvflnY?si=oEeP1vNzvvTYlahL
監査のお話

# 概要
自分の業務内容の中で監査対応の割合が高くなったので
脳内整理も兼ねてここにざっくりと記します(ざっくりね)。
今回はJ-SOXについて。

# J-SOXとは？
超シンプルに言うと、上場企業が守らなければならない制度(法律)です。

アメリカにはSOX法という
「企業の会計不正行為や不透明な決算報告などを防止する」
ために定められた法律があり、J-SOXはそれの日本版にあたります。

もう少し砕くと
会社の持っているお金、取り扱っているお金が
・不正に使われたり
・水増しして申告されたり
することを防ぐために
①不正行為ができないようにシステム上/業務上のルールを作って
②そのルール通りにシステムが動いている/業務が行われている
ことをその会社自身がチェックし、その結果を財務局へ報告する
　**内部統制報告制度**　です。

また、内部統制にもいくつか種類があるのですが
ここからは、自分が関わっている**IT統制**についてのお話です。

# IT統制について
IT統制は主に
・IT全般統制（ITGC）
・IT業務処理統制（ITAC）
があります。
※ITELCというのもありますが今回は省きます


### ITGC（IT General Control）
おおまかに言うと
業務に利用しているシステムが、内部/外部問わず不正利用されないための
①仕様/ルールが作られている
②仕様/ルール通りに運用されている
ことをチェックします。


### ITAC（IT Application Control）
おおまかに言うと
自動化された業務プロセスが、正確に処理/記録されるための
①仕様/ルールが作られている
②仕様/ルール通りに運用されている
ことをチェックします。

ITGC/ITACのどちらも、RCM（Risk Control Matrix）というもので評価します。

# RCMって何？
なんとなくで伝えると、評価対象のシステム/業務プロセスについて
①想定されるリスクを考える
②そのリスクの対処法を考える（内部統制手続）
③対処するためのルールを決める（整備）
④ルール通りに運用する（運用）
を記載し、①～④を評価するためのツール（資料）です。

RCMの中身については「RCM フォーマット」とかでググれば
いくらでも出てくるので気になる方は調べてみてください。

# 結局J-SOXってどういうこと？
つまり、上場企業としてJ-SOX法を遵守するために
①内部統制をしっかりやる
②内部統制について評価し、内部統制報告書を作成する
③内部統制報告書を監査人（監査法人等）に見てもらい、監査証明をもらう
④内部統制報告書と監査証明を財務局へ提出する
というプロセスが必要なのです。

他にも
・子会社も併せて統制/評価しないといけない
・業界によっては他にも監査がある（特に金融とか）
とか色々ありますが、それはまた別のお話。。。

~~（3点セットの話とかもあるけど書きません。気になる人は調べてみてください）~~
Notion ページ閲覧・編集状況を可視化する方法

## 概要

Notionでページの閲覧状況を可視化する方法を簡単にまとめる。

## 方法

1. 閲覧状況を可視化したいページを開く。
1. 右上の「時計アイコン」をクリックする。

    ![今日のお品書き.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/306417/d8dd7991-d4cb-7001-fc4f-1a2bd3f3c718.png)

1. 「Analytics」タブをクリックする。

    ![Menubar_と_今日のお品書き.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/306417/1ac174b2-d9f5-20ae-f0c0-414e6190032d.png)

1. 閲覧・編集状況が可視化される。

    ![今日のお品書き.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/306417/c15e0d99-dcdf-675f-c226-105e66d6418d.png)

## 参考文献

https://appllio.com/news/2023-01-27-36881-notion-page-analytics
未経験から転職して2年間で、濃密な実務経験をした話

これは「Happiness Chain Advent Calendar 2023」の1日目の記事です。
https://adventar.org/calendars/9414/

こんにちは。プログラミングスクール[Happiness Chain](https://happiness-chain.com/)でメンターをしているryoです。

今回は、僕が未経験から転職してからの2年間に、とても濃密な実務経験をしてきましたので、時系列を追って話していければと思います。

# エンジニア1ヶ月目
僕は未経験から、SaaSの自社開発企業に転職しました。フェーズとしては10->100ですが、エンジニアの人数が少なく、チームを作っている段階でした。その時点では、ビジネスサイドから上がってきた新機能やエラーを、エンジニアリーダーがメンバーに割り振る形で、進めていました。

入社当初、僕は全く別の職種からの転職なので、どのように仕事を進めるのか想像もつかず不安がありましたが、複数回のMTGにて十分に説明いただいたので、不安が解消され無事に最初のタスクを終えることができました。

入社から2週間後、大規模な新機能開発を僕1人に任せてもらえることになりました。

# エンジニア2~6ヶ月目
エンジニア2ヶ月目の時に、副業を始めました。副業を始めた経緯としては、転職活動をしていた際に0->1のスタートアップ企業を受けていて、面談の際に「流石に1人目のエンジニアに未経験の人を採用するのは怖いので、落ち着いたらまた話しましょう」ということで、再度面談をした際に副業で働くこととなりました。

副業先は、正社員のリードエンジニアが1人と僕の2人で、僕はフロントエンドをサポートする形になりました。フロントエンドは独学の際に、重点的に勉強していて自信はあったので、まずは1ページをお試しで任されましたが、そちらを短期間で作成できたので、その後全てのページを任されるようになりました。

ただこの時、本業の方も新機能開発のタスクを進めていて、土日も含めて毎日のように稼働していましたが、楽しんでいる自分もいました。

そして6ヶ月目の時に、自分が開発していた新機能をリリースすることができました。この開発は今でも印象に残っています。
1つ目は、1PRで7000行の変更を行なった点で、commitを汚くしてしまったことと、レビュワーに負担をかけてしまったことで、非常に申し訳なかったと思います。
2つ目に、フロントエンドがReactなのですが、クラスコンポーネントで記載されていて、かなりロジックが複雑で、変更を加えるのが難しいため、ファンクショナルコンポーネントに修正してから、ロジックを修正したのが、とても大変でしたし、とても勉強になりました。

# エンジニア7ヶ月目〜1年
新機能をリリースした後は、中小規模の新機能開発を進めつつ、一部新機能のマネジメントも任されるようになりました。

ビジネスから上がってきた要件から、タスクを切って割り振り、週次で進捗を確認し、必要に応じてヘルプに入る等の作業をするようになりました。

また、副業に関しては稼働時間が確保できず、この期間はお休みしてました。

# エンジニア1年~1年8ヶ月目
この時点でエンジニアの人数も多くなり、開発スピードを上げていくために、各人の役割を明確に分けるようにチームを作る流れになりました。僕は新機能のマネジメントを順調にこなしていたので、PdMとしてやっていくことになりました。

僕はPdMに関しては、知見がなかったので、カンファレンスに行ったり、本を読んで体系的に学習しました。当初はただ各プロジェクト全体の進捗を管理するものだと思ってましたが、もっと上流から考えて管理するものだということが分かり、これが完遂できたらサービスをより成長させられると思い、とても面白さを感じました。

しかし実際にPdMとして働いてみると、学習した内容と異なる部分が多いため教科書通りに進めていくのが難しく、またビジネスサイドのPdMの認識が異なっており、PdMとして役割を全うすることができませんでした。

また、副業に関しては徐々に再開していたのですが、正社員のエンジニアの方がやめてしまい、僕の方でリリース最終段階に向けてシステム全般の調整を一通り行なっていました。
そんな時に、副業の方から正社員のオファーをいただきました。

この時、僕は正直PdMを続けていく自信がなかったので、転職しようと決意しました。


# エンジニア1年7ヶ月目~2年
副業の方に正社員として転職して、正社員は僕だけなのでシステム周り全てを僕が見ることになり、様々な経験をしてきました。経験した内容は以下の通りです。

- インフラをAWSからVercel、Renderへの移行
- staging、demo環境の作成
- PapertrailとSentryの導入
- エラーがあった際のslack通知を実現
- メール送信の際とバウンスした際のslack通知を実現
- パッチ処理実現のためのサーバー構築
- バックエンドにてformatterを導入
- バックエンドにてviewのテストを導入
- バックエンドの一部テーブル設計の変更(正規化やカラム名の変更)
- フロントエンドにてテストを導入(jest、cypress)
- バックエンド、フロントエンドのrefactor
- 数百社ほどの提携先企業サービスページ量産のためのインフラ整備
- slackからnotionへの自動タスク化
- Google Analyticsの導入
- ChatGPTの導入
- ドキュメント整備

これらの経験は、前職の経験があったからこそ、完遂できたと思いますし、
実際にこういった経験は貴重だと思いますので、転職してよかったと思ってます。

こちらのサービスは僕がエンジニア歴2年になるタイミングにてリリースされ、大きなエラーはなく無事にサービスが続いています。

# 最後に
いかがだったでしょうか？
自分的にこの2年間が、エンジニアとして1番成長できた期間だったと思います。
転職前までは、2年目でスタートアップ企業のシステム全般を見るようになるとは想像もしていませんでした。
これだけの経験が積ませてくれた2つの企業の皆様には大変感謝しております。
積読している本とその傾向

この記事は 積読 Advent Calendar 2023 の15日目の記事になります。

https://adventar.org/calendars/8637




エンジニア積読消化 Advent Calendar 2023 も参加しています。
こちらのAdvent Calendarでは１日目に 「限りある時間の使い方」の書籍を読んだ感想を書きました！ 良ければこちらも見てください！

https://qiita.com/newta/items/d336da4b66f85f95c40b


上記のカレンダーは積読消化する目的のためのカレンダーなので、
今日の記事については、自分の積読の傾向について考察してみたいと思います。

もしこの機会に積読を消化したいと思ったエンジニアの方が居ましたら、こちらのAdvent Calendarに是非参加していただきたいです！

https://qiita.com/advent-calendar/2023/unread-books


# 私の属性


- エンジニア
- エンジニアリングマネージャ
- 採用マーケティング
- 技術広報

エンジニアリングマネージャとして長く働いていました。
採用をより強化するために数ヶ月前に採用マーケティングのチームにジョインしました。


# 最近の課題感

本を購入するモチベーションは自分の課題感が強い領域の知識を得るために買うのではないかなと思います。

最近の私の関心の強い課題は２つ

１． 直近はチームが大きくなり、ミドルマネジメント的な観点の力が必要と感じていた。
２． 技術発信をエンジニアとしてのオプションの活動ではなく、メインで行うのは初めて。発信に関する新しい知識を積極的に取り入れる必要があると考えていた。


# 積読リスト

ざっと分類してリスト化
半分くらい読んでいるものもあるが、読むのが止まっているものは積読に入れました

### 技術 
- 世界一流エンジニア思考法
- GitLabに学ぶ 世界最先端のリモート組織の作り方
- プロダクトマネージャになりたい人のための本
- AWSのしくみと技術がしっかりわかる教科書

### 組織マネジメント
- チームを動かす すごい仕組み
- 目標管理入門
- 組織管理入門
- みんなのフィードバック大全
- プロジェクト・シン・エヴァンゲリオン
- HOLACRACY
- ファイブウェイポジショニング

### ベーススキル
- 解像度を上げる
- 頭のいい人が話す前に考えていること
- 構造読解力
- 思考力の地図
- 反応しない練習
- 話し方伝え方ほど人生を左右する武器はない！
- ネガティブ思考こそ最高のスキル

### リーダーシップ
- 一緒に居たいと思われるリーダーになる。
- ドラッカー・スクールのセルフマネジメント教室

### アジャイル
- アジャイルプラクティスガイドブック


### 休み
- WHITE SPACE
- 心療内科医が教える本当の休み方




# 最近読んだ本のリスト

### 積読アドベントカレンダーで読みました
- 限りある時間の使い方  
- NLPの原理と道具

https://qiita.com/advent-calendar/2023/unread-books

### エンジニア採用文脈
- DevRel - エンジニアフレンドリーになるための3C
- コミュニティマーケティング
- ファンベースな人たち

### 技術
- 人が増えても早くならない
- レガシーコードとどう付き合うか
- 進化的アーキテクチャ

### ベーススキル
- 考える技術・書く技術
- 小さく分けて考える
- メタ思考トレーニング

### その他
- 100話で心折れるスタートアップ


# 積読リストと読了リストから感じたこと

課題感が強いものや今の仕事にすぐに活きるものから読んでいるように感じる。
エンジニアリングマネージャ色が強いので、直鉄的なコードの話の技術はあまり読んでない。

ベーススキルの足りなさの課題感が強い。本質的なスキルなので、新しいものも古いものも色々と良い本があるので積むのがはかどる。

マネジメント系の本は全部読む前に飽きてしまう。
半分くらい読んで止まっている本が多い。
本で言いたいことが前半に書かれているのかも知れない？

エヴァは趣味
100話で〜はXで毎日読んでいた



# 積読を減らすための行動の検討

集計してみたら思ったより本は読んでいた。
最近は色々と忙しく全く読めていない感覚だったので、忙しさの山を越えて通常ペースをつかめればもっと積読を減らせそう。

そもそも興味の範囲が広いので、積読減らすことが結構難しそう。
あと、分厚かったり、読み応えがあるものが多い。

１つの興味カテゴリの本を読まなければ、次の本を買わないというルールを試してみてもいいかも。
１つの本を読み切るまで次の本を買わないというルールを作ったことがあるが、課題感の温度が変化するので、手持ちの本を読むモチベーションに繋がらず、全く続かなかった失敗がある。


# まとめ

積読を整理してみるのは面白かった。
自分が本を読み終わると次の本に目が行ってしまって、全然読めていない感覚だったが、ちゃんと自分のやったことの実績を見れてよかった。

実績の確認データと知識の定着を目指して要点をまとめるブログとかをしてみたいと思いました。


おすすめの積読消化ルールなどがあったら教えてください！
【STYLY】渋谷駅テンプレート開発時の位置ズレ測定について

これは [【STYLY】 Advent Calendar 2023](https://adventar.org/calendars/9034) の1日目の作品の解説記事です。

# 東京渋谷駅テンプレートの開発について

こんにちは、 **せぎゅ** です！

私は2022年まで **STYLY Studio** の開発リーダーを務めており、その間に **都市テンプレート機能** の開発にも関わりました。

今回のアドベントカレンダーで採用された **東京渋谷駅テンプレートの開発** は、数多くの技術的な課題があり、とくに困難で印象深いプロジェクトでした。

`東京渋谷駅テンプレート` の開発中、動作確認のために何度も渋谷駅を訪れ、位置ズレの検証を行ったのを今でも覚えています…

その当時に撮影した現地の写真をこちらに掲載します！

|QFRONT|渋谷モディ|タワーレコード渋谷店|
|---|---|---|
| <img width="200" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/221845/93bc0ec8-1e09-e6bc-78b5-832f12de6f56.png" /> | <img width="200" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/221845/0b53c640-c5b0-bbc1-6a83-ad6f627ffd80.png" /> | <img width="200" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/221845/0a96115f-fad8-edfb-d27c-faf9f0e19dec.png" /> |


|渋谷Tビル|KN渋谷1ビル|渋谷センタービル|サンルイビル|
|---|---|---|---|
| <img width="200" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/221845/df5c1157-d158-efa0-36b8-058894b6d1e1.png" /> | <img width="200" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/221845/99ffd340-e330-4f72-d309-ee64fa8adf5d.png" /> | <img width="200" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/221845/b4007ca0-a585-a7f6-3eac-3a6d8d583d36.png" /> | <img width="200" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/221845/5d079784-8803-220f-78a2-aff0c530e3b7.png" /> |

これらの写真は、CGで作成された建造物を赤い線で表示し、実際のビル群との位置ズレを測定するために撮影されました。ARによる位置合わせの精度を評価するための重要な作業でした！


# 作品紹介

`東京渋谷駅テンプレート` 開発時の位置ズレ測定シーンを再現したものがこちらです！

https://gallery.styly.cc/scene/cb475cf3-2f51-491d-be49-0d302ae0c754

今回のアドベントカレンダーの1日目の作品として、このシーンを応募しました。ぜひ現地で体験してみてください！



# 宣伝
Psychic VR LabではUnityエンジニア・サーバーサイドエンジニアを募集しています！！ご応募お待ちしています！！

https://www.wantedly.com/projects/1360135

https://www.wantedly.com/projects/1360123
IBM i アーキテクチャー：主記憶域管理（メインメモリ管理）：ページングとページ不在

IBM i のメインメモリ管理について説明します。

■IBM i のメインメモリ管理
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1011394/93aa9f06-2fce-c37d-7f7a-9e196c5b90bc.png)

基本的な動作
・通常、メインメモリにロードされ実行中のプログラムは、プログラムコード全てがメインメモリ上にロードされている訳ではありません。
・プログラムがメインメモリ上に存在しないページに記憶されている命令を実行しようとした場合、ページ不在 となります。

・このとき、もしメインメモリ上の全てのページが使用中であった場合、不在ページをメインメモリ上にコピーするために（ページ・インするために）上書きしてもよいページを決定します。このときLRU（Least Recently Used）アルゴリズムで上書きするメインメモリ上のページを決定します。
上書きされる対象となったページがストレージから読み込まれて以降、変更されているならば不在ページを読み込む前にストレージに書き出しを行います。この処理を ページング と呼びます。
・ページ不在となると、実行中のタスクは制御権を喪失し、他のタスクが実行を開始します。実行優先順位に基づき、ページインしたいページがメインメモリ上にコピー完了したか、一定時間経過後（タイムスライス値経過後）、制御権を失ったタスクが再び制御権を獲得しプログラム実行が再開（継続）されます。

・LRUアルゴリズムでは、最も使用頻度の高いページは常にメインメモリ上にあるのでパフォーマンスがよくなります。ですが、メインメモリのサイズに比較して過剰な大量タスクがページを取り合うと、比較的新しいメモリ・ページが上書きされ始め、制御を受け取ったタスクはそれ自身ですぐページ不在になってしまう現象が発生します。この活動中のタスクによって新しく使われたページの循環的な取り合いを スラッシング と呼びます。
・スラッシングは本来のプログラム実行に消費するべきCPU,ディスクをページイン・ページアウト処理のために占有してしまいパフォーマンス悪化をもたらします。
・スラッシングの根本的な解決策はメインメモリサイズを処理負荷に応じて適正に追加することだと思われますが、IBM i OSのアクティビティーレベル（活動レベル）を適正に調整することでも改善できる場合があります。IBM i OSのシステム値QPFRADJ（パフォーマンス自動調整）を1, 2, 3のいずれかにすることでアクテビティーレベルを適正に調整することが出来ます。一般にQPFRADJシステム値は2または3にしておくのがよいと思います。

※QPFRADJシステム値による調整は小刻みに行われ、それはWRKSYSSTS画面のプールの箇所を観察するとよくわかります。プールサイズや最大活動(数)が刻々変化（自動調整）するので機会があれば観察してみてください。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1011394/3eef8dc3-3372-f4cc-7e68-1d81bfd4faed.png)

※参考: パフォーマンス・システム値: 記憶域プールと活動レベルの自動調整 https://www.ibm.com/docs/ja/i/7.5?topic=svpo-performance-system-values-automatically-adjust-memory-pools-activity-levels

------

■IBM i のクラス *CLSオブジェクト のPURGEパラメーターとページング動作

IBM i にはクラス *CLS というオブジェクトがあります。クラスはすべてのジョブ（プログラム）で使用されます。以下はIBM i OSデフォルト提供のクラス *CLSオブジェクトの一つ(QSYS/QBATCH クラスオブジェクト)でバッチジョブのデフォルトです。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1011394/f9c8d1b7-c64b-bf60-fde8-e7aa1042f83d.png)

前の章で説明した、プログラムからの要求に基づいてストレージから必要ページをメモリに移送するページング方式を 要求ページング と呼びます。
・上のクラス *CLS の除去可能（PURGE)パラメーターで *NO が指定されたクラスを使用するタスク（ジョブ）においては、ページングが実行されるのは要求ページングが発生したときだけになります。
バッチジョブでは例えばユーザー端末（5250端末ほか）からの応答待ちは殆ど無く長時間実行されるので要求ページング以外は実行させたくない、ということになります。
・ところでもし*CLSクラス・オブジェクトのPURGEパラメーターが *YESの場合、要求ページング以外にもタスク（ジョブ）が長時間の待ち（ロング・ウェイト）または *CLSのタイム・スライス値に達した場合、異なるページング方式が実行されます。
ロング・ウェイトの代表例は以下です。
　- 5250端末でのユーザーからの入力待ち
　- メッセージキュー *MSGQ へのメッセージ到着待ち
　- プログラムやその他オブジェクトのロック待ち、データベースレコードのロック待ち
　- プリンターなど低速な装置へのデータ送信
※ストレージへの入出力待ちはロング・ウェイトには含まれません。
・ロングウェイトが発生すると、タスクのページは直ちに開放され、他のタスクで利用可能となります。ロング・ウェイトが完了したとき（例：5250端末でユーザーが実行キーを押したとき）、プログラムの再活化に必要なタスクのページが一度にメインメモリにコピーされます。この操作を スワッピング と呼びます。

・PURGE *YES は対話型ジョブなどロング・ウェイトの発生が予想されるジョブに適している、とも言えます。実際、対話型ジョブでデフォルト使用される *CLSクラスオブジェクト QINTERでは、PURGE *YESが指定されています。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1011394/a2c065bf-cbce-89bf-9c21-fe0eb7c91ca8.png)
MRTKを使ったアプリをHololens2にデプロイすると片目しか表示されない問題

# 現象
Azure Remote RenderingとMRTKを使ったアプリをHololens2にデプロイしたところ、片目（左目）しかモデルが表示されなくなった。

# 原因調査
### 1. Render Modeを変更
Unity Editorの上タブにある「File」をクリックして、「**Build Settings**」を選択。
![MicrosoftTeams-image (6).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1812049/8cefc40d-9b40-ef52-225d-69e133ba8b5c.png)

左下にある「**Player Settings**」を選択。
![MicrosoftTeams-image (7).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1812049/3664da0f-bc45-4af3-22a9-f57648cdbfe6.png)

サイドバーから「XR Plug-in Management」内の「**Open XR**」を選択
![MicrosoftTeams-image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1812049/b8187087-8575-37b9-8b1a-9fb0663789ca.png)

Render Modeを「<font color='red'>**Multi-pass**</font>」に変更
![MicrosoftTeams-image (3).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1812049/43a31ab1-d5a8-447d-b1e9-dd7267fce149.png)

...
しかし現象は治らず。
原因はここではない模様

### 2. Scene内のMain Cameraの設定を修正（解決）
MRTKを導入した際に作成される「MixedRalityPlayspace」オブジェクト内の「**Main Camera**」を選択
![MicrosoftTeams-image (2).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1812049/91ce99b5-b432-755b-0281-86e054ba390b.png)

右側に表示されるinspectorの中に「**Target Eye**」を発見。
デフォルトで「Left」となってて気づかなかった。。。ここが原因な気がする。
「<font color='red'>**Both**</font>」に変更。
![MicrosoftTeams-image (1).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1812049/00efd32e-7d5e-c1de-a8be-b97285f8ea09.png)

...
無事両目で3Dオブジェクトが表示されました。
MRTKを導入した際は、もしかしたらLeftになってる可能性が高いので、Bothになっているかチェックするように！
Marp for VScodeでテーマが適用できない場合（結論：githubのRAW URLを使う）

おはようございます。

Marp for VScodeで、自作したテーマが認識されないと、困っていると思います。
でも、有志の人が公開しているテーマは認識していませんか？

-   ローカルの自作テーマは適用できない
-   有志のテーマは適用できる（github）

ということは、github上に作成した、自作したテーマも認識できるということ。

## 結論 ：githubに自作テーマを置きましょう

この記事を見ているということは、皆さん自分のgithubアカウントを持っていると思います（）
有志作成のテーマも、githubのRAW URLで取得していると思います。[RAW URLについて](https://docs.github.com/ja/enterprise-cloud@latest/repositories/working-with-files/using-files/viewing-a-file)
ということは…

### 自分のテーマもgithubのRAW URLで取得できるようにすれば、良いということ。

こんなところです。

githubへのアップロード方法やRAW URLの作成方法などは、自分で調べてください。
この記事までたどり着けたあなたなら、調べれると思います。

では、良い睡眠を
コンポーネントベースの開発時代においてCSS設計は本当に必要なのか？考えてみた

ReactやVue.jsなどのコンポーネントベースの開発が広く普及する中、CSS設計を学ぶことに時間を使うのはどれだけのメリットがあるのか？と思いました。

そこで改めて「CSS設計」責務を考えながら考察してみたいと思います。

:::note info
今からCSS設計を学ぼうとしている方の判断材料になれば幸いです！
:::

## 結論：「CSS設計」を学ぶのは後回しにした方が良い
今からCSS設計を学ぶなら後回しにしたほうが良いと考えます！

:::note warn
誤解のないように補足しておきますが、**学ぶ意味はあります**。
ただ、自身の状況に合わせて優先度は落とした方が良い場合もあるということです。
:::

では、なぜ**後回しにした方が良いのか**について書いていきます。

## 「CSS設計」を学ぶのは後回しにした方が良い理由
理由は、ReactやVue.jsでの開発が主流になったためです。

:::note info
ReactやVue.jsのコンポーネントベース開発がこれまでCSS設計で担っていた部分をより良い形で実現してくれるようになりました。
:::

必ずしも必要な知識ではなくなってきたと考えています。
では「CSS設計」の責務にはなんだったのか？について考えてみます。

### CSS設計の責務はなんだったのか？
CSS設計の大きな責務は2つだと考えています。
- メンテナンス性を向上させること
- チーム開発を円滑にできるようにすること

さらに細かくいうと…
- 冗長的なコードをなくすこと
- 可読性を担保すること
- スタイルの記述方法に一貫性を持たせること
- 変更による影響範囲を最小限にすること
のようなことをCSS設計によって実現することでチーム開発を円滑にしていくものだと考えています。

:::note info
CSS設計は命名ルールや考え方によって**変更のしやすさ・コードの見やすさ**を高める目的のために導入されてきたと思います!
:::

### なぜ「CSS設計」が必要だったのか？
WEBアプリケーションが大きく、複雑化してくに伴いそれまでのCSS管理方法では限界が来たからだと考えています。

:::note warn
それはCSSの特徴である**グローバルスコープ**、**カスケード**、**詳細度**が影響していると言えます。
:::

https://developer.mozilla.org/ja/docs/Glossary/Global_scope

https://developer.mozilla.org/ja/docs/Learn/CSS/Building_blocks/Cascade_and_inheritance

CSSの記述量が増えれば増えるほどCSSの特徴が開発の効率を下げ、時には表示崩れなどの不具合を引き起こす原因となりました…。

上記の特徴からWebアプリケーション開発が大規模かつ複雑なインターフェースをチームで構築する時非効率にならざるおえない状況がやってきたのだと考えています。

## CSS設計の責務はコンポーネントベースの開発がその一端を担ってくれた
CSSの特徴である干渉し合う仕組み、グローバルスコープを回避してくれたのが**コンポーネントベースの設計**です。

CSSの影響範囲をコンポーネント内に閉じ込められることによって、グローバルスコープを回避してCSSを扱えるようになりました。

:::note info
コンポーネントごとにclass名を検討できるため、class名のネームスペース確保に悩む時間がほぼなくなりました。
:::

## CSS設計は必要なくなったのか？
これは「No」だと考えています。

グローバルスコープや命名を考える労力が減ったのは確かですが、**コードの一貫性**はコンポーネントベースの設計では補えません。

一貫性というのは…
- 要素の名前をどのように命名するのか
- 要素と要素の間は、marginで確保するのかflexのgapを利用するのか
- marginは上方向につけるのか、下方向につけるのか
- プロパティの書き方

などをチームで認識を合わせて一貫したスタイリングを保つことを言います。

:::note info
一貫性をどのように担保するのか？について考える時「CSS設計」に対しての知識や知見が一定量必要だと考えています。
:::

なので「CSS設計」が必要なくなったのか？に対する答えは現時点では「No」です。

## 【コンポーネントベースの開発時代においてCSS設計は本当に必要なのか？考えてみた】まとめ
CSS設計を学ぶ意味はあります。
コンポーネントを設計する上でもある程度役には立っていると感じるためです。

TypeScriptやNext.jsなどでどのように表現したら良いか分からなくても…
こうであってほしい、このようにコンポーネントを切り分けたいなどはCSS設計の知識が活かされていると思うからです。

この記事がご自身の状況に合わせて、今CSS設計を学ぶメリットが大きいのか、小さいのか判断できる材料になれば幸いです。
Jasmine TeaでHello, world!

この記事は、 [Jasmine Tea アドベントカレンダー 2023](https://qiita.com/advent-calendar/2023/jasminetea) の第1日目です。

# はじめに

[Jasmine Tea](https://jasminetea.app) (ジャスミンティー) は、プログラミングの楽しさを多くの人に知ってもらうために作られたプログラミング言語です。初心者が学びやすい仕組みで、実際に社会で使われている多くのプログラミング言語に応用できる基礎が身に付きます。

ここでは、Jasmine Teaを実際に開いて、最初のプログラムとなる定番の「Hello, world!」を表示してみましょう。

# Studio画面を表示する

Jasmine Teaでプログラミングを行う画面は、Studio画面と名付けられてます。まずは、Studio画面を開きましょう。

以下のウェブページにアクセスしてください。

https://jasminetea.app

Jasmine Teaのトップページが表示されます。右上にある「試してみる」ボタンを押してください。

![スクリーンショット 2023-12-01 6.22.10.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3632303/5f605e0d-547c-eae9-7e67-d2baa9ba3cb4.png)

すると、以下のような画面が表示されます。これが、Studio画面です。

![スクリーンショット 2023-12-01 6.24.48.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3632303/c41d03cd-ac82-9674-cfbe-6ab07b0ffda4.png)

# プログラムを書いてみよう

何も考えずに、さっそくプログラミングを始めましょう！

Studio画面の左側には、プログラムを入力するためのエディターがあります。

![スクリーンショット 2023-12-01 6.24.48.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3632303/f8d657e9-209e-b0d3-523b-6a20db3c7c9e.png)

赤で囲まれた部分をクリックして、「1」と書かれた付近にカーソルが点滅していることを確認してください。

では、キーボードを使って、以下のプログラムを入力してください。

```
print "Hello, world"
```

最後にENTERキーを押して、改行しておいてください。

![スクリーンショット 2023-12-01 6.30.47.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3632303/a122b39c-378d-4213-7bb8-ce33479ea96f.png)

もし赤くなってしまっていたら、打ち間違いがあります。直してください。

![スクリーンショット 2023-12-01 6.52.24.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3632303/b09a4892-1a74-de70-a01c-d20bc81611a7.png)

# 実行してみよう

プログラムを実行してみましょう。エディターの下にある「実行」と書かれた青色のボタンを押してください。

![スクリーンショット 2023-12-01 7.03.21.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3632303/3a5f26d9-db15-0d75-64f8-256eff2b42b4.png)

Studio画面の右側の表示が切り替わります。「Hello, world」と表示されましたか？

![スクリーンショット 2023-12-01 7.04.42.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3632303/2433e3dd-e59f-f7a9-6dce-cb889b4489a4.png)

「OK」とも表示されていますが、これはプログラムの実行が正常に終了したことをコンピューターが教えてくれています。

# プログラムの解説

簡単に、プログラムの解説をします。

```
print "Hello, world"
```

Jasmine Teaには、様々な「[命令](https://jasminetea.app/docs/references/index)」があります。Jasmine Teaのプログラムは、

「1行ごとに1つ命令を並べていく」

で書いていきます。命令は、

```
beep
```

のように命令の名前だけを書けば良いこともあれば、今回の `print` 命令のように「命令を実行するときに必要となる情報（パラメーターと呼びます）」を書く必要があることもあります。

[`print` 命令](https://jasminetea.app/docs/references/command-print)は、テキスト画面に文字を表示する命令です。パラメーターとして、表示したい文字列を「"」で囲って書いています。結果として、実行画面上に「Hello, world」と表示された、ということです。

# 明日は何をつくるの？

明日は、もう少しコンピューターっぽいことをしてくれるプログラムを作ってみようと思います。

https://qiita.com/yoichiro6642/items/ccf50ba6ea4565aca5a5
情報技術者試験受けた。

令和5年度秋期試験に受けました。合格発表はまだです。(受かっててくれ)
試験に向けた対策や受けた時の感想などを書いていきます。
# プロフィール
* 短期大学1年生
* 好きなコーヒーはニカラグアの浅煎り
* web系の会社に就きたい
* もう就活始まる
# 応用情報技術者試験
情報処理の促進に関する法律第29条第1項の規定に基づき経済産業大臣が行う国家試験である情報処理技術者試験の一区分。

https://www.ipa.go.jp/shiken/kubun/ap.html

# 使用した参考書とwebサイト
* 令和05年春期秋期応用情報技術者合格教本

https://gihyo.jp/book/2022/978-4-297-13158-6

* 応用情報技術者試験ドットコム

https://www.ap-siken.com/apkakomon.php

# 午前試験
私が実践したのは過去問道場駆動学習です。(勝手に名付けた)
具体的に言うと、

1\.　**分野を選択(ストラテジ系、テクノロジ系など)**
2\.　**問題を読む**
3\.　**理解している ? 解いて次に進む : 参考書で調べて解く**

2,3を繰り返して勉強していきました。問題を解かないと頭に入らないタイプなので、参考書を読み始めるまえに問題を解くスタイルが効率よく勉強できました。網羅度レポート(過去問道場)は全2960問中539問回答(18.2%)と、やる気が無かったと疑われてもおかしくない数値で試験に挑みました。

試験を受けた感想としては、初めて見る問題が多く感じました。勉強不足ですね。試験会場内はけっこう窮屈で、隣の机との距離がかなり近いし、机自体も小さかったのでやりにくかったです。開始から1時間半程で見直しまで終わったので途中退室しました。同じ部屋で試験を受けていた人の半数くらいはそのころに退室していました。
[問題冊子](https://www.ipa.go.jp/shiken/mondai-kaiotu/ps6vr70000010d6y-att/2023r05a_ap_am_qs.pdf)
# 午後試験
午前と同じく過去問ベースで取り組みました。対策した分野は**情報セキュリティ**・**プログラミング**・**システムアーキテクチャ**・**組み込みシステム**・**プロジェクトマネジメント**です。記述式なので暗記しておかないと解けない問題があるので午前対策をある程度してから取り組み始めるとストレス少なく進められると思います。また、試験が近くなったら1週間に1回くらいの頻度で実際の試験と同じように5問続けて解く練習をしてました。

午前同じく2時間半問題を解く時間がありますが1問30分で解かないと終わらないのできつめでした。情報セキュリティが難しかったです。基本情報では得点源だったのに応用情報では足を引っ張る分野になってしまいました。
[問題冊子](https://www.ipa.go.jp/shiken/mondai-kaiotu/ps6vr70000010d6y-att/2023r05a_ap_pm_qs.pdf)
# 終わりに
私は勉強が嫌いではないですが、情報技術者試験の勉強はやっていてあまり面白くないのでモチベーションの維持が難しかったです。夏には1か月弱参考書を開かなかった時期もありました。高校では一緒に試験対策する人が5人くらいいて、モチベが下がることはなかったので、もし試験に挑もうとしている人は同じ志を持つ仲間を集めることをおすすめします。自己採点がかなりぎりぎりなので受かったらラッキーくらいの期待度で発表を待ちたいと思います。
(まじで受かってくれ)
Amazon Qに関する情報まとめてみた

# はじめに

re:invent盛り上がってますね！
この記事では今回の目玉発表であったAmazon Qについてのアップデートや関連するブログについて簡単にまとめています。
※ほぼ自分のための備忘録ですのであらさがあることはご容赦ください

# Amazon Qとは

2023年11月28日に、[生成AIを活用したアシスタント](https://aws.amazon.com/about-aws/whats-new/2023/11/aws-amazon-q-preview/)として発表されました。現時点ではプレビュー版です。
Amazon Qは、特にビジネス用途に特化しているとされていて、社内のストレージ等と接続することでさまざまなコンテンツ、リポジトリにまたがる知識からの質問・回答、レポート要約、記事の作成を実行出来ます。

## もう少し詳細に

現時点でプレビュー版ではありますが、Amazon QuickSight、Amazon Connect、AWS Supply Chainとの連携が発表されています。
現時点で様々なサービスとの連携が発表されているのでこれから更に連携は拡大するものと思われます。

詳細は下記をご確認いただければと思います。

https://aws.amazon.com/q/

利用プランは大きく2つに分かれていて、料金体系も異なるので注意が必要です。

https://docs.aws.amazon.com/amazonq/latest/business-use-dg/what-is.html

https://docs.aws.amazon.com/amazonq/latest/aws-builder-use-ug/what-is.html

# 各種用途に応じたブログ

## ビジネス用途関連のブログ

下記ではビジネス用途で利用する際の例が記載されています。ブログの中では、AWS Blogを学習させてその内容に関する質問をする手順が簡単に記載されています。

https://aws.amazon.com/blogs/aws/introducing-amazon-q-a-new-generative-ai-powered-assistant-preview/


## AI-powered assistance関連のブログ

下記では開発で利用する際の例が記載されています。

https://aws.amazon.com/about-aws/whats-new/2023/11/amazon-q-expert-capabilities-aws-preview/

https://aws.amazon.com/blogs/aws/amazon-q-brings-generative-ai-powered-assistance-to-it-pros-and-developers-preview/

## Amazon Q in QuickSight関連のブログ

下記ではQuickSightで利用する際の例が記載されています。

https://aws.amazon.com/about-aws/whats-new/2023/11/amazon-q-quicksight-data-exploration-generative-bi-capabilities-preview/

https://aws.amazon.com/blogs/aws/new-amazon-q-in-quicksight-uses-generative-ai-assistance-for-quicker-easier-data-insights-preview/

## Amazon Connect関連のブログ

下記ではコンタクトセンターで利用する際の例が記載されています。

https://aws.amazon.com/about-aws/whats-new/2023/11/amazon-q-connect-generative-ai-powered-agent-assistance-real-time/

https://aws.amazon.com/blogs/aws/new-generative-ai-features-in-amazon-connect-including-amazon-q-facilitate-improved-contact-center-service/



# その他の機能との内部的な連携に関する情報

https://aws.amazon.com/about-aws/whats-new/2023/11/aws-chatbot-q-conversations-teams-slack/

https://aws.amazon.com/about-aws/whats-new/2023/11/amazon-q-optimal-ec2-instance-selection-workload/

https://aws.amazon.com/about-aws/whats-new/2023/11/feature-development-capability-amazon-q-preview-codecatalyst/

https://aws.amazon.com/about-aws/whats-new/2023/11/amazon-redshift-generative-sql-query-editor-preview/

**まだ、整理しきれていないので整理でき次第で順次更新します！**




# まとめ

めちゃくちゃ便利な機能ですね。あらゆる問い合わせ業務や調査にかかる時間が激減するような予感がしました。
私自身、早くキャッチアップして使いこなせるようにしたいです。
推し活とちゅらデータ

初めましての方も、そうでない方もこんにちは。
ちゅらデータでシステムエンジニアをしておりますmahoshiです。

ちゅらデータにジョインしたのが6月1日、気がついたら12月になり、入社して半年ほど経ちました。
アドベントカレンダーは初参加、せっかくなので何か書きたいと思い参加表明をしたものの、技術記事を書けるほどネタもなく、かといってただの入社記を書くのも特に面白くない。
特にネタもなく悶々としていたところ、ふと思い出しました。

**私には推し活があるじゃない！！**

ということで、推し活とちゅらデータで記事を書いてみようと思います。

## mahoshiと推しの話

本題に入る前に、少し自己紹介をさせてください。
mahoshiと名乗る私は、冒頭でも書いたとおり、6月1日にちゅらデータにジョインしました。
それ以前はとあるSES企業で働いていたのですが、それはまた別の機会に。
ちゅらデータの所在地は沖縄県で、私は東京在住。現在はフルリモートで勤務しています。

東京に住んでいる色々理由はありますが、推し活がしやすいのもその一つ。
最近の推しはとある男性アイドルグループなのですが、推し事をするには東京が圧倒的便利。。！
しかしながら、地方公演がある際には遠征と称して公演のある土地まで行くことも。

実は今月も、推しグループの公演があるため、九州に行くことが決まっています。
遠征が決まった日、私はふと思いました。

**九州にいるちゅらの先輩がいるし、もしかしたら会えるのでは？？？**
（おいしいご飯やさんがあれば紹介してもらえるかも！）

## フルリモート勢も多いちゅらデータだからこそ

ちゅらデータには、フルリモートで働く社員もたくさんいます。
入社前は、あまり会社の人との交流はないのかなあ、と漠然と思っていたのですが、蓋を開けたら全くそんなことはなく。
首都圏に住む人も多いため、時々都内でも飲み会が開催されていました！ありがたや。
また、Slackでのコミュニケーションが活発で、寂しさもほとんどありませんでした。

しかしながら、首都圏に住む方々以外とは直接交流する機会が少ないことも事実。

早速、九州に行くことが決まった旨を報告。
すると、あれよあれよと話が進み、飲み会の開催＆お店の予約まで！ありがたすぎます。

1人で行く遠征は、推しに会う以外の楽しみが一人旅になってしまうのですが、1人だとご飯に悩むことも多々。
しかし、全国に社員がいるちゅらデータでは、行く先に大抵誰かいます。しかもフットワークが軽い。

**推しに会う楽しみと、普段会えないけど話したい人に会う楽しみがある遠征、素敵じゃないでしょうか？？**

## おわりに

推し活とちゅらデータ、ちょっと無理があるかなあなんて思いながら記事を書いていました。
だけど、プライベートの用事だけどせっかくだから会社の人にも会いたい！って思える環境ってなかなか素敵だな、と改めて思ったりしました。

私も東京に来た時に会いたいと思ってもらえるように今後も精進していきたいと思います！
Figmaによるチーム、プロジェクト、ファイルの作り方【2023年度12月1日最新】



Figmaは誰でも無料で使えるデザインツールであり、プロの現場でも使われる素晴らしいソフトウェアです。
Mac / Windows / Webブラウザを使って誰でもデザインを始められ、その柔軟さと機能性でユーザー数を伸ばしています


## ツール

- Figma
    - デザイナーのためのプロトタイプ作成ツール。
    - ブラウザベースのサービスだが、動作を軽くするためにデスクトップ版のインストールを推奨します。
- Figma (iOS)
    - PCで作成したレイヤーを実際にiOSから動作確認するためのアプリです。



## Figmaの構成


- ドラフトファイル : 下書きファイルのこと。自分のみしか編集することができない。（参照は可能）
    - ドラフト
- チーム : 共同編集者を無制限に追加することが可能。ただし、無料プランではプロジェクトの数とファイルの数に制限がある。
    - プロジェクト
        - ファイル: ドラフトファイルと同じもの。ドラフトファイルで下書きしたものを追加することが可能。無料版では一つのプロジェクトに3つまで追加可能。


## チームの作り方

ホーム画面に行き、「Teams」から「Create new team」を押下

<img src="https://github.com/minegishirei/psy/blob/main/img/figma/create_team/1.png?raw=true">

チーム名を入力する

<img src="https://github.com/minegishirei/psy/blob/main/img/figma/create_team/2.png?raw=true">

共同で編集したいメンバーがいればメールアドレスを追加する

<img src="https://github.com/minegishirei/psy/blob/main/img/figma/create_team/3.png?raw=true">

フリープランを選択

<img src="https://github.com/minegishirei/psy/blob/main/img/figma/create_team/4.png?raw=true">

ホーム画面に自動的に戻り、新しいチームが作成されている


## プロジェクトを追加

「+ Project」を押下

<img src="https://github.com/minegishirei/psy/blob/main/img/figma/create_team/5.png?raw=true">

新しいプロジェクト名を入力し、「Create project」を押下

<img src="https://github.com/minegishirei/psy/blob/main/img/figma/create_team/6.png?raw=true">

ホーム画面に自動的に戻り、新しいプロジェクト名が作成されている


## デザインファイルを追加

「+ Design file」を押下

<img src="https://github.com/minegishirei/psy/blob/main/img/figma/create_team/7.png?raw=true">

新しいデザインファイル画面が作成される

<img src="https://github.com/minegishirei/psy/blob/main/img/figma/create_team/8.png?raw=true">


任意の編集を行う（ここでは「TEST PROJECT」と入力）

<img src="https://github.com/minegishirei/psy/blob/main/img/figma/create_team/9.png?raw=true">

画面上部にあるプロジェクト名を押下し、編集する

<img src="https://github.com/minegishirei/psy/blob/main/img/figma/create_team/10.png?raw=true">

<img src="https://github.com/minegishirei/psy/blob/main/img/figma/create_team/11.png?raw=true">

ホーム画面に戻ると、新しいデザインファイルが作成されている。

<img src="https://github.com/minegishirei/psy/blob/main/img/figma/create_team/12.png?raw=true">
初学者向けAnsibleチートシート

## 前書き
本投稿は、Ansible初心者が備忘録として作成した記事で、[Ansibleカレンダー](https://qiita.com/advent-calendar/2023/ansible)の19日目の記事です。
内容に間違いがありましたら、編集リクエストもしくはコメントにてお知らせください。

## Ansible 公式ドキュメント
本稿は以下のドキュメントを参考に作成しています。
https://docs.ansible.com/ansible/latest/index.html

## Ansible
Ansibleでは、構築する環境の情報が記述された『Playbook』と呼ばれるYAMLファイルを実行することで、VMなどの環境を構築します。
YAMLファイルには、『PLAY』と呼ばれるタスクリストを定義し、PLAY内のタスクは上から下へ順番に実行されます。

### バージョン情報
https://github.com/ansible/ansible/releases

## Ansibleのインストール

以下のドキュメントを参照
https://docs.ansible.com/ansible/latest/installation_guide/intro_installation.html

最新版のドキュメントだと、OSごとのインストール案内ではなくなっており混乱する可能性があります。現在のlatestは`v2.16.2`なので`v2.9`は結構古いですが、以下のページ(v2.9)を参照するとOSごとのインストール案内が書いてあるので、ヒントになるかもしれません。
https://docs.ansible.com/ansible/2.9/installation_guide/intro_installation.html

## Playbookの構成
`inventory.yml`ではVMなどのホストを作成し、`site.yml`ではホストに対してタスクを実行することで環境構築を行います。

**構成例1:**
- inventory.yml
- playbook.yml

**実行コマンド例：**
```
ansible-playbook -i inventory.yml playbook.yaml
```

**構成例2:**
Playbookは役割ごとに分割することも可能です。
- inventory.yml
- roles/hoge/tasks/main.yml
- sites/hoge/site.yml
- files/template_test.conf.j2
- ansible.cfg

**実行コマンド例：**
```
export ANSIBLE_CONFIG=${PWD}/ansible.cfg; ansible-playbook\
-i inventory.yml -l test-host sites/hoge/site.yml
```

## モジュール
Ansibleには、タスクを定義するためのモジュールがあらかじめ用意されています。
例えばホスト内でshellを実行したい場合、Ansibleモジュールを使用して定義・実行することができます。

```roles/hoge/tasks/main.yml
- name: "test task"
  ansible.builtin.shell: |
    apt install -y vim
```
https://docs.ansible.com/ansible/latest/collections/ansible/builtin/shell_module.html

また、`apt install -y vim`は以下のように`ansible.builtin.apt`モジュールを使用して記述することも可能です。
```
- name: "test task"
  ansible.builtin.apt:
    name: vim
    state: present
```
https://docs.ansible.com/ansible/latest/collections/ansible/builtin/apt_module.html

## Jinja2 テンプレート
AnsibleではJinja2を使用してテンプレートを作成することが可能です。
これにより、テンプレートファイルの中身を変数で定義し、ホストごとに異なるパラメータの設定ファイルを配置できます。

https://docs.ansible.com/ansible/2.9_ja/user_guide/playbooks_templating.html

### 使い方
本例で使用するファイルは以下です。

- `files/template_test.conf.j2` : テンプレートファイル
- `inventory.yml` ：変数の定義
- `roles/hoge/tasks/main.yml` ：テンプレートファイルの変換と配置

``` template_test.conf.j2

huga {
    piyo: {{ unyora }}
}
```

``` inventory.yml
<中略>
hoge:
    vars:
        unyora: kirokiro
<中略>
```

``` roles/hoge/tasks/main.yml
- name: "hoge"
  template:
    src: "../../files/template_test.conf.j2"
    dest: "/etc/hoge/template_test.conf"
```
↓
Playbookを実行すると、ホスト側には以下のように変数に値が代入されたファイルが配置されます。
``` /etc/hoge/template_test.conf
huga {
    piyo: kirokiro
}
```
## Ansible Semaphore
Ansible Semaphore（SemaphoreUI?）を使うことで、デプロイをコマンドラインからではなくUI上で管理することが出来ます。また、GithubやGitlabのSSHキーをSemaphoreに持たせることで、リポジトリ上のソースコードでデプロイが行えます（裏側処理では、Semaphoreが自動でcloneを行っている）。
https://www.semui.co/
https://hub.docker.com/r/semaphoreui/semaphore
※ RedHatの公式ツールとしてAnsible Towerがありますが、本稿では著者が実際に触ったSemaphoreを紹介しています
Microsoft Graphってなんですか：概要編

### Microsoft Graph入門：初心者のためのガイド

Microsoft Graph（MS Graph）は、マイクロソフトのクラウドベースのサービスとアプリケーションを統合し、豊富なデータアクセスと操作機能を提供する強力なツールです。このガイドでは、MS Graphの基本的な概念、機能、そしてそれがどのようにして組織のニーズに合わせたカスタマイズ可能なソリューションを作成するのに役立つかを紹介します。

#### MS Graphの立ち位置
Microsoft Graph、Azure AD、およびActive Directory（AD）の違いと関連性、さらにそれぞれに関連するAPIの特徴と使用法を図解する
```mermaid
graph TD
    subgraph cloud [クラウドサービス]
        AzureAD[Azure AD]
        MicrosoftGraph[Microsoft Graph] -- データアクセス --> AzureAD
        MicrosoftGraph -- データアクセス --> ExchangeOnline[Exchange Online]
        MicrosoftGraph -- データアクセス --> MS365[Microsoft 365]
        MicrosoftGraph -- データアクセス --> EMS[Enterprise Mobility + Security]
    end

    subgraph onprem [オンプレミス環境]
        OnPremAD[Active Directory]
    end

    AzureAD -.->|ID管理| MicrosoftGraph
    OnPremAD -.->|同期| AzureAD
    OnPremAD -.->|相互運用性| MicrosoftGraph

    style cloud :#bbf,stroke:#333,stroke-width:2px
    style onprem :#fbf,stroke:#333,stroke-width:2px


```



#### Microsoft Graphの基本

- **データアクセスと管理：** MS Graphを使用すると、ユーザーのメール、カレンダー、連絡先、文書、ディレクトリデータなどにアクセスできます。
- **一元化されたAPIエンドポイント：** MS Graphは、マイクロソフトのクラウドサービスにまたがるデータに単一の統合APIエンドポイントを提供します。

#### MS Graphの一元化されたAPIエンドポイントの利点

MS Graphは、マイクロソフトのクラウドサービスを統合し、単一のAPIエンドポイントを提供します。これにより、開発者は複数のAPIエンドポイントを別々に扱う必要がなくなり、効率的に開発作業を進めることができます。

##### 図解：MS Graphの一元化されたAPIエンドポイント

```mermaid
graph LR
    A[従来のAPIエンドポイント] -->|統合| B[Microsoft Graph API]
    A --> C[Outlook API]
    A --> D[OneDrive API]
    A --> E[Teams API]
    B --> F[統一されたアクセス]

    style B :#f9f,stroke:#333,stroke-width:2px
    style F :#bbf,stroke:#f66,stroke-width:2px
```


#### MS Graphが可能にすること

1. **オートメーションと効率化：** ユーザーのカレンダーから自動的にミーティングをスケジュールしたり、メールを整理したりするアプリケーションを作成できます。
2. **カスタムアプリケーションの開発：** 企業固有のニーズに合わせたカスタムアプリケーションを作成できます。
3. **インサイトと分析：** MS Graphは、ユーザーの作業方法や組織内でのコラボレーションのパターンに関する洞察を提供します。

#### MS Graphの構造（MermaidJSでの図解）

以下はMS Graphの基本的な構造を示すMermaidJSの図です。これは、APIエンドポイントと主要なコンポーネント間の関係を視覚的に表現しています。

```mermaid
graph TD
    A[Microsoft Graph API] -->|アクセス| B[Office 365サービス]
    A -->|アクセス| C[Windows 10サービス]
    A -->|アクセス| D[Enterprise Mobility + Security]
    B -->|データ| E[Outlook, OneDrive Teamsなど]
    C -->|データ| F[デバイス管理　セキュリティ]
    D -->|データ| G[アイデンティティとアクセス管理]

    style A :#f9f,stroke:#333,stroke-width:2px
    style B :#bbf,stroke:#f66,stroke-width:2px
    style C :#bfb,stroke:#f66,stroke-width:2px
    style D :#fbf,stroke:#f66,stroke-width:2px
```

### まとめ

Microsoft Graphは、開発者に効率的でカスタマイズ可能なソリューションを作成するための強力なツールを提供します。マイクロソフトのクラウドサービスとアプリケーションを統合し、組織のニーズに合わせてこれらのリソースを最大限に活用することが可能になります。
バッチファイルでwin10 Teamsをタスクキル/キャッシュを消す


## 背景

リモートデスクトップ先でTeamsを開くと，ウィンドウ上のキー・マウスの入力が受け付けなくなることが多かった．
毎回タスクマネージャーを開いて消していたが，毎回開くのが面倒なので簡単に消す方法を考えていた．
そこで，デスクトップ上に配置したバッチファイルを用いてタスクキルすることを思いついた．
ついでにPCが重くならないように任意でキャッシュも消せるようにしておいた．
バッチファイルの作成があまり得意ではないので，その練習も兼ねている．

## バッチファイルの作成

```
@REM deleteTeamsCache.bat
 
@echo off
 
@REM MicrosoftTeamsをタスクキルする
echo ------1.Kill Teams Tasks------
taskkill /F /IM Teams.exe
 
@REM Teamsのキャッシュを削除する
echo ------2.Delete Teams Cache------
dir %appdata%\Microsoft\Teams
rd /s %appdata%\Microsoft\Teams
```

1. タスクキルをするコマンド
 win10では`taskkill`コマンドを利用する．(linuxは`kill`を利用)
    `/F`は，プロセスの強制終了．
    `/IM`は， 終了させるプロセスのイメージ名を指定する．今回だとTeamsの実行ファイルを指定している
1.  キャッシュを削除するコマンド
     削除しても問題ないファイルかを確認するために，`dir`コマンドで削除予定のファイル一覧を表示している．
     Teamsのキャッシュは，`%appdata%\Microsoft\Teams`に保存されている．
     初めて動作させる前に`win+r`(ファイル名を指定して実行)でパスを入力して，エクスプローラーで確認しておくといいと思う
     キャッシュの削除は，ディレクトリごと削除する`rd /s`コマンドで削除する．
    
## 注意
エクスプローラーから削除するのと違い，一撃完全削除なので，
重要なファイルが無いか，必ず確認しておく必要がある．
AWS Glueを使用したS3からRDS（MySQL）へのデータ取り込み2

## Glue・RDS間の接続

まずはRDSへの接続から作っていく。

Glue→Connectionを選択し、「Create connection」ボタンを押下。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/390179/3a311941-f0ab-949a-1c52-12f35ad8d34d.png)

Name：　任意の名称を入力
Connection type：　Amazon RDS
Database engine：　MySQL
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/390179/8e31a83a-b09f-fa52-3d67-a9ab56f0acbf.png)

Database instances：　接続対象のRDSインスタンス
Database name：接続対象のデータベース名を入力
Credential type：Username and passwordを選択する
Username：接続対象のデータベースユーザーネームを入力
Password：接続対象のデータベースパスワードを入力

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/390179/b8fd672a-4d17-3792-03d3-fe1905d17a19.png)

画面の「Create connection」を押下する。
で、この時点では実はまだ設定は終わってないんですな。
なんでそんな作りになってるかは不明。。。

一覧を表示したら、作ったConnectionを選択して、「Actions」から「Edit」を選択する。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/390179/2af61375-1c1b-3c33-79a3-57ef467b2ecc.png)

「Network options」を開いて、追加の設定をしていく。
VPC：RDSがあるVPCを指定
Subnet：RDSがあるSubnetを指定
Security groups：Glue用に作ったSecurity groupsを指定
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/390179/d4d5174b-a1ab-a966-3a47-d2f233340af1.png)

再度、「Create connection」を押下する。

一覧から対象のConnectionを選択して、「Actions」から「Test connection」を選択する。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/390179/2af61375-1c1b-3c33-79a3-57ef467b2ecc.png)

これで成功すれば完了。
でも↓のエラーが出ると思う。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/390179/ea0a3eb4-0ad2-942a-e605-84a7e25c290a.png)

原因が全くわからんが、この場合はもう一度「Actions」から「Edit」を開いて、
あえてデータベースのパスワードに間違ったものを入力して保存。
「Test connection」を実行すると当然エラーが出るので、再度「Actions」から「Edit」開いて、
正しいパスワードを入力し保存すると、「Test connection」が成功する。

RDSの再起動をした場合も上記のエラーが出るので、RDS再起動後は同じ対応をすると接続できるようになる。
ほんと理由わかんない。だれか知ってたら教えて。。。
長い動画を25MBごとに分割すーる（Python）

# はじめに
[がちもとさんアドベントカレンダー](https://qiita.com/advent-calendar/2023/gachimoto3)1日目の記事です。
今日は、長い動画を25MBごとに分割するプログラムを作成しました。

# 開発環境
- Windows 11 PC
- Python 3.11

# 導入
## ライブラリのインストール
pip install moviepy

## プログラムの作成

~~~split_video.py
from moviepy.editor import VideoFileClip
from moviepy.editor import concatenate_videoclips
import os
import tempfile

def split_video(file_path, max_size_mb=25):
    clip = VideoFileClip(file_path)
    total_duration = clip.duration
    max_size_bytes = max_size_mb * 1024 * 1024

    current_clips = []
    current_size = 0
    part = 1

    base_name, ext = os.path.splitext(os.path.basename(file_path))

    for i in range(0, int(total_duration), 60):  # 60秒ごとにループ
        subclip = clip.subclip(i, min(i + 60, total_duration))

        # 一時ファイルのパスを生成
        temp_fd, temp_filename = tempfile.mkstemp(suffix='.mp4')
        subclip.write_videofile(temp_filename, codec="libx264")
        clip_size = os.path.getsize(temp_filename)
        print(current_size / 1024 / 1024)

        if current_size + clip_size > max_size_bytes:
            final_clip = concatenate_videoclips(current_clips)
            final_clip.write_videofile(f"{base_name}_{part:06d}{ext}", codec="libx264")
            part += 1
            current_clips = []
            current_size = 0

        current_clips.append(subclip)
        current_size += clip_size

        # 一時ファイルを削除
        os.close(temp_fd)
        os.remove(temp_filename)

    # 最後のパートを保存
    if current_clips:
        final_clip = concatenate_videoclips(current_clips)
        final_clip.write_videofile(f"{base_name}_{part:06d}{ext}", codec="libx264")

# 使用例
split_video("example.mp4")
~~~

このスクリプトは、動画ファイルを指定した最大サイズに分割するために使用されます。手順は以下の通りです：

1．指定された動画ファイルを読み込み、その全体の長さを取得します。
2．60秒ごとに動画を区切り、各セグメントを一時ファイルに保存します。
3．これらのセグメントのサイズをチェックし、合計サイズが指定された最大サイズ（デフォルトは25MB）に達するまでセグメントを追加します。
4．最大サイズに達したら、これまでのセグメントを結合して1つの動画ファイルとして保存し、次の部分に進みます。
5．全てのセグメントが処理されるまでこのプロセスを繰り返します。
6．最後のセグメントも同様に結合して保存します。

使用例では、"example.mp4"というファイルをこのスクリプトで分割しています。このスクリプトは、動画の長さに関わらず、任意の動画ファイルを指定したサイズに分割することが可能です。

# 実行

example.mp4は310MBあるのですが、25MB以内の9個のファイルに分割できました。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/63863/6cba3252-7872-7e62-b85b-c809bcda75ad.png)

他にもっといい方法があれば教えてください！
お疲れさまでした。
楽に続けられる！技術書勉強法

# はじめに
この記事は アイスタイル [Advent Calendar 2023](https://qiita.com/advent-calendar/2023/istyle) 8日目の記事です。

[アットコスメ](https://www.cosme.net/)のWEBを担当しているyamaguchiiです。

みなさん技術書の勉強ってどうしているでしょうか？
読みたい本はたくさんあるのに、なかなか読めずに積読してしまうことがありますね。
通勤時に読んだり、冬休みにまとめて読むなど、読み方はいろいろあると思います。
今回は、私の「楽に続けられる！」技術書の読み方を参考になればと思い紹介します。

## 「楽に続けられる！」技術書の読み方
![kindle.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3621287/fb02e7de-07fe-86ac-387c-49b391eeed98.png)
果たして、こんなにたくさんの技術書を読めるのか！？

### ざっくり言うと
:::note warn
毎日寝起きに電子書籍をノートPCで1冊2～5ページを5,6冊読む
:::

### いつ読むか？
私は朝起きてまず、ノートPCを開き、キンドルのアプリなどで電子書籍の技術書を読みます。
朝は頭が冴えているから、勉強するのに適しています。（寝起きが悪いなど、個人差はあると思います。）
また早朝だと、slackやスマホの通知なども少ないので、邪魔されずに集中できます。

大事なのは朝に限らず、毎日同じ時間に読むことを習慣化してしまうことです。
通勤電車やお風呂に入浴中などもいいですね。
毎日決まった時間で、あまり割り込みが入らない時間がおすすめです。

いつか時間があったら読むという不定期だと、時間が経つと前回まで読んだところが忘れてしまうことが多く、読み始めるのが億劫になります。
毎日決まった時間に読んでいると、前回の内容もすぐに思い出せますし、記憶にも定着します。（[エビングハウスの忘却曲線](https://ja.wikipedia.org/wiki/%E5%BF%98%E5%8D%B4%E6%9B%B2%E7%B7%9A)）
毎日着実に成長している実感が得られます。


### 1冊2～5ページを5,6冊読む
1冊の技術書を続けて長く読むのは、集中力が切れたり、ボリュームが多くて覚えられなかったりで、疲れてしまいます。
そうすると、毎日読もうという気力も無くなり、習慣化できません。

私の場合は、1冊につき2～5ページ読んで、次の本、次の本と繰り返して、5,6冊を短く少しずつ読んでいます。
たった2～5ページだと5～10分もあれは読めます。飽きたり、苦痛になる前にやめているので、嫌になることがありません。
1冊の本を1時間通読するのは大変ですが、これなら楽に1時間で5,6冊は読めます。
なので毎日でも続けられるのです。

中学高校のときに英単語を覚えるのと同じ要領です。一度に100単語は覚えられませんが、毎日5,6個なら少しずつ覚えられます。
「エリック・エヴァンスのドメイン駆動設計」のような分厚い本を読むのには、数か月の時間がかかりますが、途中で断念せず読み切ることができました。

### パソコンのキンドルアプリで読む
紙の本で5,6冊まとめ読みするのは、本を置くスペースを確保しないといけません。
また紙の本やタブレット端末などを手にずっと持っているのも、重くて疲れます。
なので私は、パソコンのディスプレイで読んでいます。

### キンドルアンリミテッド
電子書籍サブスクのキンドルアンリミテッドでは、技術書も豊富にあります。
電子書籍版だけ出版されている技術書もあるので、キンドルアンリミテッドでも読めます。
高いお金を出して本を買うには、得たい情報が載っているかとかレビューを見て吟味しますよね。
でも、サブスクなら、試し読みができるので、期待と違っていたら読むのをやめることができます。
なので気軽に本を選べて、まとめ読みにちょうどいいです。意外と良い本に出会えますよ。

また、同じテーマの本を何冊か読んで理解を深めることができます。
私はdockerの本を1冊読んだだけでは、よく理解ができませんでした。
そこで別なdockerの本を5冊くらい読んで、ようやく理解できました。（遅い・・・）
こうしたことが気軽にできるのもサブスクの特徴です。

サブスクに無い本もあるので、読みたいものは、お金を出して買ってます。

### 読んだ本の履歴を見る
今年何の本を何冊読んだ。という履歴が分かると、これだけの本を読んで頑張ったんだという充実感が得られます。
キンドルのiphoneアプリでは、毎年の読み終わった本の履歴が見れます。
そして、今年は少ないな、もっと読もうというモチベーションにもなります。
![road.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3621287/80cf4015-0d2d-15af-4a49-5f417bda1b66.png)

BookLiveという電子書籍サイトでは、年末に1年間でどれだけ本を読んだかが集計されて見れるようになります。（BookLiveで購入した本に限る）
このように実績を振り返れるのも、楽しいですね。
![booklive.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3621287/307fa7d9-c2bd-88f1-9805-c0284cea945e.png)

# 最後に
いかがでしたか？
なるべく楽に読書を続けられる方法を紹介しましたが、参考になる部分があれば取り入れて、新しい技術の習得の役に立ててもらえると嬉しいです。
再利用しやすい日付テーブルの準備

# 要求事項
以下の要求を実現する日付テーブルの作成を考えます。
　　1. 再利用しやすい。
　　2. 曜日を考慮したい。
　　3. 祝日を考慮したい。
　　4. 複数パターンの会社（就業）カレンダーの休みを考慮したい。
　　5. 会計年度を取り扱いたい。
　　6. 会計年度を考慮した四半期を取り扱いたい。
　　7. 締め日を考慮したい。
　　8. （その他）データの更新日時を知りたい。

今後追加を検討したいこと
　　+ 英語表記の追加
　　+ 言語の切り替え

# 実現方法
<dl>
  <dt>Power Query</dt>
  <dd>情報の登録とパラメータによる必要なカレンダーの生成</dd>
  <dt>Power BI Desktop　[モデル]、[テーブル]ビュー</dt>
  <dd>日付テーブルの指定と階層の設定</dd>
  <dt>Power BI Desktop　[レポート]ビュー</dt>
  <dd>準備した日付テーブルの確認</dd>
</dl>

# 設計・設定のイメージ
![日付テーブルの準備_20231130-01.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3626635/b86ef09d-83a4-d53f-32ce-501c3735a903.jpeg "日付テーブルの準備")

# 準備した日付テーブルの確認
![日付テーブルの確認_20231201-01.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3626635/3e574bf6-759f-2bab-fe6e-c01256e2f9d3.jpeg "日付テーブルの確認")

# 本記事の担当範囲
:::note info
Power BI作成の流れ（下図）の赤枠部分に対応しています。
![Power BI作成の流れ_20231113-01（日付テーブルの準備）.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3626635/c243021c-6997-2c3e-87c5-7199de77fc7a.jpeg "Power BI作成の流れ（日付テーブルの準備）")
:::

https://qiita.com/NoriyukiT/items/5fb5e1c259c10900736d