Mickaël’s Weblog

I get a PRS-505 for Xmas. First of all, this reader is very good and I’m very pleased with it. In France, the “official” book online provider is www.fnac.com. Their online catalog is really not of interest: only 3000 references, and all in very strange/weird categories like cooking for example. I’m not a fan of cook books andfor example on science fiction they have only 3 references…yes THREE.

So I decided to buy some books somewhere else: NumiLog. I found a science fiction serie of books. I decided to buy 2 of them. You’ve notice how easy it is to buy something…it occured like a charme. I was just surprise not to see a download starting at the end of the purchase process. So I surf a little bit on the site and found that I have to explicitely doanload the books that I have bought. This is where it starts to spin out.

I was asked for 1 or 2 PID. The PID is the ID of the reader, and the PRS-505 has …. no PID!!!! In fact the MobyPocket format is based on a kind of DRM. To read them on your reader, you have to remove the DRM.

This post is for people that have legally bought books with mobypocket format, and would like to read them on their PRS-505. You have to acquire legaly the book, this post is not for these guys that does not support book industry.

To remove the DRM, I use a (2 in fact) python script that will remove a fake DRM (you are not able to download without providing a DRM).

So first, you need to get a PID; I did not tried with a totally fake one, I simply installed the moby pocket reader and grab its PID that you can found in its About window. Then you need to install python language.

Create a temporary folder, let’s say c:\mobypocket. Download 4DeDRMfiles.zip with your favorit torrent client. Extract content in c:\mobypocket. Create an ‘input’ folder, and an ‘ouput’: c:\mobypocket\input and c:\mobypocket\output. The python scripts have to be renamed for simplicity. rename “Python Script for MobiDeDRM.py 0.01.txt”, rename it as MobiDeDRM-0.01.py, and ”Python Script for MobiDeDRM.py 0.02.txt” as MobiDeDRM-0.02.py. You may not need the 2 scripts, but in my case, one script was ok to remove DRM on a file but not the otnher script, and vice-versa for another file.

Now run, the script to remove the scripte like this:

 (click on image to enlarge)

I’ve hidden my PID, you should use your. If you get errors, try the other script: MobiDeDRM-0.02.py.

Now, in the output folder, you get your acquired books without DRM and you will enjoy them on your reader.

I should add “versus backend features, especially for an enterprise software”.

Have a look at Ayende work around NHProf. In a recent post he describe a change he will have to implement. I’ve no doubt he already made this significant change quite rapidely, but such change is usually heavy. You can check the number of line of code in the client vs backend there. So, technical requirement/constraints may force you to take a radical approach for the UI which induce significant extra work…especially as (from a performance perspercitve):

UI operations are expensive, while backend operations tends to be cheap.

From a requirement perpective also, UI can be very expensive to develop. Usually, customers (internal or not) are suddenly very creative when the “see” the UI of a feature and add a lot of new requirements…or changes. That’s why products like Balsamiq Mockups are really useful, to avoid useless iterations.

In the context of an enterprise software the ROI of UI becomes terribly low. The first reason is that usually, there is a need for multiple clients that are totally different: business intelligence, RIA, outlook integration, RSS/ATOPM integration, fat client, web client. This makes the development on a single client a very small piece of the entire picture, which reduce the ROI. 

The second reason, is that UI technology and trends are evolving a lot (RIA, Web 2.0…etc). At the opposite, the business logic encompassed into your enterprise software is tighted to the “business” which evolve at a slower rate. In this context, adding a new “business feature” has touthands more value/ROI than a UI feature.

In my opinion:

• UI technology should support rapide development to be able to follow trends and technology evolutions without exploding investments,
• backend technology should be selected with a long term vision,
• do not put any business logic in UI, simply allow projections of backend business logic in the front end.