ごらくらいふ

プログラミングしたりゲームしたり

書き捨てストレッチ:素数を判定するツール

「もう6月も終わるし、なんかネタ出さないとな」とデレステのイベントを走ってたら素数っぽい数字が見えた。

そういえば素数判定するコードは書けるはずだけど、すぐ参照できる場所にコードがないな…?

書いてみた

書き捨てだから(免罪符)深いこと考えない実装をしてみた。

/**
 * 素数判定スクリプト
 * @param {number} value 素数判定したい数値。0以上の整数を期待する。
 * @return {boolean} 素数であれば `true`。
 */
function isPrimeNumber(value) {
  if (value < 2) {
    return false;
  }
  let element = 2;
  while (element * element <= value) {
    if (value % element === 0) {
      return false;
    }
    element += 1;
  }
  return true;
}

Webツールとしてはいつもの GitHubホスティング

yajamon.github.io

factor コマンド使えば良い

こんな実装し~なくても。ってやつ。

factor というコマンドはパラメータの値を素因数分解してくれる。 この結果を確認すれば、素数か判断できる。

factor 180007
# 180007: 180007  
factor 10
# 10: 2 5

チラシの裏

  • 素数は英語で「prime number」というらしい
  • 合成数は英語で「composite number」というらしい

新和英大辞典 第5版 研究社より

PS5版を買うかPC版を買うか悩むときの評価軸

欲しいゲームが PS5 や Steam などマルチに展開している場合、どこで買うか迷ってしまう。 例えば今、テイルズオブアライズを ウィークエンドセールのSteam で買うか ゴールデンウィークセールのPS5 で買うか迷っている。

答えは出ていないが、プラットフォームを決定する評価軸があるはずなので書き出してみる。

評価軸

販売先

  • 前提として、販売対象のプラットフォームが検討対象になる
  • 単一のプラットフォームにしかない場合、ただ買えば良い

値段

  • ストアの恒常的な値下げ
    • PS Store の場合、 Hits になったソフトが安くなったりする
  • セールで安い
    • 今すぐやりたいほどではないが遊ぶつもりのもの
    • 安いときに買う
  • 即買いラインを下回っている
    • プラットフォームごとに買う場合もある

プラットフォームによる違い

  • プラットフォームのスペック
    • PS4 より PS5
    • PC と PS5
      • SSDストレージの大きさ
      • GPU性能
  • ソフトウェアの可搬性
    • PC版は基本的に端末を新しくしてもなんとかなる
    • PS5版は Sony が互換性を提供する限り遊べる
  • 操作方式の違い
    • PS5 はコントローラー操作が基本
    • PC はマウス・キーボードがあって当然で、コントローラーも使える

ストアの違い

  • 表現規制の差異
    • PS版は独自な表現規制が施されがち
    • Steam版の方に規制が施される場合がある
    • 事前に情報が得られるなら参考にする
  • 再ダウンロードのサポート
    • Steam
      • パブリッシャーがSteamに卸している限り保証される
    • PS Store
      • コンソールの場合、ほとんどが長期にわたって継続して提供される

ゲームと直接関係ない部分の理由

  • ゲーム配信がしたい
    • リソース消費の激しすぎるゲームをPS5に切り離す

Modの需要

  • 楽しみたい内容に Mod が含まれるなら PC 版しかない

買うこと自体を延期するか

ちゃぶ台返しなので末尾に……。

  • 絶対ネタバレされたくないか
  • すでにカートに突っ込んだゲームの数々
  • 積んでるゲームの数々
  • セール待ちをするか

ふとresult.tsを更新した

Changelog

  • バージョン 0.3.0 になりました。

Enhancement

  • ok<T>(value: T) という関数を追加しました。
  • err<E>(error: E) という関数を追加しました。

Deprecated

  • Ok<T>(value: T)
  • Err<E>(error: E)

www.npmjs.com


経緯

先日、 WSL2 環境を Ubuntu 22.04 LTS に移行した。 環境が新しくなると整えたくなるもので、この移行に伴って dotfiles の整備をはじめた。

以前からなんとなく気になっていた efm-langserver を使ってみようと思い立った。 これは、 ESLint などの linter が吐き出すメッセージを Language Server Protocol (以下 LSP) に載せ替えてくれるLanguage Serverだ。 ESLint+prettierの lint結果をLSP経由で扱えるだけでも便利だし、 zenn.dev に投稿する文書を textlint で校正もできるようになる。

これの実験にちょうどよいのが result.ts だった。 ESLint , prettier, TypeScript を使っていて、ボリュームも小さいからだ。

result.ts とは

ここで一旦説明をする。 result.ts は Rust の Result を真似て書いてみたものである。

export type ResultOk<T> = {
  isError: false;
  value: T;
};
export type ResultErr<E> = {
  isError: true;
  error: E;
};

export type Result<T, E> = ResultOk<T> | ResultErr<E>;

https://github.com/yajamon/result.ts/blob/75e33b52193f5f16e99d53b43b388616ab1967b6/src/main.ts#L1-L9

  • こんな具合に、値かエラーを包んでいるオブジェクトは共通して isError を持っており、これを if でチェックするとスコープの中で型が確定できる。
  • 個人的なこだわりは、 class を使わず、ピュアなオブジェクトに包むことである。

シグネチャへの違和感

result.ts だが、最終更新を確認すると2年以上前である。 これほど時間が経つと、当時とコードに対する感覚も変わってくる。

ふとコードを見ると違和感があった。

export const Ok: <T>(value: T) => ResultOk<T> = v => ({
  isError: false,
  value: v
});
export const Err: <E>(error: E) => ResultErr<E> = e => ({
  isError: true,
  error: e
});

https://github.com/yajamon/result.ts/blob/75e33b52193f5f16e99d53b43b388616ab1967b6/src/main.ts#L13-L20

TypeScript なのに関数がパスカルケース ( Ok(v) , Err(e) ) なのだ。 当時の感覚としては、Rust の タプル構造体 を生成してるように見えて面白いからといった所だろうが、いくらなんでも寄せすぎた。

Rust においては、あくまで enum Result<T,E> のいち構造体様の生成であり、関数ではない。

doc.rust-lang.org

TypeScript / JavaScript において関数のシグネチャは、少なくともパスカルケースは主流ではない。 そしてオブジェクトの生成は new Ok(value) などとするものだ。なんとも上記のコードでは気持ち悪さを感じる。

ということで ok(v)err(e) を生やすこととした。

現行バージョンは 0.2.x だし、シグネチャをまるっと変えても良いかなと思ったけれど、「わざわざ破壊しなくてもいいか」と思いとどまった。 代わりに @deprecated アノテーションを付与した。

書き捨てストレッチ:縦書きジェネレーターを書いてみた

なんか作った感を得たくて、書き捨てツールを書くストレッチをした。

シリーズ物というわけではないが(?)、今回のお題は縦書きジェネレーター。

縦書きジェネレーター

書き捨てストレッチでは、ひとまず単体の HTMLファイル で完結させることにしている。 Node.js も TypeScript も関係ない、原始的なものを書きたくなることって、あるよね。

実際のところ、html内埋め込みで書くのは面倒である。 補完が効いてるような効いてないようなって感じだし、jscss の単体ファイルでは起こらないようなインデントのわちゃわちゃが起きて、開発体験は眉がハの字になってしまう。

それでも、なんも気にせず書くのは楽しい。 画面上に説明書きも用意されてないし、振る舞いのオプションはないし、期待していない入力への手当もない。 しかしながら目的は(自分目線で)間違いなく達成されている。

「ほしいな」「つくった」「うごいた」これで心が少し潤う。

放送大学の全科履修生になりまして。

「仕事の上で学んだことはありますか」

職場のアンケートだとか、1on1 だとかで、よく登場するこの質問。 生来のネガティブ気味な思考もあいまって、この問いにポジティブな回答をすることは、ほとんどない。

いや、何もないわけではない。

不具合があれば要因を切り分け、対処する。 新規要望があれば要素を切り分け、対処する。

確かに未知の情報があり、調査があり、実験があり、結論がある。自分の頭の中にあるものだけで解決していることは、無いと言っていい。 それでも、「それに学びはありましたか」と問われれば、「うーん。いえ、とくには」となる。

実際のところ、そこに学びが無いということは false なのだろう。発見する力とでもいうものが足りていないというか。 それとも自分は学びを得ているのだろうか。それを吐き出す力がないだけであってくれるのだろうか。 ともかく、目の前に起きている物事から教訓を見出すのは、きっとなにかしらの手続きというものがあるのだろう。

まあ、いい年こいて職場に教えてもらおうというのは、いかがなものかという考えはある。

「学んでいますか?」「うーん。」という問答に毎度ビミョーな気持ちになるのなら、実際に学びにいけばよい。 その実感を得るならば、学習できる機関に所属するのが一番だ。

自分はものぐさで、完全に決まった時間に決まった行動するのは上手ではない。 場所に縛られず、時間にも縛られない条件をもとに選定したところ、なんとまあ放送大学というものがあるじゃあないか、と。

高卒からプログラマーの仕事をしてるので学歴に関して思うところの解決と、仕事で得ている知識を単位に還元してやろうという打算と、そんなところがモチベーションだ。


で、前期に科目履修生として入学して、3単位全部落としてきました。観たいものだけ観てたやーつ。 ちゃんと失敗してうまくやる勘所を掴んだ気がするので、今期から全科履修生として本格入学します。

Obsidianでノートを取って10ヶ月が経過した

obsidian.md

Obsidian とは

Markdown ファイルの利用に特化した メモツール です。 プラグイン拡張が可能で、コミュニティプラグインだけでなく、コア機能もプラグイン化されています。

私も自作プラグインを作りました。

yajamon.hatenablog.com

yajamon.hatenablog.com

Obsidianとの出会い

友人に紹介されて出会いました。

Obsidian を使う目的

『知的生産の技術』(著:梅棹忠夫 1969年) という本に、ノートのとり方を触発されました。

yajamon.hatenablog.com

自分の知識を書き貯める、自分のデジタル文書館を整備しようと思ったのです。 ある程度みじかく完結したノートと、それらをリンクでつなぎ集積したもので知識を表現する思想が、自分に合っていました。 これを、Obsidian は強力に支援してくれるものでした。

書き貯めた知識は、ブログ記事原稿の素材入れとしても役立っています。

10ヶ月経過した

昨年の5月から使い始め、10ヶ月が経過しました。 ふと振り返ったら10ヶ月が過ぎていると気付いてしまったため、勢いに任せてブログ記事を書いています。

グラフビューの成長

f:id:yajamon:20220301050651p:plain
10ヶ月分のメモを表すグラフビュー

  • リンクで結びついたノートが近くに集まっています。
  • 赤い点はデイリーノートで、その日に追加したノートのリンクを集めて集約しています。
  • 緑の点は書き貯めたノートです。

ファイル数

  • ノート: 1328
    • ヤクの毛刈り的に固有名詞のノートが膨れ上がっているところがあります。
  • デイリーノート: 258

まだまだ歩き始めたばかり

固有名詞を取り込むために増えたノートが多いです。 もっと冗長なノート同士の関連性を見出して、新たにノートを発見したいと考えています。


応用した

この Obsidian を使ったメモ手法を、ゲームの遊び方に応用しました。

レポートプレイ

ゲームをひたすらメモしながら遊んでいくプレイスタイルを試みています。

youtube.com

  • RPGのシナリオをすくい上げる
  • ちょっとしたキャラクターの関係性を拾い上げる
  • 遊んでいて起きた出来事の記録

などなど、世界観を明らかにしたりお手製の攻略情報を積み上げようとしています。


自分のノート作成方針

別建てにしても良かったのですが、ついでに自分のノートづくりについても記載したいと思います。

ノートのかたち

  • ノートは一枚で完結した内容を書き、一行に要約することを目指します。
    • 一行の要約が、記事タイトルやファイル名になります。
    • 上手くいくと、git のコミットのようになると考えています。
どれくらい書くか
  • テキストベースで作るなら、ほとんどのファイルはセクタサイズで同一のファイルサイズに規格化されます。
  • 現代のディスクストレージでは殆どが4KBでしょうから、4KB以内であれば短く書こうが長く書こうが一緒だという認識です。
  • iPhoneで撮影した画像一枚を上回るほどノートを取るのは大変なことです。

ノートを作るタイミング

調べ物をしたらノートを作るタイミング
  • Webを検索する前に、まず自身の保管庫を調べます。
    • (だいたいそうですが)答えがないなら知識として追加する絶好の機会です。
気になるWeb記事があったらノートを作るタイミング
  • 読んだ内容の一行まとめや、自分の感想を書きます。
  • これをデイリーノートが集約することで、その時気になった記事という記録が残ります。
  • 記事部分を抽出したスクラップノートを作っても良いです。
    • 手間ですが、Web記事は消える恐れがあります。
    • 一方で、スクラップするよりも、リンク先が消えても問題ないように知識として抽出すべきだという考えもあります。
      • スクラップはあくまでノートの素材を確保しているに過ぎません。
  • こういうノートを作るとき、調べ物もしたくなるでしょう。(そしてノートが増えます)

複数端末での利用

  • Obsidian Sync という、公式の同期サービスがあります。
  • すでに Dropbox などのミラーリングソフトウェアを利用していれば、こちらで共有するのもよいと思います。
    • モバイル端末との共有は難しい点もあるようです。

ノートの公開

  • Obsidian Publish という、公式のパブリッシュサービスがあります。
    • が、私は利用していません。
プライベート保管庫のススメ

個人的には、知識の保管庫を作る場合、ノート作りをプライベートにするとよいと考えています。なぜなら、ひとの目を気にするというのはブレーキ要素になるためです。

「だれかの顰蹙を買うかもしれない事柄」だけでなく、「自分のこの部分は知られたくない。しかし、そこに深く関係している事柄」あるいは、「人に見せるならもっとちゃんと書きたいし…」と渋って忘却してはもったいないです。

なんでも覚えていることは難しいです。考えを吐き出すことにブレーキをかけるべきではないと考えています。

気にすべきは、未来の自分だけでよいでしょう。未来の自分に伝えられる文書がかければ、それでよいのです。(それもまた難しいですが)

プライベートに知識を書き貯めて、公開する原稿を書くときに引き出す。 ひとの目はこのときに気にして、文書の体裁を整えることに注力すればよいと考えています。

Unity バージョンはいつまでサポートされるのか

定期的に忘れるので備忘録。

2022年現在、Unity のサポート期間は以下のようになっている。

2017.4 以降

20xx.4 はLTSバージョンであり、リリースから2年間がサポート期間となる。

たとえば 2017.4 は 2018年の春に 2018.1 のリリースと合わせて行われるという。 そこから2年間、すなわち 2020年の春 までサポートされる。

ざっくり年度バージョンの +2年 までサポートされると覚えておけばいい。

2017.x 以前

2017.1 リリース以前は、 5.6.x などといったバージョンがリリースされていた。

これは、メジャーバージョンがリリースされてから 1年間 がサポート期間となっていた。

この書式の最後のメジャーバージョンである 5.6 は 2017年にリリースされたので、 2018年までサポートされた。