DEV Community: Alvin Lim

HTTPS Domain Forwarding for Free via Netlify

Alvin Lim — Tue, 02 Nov 2021 14:39:09 +0000

This evening GoDaddy reminded me of an unused personal domain, alvinlim-writer.com, which is due to expire late next year. Several years ago I had used it for my personal website, and it still appears as a search result on Google. As such I decided to forward this domain to my current website alvinlim.dev.

I had previously done this with another domain via GitHub Pages, but this time I decided to go with Netlify as I suspected doing so would be easier.

So first I created a bare bones index.html file containing a meta refresh tag that would load my target URL:

<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="refresh" content="0; URL=https://alvinlim.dev">
  </head>
  <body></body>
</html>

Then in Netlify I deployed this index.html file as a running website. Usually I deploy projects to Netlify by connecting to the appropriate repo on GitHub, but for this I just clicked the Sites tab and dragged and dropped the folder containing the index.html file into the following button:

Once the index.html file was deployed as an active website -- just a few seconds later -- Netlify gave me the option to set up a custom domain for this website. This was my opportunity to connect my old domain alvinlim-writer.com to this index.html file which would automatically redirect the user to my current website alvinlim.dev.

To set up this custom domain, Netlify gave me the A and CNAME records that I would need to set up in my domain name registrar, in this case, GoDaddy. In GoDaddy, I set up the Netlify A and CNAME records in my alvinlim-writer.com management panel, and almost immediately the URL pointed to the website I had set up in Netlify! Which meant typing alvinlim-writer.com in the browser would automatically redirect you to alvinlim.dev.

From my recollection, setting this up on Netlify was much easier than doing the same on GitHub Pages. Having said that, setting up HTTPS domain forwarding on GitHub Pages can't be described as a difficult task either!

HTTPS Domain Forwarding for Free via GitHub Pages

Alvin Lim — Fri, 29 Jan 2021 08:56:17 +0000

This week I decided to move my homepage from alvinlim.me to alvinlim.dev.

I remembered that my domain name registrar offered a free URL redirect service, and I decided to use that forward alvinlim.me to alvinlim.dev. While that worked for http://alvinlim.me, clicking https://alvinlim.me instead threw an SSL error.

Basically, for the URL redirect of https://alvinlim.me to work, https://alvinlim.me first had to be recognized by the browser as a valid website, and this meant it had to have a valid SSL certificate attached to it.

This meant I had to set up a website for https://alvinlim.me, attach a SSL certificate to it, and configure the HTML to redirect the browser to https://alvinlim.dev. 😅

This raised the question -- wouldn't setting up the website and SSL certificate be expensive? That's when I remembered that I could quickly set up a free website on GitHub Pages, connect it to my alvinlim.me domain, and GitHub Pages would even provision and attach an SSL certificate to it for free! Since I already had the alvinlim.me domain, I decided to go with this option.

So I created a new repo on GitHub which hosts an index.html file which is empty except for the important meta refresh tag which redirects the browser to the new URL:

<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="refresh" content="0; URL=https://alvinlim.dev">
  </head>
  <body></body>
</html>

I next created a GitHub Pages site from that repo and attached my domain to it. In the GitHub Pages settings I then selected the "Enforce HTTPS" option.

With all this in place, clicking https://alvinlim.me no longer throws an SSL error but instead correctly redirects the browser to https://alvinlim.dev.

How to make Windows Terminal look like oh-my-zsh

Alvin Lim — Thu, 12 Nov 2020 11:55:17 +0000

One of the joys of working in a Linux environment is its superior terminal experience. With the wide selection of themes available in the oh-my-zsh plugin for the zsh shell -- and likewise for oh-my-bash for the bash shell, using the terminal in Linux can be a delightful aesthetic pleasure.

Hence switching from a Linux to a Windows environment had always come with a sense of disappointment. So it was with great surprise when I learned that it was now possible to configure Windows Terminal to look like oh-my-zsh. The instructions can be found here. And if you implement these steps in Windows Terminal 1.5, hyperlinks -- which previously had to be copied and pasted into the browser -- now become clickable:

The instructions include the installation of a Powerline font like Cascadia Code. The added benefit is that, once installed, you can use the same font in your favorite code editor like Visual Studio Code, which can enhance your developer experience.

Building a vanilla JS navbar

Alvin Lim — Sun, 11 Oct 2020 16:05:28 +0000

In the last iteration of my personal website, I removed all JavaScript and used HTML5's details/summary elements to selectively show or hide the different sections of my website.

While this led my website to achieve a 100% Lighthouse performance score, I didn't like the resulting appearance. Hence I decided to bring back just enough JavaScript to build a simple navbar to accomplish that same task.

This is how I wanted my website to look. When you first land on my website -- and if you click the "Hello" button in the navbar -- you will be presented with the "About" section:

If you click the "Code" button, you will be presented with the Coding Projects section of the page:

And finally, if you click the "Contact" button, you will be presented with the contact form:

The key thing to note is that these three sections are not three separate HTML files but are instead three sections of one HTML file. JavaScript is used to hide two of these three sections at any one time, creating the illusion that there are three separate files. This can be seen when JavaScript is disabled. In this situation, all 3 sections are displayed:

To achieve this look, I first identified the About, Coding Projects, and Contact Form sections with the appropriate id tags in the HTML: <article id="about">, <article id="code">, and <article id="contact">.

In the navbar, each button -- which is just an anchor element with text and an icon from Fontastic -- has its own unique id:

<nav>
  <a id="nav-about">#Hello <i class="icon-smile-o"></i></a>
  <a id="nav-code">#Code <i class="icon-codepen"></i></a>
  <a id="nav-contact">#Contact <i class="icon-pencil"></i></a>
</nav>

Once styled with CSS, the buttons wil look like this:

With these ids in place, we can now use JavaScript to pair each button element in the navbar with its corresponding article element in the HTML, and create event listeners to change the appearance of the website when the different buttons are clicked.

First, the navbar. Since the navbar uses JavaScript to control the appearance of the website, it is useless if JavaScript is -- for whatever reason -- disabled on the browser. In this situation, I do not want the navbar to appear. Hence in CSS the navbar is hidden by default:

nav {
  display: none;
  ...
}

If JavaScript is working in the browser, the following script in the HTML will activate the navbar. The script will also display the "About" section and hide the "Code" and "Contact" sections, giving us the desired default appearance of the website:

 <script>
    document.querySelector("nav").style.display = "flex";
    document.getElementById("about").style.display = "block";
    document.getElementById("code").style.display = "none";
    document.getElementById("contact").style.display = "none";
    ...
  </script>

Now the event listeners can be added. When the "Hello" button (with the nav-about id) is clicked, the "About" section should be shown while the "Code" and "Contact" sections remain hidden:

 <script>
    ...
    document.getElementById("nav-about").addEventListener("click", function () {
      document.getElementById("about").style.display = "block";
      document.getElementById("code").style.display = "none";
      document.getElementById("contact").style.display = "none";
    });
   ...
  </script>

When the "Code" button (id: nav-code) is clicked, the "Code" section should be shown and the "About" and "Contact" sections hidden:

 <script>
    ...
    document.getElementById("nav-code").addEventListener("click", function () {
      document.getElementById("about").style.display = "none";
      document.getElementById("code").style.display = "block";
      document.getElementById("contact").style.display = "none";
    });
    ...
  </script>

Finally, when the "Contact" button (id: nav-contact) is clicked, the "Contact" section should appear with the other two sections remaining hidden.

 <script>
    ...
    document.getElementById("nav-contact").addEventListener("click", function () {
      document.getElementById("about").style.display = "none";
      document.getElementById("code").style.display = "none";
      document.getElementById("contact").style.display = "block";
    });
  </script>

And that's it! With these event listeners in place, the buttons are now functional. With the reintroduction of JavaScript to my website, I had concerns about the impact on performance, but a Lighthouse audit allayed my fears:

If you're interested, the source code of my website is available on Github.

Less can be More, A Lot More

Alvin Lim — Tue, 22 Sep 2020 07:28:37 +0000

After I posted my last article, Speeding up my website, I wanted to see if I could further optimize my website's performance so that it would get a higher score than 80% on Lighthouse ... and after a few major adjustments, I managed to improve its Lighthouse performance score to 100%!

How was this done? By ruthlessly minimizing the assets that needed to be loaded and rendered on the screen. In this experiment, less really proved to be a lot more.

Background Image

The previous version of the website featured a large background image. Even though I had optimized it by converting it to the compressed WebP format, it still remained the largest asset in the website. To maximize performance, I decided to radically change the look of my website and remove this background image entirely, and replace it with a repeating SVG pattern from Hero Patterns. So instead of a photo of the desert, the background of my website is now wallpaper patterned on graph paper.

JavaScript

In the previous round of optimization, I had removed the Google Analytics and Google ReCaptcha scripts. The only JavaScript script I kept was the one that built the virtual tabs for my website. To maximize performance I decided to remove this remaining piece of JavaScript.

To replace its functionality, I found inspiration in Tapas Adhikary's article 10 useful HTML5 features you may not be using, in which he showed how the Details/Summary HTML5 element could be used to selectively hide content in a website.

Since this was what the old JavaScript virtual tags had done on the previous iteration of my website, I decided to use Details/Summary HTML5 tags to selectively hide the coding projects and contact form sections of my website:

This however altered the layout of my website but I saw this as an opportunity to rejuvenate it with a brand new look, and I spent a couple of fun hours experimenting with new fonts and color schemes.

Minification and Compression

To make sure that the size of the assets that would be piped from the web server to the browser remained as small as possible, I made sure that Netlify, my web host, was configured to automatically minify and compress them:

Further compression comes from the Brotli compression which is deployed automatically on Netlify's Edge network, on which websites on Netlify's generous free tier are hosted.

While there are remain opportunities to further improve performance -- for example, while Netlify minifies CSS, it doesn't do so for HTML -- for the moment I'm happy with the latest round of optimizations.

Speeding up my website

Alvin Lim — Sun, 20 Sep 2020 03:51:03 +0000

My project this weekend was to speed up my personal website. I had decided to work on this after it received a failing grade on Google Lighthouse. After a series of much-needed optimizations, the website now loads noticeably faster and its Lighthouse score is much improved:

I will now share the key optimizations that I implemented that sped up my website:

Optimizing Images

The previous version of my website featured a 3 MB JPEG file which I used as the full background image. I wanted to keep the same look, which meant I had to replace this image with a format that featured better compression than JPEG. I had considered the new AVIF format but unfortunately it is currently not well-supported:

I hence opted to replace the existing JPEG and PNG images with WebP images, as the WebP format is better supported:

Apart from changing the image format, I also ensured that the images used in my website are the exact same dimensions as they will be presented on the screen.

For example, the dimensions of the portrait image I had previously used were much larger than the small 200x200 round image shown on the website. Not only did this mean precious milliseconds would be squandered downloading this unnecessarily large file, the browser too would waste time resizing the image. By deploying images of the correct dimensions, milliseconds would be saved.

Removing Unnecessary JavaScript

Apart from the need to optimize my images, Lighthouse also indicated that I could optimize my website further by removing unnecessary JavaScript scripts. I had 3 JS scripts running on my website -- a virtual tab builder; a Google Analytics script; and a Google ReCaptcha script.

I decided to keep the virtual tab builder as I liked how it enhanced my website. I decided to remove the Google Analytics script as I realized that I didn't need it since I was not using my personal website for a function like ecommerce.

I likewise opted to remove the Google ReCaptcha script from my FormSpree contact form and adjusted the form's settings to use the ReCaptcha function hosted on FormSpree instead. Removing these third-party JavaScript scripts significantly reduced the time taken for the browser to load and render the website.

Dumping CDNs

Prior to optimization, my website made use of 3 CDNs -- Google Fonts, Font Awsome, and Bootstrap. Replacing these with locally hosted assets resulted in major savings of time.

Google Fonts

To replace the use of the Google Font CDN, I downloaded the fonts that I needed and used Font Squirrel to convert them to web fonts. I then moved the woff2 font files to a fonts folder that I created in my website project directory and declared them in my CSS file.

For example, one of the Google Fonts that I use in my website is Righteous. I imported this into my CSS file by declaring the @font-face (including the location):

@font-face {
  font-family: "Righteous";
  src: url(fonts/righteous-regular-webfont.woff2);
  font-display: swap;
}

and used it in the appropriate CSS component, in this case, the banner:

.banner h1 {
  ...
  font-family: "Righteous", cursive;
  ...
}

Font Awesome

Prior to optimization, my website relied on Font Awesome to get the LinkedIn, Google, and GitHub icons used in the footer. To optimize this, I switched to Fontastic which allowed me to download these icons as a single font file which I can host locally. (When you download this font file, Fontastic will give you the appropriate CSS and HTML snippets to insert in your code to display the icons.)

Bootstrap

I had previously included Bootstrap in my website to tweak its layout but I decided that this benefit did not justify the cost in terms of the time used to download Bootstrap from its CDN and render the Bootstrap classes in the browser. After removing Bootstrap I discovered I only had to spend just a bit of time to adjust the HTML and CSS to get the look that I wanted.

A Speedier Website

These optimizations were long overdue and apart from the higher score my website received from Lighthouse, the benefits could be felt in a discernibly faster website. I also tested my website in HubSpot's Website Grader which gave it a higher grade than it had received before the optimization:

Testing and Deploying a PHP App in Ubuntu

Alvin Lim — Fri, 11 Sep 2020 17:35:18 +0000

If you've been learning PHP in an online classroom like Codecademy you may find yourself surprised when setting up your workstation for PHP development.

Unlike HTML or JavaScript code which will run automatically in your browser, PHP code -- even if it works perfectly well in your online IDE -- will not work on localhost unless you are running it from a server.

Without a server to render your PHP code, your may find your browser prompting you to download the PHP file you're trying to open, or just displaying the PHP code without rendering it. In technical terms, while JavaScript is a client-side scripting language, PHP is a server-side language.

Hence, to get your PHP code working in localhost, you will need to run it with a server. One popular solution is to use a prepackaged stack like XAMPP which will contain Apache (the server), MariaDB (a popular MySQL database), and PHP. Such prepackaged stacks will save you a lot of installation time.

However, if your OS is a Linux distribution like Ubuntu, you can take the opportunity to set up a classic LAMP stack (Linux, Apache, MySQL, PHP). Setting this up will however require extra configuration in addition to installing the software.

MySQL

Let's start with the database installation. I recommend MariaDB as it offers an optimized installation of MySQL. These commands will install MariaDB and set up the database's security options according to your preferences:



sudo apt update
sudo apt install mariadb-server
sudo mysql_secure_installation

Apache

Next, you need to install the Apache server:



sudo apt install apache2

Now that you have an Apache server running on your machine, you will need to configure Ubuntu's firewall. You can run sudo ufw app list to see the available firewall profiles and sudo ufw app info "Profile Name" to get information on a particular profile:

If you like a particular profile, say in this case, Apache Full, you can activate it with the command sudo ufw allow in "Apache Full"

You can now open http://localhost/ in your browser to see your Apache server running:

However, additional configuration is still needed for Apache to render your PHP code. By default, Apache will open files saved in the /var/www directory. However, this directory is protected and you will need to sudo to write into it. Hence it won't be good practice to keep your code here.

A better solution will be to activate Apache's User Directory feature, which will allow you to run your PHP code from a new public_html directory in your home folder. The following command will activate the User Directory feature:



sudo a2enmod userdir

Next, you will need create the User Directory (~/public_html) and set the correct directory permissions:



mkdir $HOME/public_html
chmod +x $HOME
chmod 755 $HOME/public_html

You will then need to enable PHP scripting in the User Directory (by default Ubuntu disables this). To do this, first:



cd /etc/apache2/mods-enabled/

When you are in the /etc/apache2/mods-enabled/ directory, use the command ls to look for the PHP configuration file. It will be named php[version_number].conf:

In this example, the version number is 7.4 and you will need to edit php7.4.conf to activate PHP scripting in the User Directory:



sudo nano php7.4.conf

Look for the following lines:



<IfModule mod_userdir.c>
   <Directory /home/*/public_html>
       php_admin_flag engine Off
   </Directory>
</IfModule>

Add an # at the start of each line to deactivate Ubuntu's disabling of PHP scripting in the User Directory:



# <IfModule mod_userdir.c>
#    <Directory /home/*/public_html>
#        php_admin_flag engine Off
#    </Directory>
# </IfModule>

The file should now look like this:

Press Control-O to save the file and then Control-X to exit the text editor.

In that same directory, you will also need to edit another Apache configuration file:



sudo nano /etc/apache2/mods-enabled/dir.conf

Look for this line:



DirectoryIndex index.html index.cgi index.pl index.php index.xhtml index.htm

In this line, cut and paste index.php so that it comes before index.html:



DirectoryIndex index.php index.html index.cgi index.pl index.xhtml index.htm

Save the file and exit. You will now need to restart Apache to active the new settings:



sudo systemctl restart apache2

PHP

The final part of the LAMP stack is of course PHP:



sudo apt install php libapache2-mod-php php-mysql

This command will install PHP as well as the packages needed for PHP to access Apache as well as MariaDB.

You should now be able to run your PHP code in your new LAMP stack. To test this, write and save a PHP file in your public_html directory. Here's a very simple -- but useful! -- PHP script you can use:



<?php
    phpinfo();

Save this in your public_html directory. I have named mine test.php but you can name it anything you want; just make sure the filename has the .php suffix.

Open your browser and go the following address (replace username with your Ubuntu username and filename with the name you gave your test file):



http://localhost/~username/filename.php

In my case, the URL is http://localhost/~alvin/test.php. My LAMP stack has successfully rendered the PHP script in the browser:

Deploying to Production

Given these complicated steps just to render a PHP script in localhost, you might imagine that deploying a PHP app would be similarly complicated, and you would be right!

Apps written in PHP will not run on platforms like Netlify which are designed to host static apps. While you can host and run your PHP app on Heroku, it has to be deployed with a composer.json companion file otherwise the deployment will fail. To generate a composer.json file, you will need to use install and use Composer. Please refer to its documentation for instructions on how to do this.

The purpose of composer.json is to keep track of the dependencies of your PHP app, but even if your app has no such dependencies, you will still need to generate a composer.json file if you want to deploy your app to Heroku. My Magic 8-Ball PHP app, which is hosted on Heroku, has one such dependency-free composer.json file:

But it's important to keep the goal in mind. Once you get past the hurdle of creating a composer.json file, you will have a shiny new PHP app for your portfolio!

Coding with No Code

Alvin Lim — Thu, 30 Jul 2020 13:54:13 +0000

I'm working through an intense React.js course and I decided to take a break and check out some of the no-code platforms which have come into prominence again thanks to the recent launch of AWS Honeycode. I signed up for Bubble.io thanks to its tutorials and had my preconceptions shattered about what a no-code app could do.

One of the first projects of the React.js course I'm doing was the creation of a Giphy clone, so I was amused to find that creating a Giphy clone was actually one of Bubble.io's 3-minute tutorials. When I worked on this further as my own project I only had to spend a few more minutes to get the images to be properly sized for mobile:

A separate to-do list app that I worked on showed that no-code apps can have CRUD functionality. Indeed, Bubble.io's collection of tutorials include how-tos on creating no-code versions of major apps like AirBnB.

So what is the no-code experience like? As promised, there is no code -- you just wireframe and fill out how you want your app to look -- the inputs, buttons, images, etc. -- and then you click on each component to specify the back-end logic of how they should connect with the database, with one another, or with external plugins. Instead of code you use a GUI to describe the internal logic of your app.

In that sense no-code programming is a natural extension of coding, since a successful no-code app will still need to have a consistent internal logic. Instead of a programming language, the coder's pseudocode will be implemented through the no-code platform's GUI. No-code can hence be seen as just a further abstraction rather than a radical break from coding.

While it's as yet unclear how far the no-code movement will go, given how quickly apps can be created and deployed on no-code platforms, this is definitely a tool that coders should have in their toolkits.

Writing an API in Rails 6

Alvin Lim — Tue, 28 Jul 2020 15:25:47 +0000

In the final stage of my coding bootcamp, when I had become familiar with Ruby on Rails, one project I wanted to do was to write my own API.

APIs (Application Programming Interfaces) are widely used on the internet for computers to send data to one another. Unlike a standard web page, where the server sends a bundle of HTML, CSS, and JavaScript to create a view which is consumed by a human audience, with APIs it is machines communicating with one another.

So if you are viewing a web application that requires data from an API, your browser will send the request to the API, get the requested data back, and then render that data into a format that is suitable for you, a human, to view.

Hence, instead of HTML and CSS, APIs send data in more machine-friendly formats such as JSON, YAML, or XML.

For my API, I wanted to do something fun. My coding class had previously learned how to use Faker to seed our databases with mock information, and I recalled that one of Faker's libraries consisted of Chuck Norris jokes. I decided to go with this and create an API that sends out Chuck Norris jokes.

Let's build the API! First I create the directory and go into it:

$ mkdir chuck-norris-api
$ cd chuck-norris-api

Once in the directory, I instruct Rails to generate the app:

$ rails new chuck-norris-api --api --database=postgresql

The --api option (which is available in Rails 6) tells Rails that you don't want it to generate a full app -- only enough for an API to run. I set the second option --database=postgresql as I will be using Heroku to host the API, and Heroku does not support Rails' default SQLite database.

Once the app is generated, I open my code editor and edit the Gemfile located at the root of the directory. I add gem 'faker' and uncomment gem 'rack-cors':

As I explained earlier, I will be using Faker to populate my database with Chuck Norris jokes, while Rack CORS is the middleware I need to ensure that the front-end I will be building to display the jokes will be able to receive the jokes from the API (more on that later).

I then run bundle install in the terminal to install the new gems. Once that's done, it's time to build out the app's MVC!

First, the models. In this case, there's only one: the jokes. Each joke has one field: its content. In the terminal I instruct Rails to generate the model:

$ rails g model Joke content

This create the following migration:

In the terminal I instruct Rails to run the migration:

$ rails db:migrate

This creates the Jokes table in the database:

The database can now be populated with the Chuck Norris jokes. In seeds.rb I instruct Rails to retrieve a hundred jokes from Faker's Chuck Norris library:

In the terminal, I then instruct Rails to run seeds.rb and populate the database:

$ rails db:seed

Now that the model and database are sorted, I can proceed with the controller and view (the remaining two-thirds of the app's MVC). In the app\controllers folder I create the nested folders api\v1. In the v1 folder I create the jokes_controller.rb file:

In my controller, I only allow the user to perform two actions: get all jokes, and get one particular joke. I do not want the user to edit or delete existing jokes or to add new jokes. This is for the simple reason that I do not want to have to keep checking the database for inappropriate content once the API is deployed. Hence I do not include these remaining CRUD operations in the controller.

As with the controller, I add nested folders (api\v1\jokes) in the app\views folder. The api\v1\jokes folder has two files corresponding to the two controller actions. The first is the index.json.jbuilder file which will build and return a JSON file containing an array of all one hundred Chuck Norris jokes when a request for all jokes is received. In particular, I instruct the JSON builder to only include the content of each joke in the array, and leave out the other fields such as the id numbers of the jokes:

The second is the show.json.jbuilder file which will return the joke with the particular id sent by the controller. As with the index file, I instruct the JSON builder to only include the content of the joke in the JSON file that is sent back to the user:

Now that the MVC are done, we can now proceed to the routes. In the config\routes.rb file I specify the nested api and v1 namespaces that correspond to the nested api\v1 folders where the controller is housed, and I also specify that the only actions offered by the API are the index (get all jokes) and show (get one joke) actions, rather than the full suite of CRUD operations:

There is one final step that I need to do before I can deploy the app to production. It is a security feature of modern web browsers that, by default, they do not retrieve data from APIs if the domain of the requesting web page is different from the domain of the API. This will only be allowed if the API specifically allows web pages hosted on that particular domain to retrieve its data.

The obvious way to get around this restriction is to host the web page on the same domain as the API. But what is the fun in that? For this project, the API will be hosted on Heroku, and the web page which I will be displaying the jokes will be hosted on GitHub Pages. This is where the Rack CORS gem that had been installed earlier comes in. In the config\initializers\cors.rb file I specify that my GitHub Pages domain is to be allowed:

While it is certainly possible to set origins '*' in cors.rb and allow any website to access the API, this will effectively bypass the security protocol. So I will be following the best practice and curate which domains are allowed to use the API. It should be noted that this is a security feature of web browers. As we shall see, if you use a tool like curl or Postman to access the API, this cross-domain security block will not apply.

The app is now ready to be deployed! It can be accessed at https://rails-chuck-norris-api.herokuapp.com and as noted, you can use curl from your terminal to retrieve all the jokes:

curl -s https://rails-chuck-norris-api.herokuapp.com/api/v1/jokes | jq

... or any one of the one hundred jokes. Here curl retrieves joke #99:

curl -s https://rails-chuck-norris-api.herokuapp.com/api/v1/jokes/99 | jq

But as noted, I have created a nice front-end at GitHub Pages to retrieve and display the jokes. The source code can be viewed here, but the essential part is this JavaScript code which generates a random number between 1 and 100 and retrieves the joke with that id from the API:

Chuck Norris has the final word:

I found this to be a really fun project to do, and I hope it will inspire you to create your own API!

So I just completed coding bootcamp...

Alvin Lim — Mon, 20 Jul 2020 15:11:22 +0000

I've just completed the most gruelling 9 weeks of my life -- Le Wagon Singapore's web developer bootcamp. I started as a complete code newbie and now have several web apps deployed to Heroku, including my coding team's beautiful capstone project Savvy Granny:

I am a mid-career convert to the tech sector. In my earlier career I was an academic. After publishing two books, I felt burned out and wanted to create and build things instead of analyze or write about them. The idea of coding bootcamp appealed to me, but with my liberal arts background, it just seemed impossibly difficult.

The turning point for me was when I came across a post from Le Wagon's co-founder Sébastien Saunier explaining why they taught Ruby. His description of Ruby as "simple, concise, close to the English language and very flexible" intrigued me, and I soon signed up for Codecademy's free Ruby course. I decided that if I could learn Ruby, then I could handle a coding bootcamp.

As it turned out, I not only completed Codecademy's Ruby course, I found it incredibly fun! Coding was not at all what I had previously imagined it to be. I signed up for Le Wagon's web developer bootcamp, and began learning as much as I could about technology, almost as if to make up for lost time.

The bootcamp itself was a blast. Everyday we did a series of Codewars-type coding challenges, and we began building things with code. One of the earliest and most gratifying moments for me was when I built my personal website with HTML, CSS, and JavaScript and deployed it to GitHub Pages. I had built my previous website with WordPress' drag-and-drop interface -- lacking at that time any knowledge of CSS -- so I felt a great sense of personal accomplishment in coding my own website.

Once we moved into Ruby on Rails, we began building apps that we could deploy on Heroku. We started small -- simple productivity tools like to-do lists, and then we moved into larger apps like the Mr. Cocktail mixology app. Along the way, I had gained the confidence to start building my own projects, including this website hosted on Github Pages which displays random Chuck Norris jokes received from its corresponding API hosted on Heroku.

The climax of the bootcamp was the two weeks spent building our capstone projects. I was extremely fortunate to be grouped with three talented developers, and we quickly built the guts of the app in the first week, and methodically built out the special features of the app in the second. I was especially pleased that our app serves the urgent social need of bridging the generational digital divide.

Now that the bootcamp is over, my fellow grads and I have the technical foundation to learn and build more. Our familiarity with the Rails framework has given us the confidence to move into other frameworks, in particular React. I for one am excited about the new apps that we are going to build.