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.

jeudi 29 octobre 2015

Refactoring, you're doing it wrong (en)

Some developers consider that refactoring is a huge chunk of work that needs to freeze the repository during a week. A week when every features are broken and rebuilt. Afterwards, another week is needed to merge the new features, once pushing on the central repo is authorized again. That’s so wrong, so costly!

It reminds me a talk by Joshua Kerievsky in which he explains more or less that I would try to remain the shortest time possible in the red while refactoring. With this principle, he keeps the ability to deploy continuously while refactoring the whole system. It’s been revelation for me. I like to feel I can deploy whenever I want, even if I don’t have the need to do so. In fact, I do not want to be in a situation where I block the repository, where I prevent my team mates to commit, where I’m sure I will spend painful hours to merge others changes one by one without feeling safe about it.

The ideas:

  • Refactor in small steps. Consider that you will continuously refactor the application and not perform a big bang refactoring once in a while. Think boy scout rule.
  • Consider refactoring only if you have a decent code coverage on the part you want. If you don’t, start with writing a test harness. At least system tests that will experience the code from the UI and check the outputs or the database. If you want to do refactoring that matters, you have to be damn sure that your are not slaughtering the application.
  • Use your IDE. You have to know every features that lies in the Refactoring menu and use them rather than manual editing. Tooling won’t take any risk and they will ask you if they’re not sure of what they’re doing.
  • Consider the “I build a huge amount of code that will work in parallel of the current system that I’ll branch when it’s ready” only when you have no simpler solution left.

Timebox your refactoring session. I promise you that you can do significant improvement within 30 minutes. Tell yourself that delivery is tomorrow, or in 1 hour or in 30 minutes. It will keep you motivated

(this post is a translation of an older one)