Disqus - Latest Comments for jamesgolick

Re: Why RubyGems Needs Loren Segal | James on Software

jamesgolick — Fri, 03 Jun 2011 17:44:11 -0000

Yes, I have. I don't see SourceIndex back in RubyGems, and I have yet to see any evidence that legacy APIs are going to be maintained going forward. I have yet to see any evidence that they're not just going to revert to their obnoxious, anti-social behaviour as soon as all of this blows over. We're talking about 4+ /years/ of this, and you expect us to believe that after two weeks of relative silence from them, everything is going to change?

In fact, what I see is proof that things won't change. I see you looking for evidence that these changes aren't needed (your blog post looking for breakages caused by 1.8.5), trying to discredit Loren (apparently his share of the personal conflicts discredits him, while the same can't be said about Eric and Ryan), and bolster your position that the ruby community should live with the current status quo (bringing on a release manager who is a member of this social circle).

Re: Why RubyGems Needs Loren Segal | James on Software

jamesgolick — Fri, 03 Jun 2011 16:48:53 -0000

> ...I've witnessed their outright rude interactions online.
> Cooler heads are needed here...

Then by your own argument, Eric and Ryan should go.

Re: Why RubyGems Needs Loren Segal | James on Software

jamesgolick — Fri, 03 Jun 2011 16:29:18 -0000

> My only concern is that it does gloss over some personal conflicts on both sides of the fence...

I'd really appreciate if you would be upfront about the fact that you are personal friends with these people. I disclosed my possible biases. You should too.

> ...that seems to be a good way for him to gain the community's trust...

As far as I can tell, Loren has a lot more of the community's trust than the current RubyGems team.

Re: James on Software | Introducing Trample: A Better Load Simulator

jamesgolick — Tue, 15 Feb 2011 01:13:14 -0000

This isn't a rails plugin. I'm not entirely sure why it would need to be updated for a version of rails?

Re: We are experiencing too much load. Let's add a new server. | James on Software

jamesgolick — Mon, 01 Nov 2010 16:17:35 -0000

If you're attempting to alleviate load being imposed on a cluster, then fundamentally, that cluster must be short on some resource. If that resource is necessary to bootstrap a new machine, then bootstrapping that machine will increase the load on the cluster before it decreases it. It doesn't matter what kind of software you're using.

Re: We are experiencing too much load. Let's add a new server. | James on Software

jamesgolick — Mon, 01 Nov 2010 15:56:35 -0000

Totally. That's why I specifically used the words "storage cluster". (Also, GlusterFS, like my toaster, is NoSQL ;-)).

Re: Crazy, Heretical, and Awesome: The Way I Write Rails Apps | James on Software

jamesgolick — Tue, 20 Jul 2010 12:15:28 -0000

I'm using this: http://github.com/thoughtbo...

Re: Two Weeks With Cassandra | James on Software

jamesgolick — Wed, 05 May 2010 11:00:08 -0000

Not at all. There are a few places we're probably still going to use it, and I have a bunch of awesome changes that I'm going to push in the next little while.

Re: Two Weeks With Cassandra | James on Software

jamesgolick — Tue, 04 May 2010 17:02:56 -0000

The cases have 4 disk bays.

Re: Two Weeks With Cassandra | James on Software

jamesgolick — Tue, 04 May 2010 16:40:58 -0000

Separate disks for each, yes. Soon, I'd like to upgrade to RAIDed disks for durability.

Re: Two Weeks With Cassandra | James on Software

jamesgolick — Tue, 04 May 2010 10:37:17 -0000

Yes. Although, we are in the process of moving various other functionality over to cassandra since it has been so successful thus far.

Also, CPU usage is no longer hovering around 0, but I'll explain more in another post.

Re: What does "scalable database" mean? | James on Software

jamesgolick — Tue, 30 Mar 2010 14:24:58 -0000

CouchDB (on its own) is not horizontally scalable, because once a single machine is completely saturated with writes, you can't just turn on another to alleviate load. The lack of (built-in) partitioning makes all the difference.

That's not to say that couchdb isn't a great product, though. I love couch!

Re: What does "scalable database" mean? | James on Software

jamesgolick — Tue, 30 Mar 2010 13:51:42 -0000

I'm only interested in including databases whose operational properties I'm able to understand. Given that those two products are managed by somebody else and closed source, I don't think that they belong in this discussion.

Re: Most NoSQL DBs Are Not Scalable | James on Software

jamesgolick — Tue, 30 Mar 2010 00:44:56 -0000

There's nothing to substantiate. Something either scales horizontally or it doesn't. It's a complex feature that has to be designed and built for, not some magic property that just appears when you remove schemas and SQL.

Re: Crazy, Heretical, and Awesome: The Way I Write Rails Apps | James on Software

jamesgolick — Sat, 27 Mar 2010 22:26:13 -0000

Yes.

Re: Crazy, Heretical, and Awesome: The Way I Write Rails Apps | James on Software

jamesgolick — Fri, 26 Mar 2010 12:20:31 -0000

Yep, that's what we do.

Re: Crazy, Heretical, and Awesome: The Way I Write Rails Apps | James on Software

jamesgolick — Fri, 26 Mar 2010 12:16:43 -0000

The pattern matters, I agree. But, that doesn't mean that introducing a new pattern is a valid concern. If your team can't handle a new pattern (especially a straightforward one for which there is much literature), something is deeply, deeply wrong.

Re: Crazy, Heretical, and Awesome: The Way I Write Rails Apps | James on Software

jamesgolick — Fri, 26 Mar 2010 11:55:08 -0000

This blog is static html, generated by webby. Here's a gist of the helper I wrote to generate those code blocks.

http://gist.github.com/345040

Re: Crazy, Heretical, and Awesome: The Way I Write Rails Apps | James on Software

jamesgolick — Fri, 26 Mar 2010 11:53:57 -0000

I'm not suggesting that anybody use a DI framework. That's certainly not necessary. But, a service layer (or something like it) is if you want to do this in rails.

It's not really possible to properly inject dependencies in to model objects (because the ActiveRecord framework controls instantiation). So you need another layer that handles all the coordination.

Re: Crazy, Heretical, and Awesome: The Way I Write Rails Apps | James on Software

jamesgolick — Fri, 26 Mar 2010 11:33:18 -0000

This is always the "big question" when people talk about modular code: how far is too far? How much decoupling do we need?

Of course, the answer is situational, and good judgement is necessary. But, my philosophy on this is that if you're writing mockist unit tests, they will guide you until you've built up enough experience to make those judgements for yourself.

If something starts becoming hard to test, it's time to break it up. Until then, just keep on going with it.

I'm not compelled by this "too many objects, I don't know which one to use" argument. It's easy to imagine php people making the same argument about model objects. "Should I write SQL in my templates (like I'm used to) or use the model object? I don't know which one to use."

Any programmer worth their salary is going to be capable of adapting to new patterns.

Re: Crazy, Heretical, and Awesome: The Way I Write Rails Apps | James on Software

jamesgolick — Fri, 26 Mar 2010 11:25:10 -0000

> You should open your mind to the possibility that when you save or when you log something IS business logic

Actually, I've shipped dozens of rails apps that were written using the anti-pattern I describe above. My mind was more than open to it.

Part of the point of using DI here is to make the unit tests isolated. If you don't isolate your unit tests with mocks and stubs, they're functional or integration tests anyway. And your integration tests are *always* important. DI or not.

> Adding more code is the last resort..

It's not really much more code. And more code is nearly always worth it when it enhances clarity.

> "theoretical concerns"

I listed several examples of non-theoretical concerns in the article.

Re: Crazy, Heretical, and Awesome: The Way I Write Rails Apps | James on Software

jamesgolick — Mon, 22 Mar 2010 16:11:04 -0000

Perhaps this was a bad example, because it could have been implemented with observers. There are a lot of cases where putting all this logic in to your models creates tight couplings and problems that can't be resolved with observers.

As for simplicity, I'm still not sure how you can call a callback that much easier than:

def save; something_before_save; super; end

And the above doesn't come with the weird side effects of the callback system.

Re: Crazy, Heretical, and Awesome: The Way I Write Rails Apps | James on Software

jamesgolick — Mon, 22 Mar 2010 16:06:32 -0000

The problem is that you can't inject in to ActiveRecord objects, because you don't control instantiation. If you add parameters to initialize, you'll completely break the behaviour of the objects.

That's because activerecord expects the object to be under its control. Which is fine, because if you respect SRP, then you don't need to add all kinds of additional stuff to AR::Base subclasses. They inherit just about everything they need to perform their responsibility from their superclass.

Callbacks inside of an object just don't make any sense to me. If you're implementing the object, why do you need a callback? "def save; do_something_before_save; super; end" is a hell of a lot clearer than some declarative injection of a method name in to an array that gets called behind closed doors inside the AR lifecycle. Especially when you consider the fact that those callbacks frequently get injected by plugins.

But the issue isn't really with callbacks, it's with massive SRP violations. I've just never seen this kind of design work out in the long term.

Re: Crazy, Heretical, and Awesome: The Way I Write Rails Apps | James on Software

jamesgolick — Mon, 22 Mar 2010 15:53:08 -0000

Putting logging in the controller is a reasonable solution to this particular problem. But it doesn't work in all cases. And used as a pattern, you wind up with fragments of logic all over your application. Not to mention that functional tests are a lousy mechanism.

If your reason for disliking service objects is that programmers will forget to use them, then I'm not sure there's really an argument to be had here. Any decent developer should be capable of adapting to new methodologies. If they're not, then they're probably not worth having on the team in the first place.

As for being overwhelmed with possible decouplings, the point is that things should just be built decoupled from the start. Lots of people and projects have done this successfully.

You don't have to worry about the future. You just have to worry about building the present in a way that respects the tried, tested, and true principles of object oriented programming. If you don't like OO, that's another argument altogether, but if you do, cramming all of your logic in to a small handful of objects is pretty clearly a bad idea.

Re: On Mocks and Mockist Testing | James on Software

jamesgolick — Mon, 15 Mar 2010 18:15:14 -0000

That's a pretty interesting idea. To make it work, you'd have to indicate which concrete object a mock is doubling to the framework. Most of the existing ruby mocking frameworks don't do that, but it could be added pretty easily.

Also, this problem is solved entirely by static typing.