Category Archives: Programming

How to test services that make async network calls in Swift and return an Optional

One of the things that threw me the first time I did iOS development was the fact network calls were done asynchronously by default. From an implementation side this was nice, I didn’t have to worry about blocking my main thread. But from a testing side… well that was something new.

Since then Apple’s come out with Swift. And with Swift comes the need to learn new ways to do things.  A couple of things I wanted to work out how to do nicely was:  how can I stub out my network layer as I don’t want my test to have to run against a dummy backend, and secondly how can I assert the Optional value I get back is set.

Turns out it wasn’t too tricky. The optional var was set as a result of an async call, so the easiest way to check the value is to first wait till the var has a non nil value.

And stubbing out the network layer was easily achieved by using OHHTTPStubs.

My final test ended up looking like:

 

YOW! Connected 2015: Bridging the Designer – Developer Divide by Chris van Raay

I had the opportunity to go down to Melbourne for the YOW! Connected 2015 conference. It’s the second YOW! Connected to be held and even though it was at a smaller venue this year I enjoyed it just as much as last year.

What I enjoy about conferences is it’s a chance to hear how other people are doing things, get interesting insights and things to look into. And lastly to somewhat reassure you that as a developer (and organisation) the decisions you’ve made so far have actually been sensible choices. When you’re sitting in an audience and multiple speakers are mentioning things along the same lines there definitely is a sense of relief in a way.

But back to the conference. Whilst the conference covered both mobile development and the IoT, I mainly attended talks leaning on the mobile development side. For me there were two running themes in this space:

  • Designers and developers working together
  • The use of reactive programming in mobile development

There were also a few talks on mobile app testing, CI and CD that reaffirmed for me the state of testing for mobile, the decision we’ve made so far and where we can go next.

I’ll focus on trying to get up my notes on the designer and developer talks first as there were 3-4 talks on this topic. Whilst every talk had differing ideas on how designers and developers could work better together the crux of it all was communication and having a shared understanding.

Bridging the Designer – Developer Divide – @chrisvanraay

Common issues in the divide

Chris opened by discussing a number of issues in the designer – developer divide and how they may be overcome:

Us and them mentality
Developers thinking ‘designers don’t know anything’ and designers thinking ‘developers are lazy. To help overcome this:

  • Designers should be experts in the platform they are designing for
  • Developers need to be honest. Nothing is impossible, just harder/hard to do.
  • Break down the walls and have respect for each other. Working in a cross functional team helps with this

Implications of design decisions
It’s not easy for designers to know what is easy/hard. You get get through this by simply talking and working through it together.

Point 1 in ‘Us and them mentality’ about being an expert will help in understanding the implications.

Speaking different languages
Designers and developers often speak in different terminology. Use a shared language. E.g. things you can standardise:

  • Are you talking pixels or points
  • Is it a screen or a view controller

Design isn’t always measurable
Developers need to understand design isn’t scientific and will have to be more patient.

Geographical separation
Easily overcome by co-locating/sit together. Also better handover docs (this is more relevant if you’re geographically separated).

PSDs are terrible docs for developers to use
These are often provided as the output of design for developers to use. They’re not ideal though as developers often don’t have Photoshop nor the skills to use it well. Designers could help developers learn enough Photoshop but PSD files aren’t valuable enough in itself.

Conflict isn’t a bad thing
It gives you a different view on things. But you both need to be able to compromise on things.

But at the end of the day designers and developers aren’t really that different. Your goals are really the same thing, just in a different language.

How/what can designers developers do to help bridge the divide?

How does a team overcome the issues identified above? There are a number of things that a team can do:

Have a consistent design
This means you have less things to build, as a common understand is shared between both parties. To achieve this there are obviously some changes/improvements that need to be made:

Designers can structure their work to make the transition as painless as possible

  • Communicate the design rationale
  • Documentation of the stuff you will look at every day. Things like font, spacing, colour palette
  • Use smarter prototyping tools
  • Handover a spec – if you’ve documented the common things, you can get down to just handing over a wireframe with the styles listed next to boxes.

Developers can do the following things better

  1. Code for consistency
  2. Code for change – Change is inevitable. Branding can change, apps get sold. Really this is the same as principle 1.

But how can we do all this?
A number of approaches we’re given on how designers and developers could help achieve the above:

  • Name your colours something easily understood. E.g. instead of saying ‘colour #8cd8fd’, maybe your team will call that colour SkyBlue.
  • Centralise colours – e.g. use a category to add your defined colours to UIColor.
  • Name your different font variations. E.g. H1 could be 17 point System Font.
  • Give names to combinations of fonts and styles so they can be references in wireframes. E.g. H1SkyBlue would mean the font is 17 point System Font in SkyBlue.
  • Document reusable views somewhere. This makes it easier for developers and designers to know what something looks like and refer to where it is already being used.
Why should we care about this all?

Everyone wants and loves working in a high functioning team. Happy designers + happy developers = a better functioning team. You’ll have increased flexibility and productivity and a general better working environment.

It was interesting listening to this talk as we’ve started doing some of the things mentioned above at work and the designers and developers already agree it is a better experience for both parties.

Is bridging the divide an easy thing to do?

Yes and no. You’ll need discipline and ensure designers and developers have both bought into the process. Things can get into the way like really strict rules on checking in code. All of these can be overcome if the team is willing to be flexible and do a bit of forward planning and creative allocation of work. E.g. if you’ve got a hefty design piece, split it down and sequence the stories in a ordered known way that makes sense. We’ve actually already started doing this at work and it’s been a much more pleasant process in getting design improvements delivered.

 

 

Adventures with Swift and unit testing

Firstly, it’s been a long time with no blog. Life, the universe kind of caught up with me. That and I think blogging for a number of years in my late teens/early twenties kind of got the better of me… But from now on, let’s see how this blogging stuff goes. Hopefully it’ll be a place for me to brain dump my thoughts and learnings… Which brings me onto the topic of this post ‘Adventures with Swift and unit testing’.

Bit of background, about 5 years ago in my previous job I was part of an ios development team. Things were different back then. Where I worked didn’t practice TDD and the testing landscape was fairly immature with respect to mobile development.

Fast forward to the present and I work at place that does TDD and tooling/frameworks for testing ios development has vastly improved. It’s still somewhat behind what I’m used to as a Java developer, but we need to bear in mind the mobile ecosystem/environment is still relatively new in the timeframe of things (the first iPhone was only released in 2007).

At WWDC 2014 Swift was introduced. I’ve read a bit here and there, but I’m finally getting round to giving it a try – TDD style. With Xcode 6 beta 4 access controls has been introduced which has provided a bit of an interesting situation with unit testing.

Access controls come in 3 flavours:

  • Public – as it states, accessible from it’s own module as well as any other code that imports the said module. Pretty much more or less the same as public in Java.
  • Internal – Only accessible within the defined module. Somewhat similar to package private in Java.
  • Private – Only accessible via the defining source code. Pretty much the same as private in Java.

What’s interesting is that by following good practices of encapsulation using the above access levels brings about some interesting implications for unit testing. This comes about because in ios developer a test target is not part of the applications module and thus cannot see anything that is not marked public. This is particularly frustrating as in Java something marked package private can still be accessed/seen in the test tree when in the same package.

The beta release notes actually state:

Can this be worked around? Somewhat so… At the moment you could mark everything as public, but that seems rather unfortunate as it pretty much bypasses any encapsulation. Add the class under test to your unit test target.

Interestingly enough, on the developer forums Chris Lattner has posted that they know the access control design doesn’t really work for unit testing…

Objective C, Xcode revisted

It’s been a few years since I’ve written in Objective C for iOS and used Xcode, and I must say it has changed/matured a lot since then.

The first time, thrown into the middle of an intense project, was a crash course in the intricacies of the language and IDE. And being mainly a Java front end dev back then with very limited C experience was interesting to say the least.

But I’m glad to say that alot has changed since then, and for the better. After giving some documentation a once over and playing around with things, lots of the oddities that I saw coming to the language as a Java developer have now been improved.

The biggest things for me (so far) I think were:

  • Automatic synthesizing of properties.
  • Automatic reference counting (ARC). It puzzled me that writing code for the OS had memory management, but you had to manually manage for iOS.
  • Setting up your project with unit tests is a breeze.

There are other things, and if you haven’t looked at it in a while you might be pleasantly surprised.

Monitor your Jenkins build with an Arduino (and some Java code)

So I got my hands on an Arduino kit a while back but hadn’t played around with it much. Whilst I await for some books to arrive so I can learn basic electronics and circuits (am a developer without engineering/electronics background…) I thought it’d be fun to see if I could write something simple that could be useful in my day to day job as a Java developer.

One of the tools we use is Jenkins and whilst we get emails and check the Jenkins Dashboard to see if a build has failed,  developers often have a tendency to not check their emails or check Jenkins to see what the state of the build is… As a result it may be hours or even a few days before someone realises the build is not passing…

So it seemed fitting to write some code to get a LED light to blink if the build is failing. To do this you’ll need the following:

  • Jenkins with the build you want to monitor setup
  • Arduino (I’m using an Uno)
  • A LED (though for test purposes if you’re using an Uno pin 13 has a LED built in which should be sufficient)
  1. Wire up your LED to one of the pins or do what I did and use the built in LED on pin 13.
  2. Write some code in your language of choice to grab the build status from Jenkins and send it serially to the Arduino. I chose to grab the status as JSON, but there are other options available. I used Java and the Spring Framework to schedule a process to run every 5 seconds to grab the Jenkins status and send it across to the Arduino with the main grunt work being the code below: [sourcecode language=”java”]
    package com.delineneo.processor;

    import com.delineneo.communication.SerialCommunicator;
    import org.springframework.beans.factory.annotation.Autowired;
    import org.springframework.scheduling.annotation.Scheduled;
    import org.springframework.stereotype.Component;
    import org.springframework.web.client.RestTemplate;

    import java.io.IOException;

    import static org.apache.commons.lang.StringUtils.contains;

    /**
    * Created by IntelliJ IDEA.
    * User: deline
    * Date: 2/03/12
    * Time: 8:33 PM
    */
    @Component
    public class JenkinsStatusProcessor {
    private static final String JENKINS_URL = "http://localhost:8080/job/JenkinsStatus/api/json" ;
    private static final String SUCCESS_BUILD_COLOR = "blue";
    public static final char BUILD_FAIL = ‘0’;
    public static final char BUILD_SUCCESS = ‘1’;

    private RestTemplate restTemplate;
    private SerialCommunicator serialCommunicator;

    @Scheduled(fixedDelay=5000)
    public void process() {

    String jsonString = restTemplate.getForObject(JENKINS_URL, String.class);

    boolean buildSuccess = isBuildSuccessful(jsonString);
    try {
    serialCommunicator.send(buildSuccess ? BUILD_SUCCESS : BUILD_FAIL);
    } catch (IOException e) {
    e.printStackTrace();
    }
    }

    private boolean isBuildSuccessful(String jsonString) {
    if (contains(jsonString, SUCCESS_BUILD_COLOR)) {
    return true;
    }
    return false;
    }

    @Autowired
    public void setRestTemplate(RestTemplate restTemplate) {
    this.restTemplate = restTemplate;
    }

    @Autowired
    public void setSerialCommunicator(SerialCommunicator serialCommunicator) {
    this.serialCommunicator = serialCommunicator;
    }
    }
    [/sourcecode]

    In the process method we grab the status as JSON using Spring’s RestTemplate then search for the build status colours in the string. Blue represents success and I treat any other colour (yellow and red are the other ones) as a failure. We then send either a ‘0’ or ‘1’ for fail or success respectively.

    You might wonder why we send a char instead of a boolean… Serial write to the Arduino is as an int or byte array, and on the Arduino side read is done either as an int or a char. For example sending ‘A’ will be received via the Arduino as either the char ‘A’ or the int value 65 (the ascii value). This post on bildr gives you a bit more info on why one might choose to read values as and int instead of a char.

  3. Write some code for the Arduino to process the received data and set the LED to flashing if the build has failed. The code below listens on the serial port:
    [sourcecode language=”cpp”]
    /* JenkinsStatus will turn the LED at pin 13 on/off depending
    * on the value serially read.
    */
    const int BUILD_SUCCESS = 49;
    int inByte;
    int currentPinValue = 0;

    void setup() {
    Serial.begin(9600);
    pinMode(13, OUTPUT);
    }

    void loop() {
    if (Serial.available() > 0) {
    inByte = Serial.read();
    if (inByte == BUILD_SUCCESS) {
    digitalWrite(13, LOW);
    } else{
    digitalWrite(13, HIGH);
    }
    } else {
    currentPinValue = digitalRead(13);
    if (currentPinValue == HIGH) {
    delay(1000);
    digitalWrite(13, LOW);
    delay(1000);
    digitalWrite(13, HIGH);
    }
    }
    }
    [/sourcecode]

    In the loop if there’s data to be read we read it then determine if what state the LED on pin 13 needs to be in. The pin needs to be LOW (i.e. off) if the build is passing and HIGH (on) otherwise. Additionally, if there is no data to be read we want to keep the LED in a flashing state if it was set to HIGH (last read indicated build had failed).

So that’s pretty much the long short of it, the full code is available on my Git repo – https://github.com/deline/JenkinsStatus

Some thoughts on how JenkinsStatus could be improved:

  • Allow config of Jenkins details via properties files
  • Allow more than one Jenkins job to be monitored
  • Put in more LEDs for other states

Simple RegEx and Closure example in Groovy

I’ve been intermittently reading Groovy in Action for the last few nights and whilst it all seems pretty straight forward, for me the real grasping of an understanding comes by writing some code to affirm what was read. That posed the dilemma of what to write, as since leaving uni most of my learning experiences in Java (and development concepts in general) have been in relation to real world business style scenarios. I gave a thought back to my high school days where I learnt how to program. Why not just start with a somewhat simple/trivial problem – e.g. a factorial calculator, or sentence word reverser and go from there? Sure it’s not anything too swish, but it seems a good way to get an understanding of the language.

So here I present a simple solution in Groovy that uses RegEx and Closures to captalise the first letter of each word in a string. I’ll also show you an even neater solution after….

First up:

[groovy]

String testString = ‘the quick brown fox jumped over the lazy dog’
String regex = /bw*s?b/

testString.eachMatch(regex) { match ->
print match.capitalize()
}

[/groovy]

Lines 1 and 2 should be pretty self explanatory. We’ve based our regex of the basis that a word consists of word characters only, may have a space after the last word character and has a word boundary on either side.

Lines 4-6 is where the cool stuff happens, as for each word match we make we want to upper case the first letter and print it out. The method eachMatch takes two arguments a String regex and a closure. From the Groovy docs‘A Groovy Closure is like a “code block” or a method pointer. It is a piece of code that is defined and then executed at a later point.’ In the example above we have defined the closure inline with one parameter match – parameters are listed before the ->. The closure calls capitalize on the match and prints it out.

We could have easily defined the closure separatley and provided it to eachMethod as such:

[groovy]
Closure capitalize = { match -> print match.capitalize() }
testString.eachMatch(regex, capitalize)
[/groovy]

Seems pretty easy right? Not many lines of code and quite succinct about what is happening. Well as is often the case, I did a little Google and here’s an even easier solution:

[groovy]
String testString = ‘the quick brown fox jumped over the lazy dog’
print testString.split(‘ ‘).collect{ it.capitalize() }.join(‘ ‘)
[/groovy]

In the end my solution was a first attempt into using Groovy to solve a problem without having much exposure to the language whilst at the same time trying not to use my Java mindset. After seeing the alternative solution on the Internet it kind of shows that if you know what to use Groovy can make things even simpler as it’s definitely cleaner without using the RegEx.

Installing Groovy on a Mac

Having heard about Groovy and Grails for the last few years but not having actually had a look at it I installed Groovy on my Mac the other week for a bit of a play. It’s always good and fun to have a look at a different language even if if you’re not going to use it in your day to day job. Coming from predominantly a Java background Groovy seemed like a good choice as it runs on the Java platform and the language is similar. Having had the opportunity to use Objective-C for a few months last year and seeing how in some ways it was more powerful than Java (but also in other ways frustrating), I was curious to see what power Groovy gave to a developer.

The first step though was to get Groovy installed on my Mac. So I thought I’d put a post up mainly for anyone new to developing on a Mac. Whilst I’ve had my Mac for a year or so, I hadn’t really had it setup for anything other than Java until recently, and there were definitely some things that were a little different to what I was used to on Windows as well from my prior limited stint in Ubuntu land.

These instructions are based on a setup for OS X. I’d imagine the setup may be similar on any other version?

  1. Java should already be installed on your machine. Confirm this by opening up a Terminal and typing in ‘java -version‘.
  2. Download the binary Zip release of Groovy from the Groovy site.
  3. Extract the contents into /usr/local – e.g. my install location is /usr/local/groovy-1.7.6/. You will probably need to need to use the sudo command for the extract as you will need to be superuser to write to the location.
  4. Check if a file called environment.plist exists in the following location /Users/YOUR_USER_NAME/.MacOSX. If it doesn’t create it.
  5. Open environment.plist in the Property List Editor
  6. Add an entry for JAVA_HOME if not present, ensure the value is the location of your Java installation. This should be /System/Library/Frameworks/JavaVM.framework/Versions/CurrentJDK/Home
  7. Add an entry for GROOVY_HOME if not present and ensure the value is the location Groovy is installed. E.g. /usr/local/groovy-1.7.6
  8. Add an entry for PATH if not present, and ensure the Groovy bin and Java bin directories are present by adding  $JAVA_HOME:$GROOVY_HOME/bin
  9. Log out and re log back in for the changes to take effect.
  10. Check that everything is all setup correctly by opening a Terminal and running groovy -version which should show you which version of Groovy is installed.

Easy integration with Spring Integration

So I’ve had the opportunity to use Spring Integration recently and I thought I’d do a blog post about it – partly for my own review/recap/learning but also for anyone out there looking to play around with it. In a nutshell Spring Integration lets you integrate with other systems without having to deal with all the boilerplate concerns of your typical enterprise integration solutions. It provides a number of integration adapters straight out of the box for common integration methods such as: files, jms, jdbc, ftp and so on (take a look at the Spring doco for the full set).

The general gist of things has you defining a series of channels of which the endpoint may be the entry or exit to the system. One endpoint may be the entry point to another channel. E.g. in the following A<——–>B is a channel with A as the input and B as the output endpoints. B<——–>C is another channel where the output B from the A<——–>B channel is the input and C the output.

A<——–>B<——–>C

To really see how it all hangs together I’ve knocked together a little working example to integrate with Twitter using the built in Twitter Adapter. The app basically polls Twitter with a search on a hashtag, adds a field to the header then passes the message on to a service to be dealt with – in this case we are just going to print out to System.out. Sounds complicating, but Spring makes it easy – take a look at src/main/resources/twitter-integration.xml.

[xml]
<channel id="inboundMentionsChannel"/>
<channel id="inputServiceActivatorChannel"/>
[/xml]

This defines the channels, note that we haven’t actually specified what the endpoints are yet…

[xml]

<twitter:search-inbound-channel-adapter query="#springintegration" channel="inboundMentionsChannel">
<poller fixed-rate="5000" max-messages-per-poll="3"/>
</twitter:search-inbound-channel-adapter>

<header-enricher input-channel="inboundMentionsChannel" output-channel="inputServiceActivatorChannel">
<header name="headerField1" value="dummy header value"/>
</header-enricher>

[/xml]

This is the interesting stuff where we link all the endpoints and channels together. Lines 1-3 define the inbound adapter (endpoint) which connects the system with Twitter. This is a search-inbound-adapter that polls for a twitter search using the specified query – in this case the hashtag #springintegration.

Lines 4-7 defines a header enricher. This allows us to pop values into the message header that can be used downstream. For this example we’re just populating a field called ‘headerField1’ with a dummy value. We’re not actually going to use this field for anything in the example but I wanted to show how easy it was to add info to the message header. The header enricher also has an input channel and output channel specified. As you may have worked out the input to the header enricher is from the endpoint of the ‘inboundMentionsChannel’, which in this case will contain the results from the Twitter search. And the outbound channel is to a service activator which references the TwitterService bean (bean is autowired).

If you take a look at TwitterService.java you’ll see that it prints out to System.out and adds the tweet to a list. Running the test case TwitterIntegrationTest.java you can check that the output matches the expected tweet search result count of 3.

twitter-integration.zip