Archive for March, 2009

Using a scrum-like project approach

Wednesday, March 25th, 2009

scrum

We at Componence decided to use the agile project development methodology Scrum to develop a product that has little predefined requirements and a lot of technical challenges.

Scrum is quite a leap from our usual approach called PIM which is Prince 2 based and aimed at structured and controlled project development. Scrum has a highly agile character with scope and planning using yellow papers, daily stand up meetings and a lot of interaction between the developers, designers and project management.

The project team is located in one room on our office. This meant taking people from their usual places and getting them deep into the project ‘cave’. We’ve drawn up a lot of yellow papers with features on them and stuck them to the wall in a square called “Todo”, this represents the open workload and the upper line of yellow papers is the sprintworkload for the active sprint of 1 week. When a feature is being developed we move it to the next square called “In progress”, which has a subsection with features that will be finished today. Finally there is a square called “Done”, this shows all completed features.

Each morning at 9.00 sharp we discuss the previous day, the current day and the challenges we’ve had and still expect. This meeting is open for every member of the project, including our client.

planningThe approach takes some getting used to. Especially since we’re used to working with a strictly defined functional scope that can be developed by multiple teams at once. Scrum is much more efficient, but it is far less predictable and you have to be alert all the time to solve challenges as they arise. As always communication is the key and Scrum supports that very well.

So far the team is happy with the approach and we’re delivering very fast. I’m also very enthusiastic and looking forward to deliver the final product.

Speaking of colors

Tuesday, March 17th, 2009

Componence being the company that it is provides some … interesting experiences abroad. Last week I took a short trip over there to discuss some matter related to the boring stuff we call work.  But it also happened to be “Holi“, a festival that celebrated the victory of good over evil. As with many things in India, they celebrate with as much exuberance as they spice their food.

I was fortunate enough to be with our guys during this time of celebration and they have shown me that they want you to experience India to its fullest whenever they can. In this case it meant that I got to wear many colors. Kind of like a Chameleon one might say. The result is rather colorful and to me the way our Indian team “allowed” (and I use that term lightly!) me to join in on their celebration signifies to me the way we operate here at Componence. Whether in Jaipur, Nieuwegein, Auckland, Lviv or Spain… somehow we always tend to be able to enjoy each other’s company beyond the drudgery of work.

Anyways, more on actual work related stuff later! For now I leave you with a picture and invite you to “spot the foreigner!”

These colors however... do somethingthe colors! they do nothing!

Chameleon needs to be more visual and conceptual

Sunday, March 15th, 2009
We need to be more visual to show the value of our Chameleon solution

We need to be more visual to show the value of our Chameleon solution

In the past weeks I have been telling about our Chameleon solution to managers of different type of businesses like music, publishing, health, communities, education and even pharmaceutical.

The concepts are definitely there, they see the interesting possibilities to combine their content with the Web APIs. And with the possibility to let the results or parts of the results be serviced through different channels (communities, partner websites, desktop, mobile) the possibilities for new online business models become even more evident.

But I have also spoken to many designers, creative directors and business consultants. They all said the same thing: you guys are too technical referring to the presentation of a Fanbase 2.0 concept, thinking that it was a lot less technical than all our other presentations.

Componence Fanbase2 0 Solution V2.3 Teaser 20090312

View more presentations from Ha Vo.

In the coming month I will get us some new presentations that will be 100% better for non technical people to visualize their own possibilities with Chameleon! I will work together with external people to make sure that this time Chameleon will sound like a business solution rather than a technical solution. We should be able to present a presentation like this:

Activity Streams & the social networking malaise

Using XIP tool in WLP10.2

Saturday, March 14th, 2009

Installing the Export/Import Utility

You only need to perform the following procedure if you intend to run the Export/Import Utility as a stand-alone application. If you only want to run the WorkSpace Studio propagation tools, then the following procedure is unnecessary.

  1. Before installing the Export/Import Utility, be sure you have Ant 1.6.5 in your PATH environment variable. Ant is part of the normal WebLogic Server installation. It is located in:
  2. <BEA_HOME>/modules/org.apache.ant_1.6.5/bin

  3. Stop WebLogic Server if it is running.
  4. Open the file <WLP_HOME>/bin/xip/build.xml, and edit the following properties in the Installer section to point to the appropriate locations:
  5. Property
    Description
    bea.dir
    Points to <BEA_HOME>/wlserver_10.0.
    wlp.lib.dir
    Points to ${bea.dir}/portal/lib.
  6. Using a utility such as WinZip, open the following WAR file:
  7. <WLP_HOME>/lib/modules/wlp-propagation-web-lib.war

  8. Extract the file propagation.jar from the WAR file and save it in <WLP_HOME>/lib.
  9. Tip: If you place the propagation.jar file in <WLP_HOME>/lib, you do not need to add it to the wlp.classpath in the build.xml file. If it is not in this directory, you must add it to the wlp.classpath in build.xml.
  10. Create a directory called ejb under ${wlp.lib.dir}/netuix, and extract netuix.jar from the following EAR and place it in that directory:
  11. <WLP_HOME>/lib/modules/wlp-framework-full-app-lib.ear

    Note: The file ${wlp.lib.dir}/netuix/ejb/netuix.jar is referenced in the wlp.classpath in build.xml.
  12. Build the Export/Import Utility. To do this, run the following command from within the <WLP_HOME>/bin/xip directory:
      export JAVA_HOME=$BEA_HOME/jdk150_11
  13. ant

    Note: If you get the error “taskdef class weblogic.ant.taskdefs.build.LibClasspathTask cannot be found”, please provide additional lib reference to ant as -

    ant -lib $BEA_HOME/wlserver_10.0/server/lib/weblogic.jar

    Note: You may also get some error like “java.lang.UnsupportedClassVersionError: org/apache/tools/ant/loader/AntClassLoader2″, please also set variable JAVA_HOME to your jdk1.50_11 as -

    export JAVA_HOME=$BEA_HOME/jdk150_11

    Note:It is recomended to make a shell script with all the tasks required to run as:


    #!/bin/bash
    export BEA_HOME=/usr/bea/bea102
    export JAVA_HOME=$BEA_HOME/jdk150_11
    export WEBLOGIC_HOME=$BEA_HOME/wlserver_10.0
    export PATH=$PATH:$BEA_HOME/modules/org.apache.ant_1.6.5/bin
    export WL_HOME=$WEBLOGIC_HOME
    ant  -lib $BEA_HOME/wlserver_10.0/server/lib/weblogic.jar

    You may safely ignore the error <BEA-160144>

    Overview of the Export/Import Utility

    The XIP Utility allows a full round-trip development life cycle, where you can easily move portals and desktops between a WorkSpace Studio environment and a staging or production environment, as shown in figure:

    Round Trip Development

    Round Trip Development

    This utility lets you import .portal, .pinc, and other portal framework files into the database, and lets you export these files from the database. The exported files can be loaded back into WorkSpace Studio, or imported into another WebLogic Portal database.

    The utility performs its work in a single database transaction. If the utility fails for some reason, the database is not affected.

    What the Utility Moves

    The Export/Import Utility moves desktops, portlet references, books, pages, and localization definitions. In other words, the utility exports .portal, .pinc, and other portal framework files from a database, and imports the contents of those files back into a database.

    Note: The actual definitions for portlets, look and feels, shells, menus, layouts, themes, JSPs, and other code are contained in the EAR file. These files are stored in directories in portal web applications, such as the framework/markup directory. If any of these file-based elements change, you must rebuild and redeploy the EAR. The .portal and other portal framework files simply refer to the definition files.

    What the Utility Does Not Move

    The Export/Import Utility does not handle the following items: campaigns, behavior tracking events, content management assets, entitlements, WSRP producer registration, portlet categories, localization resources, user profiles, and commerce data.

    Refining Rules for Exporting and Importing

    The Export/Import Utility allows you to select an object (desktop, book or page) at any level (library, admin, visitor) and import it or export it, according to specified rules.

    To refine and customize the export and import of .portal, .pinc, and other portal framework files to and from the database, you can:

    * Specify rules to determine how portal elements are merged. For instance, in a manner similar to that of a source code control mechanism, changes in a .portal file can be merged with changes in the database.
    * Specify scoping rules. Scoping rules determine how new books and pages will be merged into the new environment. Note that user and administrator customizations are preserved when assets are merged.

    As shown in Figure below, the Export/Import Utility offers flexibility with respect to importing, exporting, and scoping. You can scope changes to the library, admin (desktop), or visitor (individual user) level. For instance, if you import a desktop at the admin scope, the imported changes will be applied only to the specified desktop. If a user has customized that particular desktop, then the changes will also be inherited by the user desktop. Note, however, that changes are never inherited up the hierarchy. Elements in the library will not inherit changes made to a desktop.
    Tip: For a more in depth discussion of the relationship between the library, desktops, and user views, see Scope and Library Inheritance.

    Options

    Options