Who’s On Phirst

Official blog of Phurnace Software.


Posted by: Daniel Nelson on

As just about anyone who has worked in software development at some point in their life can attest to, there are three levers that management can pull to affect the version under development: date, quality, and features. Now, I’ve worked at my fair share of development shops – some big, most small – but I think that which lever management goes to pull the most ends up saying a lot about the company, and also a lot about their business model.

Let’s take for example the apocryphal enterprise software company. They sell their software to big companies for a lot of cash. They have hundreds if not thousands of professional service engineers to do customizations after the sale. They also have a lot of competition. So, if a release is in jeopardy, which lever are they going to pull? Well, the quality one, of course. They can’t cut features, because those are what they compete on. They can’t push out the date, because those dates have been promised to customers, who won’t sign the check without the release. So, if something needs to get cut, it will be quality. Because (and I swear I have heard this) Pro Serve can fix the bugs in the field. (I’m not going to comment on that in this blog).

So, let’s take another example. Let’s say there was some mythical software company with a veritable big presence in operating systems and word processors. Well, they certainly aren’t going to cut features – releases are a big thing and they need to show real momentum. And they won’t cut quality – when you have a lot of customers you will enrage them quickly with shoddy work. (I know – we can debate whether they actually put out quality, but they DO care about it, and spend a lot of money on it.) So what they end up doing delaying releases over and over again. Sounds familiar?

So, of course, that leaves little ol’ us. Quality is obviously very important to us. We get people’s code and config out to their customers. It has to work really well or we just don’t provide value. Dates are also very important to us. Out of 23 iterations, we have been late a grand total of 2 days (and 1 day early). That’s because the way we work is to get out software in people’s hands and have them tell us what to build next. The lever we pull, when we have to, is features. We literally have about two years of new features already planned, but they won’t do anyone any good if they aren’t high quality, or if we spend forever getting them to market. So that’s what we focus on.

Which, I think, says a lot about us.

In Untagged 
Comment (0) Read More...


Posted by: Jessica Gass on


Here are a few helpful hints our developers have come up with while working with WebSphere.

Need to Make a Cell Name Change in WebSphere 6.0/6.1 Without Re-Installing WebSphere?
IBM provides a collection of sample Jacl & Jython scripts for less common administrative tasks. The scripts can be downloaded from IBM DeveloperWorks.

 

Stuck with an Annoying Cluster Name?
With Phurnace Deliver™, simply take a snapshot and globally replace the old name with the new one in the Configuration XML file. Then, use Phurnace Deliver™ to create a new Cluster with the correct name. All of your settings will be transferred to the new Cluster.

 

Comparing Raw WAS configurations
Trying to compare the raw configuration files of two different WebSphere environments? Make sure to check at the cell, node, and server scope for configuration objects. Since configurations are inherited from cells to nodes to servers, configurations can be applied to a server but the configuration XML will be missing from the server directory.

 

SIBus Startup Problems
If you encounter Service Integration Bus (SIBus) startup problems in WebSphere after restoring a configuration, you may have a GUID conflict in your SIBus database. Stop the server and delete the folder /path/to/profile/filestore/com.ibm.ws.sib. The problem is a GUID mismatch between the restored configuration and the database. Deleting this directory will make WebSphere recreate the database with the correct GUID.

 

WSADMIN Slowness
Each discrete call to WSADMIN instantiates a new JVM, which explains part of its slowness. In addition, each call is committed prior to continuing with the next step – which can cause problems if an error occurs mid-way through a script. A work around is to wrap the whole process in a transaction and roll-back in case of error.

 

WebSphere Profiles and Hostnames
When creating WebSphere profiles with the intention of federating them to a Cell, pay close attention the hostname you use. Verify that you can resolve all hostnames from all servers--both from the Node(s) to be federated and from the Deployment Manager. Setting the hostname to localhost will only work for standalone instances.

In WebSphere
Comment (2) Read More...


Posted by: Cynthia Sadler on

It seems like everyone is blogging today. Phurnace has a blog. I have a blog. My mother has a blog. All the cool kids are doing it, right? There are many reasons for starting a blog. For some, it is like a personal (or non-personal) diary for the whole world to read. Artistic folks use blogs to showcase their poetry, photographs or art. Businesses (like Phurnace Software) use a blog to show a more conversational and personal side to their company while still generating interest.

So, how can technical people benefit from blogs? When doing work related web searches, a good portion of information that I actually find and use comes from blog postings. There are a lot of tips and tricks out there, as well as some really good tutorials on a variety of topics. Looking for WebSphere related information? You could check out the WebSphere Community Blog as well as the developerWorks blog hosted on IBM. There are also plenty of programming languages blogs as well. Coming to mind are java.blogs and O'Reilly Ruby blog. And there is always my favorite all-around geek blog (and occasional gratuitous timewaster): Lifehacker.

Rather than just being on the receiving end of information, it is important for technical people to contribute to the blogosphere. Are you excited about a new technology? Spread the love. Did you discover a new technique? You should share with the rest of the world. Did you spend hours troubleshooting a problem? You should write it down to save yourself (and others) the pain the next time that occurs. And for these reasons (and there are many more), if you are the type reading this blog, then you should have your own blog or contribute to a team blog.

What makes a good technical blog? One that shares news or technical ideas. For example, you find a provocative news item (e.g., the latest web application server release), and have an opinion or comment on it. Or perhaps there is a specific bug or coding technique you can abstract to a wider audience. And include code samples! We love code samples! Think about this: if you were looking for information, how would you search for it on a search engine like Google. You should include that in your title for your blog entry.

Since writing a good technical blog is like being a mentor or coach, in that you will master your subject the more you do it, you should write, write, write. Hopefully you are now inspired to do so.

In Untagged 
Comment (0) Read More...


Posted by: Carey Benge on


“Every battle is won long before it is ever fought.”
     -- Sun-Tzu, the Art of War

I would like to share some of my thoughts on giving technology product demonstrations after years of being in “the heat of the battle.” The solutions-oriented sales cycle involves a sales team forming a relationship with a customer through which they are able to gain a thorough understanding of what the customer’s business needs are and how those needs affect the customer’s business. The sales team then uses this understanding to articulate how their solution can address the customer’s business needs to the benefit of the customer and their organization.

The “Demonstration” is the primary tool of the Sales Engineer and is a significant event in the technical selling process. It sets the stage for the remaining phases of the evaluation. While it is quite difficult to recover from a poor demonstration, an outstanding demonstration can make a solution the front-runner.

Demonstrations need to be well tuned to a customer’s needs in order to be successful. This tuning process begins with the definition of a solution for a targeted market. The process continues as the sales team consults with a customer and learns more about the needs of that specific customer. At the end of the sales cycle, when the customer signs a deal, the demonstration should be a visualization of the solution that the customer has purchased.

Demonstrations are a manifestation of a defined solution for a given market. They exist to provide a visualization of the business value that a customer could reap from a given solution. For a demonstration to be effective, however, there are several prerequisites that must exist.

The first prerequisite to a successful demonstration is that the product it represents must target a well-defined market and the specific needs of customers within that market. This ensures that a demonstration will have the potential to be relevant to any customer in that market.

The second prerequisite is that the sales team working in the targeted market must be able to “qualify” a given customer need to validate that the solution will be relevant to a given customer. This sales qualification process has two components. The first component involves one or several meetings with a customer to determine if they, in fact, have needs that are addressed by a given solution. If the customer’s needs could be met by the solution, the qualification process proceeds to the second component. In the second component, the sales team determines if the customer has a reason to act on those needs. Reasons for acting on those needs exist when:

  • Pain exists – there is some fundamental problem in the customer’s business that is causing some aspect of that business to under-perform.
  • A Need to fix the pain - consequences if not fixed, payback if it is fixed
  • A Business Driver to address the need - Compelling event, a sense of urgency; An initiative, a directive, a project
  • Owners of the Business Driver - the person that has the pain and needs the solution.

An effective demonstration does not "feature dump" or try to prove how smart the sales team is; it establishes value and technical differentiation by mapping qualified business needs to the technical solution.

In closing, let me clearly state that positioning features and benefits in terms that customer’s can understand and visualize while applying their business need -- is the key to setting the stage for a positive and smooth engagement. While positioning features and benefits occurs throughout the sales process, the demonstration is a significant event that visually links the business value to the technology. Remember again, it is quite difficult to recover from a poor demonstration but an outstanding demonstration can make you the front-runner.

Every mouse click, every keystroke, every additional capability, every new screen shown in a demo adds to the perceived complexity in the minds of the audience.

Focus on the specific capabilities needed by the customer to address their business issues – and hold everything else back. The demonstration should build a vision in the customers’ minds that they can easily visualize using the software themselves.

Focus and execute – and the reward will be the full order!

In Untagged 
Comment (0) Read More...


Posted by: Wesley Willard on

One of the hottest technologies right now in server-side development right now is OSGi (formerly known as the Open Services Gateway initiative). As the underlying framework on which the Eclipse Project's runtime is based (since 3.0), this technology is starting to garner a lot of attention for its abilities to allow the development of "bundles" (or, "plugins"). This has enabled the popularity of Eclipse to grow by leaps and bounds, as plugins can be quickly added or updated.

OSGi has moved beyond being "just" a very powerful piece of the Eclipse Project, and is rapidly gaining traction amongst enterprise application servers. It offers a mechanism for resolving complex classloading issues, which often cause problems for the developers of services for the application servers. It also provides the ability to control the visibility of the implementation details, which serves to prevent unintended coupling between bundles. By default, all packages in a bundle is private, and can only be visible outside of the bundle by explicit exporting. By enforcing these visibility rules, unnecessary dependencies in the software are avoided, allowing for independent development, and versioning of bundles. OSGi manages the life cycle of a bundle, from start to stop, and enforces security concerns at each step of the way. Also, OSGi is capable of functioning as a standalone container, which allows bundles to be tested without the need for a full-blown application server environment.

With the release of the SpringSource Application Platform, SpringSource has embraced OSGi in a big way, building its application server on top of the Eclipse Project's Equinox OSGi runtime environment. From the release announcement, these quotes from SpringSource CEO Rod Johnson stand out with regard to SpringSource's commitment to OSGi:

"It is the first product that built on a modern technology basis. Java EE compliance is no longer the be all and end all. We've got a competitive advantage because we have a clean new code base. We have designed and delivered to meet the requirements of today and not those from the last 10 years."

"The OSGi technology used is a fundamental next generation technology."

JBoss Application Server 5 is nearing its long-awaited release. In contrast to SpringSource's approach, JBoss is definitely hedging its bets, that while OSGi is definitely a major technology force, it might be prudent to be a little cautious in adopting it wholesale. By abstracting its interface to the component model, the JBoss Microcontainer will allow native support of POJO's, legacy MBeans, as well as OSGi. Its pluggable architecture model will also allow the flexibility to work with other component models that will be developed in the future.

In this article, Open Source analyst firm Redmonk's Michael Cote is quoted as saying:

"Rather than build their core on OSGi, they're building the core on their own stuff, and supporting OSGi as a sort of way of using that JBoss-specific core," he said. "The hedge there being that they can add on support for whatever comes into fashion if OSGi becomes tomorrow's bell-bottoms. If you have the time to build an architecture that lets you hedge like that, it's usually a good thing."

So, while both Spring and JBoss are definitely adding OSGi to the mix, their approaches reflect very different approaches. It will be interesting to see if one approach is better than the other.

In Spring FrameworkOSGiJBoss
Comment (0) Read More...


Posted by: Ann Nguyen on

If you have to provided a view that display RSS feeds content within a JSP, you have several choices of how you can approach this.

If you want to roll your own sleeves and parse the RSS XML, you can do so. Another choice is to defined the XML Schema for the different versions of RSS Feed and used JAXP or XMLBeans to generate the parser code for you.

With either one of those above choices, you still have to write the display code using the parser.

Another option, the one that I have chose to used is Sun's RSS Utilities. This comes with both the RSS parser code and a tag library that you could used inside of your jsp page. This utilities support RSS content version 0.91, 0.92, and 2.0.

The RSS Utilities are well documented at:

http://java.sun.com/developer/technicalArticles/javaserverpages/rss_utilities/

http://today.java.net/pub/a/today/2006/03/21/reading-news-with-sun-rss-utilities.html

What I have found out is that the utilities does not handle RSS Feeds with different languages. If you pull down news feeds that are not in English, the characters will not display correctly.

If you are using the same code to display RSS feeds from different places within one application, please be sure to specify the startIndex and endIndex, otherwise, it will only display up to the last index of its previous feed.

<%@ taglib uri="/WEB-INF/tlds/rssutils.tld" prefix="rss" %>
<%@ taglib uri="/WEB-INF/tlds/struts-tiles.tld" prefix="tiles" %>
<%@ page import="com.yourCompany.yourProject.YourConstants"%>
<tiles:useAttribute name="RSS_FeedUrl" scope="request"/>
<rss:feed url="<%=RSS_FeedUrl%>"
feedId="justAnId"/>
<b>Image: </b><rss:channelImage feedId="justAnId"/>
<b>Title: </b><rss:channelTitle feedId="justAnId"/>
<b>Link: </b><rss:channelLink feedId="justAnId" asLink="true"/>
<b>Description: </b><rss:channelDescription feedId="justAnId"/>
<ul>
<rss:forEachItem feedId="justAnId" startIndex="0" endIndex="<%=YourConstants.MAXIMUM_RSS_ITEMS%>">
<a href="<rss:itemLink feedId="justAnId"/>" target="_new"><rss:itemTitle feedId="justAnId"/></a>
<rss:itemDescription feedId="justAnId"/>
</rss:forEachItem>
</ul>

 

If the RSS tag could not parse, it will just throws Exception, thus it would be wise to catch these exception and handle it appropriately for your application, or for your portlet.

Happy RSSing and if you find an easy tool that could handle I18N, please let me know.

In Untagged 
Comment (0) Read More...


Posted by: Robert Reeves on

Steno PoolAbout 25 years ago,  “Word Processor” was a job title, not software. A company would dedicate cavernous rooms with rows upon rows of desks for each stenographer. The reason the term “stenographer” was used is that the pool members would use stenography, or shorthand, to take dictation. Anyone needing a letter written would have the stenographer bring a pad to their office and dictate the letter.

 

In a world that started at 9 and ended at 5, moving at this sort of glacial pace was more than acceptable. Fast forward to today’s 24 hour business day and downtime measured in milliseconds, the very idea of a steno pool is as ludicrous as bloodletting to cure a sinus infection. With computers on every desk, there is simply no reason to have an employee provide stenography services when we can all just type our correspondence ourselves. Moreover, we don’t even need printers or stamps or even a fax machine with email and wiki’s and IM. Just as the life insurance salesman has become a relic of an age dominated by middlemen, we have eliminated job tasks that are not core to our business.

 

We see the same shift in other business roles. Take the role of Office Manager, as an example. For a decades, the Office Manager mainly handled payroll. Today, with the rise of ADP, that role has diminished to the point that an Office Manager is a relic, albeit one from five years ago. Fortunately, we can expect that same marginalization of the Software Consultant role.

 

The Software Consultant, most often bundled with Professional Services, is another relic that should be eliminated. The very idea of Software Consulting means one thing: the software doesn’t work out of the box.

 

There are few situations where out-of-the-box productivity is not a requirement. These products are typically middleware that are so robust and feature-rich that the idea of them supporting your specific business processes is silly. After all, no one expects SAP to work out of the box. At the very least, you have to enter some employee data, customers, etc.

 

I expect better from my development and IT tools. Development and IT are well understood processes. As such, we’ve come to expect tools to support these processes out-of-the-box. For example, I certainly don’t require a Software Consultant to use Toad nor do I need one to help me with InstallAnywhere. The same can be said for Ant, CruiseControl and Eclipse. In today’s world, we expect the tools to Just Work, just like we expect people to type their own correspondence.

 

When you purchase software that requires Professional Services, typically, you are purchasing a framework. In turn, the Software Consultant will customize the implementation of the framework. Before you can say “billable hour”, the framework becomes a “bespoke framework”, and you are now a software development shop with outsourced labor costs. And you just thought you purchased some software…

 

Here is a handy test to see if you are purchasing software or a framework: Ask your account rep to provide a full accounting of your costs over the next five years, including upgrades and support for your infrastructure upgrades(OS, middleware, etc.) If the answer isn’t a number and instead results in days of answering questions about your internal process, then you’re buying a framework. Good luck.

In SoftwareServices
Comment (0) Read More...


Posted by: Nate Dillard on

Internships are a great resume builder, as you may already know, for a newbie trying to break into the software development field. Currently I'm interning for a start-up software company called Phurnace Software, Inc. located in Austin, Texas. They develop java software for application servers like WebSphere, JBoss, and Weblogic. I've had experience in coding in java, but hadn't of an application server. Truth be told I was kind of scared, since I didn't really know what I was getting myself into. Also, being from Michigan, about 1,300 miles away from home. Any kind of comfort zone I had was far away. Venturing out on your own can be scary, but rewarding at the same time.


Now, you might be wondering how a college kid from Michigan found himself a job with a small software start up in Austin. Well, I just happened to find a job posting on Craigslist in the Austin area. I sent an e-mail with my resume, and received a quick reply. A week later I had a job offer and I was off to Texas. I applied to a ton of large companies in the industry, since most of their application process is pretty cut and dry. But to no avail as I was probably up against a large number of applicants. I was really hoping to score a job with a small company with the reason being that I would be able to see more of the software development process and not doing the same repetitive task every day.


Currently, I'm already 2.5 months into my internship and it’s awesome! I'm glad I chose to work for a small start-up company because this is exactly what I want to do in life. How many jobs are you going to have where you can talk with the CEO and the co-founders of the company at any time? Or better yet, working with people who've been in the industry for a while and being able to soak in their knowledge. I'm learning a lot, more then I would from a class room and a text book. So, to anyone out there looking for an internship in the Software Development industry, I suggest finding a job with a small company that moves quickly (Austin ain’t bad either). It’s an awesome time you won't regret.

 

In Untagged 
Comment (0) Read More...


Posted by: Shawn Spiars on

The Eclipse Resources Plug-in (org.eclipse.core.resources) is one of the handiest Eclipse plug-ins that no one ever talks about. The Resources Plug-in is rarely talked about because it works behind-the-scenes to enable other plug-ins and APIs to function well. For example, it is the Resources Plug-in that enables the Resource Navigator view to expose a tree hierarchy of all the projects, folders, and files in your Eclipse workspace.

Before we get into the details of the Resources Plug-in it's important to understand the function of the Eclipse Workspace. The Eclipse Workspace is where the Eclipse IDE stores all your development artifacts (Projects/Folders/Files). The Eclipse Workspace's resource model is very similar to a file system. All Workspace resources are backed by a real file or directory in the native file system.

The Resources Plug-in, or API, contains many interfaces to help developers access and manipulate the artifacts within the workspace. Here are a few definitions of the more common interface classes.

 

  • IResource – all artifacts in the workspace are resources
  • IWorkspace – the basis for the Eclipse Platform resource management
  • IWorkspaceRoot – a root resource that represents the top of the workspace hierarchy
  • IContainer – resources which may contain other resources (projects and folders)
  • IProject – a type of resource which groups resources into buildable, reusable units
  • IFolder – may be leaf or non-leaf resources, and may contain files or other folders
  • IFile – files are leaf resources which contain data

If you are a java developer you are probably familiar with the java.io.* class library. The java.io.File class is what java developers normally use when reading and writing files and directories. When you are working with files and directories within the Eclipse workspace you should use the Eclipse Resources API, rather than the java.io.File class. If you use the standard java.io.File class to modify files or directories within the workspace you will need to force a refresh in your viewer so the changes made to the model (resources) are visible to the user.

The screenshot below shows a Package Explorer view exposing the contents of an Eclipse Workspace. This workspace contains a single project named “My Project”. The project contains a single folder named “My Folder”, and the folder contains a single file named “deleteMe.txt”.

 

The following code snippet demonstrates how to use the Resources API to access the project, folder, and file in this workspace example. After getting a handle to the workspace file “deleteMe.txt” we use the IFile delete method to delete the file from the folder.


try {

IWorkspace workspace = ResourcesPlugin.getWorkspace();

IWorkspaceRoot workspaceRoot = workspace.getRoot();

IProject myProject = workspaceRoot.getProject("MyProject");

if (myProject.exists()) {
IFolder myFolder = myProject.getFolder("My Folder");

if (myFolder.exists()) {
IFile myFile = myFolder.getFile("deleteMe.txt");

if (myFile.exists()) {
myFile.delete(true, true, null);
}

}

}

} catch (CoreException e) {
}

This is a very simple demonstration of how to use the Resources API to access and manipulate artifacts within the Eclipse Workspace. For more information on the Resources Plug-in and the Eclipse Workspace, check out these links:

Eclipse Wiki - Resources
Eclipse Workspace Team
Eclipse.org

In Eclipse
Comment (0) Read More...


Posted by: Alexander Bibighaus on

All companies have different needs and reasons they pursue outsourcing. While Phurnace had success with our first outsourcing project, it was not without lessons learned. Having just kicked off our second outsourcing project, I'd like to share some of these lessons for those of you who might be considering an outsourced software development project.

Recognize the inevitable challenges
If you are going “offshore”, the language barrier is always a challenge. Even well spoken English can sometimes be hard to understand when you are accustomed to hearing the Texas drawl. The time difference is challenging primarily because it adds stress to the end of your day and in the same way your begins with stress. Finally, the lack of direct interaction is by far the biggest challenge. Nothing replaces direct communication. The recognition of these challenges is important so that you find creative ways to mitigate them.

Choose your project wisely
Selecting a project with a lot of unknowns leaves the door open for disaster. In addition, maintenance projects can be a bad idea. Maintenance is often perceived as easy which evolves to thinking that maintenance can be outsourced. While it is certainly possible, maintenance often involves very difficult problems and your most knowledgeable developers. Instead, find a project that your internal development staff could knock out of the park; but, is not the best use of their time, technically speaking.

For Phurnace, the best projects are usually those that have two qualities:

  • Direct knowledge of the problem domain and scope by our development staff
  • Well defined deliverables

Don’t underestimate the time required
View your outsource team as an addition to your current team. One common mistake is to fall for the sales pitch that they will manage it for you. If you just acquired an outsource team of five people, think about the impact of 2 or 3 new additions to your staff. Use that as a starting point for estimating your time required.

Daily Communication
Agile development practices encourages direct and often communication. This same approach works very well with an outsourced team. Setup daily calls to get your project going. It may require a little nudging, but be persistent. The outsource team will eventually give because they want the project to be successful, too. If you gain confidence, you can figure out what works best once you have an understanding of how your team interacts with the rest of your organization.

Do away with formal status reports
Formal status reports might as well be named TPS reports (from the movie Office Space). They are very overrated but extremely common in outsourcing processes. They usually involve a few tables with tasks and hours. This tells you nothing about the actual progress. Think about what you really want to know and tell them what you to know and when. Here are some examples: What issues are currently outstanding. What items is the outsourcing team waiting on you for. What are is the plan for next week by person. This is the information you need so problems can be resolved quickly, and you can hold each individual accountable as you would your own team.

Expect to be very technical
Know the code that they are working with, understand the technical challenges, and be capable of providing direct technical advice. Don’t delegate this on an as-needed basis. If this is not your expertise, my recommendation is to find someone who can be on this project from day 1 to provide this assistance. This is extremely important because otherwise you will never really know how well the project is going.

Don’t forget testing
Ask for tests as deliverables. More importantly, make sure these deliverables are something you can take in-house in the case you decide to no longer use the outsourcing team.

So those are a few of the lessons learned from my first time around at Phurnace. I am excited about my new team and look forward watching their project -- very closely!

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