受託開発とGPL
GPLに対する代表的な誤解・・・というかむしろ謎のひとつに、受託開発（SI）におけるライセンスの扱いがある。この点が明確になっていないため、受託開発において無意味にGPLを回避しようとしたり、GPLに対するFUDを流布することに対する原因になっていたりするように思う。フリーソフトウェアおよびオープンソースソフトウェアを愛する者として、そのような状況は断じて見過ごすことができない！！というわけで、今日はGPLを受託開発（SI）において用いる場合の注意事項を説明しよう。 GPLの使いどころ受託開発においてGPL（とその仲間たち＝LGPL、AGPL）が登場するのは、第三者、つまり発注側でも受託側でもない者が作成したGPLのソフトウェアを利用する場合である。例えばGPLが適用されたライブラリなどだ。周知の通り、GPLのソフトウェアをリンクしたソフトウェアを再配布する場合は、そのソフトウェア全体に対
真の自由とは？フリーソフトウェアにおける究極の選択。CopyleftかPermissiveか。
オープンソースソフトウェアにとって、ライセンスが何であるかというのは非常に大切なことである。なぜならば、ソフトウェアのライセンスの種類によっては、組み合わせることができるものと、そうでないものがあるからだ。ソフトウェアの利用制限がない「自由なライセンス」として有力なものの中には、Copyleftと呼ばれる種類のものとPermissiveと呼ばれる種類のものがある。いずれも、フリーソフトウェアライセンスとして定義されているライセンス形態であり、Copyleftで代表的なものにはGPL（GNU Public License）、Permissiveの代表格としてはBSDLやMIT Licenseなどが挙げられる。これらは一体全体どちらが真に自由をもたらすソフトウェアライセンスなのであろうか？ CopyleftライセンスGPLでは「ソフトウェアの自由」を以下のように定義して、これが守られるようにC
オトコの生きる道
2008年初頭に、MySQL ABがSunに買収されて非常に驚いた。400人弱の会社を10億ドル（1000億円程度）で買収するという破格の買収劇だった。単純計算でいうと、一人頭2.5億円で移籍したわけである。そして俺もその400人の中に含まれていた。。。 MySQL ABは素晴らしい職場だった。Sunに買収されてから現在に至るまでも、Sun自体の業績が良くなかったために人員の増加が出来ない（超忙しいヨ！）といった問題はあったものの、基本的にはMySQL ABと同じ労働環境を維持することができた。MySQLサポートチームの同僚は世界中に住んでいて、仕事を始めると社内のIRCにログインして挨拶を交わし、電話とPCとインターネットさえあればどこでも仕事をすることが出来た。（だから殆どが在宅勤務である。）そして同僚の技術レベルが素晴らしく高かった。早いときには30分以内にソースコードを確認して回答
やってはいけない!!MySQLに悲鳴をあげさせる10の方法
いつも「MySQLを使うときはこうするべき」という観点から記事を書いているが、今日は逆に犯してはいけない過ちをリストアップしようと思う。 1. 全てのカラムにインデックスをつけるデータベース初心者がもっともやってしまいがちな間違いはコレではないだろうか。インデックスはいい。検索がとても速くなるから。しかし、それと引き替えにインデックスは更新するときにコストがかかるし、その分多くのディスクスペースを消費する。特に更新にかかるコストは時に甚大で、該当するインデックスのページがキャッシュ上にない場合はディスクからいったんそのページを読み込まなければいけない。ディスクアクセスは動作にとても時間がかかるので、インデックスが多数、例えば全てのカラムに付いていたりすると「あれ？固まったか？」というような状態になってしまうことがあるだろう。インデックスは必要なカラムにだけつけるようにテーブルを設計しよう。
MySQLのEXPLAINを徹底解説!!
以前、MySQLを高速化する10の方法という投稿で「EXPLAINの見方についてはいずれ解説しようと思う」と書いてしまったので、今日はその公約？を果たそうと思う。 MySQLのチューニングで最も大切なのは、クエリとスキーマの最適化である。スキーマの設計は一度決めてしまうとそのテーブルを利用する全てのクエリに影響してしまうためなかなか変更することは出来ないが、クエリはそのクエリだけを書き直せば良いので変更の敷居は低い。そして遅いクエリをなくすことは、性能を大幅に向上させるための最も有効な手段である。従って、アプリケーションの性能を向上させたいなら、まず最初にクエリのチューニングを検討するべきなのである。 最適化するべきクエリはスロークエリログやクエリアナライザで見付けられるが、ではそのようなクエリが見つかった場合にはどのように最適化すればいいのか？そのためにはまず現在どのようにクエリが実行さ
なぜMySQLのサブクエリは遅いのか。
よくMySQLはサブクエリが弱いと言われるが、これは本当だろうか？半分は本当で半分は嘘である。MySQLのサブクエリだってなんでもかんでも遅いわけではない。落とし穴をしっかり避け、使いどころを間違えなければサブクエリも高速に実行できるのである。今日はMySQLがどんな風にサブクエリを実行し、どのような場合に遅いのかということについて説明しよう。 EXPLAINで実行計画を調べた際に、select_typeにはクエリの種類が表示されるのだが、代表的なサブクエリには次の3つのパターンがある。 SUBQUERY DEPENDENT SUBQUERY DERIVED 結論から言おう。遅いのは2番目、DEPENDENT SUBQUERYである。DEPENDENT SUBQUERYとはいわゆる相関サブクエリに相当するもので、サブクエリにおいて外部クエリのカラムを参照しているサブクエリのことである。そし
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
