Recently I wrote about switching my hosting away from AWS over to Netlify. As part of the process, I also moved my DNS records over to Netlify. This process was painless but in the euphoria of such easy deployment, I forgot all about my mail records.
I use Hover as my domain host and use their email forwarding service on a selection of addresses. After a couple of days, I noticed these addresses were no longer being forwarded and I felt like an idiot!
After I berated myself, I set about looking at how I managed to get the MX records added to Netlify’s Domain zone records. To be honest it was harder than it should have been. Mainly down to the non-complete documentation from Netlify. They make reference to being able to do it but for the less inclined it was not at all clear.
So this is how you add your email (MX) related records to Netlify:
Login to Netlify and head to the Domain Settings section for your site.
Scroll to the bottom of the page and look for the new DNS zones section. At the time of writing, it looked like this.
Select the zone relating to your domain.
Click the Add new record button and enter the settings.
The settings are as follows:
Type - MX.
Hostname - Will default to the name of your Netlify site name.
Value - This should be the server path for your email service. Do not include http:// or htpps://
TTL - This is the Time To Live setting for the record. The standard Netlify setting appears to be 3600 but I tend to set short TTL’s where possible.
Priority - This should be set to 10 from what I can ascertain.
Click the Save button and wait for between 15 and 30 minutes for the settings to propagate. Your email services should be working as before.
If you have any comments or would like to discuss this topic further then please message me via twitter or email.
The new year lead me to finally rebuilding my Thinkpad and swapping in a new 240gb SSD. This means a shiny new install of Antergos which in turn means a short tweaking session to make it right.
Antergos, for those that are unaware, is a version of Arch that comes with a useful installer. While Arch Linux is not hard to install it can be a distraction from life. Their documentation is superb and it is easy to get lost in pages and pages of packages and options. I have seen some articles recently which suggest Antergos is a great beginner Linux. I would argue that it is better than Fedora, Ubuntu and co but that is probably another post in itself.
The main issue I had while tweaking Antergos this time was to do with power settings and suspending on lid close. I also decided to switch back to the GDM login manager as I have never really liked LightDM.
Installing GDM and configuring it is very easy. In a shell run the following command:
will configure systemd to use it as the default login manager.
At this point, I rebooted to ensure it worked and all was as expected.
The next step was to get suspend working. By default, this time, nothing happened when I closed the Thinkpad’s lid. A little bit of Googling later and I found that first off I needed to install Gnome Power Manager:
$ sudo pacman -S gnome-power-manager
Then I had to alter the /etc/systemd/logind.conf configuration file. This file is used by systemd to define the various settings for power related events. In my file, all settings were commented out. I uncommented the following entries and updated their setting values. One reboot later and suspend was working.
The final step was to enable the Screen Lock setting. Doing so ensures that when you suspend and power back on that GDM protects you by forcing you to log back in. This can be found under the Privacy setting section in Gnome Settings.
Unusually, figuring this out took a little reading and many sources. Hence why I am documenting it here, in case it is useful for anyone else.
If you have any great tweaks or Antergos/Arch related tips then please message me via twitter or email.
When you start a company you sign up for a never-ending amount of online services and utilities. Bitbucket, GSuite, a CRM, an accounting package. These days the list goes on and on. When there is only you, the founder(s), it is easy to not give a thought about how you sign up for these services or accounts. But, you should for many reasons.
The main issue is availability. Bob Smith is a founder and signs up for some services with bob.smith@shinynewstartup.com. He starts to use the services and grows his business. Awesome! A little while into the future and one of Bob’s new employee’s needs to get access to one of the services, urgently. Unfortunately, Bob is on site for a customer and is unreachable. This is not ideal and it gets worse over time. What if the person whose email is used to access vital services leaves? You can see how this could be disastrous.
The solution? I have always found that creating a generic email group and using that is the answer. services@ or operations@ are good options. Ensure that your group contains your current senior team members. Then junior members know to approach their seniors for passwords when needed. Create a core HR policy stating that all services for core business operations use that email account. Then enforce it. Make it a core, cultural, pillar. Instil it in all your new hires.
The next thing to consider is how you manage the passwords associated with all the accounts. There is a host of password managers out there and I am not going to tell you which to use. Some have super useful features but a lot also have been compromised. So do your research and decide on the risk to your business should your passwords be compromised or go offline. Also, think about how you would handle a manager service going offline.
My current approach is to use KeePass to generate and store passwords on a synced drive. There are a few useful sync tools such as Dropbox and Bit Torrent Sync for sharing the KeePass file. The file itself is encrypted using AES and Twofish encryption. This is good enough for US Federal Government. When you create your password file you secure it with a password. That is then the only password you need to share amongst your team. I always make it a stupid phrase based on a shared TV show or song.
If you have any comments or would like to discuss this topic further then please message me via twitter or email.
Broken windows can cause big issues to occur and ruin communities. The original theory has is rooted in academia and was proposed by James Q. Wilson and George Kelling in 1982. The theory used broken windows as a metaphor for disorder within neighbourhoods. It links disorder and incivility within a community to occurrences of serious crime.
It stated that when a window in a building is broken it impacts peoples view of the building. When left for a long period of time it impacts the way community thought and cared about the building. It reflected a sense of abandonment. This would be reflected by another window being broken or structural damage occurring. Over time the building would fall in to complete disarray. It would lead to it eventually being abandoned.
The Pragmatic Programmer book is a classic within software development. Within the book, it highlighted the similarity with software entropy. They likened the avoidance of fixing small issues within a project to that of broken windows. They highlighted the psychological impact that ignoring small issues had. It affected both on the codebase and the culture of the project team. As they said:
neglect accelerates the rot faster than any other factor.
I was discussing this theory with our new Head of Product at Open Energy Market. In refining our development process he suggested that we have a day a month where we fix the broken windows.
I disagreed. I suggested that it was a bad idea for the following reasons:
We push out 2 releases a month a present. That means we are happy for a Broken Window to be on show for 6 weeks on average. From a users point of view, that’s not acceptable.
The development team culture would change. Developers would be happy to take shortcuts based on time constraints. They would know they could fix any issues on the Broken Window day. This would change the culture of the team and breed laziness and low standards. It could also impact the standard of code reviews.
Broken Window day will not always happen. Experience tells me that out of a possible 12 Broken Window days in a year, 8 - 10 will be missed. This is not on purpose or because the development team do not want to take part in them. It is because they will get pushed due to targets and commitments. Even if we did complete 12 days there is a high chance of not all developers having the capacity to take part.
Would we have the capacity to complete all the identified Broken Windows each month? If not do we roll the issues over to the next month or increase the number of days assigned to these issues?
There is another theory/rule in software development that can prevent broken windows. It is the Boy Scout rule which is outlined here.
(Note, I am quoting the original fairly dated rule. Boy Scout should be replaced with Girl Guide where appropriate.)
The rule states that you should “Leave Things BETTER than you found them”. That as you work on code you should perform maintenance and opportunistic refactoring as you go. This means that if you notice badly written code, missing tests or architectural design flaws you correct them. You may not have written the code but you fix it as part of your responsibility as a developer on the project. Every time you commit, you leave the code that was there in a better state But, the approach to be taken is towards betterment not to perfection.
This is an important definition for a team to make and include in their process. What are maintenance and opportunistic refactoring’s which can be done as part of a story? When does it move into a larger piece of work and how do you track it? These are important questions that should be decided by your team. The key thing is to ensure that any non-trivial Boy Scout tasks are added to your backlog and prioritised as tasks. If you do not have time to fix an issue as part of day to day work do not ignore it. Log it, prioritise it and resolve it.
Technical debt and small issues will always appear in any project. Instilling the Boy Scout rule as a core part of your development team’s culture will help to prevent Broken Windows.
If you have any comments or would like to discuss this topic further then please message me via twitter or email.
Happy New Year! I hope your 2018 is awesome and productive and full of fun.
I wrote a post last year about how I got this site running on AWS. For a variety of reasons, I was not happy to stay on AWS long term. These were based on cost and complexity of administration. So over the Christmas break, I finally got around to migrating the site to Netlify.
Netlify have many plans based on your requirements. It focuses on hosting frontend projects based on a variety of frameworks. A full list of features is listed here.
Setting up an initial site is very easy especially if your code lives in Git. As part of the set up process you grant access to your repo to Netlify which automatically detects commits. This is turn will trigger a new build. There is a simple to follow guide here for new sites. They support custom domains on their free tier and also provide full Lets Encrypt support. You read that right, a free hosting solution providing secure domains.
My problem came in that I already had a working Jekyll based site that I wanted to migrate over. The main issue was that my site was not configured using bundler. So the process I outline here is a mix of the new site guide and a migration guide I found here.
As per the instructions, I updated the #gem ‘ruby’ line by removing the comment character and changing ruby for jekyll. I also commented out the git_source line as I host my repo on Bitbucket and not GitHub. My Gem file ended up looking as follows:
(I also had to add the jekyll-paginate line you see in the file above as that is a gem used by my theme.)
The next step was to run:
$ bundle install
This worked but broke the site locally as now I had two versions of Jekyll installed. I only realised this after a little googling and found that the answer was to run:
$ sudo gem uninstall jekyll
This will list each version of jekyll you have installed and I found that the solution was to remove both versions that I had. Then I rerun:
$ bundle install
This reinstalled jekyll and all required gems and I now had a site running locally on my machine.
The next step was to push my changes to my repo. As part of setting the site up on Netlify, I had configured automatic builds and deployments. As soon as I pushed my commits to origin I could see the build kick off on Netlify and fail. I realised it was going to be an issue with my site and set about finding the answer.
The logs gave the following output.
After a little googling it turns out that Netlify supports many Ruby versions up to 2.4.2 (at the time of writing). You have to specify your Ruby version by creating a .ruby-version file in the root of your repo. Once created you add nothing but the Ruby version number you want them to use. One quick commit and push later and my build was running and succeeded. I was almost disappointed that it was that easy. Actually, that’s a lie, I was really impressed by how easy it was.
So that is all it took to migrate my site over. So far I have not scratched the surface of the features that Netlify offer. I am already more than happy having a simple hosting solution with continuous builds. I will try and write a post on other features as and when I use them.
If you’ve found this post useful or have any comments or questions about hosting on Netlify please do message me via twitter or email.
Welcome to my site and blog. You can find out about me and read my thoughts on code and technology, start-ups and building things.
