I would also say "strict" ACID is become just another marketing term. I think what is more important is evaluating a databases support of different consistency and isolation levels. As well what level of availability do they support with these transaction guarantees? Do they support fail over to an active replica on the fly with no downtime? Are minority replicas available during network partition?
"strict" ACID can mean a lot of different things. There is a lot of levels of consistency and they prevent different types of issues with data correction and isolation. I think database vendors should clarify what consistency model they mean as defined by https://jepsen.io/consistency
That's a great resource. We've tried to be consistent in using these terms. I think a lot of the confusion and lack of standardization over terminology came from the fact that database and distributed systems research had less overlap in the past...
Consistency in the ACID sense meaning something different from CAP Consistency is another good example.
Another point that often gets lost when talking about ACID guarantees is the maximum scope of a transaction that a system supports. There are many systems which support ACID guarantees for a single record or shard, but fewer that can support fully distributed transactions across a sharded dataset in a scalable manner.
How does fauna's consistency guarantees compare to coakroach, spanner and yugabyte? It is difficult to compare because different vendors use different terminology. For example spanner supports 'external consistency'. And Coakroach says it supports serializable as defined by ANSI. Is this the same as what Fauna calls strict serializable?
I believe what we spanner calls 'external consistency' we call strict serializability. Read-write transactions in FaunaDB are strictly serializable, whereas reads default to serializable. This allows us to serve reads independently from the closest region to the client, cutting down on latency in geo-distributed clusters.
Grand Cloud | Software Consultant, DevOps Consultant | Western United States | REMOTE & ONSITE, FULL-TIME, CONTRACT | https://www.grandcloud.com/
We're a small consulting shop tackling projects other companies deem impossible. We currently have multiple clients ranging from large enterprises in retail and ad tech space to small startups in fintec and education. We work with the latest technologies such as Kubernetes, Istio, Vault, Consul, etc. on Infrastructure and develop applications with Corda, Kotlin, Scala, gRPC, etc. For data platforms we are using FaunaDB, Spark, Cassandra, etc.
We're looking for engineers who enjoy a diversity of projects and are self-directed:
Backend Engineers / Consultant -> experience in the JVM ecosystem (Scala, Kotlin or Java) and Data Technologies (Cassandra,Spark,etc.)
DevOps Engineers / Consultant -> experience with the HashiStack, Kubernetes and Infrastructure Automation
CryptoCurrency / Smart Contract Engineers / Consultant -> experience with Corda, Blockchain, etc.
On-site opportunities available in the western US. Remote opportunities worldwide.
We spent a fair amount of time evaluating lift, play and other frameworks recently. We ended up choosing Play for these reasons:
Developer Productivity - Having worked with a lot of the major frameworks they are all very comparable. You can say the same things about Play, GWT, you don't worry about the plumbing, setting up routes, ajax, etc. ...
Learning Curve - You really need to know Scala and functional programming to be effective with lift. Even though lift itself might be more productive, easier, etc. none of that matters if you are not experienced in Scala. And becoming truly experienced in Scala takes a fair amount of time.
Play is plain Java and so it took the developers on are team less than a day to become productive with Play, they have a great tutorial that walks through all the major parts of a Play framework.
Developer Perception: Seriously emacs? Textmate is the only way to go.
Developer Availability - Well you might be able to find Lift developers, but they come at a major premium because they know Scala. Java developers are much more common and don't have the major premium. And there are a lot more Java than Scala developers (DP charges a very healthy $250 / hour - http://www.quora.com/What-are-the-going-hourly-contracting-r... )
Templating - Yep most frameworks have them, pretty common.
Plugins - Play has those in the form of modules
In the end I would agree with Raible's findings, there is not a huge difference in frameworks.
I do find one thing curious about all of David Pollak's rants are they always reference Foursquare and Novell.
This website http://www.hellokeepa.com is also doing some interesting things with what looks to be the onscroll event, the page continuously wraps around. Also notice how you can drag the page left and right.
Basecamp has one major limitation for me and that is only people within your company can track time against projects. I work with a lot of independent contracts and I wanted to put them in separate companies, but still have them track their time in Basecamp. I have talked with support and this is a "feature" which they are sticking with, very frustrating.
Even if it is not the first day, I think the point is well taken that this needs to happen ASAP. I have worked as a consultant at large corporations and have seen developers go months without ever checking in code.
