After switching over my blog to Gatsby and using markdown, I have been on the lookout for a decent markdown editor to use for writing. Up until now, I have been using a combination of Dillinger.io and Markdown Navigator Enhanced in PHPStorm.

I switch between a windows desktop computer and a MacBook throughout the day, so having the same software on both platforms was vital to me. I also wanted something open-source, as I’m trying to focus on making more open-source contributions.

Well, I’ve found something that satisfies both of the above: Mark Text.

I could talk about all of its features and how its interface is beautifully minimalistic, but you can read all about that on their website or if README.md is more your thing, check out their Github.

This year, one of my personal goals was to revitalise this website and get the source code onto Github.

Historically it has been a blog, and not that anyone’s really noticed, but I haven’t done any blogging lately. While I do want to maintain my blog, and I intend on continuing to post to it, I don’t think it should be the focus of this website anymore.

Moving forward, I want this website to be somewhere:

• I store technical information that I might need to refer to later.
• I can highlight projects I’m working on & try out new ideas.
• I can blog about different topics easily.

This presented a few issues for me with the websites existing setup:

• It was built on WordPress, which I didn’t find very motivating to develop on anymore.
• It was self-hosted on a server that included websites for family & friends. This made me hesitant to install new tools or languages on the server.
• The existing UI/UX of the website didn’t cater to most of what I had in mind.

Naturally, I concluded the best course of action was to start from scratch—the sort of decision you can easily take on a project that’s entirely your own.

I had recently started to use ReactJS on a few projects at Kobas and was enjoying using it, so I decided I would use that for the frontend. I also knew I wanted to utilise some form of auto-deployment for the project, as that makes development much more comfortable.

After several iterations of trying different JAMstack frameworks, I landed on Gatsby hosted on AWS Amplify.

I started the project using the ”Gatsby WordPress starter”, immediately giving me a ReactJS frontend with the data sourced from my existing WordPress instance.

This allowed me to quickly get to a point where I could work on the design using real data and recognise the functionality I needed to code myself. While I did have data sourced from WordPress, I didn’t have a comment system, contact page, search, or sidebar widgets for things like tags/categories.

I needed to decide what I didn’t immediately require, as I wanted to get the new version out as soon as possible. A design I was happy with was the first thing to get added to my MVP list. The sidebar widgets I considered design-related, the website looked bare without them, they went into my MVP list. The contact page also went onto the MVP list, mainly as it was trivial to add utilising getform.io.

I decided that I could live without a comment system, it had never gotten much engagement anyway. I also thought that if I wanted one later, I could use something like Disqus. Adding search functionality seemed the most complex out of the features I was missing, so I didn’t add it to the MVP list.

Over the next few weeks, I worked on the above MVP list. Doing my best to avoid adding more functionality along the way.

Once I was done with the MVP list, I started looking at deployment options. I wanted something I wouldn’t need to spend much time configuring. AWS Amplify fit that requirement. First, I moved my domain over to Route53. Then I pointed Amplify to my Github repository, which automatically picked up the build command in my package.json. So simple!

I’m pretty happy where I’ve got to at this point, any future development I want to do here is much more streamlined for me. More fun stuff to come I hope. 😀

While converting over my previous post of my Programmer Personality, I decided to do it again and see whats changed, as expected it has.

Your programmer personality type is:

DLSB

You’re a Planner..

You may be slow, but you’ll usually find the best solution. If something’s worth doing, it’s worth doing right.

You like coding at a High level.

The world is made up of objects and components, you should create your programs in the same way.

You work best in a Team.

A good group is better than the sum of it’s parts. The only thing better than a genius programmer is a cohesive group of genius programmers.

You are a liBeral programmer.

Programming is a complex task and you should use white space and comments as freely as possible to help simplify the task. We’re not writing on paper anymore so we can take up as much room as we need.

Find out what kind of programmer you are here !

Having the functionality of automatically being prompted to sign your commits while still using PHPStorms Git GUI means you’ll never forget to sign commits again.

To start with, the version of Git installed needs to be > 2.0, otherwise certain options we are using will not work.

On CentOS 7 you’ll need to either build from source, or use a 3rd-party repository such as the IUS Community Project in order to do that. I prefer using repositories over building from source, as it’s easier to update the packages later on.

To use the 3rd-party repository method run the following:

yum install epel-release
yum remove git
rpm -U https://centos7.iuscommunity.org/ius-release.rpm
yum install git2u

Next, if you don’t have a GPG key yet, you’re going to need to generate one, GitHub have a nice guide on this already.

Next we need to add some options to our git config, I’ve went with adding to my global configuration here, however you can set this on a project by project basis by just omitting the --global tag.

git config --global commit.gpgsign true
git config --global user.signingkey ENTER_YOUR_KEY

If you’re confused on how to get your signing key for above, again Github have a guide on that.

At this point, running git commit -S -m "Example commit" will prompt you to enter the password for your secret key.

The last part is to add the following configuration to ~/.gnupg/gpg.conf

no-tty

Now when you make a commit in PHPStorm, you’ll be prompted for the password for your secret key, and the commit will be signed.

I’ve been at Kobas two years now, I previously wrote about my experiences in my first month , so it seemed fitting to do an overview of my experiences since then surrounding the software we use for DevOps.

Jenkins & Continuous Delivery

At Kobas we use continuous delivery rather than continuous deployment, tool of choice; old man Jenkins .

Jenkins, although riddled with UI/UX issues, is a very helpful tool for us day to day now. We have all sorts of pipelines setup for deploying to our EPoS & Cloud servers. Having the ‘one click’ ability to release to a QA or Production environment and letting Jenkins handle all the steps that go on throughout that build process is a time-saver.

Having the ability to rollback to a previous git tag when a bug has been introduced proves to be a real lifesaver. I can’t imagine going back to releasing projects via script or knowledge.

We keep our Jenkins configuration backed up in Git as the thought of losing all the work put into Jenkins and having to start again is nightmare inducing.

Codeception & Jenkins

My latest win, and one that took the longest to achieve was having Codeception and Jenkins play nicely together for automated testing.

The initial part of that went fine, just getting Codeception to run automatically via the Jenkins build process. But then I decided I wanted metrics like code coverage, the ability to run acceptance tests via Selenium & being able to reset our testing database before each test runs.

Selenium is something I’ve played with a lot on my own machine, so setting up Selenium Grid on a server didn’t cause me much trouble.

Code coverage however has been a pain. Needing c3.php to get remote code coverage working required a number of disgusting hacks / workarounds. This was due to the way our project is setup, the main directory Codeception is in, isn’t even synced to our servers.

The results where worth the pain though I now have the ability of viewing a breakdown of code coverage like this:

(clearly not an image from our Jenkins, imagine a lot more red).

You also get a dashboard for coverage distribution and showing you the files with the most CRAP (change risk anti-patterns), my new favourite acronym. I can’t seem to find an example of that view online however.

Perhaps later I’ll do a blog post on how to set this up on an open source project and will link to it from here. (Making plans for 2020 already)

Puppet & Server Config

Controlling configuration manually might seem okay when you only have a handful of servers, I certainly manage my personal servers manually still.

At Kobas we have two types of servers, our ‘Cloud’ servers (hosted by AWS) and our ‘EPoS’ servers (hosted by our clients on-site). Currently, we have 4-5 AWS servers, and 170+ EPoS servers. Managing configuration change across the EPoS servers would be impossible without Puppet.

Puppet isn’t the only tool that handles configuration management, there are a number of tools to choose between; Chef and Ansible are two that come to mind. I’ve only used Puppet so can’t comment on the advantages of one over the other. I do recommend getting at least one of these tools setup to manage your server configuration though as the pay-off is huge.

Using a configuration management tool ensures that all your configuration is the same across every environment; development, qa and production. Significantly reducing the ‘But it works on my machine’ issue. It also requires you to put additional thought into making configuration changes.