mardi 25 octobre 2016

Namedtuples in Python

Lately, I integrated namedtuples in my Python programming vocabulary. They allow you to create data structure classes in one line.

Start by importing them from collections module:

from collections import namedtuple

Define a new class as a namedtuple:

Person = namedtuple("Person", ("firstname", "lastname"))

You can know create new instances of Person, as you would do with any other class:

john = Person("John", "Doe")

And if you print it:

In [8]: print(john)
Person(firstname='John', lastname='Doe')

(yes, I use IPython, don't you?)

Now let's see what namedtuples give you.


In [9]: f,l = john

In [10]: f
Out[10]: 'John'

In [11]: l
Out[11]: 'Doe'

Field access by name:

In [12]: john.firstname
Out[12]: 'John'

In [13]: john.lastname
Out[13]: 'Doe'

You also have access by index:

In [27]: john[0]
Out[27]: 'John'

In [28]: john[1]
Out[28]: 'Doe'

(OK, I tried some stuff during the redaction of the article)

And that means you can iterate on them, great!

In [31]: for value in john:
   ....:     print(value)

You can retrieve the indexes of defined values (like in tuples):

In [29]: john.index('Doe')
Out[29]: 1

And count the occurrences of the values for free (also like in tuples, which is useless in my example)

In [30]: john.count('John')
Out[30]: 1

There's more. Contrary to classes, equality is defined for you for free:

In [32]: john2 = Person('John', 'Doe')

In [33]: john == john2
Out[33]: True

And last but not least, like standard tuples, namedtuples are immutable

In [34]: john.firstname = "Billy"
AttributeError                            Traceback (most recent call last)
<ipython-input-34-a7d9f29302d8> in <module>()
----> 1 john.firstname = "Billy"

AttributeError: can't set attribute

This last one is awesome.

So what is cool with all that? The great strength of tuples is that they are immutable, unlike lists. Thats why, when you have an array of values that is not subject to change, you should consider to create it as a tuple by default. Tuples are memory efficient and give you the insurance that nothing will alter them in your application. Besides, the syntax to create them is a bit shorter:

In [39]: t = 1, 2, 3, 4, 5 # you don't even need the parens!

In [40]: t
Out[40]: (1, 2, 3, 4, 5)

Named tuples extends this ability to any data structure you could create, giving you access to fields by name for readability.

The only drawback is that you cannot define methods or properties on them, as you could do in immutable data structures in other languages. Yet it is still a nice feature of Python.

mardi 23 août 2016

Playing with Tkinter

I committed to produce a GUI for an utility at work. My idea was to use Tkinter module in Python. It was a great pretext to use it for the first time!

Tkinter is a GUI toolkit provided with Python’s standard distribution. It’s great since it avoid the burden of installing an external dependency on target systems. I’m impressed because the development is really simple. I’ve faced far less difficulties that I had with wxWindow in the past (I’m also more experienced though).

Before coding I believed that the toolkit would produce bad looking UI. Actually that’s the case, unless you use themed widgets from ttk submodule.

I struggle to find decent documentation as there is too little documentation on Python’s website. I found something relevant here (doc also available in PDF). Stack Overflow takes care of the rest.

Epilogue: eventually the piece of software will be coded in vb.Net and integrated in a larger app. It’s a shame! By the way I had fun working with Tkinter.

mercredi 8 juin 2016

The Software Craftsman

I’ve been asking myself if I should buy and read The Software Crafstman by Sanddro Mancuso given I already read The Clean Coder by Robert C. Martin. Both books deal with the same topic: professionalism in software development. Lately, I grabbed a copy from a colleague (thank you Jeff) and I read within a weekend (skimming a few pages, I admit).

There’s a lot in common between this book and the Clean Coder of course. What I appreciated though is that being younger than Bob, Sandro writes about experiences close to mines. He talks more about issues on Java projects than bugs in the early stage of computing with punch cards and teletypes.

What did I took from the book? The part about building a learning culture at work. Proposed ideas are great! I regret the overall tone of sarcasm against management though. The book is worth reading for managers too, not to blame them but to educate them.

Do you need to read it if you already read other book on technical agility, like the Pragramatic Programmer, Extreme Programming Explained or The Clean Coder? Maybe not. On the other hand, if you just discovered and feel attracted by the idea of software craftsmanship, this book is the perfect companion to start your journey on this path.

vendredi 3 juin 2016

TDD By Example

I’ve been practicing Test Driven Development for years now. Yet, I haven’t read Kent Beck’s book TDD by Example until these days. And I have to admit I learned useful things!

First, you all know the 3 steps of TDD: red bar, green bar and remove duplication. But I though that it talked about duplication in the production code. Actually, the most common aspect of duplication when you TDD is between your testing code and your production code. For instance, when you write as the first test for a sum function:

assert sum (1, 2) == 3

Then the code:

def sum(a, b):
    return 3

The hardcoded value 3 is a duplication you have to get rid of when having a green bar. It’s nice because you don’t have to write another test to create a triangulation situation (notice that following this logic of triangulation, you could create a test for every different input. That’s stupid).

When I began, I did not understand this idea of the most simple implementation possible that passes the tests. Today, I do it systematically: it allows me to get my first green bar quickly. It’s not that simple because all the code that is called in the test has to be implemented. Now I can give an explanation for this way of doing!

I also learned is that the goal of TDD is not to allow you to write the perfect code during your first sprint (or iteration) though it’s a great too to do so. The test harness allows you to deliver good enough code that will be easy to extend when new features are needed. Most of the time, you do not need an over engineered generic code and it’s OK not to comply at 100% to the Open Closed Principle at first.

Refactoring is a very pleasant activity that can give a lot of satisfaction: you are in the green, you add abstraction, you implement design patterns to show your skills to your colleagues. But it takes time and you’re not payed to show technical mastery. You’re paid to add value, to help your company to gain more profit!

I had this problem lately. Getting into Domain Driven Design, I had a tendency to put the patterns in place everywhere. Sometimes, I may have fall into the over engineering trap… Well, that’s learning!

lundi 25 avril 2016

Now I use space as leader

Lately, I read an increasing number of articles about using space bar as leader key to Vim. So I decided to give it a try.

Leader key is a key that can be use in your Vim mapping with the <leader> keyword. For instance:

" Typing <leader> then n in normal mode toggles NERDTree
nnoremap <leader>n :NERDTreeToggle<cr>

So it can quickly become a mapping trigger.

I have to admit I am a recent user of the leader key. By default, it's set to backslash. You can change it by writing the line bellow in your .vimrc:

let mapleader='<some_char>'

Backslash is not convenient, even less for French users sticking with French keyboard layout. So I changed to the comma (as I read it was the way to do). It makes me begin to use it in my mapping. But I have not using it a lot so far, as the comma does not get so easily under my finger.

And a couple of days ago, I decided to map it to space. And I got my mind blown!

" doing so is enough
let mapleader=' '

Obviously, the space bar is the most accessible key of your keyboard, so mapping can be typed as easily as possible.

The greatest effect is that it makes me think about creating new mappings to improve my productivity. And I have a lot of fun doing it since then. I shall update my .vimrc on github soon. I have put some other new stuff in it.

jeudi 14 avril 2016

Lesson of humility

I had a bad habit in Java. I've been used to check for logger level availability before using it. Stuff like:

if (logger.isDebugEnabled()) {

I've been told to do so because blah blah blah.

Seeing this made my teammates a bit mad! Therefore I took time to search for a valid explanation. And I had to admit it was useless, at least with Java 1.5+.

The usage came because for logged strings that often happen to be made of lot of information, concatenated into a single String. As you may know, concatenating Strings with + is theoretically costly since a new String instance is created every time. In the real world, the things are optimized for you to use a StringBuilder.

Prior to Java 1.5, StringBuilder did not exists and you had to use StringBuffer which is synchronized. As you can imagine, logging could then cause an overhead in a multi threaded environment like a web server.

It always hurts to be wrong. It's worse to stick with unjustified habits though. I learned a great lesson this day.

vendredi 25 mars 2016

Documentation workflow

I do that because I use to spend a lot of time struggling with MS Word to get the document and the layout I want. I’m quite happy with the result.

Here are some special tips I use: come with docutils package in Python. You can install it with pip and it works with Python 2 and Python 3:

pip install docutils

I write documentation in French (mostly), with non ASCII characters. Therefore, every rst files I write uses UTF8 encoding. It can be a problem when you use on Windows with Python 3. Fortunately, you can specify input and output encoding with --input-encoding and --output-encoding optioins.

You have to fix the special characters like apostrophes, quotation marks and hyphens in your text file. To do so, you can use Vim digraphs.

I chose reStructuredText (rst) instead of markdown because it allows more options for layout. Precisely, you have a standard ways to draw tables. I know that AsciiDoc can to the same, but I do not want to learn another syntax.

Vim can do spell checking. Use this command:

:set spell spelllang=(your language)

If you do not have a dictionary installed for your language, Vim will download it for you. Default language is English, of course.

Pandoc is really easy to use. Oh, by the way, it’s written in Haskell:

pandoc -f rst -t docx -o your_doc.docx your_doc.rst

Adapting style in your resulting docx can be done painlessly in most of the cases. Select a paragraph that needs style change and use contextual menu to select every paragraph with the same style. Finally, apply the style you want to the selection.

It is a nerdy way to write project documentation, but it’s the way I like it. I think it helps me to write faster compared to direct MS Word editing.