Archive for the ‘Programming’ Category

Out of intellectual curiosity, I sparked up MonoDevelop and decided to see what would happen when I tried to compile the ASP.NET MVC source code. I figured that it would Just Work.  After all, I can use the .NET compiled assembly with no problems on Mono, so there really shouldn’t be any problems trying to compile the code.  Bad news is that there is one minor glitch.  Good news is the glitch is easy to work around and has already been fixed so it shouldn’t be a problem for future version of Mono.

When you compile, here is what you get:

Compilation failed: 1 error(s), 0 warnings

/home/tom/Projects/MVC-MS-Pl-original/MVC-MS-Pl/Mvc/FormCollection.cs(25,6): error CS0246: The type or namespace name `FormCollectionBinder’ could not be found. Are you missing a using directive or an assembly reference?

Build complete — 1 error, 0 warnings

So, this kind of surprised me.  Looking at the code, I did see the FormCollectionBinder in the code, it’s an embedded class within System.Web.Mvc.FormCollection, check out lines 68-88 below:

   1: /* **************************************************************************** 
   2:  * 
   3:  * Copyright (c) Microsoft Corporation. All rights reserved. 
   4:  * 
   5:  * This software is subject to the Microsoft Public License (Ms-PL).  
   6:  * A copy of the license can be found in the license.htm file included  
   7:  * in this distribution. 
   8:  * 
   9:  * You must not remove this notice, or any other, from this software. 
  10:  * 
  11:  * ***************************************************************************/ 
  12:  
  13: namespace System.Web.Mvc { 
  14:     using System; 
  15:     using System.Collections.Generic; 
  16:     using System.Collections.Specialized; 
  17:     using System.Diagnostics.CodeAnalysis; 
  18:     using System.Globalization; 
  19:     using System.Web.Mvc.Resources; 
  20:  
  21:     [SuppressMessage("Microsoft.Usage", "CA2237:MarkISerializableTypesWithSerializable", 
  22:         Justification = "It is not anticipated that users will need to serialize this type.")] 
  23:     [SuppressMessage("Microsoft.Design", "CA1035:ICollectionImplementationsHaveStronglyTypedMembers", 
  24:         Justification = "It is not anticipated that users will call FormCollection.CopyTo().")] 
  25:     [FormCollectionBinder] 
  26:     public class FormCollection : NameValueCollection { 
  27:  
  28:         public FormCollection() { 
  29:         } 
  30:  
  31:         public FormCollection(NameValueCollection collection) { 
  32:             if (collection == null) { 
  33:                 throw new ArgumentNullException("collection"); 
  34:             } 
  35:  
  36:             Add(collection); 
  37:         } 
  38:  
  39:         public IDictionary<string, ValueProviderResult> ToValueProvider() { 
  40:             CultureInfo currentCulture = CultureInfo.CurrentCulture; 
  41:  
  42:             Dictionary<string, ValueProviderResult> dict = new Dictionary<string, ValueProviderResult>(StringComparer.OrdinalIgnoreCase); 
  43:             string[] keys = AllKeys; 
  44:             foreach (string key in keys) { 
  45:                 string[] rawValue = GetValues(key); 
  46:                 string attemptedValue = this[key]; 
  47:                 ValueProviderResult vpResult = new ValueProviderResult(rawValue, attemptedValue, currentCulture); 
  48:                 dict[key] = vpResult; 
  49:             } 
  50:  
  51:             return dict; 
  52:         } 
  53:  
  54:         public virtual ValueProviderResult GetValue(string name) { 
  55:             if (String.IsNullOrEmpty(name)) { 
  56:                 throw new ArgumentException(MvcResources.Common_NullOrEmpty, "name"); 
  57:             } 
  58:  
  59:             string[] rawValue = GetValues(name); 
  60:             if (rawValue == null) { 
  61:                 return null; 
  62:             } 
  63:  
  64:             string attemptedValue = this[name]; 
  65:             return new ValueProviderResult(rawValue, attemptedValue, CultureInfo.CurrentCulture); 
  66:         } 
  67:  
  68:         private sealed class FormCollectionBinderAttribute : CustomModelBinderAttribute { 
  69:  
  70:             // since the FormCollectionModelBinder.BindModel() method is thread-safe, we only need to keep 
  71:             // a single instance of the binder around 
  72:             private static readonly FormCollectionModelBinder _binder = new FormCollectionModelBinder(); 
  73:  
  74:             public override IModelBinder GetBinder() { 
  75:                 return _binder; 
  76:             } 
  77:  
  78:             // this class is used for generating a FormCollection object 
  79:             private sealed class FormCollectionModelBinder : IModelBinder { 
  80:                 public object BindModel(ControllerContext controllerContext, ModelBindingContext bindingContext) { 
  81:                     if (controllerContext == null) { 
  82:                         throw new ArgumentNullException("controllerContext"); 
  83:                     } 
  84:  
  85:                     return new FormCollection(controllerContext.HttpContext.Request.Form); 
  86:                 } 
  87:             } 
  88:         } 
  89:  
  90:     } 
  91: }

The version of Mono 2.4.3 I have doesn’t compile the class FormCollection because the FormCollectionBinderAttribute is inside the FormCollection class.  This is the bug, and it has since been fixed.  Easy ways to get around this:

  1. Just use the binary assembly from Microsoft for ASP.NET MVC.
  2. Build your own Mono with the fix included
  3. Move the code for FormCollectionBinderAttribute class outside of the code for the FormCollection class.

One question that has been bouncing around in my mind is what, exactly, does one have to do to be considered Agile?  Let’s look at the Agile Manifesto:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on
the right, we value the items on the left more.

Sounds pretty simple.  I notice that there are twelve Agile principles:

Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.

Welcome changing requirements, even late in
development. Agile processes harness change for
the customer’s competitive advantage.

Deliver working software frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale.

Business people and developers must work
together daily throughout the project.

Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.

The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation.

Working software is the primary measure of progress.

Agile processes promote sustainable development.
The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.

Continuous attention to technical excellence
and good design enhances agility.

Simplicity–the art of maximizing the amount
of work not done–is essential.

The best architectures, requirements, and designs
emerge from self-organizing teams.

At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behaviour accordingly.

The agile principles are interesting, because in a lot of ways I can see advocates of other methodologies (BDUF) saying the believe in the same thing.

Asking amongst some peers, and there didn’t really seem to be a concise definition of Agile and what you need to do to call yourself.  I’ve seen some places that will suggest that they are Agile because they stand up at meetings (or a manager wanders around once a day), avoid documentation, and have a meeting every three or four weeks that they call a “retrospective”.  So, does anybody care to offer up their thoughts on what one needs to do to be considered Agile?  I have my own thoughts, but figured I’d save them for a later blog post.

After a bit of tinkering, I managed to provision my ADP1 setup without a SIM card.  A bit of google, and here is what I did

  1. Download the Android SDK.  In my case, I unzipped it to C:\android-sdk-windows-1.1_r1.
  2. Connection the phone via the USB cable to my computer.  When the phone asks for a device.
  3. You’ll get the new hardware dialog, when prompted for the drivers, you’ll need to specify the location.  The Android SDK has the drivers, in my case they were at C:\android-sdk-windows-1.1_r1\usb_driver\x86.
  4. Once you have the drivers installed cd to c:\android-sdk-windows-1.1_r1\tools.
  5. Type adb devices.  This should list all the Android devices that you have connected.  If you don’t see any devices listed, then you have a problem.
  6. Type adb shell.  This will direct your commands to your ADP1
  7. Now while at the adb shell, su to root, then : 
  8. cd /data/data/com.android/providers.settings/databases/
  9. sqlite3 settings.db
  10. INSERT INTO system (name, value) VALUES (‘device_provisioned’, 1);
  11. .quit
  12. Reboot the phone
  13. adb shell
  14. am start –a android.intent.action.MAIN –n com.android.settings/.Settings

Once all that is done, you should be enable to use your ADP1 as if you had a SIM card in it (we’ll except for the phoning part).

Useful link:  FAQ: Unlocking/Activating a G1 or ADP1 Without A Sim Card.

Every developer, no matter how experienced, has to dig in and fix bugs.  This is, in my experience, the typical cycle:

  1. bug is reported
  2. bug is assigned to developer
  3. developer thinks the bug is fixed
  4. developer marks bug as resolved
  5. tester checks to see bug is fixed, but it isn’t.
  6. tester reopens bug, assigns it back to developer
  7. back to step number two.  Repeat until developer (or tester) climbs to the top of a 307 foot administrative building with high-powered rifles to demonstrate USMC-worthy marksmanship.

Now, even if you aren’t into the whole Lean Software development philosophy (i.e. eliminating waste), you can probably appreciate that it can be pretty wasteful of time and patience every time that #6 happens, so please indulge me as I elaborate on some of the finer points of bug reporting.  Now, where I say “bug reporter”, I typically mean somebody who is in a QA role – their job is to find bugs and report them.  This doesn’t always have to be the case though.

If you check out most open source projects, you will often find rules/guidelines for reporting bugs.  In the case that doesn’t exist then perhaps the following might be of use: When you log a bug, be explicit, and give lots of details.  Don’t be lazy.  If it’s hard to duplicate your bug, then odds are it either won’t get looked at, or won’t be fixed properly.  And when it doesn’t get fixed properly, there will be a lot of churn.

At the very least, when reporting a bug you should provide:

  • A detailed description of the problem.  Note the emphasis on problem.  Odds are you don’t have the solution, so don’t bother.  Let the programmer figure out the solution.  For example:  Using version 3.1415 of the application on 28-July-2009, I was expected a date to be calculated a certain way based on some values.  The application didn’t crash, but the correct date was not calculated.
  • What you expect to happen.  If you have some sort of formal spec, repeat it here, and cite how to find the spec.  i.e.  According to Page 1054, in section 1095.4.3.2 the new date is to be calculated as follows :  add the value of  ((a – b)- 10) /2 (rounding down) to the date Y for a new date of Z.
  • What actually happened.  i.e.  Using these values a=300, b= 150 and Y of 1-Sep-2009 I expected that the new date Z should be 2-Oct-2009
  • A step-by-step description of HOW to duplicate the bug.  This means explaining in excruciating detail HOW the programmer can duplicate what your reporting, i.e.
    • Go to the URL http://myproblem.com/is/here
    • Click on the text box next to the label “Value A:” and enter a value of 300
    • From the drop down list by “Value B:” and click the value 150 from the drop down list
    • Use the tab key to navigate to the “Calculate new date” button.
    • Hit Enter
    • The text box by the “New Date:” label now has the date of 4-July-1943.  I expected 2-Oct-2009.
  • How the developer can get a hold of you.  This comes in handy when for some reason the developer can’t duplicate your bug or doesn’t understand what you were doing.

When the developer flags the bug as resolved and it turns out not to be fixed, don’t just re-open the bug with curt “This is still broken”.

Ah, but now aren’t I the smug developer – shifting my inability to quickly resolve a bug to the poor reporting capabilities of my tester.  I’m pretty ungrateful too.  I mean, somebody took the time to test out my application, and then enter a bug like “I tried to calculate the new date and it didn’t work.  Please fix”.  Well, fear not – there is a lot developers should be doing as well, but that is the subject of a later post.

Of course, the key part in all of this is COMMUNICATION.  Don’t be afraid, as someone reporting a bug, to actually talk to the developer.  Nothing really beats face-to-face communication (or a phone call) if things seem unclear. Odds are you won’t have an empty whisky bottle thrown at you.  Most likely the personal grooming standards of the developer will be higher than that of a middle age serf during the Black Plague.  In theory, as a tester, you’re on the same side as the developer trying to fix the bug.

(Note:  this article is pretty dated, and used IntelliJ 8.  I plan a follow-up covering IntelliJ 9)

So I have this semi-fancy Google Android Dev Phone 1.  Lately I’ve been devoting part of my spare time to learning about programming for Android (the OS of the phone).  Google (probably because they didn’t ask for my opinion and/or input) decided to use Java as the lingua franca for Android programming.  If you ask me – and I know you will – they should have used C# and Mono (I might be a bit biased here).  Luckily, years ago I had done Java programming, so I wasn’t that intimidated by the use of Java on Android.

The first big question that every developer faces is which IDE?  There are a few Java IDE’s out there, but if you ask me the only ones worth considering are Eclipse and IntelliJ.  The documentation for Android points you to using Eclipse.  Eclipse is a good IDE.  However, back in the day when I was getting paid for Java development, my employer got us all copies of IntelliJ, from JetBrains.  I liked it.  I like it enough that if I landed a contract tomorrow that involved Java, I’d buy me a copy of IntelliJ.

So, all that being said, I figured I’d give IntelliJ a spin as I travelled down the stack-trace of Android programming.  Here are my observations, in general:

  1. There is an Android plug-in for IntelliJ.  Now, you might believe that development on the Android plug is dead.  Not true.  The plug-in is undergoing active development – it just seems to be kind of slow
  2. I found the installation of the Android plug-in for IntelliJ far easier than for Eclipse.  Just download the most current release, and then unzip to your plugins folder in your IntelliJ installation.  With Eclipse, it is simple, but not when the documentation is wrong.
  3. The IntelliJ plug-in is simple, and seems to get the job done.  It’s a bit to simple at this time, if you ask me.  The ADT for Eclipse provides a far richer dev-centric experience for Android coding.  For example there are designers to help you with laying out your form, a lot more control over starting up the Android emulator, and better tooling for hooking up the debugger to either the emulator or an app running on the physical phone.
  4. Being a Resharper junkie, I found that IntelliJ was more natural for me to use.
  5. I didn’t run into to many problems when I was trying to use/convert Eclipse project with IntelliJ. This is good, because the vast majority (all?) projects I’ve seen are all Eclipse based.

So, my conclusion at the end of the day, is that I’m going to stick with Eclipse for my Android development.  There just seems to be less friction at the moment if you’re using Eclipse.  In a couple of months maybe I revisit IntelliJ and see what’s new with it and Android development.  However, at this time, I’d like to really concentrate on learning the Android SDK, and it seems simplest to me right now with Eclipse.

After a bit of tinkering, I managed to provision my ADP1 setup without a SIM card.  A bit of google, and here is what I did:

  1. Download the Android SDK.  In my case, I unzipped it to C:\android-sdk-windows-1.1_r1.
  2. Connection the phone via the USB cable to my computer.  When the phone asks for a device.
  3. You’ll get the new hardware dialog, when prompted for the drivers, you’ll need to specify the location.  The Android SDK has the drivers, in my case they were at C:\android-sdk-windows-1.1_r1\usb_driver\x86.
  4. Once you have the drivers installed cd to c:\android-sdk-windows-1.1_r1\tools.
  5. Type adb devices.  This should list all the Android devices that you have connected.  If you don’t see any devices listed, then you have a problem.
  6. Type adb shell.  This will direct your commands to your ADP1
  7. Now while at the adb shell, su to root, then : 
  8. cd /data/data/com.android/providers.settings/databases/
  9. sqlite3 settings.db
  10. INSERT INTO system (name, value) VALUES (‘device_provisioned’, 1);
  11. .quit
  12. Reboot the phone
  13. adb shell
  14. am start -a android.intent.action.MAIN -n com.android.settings/.Settings

Once all that is done, you should be enable to use your ADP1 as if you had a SIM card in it (we’ll except for the phoning part).

Useful link:  FAQ: Unlocking/Activating a G1 or ADP1 Without A Sim Card.

After an uneventful flight from YEG to PSP, I’m settled in with my family.  After spending some time with beer at the pool, I’m sitting down with my Android Dev Phone 1 that I ordered last week (ship to PSP).

First impressions:  it seems like a nice phone, and I like the fact it has a keyboard.  I don’t have a SIM card to help with provisioning the phone, so all I get is this message saying "No SIM in phone" and "Emergency call".A quick search on Google tells me that how to get around this and use WiFi.  So, that’s my task for tonight.

Tomorrow we’re heading to the farmer’s market at the College of the Desert where I hope to refresh my collection of quality shirts.

image001_2

If you using a unit testing framework such as NUnit, you’re no doubt familiar with the [Ignore] attribute.  (Note:  I haven’t used MbUnit in a while, but I’m pretty sure that all this applies there as well.) For those who aren’t, when you adorn your [Test] with this attribute, then your test runner should pay no heed to this particular [Test].  Instead of going green or red, your test turns up as yellow in your test runner. At first blush, this seems handy – rather than deleting a failing or broken test you can have it [Ignore]d, much like your typical computer geek at a high school dance before the punch get’s spiked. Now you can deal with the wayward test on your own time with the pesky failure cluttering up your CI build (you do have a CI build box set up, right?).

Please bear with me while I submit to you: This isn’t a good idea. This is a bad idea. An ugly idea. The kind of bad, ugly idea than even Belcham-esque quantities of scotch couldn’t make pretty. Why? Well, the whole point to having a unit test is to test something. If your test is failing, that means something is broken.  You should be addressing the cause of the failure and dealing with the problem now. Covering up the failure with some attribute kind of defeats the purpose of having the unit test in the first place. I mean, really, if you had open, festering lesions on your skin would you just cover them up with a band-aid and pretend nothing was wrong?  Odds are you’d go to a doctor and get that checked out.

Alternately, perhaps the test isn’t valid anymore: your application has changed/evolved and the code that you were testing isn’t around anymore. Then, get rid of the test! Delete it from your test fixtures, and don’t look back.

Granted the world we live in is not black and while.  Sometimes we’re working on things, and we only want tests to run when it is explicitly asked to run.  To handle this scenario, NUnit provides the [Explicit] attribute.  This is a kinder, more gentle kind of ignore.  This instructs NUnit to only run the test when it is told to run the test.  If you add a comment to the attribute, then it helps those going through the build log understand why the test is being run.  However it is still possible to run the test if desired.

[Explicit("This test takes a really really really long time to run so we don't want to run it in this test suite every time")]
[Test]
public void My_very_important_test()
{
    // Test valuable things here
}

I know some people are going to protest my advice. So I will offer up this one last piece.  If you are going to [Ignore] a [Test] then please take advantage of the fact that you can add a comment to the Ignore which will show up when NUnit ignores the test:

[Ignore("This test is ignored as I wish to incur the wrath of Cthulhu (or his proxy)")]
[Test]
public void My_very_important_test()
{
    // Test valuable things here.
}

Now when your CI server runs your unit tests, you will have a nice friendly message that will inform others as to why the test is not running.

Well, in a scant few hours I’ll be off to Austin, Texas, for KaizenConf.  It will be a fun packed couple of day dealing with some very interesting topics.  In all honestly, I don’t exactly know which of the topics I want to attend – the pretty much all are of interest to me.  Makes me wish I could clone myself.

My plane lands early afternoon, so if you’re kicking around Austin and want to entertain an easily amused Canuck, give me a holler (comments here, or on twitter).

Two topics merged into one.  Rod Paddock wants to talk about stored procs, and others want to learn how to explain NHibernate to other people who aren’t familiar with it (and minimize the jargon).

Rod uses a custom code-gen solution based heavily on sprocs – a data driven approach.  Sounds like it works well for him.  Oren concurs that this technique could be very effective in certain circumstances.  It will have problems with complex situations that deal with convoluted/difficult data scenarios.  He’s giving an example, but I just can’t keep up with him.  The point of Oren’s story is that a domain driven approach will would better when you’re not dealing with data but with data and behavior.

Brad Abrams brings up the point of noun centric vs. verb centric  designs.  Noun centric == data driven.  Verb centric == domain driven.

Oren talks about one of the big advantages of DDD.  We can very easily change the model, as it is all in code.  Tools like R# allow us to make changes quickly, and then NHibernate will allow us to update the database just  as quickly.  Databases are an implementation detail, part of the application, a mere persistence store.  A good domain design will generally lend itself to a  decent database design.

Apparently it is possible to suffer from an SQL injection attack with NHibernate.  According to Oren, you have to be pretty stupid for this to happen, but it can happen.  I did not know this.

Topic changes:  what do you do when you come to a client who has 1.5TB of established data and database.  How do you deal with that?  Ideally, you claim ownership of the data, and carry on.  This isn’t very realistic.

Oren starts explaining that NHibernate can allow you to partition the data in existing databases to match your model.  He suggests that it might be better to speak with the DBA to make a new model, as this approach might take a lot of effort.  Might be smarter/better to change the persistence.

Oren’s preference is to generate the HBM’s by hand.  He wants the pain to be real.  The logic is that the pain will force you to thing about your model, and helps you focus on what is important to your model.  By generating the code, you end up with, for example, a domain model that has 200 classes/tables and classes with 700 fields.

Another advantage of using NHibernate:  you get a nice way to set up a unit of work, and can specify boundaries for your application.  For example, you can, via an HttpModule with your unit of work, limit the number of queries (trips to the database).  Oren:  Going to the database is the best place to optimize, not the query itself.  Minimize the trips to the database.  You can enforce this limit right away.  It is not a problem that will hit you out of the blue in production.

NHibernate is very complex, and the learning curve very steep.  Oren argues it is not overly complex, and this complexity allows you to very advanced things.  For the simple stuff, NHibernate is very easy.  It is very irresponsible to just parachute in, introduce NHibernate, and then disappear.

Oren quotes:

  • "I tend to be nice to people that pay me"
  • "Use a set, that is all"
  • "Don’t worry about performance until you see you have a hotspot and are using a profiler"
  • "Whoever designed Linq bordered between genius and madman"

Ben Scheirman refers us to Chapter 6 in NHibernate.  Important for collections.

It seems that this session is not so much stored procs, but a Q&A session from the community about what exactly NHibernate can do.  Oren’s knowledge and experience

The CLR is very fast, asserts Oren Eini.  Rod Paddock disagrees.  With WebForms, it isn’t the CLR that is slower, it is all the stuff that goes on behind the scenes with the page lifecycle.

The question is asked:  Are datasets more efficient that NHibernate.  Apparently some people get hung up on these types of things, and claim that tools like ORM’s aren’t good because they add overhead.  Sounds like premature overhead to me.

Unrelated trivia:  This is the latest in the year it has snowed in Seattle since 1968.