11 Jul

Wine Adventure Trail Run @ Warwick Wine Estate

We all knew it would be a wet day, from a week before the race the weather was already predicting upwards of 70% rain showers, steadily increasing as the days went on, by Saturday it was sitting at 93% so there was no doubt.

Photo by Chris Hitchcock

Around sunset Saturday evening it started pouring, and my never tested Waterproof Running jacket was added to race prep pile. After all, what is heavy rain shower to a real trail runner (guess I am one now).

Fast forward to Sunday morning and as best I could tell the rain had not let up much if at all, the wine farm was nothing but mud as far as the eyes could see, and yet plenty a runner had arrived, sporting all their colourful raincoats, and few more crazy ones dressed as if it where a summers day.

Having never run in such conditions before, I had no idea what to expect, and that pretty much added to the excitement, only 1 small change in the goals for the day, forget the time target and make down in one piece. Awesomely enough I had only missed what would been my target by about 3 minutes.

Nearing the finish line.

As it turns out, at least 78 other runners had arrived for the wet, wet, wet 15km run, and while I cannot speak for all of the rest, I most certainly hope they enjoyed it as much as I did, a familiar route, made more spectacular by a hole new perspective.

Thanks to the winter season now, in a few days time my shoes, that are now clean, should be dry enough for my next run. Part of me even hopes that for my next race, in about 2 weeks time, the weather tosses in a good downpour just for the funzies.

Wine Adventure Trail Run @ Warwick - Reme Le Hane's 14.3 km run

Help me as I raise fund for the animals while I run for the Cape of Good Hope SPCA in the Sanlam Cape Town peace Trail Run 22km.

Running for the animals

Wine Adventure Trail Run @ Warwick Wine Estate was originally published in Running For A Cause on Medium, where people are continuing the conversation by highlighting and responding to this story.

25 Jun

Running for a cause: Mid Year Trail Run @ Muratie

It was a very cold start to a pretty great run this morning, gloves, sleeves and rite until the gun, even the breaker.

A nice big crowd getting ready for the 12km, getting ready to enjoy some spectacular views. The sun was just starting to warm things up a bit, but that was short lived, as after 2 quick corners we were back int he shade of the mountain and climbing away. Would be a good 3 or 4km before we found some sun again.

Felt a bit tougher than it was at the start, felt almost like I was pushing too hard at the beginning, maybe it was the cold, maybe I just rested way too much this week :D.

But near the 7km mark, after a 20 second walk break and a 6 word pep talk off I went, and I was pretty impressed with my time, so maybe the pushing was all in my head, but I can see the training is definitely paying off, and back into full swing the coming week.

Running for the animalsMid Year Trail Run @Muratie - Reme Le Hane's 11.8 km run

Running for a cause: Mid Year Trail Run @ Muratie was originally published in Running For A Cause on Medium, where people are continuing the conversation by highlighting and responding to this story.

20 Jan

VueJS: First Impressions

With all the new libraries and frameworks it is pretty hard to keep up with all of them, and that is if you can even decide which ones are worth spending time one, over the last year or so I was exposed to many a new tech stack, with React for work and just personally playing around with React-Native, Aurelia and Angular2. Each of them attached to a new project, partly justified by wanting to try it out or form my own opinion.

Previously I had written about Aurelia, which I was very impressed with after than Angular 2 disaster, if you like, you can read more about it here:

Aurelia: First impressions

This time round I decided to dive into Vue.JS, a lot of good things are being said about it on the web, with it apparently being faster than react, with it’s implementation of Snabbdom, a simple and powerful Virtual DOM focused on performance. On top of that is is notably smaller than React sitting around 14kb.

Of all the frameworks and libraries I have worked with over the years, one thing that stood out to me about Vue.JS was the documentation, very detailed and easy to follow, covering multiple use cases and all the various options, where applicable, for each of it’s built in methods.

Now for a look at the code, the following example is for a very simple component, written in absolute bare-bones, just for you to get an idea of how things are structured..


Vue.JS uses a template file containing both you template body and a script section, and these files are saved with a .vue extension.

Vue.JS itself is completely template agnostic, you can use handlebar/directive template as above, you can also use JSX, or even build it up very manually using es5 or es6 string interpolation if you prefer.

This file pretty much handles it all, you will define the HTML structure as well as relevant scripting logic, and either define a <style> block or import a style sheet like in the example.

The script tag is where all the real work begins, we start by importing Vue and whatever components we intend on using within the component.

name: 'Events', components: { 'header-bar': Header, 'search-bar': Search, 'list-data': List, 'footer-bar': Footer, },

Above we have a snippet from the default export object, we start with the components name, followed by a components object. This object defines a key which is the tag name for the HTML element within our template with its value being the component we imported a little further up.

Next we have some of our methods to control initial logic and define usable functions.

data() {  return { data: [], searchTerm: {},  }},

The data() function is used to setup default data for initial rendering of the component, here the data key is setting itself as an empty array as later when we fetch the data it will become and array of objects, and we do not want to break the render by defaulting with invalid data types.

created() {  // API/Service calls would go here  return { data: [ {}, {} ],  };},

created() is similar to reacts componentWillMount life cycle method, this is the best place within the life of the component to go fetch any data that is not available on initiation of the component, in this case to go fetch the actual list items.

methods: {  search() { // Search method written here  },}

methods() is where you define functions that will be used within the component itself, or passed down to a child component as props, as is the case with search(), the child Search component will receive this method via the props, and this will then be fired off when a user interacts with the search component.

One thing that was not specifically included in the example but was was referenced was props, like react and probably many other libraries at this stage, Vue.JS also supports props, and like react they can be anything that a child component needs, be it static text, a function, and array of data needing to be looped over, or an object with key value pairs for simple dynamic display.

Props are quite simple to define, within the default export you would add another key, called ‘props’ with an array of all the props it is expecting to receive.


Above would then be an example of the search component, as you can see it is taking in 2 props, the submit method and term, which is a model for handling the search value that will be passed into the function.

This was just a taste of what is possible with Vue.JS, you will see many more examples by visiting their documentation at Vue.JS docs.If you wish to quickly spin up an application and start playing around with Vue.JS, I can suggest taking a look at the Yeoman generator created by FountainJS.

Working with Vue.JS was a great pleasure, I found the learning curve very shallow, however that could purely be based on my experience, as mentioned before I have worked with a few in the past.

The default template structure feels very similar to how it was working with Angular, so developers coming from that background may pick it up a bit faster than they would react. I cannot really go un-learn react to see if it influences how easy it was to pick up Vue.JS.

VueJS: First Impressions was originally published in Hacker Noon on Medium, where people are continuing the conversation by highlighting and responding to this story.

11 Nov

Aurelia: First impressions

Recently had a small personal project that I wanted to rebuild, a project I had initially started quite some time back using AngularJS 1.x, but had never gotten around to finishing it.

Since then, there have however been countless changes in the Javascript world, with ES6 and all the new frameworks available, it seemed a better idea to simply start over with something newer. My first consideration was React, as currently at work we are developing with it, and I had recently used React Native to build a mobile application, it seemed the logical choice, also in part as it is to be the web version of the mobile application, Lusus.

Then I remembered that Aurelia, something that was on my 2016 ToDo (learn) list, and being both a small and personal project, there was no harm in trying something new, not like it had any actual deadline. Worst case scenario, I dislike the framework, formed a valid opinion and can try something else.

Having worked with both AngularJS 1 and 2, I was not really sure what to expect from Aurelia, it was the idea of Rob Eisenberg as he was not happy with the direction the team was taking with Angular 2, and personally neither was I, quite frankly I found it to be a horrific disaster, but that is my opinion…

Starting off could not of been easier, a quick spin up of the Aurelia skeleton navigation application, ES6 flavor of course, and I was off.

My zero second impression was confusion, expanding the ‘src’ folder in Atom to find a mess of files with no apparent structure, which is not something I am used to, but very easily rectified to my personal preferences.

Having read none of the documentation, watched no online tutorials and effectively going into the framework all but blind, I expected just jumping in to be more difficult than it was, it however felt both familiar and different at the same time.

From AJS 1.x I would have to say some of the more menial things have been simplified, including modules/components is a simple require tag.


If you take a look at the block above you will see 2 ways of including a component, the first could be considered a ‘smart’ component which contains a view with logic, where both files share a name and only differ in extension.

Second would then be ‘dumb’ or a simply view component, containing no logic.

Rendering those imported components are just as simple, following the same convention as your file name.


Binding logic to your components is almost intelligence in the way it wires everything together, firstly you do not actually need to specifically reference the JS file within your component, everything is wired together with the extension-less ‘require’.

This does mean however that there are some rules around naming your files/classes. File need to match, and class names need to be the CamelCase version of the file name.

For data binding, you simple need to import ‘bindable’ module, declare your binding reference, and add in an optional change handler, useful if you need to do any modification to the data for view purposes, like date formatting.

There was definitely some learning that had to happen, but I would have to say that this is how I would have imagined AngularJS 2 to have turned out.

This is not to say that Aurelia is perfect, and maybe I still need to do some additional learning, but I found it’s error logging and failure handling a bit too graceful and silent. No errors are logged to the browser console when you made a typo for example, so you will make a change, things do not line up and the application just sits there in the browser in a state of limbo with no indication as to what is wrong, not even a useless message like ‘error’ shows up.

API Call fails and you have not written specific handling for it, it either returns to the previous view, or hangs again without any indication, this could of been intentional as well really should be handling errors ourselves, but I still feel it is a bit too graceful.

Also just really silly, with the build in gulp processes, the build which is used for dev minfies the index.html, but the export (production) step does not, not even 10 seconds to fix it, but still funny.

All in all, anyone coming from AngularJS 1.x looking to move into the next generation, I would highly recommend Aurelia over Angular 2.x, there is infinitely less stupidity and bad decisions in Aurelia, and a much stronger familiarity.

VueJS: First Impressions

14 Sep

Rendering HTML in your React Native application

Working with RAW HTML in React native is unfortunately not a simple task, for an application I recently developed, the event descriptions were raw HTML coming from the database.

Currently the best option available within react-native itself is the WebView, however I found this to be a component to be very similar to the web iFrame, which means that certain things that we would like to be simple are not quite.

While it is pretty simply to place the raw HTML into the WebView, it does need to be manually or programmatically sized, not something natively taken care of by the component. The best solution Google provided me with for doing this programmatically was THIS, a solution by Github user danrigsby. A great solution, but not exactly what I was looking for, for my application.

A simple approach injecting some additional scripts into the view and using that to help calculate an appropriate height.

The alternate to that would be setting a fixed height which could result in a scroll bar being added tot he WebView component, this however could easily result in a UX issue when, like in my case, the parent component is a ScrollView component. Depending on the users device screen size and pixel density, we could end up with both the ScrollView and WebView having scroll bars.

Additionally, styling the contents of the view, to better align with the rest of the UI would require similar solution, passing style sheets into the WebView container or even worse, having style attributes within the HTML itself.

A possibly nicer solution…

Further searching gave me a very well developed component by a Github user jsdf, and his component react-native-htmlView.

It does a fantastic job of rendering the HTML natively in the react native layout, with the option to pass in a standard react native styles object referencing standard HTML elements.

Sample implementation code:
var React = require('react')var ReactNative = require('react-native')var {Text, View, ListView} = ReactNativevar HTMLView = require('react-native-htmlview')var App = React.createClass({  render() { var htmlContent = '<p><a href="http://jsdf.co">&hearts; nice job!</a></p>' return ( <HTMLView value={htmlContent} stylesheet={styles} /> )  }})var styles = StyleSheet.create({  a: { fontWeight: '300', color: '#FF3366', // pink links  },})
Real world implementation result:

Considering the image above, everything underneath ‘More Info:’ is the HTML brought in from the database and being rendered by the react-native-htmlView component.

I found that using this, at least for me, resulted in a much simpler implementation, that looked more like it belonged on the screen with all the HTML displayed.

I am pretty sure displaying content directly from a database is quite a common use case, something that the React-Native teams really needs to consider for some enhancements on the native WebView, until then, kudos to jsdf for the great component.

See the app in action on your device:Lusus on Android | Lusus on IOS (Coming soon)

23 Aug

Developing: First mobile app

Recently had an idea for a very simple mobile application, having been a runner for some time I already had an app for finding running events, but when I recently took up cycling I was surprised to see that nobody had created something similar for cyclists. While probably not a massive need, it is a nice things to have as most sites do not cover all available events, so a single source is handy.

As a Front-end/Web Application developer my first instinct was to head towards a hybrid solution, as Javascript is my strength and I had already gained some experience through work on a past project using Ionic, so it seemed like a good idea t the time.

As it was my own project, I decided on the riskier approach and went for Ionic2, which at the time was still in beta, biggest reason for that was the idea of killing 2 birds, maybe even 3, this way I would gain experience with IO2 and learn Angular2 in the same breath as well as hopefully end up with a pretty decent app.

The process started out quite simple, getting most of the view components setup and working was easy enough, the complexity began to come in when working in actual logic and reusing the components I had written, I quickly became unimpressed with what I believe to be extremely silly changes Angular made for V2, things that used to be dead simple like providers (formally services) had developed additional steps that to me seem quite unnecessary, like having to import and bootstrap a service within the parent layer (formally run method), before I could import and use it within a component, and unfortunately being in an RC state, it was quite frustrating having to find solutions to problems that quite frankly should never of existed to begin with.

In the end I persisted, not one for giving up easily, I figured there had to be a way to win within this scenario, so I carried on with the project and managed to get what I felt was a decent first stab completed.

As this project was the precursor to a larger idea that a friend and I were working on there was some waiting to be done before it could be submitted to the store, some general copy and designs and such.

During this time, I had heard about React Native from one of the guys at work, and as the project I was on was a React one, it seemed like a good idea to look into this, I was impressed with the idea of coding in JS to yield a native result.

While I had expected that this was likely to result in a faster application, I was most pleasantly surprised by the results, even in the initial stages the performance advantages were obvious, and being so close to react itself (it is dependent on it), it was pretty simple to learn, it was very well documented with proper code samples to go along with it. I only ran into a few hiccups, having come from a mostly FE background, some of the strictness was frustrating, even though understandable, at first, writing a stylesheet with no cascade as a Javascript object…

React Native also explicitly uses flex to control it’s layout, which is quite fantastic, but a little complicated when you are not familiar with it and its caveats, this is made even more complex by the lack of inspect tool that I had become so used too, a bit of a time rewind having to build layouts with the old ‘Save and refresh’ method, as the debugging version of the application is still an APK that gets installed onto an android emulator, or physical device if you connect one up. You can still make use of a browse for some debugging, but that is limited to what can be done in a console.

It did take a bit longer to develop the actual application in React Native, with the additional complexities, but the end result was a much better performing application.

Comparing the Ionic2 and React native applications, the most noticeable difference was start time, the Ionic2 took nearly 7 seconds before the first screen was displayed, while React Native was far closer to 2. From a users perspective, an application loading 3x faster is an absolute no brainier.

A final note, React Native, is not 100% pure native as the name may suggest, you still have your Javascript running, just with a far deeper integration into the device’s capabilities and methods, while the performance is excellent, and far exceeds that of a truly Hybrid/Webview solution.

If you are looking for something that yields a truly native result, a good option to look into would be Xamarin. I have no personal experience with it, but it has got a few more years under it’s belt than React Native which is currently still in RC, I would expect that in some cases the performance would be better at this stage and it is likely that it has better/more support within the specific OS’s, only time will tell what React Native can really do.

To read up more on React Native:Main website| Getting Started| Performance

App links:Lusus on Android | Lusus on IOS (Coming soon)

Rendering HTML in your React Native application

30 Mar

Automated deployments to Digital Ocean using Wercker

A few of these articles may already exist, but as I am pretty sure I have been through them all I know that they are lacking some explanation and information, there was quite a bit I needed to work out for myself to finally get it working properly.

lets start off with what wercker is, in simple terms it is a platform you can use to perform automated deployments of your code, so the simple steps of ‘git commit’ and ‘git push’ can now also publish your application to the web, be it staging or production, or any other environment you need.

Within this guide I am making a few assumptions, 1 of them is that you are using node, but that is not a requirement and configurable in our .yml file that we are going to build up, the other is that you already have an existing repo with files in it on either github or bitbucket. If not, you can set that up and then pick up at the next paragraph.

When you perform a push on git to a specific branch, your app will then be containerized by wercker and then pushed over to Docker Hub registry, similar to github to an extent. Once done, we will have our Digital Ocean server pull that docker image down, remove the current one and then run this new one. All nice and automagically.

Step 1: Account setup

If you do not already have accounts for both docker and wercker, go ahead and set those up now, no point proceeding without them:

Step 2: Wercker setup

Start off by creating a new wercker application and linking it to your project n github/bitbucket repo.

To enable communication between Docker Digital Ocean, we need to setup some environment variables and an SSH key.

Head over to application settings > ‘Environment variables’ and then add in 2 new variables, ‘DOCKER_USERNAME’ and ‘DOCKER_PASSWORD’ and make sure ot check ‘protected’ for the password to hide the actual text from the logs.

Let’s also create ‘DOCKER_REPO’ and set the to your repo path ‘<username>/<app-name>’ and ‘APPLICATION_NAME’ and set that to ‘<app-name>’. You do not have to use the app name here though as this is simply a reference name to be used when launching the docker app.

Lastly, lets store our droplet server IP, ‘SERVER_IP’ to be the IP of your droplet server with Digital Ocean.

I prefer creating a few extra variables, that way all the important things can be updated on wercker without creating additional commits.

No click on ‘SSH keys’ on the left and generate a new key called ‘digitalocean’. Copy the public key over to a text document for now as we will need that in a minute when setting up thins on Digital Ocean.

Now still on wercker, click on ‘Targets’ on the left and add a new deploy target and name it as you need too, for the purpose of the article we will call it ‘Production’ and set the auto deploy to be ‘master’. If you were using gitflow you could match up master to production and develop to dev or qa or similar.

Now we just need to reference the SSH key we created, so back in ‘Environment variables’ add a SSH key named ‘DIGITAL_OCEAN’ paired with the ‘digitalocean’ key we created earlier.

Step3: Digital Ocean setup

This is the easy part, DI has pre configured ‘One click’ apps for use to use, so go ahead and create a droplet, select the ‘One-click Apps’ tab and then choose the currently available ‘Docker’ droplet, then just pick your size and location.

You then select ‘New SSH key’ and paste int he key you put in that text document earlier, change the name if you like and then click create, while it does its thing we will carry on with the rest of the setup.

Step 4: The wercker.yml

This is the file that contains all the instructions we need to pass over to wercker so it knows how we want the app built and deployed within your container.

Each group of instructions is referred to as a pipeline and each specific instruction is a step. Our main focus will be the deploy pipeline, this is the part that will handle moving the code from docker to digital ocean.

Start off by creating a wercker.yml file in your projects root folder, and open it with your preferred editor.

First line we need to put in is the base image, this is what wercker will use to create the container for our application, as we are using node it will be

box: node

If you were creating a python app you might use ‘box:python’

We are now ready to define our 2 pipelines, build and deploy, our build one is pretty simple:

build: steps: — npm-install

For now this step is pretty simply, all it is doing is installing our node packages, this step could be used to run automated/unit testing, as the deploy will only proceed if the deploy is successful.

Now let us move onto our first few deploy steps:

deploy: steps: — npm-install — script: name: install supervisor code: npm install -g supervisor — internal/docker-push: username: $DOCKER_USERNAME password: $DOCKER_PASSWORD repository: $DOCKER_REPO registry: https://registry.hub.docker.com cmd: /bin/bash -c "cd /pipeline/source && supervisor — watch ./src src/server.js"

Firstly we are installing supervisor, this will keep our server up and running should anything go wrong on the server, minimizes down time.

After that we begin our docker push using an internal plugin from wercker, we specify the username, password, repo and registry ( I found this to be the reason mine was failing as it is not mentioned in any guide).

Next we have our cmd (command), that simply puts the instance in the correct place and runs the node instance, so everything after watch would be specific to your application, be it ‘npm start’ or ‘node web.js’ however you launch your application is what needs to be there.

This whole pipeline is responsible for pushing our code over to docker in a docker image for us to pull in the next step.

- add-ssh-key: keyname: DIGITAL_OCEAN - add-to-known_hosts: hostname: $SERVER_IP

Following that we add our SSH key so that we will be able to access our DI droplets and then the IP to the list of known hosts.

- script: name: pull latest image code: ssh root@$SERVER_IP docker pull $DOCKER_REPO:latest - script: name: stop running container code: ssh root@$SERVER_IP docker stop $APPLICATION_NAME || echo ‘failed to stop running container’ - script: name: remove stopped container code: ssh root@$SERVER_IP docker rm $APPLICATION_NAME || echo ‘failed to remove stopped container’ - script: name: remove image behind stopped container code: ssh root@$SERVER_IP> docker rmi $DOCKER_REPO:current || echo ‘failed to remove image behind stopped container’ - script: name: tag newly pulled image code: ssh root@$SERVER_IP docker tag $DOCKER_REPO:latest $DOCKER_REPO:current || echo ‘failed to change tag’ - script: name: run new container code: ssh root@$SERVER_IP docker run -d -p 80:$NODE_PORT --name $APPLICATION_NAME $DOCKER_REPO:current

Lastly, we have all the magic, this is the part of our script that moves our code over to DI, deletes the existing instance and deploys and runs our update.

All the commands begin with ‘ssh root@$SERVER_IP’ as they are all being run on the droplet itself.

Our first step is to pull the latest image, the one we pushed up earlier.Now we stop the running containerWe then remove the container we just stopped.This is a cleanup process to remove any of the old docker images as to not waste any space.Next we tag the image we just pulled as the current image so that we can easily identify it for cleanup next time round.Finally we run our new container, here we are mapping port 80 (-p), the HTTP port over to port 5000, the port our node application is listening on. The -d flag sets teh container to be detached, aka run in the background. –name gives our application an easy name to use when starting/stopping/restarting it when needed.

You are done, now all you need to do is commit and push the wercker.yml file to your master branch and the build then deploy should run automatically.

You can see the complete yml file in this gist

Originally published at www.remelehane.co.za.