勇者だって最初はひのきの棒とナベのふた

技術を中心に発信。時々SFの読書感想も。

CosmosDBのドキュメント読む その１

はじめに

masamoriです。 Cosmos DB盛り上がってますね。AI関連で。そろそろ触ってみるかー、と思い立ちまずはドキュメント。 恥ずかしながら、RDBしか触ったことがないので、CosmosDBがどう動くか分かってないのです。
この記事の目的は、ドキュメント読んで理解したことやドキュメントを理解するために調べたことを備忘録的な感じで残すということです。
なお、ドキュメントの量が結構あるので何回かに分けて記事を書きたいと思います。(その１とはそのため)

今回はこのドキュメントの最初の部分。

learn.microsoft.com

の概要のセクションから読んでいきます。 ちなみに使い方についての解説は他に素晴らしい記事がたくさん出てると思うので、あくまで自分の理解を記すに留めておきたいと思います。

CosmosDBの概要？

まずはこちらのドキュメントで概要を見てみます。

learn.microsoft.com

うーん、AI推しですね。AI目的のDBなのかと勘違いしてしまいそうですが。。まぁしかし、AzureOpenAIサービスを組み合わせた構成を考えるとき、CosmosDBを使用するのはもはやデファクトスタンダード化しているので、この文面は仕方が無いのかなと。MSはCopilotゴリ押しですし。 ただ、注目はこの部分。

Azure Cosmos DB は、AI、デジタル コマース、IoT、予約管理、その他の種類のソリューションを含む、現代のアプリ開発のためのフル マネージドの NoSQL とリレーショナルのデータベースです。 Cosmos DBを一言で言い表すなら、ここかなと思います。

フルマネージドかつ、データをグローバルに自動的に分散することによって高可用性・低遅延を実現していることが特徴でしょうか。
基本的にはNoSQLみたいです。
ちなみに、CosmosDBはBuild 2017で発表されたらしく、元々はDcumentDBとして公開されていたようです。
この辺の歴史はこちら

ryuichi111std.hatenablog.com

API.

続いてこちら.

learn.microsoft.com

初めにCosmosDBのAPIサポートについてドキュメントを読んだ時、正直意味がよく分かっていませんでした。今までPostgreSQLなどのRDBしか触ったことなかったので、「色んなDBのAPIをサポートしている」という概念がよくわからなかったのです。
例えば、RDBとKVSを併用したい場合、当たり前の話ですがリソースを別々に立てないといけません。しかし、このCosmosDBの「API複数サポート」という文言を見て、これ、CosmosDBのインスタンス一つ立てたら、その中で色んなDB使える感じ？とか思ってました。PostgreSQLにも対応しているようなので、一つのリソースの中でDBの種類を使い分けることができるなんて最高。って。しかし、そんなことは無いんですねー。
そんな甘い幻想を打ち砕いてくれたのがこちらの画面.

.

Cosmos DBを作成するとき、最初にAPIを選ぶ必要があります。なので、
一つのCosmos DBで使えるAPIは一種類. これが原則のようです。
じゃあ、NoSQLだけのサポートで良いんじゃないか？とか思いました。どういう場合にCosmos DBで他のDBのAPIを使うのかなと疑問に思っていたんですが、こちらに一つの解答がありました。

learn.microsoft.com この中の次のセクション.

NoSQL 用 API は Azure Cosmos DB にネイティブなものです。

MongoDB、PostgreSQL、Cassandra、Gremlin、Table 用の API では、オープンソース データベース エンジンのワイヤ プロトコルが実装されます。 これらの API は、次の条件が満たされている場合に最適です。

既存の MongoDB、PostgreSQL Cassandra、または Gremlin アプリケーションがある場合 データ アクセス層全体を書き直す必要がない場合 オープンソースの開発者エコシステム、クライアント ドライバー、専門知識、データベースのリソースを使用する場合

つまり、既に運用しているDBがあればAPIを使うと良いということでしょうか。 例えば、何かしらのインスタンスを立て、DBを入れている場合スケールは手動でしなければなりません。しかし、Cosmos DBはフルマネージドなのでその辺もよしなにやってくれると。また、データをグローバルに分散しているので可用性も保証されると。それらに対してメリットを感じたらAPIというのも一つの手ですよ、という感じでしょうか。
個人的には、RDBはRDBで立ててNoSQLはNoSQLで立てて運用した方が、良いような気もします。が、RDBとCosmos DBの連携がCosmos DBのAPIを使った方が遥かに容易になるのであれば、RDBもCosmosDBのAPIに任せてしまうのもありかなと思います。この辺はユースケース調べてみたいですね。
ちなみに、PostgreSQLを分散型データベースとして利用することを可能にしているのは、このライブラリらしいです。

github.com

興味深い。これも深掘りしてみたいです。
ちなみにちなみに、CosmosDBが分散リレーショナルに対応したのは割と最近っぽいです。

https://www.publickey1.jp/blog/22/postgresqlazure_cosmos_dbdbcitusignite_2022.htmlwww.publickey1.jp

終わりに

今回のブログではここまでにしたいと思います。今後何回かに分けて、ドキュメント読んで自分の学んだことを記事ににしていこうと思います。
基本的にはドキュメントの上から順に読んでいこうと思ってます。
なお、多々自分の理解に間違いがあると思うので、修正は入れていきたいと思います。

Azure Function をVSCodeでslotにデプロイする

Azure 技術 Functions

はじめに

masamoriです。今更感がありますが、ゼルダの伝説ティアキン始めました。いやー、面白い。寄り道ゲームとして最高の出来だと思います。考察についてはこれだけで3本ぐらいの記事になってしまうので、また別の機会に。
さて、最近Azure Functionsに触れる機会が多くなってきました。便利なんですよねこれ。何が便利かって、まずは使った分だけしかお金かからないってことですが、それよりもアプリケーション構成がものすごく考えやすくなったってことが便利です。
どういうことかと言うと、モノシリックにアプリを作る場合、全てのイベントを一つの大きなファイルにまとめなきゃいけないんですよね。後で機能を追加したい場合、そのアプリケーションのルールに従って書かなきゃいけないわけです。当然ですね。
しかし、Functionsのようなサービスを使う場合、イベント駆動的な処理はFunctionsに任せて、アプリは通信の出入り口を提供するだけで良かったりします。まぁ、Functionsを使いすぎると逆に依存関係が複雑になってしまうということもありえますが、その辺はバランスを見ながらの設計が必要ですね。

VSCode からFunction

前置きが長くなりましたが、Functionsを作成するときはVSCodeを使うと便利です。ローカルデバッグからデプロイまで全てVSCodeで完結できます。

learn.microsoft.com

コマンドを打つことなくAzureの環境にデプロイができます。便利ですね。なんならリソースグループ作ったりするのもVSCodeで出来てしまうので、Azure のportalでポチポチやる必要がなくなります。意外とVSCodeとportal画面を切り替えるのってストレスなんですよね。。
検証などでFunctionsを使用したい場合、このドキュメントのデプロイで十分だと思います。
しかし、例えば本番運用する前にステージ環境でFunctionsのテストをしたい場合もあると思います。というより、きちんと運用するならしないと。
ちなみに、App Serviceの場合、デプロイスロットという機能を使ってステージ環境と本番環境を容易に切り分けることができます。

learn.microsoft.com

これ、Functionsでも同様のことが出来ると分かりました。

learn.microsoft.com

スワップ操作は便利なので、早速ステージスロットを作成してローカルで作成したFunctionをステージ環境にデプロイしようとしました。
しかし、VSCodeからステージ環境にデプロイってどうやるんだと思い調べた結果です。

調査

実は、上記のデプロイチュートリアルの方法でデプロイすると、運用スロット(デフォルトで作られているスロット)に自動でデプロイされてしまいます。 しかし、Azureサイドバーからから作成したスロットにデプロイできます。

いたせり尽せりのVSCode。

終わりに

FunctionsにデプロイをするにはGtHubからでもできます。この辺はApp Serviceと一緒です。CD環境を構築したい場合はGItHubを使用してデプロイする方がいいと思います。GitHub Actions のfileも自動で作ってくれますしね。
サーバレスの場合って、この辺のCI/CDのベストプラクティスは気になるところです。いろんな人のブログ読んでいこう。
ちなみに、今回言及したようにApp ServiceやFunctionsにおいて、ステージ環境から運用環境にデプロイするにはスワップという機能が便利なのですが、これはまた別の機会にAzureが提唱するデプロイのベストプラクティスという形で記事にまとめようと思います。

ManagedID でAzure PostgreSqlにアクセスする

Azure 技術 JS

はじめに

masamoriです。今年はもうちょっと記事書きたいです。

Azure FunctionsからDBに接続したい場合(クエリを発行したい場合)、シークレットの扱いが面倒だったりします。Key Vault使うのか環境変数ファイル用意するか。
ファイルを用意するのは正直面倒なので、Functionsの構成にシークレットを埋め込んで、それを呼び出すのもアリです。 しかし、それも面倒だったりするので、特に外部のDBを使う必要がなければ、Azure でDBを立ててマネージドIDを使うとシークレットの呼び出しする必要ないので、手間が減ります。(ただし、マネージドIDについて理解するには時間がかかる。) マネージドIDの説明はこちらが詳しいです。

tech-lab.sios.jp

Azure Functions とAzure PostgrSqlを接続することにしたので、マネージドIDを使うことにしました。 しかし、これが意外に上手くいかず少しハマりました。
なので、そのエラーと解決法の共有をします。

準備

まずは、FunctionsのマネージドIDをONにします。 そして、IAMでFunctionsに対して「共同作成者」のロールを付与しました。 次にコードを書きます。 参考にしたコード例は以下のサイトから得られたこちら learn.microsoft.com

import { DefaultAzureCredential, ClientSecretCredential } from "@azure/identity";
const { Client } = require('pg');

// Uncomment the following lines according to the authentication type.  
// For system-assigned identity.
// const credential = new DefaultAzureCredential();

// For user-assigned identity.
// const clientId = process.env.AZURE_POSTGRESQL_CLIENTID;
// const credential = new DefaultAzureCredential({
//     managedIdentityClientId: clientId
// });

// Acquire the access token.
var accessToken = await credential.getToken('https://ossrdbms-aad.database.windows.net/.default');

// Use the token and the connection information from the environment variables added by Service Connector to establish the connection.
(async () => {
const client = new Client({
    host: process.env.AZURE_POSTGRESQL_HOST,
    user: process.env.AZURE_POSTGRESQL_USER,
    password: accesstoken.token,
    database: process.env.AZURE_POSTGRESQL_DATABASE,
    port: Number(process.env.AZURE_POSTGRESQL_PORT) ,
    ssl: process.env.AZURE_POSTGRESQL_SSL
});
await client.connect();

await client.end();
})();

こちらはApp Serviceのチュートリアルですが、Functionでも基本的には同じです。 マネージドIDを使用してDBに接続を試みる場合、上記の「AZURE_POSTGRESQL_USER」は最初にDBを作成した際に設定したユーザーじゃないです。マネージドIDのオブジェクト名にします。今回は、Functionsの名前です。

実行とエラー

さて、とりあえずローカルの環境で接続テストをしてみました。すると、以下のエラーが発生。

error: password authentication failed for user "<ユーザー名>" at Parser.parseErrorMessage.
どうやら認証に失敗した様子。おかしいな。マネージドIDを設定したはずなのに、IAMのロール割り当てが間違っていたか？ ところが、「管理者」権限を割り当てても解決しません。

解決法

ということは、他の認証が必要ということですね。ググってみたら、解決に役立ちそうな記事がありました。 qiita.com

なるほど、この認証が必要なんですね。 そして、この画面下にある「Microsoft Entra 管理者の追加」でFunctinosのマネージドIDを設定したら、接続に成功しました。

まとめ

DBと接続したい場合は、「認証」をRBACとは別に設定する必要があります。ということは、この「認証」はDB特有の設定なのでしょうか？
ちなみに、「管理者」「共同作成者」を外してもDBに接続できました。この「認証」を次の記事あたりで深掘りしてみたいですね。

また、踏み台サーバーなどからDBに通常アクセスしたい場合は、最初に設定したユーザー名とパスワードでアクセスしましょう。

Azure DefaultAzureCredential() 認証についてのお話

Azure 技術

はじめに

どうも、masamoriです。しば犬って可愛いですよね。小紅書でしば犬ばっかり見てたら、タイムラインとレコメンドがしば犬ばっかりになって幸せです。
さて、今回はAzureの認証について調べたことについて書きます。

Azure Function を使ってKey Vaultにアクセスしようとする時、MSの推奨としてはマネージドIDを使うことになっています。
というより、Azureのリソース間で認証を行うときはマネージドIDが便利でセキュアです。なぜなら、コードにシークレットを埋め込む必要がなくなるからです。(.envとか使っていても、埋め込んでることにはなる。) ちなみに、マネージドIDって何？って方は、こちらの記事を見ると分かりやすいです。 tech-lab.sios.jp

マネージドIDを使用して、Entra IDから資格情報を得るときに使うメソッドが. DefaultAzureCredential().
です。

Functionをローカルで開発していて上手くいっていたのに、デプロイしてFiunctionを動かしてみるとKey Vaultの認証で弾かれてしまうことがありました。 というわけで、この原因を調べるべくDefaultAzureCredential()について少し深掘りをしてみました。

そもそも

DefaultAzureCredential()の定義はこちらです。

learn.microsoft.com

これが有効になっている場合、ドキュメントに書かれているCredentialの上から順番に試されていくんですね。なので、環境によっては違うCredentialが読み込まれることも十分にあり得るわけです。

そして、次にこちらの記事

learn.microsoft.com

これはApp ServiceからDBに接続するチュートリアルになりますが、注目する部分はここ

DefaultAzureCredential は、開発環境と Azure 環境の両方に適応できるだけの柔軟性を備えています。 ローカルで実行しているとき、任意の環境 (Visual Studio、Visual Studio Code、Azure CLI、Azure PowerShell) からログインしている Azure ユーザーを取得できます。 Azure で実行しているとき、マネージド ID が取得されます。 そのため、開発時と運用時の両方でデータベースへの接続が可能です。

コード実行の裏側で、こういうことが行われているんですね。
これ別の解釈すると、「環境によって取得するCredentialは違うから、気をつけて開発してね」っていうことなんだと思います。
ローカルとデプロイ環境だと当然環境も違うので、取得するCredentialが異なる。その結果、ローカルで動かした時に認証が上手くいっていても、デプロイ環境の設定(マネージドIDの設定やマネージドIDへの権限付与)が上手くいっていない場合、デプロイするとアプリケーションが動かない場合があるということです。

僕のケースでは、ローカル環境でaz account showと打つと、自分のアカウントが出てきたので、AzureCLIにサインインしている状態です。
なので、認証としては"DefaultAzureCliCredential"が使われている可能性が高いです。そして、デプロイした場合"DefaultManagedIdentityCredential"が認証として読み込まれる優先順位が高いので、ManagedIDが設定されていなかったので、Functionの実行に失敗したという感じでしょうか。

あれ？そうなると、デプロイした環境だと"DefaultAzureCliCredential"は読み込まれないんでしょうか？挙動を見るとそうなりますよね。つまり、デプロイした環境(Azure環境)ではAzureCLI環境は読み込まれず、環境変数やマネージドIDを使って認証をすることになります。この辺、やや複雑ですね。間違っていたらご指摘ください。

というわけで

Functionを使ってAzureの各リソースにアクセスしたい場合、まずはFunctionのマネージドIDをオンにして、各リソースにそのマネージドIDに対して適切な権限を割り振りましょう。ユーザーに割り振ってしまうと、アプリケーションの想定する挙動とは異なると思います。
冒頭のKey Vaultにアクセスできない問題は、Key Vaultに対してユーザーにはシークレットの読み取り権限が設定されていたにも関わらず、FunctionのマネージドIDには割り振られていなかったんですね。 なので、全く同じコードでも動かなかったと。
というわけで、マネージドIDに権限を割り振ったら解消しました。

終わりに

認証周りは結構複雑になりがちです。ドキュメント通りに実装して他のAzureリソースにアクセスできない場合、認証を見直してみましょう。
個人的には認証周りはややこしいなーと思っています。 マネージドIDとかサービスプリンシパルとか、そもそもEntra IDってなんなの？みたいな。

マネージドID、サービスプリンシパルについてもいずれ記事にしてみたいと思います。
いつになるか分かりませんが。

Azure Key Vaultを使ってFirebase Authのユーザー情報を取り出す②Functionのプロジェクトを作成する

Azure 技術 JS

はじめに

masamoriです。 Youtubeのディスカバリーチャンネルの「ベーリング海のカニ漁」シリーズにすっかりハマっています。日本語の字幕付きなので英語の学習にもなるよなー、と思っていたんですが、めちゃくちゃピー音が入っていて何言ってるかよくわかんないシーンも多々あります。さすが荒くれ者の集まりで、すぐに興奮して放送禁止用語を連発しているんですね。あのチャンネルお勧めです。カニ食べる時にめちゃくちゃ感謝すること間違いなしです。簡単にマズイって言っちゃダメです。残すなんて言語道断。
さて、時間が経ってしまいましたが前回の記事の続きです。 今回は実際にコードを書いて、Firebase Authentication に登録されているユーザー情報を取り出して表示してみたいと思います。 なおデプロイに関しては次回記事で書きます。

おさらい

Firebase Authenticationに登録しているユーザーをAzure FunctionのHTTPトリガーで取り出し、Azure Postgresql フレキシサーバーに格納します。前回はFirebase にアクセスするために必要なシークレットをKey Vaultに格納するところまでやりましたね。

準備

VSCodeを使ってFunctionを作成します。基本的なやり方はこちらの公式ドキュメントに書いてあります。

learn.microsoft.com

JSを使って書いていきます。というわけで事前に必要なものは以下の通りです。

実行

まずは適当な空のディレクトリを作成します。そしてVSCodeを開きます。 ここを押して、「Azure」を選択します。 Azureのサイドバーが現れるので、WORKSPACEのLocalにポインターを当てると雷みたいなマークが出てくるので、そこをクリック。プロジェクトを作成します。 そうするとVSCode上部に、Fuctionの詳細を選択するメニューが現れるのでJSを選択。 そのあとは基本的にデフォルトのままで選択し続けましょう。HTTP trigerを使います。 一点注意としては、v3とv4で書き方が大きく変わりました。この辺の詳細はこちらのブログが詳しいです。 blog.shibayan.jp

以上の手順を踏むと、

こんな感じでプロジェクトができていますね。 では、これを実際に動かしてみましょう。 サイドバーのデバッグを選択します。虫っぽいやつです。そして実行しましょう。

そうするとポップアップが出てくるので、Use Local Emulatorを選択します。

そして、Debug Anywayを選択。そうすると、ターミナルにURLが現れますね。このURLにアクセスします。

Hello world!がブラウザに出てきます。

このコードを見てみると、どうやらGETで指定した文字列をブラウザに映し、指定がなかったらworldを映す、という挙動になっています。

const name = request.query.get('name') || await request.text() || 'world';

というわけでURLに ?name=masamori と付け加えます。これでリロードすると

はい、変わっていますね。とりあえず、無事にHTTPTrigerのFunctionプロジェクトの雛形ができました。

次回

次回はこの雛形をベースにKeyVaultにアクセスするところまでやります。 ちょっとややこしいAzureの認証の話も出てきます。 今回はここまでです。

Azure Key Vaultを使ってFirebase Authのユーザー情報を取り出す① Key Vaultにシークレット情報を保管する

Azure 技術

はじめに

どうもmasamoriです。
突然ですが、流しそうめんって知ってます？夕方のニュースでたまに夏の風物詩として流れてくるあれです。
家族で参加して「わー、取れなかったー！」「まぁ、次は取れるといいわね！」「うん！」なんて、微笑ましい光景が脳裏に浮かんだ方も多いのではないのでしょうか？

実は数年前、友人と流しそうめんに参加したことあるんですが、あれ、急にそうめんが流れてくるのでおちおち喋っていられないんですよね。話が盛り上がったらいきなりそうめんが、シャー！って流れてくるんで、もう神経を尖らせなければ参加できません。HUNTER x HUNTERの円を使わないとあれ食べれないんじゃないか、と思うぐらいシビアです。
結局円を使えない僕は一本もそうめんを食べれずに流しそうめんの料金だけ払ってやったぜ〜。ワイルドだろぉ〜？

さて、Firebase Authenticationを使用して認証に使っている方もいると思います。手軽にソーシャル認証も実装できるので、自分もプライベートで使用するときもあります。
ただ、Firebase Authenticationにはデフォルトでユーザー情報の自動バックアップ機能がついてないんですね。これを実装するには、Firebase内の他のサービスを使う必要があります。　　　

firebase.google.com

Firebaseの中にはプランがあって、無料のSparkプランではFirebase Realtime Databaseで自動バックアップ機能を使えないんですよね。従量課金プランBlazeプランなら使えるそうです。
さて、ここで従量課金するのはどうかなぁと考え、それならクレジットが残っているAzureに自動バックアップできる構成を組んじゃえばいいのでは？と思い立ち、構成を考えて実装することにしました。なお、勉強を兼ねてのアウトプットなので、間違ってることも多々あるかと思いますが、そこはお手柔らかに。。

構成と使用するサービス

さて、今回の構成を超シンプルに描いてみます。

使用するAzureのサービス.

  • VNet
  • Postgresql for Azure
  • サービスエンドポイント
  • Azure Function
  • Key Vault

VNetの中にサブネットを切って、そこにDBを置き、サービスエンドポイントを使ってDBとの通信をするようにします。Azure Functionに、Firebase Authentication からユーザー情報を取得しDBに保管するPythonのスクリプトファイルを置きます。なお、Firebaseとのやりとりの際に、Firebase AuthのSDKとserviceAccountKey.jsonが必要になります。(serviceAccountKey.jsonの取得の仕方は記事がたくさんあるので、方法はそちらを参照してください。)

秘密情報の取り扱い

さて、Firebase AuthのSDKを用いてローカル環境でFirebase Authenticationに登録してあるユーザーを取得するのは結構簡単です。serviceAccountKey.jsonを適切なディレクトリに配置して、スクリプトを書くだけです。しかしこれをデプロイするとなると話は別で、serviceAccountKey.jsonをどのように取り扱うかがまず一つのポイントになると思います。このような秘密情報を取り扱う方法はいくつかありますが、今回はAzure のKeyVaultサービスを使いたいと思います。 azure.microsoft.com

ちなみに、chatGPTにserviceAccountKey.jsonをそのままGithubにデプロイしたらどうなるか聞いてみました。

いい感じにヨイショしてくれて叱ってくれました。chatGPT優秀！！！

KeyVaultの使い方

Azure KeyVaultに格納できるオブジェクトは

  • キー
  • シークレット
  • 証明書

この3点で、今回はシークレットを使います。シークレットは、その名の通りアプリケーションなどのシークレット情報をkey-valueの形で格納できます。今回はserviceAccoutKey.jsonを文字列に変換して一つのvalueとして取り扱い、キーを指定して取り出すときにjsonモジュールを使用してjsonに戻すという形を取りました。

Azure CLIを使ってシークレットを作成する

さて方針が決まったところで、早速対象のjsonファイルをシークレットに格納します。Azure のportal画面からポチポチやってもいいんですが、ここはエンジニアとしてCLIを使って、サラッといきたいところです。ですが、PC内のグローバル環境汚したくないなぁとか、どんなライブラリインストールすればいいんだっけ。みたいなこと考えてたら、全然サラッといきませんでした。
順序としては以下のとおりです。

  1. AzureCLI にログイン
  2. jsonファイルを文字列に変換
  3. KeyVaultを指定して格納

2,3に関するコードはこちら

bash
JSON_DATA='{
  "type": "service_account",
  "project_id": "project",
  ...
  "client_x509_cert_url": "---"
}'

az keyvault secret set --name [シークレットの名前] --vault-name [Key Vaultの名前] --value "$JSON_DATA"

という感じです。 jsonファイルの中身をそのまま文字列に変換しています。シークレットの名前はなんでもOK。
ここで注意。
ログインしているユーザーが、シークレットに対して書き込み権限がない場合はエラーが出ます。なので、対象のシークレットに対して権限が適切に振られているか確認してください。portalから簡単に権限割り振れます。CLIでも多分できるんじゃないかなと思います。

この段階で、シークレット情報が作成されているはず。
上手くいったかどうかはportalでも確認できますし、

bash
az keyvault secret show --name [シークレットの名前] --vault-name [Key Vaultの名前]

これでも確認できます。(シークレットキーの名前のみ確認できて、中身は表示されません。)

続きは...

次回はVSCodeからFunctionを作成します。 続きはこちら

「GitHub dockyardコミュニティ 竣工イベント！」に参加してきました

Github イベント

はじめに

はじめまして、masamoriです。
記念すべき初投稿は「GitHub dockyardコミュニティ 竣工イベント！」

github-dockyard.connpass.com

のイベントレポートです。

僕は、とあるスタートアップで働いているエンジニアで、エンジニアとしては２年目になります。
イベントに参加するのが好きなので、その紹介をしたり、技術的なアウトプットをそろそろしてみたいなと思ってこのブログを立ち上げました。
業務ではPythonを使ってWebアプリを開発していて、最近はクラウドエンジニアとしても活動したくMicrosoft Azureも勉強しています。
なので、技術の話は主にPythonとAzureになるかなぁと思っています。他にも気になる技術があれば紹介するつもりです。

イベント参加のきっかけ

業務でGithubを使っていて、CI/CDもActionsで構築しています。毎日Githubに触れているにも関わらず、あまりGithubについて真剣に勉強したことのないなぁと思い、このコミュニティに参加しました。
コミュニティ参加のきっかけは、主催者の@dzさんとある勉強会で知り合いになりまして、そこでお誘いを頂いたのがきっかけです。
Copilotの登場でGithub界隈が熱く盛り上がってるし、個人的に勉強してみたいし、っていう色んなタイミングが重なって参加をすることにしました。

概要とお品書き

"dockyard"、造船所、船を修理したりメンテナンスをするドックやその設備。

GitHub は開発に欠かせないツールであり、さながら広い宇宙を行き来する旅人らが使う宇宙船のような、この広いテクノロジーの星々を渡り歩くためになくてはならない存在です。

その船のトラブルを修理し整備するために立ち寄る "dockyard"。船だけでなく、一時の休息に、または旅路の情報を求めて立ち寄る旅人たち。彼らは装備を整え、また新たな目的地を目指して旅立つ。

GitHub とともに開発に携わる人たちが、トラブルを解決し、情報を共有し、労いあい、そしてよりよいプロダクトを生み出すために開発に戻っていく、そんな場所を作りたいと思い、この名を付けました。

素晴らしいですよね。 個人的な印象なのですが、Githubの情報って探しにくい印象です。
基本的にはコマンドの解説をしている記事が多く、Githubのリッチな機能を使用している具体例ってあんまり見たり聞いたりする機会ってないなと思ってました。

以下は発表タイトルと、感想をちょこっと書いていきます。みんな素晴らしかった。というより、レベルが高かった。

実演TypeScript + GitHub Copilot 佐々木俊介（erukiti）さん

speakerdeck.com

Github Copilot, 僕も毎日のように使っています。僕の場合は、コメントを書いてCopilotにコードを書かせるというより、ラフなコードを先に書いて後で埋め合わせしてくれるって使い方しています。でも、フロントエンドでJavascript書く時はコメント主導で書いた方が早いのかなーと思いました。
Copilotも優秀ですけど、そもそもerukitiさんのコーディングのスピードが早くて、そっちに驚愕しました。

自称日本一GitHub Projectsを使っているので魅力を伝えたい！小笹佑京（yukiozasa）さん

speakerdeck.com

GitHub Projectsを極限まで使っているなぁと感心しました。よく考えたら、Githubを使わない開発ってもうあんまり考えられなくて、毎日アクセスします。だったらプロジェクト管理ツールもGithubで良くね？っていうのは筋が通ってるし、色んなサービス使わなくても良いっていうのは大賛成です。ポイントはプロジェクトの実態に合わせた利用法にカスタマイズすることだと思いました。弊社でもプロジェクト管理をGithubにしようかなと強く思いました。

最近のGitHub Actionの気になるアップデートの紹介 加瀬健太（Kesin11）さん

www.docswell.com

これはレベルが高かった。。弊社もGithubActionsを使ってデプロイのパイプ作っているんですけど、利用の仕方が深くてただただ感心していました。よくそこまで調べ上げているなぁと。キャッシュ機能は僕も使っていましたが、知らない機能がありすぎて、また、その説明も結構難しかったのでゆっくり理解していきます。（予定）

パワーワード.
ビルドを速くするために重要なことはビルドをしないことである by Kesin11さん.

地味だけど劇的に便利になるリポジトリ設定あれこれ 岩永かづみ（dz_）さん

speakerdeck.com

主催者dzさんの発表。
Githubのtipsが盛りだくさん。すぐに弊社のGithubにも取り入れられそうな機能があったので、早速取り入れました。Branch protection rulesとか、自動でブランチ消える機能とか。ご本人は謙遜していましたが、これぐらいのレベル感でのお話が今の僕にはちょうど良かったのかなぁと思いました。早くSquash merge使ってみたい。

まとめ

総じて、Githubを全く使いこなせていないなぁと実感しました。というより、Githubの開発チームってやっぱりとても優秀で、きちんとエンジニアの目線で何が必要かって分かっていて、開発自体をGithubで完結させる、みたいな意気込みのようなものを今回の発表を通じて感じました。
まぁ、あれですよね、Lv99のミュウツーがジムリーダーバッジ１つのポケモン使いの言うこと聞かないのと同じようなもんで、自分がエンジニアとして成長していくと、Githubの凄さがもっと分かっていくんじゃないかなぁと思いました。

それにしてもとても楽しいイベントでした！
イベント作るのって本当に大変なんですよ。。イベント開催まで漕ぎ着けるのが本当に大変だったんじゃないかなと思いました。僕も、別コミュニティでイベント運営したことがあるので、大変さは分かるつもりです。
なので、運営の皆様にはただただ頭が下がります。僕もできることがあるなら積極的に協力したいなぁと思いました。
運営のみなさんお疲れ様でした！！！

スパムおにぎり美味しかった。