My One-Man Hackathon Session

Aiman Ismail — Sat, 21 Mar 2020 23:20:15 +0000

Last week I got an email for a telephone interview for my first full-time software engineering job. The shop uses mainly Vue.js and Laravel. I only had brief contact with Frontend programming using Angular 4 and Typescript during one of my internships before. Being overprepared that I am, this weekend, I wrote a simple static web application using Vue.js. My goal is to show my future employees (hello if you're reading this :) that I am ready to learn new languages/frameworks if need be.

Due to the timezone differences, the phone interview will be conducted in Malaysian office hours. I am currently in Germany (UTC+1), and the company that I'm applying for is based in Malaysia (UTC+8). While finding a suitable time for the interview, I realized that even though there are a lot of world clocks online that show what the current time in other timezones is, I cannot find any that offers me to enter any arbitrary time. So why not write one?

I started hacking around Friday at noon. My first commit is a design document describing what this application is about and how the user will interact with it. Here's a blog post from Julia Evans explaining why design document is a great idea, even for a small project.

After that, I dove into the documentation of Vue.js and started learning. My experience was pretty good, and the Essentials section had all that I need to know to bring my idea to life. I learn the most by using the framework directly. I ask myself questions on how to do something and then look for it in the documentation. Going through the docs all at once is okay, too, because we got to have an overview of what tools are available, but sometimes some concepts are a bit vague, and we cannot discern the differences unless it is put into practice.

Not all the things that I planned to do end up in the final product, but that's just how it is. You can go to https://pokgak.gitlab.io/whatistheirtime to check it out.

I hosted the application on Gitlab Pages (free hosting!) instead of Github because I had used Gitlab CI before and liked it. The idea of having an integrated platform for doing CI/CD and the whole DevOps lifecycle seems cool too. I know Github also has Actions now, but I haven't got to it yet.

I'm satisfied with the project as a weekend hack session. I got to learn a lot and brushed up on my HTML, Javascript skills and taught me some CSS. Aside from knowing what the abbreviation means and what it does, I knew nothing about CSS, so my application only has minimal styling for now. I plan to upgrade it further when I have the time in the future.

I Wrote a Dropbox Clone

Aiman Ismail — Wed, 18 Mar 2020 19:30:57 +0000

I took part in a course on cloud computing at my university last semester. The course is offered with cooperation with IBM. Two of IBMs engineer joins us as in the course and together with the professor, they assigned us the task to build a dropbox like cloud storage solution using the cloud.

We must choose at least two cloud providers to deploy our application on and my team chose Google Cloud Platform (GCP) and Microsoft Azure. We can also use any sort services offered by the cloud, at any level that we prefer. In the first day of the course, we are given the introduction into the abstraction levels offered by cloud providers. These are from the bottom: Host own infrastructure, Infrastructure as a Service, Platform as a Service, Serverless, or Software as a Service.

Background

Before explaining further, maybe it's good to first tell you first about our background. We are a group of 4 Computer Engineering students who, before this, mainly works with programming hardware. I have used Docker, Maven in the past and would consider myself somewhat comfortable on the command line in Linux. Another one does cloud software data connecting using software. That is how far our knowledge about cloud infrastructure goes --- virtually none.

Choosing Cloud Services

Our first task is to choose what type of abstraction we are going for. We are given 3 weeks for this task. After doing ~a bit of research~ discussion with my teammate, we decided to go as low-level as possible but still without putting too much burden on our shoulders on managing the infrastructure itself. As we are planning to deploy on multiple cloud, we also consider the work that are needed to port the application from one cloud provider to another.

As a result, we decided on Kubernetes! Why? Kubernetes as a service is offered by both of our chosen cloud providers. Depending on Kubernetes also means that we don't rely on the API/interface provided by the cloud provider. We can program our application once for Kubernetes, and the ground structure will not change for other cloud provider as we are still in the same environment --- in home k8s cluster.

We also decided on S3 based cloud storage and database services provided by the cloud providers so that we don't have to manage the software ourselves. Just use it.

Architecture

Next comes how we want to structure our application. Being cloud-native is almost synonymous with microservice architecture. So, giving in to the hype, we decided to use it too although we don't really have any concrete reason to prefer this architecture compared to classic monolithic architecture. Hello, distributed monoliths!

We need to do a lot of catchup on the terms used in web development generally e.g. what is URL, endpoints, basic auth, token, JWT but after our first meeting, I would say that we know a little bit more about the world of web development in general.

Hello, Cloud!

After we got all the designs done, now comes the implementing part. We first started with Azure as our first cloud provider. The documentation is okay, with tutorials on using the services and SDKs in the most popular language. The first challenge comes when each of us must work with new tools such as Docker, Maven and Spring Framework.

Regretfully (more on this later), with the deadline encroaching, I decided to take away the difficulties from my friends and be the guy that are responsible for building and packaging the software. I gave them the template generated from Spring Initializr, built the software, and wrote the Dockerfile myself. All they have to do is focus on the software part, using the built-in run button in their IDE of choice to run the software when they need to test if their code is working. This works out fine but I do wish that we took the time to explain and learn the tools together. As time goes by, I am becoming more and more the bottleneck of our team.

At the same time the others start writing the software, I started my journey playing with Kubernetes. There are tonnes of resources available online to learn K8s and the official documentation is also really good. I have to give a shoutout to the CNCF YouTube channel because I spent countless hours in my evening watching videos and learning more about the wonders of Kubernetes.

The Bus Factor

As I've mentioned before, ~we~ I decided to hide the complexities of the tools from my teammates with the intention to give them the smoothest experience writing software for the cloud. Admittedly, that decision is wrong. We should have spent the time learning the tools and concepts needed.

I think none of my teammates understood Kubernetes Pods, Deployments, Services. I never explained it to them. As the project goes on, I am the goto guy if we have to debug what is happening on our cluster. Only I knew how to use kubectl logs to see which exception is thrown. This dependency really did slow our development process. Now, we didn't have the knowledge to solve our own problem. All we did is throw our codes at the wall and hope that it works. If it didn't work, call Aiman!

Conclusion

We ~learned~ crammed a lot in our first three weeks in the project. Amidst all that, there are sure some concepts that we got wrong and designs that are clearly flawed due to our inexperience. We will see that in the next entry in this series. Hope to see you again next time!

DEV Community: Aiman Ismail