「心理学，認知・行動科学のための反応時間ハンドブック」を読んだ
読みました。
全ての人間が読むべき本かというと、そうではないです。
私がプログラマーなので、プログラマー文脈になってしまいますが、
あたりの人間が読むと、知識に深みが出そうです。
実務的な数値とかは、こういった記事の方が揃ってます。ただ、こういった記事を読む際に「そもそも反応時間とは？？？」という基礎知識を得ておきたい場合には非常に良い本でした。
私が読んでた時のログはTwitterに流してました。これを見てもらえば書いてある雰囲気は伝わると思います。
反応時間ハンドブックを読み始めた https://t.co/uVKEbEH5G0
— てるるー (@terurou) 2020年8月15日
各用語や過去の研究等の説明がかなり丁寧で、入門レベルの人間でも読めるようになっています。元々の想定読者に研究者が想定されていて、関連論文のサーベイ本みたいな感じもあり、引用文献は巻末に大量に書かれています。この本を片手に用意しておけば、反応時間関連の英語論文もなんとなく理解できる程度のは読めそうな気がしてきます。 ただし、かなり工学書に近い書き方をしている本なので、こういった本を読みなれてない人にはかなりしんどいと思います。
設計書には何を書くべきなのか
設計とは、
- 要求（やりたいこと）をヒアリングする
- 要求を要件（何を満たさないといけないのか）に落とし込む
- 要件を実現するために考えられる手段を洗い出す
- 手段の検証を行う
- 検証結果を元に、どの手段を使うかを選定する
- 選定した手段を合意する（一部要件を満たさない事項がある場合は、代替策や妥協ラインについても合意する）
- 合意内容を元に、実装や設定に落とし込む
をやることである。画面設計や機能設計のように、3-5の検証/選定が薄くなったり曖昧になったりするものはあるが、一般化するとこの流れになる。
設計書には、上記の設計でやってきたことを順番に書いていけばよい。これを文章構成のテンプレに落としていくと、
- 要求
- 要件
- 方式
- 対応案（いわゆる比較表で書いていくのが楽）
- 検証結果
- 選定・合意結果（合意した代替策や妥協ラインについても記載する）
- 詳細設計（どういう実装にするとか、パラメーターにするとか、細かい話）
という感じで書いていけばよい。
ありがちな失敗としては、4.詳細設計しか書かないことである。これだと、後から読んだ際に「なんでこれ使うことにしたんや…」がわからないという事態が発生してしまう。前述のとおり、画面設計や機能設計では方式を選ぶという事が薄いので、普段このあたりを多くやっている人ほど、3.方式を書くという意識が飛びがちになる。
あと、2.要件はまあまあ書かれるのだが、それに対して 1.要求は「ちゃんとした設計書」ですら書かれていないことがあり、やはり「なんでこの要件になったんだっけ？」が発生しがちになる。
ASUS TUF Gaming A15を買って、すぐにRAM32GB/SSD1TBに換装した
ASUS TUF Gaming A15（FA506IU）を買いました。この記事を書いている時点ではこの機種が在庫切れのようで、次のAamzonリンクは1つ下位の機種（GTX 1660 Ti ではなく GTX 1650 Ti、他は同じ）です。
TUF Gaming A15は、Ryzen 4800H搭載で2.2kg程の15インチゲーミングラップトップです。同じようなカテゴリーでは、同じASUSのROG ZEPHYRUS G14がRyzen 4900HS搭載で1.7kg程ということで、大きなインパクトがあり有名です。
では、なぜわざわざASUS TUF Gaming A15の方を購入したかというと、これにつきます。
ASUS TUF Gaming A15を買いました pic.twitter.com/KeVia2003r
— てるるー (@terurou) 2020年7月16日
公式にこういうことが書いてあったら、当然の措置 pic.twitter.com/PkXqfJCOwP
— てるるー (@terurou) 2020年7月16日
機種選定にあたっての利用想定は、
- ゲームではなく開発で使用
- RAM16GBでは人権が守れない
- 自転車移動で持ち運んで使うことがありうるので、現実的な重量のラップトップ
という感じです。
CPUパワーが欲しいので、今のご時世ではRyzenしか考えられません。というか、Ryzen機のコストパフォーマンスが良すぎます。Core機より5万円ぐらいのレンジで平気で安いの、一体どうなってるんだ。
現行世代のRyzen 4000でRAM16GB超となると、選択肢がかなり限られてきます。冒頭でも書いたROG ZEPHYRUS G14もかなり本気で検討したのですが、RAMが24GBシングルチャンネル（オンボード8GB＋換装可能スロット1）にしかアップグレードできないROG ZEPHYRUS G14はしんどいなあと判断して見送りました。
TUF Gaming A15はRAMスロットが2本あり、スペック上は64GBまで増設可能となっています。YouTubeでもRAMアップグレード動画が十分に数があり、かなり簡単なことは確認できたので、完全にこれが決定打です。
本体2.2kg＋ACアダプター450g程度と、最近の15インチのラップトップでは若干重い（ゲーミングとして考えると軽い）のですが、ここ数年の自分の稼働状況とCOVID-19の状況から、持ち出し頻度はかなり少ないだろうと判断し、重量は優先度を下げました。
最初から自前で換装して使う想定なので、RAMとSSDも合わせて買いました。Amazonのリンクを張ってますが、実際にはarkで勝っています。
ウエスタンデジタル WesternDigital SSD WD Blue SN550シリーズ NVMe M.2 2280 1.0TB WDS100T2B0C
WD Blue SN550は、発熱が低めで、なによりコスパが良いという理由で選んでます。連続書き込みでキャッシュアウトした際にシーケンシャルリードが500MB/s弱しか出なくなるので、あまり性能が良くないという言い方のレビューも見てはいるんですが、ぶっちゃけシーケンシャルリードが500MB/sでも3000MB/sでも、日常の利用シーンでの違いは体感できないので、問題なしという判断です。高解像度の動画なんかを操作する人達には当然違うんでしょうが、自分はそうではないということで。
換装の手順は、この動画を見てもらうのが分かりやすいです。当然ですが、換装する前にはリカバリーメディアを作っておきましょう。これは換装後でも大丈夫ですが、MyASUSアプリから製品登録をしておくと無難です。
動画ではわかりづらい点を強いて上げると、
- ネジは普通のプラス精密ドライバーがあればOKだが、いわゆる「こじ開けツール」が必要
- 底面パネルのネジがいくつか長さが違うものか混ざっているので、ネジを締めなおす際に間違えないようする
- SSDを換装した際は、BIOSでSecure Bootを無効化しないとエラーが出る（Secure Bootを無効化しろいうエラーなので、わかると思いますが）
といったぐらいです。
私は、元々取り付けられていたSSDを外して換装しました。NVMeスロットが2本あるので換装前のSSDをセカンドスロットに刺しなおしてもよかったんですが、いざとなったときは刺しなおせば工場出荷状態に戻せます。
換装が終わったら、普通にWindows 10をインストールするだけです。私はVisual Studioサブスクリプションを持ってるので、Windows 10 2004 Enterpriseをインストールしました。
ドライバー類はWindows Updateから全て自動で入りましたが、Windows Updateでは入らないASUSのUtility類もサポートサイトから全てダウンロードできます。
ASUS TUF Gaming A15 | ASUS TUF Gaming | ノートパソコン | ASUS日本
次をインストールすればOKです。
- ASUS System Control Interface V2
- DTS Ultra LPAP Component Driver
- ROG Live Service Package
- Refreshrate Service
- ARMOURY CRATE Service
- Armoury Crate UWP
- 排熱（ファン）のモードとか、キーボードのゲーミングっぽいイルミネーションの設定
- DTS:X Ultra UWP
- サウンド設定
GameVisual UWP- 液晶パネル設定だが、Armoury Crate UWPに統合されているので不要
- MyASUS UWP
- サポート関連の他、バッテリー充電設定がここにある
これで換装は完了です。
キャンペーン価格や自前アップグレードパーツ代を込みで、トータル157,980円（税込）でした。Ryzen安すぎる…。
Azure PipelinesのWindows VMでHaxeを動かす
色々悩んだ結果、curlしてunzipすれば動くことがわかった。Azure PipelinesのPATH周りでだいぶ苦労した。
ポケットモンスター ソード/シールドにHaxeが採用されていた
顛末
昨日、こういう感じのツイートを見かけかました。
ポケモンほどの大規模なゲームでHaxe採用されるの初めてなのではhttps://t.co/i8lCJx0NWh
— neguse (@neguse) November 14, 2019
結果、このような形となりました。
これは、Haxeという高度な型システム及びマクロシステムを持つ静的型付き言語であり、マルチプラットフォームでC++, JavaScript, C#, Java, Python, PHP, Luaなどのターゲットに出力可能なプログラミング言語の現実世界での利用状況を調査するために購入されたものです pic.twitter.com/UnaZsMrH9I
— てろるー (@terurou) November 16, 2019
調査結果
確かにポケモン ソード/シールドの知的財産の表記には、Haxeの記載がありました。
確かにポケモン剣盾にHaxeの表記あるな #NintendoSwitch pic.twitter.com/wqdfu2VuMX
— てろるー (@terurou) November 16, 2019
- Immersion
- Symplygon
- Wwise
- Protocol Buffers
- FlatBuffers
- Fixed size function
- Haxe(Haxe Standard Library)
- Lua
- Sol
- YEBIS
- cURL
- Stagefright
- H.264
- VP8 and VP9
- libvorbis
- libwebm
- Wslay
- RapidJSON
- LZ4 Library
確かにHaxeの記載があります。合わせて気になる点は、
- LuaとSol（おそらく https://github.com/ThePhD/sol2 ）の記載がある一方で、 hxcpp が記載がない
- ライブラリの記載順が、比較的関係のありそうな順番に並んでいる
- Haxeと依存関係がありそうなライブラリがLua以外にない
というから、
ものと推測されます。
この記事が注目されるようなことがあれば、もしかしたら後々答え合わせ的な情報が任天堂から出てくるかもしれません。
Haxe製のゲームについて
「Haxe製のゲームでビックタイトルはポケモンが初めてでは？」という点については、若干気になるので言及しておきます。
洋ゲーなのであまり国内では有名ではなく、ポケモンと比べたら確かに知名度もないのですが、 Dead Cellsというタイトルがゲームエンジンも含めてガッツリHaxe製です。
最新のセールス数は把握してないのですが、この記事によると全世界で100万本を超えているとのことなので、ビックタイトルと言っても差し支えないのではないかと思います（開発規模がビックタイトルかという話もあるんですが、まあそれはそれとして）。
また、国内開発タイトルにもHaxe製のものがあるのですが、情報を出していいんだかよくわからないので、公開OKをもらってから追記しておきます。
ゲーム以外（Web）でのHaxe採用事例
おそらく一番規模が大きな事例としては、DAZNがHaxe/JS + React.js製です。
国内では、ヌーラボさんのサービスがHaxe/JSが使われています。中の人から使っているという返答も来ています。
つこうてますよー。
— 橋本正徳👨💻ヌーラボ (@hsmt) March 14, 2018
ここらへんからは私も半関係者みたいな感じになってきますが、このサービスもHaxe/JS製です。
数は多くないんですが、まあ普通にプロダクションで使えるプログラミング言語です。
Azure Cosmos DBのデータ構造
昔書いたCassandraの記事 Cassandraのデータモデル - terurouメモ 的にCosmos DBのデータ構造と用語を整理。
データベースアカウント
- Azure PortalからCosmos DBを作成するとできるトップレベル要素
- 図のデータベースよりも上位の存在
- データベースエンジン（SQL API、Azure Table API、MongoDB API、Cassandra API、Gremlin API、etcd API）はこのレベルでしか設定できない
データベース（図ではDatabase表記）
- RDBのデータベース（もしくはスキーマ）相当、CassandraのKeyspace相当
- データベースレベルでスループットをプロビジョニング（上限RUの設定）すると、配下のコンテナー全てでプロビジョニングスループットが共有される
コンテナー（図ではContainer表記）
- RDBのテーブル相当、CassandraのTable相当
- スループットはコンテナー個別にも設定することができる
- Cosmos DBリリース直後はコンテナーに対してしか設定できなかったはずだが、いつの間にかデータベースレベルで設定できるようになっていた
Partition Key
Cosmos DBの設計で特に重要となるポイント
- CassandraのPartition Key相当、RDBには相当するものはない
- Partition Keyはプライマリキーではない
- Partition Keyによって論理パーティションが分割される
- Partition Keyは複合キーを指定することができる
- 論理パーティション単位でシャーディングとインデックスの作成が行われる
- 分散しないPartition Keyを設定してしまうと、データベース全体の性能に影響してしまう
- とはいえ、論理パーティションを分割しすぎると有効にインデックスが使えなくなってしまう（レンジスキャンしたいケースが典型例）
- トランザクションは論理パーティション内でのみ有効となる
- トランザクションは、ストアドプロシージャ等のCosmos DB側で動作するロジックでのみ有効
Item（MSDNでは "項目" と訳されているが…）
- RDBのレコードに相当
- もしくは、ドキュメント、エンティティ
- IDにより識別される
ID
- いわゆるPrimary Key
- 一意キー制約は、論理パーティション内で有効
- コンテナー単位ではないので注意
- ID指定の検索は速く、RUの消費も最小限になる
参考資料
- Azure Cosmos DB | Microsoft Docs
- 公式のMSDNの資料を一通り読むべき
- Cloud Platform 関連コンテンツ | マイクロソフト クラウド プラットフォーム
- MSDNを読むべきだけど、読むだけならこっちの「Azure Cosmos DB 入門」テキストの方が読みやすい
Node.jsでCSV (RFC4180) をparseするのに苦労した
単純に1行分のレコードを Array<String> に変換してくれればよかっただけなのに、簡単に使えるライブラリになかなか当たらなくて難儀した。これを使えばよかった。
const CSV = require('comma-separated-values'); const fs = require('fs'); const data = fs.readFileSync('test.csv', 'utf8'); const csv = CSV.parse(data, { cast: false }); console.log(csv);
castオプションをfalseにしておかないと、無駄な変換が入ってしまう。
以下、RFC4180が処理できなかったやつ。これらは "" でクォートしてたりしてなかったりする列が混在していると解釈できないようだ。使い方が間違っていただけの可能性もあるが、そもそも高機能である必要がない（例えばヘッダ行をもとにKeyValueに変換してしまう機能なんか要らない）ので、要件が合わなかった。
