MassDataHandler article in .Net Developer's Journal

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/massdatahandler_article_in_net_developers_journal.htm]

Paylocity recently published an article about the open-source MassDataHandler. This framework assists with testing the database.

We've also uploaded version 1.3, which offers several new features:

• Improved handling of identity values and triggers: (1) Triggers no longer break the identity inserts, (2) You can specify identity inserts for a table-by-table basis using an Xml attribute on the Table element, (3) If you set IdentityInsert=On for a table without Identity, then it no longer crashes.
• Improved extracting from existing data: (1) The Existing Data tab can now use a custom select that returns many tables, and (2) When using Existing Data tab, if you use a Custom filter, it will copy your Sql select values into the Xml file as a meta node.
• Some miscellaneous bug fixes and enhancements.

You can download the framework on Microsoft's CodePlex site.

How Old is Legacy Code?

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/how_old_is_legacy_code.htm]

Most developers like to write their own, new exciting code. However, the reality is that often you deal not with new code, but rather existing "legacy" code. How old does code need to be before it's considered legacy? Some people say just a few minutes - you type code, you go get a snack, you come back, it's now legacy code. I don't think this is fully practical. Rather, here are some general guidelines that I personally find helpful in deciding if something is legacy code or not:

• Is the original author no longer available? - Nothing makes code seem more legacy than when you no longer know who wrote it.
• Is the code already in production? - Once code is in production, there is a definite contract and expectation that you need to adhere to.
• Is the code to big to just throw away? - If the code is small enough that you can just throw it out and restart, it's not really legacy yet.
• If it's your own code, have you forgotten it? - Even if you wrote the code yourself, if you've done several things since and therefore no longer remember it, it seems more legacy.

In summary, legacy code implies it's already in production, or it's too big to throw away, or you have to re-learn what the code does (because either the original author is gone, or you can't remember it). Throw-away code that you wrote five minutes ago which isn't used by anyone else isn't really legacy yet.

Paylocity is hiring a QA engineer

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/paylocity_is_hiring_a_qa_engineer.htm]

If there's any sharp QA Engineers in the Chicago, IL area looking for a new job, my company, Paylocity (http://www.paylocity.com/) is hiring. This is a good environment - little politics, vibrant and growing company, great team chemistry, and a ton of learning and growth opportunities. We're a .Net development shop, primarily working on an ASP.Net 2.0 web application that assists clients with Payroll. I'm a developer, and from a developer's perspective, the ideal candidate would have a technical and automation background, and would be comfortable with questions like:

• How would you test the function IsEven (check here for some ideas)?
• How would you test Notepad or Excel?
• Have you ever needed to set up your own performance or UI testing framework?
• Do you like using tools and technologies to simplify and automate testing? Which technologies do you think are good for QA testers to know?
• How can you improve a process to reduce testing time (such as using automation for regression testing)?

QA engineers are vitally important, and there's so much more to good QA testing than repetitively clicking away at a website. For an opportunity to be part of a great team, just send an email to  tims#@#paylocity.com (remove the '#").

UPDATE: Description moved to here

Good article on achieving a zero-bug count

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/good_article_on_achieving_a_zerobug_count.htm]

James Shore wrote a great article on achieving zero-bug count. It's part of his up-coming book.

Some of the things I really like are how he emphasizes that bugs are not "okay" or "necessary", but rather that the team should take active steps not to just prevent bugs, but to prevent the cause of bugs. For example, being required to explain why a bug occurred, such as adding a textbox to your bug-tracking system that requires the developer to explain what caused the bug.

The problem with bugs is that they take 10x longer to fix than create. So if you can improve your process to reduce bugs (which takes more time upfront), you can then go into an "upward spiral", where things keep getting better and better.

It's a thoughtful article.

Merry Christmas!

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/merry_christmas.htm]

Merry Christmas!

Different Types of Comments

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/different_types_of_comments.htm]

Programming enterprise apps and their supporting processes, I've used at several languages. Most of them have different ways to make comments.

Characters	Languages	Multi-line vs. Single-line	Characters
//	C#, JavaScript	Single	2
/*  */	C#, SQL, CSS	Multi	2,2
'	VB	Single	1
REM	DOS	Single	3
	XML, HTML	Multi	4, 3
<%-- --%>	ASP.Net	Multi	4, 4
--	SQL (single line)	Single	2

I didn't have any big dialogue on this, I just found it interesting - 7 different ways to comment code for a set of languages that are often used together for a common goal. I'm sure that someone with a strong Compiler background could explain the significance of multi-line comments vs. single-line comments, and number of characters involved to create the comment identifier.

ASP.NET AJAX Control Toolkit - making it simple

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/aspnet_ajax_control_toolkit__making_it_simple.htm]

Looking at the newly available ASP.NET AJAX Control Toolkit, there are several things I really like about it.

• It has a quickstart with a sample page for each control.
• It takes less than 5 minutes to download and get running.
• The controls are mostly cross-browser compatible.
• It's free.
• It's open-source.
• It's practical - i.e. the controls are based on useful needs, not just flashy toys.

I especially like the ModalPopup and PopupControl. The first presents just that - a modal popup (which nicely fades out the screen). The second provides a dropdown-type control which is great for X-Pickers (Date-Pickers, Employee-Pickers, Color-Pickers, etc...)

Even if you're in an older shop that already developed a lot of your own controls, it's still worth investigating because these are (1) standardized, (2) likely to continually improve with the support of an entire community, and (3) potentially better and more robust than a control that a single dev whipped up a year ago under schedule pressure.

What I notice is that these controls abstract a lot of complicated DHTML features, like drag & drop, multi-layering, and DOM-modification, all while being cross-browser compliant. In a way, it's reduced advanced DHTML to mere copying and pasting.