Building Flexodoro
Lessons From My First Web Application
At the end of LS 175, I embarked on the most challenging and rewarding experience that I have had at Launch School so far; creating my own Sinatra based web application. After viewing several impressive projects submitted by other students, I decided to build a tool that I had been wanting for some time: a flexible Pomodoro time tracker.
The ensuing project tested my problem solving skills, Ruby fluency, and object oriented design intuition. In addition, it required comfort with the Sinatra framework and familiarity with the HTTP request-response cycle. But most importantly, it highlighted my weaknesses and taught me many valuable lessons about writing an application from scratch.
Lesson #1: What seems simple, is not.
I started the project by making a simple outline of the app’s functionality followed by a more complex outline of the server side logic that would enable that functionality. I began to code and was amazed how quickly my first web application was coming together. But as the program grew, so did the complexity, and the ensuing problems became much more tangled and challenging.
One button, for example, originally called on one function. But by the end, it was much more complex, calling on up to eight functions, some of which called on many other functions.
Lesson # 2: Writing tests is not fun.
As I wrote the program, I wrote tests for each new feature which was typically more challenging than creating the feature itself. With each test, forward progress seemingly halted as I was forced to painfully scrutinize and refactor my code.
Lesson 3#: Writing tests is good for your program.
As much as I dreaded writing tests, I began to realize the value of writing them. A good test demands clean code and many times, I was forced to clean up my code in order to write a decent test for it. Once the tests were written, they saved me tons of time. Rather than manually testing my app by clicking around, I could test its entirety with one command.
Lesson #4: It’s just a series of small problems.
In the end, writing this web app was just a series of problems, each with its own set of unique challenges. After many days, hundreds of lines of code, dozens of tests, and countless bugs CRUSHED, the app worked. Routes handled HTTP requests, view templates displayed the appropriate information for each route, and dozens of methods handled all of the application logic. The app had all of the planned features: sign in , sign up, a flexible Pomodoro time tracker, and a time tracker log that used YAML files for data storage.
Lesson #5: When you have a full app and a full test suite, its really hard to just switch it over to a different programming paradigm.
After finishing the first version of the app, I decided to go for an extra challenge and modify it to use an object oriented design. It would make the app less tangled, and all of the unanticipated methods would be encapsulated in classes where they couldn’t attack other parts of my program.
I tried to add classes and objects to my program and I couldn’t figure out how to do it without severely breaking the whole thing. So, I looked at code for other student’s projects. I was impressed and humbled by their amazing quality, but I still couldn’t figure out how to add classes and object to my program without breaking it.
So, I built Flexodoro from the ground up, again. This time, it took on an Object Oriented Design with recycled code from V1.
Lesson #6: Use debugging tools.
The complexity added by classes in external files unleashed a swarm of tricky bugs that I was not well suited to solve. At one point, I actually chased a ghost bug (a bug that didn’t exist). With more simple programs, I always knew where the bug was coming from and I could just ‘puts’ values until I figured out what exactly was causing the bug. Now, it was much harder to tell where the bug was and the application was way too complex for ‘putsing’ values.
I learned, the hard way, to really read the stack trace and figure out exactly where the bug was coming from. Then, I learned to expertly use pry to check values and see exactly what was causing the bug.
Lesson #7: An object oriented design makes future changes much easier.
Recreating Flexodoro with classes and objects proved to be even more challenging than creating the original version. The new design increased complexity with a whole new set of possible design choices and tradeoffs. But it was worth it. It pushed me to the limits of my knowledge, to the edge of my comfort zone. Now, the program is stronger for it.
After version one, the application was fragile, just waiting to break with the first new line of code. But with the object oriented design, I have been able to easily add features without breaking the whole app.
Lesson #8: Figure out what you don’t know, then learn it.
One of the great parts of this project has been realizing the shortcomings of my skillset that will be solved by learning more technologies. It’s a common Launch School teaching tactic: let a student feel the pain associated with a certain problem and then reveal the technology that was built to help solve that problem.
Flexodoro is live and you can check it out here. I plan to continue adding features (and styling) as my skillset grows.