Braveterry

http://zerovm.org/

I have to confess that I don’t quite understand how this works. I’m quite familiar with virtualization products like VMWare or VirtualBox. They are virtual servers complete with virtual hardware to install a complete Operating System on.

According to the Rackspace Blog ZeroVM is…

…a lightweight open-source hypervisor created by LiteStack and built to run
cloud applications. ZeroVM breaks down the barriers between compute and
storage. Where traditional cloud architectures have needed to move the data
to the app for processing, ZeroVM flips that approach and moves the app to
the data. This dramatically increases speed of access and decreases latency.

ZeroVM is efficient because it is made to virtualize applications, not
machines. The runtime virtualizes only the server parts that do the actual
work at hand – making it much faster. Today, the fastest virtual servers
take at least two minutes to create, while ZeroVM takes less than 5
milliseconds – or 1/20,000th as long. ZeroVM is fast enough that you can put
every request into its own mini-VM to spread horizontally.

Making things smaller, lighter and faster also provides greater security.
ZeroVM is fast enough to isolate each individual user in a separate
container, which delivers greater granularity of security and control.

https://www.atlassian.com/git

This is a microsite hosted by Atlassian devoted to Git. It has tutorials, sample workflows, migration tips, and links to other Git resources including a PDF Git cheat sheet.

I sort of have a thing for back-end systems: RPC calls, middleware, serialization protocols. A well put together and well-documented API makes me smile. MessagePack (via) looks like another great tool for my tool-belt.

The MessagePack website says:

MessagePack is an efficient binary serialization format. It lets you exchange data among multiple languages like JSON. But it’s faster and smaller.
Small integers are encoded into a single byte, and typical short strings require only one extra byte in addition to the strings themselves.

Here’s an example in Java, also from the MessagePack site:

Simple Serialization/Deserialization/Duck Typing using Value

// Create serialize objects.
List<String> src = new ArrayList<String>();
src.add("msgpack");
src.add("kumofs");
src.add("viver");

MessagePack msgpack = new MessagePack();
// Serialize
byte[] raw = msgpack.write(src);

// Deserialize directly using a template
List<String> dst1 = msgpack.read(raw, Templates.tList(Templates.TString));
System.out.println(dst1.get(0));
System.out.println(dst1.get(1));
System.out.println(dst1.get(2));

// Or, Deserialze to Value then convert type.
Value dynamic = msgpack.read(raw);
List<String> dst2 = new Converter(dynamic)
    .read(Templates.tList(Templates.TString));
System.out.println(dst2.get(0));
System.out.println(dst2.get(1));
System.out.println(dst2.get(2));

http://superherojs.com/

We consume a lot of SOAP web services at work, and frankly, it sort of sucks. SOAP is heavier (and slower) than I would prefer.

From the Apache Etch web page:

Etch is a cross-platform, language- and transport-independent framework for
building and consuming network services. The Etch toolset includes a network
service description language, a compiler, and binding libraries for a variety of
programming languages. Etch is also transport-independent, allowing for a
variety of different transports to be used based on need and circumstance. The
goal of Etch is to make it simple to define small, focused services that can be
easily accessed, combined, and deployed in a similar manner. With Etch, service
development and consumption becomes no more difficult than library development
and consumption.

Etch was started because we wanted to have a way to write a concise, formal
description of the message exchange between a client and a server, with that
message exchange supporting a hefty set of requirements:

• support one-way and two-way, real-time communication
• high performance and scalability
• support clients and servers written in different languages
• support clients/servers running in a wide range of contexts (such as thin web
  client, embedded device, PC application, or server)
• support anyone adding new language bindings and new transports
• be fast and small, while still being flexible enough to satisfy requirements
• finally, it must be easy to use for developers both implementing and/or
  consuming the service.

Here is a list of the language bindings Etch currently supports:

• Java – stable
• C# – stable
• C – stable
• C++ – beta
• Google Go – alpha
• Javascript – alpha
• Python – alpha