National Three Peaks Challenge

Towards the start of the year, Mark the owner of the gym I go to mentioned he was planning to do the Three Peaks Challenge for charity and was wondering if I and a couple of the other people from the gym would do it too. I wasn’t 100% sure at first, a little bit of research and having looked at the calendar turns out we had about 4 to 5 months depending on the date we would set for it so I thought why not.

Well, the weekend just gone (Saturday 20th July 2019) was the day we started the 24 hour challenge, and we finished it within 24hours on Sunday morning.

Everything you read about doing the Three Peaks Challenge talks about starting at Ben Nevis and finishing at Snowdon, but we decided to do it the other way around, mainly because we all live in Scotland and it’s about the same distance home if not a few minutes quicker.

Three Peaks Challenge results

Peak 1 – Snowdon

Distance: 12.49 km
Time: 3hours 16minutes 40seconds

We started Snowdon at 09:52 on Saturday morning, we planned to start at 10am but we were ready to go and the weather wasn’t very pleasant so we just got going. To start with the weather was dry but very low cloud. We took the Pyg Track up from Pen-y-pass, reaching the summit just around 11:30 where visibility was next to nothing a quick picture at the top to mark the achievement and then started making our descent. From the top to the junction on the ridge for the Pyg Track was full wind and rain due to the weather we opted to return on the Miners track as most of the Pyg Track path up was rock and lots of  rnning water. Having stated the hostel across the road from the car park at Pen-y-pass upon return to the van we grab a quick shower to warm back and before heading north to Scafell.

 

Peak 2 – Scafell

Distance: 9 km
Time: 3hours 3minutes 42seconds

After the roughly 4 and half hour drive with a stop for some food and fuel we arrived at Wasdale Head car park around 6:15pm, and begun our walk at 6:24pm. Having walked Scafell Peak just over a month ago we knew was was in store and to say the second time up it wasn’t any easier. Scafell is much different to Snowdon, it’s shorter and steeper which means you get straight into it and start climbing – Once you’ve walked up and across a grass field you are straight into the rocky path that’s just keeps on going. We decided to go up the shorter route which means taking the path to the right when you reach Hollow Stones, this involves a bit of a scramble up a steep loose rocky section. We summited the peak just after 8pm, quick snack and drink then made our way back down the other path to be safer. After doing Snowdon in the rain, tackling Scafell in the early evening setting sun was a completely different walk and it provided some amazing views that made the walk so much more enjoyable.

 

Peak 3 – Ben Nevis

Distance: 16.63 km
Time: 5hours 41minutes 22seconds

We arrived at the car park at the bottom of Ben Nevis just after 3am Sunday morning to tackle the last of the three peaks after a night drive from Scafell, a few hours sleep for myself, and not much for any one else is appears we decided to take a little breather and set off a 4am to give us a bit more natural light and to time our arrival back to the car park for after 9am so that all the people who had come up to congratulate us would be there. We decided to walk Ben Nevis starting at the Ben Nevis Inn.

With our head torches on we set of at a steady pace from the car park, knowing this one was the longest and likely to the be the hardest after the other two – how wrong were we! 10 miles round trip for Ben Nevis and boy you felt it, it felt so much longer. The ascent was hard going some times you felt like you had walked half a mile to check the track and only a hundred meters or so. The weather wasn’t in our favour, but for the first half of the way up it was foggy, little bits of rain here and there but generally not bad for walking, the second half was a whole other story visibility was down to around 20 meters, there was wind and rain and it was much colder than the lower slopes.

Eventually we arrived at the summit just after 7am the ascent was just over 3hours. At the summit there was a small rescue shelter we took some cover in from the elements added another layer of clothing for the descent and made some phone calls and messages to loved one to tell the world we made it. Amazing that there was 4G at the top in that weather. A 10 minute stop and refuel before we tackled the descent. Descending was quicker than the ascent but not any easier. The legs were feeling it now, the knees where starting to ache from the impacts of the descent. The descent seemed to take forever and as we thought we were getting closer to the end there always seemed to be “another” corner, looking at the clock we had to start to pick the pace up a little if we were to complete it within the 24 hours. Then we came around another corner and there was the carpark with a small group of friends and family waiting for us.

09:42 we arrived at the start of the Ben Nevis climb! 23hours 50minutes after we started Snowdon we had completed the Three Peaks Challenge.

 

2018

2018 was a big year for some personal items most notably purchasing our first house, a little late getting on to the property ladder, the last decade or more it’s been increasing hard for first time buyers, finally we managed to do it and it’s been amazing to really call a place home, and put our mark (where possible it’s a new build) on it, next year we will be able to add some more marks most notably do some painting to brighten it up — with new builds they recommend waiting at least twelve months before plaiting to let the house settle and dry out.

Owning our own house gave us the opportunity to finally add another addition to the family, that of the four legged kind. We have always talked of getting a dog (cat’s seem to be more accepted within the rental market), and during the summer we added Einstein to the family, a fox red Labrador who is amazing, and both children adore him — still not convinced Fred (the cat) has taken to him yet but there’s still plenty of time for them to finally allow me to get some pictures of them cuddled up together sleeping like best buddies.

Couple of months after moving into our home I joined a gym, not your typical gym. I wasn’t after a membership to a room full of equipment for me to eventually stop going. This gym has a focus on functional fitness, lots of classes during the week which is a big focus. As my work schedule is a little different to the normal, I work an offset day to provide more overlap with the East coast of the US I was finding that I was working too much — trying to make up time in the mornings when the US was asleep but then also feeling guilty for not being online during their afternoon hours. This was leading to me not getting out much, getting exercise and starting to mentally struggle to keep up with everything. By joining the gym that has morning sessions four days a week it provided me a way to enforce I wasn’t working too much, getting me back into shape and making new friends. In the eight months of attending the gym I am a jean size smaller (only a few kilo’s lighter) and much stronger physically and mentally.

The finally thing of 2018 that was a huge achievement was me and my wife celebrated our 10 year wedding anniversary which I’ve wrote about in a separate post.

2019.

Looking ahead to 2019 I am planning to make the year about Focus.

My primary focus will be on my family and health, professionally I am putting focus into areas that really excite me and try not to spread myself across all areas. With some recent changes this is heading in the right direction, the start of the year will provide the time to ensure steps are in place to move it towards where I want it to be.

10 Years

10 years ago, December 19th 2008 — I married the love of my life, and I promised her I would take her to New York one day. As the years passed by it started to feel a lot like Carl and Ellie’s story, an adventure that kept us both going. Next year we will go… Life carried on always with a trip to New York in the back of our minds, it would come up from time to time, life would get in the way. Three years ago we had another child and it just felt so far away this allusive trip to New York City. That was until the start of the year where we put a plan together to ensure we made it to the Big Apple this year! The plan to save and book early to ensure we did make it this year.

April 2018 we booked our flights to Stewart International, we jumped on the early release tickets for Norwegian Air’s new destination this year of non-stop flights from Edinburgh to Stewart International (requires a 90minutes shuttle to Manhattan at $20 each for each way).

With the flights booked, we were half way there to a half organized week in NYC, we kept and eye on hotel prices and waited a few months before booking them. Given we had booked our flights and were looking around for hotels, and all the tourist things we would want to do in the 5.5 days we would be in NYC I started to think to myself what could I do that would be super special for our 10 year anniversary which would happen on the Wednesday of our trip (middle of the trip). I am not sure what exactly made it jump to my mind but once I thought of it I knew I had to do all I could to ensure it happened. The plan was for me to arrange for us to renew our vow’s in Central Park. What better way to surprise Pamela and mark our 10 years together, with all life’s thrown at us through thick and thin, I knew this would be the best thing I could do for my wife, show her what she means to me and show her that I am here to stay by committing myself again to her for life!

The idea of doing a vow renewal came to me around the middle of May, and for the next couple of weeks I did all the research I could do. I thought that it shouldn’t be too hard too organise, opposed to a full on wedding where you need to get all sorts of paper work organised, and not least it being in a different country to add in to the mix. With it not being a marriage it should be less hoops to jump through. Upon my research it was apparent I wasn’t the first and not the last to think of this, and there were tons of companies you could pay to organise all the parts for you. This seemed to be the simplest and slightly more expensive option, even the most convenient and less stressful way of organising such an event. After some emailing between a few different companies to get prices and information on what’s involved with such a ceremony I decided to use Simply Eloped, after having a good feeling with the initial communications and with them being very open and forth coming, I never got the feeling I was asking to much of them, they would respond with answers to all my questions not matter how simple they seemed.

By the end of May I had it all booked up and ready, date saved, permit organised and communication with the officiant and photographer had begun. May! 7 months before the big day! How am I supposed to keep this a secret… Well that I managed to do until about 2 minutes before we began the ceremony. A couple of months out from December I had to give some details to Pamela around a possible “event” I had organised, the details I provided were that she would need to be a “Smart Casual” dress and then about a month before we were due to fly out I then told her she should look at getting her hair down in the morning, with the event being around lunch time, all the time being very careful as to not give away to many details but trying to ensure I gave her enough details to ensure she wouldn’t be annoyed to not have been prepared for getting photo’s taken.

As the big day arrived I was pretty nervous, as it was a big surprise for Pamela, and I wasn’t 100% sure how it would go down, the morning started with us going to a salon to have Pamela’s hair done, then a big a brunch as the ceremony was at 1pm which made it a little awkward to do a proper lunch, get ready and get to the location. Trying to pass time was hard, and I was trying not to say anything, I wanted to go for the big reveal and leave it to the last minute. After getting ready and heading to the subway to make our way north and into Central Park, I was sure Pamela would figure out what was going on, but turns out I was wrong. We arrived at the Ladies Pavilion which is on the West Side of central park roughly half way up the West side, not too awkward to get to on foot from a subway, thankfully the weather was good a little on the cold side but bearable. Upon approaching the Ladies Pavilion, there was someone sat in the pavilion reading which as we soon found out was our officiant – Who thought I was going to pop the question, she was surprised how young we were. I gave it a couple of moments before I asked if she was who I thought she was, someone from Simply Eloped, by replying she was Sarah our officiant I let her know Pamela still didn’t know why we were here, it was at this point I let Pamela know what we were doing in the middle of Central Park in the middle of the day on out 10 year wedding anniversary, and minutes later we stood in front of each other while Sarah out officiant gave a beautiful reading and we renewed our vows, and exchanged rings again pleading our love for each other and making the commitment once again to be husband and wife, till death do us part.

After the reading a vows renewed we spent the next hour getting photo’s taking around Central Park.

Logitech Unsubscribe “at any time”

When making a purchase recently from Logitech directly I encountered some bad auto subscribing to their marketing emails, that did not allow the user to un-subscribe at the time of making the purchase, but they did have some text telling you that you could un-subscribe at any time… Appears it means anytime just not right now.

What appears to be a valid checkbox as the Terms of Sale checkbox works perfectly, you could select and deselect that. By default that was unselected, forcing you to select it to be able to make a purchase.

This is bad marketing for logitech, I should know because I just did a marketing campaign the last month and used the best content calendar, check out AngieGensler.com to know what I’m talking about.

Being the developer I am, I thought that maybe they were just showing a checked checkbox to the user in the same manner as the terms of sale one was output. Upon inspecting their checkout page using developer tools, I found that they just never added an id attribute to the checkbox input or for attribute to the label and made the label element cover the input thus stopping me from being able to unselect the option. I removed the checked attribute from the input and continued with my purchase. I believe it saved my unchecked preference as I have yet to receive any marketing type emails as of yet.

 

 

Photo taken at: Disneyland Paris

2017 Perseid Meteor Shower

First time out to watch the Perseid Meteor Shower, also the first time taking photo’s of the night sky. After reading around during the afternoon of some general settings that should be used we set out around 9:30 PM into AE Forest to a Loch to set up camp for a few hours to see what we could see. My son lasted about an hour before he climbed back into the car and fall asleep, and I last till just after midnight before calling it a night.

Having a Canon 80D I thought the built in WiFi stuff was a bit overkill for my needs, but having to do long exposures without a remote was going to be tricky to avoid camera shake on the tripod. (Should remember to charge my phone before going out tho). Using my iPhone to live shoot also allowed me see the images captured, and also change some of the settings like ISO, Aperture and Shutter speed.

Micro.blog Desktop

I’ve been using micro.blog for a few weeks now. The new way of posting and owning my own content is growing on me and I am really enjoying posting to my own site again. One thing I found was I wasn’t really interacting much during the day, I put this down to not having a desktop app. Yes. I could use the micro.blog website, but I prefer to keep my browsers for work related and I am trying to reduce my tab count.

So with that in mind, and know there is an API for micro.blog I decided to put together a desktop app for micro.blog using the electron framework. What better way to build a desktop application than use the tools I already use on a daily basis.
Last week I had a quick play around with electron and calling the micro.blog API, and all seemed to simple to be true, but it turns out it didn’t actually get much harder. In order to keep things simple and to have a consistent UX / UI with the micro.blog ecosystem at the moment, I decided to reuse a lot of what Manton had already created in terms of the UI, and just wrap up it all up in electron and calling out to the API.

I currently have only built the App for Mac OS X until I can test on the other platforms, to make use of the electron ability to cross compile.

Currently you can follow your timeline, see you mentions and favorites and reply to posts. I plan to expand on this over time, but if you would like to try out Micro.blog on Mac OS X then you can download it from here: Download Micro.blog OS X

Micro.blog – My initial thoughts

First and foremost, I’d like to thank Manton for creating Micro.blog, and more important thank him for all the hard work he’s put in. Even more this past week during the lunch. It can not be easily launching something like this and not have some teething problems, and he’s always been around to answer people’s question and very quickly too. It’s not small feat to do this, even with the small fires that have arisen.

Having followed Manton for a few years and trying to get myself into the “IndieWeb“, of owning your own content more in the past year or so. I found there are many gaps missing in all the different steps, of fully controlling your own content but not feeling like you are missing out from the “other” service. It’s not overly difficult it you are quite tech savvy and don’t mind diving into some code. But for the non tech savvy people the “IndieWeb” still has a little way to go. I’ve found myself a little confused on certain aspects and still need to read up on some of different aspects. When Manton mentioned he was working on something to allow for the indieweb of short posts, which he has called Micro.blog I dropped my name into the hat (added my email to the list), and then when he made it into a kickstarted, I jumped straight on board and signed up.

A few months on after the kickstarter got funded Manton has invited the backers first into the system. Being an early backer inside the first 100 I got into the system within the first couple of days. Which was great, but to be honest maybe a little intimidating as I wasn’t sure what to expect. How would I use this, what would it replace? You can follow me on micro.blog if you are a backer, at micro.blog/matthew.

Currently I don’t do the whole POSSE (Publish (on your) Own Site, Syndicate Elsewhere), I do more PESOS, Post Elsewhere, Syndicate (on your) own site. Mainly due to the tools and amount of tinkering that’s required. There are many people are doing POSEE very well. But I like that I can use the app’s of other social networks, publish via them and then have my site pick it up. This is what I do with Instagram. I have a couple of plugins install to fetch the posts over, and it even pulls the image across and puts them in my S3 bucket. (Instagram plugin by DsgnWorks, Amazon Web Services, and WP Offload S3 Lite)

I plan to initial use Micro.blog in the following way, based on the current feature set. Over time I am sure I’ll adjust it as it grows. I believe as more people start to use the platform the more it will evolve, and I’ll adjust as I see fit.

  1. As a IndieWeb RSS Reader
  2. Post from the Micro.blog iOS – once I can get the titles of the posts in my WordPress install to save how I want

IndieWeb RSS Reader

This is the biggest thing missing in the IndieWeb at the moment, a way to truly follow other peoples “micro” blogs in a nice timeline manner. I started on a path with my own RSS Reader to try to emulate a timeline based view but never delved into the IndieWeb consumption. Now Micro.blog is around I may have a bit more of a play with my own reader, but I am hoping Micro.blog’s platform will mean I don’t have to. (RSS is only a text medium, but it’s a pretty crazy world to go into an start consuming and parsing).

The only downside I see at the moment to the Micro.blog approach is if I reply to someone’s post I would love for that to create an entry on my site. It creates a web mention on the users site but I would love for it to create an entry on my own with a reply format. This way it keeps a history of conversations I’ve had.

Posting from the Micro.blog iOS

Another thing that keeps me going back to twitter or Instagram to first post there is the ability to do it quickly. This is where the Micro.blog iOS will win me over (one I fix the blank titles). Having the ability to easily and quickly post “Micro” posts to my site will mean I’ll more likely do that than reach for Twitter. My content will still reach Twitter via cross-posting but I’ll truly be doing POSSE.

UI Testing with Nightwatch.js – Page Objects

I have already written a little about UI testing with Nightwatch.js. This was a little while ago and nightwatch.js has changed a little since then. In v0.7.0 they changed their implementation of page objects and added enhanced support. Nightwatch is a great framework for writing UI tests, and it easy to pick up an write some basic tests. But, if you are going to be writing lots of tests which you are more than likely going to, to ensure your UI is working as planned then you should really be making use of page object within the Nightwatch framework. Page objects are going to save you a lot of time, and prevent duplicated test code. By using page objects you able to abstract away a lot of the HTML actions needed when you are accessing and manipulating your pages. Also by using page objects you can increase your test coverage as you reuse the objects in multiple tests.

There are two parts to the page objects in the Nightwatch framework. Elements and Sections. For me, you need to be using both combined to get the most from the page objects. This is where you will get the most of them. To highlight this I’ve put together a couple of examples to explain how elements and sections work. Following on from my first post: UI testing with Nightwatch.js. I will be using the test from that post, and making two more test files, one that uses elements, and another that uses elements and sections together.

Getting started with page objects

Before you can get using page objects you need to update your config file to tell Nightwatch where to look for your page object files. In your Nightwatch config file you need to update the property:  page_objects_path. Mine looks like: 

"page_objects_path": "page-objects",

I am putting all my page objects inside of one folder so I use a single value in my config. Nightwatch allows you to set the value of page_objects_path as an array, with each element in the array a folder path. As your UI tests grow it might be worth looking at splitting them up into multiple folders for better maintainability. Each page object should be within it’s own file. Nightwatch will read the contents of each folder and these will become your page objects you can use within your tests.

Using Page Objects in your tests

Once you have updated your config to pull in the page objects you need to reference them inside of your tests to be able to call the commands or using the elements. You can name your files how ever you like, I name mine all one word using camel case if needed. You can use hyphens, underscores or even spaces in the file names if you so wish. Depending on how you name your files will matter, as you will need to reference the page object differently inside of your test files. All your page objects are available to all your test on the function argument .page context. I stick with the argument being named browser as per the Nightwatch documentation, but you can use whatever you wish.

The reason I keep the filename to camelCase is because the browser.page is a JavaScript object of all your page object files and folders. I have a page object file named simpleLogin.js which I reference in my tests as:

var login = browser.page.simpleLogin();

If you where to use hyphens in your file name you would need to use the following syntax.

var login = browser.page['simple-login']();

You can make your page object folder have nested folders. This would result in the browser.page object have a key for the folder name which is an object containing the page object files within that folder, you could then call that object like:

var login = browser.page.folder['simple-login']();

Page Elements and Sections

Page elements, or elements as they are referred to within the code are a way to reduce to keep the selectors you use in your tests DRY (Don’t repeat yourself). Rather than having to write the same selector over and over again in you test file you can add it as an element. An element is a property of a page object that have a selector attached to them. You can then use the element name in your test to reference to the selector of the HTML element you want to test for. This allows us to remove the duplicated selector references from our test files and move them into a single file. By doing this we only have one location to change if at a later point in time you are refactoring you application and change the class or ID of the element you are using in your test, you just need to update the selector value in your object file and all the test’s using that element will get the new value.

From the tests in my previous post, switching the selector I was using into page elements gives me the following elements

elements: {
  username: {
    selector: '#username'
  },
  password: {
    selector: '#password'
  },
  submit: {
    selector: 'input[type=submit]'
  },
  error: {
    selector: '.error'
  }
}

If you look at the Nightwatch documentation for page elements you will see there are a few different ways to set up you elements object. I go with the name of the element then an object containing selector and value. As you can see from my example we have four elements, username, password, submit, and error. Each have a selector value that corresponded to an HTML element within our page. You can split your elements down into sections if your object is dealing with a lot elements, you could split your elements object into sections to allow for better maintainability. See the Nightwatch documentation for more on using element sections.

To show you how you could use page elements in a test, here’s our initial test written without using page objects:

'Login Page Initial Render': function(browser) {
  browser
    .init()
    .waitForElementVisible( 'body', 1000 )
    .verify.visible('#username')
    .verify.visible('#password')
    .verify.value( 'input[type=submit]', 'Log In' )
    .verify.elementNotPresent('.error')
    .end()
}

Here’s the same test written using a page object that contains just page elements:

'Login Page Initial Render': function(browser) {
  var login = browser.page.simpleLogin();

  login.navigate()
    .waitForElementVisible( 'body', 1000 )
    .verify.visible('@username')
    .verify.visible('@password')
    .verify.value( '@submit', 'Log In' )
    .verify.elementNotPresent('@error')

  browser.end();
}

As you can see it’s not any shorter in length, possibly longer if anything. First off you need to setup the page object you wish to use in your test, you do this by setting a variable with the value being the page object. Then you start your test chain using this new variable, you can then make use of the elements from the page object by using the name of the element prefixed with an @, as you can see I’ve replaced #username with @username.

Page Commands

Page Commands, or commands called by the Nightwatch documentation is what makes using page objects all the worth while. By using commands you can make your test files really DRY, and move the bulk of your test logic into the page objects allowing future developers or tests who need to contribute to your test to reuse blocks of test’s without having to reinvent the wheel.

Commands are functions that contain logic for reuse in your tests, if you find yourself writing the same assertions or verify statements over and over, you should look at using a command. A really common example would be having to click submit on a form, rather then each test having the same code to click and verify something to do with the form submission you can wrap this up in a command and call the command inside of your test. Commands will still output to the terminal or your report for assertions and verify statements, there is no drastic difference between using a command verses having the test code within the test file. Using commands inside of your page objects make things more maintainable, and helps others who may need to write tests that touch parts of the page you have worked on.

If we take our first test, that’s not using pages objects and show you how we could write it using a page object that makes use of elements and commands

'Login Page Initial Render': function(browser) {
  browser
    .init()
    .waitForElementVisible( 'body', 1000 )
    .verify.visible('#username')
    .verify.visible('#password')
    .verify.value( 'input[type=submit]', 'Log In' )
    .verify.elementNotPresent('.error')
    .end()
}

Here’s the same test written to use page objects with elements and commands:

'Login Page Initial Render': function(browser) {
  var login = browser.page.commandsLogin();

  login.navigate()
    .validateForm()

  browser.end();
}

Sure makes our test a lot smaller, that’s because we have moved the logic into a page object command named “validateForm()”, which now contains the test logic for validating the form is present, inside of the page object we have the following

var loginCommands = {
  validateForm: function() {
    return this.waitForElementVisible('body', 1000)
      .verify.visible('@username')
      .verify.visible('@password')
      .verify.value('@submit', 'Log In')
      .verify.elementNotPresent('@error')
  }
};

module.exports = {
  commands: [loginCommands],
    url: function() { 
      return this.api.launchUrl; 
    },
  elements: {
    username: {
      selector: '#username'
    },
    password: {
      selector: '#password'
    },
    submit: {
      selector: 'input[type=submit]'
    },
    error: {
      selector: '.error'
    }
  }
};

As you can see, we have page elements and commands combined in our page object file for our login page. Overall a bit more code than our very first test, but this is a simple example, if you look at our other tests which is all on my GitHub, you will be able to see how I have used page objects that combine both elements and commands.

Take a look around the updated nightwatch-demo repository to see the other test’s and how I’ve switched them over to use page objects. You can even clone it or download the repository, I’ve updated it to contain all it’s required dependencies, and all runs from an npm install (tested on a Mac and Travis-CI only)