Whaddya got under the hood?

Just in cast you're wondering what makes AppDev go, it's powered by a Content Management System (CMS) called PostNuke. I've been using PostNuke for several years now as a development portal. The framework is easy to set up, easy to customize, and easy to administer, and it runs on virtually any hosted server. If you need to set up a web site of any kind, I recommend you take a look -- it's worth a quick eval.

[edit: this post is out of date, but it's interesting as an archival snapshot]

Tip: building connection strings from scratch

Here's a tip posted by someone on the VB-DATA list. It's already come in handy for me once or twice. Click "read more" for details....-----Original Message-----
From: Discussion for Microsoft Visual Basic Data Access
[mailto:VBDATA-L@PEACH.EASE.LSOFT.COM]
Sent: Monday, August 26, 2002 12:13 PM
To: VBDATA-L@PEACH.EASE.LSOFT.COM

Subject: Re: Web Site for OLEDB connection strings

Just to add to the URL that others have posted....

The method I use to get a connectionstring is to create an empty file with the file extension, "UDL"

Then I open the file, which launches the "Data Link properties" dialog I select the Provider I want to use, and al the criteria (servername, etc), then hit OK

Then I open the file in Notepad to find one conenction string..ready for copying and pasting into the source editor/config file/whatever

See also:

Common connection strings

Running the gamut of testing tools

I have been working recently to introduce JUnit and NUnit to my development shop. My findings are pretty interesting. My Java developers jumped all over JUnit, and my .Net developers were substantially less enthusiastic about NUnit.

I've also done some work with NUnit myself, and have found that it's a pretty interesting platform -- in my case not for unit testing as much as for integration and acceptance testing. In fact, I've wondered if "JINtegration" and "NIntegration" can be far behind.

Hire Good People — Not Good Resumes

In my years hiring developers, I've had the chance to see thirty or so people come on board and grow with me in one organization or another. These people have ranged from fresh out of school to seasoned veterans. The single greatest impression I'm left with after all this is that you don't always get the best developers by going after people with years of
experience.There are a lot of pretty standard practices in hiring developers. Recruiting firms make a living out of classifying people and finding fits for them.

Ask yourself how many of these maxims you have relied upon or adhered to in hiring over the year.

* Hire someone with experience in the technology you use.
* Don't get someone fresh out of school unless you can take a great deal of time to train them.
* Pay should increase with experience.
* If you want to build a high-powered team quickly, hire experienced developers.

Now, go back and reflect on how some individual hires have worked out with respect to these guidelines. Here are some of my thoughts.

When it comes to the technology you use, you have to be ready to give a little. I'm not ready to suggest that you hire a Cobol guy for a C++ job, because the gulf is pretty wide there. But if I want a database developer to work in Oracle, and I find a guy who understands SQL Server, I'll consider him pretty strongly, especially if I think he really *understands* SQL Server and isn't just working out of the books.

There's a stigma about getting folks right out of school, and it's
understandable in a lot of cases. After all, when I came out of school, I still didn't know what I wanted to be when I grerw up. 😉 Some people I've met, however, have been damn sharp - straight out of school. I'm not suggesting you let your guard down on this point, but make sure you keep an open mind.

There is also a pretty common practice to just roll over on pay increases with experience. I'm pretty sure that not everyone's experiences are the same as they move through their carreers, yet they seem to all end up the same -- "C++ programmer with 5 years' experience". I like to try to use the interview to tell whether this experience was rich or whether the guy was just sucking up oxygen.

Finally, I want to talk about building a team out of high-powered, experienced developers. It's probably about the worst idea you could have. Get a bunch of "experienced" developers together, and unless you're real lucky, all you'll get is a bunch of infighting. If you want to build a team as quickly as possible, look for good attitudes, because everyone is going to have to learn a ton of stuff as things evolve, and there isn't a lot of room for egos.