Category Archives: Tips - Page 3

10 Ways to Learn New Things in Development

Posted by on April 1, 2008 10 comments

Expanding upon one of the topics in my post about 5 Attributes of Highly Effective Developers, I’ve been thinking of various ways to kick-start learning opportunities in my career and hobbies.

1. Read books. There are tons of books about programming–probably most of them are useless, but there are many, many gems that can greatly influence your abilities.

I still find that it’s easier and faster to find information about many topics in familiar books than to find similarly valuable information online. Read all your books to get to this point.

Books are also valuable from theory, architecture, design point of view. There just aren’t that many places on the web to get high-quality, authoritative instruction in this.

My first book, C# 4.0 How-To is now shipping! If you like tips you can use, check it out!

2. Read Code. This is something I was late to. I didn’t start reading a lot of significant code until after I had a few years of professional programming experience. I would be a better programmer if I had started earlier. I try to read some source code every week (not related to work, not my own, etc.) from an open source project. Start with programs that you use and are interested in. I started with Paint.Net and it solidified a lot of .Net program design technique for me.

Reading other people’s code shows you different ways of doing things than you might have thought of on your own.

3. Write Code - Lots of it. Fundamentally, the best way to learn something is to do it. You can’t fully internalize something until you’ve written it. This starts with something as simple as copying the code examples from tutorials and books. That’s copying by hand, not cut&paste. There’s a difference. The idea is internalize and think, not blindly copy. Look up new API calls as you go. Tweak things.

Most importantly, develop your own projects–whether they’re simple games, participation in an open source project, or a simple plug-in to a program you use.

Try to use new technologies, new techniques, new designs–do things differently. Do things better in this project than in previous ones.

This is really the core point–if you want to be a better developer than develop.

4. Talk to other developers – about specific problems you have, as well as the latest tech news from [Apple|Microsoft|Google|Other]. This not only helps you feel part of a team or a community, but exposes you to a wide variety of different ideas.

Different types of projects require different designs, coding techniques, processes and thinking.

If you work in a small team (like I do) and you don’t have access to many other people, go find some at a local user group meeting. If nothing else, participate in online forums (you’ll have to look harder for an intelligent discussion).

5. Teach others. Similar to just reading code versus writing it, teaching other people can do wonders for forcing you to learn a topic in depth.

The very idea that you’re going to have to teach a topic to someone else should force you to learn something with a far better understanding than you might otherwise. You can face questions.

If you can’t explain a concept to a 6 year-old, you don’t fully understand it. – Albert Einstein

Teaching situations are myriad: one-on-one with your office-mate, water-cooler meetings, informal weekly gatherings, learning lunches, classrooms, seminars, and more.

How about setting up a once-a-week 30 minute informal discussion among like-minded developers? Each week, someone picks a topic they want to know more about and teaches it to the others, instigating a conversation. If you knew were going to teach the group about synchronization objects, don’t you think you’d want to understand the ins and outs of critical section implementation?

6. Listen to podcasts

If you’ve got time where your brain isn’t otherwise occupied, subscribe to podcasts. My current favorite programming-related one is .Net Rocks. They also do a video screen cast called dnrTV.

These will help you keep up on the latest and greatest technologies. You can’t learn everything and podcasts are a good way to get shallow, broad knowledge about a variety of topics, from which you can do your own deep investigations.

If there are other, high-quality developer podcasts, I’d love to hear about them.

7. Read blogs

There are more blogs than people to read them, but some are extremely well-done. I’m not even going to post links to any–there are plenty of other resources out there for that. This is one of the best ways to connect to people who actually develop the software you love and use.

8. Learn a new language

If all you’ve ever done is C(++,#)/Java there are a LOT of other ways to think about computer problems. Learning a new language will change the way you think. It’s not just a different syntax–it’s fundamentally rewiring the brain. Sure, all languages get compiled down to assembler in the end, but that doesn’t mean a high level abstraction isn’t valuable.

Functional, query, and aspect-oriented languages are starting to merge with C-based languages–are you ready?

9. Learn the anti-patterns

Aside from knowing what to do, learn what not to do. Read Dailywtf.com often and take the lessons to heart if you don’t already know.

It’s all well and good to understand proper OO design, coding style, and what you should be writing, but it’s easy to get into bad habits if you’re not careful. Learning to recognize bad ideas is vital when taking charge of a project.

Wikipedia has a thorough breakdown of many common anti-patterns,

10. Be Humble

Learning means:

  • Replacing faulty knowledge with better knowledge
  • Adding knowledge that you do not already have

There’s no way to learn until you admit you have some deficiencies. It all comes back to humility, doesn’t it? If you ever start thinking you know everything you need to, you’re in trouble. True learning is about hungrily seeking after knowledge and internalizing it. It takes lots effort. We all know this in theory, but we have to be constantly reminded.

My first book, C# 4.0 How-To is now shipping! If you like tips you can use, check it out!

Popularity: 27% [?]

How to file good bug reports (from Frank Kelly)

Posted by on March 19, 2008 No comments

This is an issue I run into constantly at my job.

Frank Kelly wrote up a good summary of some items. They’re simple, easy to understand, easy to follow, even for non-programmers. ;)

In fact, I’m sending this link out to everyone in my group here at work.

Technorati Tags: ,,

Popularity: 4% [?]

Never make assumptions about performance

Posted by on March 17, 2008 No comments

The importance of measuring performance changes is a topic that has been covered by others smarter and more experienced than me, but I have a recent simple tale.

I’ve simplified the code quite a bit in order to demonstrate the issue. Suppose I have a wrapper around an image (it has many more attributes):

   1: class Picture
   2: {
   3:     Image _image;
   4:     string _path;
   5: 
   6:     public Image Photo
   7:     {
   8:         get
   9:         {
  10:             if (_image==null && !string.IsNullOrEmpty(_path))
  11:             {
  12:                 _image = Bitmap.FromFile(_path);
  13:             }
  14:             return _image;
  15:         }
  16:     }
  17: 
  18: }

I had this and a view that loading about 2,700 of these into a customized ListView control at program startup. On a cold start (where none of the pictures were in the disk’s cache), it would take 27 seconds. Unacceptable.

What to do?

My first thought was to load the pictures asynchronously. I wrapped Bitmap.FromFile() into a function and called it asynchronously. When it was done, it fired an event that percolated up to the top.

Well, I spent about 30 minutes implementing that and ran it–horrible. The list showed up immediately, but it was unusable. The problem? Dumping 2,700 items into the ThreadPool queue is a problem. It doesn’t create 2,700 threads, but it causes enough problems to not be a viable option.

Asynchronicity is still the answer, though. But it’s at a different level. Instead of loading the individual images asynchronously, I skipped loading the images when creating the list control and instead launched a thread to load all the images and update them when done. The list loads in under a second, and the pictures show up little by little after that.

Measure, measure, measure. And pay attention.

Technorati Tags: ,,

Popularity: 5% [?]

6 Ways to Increase Your Confidence As You Code

Posted by on March 6, 2008 5 comments

One of the key requirements for being able to reliably update software is the confidence that the changes you are making are safe. The amount of confidence required increases with the complexity of the system.

In my day job I work on a real-time messaging system that can have very, very little downtime. As the service grows and sees more traffic, the amount of downtime shrinks. We start to worry now if upgrades take longer than 5 minutes. (It’s almost to the point where we’ll need redundant systems in order to do maintenance).

To upgrade this software, I have to have an awful lot of confidence in the code changes made. Sometimes that confidence varies.

What to do to gain confidence:

1. Consistent process

Having a set of rules to follow is a fundamental requirement of good software engineering. I’m not going to discuss what the process should be, but you should have one that works well.

Why is this important?

Programmers like order. We like well-defined problems where we can see the end from the beginning. We don’t like haziness, indeterminism, or too many choices.

A process nails down the unknowns–it tells you very specifically what the next thing to do is. A good process leaves no room for doubt.

A good development, testing, and deployment process is the first step to building confidence in what you’re doing.

For my messaging system example, here’s a short summary of what our upgrade process is. We didn’t just come up with it–it evolved as our business grew and the requirements grew with it.

  1. All unit and integration tests pass (we have about 2200 automated tests for this that can run in about 4 minutes)
  2. We’ve run it on staging server for a few weeks with no issues.
  3. All new features have been tested on the staging server
  4. Formal change document has been submitted and approved.
  5. Formal test results documented.
  6. Previous version backed up.
  7. Perform upgrade
  8. Monitor system (including custom automated monitoring tools)

At any point, I know where we are in the process and what needs to be done next. Sure, there may be details within these steps that require thought and creativity, but the process guides it all and makes us more confident that we’re not performing ad-hoc operations.

2. Unit Testing

There are other types of testing, but it all starts at the unit level, with simple tests that exercise your code line by line, function by function, feature by feature. I recently wrote a few thoughts about unit testing. Unit testing is where you can see the overall wellness of your code–you want that green bar!

Without unit testing, how do you know the code you’re writing is doing what it should? do you just run it and push it through its paces? This is highly inefficient for most types of code. You’ll run out of steam before you start getting close to edge cases.

The fact is that automated unit tests are a baseline for confidence in your code. You need to be able demonstrate time and again that your code performs well.

This all presupposes that you are writing good unit tests. If you’re not sure, start studying. I don’t buy the arguments about lulling developers into a false sense of security–sure, that can happen, but having good developers who understand this is a prerequisite.

If you’re not unit testing–what is your basis for confidence in your code?

3. Code Coverage

Code coverage goes hand-in-hand with unit testing as a good way to automatically discover what areas of your program are in need of more testing. I’ve found that one of the biggest barriers to unit testing a large C++ application we have is that we have no way of easily measuring test coverage. If we had time, we could definitely to the analysis ourselves, or we could spend a lot of money to get a C++ instrumentation profiler, but these are slow and very tedious to use in my experience.

In .Net, use the tools to your advantage.

The psychological benefits of seeing 75-, 90-, 95-, even 100-percent coverage are immense. You know that every line of the program has at least been touched.

Of course, most code coverage tools analyze line coverage, not path coverage. Combine  complexity analysis with code coverage to determine which functionality should probably have better testing. There are plenty of free and commercial tools that will give you cyclomatic complexity, among other metrics.

Use other analysis tools like FxCop to make sure your other ducks are in a row. It can find easy-to-overlook problems like not validating arguments of public methods, which can then lead to more unit tests and more coverage to achieve.

4. Automation

Take yourself out of the equation as much as possible. The point of a process is to be repeatable–it’s like automating yourself. Not only should unit testing be automated (thankfully, most testing frameworks handle this easily), but so should coverage and quality analyses.

What about deployment? Automate it. Documentation generation? CD master creation? Web upload? E-mail notification? Automate them all. Production builds should be invoked with a single command.

Working on boring, repeatable code? Automate it with code-gen.

The bottom line is: Don’t waste your brain cells on stuff that is highly repeatable, especially when it is prone to mistakes.

5. Code Review

Last week, a rather serious bug was discovered in some of our software (not released yet, thankfully, but close). The bug was mine, and I knew exactly what the problem was, but instead of designing a solution by myself, I brought a co-worker into the discussion just to bounce ideas off of. He had great suggestions, and made me think of things I might not necessarily have thought of on my own. We both went over the code and came to a solution that was simple and acceptable to both of us. The confidence level was much higher with this than it would have been otherwise.

This story is repeated daily by programmers throughout the world. Code review is a practice based on the simple notion that there is no one person smart enough to get it correct the first time.

Even if you’re working alone, which I often do, it pays huge dividends to regularly review your code with an eye for finding trouble. If you see any weakness at all, don’t ignore it–fix it. If you’re reviewing your own code, it’s a good idea to wait a bit after the time you wrote it. This gives your brain a chance to forget a little bit about it. Then, if you find you can’t understand it anymore, it’s either too complicated, or (if it fundamentally really is complicated) you need better comments.

Reviewing with other people has more benefit, however. Not everybody thinks the same way about problems. People have different experience, different expertise and focus, and you can’t take advantage of that if you don’t let them teach you. Even if the other people have less expertise than you, it is still beneficial (assuming they have some basic competency that they can bring to the discussion).

Once you let other people tear into your code (nicely, I hope), your confidence can be higher because you can add the confidence other people have in it (once your problems are corrected, of course!)

6. Repeatable Experiences

In the end, one of the best ways to increase your confidence in yourself, your code, and your practices is to have the evidence of repeated experiences behind you. You’re always learning, and that learning contributes to improvements in processes, testing, and your personal coding practices. Once you learn what works, especially during tricky upgrades, you can go into the next trial with increased confidence that you’re doing something right.

Have any other ideas on increasing confidence? Leave them in the comments!

Technorati Tags: ,,

Popularity: 16% [?]

Tip: Easily Automating use of WaitCursor

Posted by on February 22, 2008 1 comment

This is really simple and probably common, but it’s a useful tip anyway.

Say you need to set a form’s cursor to the wait cursor while you accomplish something.

You would do something like this:

this.Cursor = Cursors.WaitCursor;
 
//do something
 
this.Cursor = Cursors.Default;

Of course, what if “do something” throws an exception? Then your cursor won’t be set back to the default.

So let’s wrap it in try-finally.

try
{
    this.Cursor = Cursors.WaitCursor;
    //do something
}
finally
{
    this.Cursor = Cursors.Default;
}

Better, but that’s a lot of wrapping around a simple operation. Notice, that the try-finally is exactly the pattern that using is. Why not wrap this functionality into a simple to use class that handles the cursor reset automatically?

internal class WaitCursor : IDisposable
{
    private Control _control = null;
    public WaitCursor(Control control)
    {
        _control = control;
        _control.Cursor = Cursors.WaitCursor;
    }
    public void Dispose()
    {
        _control.Cursor = Cursors.Default;
    }
}

And to use it in a form is simple:

using (new WaitCursor(this))
{
    //do work
}

Of course, you could easily add functionality like restoring the previous cursor instead of always the default, handling exceptions, make it thread-aware so it uses Invoke if necessary, better error-handling, etc.

Technorati Tags: ,,,

Popularity: 7% [?]

.Net Reflector

Posted by on February 13, 2008 No comments

Lutz Roeder’s .Net Reflector has been discussed on many blogs before, but I want to give it an additional plug. I recently had to emulate some C# serial-port code in our C++ app. The .Net SerialPort class is great, easy-to-use, and works well. Unfortunately, we’re using a C++ serial port library that does not support all the possible features. Fortunately, we have the source code and can easily extend it. Unfortunately, I’m not too familiar with serial port programming, and the .Net functionality does not all obviously map to the Win32 API in every respect.

Enter Reflector. It was trivial to poke into the .Net assemblies and see what the SerialPort class was doing under the covers and then use the correct Win32 functionality in our app.

There are also a ton of plugins available.

Technorati Tags: ,,,

Popularity: 6% [?]

Fighting Brain Rot

Posted by on February 7, 2008 No comments

Alex Shalman has a great post at zenhabits about how to avoid letting your brain decay into apathy and atrophy. It’s a great call to action, to find ways of self-improvement. I think the behaviors listed here dovetail very nicely with the attributes of highly effective programmers.

By continuing to do as we always have, the quality of results will be the same as always. Only when we step out of our comfort zones, and push ourselves to improve, will we gain useful new experiences, knowledge, and ideas.

I think the methods of expanding the mind are highly applicable to software developers. I just have a little bit of commentary on each one.

11. Reading – I think I would have put this at #1. It’s the easiest way of cramming information into your skull. It’s the most efficient method of information transfer, and that’s our bread-and-butter as programmers, so we should become expert at it.

10. Writing – We write code for a living, not necessarily prose, but communication is key to so many areas in life, that learning how to write effectively is critical to most careers. For myself, I definitely find it easier to express myself in writing than in-person. Doing this well becomes a critical ability.

9. Puzzles – Developing a large software project is in many ways like an enormous software project. It’s so large, though, that we can’t comprehend it all at the same time. But practicing other types of puzzles can train our brains to look for patterns and to develop new, creative ways of thinking. My favorite offline puzzle is the New York Times Crossword, but I enjoy the occasional sudoku.

8. Mathematics – a good understanding of boolean logic, prepositional calculus, discrete mathematics, asymptotic notation, etc. are great things for developers to have. A general understanding of algebra, calculus, trigonometry, and statistics also comes in handy more-than-occasionally. Another valuable idea that comes out of mathematical understanding is the idea of precision in thought and rigorousness in testing or understanding your software–think loop invariants.

7. Painting – I am definitely not an artist by any means, but the underlying principle of some kind of artistic self-expression is important. The creative side of your brain must be regularly exercised. For me, this is in the form of building Legos.

6. Cooking – I initially found this to be a peculiar choice, but it makes more sense when I ponder it. Cooking is at once creative and precise. Not only does it use all the senses, but it requires you to think on your feet and be very, very organized and detail oriented, especially when you start cooking for more people. Planning and execution both become huge issues.

5. Music – I wholeheartedly agree, and I’ll even go out on a limb and say that you need to listen to lots of genres of music, especially classical. Why classical? Because it exhibits more musical complexity than all others. It doesn’t minimize various musical aspects (variation, melody, harmony, tempo, timbre, i.e.) for the sake of a single one (i.e., rhythm).

4.Poetry – I used to write fiction and poetry in high school and earlier, but it’s been quite a while. I do remember it being quite the exercise to compose sonnets–it forces you to be extremely creative with grammar, syntax, meaning, vocabulary, and more.

3. Meditate – This is an art I need to learn more about. I find I do this automatically in some situations where I’m not otherwise preoccupied (the shower), and I can solve a question I’ve had. I find that NOT doing something is as important as doing something in many cases. When I’m faced with an especially thorny problem at work, it really helps to just write down my thoughts about it and let it sit for a few days while I think about it in my off moments. Most of the time, I can come back and have a better solution than if I had started right away.

2. Learn a language -

A language that doesn’t affect the way you think about programming is not worth knowing. – Alan Perlis

The original article obviously means foreign spoken languages, which I definitely agree with. I speak Italian, and the insights it’s given into my own native English are quite valuable. If you’re a careful student, knowing two languages definitely forces you to think about the meaning of words and constructs. It’s much harder to take things for granted.

I think the same is true of programming languages–knowing more than one helps your mind think about a problem in different ways. Once you understand functional programming, for example, you will never look at programming the same way again.

1. Question Everything – This is analogous to love of learning in my Effective Programmers essay. It’s not being a jerk and denigrating everybody else’s ideas. It’s asking yourself continual “Why” questions in order to understand the issue.

Technorati Tags: ,,,,

Popularity: 7% [?]

Solving "Unexpected Store Error" in Exchange

Posted by on January 30, 2008 No comments

Getting a weird COM Exception with the cryptic ID 0x8055001E?

We’ve been struggling with this problem for over a year now, and we finally have a solution.

We have some critical code that is contacting Exchange server via COM Interop and CDOEX.DLL to read some inboxes and process e-mails. About once a month or so, we get this error:

System.Runtime.InteropServices.COMException (0x8055001E): Unexpected
store error: %1!d! (0x%1!8.8x!)
   at ADODB.RecordsetClass.Open(Object Source, Object
ActiveConnection, CursorTypeEnum CursorType, LockTypeEnum LockType,
Int32 Options)
   at MessageService.Exchange.ExchangeClient.Connect(String folderUrl,
String userId, String password, Boolean useHttp)

After this point, restarting our software does not help. The only recourse is to restart the Exchange store completely. Did I mention that our software needs to run 24/7/365 with no downtime (a few minutes here and there are acceptable)?

So about once a month, I get a message on my phone, I log into the server, reboot Exchange, and all is well.

Searching on Google revealed nothing at all. Until recently.

I now believe the problem was we were checking two e-mail accounts back-to-back, in a loop like this (highly simplified):

while (running)
{
    CheckAccount1();
    CheckACcount2();
    Thread.Sleep(60000);
}

Apparently, there is some bug in the CDO COM components’ code that will cause errors if you reconnect too fast. Occasionally, the Exchange code must have completed so quickly that it didn’t provide enough time for the COM components to clean up properly before the next solution attempt. Solution?

while (running)
{
    CheckAccount1();
    Thread.Sleep(5000);
    CheckAccount2();
    Thread.Sleep(60000);
}

We implemented that change on a staging server that was also experiencing this problem and haven’t had a single reoccurrence since. The fix will be going into production very soon. No more 2AM alerts!

Popularity: 6% [?]

20 Things to do when the Internet goes down

Posted by on December 14, 2007 No comments

Even if the Internet connection goes out, your computer does not become a dumb brick. There were days these last few days where I didn’t bother turning it on. Then I realized all the things I could still do.

(My home Internet connection finally came back this morning. I’m bit upset that they didn’t figure it out earlier. It turned out that the first technician grossly misdiagnosed the problem. He put in an order for a new drop to be put in. Turned out it was just a broken modem. Why didn’t they try that earlier? Worse, why didn’t I think of it earlier. To be honest, I did think of it, but didn’t push it. Now I just need to get my money back from Comcast.)

Without further ado, here’s my suggestions for what to do when the Internet goes out:

On the computer:

  1. Organize photos in Picasa – I have nearly 6,000 photos on my computer. Many of them need to be deleted, organized, tagged, labeled, e-mailed, etc. (Yes, e-mailed–I can queue them in Outlook until the connection comes back).
  2. Organize My Documents – I’ve let My Documents folder get very messy. Lots of files that don’t need to be there anymore. Others need to be filed, or re-filed.
  3. Organize e-mail – I’ve got hundreds of folders in Outlook. I’ve tried to keep my Inbox empty and put things into @Action, @Someday, or @WaitingFor folders before they find a permanent home, but sometimes it still gets out of hand.
  4. Organize and fill in information in Windows Media Player. I still have music tagged with the wrong genre…
  5. Program. I’ve got two major programming projects I’m working on. They don’t depend on the Internet. The Internet is NICE if you need to learn something, but there’s always plenty of stuff to do that doesn’t require it. Write unit tests, run code coverage, design graphics, do all the other stuff if you must.
  6. Write e-mails to family. Long ones. Your mom will thank you.
  7. Catch up on podcasts. I got through ten episodes of Ask a Ninja, and nearly all backlogged podcasts. Now I’ll have a flood when I sync tonight.
  8. Write blog entries. I use Windows Live Writer. I should have done more of this.
  9. Play a game.
  10. Better, write a game.
  11. Setup appointments and events in Outlook for the next year.
  12. Read some classic programming texts.
  13. General computer maintenance. Defrag your disk, delete temp files, delete old installation files you haven’t used in 5 years (yes, I have some of those…). Use DiskSlicer to find where your space is going.
  14. Do long-avoided projects. I have approximately 20 hours of audio I need to edit and split into tracks. I’ve been putting it off for a very long time.

Off the Computer:

  1. Practice the piano.
  2. Read books. I’ve just started Cryptonomicon by Neal Stephenson. Very good, so far. Go buy it. If you’re a geek, you’ll like it. How can you not love a 2 page diversion into the mathematics of when a bike chain will interfere with a broken spoke and fall off? Other than the geekiness, it’s a good story.
  3. Learn to cook a new dish.
  4. Do crosswords.
  5. Exercise.
  6. Relax.

Or just go to the library and use the Internet. I only did this a few times, despite it being within walking distance from where I live.

Technorati Tags: ,,,,,,

Popularity: 6% [?]

Tip: Mouse back and forward work in Visual Studio 2005 too

Posted by on November 9, 2007 1 comment

You know how you can use the extra mouse buttons to move back and forward in Internet Explorer?

The same shortcuts work in Visual Studio. Suppose you right-click on a function call, and select Go To Definition. Once you’re done looking at the definition, hit the back button on your mouse: You’re taken right back to where you came from!

(The keyboard equivalents are Ctrl+ – and Ctrl+Shift+ -)

Technorati Tags:

Popularity: 5% [?]