RSSInYourFace

À propos of my last post, my latest creation is finished and needs some beta-testing now. It's called RSSInYourFace, and it's an RSS feed reader. Yes, I realize that there are already dozens of RSS feed readers out there, but this one is mine.

I wrote it so that I could stay current on all my favorite blogs and news sites without actually having to waste time surfing the web. This is particularly useful at work where you might want to appear as though you're doing something besides surfing the web all day. The gist of the program is that you supply a list of URLs to your favorite feeds, and the program will sit quietly in your system tray until something new gets posted from one of them, at which point it will alert you with a balloon popup about the new item. Subsequently clicking the balloon as it pops up will launch that website/news item in your default browser.

It was written and tested on Windows 7 64-bit, but should work on 32-bit as well. .NET 4.0 is required.

I would really like some feedback if you would like to use it. Try to break it, make it crash, etc. I'd really like to squash any bugs or inefficiencies that I haven't caught yet. Also feel free to make feature requests - I can almost certainly make it happen. My main concern right now is maintaining support for the myriad different formats of feeds out there. Imagine my dismay when I realized that there wasn't just one standard type of RSS feed. There's never just a standard...

Link to version 1.03 Release Build: RSSInYourFace1.0.3.exe (87.00 kb)
Link to version 1.02 Release Build: RSSInYourFace.1.02.exe (87.00 kb)

 

.NET Programming Love, Multi-Threadedness, and CPU Usage

I do not want to ever be known as a professional software developer.

It's not because I don't enjoy programming, and certainly not because I don't appreciate the people who do love being professional developers. I do enjoy it. It's fun. I've been writing computer programs since I was drawing multi-colored circles in QuickBasic at 14 years old, and I still find it so fun that I do it as a pastime for no other reason than pure personal pleasure.

It's not because "I'm a server guy, or a hardware guy, or an architecture guy, or a network guy... and so therefore I don't need to write programs."  I know plenty of hardware, network and server architecture guys that have entire life-long careers going and don't care to write a line of code ... sometimes not even a line of script!

I don't want to be a professional developer because I'm deathly afraid that if I were forced to code for a living, it might suck all the fun out of it. It's like playing poker for a living. Sure it's fun to play poker with your buddies on a Saturday night and drink and laugh and play ... but what if you needed to play poker to earn a living? What if your performance in Texas Hold 'Em dictated how well you ate or if you made your rent for the month?  All of a sudden, Texas Hold 'Em isn't so fun any more...

You might hear me reiterate that sentiment again throughout the course of this blog, as (at this point in my life) I feel it is one of the defining sentiments of my career as an IT professional.

So, with all that said, I want to share some programming goodness that I encountered tonight, simply as an enthusiast and an amateur programmer. You are more than welcome to comment on how amateurish and unevolved as a programmer I am. I encourage it actually, as there is no better way for me to learn than by accepting constructive criticism.

I really like .NET. I love it. And what makes that very ironic is that years ago, I used to denounce languages such as Java because of its JVM nature. "Why not program against the machine itself? It would obviously be more efficient," I used to say. Well years later, here I am professing my love for .NET - a CLR language, which basically makes it the Microsoft equivalent of Java! I get the feeling that Russinovich and his ilk don't have much respect for us CLR/JVM coders because we operate in a managed sandbox environment and don't have to worry as much about things like byte-by-byte memory allocation... and god forbid we forget to de-allocate something.

But you know what? .NET gives me time to focus on solving business problems, instead of agonizing over every last little memory leak.  That's what makes .NET the perfect "Systems Engineer's" or "Systems Administrator's" language. I don't care about typecasting every last delegated sub type as an enum... and such as.  (Source: Miss South Carolina)

.NET just lets me focus on doing things and solving problems.

Tonight, I was working on a little program for myself, as opposed to something for the company where I work.  Just something that I was personally interested in.  And I had only just recently really grasped the concept of multi-threading my .NET applications. It's something that I had been struggling with for a long time... and I'm not so ashamed to admit that because there are some enterprise-grade applications that I use at work today that our company pays a lot of money for where the GUI freezes up hard for several minutes while the application downloads data and you're left staring at a non-responsive GUI... And now I know that I can do it better than that.

I guess I'll add that to list of things they should be paying me for, eh?

It's not that creating parallel threads is difficult. Least of all in .NET. You can find hundreds of examples out there on Google right now. Knowing when and where to put them in your program and how to use them effectively and design the rest of your application to work with threads effectively is the tricky part. It's a design problem, not a technical one.

It's the C# BackgroundWorker that really got me in to designing good, multi-threaded GUIs.

BackgroundWorker workerEngine = new BackgroundWorker();
workerEngine.WorkerReportsProgress = true;
workerEngine.ProgressChanged += new ProgressChangedEventHandler(worker_ProgressChanged);
workerEngine.DoWork += new DoWorkEventHandler(worker_DoWork);
workerEngine.RunWorkerAsync();

And now you're executing this code in a parallel thread:

void worker_DoWork(object sender, DoWorkEventArgs e)
{
    // do some stuff
    // Sending "progress report" to the worker_ProgressChanged method
    ((BackgroundWorker)sender).ReportProgress(0, "I'm still working hard over here!"); 
}

Which can send "updates" to this method:

void worker_ProgressChanged(object sender, ProgressChangedEventArgs e)
{
    // Sending results back to the main/GUI thread
    outputListBox.Items.Add((string)e.UserState);
}

Which can in turn interact with your GUI. You can do interesting things like populate a listbox on your GUI with updates from the background worker. See, that's one of interesting challenges for us novice coders trying to get in to multi-threaded programming... All of your GUI elements exist on one thread, and you cannot manipulate them or even get any information from them at all from another thread. So the difficulty is in creating a bridge (or a delegate, if you will,) between your threads, which we have now done with a BackgroundWorker object.

Now when you run this code, be aware that your worker thread is trying to try run as fast as he possibly can, which means he can eat up CPU time:

That's my background worker thread doing nothing but spinning in an infinite loop, causing significant CPU spikes on every core. At least the GUI remains responsive. Now let's stick a System.Threading.Thread.Sleep(100) (milliseconds) in the background thread so that perhaps he'll pace himself:

Much better! Now our background thread isn't hogging up the CPU, and our main GUI thread stays responsive and smooth throughout.

And one last thing - never put Thread.Sleep(x) anywhere on your GUI thread. It will obviously cause your GUI to be jerky and unresponsive while it's sleeping, which makes for an awful user experience.

Oh, and Merry Christmas. Hope Santa brings you what you wanted.

NT Debugging

I'm not talking about the NT Debugging blog.  This is one of my personal experiences with NT debugging.

A couple weeks ago, I was looking at a Windows VM that was apparently crashing on a somewhat regular basis.  Through the use of usual logfile analysis techniques we can get some correlations and some probable causes.  In this particular case it was plainly evident that the system was working perfectly until some 3rd party software was loaded.  Then the regular unexpected shutdowns began, about once every day or two.

The correlation was found through the use of the Reliability and Performance Monitor, which is a very nifty tool: 

A "stop," or "bugcheck" we are all familiar with.  It produces a memory dump file in %SystemRoot%\MEMORY.DMP and other "minidumps" in %SystemRoot%\Minidump\ unless otherwise configured.  It's pretty much, well, a dump of everything that the system had in memory when the offense took place.

But do we really know what to do with an NT memory dump?  I have to say I didn't really, and I was a little embarrassed about it.  So I set out to figure out what useful information I could really glean from that memory dump. Having that extra bit of tenacity to really dig down deep and identify with greater precision what the root of the problem is, rather than just saying "well it's some sort of software compatibility problem, better reformat the hard drive!" can help you out in your quest to be the office guru. 

Well it turns out there's a nice utility called Windbg.exe. You can get it from the Windows SDK.  To effectively debug an application, you need debugging symbols. Fortunately, Microsoft has provided some public debugging symbols on their own symbol server.  I hear that Microsoft also has a private symbol tree for internal use only, but we'll just have to settle for the public ones.

Here's a KB  that will help you get Windbg and your symbols path set up correctly. 

Now that you have that configured, simply drag the memory dump file into the Windbg window, and it will tell you with much greater certainty exactly what driver and/or interaction caused the BSOD.

One of the interesting things that Windbg can reveal, is that sometimes drivers installed by crashy software still get loaded even after the software has been uninstalled. And if all that machine code-looking stuff seems scary, Windbg also outputs the simple line: "Probably caused by: driver.sys" that can at least give you a lead.

There are also other dump file analyizers, such as WhoCrashed, that may be more to your liking.

And lastly, be careful about sharing your memory dumps, as they might contain password hashes.

The Linux Kerberos Project

I am absolutely a Windows engineer and an extremely avid advocate of most everything Microsoft, but more importantly I'm an enthusiast of all forms of technology that help to achieve business goals. Whatever it takes to further the state of the art. That means I occasionally enjoy dabbling in Linux too. Whatever gets me closer to the bleeding edge of technology. Not to mention that the vast majority of enterprises have some sort of mixture of both operating systems.

But it's rare to see a deployment in which the Unix/Linux servers participate in Active Directory. Yes, Active Directory is a Microsoft technology and *nix isn't just ready to jump into domain membership right out of the box, but I strongly believe that AD is the mortar that glues any corporate IT environment together. Let us not think Linux vs. Windows... but Linux and Windows!

So what are the ways *nix could benefit from Active Directory?

  • Secure, central management:
    No more maintaining a separate list of local user accounts and passwords on each and every machine. Why not keep just one database of users and machines in your Active Directory that is guaranteed to stay consistent and secure among every single member server forever?
  • Authentication:
    The main mode of authentication in an Active Directory domain is Kerberos. It was invented by some nerds at MIT. Kerberos is Greek for the three-headed hound that guards the gates of hell. (Cerberus in Latin.) This name is apt, because Kerberos is an authentication system that requires three parties. This authentication system involving a "trusted third party" has proven to be secure and trustworthy in any enterprise environment. And the best part? Kerberos is an open protocol that both Microsoft and *nix can both enjoy.
  • As if that wasn't enough:
    Authenticate from machine to machine to machine, without having to re-type your password; without any user intervention at all even! Use one account to run a service on every machine. Active Directory-integrated machines can securely and dynamically update their own DNS records. Log on to a freshly-built machine with domain credentials, without ever needing to manage the local accounts on each and every box. The list goes on and on...


As any IT company grows, it becomes increasingly important that they maintain a cohesive, easily manageable structure that includes all of their devices. So, to that end, I took the time to replicate in my personal lab the steps necessary to join a Linux machine to my existing Windows Active Directory domain. And I've documented the journey. So without further ado: 


As you can see, I've created a virtual machine and installed Linux on it. My domain is at the 2008 R2 forest and domain functional levels. It's pretty much the best domain ever. I'd put my AD architecting skills artistry up against anyone's.


Here I am on said virtual machine, downloading the Likewise (free edition) client. I was planning on doing it all the long, complex, hard way. This software saved me a lot of time.


I created a basic user, and delegated domain-joining permissions to him, but nothing else. I'm going to use this service account for the sole purpose of joining *nix machines to my domain.


Here's where the hair on the back of the neck of any real nerd would start standing up. See what I did there? I just joined my Linux machine to my Active Directory domain, using my specified service account. "SUCCESS" it says. I shall stand for nothing less.


Now we rush off to look at the security log on our domain controller. And what else do we see there but zero audit failures, and a handful of beautiful Kerberos ticket requests and grants. The machine account even popped up in my AD Users & Computers!


And finally - the one screenshot to rule them all - here I am SSH'ing into my Linux box for the first time using domain creds! Kerberos wins the day.

So, that's all I've got for now. I haven't really done any more in-depth research into this than what you've just seen. You're probably already wondering if I can make it do smartcards next, aren't you?