Recently, I’ve been trying to read at least one book every week, and this week’s pick was “Expert Python Programming” by Tarek Ziade. Besides its few shortcomings, I found it to be useful - Python is a language of choice for me, and I found some valuable tips I could add to my arsenal.

The best thing about this book is that it covers a very wide range of topics: syntax recommendations and code profiling, testing practices and project management, technical writing and design patterns, package distribution and version control… My favorite chapter covered writing technical documentation: I am very interested in writing in general, and the tips Ziade provided turned out to be very useful for documenting code, writing design documents, and even posting to this blog. Not much else caught my eye, but I had a number of “Aha!” moments such as, “Oh, I never used that!” and “That’s an interesting topic to look into!” scattered throughout the book. This book is very useful for filling in little gaps in knowledge which programmers can have: the author covers an extremely wide variety of Python development aspects.

Unfortunately, I found the book to be poorly written. Weak writing style, typos in the text and code examples - it looked like the book was put together sloppily, in haste. Reviewers did not do a very good job evaluating this book. “Expert Python Programming” gives you the feeling that the author tried to fit in as much content (and code) as possible in his book, with no consistent style. Many chapters go into unnecessary details, and the author has tendency to paste completely useless chunks of code, such as a page-long output of an installer. As I have mentioned, the book hops from one topic to another, and covers a wide variety of subjects: this is both a key strength and the biggest weakness of the book. There is just “too much stuff” and it’s too scattered across the topics.

“Expert Python Programming” will be of best use to, you guessed it, an expert. I found it best to scan through the content and seek out interesting bits of information. Beginners, however, might be completely overwhelmed. While advanced and intermediate Pythonistas will get the most out of this book, it will probably be too hard (and painful) to read to be of real value.

Today I received in the mail a copy of Steve Krug’s “Don’t Make Me Think, Revisited: A Common Sense Approach To Web And Mobile Usability” (oh, that’s a long name). I went through the whole book only in under a few hours, and I am so glad I’ve read it. It’s a very quick read, but the book is full of concrete and valuable tips and advice about usability.

“Don’t Make Me Think” contains practical advice on a large number of topics: web and mobile usability, design, and writing for the web. The advice can be easily used and incorporated into your daily workflow; and the author provides concrete guidelines for applying his tips in the real world.

The biggest thing I’ve learned from this book (and want to apply in practice) is individual usability testing. I actually performed my first usability test just three days ago, just before reading “Don’t Make Me Think”, after I found that Donald Norman’s masterpiece mentioned observing user interactions with your product (I’ll get to the similarities between two of these books in a moment).

I asked two of my colleagues, one after another, to visit a website I was working on, and I silently watched them navigate through it. They had never seen the website before, and the results were very shocking to me: they ignored the things most obvious to me, but attempted to click through things which are not even meant to be clicked. I carefully wrote down all of my findings, and delivered the patches with enhancements to improve the biggest areas of struggle these particular users had faced.

Usability testing turned out to be invaluable: it pointed out actions that I, as a developer, did not anticipate, and highlighted parts of the system ignored by the users. I now plan to run usability tests regularly, grabbing colleagues from the hallway, and asking them to use my application for a few minutes.

Steve Krug’s book is very much like “The Design Of Everyday Things”, but stripped from the extended theoretical part. The book references Norman’s work quite a lot, and seems to be heavily influenced by it. It focuses on practical aspects of designing easy to use and understandable user interfaces. It successfully explains why you should be thoughtful of user experience, accessibility, and understanding the way users think. I would recommend reading this book after reading Donald Norman’s masterpiece first, since it provides you with the reasoning behind many decisions Steve Krug makes throughout his book.

Unfortunately, I have not been reading as much as I would love to lately. In the past year I have only read two books, one of which was a technical manual. Don’t get me wrong, I still had a lot of personal and professional growth going on: reading blogs, articles, guides, watching keynote talks… But I did miss the feeling of holding a good book in my hands, turning the pages with the tips of my fingers, seeing the texture of the paper under the print. A few weeks ago I went ahead and ordered one of the books on my reading list: “The Design of Everyday Things” by Donald A. Norman. I just finished reading it a few hours ago and am eager to share my impressions of the book.

“The Design of Everyday Things” turned out to be one of the most eye-opening books about design I have ever read (alright, alright, I haven’t read any design books before). It’s mind blowing to think that I have never considered the points brought up by the authors. Hell, (and I will probably have rotten tomatoes thrown at me for this statement) but I didn’t even think design was a “real” job. Oh dear, how wrong I was.

Norman’s masterpiece talks about the psychology of everyday things (which was actually the initial title of the book, but was changed to “Design” after the first release). The author explains how users make decisions, use objects, make errors - and so many other factors which should go into the design process. Norman explains fundamental basics of the psychology of human-object interaction, something most people never think about. How hard could it be to design a door? Turns out the answer is - very hard. And every time you see someone pulling the door instead of pushing and vice versa - it’s a result of a poor design. So many everyday frustrations could have been avoided if designers would have put more thought into usability of their product.

I build software for living, and I was skeptical if I even needed to know anything about good design. I mean, how hard could it be to put together a few pages and forms? “I tackle complex software problems, I don’t need any of this liberal arts bullshit!” - I thought that way, and I know many people who still do. Well, Norman’s book is a great starter for people like me: he does a great job explaining why the design process so important. By the time I finished reading it, I had a pretty solid set of ideas why there are so many things wrong with our industry, and how good, thoughtful design is a way out. The funniest part is - the book itself is published in the year 1988, over twenty-five years ago. It doesn’t talk much about computers, concentrating on objects more common at the time: cars, telephone systems, even stoves and dish washing machines. And here I am, reading this book in the year 2014 - and the situation did not change at all. Expensive laundry machines are as hard to operate, computer programs are as clunky.

“The Design of Everyday Things” compels the reader to become a part of the solution to this enormous and bulky design problem the world is stuck with. In the everyday world, for every good case of design out there, you will face a hundred faulty, frustrating, and downright insulting design attempts.

The book is very easy and pleasant to read, and I went through it in under a week. Most of it is a set of rants about poor design decisions, with suggested improvements and solutions. Throughout the reading process, I had to revisit the systems I built at work and rearrange the components, add more feedback to user’s actions, and do many other little and big improvements in order to make make the system image much more transparent to the user. Norman taught me the most obvious truth: a designer is not your typical user of the system. This changes so many things, makes you doubt and rethink a number of design decisions you made along the way - all in order to build a product that is easy and pleasant to use.

I now consider myself to be blessed with an understanding of the importance of good design, and admitting there is a problem is the first step to fixing it. And believe me, there is a problem. I will now continue learning about the best practices in building systems that are easy to understand and pleasant to operate for the user. My next stop is “Don’t Make Me Think, Revisited: A Common Sense Approach to Web Usability” by Steve Krug. I’ve heard a lot about this book, and I will be sure to share my impressions here.

I enjoy organizing things. I am accustomed to keeping neat “To Do” lists, written notes, and just about anything that will let me arrange my tasks instead of actually accomplishing them. I recently stopped writing things down, and the results were pleasantly surprising…

I was keeping a list of things I would need to complete. I organized it by priorities, and at some point I even used Gina’s fancy “Todo.txt” wrapper for managing it.

What I realized after using such a scheme, is that my list was growing longer and longer with every week. After a while, the number of tasks became hard to manage, and the number of tasks became permanent residents on my task list. Why did this happen? Well for one, I turned my list into a “check box machine”. Complete a task, check off a check box. There was no mindfulness about it: I was just completing task after task. “All right, this one is done, let’s move to a next one.” - this is what was constantly running through my head. Secondly, by writing down a task on my list in the first place, my brain would register it as being completed, and then I’d go on with my day. Needless to say, certain tasks would sit on my list for an indefinite amount of time.

After a while, I deleted my “To Do” list. Instead, every day I ask myself a simple question: “What should I do today to succeed at what I am trying to accomplish?”. This way, work becomes achievement driven. I started choosing tasks which provide the biggest impact, dedicating some days just to minor “clean up” tasks which I didn’t deem important enough for productive days.

I threw away my “To Do” list, and I am glad I did it. I love being mindful about my day, I know exactly what I need to accomplish in order to succeed. It’s easy to get caught up in a daily route, and forget that your life isn’t just a list of things to do, but a number of goals you want to reach. By not relying on a written manifesto cluttered with tasks, I am forced to concentrate on the bigger picture, where what I set out to accomplish has the highest possible impact on my life and career.

I prefer to create and edit my posts in plain text. It’s a timeless format, and I find it nice to have an archive of posts lying around in plain text.

I wrote a little Python script which I used to extract an archive of my posts and pages into a bunch of files on my computer. In order to use it, you need to use “WordPress Importer” plugin. Export your posts and pages into a WXR format, and feed the file to the script.

Source code of the script is below (link for downloading the script is at the bottom of this post):

#!/usr/bin/env python

"""This script converts WXR file to a number of plain text files.

WXR stands for "WordPress eXtended RSS", which basically is just a
regular XML file. This script extracts entries from the WXR file into
plain text files. Output format: article name prefixed by date for
posts, article name for pages.

Usage: wxr2txt.py filename [-o output_dir]
"""

import os
import re
import sys
from xml.etree import ElementTree

NAMESPACES = {
        'content': 'http://purl.org/rss/1.0/modules/content/',
        'wp': 'http://wordpress.org/export/1.2/',
}
USAGE_STRING = "Usage: wxr2txt.py filename [-o output_dir]"

def main(argv):
    filename, output_dir = _parse_and_validate_output(argv)
    try:
        data = ElementTree.parse(filename).getroot()
    except ElementTree.ParseError:
        _error("Invalid input file format. Can not parse the input.")
    page_counter, post_counter = 0, 0
    for post in data.find('channel').findall('item'):
        post_type = post.find('wp:post_type', namespaces=NAMESPACES).text
        if post_type not in ('post', 'page'):
            continue
        content = post.find('content:encoded', namespaces=NAMESPACES).text
        date = post.find('wp:post_date', namespaces=NAMESPACES).text
        title = post.find('title').text
        date = date.split(' ')[0].replace('-', '')
        title = re.sub(r'[_]+', '_', re.sub(r'[^a-z0-9+]', '_', title.lower()))
        if post_type == 'post':
            post_filename = date + '_' + title + '.txt'
            post_counter += 1
        else:
            post_filename = title + '.txt'
            page_counter += 1
        with open(os.path.join(output_dir, post_filename), 'w') as post_file:
            post_file.write(content.encode('utf8'))
        post_counter += 1
    print "Saved {} posts and {} pages in directory '{}'.".format(
            post_counter, page_counter, output_dir)

def _parse_and_validate_output(argv):
    if len(argv) not in (2, 4):
        _error("Wrong number of arguments.")
    filename = argv[1]
    if not os.path.isfile(filename):
        _error("Input file does not exist (or not enough permissions).")
    output_dir = argv[3] if len(argv) == 4 and argv[2] == '-o' else os.getcwd()
    if not os.path.isdir(output_dir):
        _error("Output directory does not exist (or not enough permissions).")
    return filename, output_dir

def _error(text):
    print text
    print USAGE_STRING
    sys.exit(1)

if __name__ == "__main__":
    main(sys.argv)

You can download the script from here: wxr2txt.py.