Ruby Midwest 2011 - Keynote: Architecture the Lost Years by Robert Martin

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: ▶ this video

in “Hanami – web framework for Ruby” · View on HN

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: [link] ▶ this video [link] [link] 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.

in “Crystal: the programming language” · View on HN

Here's Uncle Bob talking on his version of the idea extensively: ▶ this video 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

in “Slow Tests Are the Symptom, Not the Cause” · View on HN

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] ▶ this video [1] [link]

in “Code Organization in Large AngularJS and JavaScript Applications” · View on HN

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 pr

in “I’m done with the web” · View on HN

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. ▶ this video 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.

in “RIP TDD” · View on HN

"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 ▶ this video Jump to the 58 minute mark if it doesn't automatically.

in “When TDD Doesn't Work” · View on HN

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: ▶ this video 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.

in “How testability can help” · View on HN