You have to take into consideration developer time, because often you are paying more for your staff than for your servers. Python and Ruby applications are known (unsourced) to have faster, more rapid development cycles than PHP applications. The ecosystems there tend to be friendlier for people looking to plug and extend existing libraries to put together a minimum viable product quickly.
My issue with CouchDB is the basic approach. Instead of maintaining indexes, the goal of CoachDB is to pre-cache all search functions with the actual result, for all records. This takes a lot of disk space for certain use-cases. This difference makes MongoDB a more attractive choice than CouchDB.
I think the key to recovering from over-commitment is to increase your rates. If you are over-committed, you are giving away your time for too little money.
The article is about someone who works a steady non-contract job who signs up for personal side projects and research stuff at work, I'm not sure how you think "increasing your rates" applies in the situation.
(FWIW, if you're a contractor who has more work than they can complete, I absolutely agree with your analysis)
We are using Softlayer and we found that on our server we were not bottlenecked by memory, CPU or disk I/O. However, we were bottlenecked by our bandwidth which sat around 5 MB/s. Perhaps we could upgrade to a higher-throughput network card or something (I don't maintain our servers), but we ended up just offloading static files to a CDN instead.
I'm having a hard time nailing down what the killer features are here. For example, I saw that they advertise drag-and-drop with support for touch devices, but I couldn't even find the drag and drop demo on the site.
Thanks. I'll be checking this out, although I was hoping they would also have something equivalent to jQuery's Sortable (http://jqueryui.com/demos/sortable/).
I do a lot of near-pixel-for-pixel reproduction from Photoshop documents, and I find that using rule nesting, mixins and child selectors (a similar style to the final example from the article, the first example is atrocious) definitely helps me build more semantic HTML.
Here is a quick cut-and-paste from a LESS stylesheet:
There are a lot of random items and I find it easier not to cascade styles as much as some recommend. I try to consolidate styles into generic classes or mixins as I find opportunities to re-use them. I try not to use the child selector unnecessarily (the article uses it a totally unnecessary amount) because I often need to add unsemantic wrapper elements to achieve the right effect.
The examples in the article are simplifications for the purpose of illustrating the points. We'd almost never use nesting to any element all the way back to the HTML or BODY laments. But when you have elements like SECTION, ARTICLE, LI, DIV, etc which can be nested infinitely in HTML judicious use of the child selector is a godsend.
The examples in your gist would not benefit from additional use of child selectors, but I'll bet they'd appreciate it if the parent elements did :)
I wonder how hard it is to open source a Google product. I imagine that Google's products are heavily tied in to its proprietary solutions like BigTable.
