mercredi 23 novembre 2016

My talk at Pyconfr 2016

This year I got the chance to speak at the Pyconfr! It was motivating for me, as it is a national event and, as you may know, I really like Python.

I was a bit nervous, of course, but as trained myself before the talk, I gained confidence. It's a chance, because I was not so motivated to rehearse. But if I did not, my talk would have been lame. I mean, more that it actually was!

For the record, I submitted 2 talks at the CFP this year. The first one was about Hypothesis and property based testing. I really wished it would be accepted, as it would have motivated me to explore this library.

The one that has been accepted is Help, we to not have any Python project in my company, not so easy to present. You can watch the video here!

And, yes, it's in French.

mardi 1 novembre 2016

Fed up with properties files

Once again, in the source code of our applications, I find lots of constants defined in a properties file in Java. Why that? In these files, one can only define strings. Reference to property entries are also strings. They're not checked at build time. Hence, they cannot be interpreted by an IDE. You cannot jump easily to your property value. It's a shame, as this is why we use heavy IDEs! Why are you carrying out such a sabotage???

In my case, a Java file references constants that are declared in another Java file where they reference… Properties! That's indirection for the sake of indirection.

In lots of situations, properties are useful though. You sometimes want to be able to configure your application without building it again. You want to be able to setup parameters specific to your running environment. You want to be able to change some parameters and see them applied without restarting the application, such as logger configuration.

That represents very few cases though. This is not a good idea to store to every constant that are used by your application in those files. In most cases, changing a constant value should be thoroughly tested. It is not something to be done by everyone, without going into build phase.

So please, stop using properties by default. Create one only when you cannot avoid it.

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.