I can never remember all the options for string formatting, particularly the ability to 'pad' strings - in the past I've written padding methods in C# because I didn't know about the format specifier!
idunno.org: String.Format("{0}", "formatting string"}; has a good reference for the most common format specifiers...
idunno.org also has a good reference for accessing IndexServer from .NET.
Thursday, 29 July 2004
Sunday, 18 July 2004
ASP.NET HtmlControls vs WebControls
One of my 'standard' questions when interviewing for ASP.NET Developer roles is What is the difference between HtmlControls and WebControls?
I have not yet received a really good answer from any candidate, and I've been using this question for over 18 months in a number of interviews... I've just finished another round of interviews and haven't found much understanding of this stuff!
These two articles go some way towards explaining the issues:
What I want to hear is:
Things I don't want to hear are: HtmlControls don't run on the server, HtmlControls don't have ViewState support, HtmlControls are somehow less useful, confusing HtmlControls with non-runat=server Html tags in the source.
If you've done any Mobile development then it might help if you know how the BroswerCaps works to render cHTML/WML/etc on different devices...
Bonus points for: Mentioning the INPUT TYPE=FILE HtmlControl and how it works when run as an HtmlControl, mentioning the asp:Literal control and how all 'static' text between Server Controls on a page becomes an instance of the Literal control during page parsing, mentioning the more complex WebControls such as Date Picker and the Validation controls.
You're hired if: you can explain what happens when WebControls are rendered on up- and down-level browsers; you can explain the barriers to the WebControls being rendered as up-level on non-IE browsers, the issues with the Validation controls in thisi scenario and how to fix them; and you know why these two namespaces are significant for control rendering System.Web.HttpBrowserCapabilities and System.Web.Mobile.MobileCapabilities...
I wonder how many candidates 'Google' their prospective employers/interviewers...
UPDATE: words to avoid in your resume
I have not yet received a really good answer from any candidate, and I've been using this question for over 18 months in a number of interviews... I've just finished another round of interviews and haven't found much understanding of this stuff!
These two articles go some way towards explaining the issues:
What I want to hear is:
- With HtmlControls, you *know* what the output will look like at design time (basically what you've typed, with the runat="server" gone)
- The HtmlControl.HtmlGenericControl is the *only* way to accomplish some things neatly like manipulating the TITLE, META and other tags
- WebControls have a 'consistent' object model (ie. they all have a .Text property, whereas HtmlControls might require using .Value or .InnerHtml)
- WebControls *may* be rendered differently depending on their attributes OR the BrowserCaps of the browser. Eg. an asp:TextBox might be rendered as an INPUT or TEXTAREA if TextMode="mulitline"; the Date Picker will be drastically different on up- and down-level browsers
Things I don't want to hear are: HtmlControls don't run on the server, HtmlControls don't have ViewState support, HtmlControls are somehow less useful, confusing HtmlControls with non-runat=server Html tags in the source.
If you've done any Mobile development then it might help if you know how the BroswerCaps works to render cHTML/WML/etc on different devices...
Bonus points for: Mentioning the INPUT TYPE=FILE HtmlControl and how it works when run as an HtmlControl, mentioning the asp:Literal control and how all 'static' text between Server Controls on a page becomes an instance of the Literal control during page parsing, mentioning the more complex WebControls such as Date Picker and the Validation controls.
You're hired if: you can explain what happens when WebControls are rendered on up- and down-level browsers; you can explain the barriers to the WebControls being rendered as up-level on non-IE browsers, the issues with the Validation controls in thisi scenario and how to fix them; and you know why these two namespaces are significant for control rendering System.Web.HttpBrowserCapabilities and System.Web.Mobile.MobileCapabilities...
I wonder how many candidates 'Google' their prospective employers/interviewers...
UPDATE: words to avoid in your resume
Saturday, 17 July 2004
"Universal" or "Neutral" Spanish Translations
There's always something new to learn about software localization - for instance
Microsoft's approach to creating "Universal" or "Neutral" Spanish Translations.
I suppose if you asked the 'person on the street' they might think there _is_ only one Spanish (or French, for example) language - at the other extreme if you asked a Mexican, Bolivian (or New Caledonian/French Canadian) they would probably insist their native tongue is quite distinct from that used in Spain (or France).
When faced with localization in these languages, the two obvious solutions might be:
* use the 'original' language and expect it to work in all other countries; or
* localize into each and every 'dialect' of the language to ensure you do not alienate customers in each country.
The (think outside the square) solution is, of course, to merge these two ideas -- purposefully structure the language you use so that it appears natural to ALL speakers. That's actually a lot harder than it sounds, but reducing the number of software versions you have to ship from ten to one (eg. in Spanish) certainly appears to make it worthwhile. This i18nguy article about Microsoft discusses the concept of “Universal” or “Neutral” Spanish and particularly Latin American Spanish (es-americas).
Microsoft's approach to creating "Universal" or "Neutral" Spanish Translations.
I suppose if you asked the 'person on the street' they might think there _is_ only one Spanish (or French, for example) language - at the other extreme if you asked a Mexican, Bolivian (or New Caledonian/French Canadian) they would probably insist their native tongue is quite distinct from that used in Spain (or France).
When faced with localization in these languages, the two obvious solutions might be:
* use the 'original' language and expect it to work in all other countries; or
* localize into each and every 'dialect' of the language to ensure you do not alienate customers in each country.
The (think outside the square) solution is, of course, to merge these two ideas -- purposefully structure the language you use so that it appears natural to ALL speakers. That's actually a lot harder than it sounds, but reducing the number of software versions you have to ship from ten to one (eg. in Spanish) certainly appears to make it worthwhile. This i18nguy article about Microsoft discusses the concept of “Universal” or “Neutral” Spanish and particularly Latin American Spanish (es-americas).
Thursday, 15 July 2004
MS: Hazards of Hiring
The Hazards of Hiring is the last topic I expect to read about on MSDN -- but relevant since I'm hiring at the moment.
The other article I found useful was the Guerrilla Guide to Interviewing, which I may have blogged previously (but it's worth another look).
UPDATE [7-Sep] WHY is it that candidates no longer feel any compulsion to do any research on a company before attending an interview. My first question is always "What have you learned about our company?" or "Did you review our website?" -- the answers to which are inevitably "No..." Why waste your time (and mine) by turning up to an interview where you don't even understand what our company does? This laziness is so common that it's ceased to be a useful measure of a candidate's interest in a position, because NONE of them bother to do it!
The other article I found useful was the Guerrilla Guide to Interviewing, which I may have blogged previously (but it's worth another look).
UPDATE [7-Sep] WHY is it that candidates no longer feel any compulsion to do any research on a company before attending an interview. My first question is always "What have you learned about our company?" or "Did you review our website?" -- the answers to which are inevitably "No..." Why waste your time (and mine) by turning up to an interview where you don't even understand what our company does? This laziness is so common that it's ceased to be a useful measure of a candidate's interest in a position, because NONE of them bother to do it!
Wednesday, 7 July 2004
Character-set/encoding detection using C# - NCharDet
NCharDet is a C# port of the Java JCharDet, which is based on C++ code used in the Mozilla open-source browser project.
I don't yet fully understand the implications of the Netscape Public Licence so the code is just posted on my website for now.
I was disappointed that I couldn't find info on this already available on the web - particularly that no-one seems to have got MLang.dll running under COM Interop with C#/.NET...
I don't yet fully understand the implications of the Netscape Public Licence so the code is just posted on my website for now.
I was disappointed that I couldn't find info on this already available on the web - particularly that no-one seems to have got MLang.dll running under COM Interop with C#/.NET...
Saturday, 3 July 2004
Populating a Search Engine with a C# Spider on [The Code Project]
My two Searcharoo search engine articles are now also available on The Code Project
as well as on my personal website... a friend suggested they might get better coverage there - and so far a couple of very useful comments, so it was a good idea!
ALSO I just came across an excellent article about Integrating Unit Testing into the Software Development Lifecycle - check it out.
AND FINALLY, this is also a great post/book review of Debugging the Development Process by Steve Maguire. Even if you don't read the book - READ THE POST.
- Static-Site Search Engine with ASP.NET/C#
- The Code Project - Populating a Search Engine with a C# Spider - ASP.NET
as well as on my personal website... a friend suggested they might get better coverage there - and so far a couple of very useful comments, so it was a good idea!
ALSO I just came across an excellent article about Integrating Unit Testing into the Software Development Lifecycle - check it out.
AND FINALLY, this is also a great post/book review of Debugging the Development Process by Steve Maguire. Even if you don't read the book - READ THE POST.