Friday, August 11, 2006
[Update] My blog HAS MOVED to a new location:
URL: http://www.claudioperrone.com/blog/
RSS: http://www.claudioperrone.com/blog/xml/rss20/feed.xml
Getting to Denver hasn't been easy at all. The flight to Chicago has been delayed for several hours and as a result I missed my connection.
I finally managed to get to the hotel in Denver at 11:30pm local time and, although I was in a terrible state, my body just refused to fall asleep.
In the morning, I met Erik Doernenburg at the lobby and together we drove back to the airport to join Niclas Nilsson, Arjen Poutsma and Mike Roberts.
With the exception of Mike, everybody else is a survivor of the expedition to Cortina early this year so I'm sure that Jimmy Nilsson (who co-organized the event in February with Andrea Provaglio) will be proud of us.
With two cars available, we finally started our trip to Crested Butte and I took the chance to know a bit about Mike's work, my co-pilot in this circumstance.
Given his involvement in the development of CruiseControl.NET, it was natural to talk about software configuration management systems and the possibility of using Windows Workflow in this context.
We also went to a bit of discussion on the topic of graphical languages and code generation.
Considering my background in electronics and my experience in automation where graphic languages have been successfully used for years, I'm often surprised to see how much resistance I encounter on the subject.
The future will tell if finally some form of model-driven development will reach the maturity and the widespread adoption that I believe it deserves, but it is clear that a lot of people are currently very sceptic or quite simply indifferent.
Code generation is another controversial subject as many see it as a workaround to a fundamental issue with code intensive frameworks and languages.
I'm certainly keen to explore both subjects in the next few days.
Driving to Crested Butte is quite an experience as the scenery is absolutely breathtaking.
In fact, since we reached an altitude of about 3900m, the body requires a bit of adaptation. We kept drinking a lot of water to avoid dehydration, which apparently is the main enemy in these cases but I must say that at some point I really started falling into pieces given the combination of jet leg, lack of sleep and scarcity of oxygen.
After 7 hours (yes we took it very easy) we finally reached our final destination, a fantastic house that Niclas booked for all of us a few weeks ago.
Finally, we ended the day into Bruce Eckel's house where some of the other delegates convened for a little party. I was pleasantly surprised to see Philip Nelson again, another friend from Cortina. We had some little "geeky" conversations but quite honestly I was so tired that I doubt I made any meaningful contribution.
Tomorrow I will hopefully be able to describe what happened the following day, during the official opening of the workshop.
Monday, May 08, 2006
Writing about
muffin morning was fun, perhaps because our current sessions are very enjoyable.
As I will gain more understanding of the forces at work and the wide implications of this simple practice, I will update the pattern with the new findings.
By the way, if you are implementing it (or considering putting it into practice) within your team please share your thoughts!
For my future reference, I want to add a few points that I haven’t covered in my previous post, mainly because a pattern should be based on
observations rather than
speculations.
So what did I leave out? Many things for sure, but for now I only have this list:
- Environmental factors conducive to this type of activity
- Relations/interactions with other practices, for example daily stand-up meetings
- Higher management perception/acceptance
- Pressure/deadline handling
- Basic financial support and equipment
- Team size/composition/roles and correlation with volunteer availability
- Finding engaging topics on a regular basis (experiences on the job, technology/product/process, dept vs. breath of coverage)
- Format (lecture, open discussion, study group, etc)
- Time management (preparation phase, delay, overtime, rescheduling, recurrence)
- Session/topic follow-ups
- If/why/how-to involve other teams
In all the cases I just mentioned, I either don’t have the problem or I don’t have conclusive data, solutions or suggestions. At least, not yet :-).
Tuesday, August 08, 2006
I feel a little bit strange writing a post after such a long time. Some say that a blog is like a shark: it has to keep moving all the time to stay alive; I'm afraid the shark is long dead.
I often wonder how certain people keep up writing so often and consistently. Does everybody else have so much more time and talent than I do?
Of course not. It would be such a self limiting belief that I just refuse to consider the thought.
Some people are fast writers; clearly I don't belong to that category, which is pretty peculiar considering that my very first job was as technical writer! (That was a long time ago, before I managed to decisively follow my heart and start earning a living in software development).
Sure, expressing my thoughts using a foreign language is slightly less immediate, but the more I think about it, the more I realize that I really find the act of writing only moderately pleasing and tremendously painful.
In fact, I find so hard to choose the right words, that in the process my entire body often saturates with anger and frustration.
I get grumpy, my beard grows twice as fast and only my cats dare to stay close to me :-).
My wife once said that she would divorce immediately if I ever dare writing a book. She was joking, but it should give some idea of what I'm capable of becoming.
So why am I writing today? Well, there are things I just have to report.
I am now flying to Colorado since I am one of the few lucky delegates of this year's software architecture workshop in Crested Butte, a beautiful place right at the heart of the famous Rocky Mountains.
I will certainly meet some old and new friends in the next couple of days and I'm sure you will soon wish you were there as well.
Stay tuned!
Friday, April 28, 2006
How do you create a strong, positive culture within a team/organization? I considered this problem several times throughout my career. In fact, I think about it all the time.
At some point in my life, my habitual focus on self-improvement gained a whole new dimension as I realized that I could achieve something really amazing only with the synergistic cooperation of others.
I mostly owe this framework of thinking to Stephen Covey: his seminal book, The 7 Habits of Highly Effective People, played a major role in my quest for personal growth.
As developers, we are used to consider software development in pure technical terms: we focus on various technologies, we master the tools and we improve the processes.
While all these elements are very important, there is one fundamental omission; we often forget about the people we work with.
No, I'm not referring to the resources we allocate in a project plan; I'm rather thinking about individuals like you and me, with their cultural differences, their talents and the ideas that they bring, the ones with their struggle to keep up with endlessly evolving technologies, but also with their pride for a job well done.
I recently had a conversation with a developer who told me that people have to earn his respect and trust. He was pretty surprised to hear that I assume people are totally trustworthy unless proven differently over time.
I can understand his point of view. It is the result of a self-preserving mechanism that is unfortunately very common in too many corporate environments; in fact I, for one, have been poisoned by years of the worst corporate (anti) cultures, witnessing people fighting against each other on a daily basis; it’s within enterprises after all that I learned terms such as deception, hidden agenda, blame game, scapegoat, etc.
It does not have to be like that, however.
It takes incredible courage, passion, openness, integrity, determination, respect. These are the same core values that Covey taught me, values I firmly believe in.
Incidentally, I can also argue that these are the same values at the core of all agile methodologies, with their emphasis on individuals and interactions.
As a team leader, over the years I tried several times to become a catalyst of change by helping others to give their best and genuinely succeed in their careers.
I've been told more than once that my culture of openness is risky, that it will bite me back hard some day; I'll keep taking my chances despite the cynical remarks and the unavoidable failures, thank you.
Today, I'm happy to observe that the InnerWorkings' ecosystem shows more than a few traces of this culture almost everywhere; our thriving daily standup-meetings, internal forums, pair programming efforts, weekly muffin mornings, etc. are a testament of a social culture that is expanding well beyond my wildest dreams.
So, how do you create culture? I'm afraid I don't have the complete recipe. In fact, I can't even take full credit for what's happening in my organization.
But I have one certainty: you too have the power to make a fundamental difference in your organization, your career, your life.
All it takes is courage.
Wednesday, May 03, 2006
At the software architecture workshop held in Cortina last February, JC Oberholzer mentioned that he has been doing a special meeting on a weekly basis for the last three years, with the aim of sharing technical information and improve the morale of his team.
In the past, I thought several times about doing something similar but I was never quite sure it could work out in a sustainable way; JC's example, however, inspired me to try it here at InnerWorkings and, after successfully testing it for almost three months, I can certainly announce that not only it works for us, but it’s becoming part of our DNA!
Would you like some details?
Ladies and Gentlemen let me introduce you a half-baked (bun…oops…pun intended…ok stop!) pattern that you will never forget:
Muffin Morning
Software developers mature distinct experiences and learn technologies and techniques that can be relevant to others in their team.
How can I share technical information across a team/organization and encourage a healthy self-learning culture?
The most effective developers generally invest a significant amount of their own time researching new technologies, seeking optimal solutions to problems and continuously improving their skills; this is hardly surprising given the rapid transformations that the software industry imposes.
What is needed is a way to encourage team members to share technical information with others.
Volunteer to illustrate and debate a technical topic relevant to the team on a regular basis. Encourage others to do the same by keeping things simple and very informal. Meet for an hour every Friday morning without exceptions, and provide muffins, doughnuts, coffee, etc.
The most important thing to keep in mind with muffin morning is that if presentations become too formal, too long or elaborate, few will be able to contribute as it will require too much preparation; a team deadline could easily break the regularity of the event and muffin morning would become nothing more than a failed experiment.
As a consequence, PowerPoint slides should be absolutely banned and the urge to show live code examples on a projector carefully considered.
I personally find that the most successful presentations are the ones that use a whiteboard only, as they encourage a greater dialog and instigate curiosity to find out more about a particular topic.
One of the biggest attractions of muffin morning is its capability to involve several team members in a communication and self-development exercise.
Independently from their presentation skills, volunteers are almost invariably cheered and supported by the rest of the team since they earn the respect of their peers for their courage and effort.
While volunteers have usually enough interest and understanding of a topic to be able to illustrate it to their peers, it is not expected for them to be experts on the subject. Indeed, often some other team mate may happen to have more experience or knowledge about the subject and consequently play a supporting role for the event.
Monday, March 20, 2006
In this post, Paul Gielens mentions the article "Design and Implement a Software Factory" published with the new issue of the Architecture Journal magazine.
The article describes Microsoft’s progress in developing a proof of concept of a factory in the healthcare domain. It is definitely worth a read, particularly if you are (as I am) struggling to find a real, or at least realistic, example of a factory schema.
On a related note, you might have missed Ron Jacobs' ArcTalk interview to Jack Greenfield and Mauro Regio on the very same subject; the interview serves as an introduction to the HL7 project and to the whole concept of a software factory.
Towards the end of the talk, Mauro gives some comments about the perceived loss of developer creativity that switching to a more "industrialized" process seem to imply. Well, I totally share his view that creativity is not gone at all, but simply repurposed to solve new and more interesting problems.
A while ago, I showed to my team an early prototype of a very simple domain-specific language that I wrote which will be part of a product line that we are building.
To be honest, there wasn’t much to it; after the quick demo, however, one of the previously skeptical developers looked at me with evident surprise and said:
"Claudio, now I finally get it! You are going to remove the boring parts of my job".
Yes I am, buddy... yes I am :-).
Sunday, March 19, 2006
Last week Jimmy Nilsson expressed his growing dislike for today's overuse of XML, particularly when conceived as a surrogate programming language.
I really share Jimmy's concern, especially when I think about the XML abuse I've been subjected to while creating languages and recipes using the Domain-Specific Language (DSL) Tools and the Guidance Automation Toolkit (GAT).
On the other hand, I recognize that it is totally unfair for me to complain; this is, after all, the price we pay for dealing with prerelease software.
In fact, the DSL Tools team already announced that will soon provide us with a modeling language able to deal with the .dsldd file and hide that ugly XML from our sensitive eyes.
I haven't heard of announcements regarding similar improvements on the GAT side, but I choose to be optimistic and wait for new developments.
Unfortunately this problem does not affect prereleases exclusively; released software, both closed and open source, is not immune either.
Let's face it, it is far too easy to define and process a language using XML for not taking advantage of it; in a not-that-distant future, however, I have no doubts that we will look back and laugh thinking about how we put up with manually dealing with its angle brackets notation on a daily basis for all these years.
Apart from really extreme cases such as XSLT, perhaps XML-based build languages of the likes of Ant, NAnt and MSBuild are among the most obvious and discussed examples of how a good idea can turn nasty when scenarios get a little more complex than anticipated.
Martin Fowler already suggested that today's enterprise applications require pretty sophisticated builds which are better handled using a full-fledged programming language.
Last year, he also wrote an article about his explorations using Rake, a build language based on Ruby. In a nutshell, using an internal (text-based) domain-specific language such as Rake enables developers to easily switch to the external general-purpose language (Ruby) whenever necessary.
But how sophisticated can builds be? To put a little bit of perspective into things, let me tell you that for more than two years at InnerWorkings we have adopted a continuous integration solution based on CruiseControl. NET and NAnt; unless you've read Jimmy's brilliant manuscript of his upcoming book (in which I was honored to make a small contribution as guest author) you will be surprised to hear that we manage to automatically and continuously build, obfuscate, package, test and deploy several hundred .NET solutions.
While I think that we have done more than a reasonable job at maintaining a good degree of modularity and reuse in our XML scripts, our tolerance to NAnt's notation has been tested several times.
Resorting to a DSL written on top of a full programming language as Martin suggests would definitely help, but I have the impression that a purely text-based language may still be rather inadequate at solving one of the issues that we often face, particularly when dealing with many scripts in parallel like our scenario requires: lack of run-time visibility about the progress of each build.
Do I have a viable solution? I'm not sure, but I speculate that it won't be long before we will see the raise of a new generation of continuous integration systems built around the upcoming Windows Workflow Foundation, with steps defined using domain-specific activities.
What do you think? Is it a daft idea?
Sunday, March 12, 2006
Despite the fact that you probably haven't noticed or cared, I want to apologize for my lack of posting in the last few months.
Sure, I've been extremely busy, but in many ways I feel like I've been a horrible member of our software community, unfairly learning without sharing my findings with everyone else.
So here I am again, promising that I will try to contribute more in the future with the hope to encourage others to do the same.
There are several things I feel I should write about (including the amazing software architecture workshop that took place last month in Cortina d'Ampezzo, Italy) but today I will just mention the more recent Microsoft Architect Forum 2006 which was superbly organized by Bill O'Brien here in Dublin.
I really couldn't miss the full-day event since Beat Schwegler and Ingo Rammer were set to dig deep into a topic that I simply can't afford to ignore these days: Software Factories.
Beat and Ingo were excellent in articulating Microsoft's vision of how to combine model-driven development, guidance, frameworks and tools together with the objective of creating one or more product lines able to systematically exploit commonalities among the members of software product families.
Bill has kindly made available all the slides in this post so I won't go into the details of each session.
During his analysis, Beat emphasized that we should consider that, in many cases, up to 70% of the cost of a software project goes into operations rather than pure development; as a consequence, he recommended that we should start adopting model-driven development not only for code generation, but also for requirements, deployment, configuration, and, more generally, for all other activities that are involved during the full lifecycle of a project.
While in principle I don't disagree with this thought, today I find quite unlikely that different stakeholders (business analysts, network engineers, enterprise architects, solutions architects, developers, security specialists, QA testers, etc.) would accept to use the current incarnation of tools and designers and be confined to one single hosting environment, namely Visual Studio Team System.
But hey, in fairness we are talking about a medium-to-long term goal here, so I will surely change my mind on this point whenever Microsoft (or I :-)) will get there.
Ingo was really impeccable throughout the day and used several examples to illustrate the capabilities of the DSL tools. In one specific instance however, I could not help but notice that the version of the domain specific language that he used did not provide a particular option he needed for his demonstration; he then resorted to manually modify the generated code to accomplish his objectives. Tut-tut Ingo, you are not supposed to do that ;-).
I know I know, it was just a demo, and I really sound way too fussy.
It would be good however if somebody out there explained that, in the real world:
- We obviously cannot modify code once generated since the DSL models will diligently overwrite everything at the next transformation; as a consequence:
- Put a comment header in each template to explain that "This code has been generated by a tool…do no modify…etc."
- Do not put the generated code under source control. That code is a dispensable artifact. Put the designer file and the templates under source control instead.
- Modifying a template is clearly a better option, generally however:
- You need to put it under source control
- You need to deploy it in a centralized location so that it can be shared across different applications in the same family
- A change in the template may not be done lightly as it could easily break all other existing solutions that use the same template.
- You need to unambiguously identify the version in use (you may put a version number in the header of even resort to change file name if changes are substantial and break existing applications that use it)
- A change in the template that breaks existing applications may trigger the beginning of a new product line, particularly if you can't accomplish 100% code generation of a solution and you can't afford to retrofit all the existing solutions.
- If we are unable to build systems that achieve 100% code generation (which happens if the degree of variation in a product family is not completely known):
- We need careful guidance (patterns) to understand how to happily write manual code beside generated code. How do we create the extension points? What do you put in the underlying frameworks and what do you keep in a template? Who should make the changes in the first place? Is it up to us to rediscover these tricks over and over? Sure we can use base classes, template methods, etc. But no, the one-size-fits-all solution of using partial classes does not work all the time (wake up people, we often deal with xml files with little or no control on the reader...has anyone heard of the app.config file for example?)
- There is an evident abstraction leak as developers need to appreciate the generated code as they are going to write beside it and even debug it if necessary (tip: keep templates "thin" by leveraging rich frameworks instead). By the way, the idea that the "smartest" people will write DSLs and templates while the others will just use them is flawed in my opinion, but I will definitely save an explanation for another post.
I'm exhausted already and I'm aware that this list is far from complete; and I haven't even started talking about how I see we could version a domain specific language or an entire product line using the current tools. Or maybe I should attempt to figure out how I would assemble effective teams within this new paradigm. Has anybody discussed yet how to deal with developer's natural resistance to model-driven development? How should we address their concerns of domain-restricted job specialization and the rightful dislike for anything that contains the word factory in it? Or has everybody agreed that this is not an issue?
As often happens, the real problem is that the tools are getting there, with their capabilities and limitations, and we really need to go beyond the simple APIs to be good at using them.
But perhaps it is unfair to ask a toolmaker to tell us out how to excel at using those tools.
After all Mozart wasn't a piano maker, right ;-)?
Tuesday, October 10, 2006
My blog HAS MOVED to a new location:
URL: http://www.claudioperrone.com/blog/
RSS: http://www.claudioperrone.com/blog/xml/rss20/feed.xml
I want to publicly thank Paschal Leloup for being so kind to host my blog at developers.ie for all these years.
In fact, I want to thank him once again for all the work and energy that he has put in the past to create what is now a vibrant developer community here in Ireland…
For the rest of you guys, please update all your blog readers.
Now that I have a shiny new blog, (perhaps) I will find enough enthusiasm to bless you with some more posts :-).
Thanks and see you there!
Sunday, November 13, 2005
Today I'm finally breaking radio silence to express and share with you all my joy as InnerWorkings has been honored with the prestigious "New Company of the Year" software industry award by the Irish Software Association.
On Friday night I attended the formal ceremony together with four colleagues from the management team. Hundreds of people, including politicians and personalities from the software industry were rigorously dressed for the big occasion.
I was particularly nervous since the week before I was personally interviewed by one of the judging panels together with Fran (our CEO).
I already considered it a privilege to be short listed for both the "Technical Innovation" and the "New Company of the Year" awards, but given the names we were up against, I thought that our chances of winning were realistically slim.
At the risk of sounding clichéd, I want to give my personal congratulations to Fran and all my colleagues in US, Canada and Europe, who are delivering on a very audacious vision conceived less than three years ago. We still have lots to learn and improve, but InnerWorkings truly represents an unstoppable creative force and I'm proud to be part of it.
Finally, I want to express my sincere gratitude to the R&D team I lead and serve.
Guys, you are the most talented team I have ever worked with.
Thank you, thank you, thank you!
Monday, August 08, 2005
[Update] My blog HAS MOVED to a new location:
URL:
http://www.claudioperrone.com/blog/
RSS:
http://www.claudioperrone.com/blog/xml/rss20/feed.xml
Last week Eamon O'Tuathail of Clipcode released a Domain Specific Language (DSL) for some of the Gang of Four design patterns using the Microsoft DSL Tools for Visual Studio 2005.
It is indeed a very remarkable proof of concept and although the implementation is still pretty rough, it represents a valuable model for discussion and learning.
Eamon is very active (particularly) within the Irish community and he is a regular speaker at the Irish .Net Developer Alliance (INDA) events where I often see him.
I briefly talked to him last night as we both were present at the excellent Roy Osherove's talk on agile development and unit testing best practices.
Eamon told me that he only spent a couple of days developing it; this is something I consider rather impressive given the premature stage of the supporting tools currently available (I bet that his superb documentation took him more time to develop ;-)).
The DSL designer currently allows setup and code generation for five patterns:
- Abstract Factory
- Builder
- Factory Method
- Prototype
- Singleton
Overall, I liked the organization of the code templates in the debug solution, as they are neatly located in a common folder and are referenced only through the ClipcodeEngineTransform.ReportTemplate file which acts as a template controller for all the instantiated designers.
Besides some understandable limitations of both the language and the underlying platform (i.e. the DSL Tools) that will be undoubtedly addressed in future releases, my main interest (and point of concern) lies in the level of abstraction of the model.
Using the language to generate code that realizes a pattern is pretty straightforward as the designer diligently constrains allowable classes and connections.
However, my worry is that, in order to realize a pattern, you need to select every single participant (class/object) from the toolbox and manually connect it to the permitted collaborator(s). As a consequence, you end up creating a diagram that matches quite closely the classic UML representation of each pattern. But do we really need to visualize the structure of a pattern?
As my exploration of the Domain-Specific Modeling (DSM) world progresses, I'm more and more obsessed by the idea that if we want to create the biggest ROI, it is essential to push our models towards a level of abstraction that is significantly higher than the level at which code statements and classes are written.
In other words, a one-to-one mapping between a class created in a diagram and a class generated in code does not generally save enough time and I would dare to consider it an anti-pattern.
A symptom is that the toolbox is generally filled with lots of different elements even if the main concepts (in this case the GoF patterns) are more coarse grained.
So here is a challenge that anyone interested can take. In order to realize an abstract factory, I should need to drag only one class on the designer (e.g. AbstractClassRealization) and setup its participants (AbstractFactory, ConcreteFactory, AbstractProduct, ConcreteProduct) using compartments only. Is it possible? I guess so. I will try soon anyways.
By the way, if you think about it, a GoF pattern is still at a pretty low level of abstraction. In fact, it is the very essence of an OO pattern to address recurring cross-domain concerns. So a "real" DSL may still be built on top of it and possibly provide an even higher return of investment for your organization.
Sunday, July 10, 2005
My good friend Marcus Mac Innes is just back from Amsterdam and posted a lucid report of what he saw at Tech-Ed Europe.
His apartment faces our offices in Dublin, so it is natural for us to occasionally meet and share some ideas.
I can't wait to have a chat with him again over a good cup of (Italian :-)) coffee!
With Marcus I often talk about many topics, but lately SOA dominates a lot of our conversations.
I'm actually very surprised to read that about 60% of the audience claimed to be currently building SOA based applications.
I suspect that a lot of them are simply creating basic web service façades over their existing applications.
That is so !SOA.
Friday, June 10, 2005
Wednesday’s session about the DSL tools for Model-Driven Development in VS2005 was truly fascinating. Actually, I think that it justifies the investment of my trip across the Atlantic alone!
After illustrating that domain specific languages are ways to improve effectiveness in communication, Jochen Seemann literally blew my mind by demonstrating what can be done today with the CTP release version of the upcoming Microsoft Domain-Specific Language (DSL) Tools.
This SDK allows you to easily build a graphical designer hosted by Visual Studio 2005 that is able to provide support for a custom domain-specific language.
What does it mean? Once the designer is built, a user can instantiate the designer, drag custom shapes from the toolbox, connect those shapes together (with validation support according to the language rules) and use the template engine to generate code/artifacts!
Building a DSL designer requires several steps, which basically involve the definition of:
- the elements of our domain in a domain model (classes and relationships)
- the notational elements (shapes and connectors) for the business entities
- the legal rules (validation/constraints) from a notational perspective, and the mapping of the notation to the elements of our domain.
Once the designer is built and instantiated we can use template-based generators to generate artifacts from our model (e.g. code, HTML, XML, WordML, etc). The templates have a notation similar to CodeSmith or classic ASP, and in the future some form of Intellisense (to query the model) is likely to be provided.
Some of these steps currently require the editing of an XML file. However Jochen said that this is really an “alpha” version of the toolkit and that better support will be provided in further iterations (indeed, the textual generator engine, code named T4, is only 6 weeks old!).
He plans to release incremental versions of the toolkit every 2-3 months, maybe even after version 1.0 will be shipped.
Currently I have only a few random observations/considerations on DSL designers that I want to dump here for my reference and eventually refine in future posts as I become more experienced in this field:
- We can build multiple designers to generate different parts in our systems, so we can (and probably should) start small.
- 2-Way synchronization (e.g. graphical model – to generated code – back to graphical model) is probably not going to be provided with version 1.0. It is a difficult problem to solve and I agree with Jochen's pragmatism that it would be a fundamental feature only in a relatively small number of cases.
- Template/designer versioning and deployment are going to be difficult issues. We will need a defined structure and guidelines to avoid dealing with a total mess.
- A DSL designer is likely to work effectively in areas when the domain entities are very well understood. I can see how the use of a ubiquitous language would be core in this context.
- DSL designers could be used for requirements; however I have some reservation in this direction as the domain model is likely to be refined and changed way too quickly in a real world scenario. Use cases, CRC cards, and UML drafts are still likely to be my preferred option in the short term. I might be totally wrong on this, and I hope somebody can change my ideas soon (any volunteers?).
- There is a space for graphic tools and a space for code. A guy asked if Microsoft was going to provide basic notational elements that would give us very fine grained control capabilities (ifs, whiles etc). I think that writing code using shapes is insane. This is not a new idea (companies have been trying for years to propose solutions in this direction) but when you get pages and pages of icons you quickly realize that you are in the wrong space.
- Code generation driven by a designer is very cool. However writing templates is a pain and it feels like going back to messy scripting languages.
- Aspect Orientation could have a major role in this type of development. You add an attribute to a shape and (with the right template) your code magically gets to be generated. Jochen is not totally convinced by the feasibility of the AO approach as many people got burned. After talking to the guys in Avanade, however, I’ll be willing to take a serious shot in my problem space.
- It will be fundamental to maintain a clear separation between generated code and custom code. Use of partial classes that can be regenerated would be an option, separate classes and aggregation/inheritance another.
- I wish we could have several injection points in the designer and even a link to MSBuild, so that separate tasks could be executed upon code generation.
I hope this post gave you a sense of what this technology can provide. As I said at the beginning, I’ve been totally fascinated by it.
Finally let me just say that this technology gave me a fantastic idea that promises to provide an incredibly elegant solution to a huge problem in Innerworkings’ domain. Unfortunately I’m only teasing you guys because I can’t tell you what it is, as probably Fran (my CEO) would literally kill me if I did :-)
Sunday, July 03, 2005
Tech-Ed Europe is about to start and I join Bill O'Brian in the multitude of really envious people that would love to be there.
Instead I'm trapped here in Dublin, craving for news from Amsterdam.
I don't have any reasons to complain, really. After all, I was in Orlando just a few weeks ago.
In fact, I consider this coming event as an occasion to go through my mind maps and, once again, reflect on my recent experiences.
Bill recommended Gregor Hohpe's session on event-driven architectures.
I cannot agree with him more.
Gregor is a true expert on asynchronous messaging patterns and co-wrote what I consider the best book on this subject (Enterprise Integration Patterns).
By the way, if you believe that asynchronous messaging technologies such as Message Queuing (MSMQ) are not for you, I actually implore you to go to one of Gregor's sessions.
Maybe you will think about it next time you will wake up early trying to book tickets for your next U2 concert and the site goes down because suddenly there are too many requests that the server can't cope with ;-)
In addition to Bill's favorites, I would include Ron Jacobs's "ARC313 - Patterns for SOA". The patterns and anti-patterns described in that session are simply invaluable and I'll be certainly sharing some thoughts about them in the future.
Finally, I certainly suggest spending some quality time at the so-called Chalk-&-Talk/Cabana sessions. It is such an excellent way to meet a lot of talented people and share insightful ideas and tips!
Sunday, June 19, 2005
About eleven years ago, I got involved in the development of my first "serious" client-server application using Visual Basic 3.0 and Oracle (using a data access API called Oracle Objects for OLE).
We were a small team of 3 developers working together for several months and, to be honest, I don't think we actually knew what we were doing (well, I'm sure I didn't! :-)).
I really enjoyed those times and it certainly was a valuable experience.
Back then, I had the pleasure to work with Manlio R.
Manlio was essentially what I consider a pragmatic anti-Microsoft guy; someone who fundamentally dislikes Microsoft but earns a good living by using Microsoft technologies.
He was so funny though. Whenever we would find a bug in Visual Basic he would smile and say something like "Microsoft is only good at building nice dialog boxes; Oracle/Linux is the way to go!"
It didn't matter if our bookshelf was full of Oracle manuals as the software wasn't that user-friendly or bug-free either.
Even WinWord would not pass lightly his severe judgment as the VI editor was a way better tool in his hands.
I haven't seen Manlio since then, and we only stayed in touch with the occasional emails in the first few years that followed. Then I totally lost contact.
Manlio now has his own family and he is an accomplished J2EE/Agile developer.
How do I know? He surprisingly found one of my posts and, after so many years, he dropped me an email to say hello.
Thanks Manlio, you are the man!