Archive for September, 2008

Screencast on supporting POCO with Linq to SQL

September 29th, 2008 by Sidar Ok

  http://www.developers.ie was kind enough to invite me to do a screencast for them, where I will be talking in .NET Coffee Break show about POCO support in Linq to SQL.

The event is on Thursday, 11:00 A.M Greenwich time. Registration is free through http://www.developers.ie/Webcasts.aspx .

Hope to see you all there !

UPDATE : Thanks to Paschal and http://www.developers.ie, to provide me this opportunity. Here are the source for the demo. Sorry for the unluckiness that connection dropped twice (yes, twice :( ). Thanks everybody for listening, and as son as Pascal provides the link I will post it here.

UPDATE 2: Still waiting the show to go online.

UPDATE 3: Here it is :Part1 , Part2.

kick it on DotNetKicks.com

Share it on: These icons link to social bookmarking sites where readers can share and discover new web pages.
  • Digg
  • Sphinn
  • del.icio.us
  • Facebook
  • Mixx
  • Google
  • Blogosphere News
  • e-mail
  • YahooMyWeb
  • DotNetKicks
  • DZone

What is this Managed Extensibility Framework thing all about ?

September 26th, 2008 by Sidar Ok

No, this is not another introduction post. Being one of the earliest adopter of MEF, I started to see a great confusion around what MEF is, and what it really is suppose to do in this wild world of DI containers… Well ok, I can’t lie anymore about, as people have twitter proofs to throw at me, I was a part of that confusion :

image

As you see, I was pretty biased as an avid DI user, that MEF is an IoC container so why doesn’t it behave in a normal DI ish way ? I was seeing MEF as an only IoC container so much, and in that limited perspective its design has sucked big time for me, especially because of the unnatural Export - Import system. And for that matter, I even implemented a way of an external configuration for MEF.

This has proven to be really painful. Glenn Block, saw my pain through twitter and called me for an hour of a very nice and informative chat.

Here is the result: MEF is not a DI container. DI is only a part of the solution that MEF tries to bring into the scene. Ayende just got quicker in the game, and explained it well, so I couldn’t have the joy of telling the world first :)

I won’t repeat what Ayende said, I’ll just try to make things a bit more concrete in perspective of my understanding as a person who likes to talk over examples.

Understanding MEF with an example

Now, it is time to take those DI glasses off and look at a different view. Forget about DI, containers, IoCs et all. Let’s start thinking with a concrete example we all know about. Visual Studio has a plug in infrastructure. Say that we are handed to build that, what do we do ?

  1. First, we need to come up with an interface (be it an SDK or API reference), sort of a hook to outside, so addin implementors can code against it.

    1. This involves the lifecycle of the addin. You should be able to achieve basic needs create instance / retrieve already created one (singleton).

  2. We should be able to provide a way of interact with add-in. Add-in should be able to easily send you messages about, say show solution explorer or open a file in editor.

  3. We should be able to lazy load it if needed. E.g there is no need to load an add-in at start up when the add in is supposed to be performing within a context menu event.

  4. A new add-in, or a replace of an old one should be as easy as throwing the dll in bin folder. This means that if a new set of addins is in place, you need to be able to choose amongst them. (meta-data based discovery)

  5. When an add-in is replaced or simply dead, we need to unload it.

So in all this sense, VS is a composite application. It needs to be composed dynamically.Beware, during all these steps we still don’t care about the actual add-in. We just care that if it complies to our needs that we specified in the contract. We need something that quacks, and looks like a duck. Anything that supplies these demands, even if it is a dog, more than welcome to be part of our Visual Studio.

Now, these are all huge works. Imagine just lazy loading of a component has a lot of edge cases already(#3), let alone solving the unloading problem from AppDomain(#5). But let’s say that we finished and shipped our Visual Studio. Happy days, counting the money.

And now, we are assigned on a new task and writing Lutz Roeder’s great tool Reflector. And guess what, Lutz Roeder wants us to implement an add-in infrastructure so that they can perform several tasks in reflected code. To accomplish this, we need to do ALL the steps above again, from 1 to 5. All that drudge work, and none of it is reusable because we designed it in an application specific way (and that perfectly makes sense since our concern was not to build that framework). Now you got the point: MEF is a core .NetFx component that adds ability of composability to any app by default.  Its aim in short term is, not replacing IoC containers but working with IoC containers, which fits this greater vision.

Another Example - Publisher Subscriber

A lot of confusion is also going around between MEF and System.Addin Namespace, similar to the confusion addressed above. Let’s look at another example that has nothing to do with add-ins, to show that problem is not an add-in bound system.

Say we have a banking system, with a strong domain model. We need services like Accounting, Personal Info, Leasing etc. And in this bank, in every two weeks or so there comes a new service.For the discovery and configuration of these new services, you would normally use an ESB (Enterprise Service Bus). That discovery part has indeed very similar roots with MEF.  MEF provides you a lightweight bus-alike approach for your extensions. By hosting MEF, you are delegating this discovery system to MEF, and it provides you a rich Meta Data to be used. The Export - Import model indeed looks very similar to Publisher and Subscriber model in this sense.

Conclusion

MEF is by no means a replacement to today’s IoC containers, nor to System.Addin . It aims to be a reusable solution to provide a common base for the heavy lifting code of extensible applications, so we (hopefully) will need to worry less about extensibility concerns of the application. If you like, you can use MEF as your IoC container, but this doesn’t mean that you should. We can also use our favorite IoC container of choice with a free (as in speech) collaboration with MEF by Resolvers.I am planning to cover the concepts with a hands on application which will hopefully help to build better understanding, stay tuned.

kick it on DotNetKicks.com

Share it on: These icons link to social bookmarking sites where readers can share and discover new web pages.
  • Digg
  • Sphinn
  • del.icio.us
  • Facebook
  • Mixx
  • Google
  • Blogosphere News
  • e-mail
  • YahooMyWeb
  • DotNetKicks
  • DZone

After Linq to Sql Talk in Cork

September 23rd, 2008 by Sidar Ok

The talk last night was awesome. Thanks to all who showed up, there was a good turnout. Also thanks to Joe Gill and MTUG for organizing the event, and to Microsoft for sponsoring. 

pic1 

I had the great chance of sharing my thoughts, knowledge and experience on Linq to SQL, analyzing upsides and downsides of it. It was targeted for advanced audience, so I enjoyed talking to a bunch of geeks.

Here are the slides for the presentation. I also made a demo on how we can support Domain First Design and create POCOs with Linq to SQL, and didn’t have the time to do the second demo on a short multi tier development demonstration. You can find them here in rar format.

It is always great to have good techies around you, and free beers along with chicken wings !!

This was the beginning event of the year and I am honored to have done it. Hope this will encourage more people to share the views and experiences on subject matters.

Share it on: These icons link to social bookmarking sites where readers can share and discover new web pages.
  • Digg
  • Sphinn
  • del.icio.us
  • Facebook
  • Mixx
  • Google
  • Blogosphere News
  • e-mail
  • YahooMyWeb
  • DotNetKicks
  • DZone

Agenda on Linq to SQL talk

September 20th, 2008 by Sidar Ok

I decided on some of the bullet points that I will talk about at 22nd. This will be a MS-200 level talk, means that it requires also basic level knowledge of Linq to SQL. Although if you don’t have the basic knowledge, you are still welcome to fill the seats and make the place look crowded :-)

In this first event of the year, here is what I am going to talk about ORM s and Linq to SQL in particular:

  1. Building a Common Glossary
  2. Defining the Problem
  3. Building in house ORM/DAL vs Use an existing one
  4. Linq to SQL Comes into play : Myths and Realities
  5. Linq to SQL beyond drag and drop : Concepts
  6. Linq to SQL Entity Model
  7. Mapping Engine
  8. Attribute Level or External ?

    SQL Metal to rescue

    What it does, what it lacks

  9. Understanding DataContext
  10. Change Management & Change Communication Strategies
  11. Advanced Topics (If time permits)
    1. Debugging and Troubleshooting
    2. Transaction Handling
    3. Concurrency & Conflict Handling Scenarios
    4. Entity Validation
    5. Security Model
    6. Serialization
    7. Performance Advices & Best practices

I also prepared a couple of demos to serve some of the practical implementation of the concepts that I want to share.

Looking forward to see you at Imperial Hotel on Monday!

Share it on: These icons link to social bookmarking sites where readers can share and discover new web pages.
  • Digg
  • Sphinn
  • del.icio.us
  • Facebook
  • Mixx
  • Google
  • Blogosphere News
  • e-mail
  • YahooMyWeb
  • DotNetKicks
  • DZone

Talking on Linq to SQL on 22nd of September

September 5th, 2008 by Sidar Ok

I am going to be talking about Linq to SQL, one of the ORM mappers coming out of Redmond. I am planning to cover how to utilize Linq to SQL to get the best benefit out of it, Linq to SQL’s place in the ORM world and pros-cons and of course ways to apply patterns and practices with a couple of demos.  I’ll be more than happy to see any of you there and do some geek chat , and have a couple of pints. Pints and chicken tenders are free and Microsoft’s courtesy (Himm, free tenders…That is more appealing then the talk…tenders…)

Registration is free through this link : http://www.cork.mtug.ie/Events/EventInfo.aspx?ID=b2515894-866f-4d70-8c87-ebaa69c69b7d 

 See you there !

Share it on: These icons link to social bookmarking sites where readers can share and discover new web pages.
  • Digg
  • Sphinn
  • del.icio.us
  • Facebook
  • Mixx
  • Google
  • Blogosphere News
  • e-mail
  • YahooMyWeb
  • DotNetKicks
  • DZone

Documents 2.0 - Consumable Documents

September 3rd, 2008 by Sidar Ok

I was in Brussels last weekend to visit a friend, and had a chance of meeting up with a group of highly skilful and visionary people. We had a very interesting chat, and one point was about documentation came up. Seemed like everybody has the same pain, reading and writing technical documents consume an incredible part of any developer’s day, usually most of the work done is about searching the right needle through a pile of garbage.

It is amazing that over the years that hardware technology is evolved a lot. Not so much as it, software has also progressed and proved some quality.

But one thing couldn’t make the big move: Documentation. No, I know we have better word processors, heck, I am using one for this entry. We have the enough technology to write more old styled documents. We have been reading tons of papers 30 years ago to accomplish a single development task, thanks to the internet, web 2.0 or whatever brought us, we now have wikis, podcasts, screenCasts and blogs which speak to different senses and styles. Of course there still is some technical problems, such as indexability, searchability, and relevancy to the need of these but it is getting better over the time.So what is my problem ?

Ok, I am gonna say it. It is that we DON’T get enough benefit of all these in our daily business environment.How many of you have been left with a legacy code ? Surely most of you. How much are them was documented ? I bet since most aren’t, it is not a few either. And why don’t we get any podcast, or a web cast on, let’s say Provider Infrastructure for Insurance, or Dealing with Leasing Options in Banking where we are more than happily get provided hundreds of pages ?

Now known that while handing over the legacy code, pairing with the person who originally wrote it is one of the best things that you can do, why does this information fly? When that person goes away either you loose all the info, or if you have a documenting process it might be even worse: you’ll face the hungry monster of 200 pages, which hasn’t been maintained like 10 years ago.

My point is, let’s produce those documents keeping in mind that a person will read it - not that because writing a thick book on the subject makes us seem more intelligent and hardworking. I want to see more agile documents. Those include:

  1. If a document is longer than 20 pages, please consider breaking it down to multiple ones.
  2. If you can tell more with less words, please do so. Usage of patterns for e.g, applies well here.
  3. If you can tell more without any word, even more appreciated. Using pictures, diagrams or even comics sometimes, usually reach to the point
  4. Know your audience, and produce the document for him/her not for comfort of yourself. If I am your audience, know that I am a highly technical guy and not a native English speaker. Don’t assume that I know what you know, such as your sector’s details and don’t think that I am dying to look at your design document to learn what a Memento Pattern is all about.
  5. If you think that you can express better if you speak, do a podcast and link it from that document. If you want to show a process, let’s say a migration chain, don’t hesitate to record a screen cast. It will take only 2 mins and will stay there forever, so you won’t spend your time going over and over it to the newbies joining the team. You don’t need to be an expert, as these will stay internal.
  6. Blog about what you found. Put it in the company wiki. Get angry with the people asking you questions before looking at the wiki. Girr !
  7. Use documents to increase the quality of communication, not the time spent on it. If you need a meeting to talk about a 100 page document, either the document or meeting is not to its full intent.

In business environments, I see an incremental Agile Documenting Fear (term stolen from M.Fowler as in Parser Fear) that leads us to the apocalypse of inconsumable documents. IMHO, that’s something that we should avoid for our own goodness.

kick it on DotNetKicks.com

Share it on: These icons link to social bookmarking sites where readers can share and discover new web pages.
  • Digg
  • Sphinn
  • del.icio.us
  • Facebook
  • Mixx
  • Google
  • Blogosphere News
  • e-mail
  • YahooMyWeb
  • DotNetKicks
  • DZone