Updates from October, 2021 Toggle Comment Threads | Keyboard Shortcuts

  • ThomasPowell 7:58 am on October 9, 2021 Permalink | Reply
    Tags: , , m1 mac, node-sass,   

    Error on an M1 Mac loading Rails: node-sass refusing to compile. 

    M1 Mac specific error

    In trying to transfer and restart development on a Rails 6.1.3 app and get it up-to-date, I got an error on an M1 Mac about node-sass not supporting my current environment (the M1 Mac’s ARM 64 architecture).

    ERROR in ./app/assets/stylesheets/application.scss (./node_modules/css-loader/dist/cjs.js??ref--6-1!./node_modules/postcss-loader/src??ref--6-2!./node_modules/sass-loader/dist/cjs.js??ref--6-3!./app/assets/stylesheets/application.scss)
    Module build failed (from ./node_modules/sass-loader/dist/cjs.js):
    Error: Node Sass does not yet support your current environment: OS X Unsupported architecture (arm64) with Unsupported runtime (93)

    Just yarn install?

    Unsurprisingly, this didn’t work, but my first instinct was a yarn install: and a few errors presumably unique to the M1 Mac (or maybe Big Sur’s Xcode environment) showed up:

    ../src/libsass/src/ast.hpp:1616:14: note: use reference type 'const std::basic_string &' to prevent copying
    for (const auto denominator : denominators)
    /Users/tpowell/.node-gyp/16.10.0/include/node/v8-internal.h:489:38: error: no template named 'remove_cv_t' in namespace 'std'; did you mean 'remove_cv'?
                !std::is_same<Data, std::remove_cv_t<T>>::value>::Perform(data);
    1 error generated.
    make: *** [Release/obj.target/binding/src/binding.o] Error 1
    gyp ERR! build error
    gyp ERR! stack Error: `make` failed with exit code: 2
    gyp ERR! stack     at ChildProcess.onExit (/Users/tpowell/projects/blog-post-debug/self-journal/node_modules/node-gyp/lib/build.js:262:23)
    gyp ERR! stack     at ChildProcess.emit (node:events:390:28)
    gyp ERR! stack     at Process.ChildProcess._handle.onexit (node:internal/child_process:290:12)
    gyp ERR! System Darwin 20.6.0
    gyp ERR! command "/opt/homebrew/Cellar/node/16.10.0_1/bin/node" "/Users/tpowell/projects/blog-post-debug/self-journal/node_modules/node-gyp/bin/node-gyp.js" "rebuild" "--verbose" "--libsass_ext=" "--libsass_cflags=" "--libsass_ldflags=" "--libsass_library="
    gyp ERR! cwd /Users/tpowell/projects/blog-post-debug/self-journal/node_modules/node-sass
    gyp ERR! node -v v16.10.0
    gyp ERR! node-gyp -v v3.8.0
    gyp ERR! not ok
    Build failed with error code: 1

    Upgrade to node-sass compatible with the M1 Mac via @rails/webpacker

    The const auto denominator error led me to this StackOverflow answer. The last time I had downstream dependency issues, the cleanest resolution was upgrading the @rails/webpacker using outdated dependencies in package.json. The current version is 5.4.3:

    <     "@rails/webpacker": "5.2.1",
    >     "@rails/webpacker": "5.4.3",

    After this a yarn install should work fine. (Your need to delete node_modules may vary). Now the assets are compiling and page rendering properly:

    M1 Mac now rendering Bootstrap
    I guess I’ve never been so happy to see Bootstrap-style buttons.
  • ThomasPowell 9:48 pm on August 25, 2021 Permalink | Reply
    Tags: , , group, ,   

    Getting a Count of Occurrences of Items in a Ruby Array (and a Caveat for Rails) 

    I feel like I’m often wanting to count occurrences of items in an array (Rails has its own special case as well), and I’m always trying to do it the “long way.”

    I finally stumbled upon this answer on StackOverflow that details the version-by-version options:

    • Ruby 2.7+ use .tally directly on the array:
    irb(main):006:0> %i{a b c c d c e b a a a b d}.tally<br>=> {:a=>4, :b=>3, :c=>3, :d=>2, :e=>1}
    irb(main):011:0> %i{a b c c d c e b a a a b d}.group_by(&:itself).transform_values(&:count)
    => {:a=>4, :b=>3, :c=>3, :d=>2, :e=>1}
    irb(main):012:0> %i{a b c c d c e b a a a b d}.group_by(&:itself).map { |k,v| [k, v.length] }.to_h<br>=> {:a=>4, :b=>3, :c=>3, :d=>2, :e=>1}

    The Rails Exception

    It’s a pretty common temptation, especially once you start thinking in terms of the list of items you want to count, to try to use a pure Ruby solution for things. But what if your source is from the your database?

    The key here is the database. You probably don’t want to load all of the records from the database just to count them using the above methods, and SQL has a GROUP BY clause which is just called .group.

    irb(main):013:0> Entry.group(:user_id).count
    D, [2021-08-26T02:49:43.996743 #4] DEBUG -- :    (1.2ms)  SELECT COUNT(*) AS count_all, "entries"."user_id" AS entries_user_id FROM "entries" GROUP BY "entries"."user_id"
    => {1=>231, 4=>15, 2=>2}

    This output is tallying entries by what User (via user_id) entered them. More importantly, the SQL used did the counts within the database without retrieving any data contained into the application except what was counted. (This used to be a pun on the :what column in the entries table, but apparently we’re not there with proper rendering and cutting and pasting of emojis between apps and OSes and well, I enter emoji as part of my entries in this app.

    This original example in extreme wide screen glory
  • ThomasPowell 1:15 pm on August 7, 2021 Permalink | Reply
    Tags: , find_each, ,   

    Use find_each vs. select or each when needing to process each record via Ruby 

    The problem:

    This scenario is a much more practical case of a similar concept with Rails / ActiveRecord count, size, and length. In this case, you’re needing to run ruby code off of either every value from a where method result or a subset that is determined by ruby code. For example, assume that a model Entry has a method after_sunrise (probably want a real sunrise/sunset gem but this is a simplistic example) as follows:

      # determine if a time included in the string description of the entry is after sunrise
      # nil (falsey) if not found
      def after_sunrise
        notated_time = what.match('\d+:?\d* ?[AP]M')
        return nil if notated_time.nil?
        (Time.parse([date.to_s, notated_time].join(' ')) > 
          Time.parse([date.to_s, "6:30 AM"].join(' ')))

    Using select for filtering will cause the result from where clause to be loaded all at once:

    irb(main):178:0> entries = Entry.where(private: false).select { |entry| entry.after_sunrise } #.each { do something with each record here }
    D, [2021-08-07T17:53:52.492261 #4] DEBUG -- :   Entry Load (10.4ms)  SELECT "entries".* FROM "entries" WHERE "entries"."private" = $1  [["private", false]]

    find_each for the batch

    If you don’t have very many records, this isn’t a big deal, but if you have models with a lot of data per model instance and you have millions of rows, you risk running out of memory trying to load it all at once. Anytime you take the result of a query or association and try to switch to operating on it like an array of ruby objects, you force the lazy loading of ActiveRecord::Relation and ActiveRecord::Association::CollectionProxy to load those records.

    If you switch to find_each you can load those records in batches:

    irb(main):179:1* entries = Entry.where(private: false).find_each do |entry|
    irb(main):180:1*   next unless entry.after_sunrise
    irb(main):181:1*   # do something with each record here
    irb(main):182:0> end
    D, [2021-08-07T17:57:07.895360 #4] DEBUG -- :   Entry Load (5.1ms)  SELECT "entries".* FROM "entries" WHERE "entries"."private" = $1 ORDER BY "entries"."id" ASC LIMIT $2  [["private", false], ["LIMIT", 1000]]
    => nil

    I only have 214 records in this example database, so the default batch size of 1000 makes this look almost identical to the original. However… you can use a keyword argument of batch_size: to tune the size of the batches pulled, in case your records are small and so more than 1000 records can be loaded at a time or they’re large and 1000 records is too much, or you have contrived example and want to show it actually batching:

    irb(main):184:1* entries = Entry.where(private: false).find_each(batch_size: 2) do |entry|
    irb(main):185:1*   next unless entry.after_sunrise
    irb(main):186:1*   # do something with each record here
    irb(main):187:0> end
    D, [2021-08-07T17:59:22.339190 #4] DEBUG -- :   Entry Load (1.9ms)  SELECT "entries".* FROM "entries" WHERE "entries"."private" = $1 ORDER BY "entries"."id" ASC LIMIT $2  [["private", false], ["LIMIT", 2]]
    D, [2021-08-07T17:59:22.344225 #4] DEBUG -- :   Entry Load (1.8ms)  SELECT "entries".* FROM "entries" WHERE "entries"."private" = $1 AND "entries"."id" > $2 ORDER BY "entries"."id" ASC LIMIT $3  [["private", false], ["id", 8], ["LIMIT", 2]]
    D, [2021-08-07T17:59:22.347152 #4] DEBUG -- :   Entry Load (1.9ms)  SELECT "entries".* FROM "entries" WHERE "entries"."private" = $1 AND "entries"."id" > $2 ORDER BY "entries"."id" ASC LIMIT $3  [["private", false], ["id", 10], ["LIMIT", 2]]


    The difference between chaining .each or .select off of a .where clause vs. chaining .find_each is something you won’t necessarily see the benefits of if you’re building something from the ground up and don’t have much data flowing through your application. You may even even have a successful launch until you grow an order of magnitude or so. That’s part of the challenge of recognizing the need for it.

Compose new post
Next post/Next comment
Previous post/Previous comment
Show/Hide comments
Go to top
Go to login
Show/Hide help
shift + esc
%d bloggers like this: