GPD WIN2のSSD換装でいろいろ失敗したので覚書
GPD WIN2を購入したのですが、その時色々失敗したので、失敗の経験の共有として覚書
SSD購入、しかし、精密ドライバがないから蓋が開けられない
先端サイズ+000の精密ドライバーが必要になるがなかった (持っていたはずだが失くしていることに気が付いた)
仕方がないので購入した……のだが、後にダブるのである
SSDを刺し込み損ねてリカバリを開始し、リカバリメディアをフォーマットする
後に気づくのだが、SSDがちゃんと刺さっていない状態で本体付属のリカバリUSBメディアを挿入しリカバリを開始した
するとリカバリ用のブートプログラムは唯一のドライブであるUSBメモリのリカバリメディアをリカバリ先とみなしてUSBメモリをフォーマットするらしい (というか、フォーマットされた)
結果、当然リカバリには失敗するし、リカバリ用メディアも失う羽目になる
改めてリカバリメディアを作るためにドライバなどをダウンロードする
公式サイトの GPD WIN 2 Pocket WIN XD Laptop Game Console Game box Video Game Player Gamepad からリカバリメディア用のファイルを改めて取得する
これが9.33GBもあり、さらにダウンロード元のMEGAというストレージサービスはアカウント作らないと大きなファイルはダウンロードできない
仕方がないのでアカウント作ったのだが、無料ユーザーだと帯域制限があり、合計9.33GBに及ぶファイルをダウンロードするには金を払うか、5GBダウンロードする毎に数時間のインターバルが必要になる
と言う訳でここで半日程度かかる
無事SSDを換装できたので古いSSDをUSBメモリ化するケースを購入する
このUSBメモリ化するケースに精密ドライバーがついてくる
じゃあ最初に精密ドライバー買わずにこれ買えばよかったじゃん
ギャフン
2018年の抱負の進捗状況 (7月1日時点)
この記事は自分向けの記事です
もうちょっと頻繁にblogを更新する
個人的にはもう少しかけた方がよいと思っているのですが、今アウトプットよりもインプットの方が楽しくなっており、「これブログのネタになるかな」と思ってもなかなか記事を書かない、更新しないという状態になっています
無理に書こうとして、そもそも何もかも嫌になって投げ出すのが今までの自分のパターンなので、気が向いたらと言う事で
体重を60kgまで落とす
の朝が64.85kgでの朝が61.40kgでした
目標は60kgですが、現在体脂肪率が10から9%台となっており、大変ばて易い状態になっています
体重60kgは手段であって真の目的は健康になる事であり、その意味では既に目標を達成している状態なので、様子を見ながら過ごしています
HTML5.2の仕様書を一通り読む
3月中旬にいったん作業を中断してからそのまま止まってしまっています
また、年始の頃の勢いは昨年末からやっていての貯金あっての状態だったので、この後はスローペースで続けることになります
なお、HTML5.3の勧告の方が明らかに先なので、そうなったらHTML5.3へ移ることになる見込みです
……もしかして永久に終わらないのでは
応用情報技術者試験に合格する
受かりました
合格者の平均年齢は29歳前後なので42歳の自分が合格するのは順当なのですが、それはそれとして素直に嬉しいです
応用情報処理技術者試験の合格者は合格から2年の間、高度試験および支援士の試験の午前I免除というのがありますので今年の目標は達成とした上で秋にも何か受けてみよう思います
IPA 独立行政法人 情報処理推進機構:情報処理技術者試験:高度試験等の一部(午前Ⅰ試験)免除制度
情報処理技術者試験の高度試験、情報処理安全確保支援士試験の一部免除対象となる条件(いずれか一つでも満たせばOK)
もうちょっとだけ続くんじゃ
Oculus Go購入拙速感想文
安い、早いで話題のOculus Goを購入したところ、思った以上の没入感に感動したので感想文を書きます
入手2日目の勢いで書いた感想文なので技術的な事は一切期待しないでください
結論
3万円以内でこの体験ができて私は買ってよかったと思っている
決め手は視野のかなりの範囲を奪う没入感
今までPS VRでVRゴーグルを使っていたが、PS VRよりもOculus Goの没入感の方が上
しかし、あくまで没入感という個人の感覚に属する物なので、人によってはそう感じないとか、Oculus Goを被っている事が気になって集中できない、没入感が得られない人も居るかもしれない
Oculus GoはVRのビュワーとして必要な機能を一通り備えているように思うが、入力がヘッドギアの3DoFと片手分のコントローラーだけなので入力装置としては弱い
購入する際はVRビュワーと割り切って使うことに成ると思われる
Oculus Goの良い点としてスタンダロンと言うのがあるが逆にこのため手持ちのBlu-rayを見ようとしたり、著作権保護されているOculus Go非対応のコンテンツを見ようとするとできなかったりかなり面倒なことに成ると思われる
言うまでもないが、視界をすべて奪われるのでながら作業が不可能になる
Oculus Goのなかでも基本的に1つのアプリしか起動できないので360度ディスプレイであるが、「正面にYoutube、右側にTwitter」みたいな使い方は出来ない
また、キィボード入力はVR内のヴァーチャルキィボードを使うことに成るので、各種サービスにログインする位であれば問題ないが、キィボードを使ってのチャットなどには向いていない
よって、既存のディスプレイでは不可能なVRコンテンツを体験するか、1つのコンテンツに集中して大画面で何かを視聴する作業に向いているデバイスである
そもそもなんでOculus Goを買おうと思ったのか
- Twitterなどで話題になっており、流行り物として興味を持った
- ストレージ32GB版が23,800円、64GB版が29,800円とVRヘッドセットしては安い
- セットアップにiPhone/Android Phoneは必要だが、スタンダロンで使える
- スタンダロンなのでPCのスペックや、空いているUSBポートやコンセントを気にする必要がない
- 安さなりの性能と言う事で不満の声が聞こえない
- カメラが付いていたら嬉しいとか、コントローラーがもっと高性能なら、トラッキングが6DoFなら ( Oculus Goは3DoF) という声も聞こえるが、値段相応と言う事でお買い得と言う声の方が圧倒的に多い
ちなみに6DoFと3DoFの違いはいらすとやさんのイラストでご確認ください
自分の購入からセットアップの流れ
購入ガイドではなく、あくまで私が購入した流れです
- 5月下旬あたりから上記の理由で欲しいなと思い出す
- 5/29 に Oculus Go | Oculus で購入を試みるが自分の持っているVISAカードでの支払いが通らない (私の場合、名義の表記に揺れがあり、不一致でVISAカードが使えないことがよくある)
- 5/30 7:00頃にPayPalアカウントを作り、併せてサイトからOculus Goを注文完了
- 5/30 21:30頃に出庫のメールを受領
- 6/1 に自宅で宅配の不在票を受領 (配送日指定ができなかったので平日日中帯に配送いただいたが受け取れなかった)
- 6/2 再配送で受領
- Zenfone5にOculusのアプロをダウンロードし、Facebookのアカウントでログイン
- Oculusのアプリに従ってOculus Goを自分のFacebookアカウントに結び付けたり、Wifiの情報を転送したりとか
- Oculus Goに眼鏡のスペーサーを取り付ける Oculus Go | Inserting the Glasses Spacer - YouTube
- Oculus Go被って使い始める
ちなみに、自分は購入していませんが、鼻があんまり大きくない平均的な顔立ちの日本人はついでにFitted Interfaceを買うのもいいかもしれません
使ってみて
- 今までPS VRでVRゴーグルを使っていたが、PS VRよりもOculus Goの没入感の方が上
- ヘッドセットの角度をかなりしっかり調整しないと、視野の中心のピントが合っていても視野の端のピントがボケることがあるので最初にしっかり被るの大事 (この現象の問題の原因がOculus Goのレンズか、眼鏡か、私の眼その物かは分からないが)
- スタンダロンなのでケーブルが絡まったりしないのが嬉しい
- 一方、スタンダロンなのでOculusに転送したり取り込めない著作権保護付きのコンテンツは見られない
- Blu-ray見るならPS VR
- Oculus GoでNetflixを使って映像を見てみたが、視野に対するスクリーンの大きさでは劇場鑑賞並み
- ブラウザは天井を向いてセンターをリセットすれば天井にブラウザの画面が出るが、Netflixのスクリーンは横固定なので布団に寝てNetflix見ようとするとVR天井を眺めることになる
- 解像度の荒さなどはわかるもののそもそも私は目が悪いこともあって不満に思う程ではない
- スクリーンの大きさ基準で劇場並み、下手な劇場や席より良いとする人がいても納得する
- 音はOculus Goのステレオスピーカーの音で劇場の圧勝
- 3.5mmのミニピンイヤホンジャックも備えているので手持ちのヘッドフォン次第ではあるが被るだけのお手軽さが減るし、視界を完全に奪われた状態で装着するの手間
- YoutubeやNiconicoはブラウザで見る事ができる (NiconicoはVR用アプリもあるがGear VR用のインタフェースの様でOculus Goでも使えるが、微妙に不便)
- Huluはログインできるが著作権保護に阻まれて再生できない
- ブラウザはタブブラウザ?だが2画面同時は見られないのでながら作業は出来ない
- Oculus Go、首の方向の動きに対する画面の追従は違和感がない (3DoF)
- 方向の追従のみなので方向を固定して歩き回っても画面は動かない
- コードレスなので360度くるくる回ってもコードが体に絡まるということはない
- このため回転機能を備える椅子に座り、椅子の周りからぶつかる物をどけてOculus Goを被るとお手軽に360度向きを変えながらVR環境を楽しめる環境になるようだ
- 調子に乗ってくるくる回ると現実同様に酔う
こんな感じ
2018年の抱負の進捗状況 (6月1日時点)
この記事は自分向けの記事です
もうちょっと頻繁にblogを更新する
5月28日にWindows 10 April 2018 Updateで追加された和暦のレジストリィの話を更新しましたが、本当はゴールデンウィーク中に書こうと思っていた記事で、何とか5月中に間に合わせで書いて公開したような感じになってしまいました
書きたいことがあったのに書かずに放っておいて、公開するのを目的かして公開するという自分としてはよくないblogの書き方をしているので改善したいところです
体重を60kgまで落とす
の朝が67.15kgでの朝が64.85kgでした
日々多少の増減はあるものの、最近はBMIがコンスタントに24程度、体脂肪率は12%程度になっており、BMIや体脂肪から見た状態では脱肥満となりました
この調子でいけば10月には目標が達成できそうなのでこの調子で続けたい次第です
HTML5.2の仕様書を一通り読む
5月はほぼ進みませんでした
読めたのは数段落で、2.7. Common DOM interfaces (共通DOMインタフェース) で完全に詰まっている状態です
興味が薄くてやる気が出ない、英文が難解で理解するための邦訳作業に時間がかかるが要因となっており、2.7. についてはいったん飛ばして興味があったり、楽に読める箇所までいったん読み飛ばしてしまうことを検討しています
応用情報技術者試験に合格する
合格発表はなのでそれまではモラトリアム期間です
Windows 10 April 2018 Updateで追加された和暦のレジストリィの話
追記 (2019/4/2)
次の元号として令和が発表されましたので、令和のレジストリィを追加するPowerShell Scriptを書きました
Windowsに令和のレジストリィを追加するPowerShell - 木俣ロバート久の覚書 - Hatena Blog
追記 (2018/6/25)
.NET Framework の新元号対応予定について – Japan New Era Name Support Blogにて.NETの仕様変更が発表されました
アメリカ時間のからupdateが提供が開始され.NETの挙動が変わるため、本記事の内容と異なる状態となる見込みですのでご注意ください
各所既報の通り Windows 10 のWindows 10 April 2018 Update (1803) で元号のレジストリィに、に改元予定の仮データが入りました
例によってPowerShellで取ってみます
PS >Get-Item 'HKLM:\SYSTEM\CurrentControlSet\Control\Nls\Calendars\Japanese\Eras';Hive: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Nls\Calendars\Japanese
Name Property
Eras 1868 01 01 : 明治_明_Meiji_M 1912 07 30 : 大正_大_Taisho_T 1926 12 25 : 昭和_昭_Showa_S 1989 01 08 : 平成_平_Heisei_H 2019 05 01 : ??_?_??????_?
ちなみに、"?" や "?" は文字化けの類ではなく、Unicode でいう 'QUESTION MARK' (U+003F) や 'FULLWIDTH QUESTION MARK' (U+FF1F) の文字が仮データとして入っています
あくまで仮データではあるのですが "必ず漢字かアルファベット" だと思い込んでレジストリィから取得した値をエスケープせずに正規表現に突っ込むと本番では起こらない筈のエラーが出たり意図しない挙動になります (なった)
また、例えばファイルを和暦の文字列で "H30.05.28" のようにしているシステム場合、現時点でレジストリィから値を取得してファイル名を作ると 2019年5月1日のファイルの名前が "?1.05.01" となりファイル名として "?" が使えないためエラーになったりするかも知れないので仮データならではの注意も必要になります
更に、平成31までの日付の文字列は DateTime型に変換できていますが、平成32年以降の日付は変換できなくなっています
PS >'平成31年12月31日' -AS [DateTime]; 2019年12月31日 0:00:00PS >('平成32年1月1日' -AS [DateTime]) -Eq $null; # -AS で変換しているので変換できなかった場合はNullになる True
また、明治を1、大正を2として明治以降のその時の元号のカウントを返すGetEraも2019年5月1日以降は5を返すようになっています
JapaneseCalendar.GetEra メソッド (DateTime) (System.Globalization).aspx)
PS >[System.Globalization.JapaneseCalendar]::New().GetEra([DateTime]'2019/4/30'); 4PS >[System.Globalization.JapaneseCalendar]::New().GetEra([DateTime]'2019/5/1'); 5
以上は.NETの話で、独自実装されたものは勿論それぞれがレジストリィを参照しているかどうかの実装次第ですし、例えばExcelのVBAの場合、 では新元号には対応しておらず、平成32年以降の日付も使えている状態です
例えばセル内のデータを 2030/5/1としてセルの書式設定で元号表記にすればH42.5.1となります
以下のようなマクロで処理した場合も平成のまま処理が行われます
Function ChangeJapanese(ByVal DateString As String) As String ChangeJapanese = Format(DateString, "ggge年m月d日") End FunctionFunction ChangeChristian(ByVal DateString As String) As String ChangeChristian = CDate(DateString) End Function
- セル内の式:
=ChangeJapanese("2020/5/1")
- セルに返却される値: 平成32年5月1日
- セル内の式:
=ChangeChristian("H40/1/1")
- セルに返却される値: 2028/01/01
というわけでプログラマ各位としては和暦文字列と日付データの変換個所やGetEra
の結果が5でも問題ないか (例えばSwichに入れた結果 Default で未知の元号扱いにしていないか……実際現時点では未知の元号なので正しいといえば正しいのですが) などを確認しておいた方が無難かもしれません
もし改元が江戸以前のように数年に1回程度発生してればシステム側としてももっとノウハウがたまっているかと思うのですが、今回は30年ぶり、次回はいつになるか分からないので今回できるだけ記録を残したいなあ、と思っている次第です (改元の契機を考えるなら次の元号も長く続いた方が嬉しいのですが)
2018年の抱負の進捗状況 (5月1日時点)
この記事は自分向けの記事です
もうちょっと頻繁にblogを更新する
内容は兎に角、進捗状況報告以外に2本記事を書いたので良しとする、くらいの感じです
もっと内容をとか言っていると書かなくなるので、チラシの裏レベルでもとりあえず更新する癖を付けましょう、位の緩い感じで
体重を60kgまで落とす
の朝が69.4kgでの朝が67.15kgでした
私の身長が165cmなのでBMI が25未満 (67.15/1.652 ≒ 24.7) になり、BMI基準で標準になりました
引き続き60kgを目指しますが、生活習慣を見直して健康になるという目標は今の所、達成できているようです
HTML5.2の仕様書を一通り読む
3月中旬から4月中旬まで忙しくて仕様を読めていなかったのですが、そのまま4月下旬になっても再開できていません
この手の作業はやる気の問題云々ではなく、単に習慣づけて「空いた時間に自然にやる」位の所に持っていくのがベストだと思うので、「暇になったらtwitterみる」ではなく「暇になったらHTML5.2の仕様を読む」位に持っていきたい所
あまり気張ると疲れちゃうので今後ともだらだら続ける心算です
応用情報処理試験に合格する
4月15日に受験しました
合格発表はです
午前、午後とも回答欄を埋めることは出来 (午前はマークシートなので埋められて当たり前なのですが)、それなりの手ごたえはありましたので秋には受かるんじゃないでしょうか (駄目じゃねぇか)
今どきの安全なパスワードについて
2008年にサーヴィスごとに異なるパスワードの生成法と言う記事を書いていたのですが、この内容が (当時から、あるいは現在の基準だと) 間違っている為、内容を更新します
結論: サーヴィスごとに十分な長さのパスワード (パスフレーズ)を使う、漏洩の疑いがある時は迅速に変更し、定期的な変更は不要
パスワード (単語レベル) ではなく、パスフレーズ (単語の集まり) を使い、長い文字列を使うべきです
例えば英数字と記号をランダムに組み合わせた '2v9s!nQ%' よりも 'petbottlecrystalfacility' (PET bottle, Crystal, Facility) の方が安全です
また、サーヴィスごとに異なるパスワード (パスフレーズ) を使うべきです
パスワード (パスフレーズ) が漏れた疑いがある時は迅速に変更する必要がありますが、定期的な変更をするよりも長いパスワード (パスフレーズ) を使った方が安全です
(以降、この記事ではパスワードとパスフレーズを統一してパスワード書きますが、推奨するのはパスフレーズです)
サーヴィスごとに異なるパスワードを使う
サーヴィスごとに異なるパスワードを使うべきなのは今も変わりません
十分複雑なパスワードを使っていても全てのサーヴィスで同じパスワードを使っていれば何かの拍子に漏れた時にあらゆるサーヴィスのパスワードが漏れたのと同じことになってしまいます
サーヴィスごとに別なパスワードにした場合に問題になるのは管理方法ですがサーヴィスからパスフレーズを生成するか、OSやブラウザのパスワード管理機能やパスワード管理ツールを使うのがお勧めです
管理が面倒だからと簡単なパスワードを設定したり、同じパスワードを使いまわすより、普段はOSやブラウザのパスワード管理機能やパスワード管理ツールに任せ、何かの拍子に必要になったが思い出せない時はパスワードの再設定をした方が良いでしょう
長いパスワードを使えば定期的なパスワードの変更は要らない
仮にアルファベット小文字のみ8桁のパスワードが30日で突破される恐れがあるとします
ならばそのパスワードを1桁増やして9桁にすれば26倍の複雑さになり、突破されるまでの期間は 26×30日 = 780日となり、5桁増やせば265×30日 = 3億5644万1280 日、つまり約97万5910年となります
突破されれる恐れがある短いパスワードを定期的に変更するより、突破されにくい長いパスワードを使うべきです
使用する文字の種類を増やすよりも長いパスワードにする
パスワードの組み合わせは使用する文字種のパスワード桁数乗になります
パスワードの桁数の上限が8桁程度と少なかった場合、使用する文字種を増やすとパスワードの組み合わせが増えるため良いことでした
- アルファベット小文字のみ8桁の場合の組み合わせ
- 268 = 2088億2706万4576通り
- アルファベット大文字小文字、数字、記号10種の (計72) の8桁の場合の組み合わせ
- 728 = 722兆2041億3630万8736通り
しかし、パスワードの桁数を増やせば使用する文字種が少なくても十分複雑なパスワードを作ることが出来ます
- アルファベット小文字のみ11桁の場合の組み合わせ
- 2611 = 3670兆3444億8698万7776通り
アルファベット小文字のみ文字26種類のパスワードでも11桁あれば文字72種8桁のパスワードの約5倍複雑なパスワードを作ることが出来ます
ですので8文字のパスワード、例えば 'babymaze' を8文字のまま 'a' を '@' に 'e' を '3' にして 'b@bym@z3' と言うもパスワードを作るよりも、覚えやすい単語、例えば "fish" を足して "babymazefish" にした方が、より複雑で人間にも覚えやすいものになります
なお、前述の 'a' を '@' に変えるような変換や、キィボードを隣にずらすようなノウハウは攻撃者側も十分の承知しているため、安全性を高めることになりません
ありがちなパスワードは駄目
一般的にパスワードは入力を受ける側はハッシュ値で保存しています
ハッシュ値とはある値を別の値に不可逆的に変換した値で、例えば 'cat' が 'WNS'、'dog' が 'HYB' になったりします (あくまで例です)
暗号化と違ってハッシュ値は変換後の値から変換前の値に復号するのが非常に困難ですが (基本的に総当たりで計算することになる)、予め 'cat' が 'WNS'、'dog' が 'HYB' になることが分かっていれば逆引き辞書を作り、'WNS' なら 'cat'、'dog' なら 'HYB' と知ることが出来ます
このような攻撃者の逆引き辞書でパスワードが突破されないために「辞書に載っている文字をパスワードにしてはいけない」と言われています
この場合の「辞書」とは攻撃者が用意する逆引き用の辞書の事なので、一般の辞書には乗っていなくても 'aaaaaaaa' や 'p@ssw0rd '、'abcd1234 '、'qwertyui' あるいは日付になる様な8桁の数字などありがちなパスワードは使ってはいけません
そして前述のように 'Password' のようなありがちな単語を 'a' を '@' に変えて 'P@ssword' にしてもパスワードとしてやはりありがちな単語のままであり、安全性を高めることになりません
部分的に辞書に載っている単語でも問題ない (全体はだめ)
前述のように一般的にパスワードは入力を受ける側はハッシュ値で保存しています
しかし、先の例のように 'cat' が 'WNS'、'dog' が 'HYB' になる場合でも 'cat' と 'dog' を連結した 'catdog' は 'WNS' と 'HYB' を連結した 'WNSHYB' にはならず、全く別な値になります
このため、パスワードの一部分が辞書に載っている単語でも全体として辞書には載っておらず十分複雑なパスワードなら問題ありません
(パスワードの一部が予め攻撃者に知られてしまっているのは話が別です、念のため)