Clojure eXchange: Call for Papers

CLOJURE14

The Call for Papers is now open for the 2014 Clojure eXchange

Now entering it’s 4th year, the annual Clojure eXchange brings together experts and enthusiasts from the world of Clojure to explore one of the fastest growing functional languages.

This is not just an opportunity to come and listen to experts for 2-days, but a chance to fully immerse yourself in all things Clojure – and we’re looking for passionate, talented and brilliant Clojure virtuoso’s to join our line-up.

As with our other conferences, we aim to have between 25-50% of talks targeting newcomers to Clojure, Lisp and the JVM. The types of talks we’re looking for include:

  • Clojure in startups
  • Clojure in enterprise
  • embedded projects
  • experience reports
  • robots, art, music, humanities, games, social science…

You can choose to either present a full-length 40 minute talk, or go for a shorter 10 minute lightning presentation. Talks don’t necessarily have to be about Clojure, but must be interesting to Clojurians!

If this sounds like you, head over to the CfP page now. If you have any questions then please contact us clojurex@skillsmatter.com.

The CfP will close on Friday 31st October, and successful presenters will be contacted by the week commencing 10th November.

One Model In, One Model Out

jimmy-bogard-skills-matter-blog

This is a guest post from Jimmy Bogard, a member of the ASPInsiders group, the C# Insiders group, as well as being the “Microsoft Most Valuable Professional” (MVP) for ASP.NET since 2009. He is also the creator and lead developer of the popular OSS library AutoMapper.

Jimmy will be speaking at Skills Matter on 3rd September at his In the Brain talk on Object-Relational Mapper’s. The talk will look at application patterns, ORM features and more to show the correct way of using your ORM, and when to ditch your heavyweight ORM and reach for a lighter one. You can register for this free talk here.

In this post, Jimmy discusses mediator patterns, and how we can use them to ensure that our behaviours become less driven by a framework – allowing us to focus on the real work being done.


In most of the projects I’ve worked on in the last several years, I’ve put in place a mediator to manage the delivery of messages to handlers. I’ve covered the motivation behind such a pattern in the past, where it works well and where it doesn’t.

One of the advantages behind the mediator pattern is that it allows the application code to define a pipeline of activities for requests, as opposed to embedding this pipeline in other frameworks such as Rails, node.js, ASP.NET Web API and so on. These frameworks have many other concerns going on besides the very simple “one model in, one model out” pattern that so greatly simplifies conceptualizing the system and realizing more powerful patterns.

As a review, a mediator encapsulates how a series of objects interact. Our mediator looks like:

public interface IMediator
{
    TResponse Send(IRequest request);
    Task SendAsync(IAsyncRequest request);
    void Publish<TNotification>(TNotification notification) where TNotification : INotification;
    Task PublishAsync<TNotification>(TNotification notification) where TNotification : IAsyncNotification;
}

This is from a simple library (MediatR) I created (and borrowed heavily from others) that enables basic message passing. It facilitates loose coupling between how a series of objects interact. And like many OO patterns, it exists because of missing features in the language. In other functional languages, passing messages to handlers is accomplished with features like pattern matching.

Our handler interface represents the ability to take an input, perform work, and return some output:

public interface IRequestHandlerTRequest, out TResponse>
    where TRequest : IRequest
{
    TResponse Handle(TRequest message);
}

With this simple pattern, we encapsulate the work being done to transform input to output in a single method. Any complexities around this work are encapsulated, and any refactorings are isolated to this one method. As systems become more complex, isolating side-effects becomes critical for maintaining overall speed of delivery and minimizing risk.

We still have the need for cross-cutting concerns, and we’d rather not pollute our handlers with this work.

These surrounding behaviours become implementations of the decorator pattern. Since we have a uniform interface of inputs and outputs, building decorators around cross-cutting concerns becomes trivial.

Pre- and post-request handlers

One common request I see is to do work on the requests coming in, or post-process the request on the way out. We can define some interfaces around this:

public interface IPreRequestHandlerTRequest> {
    void Handle(TRequest request);
}
public interface IPostRequestHandlerTRequest, in TResponse> {
    void Handle(TRequest request, TResponse response);
}

With this, we can modify inputs before they arrive to the main handler or modify responses on the way out.

In order to execute these handlers, we just need to define a decorator around our main handler:

public class MediatorPipeline<TRequest, TResponse>
    : IRequestHandler<TRequest, TResponse>
    where TRequest : IRequest {

    private readonly IRequestHandler<trequest, tresponse=""> _inner;
    private readonly IPreRequestHandler[] _preRequestHandlers;
    private readonly IPostRequestHandler<trequest, tresponse="">[] _postRequestHandlers;

    public MediatorPipeline(
        IRequestHandler<TRequest, TResponse> inner,
        IPreRequestHandler<TRequest>[] preRequestHandlers,
        IPostRequestHandler<TRequest, TResponse>[] postRequestHandlers
        ) {
        _inner = inner;
        _preRequestHandlers = preRequestHandlers;
        _postRequestHandlers = postRequestHandlers;
    }

    public TResponse Handle(TRequest message) {

        foreach (var preRequestHandler in _preRequestHandlers) {
            preRequestHandler.Handle(message);
        }

        var result = _inner.Handle(message);

        foreach (var postRequestHandler in _postRequestHandlers) {
            postRequestHandler.Handle(message, result);
        }

        return result;
    }
}

And if we’re using a modern IoC container (StructureMap in this case), registering our decorator is as simple as:

cfg.For(typeof (IRequestHandler<,>))
   .DecorateAllWith(typeof (MediatorPipeline<,>));

When our mediator builds out the handler, it delegates to our container to do so. Our container builds the inner handler, then surrounds the handler with additional work. If this seems familiar, many modern web frameworks like koa include a similar construct using continuation passing to define a pipeline for requests. However, since our pipeline is defined in our application layer, we don’t have to deal with things like HTTP headers, content negotiation and so on.

Validation

Most validation frameworks I use validate against a type, whether it’s validation with attributes or delegated validation to a handler. With Fluent Validation, we get a very simple interface representing validating an input:

public interface IValidator<in T> {
    ValidationResult Validate(T instance);
}

Fluent Validation defines base classes for validators for a variety of scenarios:

public class CreateCustomerValidator: AbstractValidator {
  public CreateCustomerValidator() {
    RuleFor(customer => customer.Surname).NotEmpty();
    RuleFor(customer => customer.Forename).NotEmpty().WithMessage("Please specify a first name");
    RuleFor(customer => customer.Discount).NotEqual(0).When(customer => customer.HasDiscount);
    RuleFor(customer => customer.Address).Length(20, 250);
    RuleFor(customer => customer.Postcode).Must(BeAValidPostcode).WithMessage("Please specify a valid postcode");
  }

  private bool BeAValidPostcode(string postcode) {
    // custom postcode validating logic goes here
  }
}

We can then plug our validation to the pipeline as occurring before the main work to be done:

public class ValidatorHandler<TRequest, TResponse>
    : IRequestHandler<TRequest, TResponse>
    where TRequest : IRequest {

    private readonly IRequestHandler<trequest, tresponse=""> _inner;
    private readonly IValidator[] _validators;
    
    public ValidatorHandler(IRequestHandler<trequest, tresponse=""> inner,
        IValidator[] validators) {
        _inner = inner;
        _validators = validators;
    }

   public TResponse Handle(TRequest request) {
        var context = new ValidationContext(message);

        var failures = _validators
            .Select(v => v.Validate(context))
            .SelectMany(result => result.Errors)
            .Where(f => f != null)
            .ToList();

        if (failures.Any())
            throw new ValidationException(failures);

        return _inner.Handle(request);
   }
}

In our validation handler, we perform validation against Fluent Validation by loading up all of the matching validators. Because we have generic variance in C#, we can rely on the container to inject all validators for all matching types (base classes and interfaces). Having validators around messages means we can remove validation from our entities, and into contextual actions from a task-oriented UI.

Framework-less pipeline

We can now push a number of concerns into our application code instead of embedded as framework extensions. This includes things like:

  • Validation
  • Pre/post processing
  • Authorization
  • Logging
  • Auditing
  • Event dispatching
  • Notifications
  • Unit of work/transactions

Pretty much anything you’d consider to use a Filter in ASP.NET or Rails that’s more concerned with application-level behaviour and not framework/transport specific concerns would work as a decorator in our handlers.

Once we have this approach set up, we can define our application pipeline as a series of decorators around handlers:

var handlerType = cfg.For(typeof (IRequestHandler<,>));

handlerType.DecorateAllWith(typeof (LoggingHandler<,>));
handlerType.DecorateAllWith(typeof (AuthorizationHandler<,>));
handlerType.DecorateAllWith(typeof (ValidatorHandler<,>));
handlerType.DecorateAllWith(typeof (PipelineHandler<,>));

Since this code is not dependent on frameworks or HTTP requests, it’s easy for us to build up a request, send it through the pipeline, and verify a response:

var handler = container.GetInstance<IHandler<CreateCustomer>>();

var request = new CreateCustomer {
    Name = "Bob"
};

var response = handler.Handle(request);

response.CreatedCustomer.Name.ShouldBe(request.Name);

Or if we just want one handler, we can test that one implementation in isolation, it’s really up to us.

By focusing on a uniform interface of one model in, one model out, we can define a series of patterns on top of that single interface for a variety of cross-cutting concerns. Our behaviours become less coupled on a framework and more focused on the real work being done.

All of this would be a bit easier if the underlying language supported this behaviour. Since many don’t, we rely instead of translating these functional paradigms to OO patterns with IoC containers containing our glue.


In the Brain of Jimmy Bogard: ORMs – You’re Doing it Wrong

On 3rd September, Jimmy discusses Object-Relational Mapper’s at Skills Matter HQ. If you want to make your DBA (and your users happy), you’ll want to use your ORM intelligently – come along to find out how!

Register for your free ticket now!

While It’s Compiling: Skills Matter interviews Karolina Szczur

Karolina Szczur is a designer and developer at &yet and contributes to various open source projects such as NodeCopter, AmpersandJS and Otalk.

We caught up with Karolina ahead of her talk at Fullstack: The Node and JavaScript Conference where she will be looking at up-to-date front-end tooling and analysing alternative approaches to compiling, building and automation processes. Here she gives us an insight into her talk topic, the iterative nature of design and her views and thoughts on the Open Source community.

karolina-szczur


Your recent work includes roles such as the UX Lead at Nodejitsu, writer and editor at Smashing Magazine for the mobile, coding & design sections, and Front-end Developer/Design Lead at XHTMLized. However, you started out doing photography, via psychology, anthropology and the history of art among other things – what first drew you towards development and design?

Honestly, I don’t recall a specific aha moment. I’ve always been drawn to art and photography—we used to have a darkroom at home when I was younger. As soon as digital photography went somewhat mainstream (or at least it became more accessible to the layperson) I started my adventure with editing in Photoshop 5 (yes, it was the 90s). That quickly led to trying to do more than adjust the colours or exposure. It was at the time when GeoCities was at its peak, so my photography passion escalated to “What if I could have a website too?”. I’d say it was rather natural curiosity and organic growth of interest in interconnected fields.

At the end of a recent article you wrote that design “is by nature an iterative process”, and that contributions from others is essential. Considering your experience in front-end design, can you take us a little further into this iterative process?

It takes an extraordinary amount of craftsmanship to create something that’s in any way timeless. Great design and front-end don’t happen instantly. Research, prototyping, implementation and testing take time. But trying to chase perfection before launching only prevents shipping. Like many designers, I’ve struggled with attempting to achieve some arbitrary ideal, but that kind of thinking doesn’t foster creativity.

Content we design for often changes, sometimes drastically. Web standards evolve. We can’t rely on predictability of either the medium or the technologies we have at hand. Working on the web’s rapidly evolving platform means our work will always be an iterative process, whether or not we choose that. There will always be something to improve or fix and we have to be ready to embrace the absolute lack of perfection.

There has been a lot of discussion lately surrounding the importance of shipping—iteration is empowering because it removes the boundaries of judgemental and perfectionist ideals. Collaboration and contributions from others take this idea even further by allowing room for constant feedback, broader perspective, and fresh ideas.

When working on a project, how do you ensure you maintain ownership whilst still benefiting from the input of others?

Ownership is essential. It doesn’t even have to be designated (“This person is the owner”). Often I see individuals stepping up as leaders. In a way, every single person involved in a certain project is an owner—they are all responsible for its execution and success. When everyone feels like that instead of irrelevant cog in a giant machine, feedback happens naturally.

Building up fearless candor and honest feedback requires zero judgmentalism and allowing others to step up. Making everyone a leader doesn’t take ownership away—it helps us to be better when working towards a mutual goal.

From a practical standpoint: ask for specific input as often as you can and enable anyone to express their opinions if they are willing to do so. Kill bikeshedding.

In your upcoming talk at FullStack you’re looking at the dangers of introducing too many tools in the development process, making everything more complex and time-intensive. How can you tell when your work-flow is as optimised as it’s going to get?

The topic of tooling is as opinionated as debating the superiority of programming languages or promises over callbacks. Automation and optimisation are crucial, both for complex, bigger projects and the small ones—they let us focus on tasks that simply cannot be automated and bring desired levels of uniformity.

The questions I like to ask myself are: Can it be faster? Can I use less tools and more natively available utilities? And last but not least—is it understandable and simple enough to empower my team members and collaborators? I believe that all tools are ultimately created to make our lives easier, thus making sure that it doesn’t introduce cognitive overhead for others is crucial. If it’s standardised, fast, reliable and comprehensible for others—I know I’m home.

It seems that a lot of this comes from the work you’ve been doing on standardisation of front-end tooling at &yet. Can you tell us a little bit more about &yet, and the work you’re doing there?

I’ve been working at &yet for over a year now—it’s been a very humbling experience that allowed me to grow both as a professional and as a person. I’ve been mostly focusing on internal projects, be it our own products or processes for optimising design and development.

In the last months I’ve been busy with a larger endeavour I like to call front-end standardisation. With a hugely multidisciplinary team, where almost everyone can code at some level, it’s important to create an environment that not only enables learning good patterns but also fosters code consistency:

“All code in any code-base should look like a single person typed it, no matter how many people contributed.”

These efforts been mostly focused on creating a code guide and pattern library in a form of small, modular CSS framework. It’s definitely a very challenging project and requires a lot of collaboration and feedback from team members. Standards work is never one person creating arbitrary rules to follow, but an collective effort for reaching consensus of optimal approaches suitable for given teams.

Next adventure? Improvements to our WebRTC-based video chat app— Talky.

&yet describes itself as an Open Web Company, and on your own website you say that you strongly believe in Open Source. What makes Open Source so important in your opinion?

Open Source was always at the core of our interests—we’re strongly involved in the Node, XMPP, WebRTC, and JavaScript communities. We support people who write and maintain libraries that we use on Gittip and we contribute and share everything we can.

It aligns perfectly with our people first approach to everything we do. After all, writing software or designing is just a means to an end. If we can enable others to make the world a better place even slightly by open sourcing our work or paying others to do so, then we will. We are building these things and working on standards for the good of all of us. If that doesn’t make open source important then I have no idea what does.

karolina-szczur-blog-post

&yet have been involved in creating a few community events themselves, and you’ve spoken at conferences such as JSConf EU, the Future of Web Design in Prague and the Frontend Conference in Zurich, amongst many others. How important is the community to the future of Open Source?

The dictionary definition of Open Source focuses on the openness and public availability of the source code. I want to go a little bit further—without people, Open Source dies. With collaboration and contributions projects flourish.

I don’t want to undermine the quality or livelihood of one-person projects (there’s plenty of those on npm) but we’ve learned the need for a community with our recent endeavour, AmpersandJS. We got quick traction and many contributors—one of them already added to the core team. One day we were debating the accessibility of the role attribute and got almost 70 comments from people deeply involved in that matter. We wouldn’t be able to improve the project and push it forward so fast without the help of the community.

Maintaining an Open Source project is a job—it takes a tremendous amount of time and, in a semi-direct way, money. Finding and even fixing bugs is so much harder without others using the software in the wild. I can’t see the future of Open Source without the community surrounding it.

Considering the conferences you’ve been involved in have taken place all over the world, do you see yourself as part of an intrinsically global community, or has your experience been that developers’ goals and missions change depending on where they are?

The idea of global community still feels a little bit like a dream to me. There are a lot of subcommunities, which on one hand is completely natural (the design community, the JavaScript community or the Ruby community) but when those communities become too exclusive and the barriers to entry become discouraging for newcomers it’s hard to talk about a global population of people involved in tech. There’s not only division in specific fields of interest or programming languages but also cultural differences—The Bay Area is so much different from the fairly small town of Kraków where I live, so I can see how priorities could shift depending on the location.

Nonetheless what I would love to see is less judgmentalism, more openness towards beginners as well as inclusivity towards people of colour, women, and other minorities, including people for whom English is not their first language. I certainly don’t feel excluded nor do I try to categorise myself as a part of a certain group, but until we all feel fairly comfortable to say that I can’t see a healthy, global community, there’s still work to do to make everyone feel welcome.


While It’s Compiling is a continuing series of interviews with experts across a range of bleeding-edge technologies and practices, exclusive to Skills Matter. Be sure to subscribe to this blog for future interviews, or follow us on Twitter.

Find out who we’ll be interviewing next, and get a chance to put your questions forward with the hashtag #whileitscompiling.

fullstack-2014-1000x150px

This Week at Skills Matter: 26 – 29 August

The Open Tech School

The Open Tech School

As you read this we assume you’re asking the same question as us – can this really be the end of summer? But don’t be gloomy (even if this was the chilliest August Bank Holiday ever recorded), we’ve got six fantastic meetups this week, from Londroid looking at moving your app interface beyond 2D to an introduction to web programming with the Open Tech School. Check them all out below!


Tuesday:

The London Android User Group join us for another fully booked talk this evening, as they discuss Holo to Material Design. This is an open discussion around one question – what if an interface wasn’t just 2D? If app developers take advantage of virtual light sources, realtime shadows and put an emphasis on clean typographic layouts with rich animated touch feedback, can they transition their beloved Holo? And if so, should they? And when!?

In anticipation of the talk, you’re also invited to share your own examples and apps using #materialdesign. Find out more and see the full agenda on the group’s page.

Also joining us tonight, the Open Tech School return for the second part of their introduction to web programming using Javascript. Be sure to bring a laptop!

Wednesday:

The Neo4j User Group bring along speaker Rik Van Bruggen – regional territory manager for Neo Technology for the BeNeLux, UK, and Nordics – for a talk on importing data into Neo4j. With examples, strategies and live demos Rik will demonstrate the advantage of using a graph database to represent complex relationships between pieces of data directly, covering the various aspects of the data import process for Neo4j and present the existing procedures and tools.

Thursday:

Get hands-on with FParsec on Thursday as Phil Trelford and the F#unctional Londoners, as they introduce parsing domain-specific and general purpose languages using FParsec. Along the way you’ll cover creating a simple Abstract Syntax Tree (AST) with discriminated unions, and interpreting or compiling the language using pattern matching.

Go back to basics for WebGL Workshop London’s talk on WebGL, Three.js and Babylon.js. This month they finish the rotating dice in raw WebGL, then do the same in Three.js and Babylon.js for comparison. This is the second part of this talk, the first of which you can watch here.

Finishing off the week the London Java Community bring us their Java 8 Roadshow. Join speakers Tori Wieldt, Raoul-Gabriel Urma and Richard Warburton as they take you through the great new features on Java 8!

A Look at Swift: Strings and Things

boisy-pitre-swift-guest-post

This is a guest post by Boisy Pitre, Mobile Visionary and lead iOS developer at Affectiva. Here he talks to us about string manipulation and interpolation, the simplicity of Swift and the power of Apple’s compilers – and how with Swift, less is more.

This is a follow-up post to Boisy’s While It’s Compiling interview from iOSCon 2014, which you can read here.


One of the very cool things about Swift is probably the most mundane: string manipulation and interpolation. The fact that as a developer, we can juggle using strings as naturally as numeric types is a huge deal. In this article, I’ll show you just why this is important, and how it can be not only a time saver, but a bug saver too.

Back In My Day…

Us “old timers” love to start out telling stories with that phrase. In this case, “back in my day” is not that long ago when we were (and still are in most cases) using Objective-C as our primary development language. Objective-C inherits a lot from C, and one of the things it tried to improve on was strings. If you’ve ever worked with C, you’ll remember the obtuse functions we had to use just to concatenate two strings:

char s[255];
strcpy(s, "This is a string. ");
char *p = strcat(s, "And this is another!");

No kidding. If this is foreign to you, then be thankful. Such code is fraught with potential security issues, not to mention the real possibility of outright crashes. Granted, functions like strncat and strncpy came along to limit the security risk by enforcing a maximum number of bytes to copy, but still remained unwieldy to use and slightly unnatural in appearance.

Objective-C did its best to make things better. Here’s the C code above, rewritten in the simplest Objective-C style:

NSString *s = @"This is a string. ";
NSString *p = [NSString stringWithFormat:@"%@ And this is another!", s];

… still not elegant, but fairly descriptive, and safe from the dangers of accessing memory in a more direct fashion in C. And by God, we loved it. And still do.

boisy-pitre-swift

Swift’s Response

If you think the above code is easy to understand, then you’ve probably seen it one thousand times over. If you think it’s way too complicated, then you’re probably right in line with the new crop of developers who have cut their teeth on scripting languages like Ruby and Python. No matter which camp you’re in, you have to appreciate the simplicity of this:

let s = "This is a string. "
let p = s + " And this is another!"

Come on. This is just too easy, isn’t it? That’s all it takes to add two strings in Swift. I have to tell you, when you come from the old way, it almost feels like cheating. Deep down, you don’t trust the compiler and think all of this pretty, sugary stuff is eating up tons of CPU cycles. Where are the good old “bare metal” programming days going to?

You can relax, because Apple’s compiler wizards have worked hard to optimize these statements under the covers. Just bask in the enjoyment of all that typing you’re going to save.

Format Specifiers… Ugh!

Another win that we get in Swift is with the printing of constants or variables. How many times in your code do you do this? A lot. And it’s a lot of typing… and tedious to boot. Here’s a simple contrived example:

int x = 42;
char *s = "life";
printf("The answer to %s is %d!\n", s, x);

Now multiply that times one hundred lines!

This has been the bane of C and Objective-C for a long time. Keeping track of what format specifiers to use for what types is a pain, but what’s even more of a pain is if you have a ton of them in one printf statement, and forget a couple, or worse, transpose the variables so that the types don’t match. Compilers got smarter over time and warned you of such transgressions, but what a time killer nonetheless.

C++ tried to get it right, and did a decent job, but it still didn’t have that “natural” syntax flavor:

cout << "The answer to " << s << " is " << x << "!\n";

Nice try, C++, but Swift cuts through this problem like a hot knife in butter:

let x = 42
let s = "life"
println("The answer to \(s) is \(x)!")

You may have to get used to typing a backslash followed by open and closing parentheses around your variable names, but this is clear and concise and has minimal chance of collision with your string characters.

Less is More

Strings are just one of many things that Apple has really made fun and easy to use in Swift. The theme of the language certainly seems to be “less is more.” Less typing and gaining more functionality. After all, computer languages are about us humans expressing ourselves more naturally in our work so that things can get done quicker.

If you haven’t started learning Swift yet, you should. If you have started, hold on to your bucket seats, because it’s going to be a wild but great ride!