2021年はブログを書くのをがんばろうという話 - かみぽわーる
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
ISUCON10予選ふりかえり - かみぽわーる
ISUCON10予選おつかれさまでした。ISUUMOいい問題でしたね。過去出題側を担当したこともある身でも、参加者の完全攻略に対する怖れもあって仕様が肥大化するなか今回これだけコンパクトな仕様のアプリケーションでこれだけ楽しめる出題をしたのマジですごいと思いました。 今回の問題はMySQLかつ検索ヘヴィな問題で僕のバックグラウンドに向いてる問題にも関わらず、ずっと手を動かしていたわりに効果の高い施策に取り組めず、あらためてISUCONの難しさを痛感したしこれぞISUCONなのだなあと思います。 僕の文章読解が遅く仕様理解にとても時間を要するという性質から、これまでのISUCONでは常にアプリケーションの仕様や性質を理解できる前に時間的制約からあらゆる決断を迫られるという状況にあり、この状況で仕様や性質を理解できていたとしたらできた正しい決断をしていくのは本当に難しいと思っていて、今回ずっと
Treasure Dataを退職します - かみぽわーる
急なお知らせですが、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のクエリの良し悪しはrows_examinedで判断する - かみぽわーる
仕事やらなんやらで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
Treasure Dataに入社しました - かみぽわーる
近況などをブログに書いたことはなかったんですが、4月からTreasure Dataで働くことになりました。 3月に新しい仕事を探してたタイミングでちょうど声をかけてもらって、他に誘ってくれてるところもあっていろいろ考えたんですけど、今まで自分がやってたWeb屋さんとは結構ちがう専門的なプロダクトが面白そうだったこと、話してみてエンジニアリング上の解決したい課題についてすごく具体的にいろいろ話してくれたので、畑違いな気もするけどやれることは結構ありそうだなとイメージできたので入社することにしました。 あとは声をかけてくれるのが2週間遅かったら他のところに決めちゃってたので、お互いのタイミングが合ってたことで自分が想像していなかった選択肢が生まれたことにも面白さを感じて、まあこれも自分の中のひとつのチャレンジだと思って返事をしたという感じです。 HadoopもFluentdもよく分からんしSl
InnoDBのロックの範囲とネクストキーロックの話 - かみぽわーる
この記事はMySQL Casual Advent Calendar 2013 3日目の記事です。 はじめに 以前にSELECT ... FOR UPDATEとロックの挙動 - walf443's blogの記事にTwitterで少し言及したんですが、それの補足というか、InnoDBのロックの範囲について僕はこう理解していますよという話です。 MySQLといえば、InnoDBをネットワークサーバとして使うためのフレームワークであり、SQLはInnoDBのインデックスにアクセスするためのDSLといっても過言ではないでしょう。 InnoDBのロックとはつまるところインデックス行のロックなので、InnoDBのロックの範囲を理解するためにInnoDBのインデックスについて少し前置きしておきます(だいぶ端折ったけど長くなった…)。 クラスタインデックスとセカンダリインデックス すでにInnoDBのイン
優勝したらあの子に告白することばかり考えていた #isucon - かみぽわーる
ISUCON3本選お疲れさまでした！ うちのチームのことはだいたいgfxが書いてる通りなんですけど、おもに僕がやったこととか本選後に振り返ってみたことを書いておきます。 予選後の教訓で、最初にちゃんとコードを読んで方針を決めようって話してたので、最初に全員でざっと構成とかコードとか初期状態でのベンチとか回してみて全体を把握してから昼に作戦会議。 そのときに僕が話した見解は このアプリケーションから何らかの方法で参照時の画像変換のボトルネックを取り除いたとき、次にボトルネックになるのは帯域になる なので理想的な状態から逆算すると5台でWANにトラフィックを吐く構成になってる必要がある 最悪、参照時にまったく変換しなくて済む理想的な高速化に失敗してすべての変更をrevertすることになっても、5台並べて参照時の画像変換して返せるようにできてれば単純に初期状態の5倍のCPUでスケールできるから5
#cross2013 に行ってきた - かみぽわーる
聴いたやつ。 HTML5 x セキュリティ 体系的に学ぶ安全な利用規約の作り方 継続的サービス改善のゲンバのハナシ 継続的システム運用のゲンバのハナシ 感想など 出張Shibuya.XSSでCD-ROMをイジェクトしたくならない人は今すぐ病院に行ってくださいで有名な@hasegawayosukeさんが登壇されるのを楽しみにしていたんですが、ノロで口からイジェクトしまくって欠席されたみたいで、その記事を書くのをやめて今すぐ病院に行って欲しかったです、残念でした…。 そのはせがわさんが言っていた好きな言葉があって 「その仕様を最も悪用できる方法を思いつくことが世界の平和の貢献につながる」 NetAgent Official Blog : 私がセキュリティの世界に挑戦した理由 ～はせがわようすけ～ 僕は世界の平和とまではなかなか言えないのだけど、僕と僕のまわりの平和ぐらいは守りたいし、世の中の悪
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
