制作物の技術選定振り返り

運用をしていると色んなことに気がつけますね。今日はあまあま技術選定を振り返って行きます。
この記事は他人の技術選定の振り返りを見て、「知ってるのがそれしか無かったから」とか言えなくし、フォロワー、ひいては日本、ひいては世界の開発環境を良くしようという試みです。（嘘かもしれません）

ポートフォリオのバックエンド

どうしてGoで書いたのでしょう。

• DBはサーバーアプリ以外から操作されない。

• 手軽に更新したいからCMSが欲しい。

• SQLがゴリゴリ必要なほど高度なものを書かない。

どう見てもDjango側に分があります。次の更新ではDjangoに切り替えたいですね。

最適グラボのバックエンド

DjangoとServletとC以外の選択肢がなかったことがたいへん悔やまれます。

• DBは基本seleniumからのアップデートで、Djangoモデルが使えない。

• SQLをゴリゴリ書く必要がある。

• 型のアップデートが頻繁で、どこがどう反映されるか知る必要がある。

• CMS要らない。

さて少なくともPython向きではありません。今だったらGoかJavaで作るでしょう。少なくとも動的型付け言語を使うわけがありません。型の変更がコンパイルエラーにつながってくれたほうがもろもろ便利に決まってます。あとモデルが効かないのにDjangoを使うのは愚かでした。

最適グラボのフロントエンド

Reactでしたが、Next.jsにしたいです。これはただ単純に全部Next.jsにしたいだけですが。

参考資料検索サイト(大学生の参考資料)

これは今でもDjangoは使いそうですが、フロントとバックエンドに分けると思います。少なくとも動作するフロントエンドにScriptタグだけで対応するのは設計としてヤバすぎます。Gitのブランチ管理してる場合じゃありません。あと、JavaScriptにして型を追いきれない状態にしていたせいで、更新が難しくなっています。Next.js(TypeScript)を使い、DjangoをRESTAPIにしたいです。

クワインマクラスキー法シミュレータ

ちょっとガチ工学が入ってしまうので申し訳ないです。論理回路を短く作る方法としてクワインマクラスキー法なるものがあります。これをコンソールアプリとして作りました。
Javaで書いたのですが、正直技術選定以前の問題が山積みです。まだ未熟でしたし。
まず、コンソールに渡す引数が多すぎる。

• 真理値表のcsv

• 入力の個数

• ビット数

が必要です。が、真理値表があれば残り2つは動的取得出来るので、アプリ製作者の怠惰ですね。もちろん「入れられるようになっている」は大いに賛成ですが、「必須である」はダメです。
そもそもコンソールアプリは良くない。今どきGUIが無いってなんですか？ありえませんね。
以上の特性から、Webもしくは.netフレームワーク、MAUIなどでGUIをつけることが求められそうです。

また、プログラミングから見たこのコンテンツの特性は

• 型は決まっている。

• 値は3値("1","0","-")

• 変数名も$${i_{11},i_{12} … i_{31}}$$などしか候補が無い。

ですので、Python3の主戦場ではないでしょうか？

少し候補を出しましたが、結論はMAUIでフロント、Pythonをexe化、両者を梱包してインストーラーやzipで提供となりそうです。これではWindowsしか対象ではなくなりますが、exe化のところをmac,linux用に変えればOKですしね。

まとめ

RubyとRustとScalaをこれからやっていこうと思っています。これからも新たな発見があることを願います。