Why do so many software development projects either fail or result in poor-quality products? It may have something to do with the way we educate software professionals, this author contends. Drawing a distinction between software engineering and software development, he outlines the practical approach he uses to prepare college students for their first industry job.

NetScout Systems delivered disaster recovery to its performance and application management users when it released a new standby server for its nGenius Performance Manager Server. Between natural disasters, security breaches, and government regulations such as Sarbanes Oxley, a growing number of network operators and application administrators are asking for the ability to fail over to a backup server for their performance monitoring and management offerings. Tools such as the distributed nGenius Performance Manager can show which systems and applications are online, which users and sites are online, and how well servers are performing on backup networks and systems.

I’ve had the night to sleep on my implementation of pinging to RSS ping servers and I realized I had a question. In my research, I found tools that sent a ping for every new item, and sent that item’s URL and name to the pinging servers. I also found tools that seemed to send a ping once for each time the feed was updated, and then sent the URL of the site and the name of the site to the pinging servers. I’ve implemented the first approach, but I’m wondering whether it’s overkill. I noticed that Technorati is accepting our pings, but now shows all of the ZATZ magazines as the linking sources to all the other ZATZ magazines, which, in and of itself, doesn’t mean much, but it might mean there might be a better approach to pinging. If you’ve been dealing with RSS pinging, please drop a note to me at david@ZATZ.com with your thoughts. — David

Pinging RSS servers now works. I had one other thought about why everything jammed up. Back when I mentioned we had allowed 200 entries, times 12 ping servers, for 2400 entries, I didn’t factor in that’s only per magazine — and we have five magazines. So I’d just queued up 12,000 individual pings, which isn’t good for anyone. We’re now caught up on a much smaller number of pings and should be running smooth from here on in — at least for this feature. G’night all! — David

That’s better! It’s working now. As new news items are processed and posted, we’re now queueing pings for the pinging servers, getting the results of the pings, and processing RSS feeds. As of now, we have RSS 2.0 feeds working, auto-discovery working, and automated pinging of n-number of defined pinging servers working. That’s a yabadabado! — DG

I think I’m on to something. One of the reasons this is an issue is that the first time a news item is processed, it’s queued for pinging to the RSS pinging servers. Since DominoPower’s never done that, there’s a ton of news items queued. Once we run this through successfully once for each magazine, we’ll only be queueing a few news items each day.

Well, that certainly helped. By the way, the reason I’m telling you all this is because we need to test this system with new news entries. Since DominoPower readers are comfortable in the ways of debugging, I figured I’d expose you to this process. I just reduced the queue size and cleared the backlog of problem entries. Let’s see if that gives us a queue we can manage.

I’ve got a couple of theory’s about what’s causing the backup. First, now that we’re pinging RSS pinging servers, we’re doing it for 12 different servers for each news message. We were building feeds with as many as 200 news items, so a single update would cause 2,400 items to queue in the render queue, each of which would require a network connection. I also modified the render queue to process items at a much higher speed, but that speed may have resulted in less cycles for other work. Let’s see what we get if first, we reduce the size of the feed back to a more manageable 20 items.

Well, whatever’s jamming up the system with in my new RSS pinging code isn’t pretty. When I ran the last test, the system took both CPUs to 100% and locked them there. Now, this routine normally runs for a fraction of a second and uses maybe 5% of the system’s resources. So it’s time to do a trace and see what’s causing the jam. Stay tuned…

OK, something jammed. Let’s see if we can see what’s happening.