Very exciting, but high availability, instance cloning, and read replicas are listed as "This functionality is not yet supported for PostgreSQL instances" in the docs. Seems like those need to be available before it's a realistic option for production workloads.
Being able to ship something is definitely important as there are a lot of junior (and even more experienced devs) that just can't seem to finish a project.
Also, stick around for a while after it's been shipped or deployed and see what kind of difficulties the ops guys have with it if it's a SaaS product or the customer support team has if it's a locally-installed product. There is a huge difference between shipping a working product that is simple to operate and support vs. one that requires constant care from an expensive ops or support team.
I despise these forms and their presence almost always results in my deciding not to submit an application. The best companies I've worked for have either (a) not had these employment history forms at all or (b) asked for them to be filled out in minimal fashion after the offer had already been extended and accepted.
If you're going to do this, you should leave out X. The larger the differential between X and Y, the higher the unconscious (or perhaps even conscious) bias will be against you. "This guy wants a 40% raise to come work for us" vs. "This guy wants $Y to come work for us."
And CloudWatch is free for RDS at 5-minute collection intervals which is more than adequate for alerting on things such as "Am I about to hit the space limit on my database?"
Unless you have a workload that won't fit on a single machine, a distributed database isn't really an advantage over a single master with one or more appropriate replicas that are available for failover.
1) It's rare to have enough insight into the internals of a particular datastore to accurately predict how it will perform on a particular workload. Whenever possible, early testing on production-scale workloads is essential for planning and proofs of concept.
2) Database capabilities are a moving target. E.g., the performance improvements to pgsql's LISTEN/NOTIFY are essential to its ability to handle this particular workload. In previous jobs, I've had coworkers cite failed experiences with 15-20 year-old databases as reasons for not considering them for new projects. Database tech has come a long way in that time.
3) Carefully-tuned RDBMSs are more capable than many tend to admit.
I'd say YAGNI applies here since 95% of systems will never need to scale beyond the capabilities of a properly-configured RDBMS. Ensuring consistency and durability with a non-relational, distributed datastore generally requires a lot more detailed understanding of its internals than with a RDBMS, so choosing one of those rather than a RDBMS is going to impose costs that should be deferred until they're absolutely necessary.
Yeah, San Antonio is almost certainly a better description of the location. Rackspace's HQ is technically in the incorporated city of Windcrest, but unless you've lived in the San Antonio MSA, you've probably never heard of Windcrest. It's a two square-mile city of 5300 people entirely surrounded by San Antonio and its MSA population of 2.3M people. Windcrest consists of a single suburban residential neighborhood and a couple retail strip centers. Rackspace bought an empty shopping mall on the very edge of the city that had been vacant for about two years for its HQ. Given the retail decline in the area, it was, no doubt, a coup for Windcrest. I grew up just north of Windcrest and used to go to that mall all the time although it was on the decline even 25 years ago.
Ah, that's an awfully nice search capability. I posted elsewhere in this thread that I use SimpleNote. It's not perfect, but >95% of my note-taking needs were text-only and SimpleNote was less hassle than Evernote.
I've heard that it's good, but I never tried it myself. I think OneNote is free now, so I'm pretty sure you could try it without having to buy anything.
I don't have any screenshots or other images in my notes. If I needed one, I'd probably upload to an image hosting site and put the URL in my note. That's obviously not as good as embedding inline, but I haven't found anything that I consider perfect, yet. I probably would have just upgraded to a paid Evernote account if I hadn't found their client apps so buggy.
I wanted a tool with some organizational and formatting capabilities and built-in syncing, so I used EverNote up until the point that they limited the number of devices that would work for unpaid plans. I have since switched to SimpleNote. Both have reasonable search capabilities. Neither are perfect for what I want, but both are adequate.
The SQL Server licensing model is "per core", but the minimum licensing increment is 2 cores which costs (2 * $7k = $14k). It's obviously a confusing pricing scheme, but try pricing out Oracle some time!
It's unclear what you mean about the difficulties of getting data out of SQL Server since it's really no harder or easier than getting data out of any other RDBMS. Scaling SQL Server, just like scaling any other RDBMS, can be challenging since traditional RDBMSs don't distribute well. While some workloads are CPU-limited, that is not true for all workloads so the per-core licensing model of SQL Server (which ~$7k per core for 2016 Enterprise edition, not $16k) is not always prohibitive if your workload is more disk or RAM-intensive. There are points of differentiation between SQL Server, PostgreSQL, and MySQL that might make one better suited to a particular workload than others, but those situations are dependent on the details of a particular workload and something as general as "getting data out" or "on a customer-facing system" aren't specific enough to identify any one of those as more suitable than another.
I suspect your familiarity is with areas that are much higher cost than average. I've owned houses in two different MSAs in the top 25 in the US and the land value was much lower than 80% of the total value. Land value is also very demand-driven though local zoning regulations (multi-family units, proximity to commercial zones, etc.) do drive some of that demand.
From what I've read about CockroachDB, I thought it was master-less. If so, I certainly hope there's a market for a horizontally-scalable, ACID-compliant database. I know it would come in handy for a number of applications I've worked on that required consistency but had workloads that were difficult to fit on a single server or a master-slave setup.
Did that 40x number come from that video? In my experience, any non-trivial async operation (e.g., a 2ms database insert in a fast OLTP system) is going to be on the order of 10-20% slower in straight-line operation latency than a sync operation while handling vastly more throughput.
>>I would argue that async/await is far more important for native applications. I've seen plenty of apps doing significant work on the UI thread and hanging. Making it easy for developers to run things in the background is great for performance. Web browsers automatically add a level of asynchronous interaction.<<
You can achieve the same thing in a GUI app by simply off-loading the long-running operation to a separate thread. The same is _not_ true for a highly concurrent, I/O-heavy server workload. That's where async/await is necessary and not just a syntactic convenience.
This is very true and a better explanation of the benefits of async/await than "Efficiency and Comfort" from the article. There are a lot of articles on async/await in .NET that use the example of off-loading a long-running operation from the GUI event thread. While that's a legitimate use, it obscures the true benefits which are most closely tied to throughput scalability. In other words, maintaining a relatively small pool of threads to service I/O completion events allows a machine to minimize the overhead of thread context switching that can become a bottleneck in a thread-per-operation model.
Additionally, many people have the misconception that async operations are somehow faster than their sync counterparts. In fact, they're generally slightly slower, but a fully asynchronous server will be able to maintain a much higher level of throughput, usually with similar latencies, than a fully synchronous server. In other words, the principal class of applications that benefit from async/await are high-concurrency server applications.
One more place I see these kinds of misconceptions is in naive benchmarks that purport to test async performance without using a concurrent workload. That tests only straight-line latency of individual requests and isn't the point of async. The benchmarks in the blog post above properly use a concurrent workload for testing.
My team has a daily 15-minute scrum meeting that I haven't found overly burdensome. We're spread over a 4-hour time difference, so the time of day isn't really an imposition on anyone. It's also no big deal if someone misses from time to time but I've found it generally helpful for keeping up with what the team is doing.
Beyond that, I'd say the ease with which a video chat can be initiated is important so that the annoyance of starting one does not become an impediment to using them when they are appropriate. My team uses Sococo which, while not without its problems, does allow for one-click video chats and screen sharing with 1 or more co-workers. It's really nice to have the option to jump into a 5-minute video chat/screen share with the click of a button to work through something that would otherwise be a 25-minute chat conversation.
I'm a big fan of PG and PG is good enough that it can compare favorably to MSSQL on its own merits, but that article reads more as a screed against commercial software than an objective assessment of PG's strengths relative to MSSQL. As an example, a big advantage of MSSQL for data analysis applications is its column store indexes which the author dismisses as something he doesn't use.
You're misinformed about the nature of the SQL Server codebase. While it was originally licensed from Sybase, all parts of it have been completely re-worked. I read somewhere that they celebrated "zero Sybase day" or something to that effect in the early 2000s to mark the retirement of the last of the original Sybase code. Some more info here: https://blogs.msdn.microsoft.com/euanga/2006/01/19/sql-mythb...
As for its performance and features, I have run PostgreSQL, MySQL, and SQL Server in production on large workloads and am a big fan of PostgreSQL. That said, I've encountered the fewest sharp edges and disappointments with SQL Server. It is a very respectable RDBMS and it's great that it's now available on Linux.
I've not heard of any. I would imagine that the real value for Microsoft is in expanding the number of server platforms on which SQL Server can run and MacOS doesn't really fall into that category.
SQL Server supports heaps (tables w/o clustered indexes) on which indexes point directly to the referenced row. It's nice that they allow you to choose between those and tables with clustered indexes where any secondary index references the primary key. See
https://msdn.microsoft.com/en-us/library/hh213609.aspx