Sunday, May 17, 2009
Back from hiatus.
I've never had an excuse to do remote debugging until recently, but I've always heard that it's a serious pain in the ***, hence, I avoided it. Recently I really needed it to work, and of course, it didn't.
Remote debugging seems to be a little easier than it used to be, and if you do enough searching you'll eventually find what you need. Here's the short version:
Step 1: Go here: http://www.microsoft.com/downloads/details.aspx?FamilyID=440ec902-3260-4cdc-b11a-6a9070a2aaab&displaylang=en
This is the remote debugging service installer. Assuming that you don't want a full Visual Studio installation on the remote machine, you can install this service on the remote machine.
Step 2: Add permissions. The debugger service you downloaded in step 1 needs to run under an account that has permission to your local machine. I think it may need admin rights on both boxes, but I'm not sure. In any case, the accounts I used to get it to work were admins on the machines they were on.
Step 2.5: Fake it out. Here's where it got wonky for me. I couldn't add the permissions in step 2. My dev box was in one domain, the box being debugged was in another domain (dev domain), and the domains did not have a trust relationship. Therefore, I couldn't add my local account to the dev box, nor could I add the remote account to my local box. Game over? not quite. There is a workaround. Create a local account on your dev box with the same username/password as your domain account. Do the same on the remote box. Run the service as that account. Magically, it all just works.
Step 3: Miscellaneous debris. I also was not able to resolve the remote machine's name through DNS, but when you connect to the service, it wants to resolve the name. Get around this by adding the remote machine's name to your hosts file (at c:\windows\system32\drivers\etc\hosts). It just works better.
Step 4: Do it. Select Debug->Attach To Process. Under Qualifier Type the remote machine's name (or IP address) or select Browse, if you have name resolution. The processes from the other machine should show up. Select the one you want. (Don't forget to set a breakpoint).
That's it. Easy when you know how. Serious pain when you don't.
Friday, January 23, 2009
This is one interview question I ask in every interview, and I get a lot of grief for it. I've done it for years. I used to work for a guy who was primarily a Delphi developer, and he as much as ordered me to not ask that anymore. I think it's a fair question. People who work in IT using an object oriented language should have a basic grasp on what the three tenets of Object-Oriented Programming are. If you work in an object-oriented language, you know what they are, but you may not know what they're called.
- Encapsulation: This is basically information hiding. All it means is that data internal to the class that other classes have no business messing with are inaccessible to the naughty classes trying to mess with them. That's what the "private" and "protected" keywords are for. If you make everything public, you might want to go pick up the old Bjarne Stroustrup book. This is your craft, time to learn it.
- Inheritance: This one is easy. It's what comes after the colon in your class declaration (in C-style languages, anyway). Most everybody knows what this is. One hopes they do, anyway.
- Polymorphism: This is the one everybody forgets. It's also the hardest one to describe. In layman's terms it means you have a virtual function/property/whatever declared in an ancestor class that is overridden in a descendant class. For instance, if you have a Shape base class with descendants Square, Rectangle, and Circle, you might have an Area() method on the base class that is implemented differently by each descendant class. A Shape pointer/reference that actually points to a Circle will calculate (Pi)r^2. A Square will calculate W^2, and a Rectangle will calculate L*W. The more common example is the Employee base class that calculates salary differently for hourly and salaried employees, without the need to know what type they are. You just automatically get the right one because the method is virtual.
Most people are familiar by now with how virtual methods work in their favorite OO language, but most people don't know there's a computer science term associated with that behavior. That's why I ask this question. I don't expect most people to get it right, it's about the reaction to the question.
The results to this question are always fascinating.
At a previous job, one candidate answered that he wasn't sure if he had the right answer, but tried anyway. He went on to describe Encapsulation. I gave him credit, because he was A) honest that he wasn't sure, and B) I was pretty sure he knew the answer at one time, because describing Encapsulation means he actually learned the three tenets at some point. We hired him. He realized what a nuthouse he'd gotten himself into and left. C'est la vie.
I told a friend of mine about this question and she used it in an interview. The interviewee responded "Oh, that's just a buzz word". That's the kind of thing that sets me off. You can't possibly think I would ask a question I didn't know the answer to? Don't bluff. Calling one of the staples of computer science a "buzz word" shows that A) you're bluffing, B) you don't really know, and C) you've dismissed it as something not necessary to learn to do this grunt work thing called programming. Any monkey can do this, right? Calling polymorphism a buzz word is a bit like saying the X-Ray is a passing fad in the medical field. This kind of answer tells me that coding is not a craft to this person, it's a 9-5 job. Programmer is not what they are, it's just their job. That doesn't make them a bad person necessarily, just not somebody I want to work with.
A more recent interviewee responded simply "I don't know". Surprisingly, this is a good answer. It shows honesty and integrity. It tells me that I can count on a straight answer from you when I need it. Besides, I was pretty sure he knew it, he just didn't know it's name. There's a Taoist tenet that states "knowing gets in the way of learning." This sounds absurd at first, as do most Taoist tenets, but someday it will click, if it hasn't already. Admitting that you don't know means you're able to learn it. That's a good thing.
You can learn a lot from an interviewee from this question. Short of having them actually write code (which I think we should), it's one of the best ways to cut through to what kind of programmer this person is.
I've been talking with my boss recently that I think the interview process for developers is a bit flawed. We hire people based on their ability to interview well, not their ability to write good code. Jeff Atwood of Coding Horror wrote last year about the FizzBuzz test. Jeff is one of my favorite bloggers. He takes his craft seriously and has trouble with people who don't. He defines the type of person I want to work with. Luckily, most of the people I work with currently qualify. I've suggested (seriously, even thought I think it wasn't taken as such) that we should administer the FizzBuzz test. The test is simple.
Write a program that prints the numbers from 1 to 100. But for multiples of three print "Fizz" instead of the number and for the multiples of five print "Buzz". For numbers which are multiples of both three and five print "FizzBuzz".
Since I work with good developers, I find it hard to believe that 199 out of 200 applicants could not pass this test. I would hope most of the candidates I see could. Maybe they can't. This test would tell us a few things though.
A) Whether or not they can write code at all. That's a good thing to know when you're hiring a developer at near those kinds of salaries. Some people interview really well, and can't write code to save their mother. That's not necessarily easy to glean in a 30 minute interview unless you ask them to write code.
B) How they code. Truthfully, there's more than one way to solve the FizzBuzz test. The "obvious" choice is to use the modulus operator, but there's always another way. Say using counters. How the applicant solves the problem is telling. Also, seeing them code the answer gives you a clue to how they work, something you can't tell from a finished product, even if they get it right.
Anyway, there's no summary point to this, just a final suggestion. Take your craft seriously. It is a craft, it is an art. Your college COBOL teacher was wrong. It's what we are, not just what we do. If you don't "go try that out at home" occasionally, if you don't have some sort of IDE installed on your home PC, you might reconsider is this is the right career for you. On the other hand, if you're reading this blog, it's highly unlikely that you fall into that category.
Sunday, December 21, 2008
I started this blog back in September with a particular purpose in mind. Every yahoo and his brother has a blog these days, and by far the majority of them are absolute trash, but every so often there's a gem. As developers, we seem to mostly agree on which ones are the gems. Non-developers most likely have different lists, depending on their focus. There's a long list of blogs I love to read, and couldn't possibly hope to be counted among them, but one day I realized something. There's a lot of things I know that many others don't. Sure, somebody somewhere knows that particular little piece of knowledge, but they may not have a blog of their own. Fairly often when googling for the answer to a problem I can't find just the right answer I'm looking for. Somebody somewhere knows the answer, but they didn't blog it. That's when I saw the value of starting my own blog, so I created The Code Monkey (inside joke) for just that purpose. It's a place to post those little tidbits of knowledge I've acquired that not everybody else knows. Then life caught up with me and I got busy. That's why I haven't posted since September.
There's been this little voice in the back of my head bugging me for weeks now. I'm pretty sure it's Jeff Atwood. I have a lot of respect for Jeff, and he talked about how difficult it is to maintain a blog in a DotNetRocks interview last year. In it he talked about how he made a decision to write X many times per week. While that's very admirable, I think I'm going to have to set my sights a little lower to start with. I'll aim for one post every two weeks or so. Why am I telling you this? So that you'll mock me if I fail to keep it up.
Peer pressure, you can make it work for you too.
Just to top it off, a friend of mine challenged me and another friend to write two posts in two weeks. The one who fails to has to buy the beer. That's pretty motivating. If you blog and have friends who blog, you should try it out. Unfortunately I think I've already missed the two week deadline, but I can still beat the other guy and get free beer. Helping out your fellow developer and getting free beer at the same time, you can't beat that.
So began my search for a blog topic. Turns out it found me. A couple of months back I was working for Magenic in Minnesota. Check out the link, I was excited because I got to help a friend debug some of the Silverlight on the front page. Anyway, Rocky Lhotka, creator of CSLA and Microsoft Software Legend for those who don't know, posted a question on the internal forum server which got me thinking. I don't remember if I put my $.02 in or not, but out of curiosity I asked the same question on the forum server at my new job. The results surprised me a bit, but they probably shouldn't have.
The question was "Should var be used for variable declarations outside of using LINQ?" This is a surprisingly polarizing question, and it's showed up a few other places recently. One of the managers at Resharper, Ilya Rezhenkov, had this to say:
"Some cases where it seems just fine to suggest var are:
- New object creation expression: var dictionary = new Dictionary<int, string>();
- Cast expression: var element = (IElement)obj;
- Safe Cast expression: var element = obj as IElement;
- Generic method call with explicit type arguments, when return type is generic: var manager = serviceProvider.GetService<IManager>()
- Generic static method call or property with explicit type arguments, when return type is generic: var manager = Singleton<Manager>.Instance;"
I have to admit, ReSharper was a big influence in overcoming my aversion to the "var" keyword. It's no secret that I'm a fan of ReSharper and think that it helps standardize and improve code. It doesn't hurt that each subsequent version of Visual Studio implements a lot of the functionality that ReSharper already provided, forcing them to work hard to stay ahead of the curve to justify purchasing it.
The main argument against the var keyword is that it reduces code readability. Looking at the five listed scenarios above, I don't see how it reduces readability. Take example one. Is it really necessary to say "Dictionary<int, string>" twice? I don't think so. The same is true for 2-5. Each example already states the type quite clearly, and var allows you to say it once.
However, take this example.
var rdr = DataWrapperClass.ExecuteReader();
It's not immediately clear what type of variable rdr is. I still think var is a good choice here, and I have backing reasons for it. This is taken from an actual scenario I ran into in my current job. In this case we had a wrapper class around all of our data access code, and it provided some useful functionality. We use CSLA in our shop, and this method returned an instance of CSLA's SafeDataReader, which is itself a wrapper around the IDataReader interface. However in the current project it fell a little short. We're upgrading a rather dated codebase that was originally written in C++. Much of the code dates back years. Having started out in C++ myself, I remember when C++ didn't have a native boolean type. What you used was integers. 0 was false, non-zero was true. The database we were working with followed this same convention. Many boolean values were stored as integers. To help out with this, I extended SafeDataReader to allow reading an integer column as a boolean. Next, I changed the return type of ExecuteReader to return my new class. All references to ExecuteReader explicitly declared the return value to be SafeDataReader. There's a number of ways this can go. The particular method I overrode happened to be virtual, so it turns out the code would work as is, but seeing this in the code
SafeDataReader rdr = DataWrapperClass.ExecuteReader();
can be even more confusing that var, because while you think you're working with SafeDataReader, you're not. But what if the method I had overridden hadn't been virtual? The code would still compile, but when you tried to read an integer column as a boolean, the code would blow up. Why? Because even though the actual instantiated type is my custom derived class, you are still accessing it with the SafeDataReader interface so it would call GetBoolean from SafeDataReader, which doesn't expect integers. That becomes a runtime error, my friend, not a compile time error.
Here's another example. In this same class I implemented a new reading function that would translate "O" and "P" to true/false. Don't ask, but it actually happened. This method is not accessible from SafeDataReader, it's only accessible if you use my derived class.
Both of these examples can be shrugged off, with a "We'll fix them as we find them" attitude. On the other hand, what if I had needed to implement my own class instead of inheriting from SafeDataReader, even though the interface is similar? I now have to fix hundreds of lines of code before I can recompile. If they had been declared with var instead of SafeDataReader, I could have done the same thing in a couple of lines of code.
Dare Obasanjo responded to the ReSharper post with examples of how the codebase for RSS Bandit had become less legible as a result of ReSharper's suggested use of var. I like Dare, but I have to take exception to some of his responses. They're not in any way suggesting we should go back to Hungarian naming conventions, and I would sooner write Cobol than see that. They're suggesting better names like "currentElement" instead of "e" or "element", which we should all be doing anyway. He even invokes the holy Microsoft C# Language Reference to make his point.
Jared Parsons also chimed in in response, and quite observantly grouped people into three camps on this topic.
"There appear to be three groups in this debate.
- Whenever it's possible
- Only when it's absolutely clear what the type is
- Never, type inference is evil "
I'm still surprised at how many people, even in my own office, fall into category 3. I'm somewhere between 1 and 2, but I lean heavily towards 1. I'm still not convinced there's any value to
var someValue = 5;
But I can't quite articulate why that one bothers me and the others don't. The main reason I like var, however, was listed on Jared's page rather than any of the Resharper team's reasons.
"Makes refactoring easier. I re-factor, a lot. I constantly split up or rename types. Often in such a way that refactoring tools don't fixup all of the problems. With var declarations I don't have to worry because they just properly infer their new type and happily chug along. For explicit type cases I have to manually update all of the type names. "
Yep, as noted above, I ran into that one myself.
I understand the readability remark, given that you're using Notepad to write your code. It's not a problem for me because, apparently unlike the denizens of Camp #3, I use Visual Studio for my day to day work. For those who can't afford VS, there's a free version as well. It's got this really cool feature that Notepad doesn't give you. If you move your mouse over the "var" keyword, you see this:
Yep, that's the compiler inferred type right there. If you're not sure what type rdr is, all you have to do is move your mouse.
I probably sound a little snide with this example, but really people! We've moved on. Code is too complex to be done in Notepad these days. IDEs handle most of these kinds of problems out of necessity. It's even been suggested that the complexity of modern code could be mitigated by storing source in a custom format rather than text files. We've been using text for decades and it might be time to upgrade. That's a topic for another post, however.
As usual, I'm the Black Sheep in my company on this topic, and have taken a fair amount of ribbing about it. My last parting thought to the citizens of camp #3: Check out C# 4.0. It introduces the dynamic keyword. It's coming people, get used to it or become the next Cobol programmers.
(My apologies to any Cobol programmers reading this.)
Wednesday, September 10, 2008
It doesn't seem like all that long ago I was trying to get my head around exactly what a delegate was. Honestly it wasn't that hard for me coming from a C++ background, since they were an awful lot like function pointers. But still, the concept was just a little different.
In the interest of making your UI more responsive, it's a good idea to thread some of the more intense work that occurs in your application. As soon as you say "Threading", a lot of people blanch and go pale, but it's really not that difficult, in fact, one class makes it downright easy.
The BackgroundWorker component (System.ComponentModel.BackgroundWorker) is specifically designed to take some intensive work and make threading it easy. It's a component, so you can drop it right on your form and just simply subscribe to the events DoWork and RunWorkerCompleted. DoWork is the event that fires on the worker thread and is where your intensive work that would otherwise freeze the UI would occur, and RunWorkerCompleted is the event that fires back on the main thread (or more accurately the thread that initiated the work) and allows you to get the results of the threaded work. RunWorkerAsync() is what tells the worker to spawn of the worker thread and do the work.
I like using this component, because it takes a lot of the complexity of working directly with with the Thread class away and handles it for you. Less plumbing to maintain.
I recently ran into a case where I wanted a component to behave similarly, where you would simply call a method to say "go do your thing" and then fire an event when it was done letting the caller know it could get the data now. The work would occur on a worker thread so that it would not freeze the UI, but the UI would not need to know anything about that. As far as the UI was concerned, it called a method and later on got an event, without ever having called any threading code.
Here's how that played out. I've created some demo code structured in the same manner, but it's been genericized. First off I needed something for this code to do, so it will return an IEnumerable instance of DataClass. DataClass is just a data class that I can bind to a grid on a form.
I drop a DataGrid, a binding source pointed at DataClass, and a few buttons and I've got my framework done. I created DataService to handle to complexities of retrieving the data, so that in the button click event it simply calls dataService.GetDataAsync() then the DataRetrieved event fires so that the form can retrieve the data from the event args and plug it into the binding source, updating the grid.
Internally to the DataService, is where the cool stuff happens. Here's GetDataAsync()
public void GetDataAsync()
{
using (BackgroundWorker worker = new BackgroundWorker())
{
worker.DoWork += new DoWorkEventHandler(worker_DoWork);
worker.RunWorkerCompleted += new RunWorkerCompletedEventHandler(worker_RunWorkerCompleted);
worker.RunWorkerAsync();
}
}
I could have dropped BackgroundWorker onto the design surface of DataService, since I made it a component, but I decided not to so that I can show some delegate goodness. What you see here is DataService subscribing to DoWork and RunWorkerCompleted then kicking off the thread. What we've done here is pass a delegate into the event handler. DoWorkEventHandler and RunWorkerCompletedEventHandler are both predefined delegates that match a specific interface, allowing it to be passed to the event handler. The parameter to the delegates simply take a pointer to the method. If the method does not match the signature, a compile error will be thrown.
This is how we had to do it in .NET 1.0, 1.1 days, and if you subscribe to events in the designer, this method is still used, and the code is generated and placed in InitializeComponent. However, we can make it cooler.
.NET 2.0 gave us anonymous delegates, which were essentially a way of declaring an anonymous method. The reason I like this approach is because it keeps all the code related to a given task in the same place rather than spread out among several methods. This isn't always practical or the best design, but in a lot of cases it is. That code would look like this:
public void GetDataAsync()
{
using (BackgroundWorker worker = new BackgroundWorker())
{
worker.DoWork += new DoWorkEventHandler(delegate(object sender, DoWorkEventArgs e) { e.Result = GetSomeData(); });
worker.RunWorkerCompleted +=
new RunWorkerCompletedEventHandler(delegate(object sender, RunWorkerCompletedEventArgs e)
{
IEnumerable<DataClass> data = (IEnumerable<DataClass>) e.Result;
OnDataRetrieved(data);
});
worker.RunWorkerAsync();
}
}
I've taken the contents of worker_DoWork and worker_RunWorkerCompleted and moved them inline to an anonymous delegate. The signature still needs to match the delegate, and Intellisense won't help you out much here. What's important to realize is that the code will operate exactly the same way as the other code, so the code in the delegate wont actually execute until the event fires. There are several resources that explain what the compiler actually does to make this work, so I won't cover it now.
There's still some redundancy here. The compiler is smart enough to know what the signature of the delegate is, so we don't necessarily have to define it. We can actually write the same method like this:
public void GetDataAsync()
{
IEnumerable<DataClass> data = null;
using (BackgroundWorker worker = new BackgroundWorker())
{
worker.DoWork += delegate { data = GetSomeData(); };
worker.RunWorkerCompleted += delegate { OnDataRetrieved(data); };
worker.RunWorkerAsync();
}
}
Oops, I snuck in another change as well. You'll notice that data is defined as a variable in the method. No worries! The compile handles all this for you too. Again, the classes and stuff that are generated here are discussed in plenty of other places, so I'll leave the details alone for now, but it does work. What this allows us to do is to not box and unbox the data using the Result property of the event args which is of type object. Since we no longer need event args, we don't even have to specify them. The compiler knows that DoWork takes a DoWorkEventHandler, and that the anonymous delegate can fit that bill, so it allows it. The code is just about as small as it was as it was initially, but we've refactored out two event handler methods. That's pretty cool.
But I'm not done yet. We can take it one step further. In 3.5 we got Linq, and Linq gave us some pretty cool stuff, and a lot of it can be used outside of the context of Linq. Specifically I'm talking about Lambda expressions.
A Lambda expression is basically a syntax for specifying an anonymous delegate. Again, the compiler is smart enough to know the signature of the delegate, so we don't always have to type that code out. You've probably seen code like
data.Where(x => x.Beta < 100);
Since data is IEnumerable<DataClass> and Where takes a Predicate, it knows that the single parameter of the predicate should be a DataClass and the return value is a bool. Therefore this code equates to
data.Where(delegate(DataClass x)
{
return x.Beta < 100;
});
We can also use Lambda expressions for all kinds of anonymous delegates. Now we can write the GetDataAsync code like this:
public void GetDataAsync()
{
IEnumerable<DataClass> data = null;
using (BackgroundWorker worker = new BackgroundWorker())
{
worker.DoWork += ((sender, e) => data = GetSomeData());
worker.RunWorkerCompleted += ((sender, e) => OnDataRetrieved(data));
worker.RunWorkerAsync();
}
}
How cool is that?