Disqus - Latest Comments for malesca

Re: Synchronise variant inventory quantity with Shopify Flow

Henrik N — Thu, 30 Oct 2025 13:01:28 -0000

Thank you for letting me know! 😊 Great to hear that it's helpful to others.

Re: Write self-deprecating comments

Henrik N — Fri, 27 Jun 2025 09:57:26 -0000

Oh, thank you! 😊 That's lovely to hear.

Re: Randomize your factories - The Pug Automatic

Henrik N — Sat, 14 Sep 2024 12:57:01 -0000

Hi! I don't think that post makes a convincing case.

Yes, tests should be trustworthy, but I'd argue it's more trustworthy for a test stating "given a user, this behaviour holds" to get a user with random properties – then what is being stated and what is actually happening matches up better. It's less of a lie .

If you intend to test "given a user from the USA with an email address", then make that explicit in the test.

And since a provided seed makes them deterministic, arguably you have the best of both worlds. More truthful tests most of the time that may reveal gaps. And reproducibility when such a gap appears.

Re: Time zones and multidimensional grouping with Active Record and MySQL

Henrik N — Tue, 02 May 2023 12:49:47 -0000

I used this today (10 years later!) and realised it's not intelligent about DST. So if created_at is in a period that should be CEST (UTC + 2) rather than CET (UTC + 1), the code above will be off by an hour.

But this appears to do the right thing:


User.group("((created_at AT TIME ZONE 'UTC') AT TIME ZONE 'Europe/Stockholm')::date").count

If you want it to dynamically use the Rails Time.zone:


User.group("((created_at AT TIME ZONE 'UTC') AT TIME ZONE #{User.connection.quote(Time.zone.tzinfo.name)})::date”).count

For a list of other time zones in this format, see e.g. https://popsql.com/learn-sq....

To further confirm, try something like this in a DB console:


# SELECT (((TIMESTAMP WITHOUT TIME ZONE '2023-03-26 00:59:59') AT TIME ZONE 'UTC') AT TIME ZONE 'Europe/Stockholm');
      timezone
---------------------
 2023-03-26 01:59:59
(1 row)

# SELECT (((TIMESTAMP WITHOUT TIME ZONE '2023-03-26 01:00:00') AT TIME ZONE 'UTC') AT TIME ZONE 'Europe/Stockholm');
      timezone
---------------------
 2023-03-26 03:00:00

Re: Headless Rails for tasks and tests

Henrik N — Wed, 05 Oct 2022 10:12:51 -0000

I did this again recently and updated this Stack Overflow answer with the code I used – it's changed a little: https://stackoverflow.com/q...

Re: UNION with Active Record - The Pug Automatic

Henrik N — Wed, 13 Apr 2022 18:17:56 -0000

I'm now using this in a Rails 6.1 project and it does look like the unprepared statement stuff is indeed no longer needed.

Re: Update with joins in Rails migrations with Postgres

Henrik N — Fri, 08 Apr 2022 05:22:10 -0000

In Rails 5.1+, update_sql is now just update.

Re: Rails/jQuery UI sortables with single UPDATE query – The Pug Automatic

Henrik N — Fri, 11 Mar 2022 09:48:17 -0000

Did this in Postgres again today and made use of the array_position function, e.g.

UPDATE images SET ordinal array_position(ARRAY[3,1,2], id)

which in Rails could be e.g.

ids = params[:ids].map(&:to_i) Image.update_all(["position = array_position(ARRAY[?], id)", ids])

Re: Vim's life-changing c% - The Pug Automatic

Henrik N — Wed, 01 Sep 2021 17:11:14 -0000

Thanks, Josh!

Re: Write self-deprecating comments

Henrik N — Mon, 28 Jun 2021 10:15:34 -0000

Excellent point :) Made me think of this fantastic article: https://thoughtbot.com/blog...

Re: Using load with any? to avoid double queries from Active Record

Henrik N — Fri, 26 Mar 2021 05:24:37 -0000

I just ran into a situation where "load.any?" is worse – if you use counter caches in Rails. So if you have a column buyers.items_count and use counter caches, then "buyer.items.any?" would not make *any* queries, but "buyer.load.any?" would.

Re: Using load with any? to avoid double queries from Active Record

Henrik N — Fri, 05 Mar 2021 12:43:32 -0000

I've now updated the Rails docs for `empty?` and `any?` to suggest using `load` :)

- https://github.com/rails/ra...
- https://github.com/rails/ra...

Re: Systematically removing code – The Pug Automatic

Henrik N — Wed, 18 Nov 2020 15:16:46 -0000

I think I've seen it before but never tried it! Seems rather interesting. Though probably more as something to catch mistakes than something I'd ever do instead of trying to get it right at removal time.

Re: Systematically removing code – The Pug Automatic

Henrik N — Sat, 14 Nov 2020 19:37:04 -0000

The nice thing about live code is that tests will help you not miss a rename. But I agree metaprogramming is a liability. Sometimes worth it; often not.

Re: Systematically removing code – The Pug Automatic

Henrik N — Wed, 11 Nov 2020 16:13:27 -0000

Thank you! 😊

Re: Systematically removing code – The Pug Automatic

Henrik N — Wed, 11 Nov 2020 16:05:26 -0000

Thank you!

Yeah, with a highly dynamic language like Ruby, you can't be guaranteed to find every call to a given method without actually executing every line of code. Well, not even then, since you can do silly things like send("hello#{Time.now.wday}") that will call a different method for each day of the week…

I feel you about searching for a field like `type`. In cases like that, I would (in Ruby) usually search the class/module itself and any descendants (since they can call the method without an explicit receiver) for type, and then search the whole codebase for some likely receivers like item.type and /\bi\.type/ – with a word boundary so it finds "i.type" but not e.g. "pi.type". Word boundary searches are great to decrease the amount of spurious matches.

Still not guaranteed to catch everything, of course, but this gets you pretty far :) And if a piece of dead code evades a systematic search, it's earned its right to stay around a while.

Re: Optimising data-over-the-wire in Phoenix LiveView

Henrik N — Thu, 05 Nov 2020 11:16:37 -0000

Thank you, Andrew! Appreciate it.

Re: Optimising data-over-the-wire in Phoenix LiveView

Henrik N — Fri, 07 Aug 2020 07:22:10 -0000

Thank you! 😊

Re: Optimising data-over-the-wire in Phoenix LiveView

Henrik N — Fri, 17 Jul 2020 05:49:22 -0000

No worries at all! This blog post is part of my own LiveView (and Elixir) learning journey, and these kinds of questions help me learn too :)

https://hexdocs.pm/phoenix_... has some good info, including

> Components run inside the LiveView process, but may have their own state and event handling.

and this section on managing state: https://hexdocs.pm/phoenix_...

Each stateful component must have a unique ID, so if the parent LiveView needs to update a component, it can use that.

If you want to explore this stuff yourself interactively, you can try things like `IO.inspect {:my_pid, self()}` inside a LiveView and/or a component and see what you get. Note that since LiveViews mount twice (a disconnected static HTML render and then a connected one over WebSockets), logging in their mount will log first one PID, then another :)

Re: Optimising data-over-the-wire in Phoenix LiveView

Henrik N — Thu, 16 Jul 2020 06:13:53 -0000

Hi Pablo – and thank you!

My understanding is that each LiveView instance is one process. Components are not their own processes, but effectively "live inside" their LiveView's process.

So if a page renders three LiveViews, each containing 100 components, and two users visit that page (or the same user opens it in two tabs), that would be six LiveView processes.

Re: GitHub Actions - Deploy to Heroku

Henrik N — Sat, 27 Jun 2020 13:02:06 -0000

Thank you for this. To also run migrations, I used https://devcenter.heroku.co... – so adding a line to Procfile, and Heroku runs the migration as part of the release.

Re: Randomize your factories - The Pug Automatic

Henrik N — Wed, 17 Jun 2020 13:06:08 -0000

Hi! Sorry, didn’t see your comment until now.

We can’t practically test everything with every combination of values. If every test tried every possible combination of user gender, with-or-without email, in country A or country B and so on.

It would give better confidence in the code, but likely at too high of a cost.

Randomising factories will give less protection - it may end up never generating an order for a female user without an email address in Norway, triggering some obscure bug - but it definitely increases the chances of finding edge cases compared to running almost all tests every time with the same set of properties.

Re: How we do remote retros – The Pug Automatic

Henrik N — Fri, 20 Mar 2020 17:24:25 -0000

Hm, I think you may be right. Will look into it next week. Thanks!

Re: How we do remote retros – The Pug Automatic

Henrik N — Fri, 20 Mar 2020 17:23:05 -0000

Thanks, Johan! I've had Miro recommended before – it's on my list of tools to try. Will check out Whimsical as well.

Re: Archiving a (Rails) site as static files on Nginx

Henrik N — Sat, 01 Feb 2020 20:51:12 -0000

I just moved this archived site to Netlify.

To host such an app on Netlify instead, you will need to add a custom `_headers` file per https://stackoverflow.com/a.... You'll also need to rename files not to have e.g. "?page=2" in their filenames (left as an exercise to the reader). You can then use a `_redirects` file with rules like `/artists page=:page /artists-page-:page 200` so old links still work.