2023-11-26

Vue.js触ってみたメモ（作業日：2023年11月26日）

node.js Vue.js

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

なんで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

クイックスタート

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

感想

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

2023-05-07

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

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

宣言的UIとは……

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

.NETに明るい人向け

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

上記以外の人

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

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

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

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

2022-09-25

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

クラウド node.js

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

2022-06-16

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のコミット履歴を全部書き換えました。
……できた……はず……。

2021-08-21

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

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

2021-07-25

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な変数にアクセスする際に注意が必要というのは非常にわかる。よくバグになっている。）

2021-07-10

Visual Studioでハマった時の覚書（随時追記）

.NET C# VisualStudio

何かにハマったら適宜更新していきたい。
本記事公開時の環境はVisual Studio2019。

リソースが見つからない
具体的な例外をcatchしているのに「CA1031 一般的な例外の種類はキャッチしません」が消えない（2021/7/25追加）
インストーラーの作成について（2021/7/26追加）
作成したクラスが構成を変更すると参照できない

リソースが見つからない

リソースファイルのプロパティにて下記2点を設定しないと参照できない。
久しぶりにやると大体これを忘れる。

ビルドアクション：リソース
出力ディレクトリにコピー：新しい場合にコピーする or 常にコピーする

具体的な例外をcatchしているのに「CA1031 一般的な例外の種類はキャッチしません」が消えない（2021/7/25追加）

CA1031: 一般的な例外の種類はキャッチしません (コード分析) - .NET | Microsoft Docs https://docs.microsoft.com/ja-jp/dotnet/fundamentals/code-analysis/quality-rules/ca1031
コード分析した時のInformationだったので無視することもできましたが気持ち悪いのでいろいろと試したところ、下記で消えました。

発生するコード例

            try
            {
                File.AppendAllText($"{folder}{fileName}", outText);
            }
            catch (DirectoryNotFoundException)
            {
                ShowErrorMessage($"出力先のフォルダが見つかりませんでした。\n{folder}");
                return false;
            }

修正後のコード

            try
            {
                File.AppendAllText($"{folder}{fileName}", outText);
            }
            catch (DirectoryNotFoundException e)
            {
                ShowErrorMessage($"出力先のフォルダが見つかりませんでした。\n{folder}");
                LogService.DumpException(e); // 自前のログ出力クラス。
                return false;
            }

以下はコードの経緯と推測。
元々、Exceptionを直接catchしていた（どうせIO関連以外の例外なんてそうそう発生しないんだからあとできれいにしようという考えのもと仮実装していた）。
この時はWarnaingが出ていたのですが、アプリ全体の例外処理とログ出力処理を追加したところInformationに変わりました。
今回、仮実装したところを個別の例外をcatchするように変更したところ、Informationが消えないままでした。
全体の例外処理をハンドリングしてログ出力しているのにここではログ出力しないんか？例外の情報参照してないぞという気付きを促すものなのだと思います。
（もう少しわかりやすいメッセージにしてほしい。）

更に追記
試しにアプリ全体の例外処理を削除してもInformationのままでした……。警告じゃなくなったのは別要因だと思われます（上のコード修正で直るのは変わりない）。

インストーラーの作成について（2021/7/26追加）

Microsoft Visual Studio Installer Projectsを使用した場合の注意点。
NuGetで参照するdllのバージョンが下記のようになっている場合、ビルドした際とInstallerが自動で検出する際とでバージョン差違が発生する場合がある。

C:\Users\%USERNAME%\.nuget\packages\system.buffers\4.5.1\lib\net461
C:\Users\%USERNAME%\.nuget\packages\system.buffers\4.5.1\ref\net45

仕方がないのでbinフォルダに出力されたファイルを直接Setup対象ファイルとして追加することで回避。
ライブラリが増減するたびにメンテが必要なので注意。

作成したクラスが構成を変更すると参照できない

以下の手順を行うとクラスが参照できなくなる。

クラスを作成する
作成したクラスを別のクラスから参照する
作成したクラスをリファクタリングで名前を変える
構成を変更する（Release→Buildなど）

一度、プロジェクトの参照から外して再追加すると参照できるようになる。
（リネーム前に両方の構成でビルドしておくと問題ないっぽい）
（これはバグでは？？？）