a coding nagger's blog

My name is Jean-Dominique Nguele and this is my blog. FLVCTVAT NEC MERGITVR

Tag Archives: aws


Domain name migration without losing SEO

Reading Time: 6 minutes

How did that even come up?

I originally started writing another post last week but in the meantime I did a domain name migration. What is a domain name migration you will ask? It is the act of migrating content from a domain to another domain. Not host, domain. If this was about host migration there would be no need for a post as the changes would be straightforward. People may give you a different or more precise description but it is basically what I did. And also what it sounds like. I like to name things so that when they are described or revealed they turn out to be pretty much what you expect. It’s like coding. If I have a piece of code with a method boolean validatePassword(string username, string password) when looking at the code you pretty much expect to see some user retrieval and maybe encoded password validation. You definitely do not expect a session to be started or anything funny like that. Enough with this, let’s get back onto today’s topic. Domain name migration.

Why would I do that?

I decided to separate my blog from my main domain iamnguele.com a couple of weeks ago as I picked a new pseudo that you may have noticed by now: Coding Nagger. Why that name and why move only the blog? I thought I should pick a different and more playful pseudo than IamNguele. IamNguele was more of a statement, some “Hey I’m here” kinda thing. Also, my english was not great and nguele.com was taken. On top of that, iamnguele gets me on top of the SEO rankings on my name. On top of that, I gain rankings for the search term coding nagger as you can see below.

coding nagger seo

More SEO power to me, even though mixed for now

Now, after five years living in London I like to think I somewhat improved my english speaking and writing skills. Also I picked a name that would be more fitting. The Coding part is pretty self-explanatory, and Nagger because I can try to push you something that I believe is the right thing whether you like it or not. Just to precise the context I’m talking about code reviews, solution analysis/design. So here we are, Coding Nagger and I still have not mentioned anything about domain name migration but you get the context at least.

say nagger

You understood that reference or you will

The challenges involved

Changing domain name in itself is relatively easy. Most hosting providers allow you to point and click your way through it even if you go for tech saavy stuff like Amazon Web Services. However, there are a few things that you need to take into consideration before you get started. If your website or blog is part of your personal brand and ranks well either you are a probably a pioneer in your field, no matter how niche it can be. If it is the case, congrats you may not need SEO as much as others such as myself.

What is SEO? I hear you ask. SEO stands for Search Engine Optimisation. The rules seem to change pretty constantly and vary based on which search engine you use. Basically, put out quality content, stay on focus of the topic you want your article/blog/website to rank up and voila. The problem with domain name migration is that if you are not careful, it will take a while before your pages rank back up. It will happen because your search engine will consider that your “renamed” site is a new site. Therefore whatever counter or algorithm search engines use to rank sites will see your website as having a score of 0 out of 100 instead of let’s say 42 figuratively speaking.

Do your pages have a decent SEO rating? Do you intend to keep things like this? If the answer to either of this questions is no, feel free to skip the end of the post and rejoice for the now more useful introduction I gave you.

Eventually, you need to consider whether your existing website requires a SSL certificate and whether the links you find through your favorite search engine use the http or https protocol. If your website has secure links the they are likely to rank higher and be prioritised over their non-secure version by your browser or search enine.

Once you figured your constraints we (mostly you) can get to work.

SEO safe domain name migration in 3 easy steps!

This probably should have been the title of this post, really clickbait worthy. The gist of what needs to happen is redirecting your existing website links towards the new domain name. Let’s get down to business.

domain name migration shang

General Li Shang definitely knows what’s up

Step 1: Point your new domain to your content

If you do not have your new domain name, the obvious first step is to buy. Just the domain name, nothing more, nothing less, yet. Once you have the domain name, get it to point to the location where your existing website is hosted. Some hosting providers will allow you to do so with a couple clicks. If you manage your domain names separately from your hosting you will need to CNAME entries of your new domain yourself to point at the IP address where you host your website.

After a few minutes, you can try to access your website using your new domain name. You should be able to navigate it with the right links and the same structure you have for your existing domain.

Step 2: Keep the lock on if lock there was

You may remember that I mentioned something about http and https links visible through a search engine result page. If your existing website has its pages indexed with the https protocol prefix you have one last thing to deal with before setting up the redirect. You need to setup a SSL certificate so that browsers allow people to access your new site. Believe me, you do not want to just reassign the certificate to the new domain. I tried and had a micro-heart attack when I realised 5 minutes later that the links to my existing blog would not even open redirect or not. This is because if your website tells a browser it has a secure link but have no certificate it will simply be blocked. If it has an invalid certificate it will prompt users that your website is unsafe to access or stole another site’s certificate. Just buy a new certificate and assign it to your new domain. Keep the existing stuff where it is.

Step 3: Do the actual redirect

Here we do the easy bit. Your hosting provider should give you access to at least a FTP containing a bunch of folders and one of these contains your website. From there, you need to create a new folder sitting next to your website folder that will contain the .htaccess file where you shall write the permanent redirection configuration. Once that folder is created you will have to upload a .htaccess file with these contents:

Obviously you may replace www.codingnagger.com with your domain name unless you want to send me more traffic. I would be more than fine with that. Also, if you do not have nor require a SSL certificate on your existing and new domain, replace https with http.

Closing

Here I chose not to detail the specific of each step as there is multiple ways to achieve this for all providers. Also, for most hosting provider the process is trivial in itself and if you manage your domain name yourself you definitely know your way around your provider dashboard. The one thing you may need is a bit of experience, of guidance. A flow showing in which order you should proceed to avoid losing your SEO ranking. I mean, personally it did not go so bad. My blog went from top hit when googling myself to bottom of the first page with a title change on top of the domain change. Just look:

first page coding nagger

Still first page

Note that I had a look at some of my most popular posts, the one that have the best SEO rankings. Some still appear under the blog.iamnguele.com domain. Try to google nsattributedstring color image and see what comes up maybe not first everywhere but at least second.

nsattributed string coding nagger bing

First 2 results on Bing

nsattributed string coding nagger google

Second on Google, not too shabby

This is why SEO matters. And I will update the post in a few days/weeks to see if it still pops up on top after Google’s indexer sees it as a codingnagger.com entry. It has been there for a couple years now and I doubt it changes. Unless I screwed up completely and give you an excellent reason to disregard this whole post.

Thank you for reading and hopefully this will help you doing some domain name migration without losing your content rankings. Till next time.

Serverless’ latest release breaking Babel polyfill?

Reading Time: 4 minutes

Here, get some context

Hey everyone, let me tell you about Serverless‘ latest release. You must be thinking “Three posts in ten days after three months absence what got into you JD?”. Nothing particular, well now that I go exercise in the morning and finish work around 5 I have tons of time to do stuff afterwards. Also I keep running into things from that feel blog worty. Indeed, today I experienced what can easily become a nightmare for developers. Broken continuous integration from out of nowhere. Indeed, this morning as I was making the latest adjustments to a project set to move towards production in a few days, the continuous integration broke after merging my latest pull request. The pull request contained minor changes in a configuration but nothing that would be used at any point  through CI.

Let me add some context about the stack here, the project relies on the Serverless framework which allows building serverless solutions. By serverless solutions I mean stuff running on what you would call Functions apps on Azure or Lambdas on AWS. Pretty clever stuff that reduces the pain of setting up deployment and privileges focus on development.

Now the continuous integration part, I use that serverless package command that permits to build the package generated by the serverless deploy command that allows deploying your functions to whichever provider you want. That way after the unit tests are passed I can validate that the configuration for deployment is all set. This is the part of the CI that broke with some random error about babel-polyfill requiring a single instance.

Columboing around

This is where my biggest head-scratcher in a few months started. Continuous integration breaks after changing a configuration file used at runtime by a serverless function but not used at any point through the build steps. I could not reproduce the issue locally no matter how hard nor often I tried. Believe me I tried harder and a Gold V in League of Legends. I tried deleting the package-lock.json & node_modules then running serverless package on my local but still nothing. Still stuck. Then I checked again the file changes between the last successful CI build and the first failed one. Still nothing.

I thought that maybe it was just some timing error as it happened to me a while ago on VSTS when there was that cloudfront thing with NPM not retrieving packages. So I triggered the CI build manually but still nothing. At that point I was grasping at straws. Even compared the builds to try and figure what was the difference in execution but still nothing.

After a couple of hours I eventually went for lunch with my girlfriend and a friend of hers, still with that issue in mind. As they do when together they were speaking italian which allowed me to think through everything again but far from the screen and temptation to google things I knew would have no answer. Then I got what I thought was my aha moment. What if serverless was the reason the CI broke? Unlikely, yet I had seen way worse in the past. After all all the continuous integration was set to use Serverless’ latest release. It just kept growing on my mind while munching on that sweet chili chicken from Wasabi. It reached the point where I rushed the end of the lunch then went back to the office to check my theory.

Serverless’ latest release

The first thing I wanted to validate was updating my local to use Serverless’ latest release (1.28.0) which matched the last few failed builds. Yes few builds, as I was saying I did try loads of stuff. After the update I ran the serverless package command and it still worked. There goes my aha moment. At that point it crossed my mind that it could be my continuous integration system that could have had a weird temporary issue so I tried my luck one more time. However, this time I did explicitely set my CI definition to install the previous version (1.27.3) of Serverless just in case. I trigerred yet another build and went to grab a coffee, as one does.

You probably guessed it, I came back to another failed build. It starts to get on my nerve a bit so I decided to up the ante. I put my headset on with some some gangsta rap to go all out on this issue. So I eventually went through the logs comparing every single command, displayed verbose from the last successful build with the last failed one. I even went to check Serverless’ latest release page. I even went to checkout Serverless’ npm page. As “King’s Dead” from Kendrick started hitting my hears I got a aha moment from my previous aha moment. Do you know what happened this morning? Serverless 1.28.0 got released. Right after that I noticed something else. The last failed build still installed serverless 1.28.0 instead of 1.27.3.

Serverless' latest release

Yup, exactly

As it turns out I changed the title of the task and not the actual command. That’s what happens when you do changes pre-coffee.

Roll credits

After correcting it on the continuous build for our development environment, I triggered the build again. It worked! But I was way too happy to have figured that out to care about my previous fix attempt to have been defeated by a dumb mistake. Afterwards, I updated all the build and release definitions using serverless to explicitely target the 1.27.3 version. I guess that was a good refresher that when you setup continuous integration/delivery you should fix the versions of everything you use in your build. You can never know when people behind the tool you rely on will issue a broken release.

How to install the CLI Amazon tools on a Mac

Reading Time: 5 minutes

Recently I had to connect to an amazon EC2 instance using SSH to do some stuff and realized that there is no manual for the Mac setup, but for Unix-like OS. However, since OS X is Unix based the instructions kinda work but if you’re unaware of some specifics you may get stuck at some point, plus even googling did not help me there. As I managed to make it quite easily, I thought it is my duty to share it with the world. That somewhere on the internet there is a reference allowing you to just copy-paste commands to gain time. Yes, the good engineer is lazy (work for devs too). Not the lazy laziness of not doing anything, but the one that forces you to think something long and well enough so you don’t have to restart it or to do it again and again.

Note

This guide is partially inspired from Amazon’s documentation on the subject

A. Download and Install the CLI Tools

First of all you will need the Amazon CLI tools. Download the tools. The CLI tools are available as a .zip file on this site: Amazon EC2 CLI Tools (aws.amazon.com/developertools/351). You can also download them with the curl utility.

You can, optionnal, verify that the CLI tools package has not been altered or corrupted after publication. For more information about authenticating the download before unzipping the file, see Verify the Signature of the Tools Download.

Unzip the files into a suitable installation directory, such as /usr/local/ec2. Notice that the .zip file contains a folder ec2-api-tools-x.x.x.x, where x.x.x.x is the version number of the tools (for example, ec2-api-tools-1.6.12.2).

B. Tell the Tools Where Java Lives

You can verify whether you have Java installed and where it is located using the following command:

You should see the following is example output.

If the previous command does not return a location for the Java binary, you need to install Java. For help installing Java on your platform, go here.

Find the Java home directory on your system. The which java command executed earlier returns Java’s location in the $PATH environment variable, but in most cases this is a symbolic link to the actual program; symbolic links do not work for the JAVA_HOME environment variable, so you need to locate the actual binary. The /usr/libexec/java_home command returns a path suitable for setting the JAVA_HOME variable.

Set JAVA_HOME to the full path of the Java home directory. Set the JAVA_HOME variable to $(/usr/libexec/java_home). The following command sets this variable to the output of the java_home command; the benefit of setting the variable this way is that it updates to the correct value if you change the location of your Java installation later.

You can verify your JAVA_HOME setting using this command.

If you’ve set the environment variable correctly, the output looks something like this.

Add this environment variable definition ($JAVA_HOME) to your shell start up scripts so that it is set every time you log in or spawn a new shell. The name of this startup file differs across platforms (in Mac OS X, this file is commonly called ~/.bash_profile and in Linux, it is commonly called ~/.profile), but you can find it with the following command:

If the file does not exist, you can create it. Use your favorite text editor to open the file that is listed by the previous command, or to create a new file with that name. Then edit it to add the variable definition you set in Step 3.

If the file exist set rights so you can edit it, then edit it using textedit, and change permissions again

Verify that the variable is set properly for new shells by opening a new terminal window and testing that the variable is set with the following command.

Note: If the following command does not correctly display the Java version, try logging out, logging back in again, and then retrying the command.

C. Tell the CLI Tools Where They Live

The Amazon EC2 CLI tools read the EC2_HOME environment variable to locate supporting libraries. Before using these tools, set EC2_HOME to the directory path where you unzipped them. This directory is named ec2-api-tools-w.x.y.z (where w, x, y, and z are components of the version number). It contains sub-directories named bin and lib.

In addition, to make things a little easier, you can add the bin directory for the CLI tools to your system path. The examples in the Amazon Elastic Compute Cloud User Guide assume that you have done so.

You can set the EC2_HOME and PATH environment variables as follows. Add them to your shell start up scripts so that they’re set every time you log in or spawn a new shell.

To set the EC2_HOME and PATH environment variables on Linux/Unix

Use this command to set the EC2_HOME environment variable. For example, if you unzipped the tools into the /usr/local/ec2 directory created earlier, execute the following command, substituting the correct version number of the tools.

Note

If you are using Cygwin, EC2_HOME must use Linux/Unix paths (for example, /usr/bin instead of C:\usr\bin). Additionally, the value of EC2_HOME cannot contain any spaces, even if the value is quoted or the spaces are escaped.

You can update your PATH as follows.

D. Tell the CLI Tools Who You Are

Your access keys identify you to the Amazon EC2 CLI tools. There are two types of access keys: access key IDs and secret access keys. You should have stored your access keys in a safe place when you created them. Although you can retrieve your access key ID from the Your Security Credentials page, you can’t retrieve your secret access key. Therefore, if you can’t find your secret access key, you’ll need to create new access keys before you can use the CLI tools.

Every time you issue a command, you must specify your access keys using the –aws-access-key and –aws-secret-key (or -O and -W) options. Alternatively, you might find it easier to store your access keys using the following environment variables:

If these environment variables are set properly, their values serve as the default values for these required options, so you can omit them from the commands. You can add them to your shell startup scripts so that they’re set every time you log in or spawn a new shell.

You can set these environment variables as follows.

E. (Optional) Set the Region

By default, the Amazon EC2 CLI tools use the US East (Northern Virginia) region (us-east-1) with the ec2.us-east-1.amazonaws.com service endpoint URL. To access a different region with the CLI tools, you must set the EC2_URL environment variable to the proper service endpoint URL.

To set the service endpoint URL

To list your available service endpoint URLs, call the ec2-describe-regions command, as shown in the previous section.

Set the EC2_URL environment variable using the service endpoint URL returned from the ec2-describe-regions command as follows.

If you’ve already launched an instance using the console and wish to work with the instance using the CLI, you must specify the endpoint URL for the instance’s region. You can verify the region for the instance by checking the region selector in the console navigation bar.

For more information about the regions and endpoints for Amazon EC2, see Regions and Endpoints in the Amazon Web Services General Reference.