Toolkit overview

Llaith-Toolkit Project

Llaith's personal toolkit library.

toolkit-core:

Core toolkit classes. Mostly architectural patterns.

org.llaith.toolkit.core.controller:

    Architectural pattern used for implementing views as a
    collection of stacks of controllers that can reject calls to
    dispose themselves. This pattern can represent portal interfaces,
    desktop-like interfaces, and breadcrumb based pages in the same
    way.

org.llaith.toolkit.core.dto:

    A DTO implementation. Dtos have change tracking, a pseudo-type,
    can be nested and support merging values with an origin. On top
    of that there is a more experimental session system which uses a
    stack of collections of Dtos which can push their changes down
    to other Dtos in obscured layers. This is used to minimise
    refreshing in rich guis. Also includes a fluent building mechanism.

org.llaith.toolkit.core.fault:
    Faults are a replacement for simply throwing exceptions. They
    work similar to compiler warnings/errors for use in complex cases
    where one wants to collect errors but continue as far as is
    practical despite failures. They also have the concept of supressing
    errors to allow code that performs validation to be as strict as
    possible and let the caller decide what consitutes a real error
    in that case.

org.llaith.toolkit.core.memo:
    Memos are used for structured text output. They support a common
    subset of output that can be displayed on consoles, but still
    support reasonable structure in html.

org.llaith.toolkit.core.pump:
    A pipes and filters implementation. It is implemented via
    decorators. Supports push and pull and instead of using events
    or additional methods on the interface (such as isOpen()). A stream
    may be converted to and from 'chunks' by the implementation, and a
    robust (can throw errors without closing) and polling (can return
    nothing without closing) approach is supported by returning empty
    chunks to signify no current work on an open source.

org.llaith.toolkit.core.registry:
    A simple registry pattern. Used for type-safe registration of
    implementors of a service interface.

org.llaith.toolkit.core.stage:
    An implementation of a set of queues of commands patterns to be
    executed in a controlled manner. Used heavily in batch processing
    codebases. Supports a fluent approach to building. Uses decorators
    to determine if raised exceptions are to cause a failure or a skip.

org.llaith.toolkit.core.status:
    A display abstraction that supports both console and web/desktop
    gui outputters. Particularly useful with used with either the
    stage or the pump implementations.

toolkit-common:

    Utilities and miscellanious helper/convienence classes. For the most
    part these stand alone and do not deal with any architectural concerns.

org.llaith.toolkit.common.depends:
    A dependency calculator. Calculates reverse dependencies from
    normal dependencies. Pretty clunky and badly needs a refactor but
    does the job for what I used it for (reverse dependencies of
    class heirarchies)

org.llaith.toolkit.common.contrib:
    Stuff written by other without a license/in the public domain.
    Tends to ebb and flow but at the moment contains a great tuples
    implementation found on stack-overflow.

org.llaith.toolkit.common.debug:
    Misc debug utils with norwhere else to live. At the moment has
    a couple of reflection based utils.

org.llaith.toolkit.common.exception:
    Some exception handling utils. This used to be very stable and
    heavily used in my code but over the years Guava started
    containing utils to do the same thing and this was cut down and
    adapter to a few more experimental and less useful leftovers.
    Also contains some common exceptions used throughout my codebase
    like the 'WhoopsException'.

org.llaith.toolkit.common.guard:
    A preconditions utility. Most of the functionality has been
    subsumed with recent versions of Guava, and so now has only a more
    experimental fluent approach based on hamcrest. Use where clarity
    more important than performance, else use the Guava or JDK equivs.

org.llaith.toolkit.common.guava:
    A few common implementations of guava interfaces, including a
    simple bridge between hamcrest matchers and guava predicates.

org.llaith.toolkit.common.ident:
    Used for modules to 'identify' themselves by supplying a more
    human-readable name for themselves to mechanisms that have
    dynamically loaded them. Bit clunky but does the job.

org.llaith.toolkit.common.intention:
    Contains a set of annotations which are used to indicate the
    programmers intentions for a peice of code. Currently I have
    pulled most of these out because they work in tandom with the
    pluggable compiler annotations support which I have not included
    in this current release. I have left the maturity one because
    that is still a good warning without the annotation processor.
    (The annotation processor in this case just emits warnings when
    it finds code marked with a maturity level below release).

org.llaith.toolkit.common.lang:
    A bunch of utils that deal with core SDK classes. Always
    shrinking as Guava grows :)

org.llaith.toolkit.common.meta:
    A metadata implementation that I use heavily when implementing
    meta-models that are shared between modules. Simple but very
    useful.

org.llaith.toolkit.common.pattern:
    A few left over patterns that are too simple to end up in the
    toolkit-core library. Activities, Resources and Commands are
    commonly used in my other codebases.

org.llaith.toolkit.common.snapshot:
    A versioning mechanism I have used for some cases where models
    support partial versioning.

org.llaith.toolkit.common.util:
    Utilities are generally classes made up of purely static functions.

org.llaith.toolkit.common.util.jdbc:
    The only bit still left here is a simple SQLException util. All
    other utils have gone away and been replaced with better 3rd
    party libraries such as sql2o.

org.llaith.toolkit.common.util.lang:
    A few utils for core SDK classes. Some equivalents to Guava or
    common-utils where it would be pointless to bring in a dependency
    for a simle function (like blank string checking).

org.llaith.toolkit.common.util.reflection:
    I do a great deal of work with reflection. Here are some useful
    general utils for helping with that. Like most reflection code,
    it's not pretty. For more complex reflection work I recommend
    something like vidageek-mirror library.

toolkit-dbadapter:

    Adapters for using specific 3rd party dependencies with the
    toolkit-core patterns.

Rationale for name change.

This blog is inspired by the article 'The Ghost Who Codes':

http://www.troyhunt.com/2013/02/the-ghost-who-codes-how-anonymity-is.html

I realized that I am probably one of his 'ghosts who codes'. However, while there are many reasons why such a categorization is unfair to those like myself (and I will indulge myself to present a quick counter-argument here), I also realize that the best way to deal with the situation is just to go along with the crowd, and that's what this blog is for. I believe the intentions of the author's piece are to help those like myself, and I would be remiss to not take it as a kick on the pants! ;)

Firstly, however, I want to make a quick counter-argument. Off the top of my head, I can think of several reasons why someone (such as myself) may be 'A Ghost Who Codes'.

1) Different kind of coder from a different era:

There are many reasons why a developer may seem like one of the 'ghosts' from the article. Firstly, it should not have escaped anyone's attention that it's a different generation of coders who are making up the majority of the community noise.

I became a software engineer when it was still mostly termed 'computer programmer' and the next career steps where 'analyst-programmer' then 'systems analyst' at the top. This was before the dot-com era, where computing was taught in the school of maths, before the internet really existed (we used to run SLiP in terminal sessions with modems to access Gopher and Newsgroups and large commercial providers has 10-20 concurrent connections to the internet available for customers).

Needless to say, before the dot-com era, it wasn't cool to be a software engineer, it wasn't known for attracting high salaries, and it certainly didn't attract the sort of person that thrives today who has strength in various forms of social networking and blogging about their achievements. And although this may seem harsh, a lot of us retreated in general from the first era of online Q&A forums such as MSDN and Javalobby v1, became grounds for endless flame-wars from developers with more energy to share their opinions than to consider them carefully ;)

My peers and friends from the companies I have worked at mostly share this trait, being possessed of a high level of technical ability rather than social. That's not to say that they don't communicate effectively however, on the contrary, communicating solutions technically to business users via high quality formal business communications is usually something that our generation does very well, but it's not the same sort of skill as you need to create an engaging blog.

2) Hostile corporate environment:

Despite the idea that good developers contribute to open source in their free time, I've yet to see it any significant contributions made like that. While developers may *say* they are doing it in their free time, those that do so usually do it with the sanction of their employer.

Unfortunately, not all employers are ideal in that regard. Many are frightened of the legal issues around open source, such as financial institutions, and many are hostile to the idea that an employee is spending his time on matters not directly related to solving the task at hand and moving on to the next one.

In some cases, such as in the UK, the existence of a full time employment contract gives your employer more rights than would seem obvious, including certain rights to work you would do in your free time if it can be seen as even tangentially related to your day job. It is for this reason that 'moonlighting' is seen as problematic for employers in the UK. In such an environment, it is rational to be as discrete as possible about any open-source or commercial side efforts, if not to avoid being involved altogether.

3) commercial side projects instead of open source ones:

Sometimes a persons side projects are also commercial. Whether that is freelancing in your free time, working on a start-up, or making apps for mobile platforms. Obviously, blogging about these is often not possible.


***

As I mentioned previously, it's usually easier to go along with the flow than to fight it, especially when the flow is in the right direction in the first place. In my case the only practical option, as I am bound by commercial constraints, is to try to do the following in this blog.

1) I will be going over many of my smaller projects that can be shared, particularly collections of utils, and extracting them into a libraries that I can share. The first of these is the one I have named 'toolkit' and is up on github.

2) I will be discussing in general terms many of the other projects I am or have worked on, although I will not be able to share code from these projects, I will try to illustrate a concept with a code snippet where possible. You will have to forgive me for not being able to offer more.

However, because all of this is literally in my hour of free time a day (I am a father of two young children, one of whom is on the spectrum) you will have to forgive me for being terse and to the point when I post.

Originally, I set up two blogs, shortly before becoming a father (and not realising what that would entail!) One for blogging my personal and generally ranty opinions ('And Other Curious Things'), and the second for a project of explaining what I thought was the prevailing ail in software development which was a lack of understanding about how to do good software *design*. That blog ('The Art of Heresy')was not going to steer away from controversy. However, that idea turned out to be rather ambitious considering my new status as a family-man. I still intend to do the blog about design, but for now I will be adding this blog ('The Ghost Who Codes') to go through my existing code and explain briefly my design choices, and this will take the majority of my energy for the time being.