なんでも書く

できる限り記録する

機動戦士ガンダム GフレームFA 09 Ξ(クスィー)ガンダム

食玩のGフレームFAの新作にΞガンダムが追加されたので購入した。

www.bandai.co.jp

79Aの内容物。

ランナーはタッチゲートっぽい。

パーツが小さいので指が痛くなるが普通にもげる。
断面気になるならニッパーやデザインナイフを使うのもありかも。

フレームから外した図。
正確にはもっと外せる箇所があったがパーツの嚙み合わせがしっかりしていて外しにくく断念。

フレーム。  

合わせ目は段落ちモールドになっていて目立たない。

全ての合わせ目が見えなくなっているわけではないが、正面から見える箇所は以下のようにパーツをかぶせることで合わせ目が見えないようになっている。

フロントアーマーは独立稼働する。

腕に関しては、二の腕はパーツをかぶせるだけ、前腕は一部合わせ目が目立つもののパーツ分割が工夫されている。

顔の造形は素晴らしい。 

組み上げたところ。

79Oの内容物。

先ほどの79Aと合わせることでΞガンダムが完成。

79Fの内容物。

フレームなのでランナーが多め。

パーツが小さいので指が痛い。

可動域は非常に素晴らしい(アーマー被せると干渉して動かしにくくなるが)。

ビームライフルとシールドも持たせる。

アーマーがだいぶ干渉するがちゃんと可動する。
非可動フレームはスタンドにもなる。

パーツ差し替えでフライトフォームの再現も可能。

砂漠の背景で劇中っぽく。

初めて見た時の異物感はすごかったが、映画で動いているところ見るうちにめちゃくちゃカッコよく感じた機体。
HG買ってもデカすぎて置くところないなと思っていたので今回GフレームFAでΞガンダムが出て良かった。
全長14cmくらいなのでまだ飾りやすいサイズだと思う。

環境構築メモ: WSLのアップデート

はじめに

普段の個人開発や学習ではWSL上のUbuntuを使っている。
WSLについては初期設定をしてからほぼ触っていなかった。
その間にもWSLのバージョンが上がっており、久しぶりにPCの環境設定周りを見直していたところ、GUIのWSL Settingsが起動できなくなっていたのでWSLのアップデートをしてそのエラーを解消した。

前提

  • 実施時の環境
    Windows 11
    WSL2(2.4.x)
    Ubuntu 24.04

事象

初期設定移行、WSL側は特に何も触った覚えがなかったが、以下のようにWSL Settingsを起動させることができなかった。

WSLのリポジトリを確認したところ、最新のリリースバージョンが2.6.xになっていたため、まずは最新までアップデートしようと思った。

Power Shellで以下のコマンドを実行する。

wsl --update

その後、再度WSL Settingsを起動したところ、無事起動できた。

おわりに

環境設定周りは定期的に見直していきたい。

AZ-204学習メモその3: Azure CLI [az webapp]

はじめに

AZ-204のMicrosoft Learnで実際にAzureを触って動かす演習を実施した際の忘備録その3。
その2は以下から。

kohey94.hateblo.jp

前提

書いた本人は、実務でAzureを利用した開発経験ありだがAzure PoralでのGUI操作が主。
現在AZ-204取得に向けて学習中。
そのため、Azure CLIでの操作初心者、 AZ-204学習者向け。

今回実施した演習

learn.microsoft.com ラーニングパス: Azure App Service Web アプリを実装する
モジュール: Azure App Service デプロイ スロットについて詳しく知る

演習の該当リンクは以下から。

microsoftlearning.github.io

Azure CLIコマンド

az webapp

Web アプリを管理する。
learn.microsoft.com

az webapp up

Web アプリを作成し、ローカル ワークスペースからアプリにコードをデプロイする。

az webapp up -g $resourceGroup -n $appName --sku P0V3 --html

パラメーター

オプション
  • --app-service-environment
    省略形: -e
    デプロイ先の (既存の) App Service Environmentの名前またはリソース ID。
    Isolated V2 SKU が必要。

  • --basic-auth
    ベーシック認証を有効または無効にする。

  • --dryrun
    実際にデプロイせずに、作成されるアプリの概要を表示する。

  • --enable-kudu-warmup
    trueの場合、Linux Webアプリのデプロイを実行する前にkuduがウォームアップされる。

  • --html
    HTMLアプリとしてデプロイする。

  • --ids
    1つ以上のリソースIDを指定する。

  • --launch-browser
    省略形: -b
    既定のブラウザーを使用して、デプロイしたアプリを起動する。

  • --location
    省略形: -l
    リージョンを指定する。

  • --logs
    Webアプリを起動した直後にログ出力を有効にする。

  • --name
    省略形: -n
    Webアプリの名前。
    指定しない場合はランダムに生成される。

  • --os-type
    アプリのOSを指定する。

  • --plan
    省略形: -p
    App Serviceプランを指定する。

  • --resourse-group
    省略形: -g
    リソースグループの名前。

  • --runtime
    省略形: -r
    Framework:Version形式の正規化されたWebランタイム(例: "PHP:7.2")。

  • --sku
    価格レベル。

  • --subscription
    サブスクリプション名またはID。

  • --track-status
    true の場合、デプロイ中のWeb アプリの起動状態は、Linux Webアプリに対して追跡される。

az webapp deployment slot create

デプロイスロットを作成する。

az webapp deployment slot create -n $appName -g $resourceGroup --slot staging

パラメーター

必須
  • --name
    省略形: -n
    Webアプリの名前。

  • --resourse-group
    省略形: -g
    リソースグループの名前。

  • --slot
    省略形: -s
    スロットの名前。

オプション
  • --configuration-source
    構成を複製するソーススロット。

  • --container-image-name
    省略形: -c
    コンテナーのカスタムイメージ名と、必要に応じてタグ名。

  • --container-registry-url
    省略形: -r
    コンテナーレジストリーサーバーのURL。

  • --container-registry-user
    省略形: -u
    コンテナーレジストリーサーバーのユーザー名。

az webapp deploy

指定された成果物をAzure Web Appsにデプロイする。

az webapp deploy -g $resourceGroup -n $appName --src-path ./stagingcode.zip --slot staging

パラメーター

オプション
  • --async
    trueの場合、非同期的にデプロイする。

  • --clean
    trueの場合、デプロイする前にターゲットディレクトリをクリーンアップする。

  • --enable-kudu-warmup
    trueの場合、Linux Webアプリのデプロイを実行する前にkuduがウォームアップされる。

  • --ids
    1つ以上のリソースIDを指定する。

  • --ignore-stack
    trueの場合、スタック固有の既定値は無視される。

  • --name
    省略形: -n
    Webアプリの名前。

  • --resourse-group
    省略形: -g
    リソースグループの名前。

  • --restart
    trueの場合、デプロイ後にWebアプリが再起動する。

  • --slot
    省略形: -s
    スロットの名前

  • --src-path
    デプロイする成果物のパス。

  • --src-url
    デプロイする成果物のURL。
    WebアプリはこのURLから成果物をプルする。

  • --subscription
    サブスクリプション名またはID。

  • --target-path
    成果物をデプロイするパス。
    既定値は"home/site/wwwroot/"。

  • --timeout
    デプロイ操作のタイムアウト。
    "--src-url" を使用する場合は無視される。

  • --track-status
    true の場合、デプロイ中のWeb アプリの起動状態は、Linux Webアプリに対して追跡される。

  • --type
    デプロイされる成果物の種類をオーバーライドするために使用される。

おわりに

az webappはAzure App Service を操作するためのコマンドなため、種類もオプションも多い。
しかし、ざっと見た感じオプションに関しては同じオプションが多く、コマンドも使用頻度に差がありそうなので、使いそうなものを重点的に把握していきたいと思った。

WSLからVisual Studio Codeを起動する

個人的メモ。

kohey94.hateblo.jp

過去に上記の記事通りにvscodeとwslのセットアップをしていた。
この記事によればWSLという拡張機能を入れていればWSL側からvscodeを起動できるとのことだったが、起動できなくなっていた。
調べたところ、Remote Developmentという拡張機能を入れる必要があるらしい。

以下、公式ドキュメント。   learn.microsoft.com

見たところ、WSL拡張機能も含めた必要なものをまとめてインストールしてくれるパックのようなので、これからWSLで開発環境構築する際は「Remote Development」をインストールすればよさそう。

AZ-204学習メモその2: Azure CLI [az role]

はじめに

AZ-204のMicrosoft Learnで実際にAzureを触って動かす演習を実施した際の忘備録その2。
その1は以下から。

kohey94.hateblo.jp

今回実施した演習

learn.microsoft.com ラーニングパス: Blob Storage を使用するソリューションを開発する
モジュール: Azure Blob Storage の使用

演習の該当リンクは以下から。

microsoftlearning.github.io

Azure CLIコマンド

az role

Azure ロールベースのアクセス制御 (Azure RBAC) を管理する。 learn.microsoft.com

az role assignment create

ユーザー、グループ、またはサービス プリンシパルに対して、新しいロール割り当てを作成する。
以下の例は、$userPrincipalに対して$resourceIDのストレージBlobデータ所有者ロールを付与している。

az role assignment create --assignee $userPrincipal \
    --role "Storage Blob Data Owner" \
    --scope $resourceID

本筋からズレるが$userPrincipalと$resourceIDは以下のスクリプトによって取得している。

userPrincipal=$(az rest --method GET --url https://graph.microsoft.com/v1.0/me \
    --headers 'Content-Type=application/json' \
    --query userPrincipalName --output tsv)

resourceID=$(az storage account show --name $accountName \
    --resource-group $resourceGroup \
    --query id --output tsv)

パラメーター

必須
  • --role
    ロール名または ID。

  • --scope
    ロールの割り当てまたは定義が適用されるスコープ。

オプション
  • --assignee
    ユーザー、グループ、またはサービス プリンシパル。

  • --assignee-object-id
    担当者のオブジェクト ID。
    '--assignee' の代わりにこの引数を使用すると、ログインしているアカウントに権限がない場合や、マシンに Microsoft Graph をクエリするためのネットワークアクセスがない場合に、Microsoft Graph クエリをバイパスできる。

  • --assignee-principal-type
    --assignee-object-id と共に使用して、Microsoft Graph の伝達待機時間によって発生するエラーを回避する。

おわりに

az roleはAzureの管理者やクラウドインフラを担当するようになればよく使いそうなコマンドだと思った。
開発者向けの資格であるAZ-204でどれくらい深く出てくるかは分からないが覚えておくべきところだろう。

miseを使ったdotnet環境構築

はじめに

現在Azure資格のAZ-204取得に向けてMS Learnを使って学習している。
その中で実際に手を動かす演習もあるのだが、ローカル環境でプロジェクト作成を求められることもある。
例えば、Azure Functionsについての演習は以下のような感じ。

microsoftlearning.github.io

今まではVisual StudioのGUI頼りにやってきていたが、実際の試験では選択肢問題だけではなく、サービスを作成するための手順を選んだり自分で操作する問題もあるらしい。
そこでCLIでのdotnetやazureの操作に慣れるため、自分のPCにCLIの環境構築をした。

前提

環境はWSL2上のubuntu24.04。
miseインストール済み。
miseのインストールについての記事は以下から。

kohey94.hateblo.jp

.NET SDKのバージョンを確認する

基本は最新のものを入れればいいと思うが、バージョンを選んで入れたい場合は以下のコマンドを実行してバージョンを確認する。

mise ls-remote dotnet-core

インストールする

前回miseを使ったときに勘違いしていたこととして、mise installだと指定verをインストールするだけで、それを有効化するにはmise use(グローバルで有効化するには-gもつける)が必要だった。

kohey94.hateblo.jp

mise useをすれば未インストールならインストールをし、有効化してくれるので単に以下のコマンドを実行する。

mise use -g dotnet-core@10.0.103

以下のコマンドでインストール済みのバージョンを確認できる(すでに8をインストール済みだったので8も表示されている)。

mise ls dotnet-core

これでdotnetの環境構築が完了した。

dotnet --version

おわりに

Windowsでdotnet開発する場合はVisual Studioをインストールするのが一番楽ではあるが、Windows以外のOSだったりWSLに環境構築する場合は.NET CLIをインストールすることになると思う。
その際にもmiseを使って環境構築するのが簡単で楽だと感じた。

AZ-204学習メモ: Azure CLI

はじめに

AZ-204のMicrosoft Learnで実際にAzureを触って動かす演習を実施した際の忘備録。

今回実施した演習

learn.microsoft.com
メッセージベースのソリューションを開発するというラーニングパスで、その中でDevelop solutions for Microsoft Azureというリンクの、Send and receive messages from Azure Queue storageとSend and receive messages from Azure Service Busを実施した。

microsoftlearning.github.io

microsoftlearning.github.io

Azure CLI

learn.microsoft.com 演習では基本的にAzure CLIを使ってリソースの作成を行っていく。
コマンドは「az」で始まる。

az group

リソースグループとテンプレートのデプロイを管理する。 learn.microsoft.com

az storage account

ストレージアカウントを管理する。 learn.microsoft.com

az rest

Azure用のcurl。
learn.microsoft.com

Microsoft Graph APIを叩く場合はaz restを使うほうが楽。

# curlの場合
# Azureからアクセストークンを取得
token=$(az account get-access-token --resource-type ms-graph --query accessToken --output tsv)
# curlを叩く
curl -X GET https://graph.microsoft.com/v1.0/me \
     -H "Authorization: Bearer $token" \
     -H "Content-Type: application/json"

# az restの場合
# ログイン済みならこれで叩ける
az rest --method GET --url https://graph.microsoft.com/v1.0/me

--query

azコマンドのオプション。jqっぽく使える。
以下のようにユーザー情報からuserPrincipalNameのみ取得するときなどに使える。

userPrincipal=$(az rest --method GET --url https://graph.microsoft.com/v1.0/me \
    --headers 'Content-Type=application/json' \
    --query userPrincipalName --output tsv)

JMESPathというクエリ言語らしい。
learn.microsoft.com

おわりに

Microsoft公式が演習用意してくれるのはありがたい。 試験でもリソース作ったり、コード書いたりする問題もあるらしいので手を動かして覚えていこうと思う。

Googleドライブから完全削除したファイルを復元する

スマホのデータ整理をしており、Googleドライブの容量に空きはあるものの不要ファイルを削除したくなったので、その流れでGoogle Oneストレージ管理ツールで不要データを削除していた。

その際に誤って削除してはいけないファイルを削除してしまった。
以下のダイアログが表示されるのだが完全に削除した後に、「あれ削除しちゃいけないやつだったわ」と思い出し、後の祭りに。
もちろんゴミ箱にはない。

ビジネスアカウントであれば連絡すれば復元できそうだが、個人アカウントなのでまあ無理だろうなと思いつつ助けてGeminiマンをしたところ、ファイルの復元リクエストができるらしい。

というわけでGoogleドライブの[ヘルプとフィードバック]>[Googleドライブで削除したファイルを復元する]と進み、

[ファイルの復元リクエストをする]を選択する。

ブラウザが開き本人確認をしてログインする。
Googleドライブ内にファイルが残っていないか確認する手順もあるが、ドライブから完全削除しているため、いいえを選択して[次へ進む]を選択する。

復元できるファイルは過去25日以内のGoogleドライブから削除されたファイルのみ。
他にも復元できる条件はあるが今回は特に問題ないため、そのままファイルの復元をリクエストする。

リクエスト完了後はメールが来るのを待つ。

しばらく経ったらメールが来たので、削除前のドライブを見に行くとファイルが復元されていた。

ありがとうGoolge、ありがとうGemini。

IoT初心者のためのM5StickC Plus2を使った開発入門

はじめに

私は現在業務でも個人でももっぱらWebアプリ開発をしている。
しかし学生時代にはハードよりのプログラミングも多少していた。
そのため今になってもハードウェアも使ってIoTをしたいと思うことがよくあり、今回は手軽に扱えるM5シリーズのデバイスを使ってみようと思う。

対象

IoT初心者。
LinuxでM5シリーズを使った開発をしたい人。

前提

OS: Ubuntu 24.04.2 LTS + KDE Plasma 5.27.12

購入したもの

以下の2つをスイッチサイエンスで購入。 今回はM5StickC Plus2のみ使用した。
M5StickC Plus2 ¥4,455
M5Stack用温湿度気圧センサユニット Ver.4(ENV Ⅳ) ¥1,056

M5StickC Plus2www.switch-science.com

M5Stack用温湿度気圧センサユニット Ver.4(ENV Ⅳ)--在庫限りwww.switch-science.com

環境構築

Arduino IDEのインストール

公式サイトからLinux向けのZipファイルをダウンロード。

.arduinoディレクトリにダウンロードした。

chmodで読み取りと実行権限を付与する。

起動しようとしたところエラー。

上記のエラーは--no-sandboxオプションをつけることで回避。

エラー解消の参考にしたサイト。
askubuntu.com www.indoorcorgielec.com

Arduino IDEの環境構築

M5Stackの公式ドキュメントを参考に環境構築を行う。
docs.m5stack.com

Arduinoボード管理の設定をする。

  1. 下の M5Stack ボード管理 URL を Additional Board Manager URLs にをコピーして保存します。
    https://static-cdn.m5stack.com/resource/arduino/package_m5stack_index.json

ライブラリマネージャーからM5StickC Plus2の開発ボードをインストールする。
ライブラリのアイコンをクリックして検索して該当のものをインストール。

依存関係のあるライブラリもインストールする。

プログラムを動かす

docs.m5stack.com

開発ボードの選択

Tools>Board>M5Stack>M5StickCPlus2を選択する。

ポートの選択

Tools>Port>/dev/ttyACM0を選択する。

Hello Worldする

以下のコードを書き込み、右上のUploadボタンを押して実行する。

void setup() {
    M5.begin();
    M5.Lcd.print("Hello, M5StickC Plus2");
}

void loop() {
  // put your main code here, to run repeatedly:

}

実行したところ。

サンプルプログラムを実行する

File>M5StickCPlus2>Basic>batteryを選択する。

左上のUploadボタンを押して実行する。

実行したところ。

おわりに

Arduino IDEで環境構築をして、M5StickC Plus2でプログラムを実行させるところまでできた。
M5Stackシリーズは買ってすぐにプログラミングができるように取り扱いやすいハードウェアだし、チュートリアルやサンプルプログラムも豊富にあるのでIoT初心者に非常におすすめだと思った。
次は一緒に購入した温湿度センサーを使ってみたいと思う。

「誰にも読まれなくても書き続けられる仕組み」──LAPRASのAIレビューを活用してみた

はじめに

この記事では、ブログ等のアウトプットを継続的に行うために自分がどんなものを使っているかを紹介したいと思います。

対象読者

IT分野に関わりのある人(LAPRASというサービスを利用するため)。
技術的なアウトプットをしたいがなかなか継続できない人。
書いたはいいものの書きっぱなしになっている人。
自分を定量的に振り返りたい人。

ここで説明しないこと

LAPRASの登録方法などの細かい説明やAIレビュー機能以外の説明。

本編

なぜアウトプットを続けにくいのか

学習を進める上でアウトプットが大事だと言われます。
アウトプットを続けるにはどうすればいいのか。
そのひとつに「誰かに見てもらう」ことがあると思います。
誰かに見てもらい、反応があることで改善のヒントが得られ、やりがいも生まれ、質も高まっていくと考えられるからです。
しかし現実はどうでしょうか。
始めたばかりのブログに読者がつく保証はありませんし、SNSに投稿しても何の反応も返ってこないこともあります。
理想を言えば、禅問答のように反応など求めず、ひたすら書き続けられればいい。
ですが、それを継続できる人はそう多くはないと思います。
少なくとも自分はなかなか継続できませんでした。

続けるために必要なのは「反応」だった

そんな状況でも、自分のアウトプットに必ず反応してくれる存在があります。
それがAIです。
ChatGPTのような生成AIに記事を読ませてレビューさせるという方法もあります。
プロンプトを作り込み、自分専用のレビュワーAIを作ることも可能です。
ただ、そこまでの仕組みを自作するのはそれなりに手間も知識もかかります。
もう少し手軽に、かつ継続的に使える「反応」が欲しい。
そう考えていた自分にとってちょうどよかったのが、LAPRASのAIレビュー機能でした。

補足: LAPRASとは

LAPRASとは、ブログやSNSなどのアウトプットをAIが分析して技術力や市場価値をスコア化できるWebサービスです。
企業からのスカウト機能もあり転職活動にも活用できますが今回は割愛。 lapras.com

LAPRASのAIレビューとは

LAPRASのAIレビューとは、自分の技術記事をアップロードすることで、AIが内容を分析し、「論理性」「実用性」「読みやすさ」「独自性」「明確性」 という5つの観点から5点満点でスコア化してくれる機能です。
また、単なる点数だけでなく、それぞれの観点で改善点や全体講評もフィードバックしてくれます。
利用にはLAPRASのアカウント登録が必要ですが、無料で使えるのがありがたいです。

スコアとフィードバックで記事を改善した実例

以下は自分のAIレビューのキャプチャです。
自分が書いた技術記事の一覧と、それらについての総合評価が表示されています。
最近の3~4記事は、AIレビューのフィードバックを確認し、改善点を意識して書いたため、スコアが上昇傾向にあります。

クリックするとその記事のレビュー詳細を見ることができます。
「【mise use -gをしろ】miseでnodeインストールしたのにnodeが使えない事象の解消」についてのレビューを確認したいと思います。
記事は以下から。
kohey94.hateblo.jp レビュー詳細は以下です。

これにより自分の記事の良い点と改善点を可視化することができます。
自分はこれを読み一通り満足感に浸ったあと、評価3.5の論理性と明確性の改善点を確認しました。
論理性については、節の必要性や関連性が不明確であること、
明確性については、読者の技術レベルや前提知識の配慮が不足であること、
があげられました。

次の記事ではこの点を意識して書きました。
書いた記事は「Ubuntuでセットアップ時以外のネットワークが認識しないときの対処方法」です。
記事は以下から。
kohey94.hateblo.jp レビュー詳細は以下です。

前回の改善点として意識した項目については、論理性:4.5、明確性4.0とどちらも改善することができました。
総合評価も3.8から4.2と上昇しました。

このように自分が書いた記事が数値化され、どこが良くてどこが改善点なのかを確認できるようになるため、「振り返って修正する」というアウトプットの循環が生まれました。

なぜAIレビューは自分に合っていたのか

それは、昔から「自分を客観的に数値化して振り返る」ことが好きだったからです。
これまでにも、LAPRAS以外にもFindyやForkwell(※現在はGitスコア分析は廃止)などの、スコア可視化系のサービスもよく使ってきました。
自分がどう変化したのか、何が得意で何が足りないのか、それを数字として眺めるのが単純に面白いし、次に取るべき行動のヒントにもなります。
だからこのAIレビュー機能も、自分の性格やスタイルに非常によく合っていたのだと思います。

こんな人にLAPRASのAIレビューは向いている

LAPRASのAIレビューは、文章の添削サービスではありません。
継続的にアウトプットするための反応装置であり、定量的に振り返るためのレンズです。
だからこそ、以下のような人にこそおすすめできると思います。
・ブログを書いても続かない
・書きっぱなしになっている
・フィードバックがなくてモチベが湧かない
・自分を定量的に振り返りたい

おわりに

アウトプットを続けるのは難しいです。
それを可能にするための仕組みが「反応」であり、「振り返り」であり、「意味づけ」だと思います。
たとえ誰にも読まれていなくても、AIが反応してくれる。
自分の成長や変化を数字で教えてくれる。
その仕組みがあるだけで、書くことは継続しやすくなります。
LAPRASのAIレビューは、その入り口としてとても良いものだと思います。
自分も引き続き活用していこうと思います。 ぜひ試してみてください。