There are a few principles that I would like the ecosystem of build tool developers to adopt so we can all get on the same page. Here they are in priority order:
- The build tool should be designed to make it as easy as possible for other developers to build your project. The primary consumer of the automated build should not be you. It is your CI machine, it is your fellow developers, and it is your open source users. You could build it with a bespoke shell script much more efficiently.
- There should be a single style of dependency management so that all published artifacts are consumable by any build. The bifurcation into Ivy repositories and Maven repositories makes very little sense. NIH is not a reason to make up a new directory structure.
- Innovation in the space should be around tools that sit in front of a common backend so that the primary developer doesn’t need to change the ecosystem to make their build configuration less verbose.
As the developer of mustache.java I get a lot of feature requests to break the mustache language and add real logic to the templates. In virtually every case the reason the developer wanted the functionality was because they were using mustache with a template backed with a model without an interposed view. Let me give you a common example. Developer has a user object with a few fields:
I wanted to document the most interesting features of JDK 7 here, for my own gratification and to make a place where you can contribute your great finds: Continue reading
Almost a year and a half ago I talked about my implementation of mustache, which I call mustache.java. Since then, we used it to develop Bagcheck and it has also been adopted for a variety of use cases by Netflix, Twitter and others. In my post I mention that for all intents and purposes, the template engine was ‘finished’ and I would say that for the most part, that was accurate. However, there have been a couple of things that have been done since then around optimization and also some interesting extensions that I would like to share with people to get feedback. Continue reading
Update: A bunch of code from hotspot was just integrated into the bsd-port and some of it breaks the build. Use my distribution at the end of this blog post if you want to test the features.
In December JSR-335 was approved by the JCP and is now starting. I’ve joined as member of the expert group, but like with most recent JSRs all the real discussion will take place on the public mailing list. A lot of work has already been done in OpenJDK to support the features of this JSR which will ultimately be included in Java 8 if it completes successfully. Here is the current state of the JSR. Though JDK 8 is when official support would ship, you can already build and execute the draft features of JSR-335 by using the regular OpenJDK 7 build along with some compile-time and run-time tools. Before I go into the guts of how to build them, here are some examples of what you will be able to do:
The great thing about the AvroBase interface is that it can be used with many different datastores because of its relatively low requirements on those stores. HandlerSocket is a plugin for MySQL that gives you direct access to the low level APIs that let you do the operations that AvroBase requires without going through the high-level SQL APIs and therefore skip a lot of boilerplate parsing that happens for every single lookup or scan. You can read about the HandlerSocket benchmarks here. Percona Server is just a better implementation of MySQL with its own modified InnoDB engine called XtraDB. In combination you should be able to get even higher numbers of transactions per second for individual servers in a cluster. Building it on the Mac (or any unix system) is pretty straight-forward.
Building out a social consumer internet product that could change quickly and evolve over time puts special requirements on the underlying data store. You need to be prepared for scale but not investing too much too early, your business may need to pivot in different directions so data models can’t be set in stone and you need to be able to search that data to enable many of the features users expect from an online social product. I have the additional requirement that I wanted all the entities in the system, regardless of where they are stored, to be accessed the same way and be described by the same data description language for consistency and maintainability. I’ve created what I think to be a novel solution to these requirements in the form of HAvroBase. Continue reading
Today someone decided to pretend they knew something about how a modern statically typed language developer works. Perhaps they are big emacs fans or something because they felt that static-types leading to autocomplete in an IDE was somehow a feature in the language FOR THE IDE. The IDE gets no benefit, in fact, editors like emacs and TextMate are much simpler. But I can tell you that the developer gets a tremendous benefit by having this metadata database not only present in the code and easily queryable but heavily exploited by her tools. What is amazing about this metadata database is that it is actually populated by that same IDE. There are very few times that I even type a Type — 90% of those times are when declaring a new Type — the rest of the time the IDE is very patiently maintaining and leveraging that database for me. Even better, when someone else is looking at the source code, or even using the library, they instantly get 80% of the documentation. All that is left are the semantics of the calls. Perhaps we need to have some sort of meetup where we look over each others shoulders and actually understand how someone who is on the other side really works rather than dynamic-typing language people assuming that the programmer is maintaining the huge metadata database present in the static-typing language developers code. And on the otherside that static-typers are assuming that the dynamic-typing language developer is memorizing all kinds of arcane method call names, argument shapes and the shapes of all the libraries they are using. Do you really memorize all that trivia?
A month and a half ago I had put out a call for what I was calling the ‘ideal web application template engine‘ along with a list of requirements that I thought would be present in such a system. Since then I looked a bunch of them and decided that I like the simple markup that mustache defined but none of the implementations were up to doing what I wanted. This led me to embark on building a new engine with for that markup for my chosen platform, Java, which I called creatively, mustache.java. Though it claims to be ‘logic-less’ I would say that it has some amount of logic. It will loop over a set of objects and it will check booleans, but I think it is about as close to logic-less as you would want to be in a template language. So, let’s look at each of the requirements and how I ended up implementing them: