Blob Store

In release 2.0-beta14 (I know, this is the late beta release) AliBaba introduced a new BLOB store. The blob store integrates with the RDF repository ObjectRepository to synchronize transactions. This allows both the BLOB store and the RDF store to be isolated and always consistent with one another. This is done using two-phase commit transactions in the BLOB store.

The BLOB store also has a few other advantages over a traditional file system. First every change is isolated until it is closed/committed. This prevents other readers from see an incomplete BLOB and help prevent inconsistency between the BLOB and RDF stores. In additional, as disk space is generally considered cheap, all past versions of BLOBs are keep on disk by default. This allows any previous versions to be retrieved (and restored) using the API.

The BLOB store API is fairly simple. Here what some code might look like using the BLOB store.

BlobStoreFactory factory = BlobStoreFactory.newInstance();

BlobStore store = factory.openBlobStore(new File("."));

String key = "http://example.com/store1/key1";

BlobObject blob = store.open(key);

OutputStream out = blob.openOutputStream();

try {

// write stream to out

} finally {

out.close();

}

InputStream in = blob.openInputStream();

try {

// read stream from in

} finally {

in.close();

}

More API options can be see in the JavaDocs:

http://www.openrdf.org/doc/alibaba/2.0-beta14/apidocs/org/openrdf/store/blob/package-summary.html

Open Concepts

Most examples of open classes are extensions of core system classes (string/float), such as adding a "to_cents" method on Float. Often such extensions are not needed, as a new wrapper class, such as "Money", would serve the purpose better.

Core classes may not need to be open for extensions, although that can sometimes be useful (remember how long it took Sun to add java.lang.String#replace(String,String)). It is important for Model classes to be open for downstream extensions. For this reason I use the term "Open Concepts" to indicate that the concepts in the model are extendable.

The biggest advantage for having "Open Concepts" is that the model can be modified without modifying the original source. This creates many opportunities for multiple team system development. By enabling the model to permit dynamic integration of independent and decentralized designs (open), the code becomes simplified and more useful to a wide array of use-cases. Consider the productivity advantages of allowing downstream development to have more influence to extend the supplied model without necessarily involving upstream in the changes. These are many of the advantages that allowed the Ruby language to gain so much popularity.

There are many ways to enable this, even in more mainstream languages. One popular approach is to implement a plug-in system for key points in the model (although this quickly become complicated with many "key points").

A more generic way is to implement the role class model in all the concepts. This allows every individual to expose itself through multiple concepts. However, anyone that has used Mozilla's XPCOM, knows first hand how the syntax of this pattern can get out of hand.

Today, with the popularity of new languages that support the run-time mixing of classes, new opportunities for creating an expendable model now exist. Such an approach allows both plugin-style and role-style extensions, but still uses the syntax of the host language. This allows the model to be used the same way as if no extensions are present.

Any large system will need some type of extendability be it a plugin-style, a role-style, or an open-style model. It is worth considering the approach early in the development cycle, as many of these approaches are intrusive, by syntax or language.

Utilizing a Multi-Core System with the Actor Model

Demand for multi-core/multi-processor applications is growing, but developing for a multi-threaded application does not require a steep learning curve or an understanding of complicated edge cases. Learn how to develop efficient multi-threaded applications without using synchronized blocks.

http://www.devx.com/Java/Article/39868

What a Modelling Language Should Look Like

InfoQ gave a summary yesterday of a few blog posts on Modelling languages.
Briefly, Steven Kelly and Juha-Pekka Tolvanen say such a language should:
1) Map to the domain problem concepts and not implementation details.
2) Be formalized and helpful.
3) Have stand alone tooling support.

http://www.infoq.com/news/2008/11/useful-modeling-language

Unfortunately, the discussion focused on a visual modelling language (UML) and did not address any alternative modelling languages, such as the standard Web Ontology Language (OWL), which addresses many of these issues. Although OWL was not designed as a visual language or arbitrary code-generation, it has grown to support such usage.

TopBraid Composer, for example, is a mature editor and visualization tool for OWL.
http://www.topquadrant.com/topbraid/composer/

Module Dependencies

I was reminded recently of a domain model I used to work with that did not separate interfaces from their implementations. They never considered dependencies to be an issue because javac could compile the entire source tree at once.

When I came on board, their product was nearing it's first release and their domain model's class dependency chart looked like a bowl of spaghetti. Eventually the lack of dependency management become apparent: each team was developing at a different pace, but everyone was forced into monolithic releases.

Much of the circular dependencies were addressed by introducing interfaces or abstract classes. However, the process was slow and full of challenges. Hibernate only supports a single inheritance model, but with so many different perspectives such a restriction proved very limiting.

Many of these problems could have been avoided had more thought gone into the the conceptual class hierarchy earlier and distinct modules been created to force developers into observing and thinking about class dependencies early in the development cycle.

Where are programming languages going?

Anders Hejlsberg gave a keynote last month at JAOO http://jaoo.blip.tv/#1324214 (published two weeks ago) entitled "Where are programming languages going?". He said that with a little more restriction in languages, compilers could do a much better job at optimizing the code. I think this is an interesting discussion and agree with many of he ideas.

Towards the end of the talk he addressed concurrency. He suggested that a for loop, for example, could automatically execute all iterations in parallel - if few mutable variables existed. This is an interesting idea, although a very difficult task. Unless the code fits into the map-reduce pattern, it will likely modify some shared memory structure or external state (read database) and could not safely be executed in parallel. I think we will have to see more integration between persistence frameworks and optimizers before such as idea could be realized.

Keeping Classes Small

Most people would agree that smaller classes are better. It is generally accepted that smaller classes are associated with robustness, reliability, reusability, and understandability. However, what causes a class to become too large?

Many people instinctively try to implement a interface or concept as a single class. However, sometimes the implementation is too complicated to be understood quickly and the class size gets too large. If you think this might be the case, take a look at the class variables. If the number of variables is large, if some of the variables could be "grouped" together, or if some of the variables are only used some of the time, try and split the implementation details into their own classes and allow the original class to delegate to or compose them.

Every time you are creating or adding to a class ask yourself if this could better explained in a separate class. This will help you or a co-developer later find what it is they are looking for faster.

Smaller Class Sizes

We hear this a lot wrt education, but can it also help programming? I think so!

Code should be written in a way that explains what the code "should" be doing. This can only be done by continually giving the reader a summary of the operations that need to be performed. Think of each class as cheat sheet: it contains what is important to understand its behaviour. A class should not go into too much detail, but instead delegate to other classes for further details, leading to smaller classes. Every computer operation can be divided into sub operations. These sub operations may not be as important to a reader and should not distract or confuse the reader when trying to understand the purpose of the class.

Easy To Read Code

If we wanted to write code for a computer, we would be using only 0s and 1s, but we don't. Code is written for human consumption. It is more important that a co-developer can easily "compile" the code than any machine. If any code contains a bug, a machine isn't going to fix it - only a human will. Therefore we should take extra care to make the reader's job as easy as possible by making the code as easy as possible to read. Any code worth writing is worth writing well.

Unlike a computer, we can't read one line at a time. Our natural field of focus has a limited width and this needs to be considered when writing and creating APIs. This courtesy leads coders to limiting the length of each line. The easiest way to correct long lines of code is to use more local variables to allow operations to be separated on separate lines. However, too often this is not enough.

Often libraries use overly verbose and repetitive names. This is done in the name of clarity, but at the expense of the readability of their users' code. API developers need to keep not only the readability of their own code in mind, but also the readability of their users' code. Here are four examples that I have seen recently, of APIs that force their users into writing difficult to read code:

• ServletConfig#getServletContext() - The word Servlet is redundant in the method and could be removed to shorten calling code.
  
• org.openrdf.repository.RepositoryConnection - Unless it is common to work with multiple connections from different packages, there is no need to repeat the word "repository" in the package and class prefix.
• IReadableBinaryStreamRepresentation - Here is an example of a repeating suffix that adds nothing to clarify its use.
• context.getKernelContext().getThisKernelRequest().getRequestScope() - If the API forces users in this type of repetitive message chaining, not only is the API forcing code that is hard to read, but it also couples the client to the structure of the navigation and any changes to the intermediate relationships forces the client to also change.

To any API designers (or would be API designers) out there: Please spend some time thinking on how you can reduce the repetition in your API and strive to use short concise names. It will go a long way to making more readable code.