The Shortest Distance between Two Points is MATH

They need me to put together a simple little system at work that finds known locations within a given radius of a given location. This sounded familiar, so I dug up an old SQL query of mine from a LONG time ago...

SELECT
  Name,
  Address,
  City,
  State,
  Latitude,
  Longitude,
  (
    ACOS(
      COS(@center_latitude * (PI()/180)) *
      COS(@center_longitude * (PI()/180)) *
      COS(Latitude * (PI()/180)) *
      COS(Longitude * (PI()/180)) +
      COS(@center_latitude * (PI()/180)) *
      SIN(@center_longitude * (PI()/180)) *
      COS(Latitude * (PI()/180)) *
      SIN(Longitude * (PI()/180)) +
      SIN(@center_latitude * (PI()/180)) *
      SIN(Latitude * (PI()/180))
    ) *
    (
      (@equatorial_radius * @polar_radius) /
      (
        SQRT(
          (@equatorial_radius * @equatorial_radius) -
          (
            (
              (@equatorial_radius * @equatorial_radius) -
              (@polar_radius * @polar_radius)
            ) *
            (
              COS(@center_latitude) *
              COS(@center_latitude)
            )
          )
        )
      )
    )
  ) AS Miles
FROM
  Places
WHERE
  Miles <= @search_radius

This query accepts a center lat/long (the customer location) and a radius (the distance from the location to search) and finds any known locations within that distance from the center and notes that distance in miles (so we can sort and find the closest).

It also accepts parameters for the radius of the Earth. The radius of the Earth can be expressed in many various ways. For simplification, we'll use these:

@equatorial_radius = 3963.190 miles
@polar_radius = 3949.902 miles

(Note that this equatorial radius may not account for the crust displacement during the 2004 Indian Ocean earthquake.)

This distance calculation not only plots a circle around the area, but in the projection of that circle onto the plane of the Earth it accounts for the curvature of the Earth’s surface and the bulging at the equator, derived from the WGS-84 ellipsoid model.

We never did get around to using this at a previous job. (They plotted searches as rectangles around the center... ew. Just goes to show how a fundamentally broken business idea can churn out sub-par results from an otherwise intelligent and talented team of developers.) But maybe I'll finally get a chance to use it here.

Prototypes, not your everyday inheritance

So a concern came up today around Javascript. Specifically it was that there are no private members in the language. I quickly spoke up saying that how closures work and the use of the var keyword keep your variables private but was met immediately with those are not instance variables and you can't have private instance members. It turns out there was some confusion as to what the prototype attribute does on functions and it's role with inheritance.

This was the example to prove that there are no private instance members in Javascript:

function Person() {
  //public member
  this.Name = "Copenhaver";

  //convention based "private"
  this._ccn = "5555555555555";

  /* thought this was unusable, but it's actually scoped inside
   * this invocation of the function and usable by other members of
   * the object currently being built.
  var ssn = "xxxxxxxxx";
}

/* this is actually creating a completely separate object that
 * will act as the parent of all objects built using Person()
Person.prototype = {
  getSSN: function(){
    //this doesn't do what you want
    //actually would try to grab this out of global scope
    return ssn;
  },

  getCCN: function(){
    //anyone could access this variable
    return this._ccn;
  }
};

Now the developer was used to using the prototype variable basically for class style definition and inheritance with Javascript. The confusion comes in with that as well. That prototype attribute on the function is going to point to a single object and that object gets hooked in as the parent of any object created with the function. Yeah think about that, so that would be a single object as the parent to many children. Not a class, an object. That is prototypical inheritance. If you wanted them disjointed then you would clone the parent first.

I personally see the prototype attribute as a bit of a wart on the Javascript language that just confuses the people who come in trying to use it the same as they did classes and inheritance in other languages. Anyway I'm starting to see all this constructor inheritance business in Javascript to be a bit off. I'm thinking that you should really think about these functions as initializers and inheritance as something to create off of:

var linkedChild1 = Object.create(sharedParent);
var linkedChild2 = Object.create(sharedParent);

//now you become a Panda... but it could effect everyone else making them sad
linkedChild1 = Panda(linkedChild1);

var unlinked1 = Object.create(parent.clone());
var unlinked2 = Object.create(parent.clone());

//now you become a Grizzly leaving everyone else behind so you can eat them
var raaar = Grizzly(unlinked1);

I haven't used this idea yet and it's partially based on a Crockford's Object.create() idea which is getting incorporated into Javascript. Figured, throw the idea out there and see what comes of it.

Links:
http://javascript.crockford.com/prototypal.html
http://javascript.crockford.com/private.html

HtmlHelper Extensions

I'll keep this fairly short. Do yourself a favor and organize your HtmlHelper extensions. That thing gets polluted quick and you'll find yourself with pages of items in intellisense and large method signatures for your configuration options.

I suggest trying an idea of having HtmlHelper extensions that create and return custom html builders for related or even individual UI widgets. The builders can have a fluent interface for more complicated configuration of the output and you get the added benefit of keeping the HtmlHelper somewhat clean.

Here is an example of what I'm suggesting.

Clean simple HtmlHelper extensions:

public static class HtmlHelperExtensions
{
  public static PhoneHtmlBuilder<tmodel> Phone(this HtmlHelper<tmodel> helper)
  {
    return new PhoneHtmlBuilder<tmodel>(helper);
  }

  //... a bunch of other things
}

With Html Builders doing the real work, possibly grouping related widgets (as I'm calling them):

public class PhoneHtmlBuilder<tmodel>
{
  private HtmlHelper<tmodel> _helper;
  private Expression<Func<TModel, string>> _phoneNumber;
  private Expression<Func<TModel, string>> _extension;

  public PhoneHtmlBuilder(HtmlHelper<tmodel> helper)
  {
    _helper = helper;
  }

  public PhoneHtmlBuilder<tmodel> For(Expression<Func<TModel, string>> property)
  {
    _phoneNumber = property;
    return this;
  }

  public PhoneHtmlBuilder<tmodel> WithExtension(Expression<Func<TModel, string>> property)
  {
    _extension = property;
    return this;
  }

  public MvcHtmlString Render()
  {
    //probably register javascript to get rendered or generate some

    //i'm not even sure if this compiles, just getting a basic format of the idea down
    return MvcHtmlString.Create(
      _helper.LabelFor(_property) +
      _helper.TextBoxFor(_property) +
      _withExtension ? _helper.TextBoxFor(_extension) : "" +
      _helper.ValidationMessageFor(_property));
  }

  public override string ToString()
  {
    return Render().ToString();
  }
}

Providing organization and possibly fluent or more options for the more complex widgets:

  
Cell Phone
@Html.Phone().For(m => m.Cell)

  
Business Line
@Html.Phone().For(m => m.BusinessNumber)
               .WithExtension(m => m.BusinessExtension)
               .Render()

Note that the call to Render() for the business number was optional, just trying to show options.

I hope that's helpful. I would love to hear any feedback or ideas.