5ヶ月前に退職エントリを出してから、いろんな会社さんだったり個人的にだったり、いろんな人と話させてもらった。 blog.kamipo.net みーみちゃん転職(前)祝いだよ🍶 pic.twitter.com/0kdy47mOiw— Ryuta Kamizono (@kamipo) August 28, 2020 みーみちゃん毎日退職祝いだよ🥩 pic.twitter.com/ZDE8tnRRfD— Ryuta Kamizono (@kamipo) September 1, 2020 今日は会食だよみーみちゃん🌾 pic.twitter.com/myLq9gkpxZ— Ryuta Kamizono (@kamipo) September 17, 2020 今日も会食だよみーみちゃん🌀 pic.twitter.com/d5HTVreV0b— Ryuta Kamizono (@kamip

無職になってからのこと書こうと思ったら保険と給付金だけで力尽きました。 ハローワークで求職者登録 だいたいの会社員は雇用主によって雇用保険に加入しており、失業中にはいわゆる失業手当を受給できる。 せっかく保険料払っとるねんから一回ぐらい失業手当もらっとかなあかんなということでハローワーク(公共職業安定所)に通ってる。 ちなみに、ハローワークでいうところの "失業" とは、離職中のひとが "就職しようとする意思といつでも就職できる能力があるにもかかわらず職業に就けず、積極的に求職活動を行っている状態にある" ことをいうそうです。 ところで、失業手当がいくらもらえるのかざっと検索するとだいたい賃金の50～80％ぐらいって出てくるんで、え、そんなもらえたら無職のまま豪遊できてしまうで、と思ったけどそんなうまい話はなかった、基本手当日額には上限が存在していて、僕の場合は基本手当日額7,605円であ

急なお知らせですが、8月31日をもってTreasure Dataを退職することになりました。 今後の活動についてはいまのところなにも決まっていないので、自分になにができるのか、どんなニーズがあるのか、いろいろ相談に乗ってもらえるとうれしいです。 きっかけはというと、長年Railsコントリビューター/メンテナーとして並々ならぬ思いで活動してきたんですが。 どのぐらいがんばっていたかというと、たとえば2020年8月時点のコミット数ベースの今年のアクティビティでいうと、上位10人のアクティビティを母数にするとその半数が僕になります。 rails/rails contributors 2020-01-01 - 2020-08-26 Rails 5.0以降のも置いておきます。 rails/rails contributors 2019-01-01 - 2019-12-31 rails/rails c

仕事やらなんやらでMySQLのクエリの良し悪しを判断する必要があるとき、EXPLAINの内容だけだとどのぐらい良くなったり悪くなったのか分からないので SET long_query_time = 0; してrows_examined (そのクエリでrows_sent行の結果を返すために何行に触ったのか)も一緒に提示するようにしている(少なくともMySQL 5.7時点ではrows_examinedはslow_query_logでしか確認できないはずperformance_schemaが有効ならevents_statements_historyやその仲間たちで確認できるとのこと*1 MySQL :: MySQL 5.6 リファレンスマニュアル :: 22.9.6 パフォーマンススキーマステートメントイベントテーブル)。 例: 上の例のBeforeは、もともとDBAが書いた温かみのあるSQLでO

近況などをブログに書いたことはなかったんですが、4月からTreasure Dataで働くことになりました。 3月に新しい仕事を探してたタイミングでちょうど声をかけてもらって、他に誘ってくれてるところもあっていろいろ考えたんですけど、今まで自分がやってたWeb屋さんとは結構ちがう専門的なプロダクトが面白そうだったこと、話してみてエンジニアリング上の解決したい課題についてすごく具体的にいろいろ話してくれたので、畑違いな気もするけどやれることは結構ありそうだなとイメージできたので入社することにしました。 あとは声をかけてくれるのが2週間遅かったら他のところに決めちゃってたので、お互いのタイミングが合ってたことで自分が想像していなかった選択肢が生まれたことにも面白さを感じて、まあこれも自分の中のひとつのチャレンジだと思って返事をしたという感じです。 HadoopもFluentdもよく分からんしSl

この投稿はMySQL Casual Advent Calendar 2014の5日目の記事です。 @kamipo 質問させてください。このエントリーで COMPRESSED ではなく DYNAMIC を選んでいる理由はなぜですか？あまりDB詳しくないので参考リンクなどポインタを教えていただけるだけでも構いません http://t.co/9sC4lzLjXr— kiyoshi nomo (@kysnm) November 27, 2014 先週ツイッターでInnoDBのことを質問されまして、せっかくなのでアドカレのネタにしようと思いますってことでInnoDBのファイルフォーマット毎の違いをカジュアルに説明しようと思います。 InnoDBのファイルフォーマットBarracudaと新機能 InnoDBにはファイルフォーマットとして昔からあるAntelopeと新しいフォーマット(5年も前からあるの

これはMySQL Casual Advent Calendar 2011 - MySQL Casualの8日目の記事です！ UDFでFizzBuzz id:sugyanさんがストアドプロシージャでFizzBuzzをやっていたのでMySQLのUDF(user-defined function)でもやってみました。 kamipo/mysql_fizzbuzz · GitHub git clone git://github.com/kamipo/mysql_fizzbuzz.git cd mysql_fizzbuzz g++ -shared -fPIC -Wall -g mysql_fizzbuzz.cc -o mysql_fizzbuzz.so cp mysql_fizzbuzz.so /usr/local/mysql/lib/mysql/plugin mysql -u root -e "cr

ISUCON3本選お疲れさまでした！ うちのチームのことはだいたいgfxが書いてる通りなんですけど、おもに僕がやったこととか本選後に振り返ってみたことを書いておきます。 予選後の教訓で、最初にちゃんとコードを読んで方針を決めようって話してたので、最初に全員でざっと構成とかコードとか初期状態でのベンチとか回してみて全体を把握してから昼に作戦会議。 そのときに僕が話した見解は このアプリケーションから何らかの方法で参照時の画像変換のボトルネックを取り除いたとき、次にボトルネックになるのは帯域になる なので理想的な状態から逆算すると5台でWANにトラフィックを吐く構成になってる必要がある 最悪、参照時にまったく変換しなくて済む理想的な高速化に失敗してすべての変更をrevertすることになっても、5台並べて参照時の画像変換して返せるようにできてれば単純に初期状態の5倍のCPUでスケールできるから5

.zshrcにstatic_httpdって関数つくってる。 dotfiles/.zshrc at master · kamipo/dotfiles · GitHub function static_httpd { if type plackup > /dev/null; then plackup -MPlack::App::Directory -e 'Plack::App::Directory->new(root => ".")->to_app' elif type ruby > /dev/null; then if ruby -v | grep -qm1 'ruby 2\.'; then ruby -run -e httpd -- --port=5000 . else ruby -rwebrick -e 'WEBrick::HTTPServer.new(:Port => 5000, :D

もうMySQL 5.5 GAが出てから１年以上が経ち、つい先日とうとうMySQL 5.6 GAも出た昨今、これから先パーソナルユースでこれより以前のMySQLなど使うことはないだろうと~/.my.cnfを書いていたのだけど、昨日ちょっとしたアレでMySQL 5.1を入れたらMySQLが進化しすぎててオプションコメントアウトしまくらないと動かないわーとかいってたらloose-つけるといいですよって教えてもらった。 my.cnfのオプション名の頭にloose-と書いておくと、オプションが存在しなくてもWARNINGでERRORにならずに済みますよー。loose-log-slow-queriesloose-slow-query-logと書くと5.1でも5.5でも使える、みたいな。— ts. yoku (@yoku0825) February 6, 2013 これは知らなかった！ MySQL 5.

当日を振り返った翌日の感想はコチラ。 昨日は藤原組と山形組の抗争に巻き込まれて無残に死んだ #isucon2— Ryuta Kamizono (@kamipo) November 4, 2012 今回もチームやすべえとして@riywoくんに熱烈ラブコールを送ってたんですが、当日は飛行機の上ということで振られてしまったので、それぺちの@do_akiさんとRails高速化の@mirakuiさんまったく接点のない二人を誘って参加しました！ 二人とも突然の誘いを快く受けてくれてありがとうございました！！ 結果はというと、まずクエリのボトルネックをインデックス張ってつぶしたあたりまではよかったんですが、サイドバーのキャッシュの不整合を解決できずDBから引き直そうとしたところで致命的な設計ミスに気づいてしまって、せめて完走させてスコアは出そうってことでgit initした状態に戻してフィニッシュでした

朝からピングドラム観てる場合じゃなかった…。 前回のWordPressに引き続いて今回のMediaWikiも圧倒的なPHPのCPUバウンドなアプリケーションで、PHP 5.4をビルドした人が上位を独占でしたね。 僕はといえば、PHP 5.4ビルドしたら負けかなと思ってnginxのproxy_cacheで動的ページをキャッシュしようと試みてうまくいかず、デバッグしながらHeader unset Cache-ControlしたりHeader unset Expiresしたりしてブラウザからのアクセスはキャッシュできるようになったけど、ベンチマークまわすとキャッシュが生成されないのをsquidとかも試してみたけど解決できず時間切れでした。 結果的にはまたPHP 5.4かよって感じですが、前回はともかく今回の課題はもう一度おなじ条件でやればまったく違う結果になる余地があるいい課題だったんではないか