ブラウザの仕組み | Articles | web.dev
序文 WebKit と Gecko の内部オペレーションに関するこの包括的な入門情報は、イスラエルのデベロッパー Tali Garsiel 氏による多くの研究の成果です。数年にわたり、ブラウザ内部に関するすべての公開データを確認し、ウェブブラウザのソースコードを読むことに多くの時間を費やしました。彼女は次のように書いています。 ウェブ デベロッパーは、ブラウザ操作の内部構造を学ぶことで、より的確な意思決定を行い、開発のベスト プラクティスの背後にある理由を知ることができます。これはかなり長いドキュメントですが、時間をかけてじっくり読むことをおすすめします。やったら嬉しいよ。 Chrome デベロッパー リレーションズ、Paul Irish はじめに ウェブブラウザは、最も広く使用されているソフトウェアです。この入門編では その仕組みを解説しますアドレスバーに「google.com」と入力し
本気でプロダクトに向き合うCTOになるために必要な事 (技育祭2024春)
技育祭2024春のスライドです。 価値のあるプロダクトをつくるエンジニアになるための話と、自分がどういうキャリアでそうなっていったかを話します。
More powerful Go execution traces - The Go Programming Language
The Go Blog More powerful Go execution traces Michael Knyszek 14 March 2024 The runtime/trace package contains a powerful tool for understanding and troubleshooting Go programs. The functionality within allows one to produce a trace of each goroutine’s execution over some time period. With the go tool trace command (or the excellent open source gotraceui tool), one may then visualize and explore t
個人開発を7年以上続けて分かった技術選択のコツ
技術革新に適応しようとするイヌさんInkdropというMarkdownノートアプリを作り続けて7年になる。 お陰さまでその売上でずっと生活できている。 これまで個人開発でどう継続していくかについて「ユーザの退会理由をあれこれ考えない」とか「アプリの売上目標を立てるのをやめました」とか、ビジネス面あるいはメンタル面からいろいろ書いてきた。 今回は、技術面にフォーカスして、どう継続して開発していくかについてシェアしたい。 TL;DR最初はとにかく最速でリリースする事を最優先する迷ったら「ときめく方」を選べ程よいところで切り上げて開発を進める使っているモジュールがdeprecatedされるなんてザラだと覚悟する古いから悪いとは限らないシンプルにしていく老舗から継続の秘訣を学ぶ運ゲー要素は排除しきれない最初はとにかく最速でリリースする事を目標に技術選定する開発計画とビジネス計画は切っても切り離せな
開発プロセスをインクリメンタルに改善する - 一休.com Developers Blog
一休.comレストランのエンジニアのkymmtです。 2023年度の下半期、一休.comレストランの開発チームでは開発プロセス改善に取り組みました。改善は小さい単位で徐々に進め、バックログの作りかたやカンバンの運用方法を改善することで、フロー効率の向上、開発ペースの把握、チーム内外からの進捗の見える化ができるようになりました。 この記事では、このようなインクリメンタルな開発プロセス改善の取り組みについて紹介します。 従来の開発プロセス 主に2023年度前半の開発プロセスは次のような形でした1。 プロダクトのリリースに必要なタスクが長いバックログとして存在し、ひたすらタスクを消化 その状況に課題を感じ、区切りを入れるために2週間のスプリントを導入 この時点では、スプリントは2週間ごとに状況を確認するためのもので、目標に対するふりかえりや、次のスプリントの計画を作るためのものとしては活用してい
横浜中華街デートで1日過ごせ｜まりにゃ
中華街について雑に作ったネタがバズって地元の友達からも回覧されてきた。横浜出身の相互からもリア友からお前のポストがLINEで送られてきてビビったなどの苦情が寄せられている。 せっかくなのでこのポストについての解説と、じゃあ実際中華街で丸一日デートするとしたらどうしたらいいのかについて書いていく。 結論から言うと中華街は単体でデートで1日過ごしても十分楽しめる魅力的な街である。 お前を中華街に連れて行く前に 言っておきたいことがある かなり厳しい話をするが 俺の本音を聞いてくれ 小籠包や肉まん食べ歩きはやめろ 食べ放題の店に入るな 甘栗買うな 世界チャンピオンの店に入るな よく分からないフルーツ飴を食うな 一番リピーターが多い占い屋に入るな — まりにゃ🌰🐿 (@mayimbesasson) February 28, 2024 1.「中華街でしてはいけないこと」の解説別にしてもいいのだけ
Software Designドメイン駆動設計に参加 - Qiita
前書き 業後に以下のDDDイベントに参加してきた。 その議事録とアウトプットとしてここに残す。 画像の上２つが自分が書いたものである。 ドメイン駆動設計概要とユビキタス言語 コンテキストマップとコアドメイン 全体像を俯瞰したコンテキストマップ→その上でのどこにモデリングコストかけるか策定。コアドメインの時間経過に伴う変化(動き)、境界の位置含めて。詳細での検証の上で演繹的に前提となるマクロな境界の位置を修正。 それに対して参加者の方から、 ①コンテキストマップからのコアドメインの定義という順番(トップダウン寄り) ②コアドメイン先に定義してからのコンテキストマップ作成という順番(ボトムアップ寄り) どちらなのか？ という良い質問があった。 どっちかというとコアドメインを最初に特定して、それを支える業務サービスとして他のドメインがあるため、わりとボトムアップ式にコンテキストマップ作成という話
読書メモにはObsidianが最高という話 - Qiita
 ## 著者 [[{{author}}]] ## 発行日 {{publishDate}} ## 読了日 ## 3選 ## メモ [[読書記録]] 自分は使ってないですが、{{category}}なんかも取得できます。 ひたすらメモる あとは読みながら気になったことをメモしていきます。 ちなみにこのメモは本を読みながらではなく、本を閉じて行うことをお勧めします。 なぜなら、本の内容を思い出すという行為で脳に負荷をかけることで、記憶への定着がいくらか期待できるからです。 『科学的根拠に基づく最高の勉強法』に記載されている「アクティブリコール」の簡易版といった感じです。気になった方は是非この本を読んでみてください。為になる情報がたくさん載っていてお勧めです。 科学的根拠に基づく最高の勉強法 読了後に3選を決める 本を読み終えたら、メモした内容の
Feature Flag Deep Dive
チーム勉強会で Feature Flag とトランクベース開発の話をしました （追加訂正と書かれているスライドは、勉強会後議論した結果を反映したものです）
RustでWeb APIを作る際のエラーハンドリング - CADDi Tech Blog
TL;DR エラーハンドリングを行う目的 エラーハンドリングが適切に行われているとどう嬉しいか 1. エラーの発生原因が分かる 2. レスポンスステータスを型安全に出し分けることが可能になる どうエラーハンドリングを行うのか 実装方法 エラー型の定義で気を付けるべきポイント なぜanyhowを利用しないのか エラーハンドリングを行う上で持っている課題感 Drawer Growth グループ バックエンドエンジニアの中野です。今回は、私が所属するチームで gRPC API を開発する際に実践している Rust でのエラーハンドリングについて紹介していきます。 TL;DR エラーの発生原因がわかるようにエラー型を定義することが大切。 anyhow は使わずに自前のエラー型を定義して利用する。 エラーハンドリングを行う目的 そもそもなぜエラーハンドリングを行う必要があるのでしょうか。私が所属する
マイクロサービスアーキテクチャへのIntegration Test導入のすゝめ
こんにちは、バックエンドを中心に開発をしています、野島といいます。 ソフトウェアテスト自動化カンファレンス2023に「マイクロサービスアーキテクチャへのIntegration Test導入のすゝめ」というお題で登壇しました。 そちらで発表した内容を記事にしつつ、当日話しきれなかった内容についても書きます。 発表は下記の内容を話しました。 Integration Testの導入を決意した背景にあった課題 Integration Testの導入/運用での工夫 Integration Testを導入して得られたメリット まとめ 本記事では、Integration Testを以下の定義で扱います。 マイクロサービスが依存する外部コンポーネントをモック化せずに行うAPIテスト。 外部コンポーネントとは、具体的にはデータストア、外部サービス、テスト対象が依存するマイクロサービス、などを指します。 テス
【翻訳】テスト駆動開発の定義 - t-wadaのブログ
このブログエントリでは、テスト駆動開発（TDD: Test-Driven Development）の考案者Kent BeckがTDDの定義を改めて明確化した文章を、許可を得たうえで翻訳し、訳者の考察を沿えています。 きっかけ 2023年の年末、テスト駆動開発（TDD: Test-Driven Development）の考案者Kent Beckは、substackにTDDに関するポストを連投して論戦を繰り広げていました。TDDはその誕生から20年以上が経ち、その間に「意味の希薄化」が発生して議論が噛み合わなくなっていました。意味の希薄化（Semantic Diffusion）とは、新しく作り出された用語が広まる際に本来の意味や定義が弱まって伝わる現象です。 私（和田）はTDDと関わりの深いキャリアを歩んできました。Kent Beckの著書『テスト駆動開発』の翻訳者であることもあり、TDDの正
僕は自分が思っていたほどは頭がよくなかった - しのごの録
Redditで話題になっていたポストを訳してみた。 僕は自分が思っていたほどは頭がよくなかったという高校生の独白にたいしてつけられたこのちょっと長めの返信がとても的確で示唆に富んでおり、多くの人のこころをつかんでいました。私自身、勇気づけられるというか身につまされるところがあり、忘れないために翻訳をしてみました。 まずは高校生の独白から。 僕は自分が思っていたほどは頭がよくなかった 僕はいま高校の最終学年で、次の６月に卒業する予定です。高校の成績は、いままでずっとAを取りつづけていましたが、去年始めてBをとってしまいました。もしそのBがなければ、卒業生総代に選ばれていたでしょう。 総代にふさわしいのは自分だ、つまりクラスで本当に一番頭がいいのは自分だと思いたいです。でもこの一年で、僕にそれほどの知性はないし、僕より頭のいい人はたくさんいるんだということを思い知らされました。 また僕は、自分
長く活躍できるエンジニアになるためには？ 技術者として大切にしたいこと
フロントエンドのパラダイムを参考にバックエンド開発を再考する / TypeScript による GraphQL バックエンド開発
はじめてのインタープリター
インタープリターを書いたことがない方向けに、四則演算といった簡単なものから始め、少しずつ機能を足しながら言語を拡張していくような本です。
Terraform でディレクトリ構成を意識しながら Azure OpenAI Service の閉域環境を作る
本記事は、Microsoft Azure Tech Advent Calendar 2023[1] の 21 日目の記事です。 はじめに 最近 IaC にハマっており、Bicep では飽き足らず Terraform に手を出し始めた zukako です。今回は、Microsoft Azure Tech Advent Calender 2023 にも関わらず Terraform を触る系の話です。構築する対象としては、Azure OpenAI Service(AOAI) の閉域化環境としました。ネットをいろいろと検索してみたのですが、まだ Terraform x Azure OpenAI Service の記事が少なそうに見えたので、ちょうどいい規模感かな～と思った次第です。閉域化といっても、独自のデータで Chat モデルを利用する、所謂「Add Your Data」の部分は含みませんので
NIST サイバーセキュリティフレームワーク 2.0を解説｜約10年ぶりの大幅改訂、押さえるべき要点とは？
HOME NRIセキュア ブログ NIST サイバーセキュリティフレームワーク 2.0を解説｜約10年ぶりの大幅改訂、押さえるべき要点とは？ 2024年2月26日、NIST（米国立標準技術研究所）は、「NIST サイバーセキュリティフレームワーク（NIST Cybersecurity Framework：NIST CSF）」のバージョン2.0を正式に公開した。2014年4月に初版であるNIST CSF 1.0が公表されて以来、約10年ぶりの大幅改訂である。 本記事では、NIST CSF 2.0における主な改訂のポイントと、特にインパクトの大きい6つ目の新機能「GV（統治）」について解説する。 ▶「経営層が納得するセキュリティ報告」を読む はじめに 2020年代に入り、新たな生活様式の変化に起因する脅威の発生、世界各国での深刻かつ大規模なサイバー攻撃の急増、生成AIなど新技術の普及に伴うリス
Rustでリレーショナルデータベースを自作したときの成果と反省と学び - Yoshisaurのメモ
はじめに この記事では、個人プロジェクトとしてRust言語でリレーショナルデータベースを開発した経験（もう五ヶ月も前...）について、その成果と反省、得た学びを共有します。 DBMSを自作した理由 自分がDBMSの自作に着手したのは、『Designing Data-Intensive Applications』という本の内容を深く理解するためでした。 この本は、データシステムの設計と運用において最も大切な「信頼性」、「拡張性」、「保守性」を保証する方法論を、豊富な文献を引用しつつ、理論と実践の橋渡しを巧みに行いながら、丁寧に説明している名著です。読んだことがない人は速攻購入してくだい。本当にいい本です。 この本は、データベースの内部構造に関する話も豊富に含まれていたので、「データベース自作してみようか...」という気持ちになりました。 Rustを採用した理由 データベースの実装のついでに、
SaaS アーキテクチャ概要
SaaS をアーキテクトをするにあたって、どのような事を考えればよいのか？をまとめました。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
マルチテナントの実現におけるDB設計とRLS / Utilizing RSL in multi-tenancy
