resource generation

C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin\resgen.exe will contain a tool called ResGen which may be used to run command line commands to transform .resx files into .resources files if one downloads it here and I am convinced that I need to use it to make my .resx files here accessible by the code I wrote.

(go vote today)

struggling with resources

Trying to follow an example in C# 4.0 in a Nutshell, I made welcome.en.resx as shown in the image. When inspected in notepad, the file ended like so:

   <data name="Greeting" xml:space="preserve">
      <value>hello</value>
   </data>
</root>

 
 

I also made welcome.de.resx for a German greeting.

   <data name="Greeting" xml:space="preserve">
      <value>hallo</value>
   </data>
</root>

 
 

The resources were in an MVC4 project. I tried to roll a test in a test project like so:

using System.Reflection;
using System.Resources;
using Microsoft.VisualStudio.TestTools.UnitTesting;
namespace ResourcesExperiment.Tests
{
   [TestClass]
   public class MyTest
   {
      [TestMethod]
      public void TestMethod1()
      {
         Assembly assembly = Assembly.LoadFile(@"c:\Tom\ResourcesExperiment\
               ResourcesExperiment\bin\ResourcesExperiment.dll");
         ResourceManager resourceManager = new ResourceManager("welcome",
               assembly);
         System.Threading.Thread.CurrentThread.CurrentUICulture = new
               System.Globalization.CultureInfo("en");
         Assert.AreEqual(resourceManager.GetString("Greeting"),"hello");
      }
   }
}

 
 

This blew up like this:

Could not find any resources appropriate for the specified culture or the neutral culture. Make sure "welcome.resources" was correctly embedded or linked into assembly "ResourcesExperiment" at compile time, or that all the satellite assemblies required are loadable and fully signed.

 
 

This and this had some advice, but I am yet to get around the problem. I tried putting the resources in a App_GlobalResources and/or App_LocalResources and I experimented with setting the Build Action to both Embedded Resource and Content. I also tried to just jam my logic into a Controller, setting a breakpoint at return View();

using System.Reflection;
using System.Resources;
using System.Web.Mvc;
namespace ResourcesExperiment.Controllers
{
   public class HomeController : Controller
   {
      public ActionResult Index()
      {
         ResourceManager resourceManager = new ResourceManager("welcome",
               Assembly.GetExecutingAssembly());
         string setBreakpointHere = resourceManager.GetString("Greeting");
         return View();
      }
   }
}

 
 

...and yet. I'm still screwing something up.

no parameters in test method signatures

If the TestMethod attribute decorates a method (assuming the Microsoft.VisualStudio.TestTools.UnitTesting namespace) one cannot have parameters in the method signature, otherwise the test will be reported at "Not Runnable" in the Test Results pane in Visual Studio.

em

One em is equal to the current font size while two ems are equal to to twice the current font size. In Internet Explorer, at the Page menu, there is an option for Text size which allows one to pick options for Largest, Larger, Medium, Smaller, and Smallest. If the size of a font is not concretely defined like so:

font-size: 10px;

 
 

...then its size will change as you change this setting. (By the way, I don't know how to change this setting in other browsers as I don't care.) This allows people to set the fonts to be really big if the web page they are veiwing is accomodating. If you want to be accomodating, but also wish to bias the font-size even as it changes, you can do something like this:

font-size: 1.1em;

 
 

...which is going to make the font 10% larger than the default across all five of the settings found in the Text size option in the Page menu. The pixel value settings in contrast will maintain one fixed size across all five of the settings.

I have a few questions for the room on documentation.

I looked through the slides here from a talk Emmelyn Wang undertook (with a Mr. Christopher Ward) on how documentation certainly provides a return on a company's investment and is moreover crucial to the financial health of an enterprise. I wasn't actually at the talk when it was held in Oregon so of course I'm just getting the gist, but the gist is:

• Documentation that has integrity, accessibility, and searchability is key. It serves as the go-to crutch for many processes and in its absence or weakness such processes will have dysfunction and businesses will suffer for it. Think of a call center's staff and how it does its job. Or, think of the scenes from "Love and Other Drugs" wherein Jake Gyllenhaal, as a Pfizer rep in training, tries to recite his talking points on Zoloft that he has to retain before a match at his fingertips burns him. Where does the information he needs to do his job come from?
• Pilot programs in the name of understanding what a process is and how the parties involved fit into it are a good way to start building that documentation which your gut tells you are lacking.
• Documentation is needed for presales.
• Documentation is needed post sales. It will empower your helpdesk, allowing the helpdesk to be... helpful, and hence increase customer loyalty. The slide deck has metrics on how many customers leave companies due to bad customer service experiences and how more than half of the time they are leaving for a competitor. The average business looses half of its customers every five years, but the average business should also be trying to do something about this problem. Improving customer retention is a good money-making strategy. It can cost up to five times more to gain a new customer than to merely keep one from leaving. Empower your own to stem the bleeding!
• Documentation is needed for contacts. A searchable CRM is a must have.
• At the end of the slide deck there is some data on our modern problem of a talent drought in IT. The good news is that if you were to make a pie chart of all of the tech jobs that American companies can't fill that there is a sizable piece of pie which can be populated by data analysts which does not demand an ability to write code.

I am convinced that Emmelyn is right!

The bad news is that I see a geek culture that struggles with documentation. There is a trend in favor of logging errors and also having good commentary when checking into source control, but there is also a trend towards writing readable code in lieu of having code comments, and, in an Agile process, there isn't going to be the upfront documentation of the Waterfall process. The latter two "negatives" are arguably not negatives at all, but, with regards to Agile, retrospective notes are largely the only documentation. It doesn't make sense to type up copy on what your application does when that wasn't defined upfront and is subject to change as development is underway. You could argue that someone should roll documentation on an application when it is "finished," but this doesn't happen in my experience.

At Veterans Affairs, I was put in charge of retiring a server running MSSQL2000 databases in the name of a bigger push to get away from MSSQL2000. Some databases had not been used in forever and could be dropped. Others had to be migrated to MSSQL2008. Largely, the only way to figure out what was what and what application something corresponded to was to speak to various people in the building I was working in. Little was documented.

I then became part of the problem myself. I rolled a bunch of documentation, but when I realized that my whole job was of documentation and playing with Excel and Outlook all day long, I found another job and got out of there. Again, I see a geek culture that struggles with documentation.

What are some potential solutions? Hire the right ratio of business analysts to developers? What will the analysts do during an Agile process? I'd love to hear any feedback!

Fun Fact: Emmelyn Wang is the only human being ever to work at both Headspring and Dovetail.

Addendum: Since writing this blog posting I thought of the stories that drive an Agile process. I suppose at development's end a holistic view of an application could be put together from the stories themselves as the sum of the stories executed upon would add up to what an application does. I've never yet seen what happens at the "end" of an Agile project.

I hate the GAC

If a library is in the Global Assembly Cache it is, per C# 4.0 in a Nutshell, going to take precedence over the same library in your bin folder. Confusing! I didn't know this until yesterday, but I've always loathed the GAC because it sort of "hides" dependencies by empowering a false belief that you have everything you need at your app. At least it does for me or anyone else who does not consciously think of the GAC.

div is depreciated in HTML5

...or is that deprecated? Whenever I'd use the term depreciated at HDRI someone would correct me and tell me to use deprecated. :)

Anthony Dominguez was telling me about this this morning and he asserted that one of the things mentioned in these presentations is that one should use a div to break stuff up as a last resort only. This idea is going to be a BIG change for me as div is my crutch for everything! Anthony said that the videos suggest using article and section instead of div. It looks like they both may have header tags inside of them and that at least section will accomodate a footer tag as well. Yikes. I remember how painful it was for me to stop crafting everything with Dreamweaver tables and go to a tableless design, embracing CSS. I'm in for another jarring change again.