恥ずかしながら今更Codexを触ったけど外出先でスマホからでも簡単に開発が出来ちゃった話(2026年3月23日)

最近家でまとまった時間取れなくて環境整えるの面倒だしなぁ~と思っていたのが触ってなかった理由。
結論、環境を整える必要なんてほとんどなかった。
Codexはブラウザから操作できるしCodexとGitHubの連携しちゃえば下記の手順でスマホから開発が出来ちゃう。

  • ブラウザでGitHubにリポジトリを作成する
  • CodexからGitHubのリポジトリを指定してプロンプトを投げる
  • コードが生成されるのでCodexからPRを作成させる
  • GitHub側でPRをマージする

Vercelみたいなサービスと連携している場合、これだけで自動で環境反映できちゃう。
ここまで簡単だとは……出先からでも気軽に修正投げさせられて捗りますね、これは。
ChatGPT ProだとCodexをアプリから操作できるらしいのだけれどもProはちょっとお値段的に……。追記参照
もっといろんなこと試したいし、作ったアプリも汎用性が高まったら公開してみようかな。

2026年3月29日追記
軽く調べた範囲ではPlusではできないってあったんだけど、アプリ見たらCodexの欄があった。
一度Webから触るとアプリから使えるようになる仕組みらしい。
ちなみに、iOS版のアプリのみでAndroid版はまだ対応してないみたい。

Vue.js触ってみたメモ(作業日:2023年11月26日)

中身は空っぽです。悪しからず。

なんでVue?

オワコン説も流れてるけどあれこれ悩むより有名どころ色々触ってみれば?って気持ちになってきたので。
あと、少人数・小規模に向いているって話も見かけたので最初に触るのにちょうどいいかなって。

チュートリアル

Tutorial | Vue.js https://ja.vuejs.org/tutorial/#step-1
解説と設問があってその場で試せるのいいですね。

nvmインストール

Releases · coreybutler/nvm-windows https://github.com/coreybutler/nvm-windows/releases
Node.jsの古いバージョンが入ってたので複数バージョン使えるように念のため。
nvm で複数の Node.js バージョンを切り替えて使用する (Node Version Manager) - まくまくNode.jsノート https://maku77.github.io/nodejs/env/nvm.html

クイックスタート

プロジェクトの作成から実行まで。

感想

びっくりするくらいサクッと入門できますね。もちろん、学んだ方がいいこと覚えたほうがいいことはもっとたくさんあるんでしょうけれども。

サーバサイドがメインの人のための宣言的UI

フロントエンド界隈を眺めているとたまに見かける宣言的UIという言葉。
なんだろう?と思ったので調べて自分の言葉で説明してみた。

宣言的UIとは……

宣言的UIが何か分からなかったので調べてみた
https://zenn.dev/arei/articles/f59e263aa3edf2
大変わかりやすくまとめられていました。
サーバサイド視点から見るとこれって……?と疑問の浮かぶ点がいくつかあるので追加で調べて考えてみた次第です。

.NETに明るい人向け

上の記事を読んだら頭に浮かんだ人もいると思いますが……私はXAMLじゃん!ってなりました。
XAMLの定義を調べてみたところ「宣言型マークアップ言語」とのこと。
XAMLも宣言的UIなのだと理解してよさそうです。

上記以外の人

.NETなんて知らないよという人や、.NETは使ってるけどXAMLは……という人向け。
読んでいて、サーバサイドの経験がある人はCGIJSP、aspx(今ならRazorかな……)を思い浮かべた人も多いのではないでしょうか?
私はその感覚は正しいと思います。

古のCGIServletでは文字列をHTMLの形式で結合するプログラムコードを書いてそれをHTTPレスポンスとして返却するようなコードを書いていました。
ただ、それだと出来上がりのHTMLが想像しにくいのでそれらを解消するために生まれたのがJSPだとかHTMLにPHPのコードを埋め込んだりとかするようになったと。
その流れがフロントエンド界隈にも来たということなのかなと。

ただ、CGIJSPにはなかった要素としてUIとオブジェクトを紐づけ(バインディング)してUIを操作した時に決められた動作をするだとかオブジェクトの値が変わったらUIにも反映されるだとか言ったものがあります。
CGIJSPは基本的にサーバでHTMLを生成して返却する仕組みなのでないのは当たり前かもしれません。(完全に皆無だったかと言われるとASP.NETはクライアントの操作でHTMLを再生成させるようなものがあったような気はしますが……主流とは言い難かったと思います。)
と、いうことでサーバサイドな人としてはCGIやらJSPのようにHTMLベースでUIを表現することがクライアントでもできるようになって、さらにそのUI操作とクライアントサイドのコードとも紐づけられるようになったぐらいの理解をするとよいと思います。

本当のことを言うとUIのコンポーネント化だとかMVVMとの関連性とかその先の発展があるような気はしていますが導入としてはこんなところでよいのではと感じます。

deta.shに登録してみた@Windows (作業日:2022/09/25)

data.shを登録するきっかけからアプリ動作確認までを書く予定。
作業日に年月を書いたのはこの手の登録・構築系作業は時がたつと手順が変わっていることがあり、ググった時に正しい更新日時が表示されるわけでもないので明記することにした。
今後もこの手の記事には付けようと思う。忘れてなければ。

使おうと思ったキッカケ

色んな事情によりサクッとWebサービス作れる環境ないかなと前から思っていてよし作るかという気分が来た。
ちょっと前にHerokuに登録してみて使ってみようかなと思ったまましばらく時がたち……気づいたら無料枠終了のお知らせ。
ということで、代わりになるサービスを探していたら以下の二つを見つけた。

Herokuの無料枠が廃止になるのでDeta.shへ移行する - Qiita
https://qiita.com/namachan/items/b8c1ee89dc091d656d4f
Deta.shの無料枠が廃止になったらCyclic.shへ移行する - Qiita
https://qiita.com/relu/items/b60330ea3137f2f745c5

Cyclic.shの方が出来ることは多そうだったんだけれども、以下の理由からDeta.shにした

  • お試し的に使いたいだけだった
  • Cyclic.shは上位プランもあることからHerokuみたいになることもあり得ると感じた
  • 開発者向けでありエンタープライズ向けではないという点に惹かれた

まぁ、別サービスのマネタイズ失敗したわっていってサービス終了する可能性もあるんだけど無料だしその時はその時ということで。

構築作業

基本的には下記のページを参考に実施。
Getting Started | Deta Docs
https://docs.deta.sh/docs/micros/getting_started/

  • 登録は特に難しい手順はなかったので割愛。
iwr https://get.deta.dev/cli.ps1 -useb | iex
  • ログイン
deta login

このコマンドを実行するとブラウザで画面が開く。開いたブラウザでログイン済みだとそのまま認証される模様。恐らくログイン未済だとここでログインが求められると思われる。
Webシールドが有効だとダメな場合があるのでその手の拡張機能やブラウザ使ってる人は一時的に機能を切らないとダメかも。
私はエラーが出たのでそのページだけ一時的にオフにしたらイケた。

  • アプリの実行環境(DetaではMicroと呼ぶ)を作成
deta new --node deta-test

「--node」はnode.jsを使用の意味。現状だとnode.js14.*が使用される。
実行すると「Successfully created a new micro」というメッセージとJSONデータが出力される。
この時のJSONデータのendpointはアプリへのアクセスに使用される。
他には下記が指定できる。「--node」や「--python」を指定すると使用できる範囲の最新が使用され、「--runtime ~」でバージョン指定ができる。

Python: python3.7, python3.8, python3.9
Node: nodejs12, nodejs14
  • 依存関係のインストール

Microの作成でつけた名前のフォルダが作成されているのでそのフォルダに移動し、npmの初期化を行う。
この際、インストール済みのnpmが古いとバージョンアップを勧められる。とりあえず上げといた。

npm install -g npm
npm init -y
npm install express
  • デプロイ
deta deploy

Micro作成時に表示されたendpointにブラウザからアクセスすると無事Hello Worldのメッセージが表示されました。

あとはindex.jsを含めたプログラムを更新していけば開発できるはず。

その他

コマンドに困ったらヘルプ読めば大体想像つくよ!

deta -h

endpoint忘れたら詳細表示

deta details

Turing.comからのスカウトメールがうざいのでGithubのコミット履歴のメールアドレスをダミーアドレスに変更した

タイトルの通り。

Turing.comからのスカウトメール - Qiita
https://qiita.com/Elson/items/b2259dd7c0f202d42e3c

これを見てそうか!Githubのコミット履歴から来たんか!ってなった。
これを解消するには……どうしたら……と調べていたらこんな記事があった。

【Git】 過去コミットのAuthorとCommitterを一括変更する【歴史改変】
https://zenn.dev/wabeshew/articles/ee9119a16e3458bbc3d7

これはすべてのコミットを書き換えるので共有リポジトリでは使えなさそう。
自分のコミットに絞る方……までは調べませんでした。自分のリポジトリにしかコミットしたことないので。

さぁ変えよう!となった時に、メールアドレスどうしよ……ってなって調べたところGithubにはダミーメールアドレスがあるということを知りました。

GitHub でダミーのメールアドレスを使用する - Qiita
https://qiita.com/sta/items/982ab68e8220a81d485c

ということで、Githubのコミット履歴を全部書き換えました。
……できた……はず……。

.NETにおけるテスト時のカバレージ確認

バレージの取得はMS公式だとEnterprise以上のエディションかコマンドで頑張るかのどちらかになってしまうようなのだけれども、Fine code coverageがなかなかよさげ。
Fine Code Coverage - Visual Studio Marketplace https://marketplace.visualstudio.com/items?itemName=FortuneNgwenya.FineCodeCoverage

C#のコーディング規約について 命名規約編

基本的には、Microsoft標準でいい……と思っていたのですがちょっと微妙。

C# のコーディング規則 | Microsoft Docs
https://docs.microsoft.com/ja-jp/dotnet/csharp/fundamentals/coding-style/coding-conventions

class、record、または struct の名前を付ける場合は、パスカル ケース ("PascalCasing") 使用します。
interface に名前を付けるときは、名前の前に I を付けるだけでなく、Pascal 形式を使用します。 これにより、それが interface であることがコンシューマーに明確に示されます。
フィールド、プロパティ、イベント、メソッド、ローカル関数などの型の public メンバーに名前を付ける場合は、パスカル ケースを使用します。

特に異論なし。

private または internal のフィールドに名前を付ける場合は、キャメル ケース ("camelCasing") を使用し、_ を使用してプレフィックスを付けます。

……_いらなくない??

private または internal である static フィールドを使用する場合は、s_ プレフィックスを使用し、スレッド静的には t_ を使用します。

クラス単位のstaticやスレッド単位のstaticはアプリケーション的に意味があるし、注意すべき点もあるからつけてもよいという気はしないでもないですが……うーん。
(クラス自体がstaticの場合、s_は非常に鬱陶しい気がする。生成されたインスタンスからstaticな変数にアクセスする際に注意が必要というのは非常にわかる。よくバグになっている。)