Archive for the ‘geek’ Category

Constructor Vs Setter: A Better Way

This post originally appeared on DZone at https://dzone.com/articles/constructor-vs-getter-a-better-way

One of my jobs as a Zone Leader at DZone is to syndicate content; that is, read posts from the giant firehose of articles from our MVBs and select the best ones for republishing on DZone (aside; we’re always looking for new MVBs. If you want your blog to be read by thousands of people then click this link). My interest was particularly peeked when I saw “Constructor or Setter” on the Let’s Talk About Java blog. I’m always interested in the ways different people code in the hope I can learn something new, or pass on some knowledge.

Honesty from the start; I hate setters. They’re generally the wrong thing to do and represent a code smell from bad wiring. Wherever possible (which is most of the time) you should pass everything in you need to the constructor and generally assign it to a final field. I don’t think that’s going to blow any minds as it’s general good OO practice. If you’re writing code using TDD you’ll never inject something via a setter.

The example used in the article is an interesting one, though. Your code base is evolving and as a result, you end up with multiple constructors due to evolving optional client demands; they’d like the option of having notifications on a trigger, they’d like the option of a snapshot etc.etc. which results in the below code.

public class SomeHandler {
   public SomeHandler(Repository repository, Trigger trigger) {
       // some code
   }
   public SomeHandler(Repository repository, Trigger trigger, SnapshotTaker snapshotTaker) {
       // some code
   }
   public SomeHandler(Repository repository, Trigger trigger, Notifier notifier) {
       // some code
   }
   public SomeHandler(Repository repository, Trigger trigger, SnapshotTaker snapshotTaker, Notifier notifier) {
       // some code
   }
   public void handle(SomeEvent event) {
       // some code
   }
}java

Everyone can agree this code is ugly and confusing; so many overridden constructors are far from ideal, and they’re the wrong thing to do. From the original article:

“Why do we have so many constructors? Because some dependencies are optional, their presence depends on external conditions… we should place in the constructor only the required dependencies. The constructor is not a place for anything optional.”

So far so good. The solution proposed is to effectively use setters, although not using “setX”, but instead enable() methods where the optional dependency is set.

public class SomeHandler {
   public SomeHandler(Repository repository, Trigger trigger) {
       // some code
   }
   public void enable(SnapshotTaker snapshotTaker) {
       // some code
   }
   public void enable(Notifier notifier) {
       // some code
   }
   public void handle(SomeEvent event) {
       // some code
   }

There is, however, another way which I strongly advocate people to take which I believe is cleaner in design and code, and will have fewer bugs.

The problem here is the premise that these dependencies are optional. In reality they are not; whether they are present or null, a code path will have to be called. In the example given, the code would likely look like this:

public void handle(SomeEvent event) {
     Data data = repository.getData(event);
     if(snapshotTaker != null){
         snapshotTaker.snapshot(data);
     }
     if(notifier!= null){
         notifier.notify(data);
     }
     trigger.fire(data)
 }

Those two if statements dramatically increase the cyclomatic complexity of this method. You would need tests to make sure it functions when:

snapshotTaker and notifier are present
snapshotTaker and notifier are null
snapshotTaker is present and notifier is null
snapshotTaker is null and notifier is present

And that’s before you get to testing the original functionality in the class!

In reality, these fields are not optional as there are code paths exercised. Plus, null is a terrible thing. Instead, the code should be reduced to the single constructor which takes all three fields. If the instantiating class doesn’t need the “optional” functionality then it owns the responsibility of creating and passing in a no-op version.

In the examples, let’s assume notifier and snapshotTaker only have one method, notify and snapshot respectively. This makes this really easy in Java 8:

new SomeHandler(new DBRepository(), new EmailTrigger(), data ->{}, data -> {});

Alternatively, we can have specific no-op classes for clarities sake.

new SomeHandler(new DBRepository(), new EmailTrigger(), new NoOpSnapshotTaker(), new NoOpNotifier());

As a result, there are no if statements in the executing code, making it clearer to read and simpler to test, and less error prone.

The case of optional subscribers is particularly interesting, though. Often these may not be known at construction time, in which case it makes sense to have a specific subscribe (Subscriber sub) method. Often though it makes sense to allow multiple subscribers so these can be stored in a List. Again, if there’s zero subscribers it’s no big deal as the List is owned by the class and will never be null.

If we apply this to the case of the notifier in the previous example:

private final List<Notifier> notifiers = new LinkedList<>();
  public SomeHandler(Repository repository, Trigger trigger, SnapshotTaker snapshotTaker) {
        // some code
        this.repository = repository;
        this.trigger = trigger;
        this.snapshotTaker = snapshotTaker;
    }
        public void handle(SomeEvent event) {
        Data data = repository.getData(event);
        snapshotTaker.snapshot(data);
        for (Notifier notifier : notifiers) {
            notifier.execute(data);
        }
        trigger.fire(data);
    }

Clean code with zero complexity. I Hope this offers a compelling alternative in the battle between constructors and setters.

Continuous Deployment With Heroku and Github

This post originally appeared on DZone.

The movement to Continuous Deployment (CD) has been gathering speed and is widely acknowledged as the way to go. Code is checked in, an automated suite is run, and if passed it is automatically deployed into production. A story is not “done” until it is in production, providing value to the end user and CD gives us the smallest mean time to production for our code. To get to this point we have to have a lot of faith in our test suite and the code base, which ensures we will write more robust systems to cope with this way of working.

There still isn’t a huge heap of tooling available to build a continuous deployment pipeline; it tends to be something people have manually crafted using tools such as Puppet, Ansible and Chef. That’s why when I went to put a project up on Heroku for the first time in a while I was pleasantly surprised to see it now supports building your code from GitHub and continuous deployment from that repository.

Let’s first discuss what Heroku brings the table. It’s a great place to deploy your applications and services in a scalable fashion. You can pretty much just drop any application in any language onto Heroku and it’ll spin it up for you, accessible for the world. Your app is scalable on a simple web dashboard too; start out with a single dyno, but increase if you need the capacity. There’s lots of awesome addons you can throw on too such as papertrail for log alerting and HTTPS certificate hosting. The addons vary in price, but to get a simple process up and running is totally free.

This tutorial presumes you’ve signed up for an account at heroku.com and you have an existing Java web project you’d like to set up for CD which is already in Github.

Step 0: Github Build

As with any good continuous integration you want to make sure your tests are all run first. Fortunately this is easy to do with Github and TravisCI. You can sign up using your Github account atTravis-CI.org which will then allow you to easily create automated builds which are triggered on every check-in.

Once you’ve signed in, you will be given a list of all your repositories. Flick the toggle switch for the project that you’re setting up, in my case WizChat.

Image titleTravis requires a config file to be placed in the root of your project names .travis.yml. Although there’s a variety of options you can choose to setup, for the purpose of this example I went with the simplest options; telling Travis the project is Java and to build using Oracle JDK 8

Image title
Check this in and your first build will be automatically triggered. If everything is setup correctly in your project, and your tests are passing, Travis will give you a green build. Either way it should send you an email to let you know.

Image title

For bonus marks, once you’ve completed your first build you will see a badge indicating the build status. Click this and you’ll be given a variety of ways to integrate the build badge into other sites. Convention dictates placing it at the top of the readme for your project. As my readme is in Markdown format I simply copy and paste the Markdown syntax provided:

Image title

Setting Up Your Project for Heroku

As mentioned before, it’s possible to throw pretty much anything at Heroku and have it run. All it requires first is the creation of a Procfile, used by Heroku to know what to run and how.

For web projects it only requires a single line. Again, there’s lot of extended config that you could dig into if you need finer grain control, but the following should be sufficient to get your web project going:

web: java -jar target/wizchat.jar

This tells Heroku the command to run, and that the project is a web project so it needs to let us know what the port is which is done via a system variable. You need to ensure that your project runs on whatever port is handed to it by Heroku else your application won’t run. For example, this is done in SparkJava using the following syntax:

port(parseInt(ofNullable(System.getenv("PORT")).orElse("8080")));

For our Procfile to work it also relies on us having a runnable Jar. This can easily be achieved using the Maven assembly plugin, or the Maven shade plugin.

<plugins>
            <plugin>
                <artifactId>maven-assembly-plugin</artifactId>
                <configuration>
                    <archive>
                        <manifest>
                            <mainClass>com.samatkinson.Main</mainClass>
                        </manifest>
                    </archive>
                    <descriptorRefs>
                        <descriptorRef>jar-with-dependencies</descriptorRef>
                    </descriptorRefs>
                    <finalName>wizchat</finalName>
                    <appendAssemblyId>false</appendAssemblyId>
                </configuration>
                <executions>
                    <execution>
                        <id>make-assembly</id>
                        <phase>package</phase>
                        <goals>
                            <goal>single</goal>
                        </goals>
                    </execution>
                </executions>
            </plugin>

This code builds a single fat executable jar with all the dependencies built in. You must set the mainClass and finalName and Maven does the rest.

With everything checked in we now head over to Heroku and login to the dashboard. In the top right is an arrow. Click on it and select “Create new app”.
Image title
Create a name for your app and select in which region you’d like to run it.
Image titleYou can then choose the deployment method: select Github and sign into your Github account when prompted. This should integrate and pull al of your repos in. Search for and select the repository you’re integrating and press “Connect”.
Image titleFor the final step, select “Wait for CI to pass before deploy” and click Enable Automatic Deploys. You will now have automated deployment of your application to Heroku every check in if the CI passes! Your application will be available at <appname>.herokuapp.com.
Image titleI highly advise setting up the Heroku Toolbelt so that you can then tail the logs of your application to make sure it started correctly.

Reasons I love IntelliJ #1

Recently I’ve been  interviewing a lot of candidates at work, most of whom use Eclipse and have very little experience with keyboard shortcuts that seem to be default with IntelliJ users. I guess if you’ve made the effort to go out and look for a better IDE then it’s indicative that you’re keen to be as efficient and effective a developer as possible, which I think is hugely important. If you’re going to spend over 9 hours a day doing something then learning at least the most basic shortcuts is the least you can do to improve your code output.

 

Inspired by this I put a video together to showcase the features that excite Eclipse users the most when they see them for the first time, or if you tube’s not your thing, read on for gifs and transcript.

This is effectively an exercise in loving the shortcut alt-enter. If anywhere in IntelliJ you see something red or grey, hit alt-enter on it and IntelliJ will create or fix it for you.

Create New Variables

variable

One of the really cool parts of IntelliJ is how it writes most of the code for you;  as a user you don’t have to do much typing.  In this shortcut, Ctrl/Cmd+alt+v will create a new variable for you from a newed up object.

Create new class

new class

Write the name of a class you want but doesn’t exist, hit alt-enter on it and IntelliJ will create the new class for you

Create new methods

method

Yet again, write the code you want to see in intelliJ and hit alt-enter and it will create it for you.  Write your new method name, hit alt-enter and the method is created.

Adding Parameters

parameter

If you need to pass something into a method in intelliJ, just put the parameter in and hit alt-enter and it will add it in.  This becomes immensely helpful if you have tens/hundreds of instances around your code base; write it once and intelliJ will add in the parameter and allow you to set a default parameter.

parameter2

 

Code Templates

code template

IntelliJ has a whole host of code templates that allow you to write code with very little text! Why write public static void main when you can write psvm and hit tab.  iter allows you to auto generate for loops.  And you can write your own templates which is very cool.

Generator

generator

IntelliJ is smart enough to know standard coding patterns.  If you pass parameters into a constructor you probably want to create fields for them; alt-enter on the grey text (which indicates it’s unused) will allow you to create new fields for constructor parameters.  Using alt enter on the new parameters or using the generator (alt-insert windows/ctrl-n mac) you can then easily create getters for those fields

Why I hate Spring

When I started my career I really fell in love with Spring. I went long on it. I threw it into all of my projects. I even managed to chuck a bunch of Spring Integration in there for good measure. I was like an XML king.  I was building was a custom RPC layer based over JMS, protobufs and Kaazing to be used across our department and further around the bank. “It’s so configurable” I would say. “It’s just a few XML files, it’s really flexible” I would say. I was pretty pleased with myself.

The thing is, there were some people around me that tended to disagree. They were having issues getting this wired together how they wanted, they didn’t know which spring XML files they needed where. There were issues with spring versions and getting the right versions together (I’d also gone long on modularisation; there was about 5 or 6 different modules at different version numbers with no obvious way, other than an email from me, to know which to use). I didn’t notice these smells; I just thought it must need more documentation or that the people using it were being stupid. This is a pattern that repeats itself too; for one of the most disliked and difficult to use frameworks internally currently cries for help are often met with “It’s one file and some parameters, it’s not that hard” whilst everyone else wastes days trying to get the magic combinations of files and parameters to make something happen.

I’m still in the same organisation, and in my new role I’m a consumer of my old framework. This dogfooding has now led me to hate 2009/10 era Sam for several reasons, but mostly for spring. Spring is evil on a good day, but when it’s included as part of a consumable library or API it becomes next level, like a love child of Hitler and the devil. Don’t let Spring leak out of your APIs.

There are a number of reasons why Spring sucks which I felt the need to document, as nothing’s showing up on google as a concise argument against it.

  • Configuration in XML : I’d like to think that as a profession we’d moved beyond XML. It’s incredibly verbose but that’s just a minor starting gripe. Much more importantly, I don’t want to program in XML. The wiring of all of your classes together is a hugely important part of your application. You’re a java developer, not an XML developer. One of the beauties of java as a language is compile time safety. In my springless applications I can hit compile and have a 100% certainty everything’s built, plugged in and ready to work. In applications I work on with Spring, you hit run, wait for 30-60 seconds whilst it initialises beans, before falling over. In the modern world we live in this is insane, particularly when you multiply that up over a number of integration tests where you need to spin the container up and down.   There’s also a special place against the wall for the “It means I can change my implementation without recompiling!”.  No one does this.  Ever.
  • Magic : At this point the usual come back is “you can do it all via annotations now! No more xml!”.   Whilst not programming in XML is swell and all, annotations are still magic.  Until you run your app you’ve no idea if it’s wired up correctly.  Even then you don’t know it’s wired up correctly, only that it’s wired up.  I don’t like magic.
  • Importing other Spring files : This is currently the item that causes me the most rage.  I’ve discovered there’s a tendency to break Spring files down into smaller spring files, and then scatter them across modules.  I’ve just spent 2 weeks of crawling through jars trying to find the right combination/order/version of spring files to make something actually run.  Spring files in jars is a bad, bad idea.  Terrible.  Every time you spread dependent spring files across jars a child dies.
  • Complexity : When interviewing candidates the most common answer to “any pitfalls to Spring?” is that it has a steep learning curve. Whether or not that’s true is another discussion for another day, but I wanted to highlight the fact that Spring is now so complex that it has it’s own framework, Spring Boot. A framework for a framework. We are in Framework Inception, a film about Leonardo Di Caprio trying to find his long lost java code by going deeper and deeper through layers of XML and annotations before eventually giving up on life.

The thing is, I’m sure it’s possible in theory to use Spring well in an application.  I’ve just yet to see it happen, and this is the problem.  And for me all of the “benefits” it offers are perfectly possible without it.  When asking about Spring as a part of our interviewing process and the standard answer is “it means you have clean code, separation of concerns, and it’s really good for testing”.  All things I’m huge fans of (in particular the testing part) but the simple fact is these are not outcomes of using Spring, but outcomes of programming well.  Perhaps Spring is a good crutch for new developers to use to be introduced to the ideas of dependency injection and mocking and testing, but the simple fact is they’re orthogonal.  If you TDD your code you’ll find no getters and setters, only constructor injection which you can mock for tests, and then when you’re putting your application together, just use the often forgotten about construct, the “new” keyword.  We often build a class called “ApplicationContext” which is in control of wiring everything together.  It’s clean, everything’s testable, I have compile time safety and my tests run darn quickly.

 

 

My First Hackathon

image

This is a picture of me on hour 30 of 37 with no sleep.  Mild hallucinations, lots of shouting at my laptop and volumes of coke zero.  No, this isn’t a new interrogation technique, but Hong Kong’s first hackathon.

Angelhack is a US Company that specialises in hackathon and hackcellerators and runs events globally (and often, simultaneously).  The concept is simple; Bring yourself, maybe a team, an idea and your laptops, maybe some hardware, and in 24 hours go from no code to fully fledged working app.  This hackathon was mobile oriented, with the focus being on new apps (although not necessarily for phones; a smartwatch company had brought a bunch of their android based watches for people to hack).  You must bring NO CODE to the event with everything must be written fresh which will be checked for the victorious (somehow). Libraries are allowed so you could probably do most your work as a lib before and wire it at the event, but that’s not really in the spirit.

When I’d first seen the hackathon online, I signed straight up and then pretty much didn’t think about it again until the night before the event  (caveat: I had been drinking when I signed up) when I started to do a bit of googling around it.  The only similar event I’d done before was HK Startup Weekend and I’d been expecting a similar setup.  Oh how wrong I was!  Moreso, I was surprised by how little was available information wise about what the angelhack experience is actually like, which is why I wanted to write the experience up for future victims and to blunt my rose tinted glasses next time I want to apply.

First point of order: this is not a social/networking event like Startup Weekend where you create your teams on the day, do a lot of mingling and exchanging name cards, and come out with lots of new contacts and friends.  At Angelhack most people arrive as a pre-arranged team with an idea.  There’ll be a few stragglers (like me), and you’re able to hack solo or form a team on the day (like me), but I’d probably encourage you to go in with people you know and an idea you believe in. I was lucky enough to meet and pair up with someone, come up with an idea, and not end up killing each other.

Registration in the morning was terrible at this event, run by a HK Startup EventXtra whose systems kept crashing which meant everyone going through the system multiple times which was very slow.  This was mitigated somewhat by the Starbucks breakfast inside (my stomach dictates my mood, or at least has a significant influence on it).  After an hour of general shmoozing time & strategy planning (and stealing the best tables), and 2 hours (!) of sponsor presentations we got around to pitches.

Pitches are an opportunity for individuals and teams to pitch their idea and find people to join their groups.  It’s fairly poorly organised and as most people are pre-organized i’m not convinced anyone picked up new team members from this. As mentioned before, go with a team organised beforehand if you can!

Then comes the hacking.  It really is just 24 hours of coding the crap out of something and using as much brute force and hacks to get it (to look like it is) working.  I’ll go into detail what we built and the tech behind it in another post. Elevator pitch- it’s a push-to do list so you can nag other people. Use case: fiancé reminding me to take washing out the machine after she’s gone to work. It was a hell of a learning experience from both a technology perspective and as an individual.  I’m proud of what we managed to put together in that time frame compared to how much I managed to get done when coding personal projects normally.  Most the teams didn’t code thought the night, with a number of people passed out over tables or on the supplied bean bags, and some people even just went home and came back the next day.  But for the true experience, stick it out.  You won’t regret it after you’ve recovered (which took me about a week).

At the end of the hacking came the presentation. I can safely say that whilst I wanted to do well my enthusiasm was waining as I was feeling immensely broken. There were something like 24 teams presenting, so there’s a lot of waiting around. At ours, we got 3 minutes to present to a panel of 4 judges. I think this is one of the most disheartening things I’ve ever been through; after 24 hours with no sleep busting my nuts, with mad dash sprints to get little beautiful features working, to then get just 3 minutes to show it is nowhere near long enough and is quite an affront to how hard some of the teams worked. It’s a very different mentality from a group like startup weekend where everyone is encouraged to present no matter what state they got to. Hopefully it’s something they can look to improving in future iterations

The judges narrowed down the running to 9 teams (of which one went MIA), who presented to the whole room.  By this point I’m very tired and very frustrated from all the waiting around, and desperately in need of some proper food and sleep.  Delirium had definitely set in, with the stupidest and simplest of jokes setting me and my programming partner off laughing uncontrollably for minutes at a time.  Then, more waiting! Judges make their decisions and announce, prizes handed out, big group photo and then FREEDOM!  A lot of the groups had piled out of the venue when discovering they weren’t in the running to win, meaning the eventual group photo was lacking a lot of the attendees. 

It’s now some months down the line, and if the opportunity to do this again came up I think I probably would.  It’s a huge learning experience, and an opportunity to actually churn out some software.  We’re planning on finishing the app, although I went back into the codebase a week after and it’s a mine zone, which is to be expected really. 

Top Tips if you’re going to/thinking of going to a hackathon:

  • Definitely go. I was on the verge of bailing because I was in one of my unsocial “I can’t be bothered to talk to other people” modes.  I always inevitably end up enjoying it when I go so I forced myself, and even though I was being grumpy, managed to find a great team mate and project. 
  • Bring subtle entertainment; whether it be a kindle or your pocket backlog or whatever. There’s a lot of procession and rubbish before you actually get to do any development. Also sit at the back so you don’t get called out for not paying attention to the sponsors
  • Bring layers! As you can see in the photo, I look utterly ridiculous like a hobo Where’s Wally, but the aircon was maxed out and so I had to throw on all the layers I had.  Bring gear for any occasion
  • Speaking of gear; bring lots! Cables, phones, tablets, adapters, routers etc.  You never know what you’re going to need.
  • Set your expectations; sure, there’s a grand prize of getting into an accelerator, but you’re probably not going to win.  It’s incredible the stuff that they  turned out at our hackathon.  The winning team built a personal eBay with instagram filters, Facebook and twitter AND PAYPAL integration, in a slick, working application.  Another team built a working multimeter which had hardware that plugged into the audio jack.  I didn’t even know what a multimeter was.  People are good at this.  Go in with the aim of having fun and learning something.

Hope that sums it up. Whack a question in the comments if there’s anything specific anyone wants to know.

Stormfly; A PC on your wrist

I’m a huge fan of the kickstarter concept. As well as allowing technologies to exist that may not have without it, it allows me as a geek to get in on the ground floor.  I’ve backed 2 things so far; My Pebble, which is fantastic but was incredibly infuriating to wait for, taking well over a year, and Stormfly, which I backed about 4 months ago in March.

Stormfly’s slogan is “Like a PC on your wrist”.  In effect, it’s a wearable USB which you plug into a mac or windows PC and boot from, giving you access to a linux OS and all your files.  There’s a bunch of nice value adds such as a back up and 24h replace service.

There’s a bunch of reasons you’d want something like this. Perhaps security, so you don’t keep yourself logged onto friends machines. Maybe you’re a big traveler and stay with friends.  My personal reason was simple; When I travel with work I have to take my work laptop (locked down to the max and so useless for personal stuff) and my own laptop, for email, Facebook, videos, maybe a bit of development.  My hope was I could boot Stormfly up on my work PC before all the encryption and lockdown shenanigans, meaning I could just take my work PC and still have a personal machine.

The Stormfly cost me $74 including shipping (yet another kickstarter shipping from China that charges more to send to HK than the US!), which was a fairly pricey bet that this would work.

image

I was really suprised to come home and find my stormfly had arrived having had no shipping notice, nor a kickstarter update to say they were shipping. That said, this was a nice surprise, and I’d rather it be this way as I’m far too impatient when waiting for shipping. The box is fairly small, basic cardboard so lacking a bit of shiney but sufficient for the job.

It comes with some basic instructions (namely, how to boot in mac/windows to stormfly) and has a QRcode for the website if you want more information.  I dug straight in for the test.

My test machine for this was an X200 IBM Thinkpad. Plugged in Stormfly, held the thinkvantage button and prayed.

image

Hey presto!  It works.  The installation process is fairly painless; as with everything these days there’s a sizable download update.  The OS is basically Ubuntu with a couple of extra apps thrown in related to Stormfly so it can back up for you to the cloud.  I’m pleased by this as some of the earlier updates implied it might be quite heavily customized; and whilst it might be under the hood, in appearance it’s just Ubuntu.  All the updates are direct to the USB, so I can now take that and plug it into my Mac, my friends computers etc. and it will be my personal environment.

I was lucky enough to get an email directly from Stormfly a few minutes later.  I’m the first Kickstarter backer to register their Stormfly, so it’s a big milestone for the company (and a little geek victory for me).  No word on whether they’ll throw in a t-shirt or some free subscription to congratulate me ;).

I’ve played with it for most the night, managed to get Java and IntelliJ up; I forgot how terrible Linux is for getting most stuff installed and working.  It’s really very nice and nippy.  Will it be worth the cost?  I think that will become clear over the next couple of weeks as I head out on holiday, followed by work travel, and I’ll be leaving my regular laptop at home in favour of Stormfly.  If you’ve got a corporate laptop and are fed up of carrying 2 around, I highly recommend you purchase one.

Technology & Innovation; The Future of Banking Conference

I was fortunate enough this week to attend the “Technology & innovation- the future of banking” conference held at the renaissance hotel in Wanchai by FST media.  The conference consisted of about 10 or so booths with a variety of technology companies and a host of speakers, primarily from the banking industry.

As with any conference there were both good and poor presentations, but overall it was a fantastic day.  The main buzzwords for the day were mobile, innovation and customer.  The first 2 are fairly standard at the moment, but it is the latter, “customer” which I think is the most interesting one.  A number of the big APAC banks were showcasing big new products or streams which put the customer front and center, making it as easy as physically possible for a customer to do a transaction with them.  The best example of this was Citibanks funky new double touchscreen ATM which is now in 3 regions and coming to HK; customers can request a loan via their mobile with almost instant approval and take it to from the machine; they can apply and be approved for a credit card at the machine, and the card will be printed and provided there and then.  Lost your bank card? A thumb print is all you need to get a new one.

I think for all the fancy gadgetry, the ability to apply and recieve a credit card in a matter of minutes is going to be a massive winner for them.  People are incredibly impatient and lazy, and will always follow the path of least resistance.  Going to a branch, getting forms, filling them out, posting, waiting 2 weeks is far too long for a generation expecting 24 hour access to a full suite of banking services.

Standard Charter also continues to echo the customer first mantra and showcased a huge sweeping change to their client facing technology. A fully responsive website has been built that looks beautiful on all screens, and a new mobile app which has been designed to be intentionally as simple as possible; Very apple, and very refreshing to see a bank innovate and have a true direction and opinion when it comes to design.

The first speaker panel of the day through up some very interesting insights and quotes that show where the industry is heading. (Quotes may be paraphrased due to my less than sterling memory)

Bring your own device (BYOD) isn’t an optional thing’ it’s here and people expect it.  We have to have it in place. We now have to backtrack and get it working as quickly as we can.” – Ian Rae, head of technology for ANZ bank

“We haven’t done the financials and put a business case together for Byod as its just demanded of us; our competitors use iPads, we look behind the curve. The main benefit of BYOD is staff retention, it’s something people want, and that’s hard to measure”-Micky lo, global head of technology, China, Deutsche Bank.

My personal favourite insights came from Minerva Tantoko, head of client facing finance technology at UBS.  They’ve introduced hackathons (under a corporate name) in the US.  The difference to other banks is that the winning projects get funding.  In her area they’ve just launched a new and strategically important iPhone/ipad app in the US which came from the first hackathon.  That’s a hell of an incentive for staff to participate and a great way to attract talent.  Some of the other banks commented they gave extra annual leave away to the victors.

The other interesting UBS concept is that of “social coding”. Minerva didn’t elaborate more than to say they had Social Coding and anyone anywhere could look at and comment on code.  I’ve followed this up with an ex colleague who’s there and he’s confirmed they’re now using GitHub enterprise.  Very cool indeed.

One of the final speakers of the day was Ian Rae from ANZ.  In a time when other banks are rapidly contract, saving costs and taking the austerity approach to handling the financial crisis, ANZ are investing to win.  They’re rapidly expanding the bank to cover a multitude of new sites in APAC, with a long term view to expanding globally.  They’re “hiring selectively”and putting their technology and innovation to the forefront as they expand (yet again with the “customer first” concept).  It must be a really interesting challenge to expand rapidly, but without being weighed down by the legacy systems of traditional big banks.

Overall, a really interesting and thought provoking day, even if I didn’t win one of the iPad mini draws!

Dipping my toes in Node.js

Having played around a little with Node before in hack projects at work, I wanted to have a proper dive and get my hands a bit dirtier. As a result, I’m midway through another increment of http://lastband.in, this time with a node backend.  Here’s some things I’ve discovered so far

Use Express 3.0 and persist with it

I started out wanting to do a slightly different project connecting facebook to some other bits and pieces.  When you sign up with Facebook it offers to kick you off with a basic project in Heroku, which is a very nice feature; If you don’t know Heroku, it’s a great place to deploy stuff for free when starting out and offers a lot of nice tools.

The basic app uses express as it’s HTTP mechanism. If you google there’s a few “roll your own” solutions, then express and connect.

I wanted to use handlebars as my templating library which should be easy enough, but I instantly ran against a ton of issues, mostly because I was ignorant to the ways of express; When Express went from Express 2 to 3 a lot changed, and it seems a lot of the internet hasn’t caught up yet. All of the mixed documentation got me in a faff so I switched over to use connect. DO NOT DO THIS! It’s very very difficult to google, there’s very little documentation on the main site and the internet has very little to offer.

On the other hand, express is as close to a standard as you can get in node land, and once you wrap your head around it and find some reliable articles, it’s actually quite usable! 

How to use Express 3.0 with Handlebars

I was going to post the server up here but instead I’ve whacked it up on my github at https://github.com/samberic/express-handlesbars-starter. 

Node.js is still very immature

Whilst node is undeniably awesome, very easy to use, and just a lot better for quick projects and fast progress, it’s still at the very early stages.  A number of the projects I tried using in npm just wouldn’t work at all. Want to profile your app on a mac? Not a chance.  All very frustrating, and would certainly be a blocker from using it in the enterprise.

You’re not in the browser any more

For lastband, it worked in 3 tiers;  first, find the band on last.fm, render a handlebar template. Then, find artists with that name on bandcamp, render a handlebar template. Then, for each artist, get their discography, and render a handlebar template, then add them all together with a bit of jquery.

This was the easiest way to do it in the browser (I thought at the time), as I was dealing with 3 different API calls.  When porting to node I spent ages looking at JQuery replacement libraries (most of which are based on jsdom and are terrible/won’t compile; If you’re going down this route I recommend Cheerio) at building the html up in this incremental fashion.

I got this working, but it was slow, the code was fugly, and it just didn’t feel right.  As a result, I switched it up; after playing with JS for a bit I realised I could just append each API JSON result to the previous one, resulting in one massive JSON doc; Combine that with 1 single handlebars template, and voila! Now my template is clean and very obvious what’s going on, and my code is to.