herewego

You're wrong. I live in Boston. The MBTA was shut down, but businesses were allowed to open (my employer was), and people weren't getting "swarmed" by any means.

Their implementation was lacking, but the concept was sound. Someone could get this right, particularly if it was marketed as a learning tool.

I strongly disagree with this. Much of the world's code is not on GitHub or StackOverflow. This is a much underserved market in my opinion.

Not in this book, but worth taking a look at if you're into reading source code for large open source projects, is Redis and Mongrel2. Both are really well written C code-bases.

I'm curious what you issues you ran into as well. I've used it in production environments for the past few years after moving away form Apache. It was a near seamless transition for my team, myself included. We use it behind some heavy iron load balancers and in front of a dozen web servers and it's been a generally pleasant experience.

I would use this for PHP development.

I really like the idea of having an editor that I can play with on all of the things that I don't want to, or can't, setup an editor on (iPad, various laptops, etc). Is it possible to have a non-hosted version that I could put on my own servers as well, that I can then access from anywhere I wanted?

The aesthetic quality is superb by the way. Who does your UX?

I can attest to their support being phenomenal. I found a critical bug last week and got a patch within hours of reporting it to their customer advocate. You don't see that kind of turnaround very often.

Agreed. This title is quite obviously biased. I don't see a reason not to use the linked content's title as the title for submission.

I partially look at hybrids and electric cars as a hedge against the possibility of Peak Oil making a significant difference in oil prices at some point in the next few years.

Might happen, might not. Regardless, I get to drive a fun new toy -- I find the experience of driving a hybrid to be fun (the sound, instant torque, etc).

Fear not, everyone fails before they succeed.

Google Analytics, Quantcast, and Chartbeat are a good start.

Google Analytics gives you the ability to slice and dice your visitors. Quantcast gives you demographics. And Chartbeat gives you real-time tracking with historical playback.

Between the three of them, you can discern almost any information you'd want to know about your visitors short of business logic tracking.

Interesting. I should have been more explicit - my figures are for the U.S. only.

Ruby in particular is hot right now and they're fetching higher salaries relative to other OS languages, you're correct about that. I clumped them all together in my query, and PHP (and Java to a lesser extent) pulled the average down.

Also, notice that I didn't specify junior developers on the salary scale - they're all over the place in terms of salary.

Government contract work is always the exception in any industry. I think that's a given.

I work for a mid-size (read: 100+ employee) IT recruiting company and I have to tell you that this boils down to one thing and one thing only for most people that have chosen .NET: economics.

If you want to be a developer and you're goal is to give your three kids a good life, drive that BMW 5 series, and own a $500k house, then you should be a .NET developer. The math is simple and I have a mountain of data that supports the reality that .NET developers get paid significantly more (20-30%) on average than any of the hot whiz-bang alternatives (Ruby, PHP, Java, etc). The average mid-level .NET developer in a dev-friendly town (san fran, boston, new york, etc) is making $80-90k, Senior $90-110k, Architects $110-130k, Director/Managers $130-160k. Those are averages that don't include bonuses. There are of course exceptions (finance industry add 20% to the above figures, start-ups subtract 10%, etc).

Never underestimate the position that money holds in ones relationship with their chosen path in life.

I think the authors argument is valid and is the reason why most of the developers that leave the .NET world do, but my observations indicate that most .NET/MS developers are lifers.

On a side note, I actively practice development in.NET, PHP, Java, and a few other languages at my 9 to 5. I like to think that I'm fairly unbiased.

This has been tried before using Javascript - there is no new thinking here. That aside, the problem as I see it, is that the following issues have yet to be solved:

1. You can't currently limit CPU cycles in Javascript reliably

2. You can't automatedly prevent malicious Javascript code from being uploaded and distributed while still allowing people to use the Javascript keywords and constructs that are required for most useful algorithms

3. Any data that is in a format to be processed is not secure because one can view the code and the data, thereby deducing its purpose with minimal difficulty

Fair enough. I got about 1500 words into it and said to myself, this is a book I'm trying to fit into a post. Such is the reality of complex topics like these.

I agree with most of the points you're making, but I also think that its important to remember that most people have no idea about what's even involved in the basics. Your points are advanced and are details that are VERY important, but are beyond the scope of a post. If the criteria for trying to put into words some of the concepts behind scalability were that you need to be writing a dissertation to do so, then we would live in a sadly uninformed world.

My intent wasn't to make it a thorough primer so much as to touch on some of the concepts involved in making scalability a reality in day-to-day development of web applications: scalable datastorage, scalable application layers, etc. I hope the readers see it for what it is and then go do further research of their own.

True that!

Honestly, its embarrassing that I didn't remember RavenDB before writing up this post... my bad.

As far as production websites go, you are completely wrong.

I disagree. You are talking about the relational model conceptually. The author is talking about the relational model as it is implemented in today's RDBMS solutions.

You elude to this in the last paragraph of your comment. Having a horrible experience horizontally scaling, for example, is ample reason enough to look into document databases. Largely because the current implementations of document databases allow for ease of partitioning in a way that the current implementations of RDBMS' don't.

The author doesn't imply that document datastores are free lunches. They're simply alternatives and he goes on to say that document datastores are better for some problem domains than others.

Also, you oversimplify the difficulties in implementing a highly-performant document datastore by implying that data should be normalized and that storing the data on disk is an optimization layer. This comment comes off as being written by someone who is ignorant of how document disk storage is implemented and why it is so fast. Doing what you suggest would very likely result in a datastore that was drastically slower than the currently implemented document datastores or even key/value datastores for that matter (MongoDB, CouchDB, Cassandra, etc).

Will we someday perhaps have the end-all-be-all of RDBMS's that merges the feature-set of current RDBMS's and the performance of document/key-value datastores? Maybe, but until then, they're alternatives to each other that generally succeed in providing solutions for the problems for which they were designed:

* RDBMS - consistency, transactions, predictable schema, etc. * Document/Key-Value - horizontal scalability, raw performance, flexible schema, etc.

Different solutions for different problem domains.

Not all services scale perfectly linearly. They are likely limited by certain costs associated with using an Amazon infrastructure or their own infrastructure, or it is simply a matter of customer hot spotting trends and perceived demand.

From someone who lives and develops in the real world, your prices, current offerings, and future offerings are right on the mark.

Simply GeoDjango you are not. Nice job.

The quick and dirt: your mileage may vary.

It's probably worth mentioning that the reality is that not every developer is of equal ability, nor has the same level of potential ability.

I've met many developers that clearly don't have the same capacity for learning and applying languages to problems as well as others. Do what works for you based on your own perceived capabilities.

This is seriously creepy.

An iPhone interface and/or a generic smart phone interface (Android, WinMo, etc). Forget the lower end phones that don't support CSS, they aren't going to be in your demographic anyway.

A lot of times you can get away with a decent smart phone interface and just put a few meta tags in the head tag for the iPhone so that it looks slick for the iPhone too.

Adding mobile capabilities would be a game changer for me. I'd sign-up for a year and pay you for it if you built a mobile interface and/or sms interface. I'd be willing to pay $10/month if this made scheduling my life as easy as it looks like it could and it included all the free SMS I wanted to send for use in scheduling tasks via mobile.

This is the most intuitive scheduling app I've ever used. The way that you just hover over everything and get to see what different features do without committing to anything allows me to explore your app without much fuss.

Feature requests:

1.) When I add a task, sometimes I'd like to add a really detailed description (or any description for that matter) (i.e. a project spec) and I'd like the ability to do that. The ability to bold, italicize, change font size and format, etc, would be helpful in descriptions.

2.) Attachments. I want to be able to attach files to my tasks.

3.) Keep the above features out of the way. Most of the time I won't need them, but when I do, I really need them.

EDIT: 4.) Just realized that the projects aren't hierarchical. I expected them to be, and it doesn't allow me to be super organized for more complex projects/tasks. An example of this might be Work>Websites>ClientA and another might be Life>Exercise or Life>Clean-Up.

If I think of more, I'll let you know. Nice job so far.

Hi, I'm the author of the post.

My intent in using Memcache as the mechanism for this type of indexing was more an attempt to relate the subject with something that most developers are at least somewhat familiar with. I explicitly address the weaknesses of Memcache in the section titled "Weaknesses". I also recommend some work-arounds to lessen the effect of Memcache's limitations. In the "Wrap-Up" section, I even go so far as to say that Memcache is really only one example of a distributed hash-table and that there are alternatives. Rolling your own is another option, and both of solutions are probably better suited to the indexing problem than Memcache.

Again, I was afraid that the subject would be lost on most people if there wasn't at least some relation made between the concept and something that concretely exists. Try to look at it as an exercise in thinking "outside the box", using the best example I could think of.

Thanks for the comments, good and bad. These critiques really do help.

The data access code was intended to display as simply as possible how the Model should be architected in regards to encapsulation. Switching out the data access code itself with something more robust, while still maintaining the overall Model architecture is in fact encouraged. I should have made that more clear, thanks for the feedback.

Kick some ass! Congrats on your self-promotion Mr. Founder :)