$ wget -S http://www.idsoftware.com/ --08:57:08-- http://www.idsoftware.com/
=> `index.html' Resolving www.idsoftware.com... 192.246.40.185 Connecting to www.idsoftware.com|192.246.40.185|:80... connected. HTTP request sent, awaiting response...
HTTP/1.1 503 Service Unavailable
Content-Type: text/html
Date: Thu, 08 May 2008 12:57:20 GMT
Connection: close
Content-Length: 28 08:57:08 ERROR 503: Service Unavailable.
I recently gave my DOOM 3 box to a friend who bought a new laptop... after several years the game should be playable now on a medium-powered laptop. That's the way to do it - buy the "3.years.ago" game of the year and play it with all the dials turned up.
I graduated as a comp sci major, and my huge beef with the computer science and engineering professors was that they lacked the ability to translate the material into something that someone would actually USE. Go home and write a B* tree because this is a database class... well great. It's very rare to see someone design their own new database structure these days, when they could just install SQL or mySQL or Oracle or whatever... Ergo, that class was utterly worthless to me. I had a lot of experiences that were just like that. Took a class on cryptography, but because the math involved in most cyptography is very complex, the class runs along with a lot of handwaving, and so all you end up doing is implementing other people's algorithms; you don't need a class for that, you could do that in any generic programming class.
I can see where this guy is coming from, but at the same time, implementing these algorithms teaches you 1) how to concentrate and focus 2) how to test your work and 3) how to do "hard stuff" in whatever language the class is using. It's hard work, but it's interesting stuff... or at least it should be if you're a comp sci major.
Re:Chapter 10 - Large Projects
on
Advanced Rails
·
· Score: 1
> Defining large in terms of the size of the code base is not appropriate
Hm, at least, KLOC is a contributing factor. Maybe cyclomatic complexity would be a better measurement?
> I'd imagine "large" is being used here to mean an > ability to tolerate enterprise load level.
Yup, but an enterprise load level usually means a server farm with a web/app/db breakdown and some caching servers. At that level, the Ruby interpreter and the framework method calls usually aren't the bottleneck - there's s DB to be tuned, stuff that should go in memcached, page and fragment level caching, and so forth; that makes the difference.
> the framework encourages development without much concern for database speed
Very true. But you know what they say about premature optimization... and you can always load a bazillion records into a test db and find the bottlenecks. I just sorted out one of those for a customer a few weeks ago; PostgreSQL's EXPLAIN ANALYZE to the rescue...
Re:Chapter 10 - Large Projects
on
Advanced Rails
·
· Score: 1
> Production architecture, webserver integration, and > deployment were all huge pains two years ago.
Yup. Judicious Capistrano + mongrel_cluster + monit usage make a difference these days, but it would still be nice to have fewer moving parts. Maybe Rubinious will get us there.
Incidentally, "cap deploy:check" totally rocks.
Re:Chapter 10 - Large Projects
on
Advanced Rails
·
· Score: 3, Interesting
> Horror stories, these are the only stories I have heard from anyone > trying anything close to what I would consider 'large' projects.
I've found that Ruby has a way of making large projects into small ones. Going from 250 KLOC in Java to 10 KLOC in Ruby would not surprise me.
> RoR is not the right tool for many significant sized project, especially in the enterprise environment.
Most enterprise environments are a morass of battling departments, entrenched legacy technologies, and outdated, inefficient processes. While that significant-sized 30 person project is bogged down for two months negotiating more app server licenses, the 3 person Rails team can knock out a fully tested application that does the job.
Required reading
on
Advanced Rails
·
· Score: 2, Interesting
> I don't know if I'd go so far > as to label it required reading
I've been doing Rails for about two years and still found this book to be very helpful. It should be called "Rails For Real Projects" or something, because he covers stuff you _will_ run into. The nice thing about this book is that he doesn't waste time explaining what 'puts' does and such; he gets right down to business. The section on modifications that Rails makes to the Ruby standard library is worth the price alone.
> But if you are letting you AI out into Second Life and > comparing it to intelligence there, surely you are setting the bar rather low?
Time for an "Office" quote:
Dwight: Second Life is not a game. It is a multi-user, virtual environment. It doesn't have points or scores, it doesn't have winners or losers. Jim: Oh it has losers.
> or maybe you could actually learn what 'postfix' is.
You're right, I misunderstood the post. I thought the question was "what's the successor to Apache that will do for Sendmail what Postfix did - e.g., make it obsolete?"
...which for me is one of the trickier bits of Apache, get Rich Bowen's excellent mod_rewrite book. It's helped me figure out a bunch of complicated stuff and even has a great chapter on when _not_ to use mod_rewrite - e.g., if a RedirectMatch will do the trick, use that instead.
> Rails effectively requires one image per concurrent client.
Hm, well, one concurrent HTTP client, yes. But if a Rails process can serve up 30-40 requests a second and a human using a web browser is only doing a request every 2-3 seconds, and you've got a cluster of 10 Rails processes... it seems to work out ok.
> As to scalability, I don't know of any particular problems with Ruby there.
Yup. It's strange - folks will post comments like "Ruby can't scale for a huge enterprise app!". The odd thing there is that for a huge enterprise app the opcode execution speed is probably not going to be the primary bottleneck. In fact, almost anything that reaches over a socket into a database is going to have bottlenecks that have nothing to do with how fast the Ruby interpreter can navigate an AST or set up a stack frame.
...if you're doing Rails apps is Advanced Rails by Brad Ediger. It's got a ton of helpful hints on all sorts of things - sessions, memcached, how Rails uses Ruby's dynamic features, how plugins work, how to do complex associations, details on REST, etc etc.
The nice thing is that he doesn't fool around with explaining the simple stuff that you know already if you've done even one Rails app; he gets right down to business. Of course there are always interesting gotchas, but this is a book every Rails developer should have.
> I nearly locked myself out while trying to set up a svn+ssh client
Yeah, that's a bad feeling. But the good thing is that you can usually ssh in from some other subnet. Unless you've already set up AllowHosts or something, in which case, yeah, a drive to the colo is in your near future:-)
> I used to get a lot of traffic from SSH brute force attacks
Yup. One of the first bits I install on a new server is DenyHosts; "service denyhosts start" and an hour later there are a half dozen IPs in/etc/hosts.deny. Good times.
The reviewer suggests encrypting the password. Well, storing a hashed version of the password is at least a step in the right direction. Storing a salted hash is better, though. Encrypting that salted hash would be another level of security, although I don't think it'd buy you much more than salting it.
> are there good reasons for sticking with CVS or SVN > or is GIT now The One True Way?
Seems like the other distributed SCMs have their fans too; I've gotten requests on RubyForge for Mercurial, monotone, darcs, etc. There's a request in for git, too. Just need to take some time and set that stuff up and see which ones folks start using, I guess.
There's some other good stuff there too, although the interview with Dr. Stonebreaker about column-oriented storage is kind of light on technical detail.
"You seem to not have noticed that mapreduce is not a DBMS."
Exactly. These are the same sort of criticisms that you hear around memcached - the feature set is smaller, etc - and they make the same mistake. It's not a DBMS, and it's not supposed to be. But it does what it does quite well nonetheless!
Looks like there's a SPARQL grammar from which JavaCC can generate a parser (and, since it's a JJTree grammar, an abstract syntax tree). Nice to have that piece of work available and BSD licensed....
> Has it really? I don't think that Java has survived the > lack of mod_java. There are very few webhosts that > offer Java. And when they do, it's usually quite more cumbersome to use than PHP
Hm, yup, very true, Java's not a really player in the shared hosting space. I guess I meant that there still seem to be plenty of web apps written in Java... just not in the DreamHost-type environment.
Slashdot Mirror
$ wget -S http://www.idsoftware.com/
--08:57:08-- http://www.idsoftware.com/
=> `index.html'
Resolving www.idsoftware.com... 192.246.40.185
Connecting to www.idsoftware.com|192.246.40.185|:80... connected.
HTTP request sent, awaiting response...
HTTP/1.1 503 Service Unavailable
Content-Type: text/html
Date: Thu, 08 May 2008 12:57:20 GMT
Connection: close
Content-Length: 28
08:57:08 ERROR 503: Service Unavailable.
I recently gave my DOOM 3 box to a friend who bought a new laptop... after several years the game should be playable now on a medium-powered laptop. That's the way to do it - buy the "3.years.ago" game of the year and play it with all the dials turned up.
Yup, and for some more numbers and some good commentary on this, check out this post from EU Referendum: 'A world gone mad'.
> Defining large in terms of the size of the code base is not appropriate
Hm, at least, KLOC is a contributing factor. Maybe cyclomatic complexity would be a better measurement?
> I'd imagine "large" is being used here to mean an
> ability to tolerate enterprise load level.
Yup, but an enterprise load level usually means a server farm with a web/app/db breakdown and some caching servers. At that level, the Ruby interpreter and the framework method calls usually aren't the bottleneck - there's s DB to be tuned, stuff that should go in memcached, page and fragment level caching, and so forth; that makes the difference.
> the framework encourages development without much concern for database speed
Very true. But you know what they say about premature optimization... and you can always load a bazillion records into a test db and find the bottlenecks. I just sorted out one of those for a customer a few weeks ago; PostgreSQL's EXPLAIN ANALYZE to the rescue...
> Production architecture, webserver integration, and
> deployment were all huge pains two years ago.
Yup. Judicious Capistrano + mongrel_cluster + monit usage make a difference these days, but it would still be nice to have fewer moving parts. Maybe Rubinious will get us there.
Incidentally, "cap deploy:check" totally rocks.
> Horror stories, these are the only stories I have heard from anyone
> trying anything close to what I would consider 'large' projects.
I've found that Ruby has a way of making large projects into small ones. Going from 250 KLOC in Java to 10 KLOC in Ruby would not surprise me.
> RoR is not the right tool for many significant sized project, especially in the enterprise environment.
Most enterprise environments are a morass of battling departments, entrenched legacy technologies, and outdated, inefficient processes. While that significant-sized 30 person project is bogged down for two months negotiating more app server licenses, the 3 person Rails team can knock out a fully tested application that does the job.
> I don't know if I'd go so far
> as to label it required reading
I've been doing Rails for about two years and still found this book to be very helpful. It should be called "Rails For Real Projects" or something, because he covers stuff you _will_ run into. The nice thing about this book is that he doesn't waste time explaining what 'puts' does and such; he gets right down to business. The section on modifications that Rails makes to the Ruby standard library is worth the price alone.
> comparing it to intelligence there, surely you are setting the bar rather low?
Time for an "Office" quote:
> or maybe you could actually learn what 'postfix' is.
You're right, I misunderstood the post. I thought the question was "what's the successor to Apache that will do for Sendmail what Postfix did - e.g., make it obsolete?"
...which for me is one of the trickier bits of Apache, get Rich Bowen's excellent mod_rewrite book. It's helped me figure out a bunch of complicated stuff and even has a great chapter on when _not_ to use mod_rewrite - e.g., if a RedirectMatch will do the trick, use that instead.
> What's tomorrow's postfix?
Maybe nginx? highscalability.com has an article about a popular Rails Facebook app that replaced a hardware load balancer with a dedicated nginx box. 10M hits a day, not bad.
> Rails effectively requires one image per concurrent client.
Hm, well, one concurrent HTTP client, yes. But if a Rails process can serve up 30-40 requests a second and a human using a web browser is only doing a request every 2-3 seconds, and you've got a cluster of 10 Rails processes... it seems to work out ok.
> As to scalability, I don't know of any particular problems with Ruby there.
Yup. It's strange - folks will post comments like "Ruby can't scale for a huge enterprise app!". The odd thing there is that for a huge enterprise app the opcode execution speed is probably not going to be the primary bottleneck. In fact, almost anything that reaches over a socket into a database is going to have bottlenecks that have nothing to do with how fast the Ruby interpreter can navigate an AST or set up a stack frame.
...if you're doing Rails apps is Advanced Rails by Brad Ediger. It's got a ton of helpful hints on all sorts of things - sessions, memcached, how Rails uses Ruby's dynamic features, how plugins work, how to do complex associations, details on REST, etc etc.
The nice thing is that he doesn't fool around with explaining the simple stuff that you know already if you've done even one Rails app; he gets right down to business. Of course there are always interesting gotchas, but this is a book every Rails developer should have.
> A load balanced network of highly available virtual servers running on my laptop.
Nice! I'm working on Capistrano deployment stuff and so my Macbook is running a couple of FC8 VMs. It's not happy about it either...
> I nearly locked myself out while trying to set up a svn+ssh client
:-)
Yeah, that's a bad feeling. But the good thing is that you can usually ssh in from some other subnet. Unless you've already set up AllowHosts or something, in which case, yeah, a drive to the colo is in your near future
> I used to get a lot of traffic from SSH brute force attacks
/etc/hosts.deny. Good times.
Yup. One of the first bits I install on a new server is DenyHosts; "service denyhosts start" and an hour later there are a half dozen IPs in
And then ROT-13 it!
The reviewer suggests encrypting the password. Well, storing a hashed version of the password is at least a step in the right direction. Storing a salted hash is better, though. Encrypting that salted hash would be another level of security, although I don't think it'd buy you much more than salting it.
> are there good reasons for sticking with CVS or SVN
> or is GIT now The One True Way?
Seems like the other distributed SCMs have their fans too; I've gotten requests on RubyForge for Mercurial, monotone, darcs, etc. There's a request in for git, too. Just need to take some time and set that stuff up and see which ones folks start using, I guess.
...getting interviewed about Groovy here.
There's some other good stuff there too, although the interview with Dr. Stonebreaker about column-oriented storage is kind of light on technical detail.
...entry says;
"You seem to not have noticed that mapreduce is not a DBMS."
Exactly. These are the same sort of criticisms that you hear around memcached - the feature set is smaller, etc - and they make the same mistake. It's not a DBMS, and it's not supposed to be. But it does what it does quite well nonetheless!
Looks like there's a SPARQL grammar from which JavaCC can generate a parser (and, since it's a JJTree grammar, an abstract syntax tree). Nice to have that piece of work available and BSD licensed....
> Has it really? I don't think that Java has survived the
> lack of mod_java. There are very few webhosts that
> offer Java. And when they do, it's usually quite more cumbersome to use than PHP
Hm, yup, very true, Java's not a really player in the shared hosting space. I guess I meant that there still seem to be plenty of web apps written in Java... just not in the DreamHost-type environment.
> Obviously since you are creating a class representation
> of the database, how much gets altered will certainly muck things up.
Definitely, yup, when you change the data you'll need to adjust the code as well.