March 8th, 2010 §
If you have done any development in Java-land, then surely you came across the dreaded three letter word EJB. And you were most likely duped into thinking it was great. I did! Then I realised it was just a specification. It was a great big, furry, non-executable PDF. A specification for managing objects but the creating of these objects were just horrid. EJB3 was a clean-up exercise, but still far from nice.
A couple of months ago I ran into OSGi again, but with SCA on top of it. Horrid! SCA is yet another warm and huggable specification. But it’s so ugly to work with. Everything feels so over the top complicated and restrictive in expression. And the tools that I saw built on this SCA implementation were just awful. Beyond being buggy, the enforced paradigm was just counter-productive. When will tool vendors realise that talented developers do not want a diagramming interface to write code? But the root cause is that the SCA specification describes the diagramming notation. Yuck! Same reason that I do UML sketches with a lot of bastardisations with no tie-in with my code.
And let me not go into domain specific big vendor specs, designs, blue prints, etc. like IBM’s Insurance Application Architecture (IAA). Nasty stuff.
More commonly, I see so many self-confessed agile teams fearing the dreaded big design up front, and the big requirements up front document thrown over the wall. If there is such a fear for big-x-up-front, why is there no fear for big-industry-and-vendor-specs-up-front like EJB, SCA, IAA, etc?
Why?
There are deep lessons and principles lurking beneath this surface. Agile demands you to be a lot more aware of actions, decisions and consequences.
So why do you choose not to be agile when you are trying so hard to be agile?
December 28th, 2009 Comments Off
I just upgraded to Snow Leopard and installed buildr which failed miserably.
/Library/Ruby/Gems/1.8/gems/rjb-1.1.9/lib/rjbcore.bundle: dlopen(/Library/Ruby/Gems/1.8/gems/rjb-1.1.9/lib/rjbcore.bundle, 9): no suitable image found. Did find: (LoadError)
/Library/Ruby/Gems/1.8/gems/rjb-1.1.9/lib/rjbcore.bundle: no matching architecture in universal wrapper - /Library/Ruby/Gems/1.8/gems/rjb-1.1.9/lib/rjbcore.bundle
It turns out that I needed to rebuild rjb, the ruby-java bridge, but that failed too.
extconf.rb:48: JAVA_HOME is not set. (RuntimeError)
I was certain that JAVA_HOME was definitely set and it was pointing to the 64-bit Apple 1.6 JDK. Digging in extconf.rb, it finds JAVA_HOME from the ENV hash
javahome = ENV['JAVA_HOME']
So, nothing weird about that too! What’s going on? I was installing buildr like this
sudo gem install buildr
The problem is that once you sudo, you are running with another environment, one without the JAVA_HOME variable. So, the quick fix is simply
sudo env JAVA_HOME=$JAVA_HOME gem install '1.1.9' rjb
sudo env JAVA_HOME=$JAVA_HOME gem install buildr
I completely forgot about this side-effect. Like all side-effects, it was painful – it just cost me an hour of digging around looking at all sorts of other things. But, more importantly, breaking fundamental assumptions (e.g. my environment is the sudo’s environment) and zoning in on the root cause of the problem resulted in a very simple solution.
August 12th, 2009 Comments Off
I finally got out of neutral and pulled together the first public offering our Domain Driven Design courses in Cape Town, South Africa. Normally we give these courses on-site with people on the same development team but I thought it may be fun and inspiring to open it up to everyone for a change. Now I’m all excited again and really looking forward to a diverse mixture of people. Hopefully, I will see some old faces and lots of new people.
The one thing I can tell you is that the course is a very immersive experience. I really hate lecturing but I enjoy probing conversations and that’s how I give the course. I don’t have answers to the practical work and concerns are addressed as we go along. As a result, the day takes unexpected turns and routes. But in the end I get you to the right destination. Come along; you will leave exhausted, but inspired!
Take the Fast Track to Domain Driven Design
about the course / course contents / should you attend? / register for the course
factor10 has expanded its services in South Africa to include our advanced and
expert level courses aimed for the software professional. On September 8-9, 2009,
we will be offering a fast track to DDD for Architects at the BMW Pavilion in
Cape Town.
Who should attend?
This course is for software professionals that want to take the right steps towards
advanced and expert levels in their careers. Register for this course if you want to …
- learn more than just another syntax and set of tools
- write software for large, long living systems
- increase the quality and maintainability of your design
- design high quality models and use code to represent those models effectively
- develop applications with a good APIs
- add a design edge to your skill set
Why should you learn DDD?
More and more developers and architects realise that learning every detail of a new
API just isn’t the way to deliver the best business value. It’s such a tough balancing
act; focus on the solving the business problem and focus on building working software
with your frameworks.
One way of taking a big leap in the right direction is to learn and apply domain driven
design. It is definitely not abstract and fluffy; it deals a lot with the code also. DDD
leads us to focus on understanding and to communicate that understanding very well;
in language, in design and in code. You will shift your focus away from designing for a
technology, and you will learn to design for the business domain; to the core of the
problems and solutions. Those are the most interesting parts and what your users
and customers really care about.
about the course / course contents / should you attend? / register for the course
May 7th, 2009 §
The unfortunate human characteristic in all of us is that we like rules when we’re in a new and unfamiliar situation, and hate them the moment we think we are experts. The problem is that rules are great for creating concrete things. If you want to build this then: do a, then b, if you have a c then do d otherwise do e. But it does not work with creating abstract things. And software development is all about building abstractions.
In the past few weeks, I’ve had a few instances where I realized that some people were, basically, asking me for DDD rules – steps for building an aggregate, when and how to use the specification pattern, etc. There are no rules for the noobs for these things. But I think I can constrain the environment so that the noobs can focus a bit more intimately with these aggregates and specifications. One rule I put down was “When working with the following … don’t work outside of this Java package”
Essentially, my proposition is that rules for noobs should constrain the learning environment, not the subject being studied.
November 25th, 2008 §
My presentations from Oredev are finally available. After working through almost all the export options on Keynote, I have settled on QuickTime as the distro format. The “flying code” in the aspects presentation worked out best with QuickTime. Note that it’s not a continuous playback and you have to click-through each frame.
). This one has the flying code, as