Compose, customize, and extend every part of the commerce stack—from storefront to checkout to backend integrations—and create unique experiences for your brand or millions of merchants around the world.

Compose, customize, and extend every part of the commerce stack—from storefront to checkout to backend integrations—and create unique experiences for your brand or millions of merchants around the world.
はじめに JSON でなく HTML を送ることでモダンなウェブアプリケーションを開発できる Hotwire に少し前から興味がありました。 Hotwireとは何なのか? を始めとした日本語の情報を拾い読みしていたのですが、 ユーザにとっても、開発の進め方も Progressive Enhancement にできること と書かれていたりして、わかったような、わからないような。 で、Hotwire を開発した DHH 氏みずから Hotwire の使い所を解説していた Podcast があって聞いてみたら、とてもわかりやすくて納得した。 » 151: DHH – Building HEY with Hotwire | Full Stack Radio 実際にデモアプリを作りながら、Hotwire がどういうものなのかを見ていきます。 クラシックなウェブアプリを作る まずは現時点で最新の Ru
概要 原著者の許諾を得て翻訳・公開いたします。 英語記事: Comparison of class level accessors in Ruby On Rails 公開日: 2017/07/24 著者: Błażej Kosmowski サイト: selleo.com 参考: Rails API cattr_accessor -- Module 参考: Rails API class_attribute -- Class 2017/10/19: 初版公開 2023/07/31: 更新 attr_accessorは、インスタンス変数のgetterとsetterを提供する非常に有用なマクロです。これと同じ効果をクラス変数でも得られれば、クラス変数でクラスを設定できて便利な場合もあります。 そのための方法として、少なくともattr_accessor、cattr_accessor、class_a
パッチ会や地域 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
こんにちは。メドピアのRuby(Rails)化をお手伝いしている@willnetです。最近はエンジニアが増えた影響か、Railsの質問に答えていることが多いです。 以前、Railsの太ったモデルをダイエットさせる方法についてというタイトルでPOROを使っていこうという話を書きました。その際にコード例などもなるべく多く載せるようにしたのですが、このエントリだけを読んだ状態では、いざ「POROを使ってみよう!」としたときにまだ悩む余地がありそうです。 POROはその名の通り普通のRubyオブジェクトなので、いろんな書き方ができてしまいます。それなりに経験がある人でないと、どのように書いたらいいんだろう…と悩んで時間を使ってしまいそうですね。さらに、複数人で開発しているチームだと書き方のバラツキも気になるところです。きっと、POROを書くときのお作法が決まっている方が開発しやすいはず。 そこで、
Note: Rails versions of these apps are valid as the date of latest commit. They are defined in their Gemfile and/or Gemfile.lock and they might be outdated. If you find it outdated, don't forget to notfiy us by opening a pull request. FAE - A modern CMS developed by FINE (using Rails 5.2) activeWorkflow - An intelligent process and workflow automation platform based on software agents (using Rails
FactoryBot is one of my favourite testing tools — I was a fan prior to joining thoughtbot. It’s one of those tools I miss immediately when working outside the Ruby ecosystem. Recently I’ve been working on a Rails project that doesn’t need any database persistence and therefore doesn’t use an object-relational mapper like ActiveRecord. Instead data is fetched from an external JSON API and parsed in
http://eng.joingrouper.com/blog/2014/03/03/rails-the-missing-parts-interactors 3 comments | 0 points | by WazanovaNews ■ comment by Jshiike | 約2時間前 飲み会アレンジサイトGrouperが、同社のエンジニアブログで、規模の大きなRailsアプリをパフォーマンスよくつくるときの工夫を提案をしてますが、それに対してRailsのクリエーターのDHH (Basecamp / 37 Signals) が厳しいコメントを残しています。 1) Grouperの提案 問題意識 Railsは、コードベースが千行を超えると、テストスイートが遅くなりがちで、フレームワークのロードタイムが増える。 よくあるのは、ビジネスロジックのほとんどがActiveRecord /m
先月、heroku の推しサーバが unicorn から puma に変わったという発表がありました。unicorn だとスロークライアントの影響を受けやすいというのが理由なようです。 もう少し詳しく調べてみましょう。 そもそもスロークライアントってなに その名の通り遅い回線のクライアントです。3G環境のモバイル端末などが該当します。 「unicorn だとスロークライアントの影響を受けやすい」とは unicorn はプロセスモデルのサーバであり、blocking I/O モデルを採用しています。つまり、クライアントとの通信中プロセスが専有されるということです。 例えば unicorn がワーカプロセスを3つ立ち上げていて、そこへ通信完了に10分かかるようなスロークライアントが3つ接続されたら…、続くクライアントはスロークライアントの通信が完了するまで実行を待たなければならなくなります。プ
pry(main)> a.try(:[], :email) # => nil pry(main)> a.try(:fetch, :email) # KeyError: key not found: :email from /home/vagrant/.rbenv/versions/2.1.5/lib/ruby/gems/2.1.0/gems/activesupport-4.1.8/lib/active_support/core_ext/object/try.rb:45:in `fetch' #となりますので、fetchの場合は、以下のようにします。 pry(main)> a.try(:fetch, :email, nil) => nil
RailsのConcernで使われるモジュール名はたしかに xxx-able となっているものが多いです。 実際僕もよく xxx-able という名前のモジュールを作ります。 が、これはあくまで慣習であり、規約ではありません。 なので、xxx-able以外のモジュール名にしても全く問題ありません。 一般論として、クラス名/モジュール名やメソッド名には「わかりやすい名前」を付けるのが原則です。 なので、たとえば「includeすると タグが使える ようになるモジュール」であれば、「タグが使える = Tag + able = Taggable」という名前を付けるとわかりやすい、ということになります。 ですが、絶対ではないので、Taggableよりも適切な名前があると考えるのであれば、別の名前を付けるのもアリです。 とはいえ、「Concernであればxxx-ableにする」というのがRailsの
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く