  |
はてなキーワード:cacheとは
携帯電話【080xxxxxxxx】利用停止予告、12月分4,751円料金引き落と失敗。
PayPayの自動支払い：
$curl -Ihttps://example.invalidHTTP/2 301date: Wed, 21Jan 202611:48:18GMTcache-control: no-cache, no-storeexpires: -1location:https://qr.paypay.ne.jp/XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXengine: Rebrandly.redirect,version 2.1strict-transport-security:max-age=15552000
これクリックするとPayPayが起動して
携帯料金(4751円)請求書払いさんに送る4751円
が表示されるんだわ
クリックしたら一巻の終わり
発信元はここな
https://www.telnavi.jp/phone/07047294320
通報しといたわ
https://www.internethotline.jp/reports7/
本物のURL を増田に貼るのはOKなのだろうか？っていうのはちょっと疑問なんですが、例えば詐欺のURL をそれと分かって貼るのはどうなんでしょう？
じゃあ消しといたよ
本物見たい奴はhttps://web.archive.org/ でhttps://anond.hatelabo.jp/20260121205222 を探して
問題 1
あなたはある企業のAWSアーキテクトです。既存のオンプレミスの金融データをAWSに移行する必要があります。移行後、すべてのデータは 削除や上書きができないように保護 する必要があります。
A.AWS StorageGateway +AmazonEBS +Object Lock
B.AWS DataSync +Amazon S3 +Object Lock
C.AWS DataSync +Amazon EFS +Object Lock
D.AWS StorageGateway +Amazon S3 +Object Lock
回答C。 AWS StorageGateway は名称てきにオンプレミスと sync しなさそうだから、DataSync -> EFS だと考えた。S3はストレージだからなし。
問題 2
Auto ScalingグループにあるEC2インスタンスのスケールインが発生しました。
デフォルトのスケールインポリシーの場合、どのインスタンスが優先的に削除されますか？（3つ選択）
C. 最も最近作成されたLaunch Templateのインスタンス
D. 最も古いLaunch Templateのインスタンス
スケールイン,スケールアウトの違いがわからない。アウトは拡大する、インはスケール縮小？
回答：A, 多いほうから削る。D, 古いものは削除、E,残り時間が少ない順から削る？
問題 3
グローバルに展開するアプリケーションがあり、ログイン処理が遅く、HTTP 504エラーも発生しています。
CloudFrontを利用してコストを抑えつつ、パフォーマンスを改善する方法として適切な組み合わせはどれですか？（2つ選択）
A.複数リージョンにアプリを展開してRoute 53のレイテンシルーティングを利用
B.CloudFrontのオリジンにCache-Controlmax-ageを設定してキャッシュ比率を上げる
C.Lambda@Edgeを使って認証処理をユーザーに近い場所で実行
D. 各リージョンに複数VPCを作りTransitVPCで接続してSAMでLambdaを配置
E.CloudFrontのオリジングループでフェイルオーバーを設定
回答：BとCかな。Aは手数が多すぎる。非効率かなと。Dも工数がかかりそう。手作業で複数作るのかな？Eはこういう設定して意味あるのかなと思った。
問題 4
医療系企業がAWSで複数のアプリケーションVPCを作成します。各アプリは 共有サービスVPC にアクセスする必要があり、アプリ同士も通信します。
将来的に数十のアプリが追加されることを考慮した場合、管理負荷を最小化する構成はどれですか？
回答：A 他はなんか怪しい。
問題 5
アプリケーションはEC2 + RDSSQL Server で構成されています。
要件:EC2とRDS間の通信はすべて暗号化されていなければならない
どの設定が最適ですか？（2つ選択）
A.EC2とRDSのセキュリティグループでポート443のみ許可
C. rds.force_sslパラメータをtrueにしてDB再起動
E. RDSルートCA証明書を取得しアプリでSSL接続を設定
回答 AとC。Eも正解っぽく感じる。
ーーーーー
答え
ーーーーー
問題 1
あなたの回答：C (AWS DataSync +Amazon EFS +Object Lock)
実際の正解は B (AWS DataSync +Amazon S3 +Object Lock)
理由：
Object Lock はAmazon S3 のみ がサポートしています。EFSやEBSではできません。
AWS DataSync で S3 にデータを移行し、Object Lock を有効にすると、削除や上書きを防止できます。
StorageGateway はハイブリッド用途（オンプレと同期）に便利ですが、このシナリオではすべてクラウドに移行するため不要です。
問題 2
あなたの回答：A, D, E
正解：A, D, E ✅
理由：
スケールインは 余剰リソースを減らす操作（インスタンスを削除する）
選ばれたAZの中で 最も古いLaunch Templateのインスタンス を削除
※「スケールイン＝縮小」「スケールアウト＝拡大」で覚えておきましょう。
問題 3
あなたの回答：BとC
正解は C と E
理由：
Lambda@Edge →認証処理をユーザーに近い場所で実行でき、ログイン処理を高速化
B（Cache-Controlmax-age）は静的コンテンツのキャッシュ用で、このシナリオの問題（認証処理の遅延や504）には直接関係なし
AやDはコストや運用負荷が高く、今回は「コストを抑えて改善」が条件
問題 4
あなたの回答：A
理由：
VPC Peering は数が増えると接続管理が爆発的に複雑 になる
TransitGateway を使えば 1つの中央ハブ で全VPCを接続でき、管理負荷が大幅に削減
VPNやDirectConnectはオンプレ接続用なので不適切
問題 5
あなたの回答：AとC
正解は C と E
理由：
rds.force_ssl=true → RDSがSSL接続を強制
クライアント側で RDSルートCA証明書を使用 してSSL接続
TDEは 静止データの暗号化 用で、通信の暗号化には関係なし
日中の生産性は、夜の過ごし方、特に「就寝」というクリティカルなタスクをいかに成功させるかにかかっている。本記事では、つい夜更かししてしまうエンジニアのために、早寝を「技術」として体系化し、再現性のある形で実践するための具体的な手法を探求する。これは精神論ではない。あなたのQoLと生産性を向上させるための、実践的なスリープエンジニアリングだ。
我々エンジニアにとって、夜は不思議な魅力を持つ時間だ。日中の喧騒から解放され、思考は冴えわたり、ゾーンに入りやすい。しかし、その魅力的な時間は、往々にして「早寝」という、人間の生存に不可欠な基本プロセスを犠牲にすることで成り立っている。
「リファクタリングが楽しくなってきた」
これらの探求心はエンジニアの美徳であるが、同時に我々を「睡眠負債」という深刻な技術的負債へと導く。本稿は、この負債を返済し、持続可能な開発（と生活）を実現するための「早寝」という技術に焦点を当てる。
早寝を実装する前に、まずは現状のアーキテクチャに潜むアンチパターンを特定しよう。
就寝前のスマートフォンは、まさに同期的なブロッキングI/Oだ。SNSの無限スクロール、動画プラットフォームの自動再生、チャットアプリの通知。これらは我々の意識というシングルスレッドを完全に占有し、本来実行されるべきsleep()プロセスへの遷移を妨げる。
深夜まで続くコーディングや問題解決は、脳を極度の興奮状態にする。ベッドに入っても、アドレナリンやコルチゾールといったホルモンがCacheに残り続け、CPUがクールダウンしない。shutdown -hnowを叩いても、プロセスが終了しないのだ。
「夜更かしの供」として注入されるカフェインやアルコールは、一見するとパフォーマンスを向上させるように見える。しかし、これらは睡眠の質という重要なmetricsを著しく劣化させる、誤った依存関係だ。特にアルコールは、入眠を助けるように見えて、実はレム睡眠を阻害し、睡眠のアーキテクチャ全体を不安定にする。
不規則な就寝・起床時間は、体内時計という最も重要なCronジョブを破壊する。毎日異なる時間に実行されるジョブが安定した結果をもたらさないのと同様に、不規則な睡眠スケジュールは、日中のパフォーマンスを予測不可能なものにする。
では、どうすればこれらのアンチパターンを排除し、安定した早寝pipelineを構築できるのか。ここではSleepas Codeの概念に基づき、具体的なプラクティスを紹介する。
毎晩、同じ手順で就寝プロセスを実行することで、入眠を自動化する。
-PC/スマホのシャットダウン: 最も重要なステップ。物理的に電源を落とすか、手の届かない場所（別のコンテナ）にdeployする。
- 入浴: 38〜40℃のぬるめのお湯に15分ほど浸かる。これにより深部体温が一時的に上昇し、その後の下降とともに入眠が促される。これはHot-swapならぬHot-bathによるクールダウンだ。
静的コンテンツの消費: 激しい思考を伴わない、静的な情報（紙の読書など）に切り替える。電子書籍ではなく、紙媒体が望ましい。
ストレッチ: 軽いストレッチで、日中のcommitで固まった体をreleaseする。
すべての準備が整ったら、ベッドという本番環境にデプロイする。余計な思考はgitclean -fdで強制削除し、呼吸に集中する。
例：「夕食後のコーヒーが原因だった」→「カフェインの摂取は15時までというSLAを設ける」
早寝は、単に体を休める行為ではない。日中の高いパフォーマンス、明晰な思考、そして創造性を維持するための、最も効果的で再現性の高い「技術」だ。
我々はインフラをコードで管理し、CI/CDでデプロイを自動化するように、自身の睡眠もまた、技術と工夫によってコントロールできる。今夜、あなたのwhile(true)なループをbreakし、持続可能なパフォーマンスを手に入れるための第一歩を踏み出してほしい。
Happy sleeping!
日中の生産性は、夜の過ごし方、特に「就寝」というクリティカルなタスクをいかに成功させるかにかかっている。本記事では、つい夜更かししてしまうエンジニアのために、早寝を「技術」として体系化し、再現性のある形で実践するための具体的な手法を探求する。これは精神論ではない。あなたのQoLと生産性を向上させるための、実践的なスリープエンジニアリングだ。
我々エンジニアにとって、夜は不思議な魅力を持つ時間だ。日中の喧騒から解放され、思考は冴えわたり、ゾーンに入りやすい。しかし、その魅力的な時間は、往々にして「早寝」という、人間の生存に不可欠な基本プロセスを犠牲にすることで成り立っている。
「リファクタリングが楽しくなってきた」
これらの探求心はエンジニアの美徳であるが、同時に我々を「睡眠負債」という深刻な技術的負債へと導く。本稿は、この負債を返済し、持続可能な開発（と生活）を実現するための「早寝」という技術に焦点を当てる。
早寝を実装する前に、まずは現状のアーキテクチャに潜むアンチパターンを特定しよう。
就寝前のスマートフォンは、まさに同期的なブロッキングI/Oだ。SNSの無限スクロール、動画プラットフォームの自動再生、チャットアプリの通知。これらは我々の意識というシングルスレッドを完全に占有し、本来実行されるべきsleep()プロセスへの遷移を妨げる。
深夜まで続くコーディングや問題解決は、脳を極度の興奮状態にする。ベッドに入っても、アドレナリンやコルチゾールといったホルモンがCacheに残り続け、CPUがクールダウンしない。shutdown -hnowを叩いても、プロセスが終了しないのだ。
「夜更かしの供」として注入されるカフェインやアルコールは、一見するとパフォーマンスを向上させるように見える。しかし、これらは睡眠の質という重要なmetricsを著しく劣化させる、誤った依存関係だ。特にアルコールは、入眠を助けるように見えて、実はレム睡眠を阻害し、睡眠のアーキテクチャ全体を不安定にする。
不規則な就寝・起床時間は、体内時計という最も重要なCronジョブを破壊する。毎日異なる時間に実行されるジョブが安定した結果をもたらさないのと同様に、不規則な睡眠スケジュールは、日中のパフォーマンスを予測不可能なものにする。
では、どうすればこれらのアンチパターンを排除し、安定した早寝pipelineを構築できるのか。ここではSleepas Codeの概念に基づき、具体的なプラクティスを紹介する。
毎晩、同じ手順で就寝プロセスを実行することで、入眠を自動化する。
-PC/スマホのシャットダウン: 最も重要なステップ。物理的に電源を落とすか、手の届かない場所（別のコンテナ）にdeployする。
- 入浴: 38〜40℃のぬるめのお湯に15分ほど浸かる。これにより深部体温が一時的に上昇し、その後の下降とともに入眠が促される。これはHot-swapならぬHot-bathによるクールダウンだ。
静的コンテンツの消費: 激しい思考を伴わない、静的な情報（紙の読書など）に切り替える。電子書籍ではなく、紙媒体が望ましい。
ストレッチ: 軽いストレッチで、日中のcommitで固まった体をreleaseする。
すべての準備が整ったら、ベッドという本番環境にデプロイする。余計な思考はgitclean -fdで強制削除し、呼吸に集中する。
例：「夕食後のコーヒーが原因だった」→「カフェインの摂取は15時までというSLAを設ける」
早寝は、単に体を休める行為ではない。日中の高いパフォーマンス、明晰な思考、そして創造性を維持するための、最も効果的で再現性の高い「技術」だ。
我々はインフラをコードで管理し、CI/CDでデプロイを自動化するように、自身の睡眠もまた、技術と工夫によってコントロールできる。今夜、あなたのwhile(true)なループをbreakし、持続可能なパフォーマンスを手に入れるための第一歩を踏み出してほしい。
Happy sleeping!
Programming proficiency necessitates a comprehensive understanding of multifaceted concepts,paradigms, and philosophies that underpin theart and science ofsoftware development. TheUnix philosophy, withits emphasison modularity, simplicity, and composability, servesas a foundational ethos for elegant code design. This philosophy advocates for creating small, focused programs thatexcelat singular tasks, facilitating the construction ofcomplex systems through the judicious composition of theseatomic units.
Proficient programmers must possess an encyclopedic knowledge of algorithms and datastructures, enabling them to architect solutions with optimaltime and spacecomplexity. This encompasses adeep understanding of sorting algorithms (e.g., quicksort, mergesort), searching techniques (binary search, depth-first search),and advanced datastructures (red-black trees,B-trees, Fibonacci heaps) The ability to analyze algorithmic efficiency usingBig O notationis paramount for creating scalable solutions.
OOP principles—encapsulation, inheritance, andpolymorphism—form the bedrock of modernsoftware architecture. Mastery of design patterns (e.g.,Singleton,Factory,Observer) and SOLID principlesiscrucial for creating maintainable and extensible codebases.
TheFPparadigm, withits emphasison immutability andpure functions, offers a powerful approach to managingcomplexity and facilitating parallel execution. Proficiency in higher-order functions, currying, and monadsis essential for leveragingFP's full potential.
Expertise in language-specific advanced features, suchasC++'s template metaprogramming orPython's metaclasses, allows for thecreation of highlygeneric and reusable code. Understanding compilertheory and the ability towrite domain-specific languages (DSLs) further expands a programmer's capabilities.
In an era of multi-core processors and distributed systems, mastery of concurrent programmingmodels (e.g., actormodel, communicating sequential processes) and parallel algorithmsis indispensable. This includes proficiency in lock-free datastructures, memorymodels, and synchronization primitives.
Adeep understanding ofcomputer architecture,operating systems, and memory managementenables thecreation of highly optimized,low-level code. This encompasses knowledge ofcachecoherence protocols,CPU pipeline optimization,and assembly language programming.
In an increasingly interconnected world, a thorough grasp of cryptographic principles, secure coding practices, andcommonattack vectors (e.g., buffer overflows,SQL injection)iscrucial for developing robust and secure systems.
Proficiency in distributedversion control systems (e.g.,Git) and collaborative development practices (code reviews, continuous integration)is essential for effective team-basedsoftware development.
Advanced testing methodologies, including property-based testing, fuzzing, and formal verification techniques, are indispensable for ensuringsoftware reliability and correctness.
In conclusion, the pantheon of programming knowledge extends farbeyond mere syntax mastery.It encompasses a richtapestry of theoretical concepts, practical skills, and philosophical approaches that, when harmoniously integrated,enable thecreation of elegant, efficient, and robustsoftware systems. The relentless pursuit of this multifaceted expertiseis the hallmark of a truly accomplished programmer.
AIが盛り上がって数年経つが、個人が買えるような価格帯で、良いAI向けのハードが出てこない。
RTX 3090のVRAM24GBを大事に使っているが、そもそもVRAMに入らないモデルの方が多い。
複数のAIを立ち上げるなんてのは、VRAM容量が溢れるので、そもそも動かせない。
動けばNVIDIAの Nsight Systemsなどで遅い所などを探せるが、そこまでいかない。
複数のSSDを仮想メモリにするというのも、RTX 3090のNVLinkBridgeでVRAMだけ拡張するなんてのも世の中に出てこない。
Appleもそろそろ出してくるかと思っていたが、M4は普通の順当進化だった。
M2 Ultraはチップtoチップを接続し2.5TB/sを謳ったが、同じチップを繋げたのでいらない機能が倍になっただけだった。
M4 Ultraで、片側のチップをGPU or NPU＋帯域の広いGDDR orHBMになればいいが、あまり期待が出来ない。
GPU or NPUのコアが増えたとしても、L2/L3キャッシュの容量が少なすぎる、増やしても距離が遠ければ性能も出ないので、
AppleもAMDのように3D V-CacheでSRAMを積み、Hybrid Bondingで上下の帯域を確保してくれないだろうか
IBMはTelum IIとSpyreを出してきたがエンタープライズ向けなのでパス
Groq社がLLM用LPU、HyperAccel社がLLM用ASICを出して来たが、
Groqは1枚のPCIeカードでは全くメモリ容量が足りず役に立たなそうで、HyperAccelはサーバー前提でこちらも個人から手が出しにくい。
FPGA＋HBMが載ったPCIeカードは個人向けには販売できるような価格でもなければ、そもそも販売すらされない。
ジム・ケラー率いるTenstorrentも1枚のPCIeだとメモリが足りないし、Ethernetでなんとかやりくりしようとしているが帯域に引っ張られそうに見える。
NextSilicon社がMaverick-2というIntelligent Compute Accelerator (ICA)というのも出してきたが、HPC向けで個人利用からは遠い。
中国も良いのが出てきていない。
Biren、Fuzhou Rockchip、VeriSilicon、Moore Threads、LinJoWing、Loongson、JingJiaMicro、Cambricon、Vastai Technologies、Xiangdixian Computing、Enflame Technology、MetaX、Zhaoxin、LingjiuMicroelectronics、
DengLin Technology、Iluvatar CoreX、Innosilicon、Horizon Robotics、BlackSesame Technologies
docker buildコマンドに --pullオプションを指定することで、ベースイメージがローカルにあっても最新バージョンをリモートリポジトリから強制的に取得します。
サンキューchatgpt
docker build --no-cache を使用すると、Dockerはキャッシュを一切使用せず、すべてのステップを再実行します。ただし、ベースイメージに関しては少し異なる動作をします。
docker build --no-cache を使用しても、ベースイメージ（FROM で指定されたイメージ）は一度ローカルにダウンロードされていれば再度ダウンロードしません。
ベースイメージがローカルに存在しない場合は、インターネットからダウンロードされます。
ローカルにすでにある場合は、--no-cache でもそのまま利用されるので、ベースイメージを毎回ダウンロードしているわけではありません。
UbuntuベースのPythonイメージは通常1GB程度になることが多いですが、軽量なイメージ（例えばbookwormやslimタグ）を使用すると、サイズを大幅に削減することができます。
bookworm（Debian12ベース）は、一般的にパッケージが少ないため、通常のubuntuイメージよりも軽量です。
例えば、python:3.11-slim-bookworm のようなイメージはかなり小さく抑えられており、数百MBに収まることがあります。
まとめ
docker build --no-cache でも、ベースイメージがローカルにある場合は再ダウンロードされません。
別の人からもあったそうです
