Ups and downs
At the beginning of the journey, I didn't know how many features I can integrate into the system, but I knew for a fact that a user login is required.
But very soon I figured out that requires a properly working domain to work well, which means I needed to deploy the app.
To be able to have a "continuous" deployment, I decided to use docker and docker-compose, that way I could be sure that if things are working on my (windows) machine, they're still working on the Linux server.
So now day 2 was all about adding login. Using Auth0 made things much easier for me because the login, logout, and sign-up functionality were all provided out-of-the-box. There were a few glitches because of using a new API, but easy enough to fix.
Now that I had the login and the deployment, it was time to create some pretty UI. But again, I couldn't go on without having a mockup/wireframe. So I decided to create a simple wireframe using Balsamiq. It was easy enough to create wireframes and export them as images. The final result wasn't far off what was actually implemented in the end.
- The original UI was implemented using pugjs and was working fine
- Reactjs was going to add a lot of complexity which wasn't needed at this stage
You can see a list of pros and cons which helped me decide here.
For day 4 I decided to do some refactoring first. The reason was the create page which was supposed to let users enter arbitrary descriptions for their pixels. Before this, the pixel name was extracted from the URL of the create page (`/create/name.png`), this wouldn't be intuitive for users, so had to go. Instead I decided to use the image ID in the DB to maintain a one-to-one mapping between the pixels and their record in the DB.
I was naive to think that I can do that refactoring then go ahead and implement the new design, the decision led to a long list of tasks which in the end did not finish and robbed me of the sense of accomplishment I used to get by the end of each day.
Finally, on day 5 I got to implement the UI using Material Design Lite and pugjs. It was relatively straightforward, as I didn't need to add any boilerplates and could jump right into implementing the features. On the downside though, pugjs wasn't great when it comes to composable components, so I had to mix JS, HTML, and a lot of
I decided to tend to some bugs that I found while testing the app (with help from a friend). In my opinion, good usability is even more important than good looks (at least in the longer term).
I decided to fix some bugs and it was showing my lack of sleep and late-night works have done some damage to the quality of the product, maybe I'll write about that later.
Also, I got lucky enough to be able to implement live-update in the end. It was actually pretty hard because I was super tired by the end of day 7 and was literally adding more bugs than fixing them.
It was a 7-day challenge that I made for myself to sharpen my skills and make an app I used to use to be usable by others. During the days of building in public, I learned a few lessons:
- It is very fun, seeing users visiting your site and exploring around (even getting feedbacks)
- Keeps you motivated to work constantly without interruption (no matter what)
- Can cut down unnecessary features for the important ones, because of the time constraint
- I got a lot of Twitter engagement that I would not get otherwise
- I decided to do the same with my old code in the coming weeks (with probably more realistic goals)