Paul Sheriff's Outer Circle Blog

Confused about which Data Access Technology to use?

psheriff — Mon, 18 May 2009 16:54:00 GMT

Well, you are not alone. Even the experts do not agree on which data technology you should use. However, you will find a common theme among each of the panelists in this lively video: The Data Access Menu: Making Intelligent Choices. (http://www.msteched.com/online/view.aspx?tid=fa50fd2a-05f3-41d9-aaa6-110daea9dce2)

Panelists include Rocky Lhotka, Stephen Forte, Paul Sheriff, Jeffrey Palermo, Kent Alstadt and Richard Campbell. Watch as these heavy weights in the industry talk about the various Microsoft Data Access technologies and how you should best approach each one.

This video is only about 35 minutes long, and is a lot of fun to listen to. I sure had a great time doing this panel!

Paul

The Incredible Race Condition

psheriff — Wed, 13 May 2009 04:51:00 GMT

OK all you folks at Tech Ed. Here is my special code for my "Race":

http://tr.im/theregion_2361

You can get more information about the "Race" at http://tr.im/race_condition

Paul

Tech Ed Panel Now Viewable

psheriff — Wed, 13 May 2009 04:42:00 GMT

Hello All,

Are you looking to strike out on your own and create your own software consulting business? If you have ever thought about doing so, you might want to check out this panel entitled: "Let's Talk About Software Consulting as a Business". This panel was presented at Tech Ed on May 11, 2009. You can view this panel at: http://www.msteched.com/online/view.aspx?tid=bb81bae0-320a-4bda-9146-12f0b20a8733.

In this panel are panelists, myself included, that have had many years of experience running a consulting business. You are sure to pick up some wisdom from those of us that have "been there". The topics covered are managing client expectations, fixed price versus time and material and lots of other great tips and tricks.

Hope you enjoy.

Thanks,
Paul

I Love the File/Directory Classes in .NET!

psheriff — Fri, 15 Jun 2007 21:53:00 GMT

I just had a situation where a potential client gave me a zip file of about 200 files. They wanted us to give them an estimate on how long it would take us to recreate each screen in ASP.NET 2.0. I did not relish the thought of typing in all those file names into an Excel spreadsheet so I could assign hours to each one. So I wrote a simple little utility to grab each file in the folder, and add that file name to a StringBuilder object. I separated each file name with a CRLF. Once I had all of the files in the StringBuilder object, I simply copied the text to the Clipboard. Then I opened up Excel and pasted the contents of the Clipboard into an Excel column. Bingo! I now had all those file names into Excel, ready for me to assign hours to!

C# Code
private void GetFiles()
{
System.Text.StringBuilder sb = new System.Text.StringBuilder(1024);
System.IO.FileInfo fil;

foreach (string strFile in System.IO.Directory.GetFiles(@"D:\Customers\ASP"))
{
fil = new System.IO.FileInfo(strFile);
sb.Append(fil.Name.Replace(".asp", "") + Environment.NewLine);
}

Clipboard.SetText(sb.ToString());
}

VB.NET Code
Private Sub GetFiles()
Dim sb As New System.Text.StringBuilder(1024)
Dim fil As System.IO.FileInfo

For Each strFile As String In System.IO.Directory.GetFiles("D:\Customer\ASP")
fil = New System.IO.FileInfo(strFile)
sb.Append(fil.Name.Replace(".asp", "") & Environment.NewLine)
Next

Clipboard.SetText(sb.ToString())
End Sub

I hope this little tip helps you the next time you have to do something like this!

Paul

Code Audits: Not just for beginners!

psheriff — Thu, 03 May 2007 12:51:00 GMT

When is the last time you had one of your peers or an external consultant evaluate your coding? If you have not done this in awhile, you should seriously consider it. While I am sure you are a great programmer, different people have other ideas as well. In the IT business, it is all about learning. If you are not sharing ideas, or talking with others about your coding, then you are probably not learning as much as you could.

Now, I know reading articles and google-ing for code is a great way to learn as well, but everyone can bring fresh ideas to you. Never pass up a chance to "put yourself out there" and ask for some help.

At my company, PDSA, Inc. (www.pdsa.com) we actively encourage (actually, we enforce) code reviews on everyone. In fact, we have developed a set of checklists that we use to do a code review. For our security review, for example, we have over 144 points that we go over. This checklist not only covers code, but also security from an organizational standpoint. Our Application Design review covers about another 100 points and our SQL Server review also covers about 100 items.

I would encourage you to come up with your own checklist that you can use for doing reviews of code, organizational structure, databases and security. If you do not know where to start, you could join my Paul Sheriff's Inner Circle (www.PaulSheriffInnerCircle.com). IT Professional members on my Inner Circle have access to all of my checklists.

Just recently, I performed code and security audits at two separate companies. These were companies that thought they had developed secure, well-written and performant applications. However, they had never had anyone audit their code before. As a result, I wrote a 16 page report for one company and a 20 page report for the other of improvements that could be made in their applications. Just an example of what can be learned by having someone else look at your code. The next steps for these companies will be a training session to talk about the findings in these reports.

I hope this inspires you to come up with your own code review process at your company.

Paul

Watch out for Daylight Savings Time this Sunday!!!

psheriff — Thu, 08 Mar 2007 19:42:00 GMT

There are serious potential problems with the upcoming switch to Daylight Savings Time this Sunday. While MSFT is working on a fix, so far it is not perfect. Check out these entries.

http://support.microsoft.com/gp/cp_dst

http://support.microsoft.com/gp/dst_prodlist

http://support.microsoft.com/kb/933146

The network company we work with, CSI (www.csiteks.com), has discovered the following:

1.) If a client [like Outlook, entourage, palm or windows mobile] gets the update first, there will be a 1 hour disparity.

2.) If the workstation gets the update before the mobile device, it can hose and duplicate appointments!!!

3.) If the user changes his/her clock forward on Tuesday [instead of the system administrator changing the time on the server or applying the patches across all machines] that user will be locked out of Active Directory until someone logs on as a local administrator. This particular scenario we can almost count on as most of our users are local administrators of their machines!

Hopefully MSFT will give us a fix before this Sunday.

Paul

www.pdsa.com

www.PaulSheriffInnerCircle.com

Deborah Kurata's new book is out!

psheriff — Mon, 05 Mar 2007 18:19:00 GMT

Hi All,

Just wanted to let you know that my good friend, Deborah Kurata, has just released the updated version to her popular book "Doing Objects in VB" for VS.NET 2005. Check it out if you get a chance!

Title: Doing Objects in Visual Basic 2005
Author: Deborah Kurata
ISBN: 0321320492
More Info: http://www.insteptech.com/home/books.htm

Paul

Finding Machine.Config

psheriff — Tue, 27 Feb 2007 18:18:00 GMT

OK, this is just a quick little tip. I need to be able to programmatically locate the Machine.Config file. Instead of hard-coding the path where I know it is, I used the new ConfigurationManager class in .NET 2.0 to perform this. Here is the code.

C#
using System.Configuration;

Configuration cnf;

cnf = ConfigurationManager.OpenMachineConfiguration();

MessageBox.Show(cnf.FilePath);

VB.NET
Imports System.Configuration

Dim cnf As Configuration

cnf = ConfigurationManager.OpenMachineConfiguration()

MessageBox.Show(cnf.FilePath)

You will need to add a reference to the System.Configuration.dll to be able to use this, but then you can use File IO or XmlDocument methods to open and affect the Machine.Config.

Hope this helps someone out.

Paul

Are you still writing Add/Edit/Delete code?

psheriff — Fri, 23 Feb 2007 16:25:00 GMT

Recently one of my programmers came to me after having visited with a PDSA client. He told me one of the programmers at this client was creating a new .NET application and had about 5 add, edit, delete screens created. He had spent, on average, about 7 hours creating, testing, debugging and tweaking the code on each screen. He wrote a little over 200 lines of code for each screen and at least 5 stored procedures for each screen as well. Even though he was able to copy and paste a lot of the code from one screen to another, he still had to fully debug and regression test all the add, edit and delete routines on each screen. This was in addition to the business rule logic that he had to test.

So, what is the point of all of this?

Why was this programmer (and maybe you?) not using some sort of code generator and Framework to generate all of this CRUD (Create/Read/Update/Delete) logic? If you are not using a code generator to create add, edit, delete and simple business rule logic for data, in my opinion, you are spending WAY TOO MUCH TIME CODING and NOT ENOUGH TIME SOLVING the business problem.

The problem with hand-written add, edit, delete code can be summed up fairly succinctly:

It may not be standards based (give a CRUD screen to 10 developers and you will most likely get 10 different versions).
It is difficult to reuse for the next application.
When it needs updating, someone will have to search through all those lines of code looking for locations to update. Guess what? They won't find all of them, resulting in high error rates.
This code will be harder to maintain over the life of the application, as new team members replace the original coding team.
It has to be written and re-written any place you need to add, edit, delete the same table, even on different forms.
If you change the table schema, you will need to find all the places where the add, edit, delete code for that table is and modify all those locations. This is a very error prone process.

You can eliminate every one of these consequences if you take advantage of a good Framework and Code Generator.

NOTE: Many frameworks are NOT worth the hassle. Microsoft's Enterprise Library, for example, has so many downsides (no support, high learning curve, bad documentation, no upgrade path, way over-engineered, hard to use just one block by itself), it is used at the peril of any developer.

So which Framework should you use? It depends! I know, not a very good answer, but there are so many different frameworks and code generators out there that it is hard to find a one-size-fits-all. As far as code generators go you can't go wrong with CodeSmith (www.codesmithtools.com). This will help you generate CRUD logic quickly and simply.

As far as Frameworks, some are good and some aren't. What you need to look for are the ones that do not lock you into their way of doing things:

Once a Framework generates code how customizable is it?
Can you inherit from their base classes?
Can you override their methods?
Can you add your own code to the generated code?
Do they separate their business logic from their data access code so you can add on your own business logic and not have it wiped out when your database schema changes and you need to regenerate?

So many questions, and so few answers. You will need to ask these questions before purchasing a Framework.

Many people have asked me what we use here at my consulting company PDSA, Inc. (www.pdsa.com). We built our .NET Framework and Code Generator from scratch! I know, a lot of work, but it was worth it. We now have a process in place that is consistent from developer to developer. We have all CRUD logic generated in literally a few seconds. This includes all stored procedures. The code generated is also 100% bug free! This means we do not need to test any of this code. We only need to test the custom business logic we need for those particular screens that we are coding. This eliminates hours and hours of work. If the table schema changes, we simply regenerate, and since our business logic is separated from the CRUD logic, our custom code is preserved.

So, how does our Framework and Code Generator work? I do a monthly webcast that shows you our Framework. Sign up at www.pdsa.com/webcasts.

Please understand I am not on this blog to promote our stuff. I happen to believe in Frameworks, any Framework, and I believe you owe it to yourself to check out the myriad of Frameworks that are on the market. I have been developing and designing Frameworks since I worked on COBOL on the mainframe. When I was doing Clipper programming I designed a code generator, screen painter, and a process for creating CRUD logic. In VB 3.0 I created a code generator and starting with VB 4.0 I have had a more complete framework. That has then led into our PDSA .NET Productivity Framework that we sell today. So stop writing so much code and focus on the business problem at hand. This will make you a better developer and one that is more demand by employers.

Paul

Check out DNR TV!

psheriff — Wed, 07 Feb 2007 01:11:00 GMT

Last month I recorded an episode of DNR TV on creating custom providers. Carl and I go through a lot of code showing how to create your own custom providers. Enjoy!

http://www.dnrtv.com

Migrating to .NET, simple to do

psheriff — Tue, 06 Feb 2007 16:18:00 GMT

In my travels, I have noticed many companies are sitting on legacy applications that are good candidates to migrate to .NET.

While many of these applications run fine right now, eventually they will become obsolete due to changing business requirements, new operating systems, missing source code, etc. Upgrading to .NET offers significant advantages, but the time to start upgrading these applications is *before* they become obsolete.

Planning for Obsolescence

Planning for the end of an application's life should be a part of your overall IT strategy in your company. Does this mean you lose all the investment you put into this application? Not necessarily. Hopefully the application has provided value to your company. There are plenty of business rules, screen elements and other valuable assets in the existing application that can be leveraged in the migration to .NET.

Starting the Migration Process

One of the first steps in any migration process is to identify which applications should be migrated first. Once you decide on this, you should find any old specifications or requirements documents that describe the old system. If you can not find any, then create new ones. The goal is to create a new document that describes what the new application will do, what its goals are, and what the value proposition (ROI) will be to the company.

The next step is to prototype the screens in the new technology. Either ASP.NET web forms, or maybe Windows Forms. This step should be fairly easy since you have an existing application that you are designing from. However, you might want to the opportunity now to update the look and feel of the application to some of the newer ways people like to view applications.

When you are doing the prototyping, you should look around on the Internet for any tools that might help you migrate the screens and/or code to the newer platform. While the code may not migrate perfectly, it can be a help to identify business rules. We always recommend re-writing code as opposed to using code that is converted, but we need to find all the buried business rules in the existing code.

As you prototype the new application, you should also be updating the specifications and requirements document with any new business rules, fields and additional screens that will be added to the new system.

Using a Framework

Before you begin any serious coding, you should have a Framework in place. As most of you know PDSA is a strong proponent of Frameworks. We believe that if you don't have a Framework in place, you should purchase one (preferably ours!), or create one. A proper Framework is essential to ensuring your application development is done correctly, quickly, efficiently, consistently and ensures a lower Total Cost of Ownership over the life of an application.

If you look at many of your legacy applications you will most likely find the same routines written in each one. Take the time now to find/create a Framework that creates these routines in one DLL and can then just be re-used as you migrate each application.

Write the New Code

Now that you have created the prototype, created a specification document, consulted with the users of the system, convinced management of the ROI of the application, put your Framework into place, you are finally ready to start coding! Now is the time to look at other tools that can help make your job more efficient. For example, are there third-party tools that will make your UI design better, quicker, more efficient, and take you less code to write? Use CodeSmith, or the PDSA DACGen (from the PDSA Framework) code generators to develop the CRUD (create, read, update, delete) logic for your database calls.

The goal of developers today should be to reduce the amount of code you write and to focus on the business rules of the application. How the application manages the business is most important, not how many cool, wiz-bang routines you wrote. Those programmers that write applications to save the company money or reduce costs are the programmers that are most valuable to the company.

Summary

While migrating legacy applications does take time, money and resources, the upsides are tremendous. You will keep your programmers skills up to date, you will get better documentation, you will get a better, more robust system that is able to grow with your business, you will get a chance to put standards and a framework in place that will help with all other applications you migrate and create from scratch.

My company (www.pdsa.com) have done many migrations over the last few years. While it is never a "slam-dunk", once it is complete, the upsides for our clients have been huge. I have posted many samples that can help developers migrate their applications up on my Inner Circle at www.paulsheriffinnercircle.com.

Not Estimating and Tracking your Projects? Expect Failure

psheriff — Sat, 20 Jan 2007 00:24:00 GMT

Estimating software development projects is one of the hardest things to do. First, programmers just don’t like doing it. And why should they? They are usually incorrect and may feel the heat when their estimates slip. Secondly, most programmers just don’t have a method or process by which to develop an estimate. I will lay out some simple steps to follow to help you on your way to actually “loving” to provide estimates. Yes, loving it. Because if you can be right most of the time, wouldn’t you love it too? If you come up with a process for estimating, you will be on your way to being right a large percentage of the time!

If you ask three programmers to give you an estimate for a project, you will have three different answers. Why? Each one used their own backgrounds, experiences, and checklists to derive an estimate. So what do you do? Leverage those experiences in a structured approach and document it. What we did at my company PDSA, Inc. (http://www.pdsa.com/) is develop an estimating model and approach to estimating. We built and defined an estimating process. Remember: you can never improve an estimate if it is in someone’s mind. But if you build an estimating process and document it, you can improve the process and measure the process. Once you have done that, you can begin to build solid and more predictable estimates.

Step 1: Build an estimating model.

What are all the elements to an estimate? Collect your teammates together and brainstorm all the elements of a project. There are many books out in the market, and I am sure your teammates will have some ideas to. Here are some sample elements: logical database design, physical database design, unit testing, integrated testing, prototyping, requirements meetings, coding, etc. You will likely have a list of over a hundred items. Classify them into categories like: requirements, development, testing, customer buyoff, etc.

Step 2: Use the estimating model

Does that sound silly? Why did I just go through all the work in Step 1 only to not use it in Step 2? That is because your customers or upper management will want a quick answer. The problem is that they will remember your quick “answer.” Try and resist. Once you start using your estimating model and you can show how successful you are, they will trust and believe in you. Now that is something new for IT!

Step 3: Track your work

An estimate is only just an estimate unless you have time tracking in place. I don’t mean the kind where I track whether you went to lunch or not, but the kind of tracking that captures for every single task in your estimating model how many actual hours are spent. This is important. You have no idea how good your estimate really is unless you track actuals against it. You must do this and I can’t impress this point upon you more. By understanding your actuals you can refine your estimating model. Refining your model may include changing the number of hours you think a task really takes, or it could be that you forgot several tasks. Now you can add those new tasks back into your model. It is imperative to leverage your lessons learned and improve your model. Better models enable you to better predict project results, which yields in projects coming in on time and your customer’s appreciating it.

Once you have estimated and tracked several projects, you will begin building up a repository of estimating information. Another benefit is that at times a custom may ask for a quick estimate. You don’t have time to do much if any analysis, but they need that magic “number” to put into their budget. You could mine that data to find projects roughly similar to the new project. You could then at least provide a range of estimates based on some very high level project criteria. The estimate certainly is not perfect and should come with the usual disclaimers, but at least you have used real data based on your experience. At PDSA, we have over 9 years of tracked data and it has been extremely valuable in helping our clients in the initial planning and budgeting phase.

Estimating “Rules of thumb”

Estimates must be created using a standard, repeatable process. But when developing your estimating model, your model should produce reasonable estimates. If your model produces estimates that are unreachable, your development team will not work within your process. So your estimates need to be reasonable (within the context of your company, skill sets, leadership, etc.). On the other hand, make sure your estimates are a bit of a stretch. Each person should be challenged and your software development process should be challenged as well. As you challenge your team and processes you will find a wonderful outcome: innovation! You will innovate and discover new or different ways to do things better, faster, and cheaper. It may sound like a cliché, but it works.

Summary

Estimating is an important skill that can be learned and improved. It is not a scientific process unless you let it become one. Accurate and consistent estimating builds customer loyalty and team confidence. Tracking provides real time feedback to not only your team members to see exactly where they are, but also to your customers. In October of 2006, I did a Webcast on Estimating on my Paul Sheriff's Inner Circle (http://www.paulsheriffinnercircle.com/). On January 26, 2007 we are having another Webcast on the Top 10 Best Project Management Practices that will also talk about estimating and time tracking.

5 Things you did not know about me...

psheriff — Wed, 17 Jan 2007 21:11:00 GMT

Thanks to Craig Shoemaker for tagging me on the "Five Things"<g>. So, here we go, here are five things you probably didn't know about me:

1. I grew up in Iowa. I love the Midwest and I try to get back there to see friends whenever I can. I try to speak at the Des Moines, Iowa .NET User Group once a year, since that is where I have a lot of friends. I will be speaking there on March 7, 2007, so if you are in the area, stop by! (www.iowadnug.org)

2. I snow ski. I try to go a few times a year to Mammoth with my friend, and the VP of my company, Michael. I love being out in the fresh air and getting exercise. I am an intermediate skiier. I tried snowboarding once, but I prefer skiing.

3. I play drums in a progressive rock band called Evolve (www.MusicEvolve.com). We are an all-original music band. We have created about 20 songs so far and are working on our first CD which we hope to release in about 1 month. I picked up drums in January of 2004 after not having played for 20 years! Took awhile to get the chops back, but thanks to some good instructors, I am improving all the time. In fact, I am fortunate to have a local guy who is a Gene Krupa impersonator give me some lessons. Check out Randy Caputo if you are interested (www.RandyCaputo.com).

4. I was going to become a theatre major before I discovered computers. While in college I was working in the school theatre doing lighting and stagecraft and we used an old Apple II+ to run the lights for the productions. I really enjoyed playing with the computer, and that is how I decided I liked computers better than theatre. However, to this day, I still love live theatre and go whenever I have a chance.

5. I have an 8 year old daughter named Maddie. She and I are like two peas in a pod. We love roller blading together, and in fact, we go 2 times a week to a local skating rink. We enjoying walking with the dog, going to movies, and just laughing and being together. Being recently divorced has cut down a little of our time together, but we still have some great quality time together.

Hopefully, this gives you a little insight to my life. I hope you find it interesting.

So, if I were to pick on 3 other people, here is who I would like to know more about.

Paul

Use Close and Finally

psheriff — Tue, 16 Jan 2007 20:50:00 GMT

In the last 2 weeks I have had two different clients complain that there are "memory leaks" in .NET. I tell them very politely, that most likely it is their code!<g> In both cases it was their code. The first case had to do with the programmers using a DataReader and not closing them when they were done with them, or they put the Close() method call within their Try block and not in a Finally. The second case involved the StreamWriter in the File.IO namespace where once again the file was not always being closed correctly due to the programmer not putting the close in the Finally block. Below is what the original code looked like:

using System.IO;
private void CreateLogFile()
{
try
{
    StreamWriter sw =
      new StreamWriter(@"D:\Samples\Test.txt",
      true, System.Text.UTF8Encoding.UTF8);

    sw.WriteLine("This is some text");
    sw.Close();
}
catch(Exception ex)
{
    throw ex;
}
}

You can see in the above code that the sw.Close() method is within the Try block. If an exception occurs when trying to open or write to the file, the code would go immediately to the Catch block and the Close would never execute. If this method is being called many times, this can cause and "apparent" memory leak. With just a little re-factoring the code was fixed to close the file in the Finally block.

private void CreateLogFile()
{
StreamWriter sw = null;

try
{
sw = new StreamWriter(@"D:\Samples\Test.txt",
true, System.Text.UTF8Encoding.UTF8);

    sw.WriteLine("This is some text");
}
finally
{
    if (sw != null)
    {
      sw.Close();
    }
}
}

Notice that there are three items that we had to fix up here. First, the declaration of the StreamWriter was moved out of the Try block. If we did not do this, then the variable "sw" would not able to be accessed from within the Finally block since it would have block-level scope only within the Try portion. Secondly, we created a Finally block, checked the "sw" variable for null, and if it was not null then we closed it. Thirdly, since nothing was happening with the catch, we eliminated it all together.

Watch these types of scenarios as this can cause hard-to-find bugs in your code.

Beware of Encoding Types when saving to a File

psheriff — Tue, 16 Jan 2007 01:12:00 GMT

I learned something today... I was doing some Encryption of strings using DPAPI and converting them to a Base64 string and everything worked fine when I was encrypting and decrypting. However, when I saved the Base64 string to a file, then re-read the data and tried to decrypt the data, it would not work. It took me quite awhile to figure out what was going on.

I realized that when saving text using the WriteAllText method on the File class, you need to specify the Encoding type. For example:

File.WriteAllText(C:\Temp\Test.txt, "This is some text", System.Text.Encoding.UTF8)

Now the above example uses just plain text, but when you are using doing encryption and decryption and you are translating a string to an array of bytes, you use one of the encoding mechanisms to do the conversion. For example:

bytArray = Encoding.UTF8.GetBytes(strValue)

So in this case if you use UTF encoding to translate a string into an array of bytes prior to doing the encryption, you need to make sure that you store these characters to a file using the same encoding mechanism.

I hope this helps someone else, so you won't have to go through the same agony I did!

Paul