I use Inno Setup as an installer for all my windows-based projects. Often-times I want to build the installer when I build the project from within Visual Studio but only when I build the “Release” configuration.

Here is the post-build script that will accomplish this:

c:
cd\
IF Release==$(ConfigurationName) "C:\Program Files\Inno Setup 5\Compil32.exe" /cc <PATH_TO_ISS_FILE>


batch files · inno-setup · post-build · Programming · visual studio

I’ve always wanted to write an end-of-the-year summary post that would explain some of the lessons I learned during that year. For one reason or another I’ve never done this and I figured that it was time to start. So to make up for my slacking I assembled a list of some of the lessons I’ve learned over the last 8 years.

• Never under any circumstances store a password in plain-text.
• Do not insert unfiltered strings into a query. Ever.
• Users aren’t stupid. They are clever. Like foxes. Like foxes with augmented AI Skynet brains. They will do things you would never think of in 1 x 10^1000 years.
• Develop and test on the same platform / permissions level that your app will run under. Trust me, this will save you serious future debugging time.
• And on that note: Test, test, test, test.
• Regular expressions work 90% of the time but you only really need them 10% of the time.
• If something doesn’t feel right it probably isn’t. If you can fix it fast do it, otherwise root out code smell and refactor in your down-time.
• XXXX technology isn’t always the answer. Be pragmatic. Solve problems as easily as possible. We exist to reduce and handle complexity in non-complex ways.
• Open source is a good thing.
• Contribute to or start an open source project. Extra XP and a good resume bullet.
• Did I mention test, test, test, test.
• Only re-invent what you absolutely have to. Would you rather spend a week implementing and testing your own GridView or install a commercial control in a day?
• It’s not the hours you put in, it’s what you do with them. Refactor your own development process. If you spend 1/2 a day doing something, odds are you can improve that time.
• “It works on my machine” is ok if, and only if, you are coding for your machine.
• Nobody makes bug-free software. Learn from the bugs you make now and you’ll make newer more interesting ones.
• Oh, and Test, test, test, test.

The items on the list above are definitely not things I knew coming into software development. They are all things I’ve had to learn the hard way, usually by falling completely on my face. The first two especially.

We all make mistakes, it’s part of learning. All I hope is that this list prevents someone from making the same mistakes I made so they can go on and make their own, newer, more complicated, and more interesting mistakes.

be-a-better-programmer · best practices · learning · Programming

I know exactly why I got into programming. I’m not so sure when it happened but I do know why.

I was always obsessed with understanding how things worked. I had to know. Everything had to be taken apart and then put back together, whenever my dad or mom would throw out some piece of computer hardware or other machinery I would ask to see it before they did.

Then I would retreat to my room and take whatever it was apart and see how it did what it did. Even if I didn’t really understand what was going on with whatever I was taking apart in the end it was still fun and exciting. Transformers were, of course, my favorite toys.

I think it was late 1995 / early 1996 when my dad bought me a copy of Visual Basic 4.0 at one of our local computer shows. I remember being really excited because I would finally figure out how programs like WordPerfect, xTree, Windows, and Commander Keen really worked.

Unfortunately my copy of Visual Basic never really showed me how Windows or Commander Keen worked but it kept me occupied for that whole summer and opened me up to a whole world of new things to figure out.

I know exactly why I got into programming. I’m not so sure when it happened but at least I know why.

Programming