integraton

Outside of the Bay Area remote work is more acceptable for startups and small companies, and most of the advocates for remote teams are in cities like Chicago and New York.

Even if every staff member believes they checked the "Scrub Data" checkbox or used the API flag when destroying droplets, human memory is unreliable and people make mistakes.

This is a very serious security issue and it's appalling that anyone is making excuses for it, and it's even more appalling that the company responds by blaming customers.

Customers should not be able to access other customers' data under any circumstances. It shouldn't even need to be stated that providing access to other customers' data should not be the default.

I care. Semantic HTML is easier to work with when creating, maintaining, interacting with, or consuming HTML.

> why does every single Sass/Less framework suggest first in the documentation that you should write your HTML like this?

Most major Sass grid frameworks encourage semantic HTML and always have. See, for example, Chris Eppstein stating the rationale behind blueprint-sass in 2008:

"The biggest advantage of using the "sassified" version of blueprint is that you can use semantic class names again and stop putting "display classes" in your markup." - https://groups.google.com/d/msg/blueprintcss/Yyx9PpZpCRA/wq1...

Both Susy (http://susy.oddbird.net/) and Bourbon Neat (http://neat.bourbon.io/) follow in this tradition.

The Foundation and Bootstrap documentation is targeted at people using the generated CSS, which is why they use non-semantic class names. I'm not familiar with Gumby, but there is no good reason for them to encourage non-semantic class names when using SCSS, although presumably they are assuming their main users are similar to the CSS-only users of Bootstrap and Foundation.

Furthermore, high turnover is very, very common in VC startups, including CEOs.

Concise, semantic markup results in:

    * less complexity
    * easier maintenance
    * greater portability

What happens when 3 years from now someone inherits your mess of HTML with presentational styles for a framework that's years old and no longer relevant? In addition to updating the styles, they also have the pleasure of spending hours or longer stripping out your outdated, framework-specific presentational classes and ids.

What happens when you HTML needs to be consumed in an unknown, unpredictable context? Content organizations are still dealing with the fallout of having inflexible HTML and CSS that can't easily be adapted for mobile.

The only thing that seems to be missing is pl/v8 support. In case anyone from amazon is reading this, I've noticed that the functions floating around on github for the new json data type are using pl/v8, and I suspect this will only become more common.

GIN indexes are big, but Mongo's indexes are bigger than all other PostgreSQL indexes, and Mongo also requires much more space for the data.

Rails, for example, despite always having been "slow," performs far more than adequately for the vast majority of web applications, scaling patterns are well established, and it's obviously hugely productive for many, many developers and companies.

Honestly, now with all the great Scala frameworks, Clojure, and the ability to run Rails, plus Cassandra, Storm, etc, I'm a little creeped out that I'm actually strongly considering building my current new project completely on the JVM.

    > [1,2,"10",3].sort()
    [ 1, '10', 2, 3 ]

More importantly, it's very standard practice to do asynchronous jobs and notify users on completion, as seen in the data export or input features on many web services. Whether users get results immediately or need to be notified is a UX issue, and a requirement that the entire system be designed to deliver results immediately sounds exactly like the kind of speculative, unconventional UX requirement that non-UX people come up with around a conference table.

Large parts of the technology world operate according to the latter model, and they do so for a variety of very valid reasons. Obviously, the government and government contractors do not.

jroseattle's comment presents a speculative model for how to apply a distributed, fault-tolerant model to this kind of technology project.

It's also pretty common for companies to sink money into developing native apps for either platform only to find that they get few users and ultimately generate little to no revenue. It totally varies depending on the nature of the product or service, but I've rarely encountered situations where market share was a primary indicator of what platforms a product or service needed to support.

And since this is supposed to aid in rapid prototyping, how does it do so? It seems to me that it does just the opposite by introducing a significant and totally unnecessary burden.

PostgreSQL:

    ALTER TABLE posts RENAME COLUMN author TO writer;

    db.posts.update({}, {$rename:{"author":"writer"}}, false, true);

Which is why it doesn't make any sense to claim that using MongoDB somehow eliminates needing to migrate your data as it evolves.

What's your magic non-db level, supposedly-easier-than-updating-a-schema approach to renaming a field common to all existing documents in a collection, eg, rename an "author" field to "writer"?

Regardless of whether you are dealing with a strict schema or flexible schema, you still have to make changes to how you structure your data as you are prototyping or otherwise iterating on it. MongoDB provides no tangible benefit in this case. If you want to rename a field, then you still need to run an update.

How are ad hoc, manual, historically opaque tweaks to data in any way better than an easily generated and version controlled series of scripts representing a replayable history of changes to the data?

If anything, manual untracked tweaks make "rapid prototyping" more difficult since lots of partially or completely undocumented changes to the structure of the data are harder to revert, replay, reason about, or share with others. It's also more work to do it manually since you need to run the commands in multiple environments, rather than just entering the same command or, more frequently, a shortcut command into a generated file.