2099-03-31

このブログについて

仮投稿、記載修正予定

Twitter:

メイン(低稼働): @gasegi
VR用アカウント: @nerinuvr
Dev: 記載予定

2019-11-04

会社に対する思いの走り書き

最近行った韓国のホテルから見下ろした景色

殴り書き#

久しぶりの更新がこんなものであれだけど、更新テストもかねて投稿。

以下注意

‪個人的なことなので自分以外誰も読む必要はないです。‬
‪※この話は実在する団体等とは関係ありません。フィクション(笑い)です。‬
今の感情ともことなります。

本文#

恐るべきことに気づいてしまった‬

‪プライベートでパソコンを勉学や開発に使用すると、その時間に比例して会社のPCの性能が相対的に下がり(会社のPCは大変高性能であり、私の使用方法ではChromeを閉じることに20秒もかけてくれるのである)会社での体験が悪化する。これは到底看過できないことである。‬

‪勉学や開発というのは自身のPCをゲームあるいは簡単なタスクを除く時間に割り当てられており、自身の成長を渇望し努力を重ねるほど会社での苦痛も強くなるということになる。‬

‪会社の掲げる理想の社員像に「自己勉学に励む」などというものがあるが、このような状態では自身には全く面白い冗談である。‬

‪性格上、「止む終えない事情により自身の力を発揮できないこと」に対する受け止め方に不具合があると自認していて、「すべてを許して諦める」か「不都合を取り除くことに執着する」のどちらかに倒れてしまい、いい塩梅で対応するのが苦手である。それを無理やり抑え込むといろいろ不都合がある。‬

‪社会の中で、どうにもならないことというのはままあることで、それに対しては不器用ながらも「すべてを許して諦める」ことにより、付き合っていくことで今までやってきたが、この件に関しては自身はどうしても「どうにもならないことと捉えることができない」ので、これを社会とのすれ違いと捉えている‬

‪社会とのすれ違いは、「社会を変える」か「自身の所属する社会を変える」かどちらかで対処できなけば解決しないが自身にここをどうにかできる力があるとは考えていない。‬

‪社会を変えるよりは自身の所属する社会を変えるほうがまだ可能性が高い。‬

‪また解決せずに諦めるという手はあるが、これは自身の思想に対して長期的に悪影響を与えると予想できるため将来の自身のためには取りたくない選択肢である。‬

‪これらを踏まえて、今後はさらに大胆な選択肢も含めて自身の行く先を決めていかなければならないと強く意識していくべきであると考える。‬

2019-06-23

AWS Summit Tokyo 2019 メモ書き「Amazon Workspacesの運用管理」

はじめに#

このページは AWS Summit Tokyo 2019 のセッション B2-03 「Amazon Workspacesの運用管理」のメモです

詳細は公式のガイドを参照してください。メモは主に個人用です。

台数規模の大きい利用シーンでの Amazon Workspaces の利用
自動化
- バックアップ
コスト可視化

台数規模の大きい利用シーンでの Amazon Workspaces の利用#

台数規模の大きい利用シーンでの Amazon Workspaces の利用では以下の要素が重要です

構築、再構築、デプロイ
→自動化
- Workspaces API/CLI
- 特定の操作では管理者に即座に通知など
- AWSサービスを利用してWebサービスやSlack等からリクエスト受付、API Gateway、Lambda、DynamoDBに処理が流れ、SESとStep Functionで管理者承認を実装し、その許可拒否によって処理変更
状態確認
⇒メトリクス取得
- CloudWatch Metrics、Dashboard
  Metricsは、Dashboardで画面上にグラフィカルに表示、Agentで仮想環境にドライバをインストールし細かいデータも取得可能、Agentのカスタムメトリクスを使用
  WorkSpacesが増えるごとに設定不要
- ログインイベントをトリガとした対応(CloudWatch Events）、特定IP以外のアクセスでWorkSpaces強制停止など
データ取得
→インベントリの確認
- QuickSight,Athena,WorkSpaces APIを使用。CloudWatch Events(time-based)からLambdaを実行

自動化#

Inventry Dashboard が使用できる

セキュリティアップデート→パッチ管理
→WSUS.SCCM
- ネットワークトラフィックに注意(台数が多いとトラフィックが増加するため、WSUSサーバをAWSに移動させるのを推奨)
データ保全バックアップ
→バックアップ、リカバリ
- ルートボリューム(C)、ユーザーボリュームを提供
  シンプルなバックアップ機能を提供

バックアップ#

ルートボリューム、ユーザーデータを保存しない

ユーザーデータ、12時間ごとにスナップショットが自動実行、WorkSpacesに障害発生時には、リストアする
RPOがより必要なら、ファイルサーバを推奨

コスト可視化#

→Cost Explorer

WorkSpaces の課金オプションを選択するための情報を得る
WorkSpaces Cost Optimizerで前月の使用実績から自動的に課金オプションを変更、ドライラン、一部のWorkSpacesを除外
裏ではコンテナを稼働させる。CloudFormationで展開、20台の管理に20セント程度

2019-04-20

Blender いくつかの作業メモ

はじめに#

いくつかの作業のメモ

Blender: 2.79b
Cat Blender Tool: 0.12.2

読み込んだアバターのフルボディトラッキング
メッシュを分割する
シェイプキーを Unity で扱う際に扱いやすい形に並び変える

読み込んだアバターのフルボディトラッキング#

あらかじめ下の[Import Model]ボタンを押してインポートしています

以下の画像のように、すべてチェックを入れればとりあえず問題なく動作します

メッシュを分割する#

Model Option の Separate By [Material] を使用する

分割されたメッシュを再度結合するには、基本的に Fix Model を使用します
あるいはアウトライナーで Shift キーを使い結合する対象をすべて選択後、 3Dビューにカーソルを持って行ったあと [Ctrl+J] を押すことでも達成できるかもしれません

シェイプキーを Unity で扱う際に扱いやすい形に並び変える#

この画面で右の▲▼ボタンで直します
下にA-Zなどで並び替える機能がありますが、表示上のみで記録されないので、手で直す必要があります

2018-06-03

設計メモ

思ったことをデータに残しておかないともったいないので、走り書きで残す
基礎の基礎も含めて網羅したい

新しいことが書きたくなった時にこれを更新するか、新しくページを作るかは考える

目次#

試験行程に必要なもの
試験行程で行う実際環境とのマッチについて
設計について
他チーム、顧客に提示する必要があること

試験行程に必要なもの#

試験行程はテストシナリオがなければ正確に行えない
テストシナリオは正確な設計書がなければ作成できない
正確な設計書は正確な業務フロー、業務シーケンスがわからなければ作成できない

試験行程で行う実際環境との調和について#

顧客環境で動かす場合、それが一般に普及したブラウザ上で動くものでもない限り、先行検証を行うほうがベター
（ただし、ブラウザ上で動くものでも、性能要求を満たせているか確認する目的は達成できるため検証をする価値はある）
検証によって利用するアプリケーションやDLL、ライブラリ、ファイアウォールとの相性や実際の環境の性能においてパフォーマンスが出るか、確認できる

顧客人員の個人PCで動かすならそのPC（と可能ならばネットワーク）を借りて、
顧客の自社運用サーバーで動かすならできれば同様スペックのPCを借りて試す

設計について#

設計において、何かの要求について起こりうる業務フローをしっかりと検討する
検討した業務フローに対して必要な機能が定まる

データ登録機能に対して、排他制御機能
個人PCインストール機能に対して、インストーラー機能、バックアップ/リストア機能

複数のパターンが考えられる場合は、資料上でわかりやすく示す必要がある
以下の図示方法の利用が考えられる

デシジョンテーブル
シーケンス図
フロー図

他チーム、顧客に提示する必要があること#

他チームに連携する必要があるのは、まず他チームと連携して動作する必要がある事柄。

業務フローに対して、どのような方法(json,rpc,ファイルストリーム)でやり取りをするか
やり取りの標準的な形式、（エラー、情報の）メッセージ情報のやり取りのkey、形式、内容
想定される文字種やデータ形式

他には、自身のアーキテクチャ設計の範囲内で製造業務を行うメンバーに対して、

開発を行うにあたり、用意しなければいけないアプリケーション、環境構成、変更が必要な設定

2018-05-21

プロダクション環境で起きたエラーの収集とハンドリング

webpack で処理した Node.js アプリケーションのエラーを取得する#

Visual Studio Code (VSCode) で Node.js のプログラムデバッグをする時、 webpack で処理してしまうと
生成後のコードでブレークする。 JavaScript 特有かつ頻出の問題。

これらに対処するために、 Source Map (ソースマップ) という仕組みがある。
生成するためのライブラリ (https://github.com/mozilla/source-map) が Mozilla から提供されている。
ただし、ソースマップを利用するだけならこのライブラリの存在を知る必要はない。

この問題に対応するには以下の手順を踏む。

webpack で devtool (https://webpack.js.org/configuration/devtool/) の設定を行う。
VSCodeの デバッグ起動 (https://code.visualstudio.com/docs/editor/debugging) の設定を行う。
デバッグ起動を行う。

個別手順#

1. webpack での設定を行う。#

以下のページを元に、ソースマップが出力する。

https://webpack.js.org/configuration/devtool/

設定の種類が多いが、開発 (https://webpack.js.org/configuration/devtool/#development) や
製造 (https://webpack.js.org/configuration/devtool/#production) の通りに設定すれば問題はない。

要約すると以下のようにすればよい。ページにも記載があるが、 devtool を使用する場合、
SourceMapDevToolPlugin / EvalSourceMapDevToolPlugin は必要ない。

ケース	設定
開発時	`eval-source-map`, `eval`, `inline-source-map`
製造時	`hidden-source-map`

基本的に eval から始まる設定で良いようだが、手元の環境では zone.js を使用しているからかわからないが、
eval-source-map でビルドした結果が実行できなかったので source-map を使用した。

2. VSCodeのの設定を行う。#

VSCodeのデバッグ起動に関する基本はデバッグ起動で確認することができるが、
Node.js(Javascript) 固有の設定はNode.js VSCodeでのデバッグの方が詳しい。

Ctrl+Shift+P を押しコマンドパレットで launch.json と入力することで「Debug: Open launch.json」という
コマンドを実行する。
表示された選択肢は Node.js 、なければ Other を選択する。

作成されたファイルに以下のように設定を記載する

{
  // Use IntelliSense to learn about possible attributes.
  // Hover to view descriptions of existing attributes.
  // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
  "version": "0.2.0",
  "configurations": [
    {
      "type": "node",
      "request": "launch",
      "name": "Launch Program",
      "program": "${file}",
      "protocol": "inspector",
      "sourceMaps": true,
      "sourceMapPathOverrides": {
        "webpack:///./~/*": "${workspaceRoot}/node_modules/*",
        "webpack:///./*": "${workspaceRoot}/*",
        "webpack:///*": "*"
      }
    }
  ]
}

name , program 辺りを自身の環境に合わせて設定しておく。

注意しなければならないのが、 protocol であり、これは必ず "inspector" を指定しておく。
これをしておかないと、 Node.js のバージョンが6系以下を使用した場合に "legacy" が指定された事になり、ソースマップが利用されない可能性がある。
"inspector" 設定は、現時点でサポートされている全ての Node.js バージョン (>= 6.3 (Windows: >= 6.9)) で
サポートされているので、 Node.js が古すぎて使えない場合はアップデートを行う。 (バージョン6系も既に古すぎるというツッコミはしてはいけない)

基本はこれらの設定で問題ないはずだが、もし動作しなければ、最初に outFiles , sourceMapPathOverrides 辺りをいじってみる。

3. デバッグ起動を行う。#

F5 でデバッグ実行を行う。実行する起動設定を聞かれたら 2. の name で指定した項目を選択する。

オリジナルソース（エディタで編集を行っているファイル）上でブレークポイント (F9) を設定して正しくブレークされれば成功。

2018-05-02

最初のページ (initial-page)

一番最初のページ (initial page)

nerinu diary

ねりーぬだいあり

このブログについて

会社に対する思いの走り書き

殴り書き#

本文#

AWS Summit Tokyo 2019 メモ書き「Amazon Workspacesの運用管理」

はじめに#

台数規模の大きい利用シーンでの Amazon Workspaces の利用#