Code Bytes

Flipping through iFlipd’s Development

By November 2, 2016 No Comments

“iFlipd is a web application that allows you to rent books or textbooks on a weekly basis for as low as $2 per book, per week. But they aren’t just a Rent-All shop for students. iFlipd is also a library, campus bookstore and and a scholarship program. They want students to instantly have access to the books they need, when they need them. iFlipd also allows you to “flip” books back to the community, share study notes, and stay social — just like school. And you earn rewards for doing it!”

 

At the beginning

At first glance, when their old developer introduced this project to the team, the application appeared quite simple. Later we learned just how complex it really was. It was built on a single page application using VanillaJS, HTML and CSS. That’s a single page application with a single HTML, Javascript and CSS file on it and, of course, a thousand lines of code in there in each file.

Since the application was built with old web technologies and the old way of implementing code or structure architecture (let’s say it’s a procedural way), we did a lots of code refactors, tweaks and manual fixes. These were for the responsiveness of the application user interface to be able to fit small devices.

When we added new features to it to extend the functionality of the existing modules, the application became more complex and lost maintainability. These issues might slow down the application’s performance. So the team asked to rebuild the application from scratch and to use new tools and framework. We also proposed a new development cycle for the application using the Agile methodology with Scrum.

The team introduced JIRA software for the development cycle and project management of the application, as well as EmberJS framework for the frontend and bootstrap 3 for the CSS framework that would make the application fit any device. We also used Strongloop, a NodeJS framework intended for the server side of the application. We all know that there’s a lot of new javascripts framework/libraries now, but the good MVC structure, a convention over configuration type of framework, is the reason why the team chose EmberJS over AngularJS and ReactJS.

 

Trial by fire through Ember

During the rebuild process, Ember looked to be a great solution for development. The team set a shorter timeframe for it because it seemed that the functionalities and other requirements for the application were already there in the old application.

As a beginner of the said framework, however, I felt lost in the world of Ember. I knew Ember and Ember-Data were very powerful. The documentation showed how easy it was to use. Unfortunately this wasn’t so for all scenarios of the application. Multiple times I was stuck because things didn’t go as I expected. Ember didn’t do things the way I thought it would. (This isn’t to make Ember look bad. It’s most probably my lack of experience with the framework that was making it difficult for me.) I considered this as a roadblock that might delay the delivery of things that needed to be done early due to our shorter timeframe.

I realized that I could be the reason for the delay of the rebuild, so I researched further about it, doubled my time in studying during weekends. Learning the so-called “Ember Way” and the internal designs of their structure architecture was a great help in understanding and implementing certain tasks. Ember is a little rough for beginners like me, but it is powerful. When I understood more about this framework, the team and I continued to develop and add more features to the application faster than before.

Enough talk about Ember, though, let’s continue. 🙂

 

Scrum time!

We have had daily standup meetings with the client for updates. During our sprint planning, we’ve discussed specific criteria of the issue or tasks and estimated story points per tasks in our poker planning sessions. Through this technique, both the client and the dev team could now easily track, organize and manage the project’s concerns during the development process. We could also prioritize and discuss specific issues that needed to be done first including bug fixes and minor copy changes.

Our process improved team performance on delivering tasks on the said deadline based on the story points set during poker planning sessions. The team also has an experienced Quality Analyst who tracks and reports bugs during the test process, which we can address immediately.

We’re continuing with the application’s development and enjoying the process, doing some minor bug fixes and adding more features to it. The application is now up and running and it continues to acquire more users, helping more students save money on books.

Rexon De los Reyes

Author Rexon De los Reyes

More posts by Rexon De los Reyes