vijava not working with vSphere 6? Try YAVIJAVA instead!

If you are using vijava 5.x stable or beta release and you are ready to move on to vSphere 6 then find your InventoryNavigator is giving you problems and your code isnt working as expected anymore give yavijava a try. I fixed an issue with the InventoryNavigator class that is part of 5.5.10-DEVELOPMENT and newer releases of YAVIJAVA. Since 6.0 went GA today I will be pushing 5.5.10 to public maven this weekend.

Im currently working on adding all the new ManagedObjects and DataObjects that are part of 6.0 to YAVIJAVA and should have an official 6.0 release in a couple of weeks. If you want to help out with those efforts or just follow the development feel free to tune into this branch on GitHub where I am pushing all of the vSphere 6 code before it gets merged into the primary release branch.

How to contribute to an opensource project like a boss

So you found a cool project online and its opensource and now you want to give some of your time and efforts back to the community, but you dont know where to start. This blog post should help get you started and help you get your code accepted on just about any project out there.

The first step you should take is to read the documentation that comes with the project. A great place to start is often the README in the project. Generally you will find all kinds of info in this file. Some of that information may be code standards, where to find help, TODO lists, or just general project guide lines.

Next get familiar with the tools used in the project. This could mean having to learn to use a new revision control system such as git with a focus on using it via github or bitbucket. Many projects have some special requirements when it comes to their source code. You do not have to be a master with these tools, but you should at least understand how to do some basic tasks with them. For example, with projects using git and github you should understand forking, branching, fetching, merging, pushing, and most importantly pull requests. Its OK to ask for help getting these things done, and you can generally find where to get that help in the README.

Next it may be helpful for you to look at the rest of the code in the project, or at least some of it. I know this may be a lot of work because some projects are so large. Maybe you don’t need to see every line of every piece of code but it will help to look at some of it to get an idea of how the rest of the code is written so that you do not camelCase where the rest of the project uses underscore_syntax.

Next you should be open to community feedback. Opensource development generally speaking works differently than what you may be used to doing at work. Most projects I have worked on have some kind of peer review system where community members and projects owners will look at your code and make sure it meets the code standards, and has logic in it that is easy to follow and makes sense. These reviewers may ask you to make changes, but don’t take it personally. This feedback should not be taken as a personal attack. Remember you are going to donate this code and you may never come back again, so it will be up to other community members and project owners to maintain it. You may be doing this on your free time, but odds are that so are some if not all of the other people reviewing your code. Generally speaking no one will ask you to make changes to your code that they wouldn’t expect of their own code.

On the topic of changes no one is forcing you to make these changes. Generally speaking it is just an ask. If you don’t want to make the changes kindly tell the reviewers something like “Im sorry I am not interested in making these changes, please feel free to take my code if you can”. Most projects would rather have working code that needs to be “reformatted” than have nothing while others may not be interested in your code if you don’t make the changes.

Finally and this may seem very obvious but try to write good, well documented, clean code that is easy to follow and understand. I have been doing this for almost 15 years now and I have never run into some code where I said “Damn this documentation is way too good, and there is just way too much of it”, and I am willing to bet I never will. Often it is the opposite of that and I am cussing as I read through line by line trying to figure out how or why something is the way it is.

If you follow these steps, or suggestions as they really are, it should help the process be very smooth and pain free for all parties involved. If you have any suggestions about things that I should add to this list please feel free to let me know. I would love your feedback. I hope this blog post will be helpful to someone out there who is thinking about getting into working on opensource projects.

Building Fluxbox GIT on Ubuntu 10 and adding it to GDM

Many of you may recall from the past that this site used to be ALL about FluxBox my focus now is more on general Linux usage. I do however still use Fluxbox. Something I thought I would talk about is how to add Fluxbox to GDM and what it takes to build Fluxbox GIT on Ubuntu. This process should also work on Debian as well.

The first thing you will need to do is install some dependencies. The best way to do that is using the following commands:
apt-get install build-essential
Next you need to install some stuff specific to Fluxbox, the easy way to do that is like this:
apt-get build-dep fluxbox
Next you need to either grab a source tarball of git, or install git using the following command:
apt-get install git

You should now have everything you need to build the latest version of Fluxbox on your machine. Lets pull the code and build it. As a normal user and with out using sudo:
git clone git://git.fluxbox.org/fluxbox.git && cd fluxbox && ./autogen.sh
Once this completes successfully it will be time to configure the build options. Since you may be doing this just to test out the latest version and may still want to have the primary version installed via apt-get Im going to suggest configuring with the following options:
./configure --prefix=/usr/local && make && sudo make install
This will place the files that fluxbox git version installs into the /usr/local directory. Now fluxbox is installed and all you need to do is manually create a fluxbox.desktop file so that GDM will know about.

To make the fluxbox.desktop all you need to do is open your favorite text editor and create a file that looks like this:

[Desktop Entry]
Encoding=UTF-8
Name=Fluxbox-git
Comment=Highly configurable low resource X11 Window Manager
Exec=/usr/local/bin/startfluxbox
Terminal=False
TryExec=/usr/local/bin/startfluxbox
Type=Application

Next save this file in /usr/share/xsessions/ and name it fluxbox-git.desktop

You may need to restart X for the Fluxbox-git entry to show up for you to select, but thats it!! You should now have Ubuntu with Fluxbox Git installed. Enjoy!!