漢(オトコ)のコンピュータ道: ダウンロード違法化の審議について一言言っておく
ライセンス違反の静止画像のダウンロードを違法化しようという法律の審議が行われているらしい。 海賊版静止画のＤＬ規制を 文化審議会が意見まとめる：朝日新聞デジタル はっきり言って、これは由々しき事態である。インターネットの利用に大きな制約をかけ、日本の文化を破壊するであろう、最悪の法案であると言える。はっきり言って、このような低レベルな話し合いが行われていること自体に私は憤怒している。最近は多忙のため筆を置いていたのだが、久々に筆をとることにした。この法案の問題をしてきしておかねばならないからだ。 技術的に取り締まりは難しい一技術者としてこれだけは言っておきたい。そもそも、ダウンロード側を意図したものだけ上手く取り締まるような技術は存在しない。 まず、ファイルのダウンロードというが、それは範囲が大きすぎる。多くのウェブページには画像が多数埋め込まれているが、基本的にそれらは画像ファイルを特定
MySQLのZero Dateへの対処法
MySQLのZero Dateへの対処法 MySQLの0000-00-00 00:00:00は使ってはならない - そーだいなるらくがき帳 このエントリで、MySQLのゼロが含まれる日付け、いわゆるZero Dateについての問題点が色々挙げられているのを見かけたので、手短に対処法を述べておきたい。 Zero Dateが存在する理由なぜそんな厄介なデータが存在するのかというのは、開発の経緯や互換性といった深淵な理由からなので気にしないで欲しい。まあ、人間は完璧ではないので、人間が作るプログラムも完璧ではないということだ。 当然ながらSQL標準から外れているものは、例外的な使い方をしたい場合を除き、使うべきではない。アンチパターンも使い方次第という話もあるが、例外的な使い方は基本的に苦労が増えるので使うべきではない。 SQLモード実は、Zero DateはSQLモードで禁止できる。SQLモー
データベースについてのそもそも論
先月のはじめのほうで、「リレーショナルデータベースとの上手な付き合い方」というタイトルで、2回発表をした。ひとつは「まべ☆てっく Vol.1」であり、もうひとつは「Hacker Tackle（ハカタクル？）」である。 「リレーショナルデータベースの開発・運用に纏わるもろもろの話をして欲しい」というような内容の話をしてくれないかという同じような依頼を、ちょうど2日違いのイベントで頂いた。9/8のまべ☆てっくと、9/10のHacker Tackleである。そうなると必然的に話す内容も、同じようなものになってくる。同じ人物（＝私）が話すのだから、テーマも同じで時期も同じであれば、内容が同じようなものになるのが自然である。もし違うものになってしまっているのであれば、片方はウソをついているということになるはずだ。今日は発表に使用したスライドを紹介しつつ、なぜデータベースを使うべきなのか（あるいは使う
「PCをWin7のままにしておきたいのに強制的にWin10にするMSが嫌だ！Linuxに行く！」という方へLinuxユーザーとして言っておきたいこと
「PCをWin7のままにしておきたいのに強制的にWin10にするMSが嫌だ！Macに行く！」という方へMacユーザーとして言っておきたいこと という記事を見かけたので、Linuxデスクトップユーザーからも一言だけ言っておく。 結論から。 「悪いことは言わないからやめておけ！」 以前、いますぐWindowsを捨ててデスクトップでGNU/Linuxを使う10+の理由というエントリを書いたことがあるので、使っちゃいけないみたいなことを書くと、「おいおい、いまさら何言ってんだよ」と思われる方も居るかも知れない。だが、以前のエントリの主旨は「GNUのWindows移植版であるCygwinを使うぐらいだったらGNU/Linuxはいかが？」という提案をするためのものであり、いわばCygwinを使うようなIT技術者向けのメッセージである。Cygwinが必要だということは、UNIXライクなツール群を必要とす
残業は悪か？あるいは日本人の生産性が低い最大の理由
最近、残業をするのは社員が悪いというような記事を見たので、一言言っておこうと思う。 残業常習者が会社を壊す｜トンデモ人事部が会社を壊す｜ダイヤモンド・オンライン なぜ残業が常習化するか 最初に結論を言ってしまうと、経営が悪いからだ。経営と言っても事業戦略ではなく、組織運営という意味での経営だ。残業が常態化しているということは、組織運営ができていないことの証拠だと言っていいだろう。 なぜ残業の常態化が経営の失敗だと言えるのか。残業が常態化しているということは、組織がこなすべき仕事に対して人員が足りないことが原因として上げられる。人材の確保に失敗しているのは、経営側の失敗だ。 もし社員がダラダラと残って働いているのだとしたら、社員が何をすべきかということがトップダウンで明確に指示されていない兆候かも知れない。何をもってその日の業務が終わりだ判断とすれば良いのか。それは上司からの指示、つまり担当
MySQL・PostgreSQLユーザーグループ（MyNA・JPUG）合同DB勉強会で発表した資料を公開しました。「データモデルについて知っておくべき7つのこと 〜NoSQLに手を出す前に〜」
表題の通り、MyNAとJPUGの合同DB勉強会で発表をしたので資料を公開した。 内容の詳細はスライドそのものを見ていただくとして、言いたいことの主旨はこうである。世の中に完璧なデータモデルはないので、NoSQLは当然の如く必要になる。だが、何でもかんでもNoSQLを使えば良いというものではない。むしろアプリケーションが必要としているデータモデルが何かということをよく理解し、本当に必要な場合にこそ、NoSQLを使うべきなのである。つまり「ご利用は計画的に！」ということだ。 大切なのは、様々なデータモデルを理解し、アプリケーションにとってベストな製品を選択するということだ。ベストなのがRDBかも知れないし、そうでないかも知れない。最適なデータモデルを選択した場合に、出来上がったものの性能も最高になるし、開発効率も最も良くなる。データベースの主流はRDBだが、それはリレーショナルモデルがカバーで
書籍出版のお知らせ：理論から学ぶデータベース実践入門 ~リレーショナルモデルによる効率的なSQL
来る2月27日、データベースの新書籍を発売させて頂くことになった。タイトルは「理論から学ぶデータベース実践入門 ~リレーショナルモデルによる効率的なSQL」となっている。単に「データベース」と書いてあるが、RDBがメインのテーマの書籍である。 多くの人が未だにRDBを使いこなせていないのではないか。RDBの使い方をマスターするには何が必要なのか。それがここ数年私が追ってきたテーマであり、この書籍を出すことになった動機である。 あまりにも酷いDB設計、あまりにもスパゲティなクエリ、あまりにも希薄なデータモデルへの理解。そういった問題はどこから生み出されるのか。そのひとつの結論としてたどり着いたのが、「そもそもRDBの使い方があまり理解されていないのではないか」ということだった。名著、SQLアンチパターンでは「やってはいけないケース」について学ぶことができるが、その反対のテーマ、つまり本来どの
MySQLレプリケーションの運用が劇的変化！！GTIDについて仕組みから理解する
メリークリスマス！！やあ、良い子のみんな！！サンタクロース・・・ではなく、ヒゲモジャギークからのクリスマスプレゼントだよ！！ というわけで、MySQL Casual Advent Calendarの25日目である。今朝Advent Calendarを覗いてみると、本日分のエントリーが無かったので、急遽書くことにした。Advent Calendar最後の日、クリスマスを飾る記事のテーマはGTIDだ。 前回の投稿では、MySQL 5.6の目玉機能として、レプリケーションがクラッシュセーフになったことを挙げた。レプリケーションまわりで言えば、もうひとつ外せない目玉機能がある。それがGTID（Global Transaction ID）である。 GTIDは良くも悪くもレプリケーションの運用を変化させる。GTIDを使うことによって得られる最大のメリットは、CHANGE MASTER TOでバイナリロ
特許制度が破綻していることを示す最近の2例
最近、特許関連で興味深い2つのニュースが流された。本ブログでは、これまでにも書籍「＜反＞知的独占」の書評などで特許が如何に害悪であるか、社会にとって不必要なシステムであるかを述べてきたが、2つのニュースはそれを裏付けるような内容だった。 Amazon Technologies, Inc.による写真撮影の特許 Amazonが写真撮影の手法を「発明」したとして特許を取得したことが判明 - GIGAZINE この特許は、商品の写真を撮影するときに照明の角度などを工夫することで綺麗に撮れるというものだ。 引用：撮影の場合には、メインストロボ(107)やリア照明(115/117/119/121)や遮光板(131/133)、遮光カーテン(108)などを組み合わせることとされています。 という事らしいが、こういった機材を使うのは商品の写真撮影では極めて自然なことではないだろうか。上記のニュースには続きが
ホワイトカラーの生産性を上げる方法
先日、新「労働時間制度」創設へ検討指示 NHKニュースという記事（魚拓）が上がった。この記事を読む限りでは、政府はホワイトカラーの人たちの生産性を向上させるために新労働時間制度を創設しようとしているように見える。だが待って欲しい。労働制度を変えることで本当に生産性が上がるのだろうか。今日は、政府が行なっている議論の問題点についての指摘と、本当にホワイトカラーの生産性を上げる方法について考察してみよう。 政府は論点がずれている。なぜならば、結論ありきだから。まず、新労働時間制については次のように職種を限定した議論が行われているように見受けられる。 そして具体的な業種や業務について、経営企画や新商品の開発、海外プロジェクトなどを担うリーダー、それにＩＴや金融関連のコンサルタント、資産運用を行うファンドマネージャー、経済アナリストなどを挙げています。 一方、田村厚生労働大臣は年収が数千万円に上る
一般の職務で残業代を０にしてはいけない理由。あるいは０にするための要件。
｢ヒラ社員も残業代ゼロ｣構想の全内幕という記事が注目を集めている。そこでは、経産省の役人と経団連の間で、残業代ゼロ政策についてどのような駆け引きがあったかということが赤裸々に語られており、中でも竹中平蔵氏の「アーティストは残業代ゼロなんですよ。」という発言が特に目を引く。アーティストと一般の雇われ労働者を同一視するというのは愚の骨頂としか言いようがない。 朝日新聞の記事によると、方向性は大幅に修正され、幹部候補だけが対象となったようだ。だが油断はならない。経団連は労働者から搾取しようと手ぐすねを引いて待ち構えているからだ。今日は残業代ゼロの何が問題なのかについて語りたいと思う。 成果？それとも時間？残業代ゼロの何が問題なのかについて、まず結論から言おう。一般的な雇われ労働者は、時間的に拘束されることがその職務の一部になっているからだ。 アーティストは確かに残業代は出ないかも知れない。しかし
SIerは終わっているか
先日、みんな大好きアノニ増田イアリーで、「SIerって終わってんな」という記事が掲載された。これは、「日本のITエンジニアの地位はなぜ低いのか：日経ビジネスオンライン」に対するツッコミ記事である「コーディング技術にこだわり過ぎるとITエンジニアの地位は向上しない - プロマネブログ」に対するさらなるツッコミ記事であり、ここのところこの話の流れはかなりホットなようである。 「SIerって終わってんな」という記事にはどうしても突っ込んでおきたいところがあったので、ここで突っ込んでおくことにする。 問題の箇所はここだ！！どうやって世界と伍して戦う？ どうやって他の製品を上回る？ 微々たる使い勝手の差などは、技術力の差の前では圧倒的に無力だということは データベースはオラクルだのSQLに依存し、製品ではSAPなどに完敗を喫し続けているSIerこそ理解すべきだろう ん？ SQLは言語であってどのRD
DB設計の難しさ
今日は徒然なるままにDB設計について思っていることを並べてみようと思う。 ようやくWEB+DB Pressの次号の原稿を書き終えた。2年間の連載であるが、来年はプライベートが忙しくなる予定なので、連載はこれにて終了とさせてもらうつもりである。 「なぜ人はリレーショナルデータベースを使いこなせないのか」 このところ執筆や講演を通じてリレーショナルモデルについて説明する機会を色々頂いているが、それらの活動の根源となっているのが、この素朴な疑問である。その疑問をパワーにしてこれまで活動を行なってきた。 現時点での自分の回答は「データベース設計が難しいから」である。もちろんリレーショナルモデルそのものの難しさというのもあるが、それよりは「適切な使い分けができていない」ということが大きいように思う。言葉を変えると、リレーショナルモデルを適用すべきデータとそうでないデータの判断ができていないからDB設
SQLインジェクション対策に正解はない
最近、SQLインジェクションのネタが盛り上がってるようだ。下記のTogetterまとめあたりが震源地だろうか。 「プリペアードクエリが基本だけど、動的に SQL を組み立てる場合もあるから、そういう場合に備えてエスケープも知っておいたほうがいいかも」 - Togetterまとめ まとめを読んだ感想としては、「どちらの意見も間違ってはいない」というものだ。前提あるいは見方が異なるために、見解の相違が生じているだけのように思う。SQLインジェクションについては私も若干思うところがあるので意見を書いておこうと思う。 攻撃を防ぐのは難しいSQLインジェクションをはじめとするセキュリティ対策が難しいのは、ひとつでも穴があると致命的なダメージを受け得るということだ。「どうやって効率よくコードを書くか」とか「コードのメンテナンス性を高めるにはどう書くべきか」みたいな議論とは全く質が異なる議論が必要になっ
IDの設計についてのさらに突っ込んだ議論
今日も前回に引き続きデータベース設計の話をする。今回の話で一旦データベース設計については筆を置くつもり（ブログ書いてないで原稿書けよ＞俺）であるが、その前に話をすっきりさせて置きたいと思う。最後を飾るテーマはIDの設計である。 数字しかないのに意味を含んだID前回のエントリを見ていただいた方から、次のような構造を持った学籍番号があるというフィードバックを頂いた。 全部数値で"入学年度下2桁"+"学科コード"+"学科内のあいうえお順の順位" このようなルールで割り当てた学籍番号を、単なる数値として扱うのであれば大きな問題はない。これは数値しか含まれていないので、SQLのデータ型としては単に数値型を使えば良いだろう。だが、学籍番号から入学年度を判断する、あるいは学科を判断するといった用途で使われるのであればやはり適切ではないといえる。リレーショナルモデルの観点だけからではなく、IDとして適切で
リレーショナルモデルのドメイン設計についての議論
リレーショナルモデルを実践するには、ドメイン（≒データ型）を如何に正しく設計するかということが極めて重要になる。しかしながら、ドメインをどう設計すべきかという議論はあまりされていないように思う。その結果、ドメインについての理解はあまり進まず、データベース設計に失敗しているパターンが多いように思われる。 というわけで今日のテーマはドメインである。 集合を定義するリレーショナルモデルにおけるデータ型とは何か。リレーショナルモデルを実践するにはまずその点から理解する必要がある。 リレーショナルモデルでは、データ型はドメインと呼ばれる。ドメインとは、その属性（≒カラム）に入るべき値はどういったものかを集合として定義したものだ。言い換えると、属性値とはある集合の要素の一つであると言える。従って、ドメインを設計する際には、SQLで言うところのデータ型、つまりINTやCHARといったものだけでなく、その
ナチュラルキーとサロゲートキーについての議論
とあるブログエントリで「ナチュラルキーを主キーにしてはいけない」という主張を見かけたのでこれに反論しておく。これはリレーショナルモデル的には明らかに間違った考えだからだ。 リレーショナルモデルにあるのはナチュラルキーだけリレーショナルモデルには「サロゲートキー（代理キー）」という概念はない。まずこの点に注意して頂きたい。サロゲートキーとは、データベースアプリケーション開発において実用上必要とされる機能であって、本質的には不要のものである。リレーショナルモデルでは、いわゆるナチュラルキーというものがあれば機能的には十分だからだ。 そのためにはまず「キー」という概念が何を指し示すかということについて正しく理解しなければならない。リレーショナルモデルではキーと呼ばれるものは候補キーとスーパーキーという2つの概念だけである。「タプル（≒行）の値を一意に決定することができる属性（≒カラム）の集合」の
ヒゲモジャのギークが提案する技術習得戦略
先月、Dbtech Showcaseで松信さんがデータベース技術の羅針盤という講演をされた。残念ながらプレゼンそのものを観に行くことはできなかったが、その前の日に松信さんと一緒に昼飯を食べたとき、講演のあらすじについては伺っていた。その際にも同じようなことを松信さんには言ったのだが、スライドを見直した上で改めて自分の意見をまとめておこうと思ったので筆をとることにする。 なお、このエントリではスライドに書かれているトピックについて語るので、まだ松信さんのスライドを見てない人は先にスライドに目を通してから本エントリを読んで欲しいと思う。結論は全く違った方向に進んで行くが、その点は了承して頂きたい。 あなたに選択肢はあるか？ひと握りの天才なら自分の興味のある分野を開拓することができるだろう。あるいはすでに成功を収めた人であれば転職に困ることはないので、成功しそうな会社に乗り換えることもできるだろ
その選択、ちょっと待った！NoSQLデータベースへ乗り換える前に検討すべき3つのポイント
最近、どうも安易に「NoSQLにすれば厄介なDB設計から開放される」と考えている人が多いように思えて仕方がない。だが待って欲しい。本当にNoSQLと呼ばれるデータベースを使えばアプリケーションの開発・運用の苦しみから逃れられるのだろうか。もちろん「そんなことは無い！！絶対にだ！！」と私は考える。今日はその理由について語ろうと思う。 トランザクション先日、リレーショナルデータベースにおけるDB設計についてセミナーで解説したばかりだが、リレーショナルデータベースにおけるデータの整合性は何もDB設計だけが担保しているわけではない。リレーショナルモデルと同じかそれ以上に欠かせないのがトランザクションだ。 トランザクションがあるおかげで、トランザクション終了後のステータスは「成功」か「失敗」の2つしかないということが保証される。すなわちオール・オア・ナッシングだ。もしトランザクションの途中で何らかの
DBエンジニアのための技術勉強会で発表したスライドを公開しました。
DBエンジニアのための技術勉強会というイベントで、リレーショナルモデルにおけるDB設計について話す機会を頂いた。リレーショナルモデルは非常に重要であるにも関わらず、現場ではないがしろにされてしまっている。その結果、アプリケーションのロジックを上手くクエリで表現できず、開発現場では非効率な開発が行われ、多くの人がデスマ的な状況に追い込まれている。そういう危機意識について、これまで何度か本ブログでも書いてきたし、WEB+DB Pressで連載している動機もその点にある。リレーショナルデータベースはやはりリレーショナルデータベースとして使うべきだ。そのための鍵となるのが、DB設計である。 今回はなんと約2時間の持ち時間を頂いた。リレーショナルモデルについてはこれまで何度か話す機会を頂いたが、2時間というのは最長記録である。それに合わせてスライドもボリュームたっぷりのものになった。過去のスライドと
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
