Qiita is a knowledge sharing service for engineers. You can follow users and tagsYou can stock useful informationYou can make edit suggestions for articlesFunctions that can be used after logging in

なぜ調べたか 実務でWebアプリケーションの開発をしていると、主にエラーハンドリングの文脈で タイムアウト という概念が度々登場します Wikipediaの当該記事 を読むと、以下のような説明がなされています 一定時間に処理が完了しなかった時に、制御を打ち切って中止するための機構 処理完了までに永遠、または非常に長い時間がかかってしまうケースにおいて、計算資源の占有を抑止する これは、タイムアウト制御の必要性とそれが解決する問題について端的に説明していますが、 具体的な対応方法や、実務においてどのような観点に気を配るべきかについては示されていません 私自身、十分な対応をおこなえていなかったことで、レスポンスタイムの低下や、最悪のケースではサービスダウンを引き起こしてしまったこともありました そうした経験を踏まえ、シンプルなWebアプリケーションを想定したときに、 アーキテクチャ中の各レイヤ

お知らせ：noteの更新はこれからしないので同じ内容を読みたい方はThe Pathをご覧ください ジョブレベル呼び方は組織によって違うが一般的にジョブレベルは ジュニア（新卒・インターンなど） ミッド シニア スタッフ -> シニアスタッフなど/マネージャ -> シニアマネージャ のように分けられてます。 実例を見るとwiseはこのようにキャリアマップを作っています wiseエンジニアのキャリアマップシニアに到達するとその次はICのトラック（スタフ、プリンシパル）を続けるかピープルマネジメントトラック（エンジニアリングリード、シニアエンジニアリングリード、ディレクター）に移すか選択できる。もちろんシニアのままにいるのも企業によって可能だったりします。シニアエンジニアは１人前でタスクをこなせたりプロジェクトをリードしたりできると期待されているでしょう。チームメイトのメンターシップも必要があれ

はじめに AWSの豊富なサービス群を活用することで、高可用性かつ高スケール性を実現するシステムを構築することが可能です。 しかし、クラウドサービスの特性を最大限に活かすためには、適切なデザインパターンを理解し、実践することが重要です。そこで今回は、AWSを利用して「高可用性」かつ「高スケール性」を実現するための代表的なクラウドデザインパターンを紹介します。 1. EC2インスタンスを利用した動的コンテンツの配信 動的コンテンツとは？ 動的コンテンツとは、ユーザーのリクエストに応じて生成されるコンテンツのことを指します。たとえば、ユーザーのログイン状況や入力内容に基づいて異なるページを表示するようなケースです。 AWSサービスの簡単な解説 Amazon EC2 (Elastic Compute Cloud): スケーラブルなコンピューティングリソースを提供するサービスです。必要に応じて、イン

PPR の登場でだいたい登場人物が出揃ったかな、というタイミングのため、一度まとめる。 左が古いもの、右が新しいもので並べている。 これらの目的 いたずらに登場人物を増やしているわけではなく、解決したい課題に対する解法としてこれらがある。というわけで、そもそもこれらが出てきた目的に立ち戻って考えてみる。 と言っても特に難しいことはなく、すべてユーザーからのリクエストを起点としてできるだけ速くユーザーが画面を操作できるようにするためのものだ。特に最近出てきたものほどその傾向が強い。 速度にこだわる理由は、コンバージョンや売上の減少を回避するためが大きいだろうか。ユーザーが短い時間で目的を達成できるのであればそれに越したことはないし、ともすればロイヤルティも向上する。 待ち時間は少ないほうが良いのか？ ここではどういった状況であっても待ち時間は少ないほうが喜ばしいという推測に立っている。が、す

React19のRCが発表され数ヶ月が経ちました。Next.jsではReact19のExperimentalな機能を使った実装をいち早くしていたので、少し馴染みのあるアップデートが多かったように思います。 Next.js（特にApp Router）においてReact19のAPIやHooksをどのように使うべきかはNext.jsのドキュメントを見れば大体のベストプラクティスが見えてきます。ですが、実際の開発現場ではApp Routerを採用しているケース以外にもVite+ReactやPages Router, Remixなどと様々な実装があるのが現実です。 そこでこの記事では、特にVite+Reactのスタックを前提にReact19の新機能をいかに活用できるか整理したいと考えています。 また、React19の新機能を見た時にTanStack QueryやSWRのようなサードパーティの状態管理

背景 Next.js に App Router が導入されてから1年近くが経ちました。しかし、未だに App Router を前提として設計のベストプラクティスが定まっておらず、身近なフロントエンドエンジニアはみな「まだプロダクトに取り入れるには考えることが多いよね」という共通認識のまま止まっているような気がしています。 また、App Router が導入されるまでは、技術選定の無難な選択肢として Next.js が最有力でした。しかし、現在は App Router の設計のプラクティスが未発達なことや、オーバースペックであるという見方が出てきており、検討しなければならないことが多くなったように感じます。 そうした中で、ではその懸念というのはどのようなものがあり、導入しずらい要因に何があるのか、というところが、今回執筆を行う上での背景になります。 App Router導入で考えないといけな

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに エンジニアとしての投資の重要性を実感していない人は多い 新NISAが始まったことによって、将来に向けて少額を投資するというのが世間的にも一般的に行われるようになりました。これによりYoutubeや書籍などでは金融に関するものがヒットする傾向にあります。 投資がなぜ重要なのか、なぜいまから始めるべきなのか、単利や複利などを多くの人が理解して実施する中で、 「積立投資の重要性を理解して実施している人は多いものの、エンジニアとしての投資を同じ発想で行えている人はまだ少ない」 このように思うことがありました。 この記事ではエンジニアと

はじめに 最近書いてるソフトウェア設計シリーズです。今回は例外に関して。以前、以下のような記事を書いたのですが、もう少し深堀して書いてみました。 ちなみにソフトウェア設計シリーズは他には以下を書いています。 モジュールになぜ分けるのか？ モジュール、依存、そしてカプセル化 モジュールをどう分割するのか？ 簡潔さは力なり？　予測可能な振る舞いと簡潔さについて ドキュメントとしてのコメント TL;DR 例外は「原則」キャッチしない 業務例外や必ずハンドリングさせたい例外はOptionalなど戻り値の方が便利 だいたい以下の図が言いたい事のすべて 例外処理とは？ 「例外処理(Exception Handling)」は言語に依らず普遍的な関心事です。端的に言えば例外処理は異常やシステムの動作に不備が発生した際の特別な分岐処理です。リカバリやリソースの解放、あるいはユーザへの通知などがありますね。

はじめに こんにちは、FarStep です。 プログラミングを学ぶ中で、「プロセス」と「スレッド」という言葉を耳にしたことがある方は多いと思います。 しかし、これらの違いを明確に説明できる自信がない方も多いのではないでしょうか。 本記事では、プロセスとスレッドの違いについて、エッセンスを抽出して 解説します。 説明を簡潔にしましたので、本記事は 5 分程度で読み終えることができます。 本記事の内容を自分の言葉で説明できるようになれば、プロセスとスレッドの違いの理解は十分でしょう。 それでは、始めます 🚀 プログラムとは プロセスとスレッドの違いを理解する前に、まずは「プログラム」について理解しましょう。 プログラムとは、プログラミング言語で書かれた一連の命令 のことです。 プログラミング言語の例としては、以下のようなものがあります。 C 言語 Java Python Ruby JavaS

普段Gitを使ってて頻繁にブランチの切り替えを実行しているとたまに git pull を忘れてしまい、作業が完了して git push しようとすると既にリモートには別のコミットが存在してエラーになってしまうことがあります。 その時には git pull すればいいんですが、コミットログに不要な merge が入ってしまい少し気持ち悪いですね。 Gitでブランチを切り替える際に自動的に最新の状態を pull すればそういう問題は解消しそうです。 Git Hooks Git HooksとはGitで何かしらのイベントが発生する前後でスクリプトを実行可能にする仕組みです。 exit 0 でスクリプトが終了すればその先の処理も実行されますがそれ以外( exit 1 など )で終了すると処理を途中で止めることができます。 具体的には公式のドキュメントを参考にしてください。 post-checkout

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに 開発生産性をテーマとした技術イベントに出まくった結果、ある程度体系化された知識のおすそわけ記事です。 この記事を読めばわかること 開発生産性のトピックでよく語られている前提の部分 開発生産性を語るうえで大事なざっくりとした体系的な知識 開発生産性を測るためによく使われるメトリクス 雑に言えば、数字とってデータ駆動でPDCA回そうという話です。 この記事を読んだ後に、「開発生産性の議論 ﾅﾝﾓﾜｶﾗﾝ ...。」という人でも「まずはこの辺調べてみよう」ができる状態になればいいなと思って書いてます。 この記事を読んでもわからないこ

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに 「テーブル・DBを設計するときのさいきょうの極意」を完全に理解したので 初心者（私）向けに共有する記事です。 どうぞ揉んでいただければ幸いです。対戦よろしくお願いします。 さいきょうの極意 初心者が「テーブル・DB設計して」と言われると、 「アソシエーションってあったよね・・・バリデーションも？中間テーブルを使うときと使わないときと・・・」と大変に混乱し、何から手をつけていいかわからなくなります。 そんなあなたにこれ！ ・テーブル・DB設計は「属性」と「関係」の２つだけ ・「属性」は必要なものを書くだけ ・「関係」は 1:1

はじめに Git Graphという拡張機能を使います。 Git GraphとGitLensという拡張機能を使います。[1] また、gitから開かれるエディタをvscodeにしておきます。 コミットのまとめかた（1分未満でできるよ） ステータスバーのGit Graphのボタンをクリックして、Git Graphの画面を開きます。 まとめたいコミットの一つ前のコミット（今回だとinit）を右クリックして、「Rebase current branch on this Commit...」を選択します。 「Launch Interactive Rebase in new Terminal」にチェックを入れて「Yes, rebase」をクリックします。 こんな画面が開きます。 まとめたいコミットを上から順にpickからsquashに変更します。最後の一つはpickのままにしておきます。そして「STAR

概要 レビューコメントを残す際にラベルやアラートを付けるどのような指摘なのかがより明確に伝わり、対応するべきか、そのままでいいのか判断しやすくなります。 Gitシリーズ記事まとめ 各種機能紹介 Saved replies 公式で用意されている、IssueやPull Requestを書く際に使用できる返信テンプレートを管理できます。 Alert マークダウン形式でアイコンと色で重要性を使い分けることができます。 Shields.io 公式の機能ではないですが、よくGitHubのREADMEなどにおしゃれなバッジを付ける時に利用されます。 返信テンプレートに登録する こちらのリンクからテンプレートを設定します。 何でも登録できますが、私は下記の設定をしてます。ご参考にどうぞ ラベルを使うのか、アラートを使うのかはぶっちゃけ好みだと思うので、自分が好きだと思う方を使ってみてください！ ラベル 絶

Dain 古今東西のスゴ本（すごい本）を探しまくり、読みまくる書評ブログ「わたしが知らないスゴ本は、きっとあなたが読んでいる」の中の人。自分のアンテナだけを頼りにした閉鎖的な読書から、本を介して人とつながるスタイルへの変化と発見を、ブログに書き続けて10年以上。書評家の傍ら、エンジニア・PMとしても活動している。 わたしが知らないスゴ本は、きっとあなたが読んでいる keyboard_arrow_down はじめに keyboard_arrow_down 独学のキモは「いかに継続するか」 keyboard_arrow_down 「顧客が本当に必要だったもの」をいつ知るか？ keyboard_arrow_down チームに笑顔を keyboard_arrow_down 質の高い課題を見極める keyboard_arrow_down 技術を哲学する keyboard_arrow_down おわり

はじめに タイトルのとおり、RDBのデータモデリング・テーブル設計を行う際に参考にしている考え方と関連資料をまとめました。 P.S. なんと本記事内でいくつか参考として挙げさせてもらっている増田さん・かとじゅんさん・奥野さん・そーだいさんからコメントいただくことができました。 本当にありがとうございます。 前提 RDBを採用するのは事実を無駄なく正しく記録するため 正規化、トランザクション、制約とデータ整合性 基本的には始めに理想として集合論・リレーショナルモデルに基づいて正規化を考え(論理設計)、パフォーマンスなどの現実問題に対して折り合いをつけていく(物理設計) 制約を最大限利用する cf: ↑P91〜 ↑P.29,41 ↑P56〜 ↑5章 ↑P347～ 情報とデータ データ：単なる事実の値→これを永続化して蓄えるものがRDB 情報：データから生み出される意味や目的のあるもの→RDBか

PostgreSQLのインデックス再編成 インデックスは肥大化しやすいので、再編成が必要になることが多いと思います。 実際にインデックスがどのように肥大化するか確認してみます。 まずはテスト用のテーブルを作成し、データ（500万件）を投入します。 drop table testa; create table testa ( id numeric, txt varchar(10) ); insert into testa(id, txt) select i, '0123456789' from generate_series(1, 5000000) as i; create unique index idx_testa01 on testa(id);

はじめに 昨年、AWS のインフラを運用・監視する上で使いやすいと思ったサービスを組み合わせて構成図を紹介した記事、「【AWS】ぼくのかんがえたさいきょうの運用・監視構成」が投稿したその日の Qiita のトレンド 1 位になり、はてなブックマークのテクノロジー分野でトップを飾りました。（たくさんの方に見ていただき感謝してます！） 本記事では「ぼくのかんがえたさいきょうの運用・監視構成」の続編として「ぼくのかんがえたさいきょうの DevOps 実現構成」を紹介させていただきます。あくまでも「ぼくのかんがえた」なので私個人の意見として受け入れていただけると助かります。 前回の記事でもお伝えいたしましたが、各個人・企業によって環境は違うと思いますし、使いやすいサービスは人それぞれだと思うので、これが正解という訳ではありません。一個人の意見として参考にしてただければ幸いです。 また、こちらの記事

Bashでスクリプトを書く場合のポイントをまとめた Bashなどで書くシェルスクリプトは文法がシンプルで覚えると便利。他のプログラム言語だと何行もかかなければならないファイル操作や中身のデータ処理を、ちょちょいと数行レベルで書けとても強力だ。コマンドとの親和性が高い恩恵だろう1。 旧来バッチ処理で本領を発揮するシェルスクリプトだったが、昨今はDocker（Dockerfileや起動スクリプトなど）で活用される機会も多いだろう。 しかしながら他のプログラム言語ではみられない記法があったり、逆に似た書き方もあったりと、混乱しがちなのもシェルスクリプトの特徴かもしれない。 いちいちGoogle先生に確認するのもめんどうなので、このページに整理した2。 主な参照先（よくお世話になっているページ）： UNIXの部屋(68user's page) - http://x68000.q-e-d.net/~