I'd look for a new job as your team evidently heard about Agile, thought it was great and then implemented it wrong. Agile has nothing to do with commenting code. Agile is about reducing all the lengthy, useless documentation that follows a project because it assumes the docs will be wrong. Such docs are unrelated to code comments. Comments help clarify what the code is suppose to do. I do agree that you should not comment every line of code. I also agree that you should use meaningful names and proper modularity but it is important to remember a couple of things that comments provide that you simply can't get in code: 1) Comments specify what the code is suppose to do, not what it actually does. Unless you write perfect code there is always a chance that you'll introduce a logical error into your code. When reviewing someone's code if the comments don't match the code then it should send up a red flag. Just having the code won't help you here. 2) Comments justify why code works the way it does. This is especially important when you don't use verbose documentation (since that goes against Agile). Sometimes there are business rules or decisions that are made by analysts or others and your code just has to do it. It is therefore important to identify why the code works the way it does. For example a block of code that is difficult to read and manage because it has been heavily optimized would probably send an agilist into refactor mode but wait. If a comment above the code said something like "This code is called hundreds of times a minute and has been optimized using profiling and memory utilization tools to make it as fast as possible" then the agilist would know to leave the code alone. Yes in a real world all code is perfectly designed but the more you modularize and OOD a problem the slower the app gets. 3) Agile should not dictate type and variable names. Sure you can use descriptive names but there comes a point where the name of identifiers simply gets too long. For example suppose you are writing some base class types and you need to implement a base class that implements a couple common interfaces such as IEditableObject, INotifyPropertyChanged and IDataErrorInfo. Try naming that type in a meaningful way. Chances are you're going to reduce it to something like BaseBusinessObject or something. Now how does that in any way convey information about the interfaces being implemented? It doesn't. You'd have to look at the code itself. Start nesting these types and it can get ug

There are actually several variations that will give you this error. In all cases you are using a keyword. The problem is there are some keywords that are either not documented or context sensitive. For example get_ is not allowed because this is the signature use to generate the getter of a property. In general you should not use any variable that starts with __ (two underscores). C/C++ defines compiler-specific values and keywords using two underscores for convenience. The C# folks followed the same rule. Avoid using __ and you should be fine.

But you can double click the svchost process to bring up the properties. Then switch to the Services tab to get the services running within it. Finally you can pause and stop each service from the dialog until the CPU utilization drops again.

Doing things to make yourself look bad will be detrimental to your career and likely will get you fired. Think about the possible scenarios. 1) The project completes in 6 months. You've done well and everybody is impressed. You have domain and company knowledge. They aren't going to want to let you go. They'll have to move you to another project where you can be best utilized. Or perhaps even promoted to manage another project. 2) The project goes on forever because, realistically, no project ever dies. We still have a client using an old DOS version of our program :{ If it looks like it'll never end and you don't want to work on it then you should approach management about moving you elsewhere. Depending upon the company politics you can convey how you don't really enjoy the job and would like more challenging/appropriate tasks. If they agree then you get transferred. If they don't then you should start looking for a new job. 3) The project is going on forever so you start doing things to get off the project. The company will take one of two actions: fire you or transfer you. If they transfer you then you'll now be marked as that person who will start getting lazy when they don't enjoy the job anymore. How long will you last on your next project (the PM will wonder)? This is the slow, but guaranteed, way to get laid off. In an ideal world you'll get transferred but, based upon your comments, that doesn't seem likely so you are left with getting fired or finding a new job. If you start looking for a new job and your employer gets wind of it then they'll either become more interested in your feelings and probably give you what you want or they'll throw you out. In the former case they'll signify they don't want to lose you (but the problem might occur again). In the latter case they are showing the mantra of "you're with us or against us" in which case you probably shouldn't be there anyway. If you do something to get fired then this will come back to haunt you for the rest of your career. Your current employer will not be a good reference. Furthermore when you are asked why you left the company at future interviews then you can't really lie. At the same time keep in mind that if you do a lackluster job and get transferred to another project then that will leave a mark as well. In future reviews or in job interviews you will be seen as someone who "throws a tantrum" and does poor work when they don't like their job. These types of people are troublemakers and most companies like tig

Why bother buying software at all? VS supports text-based templating out of the box via the T4 engine. This is the technology behind how VS generates many of its own designer-specified files. Basically you drop a .tt file into your project and it'll spit out a C# or VB source file that is part of your project. T4 templates are available online and can be really complex. For example I've seen T4 templates to auto-generate metadata classes to use in lieu of string names for INotifyPropertyChange interfaces. I've also seen templates for generating the boiler-plate code for dependency properties in WPF. There are entire websites dedicated to T4 if you're interested. It is by no means the best solution in all cases nor is it necessarily easy to create complex templates but its capabilities are phenomenal especially when you consider that it can execute custom code that works against the IDEs project object model. It really allows you to do things that would otherwise be difficult. Best of all it is free and already integrated into VS.

Having taught programming courses in various languages I can assure you the problem isn't with the language itself. The biggest detractor to .NET languages today is the framework and runtime. It is not sufficient to just use a language to write a program. You have to use the framework. Languages like C++ don't have this issue because you can write an entire C/C++ sample program without every using anything more than what is in the core language (aka defined by the language specification). STL, Windows and all the other libraries that are added to C++ aren't needed for simple stuff. (yes I know STL is defined in the C++ spec but it was a library that was added in later revisions and C doesn't have it) You can't do that with a .NET language. Even the simplest program requires that you rely on the framework. Not unto itself bad but it becomes harder to explain to someone who doesn't even yet know what a type or method is that they have to rely on a type and method to do something. Add to that the complexity of the framework (reference vs value types, newing ref types, etc) and things just get harder. It is to the point that you have to have a far broader knowledge base before you can write a simple program in .NET. Some books/classes on beginner .NET programming gloss over the framework until later. Whether that is better or not remains to be seen. Nevertheless Basic as defined in the article is outdated. Peek/Poke? The OS won't even let you directly access raw memory anymore so why make somebody use a language that embeds such features into the core language. There are updated beginner languages that would be better to learn against. I can't think of the name of the language right now but somebody wrote a new language about 5 or 6 years ago that is a stripped down version of VB that runs against .NET. It was designed for kids to learn programming. It attempts to isolate out the framework to allow kids to concentrate on the language while still building cool apps. I believe the sample apps included an asteroids like game which (of course) kids would be eager to learn to write. Overall it was a pretty impressive language because in a minimal amount of code they could have a simple game working. As they became more comfortable they could start grasping with the framework and runtime more because, after all, it was a .NET language.

How do you know it is a Foo? Do you really trust method names that much? If you do then the least of your worries should be what type foo actually is. Here's just a few examples of a Get/CreateX where X dosn't mean anything in regards to the return type: GetParent, GetOwner, GetDesignModeState, CreateHandle, CreateControlsInstance, etc. So given the original statement you can infer nothing about the type of foo. BTW new isn't redundant in all cases. For example what should be the result of this: class MyClass { Type Type ( int default = 1 ) { ... } void Initialize ( ) { Type temp = Type(); } } Now you might say that the default parameter is not valid in C# but it is as of v4. Since C# (and Java) are based upon C++ they follow many of the same rules partially for consistency and partially for support of similar features. Defaults weren't in the original spec for ideological reasons but to make an inconsistent change to prevent their usage would be overkill. I do agree however that it would be nice to eliminate the need for new in the few cases where its usage is redundant such as when inlining a temp variable in which the concrete type is known.

They are designed for different people. MCPD is designed for general devs who target either Windows or ASP.NET. When you get MCPD you get it either in Win or Web. It "marks" you as an expert in MS technologies related to either area. MCSD is for devs who are an expert in both areas (and a few others). As MS sees it MCPDs are for general devs whereas MCSD is for architects and team leads. If you get MCPD in both Win and Web then you are mostly (if not all the way) to MCSD. Now for the merits. Honestly I have a few certs and they are all but useless to me. They help you get in the door for interviews and look good on paper but they have little real bearing on day-to-day work. I've never lost a job because somebody else had a better/more certs than me. If such a case did exist then the company isn't one I'd be working for anyway. The problem with the certs is that they test your knowledge of MS technologies exclusively (available at the time the exam was written). How often in the real world do we develop apps that use only MS technologies? Not often. For example if a question on the exam asked how you might display a modal dialog in a web app you might immediately think the AJAX Toolkit but that wouldn't be an option since the toolkit wasn't available when the exam was written. What makes the tests hard is that you really have to get into the head of the test writer. Many questions on the exam have multiple right answers but you have to choose the "best" one. Best is relative to what is important and rarely do the questions make it clear. I've taken more than one test where the difference between the correct answer and the wrong answer was whether security or performance was more important. Well that depends on the test writer. In my experience the exam questions are too far off of real world to truly verify you are an expert. True story. Way back when I was a junior dev we were hiring for a sr dev position. I was responsible for the tech portion of the interview. We were using OLE, DDE and threading at the time so my questions were directed that way. We received a resume from a person who had: MCP Windows NT, MCAD, MCSD, MCSE, MCT (amongst others). We brought him in. I figured it would be a quick interview so I through out a "simple" OLE question and was ready to move on. He couldn't answer it. I was shocked so I moved on to another "simple" DDE question. Again, no answer. After a while of this he said "guess you're wondering why I can't answer these questions even thoug

MS has an internal release date for 2010 that they've mentioned to the few outsiders close to the project. However it is under NDA so if anybody outside MS gives you any release date beyond a guess then they will lose their NDA status. You'll also get a visit from some gentlemen wearing black MS shirts :} VS2010 will release in 2010 without a doubt (IMO). Watching the communications from MS it is obvious that the feature set of 2010 is solidified and mostly working. MS is working on getting things working correctly, fixing known bugs and, of course, trying to optimize performance which seems to be the current hotspot for the release. So if you are hoping to get any new features into 2010 then you're out of luck at this point. MS has changed from "what do you want to see" to "what feature, if missing, will cause you not to upgrade" mode. This is a sign that the featureset is locked. Unless you're a major dev team with MS you aren't getting any new features (and even then they are pushing a lot of things off). Beta2 is scheduled for release in the Fall. If MS follows practice then you can expect this to be the last public demo of VS before the release (although they might do a short RC cycle to select customers). Beta1 was horribly broken with many features either missing or disabled. As such it doesn't paint a good picture of VS2010's state. Beta2 is suppose to have all features added and enabled. Once we get our hands on it I think we can start estimating a more accurate schedule. In B2 mode MS is going to be looking for feedback on what doesn't work correctly. At this point it boils down to how fast the devs can fix the issues. If you assume a standard turnaround time for B2 fixes then a release by late Spring or early Summer of 2010 is in the ballpark to me. However if B2 proves to be a diaster like B1 then it is likely to slip until the Fall. We'll know more shortly after B2. After the final release you can probably expect a SP1 release 9-12 months later if MS follows practice. What makes VS such a hard product to build and update is that many of MS'es other tools rely on it and some of them are real picky. SQL Server is notorius for compatibility with VS as is SharePoint. These products do not fall under the VS team's control so they have to coordinate schedules with the other teams for the release and any patches.

It sounds funny until you realize that it was written for a product that is over 12 years old. Furthermore it was last updated 7 years ago. It was likely a problem for cooperative MT operating systems such as Win9X (for 16-bit apps) which the Oracle component might have been. If you've never worked with a coop OS then it sounds funny but it was a serious problem. Hence why modern OSes are preemptive. Continuing on with the trend though. In Windows 95 the help window that you'd get if your mouse was not responding or didn't appear would give you a suggestion. It said if that didn't help then "Click here to continue". Not sure how you could click anywhere if your mouse wasn't working... I was ready to chuck Win95 at that point and go back to OS/2.

Sending a random e-mail to someone at MS will get you nowhere. That's equivalent to forcing your way to the front of the line just because you think you'll get somewhere. In the unlikely event he even reads it (given spam filters, junk e-mail and sheer # of e-mails received) he'll probably tell you the same thing everybody else will. Use proper channels or you won't be heard. That's just the way it is. Have you bothered posting to the MSDN Forums? They are the only forums that MS will officially react to. However for all suggestions and bug reports you should post to the Connect site (http://connect.microsoft.com). This is where all future features come from. Scott, while in management and having some control over what goes into releases, isn't ultimately the determinator for what features get added to the product. The feature list is based upon demand, ease of implementation and general usefulness. Most of that information is encapsulated on the Connect item. Management (and there are many of them) sit down and go through the feature lists to determine what is and isn't doable. An e-mail from you isn't going to make that list. Submit your single request (a separate request is needed for each suggestion) and then get your friends to vote on it. Note that it is well beyond too late for anything in VS2010 but enough people vote then you might see something in VS.Next.

You really need to be careful with the suggestions on this site though. The very first suggestion about left-aligning labels is for a very specific case. The reference article that the suggestion came from confirms that left-aligning labels is the worse way to design a UI in most cases. The suggestions attempt to use a problem/solution type approach but don't bother to convey that some of the suggestions apply to special cases. One line problem statements are too vague. This particular suggestion (left-align labels) in my opinion violates one of the cardinal rules of UI design (ironically): make the most common/obvious case the default. Hence the suggestion should have said that you should left-align above or right-align labels by default. It could then explain the special cases where left-aligning labels is more beneficial. IMHO.

In general you should go for 64-bit if it is available because the advantages outway the disadvantages. People have been saying that 32-bit is dead for years. While I don't quite agree with that it is true that 64-bit is becoming mainstream in the home. Advantages 1. More memory. Vista runs fine on 4GB but the more you throw at it the better it gets. 32-bit cannot go above 4GB. 2. Faster. The verdict is still out on this but it is true that the processor can push more data across the wire on a 64-bit system. Some apps, like floating point heavy ones, perform better on 64-bit. 3. Future. 32-bit systems are going away eventually just like 16-bit did. It is hard to say when the 128-bit machines will be coming. Still it is probably better to lean toward 64-bit with all else being equal. 4. Microsoft servers only support 64-bit going forward. This has already happened on some lines like Exchange and others are to follow. 5. You can still run almost any 32-bit app. For the few that just don't like Windows you can use a VM. I have even notice a slight performance increase under the WOW3264 layer for some apps. Disadvantages 1. App compatibility. 16-bit apps don't run at all. You have to use a VM for them. Some 32-bit apps refuse to work under 64-bit. Generally any that rely on a custom driver (TI I'm looking at you) simply won't run. Again a VM will resolve the issue. 2. Installer Issues. Some apps will run under 64-bit just fine but the installer is 16-bit and won't run. Therefore you either have to manually install the app or create a custom installer. 3. Driver support lags behind 32-bit right now. I suspect this to change but it hasn't yet. 64-bit AV support didn't come until after Vista was formally released while 32-bit AV support was available at release. nVidia drivers took months to become stable under Vista. Surprisingly the 64-bit versions where more stable but they were updated less frequently. 4. More space is needed. An unfortunate side effect of the way Windows does compatibility is that you effectively have multiple copies of many files on your machine. Don't even get me started about the whole Program Files (x86) directory annoyance. Therefore make sure you have a larger HDD than you would normally need for 32-bit.

There are thousands of job applicants out there. The job of a recruiter is to filter this # down to a couple so the company doesn't have to waste their time doing the filtering. That is one of the benefits of a recruiter. Hence recruiters often ask a few questions to get a feel for the candidate. However they can rarely validate the technical expertise. Thus they are more interested in your confidence level and behavior. If you act confidently and seem to know what you're doing then they are easily fooled. This is bad for the customer because now the customer might be getting a lot of unqualified applicants. Sort of defeats the purpose of a recruiter. You must remember that I can write anything I want on a resume. I could put down that I've worked for some really big companies and handled awesome projects. Prove me wrong. The only way you can do so is to either call all my references (which is a time consuming process and has some legal issues) or test me. That is what face to face interviews are generally for. Years ago I interviewed someone with 3 different MS certifications and a MCT. He couldn't answer basic COM questions. I was shocked. Turns out his company required all devs to get these certifications even if they never did anything that would use them. Hence the knowledge was stale. Interviews are costly to a company. Therefore most companies use a filtered interviewing scheme starting with a recruiter then generally either a phone interview or test followed by one or more face to face interviews. Each one is progressively more expensive but should be progressively less common. I do disagree with giving personality/intelligence tests that have no bearing on the job. I've had one or two of these. The thought is that you're not acting like yourself during an interview (and you're not) so a test will help reveal it. Personally I could care less if you are an introvert provided you know what you're talking about and can work with the team. These are things I'll figure out during the interview.

While academically interesting it is commercial meaningless for several reasons. Firstly taking a single, small sampling of data and then generating a theory on it is easy to punch holes through. Start with the fact that memory and processor utilization can easily impact any sampling that you might do. You would need to run the test several times to start normalizing the results. The more you run the less likely the utilization noise is taking its affect. The second problem is the sample size itself. Small sample sizes cause the overhead of the mechanism used to be more important than the work itself. Larger sammple sizes tend to reduce the impact. For example in databinding the string names have to be mapped to the data source. This can be an expensive operation. Say it takes 10ms but then each actual insert thereafter takes 1ms. Unless your sample set is large enough to amortize the 10ms over time then it will dominate your experiment. You can argue that it should but caching and processor pipelining are based upon these same amortize over time concepts and they seem to be really helping out performance so there must be something to it. I would say that in a code review I might let you get away with the first or second code blocks but the third block will send you back to programming school. The third block of code is unmaintainable. You are trading off maintainability for performance. The general rule is 90/10 or 80/20. I doubt that this data binding scenario is in the top 10% of your performance issues. Remember that performance should be analyzed not by how much time it takes but by how often it impacts the program. Hence a little used feature (like reporting) might run acceptably slow provided the main UI is still running fast. So the fact that you're trying to do local optimization of this code block is a poor idea. If you really feel that performance is more important than maintainability then I would question why you are using classes and methods at all. A single main function with all the logic contained within it will always run faster than classes/methods. Performance concerns must always be gauged against maintainability and other factors. Finally I would tend to agree that your second code block would normally perform better. Data binding (as with most auto-generated features) isn't designed to run faster than hand generated code but rather be more maintainable and require less time to implement. Data binding requires 3 lines of code and is easy to read. Your second bl

This isn't the first time that it has happened in .NET. One of the previous releases added a new feature that was only available on the XP+ version of the framework. So if you assumed that the framework was the same across the board then you already made a false assumption. Do a google search to find the related set of complaints about that one. Was it a bad choice on MS'es part? Yes. Is there anything you can do about it? No. To assume that MS won't add any new features in a SP is flawed though. MS has been doing that for years. Whether it is reasonable or not is a different story but it is what it is. The problem for the particular method in question is that the v2.0 and v3.5 source is the same. The functionality was needed in v3.5 so it was added. As a consequence the v2.0 runtime inherited it. Remember that v3.5 and v2.0 share the same core v2 RTL. In fact installing v3.5 upgrades v2.0 to SP2. So while it is in v2.0 it is probably recommended that you don't use it except for v3.5. The documentation for the method specifies that it is for SP1+ so there shouldn't be any confusion as to what you'll need.

I consider dual monitors mandatory for serious development (and even general use). For development working in one monitor with VS while having documentation, sample code or even tertiary VS windows open on the other is great. It also makes debugging paint/DirectX code easier as you can put your app on a secondary monitor and test it without having to fight for screen realestate. VS.Next is suppose to have some very useful new features to support multiple monitors. It would be nice if you could split a document view across two monitors. Right now it is limited to splitting within the same window (or having multiple windows open) so trying to compare two files can be a little annoying. Another interesting benefit is that for apps that take over the screen (like DirectX) you can still get to Task Manager/VS on the secondary monitor. The secondary monitor is also handy for holding those progress/notification windows that are so popular these days. You know when you're waiting for something to download but you still have to get some work done. Finally note that in Vista the sidebar and the XP/Vista task bar can be positioned to any window. Therefore I find it handy to keep the clock and CPU temps on the sidebar on a secondary monitor while I use my main monitor for full screen work. One monitor can do that as well but full screen is full screen so anything on the screen is going to be covered when you go full screen unless you've configured the window to be on top. As an aside most people seem to use multi monitors as two separate screens but most cards also support a single unified screen or cloning. Cloning can be handy when you need to talk to someone about code as you can clone your desktop to another monitor so they don't have to hover over your shoulder and drowl.

If you are not interested in WPF then you don't have to learn it. WPF, in its current state, reminds me of the real old days of HTML programming. The tools, while getting better, are still way to immature to be overly useful. As a result you do spend a lot of time in the XML realm. But this isn't the way it will always be. Sort of like ASP.NET today or even WinForms, eventually you'll be building UIs via the designers and not thinking about the code behind the scenes. At the end of the day every UI framework ultimately is nothing more of a facade over the real format. WinForms is nothing more than hiding code. ASP.NET is nothing more than HTML. Even Win32 dialogs are nothing more than structures in memory. WPF does open up a lot of flexibility that Win32/WinForms just doesn't have. Ultimately whether WPF succeeds or not depends upon how much people want non-standard UIs over standard ones. It is ironic that for the past couple of decades MS has pushed consistent UIs (except anything related to music, go figure). Now WPF comes along to introduce non-standard UIs. WPF also eliminates many of the headaches of Win32/WinForms programming. Rather than messages going to a target window they can be bounced up and down the window hierarchy with ease. This makes taking over child controls a lot easier than in Win32/WInForms where you would have to use hacks. My definition of a good UI is one that the user can easily pick up and understand without the need for training or help. It is intuitive and all core functionality is easily accessible to keep efficiency up. Whether the UI is a listbox and a button or a complex form doesn't matter. It is in how users will use it that determines a good UI. WPF doesn't make it any easier to develop good UIs. It allows you to accomplish certain things easier. Many of the canonical examples that you'll see for WPF involve animating buttons or displaying videos in controls. Honestly these are to show off what is possible with WPF rather than examples of how you will commonly use it. More likely uses for WPF would involve the ability to theme the entire app and allow users to change it (something that is doable, but not easy, in WinForms). For people with color blindness or sensitive eyes this is a blessing. WPF also has some hooks for better architecture such as command routing (sorely missed in WinForms). WPF has its usages but it isn't right for everyone or every project. Right now I'm working on a project where users can design their own screens

VPC doesn't support 64-bit guests under any OS. It is a known limitation and one of the big reasons why VMWare is still doing really good business. VPC 2007 does support running under a 64 bit host but it technically is still a 32-bit app that uses a 64-bit driver. You should refer to the VPC site for the details about 64-bit support as it gives a better explanation. From the site I'd say 64-bit support is a low priority but it is inevitable. Given that it took 3 years to release the next version of VPC and that it didn't add any major new functionality a 64-bit guest edition is probably going to be a while.

I'll put my two cents in as there are a couple of issues going on here. Firstly, if you are asked to crack a program, is it legal. Every license agreement I've ever read says something about it being illegal to reverse engineer or decompile the code. Hence the act of cracking itself is illegal. Merely asking might or might not be but, as someone already pointed out, solicitation for a crime can be. Even worse is that if a crime is committed and you are aware of it you might be held accountable as well as an accomplice even if you don't actually do anything. While unlikely, it has happened before. You could argue that some companies make money by cracking programs to identify flaws and whatnot. You're on the fringes here. It is illegal to own many military weapons yet the military has them. It is illegal to have certain chemicals or mix explosive devices yet chemist can. See where I'm going with this. The act of cracking software is illegal, period, unless you are a (legal) business where your function is somehow related to cracking software. Now, what to do. Firstly brush up your resume and start finding a new job. A company that willfully will crack software to keep itself afloat is not a company I'd want to work for. What other "actions" will they take to save themselves. If you're in the business then you should really take software piracy seriously. It's money that people are taking away from our business. Why should we help them? Secondly you may or may not notify the software police (the FBI, in the US, is also responsible for piracy). Personally I'd probably hold off unless the company actually does crack the software and use it illegally for a reasonable length of time. The burden of proof is on you so you don't want to blow the whistle too early. Keep in mind that once you take such steps you can't go back. Although it isn't right, snitches keep their title for life so it'll be hard to explain at job interviews why you left the company and forget about recommendations. If the problem is simply that a license has expired then companies generally have support options with the manufacturer. By contacting the manufacturer I'm sure your company could get a temporary license or something to allow you to keep running until the PO is issued. It is also likely to be faster than cracking the code. If your company's server goes down then it is bad business for the manufacturer too. They don't want to lose your revenue so they'll likely help you out any way they can. Justi