alan.codegardener.com
Passionate Rubyist. Empathetic leader. Fallible human. Storyteller. Speaker. Environmentalist. Feminist. Ally. Swell photographer. Rusty drummer. Loving husband & twins dad.
Owner of too many hats, given I only have the one head.
the.codegardener.com
93 posts
925 followers
358 following
Regular Contributor
Active Commenter
comment in response to
post
We need to be educating engineers NOW on how to write automated specifications well. That will be THE most critical skill moving forward -- writing self-verifying prompts using automated specifications.
comment in response to
post
Developer tools will be able to accept a test, generate some code, run the test, and regenerate the code in a loop until the test passes.
comment in response to
post
Generative AI Tomorrow
Automated specifications are the future of software development. Get used to TDD. That will become the largest part of an engineer’s job in the near future.
comment in response to
post
I believe we are witnessing the transition of the role of programmer from human to machine. What we are not (yet) witnessing is the transition of the role of software designer/architect. We will still need to own the big picture for a while longer at least.
comment in response to
post
Generative AI Today
I’ve had some amazing conversational experiences with LLMs. Stunning, really. I’ve also found success prompting ChatGPT, Claude, and Deepseek with automated specifications for a single class. All 3 wrote code that passed the tests just by prompting them with the specifications.
comment in response to
post
California knows no bounds!
comment in response to
post
How can spring be here? It's 3ºC in January! Why are those blossoms blooming?!?!
comment in response to
post
Depends on the coffee shop and the line.
I had a snotty barista at Pete’s berate me for using the word venti. “What is that? We have small, medium, and large!” I’ll be ordering from the app every time I go in that particular store from now on.
comment in response to
post
I like how the titles of your top 5 songs tell a tragic love story.
comment in response to
post
That's the beauty of small talks like this. You can always sneak them in somewhere!
comment in response to
post
Hi Gregory! Thanks for reading!
For the purpose of this post, I'm using the de facto "de-duplication" definition that so many code bases fall prey to.
@avdi.codes has already pointed out that The Prag Prog has the canonical definition of "good" DRY. That's not what we're talking about.
comment in response to
post
Of course, that should have said "bug report" which is hilarious.
comment in response to
post
First (really nit picky) but report... Guide should be capitalized.
comment in response to
post
Just noting that this gem would require maintenance over time. And the changes would be expected pronto.
comment in response to
post
There is a gem for time zones. They change. They’re not static. Same with countries. In fact, country names are different depending on who you ask. Taiwan is one. Western Sahara is another.
comment in response to
post
My preferred way to build applications is to TDD one class per use case. A to-do list, for example, has a `CreateTask` class. `CompleteTask`, `RankTask` and others make perfect sense as independent classes in that context. Then I add persistence and an interface. In Ruby that often means Rails.
comment in response to
post
Show them this talk (sorry for the self promotion): youtu.be/4b4Ew_BUdrY?...
comment in response to
post
I think we're on to something here. So much of the code I see has been de-duplicated in a way that makes it harder to understand and harder to modify/test/extend. And, I do think it has to do with the acronym. I wonder what proposals we could make for a more expressive acronym?
comment in response to
post
And, a few more:
* Domain Driven Design
* Working Effectively with Legacy Code
* Growing OO Software
comment in response to
post
Agreed. Here are my top 5:
* POODR
* XP Explained
* Refactoring
* Design Patterns
* Pragmatic Programmer
And, no, I didn't get Design Patterns until I read other books on the subject. Back to that thing about some authors speaking to you and others not.
comment in response to
post
And, how many engineers born after 2000 have ever read the Pragmatic Programmer?
comment in response to
post
Several points to make:
1. Good design principles bear repeating.
2. Sometimes one author speaks to you where another doesn't.
3. I learned DRY in 1987 — long before Hunt & Thomas documented it in 2000.
4. I learned it before I learned OOP — it was not a nuanced discussion about abstraction.
comment in response to
post
It’s cedar (brown) and sail (off white). Left.
comment in response to
post
That's a fail, for sure. The must have been targeting 27" desktop monitors. 🤷♂️
comment in response to
post
Here's the CFP: www.papercall.io/tropicalonra....
We had a fantastic time at Tropical.rb last year. With the infusion of Rails Foundation support, it seems like the conference will be a bit more like Rails World this year.
São Paulo is astonishingly big. Hardly saw any of it. Want to go again!
comment in response to
post
Tropical has a list of topics they want speakers to discuss in their CFP. It's basically marketing for Rails 8. But, the do say this: "We encourage you to submit proposals that challenge the status quo, showcase forward-thinking ideas, and push the boundaries of what's possible with Rails."
comment in response to
post
What size is your screen?
comment in response to
post
@fito.codegardener.com and I are considering writing a talk about why putting all your business logic in your models is a bad idea -- specifically for Tropical.rb -- but in the context of, "Hey, Merb had some good ideas (restful routes, bundler!). Why can't we challenge the status quo elsewhere?"
comment in response to
post
WHAT? Blasphemy! 🤣
Also, you must not be using Ruby...
comment in response to
post
If so, I was right. 😇
comment in response to
post
Was the cache sharing state across multiple tests?
comment in response to
post
Shared state between 2 tests?
comment in response to
post
Done!
comment in response to
post
Awesome!
comment in response to
post
💯
Here's a hot take...
Concerns are a means of hiding complexity rather than dealing with it. And, in fact, they make things worse, because now you've got to track down where that mystery guest variable comes from.
Prefer POROs over concerns. POROs contain stuff. Concerns leak like colanders.