DougHughes.net

The Chicken Comes First

I have avoided writing the next entry in my series on learning the UML for several weeks. I keep sitting down to write it but quickly get frustrated and give up. Today I tried to force myself to write the entry and I still came up empty handed. I’m running into a fundamental problem when teaching something: You’ve got to know the subject matter!

I planed to write an introductory entry which acted as a quick overview of the various types of UML diagrams. Unfortunately, this has not been as easy as I hoped it would be. The fact of the matter is that to write an introduction to something, you know to know more about it than I do (yet).

So, I’ve decided to skip this entry and to save it till last. When I’m done with all of my entries on the UML diagrams I will then write the diagram overview. After this is done I will piece all of the entries together into a short book and make it available freely on this website.

Look for the next entry to be on requirements gathering! Coming soon to this blog!

See JRun Run Laszlo

If you haven’t heard of Laszlo, you might be interested in knowing that it’s a free, open source server which generates flash and is similar in nature to Flex. Unfortunately, it didn’t seem like it would run on JRun.

Well, seeing as its open source, I downloaded it and started trying to figure out why it didn’t work. After about two weeks of screwing around with it, I figured out a sequence of steps to get Laszlo up and running under JRun.

The steps below have been reproduced successfully on two separate machines. Another coworker of mine was not able to get this to work and I wasn’t able to help him resolve it. Please, if you try this, know that your mileage may vary! On top of that, remember that JRun is not (yet) a supported deployment platform for Laszlo! I will not be held accountable for what you do, or the results of what you do, with this (or any other) information!

Without further ado, here are the instructions I came up with. Please contribute any additional information in the comments section, if you have any.

1. Download / Install JRun
2. Download and extract the Laszlo 3 beta 1 core files. I did to F:downloadsLaszlo Core 3b1. The extraction created a tree of folders under lps-3.0b1-core. One of these folders is lps-3.0b1.
3. Create a new JRun server named “Laszlo”. Don’t start it. Take note of the HTTP port used. You’ll need to know this later.
4. Open the folder C:JRun4serversLaszlo and create a new folder called “Laszlo-war” under it
5. Delete the default-ear folder.
6. Copy the contents of lps-3.0b1 to C:JRun4serversLaszloLaszlo-war
7. Under Laszlo-war, open the WEB-INF folder and create a new file named jrun-web.xml. Put the following content into this file and save it:

<!DOCTYPE jrun-web-app PUBLIC "-/Macromedia, Inc./DTD jrun-web 1.0/EN" "http://www.macromedia.com/dtd/jrun-web.dtd">
<jrun-web-app>
<load-system-classes-first>false</load-system-classes-first>
</jrun-web-app>

1. Find and copy the file xerces.jar into C:JRun4serversLaszloLaszlo-warlib. I found the one I’m using in the source code distribution. I understand that Laszlo can be rather picky about this. I suggest getting the one from the source download.
2. Open C:JRun4bin
3. Copy jvm.config to jvm.config_Laszlo
4. Edit jvm.config_Laszlo in notepad. If you’re using ColdFusion on JRun delete any reference to any ColdFusion or cfusion (and its related settings). For me this was:
   • Remove: -Xbootclasspath/a:”{application.home}/servers/cfusion/cfusion-ear/cfusion-war/WEB-INF/cfusion/lib/webchartsJava2D.jar”
   • Remote everything after the “=” on the java.library.path= line.
   • Three paths with cfusion in them from the class path.
   • You may have others. Get rid of them!
5. Make these additional changes to the jvm.config_Laszlo file:
   • Add {application.home}/servers/Laszlo/Laszlo-war/WEB-INF/lib as the FIRST entry on the java.class.path line of jvm.config_Laszlo.
   • Then, move the {application.home}/lib from the end of the line to the second element.
6. My jvm.config_Laszlo ended up looking like as follows. Note, that some lines are shown wrapping. These are not line breaks. Also note, don’t just copy and paste this. Use this as a reference for your file. I broke another server by just copying this. Just make the changes suggested above and use this as a reference.

# VM configuration
#
# Where to find JVM, if {java.home}/jre exists then that JVM is used
# if not then it must be the path to the JRE itself
java.home=C:/JRun4/jre
#
# If no java.home is specified a VM is located by looking in these places in this
# order:
#
# 1) bin directory for java.dll (windows) or lib/<ARCH>/libjava.so (unix)
# 2) ../jre
# 3) registry (windows only)
# 4) JAVA_HOME env var plus jre (ie $JAVA_HOME/jre)
#
# Arguments to VM
java.args=-server -Xmx512m -Dsun.io.useCanonCaches=false -XX:MaxPermSize=128m -XX:+UseParallelGC
#
# commas will be converted to platform specific separator and the result will be passed
# as -Djava.ext.dirs= to the VM
java.ext.dirs={jre.home}/lib/ext
#
# where to find shared libraries
java.library.path=
system.path.first=false
#
# set the current working directory - useful for Windows to control
# the default search path used when loading DLLs since it comes
# before system directory, windows directory and PATH
java.user.dir={application.home}/../lib
# JVM classpath
java.class.path={application.home}/servers/Laszlo/Laszlo-war/WEB-INF/lib,{application.home}/lib,{application.home}/servers/lib,{application.home}/servers/lib

1. To use the config file you just created, you will need to create a window service and tell it to use the config file. To do this, open a command prompt and go to c:jrun4bin. Type:

   jrunsvc -install Laszlo "Laszlo" "Laszlo" -config jvm.config_Laszlo
   

   This will install the Laszlo server as a service. When the service starts up it will use the config file we just created.

2. Start the Laszlo service from the services control panel. Note, you actually need to not start Laszlo from the JRun interface. For it to work correctly you must use the services control panel. (I think.)
3. Navigate to http://localhost:8101/Laszlo-war/index.html (Note, use the HTTP port you noted when we got started and created the server).

Hooking into IIS

To hook Laslo into IIS via JRun follow these instructions:

1. Run the Web Server Configuration Tool. This will open a small window listing all your current configurations.
2. Click Add
3. In the new window select the JRun server to connect to. In this case “Laszlo”.
4. Select the IIS website to connect to from the drop down list. Note: I was able to get both CF and Laszlo to run via different JRun instances on the same IIS entry.
5. Do not check Configure web server for ColdFusion MX applications.
6. Click advanced.
7. Click the Use Application Mappings radio button. Type in .lzx (to the right of the add button) and click add.
8. Click ok.
9. Click ok again. You’ve now configured IIS to send requests for lzx files to JRun and Laszlo for processing. There’s a gotcha, though. Laszlo doesn’t quite work correctly with IIS.
10. To correctly complete the configuration open the IIS admin and find the site you just connected JRun to. Add a virtual directory in the root of the site named Laszlo-war. Map this to C:JRunserversLaszloLaszlo-war.
11. Place any .lzx files you need into the C:JRunserversLaszloLaszlo-war directory. You can now access them via http://yourservername.com/Laszlo-war/yourfile.lzx and all will work! Woo hoo!

I will see what I can find out about how .lzx work so they can be placed right into your webroot.

Export ColdFusion 7 Settings

Have you ever wanted to export all of your settings from ColdFusion but didn’t think you could? What if you had to reinstall your server for some reason, or simply wanted to backup your settings? What if you wanted to move your configuration to another server? Well, many people don’t know that it’s very easy.

Follow these instructions to export your settings:

1. Login to the ColdFusion administrator
2. Click Archives and Deployments under the Server Settings section in the left hand navigation menu. This screen will let you create an archive of settings. Ostensibly, the purpose of this is to export settings for a single application. However, you can use it to export all of your settings (and import them too!)
3. In the Create New Archive form type an archive name. I typed “My Settings”. Click create. The page refreshes and you see your new archive listed in the Current Archives Definition List.
4. Click the edit icon (the pencil and paper) to the left of your archive. This opens a popup window where you can select the settings you want to export. You can give this a description if you want. Simply click the Select All button to select all the settings on your server. (I think this might be the default.) If you don’t want to export all your settings go though the items on the left of this window and select what you do want to export. When done click Close Window. You archive has now been configured.
5. To export your archive click the Build icon (looks like a pyramid and paper, to the right of the edit icon). This opens another popup window. The first page reviews the settings you’re exporting. Click the next link in the lower right corner. The next page ask where you want to create the archive. I tend to just stick these in the root of my C: drive. You have to name the file with a “.car” extension. I called mine c:settings.car.
6. Click next again. The archive is created and you will receive a popup indicating that it was successful. You will now have a file on your server wherever you indicate it should be created! This can be backed up, emailed, copied, or whatever.

Follow these instructions to restore your archive:

1. Login to the ColdFusion administrator
2. Click Archives and Deployments under the Server Settings section in the left hand navigation menu.
3. Type the path to your .car file in the Deploy an Existing Archive section. Click Deploy.
4. Review the settings in the popup window.
5. Click next in the lower right corner. Your settings will be deployed to your server.

This can be VERY useful when working with a large number of clustered ColdFusion servers. Imagine manually adding a data source to 10 servers without messing something up! All you need do now is type them in one location, export your settings and import on 9 other servers.

Drinkin' Cold Coffee -or – CFUG Doug

As Joe Rinehart blogged recently, he and I are in Austin, Texas today and will be visiting the local CFUG. I will be speaking on how to use Java from ColdFusion.

In the spirit of the ColdFusion Community as a whole, I decided to post the presentation to my site. You can download the presentation here.

There are a number of example files which expect to be run from a CF enabled web server. The first examples are based on a ZIP component, complete with source. A second set of examples use the Alagad Image Component. To see the Image Component examples you will need to download the Alagad Image Component from Alagad.com and create a mapping named Image2 to the directory containing the image.cfc file.

I’m open to doing Breeze presentations of this for other user groups, if there’s an interest. I also have a few other presentations I need to post at some point.

I there are any specific topics you want me to write presentations on let me know and perhaps I will!

What Is UML?

This blog entry begins a series on learning the Unified Modeling Language (UML). For more information on the series read my blog entry entitled “Learning UML“. This entry gets us started by explaining what UML is.

What is UML?

Before we can start learning about the Unified Modeling Language (UML), we should first understand what the UML is, and, if possible, what the UML is not. The UML Specification defines UML like this:

The Unified Modeling Language (UML) is a language for specifying, visualizing, constructing, and documenting the artifacts of software systems.

I had to look up their definition of “artifacts” to really begin to understand what this was supposed to mean. The UML specification defines artifacts as:

A physical piece of information that is used or produced by a software development process. Examples of Artifacts include models, source files, scripts, and binary executable files. An artifact may constitute the implementation of a deployable component. Synonym: product. Contrast: component.

All in all, this is a pretty verbose way of saying that the UML is a language for modeling everything involved in software systems. Artifacts are simply the products created by and for the system. These might be class files, data, scripts and more. In fact, the UML is a generic system for modeling business processes not specific to software systems. I will be focusing on its application to software systems.

The UML standard defines a number of graphical diagrams. The diagrams are designed to give us different perspectives on the system we are modeling. This means that for any concept in a system we will have multiple diagrams. No single diagram is sufficient to model your system. However, combined, the diagrams help to create a consistent picture of the system. Each diagram illustrates concepts from a specific perspective and helps us to thoroughly analyze our systems.

The diagrams included in the UML specification are as follows:

• Use Case Diagram
• Class Diagram
• Behavior Diagrams:
  • Statechart Diagram
  • Activity Diagram
• Interaction Diagrams:
  • Sequence Diagram
  • Collaboration Diagram
• Implementation Diagrams:
  • Component Diagram
  • Deployment Diagram

Note: The purposes of the diagrams will be covered in a future blog entry and each diagram will also receive a dedicated and detailed entry.

In a previous blog entry which addressed why projects fail, I compared software development to bridge building. To continue that metaphor, the UML provides the same purpose to software development that blueprints do to bridge building. UML is the blueprint for your software. Blueprints and UML both serve the purpose of illustrating interrelated portions of a complex system in a detailed manner. The illustrations enable us to comprehend and understand a system in its entirety.

Construction blueprints provide a standardized language which allows an architect to clearly communicate with the workers who build the bridge. The UML provides the same purpose in that it allows software architects to effectively communicate their design to the programmers who build the system. The UML provides the fundamental concepts, semantics, and visual elements to facilitate this communication.

Because of the continuing importance of software, the software industry has been in search of techniques which help improve quality, manage complexity, shorten the time to market, reduce expense, and insure project success. The search has produced technologies and techniques such as visual programming, design patterns, development frameworks and more. The UML is not tied to a specific architecture or methodology and, therefore, integrates with virtually any technique, technology or architecture.

An important tenet of the UML is that it not process specific. In other words, the UML is only a language for describing software system. Consequently, UML integrates well with existing methodologies and allows architects to apply their own styles. The UML’s separation from process also means that UML is language, tool, and process agnostic.

So, what exactly is the UML?

The UML is a process agnostic graphical language for specifying, describing and architecting components of Object Oriented software systems. By utilizing various types of diagrams, the UML allows you to see and understand software system from multiple perspectives. Additionally, because UML does not define or require a specific process, it can be integrated into most development methodologies and allows architects to apply their own best practices, techniques and unique styles.

Watch this site for the next entry in the series on Learning UML. The next topics will be on development methodologies and the various UML diagrams.

The Fortune Web Service

Those Linux and BSD users out there might be familiar with the Fortune program which outputs random adages. I just ported it to a ColdFusion Web Service. Click here for more information.

Why So Many Software Projects Fail and What You Can Do About It

As Thomas Pender states in his book, UML Weekend Crash Course, software development is not a formal discipline. What this means is that application programming, unlike, for example, bridge building, does not have formal standardized processes.

Consider this comparison: Bridge builders (as well as other engineering and construction professions) are renowned for designing and building highly reliable structures on time and on budget. Software developers are notorious for building highly unreliable systems which are delivered late, if ever, and over budget.

When was the last time you drove over a bridge which collapsed? How about the last time you had a problem with software?

So the question then becomes why do so many software projects fail? Well, there are many facets to this question. However, I personally believe that most of the time the failures result from a failure to manage and control common problems in software development. These problems include, but are not limited to:

Problems which are managerial in nature:

• Project Requirements are Poorly Defined

  How many of us have worked on projects where there were no documented requirements? I have sad memories where the only requirements for projects were notes I scribbled down while talking to clients. Most of these projects failed to get off the ground.

• Lack of User Feedback

  Lack of user feedback is a serious problem in software development. In many cases, projects I worked on failed due to a lack of user feedback. There were many times I was left without any feedback on what I was building until the first version of the software was completed!

• Change

  As software development progresses there are bound to be changes. These changes can be a result of changing client requirements, lessons learned in previous development cycles, or for any other host of reasons. Failure to control change can lead to scope creep and projects which are never complete.

• Unrealism

  We’ve all worked on projects with unrealistic requirements. These might be unrealistic expectations or unrealistic timelines. If a project has unrealistic objectives, how can you ever hope to achieve them?

Problems which are not necessarily managerial in nature:

• Complexity

  Let’s face it, software is complex. I challenge you to name one piece of machinery which can produce as many outputs as a simple text editor. Unfortunately, over time, even with the best intentions, complex software applications tend to break down into buggy, difficult to maintain spaghetti code. Complexity is a big threat to the successful completion of an application.

From the perspective of a software developer this list of problems can seem quite daunting, to say the least. But take heart! Bridge building was not always a science; it has matured over 3000 years. Bridges have not always been built on time or on budget. Sometimes they fell down! I interpret this to mean that software development will continue to trend towards more reliable systems developed increasingly on time and on budget.

For many years now people (who are much smarter than me) have been working to formalize the software development field. The results of their work are concepts such as UML, various Development Methodologies, Design Patterns and much more. As developers, we are beginning to be responsible for not only keeping current with the most recent technologies, but also the most recent techniques. These techniques can help manage the problems listed above and help us to deliver reliable software on time and on budget.

Development Methodologies

Development methodologies are a means and technique applied to the entire process of software development, from inception, though requirements gathering, programming, project completion and everything in between. Development methodologies do not necessarily directly impact the code created. They do, however, define the process, vocabulary, rules and guidelines for creating software.

In a nutshell, development methodologies are a science of the process of creating software applications. There are literally hundreds of formal development methodologies. This might be because not all methodologies are well suited for types of software or all development teams.

A methodology which is iterative or incremental in nature will help in defining project requirements and obtaining user feedback. It will also help integrate change into the development process and foster realistic expectations.

Object Oriented Programming

A greatly simplified definition of Object Oriented Programming (OOP) is a programming technique in which code is grouped into objects which make up a software application. Objects abstract and provide ways of manipulating data. I will not get into the details of Object Oriented Programming. There are many fantastic resources on the web dedicated to Object Oriented Programming.

Object Oriented Programming helps you to create more manageable software applications by helping you to control the interrelated problems of complexity and change. Because program logic is encapsulated into logical objects, Object Oriented Programming helps control the complexity of software code by helping to prevent redundant and spaghetti code. By controlling the complexity of software changes to the software become easier. Object Oriented Programming also helps to reduce the cost of maintenance and helps in the creation of reusable code.

Uniform Modeling Language

Unified Modeling Language (UML) is a standard way of modeling and describing object oriented software systems. UML provides a visual vocabulary made up of icons used to describe object oriented software systems. UML does not define how the diagrams are to be used and allows architects to apply their own styles.

Because UML visually describes complex systems, it is a terrific tool to use so that all stake holders in an application can understand it before any code is written. UML helps expose potential problems, limitations, misunderstandings, and more in a complex system before the system exists.

UML is compromised of a number of diagrams, each with their specific purposes. Notable among these is the Use Case diagram which visually describes interactions between the system and users. This diagram illustrates to both clients and developers how a system will be used. This information is useful for validating requirements, helping clients provide feedback, and facilitates change when it’s most easily integrated.

UML provides a comprehensive way to understand complex systems. Because such an understanding is available before the system is created, it makes it easier to comprehend what will be required to build the system. Therefore, UML helps to foster realistic expectations of delivery timeline, system features and more.

Design Patterns

Design Patterns can be defined as time tested solutions to recurring software design problems. The concept of Design Patterns comes from the construction and engineering fields. Engineers came to the realization that for a particular class of problem there was frequently an eloquent solution could be applied time and time again. The same principal holds true for software development. By applying Design Patterns to software development problems you can help improve understanding and comprehension of a complex system across the development team. Design Patterns also help to create more reusable and flexible code.

As you can see, there are many techniques which can be applied to the software development process to help insure project success. Over the next few weeks and months I hope to touch on more of these issues. In particular, I plan on a high level review of Development Methodologies, requirements gathering, and lots of details on the various UML diagrams. If there is anything in particular you would like to see covered please leave a comment.