パッチ会や地域 Ruby コミュニティなどで集めた知見を元に、勤務先の永和システムマネジメントなんかで度々話している表題についてテキスト化しておく。 TL;DR Ruby 2.8.0 の開発が始まっているが、それは 2020 年のどこかで Ruby 3.0 になるらしい Ruby 3.0 ではキーワード引数 (以下 kwargs) の分離という破壊的変更があり、Ruby 2.7 系は事実上の移行パスバージョン的な位置付けになるだろう 2020年1月8日の現時点では、Ruby 2.7 の kwargs の分離警告について対応された安定版の Rails はなく、周辺 Gem も WIP なので OSS エコシステムに参加していくと良い 2.8.0 (tentative; to be 3.0.0) development has started 2019年の ruby/ruby での matz
order、つけ忘れがちですよね。環境が変わると思ってた順番に出なかったりします。 更に厄介なのは、つけ忘れてもなんとなく正しい順番で動いているときで、何かのタイミングで思った順ではなくなってしまうことがあります。というかありました。 多分僕の場合はDBのマイナーアップグレードの影響のように見えました。詳細は追っていないですが、確かに一部でOrder指定が漏れていたので順番が変わってしまったのです。 そういう事態に開発中に気がつけるようにするため、must_be_orderedというgemを作りました。勤めてる会社の社内ハッカソンが8/31にあったので、ちょうどいいネタとばかりにこれを作りました。 gemはこちらにございます。
Shopifyが出しているBootsnapというgemがあります。説明に書いてある通り、巨大なRuby / Railsのアプリを高速化する為のgemらしいです。 何をやってくれるかというと、Ruby, Active Support、YAMLのメソッドの呼び出しの最適化、及び、キャッシュをしてくれる、というものらしいです。 なお、1.0.0の時点でサポートしているプラットフォームはMacOSとLinuxだけです。Windowsは未対応。 また、Rubyは2.3.0以上のみサポートしています。 require 'bootsnap' Bootsnap.setup( cache_dir: 'tmp/cache', # Path to your cache development_mode: ENV['MY_ENV'] == 'development', load_path_cache: true,
ピクスタ開発部で毎日ヒィヒィ言いながらエンジニアをやっております @muramurasan です。 今回はPIXTAのとあるリポジトリにおいて、未使用のメソッドを削除しようとした際、gemを組み合わせることで、効率的かつ安全に削除することができたという話をしたいと思います。 よくやる方式 外部の勉強会などで、「未使用のメソッドを削除する際にどうしているか？」ということを聞いた際、よく聞くのが「未使用らしきコードを見つけ次第、ロギングを行うメソッド呼び出しを挟み込んでいく」というものでした。 この方式は、動的なメソッド呼び出しにも当然対応できますし、お手軽なので、一般的に好まれているようです。 問題点 ただし、この方式では以下の問題点があると私は考えています。 そもそも、未使用らしいメソッドを見つけるのが大変 プロダクションコードを汚してしまう これらの問題を解決するために、PIXTAでは
freeeのkakkunpakkun(略してkp)といいます。マイクロサービスおじさんです。 freeeではモバイルバーサーカーとかフロントエンド革命家など、独自の名前が多いですが、私は「分割おじさん」「認証おじさん」「rspecおじさん」などと呼ばれたりしてきました。 バーサーカーや革命家と比べてかっこ良くないのがなんだか気になる今日このごろです。 今日はおじさんらしく細かくて面倒な話をして、その対策としてfreeeで使ってるgemを公開したのでその説明をしようと思います。 パスワードはDBでハッシュ化していても簡単に見えてしまう 「パスワードが見えてしまう」というのはすごい不安になる言葉ですが、あまり考えずにサービスを開発していると簡単に起こる事象です。 ではどこでそういうことが起こりやすいのでしょうか。 DBにハッシュ化したパスワードを保存するのはかなり一般的になり、各種ライブラリも
id:joker1007 さんに触発されました。 Ginza.rb 21回の発表資料。rails_adminのつらみとオススメgem達。 1年間で10個以上アプリやgemを作っている中でよく使うgemをまとめてみます Railsアプリ（rails new した直後に必ず入れる） annotate https://github.com/ctran/annotate_models modelのソースの先頭にテーブルのスキーマ情報を付加してくれるgem。いちいちschema.rbを見に行く必要がなくなるので超ベンリ こんな感じ # == Schema Information # # Table name: plugins # # id :integer not null, primary key # name :string # title :string # version :string #
ginzarb_21.md rails_adminのつらみとオススメGemについて rails_adminのつらみ カスタマイズできるようで出来ない rails_adminをカスタマイズする方法まとめ - Qiita レコード件数が一定以上になると使えない機能 ダッシュボード 何も考えずに各モデルをカウントするのでレコード件数増えるとえらいことになる。 関連を付け替えするフォーム 出したり出さなかったりを一々切り替えるのがめんどい 検索機能がほぼ役に立たない じゃあどうするか プロジェクト用のscaffoldを作る方が良いのでは？ 一つのモデルに対するを管理画面を作って大まかなレイアウトを決める それをテンプレート化してlayoutとscaffoldのテンプレートを上書きする コントローラーの構成もテンプレートで上書きできる それ以上の場合はlib以下にgeneratorを書く Rails
Railsで404や500といったエラーページを動的に表示するrexceptionというGemを公開しました。 インストール方法 Gemfileに以下を書いてbundleするだけで使えます。 gem 'rexception' 使い方 最もシンプルな使い方は、app/views/errors/application.html.erbにビューを配置するだけです。 これで、（捕捉可能な）すべての種類のエラー発生時に、対応するステータスコードとともにビューをレンダリングします。 not_found.html.erbやinternal_server_error.html.erbなど、ステータスに対応するビューを配置した場合、そのビューがapplication.html.erbよりも優先して表示されます（ファイル名はこの辺りの実装に準じています）。 また、レイアウトやエラーファイル配置ディレクトリ、独
Gitのブランチ名をもとにActiveRecordが接続するDBを切り替えるRubygemを作った。 使い方 group :development do gem "brancher" end Gemfileに書いてbundle installするだけ。あとは自動的にブランチごとに別々のDBが使われるようになる。 config/database.ymlでdevelopment環境のDB名をsample_app_devと指定していた場合、masterブランチならsample_app_dev_masterが使われるし、some_featureブランチならsample_app_dev_some_featureが使われる。 問題意識 複数のブランチを移りながら開発していると、migrationを実行したブランチとしてないブランチでDBのスキーマが不整合になってエラーをおこすことがよくある。そのたびに
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
