Xml Namespaces I've Loved and the Nature of RSS

Yesterday, during yet another interview, we didn't deliver quite  the finest explanation of what an XML Namespace is. Today, we're using them to parse a Stack Overflow feed so clearly we understand them, however, if part of the question's purpose is to assess our ability to express this simple idea simply then shitehawks! #fail

Take this feed, for example, which is the RSS for a useful post on Volatile vs. Interlocked vs. lock. In order to to be able to use XPath with XDocument to retrieve the question we rely on XmlNamespaceManager.

[code:c#]

    var xDoc = XDocument.Load("http://stackoverflow.com/feeds/question/154551");

    var xmlNamespaceManager = new XmlNamespaceManager(new NameTable());
        xmlNamespaceManager.AddNamespace("atom", "http://www.w3.org/2005/Atom");

    var postedQuestion 
        = xDoc.XPathSelectElement("/atom:feed/atom:entry/atom:summary", xmlNamespaceManager);

[/code]

This is another example of Stack Overflow brilliance. The feeds are in chronological order so that we can guarantee that the first item (or entry) is the original post. Following the Volatile trail leads to a Joe Duffy post on Volatile Reads and Writes, and Timeliness. For example, he writes the C# documentation for volatile is highly misleading with reference to the following MSDN documentation:

The volatile modifier is usually used for a field that is accessed by multiple threads without using the lock statement to serialize access. Using the volatile modifier ensures that one thread retrieves the most up-to-date value written by another thread.

Unfortunately, I can't find this specific RSS item within the Technology feed and the same is true for the RSS feed for this blog. Although it's possible to score a reference to the item if it appears within the list of entries as they each have a unique ID, should the category contain too many entries then the older posts don't show up. Soon I'll show why this might matter but I digress.

The quoted paragraph above came as some surprise and a few hours reading suggests that:
  1. This stuff is hard!
  2. It would take *years* at the exclusion of a whole lotta stuff to have a legitimate claim to deep understanding of the intricacies of threading in .NET
  3. A solid handle on this C# Threading series of posts might just be enough (for now).
The real trick, however, might be recall during interview. There's definitely a theme here.

Comments (12) -

  • Ever thought this might not be what you are being asked? I was asked this recently and it wasn't from a .net perspective. Just simple, very simple XML.
  • You're right. Nothing to do with .Net really but I thought answering the question with an explanation of code that needs to consider this might demonstrate an awareness/appreciation. It might have done if it had been better expressed. Thanks for the suggestion though.
  • When I was asked, all they apparently wanted was an answer saying why they are needed within an XML document. So I gave the answer about how if types with the same name were represented the namespaces allow processing code to differentiate between the 2. Inhave to ask, you say we interviewed a lot. I have never been to an interview with more than just me. So who is "we"?
    • The "we" is a long-running joke about there being no "I" in "team" and then there's the Royal We: http://en.wikipedia.org/wiki/We

      Just one question of many. The most interesting one was about how I'd going about designing an email system to support over 100 million users and have it perform better than Google Mail. Your thoughts?
  • Just looking at your Twitter feed bit below. What did they ask you to do that required all that? Nh and membership?

    How did it go?
    • It was for an ASP.NET application I needed to write in four hours as part of an interview. Not being able to use the aspnetdb database (it existed already and I didn't have the necessary permissions) meant that I had to write some code to handle authentication which wasted a good amount of time because using the provided Login controls - some say they're naff but they work okay in simple scenarios - would have meant completing more of the application. I think I may redo it when I have time next week as a chance to practice TDD.
      • Code tests in interviews are your chance to show you know how to code not that you can use built in tools. Finishing a test is good but generally not the goal or expected. Based on what you said, I would have stayed clear of
        membership. Part of the reason is it is web only and whilst you said it was for the web you don't demonstrate you can think about the issues involved. Stick to the basics and when they are working, refactor or add extra stuff. It's mainly about how you layer a system. Eg multiple assemblies, using interfaces, etc. If you have time to get fancy then do but using membership is not fancy and only shows you can read the beginning asp.net books.
        • I'd agree with much of that. The idea wasn't to demonstrate fanciness but to try and complete as much of the application as possible and demonstrate good design. Admittedly, spending the next hour seething that I couldn't use membership wasn't helpful.

          I began mocking out the database calls thinking that I could do that quickly and leave database code until later but "soon" realised, after having spent too much time on writing custom mocks, that I'd end up mocking either session state or application state also to simulate repository behaviour. Not clever. I need to learn Rhino Mocks. Also the spec suggested completing vertical slices of the application.

          I wrote the trivial database code for authentication, the whole time realising that if I knew NHibernate well enough I'd have been able to just create domain objects and have the ORM handle persistence/retrieval for me and that would have saved some time. Lost more time having not remembered to differentiate between Response.Cookies and Request.Cookies.

          I didn't get anywhere near the end. The data access code wasn't great - who still writes data access code by hand? I've been using Code Smith intermittently over the years and should have taken that along alternatively.

          The overall design was poor and there was a lot of waste. I learnt several things:

          i. It wasn't a particularly good idea to use mocking in an unfamiliar environment when limited to a few hours for a complete solution.

          ii. It's definitely worth using some code generation tools. Membership included - for an ASP.NET webforms solution.

          iii. Ideally, it would have been ASP.NET MVC, TDD and NHibernate (but actual objects instead of mocks) and I'd have completed more of the application. I need to get adept with each.

          iv. Next time I'm taking a keyboard of my choice with me!

          v. Finally, I need to clean up as I go because there were too many unused/incomplete objects remaining and I should avoid hacking because time is ticking. I had a half decent design when I started out but that got thrown out as pressure mounted.

          It's worth pointing out perhaps that I have successfully written code during interview before. I've just not had enough practise building web applications from scratch within four hours. Funnily enough, I went back to the beginning asp.net books to make sure that there weren't some basics I was overlooking.
        • Hey Anon, Kofi is obviously a junior developer so give him a break.
          • Heh. I'm not a junior developer but sure, I've quite a lot to learn. It was quite painful re-deploying this site, for example. It was entirely manual and the process was error-prone. What do you use to deploy, codemonkey?
  • Whilst tools such as NH and mock frameworks are lovely, they are no substitute for being able to hand code when you need to. The part I am unable to understand is your comments regarding  taking your own keyboard, using code generation tools etc to an interview. You also made a comment about findin scripts online. If you are at an interview then you use the tools they provide. To me it would seem disrespectful to do otherwise.

    I find too many people focus on tools than an understanding of the language / technology they have chosen. Imagine a doctor who knew all these tools but then had to save someone without them. A lack of anatomical knowledge would be no excuse. A bit extreme an example but if you want someone to employ you and pay you, them you should be able to do the job.

    I'm not having a go at you. I just think too many people go on about the buzz words in IT to look better than they are. A solid understanding of the basics to me is much more important. So did you get the job or any feedback?
    • Hey Anon, appreciate the dialogue.

      I think hand-coding is great for spikes, prototypes and for those times it isn't possible to generalise. Also, when there's the luxury of more than four hours to build an application then hand-coding again makes sense. Code-generation exists for a reason and my experience is that it pays off knowing how to use the tools. That said, it's also important to know what's being generated, how it's being generated and how to fix/edit where necessary. I've cranked out code using the concatenate function in Excel, generated WSDLs and strongly-typed datasets from XSDs. These are all time saving devices and they deserve their place.

      I've been writing software long enough, for example, to see data-binding arrive, go out of fashion, reappear, disappear and I think it's back in fashion again. Or is it? Any day now the goto statement is going to make a come back!

      I've had two interviews during the last month during which I've had to write code. One was a pair session and for the other I was left to my own devices. In the first I needed to demonstrate complete familiarity with TDD whereas I've just dabbled with unit tests since about 2003. Often when I've written tests (in permanent employment) I've had to remove references to my test project before checking in the solution file. Sometimes when I've been hired as a consultant I've had the freedom to write tests and it was immensely satisfying.

      However, In two of the last three places I've worked the team leader, technical architect, head of development or boss guy has bunked unit testing so much of what I did to help ensure delivering software with fewer defects was in effect contraband. On one occasion I didn't write a unit test for a database change - I'm happy to use NUnit, for example, to test database code even though they're really part of integration testing. I keep these in a different project from that with the unit tests - anyhow, I didn't "unit" test the database changes and I got stung! It's also about knowing how to use the tools.

      Hand coding is essential, yes, but it's just one piece in a much bigger puzzle. I'm not sure how you've arrived at your moral judgement and your cultural values may be misplaced in at least these two cases. I suspect the interviewers were clued up enough to realise that an unfamiliar keyboard might hamper progress. If they'd supplied notepad.exe and csc.exe as my tools I'd have complained, however disrespectful that might seem to you. Let's not bind my feet and try to run!

      It seems to me that the closer we move to the problem domain - and yes I am one of these people who believe that it ought to be about pragmatism and providing business value - the less most of us should need to consider registers and low level operating system behaviour.

      I previously overlooked the "buzzwords" as you put it and when I heard first  about XP in 2001 I thought "buzzword" and didn't look into it. I wish I'd paid more attention to the "buzzword" because perhaps I'd not still be mistaken for junior programmer. I think eight years of scrum would have made me a better developer.

      You know, I think a more constructive exchange would involve me telling you about a recent hack I've done to see whether you've a better solution where I'm trying to avoid Reflection if possible and it might just come down to Namespaces. Now *that* would be useful rather than, say, my sharing a life story and offering some cultural context.

      No job! No feedback! Search continues. Thanks for your continued support.
Comments are closed