jamesgolick

More like Memory Allocators 405 haha

Actually, the reason is that aspartame has a high glycemic index, so your body reacts to it roughly the same way it reacts to sugar.

http://www.glycemicindex.com/

Oops - meant to reply here. http://www.livestrong.com/article/536467-does-stevia-affect-...

> You have to think a bit more about what OO really is about.

If you want to have a respectful debate, I'm completely game. If you'd prefer to continue with your incredibly condescending tone, then I'll bow out here.

> Regardless of any minor difference of opinions, I think what you're trying to bring to the rails community is to be commended.

Thanks a lot, man.

The point I was making was that you can use the library in a different way successfully.

I've read at least a dozen papers on the history of OO, not to mention books and papers on current practices. This is what I came up with. I made what I think is a pretty coherent argument for why in the article. I'd love to hear your refutation of the points I made in there.

You can move over slowly by building new components using objectify, and leaving the rest of your legacy app the way it is, if you like. It's designed specifically to be able to coexist with what you've got.

> It's hard to strike a balance between a strong design which takes a lot of time to work within, and one that just allows you to get things done, but once your project begins to grow in size and complexity, and testing becomes even more important, these things really do start to matter.

The whole point of objectify is that it actually makes it pretty reasonable to work this way right off the jump. I would have a hard time believing that it's really any more work to build an objectify app than it is to build a vanilla rails app - at least once you become accustomed to the paradigm.

> That said, if you have a large amount of single method classes, you might need to take a look at why you need them and find a better approach (which will vary from project to project).

I don't buy that. My project has hundreds of single method classes and it's by far the best factored non-trivial application I've ever seen (anecdotal, obviously, but so it goes).

I gave an answer better than that. Did you read the post?

Because of SRP.

Mixins/modules and open classes do not separate your class in to multiple components - merely multiple files. As I explain in the article, for separate components to be useful, they have to be "protected" from each other - encapsulation, in other words.

This would be funny if it made any sense and if it wasn't a ripoff of an old Merlin Mann tweet about DHH.

> ...a very complex system

Auto-pilot on a 747 is a very complex system. RubyGems is not.

> hostile fork

What's hostile about proving points with code?

> ...the division that would be caused by a fork...

You still haven't explained what the problem with this "division" is. Why will this be different than the rails/merb fork? Honest question: are you afraid of division or of your friends losing control of the project?

> There is no denying that Eric+Ryan have had personal conflicts with Loren...

As well as just about anybody else who has tried to work with them.

> However, Evan Phoenix...

Evan is a great and brilliant guy, but let's be honest here. He's another personal friend of the current maintainers and (former?) Seattle.rb member. We need fresh blood.

If you weren't paying such an enormous premium for your hardware, you'd have a lot more cash. On a per-dollar basis, you're paying anywhere from 2-10x the price for computing power on the cloud, depending on which resource you look at (CPU, Memory, Disk IOPS, etc).

Seriously. Do the benchmarks.

If they weren't paying 2-10x for their power (the cloud tax), it wouldn't be so bad.

The fundamentals of capacity planning do not change based on the magnitude of your data growth. Why would they?

We're mostly talking about looking at your data growth curve and extrapolating points in the future. Why would that become impossible just because the curve is steep?

First of all, there are managed hardware providers who can get you hardware online in less than 4 hours. Second of all, capacity planning can save you from "needing elasticity". Third of all, if you were on machines that gave you reasonable performance (i.e. not shared hosting), you probably wouldn't "need" nearly as much elasticity.

> You have a "Creative Director"

> it's all about technology and not about people or emotions.

Yes, hiring a designer definitely shows a complete disregard for the people using the product.

So, I think my biggest problem with this app is the UI. The layout is okay, but there are lots of places where the spacing is really far off.

Especially the enormous yellow bar on the front page. The type is way too big for the box, and the facebook connect icon is way too big. It needs to be displayed in its natural size - or an appropriately sized one needs to be found.

In general, little issues like that plague the UI and make it feel unpolished. Fixing them will go a long way towards making the app feel like something I'd want to use.

What's painful and embarrassing is when somebody who didn't actually read the article calls it "painful and embarrassing".

> Patterns are still patterns whether you acknowledge them or not, and they are not defined by the LOC or number of classes they require in language X.

> Refusing to admit that patterns are used hurts your development team and the community, because patterns (simply identifying them) serve a very important purpose.

> Well, design patterns are just like [agile] metaphors, but they are meant for code, not UI.

> For instance, consider the factory pattern versus the builder pattern. Both are concerned with creating objects, but a builder is also concerned with the assembling of the object. This is a relatively subtle but pretty noticeable difference. Telling someone you are using a "builder pattern" should immediately ring a bell in their heads saying, "oh, it’s not just a factory".

Patterns are specific nomenclature not implementation.

I'm totally with you. The title was tongue in cheek.

In retrospect, logging was absolutely the wrong example for this article. I intend to follow up with a better example.

In the case of logging, an observer may or may not be appropriate depending on the specifics of your application. In your Go app, it sounds like a NotificationObserver makes perfect sense.

The broader point that I was trying to make in the article was that coupling all of your business logic to your persistence objects is a bad idea. It couples all of the concerns together, and with larger codebases, makes for slow tests and code that's difficult to reason about and debug.

If your business logic lives outside of your persistence layer, service objects can be a great way to coordinate several objects necessary to complete some user action. Observers can work quite well too.

As long as business logic is decoupled from persistence, I think a big step has been made towards better code.

Totally fair.

My data is from a real-world application. One that gets plenty of traffic. Friendly has served almost 50 million hits since we put it in to production two weeks ago.

It actually happens to be quite a write-intensive workload. We have definitely seen a slow down on writes, but the speed up on reads has more than compensated for it.

We do have more data than RAM. But, most of the data that actually gets read is fresh, so it's hot in cache.

Of course Friendly isn't going to be right for everybody. But, I just want to make it clear that my data isn't from synthetic benchmarks. It's from production.

It already works with Postgres. Just set :adapter => "postgres" when you call Friendly.configure.

Awesome. You guys rock!

Actually, we do run redis in production, and it has been awesome for us. But, for this particular aspect of our application, we see about 20GB of data growth per week. So, an all-in-RAM db isn't really practical.

Either way, durability wasn't the issue for us. Mongodb has no write concurrency. So, when it got so overloaded with data that queries were taking forever, we had no way to purge older data without blocking all read & write operations for hours.

I probably wouldn't tell somebody to go practice typing either, but that's not because it isn't important. I would just take it for granted that they could already type.