はじめに エンジニアに関する情報量は日本よりも海外（特にアメリカ）の方が圧倒的です。 そのため、英語での情報収集を習慣付けておくとより早く必要な情報に辿り着くことができます。 英語がわからない場合は、ChatGPTに全てコピペして翻訳させましょう！日本語ネイティブの皆さんでも余裕で海外コンテンツを見ることができるでしょう！ 本記事では、濃い情報が集まる場所をまとめました。 日頃の情報収集やキャリアに関する情報まで幅広くまとめたので、エンジニア学生や初学者にとって役に立つ内容かと思います。 ChatGPTと紹介している情報源を連携すれば、英語が苦手だとしても必要な情報に素早く辿り着くことができるでしょう。 本記事の対象読者： 日頃の学習に役立つ情報源を知りたい方 年収やキャリアに関する情報を手に入れたい方 インターンや就活前に情報を仕入れておきたい方 本記事の構成 学習系 ニュース系 キャリ

The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024

「CTOの視点で選ぶ「最適な」アーキテクチャとは？」というイベントで登壇しました。 本記事は登壇資料をMarkdownとしてそのまま記事化したものです。スライドのほうが読みやすい方は、Speaker Deckで御覧ください！ 自己紹介1｜職歴、趣味など 職種・SNS 株式会社NoSchool CTO 2016年〜Webエンジニア。2019年〜現職 Twitter(X): 名人｜マナリンクCTO Zenn: https://zenn.dev/meijin 好きなHTTPヘッダーはCache-Control 趣味 将棋☗、カメラ📸、ラム酒🥃、個人開発💻、筋トレ💪、高校野球観戦⚾ 自己紹介2｜外部発信・諸活動 ZennでReact記事が人気 歴代記事でLike数1位（登壇時点） 個人開発 テストメーカー（ユーザー20,000人以上） エンジニア向け教材執筆 「LaravelでFat Co

※月単価80万円を基準に、7ヶ月分の工数として560万円相当と換算しています。 最初に こんにちは！ 普段はIT企業でWebエンジニアとして働いています。 現在はフリーランスとして活動し、Ruby（Ruby on Rails）、TypeScript（Next.js, React）、Pythonなどを使って、フロントエンドとバックエンドの両方に携わっています。 将来はソフトウェアエンジニアとしてアーキテクチャ・設計について自ら意思決定した上、プロジェクトを推進する事が出来るようになりたいです。 そのためさらにスキルを磨いていきたいと思っており、日々技術に対して情熱を持って仕事に取り組んでいます。 以前Qiitaで 退職して560万円相当の工数をかけてお金を稼ぐサービスを開発した という事でBizRankというビジネス書籍を紹介するサービスを開発しました。 今回はその後としてのお話になります。

この記事は以前 エンジニアと人生 というオンラインコミュニティで執筆し技術書典で頒布した本の中の、私の執筆した章をリライトしたものです。 無料公開の背景 本は有料で販売していたのでこの記事も有料記事にしようかとも思っていましたが、最近個人開発をネタにした特に中身のない記事を有料で買ってしまい後悔している友人を見かけて、そういうのにうんざりしていたので無料で公開することにしました。 個人開発云々いうなら中身のない情報商材じゃなくて自分のサービスで稼げよな！ ということで。でも投げ銭はありがたくいただくのでいいと思ったらバッジしてください！ 【追記】 上記に対して「有料記事がダメって事？」という反応を頂きました。書き方が悪く申し訳ありません。 有料でノウハウなどを販売する事は良いと思います！そしてそれでサービスの運営費を賄えるなら嬉しい事です。 なんならサービスに関する事ならこの記事の"データ

本日10/23発売の「絵で見てわかるLinuxカーネルの仕組み」という本を自分含め6人で書きましたので、宣伝します。 絵で見てわかるLinuxカーネルの仕組み 作者:市川 正美,大岩 尚宏,島本 裕志,武内 覚,田中 隆久,丸山 翔平翔泳社Amazon 本書はIT技術のさまざまな分野について視覚的に理解するための翔泳社の「絵で見てわかる」シリーズの中の一冊です。 www.shoeisha.co.jp このシリーズは、これまでに「ITインフラの仕組み」、「Webアプリ開発の仕組み」、「マイクロサービスの仕組み」など、さまざまなものを扱ってきました。本書は「Linuxカーネル*1の仕組み」を扱います。Linuxカーネルを絵から理解するというコンセプトの本です。 Linuxカーネルは Red Hat Enterprise LinuxやUbuntuといったLinuxディストリビューションの核(カー

この本では、初心者・入門者の方に向けて、Next.jsの知識や使い方を体系的にまとめました。 【概要】 ・内容：HTML・CSS・JavaScriptとは？、Next.jsとは？、アプリを作る上での環境を整えよう！、Next.jsのプロジェクトを作ろう！、チャットアプリのパーツを作ろう！、オウム返しAPIを作ろう！、MUIを使ってリッチにしよう！、Vercelにデプロイしよう！、【余談】Joy.uiによるUIの変更 ・所要時間：約3時間 ・必須条件：HTMLの知識、CSSの知識、JavaScriptの知識 ・推奨OS：macOS / windows(WSL2) ・レベル：★★☆☆☆

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに 今年の夏はTOEICスコア900超えを一つの目標にしていて、そのためにはリスニングが課題でした。 とにかく数をこなそうと、無料で問題を解けるアプリを探して、初めはそれをずっとやっていましたが、一日に解ける問題数が限られていて、徐々に物足りなくなってきました。 前々からTOEICの問題ってAIで生成できるんじゃね？と思っていたので、この際スコア900越えに加えて、AIでリスニング問題生成＆Webサービス化を目標にし、ようやく完成したので公開しました。 公開したリスニング問題AI生成サイト ※AIで生成し、内容のチェックは行ってい

参考 IT業界では、請負契約と準委任契約がよく使われます。 委任契約はあまり使われることはなく、筆者も見たことがありません。 これは、エンジニアが法律行為を伴う業務を行うことが少ないためです。 請負契約と準委任契約の違い 請負契約と準委任契約は、どちらも業務委託契約の一種ですが、大きな違いがあります。 一言でいうと、請負契約は「成果物を納品することが目的」であり、準委任契約は「業務の遂行自体が目的」です。 請負契約では成果物を納品する責任が発生しますが、準委任契約ではその責任は発生しません。 ウォーターフォール開発で言うと、PoCや要件定義は準委任契約、設計や開発、テストは請負契約になることが多いです。 また、SES（システムエンジニアリングサービス）も準委任契約で結ばれることが多いですね。 PoCや要件定義が準委任契約になることが多いのは、不確定要素が多いため、確実に成果物を納品すること

Jotaiのテスト方法に関する記事があんまりないので書きました。 公式ドキュメントにもテストに関するページはあるのですが、わりとあっさりしていて実際テストしようと思うと手探り感が強いです。 この記事では、公式の内容に加えて、Reactに依存せず必要なatomのみをテストする方法をまとめます。 環境＆バージョン viteのテンプレでReactのアプリを作って、JotaiとVitestを入れます。すべてテンプレのデフォルトまたは執筆時の最新版です。そのほかlinter等（biome, eslint）は好きに調整してください ※ 後述しますが、テストのやり方によってはここまでフルセットに色々入れる必要はないこともあります。ここに書いたのこの記事で書かれているテストを動かすための全部入り構成です。 { "dependencies": { "jotai": "^2.10.0", "react": "

YAPC::Hakodate 2024での発表内容です。 https://yapcjapan.org/2024hakodate/

9月26, 27日に開催され、めちゃくちゃ盛り上がったRails World 2024でKamal 2が発表されました。Kamal 2はRuby on Railsを作った37signals社が、自社の人気サービスをデプロイするのに使用しているツールです。 37signals社はAWS等のクラウドに年間で$3,201,564を使った(2022年: 日本円で4.5億円ほど)らしく、一方でAWSを使ってもインフラ系人員の削減もほとんどできなかったので、全然割に合わないからもうクラウドはやめて自分たちのサーバを使うと宣言しています。Kamal 2はそのために作られた、本格的なデプロイツールです。 （ちなみに自分たちのサーバを使うと言ってもオンプレミスでサーバを運用するというのではなく、さくらの専用サーバに近いイメージです） Dockerベース Docker化されたアプリなら何にでも対応 (Rail

こんにちは。 株式会社ラクスで先行技術検証をしたり、ビジネス部門向けに技術情報を提供する取り組みを行っている「技術推進課」という部署に所属している鈴木（@moomooya）です。 ラクスの開発部ではこれまで社内で利用していなかった技術要素を自社の開発に適合するか検証し、ビジネス要求に対して迅速に応えられるようにそなえる 「技術推進プロジェクト」というプロジェクトがあります。 このプロジェクトで「PostgreSQL環境における、DB定義変更を伴う無停止リリース」にまつわる検証を進めているので、その中間報告を共有しようかと思います。 ※本記事はタイトルに「概要と計画」編とあるように、通年で行う調査の前半時点の中間報告となります。 実際の検証結果については3月末に予定している後編をお待ち下さい。 課題の経緯、前提条件 課題の経緯 無停止リリース実現のモチベーション 前提条件 実現手法 候補に上

はじめに こんにちは。calloc134 です。 前のハッカソンイベントで、UUID をプライマリキーに利用するかどうかの議論がありました。 結果的にはあまりパフォーマンス要件の高くないアプリケーションであったため、プライマリキーとして UUID を採用することにしたのですが、イベント終了後に気になったため、調査を行いました。 今回は、この調査の結果を元に、MySQL と PostgreSQL におけるインデックスの内部構造の違いと、UUID をプライマリキーにする際の問題についてまとめてみたいと思います。 インデックスの概要 インデックスとは インデックスとは、データベースのテーブルに対して、アクセスを高速に行うための指標となる構造のことです。 インデックスとは日本語で索引ですが、まさに辞書の索引のように、アクセスにおいての手助けをしてくれます。 より具体的に解説すると、データベースにお

TypeScriptではtype alias syntax（型エイリアス構文）とinterface declaration（インターフェース宣言）を使って型を定義できます。 おおよそ両者同じことができるので、どちらを使うか迷います。 両者の使い分けに関する記事は沢山あります。 これらの記事を読んで基本的にはtypeを使えば良いと思っていました。 ですが最近以下のことがあり、typeとinterfaceの使い分けがわからなくなってしまいました。 typeよりもinterfaceの方がコンパイルのパフォーマンスが良いという話を耳にした。 interfaceしか使えない特定の機能を知った。 そこでtypeとinterfaceの違いを学んで、どう使い分ければよいかを整理しました。 type, interfaceそれぞれのメリット typeのメリット interfaceで表現できないことが表現できる

【期間限定：ほぼチャプター無料公開 (公開終了期間未定)】 フロントエンドはNext.jsで、バックエンドはNestJSでやりたいとなった時に参考になるようにまとめようと思います。実務でも使えると思いますので、ぜひ活用ください。 説明は簡潔明瞭にするので、わからない部分はさらにググってみてください。本書の目標は「何となくわかるようになる」です。 なお、環境はMacにて動作確認しております。 本書で学べること ・データベースを利用したバックエンド(API)の構築方法 ・データベースにデータをCRUD(追加・読取・更新・削除)する方法 ・フロントエンドからバックエンド(API)を使う方法 ・Next.jsとNestJSのおすすめディレクトリ構成 キーワード(技術スタック) 「Next.js」「NestJS」「TypeScript」「REST API」「TypeORM」「MySQL」「Tailw

1つのIssueが大きくなると1 Pull Requestで大量の差分が発生します。 そうなるとレビュワーに負担がかかり、コンフリクトの可能性も高まり、コードレビューを効率よく進めることができません。 このINVEST原則を守ることでチームはより効果的に作業を進め、柔軟に対応して開発を進めることができます。 Git Flow Git Flowは5種類(main, hotfix, release, develop, feature)のブランチを運用するブランチ戦略です。 2010年に提唱された有名なブランチ戦略です。 オンラインサービスのように継続的デリバリーするコードを想定して作られた戦略ではないです。 main ブランチ 常にリリースできる状態を保つ hotfix, develop へ切り出す このブランチへの直pushはNG hotfix ブランチ バグ修正など緊急時に対応するためのブ

React でネタ画像ジェネレーターを作った話 Twitter でこのツイートを見たこと、ありませんか？ 今回、僕が作ったネタ画像ジェネレーターの宣伝ツイートなのですが、たまたまたくさんの人に見てもらうことができて、その結果 10 万回以上このジェネレーターで画像を作られてしまいました (これはボタンに GA4 イベントを設置して計測した値なので、もっと多いかもしれません)。この Qiita の記事では、技術的な面から「どのように作ったのか」「どんな課題があったのか」「どんな工夫をしたのか」について書きます。 どのように作ったのか 使用している技術は、以下の通りです。 Astro (ウェブサイトのフレームワーク) React (ジェネレーター部分) Canvas API (画像生成部分) Astro Astro である理由は全くないのですが (笑) ウェブサイト用フレームワークとしてトレン

https://kyoto-nanka.connpass.com/event/324686/ 補足など: https://susisu.hatenablog.com/entry/2024/09/07/213747