追記 npxコマンド一発で蔵書リストが取れるツール作ったので、結果だけが欲しい人はそっち使う方がいいです。 npx kindle-title-exporter > books.csv dominion525.hatenablog.jp 背景 Kindleの蔵書、主に漫画なんですが、現在ざっくり3500冊、600シリーズくらいあるんですよ。 なお、継続購入してるシリーズが100件くらい。 こうなるとあんまり上手く把握できなくなっちゃうからなんとかしたいなーと思ってたわけです。 しかもAmazonは公式なエクスポート機能を提供してくれないし…。 で、以前調べた時は下記くらいが挙がってたものの、ちょっとなんだかなあと思ってたんですよ。 蔵書ページをスクレイピングする方法 Kindleの蔵書を取得する - TypeScript入門 Kindle Cloud reader のWebDBを取得する方法
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 「利用者は数十億人！？ SQLiteはどこが凄いデータベース管理システムなのか調べてみた」の続きです。 はじめに 複雑な構造のデータを扱うのであればシェルスクリプトや Unix (POSIX) コマンドでデータ管理を行うのは避けるべきだと思います。解決不可能な問題が多いからです。しかしそれでも何かしらの理由でやろうと考える（やらなければいけない）のであれば SQLite を使うのをおすすめします。シェルスクリプトや Unix コマンドは行単位の単純なテキストデータをシーケンシャルにデータ処理するのが前提となっており、改行や空白が含まれる
ユーザなどのリソースエンティティのパージするわけではないデータ削除(a.k.a. 論理削除)をどう設計するか、は単純でありながら、イミュータブルデータモデルの基本形を学ぶ良い題材なので、順を追って説明する。 リソースの検討 まずユーザがアクティブなユーザと削除されたユーザで扱いが異なるかどうかを考える。この段階で物理設計としてどうするかを考えると検討ポイントが十分考慮されないことにつながるので注意しよう 。(イミュータブルデータモデル#5e3a5f1da8e5b200009c0499) 扱いが異ならない場合を考えてみよう。 code: (mermaid) classDiagram direction LR class ユーザ { <<Resource>> ユーザID : SERIAL PK 名前 : VARCHAR メールアドレス : VARCHAR ユーザ区分 : ENUMアクティブ/削
これを記事にしている 2025 年 5 月の二年ほど前 (2023-06-02) に、縁あって明治大学 情報科学科での特別講義 [1] を担当させてもらいました。 身内の評判は悪くなかったのでスライドは公開していたんですが、単に Google Slides を公開状態にしただけだったんですね。 [2] これではあとから参照・引用するのも難しく、ちょっともったいないかと思ったので、いまさらながら記事の形でまとめなおしておくことにしました。 一年も経てば情報が古くなってしまうコの業界です。賞味期限切れの話もあると思いますが、話のネタにでもしてもらえれば幸いです。 講義の対象と目的 この講義、目的は2つあって、まず「最新の情報科学トピックに触れる」こと。 それから、就職活動が始まる3年生がメインの対象者なので、 今後のキャリアプランとか人生指針に関するいろいろな視点を持ってもらうことです。 この
RAGの限界性 RAG、つまり検索強化生成（Retrieval-Augmented Generation）は、現在の大規模言語モデル分野における注目の方向性です。これは情報検索技術と生成モデルを組み合わせ、大規模モデルの知識の正確性、文脈理解、最新情報の活用などの課題を解決します。 でも追加の知識をRAGを通じて導入するだけで、モデルがそれらの知識関連の質問に完璧に対応できると考えています。しかし実際と想像にはギャップがあり、実際に試してみると、RAGの精度はそれほど良くないことに気づくかもしれません。 RAG自体の技術的原理から見ると、現在以下の問題が存在します： 検索精度の不足：まず、RAGの最も核心的な部分は、知識を「ベクトル」に変換し、「ベクトルデータベース」に導入し、ユーザーの入力情報も「ベクトル」に変換してから、ベクトルデータベースから類似の「ベクトル」をマッチングさせ、最後に
『手を動かしてわかるクリーンアーキテクチャ 』の第二章の冒頭に登場する話題に共感したので紹介。 従来の多層アーキテクチャでは、データベースを中心にアプリケーションの 開発が行なわれます。この場合、Web 層はドメイン層に依存し、ドメイン層は 永続化層、つまり、データベースに依存することになります。そうなると、す べてのものは永続化層上に構築されることになり、その結果、いくつかの要因 が絡まり合って、問題が起きやすくなります。 手を動かしてわかるクリーンアーキテクチャ ヘキサゴナルアーキテクチャによるクリーンなアプリケーション開発 20p 手を動かしてわかるクリーンアーキテクチャ ヘキサゴナルアーキテクチャによるクリーンなアプリケーション開発 作者:Tom Hombergs,須田 智之インプレスAmazon 著者によれば、機能開発をデータベース中心に設計すると、ドメイン層と永続化層の密結合が
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに 「テーブル・DBを設計するときのさいきょうの極意」を完全に理解したので 初心者（私）向けに共有する記事です。 どうぞ揉んでいただければ幸いです。対戦よろしくお願いします。 さいきょうの極意 初心者が「テーブル・DB設計して」と言われると、 「アソシエーションってあったよね・・・バリデーションも？中間テーブルを使うときと使わないときと・・・」と大変に混乱し、何から手をつけていいかわからなくなります。 そんなあなたにこれ！ ・テーブル・DB設計は「属性」と「関係」の２つだけ ・「属性」は必要なものを書くだけ ・「関係」は 1:1
はじめに この記事では、個人プロジェクトとしてRust言語でリレーショナルデータベースを開発した経験（もう五ヶ月も前...）について、その成果と反省、得た学びを共有します。 DBMSを自作した理由 自分がDBMSの自作に着手したのは、『Designing Data-Intensive Applications』という本の内容を深く理解するためでした。 この本は、データシステムの設計と運用において最も大切な「信頼性」、「拡張性」、「保守性」を保証する方法論を、豊富な文献を引用しつつ、理論と実践の橋渡しを巧みに行いながら、丁寧に説明している名著です。読んだことがない人は速攻購入してくだい。本当にいい本です。 この本は、データベースの内部構造に関する話も豊富に含まれていたので、「データベース自作してみようか...」という気持ちになりました。 Rustを採用した理由 データベースの実装のついでに、
このように、層ごとに関心事の分離を行うことで、保守性の高い（変更容易性や再利用性等）アプリケーションを実現できます。 しかし、「トランザクション」においてはどうでしょうか。 トランザクションはビジネス領域においても、技術領域においても関心事がある内容です。 そういう曖昧なものは「ひとまず usecase 層に入れてしまえ」という方針になりがちです。 ですが、DB 固有の知識を usecase 層の関心事にしてしまっては、関心事の分離をするメリットが得られません。 そのため、関心事の分離を実現しつつトランザクション実装をする方法を模索してみました。 前提 1. クリーンアーキテクチャを採用している（オニオンアーキテクチャやレイヤードアーキテクチャも含む） そもそもビジネス知識と技術知識を分離していないアーキテクチャを採用している場合、メリットは得られません。 そのため、オニオンアーキテクチャ
リレーションRが次の二つの条件を満たす。 1.第１正規形であること 2.すべての非キー属性は、いかなる候補キーにも部分関数従属していない(完全関数従属である)こと ですがこの定義の説明、専門用語と独特の言い回しが多く初見だと難しく感じたので順を追ってわかりやすく非正規形から第３正規形にしてみようと思います。 STEP0 基本となるテーブル説明の為、サンプルとなるテーブルを用意します。社員番号、社員名、部署コード、部署、趣味を持つものとします。社内向け社員検索システムの設計の一部だとでも思っていただければよいです。 仮のレコードも付け加えると以下のようになります。以後、主キーは下線にて示します。 この社員テーブルは非正規形の状態です。 社員 ※1 本来であれば社員名は姓、名で分けたり、よみがなの項目を分けて持つべきですが、今回の説明の主旨から外れるので簡易的に社員名として表現しています。 ※
# Event データモデリングとデータ基盤の構築・運用 （第14回ちゅらコラボ）CARTA HOLDINGS x ちゅらデータ 合同イベント https://churadata.connpass.com/event/254417/ ぼくのかんがえる最高のレポーティング基盤 …
関わっているあるプロジェクトで、Javaでのコンポーネントベース開発を進めるためのクラス図が出来上がりつつある。DDD（ドメイン駆動設計）に関心を持つ技術者にとってお手本になるような端正なドメインモデルだ。それを眺めながら関係者がしみじみと感じていることがある。どんなに優秀なドメインエキスパートと組んだとしても、DDDにもとづいてこのモデルを「先に」生み出すことは不可能だっただろう。 どういうことか。我々はまず、泥臭い分析と設計を重ね、あるべきデータモデルを完成させた。そのうえで実装方式の専門家の協力を仰ぎ、クラス図が出来上がった。つまり、データモデルからドメインモデルが導かれたのであって、その逆ではない。じっさい、ドメインモデルからデータモデルを導くことが不可能であったことは、両者を並べたら一目瞭然なのであった。 これは重要な論点だ。データモデリングとドメインモデリングのどちらを先行させ
Oracle Cloud Infrastructureのアカウント停止発覚 最初にも書いたが、Oracle Cloud上で稼働させているサーバプログラムが応答していないことから、アカウントが一時停止状態にあることが発覚。 急遽停止してしまったサーバプログラムに対しては暫定対応をとり、事なきを得る。 ちなみにダッシュボード上には下記のようにアカウント一時停止の旨が表示されている。 Oracle Cloudアカウントの状況 最初に自身のOracle Cloudアカウントの契約状況を書いておくと、少し前にアカウント自体はトライアルから有料アカウント(Paid Account)にアップグレードが完了している状態。 請求なども想定通りに発生しており、アカウント自体は問題なく運用できていると思っていた。 そのためアカウント一時停止が発覚した際はなぜなのか？という疑問と、突然頭から氷水をかぶったような感
NULL絶対ダメ論や現実的には無理だから上手く付き合っていくしかないんだよ論など見られるが、せっかくCodd博士が上図の分類を提示しておられるので、これを元にもっと詳細化して考えてみよう。
この記事を見てびっくりした。 https://laiso.hatenablog.com/entry/nope-sql 「個人開発のコストはDB次第」 まずビックリしたのは「DBってそんなにお金かかる？」という点。 もちろんDBがストレージ、CPU、メモリを食うのは分かる。 でもVPSならそんなにコストかからんだろう？ 俺は１日100万PVほどのエロサイトを運営しているが、WEBサーバ1台、DBサーバ1台、画像サーバ2台で動いているぞ？ VPS4台で月額6000円くらい。 次にビックリしたのは、個人開発なのに難しそうなDBサーバを使っている事。 「Cloud Firestore」「Amazon DynamoDB」「MongoDB Atlas」 ↑俺、全部知らない。。。 もちろん、こうしたDBサーバの必要性は分かるのよ。 稼働率、安定性、拡張性などなど。 でもそれって、大規模サイト向けじゃない
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
