Random Acts of Coding

Video - Inversion of Control with StructureMap

noreply@blogger.com (Anonymous) — Wed, 17 Nov 2010 03:10:00 +0000

This past Spring, I also attended the Iowa Code Camp. Unlike the Fall's which just past, I recorded 3 sessions (2 plus my own) while there. I've had some issues finding time, space, etc. to encode the files and get them hosted somewhere. Now that I have a Vimeo account, I will be posting any of the videos with the presenter's consent.

The first of the videos from this Spring is from Brad Tutterow who presented on Inversion of Control with StructureMap. This was an awesome session and thanks Brad for letting me record and post the video.

Inversion of Control with StructureMap from James Eggers on Vimeo.

For more information about what Brad's up to, check out his Twitter (@CodeBadger) and Blog (http://www.codebadger.com).

Iowa Code Camp - Fall '10 Review

noreply@blogger.com (Anonymous) — Fri, 12 Nov 2010 22:15:00 +0000

Over the first weekend of November, I attended and spoke at the Iowa Code Camp in Des Moines, Iowa. Every time I attend, the event is great and everyone there are some of the top developers in the area. As with any conference I go to, I want to make sure and write a review on the experience overall. I was able to attend 4 sessions at this code camp after doing my presentation on the Low Hanging Fruit of Html5. Below is a rundown of each session I attended.

Getting Dirty with Android - by Brent Edwards

I've talked with Brent on a number of occasions via Twitter and was looking forward to attending his Android development presentation. I had looked at Android development briefly in the past; however, hope to get into it more now that I've traded in my iPhone 3G for an HTC Evo. Brent did a really good job on showing the basics of Android development using Eclipse on a Windows system. He wisely had all examples setup prior to the presentation in order to not bore the audience by manually typing the xml associated with Android's layout. He also made a point to educate the audience on some of the things that may cause a new Android developer to get hung up. His presentation was one of the few that I've been to that I couldn't find hardly anything to provide constructive feedback on. He was well practiced on the topic, he had the examples working well, and he was able to field any questions. Overall, it was a great presentation that I'd recommend to anyone looking to get into Android development.

Curriculum Development Workshop - by Dustin Thostenson

Every so often on Twitter, a conversation will come up on a number of academic topics. A few months ago, the topic of how to build a better college curriculum for software developers or engineers came up. After multiple hours on Twitter, many conceded that moving the conversation to a forum like Iowa Code Camp would be a good idea. This session was solely a discussion about that topic. Dustin is on the curriculum board at the Des Moines Area Community College which makes the topic more than just a theoretical discussion. In the session, we had a large mix of educators, students, and other people who varied in how they came about being a software practitioner. Dustin had a number of pseudo-exercises he asked us to do in order to limit group think early on. From these exercises, the discussion focused on the fact that some of the most common set of courses that the attendees deemed were most important were not technical at all. Courses like public speaking, group dynamics, research methods, and writing were all rated as some of the most important while language specific skills were some of the lowest. From everything discussed, I left the discussion thinking not what courses are the most important for a college student but more about how to inspire a student to have patience in learning true programming skills. Knowing how to cut code is the least important aspect of my day job and, after the discussion, I'm not alone in feeling that way.

Using and Extending Django - by Matt Morrison

By day, I'm a .Net guy. By night, I love programming in anything that isn't tied to Microsoft. I enjoy working in Python and have dabbled in Django a little bit; however, nothing enough to feel comfortable to really ensure that I was doing things right. This session was a slight treat for me since I could learn the Django way of doing things from a guy that actually uses Python daily. Matt's presentation was very open which was bittersweet. I was able to ask questions and help mold the presentation to the aspects that I'm interested in; however, it also lead to some uneasy pauses and breaks in the flow of the presentation while Matt was soliciting the audience on for what they may be interested in. Overall, there was a lot of information that I saw and gained from the presentation even though it was very rudimentary. I would have enjoyed seeing a bit more structure but overall, the content was good and it was obvious that Matt knew the subject matter. I also would have liked to see a few steps on how to start the application from nothing and how he located and setup the eggs.

Using Django and TDD to version Databases - by Matt Morrison

In a continuation of the previous conversation, Matt focused more on how to do TDD with Django as well as introduced how to work with South, a Django add on for doing database migrations and versioning through modifying your model. This talk was very beneficial for me in that I saw TDD in Python/Django, more specific Django stuff, and how Django does database migrations. I was very curious on the database migration elements because of my involvement in the Dot Net Migrations open source project in the .Net space. In comparison with the previous topic, this presentation was very structured and spot on. It answered a lot of my questions and provided me a ton of insight.

Overall Reflections

Every conference I go to I enjoy. Iowa Code Camp is no different. This time around, I saw a large amount of Macs and a bit more diversity in the sessions than in past conferences, which were very .Net heavy. While I'm a .Net guy, I have shifted my presentation topics away from .Net in order to provide different viewpoints to the audience. I like seeing how conferences like this are providing a forum for such as well. I don't regret going to any of the presentation that I went to though wish I was able to clone myself and attend others as well. I only recorded my own presentation this time around due to logistical issues that I encountered in the Spring. Next Spring's code camp I may have a different camcorder in order to make things a bit easier to off load and recharge the camera easier. Beyond that, I'm looking forward to playing around with the knowledge I picked up last weekend. I also am working on some additional presentations as well. Next year is going to be a busy year for me as a presenter and I can't wait to see how things go.

Speaker Contact Info

Brent Edwards - @brentledwards

Dustin Thostenson - @dustinson

Matt Morrison - @mattjmorrison

Presentation: Low Hanging Fruit of Html5

noreply@blogger.com (Anonymous) — Wed, 10 Nov 2010 02:40:00 +0000

This past weekend, I participated at the Iowa Code Camp in Des Moines, Iowa, USA. While at the event, I spoke on some of the elements of HTML5 that can be used in today's web design and development world. Below is a copy of the materials, the presentation, and a video of my session. I plan on doing additional sessions on or relating to HTML5 in the near future so stay tuned.

A Tale of Two Interviews

noreply@blogger.com (Anonymous) — Wed, 20 Oct 2010 13:00:00 +0000

Disclaimer: This story is completely true, sort of. The names and faces of those depicted in this blog post have been changed in order to protect the innocent and incompetent alike. Any similarity to people or places you know is completely coincidental. Furthermore, no animals were hurt in the publishing of this blog post.

Over my career, I have had the opportunity to be on both sides of an interview table. I have searched and applied for jobs as well as sought the assistance of recruiters. I've also been the one looking for employees to add to my team to replace ones that left or to expand the team. With every experience on either side of the table, I've walked away feeling that something wasn't quite right with the process as a whole. These notions bubbled up this past week when a good friend of mine, we'll call him Bob, was telling me about his tales while searching for a job. I figured I'd retell the story here.

Bob is a fairly seasoned programmer with a number of years and languages under his belt. It takes a lot for him to change jobs because he enjoys trying to help companies become better and work close with the friends on his team. He's active in the community and has a thirst for learning anything development related. For a variety of reasons, Bob is at a point where he wants to change jobs and decides to do the interview dance. With in a short time of looking, two interview opportunities presented themselves to him.

The first was with a smaller company that sounded like a breath of fresh air compared to the corporate cubicle land that Bob is attempting to leave. The interview was held at a local coffee shop and with two very knowledgeable members of the company's development team. Having known his work from the community and online, the interviewers focused a lot on Bob as a person and what he's looking for in a company, a team, and a career. There were some discussion on technical topics; however, many stemmed from Bob's questions about the company's processes and infrastructure. Shortly into the interview, Bob found himself to be very comfortable, candid, and casual with the two people he was sharing the conversation with.

Later that same day, Bob had another interview in a different part of town. The interview was with a little bit bigger company that was comparable in size to his current employer. The interview was in a very similar office building as well. The receptionist paged the interviewer for him and then he was escorted into a small, closet of a meeting room where 2 chairs and a table barely fit. Walking through, Bob noticed the high cube walls, the silence in amongst the desks, and the lack of expressions on the faces of the few people he saw. Over the course of the interview, a lot of questions were asked that discussed fundamentals and text book definitions. There were some questions about Bob's past that were not really acknowledged by the interviewer when an answer was given. When everything was said and done, Bob was escorted back to the entrance and ways were parted.

This story provides an interesting look at how 2 different approaches are taken to a common problem; how does a company attract and hire good developers and how do developers identify good companies to work for. Hopefully, I don't have to say which of the two experiences portrayed above attracted Bob more. The interesting thing that came to my mind while Bob told me this story was not only the differences between the companies but how important the interview process is to both the candidate and the companies. Based on the story, which company appeals to you and why? How was your perception created on each company, which you had no prior knowledge of?

My Development Toolbox

noreply@blogger.com (Anonymous) — Wed, 13 Oct 2010 12:59:00 +0000

Over the years I've carried around my own personal toolbox for development. The contents has changed throughout the years; however, the purpose has remained the same; to provide me with tool, templates, and snippets to allow me to build my web pages quicker, faster, and cheaper.

In this week's post, I'll walk you through what I currently keep in my toolbox from a high level so that you may be able to build your own or add some new tools into one you already have.

General Guidelines

Before we dive too much into the contents, I want to comment on a few guidelines that I try to keep when updating my toolbox. One of the largest guidelines that I attempt to follow is that everything must be free to be reused and redistributed. The reason for this is simple, I hope to applies these items into a variety of my projects and thus am redistributing them. I don't want to worry about paying a licensing fee every time that I want to add this module or use that font. Keeping this open, free, and available to be redistributed makes everything a lot easier.

The second guideline that I follow is to try and keep a copy of the license and author information of everything in your toolbox. This includes deciding on a license that fits your views and opinions for your own works that you add. Keeping a license around will help if someone asks you when you attempt to integrate it into a project. In addition to the licenses is the author's or the source's information. This could be nothing more than a url in my opinion but knowing where you got something and who did it can help you build a network of people and sites to keep an eye on for new stuff they may develop or post.

The third primary guideline that I try to keep is to store your toolbox in the cloud and on a flash drive. Some people argue that with the device syncing powers of tools like Dropbox or Evernote that you don't really need to keep a copy with in arm's reach on a thumb drive; however, I still like the speed of reaching into my bad and tossing someone my thumb drive to get the file(s) in the event I can't interact with the cloud easily or quickly. This is often the case at conferences.

CSS Examples

The first item I currently have in my toolbox is a group of files that provide various CSS examples. These are anything from templates to style a vcard, a CSS reset file, or examples of things that I took more than 2 seconds of effort to truly learn how to do.

Fonts

This is an area where I'm still getting my feet wet; however, with the ability to embed fonts into your web pages through CSS3, having open and freely-redistributable fonts comes in handy. One good resource for learning some of the legal nuances of embedding fonts, I highly encourage you to check out www.FontEmbedding.com.

Icons

Having the right icon for a given scenario or page can cause huge improvements to a page's design. Having the wrong icons can destroy just the same as well. I found myself searching for just the right icons on the web and in various libraries way too much. Now, I keep track of the icons that I have frequently used and will constantly add to them as needed. One item that I've began to track in here too are example favicon.ico files and icons for iPhone shortcuts.

Images

The reason why I have Icons and Images in separates folders in my toolbox is because of their intent. I keep images for background images and stock photos. The stock photos I'll probably branch out as my collection grows. As for the backgrounds, this ranges from simple gradients to watermarks to signify drafts or beta releases.

Scripts

I use this folder in a similar way to that which I use the CSS section. Here I keep a list of utility scripts (like an Html5 Feature Detection script) as well as snippets on how to use certain jQuery plug ins or do something else through JavaScript

Templates

This section of my toolbox is used for a variety of different scenarios. Since my day job is working in the Microsoft .Net space, I have a number of Project and File templates in this directory (since the ones that come out of the box in Visual Studio hurt my head). This is also the place where I keep track of other design and layout templates that I've either made or have found online

Utilities

My utilities folder is for any reusable, compiled component. This include stuff like a tool for handling database version migrations, database documentation, a random password generator, and abstraction classes that I can quickly plug into my .Net projects without worrying about rewriting the same abstraction layers over and over again.

Web File Examples

This folder I use for references and as a launching pad for creating some files. This folder contains a files that lists the DocTypes that I use the most, an example robots.txt, a sitemap.xml, opensearch.xml, and dublin.rdf. These are files that are missed in a number of templates and having them available makes it easy to add them in.

Personal Information

This isn't so much a folder as just a category of other items you should toss into your toolbox. Some of these items would be check lists that you use to keep yourself on track or to define a process that you have with your workflow, a copy of a personal biography that you may use for a presentation, a vcard of your contact information, a copy of the license(s) you place your own work under, and a copy of your CV or Resume.

That's my current toolbox. Obviously it's web heavy; however, that's where I find myself the most these days and what I enjoy doing. There's so much out there to learn and do and apply to your day jobs, it's nice to be able to have the resources you need and are familiar with at your finger tips.

-J

Code Shot - hCard Template

noreply@blogger.com (Anonymous) — Wed, 06 Oct 2010 13:40:00 +0000

In this Code Shot post, I'll provide a sample template that I've used in the past for marking up and styling address information in the hCard microformat.

Html Template



<div class="vcard">

<a class="fn org url" href="http://randomactsofcoding.blogspot.com">Random Acts of Coding</a>

<div class="adr">

<div class="street-address">123 Any Street</div>

<span class="locality">Some Town</span>

<abbr class="region" title="Missouri">MO</abbr>

<span class="postal-code">12345</span>

<div class="country-name">USA</div>

</div>

<div class="tel">

<span class="type">Work</span> <a rel="nofollow" href="tel:1234567890">123-456-7890</a>

</div>

<div class="tel">

<span class="type">Mobile</span> <a rel="nofollow" href="tel:0987654321">098-765-4321</a>

</div>

<div>Email:

<span class="email">name@domain.com</span>

</div>

</div>

CSS Template for the Html



div.vcard

{

margin:5px;

font-size:0.6em;

}



div.vcard .url

{



}



div.vcard .org

{



}



div.vcard .fn

{



}



div.vcard .adr

{



}



div.vcard .adr .street-address

{



}



div.vcard .adr .locality

{



}



div.vcard .adr .region

{



}



div.vcard .adr .postal-code

{



}



div.vcard .adr .country-name

{



}



div.vcard .tel

{



}



div.vcard .tel a

{

text-decoration:none;

color:Black;   

cursor:default; 

}



div.vcard .email

{



}

Example

Random Acts of Coding

123 Any Street

Some Town MO 12345 USA

Work: 123-456-7890

Mobile: 098-765-4321

Email: name@domain.com

Additional Resources

Code Shot – Doctypes

noreply@blogger.com (Anonymous) — Fri, 01 Oct 2010 01:51:00 +0000

First Quick Code Shot…less talk; more code.

Xhtml 1.0 Strict

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

Xhtml 1.0 Transitional

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

Html 4.01 Strict

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">

Html 4.01 Transitional

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">

Html 5

<!DOCTYPE html >
There are others; however, these are the primary ones that I either use or have seen a decent amount in the wild.

-J

A New Format Coming

noreply@blogger.com (Anonymous) — Wed, 29 Sep 2010 17:26:00 +0000

I'll admit, I've been pretty lax on my blogging as of late. This has been due to a number of reasons / excuses that I won't bore you with. Regardless, it's a part of my life that I'm working on getting back into the habit with.

One issue that I always had with blogging was the time aspect. A commentary post would take me 2-4hrs to write and post while a code one could take me 8-24hrs depending on the size and depth of the material.

Starting this week, a new format of code-related posts will begin to trickle onto this blog. I'm dubbing these Code Shots since they are going to be terse and more focused on the code them the blocks of text surrounding them. This format makes a lot more sense when you 1) the samples are simple and short and 2) most of the people who read this blog can read code.

Expect some Code Shots on topics ranging from Html5 to JavaScript and even inter-language interop.

Stay Tuned!

- J

The Paradox of Choice for a Programmer

noreply@blogger.com (Anonymous) — Wed, 08 Sep 2010 02:11:00 +0000

In everyone’s life, we strive to find our own self-identity. Some of us establish ourselves rather naturally while other’s take a while to truly understand and mold their own self truth. We see it every day with every time we experience new things and try out different solutions to a problem; be it in algebra, Rubik’s Cube, or even a more socially-related problem. This search for self-identity is apparent to everyone since no one wants to be a nameless drone who mindlessly obeys big brother; we want to stand out from the rest. We want to be unique, just like everyone else. This sense of identity and individualism surpasses the realm of how an individual acts or behaves, it also crosses into a realm of how a person shapes their career. While this is an extremely important factor in some fields (i.e. Journalism, Politics, Sports, etc), it can also cause issues in other fields.

Individualism in a career leads to people trying to be the best at what they do. Journalists and photographers strive for the recognition of fame and prizes; politicians strive to be elected. People strive to seek value in what they do and eventually hope to build a reputation (and furthermore a legacy) around their works and their individual brands; however, this could also turn into a self destructive motive in some fields. One such field is software development.

No field isn’t without its celebrities. In the greater Information Technology field; it’s hard to argue that Bill Gates, Steve Jobs, and Linus Torvalds are amongst some of the names that come to mind as “celebrities” in the culture. In every development circle, be it .Net, Java, Lisp, or Ruby, there are also those types of people who tend to stand out and people recognize the names. At a micro level inside of your company, is there a celebrity or “go-to” person whenever there’s a crisis that tends to wave their hands and make the fires go away? Here’s the catch though, what happens when your company has more than 1 of these people?

Software developers are a lot like carpenters, in my opinion, when it comes to individualism. Each professional has a set of restraints but no 2 may do the same thing the same way. Sure there are frameworks and regulations that have to be adhered to but in the end, how the product was ultimately constructed could be vastly different. This is where the issue of individualism in our profession can be seen the greatest.

I once worked for a company who wrote a number of different software solutions for a wide variety of clients. These projects ranged from Business-To-Business process to e-Commerce sites to internally used CRMs. For years the request always came in and for years the same types of application were developed from scratch. Admittingly, I was part of the problem; I focused on the differences and argued that a standard platform couldn’t be developed. Experience has taught me that I was wrong in those days. The issue with reinventing these applications each time was each one was different to varying degrees depending on who developed it. As developers on the team shifted from project to project or as new developers came on board, the projects turned into a nightmare of a learning curve. In addition to the learning curve was the issue that it caused deadlines to be extended. The only advantage was that each developer learned from their past experiences (usually).

Obviously, the need to automate the foundation was seen but at this point, the paradox of choice sat in. Which of the various frameworks that other people had made do you chose to be the basis of all applications going forward? Since we’re talking about business-related decisions, it could turn political at times and personal matters of pride at others. It’s not an easy question to answer. The same can be said about a new, rank amateur developer who just started or is thinking about starting. Not only is it a choice of platform (Web, desktop, etc.) or language; but also a matter of what frameworks to use with such. If we target .Net and pick C# and the web platform; MS now has ~4 frameworks to focus on (Silverlight, WebForms, MVC, WebPages)…looking at just MVC, there’s a large list of subprojects by other developers within the community who enhanced it in their own image; some more widely known than others. A person may ask which is better on a forum and then the whole pissing match of which framework tastes great or is less filling. A person become paralyzed by the amount of analysis he or she feels just to make a simple decision. This is the paradox of choice; too many choices leads to analysis paralysis. Below is a video that accentuates the paradox of choice further if you are interested.

So what is a person and/or company to do when faced with a number of individuals who believe theirs is the best way? Ultimately, just decide. To an extent, this is risky; however, nothing says that you can’t change later. Egos will subside since the goal is to work more efficiently as a company, as a collective. Put the vocal critics in the forefront of the decision since they, theoretically speaking, will be the most critical of the decision and have their eyes open the most to issues that may arise. For those issues, those same people may turn into the ones who enhance the decision more into something even better for the whole as well. Furthermore, nothing says that you can’t decide to focus on the parts and not on any whole framework. Sometimes, it’s better to find small tools and utilities instead of something completely encompassing. The key though is to just decide and don’t be afraid to change if you need to later. People can still make a name for themselves and still seek individuality within and outside of a company and community. The secret is to strive for the collective of a given company to form their own group identity for when that happens, individual styles will merge and anything is possible.

Social Media - The Way of Becoming Antisocial

noreply@blogger.com (Anonymous) — Sun, 22 Aug 2010 04:36:00 +0000

I'll get back to the code-related posts shortly; however, right now I just want to type something up that has been on my mind recently. I've been looking at the affects Social Media streams have been used by different people and entities while also watching the trends of other industries. Quite frankly, I'm scared what the future holds. In my opinion, social media gives people a false sense of connectivity to people and popularity. Seriously, do YOU truly care how many followers you have on Twitter or how many friends you have on MySpace or Facebook? How often do you meet those same people in person and under what occasions brings such a true in-person interaction?

I use Twitter for a lot of fast questions and to get information on the career aspect of my life. I use it, and thus the people I follow, more for their collective humor and knowledge than to really have conversations about their kids or their ailing relatives. Facebook I use for more personal reasons to keep in touch with friends I've made over the years that have moved away...people I miss and always want to share a pint with whenever I'm in their city. Sure there's a few local people I follow in both streams but the ratio is more in favor of distant friends.

Before the land of social media grew greater than IRC, IM, and Email, I loved getting a bunch of people from work, school, and from wherever and have a great time with a lan-party or a bar-b-que. Back then it was Warcraft II, Quake II/III, UT, and Starcraft. The days were great. Now look at the current game scene...the amount of co-op games are few and even Starcraft II doesn't (currently) offer LAN support. Playing over the internet is great but there's something to be said about sharing beers and obscenities with the person on the other side of the table who just killed you in the game.

How well do the people you connect with know you? How well do you allow them to know you? The people you work with will always fall under those you'd go out for a beer after work with and those you wouldn't. These are people you work with and interact with every work day...assuming you don't work remotely. Now a days there's a lot of people who say you should always manage your personal brand online and not ask stupid, "n00b" questions online or reveal some embarrassing facts and what not. These are things you can't really hide in person because such things affect our personality. If you only talk to people online and pretend your a genius, what happens when they find out your a fraud?

Social media has a place but a person still needs the in-person interactions. The trust you get from such is better than anything else you can get from just the 1's and 0's that come over the wire. A couple years ago I was told by a complete stranger (to me) that my grandfather was one of the greatest people he ever knew; the most honest and genuinely good person that this person had ever known supposedly. I don't doubt this stranger's opinion of my grandfather; however, it still makes me hope that I can live up to social precedence that my grandfather placed on this one person that effected him so much that he had to relay such information to a grandson he just met. Do you think ANY of your friends on Facebook or Twitter or MySpace will ever relay that information if they met one of your relatives? I truly don't know how it's even possible.

And Now For Something Completely Different

noreply@blogger.com (Anonymous) — Thu, 24 Jun 2010 00:33:00 +0000

It's been a crazy past couple of months. Between all but reaching the point of burning out and having some family things I had to focus on, I was stretched pretty thin and had to make some cuts in my routine. From such, I have some ended up with some interesting observations and frustrations that has me changing my focus for this blog and my own pet project stuff. Some of these changes will lead to a lot of fun projects while others may piss off a few people. Hopefully, these changes will help inspire me to keep working on some new projects and to keep fueling the blog with some new content.

So What's New?

First thing's first...I'm turning into a Mac guy. After over 2 decades of using PCs, I ended up transitioning to a Mac over this past month. I have used Apple IIs and early Macs back in the day but those don't compare to the Macs of today obviously. After using my new MacBook Pro for a while, I may be completely changing everything to use my Mac. This means all of my personal .net development will more than likely be exclusively Mono-based. This leads to some interesting opportunities about not using Visual Studio or even Windows and has been a fairly painless transition thus far.

More things that the Mac opens up is that it provides a great platform for branching out to other platforms; namely Python, Ruby, Java, and mobile development. Yes I could do all of the same development on a Windows box; however, there are some tools and issues I've had in the past. In addition, if I was on a Windows box, I'd be tempted to use IronPython or IronRuby more. I like those languages from the little bit that I've played with them; however, I'm a firm believer that fundamentals are sometimes better than abstractions. So I'm going to be focusing on using the core languages first and then integrate the Iron* languages into my dev work later.

Why New Languages?

I used to be a Java developer years ago. Around the time .Net came out is when I transitioned into the MS world more whole heartedly. I'm working on getting back to my roots while expanding my knowledge into other realms. Over the past handful of years, I've seen the MS-related communities change in a way that, in my opinion, isn't good. A lot of this has been described by other people but from my own personal experience, I feel like the MS-related communities are like the subdued humans in Apple's famous 1984 commercial. It feels like as a community, the status quo has turned into going someplace and being told about a product that was released by MS. I'm guilty of falling into a trap as both a presenter and an observer. I would go to use groups and conferences and sit and listen while someone talked about the latest technology provided by MS. As a presenter, I was the one who put on the dog and pony show for the Managed Extensibility Framework. This blog is a testament to my own hypocrisy.

The issue that I have with this model is that it seems that over the past two years, almost everything has turned into one large non-commissioned marketing machine for the Microsoft way of doing things. I used to be all about Silverlight but now I can't look at it without feeling that it's a web-hosted version of VB6. I would love to say that I was excited to see ASP.Net MVC when it was released; however, around that same time, I was beginning to experiment with Rails and Django. Even to this day, the latest version of ASP.Net MVC doesn't really hold a candle to those frameworks. Yes there are some major differences in the foundations of those platforms; however, even from a feature perspective, the MS stack is lacking. In short, I feel that Rails and Django are significantly better platforms for developing web-based solutions than the MS provided stack.

Admittingly, I haven't looked too far outside of the MS stack myself. I looked at using nDjango and it was a huge change for a common VB or C# dev. I haven't looked at FubuMVC, Spring.Net nor MonoRail so these solutions may fill in the holes during my feature comparison. Even if these other open-source .net frameworks allow for better, faster, cheaper web development; there are still a lot of things that just doesn't exist in the MS space. The largest one being a package management system but it's not the only one.

Solution frameworks "measuring" aside, the community is beginning to concern me more and more every month. The perceptions are skewed. Mine was and to an extent, still is. I used to think that anyone who presents or has a blog is a super star. I have been called such; however, I assure you, I'm not. I started this blog and began to do speaking because I love to talk about technologies but also to provide an outlet to learn better. When I was doing Java development close to a decade ago, the community seemed more about helping each other and swapping war stories on how a developer fixed a given situation. I've never had that feeling at any .net function I've been to outside of an open space slot at a conference and even those are a crap shoot sometimes. The dialog between community members feels very limited. Twitter has been great for bouncing ideas and getting help to questions but applying such to a bunch of developers in a room at a conference seems to be difficult. Participation for such open discussions, round tables, and dojos seems to paralyze people. This is concerning.

So What Am I Going to Do About it?

I was told a long time ago to not bitch about something unless you offer a solution or at least some way to possibly change/improve what you're bitching about. To that end, I'm dramatically reducing my .Net coding outside of my day job. I want to learn more about other communities and languages and techniques. I learned a ton when I was playing around with Rails and Django years ago and, to a more MS extent, Subsonic. I want to continue learning such so that I can help apply those ideas back into my day job, my presentations to user groups and conferences, and of course this blog. If anything, more hybrid projects will come from such. I fully support mixing languages in solutions in order to take advantage of each language's strength. I have started working on a project that is utilizing HTML5, C#, F#, an Object Database, and IronRuby (for testing). This isn't something you'd see in today's .net ecosystem and it's not really advocated much by those who are doing MS's marketing. I'd love to see it in the wild but it's a far stretch for a number of reasons. Regardless, I'm going to be working on seeing about applying different concepts across the languages and see how things go.

So stay tuned. There's a lot of new stuff that's going to be coming down the pipe shortly and it'll truly be fairly random.

My Thoughts on Pex

noreply@blogger.com (Anonymous) — Sat, 15 May 2010 17:36:00 +0000

Earlier this week at work I got an email asking me to install Pex, Microsoft Research's White box Unit Testing framework for .Net. While my company falling into the "early adopter" category (we're already on .Net 4 and VS2010), this one surprised me since it's a Research project. I briefly looked into Pex last fall and didn't get too into it since I was content working with NUnit and my current unit testing tools. Now that it appears that I may be using it to some extent at work, I decided to take a more meaningful look at it.

Like I said previously, Pex is a MS Research project for doing White Box Unit Testing in .Net. White Box unit testing means that the tests are focused to cover the current code. This is one of the shining aspects of Pex; it will scan the code to be tested and generate unit tests that cover all logical paths within it. This is a great way to bring your code coverage up if you aren't getting the coverage rate with your traditional habits. After Pex scans and tests the code, you can drill into the tests themselves as well as the results. Pex allows you to update your own code with conditions specific for code under test too.(e.g. Pex can add null argument validation code if you so desire) When everything is all set with the tests that have ran, you can save them out into a separate or existing project so that they can be ran again later. In addition to all of these things, Pex comes wired up and ready to use an assortment of Unit Testing frameworks beyond MSTest so that it can play nicely with your existing tests and test runners also.

While those elements are awesome and helpful, there are a few things that turn me off of the framework. Pex will dive into all dependencies found with in the code under test. Where you traditionally may mock or stub out a dependency, if there's a hard dependency found, Pex will dive into it. Now, this can be averted using some form of IoC container or Isolation Framework (more on this below); however, if you don't use one of these, that code will be tested as well. In addition, Pex only tests Publicly exposed code. If your code is marked as anything other than public, Pex will inform you that it can't test it. This doesn't bode well for software businesses who have a lot of internal classes. During my tests, I even tried to use the InternalsVisibleTo assembly attribute and it still wouldn't work with it. Lastly, I was a bit disappointed in Pex only scans the currently active file inside of the IDE. While there's a command line way of running Pex, supposedly, from within Visual Studio itself, Pex can only work with 1 file at a time.

Finally, Pex has this nice little buddy called Moles. Moles is an isolation framework for handling dependencies. You can use either without Pex; however, they are closely tied together from a project and documentation standpoint (if you find info on Moles, you'll almost always find info on Pex and visa versa). Moles focuses on generating Stubs in the same way as frameworks like Rhino Mocks and NMock2; however, it also has what it calls Mole objects which focus on Sealed, Static, and or Privately scoped classes. I did not dive too deep into Moles; however, it would appear that it does not mock these types but rather intercept and detour the method calls into the implementations you wire up. From my understanding this is similar to how TypeMock handles the same task.

Overall, I think Pex is a good product for people trying to get their code coverage up and are in a Test-Last mentality. It works great under that situation and makes for a great candidate for automating unit test generation of DTO/Domain Model classes that tend to be public due to how they get passed around and usually consist of just getters and setters. It's not a tool I see myself using personally, though. I'm human and can see a very difficult argument in justifying a Test-First approach beyond design when Pex can/will write the tests for you. Applying that logic to a business environment and justifying a few minutes to write some tests to a manager vs a few seconds to run Pex and generate more tests is a hard sell.

Iowa Code Camp - Spring '10 Review

noreply@blogger.com (Anonymous) — Sat, 15 May 2010 15:34:00 +0000

Back on the first of May, many from the .Net community in the Midwest flocked to Iowa City, IA in order to attend the Iowa Code Camp. For those that aren't aware, Code Camps are community driven events where speakers volunteer to give presentation on a variety of topics for people to come and learn. The Iowa Code Camp happens twice a year and every time it's been a great event.

This Spring's Code Camp saw me presenting my talk on the Managed Extensibility Framework (MEF). The talk went fairly well in my opinion though we are our own worst critics sometimes. The feedback I got on the talk was very constructive and gave me a lot of things I need to work on beyond what I was able to find from personal reflection. I also ended up recording my talk using my Flip MinoHD camera which works very well other then the fact that it's hard to tell how the HD video truly looks on a tiny screen. If you present, I highly recommend that you record yourself either in practice and/or presentation in order to obtain additional feedback on yourself; since you know the subject matter, you'll find more things about your presentation style and quirks that many evaluation forms miss.

Beyond my presentation, there were 4 other time slots/talks available for me to attend. This specific code camp I wanted to focus on solidifying my knowledge of topics that I have pretty much taught myself. While I was very confident in my abilities with the code-related topics, I wanted to see another person's perspectives of such so that I can gauge my own understanding and learn a few new tips as well. Below is a rundown of the sessions I attended:

IoC with StructureMap - By Brad Tutterow

Inversion of Control and Dependency Injection have been topics that some people get and some people still don't fully see the value of it. I got it pretty quickly because of my TDD experience; however, am always interested to learn new things about IoC containers and the patterns in general. Going into this talk I figured there'd be some discussion on the principles and patterns; however, there'd be a lot of discussion on how to use StructureMap. What the presentation turned out to be was a jewel. The polished presentation focused probably 75% on IoC and DI with the last 25% being about StructureMap. Brad did an excellent job in not only explaining the "What" of the topics but the "Why" as well. Looking throughout the audience, I could see some people finally understand it and it's importance. In addition, Brad provided a great, evolving example that went from tightly coupled to decoupled to implementing StructureMap for fully handling all dependencies. The time with StructureMap may have been less than I expected, but the value of the presentation as a whole completely outweighed my curiosity on the "How".

TDD Dojo - By John Teague

I've been unit testing my own code on side projects for a while now. I don't always push them in my blog post examples (I should though; I know); however, seeing a true TDD with pair programming session was something I wanted to observe and partake in. In my opinion, a person's adoption rate of TDD and specifically Test-First is directly related to how close they are to finding that spot in Red-Green-Refactor where they write enough tests and code to feel meaningful. I've seen a lot of people get turned off with the RGR pattern and TDD's principle of doing the bare minimum because it seems too simple and impractical; however, if you can find a level between writing all of the code and writing the bare minimum, usually they begin to adopt it more.

This issue is one of the things I felt from John's session. John's session was broken up into 2 sessions and I only stayed for the first half. In the first half, there was a wide assortment of experience levels among attendees. Some people have been doing TDD for a while; however, there were a number that either rarely unit test or have never unit tested at all. This range made some people question to simplicity of TDD's cycles and the perception of the impracticality of it all. Despite what the session abstract said, I believe people were expecting slides on how to do TDD instead of a more hands on approach...the different format, which included pairing in front of everyone, seemed to make some uncomfortable.

With that said though, John did a great job in handling all of the questions and comments and an even better job in helping people pair up and begin to get familiar with TDD. It was really good to see a ~~talk~~ session in a different format and a practical flow. It was really good to see how attendees who finished their pairing time to come back with a "I get it" look on their face.

Open Session

There were no open sessions on the schedule for Iowa Code Camp this time around. I had every intent to continue with John's Dojo for the second half; however, a few of my friends were in the session had never written a unit test and were a bit overwhelmed. When I ended up doing instead is taking one aside and worked with him on a one on one basis to help him understand unit testing, in general, a bit better. One thing I wanted to make sure though was to use the same frameworks that John used in the first half of his Dojo since he covered the basics of seeing up a test class and test methods. The developer I worked with absorbed these aspects of John's session; however, was having a hard time seeing how to apply it. For example: show a person who's never unit tested a test that validates a method returns true is great; however, they tend to get lost in the practicality of the test when the method body just reads "return true;". I worked with him on an example of splitting a paragraph into various lines after a certain length, ensuring words were not broken as well. My example was well; however, I didn't do so well on demonstrating stuff. Towards the end though, he had written his first couple unit tests though and saw it working. Now for me to go through more katas myself - practice makes perfect right?

Being a Technology Entrepreneur - By Scott Davis

This session was packed. I've looked into doing some side projects and freelance work in the past and this talk helped provide some insight on how I should go about doing such correctly from the start in the event that I wanted to go from simple freelancing to turning it into a true business. Scott's advice was fantastic and the information he provided on the types of things to be mindful of was invaluable. He kept everything relevant from things you should do when dealing with an attorney or accountant to what and how long it takes to setup a business with your local state. His information on what types of businesses you should be looking at as well as how companies like Microsoft can help out as well. Scott's talking again at the Kansas City Developers Conference in June and I may be attending the talk again since I know there'll be more things I didn't pick up on the first time around.

Learning Distributed Source Control with Mercurial - By Chris Sutton

Chris was kind enough to allow me record his talk despite the fact that I went to a different session (Thanks again, Chris!). I have very little knowledge of Mercural (Hg) or Git so I was hoping to attend a talk on one of these while there; however, there were so many good sessions I had to resort to my recording. Chris did a great job on presenting Hg. He provided a great explanation of distributed version control systems and how they different from more traditional options like Subversion or Team Foundation Server. His examples showed how to use Hg in a variety of tasks. There were a lot of good questions during the discussion in terms of branching, merging, and comparisons which Chris fielded very well. This talk wanted me to move all of my code to a dvcs instead of the systems I've been using up to this point.

Reflections

After looking over my notes and the conversations I had surrounding the event; I wish it was longer. Being able to bounce ideas from other developers and also focus on ways to make the event better was great. Everyone involved in putting on the event was fantastic and for that Thank You! I'm looking forward to (at least) attending the next Iowa Code Camp in November and see what may come from that.

Outside of the great event, there were a lot of things that I noticed. The talks with the most interest were associated with either mobile development or Scott's Entrepreneurship talk. Mobile is a hugely hot topic in the industry and the entrepreneurship talk's attendance matches what I've been seeing on Twitter and other conversations. There seems to be a desire for information on how to be better outside of the code. This is not to say that there should be talks on how to be a manager; however, how to be better at business, interactions with others, and skills that are important but not about really writing code. I've been seeing this for a while; however I'm seeing the trend increase for things like Scott's talk as well as Brian H. Prince's Soft Skills talk.

In addition, I noticed the experience gap. Now, I'm not expecting everyone to be super star developers; however, I see a need for something additional to be made available to help those understand concepts they may not fully understand before or even after a topic. There isn't a magic bullet that provides the solution to this, but it's something that I am brainstorming on. Should there be a 100% open spaces track dedicated to "mentoring" and helping people out with different topics or projects than just a discussion of random things like some open spaces turn into? Should there be prerequisites suggested for every session? Am I actually just imagining this gap?

Lastly, this code camp brought a lot of insight into myself. After seeing the presentations and also this TED talk on how leaders inspire action, I'm going to be changing my MEF presentation around a lot. Brad did a great job in his presentation in building an understanding of why things are important and why he's passionate about such. This is something that I felt was lacking from my presentation. In addition, I'm hoping to get more involved in the near future. Do I know specifically what that means, no but that's the beauty of community, people can fill where the need is. In addition, I may be moving my presentation focus away from tools and into a more community focused array of topics; like Interviewing Skills, getting involved in Open Source Software, and ways to become a better developer and getting involved in the community. Needless to say, there's no shortage of things I can improve upon with in myself and my abilities. I can't wait to see how I'll grow and be ready for the next Iowa Code Camp.

Contact Information:

My Managed Extensibility Framework (MEF) slides from the Iowa Code Camp

noreply@blogger.com (Anonymous) — Fri, 30 Apr 2010 22:30:00 +0000

Below are the slides I gave at the Iowa Code Camp on May 1st in Iowa City, IA.

Mef 12 step program

View more presentations from JamesEggers.

Demo Projects

Hiding Parts From InheritedExport

noreply@blogger.com (Anonymous) — Thu, 15 Apr 2010 01:31:00 +0000

In a previous post in my ongoing series on the Managed Extensibility Framework (MEF) I discussed using the InheritedExportAttribute in order to simply export declarations throughout a class hierarchy. This attribute can be applied to either an Interface or a base class. However, what if you wanted to implement the interface or inherit from the decorated base class (either directly or indirectly) but didn't want this new derived class to be imported during composition? Thankfully, the designers of MEF thought of this issue and created the PartNotDiscoverableAttribute. This attribute is very straightforward; simply place it on the part you wish to exclude and MEF will ignore it.

Post Links

Using MEF with Signed Part Assemblies

noreply@blogger.com (Anonymous) — Thu, 15 Apr 2010 01:01:00 +0000

Over the past few months, I've been giving a number of presentations over the Managed Extensibility Framework. Every time I've given the presentation, the same question has came up - "How was signed assemblies and security factor into MEF?". Ultimately, I didn't have an answer at that time since my experience with the need to do assembly signing has been limited, and my perception is very trusting when it comes to plug-ins and extensibility. Regardless, I don't like not having an answer on a subject I'm presenting/teaching. So, in this post, we'll look at the challenges that exist to ensure that any assemblies that contains parts is signed and how to control composition of those assemblies in your MEF-enabled application.

Important Links

How To Check If An Assembly Is Signed?

While I have said that my experience with signed assemblies has been limited, I have always created or consumed signed assemblies. This was great when adding references but the point of using MEF is to ensure we don't have to add references and recompile. How do I check if an assembly is signed without having to add a reference and recompile the code? After doing a little digging, I wrote the following unit test:

   1:  [Test]

   2:  public void Check_Unsigned_Assembly()

   3:  {

   4:      var assembly = Assembly.GetExecutingAssembly();

5:

   6:      Assert.IsEmpty(assembly.GetName().GetPublicKey());

   7:  }

8:

   9:  [Test]

  10:  public void Check_Signed_Assembly()

  11:  {

  12:      var assembly = Assembly.LoadFile(ASSEMBLY_ONE_PATH);

13:

  14:      Assert.IsNotEmpty(assembly.GetName().GetPublicKey());

  15:  }

In the first test we are loading the test assembly which isn't signed; however, the second test uses a signed assembly. In these tests we are checking the assemblies' AssemblyName by calling GetName() and then GetPublicKey(). If the PublicKey values, which is a byte array (byte[]), is empty, then the assembly is not signed. That's easy; however, if 2+ assemblies are signed with the same .snk file are compared, do they have the same PublicKey value?

   1:  [Test]

   2:  public void Check_Signed_Assemblies_For_Same_Key()

   3:  {

   4:      var assembly1 = Assembly.LoadFile(ASSEMBLY_ONE_PATH);

   5:      var assembly2 = Assembly.LoadFile(ASSEMBLY_TWO_PATH);

6:

   7:      CollectionAssert.AreEqual(assembly1.GetName().GetPublicKey(),

   8:                                  assembly2.GetName().GetPublicKey());

   9:  }

Short answer....yes, the keys are the same. Now that we know how to test for signed assemblies and know that assemblies that are signed with the same key have the same PublicKey byte array value, let's look at how we can push this into our MEF-ed out application.

Validating Part Assemblies Are Signed

There are a few ways we can apply the logic we explored using the unit tests above. We could loop through a directory of assemblies and validate the assemblies prior to adding each one as the target of an AssemblyCatalog for an AggregateCatalog. Ideally, we would probably want to wrap that logic as a custom, extended catalog in order to make it reusable if this is something you'll need more often. For this demo though, let's just keep everything local to our application through the below method:

   1:  private void Compose()

   2:  {

   3:      var key = Assembly.GetExecutingAssembly().GetName().GetPublicKey();

4:

   5:      var catalog = new AggregateCatalog();

   6:      catalog.Catalogs.Add(new AssemblyCatalog(Assembly.GetExecutingAssembly()));

7:

   8:      var dir = new DirectoryInfo("Plugins");

   9:      Assembly assembly;

10:

  11:      foreach (var file in dir.GetFiles("*.dll"))

  12:      {

  13:          assembly = Assembly.LoadFile(file.FullName);

  14:          byte[] assemblykey = assembly.GetName().GetPublicKey();

15:

  16:          // custom compare method

  17:          if (ArraysEqual(key, assemblykey))

  18:          {

  19:              catalog.Catalogs.Add(new AssemblyCatalog(assembly));

  20:          }

  21:      }

22:

  23:      var container = new CompositionContainer(catalog);

  24:      container.ComposeParts(this);

  25:  }

In this method, we're adding AssemblyCatalogs into an AggregateCatalog only if a located assembly is signed. If the assembly is not signed, we're not going to load it for this particular composition. Other parts of the application may use all assemblies but for this method, we only want to be signed assemblies that have the same key as the executing assembly. Sounds simple enough, right? Well, there are a few things you need to do to make this work.

A Caveat to Implementation

The first thing I ran into when I tried to implement this with MEF Preview 9 out on Codeplex was that the MEF assembly isn't signed. This wouldn't be an issue except for the fact that any signed assemblies cannot reference unsigned assemblies. So, if you expose a public assembly that contains a custom ExportAttribute or a base class/interface that is decorated with the InheritedExportAttribute, you'll need to have that assembly signed so it can be used by those extending the application. Since that assembly is going to be signed, then it needs a signed version of MEF. It's a vicious cycle. Once you have your core application signed (since it needs to referenced your signed public assembly), you're good to go. In the accompanying C# project, I created a signed version of the MEF Preview 9 source and referenced it in each project that needed such.

Summary

While this is more proof of concept code, it hopefully illustrates what can be done in order to verify not only how to selectively load assemblies that contain MEF parts based on if they are signed or not as well as dependent on the key too. Like I said before, the above code could be refactored into a custom and/or extended catalog in order to simplify the logic in the Compose() method as well as advocate reusability.

Update:

After passing this post around, I was informed that checking to see if the assembly is signed with a public key and/or that if the key matches an existing key is not enough for security sake. To take it another step further, please check out the below blog post by Andreas Håkansson (The Code Junkie) that describes how to test for a strong name as well.

Checking An Assembly for a Strong Name and Specific Public Key - By Andreas Håkansson (The Code Junkie)

Development Achievements

noreply@blogger.com (Anonymous) — Fri, 26 Mar 2010 20:32:00 +0000

A couple months ago, I came across this question over on StackOverflow. In a nutshell, the question was wondering what people have experienced and recommend on how to go about training an intern developer. I took the approach of any developer as opposed to focusing solely on an intern level person because to some degree we are all "that" person when we first joining a new company with new practices, products, and code. My recommendation for that question revolved two ideas. First, around training the person on the product(s) that the person would be using as if they are an end user so they have the context of the application(s). The second idea was a peer programing/mentoring aspects that many of us have heard about yet not as many have experienced.

A Missing Piece?

Since I posted my answer though, I began to feel as if there was something missing. My answer to that question revolved around my own experiences as a new developer in a company as well as mentoring/training new developers that join a company that I'd been at for years. Something still felt like it was missing though. What if the person didn't like the direction of the product/application and is uncertain about speaking up? What if they are anti-unit testing when they join a team that does such? How do you make sure that the developer made the right choice by accepting the offered position while providing long term motivation for more veteran developers on the team?

These questions outlined the missing piece. How to motivate and keep the people involve is a huge thing to new developers. Sure regularly going out to eat for lunch with other team members can help build friendships and a sense of belonging but what if the intern's job for the first 3-6 months is doing nothing but very remedial work? If I was an intern and been able to do a large amount of coding but was told to only do unit tests for the first 3-6 months at a job without the ability to truly change directions or suggest tools, I'd be questioning my decision of joining the company or (if I was brand new to the industry) the career as a whole. I'd probably feel that I was capable of more even if I was a bit naive. We all have to do the grunt work but how do you mitigate the ceremony and monotony of the pieces that cannot be automated?

Is Achievement System Possible?

This got me to think about the theory of inconsistent rewards which says, in a nutshell, that inconsistently awarding rewards can lead to continued behavior. This behavioral theory is what makes gambling addicting as well as the badge systems (i.e. FourSquare, StackOverflow) and achievement systems in video games work so well. Could this work for developers and development teams? In my opinion, yes and no.

In my opinion, the ability to apply an arguably meaningless recognition system together for the greater developer community with regards to experiences is impossible. Yes, there are a few pieces of low hanging fruit that could be applied to just about every development shop like "Wrote x Unit Tests", "Refactored x lines of code", "Demonstrated good SOLID Practices", etc.; however, those things don't truly map well beyond the basics and theories when applying such to an internal team's focus. With such a low common denominator of options that could be applied across the board, I wouldn't be surprised if such acquired the same stigma of most industry certifications.

However, what if the focus was moved from the global scale of all developers down to an individual team or company? All of the sudden you have achievements associated with adding new technologies into the company, migrating legacy code to a new platform, did X to project Y, an "expert" in project Z, and more. This can turn into motivation tool in that you want to obtain those achievements as well as help identify the "go to" people on certain things. If someone doesn't have the "wrote first unit test" achievement, then more than likely that's not the person you'd want to talk to if you have a mocking question.

What Would It Take?

Looking solely at a team/company level of implementation, there are a few things that would have to be done in order to ensure that an achievement system could be implemented. First, there'd have to be some place that showcases each developer's achievements. What's the point of awarding something if it's not known by people? This could be a bio page on SharePoint or something else. Personally, I don't like hanging certifications or anything like that on my cube wall and the purpose of an achievement system would be to obtain more and more so hard copy forms of the achievement probably isn't a good idea. Hard copy would also be pointless if you have remote workers.

Second, there needs to be a consistent method on how to evaluate if the achievements have been obtained by a person. Many development teams practice peer reviewing their code in some fashion; some aspects of a peer review could be quantified and the achievement system could be based on such. Things like "First Unit Test", "1000th Unit Test", etc. could very easily be addressed in this way; however, there should also be a way to identify details of other achievements for giving a presentation on a new technology or similar.

Lastly, as much as I think it could work as is, I'm certain some managers in some companies who wouldn't buy the idea unless they could figure out a way to tie it into performance reviews or other process. Since the idea around the system would depend on inconsistency of awarding the achievements, I don't think it'd be a good idea to use such a system in a quantitative fashion; however, it could be used for qualitative analysis. If this need is present, it would ultimately turn into the needs of the team/company and what achievements they define.

Ideas for Achievements

Below is a list I have been thinking about that could possibly be such achievements. The list isn't in any order and are more or less me thinking "out loud". A community site could be cool if the idea works though. Some of the ideas here are criteria while others would be the idea/concept of what it's trying to convey.

Wrote First Unit Test
Wrote X Unit Tests
First Project Task Finished
First Project Task Finished Without any bugs found.
Project X - Novice
Project X - Craftsman
Project X - Veteran
Language X - Novice/Craftsman/Veteran
First Project in X Language
Multilingual (development languages)
Novice Presenter
Occasional Teacher
Educator
Implemented Technology X first

This list is not all inclusive and can grow as needed. I'm curious to know your thoughts on the idea as a whole, what else could be considered for achievements, and what implementation issues may arise. I just had the idea and figured I'd throw it out here and see what people think.

Looking Ahead a Bit

noreply@blogger.com (Anonymous) — Thu, 04 Mar 2010 16:36:00 +0000

As frequent readers have noticed, my cadence for writing has dropped as of late. Between work and the other usual excuses, finding time to blog hasn't been easily located. However, that doesn't mean I don't have a lot of things coming down the pipe in the next month or so. Below is some of the topics that I'll be talking about as soon as I can find time.

Using Automapper to easily implement MVVM in ASP.Net MVC
Looking at db4o - an object database
Using MEF with MVC

I don't know how many posts will be associated with each topic; however, there's a lot to write about and some interesting examples associated with such.

Stay Tuned.

Presentation: Extending Your Applications With MEF

noreply@blogger.com (Anonymous) — Wed, 24 Feb 2010 13:45:00 +0000

Last night I did a presentation to the Kansas City .Net User Group on the topic of using the Managed Extensibility Framework. The demos were simple and progressive and the slides were, hopefully, informative. While I'm going to be taking a lot of the feedback in order to refine/redo the presentation into something better overall, I wanted to post the demo projects and slides here so people can access them if they so desired.

Demo Project Listing:

Demo 1: On the Fly MEF Implementation of just Import and Export attributes
Demo 2: Using MEF's attributes at the class level and using labels and declarative type mappings.
Demo 3: Using the Type Catalog
Demo 4: Using the Directory Catalog
Demo 5: Using the Aggregate Catalog
Demo 6: Using untyped Metadata
Demo 7: Using Strongly Typed Metadata
Demo 8: Creating a Custom Export Attribute that contains the Metadata as well.

Lastly, this talk was registered under SpeakerRate and can be reviewed at http://speakerrate.com/talks/1922

A Look at the New DotNetMigrations

noreply@blogger.com (Anonymous) — Mon, 01 Feb 2010 03:20:00 +0000

One aspect of .Net that a lot of people struggle with is how to manage database changes. If anyone has looked beyond .Net into the realms of Ruby on Rails or Python's Django project, database management is one of the first things that becomes obviously different. Thankfully, there's been a number of migration utilities that have been ported or recreated in the .Net world. After trying out a couple of them, I began to notice that there was a wide variety of how each attempt to accomplish this pain point. Some require IronRuby scripting, many use a custom C# DSL, and some use external build utilities like NAnt to fully manage the changes. One that I was introduced to by a friend and began to really enjoy was DotNetMigrations - an OSS project over at CodePlex.

An Overview of DotNetMigrations

DotNetMigrations started as an OSS project over at CodePlex by Joshua Poehls in early 2008 when he liked what he saw in Ruby on Rails and wished there was a sql script-based version of such a utility in .Net. Unlike Rails' migration strategy which used a DSL written in Ruby to do all of the database object changes, DotNetMigrations was focused around native Sql scripts that would be read and executed by the migration engine. As the project evolved, new commands were added and updates to the Rails platform's migration strategy were also made to DotNetMigrations. Soon, it was obvious that DotNetMigrations had a lot of potential when it comes to new commands and other things. I ended up joining the project in mid 2009 to make some updates and add some commands that I required for a project I was using it on.

After my project was finishing up, I ended up beginning to think of ways to make the application easier to maintain. After some conversations with Joshua about this, we decided to go ahead with rewrite with the goals of making it easier to maintain and extend while keeping the same spirit which it was started in. This past weekend, the finishing touches were placed on the rewritten code and a new release was established with some great features.

Extending DotNetMigrations Thanks to MEF

Any reader of this blog knows that I've been addicted to MEF these past few months. When I looked at the architecture of DotNetMigrations and the goals of such, the decision to use MEF was an obvious one. MEF provides the ability to not only extend but also compose internal components of an application. One of the things we wanted to do was allow other people to create new commands that fit their needs without requiring them to recompile the application's source. MEF allowed us to do such for external commands and because of such, we also turned all internal commands to conform to the same contracts.

In addition to the command aspect of DotNetMigration, we also changed the way messages could be logged. In the older versions of the application, it acted like a standard console application with all messages being output to the console application window. This works for many scenarios; however, if you needed a "silent" program for your task scheduler or wanted to log all messages to a text file, you'd have to do a lot of additional work with the source code or pipe the command to the text file at the command line. Through using MEF and the custom configurable type catalog, creating new logs becomes easy as well as being able to utilize one or many different logging mechanisms.

What Else Is New?

In addition to the core code being rewritten to leverage MEF, we also launched the DotNetMigrations-Contrib project. The focus of this project was to allow others to suggest and share new logs and commands they have written. The components found in this project also will help allow companies who are locked into specific versions of software upgrade with new commands without having to upgrade the core app. As time passes in, some elements from the Contrib project may find their way into the core application; however, things are just starting for now.

As new features and such are added to each project, I'm sure I'll be talking about them here. Until then, feel free to head over to the CodePlex projects' sites and check it out for yourself.

Making Part Declarations Easier with InheritedExports

noreply@blogger.com (Anonymous) — Wed, 27 Jan 2010 03:24:00 +0000

After playing around with MEF for a while, you begin to find more and more locations where it could be used to extend your application. It works great for a large number of scenarios and provides a method for others to extend your apps in a way as simple or complex as you want to make it for them. However, anyone who has sought community participation can tell you that the best way to get such is to make thing as easy as possible for a member of the community to participate. If you have the greatest, extensible application in the world but require 50 steps to get a part added to the application, the user community may not be very prone to build extensions for such. Alternatively, if the work required to extend the application was whittled down to only a few steps, the probability of participation rises. In this blog post, we'll look at this pattern and show how using MEF's InheritedExport attribute can be used to make part creation extremely simple for their authors.

Reviewing Previous Examples:

In previous examples of this series, we created parts that would be placed into a directory and imported into the app based on how the classes were decorated. By explicitly decorating our parts with the Export attribute works well since it gives us the ability to say which classes to import and which not to; however, in order to use the Export attribute we also had to include a reference to the System.ComponentModel.Composition assembly & namespace. Depending on how we setup our part contacts, we would also need to add a reference to our application as well. While that's not a lot of setup, it adds up since it has to be done every time a new part has to be created. If the parts were created as part of a framework or engine, then it would be in a person's best interest to create a VS template or some other form of code generation or snippets to automate as much of that ceremony as possible. But what if there was a simpler way to address this from within the application we're trying to extend?

Simplification through Inherited Exporting:

One of the lesser-documented items contained within MEF is the InheritedExport attribute. This attribute flags all derived classes as parts that fit the contract defined by it. So instead of requiring every part that implements a particular interface or base class to use the Export attribute and settings, you can just decorate the interface or base class with the InheritedExport attribute and then every class is considered to be an Exported part by default. If you are familiar with WCF, this is similar to the practice of creating an Interface for declaring your data contracts instead of directly decorating concrete classes. Below is an comparison between the way that has been show thus far and using the InheritedExport attribute.

Previous Example:

   1:  [Export("commands", typeof(ICommand))]

   2:  public class Command1 : ICommand

   3:  {

   4:      // Implementation of the Interface

   5:  }

6:

   7:  [Export("commands", typeof(ICommand))]

   8:  public class Command2 : ICommand

   9:  {

  10:      // Implementation of the Interface

  11:  }

Inherited Example:

   1:  [InheritedExport("commands",typeof(ICommand))]

   2:  public interface ICommand

   3:  {

   4:      // Interface Declaration

   5:  }

6:

   7:  public class Command1 : ICommand

   8:  {

   9:      // Implementation of the Interface

  10:  }

11:

  12:  public class Command2 : ICommand

  13:  {

  14:      // Implementation of Interface

  15:  }

Without the requirement of marking all of the parts with the Export attribute, the developers who are creating extensible parts for your application will no longer need to reference the System.ComponentModel.Composition namespace. In addition, the risk of mistyping the contract information in the Export attribute is removed. By using the InheritedExport attribute, the only requirement for authoring parts becomes just a reference to the assembly containing the decorated base class or assembly.

A Useful Pattern of Inherited Exporting:

While the InheritedExport attribute provides a simplified and safer method of handling part creation, it is an All-or-Nothing mechanism. While there are ways to exclude parts using different catalogs, there is no way to explicitly exclude a part like you could when we were using the Export attribute on all parts. A good way around this issue is to base your part contract/type on an interface and add the InheritedExport attribute to an abstract base class that implements said interface. This provides the blanketed support and convenience of using InheritedExport while providing authors an advanced mechanism by directly implementing the interface and adding the Export attribute manually if needed. Below is an example of this pattern.

   1:  public interface ICommand

   2:  {

   3:      // Interface Declaration

   4:  }

5:

   6:  [InheritedExport("commands", typeof(ICommand))]

   7:  public abstract class CommandBase : ICommand

   8:  {

   9:      // Abstract implementation of the Interface

  10:  }

11:

  12:  public class Command1 : CommandBase

  13:  {

  14:      // Implementation of the Abstract Class

  15:  }

16:

  17:  public class Command2 : CommandBase

  18:  {

  19:      // Implementation of the Abstract Class

  20:  }

Summary:

In this post, we looked at how to streamline and simplify our part definitions by using the InheritedExport method instead of just the Export attribute. We looked at the benefits of this simplicity and how it can help make things easier for part authors as well as identified a possible fault with using the InheritedExport attribute at the wrong level of abstraction. In the corresponding example project linked below, the concepts discussed above are applied to a previous example project in order to illustrate some of the simple benefits that can be used within your application.

Resources:

A Configurable Type Catalog for MEF

noreply@blogger.com (Anonymous) — Wed, 13 Jan 2010 04:24:00 +0000

Over the past month or so, I've had some time to focus on a few different projects. In one of these new projects, I was using MEF in order to provide a number of extensibility points. Everything was going well until I started to dive into a place where I wanted it to be extensible but also configurable like a traditional provider model scattered throughout the .Net framework. With MEF, there's a couple of different ways of handling this situation; however, after playing around with a few of them, I decided to extend the TypeCatalog in order to provide another layer of abstraction that allows me to harness the power of MEF with the ability of outside configuration. In this article, we'll diving into the code that provides provider-like configuration aspects to MEF as well as shine the light at 2 possible pitfalls of using something like this. Before we do that though, let's examine what MEF has to offer out of the box in order to understand why I felt another layer was needed for my project.

Looking in the Box and at MEF-Contrib

So far in my MEF posts, I've really been focused on simple solutions that utilize the AssemblyCatalog and DirectoryCatalog objects. These specific catalogs provide a very fast and easy way of composing your various parts together. Part of their simplicity comes from how they handle the parts that it finds in the assemblies you provide it; namely, they take an All-or-Nothing approach. If they find parts that meet the defined contract criteria, they assume that they are going to be part of some composition. But what if you only wanted to use only a few parts located in a loaded assembly?
This question was half of the problem I was trying to solve for my project. Looking around what's been done so far with MEF, I saw that I could address this part of my problem using a TypeCatalog. A TypeCatalog differs from other ComposablePartCatalogs in that it allows you to explicitly specify which Types you want to use as Parts. For example, in previous posts we showed "Help Text" of various parts that represented different commands/arguments of a command line application. If you didn't want Command #2, you could simply load all other commands into a collection explicitly and then pass the collection into a TypeCatalog.
Great, one problem solved, right? I can now explicitly load which parts I want to import; however, the second part of my problem was that I didn't want to recompile the code every time I wanted to change which parts were imported. At this point, I started to look around at what other people might have already done that would allow this type of configuration. I ended up looking at the Provider Model for MEF that was a part of the MEF-Contrib project out on CodePlex. What the Provider Model from MEF-Contrib does is move the part declarations (i.e. the Import and Export Attributes) to a custom configuration section. This held a lot of promise; however, ran into some trouble while working with it. After about a day of working with the MEF-Contrib provider model, I decided to try my hand at a different approach.

Adding a Layer on top of MEF

While I'm still determined to look into the MEF-Contrib provider model deeper in the near future, I also began to feel that mixing the attributed model and a provider model in the same application felt a bit dirty or smelly. I wanted the leverage the power and simplicity MEF's attributed model but be able to push it to the level of configuration that comes with a provider model. In order to reach this goal, I decided to add another layer of abstraction onto of the great foundation MEF provides for extensibility.
In order to do this, I needed 2 things:

A Custom Configuration Section to Identify the specific Types to import
A ComposablePartCatalog that will grab these parts.

Creating the Configuration Section

I'm not going to go into a large amount of information on how to create a custom configuration section. There's a large amount of resources out on the Internet that can assist with such. What I needed was a simple section that took a collection of types. I wanted to truly keep things simple. What came out mapped to the following:

1:  <configuration>

2:      <configSections>

3:          <section

4:            name="mef.configurableTypes"

5:            type="MEFExample8.Core.Provider.ConfigurableTypeSection, MEFExample8.Core" />

6:      </configSections>

7:

8:      <mef.configurableTypes>

9:          <parts>

10:              <part type="MEFExample8.TestCommand1, MEFExample8" />

11:              <part type="MEFExample8.Commands.TestCommand3, MEFExample8.Commands" />

12:          </parts>

13:      </mef.configurableTypes>

14:  </configuration>

Creating the Catalog

Now that I have the section how I needed it, I had to create a catalog that will utilize it. While I could have create a custom catalog using the ComposablePartCatalog base class, I decided to just extend the TypeCatalog that comes with MEF. The TypeCatalog works great for such and the only thing I had to do was bring in the Types from the config file, load them into an IEnumerable<Type> collection, and then pass it to the TypeCatalog base. Simple right?
As it turned out, I looked beyond my original needs and found two issues. The first was addressing what to do if the configuration section was named differently. The second issue was dealing with what to do if the catalog is instantiated more than once. Luckily, a simple solution to both was to allow the developer to pass in the section name into the catalog's constructor. This addressed the renaming concern while allowing multiple catalogs to point to different configuration sections.
Below is the catalog's code:

1:  public class ConfigurableTypeCatalog : TypeCatalog

2:  {

3:      public ConfigurableTypeCatalog()

4:          : base(GetTypes())

5:      {

6:      }

7:

8:      public ConfigurableTypeCatalog(string sectionName)

9:          : base(GetTypes(sectionName))

10:      {

11:      }

12:

13:      private static IEnumerable<Type> GetTypes()

14:      {

15:          return GetTypes("mef.configurableTypes");

16:      }

17:

18:      private static IEnumerable<Type> GetTypes(string sectionName)

19:      {

20:          var config = GetSection(sectionName);

21:

22:          IList<Type> types = new List<Type>();

23:

24:          foreach (ConfigurableTypeElement p in config.Parts)

25:          {

26:              types.Add(Type.GetType(p.Type));

27:          }

28:

29:          return types;

30:      }

31:

32:      private static ConfigurableTypeSection GetSection(string sectionName)

33:      {

34:          var config = ConfigurationManager.GetSection(sectionName) as ConfigurableTypeSection;

35:

36:          if (config == null)

37:          {

38:              throw new ConfigurationErrorsException(string.Format("The configuration section {0} could not be found.", sectionName));

39:          }

40:

41:          return config;

42:      }

43:  }

As I stated before, I decided to extend the TypeCatalog class. In order to extend it and meet the needs of my project, I overloaded the constructor so that I could set the default configuration section name (used in the configuration file snippet above) while allowing the second constructor to specify the section name. Since the constructor of the TypeCatalog class takes either a single Type or a collection of Types, I turned the code that retrieves that information from the configuration section into a static value. Since I'm not overriding any aspects of the TypeCatalog other than the constructors, I needed a way to pass the information to it as such and the static methods provided.

Notes about the Catalog:

At this point, I have a fully functional catalog that allows me to specify which types to include into a certain piece of my application. After I played around with it a bit I found that it worked well but had a few shortcomings that may cause people to wonder what's going on.
The first scenario I came across was working with the catalog to reference parts in a subdirectory. This issue doesn't exist if the types you are referencing are in the same assembly or an assembly that's in the same directory as the executing program; however, if the assembly is in a subdirectory, you'll need to probe the directory as described in my previous MEF post - Using MEF and Custom Configuration Sections.
The second scenario came with the need for Type or Part exclusions. The code above uses the same attributed model that all out of the box catalogs use. This means that if you created an assembly with 3 attributed parts in it and used an AssemblyCatalog or similar one, all 3 parts would be identify and consumed. The custom catalog outlined in this post focuses on Type inclusion and not exclusions. Because of this, if the above catalog is combined in an AggregateCatalog, all of the parts that meet the contract will still be imported. Through this fact, I highly recommend using the above catalog separately from the others.

So What's Next?

As for this catalog, I need to do a bit more refining and possibly add a few more catalogs that follow a similar manner. Ultimately, I'm going to be wrapping some unit tests around it and packaging it up separately. Beyond that, there's a lot of MEF content coming in the future so stay tuned.

Resources:

Goals for the New Year (2010 ed.)

noreply@blogger.com (Anonymous) — Wed, 06 Jan 2010 13:35:00 +0000

When I started to write down my professional goals for 2010, I ended up doing the same things as I did last year; just create a list of things to learn. Looking back over my experiences while attempting to accomplish my goals for 2009, I began to believe that this was the wrong approach. My initial goals were very focused on learning different technologies or hitting certain milestones in general. By the end of 2009, I found that sure I may have hit most of my goals; however, something was lacking.

For example, one of the items that I completely wasn't anticipating becoming so passionate about was the possibilities of MEF. This lead to a large number of rapid fire posts in March on some pretty rudimentary tutorials on the basics of MEF. While I was working on creating these tutorials, I constantly wished I was able to work on the latter posts (the ones that I'm slowly working on currently). It wasn't because I didn't think providing tutorial information wasn't important but being able to provide a better context was. This was also true earlier in the year during my initial F# exploits. Doing tutorials is good but sometimes showing the overall value before the tutorials can provide the basis as to the WHY someone can learn something instead of just the HOW to use it. If you have ever looked into becoming a better speaker, this practice is sometimes described as "showing the sex first". Get a person interested and intrigued first and then provide them the information and tools necessary to run with what you showed.

With this in mind, it's what my goals now resolve around. While I'll be working hard on learning new technologies or tying down loose ends on technologies I haven't fully learned, my focus is going to be on context.

Things I'm focusing on in 2010:

Getting More Involved
I'm a firm believer that teaching is one of the greatest ways of evaluating how well you know a topic. One of the things I discovered a few years back is a passion for presenting and teaching. Combine that with a desire to get more involved in the development community as a whole and it leads to a lot of opportunities. Right now I'm staring at about 4-5 presentations just in the first half of the year to various user groups and code camps all over the midwest. I'm hoping to expand this more by the end of the year. Sure it'll keep me busy and traveling but it's fun and I would am looking forward to meeting a lot of the community leaders at each location. As my calendar solidifies, I'll make sure to update things here.

More Contextual Value on Posts
Looking over the past 2-3 years that I've been writing in this blog, the posts that have the deepest impact are also the ones that provide the richest examples or specific focus. Some of the basic tutorial posts have appeared to be viewed well; however, the some of the posts that took me a significantly longer amount of time to write and develop the samples for have seen the best amount of feedback. With this in mind, I'm going to focusing more on intermediate examples more than introductory posts. The introductory elements will still remain; however, I'm hoping to change the quantity of the two types of posts in order to provide more balance and value to the readers.

Tying up Loose Ends
Last year I worked a lot on learning a number of new tools; however, some of them I only learned enough to understand where they may fit into my current situation (a.k.a. just learning what value is in it for me). This is usually a pretty good way of learning things; however, it can limit the potential. After changing jobs at the end of 2009, being able to reevaluate what I learned last year and expand on such will allow me to adapt better to different scenarios. This also will help me provide even better context when learning other things. An example of this is the fact that while I know the basics of writing in Silverlight, I need a little bit deeper understanding of it so that I can start applying MEF into my Silverlight applications when applicable.

Redefining a Dream
When I started getting serious about my development career, I wondered what I would consider to be my dream job. This idea always shifted with every career progression on my way towards my dream job. Recently, I landed a job that is the closest match thus far and am begin to evaluate the environments and companies I've worked for thus far as well as my current one. While I don't plan on leaving my current employer since I just came onboard and they are a very good company thus far, I'm a person that loves striving for what's next. Perhaps what's next is not a different company but something that augments my day job like getting more involved. Perhaps is back to a more remote working environment. Lots of ideas to consider and think about. Ultimately though, it's the journey that drives me, not what I have currently obtains. Anything is possible as long as you keep dreaming in my opinion.

Controlling Personal Projects with TDD/BDD

noreply@blogger.com (Anonymous) — Wed, 30 Dec 2009 12:46:00 +0000

Last night, a friend and I were discussing our ever growing list of personal projects and tasks that we strive to find/make time to whittle away. The items on our list ranged from reading a simple blog post, asking a mentor a question, or working on a personal, pet project. I don't know any developer who doesn't have a similar list to be honest.

Though the conversation, we began to talk about an issue we were both sharing about our pet projects getting drawn out. While there are true reasons (i.e. time constraints being the most prevalent), the one that plagued us was the concept of scope creep. As a developer, we battle with scope creep during our day jobs (usually) but to experience such at home leads to only a single person to put the blame on; ourselves.

This really got me thinking and reflecting on my project and my own scope creep issues. I began to realize that every time I had scope creep, it was a spot where I hadn't written unit tests first. In many cases I focus on a test-first strategy of TDD; however, there are a few times when I get in the flow and just write the code. This works sometimes but the times in which I can identify as scope creep all fell into these moments. If I had stayed focus on a test-first strategy, would these moments of scope creep been prevented? Probably not; however, it would have probably allowed me to be more conscience of the decision and possibly move it to some form of feature list for another iteration.

I only use standard NUnit-based unit tests and haven't fully tried out writing specs associated with BDD. Using something like a full spec like BDD would have been able to control the feature list a bit better but, again, not fully prevent scope creep. Regardless of the method, staying focused on a test-first approach does have a habit of controlling and identifying scope creep. It's easier to finishing a single iteration and enhance/refactor than it is to always go with the flow and allow the scope to continue to grow.

Using MEF and Custom Configuration Sections

noreply@blogger.com (Anonymous) — Wed, 23 Dec 2009 03:33:00 +0000

Up to this point, I've dove into some of the core fundamentals of using the Managed Extensibility Framework. Starting with this post, we're going to dive into how to apply it under certain circumstances. Some of the scenarios in the upcoming posts will focus on using MEF with different .Net technologies, applications that use MEF, or tricks in .Net that can assist when working with MEF. In this post, we'll start with this last category of scenarios by looking at how to utilize a custom configuration section defined in an assembly used as a MEF part and not located in the same directory as the executable. Using this method, it will allow even greater power to your application and freedom to the parts consumed by such.

Setting the Stage

For this post, we'll look at a simple code base we worked on earlier in the series which imported MEF parts from a separate assembly. Let's extend the code base by defining our simple custom configuration section from within the same assembly that define our external part. For simplicity sake, let's call the custom configuration section MEFCustomConfigSection. Below is the code for our custom configuration section:

   1:  public class MEFCustomConfigSection : ConfigurationSection

   2:  {

   3:      private static MEFCustomConfigSection settings = ConfigurationManager.GetSection("MEFCustomConfigSection") as MEFCustomConfigSection;

4:

5:

   6:      public static MEFCustomConfigSection Settings

   7:      {

   8:          get { return settings; }

   9:      }

10:

  11:      [ConfigurationProperty("message", IsRequired = true)]

  12:      public string Message

  13:      {

  14:          get { return this["message"].ToString(); }

  15:          set { this["message"] = value; }

  16:      }

  17:  }

This configuration section is very simple in that it only defines one property/attribute called Message. This property will contain a string value in which we'll be displaying on the screen when the application consumes our part.

Consuming Our Section

Now that our configuration section has been defining, let's go ahead and create the code to consume such. In previous examples, each of our parts had a property called HelpText that is used by the consuming application to display command line help documentation for each part. What we will do with this new part is using our configuration section's Message property to define what the value of the HelpText property should be. Thankfully, the code for this is extremely simple as shown below:

   1:  [Export("command", typeof(IHelp))]

   2:  public class CustomCommand : IHelp

   3:  {

   4:      public string CommandName

   5:      {

   6:          get { return "Custom"; }

   7:      }

8:

   9:      public string HelpText

  10:      {

  11:          get { return MEFCustomConfigSection.Settings.Message; }

  12:      }

  13:  }

Setting Up the Configuration File

Now that we have the custom configuration section created and code that needs it, we're now ready to update our consuming application's App.config file.

   1:  <configuration>

   2:      <configSections>

   3:          <section name="MEFCustomConfigSection"

   4:                   type="MEFExample7.Commands.MEFCustomConfigSection, MEFExample7.Commands" />

   5:      </configSections>

6:

   7:      <MEFCustomConfigSection message="Hello From a Custom Section" />

8:

   9:      <runtime>

  10:          <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">

  11:              <probing privatePath="Plug-ins;" />

  12:          </assemblyBinding>

  13:      </runtime>

  14:  </configuration>

Setting up the custom configuration section is the same as any other configuration section that would need to be setup. We first define our section within the <configSections> node and then we're able to insert our section; however, what's that last section?

The <runtime> section in the above snippet is needed to tell .Net to scan the Plug-ins subdirectory for the assembly that contains our configuration section. There are two ways of doing this. The example above uses the <probing> node which is great for little examples like this; however, can lead to performance issues since it will scan all assemblies in the paths that are provided. Another issue with the <probing> node is that it doesn't provide a way for targeting specific, strongly named assemblies nor specific assembly versions. If you need stronger control of what assemblies gets loaded, you can use the <codeBase> node instead.

For more information on using the <probing> and <codeBase> nodes for loading assemblies this way, feel free to check out the following links:

NOTE: One final item I need to mention about using <probing>, it can only look in subdirectories of the location the executable is in. So if the assembly is in /bin, your path to probe for assemblies cannot be in a parent directory.

Once the configuration section is setup, and the Plug-ins directory is a child directory of the location of the executable, our new command is now displayed when the application runs.

Summary

In this post, we briefly looked at some things to be aware of when defining a custom configuration section from with in an assembly used as an external MEF part. In future posts, we'll be looking at other scenarios on using MEF including consuming parts written in F# by a C# application as well as take a look at an open source project that will soon be releasing a new version that uses MEF.

Resources

Random Acts of Coding

Video - Inversion of Control with StructureMap

Iowa Code Camp - Fall '10 Review

Getting Dirty with Android - by Brent Edwards

Curriculum Development Workshop - by Dustin Thostenson

Using and Extending Django - by Matt Morrison

Using Django and TDD to version Databases - by Matt Morrison

Overall Reflections

Speaker Contact Info

Presentation: Low Hanging Fruit of Html5

Presentation

Materials

Video Recoding

A Tale of Two Interviews

My Development Toolbox

General Guidelines

CSS Examples

Fonts

Icons

Images

Scripts

Templates

Utilities

Web File Examples

Personal Information

Code Shot - hCard Template

Code Shot – Doctypes

A New Format Coming

The Paradox of Choice for a Programmer

Social Media - The Way of Becoming Antisocial

And Now For Something Completely Different

So What's New?

Why New Languages?

So What Am I Going to Do About it?

My Thoughts on Pex

Iowa Code Camp - Spring '10 Review

IoC with StructureMap - By Brad Tutterow

TDD Dojo - By John Teague

Open Session

Being a Technology Entrepreneur - By Scott Davis

Learning Distributed Source Control with Mercurial - By Chris Sutton

Reflections

Contact Information:

My Managed Extensibility Framework (MEF) slides from the Iowa Code Camp

Demo Projects

Hiding Parts From InheritedExport

Post Links

Using MEF with Signed Part Assemblies

Important Links

How To Check If An Assembly Is Signed?

Validating Part Assemblies Are Signed

A Caveat to Implementation

Summary

Update:

Development Achievements

A Missing Piece?

Is Achievement System Possible?

What Would It Take?

Ideas for Achievements

Looking Ahead a Bit

Presentation: Extending Your Applications With MEF

A Look at the New DotNetMigrations

An Overview of DotNetMigrations

Extending DotNetMigrations Thanks to MEF

What Else Is New?

Making Part Declarations Easier with InheritedExports

Reviewing Previous Examples:

Simplification through Inherited Exporting:

A Useful Pattern of Inherited Exporting:

Summary:

Resources:

A Configurable Type Catalog for MEF

Looking in the Box and at MEF-Contrib

Adding a Layer on top of MEF

Creating the Configuration Section

Creating the Catalog

Notes about the Catalog:

So What's Next?

Resources:

Goals for the New Year (2010 ed.)