Reflection snippet:

Type t = Type.GetType(kid.Attributes["type"].Value);
...
object o = t.Assembly.CreateInstance(t.FullName);


How to convert a string in ISO date format to a C# DateTime:

DateTime dt = DateTime.ParseExact(dateString, “yyyyMMdd”, CultureInfo.InvariantCulture);

Yet another DateTime conversion routine, this time using DateTime.ParseExact()

int integerDate = "20081113";

DateTime date = DateTime.ParseExact(integerDate.ToString(), "yyyyMMdd", System.Globalization.CultureInfo.CurrentCulture);

I can’t claim credit for this, as I saw it yesterday whilst receiving a demo of a (very good) messaging architecture written by another developer.  It’s only a little scrap of code, but that makes it even better: its beauty is its simplicity.  So, to get parameters out of some parameter holding class, but to not have to (a) make everything the same type or; (b) have N methods for retrieving N types, you can do this:

    public class Params
    {
        Dictionary _values = new Dictionary();

        public Params()
        {
        }

        public T GetParam(string name, T defaultValue)
        {
            if (_values.ContainsKey(name) == false)
            {
                return defaultValue;
            }
            return (T)_values[name];
        }
     }

Which you then call like this:

            Params p = new Params();
            int key1 = p.GetParam("key1", 39);
            string key2 = p.GetParam("key2", "defaultValue");
            double key3 = p.GetParam("key3", 44.2);

As a former physicist, and an experimental/numerical/computational physicist at that, I am often in conflict with the “Theorists” be they Theoretical Physicists or Mathematicians.  In a programming context, I find that Theorists want to map out every last detail and believe that they can explain and account for every possible situation on paper.  This isn’t so surprising when you consider that’s what they do/did as TPs or Ms.  Yet in my opinion the best thing you can learn, whilst moving from junior to senior programmer, is how much you don’t know about what might happen.  This led me to think up a pithy phrase to use against a particularly wiley Ph.D. mathematician/”programmer” (I use the latter term loosely…):

“Theory without Experiment is just a set of internally consistent reasoning”

or to put it another way

“Theory is Ego, Experiment is Humility”.

EDIT:  And this pithy re-write that I’ve just found here (http://stackoverflow.com/questions/58640/great-programming-quotes):

The difference between theory and practice is smaller in theory than in practice.

Is Courier New not good enough for you?  Give your IDE a new lease of life with one of these programming-specific fonts.  I’m currently testing Proggy Tiny, in 11 point size. 

http://keithdevens.com/wiki/ProgrammerFonts

select  RTRIM(LTRIM(rl.ric)) 'Identifier',
        case
            when (rl.code like '%46%' ) THEN 'True'
            when (rl.code like '%47%' ) THEN 'True'
            ELSE 'False' END D1,
        case
            when (rl.hard_restriction = 1 AND rl.hard_to_borrow=0) THEN 'Restricted'
            else '' end 'EventType'
from restricted_list rl_1
    inner join (select id, max(entry_date) as MaxEntryDate
                from restricted_list rl_2
                group by ric) rl_2
        on  rl_1.ric = rl_2.ric
        and rl_1.entry_date = rl_2.MaxEntryDate
order by rl_1.ric

I’ve been heavily involved in interviewing recently, both as a candidate and offering advice from the “other side of the fence”.  I’ve been spending a lot of time working out in my head exactly what the best way of interviewing is.  Below is a summary of what I’ve come up with so far, with each point to be extended in later posts.

• Decide exactly what you’re hiring for, the role and the tasks to be performed by that role. 
• Test for aptitude, not specific knowledge.
• Questions need to be fair: if you’re going to ask for very answers to very specific things, then consider sending the candidate an outline/”reading list” before the interview. 
• Remember that a good team has a mix of people, skills and backgrounds.
• Expect no more or less of your candidate than you expect of yourself – that includes turning up on time, a certain level of dress, the ability to answer questions, particular technical knowledge, etc., etc.

More to come.

Simple, first of all create a variable that contains (n*m) elements

>  a = rnorm(100*100, mean=100,sd=1)

then dimension it

> dim(a) = c(1000,10)

where the first parameter is the number of rows, and the second the number of columns.  Easy.

I am using R quite a bit at the moment and found a useful snippet of code to generate random “coin tosses”:

x <- sample(c(-1,1), 1000, TRUE)