はじめに 前提 アメリカで働くためのビザ 業務経験 2023年のアメリカのテック業界の状況 具体的な就活のステップ ソフトウェアエンジニアのインタビューで求められることの抽象的な理解 レジュメ Job Descriptionから逆算してレジュメを作る 一枚におさめる 数字を用いてスケールとビジネスインパクトを示す なるべく隙間を埋める フォーマット添削ツールにかける レビューを受ける ネットワーキング・リファラル 応募する アメリカの就活はNumber Game 採用のトレンドを追う 時期を見計らう Linkedinで最新の求人を見つける方法 Promotedをすべて非表示にする "Most Recent"順にする 検索クエリを工夫する 設定をブックマークする 時間を決めて巡回する コーディングインタビュー対策 アルゴリズムの地図を脳内に作る 大学やCouseraでアルゴリズムの授業を取る
はじめに 今回の記事では、設計やソフトウェアアーキテクチャを学べるGitHubリポジトリを16個紹介する。 対象とする読者 設計やソフトウェアアーキテクチャに興味関心があるエンジニア GitHubをエンジニアリングの情報収集に活用したいエンジニア タイトルで気になった人 Architectural Patterns システムの基本的な構成を理解するためのパターンやテンプレートを提供している。これらのパターンを学ぶことで、システムの構造やコンポーネントの関連性、相互作用を理解できる。これが開発者にシステムをより効率的かつ効果的に設計・実装する能力をもたらす。 Design Patterns for Humans 設計パターンを人間が理解しやすい形で説明している。デザインパターンは特定の問題に対して再利用可能なソリューションを提供する。これによって、開発者はより効率的にコードを記述でき、メンテ
これはなに ども、レバテック開発部のもりたです。最近めっちゃ元気！！ 今回は『データベースについて勉強したいあなたに送る技術書17冊(+11冊1講義7link)』として、もりたがここ半年くらいでわーっと集めたデータベース周りの書籍（とか）を紹介していきます。アプリケーションって結局はデータベースみたいなところがあると思うんですが、おれは長いことデータベースをどう学んだら良いのか分かりませんでした。同じような気持ちを抱えているITエンジニアの人もいると思うので、学習ロードマップと合わせて紹介していきます。 なお具体的な対象読者は業務でなんとなくSQL書いてるけど、ウィンドウ関数とか言われると分からんな……くらいの人です。 扱う領域と扱わない領域 扱う領域としてはだいたい以下 再入門本 SQL 内部構造 論理設計 周辺知識 データベース理論 その他高度なもの モデリング、NoSQL、分散データ
大学の情報工学科に入学時に教科書として指定されたいわゆるパタへネを推します。 コンピュータの構成と設計 第5版 CPUの構造と基本は現代ではかなり複雑になりましたがこの本に書かれている基本を知っているかどうかで込み入った問題にぶち当たった場合の解像度が違います。 由緒正しいDBの読本というとオンラインで読めるRedbookとなりそうですがここは敢えて データ指向アプリケーションデザイン いわゆるイノシシ本を推します。名前からしてアプリケーションの話のように見えますし、分散システムに関する話が多いのですが最終章まで通して読むと「アプリケーションとデータベースの境界とは本来存在せず、入力されたデータを『いつ』『いかに』『安全に』加工・保存・出力するかがアプリケーションであり、その目的に対する最善手をフラットに考えるとある意味でアプリケーション全体が既にひとつのデータベースであってその仕事の一部
大学在学時に、ソフトウェアVPN（Virtual Private Network）の「SoftEther VPN」（以下、SoftEther）を開発したことで広く知られる登 大遊氏。SoftEther開発後も中国の検閲用ファイアウォール「グレートウォール」へのハッキングなどで話題を集め、現在は東日本電信電話（NTT東日本）のビジネス開発本部 特殊局員、情報処理推進機構（IPA）の産業サイバーセキュリティセンター サイバー技術研究者、筑波大学の客員教授などを務めている。 登氏が、ゲットイットが開催したWebセミナーで、日本のITエンジニアに必要な「トライ&エラー（トライアルアンドエラー）の思考法」について話した。ゲットイットは、リユースIT製品の販売やレンタル、メーカーサポートが終了した製品の保守をサポートするIT機器保守（第三者保守）など幅広い役割で、NTTグループをはじめとする多数の企業
世はまさに大サブスクリプション時代。この潮流の中で弊社スマートバンクもまた、去る2023年7月12日にB/43プラスというサブスクリプションサービスをリリースしました。 サブスクリプションといえばユーザーに提供されるコンテンツや機能といった直接的な価値に焦点が当たりがちですが、その土台にはサブスクリプションビジネスを成立させるための課金システムがあります。本記事では筆者が行った課金関連の開発を振り返ってみて重要だったポイントや工夫点を伝えてみたいと思います。 すでに世に多くのサブスクリプションサービスがある中で、課金システムの実装はコモディティ化した単純な作業に思えるかもしれません。しかしながら自社サービスにてゼロから実現するとなると、想像よりも多くの思考と意思決定が必要とされる、エンジニアリング観点ではとても奥深い題材といえます。いち開発プロジェクトのケーススタディ、あるいはいちプログラ
2024年度のサイバーエージェント新卒社内研修で「データベースの歴史」の話をしました | CyberAgent Developers Blog
こんにちは。 AI事業本部の協業リテールメディアdivでバックエンドエンジニアをしている yassun7010 といいます。 先日、 AI 事業本部の新人研修で「データアプリケーション」の講師を同じチームの 千葉 と担当しました。 今回の記事では、主に私が担当した「データベースの歴史」の章の講義資料を公開し、資料を作成する際に考えていたこと・伝えたかったことを話します。 「データベースの歴史」で説明されている内容は、AI事業本部の新卒研修で毎年取り上げられているものです。こういった研修の資料は、同じテーマであっても講師をする人の好みが反映されやすく、今年の資料も先人が作られた昨年の資料を参考にしつつ、私が好きな話題を多く取り入れたものに仕上がりました。 SlideShare でも公開しています。 今年の構成は、データベースを RDS・NoSQL・NewSQL として分け、下記のような構成を
秋のブログ週間2023の1日目です。 はじめに※この記事やこの本を読んだからと言って自身で診断を行わず、まずは整形外科などの医療機関にて診断を受けて、医師の方と治療方針を決定しましょう。また既に治療中の方は、取り組む前に一度医師や理学療法士の方と相談しましょう。 腰が痛くて仕事にならない、プログラマーこそが天職なのにこの痛みと一生付き合っていかないといけないのか…と思っている方は結構多いのではないでしょうか？ かく言う自分も腰痛持ちで、20代前半で椎間板ヘルニアと診断されました。当時はヘルニアが神経を圧迫し歩くのもつらい時期もありましたが、通院によってなんとか回復しました。 しかし完全にはよくならず、残りの人生全てを腰を気にしながら生きないといけないのか、、、と絶望しておりました。 そんなこんなで腰痛人生を送ってきたわけですが、ケリー・スターレット式 「座りすぎ」ケア完全マニュアルは自分の
Adobe Firefly で生成PdMむけの記事でこのような記事がある。 「プロダクトマネージャーこそ、戦略的に読書せよ！」── 最短で成果を出すための読書地図 (1/6)|ProductZine（プロダクトジン） これのエンジニア向けの記事がないかなと思っていたがなさそうだったので作ろうと思った。しかし客観的な視点でこれがおすすめというのは難しいので自分が参考になったと思った本を家の本棚を見ながらまずは100冊リストアップしてみた。 紹介する本は10年読まれていたり、近年発売のものであれば10年後にも読まれているだろうというものを選ぶようにしている。個別のプログラミング言語やフレームワークなどの本はバージョンアップに追随ができないことが多いので選んでいない。 入門本プリンシプル オブ プログラミングリーダブルコード定番中の定番。おそらくこの2冊はあちらこちらで紹介されている。とりあえず
サーバーレスの次はなんなんだ
はじめに この記事は、同人誌サークル「めもおきば」から不定期刊行している技術解説本「めもおきばTecReport」に書いたものを公開用に再編集したものです。 ⇒ めもおきばTecReport 2023.12 この記事のほかにも「私もSecHack365に参加したい！」や、「2023年振り返りと2024年技術予想」としてこんなキーワードを取り上げているので、気になったらぽちっとしてください！ メガクラウドと特化型クラウド／ハイパーバイザーのSoC化／ライセンスとクラウドベンダー／イベント駆動型API／LLM時代のAIペアプロ力／生活必需品としてのGPU・NPU／Passkey／ウェブアクセシビリティ／リアルイベントの再開 サーバーレスの次はなんなんだ サーバーレスと呼ばれる技術ムーブメントが盛り上がり始めて8年近くが経ちました。各クラウドベンダーのFaaS（Function-as-a-Ser
5年後には標準になっている可観測性のこと - Learning Opentelemetry の読書感想文 - じゃあ、おうちで学べる
はじめに 本稿は、オープンソースの可観測性(Observability)プロジェクトである OpenTelemetry を取り上げた書籍「Learning Opentelemetry」の読書感想文です。従来の可観測性の課題であったデータの分断を解消し、トレース、メトリクス、ログなどの様々なテレメトリデータを統合的に扱うことができる OpenTelemetry は、可観測性の分野における革命的な存在と言えます。 過去10年間で、可観測性はニッチな分野から、クラウドネイティブの世界のあらゆる部分に影響を与える数十億ドル規模の産業へと発展しました。しかし、効果的な可観測性の鍵は、高品質のテレメトリデータにあります。OpenTelemetryは、このデータを提供し、次世代の可観測性ツールと実践を開始することを目的としたプロジェクトです。 learning.oreilly.com 本書の想定読者は、
はじめに 分散システムの設計および開発において、キャッシュはパフォーマンス向上のための非常に重要な要素です。頻繁にアクセスされるデータをキャッシュすることで、アクセス速度が遅いデータベースへのアクセスを削減し、データへの迅速なアクセスを可能にします。これにより、システムの全体的な効率とパフォーマンスが向上します。 しかし、キャッシュは慎重に設計しないとむしろパフォーマンス上のデメリットになるケースが存在します。 この記事ではよく遭遇するキャッシュ設計の問題とその回避策について解説します。 Cache penetration DBに存在しない値を検索したときに、DBから返された空の結果をキャッシュしない場合に発生するシナリオです。 このシナリオではDBに存在しない値を繰り返し検索することにより、その値がキャッシュされていないため検索ごとにDBへのアクセスが必要になってしまいます。 存在しない
すぐに役に立つものはすぐに陳腐化してしまうから方法ではなく設計の本を読む - API Design Patterns の読書感想文 - じゃあ、おうちで学べる
あなたがさっきまで読んでいた技術的に役立つ記事は、10年後も使えるでしょうか？ほとんどの場合でいいえ はじめに 短期的に効果的な手法や知識は、ソフトウェア開発の分野において、急速に価値を失う傾向があります。この現象は、私たちが何を重点的に学ぶべきかを示唆しています。最も重要なのは、第一に基本的な原理・原則、そして第二に方法論です。特定の状況にのみ適用可能な知識や即座に結果を出すテクニックは、長期的には有用性を失う可能性が高いです。これは、技術や手法が時間とともに進化し、変化していくためです。 learning.oreilly.com 「API Design Patterns」は、このような考え方を体現した書籍です。しかも480 ページもあります。本書は単なる手法の列挙ではなく、Web APIデザインの根幹をなす原則と哲学を探求しています。著者のJJ Geewax氏は、APIを「コンピュータ
3. Copyright©2016 NTT Corp. All Rights Reserved. 3 • よくわかってない人でもCloudera Managerをダウンロードして1時間後 には巨大なHadoopクラスタを立ち上げてYARN, HDFS, Spark, HBase などで遊ぶ事ができる。 • 世の中では分散システムが必要以上に喧伝されている • 「コンピュータ1台よりも2台の方が高速」という直感に対して反論するの は意外と難しい • あなたのそのシステム、本当に分散システムじゃないとダメ？ 分散自体を目的にしない事 4. Copyright©2016 NTT Corp. All Rights Reserved. 4 L1 キャッシュ参照 分岐予測ミス L2 キャッシュ参照 Mutexのlock/unlock メモリ参照 1KBをZIP圧縮 1Gbpsで2KB送る メモリから1
【バックエンド】駆け出しエンジニアが目指すジュニアレベルのエンジニアとは【2024年版】 - Qiita
はじめに こんにちは。 普段はフロントエンドの開発をメインでやっておりますmamiと申します。 最近バックエンドの方の勉強や、少しずつですがDB設計やAPI作成などの業務もやらせてもらえるようになったので、自分のエンジニアとしてのレベル感や、この先目指すべき道筋を明確にしたいな〜という思いでこの記事を書いております。 これは自分のための記事であると同時に、同じように駆け出し中のエンジニアさんや、ミドル層を目指す手前のエンジニアさんにも刺さる内容になっているかと思います。 今、自分がどのようにキャリアアップしていくべきなのか、どのような道筋でスキルを磨いていけばいいのか。そんなふうに悩んでいる方は是非読んでみてください。 ※内容はバックエンドエンジニアが対象になりますが、フロントエンドの方もなにか通じるものがある…かもしれません。 ちなみにですがフロントエンドの方の記事は下記で執筆しています
はじめに 有用な知識の特性 Google SRE リソース Site Reliability Engineering: How Google Runs Production Systems The Site Reliability Workbook: Practical Ways to Implement SRE Building Secure and Reliable Systems: Best Practices for Designing, Implementing, and Maintaining Systems SLO Adoption and Usage in SRE Creating a Production Launch Plan Training Site Reliability Engineers: What Your Organization Needs to Cre
インフラマネージャー厳選！10年使える知識が身につくおすすめ書籍10選 - RAKUS Developers Blog | ラクス エンジニアブログ
ラクスでは多くのSaaSプロダクトを開発・運用しており、オンプレミスまたはクラウドを適切に選択してインフラ基盤を構築しています。 そのインフラを担うのが、ラクスのインフラ開発部です。 今回はインフラ開発部のマネージャーが厳選した、インフラエンジニアにおすすめの書籍10選をご紹介します。 それぞれの書籍に推薦コメントを記載していますので、是非ご参考になさってください。 選定基準は以下の通りで、今後インフラを深く理解し実力をつけていきたい方にも最適です。是非ご覧ください。 「すぐに役に立つがすぐに廃れる知識ではなく、10年以上使える書籍」 「分かりやすい本ではなく、難解ではあるがきちんと原理・原則を学べる書籍」 目次 目次 Operating Systemを理解しよう 詳解 Linuxカーネル 第3版 DNS & BIND 第5版 トラブルシューティングを理解しよう 詳解 システム・パフォーマ
【ソフトウェア設計】モジュールをどう分割するのか？
はじめに 前々回や、前回に引き続き、ソフトウェア設計の指針に関する話をしたいと思います。 関数やクラス、そしてサービスなどシステムの塊の単位をモジュールと呼び、モジュールを作る事で、認知負荷を下げ複雑性と戦うという話をしてきました。では、モジュールは「いつ」分割するのが良いでしょうか？ また、他にも共通モジュールを不用意に作ってしまって苦労した人も多いのでは無いでしょうか？ 今回はそのあたりの話をしていきます。 TL;DR 以下があればモジュール設計を見直す 単純な要件/普段の利用に対して、タイプ量や約束事が多い 共通モジュールが「使われ方」に依存する モジュールの役割を一言で説明できない コード管理や性能/データ整合性など利用に際してのペナルティが高い 分割 is NOT 正義 - FizzBuzz Enterprise Edition 複雑性を排除するためにモジュール分割をすることは重
修士課程を退学した15年前に、僕は全く実現可能性を考えずに”30歳までにアメリカの大学院に留学”という目標を立てました。 もう一度大学院に行きたい、行くなら世界トップのアメリカがいいだろう、そんな程度の認識でした。 ただ、これはどちらかといえば無理やりひねり出した30歳まで生きる理由であって、そこまで強い意志があったわけではありません。 しかし、おかげで何とか30歳を超え40歳目前まで生き延びることはでき、気が付けばアメリカではなくカナダで永住権を取って暮らしています。 大学院留学は引き続き他のハードルが高くて達成できる気はしませんが、15年前に目標を立てた時点では認識できていなかった 「海外に移住する」という難儀を10年ほどかけて乗り越えることはできました。 けれど、そういえば事の顛末を一つにまとめたことが無かったなと気づいたので、僕のキャリア10年＋αを振り返って記事にしてみました。
OpsBR Software Technology Inc. 代表 岩永 亮介 ソフトウェア業界で15年以上、物理的なデータセンター運用から、世界最大規模の分散システムの運用、多数の業界のお客様のシステム設計支援、フロントエンドからバックエンド、データベース管理者、DevOps やテスト設計・実装、アーキテクチャレビュー、などを経験。特に、運用に関する改善や設計は得意で、OpsBR Software Technology Inc. を立ち上げた。カナダのバンクーバー在住。経歴は、Autify で Staff Software Engineer、Sr. Technical Support Engineer、Amazon で Sr. Systems Development Engineer、Solutions Architect など。 ソフトウェアエンジニアとして海外、特に北米を目指すのであ
この記事では、2023年9月29日に開催されたSRE NEXT 2023 IN TOKYOでの講演の概要に加えて、講演では触れられなかった部分の補足と、発表を終えての後記、最後にSRE NEXT全体の感想を書きました。 SRE NEXT 2020の基調講演に招いていただいたところから始まり、昨年のSRE NEXT 2022の公募セッションでも発表し、今回で3回目の発表になりました。今回の講演は、SRE NEXTの「NEXT」と価値観の一つである「Diversity」を踏まえて、自身のエンジニアと研究者の両方の経験を活かして、SREを深く実践する上で、技術論文を探して読むアプローチを提示するものです。昨今の国内のSREコミュニティでは組織的実践に主な関心が移っている状況と対比させて、コンピュータサイエンスに基づく技術的挑戦の可能性を示唆する意欲的な講演を目指したつもりです。 この講演での主要
【2024年】ITエンジニア本大賞まとめ
アジャイルプラクティスガイドブック チームで成果を出すための開発技術の実践知 チーム・組織にプラクティスを導入し、根付かせるために！ 116の手法を一冊にまとめた“実践”の手引き チームでのアジャイル開発には、開発技術やツールなどの「技術プラクティス」の活用が重要です。 プラクティスはそれぞれの目的や役割を意識することで効果を発揮します。しかし、目まぐるしく状況が変化する開発では、当初の目的を忘れて、プラクティスに取り組むこと自体が目的化してしまうチームも少なくありません。 本書は、チーム・組織でアジャイル開発に取り組んできた著者が、プラクティスの効果的な選択・活用のしかたについて、自らの実践経験に基づいてまとめたガイドブックです。 架空の開発現場を舞台にしたマンガとともに、チーム開発の様々なシーンで役立てられるプラクティスを、幅広くかつわかりやすく解説しています。開発現場に備えておけば、
Amazon Web Services ブログ サーバーレスマイクロサービスを構築するための設計アプローチの比較 AWS Lambda でワークロードを設計すると、コードレベルでもインフラレベルでも表現できるモジュール性のために、開発者に疑問が生じます。また、コードを実行するためにサーバーレスを使用するには、基盤となる機能コンポーネントからビジネスロジックを抽出するためのさらなる検討が必要です。この意図的な関心の分離により、堅牢なモジュール性が保証され、進化的なアーキテクチャへの道が開かれます。 この投稿は同期ワークロードに焦点を当てていますが、他のワークロードのタイプでも同様の考慮が当てはまります。API の境界を特定し、コンシューマと API について擦り合わせた後、その境界と関連するアーキテクチャを構成します。 Lambda 関数を使用して API を構成する最も一般的な 2 つの方
Home Home Guides Data types Tools Curated recipes FAQ Contributors オブザーバビリティとは¶ 概要¶ オブザーバビリティとは、観測対象のシステムからのシグナルに基づいて、継続的にアクション可能な洞察を生成および発見する機能です。つまり、オブザーバビリティを使用すると、システムの状態を外部出力から理解し、(修正)アクションを実行できます。 対処する問題¶ コンピュータシステムは、CPU 時間、メモリ、ディスク領域などの低レベルのシグナルや、API 応答時間、エラー、トランザクション毎秒などの高レベルかつビジネス上のシグナルを観測することで測定されます。 システムの可観測性は、その運用と開発コストに大きな影響を与えます。観測可能なシステムは、操作者に意味のある実行可能なデータを提供し、(インシデント応答の高速化、開発者生産性の向
公開日 2024/06/19更新日 2024/07/25身近なBtoCサービスを支えるアーキテクチャ大解剖 技術選定のポイントと今後の展望 多くのIT企業では、ユーザーに対してより高品質で安定した体験を提供するために、システムアーキテクチャを進化させ続けています。 本特集では、日常生活の中で多くのユーザーに利用されているサービスのアーキテクチャ設計に携わるエンジニアの方々から、技術選定の背景や意図、そして現在のアーキテクチャの課題から未来への展望まで、詳しく伺いました。この記事を通じて、各企業のエンジニアたちがどのように技術的な課題を克服し、システムの柔軟性と効率を高めているのか、知見を得ていただければ幸いです。 ※ご紹介は企業名のアルファベット順となっております アソビュー株式会社 アソビュー株式会社では「遊び」という領域に対し、マーケットプレイス型EC「アソビュー！」やD2C型SaaS
時雨堂創業 12 年目
2013 年 3 月 8 日に時雨堂を創業し、2024 年 3 月 8 日で時雨堂創業 11 年、そして 12 年目にはいりました。あっという間です。 起業のきっかけは、ある経営者に「貴方がどんなに一生懸命に製品を作ってもそれは会社のものでしかないので、自分の会社を持って自分の製品を作って、売った方がいい」といわれた事なんですが、それから 11 年立ちました。 起業したときから状況も大きく変わりました。自社製品の売り上げだけで会社が回っています。今後の時雨堂について雑に書いて行きます。 少人数でスケールする製品を作り続ける時雨堂はパッケージソフトウェアのサブスクリプションで稼いでいる会社です。営業もいないため、買いたいといってくれる企業に売るだけです。 社員が社内にあるライセンス発行サーバーに Tailscale でリモートで繋いでライセンス (JSON ファイル) を発行し、ライセンスフ
マイクロサービスからモジュラーモノリスを経て新マイクロサービスへ - Techtouch Developers Blog
バックエンドエンジニア兼万年ダイエッターの taisa です。テックタッチは、以前マイクロサービスからモジュラーモノリスを経て新マイクロサービスへの切り直しを実施しました。本記事では、マイクロサービス・モノリスについて簡単に触れながらテックタッチがどういったプロセスでマイクロサービスの切り直しを実施したかを紹介します。 はじめに マイクロサービスとモノリス マイクロサービスとは マイクロサービスの利点 モノリスとは 単一プロセスモノリス モジュラーモノリス 分散モノリス テックタッチの場合 初期の頃の構成イメージ マイクロサービス切り直し前 特徴 モジュラーモノリス化 サービスの移行 別ドメイン境界でサービス切り直し イベントストーミング マイクロサービス切り直し後 DB 統合へ続く まとめ 参考 はじめに テックタッチは初期の頃からマイクロサービスアーキテクチャを採用していますが、一部の
本連載では、業界の第一線で活躍する著名エンジニアたちが、それぞれの視点で選んだ書籍について語ります。ただのレビューに留まらず、エンジニアリングの深層に迫る洞察や、実際の現場で役立つ知見をシェア！初心者からベテランまで、新たな発見や学びが得られる、エンジニア必読の「読書感想文」です。 著名エンジニアが、独自の視点で「おすすめ書籍」の紹介を行う本連載。 今回は、米マイクロソフトのエンジニア・牛尾 剛さんによる『テスト駆動開発』（オーム社）の読書感想文を紹介する。 発売日：2017年10月14日 著者：Kent Beck 訳者：和田 卓人 定価：3,080円 （本体2,800円＋税） ISBN：978-4-274-21788-3 サイズ：A5 ページ数：344ページ 書籍概要：テスト駆動開発とは単にテスト自動化を行うことではなく、ユニットテストとリファクタリングを両輪とした小さいサイクルを回すこ
Twitterでこんな記事を見かけたので。 zenn.dev ジェネリクスの件もそうですが、Goの言語設計は現実主義なのになにか特別なポリシーによるものだと宗教化されてしまって、ファンには勝手に崇拝されてアンチにはディスられがちだなーと感じます。 Goのエラー処理を改善する実験プロジェクトxerrorsがGo本体のerrorsにマージされた時、 errors.New() はスタックトレースを取得していました。しかしGo 1.13がリリースされる前に削除されました。 削除された理由の1つは、今までの errors.New() のパフォーマンスに依存していたコードの速度が低下しアロケーションが増えることです。 github.com しかし、これが理由だと今まで思ってたのですが、実際にはもう1つより重要な理由がありました。エラーのフォーマットです。エラーに複数のフォーマットを持たせようという提案
10年以上にわたりAWSのElastic Block Store(EBS)の開発に関わってきたマーク・オルソン氏が、EBSが共有ドライブに依存する単純なブロックストレージサービスから、毎日140兆回以上の操作を実行する大規模なネットワークストレージシステムへ発展するまでを振り返るブログ記事を投稿しました。 Continuous reinvention: A brief history of block storage at AWS | All Things Distributed https://www.allthingsdistributed.com/2024/08/continuous-reinvention-a-brief-history-of-block-storage-at-aws.html EC2がベータ版で使用可能になってから2年後の2008年にEBSはサービスを開始しました
アジャイルプラクティスガイドブック チームで成果を出すための開発技術の実践知 チーム・組織にプラクティスを導入し、根付かせるために！ 116の手法を一冊にまとめた“実践”の手引き チームでのアジャイル開発には、開発技術やツールなどの「技術プラクティス」の活用が重要です。 プラクティスはそれぞれの目的や役割を意識することで効果を発揮します。しかし、目まぐるしく状況が変化する開発では、当初の目的を忘れて、プラクティスに取り組むこと自体が目的化してしまうチームも少なくありません。 本書は、チーム・組織でアジャイル開発に取り組んできた著者が、プラクティスの効果的な選択・活用のしかたについて、自らの実践経験に基づいてまとめたガイドブックです。 架空の開発現場を舞台にしたマンガとともに、チーム開発の様々なシーンで役立てられるプラクティスを、幅広くかつわかりやすく解説しています。開発現場に備えておけば、
この記事は 食べログアドベントカレンダー2023 の23日目の記事です🎅🎄 こんにちは。食べログシステム本部 技術部 仕入チームの@shohei-yです。 今回は、新規事業の「食べログ仕入」プロダクト開発において所謂「設計書」を書かない設計に挑戦して開発効率を向上させた話を書きます。 （結局「書くの？書かないの？どっちなんだい！」と感じた人は、ぜひ読み進めてください。） 所属している仕入チームについてはこちらの記事をご覧ください。 目次 なぜ設計書を書かない設計に挑戦したのか 設計書を書かないチーム 設計書を書かないことによる問題 1. チーム協力の課題 2. ソースコードの複雑化 3. チーム変動に関わる問題 設計工程導入のきっかけ 設計書を書かない挑戦の背景 設計書を書かない設計 フロントエンド・バックエンドのインターフェースの明確化 ソースコードのスリム化対策 設計のレビュー方法
AWS Lambdaの高速なコンテナロードの仕組み | CyberAgent Developers Blog
CTO統括室の黒崎(@kuro_m88)です。今回はAWS Lambdaの高速なコンテナロードの仕組みについて紹介します。 AWS Lambdaはサーバレスなマネージドサービスであり、難しいことを知らなくてもユーザ(私たち)は簡単にアプリケーションをホストでき、簡単にスケールします。 ユーザから見るとシンプルですが、その裏側では様々な仕組みがあったり最適化が行われたりしています。 マネージドサービスの裏側を必ずしも知る必要はありませんが、仕組みを知っておくとより使いこなせるはずですし、自信を持って技術選定ができるはずです。(そして何より裏側を知ることは楽しい！🤗) 本記事はUSENIX ATC 2023で発表された論文「On-demand Container Loading in AWS Lambda」の内容に基づいて、読んでいて面白かったポイントをまとめています。 On-demand
祝🎉 POSIX.1-2024 (Issue 8) 改定！16年ぶりの大幅改定でシェルスクリプトはどう新しくなるのか？ - Qiita
FreeBSD では 2024-05-31 に 200112 から 200809 への変更がようやく行われました（一度間違えて 200808 と書いてしまっていますが）。 https://cgit.freebsd.org/src/commit/?id=2e30926a68 https://cgit.freebsd.org/src/commit/?id=6e0278408e macOS は FreeBSD のユーザーランドのコマンドを使用しているため、そのせいで 200112 のままだった可能性も考えられますが、シェルやカーネルは FreeBSD のものではないため、FreeBSD が変更になったからと言って macOS が更新されるとは限らないでしょう。Solaris 10 と 11 ではディレクトリごとに準拠バージョンが異なるバイナリが配置されており以下のようになります。Solaris
はじめに エンジニアとして就職する前に読んだ「なれる!SE 2週間でわかる?SE入門」の内容があまりにも厳しく、業界に就職するのが怖くなったことを覚えています。本の中に登場する中学生の少女にしか見えない凄腕のSE、室見立華さんのような人物は現実には存在しないでしょうが、実際の業界には彼女のような凄腕エンジニアや年齢不相応な技術力を持つ人間も確かに存在します。 なれる！SE ２週間でわかる？ＳＥ入門 (電撃文庫) 作者:夏海 公司,IxyKADOKAWAAmazon SREの探求『Becoming SRE』の内容紹介 私は「なれる!SE」が好きすぎるあまり、「なれる!SRE」というタイトルのクソみたいな文章を吐き出したこともありましたが、そのクオリティがあまりにも低かったため、外には公開せずに留めておきました。そんな中、SREの探求の原著者であるDavid Blank-Edelman(ott
データエンジニアリングの基礎
データエンジニアリングとは、組織内外で日々生成されるデータを蓄積し分析するためのデータシステムを構築し維持管理することであり、急速に注目を集めている分野です。近年ではデータエンジニアリングを支えるツールやクラウドサービスが成熟し、組織へのデータ利活用の導入は容易になりましたが、明確な指針のないままデータシステムの構築を進めると費用と時間を無駄に費やすことになります。本書は「データエンジニアリングライフサイクル」を軸にデータシステムの要件を整理することで、組織の「データ成熟度」に応じたデータシステム構築の指針を与えます。またデータエンジニアの立ち位置を明確にし、組織内でデータエンジニアが果たすべき役割を示します。 まえがき Ⅰ部 データエンジニアリングの基礎と構成要素 1章 データエンジニアリング概説 1.1 データエンジニアリングとは何か 1.1.1 データエンジニアリングの定義 1.1.
Platform Engineering on Kubernetes を読んでCloud Native の現在地を理解する - じゃあ、おうちで学べる
はじめに 近年、Kubernetesの採用が進む中、複数のチームが関わり、複数のクラウドプロバイダーへのデプロイを行い、異なるスタックを扱う組織では、その導入の複雑さが新たな問題となっています。本書 『Platform Engineering on Kubernetes』は、Kubernetes に登場しつつあるベストプラクティスとオープンソースツールを活用し、これらのクラウドネイティブの問題を技術的に組織的にどのように解決するかを示してくれます。 learning.oreilly.com 本書では、Kubernetes上に優れたプラットフォームを構築するための要素を明確に定義し、組織の要件に合わせて必要なツールを体系的に紹介しており、実際の例とコードを交えながら各ステップをわかりやすく説明することで、最終的にはクラウドネイティブなソフトウェアを効率的に提供するための完全なプラットフォーム
はじめに 本書『Observability Engineering』は、複雑化の一途をたどる現代のソフトウェアシステムに立ち向かうための、強力な武器となる一冊であり本稿はその読書感想文です。Observability Engineering を今から知りたい方はもちろん、Observability Engineering の基礎を改めて学びたい方もぜひお読みください。この記事もかなりの長さになるので普通に書籍を読んだほうがいいかもです learning.oreilly.com 「Observability:可観測性」という言葉は、近年ソフトウェアエンジニアリングの世界で大きな注目を集めています。しかし、その概念の本質を理解し、実践に移すことは容易ではありません。 本書は、そのオブザーバビリティについて、その基本的な考え方から、具体的な実装方法、そして組織への適用まで、幅広くかつ深く解説して
ブラウザベースのデザインツール「Figma」のデータベース(DB)は2020年以来100倍に拡大しました。当初は単一のPostgreSQLで構築されていたDBをどのようにして分散システムへと移行したのかについて、公式ブログで詳しく説明されています。 How Figma's Databases Team Lived to Tell the Scale | Figma Blog https://www.figma.com/ja-jp/blog/how-figmas-databases-team-lived-to-tell-the-scale/ Figmaではまず、「Figmaファイル」や「組織」などテーブルごとにDBを分割する「垂直分割」を行いました。2022年までに10個のパーティションに分割し、それぞれのパーティションを監視することでスケーリングの優先順位を付けたとのこと。 Figmaの利
クラウド技術者の不足は企業の重要課題の一つとなっており、モダナイゼーションが進まない要因の一つでもある。AWSが提供を開始する新しいトレーニングプログラムは人手不足を解消する一手となるだろうか。 IT人材不足の中でもクラウド技術者の不足は特に深刻で、クラウド大手Amazon Web Services（AWS）によると約500万人分のポストが空いているという。こうした中、同社が新しいトレーニングプログラムの提供を開始した。これまでの同社のプログラムと異なり、ITの分野における勤務経験のない初心者向けであることが特徴だ。 初心者が受講可能 人材不足解決の一手となるか AWSは最短1年で初級レベルのクラウド技術者になるための12コースのクラウドスキルトレーニングプログラム「AWS Cloud Institute」を公開したと2023年10月10日（現地時間）に発表した（注1）。 同プログラムのカ
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
アメリカでソフトウェアエンジニアの職を探した - pco2699’s blog
設計・ソフトウェアアーキテクチャを学べるGitHubリポジトリ 16選
データベースを勉強したいあなたに送る技術書17冊(+11冊1講義7link)
コンピュータサイエンスで1冊ずつ本を上げるとしたら何になりますか？就職前にバイブル的な本を勉強したいと思いました。 -コンピュータアーキテクチャ -データベース -os -アルゴリズムとデータ構造 -セキュリティ -ネットワーク -プログラミング -仮想化技術 | mond
SoftEtherの登 大遊氏が語る、「日本のITエンジニアに迫る危機」とは
サブスクリプション課金システム開発ケーススタディ - inSmartBank
腰痛と闘うプログラマー | フューチャー技術ブログ
ソフトウェアエンジニアにおすすめしたい本を100冊選んでみた | gennei's blog
開発者が知るべきキャッシュ設計でよく遭遇する問題
分散システムについて語らせてくれ
このSRE本がすごい！2024年版 - じゃあ、おうちで学べる
10年かけてカナダでソフトウェアエンジニアになるまでの道のり - As a Futurist...
最初から完ぺきを求める必要はない。10年かけて、英語で生活できるようになった話 | レバテックラボ（レバテックLAB）
エンジニアのためのSRE論文への招待 - SRE NEXT 2023 - ゆううきブログ
サーバーレスマイクロサービスを構築するための設計アプローチの比較 | Amazon Web Services
AWS Observability Best Practices
身近なBtoCサービスを支えるアーキテクチャ大解剖 技術選定のポイントと今後の展望 - Findy Tools
「テスト駆動開発」は時を超える技術。凡人が天才と肩を並べるための秘密兵器【米マイクロソフト・牛尾 剛】 - エンジニアtype | 転職type
Goのerrorがスタックトレースを含まない理由 - methaneのブログ
AWSのブロックストレージがどのように進化してきたのかを中の人が語る
【2024年】ITエンジニア本大賞まとめ - Qiita
設計書を書かない設計で開発効率を向上させた話 - Tabelog Tech Blog
なれる!SRE - Becoming SREで学んだこと - じゃあ、おうちで学べる
もう一度読むObservability Engineering - じゃあ、おうちで学べる
Figmaは多大なアクセスをさばくためにどのようにデータベースのスケーリングを行ったのか？
AWSが初心者向けプログラムを提供開始 「最短1年」でクラウド技術者を育成