Re:Our datacenter uses clustering and vertical sca
on
Rails Recipes
·
· Score: 1
> A set of apps are deployed on a set of appservers, and > each app is given a classification which determines how > important it is. CPU is at a premium in this environment,
Really? I mean, sure, you don't want something to get caught in a tight loop and burn up cycles, but is the difference between a Ruby app and a Java app really that much? Anything involving bit-shifting or really dense math can be rewritten in C... I guess I just don't see the problem.
> The administrative costs in a high-avail datacenter > are not to be sneezed at!
Hm... I would think that the more servers you have, the more you would streamline administration, until you'd get to the point that a server failure would be something to be taken care of whenever you get around to it.
Re:It's nice for little things.
on
Rails Recipes
·
· Score: 2, Insightful
> Because it's not compiled, it seems like it's not a > good idea for really large projects either.
Hm, I think if you're doing a large site - e.g., multiple app servers - the speed at which the language's opcodes are processed won't be the bottleneck. It'll be database queries or the network connections or something like that.
> Java vs typical web languages isn't the sort of fight > Java minds on a performance front. Performance certainly > isn't the thing that makes a servlet/jsp design suck.
Well said indeed. The bottleneck there is rarely the VM, it's the database queries or the network connections or disk I/O or something else. That's the strange thing about the "x doesn't scale" argument where x == Ruby|Python|Java - once you get a certain number of servers, the speed at which the language opcodes are being processed fades into the background.
> Find someone who switched from Java to flash for performance. > It's got flexible networking and rendering that wipe the > floor with flash.
I think Flash has an edge here in that there seem to be more people who know how to do whizzy graphics in Flash than in Java. I mean, my perception is that not many folks have done much working with the Java 2D API.
But Flash is starting to get some good frameworks for user interfaces - witness ActionStep. We're using it for indi and it's working out well.
We've only got a small database (17 million records or so), and PostgreSQL 8.1 has been handling it fine. But I'm still looking forward to seeing how 8.2 improves things.
> as a big corporation, you can leech the efforts of > thousands of unpaid but experienced contractors and > never once feel the need to give back. (e.g., Thanks Apache!)
True, but an open source project doesn't take much to run - just a server and some bandwidth, and the bandwidth needs can be minimized via judicious mirroring.
I recently upgraded RubyForge to Apache 2.2 and it's been such an improvement. mod_cache is great, the worker MPM is solid, and now I can run ViewVC under mod_python. And there's mod_proxy and mox_proxy balancer for making Rails apps work nicely with Mongrel. If you're still back on 1.3, I highly recommend 2.2.
One nice thing about these drives is that the filesystems can be read by any OS without hassles. This means we can include both a Mac and a PC binary (and a Linux one, once I get cracking on that) for indi on a drive and you can move your data from machine to machine with nary a hitch. Good times.
> I'm not sure how you declare the Person class before > you instantiate it from the class loaded by the network.
Right, exactly - since Java is statically typed, the type needs to be declared somewhere - probably via an existing interface or base class or some such. That's kind of the beauty of dynamic typing - types don't need to be declared in advance.
> Possibly Java's greatest strategic feature is the classloader > that can dynamically retrieve classes across the network > at runtime and safely instantiate them.
It's kind of interesting how this feature conflicts with Java's static typing system. I mean, if you're receiving a bytestream across the network you need to have some sort of way to unmarshal it into objects, and doing that in Java involves a fair bit of casting and exception catching. You see the same sort of issues with XML to object mappers, ORMs, and so forth.
Static typing has its advantages, but it seems to get in the way more and more when you're doing interesting things.
> If you feel strongly enough about it, find another > job where such issues are not likely to arise.
That's the crux of the matter. There are approximately one slew of jobs out there that won't be morally questionable, and you'll sleep better at night knowing that you're not enabling nasty behavior. It's a small victory but an important one.
Also, for Flash UI goodness, try ActionStep. It's an open source, BSD licensed UI framework for Flash. We use it in indi and it's good stuff.
> If nobody cares about a project it will die, so why is that bad?
Yup, I was thinking more of a project that had interested users/developers, but the founder or core developer was no longer interested.
> And if someone does care, they will fork it and update/maintain it, > which is clearly a good thing.
Perhaps, but it seems nicer if the project can be gracefully handed off to new owners rather than going through the controversy and flaming and discontent that usually accompanies a fork.
> Not only did Dawes lack vision, he got in the > way of everyone who did have vision.
That's rather well said. If you're the author of a successful open source project and you find yourself unable to keep working on it, do you have a duty to turn it over to the other developers for continued maintenance? I can't think of a reason not to, and if you don't, it'll either die or get forked, both of which aren't pleasant outcomes.
> For those of us who can't afford to run a commercial database package, > and have been running open source databases from the beginning, > this isn't news. MySQL and Postgres are your friends.
The beauty of podcasts is that I can listen to them in my car - videocasts demand my full attention. It's great to be able to keep up with the latest Java news while sitting in traffic; makes that time feel less wasted. This interview wasn't too bad neither.
Slashdot Mirror
> They compare PostgreSQL 8.2 vs MySQL 4.1.20 and MySQL 5.1.20a.
Mod parent up and all that. We're using PostgreSQL 8.2 for a small (18 million records) database and are pleased as punch with it. And here, too.
> In fact almost no one uses ruby.
11000 RubyForge users disagree with that...
I've got a fairly busy email server and this sounds like a great thing for the queue files... lots of little files, lots of random access.
Of course, the other posts about flash memory degrading after n writes would be something to watch, too.
> This looks liike an opportunity for Postgres
Right on. And with the excellent performance of the newly-released PostgreSQL 8.2, it's a good time to make the switch.
> A set of apps are deployed on a set of appservers, and
> each app is given a classification which determines how
> important it is. CPU is at a premium in this environment,
Really? I mean, sure, you don't want something to get caught in a tight loop and burn up cycles, but is the difference between a Ruby app and a Java app really that much? Anything involving bit-shifting or really dense math can be rewritten in C... I guess I just don't see the problem.
> The administrative costs in a high-avail datacenter
> are not to be sneezed at!
Hm... I would think that the more servers you have, the more you would streamline administration, until you'd get to the point that a server failure would be something to be taken care of whenever you get around to it.
> Because it's not compiled, it seems like it's not a
> good idea for really large projects either.
Hm, I think if you're doing a large site - e.g., multiple app servers - the speed at which the language's opcodes are processed won't be the bottleneck. It'll be database queries or the network connections or something like that.
Anyhow, it's working pretty well for us so far...
> Java vs typical web languages isn't the sort of fight
> Java minds on a performance front. Performance certainly
> isn't the thing that makes a servlet/jsp design suck.
Well said indeed. The bottleneck there is rarely the VM, it's the database queries or the network connections or disk I/O or something else. That's the strange thing about the "x doesn't scale" argument where x == Ruby|Python|Java - once you get a certain number of servers, the speed at which the language opcodes are being processed fades into the background.
> Find someone who switched from Java to flash for performance.
> It's got flexible networking and rendering that wipe the
> floor with flash.
I think Flash has an edge here in that there seem to be more people who know how to do whizzy graphics in Flash than in Java. I mean, my perception is that not many folks have done much working with the Java 2D API.
But Flash is starting to get some good frameworks for user interfaces - witness ActionStep. We're using it for indi and it's working out well.
> Writing a lexer/parser is easy,
And even more so since there's a JavaCC grammar for COBOL.
> 8.2 is positioned as a performance release.
We've only got a small database (17 million records or so), and PostgreSQL 8.1 has been handling it fine. But I'm still looking forward to seeing how 8.2 improves things.
And we're using it in another production system, too, which is going to get pretty big (I hope). Lively times!
> as a big corporation, you can leech the efforts of
> thousands of unpaid but experienced contractors and
> never once feel the need to give back. (e.g., Thanks Apache!)
True, but an open source project doesn't take much to run - just a server and some bandwidth, and the bandwidth needs can be minimized via judicious mirroring.
But I agree that corporations should support the developers of the open source projects they're using.... +1 on that.
I recently upgraded RubyForge to Apache 2.2 and it's been such an improvement. mod_cache is great, the worker MPM is solid, and now I can run ViewVC under mod_python. And there's mod_proxy and mox_proxy balancer for making Rails apps work nicely with Mongrel. If you're still back on 1.3, I highly recommend 2.2.
One nice thing about these drives is that the filesystems can be read by any OS without hassles. This means we can include both a Mac and a PC binary (and a Linux one, once I get cracking on that) for indi on a drive and you can move your data from machine to machine with nary a hitch. Good times.
> The XMLHttpRequest certainly does execute on the server
Hm... does it? Wouldn't that require a Javascript interpreter in the web server?
> I don't even play the game, but that was a god damn great episode.
Two favorite lines:
"This could be the end of the world... of Warcraft."
And:
"How can you kill that which has no life?"
> QED, pronounced "talking the talk, not walking the walk".
Hehe, so true, I feel that way so often! Well, back to reading the Rails 1.2 upgrade notes...
> I'm not sure how you declare the Person class before
> you instantiate it from the class loaded by the network.
Right, exactly - since Java is statically typed, the type needs to be declared somewhere - probably via an existing interface or base class or some such. That's kind of the beauty of dynamic typing - types don't need to be declared in advance.
Right, but aren't there a flurry of ClassNotFound exceptions and whatnot to catch? Also, I guess what I'm thinking about are things like:
person = readFromNetworkSocket(); # reads in a Person
puts person.age; # yay, we're calling methods
where you don't have a predefined Person type; instead, the data gets read from the stream and a new type is defined at runtime.
> Possibly Java's greatest strategic feature is the classloader
> that can dynamically retrieve classes across the network
> at runtime and safely instantiate them.
It's kind of interesting how this feature conflicts with Java's static typing system. I mean, if you're receiving a bytestream across the network you need to have some sort of way to unmarshal it into objects, and doing that in Java involves a fair bit of casting and exception catching. You see the same sort of issues with XML to object mappers, ORMs, and so forth.
Static typing has its advantages, but it seems to get in the way more and more when you're doing interesting things.
> If you feel strongly enough about it, find another
> job where such issues are not likely to arise.
That's the crux of the matter. There are approximately one slew of jobs out there that won't be morally questionable, and you'll sleep better at night knowing that you're not enabling nasty behavior. It's a small victory but an important one.
Also, for Flash UI goodness, try ActionStep. It's an open source, BSD licensed UI framework for Flash. We use it in indi and it's good stuff.
I think we'll stick with PostgreSQL for our little database.
> If nobody cares about a project it will die, so why is that bad?
Yup, I was thinking more of a project that had interested users/developers, but the founder or core developer was no longer interested.
> And if someone does care, they will fork it and update/maintain it,
> which is clearly a good thing.
Perhaps, but it seems nicer if the project can be gracefully handed off to new owners rather than going through the controversy and flaming and discontent that usually accompanies a fork.
> Not only did Dawes lack vision, he got in the
> way of everyone who did have vision.
That's rather well said. If you're the author of a successful open source project and you find yourself unable to keep working on it, do you have a duty to turn it over to the other developers for continued maintenance? I can't think of a reason not to, and if you don't, it'll either die or get forked, both of which aren't pleasant outcomes.
> For those of us who can't afford to run a commercial database package,
> and have been running open source databases from the beginning,
> this isn't news. MySQL and Postgres are your friends.
Right on. Those of us with over 16 million records in a PostgreSQL database are pretty happy with what we're seeing. And we're willing to run the same database on production servers as well.
The beauty of podcasts is that I can listen to them in my car - videocasts demand my full attention. It's great to be able to keep up with the latest Java news while sitting in traffic; makes that time feel less wasted. This interview wasn't too bad neither.
> It should serve as a reminder to us all to labour to avoid clichés.
We should avoid them like the plague.