やりたいことが、数行のコードで実現できる。これぞ、いいライブラリと唸りました。
Amazon EC2上のIISからAmazon Fsxにアクセスする方法
EC2インスタンスがInfrastructure as Codeとなっていると再起動すると最小限の構成を除いて復元できないため、ファイル永続化できないのです。
そこでFsxを使ってファイルを永続化することになります。
Amazon EC2上のIISからFsxにファイルアクセスする方法が検索しても出てこなかったので焦りました。
Everyoneつけても無理で。
以下のようにします。
あまり、Fsx関連の記事ってないんですよね。
良いエラーメッセージとは？
仕事をしていて
エラーメッセージの一覧を出してくれ
と上司に言われたのでした。一覧を作成して改めて見返してみると、恥ずかしい出来でしたね。
7,8割のプロジェクトが失敗する今の時代。
ほとんどのプロジェクトに工数に余裕はなく、エラーメッセージに気を遣っている時間はないのではないでしょうか。
上記の記事では開発者が見るエラーメッセージとユーザーが見るエラーメッセージとありますが、この考え方はなるほどな、と思いました。
もっと言うと、
- ユーザーが解決出来るエラー（必須項目が入っていないなど）
- ユーザーが解決できないエラー（いわゆる想定外のエラーで管理者でなければ解決不可）
なのではないでしょうか。
ユーザーが解決出来るエラー
ユーザーが解決できるエラーであれば、〜を入力してくださいなどと言って、解決を促せば良いと。
さらっと言ってしまいましたが、誤った月ですと言うよりは、正しい月を入力してくださいと言った方がいいでしょう。
エラーメッセージなので、開発者はこんなことするわけないだろ、一応、入れとくかとなるので、雑になりがちなのです。
万単位のユーザーが使うシステムに携わって知ったのですが、このレベルになると100人に1人が問い合わせをするだけでも問い合わせは100件になりコールセンターに大きな負荷がかかるのです。
なるべくユーザーが自力で解決出来るようにすることは大事なのです。
ユーザーが解決出来ないエラー
ユーザーが解決できないエラーについては、何が起きているか表示して、これを管理者に伝えてもらい、解決方法を案内することになるでしょう。
ただ、ユーザーになんでも教えてあげればいいわけではないのが難しい問題です。
セキュリティが絡む問題になると、なんでもかんでも教えてしまうと脆弱性を露呈することになります。
ログイン時のパスワードが間違ってますとかそうですね。では、メールアドレスは正しいと分かってしまうとなってしまうので。
エラーコードを巧みに使って、ユーザーには一見同じエラーメッセージでもエラーコードを使いこなしてソースコード上のどこで発生しているか突き止めることも出来ます。
参考記事
HashSetの方がListよりパフォーマンスが速い。そして両者の違いは？
ソースレビューしていたら、List使うだろーと思っていたところでHashSetを使われていることがありました。
なぜにHashSet？ そもそもHashSetってなに？と調べてみたところ……。
圧倒的にListよりHashSetの方が検索速度が速いことを初めて知りました。
では、HashSetとListの違いとはなんでしょう？
MSDNからHashSetの特徴をざっくり言うと
- 高パフォーマンスの set 操作を行える
- 重複したデータは持たない
- 特定の順序はない
Listに比べてパフォーマンスは高いが、重複したデータは持たせることが出来ないといったところでしょうか。
重複したデータを持つことがないのであればHashSetを使った方が良いということなので、頭の片隅には置いておこうと思います。
using System; using System.Collections.Generic; using System.Linq; namespace HashSetTraining { class Program { static void Main(string[] args) { HashSet<int> hashSet = new HashSet<int>() {9, 1, 2}; hashSet.Add(-3); hashSet.Remove(3); // hashSet.RemoveAt(0); Compile Error(HashSet don't have RemoveAt) hashSet.Add(2); // Cannot Add Duplicated Value Console.WriteLine(string.Join(',' ,hashSet.OrderByDescending(i => i))); // result 9,2,1,-3 } } }
参考資料
読書感想「Unity5とC#で作るライフゲーム: UnityとC#で作ってみようシリーズ3」
本に書いてある通りにやっただけですが、サクッと作れるものなんだなぁと感心してしまいました。
ライフゲームは以下の法則です。
- 死んでいるセルの周囲8セルに生きているセルが3つあれば、セルが生まれる
- 生きているセルの周囲8セルに生きているセルが2つあれば、セルは状態を維持する
- 生きているセルの周囲8セルに生きているセルが4つ以上、もしくは1つ以下だった場合は、セルは死ぬ
CEDEC2021に初参加
CEDECに初めて参加しました。
過去の発表はCEDiL - CEDEC Digital Libraryにて確認できるのを知ったのが去年。
どうして、今まで参加してなかったのか、という後悔があります。
結構前に参加申し込みをしたのですが、仕事のリリース時期とかちあいそうでしたが、三日間休んで参加できました。
初日は、ネットワークが不安定で、なかなか見れませんでした。
タイムシフト配信で、後でも見れるので、初日は休むことなかったかなあとも。
リアルタイムレイトレーシング時代を生き抜くためのデノイザー開発入門
レイトレ時代のゲームグラフィックス、地に足をつけて備えよう - NVIDIA Falcor で次世代品質のリアルタイム物理ベース照明を手軽に素早く検証する -
レイトレーシング ~ 基礎とPS5™における枠組み ~
自分のチョイスの問題もありますが、レイトレのセッションは多かったですね。
レイトレ、レイトレーシングです。多少は、最先端技術に対して追い付けたかなと。
時間帯的には「レイトレーシング ~ 基礎とPS5™における枠組み ~」が一番後ですが、これが一番わかりやすいです。
レイトレーシングは交叉判定です。二分木の構造でデータを管理して、判定処理を高速化する話はわかりやすかったです。
光源からの光を受けるかに発展して、複数光源あったら、どうするか、どんなアルゴリズムを使うかが、他のセッションへの理解が深まります。
Webを加速するQUICとHTTP/3
これはゲーム関係なく、Webアプリケーションに携わる人にはためになる話でした。
TLS1.2,TLS1.3,QUICの違いを説明しており、言葉だけしか聞いたことがなく、中の仕組みについては知らなかったので、理解することができました。
TLS1.2廃止で、調査もしたことがあったのですが。
自分に技術の深みがないところはこうした仕組みへの掘り下げがないことだなと痛感しましたね。
HTTP2では、パケットロスがあるとHTTP1より性能劣化することがあると。
そこでQUICではUDPベースでハンドシェイクはTLSを用いて、暗号化することでこれまでの課題を解決しているという話です。
大型リリースを支えるサーバーアプリケーションの可用性の高め方 〜NieR Re[in]carnation における実践〜
別VPCでGatlingで負荷検証をきっちり行なったという話。
一番、興味深かったのが、脱Kubenetesして、ECSのみとしたこと。
私は関わっていないのですが、社内のクラウドサービスについてもKubenetesを使ってはいますが、ミドルウェアのバージョンアップに手が回ってないんですよね。
作りっぱなしになりがちで、定期的に基盤を変えて検証するリソースがない。
社内の毎日の日報を書くようなところがあるのですが、そこにもKubenetes便利だけど、大変とあったので。
『Ghost of Tsushima』のローカライズができるまで
日英中の三言語対応とかしているのでローカライズは気になってました。
開発が伝えたいことを伝えるということ。
そのために、世界観を理解したり、武士と市民に分けて、使う言葉について考えたりとか、そういった考え方での話が多かったです。
2020年代のゲーム開発のためのクラウドネイティブCI/CDパイプラインの構築
リポジトリをフェッチした内容をスナップショットを生成して、ジョブを流すことで、全ジョブでフェッチせずにに1つのフェッチで解決するという考えはナイスアイデアだなと思いましたね。
Azure VMにスクリプトを流すCLIを公開されているようです。
Slack の導入と設計&運用の変遷 〜 組織の文化・風土に合わせた導入手法とは 〜
Slackなんて使っとる、1時間のセッションをわざわざ聴くのかと思いましたが、Slack Enterprise Gridというのがあるんですね。
チャンネルの権限管理が他のソリューションと組み合わせて行える、と。
育児のチャンネルが出来て、コミュニケーションが自然に広まっていくというのはいいなーと思いましたね。現職だと、そういうことないので。
それどころか、プライベートチャンネルの濫用になって、閉ざされたコミュニケーションしていって、Slackを間違った使い方をしているんですよね。
素晴らしいツールがあっても、使う人、使う会社のカルチャー次第で、変わると。
『アサルトリリィ Last Bullet』アドベンチャーパート開発ノウハウ紹介 ～2021年のアドベンチャーパート開発に必要なルールと知識～
スプレッドシートでアドベンチャーパートのスクリプトを管理されているとのこと。
実際のスプレッドシートの一部も公開されてましたが、へー、こんな感じなんだ、と思いましたね。
月5人以上で、200KBのシナリオを書く必要があるとのこと。200KBって今の時代、小さな容量ですが、200KBで文庫本一冊。
フロッピーディスク1枚1.4MBだったことを思い出しました。
他にもアドベンチャーパートの演出も紹介。
立ち位置の基本を決めておく、カメラワークやカードイラストを使うことでのカットインを使った演出。
表情は、眉３パターン、口３パターン、チークありなしといった組み合わせを用意してあると。
感情の交換、情報の交換、独り言の3つがあると、会話についての分析し、それに合わせてモーションをつける、と。
至高のシナリオチームの作り方 〜リモートワークでも導入できる「ライターズルーム」とシナリオ横串チームによるマネージメント〜
今の自分には関係ないなと見ていたのですが、海外の制作フローが面白いなと思いました。
ショーランナーというシナリオを監督する人がおり、
- コンペティション形式 ... 複数人に個別で自由に書かせて、一番良いものを選ぶ。主に映画で使う方式。
- ブレーンストーミング形式 ... 複数人が話し合って、全体構成を決めて、担当を決める。主にドラマで使う方式。ただし、映画でもシリーズ化されており、使われている。
という二つの方式は、へーなるほどな、と思いましたね。
コール＆レスポンス！- FINAL FANTASY VII REMAKE インターグレード – 生ライブでプレイしてるかのような音楽演出と日英2言語対応プロセス
FINAL FANTASY VII REMAKE インターグレードが楽しみになってくるような内容でした。
- バトルに入るとメロディが入る
- 歌詞の兼ね合いで英語と日本語でメロディが違う
読書感想「BASIC×SHADER: Unityで学ぶシェーダープログラミング」
これはUnityを使って、みっちりシェーダーを触ることができる良本でした。
ただ、4章あたりのVolumeとかは動かし方がわからなかったです。
ToonやSepiaは面白いですね。Toonは3Dモデルをこんな風にできるのか、と。
最終章のPostEffectはなんか使えそうだなと思わせてくれるものばかりです。
Unityの公式ドキュメントでは、シェーダーを「モデル表面のピクセルの見え方を決めるための、数学的な計算とアルゴリズムを格納したスクリプト」と定義しています。Cgは、NVIDIAが開発したシェーダーのための高級言語です。名前の由来は「CforGraphics」であり、C/C++に近い文法で記述できます。
GitHub - midnightSuyama/BASICxSHADER: Unity Shader Code with “BASIC×SHADER”
