The Value of a Flawed Process

imageRecently at work a few of my teammates and myself were discussing Agile methodologies and started talking about the differences between having a process, versus not having a process.  The point was brought up many times that teams at our organization claim to be using scrum or extreme programming but are really doing what I call “Cowboy Programming”, I am sure that there is a better term for it, but basically they are running down the halls holding the Agile banner but doing whatever they want.  They do not have a process.  They meet with limited success because the projects they are working on are very small in scope and they have a pretty high level of interaction with their customer.  When our company tries to apply this same approach or lack of approach to larger projects it fails, and fails gloriously. 

So what is my point?  Well, during this discussion I started to realize that having a process, even a flawed one is better than no process at all.  If you don’t have a destination in mind and haven’t charted a path to get there how can you tell if you made it or not.  The more important part of this to me is the how you are going to get there, not the path and not the destination.  I know very Zen right?

So what is the value of a flawed process?  The value of a process is that you can compare you success or failure to it and see where you went wrong.  If we didn’t have a yard stick how could you communicate if something was shorter or longer, or better yet, measured.  The process is a set of expectations about behavior during an activity.  Once the activity is complete you can see if your actions meet with your expectations.

Therefore having a process, even a flawed one, will give you a basis for comparison and a way to measure inefficiencies that will lead to improvement.  If you do nothing, you have nothing to measure. There is value in a flawed process.

Store User Credentials for External Sites in Windows 7

Back in May I posted “Stop Team Explorer from asking for login for CodePlex Projects”, and now that I have made the transition to Windows 7 at work (finally) I needed to figure this out again.

The problem is that every time I go to switch to the CodePlex TFS Server I have to enter my CodePlex login information.  I , being the lazy person I am, don’t want to have to do that every time.  Yes, it is probably more secure, but I feel if you have the ability to log on to my PC at work you probably already have enough access to really screw me.

Anyway here are the steps for Storing User Credentials so you don’t get prompted all the time.

The Credential Manager to the rescue

What is Credential Manager?

Credential Manager allows you to store credentials, such as user names and passwords that you use to log on to websites or other computers on a network. By storing your credentials, Windows can automatically log you on to websites or other computers. Credentials are saved in special folders on your computer called vaults. Windows and programs (such as web browsers) can securely give the credentials in the vaults to other computers and websites.

Storing User Credentials for External Sites

Open the Credential Manager by going to Control Panel\User Accounts\Credential Manager

image

click Add a Windows Credential

image

Enter in the server, user and password information and click “OK”.

So, there you go, the next time Team Explorer request access to the CodePlex server it will pass along the credentials you have stored instead of asking you for it every time.

Northwest Arkansas User Group Meetings for May

I am going to start posting information at the beginning of the month about User Group meetings going on in the area. Here is the current list I have.

Date Group Topic
5/9/2011 6:00 PM Ft. Smith .NET User Group How to be a rock star web developer!
5/12/2011 8:00 PM Nwa CocoaHeads Basic Controls – UITableView and iOS development
5/10/2011 6:00 PM Nwa .NET User Group Improving Software Maintenance
5/11/2011 11:30 AM Nwa SQL User Group SQL Server Isolation Transaction Levels

If you have a user group that meets on a regular basis please let me know the schedule and how I can get your meeting information and I will add it to the post.

Get out there and get involved!

Real Simple Discovery Made Easy with the JaySmith.RealSimpleDiscovery Library

Recently I have been spending a lot of time writing blog features for several applications I am working on.  I always have to wire up some of the same handlers for exposing API endpoints for services such as MetaWeblogAPI, Blogger, LiveJournal, etc.  So, being the lazy coder that I am I started looking at ways to make them easier to share between projects. 

In this post I am going to cover a configuration based approach I have developed for handing the first step in exposing those services, Real Simple Discovery.

Real Simple Discovery as described from the RFC posted here is as follows:

Really Simple Discovery is a way to help client software find the services needed to read, edit, or "work with" weblogging software.  Although I talk about weblogging software, there's no reason this format can't apply to other forms of web client/system software that I wasn't considering, or may not even exist as of this writing.  This format is simple but flexible. One of the design goals was to ensure that it would be human writeable. This was my "test" for ensuring that the format was easy for everyone to implement.

What is the benefit of using a handler versus just putting it in an rsd.xml file at your web root?

If you are creating a simple site that is for a single URL and will never be used by others then using an rsd.xml file is an ideal solution.  On the other hand, if you are creating a project that you expect others to install on their own domain they will have to modify the rsd.xml file to provide the full URL to each handler.  This is something you would expect a developer to know how to do but not someone who has just download your code and installed it.  They expect to deploy and it just to run.

Dynamically generating this information allows for a zero config setup where the code that generates the XML can figure out the correct URL’s to provide without the need of manual configuration.  The developer sets up the protocols they want to implement in the web.config file and the real simple discovery handler generates the xml based on that config.  In this scenario the user of the site does not have to setup anything to get it to work

Example rsd.xml from my blog using Blogengine.NET

  <rsd version="1.0">
  <service>
    <engineName>BlogEngine.NET 1.6.1.0</engineName>
    <engineLink>http://dotnetblogengine.com</engineLink>
    <homePageLink>http://jaysmith.us/</homePageLink>
    <apis>
      <api name="MetaWeblog" preferred="true" apiLink="http://jaysmith.us/metaweblog.axd" blogID="http://jaysmith.us/"/>
      <api name="BlogML" preferred="false" apiLink="http://jaysmith.us/api/BlogImporter.asmx" blogID="http://jaysmith.us/"/>
    </apis>
  </service>
</rsd>

Installing JaySmith.RealSimpleDisovery via NuGet

This approach will work for both WebForms and MVC applications since it uses a handler to basically bypass the UI layer.

Example of the config

<realSimpleDiscovery>
    <apis>
      <add name="Atom" preferred="false" apiLink="atom.axd" />
      <add name="Blogger" preferred="false" apiLink="blogger.axd" />
      <add name="MetaWeblog" preferred="true" apiLink="metaweblog.axd" />
      <add name="Manila" preferred="false" apiLink="manila.axd" />
      <add name="MetaWiki" preferred="false" apiLink="metawiki.axd" />
      <add name="LiveJournal" preferred="false" apiLink="livejournal.axd" />
    </apis>
</realSimpleDiscovery>

Navigating to http://[MyHost]/rsd.axd will display the following:

<?xml version="1.0" encoding="utf-8" ?> 
<rsd version="1.0">
  <service>
    <engineName>JaySmith.RealSimpleDiscovery Engine v1.0</engineName> 
    <engineLink>https://github.com/JaySmith/RealSimpleDiscovery</engineLink> 
    <homePageLink>http://localhost:4104/</homePageLink> 
    <apis>
      <api name="MetaWeblog" preferred="True" apiLink="http://localhost:4104/metaweblog.axd" blogID="http://localhost:4104/" /> 
      <api name="Atom" preferred="False" apiLink="http://localhost:4104/atom.axd" blogID="http://localhost:4104/" /> 
      <api name="Blogger" preferred="False" apiLink="http://localhost:4104/blogger.axd" blogID="http://localhost:4104/" /> 
      <api name="Manila" preferred="False" apiLink="http://localhost:4104/manila.axd" blogID="http://localhost:4104/" /> 
      <api name="MetaWiki" preferred="False" apiLink="http://localhost:4104/metawiki.axd" blogID="http://localhost:4104/" /> 
      <api name="LiveJournal" preferred="False" apiLink="http://localhost:4104/livejournal.axd" blogID="http://localhost:4104/" /> 
    </apis>
  </service>
</rsd>

Another feature is that the implementation is flexible enough to handle new APIs as they become available.  To expose a new api all you have to do is add it to the web.config file and the end point of the new api will be generated just like all the rest.

Example of new API

  <realSimpleDiscovery>
    <apis>
      <add name="Atom" preferred="false" apiLink="atom.axd" />
      <add name="Blogger" preferred="false" apiLink="blogger.axd" />
      <add name="MetaWeblog" preferred="true" apiLink="metaweblog.axd" />
      <add name="Manila" preferred="false" apiLink="manila.axd" />
      <add name="MetaWiki" preferred="false" apiLink="metawiki.axd" />
      <add name="LiveJournal" preferred="false" apiLink="/api/livejournal.axd" />
      <add name="MyNewApi" preferred="false" apiLink="/mynewapi.axd" />
    </apis>
  </realSimpleDiscovery>

Output with new API after navigation to http://[myhost]/rsd.axd

<?xml version="1.0" encoding="utf-8" ?> 
<rsd version="1.0">
<service>
  <engineName>JaySmith.RealSimpleDiscovery Engine v1.0</engineName> 
  <engineLink>https://github.com/JaySmith/RealSimpleDiscovery</engineLink> 
  <homePageLink>http://localhost:4104/</homePageLink> 
 <apis>
  <api name="MetaWeblog" preferred="True" apiLink="http://localhost:4104/metaweblog.axd" blogID="http://localhost:4104/" /> 
  <api name="Atom" preferred="False" apiLink="http://localhost:4104/atom.axd" blogID="http://localhost:4104/" /> 
  <api name="Blogger" preferred="False" apiLink="http://localhost:4104/blogger.axd" blogID="http://localhost:4104/" /> 
  <api name="Manila" preferred="False" apiLink="http://localhost:4104/manila.axd" blogID="http://localhost:4104/" /> 
  <api name="MetaWiki" preferred="False" apiLink="http://localhost:4104/metawiki.axd" blogID="http://localhost:4104/" /> 
  <api name="LiveJournal" preferred="False" apiLink="http://localhost:4104/api/livejournal.axd" blogID="http://localhost:4104/" /> 
  <api name="MyNewApi" preferred="False" apiLink="http://localhost:4104/mynewapi.axd" blogID="http://localhost:4104/" /> 
  </apis>
 </service>
</rsd>

You can see that the new MyNewApi endpoint has been included.

Looking for feedback

I am really looking for feedback on this approach so if you are creating applications that need to use Real Simple Discovery please give this a test drive and let me know of any improvements you would like to see.

Resources on Real Simple Discovery:

RFC: Really Simple Discoverability 1.0

http://archipelago.phrasewise.com/display?page=oldsite/1330.html

http://cyber.law.harvard.edu/blogs/gems/tech/rsd.html

Inbox Zero: Free yourself from the Inbox Dungeon

image

On March 26, 2011 I was meeting with Tim Rayburn and Devlin Liles at our first RoundTable (More info on this coming) meeting.  The conversation at some point turned to Inbox Zero.  I had heard of it but had to admit I wasn’t really sure what it was all about.  I stated that I didn’t think I could achieve zero emails in my inbox and the best I could hope for was to reach zero unread.  Yes, at the time I had over 2000 emails in my inbox.

Tim chided me for such a practice and started discussing the virtues of inbox zero.  That was enough for me to seriously reconsider my thinking.  So, on Monday morning I set about to learn about inbox zero.  After watching Inbox Zero by Merlin Man on YouTube, truly inspired I set about employing the techniques outlined by Mr. Man and have been greatly pleased with the results.  So much so that I wanted to put a post together discussing what worked for me and why in the hopes that others can free themselves form Inbox Dungeon.

If you can take care of it in two minutes or less do so and delete it

This is one of my favorites, if you can do it in two minutes or less just do it and delete.  Done! Gone, not more worries. 

If it is something you need to reply to but can’t in two minutes or less move it to a “To Respond” folder

This has turned out to be an awesome strategy, not only does it get it out of the inbox it allowed me to discover a really interesting feature of Outlook.  I didn’t realize that Outlook had a feature that if you reply to an email from a folder other than you Inbox it will put the reply in the same folder.  This has turned out to be a huge timesaver, if I am ready to archive both of those emails I can select them both and move them instead of having to dumpster dive the “Sent Items” folder.

If at the same time you strive to implement 5 Sentences or Less then creating the responses becomes even easier.  What do you usually do when you get an extremely wordy reply to a simple question?  Scroll to the bottom and find the main points and actions, right?  So, write your response to only include the main points and actions.  This will not only increase your time to reply it will also reduce the amount of time the other person spends trying to figure out the information.

If I can’t reply in 5 sentences or less I pick up the phone and call.  This is usually because there are questions that need to be answered before I can fully compose my response.  Instead of creating a very lengthy email thread that may takes hours or even days of back and forth, just pick up the phone, have the conversation, get the questions out of way.  Remember the goal is to reduce the amount of time spent on items in your inbox so you can spend more time on work that brings value.

Don’t let you inbox be your task list

A great point made by Merlin was that you inbox is not a task list and should not be used as such.  If you need to do something because of an email, we all get work request via email, then remove it from the inbox and put it on a task list.  Then work your task list as normal.  Having task in multiple places causes productivity issues due to all of the switching from one list to the other and often results in things being missed or forgotten.

Don’t make archiving emails too difficult.

I had about 25 folders in my personal archive that I used to catalog emails.  I couldn’t remember any time I had really needed to find an email in those folders and if I did I used the search in my email client.  So, why was I putting them in all of those folders if they didn’t add any value?  I know have one “Archive” folder where all things important that need to be saved for a while are put, a few specific project folders and one for each application I support.  The application support folders will probably go away as soon as I put some time into pruning them.

Summary

In summary I have been using the techniques for about a month now and have been able to achieve Inbox Zero every day.  I only have to process about 10 emails at a time, which means I get them done very quickly and get to return to more important work.  If you are stuck in you inbox all the time I recommend you give this a try, and decide for yourself if this frees up more of your time to spend on more valuable task.  I know it did for me.

Calendar

<<  August 2017  >>
MonTueWedThuFriSatSun
31123456
78910111213
14151617181920
21222324252627
28293031123
45678910

View posts in large calendar

Month List