Who’s On Phirst

Official blog of Phurnace Software.

Archive >> April 2008

Posted by: Daniel Nelson on

About a month ago I had a conversation with the President of a professional services firm about what was more important to succeed in the market: a good product or a good sales team. Since his background was sales, and mine was in building products, you can probably guess which sides we fell on. The conversation turned into one of those Star Wars vs. Star Trek debates where neither of us could move the other, and we just agreed to disagree.

Which is all well and good, but I have found myself thinking about that conversation on and off since then, and I am now ready to change my mind. Not that I suddenly agree that a good sales force is more important than a good product. But I think both sides miss the point.

The most important thing for success in the market is the customer pain. It won’t matter if you have a great product and a great sales force if the problem you are targeting isn’t really painful to your customer.

A good sales force can sell a mediocre product to a customer if the customer’s pain is big enough, and the reverse of that is true as well. The pain is the key.

So, how do you go about finding that out? Well, two things. First, start with an industry that you know and have worked in for awhile. That will be your divining rod that will point you in the general direction of what is painful enough to develop a product around.

Second, you have to get out there and ask. When Robert and I started Phurnace we talked to more than 100 individual Java professionals (devs, sys admins, architects, etc.). All that we asked them was what was painful about their jobs day to day. And what they told us was that deploying and configuring their applications was really, really painful. That’s when we decided to build some software to help them out.

We didn’t stop asking about the pain, though. We kept following it as we were building the product, going back to those people we had talked to as well as our early customers and ask them what features they wanted and how they wanted them to look and act. We still do that. Every feature we add has to have a customer story behind it which makes it a lot easier to figure out what to put into each iteration.

If you are planning on starting your own company or looking for an idea for a product, there is a great book by a former software exec, VC, and now professor named Rob Adams that I recommend. (Full disclosure: Rob is a friend and on the Board of Directors of Phurnace). The book is called A Good Hard Kick in the Ass. It’s got some great advice on just the kind of market validation I’m talking about.

In customer
Comment (0) Read More...


Posted by: Larry Warnock on

I just read a blog by Aziz Gilani about “Enterprise 2.0” and his take on how enterprises will respond to the web 2.0 technologies and it’s new approaches. I think it was quite insightful and I agree with him when he comments on some of the basic assumptions by Forrester Group. Aziz writes "Having spent the past 8 years either working with CIOs or within the enterprise I can honestly say that no company will come out and say something along the lines of 'I really need some Web 2.0 in here. Where is my checkbook?' They are more likely to unwittingly stumble into Web 2.0 technology based on improvements to their end to end processes". He is dead on. Web 2.0 is not a defined category like CRM or ERP was and there isn’t one monolithic vendor pushing the concept. It is a bottom-up trend with hundreds of vendors (including free open source tools) that are making it all possible.

He also goes on to mention that configuration of the ever-expanding list of applications will continue to be a huge challenge. Again, dead on. We here at Phurnace see that every day as we talk to customers and prospects. The IT ops and software development tools today talk about “configuration and deployments”, but more often than not, they state “place current deployment process here”. That is the PROBLEM. The current process used by Global 2000 companies is error-prone, cumbersome and often laden with scripts that are fragile or in constant need of attention.

Web 2.0 and Enterprise 2.0 are here indeed, but don’t lose sight of the plumbing. Deployment and configuration management should remain top of mind. Because aren’t we sort of at “Infrastructure 4.0” and it still isn’t simple?

-Larry Warnock

In Web 2.0DeploymentConfiguration
Comment (0) Read More...


Posted by: Robert Reeves on

When you buy a software tool for your use, you aren’t just buying the application; you are buying the BENEFITS of what it does. Most often, you are really buying piano recitals, little league games and happy hours with your friends. You buy yourself time when you buy a good tool. Because with the right tools, you are in bed, fast asleep, instead of the datacenter at 3 a.m. pulling out your hair because of a deployment error or a server that won’t capture transactions, or whatever. With good system administration tools you get to tackle the hard problems and challenges that made you take your job in the first place instead of the mundane, boring and error-prone tasks.

Unfortunately, “quality of life” has never been a valuable selling point for IT managers and directors. They pay you to keep the network running, deploy applications and configure application servers. The manner in which you perform your job doesn’t matter to them; only the results.

If you aren’t using the right tools, then a huge proportion of your production failures are due to configuration errors. Thus, your entire management team should care about how you perform your job, just like you do.

Simply put, proving a fast ROI is the best way to make a business case for a software purchase and it is terribly simple. ROI, or Return On Investment, is a simple calculation that states the rate offered by an investment. So, if you invest $1000 that provides you a return of $500 per year, then you have a 50% ROI per year ($500/$1000 = 50% ROI). In other words, the “pay back” period for the investment is 2 years ($500 per year, for 2 years = $1000). The rule of thumb in IT spending is that investments need to have a “pay back” of 3 years or less. So to invest $1000, you need to show that you will get more than $333 back per year.

With many tools (could be OpsWare, Build Forge, Phurnace Deliver …), you are provided with a way to avoid costly mistakes and down time. But, determining the dollar amount of those mistakes and downtime can be difficult. Luckily, many vendors (us included) provide an online calculator to help determine those values. And, when you are done filling out the web form, you can create a PDF of your cost analysis to email to your boss.

Recently, one or our customers determined their deployment costs to be $68,365.38 per year and the cost of error resolution was $171,000 per year. That’s a total cost of $239,365.38 per year. To determine their ROI, they simply divided the money saved by our product’s cost. They arrived at a monster 3 digit ROI number and were very happy with their purchase.

Of course, you can always rely on your friendly local software sales rep (like the Phurnace Account Manager) to help you with the purchase process. We all want you to be successful and tackle the truly challenging aspects of your job. So, leave the mundane, boring error-prone stuff to the tool vendors.

In deliver
Comment (0) Read More...


Posted by: Larry Warnock on

 I’ve been in the enterprise software industry for more years than I would like to admit, although my staff never misses an opportunity to ask “seemingly interested” questions about punch cards, 8 inch diskettes, and what it was like when developers used Pascal. I have witnessed many mind blowing advances in technology, process improvements and creativity. What doesn’t seem to change however, are the fundamentals of growing a company and running a good business.

Granted, many times through the last 24 years, people have claimed and tried to declare “a new model”, one where profits didn’t matter, customer service was to come later, the practice of spending on dreams vs. reality, and betting exclusively on the 1 in 1 million break through that will change the world we live in. Don’t get me wrong -- I love those life changing things – but they ARE 1 in 1 million. For the day in, day out, building of a great company; one that will make their customers always happy and provide value in exchange for dollars – the basics have stayed the same. Regardless of the “wild anomalies” that occasionally appear (remember when the market thought Touthpaste.com would have us all brushing online).

I interact often with investors, venture capitalists, engineers, suppliers, attorneys, salespeople, marketers, customers, industry analysts and the media. They are a diverse bunch and I tend to gravitate towards the optimists vs. the pessimists, but I will say that a common trait seems to be the desire to find “the new, new, new thing”. Not just the new, new thing. That is so 90’s. I am an out-of-the box thinker, as those that know me, can attest. However, some things SHOULDN’T be the new, new, new thing. Things like a) respect for your customers, b) respect for your employees, c) making tough decisions quickly, and d) leading a team vs. administrating a team. These four things are the foundation, in my opinion, of how great companies are built and run. I know, I know, a dude wrote a whole book titled “Good to Great”. It was a study of the habits and traits that were common amongst good companies that became great companies. It is a good read, but I believe that if the basic tenets that I mention aren’t followed, the rest just can’t happen. There, I saved you $24.75. Not really, you should check it out. But if you do, also read “Blue Ocean Strategy”. A good read that discusses changing existing markets. But, I will say again, without the foundation of the four basic tenets, it simply doesn’t matter.

So, if you are starting a business, running a company, or even in charge of a team, remember: 1) respect your customers, 2) respect your employees, 3) make tough decisions quickly, and 4) lead, don’t just administer. It has always been that way, always will. Wow, a Déjà vu moment – again.

In Untagged 
Comment (0) Read More...


Posted by: Robert Reeves on

BBC has a news report on how boring tasks can lead to errors and omissions. Evidently, your brain will go into 'autopilot' mode when performing redundant, boring tasks. Apparently, there is a specific bit of brain activity that can occur right before you are about to make a mistake.

Your Brain on Phurnace

Until they can make a portable MRI for data centers that will catch that brain activity, may we suggest Phurnace Deliver to simply get rid of your dull and boring tasks along with your errors?

In Tipsphurnacejavadeliver
Comment (0) Read More...


Posted by: Shawn Spiars on

As a software engineer I often find it entertaining reading the technology job postings. You can learn a lot about a company's values and culture by what they reveal in their job postings. I once had a job interview with a VP of Engineering who was bragging to me during the interview about how much money he saved his company by sending half of his development positions offshore. So I am thinking to myself "if I take this job just how long until my position goes offshore"?

One of my biggest pet peeves is with the postings that say "Entry Level Programmer" and then go on to list detailed requirements that would take 10 to 15 years of experience to accumulate. This type of posting tells me that the company is really cheap and doesn't want to pay for the experience that is required for the position.

Then there are the companies that think they are doing you a big favor by allowing you to Join their world-class team because they are so much smarter than everyone else in the industry. They only hire engineers with advanced degrees and certifications and take great pride in Their superior intellect. A few years ago I had a short stint at one of these companies with "All Chiefs and no Indians". These folks were so smart that it took them over 2 years to get a software release out the door. They just kept arguing about how to do things better and better, and ended up rewriting the same Code over and over again until they ran out of money.

One of the things I like most about working at Phurnace is the "No Punks Allowed" philosophy as Robert likes to phrase it. "No Punks Allowed" basically means we look for people who are mature in how they perform their work and in how they relate to others. It also refers to the notion of egos in check, and a willingness to constructively share ideas and have ideas shared with you. After all it's the quality and character of the people that you work with that makes a job enjoyable or not. So, if you are a developer and you are trying to decide on your next gig, just remember - "No Punks Allowed."

Shawn

In java
Comment (1) Read More...


Posted by: Daniel Nelson on

Just got back from IBM IMPACT 2008 show

3 things I learned about WebSphere customers:

Last week Jessica (our Marketing Manager) and I spent about 4 days doing booth duty at a conference, IMPACT 2008. I thought I would share 3 quick impressions that I got from the show, the people there, and what companies where showing off. Two quick caveats: first, since I was only talking to people who went to IMPACT, my impressions should probably not be fully extrapolated to a state of the general market; second, I was talking primarily to people who either stopped at the Phurnace booth or were hanging out at the same bars as me – so there may be some selection bias.

  1. WebSphere is SO main-stream. It’s everywhere. No one industry dominates. Everyone is using WAS, and its add-on products. I knew that there were lots of folks using Portal, but what surprised me was the number of people I talked to who were currently using Process Server or were planning to. Personally, I thought adoption would be slower than that. But lots of companies seem to be embracing it.
  2. There were tons of consultants. Everyone from GBS, to Perficient, Accenture, CSC, CapGemini, etc., etc., etc. Sure, they were prospecting for customers just like I was, and I get that, but doesn’t that say something about the industry that the thing we are there to see/learn/discuss is so complex that about a third of the people I talked to where consultants?
  3. There were some small companies doing some pretty cool things (and not just Phurnace). For example, the people right next to us was Clear App (a competitor of CA’s Wiley) who had some interesting stuff on performance monitoring of Portal apps. And I met Michael Dag, a solo owner of a company called MQSystems. He has an interesting tool for the modeling of MQ configs and object relationships. Start-ups and early stage companies are alive and well. And they are driven by some interesting innovation.

So that’s my quick three: WebSphere -- it’s everywhere, lots of people want you to pay them to help you with it, and there is some real innovation happening in start-up land. Oh, and next year I am not staying at the Tropicana Hotel. But that’s a whole different topic.

In WebSphere
Comment (0) Read More...


Posted by: Pete Pickerill on

Why buy the cow? Open Source QA Tools can provide a sturdy test and automation framework.

I’ve spent the bulk of my career in QA at startups so I’m not accustomed to operating with an abundance of resources. As such, I’ve researched a ton of free and open source testing tools in the hopes of automating or streamlining the test process to compensate for a lack of manpower. I’ve decided to use my blog posts to detail some of the tools that I have found useful over the years.

At my last job, we built our test lab by cruising Goodwill stores in search of donated systems capable of running Windows 98, NT or 2K with a minimum of upgrades. While our experiences in creating this “Franken-lab” made for a few good stories, we often spent more time dealing with hardware outages and the quirky behavior common in donated technology than we did testing. At the time disk space, memory, and powerful processors were expensive. Even if we were to buy mid-range systems we’d have quickly exhausted our budget. Without enough hardware to cover all of our supported platforms, we’d have had to rely on disk imaging, a process that includes a lot of downtime while one system configuration is being blown away and another written to disk.

VMWare has changed all of this. At Phurnace, my test lab consists of one system with 8GB of RAM, 2 quad-core processors, and a terabyte of disk space. I can run up to about 10 Virtual Machines concurrently so I can use one as my client test platform, use several more to create clustered WebSphere or WebLogic environments to test against, and have a few virtual machines to spare for developers to troubleshoot defects or test code before checking it in.

Benefits of the Virtualized Test Lab:

  • Installation of VMWare Server and Virtual Machine creation couldn’t be easier.
  • Quickly shift gears. If I get blocked while testing one platform, I can power down those servers and bring up another set of server images in a few minutes without leaving my chair.
  • Snapshots! VMWare also allows me to start from a known good base state every time I power on a virtual machine so I know that ‘pollution’ on my test bed will be minimal.
  • A basic CLI that allows you to start and stop VMWare images remotely. This has been very handy for test automation
  • A library of virtual appliances, some offered for free, that provide pre-installed and configured enterprise applications. I have just started investigating some of these to manage the virtual network my virtual machines are connected too.
  • Lots of available help is just a good Googlin’ away. VMWare is very widely used.
  • Free! Gratis! On the house! VMWare Server is a free offering that is intended to familiarize users with virtualization. While they have several support subscriptions and product upgrades available at a price, this free offering has more than met our needs.

So check it out here . I recommend it highly.

In Virtualization
Comment (0) Read More...


Posted by: Wesley Willard on

While Robert Reeves is correct in his assessment that scripting can be evil, especially in cases where scalable and durable automation is needed (like deployments of apps),there are occasions where a script can definitely serve as a useful problem-solving tool. A script can act as another way to view an application's data, allowing the developer to verify the state of the data independently. Creating a script does not generally require the same amount of time to code/compile/edit as a regular programming language, thus can be more quickly developed in an iterative fashion. Also, since scripting languages are not used as often to create commercial applications as are programming languages like Java, a script can be used to prototype some experimental functionality, without danger that the prototype will escape the building.

I have resisted taking the time to learn much about the many scripting languages which have been created in the last few years, but Groovy is one which, as a Java developer, has really caught my eye. It is built on Java, but provides additional features which have been inspired by other languages such as Ruby and Objective-C.

I find Groovy to be my current scripting language of choice for a few simple reasons:

  • Java-like syntax is extremely easy to pick up
  • Ability to leverage the many powerful Java APIs
  • Useful built-in features like Categories, which enable dynamic extension of any class

In the following code, I’ll demonstrate some of these things. I will be making a remote connection to a JBoss Application Server in order to retrieve MBean attributes, as well as invoke operations on the MBean.

First, I will import some classes, and make a connection to the server:


package com.groovy

import javax.management.ObjectName
import javax.management.MBeanServerConnection
import javax.naming.InitialContext
import org.apache.xpath.XPathAPI
import groovy.xml.dom.DOMCategory
import org.w3c.dom.Element

def
password = ""
def initialContextFactory = "org.jboss.security.jndi.
JndiLoginInitialContextFactory"
def JMX_INVOKER_RMI_ADAPTOR = "jmx/invoker/RMIAdaptor"
def port = 1099
def host = "localhost"
def username = ""
def password = ""
def initialContextFactory = "org.jboss.security.jndi.
JndiLoginInitialContextFactory"

//
// Connect to JBoss
//
Properties props = new Properties(System.getProperties())
props.put("java.naming.factory.initial", initialContextFactory)
props.put("java.naming.provider.url", host + ":" + port)
props.put("java.naming.security.principal", username)
props.put("java.naming.security.credentials", password)
def ctx = new InitialContext(props)
Object obj = ctx.lookup(JMX_INVOKER_RMI_ADAPTOR)
def mbsc = (MBeanServerConnection) obj
ctx.close()

Once I have made my connection, I will then use it to invoke an operation on a JBoss MBean.


//
// Create a class to be used as a String Category
// StringCategory extends the String class with
// a new method that splits a String at the newline delimiter
//
class MyStringCategory {
public static List splitOnNewLine(String string) {
return string.tokenize("\n")
}
}
//
// Invoke the operation listDeployedURLs on the Groovy MBean
// Use the category defined above to split up the return string
//
use (MyStringCategory) {
def deploymentScanner =
new GroovyMBean(mbsc, "jboss.deployment:flavor=URL,
type=DeploymentScanner")
def deployedURLs = deploymentScanner.listDeployedURLs()
def deployedList = deployedURLs.splitOnNewLine()
deployedList.each( { println it } )
}

This snippet illustrates a couple of interesting Groovy features. The class MyStringCategory is an example of a Groovy Category. A Category in Groovy is a class which defines methods which can extend any specified class. In the example, the method splitOnNewLine is a category method on the Groovy class String, due to the fact that the method is static, and the first argument (or target) is of type String. This method can be called on any instance of a String, and will return a List containing one entry per new line found in the String. To enable the category method to be called, the call must be enclosed in a use statement, which references the name of the category.

Also notice that I have created an instance of a GroovyMBean, constructing it using the server connection and the name of the JBoss MBean. The GroovyMBean is a built-in Groovy class, which allows an MBean to be used as a regular Groovy object. I use this object to call the listDeployedURLs() method on the JBoss MBean, which returns a String representation of the currently deployed URLs on the server. I then use my splitOnNewLine() category method to create a List, which can then be iterated.

The next snippet of code illustrates how easy it is to make use of an existing Java API within Groovy.

 


//
// Create GroovyMBean to retrieve the JBoss Mail Service
// configuration information, which is returned by JBoss
// as an XML Element object
//
def mailBean = new GroovyMBean(mbsc, "jboss:service=Mail")
def configurationXML = mailBean.Configuration

//
// Use the Apache XPath API to select the nodes,
// and iterate through them with a closure
//
def nodeList = XPathAPI.selectNodeList(configurationXML,
"//property[@name]")
def printNode = { println it.getAttribute("name") + "=" +
it.getAttribute("value")
nodeList.each(printNode)

After the creation of another GroovyMBean, the Apache XPath API is used to select the nodes in the returned XML Element. The resulting NodeList is then iterated. Using an existing Java API in this fashion is just as simple as importing the appropriate class, and then calling its methods.

The final part of this example uses another category, MyDOMCategory, in conjunction with a built-in Groovy category, DOMCategory, to process the same XML Element. The call to list() is a category method which transforms a NodeList object into a List object. The List object is iterated, and its attributes are retrieved using the Element category method attribute(Element node, String attrName) to retrieve the name and value attributes.

 


//
// The class MyDOMCategory extends the Element class
// to return the value for the specified attribute
//
class MyDOMCategory {
static String attribute(Element node, String attrName) {
return node.attributes[attrName]
}
}

//
// Use Groovy Categories to iterate through the NodeList
//
use (DOMCategory, MyDOMCategory) {
configurationXML."property".list().each(
{ println "MyDOMCategory: " + it.attribute("name") + "="
+ it.attribute("value") } )
}

Hopefully, these short snippets of code illustrate the simplicity that I think makes Groovy a very attractive option for scripting use in the Java development world. I would highly recommend it as a useful addition to your software developer's toolkit.

In ScriptsScripting LanguageGroovy
Comment (0) Read More...


Posted by: Robert Reeves on

In the first part of this two part post, I discussed how scripts are terrible at eliminating errors. In fact, scripts simply replace typos with system errors. A rather poor trade-off, I think.

The second problem with scripts is the burden they place on employees to maintain them and the decrease in productivity they can cause. This maintenance burden and productivity sinkhole are the two areas scripts were supposed to fix!

Frankly, I hold the tools architecture responsible. Scripts conflate the Data with the Mechanism because of the enforced procedural nature of the tools (think wsadmin). Please note that I don't mean to pick on WebSphere, but I just have a *ton* of experience with that application server. I could have just easily singled out WebLogic, OAS, JBoss or Glassfish. The architecture problem is common to them all.

To see an example of conflation, navigate to your WAS 6.1 directory and look at samples\bin\PlantsByWebSphere\install.jacl. You will see the following:

  createJ2CResourceAdapter $nodeName $serverName

That's a good start as both resources are provided at the command line when executing the script. However, the script immediately falls apart on the next directive:

  #--------------------------------------------------------------------

  # Setup security cell

  #--------------------------------------------------------------------

  set secAuthAlias "$cellName/samples"

  set secDescript  "JAAS Alias for WebSphere Samples"

  set secUserID    "samples"

  set secPassword  "$samplepwName"

  createJAASAuthenticationAlias $cellName $secAuthAlias $secDescript $secUserID $secPassword

Don't see it the problem? I don't blame you. The problem is a hardcoded secUserId. This will fail if there is another JAASAuthData that uses the same secUserId as "samples". Now, that's a simple mistake; but it's one that will require a very specific use case to find it. So, we have actually created a maintenance headache for ourselves. This script may save me time in my Dev or QA environments. But, once it gets to Production where they use entirely different usernames for the database, I will have an error I simply cannot afford to have.

But, finding the specific JAASAuthData configuration problem is just the first headache. In my Production environment, imagine that this script fails on the duplicate secUserId value. Well, that's easy to fix, right. Let's just add another argument to pass in when the script is run.

So, I'm only into the second call of my script, and already I'm required to make the script more complicated. Furthermore, since my script is not wrapped in a transaction, I'll have to manually delete the J2CResourceAdapter to completely roll back. Or, at least, I *think* that's all I need to roll back my script's changes. After all, the best thing that can happen when I run a wsadmin script is nothing. Because if I see anything on STDOUT, that's normally a bad thing.

Ideally, I would have my Data described in a simple format that defines the System Resource (or MBean) I am trying to create and its associated attributes. Then, my script would read that data structure and create the MBeans necessary. Finally, at the end, it would generate a report that details what was changed in my environment. And, of course, if any failure's occur, all changes up to the failure are automatically rolled back.

Of course, I would love to see you purchase Phurnace Deliver which can do all of that and then some. However, you can create this yourself. The tools to do so are readily available and most Application Servers provide some sort of API to manage those configuration changes. Just remember to separate the Data from the Mechanism, and you should be much better off.

In Scriptsjava
Comment (0) Read More...


<< Start < Prev 1 2 Next > End >>