Forem: Jared Norman

Anonymous Struct Literals Might Be Coming To Ruby

Jared Norman — Tue, 07 Jul 2020 15:38:44 +0000

There's been some really interesting discussion in the Ruby community about adding anonymous struct literals to the language. My Japanese isn't very good (I don't speak Japanese), but Koichi Sasada and Matz had a little Twitter exchange about the idea and that's now turned into a proposal on the Ruby tracker where there's been further discussion.

_ko1

@_ko1

@yukihiro_matz just idea なんですが、無名Structを簡単に作る仕組みをいれるのはどうでしょうか。同じキーセットなら、同じ無名 Struct が返るような感じで。

07:30 AM - 25 Jun 2020

3 14

What's a Struct?

Ruby provides Structs as a convenient way to create classes that group together a set of fields without forcing you to explicitly define a class with all the accessor methods.

For example, if you needed to pass around a representation of a dog but didn't need any additional behaviour you might do something like this:

[1] pry(main)> Dog = Struct.new(:name, :breed, :age)
=> Dog
[2] pry(main)> roxie = Dog.new("Roxie", "whippet-cross", 4)
=> #<struct Dog name="Roxie", breed="whippet-cross", age=4>
[3] pry(main)> roxie.name
=> "Roxie"
[4] pry(main)> roxie.breed
=> "whippet-cross"
[5] pry(main)> roxie.age
=> 4
[6] pry(main)> roxie.age = 5
=> 5
[7] pry(main)> roxie2 = Dog.new("Roxie", "whippet-cross", 5)
=> #<struct Dog name="Roxie", breed="whippet-cross", age=5>
[8] pry(main)> roxie == roxie2
=> true

Because instances of Structs are equal if their attributes are all equal, it makes them a great solution for defining value objects.

What does the proposal add?

There's some disagreement on the syntax, but the idea is to add a syntax for defining anonymous instances of Structs in-line. Today, you might write this:

roxie = Struct.new(:name, :breed).new(
  "Roxie",
  "whippet-cross"
)

With this proposal you'd be able to simply write something like this instead:

roxie = ${name: "Roxie", breed: "whippet-cross"}

This would create an instance of an anonymous Struct class without having to explicitly define and instantiate the class.

Why is that useful?

There are actually a number of benefits to this, but let's start with why anonymous Structs are useful regardless of the syntax.

Structs avoid typos

In Ruby we often use hashes for passing around things like configuration options and other structured data. Structs allow us to do this without allowing arbitrary properties.

In our dog example above, roxie.breeed = "pug" will cause an error because we spelled "breed" incorrectly and the Struct doesn't have a member called "breeed". If were using a Hash instead then we'd be able to accidentally assign roxie[:breeed] = "pug" without any errors, accidentally creating a new typoed key in the Hash.

There are many cases where you need arbitrary properties, but for those cases you can use OpenStruct or a Hash. When accepting configuration from a user or any other situation where you know the possible fields in advance Structs work great.

Anonymous Structs communicate intent

Writing code that communicates its own intent clearly is useful for helping future developers understand and modify that code. Using an anonymous Struct rather than a Hash or OpenStruct communicates to the person reading the code that the fields the object is defined with are the only fields that object supports.

Structs are simpler to access

This is admittedly a small improvement, but it's simpler to type roxie.breed than roxie[:breed]. In this example roxie doesn't represent an arbitrary mapping of keys to values, but a dog, so if we're following conventional object-oriented design practices, then roxie should be an object that responds to messages about itself.

Using Structs over Hashes also means that refactoring the code to use a real Class won't mean you need to change everywhere its data is accessed.

OpenStruct is slow

OpenStruct is another class in the standard library that provides the ability to create objects that are basically like Structs, but are "open" to creating new attributes like Hashes are.

This is extremely useful if you need to support arbitrary attributes on the object, but if you don't you're just opening yourself up to the same issue as using a Hash:

[1] pry(main)> roxie = OpenStruct.new(name: "Roxie", breed: "whippet-cross")
=> #<OpenStruct name="Roxie", breed="whippet-cross">
[2] pry(main)> roxie.breeed = "french bulldog"
=> "french bulldog"
[3] pry(main)> roxie
=> #<OpenStruct name="Roxie", breed="whippet-cross", breeed="french bulldog">

Additionally, while OpenStructs are definitely great when you need their "open" functionality, they are much slower than regular Structs. Koichi Sasada notes this in the performance section of his proposal.

But it says in the proposal that Hashes are faster!

One interesting detail that the proposal brings up is that Hashes are currently faster than Structs for this kind of usage. This is true, but Hashes have seen plenty of optimization because of how heavily we rely on them.

You would think that Structs would be faster than Hashes since their behaviour is simpler. Well, that's not the case but Koichi Sasada is confident that it could be the case with some optimization.

This proposal also enables a whole new optimization that is only briefly mentioned:

Thanks to this spec, we can specify anonymous Struct classes at compile time. We don't need to find or create Struct classes at runtime.

Because the attributes of the Structs is known at parse time rather than run time, it is possible to define the anonymous classes at compile time so that using this syntax incurs only the overhead of instantiating the anonymous class without having to define it too.

What does it mean for you?

For now, not much. We can't use this in our programs yet, but we are free to use anonymous Structs in our code without the special syntax. If you're creating value objects, want to limit the attributes on your object, or just want to make refactoring easier, this isn't a bad idea.

That said, keep an eye on this proposal. Switching to this syntax in your applications when it becomes available could have performance benefits, save on typos, and make your code clearer.

What do you think about this new syntax? Let me know on Twitter!

Working Around ActiveRecord Callbacks

Jared Norman — Tue, 10 Dec 2019 16:05:10 +0000

This article was original posted over here on the Super Good Software website.

Working on applications that overuse ActiveRecord callbacks can be painful. Saving or updating any given record might cause a cascade of API calls and business logic that's totally irrelevant to what you're trying accomplish. I've got a great trick for working around troublesome callbacks by allowing you to easily prevent them from running as needed.

I strongly believe that business logic shouldn't be implemented using ActiveRecord callbacks. Callbacks are great for data normalization and caching computed values. Sending e-mails, making API calls, and other side-effects should be implemented using some other programming pattern that untangles the logic from your persistence layer. Excessive use of callbacks leads to slow test suites, brittle systems, and unintended changes.

I run into many applications with complex third-party API integrations that are fueled by these cascades of after_save, after_create, and after_commit callbacks and are difficult to understand and debug. Ideally I'd love to untangle these messes and pull out the business logic into classes that can easily be understood and tested separately from the persistence layer, but I don't always have the time to do that.

Imagine this situation: you've got an Address model with a before_save callback that fetches and sets the latitude and longitude for that address. You're on a deadline and don't have the time to refactor every location in the code where you create an address. The callback is also slowing down your test suite because it's making slow requests out to the geolocation API every time you create an address. What's more, you've found some locations in the app where you create addresses and already know the coordinates. In these scenarios you don't need to do the lookup, but the lookup is being performed anyway.

You could address the test suite speed issue by using something like VCR, but with a few hundred tests creating addresses, that'll generate a ton of cassettes and doesn't solve the problem of the unnecessary API calls anyway.

There's a solution that alleviates both these problems with minimal effort. Let's say our address class looks like this:

class Address
  before_save :set_geolocation

  private

  def set_geolocation
    # Hit some API or something...
  end
end

What we can do is add an attr_accessor to control whether we want to perform geolocation and then condition the callback on that attribute. (attr_accessor :disable_geolocation is a handy shorthand for defining a disable_geolocation reader method and a disable_geolocation= writer method.)

class Address
  attr_accessor :disable_geolocation
  before_save :set_geolation, unless: :disable_geolocation

  private

  def set_geolocation
    # Hit some API or something...
  end
end

Now when updating or creating our addresses we can pass in this attribute to control whether geolocation is performed:

# This one will still cause geolocation:
address = Address.create(
  line1: "910 Government St",
  city: "Victoria",
  province: "British Columbia",
  country: "Canada"
)

# Here we prevent geolocation from running:
address.update(
  disable_geolocation: true,
  line1: "1328 Douglas St"
)

This works because ActiveRecord methods like update and create basically just assign the values you pass in, so it doesn't matter that disable_geolocation isn't backed by a database column. This also means that you can update your factory definitions:

FactoryBot.define do
  factory :address do
    name { "Jardo Namron" }
    sequence(:street_address) { |n| "#{n} Fake St." }
    city { "Vancouver" }
    province { "British Columbia" }
    country { "Canada" }

    disable_geolocation { true }
  end
end

When you create addresses using the factory you won't get geolocation by default, but can opt in as needed.

# No geolocation!
address1 = FactoryBot.create(:address)

# Yes geolocation!
address2 = FactoryBot.create(:address, disable_geolocation: false)

This pattern comes in really handy when you don't have the time to make the larger architectural changes to remove the offending callbacks altogether. It's definitely a hack; externally controlling an object's behaviour like this is an antipattern by my standards, but it extends well to more complex situations and cleanly addresses the immediate problem, so I hope you find it useful.

My 2020 Reading List

Jared Norman — Sun, 08 Dec 2019 23:10:16 +0000

This was originally published on my personal site, here.

At the beginning of 2019 I set out to read (or listen to) at least one book every month this year. It turned out that this was a poorly considered goal; I'd well exceeded that reading pace in 2018 and did so again in 2019. I don't have an exact count on the number of books I've finished this year, but I suspect it's around 30 (based on a quick glance at my Kindle/Audible libraries and bookshelf.)

This coming year I've committed to do more actual reading rather than listening to audiobooks. Of the books I finished last year, I'm sure no more than 5 were physical or kindle books. I normally listen to audiobooks while running, weightlifting, doing chores, and just relaxing, so it's relatively easy for me to work through a couple per month.

In 2020 I want to make better use of my reading time. I want to get more out of the books I read. To that end, my focus will be on continuing to make time for focused reading. I've already been doing a lot more this month due to the "digital declutter" I mentioned in my last post; the reduced screen time has so far created quick a lot of extra time and I've spent a solid amount of it buried in books.

What I'm Looking Forward To

I've reviewed my notebooks, my scribbled recommendations, and done some research of my own to compile a first draft of what I'd like to read in 2020. Here are a few titles I'm particularly looking forward to reading for the first time:

The Bell Jar by Sylvia Plath: I'm pretty ignorant when it comes to poetry, but I'm going to fix that in 2020. Before I dive into her poetry, I plan to read Plath's semi-autobiographical novel, The Bell Jar.
On Writing Well by William Zinsser: I like to think of myself as being reasonably articulate in writing, but would love to improve. I really enjoy writing and haven't put any serious effort in improving at it (other than just writing blog posts) in more than a decade. I hope this will reignite some of my interest in the practice.
Starting to Unit Test by Erik Dietrich: Unit testing is pretty second nature to me, so I'm going to look back to the fundamentals this year to see what I've missed along the way. I'm sure there are gaps to fill.
Domain-Driven Design: Tackling Complexity by Eric Evans: Domain-driven design is an approach I'm familiar with, but have never really dived into. This year I'm going to remedy that by reading this title as well as Vaughn Vernon's Implementing Domain-Driven Design.
Compilers: Principles, Techniques, and Tools by Aho, Sethi, and Ullman: I've always wanted to read "The Dragon Book" and I'm hoping this year to work through it. I don't have a specific goal in reading this book, but I hope to fill in some blank spots left from having not taken the programming languages course when I was in university.

I've also found a number of books in my collection in need of a second (or third, or fourth) pass. Here's a few that stand out:

Working Effectively with Legacy Code by Michael C. Feathers and Growing Object-Oriented Software, Guided by Tests by Steve Freeman and Nat Pryce: After I've finished Starting to Unit Test I want to reread these two classics on unit testing. I know I've internalized many lessons I took away from them when I first read them, but it's definitely time to see what more I can get from them.
The C Programming Language by Kernighan and Ritchie: I actually own a first edition copy of this book, though it's in horrible shape. I accidentally ripped the front cover off while pulling it out of my bag, so it's now taped back together. I haven't seriously written any C in ages, but I have fond memories of reading this one as a teen and am excited to revisit it.
The Mythical Man-Month: Essays on Software Engineering by Brooks: This should be an annual read for anyone who runs any kind of software organization. Aside: I'm sad that the giant sloths depicted on the cover aren't still roaming the earth. I've considered getting a tattoo of one because a) they are extremely cool and b) "adding manpower to a late software project makes it later".

I'm sure it will grow and change over the course of the year, but you can find the full list of books on my Goodreads account along with what I'm reading now.

If you've got any book recommendations, please tweet at me!

Solidus Conf 2019 In Review

Jared Norman — Thu, 31 Oct 2019 18:25:15 +0000

This post was originally posted on the Super Good website here.

Last week, the Solidus community gathered in Salt Lake City to discuss the future of the platform and ecosystem. Over the course of four days, we discussed where we're at, where we're headed, and laid the groundwork for moving the platform forward.

The History of Solidus Conf

Solidus Conf has existed in some form since the very beginning of the project. In the spring of 2015, developers from Stembolt and Bonobos disappeared into the forest near Whistler, BC and emerged after a week with a plan and a direction for the new platform.

Every year since there's been another conference: 2016 we invaded Toronto, 2017 was across the pond in London, and last year we found ourselves talking Solidus over the best barbecue that Memphis has to offer.

It's fair to say that this is a big year for the conference and the platform, though. Last year in Memphis it was announced that Stembolt had been acquired by Juul and would no longer be stewarding the platform in their previous capacity. This meant a lot of change was coming and while we did our best to plan for the future, it was really hard to understand what this might mean for the community.

This year's conference took the same format as most previous years: two days of conference talks and two days of hack days. The presenters this year all did a fantastic job.

Day One

Thomas Sample of Karma Creative kicked things off, jamming more than one hundred SEO tips into a single talk. It was an awesome way to start the conference. Thomas does a ton for Solidus and his energy was a great way to start the conference.

Next was one of my favourite talks; Ryan Cromwell of Sparkbox spoke about "Making the Leap to Tech Lead". At Super Good, levelling up our developers is one of our main focuses and Ryan had a lot of great advice around organizing streams of work and making space for team members to grow.

The third talk was focused on how consultants might improve our ability to gauge the quality of the codebases we're jumping into. Ernesto Tagwerker from OmbuLabs presented on his new tool skunk which provides an integrated code smell/test coverage heuristic, so you can identify major code liabilies when stepping into a new project.

After that, Taylor Scott gave us a complete breakdown of the continuous integration and deployment process they use at Deseret Book. Having run Solidus (and Rails) apps on a few of Amazon's different hosting offerings, it was interesting to see how they're leveraging Elastic Beanstalk and GitLab.

For the final talk of the first day, Peter Berkenbosch went over some of the lesser known extension points in Solidus, and some cool uses for them. A lot of work goes into making Solidus more extensible, so it was great for someone to help raise up some of the lesser used extension points.

What's Next For Solidus Extensions

Before Peter's talk, we got a talk that deserves a little more attention. Alessandro Desantis from Nebulab presented on the state, direction, and plan for the Solidus's many extensions.

As I mentioned before, this was the first Solidus Conf since Stembolt stepped back from their role as the primary directors of the Solidus platform. As such, everyone was curious to see what Nebulab has been doing to continue to maintain and grow the platform. Alessandro stepped up to outline everything they were doing to keep our extension ecosystem healthy.

Firstly, they're moving all the non-core extensions into the Solidus Contrib organization. The core team of Solidus is responsible for the extensions and main gems, now all housed under the main organization. The broader community is responsible for the maintenance of everything under the contrib organization.

Before Stembolt was acquired by Juul Labs and merged into their development team, Stembolt had adopted an internal policy that all employees working at the company would be responsible for one or more Solidus extensions. This was to ensure that even lesser-used extensions had someone directly responsible for them who would respond to pull request and issues and keep them up to date.

Nebulab has implemented the same policy. While they welcome support from the community in supports the extensions in Contrib, each extension has a Nebulab developer responsible for it's maintenance. While this policy was only somewhat successful at Stembolt, Nebulab has set themselves up for success with it. Nebulab dedicates Fridays to non-client work: writing blog posts, working on internal tools, and open source work. Time of this kind of open-source work is baked into their process and it's great to see that kind of commitment.

On top of committing to keeping the ecosystem maintained, they've done some great work to make that easier for everyone. They've updated solidus_cmd to make various maintenance tasks easier and adopted a consistent README format for Solidus extensions to make it easier for those new to Solidus to understand what the extension ecosystem has for them.

They're using dependabot and Pull Reminders to stay on top of updates, as well as GitHub Changelog Generator to make sure that it's as easy as possible to upgrade all the extensions your store is using.

Finally, they're committed to addressing the issues we've talked about for a long time in the Solidus (and Spree) communities: class_eval is bad and Module#prepend isn't much better. The success of the extension ecosystem is contingent on becoming less dependent on these methods of modifying Solidus's core and providing the configuration options and extension points that real stores need. It's great to see them continuing that effort.

I was really glad to see that some serious thought is going into how we're handling extensions and that Nebulab is doing their part to keep the ecosystem up to date. That said, they're only one member of this community and they need the assistance of the rest of us to make Solidus as awesome as it can be.

Day Two

Day two featured talks from Joel Saupe on the Solidus API, Jen Luker on how we can make sure not just our products, but our companies are accessible to everyone, Braden Douglass on breaking up monoliths with microservices, and Jason Swett on how to confidently modify legacy code, something everyone work on Solidus has to do on a day-to-day basis.

We also had a lightning talk section that provided some really great insight into what the community is working on. Eric Saupe from the core team described the architecture of the point-of-sale system he's working on. Matthew Bass showed off an awesome shipping rate estimator that sidesteps the unreliable APIs they'd normally use, but still makes sure you're charging your customers the right amount.

The Roadmap

For the final lightning talk Gregor Macdougall of Juul Labs and Alberto of Nebulab (both on the Solidus core team) outlined all the work that's gone into putting together a roadmap for the project.

They went over the community survey results, reviewed independent market research, examined alternative eCommerce platforms, and used common sense to outline a laundry list of what Solidus needs to continue to grow.

There are tons of stores on Solidus today, but the more stores we can bring to the platform, the more open source contributions we can leverage to make this a better platform for everyone.

The roadmap is public and can be found here. It's a work in progress, so there'll be more prioritization and consultation to come, but it represents the next steps for the Solidus platform.

Community Driven Solidus

The final talk of the conference (and what a talk to end on) was from Sean Denny. Sean is a member of the stakeholders team and did a ton of work to make this year's conference (and last years) happen.

Sean started by outlining the history of the project and how the organization functions now, before diving into his thoughts on the next steps for Solidus. He's done a ton for this community, so when he talks about the need for greater diversity and calls on everyone to "take responsibility" for moving Solidus forward, it carries a lot of weight.

I encourage everyone in the community to go give his talk a listen once it gets posted.

The Hack Days

Hack days are a staple of Solidus Conf. They help capture the energy and enthusiasm that builds around the conference and turn that into real contributions. Having everyone in the same room helps facilitate broader discussions and provides opportunities for newcomers to the platform to get involved.

This year we saw everything from optimizations that leverage new Rails 6 features to some of our oldest issues closed. I spent my time getting the discard project cleaned up to enable us to complete the migration away from paranoia.

Open Stakeholders Meeting

The Solidus stakeholders team meets weekly to manage the project, so this week we held our meeting at the hack days and made it open to anyone who was present. Everyone at the hack day was able to voice their opinion and get a look at how things are run.

This facilitated discussions around the material in the roadmap, what might be missing, and how to best prioritize that. There'll be more to come on that as the stakeholders team continues to refine the roadmap process.

What's Next

Solidus is a community made up of store owners, consultancies, individual developers, and more. Part of our strength is that so many businesses are build on the platform and are invested in its success.

The biggest next step for the stakeholders team, the core team, and other members of the community is to finish to fleshing out the roadmap.

We're also focused on increasing the funding of the Solidus Open Collective in order to hire a full time maintainer. Many of the tasks to support that are on the roadmap, but if you run a business on Solidus, consider a recurring contribution. If you look back on the everything that John Hawthorn did for the platform, it's clear that a small investment can pay massive dividends here.

The community at large is focused on improving the extension ecosystem. Extensions enable new stores to jump onto the platform with minimal friction, so continuing to build on our robust suite of extensions is critical to the continued growth of the platform.

Finally, expect to see more regional meetups and events around Solidus. The team and community are both aligned that these events do wonders for bringing us together and helping grow the platform.

Conclusion

Solidus started when a bunch of developers wandered off into the mountains in British Columbia to try to improve the state of eCommerce on Ruby on Rails. While the locale has changed, we're still here, we're still making eCommerce better, and you better bet we're still hiking off into the woods.