Thursday, November 12, 2009

Everyware: Adam Greenfield



 A few quotes and notes that caught my attention while reading "Everyware: The dawning age of ubiquitous computing".  I was inspired to finally get this after hearing Adam speak at dConstruct earlier this year.

Present IT development practices as applied to everyware will result in unacceptably bad user experience.

"If computers are everywhere they had better stay out of the way."

Build it as safe as you can, and build in all the safeguards to personal values that you can imagine.

"in dreams begin responsibilities."

It will not be sufficient simply to say, "First, do no harm."

We're not very good at doing "smart" yet, and we may never be.

"some problems routinely put forward [in ubicomp] are actually AI-hard."

Ubiquitous systems must default to a mode that ensures users' physical, psychic, and financial safety.

ubiquitous systems must not introduce undue complications into ordinary operations.

Tuesday, November 03, 2009

WMRM DisableOnClockRollback

I've been working on a project which involves using Windows Media Rights Manager (WMRM) Digital Rights Management (DRM).  As part of that project I have been applying rights to specific content (movies in this case)to meet the rules specified by the client.

Unfortunately I was receiving an error and searching on the error message returned exactly no hits.

{"Error HRESULT E_FAIL has been returned from a call to a COM component."}

at WMRMOBJSLib.WMRMRightsClass.set_DisableOnClockRollback(Int32 pVal)


In case anyone else runs in to this in the future, here's what the bug actually was.


I was setting a DisableOnClockRollback value of true, but was getting the error when I did so.  A short MSDN search later and and I found http://msdn.microsoft.com/en-us/library/bb649390(VS.85).asp. In it is the line:

This property works only if you have set an expiration date first.


That'll be the problem then.

DevDays CountDown App: My Analysis

I promise, this'll be the last time* I post about my DevDays CountDown App.

Now it's all over, it seems a suitable time to do some analysis:
  • Why did I write it?
  • Why did it get picked?
  • What helped me develop the application?
  • What did I learn from the process?
  • What would I do differently next time?

Why did I write it?
 A few reasons:
  • I thought it'd be cool to write an app that got used in quite a cool, high profile event.
  • I had an idea that I thought was quite good.
  • I thought it'd be a good opportunity to build some experience with WPF and particularly with WPF animation.
  • To prove to myself that I was able to produce a good piece of software that meets a clients requirements.

Why did it get picked?
Officially:
"... because of the twitterfeed and because the graphics are actually appropriate"
I think there are several reasons:
  • Because I actually produced something that met the requirements. - I was surprised by the number of entries that didn't. (Users won't [usually] use[/buy] a product that doesn't meet their needs.)
  • Because I actually delivered something. - There were a lot of comments from people who said they were working on something but never posted anything. (There's no reward for not showing up.)
  • Because the graphics were appropriate. - While I also had some novel. alternative, ideas I knew these wouldn't tie in with the StackOverflow or DevDays brands. (A bit of marketing knowledge helps in software development.)
  • Because I did more than was asked. - The twitter element wasn't part of the original requirements. (Having something unique is always a good selling point.)


What helped me develop this application?
  • I made sure I understood what was wanted. - I read the requirements thoroughly. I asked questions and madde sure I understood the answers. I read other people's questions and answers.
  • I understood the domain. - I go to quite a few conferences and am keen on understanding their organisation and how they are put together. (This partly ties in with my experiences of organising DevEvening.) Knowing the application domain is essential to good software development!
  • I've seen lots of different ways twitter has been used at conferences and other comparable events. - This guided how I incorporated the twitter element.
  • I have a desire to only do things well, or not at all. - Loads of people can do average. Fewer people will put in more effort to make something really refined and polished. - Good enough isn't good enough!
  • I focused on my strengths, not my design skills. - By basing the design on an existing layout, colour scheme and images.



What did I learn from the process?
  • Make the first user experience great. Optimise for it. (User input handling wasn't brilliant in the first version.)
  • Visually stunning (slick?!) and different is good for creating a good first impression. Animation is a good way of adding something new, different and visually appealing to traditional desktop apps.
  • Make user input handling really solid, smart and tolerant.
  • People love seeing their own contribution/thoughts (tweets) on screen.
  • TweetSharp is cool (despite a few temporary problems) and fluent interfaces are really nice to use. 
  • There are a lot of ways user input can get into an application. Consider all of them and 3rd party libraries and APIs as external input and treat them with caution.

What would I do differently in the future?
  • Better caching of tweets retrieved from the twitter API. So can download many at once and then stagger their display.
  • Better error logging. - Currently swallowing quite a few exceptions with no logging. - It didn't really matter for this case but could help with debugging.
  • Better messages to display if no new tweets to show.
  • Add unique images for fake tweets.
  • Add processing rules for tweet inclusion. Possibilities to consider would include: ignoring retweets; profanity filtering; spam detection and ignoring.
  • Ability to play music?
  • Better validation of all input.

Right. Must be time to go back to some of my other projects.


*This year! - who knows about the future.

Monday, November 02, 2009

Getting IIS6 working in 32bit mode on a 64bit machine

I had a server up and running hosting various sites.  One of those sites needed to be able to apply DRM wrapping to movies (WMV) files.

Unfortunately the DRM libraries are only available in 32bit versions and it's not possible to call 32bit DLLs from 64 bit processes.  The way round this is to have IIS run in 32 bit mode.

The same applies if  needing to reference any other 32 bit DLLs ffrom 64 bit ASP.NET/IIS.

Based on what I read on the internets, making this change should be quite straight forward.  Despite all the instructions on the web saying ti was just one script to run to make this change I found that more needed to be done.  Incase anyone else has the same problem, here's what I did to get it working.

Uninstall the 64bit version of ASP.NET 2.0.
c:\WINDOWS\Microsoft.NET\Framework64\v2.0.50727\aspnet_regiis.exe -u

Configure IIS to run in WOW64 mode.
cscript.exe C:\inetpub\adminscripts\adsutil.vbs SET W3SVC/AppPools/Enable32bitAppOnWin64 1

Install 32bit version of ASP.NET 2.0
c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\aspnet_regiis.exe -i

Enable 32bit version of ASP.NET 2.0 in IIS WebService Extensions

Recreate the existing websites in IIS using same setings as before.  This will use the 32bit versions of ISAPI extension executables, etc.  I tried changing these manually but that didn't seem to be enough.  I assume that there's more to change than I'm aware of. Recreating the web site takes care of all that for me.

Done.


IIS is all or nothing when it comes to using the 32 or 64 bit version.  Yes this meant that all websites on that server needed to be changed to run at 32 bit.  We therefore lose the benefits of the 64bit OS.  If the site becomes as big as the client is hoping we'll move the site doing the DRM wrapping to a different box and put everything back to 64bit so we can make the most of the 12GB of memory installed.