HN Theater @HNTheaterMonth

> Many people will argue that not using a framework means write everything yourself. This is a false dichotomy. We can use libraries and frameworks just fine. ...

> But we should give them a clear, and well-isolated place in our project. ...

There's an excellent, if older, presentation called "Architecture, the Lost Years" that addresses exactly this problem and gives very specific, actionable guidance on how to solve it:

https://www.youtube.com/watch?v=WpkDN78P884

But how to pull off this decoupling? The answer is both obvious and surprising. Define a boundary. On one side is the framework. On the other side is your code. Through the boundary, only dumb data structure can pass. JSON works. So do structs. So does XML. The point is that these are behaviorless blobs of data.

This buys you a lot. You can run your application completely detached from the network, a database, and other expensive dependencies. So testing becomes much simpler and easier. And of course, you can replace the framework by writing new boundary code.

The other big lesson has something to do with why frameworks get added to a project in the first place. When designing a system, the goal should be to defer major decisions for a long as possible. That's when the best information is available. Sometimes you can just defer until the point becomes moot, which is a major win.

Reaching for a framework before being forced to do so sets up the kind of situation the author is talking about.

⬐ hamandcheese

“When designing a system, the goal should be to defer major decisions for a long as possible.”

I noticed that I tend to do this, but never knew it was a legit strategy.

⬐ googlryas

Isn't the problem here that your decouple framework requires data X,Y, and Z in the message across the boundary, so you plumb that data through right near boundary where the request is made. But later on, you want to switch out a different framework, but that framework requires U, V, W, X, f(y), and Z. So even on your apps side of the boundary layer, you still formatted your code and data flow to support the single framework you started with.

⬐ fuzzy2

If your message contains framework-dependent data, it wasn’t decoupled.

For example, in a typical web API, all the stuff concerning HTTP endpoints, JSON, OpenID Connect or whatever should be entirely separate from your domain logic. I’ve been doing this for years and it is very feasible.

Do you still have to write code where the framework dictates its structure? Absolutely. That’s the decoupling layer. Do you have to change this layer if you upgrade or switch frameworks? Also yes. However, you don’t have to touch the application core.

⬐ berkes

I too have been doing the same. It's surprisingly simple and elegant. I prefer 'ports and adapters, aka hexagonal architecture', but there are many alternatives.

This is what prompted me to write this article: the simplicity, elegance and maintainability of those codebases that had domain logic separated from delivery and storage mechanisms.

> Although the design above is perfectly valid in terms of OOP, neither of these classes are actually unit-testable. Because LocationProvider depends on its own instance of HttpClient and SolarCalculator in turn depends on LocationProvider, it’s impossible to isolate the business logic that may be contained within methods of these classes.

The design of those classes is bad, and the perceived need to reach for mocks (or interfaces) is telling you that.

The next step the author takes is to go for interfaces. That's not what I'd do. Instead, I'd decouple network from calculation with intermediate dumb data structures. The network side produces the data structure and the calculation side consumes it. The network side can further be broken down with a transformation of the API call result into the dumb data structure used for calculations.

This idea comes from an old Bob Martin presentation [1]. The whole thing is worth watching to put it into context.

This is the kind of thing that never seems to get discussed in these pieces praising integration tests over unit tests. For even better results, ditch the classes altogether and just use functions. It's quite surprising how badly designs come off the rails with the "everything is a class" model.

[1] https://www.youtube.com/watch?v=WpkDN78P884

⬐ jesterman81

This!

⬐ hinkley

Which in turn comes from Bertrand Meyer, who probably stole it from somebody else in 1990. Code should act or decide, but not both.

Ah I forgot the link https://youtu.be/WpkDN78P884

The talk that had the most influence on how I write software is Robert 'Uncle Bob' Martin's "Architecture: The Lost Years" [1]. Being a Ruby conference keynote, it helps if you know how Ruby on Rails works, but the lessons apply to all software.

Another one would be "Let It Crash! The Erlang Approach to Building Reliable Services" by Brian Troutwine. [2]

I don't know if you would call it "technical" but Brett Slatkin's talk on Cohort Analysis is something anyone interested in tools to analyze how our users behave should watch. [3]

[1] https://www.youtube.com/watch?v=WpkDN78P884

[2] https://www.infoq.com/presentations/erlang-reliable-services

[3] https://www.onebigfluke.com/2013/05/video-cohort-analysis-ta...

Uncle Bob's stuff missing on purpose?

https://www.youtube.com/watch?v=WpkDN78P884 was kinda a classic for the Rails community.

⬐ yaj54

Not on purpose at all, I've learned a lot from Uncle Bob. 50k talks is certainly not all of the talks ever, and there are many good talks not included in the 6 lists I've generated (which is a total of only about 230 talks). I'd like to add more filters to be able to hone in on top talks for different contexts.

⬐ suyash

What is "50k"? What's your criteria on selecting talks?

⬐ yaj54

50k is 50,000. Which is a lot of talks, but certainly not all of them. My abstract criteria for a talk being considered a "tech talk" is a live lecture given from the front of a room to a live multi-person audience with a subject matter related to computing. The 50k is just the number my hacky talk finder script found.

⬐ suyash

so your pool is limited 50k talks ?

This "Architecture: the lost years" keynote from uncle bob was helpful for me: https://www.youtube.com/watch?v=WpkDN78P884

I've also struggled with this notion of "untestable" code. Untestable code seems to usually be a big pile of function calls. Testable code seems to be little islands of functionality which are connected by interfaces where only data is exchanged.

Practically, this seems to be about shying away from interfaces which look like 'doThis()', 'doThat()', and more like 'apply(data)'. Less imperative micro-management and more functional-core/imperative-shell.

Edit: a network analogy might be: think about the differences between a remote procedure call API vs. simply exchanging declarative data (REST).

Microsoft Application Architecture Guide https://msdn.microsoft.com/en-us/library/ff650706.aspx

Domain Driven Design (The book is hard to read, but worth it I think) http://martinfowler.com/tags/domain%20driven%20design.html

This uncle bob talk is not too bad https://www.youtube.com/watch?v=WpkDN78P884

I think the microsoft guide is the most comprehensive, but don't limit yourself to it.

My (limited)experience is that when a rails app gets too big, it becomes hard to manage. That was my case, anyway. The architecture of hanami promotes longterm developer sanity. The fact that views are objects and the existence of interactors is a real plus. See this old Uncle Bob video re interactors: https://www.youtube.com/watch?v=WpkDN78P884

It might do that wildly inefficient thing...

Or, you might do something where you have a list of pointers, and you point at a different value instead of mutating an existing value.

I haven't dug into the details of how immutable data structures can be made to work efficiently, but part of the charm is that in many cases you don't mutate the array at all. What I mean is, there are certain behaviors around mutation that programmers do because they can.

When you take away the ability to mutate data, you design differently and without side effects. All of a sudden testing becomes easier, faster, cheaper for large parts of your codebase. You have simpler solutions that are potentially easier to reason about because the complex (and sometimes elegant) solutions aren't so readily available.

A few talks that are around this style of thinking:

https://www.destroyallsoftware.com/talks/boundaries

https://www.youtube.com/watch?v=WpkDN78P884

https://www.youtube.com/watch?v=tq5SQ4W3gRI

http://www.infoq.com/presentations/Simple-Made-Easy

Boundaries are good, values are good, simple things that work together are good. The more we can take the good parts and form them together into a cohesive language/framework/platform, the better our software will be.

I think his first sentence is a strawman. What I'm tired of from the TDD crowd is that they insist that people are doing it wrong if they don't do to the extreme demand of others.

A great example of this is Bob Martin saying that you are absolutely doing it wrong if you don't write your tests before your code and if you don't restrict your writing of app code to the pure case of making a failing test which you wrote first pass. This is an extremist ideology, and many of us are tired of having this thrown in our face over and over again.

Here is Bob saying this: https://www.youtube.com/watch?v=WpkDN78P884&feature=youtu.be...

No one said, "testability is a meaningless goal", and it's dishonest to say that. We're saying that the extreme to which the TDD crowd takes this good general guideline is bad, and their insistence that anyone who doesn't do it that way is doing it wrong is growing very tired and someone has to speak up against it.

⬐ jbrains

I agree. I think you've overstated how many people take that position, but I agree. By the same token, I find it unfortunate when a person turns "TDD doesn't work for me" into "TDD is a bad idea", which DHH has certainly and explicitly said in his articles on the topic. His title "TDD is dead" simply makes one group of people cheer mindlessly and another group roll their eyes. It doesn't help the conversation.

That said, I understand meeting extremism with extremism. I don't think it works, but I understand it.

⬐ jshen

Here's another example that showed up on /r/ruby

http://benlakey.com/2014/05/04/testing-is-science/

I don't think I'm overstating it.

"Over the years many people have complained about the so-called "religiosity" of some of the proponents of Test Driven Development. "

And Bob is guilty of that religiosity himself. See here https://www.youtube.com/watch?v=WpkDN78P884&feature=youtu.be...

Jump to the 58 minute mark if it doesn't automatically.

Is bob Martin a cargo cult practitioner?

jump to the 58 minute mark. http://m.youtube.com/watch?v=WpkDN78P884

Neither of us ever said all TDD folks are cultist. We are both tired of being told that we are absolutely doing it wrong if we don't practice TDD. For an example of people telling us this please see this talk by bob Martin and jump to the 58 minute mark. http://m.youtube.com/watch?v=WpkDN78P884

Bob is not an obscure figure by any stretch of the imagination. You have admitted to having no real data to back up the claim that writing tests first leads to better code, yet we have bob here telling us we are absolutely wrong if we don't follow his religion.

Excellent riposte! Mine was going to be somewhat less polite :-)

Can't stress enough that TDD is not about testing (sth. DHH, like many if not most critics gets wrong). It is about development and design. The fact that you get a pretty decent test suite out of it is a nice side effect. (Love me those side-effects, wouldn't want to program without 'em).

I also find that whenever I skimp, it always comes back to bite me. And usually it was because I hadn't understood the problem-space well enough to write a proper test. That's one important part of TDD for me: I have to understand the requirements well enough to actually write a test for them.

And the OP is also right in that Rails is a bad environment for TDD, as far as I can tell, because all the magic and auto-integration gets in the way and has to be laboriously stubbed/mocked etc.

Maybe it's time the community got over Rails. (See also Uncle Bob's excellent architecture talk: http://www.youtube.com/watch?v=WpkDN78P884 ).

Here's Uncle Bob talking on his version of the idea extensively: https://www.youtube.com/watch?v=WpkDN78P884 The main idea is to separate the system into entities, interactors and boundaries, which correspond roughly to model, controllers and interfaces+DTOs (Data Transfer Objects), but with the difference that model classes are not exposed through the interfaces. Rather, the DTOs are used to communicate the changes in the data.

We have been using this approach for a year now, with REST on top, and it so far has worked beautifully. The entities map naturally to REST resources and DTOs makes nice request and response classes.

Armed with CQRS (now I sound enterprise-y), the data storage is easy to work with using the same DTOs (the data storage and its interface do not know anything about the entities either). On the DB implementation level, we work on the DTOs, which are trivial to store to the database (even without ORM, although it does remove much of the boilerplate). Only one class - the entity repository - is needed to convert the DTOs to entities, and this only happens on create, update, and delete. Reads (due to CQRS) go directly to DB without instantiating any entities - neat. We also use 'unit of work' -pattern to abstract the notion of transaction on create, update, and delete operations, which simplifies the interactor code, hiding the nature of the data storage (making it a swappable in this respect too).

But to stay on topic, our tests are fast too as the interactors can be tested by injecting an in-memory database as a data storage to test the business logic, and the interactors have no dependencies on any frameworks, web or otherwise. Testing the interfaces makes BDD feel natural and also supports clear separation of the REST layer (the communication channel) and the interactors (business logic).

This reminds me of the beginning of Bob Martin's keynote[0] at Ruby Midwest 2011[1]. I don't agree with everything he said, but the code organization point is sound.

[0] http://www.youtube.com/watch?v=WpkDN78P884&t=6m39s

[1] http://www.confreaks.com/events/rubymidwest2011

Many of the author's complaints read similar to this one:

Now, people compare Backbone to Cappuccino, or Ember to Rails. Cappuccino, Backbone, and Rails all serve completely different purposes, and saying you don’t need one because you have another is just asinine.

Three questions:

1. Who are these people that compare those three frameworks?

2. Why do you let them get under your skin?

3. What does that have you do with you "being done with the web" (or web community)?

I don't understand any of these. So some morons want to compare apples and oranges? This has nothing to do with "the web" and crops up in all industries and spheres of life. Welcome to humanity, enjoy your stay.

As best I can tell, my lack of empathy must come from a different definition of "web community". When the author complains about how The community has tossed out everything we’ve learned from the last 30 years of building applications in favor of being able to put something together quickly with complete disregard for maintainability or extendability. part of me wants to agree with him, flip a table, and join the melee [1].

But at the same time, I was listening to the Ruby Rogues episode with Sandi Metz last night [2]. There is a 20-minute discussion about utility of does-it-all frameworks, their use in a project, the types of projects you use them for, and the point at which all projects will necessarily need to have designed a better solution, or massively adapted the framework, to better fit their problem. It's all very clear-eyed and up front about this exact tradeoff (that is, complaint by the author). That is but one example, and I won't belabor the thread with more.

At the end of the day, either the author is simply frustrated that it was hard to convince people to use his project/product, or we must live in very different "web communities".

[1] http://www.youtube.com/watch?feature=player_embedded&v=W...

[2] http://rubyrogues.com/087-rr-book-clubpractical-object-orien...