リクエストヘッダに『Accept-Encoding: gzip』を含む場合、クライアントが「gzip圧縮して返しても大丈夫よ」って言ってるので、サーバー側はレスポンスを返す際に条件を満たしていれば、レスポンス・ボディ部分を圧縮した上で、レスポンス・ヘッダに『Content-Encoding: gzip』を付与して「gzipで圧縮しておいたよ」と返します。 WEBサーバーに限らず、CloudFront といった CDN も同等の機能を持っていて、圧縮メリットがあると判断した場合は有効にしておくとよいでしょう。 圧縮ファイルの供給 – Amazon CloudFront 圧縮の目的 ここはエンジニアとしての話というても、自宅パソコンでも何かしら圧縮機能は使っているでしょうから、説明は不要でしょうが…… メインは容量の縮小、次いで複数データを１ファイルにまとめる、ってところで今回は容量縮小を”手

日々何気なくお世話になっている VPC 含むネットワークは、ちゃんと理解しようとすると思ったより多い情報量と、それに対するパターンの経験が必要になります。 私自身、正直ネットワークのお話は好きじゃないのですが、現行の事情を踏まえてこの辺の基本と雑学を振り返っておくと、技術力のベースが整ってよろしいのではと思って整理することにしました。 はじめに 新年度なので、学習教材シリーズです。今回はネットワーク周りで、基礎に味付けするような内容です。もしかしたらお嫌いなジャンルでしょうか、でも少しだけやりましょうそうしましょう。 関連情報としては、このあたり。 公式 ENOG81: AWSのIPv6とPublic IPv4のおはなし – Speaker Deck Amazon VPC とは? – Amazon Virtual Private Cloud 外道父の匠 AWS VPCルーティングの基本から

米ドル/円 が150円と計算しやすくなり、コスト削減の圧力が日々強まる中、皆様お宝探しと垂れ流し回収の真っ最中でございましょうか。 最近はコスト削減や予算について見ることが多いので、その中で出てきた面白げな話に雑談を加えてとりとめなく書いてみようと思います。 削減余地はある 昨年にご好評いただいた AWSコスト削減とリソース管理 | 外道父の匠 を含め色々な削減施策を試みてきましたが、サクッと成果になる箇所から泥沼に動かない所まで様々あったりします。 ただ、どんなアカウントでもトラフィックや処理負荷には波があり、それに対する余剰リソースを確保して構成しているので、その辺をキュッと絞ることまで含めればやれることは必ず一定以上存在することになります。 そういう大きなお宝ではない小さなお宝だと様々あり、古びたとか退職者が作ったとかで、ほぼ使っていない垂れ流しリソースやデータをかき集めれば、チリツ

鉄拳で使っているノートパソコンのファンが異常にうるさくなったので、その修復記録です。 たいした内容じゃないけど、せっかく色々調べたり試したので、どんな項目があるのか、どのような現象と対処だったのかが、いつかの誰かのためになりますように。 環境と現象 鉄拳７復帰時は何もわからず PS4 で始めて、後半は鉄拳８も見据えて Steam に移行したので、その時に買ったゲーム用ノートパソコンが１年を過ぎた頃、ファンの回転数と音が徐々に大きくなりやすくなり、最終的にはほぼ何も負荷をかけていなくても高まるようになり我慢の限界を超えました。 GPU は GeForce RTX™ 3060 LAPTOP でスコア 350台、普段はグラフィック設定『低』で、動作も温度も騒音も問題なく稼働している状況です。 設定を『高』以上にしたり、CPU / GPU の負荷が 50％ 辺りを超えるとファンが煩くなったりはしま

現在、持ちキャラの調べ物は区切りがついたので、絶賛キャラ対策を進めてみています。 ただ漠然とキャラ対策といっても難しいもので、せっかくなので初心にかえって考え直してみることにしました。 皆が思うこと 初心者に限らず、出たての鉄拳は誰もが↓↓同じことを感じながら対戦を続けているので、そんなもんではあるのだけども、そんなところから先に進めるにはどうしたら良いのかって話へ膨らませるべしってことですね。 【#鉄拳8 初心者の本音】 第3位：キャラ対策できる気がしない ただでさえ技が多いゲームなのに始動技と派生を覚えて右or左移動orしゃがみで避けろ、またはガードしたときの有利フレームを覚えて反撃しろって例え覚えられたとしても実戦で瞬時に判断するのはムリがある… — 天野さとし (@ten_amns) February 13, 2024 直レス以外にも、引用でトッププレイヤーっぽい人も考えているので

通常コンボがだいたいまとめ終わって慣れたので、次はヒートを絡めていきます。 最初はヒートまで慣れる気がしませんでしたが、まぁやってりゃなんとかなるもんで、使い所もなんとなくイメージが湧いてきました:-) ヒートコンボリスト 前回まで公開してたスプレッドシートと同じです が、【共有】で公開してたのをやめて、【WEBサイト】として公開に切り替えました。 → 使い勝手の都合でやっぱ戻しました。 鉄拳８吉光 技表 by Noko ver1.0 ＞ コンボ ヒートは新要素ですので、なんとなく表の上の方に追加しておきました。面白いけど、練習するなら通常からやった方がいいと思います。 ヒートの使い所 立ち回りではなくコンボ関連として考えると、以下のような使い所に整理できると思われます。慣れるためにも、バンバン試すとよさげです。 コンボ終盤にバーストを発動してヒットバックを減らし、コンボを伸ばしてヒートの

技表のまとめが落ち着いたので、ようやく次は楽しいコンボ練習に参りましょう。 依然として対戦はまだ全くやっていません。リーマンなんてそんなもんよね。 前と同じスプレッドシートに、コンボ用シートを追加しました。技表と同じデータの方が捗るということで。 鉄拳８吉光 技表 by Noko ver1.0 ＞ コンボ もうワシも歳じゃけん、練習だけで覚えたり、ブログにちまちまコンボを書くのは億劫なもんで、表にまとめないとやってけないんよ……ゴホゴホ…… おことわり コンボ開発とか苦手ってゆーか、気づいたら世の中にコンボが散らばっている良い世の中なので、自分で考えることなどほとんどありません（ｷﾘｯ eyemusician のコンボ動画や Twitter で見かけたものを、ひたすらラーニングしてまとめている感じです。なので、まずは世のコンボ好きに感謝を。 Tekken 8 Yoshimitsu Comb

昨日の今日でアレですが、技表に「コンボ始動」「寝っぱ」の項目を追加しました。 対戦動画やコンボ動画を眺めているだけで、色々思うところが出てきちゃって、まだ全然対戦してません:-) 更新内容 スプレッドシートはこれです。 鉄拳８吉光 技表 by Noko 変更点は、 「コンボ始動」の列を追加 「寝っぱ」の列を追加 ダッシュ中の「タックル」を追加 アルティメットタックル切り返し時の串刺しを追加 技名の1発止めなどにも表記を追加 当初は寝っぱには何がイィか考えようとしたら、サクッと表に足したほうが判断しやすいのでは、と思ってたら色々追加することに。

2024年1月26日午前8時 (JST) から、ついに鉄拳８が開始して３日目であります。 今作はそこそこ真剣に取り組むぞ、ということで私の場合は己を知るところから、で吉光の技表を作成してみたので共有したいと思います。 吉光の技表 スプレッドシートにまとめました。 鉄拳８吉光 技表 by Noko 鉄拳８としてのバージョンは見当たらなかったのでシートでは ver1.0 としていますが、Steam 内での表記は以下の内容のとおりです。 BuildID : 13261262 更新日時：2024/01/26 08:40 各種付与効果をフィルタリングしたい場合は、 「データ」→「フィルタ表示」→「新しい一時的なフィルタビューを作成」 の後にヘッダ項目部のフィルタマークから o で絞ることができます。 おことわり 一応、当たり前のことを書いておきますが、この技表は自分のために作成したものであり、閲覧は

今のところ、AWS IPv6化や PublicIP 外しはボチボチやったり、いったんやらない判断したり色々です。 そんな中で、考察し直した部分や、新しく考察した事例などが出てきましたので、整理していきます。 はじめに 既に AWS IPv6 についてはいくつか書きましたので、その続編ということで。 AWSのPublic IPv4構成をIPv6に切り替える | 外道父の匠 AWSの削減対象なPublicIPの調査 | 外道父の匠 AWS Lambda IPv6 と APIエンドポイントと NAT G/W | 外道父の匠 AWSコンテナ系アーキテクチャの選択肢を最適化する | 外道父の匠 当初は PublicIPv4 有料化対策のつもりで書き始めたシリーズであり、それ自体は別に間違いじゃないのですが、IPv6 化をすれば即・万事メデタシになるというわけでもない、ということで色々学びつつ判断して

これまでもコンテナ関連の記事はそれなりに書いてきましたが、改めて最新事情に合わせて練り直したり見渡してみると、大きなところから小さなところまで選択肢が多すぎると感じました。 コンテナ系アーキテクチャを丸っと他所の構成で真似することって、おそらくほとんどなくて、参考にしつつ自分流に築き上げていくでしょうから、今回は築くにあたってどういう選択肢があるのかにフォーカスした変化系で攻めてみようと思った次第です:-) 目次 今年一発目の長いやつです。半分は学習教材用、半分は道楽なテイストです。 はじめに 基盤 インスタンス or コンテナ ECS or EKS on EC2 or FARGATE X86 or ARM64 ロードバランサー メンテナンス：ALB or ECS Service 共有 or １環境毎 アクセスログ：ALB or WEBサーバー ECS / EKS デプロイ：Blue/Gr

Terraform を色々見直している中で、CodePipeline の経過を知らせる仕組みに、CodeStar Notifications を使っている箇所がありました。 今回はそれを EventBridge を使う形式に変更した、というか旧式に戻した、地味なあけおめ回です。 変更理由 Terraform やら機能構成そのものを練り直している際に、もっと簡略化とか最適化できないか考える中で、CodeStar Notifications を使ってチャットに通知している箇所がありました。 CodeStar 本体は使っておらず、Notifications だけ使っている状態で、リソース構成も正しいとはいえ複雑気味に感じたので、なんとかならないかなーと調べたところ、そもそも 2024年7月31日 でサポートが終了する旨が、ドキュメントやコンソールに表示されていました。 2024 年 7 月 31

鉄拳８吉光の PV も出たし、体験版も出たし、もう７光を触ることはなくなるでしょう。 ということで、自分なりの７光の感想を良し悪しにわけて書いてみます。 良かったところ 歴代一強い まぁこれはキャラ単体でみれば、どのキャラもそうだと思いますけども、よっぽど相性が悪い相手ですら『詰む』ということは無くなりましたよね。6BR ン時はもはやゲームとして成り立ってなかったし。 昔だと、強い人が戯れで触ってもステップインアッパーでなんとかするしかなかったけど、今は基礎が強ければなんとでもできちゃう感じあるもんね。吉光使いにしかできない行動って、吉光ブレード、各種構え、ガード不能、を使いこなすことで、それ無しに勝つのを見ても何も感じないっていう。 そういう意味では、ノビ光が配信で相当意識的に使いこなそうとしていて、頑張っているなーと思う。でもさすがに吉光として参考になるところは無くて、感心するのは素の

昔は社内で自分主催の勉強会をやることがあって、それを『外道塾』と称していました。 最近手掛けた、丸っとまとまりのよい技術話ができたので、忘年会をかねて会社＆オンラインで開催しまして、それのただの感想となります。 題材 ひょんなことから、最近の色々を最適化しつつ再構成したものがありまして、ECS を軸とした全てって感じの内容です。ECS が EKS に入れ替わっても大丈夫、くらいの情報構成のつもり。 Docker , Git , ECS , Code系 , Rails あたりの、開発やインフラ設計からデプロイまでを、イィ感じに分解しつつ、社内用に教科書コンテンツを作って、ぶっつけ本番で昼食含めて３時間半ほど話しました。 とはいえ昔から勉強会そのものの効果はあまり期待していないので、どっちかっつーと書いた教科書をあとからいつでも誰でも見れるように残したところがメインの目的ですが、 参加者には、

タダ飯狙いでIT系コミュニティのイベントなどに入り込む人たちがいる、ということが少し前から話題になっている中で、実際に不審者がイベントに入り込もうとした事案がまた明らかになりました。 12月11日と12日の2日間、都内で開催されたコミュニティ主催の技術系カンファレンスで、おそらくは無料の食事を目当てにした不審な人物らが侵入しようとした出来事が発生していたことがイベントの当事者の発言で示されています。 スタッフとして不審者に対応した一人である鍋島理人氏は、「勉強会参加者や運営に危害が及ぶほどの脅威であり、必要なのは不審者対策そのものだと認識を改めた。というか僕はそれぐらい怖かった」とポストし、今回の事態の大きさを吐露しました（鍋島氏は以前、翔泳社でDevelopers Summit（通称デブサミ）のオーガナイザーを勤めたこともある、イベントやコミュニティの運営に関して十分な知見を備えた人物で

https://drecom.connpass.com/event/300236/presentation/

自分はそんなに情報収集に熱心な方ではないとはいえ、流れていく技術情報の中で関係しそうなものは目を通すし、昔から好きな組織・エンジニアのブログ・チェックくらいは継続しています。 古のエンジニアは時間経過や転職を機にパッタリ途絶えたりして減っていくも、稀に若手や新人ぽい人のアウトプットが目につくと、時代事情も相まってとても応援する気になるし、こちらも負けじと頑張る気になるってモンです。 混沌から王道へ 今の時代に、駆け出しや初級者としてアウトプットを始めるのって難しいんじゃないかと思うことがあります。 昔はハードからソフトまで貧弱だったり、色んなOSSや選択肢があって、これぞ正攻法という解がなかった混沌だったからこそ、多角的な切り口のアウトプットをしやすかったように思います。 今はクラウドの出現や、ソフト・ミドルウェアの成熟により、ある程度の正攻法が見えやすくなった上に、細かい知識や調整が不要

以前、AWSコスト削減とリソース管理 | 外道父の匠 のEBSの項では、そもそも不要なEBS・スナップショットの判断をしましょうってのと、gp3 にして安く高性能にしましょうと書きました。 今回はそのうちの gp3化 についての外伝ということで、さらりとまとめておきます。 費用差 gp2 が $0.12/GB 月、gp3 が $0.096/GB 月 なので、gp2 から gp3 に変更すると 20％ の費用削減になります。 ハイパフォーマンスブロックストレージの料金 – Amazon EBS の料金 性能に関しては、gp3 の 125 MiB/s 3000 IOPS が判断基準となる数値で、もし gp2 の時に、それ以上の性能を使い込むタイミングがある場合、gp3 にしただけで安く速くなったと安易に喜ぶことはできなくなります。 よほど読み書きが盛んなボリュームの場合は、メトリクスをチェック

何度か外から AWS の Aurora MySQL へサービス移行をして知見が溜まっていたので、吐き出しておきます。DBA 専門的な人から見たら別におもろくない内容だと思いますので、初中級者の学習用教材です。 最初は全体の流れを全て書こうとしましたが、全く同じ流れでやることはないだろうと思い、部分ごとにこういうことを検討すればえぇんちゃうんくらいの Tips にしてみました。 目次 そこまで長くないですが Tips なので目次を置いておきます。 データ転送の方法 当日にバックアップ／リストア 事前にレプリケーションする 通常レプリケーション 直にグローバルアドレスへ接続 VPN経由で接続 レプリケーション開始 DMS経由レプリケーション リンク集 メリット 大まかな流れ 非対応 DDL binlog_format バックアップの方法 mysqldump mysqldump 独自並列 mys

AWS Lambda in VPC から、IPv6 で Egress-only internet gateway を通って外に出ていけるようになりました。 それに関連して、APIエンドポイントと NAT G/W を絡めて確認したことをまとめておきます。よくわからないタイトルになりましたが、雑学用の材料ということで:-) リリース 公式情報はこちら。 Announcing AWS Lambda’s support for Internet Protocol Version 6 (IPv6) for outbound connections in VPC 英語版はLambda の Dual-stack が Yes に AWS services that support IPv6 – Amazon Virtual Private Cloud 内容的に、確認したいことはすぐ成功して終わるだろうと