[dot] Code Dump

You Don't Need Tools

2009-07-06T08:57:00.000-07:00

High quality software can be created without, advanced tools, automation, and even design patterns. Professionals in many fields besides software development are looking for latest tools, and trends to stay ahead of the competition. Allocating, learning, and implementing new tools can soon become a dangerous cycle, where an emphasis is placed on specific technologies and trends, rather than the product being created. One of the many side effects of using an ever changing tool set is adding entropy and complexity to a development ecosystem.

There are thousands of blogs on software development. Many of these blogs demonstrate, promote, or even proselytize tools or methodologies. The large amount of information provides developers with a large choice of tools and ideas. Searching for proper ideas and tools is very time consuming.

Software developers put knowledge in high regard. Learning is even more valuable. A good software developer should find a balance, between learning and doing. Programming is not philosophy. Making and creating is far more valuable to good programmers. Good is what works, and works well, not what is academically perfect.

Finding tools and even using tools can become a distraction. Learning when your tools are getting in the way is skill, which is underdeveloped, in many programmers. A perfect example is how programmers can get into holy flame wars over a TEXT EDITOR! This is just one example of where the meta-product, becomes more important than the product, but there are many others.

Ironically I am advocating learning how to ignore programming noise, in a blog.

The Lintner Code Complexity Analysis Test: Next time you start incorporating, tools, methodologies, and other ideas into your code base. Ask yourself could an average developer jump in and get the basic flow, and meaning of the code? If no, you may want to rethink your approach.

Personally I advocate simplicity, and minimalism when it makes sense, and some level of complexity is necessary. Tools create complexity. Tools require knowledge to operate, and they will change how your process works. When choosing tools, you must be aware of how they will effect your software development ecosystem over time.

Technologies, tools, ideas, or just plain noise can get in the way of creating, and making. Many times a small project or tasks can be finished the without tools, in the time it would take to set up, and use complex tool. There are many examples of high quality software that was created without code analysis tools, unit tests, and even a structured development methodologies. Next time you start working on a new project, you may want too evaluate your tools too see if they are truly valuable or just wasteful.

Whack A Mole Development

2009-04-23T09:00:00.000-07:00

Whack a Mole Development:

When making changes to a section of code, causes other bugs, sometimes recurring, to pop up. I.E. You fix one bug, and three other bugs pop up after you release.

Have you ever worked on code where troubleshooting bugs was like playing a game whack a mole. I have worked on a few applications that seem to have taken this idea to heart.

If you encounter an application that not very stable, many time your options for dealing with it are limited. You just have to work within the constraints of the system. Previously I have mentioned, defensive development as a technique to cope with difficult system. This is an example of controlling what you can, the new code, and fixes you introduce into the system.

When dealing with difficult systems your best weapon is going to be communication. Make everything as clear as possible. Make your new code readable, understandable, and most importantly comment what you changed, and why you needed to change it. Keep documentation on the system. Document critical, and time consuming tasks. If a process took you a week to update, document it, and it will take the next guy half as long.

The most important technique for dealing with difficult systems is asking questions, and making sure you understand what people are asking. Many times "whack a mole" conditions are caused by mis-communication, and lack of knowledge.

Maintaining difficult systems is a reality for many developers. This is as important, or more important of a development skill as creating new applications. Many time maintenance programming is far more difficult than new development, because you have to work outside of your code "comfort zone".

ASP.NET MVC... That was quick!

2009-03-11T05:30:00.000-07:00

So I finally delved into ASP.NET MVC. My first impression is it was very easy to get it up and running very quickly. When using the defualt application, I was very easily able to create new routes, and controllers.

The only thing that I did not like was the semantics of constructing a view. It felt so much like the spaghetti code that I tried not to use in ASP.NET. I do see benefit, because one of the down falls with traditional ASP.NET that drove me crazy was trying to implement styling, against the traditional forms controls. I can see very good things from not being tied to those controls, making it easier to implement rich controls such as items from YUI.

My first impression is it's all about the routes. Routes is the magic behind the curtains. Routes control what controllers are run, and how the URL is processed. MVC is a lot more than just URL handling, but coming from ASP.NET forms, good URL handling was one the major things ASP.NET was missing.

MVC is nothing new, but it is new to ASP.NET. I can't wait to delve into it further. I see many places where I previously used ASP.NET forms where MVC would have been a better fit. I like MVC, but I could see it being over-used, and used improperly, where something like ASP.NET forms should have been used. I also can't wait for it to go to full release, then it will be a viable option.

Optimization Is Not Easy

2009-03-09T05:30:00.000-07:00

Go to ludicrous speed!

If optimization was easy there would be no slow applications. Slow performance rarely has a single cause. Depending on the number of causes, optimization is a difficult goal. Using a consistent, and defined process needs be a critical part of any optimization effort.

"We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%" -Donald Knuth

Optimization has a number of side effects, of which we must be aware. During optimization, many times, we must make trade offs. A classic optimization case is, trading processor heavy calculations in favor of using more RAM. Optimizing code can have the unintended effect of making code unreadable, and inflexible.

I mentioned before that Optimization is a difficult goal. I lied. The truth is optimization is not a goal, rather it is a process, also it is best handled as an iterative process. Using an iterative approach allows you to compare your results, and it gives you a better shot at isolating troubled areas. The worst approach you can have is to try tackle everything at once, because you will not be able to correlate the results to a specific change.

My personal process for optimization is pretty straightforward:

Observe, and Measure
Research
Change
Analyze
Repeat (If Necessary)

Once you have a chosen something to optimize the first task is to observe and measure a metric, such as number of operations during a particular action. Attempt to do some research, as to why a particular section of code. Once you have your researched as much as you need to, use your best judgment, and make a change you think will have a positive effect. After making the change analyze whether it performed better than you original measurements, if it did you are on the right path, if not you have just eliminated a potential path.

If you are not happy with the results of a round of iteration. If you continue the process eventually you will notice that you are seeing diminished returns. A few items can be cherry picked, with a simple rewrite of this procedure. If optimizing the easiest items do not achieve your goals, then the difficult work will commence. The same procedure will be followed, but the success rate of the iterations will drop.

Optimization is one of the core group of tasks many developers will need to confront. A consistent, and methodical process will provide a stable foundation to any optimization strategy. Many times optimization goals may not be met, or will require a significant amount of effort. Serious optimization does happen, but we must realize that it is not something that just happens, it requires directed, and methodical effort.

Cloud Computing and the REST of us

2009-03-04T05:30:00.000-08:00

Cloud Computing as a buzzword is right up there with social networks, web 2.0, and everything else high technology. I have just begun to delve into researching these services, and I see a lot of potential, but I also have a hesitance that the final incarnation will not look anything like what we see now. I sincerly hope that cloud computing is not just vapor ware (pun intended). It has a possiblity of completly change the way software is hosted, and possibly even architected.

If you work for one the tech giants, or a SF start up your companies may already be creating applications in the cloud. As a web developer not on the bleeding edge this may mean something different. This will most likely serve as an option in the future for hosting larger applications, but I don't think it will wipe out traditional hosting any time soon, just because I believe many companies would be hesitant to put their data out in a "cloud".

As a developer on the ground level I think we will start to see the cloud producing content delivery services, and scalable web services that are reliable and USABLE. Once we have useful services, they can be integrated into our applications without the risk many services have today.

We may even see new languages and programming styles emerge to fit the paradigm, and that will filter back into main stream development. So I probably won't be programming in "C flat++" or "Anaconda", or "IronSaphire" any time soon, but we may see the concepts and ideas filter back to plain old boring VB, and C#.

I believe we will also see a move away from efficient nit picking in development. If you start working in an environment where processor and ram are cheap and on demand, you probably won't want to spend three days optimizing a single sort procedure, becuase it would not yeild any real ROI, and infact probably the opposite.

I do believe that this won't throw traditional programming practices out the window. As a programmer moving into the new realm of highly distributed computing, the fundamentals will be even more important. If a bug exists in single threaded system it only exists once, if a bug exists in a highly distributed system, it could exist a thousand times, and this will require us to be even more dilligent. We will also encounter new types of bugs that exist, because of distributed enviornments.

The discussion has already be started on the bleeding edge of the software community, and it will beging to become more mainstream. The developers on the ground may start to see changes, in how they do things. We will have more options on using third party services in developing their software. We will also be expected to make our applications available as a service for the companies we work with. API style programming will need to become second nature.

This all rehash of the idea that all computers do is input data, output data, and compute data, nothing more. The major change this time around is it will be done on a massive scale. So when I create my widget processing service, it will be able as many widgets as needed, and I never have to worry about machines, and bandwidth, becuase it will now be available, and scale on demand.

Programming Yield Signs

2009-03-02T05:30:00.000-08:00

I don't advocate holding any one to any specific sort of rules, but I do have a general set of guidelines that I work with. Here is a simple set of helpful coding warning signs that can save you major coding accidents, and nasty refactorings down the road if you pay attention when you see them. Most of these apply generally to object oriented language, but could apply elsewhere. Without further ado, my programming yield signs.

Recursion

If you are using recursion there may be a better way, or I like to say just because it fits into recursive paradigm, it doesn't mean it HAS to. There are many times I have found myself ending up doing something recursively, and regretting. My word of warning: "It starts with a couple of recursive functions, and then you wake up 3 days later in the middle of New Mexico in playing Russian roulette with Bill Richardson. Recursion has it's uses, but with it you probably are going to incur a performance cost that may not be worth it.

Nesting Logic

Any time you start nesting logic beyond 1 or 2 levels this should be a warning sign that something could be a miss. This is where debugging is generally going to start getting difficult. If you are having difficulty coding a section, and it involves nesting of logic this a point where you need to step back and get a second opinion on how to do it. I am by no means saying don't do it, but watch

Really Long Functions

Writing really long functions is generally a sign of two things, either there is a lot of logic to parse through, or you may be doing something poorly. This may also be an indicator that something else outside of your current scope is amiss. This is generally a point to ask questions, and thoughts on how to program a specific section.

Maze Like Program Flow

If you are constantly searching for functions, and logic, and your program looks like a maze this is probably a point where you should take a step back. This means that either there is some really sloppy code, or there is very high level of systematic complexity. If the complexity does not match the task you are trying to achieve this may a point to step back and take a look at the big picture, and possibly get a different perspective on the situation.

There are many other sets of guidelines, many other people have created. This a small list of warning or "yield" signs that I use regularly. This reflects my general bias for trying to make things as simple as possible, and reducing complexity where ever possible.

Intro to Google App Engine: Displaying Twitter Trends

2009-02-23T08:00:00.000-08:00

My adventure into to Twitter land let me to a point. JavaScript alone wasn't going to cut it. I was going to have to go back to the land of the server. I started investigating different options that were preferably free. I settled upon Google App Engine.

The Google App Engine does lock you down to using Python. I took this as a challenge to delve into Python. The App Engine does not use a traditional relational database, instead it uses BigTable built on Google File System. The App Engine is also scalable, and completely hosted by Google.

This is checklist to get an application running on Google App Engine:

Sign up for an Application (Requires a Google Account)
Download the SDK (Requires Python 2.5)
Create an application using the template provided in SDK
Upload your application to the AppEngine

Some notes on the App Engine programming, you must use python. You are limited to standard Python 2.5. They provide some extensions, and a limited version of Django. You can upload other "pure Python" extensions.

View my simple Python CGI application for displaying the Twitter trends API call.

My view of the App Engine is it is a service that has potential. The service requires you to download the SDK and work for the command line, so if you are not comfortable with this then it probably is not the service for you. I will probably continue to play with the App Engine, becuase it has some real potential, and I want to learn more about working BigTable.

Once the service is more refined it could be a really smooth way to develop highly scalable web service. Look out for this one as a major player in the cloud market if they decide to take it mainstream with other languages beyond Python.

Here is the source code, also this was my first real dive into Python, beyond just toying with the interpreter (I love it!!!1!)

#!/usr/bin/env python


import wsgiref.handlers


from google.appengine.ext import webapp
#url fetching
from google.appengine.api import urlfetch
from datetime import datetime
#use the simplejson library, lucky it was in django
from django.utils import simplejson
import time

#Output the html ick, but it's just a example
output = '<html><head></head><body>'
output += '<h1>Twitter Trends</h1>'
output += '<ul>'

# Make the API call to twitter
url = "http://search.twitter.com/trends.json"
result = urlfetch.fetch(url)

#Status code ok?
if result.status_code == 200:
json = simplejson.loads(result.content)
#Loop through the trends list
for i in json['trends']:
output += '<li>'
output += '<a href="' + i['url'] + '">'
output += i['name']
output += '</a></li>'

#Finish out the request
output += '</ul>'
output += '</body></html>'

#The primary handler, just outputs output
class MainHandler(webapp.RequestHandler):
def get(self):
self.response.out.write(output)


#Defines the calls through the application
def main():
application = webapp.WSGIApplication([('/', MainHandler)],
                                  debug=True)
wsgiref.handlers.CGIHandler().run(application)


if __name__ == '__main__':
main()

Twitter and it's addictive properties

2009-02-18T19:25:00.000-08:00

After signing up for Twitter I think I am starting to at least understand the whole idea behind microblogging. My general theory of the internet still applies though, it's really just a way for people to post small links of pictures of cats.

I think the most interesting thing is the whole openess of their service, and the ability to integrate it with other services. Hint look for this post on Twitter

Creating a simple Twitter AJAX widget using Google Feeds API

2009-02-15T20:32:00.000-08:00

I was doing some research into making API calls to Twitter using JavaScript. The one problem I ran into was calling remote domains. One quick solution I found was to use the Google Feed API. Google provides a really easy and simple interface for accessing feeds via JavaScript.

A quick how to:

To start out you must import the api using your Google API key.

<script src="http://www.google.com/jsapi?key=[Your Google API Key]"></script>

This is script was taking from the Google AJAX API Playground, I just added in the call for Twitter, the full script is below.

First the Google feed object is instantiated with the call to the Twitter API via RSS.

var feed = new google.feeds.Feed("http://twitter.com/statuses/user_timeline/ianlintner.rss");

The Google feed API is great way to access and work with remote feeds, and APIs using just JavaScript. This also an asynchronous call, so it should play well with other AJAX solutions.

The full listing, with my changes.

<!--
Copyright (c) 2008 Google Inc.

You are free to copy and use this sample.
License can be found here: http://code.google.com/apis/ajaxsearch/faq/#license
-->

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8"/>
<title>Google AJAX Search API Sample</title>
<script src="http://www.google.com/jsapi?key=[Google Key]"></script>
<script type="text/javascript">
/*
*  How to load a feed via the Feeds API.
*/

google.load("feeds", "1");

// Our callback function, for when a feed is loaded.
function feedLoaded(result) {
  if (!result.error) {
    // Grab the container we will put the results into
    var container = document.getElementById("content");
    container.innerHTML = '';

    // Loop through the feeds, putting the titles onto the page.
    // Check out the result object for a list of properties returned in each entry.
    // http://code.google.com/apis/ajaxfeeds/documentation/reference.html#JSON
    for (var i = 0; i < result.feed.entries.length; i++) {
      var entry = result.feed.entries[i];
      var div = document.createElement("div");
      div.appendChild(document.createTextNode(entry.title));
      container.appendChild(div);
    }
  }
}

function OnLoad() {
  // Create a feed instance that will grab twitter
  var feed = new google.feeds.Feed("http://twitter.com/statuses/user_timeline/ianlintner.rss");

  // Calling load sends the request off.  It requires a callback function.
  feed.load(feedLoaded);
}

google.setOnLoadCallback(OnLoad);
</script>
</head>
<body style="font-family: Arial;border: 0 none;">
<div id="content">Loading...</div>
</body>
</html>

Defensive Coding

2009-01-25T20:02:00.000-08:00

Inputs, and Data

Defensive coding produces code that accepts the fact that, inputs are going to be invalid, other code is probably not going to work right, and the data is bad. In other words real world coding. Sometimes as programmers we get caught in our own little bubbles where data is perfect, and nothing ever returns a null, but that is a pipe dream. In the real world things change, and people make mistakes, and coding defensively is way to deal with this fact.

To code defensively you must understand the following:

Don't make assumptions
You can't control user input.
You can't trust the data.
You can't trust other code.
The requirements will change.
It always takes longer than you thought.
You can do it right now, or do it right again later.

Defensively coding is necessary when confidence levels in technical, or other aspects of software project are low. Defensive coding is not a solution, but a compensenatory technique for producing high quality code when coditions do not foster it. Some people might say that defensive coding smells, and it's not ideal, but I believe it to be acceptable when rewriting a project, or reworking other aspects of the project are not a viable option.

Examples of defensive coding using VB.NET

Example 1. Null check from a database call.

Dim myDbObject as DbObject

Dim myValue as string

myDbObject = DbLayer.GetDbObject()

If myDbObject IsNot Nothing then

myValue = myDbObject.Property

End If

Example 2. Checking input data

Public Sub GetInput(ByVal Input as DateTime)

If Input > DateTime.MinValue AndAlso Input <>

DbLayer.SaveDate(Input)

Else

DbLayer.SaveDate(DateTime.MinValue)

End If

End Sub

In example one, the basic premise is that we define our variable rather than just using the object value straight from the database, and check if it's null before using it. This is basic common sense, but this pattern can be extrapolated out, and inplementing these checks will never serve you wrong. In the second example before passing data back to the database we check to see if the date values are within range. This is a basic check, but it is likely to cause errors when dealing with date inputs. It is always a good idea to use a basic check to see if your data is at least in a general range. It will save you headaches later.

These were very rudimentary examples, but this is the fundamental of coding defensively. This all can be distilled down to the idea that you can only control data once it is inside of your application, and everthing else will probably be corrupt, invalid, or buggy at some point, so deal with it.

To be continued

On the Value of Application Documentation

2009-01-07T04:51:00.000-08:00

Documentation is not something that comes naturally to programmers, we are more concerned about creating, problem solving, and of course developing software. I came upon a personal revelation: document important items, and taking notes make you a better developer. I advocate documenting, only what's important for you, what's important for other team members, and what would be important for some one inheriting the project.

My personal preference is for using a wiki rather than some sort of specialized documentation. A wiki can be shared, community editable, and open enough it can support almost any teams needs. The disclaimer is Personally I think wikis are about the best thing since sliced bread.

Once you choose a documentation implementation, whether it be a wiki, text file, or other solution. You have to start using it. Starting documentation is generally an easy affair. You go through the application you are working on, document things like servers ips, logins, connection strings, deployment processes, how tos, faqs, and general notes. This is your bare bones documentation.

The hard part of documentation is to keep it going. Keep a log of important meetings, decisions and events that occur, this allows you to go back 3 weeks later and look up what color the save button should be, or who should receive the emails from the contact us form. Keeping a historical log will also let you go back, and review the painful parts, and the successes. A fun benefit is you can go back and see why something was done, and blame it on that person.

Keeping updated notes and documentation on any software project can only help a project be successful, but if you don't have the documentation and you do need it you can be up a creek. To put it in geeky terms it is a pseudo pascals wager.

Documentation is worth the effort, because the process of keeping notes makes you more aware of the ins and outs of the project, and by keeping a project document it helps you truly understand a project, and how all the pieces work together. Personally I have found keeping documentation a great boon, and I can only recommend it.

The Importance of the Contact Us Page

2008-12-24T10:31:00.000-08:00

The ubiquitous contact us form. This was my introduction to web development, and something that is a part of almost every single web application. Developing a contact us form is a task almost every web developer has had to tackle. The contact us form is so common, because it embodies the fundamental purpose of the web: Communication. One question I ask myself is "Why are contact us forms so different?", I think this is because many companies, and organization want to customize the communication experience. A custom contact us form reflects who the organization is, and how they communicate.

To delve into the idea further, you can ascertain a lot of knowledge based on the presence or absence of a contact us forms, how you navigate to the form, and what it looks like. The contact us form can also communicate information such as organizational structure, culture, titles, naming conventions, and company jargon. Many times the form is going to emulate communicating with company over the phone, or in person.

If we look into the history of sending emails via web pages. Many times in the earlier days of the web many companies would just post a mailing address, and maybe a phone number if anything. Then this graduated to maybe including an email link, and if the webmaster knew enough the email address would be hot linked with the mailto: attribute. The whole evolution finally it all culminated with the modern contact us form where users would just enter a message, and were able to submit the form directly from the companies web page.

The modern contact us form comes in many varities, but still do the same thing as the original contact us forms. Custom things you will see is fields custom to products or services a company offers, custom geographical or census type information, or areas to select which person or department receives the email.

AT&T Complex Contact Us Navigation
When desiging a contact us form the developer must first understand the organization that they are working with. The need to understand what information they require, how they communicate, who does the communicating.

Some organizations want the users to be able send an email directly to certain individuals, and some want all communication to be funneled through one location and be dissemenated through the chain. Many organizations like to divide communication into functional areas such as sales, support, marketing, and employment. Some organizations prioritize the contact us section of their sites, while others it is an after thought. Whatever the organization style they probably have opinions on how it should be done.

The contact us form may seem like a simple endevour, but many times buisness requirements may conflict with good design, and functionality. The form may have 20 fields, and the requirements state that every field is required, my guess is many times this form will be abandoned, or on the other end of the spectrum requiring to little information may lead to messages that say "I am interested in buying" and no contact information. Make the contact form to difficult to find, and you will never get any messages at all.

The contact us form is integral part of many company websites. Understanding how a company works, and how it communicates will lead to many cues on how to design a contact us form. The contact us form is just as important as designing how a company handles standard communication. If the user has a bad experience communicating with a company electronically, it can be just as bad as having a bad experience on the phone, and a good experience ensures there are no roadblocks between you and your users.

--

Links

For Contact Form Design Ideas
Smashing Magazine Web Form Design

Bored? Try and find the contact us forms above at:

Ma Bell (AT&T) Website

Apple's Website

Basecamp's Website

Subversion Desktop Widget

2008-11-24T15:24:00.001-08:00

I learned about the Serious Samurize desktop customizer from Lifehacker. I started using it, and it made me started wondering: what technical information would be useful displayed on my desktop. Subversion (SVN) logs was the first thing that popped into my mind.

Serious Samurize Desktop Example

This was pretty straightforward to implement in Samurize.
1. Open your Samurize Config Editor.

Serious Samurize Config

2. Add a new meter, and select console meter (tutorial)
3. In the meter config tool bar on the right, select the source tab.
4. This requires the SVN command line application application installed (available here)
5. Enter the source to be this command:

svn log https://nant.svn.sourceforge.net/svnroot/nant -l 10

This is an example URL from Nhibernate’s SVN Repository
Note: You may need provide a path to the svn command.

view of the widget

This will return the last ten entries as a command line entries as a Samurize meter.
Simple way create a cool little desktop control displaying information that is relevant to a developer.

Quick Links:

Serious Samurize
http://www.samurize.com

Lifehacker
http://lifehacker.com/

Subversion
http://subversion.tigris.org

Creative Process

2008-11-24T09:16:00.000-08:00

This is a video that sounds dirty, but isn't: The meat cannon of Philladelphia. I saw this posted on BoingBoing Gadgets.

I thought this was good look into the creative process, problem solving, and flying meat.

Don't Let Your Quality Slip

2008-11-03T19:29:00.000-08:00

Lately I have been watching Kitchen Nightmares on Hulu. Being a cooking enthusiast I get into the show. Chef Ramsay always keeps saying to the chefs and restaurateurs don't let your quality slip. He would show them how to make a new menu of high quality dishes. The night would start out well, as the orders came in. Then orders would start to build up, and the kitchen staff always, let the quality slip to get the orders out on time. People would then leave, because of the bad food.

The problem is the kitchen staff sacrificed quality to get the orders out faster. The strategy that values speed over quality may win in the short term, but lose the war. Software development is full of stories of making a hack to hit a deadline. This is part of the culture that values working fast, over working right.

Fighting for qaulity can be very difficult, because no one in their right mind would ever say "I am against producing quality software." The best way to make the case for quality is to lead by example. Quality software will speak for itself, just like quality food speaks for itself. If the food is really great, you may pay a little more, and wait a little longer, but it is worth it.

You Can't Teach Perspective

2008-10-10T04:19:00.000-07:00

Perspective (from Latin perspicere, to see through)
-Wikipedia

Perspective is one of those talents that some programmers have innately. Experience may hone this ability. Perspective is a huge part of designing software. It is being able to see what the users want, not, what they say they want. There are some people who just get it right.

If the designers of a system do not have the proper perspective you will find many symptoms. Example of this is when working on an application, and you find levels, and levels of detail when only very little of the system is actually used. Too much detail just reeks of over engineering, and you can just hear the developers wheels turning as they try to flush out every edge case. This is a very dangerous pit, and as developers we must be vary wary of this.

Many other symptoms of lack of perspective exist. Another common symptom is a very slow system that appear very simple on the outside. Usually this means that either too much planning went into the back end, or very little attention was paid to performance. On the other hand a system with inconsistent screens, poor usability you, but it performs well, usually means that designing the logic was the important part of the project, and the UI was an after thought.

All of these are symptoms are caused by lack of perspective, the proverbial forest for the trees. If you do not see applications as a whole, that are used by users, you will get lost and end up fighting the wrong battles. You end with over engineered software, or over engineered sections of software, you design the system how you would like it rather than what is needed. This is just one of the reasons software development and I.T. can get a bad name.

There is a light at the end of the tunnel every one has a little bit of perspective, and intuition, it is just harder to tap into. If you find yourself in the middle of development, and things are going badly. Take a step back, ask yourself some questions. The questions that works for me is the person getting the software going to love it? If they are going to complain about speed, ease of use, complexity, the you've done something wrong. Users want what you want, they want to be able to do their job and not worry about their tools.

My final caveat on this is: All software is used by users, even if indirectly.

HTTP Fox

2008-09-29T08:35:00.000-07:00

HTTP Fox is a pretty neat firefox extension. It allows you get the details of the http transaction with the web server. Some of it overlaps the functionality of firebug. The extension is fast and provides some nitty gritty details that are sorely necessary when debugging web applications.

It provides a detailed view of the headers, querystring, cookies, post data, and the content. It also provides the trace functionality, so you can see a detailed view of all the requests made to get the content on a page. The elevator evaluation is that it is a cool tool which will come in handy when you most need it.

Download HTTP Fox

The Change Paradigm

2008-09-16T08:41:00.000-07:00

Every system will experience some change, whether by choice, or by accident. Every organization needs change, or they risk becoming irrelevant. As stated in the previous article. Change produces inefficiencies, so how do we manage change, within our code, our projects and our organizations.

We try to plan for change, and create rules, procedures, and standards to manage the chaotic nature of change. Try to reduce the number of unknown variables. Creating standards for adjusting to change. This comes from the idea change is not predictable, but reactions can be.

Creating procedures for making changes is a key point to being a succesful programmer. If you know when to make changes, and how to make changes. You will be one step ahead of other programmers. If you know how and when to make the switch to a new set of tools. The risk of being stuck with a unruly beta can be avoided. On the other hand if you wait to long you end up using obsolete technology.

Having policies in place help keep you moving, or keep you from getting cut by the razors edge. If you can find the sweet spot in making changes, you minimize the loss of efficiencies, by the benefits made from making the change.

Part III Dinosaurs and Lemmings

Change is the Enemy of Efficency

2008-09-15T12:06:00.001-07:00

Creating a disciplined development process, and environment when change is present is very difficult. If a new technique, technology, developer, requirement, etc is introduced into a project the project's efficiency will suffer. If speed and efficiency are goals of the project, than the project must be very rigid. Change has very LARGE impact on a project.

I have seen many times that a project I had worked on in the past trending towards a big success, on time, under budget, etc. Then only to have an element of change introduced to the system... *WHAMO* the project momentum is changed and things start to slip drastically. Depending on the amount of change this can push a project from success to failure.

This not only applies to projects, it can be abstracted to larger view, such as teams, and companies. Many people and groups profess the ability to handle change, but they never talk about the costs associated with it. If a group or project is under constant change, true efficencies can never be realized.

To be continued with Part 2 The Change Paradigm

Stack Overflow

2008-09-15T09:20:00.000-07:00

I am playing with a new programming question and social answer service called stack overflow.

Here is a question I submitted, and I am going to rely on wisdom of the crowd:

What is the downside of test driven development.

My Question Feed

BASIC

2008-09-08T11:08:00.000-07:00

marriedtothesea.com

Ubiquity

2008-09-04T07:19:00.000-07:00

Mozilla Labs released a new extension for Firefox called Ubiquity. Ubiquity is part graphical command line interface, part menu extension. Since it is an Firefox add-in it becomes a awesome part of the browser environment. The interface is mostly based on "verbs" that are generally related to a specific web application. Such as map, is part of google maps, and weather goes to weather underground.

Download Ubiquity Here

Ubiquity Commands are very simple, if I want to find "Des Moines, IA" in google maps. I access the command line interface by clicking ctrl-space (from windows). Once the interface comes up and type: "map Des Moines, IA".

Ubiquity could be a really useful tool, it is still in the new toy phase for me. I am enjoying just playing with it. I see many possibilities for customizing it with new verbs to create really useful and efficient workflows. Yet another reason to love Firefox.

Subversion: a Disciplined Development Strategy

2008-08-13T08:04:00.000-07:00

Version control is a really important tool that I use every day. It is not only is a great tool for storing and keeping track of code. It can make you a efficient developer by forcing you to think about your what changes you are making to your code, because once we think about what we are doing it makes us more focused on the task at hand.

This strategy is different than many other "development" strategies, because it never defines what you develop, how you develop, or even how you manage a project. The only focus of this strategy is committing atomic changes, and logging those changes in the commit comments properly, and finally only commit code that builds. Using version control in this fashion produces a usable change log that can be used to track progress between revisions.

The outline of the strategy is:

Commit only one change a time.
Commit only working code.
Comment your changes effectively.

Commit only one change a time. We should only commit one atomic feature, fix, update at a time. If you have 12 bug fixes in the queue, every bug fix should be a commit. If you have a new feature such as a new management screen, it would need to be broken in to it's basic parts. New data access code, updated business logic, new ui screen, new ui code, etc.

Commit only working code. This is a no brainier, commit only code that builds, and does not error when you go to it. If you need to commit code that breaks, comment it out. If it's such a major change it will break the build, then you need to branch. This keeps the integrity of build, and the project's trunk intact.

Comment your changes effectively. Commit log comments are not useful unless they communicate something quicker, and more effective than looking at the file log. I should be able to look at the commit log, and see what sections were touched in less than 15 words. In earlier posts I outlined a strategy for useable subversion comments, so I won't digress.

Using this strategy has made me a more effective developer, by addressing some of my weaknesses. If you are not thinking about source control in terms of development strategy you may be under utilizing the the tool. Instead of searching for the next new tool, we should look at what we already have, and how to use those more efficiently.

Killer NAnt Scripting Template

2008-08-12T12:02:00.000-07:00

I created a NAnt template for developing NAnt scripts. This template includes global variables, comments, different targets based on the deployment, job, action structure that I have talked about previously.

I have provided the entire text file listed below, and also a zip file with the template in a NAnt .build file for download.

Download
Template

Template code:

<project name="Killer.NAnt.Template" default="Deploy.Target" basedir="." >
<!-- Ian Lintner -->
<!-- www.dotcodedump.com -->

  <!-- GLOBALS SECTION -->
  <property name="Global.Debug" value="false" />  
  <property name="Global.Project" value="[Project Name]" />
  <property name="Global.Email.From" value="[Email Address]" />
  <property name="Global.Email.To" value="[Email Address]" />
  <property name="Global.Email.Server" value="[Email Server]" />

  <!-- DEPLOYMENT SECTION -->

  <target name="Deploy.Target" description="A generic deployment target" >
      <echo message="**************************************************************" />
      <echo message="* === Begin Deploy Target 1 ===" />
      <echo message="**************************************************************" />
      <echo message="* Time: ${datetime::now()}" />
      <echo message="**************************************************************" />

      <!--Put Deploy Specific Varaibles Here-->

      <!-- Put Jobs Here -->
      <call target="Job.One" />

      <echo message=""/>
      <echo message=""/>
      <echo message="**************************************************************" />
      <echo message="* === End Deploy Target 1 ===" />
      <echo message="**************************************************************" />
      <echo message="* Time: ${datetime::now()}" />
      <echo message="**************************************************************" />
  </target>

  <!-- JOB SECTION -->

  <target name="Job.One" >
      <echo message="**************************************************************" />
      <echo message="* -== Begin Task One==-" />
      <echo message="* Time: ${datetime::now()}" />
      <echo message="**************************************************************" />
    
      <!--Put Job Specific Variables Here-->
    
      <!-- Put Actions Here -->
      <call target="Action.One" />
      <call target="Action.Two" />
    
      <echo message=""/>
      <echo message=""/>
      <echo message="**************************************************************" />
      <echo message="* -== End Task One==- " />
      <echo message="* Time: ${datetime::now()}" />
      <echo message="**************************************************************" />
  </target>

  <!-- ACTION SECTION -->

  <target name="Action.One" >
      <echo message="**************************************************************" />
      <echo message="* Begin Action One: ${datetime::now()}" />
      <echo message="**************************************************************" />

      <!-- put tasks here -->
      <echo message="   *** Task One ***"/>

      <echo message="**************************************************************" />
      <echo message="* End Action One: ${datetime::now()}" />
      <echo message="**************************************************************" />
    
  </target>

  <target name="Action.Two" >
      <echo message="**************************************************************" />
      <echo message="* Begin Action Two: ${datetime::now()}" />
      <echo message="**************************************************************" />

    
      <!-- put tasks here -->
      <echo message="   *** Task Two ***"/>

      <echo message="**************************************************************" />
      <echo message="* End Action Two: ${datetime::now()}" />
      <echo message="**************************************************************" />
  </target>

</project>

View All of the Killer Nant Scripting Articles

EFF Coder's Rights

2008-08-06T11:50:00.001-07:00

The Electronic Frontier Foundation has started a new campaign aimed at protecting programmer's rights. The two main efforts of the program are "Reverse Engineering" and "Vulnerability Reporting".

From the EFF Press Release

"Coders who explore technology through innovation and research play a vital role in developing and securing the software and hardware we use everyday. Yet this important work can be stymied by bogus legal threats," said EFF Civil Liberties Director Jennifer Granick, who is heading up the project. "EFF's Coders' Rights Project will provide a front-line defense for coders facing legal challenges for legitimate research activities."

Campaign Website: http://eff.org/coders