I'm working on a project that allows the user to dynamically specify the language used in the UI. This can be set independent of the operating system language settings, and is immediately applied.
In our case, most of our strings are retrieved from resources using ResXFileCodeGeneratorEx tool-generated code. When the user switches the language, we simply set the application CurrentCulture and CurrentUICulture, and refresh the display.
However, I currently ran into an issue where a dialog box wasn't displaying text in the alternate languages. The localized text was in the resource, and everything should have been working as expected.
After a little digging, I realized that the dialog was being displayed in the context of another thread. I would have expected that the .Net framework thread initialization code would use the culture of the executing thread, but rather it defaults to the current OS culture. Subsequently, attempts to retrieve a localized string on that new thread would return text in current OS culture (English) -- not what was anticipated.
The solution was to simply set the Thread.CurrentUICulture (and Thread.CurrentCulture) properties to the values from the executing (main) thread:
thread.CurrentUICulture = System.Threading.Thread.CurrentThread.CurrentUICulture;
thread.CurrentCulture = System.Threading.Thread.CurrentThread.CurrentCulture;
Monday, August 18, 2008
Thursday, August 14, 2008
Failed string.Format w/ Parameters using CJK
I recently ran into an issue in a localized application that was using the C# .Net Framework string.Format("blah-blah {0}", parm1).
In English, everything worked fine and as expected. However when using a localized format string (Japanese), the parameter substitution failed:
string.Format("数字は、｛0｝", parm1);
(If you don't have the necessary language pack installed, here is a image representation of the text:
)
It turns out that the translated text was using different braces than 0x7B and 0x7D. In the translated text the left brace was 0xFF5B. Looks like a brace, but isn't for the purposes of string.Format. Further, in looking at the MS Mincho char set, I couldn't find that particular brace. Using the Alt+65371 trick for that character in notepad, I'd get a left bracket -- don't know what/where the brace comes from...
The simple fix was to change the 0xFF5B brace to the correct 0x7B, and then string.Format worked as expected.
In English, everything worked fine and as expected. However when using a localized format string (Japanese), the parameter substitution failed:
string.Format("数字は、｛0｝", parm1);
(If you don't have the necessary language pack installed, here is a image representation of the text:
)It turns out that the translated text was using different braces than 0x7B and 0x7D. In the translated text the left brace was 0xFF5B. Looks like a brace, but isn't for the purposes of string.Format. Further, in looking at the MS Mincho char set, I couldn't find that particular brace. Using the Alt+65371 trick for that character in notepad, I'd get a left bracket -- don't know what/where the brace comes from...
The simple fix was to change the 0xFF5B brace to the correct 0x7B, and then string.Format worked as expected.
Friday, July 18, 2008
Bugs - Should You Estimate the Effort?
Is there a purpose to estimating the effort that a bug (defect) will take to fix? I think not.
Presuming that the bug has been properly prioritized (id est -- will it be fixed in this release or the next), there is little reason to spend the time estimating the effort that bug will take to fix.
For the purposes of this argument, I don't consider the following bugs:
- Text and UI fixes. The UI shouldn't be implemented by a traditional developer; it should be largely defined and implemented by the team UI designer.
- Misunderstandings. Spec said this, developer implemented that. This isn't a defect in the code, it is a misunderstanding or failure in the communication process -- both of which should be examined and fixed.
- Spec changes. Not a bug, but a feature request or revision.
So, considering legitimate bugs -- something implemented to do a certain behavior, but doesn't -- what is the point of estimating? Presumably the original implementation by the developer was thought-out (and developer tested!), but it isn't behaving now as expected. How can someone actually presume to know how long it will take to: first, find the issue; second, fix the issue? Assuredly most any estimate provided will either be too short or too long -- so what is the value?
Bugs should be prioritized, and then fixed. Don't waste effort on estimation.
Presuming that the bug has been properly prioritized (id est -- will it be fixed in this release or the next), there is little reason to spend the time estimating the effort that bug will take to fix.
For the purposes of this argument, I don't consider the following bugs:
- Text and UI fixes. The UI shouldn't be implemented by a traditional developer; it should be largely defined and implemented by the team UI designer.
- Misunderstandings. Spec said this, developer implemented that. This isn't a defect in the code, it is a misunderstanding or failure in the communication process -- both of which should be examined and fixed.
- Spec changes. Not a bug, but a feature request or revision.
So, considering legitimate bugs -- something implemented to do a certain behavior, but doesn't -- what is the point of estimating? Presumably the original implementation by the developer was thought-out (and developer tested!), but it isn't behaving now as expected. How can someone actually presume to know how long it will take to: first, find the issue; second, fix the issue? Assuredly most any estimate provided will either be too short or too long -- so what is the value?
Bugs should be prioritized, and then fixed. Don't waste effort on estimation.
Does Agile/XP Work? Part II
Mindy brings up a good point about communication. Ah, communication, simple communication, where art thou?
Where I agree that communication is essential for success in any group or methodology, I've observed a deeper core issue that has negatively impacted the success of Agile projects that I've been involved in: a failure to account for group personalities.
If you are politically correct and don't agree with generalizations, the following is probably going to rub you wrong. That is fine, you can ignore reality all you want.
The simple fact is that there are generalizations that most definitely apply to a development team. Think about it for a moment: what kind of person chooses and becomes a developer? How about a tester? Writer? In general terms, there are specific personality characteristics for each of these types of classes of people.
Consider developers -- usually quiet, pensive, not combative, don't ask too many questions, and don't like to admit they are wrong.
Now consider testers -- opinionated, always right, looking for problems.
The other classes are equally different.
For traditional development methodologies, there are teams constituted from the same people, so why would Agile be any different? The reason is that Agile is dynamic -- things change by the moment because some customer requirement changes, something is hard to do, there is a better way for something else, etc. -- all of these changes are spawned by someone voicing something. For those groups of people that like to voice opinion -- no problem; for those that don't... See my point?
Where I agree that communication is essential for success in any group or methodology, I've observed a deeper core issue that has negatively impacted the success of Agile projects that I've been involved in: a failure to account for group personalities.
If you are politically correct and don't agree with generalizations, the following is probably going to rub you wrong. That is fine, you can ignore reality all you want.
The simple fact is that there are generalizations that most definitely apply to a development team. Think about it for a moment: what kind of person chooses and becomes a developer? How about a tester? Writer? In general terms, there are specific personality characteristics for each of these types of classes of people.
Consider developers -- usually quiet, pensive, not combative, don't ask too many questions, and don't like to admit they are wrong.
Now consider testers -- opinionated, always right, looking for problems.
The other classes are equally different.
For traditional development methodologies, there are teams constituted from the same people, so why would Agile be any different? The reason is that Agile is dynamic -- things change by the moment because some customer requirement changes, something is hard to do, there is a better way for something else, etc. -- all of these changes are spawned by someone voicing something. For those groups of people that like to voice opinion -- no problem; for those that don't... See my point?
Monday, July 14, 2008
Does Agile/XP Work?
I've now been involved in three different projects of about five releases, each using a slight variation of the Extreme Programming (XP) (we are using the Industrial -- IXP -- variant) for approaching 5 years.
So, in a nutshell, does it work?
My opinion is YES and NO.
YES, the TEST DRIVEN DESIGN (TDD) aspects work and have lead to much more maintainable code, not to mention a better code design.
As for the NO part -- agile/XP ONLY works if there is complete buy-in from the entire team, and related supporting (read: management) personnel. Without a strong and ongoing commitment from all involved, XP doesn't work.
Further, XP can't be forced -- the individual must have the vision and the self-determination to follow that vision. Forced XP produces poor results: estimates that aren't accurate, non-optimal productivity, and code that suffers in quality and maintainability.
Each team (customer, QA, development) must continually train, review, evaluate, and improve their practices. If this isn't happening, organically, then there is more than likely a problem, or soon will be.
So, in a nutshell, does it work?
My opinion is YES and NO.
YES, the TEST DRIVEN DESIGN (TDD) aspects work and have lead to much more maintainable code, not to mention a better code design.
As for the NO part -- agile/XP ONLY works if there is complete buy-in from the entire team, and related supporting (read: management) personnel. Without a strong and ongoing commitment from all involved, XP doesn't work.
Further, XP can't be forced -- the individual must have the vision and the self-determination to follow that vision. Forced XP produces poor results: estimates that aren't accurate, non-optimal productivity, and code that suffers in quality and maintainability.
Each team (customer, QA, development) must continually train, review, evaluate, and improve their practices. If this isn't happening, organically, then there is more than likely a problem, or soon will be.
Subscribe to:
Posts (Atom)