Screenshot capture on Windows: Microsoft wins.

I’ve been trying to find a good, convenient analog for GNOME 3’s screen capture utility on Windows 8.1, and it turns out the best of them seems to have been delivered with Windows itself.

I’m really bad about screen captures. I don’t normally think in ways that are easily expressed with visuals; I prefer fractured narratives. It’s easier for me to try to describe something than it is for me to see a screenshot as useful information.

However, screenshots are good: they eat up a lot of visual space (adding length, and therefore gravitas, to content), they attract readers, and they give readers useful reference points.

On Linux, the GNOME 3 screenshot application is fast, convenient, tiny. It’s not perfect, but it’s straightforward.

Windows didn’t really seem to have that. (There’s a spoiler here, if you can’t read the title of the blog post.)

I looked at a bunch of them, and installed a few: Skitch, and PicPick. Of those, PicPick was better, although it couldn’t capture the default (and convenient) hotkeys; I think DropBox was interfering, but I’m not sure.

It didn’t really matter; in the end, Windows did come with a screen shot application. The Snipping Tool that comes as part of Windows 8.1 did everything I needed, efficiently and well, without any third party software, and it’s easily accessed from anywhere.

Microsoft wins this round.

The only thing I’d like to see is a context-menu window capture option, honestly – that’d be the better mousetrap for me.

Synergy 1.6 beta released

The Synergy Project announced the release of Synergy 1.6 beta, which among other things offers an autoconfiguration mechanism. Synergy allows you to use one mouse and keyboard for multiple computers – almost like a software KVM (although chances are they’d say it was exactly like a software KVM.)

I’d tried it before on Fedora and Windows; it was “problematic” for me (as in: it didn’t work.) It was a little frustrating, because one of my friends uses it constantly and he says it works perfectly for him. I’d even contributed to the project, because it seemed so valuable as a concept… but not for me, alas.

The new version, however, works like a champ on my iMac and Windows computers; I haven’t tried it on Fedora yet. (I’m not likely to, for various reasons, mostly related to laziness.) It’s actually really handy; now I can start reducing the explosions of keyboards and mice on my desk.

Considering I presently have three of each lying around, plus various MIDI controllers, anything that reduces the clutter is worth investment and praise.

Good job, Synergy. People: help support the project.

Compose Key for Windows

One of the things that drives me crazy about Windows (among many) is the missing “compose key,” a key sequence that allows me to enter unicode sequences easily. For example, if I want to use the word “clichés” properly, I want an easy sequence to enter, like I have on my Linux installation.

Enter WinCompose. This blog post has been written entirely on Windows 8.1, with no HTML entities and no manual unicode entry. I remapped the signal key to the menu key (as I have in Fedora), but otherwise everything’s unchanged from the default installation.

I’m still in “trial mode” — I just installed it this morning, because typing the word “cliché” was annoying — but so far it’s rocking.

Rocket Java: A project to test Java 8’s More Strict Verifier

Java recently added a more strict verifier to the class loading mechanism. This isn’t really a bad thing, necessarily, because it conforms to what Java was always supposed to do – except a lot of projects now rely on the verifier doing what it’s always done.

For all intents and purposes, the Java 8u11 (and 7u65) release broke things, especially things that did classloader magic in specific ways.

Apparently the verifier’s been changed since 8u11 to allow the (now-prevented) behavior again – but the fix hasn’t made it into the public builds of Java 8, as of 8u20 and 7u67.

With some help from ZeroTurnaround, I put together a project on github, called brokenverifier, that exercises the class verifier such that it fails with behavior that older versions of Java (meaning prior releases) allowed.

Check out; it should be easy enough to clone and run regularly, until Java’s verifier is changed again.

The hardest thing about life is living it.

It’s easy to look at life’s little hurdles and respond with something trite, like “It could be worse,” or “You could have brain cancer.” The thing is: those things are true; it could be worse, you could have brain cancer… and sometimes you do. Sometimes the bump in the road is minor in comparison to the chasm ahead, but that doesn’t mean the minor issue doesn’t matter.

It does. It adds to the depth of the well you find yourself in. It doesn’t make it any easier to maintain perspective; in a way, it just adds to the tide of despair.

Sure, it’s easier to handle those little mishaps when you have something giant on the horizon; when you have a broken leg, a chipped nail isn’t that big of a deal.

Especially from the perspective of others.

That chipped nail, though, might be the thing that’s holding you together. Who can say? That one little glitch might be enough to erode hope and future.

Encourage others, when you can. Until you’ve really walked in their shoes – and not just seen their feet and thought, “Okay, I might have been there” – they need as much of your help as you are able to offer. Pay it forward; some day, you may need them the same way they need you.

(And in the end, sadly, the response still becomes “c’est la vie.”)

Writing formats for books

I’ve recently started contributing to another book, and one of my tasks was, like, “start the book.” I’ve been dealing with the tyranny of choice – poorly, as it turns out – and I think I’ve finally solved one of the hardest problems:

In what format should the book be written?

I’ve gone around and around on that question. It comes down to two features: simplicity and power.

Simplicity is what you get when you use plain text; you’re just writing. Most writer’s editors emphasize a plain writing surface; they just present you a simple screen, with nothing in front of you but the plain page. No proportional fonts, no bolds, no italics, no spellchecking, nothing: just the page; you get to (or have to) focus on just writing; the editor is out of your way. (This is a good thing.)

Power is the ability to modify the text, adding features and maximizing the impact of each word. It implies all the cool fonts, leading drop-text, references, specific layout control, grammar checking, spelling, all the bells and whistles.

Publishers tend to prefer Microsoft Word; that’s the format I’ve used for another book. Word’s certainly capable, but it’s not open source (a critical aspect for this book), and it’s not available on all of my platforms. Word strikes a good balance between simplicity and power; the ribbon doesn’t help (you have to learn how to use it, and it’s not especially fast with which to interact). As far as open source and wider availability goes, well, LibreOffice can work with Word documents, for the most part, but that “for the most part” isn’t really enough.

LibreOffice Writer might be a workable substitute altogether for Word, of course. The Open Document Format isn’t terrible; I don’t know what really biases me against this choice, but I am biased. Maybe it’s because I also use Word, and the finger-familiarity dissonance isn’t entirely pleasant. LibreOffice is a lot like Word on the balance between simplicity and power; it’s a little simpler without necessarily losing power.

I considered DocBook, and even set about writing some with it (with the help of Publican). I can’t argue against DocBook’s raw power, and won’t… but I will say that writing in DocBook is almost as fun as gnawing off your own neck. Almost. The signal-to-noise ratio for DocBook is incredibly bad – I spent more time muttering under my breath about <para> than I did actually writing the text. DocBook is the epitome of power, and doesn’t even pretend simplicity; SGML, for the … win.

If a format like DocBook prevents you from concentrating on writing, it’s a bad format for you.

HTML is out there, of course, and while HTML is very well known, it is pretty much straight markup.

I looked at Markdown, which is the format I use when writing on my blog (thanks to JetPack in WordPress). Markdown’s fairly old, but closer to what I think I want, except as a format for large, printable documents it’s vastly underpowered. Markdown tries to end up more on the side of “simplicity,” with some power; this is a good thing, because it means a simple text editor can be used to write workable Markdown.

That led me to AsciiDoctor, which is a lot like Markdown in substance, but has a lot more power: footnotes to abuse, a full working table of contents, references, a bibliography, customized rendering templates (including to DocBook)… basically, AsciiDoctor has most of the features one thinks of when considering word processors, without the “word processor” part – it’s just a markup engine with a lot of power.

AsciiDoctor strikes probably the best balance I’ve seen between simplicity and power. If you need it, you have all of the power you need; it’s not a layout engine, so the power you have to endure to get layout isn’t in your way. (This is where Word fails, honestly; you can use Word for layout, which means you get to face features aimed at layout.)

So there you have it, folks: I’m choosing AsciiDoctor to write with.

A quick first-contact tutorial for PencilBlue

Let’s see if we can figure out how to use PencilBlue. It looks interesting enough, and I like much about the approach they’re taking (“Eventually someone who’s not in love with the technology has to manage the site”); let’s see if we can hammer out some basic workflows.

The philosophy PencilBlue seems to prefer is “less is more,” and boy howdy, do they stick to that. My new site, after setting a banner, looks like this when it’s invoked:

PencilGlue's site, with my custom banner
PencilGlue’s site, with my custom banner

All right then! After I log in, it looks way different:

The site after I've logged in
The site after I’ve logged in

… except, no, it doesn’t really look different at all. The main difference is the “log out” button on the top right. If we select the farthest left icon, we end up being able to manage our profile (which allows us to change our password, our name, and our picture), but there’s still not a lot of information being thrown at us.

I actually could not find a way to get to any content administration from the landing page, whether I was logged in or not (and I’m the administrator on the site, so I should have access – and I do, as we’ll see.)

I can open the administration console by going to /admin – which is available only if I’m logged in, which is good. The admin console looks like this:

The administration console
The administration console

There’re a few things we can do here – set email preferences, see the configuration (as shown here), look at users, and check out the plugins (which include a few useful things, but nothing marvelous yet besides a mechanism by which you can import data from WordPress.)

Settings, mostly read-only
Settings, mostly read-only

What really interests us, though, is the content. Choosing the content dropdown gives us options for:

  • Navigation
  • Topics
  • Pages
  • Articles
  • Media
  • Comments
  • Custom objects

Let’s start with topics, because taxonomies should be determined fairly early (or so I think) – if we decide to add to the taxonomic structure, well, I don’t think anyone will blame us.

The topics screen is really pretty easy: It has an option for adding topics, searching for topics, and importing topics; it allows us to delete topics already created. This seems easy enough to use.

Our topics, which I'm not yet sure how to use
Our topics, which I’m not yet sure how to use

I’m not sure offhand what the difference is between a page and an article. In WordPress, a page is contained in a different structure than a post is (even though internally they’re almost identical); I’m guessing that this is similar, that articles represent information that is time-relevant, and pages represent static content for the site.

Let’s assume this is right, and create an “About” page, because everyone wants to know about this site.

Opening the pages menu option (under “content”) gives you the ability to manage your pages, and add new ones; we don’t have one, so let’s add one.

The content addition page has four headings of information for a given page: the page content, any media attached to it, topics, and SEO, which makes a lot of sense.

I’m going to add the page under the url “/page/about”, with a headline of “About this site,” and a subheading of “All the stuff you didn’t know you wanted to know.” I’m setting the publication date to now, because… just because, and I’m basically typing in an equivalent to lorem ipsum as the actual content.

At the bottom there’re two buttons: “Cancel” and “Save draft,” except “Save draft” also has an option (accessible through an up arrow) of “Save.” I’m not worried about drafting – either I’m a fantastic writer, or I’m not too concerned about the draft of this content, since it’s mostly throwaway stuff – so let’s choose “Save.”

Now, the pages … page says that it’s been published; saving is the same as publishing, based on the publication date. This is fairly important. It’s also not obvious to me, but then again, I’m probably used to more traditional publication cycles.

The problem now is: how do I find this page? The front page of the site looks exactly the same as it did. Maybe it’s time to add some navigation to my about page.

Navigation items can fit one of five different types: container, section, page, article, and link. We want to add a page, so let’s try that.

I entered “About” as the name, a short description, ignored the parent navigation item; off to “Content.” Here, it’s asking us to search for the right content. I happen to remember (because I wrote it down, you know) that the content I’m trying to include has “about” in the name, so I typed “about” and then selected “About this site,” since that was what the dropdown tried to show me.

Naturally, once I’d done that, I tried to save it, because saving is important.

Opening the site now shows me a marvelous change: I have an “About” link! It even works!


Well, that’s exciting. It’s time to see what else we can do. I’m going to create a page called “Node.js,” just because; it’s going to be like our other page, and mostly consist of content to throw away.

Now, I open my navigation panel, and add “Languages” as a container. After that, I add Node.js as a page, except instead of not having a parent navigation item, I’m choosing “Languages.” Opening the site now gives me “About” – a direct link – and “Languages,” with a dropdown including our new Node.JS page.

Except that doesn’t work! The “.js” makes it look like something it’s not; we need to use _js instead. After we fix that, the page works. We now have rudimentary, rather sparse content to go with our sparse site.

It’s time to blog, then. I’m adding two articles, called “Hello world” and “hello world, again”, both under the languages taxonomy. After saving, both show as being “published.”

And WHOA! Now we have two pieces, published in most-recent order (just like every other blog), on our home page!

It looks like a blog now.
It looks like a blog now.

Now we’re cooking with gas. I’m not sure what it does with long content – I was creating very short articles so I don’t know how well the system reduces front page content; I’m not yet sure how to use the taxonomies. But the site works – theoretically I could create a prettier (i.e., more busy) theme and publish a real, live site with PencilBlue – and it wasn’t even difficult to do.

You may be wondering where this magic site is; after all, resolves, but doesn’t necessarily work. This is not PencilBlue’s fault, at all; it’s because the VPS I use has limited resources, and it just doesn’t have the horsepower to keep everything up at the same time. I had to choose between applications; DeveloperStorm, being a simple demonstration site, just didn’t have enough priority for me to allocate resources. If I find a different container to run it on, I’ll point the IP there.

PencilBlue on Fedora 20

Tom Callaway (spot) mentioned a company local to the Raleigh area, publishing an open source CMS, called PencilBlue. PencilBlue is written with Node.js, a server environment leveraging Javascript.

You might wonder why I’m even considering trying a different platform. After all, I’m already a user of WordPress; I also work for a company that produces some killer middleware (that actually has commercial support).

Well, there are a few reasons why I’d be interested in kicking PencilBlue’s tires:

  • WordPress works, but as a CMS it’s somewhat lacking. Plus, it’s PHP – and I feel dirty even typing that. I have to admit, I like WordPress’ ecosystem; that’s why I use it in the first place… but I’m always hunting for the next thing.
  • WildFly is awesome; I really like working with it, and unlike Glassfish, you’re not hoping that Oracle will continue to support it. (Hint: they probably won’t, because Glassfish eats users from their cash cows. This is my opinion only.) However…
    • My VPS isn’t all that large, and while WildFly’s pretty light, it’s still going to be heavy for the virtual server I’m using.
    • The list of WildFly features my websites use is… very small. Not enough to justify the deployment on a public website for me. Your websites – especially if they’re not hobbyist things like mine – would not have this consideration; it’d likely be worth it for you to use WildFly.
  • I like to try new things – and PencilBlue gives me a chance to dip my toes in Node.js’ waters as well as checking out a new open source product. (Because open source is a Good Thing, you know?)

Installation of PencilBlue was very straightforward, with three steps:

Install PencilBlue

Open up a console on Fedora, and use the following commands:

sudo yum install npm nodejs git mongodb-server
sudo systemctl enable mongodb
sudo systemctl start mongodb

This installs git, Node.js, and MongoDB, and starts a MongoDB instance.

Change to where you want to install the application – let’s say /srv/develop/ for my test instance – and check out the PencilBlue repository; then let’s have Node.js install PencilBlue’s dependencies.

su - # change to a user with write access
mkdir /srv # if it doesn't already exist
cd /srv
mkdir logs
git clone develop
chown -R apache:apache /srv/*
cd develop
npm install
cp sample.config.json config.json

We’ll want to edit that config.json file: it has a value for "siteRoot" that we’ll want to change to our actual host, so I set the line to this:

"siteRoot": "",

We also might want to change the site port or otherwise firewall it off.

We actually have a site that we can use at this point, but we’re relying on manual startup and we can’t actually reach the system without specifying the (to-be-closed) port. What we need to do now is configure systemd to start our application automatically, and then configure nginx to forward to our application.

Configure systemd

systemd is how Fedora manages system services; what we need to do is write the service, and then tell systemd to manage it for us. (We already did this for MongoDB, when we prepared our system for PencilBlue; what we’re going to do is write the part that tells systemd how to manage our installation.)

It’s really simplicity itself. What I did was created a file, /usr/lib/systemd/system/developerstorm.service with the following contents:

ExecStart=/bin/node /srv/develop/pencilblue.js


I have nginx configured to run with the apache user and group; I made sure to set the directory ownership to apache, when I installed the PencilBlue app.

Believe it or not, we’re actually ready to start our application (and make sure it’s restarted if the server should reboot):

sudo systemctl enable developerstorm
sudo systemctl start developerstorm

If we haven’t closed off port 8080 to external access, we should be able to hit the application at this point.

Want to block port 8080? In Linux, use the following commands to block 8080 from external addresses while allowing the port forwarding to work:

sudo iptables -A INPUT -p tcp --dport 8080 -s -j ACCEPT
sudo iptables -A INPUT -p tcp --destination-port 8080 -j DROP
sudo service iptables save

Configure nginx

At last, it’s time to actually set up our site. First, let’s look at the site configuration file, which I have as /etc/nginx/sites-available/develop.local:

server {
    access_log /srv/develop/logs/access.log;
    error_log /srv/develop/logs/error.log;
    root /srv/www/develop/public_html;
    location / {
        proxy_pass http://localhost:8080/;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

I then linked this file to another configuration directory:

sudo mkdir /etc/nginx/sites-enabled # if it doesn't exist
sudo ln -s /etc/nginx/sites-available/develop.local /etc/nginx/sites-enabled/develop.local

Lastly, I altered /etc/nginx/conf. Look for include /etc/nginx/conf.d/*.conf; and add a line:

# Load modular configuration files from the /etc/nginx/conf.d directory.
# See
# for more information.
include /etc/nginx/conf.d/*.conf;
include /etc/nginx/sites-enabled/*;

After we’ve done that, all we need to do is restart nginx:

sudo systemctl restart nginx

And we’re done! We should be able to hit our url (in my case,, set up our initial user, and start playing with PencilBlue.

I haven’t actually done anything with it yet – as of this writing, if you go to that URL it gives you a blank site – but it’s installed and running. Next I’ll see how it manages content.

Important Note

For one thing, the names and details have been changed – this setup works, but it’s not entirely secure or trustworthy. I’ll work on hardening it – this was mostly to get a server up and running to try it out.

Rocket Java: Using different test resources in a single build

What happens when you have tests that need different resources with similar names?

Confusion, that’s what. Let’s map out a project so we can see what happens:

  • Parent Project
    • Test Resources 1
    • Test Resources 2
    • Library Code (depends on both test resources projects)

Now, in our problem code, the resources for the test data use the same names, so the library code won’t be able to deterministically work out which set of data is being used.

How does one work around this?

The first, and probably best, solution is to use a different build tool, one that gives more finely-grained control over the build lifecycle: Gradle comes to mind.

The other solution involves a little more work, and probably would be classified as a Maven hack.

What you would do is fairly simple, but verbose; you’d add two more projects, as integrations for the library and the dependencies, like so:

  • Parent project
    • Test Resources 1
    • Test Resources 2
    • Library Code
    • Integration Tests 1 (using Library Code and Test Resources 1)
    • Integration Tests 2 (using Library Code and Test Resources 2)

The problem with this kind of structure is that the Library Code project no longer has its own complete test structure; it can pass all of its own internal tests, without actually passing the integration tests, because those are in separate modules. Therefore, one might be tempted to write off failures in the integration test modules, and publish a flawed artifact to a central repository.

Again, the best approach is probably Gradle.

Rocket Java: Shadowing private variables in subclasses

This morning, a user on ##java asked if private variables could be shadowed in subclasses.

Upon being asked to try it and see, the user said that they didn’t have the time, which was ironic (and wrong), but errr… what the heck, I’ll write a test case to demonstrate that no, shadowing private variables (and retaining their reference) was not workable: the superclass will use its own reference, not a subclass’.

So let’s see some code:

public class T {
    private boolean b=true;

    public void doSomething() {

    public static void main(String[] args) {
        T t=new U();

class U extends T {
    private boolean b=false;

Upon execution, this outputs true.

Now, would this change if we used an accessor instead? Let’s add one to T:

public boolean getB() { return this.b;}

… and nope, nothing changes. The main point here is actually that shadowing fields like this (shadowing the actual field, not methods) is a Bad Idea, and doesn’t work, private or not. (If you change the visibility away from private, the result still doesn’t change.

What’s more, you generally don’t want to do it, and wouldn’t want to even if it were possible, because … what would be your point? You’d be effectively trying to change the semantic of the field, if you needed to do this – and this alters the superclass/subclass relationship in fundamentally unhealthy ways.

If you need a different value in the field you want to shadow, don’t shadow – just offer a protected mutator, and have the subclass set the value.