MVC and WCF are both worth knowing because there are lots of projects that still use them that you may have to support. However, most new projects that I have worked on (including my own) have replaced MVC with Web API + a JS framework (AngularJS, Knockout, Durandal, etc). Also, people tend to favor Web API over WCF (when possible). So I would suggest that you learn Web API followed by AngularJS. (I actually prefer Durandal over Angular, but Angular has way more traction and the lead developer of Durandal has been sucked into the Angular team). It is also worth noting that most of what you learn from Web API will carry over to MVC, as MVC controllers look almost identical to Web API controllers. So all you will have left to learn about in MVC is Views (which are very intuitive, IMO).

Should you adopt TDD? Let me answer that question with a question: Have you ever pushed a release and felt anxiety over the idea that you may have inadvertently broken a previously released feature with your new feature? If so, then I would say, "yes, you should adopt some form of automated testing procedures." I don't usually follow the TDD "test first" approach, but I have learned to create all projects using a testable interface based design. I usually add a unit test when I am done - kind of backwards, but it works for me. Also, I don't strive for 100% test coverage; rather, I add tests to methods that have logic, or that transform data in some way. I also like to test things that could easily cause run-time exceptions, like code that relies on magic strings. Route-handling tests in MVC, for example, are great candidates for unit tests - especially since the routes are cascading, so it would be easy to add a new route that messed up other routes. This would be nearly impossible to catch with unit tests on every route. Someone commented that a negative side effect of unit testing is having to refactor the unit tests along with changes. If you read Fowler's book, Refactoring, you will learn to see the refactoring not as a bad side effect, but simply as part of the process of refactoring. You are not done with the refactor until the unit tests are also refactored, compiling and green. It forces you to take a second look at all of those edge cases that you wrote tests for 6 months ago, that you would have otherwise completely forgotten about when you pushed your changes. Once you anticipate this, and accept it as part of the procedure, then it is no longer a negative side effect. Jordan

Programmer humor. I love it! My favorite is the singleton with millions of instances.

I recently upgraded an ASP.NET project from 2.0 to 3.5 framework, and I've had problems with my web deployment project ever since. It no longer copies over existing files with the latest version.   To remedy this problem I have had to manually uninstall the previous version before installing the latest version. I tried removing the deployment project and creating a new one from scratch after the 3.5 upgrade, but have had no luck.   Has anyone else had this problem?   I'm really baffled.   I'm tempted to create a custom action that will manually delete all files and subfolders before installing.   Any other suggestions before I go down that path?   Jordan

I belabored this decision for weeks before buying a Samsung LCD. When I was comparing the TVs side by side, the only difference I noticed was that the LCDs were consistently sharper. I've not had a single moment of buyer's remorse, and am considering getting another Samsung LCD for the bedroom.

Anyone ever consider hiding employers on resumes to prevent the recruiters from using the info for themselves?

Thanks for the helpful tips everyone. Jordan

I am currently working as a contractor on a project that will require me to travel to Norway to perform the initial installation ( :-D ).   They asked me if I would be willing to charge a daily rate for the trip instead of my normal hourly rate. So I thought I'd poll the lounge: how do you usually decide on a daily rate for travel situations? Do you assume a regular 8 hour day + a few bonus hours each day?

SourceGear Vault[^] has top notch Visual Studio integration, and it is free for a single developer license. If you need to add multiple developers there is a license fee, but it is very reasonable. I looked at Subversion, but I was immediately put off by the hassle of loading separate pieces of software to have Visual Studio integration. SourceGear, on the other hand, is made to interact with Visual Studio, and is extremely easy to install and configure. If you are used to working with VSS, this will feel very familiar (only better). I'm currently using it with Visual Studio 2005 and 2008. I have a repository setup locally on my machine for my own pet projects, and one on my client's machine that I connect to remotely for their development. Remote connection works seemlessly via IIS and webservices. In addition to a full featured client software, there is also a web admin tool that allows you to maintain user accounts, setup repositories, view code and check-ins, and run reports. It's nice to be able to print a report that shows how much work has been done in the last week of development. I also find the "differences" comparison tool to be very useful in showing the current version of a document side by side with the previous version, with changes highlighted. http://www.sourcegear.com/vault/[^] Jordan

What kind of software are you writing that takes so long to build? :omg:

He knows how to use interfaces but doesn't understand OOP? I say go for it if he has the experience to back him up. It sounds like you're not looking for a lead programmer, which makes it even more of a moot point. On a side note... When it comes to design patterns, most people are thinking of GoF, but I think that Martin Fowler's PoEAA is much more applicable for the kind of software I am usually hired to write. The next time I am asked to name some design patterns at an interview, my response will be "Repository, MVP, Domain Model, Layer Super Type, Lazy Load, IoC, Plugin, Etc...." Those are patterns I actually use. It seems like a lot of the GoF patterns have been implemented (at least in Visual Studio) in Microsoft's own way. For example, observer is baked into the event keyword. Bridging a base class is as simple as using the built-in refactor tools. Iterator is baked into the foreach keyword. Factory / strategy can both be done using other techniques, and it usually boils down to preference. (MS tends to promote using ctors instead of factories when possible to keep code more readable anyway). If I was writing an OS, or a development lanuguage, or some manufacturing software, I might get some good usage out of the GoF stuff. But for business programming, PoEAA all the way, since it builds on the GoF patterns and makes them more relevant to my problem domain. Jordan

I've been given the advice that I need to become either a PM or an architect. There is a tendency to believe something if you hear it enough. I enjoy developing, so I always wonder why I would have to change? To avoid learning new technology?

I'm using Unity container (not the whole CAB) on my current web app and am really enjoying it. My service classes all have a base class that has ICache, IMessaging, ISessionDescriptor, IDataPortal, IExceptionHandler, etc. These are passed into the constructor and resolved by Unity. An interesting one is IMessaging. I have a user control that lives in a master page that is responsible for displaying messsages, validation errors, etc, that implements IMessaging. The user control registers itself via RegisterInstance with Unity. Then when I resolve a service class, the correct instance of IMessaging is automatically resolved, and my service layer can indirectly handle displaying messages & validation errors. Actually, the app uses two different master pages that reference the same messaging user control, but the user control registers itself with Unity, so that is transparent to my service classes, which can rely on the fact that IMessaging will always be available for their use. I also like being about to "resolve" my service classes from the UI layer without without having to construct all this stuff manually. Another plus when resolving a service class is that if any of its pluggable dependencies have their own pluggle dependencies, they will be automatically resolved too. Jordan

Yeah, Monster.com. I just tried it again to verify. Actually it beeps like 10 times; sounds like a phone ringing. Extremely annoying, and definitely could alert the boss. ;)

UI can be broken into two sections: look and usability. It fascinates me that Craigslist is so popular; looks-wise it is ugly, and usability-wise it is just OK. While I'm at it, the new Monster UI really annoys me. Looks-wise it is pretty. Usability-wise it is bloated. It makes me mad that hitting the enter key after typing in a new search beeps three times. I remember my dad sitting in front of the Tandy 1000-SX complaining, "there is never a good reason for a computer to beep." Jordan

I hate to give the seemingly obvious answer, but... My coding interests are subject to change, usually based on my current project. The language / version I am locked into plays a pretty big role in this. I'm not going to spend too much time reading about .Net 3.5 features if I'm still using 2.0. The beauty of The Code Project is that everying is archived, so I can search for an article after it has become relevant to my current needs / curiosity. For a long time my fascination was based around architecting clean data access layers. Right now I'd definitely skip over both of those articles. Although if I had to choose, I guess I'd look at article #1 over article #2, since I am doing a side project in Silverlight as a learning experience. Article #2 sounds too in depth, and my eyes would probably glaze over unless it was something I was actually implementing. I used a Code Project write-up on creating custom web config sections for my current project. I can not imagine reading an article like that for enjoyment though. My wife gets on my case for being on the computer enough as it is. RE: UI vs behind the scenes? Both. I've always been into coding and architecting, but the effort to make a nice presentation layer is almost always appreciated by clients. In fact, I usually get more praise for UI work than for coding complex functions. This has caused me to force myself into the realm of UI (behavior that is rewarded tends to be repeated). Fortunately, I've found that UI work presents its own set of interesting challenges, and is equally (or sometimes more) rewarding. Right now, my bread and butter work has not involved excess UI work. But I am spending some time on Silverlight in the hopes that the market will want more presentation candy. Jordan

ORDER BY .. anybody wanna trade? Maybe if we put all of our clips together we'll have an entire app we can sell.

I recently bought a Samsung 46" LCD. Many of the typical arguments against LCD screens (viewing angle, contrast, etc) have been improved to the point where they may not even bother you. After comparing many LCD screens to plasmas, I decided that I preferred the LCD picture in most cases, as it was sharper. My only dislike, after having it for about a month, is the motion blurring. After going back to the store and comparing it with the other plasmas again, I perceived the same blurring in the plasmas (even though the online reviews led me to believe that plasmas did not have this problem). Overall, I am very happy with my choice.

Design Patterns in C# is a good book. My only complaint is that there are lots of errors, most of which are very sneaky, so you have to be paying attention. For example, I was just reading the chapter on the Composite pattern and one of the class names was typo'd as "MachineComponent" when it should have been "MachineComposite". I've found quite a few of those, and I'm considering looking up the errata website for the book and noting them all in the book. I really enjoy reading about patterns. They come in handy especially when writing extensible frameworks, custom controls, etc. Some are really common, like factory method. Others, It really makes me miss writing manufacturing applications, because that's where they really come in handy. Now that I'm writing mostly business web apps with ASP.NET, I find myself reaching for Martin Fowler's Patterns of Enterprise Application Architecture much more often than GoF. Jordan