Ruby / Rails の企業として新卒氏が入社した後にウォッチするように伝えるもの - koicの日記
先日、神速さんのエントリを見てあとで書こうと思ったもの。 表題ママだけれど、Ruby / Rails の企業として新卒氏が入社した後にウォッチするように伝えているもの。もちろん流量も結構なものなので実際にどの程度ウォッチしているかは本人に委ねている。自分も全部は見れていない。メールでのタイトルか送信者 (PR や Issue を出した人) で興味を引かれたものが基準。 Rails 研修での Rails Tutorial の流れで、upstream とそれに近い情報源を伝えている。特に y-yagi さんのブログは、子供の頃に読み始めた新聞と同じで最初は分からなくても読み続けているうちに分かることが増えてくるので継続するのが力になることと共に伝えている。 GitHub 上のリポジトリ https://github.com/rails/rails ... ruby/ruby のリポジトリと一緒
銀座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年目以降いつなんどき遭遇するかもしれないポイント」みたいな形で話を構成してみた。当日のスライドは以下。 静的サイトジェネレー
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
Gemfileでのgitオプション利用のリスク - koicの日記
去年の失敗談から。まだ RubyGems にリリースされていない gem について、git オプションを使って以下のような指定をした。多少改変しているけれどだいたいこんな感じ。イメージは伝わると思う。 # Use therubyracer from GitHub until cowboyd/therubyracer#413 is released. # # therubyracerにRuby 2.4対応の以下のコミットが含まれたリリースがされたらgitオプションを削除できる。 # https://github.com/cowboyd/therubyracer/commit/f5966bb55a4b0434964d66ef765907d940b4c109 gem 'therubyracer', git: 'https://github.com/cowboyd/therubyracer', r
RubyWorld Conference 2016 1日目 - koicの日記
RubyWorld Conference 2016 1日目だった。 2016.rubyworld-conf.org Matz のキーノートセッションで話されていた、Matz 自身のプレゼンテーションなどの活動がラリーウォールにも影響を受けているといった話は Matz のプレゼンについて改めて興味を持つ話だった。また、もともとはプラモデルを組むような感じで Ruby を作ってたら、社会での位置づけがとても大きくなって自分でも想像していなかった立ち位置になったというのは印象深い話だった。 午後の miyohide さんの発表。mruby 自体はとても薄く作ってあるため CRuby と比較して足りていないと思った機能はまず mrbgems にあたってみるなど、 mruby を使ったことのない立場としては実例を元にしたストーリーでポイントを聞けたのが良かった。 その少し後のセッションで見たかった
RubyWorld Conference 2016 2日目 - koicの日記
RubyWorld Conference 2016 2日目。午前中はブース番をしつつ話を聞いたりブースに来てくれた人との話をしたりしていた。 ランチを挟んだ午後は takai の話を聞きに行く。テストがない Perl のレガシーコードを Rails に置き換えていった話。最初に画面一杯の Perl のコードが 3行の Rails のコードになったというコードを使った掴みから、Rails に置き換えていった後の Pull Request の量が毎月増えて行っているグラフという話の伏線回収が上手いなと思った。この PR 量が増えて行く話のくだりを聞いた際に、 Rails に移行したから PR が増えたという変化もあると思う一方で、チームとして成熟していっているからというのも伝わって全体としての話の整理の仕方が勉強になった。あと、"2007年当時に Rails を選択するというのはリスクだった"
frozen string literal in Ruby
表参道.rb#5 (http://omotesandorb.connpass.com/event/20289/)Read less
Detroit Programming City
37. 2→８ |--- 13667 koic say -v Ralph deeeeeeeeeeeattttth |--- 13669 koic say -v Ralph deeeeeeeeeeeattttth |--- 13671 koic say -v Ralph deeeeeeeeeeeattttth |--- 13673 koic say -v Ralph deeeeeeeeeeeattttth |--- 13676 koic say -v Ralph deeeeeeeeeeeattttth --- 13679 koic say -v Ralph deeeeeeeeeeeattttth Core数の増加
私が見てきたあるセカイの物語 Part I & II
49. • map 4票 • Enumerable#inject 3票 • p 3票 • each 2票 • instance_eval 2票 • gsub 1票 • === 1票 • String#scan 1票 • collect 1票 • method_missing 1票 • Regexp#to_s 1票 • yycompile 1票 • Object#extend 1票 • Kernel#send 1票 • collect 1票 • String#slice(regexp, n) 1票 • module_eval 1票 • GC.start 1票 • Enumerable 1票 • class_eval 1票 • Thread.new 1票 • あえて作らない 1票 • do 1票 注) 職人の手作業に つきバグ混入ご免 ランキング(2015.06.04時点)
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
The three great virtues are important
Project automation for internal affairs
10年生きる Ruby / Rails アプリケーションプログラマーのエコシステム
プロの無職についての考察:序
インタフェースのこころ
Agile Estimating and Planning:the Yin Side
Koichi ITO