DEV Community: John Patrick Tobias

3 lessons from 3 years on joining startups as a Software Engineer

John Patrick Tobias — Tue, 18 Aug 2020 14:54:31 +0000

cover picture from Unsplash by Max Fuchs - https://unsplash.com/@designfuchs

Before my graduation in the university, I was inclined to join a startup due to the amount of content online against the existing corporate ladder and by reading Zero to One by Peter Thiel. Luckily for me, I had connections that were starting up a company from the ground up. As a fired up teen that was into startups, I didn't think twice, I joined them.

Jumping to three years after my first startup, I'm currently in my third startup, and here are the lessons or reflections I've gathered:

Be open to your startup about your opinions and complaints.

Being against openness and honesty to any company's management here in the Philippines is seen as a safe area to not get a bad reputation from upper management due to your ideas being bad or your complaints being negative. Thus keeping silent about your own ideas and complaints is seen as a good thing, but from what I experienced it isn't a good thing.

1. Your opinions could contribute to the next big solution/change that the company needed, thus improving the startup.

In my current startup, we always voice out our thoughts about the features we're developing. Some of the ideas we come up may be bad, but the act of brainstorming to come up with a robust solution makes the team feel confident in implementing that solution (and excited in bringing out a new feature).

This results to several features changing from time to time and having positive impact towards the usability of the user interface and the flexibility of the code.

This isn't only limited to the project we're developing, we also discuss the culture of the company in this manner as well, resulting into an enjoyable work environment.

2. Not voicing out your complaints makes unclear decisions.

My first startup didn't last longer than I expected. Having a dedicated group chat about our complaints as software engineers in the company made us hide our hatred and complaints towards the business-side. In the end, all of us software engineers decided to resign, resulting in dissolving the startup.

The problem here is not us leaving, but about us not voicing out our opinions about the current state of the company (before we decided to leave). We, as a whole startup, could've discussed about the problem and created a solution, with our without us leaving. Instead, we decided to leave without discussing our concerns thus creating unclear decisions.

Try testing out new technologies from time to time.

In my experience, doing something all the time in the safe zone of your domain of knowledge seems comfortable, and gets the job done but, it lacks growth. I've experienced projects that use the same frameworks and libraries on and on and it gets boring to a point. As startups, we should learn to experiment on tools that could make our workflow easy (and sometimes cheaper).

Having a small team has its challenges when it comes to doing quality assurance (QA) or maintaining the infrastructure of your cloud. That's why in our startup, we decided to use technologies that could ease that part. Of course, it takes time to setup but it's rewarding in the long run to have these tools ready-to-use all the time. I'll name a few and explain it briefly. I won't go in-depth to keep this blog short.

Terraform - a cloud infrastructure manager that uses a JSON-like syntax for you to easily manage the cloud without having to create services in the web console. This can be useful if you have multiple projects with the same infrastructure most of the time.

Serverless - almost the same as Terraform but more focused towards maintaining serverless functions like AWS Lambda functions. Deploying serverless functions can help you save cost on compute time if you have functions that can be separated from the main server and isn't ran most of the time (e.g. a downloader of a PDF or CSV report). This is one of my favorite technologies to explore, so I suggest you look into this!

Gitlab - used mostly for its reliable CI/CD (continuous integration / continuous deployment). This is a powerful tool combined with Terraform & Serverless as it can automatically spin up and tear down services using Terraform and Serverless' CLI commands. It's also best paired with Docker. Learn it if you want to get into deploying projects automatically every push to a branch.

There are more technologies that I have tinkered with but these are the honorable mentions I can think of. These are the commonly used tools in our daily grind. So if you're looking to easing the workflow with deployment and cloud infrastructure, I suggest you look into these technologies.

Of course, these solutions won't solve problems forever if the scale of the software begins to grow bigger (meaning more work for QA automation and cloud infrastructure scripts). It only serves a purpose in deploying reliable products in a fast way for fast results. Eventually startups would need to scale their manpower depending on the amount of work that's starting to grow due to the product's scale.

As mentioned before, exploring new technologies are good for your growth but its impossible to learn everything that exists in the world of code. That's the beauty of the coding world, endless learning! Just test and try tools and possibly you'll come up with what suits your workflow best. In a nutshell, it's being open to discard old knowledge and learn something new since in the world of code, some of the tools you learn won't last long to see the world end and will be replaced with something new and shiny (R.I.P. Adobe Flash).

Since we're speaking about growth, this is a nice segue into the next and last lesson.

Don't forget about yourself!

Being in the startup scene, there may be times that you are needed to squeeze every hour in a day. That sucks for some people but if it makes you feel good, then that's fine (whatever floats your boat). Just be mindful not to exhaust yourself too much or you might sacrifice your well-being due to burnout or any other illness that could come up from being overworked.

Pushing beyond your limit is also good from time to time, but be wary of what your limit is. Sometimes due to motivation, we tend to put unrealistic goals for ourselves that is really far beyond our limit that we can't even reach. This makes it easy for demotivation to creep in and say that "you won't make it!". From what I've experienced, it's good to also think of the process behind of achieving a goal. Starting there, assess what you currently have in your arsenal that could kickstart you in doing that process. In that way, you could see what you can currently reach in your limit and slowly climb the process from where you stand.

Always be open that processes tend to change midway of executing it. From the book Flow by Mihaly Csikszentmihalyi, he explained that moving towards a goal doesn't always go as planned, and I've experienced that in numerous occasions (most of the time in code). Sometimes we meet circumstances along the way that make us adjust in order to move forward. In the end of that changing path, there's a possibility that the end result could look better than you expected.

What is with this self-help mumbo jumbo you ask? Well, without those lessons, I would've been more burnt out as ever due to the amount of demotivation I had in my kokote (which as a word for brain or mind in Tagalog). There were multiple occasions that I set unrealistic goals for myself and end up discarding it because all I thought of was the goal, not the process. Also, there were times that I get upset if things don't go as planned, instead of adapting to what happened. If you've encountered these problems, try giving those lessons a go!

Learning to set realistic and attainable goals, and even learning to celebrate small goals, can make you more motivated to move forward and also leading to making you a happier as a person.

Don't go drowning in a sea of unfulfilled dreams and forget yourself. Start decluttering your mind and focus on what you can do in the present. It's easier said than done and eventually you'll encounter these moments in life from time to time, but it's part of the process.

Take care of yourself! It's not bad to take time off for eating food or sleeping on time (and even play games, just not too much). Sometimes for better quality work, we need to take time off from work (as juxtaposed as that sounds).

Developing & Designing a Music Composition App Tailored for Composers

John Patrick Tobias — Thu, 03 Oct 2019 04:10:10 +0000

Back when our college life was coming to a close, all of us were tasked to create a thesis or a research. As to what our professor said, "It must contribute or add something new to the current knowledge that the world has". That really got me thinking. I started thinking of possible automated technologies that can be done with artificial intelligence that would make people say "wow".

So together with my team and our thesis adviser, we brainstormed on possible topics that we can explore for our thesis. Somehow due to our previous research on building an air guitar using Myo Armbands, we shifted our focus on creating or composing music. So our problem at that time was...

"How can we contribute something new to composers that would benefit them and at the same time, adding something new to the knowledge base of Computer Science?".

Ideation Phase

It took us about an hour or two to come up with an idea that is possible with today's technology. That idea was creating melodies with gesture-based controls. It was like the swiping gesture found in smartphones' keyboards, but instead of producing words, it would produce notes. When the gesture slides upwards, it would produce a melody upwards, same thing for downwards. We even thought of varying gestures like drawing a zigzag or twirling pattern would produce different types of melodies.

Definitely it would look cool while composing music (which was our second priority, just kidding!), but we came to a theory that it may be able to benefit composers who get stuck when they reach creative block. Thus making it a solution for them to explore what the computer can generate for them and tweak or edit it to their liking.

After landing on that idea, we started reading journals and papers that could help giving a computer the ability to create music. We read about various genetic algorithms that generate music through a lot of iterations, and also Markov Chains.

After some time, one of us became worried that it might cause composers to revolt against our idea due to the fact that we're somehow automating their craft through our software. That worry led us to interview a professional composer. Lucky for us, my brother graduated as a music major in a near university so he knew some professors that are really good composers. So he gave us a few composers that we could contact and one of them was Sir Juan Carlo Magsalin (we call him Sir JC). We contacted and scheduled an interview with him. Soon enough, we were happy that he accepted to meet with us.

We asked him various questions that would help prove if our idea was helpful. The interview turned out great and to our surprise, our future isn't a bad idea as we thought. As long as we keep in mind that it should aid the composer instead of replacing him or her. After we came back to our research lab, we were then tasked by our thesis adviser to formulate a research framework.

Creating and Testing the Mid-Fidelity Prototype

Inline with our research framework, we started drawing our sample user interfaces on paper. This is a good strategy in the early process of prototyping or designing since everything done on paper is easily changeable if there are needed changes. We proceeded to present to each other our drawings and ideas. As we went on with the meeting, we supported each other's ideas and suggested changes to some ideas presented. After that, we formed our mid-fidelity prototype using Gravit and InVision based off the drawings and ideas we fixed and formulated. We made the designs to fit an iPad Mini to be used for our testing.

After creating the prototype, we wanted to test it to a number of composers. This is the part where we would stay calm when testers say that "the design is bad" because normally in the first few phases, that would occur most of the time. Instead of being angry or panicking, we ask them why. In that way we could get insightful comments from them that can help us improve the design. If there were no comments, usually we try to solve the problem by easing the interaction that the users had a hard time in using.

With several data in our hands, we proceeded to improve our prototype based on those data. We tested it again with Sir JC and other composers. The data we got from there were improved compared to before but some interactions were still hard to do.

On top of that, Sir JC caught some errors in our prototype which conflicts with the rules of music theory. He suggested a few books that we could read and borrow from their library for us to educate ourselves with music theory. I was the one who got tasked to get familiar with music writing (and I also appreciated it since I wanted to learn how to read music sheets!). Educating myself with music theory wasn't an easy task. It was a new field for me to discover, but I tried my best to understand it. This was an important step because it really helped a lot when we were developing the app in the iPad since there are plenty of rules and math to keep in mind.

Moving to High-Fidelity Prototypes

Soon enough we moved to coding the application in the iPad ecosystem using Swift 4.0 (For you questioning why not 5.0? Because Swift 5.0 wasn't available at that time yet. You hater.). This was also our first time learning and using Swift, but we didn't let that discourage us to develop this app. We gladly learned Swift and all its benefits compared to other programming languages (can't forget about Swift's null safety and awesome variable observer methods).

After learning basic music notation, we tried to put it into code and create a good basic prototype that involved adding, selecting, deleting, and editing notes. We also created a procedure or a set of tasks for composers to follow during testing and a post-testing questionnaire for them to answer. The testing procedure contained steps like "Add a note", "Delete a note", "Recreate Little Little Star", and more. The questionnaire was there to measure the difficulty per task or feature. Each task had a Likert scale which would let the composer rate the feature with four (4) being easy to one (1) being difficult. We did this so that we can review the scores which would eventually lead us to revamp the feature.

Throughout our research we did a total of four phases or iterations to improve the application. So here starts our journey to studying users or composers.

"But wait! Where's the swiping gesture that would generate a melody?"

Oh right! Midway in developing the app we decided to focus more on the user experience aspect of the application. Since there are no music composition apps that we can edit or code a plugin on, we decided to create a music composition app that has good usability first before tackling the melody suggestion feature. The generating of music would be future work (hopefully!). But don't close this article yet! The user research journey that I'm about to tell was still fun. Let's proceed with the article.

Testing our High-Fidelity Prototypes

We did a total of four (4) testing phases for our app which consists of varying participants per phase. Throughout each phase, we try to implement new features and fix design issues based on previous iterations. We also let our testers compose using traditional pen and paper, and use existing iPad apps that are currently in the app store (specifically Notion and komp) so that we can also learn from the traditional way and the existing apps, and benchmark our app if it's better or worse than those methods.

I'll be going through each iteration briefly. So, here it goes.

First Iteration

For the first iteration, just like the mid-fidelity prototype, we implemented a movable cursor (for pointing the selected location in the music sheet), and adding, editing, deleting, and highlighting of music notes. We let various music composers test our prototype.

Here are the ratings from the post-testing assessment:

List of features with high average scores:

Moving the indicator/cursor (3.6)
Moving the line/space selector (3.3)

List of features with low average scores:

Highlighting/Selecting Notes (2.5)
Delete a Note (2.3)
Edit a Note (2.2)
Add Note/s (2.8)
Editing a group of notes (2.2)
Deleting a group of notes (2.2)

Average Score: 2.6

Yep, we messed it up on our first prototype. But this was due to two (2) main reasons:

The highlighting feature was assigned to a two-finger drag along the music sheet. This made it hard for the composers to execute since they were trying a one-finger drag instead of a two-finger drag.
The buttons were too small which hindered some composers in tapping them. This is due to us always testing it on the iPad simulator provided in Xcode. It didn't simulate a real iPad interaction since we used a mouse cursor to tap/click on the buttons.

Improvements from the First Iteration

Due to the highlighting feature hindering majority of the usability. We changed the two-finger drag to a one-finger drag.

We also made the buttons bigger for a human finger to tap/touch. This made me realize that testing usability for mobile devices must really be tested on a mobile device, not from a simulator or any form of emulating the screen size in a desktop.

Second Iteration

In the second iteration, we added more features into our app. These features are:

Changing Time/Key Signature
Adding/Removing an accidental to a note or a group of notes
Zooming In/Out
Cut/Copy/Paste a note or a group of notes
Selecting a single note via hovering (not just higlighting)
Music Playback
Redesign of the delete button

The said features were also included in the testing of our application to composers. Here are the results:

List of features with high average scores:

Add a Note (3.5)
Delete a Note (3.2)
Edit a Note (3.6)
Moving the indicator/cursor (3.6)
Moving the line/space selector (3.4)
Highlighting/Selecting Notes (3.8)
Editing a group of notes (3.6)
Deleting a group of notes (4.0)
Scrolling thru the music sheet (3.5)
Change Time Signature (3.2)
Change Key Signature (3.5)
Add an Accidental to a Note (3.8)
Zooming In/Out (3.5)
Cut/Copy/Paste a Single Note (3.0)
Select a single note (3.7)
Add an Accidental to a group of notes (3.3)
Music Playback (4.0)

List of features with low average scores:

Remove an Accidental to a Note (2.6)
Cut/Copy/Paste a a group of notes (2.7)
Remove an Accidental to a group of notes (2.7)

Average Score: 3.4

Several features improved and the new features also had high scores that we didn't expect. However, don't let the high scores fool you. There were comments from the users that made us redesign some of the features that had high scores.

Some features can be improved better based on the comments we received. Those comments are:

The slider in changing the time signature made it hard to select a specific number.
The slide selection for the key signature was not clear in showing all the possible options.
Transposing note/s weren't evident or obvious enough for users to do.

The comments from the features that had a low score was:

The Cut/Copy/Paste lacked feedback or a notification when they tap the buttons for those features. The buttons for those features were also small.
Removing an accidental of a note or a group of notes was not intuitive for composers that have knowledge in music theory. The buttons for the accidentals were also small, but the main reason why they scored it low was because the interaction didn't follow music theory. According to them, removing an accidental should be done by "naturalizing". With that in mind, composers kept tapping the naturalize accidental button when they were trying to remove a sharp or flat from a note or a group of notes.

Improvements from the Second Iteration

With the time/key signature controls being hard to use led us to implement a complete overhaul of it.

We moved the transpose controls from the visible arrow keys, to a new control panel that shows when the user selects a note.

Third Iteration

In the third iteration, we implemented new features that would let composers further customize their compositions. These features are:

Putting ottava (8 va) & quindicesima (15 va) symbols for possible higher or lower pitches than before.
Putting 1 to 3 dots for dotted notes.
The ability to create chords.
A keyboard style input for people that are used to using MIDI keyboards as their input controls.

We also narrowed down the type of scores that we had so that we can focus more on the base actions of the application (instead of per feature). These are the scores:

Select/Highlighting of Notes (3.7)
Add Notes/Chords (3.7)
Edit Notes/Chords (3.3)
Delete Notes/Chords (3.7)
Cut, copy, & paste Notes/Chords (3.3)
Undo/Redo an action (3.8)
Music Playback (3.1)

Average Score: 3.5

Several improvements from the second iteration really helped in improving the scores even more. But there are still a few problems we noticed when we were watching the composers use our application.

Composers were having a hard time switching their fingers to the top and bottom menus.

The toggling of the keyboard input was not evident.
They also suggested that a guiding line should show when playback is happening. This would let them know which note is currently being played.

Improvements from the Third Iteration

We joined the top and bottom menus to make it more friendly for the composers' fingers.

Music Playback now shows a line to show which note is currently playing.

Fourth Iteration

For the fourth iteration, our testers were majority professionals (composers that compose for famous artists, a professor that lead a chorale, and students from the conservatory of music). Because of that, the score became lower than the previous iteration. They told us that our app still lacked more features and modifiers for them to further customize their composition. However, they were happy with the interaction with our app especially because of the cursor/line. They even told us that it's beginner friendly because its straightforward enough.

The Scores:

Select/Highlighting of Notes (3.4)
Add Notes/Chords (3.2)
Edit Notes/Chords (3.0)
Delete Notes/Chords (3.4)
Cut, copy, & paste Notes/Chords (2.9)
Undo/Redo an action (3.6)
Music Playback (2.9)

One composer even had a hard time performing the highlight feature, which also led him to not perform the cut, copy, and paste feature. That composer told us that he was not used to using mobile apps so its possible that that is the reason he is not accustomed using mobile applications.

Another composer also rated the music playback low because a bug occurred while that feature is being used. The tempo became slower and slower every time the composition is being repeatedly played. This made the composer disappointed because that composer is an avid user of playback to check the composition if its according to what he or she wants. This was entirely our fault because in our code, we forgot to dispose the previous instance of the playback when the playback stopped. That caused multiple instantiations to exist that began to slow down the app due to memory leaks.

Final Words

Unfortunately we stopped at the fourth iteration, this isn't because we became demotivated, but our time in the university has come to a close. A lot of testers really wanted to get our app after they tested it and I feel sorry, up until to this day, for those people because we won't be publishing this app anytime sooner (very sorry). This is due to the fact that it's still unfinished work. Maybe in the future, new researchers in our research lab might continue this UX adventure that we started.

I enjoyed this experience because I got to learn a part of music theory and also attempt to develop and design a user-centered tool that they can use to produce their craft with ease. With that said, this research taught me to put myself in the shoes of the user in order to design an interaction suited for them.

P.S. Thank you to Sir Jordan Deja for being a good mentor in user experience research and to all composers that tested our app (you all helped us graduate college).

My Experience in Creating a Website with a Non-Traditional Layout

John Patrick Tobias — Mon, 17 Jun 2019 10:35:40 +0000

We've been accustomed to websites having navigation bars at the top, the content in the middle, and footers at the bottom that contain links. This became the traditional and convenient way when designing websites in general. It provides the user the info he/she needs to find in a user friendly manner since we've been accustomed to scrolling from top to bottom when viewing a webpage. However, I was assigned to create a website that didn't follow that. A website that involves scrolling from left-to-right and top-to-bottom as screen transitions from the homepage was presented to me with the use of Adobe XD. That is what I had to do.

Personal Skill Assessment Before Starting The Project

During web projects in my university, I stayed away from using CSS for creating layouts because of my extensive use of Bootstrap. So I was totally useless when it comes to using CSS for designing a page without Bootstrap. So I didn't know how to use flex (which turned out to be handy as hell).

I had a feeling in my gut that I should use ReactJS for this project simply because the current screen being viewed could be stored in a state which I could just change with a simple this.setState();. Nevertheless, I had barely scratched the surface when it comes to using React since I tried some things out in React Native before so I know a thing or two about handling states. (P.S. It's been a while since I used JavaScript since I'm more used to REST frameworks that don't involve any JS code, so I also don't have a clue what ES6 had in store)

Knowing that ReactJS had a ginormous amount of packages that can be simply Googled and be quickly installed with a simple npm install insert-package-name-here thru the terminal, it really supported my gut feeling that ReactJS was the right library to use for this project (because that would make me progress in this project faster).

I decided to revisit Google's Firebase for storing data since I've used it before in a mobile application project that involved reading and writing Google Maps coordinates inside Firebase for our class in the university.

Basically that was my inner dialogue before I started the project. Since I was doing it by myself, I just had to assess myself about my strengths and weaknesses with relation to the project that I was about to do. :)

So in short, these are the tools that I decided to use:

ReactJS (JSX, CSS, JavaScript ES6)
Firebase (for the database and file storage)

Making The Design Come To Life

The first step I chose to do was the skeleton of the screen transitions. This is by starting to create the behavior of containers entering and exiting out of the view. Luckily, I came across the package React Transition Group.

reactjs / react-transition-group

An easy way to perform animations when a React component enters or leaves the DOM

react-transition-group

ATTENTION! To address many issues that have come up over the years, the API in v2 and above is not backwards compatible with the original React addon (v1-stable).

For a drop-in replacement for react-addons-transition-group and react-addons-css-transition-group, use the v1 release. Documentation and code for that release are available on the v1-stable branch.

We are no longer updating the v1 codebase, please upgrade to the latest version when possible

A set of components for managing component states (including mounting and unmounting) over time, specifically designed with animation in mind.

Documentation

TypeScript

TypeScript definitions are published via DefinitelyTyped and can be installed via the following command:

npm install @types/react-transition-group

Examples

Clone the repo first:

git@github.com:reactjs/react-transition-group.git

Then run npm install (or yarn), and finally npm run storybook to start a storybook instance that you can navigate to in your browser to see the…

View on GitHub

This package simulated the lifecycle methods of components through various CSS class names instead of JavaScript functions. I won't go through an in-depth guide on this but I hope you get the gist that this is really useful in the screen transitions that I'm about to do.

With React Transition Group I managed to make the sliding animations for the page transitions. My next goal was to create the different layouts per page. Those pages are the homepage, services, team, portfolio, and contact us page. As a dev that didn't understand much about CSS before starting this project, I managed to land on what people use nowadays called the Flexbox in CSS (a.k.a. godsend layout tool). I used it while following a guide in CSS Tricks (A Complete Guide to Flexbox) which was so helpful in learning and using it.

Homepage

Services Page

Team Page

Portfolio

Portfolio with an artist chosen

Contact page overlay

The first page I did was the homepage. By working on the layout, I became familiar with CSS and especially with Flexbox. I began using z-indices to help me layer things such as the white dots in the background, the text in front, and the circles that go along with the navigation. I became comfortable in experimenting with flex-grow to put weights in the resizing of the interface when resized. Using the different attributes of align-items and justify-content to align contents of different containers to their respective alignments. However, I also realized that using React's states with CSS can enable you to create animations as long as the transition property in CSS is present.

For the circles, I had to create a trick that makes it responsive so that when you resize the window it doesn't get stuck in one place (this happened when I used the left, and right properties in CSS). There is a rectangle that is being resized that carries the circle on the edge of that rectangle. The GIF below demonstrates it with the rectangle having the red background. The rectangle also adjusts to the size of the window so the circle will definitely move with it as it resizes due to window resizing.

With the knowledge of Flexbox and more CSS than before, I breezed through the different pages except for the Portfolio. I spent more time in the Portfolio page because of the right side modal. The modal contains the different songs of an artist that can be played and a Spotify playlist/album embedded player for that artist. I also had to double check that the player works on several browsers since there was a case that it works on Chrome but it doesn't work on Firefox so I had to fix it when I encountered that issue. The Spotify embedded player was easy-as-pie to integrate since it just uses an iframe in HTML and it just requires you to pass an embedded link of the Spotify playlist or album that you want to display. Because of that the portfolio was the most tested feature I did in this website (but maybe because it had interaction in it).

Implementing the mobile version of the website was easy with the aid of React since I can just display a different component that goes well with mobile depending on the windows size and be on my way. I just set a listener that listens when the screen or window size becomes less or equal than 768 pixels. With that I set a boolean state to true or false whether it is mobile or not. I then proceeded to create mobile versions of each screen and it didn't take much time as I did in creating the desktop variant.

The last piece to finish the client side was the emailer. I searched high and low for a guide that can make this serverless since ReactJS is only a frontend library. I landed on Pantaley's guide (How to integrate Serverless contact form using Firebase Cloud functions in React) which was really easy to follow although it had a missing cherry on top which was informing the client side that the request was a success. I commented it on the blog post which was putting res.status(200).end() after all processes are done inside the Firebase function so that Axios can then execute the then() function of the promise. The guide also opened me to explore the capabilities of Firebase functions (Thanks Pantaley!). However during the deployment, we decided to move out using Gmail since it uses its proprietary domain for its email address so I had to create a new emailer using PHP in our company's server.

I also thought of creating a simple content management system (CMS) for the people owning Kindred. This would enable them to edit the content of the website easily. The CMS includes the various texts in the website, the list of team members, and uploading songs for different artists and setting which Spotify album/playlist those artists would display in the website. To store the songs, I used Firebase storage which was really easy to use due to Google's good documentation. The rest of the text and images uses the realtime database of Firebase. The images are stored in base64 string so that it doesn't consume much space in the storage.

Alas! I have reached deployment stage in a month (WOW!). I asked help from my colleagues in deploying this using Hostgator with its proprietary domain. I'm also amazed that it easily connects with Firebase hosting so I don't have to worry much in migrating. With that, the website is now alive in https://kindred.com.ph/. (website with dummy values)

My Post Project Recommendations

As a Computer Science student that researched on user interaction design or user experience, I wish I had time in inlining the design to become more usable to people.

The portfolio part of the website isn't that user friendly if you don't know how to interact with it since the artists don't look clickable.
The navigation could be somehow made easy if there is an easier way to navigate thru different screens without going back to the homepage.

There might be other interaction issues with the design that has been given to me. This could only be discovered through conducting usability testings.

React Redux could've also been a huge help in minimizing the passing of numerous properties that I had to.

My Post Project Assessment

After doing that website, I believe I've become more confident in using vanilla CSS without the use Bootstrap. I've also become more knowledgeable in JavaScript ES6 with the use of arrow functions, destructuring objects, and different array/object manipulators such as the map() function to process elements in an array in a quick fashion and the spread (...) operator to spread an object for it to be used for a component's properties or another object's properties. All in all, I learned a lot in using ReactJS and vanilla CSS while doing this project.

"Continue learning new things, it's a satisfying way to taste processes that would keep your brain busy in a good way."