mai 2008 - Posts
I got all psyched up today - the entrance badges for NDC 2008 arrived the office today. One step closer to the coolest developer conference in Norway to this date (I'm probably stepping on a few toes with that statement..)
Heres a nice picture of it taken with my crappy mobiletelephone camera :
Microsoft announces Source Analysis for C#. It is very similar to Static Code Analysis (FxCop), but instead of doing on the binaries it performs the analysis on the actual C# code.
Read more about it here.
We're finally closingin on the release of the version 4.0 of the every so brilliant ReSharper.
You can find here.
Among other things the beta offers quite a bit of C# 3.0 features:
- New code analysis, context actions and quick-fixes;
- New refactorings (such as Convert to Extension Method,
Convert to Automatic Property, Convert Anonymous Type to Named);
- Updated IntelliSense.
Martin Woodward posted earlier about how to go about aligning build numbers with assembly versions in TFS2008.
We used to do the same thing as he describes for our builds, but I found it really annoying having to have a file in the file system that the build task relied on and needed to be updated whenever one needed to delete the last build (oh yes, it happens - probably shouldn't - but it does.. :) )
The build task I came up with was a task that queried the buildserver for the builds and got the last build and retrieved the buildnumber and increased according to our build numbering strategy (We increase the revision (last number) by one for every build and the build number (the one ahead) by one for every hotfix). The task automatically handles all this by looking at the buildquality indicator that is used by testers (or at least should be used by them) to indicate the quality of the build. Our current scenario says that if it is marked with "Ready for deployment" it should increase the "hotfix" number.
I've attached the entire solution
, below you'll se a snapshot of the Execute() method, it relies on a couple of other methods
and properties found in the class.
To use the task, simply override the BuildNumberOverrideTarget as follows:
The dates have changed for my workshop at METU in Turkey. The 23rd of June and for four whole days we'll have training in Xna, with focus on Xna 3.0.
We will try cover all of Xna in these four days, ranging from 2D and 3D graphics to sound and networking through Xbox Live as well.
**** <UPDATE Date="22nd of may 2008"> ****
You have to add the namespace specification in front of every element.
Create a XNamespace by doing :
XNamespace microsoftNamespace = http://microsoft.com/schemas/VisualStudio/TeamTest/2006;
Then for all the XElements do new XElement(microsoftNamespace + "<tagname>");
**** </UPDATE> ****
I've been working a bit with automating our build process and creating a lot of CI builds. Today I started getting our builds to run all the tests, create code coverage and then run static code analysis for it all. Getting the code coverage demands that the assemblies run during unit testing are all instrumented. Normally on the client side you just have a .testrunconfig file attached configured with all the assemblies. This same file could be used from the MSBuild running on the TFS as well as Buck Hodges blogged about a while back, but it would demand human interaction whenever assemblies were added or removed. I figured I had to come up with a remedy to this and created my own MSBuild task to handle it all.
The above code outputs the correct XML needed as input for the unit test run. So in your MSBuild file you need to use the same file for output through this task as the RunConfigFile property used bu the TFS TeamBuild.
The runtime for .net has a type caching mechanism that is really great. Every so often I write code where you need specific data based upon a type. Normally one tend to revert to a Dictionary with Type as the key and the datatype as the valuetype for the generic parameters.
Typically:
This will then rely on he dictionary and its implementation. Sure, it is not a bad solution, but there is a more effective and last but not least; cooler way of going about achieving the same effect:
The beauty of this is that the static constructor will run once per type and one can do type specific stuff in the constructor
The two implementations above lack a lot, so lets go for a more complete sample:
Yesterday, Microsoft launched a completely redesigned creators club site alongside with a beta of the community games.
Just entering the site after logging in, you can see how easy it is to submit a community game:
The site is intuitive to use and in my opinion has a great design. Keep up the good work guys!
The new beta version of Flash 10 comes with hardware acceleration for 3D. This could prove to be the real advantage point Flash needs over technologies such as Silverlight.
As a C# developer and eager games developer, I'd love to see this in Silverlight. I've always wondered why one have been relying on software rendering in RIA technologies such as Flash and Silverlight when the graphics adapter is perfectly capable of doing this a lot better than the CPU. Let the CPU do what its good at and the graphics adapter likewise. For cross-platform compatibility one could use OpenGL as a platform for this. I guess doing that would be quite the camel to swallow for Microsoft, an abstraction of some sort would enable them to take advantage of DirectX on the Windows platform and OpenGL on Mac and Linux or any other platform. The only issue would be devices such as a Windows Mobile or a Nokia mobile telephone that wouldn't be as powerful in 3D rendering. But I think that problem should be left to the content developer to choose how advanced graphics they want in their content.
Anyhow, the Flash 10 beta can downladed here and some samples can be found here.
As a response to Fredrik Kalseths blog about circle of interest and a subtle hint in his post that it would be interesting to see my circles (sounds a bit kinky, doesn't it), here goes :
It seems that I have a lot that I define as my core, but I think it reflects what I really care about. I could probably add a couple of more technologies in it, but I think it is more than sufficient. :)
Anywho, the background for all this is Paul Stovells post about the circle of interest (I know I called it circle of life, but then again computing pretty much consumes my life).
It was quite interesting doing this, you have to really stop and think things over. I challenge anyone reading this to do the same.
Another cool thing with XNA 3.0 is the ability to use MP3 and WMA files directly. This gives better compression for your music than the average of 27% before. These files can also be added directly to your content folder and used from the ContentManager as you would with any other content.
Kyle Schouviller has made an example of how to use this, check it out here.
One of the things that has been really annoying in XNA 1.0 and 2.0 is the fact that you had to use XACT for everything that had to do with sound. A real painstaking process that really felt like we were back doing super nintendo development in DOS (Ok, probably a bit exaggerated). Anyhow, they've finally gone about making this process as brilliant as it should be.
Now you can simply drag'n'drop a wav file into the content folder and you can load it as content directly via the ContentManager.
You still have to use XACT if you want to more advanced audio stuff, but for the simple sound effects and such, this is brilliant. Read more about it here.
JavaFX was announced this week at JavaOne. I first heard about it about a year ago and have been waiting ever since for what they are working on. It certainly looks like a direct competitor with Flash and Silverlight, but they're also aiming for more than just browser experience. They have 2 things going for it that is really great; 3D support out-of-the-box and tools support the Mac.
I guess I gotta sign up and have a go at this. After all, it's only fair after doing a lot of Silverlight stuff and attempting to do stuff with Flash earlier.
Finally the CTP we've all been waiting for is here. You can now pick it up here and start developing for Windows, Xbox 360 and Zune (if you're lucky enough to own one). Another great news with this is that it supports Visual Studio 2008. It's time to see if I can finally uninstall Visual Studio 2005.
Xbox 360 development and deployment is not supported by this CTP, unfortunately.
Anyhow.. More details can be found here.
Since I started working professionally back in 1994 with software development I got very interested in processes and methodologies. Over the years I've worked with quite a few types; Waterfall, Cowboy, eXtreme Programming and lately we've been working with applying MSF Agile. Back in 1996 I started doing test-driven development, on games as the matter of fact. We had unit tests for basically everything, some of them needed to be interactive seeing that we couldn't exactly mock visual stuff that needed the human eye to approve, but nevertheless we were TDD based.
I've been working with agile software development for the last 4-5 years, or should I say, trying to work with agile software development. All processes has a certain set of rules that needs to be followed and I remember when I had training in XP they said that you need to obey the 12 pillars of XP. The developers at work, myself included, couldn't really figure out why that was so important and decided to apply the pillars we found interesting. Mistake number 1.
We applied XP for about a year and a half and found it to be lacking certain elements to it. We felt the process was missing key quality assurance elements and was very exclusive to developers. Mistake number 2 we made was that we hadn't really applied eXtreme Programming, so who were we to judge. Anyhow, we tagged along and discovered MSF Agile and found it very interesting straight away. It had the roles we felt were missing and process elements that would fill in the missing gaps of what we felt were missing for quality assurance. We jumped aboard the train and never looked back (until today).
Mistake number 3; I found myself believing to my core that we had applied MSF Agile, at the time of introduction I was manager of application development and was working a bit more with processes and planning. I sincerely believed we had applied MSF Agile with all it's artifacts. Last spring I decided to leave the company for a job that looked very interesting (My personal mistake number X), only to find out that the company I started at was not interested in applying any form of methodology unless it was named adhoc. I decided to leave them after only 2 months and was quickly approached by the company I quit 2 months earlier and got an offer that was acceptable. I went back, this time being only a senior software developer and team manager for a smaller team (4 people, including myself). I decided at that point that I'd had it with all the management stuff, I wanted to primarily write code, but it wouldn't hurt to have some control over a specific part of the application we are working on. Anywho.. After a couple of months I started to see something very strange. We weren't working according to any process, or at least any process I knew. I got really pissed off and started ranting openly about why aren't we working according to MSF Agile (My personal mistake number X+1). The truth was that when I was too busy planning our next big project and going around believing that everyone was working according to the process, people didn't know the first thing about the process. No one had read the process guidance on our sharepoint site even. I kept ranting and was honestly really fed up that there hadn't been anyone who took charge and applied the process we had agreed upon.
And now back to the title of this post. Why do I think agile is fragile, in fact I think most processes are fragile in the sense that if you don't apply the process correctly, the process will collapse under it's own weight. Agile is fragile is just a cool title, I honestly think the statement applies to all processes. So, why are they so fragile. Take for instance "embrace change" that agile methodologies has in it's core. The concept of having code that can be changed, refactored, feature change at any given point in time demands that you apply TDD. Without unit tests you would really need to be a cowboy in order to dare to start a major refactoring job. The unit tests serves as a safety net that assures you that the code you are rewriting will still result in a working piece of software. Another example is pair programming. In order to achieve full global ownership to the code, pair programming must be applied. The beauty of pair programming is that you spread the knowledge about the code throughout your team like a wildfire. If you drop this and let developers specialize, global ownership is lost. Pair programming is probably the pillar that is hardest to apply in a team. Many developers will argue not to be part of it at all. Pair programming is not an aspect of MSF Agile. That's probably why global ownership is not a part of MSF Agile. Yet another example is the fact that the customer should be available all the time. By customer one means an actual customer or a representative for the customer that is located within the team or is available within the organization. Without having the close relationship to the customer, you will not be able to see if the project is on the right track between iterations. An agile project needs to correct itself all the time, this is done through the use of iterations. The length of the iteration can be 1, 2, 3 or 4 weeks. It is not recommended in most cases to have them go for more than 4 weeks. If you don't have the customer available at these junctions, you will not be aware of any mistakes you might have done. That means you're back to waterfall were you have a test period at the very end of the project. A very important aspect of all agile methodologies is that all roles work actively for every iteration. That means that you're planning, writing unit tests, writing code, acceptance testing and so on for every iteration. Loose one of the activities and it all collapses. I could go on and on about other fragile relationships in agile methodologies, my point is that you must be really careful about applying a whole process no matter what process you decide to apply.
The beauty of having time of work (I'm on my paternity-leave or sick-leave, not sure which one yet) and really not think about work, totally disconnected from work (I'm not even reading emails..), is that you get a lot of time to think about stuff like this. I've come up with a couple of rules that I believe is important when trying to apply a software development process :
1. Whenever you want to apply a process, one would think that having management with you should be sufficient. Wrong. You need the entire team. Every single member of the team must embrace the new process. They don't have to like it at first, but they have to agree to be willing to try it out and work according to it.
2. You need to be really strict when applying the process. You can't afford to not apply the whole process. Most processes will collapse if you do so.
3. Stretch to fit - not shrink to fit. You can adjust the process so it fits to your needs by adding to it, never removing!
4. You need at least 2 persons in the organization that are not only masters of the process, but also really enthusiastic about it. They will act as motivators for the others.
5. Train everyone! If everyone is trained in the process, and if possible, certified in it, you'll automatically have a process-cop in every single member of the team. Together the team will apply the process and correct any mistakes that is bound to happen.
I'll probably come up with a couple more rules as the days fly by sitting here doing nothing. Feel free to drop me a comment if you have input to the madness above.. :)
