jp.hamilton

Visual Studio Nirvana

1. Install ReSharper 4.0...of course
2. Install new theme. Live a little. My personal favorite is Ragnarok Blue.
3. Remove every toolbar button that you don't use. That should give you about 4 or 5.
4. Learn the keyboard shortcuts for those 5 toolbar buttons and remove the buttons left over from Step #3.
5. Learn to use ReSharper to navigate around your project:

   CTRL+SHIFT+N	Go to file
   CTRL+N	Go to type
   CTRL+F12	Go to member
   CTRL+E	Recent files list

   The nice thing about the first three is that ReSharper recognizes camel casing. That is, if I enter FB, it will locate FormBuild, FastBreak, FillyBuster, etc.

6. Unpin Solution Explorer, Properties, Team Explorer...you know, all that stuff that usually takes up real estate on the right side of Visual Studio.
7. CTRL+ALT+ENTER to enter full screen. At first it's kind of like when Luke put on the blind fold and  tried to hit the little floating thingy with his lightsaber....but without the possibility of killing everyone in the room...and you get used to it really quickly.
8. Take note of everywhere you use a context menu and try to replace that with a keyboard shortcut. By this point you might notice that you have developed some really weird habits. For me, after I took the Save buttons off the toolbar, I realized that I randomly seem to want to click Save on the toolbar all the time. So, now I just do CTRL+SHIFT+S to Save All.
9. If you find yourself doing repetitive tasks, record a macro and assign it to a hot key. If it's just a one shot need, use a temporary macro. ReSharper takes over the shortcuts that Visual Studio uses for temporary macros, so I have remapped ALT+R (to Record temporary macro) and ALT+P (to Playback temporary macro)

Well, that's all I have. If you have any more tips, please tell me about them.

Houston ALT.NET Geek Dinner

If you live in Houston or somewhere close, then come join us for the first ALT.NET gathering in Houston. Pizza, beer (or diet coke if you prefer) and good discussions await. Hopefully, we can start organizing an open-spaces conference in Houston sometime this year.

 When:
5/27/2008 @ 7:00 PM  (That's this next one, the day after Memorial Day)

Where:
Star Pizza
2111 Norfolk
Houston, TX 77098
(google map)

Good Books with Bad Reviews = Fun Times!

I love going to Amazon and searching for an awesome book just so I can read the bad reviews and lament on the sad state of the world. I am continually amazed at the idiocy I see in the world, and apparently I have some morbid fascination with observing it, taking notes, and commenting on it.

I say "idiocy", but in this case I am not sure if the term is concise. Is there a word for "people who dismiss something as worthless because they are completely clueless"? There might be, but I don't want to put those words here, because employers read blogs nowadays.

Anyway, I was over at Amazon today and I thought, "Let's see what the bad reviews say about The Pragmatic Programmer. I found this little gem attached to a 1 star review:

"I like to consider myself a master craftsman. My craft is that of programming. I live for programming. Programming is rarely from my thoughts. I am constantly thinking of ways to improve my craft. Learn a new skill. Develop a new tool...I don't know how to make an object oriented design."

Ha ha ha.

So next, I thought, "I'll head over to one of my favorite books of all time and read the bad reviews there". This book is skinny and concise; something that is so lacking in the world of programming books today. I went over to The C Programming Language, to take a peek. Wow, what gold mine:

"this book is nothing but regurge from other c book"

Say that with a Russian accent and tell me that is not hilarious. That is the funniest one yet, seeing how this was the first book about C ever written...by one of the creators of the language no less.

Next, we get this (and I swear I am not making this up):

"This book was really bad! There were no examples at all! I couldn't understand a single page form author. It is obvious that Kenighan has no idea what he's talking about. The book should be titled C The Hardway... I prefer and recommend C For Dummies"

Is this for real, man?

Testing After The Fact Still Influences Design

In the past, I have stated that backfilling unit tests, that is, writing tests for existing code, is not really doing TDD. I think to some degree I was wrong. I said this because of a hasty observation. If code already exists, then it has been "designed", hence, my tests are just making sure that the code works.

This is not really true. Today, I observed that the act of writing a test helped me find several potential problems in an existing method. Also, I found the method somewhat difficult to test. By difficult, I mean that I found myself setting up a lot of pre-conditions in order to get the test to run. This was my clue that some refactoring was in order. Once I was finished, I was left with something far superior to what I had started out with.

Support Your Local Roasters

You know, when I am in the mood for a cup of boiling hot, coffee-flavored mediocrity, I head over to Starbucks. In the true American spirit, here is one more company that decided to try and get people to pay premium prices for less-than-premium goods. I remember enjoying their coffee immensely at one point in time, but it's been so long, I don't remember when that was exactly. But hey, we gotta keep the stockholders happy, right?

I am probably in the minority here, but I am a real coffee drinker. I drink my coffee black. I like coffee for the taste of coffee. And I look down my nose at everyone who doesn't. Keep your flavoring and milk and sugar and your other masking agents.

I want good coffee and I am willing pay for it. I don't want over-priced mediocre coffee. I am not willing to pay for that anymore. And truthfully, if I can do business with a company that doesn't have stockholders, I will do it. Stockholders seem to have the strangest effect on companies. Even companies with the best intentions.

So, recently, I have decided to buy my coffee from local roasters only. Yes, I have to pay sales tax. And yes, it is more expensive. In fact, I just paid $25 for 2 lbs. of coffee. But you know what? It was worth every penny. I can't remember when I have had such a good cup of coffee. I am working from home today and I am just starting my second pot. It's that good.

So, today, I salute Mozart's Coffee in Austin, TX for their El Gato Negro blend. Thank you for giving me the best cup of coffee I have had this year. I will be ordering from you again, no doubt about it.

But probably not too soon...

Because Texas has a bunch of roasters and I want to try them all. I'm sure your state has a bunch of good roasters, too. Try them out. Support them. Corporate Coffee Sucks!

I don't have a complete list of roasters for Texas yet, but I am going to start putting one together, so keep your eyes peeled. In the meantime, head over to Mozart's Coffee and give yourself a righteous cup!

TDD is not Micro- vs. Macro-Design

I was just over at InfoQ where I saw an an interview with Cedric Beust about designing for testability. It was a pretty balanced interview and some good points were made. Even though he is skeptical of TDD, he does do it. One thing that was said, which caught my attention, was his claim that TDD is that it is all about the "micro" and ignores the "macro" when it comes to design. He states that TDD is probably really good for junior developers, but that more experienced developers should be allowed to write more code without doing TDD. Experienced developers, he claims, have good intuitions, and good ideas about how things should fit together. The guy is really smart and works for Google, so who am I right?

But I look at it like this. If I am going to go somewhere I will take a well-known route so I won't get lost. If I were to start a typical "enterprise" application right now, chances are good that I would use MVP, Repository, Factory, and a slew of other patterns which are familiar to me.  Yes, I would use TDD along the way (because there is more than one way to implement any of these design patterns), but I would know the direction in which I was heading. I would not suddenly arrive at MVP because I had been doing TDD. I would know that up front.  I already know the pattern allows me to write testable code.

As for intuition, I find that if I get a surge of ideas, I don't necessarily need to forge ahead and express them in code. I can write them down as comments in one of my test files or some known location. Or, here's a crazy idea: I can write a bunch of code to explore an idea, and then throw it all away. It's like sending out a scout before sending in the cavalry. When all is said and done, I can get back to the immediate task at hand, which may be as something as simple as implementing a property on a class in order to get a passing test.

The point is, I don't have to give up the creative process of software development. I can still experience that and do TDD at the same time.

I fully admit that maybe it's me who does not understand TDD in it's strictest sense. Maybe the way I am doing it is just not proper, but I just don't see how TDD forces me to do anything. I don't get the sense that I have given up anything by doing TDD.

TDD Mindfulness

Consider this a "report from the field" in regards to TDD. I have been actively doing TDD for awhile now and my experience so far is that it doesn't quite play out for me like it does for the folks in the TDD books and articles. Don't get me wrong. I love TDD and I am actively trying to get better and better at doing it, but I am experiencing a few trials and tribulations. It's nothing major, but I think it is worth noting because there is value in letting people know "they are not the only one".

I think my biggest problem is that I get ahead of myself. I will write a test, it will fail. I will write code to make the test pass...and just keep on writing code. Suddenly, I am at a point where I am not doing TDD anymore, but instead  backfilling unit tests. Or not. There is a difference. Writing unit tests is not TDD because at this point my code has been "designed". I am just writing tests to validate that it is working. The tests are no longer driving my design.

I think I can take a lesson from the Zen masters here and bring a little mindfulness to the situation. I can just stop what I am doing (because what I am doing is not ideal), and just start doing TDD again. It's okay. Just because I wasn't doing TDD before, doesn't mean I can't start doing it now. I can let the elaborate structures and pathways that I have let my mind build up go, like so much leaves in the wind. There is no need for me to hold on to them. In the end, it's just code, the most malleable substance in the world.

I have seen people attempt to do TDD and then stop because they don't think they can do it perfectly. Or they get ahead of themselves and exclaim that they do not have time for it. Or that since they have written this chunk of code over here without TDD, what's the point?

TDD does not have to be an all or nothing experience. At any time when I notice I am not doing it, I can make the conscious decision to start up again. For me, it comes down to this: I am looking too far into the future when I need to be in the moment. The future is nebulous. There is some kind of repository-thingy there that uses NHibernate for persistence. I just know there is going to be a service tier of some sort there. How exactly do I know that? More importantly, why do I have to know that right now? The present moment, on the other hand, is so much more concise. Here, we find a single property that needs to return a simple integer.

Elegant VB.NET: Is it Even Possible?

I doubt it, but since I am stuck on a 2 year long VB.NET project I am sure going to try. If you can't already tell, I really dislike VB. No amount of convincing is going to change my mind. I am not going to write about why I dislike VB and why I think language X is better. I want to move beyond that. I will say this before moving on, however, that this is not contempt prior to investigation. I have worked with it for years, but not by choice. Back in the 90's my preference was always C++, but here in Houston all of jobs always seemed to be VB. Even now it is the albatross around my neck. All I can say is thank goodness that ReSharper kind of almost nearly somewhat supports VB.

Since I am stuck with VB, I often find myself wondering, "Is there any way to make it look good?" I am of the opinion that good code, looks good. Consider code written using the arrow pattern. It doesn't look good. I'm not saying that all code that looks good is good, but I do think that all good code looks good. Thus, I have been making a few mental notes regarding VB and making it look better. Generally, my stance is that terse is good. This seems to be at odds with the beliefs of many VB programmers who feel that the more toothy the code is the better it is. Need something new, well hell, let's add a new keyword. Anyway, I digress. Here are a few ideas I have come up with so far:

1. Lots o' Whitespace
2. Getting DRY Using With Blocks
3. Using Implicit Variable Declarations
4. Using Extension Methods to Bypass Language Cruft
5. Think LINQ 

Note: I pulled most of the sample code from a download on MSDN called 101 Samples for Visual Basic 2005, which for all intents and purposes looks like some form of digital herpes.

 

1. Lots o' Whitespace

VB just looks better with a little whitespace injected into it. Consider this diddy:

Private Sub browseButton_Click(ByVal sender As Object, ByVal e As EventArgs) Handles browseButton.Click
    ' Provide a file dialog for browsing for the sound file.
    Dim openFileDialog1 As New OpenFileDialog()
    openFileDialog1.InitialDirectory = "c:\\windows\\media"
    openFileDialog1.Filter = "WAV files (*.wav)|*.wav"
    openFileDialog1.FilterIndex = 1
    openFileDialog1.RestoreDirectory = True
    If (openFileDialog1.ShowDialog() = Windows.Forms.DialogResult.OK) Then
        fileName = openFileDialog1.FileName
        soundFileNameTextBox.Text = fileName
    End If
End Sub

By gosh, we have undeclared variables and who-knows-what packed into there. Adding a little whitespace makes it a little more readable (but far from perfect). My two rules for whitespace are:

1. Blank likes between each block (Classes, Methods, If/Then, While/End While, etc.)
2. The inside of a block should have whitespace before and after everything inside (except if the block contains one line of code)

So, now we have this:

Private Sub browseButton_Click(ByVal sender As Object, ByVal e As EventArgs) Handles browseButton.Click
    
    ' Provide a file dialog for browsing for the sound file.
    Dim openFileDialog1 As New OpenFileDialog()
    
    openFileDialog1.InitialDirectory = "c:\\windows\\media"
    openFileDialog1.Filter = "WAV files (*.wav)|*.wav"
    openFileDialog1.FilterIndex = 1
    openFileDialog1.RestoreDirectory = True
    
    If (openFileDialog1.ShowDialog() = Windows.Forms.DialogResult.OK) Then

        fileName = openFileDialog1.FileName
        soundFileNameTextBox.Text = fileName

    End If
    
End Sub

Ahhh, now we can breathe a little easier...

2. Get DRY Using With Blocks

You can reduce a lot of noise in VB code using With blocks. After applying this to the previous example, notice how we don't even need to use any temp variables (declared or otherwise...that's sarcasm):

Private Sub browseButton_Click(ByVal sender As Object, ByVal e As EventArgs) Handles browseButton.Click
    
    ' Provide a file dialog for browsing for the sound file.
    With New OpenFileDialog()
    
        .InitialDirectory = "c:\\windows\\media"
        .Filter = "WAV files (*.wav)|*.wav"
        .FilterIndex = 1
        .RestoreDirectory = True
            
        If .ShowDialog() = DialogResult.OK Then
            soundFileNameTextBox.Text = .FileName
        End If
    
    End With
    
End Sub

3. Use Implicit Variable Declarations

Here's another way to stay DRY. With VB 9 comes implicit variable declaration. Use it (and also Import your namespaces please). Instead of this...

Public Sub AsynchronousListenerCallback(ByVal result As IAsyncResult)
    Try
        Dim listener As HttpListener = CType(result.AsyncState, HttpListener)
        Dim context As HttpListenerContext = listener.EndGetContext(result)
        Dim request As HttpListenerRequest = context.Request
        Dim response As HttpListenerResponse = context.Response
        Dim responseString As String = "some html string goes here"
        Dim buffer As Byte() = System.Text.Encoding.UTF8.GetBytes(responseString)
        response.ContentLength64 = buffer.Length
        response.ContentType = "text/html"
        Dim output As System.IO.Stream = response.OutputStream
        output.Write(buffer, 0, buffer.Length)
        output.Flush()
        output.Close()
    Catch ex As Exception
        Application.Exit()
    End Try
End Sub

...swap the old skool casting "operators", put in some With blocks and use implicit declarations:

Public Sub AsynchronousListenerCallback2(ByVal result As IAsyncResult)

    Try

        Dim listener = DirectCast(result.AsyncState, HttpListener)
        Dim context = listener.EndGetContext(result)
        Dim response = context.Response
        Dim responseString = "some html string goes here"
        Dim buffer = Encoding.UTF8.GetBytes(responseString)

        With response

            .ContentLength64 = buffer.Length
            .ContentType = "text/html"

            With .OutputStream

                .Write(buffer, 0, buffer.Length)
                .Flush()
                .Close()

            End With

        End With

    Catch ex As Exception
        Application.Exit()
    End Try

End Sub

4. Using Extension Methods to Bypass Language Cruft

Speaking of casting. I really dislike how casting is done in VB. You have the old way using CType, CInt, CStr, etc. And you have the new way(s): TryCast and DirectCast. I think that by mixing an extension method with a little generics, we can come up with something that looks much better:

' ObjectExtensions.vb
Imports System.Runtime.CompilerServices

Module ObjectExtensions

    <Extension()> _
    Public Function AsType(Of T As {Class})(ByVal obj As Object) As T
        Return TryCast(obj, T)
    End Function

End Module

This allows us to do casting like this:

Private Sub Form1_Load(ByVal sender As Object, ByVal e As EventArgs) Handles MyBase.Load

    Dim form = sender.AsType(Of Form)()

End Sub

This is the best of both worlds, really, because it's consistant and it appeases the "I like my code to have lots of keywords that read like English" crowd.

5. Think LINQ

LINQ is a great way to compress VB code into something that is more readable and at the same time more succinct. Here is a very simple example:

Public Sub ProcessNewHires(ByVal employees As IEnumerable(Of Employee))

    For Each e As Employee In employees

        If e.HireDate > DateTime.Now.AddDays(-30) Then
            ProcessEmployee(e)
        End If

    Next

End Sub

It is quite common to iterate collections and retrieve objects from them that meet a certain criteria. I think LINQ is useful in this scenario because it puts all the conditions in one place. The above sample can be rewritten like this (note: For Each variables can be used implicitly, too):

Public Sub ProcessNewHires(ByVal employees As IEnumerable(Of Employee))

    Dim newHires = From e In employees Where e.HireDate > DateTime.Now.AddDays(-30)

    For Each e In newHires
        ProcessEmployee(e)
    Next

End Sub

Conclusion

Ok, I know that only listing 5 things is lame, but the fact is, VB tires me out. I have several more things that I will discuss in later posts. For now, I think this is a good start.