Chris Blyth - aka BlythMeister

Blog Posts

The Technical Details Behind My Blog

 28 July 2017 |  Edit Post |  View Comments
 blog, wordpress, GitHub Pages, CloudFlare, BootStrap

Overview

The full scoop on why and how I created my own GitHub pages hosted blog and the technologies I used

Why Go Self Designed?

This started out as a learning exercise.

I have played with GitHub pages before on my Gallifrey project & also played with CloudFlare there too, but it was all based on standard GitHub pages templates and no blogging capability.

I have also used Bootstrap on a couple of work projects, so wanted to experiment and get more familiar with the inner workings of GitHub pages, or rather Jekyll.

I had also never linked or worked with things like comment sections, or social sharing. Both are key to a successful blog, so this would be some interesting learning along the way.

The Design

My idea was simple, keep it clean and minimalist. But when on mobile, really strip down so only the content is on show.

I wanted a gradient background from my favourite HEX colour (#ABCDEF) to white with a white rounded content panel sitting dead centre with a little shadow.

The content panel is the broken down into 4 sections:

  • Header
  • Content
  • Sidebar
  • Footer

The header is a little under-utilised at present, I have a very simple title and navigation links.

The navigation links compress into a drop down on mobile to save on screen space which is a nice trick I learnt how to do using bootstraps styling to show or hide different content on different screen sizes.

Content

The content area is quite rightly the largest section, it’s easy to read with black text on white background and it nicely framed with borders on all sides joining other content

The sidebar is only visible on medium or large devices (i.e. phones or portrait tablets will not show it).

I’ve broken the sidebar into 3 vertical sections.

The first has my photo and links to my social networks. These icons are provided by Font Awesome They provide a CSS you can link to and add CSS tags to include little images. With a bit of styling, these become link buttons with a nice hover effect!

The second is the latest 3 blog posts I have made (plus RSS link – another font awesome icon).

The third is a widget with my Twitter timeline (created by Twitter).

The sidebar helps keep the content from looking too wide on larger screens, whilst also providing links off to other useful items.

Like the header, this is very underused. I think in the future I may have some additional content to put here, but not sure what just yet!

Blog Posts

Design/Layout

I wanted to keep things how people expect to see blog posts, to up top we have the title, the publish date some tags and a comment count.

This is followed by social sharing buttons provided by AddThis. AddThis enable automatic recommendation of what social sharing to show based on usage, but I’ve gone with the static I choose approach for now. They allow for remote customisation of the buttons on their side which update in real-time & provide metrics on social shares which is kind of cool!

The main content of the post is separated from the social sharing with a horizontal bar top and bottom.

Under the post content is the Disqus. I’ve also never used Disqus before and it was surprisingly easy to add to the posts. A quick sign-up process and a bit of Javascript and we are up and running. Again, Disqus has analytics and comes complete with comment moderations by default

Post List

As with most blogs, there is a standard page with all the posts, I’ve gone for a paginated approach with a maximum of 5 posts per page. This it the bit that took me the longest to get working due to the complexity of Jekyll in this area. There are a lot of tricks you need to know to get it working such as not using perma links and the page must be HTML and not markdown!

The net result though after that effort is a nice thing, I’ve made sure to include the date, tags and comment count on these too, but there is no sharing.

This page also (like the sidebar) links off to my blog RSS feed.

Static Content

I had a couple of pages on my old Wordpress blog talking about me, my open source software and links to other blogs and websites I read/follow.

I’ve migrated these pretty much as was, but plan on sprucing that content up as time goes on as it’s a little outdated looking.

Hosting/DNS/SSL/Caching/Analytics

Hosting

The site is hosted purely on GitHub pages, this is free to use (if the repository is public). It also means that I can get reader updates should I make any silly spelling mistakes (which is almost certain to happen). This was a completely trivial exercise of creating a repository on GitHub.com and adding my pages to it!

DNS

It took me a while to decided exactly what DNS I wanted to get and settled with blyth.me.uk. A CNAME file in the root of my repository and a few DNS records added with my DNS provider and I was up and running!

SSL

You could say that for a site like mine SSL is overkill. But when a service like CloudFlare is offering is as part of their free package you would be a fool not to take it!

All I needed to do was update my DNS nameservers over to CloudFlare, they migrated the entries I had already created with the DNS provider. Having turned on “Always HTTPS” they even handle the automatic redirects for me!

Caching

Linking nicely from SSL, CloudFlare also provide free caching. This doesn’t support HTML files as standard, but you can create a page rule to state all content on the domain should be cached. I’ve set this up with a 2-day cache in CloudFlare for all content.

This has caught me out once when making changes but a quick cache purge on their website and I could see my changes instantly!

Analytics

The WordPress site I came from had analytics all built in. I didn’t want to lose this visibility, so have added Google Analytics to my site. I already had a Google Analytics account setup from Gallifrey, so this is just a second “Property”

SEO

Jekyll has a neat plugin called Jekyll-SEO. This takes some configuration information on the site and adds a whole load of meta content into the HEAD of all pages. This helps improve SEO and means links on social networks get nice looking cards!

The Cost

The cost was something I wanted to keep as low as possible.

I think I have achieved this, my only cost being my domain name.

A win for hosting yourself I would say!

New Blog

 25 July 2017 |  Edit Post |  View Comments
 blog, wordpress

Introducing my new blog designed by myself (no nasty templates!) and hosted in GitHub Pages

My old Wordpress blog is here and over the coming days I will be migrating selected posts here with their original publish dates & updating the WordPress site to link here, so watch this space.

The site is almost complete, there are still a few things I need to update such as:

  • Content updates
  • Custom 404 page
  • Social shares on posts
  • Auto tweet from my twitter on new posts
  • Custom domain
  • CloudFlare/SSL
  • Maybe more things…

Migrating Multiple Folders Between GIT Repositories

 07 June 2017 |  Edit Post |  View Comments
 git, GitHub, History, Migration, Move Folder

The Brief

I recently had a situation where I needed to move parts of a GIT repository over to a new repository but wanted to keep all the history from the original repository.

The Research

After a bit of searching on google and finding many resources on “the best way to do this,” I ended up hitting a wall.  The overall thought patterns I found looked good, but there was no one size fits all “tutorial” for how to do this.

The Eureka Moment

After muddling through (and deleting my local copies of the repository many times!) I finally managed to achieve what I wanted.

A pull request in each repository one deleting the folders with my code, and the other adding them complete with all their history (that second pull request looks very scary with a lot of commits)

But how did I do it I hear you ask…well…this post aims to make this easier for everyone, so keep reading!

The Process

The process documented below states all the git bash commands you’r going to need.

Start from any folder you have on disk, we going to leave it clean at the end :)

At various parts in the process, you will need to modify the command to put your own variable content in.  These are shown with text in brackets.

Get Your Source/From Repo

To prevent screwing up any local copies of the repo you already have, I suggest a clean pull and remove remote.

git clone (URL-to-from-repo) FromRepo
cd FromRepo
git remote rm origin

Clean Your Source/From Repo

Since we only want the history to contain certain folders, we can run a command to completely remove everything outside of these folders from history - essentially rewrite history with just the bits we want. - This may take some time if you have a lot of history.

After this, we are done with this repo, for now, so move back up to the root folder.

git filter-branch --index-filter 'git rm --cached -qr --ignore-unmatch -- . && git reset -q $GIT_COMMIT -- (folder-paths-space-seperated)' --prune-empty -- --all
git reset --hard
cd ..

Getting You Destination/To Repo

We need a fresh copy of our destination repository again, this prevents us screwing up any local copy we already have!

git clone (url-to-repo) ToRepo
cd ToRepo

Linking Our Repositories

Next, we want to get the Source/From repo into our Destination/To repo onto a branch called “feature/RepoMigrate”

git remote add FromRepo (full-path-of-from-repo)
git pull FromRepo master
git remote rm FromRepo
git branch feature/RepoMigrate
git reset --hard origin/master

Pushing Our Migrated Folders

Now we have all our folders in our repo, we can them into our repository and we are then done with this copy of the repository too.

git checkout feature/RepoMigrate
git push origin feature/RepoMigrate
cd ..

Clean Up Pass 1

So far so good right? - we have got the branch ready to put the important parts of the source/from repository into the new one, so let’s have a tidy up!

rm -rf FromRepo
rm -rf ToRepo

Removing Folders From Source/From Repository

We need a fresh copy of the source/from repository to work with to perform these updates and we also want to be on a branch to perform this clean-up

git clone (url-to-from-repo) FromRepo
cd FromRepo
git branch feature/RepoMigrate
git checkout feature/RepoMigrate

Remove and Commit

For each folder you have migrated you want to remove and commit the removal

rm -rf (folder-path-migrated)
git commit -a -m 'Remove migrated folder (folder-name) as moved to (new-repo)'

Now Push & Tidy Up

You’re almost done! We just need to push and tidy up.

git push origin feature/RepoMigrate
cd ..
rm -rf FromRepo

What Next?

Well, you now have a branch in each repo called “feature/RepoMigrate” one removes the folders and the other adds.

Personally, I raised a pull request onto master for each of these (and had to make some changes to get the CI working correctly in the destination/to repo)

Click-Once Deployment In GitHub

 26 June 2014 |  Edit Post |  View Comments
 AutoUpdate, click-once, deploy, Gallifrey, GitHub, publish

Overview

I’ve decided to use click once for my new OpenSource app called Gallifrey.

You can get/see the app on my GitHub account at https://github.com/BlythMeister/Gallifrey/

This blog post will try and explain the decision why we have used click once and how I have gone about implementing it.

What is Click-Once?

Click-Once is an easy way to regularly push updates out to your windows desktop apps.

Click-Once can install updates automatically on application start, or you can handle this manually within your app.

Why Is Gallifrey Using Click-Once?

We have decided to go with the manual check approach, the reason for this is that we can integrate this experience into the app, rather than having a launcher that downloads the updates. Therefore we operate in a similar way to other apps like Spotify whereby the updates are downloaded and installed, all the user has to do is restart the app.

How Does It Work?

GitHub offers a “raw” version of all its files, and this can be used to serve the application.manifest from a click-once application over the internet.

Changes can be made an published locally to disk, and then when the changes are committed into GitHub they are ready for everyone’s application to search and download the new versions.

From Visual Studio the publish of click once is done into 1 of 2 directories depending on the version of the app. The “stable” version will publish to “....\deploy\stable" whereas the beta will publish to “....\deploy\beta" This is just so that someone with a Stable version doesn’t accidentally get beta installs.

The update URL is then set to “https://raw.githubusercontent.com/BlythMeister/Gallifrey/master/deploy/stable/” or for the beta version “https://raw.githubusercontent.com/BlythMeister/Gallifrey/develop/deploy/beta/” This is the path to where the updates are, once published on GitHub.

The Gallifrey App using click-once will know to go to this URL when checking for updates. The great this about this is that pushing updates is as simple as pushing a new version into GitHub. The only pain point is having to manually perform the publish prior to the push into GitHub.

This means that we have 2 installers.  The first works from the master branch and is for the stable version.  This can be downloaded here: https://github.com/BlythMeister/Gallifrey/raw/master/deploy/stable/setup.exe The second is the beta version which is from the develop branch and can be downloaded here: https://github.com/BlythMeister/Gallifrey/raw/develop/deploy/beta/setup.exe

Both versions can be linked from external websites as the Gallifrey GitHub pages site shows: blythmeister.github.io/Gallifrey

And you can just link to a specific version as we have done on our Atlassian Marketplace page! https://marketplace.atlassian.com/plugins/Gallifrey

The Pain Points

There are a few pain points to get around with using this approach.

  • GitAttributes - Since your pushing XML and .deploy files you don’t want your Git client to change the line endings. You can add a .GitAttributes file to your repository (check the one in this repo) that will tell Git that all “.manifest” or “.deploy” files are binary and should not be compared or adjusted.
  • GitHub raw seems to have a cache of some description, so when requesting the latest and greatest version, sometimes this is out of date. From my experience, the updates are there within 5 minutes, so it’s fully workable.
  • You have LOTS of files in your deploy folders! Git stores everything in history, so the more versions you push, the bigger your repo gets. Even if you clean up the files, someone has to pull all the history in, which could over time become cumbersome. Though, we are not talking GB’s of download in Gallifrey (Yet!)

I hope that this is useful to you and I’m happy to help anyone else who is trying to get a click-once app deployed using GitHub :)

Auto Deploy To IIS Using PowerShell

 14 July 2012 |  Edit Post |  View Comments
 15below, Deployment, Ensconce, IIS, Powershell

Overview

At 15below we are using a tool called Octopus for our product deployment.  The tool works well, but it’s integration to install our web-based application products doesn’t suit our needs.

However, with Octopus we can write custom PowerShell for deploying our applications.  This got us into a situation where we have 3 different versions of IIS across our servers, each of which has a different method of installation, but we want a nice and easy way we can trigger the creates.  Cue a “clever” script.

Firstly, what are the differences between the versions:

  • IIS6 (Server 2K3 & XP) - WMI needed to interact between IIS and PowerShell.
  • IIS7 (Server 2K8 R1 & Vista) - PowerShell snap-in available for download (I would recommend using the Web Platform Installer)
  • IIS7.5 (Server 2K8 R2 & 7) - PowerShell module, installed when selecting “Scripts” from IIS role feature installer.

The solution we came up with is hosted in the 15below public source code repository and sits inside the Ensconce application (more on that in a latter blog post, or link to 15below post) on GitHub.  To see more information, or get the PowerShell scripts, click here.

The 3 PowerShell scripts we are talking about are:

  • CreateWebsite.ps1
  • createiis6app.ps1
  • createiis7app.ps1

Both the create IIS app scripts have the same 3 callable functions, these are:

  • CreateAppPool (which takes a string for the name)
  • CreateWebSite (which takes name, local path, app pool name, application name, host header value & log location)
  • AddSSLCertification (which takes website name to add to & certificate name)

Breaking these down, how does it work…

CreateWebsite.ps1

This will try to do a WMI control with IIS6, hiding any errors, but should it get a success, it will include the script “createiis6app.ps1”.  Should the operation be unsuccessful, the “createiis7app.ps1” is included.

From this, you will be able to call any of the 3 functions outlined above.

Therefore, your PowerShell deployment only needs to include this PowerShell, and you can install into IIS 6,7 & 7.5. - helpful right!

createiis6app.ps1

Using only WMI controls, the functions are all callable once included (either directly or through the create website script)

createiis7app.ps1

So, as I’ve already mentioned, IIS7 and IIS7.5 operate in different ways and both require something extra to be added to your PowerShell session.

When this script is included, it will check if the IIS module is present to be imported, if it is, it will import it, if the import fails, or it’s not there it will try to locate and install the Snap-In.

If neither of these things is present it will return you an error.

This means that you don’t have IIS6, and you don’t have the required components for an IIS 7 install.

Summary 

I hope that you may find this useful should you need to do any operations like this on your application deployment.

Feel free to head over to GitHub and check out the Ensconce application, and the IIS scripts. - You may find that the Ensconce application has other benefits to your deployment :)

Details of the Ensconce application functions can be found on the read-me within GitHub.