Comments on: Your Code is My Hell

By: Erik Reppen

Erik Reppen — Fri, 03 May 2013 19:42:00 +0000

I think the history of Java (lol @ java/C# devs having any more OOP discipline than people from other backgrounds btw – haven’t seen much C++) is proof positive that you cannot enforce good practices through language or tool design. Anybody who thinks public vanilla getters and setters are somehow preserving encapsulation better than public properties should have their IDEs slapped out of their hands until they’ve learned to value maintainability and how to actually think about what they’re doing from the act of writing code without one. The problem is that there will always be people who don’t want to learn more than they have to and there will always be people delighted to pay them less now so somebody else can pay ten-fold later.

By: Erik Reppen

Erik Reppen — Fri, 03 May 2013 19:17:00 +0000

Rails promises rapid results. Rapid results are attractive to people with short term priorities. In my experience in Chicago it’s the popular choice for startups writing prototypes and marketing/interactive agencies writing throwaway apps. I don’t personally like rails but I don’t blame the technology so much as management for failing to understand how much value is lost when no effort is put on hiring experienced devs who can write maintainable code. For greenfield work it really shouldn’t add that much time.

By: Erik Reppen

Erik Reppen — Fri, 03 May 2013 19:12:00 +0000

What good practices does jQuery break? It’s just a function that spits out adapter/decorator objects for normalizing and reducing cruft in the DOM API. IMO, a very well-written one that you could a learn a lot about JavaScript from. But it mostly just covers the DOM. It doesn’t architect apps for you.

By: Rohan Nicholls

Rohan Nicholls — Fri, 11 May 2012 18:11:00 +0000

One of the best pieces of advice I ever had, and have kept it in mind ever since is similar to the last paragraph of this post, and could not be more on the money:

“Write your code as if the next person to work on it is a violent psychopath with anger management issues who knows where you live.”

By: Andrew Grimm

Andrew Grimm — Tue, 06 Sep 2011 11:13:00 +0000

Would things be different if not so many people Ruby developers were using it to develop Rails applications, but were working on longer-term non-Rails projects? People’s behaviour gets affected by their peers, so it wouldn’t just be the people working on the 10-year project that’d be different, but the people who go to the same meetups as them.

By: Andrew Grimm

Andrew Grimm — Tue, 06 Sep 2011 11:13:00 +0000

By: Colin Jack

Colin Jack — Tue, 30 Aug 2011 11:45:00 +0000

Yup, wasn’t suggesting you could use traditional interfaces given Ruby is so dynamic.

What triggered my comment was the bit about “Ruby on Rails projects are exceptional in a way: they are really small”, my thinking was just that as they grow (and maybe more importantly age) do traditional interfaces begin to come into their own?

By: Eleanor McHugh

Eleanor McHugh — Tue, 30 Aug 2011 10:29:00 +0000

Every time we perform a message send in Ruby we’re asserting an implicit type interface with the target object handling type failures via method_missing or else handing the responsibility back to the call site via an exception.

Naively this could be generalised by filtering on a series of responds_to? messages but we can never provide the same runtime guarantee that’s present in Java or C# as between message sends it is entirely possible for a Ruby object to drastically change its behaviour. Type in Ruby is therefore subject to an uncertainty principle which is at odds with these kinds of static guarantees.

This isn’t to say that a traditional interface mechanism couldn’t be added to the language, but for it to be authoritative it would have to be atomic in operation and enforce a global lock on code mutation throughout the guarded critical code section.

By: Enrico Teotti

Enrico Teotti — Tue, 30 Aug 2011 04:35:00 +0000

I blame people not reading about changes in their industry, instead embracing a cushy approach to writing software.

By: Bryan Donovan

Bryan Donovan — Mon, 29 Aug 2011 19:23:00 +0000

The strange thing is, there are plenty of great books on how to write good code in ruby. The design patterns one, Eloquent Ruby, Refactoring: Ruby Edition, Rails Antipatterns, The RSpec Book. It’s just that most people are too lazy to read them or actually apply the concepts.