Thoughts about coding/programming

Hi there, lately some thoughts about various subjects have been percolating in my mind, and I think I should just write them out, to solidify what I’m thinking about and keep as a note to remember in future.

So this post contains some thoughts about programming or writing code. I think one of the important things I’ve learned during my bootcamp was code quality. I wrote very briefly about it some time back over here, but I should elaborate more this time.

Quality code is understandable, readable, tested, discoverable, changeable, documented.

The thing about programming or building software is you’re essentially writing text or words (code). Lines and lines of them. So these lines of code are the building blocks, imagine Lego blocks, that join together and are processed by the computer to perform functions.


In programming languages, there’s a distinction between higher level languages and lower level ones. Lower level languages are assembly language or machine code, they are not easily readable by humans because they are like 1s or 0s. Imagine seeing 1100011111100001010001010. It’s almost impossible to decipher and takes hours even if you try. Thus, higher level languages like C was invented, building on alphabets and mathematical symbols, things we can more easily read and understand. Then over the years, higher degrees of languages were invented, for example Ruby, which reads almost like normal English. This increases the speed in which humans can write, read and understand code, while making fewer errors.

Sorry for digressing, anyway, when programmers write code, they’re writing it for two audiences: (1) the computer to run the code, and (2) other programmers.


To dispel a myth that’s perpetuated by the media, of the lone wolf programmer who works in isolation, the reality is much programming work in the real world is done collaboratively. Each person builds a certain module or part of the software, and different parts are built at the same time by different people. It’s almost like construction workers building a HDB flat. So there has to be communication and cooperation between the programmers – they should at least have a general understanding of what the other person is writing, and thus, their code has to be standardised/formatted, and should be written in a way that’s understandable by others.

Just as in English, where you can express the same meaning using different phrases, it’s similar in code. You can get the same function or result using different paths, some of which can be complex or indirect. Usually, programmers will opt for a direct and understandable path, balancing computing speed and efficiency.

True, that are cases where one person builds the software, writing all the lines by himself or herself, so on the surface, if the computer understands the code, it doesn’t matter if other people don’t. But we are forgetting that software is meant to outlast the people who wrote it. Programmers will leave or pass on, and the new person who comes in will have a tough time trying to understand what the previous guy wrote. They’ll be facing a bomb, wondering which parts of the code you can change or remove without crashing the whole system.


In addition, software systems are not foolproof. They are designed by humans to manipulate data and information. Certain scenarios or edge cases might not have been considered when the original programmers wrote the code, like what if the user fills a form by spelling out his age as ‘Twenty’, instead of using the numbers ’20’. If the programmers had not considered how to deal with this anomaly, the software system might not be able to handle it, will throw up errors, and the user gets stuck.

Besides human errors, there are also computing errors. It’s rare but possible because computers are physical objects that experience wear and tear, and there’s limitations on the calculations they perform. I was surprised to learn of the floating point error when I started learning. Floats are numbers with decimal places. Take 0.1 + 0.2, the answer is simple, 0.3. However, you’ll be surprised because the answer in some situations if you’re not careful, is 0.3000000000001.  Once you perform a series of calculations, the magnitude of errors become more significant, and if your software programme is handling salary payrolls for employees, they may find themselves receiving a few hundred or thousand dollars more than they should get.

To learn why this happens to computers, you can check out the link I provided. The short answer is computers perform calculations in binary : 1 or 0, while we use the decimal system – calculations in 10s. So our numbers need to be translated into binary form first, and in cases where numbers have decimal points, rounding errors are introduced into the process. So usually, to overcome this, the computer needs to be specified that arithmetic functions are performed on floating numbers.

What it all means, software systems are not perfect. They need to be maintained and monitored for errors, and this task takes time and eventually more than 1 person on it. So whatever code in it has to be readable and understandable by others. Thus, writing code is not just writing code, it’s also a form of communication.

You have to consider the point of view of the person who’s going to read your code, will they be able to understand the terms you’ve used? Is what you’ve written clear and yet concise?

Speaking of concise, sorry for the lengthy post. I’ll talk about other stuff next time. Like similarities between writing code and writing tv scripts. There’s parallels between the two processes, especially as it involves working in collaboration with others. Until then, have a good day ahead.


my first recursive function (Elm)

Yay, I wrote my first recursive function in Elm today.

I was working on the 99 problems tutorial and it had this question:

How do you find the last element in a list? 

I know that in Ruby, we can use the .last method to get it, but in Elm, there’s no such method.

So I tried this:

lastElement xs = case xs of
[] -> Nothing
[x] -> Just x
y::ys -> lastElement ys

And it worked! Yay! So to explain the code, lastElement is the function that takes a list xs as its argument.  The resulting cases are:

  • If the list is empty ([ ]), it returns Nothing,
  • If there’s one element in the list ([x]), it returns it (x).
  • If the list contains more than one element (y::ys), we will ignore the first element (y) and call the same function lastElement recursively on the rest of the list (ys). Thus, we will keep eliminating the head of the list until we reach the last element and return it.

This works as tested here.

I’m happy because I’m starting to see some results in my quest to learn Elm. 🙂

Elm and Functional Programming

I think I’m going to try learning Elm and functional programming, as a way to build skills in frontend and also sidestep the tediousness of javascript. In addition, Elm is static-typed and so I think it’ll give me a perspective on static-typed languages, and that’s different from a dynamically-typed language like Ruby.

I came across this nice online beginner’s course on Elm here. Still can’t believe that it’s free to learn, I’m just watching the videos and expecting a paywall to come up anytime, but so far, 3 lessons in, it’s been great. 🙂


Rails web scraper for diaryland

I finished building my webscraper yesterday. I wanted to learn how to build one, and I followed some online tutorials and used the nokogiri gem. It was quite a smooth and interesting experience… Nokogiri is useful, you can choose to target the elements you want to scrape using CSS or Xpath.

I’m not sure what’s Xpath, okay a quick google search says it’s syntax for targeting parts of an xml document. XML is similar to HTML, except the syntax is more descriptive, like actual words in the tags instead of <p>s, <br>s and what not.

Okay, so anyway, while learning to build the webscraper with nokogiri, I learnt some cool new things.

  1. I learnt about other webscraping gems like spidey and other tools; one useful tool is a Chrome extension called SelectorGadget (the name sounds similar to Inspector Gadget, that 80s cartoon series), it helps you easily find and group the CSS/Xpath elements you want to target.
  2. I also learnt to create a random User-Agent for when Nokogiri targets a html page, because if you don’t specify a User-Agent name, you get a default one, and after a few tries, you will get a 429 error code for sending too many requests to the site/page you want to scrape.
  3. Lastly, no matter how small the project is, there’s always something new to be learnt. I guess this is because of how new I am to web dev/programming.

My initial goal to scrape my own diaryland website is accomplished. Good job lol. I followed an online tutorial that was very informative. This one.

What next? I think there’s improvements to be made:

  1. For one, I’ll need to learn how to create a background service job for scraping. So that the rails server can do other things while it’s scraping; like serve the initial results first.
  2. And pagination, I think that’s easier with the Kaminari gem.

Okay, this is it. Oh yeah, another thing I learnt, well I learnt that i have about 680++ diaryland entries. That’s amazing haha. I’ve been writing stuff at my diaryland page since I was 24? That’s in 2004, so it’s been more than 13 years. Wow. I’m surprised diaryland is still around frankly.

So okay. See you. Yeah in case you want to scrape your own diaryland page, with rails, if you have either, you can see the source code here.

Soopbot, a Facebook chatbot demo

I made a simple Facebook chatbot demo. You can message it at its Facebook page and your email and message will be saved to this website. To check out the source code, just go to my github.

I decided to build this because I think it might be easier to demo the link between Facebook messenger to rails server to If you would like to see more of what can do, maybe you can check out Rem, the mood-journaling chatbot I did with my project mates in Alpha Camp. There’s more conversation design there.

I used facebook-messenger gem and api-ai gem to link the backend with both facebook and I think tinkerbox has a message-quickly gem that allows your rails app to integrate with Facebook messenger too for chatbot functions, it looks quite nifty,  i’ll try it out some time. Maybe after I try building a webscraper with rails (following an online tutorial). I’ve always wanted to build a webscraper, it’ll help me extract and save my diaryland postings. 🙂



Rem – AI Chatbot for mental wellness

Tonight was the night of our Alpha Camp project presentation. It marks the end of our 12 week web development course and we will soon be embarking on the next chapter of our life – back to work and reality! (More coding and learning.)

So, me, Nathan and Evan, we worked on a chatbot called Rem for our capstone project. Rem is supposed to provide a listening ear for users and comfort them when they feel depressed. Besides this, Rem also incorporates techniques from CBT (cognitive behavioural therapy) – the two techniques are Mood Journaling and Gratitude Journaling. Users will be encouraged by Rem to record down their moods throughout the day, and also record down what/who they are thankful for.  These techniques have been proven to work by the way.

So yeah, we bought a domain name and are running a hobby server at heroku for this. We’ll see how it goes. You can check it out at

Just sign up for an account, check your email for a confirmation link. And then you can enter our site to start chatting.

Also, after you have signed up, you can also go to facebook messenger and find Rem to chat. It will prompt you to link your fb account to the heyrem site, so just do that and you’ll be fine.

The digital marketing girls (Hui Sze and Desiree) have made a nice digital marketing landing page for Rem at  You can check it out for more details regarding Rem.

For Rem, we used ruby on rails to communicate with FB’s webhook for the messenger integration. And for the AI language processing, we used from Google. It’s a free service at the moment. I think it really helped that we approached the project together and supplied each other’s knowledge with our own learning at the same time. So that a daunting (and unknown) task eventually became more manageable.