はじめに エンジニアとしての投資の重要性を実感していない人は多い 新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

はじめに 開発生産性をテーマとした技術イベントに出まくった結果、ある程度体系化された知識のおすそわけ記事です。 この記事を読めばわかること 開発生産性のトピックでよく語られている前提の部分 開発生産性を語るうえで大事なざっくりとした体系的な知識 開発生産性を測るためによく使われるメトリクス 雑に言えば、数字とってデータ駆動でPDCA回そうという話です。 この記事を読んだ後に、「開発生産性の議論 ﾅﾝﾓﾜｶﾗﾝ ...。」という人でも「まずはこの辺調べてみよう」ができる状態になればいいなと思って書いてます。 この記事を読んでもわからないこと 開発生産性の文脈におけるビジネスサイドとのコミュニケーションらへん 開発生産性の文脈における経営層とのコミュニケーションらへん 目次 開発生産性についての前提 開発生産性と言うクソデカワードの認識をそろえる 開発生産性には３つのレベルがあることを知る な

はじめに 「テーブル・DBを設計するときのさいきょうの極意」を完全に理解したので 初心者（私）向けに共有する記事です。 どうぞ揉んでいただければ幸いです。対戦よろしくお願いします。 さいきょうの極意 初心者が「テーブル・DB設計して」と言われると、 「アソシエーションってあったよね・・・バリデーションも？中間テーブルを使うときと使わないときと・・・」と大変に混乱し、何から手をつけていいかわからなくなります。 そんなあなたにこれ！ テーブル・DB設計は「属性」と「関係」の２つだけ 「属性」は必要なものを書くだけ 「関係」は 1:1 / 1:N / N:N しかない（しかも、ほとんど 1:N） これが極意だ！！！ 一般的な、「ユーザーがいて、投稿ができて、コメントといいねができるサービス」で考えてみましょうか。 users / posts / comments / likes のテーブルが必要

はじめに 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か

インデックスは肥大化しやすいので、再編成が必要になることが多いと思います。 実際にインデックスがどのように肥大化するか確認してみます。 まずはテスト用のテーブルを作成し、データ（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/~

AWSのインフラを運用・監視する上で使いやすいと思ったサービスを組み合わせて構成図を作成しました。それぞれのサービスの簡単な説明と類似サービスの紹介、また構成の詳細について説明していきます。 (開発で使用するようなサービスも紹介しますが、あくまでも運用・監視だけの構成です。) 各個人・企業によって環境は違うと思いますし、使いやすいと思うサービスは人それぞれだと思うので、これが正解という訳ではありませんが、参考にしてただければ幸いです。 参考になった教材を紹介した記事も作成しました。是非読んでみてください！ 【AWS】さいきょうの運用・監視構成を作成するのに参考になった書籍 インフラエンジニア1年生がプログラミングを勉強するのに使った教材 全体図 こちらがAWSにおける"ぼくのかんがえたさいきょうの"運用・監視構成です。複雑で分かりづらいかと思うので、詳細に説明していきます。最後まで読めばこ

株式会社シャペロンのsrkwです。 シャペロンでは昨年、Playwrightを使ったE2Eテストによる各種機能の検証の自動化を導入しました。 E2Eテスト導入の背景や、チームへの浸透に向けた取り組みと反省等については別の記事で紹介しているので、興味のある方はこちらも併せてご覧ください。 この記事では、シャペロンの日次のE2Eテスト実行を支えるインフラ構成と、PlaywrightによるE2Eテスト導入によって溜まったtipsをご紹介したいと思います。同じようにPlaywrightを使ったE2Eテスト導入を検討している、あるいは導入済みで格闘している方にとって、少しでもお役に立てると嬉しいです。 日次のE2Eテスト実行を支えるインフラ構成 前提:Shaperonのテナント構成 シャペロンは製薬企業向けのコミュニケーション用SaaS、Shaperonを提供しており、Shaperonは利用テナント

この記事で書いていること ORMを使っていると、知らぬ間に大量のSQLが発行されてる恐れがある クエリ数を発行しないための工夫がいくつかあるので、それを紹介する 新しい使えるテクニックを見つけたら、随時加筆予定 ORMでは知らぬうちに大量のクエリが発行されているかもしれない 私が触ったことのあるフレームワークはRails、Djangoだけなので、ORマッパーがあるのが当たり前という環境で育ってきました。 そのため、DBにアクセスするためにSQLが発行されていることをあまり意識してきませんでした。（お恥ずかしい限りですが） これから職業プログラマーとして成長していくためにはそんなんじゃあかんという訳で、絶賛試行錯誤中です。 今回は私が調べたり、先輩から教えてもらったクエリ数を抑える工夫やテクニックを紹介していこうと思います。 クエリ数を観測するには、「django-debug-toolbar

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

はじめに Cloud Run から 別の Cloud Run へアクセスするときに、その Cloud Run って「すべてのインターネットからアクセスさせる」必要ってあるのかな？という疑問がありました🤔 公式ドキュメント[1]を読むと Cloud Run からのアクセスをInternal (内部)として扱う方法について記載がありました。 3つの方法があるようですが、どうも理解が進まないので実際に検証してみたいと思います。 やりたいこと 検証プロセスの概観 Cloud Run を2つ作成します。以下はそれぞれのコードです。 client-node : server-node に対して、HTTPリクエストを投げる Cloud Run。この Cloud Run は常に 内向きは「すべて」とする。 リクエスト先 Cloud Run の公開URLを環境変数として設定している server-node

今までのインデックスについての自分の理解が、「インデックスを作ると検索スピードが上がる」くらいの理解でした。これではいけないと思い、ようやく真面目に勉強したのでそれをまとめるついでにクイズ形式にしてみました。 インデックスとは データベースにおけるインデックスは、データの検索速度を向上させるための機能です。一般的に、テーブル内のデータの特定の列に対して作成され、その列の値に基づいてデータにアクセスする際の効率を高めます。 よくある例でインデックスは本でいう索引に当たります。見たい項目を索引で探し、何ページかを確認してそのページを開けば一枚一枚ページをめくって探すより効率的に目当てのページに辿り着けますよね。 それをデータベースでも同じことをしているというイメージです。 第一問 以下 SQL 文でインデックスが使用される検索はいくつあるでしょうか？

目的 Djangoでデータベースとやり取りする際に、ORMを使うことが多いかと思います。 ORMは非常に強力ですが、場合によってはレスポンスタイムの悪化を引き起こすことがあります。 今回はその原因となる「N+1」問題についてと、その解決方法を示します。 N+1問題とは データベース上のデータを取得する際に発生する性能の問題です。 一般的に、1つの主データに対して、それに紐づく複数のデータを取得する場合、1回のクエリで主データと全ての紐づくデータを取得することが望ましいとされます。 しかし、ORMを使用した際に、1つの主データに対して、それに紐づく複数のデータを取得する際、1つの主データに対して1回のクエリを発行し、その紐づくデータを1つずつ取得することがあります。 結果 「主データ(1) + 紐づくデータ数(N)」 の数だけクエリが発行され、性能劣化を引き起こします。 N+1問題とは 主デ