Over the past month, I have been helping a client establish a solid and reliable environment for team development. To be honest, I'd heard stories about poor development environments, but it was just theory and for all I knew, it could have been "Straw man" type argument meant to demonstrate the importance of certain development practices. You couldn't actually be doing team development without source code, right?!?

Well, I can now say that it is possible - I've seen it with my own eyes. The good news is that they were fully aware of the problems, but when you're heads down day in and day out fixing issues and developing features, it's tough to get your head above water and get a few things in place - even if it will make life easier in the long run.

At some point, they knew they needed some better practices, but didn't have the time to put it together themselves, so I was tasked to help them out. In the course of just a few hours, we were able to get source control and issue tracking in place. This included importing their source, and a brief training on the basics of checking in and checking out.

The project is still on-going, and we have a few more things that we want to do, but this whole process got me thinking about what I consider to be the "no brainers" of software development - the things that you use on every project that you just take for granted. Of course, this reminded of a post by Russell Ball where he listed out his seven essential practices.

For me, the absolute, bare minimum I expect on projects I work on are source control, issue tracking and continuous integration. There are other niceties, but without those three things, I'd rather not work on the project. I feel so strongly about those three that I ensure that even for personal projects, I have all three in place. Sometimes for personal projects, issue tracking may be as simple as a wiki, but the point is that I have something. CI is such a critical piece to me that I've implemented it on projects in my spare time - and I usually end up saving time down the line because deployments are easier and I know the code at least builds at all time (or why it doesn't!).

So, what are your absolute bare minimums before you'll say that you'd rather sit and be idle then develop in those conditions?

The other day, I received a comment on my blog that was completely unrelated to the post. It happens all the time, and I usually use it as a judge of what my PageRank is - I could tell when it jumped recently because the flood of comment spam increased tremendously.

But this time, it was different. It was written from an actual person - valid email and all. And it linked to an actual company. So I decided to email the guy. I've removed identifiable pieces, but it's reprinted below.

I received this comment on my blog this morning:

Software re-use is what we do.
We are the porting and abstraction.

The link is to [His Company] and the email is yours. It's on my latest post, and at least for the time being, I'll leave it up there so you can go see it:

http://www.rosscode.com/blog/index.php?title=how_i_got_started_in_software_developmen&more=1&c=1&tb=1&pb=1

Did you leave this comment? This is a blog that I maintain and I don't appreciate the comment spam. If you want me to link to your company, then you need to give me a reason. I'm more than happy to look at what you have to offer and if I'm interested, then I'll post about it. But blatantly spamming my site is not going to work.

I will be removing the link in a few hours, and most likely banning the URL.

I've since removed the comment, but to his credit, I did get a response fairly quickly (edited to remove identifiable information).

I saw your comments about software re-use and I wanted to introduce you to [His Company]. [Marketing blurb]. Please check us out. I do apologize if you felt I was spamming you but as a software development professional I wanted to make you aware of a very good solution [More Marketing].

I don't think I was too harsh, considering that I have a do have a contact form and if his true intent was to let me know about his software, that would have been the way to do it. The only relation between his comment and my post was that I used the word "reuse" in my post talking about software I wrote in college, and it was meant as a joke! He obviously couldn't even be bothered to fully read the post, because that kind of comment is totally useless on a post about how I started in software development. The way he did it was, to me, a blatant attempt to get free advertising and link love. That's not fair to me, my readers or the paying advertisers who are part of The Lounge. If someone wants to advertise on my blog, then I'll be more than happy to point them in the right direction.

That's not to say that companies don't get free advertising on my blog. Just on the front page alone, I talk about and link to Michigan State, Deep Fried Bytes, KeePass, ISAPI rewrite, Filter.NET, Google Apps, Gmail, Outlook, Ninject, VHD Resizer, and Beyond Bullet Points. That doesn't even include links to many other blogs. Yes, I realize some of those aren't technically "for profit" but it's still promotion that they didn't request. Why was I willing to include a link to them? Because they're all things I am interested in and want to help them, even if it is just a link.

If the comment was even somewhat relevant to the conversation, that would be fine as well - for example, if someone had pointed me to StructureMap, that'd be great. It would have been relevant, even if I didn't include it originally. But comments unrelated to the content of the post just don't cut it.

Ironically, later that morning, I read this post from lifehack.org, which is all about the right way to get bloggers to promote your product. There's some really good advice about how to approach bloggers, but one thing it doesn't list is leaving random, unrelated comments. I'm seriously considering sending him that link so he doesn't make the same mistake again.

If this person would have contacted me directly and asked me to take a look at his product, I probably would have. I'd never heard of his company, but it looks like an interesting product. Too bad he spoiled it before I even knew anything about his product!

Mike Eaton, a member of my twitter tribe, is trying to get to know his tweeps better. As part of that, he asks a few questions to get a better understanding of our background. I figured that rather than answer in his comments, I' post it here instead.

Anyway, his questions are in bold and my answers follow them.

How old were you when you started programming? I was in high school - my sophomore year. I wrote a text-based football simulation on the TI-85. I also wrote a few casino games that allowed you to take your winnings from game to game. I kept that program around for a long time - but eventually, the calculator got left in the basement for a while, and the last time I came across it, the batteries had been dead long enough that the memory was erased! About the only thing I remember about writing it was that there were lots of GOTO statements!

How did you get started in programming? When I started college, I intended to be an architect. Not a software architect, an actual architect - you know, the type that designed buildings. So I started out geared towards Civil / Mechanical Engineering. I'm not clear when it happened, but I suddenly realized I was heading towards Electrical Engineering, and I was OK with that. I'd taken a couple of intro to C/C++ classes, and it made sense, but I was still leaning towards engineering. Until I took Electromagnetic Fields and Waves in my Junior year. I just sat there thinking, "This doesn't make sense. Why would I want to know this?" but writing software seemed to make sense. From that point on, I switched focus from Electrical Engineering to Computer Science. As it turns out, if you combine the two degrees at MSU, you get Computer Engineering, which is the degree I ended up getting.

What was your first language? If you count the TI-85, it was BASIC. If not, then it was C when I hit college. I distinctly remember writing a program that simulated two trains going around in overlapping circles, and we had to handle stopping one train if the other one was already over the tracks. I've always been a model train fan, so if I ever get around to building a train setup in the basement, I can reuse that code to ensure my trains don't crash!

What was the first real program you wrote? What, a football simulator doesn't count? Fine. The first program I wrote that was actually used was a console app that would read a database and spit out a SQL file that you could use to rebuild the database, including schema and data. It started out as a way for us to script out the database for the main project I was working on (it was much quicker to write this simple utility than it was to manually create the scripts just a few times), but it ended up being a simple utility that was used on a few different projects. If you don't count developer utilities, then my first program was a system that allowed clients to build online forms, mostly used to create consumer loan applications. It ended up being used by 20-30 smaller banks to take consumer loan apps and checking/savings account apps online. That was originally released in 2000, and from what I've heard (I've since left the company), parts of it are still in use today.

What languages have you used since you started programming? I used C, C++, Lisp, and Basic in college. Then I used VB, ASP, and JavaScript. Once .NET came out, I switched back to the familiar syntax of C#, but could still use VB.NET if I had to. I've dabbled in PHP and Perl, but nothing serious - my PHP experience consists of what I've needed to manage this blog. Perl experience came because I had a boss who loved it and showed me how to do a few simple text manipulations, mainly parsing log files.

What was your first professional programming gig? I'd done simple things for a couple of jobs, such as the log parsing, but my first job where programming was part of the job description was with Crowe Chizek in Grand Rapids. I started there in late '99, and my first project there was the online application builder.

If you knew then what you know now, would you have started programming? Absolutely! I can't imagine doing anything else. I think it was on the second episode of Deep Fried Bytes that someone said, "I program 10 hours a day. I just happen to get paid for the first eight." Yeah, that pretty much describes my feelings.

If there is one thing you learned along the way that you would tell new developers, what would it be? Get involved in the development community. I don't do as much as I want to, but I do a ton more than I did when I first started out. That's because I had no idea what was out there. Once I learned what was out there, I jumped in (well, the best I could). It doesn't mean you have to be at every community event - it could be as simple as blogging or reading and interacting with blogs (or just twitter, for that matter), but make an effort to get to know the developers in your area - it'll pay off in the long run and you'll have a better support group to help you learn.

What's the most fun you've ever had ... programming? The best times I've had programming is in a team environment - and it get's better the later it gets. I remember one night that we were struggling to get a few things kicked out, and a group of 5 of us stayed until 1 or 2 to knock out a few of those things. We were all in a room together and we had about a 100 chicken wings brought in, some Mountain Dew and (eventually) beer. Music was blaring since we couldn't do that during the day, and no one was in a hurry to get out of there - we knew we needed to be there. Surprisingly, we were able to stay focused and really were productive, while still having fun. The interaction with the other team members seems to get more real when you're working close together and really cranking out the code.

I know originally that Mike asked for answers from his tweeps, but if you feel so inclined, go ahead and answer these questions for yourself. Either post them in the comments here, or better yet, post them on your own blog and just point me to it in the comments.

At about 2:00 PM on the Friday before Memorial Day Weekend, I talked to a client who was frantic over an issue where a part of their system appeared to be compromised. I spent the better part of the afternoon and evening with him trying to figure out what happened and how it can be prevented in the future.

We still don't know how it happened - it doesn't look like the server was hacked and looks more and more like it was a third party service that was actually compromised. But we couldn't be sure, so we went through and did a few things to lock it down a bit more. After we were done, he mentioned this should be part of our standard project plan. And he's right, it should. So I figured I would list out what we did, what we talked about doing on a longer term basis, and why.

• Disable the administrator account. If someone is trying to get into your computer and the administrator account is enabled, you're giving them one piece of information. By creating your own admin user who isn't "administrator", you're making them obtain two pieces of information before they can gain access to the box.
• Use a pass phrase over a password whenever possible. There's two reasons for this. First, if you have a truly complex password, you won't remember it. You'll end up writing it down. And most likely, it'll be less than 10-15 characters, meaning it's potentially susceptible to a brute force attack. a pass phrase (for example, "Frankly my dear, I don't give a damn!") is much better because it's much, much longer. It's also easy for you to remember, because you pick a phrase you're familiar with.
• Different passwords for everything! This can get a little daunting to manage, but ideally, you should have different passwords for all accounts. In the end, we now have a different password for the system's user account, the database, and all third party integrated services. Now if one of those passwords is compromised, they don't have access to everything.
• Don't tell anyone your passwords. If you have secure passwords, but then the whole team knows them or you leave sticky notes everywhere, then your password isn't secure at all. It's a difficult balance to have complicated enough passwords, yet still be able to remember them. For me, I like to use KeePass to manage my passwords. This way, I only have to remember one password, and then I can get access to all of my passwords. I especially like that I can share the same file between my laptop and my Axim using the mobile version.
• Disable everything you don't need. Close all the ports you can. When we were originally developing the site, we used FTP to get the files up to the server. We no longer do it that way, but the FTP service was still on, as well as the port being open. We turned FTP off and closed the port. This left just 80 and 443, which we need for the website.
• Patch the box regularly. We originally deployed the site three years ago. A few patches had been applied, but when we went onto the box, a LOT of updates were pending. We applied all of the ones directly related to Windows 2003 (which included a service pack!). There's a reason those updates are pushed out like they are - they're meant to be applied. We coordinated with the hosting provider to have those installed periodically.
• No passwords in source control. Any place that you store your password is one more location that can be compromised. The less points of failure, the better. I usually keep staging login information in my config files that are checked in, and when I deploy, I either don't touch the config files if there haven't been any changes, or I update the one deployed with just what has been updated. This way, my login information is only stored on the production server.
• While we're at it, encrypt your config files. Or at least the pertinent sections - usually connection strings and app settings. This way, even if the server is compromised, the file is encrypted and they most likely won't get what they are looking for.

This is by no means a comprehensive list, but these are some very simple things that you can do to ensure a bit more security for your applications. I think it's a good start, but I know there's parts I'm missing, so that's where I'll look to the comments to help fill this in.

Tags: Security | KeePass

One of our new advertisers starting this month with The Lounge is SlickEdit, and as part of that, they offered us a chance to try out their SlickEdit Tools products. I love tools that'll help me be more productive, so I jumped at the chance. SlickEdit Tools is actually two products - Editing and Versioning. Both integrate with with Visual Studio, and since that's where I spend much of my time, that works for me.

I haven't had as much time writing code in the last month as I would like, so I've just been playing with it and haven't really had a chance to integrate it into my daily development habits. But one of the tools I did find very useful was the Auto Code Document Viewer, which takes your XML documentation and shows you what a help file would look like - as if you used NDoc or Sand Castle. It even allows you to save off the HTML pages for later use. This will make developing the NuSoft Framework easier, as I now have an easy way to see what our documentation looks like, without going through a long process to get it.

There's also a nice regular expression tool, with integration to RegExLib.com, which I could see being very helpful - I suck at writing regular expressions, but I understand their usefulness. Building them is a pain, and having an integrated tool to me is more useful than a separate application like The Regulator.

I do have one complaint so far about it, and I'll admit right now that it's nitpicky. They add a feature that allows you to count lines of code, which gives you a nice graph:

While useful, it's not something I want to check all the time. But I end up doing it because for 9 years now, when I want to go to the properties of something in the solution explorer, I do this from the keyboard:

Ctrl-Alt-L, Right-Click Key, Up Arrow, Enter

With the tools installed, here's the new right click menu:

As you can see, instead of "Properties", I get the line of code report. Like I said, it's minor, but it's a hard habit to break!

Tags: SlickEdit | The Lounge | Visual Studio

One of the clients I have been working with has an interesting situation where they want to use URL rewriting - but in a different way than I've seen in the past.

They've written an application for their clients, which is then used by their clients' customers. They have 100's of clients, each who has potentially 1,000s of users. As we talked about what the requirements were for the URL rewriting, we came up with two main ones:

1. They should be able to have clients running different versions of the software on the same web server  They typically have three versions at any given time: Next, Current, and Past.
2. Each client should have a consistent, non-changing URL. (for example, http://www.mysite.com/Client1)

The obvious solution is to create a virtual directory for each client and put the correct version of the software in each directory. Deployment can be easily automated, and you should be good to go, right? Well, not quite. With 100s of clients on the same server, you end up running 100's of app domains at the same time. That tends to tax your server just a bit. And by tax, I mean grind to a halt!

So we came up with an idea that we thought would work. The basic idea was to create a virtual directory for each version in production. Then in the root folder, you'd have a distributor application. It would look at the incoming request, grab the client ID, look up the client ID in a database to determine which version they were currently using, and then rewrite the URL to the correct version. As long as your application was aware of the way it has to build URLs, this would work well.

Or at least it sounded good in theory. In practice, it didn't work. As it turns out, you can't rewrite URLs across app domains. Or more specifically, you can't write to another app domain unless you have the DLLs you are writing to referenced in your application. That's a problem because we'd have to have references to three different versions of the same application. There would be namespace conflicts that would be tough to overcome. Potentially strong naming could help the situation, but it's not an ideal solution, and something we didn't really look into that much.

Eventually, we settled on an ISAPI filter that sits in front of the whole process and basically does the same thing that our distributor application was supposed to do. We couldn't use recommended filter - ISAPI rewrite - because our rewrites aren't static, and updating them every time a client moved versions would be a major hassle. We ended up using a managed ISAPI filter (Filter.NET). Because it's sitting in front of the app domains, it can handle the rewriting. It's a bit tougher to manage because it's an ISAPI filter, but it does give the flexibility they need, and the rewrites are written in managed code.

Ideally, I think we'd like to look at what IIS 7 has to offer and find a simple solution to our distributor problem, but I can't say whether that's there or not. I haven't looked at IIS 7 enough yet, and their servers aren't running Windows 2008 anyway (obviously). In the mean time, we want to make sure we're doing it the best way. Frankly, other than writing a pure C++ ISAPI filter (which would be much harder to manage, I think), I'm not sure I see any other valid solutions. I'm sure I'm missing something, so if you know what it is, please leave a comment!

Tags: URL Rewriting | Filter.NET | ISAPI

My biggest frustration since moving all of my email to Google Apps has been around how Google's labels don't really translate to Outlook folders. For the most part, it's not an issue, but for certain things, it is. Tasks is one of those things.

In Gmail, a single message can have multiple labels. In Outlook, that translates to multiple copies of the same message in different folders. I don't typically label my messages with more than one label, but just by default, all messages get labeled "All Mail", and anything starred (or flagged in Outlook) gets labeled as "Starred" in Gmail. Those translate to folders in Outlook. As a result, whenever you flag a message, it shows in your tasks pane three times. That gets really, really annoying after a while and I eventually started ignoring my tasks altogether.

Well, the How-To Geek has a solution. Unfortunately, I couldn't use it as is, because I have other email accounts that I use besides the Gmail IMAP ones, so I had other folders I wanted to include. Instead of including the All Mail folder, I excluded it, as well as excluding "Starred". But that didn't work, and I had to modify the SQL directly - by default, any criteria you add is Or'd together, and I wanted it to be And'd, so I changed it.

Now when I flag a message, it shows up once and only once in my task list. Maybe I'll actually start using it again. Outlook is NOT the best at task management, but that's a whole separate discussion!

I've heard people throwing the term "Fluent Interface" around, and, until recently, I had no idea what it meant - and more importantly, why I should care.

But then I started using one. At first, I didn't know I was using a fluent interface until I saw an example of a different one, and thought, "That's what I'm using!" I didn't even fully understand it at that point, but it definitely made the code a lot easier to follow.

So what was I using? Ninject, of course! For those who don't know, Ninject is a dependency injection framework, and it uses fluent interfaces for it's binding syntax. Here's an example of how you can bind an implementation to an interface to be used for a particular type:

Bind<IMessageLogger>().To<ConsoleLogger>().For<ConsoleService>();

In a typical implementation, the same thing is accomplished through a series of separate statements where you have to take into account the return types so you can deal with another call later on. Method names are typically longer because they're meant to be used in a stand alone fashion. By doing it this way, your method names tend to be shorter, but looking at that one line, it's pretty easy to see what's going on: I want to use ConsoleLogger whenever ConsoleService requests IMessageLogger.

So how do you create a fluent interface? It's pretty simple, really. I'll use orders and order lines as a simple example (even though Scott Hanselman is tired of Northwind!) I want to be able to write code like this:

order.AddLine("CPU", 2).AddLine("1GbRam", 4).SetTax("49456");

To accomplish that, we'd have an Order class that looks something like this:

   1:  public class Order

   2:  {

   3:     List<OrderLine> OrderLines { get; set; }

   4:   

   5:     public Order AddLine(string lineId, int quantity)

   6:     {

   7:        this.OrderLines.Add(new OrderLine(lineId, quantity));

   8:        return this;

   9:     }

  10:   

  11:     public Order SetTax(string zipCode)

  12:     {

  13:        // Calculate Tax based on Zip Code

  14:        return this;

  15:     }

  16:  }

The key is the return type. In this case, the two methods return Orders, so returning "this" is what we want - this allows you to chain your method calls together. You can also change the return type. This allows you (as the interface creator) to have control over what the next action can be.

Right now, I'm having fun using fluent interfaces. Eventually, I'll start to feel comfortable enough to start incorporating this into my own libraries. For now, I think I need to understand where it makes sense to use this a bit more first.

Tags: Fluent Interface | Ninject

I use Virtual PC for all of my development. I have a VHD for each client, and this has saved me several times in the past. First, if my laptop ever crashes, I still have my VHDs. That means I just need an OS and Virtual PC, and I'm back up and running. Second, if clients use incompatible software, I'm safe. This happens quite often actually.

Anyway, a couple of my client VHDs have reached their size limit. My base VHD was built against Virtual PC 2004, and the drive limit was 16 GB. With Visual Studio 2005 and 2008 and SQL Server on it, some of them are running out of space.

I searched around a bit, and eventually found VHD Resizer. This allows you to take a VHD file, and change the size. You can also change it from a dynamic disk to a fixed size disk, or vise versa. It was a life saver for me, and allows me to continue using my VHDs without having to rebuild completely.

Tags: Virtual PC | VHD | Virtualization

Chris Woodruff, a co-worker at RCM, recently tweeted about an idea he had - getting people together for a tech lunch a couple of times a month. People immediately showed interest, and just a day later, the first Grand Rapids TechLunch was planned.

It's going to be at Bulls Head Tavern in downtown Grand Rapids on June 2nd from 12:00-1:30. There's space for 20, but if we get more, then we can move upstairs apparently. There's also free wifi, so that's a bonus as well.

Anyway, this will be an ongoing thing. Chris has a Facebook group set up to keep us up to date, and is working on getting a website set up. The group says it'll meet every two weeks, but after talking to him, I think it's only going to be the first Monday of the month, unless it's a holiday. Then it'll be the second. If interest really gets going, then it'll move to twice a month.

Anyway, if you're in the Grand Rapids area, come on out on June 2nd. And if you plan to attend, leave a comment!

Tags: GRTechLunch