As influences go, that’s it. I received neither threats to pets I don’t have or contributions to a bank account I do have. Also a complete absence of nudges means that this post took longer than planned and that all opinions are mine. Too make them less ignorant I decided at start to give Toshl a proper test and use it for couple of months before passing judgment.

Toshl, as mentioned, is a tool for keeping track of expenses. You are obviously sensible enough to know why this is wise, if you are still reading this, so I won’t bother explaining. It comes as a free application for Android devices and Maemo based N900. I heard rumors of an iPhone version, but Symbian or BlackBerry owners are out of luck (for now). Using web based companion and synchronization is free too, but you have to pay for Pro account if you want to add expenses through website or need a more flexible export of your data.

I tested Nokia N900 version of Toshl and liked it. I don’t want to go into details since they quickly become boring and there is no better test than your own (remember, it’s free). I was impressed how well it handles decimal separator for me, since I sin by using both comma and point.

Entering expenses is easy and quick, especially if you have entered similar recently, since you can reuse tags just by clicking on suggested. You also see already entered expenses sorted by time or tags. There is still room for improvement (like adapting tags suggestions based on first entered), but not much to fault.

I believe Toshl’s goal is to be as simple and fun tracker of everyday expenses as possible. You can do basic add and removal of expenses, export inserted data, categorize each entry with tags and see few different reports. That’s it. There is no integration with banks, currency conversions,  or even a notion of income. Reports are basic and I am not a fan of those included.

I usually used more than one tag on each expense and had difficulty wrapping my head around graphs where same expense could be shown multiple times. I failed at judging how much impact do some expenses have overall without at least some tweaking of graphs. I am certain that Tufte would call it chartjunk, but their implementation certainly is fun to play with.

And that’s where Toshl’s main strength is. A fun way of doing something that most people find incredibly tedious. You might overgrow it one day and switch, but it will help you develop a necessary habit of recording your expenses.

Being simple and fun doesn’t mean powerless. Tags free you to your own categorization and multiple export options give you an opportunity to massage that data further in tools of your choice. It might not be as trivial as clicking on a graph is, but doing it in Excel is not much harder.

I will not continue to use it because I am that sort of person who gets off on double-entry bookkeeping. I’ve been using GnuCash for years and there is no easy way to sync data with it (probably shouldn’t be either) and few reasons to input every expense twice. I do recommend anyone who isn’t tracking yet or is not satisfied with his current approach to give Toshl a try.

And if you are happy with free version, then buy a Pro account. It costs little, gives you features as polished as rest of service and it help secure your apps future.

Related articles by Zemanta

• Toshl expense tracking app is web connected and I love it for that! (intomobile.com)
• Personal finance software – Free download the ultimate Gnucash (techblissonline.com)

They are right, but it doesn’t matter much. Relying on Facebook for authentication certainly makes Facebook sort of a gatekeeper. This does not matter because it can and should be a transitional phase in an evolving relationship.

My view is based on assumption that company wants to build a long lasting relationship with a customer. This may not be true, but then there really is no point in having a sign-up at all. Avoid friction of one, make a trade and move on.

I think most user lifecycle strategies look like trying to get laid by the end of evening while hoping to start a long-term relationship. It might work, but how likely?

There are two things relationships need. Continuing benefit to parties involved and mutual trust. And trust is built through actions over time.

Traditional UX life cycle can be seen as:

Awareness -> Sign-up -> First-time use -> Engagement -> Referral

Each step has to offer more benefits to person taking it as it requires more trust. Moving sign-up after first-time use changes dynamic by making service prove itself before asking same of its user.

Using Facebook Connect (or OAuth, OpenID…) is just going further in mimicking natural relationship building. It’s asking of a smaller commitment at a fragile stage of relationship. You can ask for a bigger commitment with your own authentication later on, when you have already proven your worth and gain enough trust. You could even offer something available only to “full” members to make such commitment more enticing.

If you are building years long relationship like I have with Amazon, does it really matter if you get me to fully sign-up after third month instead of first?

Hence sign-up should be thought of as a gradual process taken over time instead of one-time obstacle.

All this is just speculation at this point, but I hope to test it on two projects this year. If I do, I’ll let you know how it went.

It would also be nuts not to go and if you are a European (or not) Python developer you owe it to yourself to come.

I go to a few conferences every year and each has its own personality. It is sometimes hard to point at what makes them (feel) different, but they just are. I like many, but only EuroPython, which I regretfully had to miss last year, feels like home.

That’s why I decided to volunteer this year. It’s a way to give a little bit back, like cleaning dishes when you visit mom.

So do submit your talk and come. It won’t be the same without you.

There is no point in speculating why some of its features don’t work in more browsers. But I was surprised to see that blurred images are served that way and don’t get blurred in browser. I am playing with an idea of implementing a gallery inspired by Mike’s work, but I would like to reduce manual labor needed for maintaining it.

So I wrote a function that blurs an image on canvas. You can see it in action or copy its code, if you find it useful.

The algorithm used is described in 2001 paper by Wojciech Jarosz. Page contains two implementations, second trading algorithm purity for in my opinion nicer code. Increase number of passes or run it few times over an image, if you need a blurrier result.  Please ask, if you need help with its use.

I also measured its speed to see if it fits my needs. That brought a new surprise. Firefox 3.5.8  on my Linux powered VAIO with 1.2GHz processor blurs image twice as fast as same browser on a Mac with a 2.8Ghz processor. Numbers between runs may vary slightly, but never much. No idea why this is happening, since all functions do is some basic math over items in array that should be well optimized everywhere.

I am sure somebody can optimize it further, but I find it good enough for my use. Image isn’t very blurred after one pass, but one pass over a small image is also a good way to measure how fast a particular computer-browser combination is. On fast combinations I might go for multiple passes over images in view, but fall back to a single pass or no pass on slower systems.

I want to stress that while we use prototypes to learn what to implement and how, there is no guarantee that any particular feature shown will be actually included in our products. We do make an effort of listening to our users so please tell us what you think.

This is also a good time to mention that I don’t lead front-end team at Zemanta anymore. My new title is Chief Product Officer which is a fancy way of saying that it is my task to care about our products and our users more deeply than anybody else.

Related articles by Zemanta

• Zemanta Hackday Spring 2010 (zemanta.com)

Offline Wikipedia. When I am not behind a computer or reading, I like to be outdoors and even though cheap always available Internet was supposed to be here any day now, I regularly find myself information hungry in places with a very slow or no Internet connection. N900 with SD card could pretty much store everything I wanted and building an app that process and display information from Wikipedia dumps doesn’t look like a too difficult task.

Better dictionary for Maemo. QStarDict port is great and it has become one of my favorite applications. However its user interface suffers from being a direct port of a desktop version one and could be improved with one that wastes less space and is orientation aware. Reading dictionary is one of few things I wish I could do in portrait mode.

Web platform for Maemo. Wouldn’t it be great if you could build Maemo applications with web technologies? QtWebKit is a great place to start and I am certain I could expose new functionality through addToJavascriptWindowObject of QWebFrame class. Beside exposing this stuff I would also like to create tools and interfaces for developers and users alike with which they can easily package a web application as a standalone Maemo application or in case of users, turn a website into an application (I know you can add a bookmark to a website but it is not quite the same thing).

Caffeine for N900. I would like to pick “Switch profile to silent for <x time>” and know N900 will turn back normal profile when that time period expires. I always forget to turn ringing back on after I leave cinema.

Monitor unknown calls. I don’t want to pollute my address book with every phone number under the sun, but I would appreciate if I could get a hint if I ever talked or called the number in question. Bonus points for using public phone books to fetch name for given number and parsing number for clues (which country or part of it is call coming from).

This is not a complete list of things I want, but rest are mostly feature requests (except email client which currently really kind of sucks). For example I wish calendar had support for CalDAV or PDF viewer for screen rotate, search and fit to width.

I am aware that Maemo should be called MeeGo now, but a habit of years can’t be changed in few weeks. I searched for above applications and didn’t find them, but if you know of any I missed, then please let me know.

Zemanta widget in various incarnations today works in all major browsers (Firefox, Internet Explorer, Chrome, Safari and Opera) and on all major blogging platforms. This wide support is presenting ever bigger challenge to us and to anyone who wants to follow our path.

Most blogging platforms today support enhancement of blogs with widgets. I think it is time for them to add support for widgets on content creation side and go beyond current one-interface-fits-all state of affairs.

Open platform would enable tool makers like us to build specialized tools that might cater to specific niches and empower writers to customize their workflow to their needs .

Such platforms should at minimum have a common shared feature set, but I hope for at least partially shared API.

Current state

Some platforms like WordPress already have a plug-ins API which can be used to customize parts of creation process. However it is usually very low level, highly platform specific and available only to self-hosted users.

Creators of rich text editors have also recognized a need to let outside developers extend writing experience. Most major editors have an API that admittedly we might not be using enough. But this is not true of all editors so we end up with common development problems like not enough feature overlap and missing, undocumented or poorly documented interfaces.

There is a lot of activity, but the end result is still a very fragmented landscape that in my opinion limits developers creativity. You either add wanted functionality to your favorite platform or if you are more ambitious, you end up seeking the right balance between ironing out platform peculiarities and building features users actually care about.

And since blogging environment that most people use lets them little control over it, we develop browser extensions that are really just a patch for this problem. The only reason why we bloat browsers (a little bit) with an extension that most of the time does nothing is because we have to. Extensions are great, but they also present a risk and in this case one that should not be necessary.

My vision of future

What I would like to do as a developer can best be explained with examples translated from code to English (well, approximation of it anyhow).

I would like to write: “Take image at this address, upload it to writer’s image repository and return me its new address.”

I would like to write: “When DOM node is added to text (or removed from it), run this function.”

I would like to write: “Before text is published, run it through this filter function and save its result.”

I would like to write: “Store this information and let me retrieve when I need it.”

I would like our users to add our widget with only a few clicks. Maybe a click on our side to trigger installation and a confirmation on blogging platform with a list of permissions sought (like OAuth).

When user interface needs to be shown, I would want it to be well integrated. So if elements of interface can be rearranged, hidden or otherwise handled, then our widget would behave as expected.

In conclusion

Creating and supporting a tool like Zemanta is difficult. Front end development is challenging enough when you are against few browsers on your platform, but it is far worse when you try to deliver the same high level of experience on multiple platforms none of which you actually control.

You keep hitting at browser quirks and unexpected platform changes and ironically it keeps getting worse as other people’s code gets better. For example, wrapping your Javascript code in anonymous namespace is good practice, but it often removes hooks on which you relied and you need to come up with a new solution.

My work often feels like war of attrition, which is odd because there is no enemy. We work to complement blogging platforms, not replace them.

Surely it is time we do better.

I wrote this post at the start of February 2010. I believe everything I write about technology to be hopelessly out of date after 6 months, but I expect this article will be obsolete even sooner. So by the time you got around reading this, most of my gripes might not even be true anymore.

Nokia N900 is an uncut diamond. A wonderful thing made by talented designers that has quite a few rough edges, not all of them in device. I wouldn’t recommend it to most people, but to some of you it might become your favorite computer. It goes with me almost anywhere.

If you want a rock solid phone, then this device is not for you. I was unlucky to be in minority of people who experienced constant reboots. By constant I mean few times every hour.  My Nokia also lacked a 2GB partition, which meant I was constantly running out of space in which to install applications. Both of this problems have since been fixed. I still have a problem with GSM connection occasionally completely dying, which I can fix only by manual reboot. I’m personally not bothered since I don’t use it as phone.

On the other hand updates to software are regular, with one major firmware update already, that fixed some of my problems (reboot). Annoyances of today might literally be gone by tomorrow and thus my disclaimer.

I know how much effort goes in good software and don’t want to be too negative, but email really does suck for IMAP users. Not only doesn’t it cache headers, so if you have a slow connection and a big Inbox, get used to waiting. You also can’t set sent mail, drafts or trash folders which makes it useless to me for anything but reading email. Even worse, it creates its own folders (like iPod touch) to make a mess in your account. I am all for simplicity and avoiding needless configuration options, but it could at least get a list of folders and compare Levenshtein’s distance to common names (Sent, Sent mail…).

Gecko (Mozilla) based browser though is great, in my opinion much better than iPod’s and I completely switched my mobile browsing to N900. I am biased since unlike many I never was fond of constant zooming in and out (with pinching). My opinion might have been different if my eye-sight was poorer and I needed to zoom more.

If you are a Linux user or appreciate freedom, then it’s difficult to find a better mobile device. N900 is a Linux machine which happens to also be a phone and you have complete access to everything. There is a store (Ovi) and app manager, but you can install and run anything willing to run without permission from anybody. Terminal is loaded by default together with tools needed to prod into the system and root is one package installation away.

I dislike fixed space of iPod. N900 is only slightly better. You can expand it with SD cards, but you have to open battery cover. It looks so fragile that I don’t intend to actually do this unless absolutely necessary. Speaking of storage, as a programmer I can understand why applications can use only 2GB of it, but as user it simply looks daft.

Pair of contact and conversations applications is absolutely brilliant. Instant messaging, Skype and SMS are superbly integrated and they also feed contact application with information about your buddies found on those networks.  Install Hermes and you can update it with data from Twitter and Facebook.

Screen has higher resolution than iPod’s, but physically same (small) size, which means I’ll keep reading PDFs on my 770. Since it’s resistive instead of capacitive, it needs more pressure than iPod’s, but works better at -12 degrees centigrade (this picture was taken with my gloves on).

Maemo has a very active and generally supportive community, but some members can also be needlessly unfriendly. Just because you know where everything is and have seen certain faux pas 100 times before, it doesn’t mean either is true for a new N900 owner with a problem.

N900 RUNS PYTHON, which was my main reason for preferring it over an Android phone. Documentation is a bit all over the place, not always current and I still haven’t found information about how to control built in cameras, but I am an optimist that this will be sorted out soon and that documentation will improve as well.

I compared N900 with diamond, but maybe a better comparison would be a sports car. If you want a polished, sedated experience then N900 is certainly not for you (yet). But if you are a tinkerer who doesn’t mind rough edges in exchange for freedom to make it do almost anything, then you should give it a spin.

There is so much more that could be said, but big picture wouldn’t change much. I haven’t talked much about UI since I simply couldn’t do it justice in few sentences. On the whole it works fine and multitasking is really great even though I think iPhone/iPad’s switch-to-where-you-were model is in my experience rarely a problem and wouldn’t be surprised if it was here to stay.

If there is anything about it you would like to know, then please ask and I’ll try to respond to it promptly.

Discussion started with this function:

1. function average(arr) {
2. var i, sum = 0;
3. for(i=0;i<arr.length;i++) {
4. sum += arr[i];
5. }
6. return sum/i;
7. }
8.  
9. Download this code: /code/dreamjs.txt

Dream me, who by the way is significantly more bitchy than I ever am, wasn’t pleased and thought he could save few bytes by storing counter and sum inside of the array:

1. function average(arr) {
2. // Store counter in array[0] and sum in array[1]
3. if (arr.length < 3) {
4. return arr.length == 2 ? arr[0]+arr[1] : arr[0];
5. } else {
6. arr[1] = arr[0]+arr[1];
7. arr[0] = 2;
8. for(;arr[0]<arr.length;arr[0]++) {
9. arr[1] += arr[arr[0]];
10. }
11. }
12. return arr[1]/arr[0];
13. }
14.  
15. Download this code: /code/dreamjs2.txt

This looked ugly, but what bothered him (me?) was more that it also had a bug. Integer in Javascript is limited to 2⁵³, which is a lot, but sum can still overflow or underflow it. Since mean can never be smaller than smallest or bigger than biggest number in a list, I could fix it by writing:

1. function average(arr) {
2. var n = arr.length, sum=0;
3. while (arr.length) {
4. sum += arr.pop()/n;
5. }
6. return sum;
7. }
8.  
9. Download this code: /code/dreamjs3.txt

End of dream. Everything edited for sanity and brevity.

I don’t have much to say about second program except that I would never write something so ugly just to save 16 bytes in a function like this. I wouldn’t even use Javascript if memory was that important.

I am more intrigued by third program. Bug in second is definitely there, even though few of us operate with numbers big enough to encounter it.

It’s interesting, because if I was awake, I would probably never think of it. I used to worry about bugs like this all the time, when I was coding in C. It was an unavoidable consequence of the language.

I guess what I am getting at is that it is nice to code in a high-level language and for the most part not think about implementation details like this, but only as long as you actually know them so your brain gets triggered when they matter. Speaking of details, I bet those divisions can cause rounding errors.

Who knows? Probably all of these reasons played a role.

My private goal was to read a book every fortnight, so about 26 in total. I read 37, some of which admittedly very light in content or girth.

Time to present the books, listed in chronological order. I linked those I liked and set in bold those I recommend. Unlinked were either bad or intended for someone I can’t relate to.

DISCLAIMER: Most links point to Amazon and include my affiliate ID meaning if you buy them after following these links, I get few cents that might eventually lead to purchase of another book.

1. Mind Performance Hacks by Ron Hale-Evans. Surprised to see how many of them I discovered independently through years.
2. The Cold War by John Lewis Gaddis. Fantastic short history of cold war.
3. The Non-Designer’s Design Book by Robin Williams
4. The Non-Designer’s Type Book by Robin Williams. Like previous one probably useful only if you know absolutely nothing about design.
5. Business Cards 2 More Ways of Saying Hello by Michael Dorrian, Liz Farrelly. Worth a look before you make your own.
6. Here Comes Everybody by Clay Shirky. Astute and interesting, but might be redundant if you already follow Clay’s writing.
7. Guns, Germs and Steel by Jared Diamond.
8. Sticky Graphics: Create Memorable Graphic Design Using Mnemonics and Visual Hooks by Jessica Glaser, Carolyn Knight. WTF?
9. Thursday Next: First Among Sequels by Jasper Fforde. Fantasy series for book lovers. Enjoyed more if you’ve read a lot.
10. Designing Web Interfaces by Bill Scott, Theresa Neil. Components of modern web applications. A book that should be on the shelf of every web interaction designer.
11. Reader by Bernhard Schlink. Excellent book, haven’t seen the movie.
12. The Wall Jumper by Peter Schneider. Timeless portrait of German separation.
13. Everyware: The Dawning Age of Ubiquitous Computing by Adam Greenfield. Really late to the party with this one, but still a good and fairly unbiased treatise on intelligent tools and environments and problems related to them.
14. Always Building: The Programmable Environment by Jim Long, Jennifer Magnolfi, Lois Maassen. Optimistic thinking and examples of adaptable environments by people from Herman Miller.
15. Javascript: The Good Parts by Douglas Crockford. Concise but informative description of good parts of Javascript useful for most programmers.
16. Stardust by Neil Gaiman.
17. Ender’s Game by Orson Scott Card. As good as people say.
18. Small Gods by Terry Pratchett. In my opinion still the best book by Terry.
19. A Theory of Fun for Game Design by Raph Koster. Worth reading if you want to know what makes games fun and what to expect in future.
20. Aid and Other Dirty Business: How Good Intentions Have Failed the World’s Poor by Giles Bolton. Excellent when looking at facts of aid “business” (first 4/5 of the book). Weak when it comes to solutions with seemingly unlimited faith in globalism and power of a consumer.
21. The Caryatids by Bruce Sterling. Interesting and occasionally excellent, but a bit of a let down compared to some of his other work.
22. Sketching User Experiences: Getting the Design Right and the Right Design by Bill Buxton. Excellent book about sketching and its role in design. A must read for practitioners.
23. The Buddha: A Very Short Introduction by Michael Carrithers. Buddism seen through life of the Buddha.
24. Archaeology: A Very Short Introduction by Paul Bahn. Fun.
25. The Four Steps to Epiphany by Steven Gary Blank. I can’t recommend this book highly enough to anyone starting a new venture. Absolutely a must read.
26. The First World War: A Very Short Introduction by Michael Howard. Short, but good.
27. Everyman by Philip Roth. Facing old age and death, a book I liked more than my wife.
28. Contemporary Art: A Very Short Introduction by Julian Stallabrass. How contemporary art (world) functions and less what it is.
29. Judaism: A Very Short Introduction by Norman Solomon.
30. By Night in Chile by Roberto Bolano. Discovered by method of pulling random books from shelves in book store. Absolutely superb.
31. Against the Gods: The Remarkable Story of Risk by Peter L. Bernstein. A book about history of risk management made only more relevant by last financial crisis. Fun and very informative.
32. Forget Kathmandu: An Elegy for Democracy by Manjushree Thapa. Modern history of Nepal told through personal experience. Recommended if you are interested in Nepal.
33. The Life and Opinions of Tristram Shandy, Gentleman by Lawrence Sterne. Hard to believe that 250 years old novel can feel so modern.
34. Unseen Academicals by Terry Pratchett. I might be biased, but I would put it among his best novels.
35. Prototyping: A Practitioner’s Guide by Todd Zaki Warfel. I never got around writing review of this book. Definitely worth a read for practitioners.
36. Getting Started with Arduino by Massimo Banzi. Aimed at designers, but learned few new things anyway.
37. The City: A Global History by Joel Kotkin. Sort of a short introduction to history of cities with everything good and bad that format entails. Excellent starting point for those interested in its subject.

I wish I read as much as Aaron (latest review), who seems to devour about hundred books per year, but I don’t think I’ll ever manage that. My goal for this year is going to be about same, 25 books before bells toll midnight on 31st of December. It still is an ambitious goal, since these days I seem to have a penchant for buying tomes at least 600 page thick and want to read more of other people’s code.