One way to deal with possibly-NULL string values from a datareader is to check for NULL first, e.g.

string myvalue;
if (myDataReader["MyField"] != System.DBNull.Value)
    myvalue = myDataReader.GetString(myDataReader.GetOrdinal("MyField"));
else
    myvalue = "";

But a less-code way is to just let the Convert object handle them for you:

string myvalue = Convert.ToString(myDataReader["MyField"]);

It may not perform quite as well as explicit checking, though, so don't use it in a tight loop if you're concerned about performance.

If you're automating Excel via the ActiveX/COM objects, you may notice an annoying msgbox saying

This action will cancel a pending refresh data command. Continue?

you can disable it via

Application.DisplayAlerts = False

Or if you're actually instantiating an object from outside of Excel VBA (e.g. from a C# console app), try

Excel.Application ExcelObj = new Excel.Application();
ExcelObj.DisplayAlerts = false;

In IIS 6/Windows 2003, you may notice that session or cached information sometimes "disappears", seemingly at random. No, it's not gremlins...it could very well be your Application Pool settings.

If you are running in IIS6 mode, your web sites will be using Application Pools. If your app pools are set to run using multiple processes, then cache & session information will be inconsistently accessible to aspx pages. Check the # of processes for your IIS 6 app pool. If it's 1, then that's the cause. Or if different vdirs on your site have different pools, that would also cause the results you're seeing.

Why? Imagine your app pool has two processes, A & B. An ASPX page stores an item in the cache or session. Through random luck, it gets stored in process A. Now the user requests another page & asks for that item from cache or session. But this time, the ASPX page might look in process B. Since the item is stored in process A, not process B, it will come up emptyhanded. If your ASPX page then re-stores the item during this call, it'll store it in process B. And now you have two (possibly different) versions of the item, one in process A, one in process B. And who knows which one will get pulled up on the next ASPX request.

So, if you plan to use in-process session state or cached items, be aware of the above, or else set the number of processes of your Application Pools to 1 (uno).

It's worthwhile to be cautious if you assume the cache will stay "in sync" with a database. Memory conditions, app restarts, etc. can expire items in the cache quite easily.

This is a really good article on interviewing people. I've been developing for a long time, managing for quite a while, but only in the past few years have I been doing a lot of heavy duty hiring, interviewing, etc. I've gotten good advice, but man, it's harder than one would imagine. But this article looks pretty sweet. Or at least the first few paragraphs, which is all I've read so far. Maybe that's my problem...maybe I need to finish what I start. :) J/k, I'll finish it tonight on the train.

Ah, crazy Firefox. There's apparently a known bug that causes a slow but sure memory leak with Firefox. The basic solution is:

1. Type about:config in the address bar
   
2. Right click the page and add a New->Integer
   
3. Name: enter browser.cache.memory.capacity
   
4. Value: enter 16000
   
5. Close Firefox completely.
   
6. Fire it up again and enjoy :)

Discussed at greater length on the mozillazine forums.

I've been casually looking at various web hosting providers, trying to sort out my hosting options. Perhaps you have an idea for a web site, or a site that's outgrown its current host, but you're not sure where to host it.

There are a few things to consider for hosting your web site:

Web Hosting Consideration #1: What your site will be used for

First you need to know what your site's purpose will be. Is it an online business? Personal home page? Family photo album? Gathering place to talk about your favorite game?

Web Hosting Consideration #2: What features your site will offer

Knowing the above will help you decide which features you need on your site. For example, you may want a photo album of sorts. Maybe a message board would be nice. Sticking a blog up there could be helpful. And maybe you need an e-commerce engine and credit card processing in order to sell all that jewelry you've been making. If you're a developer, you might be making a lot of these things yourself, or modifying them.

Web Hosting Consideration #3: How many visitors you'll have

If you plan on getting a lot of traffic, you should consider dedicated hosting and a lot of bandwidth. If it's a small site about your pet cat, maybe you can just host it in your basement.

Web Hosting Consideration #4: Platform: ASP, ASP.NET, PHP, JSP, or something else

If you plan to develop web applications for your site, the platform makes a big difference depending on your skillset. I'm decent with PHP, but my strongest suit is Microsoft technology like ASP and ASP.NET.

If you're neutral on platform, consider that PHP hosting is usually cheaper, you can usually find more free "widgets" to use with PHP, and PHP is easy enough to learn. However, you might want to learn ASP or ASP.NET for career reasons, and you might get better productivity gains using Visual Studio to build ASP/ASP.NET pages. I don't see a lot of hosting providers that offer JSP. Lastly, if you're just storing images, a blog, and static HTML, then you don't need any of the above -- you can use any hosting provider.

You can find tons of online arguments over which web platform is better. I will just say that any technology is sufficient to do most or all web development in.

Web Hosting Consideration #5: Software Modules

I wasn't sure what to call this section, but I mean stuff like whether your site will need to be able to send email, whether you need a database, whether you need SSL processing. If you're a developer, you'll know if you need most of those things. Or if there are third party modules you're going to integrate (e.g. some hot PHP messageboard module), you should read the requirements and compare it to where you host your site.

Web Hosting Consideration #6: Bandwidth

This has a lot to do with how popular your site is and what is stored there. If a lot of people come to your site, you'll need a lot of bandwidth. Or, if you're hosting huge files (like giant JPGs from your 5mp camera, or 2 hour streaming home movies from Grandma's birthday), you'll also need a lot of bandwidth to keep the performance up. A home DSL or cable connection can easily accommodate a few thousand people a day for a site with no or very few large files. Otherwise, you should look into getting a better home connection (768kbps upload or faster), or hosting elsewhere.

Web Hosting Consideration #7: Disk space

Has to do with how much stuff is on your site. As mentioned in the bandwidth section, huge files or lots of big photos take up a lot of room. Some hosting providers offer a lot of bandwidth but not a lot of room to store files. If you truly need tons of space (a lot of home movies?), then your options are more limited.

Web Hosting Consideration #8: Performance: CPU, memory, etc.

If you have a lot of traffic, you need more power. You'll also need more CPU & ram if you're running dynamic web applications like messageboards, e-commerce sites, etc.

Web Hosting Consideration #9: Uptime

Uptime (sometimes called availability) refers to what % of the time your site is responding. Hosting providers will often guarantee a certain uptime, so you should consider what the impact of your site being down for a few minutes/hours/days is. A site with 100% uptime is available 100% of the time, 24x7. Good for commercial sites with a lot of usage. A site with 99% uptime sounds good, but that means it could still be down 90 minutes a week and be considered 99% available. Lastly, if you're hosting your site in your basement, or with a provider with no uptime guarantee, realize that your site might be down for hours or days. Maybe that's ok, but you should stil consider it.

Web Hosting Consideration #10: Hosting provider

Now you can start to think about where to host your site. You have a few options:

Host it yourself
If you have a DSL or cable connection at home, and a spare computer, you can host your web site yourself. If you have a dynamic IP, there are services like DynDNS or TZO so you can point www.yourdomain.com to whatever your current IP is. Check your ISP's terms of service, though -- some ISPs prohibit users from hosting sites.

Pros:

• You can use whatever operating system, software, or hardware you want. If you need more CPU or storage, you can always buy more. For example, ComputerGeeks is one place that sells cheap used computers -- for $100-$200 you can get an entire machine that would work fine as a web server.


• Affordable and flexible solution for small sites, since your current DSL/cable connection may be sufficient.

Cons:

• May be prohibited by your ISP's terms of service


• If your site is large, bandwidth and hardware costs can add up


• Ensuring high uptime can be problematic, even with a UPS.


• You can spend a lot of time just managing the hardware and operating system. For some people this is a plus, I guess. :)

Typical sites:

• Personal or family web sites with few visitors


• Sites for technical hobbyists


• Sites needing a lot of storage but not a lot of bandwidth

Use a free provider
If you have an ISP, chances are a free web site came with it. You can also find places like GeoCities where you can have a small site for free. Probabaly a good options for someone who just wants to store a few HTML pages.

Pros:

• Free!


• Less hassle, faster, and more stable than your basement.

Cons:

• Usually no functionality other than static HTML pages and images.


• Usually very little storage space.

Typical sites:

• Personal home pages


• Online resumes

Managed hosting plan
If the above two options don't float your boat, you can have someone else host your site. You'll have to do some research to see if plans and providers fit your needs and budget, but you can find plans anywhere from a few dollars a month (for basic sites) to a few hundred a month (for heavy duty sites). You can even find plans for dedicated servers (you have the entire web server to yourself) or co-location services (you purchase your own web server and store it at the hosting facility).

Pros:

• Someone else will manage the equipment and operating system, freeing you to focus on your site.


• Range of prices & plans means you can pay for what you want and skip what you don't


• Access to high uptime and value-added services like e-commerce software, etc.

Cons:

• The main drawback is cost. You can find plans for $70/year or less if your budget is tight, but if you need a lot of bandwidth, storage, etc. it can add up.

Typical sites:

• Suitable for all but the smallest of budgets

Some hosting providers you can check out:

• HostSave -- plans from $8/mo on up


• Hostingmetro.com -- also from around $8/mo up


• NoMonthlyFees -- starts around $6/mo


• ValueWeb -- plans are $25+/mo, better for popular or powerful sites
  

Hopefully the above points will help point you in the right direction for web site hosting. Good luck with your site!

I wanted to mention that if there are web pages you want to monitor for changes, WebMon fits the bill very nicely. It can monitor pages as frequently as you'd like, and alert you in the status bar and/or in a popup when the page changes. And it's free. And not ugly. :)

Check out FormShield to generate CAPTCHA images in .NET. e.g.










I was going to write a control myself, but I guess I don't have to. :)

I had a bunch of links at www.developmentnow.com/nntp/ that Google had indexed, but I wanted Google to instead use the new links at www.developmentnow.com/g/. I was planning on using a 301 Redirect per my earlier post on search engine-friendly ways to change URLs, but it seems like Googlebot has once again gotten it right.

You see, the links at www.developmentnow.com/nntp are old. I don't link to them any more -- I link to the new urls. So the old URLs are orphaned, i.e. without a home or parent. :( Yet I had to keep them up b/c search engines were linking to them.

But it seems that Google figured out that the old /nntp/ links are no good & that it needs to start using the new ones, because over the weekend it started linking to the new URLs.

I'll still use the 301 Redirect, just in case, but the takeaway is: if Google is linking to a bunch of URLs on your site that can't be reached from your homepage, then it may stop linking to those URLs.

Say you have some pages indexed in search engines, but you want to change the URL of those pages. What you should not do:

Do NOT delete the old pages and create new ones at the new URLs -- this will cause all your links to drop from search engines.

Do NOT keep the old pages around and create new ones at the new URLs -- search engines will penalize you for having duplicate content. They could ignore the new URLs, or drop your site entirely

Do NOT redirect the old pages to the new URLs via javascript or META Refresh -- search engines will think you're trying to do something tricky

Do NOT redirect the old pages to the new URLs via Response.Redirect (i.e. HTTP 302 redirect) -- this is by definition a "temporary redirect" and could confuse search engines or again make them drop your links

What you want to do is 1) automatically jump users to the new URLs when they visit the old URLs, and 2) tell search engines that your pages are still good, but they just have a new URLs. You accomplish this with a HTTP 301 Redirect : Moved Permanently". And the code is simple...put this code in your old URLs.

ASP:

Response.Status = "301 Moved Permanently"
Response.AddHeader "Location", "http://www.domain.com/newurl.asp"

ASP.NET:

Response.Status = "301 Moved Permanently";
Response.AddHeader("Location", "http://www.domain.com/newurl.asp");

Linux/Unix Apache, in your .htaccess file, put

redirect 301 /oldurl.html http://www.domain.com/newurl.html