Midterm self-evaluation: areas for improvement

Despite we did not have to post our midterm self-evaluation, I would like to write some lines about one of the most interesting parts of this assignment. I have never in my life done a self-evaluation for an University course, but after writing the document, I feel like it could be very helpful for both the professor and the student, because you have to go through over all your achievements, homework, assignments, things you did better or worse, etc. For this reason, I believe that the outcome is an evaluation that you can use to realize what were your strongest points, as well as your weakness, in other words, areas that need improvement.

Regarding these areas, in my case I will need to improve the following ones:

- Speaking: This is my main challenge for the rest of the semester. As an exchange student, I often have problems to understand the discussions in class as well as with my project team, but I will try to improve and put more attention. Moreover, I believe that one of the mistakes of my proposal was related to my pitch, especially in the questions time. I actually did not feel confident when I tried to give a proper answer to my classmate's questions, and this was definitely reflected to the audience in a lack of believability. From my point of view, I lost a lot of points on this part of my pitch.

- Participation: This is mostly related to the previous area. Honestly, I did not participate as frequently as I would like, but I will try to do it by increasing my participation in both meetings (client and team) and class discussions, giving my point of view every time I have the chance.

- Coding skills: I acknowledge that I do not have strong skills in programming (in general). Additionally, I had to learn new languages in order to face the Demigod project. In the mean time, I am glad with the team decision of using Ruby on Rails, but it also implies using other languages such as jQuery, Haml, CSS, etc. A lot of new things to learn in such a short time, that is the problem. Nowadays, I am doing a great effort to understand how they work, but it is not easy for me. Anyway, I am attempting to contribute to my project as much as I can, but I have to improve my skills on these programming languages.

Third client meeting reactions

Last Friday, we had our third client meeting, this time with professor Ackley. As in the previous sessions, the first part of the meeting was addressed to review the assigned tasks made by each member of the team. During the third week of the project, I was working with Natalie on the current challenge progress bar. We decided to meet together last Wednesday (two days before the client meeting) and we spent four hours trying to find a way to update the bar dynamically using jQuery when a user clicks on the "Success" button. We also made some tests to try the avatar uploading system, because we wanted that the picture was cropped if it was bigger than certain resolution. Despite having several problems, we finally got it, and we were able to obtain something that worked properly with random values, enough to be shown in the client meeting if it was needed.

In the next part of the meeting, our team needed to prove somehow that the key technology choice for Demigod project by using the Goldilocks method. In this case, we justified that Ruby on Rails was the best option to develop our website. Fortunately, it was quick and clear. Too much: Java or PHP (Great flexibility but would have taken too long to build up an entire), too little: Open Source Content Management Systems such as Wordpress, Joomla! or Drupal (easy to use, but the platform would not have been useful for creating a customized website), just right: Ruby on Rails (nice middle ground between customization and automatic generation).

Furthermore, we provide explanations about how certain parts of the application worked (progress bar, challenge selection and follow up, etc.). From my point of view, we made a mistake when professor Ackley wanted to see some of the parts of the website that was already working. We tried to run the website, but the time was limited and we finally were not able to show the model properly because of lack of preparation for this part of the meeting. Next time, we have to bring a laptop with the rails server running and all ready to be shown. Time is very important in a meeting, and we (and mostly our client) cannot afford to waste such a valuable time trying to set up the website. I hope we do not make this kind of mistakes any more.

Additionally, it seemed we were lack of confidence when Ackley asked us questions such as "What happens if you are doing a challenge and you forgot to check in?" We also turned in the final version of the timeline, as well as a list with possible challenges and the Goldilocks method outlines. Finally, following the timeline, we reported the tasks appointed to each member due the fourth week.

Gitg: Git client for Linux

In my last post, I wrote about the way to update our local repository from Bitbucket using the Ubuntu command line.I was working through the Ubuntu terminal, downloading the project from the Bitbucket's repository and I have not had any problem so far. It works fine and it is actually not  a big deal.

However, what happens when you are a Linux user and you want to upload some changes made in your computer (local repository) to the Bitbucket's repository? I made a quick research, and I quickly realized that there is a wide number of graphical Git clients for Linux. According to the reviews and opinions found on the Internet, I firstly installed Giggle, which seemed to be the most simple option. Despite you are able to view the changes that you have previously committed, you cannot either commit your changes nor pull/push operations, so I finally uninstalled it.

Gitg screenshot

Then, I tried other option recommended in several forums: Gitg. It has a design as simple as Giggle, but by using Gitg, you are able to commit changes and view the repositories with a friendly and colorful graphical display which makes easier to see all the changes. Installing Gitg on Ubuntu is really simple. You just have to run this command (you need superuser permissions):

$ sudo apt-get install gitg

The first step is to configure your online repository. This can be done through the File menu -> Repository properties, adding the URL there. To commit the changes, you need to select the "Commit" label on the top bar, which shows the files you changed on your local repository ("Unstage" box). By right clicking on each one of them (also available multiple selection), you have to click on the "Stage" option (prepare selected files finely for a commit) in the contextual menu. After this step, the files you want to commit will disappear from the "Unstage" box, passing to the "Stage" box. You can also add a commit message explaining the changes you made on the files committed. This is particularly useful to keep track of all the modifications, as well as inform and explain your teammates those changes. The last step in Gitg is to click on "Commit" button, that logically runs the commit operation.

In fact, there is only one step left. You have to push the changes in order to upload them to Bitbucket (or your preferred online repository). The easiest way to accomplished this operation is using the Terminal, but before run the appropriate command, you need to find out what is your alias (configurable by the command git config) and your branch (typically "master").

$ git push [alias] [branch]

Once you push the changes, you can check on Bitbucket if all worked fine by verifying the last commit's list.

Second team meeting: Updating repositories & redefining the timeline

Last Sunday, our team held the second meeting. It seems like the weekends are the most suitable time to meet together, because of work, class schedule, and so on.

The first task we accomplished was to update our local repositories to the last version of the project. We are using Bitbucket, a free web service for hosting projects with Git revision control systems. I did not know this application, but after two weeks working on the project, I can say that it is a very useful web tool when you are part of a work team. Despite existing a commercial version, the free account is enough to develop small projects with a limited number of team members (up to five users).

Depending on your Operating System, it is easier or harder to find a software to download and commit the changes made in the project. In my case, I am running Ubuntu 12.04 x86, and there exists some applications to do these kind of tasks. However, after checking some forums, I noticed that most of people prefer to update their local repositories using the command line. When I need to update my code with the last version hosted in Bitbucket, I take the following steps:

Open the Terminal and go to your project's root directory, then:
$ git stash -> Stashes all of your local changes temporarily.
$ git pull -> Pulls all of the source code from the repository.
$ git status -> Lists the status of the code downloaded. If the output shows files needed to be merged (which you will know because there is a section called "unmerged"), then you will need to open all of the files in that section. The changes upstream (top half) is the stuff pulled from the repository. The code under the "======" symbols is related to the changes you made, and you have to decide what part stays and what goes, deleting the rest of the code. Besides, yo need to get rid of "=====" and "<<<< >>>" stuff. After merges are fixed, you have to run:
$ git reset HEAD + the full path for each of the files you worked on as an argument. 

If you are luck and there is nothing to merge, you can skip the previous steps and write the last two commands. These are very important after a pull, just in case other team member added something to the Gemfile or a migration :

$ bundle install -> Install the dependencies specified in your local Gemfile.
$ rake db:migrate -> Download the last version of the database

Moreover, we redefined the timeline of the project (this was one of the Nikan's requests in the last client meeting), in other words, we created a more accurate and detailed version (actually, it is a Google Doc) by adding the specific tasks for each member during each one of the weeks left. Now, it is more clear, and I am quite sure about we are able to fulfill the schedule.

For the current week, I was assigned to continue working with Natalie in the progress bar module. We need to figure out how to change it dynamically when the user clicks on the "success" button. This should be done by using some jQuery function, but I have never in my life programmed jQuery, so I will need to find information and probably some tutorials on the Internet. Besides, we have to decide a pattern for the classes and id's of the style sheets (CSS) in order to follow the same format when we write code. Finally, we are going to prepare the next client meeting (this Friday), because we have to justify somehow the key technology choice (basically Ruby on Rails) made by this project.

CSS and Ruby on Rails

After a week working on Demigod project, I acknowledge that it is actually more interesting than I expected at the beginning. One of the Ruby on Rails features that I like the most was the way Haml (HTML Abstraction Markup Language) pages connect with CSS style sheets. I am used to write code in HTML, which syntax is well-known among programmers. Thus, once you want to declare a new DIV structure, and associate it with CSS styles, you should write something like this:

<div class='wrap'>
    <div class='right'>
        //HTML code
    </div>
    <div class='left'>
        //HTML code
    </div>
</div>

And create the new classes in your CSS file (let's call it: mystyle.css), for example:

.left {
    background-color: yellow;
    overflow: hidden;
    margin-top: 20px;
    width:25%;
}

.right {
    background-color: red;
    float: right;
    width: 95%;
}

Additionally, you need to specify in your HTML file thename of the CSS file (in this case: <link rel="stylesheet" type="text/css" href="mystyle.css"> . Fortunately, things are much easier with Ruby on Rails, because both the DIV and the associated class take the same identification, and the DIV tag does not need to be closed. So, the above code in HTML becomes the following one in Haml:

.wrap
   .right
    -# Haml code
  .left
    -# Haml code

Easier and cleaner! I also tested this feature using id's instead of classes (i.e. #left instead of .left in the style sheet), and it worked properly. Despite RoR uses SCSS files (Syntactically Awesome Stylesheets), the syntax is the same as the classic CSS. It only requires to set the same name to both the style sheet and the haml file where the style is utilized.Furthermore, you have to to leave the SCSS file in an specific directory:

project_name\app\assets\stylesheets\haml_page_name.css.scss

Finally, I would like to say just one general thing to take into account when programming in Ruby on Rails. In my case, more than 80% of the compilation errors came from code indentation issues. From my point of view, the easiest way to indent the code with no errors is to use always the tab key and avoid using the space key, because I quickly noticed RoR is especially indentation-sensitive.

Second client meeting reactions

Our second client meeting took place last Wednesday with Nikan. In the first part of meeting, we had to report what we had been doing since the first meeting. Each member of the team told Nikan the tasks we accomplished last days. In my case, I spent most of the time learning how to use Ruby on Rails by reading and watching some helpful tutorials. Additionally, I added some possible challenges to our "brainstorm" list, as well as prepare part of the user story second version (required by our client due to this meeting).

Next part of the meeting was to review the new version of our user story. Nikan asked several questions, especially focused on details about functionality, usability, as well as design, buttons, information displayed, screens, distribution, etc. She also asked about a global timeline for all the team members, but we only had a tentative timeline, and probably not as detailed as she wanted. For this reason, Nikan suggested to bring a new version for the next meeting.
Finally, we review the team member's tasks for the next week. I was assigned to develop the user's profile screen, and the challenge selection page, which also includes a module with the current challenge. As Natalie and I are novice in Ruby on Rails, the team decided that we work together in order to help each other, which will be definitely very helpful for both of us. Therefore, we started working on Wednesday afternoon...

Personal remarks:

- Despite our client did not ask about a story board, I think we did a great job by building one using a whiteboard. But we made a mistake because we only brought to the client meeting a picture of the story board that we displayed on a smartphone (it seemed not as serious as our client would expect) . We should have copied it, using any software, and turning in a hard copy to Nikan.

- Regarding the user story, I noticed Nikan wanted to be sure that what we were talking about would be exactly what she will have at the end of the project. The user story we turned in was quite detailed and completed, but in my opinion, we probably should have added parts of the story board to give a "graphical approach" to all the process we commented on the user story.

- We need to build a full time line for the whole project, describing the weekly tasks for each team member. I believe that the quickest way to create such a complete timeline should be to use a free software, ProjectLibre for instance. I used it on my Carpooling 505 project proposal, and it is very easy. Anyway, the idea in terms of the timeline is to focus on the application's functionality and then, once all works fine, move to the design and testing tasks.

First team meeting: Database model & story board

Last Sunday, we had our first team meeting. Two of the action items for the day were the design of the database model, and the creation of a story board for the application. The database model should include all the models, entities, relationships, as well as the fields associated to each entity. On the other hand, the story board  for the application is a detailed sequence of each screen which users are going to see when they are working with our application. Therefore, thanks to the story board, we could easily understand what we were putting, and where.

OK, that was the idea. At the beginning, we scheduled to do first the database model, and we actually started working on it using a big whiteboard provided by Matthew. When it seemed we had an acceptable model and moved to the story board, we quickly noticed that we forgot to add several entities, relations and fields on our tentative database model.

For this reason, I realized the importance of such a simple thing like a story board. To build it, it is very important that ALL the members of the team take part, because some characteristics or functionalities of each window could be overlooked. We finally got a well-detailed story board, which was also very helpful to complete the database model at the same time we added new stuff, as well as fix any previous database decisions. Apart from all I wrote so far, and based on the first team meeting experience, I would like to say two additional comments about the use of a story board when we face a new project:

1. Once the team gets an "officially" complete story board (this includes an accurate review by the team members), it may be interesting and especially useful, to share it with an outsider (several persons outside the project, if it is possible), because he/she could find mistakes or overlooked parts, even new features that nobody in the team thought before.

2. A good and accurate story board ensures an easier user story design. Our client claims for a "great user story, that absolutely will work by project completion", so if you have a great story board, you will have most of the work done to create an user story that satisfies your client expectations.

I always believe we can take advantage of our mistakes, and I will put more attention to the story board design in future software projects.