carpal

The amputee wasn't barred from the olympics. This particular set of prosthetics was banned.

That guy can still run in the olympics with any other set of prosthetic legs but this one. It was just deemed that these gave him too much of an unfair advantage.

I don't think it is too hard to do both. Last night I got home from a night out with friends at about 2:30 AM. I then wrote a blog post, wrote a little code, compiled and fooled around with GIT before going to sleep at 5:00 AM.

Having a social life is pretty much the best counterbalance to a career in software development. If you don't have one, you're doing it wrong.

#FFFFFF all the way

Not bad for a first shot. One suggestion is to use the "fat model, skinny controller" way of thinking. It'll help clean up your code significantly.

http://weblog.jamisbuck.org/2006/10/18/skinny-controller-fat...

I've pastied an example of how this approach should help.

http://rafb.net/p/P4YMM359.html (Pastie.caboo.se is down now for some reason, so this is good enough for now)

Generally, the only major issue I see throughout is the repeated Fueling.find(:all) calls. Not only will that hit up the database quite a bit (Rails 2.0's query caching would help a little, but that's beside the point), but it would take up a crazy amount of memory once you get a lot of fuelings in the system.

Keep at it!

I'm using Slicehost, and it's been a really great experience. I've been with them for about a year, and haven't had any downtime that I've noticed. Current uptime is 82 days, and that was when I changed over from Ubuntu to Debian.

I've also tried a Joyent accelerator, and wasn't very happy with it.

A friend of mine and I had an idea for this in 2001, and even made it into an incubator. But everything folded shortly thereafter due to the bubble bursting. The company probably deserved to die.

The main market is traveling salesmen and businessmen who are away from home for extended periods of time. If you're in China 3 weeks every quarter, for instance, a service like this is immensely valuable. But it became obvious to us that it was a niche product, and while cool, wouldn't really fly. And it is definitely not worth a $13.3 million investment.

> If you hadn't heard of the technology after reading thousands of startup ideas, then what chance do we have?

You're fundamentally mistaken. The technology is 1%. Execution is 99%. You need to stop being so obsessed over technology and focus on the execution of the technology. Build great stuff on top of Comet and it won't matter what mindshare it has or whether PG has heard of it or not.

What she's saying is that a bad idea with bad execution will end badly. That isn't exactly revolutionary. If people panic and the Web 2.0 bubble "pops" because bad businesses die, then some people seriously need their head examined.

The end point is that businesses, whether Web 1.0, Web 2.0, or what have you, need both a good idea and to have it be executed well. Trying to believe that the business is immune to those laws just because it is executed over the Internet is asinine. The people who found these companies and the people who invest in them will get burned.

And they should. And it will be good for the industry.

No, and the author never said it was.

I really like the approach of having X number of processes started automatically. You can get really fine-grained in your scaling strategy, and can balance multiple projects on the same server much better than you could with Apache.

If you really want the "automatic blah blah blah" approach, you can always use fcgi with Apache. Many people do (including 37signals).

Nginx is both incredibly fast at serving static files and pretty useful all around for reverse proxies and whatnot (not to mention being easier to configure/maintain than apache). I use it at work and it has been fantastic.

Yes, that's exactly my point. Is this the first approach that does this within the Django framework?

That is exactly how page caching in Rails works, and has been implemented for two years. It seems like Django's idea of "page caching" is equivalent to Rails' "action caching".

Is this seriously the first implementation of this in Django?

I seriously hate gloating, but Rails' page caching has been around for two years. I must be mistaken.

edit: After browsing the Django documentation, it appears that I'm right. While you can store the output of a view in the filesystem (or memcached, or whatever), cached hits still need to go through the framework to get dispatched. This appears to be the first way to skip the framework (aside from Squid or similar), which is what Rails' page caching does.

Page caching creates the cached page on the first request, and dishes out the cached output until it is swept (after a new create/update/delete). This seems like the "no duh" approach. The Django "standard" way of setting a timed expiration seems silly and inflexible.

This is a really tough problem. I worked on something like this extensively in 2005. Ultimately, the hardest part was syntax highlighting on the current line, because you had to monitor input to figure out when a "token" had been completed, and then do the corresponding magic. Dealing with the idiosyncrasies of changing colors and maintaining cursor position makes this a real bitch.

Turning off syntax coloring on the active line definitely makes the problem easier. Wish I would have thought of that. Strange how you can spend days on a problem but never think of the "easy" solution.

Generally I'd be upset at an article like this being on news.yc, but this was a really great speech that didn't focus too much on politics. It had much more to do with hope, success and fighting for what you believe in. That's a pretty universal message, and one that could easily be applied to startup life.

I kind of figured you could look outside for that. Temperature is a little harder to gauge.

I was a T-Mobile customer for 2 years, and was never treated that nicely. It seemed like every time I called, I was being pressured into signing another contract. Their systems were also always very slow, so while the rep was waiting for their service interface to load, they'd engage me in a lot of awkward small talk. I haven't been a customer for about a year, so maybe they've changed since then.

Zed was right about the http://example.com/posts/1;edit thing. It stunk the first time I saw it. I think that DHH admitted it was a bad idea in his RailsConf keynote, but I'm not sure if I remember correctly.

But the point is that just because it was a bad idea, doesn't mean Koz is categorically a bad developer, or that he's any of the things that Zed called him. I heard him talk at RailsConf, and I have to admit that he sounded kind of like an egotist, but didn't actually know how to code all that well. But do I call him a fat fucker? No. That's taking it a little too far.

Try it now. It should be much more iPhone-palatable.

There's one thing that just doesn't seem right about this rant, which I think will make his whole argument fall to pieces.

Before he wrote mongrel, it seemed like he had a pretty decent working situation. After he wrote mongrel, he was jobless and nearly homeless for an extended period if time.

That just doesn't sit right with me as being truthful. How can a person, who is otherwise a qualified developer, write one of the most well-known pieces of the Rails infrastructure, but suddenly be jobless? I wrote a shitty weather app and got 3 gig offers within a day. How can you be a household name within the Rails community and not have a job?

By being an arrogant asshole? By demanding outrageous fees? By demanding outrageous control over projects? All three?

Yes, Paul.

(This is Erik Peterson. We met at ATL Startup Weekend. Damned Internet handles. Using your name is a good idea, huh?)

That's a pretty interesting article, but I found it nearly impossible to read. Every paragraph there's a link on an (apparently random) phrase. When there's a link to something like '"real" job', I expect a link to his former company, or a blog post describing is old job. What I don't expect is an ad. Boo.

Weird. It comes straight from the National Weather Service, so it must be something strange with their data. Some sanity checking would be advisable, though.

I'm getting my forecast data from http://www.weather.gov/xml/#nonSOAP (You can read about that in my site's about (http://forecaster.ws/about.html) page). The current observations are a little more complex- you have to find the closest observation station to that zip code and look it up by the four-digit station code. Then you can look it up like: http://www.weather.gov/data/current_obs/KFTY.xml

I find the vertical forecast easier to digest. I'll experiment with horizontal layouts.

Doing geolocation would be sweet. I'll try it out.

Are those valid zip codes? Neither 77915 or 12345 are in my database of zip codes.

I have a table that has the lat/long of zip codes so that I can find the closest observation station.

Edit: If I can't find the zip, I'll default to that state's center. So even invalid zip codes like 12345 will "work"- in this case, it'll go to around Schenectady.

A little project I did over the holidays. I got sick of how slow and cluttered weather.com was, so I whipped up this little service. I hope other people can find it useful.

It took me about a day. It is written in Rails. It contains about 100 lines of application code.

Drupal kind of forces the 3-column layout on you. It's not really very easy to extend (from what I've experienced). I've just never seen anyone have a good Drupal experience.

I'm doing the exact opposite. I've got 2 weeks off of work, and I've pledged to do no work at all in that time period. I've been burning the midnight oil working on my web app nights and weekends while working at my day job full time. I need some time to really relax and recoup.

So instead I'm reading, walking ~10 miles a day and generally doing things that I've neglected for the past 2 years.

1) I highly suggest NOT changing the deploy.rb file in the Cap gem. You can override any task in your own deploy.rb file. For instance:

namespace :deploy do

  desc "Custom stop task"

  task :stop, :roles => :web do

    #My custom "stop" command

  end

end

(as a side note, does anyone know how to do code formatting on here?)

2) I think from what you're saying- it is deploying correctly, but you're confused as to why it is asking for your password three times? This is common, and I think it is a bug with Subversion. I deploy using svn+ssh as well and get the same thing. If I remember correctly, you only have to enter in your password correctly for the first one, and can just hit enter through the other 2. Alternatively, you can make sure you have your SSH keys set up correctly.