From what I can tell Schemaless has updates but represents them as inserts. When you want to change something (e.g. change the billing status of a trip), it writes a new billing status for the trip and consumers will always ask for the latest billing status for the trip, which is the most recent and up-to-date one.
Take this with a grain of salt, I just read the Schemaless articles yesterday.
That is how I understood it too. Updating your data with a call to insert won't run into the same problems as updating your data with a call to update. Their immutability implementation seems like it would behave nearly the same under both databases.
I wonder if the considered Heka (https://hekad.readthedocs.org/en/v0.10.0/), made by Mozilla? It's written in Go and, as far as I can tell, solves many of the same problems and more.
We use Heka in production and it has changed what would have been an ELK stack to a EHK stack with 0 regrets. The fact that the collector nodes can ship directly to ES without having to go through an intermediary node is extremely special...it reduces system complexity a lot.
Heka looks good and does a lot more. It doesn't appear to support Redis and S3 out of the box, so we would have probably had to evaluate, learn, and change the third-party plugins had we known about Heka beforehand.
I looked into heka a while back and was turned off by its seeming reliance on lua scripts for almost every feature. It just seemed overcomplicated to deploy and maintain for a Go app as a result, and I didn't understand why all that functionality didn't come built in.
If you want to write your own plugins, you can do them in lua or Go. Lua is the recommended way for most types - I think matching is supposed to be faster, and also then you don't need to recompile the heka binary.
If you don't want to write your own plugins, you'll never interact with lua.
Don't you need to ship all those builtin lua plugins around with your deployment of heka though? That was what turned me off - most of the other options can be used with a binary + config file.
Yeah, I like heka a lot in my limited experience with it. Easy to setup, TOML config is pretty nice and forwarding filesystem logs is fast. Interestingly, parsing the logs can be done with custom defined Lua in addition to static methods like regex.
You're both right! He's talking about getting hired, and you're talking about interviewing. The degree can have a significant impact on whether or not you get to the interview stage... and then rarely matters past that.
So, all else being equal, you're less likely to get hired without a degree, but you're just as likely to pass an interview.
We use the same dataset that IP info started with (from MaxMind), although it sounds like they have many different sources now. It's worked fine for us, matches over 99% of the IP addresses we look up, and generally responds in less than 5 milliseconds - basically only limited by network latency.
Right now this is published to a private Docker hub repository, for no good reason, but if people would find it useful we can make it public.
I ordered something from jet.com, was a terrible experience, would not recommend. They apparently decided that my order was fraudulent, cancelled my order, locked my account, _did not tell me and continued to send me marketing spam_. I only found out when I emailed them a few weeks later to ask "what gives?"
The problem isn't pushing an agenda (which I think everyone agrees is fine), it's adding something subjective with no legal definition to your license.
Since no one can say objectively "we do good", you're banking on not getting sued or having enough money and time to defend the lawsuit, which makes it unpalatable to many people.
Additionally, it makes it non-free software, by definition, so a lot of distros can't include it or anything that depends on it.
Most container orchestration systems (Kubernetes, Mesos, ECS, etc.) handle restarting failed containers - that's generally something you want to be outside of your container, not inside.
If you don't use one of those, you can still have supervisor run outside of your containers, and manage a set of "docker run" commands.
> Most container orchestration systems (Kubernetes, Mesos, ECS, etc.) handle restarting failed containers - that's generally something you want to be outside of your container, not inside.
Not sure if I understand correctly. I'm using ECS. How would you provision the Host with supervisord (automatedly)?
ECS and the other systems are taking care of restarting the containers anyway, but they don't necessarily have any logic attached (like restart it 5 times, then stop and notifify if the container doesn't come up again).
From my POV it's definitely better to directly have it deployed within the container. Maybe it's depending on the use case.
The problem is that it often happens that the container cannot restart because the main process (invoked by ENTRYPOINT or CMD) cannot start up anymore, e.g. because of corrupted (config) data which has to be loaded on startup or other suddenly unsatisfied dependencies.
> for a rapidly growing company, technology is easier to change than people.