Apolon's Software Torq

Over the last year or so, I've been heavily into listening and viewing audio and video content from the Internet. Mostly it's technology oriented but there's also a mix of other subject areas. The great thing about audio content is that you can do something else but still have your hands, eyes and feet free i.e. you can be doing other activities and have the audio on in the background. This is nothing new, but the difference for me now is access to a large range of niche content for people interested in technology. Take for example IT Conversations, Dot Net Rocks, The Server Side, The Server Side.Net, The .NET Show, MSDN TV, MSDN Web casts, Audible.com, Ken Radio and Web Talk Guys.

Just recently, my tech media content modus operandi has changed a bit. In a period where there wasn't much new content from my usual free media sources, I decided to start converting interesting web articles and the longer blog entries into audio using Text Aloud with some decent voices. It works surprisingly well when the article/blog entries are written in a conversational manner, though its a crappy approach whenever there's lots of code or diagrams being referred to in the article or post. Another aspect that surprised me was how even reasonably short articles turn into long audio content. Its really quite obvious, but the ratio of the time taken to listen compared to the time taken to read was much higher than expected.

There's a lot of scope for apps that leverage TTS (text to speech) to produce audio content. An esoteric example, would be a TTS application that navigates through a wiki generating an audio presentation of the information in the wiki. The app could use the link structure amongst the wiki pages, link popularity and date of modification to identify the structure of the linear audio output. Going through something like Martin Fowler's bliki would produce some great audio content i.e. "real techno".

Posted by Apolon at 1:40 PM | Permalink | Comments | links to this post

Just recently I've discovered the wealth of content at www.theserverside.com and it seems that innovation is flourishing with respect to middleware in Java land. The AOP related videos and discussions are particularly relevant to the software work I've been doing over the last couple of years. The ability to easily separate out particular implementations of persistence, caching, security, remoting etc. from the domain model source code is the kicker for me.

In particular, the following statement from the JBoss people rang true for me:

"Middleware, by nature, is cross-cutting"

Given the fact that the statement was delivered by a guy in a Joker outfit, it's understandable that you may doubt the validity of the statement. I first saw the beginning of the Marc Fleury Joker video via a Don Box post and thought: hmm... interesting approach to selling middleware services. It helps to know some context and the terminology of the people speaking though. For example POJO (plain old java object), IOC (Inversion Of Control) and the background of the people classed as jokers in the Middleware Company's Enterprise Java Whos Who list.

The AOP approach being taken in some Java land projects gives hope to being able to write business objects that aren't joined at the hip to particular container implementations or versions of container implementations. It's going to be interested to see where this AOP stuff goes and how much of it crosses the fence to .NET land.

My favourite videos at theserverside.com so far are:

• Ted Neward - Independent consultant, Editor-in-Chief of TheServerSide.NET and general troublemaker
• Rod Johnson - Founder, The Spring Framework, Author, 'J2EE without EJB'
• Marc Fleury - CEO, JBoss
• Scott Ambler - Senior Consultant, Ronin International
• Gavin King - Founder, The Hibernate Project
• Bill Burke - Chief Architect JBoss, JBoss Group LLC

Posted by Apolon at 4:01 PM | Permalink | Comments | links to this post

I've been modifying the GUI of a Windows Forms application to integrate in with an authorization subsystem. The approach taken is to hook into the databinding process and make the Winforms control ReadOnly if the data property being bound can't be written to by the current user. The authorization subsystem determines whether the current user is allowed to write to the data property.

This works quite well with any control derived from TextBoxBase, but for general controls there is no equivalent to the ReadOnly functionality. The best I could find was the Enabled property, but it's limiting in that the look of the control is "faded" when Enabled = false. The "faded" look is probably to highlight the fact that the control is not enabled for use. In addition, the user can't click on or select any of the text in the control for copy/paste actions. Note that the UpDownBase control has a ReadOnly property but that only affects whether the up/down buttons perform any action, not whether the control as a whole is read only. The ability to set a control as ReadOnly or not really needs to be a common item of functionality for all Windows Forms controls.

I'll probably investigate hooking in an app specific PropertyDescriptor implementation which hides the fact that a property setter exists from the data binding mechanism when the user isn't authorized to perform the set. That would at least allow the individual Windows forms to handle unsettable data properties in their own way. Just another "some time in the future" TODO to add to the long list.

Posted by Apolon at 9:46 AM | Permalink | Comments | links to this post

Following on from my previous post, I was searching for how other developers handled the definition of what roles are allowed to perform which tasks in a declarative programming model. The approach that was being taken is to be able to Allow or Deny authorization to perform a task. This is more complicated than just listing all the roles that were allowed to perform a task, so a bit of research into alternatives was started. The search results brought up this Role Based Access Control page with references to US Patent Office search results. It's kind of both scary and ridiculous how many patents exist regarding role based security in software. Do these patents overlap in applicability? Or are they so specialized that overlapping is less of an issue?

It just seems like software patents in particular are like a weapons stockpile in the cold war. If you're a small player, then you can be swatted like a fly if need be. If you're one of the big players, just keep your hand off the big red lawyer button or all hell will break loose. Patent missiles would fly thick and fast if one of the big boys like IBM, Microsoft, HP or Sun decided to go at it. So they're probably forced to accept the "Software Patent Deterrence" strategy as a defensive approach and only go on the attack in rare circumstances (considering the bad press that would arise if they did).

Posted by Apolon at 11:12 AM | Permalink | Comments | links to this post

I'm currently working on the Authorization infrastructure for a software package in the finance industry. The approach taken is to use .NET attributes to declaratively state which user roles are authorized to perform the following actions:

• read
• write
• create
• delete
• execute

These authorization attributes are placed on a .NET type, property or method. The user roles that are allowed/denied authorization are specified by role types listed in the attribute constructors. At runtime the infrastructure determines whether the currently logged in user can perform any of the specified actions and throws an exception if they can't and an attempt is made. An authentication subsystem defines the user and the roles they play in the system. It's the responsibility of the presentation layer to use this metadata to alter the user interface based on what the user is authorized to perform. Alterations include greyed out buttons/menus, panels/controls that aren't displayed etc.

While working on this functionality, I realized that the available authorization concepts that fell out of the requirements/design are most of the elements of the CRUD pattern:

• Create
• Read
• Update
• Delete

The exception was the addition of an Execute authorization concept. For a second, I considered renaming the AllowWrite and DenyWrite attributes to be called AllowUpdate and DenyUpdate. But then considering how professional the "CRUDE pattern" sounded, I decided against it .

Posted by Apolon at 4:23 PM | Permalink | Comments | links to this post

Posted by Apolon at 9:30 PM | Permalink | Comments | links to this post