  |
はてなキーワード: ストレージとは
めっちゃというか、1日1回は UNEXPECTED_STORE_EXCEPTION か何かで落ちる感じだった
このノートPCの裏蓋にはアルミ箔みたいなのが貼られてあるんだけど
このシールドで、メモリやストレージや何やらをノイズから守ってるんじゃろか
追記：ん－なんか違う。フタきちんと閉めてても落ちる。昼～夕方～夜は落ちないが、決まって朝9時前後に落ちる。
UNEXPECTED STORE_EXCEPTION というのは、メモリ（一次記憶装置）でなくてストレージ（補助記憶装置）側のエラーって事でいいんかね。
ホヨバゲーにおいで具体的には原神かスタレ(3rdはガチオタク向け)
ピックアップ天井は全有償石として2万円ジャストくらいの期待値になる
これ国産ゲーと比較すると基礎排出率0.6%と天井付近以外では滅多に排出しない設定でケチすぎると感じるが、実質コストは安いので良心的
74連目から6%ずつ加算上昇していく変動確率と天井カウント引き継ぎ仕様が特殊で、これを理解してしまえば幸運に賭けてアドレナリン噴出するようなことがなく期待せず着実に回していけるので健康的だし計画的に回せる
配信や公式が上げるYouTubeムービーの類は控えめに言ってもクリエイティビティとIP愛にあふれて優秀なので基本的にコミュニティの雰囲気が良い
ちょくちょくオーケストラ等を動員したコンサートをやって無料配信したり世界各地で大掛かりなリアルイベントをやったりでゲーム外での金の掛け方も桁違い
もちろんゲーム内もサイゲゲー以上のモデリング品質でキャラゲーのように見えつつも戦闘システムやフレーバーテキスト含めた世界観描写が巧妙で、若干翻訳が安定しないことを除けばモバイルゲームの枠越えてる
レアリティはあるがどのキャラにも強みがあるような調整がうまく、色んなキャラを使うことが推奨されるシステムは通じる部分があるだろう
ただPvP要素はどの作品でも排除されているので好みが分かれるが個人的には心穏やかに好きなペースで遊べる要因なので良いと思う
例外というか原神に関してはゲーム内コンテンツとしてTCG(カードゲーム)があって野良対戦も可能、単体アプリで出せるくらいの出来なんで戦略的なゲームが好きならハマるかもしれない
典型的な日本ソシャゲユーザーが抵抗ありそうな部分は横持ち必須でスペック要求・ストレージ要求多めなところくらいか
もしスマホが限界で手頃なゲーム用スマホが欲しいならRedmi Note 12 Turboあたりを個人輸入してみるのがいいかもしれない
Dockerは、開発から運用まで一貫した環境を提供することで、開発者の作業負担を減らすという大きな利点があります。また、仮想マシンと比較してリソースの使用効率が高いため、エコとも言えます。
ただし、確かにDockerには一定のオーバーヘッドが存在します。これは、DockerがゲストOSを持たずに、ホストOSのカーネルを共有して動作するためです。それにより、アプリケーションの実行に必要なリソースが追加で必要になり、パフォーマンスに影響を及ぼす場合があります。
また、Dockerを利用する際の設定や構成によってもパフォーマンスは大きく変わります。例えば、Dockerのネットワーキングやストレージの設定、またホストOSとの互換性など、考慮すべき要素は多数存在します。
あなたの現在の状況について具体的に述べると、FESSのクローリングが重いという問題は、Dockerのオーバーヘッドだけが原因ではない可能性があります。Dockerコンテナ内のFESSやJVMの設定、ホストマシンのリソース割り当て、ネットワークやストレージの設定など、様々な要因が絡んでいるかもしれません。
また、Dockerのログ出力が多いと感じる場合も、実際のところはFESSやDockerの設定によるものかもしれません。ログの出力レベルを調整することで、必要な情報だけを出力するように設定することも可能です。
しかし、これらの設定を調整するためには一定の知識と経験が必要で、それがなければ素直にネイティブ環境での構築が良い選択かもしれません。結局のところ、どの方法が最善かは具体的な要件や状況によります。
このような状況に直面した際には、パフォーマンスの問題を具体的に分析し、適切な解決策を見つけるためにパフォーマンスモニタリングやロギングツールを使用することをお勧めします。それにより、問題の原因を特定し、適切な対策を講じることが可能になります。
たとえば、Dockerが高いCPU使用率を示している場合、それはコンテナ内のアプリケーション（この場合はFESS）が高いリソースを消費している可能性があります。その場合、アプリケーションの設定や実行パラメータを調整することで改善できるかもしれません。
また、Dockerコンテナのリソース制限を調整することも検討できます。Dockerは、コンテナに割り当てるCPUやメモリの量を制限する機能を提供しています。これにより、他のプロセスに影響を与えることなく、特定のコンテナのリソース使用量を管理することが可能です。
さらに、Dockerのボリュームやネットワーク設定が適切であるかを確認することも重要です。不適切な設定はパフォーマンスに悪影響を及ぼす可能性があります。たとえば、ファイルI/Oのパフォーマンスは、ホストOSとコンテナ間でデータを共有する方法に大きく依存します。そのため、適切なボリュームの設定や、パフォーマンスを向上させるための最適化オプションが適用されていることを確認することが重要です。
最後に、Docker自体のアップデートもパフォーマンス改善に寄与する場合があります。最新のDockerエンジンには、パフォーマンスを改善するための修正や改善が含まれていることがあります。
これらの要素を考慮に入れ、Dockerのパフォーマンスを最適化する方法を探すことができます。ただし、これらすべてを試してもパフォーマンスが改善しない場合や、必要な知識や時間が不足している場合は、Dockerを使用しないネイティブな環境での構築が最善の選択であるかもしれません。
『2001年宇宙の旅』シリーズによると人間の記憶総量は 1TB らしい。
だとすると一枚の絵の元ネタをバックトラックするのに必要なデータは最大 1TB になる。
一枚の画像を 1MB とすると、1,000,000 枚分の換算だ。
ひとつの画像を特定するのに必要なハッシュのデータ量が 1KB ならば、脳内画像すべてをハッシュ化した場合の総量は 1GB で済む。
AI イラストのオリジナル権利者に使用料を支払うためにはサーバー内に最大、 画像数 × 1GB のデータ が必要になる。
Pixiv の登録画像総数は 1億1800万点 にものぼるとのことだが、これらがすべてネタ元の照会を要求されうる AI 画像だとすると、およそ 100PB のハッシュデータが必要だ。
最近のストレージ界隈では SSD の値下がりが話題になっていて、1GB あたり 5円 を切る製品が出回っている。
すなわち、およそ 5億円 あれば遡って権利者を特定するための記録装置だけは確保できるということだ。
https://b.hatena.ne.jp/entry/4736080561518980709/comment/TakamoriTarou
https://www.security-next.com/145617
https://aws.amazon.com/jp/s3/pricing/?nc=sn&loc=4
添付ファイルと言ってる感じはExcelかWord、もしくは画像か
これを書いてる時点で米ドルは 134.84円
| 1 W | 2 W | 52 W | ||
|---|---|---|---|---|
| kB | 10338900 | 20677800 | … | 537622800 |
| GB | 9.85994339 | 19.71988678 | … | 512.7170563 |
| USD | 0.061624646 | 0.123249292 | … | 3.204481602 |
| JPY | 8.309467292 | 16.61893458 | … | 432.0922992 |
| JPY (SUM) | 8.309467292 | 24.92840188 | … | 11450.44593 |
支払い総額を一般化すると ΣY(k) = [JPY/W]*k*(k+1)/2
五年後には支払い総額は 281,940円
五年後の容量は 2564 GB
ただ置いてあるだけで、月に8642円が出ていく
まあ件のシステムでホワイトリスト形式でファイルを消しているのは容量を節約しているのではなくてセキュリティ的な側面だろうとは想像するが
効果のほどははっきりしないとしてもね
CacheStorageが肥大化することはよくあるのだが、実はこれ、外観上のサイズと実際のストレージサイズは連動していない。
実際に保存されている内容は多くても数MB、大半は1MB未満のファイルが大量に保存されているだけだが、その合計も数MB、それでもデフォでは350MBになる。実際に消費されているのは数MBなので表示上の問題だけ。
これはOpaque responseというセキュリティ上の制約らしい。
https://stackoverflow.com/questions/39109789/what-limitations-apply-to-opaque-responses
はてぶの上位にちょいちょい載ってるTBS系のニュースサイト、newsdig.tbs.co.jpについて。
https://b.hatena.ne.jp/site/newsdig.tbs.co.jp/
何がヤバいかって、くっそ巨大なCookie(LocalStorageとかも含むのか知らんけど)をしこたま保存してんのよ。
気付いた時点では640MBも占有してた。別に巡回チェックしてるわけでもなく、話題に挙がってたら見てみることもある程度のアクセス頻度なのだが。
Chromeユーザーはアドレスバーに↓コピペして確認してみてくれ。
chrome://settings/content/all?searchSubpage=tbs.co.jp&search=cookie
試しにCookie消去してから、ただ開いただけでサイト上で何の遷移もしてないのに279MBも保存された。
次点ではpresident.jpが553MB消費してた。(こっちも話題に挙がってたら見てみることもある程度。)
(その次にはGoogleが数百MBオーダーで消費してたけど、これはGoogleドライブのオフラインキャッシュとか考えれば妥当。他に数百MBオーダーで消費してるサイトは無かった。)
多くのサイトは数バイト～KBオーダーなのに、こいつら何保存してんのか不気味すぎる。
(追記)
各自の環境の消費量を教えてくれた方々や有意義なコメントを下さった方々ありがとうございます。
始めにお断りしておくべきだったかもしれませんが、自分はソフトウェア系ではありますが、Webエンジニアではありません。認識が浅かったり、古かったり、そもそも間違ってる可能性もあります。
CookieじゃなくてCacheStorageやんけと突っ込みもいただいていますが、「LocalStorageとかも含むのか知らんけど」と書いておいた意図は(どのような技術要素かはどうでもよくて)ユーザー端末に保存されるデータボリュームについての話を意図しています。ChromeのCookie絡みの設定画面での表示なのでこのような書き方をしましたが、解り難かったのならごめんなさいね。冗長ながらも認識齟齬を招かないように平易な表現で書くと、「ユーザの明示的な承諾なくユーザー端末に保存されるデータがデカイんだが」って話です。
で、各自の環境で「ユーザの明示的な承諾なくユーザー端末に保存されるデータ」が数GBオーダーにも及ぶという事例が少なからず報告されて、自分の環境だけではない事象だということが判りました。
さらにtbsとpresident以外にもいくつかのサイトが同様に肥大化していることも知れました。
結果的にはid:hinaloeさんの解説が解りやすかったです。ありがとうございます。
https://blog.hinaloe.net/2023/04/27/chrome-too-large-cache-storage/
CacheStorageがChromeの表示と、実際のディスク消費量と一致していないことが原因であると理解しました。
追試してみたところ私の環境ではChromeの開発者ツールでの表示が74MBで実際のWindowsのファイルシステム上は33.9MB消費されました。
実際のストレージの消費は表示値の半分程度ということになり、id:hinaloeさんの1.4GBに対して5MBのように実際の約0.3%という結果とは大きく乖離がありますので、各環境で大きく違いそうな気がします。
%USERPROFILE%\AppData\Local\Google\Chrome\User Data\Default\Service Worker\CacheStorage
※配下のどのディレクトリが対象サイトのものなのか一意に特定する情報が無さそうなので、Chrome開発者ツールのApplicationタブの左上の方にあるService Workersを選択すると、右側にReceived YYYY/M/D HH:MM:SSみたいな表記が有るので当該時刻に変更されたタイムスタンプを持つディレクトリを特定するような感じになるかと思います。
ついでに開発者ツールを触っていて気付いたベースで書いておくと、
といった感じで、ユーザが見たものをキャッシュしているのではなくて、先読みしてるような挙動に思えます。
ロード時間短縮でUX改善を狙ったものかもしれませんが、個人的にはそれを1か月も保持し続けるのは過剰な感じがしますが世の中的にはどうなんでしょうね？
(追記2)
hinaloe氏の投稿で紹介されているStackOverflowの投稿やそのリンク先のChromiumのバグレポートのやり取りまで目を通してみると、特に理由の説明なく平均7MBがパディングされると書かれた投稿があります。
https://stackoverflow.com/questions/39109789/what-limitations-apply-to-opaque-responses
https://bugs.chromium.org/p/chromium/issues/detail?id=796060
該当するソースコードは↓のようです。
この中で、ComputeRandomResponsePadding()という関数を呼び出しておりその実体は↓のようです。
この関数は符号無し64bit整数の乱数(つまり、0～18446744073709551615のいずれか)を14431 * 1024 = 14777344で割った剰余(つまり、0～14777343≒約14MiB)を返却します。
これがパディング値として採用されることになりますが、乱数が正規分布している前提で、平均すると(最大値14MiBの半分で)約7MBになるよねってことだと思われます。
故にChromeの設定画面から確認できるCookie等(LocalStorageとかCacheStorageとか諸々含む)のサイズは、概算してCacheStorageに存在するファイル数×平均7MBが過大計上されていることになりそうです。
これでChromeの設定画面から確認できるサイズと、実際のファイルシステム上で消費されているサイズの違いは合理的に説明できますが、TBS等の特定のサイトだけデカくみえる理由の説明にはならないのです。
なんなんすかね？
限界が来た
初めは仕事できるねってたくさん褒められた
今は同じ注意を何度も受けて怒られる
そんな事ばかりになってきた
すっぴんで出勤するようになって
つまらんミスしないよね、って褒められてたのに最近はつまらんミスばっかり
あーあ、今日も私はダメだった…と落ち込みながら帰宅すると、帰りが遅いと親にチクチク言われる
仕事が忙しくて帰りが遅い日が続くと激しく叱ってくる
厳しいというより、両立ができていない
何も身についていないのが自分でもわかる
３月は特にひどかった
仕事が多すぎて帰れなくて、理解が浅いまま時間ばかり気にして仕事をするから適当になって、怒られて、学校の課題もできなくて、講師に注意されて、家に帰っても気まずくて、しんどかった
一度学校をサボった
最終的に死ぬほど多忙な上司に向かって「眠いです」と正直に言って定時に帰らせてもらうという愚行に出た
そんな中嬉しいこともあった
必要なアプリも入れられないくらいで困っていたので早速インストールした
そして、昔の友人が結婚式に招待してくれた
ニートになってから誰とも連絡をとっていなかったから、友達の結婚式なんて初めてだ
お祝儀に交通費、レンタルドレス、美容院、結構お金がかかるが、貯金は足りそうだ
私は元々、たくさんの情報を整理するのが苦手なほうだ
不注意もある
賢く生きられない
我ながら無茶してるが、これで上手くいきそうだった
……上手くいきそうだったのに、数日前から片方の耳が聞こえにくくなった
「眠いです」と言ってしまって帰った日から、上司の機嫌が非常に悪い
突発性難聴のことも、結婚式の日に有給を申請したいことも言えない
色々と上手くいってないけど
またひとつひとつ頑張って、少しずつでも調子を取り戻していこうと思いながら帰宅した
どうせくだらないDMしか来ないからストレージ節約のためにアンインストールしてたけど、なんか来てるかもしれないと思った
頭が真っ白になった
親に出してもらった金なのに
仕事をそんなに任されないうちに資格を取っておくのが理想的だったのに
就職して頑張って
資格取るために頑張って
人生なんとかしようとしていた
上司に言ったら残念な「顔は」してくれると思う
が本音だろう
親にはとても言えない
「死ね」と言われると思う
私も、こんな人間死んだ方がいいと思う
何のために生きてんだろう
もう消しちゃったから正確じゃないかもだけど15時間ちょいくらいでクリアしたと思う
サブクエは４，５個くらいやった
あまりにも虚無すぎるしイージーだったら幽霊でレベル上げしなくてもよくて回復アイテムがぶ飲みでいけるって気づいてからやめたけど
気づくの遅かったー
回復アイテムは道端に落ちてるので十分足りてるから買う必要ないし
ただマップ上ですきまとかも通れるのはよかったな
見えない壁で通れないとかはほぼなかった気がする
建物の中に入れなかったり階段上れなかったりするのも多かったのは正直クソだったけど
あとやたら屋上とかにコレクションアイテム系があるのに上る手段が限られてるのもクソだったなー
天狗を使ってスパイダーマンみたいにするらしいけど都合よく天狗いないし
せっかく高いとこのぼってもちょっとした操作ミスですげー高さ落ちて苦労無駄になるのほんま虚無
メインはあっさり
掘り下げもほとんどなかったし
コレクション系アイテムとか、ほりさげっぽい音声ログの場所もスキル使わないと自力で見つけるの無理だし
ほかのゲームみたいに入手したら即再生して聞きながら移動とか他の事できたらよかったのに
これまでやった海外製fpsだとこうは感じなかったってくらいのエイムしにくさを感じた
爽快感もなかった
致命攻撃みたいなやつでブルブル震えたりはするけどうざくしか感じなかったし
ステルスも敵の感知範囲広すぎてまともにやる気になんなかったし
印（敵を攻撃する魔法みたいなの）が使えなくなる場面があったとこ
もともとある便利能力を使えなくさせてもストレスしかなんねーだろってパターンが多いけど、
これはあまりにも印があると虚無すぎたからいいカンフル剤になってたわ
2回くらいあったな
ただまあそれでも逃げるだけじゃなくて弓矢（笑）とかいう攻撃手段あるから敵倒せちゃうんだけどね
しかも印より強いという（笑）もう全部弓矢でいーじゃんみたいな
まあ矢の入手手段が限られてるからあくまでも緊急避難的なものでしかないけどね
まあナイフより強いけど
ｐｓ５のストレージ足りなさすぎるわー
小学校中学年くらいのころ、「写真」というものにはいろんなものがあるのだと気づいた。
読んでいる雑誌やガイドブックにあるような写真はカメラで撮ったもので、それは最近持たせてもらえている写るんデスなどでも同じように撮れるのだと。
だから、両親に連れて行ってもらったディズニーランドで、風景の写真を沢山撮った。自分が読んだ本みたいな写真になればいいな、とワクワクしながら。
「こういう時は一緒にいる人を撮らないとダメだ。なんの思い出にもならないじゃないか」
自分の意図はうまく説明できなかった。それから以後は父から言われたような写真だけ撮ることにした。
すっかり携帯やスマホで周囲の風景や遊園地のあちこちの飾り付けを撮るのが当たり前になっている今、ときどきこのことを思い出す。いまはフィルムの数に限界はない(ストレージの限界はあるけど)。
つまり、機能的にはマイナス評価ボタンの ON/OFF をブラウザ上で切り替えているだけで、Google Analytics でボタンが押されるコメントの傾向などを調査してるだけみたい。
調べてみたらひどいクソ仕様だったので、同じ轍ふまないように知見共有します。
なお、消えてしまったデータは息子の卒業式の動画データ。復元不能。
ストレージは壊れるものという前提は理解しているつもりなので、状況ごとにいくつかのバックアップ体制は取ってある。
安くなったとは言えすべてのストレージをSSD化するには至っていない。
そのため、OSやソフトウェアなんかはSSDにインストール、写真や動画などのサイズがでかいデータはRaid HDDでミラーリングして格納するようにしている。
それ以外にもそれほどサイズの大きくないデータはonedriveとかのクラウドストレージを利用。そのデータもRaid HDDでミラーリングして二重にバックアップ体制を敷いている。
趣味で写真をやっているのだが、今回の事故はその編集のフローの中で起こった。
編集と格納は別で考えているので、アクセス速度が高いほうがいい編集はSSD上で行い、格納はRaid HDDに行っている。
そのタイミングでgoogle photoに分散バックアップ、必要に応じて家族なんかと共有を行う。
つまり、撮影が終わったら最初にすることは、SSD上にあるデスクトップの一時フォルダに写真と動画データをコピーすることから始まる。
Raid HDDに格納するのは、編集ソフトでレタッチが終わってからだ。
まずは写真データから編集を行い、RAWデータから無事にjpegデータへと書き出してHDDへの格納が終わった。
そのタイミングで妻からの頼まれごとのためにメールをpdfプリントして名前をつけて保存しようとした。
めったに使わない機能なのだが、指定されたのはonedriveフォルダだったので、そのまま保存をクリック。
ところが、PCからonedriveフォルダにアクセスしても出力したpdfデータが見つからない。
おかしいなと思ってもう一度出力を試みて保存フォルダのパスを確認してみる。
すると、今現在HDD側に指定してあるonedriveのパスが、SSD上のデフォルトのパスに指定されているようだった。
ここで思い至ったのが、確かPCにonedriveを設定した際にうっかりデフォルト設定のまま起動してしまい、その後、HDD上にパスを切り替えたという状況だった。
「そうかぁ。保存先を変更すると元のファイルを移動させるんじゃなくてコピーを作ってしまうんだな」なんて感じに妙に納得しつつ、もう一度しっかりとパスを確認した上でpdfをコピーしてからSSD上のonedriveをshift deleteで削除した。
エクスプローラーを閉じてデスクトップに戻ってくると妙な違和感。
ない。
はぁ？と思ってPCをダブルクリックすると、すぐに警告ウィンドウが開いて「デスクトップへのパスが間違っています」といったエラー表示。
焦る。かなり焦る。
ウィンドウをすべて閉じても、デスクトップ上にはデフォルトのアイコンだけが並んでいるだけ。
頭真っ白。
多少大事なデータはあったかなと思いながらも致命的と言えるものは思いつかず（まだ見落としてるだけかもしれない）、しかし、すぐに一時フォルダごと動画データがないことに気づく。
写真はすでにjpg出力してあるので、RAWデータが消えてしまったのはなんとかなる。
子供の卒業式の動画はまだ変換をかけてもないし、当然アップロードもしていない。
終わった。
あまりにもショックだ。
読み飛ばしここまで。
結局何が原因だったかというと、最初にonedriveをセットアップする際に、デフォルトの保存先、なおかつデスクトップやマイドキュメントなんかもバックアップに含めるという設定で始めてしまったからだったらしい。
この、onedriveのバックアップにデスクトップを含めるという操作をすると次のようなことが起こる。
「本来はC:\Users\ユーザー名\Desktopにあるはずのデスクトップデータが、C:\Users\ユーザー名\onedrive\Desktopに変更される」
・onedriveのバックアップからデスクトップを含めないように設定変更
この2つの動作を行ったにも関わらず、何故かこのパソコンのデスクトップは、C:\Users\ユーザー名\onedrive\Desktoに残ったままになってしまったというわけだ。
そのため、C:\Users\ユーザー名\Desktopにデスクトップがあると思いこんでいた自分は、C:\Users\ユーザー名\onedriveにあるonedriveのフォルダを、疑うことなく削除することができた。
そしてその結果、デスクトップにおいてあったデータのすべてを失った。
いや、流石にこんなクソ設定想定できないでしょ。
大事なデータを守るっていう名目があれば、大事なデータの格納先をそんな簡単に変えていいと思ってる？
それ、誰に許可取ってやってるんだよっていうさ。
その辺の共通プロトコルを、バックアップソフトが、しかもOSの提供元がやっていいのかよっていう。
これはちょっと言わせてくれ。
マイクロソフトクソだわ。
まぁ、なんというか皆さんも気をつけてください。というか、こんなの気をつけようがないけどな。
どこに気持ちをぶつけたって息子の大事な思い出は帰ってこないのはわかってるけど、やるせなさくらい吐き出させて。
※追記
ブラウザonedriveのゴミ箱にデータが残っている可能性はゼロです。
その理由は以下の通り。
このパソコンは1ヶ月ほど前に新規にセットアップしたものでした。
そのセットアップの過程で、onedriveをインストールする際にデフォルトの保存先、なおかつデスクトップをバックアップという設定にしてしまいました。
ここでノールックで設定してしまった自分が一番悪いことは認めます。
onedriveのセットアップが終わったあと、同期に時間がかかっていておかしいな？と思ってファイルのアップロード履歴を確認したところ、あらかじめ古いパソコンからコピーしてあったデスクトップのデータをアップロードしようとしていたので、慌てて設定を見直して、デスクトップ同期のオフ、保存先をHDDに変更しました。（変更した順番は書いてある通り覚えていません。順番が逆だったら起こり得なかったかも）
この操作によって、onedriveの保存先はHDDに変更になり、デスクトップの同期も停止しました。
しかしそうした操作を行ったにも関わらず、デスクトップの保存先はC:\Users\ユーザー名\Desktopに戻ることはなく、C:\Users\ユーザー名\onedrive\Desktopのままになってしまっていました。
そのことに気づかずに1ヶ月以上作業を続けていたなかで、記載の通りSSD内に同期されていないonedriveフォルダを発見したので削除した結果、デスクトップのデータが消失しまったという話です。
そして卒業式の動画データをデスクトップにコピーしたのは、onedriveの同期を切ったずっとあとのことです。
もともとonedriveにバックアップするつもりもないし、バックアップされていないのでwebに残っているはずもないのです。
デスクトップのデータがそんなところに格納されていることがわかっていれば、もともと削除なんてしません。
同期されていないすでに使われていないonedriveのデータだけしか削除するつもりではなかったのに、何故かその中に現在進行系で使っているデスクトップのデータが格納されていて、一緒に削除されてしまったというお話です。
ちなみに、削除直後は本当に何が起こったのか意味がわかりませんでした。
その後にマイコンピューターを開いた際、別ウィンドウでエラーが出たことで初めて状況が理解できたということです。
そのエラーが「デスクトップC:\Users\ユーザー名\onedrive\Desktopにアクセスできません」といった内容のエラーです。
デスクトップ？お前なんでそんなとこに保存されてたの？からの、そういえば思い出してみればこんなことあったよなーで、原因に思い至ったというわけです。
SDカードの復元を試みましたが、サイズの大きい動画データですので、ヘッダーは読み込めたものの、データそのものはすでに別の写真データに書き換えられてしまっていたせいかちゃんと開けませんでした。
SDカードからデスクトップにデータを移すタイミングというのは、行事ごとに撮影が終わったらSDを空にして新しく撮影できる状況を作るためなので、基本的にはデスクトップにコピーしたあとは次の撮影前に必ずフォーマットすることを習慣づけています。
それは、毎回SDカードを空っぽにすることで、現像のときにデータの重複が起こらないようにするためです。（趣味で写真を取っているので撮影枚数が莫大。尚且つ現像ソフトで不要データを削除するので、SDを空にしないと、削除後にまたコピーしてしまったりと効率が悪いため）
撮影→データをデスクトップに一次保存→次回撮影時にSDカードのフォーマット→時間があるときにPC上のデータを選別、現像→バックアップ含めてデータを格納→SDカードから新しい撮影データをPCにコピー→次回撮影時にフォーマット→時間あるときにPC上のデータを選別、現像→・・・・
SDカード自体も紛失の危険性とか考えてそれほど信用しているメディアではないので、できるだけデータが保管されている時間を短くするようにしています。
個人的には、このワークフローが一番データの保存性も高く、無駄も少ない処理方法だと思っています。
だって、デスクトップを間違って消すなんてこと普通しないでしょ。
壊れたなら仕方ないって、それはそれで納得できるんだって。
流石にこんなことまで想定したワークフロー作れってのは無理な話ですよ。
すでにonedriveからデスクトップの同期も切ってて、しかも別フォルダでonedriveがちゃんと稼働してるのに、まさか自分のデスクトップがC:\Users\ユーザー名\onedrive\Desktopに保存されてるなんて思う？
物が多くてストレスを感じることはよくあります。身の回りにあるモノを整理し、必要なものだけを残して身軽になることは、心の健康にも良い影響を与えると言われています。以下は、物を捨てて身軽になるためのアドバイスです。
1. 使っていないものは捨てる
まずは、使っていないものを捨てましょう。例えば、古い衣類、壊れた電化製品、読み終わった本などです。これらは、もう必要ないものであり、ただ場所を取るだけです。捨てることでスペースが生まれ、身軽になることができます。
次に、必要なものを最小限にしましょう。例えば、同じ種類の服や靴がたくさんある場合は、必要な数だけ残して、それ以外は捨てるか寄付することを考えましょう。また、一度に大量に買わずに、必要になった時に購入するようにすることも大切です。
3. デジタル化する
書類や写真など、紙媒体のものはデジタル化して保存することで、スペースを節約することができます。また、クラウドストレージや外付けハードディスクを活用することで、バックアップも取れます。
4. 物を借りる
必要な場合は、物を借りることも考えましょう。例えば、旅行用のスーツケースや大きな工具類など、一度しか使わないものは購入する必要がありません。友人や家族から借りることで、スペースを節約することができます。
以上が、物を捨てて身軽になるためのアドバイスです。必要なものだけを残し、デジタル化することで、スペースを節約し、ストレスから解放されることができます。
今の40代オタクがボクの師匠、プログラムもCGもDTMも師匠のおかげを書いた増田です。
お前が技術を中心に情報補完しろよと言われたので知っている範囲で情報を補完します。
ただやっぱりネタバレするとゲッサン編集部や作者氏から叱られそうなので、まったく本編には影響しないであろう部分を中心に情報補完させて貰います。
先に謝っておきますがネタバレ回避を考えたら第1話で語れる部分がココしかなかったっす・・・。
主人公の和田一馬が所持するガラケーはデザインに微妙な違いがあるけれど、おそらくはau W41CAで2006年の春モデル。
W41CAはペンギンケータイとも呼ばれたCASIOのヒット機種で、外観はCASIOらしく少々無骨、旧機種のW31CAでは赤外線通信やおサイフケータイへ非対応だったものの、W41CAでは対応を果たし全部入りケータイになった。
ペンギンケータイの由来ともなるマスコットキャラクターのアデリーペンギンが画面上の様々な部分で演出として登場し、ポップなオレンジの筐体色とも合わせてその可愛らしさから人気を博した。
W41CAは無骨さの中にある可愛らしさで人気となったが、CASIOのWn1CAシリーズは本来サラリーマンに高い評価を受けていた端末で、WordファイルやExcelファイルを閲覧できるPCドキュメントビューワーやPC向けWebページを閲覧できるいわゆるフルブラウザを搭載しつつ、USBマスストレージ接続が可能な端末であり、更にはFMラジオを受信できるなど当時のギークからも非常に高い評価を得ており、CASIOガラケーの銘機としてガジェット界隈では歴史に刻まれている。
当時を知る者であれば常識的な話だが、CASIOというか当時のauは学生へ対して強く訴求する携帯電話通信キャリアで「学割と言えばau」という認識が世間でなされており、auや携帯電話へ搭載する機能や展開するサービスも学生を意識したものが多かった。
取り上げているW41CAも着メロの最大発音数は128のステレオ再生、PCM音源の再生機能である着うた(AAC/48Kbps)にも対応していた。しかもSD Audio Playerを搭載しておりminiSD(microSDではない)にUSBマスストレージ経由で保存したAAC(96Kbps)の再生が可能であった。
ちなみにヒロイン(？)が使っている携帯電話は現在でもINFOBARを生み出したとして話題となるau design projectの第3弾端末であるau talby。2004年冬モデルで製造は三洋、型番がA5508SA。デザイン以外に語る部分がぶっちゃけない。
というか当時からハードウェアスペックに関して語られることがあまり無かった機種で、掲示板などで携帯電話のスペックを誇ったり最大限に活用するための情報交換などをするギークなユーザが選ぶ機種ではなかったので殆ど知らないというのが実情。
INFOBARは目新しさもあって結構いろいろ情報交換されたものだけれど第3弾ともなると正直言って失速気味になっていた。
ただ、主人公が最新の携帯電話でヒロインが型落ちのデザイン重視な携帯電話、学生なのでauという細かな描写は作者の意気込みを感じる。
個人的にはこの時期の携帯電話を挙げるならauではなくVodaphoneとNTT DoCoMoから発売されていたNokia 6630を推したく、これがまたSymbian S60で・・・と話が逸れるので別の機会に。
W41CAに搭載されている音源はYAMAHA AudioEngine MA-7i(YMU791)で、前述の通りFM音源の最大発音数は128でステレオ再生が可能であり、AACやMP3のデコードへ対応するなど非常に多機能で多くの携帯電話端末に採用されることとなる2005年に登場した最新LSIによる音源だが、W41CAでは何故かMP3デコードなど一部機能が制限されている。
着メロ形式はSMAF(MMF)で150Kbyte(153,600byte)まで、FM音源の使い勝手としては4オペレータの最大発音数128で、更にFM音源側の最大発音数を減らすことで最大16bit/12,000HzのPCM音源データを使うことが出来、同様にFM音源側の最大発音数を減らすことで着うた登場前後に一瞬だけ流行ったボーカル付き着メロで活用されたHV(合成音声)も使える。
エフェクターなども内蔵しておりMA-7シリーズは当時の着メロ職人からはかなり評価の高い音源であったものの、NTT DoCoMoしか注目しなかった頭内定位を利用した仮想サラウンド再生のための3Dポジショニング機能も実装されており、いつの世も空間に対するオーディオというのは経営者と技術者の心を掴んでしまうんだなと林檎マークを見て思いを馳せる。
ただ人気だったW41CAにも欠点はあり、当時のケータイアプリ開発者から悪名を欲しいままにしたezアプリ、つまりBREWアプリが採用されていた。当時のauは野良アプリ(勝手アプリ)開発者を締め出すことへセキュリティの都合上から躍起となっており、公式ez web以外の経路からのアプリインストールを著しく制限していた。
この制限が無くなるのは平成ヲタク リメンバーズの時間軸で言えばほんの先の未来である2007年に登場するオープンアプリプレーヤー(OAP)を待つ必要があり、W41CAは、というかau端末はその点からギークに毛嫌いされることがよくあった。
BREWアプリの欠点はそれだけでなく、これはBREWアプリよりも前のezplusアプリ時代からそうなのだが1日のアプリ内携帯電話パケット通信3MB制限という謎の縛り(後に6MBまで上限緩和)が設けられておりユーザとケータイアプリ開発者双方からヘイトを買う一因となっていた。ちなみに他社は1度のパケット通信量の上限はあったが1日の上限は無い。
いやそもそもQualcommからカフェインよりもアルコールだよと騙され酔っぱらいJAVAからBREWへ乗り換えたこと自体が愚かで、他社はJAVAのままなので単に開発負担が増え、auで公開されるケータイアプリが減るという結果しか生まなかった。これが解消されるのが前述したOAPであり、OAPの正体はBREW上に構築されたJAVA VM環境であった。
しかしこのOAPもBREW側のセキュリティパーミッションのせいでパケット通信するたびに通信を許可するためのダイアログが表示されるなど不便極まりない仕様であったためユーザの反感を買ってしまう。
マニアックなネタばかり詰め込んでもアレなので、平成ヲタク リメンバーズの本編に影響しないよな？とビクビクしながら選んだのが当時流行っていた携帯電話を活用した位置ゲームのコロニーな生活。当初はウィルコム端末向けだったが後に他の携帯電話通信事業者にも対応し、2005年にコロニーな生活☆PLUSとして改称アップデートされた。
このコロニーな生活☆PLUSはブラウザゲームの一種でコロニーな生活☆PLUSのURLへアクセスするだけでゲームへ参加できた。1km以上の直線移動距離を稼いでゲーム内通貨を貯め、自分の土地の施設を充実させ住民人口を増やしていくというゲーム。
当時を知っている人ならばオチが直ぐにわかっていると思うので間を置かず言ってしまうと、コロニーな生活☆PLUSの略称はコロプラ、現在では白猫プロジェクトやディズニーツムツムの開発元で知られる株式会社コロプラの祖業である。ちなみに今でも一応はスマートフォンアプリでサービス継続しており名称も「コロプラ」へ改称している。
平成ヲタク リメンバーズの世界の時間軸にプレイヤーは存在するだろうけれど今後ネタ被りしたら申し訳ない。
ネタバレ回避も必要だし始まったばかりの第1話でとやかく言えることはないですね。読者の興味を惹こうとする単語が現れたりするので走り出しとしては及第点なんじゃないかなと。
むしろ前述したように登場するガジェットをしっかりと時代に合わせたものにしていたりとセリフやキャラクターだけでなく登場する小物にも注目したほうが楽しめるのかも知れないというのが第1話への感想と今後への期待です。
作者氏は同年代だと思われるので、敵に回すと恐ろしいが味方につけると頼りないと言われるVIPクオリティを発揮してくれたらなと楽しみにしてます。うはｗｗｗおｋｗｗｗｗｗ
