Bugle is a project that consists of Google queries that help identify security bugs in open source software. This is a very interesting concept and while it may help hackers find vulnerabilities in software easier than scouring the code, I think it is more useful for open source project teams.

By their very nature, open source projects are generally collaborative and therefore it is easy for unsecure code to creep in. The Bugle technique effectively helps detect high-level vulnerabilities in contributed code that has not been carefully scrutinized by the project security administrator.

This brings up another topic, which is better suited for its own post, but I will briefly mention here. While open source is supposed to result in more secure code because many more eyeballs are reviewing the code, the reality is that few people that use open source software actually look at the code. Most people are in it for the “free” aspect, not necessarily for the code. If the project developers miss a vulnerability in the code, it may not be detected for a long time. How is this any different from commercial, closed source projects? 

It’s easy to persist settings for an instance of DotNetNuke modules using ModuleController.GetModuleSettings(moduleId). But sometimes you want module settings to apply to all instances of a module within a given portal. I needed to do this for a module and used the following code:

PortalSettings portalSettings = (PortalSettings) HttpContext.Current.Items["PortalSettings"];
ModuleController moduleController = new ModuleController();
ModuleInfo moduleInfo = moduleController.GetModuleByDefinition(portalSettings.PortalId,”Site Settings”);
int globalModuleId = moduleInfo.ModuleID;
Hashtable globalSettings = moduleController.GetModuleSettings(globalModuleId);

I suspect there may be better ways to achieve this objective, but this seems to get the job done. If anyone knows a better way please post in comments.

 

I have had several emails from people inquiring whether I would be releasing a My Modules version for DNN4. The answer is “Yes.” I’m trying to decide if I should base it on VS.Net WAP or WSP models. If you are not familiar with these models you can learn more about them on Scott Guthrie’s blog

I am trying hard to be objective, but I have a strong bias for the WAP model. Granted, it makes total sense for the DNN project to follow WSP since it allows DNN to be usable with the Express series of Microsoft developer products. However this is not an important consideration for most professional developers. Also, there is a significant cost to change all my existing projects to support the WSP model and it will take quite a bit of time to migrate and test hundreds of VS.Net 2003 projects and migrate them to the WSP model. I am sure there is some ROI there, but it’s just not something that makes you sit up and take notice.

I have allocated some time this weekend to study the DNN Starter Kit in greater detail and make a decision on which model to follow for “My Modules.” If you have any preference on the matter, please leave a comment or contact me using the link at right.

  

I flew out of Dulles Airport a couple of days ago and found the Flight Departures monitor displaying some interesting information. Although you can’t tell from the picture, the dialog showing is the “System is running low on virtual memory” that we have all seen at some point or the other.

Airport monitor

The dialog stayed on the screen for the entire 45 mins. I was waiting for my flight to board. Although this is only an information screen, it still makes you wonder how much thought goes into fault tolerance and recovery on the systems that power such displays?

 

The schedule information displays for public transportation in the U.S. tend to range somewhere between ho-hum to crappy. Either you have the paper schedule posted under plexi-glass or you have giant, ugly LED or OLED displays. On my recent trip to Melbourne I was totally impressed with the displays at the tram stops.

Melbourne tram schedule display

This display rocks! It is clear, concise and most importantly, real-time (note wireless antenna at top). And the unit itself is compact and not an eye-sore.

There was one important UX choice that puzzled me at first. The display is sorted by Route # versus arrival time or destination. I pondered this for a bit and the decision does make sense. If the display were sorted in descending order by arrival time, you would have scan down the list to find when your tram or bus would be arriving. This way, you can quickly skip the Route #’s you are not interested in and quickly find the time your tram will arrive.

This made me think about the sorting choices in Windows Explorer. When you are in Details view and sort columns, no matter which column you choose, there is an implicit primary sort by type (i.e. folder or file) before the selected sort is performed. I faithfully reproduced this functionality in my Posted by nik at 8:00 am