Ruby / Rails の企業として新卒氏が入社した後にウォッチするように伝えるもの - koicの日記
先日、神速さんのエントリを見てあとで書こうと思ったもの。 表題ママだけれど、Ruby / Rails の企業として新卒氏が入社した後にウォッチするように伝えているもの。もちろん流量も結構なものなので実際にどの程度ウォッチしているかは本人に委ねている。自分も全部は見れていない。メールでのタイトルか送信者 (PR や Issue を出した人) で興味を引かれたものが基準。 Rails 研修での Rails Tutorial の流れで、upstream とそれに近い情報源を伝えている。特に y-yagi さんのブログは、子供の頃に読み始めた新聞と同じで最初は分からなくても読み続けているうちに分かることが増えてくるので継続するのが力になることと共に伝えている。 GitHub 上のリポジトリ https://github.com/rails/rails ... ruby/ruby のリポジトリと一緒
Nokogiriが1.11.0からプリコンパイル済みで配布される - koicの日記
Nokogiri が 1.11.0 からプリコンパイル済みで配布される (らしい) 。 このエントリを書いている時点での Nokogiri のプレリリースバージョンは 1.11.0.rc3 なので、大きな問題がなければ近日リリースの Nokogiri からという少し先取りの話になる。 おや？となったツイートは以下。 On a more serious note, we're REALLY close to shipping precompiled native gems.https://t.co/tKcuym2UqQ— mike dalessio (@flavorjones) 2020年10月8日 後述するイシューに詳しくは記載されていますが、Linux だけではなく macOS にも対応しているらしい。 早速手元の macOS で見てみることにする。 % time gem install
銀座Rails#39に登壇した - koicの日記
銀座Rails#39に登壇した。 主催者の morimorihoge さんからは、3年目あたりを経ったエンジニアに響くような話を題材にというオファーで頂いていた。 11/19の銀座Rails#39 @koic さん登壇テーマは僕が聞きたくてお願いしました。銀座Railsが始まったころに新人エンジニアだった人が、働き始めて3年経った今刺さるような内容になってくれればと思います #ginzarails ：銀座Rails#39に登壇します https://t.co/sJUwAgj4Ec— Masato Mori (@morimorihoge) 2021年10月29日 "3年経った" がひとつのキーワードになるものの、参加者にはベテランもいるわけで「3年目をひとつの節目に、3年目以降いつなんどき遭遇するかもしれないポイント」みたいな形で話を構成してみた。当日のスライドは以下。 静的サイトジェネレー
Ruby 3.2.0dev にマージされた Rust YJIT をビルドする - koicの日記
YJIT の Rust 実装がマージされました。いまのところ今年の Shopify からの代表作ではと見ています (YJIT 自体は Ruby 3.1 で C 実装導入されている機能です) 。 github.com そういうわけで、現在の Ruby 3.2.0dev で YJIT を有効にする場合は、Rust の処理系 (1.60.0 1.58.1 以上) が必要になります。Rust のインストールに使う rustup については以下の公式ページなどを参照してください。 www.rust-lang.org YJIT はデフォルトではビルドされません (なので YJIT を使わないビルドであれば Rust 処理系は不要です) 。 デフォルトの YJIT なしの Ruby をビルドしている場合は --yjit オプションを渡しても、ruby: warning: Ruby was built w
株式会社永和システムマネジメントのエンジニアリングマネージャーをはじめていた - koicの日記
ちょうど先日 (2022-03-02) 、勤務先で岡島さんとエンジニアリングマネージャ職について社内ラジオ配信する機会があったので、かつて下書きしていたエントリを公開しておきます。 なので、これは勤務先を移籍したとかそういった話ではなく、昨今の社会背景に対する事業課題を解決していく必要性から、勤務先での立ち位置を変えることにした話です。 受託開発企業でのエンジニアリングマネージャーというのはあまり聞かないものですが、その実、事業課題においてエンジニアのキャリアと事業成長が有機的に繋がっている点など、サービス開発企業が抱える課題とも重複する部分の方が多いと思っています。42期に突入した弊社でも、その役割によって解決できる問題を顕在化させて解決していくぞと、主に事業部長の @m_pixy と考えてこれまで勤務先に明確に存在していなかったポジションとしたのが今回。あと、世の中にないパスなら作れば
RubyKaigi Takeout 2021に登壇した - koicの日記
RubyKaigi Takeout 2021 に登壇した。 rubykaigi.org まず最初に。@yahonda さんには、昨年に引き続き事前に英文や構成レビューをしていただきました。多忙のおり、丁寧に見ていただいて本当にありがとうございました。 当日のスライドは以下です。 講演内容について、当初は6つのパートがありセルフレビューでパートをひとつ削って5つのパートで構成していました。その後、@yahonda さんにレビューしてもらった際にストーリ展開の都合でさらにパートをさらにひとつ削ることになり、最終的には講演時の4つのパート構成としたのがリリース版です。フルレンスでの完全版としては世に出すことはないと思うのですが、削ったパート分はどこかで独立したショートトークみたいに使ったりするかもしれません。 登壇について今年は収録と生配信のいずれかを選択できるようになっていましたが、私は昨年の
Parser gem のバージョニングと RuboCop の TargetRubyVersion - koicの日記
Ruby 2.7.2 にあわせた Parser 2.7.2.0 がリリースされた。 Parser と RuboCop の繋がりは大きいので、この機会に RuboCop で解析する Ruby のバージョン指定との関係も書いておく。 Parser のバージョニング Parser のバージョニングは、最新の安定版 Ruby のパッチバージョンに Parser としてのリリースバージョンを加えたものになる。例えば現在の最新の安定版 Ruby は 2.7 系であり、今回リリースされた Parser 2.7.2.0 は 2.7.2 に対応した最初のリリース (0オリジン) という意味。 Ruby では安定版のパッチリリースで構文へのバックポートが入る場合があるため、安定版のパッチ版リリースごとに Parser のバージョンを揃えておくと丁寧。参考としては Ruby 2.5.5 から 2.5.6 への変
Rails/FilePath の false positive を直した - koicの日記
RuboCop のイシューが 280 を突破していたので、イシューの数を減らすのに bug ラベルを見てたりした。 ちょうど以下が2つ分のイシューを減らせる感じだったので対応しておいた。結果としてレポートからだいたい1年越しくらいの対応になっている。 github.com そのときの再現 tip を書き残しておく。 まずイシューに書かれた (的確な) 再現ケースは解決の最初の糸口になる。自分の場合は /tmp とか適当なディレクトリに a.rb や b.rb といった Ruby ファイルを作って再現コードをコピペして rubocop コマンドを実行するところから始める。その場合、Rails department の場合は rubocop --only Rails/FilePath といった形で Rails department を指定しないと非 Rails プロジェクトの /tmp/a.r
RuboCop 1.0 がリリースされた - koicの日記
RuboCop 1.0 がリリースされた。 github.com 自分が最初にリリースを行った 0.93.1 が RuboCop 1.0 より前の最後のリリースになったというのも感慨深いものがあるけれど、さておきついに 1.0 になった。 よい節目なので RuboCop 1.0 と周辺に関するエントリを書いておこうと思う。 0.93.1 までアップグレードしている人への主な変更 ここまでアップグレードしている人は、1.0 に向けたマイルストーンを達成したひととおりの機能を手に入れています。0.93.1 から 1.0 での主な変更点は以下です。 デフォルトで pending だったコアの Cop がすべてデフォルトで有効になった。DidabledByDefault: true などしているのでなければ、これが一番ユーザーインパクトのある変更だと思う。なお、今後 1 系で追加される Cop は
コミットメッセージアンチパターン: コメント対応 - koicの日記
コミットメッセージには、変更に対する「なぜ」を書く。 週末の余暇のうちに以下のツイートについてもう少しテキスト化しておく。 「コメント対応」というコミットメッセージへの指摘がめんどうなので、クライアントサイドでの git hook を用意した。配置を求めるのがなんだけど。 https://t.co/rbpS0DF2Cw— Koichi ITO (@koic) November 14, 2016 Git など使うことで、ソースコードへの変更理由について、5W1H に沿った変更履歴を知ることができることが理想。 「いつ (When) 」コードに対していつ変更を加えたのかはタイムスタンプを見れば分かる 「どこで (Where) 」コードに対して何を変更を加えたのかはリソース (file/dir) 名で分かる 「誰が (Who) 」コードに対して誰が変更を加えたのかは author を見れば分かる
FactoryBot 0.4.11 での非推奨警告を抑える - koicの日記
FactoryBot 0.4.11 で closed_at 1.day.from_now といった FactoryBot のコードに対して以下のような警告が出るようになった。 DEPRECATION WARNING: Static attributes will be removed in FactoryBot 5.0. Please use dynamic attributes instead by wrapping the attribute value in a block: closed_at { 1.day.from_now } To automatically update from static attributes to dynamic ones, install rubocop-rspec and run: rubocop \ --require rubocop-rspe
Ruby Prize 2018にノミネートされた - koicの日記
Ruby Prize 2018にノミネートされた。 RubyPrize2018｜候補者決定 主に RuboCop へのコミットなどで推薦してもらえたようで、ありがたい話です。 複数の OSS で幅広くと言ってもらえているのは、ghq + gem-src という環境を得ての活動のしやすさというのもあるので、Hacktoberfest も始まっていることでこれからそういった活動に関心のある方には環境を整えるあたりから入ってみるのは良いと思う。 ghq gem-src and more from Koichi ITO www.slideshare.net 環境を整えた先の実例としては、Ruby 2.4 のときの Unified Integer でたしか 30~40 くらいのリポジトリに PR を送ったり、今回 Ruby 2.6 での ERB.new の新インタフェース対応でもいくつかのリポジトリ
Railsのジェネレータにおけるfrozen string literalマジックコメント - koicの日記
Rails で bin/rails g migration create_articles といったようにマイグレーションファイルをジェネレータで作る機会が多いと思う。 % bin/rails g migration create_articles title:string invoke active_record create db/migrate/20171003150532_create_articles.rb % cat db/migrate/20171003150532_create_articles.rb class CreateArticles < ActiveRecord::Migration[5.1] def change create_table :articles do |t| t.string :title end end end 先日 Rails 本体は froz
永和カンファレンス - koicの日記
勤務先のプライベートカンファレンスだった。講演のオファーがあった際に、kakutani が登壇するということと「かんだ光壽」での打ち上げをギャラに引き受けた。自分の講演は去年のアジャイルジャパン長崎サテライトでの講演の再放送の依頼だったため、タイトルを改題して若干の改訂を加えた形での話だった。 スライドについては似たようなものをアップロードしても何だなと思っていることから、今回のスライドを新たにアップロードはしない予定なのでオリジナルのスライドの URL を引用するに留める。 Gate of Agile Web Development from Koichi ITO www.slideshare.net 見積りとブランチ戦略については意外とあまり話されていない気がしているので、何かしら参考になるものは話せたりしたのかなと思ったりしている。 昔なじみの町内会メンバーでの同窓会感もあったりして
2016年卒の一年の成長ふりかえり - koicの日記
勤務先に新卒氏が入社して一年の節目ということで行なった。 一年前の入社時と現在を比べて「できなかった」が「できるようになった」ことをホワイトボードに書き出すといったことを軸に進めていた。 漠然とした「やったこと」がないから「やったことがある」に変わるのは過ごした時間に対して増分する成長といえるが、「コミットメッセージに対して Why を考えて書くようになった」や「git 操作でできることが増えた」というのは、システムのメンテナンスに対して自分の頭で考えて過ごした濃度の上がった時間に対する成長かなと思っている。 来月からは任期一年の新卒氏の称号がなくなった世界を楽しんで成長してもらいたい。
OSSにパッチを出すため動かし方 (Travis CI / Appraisals 編) - koicの日記
Pull Request を出すまでの流れ。例題として RailsAdmin の v1.1.1 を挙げる (master だとそのうちサンプルとしているコードが変わるので) 。 github.com まずはテストの実行まで 途中の手順4でテストが落ちるという出来レースの話があって、そこからが人によって少しお役立ち情報かもしれない。 1. ローカルに持ってくる なにはなくとも手元になければ、 % ghq get https://github.com/sferik/rails_admin もしくは、 % git clone https://github.com/sferik/rails_admin を実行する。 ghq と gem-src を使ったりなどで既に手元にあれば git pull origin master なんかで最新のコードにする。 2. bundle install する %
gtm_railsというgemを作った - koicの日記
Google Tag Manager のスニペットタグ (というかそれに含んだ GTM のコンテナ ID) の出し分けということをしたくなったので、それように作ったもの。近いものとして、google-tag-manager-rails があるが、グローバルにひとつの GTM のコンテナ ID (GTM-XXXX といったもの) を持つ仕組みだったので今回の用途には向かなかった。 ということで作ったのは、複数の GTM のコンテナ ID を設定できる YAML をベースに、ラベル名と Rails.env の値をもとに Google Tag Manager のスニペットタグを出力するというシンプルなもの。 github.com 使い方 Rails アプリケーションの config/google_tag_manager.yml を配置する。例としてはこんな感じになる。 staging: foo:
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
社内向けに「スローテスト勉強会」を行った - koicの日記
RubyKaigi 2018で登壇します - koicの日記
PR済みのブランチを削除して同名ブランチでpushしたらCloseになる - koicの日記
