Client Meeting Reaction

Overview

The client meeting with Dave was a real eye opener. It put into perspective that we still have quite a ways to go in terms of our application. I was a little disappoint in myself for not being more prepared for it. Part of the issue I feel was that I was focusing a lot more on the back end stuff and getting the core functionality finished without paying enough attention to the user experience. I do understand that user experience is of central importance to this project, however, I suppose I was expecting the meeting to be focused more on action items that we had planned on presenting. Dave pointed out several issues concerning our application and while I wasn't thrilled with his overall reaction, he made several valid points. The one that hit home the hardest was the flow of the website. We essential have no flow as he pointed out which is a real issue. We can't expect to create a successful application if there is no rhyme or reason behind the navigation. If the application isn't easy for a user to understand and follow, there is little chance they will come back and use it again. Based on this, I have a plan that will hopefully help in creating a more natural flow of actions that will hopefully improve the usability of the application.

Improvements

The first thing I will be doing is going back to some of the websites that track carbon emissions to try and understand better how the user is prompted for information and also understand the general layout. I will take note of my personal preferences for certain behaviors and flows and see if these things can be applied in some way to our application. I am hoping that by going back to the research phase with an emphasis on user experience, that next meeting will be more successful in terms of presenting an application that a user will actually want to use.

Conclusion

The client meeting helped me understand some of the short comings that our application has and where it needs improvements. Dave did say that he felt that we had a lot of pieces which was a nice positive and he is correct in that aspect. We are lacking in the user experience area though which is no good and I feel partially responsible as the application proposer because I should have had a more concrete understanding of how I wanted the user to navigate the site. I focused more on the back end and it hurt this client meeting. I am confident though that I will be able to make some concrete deciscions that will turn our app around and make it a better experience for users.

Guest Speaker Reaction

Introduction 

On Monday, Dave had a guest speaker come in. Jeff VanDyke, founder of VanDyke software and UNM alumni spoke about various aspects of the software development industry as they are practice by his company. Topics like, development methodology and business model were address during his topic. He also answered questions posed by the class and by Dave. His company uses extreme programming for implementing features. He also mention after class when I was asking him questions that they do emphasis testing code however they do not spend too much time dedicated specifically to writing tests for trivial functionality. He also mentioned that ideas are fleshed out in advance although formal specifications are not used. I thought the use of extreme programming and the lack of formal specifications were important enough that I am going to do a "define, defend, attack" analysis of them in how they relate..

Extreme programming: 

Define

An agile development strategy that emphasis short burst of feature implementation known as sprints. The idea is that this development technique is more adaptive to changing client demands.

Defend

Being a CS undergrad seems to breed agile developers. It feels that we are always on the grind and always having to be highly adaptive to our situation based on the work load our professors put on us. This has been especially true of this class the client meetings can be good or bad depending on what kind of demo we have.

Attack

This method of development  has been serving our team well in some respects, and if it used in industry, I imagine it will serve us well in the future. The disadvantage is that I imagine most of us are use to at least a semi formal specification of what needs to be achieved which we don't really have for this project. I have tried my best to define the scope of the project and a specification of features to be implemented however this model has had to adapt based on client meetings so it has been hard finding a balance.

Accomplishments over Spring break

Over Spring break, the main focus of development was on getting as much of the back end built as possible, at least for me. My main focus was on allowing users to enter data into a form that  contains fields dependent on equations defined by an administrator. The focus was on this mainly because most of the overall functionality we are suppose to be delivering for the final demonstration hinges on us being able to receive and store user input persistently so that it can be user for things like gamification features and awards as well as the dynamic charting.

This was no easy task for me as I was and still am learning Ruby and Rails, so some of the conventions have only just started to set in after having fixed some of the bugs encountered in this process. The main challenge was getting formatted parameters to the server from a user. There are still some input validation issues that need to be address all of the calculation functionality is now working the way it should. Another issue Justine and I ran into while trying to integrate the dynamic charting in with the user statistics was attempting to do math on equations that no longer existed. Our database was polluted and so debugging that took a couple hours. Part of the problem was that it only occurred in the deployment environment and so we had to go sifting through the log file to figure out exactly what was going on.

Fortunately, we were able to get these issues resolved. Because of this, the more fun features we have proposed like awards and ranking will now be fairly easy to implement. We did take a bit of a hit in terms of the user experience as was ABUNDANTLY pointed out in the client meeting this week (which will be another blog post in its own right.)

On the plus side, we will now be free to focus almost exclusively on user experience so I am confident we will have something worth our efforts by the final demonstration.

Design Pattern: Active Record

Introduction

Active Record is a design pattern often used to as a means to access information stored in relational databases. Rails explicitly implements a class called ActiveRecord which models this design pattern. This ties back into the Rails idea of Convention over Configuration because Rails exposes its models as classes with methods that allow easy manipulation and access of data fields within a give database table.

Pro

This allows the model to implement behavior that the controller and view shouldn't be bothered with in a clean and scaleable way.

Con

This design pattern might not work well for non-relational databases like MongoDB. However, I do not have any experience with how MongoDB stores and interacts with its data types/ objects so this may not be a valid con to include.

Rails Challenges

Introduction

The past three weeks of development have presented many interesting obstacles that have require creative thinking in order to overcome the challenges. One of the obstacles I have faced is understanding the Rails convention on naming things and how this effects Rails behavior. Understanding the underlying Rails architecture has also been challenging to understand.

Rails naming convention and architecture

Rails aims at a framework that is geared towards development rather than the configuration of the underlying architecture required in order to successfully deploy a web application. Something referred to in Rails references often is "Convention over Configuration." This applies to many aspects of rails including the way things are name within programs. Specifically, when a user requests a web page, Rails uses it's routing infrastructure to determine where to send a user when a given URL is requested. These URL's generally, refer to specific actions in the Controller class of the rails framework. The controller does whatever it needs to which is generally creating instance variables of the various Models that will be used in the View of the web application. This view corresponds to one of the actions in the Controller and so their names correspond.

Conclussion

Rails is indeed a powerful framework for developing dynamic web content. In general, it does most of the heavy lifting in terms of generating a raw skeleton to work with. This, in theory, allows the developer to worry about higher level features and functionality rather than configuring Apache servers etc. The disadvantage to go the Rails way is that it can be potentially slow going in the early stages because of the learning curve associated with learning Rails convention and architecture.