CockroachDB はどのくらい「しぶとい」のか？ / How tough is CockroachDB?
ISUCON入門以前_ISUNARABE_LT#1
CockroachDB はどのくらい「しぶとい」のか？ / How tough is CockroachDB?
10年前に「ムーアの法則が終わる」と言われた頃から現在までのサーバ進化の技術的模索を振り返る（前編）
先々月、あるサーバベンダ主催のイベントで、最近のサーバにおける技術トレンドを紹介して欲しいという依頼を受けて、過去10年のサーバ技術のトレンドを振り返るという講演を行いました。 ほぼ10年前は「ムーアの法則が終わる」と本格的に言われ始めた頃で、そこから実はさまざまな技術、例えばストレージクラスメモリやFPGAやメモリドリブンコンピュータなどのプロセッサの回路の微細化以外の技術によるサーバの性能向上技術が注目され、その一部は市場に投入され定着しつつある一方で、商業的な成功を収められなかった多くの技術もありました。 それらをざっと振り返る内容にしたところ、現在のサーバ技術の方向性がなんとなく見えてきたのではないかと思うので、ここで記事として紹介します。 記事は前編と後編に分かれています。いまお読みの記事は前編です。 10年前、「ムーアの法則」が終わると言われ始めた 今から約10年ほど前、201
技術顧問との1on1で見積もりには3種類あることを教えてもらった - Qiita
はじめに 本記事はモチベーションクラウドシリーズ Advent Calendar 2022の17日目になります。 自分は外部の技術顧問の方に月に一回のペースで1on1する機会をもらっています。 今回はその中で話したことを共有します。 ※公開するにあたって分かりやすさを重視して脚色しています。 見積もりに対する課題感 ぼく「約束は開発を遅らせるという記事を最近読んだのですが、その通りだと思ったのですよね。」 さて、チームの外に対して約束するために「この機能1ヶ月で出せるよね？」とプロダクトの人やマネージャーに聞かれたら。これは返事に悩む。「ラフで構わないから」って言われて伝えたら、それがコミットメントになってしまったのを過去に何度も見たことがある 約束してはいけないと言いたいわけではない。約束が必要な場合がほとんどだと思う。ただ、その約束は開発を遅くするんだなぁ。だから、約束せずに気楽に開発
検索が爆速になるデータベース設計を公開します
こんにちは。エンジニアの谷井です。 フォルシアでは、Spookと呼んでいる技術基盤を用いて、主に旅行業界やMRO業界に対して、膨大で複雑なデータを高速検索できるアプリケーションを提供しています。 今回はその高速検索のノウハウのうち、特にDBの扱いに関連する部分について、ベテランエンジニアへのインタビューを通してそのエッセンスをまとめてみました。 一般的なベストプラクティスだけでなく、検索性能を高めることに特化しためずらしいアプローチもあるので、ぜひご覧ください。 フォルシアにおける検索DBについて まず前提としてフォルシアで扱うデータについて軽く説明します。 扱うデータの複雑さ たとえば、旅行会社向けのアプリケーションであれば、宿泊素材の情報としては ホテルの情報「〇〇ホテル」（~約2万件） プランの情報「朝食付き・ロングステイ△△プラン」（0~1500件/施設） 客室の情報（~100件/
エンジニアが開発しやすい環境作りをする
はじめに 自分は渋谷のWeb系開発会社にて執行役員兼エンジニアをやっています。(新卒入社3年目) 直近では6~8名程のエンジニアがいるプロジェクトで、ディレクトリ設計やissue作成、コードレビュー、スケジュール管理、PMへのUI/UX及び機能提案などを行なっています。 その中で自分が「エンジニアチームにとって開発しやすい環境整備」を色々試し、実践してきたので整理していきます。 この記事の主な対象者 エンジニアチームの開発モチベーションを上げたい人 エンジニアにとって開発しやすい環境の作り方 おことわり 今回紹介するのは自分が実践してきた一例であり、必ずしも正解というわけではありません 「こうしなさい」ではなく「こうするとより良くなるかも」といったモチベで書いています 具体的な開発の設計を紹介するものではありません エンジニアが開発しやすい環境作り 5つのセクションに分けて紹介していきます
markdownlintで設計書の品質を高める | フューチャー技術ブログ
はじめにフューチャー技術ブログのリレー形式の連載である、春の入門祭り2023の1日目です。TIG真野です。 ここ数年、Markdownで設計書をチームで書き、GitHub（GitLab）上でレビューするフローを採用しています。なるべくテキストベースで設計開発フローを統一するため、私の所属するチームでは以下のようなツールを採用しています。 シーケンス図、業務フロー図 Markdown中にPlantUMLで記載 参照はGitHub上からも見れるように、pegmatite を利用 システム構成図など画像系 Diagrams.net（draw.io）で作成し、.drawio.png の拡張子でMarkdownから参照 これだけは目視で差分チェックとなる Web API定義 OpenAPI SpecのYAMLファイル 参照はGitHub上からも見れるように、swagger-viewer を利用 ER
RFCの読み方
こんにちは。技術開発室の伊藤です。 ハートビーツではメールサーバを自社で運用しています。そのメールサーバの移設を実施するにあたり、移設を対応するチームでさまざまなメールの仕様を理解しておく必要がありました。 メールプロトコルの仕様についてはRFC（Request For Comments）が発行されているため、メールに関するRFCを読んでまとめる勉強会を行いました。 その際にRFCを読むにあたって知っておくとよいことがいくつかあったので紹介します。 RFCとは RFCとはIETF（Internet Engineering Task Force）というインターネット技術の標準化を推進する団体やその他の団体が発行している、インターネット標準や技術提供の文書です。もともとは非公式な文書であることを明確にするため、Request For Comments（コメント募集）という名前にしていたようです
Chat GPT-4にDDDのドメインモデルを考えさせたら凄かった件
バックエンド兼インフラエンジニアのrevenue-hackです！ DDD(ドメイン駆動設計)でドメインモデル考えますよね？ その時にGPT-4にやってもらったらどうなんだろう？とふと思い、実際にユースケースからドメインモデルを作ってもらいました！ ↓記事移行しました！↓
Docker一強の終焉にあたり、押さえるべきContainer事情
章立て はじめに Docker・Container型仮想化とは Docker一強時代終焉の兆し Container技術関連史 様々なContainer Runtime おわりに 1. はじめに Containerを使うならDocker、という常識が崩れつつある。軽量な仮想環境であるContainerは、開発からリリース後もすでに欠かせないツールであるため、エンジニアは避けて通れない。Container実行ツール（Container Runtime）として挙げられるのがほぼDocker一択であり、それで十分と思われていたのだが、Dockerの脆弱性や消費リソースなどの問題、Kubernetes（K8s）の登場による影響、containerdやcri-o等の他のContainer Runtimeの登場により状況が劇的に変化している。本記事では、これからContainerを利用したい人や再度情報
第153回 mysqlpumpを使ってバックアップを取ってみる | gihyo.jp
皆さんはMySQLからデータを論理バックアップする際にどんなコマンドを使っているでしょうか？ 5.7より前のバージョンを利用していた場合は、第15回 mysqldumpを使ってバックアップするや第62回 MySQLのクライアントプログラムいろいろ［その2］で紹介したmysqldumpを使用していることが多いのではないかなとは思います。 今回は、MySQL 5.7.8から導入されたmysqlpump（誤字じゃないです）について紹介してきます。 検証環境 今回は、第125回 phpMyAdminでDockerで建てたMySQLにアクセスするで記載したdocker-composeを利用して作成します。手元で簡単に試せるように、GitHubのわたしのレポジトリにサンプルコードとして置いてあるので、気軽に試したい方はgit cloneして試してみてください。試すにはdockerとdocker-com
Technology adoption life cycle - Wikipedia
Rogers' bell curve The technology adoption lifecycle is a sociological model that describes the adoption or acceptance of a new product or innovation, according to the demographic and psychological characteristics of defined adopter groups. The process of adoption over time is typically illustrated as a classical normal distribution or "bell curve". The model indicates that the first group of peop
Linuxの識者がよく使うstrace(1)やopen(2)の数字の意味は？
いちいち説明されないので知らない人もいるかもいるかもしれません。 Linuxの話をしていると識者が strace(1) とかopen(2)とか後ろに(数字)をつけることがあります。この数字はマニュアルの章の番号です。1がコマンド、2がシステムコール、3がライブラリです。コマンドとライブラリで名前が被っているものがあるために区別します。 例えば、printf(1)はコマンドでprintf(3)はライブラリです。それぞれのman を見るためには章番号を明示して、 man 1 printf や man 3 printf とします。 man man としてmanコマンドのマニュアルを見ると、全ての章の説明があります。 The table below shows the section numbers of the manual followed by the types of pages they
GitHubの新しいコード検索を支える技術
GitHub Codespacesは、仮想マシン上に強力な統合開発環境（IDE）を提供し、性能の低いマシンを持つ開発者がローカルリソースを消耗せずにコーディングできるようにし、AI画像の生成など様々なタスクに利用することが可能です。 GitHubが最近発表した「2022 State of the Octoverse」レポートにおいて、HashiCorp Configuration Language（HCL）がGitHubで最も成長したプログラミング言語となりました。HashiCorpは、クラウドコンピューティングのためのInfrastructure as Code (IaC) 自動化のリーディングプロバイダーです。HCLは、Terraformや Vaultなどのツールと共に使用されるHashiCorpの設定言語で、マルチクラウドやオンプレミス環境において、人間が読みやすい設定ファイルでIa
CTO から見た，なぜスタートアップ
初期のソフトウェア設計は壊れがちなのか - Speaker Deck
Speaker Deck This deck requires a password Password
レイヤードアーキテクチャを振り返る - Sansan Tech Blog
こんにちは、Sansanプロダクト開発部の清水です。 ある程度のアプリケーションの大きさだと当たり前に使われる事が多い「レイヤードアーキテクチャ」の自分が考える設計のポイントや、実際に運用する際のポイントについて書いてみようかと思います。 基本的な話なので「今更かよ」って感じがしますが、実際に設計、運用する際には様々な考慮事項のあるものだと思うので、知ってる人にとっても復習にでもお役に立てればと思います。 そもそもレイヤードアーキテクチャって何? 概要 一言でいうと、アプリケーションを作る際にそれを構成する部品を、それぞれ責務が定義された論理的なグループにまとめて整理し、それぞれのグループ間のやり取りの仕方を決めておこうという事です。 このグループ間のやりとりにおいて、一方向かつ隣接するグループとしかやりとりを行えないようにする事が多く、層状になるのでレイヤードアーキテクチャと呼ばれます。
技術文書の書き方
howto-tech-docs.md 技術文書の書き方 このメモは、私（@ymmt2005）が長年にわたってソフトウェアプロダクト開発に関わってきて 2022年現在こうしたほうが良いと考えているベストプラクティスです。 科学的な分析等に基づくわけではない経験則であるため、今後も随時見直すことがありますし、 ここに書いてあることが常に正しいわけでもあらゆるソフトウェア開発に適するわけでもありません。 しかしながら、実務経験が豊富で、モダンな技術スタックに明るいエンジニアの経験則は一定の 役に立つのではないかと考えて記します。 技術文書とは ここでは、ソフトウェア開発で技術者が書くべき文書ということにします。 ソフトウェアエンジニアにも役割がいろいろあり、アーキテクトと independent contributor では書く文書が違うということはあるでしょうけれど、ここではごっちゃにします。
SQLite Internals: Pages & B-trees
SQLite Internals: Pages & B-trees Author Name Ben Johnson @benbjohnson @benbjohnson Image by Annie Ruygt Fly.io runs apps close to users around the world, by taking containers and upgrading them to full-fledged virtual machines running on our own hardware around the world. Sometimes those containers run SQLite and we make that easy too. Give us a whirl and get up and running quickly. Ok, I’ll admi
障害報告書を書こう！ - Qiita
担当しているITサービスなどに何かしらのインシデントや障害が発生した時に、対処後のアクションとして報告書を提出して事象の内容を報告（レポート）する場合がある。 提出先は会社の偉い人だったりクライアントだったり。場合によってはユーザー向けに発表したり。事の顛末を報告して「今後同様のことを起こさないように努力します、ごめんなさい」をするのだ。どのように再発防止の努力するのかを書くものでもある。 主にクライアント向けのビジネス内容ではあるが、自分が使っているテンプレパターンを共有するので参考にしてもらえればと思う。1 全般的なポイント 心得のようなもの。次の点は留意してて欲しい。 淡々と冷静な説明をこころがける 当然のことながら事実は脚色しない。無駄な修飾も要らない。客観的な事実を簡潔に述べる。 例： ❌「一生懸命頑張って対応したが…」 ❌「寝ないで対応したが…」 ❌「本当の原因は…」 できるだ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
1,000行で作るオペレーティングシステム
https://twitter.com/namchan_koushi/status/1570564754800005121
