技術選定の審美眼(2025年版) 2025/05/14(水) 技術選定を突き詰める〜 Online Conference 2025〜 https://findy.connpass.com/event/349580/

3年前、趣味で開発するウェブアプリ向けの安価なAWSアーキテクチャについて記事を書きました。当時流行りの話題だった記憶です。 趣味Webサービスをサーバーレスで作る ― 格安編 - maybe daily dev notes 最近はAWSにも新たに色々なサービスが出てきて、以前とは一味違う構成を取れるようになっています。この記事では、アップデートされた格安かつスケーラブルなウェブアプリ向けAWSアーキテクチャを紹介します。 コード 本記事で紹介するアーキテクチャのリファレンス実装は、以前と同じリポジトリに公開しています。 github.com 主な機能は下記です: Next.js App RouterをAWS Lambda上にデプロイ CloudFront + Lambda関数URLによるレスポンスストリーミング対応 クライアントからサーバー、DBまでの型安全性 Aurora Server
まともな(信頼できる)ステージング環境を用意できてるウェブ系企業、肌感だけど5%以下という印象— たにみち (@ttanimichi) 2018年8月20日 このツイートを見て弊社は5%に入れるかどうかを考えてみたいと思った。 が、そもそも何をステージング環境と呼ぶか、何をもって"まとも(信頼できる)"と言えるのかわからないのでそこから考えてみた。 ステージング環境とは 本記事中では「アプリケーション、システムの動作や表示を試験するための環境」とする。 試験の対象は機能・性能・外部連携などの多岐にわたる。また、試験を行うのはサーバサイド開発者、クライアントサイド開発者、デザイナー、カスタマーサポート、プロダクトマネージャ etc.…と、これも多岐にわたる。 まともであるために、ステージング環境で実現したいこと 少なくとも自分の感覚では、以下を実現できるのであれば良い開発体験(Develop
こんにちは、メルペイでSREとして従事している @myoshida です。この記事は Merpay Tech Openness Month 2021 の8日目の記事です。 SREチームはお客さまへよりよいサービス利用体験を提供するため、日々様々な改善活動に取り組んでいます。その活動の一環としてPlaybookの概念を導入し、運用者の運用負担を減らす取り組みを始めました。今回はそのことについて説明してみたいと思います。 概要 メルペイではアプリケーションエンジニアとSREの双方がオンコール制度のもと運用に携わっています。 運用の悩みは様々ですが、そのうちの1つに手順書の取り扱いがあります。 どこに置くべきか、更新はされているのか、何を書けばいいのか、どの場面でどの手順書を利用すればよいのかというような悩みはどこの現場でも少なからず存在すると思います。 そこで、Playbookと呼ばれる体系的
情報システムの基礎から負荷対策・パフォーマンスチューニングにミドルウェア構成、コンプライアンスまで バックエンドエンジニアとして10年後も最前線で活躍するための基礎体力をつくる1冊 本書はバックエンドエンジニアに求められるインフラ・クラウド領域の基礎知識を1冊にまとめた書籍です。現代の複雑化するシステムにおいて、バックエンドエンジニアに求められる知識は広範に及びます。自身の専門領域はもちろんのこと、隣接する領域の知識も現場では求められます。本書は分野ごとに解説をまとめていますが、隣接する領域もつづけて学習できるような仕掛けを散りばめました。ちょっとだけ調べるつもりが1時間経っている……そんな書籍に仕上がりました。 ■本書の特徴 ・豊富な図解 言葉だけではイメージがつかみづらい内容は図解でていねいに補足しています。視覚的にも理解できます。 ・最前線で活躍する著者による解説 今もなおインフラ・
エコおじい @ally_of_earth プラントエンジニア兼業務委託でWebライターや企業のブログ運営、アプリ開発、Xの運用代行をしています。エネ管.comという工業技術ブログ、Youtubeチャンネルを運営。月間20万PV、登録者2万人達成。資格はエネ管熱と電験三種。株式投資歴12年、アパート1棟運営中です。note.com/ecoogy energy-kanrishi.com エコおじい @ally_of_earth 技術職が「これは仕様だから」「それは無理」と言うたびに、営業は謝って頭を下げている。顧客の期待と現実の板挟みになって、感情のクッション材として毎日すり減っている人達を「飲み会要員」と揶揄する人は、一度自分で顧客対応をするしんどさを経験したほうがいいと思う。 2025-05-09 07:57:57
仕事における成長は、いつも順調とは限りません。 そして、成長が煮詰まる原因は一つではありません。 この記事では、「成長の壁」について整理します。 前提 この記事については、以下の方々は対象外としています。 成長への関心や動機がない人 興味・関心のままに振る舞っていれば自然と成長できる人 ※上記の方々を否定する意図はありません。 成長の壁 成長の壁の典型的な例として、以下のようなものがあります。 次のゴールが決まっていない 次のゴールは決まっているが、必要な要素が分からない 必要な要素は分かっているが、どのように伸ばせばよいか分からない 伸ばし方は分かっているが、実践の機会がない 機会はあるが、客観的なフィードバックを得る相手がいない 1. 次のゴールが決まっていない 次にどこを目指すかについて決まっていないと成長に必要な要素も現状も把握できません。 たとえば、現状中堅のウェブエンジニアの人
前回までの連載のあと、2023年秋に『Obsidianで"育てる"最強ノート術』を刊行しました。そして2025年になって、Obsidianが大きく注目を集めています。今回はその背景と理由について解説します。 AIとの連携 ObsidianはノートアプリやPKM(Personal Knowledge Management)ツールとして注目を集めました。主な特徴として、この連載でも解説してきた次のことが挙げられます。 ローカル環境で動作する Markdownで書いたノートをリンクできる 階層型のタグで管理できる プラグインで拡張できる そんな中、2025年になって注目された背景として、「AI(人工知能)との連携」があります。ここでは「生成AIの進化」「RAGとMCPの登場」「AIエージェントの登場」という3つの視点から紹介します。 生成AIの進化 2022年末にChatGPTが公開されて
CTO 室の恩田(@takashi_onda)です。 一休レストランのフロントエンドアーキテクトを担当しています。 Intro 一休レストランでは、以前ご紹介したようにフロントエンドで React / Remix を利用しています。 user-first.ikyu.co.jp 一方、設計方針としては、React / Remix への依存が最小になるように心掛けています。 今日は、そんな一見矛盾するような設計方針について、ご紹介したいと思います。 この記事を読んでいただき Remix に興味をもたれたら、明後日 2024/8/7(水) 19:00〜 のオンラインイベント offers-jp.connpass.com にもご参加いただけると嬉しいです。 この記事でご紹介している疎結合なフロントエンドアーキテクチャを実現する Remix の魅力についてお話します。 なぜ依存を最小にするのか? R
font-size-rem.md font-size には rem を使うべきかどうかについての見解 結論 可能であれば Chrome の文字拡大機能をサポートするためにremを使用する。 ただし、実際に Chrome の文字拡大機能を「極大」にして検証することが必須条件。これに時間的・労働的なコストを割けないのならpxを使用したほうがいい。 結論に至った背景 「font-size には rem を使いましょう」という教えが独り歩きしており、実際に Chrome の文字拡大機能を「極大」にして検証していない人が多いため。 font-size だけ rem を指定すればいいという訳ではなく、文字拡大に伴ったレイアウトの変更に耐えうる設計とする必要がある。つまり、font-size だけでなく文字の拡大に依存する余白やサイズなどもフォントサイズを基準とした相対値(remやemなど)で指定する必
燃え尽き症候群燃え尽き症候群、という言葉を聞いたことはあるでしょうか。聞いたことがない、または言葉は聞いたことがあるけれどよく知らない、という方は、以下が燃え尽き症候群の傾向だよ、というポイントをおさえていただければ。 消耗感(Exhaustion):エネルギーの枯渇、疲れ切った感覚 シニシズム(Cynicism):仕事に対する距離感や否定的な態度 効力感の低下(Inefficacy):業務上の達成感や能力に対する自信の低下 なぜ燃え尽きてしまうのか燃え尽きたい…。矢吹丈のように全力を出し、後には真っ白な灰だけが残る、そういう生き方を望む人もいるでしょう。個人の考えですが、そういった自ら燃やし尽くすことを選ぶ人がそうなることは決して否定はしません。命は燃やし尽くすためのもの、かもしれませんから。 でも、それを望まず、意図せずして燃え尽きてしまうことは、できれば避けたいですね。じゃあ、なんで
初めに 本記事 『ゼロから始めるシステム障害対応フロー』 の内容について タイトルの「ゼロから始める」には二つの意味があります。プロダクトのリリースを間近に迎える中、チーム内での障害対応体制の枠組みがなかったこと。そして体制づくりを担当することとなった私の知識・知見が(ほぼ)ゼロだったこと。この二つです。 この状態から、リリース前〜リリース後の約2月間でなんとか形にすることができました。本記事ではその過程でぶつかった問題とそれに対する課題、それらにどう対応したのか、何を学んだのか、の紹介。 そして、障害対応体制の策定・構築や改善の流れの中で私が起こした失敗から、人としてリーダーとして何を心がけなければいけなかったのかの反省を共有させてもらいたいと思います。 本記事は以下の構成です。 0. 始まり ※ スクラムチームでの話。スクラムチームの登場人物は以下の三つ PO:プロダクトオーナー(Pd
おはこんばんちは、SREの橋本です。この記事は、freee Developers Advent Calendar 2021の16日め記事となります。 わたしがソフトウェアエンジニアとして仕事をするうえで、コミットログを詳細に記述する習慣づけがあり、この機会にその具体例をあえて共有してみます*1。以降はとくに明示しない限り、組織全体でルールがあるわけではなく、あくまでわたしの一個人の意見である点に注意してください。 モチベーション freeeでは、Webサービスからインフラ基盤およびその監視設定を含めてコードで管理されており、GitHub上でのPull Requestでのレビューを必須としています。わたし自身は社内の立候補制異動制度*2によってWeb開発の現場とSREを行き来してきましたが、どちらもリファクタリングのためにゼロベースでコードを書き直すこともあれば、機能追加やバグフィックスのた
自分の関わるアプリケーションやインフラのモニタリングに困っている? オーケイ、冒頭からアクセル全開の力強いワードにあふれたこの一冊を紹介するぜ! はじめに 今年(2023年)の1月末に発売されたこちらの本、もう読まれたという方も多いのではないでしょうか!(挨拶 本記事は、まだ読まれていない、買ってもいないという方に向けて、「紹介しなきゃ」という謎の強い使命感をもって書かれています。 というのも、実は本記事の執筆者(ぼくです)は、300ページを越えるこの本のまだ半分ほどしか読むことが出来ていません。。! *1 それでもこの本を紹介するモチベーションは十分です。なにしろ、この本は冒頭から、もっといえば「まえがき」の段階から、パワーワードにあふれた一冊だからです。引用してみましょう。 “(「オブザーバビリティ」という)用語が注目されるようになると、ある種の隣接性を共有する別の用語と互換的に使われ
ハイクラス求人TOPIT記事一覧Terraformを使って学ぶーAWSにインフラを構築するIaCの基本と、SREが実務で役立つ機能とエコシステムを徹底解説 Terraformを使って学ぶーAWSにインフラを構築するIaCの基本と、SREが実務で役立つ機能とエコシステムを徹底解説 Terraformは、パブリッククラウドのインフラ構築と自動化のツールとして、IaCのデファクトスタンダードとなっています。この記事では、AWS(Amazon Web Services)を活用するハンズオンを通してTerraformの動作を理解し、実務にもとづいて役立つ機能や便利なエコシステム、さらにSRE視点の事例を紹介します。アソビュー株式会社でSREユニットリーダーを務める鈴木剛志さんを中心に6名のメンバーによる共同執筆です。 アイキャッチ画像 アソビューでは、インフラストラクチャーの変更管理にTerrafo
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く