Mercari Advent Calendar 2017 の18日目です。 こんにちは。メルカリJPのサーバーサイドエンジニアの@Hirakuです。最近はメルカリNOWの立ち上げに関わっておりGoとPHPを行ったり来たりしています。 今回はネタとしては地味ですが、2017年に遭遇した、MySQLのデッドロックの話をしようと思います。 これまでも何度か話されている通り、メルカリのコア部分は今でもPHP + MySQLで構成されており、複雑なトランザクションを含む処理が各所に存在しています。そのため、意図せずしてデッドロックを作ってしまうことがあり、場合によっては重大な問題につながります。 今年は本当にデッドロックに関するトラブルに多く遭遇し、すっかり「デッドロック絶対に許さないおじさん」みたいになっていました。 事例1)出品者と購入者 デッドロックと言われてもピンと来ない方もいらっしゃるでし

表題の通り、お恥ずかしい限りではありますが、人生ではじめて警察（神奈川県警！）のお世話になる運びとなりました。 罪状としては「不正指令電磁的記録 取得・保管罪」、通称ウイルス罪とのことで、まさに青天の霹靂の思いです。 以下ではこの度起こったことを可能な範囲でありのまま共有できればと思います。 この記事の目的まず、この記事を公開した目的は「他のクリエイターの人に同じ経験をして欲しくない」という一点に尽きます。 手前味噌ではありますが、私はこれまで多くの尊敬するクリエイターの方々と同じように「良いクリエイターであろう」と腐心し、できうるかぎりの努力をしてきたつもりです。 今回の件に関しても決して私利私欲のためではなく、あくまでユーザーのためにできることを、と模索した結果でした。 それがこのような形で取り沙汰されることとなり、残念という他ありません。 忸怩たる思いではありますが、この件から何かし

The English version of this article is available here: medium.com 2/4(日)に、去年のRubyKaigiが終わった直後の新幹線で開発を始め10月に公開したJITコンパイラをRubyのtrunk (2.6.0-dev) にマージし、昨日TD Tech Talk 2018で以下のような内容の発表をしました。 speakerdeck.com まだそれほど速くできていないということもあり、私はTwitterでのみ共有して満足していたのですが、海外の方がいくつか記事を書いてくださいました。 Playing with ruby's new JIT: MJIT - John Hawthorn Ruby’s New JIT – Square Corner Blog – Medium とても丁寧に書かれているので、私の記事がわかりにくければ

ついにAWSのマネージドKubernetesサービス「EKS」が発表されましたね！ この記事では、これまでKubernetes on AWSに取り組んできた @mumoshu の観点でEKSについてまとめてみたいと思います。 @mumoshuって誰？ Kubernetes Incubatorのひとつ、kube-awsというKubernetesクラスタのプロビジョニングツールのメンテナです。 Kubernetes on AWSのつらみ これまでKubernetesをAWSで運用する場合の最も大きなつらみ（と思われていた）は、Kubernetesを自前でAWSにデプロイすることでした。 例えば、AzureやGCPにはそれぞれAKSやGKEといったKubernetesのマネージドサービスがあります。 AKSやGKEは「クラスタを作成する」という操作をすればKubernetesが使い始められたり、

前口上 アメリカで就職できなかった。華々しい成功譚は見かけるが、夢と散った話はあまり表に出てこない。 なんというか「三振したバッターが相手ピッチャーのことを語る」みたいでまるっきり時間の無駄かもしれないが、もしかしたら参考になる人もいるかも知れないし、実際に就職した人に「お前のアプローチはまったく的外れだ」と言われるかも知れない。僕も何が悪かったのか教えてもらいたい気持ちもあるし、迷ったがこのエントリを公開する。 ちなみにめっっっっちゃ長いので、要点だけ知りたい人は、アメリカで就職するにはとにかく 就労ビザ＞技術力＞学歴＞＞＞＞＞＞＞＞＞＞＞＞（越えられない壁）＞英語力 だというのだけお伝えできればと思う。 アメリカで働くために英語を頑張るぐらいなら、それより大学（院）に入り直してコンピュータサイエンスの学位をとり*1、同時に技術力を磨くほうがよほど近道だと感じた。 それから、現職の同僚は

こんばんは、新規事業開発室の生田です。 1月16日に、blockchain.tokyo#4がメルカリさんのイベントスペースで開催され、新規事業開発室のメンバーで参加してきました！今回はその発表内容を紹介させていただきます。 Bitcoin Improvement Flow @yamarkz 最初の登壇者はGunosy新規事業開発室メンバーである山口の発表です。 ビットコインは当初の仕組みからSegwitなどの改善が多数行われてきています。通常のwebサービスでは、中央のサーバーで全て情報を持っていますが、ビットコインはそれぞれのマイナーがブロックの情報を持っているため、アップデートを行った際に、マイナー同士で情報に差異が生まれトラブルになる可能性があります。その差異を無くし、トラブルが起きないようにするために、ビットコインの中に改善フローの仕組みが組み込まれているということでした。 より詳

こんにちは！広報・ブランディングをしてますmatsuriです。 今回は、16年にエンジニアとして新卒入社したsestaにピクシブに入社したきっかけやキャリアビジョンを聞いてみたいと思います。 よろしくお願いします！いま、sestaはどんな仕事をしていますか？ pixivの投稿者にフォーカスを当てたチームで、機能の改善や企画の運用をしています。 仕様を決めて他のメンバーへのタスクの割り振りをしたり、また実際にコードをかいたりもしています。 ピクシブには去年新卒で入社したんでしたよね。 はい、一昨年の春に入社しました。入社前の夏から半年間、アルバイトとして働いていたので、実質3年目になります。 入社前にアルバイトをする新卒社員は毎年いますよね！では、ピクシブに興味を持ったきっかけなど教えてください。 僕が良いなと思ったのは、ピクシブでのエンジニアの働く環境です。企画や仕様の段階から入っていき、

広告技術部の toshimaru です。この記事はGunosy Advent Calendarの24日目の記事です。 qiita.com はじめに Gunosyではいくつかの管理画面においてRuby on Rails（以降Rails）を利用しています。具体的には下記の管理画面においてRailsが利用されています。 社内メンバー向け管理画面: 社内の担当者が記事の管理を行ったり、Gunosyアプリのユーザーの管理を行ったりできる管理画面です メディア様向け管理画面: Gunosyに記事を提供していただいているメディア様向け管理画面で、レポート閲覧や記事管理を行うことができます 広告主様向け管理画面: Gunosy Adsに広告を配信していただいている広告様向けの管理画面で、広告出稿やレポート閲覧を行うことができます 今日はそんなGunosy管理画面を支えているRails技術をいくつかピックア

この記事はGunosy Advent Calendar 2017の11日目の記事です。 昨日は@okataiさんのDDLを使って0クリックから始めるパーソナライズでした。 どーも広告技術部の@k_7016です。 普段はRails書いたりしてます。 皆さん、かなりちゃんと記事書いてて焦るところですが、空気読まずゆるふわやってみた系の記事書こうと思います。 最近話題のProgressive Web Appをやってみたいなと思いまして色々読んでたんですが範囲広くて爆死しそうになったのでとりあえず Service Woker 触ってみました。 やること Service Workerで 静的ファイルキャッシュ 動的リクエストキャッシュ ができたらゴール。 対象サンプルアプリ Reactでブログっぽいもの作ってfirebase に hosting しました。 この辺もやってみたいなーと思ってやってみた

2017年12月9日に行われた Rails Developers Meetup 2017 ( https://railsdm.github.io/2017/ )での発表スライドです。 なぜRailsを採用するのか──あなたならこの問いにどう答えるでしょうか。Railsは遅い、RailsのRailには乗りたくない、Ruby/Railsの黒魔術が怖い…さまざまな批判の声も聞こえてきます。本発表ではなぜ今Railsなのか、”Why Ruby?” “Why Rails?” という２つの観点から考えたいと思います。 - Blog記事: http://blog.toshimaru.net/why-we-use-ruby-on-rails/

§1. はじめに こんにちは こんばんは 久しぶりの投稿です。 タイトルはスーパーマン松本さんのアレから拝借しました: codezine.jp 今日はポエムを書きます。 なにか技術記事を期待してた方、もしいましたらすみません。また次回。 完全に僕の観測範囲での主観に基づいていますので、燃えるかもしれません。 この文書は you should do ではなく what I didがメインです §2. 背景 数学しか知らなかった僕がGunosyに入社して、約7ヶ月ほど経ちました。 数学しか知らなかった、と書いたものの「数学は知っていたのか」と言われるNOです。 3ミリぐらいしか知りません。 僕が機械学習エンジニアになった経緯は↓の２つの記事にだいたい書いてあります: mathetake.hatenablog.com gunosiru.gunosy.co.jp 7ヶ月がむしゃらに仕事をしてきて

翔泳社は「ITエンジニアに読んで欲しい！技術書・ビジネス書 大賞2017」（ITエンジニア本大賞）を開催。ITエンジニアの投票を集計した結果選ばれた技術書、ビジネス書の各ベスト10を発表しました。 ITエンジニア本大賞の主催は翔泳社ですが、投票の対象となったのは出版社や刊行年を問わず、この1年を振り返っておすすめしたい技術書、ビジネス書全般です。 実際にベスト10に入った書籍の出版社は技術評論社、オライリー、日経BP、インプレス、オーム社、NHK出版、ダイヤモンド社など多岐にわたり、主催の翔泳社の本は1冊にとどまっています。 ベスト10の上位6冊については、同社が2月16日に都内で開催する「Developers Summit 2017（デブサミ2017）」において書籍の著者、編集者、翻訳者などによるプレゼン大会が開催され、そこで行われる最終投票によって大賞が決定されます。 技術書部門ベスト

はじめに アプリによってビジネスモデルは異なりますが、大多数のアプリがゴール（KGI）にしているのは売上増かと思います。 では、あなたは売上増に向けた指標の把握と整理ができているでしょうか？ この記事ではKPIツリーを使ってアプリの売上に貢献する指標を洗い出し、各指標について説明したいと思います。 1.KPIツリーの重要性 ◆そもそもKPIツリーとは？ KPIツリーとは、例えばアプリのKGIを売上とした場合、売上を構成する要素を分解して施策が実行可能になるレベルまで落とし込まれた指標（KPI）の一覧です。 ◆KPIツリーを作らない場合の問題点 ①ボトルネックとなっている問題がわからない 売上を構成する要素を洗い出さないと、売上増の妨げになっている問題に気づかないことがあります。 ②具体的な施策を考えるのが難しい 売上やアクティブユーザー数など上位の指標を分解しないままでは、「じゃあその指標

RubyConf 2016で登壇してきた 2016/11/10〜11/12にアメリカのオハイオ州シンシナティでRubyConfというイベントがあって、Ruby DSLによって設定できるCLIツールをRubyインタプリタやgemの存在に依存しないシングルバイナリとして実装するための知見を「Evaluate Ruby Without Ruby」というタイトルで発表してきた。 発表資料 発表動画 RubyConfってどうなの RubyConfはRubyKaigi並に規模が大きいもののあまりRubyのDeepな部分には期待できないカンファレンスなんだけど、当時行ったことがなかったアメリカに行ってみたいという思いがあって去年も参加していた。あと、RubyKaigiとは違った層の海外のエンジニアと話せる *1 のも良い点だと思う。 去年はRubyKaigi 2015で話したものと同じ内容のCFPをRu

最近はとても便利なプラットフォームがいっぱいあって、 詳細な中身を意識しなくても簡単に使えるという素晴らしい時代ですが、 深くまで突っ込んで考えないといけない場面が たまーーーーーーーに でてきます その時になって初めて、 誰かが用意してくれた快適な環境を使っていただけで自分では何も解決できない という現実を叩きつけられるわけです 大げさに言いましたすみません ちょっと前に仕事でサーバーのパフォーマンス調査をする機会があり、 その中で "プロセス" と "スレッド" って一体何が違うの！？ って疑問にぶち当たりました わかるような、わからないような 何となくわかったつもりになっている事でもそろそろちゃんと理解して、 今日からイケてるエンジニアになりましょう この記事では 1. マルチタスクOSとプロセス 2. メモリの役割 3. 物理アドレスと仮想アドレス空間 4. プロセスがメモリに保持

This document summarizes a microservices meetup hosted by @mosa_siru. Key points include: 1. @mosa_siru is an engineer at DeNA and CTO of Gunosy. 2. The meetup covered Gunosy's architecture with over 45 GitHub repositories, 30 stacks, 10 Go APIs, and 10 Python batch processes using AWS services like Kinesis, Lambda, SQS and API Gateway. 3. Challenges discussed were managing 30 microservices, ensur

Rebuild.fmを聴いてて、まだ友人のポストを見て、自分も思うところがあったので、書いてみる。 3ヶ月前からアメリカのスタートアップで働き始めたてなので参考になると思う。 まず働く上で必要な英語力って 仕事をする上で必要な能力 同僚との日常会話 の2つ。 面接に通って、仕事を手に入れる上で、英語力という意味では「1.仕事をする上で必要な能力」があれば問題ない。 実際に働く上で痛感したのは「2.同僚との日常会話」の不足。 英語の四技能 どのレベルになっても基本的には以下の能力のどれを集中して伸ばすかという話になる。 リーディング リスニング ライティング スピーキング 1. 仕事をする上で必要な能力 これは、正確に物事を表現する能力を指している。具体的には、 正しく喋っている人や、正しい書き言葉を理解する能力 ロジカルに物事を英語で正確に説明する能力 技術力による文章理解 これはどれも書

いま注目すべきシリコンバレーの有名なIT企業は新規のデザインや機能が有効かどうかを検証するためにA/Bテストを行っています。 その一方で、日本の企業も含め、A/Bテストを本番環境で導入している企業は非常に少ないです。 加えて、日本で言われているA/Bテストと海外で言われているA/Bテストは少々異なるものだと感じています。 日本のA/Bテストはフォームの最適化やデザインの修正にとどまっている一方で、海外のA/Bテストはプロダクト開発のサイクルの一部分となっています。 プロダクト開発のサイクルの一部としてA/Bテストを取り入れるためには、大量のテストを定常的に回していく仕組みが必要となってきます。 そこでデータドリブンであると言われているようなシリコンバレーのIT企業は自社でA/Bテストの基盤を作成しています。 今回は社内A/Bテスト勉強会で発表するために、シリコンバレーの有名IT企業がどのよ