  |
はてなキーワード: キャッシュとは
大元エントリが削除されていて、Googleキャッシュが消えた今、誰かが自主的に魚拓やらArchiveやらの保存を選択しておいてくれない限り、はてブで話題になってから見に来る人は内容を確認することができないのがツライ、悲しい、残念、遺憾。
これまでは削除しても、Googleキャッシュですぐに確認できて、それをarchiveに保存することもできたんだよな。
元のエントリがどんなことを書いていたのか知りたかったのにな。Bingキャッシュにも残っていない。
増田で元のエントリの番号を検索して、トラバで内容を類推するしかできない。
https://anond.hatelabo.jp/search?word=20240930083612&search=%E6%A4%9C%E7%B4%A2
今回の場合は元エントリにトラバが3つついていたことで、他のトラバのツリーにスニペット表示が残っていたので、暇空コラボ騒動への嘆きエントリに対して短く「まとまってる情報ある？」と呼びかけるトラバだと分かった。
孫トラバが付く前に子トラバで、無益でろくでもない情報のトラバしかつかなかったから削除したんだろう。
今回は文章が短いからスニペットで全文分かる稀有な例だ。そもそもトラバゼロのエントリはこんな確認できないし、削除されたエントリはしばらく経てばトラバツリーからも消えてしまう。
クリックデータの集計において、毎回全データに対して集計SQLを実行すると時間がかかりすぎ、一方でバッチ処理で集計結果を保存すると、その後に発生したクリックをリアルタイムで反映できないという問題があります。この課題を解決するためには、以下の方法を検討すると効果的です。
---
---
---
### **3. データウェアハウスとマテリアライズドビューの利用**
---
---
### **5. キャッシュとインメモリデータグリッドの使用**
---
---
---
---
### **まとめと提案**
---
1. **要件の明確化**: リアルタイム性の程度、データ量、システムリソースなどを考慮して要件を定めます。
2. **プロトタイプの構築**: 小規模なデータでインクリメンタル集計やストリーミング処理のプロトタイプを作成し、性能を評価します。
3. **システムの実装**: 選定した方法とツールを用いて、実際のシステムを構築します。
4. **モニタリングと最適化**: システムのパフォーマンスをモニタリングし、必要に応じて最適化やスケールアップを行います。
---
---
ご質問の課題に対して、リアルタイム性とパフォーマンスを両立する方法として、インクリメンタル集計やストリーミング処理の導入を強くお勧めします。これにより、新しいクリックデータを即座に集計結果に反映しつつ、全データに対する集計処理の負荷を大幅に削減できます。
PS5 proのスペックと同じスペックのPCを用意しようとした場合、モニターとOSこみで14万円かかる。
本体のみだと11万円となりPS5 Proと値段がほぼ変わらないことになる。
（PS5 ProはASK税込みの1ドル180円で計算した場合、108,000から126,000円ぐらいと思われる）
G.SKILL F4-3200C16D-16GIS (DDR4 PC4-25600 8GB 2枚組)
4,820円
XPG PYLON 550W PYLON550B-BKCJP
6,667円
中古 Intel Core i7-12700 (2.5GHz/TB:4.8GHz) Bulk LGA1200/8C/16T/L3
42,980円
中古 _MSI PRO B660M-E DDR4 (B660 1700 mATX DDR4)
8,590円
Ultimate SU630 ASU630SS-480GQ-R
4,980円
13,262円
SPARKLE Intel Arc A750 ORC OC Edition SA750C-8GOC
31,700円
11,000円
16,090円
合計 140,089円
Intel arc a770（16GB）はfp16だと39tflops程度で、中古だと3.2万円から4万円台で売られており、新品だと4万円から5万円台程度なので、運が良ければps5 proとメモリー以外全く同じやつが手に入ってしまうことになる。
以下、そうなる根拠。
公式発表では、PS5におけるGPUの処理能力は「10.3TFLOPS」。この数字は、RTX2080に相当します。しかし「TFLOPSの数字」と「実際のグラボの性能」は、百パーセント一致するものではなく、性能ほど実パフォーマンスは高くならないのが一般的です。
CPU：CPU周波数最大4.4GHz、Zen4ベースアーキテクチャ、5nmプロセス製造。台湾TSMCが製造を担当。CPUのクロック周波数を10%増加させ、3.85GHzで動作させるモードが搭載される。
（Apple M2と同じく、TSMC製4nmプロセスSoC搭載の可能性もあるとのこと）
CPUキャッシュ：コア毎に64kBのL1キャッシュ、512kBのL2キャッシュ、8MBのL3共有キャッシュ
性能：PS5標準モデルと比べ、通常時で2倍、レイトレーシングでは2.5倍の性能アップ
プロセッサ：30基のWGP（Work Group Processors）、60基のCU演算コア
ROP（Rasterize OPeration unit）：96~128基
メモリ：18gbps GDDR6 256bitメモリ、メモリ容量16GB、バス幅576GB/s、18000MT/s（現行PS5のメモリは14000MT/s）
GPU：GFX1115。GPUコアが現行の18個から30個に増加。これは約1.66倍の増加
GPUキャッシュ：L1キャッシュが128KBから256KBに倍増、L0キャッシュが16KBから32KBに倍増
グラフィック性能：PS5比で45%向上。可変レートシェーディングやハイブリッドMSAAのサポートなど、DirectX 12 Ultimateの新機能を搭載。GPUのアーキテクチャがRDNA 2からRDNA 3に変更される可能性があり、これにより各GPUコアの演算機が2倍になる。
超解像技術：ソニー独自の超解像技術を搭載。高精細と高フレームレートを両立。AMD FSR2等の採用は無し。アップスケーリング／アンチエイリアスソリューション
（AMDのFSR（FiedelityFX Super Resolution）を搭載との話も）
Theoretical Performance
268.8 GPixel/s
Texture Rate
537.6 GTexel/s
FP16 (half)
34.41 TFLOPS (2:1)
FP32 (float)
PSのCPUはRayzen 7 7700X相当で、Intel Core i7-11700だと7割の性能で、Intel Core i7 12700で同じぐらいの性能となる。
昨年、一念発起して100kgの大台から70kgまで、30kgの減量に成功した。
やたらと知見を共有したがるのはエンジニアの美点の一つだが、私もその例にならい、ここにダイエット中に学んだことを共有しようと筆を執っている。
ダイエットとはそもそも、日常の食事のことを指し、それが転じて食習慣の適正化を意味するようになった。
減量の本質もそこにある。
人は食べたものからできている。食習慣を適正化すれば、自然と健康的になる。
30kgもの減量に成功した最大の要因は、自分がエンジニアであったことだと思う。
そもそもプログラミングとは、入力されたデータに対して任意の出力データを得るために加工する、その計算方法を設計し、実装することを指す。
料理もまた同じで、食材という入力に対して、調理を実施し、料理という出力を得る。
そのため、体重と食習慣の適正化というプロジェクトに対して、プロジェクトのマネジメント手法が応用可能なのだ。
メモリ4GBのオンボロPC抱えてパイプ椅子で開発すすめても、ろくに進捗しないのと同じだ。
ただし、闇雲に金をかければよいというものでもない。投資すべきものというのは、だいたい決まっている。
どれも無くても減量自体は可能なものばかりだが、あったほうが効率が良い。
そもそも減量はモチベーション管理のゲームなので、自動化、簡易化できるところはやったほうがいい。
金を払って健康を買っていると考えればよい。
まったくアーキテクチャを考えず、行き当たりばったりでファイルごとに違う設計のプロジェクトは悲惨な結果を招く。
最初にこのアーキテクチャで行くと決め、ひとまずはそれを続けることが大事だ。
減量で言えば、ローファットでいくかローカーボでいくかということだ。
日によって低脂質でいったり低糖質でいったりするのは全く良くない。
自分は低脂質でいくことにした。そのほうが筋肉量の減少を抑えられるし、コレステロール値の改善にも効果的だからだ。
金融系プロジェクトにありがちな細かすぎるコード規約は有害無益で時間と金の無駄だが、余りにフリーダムなのも混乱のもとである。
減量でいえば、目標カロリー量とPFCバランスだ。ここがいい加減だと、到底うまくいかない。
カロリー量はハリス・ベネディクト方程式から出される基礎代謝の1.5倍とかに設定すればよいだろう
そのうえで、低脂質ならP:30%, F:20%, C:50%のように割り振ろう。
たとえば1600kcal目標なら、P: 480kcal = 120g, F: 320kcal = 35g, C: 800kcal = 200g、といった感じだ。
この規約を守るためにも、あすげん/カロミルがあれば、計算が楽だったというわけだ。
プログラミングでは、実行時に行うと重すぎる計算はビルド時など事前に行ったりすることがある。
初代スーパーマリオブラザーズのジャンプは、1フレームごとに重力係数をかけて計算しているわけではなく、加速度がハードコードされている。
ブロック崩しでさえ物理演算するような現代においても、似たようなことをすることはある。
ダイエットで言えば、時間的余裕のあるタイミングで、できることをしておけということになる。
キャベツを千切りにしたり、きゅうりやトマトを切ったり、オートミールに材料混ぜておくことは事前にできることなのだ。
夜寝る前などにやっておき、明日の調理工数を最低限にしておくことが大事だ。
処理したものはジップロックコンテナにでも入れて、冷蔵庫にしまっておこう。
よく食べる鶏むね肉や牛もも肉なんかもキロ単位で大量買いして、1食量ごとに切り分け、ジップロックバッグに入れて冷凍庫に入れておこう。
適切なキャッシュがもたらす実行速度の向上効果は非常に大きい。
これは料理についても言える。
毎食ごとに献立を考え、材料を揃え、包丁で切ったり、コンロで焼いたり…などの調理を行うのは非常に非効率である。
いわば冷蔵庫はメモリキャッシュであり、冷凍庫はディスクキャッシュのようなものである。
よく1人分作るのも3人分作るのも変わらないよ〜などと言うが、同じ理屈で1食分作るのも、3食分作るのも、手間としてはたいして変わらない。
すでに広く使われ、実績のあるライブラリがあるのに、なぜ一から作らなければならないのか。
これはダイエットについても言える。
安価で大量に手に入るカット野菜などは、買ってしまえばいいのだ。
たとえばきんぴらごぼう。作ると面倒なきんぴらごぼうだけど、その面倒さの9割はごぼうを千切りするところにある。
千切りして水にさらし終わったら、きんぴらごぼうの調理工程の9割は終わっている。
しかもこの部分は、工数が量に依存しているため、大量作成の恩恵を受けづらい部分だ。O(n)である。
一方でカットごぼうを大量買いすれば、あとは炒めるだけなので量に依存せず、大量作成が容易になる。O(1)にすることができる。
他にも、オイコスヨーグルトとか、サラダチキンとか、Baseブレッドなどの外部サービスを使うのも良い。
プロジェクトの初期段階、リードエンジニアが重要なクラス群とサンプルとなるクラスをいくつか作った後は、それをひらすらに横展開していくことになる。
この段階では天才エンジニアなど必要なく、コピペマンでじゅうぶんになる。むしろ下手に独自の考えを持たず従順に開発してくれるぶん、そのほうが良いことさえある。
ダイエットについても同じことが言える。
なぜ毎食毎食、独自の健康メニューを考え出さないといけないのか。食事の都度、栄養成分を計算し、調整しなければならないのか。
あすけんで一度100点をとったらあとは、ひたすらそれをこすり続ければいいだろう。
朝
蒸しかぼちゃ
昼
ふかしたさつまいも
蒸しかぼちゃ
夜
りんご（皮ごと）
蒸しかぼちゃ
毎食似たようなものを食べていることがわかるだろう。
これは日単位でも同じで、別の日は牛もも肉が刺し身になったり、さつまいもが蕎麦になったりはするが、その程度の差だ。
どうしても違うものが食べたくなったら、そのときに改めて計算すれば良いのだ。
そうすれば手持ちのカードが増えていく。
インシデントが発生したとき、必要なのはリカバリーであって、そんな時に人を責めても何の役にも立たない。時間の無駄だし、士気も下がるだけだ
こうしたとき、自分を責めても仕方がない。自分をクビにはできないし、ダイエットは長期戦なのだ。
ある日に食べすぎたからと言って、次の日にその分を減らすと、必要な糖質や脂質が不足して代謝が落ちてしまったり、だるさが抜けなくなったりするため、そういう方向でのリカバリーはやめよう。
しっかりと痩せる食事スタイルが確立しているなら、それを続ければ良いだけだ。
どうせ1食程度ではそんなに太ることはできない。
計測は減量期間中だけでなく、むしろ減量終了後にこそ必要になる。
そもそも、減量前の食事が減量前の体重を作り上げてきたのだから、減量前の食事に戻せば、体重も戻るのは当然のこと。
もとの体重に戻りたくないなら、新たな食習慣を作り上げる必要がある。
プロダクトリリース後、つまり減量後の運用フェーズにうつったら、減量飯でもデブ飯でもない、心にも体にも良い食習慣へと移っていこう。
急激なUI変更がユーザーの反発を招くように、急激な食事変更は体重の反発（リバウンド）を招く。
そこで、オートミールだったところを玄米ごはんにするとか、ささみだったところを蒸し鶏にするとか、ちょっとずつ維持するためのご飯へと変えていき、どのくらいの量なら大丈夫なのかを見つつ、ソフトランディングしていこう。
「有給消化はあきらめてほしいってどういうこと？有給消化せずに復職して働いたとしてキャッシュが増えるのか？」と聞いてみればよかったのに。
ちなみに退職予定より先に会社が倒産したら会社都合退職になるから、待期期間なしで失業給付金をもらえるからチャンスだぞ。
どうせ退職する予定の会社なんだから、会社から電話で言われたことなんて無視して有給を全部消化するべきだぜ。
つーか仮に会社が倒産したとして君は労働債権（賃金債権）を持っているから、君の方が会社なんかよりも立場が上だぜ。
倒産する会社から債権を回収するなんて狙ってもなかなかできないことだぞ。
君はハンバーガーの味を感じられなくなる心境だったみたいだけど、俺だったらハンバーガーの味がもっとうまく感じられるんだろうな。
労務詳しい人たすけて
「キャッシュがない、カードや借り入れも限度いっぱいまでしてて1円も払えるものがない、だから有給消化はあきらめてほしい、会社も畳むつもり」
と電話でいわれた。これよくあることなの？？こんなんで逃げ切れるの？？
労基に問い合わせてるけど電話混んでてなかなか相談の順番回ってこない
ただ待ってることが怖くて落ち着かなくてこれを書いています
そもそも私は育休中なのですが、
育休中に会社が買収され、元いたスタッフも社長もいなくなり、今は知らない人たちが事業を継いでいる
ただ、8月に保育園に（やっと！）受かり、会社にその旨伝えると、復職して一緒に働きませんか、と言ってくれていた
が、先週になって「赤字がヤバいからやっぱ復職むり」と話が変わった
私としてもいつ潰れてもおかしくない会社に復帰するのも怖かったのでこれは受け入れた
ただし手続き上復職は必須（復職の証明がないと保育園クビになる）だし、復職後、溜まっている有給（40日分）は消化させてくれと伝えた
その時は担当者も有給一括買取できるか確認してみるね！みたいな感じだった
しかし今日になって冒頭のとおり「キャッシュがないから有給消化むり」といってきた
会社として借りれるところ全部からは金を借りてるしその上で1円もないそうだ
会社も畳む方向で動いてるとか
先週まで消化方法について考えられたのに今1円もないなんてことある？
でもこれを伝えてくるってことは、労基に泣きついてもどうにもならないような手を打ってある？
ちなみに会社はメディア事業をやっていて、普通に今日も更新してるからたとえ今1円もなくても最悪でも毎日アドセンス収入が何万かはあるはず
そこには払うけど私には払わないとか選ぶ余裕があるの？
時間が経つにつれ色々疑問が浮かんでくるけど
私に金を払わない判断してるのは電話口の人ではなく経営者だからゴネても無駄だし
その人には育休手当申請や復職証明なんかもお願いするからあまり心証悪くしたくないし
転職活動しなきゃいけないのにこんなことでいっぱいっぱいになってる場合じゃないのに
他のことが何も手につかない
こんな気持ちになるならオーダーしなかったのに、オーダー直後に電話かかってきたからどうしようもなかった
奮発したのに、悲しい
似たような目に遭ったことある人、なにかわかることある人、同情してくれる人いたら言葉をください
そんな会社にいるほうが悪いっていうのは自分でもわかってる もっと早く転職してればよかったね
神社も銀行がコインの受け入れ有料化してから賽銭のコイン処理には困ってて、
釣り銭のために小銭が必要な地元商店街（銀行で札からコインに両替するのも手数料とられる）と協力して神社が無料両替サービスしたり
https://syoutengai-c.com/introduction-article/honmachi/
賽銭箱にQRコード貼ってキャッシュレス賽銭を受け付けてるところもある。
