今日はReproでの最終出社日。思い返せば 30 歳も過ぎてから Ruby とどう関わっていくかという人生だった。 MacRuby （2010年~） 暇つぶしに Mac OS X のアプリを作ってみようかと思い立った時に出会ったプロジェクトだった。 今のように Swift や clang というコンパイラもなく、 Objective-C 言語というとにかく [] を書きまくらないとならずどうにもなじめなかった。もともと趣味で Ruby はさわっていたのでそれでアプリが作れたら良いのにと思っていたところで、渡りに船的にさわり始めたのがきっかけだった。 私がさわり始めたころはちょっとしたコードを書いてもすぐにクラッシュするような感じで、ちまちま「こういうコードを書くとクラッシュするんだけど何でだろう？」とプロジェクトの issue に書き連ね、気がついたら「こういう風に直すと動くようになるんだ

転職エントリです。 前回はこちら。 www.yuki3738.net 2023年11月17が最終出社日、有給休暇を経て12月28日が最終日でした。 2024年1月1日から株式会社movに入社します。 mov.am Sansanでは Sansanでは、名刺アプリEightのサーバーサイドエンジニアとして働いていました。 5年10ヶ月の在籍期間中、主に新規機能開発チームで新機能に纏わる開発やらその他色々やってました。 フロントエンドやモバイルエンジニアと連携しながら、新機能のためのAPI生やすことが多かったと思います。 2023年で出した大きなものとしてはやっぱりVersion10でしょうか。色替えや文言替えを結構な期間やってました。サービスのリニューアルって大変ですよね。 終盤に至ってはEightってメールがすんごい種類あるので整理してました。共通化したりドキュメント整えたり。結局やりたいと

IRBの最新の自動補完機能を誰よりも使ってるぺん(@tompng)です。 IRBの補完についてGoogleで検索すると disable turn off などと書かれた記事ばかりが出てくるのですが、今のIRBは自動補完の問題点がかなり解消しています。 無効化設定している人はいますぐ ~/.irbrc を開いて IRB.conf[:USE_AUTOCOMPLETE] = false と書かれている行を消しましょう。 自動補完の問題点とどう解消されたか 補完ダイアログが大きくて邪魔・入力行が上にずれる ターミナルの高さとカーソルの位置に応じて、補完ダイアログの表示サイズを調整するようになりました。 https://github.com/ruby/reline/pull/542 色が見づらい 見た目をカスタマイズするAPI Reline::Face が導入されました。(ドキュメント) https

Development Division/Repro Team/Feature 1 Unit の Watsonです。Feature 1 Unit は Repro Tool の機能開発と保守を担っています。 弊社でも利用している Oj gem のパフォーマンス改善 PR を送った話と、その PR の内容について共有します。 ことのはじまり 以前、同僚が Ruby on Rails で JSON を返す REST API を作成した際、JSON のエンコード部分のパフォーマンス計測をしていました。JSON のエンコード方法は JSON.generate、ActiveSupport::JSON.encode、Oj gem を利用する方法など色々ありますが、私としては Oj gemの ほうがパフォーマンス的にいいだろうからそちらを利用したほうが良いのではと思っておりました。 計測結果を拝見したら確

ISUCON13 に参加した。なお、前日は気合を入れるためにラーメンを作った。 lime1024.hateblo.jp 今回もうなすけ・やままと「たんぽぽの上の刺身」で 4 回目の ISUCON に参加した。結果は 15,549 点で 160 位 (再起動試験の結果を含めたら 139 位くらい) だった。最後の 1 時間前には 100 位を切ることもあったが、結果的には 100 位以内に入れず残念だった。 1 番左のが順位です 素振り 進め方やデプロイ方法、ベンチマークの履歴やスロークエリの共有方法等、どうするか・前回どうしたっけを思い出す会をやろうと思っていたのだけど、以下の理由から通話繋げつつ個々人で振り返ったり、ツール類を直したり、家のインターネット直したりすることになった。 今日は ISUCON の素振りをはじめようとしたら、うなすけが家のインターネットを壊したせいで全然素振りがで

こんにちは、Wantedly の 2023 年サマーインターンに参加した Ran350 です。今回のインターンでは 3 週間 DX (Developer Experience) squadに所属し、「Wantedly における Ruby コードベースへの型システムの導入」をテーマに取り組んでいました。本記事では、その仮説検証の過程や調査記録を紹介します。 目次背景目的まとめ論点型システム導入による恩恵型システム導入による弊害型システム導入による恩恵-弊害を評価するために知りたいこと検討方針案【事前調査】過去の型起因のバグ【選択肢の整理と検証】型検査手法【選択肢の整理と検証】RBS 作成手法RBSの追加順序の検討【見積もり】RBS作成コスト【見積もり】型検査による恩恵型システム導入による恩恵-弊害が最適となる運用方針の提案まとめ感想注意本議論はまだ検討段階です。Rubyの型システム導入という

こんにちは，相生ゆら（@Little_Rubyist）です．最近配信でクロノトリガーをやっているんですがあまりにも面白すぎてありとあらゆる知人に「クロノトリガーをやれ」と言っています． さて，入社から半年以上経過しましたがその話はまた別でやるとして，私の所属している部署では勉強習慣というのがあって，自分の興味のあることを業務時間中に勉強してもいい時間が存在します．各々色んなことをやっていますが，私はその時間で少しずつRBSを導入しています．まだあまり触れていないプロジェクトなのでコードリーディングをしながらゆっくり入れていこうと思っています． CI導入まで済んだのでこれを一区切りとし，どういったことをやっていたのかをご紹介します． 型導入の準備 とってもシンプルです．steep, rbs_rails, katakata_irbをGemfileに追加します．ライブラリの型も必要なので，rbs

Shopify の Ufuk さんが、Twitter で Shopify が Ruby 3.2 に成した貢献を連投されていたので、許可をえて訳したものをまとめておきます。誤訳などあればご指摘ください。なお、訳はDeepL さんの力を借りて行いました。というかだいたいそのまんまです。 いやぁ、スゴイ成果ですね。 Ruby 3.2 のクリスマスリリースが近づいているので、とても興奮しています。実際、3.2 には非常に多くの優れた機能があり、リリース日が待ちきれませんでしたが、われわれはすでに Shopify のお店のすべてのリクエストに対してデプロイしています。 すべての詳細について詳しく説明させてください🧵 訳注：棒グラフY軸が 0.9 から始まっているのに注意。See also: グラフの描き方 まず一番楽しみにしている機能はYJITです。Ruby 3.2のYJITは、プロダクションレデ

Rails アプリケーションに型付けを進める中で、同僚と話題になった concern の扱いについて紹介します。 ご存知の通り、concern は「関心事を分離したもの」とよく紹介されるモジュールで、モデルや Controller などで include して使う共通モジュールです。 この concern に対して型付けをしようとしても、うまく行かないね、というのが今回の話の発端です。 話をイメージしやすいよう、ログイン状態をチェックする Loginable という concern をサンプルとして用意してみました。 module Loginable def require_logged_in redirect_to login_path if session[:user_id].blank? end def login(user) session[:user_id] = user.id

2023.7.19 監　修 株式会社Laboro.AI　執行役員 マーケティング部長　和田 崇 概　要 人々が理不尽な差別に苦しむことなく才能や努力に応じて報われる社会。実力があれば上に行ける「能力主義」には、もちろん良い側面もあるに違いありませんが、より高い能力を得るために過酷なレースが繰り広げられるようになっていることも実際です。 能力主義が手に負えなくなり始めた今、そのレースから外れがちな人々に、新たな視線が集まっています。例えば、世界では13億人が何らかの障害を抱えて生活しており、その数は世界人口の17%に相当し、世界最大のマイノリティ・グループとしても位置付けられます。ですが、彼らは「能力主義はもう古い」と言わんばかりにインターネットを通じてテクノロジー企業とつながり、社会とつながるためのAI開発にも参加しています。 こうした新しいプレイヤーの登場によって、これまで難しかった障害

RubyKaigi 2023 キーノートレポート Maxime Chevalier-Boisvertさん「Optimizing YJIT’s Performance, from Inception to Production」 ～RubyKaigi 2023 2日目キーノート 最近のRubyインタプリタの進化において非常に重要なトピックの一つが、JITコンパイラの登場です。特にShopifyのJITコンパイラチームを中心に開発されたYJITは、世の中で広く使われているRailsアプリケーションを有意に高速化できるJITコンパイラとして、既にproduction-readyであると評価されており、各所で採用が進んでいます。 RubyKaigi 2023 2日目のMaxime Chevalier-Boisvertさんによるキーノートでは、開発チームがYJITを開発するにあたってどういったアプロ

2023年4月中ごろから6月の今日までの2ヶ月と少しかけた転職活動が終了したので、記録ついでに振り返りたいと思う。 あくまで個人的な記録である。 応募手法 応募方法は、さまざまな方向から行った。 Twitterでの公開募集 エージェント経由 YOUTRUST経由 直接応募 Twitterでの公開募集 正直なところ、一回やってみたかったという部分が大きい。今回の転職活動における大きなチャレンジだった。ありがたいことに20社以上から声をかけていただいた。知り合いのフリーランスの方から「うちが関わってるところどうですか？」という声がけも3名からあった。その節はありがとうございました。 数は多いものの、話を聞く聞かないを考えなくてはならなくなり対応に追われた。公開募集とは、受動的な方法なのだと痛感した。また「会社名も書いてないから怪しいな？」と思ってDMの送信主を調べたら国際指名手配者だったという

Rubyist Hotlinksにインスパイアされて始まったイベント『Rubyistめぐり』。第2回は鳥井雪さんをゲストに迎えて、お話を聞きました。こちらは前編です。 hey.connpass.com 推理小説に衝撃を受けた小学校時代 藤村：今日はお集まりいただきありがとうございます。STORES のCTO 藤村と申します。10年ちょっとくらいRubyを使って仕事をしています。Rubyistめぐりは、僕がプログラミングを始めた頃にめちゃくちゃ読んでたのがRubyist Hotlinksで、プログラマーの人はこういう人たちなんだ！と、（Rubyist Hotlinksに載っている人は）外れ値がほとんどなんですが、めちゃくちゃ勉強になったし、励みにもなったんですよね。これをなんか引き継げないものか、新たに話を聞きたい人もいるよなと思い、始めたのがRubyistめぐりです。第2回目のゲストは鳥井

現職での業務を行いつつ、転職活動をする場合、基本的には転職意思を公にしないケースが多いでしょう。 転職媒体やエージェントを利用してその範囲のみ転職意思を開示するのが一般的です。 一方で転職意思を公にできる場合もあります 現職に転職意思を開示してもマイナスの影響がなく、気兼ねなくオープンに転職活動できるとき すでに退職が決まっているなかで、転職活動を開始するとき このようなときに行う「転職意思をオープンにした転職活動」の 方法 ポイント についてまとめます。 前提 「転職意思をオープンにした転職活動」は 本人の職種やスキルレベルを踏まえた市場価値が高い 本人のインターネット上での認知度が高い、交流範囲が広い ほど有効になります。 方法 公開レジュメの作成 転職意思をオープンにできる場合、広い範囲にリーチするためには公開レジュメの作成が有効です。 項目としては 氏名 or ハンドルネーム 住所

こんにちは。サーバーサイドエンジニアの三村（@t_mimura）です。 主に保険薬局と患者さまを繋ぐ「かかりつけ薬局」化支援アプリ kakariのサーバーサイド開発（Ruby on Rails）を担当しています。 突然ですが！ この度kakariプロジェクトは「型導入」をしました！ kakariのRailsリポジトリに型導入PRがマージされた様子 皆さんのプロジェクトは「型導入」していますか？ 「型導入」しているRailsプロジェクトはまだ少ないのではないでしょうか なぜ型導入しないのか 型を導入すると何かしらが便利になることは分かっているのに何故やらないのでしょうか（煽り気味） 「型の恩恵」と「型を自分たちで書くコスト」の２点を比較していませんか？ RubyKaigi 2023開催前の私がまさしくそう考えていました。 本当にその２点を比較するべきなのかをここで再考してみましょう。 「型導

皆さんRubyKaigi 2023お疲れ様でした! あっという間で本当にたのしい3日間でしたね。わたしは一週間が経ってもいまだにわくわくした気持ちで日々を過ごしています。 今年もありがたいことにDAY2に登壇の機会をいただいたので、この記事では今回作ったものや会期中のあれこれを振り返ってみたいと思います。 今回の発表テーマを選んだきっかけ 今回はImplementing "++" operator, stepping into parse.yというタイトルにて「"MRIにインクリメント演算子を追加する"という取り組みを題材に、MRIの字句解析器(スキャナ)と構文解析器(パーサ)に親しむ」というテーマでプロポーザルを提出しました。 (今年のRubyKaigiはパーサ関連の発表が豊作だったので、思いがけず空前のパーサブームに加わることができて幸運でした) 自分自身の個人的な技術的興味はネットワ

5/10から5/14の5日間、RubyKaigi 2023に参加するために松本市に行ってきました。前回参加したのがRubyKaigi 2019の福岡のときなので、じつに4年ぶりの参加でした。 今回はコミッター/登壇者/LTスピーカーとしての参加になりました。その結果、0日目のDevMeeting含めて3種類のスライドをつくり、3日目の"Ruby Committers and The World"含めて3回登壇するというイベント盛りだくさんなKaigiでした。 いやー、自分のRubyKaigi史上、最高のRubyKaigiでしたね。まさにParserKaigiだったのではないでしょうか。 いろいろ書きたいことはありますが、まずは時系列で振り返っていきましょう。 Day 0 (5/10) - DevMeeting DevMeetingに参加するためDay 0から松本へ向かいました。新宿から特急

（本稿のカバー写真は@ima1zumiからお借りしました。写っている面々の👍ももらっております） RubyKaigi 2023 in 松本では、IRBをメンテナンスしているチームのアクティブメンバ4名全員（！）が登壇しました。 @ima1zumi、@_st0012、@tompng、それからわたくし@hasumikinです。 そこでこの記事では、わたくしを除く3名のトーク内容や人となり（？）をご紹介します（登壇順）。 Encoding lover @ima1zumi フィヨルドブートキャンプ卒業生として有名な@ima1zumiは、UTF-8 is coming to mruby/cというタイトルの発表をしました。 こまかい話はご本人のブログでお読みいただけます。 ざっくり要約すると、現状のmruby/cにはエンコーディング概念がなく、Stringクラスのデータはただのバイナリであり、人間の

RubyKaigi 2023に参加してきました。 今回は長野県の松本での開催でした。 全体的な感想 今回は、会場のスポンサーブースの数や来場者が去年より格段に多く、かつてのRubyKaigiが戻ってきたことを強く感じました。 4, 5年ぶりぐらいに会う人も沢山居て、会う人会う人に「うおー、久しぶりです！」って言って回ってた気がします。 久しぶりに会う人と直接近況をやり取りできるのは、とても嬉しいことですね。 自分はあんまり写真撮らないタイプなのですが(食べ物と酒は除く)、今回は割と多くの #rubyfriends 写真を撮った気がする。 それぐらいはしゃいでいたと言えるのかもしれない。 (撮った写真を了解無く上げるのは、ちょっと気になったので写真は割愛) とにかく、色々な人にまた会えたのが嬉しかった。そういうRubyKaigiでした。 セッションについて 今回は、パーサー周りのトークが妙に

PDF形式のファイルを御覧いただく場合には、Adobe Acrobat Readerが必要な場合があります。 Adobe Acrobat Readerは開発元のWebページにて、無償でダウンロード可能です。