Ten must-have tools every developer should download

Here’s an excellent article by James Avery discussing the must-have tools every developer should have in their toolbox arsenal.  Just to summarize:

  • NUnit to write unit tests
  • NDoc to create code documentation
  • NAnt to build your solutions
  • CodeSmith to generate code
  • FxCop to police your code
  • Snippet Compiler to compile small bits of code
  • Two different switcher tools, the ASP.NET Version Switcher and the Visual Studio .NET Project Converter
  • Regulator to build regular expressions
  • .NET Reflector to examine assemblies


Top 10 Development Mistakes

I found this list in the Redmond Developer News newsletter, and believe it’s worth mentioning/posting here…because as we all know, there are far too many software development projects that end in abject failure (whether a simple internal app or a massive commercial system).

Here are the top 10 that made the list:

1.  Never committing to project success (that is, the target user

community needs to be on board with the application).

2.  Freezing the schedule and budget before the project is understood

well enough.

3.  Overscoping the solution.

4.  Circumventing the app dev organization altogether.

5.  Underestimating the complexity of the problem.

6.  Being stingy with subject-matter experts (SMEs).

7.  Choosing the wrong project leadership.

8.  Distrusting the managers to whom tasks have been delegated.

9.  Jumping into the “D” of “R&D” without enough “R.”

10.  Suppressing bad news.

Ajax applications with PHP

It’s about time that the open source community take on Ajax.  Check out xajax.

Ajax, or AJAX, is a web development technique used for creating interactive web applications. The intent is to make web pages feel more responsive by exchanging small amounts of data with the server behind the scenes, so that the entire web page does not have to be reloaded each time the user requests a change. This is intended to increase the web page’s interactivity, speed, functionality, and usability.

Your personal regex coach and more

If you’ve worked on text parsing projects – or an app that needed it – then you know what regular expressions are. It truly has been a lifesaver for me on many, many occassions. If, however, you haven’t dealt with it before, here’s some background on it:

According to Wikipedia, in computing, a regular expression is a string that is used to describe or match a set of strings, according to certain syntax rules.

For example, to capture the word Perl in the text below, you would use the following expression: .*(Perl).

Regular expressions are used by many text editors and utilities to search and manipulate bodies of text based on certain patterns. Many programming languages support regular expressions for string manipulation. For example, Perl and Tcl have a powerful regular expression engine built directly into their syntax.

How does it work?

  • . (dot) means match anything
  • * (asterisk) means match the previous character 0 or more times
  • (Perl) (open & close parenthesis) mean capture whatever’s in it

A tool that I personally use to learn, construct, and test regular expressions is called: The Regex Coach. This tool offers many views to show how the regex engine parses text, which garners you knowledge on how it works internally, so you can write more advanced expressions.

Here’s what the tool looks like:

The Regex Coach

To end this post, I highly recommend reading Master Regular Expressions by Jeffrey E. F. Freidl to learn how/when to use it and the text-processing power it offers. This book, in my opinion, reads like a novel and is the best book on regular expressions.Take care! =0)

Get a finalized spec as much as possible

If you develop software or web apps, you’ve most likely experienced working off of an incomplete spec.  I have, and it’s tremendously frustrating when all the work you’ve developed so far needs to be changed all of sudden because you followed the spec!

So here are some points to keep in my mind and push for before you start any kind of development:

  1. Make it clear to your client, whether it be an internal department or actual client, that you won’t be able to work on the project unless a finalized spec is delivered to you.  If they can’t give you one, wear the project manager hat and obtain it yourself by way of interviewing, document gathering, etc.
  2. If you have a spec and see any TBDs in the spec, write down questions that will assist your client help you finalize that portion of the spec.
  3. If the TBDs in the spec can’t be finalized or answered, i.e., the client doesn’t know what he/she wants, build a mock up or shell to show him/her, as it might help the client envision what he/she needs and most likely give you the answer you need.
  4. Give and allocate yourself enough development time for you to complete the project.  I personally add at least a week, on top of the time I believe I can complete it.  This way I have time to resolve bugs or unforseen issues, and…if I complete it earlier, then I look good.  =0)
  5. Most importantly, set the expectations of your customer – especially with regard to item #4.  Let them know what the end product will look like, functions it will provide, etc.  This is why building a mock up or showing the client a reference early in the development process is important.

There will be times where some – or maybe all – of these points may not apply, but try to push for them anyway.

Thanks to a good friend of mine, Dave Mercer, for making this weigh heavily in my mind!

Take care.