I am no R# Jedi so it could very well do this but I found my self wanting R# to check old code for Microsoft naming conventions (checking case etc), I know R# can apply suffix and prefix to naming styles but I really want to be able to apply a refactoring across old code to get it up to convention quickly.
Update: I came across this commerical opensource tool that will point out violations in naming standards and also apply refactorings, would be great to see something like this in R#.
Opensource is a funny old game, we do it for love (of software) and not love of money. You work when you want and how you want. You get to use technologies and explore ideas that are not constrained by your management\clients. You also get to work with and learn from some of the brightest minds in the industry. You just don't get paid for it, something has to give :)
As many of you might (or might not) know I run a OSS project called MbUnit, and its a busy time on the project. We are fixing bugs and adding small features and the 2.4.1 release is shaping up. We are working very hard on shaping up the documentation and website. We also have MbUnit Gallio underway, I'll be talking more about that later in the year. MbUnit has an amazing set of folks working all day and night on it but I'd like to attract more folks to the project, helping to fix bugs, write some cool docs (even cool articles would be appreciated), in a nutshell spare me any time you have. If you think you can, drop me a line on the contact form and we can talk.
The costal waters around the UK are unique in that sea and costal rescue is provided by a professional organization called the RNLI that is funded entirely by voluntary donations and staffed by volunteers (they don't get paid to risk their own lives to save yours). The RNLI runs in my family and is a cause I feel very strongy about, I ask that if you use the UK coasts and sea that you consider helping these folks as you may one day need their help. Check out this collection of videos and links to help see what they do, what it means and how you can help.
Some slightly older guides knocking about on the web, the easiest way of adding MbUnit to CCNet is to change the XSL reports (you can try the plugin option if you want). As noted in an earlier post, the XSL to show MbUnit reports is shipped with CCNet so you will have everything you need. I will get this into the docs I promise but for now here is a quick guide.
Get MbUnit reports into CCNet.
You will need to ensure that MbUnit is reporting to XML (you can use either the msbuild, nant or console tasks for this) and is merged into the CCNet XML by changing the ccnet.config and your projects MERGE group.
Use MbUnit XSL
When this is done you will need to change CCNet to use MbUnit XSL over the default NUnit XSL. You will need to make this change for the webdashboard and the server. There two ways of doing this, the easiest is to rename files (in the XSL folder) as follows.
-
unitests.xsl to unitests2.xsl
-
MbUnitSummary.xsl to unitests.xsl
-
tests.xsl to tests2.xsl
-
MbUnitDetails.xsl to tests.xsl
The other option is
-
change the ccservice.exe.config and the xslFiles section replacing tests.xsl with MbUnitDetails.xsl
-
change the dashboard.config, replacing unitests.xsl with MbUnitSummary.xsl and tests.xsl with MbUnitDetails.xsl.
Update: More rules being added in the comments, I have added rules 6 and 7 this morning after sleeping on this one :)
I was talking the other night with a friend about their interview experinces and in particular the how the interviewer gave the interview. I have seen a tons of interview prep posts (which I might do all the same) and not a lot on how interviewers go about it (as most seem to think that they do what ever they please, not so).
Rule .1, Don't behave like prat.
The interview is to assess the candidate against the needs of your company, your team and the role within it. Remember that you are likely to be the first person the candidate will see and as such you represent your company and your team. So lets get something stright, no one likes a prat and if you treat the interview as "power trip 101" you won't be hiring any time and it reflects badly on your company and your team. The net result is that rather than hire to solve your staffing problem you have fields of p***ed off candidate's, telling anyone within ear shot how much you suck.
Don't use the interview to boost your ego or be a smart ass, no one likes either and it achieves nothing. The candidiate will be nervous and that will reflect as either someone being quiet or loud, the key skill is put them at ease, make sure they are comfy and relaxing so you assess them as close to their true self as possible. Do start slowly and build up, do wait for an answer (pauses can useful if you think they have something else to add but don't over do it) and don't interupt if a candidate is still answering). You want the candidate to be free thinking and flowing with their answers, nerves, frustration and plain anger (at your behaviour) achieves nothing.
Rule .2, Do your home work
You expect candidates to do there home work on your business so do the right thing and do your home work on them. You should have a clear idea of what education, skills and experience your after, go through the CV with a fine comb. The candidates that match your requirements are the ones you choose first, any that are grey but peak your interest go next. Look for examples of project work and problem solving and look for examples of candidates that go further, do they take part in open source, run a user group, speak at confs etc. Look them up on the internet, have they written articles, books, do they blog and if so what subjects do they favour. All these things help you see the candidate beyond the CV and will help you draw discussion points for the interview.
Rule 3, Do ask for code
I am not a fan of whiteboard coding at interviews, do we write code in the real world on a white board, I think not. However code samples are a great discussion point and if you create a code sample for them to create before the interview it gives you a chance to see how they solve problems and more to draw questions for the interview. A few things to remember here, create a spec even if its a use story and ensure you map out the minium requirements of what you want (e.g. a command line and not bell and whistles GUI etc).
Unless you give code standards don't expect them, even if you ask for Pascal notation it gives the candidate an idea. Don't expect tests unless you ask for them, should the candidate have created a test suite then make sure that counts in the interview (ask them why they created a test suite and if you asked for them what the testing aims were). Don't be tempted to use the code sample to create some over complex example, it will take too long to get through. Instead look at key areas where the candidate could possibly improve, ensure that candidate knows you may ask these questions so they have time to think about it and you can draw it back to any experince they may have.
Rule 4, Take them on a walk about.
Show them your work place and introduce them to your team. Afterwards you can judge reaction from your team about their inital impressions, don't draw too heavily on these however as your team is a bunch of strangers to the candidate and vice versa. Do use it as a tool to see if the candidate asks questions and understands some of your process's.
Rule 5, don't be late.
Can't be helped sometimes but leaving a candiate to sweat for a while after arrivial is a favoured technique to drive up the candidates nerves. If you can't start the interview at the allocated time, make sure the candidate is offered a drink and understands you can't start at the allocated time.
Rule 6, don't ask stupid questions.
Some interview questions (manhole covers and blue sweets for example) are designed to help an interviewer look for how a candidiate solves problems, however its nothing that questions about experince from the CV and rule 3 won't let you understand in a clearer fashion. You should also keep the questions relevant, asking about tools or technologies that the person used 12 months ago is a memory test and not a test of skills or attuide. If you want to understand what the candidiate did 12 months ago then ask them how they used the technology, what problems they faced and how they over came them. Not questions that ask on the webservice project in June 2001 what the 12th line of the SOAP packet looked like.
I agree with Derick (in the comments) that making the candidate feel foolish is as pointless as it gets. If the candidate does'nt know the answer then don't make a point out of it, rephrase the question or relate it back to experience or the code sample. Don't be tempted to ask a ton of technical questions that have no referance unless your running a test and not an interview, which brings me to rule 7.
Rule 7, it's an interview not a test.
If your testing the candidiate then let them know before hand, don't spring a quick 20 questions on C# and expect them to do well. If you want to test what a candidiate knows then should really use rule 3 for that and formulate questions that relate directly back to something a point of referance that you both have.