Ruby Conf 12 - Boundaries by Gary Bernhardt

What Hacker News said

Strong rec pmarreck · 2016-04 · on “Have Software Developers Given Up?”

Here is the infamous Nagappan TDD paper from Microsoft Research [LINK] Also discussed in this infoq article [LINK] Here's someone's thesis paper on it, with data: [LINK] There's also interesting discussions like this [LINK] "it is my experience that the value proposition for TDD grows exponentially as the time and resources involved in a project grows linearly." This has also been my own experience. This person's comment also is interesting and has data [LINK] Some of the above is empirical (read: scientific, no-bullshit) data. My opinion on it has grown to the point that I think TDD should literally be inseparable from programming, and the two together should simply be called, "programming.

Strong rec dnautics · 2020-01 · on “Elixir v1.10”

if you are a rubyist, I can't more strongly recommend watching this video, which has nothing to do directly with Elixir (in fact it precedes elixir by a couple of years) but if the topics that Bernhart (of wat fame) brings up resonate with you, then you will really like Elixir. [this video]

Strong rec dnautics · 2020-03 · on “I Don't Use Classes”

> I find some problems are solved better in an OO way such as interacting with a relational database. I've switched to functional interactions with a database, (Elixir/Ecto) and really, it's much better. In particular the explicit and declarative nature of the database interactions combines the convenience of an ORM with "not hiding important gotchas from you". I'm not arguing for pure functional systems (which I can see going very poorly with relational databases). There are some things that objects are good at like caching state as a model. But even here the FP systems typically do it better via FP actors and (again, impure) message passing, which enforces no-shared memory, and at least in

Strong rec AaronFriel · 2020-10 · on “A Theory of Software Architecture”

A few years ago I was on a team and the dev lead had a practice of sharing Gary Bernhardt's Boundaries talk every time there was some degree of rotation or churn on the team. Almost part of the onboarding. As a functional programming aficionado, I didn't need the sales pitch, but it was the presentation that was gripping. Keep in mind, Ruby isn't a functional language, but here was this presenter describing essentially how you write good Haskell code, but in Ruby! A language that makes it so easy to mutate in place that it's known for libraries that "monkey patch" base classes and can change the definition of operators and functions at runtime! Fantastic talk, fantastic presentation. I now s

Recommends zachrose · 2015-03 · on “Ask HN: Front-end “design patterns”?”

Forgive me for being vague and brief, but I've been trying to test my UIs for the last year or so and this is what I've come up with. I've found the ideas in Gary Bernhardt's talk, Boundaries (1), to be very helpful in figuring out how to test interactive web UIs. The basic idea is that DOM manipulation can be an "imperative shell" with as little logic and as few conditionals as possible. Derive the state of your UI component with separate functions and methods that return plain values (a "functional core"), and write tests for those because testing for values is easy. So no, don't test for the presence of classes and IDs. Test your imperative shell once, maybe even manually or with an integ

Recommends lectrick · 2015-10 · on “The microservices cargo cult”

Many of the advantages of microservices can be achieved by refactoring your monolith code to be less monolithic. I would suggest using functional styles wherever possible, plenty of isolated unit testable code, and a hexagonal architecture [LINK] that pushes all the I/O, mutation, side effects, etc. to the very boundary of your code. Also see Gary Bernhardt's "Boundaries" talk for more interesting thought in that vein [this video]

Recommends itsmemattchung · 2016-03 · on “How to avoid brittle code”

I recommend watching this talk: [this video] Both, unit and integration tests, are imperative. Integration tests point in the general direction of where an issue might be but unit tests are more precise.

Recommends magicpat2010 · 2020-05 · on “Ask HN: Organization of Layered Software?”

This isn't an article but reading your post reminds me of the presentation by Gary Bernhardt titled "Boundaries", [this video] I would be interested in looking at the article(s) if you can find them again.