珍しい病気にかかってあれこれ考えた話。
最近、とても珍しい病気を患った。プライベートな話で恐縮だが、そのことで色々と思うことがあるので綴ってみようと思う。 ことのはじまりちょうど今月の初めごろだが、突如として全身の筋肉や関節が痛くなった。特に激しい運動をした覚えはないのだが、なにやら筋肉痛のように痛い。いや、もっと痛い。そのような症状が手、足、肩、腰などに広がり、歩行すら困難な状態になってしまった。熱はない。インフルのような悪寒もない。何故かくるぶしから膝にかけて湿疹のようなものが出て痒かった。まいったな、痛みに加えて皮膚もやられたのかよ・・・などと考えていた。 痒みはともかく痛くて仕方がないので、近所の急患センターへ行って観てもらったが分からない。一見するとリウマチのような症状だが検査しないと分からない。急患センターでは分からないので大きな病院で診てもらったほうがいいとのことで、大学病院（自治医科大学附属病院）のリウマチ・アレ
なぜリチャード・ストールマンはオープンソースを支持しないか
「リチャード・ストールマンはオープンソースを支持しない。」なんていうと、オープンソースにあまり詳しくない人はギョッとするかも知れない。ギョッとした人は是非このエントリを読んで欲しいと思う。 我らがリチャード・ストールマン（敬称略）はGNU宣言を発表してフリーソフトウェア運動を始めた偉人である。そう、リチャード・ストールマンが支持するのはフリー（自由な）ソフトウェアであってオープンソースではないのだ。なんだか似たような感じがするし、恐らくオープンソースとフリー（自由な）ソフトウェアを明確に区別している人はほとんど居ないだろう。オープンソースと言う語をはじめて公式に発表したブルース・ペレンズも「フリーソフトウェアとオープンソースは実質的に同じものを指す」なんて言っちゃってるぐらいだ。だけどリチャード・ストールマンは二つを明確に区別し、あくまでもフリー（自由な）ソフトウェアを支持する立場を貫いて
今私がSandy Bridgeを買わない理由
Sandy BridgeとはNehalemに続くインテルの新しいアーキテクチャの名称である。方々でも報じられているように、Sandy BridgeアーキテクチャCPUの性能は素晴らしいようだ。（例1、例2）素晴らしい性能を見て購入を検討している方も、すでに購入してしまった方も大勢いらっしゃるだろう。だが、それでも筆者は絶対にSandy Bridge CPUを買うことはないだろう。なぜならば、Sandy Bridgeには我々の自由を脅かす2つの恐るべき機能が組み込まれているからだ！ Intel Insiderまず問題なのが、Intel Insiderと呼ばれるDRM技術である。インテルは、この機能をハリウッドの要請を受けて追加したらしく、「安全に高解像度の動画をストリーミングするための技術」だそうだ。ハリウッドから高解像度の動画が流出するのを防ぐコピー対策技術、まさにDRM技術なのである。
なぜデジタルコンテンツが売れないか？ビジネスモデルがダメか
ドワンゴ会長の川上氏であると噂されている（？）kawango氏が、ブログで次のようなエントリを綴っている。 なぜデジタルコンテンツが売れないか？DRMがダメか - はてなポイント３万を使い切るまで死なない日記 興味深いエントリなので皆さんにも読んでみていただきたいが、時間のない人のために要約すると話の骨子はこうだ。「日本で今コンテンツビジネスの売上高は凄いが、それはガラケーでDRMがうまく機能しているからだ。スマフォが台頭するとコンテンツビジネスがダメージを受けるので、DRMの代わりになるクラウド型のコンテンツサービスを構築せねば！」 正直意味が分からない。そのようなコンテンツサービスがあったところで誰が利用するのか謎である。DRMつきの楽曲ファイルよりもさらに不便なのだから。 今日は、kawango氏に目を覚ましてもらいたい一心で、何故そのサービスがいけないかということについて論じてみよ
公園で青少年健全育成条例について考えた。
俺には幼い息子が一人居る。最近、休日はちょくちょく栃木県壬生町にある「とちぎわんぱく公園」に出かけて一日中息子と過ごすことが多い。わんぱく公園ではヤギが飼育されており、柵ごしに子供たちがそのへんに生えてる葉っぱなどをあげられるようになっている。そこでちょっとした発見があったのでブログにしたためておこうと思う。 ヤギの気持ちはヤギにしか分からないヤギに葉っぱをあげるなら、多くの人が青々とした新鮮なものを選ぶのではないかと思う。小市民たるこの筆者も当然のごとく青い葉っぱを選んで息子に「これ食べるんじゃないか？」と言って渡した。だが、いくら息子が柵の前に葉っぱをさし出してもヤギは一向に食べようとしない。それどころか、ヤギは一心不乱に足元にあるものをゴソゴソと食べている。何を食べているのだろうと覗き込んだところ、そこにあったものはなんとカサカサに乾燥して茶色くなった枯葉だった！ 我々が枯葉などを食
出来る漢になるための唯一無二の階段
はてなのホッテントリで話題になっている「仕事がデキる人」と「仕事をする人」の違いと習慣 / Keep Crazy;shi3zの日記」という記事を見て凄い違和感を覚えたので思わず筆をとってしまった。ネタバレ注意なので、まずは元記事を読んでから本エントリに移っていただきたい。 一見もっともらしい意見のようだが・・・結論から言おう。 単に与えられた命令を淡々と実行するのは当たり前。それは「仕事をしてる」ことにはなっても、「仕事がデキる」ということではない。 では「仕事がデキる人」と「仕事をしてる人」の違いはどこにあるだろうか。 僕はこれを「先読み能力」の違いだと思った。 仕事で先を読むなどということに挑戦するのはまったくの無駄骨にしかならない。 そもそも、ルーチンワークでもない限り、物事の先を読むというのは非常に難しいか、もしくは不可能である。ルーチンワークであれば段取り通りに仕事を進めていくだ
受託開発とGPL
GPLに対する代表的な誤解・・・というかむしろ謎のひとつに、受託開発（SI）におけるライセンスの扱いがある。この点が明確になっていないため、受託開発において無意味にGPLを回避しようとしたり、GPLに対するFUDを流布することに対する原因になっていたりするように思う。フリーソフトウェアおよびオープンソースソフトウェアを愛する者として、そのような状況は断じて見過ごすことができない！！というわけで、今日はGPLを受託開発（SI）において用いる場合の注意事項を説明しよう。 GPLの使いどころ受託開発においてGPL（とその仲間たち＝LGPL、AGPL）が登場するのは、第三者、つまり発注側でも受託側でもない者が作成したGPLのソフトウェアを利用する場合である。例えばGPLが適用されたライブラリなどだ。周知の通り、GPLのソフトウェアをリンクしたソフトウェアを再配布する場合は、そのソフトウェア全体に対
MySQL管理者最速マスター
巷ではプログラミング言語の最速マスターが流行ってるので、MySQLも参戦。ただし管理者向け。 まずはダウンロードとインストールダウンロードサイト http://dev.mysql.com/downloads/ バイナリにはインストールパッケージ（Windows=MSI、Mac=DMG、Linux=RPMとか）とアーカイブ（*NIX=tar.gz/Windows=zip）があるけど、初心者は黙ってパッケージをチョイス。インストールはウィザードに従うだけ。英語だけどそこはガマン！ パッケージリポジトリがあるOSを使ってるなら、リポジトリからインストールするのもありだ。例えば、 shell> sudo yum install mysqlとか shell$gt; sudo apt-get install mysqlとか。これは楽チンだけどMySQLのバージョンがちょっと古くなるので注意。 もちろん
memcachedの驚愕の事実。
MixiやFacebook、Wikipediaなど、大規模なサイトでmemcachedを利用する例が増えている。マイコミジャーナルのレポートでFacebookの事例紹介があるのだが、なんとmemcached用のサーバは805台で、メモリ容量は15TBにもなるそうだ。ディスクではなくメモリだけで15TB！である。アクティブユーザーの数は7000万人もいるそうだから、それを捌くとなるとハードウェアも凄い規模にならざるを得ないのである。 このように大規模サイトを支えるmemcachedであるが、そのプログラムの中身は一体いかなるものなのであろうか。memcachedはhttp://www.danga.com/memcachedでソースコードが配布されている。現時点での最新版は1.2.5である。ぜひダウンロードしてみてほしい。そしておもむろにファイルサイズを確認してみてほしい。するとあることに気づ
SQLインジェクションとは何か？その正体とクラッキング対策。
世間では、今Gumblar祭りが勃発中であり、SQLインジェクションがニュースに出てくることは少なくなったが、だからと言ってSQLインジェクションの脅威がなくなったわけではない。SQLインジェクションはGumblarを仕掛ける手段としても利用されることがあり、Webアプリケーションを提供する全ての人にとって、対策を講じなければいけない驚異であることに変わりはない。SQLインジェクションという攻撃手法が認識され、大いに悪用されているにも係わらず、その本質に迫って解説している記事は少ないように思う。従来のWeb屋だけでなく、今やアプリケーション開発の主戦場はWebであると言っても過言ではなく、そういう意味ではSQLインジェクションについて理解することは、全てのプログラマにとっての嗜みであると言えるだろう。 というわけで、今日は改めてSQLインジェクションについて語ってみようと思う。 SQLイン
MySQLに纏わる10の都市伝説
誰の口から飛び出したのかは定かではないが、巷ではMySQLにまつわる様々な「都市伝説」がまことしやかに囁かれているようだ。恐らくMySQLに対する理解が低い人や、MySQLがあまり好きではない面々によってFUDっぽく言われているのだと思うが、世の中にはそのような「都市伝説」を真に受けてしまう人が居るのもまた事実であである。MySQLにおける昨今の開発スピードには目覚ましいものがあり、MySQLは性能・安定性・使い易さ共に進化し続けている。（特に先日リリースされたMySQL 5.5は性能・安定性・使い易さを両立している優れたバージョンだ！！）しかし「都市伝説」で語られることは総じて「MySQLはダメな子ちゃん」であるという烙印を押すものばかりであり、MySQLerとしてはそのような言われ無き汚名を全身全霊をもって晴らさなければならない使命を背負っている。そこで、今日はMySQLについて語られ
サポートエンジニアが経験から語る、論理的文章によるコミュニケーションのススメ
俺はこれまで一貫してIT業界でエンジニアとしてのキャリアを進んできたのだが、これまでのキャリアでもう一つ一貫していることがある。それは、ずっとサポートエンジニアであるということだ。実はサポート職というのはかなり論理的なコミュニケーションを必要とする職種であり、如何に論理的な文章を上手に書くかということが、如何に良い仕事をするか（短い時間で成果＝顧客満足度を得られるか）ということに繋がるという側面がある。（もちろん高い技術力が必要なのは言うまでもないが。）サポートエンジニアはメールや報告書という形で日々論理的な文章を書かなければならないので、サポートの経験を重ねることによって論理的にコミュニケーションをする能力というのは徐々に磨かれよう。しかし、論理的にコミュニケーションをするというのは意外と皆出来ているようで出来ていないし、筋が悪いといつまで経っても身につかないこともあり、上手にお客さんを
MySQL Clusterカーネルの中身を覗いてみよう。
MySQL Clusterのデータノードであるndbd（もしくはndbmtd）プロセスは、内部的にはマルチプルステートマシン（ブロック）がシグナル（もしくはメッセージ）を交換するという構造になっており、高い同時実行性を実現しているということについては前回述べた通りである。今日は、ndbd内部にどのようなカーネルブロックが存在するかということについて大まかに説明しよう。前回の話を踏まえて読んで頂ければ、何となくイメージだけでも掴めるのではないかと思う。まずは次の絵を見て頂きたい。これは俺の脳内から引っ張り出したndbdの構造のイメージ図である。 矢印はブロック同士の相関関係（シグナルの送受信など）を示すのだが、この絵に描かれているものは非常に省略されたものであり、実際にはもっと複雑に絡み合っているのだということを覚えておいて欲しい。例えばQMGRやDBDICTといったブロックは、他のブロック
限界までMySQLを使い尽くす!!
どこまで出来るか?!やれるところまでやってやるぜ!!と、威勢が良いのは若い間だけの話。オトナのオトコは、攻めるときはとことん攻めるが自らの限界もわきまえて賢く振る舞うのがスマートってものである。というわけで、今日はMySQLのいろいろな限界についてまとめてみる。皆さんも是非MySQLの限界を知り、MySQLをもっとスマートに使って頂きたい。 SQL文の最大長 MySQLサーバーが実行出来るSQL文の最大長は、max_allowed_packetシステム変数で表される。max_allowed_packetの最大値は1GBである。max_allowed_packetの値はセッションごとにも設定可能なので、デフォルトではそこそこの値（16MBなど）に設定しておいて、必要に応じて大きな対を使うと良いだろう。 データベースの個数 データベースオブジェクトの個数に制限はない。データベースオブジェクトは
やってはいけない!!MySQLに悲鳴をあげさせる10の方法
いつも「MySQLを使うときはこうするべき」という観点から記事を書いているが、今日は逆に犯してはいけない過ちをリストアップしようと思う。 1. 全てのカラムにインデックスをつけるデータベース初心者がもっともやってしまいがちな間違いはコレではないだろうか。インデックスはいい。検索がとても速くなるから。しかし、それと引き替えにインデックスは更新するときにコストがかかるし、その分多くのディスクスペースを消費する。特に更新にかかるコストは時に甚大で、該当するインデックスのページがキャッシュ上にない場合はディスクからいったんそのページを読み込まなければいけない。ディスクアクセスは動作にとても時間がかかるので、インデックスが多数、例えば全てのカラムに付いていたりすると「あれ？固まったか？」というような状態になってしまうことがあるだろう。インデックスは必要なカラムにだけつけるようにテーブルを設計しよう。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
