自作DBを始めたい人におすすめの本 - salachike:blog
この記事は、慶應理工アドベントカレンダー2021の20日目の記事です。 カレンダー全日埋まってすごい 🎉🎉 adventar.org 「Database Design and Implementation」という簡素なDBをスクラッチで作っていく本に取り組んだので、その読了エントリです。 Database Design and Implementation: Second Edition (Data-Centric Systems and Applications) (English Edition) 作者:Sciore, EdwardSpringerAmazon こんな人におすすめ MySQLやPostgreSQLを使った経験はあるが、DBの理論やその実装はあまり詳しくない人に特におすすめです。特に自作〇〇*1に興味がある人は間違いなく楽しめると思います。単純に本に紹介されている理論
WEB+DB PRESS Vol.125の特集「GraphQL完全ガイド」を執筆しました - cockscomblog?
今週、10月23日（土）に発売されるWEB+DB PRESS Vol.125に掲載される、特集記事「GraphQL完全ガイド」を執筆しました。よろしくおねがいします。 桃栗三年、GraphQL 6年 原稿を書く過程で、知っているはずのことでも改めて調べなおしたりする。特に歴史みたいなのが好きで、GraphQLは2015年6月に発表されて、2018年に安定版になって、みたいなのをずっと調べてしまう。GraphQLってなんかすごい最近っぽく感じていたけど、発表されてからもう6年経つらしい。 ちなみにjQuery 1.0は2006年8月にリリースされていて、Reactは2013年5月に公開されたらしい。6年というのはだいたいそれくらい。 6年で、GraphQLはよく普及した。Facebookはもちろん、GitHubもTwitterもNetflixも、GraphQLを使っている。GitHubの新し
妄想的DHH理解2:概念的距離の圧縮 - Qiita
Caution この記事はDHHファンの妄想によるシナリオが多分に含まれます。 というかほとんどです。 成り立ちや考え方が間違ってることも当然あるように思うので話半分で読んでください。 これは一体 前回かいた妄想的DHH理解のエピソード0的な話です。 妄想的DHH理解では、DHHがどういう過程で今のRailsフロントエンドに達したかの話が主題でしたが、そこでは「なぜ〜を選ばなかったか」は説明されていませんでした。 彼はモノリシックを愛したり、トレンドと真逆のアプローチでフロントエンドに新しいレールを引き始めたりするので、単に彼が天邪鬼であったり車輪の再発明大好きおじさんとして捉えられがちですが、実は太い太い一本筋をもった技術選定をし続けてるってことが広まればいいなと思ってるファンの記事です。 前提知識 前回とほぼ同じです。 Railsの生みの親、Rubyist。 実はカーレーサーでもありま
もうAPIを自分で開発するのは古い？Hasuraの強烈な有効性について紹介する - Qiita
今回伝えたいこと Hasuraの有効性を伝える 開発工数の削減効果 柔軟性の高さ セキュア 「開発工数の削減」という課題 昨今のエンジニアの不足や単価の上昇により、開発工数を十分に確保できない課題がある。どこの会社も開発工数を減らすために色々な策を講じているのではないか。 新技術の活用 慣れた技術の利用 プロセスの見直し 徹底した自動化 スコープの見直し 過剰品質をやめる などなど。今回は一番上の「新技術の活用」によって開発工数を削減できる可能性があるのではないかということを提案する。 こんなアプリを作ることになったとする 仮にあなたがこんなアプリを作ることになったとする。 シンプルなオンラインホワイトボードツールで以下のような機能があることが必要 付箋に文字を書ける 付箋を動かせる 付箋の色がユーザ固有の色になる 付箋を消せる(自分の作った付箋だけ) 付箋の位置、内容などをリアルタイムに
DDDとORMのEntityを混同しないための考え方
２つの ”Entity” ある種の ORM では RDB のテーブルスキーマモデルとなるクラスのことをEntityと呼んでいます。例えば PHP のDoctrineや TypeScript のTypeORMなどがそうです。 そういった ORM を採用したプロジェクトで DDD に取り組むとき困るのが用語の衝突です。ORM の Entity は RDB のための定義を含むため当然 DDD の Entity とは異なるのですが、なにぶん同じ名前なので混同してしまいがちです。 本記事では両者を混同せず扱うための考え方をまとめます。 Entity の定義 まずは定義から確認します。 DDD での定義 エヴァンス本の日本語訳から引用します。 主として同一性によって定義されるオブジェクトはエンティティと呼ばれる Eric Evans. エリック・エヴァンスのドメイン駆動設計 (Japanese Edi
システム構成図をテキストで
Gigazineさんでdrawthe.netを取り上げていたので紹介です。使い方はGigazineさんのほうが丁寧なので、気になる方はチェックしてみてください。（2020年12月1日、追記） drawthe.netとは cidrblock/drawthe.netは複雑なネットワーク図も「テキストで書いてブラウザ上でSVGレンダリングできるようにしよう」というコンセプトのもと開発されたツールです。下図のように複雑な構成図も精度高く描くことができます。 拡大してみると情報量が多いこと、またいかに整っているかがわかると思います。 デモサイトも用意されているので、サクッと試したい場合はコチラが便利です。コードはGitHubで公開されています。更新が2017年末で止まってしまっているのが玉に瑕ですが、十分な性能を発揮してくれます。 drawthe.netを使いたい理由 美しい構成図といえばInter
サイトトップにAIを導入して売り上げに1億円貢献する - エムスリーテックブログ
エンジニアリンググループ AI・機械学習チームの金山 (@tkanayama_)です。今回は、私が立ち上げ段階から主担当として推進しているプロジェクトである、サイトトップページのコンテンツを自動更新するシステムの開発について書きます。後のA/Bテストにより、このシステムは年間換算で1億円規模の売り上げ貢献をしていることを示すことができました。この記事では、こうしたインパクトの大きいプロジェクトがどのように進行したかを説明します。よく弊社のブログや勉強会などで語られる「エムスリーはROIを重視する風土がある」ことの一例だと思って読んでいただければと思います。 （なお、タイトルに「AI」や「1億円」という強い言葉を並べてしまったことをここに懺悔します。） プロジェクトの概要 エムスリーでは、医療従事者向け総合医療情報である「m3.com」というウェブサイトを運営しています。このウェブサイト上に
データベースをリファクタリングしたお話 - BASEプロダクトチームブログ
基盤チーム所属の沖中( @okinaka )です。 「リファクタリング」という言葉、エンジニアのみなさんならご存知でしょう。 システムの振る舞いを変えずに内部を改善することを指す言葉です。 一般的に、コードの修正を指すことがほとんどですが、今回はデータベース設計のリファクタリングについてお話ししたいと思います。 絶版になってしまいましたが、データベース・リファクタリング という書籍に様々な手法が紹介されていて参考になります。英語で良ければ 原書 はまだ入手可能ですね。 データベース・リファクタリング 作者:スコット W アンブラー,ピラモド・サダラージ発売日: 2008/03/26メディア: 単行本 Refactoring Databases: Evolutionary Database Design (Addison-Wesley Signature Series (Fowler)) (
[講義] データベース設計の講義資料を公開します - YoheiM .NET
こんにちは、@yoheiMuneです。 G's ACADEMY TOKYOさんでいくつか講義を担当させていただいているのですが、新しくデータベース設計の講義を行ったので、そのスライドを公開したいと思います。 講義内容 この講義は、初めてプログラミングを学んだ方向けで、卒業制作で作るアプリケーションのデータベース設計ができるようになることを目標にしています。特に論理設計を扱い、アプリケーションで扱うデータ構造を読み解いて理解できるようになります。 論理設計では以下の項目を扱います。 データの理解 エンティティの定義 リレーションシップの定義 データ項目の定義 列の定義 少しでも参考になればと思い、もし気になった方はチラッと見てみて頂けたら嬉しいです。 編集後記 データベース設計についていざ講義を作ろうとするとなかなかアイデアがまとまりませんでした。いつもやっていることをいざ明文化しようとする
![[講義] データベース設計の講義資料を公開します - YoheiM .NET](https://cdn-ak-scissors.b.st-hatena.com/image/square/c8f8646166b23c50571aee45678e8d77a47d399e/height=288;version=1;width=512/https%3A%2F%2Fwww.yoheim.net%2Fimage%2F546.png)
イミュータブルデータモデルへの取り組み with Ruby on Rails - リサーチ・アンド・イノベーション 開発者ブログ
こんにちは。リサーチ・アンド・イノベーションの中村(konk303)と申します。 いわゆる「railsおじさん」的な立場で、主にサーバーサイドの開発をしています。 Introduction 本稿ではQiitaのイミュータブルデータモデルと webアプリケーションにおける現実解にインスパイアされて、弊社でのイミュータブルデータへの取り組み(とその苦しみ)を紹介したいと思います。 qiita.com イミュータブルデータモデルとは? まるっと引用。 イミュータブルデータモデルと webアプリケーションにおける現実解 - Qiita 詳細はリンクに譲りますが、「履歴を全て残すようなデータ設計にし、 UPDATE を廃することで情報の追跡可能性を確保、堅牢な設計にする」モデリング手法です。 原則この手法に従うと、そうそう汚いモデルにはならないという優れもの(雑) です。イベントが起こる度に新規レコ
「推測するな計測せよ」は「性能上がらなかったら捨てろ」ではない : DSAS開発者の部屋
「推測するな計測せよ」という格言がよく知られています。この格言は（ISUCONに優勝した）Goの作者の一人でもある、 Rob Pike 氏の言葉が元になっています。 ルール1: プログラムがどこで時間を消費することになるか知ることはできない。ボトルネックは驚くべき箇所で起こるものである。したがって、どこがボトルネックなのかをはっきりさせるまでは、推測を行ったり、スピードハックをしてはならない。 ルール2: 計測すべし。計測するまでは速度のための調整をしてはならない。コードの一部が残りを圧倒しないのであれば、なおさらである。 UNIX哲学 on Wikipedia このルールは、推測だけで高速化のための変更をすることを諌めていますが、直接に高速化の効果が無い変更をするなとは言っていません。 正しいデータ構造やアーキテクチャは、それだけでは性能が向上せず、それを利用した改善を入れて初めて効果が
SCOUTER開発者ブログ
2024-09-10 テクノロジア魔法学校の体験談と評判 「テクノロジア魔法学校」というプログラミング教材をご存知ですか？ ホームページの広告などで一度は目にしたことがある人も多いのではないかと思いますが、ディズニーが提供する子供向けのプログラミング教材です。 今回は、この「テクノロジア魔法学校」の体験版を実際に体験してみての感想や、「テクノロジア魔法学校」がどのようなものか、その評判などを見ていきたいと思います。 テクノロジア魔法学校とは 料金 エント […] 2024-09-10 レンタルサーバー「クイッカ」の評判と使い勝手 レンタルサーバーとして有名なサーバーの一つに、「クイッカ」があります。 名前は聞いたことのある人も多いのではないかと思いますが、今回はこの「クイッカ」について、料金やスペック、評判などを見ていきたいと思います。 レンタルサーバー「クイッカ」の基本情報 レンタルサー
フロントエンド実装中に使えるモックサーバを爆速で準備する - Qiita
で完了 なければ nodeのバージョンをnで管理する などを読みつつnodeとnpmをインストールしてください 準備するもの コンソール db.json ブラウザ（動作確認用） やること db.json ファイルを作成する bashの touch コマンドやWindowsなら右クリックからなどでお好きなようにファイルを作ってください db.json にリソースを登録する ここでモックサーバから返して欲しいデータリストを列挙します 最上位の階層の key がエンドポイントになります { "users": [ {"id": 1, "name": "hoge"}, {"id": 2, "name": "fuga"} ], "tweets": [ {"id": 1, "contents": "あー眠い", "user-id": 1}, {"id": 2, "contents": "ファビュラス！"
なぜ、SQLは重たくなるのか？──『SQLパフォーマンス詳解』の翻訳者が教える原因と対策｜ハイクラス転職・求人情報サイト AMBI（アンビ）
なぜ、SQLは重たくなるのか？──『SQLパフォーマンス詳解』の翻訳者が教える原因と対策 『SQLパフォーマンス詳解』の翻訳者の松浦隼人さんに、8つの「SQLが重たくなる原因とその対策」を聞きました。システムのボトルネックになるような「問題のあるSQL」を回避するノウハウを学びましょう。 データの操作や定義をする言語「SQL」は、どのような領域を担うエンジニアにとっても必修科目です。しかし、その仕様をきちんと理解し、パフォーマンスに優れたSQLを書ける方はそれほど多くありません。問題のあるSQLを書いてしまい、知らぬ間にそれがシステムのボトルネックになってしまう事態はよく発生します。 では、どうすればそうした事態を回避できるのでしょうか？ そのノウハウを学ぶため、今回は『SQLパフォーマンス詳解』の翻訳者であり、自身もエンジニアでもある松浦隼人（まつうら・はやと／@dblmkt）さんに8つ
ユーザー基盤を作り直しながらRailsでのサービス層に向き合う - クックパッド開発者ブログ
こんにちは。パートナーアライアンス部の諸橋 (@moro) です。 突然ですが、わたしはいまクックパッドの「ユーザー基盤」を再構築しようとしています。 一口に「ユーザー基盤の再構築」といっても、そのゴールが何を指すかは(わたし自身にとってもまだ)漠然としており、固定されたゴールは見いだせていません。しかし後述するように、いくつかの問題は明確な形を取っています。言い換えると、それら明確な問題と向き合いながら『柔軟でいい感じのユーザー基盤を目指す』というのがこの再構築プロジェクトの目的です。 その第一歩目として、ユーザー登録部分を現状のクックパッド本体とは別の小さなRailsアプリケーションとして実装を進め、つい先日、一部の限定された利用者の方に向けて公開することができました。 今後も様子を見ながら公開範囲を拡大していく予定です。 再構築の背景 ではその「明確な問題」とはなんでしょうか。 最大
「Google Cloud Spanner」発表。地球規模の大規模分散環境で稼働するミッションクリティカルなリレーショナルDB。NoSQL並のスケーラビリティでSQL対応、トランザクション処理を実現
「Google Cloud Spanner」発表。地球規模の大規模分散環境で稼働するミッションクリティカルなリレーショナルDB。NoSQL並のスケーラビリティでSQL対応、トランザクション処理を実現 Googleは、クラウド上で高度なスケーラビリティを実現する、ミッションクリティカルな業務に対応したリレーショナルデータベースサービス「Google Cloud Spanner」を発表しました。 Google Cloud Spannerは、地球規模の大規模分散処理データベースとして、NoSQL並の非常に高いスケーラビリティと高い可用性、そして高速な処理を実現しつつ、SQLに対応。強い一貫性を持つトランザクション処理も実現。企業のミッションクリティカルな業務にも使えると説明されています。 地球規模に分散したリレーショナルデータベース 一般に、ミッションクリティカルな業務に対応したリレーショナルデ
GraphQLを勉強した - mizchi's blog
自分でGraphQLサーバーを実装しながら勉強したログ。間違ってるかも。 コードはここにあるが、何の注釈もない。 https://github.com/mizchi-sandbox/play-graphql-server RESTの課題 REST は URI とモデルのマッピング構造だが、往々にしてクライアントで必要となる構造は モデルのうち一部であったり、そのリレーショナルな構造に依存する。 つまり、REST というルールに従って必要なデータを組み立てると、リレーショナルな構造によってN回のリソースへのアクセスと、興味がないデータを含んだ不要なペイロードが発生しがちである。 GraphQL は何をしたいか 1リクエスト内でモデルへの問い合わせを合成し、さらに必要なものだけ返却したい 言語とは独立した、転送経路上のモデルの定義を行いたい パフォーマンス上の理由とセマンティクスが同居している
RDBMSが強すぎる件 - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
以前、「RDBMSを採用すると、無料で外部キー制約とかチェック制約とかトランザクションが付いてきてオトク！！！」という発言をしたことがあって、その考えは今もあまり変わっていない。 RDBMSは単なる便利な箱じゃなくて、データの整合性を守るための仕組みがたくさん備わっている。もちろん、これらの仕組みは「タダ」で使えるわけではなく、データモデリングを学んだり、データ構造を学んだりという「投資」の結果うまく使えるようになるものだけれど。 ところで問題（？）は、RDBMSは強すぎる、ということです。 たとえば、トランザクションの話。「本質的にはトランザクション整合性である必要がなく、遅延してあとから整合性が取れてればよいような処理（つまり、結果整合性でよいような処理）」というのは、意外と多い。 多くの開発の現場では、トランザクション整合性が必要とされるか結果整合性でよいのかについてあまり考えず、「
DBエンジニアのミックさんが語る、RDBで階層構造データを扱う「入れ子集合モデル」の将来性
これまで階層構造データはリレーショナルデータベースでうまく扱えませんでしたが、その解決策としてジョー・セルコが提案したのが「入れ子集合モデル」です。この手法を紹介した『プログラマのためのSQLグラフ原論』の刊行にあたり、翻訳されたDBエンジニアのミックさんに入れ子集合モデルの将来性についてうかがいました。 なぜRDBで木と階層構造を扱う手法が1冊の書籍に？ ――『プログラマのためのSQLグラフ原論 リレーショナルデータベースで木と階層構造を扱うために』についてミックさんにうかがいます。最初に、本書がどういう本なのか教えていただけますか？ ミック：内容としては、リレーショナルデータベース（RDB）でグラフ構造の一つである木と階層構造を扱うための方法論「入れ子集合モデル」をメインに解説しています。RDBには大きな問題があり、入れ子集合モデルがそれを解決しうる手法だと見込まれています。その問題と
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
PayPayでのDynamoDB活用事例について
