Who’s On Phirst

Ant, the de-facto standard build tool for Java, could be defined as a platform independent scripting tool similar to Make but with an XML syntax. Ant is mature, extensible, and relatively easy to use. These qualities paved the path for Ant to be applied to other problems besides "building software". For instance, Ant is commonly used as a scripting tool to move files around, and moreover as a test tool to launch tests and generate reports. Most Java developers already know everything I just said.

I would like to share with you another way Ant can add value to your organization, embedded Ant. It is often the case where your software needs to do tasks similar to those available in Ant. For a long while, this was a cool thought, but not a good solution in practice. It required either launching Ant in another process or studying the Ant source code so you can work through some significant issues.

However, improvements in 1.6 and 1.7 now allow Ant to be easily embedded. I first successfully embedded Ant about six months ago with version 1.6. I considered the following points before making the decision to give it a try.

• Ant is very mature.
• The wide usage of Ant implies a well tested infrastructure
• Ant tasks are cross platform
• High probability anyone who inherits this code will know Ant

My product requirements for this feature were that it:

• Must be able to fork a Java JRE on multiple OS's and run a process to completion (Windows, AIX, Linux).
• Must be able to kill or stop the process on-demand.
• Must be able to capture the standard output and standard error in real time.

Sure, I could use the Java IO and Runtime; however, when weighing the cost to write, debug, and test this code versus taking the time to figure out how to embed Ant, the decision was easy.

Here is a quick tutorial that demonstrates the concept. In practice, I use more code to make this easier. However, this shows the concept.

• Create your build.xml and package it in jar.

 

 
Hello ${to}
 

         

 

• Create an Ant Wrapper

Project project = new Project();
 
project.init();
 
project.setBasedir(workingDir);
 
DefaultLogger antLogger = new DefaultLogger();
antLogger.setErrorPrintStream(System.err);
antLogger.setOutputPrintStream(System.out);
antLogger.setMessageOutputLevel(Project.MSG_INFO);
 
project.addBuildListener(antLogger);
 
          // Load the build file
           InputStream is = MyClass.getResourceAsStream(“build.xml”);
           File tempFile = File.createTempFile();
           copy(is, tempFile);

                    ProjectHelper.getProjectHelper().
parse(project, buildFile);
 
// set properties
project.setProperty("to", "World");
 
project.executeTarget("sayHello");

A few caveats still remain:

• The project.init() is expensive. If possible, you only want to do this once per build file.
• The ProjectHelper.getProjectHelper() method does not yet take an InputStream as an argument. The source code appears to allow you to write a plugin that would support this, but I took a simple approach. I read the resource from the jar and copy it to a temp file.

In summary, Ant has proved useful as an embedded library. However, what I noticed most was that Ant not only provided a robust solution, but also enabled other features that would have otherwise not been considered.

In Embedded Ant, Ant
Comment (0) Read More...

To a non-geek, spending a weekend in hotel conference rooms listening to presentations on the latest technologies in software development might make them beg, "just shoot me now, please". But to someone interested in keeping abreast of these sorts of things, for both company and personal reasons, it was a very nice way to do just that. Plus, it was hot as hell outside, the neighborhood pool is even hot, and the lake is just too far away.

The Lone Star Symposium was held this past weekend here in Austin, and it was a great show. The lack of vendor presence at these conferences allow software developers to focus on the technology itself. The people who put this conference together go out of their way to provide all the amenities to the attendees, such as good food, snacks, not to mention some of the best industry experts out there. With regard to the experts, I am always pleased to find not only those who write about the technologies at this show, but also those who have had a hand in developing them. A case in point, the presenter for the Spring Framework was Keith Donald, one of principals and founders.

It's always a shame that you can't make it to all the sessions in this type of conference, but you generally can't go wrong with any selection. Just to sort of sum up, the hottest topics this year were the ones concerning dynamic languages, such as Groovy, and it's related framework, Grails. Also, Spring continues to be THE overarching framework for J2EE development.

My favorite session, though, was one by Neil Ford, titled "Productive Programmer: Acceleration & Automation". I am a sucker for cool command line tools, and he talked about such great productivity enhancers such as Auto-Hot Key, which allows you to define (and redefine) hot keys in Windows, and clcl, which allows you to maintain multiple clipboards. I am very keyboard-oriented, and these tools will allow me to stay away from my carpal-inducing mouse.

Next time one of these conferences makes its way near you, check it out. Especially if its a hot summer weekend!

In Spring Framework, Groovy
Comment (0) Read More...

Recently, I was entertained by hearing complaints from a friend regarding their Agile practice and how impractical and inefficient it seemed. This conversation led me to think about our own agile practices at Phurnace and other companies for which I’ve worked. It is my experience, since the Agile boom, companies tend to adopt a hybrid approach that is typically a collection of agile practices mashed up with traditional practices from which people feel comfortable. I reviewed some of the basic principles of Agile software development and found several common pitfalls.

Individuals and interactions over processes and tools

Agile projects are geared to expect change. Agile practices expect that management, sales, and product leadership frequently change project requirements. Recognizing this as a reality rather than denying it leads to a more honest and accurate approach for your organization. Thus, agile projects must explicitly abandon traditional planning in favor of direct interaction with individuals. With a clear focus on high value features and releasing valuable software often, a software team can adapt to frequent changes yet consistently deliver additional product "value”.

Traditional team management use tools such as Microsoft Project to breakdown work items that look into the project's future. Resources are allocated, dependencies are tracked, and tasks are mapped to individuals. This plan is traditionally managed by identifying the "critical path" for final delivery. Any change or diversion from the plan forces the plan to be re-worked. If the project has little variance, this approach is effective. However, most software projects change often resulting in making the project plan irrelevant.

One pitfall is that most hybrid approaches continue to use traditional tools to chart out a project plan which only confuses the leadership. These estimates are put into a Microsoft Project chart to determine which stories are feasible for the next iteration. This piece of planning, even on a smaller scale, is often out of touch with reality. The reason lies behind the estimates. A spreadsheet or Gant chart of numbers fails to communicate many of the inferences and risks that would otherwise be learned by direct interaction with the team members or the lead. In essence, given a 3-4 week timeframe, relying on your team's depth of knowledge and experience thru personal interaction is a better measure for the feasibility of tasks.

The second pitfall with this theorem is around processes. Adding unnecessary processes under the name of “Agile” is, in my experience, the most abused part of the practice. For instance, daily or frequent standup meetings are very effective for encouraging frequent collaboration and communication between your team members. However, if the traditional “weekly development meeting” is simply expanded to a “daily development meeting”, it only achieves 5 times more wasted time.

Working software over comprehensive documentation

The most important thing in a software organization is consistently creating software that provides value. Frequent collaboration with your collegagues often replaces the need for short-lived documentation. Rarely, does an internal design document or test plan add value to a product suite; while actual development or test execution can produce another valuable release.

The pitfall often found in a hybrid approach is not usually around typical documentation such as test plans for design documents. Instead, organizations adopt traditional practices such as weekly status reports and require so-called-Agile “daily” status reports. Daily status reports are just another form of comprehensive documentation leaving less time for working on software!

I am sure many people experience issues with Agile development while also seeing huge improvements over the traditional practices. I am very interested in hearing any feedback or opinions. In a follow-up blog, I plan to address the other two theorems:

Customer collaboration over contract negotiation
Responding to change over following the plan

In Agile Software Development
Comment (0) Read More...

I spent most of last week in hotter-than-the-sun Las Vegas at the HP Software Universe trade show. Here are some quick observations:
 

1. Hewlett Packard Software is all about the data center. Really. All they talk about is making data centers run more efficiently – from test to deployment to performance metrics. Up and down the stack. It was nice to see such a big company have such a singular focus. There is no confusion in the HP ranks as to what their goal is.
2. As for web application servers that attendees used, WebLogic, WebSphere and Jboss were all about equally represented. Only one attendee we talked to was on Oracle OAS. Also, very few of the WebLogic prospects we talked to were on release 9.2 or 10. Most of them were on 8.1. I would have thought more companies would have migrated up by now.
3. The HP staff was pretty awesome. Lots of engineers from HP roaming around and looking at what new technology their partners had to offer. We must have talked to 8 different engineers from the Opsware group alone that wanted to learn more about what we do – and they were just as forthcoming in helping us with the questions we had about OpsWare. (Disclosure: Phurnace is coming out with an integration to Server Automation soon – that’s one of the reasons that we were at the show).
4. Finally, the Palazzo and Venetian are pretty swank.

In Server Automation, Opsware, HP
Comment (0) Read More...

I dream of buying a dilapidated shack in Middle-Of-Nowhere, Texas. All this shack needs is a small kitchen, a BBQ Pit, a sturdy lawn chair, and a butcher’s block. I would spend the wee hours of the morning prepping brisket after brisket, chicken after chicken, coercing a steady fire into life. When the time was right, the meat would hit the pit, I would plant myself in the lawn chair, and wait. The remainder of my workday would be spent checking the heat, tending to my meaty charges, and whipping up the occasional batch of sauce. I’d close up shop at 2:00 PM or when the meat sells out, whichever comes first.

Unfortunately, this is just a dream and it doesn’t show any signs of turning into a reality any time soon. Until that happens, I have to take solace in the occasional opportunity to cook for friends and family. Phurnace had such an occasion yesterday and I jumped at the chance to spend a day fighting the smoky beast instead of testing software.

 

HOW I COOK A BRISKET:

The Rub:

• 1 cup Paprika
• ¼ cup Kosher or Fine Sea Salt
• ¼ cup Fresh Ground Pepper
• 1 tbsp Granulated Garlic
• 1 tsp Cayenne Pepper

Prepping the meat:
An untrimmed brisket is pretty fatty. I usually trim the fat down to a thickness of about ¼ inch wherever I can. Once it’s trimmed, I’ll flip it over and score the top of the brisket perpendicular to the grain. This kind of gives me a guide for cutting the brisket after it’s done. After it’s trimmed comes the seasoning. I usually coat the entire brisket with a thin layer of mustard. This gives the crust that develops during cooking a little tang and crunch and helps the rub adhere to the brisket. Sprinkle the rub liberally over all surfaces but don’t feel like you need to cram it in every little nook and cranny.

Cooking the meat:
I won’t get into how you build and maintain an indirect fire here because it differs from cooker to cooker. The most important thing to remember is you want to maintain as steady a temperature as possible. I usually shoot for a temperature of 240. Put the brisket on your cooker and add some wood chunks to the fire. I usually use oak and/or apple wood chunks. Check the fire once an hour. Add more charcoal and wood chunks as needed.

Typically the brisket will take about 1.5 hours per pound to cook at this temperature. About halfway through cooking time, I start rotating my brisket every 2 or 3 hours and basting it every hour on the hour. The baste I use is pretty simple and will make your heart explode if you drink it straight. It’s 2 cups of beef broth, a stick of butter, ¼ cup of Worcestershire, ¼ cup of lemon juice, and a couple tablespoons of leftover rub.

When’s it done? Whenever the internal temperature reaches about 160 or you can pierce it with a fork easily and it pulls out with little to no resistance. Let it sit for about a half hour and then slice it, using the score marks you made during prep time as a guide. Slicing against the grain yields the most tender results.

In Brisket, BBQ
Comment (0) Read More...

Working at a small software company like Phurnace is kind of like surfing. Well, actually, - since I have never surfed - it’s kind of like what I imagine surfing to be like. You are either on top of the world or at the bottom of the ocean, and you spend very little time in between. When Robert and I first started full time with Phurnace, I was only as good as my last meeting. If the meeting had gone well, then I was convinced that our success was all but inevitable. If the meeting went poorly, then I was crushed. Sometimes I would feel both ways in the same day - or the same hour. The ups and downs were extremely hard to deal with – and if I were to be honest, they still are.

Now, before everyone starts in on how much of an emotional weakling I am (which may indeed be the case), keep in mind that it’s not just me who has had these feelings. I have talked to a lot of people who have done similar things and feel that same way. So, either this is a common experience, or I hang out with a bunch of wimps. Take your pick.

Over the years I have found a few ways to deal with this. One is just to become numb to it and be cynical about everything. Another is to go all Mr. Spock and just try to deal with it as everything as analytically as you can. Both of those can work at times, and I’ve used them to good effect.

But you know, I think that kind of misses the point about working at a small company (and especially a software company). And that point is that it is suppose to be fun. It’s supposed to be exciting. And, while the downward plummet to the abyss can be quite terrifying, ultimately it will be those times that destruction looked the most certain but was somehow avoided that will be the most poignant, and the best remembered. The trick is to be able to enjoy the downslides as much as the upswings; to be able to laugh at both of them - whether gleefully or manically.

In Untagged 
Comment (0) Read More...

I recently read on ecogeek.org, that Apple filed for a patent for “solar cells on portable devices”. I'm a bit skeptical, but solar re-chargeability might be a nice feature for the iPod or iPhone. I still do not see sitting on the grassy bank of Barton Springs Pool with my solar powered Macbook Pro; I might exceed my own geek tolerance and be forever doomed as a “geeko freako” . However, I could put it to use at ACL Festival, for example. Given there is never a shortage of sunlight at ACL Fest, my iPhone should stay charged well into the night. Then, I might avoid wandering around aimlessly; tripping over chairs; looking for my friends because my phone died from the 100 text messages I sent during the day. It also might come in handy while traveling. Instead of worrying about whether I would actually need that tourist map I left on the steps of Gaudi’s La Sagrada Famila, I could concentrate more on the bus that is about to hit me as I attempt to cross Las Ramblas staring at my zoomed in map on my phone. I guess it might have a bad side, Austin, TX has a lot of sunny days and the ole “Honey, I didn’t get your call because my cell phone died” excuse might not work during the summer. Anyway, the more I think about this solar powered Apple gadget, the closer I get to a nerdnirvana!

In Untagged 
Comment (0) Read More...

Beginning in the 90’s, American software companies began farming out development work to companies overseas, or "off-shoring". These efforts mirrored what had been taking place for quite some time in other industries, such as textile manufacturing, and sent tremors through the software community. The heady days of the dot-com boom gave way to fear and gnashing of teeth in the early part of this decade. CEO’s were pictured riding astride elephants in India, and executives were predicting that soon all non-design development work would take place off-shore. Would there be any jobs left for American software developers?

Now entering the latter part of this first decade of the 21st century, the software development community state-side finds itself in what appears to be a better situation, jobs-wise. What happened? Why did the gloom-and-doom scenarios not play out?

A couple of realities have become apparent as the decade has played itself out. First, globalization of software development has actually worked against itself, as the cost of doing business in countries like India has increased to the point where the cost savings benefit is in question. Software developers are able to demand more money there, as the need for them has increased.

But secondly, and I believe just as importantly, companies seeking to off-shore their development made critical mistakes in choosing the products that they would send overseas. The products they chose were mostly mainstream, legacy products, which tend to be, by their sheer longevity, much more complex and intricate. From my experience in this business, I have found that "old" does not equal "simple". In fact, just the opposite is true. This software has generally been developed over the years by hundreds of developers, all with different programming styles, and do not always follow textbook patterns. Asking primarily inexperienced developers to maintain or enhance these products without day-to-day guidance from at least a few senior developers is tough. Couple this fact with the risk of losing market share for these products (oh yeah, they’re probably still profitable, why else would development continue?), and you have a recipe for disaster.

What seems like such a great idea when discussed at cocktail parties 8 years ago, should now be one that should be considered with at least some trepidation.

In Untagged 
Comment (0) Read More...

A long time ago, I was on a NOLS adventure in the middle of the Olympic mountains. My group was resting one day high above the tree-line in a snow covered area when we found a small, but steep bank of snow ... perfect for headfirst nosedives. It all seemed harmless at the time, until our guide angrily reminded us that whatever choices we make, the fact remains, we must weigh the risk versus the reward. Shocked at first by his reaction, we all suddenly had the realization that given our surroundings and circumstances, the risk we were taking was much greater than the reward.

This article about Twitter recently reiterated to me some real risks with Ruby on Rails. Whether or not Twitter is abandoning Ruby on Rails, the risk of a severely flawed framework remains.

Ruby on Rails is a language and platform that makes web application development quicker and more maintainable. One of its strength is that the Rails Framework enforces consistency in style and encourages code reuse. Past that, Ruby as a language is just another language. Rails is an innovative framework, but it is only a framework. Many arguments are made regarding the technicalities of Ruby and other languages.

I do not wish to rehash these arguments; but instead, I make an assertion that by choosing the Ruby on Rails platform in an "Enterprise" environment, your organization is taking unnecessary risks considering its surroundings.

For the last two years or so I noticed a new wave of energy surrounding Ruby on Rails. I encountered some very strong proponents of Ruby on Rails who wanted to use it in an Enterprise setting -- I always had one simple concern:

Ruby on Rails is a two tiered platform; thus, fundamentally flawed. A Ruby on Rails application is doomed to scalability issues. So while it may be fun implementing a web application using a new innovative platform, it will not be fun when your company is finally on the verge of success only to discover it has a severely under-performing application on a platform that provides few options to scale. Twitter anyone?

Now, consider the recent support that companies such as IBM have put behind a long time leading web application language, PHP. By leveraging PHP, a developer can now overcome many of the "ease-of-development" drawbacks of developing a traditional multi-tiered Java based web application, but still have the facilities of a highly scalable application server environment such as WebSphere XD.

Much like sledding down a hill, creating a simple web application using Ruby on Rails has its advantages. However, when you consider the surroundings of an Enterprise Environment, it is hard to consider any situation that Rails is worth the risk.

In Twitter, Ruby on Rails, PHP
Comment (4) Read More...

As a software developer, maintaining concentration is something that requires discipline, and sometimes the aid of a good set of headphones, and some music.  While this usually does the trick, I find that familiar music can be its own distraction, since I find myself jumping to some memory that the song brings back.  In addition to this, transporting CDs back and forth from home to work is a pain.

For these, and other reasons, I've looked for alternative listening sources, and one I've found very enjoyable are the Internet radio channels streamed at Soma FM.  This full-time, Internet-only station began as a pirate radio broadcast at the Burning Man festival in 1999, and now streams 16 different channels.  My personal favorites are Groove Salad, which plays music in the Ambient genre, and indie pop rocks!, playing new and old tunes.  In listening to these two channels, I've discovered a lot of new music (which is harder to do the older I get), but at the same time, I find that I'm able to keep my focus on my development work, since I'm not as familiar with the bands.

If you're looking for some really great music to work by, check them out.  I think you'll find some great music which just requires an Internet connection to enjoy.

In Untagged 
Comment (0) Read More...