RubyGems Update 1.3.5 to 1.3.6

At first, I thought that RubyGems update should be a piece of cake but it turns out that I got some weird things happened. Here’s the scenario:

[root@bpdp-arch ~]# gem update --system
Updating RubyGems

Updating rubygems-update

Successfully installed rubygems-update-1.3.6

Updating RubyGems to 1.3.6
Installing RubyGems 1.3.6
RubyGems 1.3.6 installed
=== 1.3.6 / 2010-02-17
NOTE:
http://rubygems.org is now the default source for downloading gems.
You may have sources set via ~/.gemrc, so you should replace
http://gems.rubyforge.org with http://rubygems.org
http://gems.rubyforge.org will continue to work for the forseeable future.
New features:
* `gem` commands
 * Added `gem push` and `gem owner` for interacting with modern/Gemcutter
 sources
 * `gem dep` now supports --prerelease.
 * `gem fetch` now supports --prerelease.
 * `gem server` now supports --bind.  Patch #27357 by Bruno Michel.
 * `gem rdoc` no longer overwrites built documentation.  Use --overwrite
 force rebuilding.  Patch #25982 by Akinori MUSHA.
* Captial letters are now allowed in prerelease versions.
Bug fixes:
* Development deps are no longer added to rubygems-update gem so older
 versions can update sucessfully.
* Installer bugs:
 * Prerelease gems can now depend on non-prerelease gems.
 * Development dependencies are ignored unless explicitly needed.  Bug #27608
 by Roger Pack.
* `gem` commands
 * `gem which` now fails if no paths were found.  Adapted patch #27681 by
 Caio Chassot.
 * `gem server` no longer has invalid markup.  Bug #27045 by Eric Young.
 * `gem list` and friends show both prerelease and regular gems when
 --prerelease --all is given
* Gem::Format no longer crashes on empty files.  Bug #27292 by Ian Ragsdale.
* Gem::GemPathSearcher handles nil require_paths. Patch #27334 by Roger Pack.
* Gem::RemoteFetcher no longer copies the file if it is where we want it.
 Patch #27409 by Jakub Šťastný.
Deprecation Notices:
* lib/rubygems/timer.rb has been removed.
* Gem::Dependency#version_requirements is deprecated and will be removed on or
 after August 2010.
* Bulk index update is no longer supported.
* Gem::manage_gems was removed in 1.3.3.
* Time::today was removed in 1.3.3.
------------------------------------------------------------------------------
RubyGems installed the following executables:
 /usr/lib/ruby/gems/1.9.1/gems/rubygems-update-1.3.5/bin/gem
[root@bpdp-arch ~]# logout

Piece of cake, right? Wrong. Let’s see:

[bpdp@bpdp-arch ~]$ gem env
RubyGems Environment:
 - RUBYGEMS VERSION: 1.3.5
 - RUBY VERSION: 1.9.1 (2010-01-10 patchlevel 378) [i686-linux]
 - INSTALLATION DIRECTORY: /usr/lib/ruby/gems/1.9.1
 - RUBY EXECUTABLE: /usr/bin/ruby
 - EXECUTABLE DIRECTORY: /usr/bin
 - RUBYGEMS PLATFORMS:
 - ruby
 - x86-linux
 - GEM PATHS:
 - /usr/lib/ruby/gems/1.9.1
 - /home/bpdp/.gem/ruby/1.9.1
 - GEM CONFIGURATION:
 - :update_sources => true
 - :verbose => true
 - :benchmark => false
 - :backtrace => false
 - :bulk_threshold => 1000
 - REMOTE SOURCES:
 - http://gems.rubyforge.org/
[bpdp@bpdp-arch ~]$

So, I guess I should use old-fashioned way just as explained in manual:

[root@bpdp-arch ~]# gem install rubygems-update update_rubygems
Successfully installed rubygems-update-1.3.6
ERROR:  could not find gem update_rubygems locally or in a repository
1 gem installed
Installing ri documentation for rubygems-update-1.3.6...
Updating class cache with 132 classes...
Installing RDoc documentation for rubygems-update-1.3.6...
Could not find main page README
[root@bpdp-arch ~]# gem env
RubyGems Environment:
 - RUBYGEMS VERSION: 1.3.5
 - RUBY VERSION: 1.9.1 (2010-01-10 patchlevel 378) [i686-linux]
 - INSTALLATION DIRECTORY: /usr/lib/ruby/gems/1.9.1
 - RUBY EXECUTABLE: /usr/bin/ruby
 - EXECUTABLE DIRECTORY: /usr/bin
 - RUBYGEMS PLATFORMS:
 - ruby
 - x86-linux
 - GEM PATHS:
 - /usr/lib/ruby/gems/1.9.1
 - /root/.gem/ruby/1.9.1
 - GEM CONFIGURATION:
 - :update_sources => true
 - :verbose => true
 - :benchmark => false
 - :backtrace => false
 - :bulk_threshold => 1000
 - REMOTE SOURCES:
 - http://gems.rubyforge.org/
[root@bpdp-arch ~]#

This didn’t work too. Looks like I need to manually execute the script to update RubyGems:

[root@bpdp-arch ~]# update_rubygems
RubyGems 1.3.6 installed

=== 1.3.6 / 2010-02-17

NOTE:
[ ... cut ... ]
[ ... cut ... ]
[ ... cut ... ]
------------------------------------------------------------------------------

RubyGems installed the following executables:
 /usr/bin/gem
[root@bpdp-arch ~]#

And then I am happy with the result:

[root@bpdp-arch ~]# gem env
RubyGems Environment:
 - RUBYGEMS VERSION: 1.3.6
 - RUBY VERSION: 1.9.1 (2010-01-10 patchlevel 378) [i686-linux]
 - INSTALLATION DIRECTORY: /usr/lib/ruby/gems/1.9.1
 - RUBY EXECUTABLE: /usr/bin/ruby
 - EXECUTABLE DIRECTORY: /usr/bin
 - RUBYGEMS PLATFORMS:
 - ruby
 - x86-linux
 - GEM PATHS:
 - /usr/lib/ruby/gems/1.9.1
 - /root/.gem/ruby/1.9.1
 - GEM CONFIGURATION:
 - :update_sources => true
 - :verbose => true
 - :benchmark => false
 - :backtrace => false
 - :bulk_threshold => 1000
 - REMOTE SOURCES:
 - http://rubygems.org/
[root@bpdp-arch ~]#

Read More [...]

Posted in Ruby, RubyGems

Managing a Software Development Team: Some Experiences

Managing a software development team is never an easy task. It consists of 2 sides: technical and non-technical. This task is often assigned to the project manager. To be succeed, one has to consider those 2 sides. Below are some of my experiences in managing a software development team. This list is not meant to be complete. You may need more but at least you will be in the safety line level one if you do care with these issues.

Decide the tools which will be used by the team

Well, this is a bad news if you don't have enough technical capabilities. Once you don't decide the tools, your team will be confuse as they have more than one preferences. It's not funny to have your team uses PHP with different versions, some use WAMP while the others use XAMPP or maybe PHP which comes from some Linux distros. It's not funny to have your team uses Notepad, Textpad, Vim, Netbeans, Eclipse, for their IDE/Text Editor. This will waste much time and bandwidth. Consider this, if they use different tools, then when someone says: "uh oh, my Vim always give me a tab and not some spaces, how do I turn the tab into spaces?" and then nobody can answer this and probably think "that is your responsibility, I don't care because I never use Vim". Now consider if everybody uses Netbeans (note: I don't have any relation whatsoever with Netbeans nor a Netbeans evangelist), when someone yell "How do I create a new PHP module in Netbeans?", chances are some of the guys in your team know about this.

Use a specific software development methodology, probably with some minor adaption

A software development methodology consists of process and modelling. It guides the team through the process and enable the team to model the software which is built by the team to solve client problems. It is important to use the specific methodology so that everyone in the team knows what and how to do the development. If you don't decide any methodology, then your team won't have any guides. Remember, you have to use a specific methodology but don't be too rigid. Your team may consists of people from many backgounds with many level of capabilities. For example, you may use a Unified Process methodology but because your team is limited and don't have time to learn how to use UML, then don't push them to use rigid UP methodology. The most important thing here is process. Do use that process but don't be too rigid.

Make some conventions regarding technical issues

Again, this is important to keep the team away from the state of flux and let the guys in the team communicate with the same language. You surely don't want your team to have more than one variable / property naming system, right? What if some programmers use "this_is_a_variable", while the others use "thisIsAVariable"? quite confusing, I guess. You may need to define some coding conventions and probably uses software tool to force this conventions, for example if you use Java, you may use Checkstyle.

Know the client(s) and their problems which are tried to be solved

You must understand this good enough so that you can define the scope of the problems and deal with the problems.

Decide the scope of the problems and insists on this.

Clients basically don't understand the requirements, so your duty as a project manager is to define the scope of the problems which are tried to be solved by the software. You must cooperate nicely with the client and have the information understood by all team members. From programmers' point of view, the uncertainty caused by scope uncertainty will lead to frustration. Well, I do understand that agile methodologies encourage changes, but who want to deal with changes everytime? What I am trying to say is you as a project manager should understand that changes are possible but this should be done within the scope. Don't play with programmers' heart ;)

Have a good interpersonal relationship and don't be a jerk

I know that this software development task is not easy. Clients always ask the progress and the team is in a stress condition. It really helps to just stay with the team and always willing to help them whatever you can than just act like a jerk who walks here and there and yelling. Trust me, the team will respect you more if you are always willing to help them.

Never let the team in a state of flux

Uncertainty comes everytime. Whenever the team has anything uncertain, your decision is needed to keep them stay away from confusion. You do understand that you have to have a good grasp in technical side and problem domain to make a good decision, don't you?

Let the team concentrate on technical matters

Ok, pay attention more to non technical matters so that the team can concentrate on technical side. Don't let them do any clerical things since programmers (usually) hate to do administrative things. It's good to have a dedicated person to deal with all administrative things.

Let the team member knows each other about progress and difficulties

Opennes is important. By let them know each other's progress, you keep them in a fair situation. Low salary probably can be understood, but unfair treatment can not be tolerated.

Inform the team about your progress too

So you think you can hide your progress? The team will surely want to know that you do your jobs too. If you hide your progress, they will lose respect and trust in you.

Communicate. Communicate. Communicate

I can not stress more. This is really important for the team to have them communicate each other. Your tasks will be to communicate with them and act as a liaison between the team and the client. Oh and don't forget, have a good sense of humour.

Always keep backup of everything

You don't need to backup everything if you are sure that you always live in an ideal situation. You should keep backup in more than one place. Compress them and have them uploaded anywhere on the Internet (4shared.com, rapidshare.com, /etc) as long as you have full control of your files.

Use Version Control System

Version control system is a software which can be used to track the software source code versioning. You may use git, mercurial, subversion, /etc for this purpose.

Use web based bug tracking system, project management software, and/or wiki

This will keep any information handy and on track. All any other members can also see the project's progress. It will keep each team members informed and any unfair situation can be detected.

Read More [...]

Posted in project management