16周年のお礼 - sakaikの日々雑感～(T)編
1998年2月に会社を設立してから、なんやかんやで、本日16年目の誕生日を迎えました。 「ちょっと助けてよ」「一緒にやろうよ」から、「困ってるなら仕事回すよ」まで、たくさんの方々のおかげで、これまで続けてくることができました。日頃のご愛顧に、心より御礼申し上げます。 なかなか「自分はこれをやるぞ！」というものに向かってまっすぐに突き進むことができず、うようよきょくきょくしていますが、道具や環境などが熟しつつもあり、また、16というキリの良い年でもありますので、なにか「今までと違うことを開始した」と言える年にしたいと思っています。 今後とも、みなさんとおもしろいことをご一緒できることを楽しみにするとともに、困ったときにはお仕事をくださいますよう、お願い申し上げる次第です。 いままでは「一緒に仕事をしたことがある方ならわかる」という部分に頼ってきた部分が多く、受けられるお仕事について敢えて「メ
第68回PHP勉強会でMySQLとセルコのお話をさせていただきました - sakaikの日々雑感～(T)編
PHP勉強会に参加してきました。今回が第68回で、７〜８年目くらいになるそうで、昔よく参加させていただいていたあの勉強会に「久々に」参加した、と言えそうです。 数ヶ月前より何度か、MySQLのお話をするようお誘いをいただいていたのですが、なかなかタイミングが合わずに、今回ようやくお応えすることができました。 http://atnd.org/events/39679 今回はタイミング良く、セルコ4版日本版の発売直後ということもあり、そのお話もさせていただきたかったので、MySQL の話を合わせて豪華2本建て。 20分での予定だったのが、倍くらいしゃべってしまったようです（・・「ようです」というのは、、、素で時計を見ていなかったので、あとからTwitterのログを見て知ったのでした）。 運営の方におかれましては、色々と予定していた段取りが狂ってしまったかと思いますが、ほんと、すいませんすいませ
ファーストサーバ事件に巻き込まれて思うこと - sakaikの日々雑感～(T)編
一部の世間を騒がせている「ファーストサーバ、預かっていたデータを全部消しちゃったぞ事件」。報道で情報が増えるに従って「こんなにいろんな会社が利用していたのか」と驚かされます。もうちょっとしっかりしたサービス会社を利用していてもいいのに、、、と思うような、大会社も含まれています。 私も長いこと、ファーストサーバを利用していました。20日(水)の夕方から、POPメールが取得できないことに気づいたものの、たまにあることなので、すぐに直るだろうと特に気にしていませんでした。 まさかの全消失。 個人的には、もうどうでも良いことではありますが、ライトな契約者のひとりの立場として、記録を残して置いてもいいかな、と思い、本エントリをしたためます。 私のファーストサーバ利用法 いくつかのサービス会社で、いくつかのドメインを運用している中で、ファーストサーバは「お遊び系」という位置づけでした。要するに、公開サ
「楽しむ」それが豊かなエンジニアになるコツ 坂井恵さんのエンジニアライフ（1/2） - 特集：No okyuu, No Life [okyuu.com]
日本MySQLユーザ会の副代表を務める坂井恵さん。技術の現場で会社運営に興味を持ち、独立起業の道を選んだエンジニアだ。「ギークっていうほどの技術好きじゃなくて甘いところがある」と笑うが、何事も「楽しむ」姿勢が同氏のエンジニアライフを豊かにしている。 この企画はokyuu.com編集部が現在のエンジニア像をリレー形式で追っていくものです。 （取材・文＝編集部） 坂井恵（さかいけい） 1971年3月10日生 38歳 アートライ代表取締役 日本MySQLユーザ会（MyNA）副代表 【略歴】 1993年3月 筑波大学第一学群自然学類（化学専攻）卒業 1994年3月 筑波大学理工学研究科中途退学 1998年2月 有限会社アートライ設立 2002年8月 XOOPSに出会いオープンソースの世界へ 2003年 日本MySQLユーザ会スタッフに 主な著書：『XOOPS入門』『MySQL徹底入
PHPカンファレンス2009 第２日目テックデイに参加してきました - sakaikの日々雑感～(T)編
9月5日土曜は PHPカンファレンス２日目。テックデイです。http://phpcon.php.gr.jp/2009 こちらもそれぞれの講演の内容については、Gihyo.jp の「史上最速のイベントレポート」http://gihyo.jp/news/report/01/phpcon2009/0002 を参照ください。ちなみにこのレポート、「最速」の名に恥じぬ「講演終了の概ね３分後にはもう公開されている」という偉業を成し遂げたようです。riaf & wozozo 両名すばらしい！ 台湾のPHPコミュニティ事情 ２日目は朝10:30から開始。でも私の本領発揮。ゆっくりと参上しました(笑)。絶対聞きたかったのが 台湾から今回来てくれた、Taiwan PHP UG の Kiang さんのお話。11:15から。ちょっと遅れちゃった(^^;)。 台湾のマーケットは 2000万人程度。やはりある都市(台
PHPカンファレンス2009 第１日目ビジネスデイに参加してきました - sakaikの日々雑感～(T)編
今年は第10回記念ということで、「ビジネスデイ」と「テックデイ」の２日間の開催でした。http://phpcon.php.gr.jp/2009/ まずはその１日目。詳しい内容は Gihyo.jp の「史上最速のレポート」http://gihyo.jp/news/report/01/phpcon2009/0001 を見ていただくことにして、ここでは私の視点で感じたあれこれを書きつづりたいと思います。 めずらしく開始から参加 だいたいこの手の、自分がスタッフをやっているわけではないイベントには、開始後にのこのこと遅れて参加することが多いのですが、10周年というスタッフの意気込みを感じたからか、珍しく開始前に会場入りしました。 会場は外苑前の日本オラクルさん。すてきな会場で「ビジネスデイ」らしい荘厳な空気さえ感じました。 鈴木さんのオープニング トライコーンの鈴木さんのオープニングの挨拶。体格も
MySQL4.0からのバージョンアップ時のハマリ点〜不正な日付の扱い〜 - sakaikの日々雑感～(T)編
とっくに EOL となっている MySQL 4.0 を未だに使い続けている会社もそれなりにまだあるようです。MySQLは バージョン 4.0 と バージョン 4.1 の間に文字コードの取り扱い変更を含む大きな変更が為されているために、バージョンアップに二の足を踏んでいるという心理があるのでしょう。4.0のままでもちゃんと動いているし！ で、実際にバージョンアップの際に文字コード（文字化け）についてはこれまで多くの書籍や記事などでも喧伝されてきたので、上手にバージョンアップするノウハウも溜まっていると思いますが、もうひとつ意外なハマりどころに「日付の扱い」があります。 （１）MySQL 4.0 では日付のチェックがちょっとルーズ （２）MySQL 5.1 (たぶん 4.1以降）ではちゃんとチェック MySQL 4.0 での日付チェックについてもう少し詳しく説明すると、MySQL 4.0 では
MySQL 5.4 詳細(当社比)情報 - sakaikの日々雑感～(T)編
MySQL 5.4 について以下のURLにかなり詳しい情報が掲載されています。もちろん MySQL 5.4.0-beta 時点での情報ですので「予定は未定」的なものも多いのですが、このフェーズでこれだけのドキュメントがまとめられていることに、先行きの明るさを感じます。 http://dev.mysql.com/doc/mysql-5.4-features/en/index.html で、私エイゴヨメマセーン。 理解した(と自分が思った)とたんにもう忘れているのでメモしないと理解できないのです。 ということで、超訳というか、いやすでに訳じゃないです、妄想ですが、こんなことが書いてありますというメモを作っているので折角なのでここに書いておきます。 書いてないことまで書いてありますので注意。ちゃんとした情報を知りたい方は原文に当たってください。 明らかに意味違うよってところはコメント等で教えてい
あらかじめインデックスカラムでソートしておくことによるINSERT速度の差に関する調査(4)〜InnoDB編 - sakaikの日々雑感～(T)編
昨日の調査結果にあとから追記したのですが、【昨日の調査は MyISAM エンジンでの結果です】！ （図らずもそうなってしまいました(^^;)） ということで InnoDB での追試。諸条件は昨日とまったく同じ。 ただしテーブル生成を行う際に、CREATE TABLE文の最後に ENGINE=InnoDB を追加したのみ、です。 MyISAM の結果を見て「やっぱりソートしておいたほうが速い、なるほどね」と思っていた私には、驚くべき結果がでました。 結果(InnoDB) 件数 unsorted sorted 10,000 0.6173 0.6070 20,000 1.1663 1.3037 50,000 2.9893 2.9497 100,000 6.0137 6.1367 200,000 12.4970 12.8287 300,000 19.8357 19.8163 400,000 2
あらかじめインデックスカラムでソートしておくことによるINSERT速度の差に関する調査(2) - sakaikの日々雑感～(T)編
前回のあらすじ ２カラムを持ち、1カラム目だけにインデックス（プライマリーキー）を作成したテーブルに対して、予め1カラム目の値でソートしたINSERT文群と、ソートしていないINSERT文群を与えて、処理に要する時間を測定した。 INSERT文群の件数は 1万、2万、5万、10万、50万、約58万 を測定。 ソートしていなかったものが 10万から50万の間で大きく時間を要するようになった（ソートしてあるものはそれほどでもない） とりあえず 10万から50万の間がどうなっているのかをもう少し細かく見たいので、20,30,40万について測定を行いたくなった 前回のグラフは以下。 今回の結果 以下のとおりとなった。20万, 30万, 40万件について追試を行い、10万と50万については前回の測定値を使用した。 感想 やっぱりまっとうに（なめらかに）所要時間が増え続けていますね、ソートしていないも
あらかじめインデックスカラムでソートしておくことによるINSERT速度の差に関する調査(1) - sakaikの日々雑感～(T)編
たくさんのデータをINSERTする際の所要時間について思うところがあったので調べてみました。今回のテーマは「インデックス」です。 INSERTする際にINDEXを構築しながらデータを登録していくわけですが、これが予め並んでいれば、INDEX生成にかかる処理負担が減るのではないか、という発想です。シンプルに、以下のテーブルに対して、ランダムな値のINSERT文を生成し、（１）ランダムに発生したままのもの （２）カラム１の値でソートしたもの の２つについて所要時間を計測しました。 テーブルは、2カラムを持ち、1カラム目にプライマリーキーが設定されているだけの非常にシンプルなものです。 CREATE TABLE tb02a ( col1 varchar(128), col2 varchar(128), PRIMARY KEY (col1) ); 件数 1万、2万、5万、10万、50万、58万(
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
