Shane Duffy

Archive for the ‘Development’ Category

After getting a CurrentCost energy monitor a week ago I decided it was time to get some useful data out of it. I have 3 phase power so I wanted a tool which would create graphs for each of the phases along with combined total data. The solution to my problems would have to be custom coded and I also wanted an application which could be used cross platform as I regularly use both Windows and OSX.

My choice was to use Adobe Flex as it can provide some nice looking graphs and I have been meaning to do more work using the Flex in flash player or using Adobe Air technology to create a desktop application.

CurrentCost Application

CurrentCost Application

Im creating an application which I can give back to the community which have been developing applications already for the CurrentCost meter. So I decided to use a very simple architecture for this first demo application which uses a simple client server model.

At some stage most of us have needed to work on our websites and move things around, For most people would do this live on the website and this does not make for a great experience for your customers and clients who end up visiting broken and half finished pages. Or even worse the search engine crawlers that come along and find sample text on your pages.

One of the neat tricks of a .htaccess file is been able to enable a maintenance page for all your visitors to your website but still been able to access the website yourself for testing and development.

RewriteEngine On
RewriteBase /
RewriteCond %{REMOTE_HOST} !^86\.43\.107\.123
RewriteCond %{REMOTE_HOST} !^86\.43\.107\.201
RewriteCond %{REQUEST_URI} !/maintenance\.html$
RewriteRule .* /maintenance.html [R=302,L]

The above when placed in a .htaccess file will redirect all clients who are not coming from 86.43.107.123
or 86.43.107.201 to the maintenance.html webpage

Simple yet very handy to have!

Im working on a project now and using subversion a lot for the project. One of the things that has been annoying me in the last while is sometimes I want to move code into another svn repository while working on it, and really the only way to do it is to remove all the .svn directories check out the top level empty directory of the repository I want to place the code into and then do svn add *

The only problem been that removing all the .svn files can be a real pain on large projects.

find . -type d -name ‘.svn’ -print0 | xargs –0 rm -rdf

Is a very handy command that I now use all the time. What this does is find all the .svn directories and removes everything below them, leaving me free to add the code back into another subversion repository.

Update: This is also very handy way of reducing the transfer size if using SCP to move your code between servers. As when working on SVN subversions files the .SVN directories can double the size of your code on disk as they store copies of the files in the .svn folders for later comparison

The Microsoft Enterprise Library has a really good Logging Application Block that allows you to make your logging infrastructure configurable.

This framework makes logging as easy as typing:

Logger.Write(“System rolled over!”);

the framework is configurable from your config file.

The Microsoft Enterprise Library out of the box provides the following destinations for logging messages:

  • Email
  • Custom Locations
  • Message Queues
  • WMI Events
  • Database
  • Text Files
  • File

I took our web site and our main global error handler and did a dump routine of all exceptions to the log and it worked great. But the question arose – where should we log? Here are some of our ideas that spring to mind on this issue.

  • The least error prone seems to be the flat file. The custom location seems the worst option simply we would hope that our proprietary code is less tested in less real world scenarios than Microsoft’s Enterprise Library components.
  • The idea of logging to the database is attractive from a reporting perspective, but everyone on the team felt like it was risky given that the most typical scenario for an error in the application itself was a database related error. I suppose if we had the logging database seperate from our application database then this would reduce the risk, but we don’t have the resources for such a move, so if our application were to kill the database it would take down any logging sources there as well.
  • Even with the flat file, it is possible that it will fail. A simple scenario for it failing would that the file is read-only or the ASPNET process doesn’t have permission to access the file. So we need at least two logging mechanisms to provide redundancy. The Enterprise Library allows for this – you can configure more than one listener for every log message being written.
  • Our second challenge with using flat files is that they no provide a notification mechanism like email. So if there is an exception, the file has to be constantly monitored or periodically checked. Therefore, combining an email message and a flat file backing store seemed like a decent combination. If the email fails, then we may not know for a day or two but at least the error will be logged. If the file fails, then at least we’ll get the email.
  • The event log is not a bad option either and its generally easier to monitor as most monitoring tools already handle event log monitoring. The one issue with using the event log that I have found is that if you use an event log source that doesn’t exist the logging will fail without any notification to you. Your error will simply disappear and won’t be logged. You can use any existing EventLog source or create a new one in the registry for your custom logging needs. In addition, you have to make sure that the ASPNET account has permission to write to the event log.

That’s where we are at so far – its not quite bullet-proof yet but its getting there. If you have any further suggestions or thoughts, leave them as a comment!

What the Heck is a Regular Expression Anyway?

I’m sure you are familiar with the use of “wildcard” characters for pattern matching. For example, if you want to find all the Microsoft Word files in a Windows directory, you search for “*.doc“, knowing that the asterisk is interpreted as a wildcard that can match any sequence of characters. Regular expressions are just an elaborate extension of this capability.

In writing programs or web pages that manipulate text, it is frequently necessary to locate strings that match complex patterns. Regular expressions were invented to describe such patterns. Thus, a regular expression is just a shorthand code for a pattern. For example, the pattern “\w+” is a concise way to say “match any non-null strings of alphanumeric characters”. The .NET framework provides a powerful class library that makes it easy to include regular expressions in your applications. With this library, you can readily search and replace text, decode complex headers, parse languages, or validate text.

Some Simple Examples

Searching for Elvis

Suppose you spend all your free time scanning documents looking for evidence that Elvis is still alive. You could search with the following regular expression:

1. elvis Find elvis

This is a perfectly valid regular expression that searches for an exact sequence of characters. In .NET, you can easily set options to ignore the case of characters, so this expression will match “Elvis”, “ELVIS”, or “eLvIs”. Unfortunately, it will also match the last five letters of the word “pelvis”. We can improve the expression as follows:

2. \belvis\b Find elvis as a whole word

Now things are getting a little more interesting. The “\b” is a special code that means, “match the position at the beginning or end of any word”. This expression will only match complete words spelled “elvis” with any combination of lower case or capital letters.

Suppose you want to find all lines in which the word “elvis” is followed by the word “alive.” The period or dot “.” is a special code that matches any character other than a newline. The asterisk “*” means repeat the previous term as many times as necessary to guarantee a match. Thus, “.*” means “match any number of characters other than newline”. It is now a simple matter to build an expression that means “search for the word ‘elvis’ followed on the same line by the word ‘alive’.”

3. \belvis\b.*\balive\b Find text with “elvis” followed by “alive”

With just a few special characters we are beginning to build powerful regular expressions and they are already becoming hard for we humans to read.

Let’s try another example.

Determining the Validity of Phone Numbers

Suppose your web page collects a customer’s seven-digit phone number and you want to verify that the phone number is in the correct format, “xxx-xxxx”, where each “x” is a digit. The following expression will search through text looking for such a string:

4. \b\d\d\d-\d\d\d\d Find seven-digit phone number

Each “\d” means “match any single digit”. The “-” has no special meaning and is interpreted literally, matching a hyphen. To avoid the annoying repetition, we can use a shorthand notation that means the same thing:

5. \b\d{3}-\d{4} Find seven-digit phone number a better way

The “{3}” following the “\d” means “repeat the preceding character three times”.

Read the rest of this entry »

.NET developers that want to adopt more agile development methodologies, while still towing the line with their project management offices, may soon begin to tap into templates available with Visual Studio 2005 Team System.
Among options available are Microsoft Solutions Framework (MSF) for Agile Software Development, which ships with Visual Studio 2005 Team System, and Scrum for Team System from U.K.-based Conchango.

 The Conchango software is a plug-in and available as a free download.
Among a host of other Scrum products available today are tools from Rally, VersionOne, TargetProcess and others.

Influenced by the tenets of Extreme Programming (XP), MSF for Agile is a hybrid process that is context-based, and includes practices Microsoft itself uses to build software. The template is intended as a starting point, according to Steve Elston, product unit manager.
“The reality is most organizations want to customize their development process almost immediately,” Elston said. MSF for Agile comprises “accepted industry practices around agile and iterative development, combined with what Microsoft has had for a long time, with the Microsoft Solutions Framework.” It’s a mechanism to “get more agile, yet still collect data the project management office needs from above.”

It fits the pattern Elston said is emerging at large enterprises—development teams at the grass roots level adopting agile practices, while the project management office remains responsible for broad oversight.
“More CIOs are interested in hearing about agile,” said Clementino Mendonca, Microsoft Project Planner. “Three or four years ago [they thought] it was scary—[agile] equaled lack of discipline and documentation. MSF Agile, like XP and other agile methodologies, is very disciplined. You use the results you have in the best way possible; you avoid doing stuff that’s not necessary. [And] it makes it easier for higher-ups to get the reporting information they need, while giving freedom to the team to self-organize.”

The need to capture project data information has been one barrier for companies trying to adopt agile methodologies, Mendonca said. With MSF for Agile and Visual Studio Team System, “data capture is not something you have to think about, but it’s done under covers by the tool.”

In addition to the agile template, Visual Studio Team System also includes MSF for CMMI Process Improvement for organizations that prefer a more formal process. Both processes are customizable, and Visual Studio Team System provides a methodology template to enact the processes. This methodology template contains work items, security settings, process guidance, process reports, source check-in policies, Microsoft Project templates, document templates, and a project portal/Windows SharePoint Services site template configured to support the MSF processes, according to the company.
Visual Studio developers who prefer the Scrum methodology can download Scrum for Team System from Conchango, which was developed in collaboration with Scrum co-creator Ken Schwaber and the Microsoft Technology Centre in the U.K.
Conchango started to conceive Scrum for Team System when Microsoft was building Visual Studio 2005 Team Foundation Server. “The idea is people make their own methodology and stick it in, which I thought was a great idea. Now you can use Scrum out of the box,” said Colin Bird, chief technology officer at Conchango.

Conchango recently released version 1.2, and Bird said there have been more than 4,000 downloads. He said the company will likely look to roll out a commercial enterprise version.

“We’re not a product company, but we thought it was a good idea to build it anyway and consume it internally; the Scrum world is very collaborative so we thought we’d do our bit for it. But we are looking at where agile is going, and it’s getting bigger and being used on far bigger projects, so I suspect we will come out with enterprise version as a costed option.”

Microsoft, too, plans added features for both the agile and CMMI templates going forward, Elston said. “We’re very aware there are a number of features to support agile, like continuous integration, which is a key agile practice, and we know we don’t have great support for that.” The next generation of the template should provide that, he said. Other agile practices under consideration for future support are test-driven development, refactoring and iteration planning, he said.
As agile practices such as these have become more accepted, agile practitioners are no longer considered to be “renegades,” said Bird. “I’ve seen it change dramatically over three and a half years. When we started we were definitely renegades,” he said. “Most companies said, ‘It wouldn’t work here.’ Over the last few years most people are getting their minds around agile. There’s a certain cynicism you encounter, but most organizations need to improve the way they develop software. There’s also the [move to be] agile as an organization.”

Introduction

The purpose of this article is to define a set of ideal practices for an agile software development project. I encourage you to leave comments about this article using the comments box at the bottom of this page. Please note that the practices listed are the practices that I believe are essential to a good agile development project; they do not necessarily have anything to do with being agile. I have tried to list the practices in descending order of importance.

Practice 1: Aggressive refactoring

In my opinion, refactoring is the most overlooked skill for a software developer. A well refactored application has a much higher value to the project sponsor than a poorly refactored application. The most common sign of code in need of refactoring is excessively long methods. I try to keep methods to less than 100 lines. Other common code smells are misleading or meaningless variable names, and code duplication. Static code analysis tools, such as FxCop, can provide a useful measure of code quality.

Practice 2: Testing

Firstly, there should be some developer testing. All the code that is written should be testable and should have tests written for it. It is acceptable to modify your program to facilitate good testing. I believe that the traditional testing terms; unit tests, integration tests and system tests have become outdated. Instead, I prefer the terms developer tests, functional tests and non-functional tests. Non-functional tests are things like performance testing, functional tests are tests that the customer cares about like use case tests or business transaction tests, and developer tests are everything else that the developer needs to test to prove to herself that the code is correct.

We should automate as much testing as possible and run it as part of continuous integration. If code coverage analysis is included in the automated testing it provides a nice indication of the health of the system at any point of time.

Practice 3: Automated build and deployment

The project should have an automated build, an automated deployment and ideally automated testing. In the optimal situation, a developer can click a button and the build process will build the latest source, deploy, test and report on the result. Automating these processes not only saves time but also eliminates a huge number of bugs and time wasters.

Practice 4: Continuous integration

If a project has automated build, deployment and testing then continuous integration is really just a matter of automating the kick-off of that build, deploy test cycle. Every checkin should result in a new build and test, on a separate build server. The results of this should be reported to every team member and it should be an established team practice to immediately fix the build. A working build should be everyone’s top priority. People should not be made to feel bad if they break the build, as this decreases their courage.

Practice 5: Source control

A source control system should be used to store all project artifacts including: code, non-code documentation, build scripts, database schema and data scripts, and tests. The code should not be checked into the build until it compiles and passes its tests.

Practice 6: Communication plan

There should be a defined, direct communication channel between the developers and the customers. This can be (best to worst): on demand face-to-face communication, daily or weekly face-face communication, contact phone numbers, instant messaging, email mailing list, intermediary (BA or PM). These communication channels can and should be combined.

Practice 7: Task tracking

There should be a defined technique for recording and prioritizing development tasks and bugs. The system should make it possible to assign responsibility for tasks to individuals. If tasks are tracked against estimates then the estimate should be performed by the person who will do the task.

Practice 8: Self documenting code

Code comments should be subjected to the same quality requirements as the code itself. Everything possible should be done to ensure that no other technical documentation is required. When non-code technical documentation is required it should be subject to the following restrictions: referenced from the code, always up-to-date (change when the code changes), only one version per baseline, stored in source control.

Practice 9: Peer review

There must be some form of peer review, such as code review of fellow programmers. If the developers are subjected to performance reviews then the peer reviews they do should be an input to that process. This helps to avoid the temptation to approve everything to avoid confrontation. Make sure that the reviews are for quality, not just for correctness.

Practice 10: Work-in-progress

A working version of the latest iteration should always be available for customer feedback. The advantage of this is that customers see very quickly when something has been developed contrary to what they had in mind. Shortening this feedback loop decreases the cost of change.

Practice 11: Feedback mechanism

There should be a defined mechanism for project team members, including the customer, to provide feedback on the project’s processes. My suggestion is to hold a short meeting at the end of each iteration.

 

Article by

Liam McLennan


Subscribe to this blog now!

Top Clicks

  • None
July 2017
M T W T F S S
« Feb    
 12
3456789
10111213141516
17181920212223
24252627282930
31