漢(オトコ)のコンピュータ道: ダウンロード違法化の審議について一言言っておく
ライセンス違反の静止画像のダウンロードを違法化しようという法律の審議が行われているらしい。 海賊版静止画のＤＬ規制を 文化審議会が意見まとめる：朝日新聞デジタル はっきり言って、これは由々しき事態である。インターネットの利用に大きな制約をかけ、日本の文化を破壊するであろう、最悪の法案であると言える。はっきり言って、このような低レベルな話し合いが行われていること自体に私は憤怒している。最近は多忙のため筆を置いていたのだが、久々に筆をとることにした。この法案の問題をしてきしておかねばならないからだ。 技術的に取り締まりは難しい一技術者としてこれだけは言っておきたい。そもそも、ダウンロード側を意図したものだけ上手く取り締まるような技術は存在しない。 まず、ファイルのダウンロードというが、それは範囲が大きすぎる。多くのウェブページには画像が多数埋め込まれているが、基本的にそれらは画像ファイルを特定
MySQLのZero Dateへの対処法
MySQLのZero Dateへの対処法 MySQLの0000-00-00 00:00:00は使ってはならない - そーだいなるらくがき帳 このエントリで、MySQLのゼロが含まれる日付け、いわゆるZero Dateについての問題点が色々挙げられているのを見かけたので、手短に対処法を述べておきたい。 Zero Dateが存在する理由なぜそんな厄介なデータが存在するのかというのは、開発の経緯や互換性といった深淵な理由からなので気にしないで欲しい。まあ、人間は完璧ではないので、人間が作るプログラムも完璧ではないということだ。 当然ながらSQL標準から外れているものは、例外的な使い方をしたい場合を除き、使うべきではない。アンチパターンも使い方次第という話もあるが、例外的な使い方は基本的に苦労が増えるので使うべきではない。 SQLモード実は、Zero DateはSQLモードで禁止できる。SQLモー
MySQL 8.0登場！立ち止まることを知らない進化はこれからも続く。
ゴールデンウィークはいかがお過ごしされただろうか。今年は天気も良く、行楽日和が続いたように思う。 さて、先日MySQL 8.0が正式にリリースされた。少し時間が経ってしまったが、今回はMySQL 8.0の新機能について紹介したい。コミュニティ版のダウンロードはこちらから可能だ。 ひとつ前の正式バージョンはMySQL 5.7だったのだが、MySQL 8.0は非常に大きなリファクタリングが含まれており、5.x台のバージョン番号を捨て去ろうという話があった。そこで、次のメジャーバージョンは最初の桁を増やすということになったのだが、MySQL 6.0は過去に既に存在し、買収などの騒ぎで開発が頓挫してしまった経緯がある。7.xはMySQL NDB Clusterと被っている。というわけで、5.7の7の部分の次という意味合いもあって、8.0というバージョン番号を引っさげ、満を持しての登場となった。その
MySQL 8.0.0 Development Milestone Release登場！！
先月、詳解MySQL 5.7を発刊したばかりであるが、MySQL 5.7自体は去年の10月にリリースされたバージョンである。それから約1年弱、MySQLは開発の手を緩めること無く日々改良を重ねている。 そう、MySQL 8.0の登場である。 現在はDevelopment Milestone Release（通称DMR）という状態なので、まだ正式版における機能が固まっている段階ではないという点には注意して欲しい。MySQLの開発プロセスでは、DMRをリリースするごとにその段階で成熟した機能をマージする。DMRを何度かリリースした後に、キリの良いところでリリース候補版となって正式版で追加される機能が一応確定し、その後バグ修正を経て正式版（GA版）がリリースされる予定となっている。詳しくはMySQLのマニュアルを参照して欲しい。 バージョン8.0!!5.7の次は誰もが5.8だと思っていただろう・
この世から残念な○○が無くならない理由
少し前に、日本Web技術界隈著名人の残念さ具合というタイトルの記事が話題になった。名指しで個人を批判している記事なので、リンクするのは控えておこうと思う。意見には賛同する部分はあるものの、読んでいて気持ちの良いものではないからだ。まだ読んでなくて興味のある人はググッて頂きたい。あと、言っておくが私自身はその記事でリストアップされている人たちの仕事ぶりは知らないので、評価については言及しない。 この記事を読んで思ったのは、別に残念なのは別にウェブ界隈に限った話ではないよなーというか、残念な人をこの世から撲滅するのは構造的に不可能ではないかということだった。特に後者についてはかねてより考えてきたことであり、これはもうある意味仕方のないことではないかと思う。具体的な例を挙げるのは避けるが、割と技術書なんかでも酷いものを見かける。 というわけで、今日はこの構造的な問題点について語ろうと思う。 圧倒
RDBにおけるキャッシュという考え方
RDBの専門家として日々活動している中で気づいたことのひとつに、「RDBはデータへのアクセスの実装をインデックスに頼っているが、インデックスは全ての問題を解決できるほど万能ではない」ということがある。インデックスというのはとても強力な部品であり、その点には全く異論はない。だが、世の中の全ての問題（クエリ）を解決できるほど、柔軟性に富んだものではないということだ。RDBは、どのインデックスを使ってデータへアクセスするかということを、オプティマイザを用いて判断する。大抵のRDB製品では、オプティマイザはよい仕事をするので、インデックスとオプティマイザの組み合わせによって、ほとんどの問題に対応できる。だが、100%ではないのであり、そのようなケースがシステムの性能問題を引き起こしたり、プログラマ（アプリケーションの設計者）に、NoSQLへ完全に移行したり、クエリ高速化のために非正規化をすると言っ
書籍出版のお知らせ：理論から学ぶデータベース実践入門 ~リレーショナルモデルによる効率的なSQL
来る2月27日、データベースの新書籍を発売させて頂くことになった。タイトルは「理論から学ぶデータベース実践入門 ~リレーショナルモデルによる効率的なSQL」となっている。単に「データベース」と書いてあるが、RDBがメインのテーマの書籍である。 多くの人が未だにRDBを使いこなせていないのではないか。RDBの使い方をマスターするには何が必要なのか。それがここ数年私が追ってきたテーマであり、この書籍を出すことになった動機である。 あまりにも酷いDB設計、あまりにもスパゲティなクエリ、あまりにも希薄なデータモデルへの理解。そういった問題はどこから生み出されるのか。そのひとつの結論としてたどり着いたのが、「そもそもRDBの使い方があまり理解されていないのではないか」ということだった。名著、SQLアンチパターンでは「やってはいけないケース」について学ぶことができるが、その反対のテーマ、つまり本来どの
InnoDBのファイルサイズ管理
最近、InnoDBのデータ領域（テーブルスペース）が成長してしまって元に戻すことが出来ない場合の対処についてよく質問されるので、今日はテーブルスペースが成長することへの対策について説明しよう。（ここのところMySQLネタが続いているが、Planet MySQL日本語版を意識しているわけではないのであしからず！！＜＜ホントかよ？！＞俺） InnoDBのテーブルスペースが成長してしまうのは、ズバリ自動拡張しているからである。テーブルスペースに対して何もオプションを指定しないと、デフォルトでは次のような設定と同じテーブルスペースが作成される。 [mysqld] innodb_data_file_path=ibdata1:10M:autoextend サイズは10MBしかないが、自動拡張するのである。自動拡張してしまうと何が問題なのかというと、データが増えた場合にファイルシステムの空き領域を使い切
MySQLレプリケーションの運用が劇的変化！！GTIDについて仕組みから理解する
メリークリスマス！！やあ、良い子のみんな！！サンタクロース・・・ではなく、ヒゲモジャギークからのクリスマスプレゼントだよ！！ というわけで、MySQL Casual Advent Calendarの25日目である。今朝Advent Calendarを覗いてみると、本日分のエントリーが無かったので、急遽書くことにした。Advent Calendar最後の日、クリスマスを飾る記事のテーマはGTIDだ。 前回の投稿では、MySQL 5.6の目玉機能として、レプリケーションがクラッシュセーフになったことを挙げた。レプリケーションまわりで言えば、もうひとつ外せない目玉機能がある。それがGTID（Global Transaction ID）である。 GTIDは良くも悪くもレプリケーションの運用を変化させる。GTIDを使うことによって得られる最大のメリットは、CHANGE MASTER TOでバイナリロ
まだMySQL 5.5で消耗してるの？MySQL 5.6でクラッシュセーフなレプリケーションを活用して枕を高くして眠れる日々を満喫する方法
MySQL 5.6が登場してからかなりの月日が過ぎたが、他のことで多忙だったせいか、MySQL 5.6についてはあまりブログで情報を発信していないことに気がついた。これはイカン！！と思い、MySQL Casual Advent Calendar 2014に合わせて、MySQL 5.6を使用する上で最もオススメしたい機能であるクラッシュセーフなレプリケーションについて解説しようと思う。この記事は16日目の記事である。 レプリケーションがクラッシュセーフとはどういうことかクラッシュセーフとは、何らかの事情により、プロセスがダウンしたりマシンが電源ごと落ちたり（つまりクラッシュ）しても、再起動後に以前の状態に戻って処理を再開できるということだ。データのクラッシュリカバリであればみなさん既によくご存知であろう。（REDOやUNDOするアレのことだ。本稿では面倒臭い・・・ではなかった、本題ではないた
MEANスタックは破壊的か
最近、MEANがイイという話をチラホラと耳にする。先日も次の記事がはてブで話題になっていた。 MEAN(MongoDB, Express, AngularJS, Node.js)スタックが優れている理由 - Mozilla Open Web Day in Tokyoを終えて - albatrosary's blog この記事の冒頭では、MEANはLAMPに変わる技術として紹介されているが、果たしてそれは正しいのだろうか。（この記事では、LAMPを例にとりつつJavaがどうのという記述があるので、恐らくはLAMPではなく既存のリレーショナルデータベースを用いたアーキテクチャ一般について述べたいのではないかと思う。）MEANについて少し思うところがあるので、今日はMEANの可能性について書き綴っておこうと思う。ただし、私自身MEANスタックと呼ばれるシロモノは使ったことがなく、構造を理解した上
自由でオープンなウェブ終了のお知らせか？またはそれを守るために我々は何をするべきか。
先日、MozillaがブラウザにEMEを採用することを発表してしまった。Mozillaには正直言ってがっかりだ。以前、DRMがウェブに持ち込まれようとしている未だかつてない危機というエントリで危惧していたことが現実になってしまった。フリーソフトウェア財団も今回のMozillaの発表に対して非難の声明を出している。 EMEがブラウザに搭載されるのは、自由でオープンなウェブにとって危機的な状況であると言える。今日はそのことについて警笛を鳴らしたいと思う。 ウェブは自由でオープンだから発展したそもそも、ウェブがこれだけ発展したのは、その仕様が自由でオープンだったからだ。現実にはブラウザごとにクセが強すぎるので半ば笑い話にしかならないが、建前上は互換性はあることになっている。そのため、ウェブページはどのブラウザあるいはOSであっても閲覧することができる。中にはサポートしていないブラウザを拒否するよ
SQLインジェクション対策に正解はない
最近、SQLインジェクションのネタが盛り上がってるようだ。下記のTogetterまとめあたりが震源地だろうか。 「プリペアードクエリが基本だけど、動的に SQL を組み立てる場合もあるから、そういう場合に備えてエスケープも知っておいたほうがいいかも」 - Togetterまとめ まとめを読んだ感想としては、「どちらの意見も間違ってはいない」というものだ。前提あるいは見方が異なるために、見解の相違が生じているだけのように思う。SQLインジェクションについては私も若干思うところがあるので意見を書いておこうと思う。 攻撃を防ぐのは難しいSQLインジェクションをはじめとするセキュリティ対策が難しいのは、ひとつでも穴があると致命的なダメージを受け得るということだ。「どうやって効率よくコードを書くか」とか「コードのメンテナンス性を高めるにはどう書くべきか」みたいな議論とは全く質が異なる議論が必要になっ
SIerは終わっているか
先日、みんな大好きアノニ増田イアリーで、「SIerって終わってんな」という記事が掲載された。これは、「日本のITエンジニアの地位はなぜ低いのか：日経ビジネスオンライン」に対するツッコミ記事である「コーディング技術にこだわり過ぎるとITエンジニアの地位は向上しない - プロマネブログ」に対するさらなるツッコミ記事であり、ここのところこの話の流れはかなりホットなようである。 「SIerって終わってんな」という記事にはどうしても突っ込んでおきたいところがあったので、ここで突っ込んでおくことにする。 問題の箇所はここだ！！どうやって世界と伍して戦う？ どうやって他の製品を上回る？ 微々たる使い勝手の差などは、技術力の差の前では圧倒的に無力だということは データベースはオラクルだのSQLに依存し、製品ではSAPなどに完敗を喫し続けているSIerこそ理解すべきだろう ん？ SQLは言語であってどのRD
IDの設計についてのさらに突っ込んだ議論
今日も前回に引き続きデータベース設計の話をする。今回の話で一旦データベース設計については筆を置くつもり（ブログ書いてないで原稿書けよ＞俺）であるが、その前に話をすっきりさせて置きたいと思う。最後を飾るテーマはIDの設計である。 数字しかないのに意味を含んだID前回のエントリを見ていただいた方から、次のような構造を持った学籍番号があるというフィードバックを頂いた。 全部数値で"入学年度下2桁"+"学科コード"+"学科内のあいうえお順の順位" このようなルールで割り当てた学籍番号を、単なる数値として扱うのであれば大きな問題はない。これは数値しか含まれていないので、SQLのデータ型としては単に数値型を使えば良いだろう。だが、学籍番号から入学年度を判断する、あるいは学科を判断するといった用途で使われるのであればやはり適切ではないといえる。リレーショナルモデルの観点だけからではなく、IDとして適切で
リレーショナルモデルのドメイン設計についての議論
リレーショナルモデルを実践するには、ドメイン（≒データ型）を如何に正しく設計するかということが極めて重要になる。しかしながら、ドメインをどう設計すべきかという議論はあまりされていないように思う。その結果、ドメインについての理解はあまり進まず、データベース設計に失敗しているパターンが多いように思われる。 というわけで今日のテーマはドメインである。 集合を定義するリレーショナルモデルにおけるデータ型とは何か。リレーショナルモデルを実践するにはまずその点から理解する必要がある。 リレーショナルモデルでは、データ型はドメインと呼ばれる。ドメインとは、その属性（≒カラム）に入るべき値はどういったものかを集合として定義したものだ。言い換えると、属性値とはある集合の要素の一つであると言える。従って、ドメインを設計する際には、SQLで言うところのデータ型、つまりINTやCHARといったものだけでなく、その
その選択、ちょっと待った！NoSQLデータベースへ乗り換える前に検討すべき3つのポイント
最近、どうも安易に「NoSQLにすれば厄介なDB設計から開放される」と考えている人が多いように思えて仕方がない。だが待って欲しい。本当にNoSQLと呼ばれるデータベースを使えばアプリケーションの開発・運用の苦しみから逃れられるのだろうか。もちろん「そんなことは無い！！絶対にだ！！」と私は考える。今日はその理由について語ろうと思う。 トランザクション先日、リレーショナルデータベースにおけるDB設計についてセミナーで解説したばかりだが、リレーショナルデータベースにおけるデータの整合性は何もDB設計だけが担保しているわけではない。リレーショナルモデルと同じかそれ以上に欠かせないのがトランザクションだ。 トランザクションがあるおかげで、トランザクション終了後のステータスは「成功」か「失敗」の2つしかないということが保証される。すなわちオール・オア・ナッシングだ。もしトランザクションの途中で何らかの
データベースアプリケーション開発を炎上させる負のスパイラル
毎度おなじみ、はてブのホットエントリに「SIをダメにする負のスパイラル」というタイトルのまとめが掲載された。きしだ氏とはかなり視点は違うものの、開発現場の問題点については少し思うところがあるので意見を書いてみようと思う。と言っても、以下の話の内容はデータベースアプリケーションに限定した話であり、またSIerだけに限った話ではないのでその点はご容赦頂きたい。もちろんSIer各位の案件はデータベースは必須なので、本エントリで触れる問題点には該当するだろう。 Q.なぜ炎上するのか？ A.正しいデータベース設計ができていないから結論から言おう。データベースアプリケーションの開発が炎上するのは正しいデータベース設計ができていないからだ。ここでいう「正しい」とは、論理的に証明できる正しさという意味ではない。「本来こうするべき」といった意味で捉えて欲しい。 「炎上」というのは、例えばテストが通らない、バ
最新鋭のノートPCには欲しいヤツがないので、泣きながら一世代前の機種を購入したという話。
先日、別のエントリでも書いたが、実は最近ノートPCを新調した。以前使っていたものが購入後3年経過し、サポートが切れたからだ。サポートに従事するものとして、やはりサポート期間というものは大事にしなければならない。（ちなみに、以前のマシンも壊れているわけではないので、クッキーを焼いたりするのに大いに役だってくれた。メインマシンが壊れるなど、いざという時にはいつでも活躍できるようスタンバイしてる感じだ。バックアップがあるのはやはり安心である。） というわけで、本日は新しいマシンについて何故これを選択したかという話や、設定などを紹介したいと思う。 外観など今回購入したのはThinkpad W530というモデルである。早速フリーソフトウェア財団のステッカーを貼った。白地のステッカーは黒によく映える。 インテルインサイドやWindowsロゴのステッカーは邪魔なので速攻で剥がした。邪魔者がなくなってスッ
たった30秒でMySQLをコンパイルする方法 rev.2
もう2年以上前になるが、以前「MySQL 5.5をわずか30秒足らずでコンパイルするためのテクニック」というエントリを書いた。 エントリに書いた内容はそれなりにコンパイルの高速化に寄与はするが、実は測定方法は正しくなかった。このことについて、いつも冷静さを失わない奥一穂氏から、いつもの冷静さで指摘を頂いた。 奥さんの言う通りである。指摘をもらってから気がついた。反省した。それからからずっと「まっとうにコンパイルして30秒を切る方法」を模索してきた。そしてついに、ccacheを使わずにまっとうにMySQL 5.5のコンパイルを30秒未満で実行することが出来たので、その方法を紹介しようと思う。 速いマシンを買う いきなり身も蓋もない解決法だが、ぶっちゃけこれが一番効果的である。実行するべき処理が決まっていれば、最終的にCPUの実行速度によって処理時間が決まってしまう。 実は最近PCを新調したの
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
