6 ms·

Poof and then Rails was gone

66 points by ryansouza 12y ago

Dorian-Marie 12y ago
Poof and your site hosting is gone
- deleted 12y ago
  [deleted]
- kintamanimatt 12y ago
  I'm not sure why you're being downvoted. I saw the HostGator error page too.
- daviding 12y ago
  The delivery of the page has been abstracted via protocols, and is keeping the application logic independent of persistence and UI implementation details. The 50X is just a side-effect. :)
jrochkind1 12y ago
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. 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. (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?)
- edwinnathaniel 12y ago
  ... and of course for those who applies modern Java development patterns, we no longer see plenty FactoryGeneratorFactory. I find it a bit odd that the community who has railed Java hard suddenly came up with something more complex than... gasp... the solution in Java-land.
  - jrochkind1 12y ago
    I didn't mean to imply that everything in Java was over-engineered, just that certain historical common Java practices were examples of what happens when you over-abstract and over-engineer. Certainly over-abstracting and over-engineering happens in every language too though, it's a hazard of the trade. What community is it that you think has "suddenly" come up with what solution that's more complex than what "the" solution in Javaland? I'm not even sure what you're talking about. There are of course many solutions in Javaland, naturally, and in every other code land. I think engineering code, especially code shared between multiple developers/installations, is a constant tension between simplicity and abstraction/flexibility. It's sometimes possible to optimize both, but it requires a lot of skill and a lot of domain experience, and domain experience especially seems to be under-valued and under-present in the current environment. (Plus if the domain changes fast enough, nobody ever has enough domain experience!) I think individual developers, as well as teams and communities (language-based or industry/domain-based) often swing from end to the other. This legacy thing is too complicated, let's start over with new principles to keep it simple! This simple thing isn't as flexible as I want, let's add in some abstraction to make it possible to do what everyone needs; then do it again; then do it again; then start over at 0.
- secstate 12y ago
  Pssh, XML is so Java. They'll just use YAML or JSON ;-)
carsongross 12y ago
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 system architecture.) 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.
- sanderjd 12y ago
  I've always read into those Evolution of a Programmer jokes that what the master learned through their evolution is the right and wrong time for all the complicated stuff they did in the earlier phases, and that anything simple enough to form the basis of a joke is merely the wrong time.
jowiar 12y ago
When I read code like this and find that half of the tests are, more or less, a typechecker, it reduces to an argument for static typing.
- deleted 12y ago
  [deleted]
  - jowiar 12y ago
    - "returns a saveable object" - "accepts an employee with a notice: option" - "accepts :new" - "returns a hash with :name" Are all within the scope of a typechecker.
- voxtex 12y ago
  Completely agree with you. Many of the tests don't do any kind of assertion, simply ensure that an exception isn't thrown on the invocation of a method. An interface defined in a static language would render the majority of these tests unnecessary.
- joncooper 12y ago
  Indeed. Once you realize this it doesn't take very long to get excited about statically typed languages, especially with type inference.
ubernostrum 12y ago
So... poof, and then Rails was J2EE? 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. 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.
- adamors 12y ago
  I don't understand how anything on HN that discusses a more complex software architecture is immediately called J2EE/enterprisy and dismissed. Is this because the majority of the community is self thought? Or is this because most of you only build MVPs which are mostly CRUD apps (and therefore don't know from first hand experience the benefits of a modular system)? The constant negative reaction to anything a little more complex is frankly laughable.
  - wfjackson 12y ago
    If simple MVP CRUD apps are one end of the spectrum, then there is the other end which looks a bit like this: https://plus.google.com/+aerotwist/posts/1QhcnQizuPc https://plus.google.com/+aerotwist/posts/1QhcnQizuPc description: "Convenient proxy factory bean superclass for proxy factory beans that create only singletons." http://docs.spring.io/spring/docs/2.5.x/api/org/springframework/aop/framework/AbstractSingletonProxyFactoryBean.html http://docs.spring.io/spring/docs/2.5.x/api/org/springframew...
    - adamors 12y ago
      Of course you can overarchitect software. But there's also more discussion to be had on this subject other than "OMG looks like Java, OP sucks".
  - ChrisGaudreau 12y ago
    It does get a little tiring when somebody tells you "you're doing it wrong. It has to be more abstract and complex because you might become the next Facebook." And then everything turns into a StrategySingletonProxyFactoryBeanFactory.
scottschulthess 12y ago
I actually think that the authors rspec code is too abstract (at least for me). Unfortunately I think he's proving DHH's point.
stiff 12y ago
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. 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. 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".
- angersock 12y ago
  All of your examples don't exactly make the point you're trying to make: Ask anyone who's had to debug game engine code, compilers, operating systems, or the worst of the lot, scientific code. Most of those systems would actually benefit from proper design and architecture, but people like you decrying their "wankery" have relegated such introspection to the dustbin. And that attitude is why software engineering is mostly a dark joke.
  - ChrisGaudreau 12y ago
    That might be fine if the majority of software developers worked on game engines, compilers, or operating systems. But we're talking about Rails applications here.
    - angersock 12y ago
      Yes, Web applications are somehow magically exempt from sound engineering practices. If you want to make the argument that shitty Rails hairballs that don't scale aren't a problem, because they fulfill a business need and fill it quickly, I'll agree. That said, that's a business decision, not a technical one.
jdminhbg 12y ago
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.
ChrisGaudreau 12y ago
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"?
deleted 12y ago
[deleted]
lobster_johnson 12y ago
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".
htp 12y ago
Cached version, as the site is currently down for me: 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 http://webcache.googleusercontent.com/search?q=cache:0-I-y0x...
briantakita 12y ago
Frameworks are like cookbooks. They teach you how to make meals. It's way more fun and tastier to make your own meals.
abk 12y ago
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.
jhuckestein 12y ago
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. 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.
JoelMcCracken 12y ago
This is one of the cooler blog posts I've seen in a while. Very nice.
wnevets 12y ago
and PHP keeps on ticking
mercer 12y ago
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. 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'... Instead, I seem most effective when I write down my top three tasks of the day on a piece of paper. 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!" Which is exactly what I hear (and suggest) whenever I or someone else falls off the GTD wagon. 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 :-).

66 points by ryansouza 12y ago

Dorian-Marie 12y ago

Poof and your site hosting is gone

deleted 12y ago
[deleted]
kintamanimatt 12y ago
I'm not sure why you're being downvoted. I saw the HostGator error page too.
daviding 12y ago
The delivery of the page has been abstracted via protocols, and is keeping the application logic independent of persistence and UI implementation details. The 50X is just a side-effect. :)

jrochkind1 12y ago

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. 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. (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?)

edwinnathaniel 12y ago
... and of course for those who applies modern Java development patterns, we no longer see plenty FactoryGeneratorFactory. I find it a bit odd that the community who has railed Java hard suddenly came up with something more complex than... gasp... the solution in Java-land.
- jrochkind1 12y ago
  I didn't mean to imply that everything in Java was over-engineered, just that certain historical common Java practices were examples of what happens when you over-abstract and over-engineer. Certainly over-abstracting and over-engineering happens in every language too though, it's a hazard of the trade. What community is it that you think has "suddenly" come up with what solution that's more complex than what "the" solution in Javaland? I'm not even sure what you're talking about. There are of course many solutions in Javaland, naturally, and in every other code land. I think engineering code, especially code shared between multiple developers/installations, is a constant tension between simplicity and abstraction/flexibility. It's sometimes possible to optimize both, but it requires a lot of skill and a lot of domain experience, and domain experience especially seems to be under-valued and under-present in the current environment. (Plus if the domain changes fast enough, nobody ever has enough domain experience!) I think individual developers, as well as teams and communities (language-based or industry/domain-based) often swing from end to the other. This legacy thing is too complicated, let's start over with new principles to keep it simple! This simple thing isn't as flexible as I want, let's add in some abstraction to make it possible to do what everyone needs; then do it again; then do it again; then start over at 0.
secstate 12y ago
Pssh, XML is so Java. They'll just use YAML or JSON ;-)

carsongross 12y ago

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 system architecture.) 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.

sanderjd 12y ago
I've always read into those Evolution of a Programmer jokes that what the master learned through their evolution is the right and wrong time for all the complicated stuff they did in the earlier phases, and that anything simple enough to form the basis of a joke is merely the wrong time.

jowiar 12y ago

When I read code like this and find that half of the tests are, more or less, a typechecker, it reduces to an argument for static typing.

deleted 12y ago
[deleted]
- jowiar 12y ago
  - "returns a saveable object" - "accepts an employee with a notice: option" - "accepts :new" - "returns a hash with :name" Are all within the scope of a typechecker.
voxtex 12y ago
Completely agree with you. Many of the tests don't do any kind of assertion, simply ensure that an exception isn't thrown on the invocation of a method. An interface defined in a static language would render the majority of these tests unnecessary.
joncooper 12y ago
Indeed. Once you realize this it doesn't take very long to get excited about statically typed languages, especially with type inference.

ubernostrum 12y ago

So... poof, and then Rails was J2EE? 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. 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.

adamors 12y ago
I don't understand how anything on HN that discusses a more complex software architecture is immediately called J2EE/enterprisy and dismissed. Is this because the majority of the community is self thought? Or is this because most of you only build MVPs which are mostly CRUD apps (and therefore don't know from first hand experience the benefits of a modular system)? The constant negative reaction to anything a little more complex is frankly laughable.
- wfjackson 12y ago
  If simple MVP CRUD apps are one end of the spectrum, then there is the other end which looks a bit like this: https://plus.google.com/+aerotwist/posts/1QhcnQizuPc https://plus.google.com/+aerotwist/posts/1QhcnQizuPc description: "Convenient proxy factory bean superclass for proxy factory beans that create only singletons." http://docs.spring.io/spring/docs/2.5.x/api/org/springframework/aop/framework/AbstractSingletonProxyFactoryBean.html http://docs.spring.io/spring/docs/2.5.x/api/org/springframew...
  - adamors 12y ago
    Of course you can overarchitect software. But there's also more discussion to be had on this subject other than "OMG looks like Java, OP sucks".
- ChrisGaudreau 12y ago
  It does get a little tiring when somebody tells you "you're doing it wrong. It has to be more abstract and complex because you might become the next Facebook." And then everything turns into a StrategySingletonProxyFactoryBeanFactory.

scottschulthess 12y ago

I actually think that the authors rspec code is too abstract (at least for me). Unfortunately I think he's proving DHH's point.

stiff 12y ago

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. 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. 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".

angersock 12y ago
All of your examples don't exactly make the point you're trying to make: Ask anyone who's had to debug game engine code, compilers, operating systems, or the worst of the lot, scientific code. Most of those systems would actually benefit from proper design and architecture, but people like you decrying their "wankery" have relegated such introspection to the dustbin. And that attitude is why software engineering is mostly a dark joke.
- ChrisGaudreau 12y ago
  That might be fine if the majority of software developers worked on game engines, compilers, or operating systems. But we're talking about Rails applications here.
  - angersock 12y ago
    Yes, Web applications are somehow magically exempt from sound engineering practices. If you want to make the argument that shitty Rails hairballs that don't scale aren't a problem, because they fulfill a business need and fill it quickly, I'll agree. That said, that's a business decision, not a technical one.

jdminhbg 12y ago

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.

ChrisGaudreau 12y ago

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"?

deleted 12y ago

[deleted]

lobster_johnson 12y ago

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".

htp 12y ago

Cached version, as the site is currently down for me: 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 http://webcache.googleusercontent.com/search?q=cache:0-I-y0x...

briantakita 12y ago

Frameworks are like cookbooks. They teach you how to make meals. It's way more fun and tastier to make your own meals.

abk 12y ago

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.

jhuckestein 12y ago

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. 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.

JoelMcCracken 12y ago

This is one of the cooler blog posts I've seen in a while. Very nice.

wnevets 12y ago

and PHP keeps on ticking

mercer 12y ago

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. 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'... Instead, I seem most effective when I write down my top three tasks of the day on a piece of paper. 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!" Which is exactly what I hear (and suggest) whenever I or someone else falls off the GTD wagon. 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 :-).