beginrescueend

Yeah, when I saw it was a Software-Defined Instruction set, I immediately thought of Transmeta, as well.

Inside a company, I like transfer.sh, which is like an open source version of file.io - * https://github.com/dutchcoders/transfer.sh

That's good for the 5G +/- file transfer.

One week out of two, for a company size of 20.

The Bible, definitely. Pilgrim's Progress, by John Bunyan.

Those are the two most published books in history and have changed more people's thinking than any two other books.

Very cool idea!

0 points?!?!?

I thought this was about what non-technical books have helped me, professionally.

Intolerance?

Start with the book of Proverbs, follow its wisdom and advice, if all you're after is career improvements. Great wisdom.

(Wisdom about people, situations, attitudes, and actions are all found there).

But, move on to John, if you are eager for more.

I essentially have the same questions as you do. I'd like to evaluate Cloud Foundry, here, where I work.

I'll probably bake-off DC/OS and Cloud Foundry; maybe I'll also bake-off one or more of DEIS Workflow, SuperGiant, and maybe Apcera.

All of this is an eval for an enterprise-grade Docker platform, for development through production, including CI/CD.

I second Elixir. Concurrency and HA are the future!

Way to go! Great work, team.

It depends on what you mean, what your goals are, what you are trying to build, etc.

"No maintenance whatsoever?" I doubt it. Things break, get old, go obsolete, are insecure, and wear out.

Perhaps, you should worry about "nines of uptime" or "fixed requirements" or something along those lines.

Simplicity is first. The more complex, the more maintenance. "Everything Should Be Made as Simple as Possible, But Not Simpler" - http://quoteinvestigator.com/2011/05/13/einstein-simple/

"No moving parts."

Make it highly available and redundant. Power, cooling, networking, hardware, and software redundancies are needed.

Make it immutable. Change and mutable state will create maintenance. Implement functional programming, if you write software.

Monitor it and make it self-restart. Somebody already mentioned watchdogs, for hardware.

Make it ultra secure. No outside networking?

Program finite state machines....

If you imply a "hardware and software" solution, these points sound like you need redundant hardware and Erlang/OTP. Take a peek at OTP and the Erlang-based languages (Erlang, Elixir, Joxa, and LFE).

At least with redundant power, cooling, hardware, and Erlang/OTP (Elixir/OTP, etc.,) you gain the ability to do all of these things.

With Erlang/OTP, you can achieve very high uptimes, and if you design it correctly, you do have the ability to hot-patch running code, if you do have to (rarely) perform maintenance.

While you're at it, you also get distributed programming, concurrency, and parallelism, for free, with Erlang/OTP. This, in and of itself, can "reduce maintenance."

See https://pragprog.com/articles/erlang and http://stackoverflow.com/questions/8426897/erlangs-99-999999...

Elixir is inspired by Erlang/OTP and Ruby and the runtime is Erlang BEAM/HiPE. :-)

The hive needs to be south-facing (if you live in the northern hemisphere). Stay out of flight path, for best results...

Great article!

We're on our 3rd season beekeeping; we just collected honey, last night.

In fact, I got my first ever bee/wasp/hornet sting ever, last night, from one of our bees. I was being sloppy, wearing running shoes under my bee suit, instead of boots. It hardly hurt at all, though. (I've had worse mosquito bites; so far, horseflies are the worst bites/stings I've ever had).

We captured our first swarm, this year, and got another hive "for free." Woo hoo!

As far as ordering stuff, since somebody mentioned it, we just go to http://www.beekeepers.com/ to get our gear, since our local farm stores don't carry much.

I am interested in these projects, so I can get my bee geek on, but I don't know if I should commit the time and money to them (any success stories out there)? http://www.opensourcebeehives.net/ http://opensourceecology.org/wiki/Beekeeping http://openenergymonitor.org/emon/node/102

How does something like Phonegap / Apache Cordova fit in to VoltRB?

ArangoDB - http://www.arangodb.org/

Here's a good list: http://db-engines.com/en/ranking/graph+dbms

Here are some of my reasons for using ArangoDB: https://news.ycombinator.com/item?id=7246849

RiveScript is a FOSS chatbot scripting environment that you might want to try: http://www.rivescript.com/ http://www.rivescript.com/rivescript http://www.rivescript.com/aiml

The original interpreter is based on Perl, but there are other first-party libraries: http://www.rivescript.com/interpreters

You're welcome! :-)

Yes, if there was a standard query language for NoSQL, that would be priceless.

Gremlin appears to be closest thing, today. I like what I've seen with JSONiq, though...

This seems like a good somewhat related link: http://stackoverflow.com/questions/12043086/graph-dbs-vs-doc...

Databases, of course, are complex software, with a long list of pros and cons. I prefer ArangoDB over OrientDB, after a multi-month evaluation of both. (I also considered Neo4J but could not afford it, in production, so it unfortunately never got a fair evaluation).

As I mentioned earlier, in OrientDB, be careful using the eSQL syntax "INSERT INTO" and "UPDATE ... SET ..." for graphs, unless you are doing things 1 record at a time. Bulk inserts will cause an out-of-memory crash, as of version 1.4+. (I have never crashed ArangoDB, including performing 150M JSON bulk imports).

In OrientDB, "CREATE VERTEX" has a very different syntax than "INSERT INTO" (and "CREATE EDGE" is very different than "UPDATE ... SET ..." when you add graph relationships to existing data). Because of this, I don't find that the eSQL stuff is very useful for more than simple queries.

You can do JSON REST Bulk inserts which are very fast, but I find that creating graph relationships that way in OrientDB is challenging, unless you know the ID (###:###) of a vertex. This can be determined programatically, of course. ("UPDATE ... SET ..." when it worked in 1.2 / 1.3 was much easier).

Oddly, the /etc/init.d/ scripts seemed broken on the Linux version of OrientDB -- they don't stop the database and are odd to configure. This should be easier (versions 1.2 through 1.6).

I have mixed feelings about using the Java JVM for OrientDB, as opposed to native C/C++ used by ArangoDB. (My personal preference leans toward native C/C++.) ArangoDB seems very light-weight and responsive all the time, including startup.

Again, documentation was hard-to-find and inconsistent, as of OrientDB 1.5/1.6, but it does seem to have improved since then...

Finally, in my experience, eSQL (OrientDB) does not seem like a logical choice for JSON Documents or for Graphs. AQL (ArangoDB), after you get used to it, does seem to be designed for key-value pair queries, graphs, and documents, but it's query-only. (In ArangoDB, I actually like coding in JavaScript, mixing a bit of AQL in, when needed).

Otherwise, I really liked OrientDB, at the time I evaluated it; I was actually hoping to stick with it. Overall, OrientDB has more features. The OrientDB team, also seems VERY responsive to requests. (I haven't needed to reach out to the ArangoDB people, yet, since I have been able to figure out everything myself, so far).

Both OrientDB and ArangoDB are in a state of flux. New features and bug fixes are being done, all the time.

OrientDB seems like a logical choice to replace SQL databases or for Java developers (for graphs and JSON documents). ArangoDB seems like a logical choice to replace MongoDB or for JavaScript developers (for graphs, JSON documents, and key-value pairs). OrientDB seems designed for scalability and flexible schema design. ArangoDB should be more scalable, soon (promised in ArangoDB 2.0).

Back to the issue of query languages... There are other query options.... Both have Gremlin / TinkerPop. If you're used to that and like it, both OrientDB and ArangoDB are essentially on equal footing, query-wise.

Looking back, I probably should have tried out Gremlin, whatever choice I made, during my evaluation of OrientDB vs. Neo4J vs. ArangoDB.

For both OrientDB and ArangoDB I hope for Cypher (Neo4J's native query language) and for JSONiq (somewhat similar to ArangoDB's AQL, actually) as query language options.

I've used OrientDB and ArangoDB, both being graph and document (JSON) databases.

I had some initial success with OrientDB, under version 1.3. However, after frustration with the documentation and frustration with having to completely recode my app in version 1.4, I decided to look again. Versions 1.4 through 1.6 all had problems crashing doing bulk imports, so I gave up on it.

Now, I'm using ArangoDB and am pleased with documentation, stability, and am liking AQL and Foxx (an API server included with ArangoDB).

While there are some things in OrientDB that don't yet exist in ArangoDB, I am pleased with ArangoDB.

Try it here: http://arangodb.org/