As you might now, from November ‘08 I am working at Microsoft, and as every MS employee I am now entitled to Community Server powered blog at blogs.msdn.com (mine is http://blogs.msdn.com/eugenez).
Though Blogger is a convenient platform, Community Server is ways better, and thus I will be making MSDN my new [blog] home. So update your reader with the new feed! But if you don’t – do not worry, I will be mirroring TFS related posts here.
See you around!
This is a short post to let you know that there is one new blog of note that you should add to your RSS reader. Welcome (back) Richard Berg, blogging about TFS, PowerShell and more at http://www.richardberg.net/blog. Until recently, Richard used to work at Microsoft, and if you ever asked a question at MSDN TFS Version Control forum, you probably had it answered by Richard.
His new blog already has a whole lot of information about TFS PowerShell cmdlets, so stay tuned for more!
I received an interesting comment to my previous post on securing intellectual property, the question being whether TFS meets the requirement of FDA compliance.
Let’s think about it for a second. What kind of software is FDA concerned with? Software used in or with medical devices, which obviously does not include TFS or say, Visual Studio compiler.
But FDA does recognize the importance of tools used in process of development of medical software. As part of FDA software validation process (as described in General Principles of Software Validation document), the tools of trade needs to be validated as well:
Software tools are frequently used to design, build, and test the software that goes into an automated medical device. Many other commercial software applications, such as word processors, spreadsheets, databases, and flowcharting software are used to implement the quality system. All of these applications are subject to the requirement for software validation, but the validation approach used for each application can vary widely.
So you will say – you still have to do that validation whatever it might be (and if you have any past experience with medical software, you are probably not too excited about the prospect). Not exactly – because one has to draw a line somewhere.
Do you have to validate OS you use for development? C++ compiler you are using? That surely would be too much work, and FDA recognizes that, defining that the degree of validation for off-the-shelf software applications used in quality process depends – depends on risk posed by the specific software usage, role of the software in the process, vendor supplied information etc. (for more details, have a look at “Validation of off-the-shelf software and automated equipment”)
While I do not mean that your regulatory guys do not earn their bread and butter, the whole standard thing seems to be a little bit overrated. FDA is not that much of a boogeyman – for example, one of the principles of software validation document mentioned above is “least burdensome approach”. Meaning that the quality of the software is not necessarily measured by the weight of the documents you produce :).
And getting back to initial question – does TFS meet FDA compliance criteria? Yes it does, but specifics differ depending on TFS place in software development process and on how your regulatory read FDA documentation (with the latter usually being responsible for most grief; that’s why I recommend reading FDA guidelines yourself – to get magic out of the process and ask the educated questions).
And if anything, FDA documents are probably making much more sense than some unregulated documents I came across.
Do you care about your intellectual property? I am sure that the answer is yes. Now how about related question – are you doing anything to make sure that your intellectual property stays yours?
Even if you answered yes to the last question, it is not easy to cover all aspects of the problem. Some of more detailed questions you might want to answer:
* - If you have additional compliance to worry about (such as FDA), additional questions may need to be answered.
There are some small things you have to do proactively to make sure you are covered from the legal perspective. While I am not an expert in law, I do have couple of them to offer for your consideration:
If you happen to have any hard earned advice on the matter, please share it in the comment.
Recently I read an interesting post that attempts to explain how configuration management process has evolved from “file-based” into “task-based”; and am writing mine as some of the opinions expressed there are arguable.
First of all, the concept of task/feature/change request artifact associated with the changes to code is not new; first commercial CM system, CCC Harvest (dating from mid-70s) already employed this concept; and the current version of the software is still built around such artifacts. Thus the idea of configuration management process driven by the change artifacts rather than by the changes in code files is every bit as traditional.
Another misconception is that configuration management using files-based version control alone is simplistic as compared with task-driven CM. Branch/merge model, labels (snapshots etc.), concurrent check out and other concepts that are file-based provide for pretty flexible environment, and many of the tasks attributed to task-driven tools are achievable (as illustrated, for example, by Perforce).
But it is certainly intriguing how nowadays for most CM tools the integration with meta-data artifacts other than files (however they are called - tasks, CRs, defects etc.) became one of the most important and requested features.
Personally, I have a theory that tasks-driven approach become more popular due to the changes in the way software development is done. While task-driven process was available for years, usually it was an integral part of a rigidly formal structure. The distance between defect filed by the customer support and developer who handled the bug was huge and involved multiple tiers, and smaller shops just did not have the resources required for such multi-tier formalized setup.
But in recent years, development become more and more “agile” (for the lack of better term), and the “path” between code and related artifacts become significantly shorter. And the process itself changed as well – perhaps that’s why the tools that worked well for enterprise in the past (CCC Harvest or IBM Rational ClearCase/ClearQuest) find it increasingly difficult to compete with less formal and more flexible competitors. Microsoft Team Foundation Server is a good example of the tool that can fit into enterprise environment but is still sufficiently agile to be a valid choice for less formal one.
There are some things in TFS that you can achieve by using work items in conjunction with source controlled files:
However, there are things that are not available (out of the box), for example
Important as they are, the missing features hardly pose insurmountable obstacle in TFS adoption (of course, unless you hit some political snags along the way – you know, of the kind “if X is not supported exactly in the way I want it, we are not buying it”). If you believe otherwise, I would be very interested to hear about it.
In the spirit of providing links instead of content, here is another link – comparison of Git with other source control systems popular in OSS world.
And if you do not know what Git is, it is well worth a look (perhaps that comparison will excite you enough to have a look).
If you are using VSMDI files, chances are you know what I am talking about. You get all your test lists defined, tests running, sun is shining and suddenly, out of nowhere second and then third VSMDI files get created.
The problem is pretty irritating one, as can be witnessed by some angry posts at MSDN. The problem also seems to be a complicated one because it can happen in multiple scenarios, and some of those scenarios are not readily reproducible. The reproducible scenarios are:
Other scenarios appear to involve Test List editor tool window, and not reproducible in 100% of cases.
So you’d say – that’s all very interesting, but how about fixing that? There are several ways to go about it.
First of all, scenarios involving read-only VSMDI files should be easily fixed (by removing r/o flag). In case of source controlled solution, there is KB support article 957358 detailing steps to avoid that.
Secondly, there is piece of advice that I really like (courtesy of Chris Menegay) – always modify VSMDI files by double-clicking the file in Solution Explorer (and not by using Test List editor etc.). From my experience, it appeared to work magically.
And lastly, most of these scenarios are fixed in Visual Studio 2008 SP1. If you have installed service pack, and still observe duplicated files appearing, folks at MS would be every interested to know about it. Leave a comment or drop me a line.
In next version of Visual Studio, VS 2010, the pain associated with VSMDI files should go away as there is a whole lot of changes in the way testing is done.
Just a short personal announcement – I have removed MVP logo from my blog. Why? You have guessed correctly – I have joined the very company that awarded me MVP status.
Does that mean that my blog will change direction? Well, somewhat, since I will be working in Windows division on internal testing technologies. But I am still very much interested in ALM at large & Team System. So stay tuned!
How much do you know about the clones (apart from Star Wars stuff)? Chances are, if you ever participated in team effort developing software, you came across duplicate code, in most cases resulting from Copy/Paste magick. The best solution for finding duplicates in code is still manual code review – trusty efficient but time-consuming method. But one frequently wishes for an automated tool for that – and that’s where Clone Detective comes in. This is very interesting free tool that become available at CodePlex about a month ago and it purports to assist developers in identifying duplicate code in C# projects.
What is so exciting about this specific tool? Is that a first tool of its kind? Well, there are clone detection tools on the market; most are Java-oriented but some would work for more than one language. However, the tools I have tried were a) pretty clunky to operate, b) not integrated with IDE and c) cost money based on weird licenses (based on LOC processed etc.). Clone Detective on the other hand is a) easy to run, b) reasonably well integrated into VS and c) free. Thus it is very tempting to try!
How does the tool work? Clone Detective is essentially Visual Studio 2008 (no VS2005 support) integration front-end for ConQAT engine - COntinous Quality Assesment Toolkit, academic project by University of Munich. So when you run analysis of your code, Clone Detective will invoke ConQAT engine with the files, and will know how to process and present results in a meaningful way.
As many other academic projects, ConQAT engine is written in Java, which means you must have JRE installed (and JRE version must be higher than 1.5). Make sure you install JRE prior to Clone Detective, otherwise you will have to change the path to Java in tool settings (through “Tools->Options->Clone Detective” menu). This is an interesting twist – installing Java to analyze C# code, but remembering that the tool is free helps overcome the doubts at that stage :)
Once Clone Detective package is installed, you will have three additional tool windows available through “View->Other Windows” menu in your VS 2008 IDE: “Clone Explorer”, “Clone Intersections” and “Clone Analysis” tool windows.
“Clone Explorer” tool window is the main entry point that you will use to run the analysis and review the high-level results of it. The results will consist of list of the files in the solution folder (separated into physical folders), where for each file there is indication of clones found; "Rollup" combo box allows selection of different metrics such as "Clone Percentage", "Number of Cloned Lines" etc.
Double-clicking the file will open it in IDE with the clones detected highlighted with different color on the left margin of document window.
However, for better navigation one would use “Clone Intersection“ window, available by right-clicking on the specific file. This window displays cumulative color map for the clones in specific file on the top, and list of other files that contain clones from the selected file. Using color legend, one may view the distribution of clones within the file/across different files.
To drill down to specific clone, right-click on the color bar (either one on top or one on the right of the file), and select "Find all occurrences" - that will bring you “Clone Results” tool window to facilitate review of specific clone (double-clicking on the file will bring up IDE window with the focus on the clone and color coding on margin identifying the range of duplicated code).
Here is duplicated code found within the same file:
And here is the code duplicated across two files:
In a nutshell, that's the featureset of the tool (I did not mention the configuration, accessible from “Clone Explorer” window, which seems to hint on advanced fine-tuning options available).
One additional important point to be aware of is that the tool runs analysis on all files in the solution folder and all sub-folders and it does not require the files to be compiled; thus you may end up analyzing lots of files you did not want to. But perhaps that can be mended through settings.
To get some feel for how well the tool works I run some ad-hoc tests with Clone Detective, and here are my findings:
So in terms of success rate, I am still undecided and need to use it more to get certain benchmarks. But for a free tool it was easy to use and delivered on declared functionality (with some caveats).
On the problem side, it appears that running the tool on a large number of files may result in a huge amount of data to analyze; and the number of perceived clones may affect the analysis productivity. Thus integrating it into VS project build to be used throughout the development (a-la code analysis) and continuous build integration flow may be features to consider for the future.
Overall, Clone Detective may be well recommended for the test drive; I believe that it may be useful as part of the code review and overall development process.
Any person doing software development is often faced with the same problem: you come across some code that was developed as a quick’n’dirty answer to the project timetable (for speed reasons), or some code that works in convoluted way but could not be changed (for legacy reasons). What are your choices? One choice – you have time, skills and mandate from the management to fix the problems, revamp the architecture, refactor the code whenever you feel like doing it; so you just resolve the problem there and then. Another choice – you do not have time, do not own the code, have higher priority items etc., so you just put “TODO: Fix later” comment for later resolution.
After a (surprisingly long) while, I came to the conclusion that this traditional way of handling code problems is sadly inadequate. Seeing TODO comment in the middle of debugging session is pretty familiar sight; and there is a high chance that this very TODO is responsible for the problem you are looking for. But it is there already – so what is the problem? Short answer is that TODOs are rarely done; it is almost as if it is NEVER TODO.
And the problem is inherent in the TODO comment technique itself – code comments serve for code description, not for task tracking. And once you identified that something needs to be changed – that “something” becomes a task that should have priority, should be assigned to somebody, possible resolutions should be analyzed etc. All of which cannot be done in a code comment. And code comments do not have high visibility; if anything comment is always less visible in IDE that code; most IDEs provide extensive code navigation but hardly any comment navigation (As an anecdote on TODOs visibility, in an effort to improve it, I tried alternative technique of refactoring problem method/class names by adding telltale suffix in a belief that developers would be averse to using PerformCalculationCrap method or CustomListenerCrap class. I should tell you, having repulsive name did not affect the bad code proliferation at all :).
Thus one obvious solution is to create a task entity instead of in-place comment (if you use Team Foundation Server, that task readily maps to work item with all data formatting and reporting capabilities available there); create this entity separately from the code and ideally have it linked to the code in question. While the approach is easily the best one, it will not work well for everyone: certain overhead is involved (both with creation and maintenance of task artifacts; and at the very least it requires some task tracking system) that is not always justifiable; for example, you may still wish to mark the code for later review tomorrow morning without moving away from code here and now (after all, creating task artifact will necessitate context switch).
So nowadays I try not to use any TODO comments even in the absence of task tracking system; some alternative approaches (for Visual Studio 2005/2008) are summarized below. While not the replacement of tracking code issues in task tracking systems (and to say even more – design/architecture issues always MUST be tracked elsewhere), I believe in general these approaches work better than code comments, since they provide a) better visibility (visible in compilation log) and b) easy navigation (possible to navigate between issues) and c) require intentional action to suppress (you do not need to suppress comments at all).
And yes, I am aware that I am stretching the “intended usage” paradigm in most scenarios; all I can say is make the decisions depending on your specific scenario.
Alternative TODOs in C++
In C++ (both managed and unmanaged), the easiest way I have found is to use deprecated pragma directive. Given the method name as the parameter, the pragma will generate preprocessor warning for the method. Not so easy to ignore and easy to navigate to:
In theory, this pragma ought to be used to identify deprecated functions; however, in the projects I was a part of I have never seen it used for the declared purpose and thus it could be used as TODO indicator on methods. Of course, if on your project this pragma is used for its intended purpose, you won’t be able to use it. In such case, one may use less elegant approach; for example, the one below
#ifdef BACKLOG #error DoSomethingWrongWay is quick and dirty#endifvoid DoSomethingWrongWay(){ ... }Once you define BACKLOG on your project, you can easily review and navigate the TODOs. While less elegant, in this manner you can mark any line of code (whereas using deprecated you can only label whole methods).
Alternative TODOs in C#
For C# there are two alternatives that I used in lieu of TODO comments.
First approach is to use #warning pragma. This way you can mark any line of code and then easily navigate between your TODOs.
Another way is to use Obsolete attribute (much like the usage of deprecated pragma in C++ discussed above); when attributed member is used, warning gets generated. However, since the attribute is widely used for its intended purpose, I try not to deviate from this intended usage, so it is more of the “caveat” rather than TODO comment. For example, if there is some crazy method that cannot be changed right away for legacy reasons, it can be labeled Obsolete so no one will be using it in the future (since using it will generate new warning right away).
Using traditional TODOs efficiently
If you are still not convinced, and prefer to use TODO comments in your code, there are still ways to use them in a more efficient manner in Visual Studio.
Just open “Task List” tool window, select “Comments” in the “Categories” combo box – and voila! You will immediately see all TODO comments in one list so you can easily navigate between them [by the way, the comments shown in the task list are not limited to TODO; one can define any comments to be shown there by changing settings in “Tools”->”Options”, “Environment”->”Task List”].
This feature would be even more useful if all files in currently open solution/project would be scanned. Currently only open files are scanned, which means search through files would still be a better method to iterate over all TODO comments in project.
After writing this post, I thought I’d do quick search on the subject; while I was not able to see what’s the prevalent opinion, I found an interesting blog post from Ben Pryor that argues similar point of view.
And by the way, TODO comments are not specific to any development methodology. I’d assume that is more of general phenomenon.
Have a strong opinion about the subject? Leave a comment!
I did some general research on SCM tools lately, and one fact I found interesting was the amount of negative information floating around (no matter what tool you are looking at). What’s interesting about it is that in most cases the negative zeal seems to be misplaced. And here is why – what I know from my personal experience, blaming the tool is usually the symptom of something else lurking behind. So being positive guy that I am, let me share my thoughts about “something else”.
First problem that comes to mind is selecting the wrong tool from the start and then blaming it.
With all white papers floating around, and trial versions available (not to mention sales persons ready to do circus dance at your office), it is still the easiest thing to do. People do it by a) assigning the wrong person to do feasibility assessment, b) compiling a list of wrong requirements or c) making the decision based on political/financial motives alone. Those are just a few reasons that come to mind; I am pretty sure anybody who worked (or better yet, consulted) for multiple companies can add more. And mind you, when I am talking about “wrong” tool I mean “wrongness” on a great scale – choosing system without offline support for largely distributed work force with limited connectivity, lacking of the integration to the one development tools that is used by everybody etc. Things of that scale usually cannot be fixed internally no matter the resources available.
Choosing the wrong SCM (or looking at bigger picture – ALM) tool may result in different outcomes. Three outcomes I have personally seen are: dump the tool and do re-assessment (extremely rare since somebody has to take the blame and requires understanding that the tool is a wrong one early on), readjust internal practices to align with the tool (also relatively rare since internal practices usually have more champions that any new tool, regardless of their merit) and make a do with what is there.
In every case there will be frustration abound, and some (or may be even most) of it is always directed towards the tool.
While choosing the right tool is undoubtedly important, setting up the right process is even more important. By process I mean general set of SCM practices that may include software design, development, maintenance and release; whether these practices are formalized and documented is not material.
Let’s assume that the well performed feasibility study allowed your company to acquire the right suite of tools; i.e. the company managed to avoid “wrongness” on a large scale. The pilot project was set up, outside consultants were hired to provide inside knowledge, pile of documentation was compiled. Does that mean the process is right? Not really. The groundwork may be there, but whether the process is working still remains to be seen.
The only way of understanding whether process is working is continuous monitoring; the only way to make it work is continuous adjustment. Same as in software development in general, it appears that being agile pays better than being know-it-all-right-from-the-start.
The signs showing that the process is not working correctly are many and may be monitored with relative ease. One such easy to detect sign is a developer bitching how it is impossible to work with YYY (while with XXX everything was a breeze). Countless cases of such “issues” may be found by searching for "YYY sucks” on the WWW, though sometimes the reason is case of the "wrong tool" (it is not always easy to distinguish what is the reason – find one extreme example here; I think that one combines wrong process, wrong tool with a touch of good old RTFM advise applicable for a good measure).
Adjustments to the process should follow the signs and eliminate the bottlenecks by healing the cause – whether by developing custom utility to provide automatic generation of release notes, by training your developers in the art of branching concepts or by chucking your carefully crafted (theoretical) workflow in favour of less elegant but working one. The mantra of “developers, developers, developers” is well applicable to SCM process (just do not forget to change the words every now and then to “release managers, release managers, release managers” etc.); making everybody happy or at least content is the best metric of well implemented process.
My purpose in writing this lengthy and somewhat generic post was this – when one has an urge to write spiteful post about certain SCM tool (be it TFS, SVN, Perforce or whatever), it would really help to stop for a moment and deliberate. I am willing to bet that in majority of cases either the tool is being bend to deliver something it was not intended for or the process built around the tool is less than perfect (and I leave out the eternal cases of RTFM). Myself, I am proud of never blasting any SCM tool in public :)
How often do you check in? Do you have organization-wide policy mandating the maximum check in period? And should you care at all about those pending check ins?
As the general wisdom has it, you should check in “often”. In the past, I myself was quick to cite that maxima, but thanks to several discussions around this issue I have been swayed and now believe that "often" is not a right qualifier' rather that checking in often, one should check in when “ready”. Indeed, when you think about it, committing new revision of code to the repository is (or should be) driven by the code readiness rather than by the arbitrary time period.
But that raises another question – what is code “readiness”? While “often” is easy to define (“Thou shalt check in code once in a fortnight!”), ready to check in code is trickier and depends on your company practices. Code readiness may include one or more of the following:
It is at that stage that many decide to go back to “check in often” principle, since making sure that the code being checked in is ready code is much more complex than making sure the code is checked in every three days.
However, if you are unable or unwilling to define code check in criteria, that says a lot of (bad) things about your development process. Basically, check in should be used for committing snapshot of the development; but not just any snapshot. If the only thing definite about the code revisions checked in is that it is checked in with daily intervals, the usefulness of your source code control repository is very limited - try to rollback or go to certain state of the repository in the past, when the revision is synonymous with the date. So establishing at least elementary criteria for check in (read "code compiles") is a good start and is preferable on the face of any time based criteria.
One other argument against "check-in-when-ready" and in favour of "check-in-often" is backing up the code revisions (“when your workstation crashes, we have the copy in the repository”). With the modern SCM solutions the problem is easily solvable; for example, TFS provides shelving functionality that ought to make “check in for backup” thing of the past.
And here I am going to contradict myself a bit and say that even when you set the check in criteria, having “check in often” policy is still valuable (with “often” set to 5+ days) – but only as additional measure. That way you may discover long lasting development effort (“it is still not ready, we need another week, since if it is checked in now, everything will break” sort of effort), the effort that should not be a single check in unit anyway (probably TFS branch construct is the one to use in such cases). By the way, another interesting outcome of that policy may be to discover that granularity of development tasks assigned is too coarse. In that case working on breaking up development into smaller pieces may mitigate the check ins problem.
So to conclude my somewhat rambling post, here is my “pending check ins manifesto”
But hey, what about about the initial question – whether one should care about those pending check-ins at all? Hopefully, the discussion above makes it somewhat clearer, I believe that yes, one should care about check-ins left floating around. When somebody checks out the file(s), he essentially makes the statement “I am about to modify these files”. From that point there are two ways - that person may decide otherwise and do not commit any changes (undo) or make and commit the changes. So by using pending check-ins indication you have very simple and yet powerful tool to monitor the state of software development and to improve the process if needed.
And it is a shame that sometimes simplistic view of Configuration Management concepts prevails and makes lots of people unhappy. Let us deliberate before enforcing any policy - perhaps we could do better?
When I vented my feelings on Jeff Atwood’s naive view of commercial software development, I did not have any statistical data. For example, in his post Jeff talked about how MS Test sucks vs. NUnit and how nobody is using it.
And now, thanks to the poll that Roy Osherove did, there are some data at least to argue that claim. In his original post, he asked what what unit test framework people use, what mocking framework and what threading objects are most frequently used.
Now that the votes are all counted, everyone can see that MS Test beats everything but NUnit and was used by 27% of those responded (NUnit was 47%). Of course, you can discard the poll as not representative enough, but Roy's readers are pretty advanced bunch.
The data in the poll surely undermines Jeff’s claim that “Everybody I know who has tried to use the MSTest flavor of unit tests has eventually thrown up their arms and gone back to NUnit”. I have used both NUnit and MSTest, and while the latter may lack some features for advanced users, in general it is very decent framework with decent integration into Visual Studio.
What I really wanted to say is that it pays to experience things first-hand; if you evaluate something, do not be swayed by popular opinion without evaluating software and do make your very own opinion.
And another data in Roy’s poll (somewhat unrelated to the topic of the post) is the relative usage of threading primitives. Who could have thought that in year 2008 the close second is Thread.Sleep? Underlines the importance of code reviews, that :)
Just read an awesome post by Sasha Goldshtein on “Harmful Interview Questions”. As it happens, I also did (do) my share of both interviewing and being interviewed, and I fully subscribe to his views.
To me, the developer position candidate should first and foremost pass hands-on-test (preferably using programming language, technologies and IDE the candidate is interviewed for). That would make up 60% of the result, with other 40% made up with how well candidate communicates, past projects knowledge etc.
But somehow many companies still attempt to make intelligent decisions based on exactly kind of questions identified in Sasha’s post. More power to them.
I have opened my email client (Outlook naturally) on 1st of July, and immediately saw an email with the subject [MVP] Congratulations! You have received… You guessed it – I’ve got MVP award for the second time in a row. Thanks Microsoft!
It was pretty eventful year for me on all fronts; I have thoroughly enjoyed communicating with Microsoft product team and fellow MVPs, and I still like what I do community-wise, so see you around!
Usually I refrain from discussing general software topics (since tastes do differ, in software even more so than in real life), but I was really rankled by recent Jeff Atwood’s post.
I believe Jeff handles the matter in very naive and simplified manner. “Why Microsoft has to rewrite NUnit instead of re-using it”? Why indeed? Even if we discard copyright and other legal issue (which Microsoft generally does not do, and for the good reason, with all litigation going against the company), how about the support? You take something open source and who is going to support it – MS or original community? And what happens if there is a bug in the open source software integrated into commercial product – who is responsible for that? MS or the community? And ultimately, who gets blamed in the end? I am willing to bet whatever that same people pushing MS to re-use existing open source will jump and wave their hands saying that MS again released buggy software if bug occurs in open source project integrated with MS solutions.
And how about comparing Team System to assembled stack of open source tools? When you are the biggest software company in the world, and a commercial one at that, you want to take bunch of products from other vendors, with different licenses, using different technologies and use them in your flagship product. Or you want to use your own product stack and technology to create your solution, aligned with your customers expectations? Sounds like no-brainer to me.
So should MS provide better extensibility into its products? Absolutely. Should it use open source in its commercial offerings? May be, but I do not think many people reading my or Jeff’s post have good notion of what is really involves (including Jeff and myself).
And it seems to me that it really does not become to Jeff to come out with that kind of simplistic attitude. With 100K blog readers I find that simplicity somewhat embarassing. Or may be I have just missed the point altogether (since I do not drink soda and soda analogies were lost on me)?
P.S. And read the comments to Jeff's post too. It appears that everybody and his dog knows more than MS folks. Pretty educating, that
Believe it or not, but on the second day of TechEd I got some infection in my right eye. So all my impressions from the sessions starting the second day are sort of one-sided J. Anyway, besides the cool keynote by Bill Gates which I have already mentioned, here are my top picks for TechEd Developers 2008: And last but not least, TechEd was an awesome place to meet new people (and talk face-to-face with some of the email acquaintances). Overall, the event was excellently organized (just try to set up the conference for six thousand people) and I have enjoyed it very much (though darn that eye thing!).
Here are some impressions from TechEd Developers 2008 – live!
The highlight of the day, keynote by BillG was pretty impressing (including official version of "Bill Gates last day at MS" homemade movie). Of other presentations I saw some are awesome, some are less so – but one big bothersome thing I experienced today I thought must be blogged about (hey, there are there more days to go).
Every presenter must read Scott Hanselman's post on effective presentations, especially 4th point, quote:
"4. For the Love of All That Is Holy, FONT SIZE, People (See that?)"
What's up the fonts, people? Almost nobody changes the font (I do not even mention ZoomIt software).
Please please increase the font size! I cannot read anything (even as I blog) …
If you are going to be at TechEd this year and want to chat face-to-face about Team System or life in general, drop me a line at eugenez_at_attrice_dot_info. See you there!
Sometimes it is not easy to refrain from posting links instead of original content :) But there are three recently released tools that richly deserve advertising. Framework Design Studio allows comparing different versions of the same managed library (in binary form). You can filter the interface content being compared, comment on the differences and save the output as MS Word 2007 document. I have tested the application a little, and it packs surprising amount of functionality. One thing to be aware of is that the user interface is somewhat quirky, so make sure you read the manual before using the app (manual docx is installed as part of the application package). Typical usage for the app would be to compare new version of third party (meaning only binary is available) library with previous version, in order to discover the changes to interface. Another application I could think of would be to produce sort of release document to be distributed with the new versions of given library (since FDS allows commenting the differences and produces very nicely formatted Word document – beats documenting interfaces changes manually). VSCT Power Toy is a small application that Visual Studio package developers will kill for. It retrieves command tables (including all ids) from VS packages or VS registry, and even nicely formats it for copy/paste to .vsct file. Anyone who did it without this app can appreciate the difference (look at my previous post if you want to get a feeling). I practically drooled all over the screen with this tool running Patterns & Practices Documentation Tools is set of instruments Patterns & Practices team uses to create documentation. The tools are Word 2007 (English only) template with macro and associated toolbar to create well-formatted content and PowerShell scripts to convert the document authored through template to HTML, CHM or HxS. I did test the template, and the process of authoring document appears to be pretty smooth. The converters, on the other side, require bunch of things to be installed (in addition to PowerShell). But if you look at P&P produced documents, the result probably worth some extra work.
