ShrimpWorks

(Re-)Introducing ZOMB, an IRC bot back-end, which I planned, started work on some years ago, then promptly lost interest after it became vagely usable.

The general idea of ZOMB (like “zomg”, but it’s a bot, not a god [maybe version 3], and it sounds like “zombie” which is cool too) is to provide a client interface-independent bot framework, where bot functionality can be implemented in remotely hosted plugin scripts/applications, unlike a traditional bot where normally you’d need all the code running on one user’s machine/server.

Being interface-independent means a ZOMB client (the thing a user will use to interact with ZOMB) may be an IRC bot, a CLI application, or a web page. Since I’ve been less active on IRC than I’d like lately, the additional options would be useful to me personally, but since almost nobody uses IRC at all any more, ZOMB should hopefully be useful outside of that context.

So how does ZOMB work? From a user’s point of view, it’s exactly like a traditional bot - you issue a query consisiting of the plugin you want to execute, the command to call, along with command arguments. For example, you’d ask a ZOMB bot:

> weather current johannesburg

Where “weather” is the plugin, “current” is a command provided by the weather plugin, and “johannesburg” is an argument. In response to this, ZOMB would provide you a short text result, something like this:

> The weather in Johannesburg is currently 22 degrees and partly cloudy

In the background, ZOMB looked at the input, found that it knew of the “weather” plugin, and made an HTTP request to the remote plugin service passing the command and arguments along. The plugin then did what it needed to do to resolve the current weather conditions for Johannesburg, and returned a result, which ZOMB in turn returned to the requesting client.

As always, a new project provides some practice/learning opportunities:

• API driven development I know what I want ZOMB to be able to to, so I began by defining the client and plugin APIs, around which the rest of the design must fit. I normally write a bunch of code, then stick an API on top of it, but trying it the other way around this time. Seems to be working.
• Test driven development just to keep practicing :-)
• Git and Github since we’re hopefully going to be using Git at work in the near future, best to get some practice in.
• Custom Ant and Ivy build scripts I like Ant and Ivy and need to practice configuring and maintaining them from scratch.
• Travis-CI continuous integration for Github projects, since it’s cool to have a green light somewhere showing that stuff’s not broken, and I’ve never used any CI stuff outside of work.
• More granular commits committing smaller changes more often - I don’t know if this is a good thing or not, but seeing how it works out
• All on Windows I haven’t really built a proper project on Windows for years :D

After reading a lot of rants and essays about developers, their working environments, tools, the process of getting their work done (in relation to “the business” side of things), and career opportunities, I find myself wondering; do we just whine too much about it all, or do we really have to put up with so much more crap than other industries or professions?

Do we suffer from an inflated sense of entitlement - did we (and are expected to continue to) study, learn and practice for years only to end up like battery chickens, churning out code, or are we “deserving” of extra perks, privileges and financial reward?

Yes, developers are almost entirely responsible for every cent made (and even more so for every loss!) in almost every industry these days, and in most cases, I really don’t believe they get the credit they deserve (new product launched, management team praised and treated to expensive outing, golf day, or conference to show it off while we are at work hacking on the Next Big Thing). But we’re not alone in our suffering and expectations of better things.

Somewhere there’s the Accounting Drone capturing all the cents made possible by the developers. The Accounting Drone also has a shitty manager who expects them to capture more cents every day, under shitty conditions with just as shitty deadlines, for very poor pay. This guy’s job security is also near non-existent. Nobody capturing all the cents means us whiny developers don’t get paid. Maybe there are some rants and essays about the unreasonable conditions and tools the Accounting Drone must endure.

Elsewhere, there is the Sales Bro. Generally the bane of every developer’s life (worse than project managers!). It’s all very well for us to come up with the latest and greatest version of Thing2000 the world has ever seen, but I personally do not know a single developer who would be capable of selling Thing2000 on their own. Yes, we’ll all be highly indigent when Sales Bro “sells” Thing2000 Feature X before it exists, but at least someone out there actually knew Thing2000 existed and (hopefully) needs it to have Feature X (and is thus generating revenue for Accounting Drone to count and pay us with). I’m sure Sales Bro also has a blog where he complains about how he can never get his job done because developers are always so slow and uncooperative in delivering new things his customers need.

Let’s not forget Support Pleb, who has to suffer through customers rants and idiocy, while finding creative ways around developers shortcomings. I’m fairly confident a very large percentage of issues Support Pleb has to deal with day-to-day could be resolved by a bit of development time. This guy puts up with a huge amount of shit that would otherwise fall directly on developers, again, for crappy pay and non-existent job security. I’m pretty sure Support Pleb bitterly resents those developer slackers who always seem to be making more work for him, yet scatter like ants when problems are brought to their attention.

Finally we also have to have the Big Wig at the top somewhere. Those unreasonable people who are always hiring newbs and firing us, placing us in uncomfortable office environments, not shelling out for the tools we need, and dictating unreasonable deadlines. Again, unfortunately, I do not know a single developer capable of establishing and running a business the way Big Wig does. Big Wig possibly posts internet rants about how all he wants is for his Accounting Drones, Sales Bros, Support Plebs and developers to make more money for him - and doesn’t find that an unreasonable expectation, since he’s established and ensures the continuity the enterprise paying all their salaries.

So, are developer rants and whines about how bad they have it justified? For the most part, I’m going to have to say no. I’m also going to hazard that most of the problems developers face, in terms of unreasonable expectations, poor tools, lack of recognition, are not a result of simply being in software development as a profession, but are the result of poor management (at various levels of an organization), and are in fact faced by most other professions as well. We’re just more comfortable getting behind a keyboard and dumping our thoughts on the internet :).

TL;DR: As much as we like to think we might be, we’re not the be-all and end-all of our place of employment, and find a job at a company that makes you happy(-er).

Some thing I’ve been using for a while, and which recently became useful at work as well, is a simple HTTP service written in plain Java with existing JRE functionality, using an HttpServer.

Here’s a simple “main()” which sets up two basic “pages”, a root (/) and one which echoes your browser’s request headers (/headers/).

public class SimpleHTTPService {

    public static void main(String[] args) throws IOException {
        HttpServer server = HttpServerProvider.provider().createHttpServer(new InetSocketAddress(8080), 0);

        server.createContext("/", new HttpHandler() {
            @Override
            public void handle(HttpExchange he) throws IOException {
                byte[] output = "Hello world!".getBytes();
                he.sendResponseHeaders(200, output.length);
                he.getResponseBody().write(output);
            }
        });

        server.createContext("/headers", new HttpHandler() {
            @Override
            public void handle(HttpExchange he) throws IOException {
                StringBuilder result = new StringBuilder("Request Headers");
                for (Entry< String, List< String>> header : he.getRequestHeaders().entrySet()) {
                    result.append(String.format("%s", header.getKey()));
                    for (String val : header.getValue()) {
                        result.append(String.format("%s", val));
                    }
                    result.append("");
                }

                byte[] output = result.toString().getBytes();
                he.sendResponseHeaders(200, output.length);
                he.getResponseBody().write(output);
            }
        });

        server.setExecutor(Executors.newCachedThreadPool());

        server.start();

        System.out.println("HTTP Listening on port " + server.getAddress().getPort());
    }
}

Running this as-is will allow you to load up the URLs http://localhost:8080/ and http://localhost:8080/headers/ and see some output generated by the two registered contexts.

I’ve defined simple anonymous inner class contexts here, as it’s easy to play with, but obviously you can go wild and develop proper structures for these.

Combined with something like FreeMarker, and you’ve got a pretty neat way to deploy simple stand-alone HTTP applications written in Java with minimal external dependencies.

It’s also extremely useful for creating mock-ups services for use in unit tests for HTTP clients.

Here’s a small Java class I’ve been using in loads of applications and things for a few years (it’s evolved a little over the years).

It simply exposes a few very basic HTTP methods (for HEAD, GET and POST) which all just return strings containing the web server’s response. It’s seemed pretty useful and reliable in applications large and small, so maybe it’s of some use to someone else as well.

Download HttpUtils

Things have been very quiet on the code front lately, with bursts of activity here and there.

Primarily, I’ve been hacking on Out of Eve. The structure API classes and implementation of the API requests has been bugging me, especially when I’ve had to add a lot of stuff in recent versions, it just grows and grows and becomes unmanageable. Unfortunately fixing it has obviously resulted in breaking every single piece of the application, which I’ve been slowly refactoring and putting back together slightly more sensibly.

On the other hand it’s also a good opportunity to make allowance for the new customisable API key features CCP are implementing.

Besides that, my totally rad completely unique super secret Java-powered website project is stalled. Java’s turned out to be a bit of a pain in the backside. Sure all the background code is nice and stuff, but actually making the website portion of stuff quite sucks. I suspect this project will also need a near complete refactor at some point… Sigh. Coming soon in 2019!

Happy days. Now fully “Incursion” compatible.

Coming soon is updated API support (mail, taxes), and hopefully some more handy plugins :).

This is just a small update on the status of OOE. As the SVN server previously hosting the OOE source died, and many people have been looking for the source, a Google Code project has been started to facilitate future development.

The source is available as both a regular download and via Subversion.

It’s unlikely I will be doing any development on the project myself, however contributors are welcome.

Hah. Only 3 months late.

Out of Eve has been fully updated to Quantum Rise spec, the promised journal feeds, API key security, and a number of other tweaks. OutofEve.com has been updated to the latest available version, and the source is available for download.

Please leave any feedback in the comments of this post. I’ll set up a proper OOE page on this site at some point, with download links and more detailed information.

Well, shit happens, and unfortunately OOE 1.1 hasn’t as I’d planned. I HOPE to be able to have this going by next week….

I’ve wanted something to make browsing through largish JSON objects a bit easier for work for a long while now, and suddenly got the idea that 01:00 on Saturday morning would be a good time to create such an application.

The result is the rather simple but effective JSON Explorer.

As mentioned previously, I just wanted to outline a few plans for a new Out Of Eve version, mostly for my own reference, as I’m finding it much easier to work toward goals which are actually written down/typed up (lol?).

Obviously first order of business is Empyrean Age compatibility. A number of table and field names have changed and require some code updates. Lots of icons have been added and updated, so I would also like to make use of those. Unfortunately a number of images are actually missing in the EA icon dump (drones, rookie ships), so a simple drop-in replacement doesn’t works so well.

Another essential requirement, which should probably have been included in the original release, is encrypted API keys. My plan is to simply encrypt and decrypt these with a simple key file stored elsewhere in the filesystem - away from the usual configuration file, database and published www documents, so if any of that is compromised, without the key file, the API keys are useless to anyone snooping them. This also requires a method to automatically update existing unencrypted API keys.

Another handy feature would be the introduction of Atom feeds for market and journal transactions. My initial idea was an entry for each new transaction, however anyone doing a lot of trading would find their feed reader overloaded quite quickly. The obviously better solution is to just generate entries with all transactions since the last feed poll (taking into account API caching delays as well). I know I’d find this one particularly useful.

Actually that’s all :-). If all goes well, it should be releasable by the end of the weekend.