New Gig

Today officially marks my first day at SB Stone. I thought a post was warranted to talk about what we are trying to do and how open source, .net, mobile, all the fancy buzzwords are part of it.

I am the first full time dev in what the company is calling our "interactive" division. SB as a whole really has 4 main markets, staff augmentation, IT services, support and this new interactive group.

So what does interactive mean? Well... really all it means is we want to build a "studio" style dev wing where we do both project work for third party clients, as well as build our own products to market and resell. We're hoping the project works supports the dev time needed for our own things until those become profitable. Also as with anything some will hit and some will miss.

So why did I come over here? Mainly because the new group wants to build a new brand and image for the company, a large part of which will be participating and contributing to the dev and tech community. That means participating at and speaking at conferences, sharing knowledge through blog posts / twitter / user groups, all of it.

From a tech standpoint our group is looking at a mix of .NET and Open Source tools, specifically Ruby on Rails (although we have PHP resources as well.) We're also training up on mobile including iOS and eventually Android so a whole lot of different tools. My role from a marketing perspective is mostly going to be focused on the Rails side though. So hopefully in the near future I'll be going to more ruby conferences and events to talk to people about what we're doing and how Rails is playing in the marketplace.

The thing i'm most excited about though is building out a proper agile dev team. Earlier today we committed to following Kanban via Agile Zen for my first project, and hopefully many more going forward. We're adhering to test driven development, continuous integration and emergent design as well. The only "hot" agile practice we aren't going quite yet is pairing, and only for lack of collocated people (and remote pairing, in my opinion, sucks.)

So that's what I'm up to. If your an independent or even a full timer looking to help us out let me know. We're always looking for contractors to keep available and we'll hopefully be building up more of an in house team in the coming months. Even more importantly if you know of any small businesses looking for rails / php / .net help LET ME KNOW :-)

GiveCamp 2010

This past weekend I had the opportunity to be part of something the likes of which I had not yet seen in the Cleveland area. From Friday until Sunday the folks at Lean Dog Software in collaboration with a handful of organizers and sponsors hosted Cleveland's first GiveCamp.

GiveCamp is a national program that pairs up talented software developers, designers and other technical specialists with local non-profit organizations to complete technical projects that the non-profits would otherwise be unable to afford. This past weekend was the first time Cleveland has hosted one of these events and I think we did our geek brethren in other, much larger, cities proud. When it was all said and done over 20 charities were helped by over 100 volunteer making GiveCamp Cleveland the largest first GiveCamp ever. it wasn't quite the largest of all time, but maybe we'll take that record next year.

For those curious the weekend runs like this.

Friday night we were paired up with our charities and sat down with a sponsor from the charity to talk about their needs and what our goals for the weekend were. In most cases the plan for the weekend was mapped out in advance by a business analyst that was pre-assigned to each team. However, in the case of my charity, The League of Women Voters of the Cleveland Area, we came it knowing virtually nothing. You see the organizers had anticipated having enough people to help roughly 15 charities, but come the week of the event they had enough to add 7 more. The LWV Cleveland was one of the late additions so we had to scope and plan the project on day one instead of in advance.

Our sponsor Sherece was amazing. She understood our limited time frame and was willing to compromise when needed but also did a great job of explaining the purpose of her organization so we could build out the best site for her that the time and resources allowed.

From Friday night through all day Saturday the teams went to work, in most cases this meant building out and customizing a Wordpress installation for each charity. Something like 15 of the teams used Wordpress which is really a testament to the product and how flexible it is.

Throughout the weekend stand-ups were held to make sure the teams were on track. Also breakfast lunch and dinner were provided both Saturday and Sunday.

Sunday evening we trained out charities, presented the final projects and handed over the keys so to speak. The charities all seemed quite grateful for the work that was done, but in reality it was the volunteers who seemed most upbeat. I think I speak for all of us when I say we had an absolute blast using our abilities and skills in a way that we very rarely get to. I told some friends in advance of this weekend that I don't know how to build a house, but I know how to build a website, so getting a chance to do that for a great organization like the LWV was not only fun but an honor.

Just in case anyone is curious the site we built can be found at http://www.lwvdev.com. We had some issues connecting with their hosting provider so itll be switched over to their main site, lwvcef.org in the next week or so.

Some thanks to hand out. First off to all of the organizers especially Mark Schumann who acted as MC and leader of the organizers, Andrew Craze who served as the developer lead and Jon Stahl who's company Lean Dog hosted the event on their amazing workspace (the old Hornblowers boat on lake erie.) Also thanks to the IEEE for acting as a non-profit sponsor of the event and Burke Lakefront Airport for offering up the entire terminal to be used by the campers when the number of volunteers overflowed the boat.

On a personal note I moved to Cleveland Ohio 5 years ago because of a job offer after college. When you think of Cleveland you don't really expect to find a vibrant and exciting community of software developers and tech enthusiasts. This isn't Silicon Valley or Boston or Austin. Let me just say, if you believe that like I did you couldn't be more wrong. Over 100 people showed up this weekend from dozens of companies all over Northeast Ohio. There was a range of expertise that ranged from SQL to .NET and Ruby, Coldfusion, PHP you name it and it was represented. This is a great city to live in, with great people and one hell of a technical community, and that friends is why I'm #happyincle.

Anyway Thanks again to all those involved and I can't wait to do it all again next year.

RCov w/ RSpec-2

So I've spend the last couple weeks updating an old Rails application to Rails 3 and RSpec 2, both of which are currently still in beta.

Early on I noticed that the new rspec doesn't quite support rake spec:rcov yet. The new core framework has the rcov flag but there's no default rake task. RSpec-rails also removed the spec.rake task from your rails project and centralized it into your gem install, which confused me to no end. So in case anyone else wants to run rcov on your code I thought I might post what I did to make rake spec:rcov work again.

First a couple prereqs. I'm using an RVM install of all of this with ruby 1.8.7 (only because 1.9.1 gave me problems w/ rails 3) so in the steps below replace the paths I give with the path to your gem installation folder and you should be good.

1) Open ~/.rvm/rubies//lib/ruby/gems//gems/rspec-rails-2.XXXXX/lib/rspec/rails/tasks/rspec.task in your favorite editor.

2) Add this rake task

desc "Run all specs with rcov"
RSpec::Core::RakeTask.new(:rcov => spec_prereq) do |t|
t.rcov = true
end

That's it. Pretty simple.

A caveat. Right now this runs ALL of your specs in both your rvm ruby folder and your project. I haven't a clue why, hopefully someone smarter than I will comment. That means rcov take a while and when its done its cludgy. If someone does help me out I'll post an update, in the meantime this works.

Unit Testing Role Based Security w/ ASP.Net MVC

I recently started working on a little project management demo project in ASP.Net MVC. As part of that I wanted to make sure I unit tested as much as possible so that it could act as a good example of how to do things for other people in the future.

I ran into a bit of a snag when trying to verify that the right security roles are required on my actions. I found out from a few blog posts that ASP.Net follows the .Net 2.0 membership and role provider model, and that you can simple decorate a controller or action with [Authorized] attributes to restrict access. Pretty cool and really simple unfortunately not very testable. When you unit test actions in MVC you call the method directly from the test, bypassing the routing engine where these authorization checks are made.

Fortunately I found Paul Brown's excellent post on how to test that you have applied the right roles. I liked what he did but it was a bit to case specific for me so I made it a bit more generic. Here's what I came up with:

I took Paul's code and turned it into a series of three controller extension methods which verify if the entire controller requires authorization, a particular method requires authorization or if a particular method requires a given role (i have not yet written the obvious 4th case - an entire controller requires a given role but it should be trivial.)

public static class ControllerExtensions 
{
     public static bool RequiresAuthorization(this Controller controller)
     {
           MemberInfo memberInfo = controller.GetType();
           var attributes = memberInfo.GetCustomAttributes(typeof(AuthorizeAttribute), true);              
           return attributes != null && attributes.Length == 1;
     }
     
     public static bool ActionRequiresAuthorization<T>(this Controller controller, Expression<Action<T>> expression)
     {
           var member = expression.Body as MethodCallExpression;
           if (member != null)
           {
                 var methodInfo = member.Method;
                 if (methodInfo != null)
                 {
                       var attributes = methodInfo.GetCustomAttributes(typeof(AuthorizeAttribute), true);
                       return attributes != null && attributes.Length == 1;
                 }
           }
           return false;
      }
 
      public static bool ActionRequiresRole<T>(this Controller controller, Expression<Action<T>> expression, string role)
      {
            var member = expression.Body as MethodCallExpression;
            if (member != null)
            {
                 var methodInfo = member.Method;
                 if (methodInfo != null)
                 {
                       var attributes = methodInfo.GetCustomAttributes(typeof(AuthorizeAttribute), true);
                       var authorizeAttribute = (AuthorizeAttribute)attributes[0];
                       return authorizeAttribute.Roles.Contains(role);
                 }
            }
            return false;
       }
}

Here is an example test for Requires Authorization: (using NUnit)

[Test]
public void Should_require_authorized_user_for_all_actions()
{
     var controller = new ProjectController(null);             
     Assert.That(controller.RequiresAuthorization());
}

And a sample for ActionRequiresRole

[Test]
public void Should_require_admin_to_add_a_bug()
{
     var controller = new BugController(null);
     Assert.That(controller.ActionRequiresRole<BugController>(x=>x.Add(), "Admin"));       
}

EDIT: John suggested changing the extension methods into lambda actions so that they would be strongly typed. I agreed so this has been updated accordingly.

Forcing Visual Studio to run as an Administrator

This superuser post explains how you can force visual studio (or any application) run as an administrator. This is helpful for Windows Vista and Win7 users who have issues with IIS when running Visual Studio as a non-admin.

http://superuser.com/questions/23462/how-to-always-launch-vs-net-as-administrator

Just in case the link dies here's the answer:

To ensure visual studio and any file opened w/ visual studio (i.e. double clicking on a solution file) always opens VS as an admin (from Vdex):

Got to the actual deven.exe in "C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\", right click on devenv.exe, properties, compatibility and tick "run as administrator"

To set a particular shortcut to always open as an administrator (From Jared Harley):

• Right-click on the shortcut (this works even in the Start Menu)


• Select "Properties"


• Select the "Compatibility" tab


• Click the "Change settings for all users" button at the bottom


• Enter the administrative username/password


• In the new window, select "Run this program as an administrator"


• Click OK


• Click OK

Intro to Agile (Part 2)

In the last post i went over the first half of my presentation on agile software development. We talked about the purpose of agile and how, at a fundamental level, it's all about the way you think and not the things you do. That post was WAY more important than this one so if you're starting from scratch in agile I highly recommend reading that first.

Today I'm going to cover the various tools, practices and patterns people apply to try and be an effective agile team.

Agile Project Management

There are three overarching project management techniques that are applied to agile projects. They differ in their implementation but all focus on the same concept of continuous feedback and close collaboration. They are:

1) eXtreme Programming (or XP) - This was the first technique I heard of and in some ways it is the "strictest" of the agile methodologies. In focuses on short development iterations (or sprints), a series of planning meetings throughout the process and sound development practices like test driven development and paired programming.

2) Scrum - Scrum is an incredibly popular technique among enterprise agile implementations. It is very similar to XP in day to day implementation but also covers the scenario where a product is being developed by a large team and how you would go about managing that. Specifically scrum speaks about breaking large teams into smaller scrums then developing some sort of process (called a scrum-up) where the smaller teams report to a higher organization to share information. Development practices are more left to the individual implementations to decide but TDD is generally encouraged in all of the agile implementations.

3) Kanban - I perceive Kanban to be one of the newest options but it is getting a lot of traction. It emphasizes a continuous flow of new functionality with intermittent triggered events that might bring about planning meetings or retrospectives. It is heavily focused on pulling story cards through the process represented by a Kanban board the team views the project status from.

Which of these options you choose is up to you and your business. For the type of project work we do at my company Kanban seems like the best fit, but I have worked for in house IT departments where Scrum or XP was perfect. As with most things in agile the key is being flexible.

Storycarding

One of the common practices that occurs in any of the methodologies listed above is storycarding. Put simply storycarding is the act of breaking up an applications requirements in to small chunks and framing the description of that requirement from the perspective of the intended end user. Put even more simply its turning your product into a series of small stories.

With storycarding we have a few rules:

1. Each card should tell a story about how a user will interact with the system


2. A card should have some business value


3. Each story should have as little complexity as possible


4. Stories should consist of as little detail as possible

Numbers 1 and 2 above leave us with a problem. If every story has to be about the user and they all have to have concrete BUSINESS value how do we account for tasks that are purely IT driven, like "Setup infrastructure" or "Upgrade to .NET 4.0?" As with most things in our profession the answer is "it depends." Purists would say that those tasks need to be taken inline with some other business focused task that drives them. For example your very first story could be used as a catalyst for "setup infrastructure" because without that infrastructure that first story can never be released and thus is never complete. Some more practical teams opt to put in technical story cards and negotiate with the business time and prioritization of those tasks. Ultimately this is up to the team.

Numbers 3 and 4 go hand in hand as well. We want out stories to have little complexity so that they are each to test, complete and assign. We don't want to have stories that take weeks to finish and we don't want a lot of overhead in order to get started on one.

The reason why we favor less detail in a story is to encourage conversation and collaboration. The more we put in writing in advance of the work beginning the more likely it is that we will need to change the details later on, most likely after the card has already been completed as written. Instead a storycard is treated as an "invitation to have a conversation" with our business partner.

Managing Work-flow

So knowing how agile teams usually generate application requirements is one thing, but what do you do with all those story cards?

This is an area where the different agile approaches differ. XP and Scrum are generally in line so we'll talk about their approach first.

XP and Scrum focus on working in short sprints (also called iterations.) In this system work is typically done in 2 week spurts of activity (although the actual amount of time varies by team.) Each sprint follows a cycle that consists of a sprint planning meeting, a period of work and collaboration with the business followed by a retrospective, then the whole process starts again.

Sprint Planning Meeting

A sprint planning meeting is a time period where the team evaluates how they are doing so far (retrospective) and plans out storycards for the next sprint. Typically the business will assign priorities to cards and the cards will be scheduled for the sprint in priority order. Exceptions to the priority order rule occur when one card is dependent on another or the business, having seen the progress the team is making, decided to re-prioritize a card during the SPM.

The actual process associated with an SPM varies by team but in general it begins with a retrospective on the previous sprint. It then involves someone reviewing what tasks in the previous sprint were finished and which ones need to be rescheduled, potentially into the upcoming sprint. Some teams then opt to do a live demo of the currently in development system. Finally the business works with the team leadership to prioritize the remaining cards and schedule them into the sprint. XP uses the concept of "yesterday's weather" when determining how many stories make it into a sprint. Basically this means that however much work was accomplished in the previous sprint if the amount of work you anticipate for the next sprint. Any remaining stories are placed in a buffer to be picked up in priority order if all of the scheduled tasks are completed.

Release Planning Meetings

Scrum and XP also have a concept of a release planning meeting or RPM. An RPM occurs in advance of the kickoff of the project as a whole and is used to plan out how the major areas of functionality will occur throughout the course of the project. The estimations and schedules that come out of an RPM are really fuzzy but they give the team an roadmap of sorts as they progress throughout the project. Some teams will create storycards in advance for the first few sprints and pre-schedule those cards in the RPM. This process works well enough so long as the result is seen as flexible. Those schedules will change as you learn more.

The Kanban Approach

Kanban takes a different approach from Scrum and XP. Instead of having prescheduled meetings and working in short sprints Kanban focuses on a continuous pull of new functionality into the system. Reviews, retrospectives, demos and planning sessions still occur but they are triggered instead of scheduled.

A storycard in Kanban begins prioritized and ready to be worked on. Team members pull cards from the ready bucket into the development bucket, as they are finished they move to QA, staging and deployment (or any number of other buckets depending on the team.) New cards are planned when the ready bucket gets low. What "low" means is up to the team. For one team they might decide that when there are only 4 stories pending they need to sit down with the business and plan out more stories. For another team that number might be 20. The same applies for demos or retrospectives. One team I saw triggered a formal retrospective when enough post-it notes were left by team members on a "retrospective" board. So as team members saw good, bad  and ugly things happen they would leave notes on the board (anonymously if they choose) and when a certain number were there they would all sit down and review them.

The key thing to note here is that Kanban really doesn't "stop." There is no break to plan an IPM and then restart work. Team members keep building for as long as there is work to be done.

The Daily Standup

The final meeting that seems to be consistent across Scrum, XP and Kanban is a daily standup. A standup meeting is a short meeting held daily where all of the development team members and sometimes testing and business will get together to go over the current state of the project. In general everyone in the team should be able to answer three questions.

1. What did I do yesterday?


2. What am I doing today?


3. Do I have any roadblocks?

Should a team member encounter any problems the team should match people up to overcome those obstacles and move on. In general an ideal stand up is no more than 15-20 mins long.

Sprint 0

There's a lot of debate as to what an Agile team can do in advance of a project. The notion of pre-planning and pre-work has come to be referred to as "sprint 0." Generally the point of Agile is to adapt as time goes on and to not make decisions well in advance of when they need to be made. The notion of a period of pre-planning and decision making seems to fly against the goals of an agile team, but practically there will always be a number of tasks that must occur before the project can get rolling.

The rule of thumb for Sprint 0 is to not do any work or make any commitment to a course of action that could change based on the businesses requirements. If a task is aligned with the requirements of the project it should be accounted for in a storycard and prioritized into the project.

There are a number of activities that do make sense though. You can identify team members, stakeholders and set expectations for the project. In most situations you can decide on an overarching technology, for example if you tend to be a .NET shop you might choose between webforms or ASP.NET MVC. Finally you might identify the very large functional areas you want to hit on for this project, i.e. you might say "we are working on a billing and inventory management application that ties into our enterprise ERP system."

Wrap Up

So that's the majority of the content from my presentation on agile to my coworkers. The Slides have a bit more information if interested.

In my general experience agile is a concept worth learning about. The teams I have been on have had higher quality products, more tightly knit relationships within the teams and have ultimately delivered a result that the business was very happy with. Agile may not work in every environment but if you can make it work in your organization I would recommend giving it a try.

Intro to Agile

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

http://agilemanifesto.org

Last Thursday I had the opportunity to present agile development to most of my team mates at Paragon. For some of them it was the first time being formally introduced to the concepts  and practices and I'm happy to say it seemed to go really well. I promised a followup post on my site summarizing what was covered and providing a copy of my slides. This is part one of that post. I will provide a copy of the slides on both posts but for this first post I'm only covering the first half of the presentation.

Agile is a state of mind

There's a misconception among a lot of developers that agile is the sum of the practices, tools and processes that make it up. In other words to many people agile is doing test drive development, pairing and working in sprints. The problem with this view is that it really misses the fundamental reason why agile came to be. In fact when the agile manifesto was written it explicitly included the phrase "Individuals and interactions over processes and tools."

Agile is about how we interact with our team and our customers. Agile is about how we embrace change. The tools we use to accomplish those goals are simply a means to an end.

There are four points that, to me, making up a successful agile team.

Delivering the right product at the right time

The right product is composed of the product that delivers the most business value to the customer. Agile teams do this by allowing the business to prioritize all the work and performing that work in priority order.

The right time is when the remaining tasks no longer convey a competitive advantage to the business. We identify when this is by showing the product to real people (users, business, stakeholders) as early as possible and acting on the feedback we receive from those people.

Focusing on Communication and Collaboration

Agile teams work in close quarters. All the members of the team (project management, development, testing and the business) should all be in close physical proximity if at all possible. This allows the free flow type communication that teams thrive on. It is true that remote teams can accomplish great things in an agile manner but collocated teams are preferred.

Agile teams work with an embedded business representative. Ideally this individual is an actual employee or stakeholder of the company the product is being built for. Unfortunately that isn't always possible. In their absence any individual who can make an authoritative decision on the functionality of the application and who can set task priority can represent the business. Regardless the customer needs to be involved in key planning meetings and demos.

We strive to create short feedback cycles. This means developers working closely with testers to test the code they write as it is completed. This also means working with our business customers to show them what we build as we build it and getting feedback on it. Short feedback cycles allow us to act on problems or inconsistencies and respond to shifting priorities quickly. "Throwing the code over the wall" to QA is no longer acceptable.

Finally we learn from the past. We constantly evaluate how we are doing and adapt quickly to make sure the project is successful.

Embracing Change (even late in the process)

Agile teams deliver what the business needs and not what they think they want.

Traditionally changing the requirements of a project in midstream is frowned upon. Its scope creep or against the design and makes our jobs as developers more difficult. We introduce elaborate change management processes to punish any poor business person who should dare change our requirements.

Agile teams move past that mentality. We recognize that as we build our customers product their priorities will change. As they see the progress we are making some items will become higher priority than other and sometimes entirley new areas of functionality will become apparent.

The result of embracing change is a happier customer and higher acceptance of the product. The real goal though is delivering the right product. We know its the right product because the customer has been involved the entire time, has shifted priorities as necessary and has told us that there is no more work to be done to deliver the benefit they need.

Deferring decisions till the last possible moment

We can't predict the future but we love to try. Agile teams defer decisions until they have as much information as possible to make the right one. Very rarely is this the beginning of the project. This means we generally don't write comprehensive design documents or requirements documents well in advance of the development process because we don't know enough to accurately write those documents.

As developers this means only introducing software design elements we need. Agile has a phrase for this - YAGNI or "You ain't gonna need it." Generally if we need something once we build it in the simplest way that could possibly work, if we need it again we refactor our solution to be more flexible or anticipate future changes.

To be continued

So the message of the first part of this presentation is that agile is inherently philosophical. It's how we look at a project and how we interact with our team.

In the next post I'll cover the second half of the presentation, which goes over some of the practices that are used to help run an agile project. If you want a sneak peek here's a copy of the slides.

Into to Agile (PDF)

Sometimes ASP.NET Baffles Me

Fair warning, this post is going to be a bit of a rant about ASP.Net and how it does nothing like every other web language on the planet.

So far today i've spent about six hours trying to come up with a solution to one of those problems that seems like it should be oh so simple to solve. As of this point, I got nothin'.

So the client I'm at these past couple months uses a third party set of ASP.Net user controls to handle a lot of AJAX tricks and visual prettiness. The only problem is from what I can tell they don't work. They don't render correctly in Firefox, occasionally don't render correctly in IE and cause some serious issues when paired with jQuery. The problem i was tasked to solve was a scenario where when using this third party controlset's popup box (essentially a floating DIV) it could cause the rest of the content on the page to fall down and be essentially invisible. To make matters worse the popup itself showed up below the fold, the scroll bar was disabled and it was modal, so there's no way to get back to a usable state short of refreshing the browser. After a couple hours playing with the control I decided it would be easier to pull the control out completely and go to the quite excellent jQuery UI dialog plugin. Once I applied it to the mischievous popup the UI worked and all was well... or so i thought.

A day passed and our tech lead came over. He asked if I could convert the rest of the popups in the application to jQuery for consistency and so that the issue wouldn't reoccur in the future, so I started doing that. Things were going well until I ran into another of this toolkits controls, CallbackPanel. For all intents and purposes CallbackPanel is like an update panel except it is invoked directly in javascript. I started applying the jQuery work to a popup containing one of these panels and noticed an odd trend. It behaved correctly when executed the first time, but when run again without a page refresh the javascript would execute but the server side code was never called. As of yet I have been unable to resolve this and have a pending support ticket with the vendor. My theory is the event is somehow tied to where in the DOM the panel original resides. When i put that panel in a jQuery dialog it is updated in the DOM and that breaks the event.

Since i have little faith in the vendor's speed to fix this (or tell me its intended functionality) I opted to move ahead and try and migrate the whole section into a simple AJAX call back. I would make a call to a WebMethod and return some markup from the user control that would then be injected into the popup and voila.. ajaxy goodness. This is how i would approach this on just about any other platform. Alas, .NET is not any other platform.

The first issue i run into is that WebMethods have to be static. That means I cant access the usercontrol already on the page.

Ok no problem, I'll instantiate one and get the rendered HTML, pass that back to the client.

Try instantiating the class, no go. Turns out you need to use LoadControl (a non-static method of course) to create an instance of a user control otherwise all the child controls don't get instantiated.

Crap, ok Mr. John Miller find this article for me. I create a page object, load the control, use reflection to set various properties and even isolate all this into a class called UserControlRenderer for reuse. Things are looking good until I run it.

Error executing child request for handler ‘System.Web.UI.Page

Son of a bitch are you kidding me? Do a bit of digging and find out that you cant render a DataGrid (or GridView) unless it is contained in a form with runat=server set. Which means this approach of rendering just the user control to a string and returning it won't work for my implementation because I'm using one of the most common controls in .Net.

All told I have about 45 lines of code to do nothing but try and render the control (Set up, instantiation, the class that does the rendering, etc) and I have to tap into reflection to do it. Oh and it doesn't even work.

For those of you that haven't played with any languages outside of .Net here's how much code I would need in say Ruby to render a single "user control" (they are called partials in rails)

render :partial=>"mycontrol", :layout=>false

One line... one line of code. And it works.Of course I have to get the data and set it to a variable accessable to the control, then render out the html... but I have to do all that in .Net too and I didnt count those lines in my 45 above.

From day one the ASP.Net team assumed that their target audience was a group of people who didn't understand the web. Didn't get the general stateless nature, or how HTML works. That probably made a ton of sense in 2001 when .Net was young, people were used to writing VB windows apps and there was a push to migrate those application to the web. It 2010 it makes no sense. If you are web developer and don't understand how the web works I dare say you are a quite incompetent web developer. Thank god for the push to ASP.Net MVC, here's hoping it takes over in enterprise soon.

Ok rant done. Next post will be a bit more productive.

Book Review: The Passionate Programmer

Chad Fowler's The Passionate Programmer is a book about happiness. It is about how to lead a successful happy career doing something that you really enjoy. Naturally it is geared toward software programmers but in reality many of the tips Fowler hands out could be applied to almost any career.

Fowler takes his experiences as a programmer first and a musician second and uses them to identify a set of 53 "tips" broken up into 5 main sections. These tips run the gamut from identifying a core technology or specialty to going out on your own as an independent.

At first glance much of Fowler's content could be pushed off as common sense, however in many cases the most obvious of concepts isnt readily apparent until it is brought to one's attention. The notion of treating one's career as a product is a popular notion that Fowler subscribes to and bases his advice on.

Fowler begins with "Choosing Your Market", a segment focused on identifying a technology or specialty that fits your career goals. He identifies criteria to consider when evaluating the investment required to become versed in a particular technology.

Next he lays out "Investing in Your Product." This section identifies how one can develop expertise in both the technologies they have chosen to specialize in as well as how to become a generally excellent programmer.

"Executing" is the next section of the book, which identifies how you can work to the best of your ability in your day to day tasks. A good percentage of this section is motivational in nature. Chapters like "How Good a Job Can I Do Today?" really seek to overcome the desire to stay in bed in the morning.

Fowler then covers "Marketing..." with tips about how to get your name out both within your current place of employment as well as the greater community.

Finally the book finishes with "Maintaining Your Edge" a call to action to not give up on the prior tips and to continue to treat your career as your product.

Overall the book is a fascinating read and well worth the investment for anyone who enjoys the "softer" side of software development. It serves as an excellent companion to The Pragmatic Programmer, a book with whom it shares some lineage by virtue of the publishing house.

On a school scale I would give The Passionate Programmer a solid B+. It was a good read, with some great information, but it isn't a book I would be compelled to buy as a gift or to put on a "required reading" list.

Is Mobile the New Internet?

An interesting thing occurred the other day that got me thinking.

I spent Saturday evening with a friend wandering the local Microcenter while he considered purchasing an iMac. He was making this purchase so that he could put a greater focus on his work as an iPhone developer. Naturally we were talking about the topic while the salesman was helping answer questions regarding the machine. The salesman mentioned that he too was studying iPhone development. While he was not a full time programmer he had some hobby background in Java and other languages and really wanted to write something for the iPhone.

We left the store to get dinner and when we came back a different salesman was working. Again the topic of iPhone development came up and again this salesman said he was also looking into it. His background was mostly PHP and a bit of VB, again a hobbyist.

Having had two different people, in the same night both mention their desire to learn iPhone development I said to my friend "Wow that's kinda amazing. Two people, neither of which are full time programmers and the iPhone is driving them to learn programming. When was the last time a new technology really drove a growth in hobby programmers?" His response - "The internet."

So the thought occurs to me, is this the dawn of a new trend in computing so significant that we as professional programmers need to keep up lest we fall behind? Every so often something comes along that can separate the people who are always learning, always focused from the people who aren't. We saw this when mainframe developers suddenly found themselves writing object oriented code. We saw it again when "win-forms" (or equivalent) programmers were asked to write for the web. Will mobile be the next fundamental shift in paradigm?

I'm banking on yes, and here's why.

The rise in smart phone use (and let's be honest, the invention of the iPhone) has changed consumer behavior so fundamentally that the lack of a working mobile website can now be considered a competitive disadvantage. Consumers may not have yet reached the point where they would switch from one company to another based on the strength of their mobile offerings, but i suspect if presented to some consumers during the initial purchase process it would weigh into their decision.

Would a day trading stock buyer manage their portfolio through a brokerage firm without mobile access?
How about using a bank where you can't check your balance on your phone?

Additionally I think we have reached the point where businesses can see the smart phone replacing some of the functionality that laptops have served in the past. I used to work for a fairly large insurance company. At the time all of their claims representatives carried laptops and digital cameras so that they could document vehicles as they inspected them, and over the cell network upload that information to the internal claims management system. This had the disadvantage of being bulky and expensive to maintain / repair. The laptops and camera broke frequently, often requiring a complete replacement to the tune of $300-$1500. Replace that with a $200 iPhone, blackberry or palm pre and you have a low cost, easy to carry device capable of doing everything you could do before.

So is mobile the new internet? Should we all be buying "Learn iPhone development in 21 days" books, or is it a passing fad?