This just in: DHH is still a douchebag

Ah, DHH. A lovely series of articles showing off your inexperience once more.

And this from an “industry leader” who should know better.

There are some wonderful quotes from the father of Rails that tell me he’s still the same douchebag he’s always been, and still has no idea how quickly complex projects go bad when built with his OMFG COUPLE EVERYTHING YAY mentality. Continue reading “This just in: DHH is still a douchebag”

HI IM RAILS I CAN HAZ MAGIC?

Again, why I hate all you fucking Ruby developers

I have a serious issue with Ruby magic.. no, wait, Rails magic… hmm, well no, maybe magic within the funky “sub-framework” I use?

Oh FUCKIN’ A, I don’t know. There’s a project I work on and it uses Rails. And it’s using an unnamed and incredibly shitty “sub-framework” (referred to henceforth as “Cyclops”) that forces us to use very specific gems whether we like it or not. In some cases the gems are cool, and in some cases they are the fucking devil himself. Continue reading “HI IM RAILS I CAN HAZ MAGIC?”

The Hobbit: Too Real?

(Caveat: I have not seen The Hobbit in any form, I’m just reporting based on similar experiences)

Chapter I: The Story So Far

A lot of people over the years have touted the advantages of a faster frame-rate. In games, frame-rate has almost become something of a status symbol – games boasting a high frame-rate get a special place in gamers’ hearts, even if the game is no good. Gamers with the system powerful enough to achieve high frame-rates are demi-gods to whom us lesser nerds must bow down.

But many of us, myself included, have felt that this whole discussion is a bit… absurd. Let’s face it, the human eye is okay with 24 frames per second. If it wasn’t, movies wouldn’t have survived as they have, and at that frame-rate. Beyond that, some people feel the picture gets more fluid or realistic or whatever, but there’s always been debates about the value of high frame-rates. Continue reading “The Hobbit: Too Real?”

Improving on idiocy

I pointed out in my last post the idiot trying to improve dependency injection by reinventing it. During my rip on his ignorance, I pointed out a lot about what was wrong and mentioned a few times that I didn’t like his approach, but I didn’t provide anything better for his specific situation. I also mentioned that a service class might be a good idea… but again, I didn’t even hint at what that would look like.

So how would I solve his problem with true DI? Well, a naive approach would simply let the caller decide what class or object to use for pulling the data and parsing it:

# lib/testing.rb or whatever
module Testing
  def self.foo(klass)
    content = klass.get "http://mygreatservice.example.com/person/1.json"
    JSON.parse(content)
  end
end

# Normal use:
Testing.foo(HTTP)

# In a test:
class FakeHTTP
  def self.get(uri)
    return '{"id":1,"name":"matz"}'
  end
end

Testing.foo(FakeHTTP)

We can immediately see some benefits here over his “Injector” bullshit. For starters, there’s no dependency on HTTP at all. We just depend on some object that responds to get and returns a hash. In a truly simple case, this is a pretty good example of DI to decouple a minor dependency.

But let’s assume his Testing module is more complex, and Testing.foo does more work. In that case, we can do far better! The naive approach requires that our DI classes return a string that can be interpreted as JSON. The logic to get data and parse data is very coupled to the Testing module, which might be a problem in itself. So here’s what I’d recommend for refactoring:

# lib/service.rb
class DataProcessor
  def initialize(args = {})
    @url = args[:url]
  end

  def data_hash
    content = HTTP.get @url
    JSON.parse(content)
  end
end

# lib/testing.rb
module Testing
  def self.foo(service)
    self.do_something_with(service.data_hash)
    self.do_other_stuff
  end
end

# Normal use:
Testing.foo(DataProcessor.new(:url => "http://mygreatservice.example.com/person/1.json"))

This looks kind of awkward at first glance, and I could certainly be persuaded to change class and/or method names in a real-world scenario, but what I’m aiming for gives us a truly isolated data service that can be injected into the Testing module.

Remember, I’m assuming that the Testing module is bigger and does more stuff, hence my dummy function calls.

So now we have a central class to process data. It pulls data from an external service and parses it as JSON, returning a Ruby hash that gives us something that’s important for the rest of the module, and probably other parts of the application. Having a class for that data gathering means we can keep the “give me compatible data from some service” logic separate from whatever else this weird Testing module does.

We’re also keeping the hard-coded URL out of the service as well as the module, allowing us to configure that from whatever source we need. If we’re truly certain that the URL should be hard-coded, it’s easy enough to make that live in the service, I’m just showing that we don’t need any of the system to rely on higher-level knowledge of configurable elements.

This approach gives us some significant benefits:

  • We have a general-purpose json-service-to-hash class which may be useful elsewhere in the application
  • We can very easily inject something that reads from a file instead of pulling from a service
    • We can do the same thing with other endpoints, too – databases, console input, etc. As long as the service class returns a simple hash from its data_hash method, the Testing module doesn’t care HOW the data got there, just that it got data
  • For creating unit tests, we can stub DataProcessor or build a test-specific service class
    • Usually stubbing is easier, but we have the flexibility if we need it

Hopefully this explains DI as well as the value of service classes a little bit. And hopefully the original author of the “Interceptor Injection” pattern reads it and realizes he’s way too inexperienced to be writing about programming on the web.

Dependency injection by any other name… still means you’re an idiot

Summary for those who don’t want to read yet another angry nerd rant

Dependency Injection is still Dependency Injection even if you use an approach that’s specific to Ruby 2.1 and decide to call it “Interception Injection”. Just like incompetent developers are still incompetent even if they start inventing fake patterns. Continue reading “Dependency injection by any other name… still means you’re an idiot”

Stardock makes a huge mistake… and apologizes?

I don’t have enough time for Nerdbucket.com anymore, and it shows very clearly on the “games” side of things… though this article’s lateness should also be a pretty good indicator. Too much is going on in my real life, unfortunately.

But I thought I would take a moment to pay respect to Stardock. After Galactic Civilizations II, particularly with its expansions, I was very impressed with their quality of games. So much so that I pre-ordered Elemental: War of Magic. Continue reading “Stardock makes a huge mistake… and apologizes?”

The nerd’s small heart grew three sizes that day

I’m removing all names, but I received a very disturbing email recently about my inappropriate but horribly funny anti-obesity page, “You are too fat”. The page, for those who are honestly too lazy to click the link (oh sorry iPad users, you can TAP the link, too), has a fake “ideal” weight calculator. And up until recently, it suggested things like 0% body fat…. Continue reading “The nerd’s small heart grew three sizes that day”

Automated testing saves the day

I’m working on a Ruby on Rails application, where automated testing is an absolute must. Unlike Java or C++, you don’t have any kind of useful compile-time warnings and errors to tell you where you’ve screwed up, made a typo, etc. Most errors in a Rails web app happen when a user interacts with your code, so if you don’t test, you don’t know about bugs until it’s too late. This is one of many reasons I’m wishing for a nice C++ project to play with… but that’s another topic for another day…. Continue reading “Automated testing saves the day”