DEV Community: Arnold Ho

My honest review of the Le Wagon London bootcamp

Arnold Ho — Thu, 30 Dec 2021 15:54:32 +0000

Hey friends,
The main reason that I have started this blog in the first place was to document my learning journey over my 9-weeks intensive bootcamp at Le Wagon.

Over the course of the bootcamp, things got pretty intense so I really didn't have the time and headspace after coding 9-6 to write more about coding.

But now that the bootcamp has ended last week and I have plenty of time in my hands, what better time than now could I be writing about my experience with Le Wagon when its still fresh in my mind? I will be giving an honest review of what I like and dislike about the bootcamp.

Would I recommend it? Is it worth my money?

Short answer: Yes
Long answer: Yes, but I need more context as to what kind of learner you are. As with most bootcamps, you get out as much as you put in. Things gets pretty intense pretty quickly and there is very little room to take a break. 9 weeks will fly pass quickly and at some point during the bootcamp you will probably experience imposter syndrome (I did massively), but you can always book a 1:1 chat with your teachers and, they are extremely knowledgable and will point you towards the right resources. If you prefer a slower learning journey, you might prefer taking an MOOC or taking a more self directed route such as doing the FrontEnd Mentor Challenges.

Is it worth it if I can find all the resources online?

For me personally, yes it was worth it. Online resources such as The Odin Project or Scrimba are great alternatives to spending upwards of 6000 pounds on a coding bootcamp. It's true that most resources can be found online, but that argument can be extended to a full computer science curriculum as well. There are famous challenges such as the MIT challenge where people self-study the entire MIT computer science curriculum. Is MIT worth it? It depends on your context.

What I find useful is someone curating and designing a curriculum for me which is practical in terms of getting me to a level good enough for me to land a job. I am also able to get experience working as a team of four on the same code base using GitHub which is something I would not get as a solo learner.

Another important resource is the push to code everyday, you've probably heard the phrase multiple times that 'you are the average of the people that you spend most time with'. When you are put in an environment where everyone is aiming for the same thing and struggling in the same way, you are less likely to give up. And when you hit a roadblock it is much better to find a buddy/TA to look at your code and debug together rather than struggling alone in silence.

What about career?

The most important aspect of judging the quality of a bootcamp is probably the quality of jobs that are available to their graduates. I think career is something which you can only get out as much as you put in. For me personally, I have started applying as soon as I can (as soon as I started learning Rails, but before project week).

Le Wagon organises a lot of career talks by their hiring partners. In a way they helped me filter out the companies with a good culture in terms of growth, learning and work life balance. I applied to 4 jobs through Le Wagon's hiring partner events, heard back and proceeded with all of them, got to the final stage with 2 of them and got an offer with the first job that I applied through Le Wagon before the programme ended. I would say my case is quicker than usual but Le Wagon did give me all the support I needed in order to find a job.

I have also had a few meetings with the career support team and they helped me polished my CV, got my GitHub up to date and set up a few profiles on job site to be job hunt ready. All in all I highly rate the career support of Le Wagon.

The best part of Le Wagon

The highlight of Le Wagon is definitely the project weeks. This is when we put together all the knowledge we have learnt from the past 7 weeks into practice and make actual web apps. We learnt to work as a team, raising tickets for issues, having stand ups to discuss what we need to tackle, properly raising PR on GitHub and the whole project management side to developing a web app.

Throughout the whole project, the teaching assistants have been immensely helpful with trouble shooting anything and giving us helpful suggestions to improve our app. When we feel stuck we can always pair programme with our buddies.

In the end we managed to patch together (with a lot of duck tapes) two web apps that are fully functional. One is an AirBnB market place clone and the other one is an all-in-one cooking management app. I thoroughly enjoyed the whole process and getting to know and work closely with my team mates to produce these web apps.

Criticisms of Le Wagon

I would say the only cons of Le Wagon is the lack of training in the front end. We had around a week and a half's training on HTML, CSS, and vanilla Javascript. So for anyone who is interested in a career in the front end, they might need to continue their training elsewhere to learn a modern front-end framework. However, I do understand the rationale behind placing less emphasis on the front-end as this is a practical limitation. Le Wagon is focused on training us to have enough knowledge to ship a fully functional CRUD based web app in 9-weeks, we can learn enough front-end to be dangerous and learn more fancy frameworks later once we have the knowledge to start shipping web apps end to end.

What are my next steps?

I am starting my full time job in January as a Software Engineer. I would say Le Wagon has prepared me to be able to continue learning as it has taught me the right method to learn (a.k.a how to google the right way).

I am planning on continue learning Computer Science fundamentals so I am currently taking the HarvardX CS50 introduction to computer science course to improve my fundamental understanding. I am 1 week in so far and I am already loving the quality of the course and the energy of the lecturer. More on that next time!

Apart from my full time job, I will also be working as a teaching assistant part time at Le Wagon. Honestly I enjoyed my time there so much and I would love to continue having a connection with the bootcamp. It will also further solidify my knowledge as I start teaching others and I think teaching and public speaking is a skill that I would really want to master myself.

Final thoughts

As you can probably tell by now, I highly rate my whole experience with Le Wagon. I feel like I got my money's worth with the knowledge I gained and a job I am able to line up by the end of the bootcamp.

In no way do I think a 9-weeks bootcamp is enough to replace a 3-4 years formal computer science education, but it is a good options for folks whom university is not a good option for them. It has provided me with the support, buddies and a structure to learn, and guidance to land my first developer job. Not to mention the massive network of alumni who have attended the course.

If you would like to know more about the bootcamp, feel free to leave me a comment or drop me a DM. Merry Xmas and have a happy new year!

Ruby If-else and Case-when statements Explained

Arnold Ho — Tue, 05 Oct 2021 20:18:47 +0000

Disclaimer: I am learning in public so please do correct me if I get something wrong

In some modern programming languages such as Javascript and Ruby, there are different ways of writing loops that will do specific things under different conditions. Two most common form of this are the if statements and the switch statements. These are not exactly the same but act quite similarly. Depend on the situation you might favour one over the other.

I am going to explain both using the same example. The example will be in Ruby since that's the language I'm learning.

We want to define a statement that returns what someone should wear under different temperatures (in Celsius):

An if statement will look something like this:

if weather > 30
  puts "Heat wave, stay indoor"
elsif weather (<= 30 && > 20)
  puts "shorts, T-shirt, sunglasses"
elsif weather (<= 20 && > 10)
  puts "jumper and long trousers"
else
  puts "wear a thick jacket"
end

Whereas a switch statement in Ruby looks like this:

case weather
when > 30
  puts "Heat wave, stay indoor"
when 21..30
  puts "shorts, T-shirt, sunglasses"
when 11..20
  puts "jumper and long trousers"
else
  puts "wear a thick jacket
end

In an if statement, anything can be the condition, it doesn't necessarily have to be the weather like we've defined above, for example, we can take an extra argument like this:

if weather > 30
  puts "Heat wave, stay indoor"
if weather > 30 && work_from_home == false
  puts "short sleeve and loads of sunscreen"
elsif weather (<= 30 && > 20)
  puts "shorts, T-shirt, sunglasses"
elsif weather (<= 20 && > 10)
  puts "jumper and long trousers"
else
  puts "wear a thick jacket"
end

here we added an additional argument called work_from_home that gives a true or false output if we are working from home or not. An if statement can handle configurations like this.

However, a switch statement takes the output of the case argument and see which switch condition it satisfies. So it is very useful if all the conditions are only dependent on one variable. In some cases, writing a switch statement can make your code cleaner if you have only one variable your statement depends on.

I hope you find this useful. Have a nice day!

Happy coding!

Git & GitHub workflow 101 cheatsheet

Arnold Ho — Mon, 04 Oct 2021 20:28:14 +0000

In the spirit of learning in public, I am writing my own Git cheatsheet.

I am still new, so if I got any of the terminologies wrong, please correct me :)

This cheatsheet is going to be really basic and assumes that you only make changes and commit in the master branch. In the future I will discuss more about branches.

There are two main ways of getting a git repo in your local machine and then pushing it onto GitHub. These are:

Fetching a repo from GitHub, make the changes and push it back to GitHub
Create a new directory locally, initialise git, track the changes and push it up to GitHub

The first way is more common, we can do it using the workflow below:

git clone <the SSH key for your repository>
# This fetches the GitHub repo to your local machine and starts the tracking process

# You will now make some changes to files inside the repo
# Once you're done, you wanna check what are the changes

git status # git status tell you what are the modified files, as well as new files you've created

git add <file_names> # git add adds the files you want to commit on the stage
# you don't have to add all the files that are changed onto the stage
# for example, you might actually have made a change in one of the files and you prefer the previous version, in that case you don't have to git add the change

# You would probably want to check the git status again to make sure you have added all the correct files
git status
# Now, you would be able to see all the tracked and untracked files. Check for any errors before committing

git commit -m "add meaningful commit message" # this will add a commit message and take a snapshot of your repository with the change you wish to document
# Once you've done that, you might want to check git status again

git status
# double and triple checking is always good, now your command prompt should tell you that there is no untracked files.

# This is all good for you, but if you want to collaborate with others and for others to also see the changes you've made, you'd want to push this commit to GitHub.
# Assuming that you've been working on the master branch, you will do the following
git push origin master # This pushes the changes in the master branch to the remote called origin, which should be your GitHub repo. Sometimes, you're branch is not master and your remote is not origin, you can use the format
# git push <remote_name> <branch_name>

# Now this will become a pull request ready to be merged into the main assuming that there are no conflicts

Making a repo locally and then pushing it on GitHub is less common, but we will go through it nonetheless:

# First, you want to make the folder, cd into it and then initialise version control using git

mkdir <folder_name> # This creates a new folder
cd <folder_name> # This moves your current position into the folder
git init # This initalises git. Please do this only in a folder for a specific project, don't do something like this in your user directory because you will be tracking EVERY SINGLE CHANGE in that directory.
# If you track your user directory, this will soon become very messy

# Once you've initalised git, you can start making changes in your repository and save them the same way you do above. So I will skip through the explantions.

git status
git add <folder_and_file_names>
git status
git commit -m "add meaningful commit messages"
git status

# Now, we want to push this onto GitHub again for collaboration.
# But you might have noticed that we don't have a remote to push this to because everything we did was local.

# So now, you have to go into your GitHub and create a new repo, once you've done that, you can get the SSH key of that repo.
# Now you tell git the remote you're using:
git remote add origin <SSH Key of the repo you just created>

# After this step, you just push your changes to the GitHub repo the same way you did before as git now knows where your remote is:
git push origin master

And these are the two ways you can work locally and then push changes onto GitHub.

One useful tool is git log, this basically give you a log of all the commits. It will show you important information like:

Who made the change
When was the change made
What is the change You can then use that to debug codes or roll back to previous versions of codes. I will talk more about how to do that in the future.

For now this is it :) Hope this is useful! This only covers the basics of the basics. There are so many other powerful things git can do like creating new branches, pulling new changes from GitHub and many more. I will cover those in later blogposts.

Happy coding!

Terminal 101 cheatsheet

Arnold Ho — Mon, 04 Oct 2021 19:57:25 +0000

Terminal/Console/Command Line cheatsheets like this is everywhere on the internet, however I am still going to make my own in the spirit of learning in public :)
Also please do let me know if I didn't get something quite right the first time!

pwd

Print Working Directory, this will show you where you currently are

A dot means your current directory, so the location shown when you type your pwd

..

Your parent directory, this is one folder above your current directory

This is your home directory

cd <folder_name>

Change directory, this will move your position into the folder name, you can also cd into a path so that you can move a few folders in. You can also do cd .. to go back a directory

ls

This will show all the files and folders in your current directory

ll

Another way of checking all files and folders in your current directory, it will return a table format

mkdir <folder_name>

Make directory, this will create a new directory at your current directory (This creates a folder within your current folder)

touch <file_name>

This creates a file, for example, touch index.html creates index.html within your current directory

mv <file_location> <file_location2>

This moves the file from location one to location 2.
For example:

mv index.html tmp/index.html

moves the file index.html from the current directory into a directory called tmp within the current directory

rm <file_name>

Remove, but PLEASE MAKE SURE YOU NO WHAT YOU"RE DOING WHEN YOU USE THIS. Sometimes a stack overflow answer might ask you to use this to clear a roadblock. THINK TWICE before blindly using rm because once you've removed your file. It's gone, you can't revert back the change unless you use version control.

When you use rm, sometimes your command prompt will have a safe gate message, this is because rm is so dangerous your terminal is asking you whether you are sure you wanna remove that thing. If you are 100% sure you want to rm something, do the following:

rm -rf <file_name>

That's it for the Terminal 101 cheatsheet. These are the most basic command line tools you might use. I recommend trying to play around with this, create new files and folders, move things into different folders, and as much as possible try to navigate your files and folders using terminal only to get good.

For extra resource, try learn enough command line to be dangerous

Hope that helps and let me know what other command line tools you use daily :) Happy coding!

4 common Q&A for bootcamp developers

Arnold Ho — Thu, 30 Sep 2021 16:29:09 +0000

Not long ago, I had a virtual coffee with @clearlythuydoan, one of the speakers at codeland 2021 conference. She did her bootcamp in Toronto about 5 years ago and has since been a Full Stack Developer. I asked her a few questions with regards to bootcamps and she gave me some advices which I want to share with you all today (with her permission).

Thuy has also created an AMA page on GitHub specifically to answer commonly asked questions about bootcamp. Please go check it out!

The Q&A

The Q&A is written in first person. With me asking the questions and Thuy answering

Q1: How should I get the most out of my bootcamp experience?

A1: During the bootcamp, if you finish the challenge or task of the day quicker than other students, go help out others. Act like a TA. You learn better and you identify gaps of your knowledge when you are trying to teach a concept to someone else. Also, your bootcamp might be recruiting for TAs as there are high turnover rate in these roles. If you have demonstrated your willingness to teach others by acting like a TA, that gives them good reason to hire you as one. If your bootcamp is actively hiring TAs and you manage to secure a role with them, that gives you experience to put on the CV while allowing you some leverage to not be desperate for just any job that comes your way during your job search. You can spend more time to find the right company for you without struggling to pay rent.

Q2: Tips on securing a job after bootcamp

A2: First of use the resources from your bootcamp, apart from that, I recommend checking out Angel List. I was actively looking for side gig while I was TAing. I got a one-month contract in a company. Afterwards, the recruiter of my current company recruited my on LinkedIn based on that experience I have. I stood out amongst other bootcamp grads as I have some experience working on somebody else's code base when most other grads only have greenfield side projects. In your actual job, you will have to collaborate with other developers and work on codes you didn't write yourself. It would be really advantageous if you can demonstrate aptitude in those areas.

Q3: How do you manage doing things on the side (e.g. working on side projects) during your time in bootcamp

A3: While in bootcamp, you should remind yourself that the bootcamp is your top priority. You don't want to jeopardise your learning by doing too much and burning yourself out. If you really want to do something on the side, pick something low commitment. For example, you can tweet or blog about what you've learnt during your day at the bootcamp. Doing that will solidify your learning as well as helping you build an audience whom will lift you up along your developer journey.

Q4: How do you maintain code-life balance? I see so many developers having a well maintained blog, cool side projects, speak and conferences and sometimes even manage a podcast and YouTube channel. How do they do all that while still maintaining a code life balance.

While there are genuinely people who code 9-5 and do all of those things you've mentioned on the side, it is helpful to know that some of those people have jobs which pays them to create content and speak at conferences, these people have jobs called developer relations. So they might not be coding the majority of the day and they might focus more time on content creation. But if you still wish to create content on the side, you should consider the following:

What is your preferred channel of creating content? Would it be a blog? Twitter? A podcast or maybe a YouTube channel? Find the one you enjoy and do it there. You don't have to be everywhere.

What is the cadence and frequency that works for you and doesn't burn you out? Do you want to create content everyday? Once a week? Or spontaneously whenever you have free time? The key here is to pick what works for you and don't feel pressured to be everywhere.

Thank you so much for reading this far and special thanks to @clearlythuydoan for taking her time to answer all my questions. Once again if you have any questions regarding bootcamp, you can go check out her AMA for bootcamp developers.

Happy coding!

How I connected with other developers by consuming in public

Arnold Ho — Sun, 26 Sep 2021 18:23:17 +0000

I was once a lurker online, I would read blogposts, reddit threads, watch YouTube videos and listen to podcasts without ever participating in discussions or leaving comments.

However, I've recently started participating into the community aspect of online content more and actually gotten something out of it. I call this consuming in public.

For example, I recently left a comment on one of the talks I liked in the Codeland 2021 conference by @clearlythuydoan. I left a comment about my current situation as someone who is about to start my bootcamp , as well as why I liked her talk, we actually connected because of that comment and today I just had a virtual coffee chat with her where I asked questions to her about how I can get the most out of my bootcamp. (I am planning on making our conversation a blogpost so check this space)

Another example, I read 'the coding career handbook' by @swyx
and made a tweet about it tagging him, to my surprise, he actually replied to my tweet!

This picture aptly sums up how I feel when those things happen:

Jokes aside, just by simply leaving a comment in a piece of content that I enjoyed, it helped me make a connections with people on the other side of the world whom I would otherwise never be able to interact with and are in my own opinion 'way out of my league'. You can connect to people you look up to as well! By consuming in Public.

Why does consuming in public work?

The number works in your favour

Consuming in public works simply because not enough people do it. Remember back in your school days when the teacher asks the class whether anyone has any questions? If your classes were anything like mine, chances are no one raised their hands or said anything, for the fear of being judged. So if you're that kid who's brave enough to raise your hands, you're going to get your question answered, and if you're doing it in public, you're going to help a bunch of people who silently have the same questions as you purely by asking in public.

Take a look at any YouTube videos, look at the view count, and then look at the number of likes and comments that they get, you'll realise that the number game works in your favour. 95% of people who consumes content on the internet are lurkers (source: guesstimate), so if you are the 5% who participate in the community, you may end up getting something out of it!

If you leave a comment, the worse thing that could happen to you is for your comment to be ignored, the upside is to get a reply or a follow up from someone you look up to and establish a connection with your dev (or non dev) heroes! Seems like a no brainer to me :)

The screenshot below is from the MIT missing semester taken as of 26th September 2021, there are 100k+ views, less than 2k likes, and less than 100 comments. You can be quite sure that your comment is going to be noticed by the person who maintains this YouTube channel.

The person on the other side of the screen wants to help too

If someone is creating content in their spare time for the internet to consume, they are probably quite willing to help others! But they need to know you and your problem exist before they are able to help you out. Just remember the person on the other side of the screen is likely an empathetic human being who would not mind helping you with simple questions. If you leave a comment showing them your appreciation, chances are they are really happy about it and am grateful for your feedback, because not enough people consume content in public.

So how can you start consuming more in public

For the starters, try making a habit of leaving a comment whenever you enjoyed a piece of content (linking the original creator). Be respectful. If you have any favour to ask for, be polite but direct, give them as many details as possible and make it as easy as possible for them to help you.

At the end of the day, you're still kind of an internet stranger. If you want them to help you in something (e.g. giving you tips and guides), make sure to let them know how to contact you, propose a time (and a fallback time), make it super easy for them to follow up with you without the headache of going back and forth. And if they end up helping you, don't forget to thank them for your time!

Next time when you read a good blogpost (Ahem Ahem!), leave a comment! When you see a cool open source project that's asking for help, make a pull request + your comments and questions. Leaving a like and comment on a YouTube video you like goes way further than just helping the creator with the YouTube algorithm, they might reply to that comment you left! You will be surprised what you can get out just by doing that extra bit! It doesn't take long, but its definitely a friend catcher and career multiplier!

Thanks for reading all the way, you are awesome :) Happy coding!

When and how to contribute to open source projects

Arnold Ho — Thu, 16 Sep 2021 19:14:43 +0000

Now

Yes, you should do it now. It is a very beginner friendly process.

I have answered the 'when' part of the question in the title, the remaining blogpost will address the 'how'.

Disclaimer: I am just a code newbie myself, so I might get some of the details wrong. If I do so, please feel free to correct me!

The bar to contributing in open source is extremely low

I think this is important to mention because I always thought that contributing to open source projects are for advance hacker type Mr.Robot people out there in the world. Something that you have to have a double degree in Ivy League, worked in NASA and Google in order to do.

I was extremely relieved to have found out that this understanding of mine was sooo far from the truth. You can pretty much start contributing to open source projects once have some basic understanding of html (or even just markdown).

What is an Open Source project?

As its name suggests, an Open Source project is open to any external contribution. For example if anyone uploaded there project publicly on GitHub (or any other Git Repo), those are by definition Open Source projects since anyone can fork a repo and contribute to the codes. In fact, many large frameworks everyone talks about are open source projects (e.g. Ruby on Rails, React.JS etc).

Why do you want to contribute?

You want to contribute to open source because:

It teaches you Git workflow as a beginner (very important skill)
It teaches you the code improvement, code review process
You get to read the source code of projects done by excellent programmers
When you make a pull request on GitHub, it is almost guaranteed you are going to get feedback from the maintainer of those projects (imagine getting feedback from one of the React/Rails maintainers)
It will show on your GitHub profile

But I know too little code to do anything!

Well, you don't have to contribute code. In fact contributing code is not recommended as a complete beginner. There are loads of other contributions you can make such as:

Improving html links to make links for accessible for people accessing the site through voice reader
Correcting typos of markdowns
Improving documentation of a project
fixing dead html links

My first contribution was literally a GitHub open source tutorial where I forked a markdown file, added my name on it and did a pull request! It wasn't much but it's honest work

My second contribution was a website called Happy coding. There I corrected typos in markdowns and improved link accessibilities.

Both of my open source contributions have very little coding involved.

What have I learnt in my first two open source contributions?

In my first open source contribution, I learnt about the git and GitHub workflow, how to fork a repository and then git clone it to my own computer, how to create git branches, commit a change and push it back to GitHub and make a pull request. These are things that you will use on the job every single day as a software engineer.

In my second project, I learnt not just about accessible websites. Since I had to fork the entire repo of the website into my local machine, I got a lot of time to read through the source code of the website. I realised that most of the sites were built using markdown and I had no idea how to do that. So I shoot a message to the project owner. Since I made contribution to the site, the owner of the site was more than happy to teach me. I realised that there is this tool called Jekyll which kind of automates (for lack of a better word) the layout of the website as well as turning markdown into HTML.

Furthermore, since this project is a coding tutorial site, as I was correcting typos, I also had to read a lot of the actual tutorials to get the context. I learnt about p5.js which is a creative coding framework.

I have then implemented all of the above I have learnt (Jekyll, GitHub workflow, GitHub pages, Website Accessibilities) into creating my own website which is also an open source project where other people have made contributions.

How do you start contributing now?

I recommend going through this tutorial on contributing to open source. By the end of the tutorial, you would have contributed to your first open source project!

Once you have done that, I would recommend looking at projects marked as good first time issues, these are specifically labelled to be beginner friendly. Try to find ones that doesn't involve contributing codes, you want to build up the GitHub workflow experience and open source experience first and foremost.

Congratulations on reaching this far! Happycoding!

Why is my GitHub contribution not showing and how to fix it?

Arnold Ho — Sat, 11 Sep 2021 16:24:02 +0000

Recently I started contributing to an open source project, I have probably made 20+ commits on that project by now and a lot of the pull requests that I have made got merged in the end.

But one thing I realised is that I wasn't showing up as a contributor of that project on the GitHub repo!

If you ever find yourself in the situation, it can get super annoying since you have put in all the blood sweat and tears into the project and now your contribution is ignored.

^this is precisely how I felt, so I did a bunch of angry googling on the issue. And I realised that the problem is the following:

My local git user email is different to my GitHub user email!

It appears that this is by far the most common reason why you are not showing up as an open source contributor even after your pull request got merged. Because GitHub doesn't recognise that it is you, my@emailaddress.com (your GitHub email) if you used myother@emailaddress.org instead to make your commit on your local git.

To change that, either add your email to your GitHub account in your GitHub settings, or change your local git email address by typing in the following in your command line:

git config --global user.email = "My@emailadress.com"

To check what email address you are currently using for your local git, you can type in the following command within one of your git repository:

cat .git/config

Another way to check is by typing:

git log

which gives you a more detailed version of all your commits and the corresponding email address for each one of them.

Now that you have aligned your local git email and your GitHub email, you will finally get your well deserved recognition for your open source contribution!

This would hopefully make you one heck of a happy pikachu!

I hope this helps! This is just one of the reasons why you are not showing up as an open source contributor, if this doesn't work, you might have to find the coder's best friend for extra help.

As always, happy coding!

What is Jekyll and why might you want to learn it?

Arnold Ho — Thu, 09 Sep 2021 22:18:12 +0000

What is Jekyll and why might you want to learn it?

Disclaimer: I am not an expert, I am only Learning in Public.
Also, this post is not meant to be a comprehensive tutorial on how to set up Jekyll, for that I recommend this Jekyll guide from Happy Coding.

Jekyll is a powerful tool written in Ruby that lets you do two handy things with your website:

It lets you set your layout once and apply it to all of your pages
It lets you convert markdowns into HTML

I will run through each of these points.

Setting your layout

Without Jekyll, if you try to create a blog from scratch or a site that's kind of like a library with many different pages on it, you will set up an HTML file for each page. Your page might look something like this:

<header> My Awesome blog </header>

<nav>
  <a href="#">HTML</a> 
  <a href="#">CSS</a> 
  <a href="#">JavaScript</a> 
  <a href="#">Python</a>
</nav>

<div>
<h1> Here is my blog title </h1>

<p> Here are my content </p>
</div>

<footer>
  <a href=#twitter</a> 
  <a href=#>facebook</a> 
  <a href=#>Youtube</a> 
  <a href=#>GitHub</a>
</footer>

(code might not be exactly how you would write to get all your CSS write, the above is for illustration purpose only)

Why is this a problem you might ask, imagine you grew your blog now and you have more than a hundred pages. Now, suddenly you thought of a new feature to implement, maybe a comment section below your blog, or maybe you would want to change the style and add an extra link to your navbar. Now you would have to change all your html on every single page. This sounds extremely tedious and error prone, as programmers we'd rather not be doing that.

Fortunately, with Jekyll you would be able to automate your code. You will need to create a default layout page, call it default.html. Your default.html would look something like this:

<header> My Awesome blog </header>

<nav>
  <a href="#">HTML</a> 
  <a href="#">CSS</a> 
  <a href="#">JavaScript</a> 
  <a href="#">Python</a>
</nav>

{{ content }}

<footer>
  <a href=#twitter</a> 
  <a href=#>facebook</a> 
  <a href=#>Youtube</a> 
  <a href=#>GitHub</a>
</footer>

{{ content }} tells Jekyll that this is the place that they will fetch the content from your other files (either HTML or Markdown).

Now, when you create your new pages, you just need to write these instead:

---
layout: default
---

<h1> Here is my blog title </h1>

<p> Here are my content </p>

These blocks of html code goes straight into the {{ content }} part of the default layout for every new page that you have created.

By using Jekyll, you will be able to automate the repetitive parts of your html script. Now if you want to change your navbar or add a sidebar feature and your page, you only need to change it once in your default.html file. This is super handy and eliminate most of your sources of errors in one step.

Converting markdown into HTML

If you used markdown before (which you would have if you use GitHub or have created a post on dev.to), you would know how much more handy it is to write markdown files compared to writing HTML. Jekyll converts your markdown into html for you so that if you have a large website or blog, you can write everything in markdown and host it on a site that runs Jekyll (Github does that, so you can do this by hosting your blog on GitHub for example). This saves loads of time and eliminates sources of error.
If you haven't written markdown before, here is a comparison between html and markdown for the same article:

Your HTML looks like this

<h1>This is my header</h1>

<p>This is my paragraph</p>

<h2>This is my subheader</h2>

<ul>
  <li>item 1</li>
  <li>item 2</li>
  <li>item 3</li>
  <li>item 4</li>
</ul>

<a href=github.com>here is a link to github</a>

Your markdown looks like this

#This is my header

This is my paragraph

##This is my subheader

-item 1
-item 2
-item 3
-item 4

[here is a link to github](github.com)

When you have a lot of content, this starts to make a significant difference to how much time you need to put in to create each page. So being able to convert your markdown into HTML is an extremely powerful tool for if you want to create a large blog.

note: I haven't gone through the nitty gritty of how to set up Jekyll, this post is mainly to illustrate the power of using Jekyll. For a more in-depth tutorial, I would highly recommend this Jekyll guide from Happy Coding, or to go to the Jekyll site itself to learn form the source.

Let me know if there are any important details of Jekyll you felt like I have missed out, I am always happy to be corrected :)

Happy coding!

Simple way to increase site accessibility

Arnold Ho — Tue, 07 Sep 2021 15:09:49 +0000

Disclaimer: I am not an expert, this is more like a note to self kind of thing. I am merely learning in public

When you make a website with different links, here is how your html file might look like:

<p>If you want an html tutorial, click <a href=tutorial.link>here</a></p>

<p>if you want an example html, click <a href=example.com>here</a></p>

If the user is accessing your website visually, they are not going to have a problem when visiting your website. However, if someone is accessing your website using a voice reader and they want to navigate all the links on your website, all they are going to here is a bunch of 'here's because that is the name embedded in your link tags.

One simple fix is to restructure your sentence so that the text within the a tag tells the person what it is:

<p>Here are <a href=tutorial.link>my html tutorials</a></p>

<p>Here are <a href=example.com>a list of example html scripts</a></p>

For someone who visually visits your website they are not going to see much difference. However, this way of writing your html dramatically improves the user experience for someone using a voice reader. So bare this in mind when you are cleaning up/making your website :)

Happy coding!

Refactoring ELI5

Arnold Ho — Sat, 04 Sep 2021 12:00:25 +0000

Disclaimer: I am not an expert, I am merely learning in public. If I got something wrong or left out important details, please leave a comment! ❤️

Alrighty, lets go!

Refactoring a piece of code changes the structure of your existing code without altering what it does. Take a look at the following javascript example:

if(weather === 'rainy') {
  console.log('bring an umbrella')
} else {
  console.log('no need umbrella')
}

In the code above, I passed the variable weather into the conditional function, if its rainy, the code will tell me to bring an umbrella.

This code is fine, but we can do everything in a much simpler way with the following:

console.log(weather === 'rainy'? 'bring an umbrella': 'no need umbrella')

In the second code, I have turned the if else statement into a ternary operator wrapped around by a console.log. The two codes do exactly the same thing but the second one is just a lot simpler to look at.

We refactor our codes because of a few things (non exhaustive list):

Improve our code readability (Imagine extending the above idea into a huge file with many lines)
Improve efficiency of our code, making it easier to work with
You can refactor a code such that features can be re-used elsewhere

Happy coding!

What is semantic HTML and why does it matter?

Arnold Ho — Mon, 30 Aug 2021 15:32:24 +0000

There are two ways you can write an HTML file:

<div>
  <h1>This is a header</h1>
</div>

<div>
  <p>This is a nav bar</p>
  <ul>
    <li>first thing</li>
    <li>second thing</li>
  </ul>
</div>

<div>
  <p>this is the content</p>
</div>

<div>
  <p>this is a footer</p>
<div>

Or you can do this instead:

<header>
  <h1>This is a header</h1>
</header>

<nav>
  <p>This is a nav bar</p>
  <ul>
    <li>first thing</li>
    <li>second thing</li>
  </ul>
</nav>

<main>
  <p>this is the content</p>
</main>

<footer>
  <p>this is a footer</p>
<footer>

Both files do the exact same thing, however if you have a long html file, writing it in the way we write the first one can quickly get messy. Whereas in the second way, it provides a bit more structure to your html.

So second file is called a semantic HTML. The advantages are:

It improves readability of your code, someone else can look at it and quickly figure out what you are doing. If you write a website in the first way, in 15 minutes you are going to forget what you did and hate yourself for that.
It makes CSS this much easier. You don't have to rely on loads of ids.
It improves your SEOs, not all divs are created equal and by writing your HTML in a semantic way it tells Google (or ... Bing) how they should rank your website. Which part is more important etc.
It helps the accessibility of your website. Not all of us use internet the same way. This way of writing your HTML file helps in situations such as if your audience is viewing your website using a speech reader.

There you go, hope you find this useful!

Happy coding :)