A New Format Coming

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

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

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

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.

Development Achievements

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

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.

Goals for the New Year (2010 ed.)

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

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.

Iowa Code Camp: Session Overview

The Iowa Code Camp was held on  November 7th, 2009 in Des Moines, IA.  With a capacity crowd and a lot of great sessions, it ended up being an awesome time with a lot of great presentations and conversations.  Like conference of this type, you never have time to hit all of the sessions you may want to; however, the ones I was able to attend were still awesome.  Below is an overview on each one.

Getting Started With Behavior Driven Development by Lee Brandt

In his presentation, Lee provided a good introduction to the concepts of BDD.  The presentation focused on the origin of BDD, where it fits, and how it's an evolution of TDD from the beginning which helped to truly set the stage.  For those that have done TDD for a bit, it provided a great introduction into bridging the gap between the business case and the code by using tests as a spec.  Through this and Lee's stressing of an Ubiquitous Language as described in various DDD circles, he showed how BDD can be used in order to provide a technique that helps to show the client what the application will do once done as well as a pseudo-burndown chart of what hasn't been finished yet.  I'm definitely looking forward to exploring BDD again in the near future.

Twitter: @LeeBrandt
Blog: http://www.geekswithblogs.net/leesblog/Default.aspx 

Going From 0 to 100 Dollars an Hour with .Net you Didn't Know by Mitchel Sellers

This session was a good session; however, it wasn't as advanced as I was hoping for.  The abstract of the session focused around using advanced features of .net in order to make you more productive; however, I was hoping for some additional tidbits beyond that of the abstract.  The primary items focused on this presentation were new tips and tricks introduced by .Net 3.5 such as Lambdas, Self Containing Properties, and LINQ. All of these items I already knew and have used them in the past which is why I was hoping for a few tidbits beyond such. That being said though it WAS a good session with a lot of good code samples to convey each concept and technology.  I still learned at least one new thing and was reminded about a few other things as well. While it didn't meet my (probably unrealistic) hopes, I cannot deny that Mitchel's presentation definitely educated a number of people who were also in his session that was overfilled.

Twitter: @MitchelSellers
Blog: http://www.MitchelSellers.com 

Open Spaces

I've been to a few open spaces discussion and have came to the conclusion that some will be good, some will be bad, and others will be between or outside of those labels.  The open spaces session at the Iowa Code Camp was an in between session.  The size of the group was smaller and comprised of a diverse set of primary skills which isn't always a bad thing though the topics in discussion didn't flow like I have experienced in other places.  We had a good conversation about how to get the information to the people that don't come to conferences or how to encourage them to come.  We also talked a little bit about MEF, coding war stories, and some of the side effects of completely rewriting/redesigning an externally facing website.  Lastly we talked a little bit about Kanban vs Scrum and the paradox of software estimation.  All in all there was some good things that came up during the conversation; however, part of me was hoping that more people would have been involved in the discussion and the topics would have been more discussion/problem solving based to an extent.

Intro to ASP.Net MVC by Chris Sutton

I've dabbled in ASP.Net MVC and have wanted to learn more about it; however, finding making the time for such is not always easy.  Everything that I've learned about such has either been about the MVC pattern itself, or about other frameworks in general like Rails or Django.  With only a few MVC Videos watched and about 3hrs worth of coding so far, I decided checking out another intro session wouldn't be a bad idea for me.  Chris Sutton did a great job with the presentation.  He explained the MVC pattern very well as well as describing how the ASP.Net MVC framework relates to it and ASP.Net in general.  He showed a couple of the typical demos for this level of session and afterwards answered all of the questions I had about the next step.  All in all it was a very good session and can't wait until I can make time for using such.

Twitter: @ChrisSutton
Blog: http://subjunctive.wordpress.com 

Silverlight for WPF Developers by Kirstin Juhl

In my opinion, none of the last block of sessions really looked appealing to me.  It wasn't the fact that I didn't think any were going to be good, it was just that I wasn't interested in the topics at hand.  I ultimately decided to check out Kirstin's presentation on what WPF Developers would need to know to transition into the Silverlight space.  While I have only dabbled in WPF a little bit, I knew a number of differences and knew the power of XAML was greater in WPF than Silverlight.  The decision to go here was my current adventures in Silverlight and see what I may be able to learn.  All in all, the session was pretty good for the purpose Kirstin was targeting.  She did a good job at explaining the differences as well as provide information on how to share components between Silverlight and WPF applications (something I knew was possible but hadn't seen an example of up to this point).  Good presentation overall.

Twitter: @KirstinJ
Blog: http://www.geekswithblogs.net/Kirstinj/Default.aspx 

Overall:

Overall, I had a great time at the Iowa Code Camp.  For being a free conference, the presentations, facilities, and of course the prizes were all top notch.  It was a great conference with some amazingly talented speakers and attendees.  All in all I can't wait to head to the next one in the April/May/June timeframe.  Hopefully some of the presentations I'm working on will be ready by then since I'd love to present one.

Reviewing This Year's Goals (2009)

Back in January, I created this post focusing around what I was hoping to accomplish this year.  I was going through my old posts and stumbled across it.  I figured it would be a good time to look over them once again to gauge my progress along with what else I may have done so far this year.

 

Learn F#:

While I do not claim to be an authority of F# by any means, I do feel comfortable in saying that I learned the bulk of the language and be able to determine where it makes sense to use it.  If time allows, I can see myself using it more and more; however, for right now, I've definitely learned a lot from such and can focus on learning other things.

 

Learn DDD:

This one I am really only about 1/2 done with.  While I have went through the information and can understand the concepts involved, I haven't had a good way of applying such yet.  There's existing applications that could benefit from the practices of DDD; but I haven't pushed myself into applying such on a new project yet.

 

Learn Silverlight 2:

I got sidetracked and ended up procrastinated on this one.  While I wanted to learn SL2, I still was a bit apathetic towards it since SL1 wasn't very impressive to me.  Thankfully, I've seen a lot of what Silverlight 3 can do and am going all out on learning more about it.  Except some posts on Silverlight 3 soon.

 

Other Things:

So what else have I been up to so far this year?  Looking back I have worked on some open source projects (namely my SchemaSpy Task for NAnt and contributing to .Net Migrations over on codeplex).  I've also focused a lot of time on keeping up to date on .Net 3.5 and other technologies that I wasn't able to fully take advantage of at a previous employer.  Lastly, I've really been focusing on TDD and just writing better code in general.  There's always room for improvements but being able to learn from what's being talked about over the past year is what's important.

 

Things on the Horizon...

Learning MEF:

The Microsoft Extensibility Framework (MEF) provides some great opportunities to make very extensible applications.  With a need to make a project extensible, I'm definitely going to be focusing on understanding MEF more.

 

Learning Silverlight 3:

I'm already in the process of working in Silverlight 3 but I have only started to write applications with such.  Just like a person who has finished their first true ASP.Net application, there's always room for improvements and things that one can learn to make things better.  I'm at that stage where there's a lot more I can learn about and I'm all for it since Silverlight 3 is awesome.

 

More SchemaSpy:

My SchemaSpy post earlier this year is one of my highest trafficked posts as well as one that I refer back to all of the time.  I'm planning on answering a few outstanding questions associated with that post and also see what else I can do with the tool to make things easier for everyone.

 

<Unknown> Things:

I always leave myself open to the unknown and unforeseen opportunities.  While November and December are usually swamped for me, I never know when inspiration will hit me and I learn something new.

Is Learning though a UI worth it?

Do you remember the last time you learned a new, back-end technology like Linq-to-Sql, Entity Framework, NHibernate, the Twitter API, or some other 3rd party API? How did you first go about learning it?  If you used some tutorial of some sort (be it a blog, video, or some other medium), how did you try it out?  Did they have create a basic web page to present the data from the API that you were consuming? If you DID create any form or UI to consume this API, here's two questions for you...

 

1. How long did it take you to create that UI compared to writing the code that uses the API?
   
   
2. Did you learn more about the API from the UI or from writing the code that actually interacted with the API?

 

Now, let me restate that I'm aiming these questions specifically at back-end technologies.  Any technology that deals with any aspect of a UI (i.e. JavaScript, Silverlight, etc.) obviously depends on the UI and really does not apply. However, if you're NOT focused on a UI-dependent technology, why do you create a UI to learn something that doesn't require it?

Don't get me wrong.  I was guilty of this as well and what I found is that I got sick and tired and bored spending so much time creating a UI and it would take me longer to get to the subject of my studies.  Throw in a dash of OCD or ADHD because I couldn't just make a simple UI but needed some form of basic layout and color contrasts at the very least and it was a recipe of boredom.  It wasn't really until something clicked that I began to really realize that I learned more from the tests or the debugger while stepping through the code consuming these APIs than how the information was presented.  Sure it felt good when I could apply what I learned to a UI but applying the UI layer did not directly provide any value for me towards learning the API.

But again, if it takes so much time and provides a greater opportunity for distractions, is it worth it to learn a back end process by means of applying such to a UI?

My Barriers to Learning TDD

As a follow up to my previous post declaring that I finally "get" TDD to some extent, I figured I'd reflect on the barriers that I have had up to this point which made it difficult for me to learn how to unit test in some effective manner as well as truly understanding the benefits of TDD practices.  Now, I am by no means claiming to be an expert in unit testing, mocking, or TDD.  I didn't open the refrigerator, drink some of the TDD-flavored Kool-Aid, and threw on a subsequent Mortarboard to illustrate that I've somehow graduated into this new, higher level of software development.  I'm still learning from others as well as my own errors experiences just like everyone else.  The purpose of this is to reveal to others some of the issues that I had and hopefully provide some insight on how to overcome such.

 

The Examples Are Too Simple

This barrier was by far the most difficult for me to overcome.  I would read up on all of the buzz about how to add unit tests to your code and how to apply unit testing into TDD.  I would follow the examples and understand it and be fine; however, I would always stall out whenever I tried to do it in a real world scenario. One day, I got extremely frustrated trying to fit all of this this together even if it looked like a square peg for a round hole to me at that time.  I began to wonder how unit testing in general would work on such complex real world objects and that's when it hit me.  Around this same time, I was diving into the S.O.L.I.D. principles of Object Oriented Design and began to count the dependencies I had in the code.  The more I broke out the code into less complex objects that followed the principles, the easier it was for me to map the unit test examples that previously were "too simple" to my code.  The barrier wasn't so much that the examples were too simple as it was that my code that I was trying to directly apply the lesson to were too complex.  On the last project I had, I didn't apply unit testing to it; however, I tried to adhere to the S.O.L.I.D. principles as much as possible.  When I was trying to retrofit the tests into it, I was able to do it as well as find places where I didn't follow the S.O.L.I.D. principles as much as I thought I did.  Looking back, I probably wouldn't have had any of the refactoring issues I had after the fact if I had used TDD to provide a test-first basis for the object designs.

 

But...This Class Uses the Database

This was another barrier for me that partially stems from the previous example.  Looking over the majority of Unit Testing and TDD books and blog posts out there, very few of them actually touch dependencies as common as a database.  Looking at my own code at the time, I had repository classes that handled all of the CRUD operations to the database as well as spit out the records as strongly typed collections (where necessary).  How do I test this class when there is such a deep dependency with the database?  I was truly perplexed by this issue and decided to ask the question on StackOverflow.  The responses led me to realize that my class was doing 2 things; calling the database AND transforming the returned data in to a manner I needed.  By pushing the direct database calls to a separate class, I was able to mock away the database and make sure these particular class could be tested.

Now, that only solved half of the issue.  I abstracted the dependency of those classes but I still had data provider classes that still interacted with the database.  This is where I truly learned the difference between Unit Testing and Integration Testing.  With such an outside dependency as a database or a web service, I began to see some examples that created separate, controlled instances of those dependencies in order to test the queries and CRUD functions.  The technique I use now for database integration is to use NHibernate, even if the primary project doesn't use it.  NHibernate has the ability to recreate table schemas for each tests which helps automate the state of the database for each test.  An example of this can be shown over at NHForge.org's How-To section under Your First NHibernate Based Application.  After setting this up, it provides me an easy way to test the barrier of the database.

 

Am I Just Testing the Mocking Framework?

I had a class the called into a 3rd party library that I wanted to test.  I abstracted the 3rd party library into a proxy and called such from my class.  The 3rd party library sent messages over a TCP socket connection and returned back an "OK" or an "ERR" message.  The class that I wanted to test created and sent the messages and then reported on what it got back.  For example, I would call a method in the class and it would send a message "FOO" to the proxy and get back "OK".  That's a little simplified (see barrier #1 above) but the class itself did pretty much that.  When I setup the test, I mocked out the proxy dependency and had it return "OK" whenever my class sent it "FOO".  This is not that meaningful of a test since there is no logic in that 1 method.  Other methods had logic based on the parameters; however, this one method was just this simple.  Was I just testing the mocking framework with this particular test?  Arguably, yes...I was; however, in the future, if that ever had to change, I now have a test that I can use to ensure that I get the information correctly.

 

But Unit Testing = More Code & Time

This wasn't so much a barrier for me mentally but was a barrier to adopt it at work.  From what I've experienced now, writing unit tests AFTER the code has already been written DOES lead to more code being written, more refactoring of existing code to make it testable, and more time to do all of this.  However, I have seen that writing your unit tests BEFORE you write any code (as advocated in TDD), you tend to code at the same speed if not a little faster.  I found that I wrote code faster when I did tests before since the production code was already designed for me through the tests I had just written.  There was less thought at the time of coding since the design was setup while I was writing the tests.  I also found myself near-instantly defaulting into the S.O.L.I.D. principles instead of looking at them sometimes as a refactoring step.  Lastly, I wrote less code that would have been for future use (i.e. YAGNI). 

All of this came with a paradigm shift in my object design style.  While some of the basic directory structure and such was the same, I looked at my classes more at a "how do I want to call this class" as opposed to "what methods do I want to show in this class".  The shift in my thinking was more of a consumer than a provider or retailer.  If you only code what you need, you tend to not code things you don't need.  It's as if you go to the grocery store for 1 item and that's the only item that the store has.  Nothing else to distract you in that point in time.  No other products around that you may need in the future.  You are in that 1 moment in time and in that moment, you only have 1 need as a consumer.

 

Summary

While there were other barriers I came across, the rest were either very minor or more about basic implementation like how to return an IDataReader object. I'm sure that I'll stumble across more barriers and moments of enlightenment the more I practice TDD or just unit testing in general.  Until then, I hope some of the items described and discussed here can help others who have struggled to get their head around unit testing in general and some of the principles of TDD.

Finally Understanding the Merits of TDD

I'm not a TDD person...or at least I wasn't until last week.  Up until then, I had read the blogs and looked at the examples to try to understand TDD and unit testing (with mocking) in general.  Almost all of the examples I was shown demonstrated very basic scenarios that, in most cases, were too trivial to show value.  I would ask people who would speak about unit testing in general how you'd do a specific scenario and would get mix responses ranging from "just try it" to "you should be using this tool and it'll just write the tests for you".

Last week, I had some free time to where I could truly evaluate a code base I finished up with the prior week and see if I could apply some tests to it.  The code I wanted to add tests to were simple repositories where I had abstracted the database calls to separate classes.  Being told to mock the databases out in the past, I started to do that and focus solely on these repositories.  In some instances, it felt like I was testing the abilities of the mocking framework instead of my code but these methods were simple by design (i.e. "Get Customer by Id 'X'").  It was when I started to test more of the methods that I saw that some of the code I wrote had some issues.

The code was functional; however, it wasn't easily testable.  When I would attempt to describe the test, I found that the code did more than one things (breaking the Single Responsibility Principle).  Another incident showed that the name of 1 whole class didn't make sense.  A third incident showed me an issue with the number of complexities that come from multiple dependencies and object inheritance.  After each time that I finished refactoring these issues out of the code and eventually got to working tests, I began to see how the questions that TDD (and BDD) cause you to ask while designing an application really shine.

One example of this was a duplication of code.  I had a class called, for the sake of this post, UserRepository.  The UserRepository had a method to get all users in the system and returned a List<User> back to the calling code.  This class also had a second method that did the same thing but the List<User> only had the FirstName and LastName properties populated.  Why did I write such months ago?  Short answer - I have no idea.  Looking through the code, I found that a different feature needed just the FirstName and LastName properties and nothing else...it was then sending the List<User> to the client for an AJAX call.  While I can understand this now, I could have better implemented the solution by if I looked at the scenario and behavior better initially.

If you ever find yourself wondering how writing more code for TDD or just basic unit tests can actually help the code, my recommendation is to just try it.  Take a simple class that has only a few pieces of logic in it and test it.  Next, take a simple class that has a dependency that you'll need to mock out and test that too.  After you understand how to write these basic types of tests, you can move into the self-reflective questions that really shine in TDD.  Questions like "What type of data do I want to work with when I call method X?", "What will this class need (a.k.a. dependencies) to get me data Y?", and "Is this functionality already present?" are all questions that get forgotten while we're sometimes blindly coding. 

Looking ahead, I can only imagine how my code will be looking.

Expecting More From Example Code

While I'm typing this post, I'm actually on vacation.  A road trip to a destination in hopes to relax and unwind from my daily routines.  However, I had to bring the laptop for informational purposes (of course).  On the road, I was thinking about some of the posts that I have created and also of those that I refer back to.  I also compared a lot of these posts against the increased visibility toward the S.O.L.I.D. principles of Object Oriented design.  The more I thought about it, the more I became inspired on the question of should people who read blogs and go to presentations expect more from the authors?

In my opinion, the presentations and the traditional style of technical blog posts are fine.  I feel like they teach a concentrated concept in a, hopefully, straight forward manner.  Some topics provide more practical implementation; however, how many times have you ran across a demo where the variables were only named Foo and Bar?  Presenting a concept is great and effective; however, should more be provided in the examples of in a supplemental post on how to apply the information "properly"?

For example, I wrote a post on using jQuery for different types of visual effects of your elements last year.  It was a very simple post with a moderate amount of code that focused on the topic and didn't deviate.  I, as the author, left it up to the reader to apply this knowledge into their own works.  What if I was to go 1 step further and do a live demo similar to blogs like Beckelman.net and JankoAtWarpSpeed.com?  Would that help push the concept better?  What if I supplied a zip file with files that apply the concepts learn in a more real-world scenario?  A lot of my more recent posts include VS projects; however, it is usually a direct reflection of the code inside of the post.  In that jQuery effects posts, I could have easily created a simple directory structure containing the proper files in a traditional/standard method (i.e. separating the CSS and JavaScript into their own directories, etc.).  With regards to my .Net posts, should I make sure that all of my code is commented? Refactored properly to meet the SOLID principles (sans my F# code due to it being functional and not oo)? Include Unit Tests?  I know a lot of people, including myself, who learned some skill by taking someone else's code and then tinkering and tweaking it to learn how things work based on their changes.  I'm wondering if more people would used Unit Testing or "proper" OO design if more of the example code in the blogsphere came with such.

I said earlier that presentations and the traditional blog post is fine as is.  The reason why I say this yet question the example code is that the extra stuff (i.e. Unit Tests, Full Comments, properly design class structures) can sometimes sidetrack the post or presentation.  Questions often rise about these ancillary items as opposed to the concept you are attempting to teach.  So, with that said, I still believe that the posts and presentations are fine.

Should we expect more from the Example Code?  In my opinion, yes.  I know I have a lot of work to do since adding such polish is time consuming; however, if it can assist in improving the overall quality of the code someone else uses, then it'd be worth it.

What do you think?  Should those of us that read blog posts and presentations expect more from the example code tied to such?  Should those of us that author posts provide a more comprehensive look at their code in order to encourage better practices?

What do you think?

Automating Features vs. Fundamentals

I have been in a lot of meetings over the past few years where inefficiencies in a few practices and policies were being discussed.  In terms of software development, there's a lot of things that can be done to improve how the code is written, deployed, and tested.  The meetings began talking about these possible options; however, after about a 10 minute discussion in the first meeting, everyone seemed intent on designing the tools specific to their domain and not the groundwork that is common across all domains.  Now, nothing is wrong for discussing features to standardize an approach and not reinvent the wheel every time; however, I have learned that the features are domain specific (albeit some may be more common than others) and it's the recreation of the fundamental code that saps a developer's energy, focus, and motivation usually. 

Years have went by and still the same people talk about the features without giving any thought into the remedial code that is common and takes the longest usually.  Between debating the aspects of the features and evaluating tools, such turned into analysis paralysis very quickly with very few realizing it.  Soon, the feature advocates turned more into idea zealots; preaching their views while not provided any acknowledgement to other opinions.

Because of all of this talk and no action, I began to run a few tests with some of my colleagues.  There were 3 projects that shared the same core project foundation in it's design but each developer was going to create their own.  For the sake of this story, we'll say that this was going to be a "professional" Hello, World console application that had to handle industry standard command line arguments (i.e. -? and a few others).  Each person took about 5-6hrs writing the basis of their console application; setting the proper output color schemes and the console output for the help information and other fundamental requirements.  Finally it took them about 1hr to do the actual project specific logic. Now, in this example, one could say that Developer-A creates it and then passes it along to the others in a copy/paste sort of way; however, the test needed to be done not only for time purposes but for implementation purposes since all 3 application bases were not consistent.

From these examples, we refined the foundations and eventually abstracted it into a Visual Studio project template.  The next time they they had an opportunity to use the template, it saved them that much time yet again.  This template was only the fundamentals and didn't have any actual features (no consistent way to do things like emailing or FTP services or error handling).  Later versions have added these features into it (or provided a model to make it easy to do a custom implementation) but the original versions were just the fundamentals.

In the end of this experience, the idea zealots were still preaching their features without recommending any solution to their implementation and we became more efficient by automating the fundamentals.  If you're looking to improve efficiency, try to find remedial, repetitive areas in your process and see about automating them.  Start with the fundamentals and then add features to it.  There'll be changes; however, if you Develop > Refactor > and then Abstract what works, you'll be in a much better place than if you stayed in a meeting room and debated about what features should be in the initial version of the script or template.  My Rule of Thumb from experience: Version 0 of any automation script or template should only have the minimum amount of features possible and focus on the fundamentals.

Tackling Anxiety Against Automation

A few years ago, the company that I worked for was preparing to upgrade from MS Sql Server 2000 to Sql Server 2005.  While there wasn't too much abnormal concern about upgrading the databases themselves, there was a lot of concern about the large number of DTS packages that the company created for the majority of their B2B processes.  Their solution until they could come up and complete a test strategy to ensure the DTS packages would run under Sql 2005's DTS runtime, just incase the packages couldn't be converted to SSIS in some fashion, was to stop writing new DTS packages and push the processes into .Net console applications that would be scheduled through a batch processing system.  Personally, I liked this solution since it allowed me to write .net code in VS and not VBS code inside of the DTS Package designer in Enterprise Manager.  Actually abstracting out processes into a more reusable and testable state was a great benefit over VBS and DTS as a whole.

One of the first console applications written under this initiative was to automate a series of manually ran Sql Scripts that people were running against production to accompany a file import process.  It was a pretty simple project and ran, still to my knowledge, bug free, even when tested by my QA team.

Now fast forward to today.  The need for the process is still in place and the code hasn't been updated since no changes have been required; however, I found out that the application was only ran once in the past few years and then the person who used to manually go through the steps and scripts didn't want to automate it and has been doing the manual steps ever since.  Even today, this person has continued to manually spend a few hours every other day going through the same ceremony.  I think my brain gave me a BSOD from what I find highly illogical thinking.

So I approached my coworker who has been doing this and start asking the number of "why" questions I had.  Here are some of the responses I was treated to:

• "I don't trust what I cannot see or watch."
• "I like being able to watch and correct where necessary."
• "The process had a bug."
• "I won't ever know when it breaks or succeeds."
• "What else would I work on?"

From the discussion around these themes, there are a few design and development themes that can/should be implemented when faced with such an anxious coworker.

 

Establishing Trust through Quality

While I see James Bach's point in his "Quality Is Dead" blog post, I disagree with the blanket of the statement.  There are always constraints when you're talking about software development (usually Time/deadlines being the largest constraint), it doesn't mean that every piece of code that you churn out will be of poor quality.  Practices such as TDD or just plain Unit Testing and reporting can be implemented in order to demonstrate and achieve a higher level of quality to someone who doubts quality.  Now, I believe that any developer can write code with and without unit tests and still achieve the same level of quality; however, it's easier to validate that level of quality through unit tests and TDD practices.  This level of validation is essential to people who do not trust something to be automated.

 

Establishing Awareness through Instrumentation

The bulk of the other themes that I received surrounded the concept of being able to step through the process and watch/correct the data as necessary.  This is a nice thing for debugging; however, if an automated process has to be stepped through, then it's not automated.  One way to handle this issue is to ensure you have a high level of coverage of instrumentation in the code/process.  This means making sure the proper types of notification is provided, auditing is turned on to the degree needed, and any errors (be it bugs or bad data-related) are captured and reported appropriately.  I cannot confirm my coworker's claim that there was a bug in the code since I was unable to find one in the bug database.  If an email to capture the error existed, at the very least, I would begin having my own doubts about the quality of the code; however, even that was not found.  If instrumentation was implemented to a better degree than what I put into it for error logging and tracking, I would be able to verify the claim.  As far as bad-data and catastrophic scenarios (i.e. server loses network connection mid-process), those items can (and was) implemented through logging or some for of process auditing infrastructure.  The more data that can be provided, the more confidence the person will have when automated.

 

Establishing Automation Can Assist with Workload

The last theme that came from the conversation dealt with how the person's routine became.  This person was a very routine-oriented individual who knew exactly when to do when and how long it would take.  This person was a person of ceremony and possibly a bit fearful of being automated out of a job.  After being in the industry for a number of years, I have came to the conclusions that those nightmare stories of people being replaced by programs rarely happen to the developers or analysts that implement the program or automated process.  The automation allows for new, different tasks to be done.  Even if the automated process is kicked off manually, it still frees up time to do other things.  This means you can do more easily or in general transition onto the next big thing.  I do not really know any company out there that would say they have a truly shortage of work.  Even if it's wish-list, lowest priority, internal cost projects, there's always something to do.

 

Summary

Automation is a beautiful thing that I have grown more and more fond with.  I have grown into a developer where I look for things to automation.  I have seen the themes I talked about here at a couple of different companies I've been with and people that I've talked with.  Each time, I find more and more ways to automate certain elements of a work day and also make the work flow easier.  Hopefully a few things here will help others as well.  Now if only I could find a way to automate my chores at home. :-)

Goals for the New Year

Happy New Year!  Ok, so I'm a week late.  With the start of each year comes a tradition that some view as a farse while others hold as an event of refocusing.  New Year's Resolutions are are great time to reflect and focus what someone wants to achieve.  While I'm not big on making my personal goals known like some other bloggers (it's just not my cup of tea), below are a few goals I've set for myself that relate (directly or indirectly) to this site.

 

Blog More

This is a given.  2008 was a huge year of transition for me in my personal and professional life.  While I was able to churn out more post than I had before, I struggled on many weeks.  I'm hoping to be able to hit my goal of once per week this year.  Hopefully I'll be able to keep it up while also providing interesting topics for everyone to follow.

 

Learn F#

One of the things that I've wanted to do in recent months is expand my professional arsenal.  Coming from a Java background and transitioned into the .Net world almost exclusively now, I've somewhat been stuck trying to stay afloat with just C# and VB.Net (ASP.Net included).  While I am still working on keeping up with the times and changes in those languages, I'm wanting to expand into F# as well for a truly different perspective. 

 

Learn Silverlight 2

I dabbled in Silverlight 1 while I was also learning XAML in general for WPF.  It was fun but I didn't get too deep into it due to the JavaScript model that it used and the obvious changes Silverlight 2 (then 1.1 alpha) had.  Now that Silverlight 2 is out.  It's time for me to get back to work on it and begin getting a subtle level of proficiency in it.

 

Finish the Books I Start Reading

For those that know me, I love reading; however, I tend to read books in parallel and rarely finish technical books.  This works well for some books since they are great for references just as much as reading cover-to-cover (i.e. Wrox's Professional C# 2008, etc.).  The issue comes in when I'm reading a book to clarify a topic or to truly learn, I tend to lose attention on the material.  This goal is to simply push myself to finish the books that I feel need to be finished.  For example, here are all of the books I'm currently reading:

• Website Optimization by Andrew B. King
• jQuery in Action by Bear Bibeault and Yehuda Katz
• The Design of Sites by Van Duyne, Landay, and Hong
• Introducing Microsoft Silverlight 2 by Laurence Moroney
• Alice in Wonderland by Lewis Carroll (ok not an IT book but is a great way to stimulate the imagination and unwind)

 

Learn DDD

One concept that is being shown a lot of attention recently is Domain Driven Design.  It's got some great concepts for managing complexity and the research I've done on it so far has yielded some interesting ideas on my application designs.  I just recently picked up a copy of Eric Evans' book and will hopefully get to it very soon to clarify a lot of the items I've had some trouble with.

 

Use jQuery More

I love jQuery.  Of all of the JavaScript frameworks that I've used on both personal and professional projects, it is the one I prefer hands down.  With that being said, I haven't had much spare time to work on any personal projects that require new ways of using it so such posts have been reduced a bit.  I have projects queued up so hopefully there'll be more jQuery related posts to come up in the future.

 

In Summary

I'm sure that I'll have more goals as the year progresses; however, for right now I feel like I have a good focus for the next handful of months.  Next week I'll start up the normal posts again.  This year will have a more diverse mix of posts with more tools and different technologies and techniques coming.  Hopefully I'll be able to stick to my goals :-).

Beginning of a Different Focus

For the majority of the year, I have been researching and helping my coworkers learn a variety of technologies. This has lead to a lot of opportunities as well as forced me to really take the time and focus on a number of technologies. I've been somewhat bouncing all over the board of technologies on my researching; Regex, CSS, LINQ, AJAX, etc. Going forward, I'm going to be focusing on writing shorter, more focused blog entries in order to provide some value over the random ramblings that I've posted thus far.

Stay tuned.

Old trends aren't necessarily antiquated

I was working on rewriting an old ASP 3 application into ASP.Net 2.0 today and came into an interesting thought that caused me to look at the past 5 years of ASP.Net. Back in ye' old ASP 3.0 days, everything was inline code. Then came .Net and the trend of Code Behind files. Everything seemed good aside from the initial runtime compilation upon the site's first request. Now in the ASP.Net 2.0 world, we're blessed with the truly pre-compiled/published sites that only hold marker files in place of the traditional files that would house the mark up.

Now, looking at the history of the application that I am rewriting, this specific application tends to have a few pieces (usually just presentation layout) that requires changing on a frequent basis. Now, this is where the difference of opinion lies. Some people see these changes as a cause for a full deployment and along with that, some QA representatives would also deem that a full deployment requires a full application test (I've worked with people who demand such even if the change was only the order of text boxes). There are also others that think that one would only need to deploy only the updated files. While this seems logic, it comes with the price of having the ASP.Net 1.x initial lag once the file is accessed. In addition to the lag issue, there's also the requirement of deploying the solution in an "updatable" mode. As in most cases, this would be a trade off between security and convenience. I'll let you decide on when such a trade off is applicable.

Assuming that the convenience is agreed upon as necessary for the project, there's two ways that could accomplish this task. One is to simply replace/update the markup of an ASPX or ASCX file. While this is great, what if the UI needed to change from a drop down list to a series of cascading drop down lists to obtain the "same" value in a more refined manner?

At this point, I would advocate a full deployment in order to maintain a consistency of code (or in the case code-behind); however, curiosity got the best of me on this one. :)

Never trying it myself, I created 2 simple user controls where the code was inside of a <script runat="Server" > tag. I chose to Register the controls via Web.Config instead of directly on the page for a single location, should I find myself wanting to use the control elsewhere. Upon updating the SRC of the registration entry, the user control flips.

After doing this, I realized that it would work if I modified the user control logic a bit. Many developers create user controls that are nothing more than a segmented section of the page that houses it. This tightly couples the control to the page and is considered a bad practice in many groups. A better way is to just encapsulate the functionality of the control so it doesn't rely on any external piece of information. Yet an alternative way (and the way that arguably works best for this situation) is to create the user control where any data that would need to be passed to the page itself be exposed through properties and events. Ensuring that all controls that a person will be swapping out implement the same interface(s), the page's code behind should be able to implement the logic without a full deployment needed.

Base on this information, I'd have to argue that Code behind with a non-updatable deployment may be the best and most secure form of deployment, there may come a situation where it's not the best option.

The 4 Paths of 3.0

Microsoft.Net v3.0 has been out and around for a good couple of years now (including its days under the WinFX name) and it seems like just now people are beginning to use it. With in the past year and a half, more and more advances in development paradigms have caused the need for a better interface along with easier ways to do things. .Net 3.0 was to help in the areas of authentication (CardSpace), processing (WF), UI (WPF & Silverlight), and SOA (WCF). The 4 aspects pack a huge impact once one dives into them and applying them together makes them a true force of development.

So, if one was to start pick one up of these up, which of the 4 paths would one choose?

CardSpace:
CardSpace provides a quick and easy way to provide digital authentication. Unlike Passport, CardSpace provides better management, an easier API, and a significantly better cost structure (if anyone priced the Passport authentication licenses, you know what I mean by this). Many other bloggers view it as probably the most important piece that's getting the least amount of attention. I have a feeling that I'll be diving into CardSpace in the next few months, but not initially given some of my direct needs.

Workflow Foundation (WF):
I started reading up on WF about a month ago, randomly chosen from the 4 technologies. An embedded runtime specifically for workflows that would take compiled or xaml-based workflows was quite nice. It provided an easy interface for design and was quite easy to implement. Even with all of the benefits, WF is one that I'm going to feel is acceptable with my limited knowledge at the moment. I'll pick it back up after a bit.

Communication Foundation (WCF):
As I was researching and playing around with WF, I noticed that WCF can be integrated into it quite nicely. This, combined with recent performance statistics posed on MSDN, makes it a very nice option to learn and apply in just about any environment. Again though, I haven't truly dove into WCF and will probably do it second on my list.

Presentation Foundation (WPF):
When the first WinFX book came out, I thumbed through it and the first thing I saw was Xaml. I saw it and shrugged it off (since I was still semi-green in the ways of .Net at the time). Xaml was a strange language and I felt more comfortable honing my Perl skills before touching it. However, now looking over 3.0 and also reading more into Xaml, I must say that I wish I did discard it earlier. WPF uses Xaml (or can be generated through code) and the deeper you go into the 3.0 technologies, so does everything else. The power of Xaml is amazing and seeing how it works along with Silverlight, it truly is a remarkable language.

While probably not the most professionally practical in many current settings, I can see many companies begin to adopt WPF should their development staff become educated in such. The sheer power is amazing and becoming well versed in it has 0 negatives from what I can tell.