How to Create a Text File List of RGB Values in C

Here is a very simple C program for generating RGB values listed in a text file:

#include <stdio.h>

int main() {

  FILE *fp;
  fp = fopen("true_colour.txt", "w");

  int r = 255;
  int g = 255;
  int b = 255;

  for (r = 255; r >= 0; r--) {
    for (g = 255; g >= 0; g--) {
      for (b = 255; b >= 0; b--) {
        fprintf(fp, "%d", r);
        fprintf(fp, ",");
        fprintf(fp, "%d", g);
        fprintf(fp, ",");
        fprintf(fp, "%d", b);
        fprintf(fp, "\n");
      }
    }
  }

  fclose(fp);
  return 0;

}

C source available at http://gist.github.com/mikequentel/e32acc62b3ae5e330558
Also available in Ada at http://gist.github.com/mikequentel/6bfc40638ca4a789f8e2
and Nim at http://gist.github.com/mikequentel/d74507a6c3738869150b

Moving Sharepoint (MOSS) from One Server to Another

Lots of information exists on the internet concerning how to backup, restore, and move Microsoft Office Sharepoint Server (MOSS). Here, I will refer to this simply as "Sharepoint". Many developers (including myself) have wondered, "what is the easiest way to fully backup and restore, and even in the process, move, Sharepoint?"...so here an easy way to do a full backup of one Sharepoint server, then restore to another Sharepoint server...

Sharepoint backup from original (source) server:

C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\BIN>stsadm -o backup -url http://mysourceserver:80/ -filename C:\sharepoint_backups\myoriginalsharepointinstance.bak


Sharepoint restore to another (destination) server:

C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\BIN>stsadm -o restore -url http://mydestinationserver/ -overwrite -filename C:\sharepoint_backups\myoriginalsharepointinstance.bak


Using Ant to Automate Version Control Operations and Software Metrics

Like many developers, I use Ant to build and deploy software. Through the years, I have grown an inordinate fondness for Ant, and I have enjoyed finding ways to automate all sorts of processes in the software development life cycle.

Here, I would like to show some examples of using Ant to interact with a version control system, and to also collect software metrics.

For version control, many of us use Subversion to maintain our software repositories, and essentially, manage our intellectual property. One of the challenges in concurrently developing a system, on a team, is keeping in sync with the latest (or some particular) revision of the software. Ant can help in this endeavour.

Here, I show how Ant can be used to do an svn update on the local copy of code. I use this Ant target to ensure that I have the latest updates to the code I am working with; this target acts as a kind of continuous integration tool on Agile projects. So, introducing the Ant svnupdate target...

In the build.properties, add


# SVN Client Home -- where svn client can be found.
# eg: svnclient.home=C:/cygwin/bin/svn.exe
# or
# svnclient.home=/usr/bin/svn
svnclient.home=C:/cygwin/bin/svn.exe


Then, in the build.xml, include


<!-- Svnupdate Target -->
<target name="svnupdate" description="Updates code source to HEAD.">
<exec executable="${svnclient.home}">
<arg line='"update"'/>
</exec>
</target>


To do an svn update on your local copy, then simply use the svnupdate target, like this:


ant svnupdate


I typically combine it with the whole build, so that it is called just before the other targets.

Also, you can use Ant to create a README file based on information in the repository. To do this, add this target to the build.xml file:


<!-- Svninfo Target -->
<target name="svninfo"
description="Gets Subversion data about this local copy.">
<exec executable="${svnclient.home}" output="README">
<arg line='"info"'/>
</exec>
</target>


This would be run as:


ant svninfo


It outputs a README file that can also, using Ant, be inserted into the final deployment (eg: a WAR file or JAR file).

Ant can also call software that performs metrics. One such software, StatSVN, does an excellent job of generating statistics and charts representing the metrics of a build. Here is an example of using Ant to call StatSVN...

In build.properties:


# StatSVN parameters.
# See http://www.statsvn.org/
lib.statsvn=statsvn.jar
svn.log=svn.log
statsvn.outputdir=statsvn


In build.xml:


<!-- Statsvn Target -->
<target name="statsvn" description="Runs statsvn.jar on the local copy.">
<mkdir dir="${statsvn.outputdir}"/>
<exec executable="${svnclient.home}" output="${svn.log}">
<arg line='"log"'/>
<arg line='"--xml"'/>
<arg line='"-v"'/>
</exec>
<java jar="${lib.statsvn}" fork="true" failonerror="true" classpath=".;${lib.statsvn}">
<arg line="${svn.log}"/>
<arg line="."/>
<arg line="-output-dir"/>
<arg line="${statsvn.outputdir}"/>
</java>
</target>


This would be run as:


ant statsvn


Solaris 9 on Ubuntu!

Today, I successfully installed Solaris 9 (x86) guest operating system on Ubuntu 9.10 (Karmic Koala) host operating system. I used VMware Player to virtualise the Solaris 9 OS.

I had bought the Solaris 9 media back around 2003, and have been waiting for the right time to install the software on a spare computer (so I have been thinking, for years). But thanks to VMware Player, installing Solaris 9 and other interesting operating systems is now much easier than ever.

To do this install, I followed the directions from VMware on Solaris 9 guest OS: http://pubs.vmware.com/guestnotes/wwhelp/wwhimpl/common/html/wwhelp.htm?context=guestnotes&file=guestos_solaris9.html

Here are the results (I know, the display settings need some work)...

Management of Software Projects: General Guidelines

Over the years I have been fortunate (and unfortunate) to have worked under a variety of project managers. Additionally, I have performed the roles of a technical lead and a project manager.

Here, I do not go into the finer aspects of management of a software project, but rather, emphasise the human element of leadership. In fact, the best book on leadership I have ever read is Steel My Soldier's Hearts, by Colonel David H. Hackworth (and his wife, Elihys England). This book definitely demonstrates how to lead, and has lessons that can be applied to any leadership position.



This post is not a summary of Hack's ideas (read the book--it's fantastic); but his work inspired some of the bullets below.

When in a leadership position, whether it be as a technical lead or project manager (or both), it is best to follow these guidelines:

• Lead by example and lead from the front. You should be able to jump in and help with the actual work, if needed. You do not need to know all aspects of the domain of a problem, or how to do everything with a given framework, API, or language, but you should be able to function as an actual member of the development team. Because of all this, you should have the same IDE, build tools, version control client, developer system accounts, etc, as the rest of the development team. Be on top of what is being done--attempt to do builds of each iteration. Make sure that you monitor what goes into source control (either by watching the logs or by receiving email updates).
• Appear serious most of the time. Especially in the beginning, when people are just starting to get to know you. Having a serious, intense look, but not angry or nervous-looking, will help people to take you seriously. Then, later on, if you smile or laugh at a joke, they will feel pleased that you have a "fun" side, too. But if you are smiley and happy from the start, they might not take you so seriously. A lot of leadership involves good showmanship.
• Be friendly, but do not fraternise. Whilst being serious most of the time, you can still be friendly, just do not try to be close friends with your subordinates. Avoid going out drinking with them. Do not appear to be friendlier to one over another.
• Do not assume that most tasks can be simply broken down into smaller subtasks in the form of steps. Some managers make this mistake in thinking that everything is done sequentially, and can be put into clearly defined steps. Some complex problems instead require parallel efforts and re-iterative techniques.
• Take care of EVERY individual on your team. Make sure everyone has all the tools they need to get the job done. Make sure everyone has a functioning workstation and functioning accounts. Also, make sure everyone has equal access to equally good tools. If you have something someone needs, and you do not require it yourself, be willing to swap theirs with yours. For example, if your subordinate has a problematic monitor, and the company has none available to replace the monitor, then swap the monitor with your own. You should be like the general with shiny new boots who swaps his boots with the corporal who has worn-out boots with holes. Make sure everyone has an adequately comfortable work environment. Pay attention to every individual's complaints. Just because the rest of the team may not be complaining, does not mean that it's just one person with a problem; many are reluctant to speak up. So at EVERY meeting, ask everyone if they have what they need--do they need any extra tools to get the job done; are their workstations functioning adequately.
• Treat every individual on the team with dignity. Treat everyone as you would want to be treated. Never ridicule, insult, or shout at anyone. Do not be condescending. Never suggest or imply to an individual that they "might be better doing something else, like [fill in the blank with a role that is lesser than the person's title]". If they are unhappy, it might very well be because you are not giving them suitable opportunities.
• Use POSITIVE reinforcement and praise your subordinates FREQUENTLY. As an owner of several canines over the years, I have learned a lot about positive reinforcement. Workers are like dogs who love to be praised. You can get them to leap through hoops if you give them encouragement. Then, when they are being difficult, you can surprise them with a very stern voice and get their attention.
• Never show favouritism. Do not take only certain subordinates out to lunch, or only invite select individuals to sit with at lunch. Also, if you do take the whole team out for a meal, make sure you attempt to accommodate the dietary restrictions of the individuals (some cannot enjoy alcohol, or eat anything that simply was cooked on the same surface as an "unclean" food). Do not ignore the fact that one team member might have lesser tools than another; make sure that the poorer one is brought up to the same level of toolsets.
• Teach whatever needs to be taught, and more. Any good leader must be a teacher, too. You should be able to show anyone on the team how to do what must be done, or at least point them in the right direction. The managers or leads that say things like "I don't want to have to babysit" so-and-so; or, "I shouldn't have to spoon-feed" so-and-so, are fools that have no business occupying a leadership position. If you do not know how to teach the topic that needs teaching, you should at the very least link up the individual with someone who can show them the way. EVERY manager should be a good teacher. If you refuse to do this, then you should get out of IT project management.
• Do not let anyone on your team just fail. That is, do not let them drown if they are struggling. Do not have the attitude of "sink or swim". If someone is failing, and yet they are trying to give a good and honest effort, then you need to show them the right way to get the job done. If anyone should have to stay late or come in on a weekend, it is the project manager--the manager was supposed to ensure that the tasks could be accomplished within normal business days (8 hours of work per business day, in most of North America).
• Get rid of cubicle walls, if at all possible. Few things are as irritating as hearing someone near you, but not being able to see them. People should feel comfortable and confident about approaching other members of their team.
• Avoid crass or disgusting habits. Such as: sitting on other's desks, using your saliva to clean off your keyboard, flossing at your desk, picking at your toes, etc. Practise good hygiene.

Diagram of Skills: Perfect for IT Interviews

In addition to the typical CV/résumé for an IT interview, it might be helpful to the prospective employer to see a concise page displaying the candidate's skills. Because many of us who have been in the IT field for several years have very long lists of programming languages, frameworks, tools, IDEs, APIs, etc, that we have worked with, it might be helpful to break out the skills into separate categories. Better yet, instead of just listing them on a page, why not make a diagram? Here is a simple example:



Such a diagram can be saved to a PDF, then emailed to prospective employers or distributed at interviews.