Saturday, 5 October 2013
Thursday, 22 May 2008
I have enjoyed listening to Joel and Jeff talking about, well anything that comes up while they set up a community based site for finding answers to programming questions, at:
It's not overly technical, but it is interesting to listen to two people with very different approaches to development talk about a variety of subjects.
Craig Andera and Tim Ewald have been podcasting occasionally and have some interesting insight on RESTful services and also interviewed Jon Lam about Iron Ruby. It doesn't have a feed that I can find or a tag so I have linked to the latest and there are links there to the previous podcasts:
and Software Engineering Radio has many really good podcasts and interviews on a really broad range of subjects. Because it focuses more on software engineering, they also talk about a wide range of technologies:
If you have any other suggestions please feel free to post them.
Sunday, 18 November 2007
Go here and spend your 100$(virtual) and make a difference.
If you still need convincing that an automated build is important, Jeff Atwood has a good post on why F5 is not your build process. His reference to Hacknot's if they come how will they build is too scarily close to the reality in far, far too many companies.
I try to do something to improve the build process everywhere I work. I believe we all should.
Wednesday, 31 October 2007
Ever added a C# project by accident when you meant to add a Test project? And only realized after writing a test, adding all the references and not finding it in test manager?
I have; and I can never remember exactly how to fix it. I'll post the steps here so I can find it in the future, and maybe help other people with the same issue.
Test projects are aggregate projects (language and type) and these properties are set under an element in the project file called projecttypeguids.A test project looks a little like this:
<propertygroup><configuration condition=" '$(Configuration)'== '' ">Debug</configuration>
- Right click on the project in question and choose "unload project".
- Right click on the project again (it should now be grey and look something like [project name](unavailable) and select Edit [project name].
- for c# add:
- for vb add:
- Right click once again and choose "Reload project"
Hope this helps someone out there.
Sunday, 3 June 2007
I find the background compilation in vb.net, as it is currently implemented, does not work well for me. I often write the main structure of my code(which doesn't compile) and then fill in the gaps. And vb.net tells me it's wrong; except it isn't wrong, I just haven't finished. Ian finds this annoying as well and calls it Background Irritation.
Although it is, in someways, comparable to background spell checking, I find it is as irritating as MS Word's AutoCorrect. AutoCorrect decides that what I just typed is not what I meant to type and changes it. This works fine for "teh" and other such errors, but often AutoCorrect changes TLAs and other words until the meaning of what I have just written changes completely. Worse, it does it without telling me, which is very frustrating. But, I can switch it off when I know that I am writing something that it will cause me hassle with. In fact, now I think about it, I even use spell checking like I use the compiler. I write my text, I scan it to make sure that I think it's ok and then I ask the spell checker to double-check for me.
So what is wrong with background compilation? I want it on when I am bugfixing. I want it off when I am writing from scratch. I want it to work like that in c#. I don't care if it is on by default. But if it doesn't have a switch I don't want it. Therefore, for a tool to be useful to a good developer, it needs to be written as something that can be reached for when needed.
And on the subject of the c# compilation tax, VB.Net's bacground compilation is not free. The MSDN article Scaling Up: The Very Busy Background Compiler has some hints to help with large projects. But the idea of changing my code or switching off other features to help the performance of another feaure that I don't always want on, just seems to reinforce my perception that this needs a switch.
Saturday, 7 April 2007
By default single startup project is selected and the project currently in the drop down is what visual studio will try and start. I have recently acquired a taste for current selection (when you have are writing unit tests it is particularly handy for quickly running the current test project).
You can change the default for this by navigating to tools-->options-->Environment-->Projects and Solutions-->Build and Run. And there tick the check box "For new solutions use the currently selected project as the start up project". If you have a large solution it may also be worth checking the "Only build startup projects and dependencies on run" in order to avoid building everything to run some low level test.
Incidently, changing the default startup options doesn't just effect new solutions as the name suggests, it will effect any solution that doesn't have an options file (solutionname.suo). This means that in a team environment, as long as everyone has their own solution option files, changing this option will not effect other users.
Wednesday, 4 April 2007
switch the radio button to "Align attributes each on a seperate line".
then ctrl-k, ctrl-d your way to easy to read xml files.
Most useful when something updates your xml for you, like updating a WCF service reference.