こんにちは。MySQLは秋の季語とする一派が世に存在していることを知り、私もMySQLに関わる記事を書いてみようと筆を取ることにしました。 さて、リレーショナルデータベースをバックエンドとするWebアプリケーション開発において、特定の条件に合致するレコードがN件だけ存在するかどうかを確認するロジックは頻出といえます。プログラマとして一度は書いたことがあるのではないでしょうか？ この記事ではそのような件数カウントを行うためのクエリが引き起こした性能劣化と、その改善アプローチについて紹介していきます。 なお、本記事の内容はMySQLを前提としており、アプリケーションコードの例はRuby on Railsを用いますが特別な前提知識は必要ありません。コードの雰囲気だけ感じ取っていただければと思います。 ありがちなコード if query.count == n の問題 冒頭で述べた通り、特定の条件に
情報通信研究機構（NICT）は10月9日、大規模な太陽フレアの発生とコロナガスの地球方向への放出を確認したとして注意喚起した。10日深夜から数日間、人工衛星の障害やGPSの誤差拡大といった影響が出る可能性がある。 9日の午前10時56分、太陽面の中央付近に位置していた「13848」と呼ばれる黒点群でX1.8の太陽フレアが発生した。太陽フレアの規模を示す“クラス”の中で最も規模が大きいXクラスに分類される。 1日に発生したX7.1や、3日のX9.0の太陽フレアに比べると規模は小さいものの、今回は地球方向へ噴出したコロナガスが「けっこう大きい」（NICT）。 コロナガスが地球に到達すると地磁気嵐が発生し、その影響で地球周辺を飛ぶ人工衛星やGPSを用いた高精度測位、短波通信などに障害が発生するおそれがある。NICTは「宇宙システムの利用には注意が必要」としている。
みなさんこんにちは！ Reproユーザーコミュニティ Camp運営のEndoです。 今回は「LTVを最大化する基本戦略7選」と題し、“LTV”をテーマとした内容でイベントを実施しました。セミナーとワークショップの二部構成で、密度の高い時間になったのではないかと思います！それでは、イベントの様子をご覧ください🙌 ▼前回のイベントレポート Camp イベント開始📣今回のイベントにもさまざまなサービス・業界の担当者のみなさんにお集まりいただきました！3〜4名のグループに分かれて、まずは自己紹介から。初参加の方にもたくさんご参加いただけました😊 「LTVを最大化する基本戦略7選」セミナーさっそく、前半パートのセミナーがスタート！今回は、Reproの取締役CBDO中澤が登壇しました。30分程度のセミナーながら、LTVについて濃い内容のお話が展開されます！ セミナーで話された内容については参加者
Platform Team/Repro Core Unit の村上です。 Repro では Kafka を基盤としたストリーム処理のアプリケーションを構築する際に、Kafka Streams を積極的に活用しています。 Kafka Streams は、フォールトトレラントなステートフル処理を簡潔に実装でき、データパイプラインを Topology という表現で抽象化することで、複雑な処理でも管理しやすい形で組み立てていくことが可能です。 また、Apache Kafka 以外の外部依存がないことや Streams DSL によるシンプルな記述でストリーム処理を実装できることなども、ストリーム処理のアプリケーションをスムーズに構築する上で助かっています。 一方で、 なにかしらの問題が発生したときのトラブルシューティングや影響範囲調査の際には、Kafka Streams の内部処理を把握していない
はじめに 自社開発企業のAI部門でインターンしている25卒のエンジニアです。 フロント、バックエンド、インフラ、AIなど色んな分野に興味を持って開発しています！ 最近は個人開発で収益を上げて生活する、「Indie Hacker」のような生き方に憧れています。 将来は個人アプリを当てて、島で悠々自適に暮らしたいと思っています🏝️🏝️🏝️ マッチングアプリを作ろうと思った経緯 何を隠そう、自分の出会いを増やしたかったから 周りの大学の友達で「彼氏欲しい〜、彼女欲しい〜」と言ってる人がいる 自分の大学限定でマッチングアプリ作ったら、安心感もあるしハッピーではないかと考えた アプリの名前はシンダイ(自分の大学の呼び方) x Tinder = Sinder(シンダー)に決定 リリースまでに行ったこと リリース日を学園祭の当日（半年後）に決定 学園祭のスポンサーになって、大々的に広告を打つ作戦
YAPC::Hakodate 2024のキーノートスライドです。
YAPC::Hakodate 2024のLT資料です
何らかの問題を解決しなくてはならなくなった時に、解決よりも深掘りを優先してしまう特性の人がいます。 たとえば問題に対する短期的な対策を考えることをおろそかにして、根本原因究明と根本対策方法をじっくり考え込んでしまうような人が該当します。他人事のように言ってますが、筆者もそうです。本記事は、そういう筆者が過去に仕事で困っていたこと、ある時から状況によって取り組み方を変えられるようになったという話をします。 上記のような特性の人は、調査のたびに深い知識が得られ、血肉となっていきます。それゆえ技術に明るい人とみなされることもあります。その一方で、困ることもあります。とくにそれは発生した問題が自分ではなく他の誰かのものだった場合、かつ、急ぎ問題解決が必要な場合です。業務ではこのような場面が非常に多いです。 この場合、問題の深掘りを最優先にしてしまうと仕事が遅くなりがちです。みなさんも、「あの人、技
ターミナルでほとんどを過ごす都合がある。しばらく前まではkittyを使っていたのが、このところはWezTermを使っていた。 WezTermは最近はやりのGPU-acceleratedなターミナルエミュレータで機能が豊富である。 wezfurlong.org たとえば、タブを作れたり、リーダーキー(screenとかのCtrl-a的な感じで他のショートカットのprefixになる)を設定できたり、workspaceを複数作れたり、builtinなsshでリモート接続したり、multiplexできたりする。 wezfurlong.org これらリッチな機能のおかげで、端末+tmux的な機能と操作感をWezTermだけでできて大変にべんり…という感じだった。…が、いまはやめようかなと思っている。 やめようかなとなっている理由 環境が悪いというとそれまでなのだが、nvidiaのGPU(+Linux)
こんにちは、タイトルでだいたい言い尽くしましたが、このような悩みを自分および自分の周りでよく聞くようになったので、Stripeの方に教えてもらいながらどうすればいいか整理しました。 あくまで「めちゃくちゃ開発コストをかけない範囲で」の解決策なので多少トリッキーですがお付き合いください。あるいは、この記事を読んで「そろそろちゃんとコストかけて作りこむか」と決めていただいてもいいと思います。基本的にStripeの実装経験がある方向けの記事です。 どういう状況か さて、状況を具体的にするために具体例を挙げていきましょう。 1アカウントあたり月額3000円のSaaSを運営している。 当初はクレジットカードのみ、利用開始日に決済が走る標準の課金体系で進めていた サービスが成長し、法人の取引が増えて「請求書払いいけますか？」と聞かれることが増えた。 ここでいう請求書払いとは、10/1開始で契約したとし
regional.rubykaigi.org 9/7 に福岡で地域 Ruby会議を開催しました。 はじまり youtu.be RubyKaigi 2019 で id:nagachika が「parse.y is 魔境」と言っていたのが印象的だった。 jinroq.hatenablog.jp RubyKaigi Takeout 2021 の Ruby Committers vs the World で parse.y がマジでやばい状況なんだと認識した。なのでこんなブログをまとめさらに英訳した。 この頃から俺は Ruby パーサーに興味を持ったのだった。 もうすでに終わっている RubyKaigi Takeout 2021 で Ruby パーサーの歴史について語っているトークがあった。そのトークをした人物こそが Kevin Newton である。 rubykaigi.org 先ほどの英訳ブロ
こんにちは。スマートバンクのサーバーサイドエンジニアをやっておりますid:moznionです。 すっかり秋めいてきましたね。秋といえばMySQL*1、ということで今回は先日解消した「MySQLのロックに起因するブロックタイムアウト」のトラブルシューティングついて記していきたいと思います。 事の発端 ある時を境にSentryに ActiveRecord::LockWaitTimeout というエラーがしばしば報告されるようになっていました。 SentryにActiveRecord::LockWaitTimeoutが上がってきている様子 Mysql2::Error::TimeoutError: Lock wait timeout exceeded という文言から、MySQL上でロックを取っている他のクエリにブロックされ、そのブロックが長時間に渡ったため自クエリがタイムアウトしてabortしてし
10/2更新: 1日しない間に、大変たくさんの方々にご応募いただけました。ありがとうございます。募集は終了とさせていただき、結果は選考の上お返事させていただきます 2025年初めに刊行を予定している書籍について、翻訳原稿のレビュアーを若干名募集します。翻訳は @snoozer05 が行っています。 書籍は技術執行役員（あるいはCTOやVPoE、技術統括など）としてエンジニアリング組織をリードする立場になった後に遭遇する課題やそれを乗り越えるためのアプローチ、考え方、スキルについて学ぶ内容となっています。次のような方々を対象とした書籍です: 現在エンジニアリング組織を運営する立場にいる方 これからエンジニアリング組織を運営する立場に就く方 技術執行役員の仕事に興味がある方 具体的な書名は募集時点では規約により明かせないため、レビューに参加頂いた方のみにお知らせいたします。悪しからずご理解くだ
このブラウザ バージョンのサポートは終了しました。サポートされているブラウザにアップグレードしてください。
Magit is a complete text-based user interface to Git. It fills the glaring gap between the Git command-line interface and various GUIs, letting you perform trivial as well as elaborate version control tasks with just a couple of mnemonic key presses. Magit looks like a prettified version of what you get after running a few Git commands but in Magit every bit of visible information is also actionab
はじめに この記事では、詳細な技術の話は割愛しています。 「なぜモダナイズをやろうと思ったのか?」 「どんな課題意識があったのか?」 「具体的にどうプロジェクトを進めてきたのか?」 といった、課題設定・意思決定のプロセスに重点を置くことで、同じような境遇にあるチームの意思決定の材料になればと思っております。 RoRの限界...? ダイレクト出版の業務システムはRoR(v6.1)で動いてきました。リリースから6年ほど経っているでしょうか。このシステムは何をするものかというと、例えば、 商品を管理する 顧客を管理する 注文内容を設定する 一斉配信メールを送信する マーケティングオートメーションを設定する 各種分析を行う など、業務に関わるありとあらゆることを行っています。ソースコードは10万行程度で、中堅システムといった具合でしょうか。 実はこのシステム、そこまでレガシーというわけではなく、テ
PyCon JPにおける登壇者採択に関する件
一般社団法人PyCon JP Association理事の寺田です。 現在、インターネット上で疑義が一部で取り沙汰されている状況を確認しており、それに対する声明を発表させていただきました。 その内容に対して、具体的な説明に欠けるとのお声をいただいております。 昨年の採択プロセスにおいては、先般より事実確認を進めておりました。先の声明において抽象的な表現にとどめたのは、匿名の個人による発信に関して出所を特定することができない中、個別の事実関係を公表することで誤って関係のない第三者に影響が及んだり、特定の個人を不当な形で追求するような事態が生じることを避けたいと考えたためです。結果として皆様に対する説明が不十分となり、ご不安を与えることになったことをお詫び申し上げます。 今後、事実調査結果をどのように公表するかどうかについて、一般社団法人PyCon JP Assosiationとしては慎重に検
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
