PESPAというアーキテクチャについて、みなさんご存じでしょうか？ これはWebにおける次世代のアーキテクチャを表しており、MPAやPEMPA、そしてSPAの欠点を解決し、シンプルかつプログレッシブエンハンスメントなアーキテクチャとなっている素晴らしいアーキテクチャのひとつとなっています。 そう、Remixフレームワークが採用しているアーキテクチャです。 このPESPAという概念について、Kent C.Doddsさんが、2022年の10月21日に投稿し話題を呼びました。 日本ではあまりまだ浸透していない概念ということもあり、本当に素晴らしいアーキテクチャと思想を兼ね備えていることから、今回その記事を翻訳しました。 みなさんがこれから開発していくアプリケーションに、ぜひこのアーキテクチャを採用していただきたいと願っております。 この記事は、あくまで翻訳であり、意訳の部分も含まれているため間違

はじめに こんにちは、Techouse の人材プラットフォーム事業部でサーバーサイドエンジニアを担当している imayayoh と申します。 Techouse では各事業部でエンジニアがインフラの監視として、AWS・外部サービス等のグラフモニタリングを実施しています。モニタリングでは下記に重点を置いており、インフラ構成の見直しや障害対応の場として活用しています。 サービス運用に十分なスペックでインフラが構成されているか 最適なコストでサービスが運用されているか インフラ・外部サービスで重大な問題が発生していないか 本日はモニタリングの実施で即時対応できたトラブルの一例として、Application Load Balancer (ALB) への謎の大量アクセス攻撃を紹介します。 コストモニタリング 弊社のサービスではインフラに AWS を使用しており、モニタリングでは AWS Billing

こんにちは、駅奪取エンジニアの id:kimkim0106（旧: id:kaoru_k_0106）です。 今回の記事は、駅奪取でテーブルにレコードが「無ければ INSERT、あれば UPDATE」（いわゆる UPSERT）をする箇所で Duplicate entry が出ていたのを修正したり、未然に防ぐ実装をしたときに得られた知見です。 このような処理はよく使われますが、うまく実装しないとエラーが発生したりパフォーマンスの問題が生じたりします。 この記事では、自分が試した方法のメリット・デメリットについて説明します。 目次 前提条件 Duplicate entry とは 1. Duplicate entry が出たらトランザクション自体をやり直す 2. INSERT ... ON DUPLICATE KEY UPDATE 3. とりあえず INSERT して Duplicate entry

ついにブロックができるようになった！Amazon GuardDuty Malware Protection for Amazon S3が発表されました！ #AWSreInforce Amazon GuardDutyで待望のマルウェアに対する保護機能がリリースされました！信頼できないオブジェクトをS3にアップロードする環境ならガンガン活用していきましょう！ こんにちは、臼田です。 みなさん、AWS上でのマルウェアチェックしてますか？(挨拶 AWS re:Inforce 2024で待望のS3に対するネイティブなマルウェア検出と保護の機能である「Amazon GuardDuty Malware Protection for Amazon S3」がリリースされました！ Detect malware in new object uploads to Amazon S3 with Amazon Gua

先日こういうツイートが流れてきた。 Q:なぜ金融系では未だにCOBOLが使われるんですか？ A:お手元にExcelがありましたら任意のセルに「=4.8-4.7-0.1」って入れてみてください。— 遊撃部長F/S&RWAs (@fstora) 2024年6月6日 Q:なぜ金融系では未だにCOBOLが使われるんですか？ A:お手元にExcelがありましたら任意のセルに「=4.8-4.7-0.1」って入れてみてください。 普段我々がゴリゴリ馬車馬のように使っているソフトウェアでよく利用されている浮動小数点型、すなわちfloatやdoubleなどは特定の算術に弱いことが知られている。というかもうこの手の話題はあまりに拡散されてしまったので、なぜかネット民はみんな知っている基礎教養、三毛別羆事件とかデーモンコアみたいな感じになっている。 ちなみにこれはCOBOLかそうではないか、という軸が問題になっ

はじめに こんにちは。SRE部ECプラットフォーム基盤SREブロックの石田です。 本記事では、Aurora Serverless v2を本番導入するにあたってどのような検討をし、どのように導入していったか、また導入後に得られた効果について紹介します。 はじめに Aurora Serverless とは 背景 比較検討 比較内容 方針の決定 アーキテクチャ 導入 1. Aurora Serverless v2を手動で構築 2. AWS CloudFormationでProvisioned型Aurora MySQLバージョン3を再構築 3. AWS CloudFormationでAurora Serverless v2に移行 4. 負荷試験・障害試験 負荷試験 障害試験 導入により得られた効果 柔軟なスケーリング インフラコスト 最後に Aurora Serverless とは Aurora

また、<picture>を使えば「WebP形式の画像に対応していないブラウザなら、PNG画像を表示する」といった出し分けも可能になります。 pictureタグの使い方 具体的な使い方を解説していきます。 sourceとimgタグと使う <picture>タグは、複数の<source>と、1つの<img>を囲う形で使います。 <picture> <source srcset="候補1の画像URL" 属性 /> <source srcset="候補2の画像URL" 属性 /> <img src="候補4の画像URL" alt="~" /> </picture> 👆それぞれに表示する画像候補のURLを指定します。この中からどれか1つの画像が表示されます。<img>は1つだけですが、<source>はいくつ入れてもOKです。 条件に当てはまる画像1つだけが表示される ブラウザは以下のような流れで

はじめに セキュリティエンジニアの齋藤ことazaraです。今回は、不可思議なContent-Typeの値と、クラウド時代でのセキュリティリスクについてお話しします。 本ブログは、2024 年 3 月 30 日に開催された BSides Tokyo で登壇した際の発表について、まとめたものです。 また、ブログ資料化にあたり、Content-Type の動作や仕様にフォーカスした形で再編を行い、登壇時に口頭で補足した内容の追記、必要に応じた補足を行なっています。 また、本ブログで解説をする BSides Tokyoでの発表のもう一つの題である、オブジェクトストレージについては、以下のブログから確認をすることが可能ですので、ご覧ください。 blog.flatt.tech なぜ今、この問題を取り上げるのか？ 従来のファイルアップロードにおいて、Content-Type の値を任意の値に設定すること

起きたこと 僕が運営している『オンライン絵しりとり』というサイトで起きた話となります。 これは訪れたユーザー同士で絵しりとりを楽しめるサービスです。 ある日、このサービスをホスティングしているConoHaVPSより、規約に違反しているため利用を制限した旨のメールが届きました。 お客様のVPSにおきまして、弊社会員規約に反するコンテンツが 検出されましたので、ご利用サービスの制限をさせていただき ましたこと、ご連絡申しあげます。 そして、メールが届いたほぼ同時刻にサーバーが停止され、サービスへアクセスできない状態になりました。 メールによると、JASRACより著作権侵害に対する防止措置の申し出があったとのことです。 指摘対象のコンテンツを確認したところ、ユーザーがサイト内のチャットでYOASOBIの楽曲である『アイドル』の歌詞の一部を投稿しておりました。 ご覧の通り、話の流れで流行りの曲をみ

こんにちは。スクラムマスターの@sakebookです。 今回は「象・死んだ魚・嘔吐」をチームでやってみたのでその振り返りをします。 「象・死んだ魚・嘔吐」とは 振り返り手法の一つです。Airbnb Story 大胆なアイデアを生み、困難を乗り越え、超人気サービスをつくる方法（原題: The Airbnb Story）の中で紹介されていたようです。 翻訳されてなかなかキャッチーなネーミングになっています。 それぞれ次のようなことを意味します。 象 凄く大きい、見えているけど、みんな見ないふりをしている課題・問題。表層化しているけど大きすぎてみようとしていない。これが何かをみんなで話していく。 死んだ魚 放っておくと腐っていく。そういう問題。放置しておくとまずいことになる問題ってなんだろう？ということを話し合う。 嘔吐 自分の胸の中に隠していて、吐き出せなかったこと。これをこの場で嘔吐する。

技術的負債という言葉がある。もともとは、「楽するために導入したが、メンテにコストがかかるようになってしまった技術や構成」くらいの意味合いで使われているように思う。しかし、そもそも全部が負債ではないか、というのがこのメモの趣旨である。 負債 同僚とSlackで会話していると、「けっきょくどの言語を利用しても負債になるときはなるし、大抵負債になる」といった話になった。言われてみればそうで、基本的にコードというものは書いたそばから負債になっていく。去年書いたコードのことも思い出せない。 そんな中で思ったのだが、そもそも、負債になるコードと負債にならないコードとがあったり、技術が「負債化する」のではなく、コードや技術そのものが負債なのではないか。そして、どの言語で書こうが負債からは逃れることができない。負債にならないコードは存在しない。ゆえに、コードや技術は無ければ無いほど良い、ということになる。

CQRSとは CQRS（Command Query Responsibility Segregation、コマンド・クエリ責務分離）は、ソフトウェアアーキテクチャパターンの一つで、つまりシステムのコマンド部分をクエリ部分から分離します。基本的な考え方は、データの書き込み操作（コマンド）と読み取り操作（クエリ）を異なるモデルで扱うことです。これにより、スケーラビリティ/パフォーマンス/セキュリティの観点で柔軟な設計が可能となり、クエリ要件に合わせて最適化が実現できます。 CQRSの基本構成としては、 コマンドモデル（書き込みモデル）：データの作成、更新、削除といった書き込み操作を担当します。このモデルは、データの整合性と一貫性を確保するために最適化されています。 クエリモデル（読み取りモデル）：データの読み取り操作を担当します。このモデルは、クエリのパフォーマンスを最大化するために最適化され

【PR】 2024.05.17 働き方 SESお金 「案件ガチャ」「薄給」「会社の押し付け」など、ネット上にはSESのイメージを低下させるキーワードが飛び交っている。しかし安易に「SES＝悪」と決めつけて良いのだろうか。 世の中には、高い報酬や待遇を実現し、エンジニアが希望する案件を経験できるSES企業も存在する。そこで今回、いわゆる“悪徳SES”の真逆を行く仕組み作りを実現し、エンジニアの採用や育成に成功しているという、のらねこワークスに取材を実施。 「エンジニアが本来受け取るべき高収入をもらいながら、自由に働ける環境を作りたかった」と起業の思いを語る代表取締役CEOの佐藤貴彦さん、取締役COOの松高 健太郎さんに、優良SES企業の見極め方を伺った。 のらねこワークス株式会社 代表取締役 佐藤貴彦さん 大学中退後、トラックドライバーを経て未経験でIT業界に転職。3度の転職、ベンチャー企業

Web制作の技術は日々進化しており、会社やプロジェクトによっては昨今の環境に適さない書き方をしているケースも時折見受けられます。 そこで今回は「2024年のWeb制作ではこのようにコードを書いてほしい！」という内容をまとめました。 質より量で、まずは「こんな書き方があるんだ」をこの記事で伝えたかったので、コードの詳細はあまり解説していません。なので、具体的な仕様などを確認したい方は参考記事を読んだりご自身で調べていただけると幸いです。 1. HTML 画像周りはサイトパフォーマンスに直結するので、まずはそこだけでも取り入れていただきたいです。また、コアウェブバイタルやアクセシビリティも併せて理解しておきたい内容です。 Lazy loading <img>にloading="lazy"属性を付けると画像が遅延読み込みになり、サイトの読み込み時間が早くなります。

Result 型 (類似するものとして Either Monad の方が有名かもしれません) を導入する場合、アプリケーション全体の設計を変えたり、全箇所を書き換える必要はありません。 neverthrow は部分的に使用でき影響範囲も閉じるので、局所的に使い始めることができます。 (Rust のような) Result 型 とは ざっくり言うと関数の処理の結果と成否を 1 つの型 Result<T, E> で表したものです。(T は期待する結果の型、 E はエラーを表現する型) 筆者は詳しくはないのですが、 Haskell 等にある Either<L, R> とは厳密には違うようです(Either は両方の値が使用可能であることを前提としている？) 参考: Rust ではなぜ、Either 型ではなく Result 型を採用しているのか neverthrow とは TypeScript で

先日、フォロワーさんのスペースを聴いていて、コミュ力が低くトラブルメーカーになりがち、あるいはそこまで行かなくても他人に避けられてしまう人を如何せん、という話が出てきたのだが、これはかなり以前から随所で持ち上がっている話であり、僕も長年、いや長年ではないか、まあ折にふれ考え続けてきたことではあった。 その方はなんでも、リアルで居場所的な空間を運営していたのだが、やはり困った人が居着いてしまい、それだけならいいのだが徐々に他の人の足が遠のいて、いつの間にかその人とマンツーマンみたいな状況になってしまったという。 あげくにその問題人物が主催者に「最近ここ閑古鳥ですねw」みたいなことを云ったのでブチギレて「そりゃお前のせいだろうが！」という一幕があったとか。 まさに「悪貨は良貨を駆逐する」。あるいは「悪縁は良縁の妨げ」ともいう。 でも実際あるんですよね。そういうケースは他でも目にしていて、往々に

駅奪取チームでエンジニアをしている id:kebhr です。 今回は、駅奪取チームにおけるプロジェクト管理のツールとして、従来利用していたガントチャートに加え、新たにバッファ傾向グラフを導入してみた経験について書きます。 バッファ傾向グラフとは このプロジェクトでは、プロジェクト管理手法として CCPM (Critical Chain Project Management) を採用しました。 CCPM では、個別のタスクにはバッファを設けず、すべてのバッファをプロジェクトの終盤に設けます。このバッファをプロジェクトバッファと呼びます。 必然的に、プロジェクトが進行するにつれて、プロジェクトバッファを消費していきます。 プロジェクトバッファの消費量を可視化するツールがバッファ傾向グラフです。 下図のような、横軸に日付、縦軸にバッファ消費率を取るグラフです。 バッファ傾向グラフ バッファ消費率

はじめに こんにちは！NewsPicksのVP Of Mobile Engineeringの石井です。 約1年前にPharmaXさん主催の「事例で学ぶ！エンジニア組織文化を作る採用・評価の仕組み」というイベントでPharmaX 取締役・エンジニアリング責任者の上野さん、カオナビCTOの松下さんと私の3人で事例発表やパネルディスカッションをしました。（そのときの記事は、PharmaXさんのこちらの記事にあります） このときに私が話したエンゲージメントに関することは、「採用とオンボーディングを頑張った結果、エンゲージメントもよくなりました」的な話もしました。 ただ、それ以外にも多くのことをしています。今回はそこを深掘りしたいと思います。 以前の状態との比較 当時、発表した時のモバイルチームのエンゲージメントは次の通りでした。（NewsPicksでは半期に一度、サーベイをしています） で、202

シンプルフォーム株式会社でインフラエンジニアをしている守屋です。 本記事では Aurora MySQL の OOM(メモリ不足)エラーについて、原因となるクエリを特定するために役立つ Tips を弊社での実例を交えてご紹介します。 発端 突如 Slack に鳴り響く不吉な通知。 「パターン青！障害です！！」 どうやら本番環境の Aurora クラスターがフェイルオーバーしてアプリケーションが DB コネクションエラーを引き起こした模様です。幸いインスタンスは冗長化していて Aurora のフェイルオーバーは高速であるため、ユーザー目線では瞬断が発生した程度の比較的影響が小さめな障害に留まりました。しかしインフラエンジニアとしては捨ておけない状況です！早速原因の調査を始めました。 フェイルオーバーの原因 結論から言うとメモリ使用量がスパイクして OOM エラーが発生したことが原因でした。根拠