It’s well known that the more we enter the digital era, the more our life becomes tracked. Our mobile phones, credit cards or web browsers leave tracks behind our back.

Most of Digital-natives are aware of that, but there is a rather new and intrusive tracking method that is making its way to our homes, it’s called electronic tracking.

It’s well explained in a talk given at the 28th Chaos Communication Congress entitled Smart Hacking For Privacy.

The idea is simple: if I monitor your home’s energy consumption regularly, I can say how many electronic devices you have, how many of them are up and running, when you’re at home, and even, theorically, which channel you’re watching on TV.

How so?

Each electronic device (a dish washer, a fridge, a computer) has a specific pattern of energy consumption, it’s like a digital signature saying “I’m here!” to the moniotoring device. All this was an interesting theory but was hardly usable in real life… Until energy providers started deploying so-called Smart Meters.

Smart Meters are a new kind of electical meters that are able to measure very frequently the global consumption of a house, it’s deployed in order to increase the precision of the consumer bills but can be used in many ways to become surveillance devices that monitor the behavior of the customers.

This leads to unprecedented and invisible invasions of the consumer privacy.

Even better: not only the Smart Metter is able to tell how many devices you have, and what they are, but it’s also theorically able to tell which TV show you’re watching!

The energy signature of a TV depends on the image it displays on screen (actually, its brightness will change its energy consuption pattern). So if the device has acces to a patterns database, it can compare the one your TV is leaking with it and find out which show you’re watching… Scary.

It appears that all of this raw data is sent by smart meters to energy providers, what will they do with that? It’s an unpleasant and opened question.

If they do use it to profile your home, it’s to me one of the most intrusive, invisible and violent profiling method we could imagine: the whole house being tracked, every 2 seconds, transparently.

I can disable my cookies if I don’t want to be tracked online, I can shut my phone down if I don’t want my provider to know where I am, I can pay cash if I don’t want my bank to track my expenses, but how could I live without electricity at home?

No related posts.

In my last post I spoke about how meetings can impact your productivity at work, I realized I could also write something about a programmer’s productivity in a more general manner.

At Weborama we have training days twice a year, where we give talks and traning sessions. I gave a talk last time about how to become a Pragmatic Programmer. Of course all of the ideas came from the famous book.

Here are the 10 most interesting rules I’ve found in that book, if a programmer manages to apply them in his daily duties, no doubt they’re pragmatic (and productive).

Rule #1: Do not repeat yourself

Respect the DRY principle:

Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.

This will increase your maintenance capabilities and lower bugs proliferation.

Rule #2: Fix broken windows

The concept of Broken Windows come from the criminological theory:

Consider a building with a few broken windows. If the windows are not repaired, the tendency is for vandals to break a few more windows. Eventually, they may even break into the building, and if it’s unoccupied, perhaps become squatters.

In software development, broken windows are bad designs, wrong decisions or even poor code. If you don’t fix them as you find them, you’ll end up quickly with software rot.

Rule #3: Crash Early

It’s always better to make your code crash as soon as possible. Using return values (error codes) to notify a calling component about an error is a very bad idea. Eventually, a component will ignore that value, that means that an error can occur and silently be ignored.

As the saying goes: Dead software don’t lie.

Rule #4: Use tracer bullets

The idea of tracer bullets is to get things up in production as soon as you can.

We speak also about code that glows in the dark. When you have a new projet in mind, try to get to the point where you can ship something in production. Just make it as simple as possible, don’t try to envision everything in the first place. The first target is to have a simple, consistent package that works, in production. After that, you’ll be able to upgrade that package iteratively.

The tracer bullet is your first package, by reducing its feature set, you’ll focus on the essential: production/packaging/deployment issues. Other features and enhancements will come later on. This strategy has also the benfit of reducing the risk of premature optimizations (which is the root of all evil, as you may already know).

Rule #5: Write Shy Code

Shy code is basically what we call the Law of Demeter. It could be described as the Principle of Least Knowledge, as Wikipedia explains:

The guideline [...] can be succinctly summarized in one of the following ways:

Respecting the Law of Demeter when writing code enhance maintainability and reduce code duplication (so yes, that helps you repsect rule #1).

Rule #6: Configure, don’t integrate

Details mess up our pristine code, they change frequently. Every change to the code is a risk to break the system. To avoid that, you should get the details out of the code, in configuration files. Configurable code is called « soft code », it’s adaptable to change.

Whenever you come to the point where you put details into your codebase, stop, and extract them out of it. The time you spend now will pay-off ten times in the future.

Rule #7: Refactor Early, refactor often

You should refactor, yes, but when? Here are the moments when refactoring is a good idea:

• You’ve found some duplication you want to remove (again, rule #1!)
• You want to extract details out of the code (rule #6)
• You see a way to generalize something in your code.

Also, don’t refactor blindly, if you go into a refactoring session it’s very important to do it well, or it will come back to bite you:

• Don’t refactor and add functionality at the same time
• Make sure you have tests to avoid regressions
• Take short, deliberate steps. Change one thing at a time.

Rule #8: Design to test

If you’re a perfectionist, you might write your tests before the code (it’s called Test-Driven Development) but it’s not mandatory. A matter of taste I’d say. What is important though is that you always keep tests in mind when you write the code. Respecting the Law of Demeter (rule #5) will definitely help, because a good encapsulation always leads to testable code.

If a part of the code is difficult (or impossible) to test, you need to refactor it to smaller components.

Rule #9: if you’ve found a bug, write a test

This is a very sane approach: whenever a bug is found in production, first thing to do is to write a test that reproduces the issue. That way you’ll be sure to understand the bug correctly before thinking at the fix and you’ll have a non-regression test that will make sure the bug won’t happen again.

Rule #10: Know when to stop

Programmers are like painters, they build a picture of some part of the world out of their mind. The major difficulty here is not know when, or where to stop. Keep in mind that perfect software does not exist (no, you won’t be able to write it, no matter how hard you try).

When is a painting finished? Only the painter can say so. You are the painter of your code, know when to stop.

No related posts.

Recently a coworker lent me the famous book Rework by 37 Signals. Interesting book, a bit sarcastic and pretentious I’d say: many ideas are exposed as the holy truth, like if there was only one way to see things, but some ideas do indeed make sense.

If you don’t know it, that book is about how to manage your schedule at work in order to improve your productivity. Although it’s supposed to be read by entrepreneurs many topics are of general interest. My past experience with YoolinkPro as a startup co-founder also gave me an interesting perspective when I read that book (according to that book we did many mistakes at that time but YoolinkPro is still there and more and more efficient as time goes).

One of the idea in that book that stroke me was that meetings kill productivity, here are the main reasons why:

• Meetings have a very low information/minute rate
• Meetings always diverge from their initial plan
• Meetings are very costy (4 people in a one-hour meeting costs 4 hours to the company)
• Meetings tend to proliferate (a meeting will lead to a new one and so on)

In my daily job I spend lots of time in meetings, so that part of the book caught my attention. I wondered if I could do things better.

So I should try to kill meetings as much as I can, OK, but what is the alternative? If I need to coordinate a team on a technical subject, if I need to discuss a strategic choice for the company? Looks that most of the “Meeting Killers” vote for massive email usage.

I can see the benefit: emails are processed when you want to so you can group that task in different moments in your day rather than being managed by your calendar. But is that an universal solution? What is the issue we try to fix with meetings?

Well, let’s step back a bit: Why do we do meetings?

We do meetings when we need to share information between more than two people. Actually, a meeting is supposed to give an answer to one or more questions that involves these people. Sometimes, a meeting is also schedulded to take a decision.

Can we do that by email?

Despite the book I’d say that it depends, to me the key here is to answer the question: is that question or that decision blocking someone now ? Can’t that wait a day?

Most of the time you’ll see that it actually can wait a day. In this situations, then yes, I agree an email is better than a meeting. The email should be written very clearly though, it should not be too long (long emails are counterproductive) and should clearly expose the question that need to be answered (or the decision to be taken).

In other situations, I think a meeting is still the good way to go, but again, it should be well defined, should not involve more than 4/5 people and should be limited in time (when the ring bells, it’s over, period).

Another interesting idea to balance the whole “Kill the meetings” thing is to choose a time-frame when meetings are forbidden, it may be all the mornings, or for instance a whole day when you will never allow a meeting to be planed. I think I’ll experiment with that, like for instance, the “no meetings thursday”.

Feel free to share your experiences in the comments, I’m interested to see other point of views on the subject.

Related posts:

1. The 10 rules of the pragmatic programmer In my last post I spoke about how meetings can...

It’s been around two years since I use Boxee. When I discovered it, I bought an Acer Revo, and powered Boxee on a freshly installed Ubuntu system.

That was working well and I got a cheap full-featured media-center that way, but there was still a couple of rough edges:

• The thing is a bit noisy
• Flash HD videos were unable to play correctly
• No real remote controller (the iPhone/Android app is great, but well, it’s not as good as a real remote).
• Running a complete Ubuntu system to power a media-center always sounded overkill to me

I was a bit hesitating though: would the Boxee Box be that better than my home-made station? I’ll have the same software afterall, is the hardware they’ve designed with D-Link worth the change?

There was only one way to know it, so, I finally bought the little not-really-square monster, the Boxee Box. Since yesterday, it replaces elegantly my Revo and the small green-smiley-face-logo shines in the dark. Here are my first impressions.

• It’s very small and elegant, you really want it to be visible :) It’s classy
• It’s completely silent, very good point
• The remote changes everything, really
• Flash HD videos play smoothly
• The software is actually not the same, it’s a complete firmware dedicated to the box, and it’s better organized than the opensource version of Boxee (very nice feature: the internal search engine and the UPnP support).

So if you’re looking for the ultimate media-center, stop searching it exists, and is called Boxee Box!

No related posts.

I came accross this interesting article about social networks, the main idea being that taking over Facebook is not the question anymore: OK, Facebook has 800 millions active users, that’s huge.

But the question is no more “how many users you can get into your social network”, it’s more, “why will users come to your social network”.

That’s a very interesting point of view, and I’d say I couldn’t agree more with the idea that at some point, the number of active users is not a value I’d look for, actually it’s the opposite. Did you look recently at your Facebook wall? It’s just an empty room filled with wind and pop-corn.

My Facebook account is undead and whenever I log on to see what’s happening in my “friends” life, all I see is how much their life is exciting. OK, this last one was a bit sarcastic, but frankly, it’s not far from the truth. It’s just, well, boring. Also, don’t take me wrong, I’m not saying I don’t care about my friends life, I’m saying that everything in Facebook contribute to lower the quality of publications.

On the other hand, I make a big use of Twitter and am interested to check out what’s happening in my circles on Google+. Why so? Because the users I’m following there are interesting, they have something to say other than where they spent their holydays, how much they love their dog or whatever they ate at lunch. At the same time, their audience is paying more attention, that changes everything.
It’s a virtuous circle: more expectation from your audience brings better content.

There are less users, more specialized, yes indeed. And that’s why it’s better.

No related posts.

Just to remember the hack (and to share with those who may not be aware of it) here is how to use GMail as a Spam filter.

First, go to your GMail settings and activate a forward to your main email address.

When it’s done, any non-SPAM email that arrives to your GMail account will be forwarded (note that you can keep a copy in GMail, this is a great combo to have a backup of your emails).

Then, back to your email server side, you need to bounce all incoming emails to your GMail account; but we don’t want to create an infinite loop, so we’ll make sure we don’t bounce an email that comes from GMail’s forward (thanks to the X-Forwarded-For header).

# forward to gmail account for spam filtering - cf http://mboffin.com/post.aspx?id=1636
:0
* !X-Forwarded-For: YOURACCOUNT@gmail.com YOU@YOUREMAILSERVER
{
    :0fw
    | formail -IDelivered-To

    :0
    ! YOURACCOUNT@gmail.com
}

And Voila! That’s all you need, now all your emails go through the following flow:

Your mail server -> GMail -> GMail's Spam filter -> Your mail server

No related posts.

I am very glad and proud to announce here that I’ve came up with a prototype of dancer2 that pleases me enough to be advertised.

The source code was hosted on a private Git repo (kudos to Sawyer) but I’ve now decided to push it on GitHub.

dancer2 is a complete rewrite of Dancer aiming at providing the same awesomeness with the following major changes:

• no more globals in the core
• 100% object-oriented backend (based on Moo)
• better scoping for sub-applications
• better design (no more encapsulation violations, Law of Demeter, …)

It’s not finished yet (dancer2 supports 80% of the Dancer’s DSL) but all the core is done. It’s well tested (around 80% of code coverage at this point) and I think the last 20% wont be hard to implement (session and serializer keywords mostly).

It’s able to run simple applications (it can run the PerlDancer.org
website for instance).

Of course, with your real-life applications, chances are that it will break in many places, this is where you can help. I’d like to have as many reports as possible regarding upgrades tests.

You can test very easily your app with dancer2:

  $ git clone http://github.com/PerlDancer/Dancer2.git
  $ cd YOUR_APP
  $ perl -I../dancer2/lib bin/app.pl

Also, important to know: most of the plugins may not be working well.

Here are the next steps:

• Finish the DSL
• Work on plugins backward compat
• Write a “delta” POD (also list the deprecations)
• Write a Dancer::BackwardCompat glue module for easier upgrades

Related posts:

1. About performances I recently focused on Dancer’s core with a single target...
2. Perl Dancer meeting #1 report Here is my quick report of the first Dancer meeting...

If you follow either the Perl Dancer community or the Sinatra one, you may be aware of what happened yesterday: some unknown individual posed as different members of the Sinatra core team on CPAN ratings in order to trash Dancer. The comments posted were rude and clearly intented to harm the project or the people involved with it.

It’s not the first time Dancer is the target of an unknown individual (who always sends his attacks anonymously), we already experienced that whenever a news was posted to HackerNews about Dancer. But this time, the attack was more aggresive, 5 different accounts were created in a row on Bitcard to downgrade the CPAN ratings average of Dancer. Furthermore they used the names of known people in the Sinatra community, in order to make it look even more harmful.

But what was the result of that? Well, it turned out to be one of our most productive and positive marketing action since we launched our advent calendar. Yes. Because our first reaction when this came to our attention was to contact the Sinatra community, in order to check out with them if they were related to that or not.

Tunred out they had clearly nothing to do with this childish attacks, and were even as offended as we were that Sinatra could be associated to such low behaviour. In the end, the result of all this is an official statement from Sinatra saying that “Sinatra loves Dancer“. It has triggered a lot of very positive noise on Twitter for both Sinatra (who clearly appears to be a very classy community) and Dancer who benefits from the huge spotlight Sinatra gave. For this, I thank very gracefully the Sinatra community and more precisely Konstantin Haase.

Back from a CPAN author point of view, I wonder if we couldn’t make the CPAN-ratings system a bit more troll-safe. It is clearly very easy to create a bunch of accounts for poisoning on purpose a distribution. On the other hand, negative ratings should remain possible, otherwise the rating system would be useless (If as a CPAN author I delete all the negative reviews of my distributions, I alter the reality). I understand it’s a tricky design issue to solve, but I think we should spend energy on it.

In our case, we had the chance to be part of a very noisy event, and that helped us to have some of the fake ratings removed, but what would have happened if your distribution had less spotlights? If you don’t have an active community to defend it? If you don’t know who to contact to have some abusing ratings moderated? Then you’re vulnerable to trolls.

Maybe the following points could enhance the ratings system (feel free to comment on them):

• add a “Report abuse” link on the rating items, in order to be able to ask easily for moderation
• downgrade/hide/moderate any ratings that have a very high proportion of negative votes (like 1 of 20).
• prevent multiple accounts creation in a row: if the same IP address creates more than X accounts in the same time window, something suspicious may be happening, maybe we could block that IP for a while, like a day, …
• Another idea is to allow CPAN authors either not to appear on the CPAN-ratings page, or to reset their ratings (all of them)

I’m sure there are lots of other options. Feel free to comment on that. Maybe we could use also some sort of “reputation score” like StackOverflow does in order to enlight the ratings by revelance.

Related posts:

1. Dancer, global thoughts about our philosophy If you follow Perl5 blogs you may have been aware...
2. Dancer 1.150 released I’m happy to announce the release of Dancer 1.150. This...
3. Dancer 1.100 released A new version of Dancer has just been published on...

Chromatic has published a set of questions to identify good Perl programmers. I use it now for every job interview I handle (we want to hire experienced Perl programmers here at Weborama) and am very pleased with the results so far.

I don’t expect applicants to be able to answer every single question, but with this questionaire, I have a very solid base upon which I can build the interview. Moreover, it’s quite impossible for the applicant to bluff, she can try, but she will fail.

After doing this interview a couple of times, I’ve came up with a set of new questions I like to ask, here there are:

• How do you detect the caller’s context in a subroutine?
• What is the difference between die and croak?
• How do you mesure the code coverage of a test suite?
• What’s the difference between eval $foo and eval { $foo }, bonus point if you can show off that difference with a code snippet
• Explain what happens when the line use SomeModule; is executed. Bonus point for telling when it is executed.
• Same question for no SomeModule;
• What’s the difference between (1, 2, 3, 4, 5) and [1, 2, 3, 4, 5]?
• With the following: my $code = sub { 42 } , explain what we get in $code
• Is the following valid Perl 5 code: [foo => 42, bar => 44]? Explain the resulting data structure. Bonus point for giving another syntax for the same structure.
• Do you know a new built-in keyword of Perl 5 added in the 5.10 version?
• How would you match an email in a given string?
• Do you know a way to profile a perl program?
• Do you know how to run a perl program with the debugger?
• How would you transform a list of integers to a list of their power by two?
• What do I have in @list with the following: @list = ('a' .. 'e')
• Can you explain the difference between my $foo = shift; and my ($foo) = @_ ?

Related posts:

1. Perl Dancer meeting #1 As explained on the mailing list, we had the idea...
2. Perl Dancer meeting #1 report Here is my quick report of the first Dancer meeting...
3. Thoughts about an easy-to-use Mocker for Perl Unit-testing is the way to go in modern programing. When...

It’s the first time I’m invited as a guest to a Perl event, it’s really exciting to see how Dancer drives me into new situations!
I already said that I enjoyed seeing Dancer taking its own life, but now, it starts to drive mine! Which is even better ;)

Friday

I’ve landed at the Sofia airport friday afternoon at 4PM. The flight went pretty well, and the landing was very smooth. Apprently “Bulgaria Air” is not famous for that, so I guess I got lucky!

My first impression when I got out of the plane was the freezing air. When I left Paris, it was around 5° (C) and Sofia was around -6° (C). It’s like going back in time, when we had snow in Paris’ streets in december! But it’s a very subjective point of view, because Alexey Kapranov, who came from Moscow told us it was -20° (C) over there!

Marian Marinov came gently to take me at the aiprort and drove me downtown to meet Alexey who had found a free city-tour driven by Vanya, a very enthusisast guide.
We went by walk to see most of the historical buildings of Sofia. Yes, you can actually do that by walk, because the center of the city is not very big and most of the historical places are grouped in the same district.

It’s interesting that this city has “mutable” buildings :) From time to time, churches turn into mosques, and to churches again. A lot of Sofia’s buildings change during time, depending on the political
position of the country. Sometimes it’s destroyed then rebuilt again and so on. It’s like a volatile city! Apparently this is going to change, because bulgarian people want to stop desroying their
buildings, even if there are strong feelings linked to them. “It’s part of our history” said Vanya, “wether it’s bad or good history, it’s still history, hence we should stop destroying buildings“.

I’ve also been surprised to see that France had strong trading connections with Bulgaria in the past. We’ve seen some historical stones with scriptures written in french.
We had dinner in a sweet restaurant in Sofia, and we tried a couple of meals (Chopska Salata!), it was pretty good.

Saturday

The Perl Bulgraia Workshop takes place in the “French Center” of Sofia’s university, which is actually funded by the French embassy.
Actually we are in the french library of the university, it’s funny to be surrounded by french books when you’ve flew 2,500 kilometers to the east ;)

The conference started at 11 AM with Alexey’s talk about HTTP sessions handling. It was interesting because he went through all the details of the HTTP session protocol, explaining what stateless connections are and how cookies were used to provide that missing state in HTTP. Then we’ve seen the famous technique of embeding the whole session in an encrypted cookie; and what pros and cons you have then.

I did my talk about Dancer then, I’ve used the slides I had done for OSDCfr 2010 and refreshed them before. The talk went pretty well, I think. I tried to show off all the main key-features of Dancer and most importantly its spirit. I think I made my point. I was comfortable and felt like being more fluent than the talk I did at FOSDEM. Maybe the practice is helping ;) I should do more talks in english!

My slideshow lasted 30 minutes, so I had another 10 to do some live demos. I had prepared a set of very small working examples for showing off Dancer’s sessions, serializers and logger engines. It was a good way to end the presentation: after 30 minutes of talking, the audience is much more receptive if you break the way things are done.
Moreover, live demo are always more exciting than slides, because, you know, it’s live!

I also had with me two Dancer T-shirts to offer so I proposed to make a small lottery to find out who will win them. “What would be the best way to do that?” I wondered, “well, it has to be powered by Dancer!“.
So here I was writing a silly app during the last talk (I had 30 minutes to build the app, no more!). The app is basically the following:

my @people = (...);
get '/winner' => sub {
    shuffle @people and $people[0];
};
dance;

Of course I also wrapped all that with a nice HTML/CSS layout in order to display the winner’s name in huge characters, with a centered position.

Well that’s it, the beast was alive in time! Then I filled the list with the people registered on the BPW website and we were ready.

It was very funny to do, we may do that as well at the French Perl Workshop, it’s a very funny way to close the event and to show off Dancer’s ease of use. You have an idea, 30 minutes later it’s live.

I really enjoyed this trip to Sofia, and was very happy to be part of the Bulgarian workshop.

So long Sofia, and thanks for the fish!

Related posts:

1. FOSDEM 2011 report So this year I was to FOSDEM, and this was...
2. Perl Dancer meeting #1 report Here is my quick report of the first Dancer meeting...
3. French Perl Workshop 2010 report I’m just back from FPW 2010 and I want to...