Ericsson Mobile Positioning SDK

Ericsson released beta 2 of their MPS SDK, which is a software development kit for developing location based services on wireless phones. According to the site:

“It supports both the Ericsson proprietary Mobile Positioning Protocol (MPP) and the Mobile Location Protocol (MLP). MLP is the standardized interface between a Location Based Service application and the Mobile Positioning System.”

You can download the SDK here (requires login).

Fall weekend in New England

It’s fall in New England (in contrast to somewhere like California, where it’s fallsummerspringwinter all year ’round), so yesterday we went apple picking up in York County, Maine at McDougal Orchards with Kristen (who I didn’t get a picture of! doh!), Molly and Jack. You can see our pictures here. Afterwards, Karen and Kristen made the World’s Best Apple Pie and this morning Karen made Apple Nut Coffee Cake.

re: Features Talk, but Behaviors Close

From the newsletter, an article that was able to clearly and poignantly articulate a discussion I’ve struggled with many times at work. As part of our proposal process we’re constantly putting together “feature lists” (which admittedly we do combine with more in-depth lists and descriptions) that describes each and every entity included in the project.

Discussions of a software product in terms of its features were intended to serve as a bridge between constituents who otherwise had few terms in common: users and software developers. Users want a product to satisfy their goals (why else use a productivity application?), while software developers need to know what to build (otherwise they will just make it up themselves). Meanwhile, marketers and sales folks want to discuss the characteristics of a forthcoming product. So everybody has been instructed to talk in terms of “features.” Customer needs are translated into a marketing requirements document, which serves as a vague template for software construction. But what started out as a bridge—features—has broken apart. Users stand at one anchorage and product developers stand at the other, both scratching their heads at the expanse of shark-infested waters still separating them.

In short, the solution:

While part of the discussion can take place using the language of features (for instance, the IT guy is going to want to know whether the product has “128-bit encryption”), the best opportunities and longest-lasting relationships are going to come when the language of goals and behaviors is introduced, because then you’re in the business of solving personal goals and organizational objectives, rather than feature checklists.

Please send this to every software sales, marketing and project manager that you know. No more “features”!

Extending web.config in ASP.NET

Last March I wrote about how handy it is that ASP.NET enables you to add your own custom settings to the web.config file using syntax like this:

<add key=”connString” value=”user id=sa;password=mypassword;” />

This is nice, but can quickly get unwieldy if you have alot application settings to maintain. Back in March I failed to mentioned (because I didn’t know about it) that you can extend your web.config even further by creating your own custom configuration sections. You can read more about the ConfigurationSettingsSchema on msdn, but here’s a quick example. First you define the custom application settings:

   <sectionGroup name=”myapplication”>
      <section name=”types” type=”System.Configuration.NameValueSectionHandler”/>
      <section name=”security” type=”System.Configuration.NameValueSectionHandler”/>

and then you add the actual settings:

      <add key=”section” value=”com.ignitionlabs.Section” />
      <add key=”template” value=”com.ignitionlabs.Template” />
      <add key=”/controlpanel/” value=”Systems Administrators,Project Managers” />
      <add key=”/members/” value=”members” />   

Finally, you can use the exact same XPATH syntax that you use when retrieving other application settings. In the above example, there are multiple ‘type’ elements, so I’d first get a NameValueCollection object:

NameValueCollection config = (NameValueCollection)System.Configuration.ConfigurationSettings.GetConfig(“myapplication/types”);

and then retrieve the value of the “section” key using the name:

string section = config["section"];


ASP.NET HttpModule Security Example

I wrote a short bit about HttpHandlers and HttpModules a couple weeks ago and recently had decided to use an HttpModule to function as a security gateway for specific parts of the application I’m developing.

If you have any experience with ASP.NET, you’ll wonder why I didn’t just use the declarative Forms security. The one shortcoming that I could see of Forms security is that it requires that you only have one form for your application. For example, in your web.config, you’d have something like this:

<authentication mode="Forms">
  <forms name=".ASPXAUTH" loginUrl="/login.aspx" />
  <allow users="*"/>

and then users that access any directory you protected using the <location path=”administrators”> syntax would be redirected to the /login.aspx script. If you have two different types of users though, each requiring a different login page, you’re stuck. The web.config XML schema only allows you to have one <forms> element per application. I could have split up the applications in IIS, but then I’d have to replicate application settings and libraries to each application’s bin directory. So, long story short, I wrote a short bit of code that authenticates and authorizes users in the Application BeginRequest event. Pseudo code looks like this:

public class SecurityHttpModule : IHttpModule {
// implemented per the interface
public String ModuleName {
   get { return "SecurityHttpModule"; }
// register for the HttpApplication BeginRequest event
public void Init(HttpApplication application) {
   application.BeginRequest += (new EventHandler(this.Application_BeginRequest));
// handle the begin request event
private void Application_BeginRequest(Object source, EventArgs e) {
   HttpApplication application = (HttpApplication)source;
   HttpContext context = application.Context;
   // get the user, populate the Thread.CurrentUser...
   HttpCookie cookie = context.Request.Cookies.Get(".ASPXAUTH");
   if (peanutButterCookie != null) {
      FormsAuthenticationTicket fat = FormsAuthentication.Decrypt(cookie.Value);
      // get the user & the roles that this user is in using your own logic
      string[] roles = User.Roles;
      GenericIdentity identity = new GenericIdentity(fat.Name);
      GenericPrincipal principal = new GenericPrincipal(identity, roles);
      context.User = principal;
   // find out if the section we're viewing is meant to be secure
   // pessimistic: default to forcing a login
   Boolean forceLogin = true;
   // if the section has security and we're not on the login form for this section
   if (s.isSecure() && thisSection.LoginForm != scriptName) {
      // groups allowed in this section
      ArrayList groups = s.GroupsAllowed();
      // loop over all allowed groups, see if this user is in one of those groups
      for (int x=0; x
I left out some of the implementation as well as the import statements, so this obviously won't compile if you drop it into your favorite IDE. Couple things to note in this example:

a) the use of GenericPrincipal and GenericIdentity. GenericIdentity is a concrete implementation of the IIdentity interface, that allows you to specify information about the current user. GenericPrincipal is a concrete implementation of the IPrincipal interface, it contains a reference to the GenericIdentity as well as an array of roles that the current user is in, as well as a method to determine is a user is in a specific role. You can choose to use the concrete implementations (like I did in the example above) or you can choose to create your own implementations of those interfaces, adding your own custom properties and methods to your users identities & roles.

b) the HttpContext, which maintains a reference to the current User, which contains the IsInRole() method. Every ASP.NET page can access information about the currently logged in user and what roles this user has.

c) the use of the utility class FormsAuthenticationTicket, which provides the means of creating and reading the values of a forms authentication cookie.

Just for kicks, how does this compare to ColdFusion? In ColdFusion MX (previous versions of CF used SiteMinder, which gives me the shivers), the <cflogin> tag provides similar functionality to the GenericPrincipal and GenericIdentity classes. which you can then use with the IsUserInRole() and getAuthUser() functions. Out of the box it's probably easier to use, but it (in my humble opinion) sacrifices ease of use for extensability. You can't add additional properties or methods to the logged in user (for instance a last name or a method that returned how long the user has been logged in). Correct me if I'm wrong!

Eclipse Keyboard Shortcuts

I hate my mouse, I love ALT-TAB in Windows, Homesite gives you CTRL-TAB to effectively switch between open files but I couldn’t figure out a way to the do the same thing in Eclipse. Turns out Eclipse functions more like IE in that each file you view becomes part of your viewing ‘history’. To switch between files, you can use ALT-LEFT ARROW or ALT-RIGHT ARROW just like you can in Internet Explorer to go BACK and FORWARD. Nifty.

Eclipse Local History

Say you just modified a file in Eclipse and you want to roll back to the version you had about 5 minutes ago. With a normal IDE, if you’ve had the file checked out from SourceSafe or CVS without checking it back in you won’t be able to see your changes. Eclipse however, maintains it’s own little history of your changes, which you can see in the screenshot to the left (click it to see the large version). To get this ‘local history’, right click on the file in question, choose “Compare With” and choose “Local History”. Very very cool.

You can read more about Local History here if you’re so inclined.

Migrating from ColdFusion to ASP.NET

Microsoft has put together an extensive article for developers migrating from CFMX to ASP.NET, including a pretty fair feature comparison chart. Probably the most obvious thing that the feature comparison table lacks is the mention of the close integration of Java with CFMX, in fact it says this:

It can also access Java class libraries with some extra work.

which is true and false… it requires extra work in the same way that it requires extra work to compile a C# file to an assembly, place the assembly in the /bin/ folder of the application and then import that assemblies namespace into an ASP.NET page.

Nonetheless, check it out if you have worked with CFMX before and are just getting started with ASP.NET.