連載目次 久しぶりにソフトウェアの著作権の判例を解説する。 今回の判決は、以前「データベースをパクられたので、著作権侵害で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を作った

この記事は、2017年のClojure/conjで、Cognitect社のStuart Hallowayが発表した、Datomic Made Easy Datomic in the Cloudを元に書き起こしたものです。 2017/11/23時点で、まだ正式に発表されていないので、Sneak Previewという位置づけでお読みください。 また、Datomicについては、Rich Hickey on Datomic, CAP and ACIDを参考にしています。 Datomicとは Datomicは2012年に、Clojureの開発者であるRich Hickeyによって設計されたデータベースシステムです。Cloud上で使うことを念頭に分散データベースとして設計されていますが、多くのNoSQLソリューションと異なり、書き込みに関してはACID(原子性 Atomic, 一貫性 Consiste

This document summarizes a microservices meetup hosted by @mosa_siru. Key points include: 1. @mosa_siru is an engineer at DeNA and CTO of Gunosy. 2. The meetup covered Gunosy's architecture with over 45 GitHub repositories, 30 stacks, 10 Go APIs, and 10 Python batch processes using AWS services like Kinesis, Lambda, SQS and API Gateway. 3. Challenges discussed were managing 30 microservices, ensur

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

個人的に作っているアプリで簡単にリアルタイムにデータが同期される機構を組み込みたく調べていたところ、Firebaseにたどり着いたのでまずはざっくり概要をまとめました。 Firebaseとは Googleが運営しているMBaasです。 Firebaseの特徴としては、他のMBaasと同じ様に、オンラインでサインアップするだけで、オンラインのデータベースにデータを保存 / 取得ができることに加え、 HTML / CSS / JS / 画像などの静的ファイルをホスティングし、CDNを通じSSLで提供するとこまでを提供するFirebaseHostingやユーザーの行動を分析するFirebase Analyticsなど、Googleさまさま(?)な強力な機能も利用することができます。 Firebaseの機能一覧 サービス 概要 対応プラットフォーム

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の導入するにあたっての考え方やテクニックを紹介します。

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」にて、