Fedora 11 KDE install

Now that I have upgraded my world to Fedora 11 I wanted to take KDE for a spin. The default is Gnome on the desktop, so here is what I had to do to provide the option to use KDE as a desktop:

# install the kde package group.
#
$ yum install @kde-desktop

# but got some errors that the libavcodec.so.51 was a dependency
# to k3b-extras-freeworld package, but Fedora 11 has a higher 
# version on my machine (libavcodec.so.52), so had to skip-broken
# with yum to avoid installing this package.
#
$ yum --skip-broken instal @kde-desktop

# if you want to default KDE on the machine you can do some or
# all of the following.
#
$ yum install switchdesk-gui switchdesk

# for gui run the switchdesk command and select KDE.
#
$ switchdesk

# for cli run with kde option.
#
$ switchdesk kde 

# for gui to make KDM the default display manager.
#
$ yum install system-switch-displaymanager-gnome

# for cli to switch to KDM display manager.
#
$ yum install system-switch-displaymanager

# for gui run the system-switch-displaymanager command and select KDM.
#
$ system-switch-displaymanager

# for cli run with kdm option.
#
$ system-switch-displaymanager kdm

Not much to it! ;-)

Upgrade Fedora 10 to Fedora 11 howto

A few simple steps to upgrade:

# As root you would like to have a clean start to the
# upgrade, so get an update out of the way.
#
$ yum update rpm

$ yum -y update

$ yum clean all

# Should a new kernel install/update require it,
# reboot before continuing with the rest.
#
# Then install the preupgrade package.
#
$ yum install preupgrade

# For console upgrade, use:
#
$ preupgrade-cli

# If you like gui's to upgrade, use this.
#
$ preupgrade

Setup KVM (virtualization) in Fedora 10

I was looking at the various howto's on the internet to get this up and running, but it would not work for me. I kept getting the two error messages below depending on the type of virtualization used (Xen vs. Qemu):

# with Xen I got this when trying to connect my local 
# default machine.
#
Unable to open connection to hypervisor URI 'xen:///'

# and with Qemu I got this when trying to connect my
# local default machine.
#
Unable to open connection to hypervisor 'qemu:///'

A few things needed to be installed for qemu to get this working properly so you can define and install a new virtual machine:

# Standard Virtulization packages in the group which
# once installed will get you to the same error messages
# above once you try to connect your local machine in
# the Virtual Machine Manager.
#
$ yum groupinstall 'Virtualization'

# now we need some qemu stuff:
#
$ yum install qemu qemu-launcher virt-manager virt-mem

After this I could connect to my local machine (qemu:///system) using the Virtual Machine Manager.

Letter to President Obama about jBPM

Some of you might remember that I was published with Financial Crisis Front Line: SNS Bank in June of this year in 2009 BPM & Workflow Handbook, which was released at a W3C conference in Washington, DC.

As the focus of this book was BPM in government, the publisher has sent a copy to the President of the United States with a personal cover letter.

My chapter details a financial institution using jBPM. Will jBPM get his attention you think?

Remove your email from Mutt group reply

I was having the problem that I have two email addresses that people send to me from work and when I was replying to a group in Mutt it would include my email in the .cc line. Here is how to prevent that from happening:

# Add this to your .muttrc to prevent your name being
# added to .cc on group replies.
#
alternates "emailA@yourDomain.com|emailB@yourDomain.com"

Display and read HTML mail with mutt

I have lately been running into more people out there who seem to like HTML mail, which did not by default display all that well. Here is how to get mutt to automatically display HTML e-mail in-line:

# In your $HOME you should have (or create one) a .mailcap file,
# add these lines for displaying HTML inline.
#
text/html;      links %s; nametemplate=%s.html
text/html;      links -dump %s; nametemplate=%s.html; copiousoutput

# Then you need to turn on the automagic in mutt to actually
# display the HTML e-mail by adding this to your $HOME/.muttrc
# file.
#
auto_view text/html

Enjoy!

A JBoss BRMS workshop report

 The last week I have spent in Atlanta, GA at the RedHat offices attending a JBoss Business Rules Management System (BRMS) workshop. This was intended to give us a deeper understanding of the lastest rules platform offering that RedHat put together and was intended for a very technical audience.

I wanted to provide a bit of insight into the workshop to give you an idea what you can expect to receive if you should contemplate looking deeper into the JBoss BRMS.

Before I dig into the details and provide my impressions, I wanted to include some side notes on a trip to the USA. As you can see, the breakfast can just be awesome. I love pancakes/biscuits&gravy!

It would also not be America if you did not include something about the cars (picture is of a 1930's hotrod) and a baseball game (picture in Mariners stadium).

The workshop was held in the RedHat JBoss offices and included participants from the all over the globe; Japan, China, India, Argentina, France, Netherlands, and USA . The location was great, the instructors very good, and the kitchen was well stocked with coffee, soda, and snacks (see pictures). It was a three day show covering the following topics:

Day 1:

• Introduction to JBoss BRMS
• Rules development process
• The Drools rule language
• JBoss DevelStudio - Drools IDE
• RETE

This day started with a look at rule engines in general and what the BRMS actually includes. It demonstrated these components in action with a demo. The look at a rules development process provided a framework for making your rules projects successful. Covering the Drools rule language took us through the basics, conditions, consequences, and a closer look at the API for those programming interactions with the BRMS. We installed the JBoss DevelStudio, tooling (free if you use the JBoss DevelStudio), and looked at the various components there including the debugging facilities. The day finished with a closer look at how the rule engine really works. Forward chaining and the RETE network was discussed in great detail as we were technical geeks wanting to know exactly how it all worked of course. There were labs for all these topics, allowing us to dig into the details on our own laptops.

Day 2:

• Decision tables
• Business Rules Manager: administration and guided rule editor
• Business Rules Manager: QA and deployment
• JBDS BMR integration
• Domain specific languages

Today started with a look at decision tables, as used by a business person to manage their rule base. We imported them and took a closer look at manipulating them through the API. The next topic was the Business Rules Manager (BRM) which is the product branded from the community web interface project better know as Guvnor. We looked at administration, assets, packages, rules, QA, and testing using this interface. My personal opinion is that the testing facilities are one of the stronger points to using this product. Next topic was the integration of the development environment with the BRM interface. We looked at creating a rules repository, exploring it and then adding assets from the developers IDE to be then manipulated/used in the BRM interface. Very good stuff! The day closed out with a detailed look at Domain specific languages (DSL). What a mapping file is, rule files using a DSL, the programming API when using a DSL, and using the DSL in the BRM interface. Again, there were labs for all these topics, allowing us to dig into the details on our own laptops. On a side note, Burr Sutter (Product Manager) joined us for most of the workshop (see picture) to add comments about product direction and jumped in on any questions we might have had with regards to the various products.

Day 3:

• Advanced rule authoring
• Execution control
• Rule flow
• Complex event processing (CEP)
• Performance considerations
  

The final day started by digging into advanced rule authoring concepts like conditional elements, field constraints, nested accessors, property change listeners, and the dynamic rules API. We discussed execution control topics including salience, control facts, groups, duration, no loop, and truth maintenance. We took a closer look into the rules flow and how you can create one, add constraints, deploy it, and run it. This was a lot of fun for me personally as I come from a jBPM background and know that product very well. After lunch we discussed the more advanced topic of Complex event processing (CEP). This included event declaration, semantics, streams support, event cloud, session clock, temporal reasoning, sliding window support, rule based partitioning, and memory management. Performance considerations was a topic that represented the best practices of using the Jboss BRMS. What are the various ways to prevent larger projects from performing poorly due to bad practices or bad rule writing. Again, there were labs for all these topics, allowing us to dig into the details on our own laptops (see picture).

I will be taking this all back to the Europe region and hopefully will be spreading the word soon at a location near you! 

Creating a jBPM process repository for unit testing with par files

My latest project involves general infrastructure improvements based on my experiences with jBPM. There have been many discussions about different aspects involving a generic process structure to enable the launching of new products in a more efficient, timely, and cost effective manner.

One of the more interesting elements in the general planning is to provide the development organization with a process repository. It will enable developers to leverage the existing Maven infrastructure to provide projects with exiting Process Archives, better known to jBPM developers as PAR files.

These files are similar to JAR files and contain the process definition along with any supporting Java classes needed to run. The interesting part is that you want to define simple process components (granularity is important) so that they can be leveraged through reuse. The idea then being that a new project can simply shop for existing process components and then import these exiting PAR files into a project where they plug into the project in process-state nodes (these being the jBPM sub-flows).

This requires that a simple process is the initial building block and needs to be setup with proper unit testing. For example, a simple process (which is left empty for posting purposes) that is used to transform input into some XML format via a single web service call. This call takes place in a state node, so you can see the process definition of the SuperProcess which calls the self contained SubProcess by fishing it out of the PAR repository included in the projects dependencies.

Here the SuperProcess definition:

<process-definition name="superprocess">

  <start-state name="start">
     <transition to="XML transform" name="to_process_state" />
  </start-state>

  <process-state name="XML transform">
    <sub-process name="xmltransform">
    <transition to="end" name="to_end" />
  </process-state>

  <end-state name="end" />

</process-definition>

The SubProcess definition:

<process-definition name="xmltransform">

  <start-state name="start">
    <transition to="end" name="to_end" />
  </start-state>

  <end-state name="end" />

</process-definition>

The unit test for the SubProcess (trivial in this example):

@Test
public void testXmltransformProcess() throws Exception {

  // Extract a process definition from the processdefinition.xml file.
  ProcessDefinition superProcessDefinition = 
    ProcessDefinition.parseXmlResource("xmltransform/processdefinition.xml");

  // Test it.
  assertNotNull("Definition should not be null", superProcessDefinition);

  // Setup superprocesses.
  ProcessInstance superProcessInstance = new ProcessInstance(superProcessDefinition);

  assertEquals(
    "Instance is in start state", 
    superProcessInstance.getRootToken().getNode().getName(), "start");

  // Move the process instance out of start state.
  superProcessInstance.signal();
  
  assertEquals(
    "Instance is in end state", 
    superProcessInstance.getRootToken().getNode().getName(), 
    "end");

  assertTrue("Instance has ended", superProcessInstance.hasEnded());

}

Now the unit test for the SuperProcess:

@Test
public void testSuperProcess() throws Exception {

  // Extract a process definition from the par file.
  ProcessDefinition subProcessDefinition = 
    ProcessDefinition.parseParResource("xmltransform.par");

  ProcessDefinition superProcessDefinition = 
    ProcessDefinition.parseXmlResource("superprocess/processdefinition.xml");

  // Test it.
  assertNotNull("Definition should not be null", subProcessDefinition);
  assertNotNull("Definition should not be null", superProcessDefinition);

  // Setup super and subprocesses.
  ProcessState processState = (ProcessState) superProcessDefinition.getNode("XML transform");
  processState.setSubProcessDefinition(subProcessDefinition);
        
  ProcessInstance superProcessInstance = new ProcessInstance(superProcessDefinition);
  ProcessInstance subProcessInstance   = new ProcessInstance(subProcessDefinition);
   
  // Get our process tokens.
  Token superToken = superProcessInstance.getRootToken();
  Token subToken   = subProcessInstance.getRootToken();

  assertEquals(
    "Instance is in start state",
    superProcessDefinition.getStartState(), 
    superToken.getNode());

  // Move the process instance from its start state to the first state.
  superToken.signal();

  // Subprocess in start?
  assertEquals(
    "SubProcess instance is in start state", 
    subProcessDefinition.getNode("start"), 
    subToken.getNode());
  
  // Move subprocess out of start.
  subToken.signal();
  
  // Subprocess ended?
  assertEquals(
    "SubProcess instance is in end state", 
    subProcessDefinition.getNode("end"), 
    subToken.getNode()); 
  assertTrue("SubProcess instance has ended", subProcessInstance.hasEnded());

  // Superprocess ended?
  assertEquals(
    "SuperProcess instance is in end state", 
    superProcessDefinition.getNode("end"), 
    superToken.getNode()); 
    assertTrue("SuperProcess instance has ended", superProcessInstance.hasEnded());

Of course these are really simple examples. We are looking into unit testing much more complex processes that include task-nodes, state-nodes, and processes with several layers (deep) of process-states. Anyone have experiences with these kinds of unit tests?

Note: these are jBPM v3.x processes.