連載目次 久しぶりにソフトウェアの著作権の判例を解説する。 今回の判決は、以前「データベースをパクられたので、著作権侵害で9億円請求します！」で一度取り上げ、その考え方も説明したが、著作権の考え方を整理し直す機会として、あえて再度解説することにした。 著作権法は第二条において、コンピュータのプログラムやデータベース、通信などに関する作成物も著作物として認められると示している。しかし、こうした成果物の全てに著作権が認められるわけではない。仮に誰かが何も参考にせず、一から以下のようなプログラムを書いたとしても、これを「著作物」だと主張するのは難しい。 このプログラムを書くためには、プログラミング言語に関する最低限の知識があれば足りる。そこにプログラマーの創意や工夫、まして思想、信条などというものはない。こうしたプログラムは著作権保護の対象とはならないだろう。 だが、創意や工夫が作成したプログラ

課題 MySQL8にDocker上に構築したRailsからアクセスしようとしたら以下のようなエラーが発生して接続できなかった。 Plugin caching_sha2_password could not be loaded: /usr/lib/x86_64-linux-gnu/mariadb19/plugin/caching_sha2_password.so: cannot open shared object file: No such file or directory 注意点 本記事は caching_sha2_password 問題でハマった人向けであるが、Amazon RDS for MySQL 8.0は mysql_native_password なのでAWSで運用してしようとしている人は異なる対応が必要なので注意（参考記事を参照のこと） 原因 8.0.4からMySQLのデフ

こんな感じで、ブラウザでSQLを書いて環境構築一切不要でSQLを学べるというWebサービスです。 今北産業 SQL言語のみをサポートしています。 環境構築一切不要で、無料でお試し出来ます。 コンテンツには無料と有料の2つがあり、有料版は”買い切り”で、5000円です。全てのコンテンツがお楽しみ頂けます。 圧倒的にアカウントを買うニーズが強かった 2019年8月頃に「研修サービスのプラットフォームとして」告知をしたのですが、結論から言うと「講師や研修は別にいらん、アカウントだけ売ってくれ」が個人 / 法人共に、圧倒的に多かったため、会員登録/ログイン/マイページ/コンテンツ購入/パスワードリマインダなどの機能を別途付与して、Webサービスとしてリリースしました。 買い切りにした理由 コンテンツを定期的に追加する予定が全く無いためです。月額制にするならほっといてもコンテンツが増えていかねばなり

この記事は本番環境でやらかしちゃった人のアドベントカレンダー２日目の記事です。 内容的にそろそろ時効だと思うので供養のために書きました。 追記。そういえば時期をちゃんと書いてなかったけど事件が起きたのは去年2018年、つまり仕込み（ヲイ）は2017年の話です ぶっちゃけネタ記事ですｗ （たまたま見つけて参加してみただけなのに昨日の記事の伸びっぷりを見て戦々恐々としてる TL;DR DB移行作業において、テスト期間中は常に最新のデータで処理できるように書いておいたプログラムをcrontabで実行していた。最終的に本番に合わせて日時を調整していたが、そのことを失念し１年後に再実行されてしまい、本番データが１年前に巻き戻る事故発生。 crontab は分、時、日、月、曜日を指定できるが、１年後に帰ってくるから気をつけてね。という話。 惨劇はなぜおこってしまったのか 結論から言えばcrontabの

Slides PDF: https://15445.courses.cs.cmu.edu/fall2018/slides/01-introduction.pdf Prof. Andy Pavlo (http://www.cs.cmu.edu/~pavlo/) 15-445/645 Intro to Database Systems (Fall 2018) Carnegie Mellon University https://15445.courses.cs.cmu.edu/fall2018

こんにちは。プロダクト開発部の荒川 id:ad-sho-loko です。突然ですが、皆さんはこんな疑問を持ったことはありませんか？ データベースの内部実装はどうなっているのか？ トランザクションとはどのようなアルゴリズムで実現されているのか？ NoSQLが遅いのはなぜか？ 古典的なデータベースとは内部的にどのように違うの？ データベースを何かしらの形で利用しているのにも関わらず、意外と内部の仕組みを理解していない場合が多いかと思います。僕もそうです。*1 しかし、エンジニアたるもの、その仕組みを知ることは非常に重要です。僕もデータベースについて勉強しようといくつかの本やサイトを調べていたのですが、なかでもCMU（カーネギーメロン大学）のDatabase System Groupがアップロードしている講義が最も勉強になりました。 www.youtube.com そして本ブログでは、上記の講義

厳格なOLTPと高速なOLAPを両立 新RDBの特徴は厳格なOLTP（オンライントランザクション処理）が可能でありながら、ビッグデータ分析にも使用できる高いOLAP（オンライン分析処理）性能を有していることだ。OLTPとOLAPの両立はHTAP（Hybrid Transaction／Analytical Processing）と呼ぶ。OLTPで用いる行方向のデータは不揮発性メモリーを採用する主記憶（メインメモリー）に格納し、OLAP用の列方向のデータを2次記憶装置に格納する。2次記憶装置にも不揮発性メモリーを使用する。 OLTPに関しては、トランザクション処理の分野で一般的なベンチマークである「TPC-C」において1ノードで1000万トランザクション／秒（TPS）の達成を当面の目標とする。そしてトランザクション処理においては、一貫性と隔離性のレベルを示す「トランザクション分離レベル」が最も

Teachme Bizの力を活かした新規の事業、Salesforce連携の機能をClojure使って作った。弊社の技術スタックも多様化が進み、これからさらにClojureなり他の技術でも取り入れて柔軟性とパフォーマンスの優れたサービスを提供し続ける。 関連してClojure界隈で流行りのデータベース、Datomicも軽く試してみた。DatomicはClojureの思想を貫いたデータ不変（immutability）の旗を掲げている。 Image from Hacker NoonClojureでも、データ構造は基本的に「更新」はできない。データの一部を更新したいとき、既存のデータが変更されるのではなく、更新が適応された「新しいデータ」ができる。これを実現するClojure自体の実装やメモリー管理などにはここで言及しないが、興味ある人はぜひ調べてください。 DatomicはClojureを作った

上記の例では、単一のトランザクション(id 1001)で、EntityID 42でpersonに関するキーと値のペアが、EntityID 43でaddressに関するキーと値のペアが記録されたことを意味します。 Datomicデータベース内において、属性(Attribute)はユニークなキーを持っていなければなりません。名前空間付きキーワードの名前空間を便宜的に属性のグルーピングに使用することができます。 SQLのテーブルでいうところの行を追加するには、同じ組み合わせの属性を、別のEntityIDに紐付けて格納することになります。追加のタイミングが異なれば、新しいトランザクションを実行し、別のTx IDが割り振られることになります。 データは一度格納されると、上書きされることはありません。既存のEntityIDとAttributeで新しい値を追加すれば上書きに相当する、「新しい事実」を記録

ハンドノート T字形ERモデル　セミナー資料　(Author; S.Toriyabe SYSTEMS DESIGN Co.,Ltd. Japan)

RDBのレコードに、作成日時や更新日時を自動で入れ込むコードを書いたりすることあると思いますが、それに対する個人的な設計指針です。ここでは、作成日時カラム名をcreated_at、更新日時をupdated_atとして説明します。 tl;dr レコード作成日時や更新日時をRDBのトリガーで埋めるのは便利なのでやると良い ただ、アプリケーションからそれらのカラムを参照することはせず別に定義した方が良い MySQLにおける時刻自動挿入 MySQL5.6.5以降であれば、以下のようにトリガーを設定すれば、レコード挿入時に作成日時と更新日時を、更新時に更新日時を、DATETIME型にも自動で埋めてくれます。いい時代になりました。(MySQLが遅すぎたという話もある) `created_at` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, `updated_

今年Firebaseを使い始めてからちょこちょこ自分の中で議題に上がるのが、RDBとFirebaseのデータベース（Firestore、Realtime Database）のどちらが使い勝手良いのか、ということ。ただ、そもそもどちらかを選ばなきゃいけないというわけではなく、適宜両方使えばいいということが分かったのでそれについての雑記。 そもそもまず、なぜ悩むところがあったのか。 Firebaseのデータベースのデメリット 一番大きいのはやはりリレーショナルでないことと、クエリが弱いということ。集計ができなかったり、欲しいデータがすぐ取れなかったりする。 RDBのデメリット とりあえずRDBにしておけば何でもできるというのはあるが、デメリットとしてはやはりサーバーもしくはお金が必要になってくるということ。サーバー内に入れると管理やスペックの調整などが気になるし、別途RDSやCloud SQL

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

Firebase Realtime DBを実践に投入する Databaseと聞くと、これから利用しようとする**Firebase**がmBaaSであることを忘れてついREST(Client Server Model)で考えてしまいがちですが、大前提はMobile Platformなので、一度REST、RDBの考え方は捨ててみてください。 RDBの考え方を引き継いだままでは、Firebase Realtime DBの最善の設計はできないと考えています。 そして、RDBの考え方を引き継いだままFirebase Realtime DBを理解しようとすることが、導入の一つの障壁となっていると思っています。 ぜひ頭をリフレッシュしてFirebase Realtime DBの見方を変えてみてください。 この記事では、Firebase Realtime DBの導入するにあたっての考え方やテクニックを紹介

Firebase のインターフェースとツールで AI 搭載のアシスタントを使用して、開発を効率化します。

SQLインジェクション対策をしていなかったことについて開発会社の責任が問われた事例。 事案の概要 Xは，Yに対し，Xの提供する車・バイクの一括査定システム（本件システム）の開発を約320万円で委託し，平成24年9月に納品を受けた。 その後Xは，平成28年12月に，IPA*1から，中国のサイトに本件システムの脆弱性に関する情報が掲載されているという指摘を受けて，Yに対し，その調査と報告を依頼した。 その結果，本件システムには，ＳＱＬインジェクション対策が不十分という脆弱性が判明したことから，XはYに対し，その脆弱性はYの被用者の故意過失によって生じたものであるから，使用者であるYには使用者責任があると主張して，民法７１５条１項所定の損害賠償請求権に基づき，緊急対策費用４７万５２００円，詳細な調査，抜本的な修正費用６４０万円，サーバー移転費用３５万６４００円，セキュリティ対策のための本件システ

最近、InfluxDBを使う機会があったので、このエントリではInfluxDBについて簡単に紹介します。 なお、他の時系列データベースとの比較は行なっていないのでご了承ください。 InfluxDBの特徴 InfluxDBは時系列データベース(Time Series Database/TSDB)の1つで、HTTP APIを備えているという特徴があります。 時系列データベースはRDBと違って、時系列データに特化したDBです。 時系列データとは、サーバのメトリクスやユーザーの行動ログなどのように、1つ1つの情報自体よりも「情報の変遷」が意味を持つようなデータです。 InfluxDBにも時系列データベース特有の、データに保持期限を設けたり、データを間引いたり(ダウンサンプリング)する機能が備わっています。 InfluxDBのクエリはMySQLなどのRDBとよく似ています。 学習コストは低いものの、

こんにちは。インフラストラクチャー部 SRE グループの吉川 ( @rrreeeyyy ) です。今期オススメのアニメはツインエンジェル BREAK です。 普段の業務並びに趣味の一環として、サーバのモニタリング環境の調査や改善に取り組んでいます。 そこで本稿では、モニタリングのコンポーネントの一つとして外すことが出来ない、時系列データベースの基礎知識に関して紹介します。 そもそも時系列データ・時系列データベースとは？ 時系列データというのは、特定の時間ごとに何らかの値を取得した際の、取得した一連の値を指します。 例えば、以下のようなフォーマットをしたデータなどは時系列データにあたるでしょう。 timestamp1,key,value1 timestamp2,key,value2 timestamp3,key,value3 : 時系列データベースとは、上記のような時系列データの保存・処理に

Mackerel チームのWebアプリケーションエンジニア id:astj です。 さくらインターネットさんのプレスリリースにある通り、はてなのMackerelチームより、私 id:astjと、同じくWebアプリケーションエンジニアの id:itchynyも執筆に参加した論文「HeteroTSDB: An Extensible Time Series Database for Automatically Tiering on Heterogeneous Key-Value Stores（HeteroTSDB: 異種混合キーバリューストアを用いた自動階層化のための時系列データベースアーキテクチャ）」が、IEEEの国際会議「COMPSAC 2019」に採択されました。 論文は、2019年7月15日～19日（現地時間）にアメリカ合衆国ウィスコンシン州で開催された「COMPSAC 2019」にて、