Wednesday, March 5, 2014

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.

No comments:

Post a Comment