Well, it’s official- I am no longer a MakerSquare student. Open House was Thursday. Our final day of class was on Friday. We turned in our keys and walked out into the world as better, more confident developers.
My two final projects that I presented at Open House were a collaborative list-making app called Lyst (site) and a lecture communication tool that I called DiaLoggr (site). They are both deployed to Heroku (I included the links above)- please feel free to check them out and let me know what you think!
I was inspired to create DiaLoggr as a replacement for the i-clicker tool user by many universities. It allows discussion leaders to send out surveys for the participants to view and respond to, giving the leaders a better idea of where people stand in terms of understanding or interest level. It also allows for participants to submit questions to the leaders about material and receive answers. The goal is for two-way communication in lectures that encourages open, honest discussion. I used Ruby on Rails, WebSockets and Bootstrap. I also tested the models and features with RSpec and Capybara.
I spent a lot of time on these two projects over the past month- building new features, refining those features, refactoring and testing the code. It was a really good experience but I certainly had my share of frustrations along the way. One instance in particular was trying to implement Capybara as a testing tool for DiaLoggr. Previously, my only testing experience was with RSpec. In learning RSpec, I focused on testing the actual code and ensuring that the methods and routes all made the expected changes in the databases and/or took the user to the right page. Capybara, on the other hand, actually pulls up a browser window and allows you to test the user experience directly- are items appearing on the page when they should, are buttons functioning correctly, etc.
I read the documentation online and several blog posts about implementing it, and felt prepared to add it to my testing suite so I jumped in. But getting it to work was a lot more than I bargained for. I could test routes and check if links went to the right routes and the right titles were there, but the tests failed anytime I was adding elements to the page dynamically. Which was the core focus of my project. Without the ability to test that, my application would not have sufficient test coverage and would be at risk for bugs and issues as I went back and added/updated code.
I tried Googling my problem and kept running into the same solution- installing selenium webdriver and setting js to true for any tests dynamically adding elements to the page. Unfortunately, this alone didn’t solve my problem. When it started looking for new elements on the page, it stopped routing through the controller correctly and actually making changes to the database, which broke other aspects of those same tests. I was stuck.
After three days of trying and failing to get my tests to run properly, I finally ran across this Rails Cast: http://railscasts.com/episodes/257-request-specs-and-capybara. The combination of the database cleaner configuration and setting config.use_transactional_fixtures to false finally worked! My :js => true tests were functioning as expected. I was able to move on to the next feature of my application, knowing that I had good test coverage. It was a great feeling.
There were many other bugs and issues I ran into during final projects and MakerSquare. That’s what being a web developer entails- solving problems using all of the resources at your disposal. There is no greater feeling that figuring something like that out and feeling good about the result. It’s a huge motivator for me, and it’s one of many reasons I’m looking forward to a career as a web developer. The job search begins…