swindsor

I DON'T KNOW WHAT HTML5 IS, BUT SIGN ME UP FOR SOME. I'LL TAKE 13!!! BUY NOW!!! CAN WE INVEST? IS IT PATENTABLE??? DO IT NOWWWWW.

Also coming in Firefox 7: The number 7.

The problem with C isn't C. It's shitty C programmers.

Learn how the language works, follow good patterns, and expect some bumps in the road.

Most of the time, though, you can use a different higher level language, and be a happier and less stressed programmer

We've stop/started continus integration a few times with a few different CI servers with mixed success. What did you guys end up using?

Right now, we have tests, but I'd still say we rely pretty heavily on hoptoad to let us know if we really broke something badly. ;)

Then 'curl get.pow.cx > pow.sh'. Take you time and look at the script, then run it. Worked for me.

Sad! I worked for Obopay and on Billmonk with Chuck and Gaurav a few years ago. I hope to see the site back up and explanation on what happened.

We wanted to be able to serve arbitrary sizes so we can handle different demands for thumbnails and new use cases. Having to resize all of your images because you've re-designed your homepage sucks, and is no fun (especially if you have a large set of images).

Cloudfront is really enticing, though. For a cheap CDN, if we really had the need, we'd probably migrate to cloudfront, then come up with a task to batch resize our S3 images, then stick them back into S3. This could probably be done on a one-off task on ec2 by spinning up a few instances, or even with Hadoop.

If anyone's taken this approach, I'd love to see it!

Oh, that's cool - I didn't know you could use matches from a location in an alias. Is that a new feature in nginx?

I could see where that would be useful. Image uploads in our case are actually handled by our existing web app, so our image servers can be ignorant of user authentication/etc. We end up using swfupload, which is a nice client experience, and then in the callback we call directly into our image servers. Since it's an ajax experience, it's pretty nice, but if we had very large images, or if we had to pre-process out a number of different sizes/etc I could see where kicking off an async job would be useful.

It would be really cool to have an EC2 instance handle these resizes and put the images in new buckets for you - Might be a really neat implementation.

1. Good point - I didn't bring this up in the article. When we store the images locally, we create divide end of the unique ID of the image into two levels of subdirectories. This gives us "random enough" distribution in subdirectories, and an easy way to look up the files on disk. This logic exists in our rails app, but we didn't want to expose this pathing out to end users. This allows us to change it later if we need to create further subdirectories.

2. Good tip - we try to use our judgement here balancing good design/good performance. We tend to opt for a pretty website first, then go back and make it faster with optimization.

http://aws.amazon.com/s3/#protecting I am totally okay with 99.999999999% durability. This is way better than I'll be able to build/afford on my own.

In case of an epic S3 disaster, we could backup our S3 buckets to another offsite storage, but we're not going to improve much further than what their giving us.

Dragonfly looks pretty cool. I like the approach of using rack (our app was written pre-rack, but it's been upgraded to newer versions of rails, so we could make it rack-enabled).

Have people written different datastores (like S3?). I love the idea of a modular, pluggable image server that can choose different backends based on business need/scaling.

Luckily, we deal with pretty small pictures since they are just pictures of our users & their classes. We don't really have any need for handling larger sizes, and our biggest use cases surround generating thumbnails (similar to many social networking web apps).

True, there is guarantee. But it's a pretty good track record - and the underline technology holds up pretty well. It's more reliable than what we'd be able to build with a small startup budget (or pay for offsite backups/storage).

That I really agree with. It's a great group collaboration tool, and a much better replacement that email.

But for task management, it still isn't better than a shared Google Spreadsheet, which is weird to me.

I think my issue is that I totally agree that fine-grained project management is evil, meetings suck, I read the books, listen to podcasts, drink the kool-aid, etc.

But, Basecamp is a project management tool. It allows you to track tasks (and due-dates), and milestones. I don't care about task dependancies, or gannt charts.

I do care about agile development. I do need to see the status of my project in an aggregate way (are we close yet?) Even understanding that estimates are wild guesses, task-level timeboxing is better than working backwards from dates. I can't image the due-date feature working well except for in some very narrow circumstances.

I guess overall if my definition is "project management" is different, then wouldn't they want their product to work to handle users like me? Or not, and that's okay. I'm just saying that I'm cut out of the niche of users they are looking for, whether it be intentional or not.

I think I'm okay if Basecamp doesn't want me. Really, it's a product, and if it doesn't fit my needs, I'll move on. But I'm sure I'm not the only one. But really, it's up to 37Signals to listen to the feedback or keep the product as is. Keeping it as is will keep their market share low, and ultimately make them less money. But I might be missing the point.

No, but I think they focused on solving their own problems (and building the perfect product for them). As they've made Basecamp on of their public products, though, there are product changes they could make so that it fits everyones use cases. Or they can keep it the way it is, and only companies that work exactly like them can benefit.

I'm not even saying they should change them, but for me, there are a few feature changes that would make it way easier for me to use (and therefore a rapid fan and repeat customer).

I agree - I don't think I want Basecamp. But I don't need Zoho either. My point was that Basecamp is missing a few (very small) features that would take it from "Ok" to "Awesome". Even though this may be against much of the 37 signals philosophy of keeping things simple and lean.

I thought Basecamp is also designed to solve the distributed project management problem in a simple, easy way. I like the appoach, but the Deadline/Time tracking doesn't work for me in it's current implementation.