I wanted the design of the app to be simple, providing the least amount of friction between the products and the customer so I took inspiration from design sites like Pinterest and Dribbble.

I decided to go native, writing the front-end of the app in Swift because I didn't want to rely on third-party frameworks. UIKit and CoreData were the frameworks I used for this project.

For the back-end, I decided to leverage Firebase from Google. I used their authentication service to handle all things related to users of the app (authentication and sign-in), their realtime database to store all data generated, their cloud storage to store user-generated content and their cloud-functions service to run Node.js scripts to handle server-side logic.

Adopting the agile methodology proved indispensible during the initial stages of development. By involving my sister in important design decisions, I was able to implement features that she believed would serve her customers best.

I also learned how important taking time to design a good architecture for a system can save a lot of time and trouble in the long run. I found myself violating the DRY (Don't Repeat Yourself) principle during early stages of implementation because of my poor initial design.

This app was built entirely with Swift with a heavy lean on CoreData to save events locally on device. I utilized an open source library called CalendarKit by Richard Topchii to handle displaying saved events.

Whenever a third-party framework is brought into your codebase, you introduce the chance of your code breaking when the author of that framework makes any changes. I learned this the hard way when an update to CalendarKit caused my application to crash. I was eventually able to resolve the issue but I learned from that experience to write wrappers around any third-party libraries so I can control how my code utilizes them.

I have always been excited by web development. After reading up on Javascript and it's immense capabilities, I wanted to build something to practice my skills. Coincidentally, I had just completed reading a couple of books on the art of software development so the idea to build a library of books I've enjoyed was a no-brainer.

I got to experience how state is managed with React when I had to consume data from Google's Books API and present them on screen. Similarly, building the back-end with Express.js and PostgreSQL allowed me to practice building a RESTful API.

Single-threadded programs, although relatively easy to write don't fully utilize the power of today's computers. I have been reading on multi-threading and wanted to explore firsthand the benefits of its application. Java implements multithreadding in multiple ways. From object locks to semaphores to special keywords for method signatures. I chose the latter in my implementaion. By including the keyword synchronized, sensitive methods can be marked to allow only one thread to operate on an object at any given time.

Architecturally, I abstracted the Persistence layer of my system. By creating a Database interface that has CRUD operations that any class that implements it defines, I have the flexibility to define a LocalDB class that uses a data structure to store information. Similarly, should I need to have true persistence in the future, I can easily create a class that implements the Database interface and also connects to any of the data store providers.