# Monday, 08 October 2007

As I mentioned in my summary of the last usergroup meeting we have a little more mainstream topic for the next meeting: Object relational mapping (ORM) and LINQ.

The next meeting will be held October 24th 19:00 at Ditmer A/S. Please note that we're not doing the last Wednesday this time around due to scheduling conflicts with the speaker. As always the meeting is open to anyone who wishes to participate.

Please leave a comment to sign up for this meeting

Practical Information

The meeting will be held:

Wednesday 24/10 at 19:00


Ditmer A/S

Trindsøvej 9

8000 Århus C



Usergroup News

To keep everybody inform on the various stuff going on we'll begin with a short update on planned sessions, new initiatives, and so forth. This will also be your chance to give us some feedback on what you would like to see at future meetings or voice your interesting in presenting a subject matter yourself.

Object Relational Mapping and LINQ, Søren Skovsbøll, Ditmer A/S

O/R mapping is a widely used discipline in the .NET world. Only now Microsoft is entering the fray with two O/R mappers: LINQ to SQL and later ADO Entity Framework. LINQ to SQL has garnered a lot of publicity primarily due to the new query language which is available inside C#, VB, and other CLR languages.

Getting started with LINQ to SQL is easy but when your applications become more complex than the samples Microsoft provide you'll need to know what's going on under the hood and what an O/R mapper really is.

We'll dive into which patterns also all O/R mappers use: Identity Map, Unit of Work, Data Mapper, etc.. LINQ to SQL is a simple O/R mapper in that regard but making up for the fact are the rich design time tools which comes with Visual Studio 2008.

Søren Skovsbøll is  a development consultant with Ditmer A/S. He started working with O/R mapping when NHibernate was in its infancy with the 0.3 release. Mappers which will let you keep your domain model nice and clean is in high regard with Søren and he's even built his own O/R mapper from scratch called Matterhorn which was the first to support generics. He publishes a blog at Skarpt.dk.


Tour de Ditmer

Morten Ditmer, the CEO of Ditmer, will do a lap around his company and enlighten us on Ditmer as a company, their values, and how they go about building software in Ditmer.

The Nutcracker

Have a problem or a topic you'd like to discuss? This is your chance to get the opinion from a bunch of intelligent people working with .NET. Would you like to demo a cool tool? Show a web site which has changed your life? It's all up to you, if you find it interesting chances are that others will too. So feel free...

Looking forward to seeing you and remember not to be shy even if this is your first attendance :)

posted on Monday, 08 October 2007 15:59:29 (Romance Daylight Time, UTC+02:00)  #    Comments [30] Trackback

He's no Singing Salesman but he sure got talent. Without further ado I give you hands farting Bohemian Rhapsody. (Blame our sales guy Robert for this one :))

posted on Monday, 08 October 2007 14:03:14 (Romance Daylight Time, UTC+02:00)  #    Comments [0] Trackback
# Monday, 01 October 2007

To bring the members of Aarhus .NET Usergroup even more benefit, I've created a group for us on LinkedIn. Feel free to join.

posted on Monday, 01 October 2007 21:27:35 (Romance Daylight Time, UTC+02: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

We had little over ten people turn up for the meeting and we had great fun. I admit that the topic was rather esoteric as ESB, SOA, and BizTalk just doesn't apply to all that many people out there, especially in Denmark. ESB and BizTalk was the second part of our SOA topic and I think it rounded the topic off in a nice way. For future meeting we'll try to keep to topic of the presentation a bit more mainstream. Also the next time I plan a meeting I'll make sure not to collide with a major conference in town like JAOO. Having a usergroup meeting right after a full day of conference is a tall order, I know I went there straight after JAOO, I might not have been my most coherent self and it might have affected the turnout as well.

A big thank you goes out to Klaus Hebsgaard and Kristelig fagbevægelse for getting a nice space for us to hold the meeting, probably the nicest yet, and some very good sandwiches too.

Like always we started out the meeting by summarizing what the core group has been up to since last time. First of all we've been busy with getting new talks and speakers together and I'm proud to announce that we've got the next couple of rounds together at this point. I expect that we'll announce new meetings much earlier than we've been doing up to this point to allow people more time to sign up for the meetings. The topic of the next meeting is Object Relational Mapping and LINQ by Søren Skovsbøll and will be held at Ditmer A/S at October 24th at 19:00. Please note that we're not doing the meeting the last Wednesday of the month this time around due to scheduling issues. I'll do a separate post on the next meeting when I've got the last couple of details sorted.

We're planning a couple of meetings which are aimed at the inexperienced .NET developer because we do have a number of you attending the meetings and we'd like for the group to bring something to the table for everyone. As a follow up to that the first meeting we're trying to get a code camp together with the intent of teaching you how to create a .NET application from ground up the right way, or at least the way we feel is the right way. This is not only for the inexperienced developer as we need a number of experienced developers who can act as a kind of instructor at the code camp helping out with questions. I'd like to gauge the interest in this concept so please write me an e-mail if you're interested in participating either to learn something as an instructor.

We're still working on the web site for the group. All the technical stuff is basically done, we just need text and the pretty parts to be done as well.

Like previously we did a quick lap around the attendees to get a feel for who was present. We had a couple of new guys, one of whom had asked me before the meeting whether he could attend even though he hadn't been the previously. So I I'd like to take this opportunity to clarify that Aarhus .NET Usergroup is completely open to all who wish to participate regardless of previous attendance. We'd like you to attend every time of course to ensure continuity but it's completely up to you. You simply sign up to the meeting you want to attend and that's it. If you've attended a meeting previously you'll receive an e-mail whenever a new meeting is scheduled so you have the chance to sign up before anyone else.

Troels Riisbrich Underlien gave an interesting presentation on Enterprise Service Bus and BizTalk. The presentation focused on ESB as a technology and less on BizTalk although he gave us insight into some of the inner workings of BizTalk because they were at the heart of the ESB solution he outlined later on. Troels gave us information on how to go about building an ESB on BizTalk, the Microsoft guidance, and probably most interesting of all how Vertica has created and implemented an ESB for Bestseller. Download the slides if you want to either recap or get a feel for the content of the presentation. Essential an ESB is the way to go if you're considering doing SOA that's my personal take away from the presentation anyway. If you what want is a asynchronous, scalable and flexible solution there really is no way around the ESB as a concept.

After a short break and chatting in the hall ways we went back to the regularly planned programming where Holger Brøns Jensen the CIO of Krifa did a brief presentation on the IT organization of Krifa and the challenges they're facing. Krifa is definitely facing some interesting problems at the moment as they're moving their entire platform to a service oriented architecture, of course they have a lot of legacy which still needs to work so the last two meetings have basically been perfect for their needs. Krifa has done some very interesting stuff in the past and was off to the IP telephony races very early on which provided them with a nice head start on the callcenter side of things compared to their competition. Thanks to Holger for a very informing presentation.

Finally we had the unstructured part of the meeting which we call the Nutcracker. People usually refer to this part of the meetings as the most interesting as it opens up for discussion on various topics. we had a couple of good discussions this time around: Klaus had a problem getting their ESB to talk to WCF and we steered him in the direction of a possible solution. We even got Visual Studio fired up to show him the default binding profile for ASMX, of course I couldn't help but get sidetracked just a bit so I demoed a couple of features of ReSharper a couple of which have actually found their way into Visual Studio without my knowledge making for an interesting demo. Following that I wanted to get people's opinion on ORM and which they use themselves. I didn't really get that one off of the ground but the discussion took an interesting twist regardless so all in all a success.

Thank you to all who attended this meeting. As I started out by saying we're aware that the topic was esoteric and we'll try to keep broader topics of interest in mind for future meetings. I'd like people who plan to attend in the future to think about topics for the Nutcracker so we ca get the discussion going, maybe even prepare a short five minute talk to get the topic going.

posted on Sunday, 30 September 2007 13:25:16 (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

Remember that ANUG is holding a meeting tonight where the topic is BizTalk and Enterprise Service Bus. Read more and sign up.

posted on Wednesday, 26 September 2007 09:13:41 (Romance Daylight Time, UTC+02:00)  #    Comments [0] 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

<a  href=dasBlog-2-Download-Now" src="http://www.publicvoid.dk/content/binary/WindowsLiveWriter/UpgradedtoDasBlog2.1_9EC4/dasBlog-2-Download-Now_3.png" width="500" align="right" border="0"> dasBlog 2.0 was released little over a month ago and I've been wanting to update to it for a while; yesterday I finally got around to doing it. If you're in the same situation and need to update an existing dasBlog install here are the steps to do for a 1.9 to 2.x update:

  • Copy bin directory
  • Copy root directory files, aspx, ascx, everything found in the root directory of dasBlog
  • Copy web.config
  • Copy DatePicker and ftb (this is just in case)

When you're done updating the code remember to reconfigure your IIS AppPool to run ASP.NET 2.0 as dasBlog 2.x is now a framework 2.0 application. Please note that if you have other framework 1.1 apps running in the same AppPool you'll need a separate AppPool for 2.0 as a single AppPool will, not surprisingly, run one framework version only.

With the updated version a couple of new feature are available on this blog: Paging on the main page, i.e. you can now move backwards through posts. Scroll to the bottom of the main page if you want to see how it works.

<a  href=dasBlog-2-Main-Page-Paging" src="http://www.publicvoid.dk/content/binary/WindowsLiveWriter/UpgradedtoDasBlog2.1_9EC4/dasBlog-2-Main-Page-Paging_3.gif" width="198" border="0">

Paging in the categories, instead of just displaying everything only five posts are displayed when you looking at a particular category.

<a  href=dasBlog-2-Category-Paging" src="http://www.publicvoid.dk/content/binary/WindowsLiveWriter/UpgradedtoDasBlog2.1_9EC4/dasBlog-2-Category-Paging_3.gif" width="377" border="0">

If you're running your own blog on dasBlog a nice little addition is found in the admin module. It's now very easy to switch back and forth between dates when you're viewing you referral stats. Very handy.

<a  href=dasBlog-2-Admin-Referrals-D" src="http://www.publicvoid.dk/content/binary/WindowsLiveWriter/UpgradedtoDasBlog2.1_9EC4/dasBlog-2-Admin-Referrals-D_3.gif" width="436" border="0">

posted on Sunday, 23 September 2007 14:18:21 (Romance Daylight Time, UTC+02:00)  #    Comments [0] Trackback
# Friday, 21 September 2007