The problem with software is that it is too easy to get it working. If you would do completely stupid shit while designing an analog electronic circuit you would get completely stuck in your "inventions" very soon and would not be able to deliver anything working beyond the simplest stuff, the difficulty would just force you to adapt a sensible design approach or resign from doing any electronics in the first place.<p>In software engineering, on the other hand, the kind of wankery presented here lives on for years because there is no reality check - as long as a group of people feels good about themselves inventing fancy words and "techniques" without putting in too much effort into anything of substance, fads of this kind can live on. They can even deliver products written in this manner and get paid, for the projects work, as far as most business projects are concerned, it is simply that the code is just awful to look at.<p>Meanwhile, serious software from "firmware" for space shuttles, through huge game 3d engines, compilers, operating systems, to scientific software manages to get developed without having any need for this sort of thing. Somehow it's always the rather trivial software that gets those super-"architectures".
So... poof, and then Rails was J2EE?<p>I have a deep dislike for overabstracting a system merely because someone has a list of hypothetical use cases. And make no mistake: it is always about supporting the hypotheticals, never about supporting what's actually really needed by the system.<p>Down this road lie dozens of layers of abstracted factories and strategy implementations which exist just in case someone wants to "persist" a relational object over a serial printer line. YAGNI.
Having once been a platonist about this sort of stuff, I've rarely seen heavy code architecture work out well in practice (not so with <i>system</i> architecture.)<p>I'm reminded of the various Evolution Of a Programmer jokes which end with the master programmer writing the same code as the beginner programmer.
Excellent. Proof that you can make your code an unapproachable mess to a new team member by throwing out Rails conventions, and in return you get the much greater benefits of shaving 100 ms off your test run times and the ability to run it from the terminal.
This code is painful to read. As somebody new to a team, how can you "extend" code when you don't have a clue how the rest of the system works because somebody else decided it'd be a good idea to unit test controllers and abstract everything away because "we might need it someday"?
I'm not a huge fan of Rails architecture neccesarily, but I have to admit I have trouble following the 'hexagonal architecture' stuff, even in simple examples like this.<p>It does seem to be a lot of abstraction. Of course, with abstraction comes flexiblity, that's the point, I get it. But with (some kinds? all?) abstraction also comes complexity and cognitive load for the developer. If you're not careful, you end up in Java FactoryGeneratorFactory land.<p>(I hope the next step in the 'hexagonal architecture' isn't using an XML file to specify all the linkages and concrete classes in use. How else do you specify what concrete @db etc your controller is instantiated with?)
Like others here I'm not sure if this is a joke post or not, but... the TerminalAdapter example is not an abstraction. It's simply reimplementing a very specific protocol that implements "render" and "redirect_to". This protocol is not something that could automatically be adapted to other scenarios than HTTP — say, to a mobile app or to a desktop GUI app. The terminal, for one, might "render", but it cannot "redirect".
I might just not be very good at this programming thing, but to me these kinds of articles on testing often (not always) remind me of my annoying tendency to implement a comprehensive productivity approach (often combined with buying yet another task app) that, on paper, really should help me keep track of my life. Usually it's a variation on Getting Things Done, which stands out in its exhaustive, all-encompassing, fine-grained approach.<p>In practice the whole falls apart after a week or so because I forget to do things the right way or because I don't feel like processing my 'inbox'...<p>Instead, I seem most effective when I write down my top three tasks of the day on a piece of paper.<p>Maybe I get that feeling because I've mostly experienced companies where testing didn't really seem to have much of an effect. Whenever I asked about this lack of efficacy, the answer was usually "that's because we're not implementing it completely!"<p>Which is exactly what I hear (and suggest) whenever I or someone else falls off the GTD wagon.<p>Am I completely wrong about that feeling? I mean that as an honest question, as I truly don't want to be negative and I'm way to inexperienced to be cynical about these things :-).
Cached version, as the site is currently down for me:<p><a href="http://webcache.googleusercontent.com/search?q=cache:0-I-y0xrctsJ:patmaddox.com/2014/05/15/poof-and-then-rails-was-gone/+&cd=1&hl=en&ct=clnk&gl=us" rel="nofollow">http://webcache.googleusercontent.com/search?q=cache:0-I-y0x...</a>
I love thinking up intricate software design patterns as much as the next guy. They'll cater not only to the current requirements for my project, but also to all possible future eventualities. It'll allow me to, by simply changing one or two lines of code, change my entire database backend, implement system-wide magic caching and to expose my HTTP service as a custom telnet protocol.<p>The issue I have with posts like this is that they are decidedly NOT just about thinking up wild new designs. Instead, they claim that these designs are somehow BETTER. Unless you can give me a real world use case, I won't believe you.
I kind of skimmed the post, so maybe I'm missing something, but what exactly is the "architecture" described here? Dynamically-typed languages will allow the passing around of objects of different types as long as they implement the necessary methods. This is a nice property in some cases, but a lot of times I'd prefer to have static-typing and well defined protocols. It seems like that post ignored the more important parts of the discussion.