I've been quiet for a while... here is why...

Hi again.

Sorry for my extended silence on this blog.  My excuse is that overall blogging activity is drastically reduced due to becoming a father and starting a business... also we are blogging over at http://thebitheap.blogspot.co.uk/ these days from a business perspective.

I will very occasionally put content here when it is not directly related to our company (bheap), but don't hold your breath :-)

In the meantime, I hope you are well!

Software, jamming the signal

Here I examine, on a micro-scale, the reasons for complexity and limitations in software engineering in the enterprise.

Todays programming languages are just amazing, sure they will continue to get better and better, but right now they are pretty damn amazing. It is impossible to learn everything there is to know about even a handful of them, and if we are honest, without the luxury of time most of us are sadly lacking in proficiency. In this Pantheon (considered either by beauty, elegance, capability or a dozen other criteria) I personally would place at least Scala, Clojure and Haskell.

So, what is the excuse ? Why the complexity and limitations in software engineering ? The answer is simple. Us. Human beings. In fact, it is so bad I cannot even categorise between those of us who are technical and those who are not, (as a techie I am of course biased towards blaming those who are not technical, or technical _enough_ for all the problems).

We are slaves to so many bad habits, and philosophies that it is almost a miracle we ever get anything right. I am guilty of it too. I will not try to list the bad habits and philosophies that I am guilty of as there are so many :-) , but I will list those I have witnessed in others. To avoid being purely destructive I will also point out possible fixes I have seen (both ignored and implemented).

So in no particular order, and with no particular definition of complexity here are some bad habits, and their causes:

1) artificial technical constraint imposition

• agenda (insidious and ubiquitous)

2) artificial deadline imposition

• lack of strategy

3) poor role definition and allocation of resource to roles

• lax recruiting
• lack of understanding of the capabilities of resources
• using the wrong tool for the job

So, what kind of evil do these habits let in to your organisation ?

• rushed, unmaintainable, unstable code
• lack of exploitation of the magic and power of languages, toolkits and frameworks
• the death of motivation
• the death of projects

How do we fix the three problems isolated above ?

1) Ensure the agenda of 'the business' is always placed above the agenda of any individual. This requires good communication between key project stakeholders and business domain experts and the technical teams who will be delivering on projects. Managers need balls to sort this one out, shots may need to be called to replace individuals who are 'jamming the signal'.

2) Ensure the business and technical teams work together to define sound strategy. This needs to go through some rigorous processes, and needs buy in. It is ridiculous to impose deadlines on technical teams without consulting with them. An act of lunacy.

3) Sometimes, due to either agenda or perhaps just incompetence, a resource may act like a signal jammer. Communications break down, and a project starts to fail. Once again this needs to be recognised at a higher level. Restructuring is _always_ the right thing to do here. Why use the wrong tool for the job ?

Just as a system comprised of quality components with a clear signal works beautifully, so too does a team comprised of quality resources with clear communications.

Business Startup

So, it is out there in the wild now. I am no longer a full time permanent employee. A colleague and I have started a company and are going to write software and consult. Exciting times.

We will be employing Scala, Akka, iOS and Android, so plenty of bases are covered.

There are all sorts of reasons for us choosing to do this now, including:

- being our own bosses
- pursuing a shared set of philosophies
- prospects for exciting and varied projects
- making some money !

We have had to wear so many hats and pull so many threads in to make it all work, but it has been fun so far. Today we signed our first contract. We can't wait to get to work with our new model.

It is early days yet, (content and styling are placeholders only) but our site is up. Improvements and material to come. We will link in our company twitter details and blog when they are ready.

Free Your Domain - Better Models of the Problem Domain Part One

I touched on techniques to aid in building a better model of the problem domain in a previous post. The post briefly covered two points, the first was that we can do many things 'eventually', we can 'defer' them, thus wresting more control over when we do things with our architecture; the second was that we can simplify our abstraction or model of a problem, keeping it unpolluted. I will try to provide more detail on the second point in this post.

First let us look at what software architecture is. As a discipline I can't help but think of it as a declaration of war on a problem. The problem domain can be almost anything you can think of, and can range in difficulty from trivial to almost infinitely complex. If the problem is trivial then we are very likely going to crush our enemy without much effort. On the other hand if the problem is complex, we need to be more careful, we need to consider both tactics and more importantly strategy. We need to choose the appropriate weapons to aid us, and we need to use all the tricks we know, and then some.

So, to recap, we need to choose the right weapon, something versatile, deadly, powerful. Thats easy, let us choose Scala, and actors. Our tactics and perhaps to a lesser extent our strategy depend to some extent on our choice of weapon. Likewise our weapon choice may depend on our tactics and strategy. As it happens, at work we are comfortable that Scala gives us a better range of tactics and strategy than any other language for most use cases.

Now we are on our way to giving the problem a good hammering, but we don't want to be overconfident. Now we need to ensure our strategy is good, our tactics are sound, and that we have a few tricks up our sleeve.

The legendary strategist Sun Tzu said 'all warfare is based on deception'. We are going to deceive in two very important ways. First we are going to deceive in terms of hiding the composition of our forces (this is represented by our model of the problem domain). Second we are going to deceive in terms of when we are going to attack the problem (we are going to defer, using actors), more on this in the next post.

A Deceptively Simple Model of the Problem Domain - Conceal the Composition of your Forces

We all hate a polluted and overly complicated model of the problem domain. What is it that causes this complexity ?

- lack of thought
- lack of understanding of the problem domain
- persistence

The first two I will not comment on, but persistence is worth looking at. There are so many problems caused by the persistence facet in any project I could almost write a book about it :-) Ours at work boil down to the need to persist in a relatively flexible way, sometimes relational, sometimes post relational.

By the time we have prepared our domain for persistence in just a relational store we have either written an essay in XML, or given our code a lethal injection of annotations. Simply put, we lose the will to live. It is really quite upsetting. Worse than upsetting, it is actually in my opinion dangerous to the health of the project. The elegance, intention and pretty much all other meaningful parts of the model or abstraction of the problem domain are literally lost in a maze of tangled concerns. Thats bad mmkay ?

Now we are going to take our first steps towards a better model of the problem domain. First we are going to use Scala's case classes, and only Scala's case classes to model the problem domain. No tangled persistence gibberish. Yes I consider it to be gibberish when it has invaded my sacrosanct model, where it clearly does not belong.

It is time for some pseudo code. Please note this is overly simplified and not particularly robust, it is intended to be concise :-)

sealed trait SimpleEntity {
  var id = 0L
}

case class CannonFodderGruntType1(description: String) extends SimpleEntity

case class CannonFodderGruntType2(description: String, weapons: Int) extends SimpleEntity

Urm, that is it. Hard to find a mechanism in any language which offers so much in so little code. I won't list the goodies we get for free here, they are well documented.

At this point, it looks like we have a pushover army, unable to persist itself. That is true, for now. We are deceiving our enemy, concealing the true composition of our forces until the last possible minute. Enter Scala's implicit conversions.

Once we have decided how we want to persist our domain we use a handful of lines of code to tell it how it should persist itself. If I use as an example Squeryl, an excellent SQL DSL library.

class SquerylPersistenceWrapper[T <: SimpleEntity](grunt: T) extends SpecialKey

implicit def wrapSimpleEntity[T <: SimpleEntity](grunt: T) = new SquerylPersistenceWrapper(grunt)

At work we have wrappers for JDBC based store integration and perhaps in the future other alternatives.

Suddenly the enemy (durability) sees that we are more than a match for it. At the last minute we persist our domain, as we wish, and there is nothing our enemy can do about it. Better still, our domain model is concise, unpolluted and therefore has a better chance of remaining meaningful long into the future.

To wrap up, here is very typical sample of what a domain layer looks like after a lethal injection of annotations.

@Entity
@Table(name="CANNON_FODDER_GRUNT_1")
case class CannonFodderGruntType1(
  @Id @GeneratedValue(strategy=GenerationType.AUTO, generator="CFGT1_SEQ")
  @SequenceGenerator(name="CFGT1_SEQ", sequenceName="CFGT1_SEQ")
  @Column(name="CFGT1_ID", nullable=false)
  @BeanProperty var id: Long) extends SimpleEntity {

  @Column(name="DESCRIPTION", nullable=false, length=254)
  @BeanProperty var description: String = _
  
  def this() = this(null)
}

Urm, yes, well, something along those lines :-) The intent is most definitely in my opinion lost.

Type Class Utopia Part One

I have been working through a personal dilemma recently, namely that of deciding what the perfect solution would be for making the ultimate type class implementation. I have seen a series of dialogues based around Scala type classes in particular over the last few weeks, and it is this which made me want to look back to Haskell, to see if Scala has 'caught up' with it.

I can only speak with the benefit of experience on type classes in two languages, Haskell and Scala, an old, elegant, 'firm favourite', and a more recently found 'get things done', powerhouse. My Haskell days are mostly behind me now as I must admit to never really being able to use it in enterprise. Nonetheless it is still to me the most elegant, pure, beautiful language. My Scala experience is limited to a little over three years, with only two years worth of putting it to work in the enterprise.

If we start with Haskell and a contrived example, a Difference Engine, somewhat simpler than Charles Babbage's version. By chance we have a need at work to do something along these very lines, basically a pluggable calculation engine.

data CalculableEntity = CalculableEntity { x :: Int, y :: Int }

class DifferenceEngine a where
    calculateDifference :: a -> Int

instance DifferenceEngine CalculableEntity where
    calculateDifference (CalculableEntity a b) = a - b

calculate a = calculateDifference(a)

So, that is pure, elegant, beautiful even. Moreover it is easy to take it further and calculate on the Double type or any other, we just need a new instance working with the new type. So far there is no form of obfuscation in my opinion, it can not as far as I can see be made any simpler to a developer trying to understand intent. Is this perfection ? Let us come back to that when we have explored it further a little later.

Let us look at the Scala equivalent.

case class CalculableEntity(x: Int, y: Int)

trait DifferenceEngine[T] {
  def calculateDifference(ce: T): Int
}

def calculate[T](t: T)(implicit de: DifferenceEngine[T]) = de.calculateDifference(t)

object DifferenceEngine {
  implicit object CEDifferenceEngine extends DifferenceEngine[CalculableEntity] {
    def calculateDifference(ce: CalculableEntity) = {
      ce.x - ce.y
    }  
  }
}

This does basically the same thing. Personally I look at this and immediately see clutter. Now some of that we can excuse as Scala marries the functional and object oriented paradigms, and excellently too. One consequence of this is that Scala's type system can not be as elegant as Haskell's. What worries me more though is the use of implicits. Implicits offer us great power, but with great power comes great responsibility, and all of these extra keywords in my opinion add more clutter, further obfuscating the intent of the code.

Here it is almost like we are losing our identity a little with all of this wrapping and the sprinkling of magic keywords. I understand that we are delegating to the compiler, but in so doing we are polluting the reference manual by which our audience will understand our intent.

So ends round one, and in my opinion Haskell comes out on top. I think Charles Babbage would have backed Haskell thus far. In part two I will explore where Scala may have an edge over Haskell.

Eventually everything, and actors

I tweeted a little while ago about the appeal of 'eventual' everything; eventually persisted, eventually synchronised etc etc. I am still of a mind that this is a good thing, it lets cross cutting concerns be handled in a truly elegant way, especially when coupled with the actor paradigm.

In recent days at work we have been tasked with architecting a new logging / auditing module for our platform, and we had to jump through the usual hoops in thinking out a solution. We have what is often called a kernel, and many (surely to grow in number) satellite modules. Some persist to a relational store, some to a search index, some to a post relational store. As per usual we need to be able to audit actions on any of these, with clearly defined verbs dictating what is possible within our system. We need to think of the usual CRUD operations, and also 'preview' and 'publish' operations.

We immediately thought about the possibility of 'eventually' logging / auditing, as in our case there is no need for real time reporting on logged / audited information. Additionally, by decoupling auditing / logging to an even greater extent than using aspects, by using actors, we can keep our codebase simple and elegant, letting a hive of workers do our work for us, in a scalable way with redundancy built in whether it is on one machine or across many.

A further advantage is that completely independently from the code which fires auditing or logging operations we can model in a simple real world way the kind of delegation required to perform all these many tasks which need to occur in our platform. We simply abstract our auditing 'messages' conveniently handled by Scala's case classes, and fire them at a worker or set of workers who know how to handle them, and can choose how they want to persist them. No need to wrap unpleasant aspects across the multiple projects which comprise our ever growing platform.

We are betting on actors in a big way, and this paradigm is delivering in solving real world problems in an elegant way. Right now there are several actor implementations, with more in the pipeline. For us Akka provides a massive number of integration possibilities, and great performance.

What does Scala have to offer the workplace?

Update: Phil Bagwell of the Scala team has done a far better job than me with writing this up over at :

scala-lang.org

I posted very briefly a little while back on our experiences with Scala. The positive results of our experiences were duly noted. I thought it was time to give a little more back to the community, and those considering this move. This post attempts to put some thoughts together on:

- who are we and what do we do ?
- why Scala ?
- what do we do with Scala ?
- how to transition ?
- what benefits will you see ?

Of course this commentary is subjective, it is what we as a team have found, and we had a particular scenario in place at our company 'Thatcham Motor Insurance Repair Research Centre'. Furthermore the management have been very open minded and supportive of the technical team's decisions regarding technology stack options.

At Thatcham we conduct research and produce data based on that research. We research efficient, safe, cost effective repair of vehicles, and work with manufacturers to influence the design of new vehicles. If you want to know more, you can visit our site: www.thatcham.org (please note this is an old site currently under redesign by our team on a new Scala powered platform).

Our team is small, but over the last year we have been tasked to rewrite the entire suite of research software within the company, and to create a new publishing platform to disseminate the data gathered by the research software. These two parallel projects are long running, comprising many mostly web services based modules. The need to rewrite our software stems from a transition to a more web services oriented technical world, and a desire to architect a more coherent extensible platform. A small team needs to avoid firefighting, and must think things through clearly in order to not just survive, but evolve.

Why Scala? In all honesty our first concern was the sheer bloat involved in creating such a large architecture with Java. We initially had a split down the middle of the team between JVM land and .NET land. It is noticeable these days how far plain old Java is lagging behind. Why not use something better than both, with all the choice and power of the venerable Java ecosystem on tap?

We use Scala exclusively across the server side, and these days, that is where the majority of the action is. We have traditional ORM oriented modules, distributed modules, publishing modules and traditional webapp modules. The question in fact is what can't we do with Scala? Perhaps the most crucial of our modules or layers, are the distributed modules, here we make use of Scala's excellent concurrency ready concepts, and in particular actors / message passing. Our chosen implementation of actors is www.akkasource.org, mainly for the very capable integration capabilities it offers. Effectively Scala and in particular Akka have made us cloud ready, scalable and confident that we are flexible.

How do you get started with Scala, and more importantly bring it in to the enterprise ? Start slowly, Java and C# devs can all get fairly proficient quickly. Ensure the management understand the different ways Scala can be put into use. You can write Scala in a Java style, then harness it's power to a greater level over time. Finally, don't be afraid to ask your questions on the mail lists, both the Scala and Akka list members are very helpful.

How has using Scala benefited Thatcham ?

- the power of functional programming, more choice than just OOP
- collapsing the inheritance hierarchy, alternatives to inheritance, reducing coupling
- expressive syntax, express your intention, solve problems cleanly
- everything is a library, make the language do what you want, how you want it to do things
- enriching the toolset, upgrade your tools, 'pimp my library'
- dropping heavy, cumbersome dependencies, Scala does what Java needs many libraries and frameworks to do
- simple lightweight compile time checked composability and dependency injection
- feature rich actors / message passing, 'free your domain' from pollution, be flexible, scalable

Of note, we have measured a reduction in lines of code by approximately one third thanks to Scala's expressive syntax, and the concise nature of functional programming. Our reduction in dependency baggage has lead to our deployable artifact's more than halving in size where we are not hooked up to ORM. Perhaps more importantly we have more options at an architectural level, thanks to the capabilities of a more evolved language, and developing and architecting are just more fun, which is an often overlooked side effect of the transition.

All of this, and we can still leverage the undeniably rich JVM ecosystem, all those well implemented frameworks. In short we can do more with less code, and we can do it better.

If you want to know more, post a comment, I will be happy to give any help I can.

Scala Revisited

Some considerable time has passed since I last blogged. In part, this is because of just how busy I have been working on excellent projects at work, and in part because I must confess to tweeting these days.

There is still definitely a place for blogging if you want to say a little more though so here goes.

In short, using Scala for real in the work place has worked out better than I could ever have imagined. Not only is it a joy to work with in hobby coding world, but it is a real world powerhouse problem solver. After a successful proof of concept project, and a prototype converted project, the company have now agreed to adopt Scala for all server side development. Furthermore, because of the powerful capabilities of the language, our rules systems will probably end up being written in Scala.

This has enabled us to drop the never quite delivering on the promises .NET platform. Too many times we came up against brick walls, or found partially or incorrectly implemented specs. We now have the brilliant position of being able to use the powerful and varied open source projects in the JVM ecosystem.

Scala is a joy to use. This joy has persisted for me from when I first tinkered with it just over two years ago to the present day.

Long may it continue.

Well, a little news on my career

I am finishing with my current company in two weeks time, and heading back to a company I worked at before. Things just did not work out where I currently am, the company is a little too small, and seem reluctant to change their processes more towards those of a software house. My obsessive compulsive tendencies towards quality, are not shared by anyone else in the company it seems. They are a little too obsessed with what is shiny in the world...

I am looking forward to working with the new team, several of whom I know well, and to the challenges in the department. I will be taking with me several tools from my tool box, including Wicket, Brix, Maven, but hope to leave behind in large part Java, which I am becoming increasingly disillusioned with. I feel the JVM is still the way forward, but in order to compete with trends and the evolution of other languages I need to ditch Java.

Currently it seems that Scala does much of what I need to do, and my next step may even be to use the features of the language itself to enable me to drop all of those frameworks that the inadequacies of Java forced me to use.

More information sometime soon...

Getting involved with a newish project, Brix-CMS

Continuing my interest in all things Wicket, some months before Christmas I found an open source project called Brix CMS, currently hosted on Google Code. It seemed like a more agile fit for my needs regarding content driven websites, with high value placed on componentisation. Additionally the project owners are committers for Wicket, and have put a very well organised framework together in Brix, easily extensible, and very powerful.

I have bashed some sites together using Brix already for a range of clients for my company, and have been pleasantly surprised with how I have been able to apply the framework to so many different domains.

It is early days yet, but the discussion lists are picking up a little, and the roadmap looks promising. As a tool, it certainly fits my needs so I will be following it with great interest. Documentation is sparse but improving, and much of what you need to do to extend Brix is fairly intuitive.

Leveraging Wicket and Jackrabbit seems to provide such power and flexibility, I find it hard to go back to the ways of JSF or even worse Servlets and XSLT as some of my company's projects use. Cocoon with XSLT yes, Servlets with XSLT please no... no... no.

I am having a little difficulty getting my head around integration testing with Brix, the ability to test wicket pages in isolation is something I am missing, but hopefully I will find a way.

I have an admission to make.. I changed sides to Wicket

I had evaluated Wicket once before in its early days and dismissed it as a toy, but back in August, after frustrations with trying to write 'complete' web applications, not just for processing xml with Cocoon I tried it again... and absolutely loved it. I have since built a handful of web applications for different clients across the UK, NHS, University and other with Wicket and the Apache Jackrabbit repository backing it up.

The combination of Wicket and Jackrabbit is very powerful indeed. While the verbose nature of Java means nothing is particularly compact with Wicket, the componentisation capabilities are amazing! I love the code re-use possibilities. Every problem can be broken down into is constituent parts.

I don't know much yet about the performance I can expect to see when building webapps with Wicket, its something I will have to read up on.

I have been reading with interest over the last few months how the hippo guys are doing the same. It will be interesting to check out their latest cms release when it is out of beta.

Cocoon 2.2, Spring and Database Integration

Well, it seems I spoke too soon in my last post where I said...

'therefore, you can do anything you like with technologies like Hibernate, marvellous..'.

While Cocoon 2.2 integration with Spring is watertight.. integrating with the right versions of Spring libraries outside of the default ones, and with Hibernate or JPA is not straight forward. Furthermore, as has always been the case, while the documentation for Cocoon is slowly growing in terms of quantity, and quality, it is still far behind many other projects. I had big issues getting any solution to work in terms of writing to or reading from the database, and saw, that many others have apparently had the same problems. In many cases, I saw strange hacks to get things working, and lets face it, users want to see a solution work without strange and ugly hacks.

Changing topics, Cocoon Forms has frustrated me recently, while I have always admired its powerful capabilities, I do not like the way it just seems to 'brake the flow of an application, requiring different matchers, and templating technologies. I realy wanted to enable the componentisation of forms under my own widget system, where forms could just be embedded in a simple manner. I ended up hacking my application to such a deep level that I decided I was better of just using the 'Form is the whole World' approach as per usual. Perhaps someone else has a solution around this?

Anyhow, thats enough of my thoughts on these two subjects, I will get back to them both next time.

More on Cocoon 2.2 and Maven

Well a couple of months ago I blogged to talk about a number of projects I was working on using Cocoon 2.2 and Maven 2. Here is a little catch up. Both are on the point of going live, and since my last post, Cocoon 2.2 has finally been fully released.

My experiences are all good with both, although as per usual, and particularly where more than one technology is involved, the learning curve is definitely a factor to be taken into consideration, particularly if time is short, or your development team is small.

First up, the company website I mentioned, is due to go live in a matter of weeks now. Crafting it with Cocoon 2.2 was great fun, so neat and tidy. Managing it with Maven 2 is also very efficient. The time required to make everything work well in Maven was pretty immense though, for example the need for a private corporate repository, and a proxy to enable reproducible builds at any time.

I mentioned before that I had no experience with working with databases through Cocoon, and that seemed at the time to be a daunting prospect. Well it turns out Cocoon 2.2's integration with Spring is as watertight as it says on the box, and therefore, you can do anything you like with technologies like Hibernate, marvellous!

Separation of concerns is still to me one of the very best features of Cocoon, and twinned with powerful transformation pipelines, you get the complete set of tools to work with.

Thanks to the Cocoon and Maven teams for providing such excellent tools to work with.

Touching base on Maven and Cocoon

I blogged a while ago on a new technology (to me), Maven, and one I am familiar with... Cocoon, now here is a quick catch up on both topics.. combined. I am now using both Maven and Cocoon, in the form of Cocoon 2.2, which I am experimenting with for the first time. The modular approach for builds that maven represents appeals to me, and Cocoon is an old favourite in my development toolkit, yes it still gives me a warm glow inside, and truthfully I have not yet experienced anything as good in terms of architecting an elegant web platform.

I intend to rewrite my company website using this set of tools, and have another project to work on simultaneously, the former is purely a publishing project, something I have experience in, the latter is a database intensive operation, something I am not comfortable with in terms of Cocoon. I have still not seen any beginner (best practice) samples for developing DB powered webapps with Cocoon.. specifically Cocoon 2.2, the search goes on. If I do find any, I will be sure to post them as a follow up to this.

In terms of my experience so far, this Maven Cocoon 2 combination has a fair overhead, particularly if you are not familiar with the concept of build tools such as Apache Ant, and Cocoon by itself is a large and complex platform. The joy is in watching your efforts rewarded with powerful automation, and an incremental, concise approach, allowing the developer to use lego blocks, reusing code, and expanding the boundaries confining any architecture elements of the system.

A word of warning though, as of right now, the chances of a successful build of Cocoon 2.2, without being forced to tinker with the system are slim, it is a frustrating experience, which perhaps only makes your eventual success (hopefully), all the more pleasant.

Decisions decisions.. choosing technologies

Ah but it is so difficult sometimes to choose one technology over another. I have been a big fan of Cocoon for several years now, and know how to use it in some scenarios but not in others, I don't know of a better publishing platform, but what about when you need to work with dynamic input, and databases, what patterns are in place for that side of things?

I have yet to find a better templating system than XSLT, but then when you are getting your data dynamically from a database you don't necessarily want to be working with it in XML. What I really need is a pattern where we can splice seamlessly data from XML, database, and other backend sources, without adding the overhead of squeezing the database results into XML format. Oh and to confuse things further, I'd like to do it with Cocoon 2.2, for which there is nowhere near enough documentation yet.

On recent projects for my new company, in an effort to build componentised platforms for working in a modular way with dynamic data from a database backend, I have worked with JSF and Facelets, and while it is a big improvement over JSF with JSP, there is something that still does not feel natural about it. I get no warm glow like I do when I revisit similar past projects written in Cocoon.... perhaps I am not adapting to change very well, I don't know.. perhaps there was a more domain based language approach using Cocoon and custom templating / component systems?

If anyone has any advice on working with multiple backend stores in a fluid way with Cocoon 2.2, I'd love them to point the way.

On the same subject are there any profiling results out for Cocoon 2.2 benchmarks, without caching, information on the reduction in bloat? It would be interesting reading.

The next project, data modelling, warehouse, inventory?

So, as we are about to roll out a massive project to one of our clients, a 'very' large British company, I am excited in as much as there will be new things on the horizon. Several months ago now I blogged on an upcoming project involving workflow engines, and the fact that this was something about which I new absolutely nothing. Well I find myself in the same situation now.

It looks like for another client in the UK, a well known University, we have a need to develop some kind of inventory / stores / data warehouse system. Once again, I know nothing about this, and my first thought is, 'is there an excellent open source framework out there for this?'.

I am currently researching online, and looking through various books. But this sort of thing is of course better coming from those who are experienced, anyone out there know anything about this?

My last project hooked me up with the guys at JBoss, their workflow engine is really very good, and will only get better over time. What is out their for warehousing, inventory?

Any pointers appreciated :-)

Maven, to use or not to use

I have looked at Maven as a possible approach to standardise the way I work with projects in the past, and have thought it has a great deal of promise, but two things have held me back from working with it... time, and some negative reviews from people I respect in the software development circles.

Now I am working in a small company, where in between projects there is scope to work on improving project platforms, engine rooms etc, and there is definitely scope to improve reuse of code. Added to this I am sick of checking jar files to source control, it seems a bit pointless.

So I grabbed myself a PDF to read through, and intend to beef up on Mavenesque ways over the next few weeks, lets see how it goes.

I will report back in a while.

Goes quiet, pondering, where's my cup of tea?

Ayee, its time for the Cocoon Get Together 2007 and I cannot go!

Tis a terrible shame but I am missing the Cocoon Get Together this year as I have a massive project deadline. Double shame because it is in Rome. Oh woe is me!

Instead I am working with British Airways on a huge project which will initially be released to some 23,000 users. No pressure.

I am sad that I cannot make it, but I will just have to get everything booked early for next year. I really enjoyed doing the presentation last year with Jeremy, and as per usual the food and beer.

I will have to get back online and back on the radar again once the deadline is over to talk to the Cocoon guys.

What with being flooded one week after moving in to our new house also, its been a pretty duff year really.

Another month on, and I am still in Workflow Engine land

So, time goes by, and I am still working with workflow engines, my experience and opinions have changed somewhat.

First up I have dropped OSWorkflow, the graphical designer just did not do what I needed it to. I am now using JBPM from the JBoss folks. And not withstanding the site, which as per all other workflow sites does not point the way to a workflow engine newbie, I am very impressed with the documentation, the helpfulness of the people in the forum, and the capabilities of the product itself, including the graphical designer which is an Eclipse plugin.

The product is fairly stable, and any bugs I do find and report are not critical, so far so good. Most importantly, for a large project with one of my company's largest clients I am able to create business processes emcompassing all of their requirements.

Requirements I see to make this 'the' leading workflow engine would be some improvements to point the way for 'newbies', and a cookbook for common process definition howto's.

I am pleased that all aspects of the project are under ongoing development with regular released.

Now I am looking forward to the post project launch days where I might finally be able to go get some much needed holiday :-)

Workflow software/projects

The most poorly documented, tried and tested software I have yet encountered.. that sums it up.

Most of the projects I tried either did not work as advertised due to bugs, or were so poorly documented that it would have taken me weeks to get started.

Luckily in the case of some, there were some helpful people in the Open Source world to give me a hand getting started. Notably with OSWorkflow.

Come on guys, a couple of howto's, some some testing and a friendly to beginners site is not too much to ask?

To be fair it turns out there are some books and products coming soon for OSWorkflow, they will be helpful, just a little too late for my project unfortunately.