# Sunday, 05 October 2008

Day 3 of JAOO was a potpourri of topics for me, everything from JavaScript as an assembly language, JavaScript for building an OS, developer best practices, and data synchronization with a shiny new Microsoft toy. If you didn’t catch my summaries of Day 1 and Day 2 please make sure that you check them out.

Five Things for Developers to Consider

Last year I attended a couple of developer best practices sessions and came away liking them quite a bit so I figured I should attend at least one this year as well. The first one this year was basically five things which Frank Buschmann and Kevlin Henney collectively considers to be important to developers.

Of all the things they pulled out of their hats I liked their points on expressiveness the most. They talked about bringing out concepts which are implied in both the architecture and the low level design of a solution; something we strive to do as well. One of the key aspects when writing code I find is that more often than not code is written once and read dozens of times which means optimizing for readability is not only a good thing to do but the only thing to do.

An example of the above are variables of type string. Usually these guys contain a lot more than just mere strings, e.g. XML, social security numbers, etc., instead of going with just the string you could go for a class of type SocialSecurityNumber which would be a lot more explicit. The little things count.

Developer habitability is a term they touched on which I quite like. The idea is that if we create nice usable solutions which are easy to understand and simple in their composition developer habitability is increased – basically the code place is a nice place to live :)

Keeping in Sync

image Two-way synchronization is a notoriously difficult challenge to solve. Mostly when I’ve come up against this thing I’ve gone for a simpler solution like selecting a data master which overrides the slaves. Naturally I was excited to learn that Mike Clark was giving a talk on Microsoft Synchronization Framework which tackles this very issue.

Sync Framework actually forms the backbone of tool you might know already: Sync Toy which sync files across the network, file system, or whatever. Certainly a neat feature Sync Framework is about much more than that. It basically enables us to synchronize our custom data stores which to me is very exciting.

Included in the box is support for all data stores which have an ADO.NET Data Provider so we’re talking all major databases here. Additionally the framework gives us rich hooks so we can grab any step in the pipeline and modify it to our heart’s content.

A JavaScript OS

Really? An OS done in JavaScript? Apparently so if Dan Ingalls has his way, Actually he’s already done some amazing work on this Sun project which aims to liven up the web by doing away with a HTML replacing it with vector graphics rendered by a  JavaScript engine.

Actually my words won’t really do it justice so instead take a look at this video; basically the entire talk. Once you’re done with that go play with Lively Kernel live on the web.

JavaScript as an Assembly Language

image Keeping in the same vain I decided to go take a look at Erik Meijer talking about his current project: Volta. Volta is a project aiming to allows us to defer decisions on deployment model to a much later point in the project than what we currently do today. The current state of affairs is pretty much that we need to decide very early in the project phase which might or might not make sense. In any event having the option to defer those kinds of decisions is always better right?

Now the part which Erik focused on is the piece which allows us to run our apps in the web without actually coding for the web. The premise here is that if we view JavaScript as a language which we can target with the JIT compiler and generate a web implementation for our app which then runs without in web specific code ever written by us a devs.

Last year Erik gave the keynote at JAOO and talked about Volta at which time I was skeptical to say the least thus it was interesting to actually see that there’s some meat on the project after all. The idea is interesting to say the least and I look forward to seeing where it goes from here.

With two “extreme” JavaScript session done I was all JavaScripted out for the day but I will say this: My days doubting JavaScript as a “serious” language are way behind me.

TDD Take 2

image One is the big topics for me last year at JAOO was test driven development so I was curious to see whether new stuff had come up in the intervening time from then to now. Giving the talk on TDD was  Erik Doernenburg. I won’t go into a lot of detail about the talk because as it turns out not much have changed in the span of a year.

What was interesting for me to note is that our work with unit testing and test driven development at Vertica has paid off handsomely as everything that ThoughtWorks, which I would describe as the thought leaders in this space (no pun intended), are doing is basically what we’ve spent the last year implementing and I’m happy to report that we’re at the point where the culture is basically sustaining that particular way of doing code.

So a year and a half ago I set the goal of become better at doing unit testing and my great colleagues have ensured success in that area. For the coming year the focus will be on builds, continuous integration, and release management. To me these are natural steps in our continued development of our way of doing things … and it’s fun too :)

posted on Sunday, 05 October 2008 21:48:05 (Romance Daylight Time, UTC+02:00)  #    Comments [0] Trackback
# Friday, 03 October 2008

JAOO-logo Day 2 of JAOO 2008 was all about architecture for me, agile architecture, architecture reviews, requirements gathering, architecture testing, and finally lessons learned in architecture, Be sure to catch my summary of JAOO 2008 Day 1 if you missed it.

Architecture Reviews

Frank Buschmann from Siemens in Germany was track host and also the first speaker of the day. I caught a couple of talks with Frank last year and it’s apparent that he knows his stuff. While hugely important the architecture talks tend to be quite difficult to follow because the very nature of the topic is fluffy.

Most of the talk was pretty run of the mill in terms of how to conduct an architecture review. I’ve never formally conducted such a review but we do do them at regular intervals at Vertica just not in any sort of structured manner. We do them when they make sense and they usually consist of peer reviews and initial design sessions.

image Most interesting to me were a couple of techniques which Frank brought to light to do á formal architecture review. It’s not something you do every day and it’s certainly not something which requires a lot of structure.

My key take away from the talk is the fact that preparation for an architecture review is essential. Basically you need to sit down and try and figure out what you or the client expect from the review as the goal will impact the process of doing the review. This highlights why we can get away we can get away with very informal reviews because our goal is usually to verify that the selected architecture.

Now the situation changes rapidly when we’re conducting architecture reviews for other companies. Here the objective is to both verify architecture but more importantly to figure out what went wrong after the fact when a new system doesn’t satisfy non-functional requirements, lacks adaption in their internal dev organization, lacks maintainability, or something else altogether.

So I took away the fact that I need to be a lot more conscious about what the client expects to get out of a review and I must admit that I’ve taken a lot of satisfaction from going in and pointing out all the deficiencies in existing systems without giving thought to the fact that more often than not systems due have something good to bring to the table in spite of its deficiencies, perceived or otherwise.

Requirements Gathering

image Next up a talk which I didn’t really know what to expect from. The talk though turned out to be one of my favorites at this year’s JAOO due to the fact that it was very different from what I’ve seen at any other conference and it covered a topic, the importance of which I can’t stress enough, Communication.

Chris Rupp from Sophist at which she is the CEO and business analyst. Before I get started with my summary I must mention the fact that she spoke flawless English; a feat I’ve rarely seen performed by a German person. No hint of accent, nothing, just perfect English.

The meat of the talk was all about understanding what your client is telling you and more importantly filling in the blanks. The premise of the talk was basically something that we’ve know collectively in the software business for a while: The client doesn’t know what he/she wants. She had a twist on this though that I couldn’t agree with more which went along the lines that we can’t expect the client to know what they want. Building software is a complex task and it’s our responsibility as a community to help our clients to figure out what they want.

Chris touched on quite a number of different techniques with which we can employ to fill in the blanks. I was very pleased with the fact that she decided to focus on just a single technique called Neuro Linguistic Programming (NLP). My very limited understanding of NLP is that it’s basically the theory of the programming language of the human mind. What I took away from the talk is that NLP might be the key to picking up subtle nuances in the conversations I have with clients. Is a sentence phrased imprecisely? Maybe the client doesn’t really know what the details should be in that particular case. Is the client using very general terms to describe a feature? That could mean that we’re lacking some details, maybe we shouldn’t really allow everybody to update everything.

As I stated my understanding of NLP is very limited at this point but I definitely see a lot of potential here so I went ahead and suggested they we get some books on the subject so we can investigate further. I’m hooked at this point no doubt about it.

Agile Architecture

image James Coplien did a talk on what I thought would be pretty standard only-design-and-build-the-architecture-you-need-right-now kind of talks. Indeed he started out like that but he quickly went on to blowing our collective minds with proposing a new style of architecture where we separate the What and the Why more clearly. Now I won’t state that I understood half of what he was saying but I got the general drift and I definitely need to look into this some more.

If I were to compare it with something I know from the domain driven design world I’d compare it with the Specification pattern on steroids but I feel that it’s a poor comparison as his ideas describe the overall solution architecture where the Specification pattern is just small bits of pieces of any given solution.

To better understand the concepts I need to see a lot more source code :) You can download the pre-draft book which James is writing on the subject I think you’ll enjoy the new ideas a great deal.

Software Architecture and Testing

…. zzZZZzz…. nuff said.

Top Ten Software Architecture Mistakes

Needless to say I was not in the most energetic of moods having sat throught the snooze fest which was the previous talk. The guy in front of me must have agreed as he actually nodded of there for a while during the testing talk. It was actually pretty entertaining watching him do battle with very heavy eye lids, the mightiest of foes :)

image At least Eoin Woods (cool name or what?) took up the challenge and turned the whole mess around at the next talk in which he discussed his list of top ten architecture mistakes. Being in the last slot of the day is no easy task but he manged to get the entire room going, lots of laughs, lots of good stories, and lots of good information.

His talk basically served to highlight some of the mistakes that we’ve all made and continue to make from time to time. I believe that talks like this are invaluable as they serve to keep us mindful of at least some of the pitfalls of software architecture.

I liked that fact that this talk contained nothing but concrete examples and real world tips and tricks which we could take home with us and use. My favorite take away is to always have a plan B. I think most good architects subconsciously have these hanging around but I like the idea of having plan B be very explicit. It helps the the team if and when to enact it.

Just formulating plan B and sticking it into a document to me is hugely valuable; it gives you pause and helps you think through plan A and ultimately helps build trust as the customer ultimately gets a better solution and should, God forbid, plan A turn out to be a dud we’ve got something to fall back on. Having plan B be visible leaves more wiggle room for the client and I firmly believe that it helps build trust.

Continue to JAOO 2008 Day 3…

posted on Friday, 03 October 2008 22:33:17 (Romance Daylight Time, UTC+02:00)  #    Comments [0] Trackback
# Thursday, 02 October 2008

JAOO-logo Last year was my first JAOO experience and I was fortunate enough to get to attend this year as well. My first experience with JAOO was very positive so I was looking forward to this year quite a lot.

The Keynote

As always we started out with a keynote which this year was held by Anders Hejlsberg from Microsoft and of course fellow Dane :). Mr. Hejlsberg talked about the future of CLR languages with three pillars forming the basis: Declarative, Concurrent, and Dynamic. Interestingly functional languages like F# and new language features like LINQ seemed to fulfill this quite nicely and so played a central role to his talk.

Anders delivered a solid talk and he even mentioned a new C# keyword which we can expect to see in the next incarnation of the language: dynamic. The idea is to declare a variable dynamic to enable easier lookup of methods than what we’ve got today with reflection. Sort of like dynamic dispatch known from dynamic language but keeping everything statically typed. Powerful stuff.

Interestingly he stopped by the Danish Microsoft HQ to give a similar talk the day before from which you can watch a clip which sums up his points.

CI and more CI

image For the the last year or so we’ve been hard at work introducing unit tests and, to some extent, test driven development. By introducing unit testing I don’t just mean just introducing the concepts and seeing what happens but really have the concepts nested deeply in the way we develop software at Vertica. I’m proud to announce that we’ve had a great deal of success in doing in no small way due to my very talented colleagues and Daniel in particular.

The next logical step in this work is to introduce continuous integration, the act of building the software and running all the structured test upon check in to the source repository. Naturally I was keen to attend a couple of sessions on this very topic.

Unfortunately Chris Read from ThoughtWorks gave a very run of the mill CI talk covering the concepts and the benefits but never really digging down deep in any of the aspects. Not that the talk was bad but he simply tried to do too much in the span of a very short time which meant that he never really got around to talking about anything concrete. He did touch briefly on various client projects he’d been involved with which gave some interesting insight into the problems we might face and he mentioned a concept of creating CI pipelines which jived well with my idea of how it should work. I’d have liked to hear a lot more about actual practices, do’s and don’ts, which would have made the talk immensely more engaging.

I followed up with what seemed to be a nice topic but turned out to be one of the pitfalls of JAOO. Not the presentation itself I’d judge it to be quite useful … for Java developers. Basically it involved taking the build process a step further than Ant by introducing a scripting language on top of Ant. Powerful stuff but sadly it didn’t apply to myself.

So I talked about the pitfalls at JAOO. Basically it’s important to be mindful of the fact that you can come across talks which are heavily based on some technology. So for a .NET dev it’s probably bad to walk in on some specific Java topic and vice versa.

Cloud Computing and Insight into Google

Google App Engine Cloud computing is getting a lot of attention at the moment and frankly I fail to see why so I wanted to see if I could gain some insight into the world of cloud computing. I actually ended up getting an interesting insight into Google as Gregor Hohpe discussed various in-house technologies they employ at Google to scale to the massive size required to run services on the level which Google does.

I was fascinated with BigTable, Google’s distributed cache, which can support tuples larger than a terabyte. The Google File System was an interesting piece of kit as well as the scales to sizes of lots and lots of petabytes. While Gregor told us about the Google File System he mentioned an internal joke which goes along the lines of, “What do you call 100 terabytes of free disk space?”, “Critically low disk space”. I’m a geek so I find stuff like that funny you know :)

He did demo Google’s cloud computing service, App Engine, which basically enables us to write Python code, deploy it to BigTable, and run it from there basically allowing developers to scale apps to the same size as Google itself.

PowerShell Blows My Mind

image A while back I listened to a Hanselminutes in which Scott talks about PowerShell the ultimate scripting environment from Microsoft. Since then I’ve wanted to learn more and I jumped at the chance to see Jeffrey Snover creator of PowerShell present it himself.

Basically his presentation blew my mind. From start to finish it was all PowerShell script flowing over the screen and I struggled to keep up with everything going on.

My interest in PowerShell comes from the fact that we’re on the brink of introducing CI in our dev process as I mentioned and I figure that PowerShell will come in handy in that it’ll help us automating some of the more tricky stuff. Also it’s my firm belief that PowerShell is a technology most .NET devs will start using over the coming years as it’s simply the way to get things done or even test out small ideas without cranky up the entire VS IDE.

Form the talk my impression is that we are in fact dealing with a very powerful scripting environment, not that I actually doubted that to begin with but it’s nice to get the point hammered home from time to time. The other aspect I came away with is that there’s a lot to learn: What we’ve got is a new syntax to deal with and even more importantly a completely new mindset. PowerShell is modeled over UNIX commands where everything can be piped together to produce interesting results. A way of thinking we’re not really used to in Windows land although I feel we can benefit tremendously from.

Continue to JAOO 2008 Day 2…

posted on Thursday, 02 October 2008 22:06:02 (Romance Daylight Time, UTC+02:00)  #    Comments [0] Trackback
# Monday, 05 November 2007

Just a quick note to say that my colleague Brian is attending TechEd Barcelona 2007 and is blogging as he goes. He's getting ready for the keynote as I write this so be sure to head on over to his blog if you're interested in the stuff going on at this year's conference.


I'm very envious that I couldn't go this year too :)

posted on Monday, 05 November 2007 13:29:02 (Romance Standard Time, UTC+01:00)  #    Comments [0] Trackback
# Sunday, 30 September 2007

jaoo2007_1 JAOO is well over with and I'm just starting to get my head on straight again. I started out with my Going to JAOO 2007 post in which I wrote a little bit about why I was going to JAOO and what I expected to get out of it. In this post I'll try to answer that question and contrast JAOO with Microsoft TechEd the only other conference I've ever attended.

The conference is general felt a lot less cramped than TechEd which makes sense considering that TechEd accommodates around 4000 people while JAOO only does 1200. JAOO has a definite community feel to it, it's hard to explain but everything seems a little less tightly controlled and planned, a little more laid back if you will. Take for example the evaluation of a session: At TechEd you'd go to a computer and enter in a number of criteria to get the job done, at JAOO you place either a green, yellow, or red piece of paper to do the same. You definitely get a little less information per person but I'd wager that the JAOO folks get feedback from a lot more people than they do at TechEd. Same thing goes for the conference web site, the TechEd site is very professionally done with lots of gimmicks while the JAOO site is simple and functional. The two sites compare roughly like Hotmail and Gmail, one is pretty while the other is functional :) Now one is not necessarily better than the other, they are just different conferences with different audiences in mind. I definitely enjoyed both. One thing TechEd has going for it is the fact that they get session slides online immediately after the session is done which is nice for people like me who like to blog about the session. Essentially JAOO requires more from my note taking than TechEd does because I have the notes done for me at TechEd :)

My first reason for attending JAOO was to get a more diversified picture of software development. Naturally JAOO delivered on this in a big way. Simply put a great many of the big thinkers in OO were present at JAOO and I think it's safe to say that most of them are found outside of the .NET space. Don't get me wrong a lot of stuff is going on in .NET and in many cases .NET moves along more quickly as a whole because Microsoft controls the entire stack as it were. It was great to attend a session on enterprise frameworks and have Martin Fowler sitting right behind me asking questions of the panel. I'm glad I wasn't a speaker at that particular track as they must have felt the squeeze of having Martin Fowler present asking critical questions.

The content of the sessions was very different than what you'd get at TechEd. TechEd is basically about selling the latest and greatest Microsoft technology to the development community and while it's great to have one of the guys who actually coded ASP.NET AJAX sitting there answering questions it's still just a sales pitch. Again JAOO feels very different because we have very feel people selling an actual product. In many cases it's more about the ideas behind products than the product themselves making the content much more relevant. I'm convinced that the stuff I take away from JAOO with regards to architecture, frameworks, and methodology will be applicable in three years time while the same cannot be said about my knowledge about SharePoint 2007 and ASP.NET AJAX which I took away from TechEd last year. Technologies simply become obsolete too rapidly for that to be the case.

A couple of sessions stand out from the ones I attended: Hamilton Verissimo and Oren Eine did a couple of sessions together on the Castle project, specifically on MonoRail and ActivePack both of which were very interesting. I really like the alternative way of thinking about creating web applications and doing data access. MonoRail seems very interesting an I'd love to be able to roll it out on a project but I don't see it happening any time soon unfortunately, Active Record on the other hand might be something I can get out there soon but again a product like LINQ is something hard to ignore. The last sessions that stood out was Applying Craftmanship by Pete McBreen simply due to the fact that he presented the topic so well, he was funny and had some great points as well. Of course The Journeyman's Tale stood out as well, unfortunately it stood out like a sore thumb :)

So what is the verdict? I would definitely go to JAOO again and I firmly believe that JAOO is a conference you can attend every year without feeling that content is being repeated. For TechEd I'd say that that is not the case. With a product focus like is the case with TechEd new things need to happen with the products for the content to be different, this year and last years TechEd look pretty similar to me because not much has happened since last year product-wise. One thing I learned this is year is that with the massive amount of content you need to absorb at a conference taking notes on a piece of paper and then converting those notes to blog posts later is close to impossible. I just barely made it last year and this year I got swamped the

posted on Sunday, 30 September 2007 21:15:58 (Romance Daylight Time, UTC+02:00)  #    Comments [0] Trackback
# Wednesday, 26 September 2007

jaoo2007_1 When you are communicating with your customers you encounter the fact that you have a completely different meaning for the same words. Software craftsmanship is needed because most software is painful to use. With a few exceptions most software that people have to use as part of their job is abysmal. Corporate applications are in the dark ages and seem to be getting more baroque and unmaintainable. We need to find a better way to deliver working software that is a joy to use. Some progress has been made over the recent years but we still have a long way to go.

The concept of software engineering is nearly 40 years old. It was born in an era of optimism. Man was going to walk on the moon. No matter what the problems there was going to be a technological fix. From manufacturing it was a short step to software factories.  Factories are a great concept but it's not really a place where people need to think. Outsourcing is not successful, we're an industry dominated by anecdotes.

Standard software engineering practices seem to be designed to cause failure. Projects manager do not understand technology. "Senior developer" requires only 5 years of experience. Project plans ignore variability. Waterfall is "ideal". Testing comes last. People forget to think.

Craftsmanship is a necessary because software development is a high skill task. Talent and expertise are require to deliver software. Mechanical metaphors actuvely proven us from delivering great software that user like to use. Craftsmanship is a way to connect passion with excellence. But enthusiasm needs to be guided by experience. Apprenticeship is a traditional way of gaining mastery in many complex fields. A key part of this is to learn from other people typically from learning on the job with an experienced person. This only works for static environments because people need to agree on the content of the teachings while often the companies are pushing to get knowledge on new stuff.

We can still use the ideas from the apprenticeship programs. The basic idea is that a trainee should contribute to a real project. The best place to start out new guys is in maintenance of existing solutions because the turn over time is much shorter. We need a tool changes to allow experienced developers to review the patches before they are committed.

Too much software is  developed without appropriate adult supervision. Alan Cooper hinted at a missing role in projects, there are plenty of workers and managers, no foremen. Supervisors are a key part of most organizations. We need to find a way to retain experience and expertise. We need to encourage senior technical roles that remain active on projects. Skilled developers should not have to transition out of technical roles to advance their careers. Team leads need to take active responsibility for the quality of what their people produce. Team lead need to be very active in coaching their people to improve their skills in all areas.

The sad fact is that many people on projects do not even know the basics of their day job. Small wonder that projects are stressed. Comp sci and sfotware engineering degrees do not seem to be effective. Not a popular sentiment but how else do we explain how bad software is these days? Part of the problem is that academia does not see that is has the responsibility to train the software developers. Amusing as it may be, the open source community is much better at training than most corporations. Once key difference is that corporations do not have known individuals who are responsible.

How can we developers improve ir skills? The pramatic programmers suggested that we all learn a new language every year. Reading books and code is also an effective strategy but you have to have the attention of applying the new skills to a significant project. Working with others however remains the best way to learn new stuff. Another thing that has to change is the way we think about software. We spend too much time writing new stuff instead of improving on the existing stuff.

Software is embodied knowledge and we have to act accordingly but it is really the members on the team that matters. Multi-generational teams are a good starting point. A team of twenty somethings has a great energy but old developers bring a breadth of experience to the task. Handoff to a maintenance team never works well. The team that created the application need to stay together to maintain and create future releases. Documentation is useful but it has to be written by the experts, for the experts. Anything else downs the team in paperwork.

You need senior people in technical roles with the authority to make decisions. Managers without technical skills should be transitioned out of IT roles. Many placed have a high turnover of techical staff. Technically competent line managers provide visible evidence that development career path.

Most projects are badly mismanage. Few projects allow time to think about the issues. Project requirements are rarely questioned. Manu projects are good response to the wrond problem.

WE need project managers to report to the project lead. The person who is responsible for the success of the project needs to lead the project. Admin staff can handle tracking the project schedule. The lead needs to focus on the big picture items and whether the entire team working well?

We need to evolve our designs instead of reinventing designs from scratch. We need more continuity in our teams. That the lead architecture leaves the company should not result in a complete rewrite of the architectures. Improvement comes from spending a lot of times with users. Many ideas that look like neat fail in the real world. Initial failure is OK as long as we learn from it. Better decisions are made by practitioners.

Having deep domain knowledge means you have to ask your users. You are not your user. Especially when you know what your user needs; remember that craftsmanship comes about through humility. We can always learn more from our users. Software is meant to be pleasant to use, if it isn't we are doing something wrong. We need to commit to improve our user's day job.

Classical books that all developers must read:

Mythical Man-Month

Prgrammers at Work

Code complete

The pragmatic Programmer

Agile Software Development

Lessons Learned in Software Testing

About Face

posted on Wednesday, 26 September 2007 16:06:57 (Romance Daylight Time, UTC+02:00)  #    Comments [0] Trackback

jaoo2007_1 ActionPack is the frontend part of the Ruby on Rails framework and was derived from a commercial project 37signals did called Backpack. The guys at 37signals had an idea for a commercial project and didn't want to build it on top of the stacks common three years ago. Features are added to Rails as they are needed in commercial projects. A lot of plumbing was required before Rails at the time of its inception. With Rails 50 lines of code is reduced to 3. The change in thinking comes from going from explicit definition of your intent to implicit definition or convention over configuration as is the mantra of Rails.

Routing decides how we get from a URL to a piece of code. Routes are defined in a file called routes.rb which can be edited as you see fit. You don't have to configure routes you can go by convention alone, if you have an action (a method) on a class you can specify the path in the URL and the routing system will figure out which piece of code to execute. URLs are treated as sitename.com/:controller/:action/:id (the : denotes a variable) default and that's make makes the magic happen. Routing is basically URL rewriting. Everything is configured using Ruby, XML is apparently not something they like on the Ruby side, I kind of get where they're coming from too :)

View Context is a lot of different thing, but basically we're talking about how data from the request is accessed in the various parts of the framework. You have view contexts for template params (page scope), variables* (request), flash (something needed for a short time between redirects), cookies, no application scope.

Everything is bound together by name by default but you can override the default behavior by using the redirect_to or render keywords. Redirect sends a 302 to the browser and sends the user to a different form. Render renders a form in the same folder. render :partial is basically server side includes whereby you include one piece of UI into another.

Of course ActivePack has Filters like we were introduced to earlier in the MonoRail talk. Filters are methods that you want to be called prior to or after the action. You can use filters for authentication, authorization, logging, etc.. You defined them on the controller itself by specifying a before_filter :action. You can layer these guys to do different stuff if you need to. verify is a before filter you use to specify that a method can only be accessed through a post for example.

Rendering render :action, render :partial render :template. ERB methods is code you can use inside your templates. @ denotes an instance level property. Instance variables are automatically available to you in the view (HTML). You basically place the code inside <%%> tags like we're familiar with in good old ASP. h() HTML escapes text and u() URL encodes the string.

Formatting helpers are encapsulation of general purpose tags you can use in your HTML. You can use these for formatting dates, numbers, currency, build forms, etc.. Examples of helpers are form_tag which starts a HTML form, text_field which outputs an input, submit_tag which outputs a submit button for the form. They will create both a name and an id for JavaScript compatibility.

Layouts are the Ruby on Rails version of master pages which enabled you to get a unified look and feel for you web application.

posted on Wednesday, 26 September 2007 14:03:29 (Romance Daylight Time, UTC+02:00)  #    Comments [0] Trackback

jaoo2007_1 A software practitioner's adventures in pursuit of excellence. Being a personal account of one practitioner's encounters with fellow travelers and what he learned therefrom; claiming no particular authority or qualities, but aiming to arouse his colleague's curiosities on the subject matter. What is our work like? Our skills depend on sophisticated knowledge that your clients usually prefer to remain ignorant of. We've acquired most of your skill and knowledge through practice, imitation or mentoring rather than formal training. We work on complex projects that require a plurality of disciplines working in complementary manner. We have a professional interest in social networks.

Our work, while taken for granted, often forms the very underpinnings of your age's society. Yet we are the subject of great pressure to lower your wages, increase our performance.

What other professions read like that? Cathedrals builders in the 17th century.

Ridiculously brief history of journeyman's organizations: Craftsmen organize in associations (guilds) as early as ancient times (2000BC) in all parts of the work. Form the end of the XIth century, Europe's binge of Crusades and Cathedrals yields a body of knowledge. Trade associations rooted in the cathedral builder lore are suppressed through the Middle Ages, during the rule of associations rules from the top (bosses' associations). Clandestine worker's associations stabilize into the European compagnonnages from the XVIIth century.

Compagnonnage is a traveling worker's associations. Craftsmen pool money as mutual insurance against injuries, illness, lean times. Learning is from each other, and on the job. Societies preserve and pass on traditional skills and knowledge. Rituals , legends, and symbols structure teaching.

Industrialization and war influences compagnonnage is outlawed in France in 1791 (repealed in 1864). In parallel, industrialization and mess education compete effectively with its traditions. The two wars of the XXth century disintegrate the network of societies, leaving only splinters.

With the rapid changes of IT today structuring our like the journeyman form can be a good way to ensure that the fluent body of knowledge is passed onto new members of our profession and indeed keeping up with the changes themselves.

As you can probably gather at this point is that this session was pretty much a self promoting one in which Laurent Bossavit primarily talked about the history of the journeyman history and his own experience with the journeyman concept, getting invited into the organization, and learning how it worked. The journeyman organization to me is something that doesn't apply very much to a country like Denmark. His premise was basically that we are under pressure of lower salaries all the while being more effective is just not as big a problem as in his home country. The journeyman concept to me seems like an archaic way of organizing when we have concepts like usergroups and other community events; basically the journey man stuff seems to be overglorified version of that same concept.

So really not my kind of session and I see a lot of people agreeing with me, there's a lot of voting with the feet going on as I type this.

posted on Wednesday, 26 September 2007 12:45:19 (Romance Daylight Time, UTC+02:00)  #    Comments [0] Trackback

jaoo2007_1 I wanted to know more about alternative web frameworks out there. One such framework is MonoRail which is part of the Castle project like ActiveRecord which Oren and Hamilton spoke about yesterday.

MonoRail is a web framework which uses MVC and is built on top on ASP.NET. ASP.NET != WebForms. WebForms technology is built on top of ASP.NET like MonoRail and includes ViewState, life cycle, page structure, etc..

MonoRail was inspired by Ruby on Rails' Action Pack. It's not a direct port, however, it has its own identity and is not opinionated like is the case for Ruby on Rails. The mail goal of MonoRail is to separate concerns and getting rid of repetitive and tedious code. Controller => Model => View => User input => Controller.

Like with ActiveRecord a wizard is triggered when you create a new MonoRail project, also including the test project for TDD purposes. A lot of stuff is generated when you create a new projects just like you'd see in Ruby on Rails. Everything is spliut in Content, Controllers, Models, and Views folders. Content is for CSS, Javascript, stuff like that. The controllers folder is subdivded into a folder for each concrete controller.

All Controllers inherited from BaseController and has a number of Actions which are basically instance methods. View Engines. MonoRail has a number of ways of writing views, the default is NVelocity. You simple and complex ViewEngines, Brail for example allows for Boo code and the full power of .NET in the UI while NVelocity only provides a simple if statement. Layouts are outer views, the inner view is what the controller deails with. You specify the layout by way of attribute. The lauout contains the actual HTML while the inner lauout contains the dynamics parts of the UI. Filters is code than runs before or after specific pieces of code, e.g. you can use filters to change the theme of a site. Again attributes are used for associating the filter. Helpers is something that is made available to your View and abstracts away common HTML snippets, e-g- $Url for creating links. ViewComponents is a more elaborate way of creating stand alone controls.

SmartDispatcher allows you to bind the actions of a form directly to an Action (a method) on the controller, you only have to inherit from a different basecontroller to have this work. FormHelper and the DataBinder are for creating complex forms and you use them to bind to a specific class. You use the an attribute in concert with FormHelper to state what your type is called and to bind to HTML by $Form.TextField("customer.Name") and then you automatically get the customer served up with the correct values once you post back. Automatic Form-Validation is done by decoating the properties of a particular class with validation attributes. To trigger validation you simply say so on the action.

Combining the rest of Castle to Create Enterprise Applications. Castle is full of independent projects you can use the parts you like. The Windsor container is the most advanced of the bunch in comparison to Spring.NET, ObjectBuilder, NInject etc.. Castle Facilities provide integration to other products like IBatus, ActiveRecord, and more.

MonoRail is an organization of services. If you want to change the way MonoRails handles things you can change the corresponding service.

Not as well documented as WebForms. Has a learning curve. No designer support. It is easy to fall into the pit of success because MonoRail leads you in the direction of good design. Microsoft is working on something similar for the future and it should be about to be released in beta.

What does all this boil down to then? to my mind there are a lot of very good ideas in MonoRail but it seems to me that there are a lot of nook sand crannies to know before you get going. Oren's argument against this was that in the long run you will benefit from MonoRail because it makes it easier to fall into the pit of success. I certainly agree with that but there are a number of draw draws that I see. You loose the ability to do anything with SharePoint for example because it operates in the WebForms world, also you loose a lot of third party controls which are also built for the WebForms. It's encouraging to me that Microsoft is working on something similar because that will garner the widespread support needed to grow a third part business around a web framework based on the MonoRail principles.

posted on Wednesday, 26 September 2007 10:38:16 (Romance Daylight Time, UTC+02:00)  #    Comments [1] Trackback
# Tuesday, 25 September 2007

jaoo2007_1 Klaus Marquardt started out the session by stating that complexity is inherent in any system we build and as such we need to deal with the issue of managing it. What was interesting with this session is that Klaus laid out a number of rules for managing complexity. How do we know that complexity exists in a system? usually they way to tell is by way of anecdotal evidence, "I wouldn't touch that it's way too hard", "we don't ever go there", and so forth. There's a saying that goes, "The art of programming is the art of organizing the complex". So what do we do to organize the complex? What constitutes good rules for managing or even reducing complexity ion our solutions?

But first let us try and define complexity. Wikipedia defindes complexity as entanglement and intricacy, or in other words spaghetti code referenced back and forth in no clear way. That was the way I understood it anyway :) Another way of looking it at is like this "Complexity is in the eye of the beholder" which basically means that if you possess a different skill set than another person you might see complexity where in fact it is not. This definition comes from cognitive psychology.

The first rule is to acknowledge that our managers don't want to know. If they do want to know they're probably not a very good manager because they're focusing on the wrong thing, i.e. not managing but developing. If you get a manager involved in your job, developing software, you can be sure that you're going to face complexities due to lacking understanding of the solution.

Second rule is that you cannot get rid of intrinsic complexity in a problem area. Getting rid of intrinsic complexity would mean that you in essence don't handle the problem at hand thus creating useless software.You basically need to deal with the core business to be successful in your project.

Third rule: Hype is an indication what unresolved complexity exists at a large scale. Just think about SOA :)

Fourth rule states that process and technology can increase complexity found in your project. Process because it can lead to a lot of bureaucracy which will impede development and might lead to unnecessary compromises in your projects. Technology is obvious and we're all better for it if we pay more attention to that particular one.

Thomas McCabe invented the metric cyclomatic complexity in order to describe complexity in a piece of software. Klaus believes that this particular metric while useful is at the wrong level for architectural needs as it main deals with the control flow of the application rather than more high level stuff. He went on to describe a number of metrics proposed by Robert Martin defines for describing high level complexity. These include relational cohesion (are the right pieces in the right place), afferent coupling (external dependencies in the module), efferent coupling (dependencies on the module itself), instability (how concrete are our claseses, more concrete classes means a higher level of instability. It's important to remember that instability is not a bad thing), abstractness (are we based on interfaces, abstract classes). What we're looking for in an application is a abstract and stable or instable and concrete. Interestingly this explained to me what NDepend is trying to do. As I now understand the thoughts at the hear of NDpend I'm thinking that I might have to give NDepend another go :)

With all that talk about metric how do these impact complexity? It turns our that metrics is a bad thing for complexity as they have a tendency of forcing an organization on only the metric and nothing else which means a lot of things will fall between the cracks as it's impossible to define all important metrics in an organization or for a project. In essence metrics define their own reality. By all means measure all you want but keep the fact to yourself to avoid the metrics start setting the order of business.

Foundlings is a words I'd never heard before but what Klaus means with this are classes found in a namespace which has little or none relation to the namespace it's in but has a lots of relations to other namespaces. The classes just kind of ended up in that particular namespace for no apparent reason. Which leads nicely to the next rule: Carelessness creates complexity.

The carelessness rule not only tied in with what Robert Martin spoke about at the keynote: Leave the code base in better shape than you found it. What is in play here is the broken window theory where a single unfixed broken window will lead to more and more and finally create slum. So fix that window and avoid a big mess. It's very interesting to see the parallels between all the talks, I'm definitely starting to see trend emerge at this point.

Team dynamics is another area that creates complexity becayse you now have to deal with communication in the team, some kind of preparation before a project really starts is usually needed, and probably the most time consuming effort is the time you have to spend on reworking an application to make new features work. This of course is also tied to a lack of automated testing.

We ran out of time at this point in the presentation so he quickly fired off the remaining rules of complexity which are:

9: Where there is taboo there is complexity. WIf we don't talk about it it probably indicated a problematic area.

10: Local optimization adds complexity. Think higher optimized assembler code sprinkled around your high level C# code.

11: If previous project was complex for a team changes are that the next one will be too. The thinking here is that a team will keep doing what they know how to do, i.e. if they've gone done a significantly complex route previously chances are that they will do so again.

12: Indecisiveness yields complexity. Factors multiply, so if you have a lot of configurability, branches, versions, interconnected products, and options you'll have to deal with a lot of combinations of those factors making for a very complex system.

13: You can rid yourself of chosen complexity. Say for example that you've chosen some kind of standard product to solve a problem, you can get rid of the product or outsource development and rid yourself of the problem. Of course this might cause other problems but you got rid of the other one :)

posted on Tuesday, 25 September 2007 22:04:38 (Romance Daylight Time, UTC+02:00)  #    Comments [0] Trackback

jaoo2007_1 Mantra: Not all of a large system will be well designed. People don't behave as if they believe the mantra and will try to refactor the system to no avail.

Model: A system of abstractions that describes selected aspects of a domain and can be used to solve problems related to that domain though not as realistic as possible, it is useful to specific domain. In essence this is the ubiquitous language which we can use to talk between developers, business persons, and the computer.

There are always multiple models in a system because they need to satisfy different needs, e.g. a customer will not look the same in for CRM and shipping. Don't fight this fact by creating unified enterprise models across the business. Instead know the context you're operating in.We need to be clear about the boundaries we're operating within. Create a context map for your application which describes the various contexts and how they're interconnected, basically a number of context in which data is treated differently, in essence the number of different models available. Translation between the contexts will be necessary. Map what is there, don't map what you'd like to be there. Push translations to the borders and keep the interior unified and consistent with one model.

Benefits of context mapping: Align expectation between teams. Create environment with which models can be effective.

When a system is complex and encompass a lot of features you need to distill system into the core domain which is the interesting part of the system that makes it special. Everything else are generic subdomains, think the subsystems in an ERP system like accounting, purchasing,and so forth. Additionally supporting subdomains are there exclusively to support other domains of the system. The core domain is the part of the system that helps the business successful and succeed. It is usually the smallest part of the system. The core domain is defined by the business strategy, ask the questions: What makes your system worth writing? Why not buy it off the shelf? Why not outsource it? From the answer you'll be able to identify the core domain of the system and thus you main focus.

It's important to focus on the core domain what I see as an enabler for this is the use of standard software like we do in Vertica. Standard software will get you covered with regards to the generic subdomains and the support domain enabling you to work on the interesting parts of the system, or the core domain if you will.

Benefits of distillation: Focus effort and helps you see the forest for the trees.

Join strategy with implementation, escape the down-down/bottom-up dichotomy.

posted on Tuesday, 25 September 2007 18:01:42 (Romance Daylight Time, UTC+02:00)  #    Comments [0] Trackback

jaoo2007_1 Last session of the day is actually the one I'm looking forward to the most: How to brandish LINQ to SQL in a domain-driven design environment? I have some ideas of my own of course but I'm looking forward to stealing some from a couple of industry experts on the subject :) A little about Kim Harding. He's sold his part of Trifok and has founded a new company called Lystfisker.TV and does consultancy on the side. Jimmy Nilsson is of course the auther of a couple of DDD books.

Kim and Jimmy has two different ways of working with the product: Kim works more with the graphical designer where Jimmy starts with the code.

Avoid Anemic Domain Models which are data centered and very light on behavior. With this kind of model the behavior is usually found in transaction scripts instead of in the model itself. Queries often contain domain knowledge - they are just words without meaning in LINQ. The same query might be sprinkled many different places in the code. They have a VideoStore example they've implemented which includes a number of design patterns, associations, and aggregations.

Main focus of DDD is to work with the core of the applications and forget about distractions, don't worry about implementation details. Keep business rules separate from plumbing, e.g. keep data access code apart from business object. One of the main problems for a DDD process is that we have to deal with a relational database at some point; we need a way to bridge the gap between OO and ER and that is where LINQ to SQL comes into play. We like to start by creating the domain model and have the database take the backseat.

DDD is all about the ubiquitous language that we as developers share with the domain experts, it is developed with the domain experts in order to gain a shared idea of what we're trying to do. Many Entities are not fundamentally defined by their attributes, but rather by a thread of continuity and identity, e.g. the unique id. ValueObjects have no conceptual identity. These objects describe some characteristics of a thing, e.g. Address and Price. We can create a language from ValueObjects. An Aggregate is a cluster of objects that go together for data changes, e.g. Order-OrderLine. Repositories work as a starting point for a traversal to an entity in the middle of its life cycle; it has a collection-like interface.

Specification is used to express a business rule as a first class concept, i.e. a class. We can use it for validation, e.g are you satisfied by this validation and querying, e.g. retrieve all objects for query.

ISpecification<T>.isSatisfiedBy(T anObject)

UnitOfWork encapsulates the work we're going to do and describes the context we're working in.


Add to repository

Complete UnitOfWork

IUnitOfWork, IRepository, ISpecification<T>, LambdaSpecification<T>, IEntity<T> (T is used for key), IEntitySet<T>

Use specification as a query mechanism as well.

Good and bad about LINQ to SQL  when doing DDD; Very powerful for example regarding specifications. Makes it simple to develop. Generates very nice SQL.

Don't like lazy loading requires extra attention in the domain model classes (EntitySet). Default ctor is required. Readonly keyword can't be used. Problems with value objects are not supported in LINQ to SQL which is a problem because they are extremely important in DDD. Work around exists for value objects you can add the value object to another partial class which will be joined the class generated by LINQ.

We able to work in several different ways: We can start with a tables first approach, a diagram approach, or a classes first approach. However working with the classes first doesn't seem to be the main focus of the LINQ product. Diagram approach generates a lot of code. Classes don't follow convention over configuration everything is opt-in, counter argument is that with the designer everything is generated for you. You can have LINQ generate the schema automatically but you can only create and recreate the entire database. DataLoadOptions is used to describe what should be eager loaded but it can only be defined once per entity and context. LINQ to SQL was not designed for DDD but more for when you have an existing database. Leads to Anemic Domain Model because you get in the mode of scattering queries all over the place.

In conclusion LINQ to SQL looks like a good product and a step in the right direction but will be an eye opener for many developers doing DDD.


Streamlined Object Modeling book recommended.

posted on Tuesday, 25 September 2007 18:01:25 (Romance Daylight Time, UTC+02:00)  #    Comments [1] Trackback

jaoo2007_1 Developers != plumbers is a saying that Anders Hejlsberg has. We are spending too much time translating between multiple paradigms, be it XML, SQL, or objects. LINQ is the answer to this problem. We have two parts of LINQ that go to the database: LINQ to SQL and LINQ to Entities with LINQ to SQL as the simplest way of going to the database. LINQ to Entities is intended for the enterprise and provides more mapping features. LINQ to SQL works for both SQL Server 2000 and 2005.

So how does LINQ to SQL work? You basically write your query in the application and when you enumerate the query it will be converted to SQL and executed against the database. Adversely when you update everything is stored in the DataContext and is sent to the database on a call to the method SubsmitChanges.

How do you map a class to a table? You create your class like you would normally and decorate it with attributes. For a class you specify [Table(Name = "TableName"]. For properties you specify [Column] and additionally specify which property is the primary key like so [Column(IsPrimaryKey=true)]. Optionally you can store the mapping information in an XML file, though for simplicity and less errors keep the mapping info in attributes. No special base class is needed for the magic to work.

With the mapping done we create a strongly typed database context by inheriting a different class from DataContext where you can specify your tables. Running a query against the DataContext is where the mapping magic happens. You simply do a

var query = from c in db.Customers;

foreach ( Customer c in query ) // mapping magic happens here, not using the Table<Customer> type but the Customer type


// do stuff


Adding a where-clause will cause all the parameters in that clause will be generated to SQL parameters in order to avoid SQL injection. Generated queries are kept as simple as possible as to not confuse developers. Performing a select you can represent relationships which you cannot do in SQL; with SQL you can do only a flat resultset but with LINQ you can get back more natural OO hierarchies as results which are easier much to work with. The LINQ query language is a more expressive language than SQL and as such you are able to express every SQL query with LINQ. Only the properties you actually ask for are returned by the generated SQL query which is nice.

As an alternative to the attribute mapping you can use a graphical designer which allows you to drag and drop tables from the server explorer. It then creates the classes for you. the tools allows for overriding the generated values for the class name and various other stuff. It also allows for mapping to a stored procedure. Relationships are inferred from the database schema so get those foreign key constraints in place today :) Usually relationships are expressed by the object graph but in some cases the link is missing so you'll have to crack open the JOIN functionality of LINQ to get your job done.

One piece of LINQ to SQL that I'm not particularly fond of is the fact that interface based separation is not supported right out of the box so you need to enforce something like the Repository pattern and not allow direct access to the DataContext if you need that kind of separation.

Updates and deletions are very easy to work with. You basically update and create new instances of your objects like you would normally. When creating a new instance you also need to add it to either the DataContext or to the parent object to which it belongs. The only difference is that you must remember to call SubsmitChanges on your DataContext. Concurrency is handled via optimistic concurrency is used for updates, errors are raised if you encounter changed data. Autogenerated values like identities are automatically populated from the database into the object. If you want to use a stored procedures for selects, updates, or inserts you can configure a stored procedure to do so by modifying the behavior of the object in the designer. You simply drag the stored procedure you want to use into the designer and then configure it for the particular object. With the stored procedure is dragged into the designer you can also optionally call it directly on the DataContext.

For stored procedures returning a resultset you will default get a new type generated for the resultset of the proc. What's very cool is that you can configure the proc to not use the generated type and use a domain type instead. Additionally you can perform a query on top of the resultset returned by a stored procedure, something that is impossible with straight SQL.

An interesting feature I noticed in Visual Studio 2008 during the demo is a document preview when you're switching between open documents in the environment. Should make it much easier to find the particular code file you want.

Funny guy.

posted on Tuesday, 25 September 2007 16:50:48 (Romance Daylight Time, UTC+02:00)  #    Comments [0] Trackback

jaoo2007_1 Castle Project is an open source project created to make developers more productive and have more fun and enjoyable work. In the end to create a more maintainable app. Castle Projects consists of ActiveRecord, MonoRail, MicroKernal & Windsor (IoC containers like Spring.NET), Castle Contrib (people contributes here).

Common persistence approaches include spaghetti persistence with databinding in the UI, good for demoing, architecturally it's probably the worst way to do it. Second approach is ad hoc persistence where you write a stored procedure or SQL statement and use those directly, no fixed way of doing DAL. Next step is to have the DBA to handle persistence which leads to a lot of overhead in getting things done. After that we move to hand coded data mapping layer, the problem with the hand coded layer is that it's boring plumbing code. The answer to all these problems is an ORM where everything happens via a generalized framework.

Castle ActiveRecord is a framework which makes ORM really simple by abstracting away the complex stuff. ActiveRecord is built on top of NHibernate and leverages the work done there in the past. ActiveRecord maps to a row in the database. Attributes are used to map objects to tables.

Installer will create template projects in Visual Studio which will trigger wizard upon creating a new AR project, it will generate a main project and a test project to pull you in the right direction right off the bat. You then create your class like you would normally with properties and fields. By decoration the properties you start mapping the class to the database with the [Property], [PrimaryKey], [ActiveRecord] attributes. With the mapping done you need to set up the database context which will provide access to the actual database backend by instantiating the ActiveRecordStarter class. If the table you mapped to is not available you can have AR create the table for you automatically. This makes refactoring of the code and the database very simple because everything happens in Visual Studio instead of having you to go to both code and the database.

Relationships are where it starts getting complicated but AR has a way of dealing with this in an easy fashion as well. By adding a single attribute ([BelongsTo] / [HasMany]) to the link property AR will be able to figure out the relationship between two classes. AR will again generate the schema like before with the simple example of a single table.

Querying is handled by NHibernate query language (HQL) which is an OO query language. Unfortunately the queries are done in strings in the code. For an even better better approach you can use a fluent interface to express your queries in an intellisense supported manner. The fluent interface approach is a very nice way of doing querying because it produces a clean and readable code. Oren spoke about this very thing yesterday in his DSL talk.

Integration with Lucene.NET is provide out of the box which means that you can take any entity, index it, and do a full-text search on the object. Inheritance is another area which traditionally creates some interesting problems for us when doing ORM. AR supports this by doing join tables. AR provides validation ala what is found in Enterprise Library. You simply decorate your properties with attributes like you do when doing the mapping. Basically you can go nuts with this and doing all your validation in code rather than specifying the rules in the database.

Domain driven design is supported, you don't need to inherit from the special AR classes to get the thing going; instead you can use the Repository pattern. ActiveRecordMediator facilitates this approach. Lazy-loading is supported which is good news if you have rich object graphs in your application. Multi-level caching ensures that objects are only loaded once, basically the same concept as the DataContext in LINQ to SQL. You can even do distributed caching which I'm not sure is available in LINQ.

NH Query Analyzer is a tool like Query Analyzer from SQL Server...

No stored procedure support for CRUD. LINQ for NHibernate is under development and will go live within the next five to six months. Active development will proceed after this time as well so that's definitely good news.

posted on Tuesday, 25 September 2007 12:02:47 (Romance Daylight Time, UTC+02:00)  #    Comments [0] Trackback

jaoo2007_1 The keynote this morning was quite interesting as Erik Meijer detailed to us how he sees the future of software development from a technology perspective. Erik Meijer is oding research which according to him may allow us to defer important architectural decisions to a much later point than is possible today. His vision is to allow us to create applications without thought for the deployment scenario, they should just work based on the capabilities on the client. What this means is that in the future we might not have to select a web project over a winforms project. In essence this is deferred to either runtime or deployment. Enabling this is technology which will go into compiled IL and convert it to the which ever platform you wish to deploy to, adapting your code automatically to run on the platform you choose. He showed a couple of examples of this: UI and 3D. The UI part is not what I'd call trivial but he really blew my mind when he started talking about 3D. 3D is basically not a problem with technologies loike Flash and WPF but do you do when you need to support in DHTML? He showed an example of doing just that; they'd taken a model of a teapot and basically created than in pure DHTML using only CSS and DIVs, very impressive. Of course Javascript is no way near powerful enough to pull off a real time rendering but as we all know coding for the present is not the way to go, we need to code for the future and that's what they're placing their bets on.

Erik also mentioned parallel computing, a topic Anders Hejlsberg alluded to as being his next project last year at a TechEd 2006 in Barcelona. LINQ is basically a DSL for working with sets and as such is highly parallelizable. Interesting to hear that that particular project is moving forward.

I surely hope that Erik will be able to deliver on his project with regards to deferring platform to deployment but I fear the kind of autogenerated UIs we're going to see. No doubt a UI can be generated but different design paradigms exist for the web and the desktop are very different and as such I fear that it just won't work just porting the UI to the various target platforms.

posted on Tuesday, 25 September 2007 10:37:50 (Romance Daylight Time, UTC+02:00)  #    Comments [0] Trackback
# Monday, 24 September 2007

jaoo2007_1 Domain specific languages (DSL) are gaining in popularity thus I wanted to know more about them and how I can go about creating them myself. Oren gave an interesting talk on that very topic. So what do we need a DSL for anyway? Oren's main point here was that a DSL will ease communication with the business because you get concise code that you can show to the business users who can then verify that the code actually does what they want. The DSL is basically syntactic sugar which makes everything clean and easy to read.

While I certainly get what Oren is saying I've yet to meet a business person who can actually relate to IT in a deep way much less to actual code however simple it may be. In my experience business persons shut down whenever things start to get hairy, seeing actual code is definitely the hairiest of disciplines if you ask me.

Two types of DSLs exist: External and internal. An external DSL is created from scratch, a couple of examples of external DSls are SQL and Regular Expressions. Of course a DSL created from scratch needs a lot of work to get going thus we arrive at internal DSLs. An internal DSL is actually piggybacking on an existing language which makes it easier to get going. Boo is an example of one such language well suited to creating internal DSLs though usually one would use a dynamic language for these purposes.

So what is Boo? Boo is a CLR language like C# and VB; it compiles to IL. What Boo provides over C# and VB is an open compiler architecture which provides you with access to the compiler at compile time allowing you to change the output. Interestingly Boo is white space significant; I didn't get the concept before Oren's talk but all it means is that indentation decides which code blocks belong together. For developing Boo code we have the open source IDE SharpDevelop which actually supports C# also. I heard about SharpDevelop on DotNetRocks! but didn't think too much of it as a product. Who needs an IDE which does less than Visual Studio? Well Oren showed us why SharpDevelop is a big deal for DSLs. Basically you take the code for SharpDevelop and create a version for your code-savvy business persons and have them develop their code in an environment tailored to their needs.

All in all an informative presentation given by Oren Eini. I wasn't convinced about the value of DSls when I left the session but talking with Søren Skovsbøll who had a nice example of where you can use a DSL very effectively: Namely for creating questionnaires. Questionnaires can be notoriously complex to put together with various rules and sub-questions depending on previous answers. It would simply be much easier to express your intent with code in say a DSL :)

As a little addendum I can mention that Oren actually started out by talking about fluent interfaces which are the simplest way of doing DSL-like stuff. What's interesting here is that fluent interface doesn't require you to learn a new language to implement. You can do them in you language of choice and gain a lot of expressiveness. Unfortunately the plumbing of fluent interfaces requires a lot of work which is why you usually go for a fullblown DSL instead.

posted on Monday, 24 September 2007 21:35:33 (Romance Daylight Time, UTC+02:00)  #    Comments [2] Trackback

jaoo2007_1 Robert Martin gave a very entertaining keynote this morning. He basically spoke about defining our profession and what it means to be a software professional. As an industry we've traditionally been all over the map with each developer did what he thought best in a given situation and he tried to address some of the aspects we as an industry need to work with to reach a higher maturity level.

So how do we define professionalism? Robert Martin's idea of professionalism boils down to a shared mindset and a set of techniques. The mindset part of it is basically what the agile manifesto sets forth with the individual being responsible and generally behaving like "the good citizen". He elaborated on this by giving a couple of examples: If you write code try and leave the code base just a bit prettier than you found it. This resonated especially well for me because I inherited a large code base a couple of years back and actually adopted that very mindset. The result of this is that the code base is in much better shape than when I got back then. Furthermore he mentioned that the mindset you want developers to adopt is a that of "zero defects". Of course this is a utopian goal but if you strive for perfection you're sure to create a better product than you'd have done if you from the get go start out with a "shit happens" mindset :)

Another of his points that resonated with me is that of short iterations and no big redesigns. If you have a big mess in your system don't go down the road of a total redesign, chances are that the specs for the new system will change too rapidly making the new system obsolete before it's done. Instead try to tackle the mess one step at a time, much like the "leave the code base in better shape"-rule. This fits quite well with the idea of refactoring and as such is something I not only think is a good idea but something I've seen work in the trenches. Again this is not something which is set in stone as you will experience situations where a complete system redesign is not only appropriate but necessary; like for example when you're moving from one platform to another which is fundamentally incompatible with the other. Even in this case you could argue that technologies like web services can indeed enable an iterative approach to porting the system. But that's another story entirely :)

Test driven development is another topic he dwelled on for quite some time and with good reason too. I'm coming to believe that TDD is going to be an essential part of the modern developer's skill set and as such we need to start thinking about architectural support and guidance on it. With TDD as a natural part of development we simply put ourselves in a much better position to support our customers in the future. How many times have you experienced that development ground to a halt due to complexity, not necessarily business complexity, but complexity imposed by the fact that the system has become too much of a mess for you to be able to gauge the risks of adding a new feature, much less comfortably test it for release? With TDD this because a non-issue because you know that the system is passing your tests at all times. Thus you can actually achieve the "!refactor mercilessly" approach to software development that Martin Fowler et al advocates.

Finally apprenticeship is a topic which rung true with me. The premise of this topic was the fact the newly educated people simply don't possess the skill set to participate in a software development process right out of school. Therefore Robert Martin proposed a notion of apprenticeship for newly educated people getting hired into a software development organization. It's an area I've done a little bit of dabbling in but I've never actually gotten a completely fresh guy right out of college, my work focused more on getting people with experience up to speed in areas which they were lacking.

Robert Martin is a very skilled presenter who managed to keep the crowd entertained. His style of presenting is very active which makes it even more engaging. The keynote certainly bodes well for the rest of the conference.

posted on Monday, 24 September 2007 14:29:50 (Romance Daylight Time, UTC+02:00)  #    Comments [0] Trackback
# Sunday, 23 September 2007

jaoo2007_1 Next week marks the beginning of the JAOO 2007 conference and this year I'm going. JAOO is organized by Danish company Trifork (formerly East Object Space or EOS for short). JAOO is traditionally a Java conference with well known speakers such as Ted Neward, Martin Fowler, and more.

So why, might you ask, am I going to attend a Java conference? The answer is three fold: One I'd like to get a broader perspective on the business of software development and I'm confident that attending a conference not following the Microsoft sanctioned line will provide me that.

Secondly a conference like TechEd is geared towards actual products coming out of Microsoft rather than the ubiquitous ideas behind software development. Don't get me wrong it's great fun to learn about all the new toys coming out of Microsoft but really when you get right down to it the ideas behind are what is really interesting as they tend to stick around much longer. So what this boils down to is really that I hope to gain architectural insights for use on future projects.

Thirdly the .NET community gets a lot of inspiration from open source frameworks, ideas, and techniques. To me it seems that a lot of innovation is happening within the open source space, a lot of which we'll see a some point in .NET. Tools and frameworks like JUnit, Log4J, and Spring have been around for a long time in the Java space and they all have successful .NET ports; for NUnit so much so that it was included in Team System. With this I'm looking to learn more about the various frameworks and tools out there.

With all that said JAOO is turning away from the concept of a pure Java conference, this year two tracks are actually dedicated to .NET: The .NET Road and LINQ both of which I'll be attending. They cover Monday and Tuesday for me. Wednesday will be Professional Developer. I'm looking forward to cementing my ideas on LINQ and I'm positive that Tuesday will help me doing so.

Thursday is going to bring the part I'm looking forward to the most: The Test Driven Development tutorial. Basically an entire day of hands-on TDD. Although it'll be with a Java focus I'm sure that I can port the ideas directly to .NET. My only concern is that I'm going to be the only Visual Studio guy in there but I'll deal with that once I get there :)

posted on Sunday, 23 September 2007 20:48:55 (Romance Daylight Time, UTC+02:00)  #    Comments [0] Trackback