PBT Group and the Johannesburg Centre for Software Engineering are hosting a JRuby master class led by Andrea Provaglio. I met Andrea at the Software Architecture Workshop in Arosa, Switzerland this year and I cannot speak more highly of him. Just check out his web site for details. It’s not often that we get a chance to have such learned architects and practitioners in South Africa. Let’s take advantage of this opportunity. The greater the support, the easier it is for us to pull in heavy hitters in this industry for future events.There is a class scheduled for Johannesburg on 16 January 2008 and Cape Town on 29 January 2008. Registration is online at the JCSE website. Just follow the links from the front page.See you there!
Category Archives: Conferences
Speaking at TSS-JS 2008
I will be speaking at the next TheServerSide Java Symposium in Las Vegas in March 2008. The presentation will be part of the FrontLine Java track and will cover OSGi and its use in Enterprise Application Development. This is a more detailed presentation of what I was intending to cover at the *Camp in Cape Town.
*Camp Cape Town
UPDATE: Massive overload on the work front means a I can’t make this event 😦
The Cape Town Geek Dinner folk have managed to pull off *Camp, an unconference for all things tech-worthy. It’s happening on 8/9 December 2007 in Muizenberg in Cape Town. I may be doing a bit on SOA 101, and OSGi (depending on demand, I guess).
Geek Dinner Feedback
So I did go after all and it turned out to be a rather interesting event. There was a great turnout of about 60 or 70 people. The venue, The Wild Fig, was great, wine was sponsored by GETWINE (very generous of them), and WiFi hotspot by SkyRove. The talks were well timed, not too long or short, with a good mix of socio-political-technical chatter. The format was perfect: Quick intro to everyone, orders placed, 2 talks, starters, 2 talks, main course, 2 talks, desert, open mic. Just perfect!
Antoine van Gelder did a silent (self-inflicted-ducktape-on-mouth) talk on the One Laptop Per Child project. The point: children are taught to learn in silence, without expression. But expression online cannot be silenced. Very noble cause which I hope will get the time/publicity it deserves amongst the other fundamental challenges (hunger, health, etc) that children and families in Africa face daily. And he brought one of the laptops along for us to play with.
Bryn Divey did a well timed Python-bashes-PHP bit. If you ever liked PHP, you’d wish you didn’t. Very convincing argument against PHP, but I am still not convinced about Python. His delivery and style reminded me a lot of Dan North.
Tania Melnyczuk did one of the best project management flyovers I have seen. Nice to see that she touched on agile methodologies relevance in project management. At least I know one more project manager that I do not have to explain what a user story is and why I need to do a release planning session.
Nick Coyne did a really nice intro of Ruby on Rails and managed to evade the obvious Ruby-is-better-than-Python-is-better-than-Perl-we-all-hate-PHP dissidents. What was great to see was his pitch for having fun again and writing beautiful code. Something I relate to a lot.
Alan Levin spoke about the lack of socio-political endeavour attributed to lack of caring. In this instance, caring about bandwidth costs in South Africa … we all want more bandwidth cheaper but we really do not put our energy to make it happen. Very true. Are social and consumer causes dead in the post-apartheid South Africa? Or is it that only fundamental human rights violations warrant the mass protests of the 1980’s in which I grew up? Sri Sri Ravi Shankar will most likely pose the simple questions: What is your responsiblity and for what are you responsible?
Ian Gilfillan did a bit on emerging mind games such as Go and Marabaraba (sp?). He reckons that checkers, chess are dead ever since Deep Blue overpowered the great Gary Kasparov. It was nice diversion.
The open mic spot was seized by Robin Ronne who chatted about the Ripple project. I did not get the low down but it was something along the lines of a social network where the trust relationships have credits attached so that you can cut out the evil banks for all your money based transactions.
Neil Blakey-Milner mentioned that he will like to pull together an event in September over a couple of days. Sounded like an Open Spaces style event even if he did not use those words.
Overall: Interesting event. Was a bit disappointed initially with the lack of detailed technical content. Upon reflection, I reckon that the content suited the format. Highly recommended.
Reflections on the JCSE Agile and Architecture Talk
It was really good to be part of a very topical subject at the JCSE Architecture Forum last night. While these discussion are so valuable, the things that surface can only be glossed over, largely because of time constraints. I end up feeling a very satisfied and energised but a part of me feels a bit hollow.
So here are some of the things that surfaced at the Forum, and my narrow, unworldly opinion on each (i.e. I’m just trying to fill that hollow feeling).
When we talk about architecture, we need to define what we mean by architecture?
In my talk it was a very simple view of architecture which, thinking back, I should have disclosed very early. I am now applying from Kent Beck who talks about mutually beneficial relationships. So I think of architecture as the mutually beneficial relationship between two or more things. So what is a thing? It could be lines code in a method, methods in a class, classes in namespace, namespaces in code base, binaries in an application server, application servers in a cluster, … see where I am going? Architecture is about creating beneficial relationships, and the 5 things I discussed are based on this view. If you don’t know anything about the things, then you cannot create beneficial relationships. From an agile perspective, the beneficial relationship that you create should only be beneficial based on your knowledge right now. Tomorrow your knowledge changes, so the relationship may not be as beneficial as yesterday. Time to change.
Building infrastructural architecture independently of functional requirements…
I am not convinced of the benefit of this approach. In my limited experience, every business need defines the constraints or needs of the infrastructural architecture. I find it hard to find the point of departure, yet there is a school of thought that suggests that function is orthogonal to the architecture. Perhaps I just don’t understand this. However from an agile perspective, I want to release early and there are many constraints on infrastructure from the business (for example, administrative processes like procurement of hardware). I like to understand what these are early on, reach agreement on what we can release at the earliest and design accordingly. Perhaps the first release is on lightweight infrastructure and that means we “limit” scalability. So, I don’t design for beyond what I know is real.
Model Driven Architecture …
My view is more philosophical and abstract. What is a model? For me, a model is something intangible. It is a way we understand something. But we represent our models in many ways. Through words in written or spoken conversation, in unstructured pictures, in structured notation like UML, even code is a representation of a model.
What do we mean by driven? I view it as a something that takes an input that produces an output. In this case, we take an input, the model, and produce an output, an architecture. So, I take an understanding of problem and use that to derive an architecture. So, that’s nothing new here. However, I don’t like to confuse driving out an architecture from a representation of the model. That’s different. Now we are going beyond thought processes into mechanical processes. Then the challenge is about how to apply the feedback to the representation of the model – and that is what will make you agile. Too much for my small brain.
Plumbing …
Yup, we do too much hand crafted plumbing! It’s something that we have been working on for a long, long time. I think convention over configuration, dependency inversion, meta-programming are all attempts at addressing this problem. Some early success that I have experienced is on taking a polyglot approach. I am not talking about mixing general purpose languages on one runtime only. I am also including domain specific languages. I’ve had some early success where using DSL to describe functional intentions and then generating a large portion of the plumbing. Where I’ve suffered is when I mix concepts from different domains. There is the domain of plumbing and the domain of the business. Whenever I’ve mixed the two, it pains later rather than sooner. Right now, the only way I’ve had some success is with aspect orientation and meta-programming.
@StatelessSessionBean …
Chris Naidoo is right. That thing called J2EE and subsequent versions is just horribly broken. It’s broken encapsulation and a whole lot more. The fact that we now must use an annotation and not implement an interface is immaterial. Both result in the same pain – mixed concepts (see plumbing above). Annotations should be specific to the business such as @RecalculateCostsOnRerouteOfCargo can be used as an interception point for injecting a rule on a class or method.
I would go even further and say that the POJO JavaBean specification is also broken. Why on earth must I have a no-argument constructor and accessors and mutators.
Last thoughts …
I may have missed some of the other discussions but these are the ones that I woke up with this morning. In general, my observation is that we need to be very concrete very early if we want to be agile, even in architecture.
Resurfacing Diversity Challenges
I got a tweet from Clive Seebregts which pointed me to an InfoQ article that made reference to an old Hanselminutes podcast that I did. It’s nice to see that diversity is not being left in the wilderness and that other people are thinking about it again. It seems like some people are trying to promote diversity and others are trying to manage the challenges of diversity. Hmmm, somewhere there is point of brutal contact, but it will be for the good.
BTW, digging around on material diversity in agile teams I came across this video. I didn’t know it existed at all. Suddenly, the references to the FIFA 2010 World Cup seem sooooo dated.
Modeling out Loud Deep Dive
For those of you that attended the Modeling out Loud deep dive at the S.Africa Scrum Gathering today, here are some things that I discussed. It’s in no particular order, and it only makes sense if you attended the session.
- BDD Stories that are authored outside the team contributes to a hand-off which influences design decisions.
- Because we understand something does not mean that we know how to design it.
- Be aware of when you are analysing and when you are designing.
- Be concrete and abstract late.
- Use the scenarios to close the loop with product owners, stake holders, etc.
- Developers should write BDD stories and scenarios.
- We are less ignorant at the end of the sprint than at the beginning.
- Use code to close the feedback loop for your story.
- A story and it’s scenarios can be a representation of your model, just like a picture, UML, test code, production code.
- Seek out the behavior and express intentions.
- Use the value statement to explore alternative needs.
- Product owners should not write BDD stories
- Recycle stories if there are scenarios that you cannot commit to.
- Keep out the technical jargon. The moment you get technical, then the story shifts to an implementation.
- Evolve and accept that it is ok to change … your story, your scenario, code, anything.
- Login is not a story
There was a lot more which we all discussed, so feel free to add what you got out of it as a comment for others to grab.
The slide deck which contained the code example is available at http://bit.ly/bhNkvQ.
And lastly, thanks for joining in. I sincerely appreciate you making the time.
Remember that writing stories is a really difficult thing to learn, because is design is hard. Persevere.
Trust Everything
Trust has popped up in so many of my conversations recently. It came up at home, at a new school that Lia will be starting next term, in the DDD course that I gave earlier in the month, in Peter Hundermark’s scrum master certification course. And I got a one line email that said this.
The entire world lives on trust. Every aspect in life moves with trust.
The more I think about situations in life that will prove this statement false, the more it seems to hold true. Even in design it holds true. Your most fundamental architectural decisions are based on trust and the implementations of that architecture work because of trust.
It’s true for code too. If you don’t trust the code on which you build or depend, then you might as well write everything yourself, and give up your place on your team.
I was thinking about the AOP with DDD tutorial that I will be giving at OOPSLA this year, and this trust thing came up. Here again, aspects and the classes into which they get woven, need a trust relationship. It may seem like a stretch to make that statement, but I think it holds true again.
So, how do you gain trust? I am not sure, but I think you have give up something first. Maybe you need to show your vulnerability first, then it becomes easier to let someone into your space. Then, perhaps, they will let you in to their space too. When ego walls are erected, then trust finds it hard to grow. By ego, I don’t mean arrogance, I mean awareness of your self that you hide from others for fear. Perhaps, it is only when you show your true interface, that the other will worry less about hidden agendas.
In code, trust lies in interfaces and types, not in implementations. It’s really about trusting the implementation that makes types worthy. When you trust the type and send it a message and it behaves as expected, then you trust it. If you request something of an abstract type and the message was received by an instance of a subclass, then you expect the subclass to behave like the abstract type. You don’t hope that it does behave consistently, you trust that it does!
Trust is tied in with ubuntu too. You can’t be part of a community nor allow yourself to be defined and shaped by the people around you, if you can’t trust them. I think ubuntu coding needs trust as one of it’s values. It’s already a value in XP, and Scrum, and families. It needs to be in teams, and organisations, and communities and nations too.
Behaviour Driven Development at Cape Town Geek Dinner
Earlier this year I got to hear about Behaviour Driven Development from Dan North at the Software Architecture Workshop in Arosa, Switzerland. Since then, I’ve been using BDD to various degrees on various projects, and I have to say that it works for me.A few nights ago, I presented BDD at the July GeekDinner in Cape Town. I had no idea how this approach will be received, but I was quite surprised by the interest and chatter that I had with others after the talk, especially around rbehave. I wonder how the conversation would have turned out had I used JBehave examples instead?The rest of the GeekDinner was, as always, an interesting mix of techie, geeky things. Jonathan Hitchcock has a nice wrap-up of the evening.Download my presentation here (PDF format).
Geek Dinner
A colleague of mine, Anne Botha, gave me a heads up on the Geek Dinner that’s happening in Cape Town on 28 May 2007. It’s been 2 years going on 3 living in Cape Town, so maybe it’s time to join the geek crowd. From the blogs about past dinners, it seems to have a good balance of high quality techie talks and social networking. It will be interesting to see how this compares with the Software Architecture Workshop (convened by Jimmy Nilsson) that I attended in Arosa, Switzerland earlier this year. Jimmy’s event was over over three or four days as compared to one evening. I have a feeling that the tech talk at GeekDinner will be of equivalent quality to that at SAW.
f3yourmind 