Technistas

Matthew D. Laudato writes about software and technology

Archive for the ‘software development’ Category

A Framework for Evaluating Continuous Integration Tools

leave a comment »

For those of you interested in the methodology behind my ongoing series on CI tools, you should check out a new article that I wrote for CMCrossroads. In it I provide a framework for evaluating CI tools, and give you a checklist and ranking system to help you organize and rate your evalution.

The 2nd installment of the hands-on tool evaluation is a few days away – stay tuned for how the four tools (Hudson, Mojo, Bamboo and TeamCity) fare on providing access to common development tools and on enabling you to assemble complex build workflows.

Happy Building!

– Matt

Written by Matthew D. Laudato

June 16, 2010 at 6:36 pm

Continuous Build Automation with Subversion and Meister

with one comment

I recently got a chance to work on a project using Collabnet Subversion and OpenMake Meister and put together a short demo on how to get the two tools to work together doing continuous integration. You can view it at http://www.openmakesoftware.com/flashdemo/Meister-SVN/omsvn_small/omsvn_small.html

Meister like most CI tools has several ways to kick off a CI build. You can do a scheduled build, or you can poll the SCM system. The third way of doing a CI build is to call the build from a Subversion hook. In the demo I show two of these methods: a scheduled build in Meister, and calling Meister from the Subversion post commit hook.

The setup is pretty simple. I have a repository in Subversion that has working copies for developers, and what I’ll call a ‘hands off’ working copy that only the build process uses (meaning, no developers are ever in that copy making changes. It receives changes strictly through a ‘svn update’ command run by the CI process). In Meister, I have a workflow that knows how to build a small DOS application from some code in the repository.

In the demo, I first show Meister running a build on a schedule. Meister updates the ‘hands off’ working copy and then compiles and links the code. In the second case, I turn off the scheduler, and instead activate the post commit hook in the Subversion repository. The hook code calls the Meister command line, which looks like this:

 

java -cp c:\openmake-meister\client\bin\omcmdline.jar com.openmake.cmdline.Main
-BUILD "WINDOWS BUILD WITH SVN"

 

The same workflow runs in both cases. The advantage of running from the hook is that you are always guaranteed that every transaction in Subversion gets built. On the other hand, setting a scheduler to run every hour is easy and might be more appropriate for shops with less frequent code changes. In both cases Meister is driving the build with its dependency analysis engine, so the builds are fast and highly parallelized.

Overall it was pretty easy both to get the Subversion repository configured, and to get the Meister workflow up and running. The Meister command line lets you do things like set environment variables (not shown above), so you can control the workflow at a fine level of detail.

Happy Building!
– Matt

Written by Matthew D. Laudato

January 22, 2010 at 7:59 pm

Practical Salesforce Programming

with 3 comments

As most of my readers know, I like to write about work-related items – a webinar I’m hosting, a review of an article that is relevant to my day-to-day work in the software business, or some such thing. But every now and then I need to remind myself of what got me into this business in the first place – a sheer love of figuring out how to program something.

Last week, the something was Salesforce.com, the leading customer relations management software product on the web. We use Salesforce at the company I work for (OpenMake Software, Inc.) to help track how we communicate with customers and prospects. One of the cool things that Salesforce lets you do is to send out an email to a large list – no, not spam, but legitimate communications to people who have agreed to hear from you. As anyone who has tried to send out a mass mailing knows, all email lists are dirty – meaning, there are addresses on the list that are no longer valid and that result in a bounced email. So my task was to figure out a way to programatically set the email ‘opt out’ bit on the associated record in Salesforce.

Salesforce has an excellent web services API that gives you complete access to the underlying data model. I decided to tackle the problem using my favorite Swiss-army bazooka, Perl, along with a Perl module that I found on the internet called ‘Salesforce’. Once I installed the Salesforce module, the code was pretty easy to write.

The program assumes that you have a text file that contains a list of the email addresses that have bounced, separated by a newline character. Here’s the code:

use Salesforce;
use Getopt::Long;

# Gather command line parms
my ($user, $password, $bounceFileName, $update);
my $result = GetOptions ("user=s" => \$user,
			"password=s" => \$password,
			"bounceFileName=s" => \$bounceFileName,
			"update" => \$update);

# Set up the SOAP service and login
my $service = new Salesforce::SforceService();
my $sf = $service->get_port_binding('Soap');
my $login_ok = $sf->login('username' => $user, 'password' => $password);
die "Bad login" unless $login_ok;
print "Login OK";

# Loop through the bounce file and process each bounced email address
open (BOUNCE, $bounceFileName) || die "Can't open file: $bounceFileName";
while (<BOUNCE>) {

	# Get the lead from SF
	chomp($_);
	my $leadEmail = $_;
	print "\nProcessing lead email: $leadEmail ";
	my $result = $sf->query('query' => "select id, hasoptedoutofemail from
                                             lead where email='$leadEmail'",
                                             'limit' => '1');
	my $leadID = $result->result->{'records'}->{'Id'}[0];
	my $hasOptedOut = $result->result->{'records'}->{'HasOptedOutOfEmail'};
	print "Lead id is: $leadID. Opt out status is: $hasOptedOut\n";

	if ($update) {
		my $lead = $result->result->{'records'};
		$lead->{'Id'} = "$leadID";
		$lead->{'HasOptedOutOfEmail'} = 'true';

		my $updateresult = $sf->update(%$lead);
		my $updreshash = $updateresult->result;
		print "Update status: $updreshash->{success}\n";
	}
}
close (BOUNCE);

1;

 

As you can see, the code is pretty simple. In the initial block, we use the standard getopt functionality to get the name of the bounce file, along with the Salesforce userid and password. One comment about the password, you need to append your Salesforce security token to your standard Salesforce password – this is a standard technique in Salesforce and in many other cloud computing environments. We also set an ‘update’ flag – if it is set, we will not only query the database for the existence of a bounced email record, but we will also attempt to update the opt out bit.

The next block sets up the Salesforce SOAP service and binds to it. Once this is done, you are ready to make queries and update the Salesforce database. Salesforce uses the SOQL query language to interact with its database. In the code, we first open up and then iterate over the bounce file. Each time through the loop, we perform a query to pull the record associated with the bounced email address from the Salesforce database. If the update flag is set, we then prepare the record (as a Perl hash) for update and use the ‘update’ method to push the change to Salesforce.

I found working with the Salesforce API to be fairly straightforward. The only hard part was figuring out the exact format of the records that come back from Salesforce – in some earlier versions of the code, I just used Data::Dumper to peek inside the SOAP envelopes to determine the structure. All in all, it was a few hours of learning the API and the data formats, with the end result being a functional and useful piece of code.

Hope this helps, and happy coding!

– Matt

Written by Matthew D. Laudato

December 9, 2009 at 3:43 pm

Speedy Java builds slow down productivity

with 2 comments

I never cease to be amazed at how software development management ignores the build problem. In a recent article in SDTimes, Alex Handy reports on a survey undertaken by RedMonk that found Java developers spend nearly 8 minutes per hour doing software builds. In round numbers, that’s an hour a day, 5 hours a week, and for a typical 48 week year, nearly 30 work days every year. Let me repeat that. Your Java developers, who are presumably paid $80-120k per year, are spending 30 days per year staring at their screens waiting for builds. If we take the middle of this range, this is a productivity loss of over $12,000 per year per developer. For a small 5-10 person team, you could hire an extra developer just with the savings from improving your build process.

The article goes on to say that Java developers “have learned to build smaller portions of their projects at a time, or to compile small pieces of code and inject them into running applications”. I’m trying to think of two worse practices in professional software development. If you build a smaller portion of your project, you risk having unsatisfied dependencies, and thus wasting time when your runtime fails to operate properly. Similarly, injecting code into a running application is dangerous even in a test environment for similar reasons – you haven’t spent any time understanding the dependencies, and therefore are at risk of dependency-related failures.

As my readers know, I work for a software company (OpenMake Software) that sells a software build and workflow automation product. We have tens of thousands of Java developers using our product through our Eclipse plugin, which gives you true incremental builds that take dependencies into account. You can build, test and do a test deploy all from within Eclipse, and not have to resort to trickery such as injecting partial code into your test server. Since the cost of Meister (which I am not at liberty to publish here) is significantly less per developer than the annual productivity loss calculated above, it makes sense for development managers to move their Java developers away from the wild west of desktop builds, and consider a formal build system. Anything less and you’re ignoring one of your primary missions as a manager: controlling the development process.

Happy Building!

– Matt

Written by Matthew D. Laudato

December 3, 2009 at 8:27 pm

A Tale of Four Builds

with 2 comments

After a long break from blogging, I’m back. I’d like to invite all my viewers to a webinar that I’m hosting on Wednesday October 21, 2pm EST. The webinar is titled ‘A Tale of Four Builds’. In it I take a single piece of code and build it using four different build technologies. This survey of build methodologies moves from manual, error-prone processes to highly controlled and repeatable processes. If you’re a software engineer, development manager or build and tools manager, this webinar will help you sort out the pros and cons of the various build technologies that are common in today’s software environment.

Hope to see you there. To register, go to: https://www1.gotomeeting.com/register/554771256

Written by Matthew D. Laudato

October 16, 2009 at 1:09 pm

People, Process and Product

leave a comment »

Yesterday I had lunch with an old friend and colleague who like me, is between jobs. After talking about the kids and the family, the conversation turned to shop talk, which for my friend and I is the software business. Both of us are experienced managers, in my case having led teams anywhere from 4 to 45 persons, and for my friend, organizations upwards of 200 developers. What emerged from the conversation was our common view that the single most important thing that a manager can do to ensure a successful software product is to hire and train the right people.

Now, this may seem obvious, but there are managers out there who for whatever reason believe that the development process is the most important factor in team and product success. That you can take mediocre talent, insert it into a formal process, and have superior code emerge from the other end. At the risk of starting a flame war between the process-centric and people-centric folks out there, let’s examine the single equation that rules the software industry: People + Process = Product.

If you walk into a development shop and ask about process, chances are you will get a different answer from everyone you speak with. Managers will often fire off a list of “things that we do” and pass it off as process. Engineers on the other hand, tend to chuckle, smirk and give you a more direct answer, usually something like “I look at my list of defects and features and then write code to resolve them”. If asked about the details of the process, you will get as many different answers as there are team members. This is my first point: your process more likely than not, isn’t what you think it is.

Now, go and ask the same development team about people, and I suspect you will hear a different story: Joe is the best algorithm guy I’ve ever worked with. Jane can step up to unfamiliar code, grok it instantly, and fix nasty bugs quickly. Bob writes useful unit tests. This is my second point: the team knows intuitively who does what best, and if pressed, why those roles are critical to the success of the team.

When asked to come in and fix a troubled team, my friend doesn’t inquire directly about the process when interviewing the team. Rather he asks: what’s working around here? Usually there are 3 or 4 things that the team does well, that can and should be used as the basis of a new process. The interviews also tend to give him a sense of who the top talent is, and who the laggards are. This sets the stage for shifting people into the most effective roles, and adjusting the process – in that order. Similarly, when I have been asked to build a team from scratch, process is the last thing I think of. The first thing is hiring and training top talent. Once there is a critical mass of developers (usually at least 4), a funny thing happens. The developers, if they are truly top-notch, will start to self-organize and suggest a process. At this stage, I step in and help the team put some formalism around the process so that we can measure our progress, and the race is on.

To sum it up:
1. Your process is what your engineers actually do, not what you’ve written up on paper.
2. Great engineers deliver great products.
3. Process is a guideline to keep the greatness wheels turning.
4. If a team is underperforming, focus on your people first, then fix the process.

If you’re managing a large organization or a complex set of deliverables, there’s no question that your development process is important – it needs to be scalable, easy to measure, and non-obtrusive. But, as anyone who has watched the 0-14 Detroit Lions lately knows, without talent in all key positions, no amount of process can produce magic and turn a sow’s ear into a software silk purse.

Written by Matthew D. Laudato

December 17, 2008 at 2:15 pm

Developing in streams, releasing from streams

leave a comment »

Here’s a link to yet another post I did for AccuRev. It’s a critique of some so-called best practices around branching. Eventually every developer will realize that branches are old and dead, so here’s my small contribution to that end.

Developing in streams, releasing from streams

Written by Matthew D. Laudato

December 14, 2008 at 4:02 pm