Is it time for “Building a Static Site for Dummies”?

When you need a static site, is your first thought “can I use Rails”? If so, you’re a fucking idiot just like the author of the worst article on static sites ever written.

In particular, this passage makes me weep bitterly:

What if your requirements don’t require a dynamic server but you still want to use a mature web application framework your familiar with and trust such as Express or Rails.

Continue reading

Transpilers are not what you think

tl;dr: Explaining terms you don’t understand makes smart people ignore your article. And I’m not even all that smart, so… this must be pretty fucked.

Please don’t start your articles with a “What is X” when you have no god damn idea what the fuck you’re talking about. For instance, if you were wondering to yourself one day, “what is transpiling?”, you’d be making a huge mistake by reading the first paragraph of Hail, Babel! The Transpiling Overlord.

The author’s just plain stupid. Continue reading

Go Dependency Freezing

I’m diggin’ Go, but I’ve noticed there’s a tendency to “freeze” third-party code directly into one’s repositories on github. This is absolutely awful in my opinion – the code isn’t a part of your project, so it has no place in your repository! I do understand the problems, trust me, but this approach has some issues a lot of folks won’t realize until they’re hit HARD by a show-stopper. Continue reading

My new favorite error message

I wanted to turn a service on for a CentOS system, so naturally I ran chkconfig foo on. I forgot to run sudo first.

The message I got: You do not have enough privileges to perform this operation.

I don’t know why, but that makes me smile. I guess I sort of picture some bizarre currency called a “privilege”, and if you don’t have enough of those, you can’t afford to do stuff on the server. You don’t have enough privileges! Go find some more or get the fuck outta my server! Maybe if you and your buddies all pool your privileges you’ll be able to enable that service.

I half expect an in-app purchase window to pop up offering to sell me bundles of privileges. 10 privileges for $0.99, or BEST DEAL 100 privileges FOR JUST $4.99! Most Popular

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


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

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

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
    content = klass.get ""

# Normal use:

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

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

  def data_hash
    content = HTTP.get @url

# lib/testing.rb
module Testing

# Normal use: => ""))

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.