Mathieu Agopian

Storing credentials or tokens on the frontend

2019-11-10T16:17:00+01:00

Security is hard. Also, I'm not a security expert, so please take what you read here with a grain of salt, and let me know if there's anything wrong.

That being out of the way: I went down a rabbit hole lately, when someone told me: "we worked hard to store the auth token in cookies for our frontend, because we previously stored it in localStorage, and it's very insecure".

Indeed a search for "localStorage insecure" will return many results.

But then, is storing sensitive data in cookies, like we did in the old days, more secure?

Say you're developing a frontend for some API, or an SPA, and you need to authenticate a user. Let's break things down, and try to understand what are the risks, what are the tools at our disposal as web developers, and what are some of the solutions.

Attacks and vulnerabilities

There are two main ways to attack a website:

CSRF

A Cross Site Request Forgery is a very easy attack that works against cookies: a browser willingly attaches cookies to a request that goes to the associated website.

Say I have a cookie created by https://my.bank.com with my credentials. If I end up being tricked to follow a link to http://bad.com/evil_csrf_fake_form that displays a form looking like the following:

<form action="https://my.bank.com/account/transfer">
    <input type="hidden" name="to" value="evil_attacker" />
    <input type="hidden" name="amount" value="123456" />
    <input type="submit" value="Click here for a chance of winning a free gift!" />
</form>

The browser will happily attach the cookie from https://my.bank.com to the request, from any website or form. The backend, upon receiving the request with the attached valid credentials, will happily transfer the money.

XSS

A Cross Site Scripting attack is usually a bit more elaborate, as it needs to inject some javascript in the rendered page on the attacked website. Once it's done though, it's basically game over for the website, as the attacker will have access to everything the legitimate javascript code has. Including in-memory data, localStorage, cookies without httpOnly.

An attacker could dump the content of the localStorage using a very generic JSON.stringify(localStorage), or target the website specifically and access in-memory data, or forge a fake login form that would look totally legitimate AND be on the legitimate domain.

Storage and persistence of sensitive data

Nowadays you can store sensitive data like username/password, bearer token, jwt token... either in:

Memory

Storing in memory means holding the credentials or token in a variable, a redux state, closures or whatever.

Good: this is not vulnerable to CSRF, and an XSS attack will need to be targetted towards your specific way of storing the data.

Bad: still vulnerable to a targetted XSS attack, and you're not persisting the credentials or token: if the user opens a new tab or restarts their browser, they'll have to re-authenticate.

localStorage or sessionStorage

Both are nearly identical, the first one persists accross tabs and browser restarts.

Good: readable by javascript, very convenient, not vulnerable to CSRF attacks. They are both readable by javascript

Bad: readable in a generic way like JSON.stringify(localStorage) which makes it very easy for an attacker in case of an XSS

Cookies

Cookies can be created as httpOnly, which means the content isn't readable by javascript. It can also be sameSite to defeat CSRF attacks, but beware that this isn't supported by all the browsers yet, and is obviously only available if the frontend is served from the same domain.

Good: the cookie is automatically attached to any request sent by your frontend. Not vulnerable to XSS if httpOnly. Not vulnerable to CSRF if sameSite.

Bad: Vulnerable to CSRF if you can't use sameSite because not supported by all the browsers you target, or the frontend is not on the same domain or you're using an auth solution like auth0 or openID that you don't control.

The problem

Frontend and backend on the same domain

You control the backend, and the frontend is on the same domain. You're thus only vulnerable to XSS (but then again, an XSS is game over). To minimize the risks you might prefer staying away from local or session storage.

the backend stores and reads the session identifier in an httpOnly and sameSite cookie, and you can even add some csrf tokens to the mix
the frontend doesn't have to concern itself with the credentials

If there is an XSS in your frontend, once you fixed it you can remove the open sessions on the backend. Everybody will need to re-authenticate, and the attacker will have lost all privileges. Also make sure they didn't create an admin user in the meantime!

No control over the backend

Also applies if the backend is on another domain. In such a case, you can't use sameSite, and the backend might not support CSRF tokens (eg if it uses stateless authentication).

Let's take a concrete example (using hasura and a JWT token) which happens to be the place where I found out about the perfect solution.

A JWT token is a very sensitive piece of data: as long as it isn't expired it will be accepted. Even if you discovered an XSS on your frontend and fixed it, if the attacker has a victim's JWT token, they'll still be able to use it. There's no easy way to revoke a JWT token (see token invalidation).

So you need to:

store the JWT token somewhere safe (not in localStorage, not in a cookie as we can't make it sameSite and would thus be vulnerable to CSRF attacks)
make it expire very quickly (say 15 minutes)

This means that a user will have to re-authenticate every 15 minutes, and every new tab or browser restart. Which is obviously a pain.

So here comes the refresh token to the rescue!

This refresh token is stored in a httpOnly cookie: whenever the in-memory JWT token is about to expire (or has expired), the frontend can make a request to some /authorize endpoint that will return the new JWT token. The frontend can then store this new short lived token in memory.

It's safe to have this refresh token in a cookie because:

it won't be readable by javascript, so not vulnerable to an XSS attack
if attached to a CSRF request, it'll only refresh the tokens (in memory in the user's browser)

Conclusion

So, do we have the perfect solution with in-memory short lived sensitive data and a refresh token in an httpOnly cookie? Sure, if you're willing (and able) to set it up. It does mean that the auth backend has to support this flow (I believe it's not the case for auth0 as they recommend using silent authentication which still has the limitations of in-memory: no persistence accross tabs/restarts). It does add an extra layer of complexity compared to a simple solution like persisting the session in localStorage. And it's not a silver bullet in case of an XSS.

You might consider that if an XSS is game over, then you might as well use localStorage which is way more convenient. But then, it's not because a dedicated thief can break any lock that you leave your door open when you leave the house, right? It's a matter of mitigation and reducing the attack surface.

If you don't have anything of value in your house, you might choose to close the door, and leave the keys under the welcome mat for convenience. How did you like my analogy of using localStorage? ;)

By the way, if the "XSS is basically game over" sounds scary, know that there are ways to mitigate those, see an interesting article Github CSP journey, and a challenge to learn a bit more about this subject.

Making a pong game in elm (4)

2019-08-12T11:36:00+02:00

Following the three previous blog posts, let's continue taking tiny steps in our endeavour to create a pong game in elm.

Contribution from Rémy

Rémy is a former colleague from Mozilla and is a wonderful, very joyful and productive friend. When he saw this series of blog posts, he contributed a few issues and pull requests to the project, thanks!

The first PR is to fix a corner case where the ball would be "trapped" by the paddle: if the paddle catches the ball "too late" but still before it touches the side, the ball bounces back and forth on each frame. To fix that, the trick is to also check the direction the ball is going, and only bounce if it's going towards the side the paddle is on:

             (ball.x - ball.radius <= x + width)
                 && (ball.y >= y)
                 && (ball.y <= y + height)
+                && (ball.horizSpeed < 0)

         RightPaddle { x, y, height } ->
             (ball.x + ball.radius >= x)
                 && (ball.y >= y)
                 && (ball.y <= y + height)
+                && (ball.horizSpeed > 0)

commit

The second PR is a bit more involved: it's not related to the game itself, but rather to how people can interact and contribute to it.

Adding a few helper scripts is convenient to newcomers, and having a npm run deploy helps with automating the upload to the github pages where the most up to date version is playable.

Now for the issues. The second one is an issue I spotted but didn't get around to fixing yet. Here's how to reproduce it:

one player presses and keeps pressing a key (eg: the down arrow)
as the paddle moves down, the game is restarted (because one of the two players won)
while the game is paused (the 500ms delay), the key is released (eg: the down arrow is released)
once the game is restarted, the paddle moves down on its own, even though the down arrow is released

The reason is pretty obvious: during the pause we're not subscribed to the onKeyUp events so we don't update the PaddleMovement.

There's an easy way to fix that: reset the paddles (position and movement) once the game restarts:

         SleepDone ->
             ( { model
                 | ball = initBall
+                , rightPaddle = RightPaddle <| initPaddle 480
+                , leftPaddle = LeftPaddle <| initPaddle 10
+                , rightPaddleMovement = NotMoving
+                , leftPaddleMovement = NotMoving
                 , gameStatus = NoWinner
               }
             , Cmd.none

commit

Another way would have been to keep being subscribed to the key events even during the pause, but that wouldn't have been sufficient: during the pause we don't subscribe to the animation frame events anymore, and as such our "game loop" is on pause, and we don't update anything anymore. So even though we'd be registering the key presses, the paddles wouldn't be moving, which would be confusing.

So instead of changing the subscription, we'd have to do a case on the GameStatus when updating the ball, and only update it while there's no winner:

                         ball.vertSpeed

                 updatedBall =
-                    { ball
-                        | x = ball.x + horizSpeed
-                        , y = ball.y + vertSpeed
-                        , horizSpeed = horizSpeed
-                        , vertSpeed = vertSpeed
-                    }
+                    case model.gameStatus of
+                        Winner _ ->
+                            ball
+
+                        NoWinner ->
+                            { ball
+                                | x = ball.x + horizSpeed
+                                , y = ball.y + vertSpeed
+                                , horizSpeed = horizSpeed
+                                , vertSpeed = vertSpeed
+                            }

                 updatedRightPaddle =
                     updatePaddle model.rightPaddleMovement model.rightPaddle
@@ -248,10 +253,6 @@ update msg model =
         SleepDone ->
             ( { model
                 | ball = initBall
-                , rightPaddle = RightPaddle <| initPaddle 480
-                , leftPaddle = LeftPaddle <| initPaddle 10
-                , rightPaddleMovement = NotMoving
-                , leftPaddleMovement = NotMoving
                 , gameStatus = NoWinner
               }
             , Cmd.none
@@ -397,16 +398,11 @@ viewScore score =

 subscriptions : Model -> Sub Msg
 subscriptions model =
-    case model.gameStatus of
-        NoWinner ->
-            Sub.batch
-                [ Browser.Events.onAnimationFrameDelta OnAnimationFrame
-                , Browser.Events.onKeyDown (Decode.map KeyDown keyDecoder)
-                , Browser.Events.onKeyUp (Decode.map KeyUp keyDecoder)
-                ]
-
-        Winner _ ->
-            Sub.none
+    Sub.batch
+        [ Browser.Events.onAnimationFrameDelta OnAnimationFrame
+        , Browser.Events.onKeyDown (Decode.map KeyDown keyDecoder)
+        , Browser.Events.onKeyUp (Decode.map KeyUp keyDecoder)
+        ]

commit

So we reverted our change in the SleepDone message (when we restart the game), and we now always subscribe to all the events (animation frame and keys). And finally we only update the ball when it's not on pause after a win.

However we now have a very weird behaviour:

Well... the game loop runs every animation frame (so roughly 60 times per second). And on each frame, even when the game is "paused" (actually, just the ball is paused now) we check if there's a win, and we increase the score, and then start a 500ms delay, but this delay doesn't prevent the score increase on the next frame as there's still a win (the ball hasn't moved).

So let's modify the current case maybeWinner updatedBall to be:

                     updatePaddle model.leftPaddleMovement model.leftPaddle

                 ( gameStatus, score, cmd ) =
-                    case maybeWinner updatedBall of
-                        Nothing ->
-                            ( NoWinner, model.score, Cmd.none )
-
-                        Just player ->
+                    case ( maybeWinner updatedBall, model.gameStatus ) of
+                        ( Just player, NoWinner ) ->
                             let
                                 alwaysSleepDone : a -> Msg
                                 alwaysSleepDone =
@@ -195,6 +192,9 @@ update msg model =
                                     updateScores model.score player
                             in
                             ( Winner player, updatedScore, delayCmd )
+
+                        _ ->
+                            ( model.gameStatus, model.score, Cmd.none )
             in
             ( { model
                 | ball = updatedBall

commit

Here the case is on a 2-tuple, and the only special case that interests us is when we have no winner in the GameStatus yet, but we just detected there's a win. In this case, and only in this case do we increase the score and start a 500ms sleep. In all the other cases (destructured as _ -> here) we just return the unmodified game status, score, and no commands.

That's now working perfectly. However the code is starting to get really unreadable in this game loop... Let's see if we can rewrite and refactor it to make it clearer:

     case msg of
         OnAnimationFrame timeDelta ->
             let
-                ball =
-                    model.ball
-
-                shouldBounce =
-                    shouldBallBounce model.rightPaddle model.ball
-                        || shouldBallBounce model.leftPaddle model.ball
-
-                horizSpeed =
-                    if shouldBounce then
-                        ball.horizSpeed * -1
-
-                    else
-                        ball.horizSpeed
-
-                shouldBounceVertically =
-                    shouldBallBounceVertically model.ball
-
-                vertSpeed =
-                    if shouldBounceVertically then
-                        ball.vertSpeed * -1
-
-                    else
-                        ball.vertSpeed
-
                 updatedBall =
-                    case model.gameStatus of
-                        Winner _ ->
-                            ball
-
-                        NoWinner ->
-                            { ball
-                                | x = ball.x + horizSpeed
-                                , y = ball.y + vertSpeed
-                                , horizSpeed = horizSpeed
-                                , vertSpeed = vertSpeed
-                            }
-
-                updatedRightPaddle =
-                    updatePaddle model.rightPaddleMovement model.rightPaddle
-
-                updatedLeftPaddle =
-                    updatePaddle model.leftPaddleMovement model.leftPaddle
+                    updateBall model

                 ( gameStatus, score, cmd ) =
                     case ( maybeWinner updatedBall, model.gameStatus ) of
@@ -198,8 +158,8 @@ update msg model =
             in
             ( { model
                 | ball = updatedBall
-                , rightPaddle = updatedRightPaddle
-                , leftPaddle = updatedLeftPaddle
+                , rightPaddle = updatePaddle model.rightPaddleMovement model.rightPaddle
+                , leftPaddle = updatePaddle model.leftPaddleMovement model.leftPaddle
                 , gameStatus = gameStatus
                 , score = score
               }
@@ -259,6 +219,50 @@ update msg model =
             )


+updateBall :
+    { a
+        | gameStatus : GameStatus
+        , ball : Ball
+        , rightPaddle : Paddle
+        , leftPaddle : Paddle
+    }
+    -> Ball
+updateBall { gameStatus, ball, rightPaddle, leftPaddle } =
+    let
+        shouldBounce =
+            shouldBallBounce rightPaddle ball
+                || shouldBallBounce leftPaddle ball
+
+        horizSpeed =
+            if shouldBounce then
+                ball.horizSpeed * -1
+
+            else
+                ball.horizSpeed
+
+        shouldBounceVertically =
+            shouldBallBounceVertically ball
+
+        vertSpeed =
+            if shouldBounceVertically then
+                ball.vertSpeed * -1
+
+            else
+                ball.vertSpeed
+    in
+    case gameStatus of
+        Winner _ ->
+            ball
+
+        NoWinner ->
+            { ball
+                | x = ball.x + horizSpeed
+                , y = ball.y + vertSpeed
+                , horizSpeed = horizSpeed
+                , vertSpeed = vertSpeed
+            }
+
+
 updatePaddle : PaddleMovement -> Paddle -> Paddle
 updatePaddle movement paddle =
     let

commit

That's a big one! It looks impressive, but most of it is just moving the code related to updating the ball (checking if it bounces to update its speed and moving it) to its own updateBall helper.

However there's something worth noting here, and it's in the signature of the updateBall:

updateBall :
    { a
        | gameStatus : GameStatus
        , ball : Ball
        , rightPaddle : Paddle
        , leftPaddle : Paddle
    }
    -> Ball
updateBall { gameStatus, ball, rightPaddle, leftPaddle } =

Up til now we've seen how to write a type signature with various types, but this is the first time we're seeing this { a | ...} notation. This is an extensible record (more information in this "Advanced Types in Elm - Extensible Records" blog post by Charlie Koster and the "Scaling elm apps" talk by Richard Feldman).

To sum it up, it's a way to

document which fields are of interest to the function
narrow the arguments to the function: it'll only take, use or return specific fields from the records
make a function usable on several different types of records, as long as they have the fields defined in the extensible record

In our case we're only using this for the first two use cases.

We're now left with this game status and score update. Those two should obviously happen together, but it feels a bit alien to have them mixed in the game loop together with the updating of the paddles.

How awesome would it be to have a NewWinner Player message? If we had it, we could update the game status and the score update in this case of the update function, and it would make perfect sense!

"But Mathieu, how do we send our own messages to the update function? Aren't messages usually coming from subscriptions, or maybe events like onClick on a button and the like? We've always had those messages handed to us by the elm runtime through the update function!".

Well, yes, usually the messages are provided, relayed by the elm runtime. And we could tell the runtime to send us such a message, but as you can read from this piece, it's not recommended (check "How to turn a Msg into a Cmd in Elm?" from Wouter In t Velt for more information on why).

But if we get back to the original question: how do we send our own messages to the update function?

Well, the update function is just that: a function. And a function can be called, for example with our own NewWinner Player message, and the updated model we get in the "game loop":

@@ -63,6 +63,7 @@ type Msg
     | KeyDown PlayerAction
     | KeyUp PlayerAction
     | SleepDone
+    | NewWinner Player


 type PlayerAction
@@ -136,34 +137,32 @@ update msg model =
                 updatedBall =
                     updateBall model

-                ( gameStatus, score, cmd ) =
-                    case ( maybeWinner updatedBall, model.gameStatus ) of
-                        ( Just player, NoWinner ) ->
-                            let
-                                alwaysSleepDone : a -> Msg
-                                alwaysSleepDone =
-                                    always SleepDone
-
-                                delayCmd =
-                                    Process.sleep 500
-                                        |> Task.perform alwaysSleepDone
-
-                                updatedScore =
-                                    updateScores model.score player
-                            in
-                            ( Winner player, updatedScore, delayCmd )
-
-                        _ ->
-                            ( model.gameStatus, model.score, Cmd.none )
+                updatedModel =
+                    { model
+                        | ball = updatedBall
+                        , rightPaddle = updatePaddle model.rightPaddleMovement model.rightPaddle
+                        , leftPaddle = updatePaddle model.leftPaddleMovement model.leftPaddle
+                    }
             in
-            ( { model
-                | ball = updatedBall
-                , rightPaddle = updatePaddle model.rightPaddleMovement model.rightPaddle
-                , leftPaddle = updatePaddle model.leftPaddleMovement model.leftPaddle
-                , gameStatus = gameStatus
-                , score = score
-              }
-            , cmd
+            case ( maybeWinner updatedBall, model.gameStatus ) of
+                ( Just player, NoWinner ) ->
+                    update (NewWinner player) updatedModel
+
+                _ ->
+                    ( updatedModel, Cmd.none )
+
+        NewWinner player ->
+            let
+                alwaysSleepDone : a -> Msg
+                alwaysSleepDone =
+                    always SleepDone
+
+                updatedScore =
+                    updateScores model.score player
+            in
+            ( { model | gameStatus = Winner player, score = updatedScore }
+            , Process.sleep 500
+                |> Task.perform alwaysSleepDone
             )

         KeyDown playerAction ->

commit

What we did here is:

in the game loop, update the ball and the paddles
make an updated model with those updates
if there's no new winner, return that updated model
if there's a new winner, return the result of a call to the update function with our NewWinner Player message and the updated model

While we're rewriting and refactoring parts of the update function, let's rename this SleepDone message which isn't very meaningful to RestartGame instead:

     = OnAnimationFrame Float
     | KeyDown PlayerAction
     | KeyUp PlayerAction
-    | SleepDone
+    | RestartGame
     | NewWinner Player


@@ -153,16 +153,16 @@ update msg model =

         NewWinner player ->
             let
-                alwaysSleepDone : a -> Msg
-                alwaysSleepDone =
-                    always SleepDone
+                alwaysRestartGame : a -> Msg
+                alwaysRestartGame =
+                    always RestartGame

                 updatedScore =
                     updateScores model.score player
             in
             ( { model | gameStatus = Winner player, score = updatedScore }
             , Process.sleep 500
-                |> Task.perform alwaysSleepDone
+                |> Task.perform alwaysRestartGame
             )

         KeyDown playerAction ->
@@ -209,7 +209,7 @@ update msg model =
                     , Cmd.none
                     )

-        SleepDone ->
+        RestartGame ->
             ( { model
                 | ball = initBall
                 , gameStatus = NoWinner

commit

Source code up to this point.

We're now in a much better place!

Non linear paddles

If we look back at the original gameplay we see that the ball doesn't bounce linearily on the paddles. Depending on where it touches the paddle, the bounce angle varies. This is better explained in this tutorial on writing a pong game in unity.

Let's implement that!

When we update the horizSpeed when the ball shouldBounce, we now also need to update the vertSpeed according to the place where the ball hit the paddle.

The idea is to come up with a "distance" in signed percentage from the center of the paddle, so we would have -100% for a hit right on the top of the paddle, and 100% if it's the bottom of the paddle.

Once we have this percentage, we can divide it by 10 to have a vertical speed between 0 (the ball hits the paddle right in the center) and 10 (the ball hits the top or the bottom of the paddle).

Here's the modified updateBall function:

 updateBall { gameStatus, ball, rightPaddle, leftPaddle } =
     let
-        shouldBounce =
-            shouldBallBounce rightPaddle ball
-                || shouldBallBounce leftPaddle ball
+        maybeRightDistance =
+            maybeBounceDistanceFromCenter rightPaddle ball

-        horizSpeed =
-            if shouldBounce then
-                ball.horizSpeed * -1
+        maybeLeftDistance =
+            maybeBounceDistanceFromCenter leftPaddle ball
+
+        maybeDistance =
+            -- Combine the two maybes and keep the one that isn't Nothing, if any.
+            if maybeRightDistance == Nothing then
+                maybeLeftDistance

             else
-                ball.horizSpeed
+                maybeRightDistance
+
+        ( horizSpeed, bouncedVertSpeed ) =
+            case maybeDistance of
+                Nothing ->
+                    -- No bounce
+                    ( ball.horizSpeed, ball.vertSpeed )
+
+                Just distance ->
+                    ( ball.horizSpeed * -1
+                    , distance // 10
+                    )

         shouldBounceVertically =
             shouldBallBounceVertically ball

         vertSpeed =
             if shouldBounceVertically then
-                ball.vertSpeed * -1
+                bouncedVertSpeed * -1

             else
-                ball.vertSpeed
+                bouncedVertSpeed
     in
     case gameStatus of
         Winner _ ->

Nothing fancy here appart from the maybeDistance: we "combine" both Maybes by keeping the first one that isn't a Nothing if any. This way we simplify the case maybeDistance and we don't have to duplicate the code that updates the horizSpeed and vertSpeed if there's a hit on the left or right paddle.

Now for the hairy maybeBounceDistanceFromCenter:

-shouldBallBounce : Paddle -> Ball -> Bool
-shouldBallBounce paddle ball =
+maybeBounceDistanceFromCenter : Paddle -> Ball -> Maybe Int
+maybeBounceDistanceFromCenter paddle ball =
+    -- If the ball bounces, return Just the distance from the paddle center in
+    -- percentage, so -100% if it's the very top of the paddle, 100% if it's
+    -- the very bottom of the paddle.
+    let
+        normalize : Int -> Int -> Int
+        normalize distance height =
+            (distance - (height // 2)) * 100 // (height // 2)
+    in
     case paddle of
         LeftPaddle { x, y, width, height } ->
-            (ball.x - ball.radius <= x + width)
-                && (ball.y >= y)
-                && (ball.y <= y + height)
-                && (ball.horizSpeed < 0)
+            if
+                (ball.x - ball.radius <= x + width)
+                    && (ball.y >= y)
+                    && (ball.y <= y + height)
+                    && (ball.horizSpeed < 0)
+            then
+                Just <| normalize (ball.y - y) height
+
+            else
+                Nothing

         RightPaddle { x, y, height } ->
-            (ball.x + ball.radius >= x)
-                && (ball.y >= y)
-                && (ball.y <= y + height)
-                && (ball.horizSpeed > 0)
+            if
+                (ball.x + ball.radius >= x)
+                    && (ball.y >= y)
+                    && (ball.y <= y + height)
+                    && (ball.horizSpeed > 0)
+            then
+                Just <| normalize (ball.y - y) height
+
+            else
+                Nothing

commit

Phew, that was a tough one, but we did it!

Cosmetic changes

Well, it seems we're nearly done! By looking at the original pong we can see there's a couple of obvious differences still: the ball should be square (which will make this issue disappear), and there's a dotted line in the center of the screen.

@@ -23,7 +23,7 @@ type alias Model =
 type alias Ball =
     { x : Int
     , y : Int
-    , radius : Int
+    , size : Int
     , horizSpeed : Int
     , vertSpeed : Int
     }
@@ -104,7 +104,7 @@ initBall : Ball
 initBall =
     { x = 250
     , y = 250
-    , radius = 10
+    , size = 10
     , horizSpeed = 4
     , vertSpeed = 2
     }
@@ -321,7 +321,7 @@ maybeBounceDistanceFromCenter paddle ball =
     case paddle of
         LeftPaddle { x, y, width, height } ->
             if
-                (ball.x - ball.radius <= x + width)
+                (ball.x <= x + width)
                     && (ball.y >= y)
                     && (ball.y <= y + height)
                     && (ball.horizSpeed < 0)
@@ -333,7 +333,7 @@ maybeBounceDistanceFromCenter paddle ball =

         RightPaddle { x, y, height } ->
             if
-                (ball.x + ball.radius >= x)
+                (ball.x + ball.size >= x)
                     && (ball.y >= y)
                     && (ball.y <= y + height)
                     && (ball.horizSpeed > 0)
@@ -347,18 +347,18 @@ maybeBounceDistanceFromCenter paddle ball =
 shouldBallBounceVertically : Ball -> Bool
 shouldBallBounceVertically ball =
     let
-        radius =
-            ball.radius
+        size =
+            ball.size
     in
-    ball.y <= radius || ball.y >= (500 - radius)
+    ball.y <= size || ball.y >= (500 - size)


 maybeWinner : Ball -> Maybe Player
 maybeWinner ball =
-    if ball.x <= ball.radius then
+    if ball.x <= ball.size then
         Just RightPlayer

-    else if ball.x >= (500 - ball.radius) then
+    else if ball.x >= (500 - ball.size) then
         Just LeftPlayer

     else
@@ -391,11 +391,12 @@ view { ball, rightPaddle, leftPaddle, score } =


 viewBall : Ball -> Svg.Svg Msg
-viewBall { x, y, radius } =
-    circle
-        [ cx <| String.fromInt x
-        , cy <| String.fromInt y
-        , r <| String.fromInt radius
+viewBall ball =
+    rect
+        [ x <| String.fromInt ball.x
+        , y <| String.fromInt ball.y
+        , width <| String.fromInt ball.size
+        , height <| String.fromInt ball.size
         ]
         []

commit

We renamed the radius field of the Ball record to be size instead which makes more sense for a square ball, and updated the viewBall helper to draw a rect instead of a circle. We also took the opportunity to fix a small bug, did you spot it?

Yes, we were checking for ball.x - ball.radius for the left paddle... which meant we were bouncing the ball from the left paddle 10 pixels too early.

And for the screen divider:

@@ -383,13 +383,28 @@ view { ball, rightPaddle, leftPaddle, score } =
         , viewBox "0 0 500 500"
         , Svg.Attributes.style "background: #efefef"
         ]
-        [ viewBall ball
+        [ viewDivider
+        , viewBall ball
         , viewPaddle rightPaddle
         , viewPaddle leftPaddle
         , viewScore score
         ]


+viewDivider : Svg.Svg Msg
+viewDivider =
+    line
+        [ x1 "249"
+        , y1 "0"
+        , x2 "249"
+        , y2 "500"
+        , stroke "black"
+        , strokeDasharray "4"
+        , strokeWidth "2"
+        ]
+        []
+
+
 viewBall : Ball -> Svg.Svg Msg
 viewBall ball =
     rect

commit

And a final touch: let's move the scores closer to their edges:

@@ -442,9 +442,9 @@ viewScore score =
         [ fontSize "100px"
         , fontFamily "monospace"
         ]
-        [ text_ [ x "100", y "100", textAnchor "start" ]
+        [ text_ [ x "50", y "100", textAnchor "start" ]
             [ text <| String.fromInt score.leftPlayerScore ]
-        , text_ [ x "400", y "100", textAnchor "end" ]
+        , text_ [ x "450", y "100", textAnchor "end" ]
             [ text <| String.fromInt score.rightPlayerScore ]
         ]

commit

Source code up to this point.

And now we have it:

Randomizing the game restart

Whenever the game (re)starts the ball always has the exact same direction. It would be nice to have some sort of randomization: in the original gameplay, it seems that the ball is aimed at the last loser, and the starting height and direction are random.

So let's use the elm/random package! It should be very straightforward, just calling the equivalent of Math.random in javascript right? Wrong.

I know what you're thinking: "this elm thing is such a downer, always in my way, always restricting what I can and can't do and all that crap!". And I feel you. However let's not lose track of the upsides. Every programming language that I know of is a compromise between upsides and downsides.

Sure, the pure functional part of elm can be a pain (wait, no side effects? How are people meant to achieve anything without side effects? In elm the side effects only happen in the elm runtime), but it's also the best part in my humble opinion. Not having to worry about hidden side effects is a blessing.

So anyway, back to the point: getting a random number without an initial seed is impure (every time you call Math.random() you have a different result). And in elm everything is pure. "Pure" meaning that a function call with the same arguments will always return the exact same result. Which means there's no side effects.

With a seed though, it's entirely different: a random number generator will always give the same result for a given seed, so it's pure.

So we have two ways to get a random number in elm

send a Cmd Msg to the elm runtime, and "receive" it through a Msg
query a number directly by providing a seed

Let's try the first one, and see how it goes:

 import Browser.Events
 import Json.Decode as Decode
 import Process
+import Random
 import Svg exposing (..)
 import Svg.Attributes exposing (..)
 import Task
@@ -64,6 +65,7 @@ type Msg
     | KeyUp PlayerAction
     | RestartGame
     | NewWinner Player
+    | NewDirection Int


 type PlayerAction
@@ -159,12 +161,25 @@ update msg model =

                 updatedScore =
                     updateScores model.score player
+
+                sleepCmd =
+                    Process.sleep 500
+                        |> Task.perform alwaysRestartGame
             in
             ( { model | gameStatus = Winner player, score = updatedScore }
-            , Process.sleep 500
-                |> Task.perform alwaysRestartGame
+            , Cmd.batch
+                [ sleepCmd
+                , Random.generate NewDirection (Random.int 0 100)
+                ]
             )

+        NewDirection direction ->
+            let
+                _ =
+                    Debug.log "New random direction" direction
+            in
+            ( model, Cmd.none )
+
         KeyDown playerAction ->
             case playerAction of
                 RightPaddleUp ->

Also let's not forget to install the Random package:

$ elm install elm/random

Which results in this modification in the elm.json file:

             "elm/core": "1.0.2",
             "elm/html": "1.0.0",
             "elm/json": "1.1.3",
+            "elm/random": "1.0.0",
             "elm/svg": "1.0.1"
         },
         "indirect": {

commit

This works like a charm, we do have random directions in the console output:

The code is pretty straightforward and easy to understand, but wait a minute: when will we use this random number? I mean, it would be a pity if the sleep was expired already, and the game restarted, before we get the new direction.

The easy way to "synchronize" this is to first query the new random direction, and then when dealing with the reception of that random number, start the sleep. This way we're sure it's done in the right order. It does mean we'll have two messages that are tied together, linked, which feels a bit artifical, awkward, even though it's doable and wouldn't be that bad.

Still, let's try the other solution, just to see what it looks like. We'll use Random.step which needs a Seed. But the only way we can create a Seed is with Random.initialSeed which takes... a number.

Ok, but where does this number come from? Let's deal with that later, and use a perfectly fine number for now: 42

@@ -65,7 +65,6 @@ type Msg
     | KeyUp PlayerAction
     | RestartGame
     | NewWinner Player
-    | NewDirection Int


 type PlayerAction
@@ -165,21 +164,16 @@ update msg model =
                 sleepCmd =
                     Process.sleep 500
                         |> Task.perform alwaysRestartGame
+
+                ( randomDirection, _ ) =
+                    Random.initialSeed 42
+                        |> Random.step (Random.int 0 100)
+                        |> Debug.log "Random direction: "
             in
             ( { model | gameStatus = Winner player, score = updatedScore }
-            , Cmd.batch
-                [ sleepCmd
-                , Random.generate NewDirection (Random.int 0 100)
-                ]
+            , sleepCmd
             )

-        NewDirection direction ->
-            let
-                _ =
-                    Debug.log "New random direction" direction
-            in
-            ( model, Cmd.none )
-
         KeyDown playerAction ->
             case playerAction of
                 RightPaddleUp ->

commit

And we now have the following console logs:

So far, we don't have any randomness in the numbers we're getting... but that's expected, because we're always using the same exact Seed based on the same exact number: 42.

The cool thing with Random.step is that it gives you a new seed together with the random number you asked. So if we could store this new seed in the model and use that on the next call, we'd have a series of different random number:

@@ -18,6 +18,7 @@ type alias Model =
     , leftPaddleMovement : PaddleMovement
     , gameStatus : GameStatus
     , score : Score
+    , seed : Random.Seed
     }


@@ -96,6 +97,7 @@ init _ =
             { rightPlayerScore = 0
             , leftPlayerScore = 0
             }
+      , seed = Random.initialSeed 42
       }
     , Cmd.none
     )
@@ -165,12 +167,16 @@ update msg model =
                     Process.sleep 500
                         |> Task.perform alwaysRestartGame

-                ( randomDirection, _ ) =
-                    Random.initialSeed 42
+                ( randomDirection, newSeed ) =
+                    model.seed
                         |> Random.step (Random.int 0 100)
                         |> Debug.log "Random direction: "
             in
-            ( { model | gameStatus = Winner player, score = updatedScore }
+            ( { model
+                | gameStatus = Winner player
+                , score = updatedScore
+                , seed = newSeed
+              }
             , sleepCmd
             )

commit

"But Mathieu, that's not really random, we're always using the same seed to initialize the generator, so we'll always have the exact same number sequence whenever we reload the page!". That's true. We're using a fixed seed whenever we start the game so this means players could theoretically remembers the sequence.

This could be fixed using several techniques:

Use Random.generate the first time to initialize the seed when the game start
Use the timestamp of the current time when the program starts
Use a randomly generated number that was passed to the elm program

The first two solutions are basically the same: in the init send a command to get a random number or the current timestamp, store that in the model as the seed, and use that from then on. They also both have kind of the same problem as we saw previously: there's some synchronisation issue. What happens if the first game restart happens before we got the random number or timestamp back from the elm runtime? This is obviously very unlikely, especially in our use case. And we could also decide that it's not a big deal, and use that.

But as we're going through a series of blog posts that are dedicated to learning elm, let's take this opportunity to talk about the third solution: it's based on the javascript interop, and specifically the flags in our case.

Using flags

Flags are a way to pass initial data from javascript to the elm program. This would be a perfect tool for our use case: Call Math.random() in javascript, then pass that initial seed to the elm program on startup. And from then on use this seed to get new random numbers (and new seeds, and so on).

But before we can use flags, we need a bit of setup. Up til now we used an automatically generated index.html file containing the inline javascript code compiled from our elm code. But this means we can't modify the initialization code as it would be overwritten each and every time we could compile again.

So we need to generate an index.html file that imports the generated javascript, and a piece of javascript code that initializes the elm program.

Let's base our new index.html file on the example from the interop documentation:

<!DOCTYPE HTML>
<html>
<head>
  <meta charset="UTF-8">
  <title>Elm pong</title>
  <script src="app.js"></script>
</head>

<body>
  <div id="elm"></div>
  <script>
  var app = Elm.Main.init({
    node: document.getElementById('elm')
  });
  </script>
</body>
</html>

We also need to change the scripts entries in the package.json file. You'll see all of that in the commit.

We can now change the initialization script so it passes flags to elm.

Tiny step: let's first pass the number 42 from the javascript side:

The index.html file:

   <div id="elm"></div>
   <script>
   var app = Elm.Main.init({
-    node: document.getElementById('elm')
+    node: document.getElementById('elm'),
+    flags: 42
   });
   </script>
 </body>

And the src/Main.elm file:

@@ -82,11 +82,11 @@ type alias Score =


 type alias Flags =
-    ()
+    Int


 init : Flags -> ( Model, Cmd Msg )
-init _ =
+init seed =
     ( { ball = initBall
       , rightPaddle = RightPaddle <| initPaddle 480
       , leftPaddle = LeftPaddle <| initPaddle 10
@@ -97,7 +97,7 @@ init _ =
             { rightPlayerScore = 0
             , leftPlayerScore = 0
             }
-      , seed = Random.initialSeed 42
+      , seed = Random.initialSeed seed
       }
     , Cmd.none
     )

commit

What that says is we now care very much about the Flags passed to the init function, as we're using it to initialize our seed. So the Flags type isn't the unit anymore (remember, the type that we usually use in place of values we don't care about), but an Int to hold our seed. It could be a Record, a String, a Bool, a JSON value or any other of the base types in elm.

Next tiny step: generate a proper random number on the javascript side, and pass it to our elm program instead of the number 42.

Our index.html file should be modified this way:

 <body>
   <div id="elm"></div>
   <script>
+  let seed = Math.random() * 100; // A random number between 0 and 100.
   var app = Elm.Main.init({
     node: document.getElementById('elm'),
-    flags: 42
+    flags: Math.round(seed)
   });
   </script>
 </body>

commit

We need to Math.round() the result as otherwise it would be a float and not an integer.

And now, every time we refresh the page, we can see that the sequence of random numbers is different! We did it!

By the way if we write elm in the first place, it's to write as little javascript as possible. So maybe we should change the javascript to simply pass the raw random number which is a float between 0 and 1, and deal with the rest on the elm side?

Simplify the index.html:

 <body>
   <div id="elm"></div>
   <script>
-  let seed = Math.random() * 100; // A random number between 0 and 100.
+  let seed = Math.random();
   var app = Elm.Main.init({
     node: document.getElementById('elm'),
-    flags: Math.round(seed)
+    flags: seed
   });
   </script>

And the src/Main.elm file:

 type alias Flags =
-    Int
+    Float


 init : Flags -> ( Model, Cmd Msg )
@@ -97,7 +97,13 @@ init seed =
             { rightPlayerScore = 0
             , leftPlayerScore = 0
             }
-      , seed = Random.initialSeed seed
+      , seed =
+            -- A number between 0 and 100
+            seed
+                |> (*) 100
+                |> round
+                |> Random.initialSeed
       }
     , Cmd.none
     )

commit

Keep in mind that here we convert the float between 0 to 1 to an integer between 0 to 100. We could do whatever we want here, for example convert it to be between 0 and 10000 to have more seeds. Or we could ditch Math.random() entirely and use the current timestamp.

So anyway, now that we have our seed, what kind of random numbers are we going to generate, and for what usage? Well, in the updateBall helper we decided that the vertical speed was going to be between -10 and +10. So let's initialize our ball vertSpeed this way:

+randomVertSpeed : Random.Seed -> ( Int, Random.Seed )
+randomVertSpeed seed =
+    Random.step (Random.int -10 10) seed
+
+
 init : Flags -> ( Model, Cmd Msg )
 init seed =
-    ( { ball = initBall
+    let
+        initialSeed =
+            -- A number between 0 and 100
+            seed
+                |> (*) 100
+                |> round
+                |> Random.initialSeed
+
+        ( initialVertSpeed, newSeed ) =
+            randomVertSpeed initialSeed
+
+        initialBall =
+            { initBall | vertSpeed = initialVertSpeed }
+    in
+    ( { ball = initialBall
       , rightPaddle = RightPaddle <| initPaddle 480
       , leftPaddle = LeftPaddle <| initPaddle 10
       , rightPaddleMovement = NotMoving
@@ -97,12 +116,7 @@ init seed =
             { rightPlayerScore = 0
             , leftPlayerScore = 0
             }
-      , seed =
-            -- A number between -100 and 100
-            seed
-                |> (*) 100
-                |> round
-                |> Random.initialSeed
+      , seed = newSeed
       }
     , Cmd.none
     )

commit

So we created a small randomVertSpeed helper, and using the initial seed we compute from the javascript value, we set the initial ball's vertSpeed.

And now we want to also use a random vertical seed on each game restart:

@@ -185,16 +185,10 @@ update msg model =
                 sleepCmd =
                     Process.sleep 500
                         |> Task.perform alwaysRestartGame
-
-                ( randomDirection, newSeed ) =
-                    model.seed
-                        |> Random.step (Random.int 0 100)
-                        |> Debug.log "Random direction: "
             in
             ( { model
                 | gameStatus = Winner player
                 , score = updatedScore
-                , seed = newSeed
               }
             , sleepCmd
             )
@@ -244,9 +238,17 @@ update msg model =
                     )

         RestartGame ->
+            let
+                ( vertSpeed, newSeed ) =
+                    randomVertSpeed model.seed
+
+                ball =
+                    { initBall | vertSpeed = vertSpeed }
+            in
             ( { model
-                | ball = initBall
+                | ball = ball
                 , gameStatus = NoWinner
+                , seed = newSeed
               }
             , Cmd.none
             )

commit

We moved the new vertical speed generation and the seed updating code to the RestartGame were we also initialized the ball.

This is coming alone just perfectly!

Maybe a last addition: let's shoot the ball towards the last loser

                 ( vertSpeed, newSeed ) =
                     randomVertSpeed model.seed

+                horizSpeedDirection =
+                    -- This number is either 1 if the loser is the right
+                    -- player, or -1 if it's the left player who lost last.
+                    case model.gameStatus of
+                        Winner RightPlayer ->
+                            -1
+
+                        _ ->
+                            -- Here we are returning 1 if it's the LeftPlayer,
+                            -- and at the same time dealing with the `NoWinner`
+                            -- case which shouldn't happen.
+                            1
+
                 ball =
-                    { initBall | vertSpeed = vertSpeed }
+                    { initBall
+                        | vertSpeed = vertSpeed
+                        , horizSpeed = initBall.horizSpeed * horizSpeedDirection
+                    }
             in
             ( { model
                 | ball = ball

commit

Source code up to this point.

And we have now completed our game, and this series of blog posts!

If you've followed along during those four episodes, thanks for your patience! I hope that those have been useful to you, and feel free to reach out via email, twitter or on the elm slack.

Making a pong game in elm (3)

2019-08-06T14:03:00+02:00

Following the two previous blog posts, let's continue taking tiny steps in our endeavour to create a pong game in elm.

We left off with a ball bouncing off two paddles, and two players able to move their paddles. And the realization that we were a long way off to have a game that is at least mildly enjoyable.

Moving paddles at the same time

For starters, only one player at a time could move their paddle. And this is because we only moved the paddle when we would detect a onKeyDown. Which meant that we depended on a continuous stream of those events to continuously move the paddle when a player would keep pressing the key.

But we saw in the previous post that when a player would press a key and hold it, the events for this key would stop as soon as another key is pressed (eg if the second player wanted to move their paddle).

After some digging around on the internet it seems that the proper way to deal with that issue is to keep track of which key has been pressed (by tracking the onKeyDown events), and then update the state of this key when an onKeyUp is received.

One way to do that would be to store the pressed keys in a list, and then remove a key from the list once we detect that it's released. Another way would be track the key states in a dictionnary:

type KeyState
    = Pressed
    | NotPressed

type alias keyStates =
    { arrowUp : KeyState
    , arrowDown : KeyState
    , charE : KeyState
    , charD : KeyState
    }

Thinking about that a bit more: what if we have the following keyState:

    { arrowUp = Pressed
    , arrowDown = Pressed
    ...
    }

This would mean that we have two keys pressed for the same paddle, how would we decide what to do with that? Maybe we could have some kind of clever algorithm that would update that dictionnary...

If you're like me, you try to stay away from any clever code. As stated by Brian Kernighan

Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?

— The Elements of Programming Style, 2nd edition, chapter 2

Maybe we could come up with some other representation of the state. How about storing the state of the paddles movement?

type PaddleMovement
    = MovingUp
    | MovingDown
    | NotMoving

This way, whenever we get an onKeyDown for a key, we would update the paddle movement: pressing down would result in MovingDown, and then pressing up (even if we're still pressing down) would update the movement to MovingUp, and any onKeyUp would reset the state to NotMoving.

     { ball : Ball
     , rightPaddle : Paddle
     , leftPaddle : Paddle
+    , rightPaddleMovement : PaddleMovement
+    , leftPaddleMovement : PaddleMovement
     }


@@ -35,6 +37,12 @@ type alias PaddleInfo =
     }


+type PaddleMovement
+    = MovingUp
+    | MovingDown
+    | NotMoving
+
+
 type Msg
     = OnAnimationFrame Float
     | KeyDown PlayerAction
@@ -56,6 +64,8 @@ init _ =
     ( { ball = initBall
       , rightPaddle = RightPaddle <| initPaddle 480
       , leftPaddle = LeftPaddle <| initPaddle 10
+      , rightPaddleMovement = NotMoving
+      , leftPaddleMovement = NotMoving
       }
     , Cmd.none
     )

commit

Now we need to update the state in the update function, in the KeyDown playerAction case:

         KeyDown playerAction ->
             case playerAction of
                 RightPaddleUp ->
-                    ( { model | rightPaddle = model.rightPaddle |> updatePaddle -10 }
+                    ( { model | rightPaddleMovement = MovingUp }
                     , Cmd.none
                     )

                 RightPaddleDown ->
-                    ( { model | rightPaddle = model.rightPaddle |> updatePaddle 10 }
+                    ( { model | rightPaddleMovement = MovingDown }
                     , Cmd.none
                     )

                 LeftPaddleUp ->
-                    ( { model | leftPaddle = model.leftPaddle |> updatePaddle -10 }
+                    ( { model | leftPaddleMovement = MovingUp }
                     , Cmd.none
                     )

                 LeftPaddleDown ->
-                    ( { model | leftPaddle = model.leftPaddle |> updatePaddle 10 }
+                    ( { model | leftPaddleMovement = MovingDown }
                     , Cmd.none
                     )

commit

We're updating the paddle movements, or directions... but we aren't actually moving them. We used to add or substract a number of pixels from their y coordinates directly on the KeyDown playerAction message, but it's not the case anymore.

Updating the movements, reacting to player inputs, updating the world and all that is usually done in a "game loop". The closer we have to a game loop in our program is the onAnimationFrameDelta message. So we'll first update our helper function updatePaddle to take a PaddleMovement instead of an amount:

-updatePaddle : Int -> Paddle -> Paddle
-updatePaddle amount paddle =
+updatePaddle : PaddleMovement -> Paddle -> Paddle
+updatePaddle movement paddle =
+    let
+        amount =
+            case movement of
+                MovingUp ->
+                    -10
+
+                MovingDown ->
+                    10
+
+                NotMoving ->
+                    0
+    in
     case paddle of
         RightPaddle paddleInfo ->
             { paddleInfo | y = paddleInfo.y + amount }

And we can now use that in the update function:

                         | x = ball.x + horizSpeed
                         , horizSpeed = horizSpeed
                     }
+
+                updatedRightPaddle =
+                    updatePaddle model.rightPaddleMovement model.rightPaddle
+
+                updatedLeftPaddle =
+                    updatePaddle model.leftPaddleMovement model.leftPaddle
             in
-            ( { model | ball = updatedBall }, Cmd.none )
+            ( { model
+                | ball = updatedBall
+                , rightPaddle = updatedRightPaddle
+                , leftPaddle = updatedLeftPaddle
+              }
+            , Cmd.none
+            )

         KeyDown playerAction ->
             case playerAction of

commit

And we're now done, both paddles can move at the same time!

What is it that you're saying? That I forgot to manage the case when there's no player action anymore? Of course I didn't, I just wanted to make sure you were still following along. And you were, well done. I never doubted you.

We now need to also subscribe to the onKeyUp events for the keys we're using for the player actions, which means adding

a KeyUp PlayerAction variant to the Msg type
a case to the update function to deal with this new message
a new subscription to the Browser.Events.onKeyUp events

 type Msg
     = OnAnimationFrame Float
     | KeyDown PlayerAction
+    | KeyUp PlayerAction


 type PlayerAction
@@ -160,6 +161,28 @@ update msg model =
                     , Cmd.none
                     )

+        KeyUp playerAction ->
+            case playerAction of
+                RightPaddleUp ->
+                    ( { model | rightPaddleMovement = NotMoving }
+                    , Cmd.none
+                    )
+
+                RightPaddleDown ->
+                    ( { model | rightPaddleMovement = NotMoving }
+                    , Cmd.none
+                    )
+
+                LeftPaddleUp ->
+                    ( { model | leftPaddleMovement = NotMoving }
+                    , Cmd.none
+                    )
+
+                LeftPaddleDown ->
+                    ( { model | leftPaddleMovement = NotMoving }
+                    , Cmd.none
+                    )
+

 updatePaddle : PaddleMovement -> Paddle -> Paddle
 updatePaddle movement paddle =
@@ -248,6 +271,7 @@ subscriptions _ =
     Sub.batch
         [ Browser.Events.onAnimationFrameDelta OnAnimationFrame
         , Browser.Events.onKeyDown (Decode.map KeyDown keyDecoder)
+        , Browser.Events.onKeyUp (Decode.map KeyUp keyDecoder)
         ]

commit

Source code up to this point.

Clamping the paddles

While it may be fun at first to be able to move your paddle off the screen, and while it may be seen as an extra challenge, let's stick to the original concept, and prevent the paddles from disappearing.

We can do that by making sure we don't update the paddle's y position with a value that's "out of bounds":

     in
     case paddle of
         RightPaddle paddleInfo ->
-            { paddleInfo | y = paddleInfo.y + amount }
+            { paddleInfo
+                | y =
+                    paddleInfo.y
+                        + amount
+                        |> clamp 0 (500 - paddleInfo.height)
+            }
                 |> RightPaddle

         LeftPaddle paddleInfo ->
-            { paddleInfo | y = paddleInfo.y + amount }
+            { paddleInfo
+                | y =
+                    paddleInfo.y
+                        + amount
+                        |> clamp 0 (500 - paddleInfo.height)
+            }
                 |> LeftPaddle

commit

Source code up to this point.

Here we're using the very convenient clamp helper to make sure the y coordinates of the paddles can't go above 500 - paddle.height (which means the full paddle is always displayed), nor below 0.

Adding some verticalization

Up till now the ball would always move horizontally. Never up or down. And as such, the game... well, let's say that it wasn't very challenging. But that changes now!

Let's add a vertSpeed to the ball, and set it to a fixed value for now:

@@ -21,6 +21,7 @@ type alias Ball =
     , y : Int
     , radius : Int
     , horizSpeed : Int
+    , vertSpeed : Int
     }


@@ -78,6 +79,7 @@ initBall =
     , y = 250
     , radius = 10
     , horizSpeed = 4
+    , vertSpeed = 2
     }


@@ -122,6 +124,7 @@ update msg model =
                 updatedBall =
                     { ball
                         | x = ball.x + horizSpeed
+                        , y = ball.y + ball.vertSpeed
                         , horizSpeed = horizSpeed
                     }

commit

We're not doing anything fancy here: adding a new field to the Ball record, initializing it to 2, and adding it to the y coordinates of the ball on each frame.

And behold the result!

And now we know what we need to do next:

Bouncing the ball off the walls

What good is a ball that we can't see anymore? Let's fix that by mimicking what we did for the bouncing off the paddles:

                     else
                         ball.horizSpeed

+                shouldBounceVertically =
+                    shouldBallBounceVertically model.ball
+
+                vertSpeed =
+                    if shouldBounceVertically then
+                        ball.vertSpeed * -1
+
+                    else
+                        ball.vertSpeed
+
                 updatedBall =
                     { ball
                         | x = ball.x + horizSpeed
-                        , y = ball.y + ball.vertSpeed
+                        , y = ball.y + vertSpeed
                         , horizSpeed = horizSpeed
+                        , vertSpeed = vertSpeed
                     }

                 updatedRightPaddle =
@@ -233,6 +244,15 @@ shouldBallBounce paddle ball =
                 && (ball.y <= y + height)


+shouldBallBounceVertically : Ball -> Bool
+shouldBallBounceVertically ball =
+    let
+        radius =
+            ball.radius
+    in
+    ball.y <= radius || ball.y >= (500 - radius)
+
+
 view : Model -> Svg.Svg Msg
 view { ball, rightPaddle, leftPaddle } =
     svg

commit

Losing and winning

Whenever the ball reaches the left or right side of the screen, the game should reset, and the opposite player should win a point.

So let's detect the win/lose condition:

@@ -44,6 +44,11 @@ type PaddleMovement
     | NotMoving


+type Player
+    = LeftPlayer
+    | RightPlayer
+
+
 type Msg
     = OnAnimationFrame Float
     | KeyDown PlayerAction
@@ -144,6 +149,10 @@ update msg model =

                 updatedLeftPaddle =
                     updatePaddle model.leftPaddleMovement model.leftPaddle
+
+                winner =
+                    maybeWinner updatedBall
+                        |> Debug.log "Winner"
             in
             ( { model
                 | ball = updatedBall
@@ -253,6 +262,18 @@ shouldBallBounceVertically ball =
     ball.y <= radius || ball.y >= (500 - radius)


+maybeWinner : Ball -> Maybe Player
+maybeWinner ball =
+    if ball.x <= ball.radius then
+        Just RightPlayer
+
+    else if ball.x >= (500 - ball.radius) then
+        Just LeftPlayer
+
+    else
+        Nothing
+
+
 view : Model -> Svg.Svg Msg
 view { ball, rightPaddle, leftPaddle } =
     svg

commit

This displays Winner: Nothing in the console on each frame, until there's a Winner: Just RightPlayer as soon as the ball hits the right border... and then on each following frame, as the game doesn't reset. Yet.

"But Mathieu, what is this Maybe thing, and all that Just and Nothing nonsense?". Hoy! Behave, that's no nonsense, that's proper engineering! It's called the Maybe type and it represents "values that may or may not exist", which is exactly what we need here: there may be a winner, or maybe not. The result is either "just a player" or "nothing" (no winner). And we can now use this Maybe Player to update a new custom type that we'll call GameStatus:

@@ -13,6 +13,7 @@ type alias Model =
     , leftPaddle : Paddle
     , rightPaddleMovement : PaddleMovement
     , leftPaddleMovement : PaddleMovement
+    , gameStatus : GameStatus
     }


@@ -49,6 +50,11 @@ type Player
     | RightPlayer


+type GameStatus
+    = NoWinner
+    | Winner Player
+
+
 type Msg
     = OnAnimationFrame Float
     | KeyDown PlayerAction
@@ -73,6 +79,7 @@ init _ =
       , leftPaddle = LeftPaddle <| initPaddle 10
       , rightPaddleMovement = NotMoving
       , leftPaddleMovement = NotMoving
+      , gameStatus = NoWinner
       }
     , Cmd.none
     )
@@ -150,14 +157,19 @@ update msg model =
                 updatedLeftPaddle =
                     updatePaddle model.leftPaddleMovement model.leftPaddle

-                winner =
-                    maybeWinner updatedBall
-                        |> Debug.log "Winner"
+                gameStatus =
+                    case maybeWinner updatedBall of
+                        Nothing ->
+                            NoWinner
+
+                        Just player ->
+                            Winner player
             in
             ( { model
                 | ball = updatedBall
                 , rightPaddle = updatedRightPaddle
                 , leftPaddle = updatedLeftPaddle
+                , gameStatus = gameStatus
               }
             , Cmd.none
             )

commit

We now have a proper GameState that gets updated whenever the ball reaches the left or right, but we aren't doing anything with it yet. What should we do with it?

Well... if we're in the NoWinner state, it means we should be playing, and as such listening to user input and animation frames. If we're in the Winner ... state, we shouldn't.

 subscriptions : Model -> Sub Msg
-subscriptions _ =
-    Sub.batch
-        [ Browser.Events.onAnimationFrameDelta OnAnimationFrame
-        , Browser.Events.onKeyDown (Decode.map KeyDown keyDecoder)
-        , Browser.Events.onKeyUp (Decode.map KeyUp keyDecoder)
-        ]
+subscriptions model =
+    case model.gameStatus of
+        NoWinner ->
+            Sub.batch
+                [ Browser.Events.onAnimationFrameDelta OnAnimationFrame
+                , Browser.Events.onKeyDown (Decode.map KeyDown keyDecoder)
+                , Browser.Events.onKeyUp (Decode.map KeyUp keyDecoder)
+                ]
+
+        Winner _ ->
+            Sub.none

commit

As easy as this! Now the game stops as soon as a player wins.

Now let's restart the game after a 500 milliseconds delay. For that, we'll introduce a new concept: the Task which makes "it easy to describe asynchronous operations": in our case, the Task will be a Process.sleep.

Once we have the Task, we can ask the elm runtime to execute it for us using Task.perform which will return a Cmd Msg. We'll attach a new Msg variant that we'll call SleepDone to that Cmd:

 import Browser
 import Browser.Events
 import Json.Decode as Decode
+import Process
 import Svg exposing (..)
 import Svg.Attributes exposing (..)
+import Task


 type alias Model =
@@ -59,6 +61,7 @@ type Msg
     = OnAnimationFrame Float
     | KeyDown PlayerAction
     | KeyUp PlayerAction
+    | SleepDone ()


 type PlayerAction
@@ -157,13 +160,18 @@ update msg model =
                 updatedLeftPaddle =
                     updatePaddle model.leftPaddleMovement model.leftPaddle

-                gameStatus =
+                ( gameStatus, cmd ) =
                     case maybeWinner updatedBall of
                         Nothing ->
-                            NoWinner
+                            ( NoWinner, Cmd.none )

                         Just player ->
-                            Winner player
+                            let
+                                delayCmd =
+                                    Process.sleep 500
+                                        |> Task.perform SleepDone
+                            in
+                            ( Winner player, delayCmd )
             in
             ( { model
                 | ball = updatedBall
@@ -171,7 +179,7 @@ update msg model =
                 , leftPaddle = updatedLeftPaddle
                 , gameStatus = gameStatus
               }
-            , Cmd.none
+            , cmd
             )

         KeyDown playerAction ->
@@ -218,6 +226,13 @@ update msg model =
                     , Cmd.none
                     )

+        SleepDone _ ->
+            let
+                _ =
+                    Debug.log "restart" "game"
+            in
+            ( model, Cmd.none )
+

 updatePaddle : PaddleMovement -> Paddle -> Paddle
 updatePaddle movement paddle =

commit

This one involves quite a lot, so let's decompose it piece by piece:

On each frame, we now not only change the game status if needed, we also send a Cmd to the elm runtime if there was a win. This command is:

Process.sleep 500
    |> Task.perform SleepDone

As a reminder, that's the same as writing

Task.perform SleepDone (Process.sleep 500)

The Task.perform translates a Task into a Cmd, which can then be sent to the elm runtime, by returning it from the update function. Which brings us to the ( Model, Cmd Msg ) in the type signature of the update function, which is a tuple type. A tuple is a fixed size list of things with types which may differ. This is very different from the List type which is a variable size list of things of the same type.

Back to the code:

( gameStatus, cmd ) =
    case maybeWinner updatedBall of
        Nothing ->
            ( NoWinner, Cmd.none )

        Just player ->
            let
                delayCmd =
                    Process.sleep 500
                        |> Task.perform SleepDone
            in
            ( Winner player, delayCmd )

The first part before the = sign is destructuring a 2-tuple into two variables names gameStatus and cmd. The cmd is the command that will be returned by the update function if we're processing an onAnimationFrameDelta message.

And this command is either Cmd.none (no command) if there's NoWinner, or the delayCmd if there's a winner.

The end of the previous diff is simply processing the SleepDone message. At the moment the only thing it's doing is printing a debug message in the console. As we've seen previously, using the _ means we don't care about the variable (so we don't care about the "game" string that we passed to the Debug.log function, and we don't care either about the data attached to the SleepDone message).

"But wait Mathieu, if we don't care about the data attached to the SleepDone variant, why does it even have it in the first place?". Very good question. Brace yourselves for the answer:

A task always returns something. Sometimes, this "thing" is uninteresting, in which case we use the unit, which is represented by () and has only one value: (). And if we go back to the Process.sleep signature, it says it returns a Task x () (so a Task that returns a unit).

And this thing that the Task returns is the same thing that is attached to the message that the Task.perform takes as its first argument. Hence the SleepDone ().

Let me show you a little nugget of cleverness (but please remember, being clever is usually a bad idea, so use this sparingly): the always helper is a function that always returns the same thing, whatever the argument you give it. This seems pretty useless, but we could use it to our advantage in our case:

@@ -61,7 +61,7 @@ type Msg
     = OnAnimationFrame Float
     | KeyDown PlayerAction
     | KeyUp PlayerAction
-    | SleepDone ()
+    | SleepDone


 type PlayerAction
@@ -169,7 +169,7 @@ update msg model =
                             let
                                 delayCmd =
                                     Process.sleep 500
-                                        |> Task.perform SleepDone
+                                        |> Task.perform (always SleepDone)
                             in
                             ( Winner player, delayCmd )
             in
@@ -226,7 +226,7 @@ update msg model =
                     , Cmd.none
                     )

-        SleepDone _ ->
+        SleepDone ->
             let
                 _ =
                     Debug.log "restart" "game"

We don't care about the data attached to the message by Task.perform, so we just discard it by using the always helper. This might seem confusing, but keep in mind that a custom type variant is also a constructor. So when we wanted to create a new right paddle, we would do RightPaddle paddleInfo. You can see RightPaddle as a function with the following type signature:

RightPaddle : PaddleInfo -> Paddle

So you can also see (always SleepDone) as a function that takes a parameter and returns SleepDone, and we could call it alwaysSleepDone:

alwaysSleepDone : a -> Msg

Using a type starting with a lowercase (the a in the type signature just above) means that it could be any type, including a unit. In any case, we don't care about the type that's being passed to the helper, so no need to be specific here.

So the final diff would be:

@@ -61,7 +61,7 @@ type Msg
     = OnAnimationFrame Float
     | KeyDown PlayerAction
     | KeyUp PlayerAction
-    | SleepDone ()
+    | SleepDone


 type PlayerAction
@@ -167,9 +167,13 @@ update msg model =

                         Just player ->
                             let
+                                alwaysSleepDone : a -> Msg
+                                alwaysSleepDone =
+                                    always SleepDone
+
                                 delayCmd =
                                     Process.sleep 500
-                                        |> Task.perform SleepDone
+                                        |> Task.perform alwaysSleepDone
                             in
                             ( Winner player, delayCmd )
             in
@@ -226,7 +230,7 @@ update msg model =
                     , Cmd.none
                     )

-        SleepDone _ ->
+        SleepDone ->
             let
                 _ =
                     Debug.log "restart" "game"

commit

Source code up to this point.

This didn't give us much in terms of readability, or at least it's debatable. I know I'd rather have obvious types and slightly more complex code, but I guess that's a matter of taste.

Restarting the game

So what should happen once the delay has elapsed, and the game should "restart"? Well the ball should be reset to its initial position and speed, and the game status should be NoWinner again:

         SleepDone ->
-            let
-                _ =
-                    Debug.log "restart" "game"
-            in
-            ( model, Cmd.none )
+            ( { model
+                | ball = initBall
+                , gameStatus = NoWinner
+              }
+            , Cmd.none
+            )

commit

Once the ball touches one of the "goals", the whole game stops for half a second, and then the ball position is reset.

Keeping track of the score

Let's add a score record with the rightPlayerScore and leftPlayerScore fields to the model, and update them whenever there's a win:

@@ -16,6 +16,7 @@ type alias Model =
     , rightPaddleMovement : PaddleMovement
     , leftPaddleMovement : PaddleMovement
     , gameStatus : GameStatus
+    , score : Score
     }


@@ -71,6 +72,12 @@ type PlayerAction
     | LeftPaddleDown


+type alias Score =
+    { rightPlayerScore : Int
+    , leftPlayerScore : Int
+    }
+
+
 type alias Flags =
     ()

@@ -83,6 +90,10 @@ init _ =
       , rightPaddleMovement = NotMoving
       , leftPaddleMovement = NotMoving
       , gameStatus = NoWinner
+      , score =
+            { rightPlayerScore = 0
+            , leftPlayerScore = 0
+            }
       }
     , Cmd.none
     )
@@ -160,10 +171,10 @@ update msg model =
                 updatedLeftPaddle =
                     updatePaddle model.leftPaddleMovement model.leftPaddle

-                ( gameStatus, cmd ) =
+                ( gameStatus, score, cmd ) =
                     case maybeWinner updatedBall of
                         Nothing ->
-                            ( NoWinner, Cmd.none )
+                            ( NoWinner, model.score, Cmd.none )

                         Just player ->
                             let
@@ -174,14 +185,19 @@ update msg model =
                                 delayCmd =
                                     Process.sleep 500
                                         |> Task.perform alwaysSleepDone
+
+                                updatedScore =
+                                    updateScores model.score player
+                                        |> Debug.log "score"
                             in
-                            ( Winner player, delayCmd )
+                            ( Winner player, updatedScore, delayCmd )
             in
             ( { model
                 | ball = updatedBall
                 , rightPaddle = updatedRightPaddle
                 , leftPaddle = updatedLeftPaddle
                 , gameStatus = gameStatus
+                , score = score
               }
             , cmd
             )
@@ -306,6 +322,16 @@ maybeWinner ball =
         Nothing


+updateScores : Score -> Player -> Score
+updateScores score winner =
+    case winner of
+        RightPlayer ->
+            { score | rightPlayerScore = score.rightPlayerScore + 1 }
+
+        LeftPlayer ->
+            { score | leftPlayerScore = score.leftPlayerScore + 1 }
+
+
 view : Model -> Svg.Svg Msg
 view { ball, rightPaddle, leftPaddle } =
     svg

commit

Now that we have the score, we can display it ;)

@@ -188,7 +188,6 @@ update msg model =

                                 updatedScore =
                                     updateScores model.score player
-                                        |> Debug.log "score"
                             in
                             ( Winner player, updatedScore, delayCmd )
             in
@@ -333,7 +332,7 @@ updateScores score winner =


 view : Model -> Svg.Svg Msg
-view { ball, rightPaddle, leftPaddle } =
+view { ball, rightPaddle, leftPaddle, score } =
     svg
         [ width "500"
         , height "500"
@@ -343,6 +342,7 @@ view { ball, rightPaddle, leftPaddle } =
         [ viewBall ball
         , viewPaddle rightPaddle
         , viewPaddle leftPaddle
+        , viewScore score
         ]


@@ -376,6 +376,19 @@ viewPaddle paddle =
         []


+viewScore : Score -> Svg.Svg Msg
+viewScore score =
+    g
+        [ fontSize "100px"
+        , fontFamily "monospace"
+        ]
+        [ text_ [ x "100", y "100", textAnchor "start" ]
+            [ text <| String.fromInt score.leftPlayerScore ]
+        , text_ [ x "400", y "100", textAnchor "end" ]
+            [ text <| String.fromInt score.rightPlayerScore ]
+        ]
+
+
 subscriptions : Model -> Sub Msg
 subscriptions model =
     case model.gameStatus of

commit

Source code up to this point.

Tada!!!

Maybe it's time to talk briefly about the view. You might have been wondering how that was working.

In elm we have packages that provide helpers to build the node tree. There's one for Html and one for SVG, and they both work the same way. Each node builder has two parameters:

a list of attributes and event listeners
a list of child nodes

One notable exception is the text helper which just returns plain text.

This is how you would build a paragraph with the foobar class:

Html.p
    [ Html.Attributes.class "foobar" ]
    [ Html.text "Hello world"]

So building a node tree (a DOM) is a matter of calling helpers and providing them their list of attributes and children.

And that's exactly what we did with the viewScore function:

the parent node is an SVG <g> container, with a list of attributes
- first child is an SVG <text> node with its list of attributes
  - and its child is just plain text
- second child is an SVG <text> node with its list of attributes
  - and its child is just plain text

The use of an underscore in text_ is needed to disambiguate between the <text> SVG node and the plain text helper text.

We now have a fully playable game! It might not be pretty, or fun, but it has all the minimal requirements, congratulations!

Next time, we might have a look at how to add a few bells and whistles just for the sake of introducing a few more elm concepts ;)

There's now a follow up.

Making a pong game in elm (2)

2019-07-30T15:41:00+02:00

Following the previous blog post, let's continue taking tiny steps in our endeavour to create a pong game in elm.

We left off with a ball and a single paddle. The ball would move towards the right, bounce off the paddle, and then move left until it left the screen.

Adding a left paddle

Before adding a left paddle, let's slightly change our code to prepare for it, by renaming the current paddle to rightPaddle:

 type alias Model =
     { ball : Ball
-    , paddle : Paddle
+    , rightPaddle : Paddle
     }


@@ -38,9 +38,8 @@ type alias Flags =

 init : Flags -> ( Model, Cmd Msg )
 init _ =
-    ( { ball =
-            initBall
-      , paddle = initPaddle
+    ( { ball = initBall
+      , rightPaddle = initPaddle
       }
     , Cmd.none
     )
@@ -83,7 +82,7 @@ update msg model =
                     model.ball

                 shouldBounce =
-                    shouldBallBounce model.paddle model.ball
+                    shouldBallBounce model.rightPaddle model.ball

                 horizSpeed =
                     if shouldBounce then
@@ -109,7 +108,7 @@ shouldBallBounce paddle ball =


 view : Model -> Svg.Svg Msg
-view { ball, paddle } =
+view { ball, rightPaddle } =
     svg
         [ width "500"
         , height "500"
@@ -117,7 +116,7 @@ view { ball, paddle } =
         , Svg.Attributes.style "background: #efefef"
         ]
         [ viewBall ball
-        , viewPaddle paddle
+        , viewPaddle rightPaddle
         ]

commit

Adding the left paddle should now be very straightforward:

 type alias Model =
     { ball : Ball
     , rightPaddle : Paddle
+    , leftPaddle : Paddle
     }


@@ -40,6 +41,7 @@ init : Flags -> ( Model, Cmd Msg )
 init _ =
     ( { ball = initBall
       , rightPaddle = initPaddle
+      , leftPaddle = initPaddle
       }
     , Cmd.none
     )
@@ -108,7 +110,7 @@ shouldBallBounce paddle ball =


 view : Model -> Svg.Svg Msg
-view { ball, rightPaddle } =
+view { ball, rightPaddle, leftPaddle } =
     svg
         [ width "500"
         , height "500"
@@ -117,6 +119,7 @@ view { ball, rightPaddle } =
         ]
         [ viewBall ball
         , viewPaddle rightPaddle
+        , viewPaddle leftPaddle
         ]

commit

Yes, you clever person, I know what you're thinking: "we can't see the left paddle! And it's obvious, it's because you placed it exactly at the same position as the right paddle!". I'm proud of you, and yes, you are right. Let's fix that by modifying the initPaddle function which should now take an initial x position.

 init : Flags -> ( Model, Cmd Msg )
 init _ =
     ( { ball = initBall
-      , rightPaddle = initPaddle
-      , leftPaddle = initPaddle
+      , rightPaddle = initPaddle 480
+      , leftPaddle = initPaddle 10
       }
     , Cmd.none
     )
@@ -56,9 +56,9 @@ initBall =
     }


-initPaddle : Paddle
-initPaddle =
-    { x = 480
+initPaddle : Int -> Paddle
+initPaddle initialX =
+    { x = initialX
     , y = 225
     , width = 10
     , height = 50

commit

"But wait Mathieu, can't you see the ball is going right through the left paddle!". I sure do, and yes, let's now fix that by changing the shouldBallBounce helper function.

It'll be a bit tricky though, because we need to check both paddles slightly differently: if it's the left paddle, the check on the y position is exactly the same, but the check on the x position now needs to make sure that the ball stays "right of" the left paddle, which means that the ball's center minus its radius is bigger than the left paddle's x position plus its width.

                 shouldBounce =
                     shouldBallBounce model.rightPaddle model.ball
+                        || shouldBallBounce model.leftPaddle model.ball

                 horizSpeed =
                     if shouldBounce then
@@ -104,9 +105,17 @@ update msg model =

 shouldBallBounce : Paddle -> Ball -> Bool
 shouldBallBounce paddle ball =
-    (ball.x + ball.radius >= paddle.x)
-        && (ball.y >= paddle.y)
-        && (ball.y <= paddle.y + 50)
+    if paddle.x == 10 then
+        -- left paddle
+        (ball.x - ball.radius <= paddle.x + paddle.width)
+            && (ball.y >= paddle.y)
+            && (ball.y <= paddle.y + 50)
+
+    else
+        -- right paddle
+        (ball.x + ball.radius >= paddle.x)
+            && (ball.y >= paddle.y)
+            && (ball.y <= paddle.y + 50)

commit

It's now working exactly as expected:

That's a huge success, let's take a pause, and reflect on our awesomeness!

Refactoring and types

If you're like me, you feel that there's something smelly. Something fishy. Something that isn't quite right.

I mean, what's with the shouldBallBounce function and its check on the paddle's x position? Sure, there's a comment in there, which is a bit like a perfume spread on something smelly: it doesn't make the smelly thing less smelly, it just kinda hides the smell. And I've written "smell" way too often in the last couple sentences (see the code smell definition for the reference).

Instead of checking the x position of a paddle to know if it's the left or the right one, it would be very useful to declare the paddles as left or right.

In other languages, people would use something like an enum, but in elm, there's a wonderful thing called custom types which are very powerful and convenient to use:

type Paddle
    = LeftPaddle
    | RightPaddle

Actually, we need the position information (x, y, width, height) for each paddle, so it should rather be something like:

type Paddle
    = LeftPaddle { x: Int, y: Int, width: Int, height: Int}
    | RightPaddle { x: Int, y: Int, width: Int, height: Int}

By now, this thing might ring a bell to you: in the previous installment we declared another custom type (the Msg) which also encapsulated some data. It did ring a bell to you, didn't it? You're clever, and I'm proud of you. You should also be proud of yourself. And even if it didn't ring a bell to you, I'm sure it'll will in the future, and I'm proud of you all the same!

So what are those custom types? It might be one of the features of elm that I find the most difficult to put in words, even though they feel so natural now that I'm used to them.

They're composed of:

a name: the type itself (Msg, Paddle, ...)
some variants: you can see those as functions, or constructors. They are the different "values" for this type. For the Msg type we only declared one. For the Paddle type we'll have two (LeftPaddle and RightPaddle).
some optional data attached to those variants: the OnAnimationFrame variant had a float, our LeftPaddle and RightPaddle have some position information.

Regarding the optional data attached, you can have variants with and without those. This is how you could type an answer which is either yes, no, or other with some additional information.

type Answer
    = Yes
    | No
    | Other String

Here we used the built-in String type for the associated information, but we can use any type, including one we've defined ourselves

Oh, another cool thing, a variant can have any number of data attached to it, so we could imagine having

type Paddle
    = LeftPaddle Int Int Int Int
    | RightPaddle Int Int Int Int

But then we'd have to remember which Int is for which type of data, which would be inconvenient, more difficult to maintain, and generally seen as bad practice.

Soooooo, after all this chatter, let's

declare a PaddleInfo type alias to hold all the position data
attach this PaddleInfo to the modified Paddle type variants

-type alias Paddle =
+type Paddle
+    = RightPaddle PaddleInfo
+    | LeftPaddle PaddleInfo
+
+
+type alias PaddleInfo =
     { x : Int
     , y : Int
     , width : Int
     , height: Int
     }

And now for arguably the best part of elm: the compiler. Let's compile this, and follow the errors that the compiler is giving us, and we'll have everything compiling and working again in a jiffy.

The first error says:

-- TYPE MISMATCH -------------------------------------------------- src/Main.elm

Something is off with the body of the `initPaddle` definition:

66|>    { x = initialX
67|>    , y = 225
68|>    , width = 10
69|>    , height = 50
70|>    }

The body is a record of type:

    { height : number, width : number1, x : Int, y : number2 }

But the type annotation on `initPaddle` says it should be:

    Paddle

Here, the compiler complains because we changed to the Paddle type, and the initPaddle function signature still says it's returning a Paddle, but it should instead be a PaddleInfo:

-initPaddle : Int -> Paddle
+initPaddle : Int -> PaddleInfo
 initPaddle initialX =
     { x = initialX
     , y = 225

The next compiler error is:

-- TYPE MISMATCH -------------------------------------------------- src/Main.elm

Something is off with the body of the `init` definition:

47|>    ( { ball = initBall
48|>      , rightPaddle = initPaddle 480
49|>      , leftPaddle = initPaddle 10
50|>      }
51|>    , Cmd.none
52|>    )

The body is a tuple of type:

    ( { ball : Ball, leftPaddle : PaddleInfo, rightPaddle : PaddleInfo }
    , Cmd msg
    )

But the type annotation on `init` says it should be:

    ( Model, Cmd Msg )

What this says is that the init function should return a ( Model, Cmd Msg ) but it returns something else instead of the Model: a record that has two fields rightPaddle and leftPaddle that are... PaddleInfo (instead of Paddle). Let's change this:

 init : Flags -> ( Model, Cmd Msg )
 init _ =
     ( { ball = initBall
-      , rightPaddle = initPaddle 480
-      , leftPaddle = initPaddle 10
+      , rightPaddle = RightPaddle <| initPaddle 480
+      , leftPaddle = LeftPaddle <| initPaddle 10
       }
     , Cmd.none
     )

As a refresher, the <| syntactic sugar means that we're taking the result of what's on the right of the "arrow", and using it as an argument for what's on the left. So we're using the PaddleInfo we're getting back from the initPaddle helper function, and "attaching" it to the Paddle variant. This could also be rewritten

RightPaddle (initPaddle 480)

The next error is:

-- TYPE MISMATCH -------------------------------------------------- src/Main.elm

This is not a record, so it has no fields to access!

113|     if paddle.x == 10 then
            ^^^^^^
This `paddle` value is a:

    Paddle

But I need a record with a x field!

This is interesting: the line 113 is in the shouldBallBounce function, which is where we started all this refactoring. We're now ready to reap the benefits:

 shouldBallBounce : Paddle -> Ball -> Bool
 shouldBallBounce paddle ball =
-    if paddle.x == 10 then
-        -- left paddle
-        (ball.x - ball.radius <= paddle.x + paddle.width)
-            && (ball.y >= paddle.y)
-            && (ball.y <= paddle.y + 50)
-
-    else
-        -- right paddle
-        (ball.x + ball.radius >= paddle.x)
-            && (ball.y >= paddle.y)
-            && (ball.y <= paddle.y + 50)
+    case paddle of
+        LeftPaddle { x, y, width, height } ->
+            (ball.x - ball.radius <= x + width)
+                && (ball.y >= y)
+                && (ball.y <= y + height)
+
+        RightPaddle { x, y, height } ->
+            (ball.x + ball.radius >= x)
+                && (ball.y >= y)
+                && (ball.y <= y + height)

"MATHIEU?! WHAT KIND OF VOODOO IS THAT, YOU TRICKED ME! I thought this was going to be an easy to follow guide, and now I feel miserable!"

I'm sorry, please bear with me for a minute while I dissect what happened here:

we already saw the case in the previous blog post when writing the update function. It's like a switch in some other languages, and it's used to "select" which branch of code to execute given what the "shape" of the data is. Here we're selecting based on the variants of Paddle (LeftPaddle or RightPaddle).
the case also allows us to "destructure" or "pattern match" the type and its attached data. What we're saying is "if there's a LeftPaddle then assign its x, y, width and height to variables of the same name. So in the code after the -> the names x, y, ... all have the value of what's in the PaddleInfo record attached to the Paddle type.
in the case of the RightPaddle we didn't need the width value, so we simply didn't "destructure" (and assign) it

This new code might not be much shorter, but it's way more readable, and doesn't involve a paddle.x check against a hard coded value that we might want to change in the future. Also no more need for the comments, as it's self commenting.

And we're left with one last error:

-- TYPE MISMATCH -------------------------------------------------- src/Main.elm

This is not a record, so it has no fields to access!

152|         [ x <| String.fromInt paddle.x
                                   ^^^^^^
This `paddle` value is a:

    Paddle

But I need a record with a x field!

The fix is then:

 viewPaddle : Paddle -> Svg.Svg Msg
 viewPaddle paddle =
+    let
+        paddleInfo =
+            case paddle of
+                LeftPaddle info ->
+                    info
+
+                RightPaddle info ->
+                    info
+    in
     rect
-        [ x <| String.fromInt paddle.x
-        , y <| String.fromInt paddle.y
-        , width <| String.fromInt paddle.width
-        , height <| String.fromInt paddle.height
+        [ x <| String.fromInt paddleInfo.x
+        , y <| String.fromInt paddleInfo.y
+        , width <| String.fromInt paddleInfo.width
+        , height <| String.fromInt paddleInfo.height
         ]
         []

"MATHIEU?! YOU DID IT AGAIN!". Ok, sorry, sorry, I was being cheeky here.

The main part is this one:

    let
        paddleInfo =
            case paddle of
                LeftPaddle info ->
                    info

                RightPaddle info ->
                    info
    in

The let..in is where we assign values to names (to "variables"). Here we're assigning the attached data of the LeftPaddle or RightPaddle to the name paddleInfo (which we're using in the rest of the function code). And we're once again using a case to destructure the type. Both cases are the same because in our case both variants of the Paddle custom type have a single attached data of type PaddleInfo, but it could be different: as we explained earlier, we can mix and match any kind of variants for a given custom type.

So when we write LeftPaddle info -> info we're saying "if it's a LeftPaddle then take its attached data and assign it to the name "info", then return this "info" value" (which we then assign to the paddleInfo name in the let..in clause).

And we're now done! We have the exact same behavior, but a code that's more precise and maintainable. I agree that it might look more complex, or sometimes longer, but it gives us more flexibility, and above all, much better help and guards from the compiler, which is invaluable.

commit

Source code up to this point.

Moving the paddle

What good is a game if the player has no control whatsoever on it? It's high time that we give a way for the player to move the paddle. We'll start with the right paddle, just because.

This can't be hard, right? RIGHT? WRONG!

Sometimes elm feel complex. Complicated. Overengineered. Hard. Difficult. And that is because it's trying to do the right thing, not the simple thing. It's trying very very hard to prevent you from shooting yourself in the foot. It's helping you not have any runtime errors.

One such case are JSON decoders. And those are probably one of the major hurdles that elm beginners will face at some point, and feel overwhelmed.

Why decoders?

If they are so difficult, why bother at all? I mean, JSON is easy, right? Strings, bools, arrays, objects, numbers... how hard can it be?

Let's take a step back for a moment: if the elm compiler is going to help you have no runtime exception, it needs to be able to guarantee that there's no bad code branches. That a given field in the JSON object you're getting back is indeed a number, and not a string, or an array, or a null. Because if it can't guarantee that a value is of the proper type, it can't guarantee that the operations you do on that value are valid.

So, if the elm compiler needs to know the type of the fields in the JSON it gets, it needs a way to "decode" this JSON into proper types. And if the JSON doesn't decode properly into those types, then it'll fail in an expected way, and make you write a code branch for that case, so it doesn't end blowing up in your face at runtime.

That's where and why decoders are useful: you provide a "translation" from a untyped JSON to a typed value: if it succeeds, then you can use that typed value. If it fails, you handle this case (by displaying an error message for example).

You can see that as a way to validate the JSON that elm is receiving from the javascript land in the case of an event, or from an http request to a remote API.

So yes, decoders are hard to grasp. But if you trust my own experience, once you get to use them, you'll be missing them in other languages, and hoping there was a way to achieve the same result.

Keyboard events

There's a convenient Browser.Event module that provides event listeners for keyboard events.

Remember when we subscribed to the Browser.Events.onAnimationFrameDelta events in the previous episode? We'll do basically the same this time around.

We need to do a few things:

Decode a String from the keydown event
Attach that string to a Msg variant that we'll add: KeyDown String, so the decoder returns a Decoder Msg
Provide that decoder to the Browser.Events.onKeyDown subscription
Add a branch to the case in the update function to deal with the new Msg variant (we'll only display some debug info in the console for now)
Add an import to the Json.Decode module

 import Browser
 import Browser.Events
+import Json.Decode as Decode
 import Svg exposing (..)
 import Svg.Attributes exposing (..)

@@ -36,6 +37,7 @@ type alias PaddleInfo =

 type Msg
     = OnAnimationFrame Float
+    | KeyDown String


 type alias Flags =
@@ -107,6 +109,13 @@ update msg model =
             in
             ( { model | ball = updatedBall }, Cmd.none )

+        KeyDown keyString ->
+            let
+                _ =
+                    Debug.log "key pressed" keyString
+            in
+            ( model, Cmd.none )
+

 shouldBallBounce : Paddle -> Ball -> Bool
 shouldBallBounce paddle ball =
@@ -168,4 +177,12 @@ viewPaddle paddle =

 subscriptions : Model -> Sub Msg
 subscriptions _ =
-    Browser.Events.onAnimationFrameDelta OnAnimationFrame
+    Sub.batch
+        [ Browser.Events.onAnimationFrameDelta OnAnimationFrame
+        , Browser.Events.onKeyDown (Decode.map KeyDown keyDecoder)
+        ]
+
+
+keyDecoder : Decode.Decoder String
+keyDecoder =
+    Decode.field "key" Decode.string

commit

We used Decode.map here to attach the string we get back from the decoder to the KeyDown variant... but only if the keyDecoder succeeded!

Decode.map says "if the decoder succeeds, apply this function to the result". And we needed to do that because the onKeyDown event listener needs a Decoder Msg and not a Decoder String. In order to be able to subscribe to the events, the listener needs to know which message to call when it receives an event.

If you followed along, you'll notice a compiler error:

-- UNKNOWN IMPORT ------------------------------------------------- src/Main.elm

The Main module has a bad import:

    import Json.Decode

Do you want the one from the elm/json package? If so, run this command to add
that dependency to your elm.json file:

    elm install elm/json

If you want a local file, make sure the `Json.Decode` module is in one of the
"source-directories" listed in your elm.json file.

This very helpful message tells us that we need to add the missing dependency to the elm.json file, just like we did with elm/svg in the previous post. Running the elm install elm/json command result in the following changes in the elm.json file:

             "elm/browser": "1.0.1",
             "elm/core": "1.0.2",
             "elm/html": "1.0.0",
+            "elm/json": "1.1.3",
             "elm/svg": "1.0.1"
         },
         "indirect": {
-            "elm/json": "1.1.3",
             "elm/time": "1.0.0",
             "elm/url": "1.0.0",
             "elm/virtual-dom": "1.0.2"

It moved the elm/json dependency from the indirect dependencies to the direct ones.

In the previous post we already used the Debug.log helper, so let's take a minute to explain what that does: it's a function takes any argument (in our case the keyString) and displays it in the browser console, preceeded by the message you provide it (eg key pressed).

This is the result of pressing a few keys in the console:

The Debug.log helper also returns exactly what it received, so you can add it anywhere, it's very convenient!

However, be aware that it's not possible to use the elm compiler optimization with a Debug.xxx call, so they need to be removed before you compile for production.

In our case, we wanted to output a debug message to the console, but not do anything else. A common pattern is to use a let..in to fake a variable assignment, but not care about the resulting variable (hence the _ = ...). As we're not doing anything with the keyboard event (yet), we're also returning the exact same model we received in the update function, and send no commands: ( model, Cmd.none).

Decoding arrow key presses

There's a very convenient link in the onKeyDown documentation that brings us straight to something of great interest to us: Decoding for games.

As explained, it would make a lot of sense and give us some guarantees to use a custom type (that we could call PlayerAction):

 type Msg
     = OnAnimationFrame Float
-    | KeyDown String
+    | KeyDown PlayerAction
+
+
+type PlayerAction
+    = RightPaddleUp
+    | RightPaddleDown

Notice here that we didn't add an Other variant, because we'll be doing something else with the decoder... Event listeners in elm have a nice (and sometimes confusing?) behavior: whenever the decoder that they're given fails decoding, the event is simply discarded. Which means that no Msg is sent. It's as if the program simply didn't subscribe to those.

So we're going to modify our decoder to pass the resulting decoded string to another decoder using the Decode.andThen helper. And from this second decoder, we're going to Decode.succeed with one of the PlayerAction variants, or Decode.fail, in which case the event will be discarded.

-keyDecoder : Decode.Decoder String
+keyDecoder : Decode.Decoder PlayerAction
 keyDecoder =
     Decode.field "key" Decode.string
+        |> Decode.andThen keyToPlayerAction
+
+
+keyToPlayerAction : String -> Decode.Decoder PlayerAction
+keyToPlayerAction keyString =
+    case keyString of
+        "ArrowUp" ->
+            Decode.succeed RightPaddleUp
+
+        "ArrowDown" ->
+            Decode.succeed RightPaddleDown
+
+        _ ->
+            Decode.fail "not an event we care about"

commit

Decode.andThen is a bit different than Decoder.map: it also takes the result of a successful decoder, but returns a decoder (not a result). Which means that we can modify a decoder's behavior and make it fail or succeed instead of just modifying its successful result. In our case we make it fail if it's not one of the keys we're interested in... even though the keyDecoder would successfully decode a string from the event.

Neat, isn't it? Are you starting to like decoders? Love them even? I do.

Moving the right paddle

Now that we can detect player actions, we can react to them, and update the paddle position:

-        KeyDown keyString ->
-            let
-                _ =
-                    Debug.log "key pressed" keyString
-            in
-            ( model, Cmd.none )
+        KeyDown playerAction ->
+            case playerAction of
+                RightPaddleUp ->
+                    ( { model | rightPaddle = model.rightPaddle |> updatePaddle -10 }
+                    , Cmd.none
+                    )
+
+                RightPaddleDown ->
+                    ( { model | rightPaddle = model.rightPaddle |> updatePaddle 10 }
+                    , Cmd.none
+                    )
+
+
+updatePaddle : Int -> Paddle -> Paddle
+updatePaddle amount paddle =
+    case paddle of
+        RightPaddle paddleInfo ->
+            { paddleInfo | y = paddleInfo.y + amount }
+                |> RightPaddle
+
+        LeftPaddle paddleInfo ->
+            { paddleInfo | y = paddleInfo.y + amount }
+                |> LeftPaddle

commit

As you can see, we used a small helper function updatePaddle to update the info of a paddle, moving it up or down by a certain amount of pixels.

Moving the left paddle

Now that we have everything in place for the right player, it's straightforward to deal with the left player. We'll use the keys "e" for up, and "d" for down to cope with both azerty and qwerty keyboards. I'm sorry if this doesn't make sense for your keyboard, but I'm sure you'll be able to fix it by changing those keys in your code ;)

Let's do that step by step with the help from the lovely compiler:

 type PlayerAction
     = RightPaddleUp
     | RightPaddleDown
+    | LeftPaddleUp
+    | LeftPaddleDown

We have one compiler error:

-- MISSING PATTERNS ----------------------------------------------- src/Main.elm

This `case` does not have branches for all possibilities:

120|>            case playerAction of
121|>                RightPaddleUp ->
122|>                    ( { model | rightPaddle = model.rightPaddle |> updatePaddle -10 }
123|>                    , Cmd.none
124|>                    )
125|>
126|>                RightPaddleDown ->
127|>                    ( { model | rightPaddle = model.rightPaddle |> updatePaddle 10 }
128|>                    , Cmd.none
129|>                    )

Missing possibilities include:

    LeftPaddleUp
    LeftPaddleDown

I would have to crash if I saw one of those. Add branches for them!

Hint: If you want to write the code for each branch later, use `Debug.todo` as a
placeholder. Read <https://elm-lang.org/0.19.0/missing-patterns> for more
guidance on this workflow.

That's an easy one:

                     , Cmd.none
                     )

+                LeftPaddleUp ->
+                    ( { model | leftPaddle = model.leftPaddle |> updatePaddle -10 }
+                    , Cmd.none
+                    )
+
+                LeftPaddleDown ->
+                    ( { model | leftPaddle = model.leftPaddle |> updatePaddle 10 }
+                    , Cmd.none
+                    )
+

 updatePaddle : Int -> Paddle -> Paddle
 updatePaddle amount paddle =

The thing is, once we fixed that the compiler compiles successfully... but pressing the "e" or "d" keys has no effect whatsoever... elm compiler, why have you failed me!!!!!

Remember when we talked about the (sometimes confusing) behavior of event listeners in elm that are silently ignored if the decoder fails? And remember that we used that to our advantage to reduce the code a bit instead of dealing with an Other variant for the PlayerAction custom type?

Well here we are now: it's up to us to remember that we need to update the decoder:

         "ArrowDown" ->
             Decode.succeed RightPaddleDown

+        "e" ->
+            Decode.succeed LeftPaddleUp
+
+        "d" ->
+            Decode.succeed LeftPaddleDown
+
         _ ->
             Decode.fail "not an event we care about"

commit

Source code up to this point.

Well, it seems we have a mostly working pong game. Both players can move their paddles up or down. We would still have a LOOOOOONG way to go to make it a real, playable and enjoyable game though.

We did 80% of the work in 20% of the time. We now need 80% of the time to finish the remaining 20% of the work ;)

Some of the things that are blatantly missing:

losing/winning/scoring: when the ball moves off the screen the player should lose, and the other one should score a point
clamping the paddles to the screen, instead of letting them wander off
better input management: at the moment, both players can't keep pressing the keys at the same time, one takes precedence over the other one (at least for me on Firefox OSX)

Some ideas to make it more enjoyable:

deal with acceleration of the paddle
power ups/downs
visual effects
sound effects
increasing the difficulty (faster moving ball for example, shorter paddles)
one player mode against the computer
move the paddle using the mouse instead of the keyboard for a smoother experience
being able to play on a mobile phone/tablet using gestures
twists on the original concept

So what did you think? Did this give you a feel for the elm language? Did it make you want to give it a go for gamedev or webdev?

I would be curious to see if you come up with completed/improved games of your own!

There's now a follow up.

Making a pong game in elm

2019-07-26T15:01:00+02:00

Let's make a pong game in elm, by taking tiny steps.

If you haven't already, the very first step is to install elm, and to keep in mind that the folks on the slack channel are very friendly and helpful if you ever face an issue that you can't manage to solve on your own. You are not alone!

Create the project

$ elm init

This creates a elm.json file for you, and an empty src/ folder. Running elm make will compile the project and tell you:

$ elm make
Dependencies loaded from local cache.
Dependencies ready!
-- NO INPUT --------------------------------------------------------------------

What should I make though? I need more information, like:

    elm make src/Main.elm
    elm make src/This.elm src/That.elm

However many files you give, I will create one JS file out of them.

Ok, so let's create a very basic src/Main.elm file:

module Main exposing (main)

import Html


main =
    Html.text "Hello world"

Running elm make src/Main.elm will compile successfully and create an index.html file for us. Opening it in the browser displays a very dull Hello world message. Dull, for sure, but still a success!

Source code up to this point.

Display a ball

We're going to use the elm/svg, so we need to install it:

elm install elm/svg

Here's the result in the elm.json file once elm added the dependency for us:

         "direct": {
             "elm/browser": "1.0.1",
             "elm/core": "1.0.2",
-            "elm/html": "1.0.0"
+            "elm/html": "1.0.0",
+            "elm/svg": "1.0.1"
         },
         "indirect": {
             "elm/json": "1.1.3",

Once that's done, let's first draw a playing field (an empty light gray box), by changing our src/Main.elm file to:

module Main exposing (main)

import Svg exposing (..)
import Svg.Attributes exposing (..)


main =
    svg
        [ width "500"
        , height "500"
        , viewBox "0 0 500 500"
        , Svg.Attributes.style "background: #efefef"
        ]
        [ circle
            [ cx "250"
            , cy "250"
            , r "10"
            ]
            []
        ]

commit

This displays a 500px by 500px light gray rectangle, with a 10px circle right in the center:

Let's pull this circle out and make a viewBall function:

         , viewBox "0 0 500 500"
         , Svg.Attributes.style "background: #efefef"
         ]
-        [ circle
-            [ cx "250"
-            , cy "250"
-            , r "10"
-            ]
-            []
+        [ viewBall
         ]
+
+
+viewBall : Svg msg
+viewBall =
+    circle
+        [ cx "250"
+        , cy "250"
+        , r "10"
+        ]
+        []

commit

This doesn't give us much, yet. Now what's our next tiny step? Well, to display a ball, the function only needs its coordinates:

         , viewBox "0 0 500 500"
         , Svg.Attributes.style "background: #efefef"
         ]
-        [ viewBall
+        [ viewBall 250 250
         ]


-viewBall : Svg msg
-viewBall =
+viewBall : Int -> Int -> Svg.Svg msg
+viewBall x y =
     circle
-        [ cx "250"
-        , cy "250"
+        [ cx <| String.fromInt x
+        , cy <| String.fromInt y
         , r "10"
         ]
         []

commit

Here we started using integers for the positions (a number of pixels), instead of strings. This is because we will need to do some mathematics on the position, to get the ball moving. So we'll pass integers around, store them in our state, and at the last moment we'll translate them back to strings.

Talking about state, let's have a Ball type alias for a record holding the position:

 import Svg.Attributes exposing (..)


+type alias Ball =
+    { x : Int
+    , y : Int
+    }
+
+
+ball =
+    { x = 250
+    , y = 250
+    }
+
+
 main =
     svg
         [ width "500"
         , height "500"
         , viewBox "0 0 500 500"
         , Svg.Attributes.style "background: #efefef"
         ]
-        [ viewBall 250 250
+        [ viewBall ball
         ]


-viewBall : Int -> Int -> Svg.Svg msg
-viewBall x y =
+viewBall : Ball -> Svg.Svg msg
+viewBall { x, y } =
     circle
         [ cx <| String.fromInt x
         , cy <| String.fromInt y

commit

Source code up to this point.

Move the ball

Well, the ball isn't worth much if it's not moving, so let's do that. But let's pause for a moment, how would we achieve that?

In javascript we'd probably use setInterval, or setTimeout, and move the ball by a small amount every 16ms or so (which would give us 60fps: 1000ms / 16ms = 62.5 frames per second). Or we could use requestAnimationFrame which is an even better solution.

In elm we have the onAnimationFrameDelta event that we can subscribe to, which gives us the number of milliseconds elapsed since the previous animation frame. This way we can

animate the ball as smoothly as possible
move the ball by the proper amount, computed with the elapsed time between two frames

To subscribe to browser events we first need to change our program to be embedded as a Browser.element.

Let's do that a tiny step at a time. First let's extract the svg into its own view:

 main =
+    view ball
+
+
+view : Ball -> Svg.Svg ()
+view ball_ =
     svg
         [ width "500"
         , height "500"
         , viewBox "0 0 500 500"
         , Svg.Attributes.style "background: #efefef"
         ]
-        [ viewBall ball
+        [ viewBall ball_
         ]

commit

Now let's actually change the main to be a Browser.element. At the top of the file:

 module Main exposing (main)

+import Browser
 import Svg exposing (..)
 import Svg.Attributes exposing (..)

And below:

     }


+main : Program () () ()
 main =
-    view ball
+    Browser.element
+        { init = \_ -> ( (), Cmd.none )
+        , view = \_ -> view ball
+        , update = \_ _ -> ( (), Cmd.none )
+        , subscriptions = \_ -> Sub.none
+        }


 view : Ball -> Svg.Svg ()

commit

Well, that's an awful lot of empty parens (). Those are of the unit type in elm. They are just placeholders for now, as we're going to need some model, flags, messages...

Also, what's with all those \_ ->? That's how we write anonymous functions. And the _ simply means we don't care about that argument's value.

So the anonymous function provided for the element's update \_ _ -> ( (), Cmd.none ) can be written:

someFunction someArg someOtherArg = ( (), Cmd.none )

Let's start with a Model: this is, by convention in elm, the name of the state, the place were we store all the data needed by our system: the ball position, the paddles, the score, you name it. For now the only piece of data we have is the ball position, so our model can simply be a type alias to it.

The Model goes near the top of the file by convention:

 import Svg.Attributes exposing (..)


+type alias Model =
+    Ball
+
+
 type alias Ball =
     { x : Int
     , y : Int

And the main:

     }


-main : Program () () ()
+main : Program () Model ()
 main =
     Browser.element
-        { init = \_ -> ( (), Cmd.none )
-        , view = \_ -> view ball
-        , update = \_ _ -> ( (), Cmd.none )
+        { init = \_ -> ( ball, Cmd.none )
+        , view = view
+        , update = \_ model -> ( model, Cmd.none )
         , subscriptions = \_ -> Sub.none
         }


-view : Ball -> Svg.Svg ()
-view ball_ =
+view : Model -> Svg.Svg ()
+view model =
     svg
         [ width "500"
         , height "500"
         , viewBox "0 0 500 500"
         , Svg.Attributes.style "background: #efefef"
         ]
-        [ viewBall ball_
+        [ viewBall model
         ]

commit

Let's have a proper initialization function now: given some flags (none in our case, so we'll just keep the unit for now), it generates the initial model and commands (and we'll use Cmd.none for now):

     }


-ball =
-    { x = 250
-    , y = 250
-    }
+init : () -> ( Model, Cmd () )
+init _ =
+    ( { x = 250
+      , y = 250
+      }
+    , Cmd.none
+    )


 main : Program () Model ()
 main =
     Browser.element
-        { init = \_ -> ( ball, Cmd.none )
+        { init = init
         , view = view
         , update = \_ model -> ( model, Cmd.

commit

Ok, we should be mostly set up to receive events from the browser, and in particular the animation frames. A few missing pieces: we need to subscribe to those events, and we need to provide a message to the subscription, which will act as a kind of callback. The elm runtime will call our future update function with this message and our current model, to allow us to update the model. This updated model will then be passed down the view function to update what we see on the screen.

Let's define a Msg type (this is the conventional name used in elm):

     }


+type Msg
+    = OnAnimationFrame Float
+
+
 init : () -> ( Model, Cmd () )
 init _ =
     ( { x = 250

commit

This is a custom type named OnAnimationFrame which takes (includes? encapsulates? wraps? boxes?) a float which is the number of milliseconds since the previous animation frame.

We can now use this Msg type everywhere we used the unit previously...

In the init type definition:

     = OnAnimationFrame Float


-init : () -> ( Model, Cmd () )
+init : () -> ( Model, Cmd Msg )
 init _ =
     ( { x = 250
       , y = 250

In the main type definition:

     )


-main : Program () Model ()
+main : Program () Model Msg
 main =
     Browser.element
         { init = init

In the view type definition:

         }


-view : Model -> Svg.Svg ()
+view : Model -> Svg.Svg Msg
 view model =
     svg
         [ width "500"

And in the viewBall type definition:

         ]


-viewBall : Ball -> Svg.Svg msg
+viewBall : Ball -> Svg.Svg Msg
 viewBall { x, y } =
     circle
         [ cx <| String.fromInt x

commit

We can now subscribe to the event.

First add the Browser.Events import at the top of the file:

 module Main exposing (main)

 import Browser
+import Browser.Events
 import Svg exposing (..)
 import Svg.Attributes exposing (..)

Then use a subscriptions function in the main:

         { init = init
         , view = view
         , update = \_ model -> ( model, Cmd.none )
-        , subscriptions = \_ -> Sub.none
+        , subscriptions = subscriptions
         }

Then add the subscriptions function at the bottom of the file:

         , r "10"
         ]
         []
+
+
+subscriptions : Model -> Sub Msg
+subscriptions _ =
+    Browser.Events.onAnimationFrameDelta OnAnimationFrame

commit

If you compiled your elm files with the --debug option for elm make, you should see many many messages being received in the time traveller debug window:

Let's finally add a (mostly empty) update function, and add a Flags type alias on the unit type to clean things up a bit:

 type Msg
     = OnAnimationFrame Float


-init : () -> ( Model, Cmd Msg )
+type alias Flags =
+    ()
+
+
+init : Flags -> ( Model, Cmd Msg )
 init _ =
     ( { x = 250
       , y = 250
       }
     , Cmd.none
     )


-main : Program () Model Msg
+main : Program Flags Model Msg
 main =
     Browser.element
         { init = init
         , view = view
-        , update = \_ model -> ( model, Cmd.none )
+        , update = update
         , subscriptions = subscriptions
         }


+update : Msg -> Model -> ( Model, Cmd Msg )
+update msg model =
+    ( model, Cmd.none )
+
+
 view : Model -> Svg.Svg Msg
 view model =
     svg

commit

Source code up to this point.

We can be proud of ourselves: we changed a lot of code, but nothing changed visually: the ball still isn't moving! Promise, we're moving this ball next ;)

Move the ball (for real)

Now that we have everything in place, moving the ball is simply a matter of changing the x or y coordinates. And where better to do that than on each animation frame? We already have a subscription that fires an "event" (a message in elm's vocabulary). We also have an update function that is called with those messages, allowing us to return a new (and updated) model.

Yes, we need to return a new model because in elm everything is immutable: you don't change a model, you don't mutate it, you simply create a new one:

 update : Msg -> Model -> ( Model, Cmd Msg )
 update msg model =
-    ( model, Cmd.none )
+    case msg of
+        OnAnimationFrame timeDelta ->
+            ( { model | x = model.x + 4 }, Cmd.none )


 view : Model -> Svg.Svg Msg

commit

Source code up to this point.

Instead of always returning the same model we were passed in the update function, we now add 4 pixels to the x coordinates of the ball.

The { foo | bar = crux } notation is syntactic sugar to create a new record from the content of the foo record, but with the bar field set to the new crux value.

Once compiled and the browser tab refreshed, you should see the mighty ball moving rather quickly towards the right (and then disappearing!).

Now that the ball is moving, let's set us up quickly with some better tooling.

Tooling

At this point, you should start getting tired of running elm make, then switching to the browser, refreshing the page... modifying the code, and then starting over. Those few steps can quickly become tedious, and that's why most elm developers take advantage of:

Live reloading

Live reloading is automatically re-compiling the code whenever a file changes, and then automatically refreshing the browser tab. There are a few tools available that I know of:

They all offer some kind of web server that injects some javascript in the page, and then whenever a file changes, recompile the project, and communicate with the loaded web page using a websocket so it reloads. I've used all three in various projects, and they all have their pros and cons. I find elm-live to be one of the smallest and simplest to use, but really do feel free to pick one (but do pick one, it's really worth it ;)

Auto code formatting

Another tedious task is indenting and formatting the code properly. In elm indentation matters, and as in any written code, readability is important. The elm community has very broadly adopted a common code formatting tool that gives us a way to all share a same code style, which is a real blessing.

It also appears that once you stop caring about a code style, and let the machine do it for you, it really frees your mind from this chore, and removes all the bikeshedding and useless discussions and trolls.

This code formatting tool is elm-format, and can be configured to automatically reformat the code on save in most editors.

With those two tools installed and set up, let us continue with our game: adding a paddle!

Adding a paddle

The right paddle will be a simple rectangle (for now at least), 10 pixels wide, 50 pixels high, 10 pixels from the right border, and will start at the middle.

This makes the starting paddle coordinates:

x: 500 - 10 (paddle width) - 10 (margin with the right border) = 480
y: 500 / 2 (so it is centered vertically) - 50 / 2 (center of the paddle) = 225

         , Svg.Attributes.style "background: #efefef"
         ]
         [ viewBall model
+        , rect
+            [ x "480"
+            , y "225"
+            , width "10"
+            , height "50"
+            ]
+            []
         ]

commit

Behold the mighty paddle!

One problem though... the ball isn't boucing off of it. What good is a paddle that doesn't bounce?

But first, what does "bouncing" mean? In our case, bouncing of a vertical paddle means changing the horizontal direction of the ball. But we don't have a proper "direction" yet. For now, we only need a horizontal "direction" (or speed, or vector):

 type alias Ball =
     { x : Int
     , y : Int
+    , horizSpeed : Int
     }


@@ -28,6 +29,7 @@ init : Flags -> ( Model, Cmd Msg )
 init _ =
     ( { x = 250
       , y = 250
+      , horizSpeed = 4
       }
     , Cmd.none
     )
@@ -47,7 +49,7 @@ update : Msg -> Model -> ( Model, Cmd Msg )
 update msg model =
     case msg of
         OnAnimationFrame timeDelta ->
-            ( { model | x = model.x + 4 }, Cmd.none )
+            ( { model | x = model.x + model.horizSpeed }, Cmd.none )


 view : Model -> Svg.Svg Msg

commit

In case you're wondering what those @@ -28,6 +29,7 @@ init : Flags -> ( Model, Cmd Msg ) lines mean: that's the diff unified format telling us where the line is located: it's line 28, and it gives us a bit of context: it's in the init function.

What we did here was to extract the number of pixels we were adding to the x position of the ball into a horizSpeed state in the model.

Now that we have a horizontal speed, boucing (horizontally) simply means "reversing" its value, which is achieved by changing its sign. If we were adding 4 pixels per frame and bounced of the right paddle, we'd now need to substract 4 pixels per frame to the x coordinate.

Before going further, let's do some cleanup and slight reorganization:

Extract the ball radius and store it in the state:

 type alias Ball =
     { x : Int
     , y : Int
+    , radius : Int
     , horizSpeed : Int
     }

@@ -29,6 +30,7 @@ init : Flags -> ( Model, Cmd Msg )
 init _ =
     ( { x = 250
       , y = 250
+      , radius = 10
       , horizSpeed = 4
       }
     , Cmd.none
@@ -72,11 +74,11 @@ view model =


 viewBall : Ball -> Svg.Svg Msg
-viewBall { x, y } =
+viewBall { x, y, radius } =
     circle
         [ cx <| String.fromInt x
         , cy <| String.fromInt y
-        , r "10"
+        , r <| String.fromInt radius
         ]
         []

commit

Change the state to be a record holding a ball (instead of BEING a ball)

 type alias Model =
-    Ball
+    { ball : Ball
+    }


 type alias Ball =
@@ -28,15 +29,22 @@ type alias Flags =

 init : Flags -> ( Model, Cmd Msg )
 init _ =
-    ( { x = 250
-      , y = 250
-      , radius = 10
-      , horizSpeed = 4
+    ( { ball =
+            initBall
       }
     , Cmd.none
     )


+initBall : Ball
+initBall =
+    { x = 250
+    , y = 250
+    , radius = 10
+    , horizSpeed = 4
+    }
+
+
 main : Program Flags Model Msg
 main =
     Browser.element
@@ -51,18 +59,22 @@ update : Msg -> Model -> ( Model, Cmd Msg )
 update msg model =
     case msg of
         OnAnimationFrame timeDelta ->
-            ( { model | x = model.x + model.horizSpeed }, Cmd.none )
+            let
+                ball =
+                    model.ball
+            in
+            ( { model | ball = { ball | x = ball.x + ball.horizSpeed } }, Cmd.none )


 view : Model -> Svg.Svg Msg
-view model =
+view { ball } =
     svg
         [ width "500"
         , height "500"
         , viewBox "0 0 500 500"
         , Svg.Attributes.style "background: #efefef"
         ]
-        [ viewBall model
+        [ viewBall ball
         , rect
             [ x "480"
             , y "225"

commit

Extract the right paddle into its own type and state

 type alias Model =
     { ball : Ball
+    , paddle : Paddle
     }


@@ -19,6 +20,14 @@ type alias Ball =
     }


+type alias Paddle =
+    { x : Int
+    , y : Int
+    , width : Int
+    , height : Int
+    }
+
+
 type Msg
     = OnAnimationFrame Float

@@ -31,6 +40,7 @@ init : Flags -> ( Model, Cmd Msg )
 init _ =
     ( { ball =
             initBall
+      , paddle = initPaddle
       }
     , Cmd.none
     )
@@ -45,6 +55,15 @@ initBall =
     }


+initPaddle : Paddle
+initPaddle =
+    { x = 480
+    , y = 225
+    , width = 10
+    , height = 50
+    }
+
+
 main : Program Flags Model Msg
 main =
     Browser.element
@@ -70,7 +89,7 @@ update msg model =


 view : Model -> Svg.Svg Msg
-view { ball } =
+view { ball, paddle } =
     svg
         [ width "500"
         , height "500"
@@ -78,13 +97,7 @@ view { ball } =
         , Svg.Attributes.style "background: #efefef"
         ]
         [ viewBall ball
-        , rect
-            [ x "480"
-            , y "225"
-            , width "10"
-            , height "50"
-            ]
-            []
+        , viewPaddle paddle
         ]


@@ -98,6 +111,17 @@ viewBall { x, y, radius } =
         []


+viewPaddle : Paddle -> Svg.Svg Msg
+viewPaddle paddle =
+    rect
+        [ x <| String.fromInt paddle.x
+        , y <| String.fromInt paddle.y
+        , width <| String.fromInt paddle.width
+        , height <| String.fromInt paddle.height
+        ]
+        []
+
+
 subscriptions : Model -> Sub Msg
 subscriptions _ =
     Browser.Events.onAnimationFrameDelta OnAnimationFrame

commit

We're now ready to detect the bounce, and reverse the direction the ball is moving.

Source code up to this point.

Bouncing the ball off the paddle

The ball should bounce off the paddle, which is when the ball "touches" the paddle. That means that the ball should bounce (reverse direction) when both those conditions are met:

the x position of the ball (center) is more than radius away from the x position of the paddle
the y position of the ball is between the top (the paddle's y) and the bottom (the paddle's y plus the paddle's height) of the paddle

Let's make a helper function for that, which given a ball and a paddle will return True if the ball should bounce, and display the result of that check in each animation frame in the console:

                 ball =
                     model.ball

+                shouldBounce =
+                    shouldBallBounce model.paddle model.ball
+                        |> Debug.log "shouldBounce"
+
                 updatedBall =
                     { ball | x = ball.x + ball.horizSpeed }
             in
             ( { model | ball = updatedBall }, Cmd.none )


+shouldBallBounce : Paddle -> Ball -> Bool
+shouldBallBounce paddle ball =
+    (ball.x + ball.radius >= paddle.x)
+        && (ball.y >= paddle.y - 50 // 2)
+        && (ball.y <= paddle.y + 50 // 2)
+
+
 view : Model -> Svg.Svg Msg
 view { ball, paddle } =
     svg

commit

When running the code, you should see shouldBounce: False displayed several times per second until the ball reaches the right paddle, and the message then displaying shouldBounce: True.

It works! We can now use this to update the ball's horizontal speed (its direction) according to the check:

                 shouldBounce =
                     shouldBallBounce model.paddle model.ball
-                        |> Debug.log "shouldBounce"
+
+                horizSpeed =
+                    if shouldBounce then
+                        ball.horizSpeed * -1
+
+                    else
+                        ball.horizSpeed

                 updatedBall =
-                    { ball | x = ball.x + ball.horizSpeed }
+                    { ball
+                        | x = ball.x + horizSpeed
+                        , horizSpeed = horizSpeed
+                    }
             in
             ( { model | ball = updatedBall }, Cmd.none )

commit

Such joy, a mighty ball boucing off a glorious paddle! We're so good! The world is ours! This feeling is why I became a developer in the first place. Feeling invincible, powerful, knowledgeable.

The horror

And at the same time, there's a nagging feeling in the back of my head: how can I make sure that the code is working properly? I mean, most of it is very straightforward, not much complexity. But maybe the shouldBallBounce which seems a bit cryptic.

To make the doubt go away, let's try a few different starting positions for the ball: if it starts at 10, everything seems fine (it doesn't bounce and disappears off screen as expected). If it starts at 400, same thing. What about 200? OH NOES!!!!!!11!1!! It bounces back, even though it's very clearly way above the paddle! Wait, what about 260? OH NOES!!!!!!11!1!! It goes right through the paddle!

 initBall : Ball
 initBall =
     { x = 250
-    , y = 250
+    , y = 260
     , radius = 10
     , horizSpeed = 4
     }

commit

Ok, I'm so bad. I'm worthless. I know nothing about programming. I should stop and switch jobs. Maybe become a shepherd or something.

But first, let's try to find the issue here. I'm glad we tried a few different cases, and caught the issue early, it should be easier to deal with. By the way, that's why people like testing their code with corner cases (either using automated tests, or manual ones).

Let's look at the shouldBallBounce code again:

shouldBallBounce : Paddle -> Ball -> Bool
shouldBallBounce paddle ball =
    (ball.x + ball.radius >= paddle.x)
        && (ball.y >= paddle.y - 50 // 2)
        && (ball.y <= paddle.y + 50 // 2)

Mmmmm... it seems we dealt with the paddle as if its y position was in the center of the paddle. But in SVG, it's the top left of the rectangle! That's why we had to computer the center to display it vertically centered in the game window.

So the correct code should instead be:

 shouldBallBounce : Paddle -> Ball -> Bool
 shouldBallBounce paddle ball =
     (ball.x + ball.radius >= paddle.x)
-        && (ball.y >= paddle.y - 50 // 2)
-        && (ball.y <= paddle.y + 50 // 2)
+        && (ball.y >= paddle.y)
+        && (ball.y <= paddle.y + 50)


 view : Model -> Svg.Svg Msg

commit

Source code up to this point.

This looks way better, if the starting y position of the ball is between 225 and 275 it properly bounces.

We still have the corner case of the ball's center grazing off the paddle (so the ball's y position being for example 224 or 276): the center isn't within the paddle, but the ball's radius being 10 pixels, there's still 9 pixels of the ball clipping through the paddle. We could decide that we instead want the ball to bounce off, but it then looks weird because the hitbox of the ball is a square (we check on the x and the y, not the shortest distance between the ball and the paddle which could be in diagonal.

Anyway, let's decide that this is good enough for now, and an improvement to make in the future!

Also, let's feel good about ourselves again, and maybe even more: we were clever and persistent enough to investigate the bug and fix it! Maybe we can still be working in a programming job after all.

(Yes, this kind of ups and downs are very very common, at least in my case).

Now draw the rest of the owl

(For the reference to this meme, check How to draw an owl)

We've come a long way, but we're still a long way from having a finished pong game! This post being long enough as it is, let's wrap it here.

I might publish a follow up some day, please let me know via email or twitter if you'd be interested.

I've tried something different with the code snippets in this blog post, using the diff format. Did it make it easier to follow? Or worse? It does have the main drawback of not having the elm syntax highlighting. But on the other hand it shows exactly what changes between two code excerpts.

What do you think?

There's now a follow up.

Python et asyncio : la recette du bonheur ?

2016-08-09T10:57:00+02:00

asyncio est une librairie inclue dans la stdlib des dernières versions de python3, et qui permet de faire de la programmation asynchrone.

Oui, ok, mais ça veut dire quoi au juste ?

Asynchrone, concurrent, coroutine, parallèle

Il y a un intrus dans ce titre. Ces termes sont utilisés pour décrire des styles de programmation, mais sont parfois mal compris, ou prêtent à confusion :

asynchrone == concurrent == un seul process, dans lequel plusieurs morceaux de code, les coroutines, s'exécutent l'une après l'autre, dans le désordre, de manière non bloquante (on va y revenir)
parallèle == multiprocessing == plusieurs process se partagent un ou plusieurs morceaux de code, morceaux qui s'exécutent en même temps, sur plusieurs processeurs/cœurs/machines

L'approche asynchrone/concurrente/non bloquante est légere tant à l'implémentation qu'à l'execution - les coroutines sont très peu gourmandes en mémoire et très rapides à lancer. Elles s'exécutent au sein du même process, ont toutes accès à la même zone mémoire et il n'est donc pas nécessaire d'échanger des messages entre elles pour partager des informations. Cependant, elles n'accélèrent pas le programme car il n'y a toujours qu'un seul process. Le programme ne sera donc plus rapide que dans certains cas particuliers. Dans d'autres, il pourra même être plus lent à cause du surcoût de gestion impliqué par l'utilisation de coroutines.

Dans une approche parallèle, le programme s'exécute sur plusieurs process, ce qui l'accélère mécaniquement jusqu'à potentiellement diviser sa durée d'execution par le nombre de coeurs mobilisés. Selon les langages et les libraries utilisées, il est par ailleurs possible de lancer un programme sur plusieurs machines. C'est une approche beaucoup plus lourde tant à l'implémentation qu'à l'éxécution, car il faut lancer, synchroniser et arréter chaque processus, qui en sus demande davantage de mémoire et l'utilisation d'un système de message pour échanger avec ses voisins.

Oui, d'accord, mais comment ça marche ?

Suivant les langages, il y a différentes façons de concevoir l'exécution asynchrone et/ou de faire des appels non bloquants:

en javascript : un appel asynchrone rend la main directement et passe à la ligne suivante. Son résultat est ensuite récupéré par le biais d'un callback.
en clojure ou en go : des canaux sont utilisés pour envoyer et recevoir des messages. Ils sont assimilables à des tapis roulants entre deux morceaux de programmes, l'un qui pose des messages dessus quand bon lui semble, l'autre que les récupère également quand il le peut. Les deux bouts de code sont donc désynchronisés et ne se bloquent pas l'un l'autre.
en python : un appel asynchrone passe par l'utilisation de générateurs, appelées coroutines dans le cas de asyncio. Dans ce cas, on gère explicitement la boucle d'exécution.

Dans le cas de python/asyncio, c'est grâce aux mots-clés await (ou yield from) qu'un bout de code signale à la boucle d'exécution qu'il a temporairement terminé sa tâche. Cette dernière passe donc la main à d'autres bouts de code qui ont quelque chose à faire, au lieu d'attendre séquentiellement (de manière synchrone) que chaque bout de code se termine.

Asynchrone == plus rapide, ou pas...

Mais alors, si le code s'exécute toujours sur un seul et même process et que la gestion des coroutines implique un surcoût de temps de calcul, est-ce que mon programme ne va être plus lent ?!

Petite expérience :

En synchrone/bloquant

import asyncio

def foo():
    pass

for i in range(10000):
    foo()

real    0m0.087s
user    0m0.071s
sys     0m0.013s

En asynchrone/non bloquant

import asyncio

async def foo():
    pass

loop = asyncio.get_event_loop()
for i in range(10000):
    loop.run_until_complete(foo())

real    0m0.452s
user    0m0.429s
sys     0m0.019s

Un rapide calcul indique que la gestion des 10000 coroutines implique un surcoût d'environ 360ms (l'import du module asyncio, qui se fait une seule fois au chargement du programme, a été fait dans les deux cas afin de ne pas fausser les mesures).

Le but de cet exemple aberrant n'est pas de prouver que les coroutines sont lentes (elles ne le sont pas), mais que la programmation asynchrone en elle-même ne fait pas aller n'importe quel programme plus vite (mais ça, vous vous en doutiez).

Asyncio plus rapide pour IO-bound

Mais alors, asyncio ne sert à rien ?

Laissez-moi vous conter l'histoire de Bob, qui veut télécharger toutes les images de chat de son site préféré. Voici un petit morceau de son (pseudo-) code :

for url in urls:
    img = get_image_from_website(url)
    thumbnails = compute_thumbnails(img)
    ...

Le programme va tour à tour télécharger les images sur le site, puis en faire des miniatures. Il y a donc deux cas différents :

le téléchargement de l'image depuis le site, qu'on dit "IO-bound", car limité (lié) par l'IO (l'input-output, entrée sortie, tout échange entre le programme et l'extérieur). Pendant ce téléchargement, le programme va passer la majeure partie du temps à attendre que la requête soit reçue par le serveur distant, puis traitée, puis que les données soient envoyées, puis reçues. Pendant tout ce temps, le programme est bloqué, et ne fait rien d'autre. C'est un appel bloquant.
le calcul de la miniature, qu'on dit "CPU-bound", c'est-à-dire limité (lié) par le CPU, par la puissance de calcul de l'ordinateur, du process qui fait tourner le programme. Aucune attente ici. Plus il y a de puissance de calcul (plus le processeur est rapide, plus il y a de CPU disponible), plus le programme ira vite.

L'idéal serait de pouvoir calculer la miniature d'une image pendant le temps d'attente du téléchargement d'une autre image ! C'est une technique connue depuis bien longtemps dans l'industrie, le "travail en temps masqué" : pendant qu'une machine travaille, l'employé peut faire autre chose, comme remplir le chargeur de la machine, décharger les produits finis, lancer une autre machine, etc...

C'est la grande force de asyncio : pouvoir faire des appels non bloquants, c'est à dire profiter d'un temps d'attente pour pouvoir faire autre chose.

Reprenons notre exemple :

En synchrone/bloquant

import requests
from lxml import html
from PIL import Image

URL_TPL = "http://bonjourlechat.tumblr.com/page/{}"
THUMBNAIL_SIZES = ((100, 100), (200, 200), (300, 300), (400, 400), (500, 500))

def get_image_from_website(url):
    page = requests.get(url)
    # Get the html content as a tree.
    tree = html.fromstring(page.content)
    # Use xpath to get the image url.
    img_url = tree.xpath('//figure//img/@src')[0]
    data = requests.get(img_url, stream=True)
    data.raw.decode_content = True
    img = Image.open(data.raw)
    return img

def compute_thumbnails(img):
    thumbnails = []
    for size in THUMBNAIL_SIZES:
        thumbnails.append(img.thumbnail(size))
    return thumbnails

def get_all_thumbnails():
    for i in range(1, 11):
        img = get_image_from_website(URL_TPL.format(i))
        thumbnails = compute_thumbnails(img)

get_all_thumbnails()

real    0m9.722s
user    0m0.466s
sys     0m0.089s

Soit environ 10 secondes, une seconde par image.

En asynchrone/non bloquant

import aiohttp
import asyncio
from io import BytesIO
from lxml import html
from PIL import Image

URL_TPL = "http://bonjourlechat.tumblr.com/page/{}"
THUMBNAIL_SIZES = ((100, 100), (200, 200), (300, 300), (400, 400), (500, 500))

async def get_image_from_website(url):
    async with aiohttp.ClientSession() as session:
        async with session.get(url) as page:
            # Get the html content as a tree.
            tree = html.fromstring(await page.text())

        # Use xpath to get the image url.
        img_url = tree.xpath('//figure//img/@src')[0]

        # Store the raw image data in a file-like object that Pillow can use.
        memfile = BytesIO()
        async with session.get(img_url) as data:
            memfile.write(await data.read())

    img = Image.open(memfile)
    return img

async def compute_thumbnails(img):
    thumbnails = []
    for size in THUMBNAIL_SIZES:
        thumbnails.append(await loop.run_in_executor(None, img.thumbnail, size))
    return thumbnails

async def get_thumbnail(url):
    img = await get_image_from_website(url)
    thumbnails = await compute_thumbnails(img)


tasks = [get_thumbnail(URL_TPL.format(i)) for i in range(1, 11)]
loop = asyncio.get_event_loop()
thumbnails = loop.run_until_complete(asyncio.gather(*tasks))

real    0m4.139s
user    0m0.795s
sys     0m0.094s

Soit environ 4 secondes, 0.5 seconde par image.

Plusieurs remarques :

dans le cas du code asynchrone, il faut faire bien attention d'utiliser uniquement des appels non bloquants. On utilise donc aiohttp pour récupérer la page et l'image, puis faire les miniatures (en utilisant loop.run_in_executor).
plus le code dans compute_thumbnails sera gourmand en CPU, et sera donc long a exécuter, plus on gagnera en performance sur la version asynchrone par rapport à la version synchrone, le temps de CPU étant "masqué" par le temps du téléchargement des pages et des images.
le code asynchrone est plus long, plus complexe, et nécessite de penser le programme différemment.
le debugging de code asynchrone est également plus complexe (voir ici et là)

Attention aux pièges

import asyncio
import time

async def foo():
    for i in range(10):
        await loop.run_in_executor(None, time.sleep, 1)

loop = asyncio.get_event_loop()
loop.run_until_complete(foo())

real    0m10.137s
user    0m0.079s
sys     0m0.017s

Comment ça, 10 secondes ? Pourtant, les 10 appels à time.sleep(1) semblent asynchrones, non bloquants, concurrents, dans des coroutines qui vont bien ?!

Il y a un piège : dans le code ci-dessus les 10 coroutines sont exécutées les unes après les autres. Il pourrait être réécrit de la façon suivante, qui met bien en valeur le problème :

import asyncio
import time

async def foo():
    await loop.run_in_executor(None, time.sleep, 1)

loop = asyncio.get_event_loop()
for i in range(10):
    loop.run_until_complete(foo())

Lorsqu'une coroutine se lance, on attend qu'elle se termine avant d'en lancer une autre. La façon correcte d'écrire ce code est de lancer toutes les coroutines en même temps avec asyncio.wait() ou asyncio.gather() comme ci-dessous :

import asyncio
import time

async def foo():
    await loop.run_in_executor(None, time.sleep, 1)

loop = asyncio.get_event_loop()
tasks = [foo() for i in range(10)]
loop.run_until_complete(asyncio.wait(tasks))

Asyncio est inutile pour CPU-bound

La programmation asynchrone par coroutines n'est utile que pour les cas IO-bound : lecture/écriture sur le système de fichier, sur un socket...

Il faut imaginer un process comme étant Jean-Michel CPU, employé de Prog-corp, auquel le programme demande d'exécuter une liste de tâches. Si Jean-Michel est déjà surchargé de travail, réarranger ses tâches, les mettre dans le désordre, bloquantes ou non bloquantes, ne changera rien du tout.

Par contre, si Jean-Michel CPU est en train de se tourner les pouces pendant que Bernard IO est en train de trimmer à transporter des paquets de gauche et de droite, alors les choses peuvent être optimisées :

En synchrone/bloquant :

Prog-corp : Bernard IO, j'ai besoin d'un paquet steuplé
Bernard IO : ok, bouge pas, j'y vais
... <un certain temps s'écoule> ...
Bernard IO : pouf pouf, fatiguant tout ça, vla un paquet
Prog-corp : Jean-Michel CPU, tu m'ouvres ça steuplé, tu tries, tu ranges...
Jean-Michel CPU : ok, bouge pas, je m'y met
... <un certain temps s'écoule> ...
Jean-Michel CPU : la vache, y'avait du bouzin, vla j'ai fini
Prog-corp : Bernard IO, un autre paquet steuplé
Bernard IO : ok, bouge pas, j'y vais
... <un certain temps s'écoule> ...
...

En asynchrone/non-bloquant :

Prog-corp : Bernard IO, j'ai besoin d'un paquet steuplé
Bernard IO : ok, je te préviens quand je l'ai
... <un certain temps s'écoule> ...
Bernard IO : pouf pouf, fatiguant tout ça, vla un paquet
Prog-corp : Bernard IO, ok merci, file m'en chercher un autre, kthxbye
Prog-corp : Jean-Michel CPU, tu m'ouvres ça steuplé, tu tries, tu ranges...
Jean-Michel CPU : ok, je te préviens quand je me tourne les pouces
Bernard IO : pouf pouf, fatiguant tout ça, vla un paquet
Prog-corp : Bernard IO, ok merci, file m'en chercher un autre, tu seras bien urbain
Jean-Michel CPU : la vache, y'avait du bouzin, mais c'est bon j'ai fini
Prog-corp : Jean-Michel CPU, ah bah pas trop tôt, voilà un autre paquet
...

Voilà un autre cas qui a l'air d'être IO-bound, sans que ce soit pourtant le cas :

Prog-corp : Bernard IO, j'ai besoin du résultat de cette requête SQL
Bernard IO : ok, je te préviens quand je l'ai
Bernard IO : hop hop, le voilà
Prog-corp : euh, pardon ? Déjà !
Bernard IO : ouais parce que en fait, on dirait pas, mais une database c'est genre ultra méga hyper rapide, tavu
Prog-corp : Bernard IO, ok merci, file m'en chercher un autre, kthxbye
Bernard IO : hop hop, le voilà
Prog-corp : euh, oui, ok, mais euh, deux sec là, je suis occupé
Bernard IO : hop hop, en voilà un autre
Bernard IO : hop hop, tiens, encore un
Prog-corp : Bernard IO, ouais non mais c'est bon, merci, attends un peu steuplé, chuis débordé, et puis Jean-Michel CPU arrive pas à suivre de toute manière
...

Les bases de données sont en général bien plus rapides que n'importe quel programme écrit en python. Si, en théorie, une requête à la base de donnée est une lecture/écriture (Input-Output), dans la pratique sa réponse arrive tellement rapidement qu'il n'y a souvent rien à gagner à l'implémenter en asynchrone. Si la base de données est distante, et que le délai (le round-trip) est long, il est possible d'espérer gagner un peu. En général ce n'est pas le cas (et si ça l'est, vous avez d'autres soucis à régler, en particulier au niveau de la base de donnée elle-même). Pire, on perd le temps de la gestion des coroutines.

La programmation asynchrone est vraiment efficace et utile dans quelques cas notables, comme par exemple les lecture/écriture sur un système de fichier ou sur un socket vers un serveur distant.

Gérer des requêtes entrantes sur un serveur web de manière asynchrones grâce à aiohttp, ou des requêtes à postgresql avec aiopg (probablement inutile, comme vu plus haut ?), ou avec le tout nouveau asyncpg, et plus important que tout, télécharger des photos de chat. Voilà les exemples les plus courants croisés dans les tutoriels.

Certains problèmes sont très pénibles à écrire de manière synchrone/séquentielle, alors qu'ils s'expriment de manière tout à fait logique de manière asynchrone. Par exemple un moteur de jeu : une coroutine qui gère l'affichage en continu, et d'autres coroutines pour récupérer/traiter les entrées du joueur.

Merci à Aurélien G. pour la relecture et réécriture de l'article afin de le rendre plus agréable à lire !

Latence et boucle de rétroaction

2014-07-14T13:56:00+02:00

Latence

La latence en informatique est un délai minimum de transmission. C'est un des principaux ennemis de la performance notamment dans le domaine du web.

Un site web est généralement composé de multiples fichiers statiques (css, javascript, images et icônes en tout genre). Pour afficher la totalité d'une page, il faut donc faire de multiples requêtes au serveur, chacune prenant un certain temps de traitement, à quoi on rajoute la latence (le temps de transfert sur le réseau).

On imagine facilement l'impact d'une forte latence lorsqu'il faut effectuer plusieurs dizaines voire centaines de requêtes. Même si la latence n'est que de 10ms, si on multiple ça par 100, on atteint déjà une seconde.

Prenons un autre exemple : il n'est pas rare d'avoir des pages nécessitant des dizaines (des centaines, voire des milliers ?) de requêtes SQL à une base de données. Là encore, il faut multiplier ce nombre de requête par le temps de traitement par la base de données, mais aussi par la latence.

Étant donné la difficulté de réduire la latence, l'optimisation de la performance passe par le réduction du nombre de requêtes : on fait des bundles pour les fichiers statiques (on regroupe toutes les CSS ou les fichiers javascript, on crée des image map pour les icônes), on fait usage du JOIN pour les requêtes SQL...

Boucle de rétroaction

La boucle de rétroaction (appelée « feedback loop » en anglais) permet de raffiner un système afin d'arriver à un équilibre, à un objectif.

Une boucle de rétroaction basée sur des mesures de position permettra à robot d'atteindre la position souhaitée : la vitesse et la direction seront adaptées en fonction de la distance à l'objectif.

Plus la boucle de rétroaction sera longue, plus l'équilibre sera long a atteindre. En effet, si la mesure de position ne se fait qu'une fois toutes les 10 secondes, soit le robot devra se déplacer très lentement, soit faire de nombreux aller-retours.

Le rapport ?

En tant qu'informaticien, il nous arrive régulièrement d'avoir à raffiner un bout de code en fonction de différents paramètres : l'expression du besoin, la rapidité d'exécution, l'occupation mémoire...

Et ce raffinage se fait par le biais d'une boucle de rétroaction qui peut prendre différentes formes :

des tests automatisés (test unitaires ou fonctionnels, TDD...)
des tests manuels
des simulations
des aller-retours avec l'utilisateur final, le décideur, ...

Si la latence s'invite dans ce mécanisme, on se retrouve dans la même situation que le robot qui doit atteindre une position, mais qui n'a de retour sur sa position que rarement. Soit on avance vite et on risque les aller-retours (comprendre : réécriture du code), soit on avance lentement.

Dans tous les cas, c'est un cauchemar.

Voici quelques exemples de latence :

besoin mal exprimé ou mal compris (la mesure de position n'est pas fiable)
périmètre fonctionnel qui change (la position finale du robot change en cours de route)
grand nombre d'aller-retours avec l'utilisateur final/décideur (nécessité de faire un très grand nombre de mesures de position)
retours de l'utilisateur final/décideur très lents (mesure de position très rare)
dialogue avec une API/base de données/système distant/... très lent (chaque mesure de position demande de très longs traitements)
peu de confiance dans les résultats (nécessité de refaire plusieurs fois les mesures ou de les retraiter)

Un exemple concret

Avec mon collègue David nous nous sommes chargés de la résolution d'un ticket pour le projet AMO.

Afin de pouvoir présenter des graphiques d'utilisation/téléchargement des extensions à leur auteur (comme pour Firebug), toutes les requêtes de téléchargement et de demande de mise à jour sont enregistrées et stockées dans une base de données « big data » (pour les curieux : c'est stocké dans Hadoop et récupéré par le biais de Hive). On parle de plus d'un milliard de requête par jour, toutes requêtes confondues.

Ce qui nous a d'abord paru simple et rapide à implémenter, s'est transformé en deux semaines de sprint (et n'est pas encore terminé).

Nous avons subit et fait partie des différentes formes de latences listées ci-dessus :

besoin mal exprimé ou mal compris : la répartition des tâches entre nous et notre interlocuteur a changé plusieurs fois. Par ailleurs nous n'avions aucune connaissance du système avant de nous y attaquer.
périmètre fonctionnel qui change : malheureusement, arrivé au bout de la première semaine de sprint, nous avons appris qu'il nous fallait refaire la moitié de notre travail différemment suite à des contraintes non prévues.
grand nombre d'aller-retours avec l'utilisateur final/décideur : à l'heure de l'écriture de ce billet, nous en sommes à 54 commentaires sur le ticket.
retours de l'utilisateur final/décideur très lent : nous travaillons en France, et notre interlocuteur sur la côte ouest des USA (-9h). Il est fréquent d'avoir besoin d'attendre le lendemain pour avoir une réponse, dans un sens ou dans l'autre.
dialogue avec un système distant très lent : de par le nombre de données à traiter, chaque requête à Hive (au nombre de 6) prend en moyenne 15 minutes, et la taille des données à télécharger varie entre 500Mo et 1.6Go.
peu de confiance dans les résultats : nous essayions de mettre au point les requêtes Hive à exécuter, et par le même temps, le post-traitement de ces requêtes, pour coller au plus proche aux statistiques et graphiques attendus. Jouer sur deux paramètres en même temps est déjà malaisé en temps normal, mais là il nous était de plus très laborieux de confronter nos résultats avec ceux de la production.

La solution

Diminuer la latence dans la boucle de rétroaction, par tous les moyens possibles.

De la même manière qu'il arrive régulièrement de lancer un interpréteur Python (ou un ipdb ;) pour bidouiller et expérimenter avec un petit bout de code et avoir des retours immédiats, il faut tout faire pour accélérer la boucle de rétroaction.

ça paraît évident, mais connaître précisément le besoin et le contexte avant de se lancer est primordial. Nous avons facilement perdu deux à trois jours à cause de ça, en début de sprint, avec notre envie d'avancer rapidement (et de passer à quelque chose de plus fun ;)
périmètre fonctionnel qui change : difficile de le prévoir ou de l'éviter, mais je pense qu'en ayant une boucle de rétroaction plus courte, nous aurions eu des résultats plus rapidement, et aurions alors plus rapidement rencontré les contraintes qui ont fait changer le périmètre.
le nombre d'aller-retours avec l'interlocuteur, et leur lenteur : quand nous avons pu mettre en place un appel vidéo journalier, beaucoup de choses se sont débloquées.
dialogue avec le système distant très lent : nous aurions dû mock beaucoup plus tôt le retour des requêtes Hive. Nous aurions ensuite dû récupérer un jeu de donnée complet (plusieurs Go) le plus tôt possible pour faire des tests sur le post-traitement dans un premier temps, puis ensuite seulement essayer d'améliorer les requêtes Hive. Faire les deux en même temps est une erreur qui nous a coûté de nombreux appels à Hive (et donc de nombreuses attentes et rétro-pédalages).
peu de confiance dans les résultats : encore une fois vu la taille des données à traiter, il nous était très difficile de confronter nos données à celles attendues (uniquement disponibles en production). Nous avons fini par mettre en production un post-traitement parallèle à l'actuel, et stocker les données dans d'autres tables, en attendant d'avoir la version finale et raffinée de l'algorithme et des requêtes.

Et à ma plus grande honte, ne pas avoir de tests unitaires a été un boulet supplémentaire : lancer un post-traitement pour s'apercevoir 15 minutes plus tard qu'on a oublié une virgule dans le code...

Heartbleed, conséquences pour les utilisateurs

2014-04-09T09:11:00+02:00

Le problème

Hier, le 8 avril 2014, une énorme faille de sécurité a été divulguée, nom de code Heartbleed (plus d'infos sur http://heartbleed.com). Elle impacte OpenSSL, qui est la technologie qui permet de sécuriser les échanges entre notre navigateur et les sites qui utilisent des adresses qui commencent par "https://" (notez bien le "s" final). On estime qu'elle impacte environ 2/3 des sites sur internet.

Ces sites qui utilisent SSL apparaissent avec un petit cadenas à gauche de leur adresse, dans la barre d'adresse de votre navigateur, indiquant que la connexion est sécurisée. C'est par exemple le cas des sites de banque, de mail, mais aussi de la plupart des pages de connexion avec mot de passe, et de paiement par carte bancaire.

Cette sécurité permet de chiffrer toutes les communications entre le navigateur et le site, empêchant quiconque de pouvoir espionner (par exemple en "sniffant" le wifi sur lequel vous êtes connectés) et récupérer vos mots de passe.

Seulement voilà, hier on a appris que cette sécurité comportait un bug logiciel qui permet à n'importe qui de récupérer les mots de passe des utilisateurs et plein d'autres informations sur les sites qui utilisent cette sécurité.

Petite note pour les utilisateurs de Google Chrome : je vous recommande d'utiliser Firefox. Si vous souhaitez continuer à utiliser Chrome, veillez à activer l'option vérifier la révocation du certificat serveur. Malheureusement, Chrome a choisi de ne pas activer cette vérification par défaut pour permettre aux pages de se charger plus vite... au dépends de votre sécurité donc.

Ce qu'il faut faire

La plupart des sites ont dû mettre en place un correctif à présent, en tout cas je l'espère. Pour le vérifier, avant de vous connecter sur un site (n'importe quel site !!!), vérifiez d'abord qu'il n'est pas (ou plus) vulnérable en entrant son adresse sur le site suivant : http://filippo.io/Heartbleed/.

Dans tous les cas, je vous recommande de vous déconnecter et reconnecter sur tous les sites sur lesquels vous êtes déjà connectés, pour être sûr d'avoir la version la plus à jour de leur connexion SSL, puis de changer vos mots de passe (oui, tous). Ça va être long et pénible, mais c'est nécessaire. Faites bien la liste des sites sur lesquels vous vous êtes connectés hier (le 8 avril 2014), et surveillez bien vos comptes sur ces sites, que vous ne voyez rien de bizarre qui pourrait être causé par un pirate qui aurait récupéré vos accès (ajout de bénéficiaires de virement sur votre site bancaire, de nouvelles adresses d'expédition sur les sites de vente en ligne...).

Pour rappel, deux choses qui vous simplifient la vie concernant les mots de passe :

sur Firefox vous pouvez sauvegarder vos mots de passe dans le navigateur, et il faut bien penser à activer le mot de passe général : un mot de passe qui permet de chiffrer tous les mots de passe que vous avez enregistrés, pour que quelqu'un qui récupère votre ordinateur (suite à un vol, parce qu'il est en réparation, en prêt...) ne puisse pas voir tous vos mots de passe enregistrés
sur Firefox il est possible de sauvegarder/synchroniser tous ses mots de passe enregistrés, ses extensions installées, ses onglets ouverts et ses favoris sur un serveur entièrement chiffré et sécurisé de Mozilla en utilisant la fonctionnalité firefox sync, que je vous recommande. C'est très pratique quand on a plusieurs ordinateurs/téléphones/tablettes avec firefox. Faites bien attention de sauvegarder la "clé de récupération Sync" pour pouvoir vous reconnecter à votre compte Sync si jamais vous changez d'ordinateur (c'est un fichier qu'il faut sauvegarder et garder en lieu sûr).
il existe de multiples logiciels de gestion de mots de passe, comme KeePassX, 1password ou revelation (pour linux). Ils permettent d'enregistrer les mots de passe pour tous ses sites, et les sauvegarder dans un fichier chiffré. Il faut bien sauvegarder ce fichier (comme pour la clé de récupération Sync). C'est très pratique pour retenir tous ses mots de passe, en sachant que vous êtes sensé(e)s avoir un mot de passe sécurisé et différent sur chacun des sites que vous fréquentez. Autrement, si un de ces sites se fait pirater, le pirate peut réutiliser votre mot de passe sur tous les autres sites que vous utilisez... Et les sites qui se font pirater chaque année sont légion, et il existe des bases de données publiques de tous les comptes et mots de passe déjà piratés/connus.

Pour terminer, sur les sites qui le proposent, activez l'authentification en deux étapes, comme par exemple sur gmail. C'est une vérification en deux temps lorsque vous vous connectez ou que vous voulez faire une action sensible sur un site. Dans un premier temps vous entrez votre mot de passe (qui aurait pu être piraté), et dans un deuxième temps, vous fournissez un code qui vous a été donné lors de votre connexion par un autre moyen. Par exemple dans le cas de gmail, vous installez une application "google authenticator" sur votre téléphone, qui génère une nouvelle séquence de chiffres chaque minute. Le pirate doit donc avoir votre mot de passe ET votre téléphone si il veut se connecter sur votre compte.

Plusieurs sites bancaires permettent aussi cette authentification en deux étapes.

Allez, c'est maintenant l'heure de changer tous vos mots de passe, courage !

DjangoCon Europe

2014-01-28T08:08:00+01:00

Note

are you an english reader? If so, please scroll down to the english version.

Version française

La communauté Django européenne va se réunir comme chaque année, mais cette année, l'édition de cette grande rencontre va se dérouler en France. Plus précisément, sur une île, l'île des Embiez, dans le var.

DjangoCon Europe (pour les français qui ne le savent pas déjà, DjangoCon est l'abréviation de « Django Conference » en anglais) est un évènement incontournable, qui permet de regrouper plusieurs centaines de participants sur un même lieu, pendant 3 à 5 jours (3 jours de conférences et présentations, 2 jours de sprints).

Pourquoi venir

Ce qui fait notre force, c'est ce qui entretien notre passion du travail bien fait, notre volonté de se former chaque jour un peu plus sur notre outil, notre désir d'en apprendre toujours plus. Et pour cela, quoi de mieux que de se retrouver avec ses pairs, pour échanger et partager sur notre travail au quotidien ?

Ces rencontres permettent de se faire connaître, de faire des connaissances, de trouver de futurs clients, un employeur, ou son prochain collègue de travail.

Elles permettent aussi de se tenir informé des dernières évolutions du langage ou du framework, ou tout simplement de se faire une meilleure idée des cas d'utilisations, des soucis rencontrés et résolus par d'autres, des techniques et astuces à des problèmes de son quotidien.

Et ne vous faites pas d'illusion, vos futurs employeurs, partenaires, clients, ne s'y tromperont pas : un développeur passionné, qui participe à la communauté, aux rencontres, est d'autant plus attirant et intéressant !

Qui doit venir

Cette conférence s'adresse à tous :

les débutants, qui vont en apprendre énormément en quelques jours
les curieux qui auront une bonne vision d'ensemble de l'outil, de son utilisation et des problèmes qu'il permet de résoudre
les confirmés qui trouveront eux aussi leur compte
les indépendants qui peuvent networker et se trouver de futurs partenaires ou clients
les employés qui pourront peut-être trouver leur prochain collègue de travail
les personnes en recherche de travail qui auront une chance de se présenter en personne aux recruteurs, faire connaissance avec leur future équipe
les entreprises qui souhaitent que leurs employés restent à la pointe, se forment en continu
les sponsors qui vont augmenter leur visibilité, se faire connaître des développeurs Django, donner un peu à la communauté qui les fait vivre, trouver plus facilement de futurs employés

Cette conférence, c'est toi

Oui, toi lecteur, on compte sur toi, la communauté compte sur toi. Une communauté n'est rien sans ses membres, une rencontre n'est rien sans ses participants. Non seulement je te demande de venir, parce que j'ai envie de te rencontrer, d'en apprendre plus sur toi, sur ton travail, mais je te demande aussi de participer activement à cette rencontre.

Je te demande de proposer un sujet de conférence.

Pourquoi proposer un sujet

Parce-que c'est bien pour la communauté, pour la rencontre, mais aussi pour toi :

tu es débutant ? Qui mieux que toi peut parler à d'autres débutants, leur faire partager ton expérience, les obstacles que tu as rencontrés, ou les pépites que tu as trouvées au cours de ton apprentissage
tu es confirmé ? Qui mieux que toi peut parler de cette librairie que tu as découverte (ou écrite), de ce qu'elle pourrait apporter aux autres
tu es un expert ? Qui mieux que toi peut présenter une technique avancée, une fonctionnalité méconnue de Python ou Django
tu travaille sur des projets pointus, tu as rencontré des obstacles ou des problèmes que tu as résolus ? Qui mieux que toi peut permettre à ses pairs d'en apprendre plus, partager ton expérience pour qu'elle bénéficie au plus grand nombre

Et si tu n'as encore jamais parlé, présenté, lors d'une rencontre, n'hésite pas, c'est le moment de s'y mettre. Il y a une première fois à tout, et présenter devant cette communauté que je sais être courtoise, compatissante, patiente et encourageante ne peut être que bénéfique et une excellente première expérience.

Et si tu es un orateur confirmé et habitué, n'hésite pas non plus. Nous n'en avons sûrement pas marre de t'entendre, nous n'attendons qu'une chose, c'est qu'une fois de plus tu fasse don de ton temps et de ton expérience.

À très vite

Cette rencontre sera ce que tu y apporte. Inscris toi, propose un sujet, sponsorise. Cette rencontre, c'est toi.

English version

(Thanks a lot Daniele Procida for the translation!)

Once again the European Django community will get together as it does every year, but this year's edition of its great annual gathering will take place in France. More precisely, on an island, the Îsle des Embiez, in the mediterranean department of the Var.

DjangoCon Europe is an unmissable event, that gives several hundred participants a chance to get together in the same place, for 3 to 5 days (3 days of talks and meetings, 2 days of sprints).

Why you should attend

Our strength is nurtured by our passion for a job well done, our eagerness always to become more skilled with the tools of our trade, our desire to learn more. And what could be a better way of doing that than to meet our peers, to exchange and share what we know for the benefit of our daily work.

These conferences provide an opportunity to meet new people, to find new clients, an employer or one's next colleague.

They also provide an excellent way to keep up-to-date with the latest developments in the language or the framework, or simply to acquire a better understanding of its use cases, of problems that others have solved, or tips and techniques that will help on a day-to-day basis.

And don't be under any doubt: your future employers, collaborators, clients will be well aware of what it means: a passionate developer, who takes part in community events, is even more attractive and interesting!

Who should come

This conference is aimed at everyone:

beginners, who'll learn a huge amount in a few days
those eager to learn more, who'll gain an excellent overview of the toolbase, its use and the problems it can be applied to
skilled, who will also find their interest
freelancers, who'll have opportunities for networking, and finding new partners or clients
employees, who may discover their next new co-worker
those seeking new employment opportunities, who'll have a chance to meet recruiters in person, and meet their future colleagues
organisations that need their staff to be at the forefront of developments and always learning
sponsors, who want to increase their visibility, to become better known amongst Django developers, to give a bit back to the community, to find new members of staff

You are this conference

Yes, you the reader - we count on you, the community counts on you. A community is nothing without its members, a conference is nothing without its participants. I invite you not just because I want to meet you, to learn more about you and your work; I ask you to join in and take an active part in this event.

I invite you to propose a talk.

Why propose a talk?

Because it's good for the community, for the conference, but also for you:

are you a beginner? What better than to speak to other beginners, to share with them your experience, the obstacles you encountered, and the secrets you discovered while learning
are you experienced? Who better than you to speak of a library you've discovered (or written), and to explain it to others?
are you an expert? Who better than you to present an advanced technique, a little-known functionality in Python or Django?
you work on specialised projects, you have encountered obstacles or problems and solved them? Who better than you to give your peers a chance to learn something new, sharing your experience so that it benefits the greatest number?

And if you've never spoken or given a presentation to a conference before, don't let that put you off: this is the perfect opportunity to start. There's a first time for everything, and to give a talk to this particular community - one that's known for being welcoming, sympathetic, patient and courteous - will help make sure that it's an excellent experience for you.

And if you're an experienced and regular speaker, don't hesitate either. We're certainly not tired of hearing from you, and we ask of you just one thing: that once more you share what you know with us.

See you soon

This conference will be what you bring to it. Sign up, propose a talk, become a sponsor. This conference: it's you.

Objets ou fonctions

2013-12-16T13:39:00+01:00

Objets ou fonctions ? Voilà une question que je ne me pose pas assez souvent.

De part mon utilisation d'un langage objet (Python), et d'un framework web (Django) basé sur des objets (utilisation d'un ORM, de vues génériques sous forme de classes), je ne me pose quasiment jamais la question : j'utilise par défaut des objets.

Seulement, depuis mes explorations du côté de langages fonctionnels (Clojure, Erlang et Elixir), je me rends compte que la question mérite vraiment d'être posée.

Un exemple concret

Pour le reste de cet article, je vais me baser sur l'exemple concret du jeu de la vie de Conway qui était le sujet de la journée de code retreat à Marseille à laquelle j'ai assisté ce samedi 14 Décembre.

Voici deux implémentations, avec des objets puis avec des fonctions, pour étayer le discours. Je ne prétends pas fournir le code parfait, mais uniquement un support de discussion.

J'ai essayé de reprendre le même code (parcours de la grille, recherche des cellules voisines, calcul de la vie ou mort de la cellule) lorsque c'était possible pour avoir le plus de points de comparaison possibles.

Avec des objets

J'ai opté pour un découpage « raisonnable » (on a fait une session avec un CellContext qui s'occupait de gérer les cellules voisines, au lieu de grouper ça directement dans l'objet Cell, mais je trouvais ça un brin trop over-engineered).

La logique est d'initialiser une fois pour toutes les cellules voisines pour chaque cellule, ce qui simplifie le comptage des voisines en vie.

WORLD = [  # False = dead cell, True = live cell
    [False, False, False, False, False],
    [False, True, False, True, False],
    [False, True, True, False, False],
    [False, False, True, True, False],
    [False, False, False, False, False],
]


class Cell:

    def __init__(self, alive=False):
        self.neighbours = []
        self.alive = alive

    def add_neighbour(self, cell):
        self.neighbours.append(cell)

    def get_num_live_neighbours(self):
        return len([cell for cell in self.neighbours if cell.alive])

    def mutate(self):
        live_neighbours = self.get_num_live_neighbours()
        survives = self.alive and live_neighbours in [2, 3]
        born = not self.alive and live_neighbours == 3
        self.next_state = born or survives
        return self.next_state

    def step(self):
        self.alive = self.next_state

    def __str__(self):
        return 'O' if self.alive else ' '


class World:

    neighbours_rel_pos = [  # relative position of all possible neighbours
        (-1, -1), (-1, 0), (-1, 1),  # upper row
        (0, -1), (0, 1),  # same row
        (1, -1), (1, 0), (1, 1)]  # lower row

    def __init__(self, board):
        self.board = [[Cell(alive) for alive in line]
                      for line in board]

        # initialize neighbours for all cells
        for x, line in enumerate(self.board):
            for y, cell in enumerate(line):
                for neigh_pos_x, neigh_pos_y in self.neighbours_rel_pos:
                    pos_x = x + neigh_pos_x
                    pos_y = y + neigh_pos_y
                    if (pos_x >= 0 and pos_x < len(self.board) and
                            pos_y >= 0 and pos_y < len(self.board[0])):
                        cell.add_neighbour(self.board[pos_x][pos_y])

    def step(self):
        for line in self.board:  # compute next state
            for cell in line:
                cell.mutate()
        for line in self.board:  # apply
            for cell in line:
                cell.step()

    def __str__(self):
        return "\n".join("".join(str(cell) for cell in line)
                         for line in self.board)

67 lignes, 2 objets, 9 méthodes.

Avec des fonctions

WORLD = [  # False = dead cell, True = live cell
    [False, False, False, False, False],
    [False, True, False, True, False],
    [False, True, True, False, False],
    [False, False, True, True, False],
    [False, False, False, False, False],
]


def evolve_world(world):
    new_world = [line[:] for line in world]  # copy the current world
    for x, line in enumerate(new_world):
        for y, cell in enumerate(line):
            new_world[x][y] = evolve_cell(new_world[x][y],
                                          num_alive_neighbours(world, x, y))
    return new_world


def evolve_cell(cell_alive, num_neighbours):
    return ((cell_alive and num_neighbours in [2, 3]) or
            (not cell_alive and num_neighbours == 3))


def num_alive_neighbours(world, x, y):
    neighbours_rel_pos = [  # relative position of all possible neighbours
        (-1, -1), (-1, 0), (-1, 1),  # upper row
        (0, -1), (0, 1),  # same row
        (1, -1), (1, 0), (1, 1)]  # lower row

    count = 0
    for neigh_pos_x, neigh_pos_y in neighbours_rel_pos:
        pos_x = x + neigh_pos_x
        pos_y = y + neigh_pos_y
        if (pos_x >= 0 and pos_x < len(world) and
                pos_y >= 0 and pos_y < len(world[0]) and
                world[pos_x][pos_y]):
            count += 1
    return count


def world_tostring(world):
    return "\n".join("".join("O" if alive else " " for alive in line)
                     for line in world)

43 lignes, 4 fonctions.

Le rôle des données

Avec des objets

En POO, on scinde la donnée d'entrée (base de données, fichiers, flux de données...) pour la répartir dans différents objets. Dans notre exemple, un objet World qui stocke l'ensemble des cellules, et un objet Cell qui stocke son état (en vie ou morte) et l'ensemble de ses voisines.

+ Représentation mentale aisée des différentes entitées
+ Répartition des responsabilités
- Verbosité
- Difficulté pour les tests : il faut gérer les fixtures

Avec des fonctions

En fonctionnel, on traite directement la donnée d'entrée par des étapes successives et différentes fonctions que l'on compose.

+ Concision
+ Moins de code à maintenir, moins de code à lire et comprendre
+ Facilité pour les tests
- Duplication de la donnée (nouveau monde à chaque itération)
- Recalcul des voisins à chaque itération

La réutilisation du code

Dans notre exemple très basique, pas de réutilisation du code. Pas d'héritage pour les objets, pas de composition de fonctions.

Avec des objets

La réutilisation du code dans la POO se fait principalement par l'héritage d'objets.

Imaginons que nous ayons demain un monde différent, qui au lieu d'être représenté par un tableau de cellules carrées, soit un amas de cellules hexagonales. On pourrait alors avoir un objet HexagonalWorld qui hériterait de World et redéfinirait les méthodes __init__ et __str__.

Le reste du code resterait le même, et serait donc réutilisé.

On peut encore imaginer des cellules plus ou moins résistantes qui, en redéfinissant mutate auraient des règles différentes de vie ou de mort.

Avec des fonctions

La réutilisation du code dans la programmation fonctionnelle se fait par la composition de fonctions.

On aurait pu imaginer partir d'un format différent pour le monde, sous la forme d'une suite de 0 et de 1.

On aurait alors tout d'abord transformé chaque 0 ou 1 en booléen puis découpé cette suite en lignes d'une longueur donnée, composant deux fonctions :

data = "001001100"
to_bool(data) == [False, False, True, False, False, True, True, False, False]
to_grid(to_bool(data)) == [
    [False, False, True],
    [False, False, True],
    [True, False, False]]

Si ce n'est pas d'une série de 0 et de 1 qu'on part, mais de X et de O, on change la fonction to_bool, la fonction to_grid reste identique.

La gestion de l'état

Voilà le plus gros point d'achoppement à mon avis, la plus grosse différence entre les langages fonctionnels (plus ou moins purs) et les langages objets : la gestion et le stockage d'un état changeant et les effets de bord.

En programmation fonctionnelle, il n'y a pas de stockage d'un état changeant dans les fonctions. Une fonction retournera toujours le même résultat pour la même donnée en entrée.

Une méthode d'un objet par contre pourra retourner un résultat différent selon l'état stocké dans l'objet. Une méthode is_alive sur un objet Cell retournera True ou False selon l'état de la cellule.

L'avantage d'avoir un état changeant est de pouvoir justement cantonner des morceaux de données dans différents objets, chacun avec ses responsabilités, son domaine d'application. Avec un objet donné, on a toutes les informations nécessaires à la gestion de cet objet, et on peut connaître à tout instant son état actuel.

Le stockage de l'état va souvent de pair avec les effets de bord. Une méthode set_alive sur un objet Cell va par exemple passer cette cellule vivante, mais aussi incrémenter son âge, ou encore incrémenter le compteur du nombre de cellules vivantes de l'objet World.

Les inconvénients sont nombreux :

les fixtures nécessaires pour l'écriture de tests (il faut toujours gérer l'initialisation des objets dans un état connu)
les effets de bord : pas toujours connus, pas faciles à prévoir sans avoir une connaissance parfaite de l'objet et du code
une programmation concurrentielle très complexe : il faut que chaque process soit au courant de l'état, qui doit donc être partagé/géré, ainsi que les effets de bord

Est-ce qu'on s'est trompés ?

Il est communément admis (en tout cas dans mon entourage) que l'utilisation d'objets est plus intuitive, plus facile, plus claire et explicite. Seulement, lors de la code retreat et des différentes sessions, j'ai été confronté à des visions très différentes de mes collègues de pair-programming, par exemple sur le découpage des objets, ou sur leur responsabilité :

est-ce qu'il faut un objet CellContext qui gère le contexte de la cellule, ses voisines
est-ce la responsabilité de la cellule de décider si elle doit vivre ou mourir, ou plutôt celle du monde (ou de l'organisme, selon comment on l'appelle) ? Comment gérer le cas de cellules prédatrices qui tueraient d'autres cellules (ce n'est plus alors à la cellule elle-même de décider si elle doit mourir).
plus de code a écrire prends plus de temps, et pour des sessions de 45 minutes c'est très court, surtout en mode TDD (et on a vu que c'était plus difficile et long d'écrire des tests pour des objets : dans mon cas, 118 lignes de tests)

L'impression que ça m'a laissé est qu'avoir utilisé des objets nous mettait une contrainte supplémentaire, un frein dont on aurait pu se passer.

Alors oui, il y a de meilleures manières d'aboutir au même résultat. Oui, cet exemple trivial n'est que peu représentatif de notre métier de développeur qui est de se frotter à des problèmes beaucoup plus complexes.

Oui, si il y a autant de monde qui fait de la POO, c'est vraisemblablement que le concept n'est pas aberrant. Mais attention à la loi des nombres, ce n'est pas parce que Java et PHP sont les langages les plus courants que je vais me mettre à en (re)faire.

Mais plus j'y pense, et plus je me dis qu'on s'est peut-être trompés. Pour les curieux (et je vous recommande très fortement d'être curieux !), voici quelques liens à voir absolument :

ce qu'aurait pu (dû ?) être la programmation : The future of programming de Bret victor
la programmation concurrentielle, on a plus le choix : Erlang software for a concurrent world de Joe Armstrong (créateur de Erlang)
la simplicité dans la programmation : Simple made easy de Rich Hickey (créateur de Clojure)
pourquoi la programmation fonctionnelle : Why functional programming matters de John Hughes (impliqué dans la création de Haskell)
comment battre la concurrence avec Lisp : Beating the averages de Paul Graham (entrepreneur et capital risque)

Quitter Gmail : gestion des contacts

2013-08-06T09:14:00+02:00

Cet article est le cinquième d'une série sur comment reprendre le contrôle sur son mail, et quitter son fournisseur de mail centralisé.

La gestion des contacts est un peu plus complexe que ce que nous avons pu voir jusqu'à présent.

En effet, il n'y a malheureusement pas de moyen simple, pour le moment, d'avoir les mêmes avantages qu'avec Google.

Il existe tout de même plusieurs stratégies possibles, selon les cas d'utilisation.

Commençons par quelques définitions.

Termes et définitions

vCard

Le standard vCard est un format d'échange de données personnelles, ce qu'on appelle couramment les « contacts ».

Pour exporter ses contacts Gmail dans ce format, et en faire ainsi une sauvegarde, vous pouvez consulter la page d'aide Exportation de contacts Gmail.

Il faut surtout se rappeler d'exporter au format vCard, ce qui stockera tous les contacts dans un fichier avec l'extension .vcf.

CardDav

CardDav est un protocole d'échange de vCard, basé sur le modèle client/serveur.

Cela signifique que pour en profiter, il faut un serveur qui stocke les vCard (les informations des contacts), et les clients peuvent ensuite s'y connecter pour récuperer ces informations, ou les mettre à jour.

On a alors une synchronisation des contacts sur les différents clients (téléphone mobile, Thunderbird sur l'ordinateur...).

Comment

Rapatrier ses contacts

Nous avons vu dans la définition de vCard, qu'il est possible d'exporter tous les contacts de Gmail dans un fichier. Malheureusement, ce fichier n'est pas bien importé par Thunderbird à l'heure actuelle.

Pour information, une refonte complète de la partie gestion de contacts est en cours pour Thunderbird : Ensemble.

En attendant, pour récupérer proprement tous les contacts de Gmail sur Thunderbird, il est recommandé d'utiliser le module complémentaire Thunderbird Google contacts.

Une fois installé dans Thunderbird, il faut le configurer : dans la gestion des modules complémentaires, il y a un bouton à droite du module Google Contacts.

Y rajouter son compte Gmail, est le reste se fera tout seul.

Exporter/importer depuis son téléphone mobile

Voilà une méthode plus laborieuse, mais si les contacts sont rarements mis à jour, c'est la solution la plus simple.

Elle consiste à échanger des fichiers .vcf, en exportant ses contacts d'une source, et les important dans une autre.

iPhone

importer : envoyer le fichier .vcf par mail, l'ouvrir sur son iPhone, et importer tous les contacts
exporter : à ma connaissance un seul moyen si on utilise pas iTunes, l'application MyContactsBackup

Android

Envoyer le fichier sur le téléphone (par exemple par connexion USB, ou par email puis sauvegarde dans le téléphone).

Ensuite ouvrir le carnet d'adresse, puis le menu :

importer : choisir Importer/Exporter » Importer depuis la mémoire
exporter : choisir Importer/Exporter » Exporter vers la mémoire

Tout comme pour l'iPhone, il est possible d'ouvrir directement un fichier .vcf en pièce jointe d'un mail.

Thunderbird

Installer le module complémentaire MoreFunctionsForAddressBook dans Thunderbird. Dans une future version de Thunderbird, la gestion des vCard devrait être plus aboutie, et ne plus nécessiter d'ajout de module complémentaire.

Ensuite, dans le carnet d'adresse, dans le menu Outil » MoreFunctionsForAddressBook » Actions for contacts

importer : sélectionner Import vCard/vcf
exporter : sélectionner Export » as vCard (.vcf)

Synchronisation directe

Elle consiste à connecter son téléphone directement avec l'ordinateur qui fait tourner Thunderbird, et à lancer la synchronisation manuellement.

L'avantage est que les contacts sur le téléphone mobile et sur Thunderbird sont synchronisés dans les deux sens.

L'inconvénient est qu'il faut passer par un logiciel annexe, ou par des modules complémentaires pour Thunderbird, et une application sur son téléphone.

N'ayant pu tester ces solutions, je ne peux les recommander, et elles me paraissent peu fiables et difficiles d'utilisation. Voici néanmoins quelques liens :

Roger4apps : module complémentaire pour Thunderbird et application pour téléphones Android
MyPhoneExplorer : logiciel compatible windows et Android uniquement, qui ne nécessite pas de module complémentaire Thunderbird

Synchronisation par CardDav

C'est la solution la plus pratique et la plus aboutie, celle que vous utilisez probablement déjà à l'heure actuelle.

En effet, les iPhones synchronisent par défaut automatiquement vers iCloud, et les Android vers Google, qui fournissent tous les deux un serveur CardDav.

Voici quelques serveurs CardDav :

OwnCloud : il faut l'installer soi-même, ou "louer" une installation chez un hébergeur
iCloud: https://contacts.icloud.com
Google: ne fonctionne que pour iOS?

iPhone

Il est possible de synchroniser les contacts de son iPhone avec ses contacts Google : Synchroniser les contacts avec votre appareil iOS.

On peut bien entendu utiliser cette même méthode avec n'importe quel serveur CardDav.

Android

Il faut passer par une application tierce : CardDav-Sync.

Thunderbird

Là aussi, il faut passer par un module complémentaire : SOGo Connector.

Il existe un tutoriel pour l'installer et l'utiliser avec OwnCloud, mais on peut l'utiliser pour se connecter à n'importe quel serveur CardDav.

D'après mes tests, par contre, le module complémentaire fonctionne de manière aléatoire, et surtout, ne fonctionne pas du tout avec Google. Il est possible que les décisions récentes de Google d'abandonner les standards ouverts (CardDav, CalDav...) y soient pour quelque chose.

Pour la synchronisation avec google, il faut donc se contenter du module complémentaire indiqué dans le chapitre « rapatrier ses contacts ».

La suite

Ma préférence personnelle va vers l'utilisation d'un serveur CardDav. C'est la seule solution qui me paraît perenne, pratique, et qui égale la facilité de synchronisation de contacts fournie par Google.

Quel que soit le serveur CardDav utilisé, hormis si c'est sa propre installation de OwnCloud ou équivalent, on confie et on donne accès à ses contacts a l'hébergeur, ce qui ne fait que déplacer le problème.

Néanmoins, l'avantage d'avoir ses contacts synchronisés partout est d'avoir autant de sauvegardes.

La solution la plus pratique à l'heure actuelle semble être OwnCloud, qu'il est possible d'installer, par exemple, sur une petite Raspberry-Pi qui consomme très peu, et peut ainsi servir de serveur de sauvegarde personnel à la maison pour un coût réduit.

Quelques projets à surveiller

OwnCloud : serveur CardDav (contacts), CalDav (calendrier), sauvegarde de fichiers (à la Dropbox)
mailpile : projet opensource visant à remplacer le client GMail
caliop : projet naissant visant à fournir des outils et une plateform pour les emails que les utilisateurs puissent utiliser avec confiance
radicale : serveur CardDav et CalDav opensource
yunohost : distribution linux à installer sur un serveur, fournissant une installation facile de OwnCloud, Jappix (réseau social), RoundCube (client mail web)
sovereign : recettes permettant d'installer les logiciels nécessaires sur un serveur pour s'héberger soi-même. Très complet, permet d'avoir son propre serveur mail, son hébergement de site web, OwnCloud, VPN, sauvegarde de fichiers...

Quitter Gmail : migrer ses mails

2013-08-05T19:07:00+02:00

Cet article est le quatrième d'une série sur comment reprendre le contrôle sur son mail, et quitter son fournisseur de mail centralisé.

Pour la plupart des gens, les mails sont stockés sur un serveur de mail, sur une machine chez l'hébergeur.

Changer d'hébergeur revient donc à perdre tous ses mails, à moins de les avoir au préalable tous sauvegardés.

Nous avons vu comment créer son compte mail, mais n'avons pas encore parlé de la migration des mails vers ce nouvel hébergeur, nécessaire à la stratégie courageuse de l'article précédent.

Commençons par quelques définitions.

Termes et définitions

IMAP

Le protocole IMAP permet de consulter ses mails, tout en les laissant sur le serveur, chez l'hébergeur.

L'avantage est double : pour commencer, le message n'est téléchargé qu'au moment de la visualisation, économisant de la bande passante et de l'espace disque (imaginez la réception d'un mail énorme sur un téléphone portable à l'espace limité).

Ensuite, vu que les messages restent sur le serveur, ils sont visualisables depuis n'importe quel appareil à tout moment.

L'inconvénient étant que les messages, stockés sur le serveur, doivent être migrés lors d'un changement d'hébergeur.

Comment

Pour migrer ses mails, Jean va devoir commencer par rapatrier tous ses mails sur son ordinateur. Et pour ça, il va être obligé d'utiliser un client lourd (cf l'article précédent).

Nous allons prendre l'exemple de Thunderbird.

Connecter Thunderbird à Gmail

C'est la partie la plus simple : il suffit de créer un nouveau compte.

Configurer la synchronisation

Il faut ensuite être sûr que le compte nouvellement créé est configuré pour que tous les messages soient conservés sur l'ordinateur.

Pour cela, cocher la case « Conserver les messages de ce compte sur cet ordinateur », comme indiqué sur la page d'aide configurer la synchronisation et l'espace disque.

Rapatrier les mails

Il ne reste plus qu'à passer Thunderbird en mode « hors ligne », pour forcer la synchronisation, ce qui dans notre cas correspond au téléchargement de tous les mails de Gmail.

Le passage en mode hors ligne se fait en cliquant sur la petite icône, tout en bas à gauche de la fenêtre de Thunderbird, dans la barre de statut, ou par le menu Fichier » Hors Ligne » Travailler hors ligne.

Selon le nombre de mails, et leur taille, cela peut prendre un long moment. Pour information, il a fallut pas loin d'une heure pour télécharger un peu plus de 5000 mails, pour une taille totale de 2,23Go, avec une bonne connexion internet.

Transférer sur le nouvel hébergeur

Maintenant que tous les messages sont téléchargés, il ne reste plus qu'à faire un gros copier-coller de tous les messages du compte Gmail vers le compte sur le nouvel hébergeur.

Attention, cette manipulation prendra beaucoup plus longtemps que le téléchargement des mails. En effet, les connexions internet de nos jours sont assymétriques : on télécharge beaucoup plus vite qu'on envoie.

Une fois l'envoi de tous les mails terminés, ils seront accessibles directement par le biais du nouveau compte créé à l'article précédent, celui sur le nouvel hébergeur.

La suite

Si Jean utilise Thunderbird au quotidien, il aura tous ses mails synchronisés entre l'hébergeur et son ordinateur, et donc :

une copie de ses mails sur l'hébergeur
une copie de ses mails sur son ordinateur
une copie de ses mails sauvegardés par ses soins
une étape de moins à exécuter (le rapatriement) lors du prochain changement d'hébergeur
la possibilité de travailler hors ligne

Note

Vous DEVEZ avoir une sauvegarde de tous vos fichiers, pas seulement de vos mails !

Le prochain article abordera la Gestion des contacts.

Quitter Gmail : créer son compte mail

2013-07-31T08:21:00+02:00

Cet article est le troisième d'une série sur comment reprendre le contrôle sur son mail, et quitter son fournisseur de mail centralisé.

Dans cet article nous allons étudier les différentes possibilités et stratégies pour se passer de Gmail pour son adresse mail.

Pour rappel, Jean Dupont, qui utilisait jusqu'à présent son adresse jean.dupont@gmail.com, vient de se procurer un compte mail chez son hébergeur, ainsi qu'un nom de domaine et une adresse jean@dupont.fr qui pointent vers cet hébergeur.

Commençons par quelques définitions.

Termes et définitions

Adresse mail

C'est l'équivalent du numéro de téléphone. C'est ce qui permet d'acheminer les messages au bon endroit.

Il faut donc voir l'adresse mail comme une localisation qui peut changer (le même numéro pourrait être chez SFR un jour, et chez Bouygues le lendemain).

Une adresse email est composée de deux éléments :

jean : la partie précédent le @, la partie variable, qui correspond au compte mail sur le serveur mail
dupont.fr : la partie après le @, qui est le nom de domaine (se référer à l'article précédent), et qui pointe vers un serveur mail

Si Jean le souhaite, il peut modifier dupont.fr pour qu'il pointe sur un autre serveur mail et y créer un nouveau compte, contrairement à l'adresse jean.dupont@gmail.com qui appartient à Google, et qui ne pointera jamais ailleurs que sur les serveurs de Google.

Compte mail

C'est l'équivalent de la boite postale dans lequel le facteur dépose votre courrier. C'est l'endroit où arrivent tous les messages.

Contrairement à la boite postale qui ne sert que temporairement, le temps de récupérer le courrier, un compte mail peut stocker les messages aussi longtemps qu'on le souhaite.

Ce compte est localisé sur un serveur, une machine. En reprenant l'exemple de Gmail, le compte est localisé sur une machine « chez Google ».

À la manière d'un dossier sur un ordinateur, un compte stocke tous les messages reçus, envoyés, supprimés, classés dans des sous-dossiers, déplacés dans les spams...

Client mail

Le programme qui permet de :

lister les messages
lire les messages
écrire des messages
trier, ordonner, classer les messages

Accessoirement, un client permet aussi de gérer les adresses (contacts), mais c'est un autre sujet que nous aborderons dans un futur article de cette série.

Il existe deux grands types de clients :

le client web : un site, comme par exemple http://mail.google.com
- s'utilise sur le port 80, qui est rarement bloqué (dans les hôtels, sur les accès wifi publics, dans les entreprises...)
- ne nécessite pas d'installation de logiciel sur son ordinateur
- ne nécessite pas de configuration (dans le cas où il est fourni directement par l'hébergeur du compte utilisé)
le client lourd : un programme à installer sur son ordinateur, comme par exemple Thunderbird
- sauvegarde les messages sur l'ordinateur
- plus pratique et ergonomique qu'un client web
- peut être utilisé hors connexion : les messages à envoyer sont stockés puis envoyés lors de la prochaine connexion
- n'est pas dépendant d'un hébergeur, et donc tous les mails seront conservés le jour d'un changement

Dans une certaine limite, les clients sont interchangeables. Ainsi, on peut utiliser le client Thunderbird pour accéder à un compte Gmail.

Redirection

Comme un renvoi d'appel ou le suivi de courrier postal : il permet de faire suivre tout le courrier normalement destiné à une adresse vers une autre adresse.

Ainsi, Jean peut décider de rediriger tous les messages destinés à jean@dupont.fr vers l'adresse jean.dupont@gmail.com.

Sauvegarde

Il est possible de conserver plusieurs copies de ses messages, afin d'avoir une sauvegarde en cas de défaillance d'une machine (son ordinateur, la machine de son hébergeur...).

Exemple : l'utilisation d'un client lourd comme Thunderbird permet d'avoir une copie des messages sur son ordinateur, tout en les conservant sur le serveur (sur le compte). On peut alors envisager de sauvegarder ces messages (qui sont stockés sous forme de fichiers sur l'ordinateur) sur un disque USB, un NAS...

Comment

Jean veut avoir le contrôle de la destination de ses messages, afin de pouvoir changer d'avis si il le souhaite. Il va donc faire passer le mot que sa nouvelle adresse est désormais jean@dupont.fr, et non plus jean.dupont@gmail.com.

Par contre, Jean veut toujours recevoir les mails envoyés à jean.dupont@gmail.com, car il y a beaucoup d'entités qui ne connaissent pas encore sa nouvelle adresse, comme les impôts, EDF, ou encore des abonnements à des listes de diffusion...

Avant de rentrer dans le détail, voici les deux stratégies proposées :

timorée : conserver Gmail comme compte principal
courageuse : utiliser son nouveau compte comme compte principal

Ces deux étapes sont indépendantes, et il est tout à fait possible de rester à la première étape, ou encore de passer directement à la deuxième étape.

Le plus important est de pouvoir utiliser sa nouvelle adresse mail, afin d'avoir à minima le contrôle sur la destination des messages.

Stratégie timorée : Conserver Gmail comme compte principal

Cette stratégie est un compromis qui permet de ne pas changer grand chose à ses habitudes quotidiennes, en continuant à utiliser le client Gmail.

L'inconvénient est que Google a toujours accès à tous les messages, et cette stratégie demande plus de configuration.

Rediriger jean@dupont.fr vers jean.dupont@gmail.com

C'est la toute première chose à faire. Sur son hébergeur, Jean va configurer son adresse jean@dupont.fr pour qu'elle redirige tous les messages vers jean.dupont@gmail.com.

Ainsi, dès que quelqu'un écrira à jean@dupont.fr, le message sera automatiquement transféré, relayé, redirigé vers jean.dupont@gmail.com (comme si il avait été destiné à jean.dupont@gmail.com dès le début).

Il accédera alors à ses messages toujours de la même manière, en se connectant sur http://mail.google.com.

Cette redirection devra rester en place tant que la stratégie courageuse ne sera pas mise en place.

Configurer le client Gmail : envoyer les mails de la part de jean@dupont.fr

Par défaut, un client mail envoie tous les mails de la part de l'adresse mail associée au compte sur lequel le client se connecte.

Ainsi, le client Gmail va automatiquement envoyer tous les mails de la part de jean.dupont@gmail.com.

Prenons le scénario suivant :

bill@smith.com envoie un mail à jean@dupont.fr
le mail arrive sur l'hébergeur de Jean, qui redirige le message vers jean.dupont@gmail.com
le mail arrive chez Google sur son compte
Jean consulte le message et y répond
le client Gmail envoie la réponse de la part de jean.dupont@gmail.com
et là Bill répondra à l'adresse Gmail, au lieu de l'adresse jean@dupont.fr

Jean aura beau eu faire part de sa nouvelle adresse, dans les faits, la plupart des messages continueront à être directement envoyés à son adresse Gmail.

Il lui faut donc configurer son client Gmail pour qu'il envoie tous les mails de la part de jean@dupont.fr.

Il y a une page expliquant comment faire cela : Envoi de message avec une autre adresse.

Voici une explication résumée (si vous utilisez Alwaysdata, reportez-vous en fin de cette article pour des captures d'écran explicatives) :

Cliquez sur l'icône représentant une roue dentée en haut à droite de l'écran, puis sélectionnez Paramètres
Cliquez sur l'onglet Comptes
Sous « Envoyer des e-mails en tant que », cliquez sur « Ajouter une autre adresse e-mail »
Dans le champ « Adresse e-mail », saisissez votre nom (Jean Dupont) et l'autre adresse e-mail (jean@dupont.fr), et décochez la case « Traiter comme un alias »
Choisissez l'option « Utiliser les serveurs SMTP de votre autre fournisseur de messagerie »
Entrez les informations de connexion au compte de votre hébergeur
Cliquez sur « Enregistrer les modifications »
De retour dans les paramètres du compte, cliquez sur le lien « utiliser par défaut » à droite de la nouvelle adresse que vous venez de créer
Choisissez enfin, sous « En réponse à un message », l'option « Toujours répondre à partir de l'adresse par défaut (actuellement jean@dupont.fr) »

Suite à ce changement, tous les mails qui seront envoyés à partir du client Gmail seront envoyés de la part de jean@dupont.fr, et donc toutes les personnes qui répondent, répondront directement à cette nouvelle adresse mail.

Tous les mails envoyés à jean@dupont.fr ou à jean.dupont@gmail.com arriverons sur son compte Gmail.

Stratégie courageuse : Utiliser son nouveau compte

Bien qu'il soit théoriquement possible de continuer à utiliser le client Gmail, en le connectant sur le compte de l'hébergeur, dans la pratique ce n'est pas vraiment possible pour des raisons techniques (pour les curieux, le client Gmail ne permet pas de se connecter à un compte externe en IMAP, mais uniquement en POP, ce qui revient à utiliser le compte Gmail, chez Google donc).

Il va donc falloir que Jean utilise un autre client mail, comme par exemple Thunderbird. Il lui faudra le télécharger, l'installer, et le configurer (voir en fin d'article l'exemple de l'hébergement chez Alwaysdata).

Il peut autrement préférer utiliser le « webmail » fourni par son hébergeur (par exemple Roundcube, qui est assez répandu), pour continuer à consulter ses messages directement sur un site internet, sans avoir à installer de logiciel sur son ordinateur.

Afin de continuer à recevoir les mails envoyés à jean.dupont@gmail.com, il va falloir qu'il configure une redirection au niveau de Gmail.

Rediriger jean.dupont@gmail.com vers jean@dupont.fr

Cette redirection se met en place par le biais du client Gmail, et est bien expliquée sur le site du support de Google : Transfert automatique des messages vers un autre compte de messagerie.

ATTENTION : si vous aviez au préalable mis en place une redirection vers l'adresse Gmail, il vous faut à présent impérativement la désactiver. Ainsi, Jean devra désactiver la redirection des mails de jean@dupont.fr vers jean.dupont@gmail.com.

Une fois la redirection mise en place sur son adresse jean.dupont@gmail.com, Jean pourra utiliser son nouveau client pour se connecter à son compte chez son hébergeur.

Tous les mails envoyés à jean@dupont.fr ou à jean.dupont@gmail.com arriverons sur son compte chez son hébergeur.

Conclusion

Et demain ? Si jamais Jean décide de changer d'hébergeur ?

Il lui suffira de configurer son nom de domaine pour qu'il pointe vers le serveur de son nouvel hébergeur (enregistrements MX, se reporter à l'article précédent), puis qu'il y crée un compte pour son adresse mail.

Il lui faudra aussi configurer son client lourd pour qu'il pointe sur le nouveau compte, ou utiliser le client web fourni par son nouvel hébergeur.

Il n'y aura plus à créer de redirection ou à configurer une adresse d'expédition, bref, plus de soucis, tout est sous son contrôle, et aucun besoin de contacter tout son carnet d'adresse pour faire connaître sa nouvelle adresse.

Informations de connexion à un compte hébergé par Alwaysdata

Stratégie timorée

Voici comment configurer le client Gmail pour envoyer les mails de la part de jean@dupont.fr (stratégie timorée) :

Stratégie courageuse

Voici à quoi ressemble la configuration lors de l'ajout d'un compte mail sur Thunderbird :

Alwaysdata fourni aussi un client web (Roundcube) accessible sur https://webmail.alwaysdata.com. Il suffit alors d'indiquer son mail et son mot de passe, aucune autre configuration n'est requise.

La suite

Le prochain article donnera des techniques pour Migrer ses mails.

Quitter Gmail : réserver son nom de domaine

2013-07-30T13:44:00+02:00

Cet article est le deuxième d'une série sur comment reprendre le contrôle sur son mail, et quitter son fournisseur de mail centralisé.

Nous allons voir dans un prochain article comment créer son compte mail, mais cela nécessite d'avoir au préalable son propre nom de domaine.

Commençons par quelques définitions.

Termes et définitions

Hébergeur

Un hébergeur s'occupe d'une machine pour vous. Pour qu'une machine (un serveur) soit accessible à d'autres, pour qu'ils puissent aller sur votre site internet, vous envoyer un mail... il faut que cette machine soit :

correctement configurée
toujours allumée
administrée au quotidien : mises à jour de sécurité, installation de nouvelles version...

Vous pouvez tout à fait vous en occuper vous-même, si vous en avez les compétences, les ressources et le temps nécessaire à y consacrer. Pour la plupart des gens, ce n'est pas le cas, et un hébergeur le fait pour vous.

Un hébergeur va donc vous louer une machine (ou une partie de cette machine), avec différents services :

hébergement de site internet
base de données
stockage de fichiers
compte mail (c'est ce qui nous intéresse plus particulièrement dans le cadre de cette série d'articles)

Certains proposent des packs, comme par exemple Alwaysdata qui propose pour moins de 10€ par mois autant de comptes mails qu'on le souhaite, des bases de données, du stockage de fichiers, de l'hébergement de site web...

Nom de domaine

On peut voir les noms de domaine comme une entrée dans un annuaire, qui fait correspondre un nom à un numéro de téléphone ou une adresse.

Un nom de domaine s'achète auprès d'un registrar (comme BookMyName par exemple) ou d'un intermédiaire, comme un hébergeur qui s'en occupe pour vous.

Selon les extensions (la dernière partie d'un nom de domaine, comme par exemple .fr pour dupont.fr), et selon le registrar ou l'intermédiaire, un nom de domaine coûtera entre 5€ et 15€ par an en moyenne.

Comment

Passer directement par un registrar est moins cher mais nécessite une configuration par le biais de son interface d'administration pour indiquer qui (quel serveur) va s'occuper techniquement de vos emails.

L'intérêt de passer par le biais d'un hébergeur est qu'il n'y a pas besoin de se soucier de cette configuration, et que la gestion centralisée de ce nom de domaine et du compte mail est plus pratique.

Dans tous les cas, le nom de domaine acheté vous est réservé, et vous le faites pointer vers où vous voulez tant qu'il vous est réservé. Vous pouvez par ailleurs décider de transférer la gestion de ce nom de domaine à un autre si vous le souhaitez : Par exemple, Jean peut avoir acheté son domaine chez BookMyName (registrar), et l'avoir transféré par la suite chez Alwaysdata (hébergeur).

Trouver un nom de domaine

La plupart des registrar et des intermédiaires mettent à disposition un outil de recherche sur le nom de domaine et son extension.

Ainsi, Jean pourrait faire une recherche sur "dupont", et voir qu'il y a plusieurs domaines libres :

dupont.fr
dupont.org
dupont.net
dupont.info
dupont.com
ou encore d'autres...

Il peut alors en choisir un, ou plusieurs si il le souhaite. Dans ce dernier cas, il pourra décider de tous les faire pointer vers le même endroit.

Configurer un nom de domaine

Cette étape n'est nécessaire que lorsque le nom de domaine a été réservé par un autre biais que l'hébergeur lui-même.

Voici l'exemple de Jean Dupont qui veut faire pointer son nom de domaine dupont.fr acheté chez BookMyName vers son hébergeur Alwaysdata. Au niveau de l'interface d'administration de BookMyName, il doit rajouter les enregistrements suivants, spécifiques à la gestion des mails (pour un hébergement de site web ce sera différent) :

domain	Type	TTL	Priority	Value
dupont.fr	MX	5	10	mx1.alwaysdata.com
dupont.fr	MX	5	20	mx2.alwaysdata.com

Il faut ensuite se connecter à son compte Alwaysdata, rajouter le nom de domaine, et créer son adresse mail (par exemple jean@dupont.fr).

La suite

Et demain ? Si jamais Jean décide de changer d'hébergeur, de registrar, de serveur de mail ?

Il n'aura plus aucun soucis : il lui suffira de changer la configuration de son nom de domaine pour pointer vers son nouvel hébergeur, vers son nouveau compte mail... Et cela sans impacter qui que ce soit.

Le prochain article expliquera comment Créer son compte mail.

Note

Je n'ai aucun intéressement chez Alwaysdata ni chez BookMyName, si je les prend en exemple c'est que je suis (ou ai été, dans le cas de BookMyName) un client satisfait.

Quitter Gmail

2013-07-30T08:38:00+02:00

Cet article est le premier d'une série sur comment reprendre le contrôle sur son mail, et quitter son fournisseur de mail centralisé.

Les exemples donnés dans cette série d'articles se basent sur Gmail, mais ils sont très largement applicables pour d'autres fournisseurs comme LaPoste.net ou Hotmail.

Cette série est destinée aux personnes n'ayant pas ou peu de connaissances techniques du domaine, et a pour but de permettre à chacun reprendre le contrôle sur une partie de son identité numérique, celle qui a trait à son adresse mail.

Nous allons apprendre ce qu'est un nom de domaine, expliquer la différence entre une adresse mail, un compte mail et un client mail, et donner des stratégies pour se passer de Gmail.

Pour l'histoire, Jean Dupont, qui utilisait jusqu'à présent son adresse jean.dupont@gmail.com, veut dorénavant pouvoir gérer ses mails sans dépendre de Google, et va mettre en place sa propre adresse mail jean@dupont.fr.

Quitter Gmail : Pourquoi ?

À l'heure du cloud, du mail facile et du Gmail si pratique et quasi universel, pourquoi donc vouloir s'en passer ?

Contrôler ses données

De nos jours, il est très facile de se passer de son identité numérique. Ou plutôt, il est très difficile d'en garder le contrôle. Il devient monnaie courante d'abandonner nos données à des services tiers comme Google ou Facebook. On se construit alors son identité sur ces réseaux, sur ces « silos » à données.

Il ne faut pas se leurrer, ce ne sont alors plus nos données : notre identité, tout leur appartient, et tout leur est utile à des fins commerciales. Ces services vont ainsi pouvoir revendre vos données, ou s'en servir pour vous présenter des publicités toujours plus ciblées.

Et que se passe-t-il lorsque ces tiers décident de clore un compte ou d'en censurer un ?

Ou encore si un service doit fermer (comme Google Reader dernièrement) ? Combien de services, parfois très populaires, ont fermé durant ces dix dernières années ?

Et que deviennent vos données, une fois un compte supprimé ? Quelles sont les garanties ?

Avoir le contrôle sur ses données, c'est choisir de ne pas donner accès à cette photographie désavantageuse prise lors d'une soirée trop alcoolisée et qui pourrait nuire lors d'un entretien d'embauche.

Ou encore profiter soi-même des revenus de la publicité sur la génération de son contenu, ou tout simplement le mettre à disposition entièrement gratuitement (comme le contenu de ce blog).

Il est clair que d'avoir son adresse, son compte et son client mail tous au même endroit, fournis par la même entité, c'est bien plus pratique, mais on est alors entièrement dépendant de cette entité : on connaît tous l'adage « Il ne faut pas mettre tous ses œufs dans le même panier ».

Préserver sa vie privée

Si vous pensez que vous n'avez de toute manière rien à cacher, posez-vous cette simple question : où est la limite ? Rien à cacher, ça veut dire qu'on peut venir installer des caméras dans votre chambre à coucher ?

Et fournir l'accès aux données à la NSA, ou automatiquement diminuer la zone « privée », en fournissant toujours plus de vos informations aux autres ?

Je vous recommande la visualisation de cette vidéo : Si, vous avez quelque chose à cacher.

La suite

Le prochain article expliquera comment Réserver son propre nom de domaine.

Au revoir Novapost, bonjour FruitLab

2013-07-22T20:14:00+02:00

Novapost, c'est fini, ou plutôt, mon aventure au sein de Novapost s'est terminée le vendredi 19 Juillet 2013.

J'ai décidé, après moultes et moultes réflexions, questionnements et tergiversations, de saisir une opportunité qui m'était offerte : celle de pouvoir me lancer à mon compte, en créant FruitLab.

Novapost

C'est la larme au coin de l'œil et le trémolo dans la voix que je vais vous parler de mon passage chez Novapost.

La meilleure boite de ma vie.

J'en ai fait plusieurs, consultez mon CV si vous voulez un aperçu (toutes n'y figurent pas), et je peux le dire sans peine et sans hésitation, Novapost a été la meilleure expérience professionnelle que j'ai eu à vivre.

J'en ai un peu parlé dans un précédent article sur la taxonomie des entreprises, Novapost correspond vraiment très bien à mes critères de choix.

Merci à l'équipe

J'ai été recruté par Gregory et Lauréline, que j'avais eu la chance de rencontrer auparavant par le biais des rencontres DjangoFR. J'ai donc été le troisième recruté d'une équipe qui compte maintenant 8 personnes.

La quasi totalité des recrues étaient déjà connues du reste de l'équipe par le biais de ces rencontres, et ça, c'est un confort inouï.

Merci aux collègues

Lors de mes passages dans les locaux, à Paris (je travaillais de chez moi, dans la Drôme), j'ai aussi pu faire la connaissance de la trentaine d'autres employés. Une joyeuse équipe de musiciens, jardiniers en herbe, bons vivants, avec qui j'ai pu partager autour d'un repas dans un bon restaurant, ou troller sur Java/Ruby autour d'une mousse.

Super projet

« Dématérialisation des feuilles de paie ». Pour faire simple, Novapost développe un logiciel en mode SAAS à destination des entreprises qui leur permet de gérer la totalité de leurs documents de manière numérique : éditer, envoyer, partager, stocker les documents de manière électronique, là où il fallait auparavant imprimer, envoyer puis stocker dans des armoires, aux archives...

Une énorme liberté est laissée à l'équipe de développement sur les choix technologiques et d'architecture, ce qui est très appréciable. On se sent maître et responsable du projet, et non un bête exécutant, bon qu'à « pisser du code ».

De plus, les contributions open-source sont encouragées, il suffit de regarder le compte github de Novapost pour s'en rendre compte. Chaque brique du logiciel qui est assez découplée est ouverte, et il est courant de contribuer à des librairies utilisées.

Merci à la direction

Orientée développeurs. Contrairement à la plupart des entreprises dans lesquelles j'ai pu travailler auparavant, je me suis senti faire partie intégrante de l'équipe, être un des maillons de la chaine, avoir de l'importance.

Trop souvent, d'après mon expérience, la direction ne voit les développeurs que comme un poste de coût, qu'il faut limiter le plus possible.

Se sentir considéré, apprécié, choyé même, ça change tout. Voici un aperçu des avantages accordés à l'équipe :

une demi-journée par semaine pour l'open-source
deux conférences par an dont l'entrée est payée
sponsoring de conférences
télétravail
bon fauteuil, bon bureau, bi-écran, matériel récent
séminaire (deux jours dans un château de rêve, activités sportives, repas gastronomiques...)
repas de Noël (avec un cadeau personnalisé, choisi par les deux fondateurs !)

Mais alors pourquoi partir ?

Désolé, aucune révélation sulfureuse ici : j'ai simplement eu la possibilité de me lancer à mon compte, chose qui me démangeait depuis plusieurs années.

L'année dernière, j'ai participé à la TopCodingParty, ou j'ai fait la connaissance de Marc et Manu, les deux développeurs de TopChrétien.

Quelques mois plus tard, j'ai reçu un mail de leur part me proposant une mission de six mois pour refaire entièrement le site, afin de l'uniformiser et d'apporter une cohérence a l'ensemble des fonctionnalités et sites annexes qui ont été développés au fur et à mesure.

Très rapidement, je me suis rendu compte que cette mission serait parfaite pour moi :

travailler pour un projet qui me tient à cœur : répandre la bonne nouvelle
possibilité de me lancer à mon compte, avec 6 mois de travail garanti

FruitLab

Le nom de mon EURL est parti d'une discussion avec Manu du TopChrétien : le projet était parti pour être développé en Symfony, et j'essayais de fournir tous les arguments possibles pour utiliser un framework bien supérieur : Django.

C'est là qu'il m'a dit « ce qui compte, c'est le fruit », le résultat final, et surtout ce que ça va apporter aux utilisateurs. C'est un thème récurrent dans la Bible, et j'ai tellement aimé cette réponse que j'ai cherché un nom en rapport.

D'ailleurs merci à tous ceux qui m'ont fait des propositions de nom (oui, même toi Martyn pour « noix de cocode », et toi Laurent pour « TropiCode » ;).

C'est ma sœur Claire qui a fini par trouver le nom final, à la fois facile à prononcer et à épeler (beaucoup plus que la première idée qui était « CodeJuice »).

Le départ

J'ai eu la chance de pouvoir partir de Novapost en très bons termes. Clément, un des deux fondateurs, m'a très bien reçu, a été très compréhensif, et même encourageant. Il m'a permit de poser des congés durant ma période de préavis, me permettant d'être présent pour le tout début du projet (ce qui a été décisif dans le choix de Django ;).

Voilà maintenant plusieurs semaines que je travaille sur le projet TopVI, sur lequel nous essayons de mettre en œuvre toutes les bonnes pratiques : tests unitaires et rapides, intégration continue, revue de code, pair-programming, contributions open-source...

La suite

Voilà une bonne question : que se passera-t-il dans six mois, vers le début de l'année 2014, à la fin de cette mission ?

Quelques certitudes sur ce que je veux continuer à faire :

participer le plus possibles aux conférences et évènements sur Python et Django
aider à l'organisation de DjangoCon Europe 2014
contribuer à l'open-source, partager

Mais aussi trouver des projets, missions ou partenaires intéressants et qui me permettront de m'épanouir, tout en apportant ma vision de la qualité, et me concentrer sur le résultat final et les fruits qu'ils porteront.

C'est le commencement d'une nouvelle aventure, dont je vous parlerai quand l'arbre aura commencé à donner du fruit ;)

Retour sur Pytong 2013

2013-06-24T10:22:00+02:00

Le 22 et 23 juin, à Toulon, s'est tenue la première édition de Pytong, organisée par Laurent Paoletti et David Larlet (merci à eux !).

Le format a reprit ce dont on a maintenant l'habitude pour les conférences Django organisées par django-fr, une première journée de conférences et barcamps, et une deuxième journée de détente ensemble pour apprendre à mieux se connaître.

Les présentations

Reporting web et print

Arthur Vuillard nous a montré comment utiliser pygal pour faire de jolis reporting web avec de jolis graphes SVG annotés, et weasyprint pour un export en PDF propre, avec gestion des coupures de tableaux, centrage sur la page, etc...

Reporting web et print, les slides.

Tu peux WebTest

Gaël Pasgrimaud, mainteneur de l'excellente librairie WebTest (créée par le prolifique Ian Bicking), nous a expliqué comment l'utiliser pour tester nos applications WSGI. Ça peut avantageusement remplacer le Django Test Client, étant donné ses fonctionnalités avancées, sa facilité d'utilisation, et le fait que ça dialogue directement au niveau WSGI.

Tu peux WebTest, les slides.

Des migrations sans interruption de service

Thomas Chaumeny a listé plusieurs techniques et pratiques, ainsi que les pièges à éviter pour faire des migrations de schéma de données (principalement en utilisant South), et ce sans interruption de service. En effet, selon la migration, les changements dans la base de données peuvent bloquer une table (verrou en écriture) pendant plusieurs minutes, voire heures. Il y a donc certains pièges a éviter, et des méthodes à suivre.

Des migrations sans interruption de service, les slides.

Débuter avec salt

Yann Malet nous a fait une rapide présentation de Salt, un gestionnaire de configuration, un framework d'installation et d'exécution à distance. Pour ceux qui connaissent Chef ou Puppet, Salt est un remplaçant écrit en Python, très performant, car basé sur ZMQ.

Il a ensuite expliqué comment, à LincolnLoop, ils ont utilisé Salt en tant que framework d'exécution à distance pour leur nouveau projet de monitoring : Salmon.

Déprimé, au bord du burn-out, et pourtant il faut continuer à coder

Jean-Michel Armand nous a fait part de son expérience de surmenage, de comment il s'en est sorti, et comment il essaie de ne plus se mettre en danger physiquement et psychologiquement. Un paquet de conseils avisés, à suivre avant qu'il ne soit trop tard.

On dit souvent qu'il faut vivre ses propres expériences pour pouvoir en apprendre, et j'ai moi-même vécu une expérience similaire. Les conseils donnés dans cette présentation sont précieux, et peuvent se résumer à « vous valez mieux que votre code/travail, vivez ».

Déprimé, au bord du burn-out... les slides.

Mezzanine, le CMS des développeurs pragmatiques

Thibault Jouannic nous a parlé de Mezzanine, un CMS simple, performant et facilement extensible, qui permet de répondre à des demandes simples sans avoir à installer un Drupal ou Wordpress.

Use ZMQ and Tornado for fun and profit

Boris Feld nous a donné des recettes pour utiliser ZMQ avec Tornado pour faire le lien avec HTTP.

Use ZMQ and Tornado for fun and profit, les slides.

Écriture d'un livre sur Django

Yohann Gabory nous a parlé de son expérience d'écriture d'un livre sur Django : Django avancé. Il en a profité pour nous expliquer comment écrire une bonne documentation utilisateur, pour lui donner envie d'utiliser notre projet/librairie/application...

Écriture d'un livre sur Django, les slides.

Python dans le navigateur, et pourquoi pas

Jean-Michel Armand nous a fait une démonstration de Brython, vu que toute sa présentation était faite avec. Brython a pour ambition de remplacer JavaScript dans le navigateur par le langage Python.

Python(Script) par Python pour le navigateur

Amirouche Boubekki nous a parlé de son projet PythonScript, une autre alternative à Brython pour avoir du Python dans le navigateur.

JavaScript pour les développeurs Python

Nicolas Perriault a pris à revers les deux précédentes présentations courtes : il explique qu'il est inutile et futile de vouloir remplacer le langage qui a été prévu exprès pour manipuler le DOM et être asynchrone (à base de callbacks), exprès pour être exécuté dans les navigateurs.

Le pragmatisme du développeur Python voudrait justement qu'il utilise les bons outils pour les bonnes utilisations, et donc JavaScript pour du code dans le navigateur.

Développer une app Django

Samuel Goldszmidt s'est servi de l'exemple de son application Django-Select2Light pour montrer comment créer une application Django, en utilisant FloppyForms et TastyPie.

Développer une app Django, les slides.

Utiliser un système de packaging privé

Brice Gelineau nous a expliqué comment il utilisait un système de packaging privé pour son déploiement. C'est encore une autre alternative à l'utilisation de Buildout ou encore le mirroir PyPI privé dont j'ai eu l'occasion de parler lors d'une précédente conférence.

Utiliser un système de packaging privé, les slides.

À quoi ressemblerait mon python ?

Nicolas Dubois s'est demandé comment améliorer encore la lisibilité de nos programmes Python. Il s'avère qu'avec quelques judicieuses modification, et l'utilisation de caractères Unicode par exemple, nous pourrions avoir du code source encore plus concis et expressif.

Il y a peu de chances que nous ayons un interpréteur Python comprenant cette syntaxe un jour, mais je trouve très intéressant de se poser ce genre de questions, et nous avons commencé a écrire « BMC » (Beautify My Code) avec Nicolas, petite librairie (service ?) qui permet d'opérer des changements/remplacements sur un fichier source et d'afficher le résultat. À suivre donc.

À quoi ressemblerait mon python, les slides.

Daybed, une couche de validation pour CouchDB

Antoine Cezar nous a présenté le projet Daybed dont il est un des contributeurs. Cette surcouche à CouchDB, qui ajoute la validation de données, permet d'avoir un remplaçant à GoogleForms.

Daybed, une couche de validation pour CouchDB, les slides.

Les barcamps

Les Web Components

Il y a eu un premier barcamp proposé par David Larlet qui a fait l'unanimité (oui, c'est bizarre d'avoir un seul et unique barcamp, ça s'oppose un peu à la loi des deux pieds) : une présentation des Web Components.

Les Web Components ont à l'heure actuelle deux implémentations : celle de Mozilla avec xtags, et celle de Google avec polymer. Ce sont des composants qui peuvent être entièrement packagés et distribuables : html, css et JavaScript en un seul morceau.

Ça me laisse une sorte d'impression de déjà vu, comment si on revenait aux années sombres des « clients lourds » avec GUI, composants et widgets, etc... je vois néanmoins l'intérêt que ces Web Components apportent alors qu'on déporte de plus en plus de logique et de calcul sur le client, et qu'on cherche à avoir des applications web de plus en plus proches, justement, des applications natives.

Comprendre "this" en JavaScript

Suite à sa présentation courte sur « JavaScript pour les développeurs Python », Nicolas Perriault a indiqué les différentes utilisations et manières de spécifier this en JavaScript, ainsi que les IIFE et use strict.

J'avais déjà eu la chance de me pencher sur l'utilisation de this grâce à un lien que Nicolas m'avait fourni : Learning advanced JavaScript.

Maitriser git

Proposé par Thibault Jouannic, je n'ai pu y participer ayant assisté au barcamp ci-dessus, mais j'en ai eu de bons retours.

La journée détente

Au programme :

plage + baignade : pour les plus courageux, l'eau n'étant pas très chaude, et le vent était assez violent et frais
slackline : première fois pour moi, génial ! J'ai hâte de pouvoir en refaire
repas : bon, convivial, à l'ombre des mûriers platane, vue sur la mer, que demander de plus
jeux de société : Dixit, Pandémie
pétanque
marshmallow challenge animé par Stéphane Langlois.Sympa de voir la rétrospective, sur comment les enfants ont parfois de meilleurs résultats que les jeunes ingénieurs ou commerciaux !

Conclusion

C'est toujours un vrai plaisir de pouvoir rencontrer ses pairs, apprendre d'eux, faire des connaissance, échanger des astuces et techniques. Je pense que c'est un investissement indispensable à tout développeur passionné et curieux qui souhaite évoluer et rester au courant des avancées dans son domaine.

Vous pouvez par ailleurs consulter le compte rendu de Rémy.

Enfin, en petit bonus, je vous met le lien vers la présentation courte que j'avais préparée « au cas où », mais que je n'ai pas eu l'occasion de montrer : Sécuriser ses données.

Retour sur Sud Web 2013

2013-05-24T12:06:00+02:00

Le 17 et 18 mai, en Avignon, avait lieu la troisième édition de Sud Web. C'est une conférence que j'affectionne tout particulièrement, ayant eu la chance de participer à son organisation à ses débuts.

Le format est le suivant : une première journée de présentations, courtes (5mn) et longues (20mn + 5mn de questions), et une deuxième journée d'« élaboratoires ».

Les présentations

Les présentations étaient pour la plupart sous la forme de retours d'expérience. C'est à mon humble avis le format le plus intéressant : en effet, les nouveautés techniques sont pléthores, et les technologies éprouvées sont pour la plupart déjà connues.

Surtout dans une conférence généraliste de la sorte, présenter un point technique très précis et pointu serait une perte de temps pour la majorité de l'audience.

Le client, ce gentil méchant

Une petite piqûre de rappel : pour le client, c'est nous les méchants développeurs. Alors oui, souvent le client doit être éduqué, accompagné, conseillé, et la relation est souvent ardue, mais il ne faut pas oublier que dans l'autre sens c'est vrai aussi : un client doit souvent éduquer et conseiller un développeur, sur les côté produit/besoins.

Il faut en finir avec le dialogue de sourd entre client et développeur, qui nuit aux deux parties.

SASS et Compass ont embelli mon quotidien

Retour d'expérience sur l'utilisation de SASS (et de Compass) par rapport à un seul fichier CSS de plusieurs dizaines de milliers de lignes, impossible à maintenir.

Medhi recommande d'ailleurs une architecture et un découpage des fichiers afin de s'y retrouver plus rapidement, ainsi qu'une bonne documentation des règles écrites : justifier un décalage de 10pixels, expliciter l'utilité d'un mixin, etc...

Nous utilisons déjà SASS et Compass à Novapost, mais il reste un peu de travail au niveau de l'organisation des fichiers et de leur découpage.

Getting touchy : an introduction to touch events

Excellent exposé de Patrick sur les difficultés inhérentes à la gestions des évènements touch sur les différents devices disponibles de nos jours.

Plusieurs soucis à prendre en compte :

la gestion des évènements n'est pas la même sur tous les navigateurs et tous les devices (ordre, nombre, type...)
les hacks peuvent être dangereux. Exemple : il est possible de désactiver le délai sur la détection d'un click (pour augmenter la réactivité et se rapprocher d'une application native), mais attention au fait que ça désactive par la même occasion la détection d'un double-click, le scroll, pinch & zoom...
il y a des devices qui permettent d'utiliser une souris en parallèle du touch, comme certaines tablettes ou ordinateurs portables avec écran tactile. Dans ce cas, il faut réagir aux évènements touch mais aussi mouse

Le développement c'est difficile

En prenant l'exemple de la gestion des dates et fuseaux horaire, Rémi nous montre comment quelque chose qui a l'air simple en apparence, peut contenir des pièges multiples dans lesquels même les plus grands (Apple, Microsoft...) peuvent tomber.

A Novapost, lors du passage en Django1.4, nous avons déjà fait en sorte d'utiliser les fonctionnalités de gestion des fuseaux horaire développées par Aymeric Augustin, et pour l'instant, avec succès. Ce n'est malheureusement pas une solution définitive, à chaque fois qu'on joue avec des dates ou des heures, il faut garder en tête la problématique et bien penser à ce qu'on fait pour ne pas retomber dans le piège.

Aubergine n'est pas une couleur

Si le client vous parle d'une couleur, ne pas hésiter à lui faire confirmer cette couleur par rapport à un référentiel couleur que vous auriez en commun.

L'odyssée de l'espace insécable

Eh non, il n'y a pas qu'un seul et unique espace insécable. Oui, le plus connu est le  , mais il en existe plusieurs autres qui devraient être utilisés en lieu et place de celui-ci. La meilleure solution étant d'automatiser tout ça.

Et si j'écrivais un livre ?

Retour de Corinne sur son aventure personnelle : c'est une expérience qui a l'air attirante, mais qui est parsemée d'embûches, et il faut surtout faire attention à la gestion de son temps, de sa motivation, et des retours faits par les relecteurs.

Quête mystère

La quête de sens, (non-)présentée et animée par David : échange avec le public et entre le public sur diverses questions et thèmes

argent : qui ferait le même métier si il était bien moins bien payé (exemple : payé au smic). Une grande majorité de l'assistance a dit oui, argumentant que beaucoup faisaient de l'open-source (bénévolement), et faisaient leur métier par passion
utilité : la plupart sentent qu'ils ont beaucoup de pouvoir et d'utilité dans leur domaine, mais pas forcément dans leur mission ou emploi actuel
adrénaline : peu de gens ont l'impression de faire ce métier pour l'adrénaline de la mise en production, du débug en prod...
santé : constat alarmant, beaucoup ont des soucis de santé à cause de leur travail. En effet, le propre d'une passion est de prendre toute la place, et beaucoup se retrouvent en manque de sport, avec des soucis de dos, de stress, de burnout

Responsive news : l'actualité mobile à la BBC

Kaelig nous a raconté son expérience à la BBC sur la mise en place de « responsive web design » et leur méthode utilisée : au lieu de gérer les spécificités d'une multitude de devices, ils ont décidé de placer un curseur, et tous les téléphones qui supportent ce minimum de fonctionnalités ont la version avancée (ajax, CSS3), les autres ayant une version statique basique.

La visualisation de données

... comme outil pour découvrir et partager des idées sur le Web. Exposé fort en images et animations de Nicolas, vraiment bluffant.

On se rend compte que la bonne visualisation, selon le besoin, va avoir une vraie valeur ajoutée : découvrir les éléments qui sortent de la moyenne en regardant les directions et forces du vent, mettre en relation/opposition des tweets de candidats à l'élection présidentielle, ainsi que leur impact sur les états...

Certaines autres visualisations sont purement artistiques.

Les super-pouvoirs du nouveau venu

Par votre humble serviteur (je n'ai pas pu assister aux deux présentations courtes précédente, vu que je me préparais en coulisse).

En attendant la vidéo, vous pouvez trouver le support ici.

Le but était de montrer qu'en mettant en place un système de mentorat, une mise en relation entre un ancien et un nouveau, on a tout à y gagner.

Travailler sur ses deux pieds

Considérations sur l'impact négatif sur la santé de travailler en position assise toute la journée. De plus en plus de développeurs optent pour travailler au moins une partie de la journée debout devant leur bureau (surélevé par divers moyens).

Je teste cette méthode depuis plusieurs mois avec bonheur (et un soulagement au niveau du dos). Pour ne pas trop stresser genoux et chevilles, j'alterne régulièrement, passant parfois des jours d'affilée assis, et d'autre debout, ou alternant plusieurs fois dans la même journée.

Monitoring : une culture plus que des outils

Différentes expériences malheureuses ont conduit le journal 20minutes.fr a mettre en place un monitoring très fin des différentes parties de leur système. Ça leur a permis de détecter très tôt (parfois avant même le retour de leurs utilisateurs) de problèmes lors de la mise en production par exemple.

À Novapost nous avons depuis peu trois gyrophares en plus du monitoring par Sentry et New Relic : ils nous permettent de voir de manière ludique quelques indicateurs de notre plateforme.

Comment l'impression 3D va modifier le Web et l'économie

Marc, avocat très versé dans les nouvelles technologies, nous montre comment le futur, c'est maintenant. La répliqueuse de Star Trek, qui nous faisait rêver en étant enfant, devient une réalité avec les imprimantes 3D qui permettent d'imprimer des organes humains, des bonbons, des objets de tout type.

Cela aura obligatoirement un fort impact sur les utilisations, l'économie et la perception des droits d'auteur.

Les élaboratoires

Les élaboratoires sont aussi souvent appelés « barcamps ». Le principe est simple : plusieurs scéances dans la journée, proposées pour certaines avant le jour J, d'autres le jour même, sur différents sujets, problématiques. Le but unique est l'échange entre les participants, et est régi par la règle des deux pieds : si tu n'as rien à apprendre ni rien à apporter, change de salle.

J'y ai appris comme faire des mockups d'applications mobiles, et pourquoi Didier s'est noyé dans son code (enquête en fil rouge tout au long de la journée sur la mise en place de méthodes agiles, l'importance de se soutenir dans une équipe...).

Conclusion

Encore une excellente édition : le plus important, non décrit ici, c'est la possibilité d'échanges, de découvertes et de rencontres durant les pauses, lors des soirées communautaires, tout au long de la journée d'élaboratoires.

Ces échanges et rencontres, ainsi que les présentations, m'ont permis de repartir plein d'énergie, d'idées, d'envies d'expérimentations.

Ce genre de rencontre est à mon sens indispensable à tout développeur pour lui éviter de s'enfermer dans sa cave, de se sur-spécialiser, de perdre le contact avec ses pairs, et par là-même, de devenir obsolète.

Django1.5 : passer au Configurable User Model

2013-04-16T14:13:00+02:00

Depuis la version 1.5 de Django, il est possible d'utiliser un Configurable User Model en lieu et place de django.contrib.auth.User.

Cela permet, par exemple, de se passer de proxy model ou encore de fusionner le profil avec l'utilisateur, pour éviter des join dans les requêtes SQL.

Très pratique, et facile à mettre en place sur un projet qui commence juste, mais comment gérer ça en utilisant South sur un projet déjà bien en place ?

Le but est donc de fusionner l'utilisateur et le profil, avec pour aide/contrainte d'utiliser South, autant sur des plateformes existantes (serveur de production, de pré-production) que sur les plateformes de développement : donc les migrations doivent fonctionner sur une création de base, tout autant que sur une migration simple.

Nous allons détailler plusieurs stratégies.

Contexte

Notre projet utilise depuis longtemps un proxy model sur l'utilisateur, ne rajoutant que quelques méthodes. Toutes les données liées à l'utilisateur sont par ailleurs stockées dans un profil, qui est utilisé par le biais de get_profile() (et le setting AUTH_PROFILE_MODULE).

from django.db import models
from django.contrib.auth.models import User


class RH2User(User):

    class Meta:
        proxy = True

    ...


class RH2UserProfile(models.Model):
    some_field = models.CharField(max_length=50)
    some_other_field = models.BooleanField()

    def some_method(self):
        ...

Le résultat, une fois le profil fusionné avec l'utilisateur :

from django.db import models
from django.contrib.auth.models import AbstractUser


class RH2User(AbstractUser):
    some_field = models.CharField(max_length=50)
    some_other_field = models.BooleanField()

    def some_method(self):
        ...

Ne pas oublier de fusionner les managers, les méthodes save(), et de dédoublonner les champs ayant le même nom (dans notre cas, RH2UserProfile.last_login a été renommé en RH2User.previous_last_login, étant donné que le modèle auth.User d'origine avait déjà un champ last_login).

Il faut par ailleurs rechercher et remplacer le cas échéant toutes les occurrences de :

RH2UserProfile
get_profile()
rh2userprofile__
.user

La problématique

À partir du moment où le paramètre AUTH_USER_MODEL est renseigné :

les tables auth_user, auth_user_user_permissions, auth_user_groups ne sont plus automatiquement crées par un python manage.py syncdb
toutes les migrations South existantes sur des modèles ayant une ForeignKey ou Many to Many ne passerons plus tel quel

Il y a donc principalement deux stratégies pour les migrations South, une fois qu'on a notre modèle RH2User complet (et non plus proxy) ainsi que AUTH_USER_MODEL = 'account.RH2User' dans les paramètres :

Modifier la migration initiale de l'app account, puis toutes les migrations suivantes ainsi que les migrations des app ayant une relation avec l'utilisateur pour qu'elles se basent sur account_rh2user au lieu de auth_user
Rajouter la création de la table auth_user, auth_user_user_permissions et auth_user_groups dans la migration initiale de l'app contenant le modèle complet, puis rajouter une migration qui va renommer la table auth_user en account_rh2user

Dans les deux cas, il faudra être attentif à l'ordre d'exécution des migrations : toutes les applications ayant une relation avec l'utilisateur devront dépendre de la migration initiale qui crée la table auth_user ou account_rh2user.

Dans le deuxième cas, il faudra de plus que la première des migrations suivant le renommage, pour chaque application, dépende de cette migration.

Création de account_rh2user et modification des migrations

Le plus simple est de créer une migration de schéma pour avoir le code nécessaire à la migration 0001_initial de l'application account :

$ python manage.py schemamigration account

Il suffit alors de recopier le code de la migration créée, de le rajouter au fichier account/migrations/0001_initial.py, puis de supprimer cette nouvelle migration qui ne sera pas utilisée.

Il faut ensuite modifier chacune des migrations, en prenant exemple sur ce qui a été fait sur django-oauth2-provider.

Il reste la problématique de la migration des serveurs déjà en production (qui ont déjà un certain nombre de migrations effectuées, et une base de donnée à conserver). Une solution serait de créer une migration de données et de tester l'existence de la table auth_user, et le cas échéant de dupliquer les données dans la table account_rh2user.

N'ayant pas testé cette solution, je ne peux la garantir.

Création de auth_user puis renommage

C'est la solution que nous avons choisi, étant donné le nombre de migrations que nous avons (près d'une centaine), qu'il aurait fallu modifier une à une, ainsi que le soucis de migration des serveurs déjà en production.

Il faut dans l'ordre :

créer les tables auth_user, auth_user_user_permissions et auth_user_groups dans la migration 0001_initial de account
créer une migration dans account qui renomme la table auth_user en account_rh2user
créer une migration dans account qui rajoute les champs du modèle profil à l'utilisateur
créer une migration de données pour dupliquer toutes les données de profil dans la table account_rh2user
pour chaque application ayant une relation vers l'utilisateur, la prochaine migration créée devra dépendre de la migration qui renomme la table

Conclusion

Le plus compliqué dans toute cette histoire est la gestion de dépendances entre les migrations.

Une autre solution non évoquée aurait été de repartir de 0 pour les migrations : supprimer toutes les migrations existantes, ainsi que la table south_migrationhistory, puis reconvertir toutes les applications à South :

$ python manage.py convert_to_south ....

L'avantage est qu'il n'y a alors aucun soucis de dépendances entre les migrations, et qu'on repart de quelque chose de propre.

Les inconvénients sont multiples : gérer une migration (à la main?) pour les plateformes en cours d'utilisation, impossibilité de retourner en arrière automatiquement, perte de l'historique...

Il y a une autre possibilité (à tester !) qui consiste à spécifier l'attribut db_table = 'auth_user' dans la Meta de notre nouveau modèle RH2User, pour qu'il utilise exactement la même table. En théorie, il n'y a alors pas besoin de migration, mais il reste à gérer la fusion du profil dans l'utilisateur.

Le sport

2013-02-26T08:27:00+01:00

Ma vie

J'ai été sportif, voire très sportif, dans ma jeunesse. Étant étudiant, je pratiquais le rugby, le badminton et l'aïkido de manière intensive. Je suis passé par des périodes où je faisais 10h d'entraînement par semaine, tellement ça me plaisait.

Puis un jour j'ai trouvé un travail, et je m'y suis investi à corps perdu (que cette expression est juste, quand on y pense...).

J'étais jeune, motivé, je voulais faire mes preuves, et je ne comptais pas mes heures ni l'énergie que j'y dépensais. Du jour au lendemain, j'ai arrêté toute forme de sport, n'ayant plus de temps à y consacrer.

Par contre, j'ai continué à manger autant. Résultat, +20kg en six mois. Je mesure 1m85, et mon poids de forme doit être aux alentours de 90kg. Je suis monté très rapidement à 120kg.

Par la suite, j'ai essayé de me remettre au sport, épisodiquement, pour reperdre un peu, diminuer le grignotage, mais tôt ou tard je retombais dans les mauvaises habitudes : pas de sport (ou peu, une séance de 2h de badminton par semaine), grignotage.

Et au travail, je ressentais du stress, beaucoup, jusqu'à arriver aux portes du burnout.

En parallèle, j'ai commencé à me détériorer physiquement : j'ai maintenant 34 ans, un tassement des lombaires, des douleurs chroniques dans le dos, la nuque, le genou droit (ménisque intérieur détruit), les chevilles.

Je suis passé par une période de dépression alors que j'ai tout pour faire mon bonheur : une femme merveilleuse qui m'aime, une fille adorable et en bonne santé, un travail intéressant, motivant, bien payé, au sein d'une équipe au top, et d'une équipe de direction axée vers les développeurs (fait assez rare pour être souligné).

La poule ou l'œuf ?

Est-ce le stress au travail qui a engendré mon surpoids et ma mauvaise condition physique ?

Ou est-ce au contraire mon surpoids et ma mauvaise condition physique qui ont engendré du stress ?

Je pense que les deux sont liés, d'une certaine manière, et j'ai décidé de mener l'expérience en agissant sur l'un des deux facteurs : la condition physique.

Le sport, le remède à tous les problèmes ?

Je ne sais pas si c'est la panacée, mais je peux parler de mon expérience.

Un peu avant décembre 2012, je me suis acheté un vélo elliptique, et je me suis décidé à en faire 40 minutes tous les matins au lever, 5 jours par semaine (repos le week-end).

J'en suis au 44ème jour de pratique, et hormis cas de force majeure (cloué au lit par la grippe, en déplacement), je m'y suis tenu sans faute.

Ce que ça m'apporte : j'ai perdu environ 5kg, beaucoup de gras, beaucoup de stress, je me sens détendu la plupart du temps, bien dans mes baskets, mes douleurs chroniques sont moins courantes... d'une manière générale, je me sens en meilleure forme, posé, recentré, capable, plus léger dans mon corps et dans ma tête. Je ne ressens que très rarement le besoin de grignoter (qui était lié à mon stress), je mange moins, plus conscient du mal que je fais à mon corps.

Ce que ça me coûte : me lever 1h plus tôt chaque matin (zut, moins de temps pour m'abrutir devant la télé le soir).

Je suis loin d'avoir regagné mon poids de forme, mais je suis loin d'avoir envie d'arrêter de pratiquer du sport régulièrement, donc tout va bien !

Toi aussi, tu le peux

Longtemps, je me suis trouvé des excuses pour ne pas m'y mettre : pas le temps, pas l'envie, pas la motivation, trop ennuyeux (petite astuce : je me suis procuré une liseuse électronique, et chaque matin je peux maintenant bouquiner pendant 40mn ;).

Quand je vois le gain par rapport à ce que ça me coûte, je regrette de ne pas m'y être mis plus tôt, d'avoir laissé se dégrader ma santé et mon mental pour de faux prétextes.

On entends souvent dire « le travail, c'est la santé », mais on ne peut pas bien travailler sans la santé. La santé, on se la doit, à nous, à notre entourage, à notre employeur, ça ne devrait pas être une option mais un prérequis.

Création d'un FabLab sur Valence

2013-02-07T09:00:00+01:00

Petit message d'annonce : un FabLab s'est créé à Valence, et nous avons eu notre première rencontre ce mardi 5 février, dans les locaux de l'IUT, et plus précisément dans le bâtiment E.

Cette première rencontre concrétise cinq précédentes réunions de motivés :

il y a plusieurs mois, j'ai proposé à Nicolas Chauvat de se faire un afpyro, vu que nous étions tous les deux pythonistes et dans la région. Nous y avons rencontré Gregory Karékinian, qui nous a mis en relation avec le CARA Valence
Nicolas a ensuite assisté à une présentation Open Data au Pôle Numérique où il a rencontré Alexis, et lui a parlé de l'idée du FabLab
le mardi 8 janvier, nous nous sommes retrouvés, avec Nicolas, au CARA, et Nicolas a lancé l'idée d'un FabLab sur Valence, ce qui a immédiatement enthousiasmé Alexis, Collin et Pascal
quelques semaines après, nous nous retrouvions à nouveau autour d'une bière en compagnie de Sébastien, enseignant à l'IUT de Valence
puis ce fût une rencontre au Pôle Numérique avec une bonne douzaine de gens décidés et motivés à se retrouver deux fois par mois

Et voilà comment naquit ce FabLab, partant d'une petite rencontre anodine autour d'une bière. Ce mouvement nous a totalement dépassé pour maintenant appartenir à tout un groupe de passionnés.

Je tiens à remercier chaleureusement Sébastien qui a été un réel moteur pour cette première réunion, qui a engagé toutes les démarches nécessaires auprès de sa direction, ainsi que l'IUT qui nous met à disposition ses salles et son matériel (oscilloscopes, matériel électronique de base, salles de classe...).

Nous étions donc une bonne vingtaine, groupe hétéroclite de gens qui découvrent tout juste l'électronique ou la CAO, des étudiants et des professionnels de différents horizons et spécialités.

Je vous donne donc rendez-vous pour les prochaines rencontres qui ont lieu tous les premiers mardi ainsi que tous les troisièmes mercredi de chaque mois, la prochaine étant le 20 février (je ne pourrai malheureusement pas y assister).

Pour vous inscrire et suivre les différents événements et rencontres :

se créer un compte sur https://veille.pole-numerique.com
rejoindre le groupe fablab
rejoindre la liste de diffusion fablab.valence@librelist.com (il suffit d'y envoyer un premier mail qui ne sera pas envoyé à la liste pour s'y inscrire)

Lancement de FaitMain.org

2013-02-02T08:56:00+01:00

Depuis hier, le tout nouveau magazine faitmain.org est officiellement lancé !

J'ai une affection toute particulière pour ce magazine, non seulement parce que j'y ai (modestement) contribué, mais surtout parce que c'est un domaine (ou plutôt croisement de domaines) qui me parle particulièrement depuis plusieurs années : l'application de l'informatique et de la programmation à notre vie de tous les jours.

Comme on peut le lire dans l'édito, le magazine couvre plusieurs domaines ou sujets :

l'informatique
l'électronique
la cuisine
l'art
l'écologie

Ce qui ne gâche rien, bien au contraire, c'est que tout est open-source et disponible sur github, que ce soit les articles, le raccourcisseur d'url, le moteur de recherche et le moteur même du magazine. N'hésitez pas à y faire un tour, et y contribuer par la création de tickets si vous trouvez un bug, une typo, ou que vous avez une fonctionnalité à proposer !

Ce magazine rejoint quelques unes de mes interrogations et actions de ces derniers mois :

mon goût de plus en plus prononcé pour la domotique
ma passion toujours présente pour la robotique
le projet de création de FabLab sur Valence
ma Raspberry Pi qui trône sur mon bureau et qui me nargue depuis de nombreux mois

Bref, beaucoup d'idées de projets, de motivation et d'enthousiasme. Je vous recommande très chaleureusement la lecture de ce petit bijou réalisé avec amour, et pourquoi pas, pour le second numéro à venir, de proposer un article ?

Djangocon 2012 Tolosa Edition

2012-11-29T08:37:00+01:00

Ce 24 et 25 novembre se tenait la rencontre django-fr [1] locale à Toulouse : DjangoCon Toulouse [2]. Ce fût une fois de plus une réussite pour ces rencontres qui sont le point fort de l'année pour notre communauté.

Pardon

Je tiens tout d'abord à m'excuser pour deux points en particulier :

L'oubli

J'ai un cerveau farceur. Malgré le mail des gentils organisateurs me disant que ma présentation ET mon lightning talk étaient acceptés, je n'ai retenu que la première partie.

Je me suis donc retrouvé le matin même, à quelques minutes de mon LT, à me rendre compte qu'en fait, je devais parler deux fois dans la journée, et que je n'avais strictement rien préparé pour la présentation courte.

Panique, stress, déception, et surtout honte : non seulement l'auditoire allait devoir subir mon absence de préparation (et de slides), mais d'autres propositions avaient été refusées pour que je puisse faire la mienne.

Double manque de respect.

La preuve, si il en fallait une, que j'avais vraiment complètement occulté cette présentation courte, c'est que j'avais fait il y a quelques temps un article sur mon blog pour en parler : Vim + Screen : le pair-prog des champions [3].

La phrase malheureuse

Lors de ma présentation sur Django pour les fainéants, le retour [4], j'ai voulu faire comprendre que, à mon avis, respecter la pep8 [5] faisait partie des bases.

Je l'ai très maladroitement exprimé en disant quelque chose du genre :

« Tout le monde connaît la pep8 j'espère ! Sinon, je suis prêt à lancer des craies dans la salle hein ! »

C'est ce genre de phrase, je pense, qui contribuent et renforcent le sentiment d'élitisme que peuvent ressentir les nouveaux venus. J'en reparlerais un peu plus loin dans ce billet.

Le kif

Autant le dire tout de suite, j'ai kiffé. Comme un djeunz. L'apéro du vendredi soir était très convivial, et m'a permis de croiser des têtes connues ailleurs (ping Sudweb [6]).

Je ne suis pas persuadé que le format « on se rencontre dans un bar » soit idéal, parce que c'est en général très très bruyant, bondé, la musique trop forte, et on s'entend pas hurler à 20cm l'un de l'autre.

C'est peut-être juste mon âge avancé ;)

La journée de samedi s'est passé sans soucis, j'espère que les participants au repas de midi ont apprécié le fondant au chocolat que j'ai aidé Mathieu [7] à faire (j'ai cassé les carreau de chocolat et j'ai beurré le moule, ça compte non ?)

Autant les conférences courtes que les longues ont été de très bon niveau, j'ai appris énormément de choses, et c'est tant mieux, pourvu que ça dure !

C'est agréable de voir des retours d'utilisation, parfois dans de grandes boites dont on avait même pas eu vent jusque là.

Le samedi soir était très sympa, et surtout l'endroit était assez calme pour être propice aux discussions et échanges. Je trouve ça très utile d'avoir des temps morts pour permettre justement aux gens de se rencontrer (après tout, ça s'appelle bien les « rencontres Django-fr »).

Le dimanche avec ses ateliers semi-improvisés étaient je pense un des moments privilégiés pour les rencontres, la possibilité d'échanger directement avec ses pairs sur différents sujets, proposer de l'aide aux nouveaux venus, recevoir des conseils de vieux briscards, échanger sur de bonnes pratiques, ou tout simplement faire connaissance avec de nouveaux visages.

Pistes d'amélioration

En parlant de faire connaissance avec de nouveaux visages, je pense qu'il serait enrichissant et souhaitable que les rencontres Django-fr aident justement à faire des rencontres. Je pense que le format actuel est bon, mais j'aimerais exhorter mes collègues, amis, connaissances actuelles à rencontrer et faire connaissance avec les nouveaux venus.

Il est naturel de se diriger par défaut vers ses amis et connaissances pour échanger des nouvelles, passer du bon temps ensemble... mais cela renforce le sentiment d'exclusion et d'élitisme qui peut être ressenti par les nouveaux venus.

Merci d'ailleurs Fabrice [8] d'avoir osé prendre la parole pour faire part de ta crainte de participer et de poser des questions en étant débutant.

Il est de notre devoir à tous, et je ne parle pas des organisateurs qui ont déjà la vie dure pour faire en sorte que l'événement en lui-même se passe bien, de garder un esprit ouvert et d'accueil.

Je reviens sur ma phrase malheureuse, et c'est typiquement le genre de petite blague qui peut conforter un débutant dans l'idée qu'il ferait mieux de se taire et de ne pas poser de questions tant qu'il n'est pas un peu plus au fait des us et coutumes de la communauté.

Après tout, c'était d'autant plus maladroit que j'ai moi-même utilisé Python pendant de nombreuses années avant même de connaître la pep8 (et je ne parle pas de l'appliquer automatiquement dans tous mes projets).

Conclusion

Je terminerais en remerciant très chaleureusement Mathieu [7], Lauréline [9], Benoit [10] et Nicolas [11] pour l'organisation de cet événement.

C'est grâce à des gens comme vous qu'on peut continuer à se rencontrer, à échanger, et passer un si bon moment.

Encore félicitations pour ce week-end qui se sera écoulé bien trop vite, et vivement la prochaine rencontre [12] !

Ajout (2012-12-10) : les vidéos sont disponibles

[1]	http://django-fr.org

[2]	http://rencontres.django-fr.org/2012/tolosa/

[3]	\|filename\|vim-screen-le-pair-prog-des-champions.rst

[4]	http://mathieu.agopian.info/presentations/2012_djangocon_toulouse/

[5]	http://www.python.org/dev/peps/pep-0008/

[6]	http://sudweb.fr

[7]	(1, 2) http://blog.mathieu-leplatre.info/pages/about.html

[8]	https://twitter.com/FabriceBent

[9]	https://twitter.com/zebuline

[10]	http://www.marmelune.net/

[11]	https://twitter.com/duboisnicolas

[12]	http://forum.django-fr.org/viewtopic.php?id=1306

[13]	http://mathieu.agopian.info/presentation_videos/agopian-pair-programming.mp4

[14]	http://mathieu.agopian.info/presentation_videos/agopian-django-pour-les-faineants.mp4

Taxonomie des entreprises

2012-10-03T17:40:00+02:00

Nous avons vu dans un précédent billet qu'il existait deux principales échelles qu'il était possible de gravir dans la carrière d'un développeur.

Ces deux échelles permettent d'accéder à des types d'entreprise très différents.

Nous allons nous essayer à une taxonomie des entreprises, à une classification selon une liste de critères.

Attention, ce billet est mon point de vue personnel. Ne le prenez donc pas au pied de la lettre, mais plutôt comme un guide pour évaluer une entreprise, pour choisir parmi différents types d'entreprises, celui qui correspondra le plus à l'échelle qu'on a choisi de gravir.

Je vais essayer de rester le plus objectif possible dans l'énoncé des critères, sans laisser transparaître de jugement. En effet, il vous appartient de définir pour chacun des critères, ce qui correspond le plus à vos attentes, à vos souhaits.

Ce billet est long, très très long.

Les critères

Je vois plusieurs critères qui peuvent jouer sur le choix d'une entreprise lorsqu'un développeur est en recherche d'un emploi, de nouveaux horizons, voire même de créer sa boite :

la taille et répartition géographique : nombre d'employés, entreprise locale, nationale, internationale
la visibilité/réputation : quelle image est-ce qu'elle véhicule, quel domaine
le rapport à l'open source : pour, contre, ne se prononce pas, pratique ou non
les perspectives d'évolution : nulles, à l'ancienneté, changement de métier, d'expertise, nécessaire pour évoluer
la paie
technologie : à la pointe ou pas, imposée ou non
l'environnement de travail

Taille et répartition géographique

Plus une entreprise est grande (en nombre d'employés), et avec une répartition géographique large, plus il y a de risques de se retrouver comme un numéro, un employé de plus.

La contrepartie, est de bénéficier de meilleurs avantages : comité d'entreprise plein aux as, plus de marge pour évoluer, changer de service, « monter en grade » (diriger une équipe, nous y reviendrons). Et si il y a des plans sociaux, les indemnités sont en général bien plus importantes, et accompagnées de propositions de requalification, de formation. Il y a aussi un sentiment de sécurité, en se disant que l'entreprise est « too big to fail ».

Au contraire, dans une entreprise de petite taille, il est plus facile de compter, de faire une différence, de se sentir un maillon indispensable de la vie de l'entreprise. Il est aussi plus facile de communiquer sur ce qu'on fait au quotidien, seul ou en équipe, sur sa valeur ajoutée.

Il est par contre plus difficile de négocier une augmentation, un changement de statut, un aménagement du temps de travail, ou toute autre chose qui pourrait entraver la progression de l'entreprise. Mais en général la négociation se fait directement avec l'employeur, et non au travers d'une équipe de ressources humaines.

Visibilité et réputation

Est-ce qu'on préfère une entreprise dynamique ? Stable ? Historique ou jeune et innovante ?

Est-ce qu'on privilégie une entreprise dotée d'une aura de bienfaisance, comme une entreprise qui travaille pour des ONG, pour de l'humanitaire, ou plutôt une entreprise qui représente le pouvoir, financier par exemple, comme une place des marché, une banque, un assureur...

Rapport à l'open-source

Si on cherche à gravir l'échelle de la visibilité, il est important de privilégier une entreprise qui le permette, voire qui l'encourage.

Dans ce domaine, les entreprises peuvent être très différentes :

prédateur : utilise au quotidien des logiciels, serveurs, librairies... open-source, mais ne contribue pas, et interdit à ses employés de contribuer sur le temps de travail, ou sur du code développé par/pour l'entreprise.
neutre : utilise, mais contribue aussi à l'occasion. À l'occasion de la découverte d'un bug dans une application, ou de la création d'une nouvelle librairie, le développeur est autorisé, voire encouragé, à contribuer, y compris sur son temps de travail pour l'entreprise.
moteur : le cœur de métier de l'entreprise est basé sur un logiciel qui est en open-source, par exemple Hybird avec son CRM Crème. Ou encore Mozilla qui a pour crédo « we develop in the open ».

Surtout, se méfier comme de la peste des entreprises qui demandent une forte visibilité lors du recrutement (réclament le compte github/bitbucket/stackoverflow), mais ne contribuent pas, ni ne permettent à leurs employés de contribuer. Ces entreprises profitent de l'open-source, sans qu'il y puisse y avoir de retour. De plus, lorsqu'un développeur voudra la quitter, et trouver un autre employeur, il ne pourra plus présenter de projet récent sur lequel il aura pu travailler.

Oui, il est possible de contribuer et de créer sur son temps libre, mais combien d'heures arrivez-vous à libérer pour ça par semaine, en respectant un bon équilibre travail-vie, en accordant du temps à votre famille et à vous même ?

Perspectives d'évolution

De la même manière, on voit clairement l'intérêt d'avoir des perspectives d'évolution quand on veut gravir l'échelle de l'entreprise.

Il est en effet important de pouvoir changer de poste, monter en grade, diriger une équipe, prendre des responsabilités, dans l'optique de pouvoir se « vendre » lors d'un entretien d'embauche ultérieur.

Tout comme il faut se méfier des entreprises prédatrices de visibilité, il faut se méfier des entreprises qui vont vous demander de justifier de responsabilités ou de management dans votre précédent emploi, pour ensuite vous cantonner dans un poste sans possibilité d'évoluer.

J'ai vécu (très brièvement) cette expérience dans une boite qui promettait monts et merveilles, mais une fois embauché, j'ai vite ressenti le « plafond de verre », celui qui délimite les sous-fifres du dessous, des chefs et patrons du dessus.

Paie

Aspect non négligeable, quoi qu'on en dise, et ce pour au moins deux raisons :

le salaire, c'est en grande partie la valorisation du travail qui est fait
un salaire suffisant permet de se concentrer sur son travail, sans avoir à penser à faire un deuxième travail, s'établir en auto-entrepreneur...

Attention sur ce point glissant. Obtenir un meilleur salaire, c'est aussi subir une plus grosse pression sociale. Si on est mieux payé que X, alors il faut apporter plus de valeur que X. Il n'est pas confortable d'être la personne la mieux payée.

Par ailleurs, un fort salaire peut entraîner un niveau de vie élevé, qui sera comme une prison dorée : il est très facile d'augmenter son niveau de vie, mais le réduire c'est une autre paire de manches. Et trouver une entreprise qui corresponde à ses critères, ET qui propose un salaire au moins aussi élevé, c'est beaucoup plus ardu.

Technologie

La encore, deux écoles.

Je ne le cache pas, je suis fan de Python, de Clojure, et d'autres technos funs et à la pointe. Par contre, je sais que ce n'est pas dans ce domaine que je trouverai le plus de propositions de travail.

Java, PHP sont eux très largement répandus, très utilisés, et donc entraînent automatiquement une très forte demande.

Mais sans même parler de langages, certaines entreprises travaillent et imposent certaines technologies, certains frameworks, librairies, outils, éditeurs.

Quelle est la place laissée aux expérimentations sur d'autres technologies ?

Est-ce que le but est de devenir un expert très pointu sur une technologie précise, ou plutôt un couteau suisse, un touche à tout, un polyvalent ?

Environnement de travail

Le plus gros morceau pour la fin. Ce critère regroupe plusieurs sous critères, qui peuvent bien entendu être séparés en critères à part entière selon leur importance aux yeux du chercheur d'emploi.

Travail seul ou en équipe

Quelle est votre préférence ? Un dicton malien dit « seul on va plus vite, ensemble on va plus loin. »

C'est vraiment une question de goût. Seul, on est plus libre de son travail, mais on est aussi plus sous pression, sans aide, sans recours ni soutient. À plusieurs, on est plus confortable, on peut s'entraider, un sentiment d'émulation peut se mettre en place, une saine compétition. Il y a les revues de code, les discussions au coin de la machine à café, ou autour d'une bière, les coups de main dans les moments de stress ou de détresse, les conseils avisés, la possibilité de faire du pair-programming.

Mais il faut travailler en équipe, et c'est parfois compliqué. Il faut arriver à suivre le travail de chacun, se tenir au courant des modifications, des ajouts de fonctionnalité, il faut négocier, convaincre, écouter, accepter, partager.

Matériel

Ce point est important. Il suffit, pour s'en convaincre, d'écouter l'histoire d'un développeur anonyme : « On m'avait promis un ordinateur portable et un bureau à ma taille. Le premier jour, lors de mon arrivée dans le bureau, j'ai vu mes collègues ramener une table branlante, un pied ne tenant plus que par une vis, et le responsable sortir de la salle serveur avec un écran cathodique 14", un vieux clavier, une souris à boule, et un vieux pentium poussif (un des serveurs). Trois mois après, à la veille de la fin de ma première période d'essai, rien n'avait changé, j'ai démissionné. »

Si vous avez besoin d'une justification comptable pour investir sur du bon matériel de développement, vous pouvez jeter un œil à l'article équipez vos développeurs.

Et sachez, patrons, chefs d'équipe, ressources humaines, ou qui que ce soit qui gère le matériel dans votre entreprise, que ça peut être très humiliant de devoir quémander pour avoir un outil de travail correct. Un chauffeur de taxi ne voudrait pas passer sa journée dans une vieille guimbarde, de la même manière, un développeur ne supportera pas du matériel obsolète, lent, une chaise mal adaptée (pour ceux qui travaillent encore assis ;), un écran de mauvaise qualité...

Perception de la valeur d'un développeur

Quelle est la perception de la valeur d'un développeur dans l'entreprise ? Est-ce qu'il est perçu comme un technicien, un exécutant ? Est-ce que le patron éclate de rire quand on lui explique que le développement, ça s'apparente à un métier créatif ?

Là encore, croyez-en l'expérience d'un développeur pas si anonyme qui a testé pour vous, le patron rigoleur de la vieille école, mais aussi la grosse boite qui classe par ordre d'importance dans la boite :

le patron (logique)
les électroniciens
les opticiens
le bureau d'étude
l'administration
les secrétaires
les développeurs

On obtient alors des choses intéressantes, comme par exemple des ordinateurs trop vieux et obsolètes pour les secrétaires, qui sont offerts au développeurs. Ou encore une négociation de salaire fort surprenante.

Détrompez-vous, ce ne sont pas des cas isolés, et on retrouve malheureusement souvent, surtout en France, surtout dans les boites dirigées par des patrons de la vieille école (comprendre, ceux qui se sont fait avant l'apparition de l'informatique utilisée couramment dans les entreprises), ce genre de réactions.

Et encore plus souvent, le discours suivant : « Des développeurs, on en trouve à la pelle à notre époque. Demain, je peux trouver n'importe quel nouveau diplômé tout frai émoulu, payé une fraction de ton salaire, et qui fera au moins aussi bien que toi. »

Ou encore : « À ton âge, c'est dommage que tu sois encore développeur. Il est temps pour toi d'évoluer, de devenir chef, de diriger une équipe, ou au moins de devenir chef de projet, ou consultant technique. Tu as du potentiel, c'est dommage de le gâcher en restant prostré derrière ton écran toute la journée. C'est bon pour les juniors ça. »

Non, un développeur n'a pas forcément pour vocation de diriger une équipe. C'est un autre métier. De même pour chef de projet, c'est un autre métier. Je ne parle même pas de « technical consultant » ou autre « technico-commercial ».

Un développeur peut tout à fait souhaiter devenir un bon développeur, puis un excellent développeur, et de se perfectionner jour après jour. On trouve facilement (à l'étranger, aux USA en particulier) des développeurs bien mieux payés que leurs chef d'équipe ou chef de projet. Et ça paraît logique, vu que ce sont des métiers différents.

On imagine pas proposer à un mécanicien d'évoluer pour devenir charcutier, ou à un dentiste d'évoluer pour devenir boulanger. Ce sont des métiers différents. Qui demandent des qualités différentes.

Petite astuce : en général, une entreprise qui a un blog technique (comme celui de Novapost par exemple), qui sponsorise des évènements et conférences pour développeurs, qui encourage ses employés à participer à des sprints (en leur offrant les jours de congé)... c'est une entreprise qui accorde une grande valeur à ses développeurs. C'est bon signe !

Prodonfeur/hauteur de la hiérarchie

Plus une entreprise est grande, plus il y a de chances que la hiérarchie soit très profonde. Qu'on se retrouve avec des chefs, des patrons, des responsables, des supérieurs, des boss, des n+1, n+2 et tutti quanti.

D'un côté c'est une opportunité pour quelqu'un qui souhaite prendre des responsabilités : il y a de la place pour se faire son trou, monter dans la hiérarchie petit à petit. D'un autre côté, quand on veut apporter un changement, il faut convaincre non un ou deux supérieurs, mais parfois beaucoup beaucoup plus.

Il y a aussi des entreprises qui ont une hiérarchie très profonde/haute (tout dépends du point de vue), et on se retrouve avec plus de responsables et décideurs que de faiseurs. Rappelez-vous l'histoire du plafond de verre. Il est très désagréable de se retrouver troufion aux ordres d'une pléthore de chefs qui cherchent tous à se faire valoir les uns auprès des autres, qui s'accaparent chaque once de gloire, chaque idée intéressante, chaque accomplissement fait « en bas » pour leur propre avancement et mise en avant.

Même si le grand nombre des niveaux hiérarchiques (rapporté au nombre des employés) n'implique pas forcément une ambiance désagréable, je pense que ça en est un bon indicateur, méfiance !

Aménagement des horaires

Encore une fois, une question de goût.

On peut préférer une grande rigueur sur les horaires, ce qui permet d'être sûr d'avoir les personnes nécessaires à l'avancement de son travail quotidien quand on est au bureau. Exemple : j'ai besoin d'une nouvelle VM, mais pas de bol, il n'est « que » 11h, et le responsable ne sera pas là avant une bonne demi-heure. Ok, il sera là encore très tard ce soir, mais moi, par contre, je serais devant un bon repas, chez moi, en famille, et pendant ce temps, je suis coincé.

D'un autre côté, une plus grande possibilité d'aménagement des horaires est très confortable. Nous ne sommes pas tous productifs au même moment. Je suis du matin, d'autres sont du début d'après-midi, début de soirée, voire pleine nuit.

Ah et puis j'ai un enfant à amener et chercher à l'école, déposer au foot, mais pas de soucis, je rattraperai ce week-end, j'aurai une bonne demi-journée de disponible quand mes enfants seront chez leurs grands-parents.

Ou alors je travaille dans le train (1h30 tous les matins, 1h30 tous les soirs), du coup j'arrive plus tard au travail, et je repars plus tôt, mais je travaille au moins autant !

Possibilité de travailler à distance

J'en parlerai plus largement dans un prochain billet, mais tout le monde n'est pas fait pour le télé-travail.

Cela mis à part, si on souhaite pouvoir travailler à distance un jour ou deux jours par semaine, voire à 100%, est-ce possible ? Est-ce que l'entreprise a l'habitude, et met en place les outils nécessaires pour ça ?

Est-ce qu'elle organise des rencontres et réunions tout au long de l'année pour permettre aux employés travaillant à distance et sur place de se rencontrer, permettre à la cohésion d'équipe de se mettre en place ?

Utilisation des critères pour classifier une entreprise

Yann Malet m'a donné une excellente idée : utiliser des diagrammes radar.

Tout d'abord, faire une liste des critères qui paraissent importants, et les nommer « dans le sens où ils sont importants ». Je vais faire l'exercice pour que vous compreniez bien :

petitesse de l'entreprise : je préfère en général une entreprise à taille humaine. Une trentaine de personnes me paraît être un idéal.
bonne visibilité et réputation : si possible une entreprise qui apporte une vraie valeur, qui fait une différence dans la vie des gens
acteur clé de l'open source : j'accorde beaucoup d'importance à l'open-source, et je veux pouvoir passer du temps à y contribuer
bonne paie
technologie à la pointe : possibilité d'expérimenter de nouvelles technologies
bon environnement de travail : travail en équipe, matériel correct, aménagement des horaires

Dans mon cas, je ne sélectionne aucun des critères suivants :

télé-travail : ce n'est pas un critère que je veux utiliser pour classer les entreprises, c'est un critère indispensable.
perception de la valeur d'un développeur : idem, je ne veux pas (plus) travailler pour une entreprise qui ne comprends pas les spécificités du développement.
Perspectives d'évolution : je n'y attache plus d'importance, sachant maintenant, après avoir fait mes expériences, que ce qui me plait, c'est le développement.

Il ne reste alors plus qu'à en faire un diagramme radar (j'utilise LibreOffice). Voilà celui que j'ai fait pour Novapost, mon employeur actuel :

Diagramme radar pour Novapost

On peut voir que Novapost correspond vraiment bien à mes critères, ce qui est une chance inouïe, pour plusieurs raisons :

je ne connaissais pas Novapost avant d'avoir l'opportunité d'y travailler
je n'avais pas pris conscience des échelles ni des critères au moment d'y entrer
je n'ai pas vraiment gravi la bonne échelle pour y entrer. J'étais vraiment sur l'échelle de l'entreprise, or j'ai été embauché principalement grâce à ma visibilité (j'avais fait la connaissance des membres de l'équipe, coulix et zebuline, lors des conférences djangocong)

Les cas particuliers

Parlons des inclassables. Des entreprises atypiques, qui se classent plus haut que le maximum sur un critère par exemple :

github, connu et reconnu pour son turnover inexistant, et la maximisation du bien-être de ses employés (voir pour cela quelques présentations de Zach Holman)
Lincoln Loop, la boite trop cool qui met en place des techniques révolutionnaires. J'en veux pour preuve certains de leurs articles que je vous recommande pour leur inspiration : The Distributed Workplace, Optimize For Motivation, Everyone Sets Their Own Salary, Open Book Finances. Il y a aussi une foule d'articles techniques de bonne qualité.
Mozilla, cette immense organisation, répartie sur tous les continents, qui a pour but de libérer les usages et les utilisateurs, de fournir du choix, des outils de qualité, et qui a pris le parti de tout faire publiquement, que ce soit les réunions d'équipe accessibles à tout le monde ou tout leur code en open source.
Scopyleft, cette SCOP en cours de création par plusieurs amis, basée sur la coopération et le partage (on y revient ;). J'ai entendu parler de cette initiative il y a quelques temps maintenant par Nicolas Perriault, et depuis, je ronge mon frein et trépigne d'impatience de voir ce projet prendre son essor.

Quand on postule pour ce genre de boites, c'est plus par coup de cœur que suite à une réflexion basée sur une classification et la mise en place de critères. C'est parce que le crédo, l'état d'esprit, la cause, la réputation résonne directement avec nos attentes.

Les critères s'effacent devant un critère en particulier : l'environnement de travail et la liberté des horaires pour github, la perception de la valeur d'un développeur pour Lincoln Loop, l'open source et la réputation pour Mozilla, la coopération et le partage pour Scopyleft.

Conclusion

J'ai fait l'impasse sur plusieurs critères, par exemple est-ce que l'entreprise est à but lucratif ou non (association loi 1901), est-ce qu'elle propose un produit ou des services, est-ce qu'elle est viable financièrement, ou uniquement soutenue par des investissements, quel âge à l'entreprise (plus elle est jeune, plus il y a de risques, mais aussi plus il y a de chances d'avoir une vraie valeur ajoutée ?), etc.

En construisant et listant la liste de ses critères, on voit aussi quels sont ceux qu'on laisse de côté, qui ne sont pas importants. Je n'accorde par exemple plus beaucoup d'importance aux perspectives d'évolution, voulant à tout prix faire du développement, rester développeur. J'ai pu tester d'autres postes par le passé, mais j'en suis toujours revenu. J'ai ça dans le sang ;)

Le but de ce choix de critères, de cette classification, est de pouvoir bien cerner le type d'entreprise qu'on cherche. Et ensuite, de pouvoir en déduire le genre d'échelle qu'il faut gravir.

Dans mon cas, je me rends très clairement compte que je veux travailler pour des entreprises qui valorisent leurs développeurs, qui contribuent à l'open-source, et qui fournissent un bon environnement de travail. Et ce sont des entreprises qui en général recrutent sur la visibilité, beaucoup plus que sur le CV.

Et donc après avoir gravi les échelons de l'entreprise pendant de nombreuses années (2002-2011), je me retrouve à changer d'optique, de point de vue, et de stratégie. On dit bien que « mieux vaux tard que jamais », mais si partager mon expérience pouvait servir à d'autres, tant mieux !

(Qui a dit que le partage était la meilleure des stratégies ? :)

Plan de carrière d'un développeur

2012-10-02T19:53:00+02:00

Le plan de carrière, j'en avais très souvent entendu parler, depuis tout jeune, depuis avant même de savoir que je voulais devenir développeur.

Puis quand j'ai découvert l'informatique, je m'y suis jeté à corps perdu, et j'ai rangé cette notion dans un petit tiroir de mon cerveau étiqueté « inutile pour un développeur ».

C'était bien évidemment une erreur. Ne pas comprendre un concept n'en fait pas un concept inutile.

Je m'adresse ici aux développeurs salariés, et n'aborderai pas la création d'entreprise, n'y connaissant rien.

Le plan de carrière, qu'est-ce que c'est ?

Un plan de carrière, c'est un but à atteindre dans sa vie professionnelle. Ce but peut être multiple, et j'en vois trois principaux :

obtenir plus de responsabilités
devenir un maillon indispensable/incontournable de l'entreprise
devenir un référent technique

Chacun de ces buts permet d'atteindre un idéal qui sera différent pour chacun. Pour l'un ce sera un plus gros salaire, pour l'autre plus de temps libre, plus d'importance (l'entreprise ne pourrait pas tourner sans moi), plus de poids social (je suis le chef de x personnes), plus de sécurité de l'emploi.

Pour atteindre ces buts, il faudra alors utiliser une ou plusieurs échelles, pour reprendre l'image assez répandue de « gravir les échelons ».

Pour un développeur, je perçois deux échelles fondamentalement différentes, que je vais tenter de vous décrire.

L'entreprise

L'échelle la plus visible, évidente, la voie royale. Et pour la gravir, il existe une multitude d'équipements d'escalade appropriés : le chantage, le harcèlement moral, le léchage de bottes, le carriérisme, la prédation, le piston...

Je dresse un tableau caricatural, mais dans chaque caricature, il y a une base de vérité il paraît.

Il existe bien évidemment, et heureusement, des moyens plus nobles et droits d'évoluer au sein d'une entreprise. Le travail acharné, l'implication, la loyauté, donner le meilleur de soi-même, être fiable, ne pas compter ses heures, être agréable et aimable, facile à vivre, bon équipier.

Pour faire part de mon expérience, ayant gravi plusieurs échelons, très rapidement, j'ai aussi fait de mon mieux pour être un moteur, être force de proposition (et de réalisation !).

Et quand on dit qu'un développeur travaille beaucoup en dehors de ses horaires de travail, même en étant loin du clavier (sous la douche, sur la route, dans son sommeil), c'est d'autant plus vrai quand on est investi à 100% dans sa tâche.

Mais après tout, n'est-ce pas normal ? Tout donner à l'entreprise qui nous paie, nous fait vivre, nous permet de nous payer un toit, de quoi manger, se payer du luxe, des vacances...

Dans un sens, oui, ça paraît logique. D'un autre côté, quelqu'un a dit : « je veux travailler pour vivre, et non vivre pour travailler. »

Par contre, il vaut mieux bien choisir son entreprise, et j'en parlerai dans un prochain billet. S'investir, être fidèle, loyal, fiable, et tout donner pour une entreprise, qui en retour, vous aspire sans vergogne, et vous vide petit à petit de votre substance, c'est un danger réel à éviter à tout prix !

La visibilité

C'est l'autre extrême du spectre, l'autre chemin qui passe par le gain de visibilité au sein d'une communauté, ou pour les plus chanceux et doués, au regard de ses pairs d'une manière générale.

Qui parmi vous ne connaît pas Jeff Atwood, Joel Spolsky ou Ward Cunningham, pour ne citer qu'eux ? Ces développeurs de renom se sont fait connaître bien au delà de la communauté de développeurs utilisant le même langage qu'eux.

Sans prendre des exemples aussi extrêmes, la plupart des développeurs Python connaissent les noms d'au moins une dizaine de personnes clé, des contributeurs reconnus, des blogueurs influents, des créateurs de logiciels ou services qu'on utilise au quotidien.

Ces gens là sont visibles. La visibilité peut se faire à plusieurs niveaux, du plus simple au plus difficile :

local : au sein d'une entreprise, d'une équipe, d'un « user group »
communauté : au sein de la communauté des utilisateurs de son langage de programmation, ou du framework, CMS, CRM ou plus généralement outil utilisé au quotidien
global : nationalement, voire même internationalement, être connu et reconnu comme une référence en matière de développement

La visibilité s'acquiert par plusieurs moyens, pouvant être combinés :

contributions open source
création d'un outil utilisé par un grand nombre
blog
participation à des conférences sur son domaine d'expertise, ou mieux, en tant qu'orateur
rencontres, forums, listes de diffusion, salons IRC

Conclusion

Les deux échelles permettent d'atteindre un ou plusieurs des buts listés en début de ce billet, par des chemins différents. Nous verrons dans un prochain billet que choisir l'une ou l'autre des échelles permet d'accéder à différents types d'entreprises.

Attention à toi, jeune développeur, ne fais pas comme moi, ne te réveille pas « trop tard » en te rendant compte que tu as gravi la mauvaise échelle. Il n'est jamais trop tard pour recommencer à gravir « la bonne », mais ça implique de repartir d'en bas !

Certains me diront qu'il est tout à fait possible de gravir les deux en même temps. Je le crois, en effet, mais je doute que ce soit à la portée de tout le monde. Et de la même manière qu'on sait qu'il est impossible pour un cerveau de faire du multi-tâche, je pense qu'essayer de gravir les deux échelles sera non seulement épuisant et difficilement faisable sur le long terme, mais surtout, une échelle sera toujours privilégiée par rapport à l'autre.

D'autres me diront que gravir une échelle fait « gravir des échelons » automatiquement sur l'autre. C'est aussi vrai, mais dans une moindre mesure. Encore une fois, utiliser une échelle se fera généralement au détriment de l'autre.

Le but de ce billet est surtout de faire partager ma prise de conscience tardive. Tant qu'on est jeune, fougueux et plein d'énergie, il vaut mieux se concentrer sur une seule échelle, et le faire consciemment, au lieu de se lancer tête baissée et de potentiellement le regretter plus tard !

Edit : 19h29

Suite à la réponse de David Larlet, j'ai repensé à ce billet, et ma première réaction a été « mais il m'énerve ce David à avoir raison, et l'écrire si bien ! ».

Si vous n'êtes pas encore abonnés à son flux RSS, je ne peut que vous le conseiller, ses billets sont source d'inspiration, très bien écrits, synthétiques et concis à souhait.

Revenons à nos moutons : oui, je pense que le conseil de David de partager est le meilleur qu'on puisse suivre, mais je pense aussi que c'est orthogonal à la pensée initiale de ce billet. Je pense effectivement que la meilleure chose à faire, quelle que soit l'échelle qu'on choisi, c'est de partager, et ce pour toutes les raisons énoncées par David.

Ainsi, sur l'échelle de l'entreprise, on partagera par le biais de formations internes, de discussions à bâtons rompus à la pause café, de conseils donnés ou reçu lors de demande d'aide ou de conseil, de la revue de code.

Sur l'échelle de la visibilité, on partagera en conférences, par des contributions open source, etc.

Par contre, je reste convaincu qu'il existe vraiment deux échelles, chacune menant à une position différente, plus ou moins avantageuse selon le type d'entreprise qu'on vise. Et c'est ce que j'espère montrer et expliquer plus clairement avec le prochain billet sur la taxonomie des entreprises.

Automatiser son flake8 avec vim et syntastic

2012-09-30T11:40:00+02:00

Toi, ami développeur Python, j'espère que tu connais déjà flake8 [1]. Flake8 te permet de valider en une seule fois que ton code Python est propre au regard de pep8 [2] et de pyflakes [3].

Si tu ne connais aucun des trois programmes que je viens de nommer, et que tu n'utilise pas non plus pylint [4], je pense qu'il est temps pour toi d'arrêter de lire cet article, et de te documenter. Au plus vite. Non, en fait, maintenant, là, tout de suite.

Pour les têtes dures, ces utilitaires permettent de valider que le code est compatible avec la pep 0008 [5], qu'il n'y a pas d'erreur de syntaxe, d'import ou de variable inutilisés, etc...

Ils permettent donc d'être sûrs de la qualité de la mise en forme du code (et malheureusement pas de la qualité du code lui-même). Si quelqu'un connaît un outil qui permette de faire ça, je suis preneur : il y a bien l'indice de complexité de McCabe [6] (qui peut être fournie par flake8), mais il ne permet pas de mesurer la qualité totale d'un code. J'imagine que c'est trop subjectif pour être mesuré objectivement.

Je suis trop fainéant

C'est très bien, d'être fainéant. Être fainéant, c'est vouloir se simplifier la vie, en obtenir plus en travaillant moins, c'est un noble but [7].

Et je dois avouer que lancer à la main pep8 puis pyflakes (j'utilisais en fait déjà un plugin Vim pour pyflakes [8]) régulièrement, puis retourner sur le code qu'on pensait avoir fini pour le nettoyer, retrouver la ligne correspondante à chaque erreur, c'était fastidieux.

Flake8 permet de récupérer les erreurs de pep8 et de pyflakes en une seule fois, ce qui est déjà une amélioration. Mais ce n'est pas suffisant, il reste toujours à le lancer manuellement...

Syntastic à notre secours

C'est là qu'intervient notre sauveur : syntastic [9].

Il s'installe en un tournemain avec pathogen [10], que vous devriez utiliser (non, ce n'est pas un conseil, c'est un ordre).

La doc d'installation de syntastic est limpide, et si vous avez flake8 installé, vous n'avez rien d'autre à faire ! En fait, syntastic va utiliser le premier exécutable qu'il trouve parmi flake8, pyflakes et pylint.

Une fois syntastic installé, à chaque sauvegarde de votre fichier, vous verrez une marque apparaître dans la marge de gauche pour chaque violation de règle de formatage.

Il n'y a donc plus aucune raison pour ne pas valider ton code ! Fais toi une faveur, ainsi qu'à ceux qui devront relire ta prose.

[1]	https://bitbucket.org/tarek/flake8

[2]	https://github.com/jcrocholl/pep8/

[3]	https://launchpad.net/pyflakes

[4]	http://www.logilab.org/project/pylint

[5]	http://www.python.org/dev/peps/pep-0008/

[6]	https://fr.wikipedia.org/wiki/Nombre_cyclomatique

[7]	http://agopian.info/djangocong/dplf.html

[8]	http://www.vim.org/scripts/script.php?script_id=2441

[9]	https://github.com/scrooloose/syntastic

[10]	https://github.com/tpope/vim-pathogen

Vim + Screen : le pair-prog des champions !

2012-09-26T08:43:00+02:00

Le pair-programming [1] fait partie des bonnes pratiques du développement, ce n'est plus à prouver : il permet de produire un code de meilleure qualité, mieux pensé et construit.

On entend souvent dire qu'il est (deux fois) moins productif, vu qu'on est deux à produire un seul morceau de code, mais dans la pratique, il permet au contraire d'éviter des pièges ou bugs qui auraient pris un temps fou à résoudre.

Un autre avantage est de pouvoir mettre le pied à l'étrier d'un autre développeur sur son code, tout en douceur et efficacement. Ou encore de partager la paternité, la connaissance et l'expertise sur une base de code, entre plusieurs développeurs.

Et d'une manière générale, c'est tellement plus sympathique et agréable de pouvoir réfléchir à deux, discuter, échanger, se conseiller mutuellement !

Bref, comme je le disais, les mérites du pair-programming ne sont plus à prouver.

Mais comment en profiter quand on travaille à distance ? Je pense par exemple aux personnes en télé-travail, ou qui veulent participer à des sprints à distance.

Tu l'as deviné (facile, c'est dans le titre), grâce à VIM (ou tout autre éditeur en ligne de commande, comme par exemple l'autre dont on ne saurait prononcer le nom), le logiciel screen [2], tout ça sur SSH.

Je te fais ici un résumé de ce qui a été très bien expliqué dans un article du blog de Siyelo [3], adapté, simplifié et automatisé à ma sauce.

Installer un serveur SSH

Pour ça, tu es bien gentil, mais je pense que tu vas y arriver tout seul comme un grand.

Si nécessaire, pour que ton collègue distant puisse se connecter en local, rajoute donc une règle de redirection sur ton routeur/ta box , par exemple du port externe 22222, en TCP, vers le port 22 de l'adresse IP de ton ordinateur.

Note

Il existe un logiciel très pratique pour gérer ses règles de redirection sans avoir à se connecter à l'interface de sa box : portmapper [4] (Korben [5] en parle d'ailleurs très bien).

Installer screen

Là encore, rien de bien compliqué.

screen permet de multiplexer plusieurs shells. C'est aussi lui qui va rendre possible de se connecter à plusieurs sur un seul et même shell, celui par exemple qui lancera l'éditeur. Cela permet donc dans la pratique de pouvoir éditer un fichier à plusieurs, et de voir instantanément toutes les modifications.

Configurer

L'idée est simple : un utilisateur local (que l'on nommera pair) va lancer le screen, sur lequel tu pourra te connecter. Il suffira ensuite de donner le mot de passe de ce compte à ton collègue distant, pour qu'il s'y connecte en ssh, puis se connecte lui aussi à ce screen.

Cet utilisateur pair sera donc utilisé pour programmer, voire même commiter le code, avec éventuellement un ~/.gitconfig ou ~/.hgrc avec un nom évocateur du genre pair-benoit-mathieu, afin que les commits puissent être directement attribués aux bonnes personnes.

Pour créer ce nouvel utilisateur :

sudo adduser pair

Enfin, toute la configuration de screen est mise dans un fichier .screenrc à la racine du compte :

hardstatus on
hardstatus alwayslastline
startup_message off
termcapinfo xterm ti@:te@
hardstatus string "%{= kG}%-w%{.rW}%n %t%{-}%+w %=%{..G} %H %{..Y} %m/%d %C%a "
term screen-256color

multiuser on
acladd <ton user>  # user allowed to connect

Prends bien soin de remplacer <ton user> par ton utilisateur, afin que lorsque le screen soit lancé, tu puisse t'y connecter.

Utiliser

Lance un screen sur l'utilisateur pair en mode détaché :

sudo -u pair screen -d -m -S pairprog  # -S nomme la session

Connecte toi au screen de cet utilisateur :

screen -x pair/pairprog
# une fois connecté au screen
vim
# créer une nouvelle fenêtre dans le screen : <ctrl-a c>
# passer à la fenêtre suivante : <ctrl-a n>
# passer à la fenêtre précédente : <ctrl-a p>
# passer à la fenêtre 1 : <ctrl-a 1>
# détruire la fenêtre courante : <ctrl-a k> ou <ctrl-d>

Si tu es un vrai bon fainéant comme moi, tu aura bien sûr sauté sur l'occasion d'en faire un alias dans ton ~/.bashrc.

Indique l'utilisateur pair et son mot de passe, ton adresse IP et le port de connexion SSH à ton collègue pour qu'il puisse te rejoindre :

ssh pair@<ip de ta box> -p 22222
screen -x pairprog  # alias pair='screen -x pairprog'

Petite astuce de sioux, pour que l'utilisateur distant n'ai même pas besoin de se connecter manuellement au screen (ni même à lancer l'alias), à rajouter au ~/.bashrc de l'utilisateur pair

export TERM=xterm-256color  # compatibility with screen

if [ ${SSH_CLIENT:+x} ]
    clear
    echo "Welcome to the pair-programming session"
    echo -n "Press Enter to continue..." && read
    screen -x pairprog  # pairprog est le nom de la session
fi

La variable d'environnement SSH_CLIENT est testée pour que la petite astuce ne soit utilisée que lors d'une connexion ssh, et non à chaque lancement d'un shell.

Enfin, pour pouvoir dialoguer plus facilement, j'utilise un logiciel de voix sur IP (ou tout bêtement le téléphone). C'est nettement plus pratique pour faciliter la communication !

Il ne me reste plus qu'à te souhaiter de te coupler avec un de tes pair, de vivre heureux, et d'avoir plein de belles lignes de codes !

[1]	http://fr.wikipedia.org/wiki/Programmation_en_bin%C3%B4me

[2]	http://www.gnu.org/s/screen/

[3]	http://blog.siyelo.com/remote-pair-programming-with-screen

[4]	http://upnp-portmapper.sourceforge.net/

[5]	http://korben.info/comment-ouvrir-et-mapper-facilement-des-ports-sur-votre-routeur.html

Le miroir PyPI du pauvre

2012-04-12T09:59:00+02:00

Deux notes pour commencer cet article :

J'ai présenté ce sujet sous forme de présentation courte (lightning talk) lors de Djangocong 2012 [1], voici le support de présentation [2].
Carl Meyer [3], qui est une des références en la matière, a lui aussi présenté sur ce sujet [4].

Bonjour ami lecteur. Je vais te conter mon histoire, en me disant que tu es peut-être toi aussi passé par là, et que cette expérience t'enrichira.

Tout d'abord, le personnage principal : moi. Je suis fainéant (revoir la présentation [5] que j'ai donnée à Djangocong 2010 [6] à ce sujet).

Les protagonistes

pip [7] et PyPI [8]. Si tu ne connais pas pip, l'outil à utiliser pour installer des paquets python, honte à toi, arrête de lire immédiatement et documente toi à ce sujet.

Oui, maintenant.

PyPI (le Python Package Index) est le site listant et hébergeant la plupart des paquets, applications et librairies python qui ne sont pas dans la libraire standard.

L'intrigue

Je travaille sur un projet Django [9], et ayant fait les choses proprement, j'ai un ficher requirements.pip listant les noms ou les urls des différents paquets que j'utilise.

Ce fichier est utilisé par pip pour installer automatiquement toutes les dépendances de mon projet, par exemple lors de l'installation d'un nouveau serveur ou du déploiement de mon projet :

pip install -r requirements.pip

Les péripéties

Elles te sont peut-être arrivées à toi aussi :

PyPI n'est pas accessible au moment nécessaire (voir les solutions proposées dans l'excellent billet de JKM [11])
Le paquet (ou la version utilisée) a été supprimé de PyPI (ça arrive [10])
Une nouvelle version non compatible a été publiée (la parade est simple : utiliser pip freeze pour épingler les versions utilisées)

Une solution à tous ces problèmes est d'utiliser un miroir local de PyPI, qui contiendra tous les paquets nécessaires à notre projet, dans leur version utilisée.

Il y a plusieurs projets qui permettent de faire ça de manière plus ou moins automatique :

Mais ça nécessite d'installer et de gérer une application de plus, or, comme je l'ai précisé, je suis fainéant, et je n'ai pas envie de consacrer une machine (et une installation de serveur web) pour ça.

Le sauveur

pip à la rescousse, avec deux options très pratiques :

--find-links: URL ou chercher des paquets (notre miroir local !)
--no-index: ignorer les index de paquets (comme PyPI), et ne regarder que sur l'URL fournie à --find-links

Mais il y a mieux. Il est possible de mettre l'option --find-links en tout début du fichier requirements.pip pour ne pas avoir besoin de l'utiliser en ligne de commande (et donc ne pas changer nos habitudes, parfait pour un fainéant ;).

Pour la deuxième option, elle n'est pas reconnue dans le fichier, mais on peut utiliser l'option --index-url à la place. On est alors sûr que pip n'essaiera pas de trouver un meilleur paquet (meilleure note, version plus récente) sur PyPI.

Maintenant qu'on sait comment utiliser notre miroir local, il ne reste plus qu'à le créer :

Générer la liste exhaustive de tous les paquets et dépendances
Les faire télécharger par pip dans un répertoire
Servir ce répertoire avec un serveur web
Modifier le fichier requirements.pip

Générer la liste des paquets

Rien de plus simple :

pip freeze > freezed.pip

Télécharger les paquets

On le fait faire par pip, ce serait trop long et fastidieux de tout télécharger (les paquets et leurs dépendances) sur PyPI (ou git, svn, mercurial, …) manuellement :

mkdir pypi
pip install -r freezed.pip --upgrade --download=pypi --build=pypi

Servir le répertoire avec un serveur web

SimpleHTTPServer [17] à la rescousse :

cd pypi
python -m SimpleHTTPServer

Le miroir est maintenant accessible sur http://localhost:8000.

Il existe sinon une autre méthode qui consiste à fournir directement une URL de type file:///path/to/mirror/folder au paramètre find-links. Dans ce cas, pas besoin de serveur web !

Modifier le fichier requirements.pip

La dernière étape de notre périple, avant de rentrer voir sa princesse, de vivre heureux et d'avoir beaucoup beaucoup d'enfants.

Comme nous l'avons vu, il faut placer les deux lignes suivantes en tête du fichier requirements.pip :

--find-links http://localhost:8000
--index-url http://localhost:8000

Ayant maintenant notre propre miroir local, il ne faut plus utiliser les URLs de téléchargement sur git/svn/mercurial/… pour les paquets qu'on ne souhaite pas réinstaller à chaque fois :

les paquets devant être réinstallés à partir de leur dépôts VCS à chaque fois resteront avec leur URL complète
les autres paquets installés à l'origine à partir de dépôts n'ont plus besoin de leur url : ne conserver que leur nom (la partie après #egg= dans leur URL)
tous les autres peuvent être listés sans leurs dépendances

Par exemple, si vous avez installé django-notification de la sorte :

pip install -e git+ssh://git@github.com/jtauber/django-notification.git#egg=django_notification:nohlsearch

Il suffira de mettre la ligne suivante dans le fichier requirements.pip :

django-notification

À partir de maintenant, tout appel à la commande suivante ira automatiquement installer les paquets disponibles dans le répertoire du miroir local (si le SimpleHTTPServer est lancé bien entendu) :

pip install -Ur requirements.pip

Installer un nouveau paquet ou une nouvelle version

Rien de plus simple : il suffit de télécharger le paquet (ou sa nouvelle version) dans le répertoire du miroir local.

[1]	http://rencontres.django-fr.org/2012/lightning-talks.html#l5

[2]	http://mathieu.agopian.info/djangocong/2012/miroir_pypi_local_du_pauvre.pdf

[3]	http://oddbird.net/

[4]	http://carljm.github.com/tamingdeps/#1

[5]	http://mathieu.agopian.info/djangocong/dplf.html

[6]	http://rencontres.django-fr.org/2010/

[7]	http://pip-installer.org

[8]	http://pypi.python.org/pypi

[9]	http://djangoproject.com

[10]	https://groups.google.com/forum/?fromgroups#!topic/pypi/eDxaJwSkaJ0

[11]	http://jacobian.org/writing/when-pypi-goes-down/

[12]	http://justcramer.com/2011/04/04/setting-up-your-own-pypi-server/

[13]	http://pypi.python.org/pypi/localshop

[14]	https://github.com/crateio/crate-site/

[15]	http://pypi.python.org/pypi/pep381client

[16]	http://www.zopyx.com/blog/creating-a-local-pypi-mirror

[17]	http://docs.python.org/library/simplehttpserver.html

Vim, Restructured Text et espaces insécables

2012-03-14T12:07:00+01:00

Pour avoir un espace insécable dans un fichier HTML généré à partir d'un fichier ReST, il suffit d'utiliser un espace insécable (unicode \xA0) dans le fichier source. Il sera alors automatiquement converti en   lors de la compilation en HTML.

Pour entrer un espace insécable avec vim il faut faire la combinaison de touches suivantes : CTRL+k N S (si on a une touche Compose c'est Compose <space> <space>). Sur certains claviers (mac, bepo...) c'est plus simple : CTRL+space ou ALTGR+space.

Étant fainéant, voici comment j'ai mappé cette combinaison barbare sur CTRL+space :

" map CTRL+k S N (non-breaking space) to CTRL+space
imap <Nul> <C-k>NS

Attention, si vous utilisez gvim, il vous faut remplacer <Nul> par <C-space>.

Enfin voici une solution simple et rapide pour visualiser les espaces insécables (et les espaces en fin de ligne) :

" visual indication of trailing and non-breaking spaces
set listchars=trail:-,nbsp:_
set list

La commande barbare

Pour ceux qui comme moi oublient régulièrement des espaces insécables, voici comment remplacer tous les espaces avant un :, ;, ? ou ! (bien remplacer <CTRL+k N S> par la séquence de touches pour générer l'espace insécable) :

:%s/\(\S\) \([:;?!]\)/\1<CTRL+k N S>\2/g

Je vous avais prévenus, c'est violent. En gros, ce que ça fait :

:%s/<search>/<replace>/g : faire une recherche et un remplacement sur tout le fichier (et remplace toutes les occurences sur une même ligne)
$\S$ $[:;?!]$ : le pattern à chercher. Ça donne (\S) ([:;?!]) sans l'échappement : trouver tous les espaces entre un non-espace et une ponctuation, en capturant le non-espace ainsi que la ponctuation
\1<CTRL+k N S>\2 : ce par quoi il faut remplacer. \1 et \2 sont les deux morceaux capturés à l'étape de recherche, donc le non-espace et la ponctuation respectivement.

Avec tout ça, plus d'excuses pour ne pas utiliser des espaces insécables quand c'est nécessaire (merci @n1k0 pour la piqûre de rappel ;).

VIM et la correction orthographique

2012-02-28T09:44:00+01:00

Si vous ne le saviez pas déjà, VIM possède un correcteur orthographique dans le style de "Myspell" (utilisé aussi par la suite OpenOffice/LibreOffice ainsi que par Mozilla).

La documentation est disponible ici : http://vimdoc.sourceforge.net/htmldoc/spell.html

Ajouter le dictionnaire français

Pour l'activer :

:setlocal spell spelllang=fr

Si le dictionnaire n'est pas déjà présent, il sera automatiquement téléchargé pour vous, facile ! Attention néanmoins, vérifiez bien que la locale "fr_FR.utf8" est installée ET qu'elle est celle activée par défaut :

locale -a  # doit lister fr_FR.utf8, sinon la créer
locale  # doit lister LANG=fr_FR.utf8

Pour créer une locale, veuillez vous reporter à la documentation de votre distribution (par exemple https://wiki.archlinux.org/index.php/Locale#Enabling_necessary_locales).

Afin que le dictionnaire puisse être téléchargé et configuré, la langue fr doit obligatoirement être la langue courante. Pour l'activer temporairement, juste pour le téléchargement et la configuration :

export LANG=fr_FR.utf8
vim  # puis :setlocal spell spelllang=fr

Raccourcis pratiques

Pour activer ou désactiver le correcteur orthographique (toggle), et pouvoir basculer rapidement entre les langues fr et en, il suffit de rajouter deux touches de raccourci au choix dans son .vimrc :

" spell checking
function! ToggleSpellLang()
    " toggle between en and fr
    if &spelllang =~# 'en'
        :set spelllang=fr
    else
        :set spelllang=en
    endif
endfunction
nnoremap <F7> :setlocal spell!<CR> " toggle spell on or off
nnoremap <F8> :call ToggleSpellLang()<CR> " toggle language

Djangocong 2012 !

2011-11-14T10:49:00+01:00

C'est à nouveau ce moment de l'année ou la nouvelle tant attendue est enfin annoncée : la conférence française sur Django aura lieu pour la troisième année consécutive, cette fois-ci sur Montpellier.

Cette année, donc, plusieurs nouveautés :

la conférence aura lieu sur Montpellier, les deux précédentes ayant été sur Marseille
il est possible de coucher sur place (ou juste à côté)
le lieu des conférences est sur la plage
tous les lieux (conférences, couchage, apéro communautaire du samedi soir) sont très proches et accessibles à pied

Niveau programme, le même principe qui a fait le succès de la dernière édition est repris :

samedi matin : "on a fait", retours d'expérience sous la forme de conférences courtes (12 minutes) ou de lightning talks (5 minutes)
samedi après-midi : "on discute", ateliers participatifs, aussi connus sous le nom de barcamp
samedi soir : apéro communautaire, occasion idéale pour boire et manger ensemble, faire connaissance, échanger à bâtons rompus ...
dimanche matin : "on fait", sous la forme de sprints
dimanche après-midi : "on refait le monde", soit sur la plage, en balade, autour d'un bœuf musical ... détente !

Mais le programme, lui, dépends en grande partie de TOI ! Il dépendra des sujets que tu aura proposés, tu es donc responsable en grande partie de sa teneur !

Pour pouvoir organiser la meilleure rencontre possible, nous avons donc besoin de ton aide, et ce de différentes manières. Voici ce que tu peut faire pour notre rencontre :

proposer un sujet de conférence : tu as créé ou utilisé une librairie qui mérite d'être connue, tu as mis en place des méthodes ou outils pour faciliter ton développement web avec Django, ou tout simplement une expérience à partager ? C'est le format qu'il te faut !
proposer un lightning talk : idéal pour des sujets courts, pêchus, dynamiques, rigolos, pour présenter la dernière nouveauté, pour faire connaître son projet, sa communauté, une idée... beaucoup plus libre et dynamique qu'une conférence* *
parler de cette rencontre (et de son appel à conférence) autour de toi, en faisant connaître le lien vers Djangocong 2012
demander à des personnes que tu connaît de proposer une conférence ou un lightning talk sur un sujet qu'il maîtrise et que tu aimerait voir présenté

Tu as jusqu'au 13 janvier 2012 inclus, donc ne perd pas de temps !

Pour ma part j'ai déjà proposé trois sujets, et toi ?

P.S: tu comptes venir à la conférence, et tu aimerais amener femme et enfants ? Il semblerait que tu ne soit pas le seul, il y aura donc probablement d'autres "accompagnants" avec qui passer du bon temps ! Plus d'informations sur le sujet à venir, et je vous tiendrais bien entendu informés de l'ouverture des inscriptions !

Point-virgule

2011-10-13T08:30:00+02:00

(Ceci est mon premier essai d'écriture. Je trouve l'idée sympa, mais la réalisation est au mieux moyenne... faites moi connaître votre avis et conseils d'amélioration dans les commentaires !)

Ça a recommencé.

Tout va être à refaire, tout ce que nous avons construit, patiemment, péniblement, durant les 80 dernières années. Voilà l'amer constat qu'il m'est donné de faire, au crépuscule de ma vie.

J'avais espéré pouvoir offrir à mes pairs, mes confrères et amis, un avenir plus radieux que celui qui nous était initialement réservé.

Tout s'était mis en place, pièce après pièce, comme un puzzle, comme un Tetris bien engagé.

Le point de départ : une morne journée d'octobre, et un développeur de plus qui se fait dire que son boulot devrait être réservé aux débutants, aux jeunes diplômés. Les mots résonnent encore dans ma tête : "Le développement, c'est bouché, ça n'a pas d'avenir dans la vie d'un homme. Il faut savoir évoluer, devenir chef de projet, consultant, technico-commercial. Tout sauf rester prostré devant son ordinateur, en concurrence avec les milliers d'autres programmeurs frais sortis de l'école, toute cette main d'oeuvre bon marché. Il faut que tu saches qu'aujourd'hui, trouver un programmeur c'est super facile. Un conseil, évolue." Ces mots lâchés par un patron vraiment plus au goût du jour, dépassé, mais toujours aussi puissant, ont fait écho aux nombreuses plaintes, rancoeurs et billets de blogs traitant du sujet : le développement n'était pas apprécié à sa juste valeur, n'était pas apprécié du tout en fait. Et cette mentalité rampante était devenue à la mode, comme une évidence.

Pourtant, le manque de développeurs était flagrant. Trouver un collaborateur ou employé expérimenté, motivé et qui se tenait informé des dernières avancées techniques était de plus en plus compliqué. Les plus grandes entreprises comme Mozilla et Google attiraient la plupart de ces perles rares qui savaient pouvoir y trouver un hâvre de paix, de sérénité, et de liberté dans leur travail quotidien. Un endroit leur permettant d'exprimer leur créativité, et leur plein potentiel.

La bascule a d'abord été imperceptible. Sous l'action d'un petit groupe de Djangonautes (terme maintenant oublié depuis longtemps), les évènements se sont enchainés :

tout d'abord les prix journaliers des indépendants ont augmenté, d'abord lentement, puis de plus en plus rapidement pour atteindre les prétentions de rockstars du SEO.
la mort d'une idôle de plusieurs générations, le grand Steve, et son image de "technologie utilisable par tous". Lui et son idée du "design avant tout" avaient fait de l'ombre pendant trop longtemps au travail des milliers de développeurs qui avaient été nécessaires à ses gadgets.
la création de nouveaux langages de programmation, comme Dart, qui reniaient les avancées en lisibilité et clarté acquises laborieusement par certains pionniers, dont Py^W ... celui que l'on ne saurait nommer.
la généralisation de l'utilisation de langages complexes, d'abord Java, puis Ruby, Dart, Pronog, Cortran, kobol, et enfin, le langage qui les remplaça tous, le seul et unique autorisé de nos jours, l'Ensembleur.
les initiatives incessantes de minimisation de l'intérêt de la documentation, que ce soit sur les API, les langages, ou les projets, leur ROI étant inexistant.

Une fois tout ça en place, l'étape suivant fût d'imposer des restrictions sur les places disponibles en école informatique. Pour faire voter une telle loi, il suffisait de se mettre quelques politiciens dans la poche. En effet, depuis de très nombreuses années déjà ils étaient devenus maître dans l'art de l'absurde, dans l'art de présenter une idée comme étant la solution logique à un problème, alors que c'était exactement le contraire qui était recherché.

Quelques exemples:

On ne veut pas que le piratage de la musique soit facile ? On va limiter les téléchargements gratuits (et donc renforcer et enrichir les solutions de piratage payantes).

Il y a des problèmes de sécurité depuis qu'on a augmenté les sanctions, et diminué la prévention ? Continuons dans cette voie, et augmentons encore les sanctions, et diminuons d'autant la prévention.

Ces raisonnements illogiques, présentés comme les seuls valables, ont pavé le chemin à la grande loi : il y avait un manque d'informaticiens, de développeurs ? Limitons les places dans les écoles d'informatique pour les réserver à une "élite", qui serait bien plus efficace. Grâce au lobby alors puissant des Congs, cette loi fût votée dans le plus grand secret, en pleine nuit, par une poignée de fidèles, et ne rencontra donc aucune opposition.

Le plan se déroulait à merveille jusque là, et il alors fallut franchir le cap le plus difficile : le bannissement pur et simple du langage qu'on ne saurait nommer, et du framework plébiscité jusque là par les adeptes du web, le framework au poney magique.

Sans cette dernière étape, il n'aurait jamais été possible d'arriver où nous en sommes maintenant. Ou devrais-je dire, où nous en étions il y a encore quelques années.

Il n'était pas envisageable de garder un langage aussi facile, accessible à tous et efficace, sous peine de fragiliser la main-mise des informaticiens sur le précieux code.

Nous, les développeurs, sommes maintenant une caste renommée et appréciée de tous, ou plutôt crainte de tous. N'étant plus qu'une centaine de par le monde, nous imposons notre volonté aux hommes d'états comme aux chefs d'entreprise. Quand nous nous déplaçons, les foules nous acclament en espérant que nous daignerons continuer à maintenir les infrastructures, les services et programmes qui régulent la vie quotidien des 12 milliards d'habitants de notre planète.

Oui, dernièrement, la vieillesse aidant, nous nous sommes ramollis. Notre emprise de fer s'est assouplie, et certains pseudo-langages ont fait une timide apparition. Bien entendu, les créateurs étaient immédiatement arrêtés, convertis, puis assujettis à notre cause.

Oui, ces pseudo-langages persistaient parfois pendant quelques mois, soutenus et améliorés par quelques dissidents, quelques résistants du monde de l'opensource, ces illuminés qui ne comprenaient pas notre vision. En général une descente de flics chez ces derniers suffisait à calmer leurs ardeurs.

Oui, depuis quelques années, notre influence diminuait, et les foules qui s'ammassaient sur nos trajets avaient l'air moins craintives, plus hargneuses et revendicatrices.

Oui, j'ai entendu parler il y a quelques mois d'un langage qui persistait, et son nom aurait dû me mettre la puce à l'oreille : Boa.

Boa.

Voilà un nom étrangement évocateur. Il paraît que son auteur est Hollandais, et qui plus est, barbu. On m'a même dit que ce langage n'utilisait ni accolade, ni même de point-virgule ! Sacrilège !

Nous aurions dû nous en inquiéter, nous aurions dû préparer la relève il y a bien longtemps, une relève forte qui nous aurait sorti de ce mauvais pas.

Ça a recommencé... mon infirmière, au détour d'une conversation, m'a dit hier ces quelques mots, d'apparence anodine, mais qui résonnent depuis dans ma tête. Ces quelques mots annonciateurs du retour du grand mal :

"j'ai une super idée, et je vais demander à mon neveu de me la programmer".

La bidouille django du jour: appeller un templatetag depuis un autre templatetag

2011-05-11T11:59:00+02:00

Cet article n'est pas écrit par Mathieu. Enfin si, mais par un autre Mathieu, qui n'a pas de blog en ce moment et abuse^Wprofite de la gentillesse du maître de ces lieux pour poster ici.

Introduction

Avez vous toujours rêvé d'appeler un templatetag Django depuis un autre templatetag ? Allez, avouez-le : dans vos rêves les plus fous, vous aimeriez pouvoir faire:

@register.simple_tag
def my_templatetag():
    if condition:
        return tag1()
    else:
        return tag2()

Ça marchera si vos tag1 et tag2 sont des simple_tags, vu que c'est directement une chaîne de caractères qui est retournée. Là où ça commence à se compliquer, c'est si vous voulez que ça marche avec n'importe quel templatetag, et notamment les inclusion_tags. En effet, en appelant un inclusion_tag "à la main", vous vous retrouvez avec juste le dictionnaire qu'il retourne comme contexte, au lieu d'avoir le "vrai" résultat.

Zut, mais comment faire alors ?

Pour comprendre comment faire pour contourner ce problème, il faut regarder comment un templatetag fonctionne. Quand vous déclarez un inclusion_tag ou un tag classique, que se passe-t-il ?

Tout d'abord, via le décorateur @register.tag ou @register.inclusion_tag, votre templatetag est enregistré dans la variable register, que vous avez dû déclarer de la sorte: register = Library().
Si on inspecte cette fameuse Library, on se rend compte que chaque tag s'enregistre dans un dictionnaire, dans l'attribut tags. Ce dictionnaire contient la fonction permettant de générer l'instance de Node correspondant à votre tag. Dans le cas d'un inclusion_tag, il y a un peu de complexité qui vous est planquée, vu que, contrairement à l'enregistrement d'un tag "classique" via @register.tag, vous ne déclarez pas de sous-classe de Node, et vous ne jouez pas non plus avec un parser de tokens.
Au moment où le template rencontre votre templatetag, il récupère la fonction à appeler dans l'instance de Library qui va bien, et instancie le Node avec parser (l'instance du Parser) et token (l'instance de Token correspondant à tout ce qui était entre {% et %})
Ensuite, au moment d'afficher votre template, la méthode render() de chaque Node est appelée. Celle-ci reçoit notamment le contexte courant.

Du coup, la grosse bidouille consiste simplement à faire la même chose que Django fait. Ça donne ça:

@register.tag
def my_templatetag(parser, token):
    # On suppose que vous êtes dans le même module, sinon il faut aller chercher le register
    # qui va bien dans un autre module python
    if condition:
        return register.tags['tag1'](parser, token)
    else:
        return register.tags['tag2'](parser, token)

La beauté du truc, c'est que vous enregistrez un tag normal, mais quand il est appelé, il utilise une autre instance de Node, qui provient d'un de ses copains.

Gestion des paramètres

Il reste cependant un écueil : comment gérer les paramètres ? C'est en fait très facile: il faut modifier le token qu'on passe pour tromper Django. Et c'est là où la bidouille est un peu crade, vous devez faire comme si on appelait le templatetag depuis le template:

@register.tag
def my_templatetag(parser, token):
    # On suppose que vous êtes dans le même module, sinon il faut aller chercher le register
    # qui va bien dans un autre module python
    if condition:
        token.contents = 'tag1 argument1 argument2'
        return register.tags['tag1'](parser, token)
    else:
        token.contents = 'tag2 argument1 argument2 argument3'
        return register.tags['tag2'](parser, token)

Conclusion

Et voilà ! Je vous conseille, si vous utilisez cette technique, même si vous n'avez pas besoin d'arguments, de toujours modifier token.contents, histoire d'être sûr.

On peut encore pousser le vice plus loin et gérer des paramètres dans notre templatetag 'parent', mais ça suffit pour aujourd'hui :)

Contribuer à Django, premiers pas (patcher la doc)

2011-04-30T17:46:00+02:00

Ceci est le troisième article dans la série, les premiers étant

On sait donc quoi faire d'un ticket, et on a tous les outils en place pour y répondre, c'est parti pour une contribution à la documentation !

Choisir son ticket

Nous avons vu dans le premier article de la série qu'on peut trouver les tickets soit sur la page Reports de trac, soit sur le super dashbord que Jacob Kaplan-Moss vient de créer.

Pour ma part, je me focalise pour le moment sur les tickets qui sont unreviewed (non revus, qui viennent d'être créés).

N'oubliez pas qu'il est tout à fait possible, et même encouragé, de :

ne pas s'occuper de tickets pour lesquels on ne se sent pas à la hauteur
demander de l'aide sur le salon #django-dev sur le serveur irc freenode
lancer des discussions pour avoir plus d'informations ou d'avis sur la liste de diffusion *django-dev*

Nous allons, pour illustrer ce billet, examiner le ticket #15886 dont le titre est "Improve django.core.serializers.get_serializer() docs".

Revendiquer le ticket

Comme indiqué dans la doc sur la contribution, il est conseillé de claim (revendiquer) un ticket avant de travailler dessus, pour éviter de se retrouver à plusieurs sur le même ticket en parallèle, et sans le savoir. Vu le nombre de contributeurs potentiels, il y a un risque que quelqu'un d'autre soit déjà en train de travailler sur un patch.

Revendiquer le ticket se fait très simplement en sélectionnant accept, tout en bas de la page de modification d'un ticket.

Il est par contre inutile de revendiquer un ticket pour les cas les plus simples, ne nécessitant que quelques minutes de travail. Il suffit alors de soumettre le patch directement, et c'est ce que j'ai fait pour l'exemple choisi pour illustrer cet article.

Première étape : faire une revue du ticket

Comme vous pouvez le constater, j'ai revu le ticket, et j'ai posté un commentaire conseillant de créer un autre ticket séparé pour n'avoir qu'un seul problème à résoudre dans celui-ci. Je n'ai pas changé l'état du ticket, n'étant pas certain de ce qu'il fallait en faire.

Il faut noter que toute contribution (même un simple commentaire) peut être utile et précieuse. Dans ce cas précis, il a servi à faire créer un nouveau ticket, et à initier la discussion.

Dans ce cas particulier, Jacob a passé le ticket en accepted, vraisemblablement parce qu'il ne restait pas d'objection : le problème identifié dans le ticket (le manque de documentation) est maintenant clairement séparé de la demande de nouvelle fonctionnalité, et le "composant" concerné a bien été mis à jour.

Deuxième étape : proposer un patch

Et pour ça, rien de bien compliqué. Dans le précédent article, nous avons vu comment mettre en place un projet brouillon, et surtout comme cloner le code source de Django, et compiler sa documentation.

Modifier la documentation

Pour cela, il faut déjà repérer la page concernée dans la documentation de Django. Toujours en nous référant au ticket #15886 de l'exemple, un gentil contributeur a déjà apporté un commentaire, et indiqué le lien vers la page http://docs.djangoproject.com/en/1.3/topics/serialization/ (oui, ça tombe bien, ce gentil contributeur, c'était moi ;)).

Si on inspecte l'url, on peut voir qu'il s'agit de la page "serialization" dans la catégorie "topics". Le fichier correspondant, dans le code source de Django, se trouve donc logiquement dans

$ cd ~/projects/django/docs
$ vi serialization.txt

Dans mon cas, j'utilise le meilleur des éditeur, mais vous avez bien entendu le choix des armes ;)

Une fois le bon endroit localisé pour apporter la clarification demandée dans le ticket, il suffit de rajouter quelques lignes, en utilisant son meilleur anglais.

Il est à ce propos fortement conseillé d'avoir au moins quelques notions de sphinx, l'outil utilisé pour générer la doc, et connaître les ajouts apportés pour Django dans la page sur la contribution à la documentation.

Compiler la documentation

Nous l'avons vu dans le précédent article, il suffit pour celà d'utiliser la commande suivante :

$ make html

Si il y a le moindre problème de syntaxe reStructuredText vous le verrez lors de l'exécution de cette commande. Il suffit alors de consulter le résultat sur file:///chemin/vers/projects/django/docs/_build/html/index.html.

Créer le patch

Si vous avez suivi la méthode proposé dans le précédent article, vous avez le cloné le miroir git de Django, et pouvez donc utilisez la méthode ultra simple suivante :

créer une branche de développement pour y stocker les modifications à apporter : $ git checkout -b dev
apporter les modifications nécessaires
commit les changements régulièrement, et retourner en 2. tant que c'est nécessaire : $ git commit -a -m "un message de commit"
une fois fini, créer le patch : $ git diff master > nom_de_mon_patch.diff

Il est très fortement recommandé de créer un patch avec l'extension .diff pour qu'il soit correctement traité et affiché par trac, et de l'attacher au ticket (au lieu de pointer vers un diff ou un pull request sur github ou autre), pour simplifier au maximum la dure et (déjà) fastidieuse tâche des core developpers.

Et surtout ne pas oublier de rajouter le flag "has patch" !

Pour reprendre notre exemple, vous pouvez visualiser le patch final.

Attendre la validation de la communauté

Dans ce cas précis, j'étais inquiet de la dépendance qu'il pouvait y avoir sur le ticket #15889, qui est le ticket créé en parallèle pour la demande d'ajout de fonctionnalité (renvoyer une exception spécifique au lieu de KeyError). En effet, si le ticket #15889 était intégré dans Django (avec la documentation associée), avant le ticket #15886, il résulterait un problème de cohérence, avec deux parties de la même documentation indiquant une levée d'exception différente.

J'ai donc soulevé la question sur le salon irc #django-dev, et la réaction a été rapide : Alex a eu la gentillesse de répondre à mes craintes en fermant le ticket comme étant un duplicat du ticket #15889.

Bah oui, mais mon patch alors ?

Et là, j'ai envie de répondre : "C'est le jeu, ma pov' Lucette" !

Plus sérieusement, peu importe le temps passé (dans ce cas, vraiment minime) sur un ticket, au final le but est de

rendre Django meilleur
apporter sa modeste contribution si nécessaire
faciliter au maximum la tâche des core devs
apprendre le plus possible au passage quand l'opportunité se présente

Astuce : se rajouter dans les destinataires

Il suffit pour cela de cocher la case add to cc en bas du ticket, et de sauvegarder. Si vous êtes enregistré et connecté, votre adresse mail devrait être automatiquement ajoutée dans la liste des personnes qui seront en copie du mail envoyé lors de chaque modification du ticket : commentaire, changement d'état...

L'intérêt, en plus de recevoir les mails sur les tickets qui nous concernent, est de pouvoir faire un filtre personnalisé pour afficher tous ces tickets.

Avec ce genre de requête personnalisée, il est beaucoup plus facile de suivre l'évolution de "ses" tickets, et de pouvoir utiliser l'offre 5-for-1 !

Sud Web, c'est bon pour ton web

2011-04-27T09:30:00+02:00

En un mot comme en cent :

Et toi, cher lecteur ? As-tu pensé à réserver ta place ? Dépêche-toi, il ne reste plus que 5 jours !

Mais c'est quoi Sud Web ?

Sud Web est une conférence qui aura lieu le 27 mai 2011 à Nîmes, donc dans le sud, et (normalement) au soleil. Elle se tiendra sur une journée dans les locaux de l'Ecoles des Mines d'Alès (oui, à Nîmes ;)), et rassemblera quelques orateurs et oratrices trié(e)s sur le volet, avec des sujets répondant au slogan "Savoir-faire et faire-savoir".

Méthodologies, standards, de grands noms du Web (Karl Dubost pour ne citer que le plus connu) seront là pour nous présenter des sujets allant de la technique (SVG pour les designers et les développeurs) à la méthode (Anatomie d'une mission agile) en passant par des sujets plus vastes (Le web et l'efficience de l'intervention humanitaire).

Il y en a bien d'autres (y compris plusieurs lightning talks vraiment sympathiques), tous listés pour votre plus grand plaisir sur la page du programme.

Mais il n'y a pas que le programme, bien entendu, qui fait le succès d'une conférence, il y a aussi et surtout les rencontres, et c'est pour ça que nous vous avons concocté une soirée communautaire qui promet d'être riche en échanges, et ce dans un cadre très agréable.

Y'a un lien avec Paris Web ?

Oui et non. Comment ça elle est inutile ma réponse ?

Oui

Sud Web est parti d'une initiative de plusieurs passionnés du Web, qui lors de leur dernière rencontre à Paris Web 2010, ont décidé de se lancer dans l'aventure de créer et organiser une conférence Web, mais cette fois-ci dans le sud.

Non

Les organisateurs (dont j'ai la chance de faire partie) ont vraiment souhaité avoir une conférence (petite sœur de Paris Web), mais sur une thématique résolument différente.

Oui, la conférence va recevoir quelques-uns des orateurs qui ont déjà présenté à Paris Web (sur d'autres sujets), et oui Sud Web est aussi soutenu par le W3C, mais non, ce n'est pas une copie conforme avec (probablement) le soleil en plus et (espérons) les grèves en moins.

Autre chose ?

Oui, plusieurs autres choses d'ailleurs, et en vrac :

une conférence no-wifi comme lors de Djangocong
un débat en fin de journée sur la question Où va le Web animé par Marc Lipskier
des goodies
des repas compris dans le prix
la chance pour moi de revoir David Larlet, Jean-Michel Armand, Nicolas Perriault, Mathieu Pillard et Nicolas Dubois que j'ai vus il y a peu à Djangocong

Conclusion ?

Moi j'y vais, et toi donc ? Vite vite il ne reste plus que quelques jours !

Contribuer à Django, premiers pas (les outils, l'environnement)

2011-04-25T13:52:00+02:00

Ceci est le deuxième article dans la série, le premier étant Contribuer à Django, premiers pas (revue de tickets).

Maintenant qu'on a compris le flow entre les différents états de tickets, et les flags associés, passons aux choses sérieuses : la soumission d'un patch !

Mais avant de pouvoir soumettre un patch, il faut avoir son environnement prêt, c'est à dire une version récente du trunk, un projet brouillon et une application de test, et enfin les différentes dépendances nécessaires.

La démarche expliquée ici utilise git, qui semble être la méthode la plus répandue (autre que svn, que je connais moins bien).

Créer son virtualenv

Tout le monde sait comment créer un virtualenv de nos jours, n'est-ce pas ? Pour ceux qui ne connaissent pas encore cet excellent outil, je leur conseille vivement de s'y intéresser, ainsi qu'à pip, et à virtualenvwrapper pour les fainéant (et la fainéantise, c'est bien).

$ mkvirtualenv scratch

Créer son projet

Il est recommandé d'avoir un squelette de projet Django, pour pouvoir démarrer plus rapidement, sans avoir à répéter sans cesse les mêmes actions. Celui que j'utilise pour mes projets réels se trouve ici, et je vous conseille d'avoir le votre, avec vos propres réglages !

Dans le cas de la contribution à Django, j'ai créé un autre squelette, django_scratch, qui n'a pas d'autres applications installées que celles par défaut, en rajoutant l'admin et une application de test vide.

$ cd ~/projects/
$ hg clone https://magopian@bitbucket.org/magopian/django_scratch scratch
$ cd scratch

Cloner le repository de django

Il existe un miroir du svn de Django sur github que nous allons utiliser, mais vu que je suis super sympa, je vous l'ai déjà mis dans les requirements de pip :

$ pip install -r pip_requirements.txt

Pour le même prix, sphinx (qui dépends de pygments) sera installé par la même occasion, outil indispensable pour pouvoir contribuer à la documentation.

Finaliser

Vous avez normalement tout ce qu'il faut pour débuter votre carrière de contributeur !

Une base de donnée sqlite

Par défaut, c'est le moteur utilisé, car plus rapide pour les tests et surtout beaucoup plus simple à configurer. Pour faciliter les choses, il y a déjà scratch.db.save qui est une base initialisée avec les tables nécessaires à Django, et même un admin (login: admin, pass: admin).

Pour l'utiliser, ou la ré-utiliser pour revenir à la configuration de base :

$ cp scratch.db.save scratch.db

Il y a aussi mysql_settings.py et postgresql_settings.py qui sont là pour les cas où le moteur de base de données est important et doit être testé. Il vous suffit d'écraser settings.py avec le fichier de votre choix, et de créer un fichier creds.py qui contient (à modifier avec vos user/pass bien entendu) :

# creds.py
MY_CREDS = {'user': 'foo', 'pass': 'bar'}
PG_CREDS = {'user': 'foo', 'pass': 'bar'}

Une application de test

Cette application est constituée d'un modèle Foo avec un seul champ name, l'AdminModel qui va avec, un urls.py et views.py basiques.

Le but est d'avoir le minimum nécessaire à la reproduction de la majorité des bugs, et ce avec un minimum de travail. N'oubliez pas de faire un syncdb pour que le(s) modèle(s) soi(en)t créé(s) !

Le trunk de Django

Il a été cloné directement dans le répertoire src de votre virtualenv. Si vous avez suivi exactement tout ce qui a été indiqué dans ce billet, vous devriez pouvoir créer un lien symbolique du répertoire de Django à un endroit plus pratique et accessible (vous allez devoir y modifier des fichiers régulièrement) :

$ ln -s ~/.virtualenvs/scratch/src/django ~/projects/

De la documentation en sphinx

Elle se trouve directement dans le répertoire docs du trunk de Django, et pour la générer, rien de plus simple :

$ cd ~/projects/django/docs
$ make html

S'ensuit la génération de tous les fichiers html de la documentation de Django, que vous pourrez visualiser et contrôler en pointant votre navigateur sur le répertoire _build/html/ :

file:///chemin/vers/projects/django/docs/_build/html/index.html

Bon, et donc, quand est-ce qu'on contribue ? Nous verrons ça dans le prochain article, promis !

Contribuer à Django, premiers pas (revue de tickets)

2011-04-24T17:41:00+02:00

Contribuer au framework web Django... tout un programme, et très effrayant de prime abord. Depuis des années que j'utilise le framework, je commence tout juste à y contribuer, et je peux vous assurer que jusqu'à hier encore, je ne pensais pas être à la hauteur.

Or, ce qu'il y a de génial, c'est que tout le monde est à la hauteur, et que chacun peut apporter sa pierre à l'édifice ! La contribution la plus simple consiste à faire la revue de nouveau tickets, et c'est très utile : si vous ne me croyez pas, regardez ce qu'il est écrit :

Jacob Kaplan-Moss (Django BDFL) sur la mailing list django-dev : "this is totally something anyone here can do"
Documentation officielle Django page "contributing" : "there’s a lot that general community members can do to help the triage process"
Documentation officielle de Django page "how contribue" : "Django is a community project, and every contribution helps. We can’t do this without YOU!"

Le cheminement logique et officiel pour devenir un contributeur Django est :

être motivé pour donner un peu de temps en retour à la communauté qui a fait un framework qui me fait vivre !
se créer un compte sur le trac de Django
lire dans l'ordre (ou le désordre) les pages suivantes

Une fois qu'on a lu tout ça, on est prêts à choisir des tickets, soit sur la page Reports de trac, soit sur le super dashbord que Jacob Kaplan-Moss vient de créer.

Mais c'est trop long de tout lire !

Effectivement, il y a beaucoup de ressources, et toutes ne sont pas indispensables pour démarrer.

Pour vraiment débuter, je pense qu'il est indispensable de lire le premier document sur comment contribuer qui a l'avantage d'être assez concis. Il faut ensuite comprendre les différentes étapes d'un ticket, qui sont indiquées sur le deuxième document, dans la section Ticket Triage, avec une image très claire.

Mais c'est trop compliqué, je suis pas assez expérimenté en Django !

Il n'est pas nécessaire d'être un expert pour pouvoir faire de la revue de tickets. Si vous voyez un ticket que vous pensez pouvoir traiter, faites-le, sinon passez au suivant!

Les tickets qui sont en état unreviewed peuvent être fermés, acceptés ou passés en "besoin d'une décision de design" :

Ticket fermé, avec les statuts suivants :

invalid si ce n'est ni un bug, ni une demande d'amélioration, mais une question de support ou sur autre chose que django
duplicate si le même bug ou demande d'amélioration a déjà été signalé. Pour le savoir, il suffit de faire une recherche dans la liste des tickets, puis de fermer le ticket en cours en indiquant que c'est un duplicat du ticket #xxxx
worksforme si vous avez pu tester que ça marche pour vous, avec les informations fournies par le créateur du ticket
needsinfo si il manque des informations pour pouvoir reproduire le bug, mais que le bug a l'air d'être réel

Les autres statuts (fixed et wontfix) ne concernent que les core developers.

Dans tous les cas, lors de la fermeture d'un ticket, il est primordial de rester poli et agréable, en signalant le problème au créateur du ticket, et lui indiquant qu'il peut rouvrir le ticket si il fournit plus d'informations, si on a mal compris le problème...

Il faut garder à l'esprit que le créateur a lui aussi passé du temps pour signaler le problème, et qu'il lui a fallut de la motivation pour faire la démarche de créer ce ticket !

Ticket accepté, avec les indications suivantes :

has patch dans le cas où un patch est fourni (documentation ou code)
needs documentation si il y a un patch pour une fonctionnalité, mais qu'il n'y a pas la documentation qui doit aller avec
needs tests si il y a un patch pour une fonctionnalité sans les tests unitaires nécessaires, ou un patch correctif sans les tests de non régression
patch needs improvement si le patch de documentation n'est pas assez clair ou si le correctif n'est pas acceptable tel quel (possibilité d'améliorations, conformité aux conventions de codage...)
easy pickings pour indiquer que ce ticket peut être facilement et rapidement réglé, même par un débutant (apparaîtra dans une liste personnalisée accessible sur la page report de trac)

Ticket passé en "design decision needed"

C'est le cas notamment des tickets qui proposent des améliorations du framework, ou des corrections de "bug" qui n'en sont pas forcément, ou qui pourraient avoir plusieurs corrections possibles. Une fois le ticket passé en DDN, un des core developers pourra le passer en wontfix ou en accepted.

Et je peux changer le statut de mes propres tickets alors ?

Non.

Pour une réponse plus longue : il vaut toujours mieux au moins une validation externe pour être sûr qu'on a pas oublié quelque chose, ou mal compris la doc, ou fait une typo, ou ...

Trop long, j'ai pas lu

C'est bien dommage. Il faut tout de même un minimum de motivation pour rendre un peu à la communauté de ce qu'elle nous apporte.

J'ai lu, mais tu veux bien résumer ?

Pour débuter et commencer à contribuer, il est très facile de faire de la revue de tickets, c'est-à-dire relire et (in)valider des tickets qui viennent d'être créés.

Dans certains cas, la validation (ou fermeture) du ticket ne nécessitera même pas de test ou de reproduction. Pour les autres, il vaut mieux lire le reste des documents que j'ai listés en début de cet article, ou attendre que je fasse un résumé dans un prochain billet !

Le cadeau bonux

Jacob Kaplan-Moss a lancé une idée pour motiver les revues de tickets : 5 tickets revus, un ticket revu par un des core developers participant à l'opération (Jacob Kaplan-Moss, Alex Gaynor et Carl Meyer).

Donc si vous avez un ticket que vous aimeriez qu'un des core dev considère, vous savez ce qu'il vous reste à faire !

Dans le prochain article, nous verrons comment mettre en place son environnement pour pouvoir contribuer sans douleur !

Djangocong 2011 : une cuvée d'exception

2011-04-21T08:32:00+02:00

La deuxième conférence Djangocong, organisée par nos cher président (David Larlet) et trésorier (Jean-Michel Armand) a eu lieu ce week-end du 16 au 17 avril 2011, et a regroupé 75 personnes.

Pour rappel, Djangocong est la conférence sur, par et autour de la communauté django française. Le "g" final donne un accent ensoleillé, les deux conférences ayant eu lieu à Marseille.

Vous trouverez dans ce billet mon propre ressenti sur la conférence et je me dois de vous prévenir : j'ai cette année encore apporté ma modeste contribution à l'organisation sur place. Un *etherpad* a été mis à disposition pour regrouper les retours et remarques des présents.

Le format

Le format de cette année, sur l'initiative de David, était articulé autour de trois temps forts :

On a fait (#nowificonfs)

Retours d'expérience de 12 minutes, ces présentations étaient beaucoup plus courtes que ce qu'on peut voir en général. La durée relativement courte a permis aux spectateurs de rester concentrés et attentifs. Par contre, les orateurs ont pour la plupart dû sauter quelques diapos et explications pour respecter les limites de durée.

Format idéal pour des retours d'expériences, mais trop court si ça avait été destiné à des présentations techniques ou de produits.

Lors de cette première matinée, les organisateurs ont décidé d'expérimenter en grandeur nature le "mouvement" lancé par la conférence Sud Web : les conférences sans WiFi.

Le WiFi ayant été désactivé durant toute la durée des présentations, j'ai pu compter en tout 4 ordinateurs ouverts, dont 2 pour des orateurs, sur 75 présents. Pour référence, l'année dernière, sur environ 55 participants, il y avait en moyenne une vingtaines d'ordinateurs ouverts et utilisés pendant les conférences.

Les conséquences ont été multiples:

plus grande attention apportée aux orateurs, mais surtout, plus grand respect (difficile de s'adresser à des têtes baissées et des claviers qui cliquettent)
échanges humains plus poussés : j'ai remarqué une bien moins grande utilisation de twitter par exemple, et plus de discussions informelles (pendant les pauses, les repas, la soirée) sur les sujets présentés, avec ou sans l'orateur d'ailleurs
pas de trending topics ni de retours à chaud, pas d'etherpad rempli à la volée pendant les conférences. Couplé à l'absence de captation vidéo, cela exclu en grande partie les absents qui n'ont finalement que les slides mis en ligne à postériori

Vu que le WiFi a été réactivé le reste de la journée, ainsi que le lendemain, les gens dépendants d'un accès à internet n'ont pas dû être trop lésés.

Idée : limiter l'accès internet à l'intérieur de l'amphi où se déroulent les conférences, mais pas en dehors, par exemple en n'ayant pas de WiFi, mais des connexions filaires. Ou alors ne pas limiter l'accès à internet, mais demander aux spectateurs d'une conférence de ne pas ouvrir leur laptops (pour prendre des notes, il y a le papier+crayon!).

Vous trouverez la liste des liens vers les supports de conférence sur le salon convore dédié et sur le site de la rencontre.

On discute (barcamps)

Une grande première pour moi, et j'en ai été absolument ravi et enthousiasmé. La possibilité de pouvoir échanger à plusieurs, au calme dans une salle, sur un sujet précis, c'est vraiment inestimable.

Ayant dû m'absenter pour aider Jean-Michel à préparer la salle pour le soir, je n'ai pu pleinement participer qu'au barcamp sur "Geeks sans frontières". Ce sera probablement le point de départ d'une communauté de développeurs volontaires pour certains développements, soit d'utilité publique (pour référence, certains avaient participé au sprint sur Memopol), soit dans les cas de force majeure (mise en place d'outils pour trouver des maisons pour abriter des réfugiés suite à un tsunami ou tremblement de terre par exemple).

Il devrait bientôt y avoir une mailing list pour les gens intéressés, à suivre!

Pour l'organisation des barcamps, deux points d'amélioration pour la prochaine édition : l'organisation un poil chaotique (trop organisée selon certains sur l'etherpad), et le manque de salles (l'amphi était à chaque fois utilisé pour un des sujets, et vraiment pas adapté).

J'ai aussi loupé les lightning talks improvisés du samedi soir, je ne pourrais donc pas vous en dire plus.

On fait (sprints)

Après les discussions de la veille lors des barcamps, un petit nombre de sprints ont eu lieu le dimanche matin. Il y avait un grand nombre d'absents, ce qui aurait été dommage et pénalisant pour un orateur si il y avait eu des conférences.

Il y a eu plusieurs sprints, dont un sur les bonnes pratiques pour des applications réutilisables, un autre sur l'intégration des django-floppyforms dans la version 1.4 de django, et je suis sûr qu'il en manque!

Les repas, la soirée

Pour les chanceux ayant pu arriver le vendredi soir, il y a eu un regroupement informel dans une crêperie. Ce fût un moment très agréable et détendu, qui m'a permit de voir pour la première fois (et en avance!) des gens que je côtoie depuis parfois des années sur internet.

Les repas du midi (plateau repas le samedi, sandwich -délicieux- le dimanche) ont été une excellente occasion de se regrouper dans l'herbe au pied de l'école qui nous accueillait, et au soleil!

Le seul petit regret que j'ai pu avoir, c'est de n'avoir pas pu discuter assez (et assez longuement) avec les gens qui étaient là pour la première fois, et qui (pour certains) avaient l'air d'être trop timides pour s'intégrer aux différents petits groupes qui s'étaient formés.

Le samedi soir s'est déroulé à la Bo[a]te non loin du vieux port, dans une ambiance vraiment détendue, et autour d'une énorme paella. La encore, une occasion de pouvoir échanger, discuter, plaisanter, faire mieux connaissance avec des personnes que je croise tous les jours sur internet, et que je ne peux rencontrer en chair et en os qu'une ou deux fois par an.

N'ayant pas pu être présent au parc Longchamp le dimanche après-midi, je n'ai pas eu la chance de voir les poneys ni de manger de la barbapapa!

Conclusion

Pour moi, une édition encore meilleure que la première, et pourtant, c'était pas évident, la première étant déjà excellente! Encore un immense merci à Jean-Michel et David qui se sont décarcassés pour nous concocter cette rencontre! Merci aussi à tous les sponsors sans qui nous n'aurions pas eu à manger, ni une salle aussi agréable pour le samedi midi, ni une salle pour nous accueillir... et une mention spéciale à Jean-Michel (Hybird) et David (Biologeek) qui ont été sponsors en plus d'organiser le tout!

Je repars de cette rencontre avec un sentiment d'appartenance à une communauté (comme joliment écrit par @metamatik), et la hâte d'être à l'année prochaine, pour une édition qui sera sans aucun doute encore meilleure! Et il me faut maintenant jeter un coup d’œil a quelques solutions techniques qu'on m'a fortement recommandées et que je ne connais pas encore : sentry, go-run, jenkins, integrity.

Ils en parlent sur leur blog

J'ai créé un salon convore listant les billets des participants qui font leur retour sur cette rencontre. N'hésitez pas à compléter!

django et le handler500: retourner une erreur 503

2011-04-14T17:04:00+02:00

Une mise en production ratée ? Un (local) settings oublié ? Un bug inconnu jusqu'alors ?

Dans les trois cas cités, il y a de fortes chances pour que vos utilisateurs voient une erreur 500 (internal server error : erreur interne du serveur). Il est facile, en peaufinant son template 500.html d'afficher un message d'erreur sympatique à l'utilisateur, pour lui expliquer qu'il suffit de patienter, que vous êtes sur la brèche, et que ce bug est en cours de résolution!

En effet, votre serveur de production n'étant pas en DEBUG = True (hein, rassurez-moi), et si vous avez conservé le mécanisme par défaut de django qui vous notifie des erreurs 500 par mail, vous êtes déjà au courant du soucis.

Seulement, si un crawl bot (robot indexeur) passe par là, il va tomber sur une page (ou plusieurs) qui ne fonctionne(nt) pas. Je ne sais pas quel est l'impact sur le classement de votre site, mais ce qui est sûr, c'est que ce genre d'erreur (ainsi que les erreurs 4xx) ne peut avoir qu'un impact négatif.

Heureusement, il existe le code d'erreur 503 (service unavailable : service indisponible) qui permet de spécifier un header Retry-After (réessayer après), avec une durée ou une date.

Voici comment détourner le handler500 fournit par défaut par django, pour renvoyer un code d'erreur 503, et le header associé, dans notre cas, un Retry-After d'une heure :

Créer son propre handler

Pour celà, créer par exemple le fichier utils/handlers.py :

#!/usr/bin/env python
# -*- coding: utf-8 -*-

from django import http
from django.views.decorators.csrf import requires_csrf_token
from django.template import Context, loader

class MyHttpResponseServerError(http.HttpResponse):
    status_code = 503

    def __init__(self, *args, **kwargs):
        http.HttpResponse.__init__(self, *args, **kwargs)
        self['Retry-After'] = '3600'

@requires_csrf_token
def handler500(request, template_name='500.html'):
    """Error handler that returns a 503 status code and a Retry-After header.

    Returning a 503 error code will tell crawl bots to retry later.

    """
    t = loader.get_template(template_name)
    return MyHttpResponseServerError(t.render(Context({})))

Détourner le handler500 par défaut

Et maintenant, il suffit de spécifier dans son ROOT URLCONF (le fichier urls.py à la racine du projet) :

handler500 = 'utils.handlers.handler500'

Conclusion

Il est difficile de savoir si retourner un statut 503 est préférable à un statut 500, en particulier sur le ranking dans les moteurs de recherche. Il y a bien une réponse (approchante) d'un employé de Google qui laisse penser qu'un 503 est recommandé. Dans tous les cas, je trouve plus sympa et propre d'avoir une erreur indiquant clairement que c'est un soucis temporaire, avec un ordre d'idée du délai avant de réessayer de visiter cette url.

Qu'en pensez-vous?

La technique pomodoro : retour après plus d'un mois d'utilisation

2011-04-04T09:58:00+02:00

Ça y est, j'ai franchi la barre (fatidique?) de un mois d'utilisation de ma nouvelle habitude, ce qui, selon certains, en fait une habitude durable.

Je me fends donc d'un billet, suite à l'article précédent: La technique pomodoro : retour après deux semaines d’utilisation.

Reprenons les points principaux de mon précédent billet:

Les points positifs

La gestion des interruptions

Un des deux points principaux dans mon utilisation de cette technique, mais avec une petite modification : un pomodoro entammé m'aide à me concentrer sur ma tâche en cours, et à ne pas être interrompu par toutes les notifications "sociales sur le web" (mail, twitter, skype, irc...). Par contre, je me suis rendu à l'évidence, elle ne me permet pas de me protéger des interruptions réelles, telles que coups de téléphone, coup de sonnette à la porte, ...

Lors d'une interruption IRL, je distingue plusieurs cas:

interruption pour le travail liée à ma tâche en cours : coup de téléphone pour un retour de test où une question sur mon projet en cours
interruption pour le travail non liée à ma tâche en cours, mais très courte et ne nécessitant pas de réflexion intellectuelle : coup de téléphone me demandant si j'ai bien reçu un courrier, demande de précision sur un autre projet...
interruption non liée au travail

Dans le premier cas, je n'interromps pas le pomodoro, voire même j'enchaîne sur un autre pomodoro immédiatement après (en zappant la pause) si nécessaire.

Dans les deux derniers cas, je met le pomodoro en pause, et je le reprends une fois l'interruption terminée

Comptabiliser le temps passé, aide à l'estimation d'une tâche

Avec le point précédent, le plus grand avantage que j'y trouve dans mon utilisation de cette technique : j'ai regroupés les deux points, vu qu'ils me semblent vraiment liés. Je tiens le compte du temps que j'ai passé sur telle ou telle tâche, ce qui peut me servir pour un compte rendu, ou par la suite pour ajuster mes estimations.

Après plus d'un mois d'utilisation, je commence à voir les points sur lesquels il faut que j'ajuste mes estimations, et ceux sur lesquels j'ai assez d'expérience et de retour pour coller au plus proche de la réalité.

Aide à l’organisation

Même si, comme je l'indiquais précédemment, la technique pomodoro n'est pas à proprement parler la technique GTD, elle me permet d'avoir une liste de tâches à faire (à plus ou moins long terme), une sorte de pense-bête, et une autre liste pour les tâches "en cours", à réaliser dans la journée ou à très court terme.

Les points négatifs

Les 25 minutes de Pomodoro

J'hésite beaucoup moins à présent à stopper la tâche en cours, qui me demanderait "juste une minute de plus", pour prendre ma pause, puis enchaîner sur un nouveau pomodoro. En effet, un pomodoro effectué est une victoire, pas un échec, cf ci-après.

Les pauses

J'en parlais, et je persiste et signe : les pauses sont importantes, pour plusieurs raisons

savoir qu'on a une pause dans X minutes permet de garder sa concentration sur la tâche en cours, et motive pour ne pas craquer et succomber aux notifications et interruptions diverses
une pause permet de souffler un peu, détendre les muscles de ses épaules, jeter un oeil par la fenêtre, et par la même occasion faire travailler les muscles occulaires
combattre l'effet "tête dans le guidon" : je ne pense pas être le seul dans ce cas. Lors d'un développement, il arrive qu'on se focalise sur une solution, une implémentation, et une fois terminé, on se rends compte qu'il existait une solution bien plus élégante et/ou simple. Eh bien toutes les 30 minutes, on a une chance de s'en rendre compte avant d'y avoir passé une journée !

Les interruptions

Voir les points positifs sur ce sujet : plutôt que de m'échiner à me protéger des interruptions IRL, j'ai préféré faire avec et adapter la technique à mes besoins.

Le pomodoro effectué est une victoire, pas un échec

L'avoir écrit m'a permit de le réaliser lors de la rédaction de mon précédent billet. La méthode du rubber ducking victorieuse à nouveau!

Les points à travailler

J'avais listé les points suivants:

respect des pauses
ressenti de la fin d'un pomodoro qui doit être positif
gestion des interruptions
utilisation de la technique en télé-travail

Au vu de ce que j'ai écrit plus haut, je pense avoir trouvé la solution qui me convenait pour chacun de ces points. Respect des pauses et ressenti d'un pomodoro effectué allant de pair, et gestion des interruptions "souple" qui me permet de ne pas gaspiller mon énergie à aller à contre courant.

Conclusion

Cette technique, avec les quelques adaptations que j'y ai apportées pour coller au mieux à ma méthode de travail, me convient parfaitement. Je pense m'être un peu écarté de la philosophie de la technique officielle, en n'annulant pas un pomodoro interrompu par une interruption IRL, mais je suis content de pouvoir à présent mieux gérer et suivre mon temps de travail effectif et productif.

La gestion des interruptions "sociales" me permet aussi d'optimiser mon temps de travail, et d'améliorer le rapport "travail effectif" / "temps passé devant l'ordinateur".

Quelques chiffres:

reccord de pomodoros dans une journée : 22
reccord de pomodoros sur deux jours de week-end : 15
moyenne de pomodoros en semaine : 11
moyenne de pomodoros les jours avec 2 tâches ou moins : 12.4
moyenne de pomodoros les jours avec 3 tâches : 11
moyenne de pomodoros les jours avec 4 tâches ou plus :10.2

Il semblerait donc, après un mois d'utilisation, que ce qui joue sur le nombre de pomodoros par jour soit le nombre de tâches différentes à effectuer par jour, et donc le nombre de fois où il faut que je fasse un changement de contexte. Changer de tâches régulièrement n'est pas anodin, et conforte ma croyance que le cerveau n'est pas multi-tâche (hein No`!).

Mais plus que le nombre de tâches par jour, je pense que c'est l'état de fatigue nerveuse qui influe le plus. Après une semaine à faire en moyenne 15 pomodoros par jour (et un reccord de 22), je sens que les jours à venir vont devoir être plus détendus.

Et si il y a un seul élément à retenir et à surveiller, c'est le sommeil. Une journée sans avoir assez dormi la veille sera une journée molle, avec beaucoup de mal pour me concentrer, et une bien plus grande tentation de papillonner au gré des notifications. Depuis maintenant deux semaines, j'ai changé mon rythme de sommeil, et ne met plus mon réveil le matin. Je dors donc entre 8 et 9h par nuit, et je me sens beaucoup plus efficace dans la journée ! Ce sera peut-être le thème d'un futur billet ;)

Ce billet a été écrit en deux pomodoros complets, non interrompus.

La technique pomodoro : retour après deux semaines d'utilisation

2011-03-02T16:35:00+01:00

Voici deux semaines maintenant que j'ai décidé d'essayer la technique Pomodoro de gestion du temps. En attendant le retour d'expérience au bout d'un mois (cf le 30 days to success), voici déjà mes réflexions à mi-chemin.

Le principe

Il est simple, très simple, et c'est d'ailleurs un des points forts de cette technique : la facilité de compréhension et de mise en œuvre.

Voici la traduction de ce qu'on peut trouver sur la page d'accueil du site de la technique :

choisir une tâche à accomplir
régler le Pomodoro sur 25 minutes (le Pomodoro est le minuteur)
travailler sur la tâche jusqu'à ce que le Pomodoro sonne, et faire une croix sur une feuille de papier
faire une courte pause (5 minutes)
tous les 4 Pomodoros, faire une pause plus longue (30 minutes)

On peut ensuite rajouter quelques points à faire dans la journée :

tenir une liste à jour de toutes les tâches à faire
chaque début de journée, choisir les tâches à faire pour la journée en cours, et estimer le nombre de Pomodoros nécessaires pour chacune
en fin de journée, faire le compte du nombre de Pomodoros effectués dans la journée, faire le point sur les estimations
lors d'une interruption
- si c'est possible, la noter sur une feuille "interruptions et imprévus", et s'en occuper à la fin d'un Pomodoro
- si il faut s'en occuper de suite, le Pomodoro en cours est perdu, et ne doit pas être comptabilisé

Les points positifs

Commençons par les bons côtés :

La gestion des interruptions

Et c'est pour ce point en particulier que je comptais sur la technique Pomodoro, et je ne suis pas déçu. De nos jours, surtout si on est présents sur les réseaux sociaux (twitter pour ma part), sur irc, qu'on suit des flux RSS, ou même seulement si on surveille ses mails, on est baignés dans un flot d'informations. Ce flot n'est pas passif, puis qu'il y a de très nombreuses notifications possibles, entre celles du navigateur, de clients divers, de "highlights" irc...

Or là, la règle est simple : pendant un Pomodoro, on reste concentré sur la tâche qu'on s'est assignée, et on ignore les notifications. Et il est beaucoup plus facile de les ignorer si on sait qu'on pourra y succomber dans x minutes. Dès lors, on travaille d'une traite pendant 25 minutes, et la productivité augmente.

Comptabiliser le temps passé

Rien de plus facile : en fin de journée, il suffit d'additionner les petites croix tracées sur sa feuille pour savoir qu'on a travaillé n * 30 minutes. Je compte toujours les 5 minutes de pause dans le temps de travail, car sans ces pauses, il ne serait pas possible de rester concentré et productif. De la même manière qu'un employé de bureau ou un ouvrier ne va pas décompter ses pauses café, je ne décompte pas ces pauses qui sont, j'en suis persuadé, indispensables au bon déroulement d'une journée de travail.

Aide à l'estimation de la durée d'une tâche

En temps qu'informaticien, on me demande constamment des estimations de durées : que ce soit pour régler un problème, implémenter une nouvelle fonctionnalité, expérimenter de nouvelles solutions ... et ce, pour un devis, pour avoir une date de mise en production ...

Lorsque je rajoute une tâche dans ma liste, j'y met une estimation en nombre de Pomodoros. Je peux ainsi voir les écarts entre cette estimation et le temps qu'il m'a fallut en réalité en fin de journée. Et j'ai bon espoir que cet écart baisse avec l'exercice !

Aide à l'organisation

J'imagine que tout le monde à déjà entendu parler du GTD, cette méthode qui permet de s'organiser afin de "faire les choses". Eh bien avec la technique Pomodoro, j'ai déjà une liste de tâches à faire, et une liste de tâches que j'ai prévues pour la journée. Il y a pas mal de points communs, et je pense que les adeptes de la méthode GTD peuvent y trouver leur compte.

Les points négatifs

Du côté des points négatifs, voici ceux que j'ai pu lister jusqu'à présent. Je n'utilise la technique que depuis deux petites semaines, et concerne principalement les soucis que j'ai rencontrés lors de l'application de la technique à mon emploi en télé-travail.

Les 25 minutes de Pomodoro

25 minutes de travail, de concentration, puis 5 minutes de pause. Et 30 minutes de pause toutes les deux heures. Sauf que c'est pas toujours aussi évident.

Je me retrouve sans cesse confronté à des tâches qui me demandent "juste une minute de plus". Une minute de plus pour envoyer un mail de notification suite à un problème résolu. Ou une minute de plus pour mettre en production une fois que tous les tests sont passés. Je dis une minute, mais ça peut être 2 minutes, voire 5 ... où s'arrêter ? A quel point il faudrait plutôt faire une pause, et y passer un Pomodoro de plus ?

Lorsqu'une tâche est plus courte qu'un Pomodoro, il est conseillé de "sur-apprendre", de mettre à profit ce temps pour perfectionner son geste. Il m'est arrivé, pour un Pomodoro où il me restait 15 minutes, de refaire mon système de déploiement (merci Fabric). Super ! sauf que du coup j'ai enchaîné sur un Pomodoro supplémentaire (non prévu en début de journée), pour finaliser la réécriture de mon fabfile.

Les pauses

Pour continuer sur le point précédent, je trouve ça parfois très dur de prendre la pause de 5 minutes. Si je suis concentré, dans le flow, il m'est très difficile de m'interrompre pour cette pause.

Si il ne manque qu'une minute, je suis tenté de continuer pour terminer (et je le fais très souvent). Si je suis vraiment bien lancé, j'ai parfois peur que la consultation de mes mails/irc/twitter/rss me déconcentrent, me fassent sortir de mes rails, et que du coup ce soit plus difficile de m'y remettre pour terminer ce que j'avais commencé.

Travaillant de la maison, je n'ai toujours pas réussi à respecter les pauses de 30 minutes. Comme il m'arrive de devoir travailler sur des tâches non prévues, et trop courtes pour mériter un Pomodoro (réponse à un mail pro par exemple), je déborde sur les pauses de 5 minutes, en me disant que je me rattraperais avec ma pause repas par exemple.

Dans d'autres cas, j'arrête tout simplement le timer à la fin d'un Pomodoro (pause repas, vaisselle, allumer un feu...), et je zappe la pause (de 5 minutes ou de 30 minutes, selon les cas). Mais du coup, je pense perdre les avantages et la satisfaction de l'enchaînement de Pomodoros.

Les interruptions

Je suis en télé-travail, et il m'arrive, en général deux ou trois fois dans la journée, d'avoir des interruptions de collègues de travail qui ont besoin de moi. Ce peut être par skype ou téléphone, et c'est en général difficile à reléguer à la fin d'un Pomodoro : si il me reste 15 minutes avant la fin, je ne peux pas "mettre en pause" mon collègue qui a ses tâches à lui.

Ces interruptions peuvent être très courtes (quel est mon mot de passe pour le serveur bidule?), ou plus ou moins longues (on a un serveur en rade, tu peux t'y coller de suite?). Que faire dans ce cas ? En théorie, je dois interrompre mon Pomodoro et le "perdre", mais du coup je ne peux plus me servir du nombre de Pomodoros effectués dans la journée pour suivre le temps travaillé, et il me faut alors me servir d'un outil supplémentaire (le projet hamster par exemple).

Pour le moment en tout cas, je met le minuteur en pause, et le recommence après l'interruption, si elle a été assez courte et assez peu "mentale" pour ne pas m'avoir déconcentré.

Le pomodoro effectué est une victoire, pas un échec

En tout cas, en théorie, c'est comme ça que je devrais le ressentir. Le slogan de la technique Pomodoro, c'est de faire du temps un allié. Or quand je vois que je viens de finir un Pomodoro (de plus!) sur une tâche que j'avais sous-estimée, je culpabilise. Et je rechigne à repartir pour un Pomodoro supplémentaire.

Il faut que j'apprenne à voir un Pomodoro effectué comme une réalisation, une victoire, une bonne chose de faite. Et si j'ai sous-estimé la tâche, que cela me serve de leçon pour la prochaine.

Les points à travailler

Il me reste encore deux bonnes semaines avant mon prochain point et retour sur expérience. D'ici là, il faut que je travaille sur :

le respect des pauses : comme je l'indiquais en début de ce billet, je compte les 5 minutes de pause dans mon temps de travail, et je suis persuadé qu'elles sont indispensables. J'ai plus de mal avec les pauses de 30 minutes, et c'est là-dessus qu'il faut que je mette le paquet
ressenti de la fin d'un pomodoro qui doit être positif
gestion des interruptions : il faut que je prenne au moins une note de chacune des interruptions que je n'ai pu remettre, même si je ne "perds" pas systématiquement le Pomodoro en court. Une croix pour chaque fois que je dois mettre le minuteur en pause, retour dans 15 jours ;)
utilisation de la technique quand on est en télé-travail : est-ce qu'il y aurait un moyen d'indiquer, par exemple par un statut ou un indicatif de présence (skype, irc...) à mes collègue de travail que je suis en cours de Pomodoro ? à creuser...

Je sais qu'il y a au moins une personne qui serait intéressée par le dernier point : @dzen a plusieurs fois émis l'idée de synchroniser les Pomodoros entre utilisateurs du salon irc ;)

Conclusion

On m'avait prévenu, mais j'ai quand même été surpris : on fait beaucoup moins de pomodoros qu'on imagine ! Je me met devant le PC vers 6h le matin, et j'arrête ma journée de travail vers 20h (quand ça se passe bien ;). Je dois donc passer plus de 12h devant le pc, et en comptant large sur les pauses et interruptions, je pensais être productif au moins pendant 8 à 9 heures.

Et bien au final, sur les deux semaines passées, je suis en général entre 10 à 12 Pomodoros par jour, si je ne compte que les 5 jours de semaine. Ce qui fait donc entre 5 et 6 heures de productivité par jour.

A cela il faut bien entendu rajouter toutes les interruptions téléphoniques, le temps passé à répondre aux mails, la comptabilité... toutes ces tâches que je ne me vois pas (pour l'instant?) consigner dans des Pomodoros, mais que du coup, je ne compte pas non plus dans mon "temps travaillé" en fin de journée.

Ah, et pour les malins qui me diront que le pluriel de Pomodoro, c'est Pomodori, je leur répondrais que :

on peut soit utiliser pomodori soit pomidoro
sur le site officiel, ils utilisent pomodoros
je fais bien ce que je veux, na!

Ce billet a été écrit en

3 Pomodoros complet avec 2 micro-interruptions
1 Pomodoro interrompu (4 fois!)

django: redimensionner une image à la volée en préservant son ratio

2011-02-16T13:15:00+01:00

Une rapide recherche sur "django image thumbnail" vous sortira très vraisemblablement de nombreuses solutions : snippets, applications, astuces... en particulier la page Thumbnails sur le wiki de django qui liste beaucoup de solutions et leurs avantages.

Voulant faire simple, et profiter de toutes les améliorations que j'ai pu trouver et compulser sur diverses solutions, voilà ma contribution.

Utiliser PIL et Image.thumbnail()

Python Image Library est une des (la?) solutions les plus avancées sur le traitement d'image en python. Dans mon cas pratique, je veux, lors d'un upload d'une photo, pouvoir :

redimensionner la photo, pour qu'elle fasse au maximum 800x600 : elle sera affichée avec un max-width et un max-height
créer un thumbnail
stocker les images au format jpg
tout ceci sans au préalable sauver l'image sur le disque

Beaucoup des solutions que j'ai pu trouver utilisaient la fonction resize() de PIL.Image, et utilisaient un calcul du ratio pour conserver l'aspect de l'image. Heureusement, PIL a pensé au fainéant que je suis, et fournit la fonction thumbnail() qui va automatiquement redimensionner l'image pour qu'elle rentre dans les dimensions maximales qu'on lui fournit.

Le modèle

Modèle très simple pour illustrer notre propos :

class Foo(models.Model):
    photo = models.ImageField(upload_to='photos/')
    thumbnail = models.ImageField(upload_to='photos/thumbs/')
    legend = models.CharField(max_length=50)

La solution

Cette solution est largement inspirée de cet article qui collait le plus à la version que je souhaitais obtenir au final : generate thumbnails in django with PIL.

Tout d'abord le morceau de code qui récupère l'image en mémoire (stockée dans un InMemoryUploadedFile) et la converti en mode RGB si nécessaire :

from PIL import Image
from cStringIO import StringIO
from django.core.files.uploadedfile import SimpleUploadedFile

...

    def save(self, *args, **kwargs):
        if has_changed(self, 'photo'):
            # on va convertir l'image en jpg
            filename = path.splitext(path.split(self.photo.name)[-1])[0]
            filename = "%s.jpg" % filename

            image = Image.open(self.photo.file)

            if image.mode not in ('L', 'RGB'):
                image = image.convert('RGB')

            # d'abord la photo elle-même
            self.photo.save(
                    filename,
                    create_thumb(image, settings.IMAGE_MAX_SIZE),
                    save=False)

            # puis le thumbnail
            self.thumbnail.save(
                    '_%s' % filename,
                    create_thumb(image, settings.THUMB_MAX_SIZE),
                    save=False)

Et enfin la fonction create_thumb qui prends en paramètre une PIL.Image et une taille du style (800, 600) :

def create_thumb(image, size):
    """Returns the image resized to fit inside a box of the given size"""
    image.thumbnail(size, Image.ANTIALIAS)
    temp = StringIO()
    image.save(temp, 'jpeg')
    temp.seek(0)
    return SimpleUploadedFile('temp', temp.read())

Retourner un SimpleUploadedFile permet de le fournir directement au save() de l'ImageField.

Le bonus

Vous avez sûrement remarqué la fonction has_changed() dans l'appel de la méthode save() ci-dessus... en effet, il serait peu utile, voire même carrément indésirable de générer une nouvelle version de la photo et de son thumbnail à chaque fois que notre modèle est sauvé!

On se retrouverait vite avec autant de photos et de thumbnails que le nombre de fois qu'on a sauvé notre modèle, même si la seule modification portait sur la légende.

Pour limiter ça, on ne redimensionne et génère le thumbnail que si la photo a été modifiée, ce qu'on teste avec la fonction suivante :

def has_changed(instance, field, manager='objects'):
    """Returns true if a field has changed in a model

    May be used in a model.save() method.

    """
    if not instance.pk:
        return True
    manager = getattr(instance.__class__, manager)
    old = getattr(manager.get(pk=instance.pk), field)
    return not getattr(instance, field) == old

Django forms, HTML5 et fieldsets

2011-02-11T22:56:00+01:00

J'adore l'open-source, et j'adore le libre.

Aujourd'hui, à 20h30, je me dis que j'aimerais bien pouvoir utiliser les nouveaux form input de HTML5 dans mes formulaires django. Je me rappelle alors de l'excellent django-floppyforms de ce cher Bruno Renié.

django-floppy-forms : la librairie de widgets

Quelques minutes et un pip install django-floppyforms plus tard, je me retrouve avec un petit formulaire de test :

#!/usr/bin/env python
# -*- coding: utf-8 -*-

import floppyforms as forms


class TestForm(forms.Form):
    name = forms.CharField()
    email = forms.EmailField(widget=forms.EmailInput(attrs={'placeholder': 'john@example.com'}))
    url = forms.URLField()

Ce qui me donne le résultat visuel suivant :

On y voit bien le placeholder dans le champ de type email. Sur l'image suivante, on voit la validation faite directement au niveau du browser (firefox 4b11) :

A 20h45 : "ce que j'aimerais vraiment bien, c'est pouvoir scinder mon formulaire en fieldsets, comme le permet l'administration de django". Va-t-il falloir que je me mette à développer? Que nenni, cher lecteur, comme tu l'aura deviné, un autre développeur de talent, un certain Carl Meyer nous propose le très pratique django-form-utils.

django-form-utils : une méthode propre pour spécifier des fieldsets

Encore quelques minutes et un pip install django-form-utils plus tard, voici le code du formulaire :

#!/usr/bin/env python
# -*- coding: utf-8 -*-

import floppyforms as forms
from form_utils.forms import BetterForm


class TestForm(BetterForm):
    name = forms.CharField()
    email = forms.EmailField(widget=forms.EmailInput(
                attrs={'placeholder': 'john@example.com'}))
    url = forms.URLField()

    class Meta:
        fieldsets = [
            ('test', {
                'fields': ['name', 'email'],
                'legend': 'a test legend',
            }),
            ('other test', {
                'fields': ['url'],
                'description': 'a test description',
                'classes': ['advanced', 'collapse']
            }),
        ]
        row_attrs = {'name': {'style': 'background: #f00'}}

Et le template, un poil plus complexe que le {{ form.as_p }} précédent :

{% if form.non_field_errors %}{{ form.non_field_errors }}{% endif %}
{% for fieldset in form.fieldsets %}
<fieldset class="{{ fieldset.classes }}">
    {% if fieldset.legend %}<legend>{{ fieldset.legend }}</legend>{% endif %}
    {% if fieldset.description %}
        <p class="description">{{ fieldset.description }}</p>
    {% endif %}
    {% for field in fieldset %}
        {% if field.is_hidden %}
            {{ field }}
        {% else %}
            <p{{ field.row_attrs }}>
                {{ field.errors }}
                {{ field.label_tag }}
                {{ field }}
            </p>
        {% endif %}
    {% endfor %}
</fieldset>
{% endfor %}

Et voici le résultat (les moqueurs reconnaîtrons mon talent pour tout ce qui touche au design) :

21h00 : Tout ça est vraiment super. Mais... quitte a être exigeant, est-ce que je pourrai avoir des fieldsets ET un template plus simple? Par exemple un layout générique du style uni-form... c'est là que Daniel Greenfeld entre en jeu avec son projet pour djangonautes fainéants django-uni-form.

django-uni-form: les uni-forms pour django

Vous connaissez le refrain, quelques minutes et un pip install django-uni-form plus tard :

#!/usr/bin/env python
# -*- coding: utf-8 -*-

import floppyforms as forms
from django.forms import Form
from uni_form.helpers import FormHelper, Submit
from uni_form.helpers import Layout, Fieldset


class TestForm(Form):
    name = forms.CharField()
    email = forms.EmailField(widget=forms.EmailInput(
                attrs={'placeholder': 'john@example.com'}))
    url = forms.URLField()
    helper = FormHelper()
    layout = Layout(Fieldset('a test legend', 'name', 'email'),
                    Fieldset('other test', 'url'))
    helper.add_layout(layout)
    submit = Submit('submit','test this form')
    helper.add_input(submit)

Et le template, beaucoup plus simple du coup :

{% load uni_form_tags %}
{% with form.helper as helper %}
    {% uni_form form helper %}
{% endwith %}

Conclusion

Il fait bon être fainéant, utiliser django, et les outils déjà disponibles en open-source. Les applications que j'ai présentées ici ont été bien pensées, et sont pluggable : on peut facilement les rajouter à son projet et les utiliser ou même les combiner!

Dans notre cas on a pu tester l'utilisation de widgets html5 (django-floppy-forms) avec un layout par fieldset défini dans la class Meta du formulaire (django-form-utils), ou grâce à un helper (django-uni-form).

Pour le moment mon cœur balance entre les deux, la solution utilisant la sous-class Meta me paraissant plus naturelle, mais l'utilisation d'un layout robuste et soigné comme les uni-form étant plus simple, "standard" et économisant plus de temps.

A quand un projet permettant d'hériter d'une classe UniForm, dans laquelle on définit les fieldsets dans une sous-classe Meta ?

Ah, au fait, de 21h00 à 23h00, écriture de ce billet... une demi heure pour tester trois projets, et presque deux heures pour en parler, personne n'aurait une pluggable app qui pond des billets ?

Double encodage utf8 : afficher correctement avec python et django

2010-12-27T16:39:00+01:00

Nous avons vu dans un précédent article qu'il pouvait y avoir des soucis de double encodage utf8, par exemple pour des textes stockés dans une base de donnée.

Imaginons, un court instant (parce que plus longtemps que ça, ce serait bien trop douloureux hein ;)), que nous ayons une base de donnée avec certains champs de certaines tables qui sont doublement encodés en UTF-8, par exemple le champ name.

Le problème

Voici à quoi ressemblerait le modèle Django d'une telle table :

class Foo(models.Model):
    name = models.CharField(max_length=70)

    def __unicode__(self):
         return self.name

Et voici un exemple d'affichage (dans l'admin) du nom d'un tel modèle : HelicoptÃ¨re

En effet, Hélicoptère, représenté en utf8 par Helicopt\xe8re, est stocké en latin1 par MySQL, et donc renvoyé (doublement) encodé en utf8 sous la forme Helicopt\xc3\xa8re.

La solution

Puisque la donnée est doublement encodée, il suffit de la décoder une fois :

>>> f = Foo.objects.get(name__startswith='Helico')
>>> f.name
u'Helicopt\xc3\xa8re'
>>> f.name.encode('latin1')
'Helicopt\xc3\xa8re'
>>> f.name.encode('latin1').decode('utf8')
u'Helicopt\xe8re'

Et le tour est joué!

Un affichage (presque) propre avec django

Dans django, il est possible de spécifier une méthode __unicode__ sur un modèle, pour gérer son affichage par défaut, qui est utilisé notamment dans l'affichage des listes d'objets d'un modèle, dans l'administration.

Nous pouvons donc modifier la méthode de notre modèle indiqué en début de cet article :

def __unicode__(self):
     return self.name.encode('latin1').decode('utf8')

Mais... tout n'est pas parfait

Il faut penser aux points suivants :

il faut bien utiliser __unicode__ à la place de name partout où c'est possible, par exemple si on spécifie un list_display dans le ModelAdmin
lorsqu'on éditera l'objet, le name doublement encodé apparaîtra, et si on le modifie manuellement pour s'afficher correctement, on aura une incohérence dans la table, avec des données doublement encodées, et d'autres stockées correctement

Une autre méthode

Il est possible de spécifier des options lors de la connexion à la DB MySQL, avec django, pour lui demander d'utiliser le charset latin1. Vu que django lui-même ne parle qu'en utf8, demander à MySQL des données en latin1 revient à lui demander de ne pas ré-encoder la donnée qu'il pense être stockée en latin1, mais qui sera ensuite correctement affichée par django :

DATABASES = {
    'hack': {
        'NAME': 'bar',
        'ENGINE': 'django.db.backends.mysql',
        'USER': 'baz',
        'PASSWORD': 'bizbaz',
        'HOST': 'localhost',
        'PORT': '',
        'OPTIONS': {
            'charset': 'latin1',
            'use_unicode': False,
        },
    },
}

L'avantage ici est qu'il n'y a pas besoin d'avoir un traitement spécifique des données, par exemple dans la méthode __unicode__, et que toutes les données lues seront dé-doublement-encodées (!?).

Le gros inconvénient est que toutes les tables subiront le même traitement, même celles qui ont un encodage et stockage correct. L'utilisation d'un routeur et d'une deuxième entrée dans les DATABASES uniquement pour les tables ayant un soucis n'étant pas une solution durable non plus, car celà limite les relations entre tables.

Et tant qu'à faire dans le crade

La solution la plus dangereuse serait d'avoir un traitement "par défaut" de toutes les données qu'on veut afficher, pour :

régler le problème du double-encodage si il y en a un
afficher la donnée brute si on ne peut pas dé-double-encoder

Exemple :

def __unicode__(self):
    try:
        return self.name.encode('latin1').decode('utf8')
    except:
        return self.name

On ne se pose alors plus la question de la cohérence des données et de leur encodate et stockage dans la base de donnée, mais on se met à dos une énorme dette technique : le développement du traitement spécifique de toutes les colonnes de toutes les tables le nécessitant peut être titanesque, et bien plus lourd que la correction du problème à la base.

Conclusion

Rien ne vaut une DB saine, ses tables étant toutes encodées correctement. Si vous commencez à utiliser des workarounds ou hacks divers, vous vous en mordrez les doigts (il me manque déjà plusieurs phalanges, croyez-moi).

La dette technique (métaphore inventée par Ward Cunningham) est une plaie dont il faut se préserver au maximum, et qu'il faut rembourser le plus tôt possible.

La vie a la couleur qu'on veut bien lui donner

2010-11-15T08:53:00+01:00

Ce billet n'est pas technique, il est une manière pour moi de mettre par écrit, mettre en mots, un état d'esprit, une réflexion sur ma propension a râler et rouspéter à la moindre occasion.

Je suis un râleur

Je le sais, je le reconnais, et ce depuis longtemps. Ce que je ne sais pas, c'est pourquoi.

Je pense avoir toujours eu de la chance, moins que d'autres sûrement, mais bien plus, infiniment plus que d'autres : SDF, exclus, souffrants d'un handicap, rejetés par leur famille (peut-être le plus grand des malheurs?), torturés, génocidés (je suis d'origine arménienne), victimes de la famine, d'épurations ethniques, d'ouragans, de guerres civiles, de despotes et dictateurs en tous genre...

Mon empathie me fait souvent souffrir pour les victimes d'injustices, les laissés pour comptes, les galériens qui trimeront toute leur vie pour ne pas arriver à subvenir à leurs besoins et ceux de leur famille.

De mon côté, j'ai eu une enfance vraiment dorée, entouré de parents aimants et de trois petites sœurs adorables. Je n'ai jamais manqué d'un toit ni de nourriture. Même si nous n'étions pas aisés, je n'ai jamais ressenti le moindre besoin.

Je suis maintenant (jeune) marié à une femme extraordinaire, que j'aime et qui m'aime (peut-être le plus grand des bonheurs?).

Mais je râle gentiment

Suite à une discussion ce matin avec un ami, qui me relance régulièrement pour que j'écrive un polar geek, je me suis remis en question. Voici notre échange :

<magopian> voilà pourquoi je ne sais pas écrire de nouvelles :
    ça finirait en rouspétage
<magopian> j'ai pas envie qu'on m'appelle le caliméro du polar geek ^^
<J-Mad> ben ca pourrait être une idée cool de perso
<J-Mad> un gros râleur
<J-Mad> qui râle pour tout
<J-Mad> un de mes amis est comme ça
<J-Mad> quand il rale pour des trucs insignifiants
<J-Mad> on sait que tout va bien, qu'il faut juste qu'il râle sur un truc

Un râleur continuel, le rouspéteur de service. Ce gars dont les révoltes ne sont qu'une expression naturelle de sa personnalité, une image de bougon, pas renfrogné mais facilement revendicateur.

Un gars sympa quoi, pas méchant, plutôt agréable, et un peu marrant avec ses coups de gueule et ses logorrhées inutiles.

Vraiment?

Mais alors, si j'ai autant de chance, de bonheur, si j'aime autant être de bonne humeur, rire, communiquer, partager, profiter, pourquoi râler?

Pourquoi véhiculer la mauvaise humeur, la rancoeur, la colère même? Je sais pourtant qu'un état d'humeur, que les sentiments sont contagieux. Pourquoi alors, ne pas véhiculer la joie de vivre et la motivation?

La vie a la couleur qu'on veut bien lui donner

Voilà la phrase, toute simple et pourtant lourde de (bonnes) conséquences, qu'une charmante dame m'a confié comme "astuce de bonheur". Une dame frappée par les malheurs, et qui pourtant a toujours le sourire aux lèvres.

"Moi, je veux la voir en rose, pas besoins de lunettes teintées d'enfant pour ça, c'est juste un état d'esprit!" m'a-t'elle confié.

Et bien moi aussi, je veux la voir en rose (en poney rose même, hein Zébuline ;)

lancer gunicorn avec supervisord

2010-08-31T16:48:00+02:00

Après avoir mis en place une méthode pour lancer gunicorn avec runit, voici un second article pour lancer ce même gunicorn (qui poutre du poney, rappelons-le), mais avec un outil que je trouve à l'utilisation bien plus pratique : supervisord

Pourquoi supervisord et pas runit ?

Après l'avoir utilisé sans aucun soucis depuis quelques temps sur le serveur de secours de notre site web, je trouve que supervisord est plus convivial à utiliser, et plus "clair" à mettre en place.

Plus convivial à utiliser parce qu'il a un client CLI qui permet d'interagir directement avec les processus monitorés, mais il y a aussi les mêmes fonctionnalités par le biais d'une interface web fort pratique.

Plus "clair" à mettre en place parce qu'il se lance grâce à un simple script d'init, et qu'on peut faire la configuration de tous ses processus à monitorer dans un seul et même fichier de configuration, au lieu d'avoir un répertoire et des liens symboliques à gérer (certains préfèrent peut-être cette modularité, mais personnellement je trouve ça beaucoup plus pénible à maintenir).

Installer supervisord

Etant donné que supervisord est en python, il est possible de l'installer avec un simple

$ pip install supervisor

Pour les old-school qui ne profitent pas encore de la puissance et de l'ergonomie de ce magnifique outil de Ian Bicking, il est possible de remplacer pip par easy_install (même si je vous conseille plutôt de faire un easy_install pip puis de vous passer de easy_install par la suite!).

Configurer supervisord

On le configure en deux temps : une première configuration de supervisord lui-même, puis l'ajout des processus qu'on veut qu'il monitore.

Dans le fichier /etc/supervisord.conf :

; configuration de supervisord lui-meme
[unix_http_server]
file=/tmp/supervisor.sock   ; chemin vers le fichier socket

[inet_http_server]
port=192.168.0.21:9001      ; adresse ip _LOCALE_ de la machine pour la connection web

[supervisord]
logfile=/var/log/supervisord.log ; fichier de log principal de supervisord

[rpcinterface:supervisor]
supervisor.rpcinterface_factory = supervisor.rpcinterface:make_main_rpcinterface

[supervisorctl]
serverurl=unix:///tmp/supervisor.sock ; connection pour le client CLI

; liste des processus qu'on veut confier a supervisord
[program:gu-www]
command=/path/to/venv/bin/python /path/to/venv/bin/gunicorn_django -b localhost:8080 --log-file=/path/to/log/gunicorn_gu-www.log --workers=3
directory=/folder/containing/settings/file/
user=www-data
autostart=true
autorestart=true
startsecs=10
redirect_stderr=true
stdout_logfile=/path/to/log/supervisor_gu-www.log

Bien entendu, faites en sortes que l'utilisateur www-data ai accès en écriture aux fichiers de log gunicorn_gu-www.log configuré où le processus échouera lors de son lancement.

ATTENTION: comme indiqué dans le commentaire pour la ligne de configuration inet_http_server il faut absolument faire en sorte que l'adresse ne soit pas accessible à tout le monde! En effet il est possible de redémarrer ou tout simplement stopper les processus par cette interface! Vous pouvez désactiver complètement cette possibilité en supprimant ces deux lignes, il n'y aura alors pas de moyen de contrôler supervisord par une page web.

La commande indiquée pour information lance gunicorn_django avec dans un environnement virtuel (ce que vous devriez faire vous aussi!). Il n'est pas nécessaire d'indiquer le chemin vers le fichier settings.py dans les options de gunicorn_django étant donné que le processus sera lancé directement dans le répertoire le contenant (si vous le configurez correctement avec le paramètre directory comme indiqué ci-dessus).

ATTENTION: il faut absolument que gunicorn_django soit lancé en foreground (en tâche principale, pas en arrière-plan/background/démon/daemon), ce qui est le cas par défaut si vous n'avez pas explicitement dit le contraire dans votre fichier de configuration (ou en paramètre de la commande) de gunicorn_django.

En effet c'est supervisord qui se charge de le faire : si le processus est lancé en arrière-plan, supervisord ne peut pas prendre la main dessus et le contrôler ni le monitorer, et va essayer de le lancer plusieurs fois d'affilée pensant qu'il échoue à chaque fois.

Lancer supervisord et le relancer à chaque reboot

Il suffit pour cela de créer un script de démarrage dans /etc/init.d/ et de le faire se lancer à chaque démarrage.

Dans /etc/init.d/supervisord :

#! /bin/sh
### BEGIN INIT INFO
# Provides:          supervisord
# Required-Start:    $remote_fs
# Required-Stop:     $remote_fs
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: Example initscript
# Description:       This file should be used to construct scripts to be
#                    placed in /etc/init.d.
### END INIT INFO

# Author: Dan MacKinlay
# Based on instructions by Bertrand Mathieu
# http://zebert.blogspot.com/2009/05/installing-django-solr-varnish-and.html

# Do NOT "set -e"

# PATH should only include /usr/* if it runs after the mountnfs.sh script
PATH=/sbin:/usr/sbin:/bin:/usr/bin:/usr/local/bin
DESC="supervisord"
NAME=supervisord
DAEMON=supervisord
MANAGE=supervisorctl
DAEMON_ARGS=""
PIDFILE=/var/run/$NAME.pid
SCRIPTNAME=/etc/init.d/$NAME

# Load the VERBOSE setting and other rcS variables
. /lib/init/vars.sh

# Define LSB log_* functions.
# Depend on lsb-base (>= 3.0-6) to ensure that this file is present.
. /lib/lsb/init-functions

case "$1" in
  start)
    $DAEMON
        ;;
  stop)
    $MANAGE shutdown
        ;;
  reload|force-reload)
    $MANAGE reload
    ;;
  restart)
    $MANAGE restart
        ;;
  *)
        echo "Usage: $SCRIPTNAME {start|stop|restart|reload|force-reload}" >&2
        exit 3
        ;;
esac

Ce script contient des commentaires en début de fichier qui permettent de le faire se lancer automatiquement à chaque démarrage :

$ chmod a+x /etc/init.d/supervisord
$ update-rc.d supervisord defaults 99 # le chiffre fourni est la priorité

Cette commande devrait indiquer qu'elle a créé tous les liens symbolique nécessaire pour lancer ce script à chaque démarrage du serveur. La priorité est le chiffre utilisé pour le nom du lien symbolique (S99supervisord, K99supervisord...). Les scripts sont lancés dans l'ordre croissant de ces chiffres : si on veut que supervisord se lance dans les derniers (recommandé, pour que tous les services indispensables soient déjà lancés), il faut un chiffre élevé.

Il ne reste plus qu'à lancer supervisord maintenant et vérifier que notre site est accessible :

$ /etc/init.d/supervisord start

Monitorer et contrôler ses processus

Soit en utilisant le client CLI :

$ supervisorctl

Soit en accédant à la page web dont on a configuré l'adresse dans le paramètre inet_http_server dans le fichier de configuration de supervisord. De là vous pouvez redémarrer vos processus, les arrêter, visualiser le contenu du fichier de log...

Un soucis?

Pensez à regarder dans les fichiers de log indiqués dans les paramètres pour voir si il y a des indications sur le problème
Vérifiez que la commande configuré dans /etc/supervisord.conf se lance correctement manuellement, et que le processus est bien en foreground
Faites un tour sur l'excellente documentation du projet supervisord

Edit du 2010-12-14 : rajout de la priorité de lancement lors de l'appel de la commande update-rc.d

PyCon.fr 2010 : retour sur une conférence organisée par l'AFPY

2010-08-30T08:53:00+02:00

Cette édition de PyCon.fr était la deuxième à laquelle j'ai assisté. Elle s'est déroulée, comme l'année dernière, à la CyberBase de la Cité des Sciences à la Villette, Paris.

Et comme l'année dernière, j'ai apporté ma maigre contribution à l'organisation sur place, aux côté des super-motivés de l'Association Francophone PYthon (liste non exhaustive : Christophe Combelles, Michael Scherrer, Gaël Pasgrimaud, Jean-Philippe Camguilhem, Olivier Grisel).

Le cadre

Nous avons été encore une fois super bien accueillis par la CyberBase. A disposition, un amphitéatre et une "base technique" (salle équipée de nombreux ordinateurs, idéale pour les mises en applications et les travaux pratiques). Les deux salles ont tout l'équipement nécessaire pour la rétro-projection des présentations, et avaient cette année encore la couverture vidéo de Ubicast.

Les sponsors

Vous trouverez la liste des généreux sponsors sur le site de PyCon.fr 2010. C'est en très grande partie grâce à eux qu'une telle conférence peut être organisée, en restant gratuite, j'en profite donc pour les remercier à nouveau (et les encourager à recommencer l'année prochaine bien évidemment ;).

Nous avons entre autres eu des présentations de plusieurs produits libres et open-source des sponsors Logilab (avec leur solution Cubic Web qui fait tourner le site de pycon.fr) et Itaapy.

Les présentations

Vous trouverez là aussi la liste sur le site de pycon.fr, et je vais lister ici les présentations auxquelles j'ai pu assister et qui m'ont marqué (les autres je les verrais en vidéo, grâce à Ubicast, dès qu'elles seront en ligne) :

plusieurs lightning talks, en particulier sur Pyaler, le GSoC sur distutils 2 (vivement que ça sorte!), pysandbox, restkit
Optimisation d'applications Django de Bruno Renié (mon co-champion "planet" pour django-fr ;) : plein d'astuces pour limiter le nombre de requêtes, utiliser le cache de manière intelligente ...
MongoKit de Nicolas Clairon : comment utiliser une base NoSQL MongoDB facilement et efficacement avec MongoKit
Analyse statistique et classification automatique de texte de Olivier Grisel : ça m'a replongé dans mon mémoire de DEA sur l'apprentissage automatique ;)
l'incontournabl)e Gunicorn de Benoit Chesneau : à mon avis, l'un des plus grands pas en avant pour rendre python (et Django) très facilement déployable
Construire un CMS sur mesure avec Django de Yann Malet : il faut arriver à vendre non pas du forfait (trop risqué pour le développeur, trop cher pour le client, et risque d'effet tunnel), mais des cycles de développement (par exemple de deux semaines, avec review + paiement à chaque cycle, puis décision sur le cycle suivant). Voilà quelque chose qui me plait, mais qui est très difficile à vendre à des clients qui veulent surtout pouvoir chiffrer de manière très précise leur budget
Programmation en Flux de Jonathan Schemoul : présentation de PyF qui permet de traiter de très nombreuses données en limitant la mémoire utilisée (grâce aux "flux"). Très intéressant, et un outil graphique en ligne qui m'a l'air très simple et pratique d'utilisation

Les rencontres

J'ai pu revoir nombre de personnes déjà rencontrées à l'édition de l'année précédent de PyCon.fr, ainsi qu'à Djangocong, personnes que je connaissais déjà auparavant par internet (irc, twitter, mailing lists de l'afpy et de django-fr ...). Revoir "en vrai" des personnes qu'on côtoie très souvent de manière électronique est pour moi toujours une joie et un enrichissement, car l'échange est bien plus facile, et on tisse des liens bien plus étroits autour d'une bière que par internet!

Et comme je l'ai déjà twitté, j'ai par ailleurs été ravi de faire de nouvelles connaissances, que j'espère pouvoir revoir bientôt (un an entre chaque pycon.fr, ça fait long!). Il paraît qu'il devrait y avoir d'ici peu un autre afpyro national organisé, il faudra essayer de rassembler les troupes sur Sophia/Nice à cette occasion! Peut-être une occasion de tester le pastis magique de Jean-Philippe (il m'a promis qu'il ferait un article là-dessus, que je lierai ici ;)

Les bonus

Comme si cela ne suffisait pas, il y a eu quelques bonus très sympathiques :

un écran géant et tactile dans la CyberBase qui affichait en boucle isparade.jp sur le mot clé #pyconfr
j'ai découvert aspirator de Bruno Renié, un news reader fait en django, et qui à l'air vraiment génial... ce gars est vraiment doué, ça en est limite énervant ;). Il travaille aussi sur wombat, un projet de client mail
j'ai revu une bonne partie de mon ex équipe de badminton qui prenait le même avion que moi! (ils étaient aux championnats du monde qui avait lieu ce même week-end sur Paris)
Alexis Métaireau (@ametaireau) nous a parlé de son travail pour le GSoC avec Tarek Ziadé sur distutils 2 : vivement que ce soit dans la stdlib!
Rémi Ubscher (@natim) est Eclaireur lui aussi! Salut Fennec ;)
Benoit Calvez (@_dzen) m'a parlé de fabulator et de vineolia : énorme potentiel (et il a d'autres projets dans les cartons ;)

Conclusion

Vivement la prochaine édition (peut-être sur Pau? ping Jean-Philippe ;) et d'ici là, peut-être une nouvelle édition d'une rencontre Django en france!

Encore un énorme merci aux organisateurs, sponsors, présentateurs, et aux participants, qui font de cet évènement un moment agréable et enrichissant!

djangocong : rencontre Django à Marseille

2010-04-28T08:19:00+02:00

Comment décrire en un mot cette rencontre Django à Marseille le 24 et 25 Avril :

Excellent !

Après cette entrée en matière fort peu cavalière, permettez-moi de développer en deux points :

Ce que j'ai retenu de ma conférence

Ma présentation portait sur toutes les astuces et raccourcis à la disposition des développeurs web, et s'intitulait Django Pour Les Fainéants.

Les points positifs :

le format "interactif" : faire participer le public le plus possible permet de le garder attentif, éveillé et intéressé
les "bons points" : un autre moyen de captiver l'attention, en récompensant par un bon point (humoristique) les participants
- bon point "glue" : le participant m'a posé une colle, à laquelle je ne sais répondre
- bon point "fainéant" : le participant a proposé une astuce/raccourcis/outil que je ne connaissais pas, ou n'ai pas présenté dans la présentation
- bon point "django pony" : le participant a partagé une bonne pratique django, ou parlé d'une astuce/raccourci/outil que je présentais dans une diapo suivante
- bon point "casse nouilles" : donné à un complice, ou quelqu'un dont on est sûr qu'il le prendra à la rigolade, et qui a fait une remarque sur une typo, une parenthèse manquante...
les diapos "concises" ne contenant pas de phrases, mais des mots clé ou listes de points : permet de garder l'attention du public sur ce que l'on dit, en ne se servant des diapos que comme un support visuel (pour pointer du doigt)

Les points négatifs :

le format "interactif" : difficulté à prévoir le temps de parole pour la présentation. Si il y a beaucoup de participation, le temps de parole prévu empiètera sur le temps consacré (25mn de présentation + 10mn de participation > 30mn). A contrario, si il n'y a pas assez (pas du tout!) de participation, le temps de parole prévu sera trop court (25mn < 30mn).
le format "interactif" et les "bons points" : applicable pour des salles plus grandes, avec un public plus nombreux? Avec 50 personnes, je me demande si on atteignait pas la limite pour ce genre de format...
les diapos "concises" l'étaient peut-être trop : rajouter des photos comme par exemple pour les présentations de Olivier Meunier pour que ce soit plus agréable visuellement (ou comme pour celles de Cyril Baÿ, private joke inside ;)

Dans l'ensemble, je pense que la présentation s'est bien passée, et a été bien reçue d'après les retours que j'en ai eu (merci à tous ceux qui sont venus me complimenter, ça fait chaud au coeur!). N'hésitez pas à me faire vos retours (positifs ET négatifs) dans les commentaires!

Ce que j'ai retenu des autres conférences

Il y a déjà plusieurs comptes rendus très complets sur la toile (liste exhaustive faite par Nicolas Ferrari sur le blog d'AlwaysData), je vais donc essayer de résumer ce que j'ai retenu de chaque présentation :

Django 1.2 : un point de nouveautés, par Nicolas Ferrari : lire les releases notes n'est pas suffisant! pour connaître toutes les excellentes améliorations de la 1.2, il faut soit lire la conf de Nicolas, soit suivre DjangoAdvent ;)
Boîte à outils Django, par Eric Veiras Galisson : de multiples outils pour vraiment être un fainéant (cf ma présentation) et se simplifier la vie !
Cours de géo, par Samuel Adam : c'est pas si compliqué finalement, et LA TERRE N'EST PAS RONDE! présentation très claire sur les outils disponibles et leur puissance
Une authentification pour les contrôler tous, par Olivier Meunier : une "fail story", au moins aussi importante que la "success story" aussi présentée, sur comment adapter l'authentification django à sa sauce
Tester son projet Django, par Bruno Renié : on ne le dit jamais assez, il faut tester ses applications. Non seulement un garde-fou, c'est aussi un gage de la qualité du code final! (et chapeau pour la présentation faite au pied levé pour remplacer un conférencier qui n'a pu venir, et ce moins de trois jours avant la conférence!)
Les dessous d’alwaysdata, par Cyril : on a pas vu beaucoup de dessous, mais on en a appris énormément sur AlwaysData, leur sérieux, leur compétence, et leur boulot au quotidien pour nous simplifier la vie (et nous permettre d'être fainéants!)
Django pour les développeurs Symfony, par Nicolas Perriault : superbe présentation, donnée de main de maître (et hilarante), qui donne un regard nouveau sur ce qu'il est possible de faire avec un langage comme PHP. Au final, Symfony à l'air d'être une bonne alternative à Django quand le client ne veut pas entendre parler d'autre chose que PHP.
Beer over IP, par Bruno Bord : retour d'expérience sur un site reconnu (par moi en tout cas ;) d'utilité publique.
Django et XMPP, par Jean-Michel Armand : quand utiliser XMPP, et surtout quand ne pas l'utiliser! Un retour d'expérience donné par notre cher Jean-Michel préféré!
Gunicorn, Django et WSGI, par Benoît Chesneau : présentation d'un outil que j'utilise en production depuis bientôt un mois sans jamais avoir eu le moindre soucis.
Des lapins et des poneys, quand AMPQ rencontre Django, par Olivier Meunier : explication d'une mise en oeuvre de AMPQ comme moyen de communication entre différents processus, très instructif
Introduction à Pinax, par David Paccoud : boîte à outil pleine d'applications réutilisables qui permet d'arriver à un produit fini avec moins d'efforts et plus rapidement. La question étant, comment faire la part entre un projet "fait main" qu'on maîtrise, et une boîte à outil qu'on ne maîtrise pas forcément. Qu'en est-il de la courbe d'apprentissage?
« Tain cong, Django speaks marseillais, par Stéphane Raimbault : il y a plusieurs formes plurielles dans certains langages (Polonais par exemple), et beaucoup plus de spécificités que je ne m'en doutais! Il va falloir que je reprenne ma copie...
Internationalisation de contenus avec Django, par Benoît Bryon : présentation très claire des limites (et de certaines solutions) de Django pour tout ce qui à trait à la traduction et localisation de sites
CouchDB et Django, l’utilisation de CouchDBKit, par Benoît Chesneau : pas forcément évident à prendre en main, CouchDB est sensé être le choix incontournable quand on tient à ses données (multiples mécanismes comme l'écriture régulière sur le disque pour éviter les pertes de données lors d'un crash)
Les limites de Django, par David Larlet : qui n'a pas été confronté à certaines de ces limites? Un regard réaliste sur ce qu'on ne peut tout simplement pas faire (à l'heure actuelle) avec Django.

Ce que j'ai retenu de l'orga

Un immense merci à David et Jean-Michel, sans qui nous n'aurions tout simplement pas eu cette occasion de se rencontrer entre passionnés de Django (et d'autres! dédicace à Jérémy Lecour), et de voir en chair et en os des personnes (oserai-je dire amis?) qu'on cotoie parfois tous les jours sur internet, certains depuis des années! Merci aussi à Johan Charpentier pour l'impression des TShirts!

J'ai été vraiment impressionné par la ponctualité (malgré les aléas de la restauration et ses délais imprévus), le contenu très fourni et divers de toutes les présentations, le professionnalisme et en même temps l'accessibilité de chacun. Pouvoir discuter et échanger des expériences avec des collègues (comme on dit dans le sud ;) est vraiment enrichissant.

Plus que tout, je tiens encore une fois à remercier Jean-Michel, qui s'est occupé d'une (très) grande partie de la logistique, de nous avoir trouvé les salles, chouchoutés (combien d'aller/retours il a fait pour remplir la cafetière? et de trajets en voiture pour amener/chercher des gens au métro/restau?), et de s'être autant appliqué à nous apporter tout le confort possible.

Vivement la prochaine rencontre!

MySQL, mysqldump et PHP : convertir de latin1 vers utf8

2010-03-08T07:38:00+01:00

Cet article à pour but de vous éviter, à vous lecteur, de vivre la perte de neurones (et le gain de cheveux blancs) que j'ai subit dernièrement, à investiguer des soucis de charset dans une base de donnée MySQL (et l'affichage sur une page web par le biais de PHP).

Je tiens à préciser que je ne suis pas un expert MySQL, et encore moins un expert en encoding, et certaines définitions ou mots utilisés dans cet article peuvent ne pas être utilisés à bon escient. Le fond et la méthode présentée ont par contre été vérifiés et testés!

Introduction à l'encoding

Je ne parlerais pas ici de ASCII ou Unicode (normes utilisées pour stocker les données), mais du jeu de caractères utilisé pour encoder ces données (et les afficher de manière lisible pour un être humain). Pour commencer, quelques définitions:

encoding = character set = charset : jeu de caractères utilisé pour représenter des données
utf8 = UTF-8 : un encoding qui associe un caractère à chaque "codepoint" Unicode (particularité: tous les caractères hors latin1 sont stockés sur deux octets)
latin1 = latin-1 = ISO-8859-1 : un encoding qui associe un caractère à chaque octet de la table ASCII

Pour résumer, chaque caractère peut être stocké sur le disque en Unicode (ou en ASCII, beaucoup plus limité). Il est ensuite encodé (traduit, représenté) avec un jeu de caractères pour être affichable et lisible par un être humain.

Historiquement, pour les pays occidentaux, l'encodage était fait en latin1 (caractères latins avec ses accentuations). De nos jours, de plus en plus d'applications se tournent vers Unicode et l'encodage en UTF-8 qui permet de représenter l'ensemble des caractères utilisés universellement (il n'est donc pas limité aux caractères latins, mais inclut par exemple les caractères cyrilliques, chinois...).

Charset utilisé par les tables et les champs

Pour consulter l'encodage utilisé par défaut pour une table ou un champ particulier :

mysql> SHOW CREATE TABLE bar;
+-------+-------------------------------+
| Table | Create Table                  |
+-------+-------------------------------+
| bar   | CREATE TABLE `bar` (
  `id` int(11) default NULL,
  `firstname` char(20) default NULL
) ENGINE=MyISAM DEFAULT CHARSET=latin1 |
+-------+-------------------------------+
1 row in set (0.00 sec)

ATTENTION : les charset définits au niveau de la base de donnée, de la table et du champ sont des "default charset". Il est tout à fait possible d'avoir une table avec un champ dont le contenu est en latin1, puis changer le DEFAULT CHARACTER SET à utf8 pour ce champ. Toutes les données existantes seront toujours en latin1, par contre toutes les nouvelles données entrées en utf8 seront en utf8. On est alors confronté au pire des problèmes : des charsets différents au sein d'une table pour un même champ.

Charset utilisé par le serveur, la database, les tables, les champs, le client, la connexion, les résultats...

Les encodages utilisés par le client, la connexion, le serveur, et l'affichage des résultats sont consultable par la commande suivante:

mysql> SHOW VARIABLES WHERE variable_name like 'char%';
+--------------------------+----------------------------+
| Variable_name            | Value                      |
+--------------------------+----------------------------+
| character_set_client     | utf8                       |
| character_set_connection | utf8                       |
| character_set_database   | utf8                       |
| character_set_filesystem | binary                     |
| character_set_results    | utf8                       |
| character_set_server     | latin1                     |
| character_set_system     | utf8                       |
| character_sets_dir       | /usr/share/mysql/charsets/ |
+--------------------------+----------------------------+
8 rows in set (0.00 sec)

Dans cet exemple, le client, la connexion, la database et les résultats sont tous en utf8. Il n'y a que le serveur lui-même qui est en latin1 par défaut. Pour configurer le client, la connexion et les résultats, on peut soit utiliser la commande

mysql> SET NAMES utf8;

Soit configurer les variables décrites dans le paragraphe suivant :

Les variables de configuration

Elles peuvent être définies au niveau du fichier /etc/mysql/my.cnf (peut être situé à un autre endroit selon la distribution):

[mysqld]
default-character-set=utf8
character-set-server=utf8
collation-server=utf8_general_ci # utilisé pour les comparaisons

[mysqldump]
default-character-set=utf8

[mysql]
default-character-set=utf8

L'encoding du terminal: attention au piège!

Quels que soit les charsets (par défaut) que vous avez configurés, il faut savoir que c'est le charset du terminal (si vous êtes en ligne de commande sur mysql par exemple) qui sera utilisé lors d'un UPDATE ou INSERT dans une table.

Ainsi, même si vous avez tout configuré (y compris le SET NAMES) pour être en latin1, lors d'une insertion dans une table, si votre terminal est en utf8 la donnée sera stockée en utf8.

Reportez-vous à cette astuce pour tester le charset (latin1 ou utf8) de votre terminal. Il faut ABSOLUMENT que votre client ai le même encoding que votre terminal pour éviter les `conflits`_ (à partir de la page 21).

Détecter le charset utilisé pour un champ

Commençons par une astuce pour différencier une donnée stockée en utf8 de latin1 :

mysql> select firstname, length(firstname) from bar;
+-----------+-------------------+
| firstname | length(firstname) |
+-----------+-------------------+
| dédé    |                 6 |
+-----------+-------------------+
1 row in set (0.00 sec)

6 octets pour stocker 4 caractères ? C'est de l'utf8! Les accents sont stockés sur deux octets. Si ça avait été du latin1, la longueur de la donnée aurait été de 4 octets.

Mais alors, je peux demander à MySQL de convertir mes données ?

Oui, mais pour savoir où aller, il faut savoir d'où on vient: avant de demander à MySQL de convertir une donnée, il faut connaitre son encodage actuel, et surtout dans quel encodage MySQL croit que ces données sont.

Il faut bien garder en tête que lorsqu'on parle du charset d'une table, d'un champ, d'une base de donnée... on parle du charset par défaut, et donc du charset que le serveur va utiliser pour insérer/retourner des données. Cela n'a aucune incidence sur l'encodage utilisé auparavant pour les données.

charset du serveur égal au charset du client : aucune conversion n'est faite
charset du serveur en latin1, charset du client en utf8 : la donnée va être encodée en utf8 (même si elle l'était déjà => problème de double encoding)
charset du serveur en utf8, charset du client en latin1 : la donnée va être encodée en latin1

Mes données sont stockées en utf8 et MySQL ne le sait pas!

Symptôme: quand on affiche le length d'une donnée avec des caractères accentués, ça donne un nombre d'octets plus grands que le nombre de caractères. La donnée est donc en utf8. Par contre, le serveur, la db, la table, le champ... sont configurés pour être en latin1. Et quand on essaie de faire un SET NAMES utf8, la donnée s'affiche avec des "Ã©" : dans ce cas, c'est une donnée stockée en utf8, mais qui est interprétée comme du latin1 par MySQL, qui va donc l'encoder une seconde fois en utf8 (problème de double encoding).

La solution :

Le serveur pense que les données sont en latin1 et on sait qu'elles sont en utf8 (notre charset final souhaité). Il suffit de

faire un dump de la base dans un fichier en latin1 pour qu'il n'y ai aucune conversion (pas de double encoding)
modifier ce fichier pour y faire disparaitre toute trace de "latin1"
configurer la table, la base de donnée et le serveur pour qu'ils soient en "default charset utf8" (cf le chapitre sur les variables de configuration)
réimporter les données dedans

Mes données sont stockées en latin1 et MySQL le sait, mais je les veux en utf8

Vu que le serveur sait que ses données sont en latin1, il suffit de lui demander de nous les fournir en utf8 :

faire un dump de la base dans un fichier en utf8 pour qu'il y ai une conversion automatique à partir de latin1
modifier ce fichier pour y faire disparaitre toute trace de "latin1"
configurer la table, la base de donnée et le serveur pour qu'ils soient en "default charset utf8" (cf le chapitre sur les variables de configuration)
réimporter les données dedans

Et PHP dans tout ça? Avant ça marchait, maintenant j'ai des � !

Ce cher PHP (hint: passez à Django! c'est bien plus beau!) ne prends pas en compte les configurations mises au niveau du serveur (ou du fichier de configuration) pour son encoding!

Par défaut la commande mysql_connect va toujours utiliser le charset latin1 : vous pouvez en avoir la preuve avec la commande mysql_client_encoding.

PHP va donc vous fournir des données interprétées en latin1 alors qu'elles sont en utf8, d'où les caractères � non valides.

Il suffit alors d'utiliser la commande mysql_set_charset('utf8', $connection) sur la connexion ouverte avec mysql_connect.

Faites bien attention d'avoir définit utf8 pour l'encoding de vos pages HTML soit par une balise meta dans votre entête de page, ou en ayant configuré votre serveur web pour servir les pages en utf8. Un moyen simple de vérifier ça est d'afficher les informations de la page.

Django : Envoyer des emails HTML avec images inline (intégrées)

2010-02-17T10:37:00+01:00

Voyons comment envoyer des emails multiparties (texte et HTML) avec des images inline (intégrées dans le mail lui-même, et non en pièce jointe), et ceci en utilisant des templates afin de profiter (par exemple) de l'i18n avec gettext, des filtres et tags, de l'utilisation du contexte...

Ce code est un mélange de deux méthodes complémentaires, une sur les mails HTML par Ross Poulton, et l'autre venant d'un djangosnippet par sleytr.

Pour en faciliter l'utilisation et la maintenance, j'ai mis ce petit module django-nice-emails sur bitbucket.

Plutôt que de copier le code ici, je vais plutôt en décrire les grandes étapes:

Utiliser le setting DEFAULT_FROM_EMAIL si l'expéditeur n'est pas fourni
Créer un django.template.Context à partir du dictionnaire fourni (permet de remplacer les {{ var }} dans les templates)
Utiliser le contexte créé pour initialiser le contenu texte, HTML ainsi que le sujet
Transformer le destinataire fourni en liste (si ce n'est pas déjà une liste de destinataires)
Créer un django.core.mail.EmailMultiAlternatives qui est la base de notre email (basé sur le contenu texte)
Rajouter la partie HTML
Rajouter les images en inline si nécéssaire
Envoyer le mai

Rien de compliqué donc dans ce code qui fait moins de 20 lignes "utiles".

Voyons maintenant un exemple d'utilisation avec de la traduction et de l'héritage de templates:

Les templates

On utilise ici la méthode de Ross Poulton qui consiste à ne fournir en paramètre template_name que la base du nom de fichier, sans l'extension. On fournit ensuite au django.template.loader ce template_name avec l'extension .txt et .html, ces templates doivent donc exister tous les deux.

templates/test_email.txt

{% load i18n %}
{% trans "Bonjour" %} {{ nom }},

{% blocktrans %}Ceci est un exemple de "nice-email" que je vous fait parvenir,
à titre d'exemple, et bien que vous vous en fichiez{% endblocktrans %}.

{% trans "Cordialement" %}

Mathieu Agopian

templates/test_email.html

{% extends "base_email.html" %}
{% load i18n %}
{% block email_content %}
<p>{% trans "Bonjour" %} {{ nom }},</p>
<p>
    {% blocktrans %}Ceci est un exemple de "nice-email" que je vous fait parvenir,
    à titre d'exemple, et bien que vous vous en fichiez{% endblocktrans %}.
</p>

<p>{% trans "Cordialement" %}</p>

<p><em>Mathieu Agopian</em></p>
<img src="cid:signature" />
{% endblock email_content %}

templates/base_email.html

<table width="600">
<tr><td><img src="cid:logo" /></td></tr>
<tr><td>
    {% block email_content %}{% endblock email_content %}
</td></tr>
</table>

Le contexte

Un simple dictionnaire python pour chaque tag utilisé dans les templates:

context = {'nom': 'Johnny Biboul'}

Les images

Elles doivent être passées en paramètres dans un tuple de tuples, sous la forme (('/chemin/vers/image.png', 'tagimage'), '/chemin/vers/image2.png', 'tagimage2'), ...). Si les images sont dans le répertoire images du MEDIA_ROOT:

images = (
    (path.join(settings.MEDIA_ROOT, 'images', 'signature.png'), 'signature'),
    (path.join(settings.MEDIA_ROOT, 'image', 'logo.png'), 'logo'))

Dans les templates, on utilisera les images sous la forme <img src='cid:tagimage' />.

Le code

#!/usr/bin/env python
# -*- coding: utf-8 -*-

from os import path
from django.conf import settings
from django.utils.translation import ugettext
from utils.nicemails import send_nice_email


context = {'nom': 'Johnny Biboul'}
images = (
    (path.join(settings.MEDIA_ROOT, 'images', 'signature.png'), 'signature'),
    (path.join(settings.MEDIA_ROOT, 'images', 'logo.png'), 'logo'))
subject = ugettext(u"Test de mail pour %(nom)s") % {'nom': '{{ nom }}'}
send_nice_email(template_name='test_email',
                email_context=context,
                subject=subject,
                recipients='johnny@biboul.com',
                sender='foo bar ',
                images=images)

Conclusion

Il vous suffit de mettre ce code dans une de vos vues pour pouvoir faire de jolis mails de confirmation d'inscription, des newsletters, ou voir même (bouh! c'est mal!) du mass-mailing. Veillez néanmoins à ne pas forcer la dose sur le html, ou les images inlines!

lancer gunicorn avec runit

2010-02-10T11:37:00+01:00

ATTENTION votre serviteur a fait le test pour vous sur une ubuntu: après avoir installé runit et runit-run, le système ne démarre plus. Pour suivre les étapes de ce billet, il ne faut pas installer runit-run, qui ne doit être installé que lorsque l'on souhaite remplacer totalement le système d'initialisation (et cela demande plus de configuration qu'une simple installation du paquet).

Pour les malheureux qui ont fait les frais de la première version de ce billet (demandant d'installer runit-run), je ne peux que m'excuser platement, et vous fournir la méthode "au secours rescue moi!":

récuperer une installation avec un cd ubuntu

Une fois chrooté sur la partition root, il vous restera à désinstaller le paquet fautif et redémarrer:

$ aptitude purge runit-run

Edité le 2010/02/10 à 20:58

Pour faire suite au précédent billet gunicorn: un server wsgi ultra simple à utiliser et configurer, voici une recette rapide pour lancer automatiquement (et monitorer) gunicorn avec runit.

Pourquoi runit et pas sysvinit, inittab, upstart, ...

Je vous laisse consulter la page benefits sur le site officiel pour vous faire une idée. Pour les personnes ne parlant pas anglais, voici un bref résumé:

Un répertoire par service, contenant un script run
Un environnement d'exécution propre et prédictible pour chaque processus
Service de logging (optionnel) qui sera lancé en même temps que le processus, et en couvrira toute la durée de vie (redémarrages compris!)
Très peu encombrant, efficace... et peut complètement remplacer le système d'initialisation de votre linux

Utiliser runit avec le système d'initialisation actuel

Pour nous faciliter la vie, et ne pas avoir à modifier/importer de nombreux scripts de démarrage pour tous les démons et services déjà installés, nous allons utiliser runit "avec" le système d'initialisation actuel.

Installer runit

$ aptitude install runit

ATTENTION: Si vous installez aussi runit-run, il vous faut absolument configurer votre système (How to replace init), et ce, avant de rebooter (sinon votre système ne démarrera pas, et vous serez contraint à utiliser une méthode de récupération, comme celle présentée en tête de ce billet).

Créer un répertoire pour le service gunicorn et son script de lancement

$ mkdir /etc/sv/gu-monprojet
$ vi /etc/sv/gu-monprojet/run

Et voici le contenu du script run

#!/bin/bash
source /path/to/venv/bin/activate # activer le virtualenv
cd /path/to/django/project
exec gunicorn_django -b localhost:8080 --workers=3

Avec la version de gunicorn utilisée pour l'écriture de cet article, il est nécessaire d'être dans le répertoire du projet django (là ou se situe le fichier settings.py) pour lancer gunicorn_django.

Dans une future version (la modification est dans le trunk à l'heure de l'écriture) il suffira d'indiquer le chemin vers le fichier settings.py comme paramètre à la commande gunicorn_django.

Enfin, ne pas oublier de rajouter les droits d'exécution sur le script qu'on vient de créer:

$ chmod a+x /etc/sv/gu-monprojet

Indiquer à runit qu'il doit lancer le script

Pour celà, un simple lien symbolique, et dans les secondes qui suivent le script sera lancé:

$ ln -s /etc/sv/gu-monprojet /etc/service/

Et c'est tout!

Il suffit maintenant d'en profiter en allant sur http://localhost:8080, en configurant apache pour proxiser les requêtes directement dessus (cf le billet gunicorn: un server wsgi ultra simple à utiliser et configurer), ou encore en utilisant la commande sv pour gérer le service gunicorn:

$ sv status gu-monprojet
$ sv check gu-monprojet
$ sv up gu-monprojet
$ sv down gu-monprojet
$ sv restart gu-monprojet
$ sv hup gu-monprojet

...

gunicorn: un server wsgi ultra simple à utiliser et configurer

2010-02-09T17:08:00+01:00

Deux billets le même jour, c'est fête!

Voici une recette simple pour installer, configurer et utiliser gunicorn avec apache et django.

Installer gunicorn

Pour installer gunicorn dans son environnement virtuel:

$ pip install -E /path/to/venv install gunicorn

Configurer Apache en proxy

Apache servira les fichiers statiques, et "proxisera" toutes les autres requêtes directement à gunicorn qui sera lancé en local sur le port 8080:

<VirtualHost *:80>
ServerName example.com
ServerAlias www.example.com

DocumentRoot /path/to/django/project

<Proxy *>
    Order deny,allow
    Allow from all
</Proxy>

# laisser apache servir les fichiers statiques
ProxyPass /robots.txt !
ProxyPass /favicon.ico !
ProxyPass /static/ !

# proxiser toutes les autres requêtes vers gunicorn
ProxyPass / http://localhost:8080/

# robots.txt et favicon.ico sont dans /path/to/django/project/static/
Alias /robots.txt /path/to/django/project/static/robots.txt
Alias /favicon.ico /path/to/django/project/static/favicon.ico

<Directory /path/to/django/project>
    Order deny,allow
    Allow from all
    Options -Indexes
</Directory>
</VirtualHost>

Pour que le tout fonctionne correctement, il faut activer les modules mod_proxy et mod_proxy_html (et en option mod_cache):

$ a2enmod proxy proxy_http cache

Puis de redémarrer le server Apache:

$ /etc/init.d/apache2 restart

Lancer gunicorn

Il suffit de se placer dans le répertoire du projet django (avec le virtualenv activé), puis de taper:

$ gunicorn_django -b localhost:8080 --workers=2

Un ordre d'idée pour le calcul des workers: un de plus que le nombre de CPUs de la machine.

Conclusion

On peut alors se créer un script (a placer dans /etc/init.d) et l'activer pour qu'il se lance automatiquement au démarrage avec la commande update-rc.d (sous Debian), ou utiliser runit (jamais testé, peut-être un futur billet?).

Encore mieux, remplacer Apache par Nginx! (jamais testé non plus, et sûrement un futur billet ;)).

On peut difficilement faire plus simple!

Installer PIL (Python Imaging Library) facilement avec pip

2010-02-09T12:41:00+01:00

Le fabuleux utilitaire pip de Ian Bicking est un remplacement à easy_install qui fonctionne très bien avec virtualenv (pas étonnant, c'est du même auteur!).

Je laisse le soin au lecteur de consulter la documentation sur ces deux utilitaires très pratiques et indispensables à tout développeur python.

Voici la commande à utiliser pour installer PIL (Python Imaging Library) dans votre environnement virtuel:

$ pip -E /path/to/venv install http://effbot.org/downloads/Imaging-1.1.7.tar.gz

Vous pouvez consulter la liste des versions disponibles en vous rendant sur la page officielle de Python Imaging Library.

ATTENTION: Il faut avoir les sources de python installées et disponibles afin de pouvoir compiler le paquet. Sur debian, il vous suffit de taper

$ aptitude install python-dev

Si vous avez une erreur pip du genre

ImportError: No module named pkg_resources

il vous faut aussi installer python-pkg-resources:

$ aptitude install python-pkg-resources

Obfuscation de l'email alternative et accessible

2009-09-27T12:51:00+02:00

English translation of this post also available.

Le Problème

Les quatre prérequis pour l'obfuscation d'une adresse mail sont les suivants:

Ne pas pénaliser l'utilisateur: pouvoir cliquer sur le mail
Ne pas pénaliser l'utilisateur: pouvoir copier/coller l'adresse
Ne pas pénaliser l'utilisateur: l'addresse doit rester accessible (en mode texte, sans css et/ou sans js)
Difficilement récupérables par des spambots

L'ordre n'est pas une coïncidence: le but de l'obfuscation est bien entendu d'empêcher les spambots de récuperer l'adresse email, mais celà ne doit en aucun cas pénaliser l'utilisateur du site.

Les différentes méthodes d'obfuscation d'adresse email qui tournent sur la toile, malheureusement, échouent en général au moins sur l'un des 4 points listés.

La Solution

Pour les utilisateurs de webkit avec le javascript désactivé, voir les limitations.

<a href="/contactform.html" id="emailaddress">
    prenom.nom<img src="" alt="@" />example.com
</a>

<script> type="text/javascript">
    mail = new Array("prenom.nom", "example.com").join("@");
    ea = document.getElementById("emailaddress");
    ea.href = "mailto:" + mail;
    ea.innerHTML = mail;
</script>

Et voici le résultat:

prenom.nomexample.com

L’Explication

Si javascript est activé, l’attribut href ainsi que le contenu du lien sont modifiés afin que l’obfuscation soit invisible. Rien de nouveau donc.

Si javascript est désactivé, en utilisant le contenu alternatif d’une image inexistante pour remplacer le « @ », on obtient plusieurs résultats intéressants:

les lecteurs d’écrans liront l’attribut alt pour l’image, l’email étant donc très facilement déchiffrable
l’attribut alt est affiché, rendant l’obfuscation invisible, même en mode texte ou sans css
l’adresse est copiable sans aucun soucis
l’email est toujours clickable, le lien menant sur un formulaire de contact

Un gros avantage d’utiliser un attribut d’un tag html est qu’il contre les spambots qui ne récupèrement que le texte, et non les tags html, afin de ne pas être bloqués par les méthodes d’obfuscation basées sur l’insertion de tags invisibles ou de commentaires dans l’adresse. Ici, supprimer le tag <img> revient à perdre l’information capitale du « @ ».

Les limitations

Il y a deux bugs non résolus dans Webkit à la date de rédaction de cet article:

Les conséquences sont alors visible sur un navigateur utilisant Webkit, et avec le javascript désactivé:

Image manquante sous Webkit

De plus, l’adresse n’est plus copiable, mais le lien (vers le formulaire de contact) reste disponible.

Une solution serait alors d’utiliser une image contenant le symbole « @ », mais celà peut poser des problèmes de style (couleur, famille et taille de la police, anti-aliasing…):

Adresse email avec une image remplaçant le @

Note

Il est possible d’afficher l’attribut alt de l’image sous webkit, en forçant la taille de l’image pour qu’elle soit assez grande:

<img src="" style="height: 60px; vertical-align: top;" alt="@" />

Image assez grande pour afficher l'attribut alt

C’est hideux, mais ça reste lisible, et ça n’impacte que les quelques pourcents d’utilisateurs de webkit qui ont le javascript désactivé.

Conclusion

Voilà donc une nouvelle méthode d’obfuscation d’adresse email, qui devrait être efficace (au moins autant que les autres) contre les spambots, mais qui impacte le moins possible l’utilisateur final. Et surtout, l’adresse est accessible pour les lecteurs d’écrans!

Linux: savoir si le processeur est 32bits ou 64bits

2009-09-24T08:16:00+02:00

Voici une astuce rapide pour savoir si le processeur d'une machine donnée supporte le 64bits:

Il suffit de vérifier si le flag lm est présent dans les informations de /proc/cpuinfo:

$ cat /proc/cpuinfo | grep lm
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe lm constant_tsc pebs
bts pni monitor ds_cpl est cid cx16 xtpr lahf_lm

Le flag lm signifie "long mode", comme on peut le voir dans les sources du noyau (include/asm-i386/cpufeature.h):

#define X86_FEATURE_LM          (1*32+29) /* Long Mode (x86-64) */

Vous trouverez une liste de tous les flags sur le blog de Nick Burch (en anglais).

PyCON.fr, excellent!

2009-06-05T06:56:00+02:00

Et voilà, l'édition 2009 de PyCON.fr, ma toute première conférence sur Python (et ma toute première conférence en tant qu'orateur!) est terminée.

Je tiens à remercier l'AFPY, Association Francophone PYthon, organisatrice de cet évènement. Je remercie aussi tous les membres de l'association, et bénévoles, qui m'ont accueilli aussi chaleureusement!

Je remercie Ubicast qui m'a permis d'avoir ma conférence filmée, streamée et mise à disposition, et qui m'a permit de découvrir et utiliser leur solution vidéo (très ergonomique et facile à utiliser, même pour un novice comme moi).

Je remercie enfin les personnes qui ont assisté à ma présentation, qui ont été réactifs, attentifs et qui ont fait de cette première expérience une réussite!

La présentation en ligne
Les sources sur bitbucket.org
La vidéo (les quatres premières minutes de son manquent)
Toutes les vidéos de PyCON.fr (à l'heure où j'écris ces lignes, toutes les vidéos ne sont pas encore disponibles, mais ça ne saurait tarder!)

PyCon.fr: venez m'y voir!

2009-05-23T07:28:00+02:00

Toi, oui toi lecteur,

sache qu'il y a une conférence sur Python, entièrement gratuite, qui se tiendra le 30 et 31 mai (autant dire, le week-end prochain) sur Paris, à la Cité des Sciences et de l'Industrie de la Villette.

Tarek Ziadé, le président de l'association AFPY, donne un peu plus de précisions sur cet évènement.

Et enfin un lien vers l'évènement lui même, afin d'y trouver des informations sur le programme: PyCon.fr 2009

J'y donnerai une présentation de 20 minutes sur un billet que j'ai commencé sur ce blog: Les (D)VCS, pourquoi, comment? (le premier article: Le contrôle de version de sources, pourquoi?)

Le contrôle de versions de sources: pourquoi?

2009-03-30T19:07:00+02:00

Je vais vous raconter l'histoire de Brian. Brian est ingénieur informaticien.

Le crash disque

Brian n'a pas de chance, et il a failli devoir pointer à l'ANPE quand il s'est rendu compte que

Son disque dur avait crashé
Il n'avait pas fait de sauvegarde de son boulot

Heureusement, il a pu récuperer les sources sur le serveur de production, et en moins de deux semaines il a pu réimplémenter les dernières fonctionnalités et corrections de bugs qu'il avait apportées au logiciel.

Le boss indécis

Brian n'a vraiment pas de chance, il a un boss indécis qui vient de lui dire qu'il ne voulait finalement plus de la dernière fonctionnalité en date:

"c'est une très mauvaise idée, commercialement parlant, supprime là au plus vite".

Trois jours plus tard, Brian pense n'avoir oublié d'annuler les modifications dans aucun fichier.

La faute à Murphy

Brian, qui a la poisse, se retrouve à débuguer un morceau de code obscur, et se demande tout à coup qui a bien pu créer ce "code spaghetti".

Serait-ce John, le cousin de l'oncle de sa soeur, qui code comme sa grand-mère?
Ou encore Steven, le surfer blond, qui sort juste de l'école et n'a jamais appris à commenter son code?

Si seulement Brian le savait, il pourrait demander des éclaircissement à l'auteur, et aurait quelqu'un à pointer du doigt à son boss qui vient de sortir son fouet.

Le CPOLD: la fausse solution

Pour reprendre le blog de Roland, le CPOLD à d'innombrables qualités:

pas de format de fichier complexe et susceptible de corruption
pas de conflits
aucun besoin d'un serveur dédié (on peut tout mettre ensemble, prod et dev confondues)
aucune limitation sur la gestion des branches
une rapidité insurpassable
une simplicité de mise en oeuvre et d'apprentissage enfantine
pas de modèle de développement imposé (centralisé, distribué, en quinconce, en hélice, toutes les variantes sont possibles)
des sauvegardes facilitées
etc...

Voici en quoi consiste la mise en place du CPOLD:

$ cp fichier.py fichier.py.old

Et voici un exemple de mise en oeuvre du CPOLD:

foo_dev
    foo.py
    foo.py.old
    foo.py.old.2009_03_29
    foo.py.marche_pas
    foo.py.todelete
    foo.py.OLD.2006_05_12
    foo.py.bak
    foo.py.fonctionalite_bar
    foo.py.bug
    foo.py.save.20081210
    foo.py.check
    foo.py.test

foo_prod
    foo.py

foo_savedev.tgz
foo_save20090329_v2_0.tgz
foo_save20080412_v1_2.tgz
foo_save20060509_v1_0.tgz

Et pour faire bien, voici un extrait du fichier foo.py:

...
def bar(thing): # Added the 10th of june, 2006 -- Steven
    """This function is very usefull!"""
    # Brian: refactored 20080410 for release 1.2
    #if thing == "bar": ### Steven: 11/06/06 fixed typo (was thing = "bar")
    #    return True;
    return (thing == "bar")
...

La fausse bonne idée

Nous avons déjà vu les avantages du CPOLD, maintenant les inconvénients:

Duplication de fichiers
Duplication de code
Réduction dramatique de la lisibilité
Difficulté de grouper des modifications (pour une fonctionnalité par exemple)
Ai-je déjà mentionné la duplication?

Conclusion

Sommes-nous maintenant tous bien d'accord avec Brian pour dire que le contrôle de versions, c'est indispensable? Et que le CPOLD, c'est dépassé?

Dans une prochaine histoire, les enfants, nous verrons avec Brian quels sont les merveilleux outils à notre disposition: les "Version Control System" !

EDIT (05/06/2009): la totalité de cette article (cette première partie ainsi que les deux suivantes, qui ne seront pas publiées sous forme de billet) a été présentée à PyCON.fr. Vous trouverez les liens vers la présentation (en ligne, au format vidéo, et les sources) dans le billet "PyCON.fr: excellent!"

Django, sqlite et mod_wsgi, attention au piège!

2009-03-14T15:34:00+01:00

Tout d'abord, je tiens à préciser que le problème qui suit n'est pas limité à l'utilisation de django ou de mod_wsgi.

Le contexte

Utilisation de SQLite pour un projet django déployé sur mod_wsgi:

# settings.py
DATABASE_ENGINE = 'sqlite3'
DATABASE_NAME = '/opt/mysite/mysite.db'

Et voici les permissions sur le système de fichier:

-rw-rw-rw- 1 ohan ohan 29696 2009-03-14 13:30 mysite.db

Tous les répertoires parents sont eux en 755 (lecture et exécution), ce qui ne devrait donc poser aucun problème, même pour l'utilisateur utilisé par les processus apache/mod_wsgi.

Le problème

Lors de la première tentative d'accès à la base de donnée (par exemple en accédant à l'administration django), une erreur 500 INTERNAL SERVER ERROR est renvoyée, et dans le fichier de log d'apache:

OperationalError: unable to open database file

La solution

Lors de l'accès à un fichier de base de données, SQLite va créer un fichier journal qui lui servira (entre autres) à gérer les accès à cette base. Plus d'informations sur la page expliquant les méthodes de vérouillage: locking in sqlite v3.

Pour créer ce fichier, il faut donc que l'utilisateur puisse écrire dans le répertoire parent.

chmod a+rw /opt/mysite

Ce problème ne devrait se présenter que lors d'un déploiement en environnement de production pour un projet qui utilise SQLite, ou sur un environnement de test si, comme moi, vous préférez tester sur apache directement, et non sur le runserver.

Checklist: différences entre MySQL et les modèles Django

2009-03-02T10:54:00+01:00

Comme vu dans un précédent billet (MySQL et les modèles Django), il existe des inconsistances entre une base de donnée MySQL et sa représentation par des modèles Django.

Création des tables à partir des modèles Django

Lorsqu'on utilise python manage.py syncdb, les tables créées dans la base de données

N'auront aucun commentaire, que ce soit sur les champs ou les tables, qu'il y ai ou non des help_text et des docstrings
N'auront aucun champ *ENUM*: les champs possédant une liste de choix sont représentés par un *VARCHAR* de longueur égale à la taille du plus long des choix
Les valeurs par défaut indiquées dans les modèles ne sont pas transmises dans les scripts de création des tables
Les *BooleanField* sont représentés par des TINYINT de 1bit
Un DateTimeField avec le paramètre auto_add_now ne sera pas représenté par un TIMESTAMP avec la valeur par défaut CURRENT_TIMESTAMP

Inspection des tables dans Django

Par ailleurs, si la base de donnée existe déjà, et que les modèles sont créés automatiquement par l'utilisation de la commande python manage.py inspectdb, il faudra garder à l'esprit que:

Les commentaires sur les champs et tables ne sont pas traduits en help_text ou docstrings, il faudra donc les dupliquer manuellement
Un champ ENUM sera représenté par un CharField
Les tailles de champ ne sont pas respectées. Par exemple, un Charfield sera avec un max_length de 135 par défaut
Les champs TIMESTAMP avec une valeur par défaut de CURRENT_TIMESTAMP ne seront pas importés en champ avec une valeur par défaut auto_add_now
Les valeurs par défaut ne sont pas importées

Il y a deux derniers points à noter:

Le script d'inspection va importer les champs primary_key pour chaque table, alors qu'ils peuvent être automatiquement générés de manière transparente: un modèle sans primary_key explicite en aura un de manière implicite
Le script d'inspection va créer un modèle pour les tables utilisées pour les relations ManyToMany alors que là aussi, Django peut les générer de manière implicite dans la plupart des cas (lorsque cette table ne contient pas d'information supplémentaire)

Je trouve préférable de laisser la gestion implicite des primary_key et des tables ManyToMany quand c'est possible, dans un soucis de concision et de lisibilité.

Néanmoins, celà introduit une inconsistance entre les modèles et leur représentation dans la base de donnée, inconsistance qui peut porter à confusion.

Plus de cohérence entre les modèles et la base de donnée

Plusieurs possibilités:

créer un script python qui va introspecter les modèles, et automatiquement rajouter les help_text comme commentaires aux champs, et les docstrings comme commentaires aux tables, ou vice-versa
Utiliser des *Custom SQL*
Créer des *Custom fields*
Pour le type ENUM, il existe un *django snippet* qui vise à apporter une meilleure cohérence dans son utilisation

Partagez vos astuces et faites part d'autres incohérences dans les commentaires!

MySQL et les modèles Django

2009-02-24T19:45:00+01:00

Le problème

D'un côté, une base de donnée MySQL maintenue par MySQLWorkbench. De l'autre, Django et ses modèles.

Entre les deux... pas grand chose.

Les acquis

MySQL et MySQLWorkbench

MySQLWorkbench est un outil excellent pour pouvoir maintenir une base de donnée:

Gestion des commentaires sur les tables et champs
Affichage des relations entre les tables d'une base de données sous forme d'un schéma
Facilité de modification d'une base de donnée en production par l'export de scripts SQL

Django et les modèles

Django, de son côté, nécéssite une représentation de la base de donnée par des modèles. Ces modèles sont des classes codées en Python:

Facilité de suivi des modifications d'un modèle par le biais d'un contrôle de version (Git, Mercurial, SVN ...) accompagné de commentaires pour chaque commit
Facilité de documentation: un paramètre help_text pour chaque champ, un docstring pour chaque modèle
Abstraction de certaines tables et champs générés automatiquement (comme les primary key ou les tables ManyToMany)

Les outils

Comme indiqué plus haut, MySQLWorkbench permet d'exporter des scripts SQL de création et/ou de modification. Il est aussi possible de reverse engineer le dump SQL d'une base de donnée, et ainsi créer toutes les tables dans l'interface graphique, et y visualiser les relations sous forme de schéma.

Django permet l'export de scripts SQL de création, mais aussi l'inspection d'une base de données (par la commande python manage.py inspectdb), ou encore l'exécution de scripts SQL custom à chaque création/modification d'une table (par la commande python manage.py syncdb).

Les méthodes

La méthode basique

... qui casse complètement le principe DRY (Don't Repeat Yourself): maintenir les deux parties en parallèle.

Lorsqu'il faut rajouter une table dans la base, ou y apporter une modification, faire la modification dans MySQLWorkbench, puis répliquer l'ajout/la modification dans les modèles Django.

Pour: Méthode simple, pas de procédure ou méthode à mettre en place.

Contre: Méthode manuelle, sujette à l'erreur humaine (faute de typo, oubli...).

MySQLWorkbench => Django

Maintenance dans l'outil MySQLWorkbench, puis export des scripts de création/modification.
Execution de ce script sur la base de données pour la mettre à jour
Utilisation de inspectdb avec Django pour mettre à jour les modèles

Pour: Méthode automatique, donc pas de risque de typo ou d'oubli

Contre: Méthode très complexe à mettre en place. En effet, inspectdb est loin de créer des modèles fidèles, et il manque de nombreuses informations (un futur billet sera écrit sur ce sujet).

Django => MySQLWorkbench

Ajout ou modification d'un modèle dans Django
Mise à jour de la base de donnée en utilisant python manage.py syncdb (et des scripts custom si nécéssaire)
Utilisation de MySQLWorkbench pour reverse engineer les scripts de création de la base de donnée

Pour: Méthode automatique, donc pas de risque de typo ou d'oubli. De plus, contrairement à la méthode précédente, la représentation des tables est 100% fidèle à la structure de la base de donnée créée par les Django.

Contre: Toutes les informations de commentaires (et d'autres, comme nous le verrons dans un futur billet) sont perdues à chaque modification.

Conclusion

Je n'ai malheureusement pas trouvé à l'heure actuelle de méthode miracle. Il y a des pistes, mais il semble qu'il n'y ai rien de concret pour le moment.

Pour certains cas particuliers, l'une ou l'autre méthode sera préférée:

Création d'une nouvelle table: la méthode Django => MySQLWorkbench sera facile à mettre en place, et il n'y aura rien de perdu vu qu'il n'y a pas d'existant
Modification d'une table par le rajout d'un nouveau champ: l'une des deux méthodes automatique peuvent faire l'affaire
Modification d'un champ d'une table: la méthode manuelle sera en général la plus rapide et la plus simple à mettre en place
Modifications complexes, multiples, perte de donnée possible...: dans ce cas, point de salut, il ne reste que la méthode manuelle, et une grande concentration!

Et vous, quelle est votre méthode?

Apprendre à faire, et faire

2009-02-22T15:03:00+01:00

Quelle est la meilleure méthode d'apprentissage?

Scénario: "moi, j'apprends"

J'apprends.

Je commence par le tutoriel, que je lis de fond en comble
Je continue par les concepts annexes
J'approfondis quelques sujets qui me paraissent importants, utiles, bons à connaître

Malheureusement, très rapidement

Je prends du retard sur mon projet
Je m'éparpille, je me documente sur des concepts qui ne me serviront peut-être jamais
J'approfondis trop, au détriment d'une vue d'ensemble
Et surtout, je commence à oublier ce que j'avais appris au début, je perds le fil, je me rappelle à peine du tutoriel...

Scénario: "moi, je fais"

Je me lance.

J'essaie de comprendre les concepts de base, peut-être le début du tutoriel
Je me lance, je débute mon projet, et je défriche au fur et à mesure
Quand j'ai besoin d'un nouveau concept, j'épluche rapidemment la documentation, et j'applique mes acquis

Malheureusement, très rapidement

Je passe à côté de concepts très utiles et intéressants
Je ne possède pas assez de bases pour développer mon projet intelligemment
Je ne connaît pas les outils qui me simplifieraient la tâche
Et surtout, je me rends compte que mon projet mériterait un refactoring, alors qu'il débute à peine

Scénario: le juste milieu?

J'essaie de trouver le juste milieu entre "j'apprends" et "je fais".

Je commence par le tutoriel, que je fais
A chaque étape du tutoriel, je met en pratique ce que je viens d'apprendre en faisant quelques modifications/améliorations
Je me fais ensuite (rapidement) une vue d'ensemble des différents concepts et outils disponibles

Ensuite, j'entamme le projet. Le déroulement d'une journée de travail pourrait être :

Je démarre le projet par la partie la plus simple
Dès que j'en ai besoin, j'approfondis un concept/outil nécessaire à l'étape en court du projet
Quand je rencontre un concept/outil adjacent, qui pourrait m'intéresser dans l'avenir, je le marque comme "à lire"
Une fois rentré chez moi, ou avant de commencer le travail le lendemain, je passe un peu de temps à me documenter sur ce que j'ai marqué comme "à lire"

Ma méthode

J'essaie de suivre au mieux le scénario "le juste milieu" : Apprendre chaque jour un peu, et faire. Voici un ordre d'idée du déroulement d'une journée de travail, une fois que le projet est démarré:

Je me réserve une heure le matin, pour me documenter sur des sujets généraux, des outils...
puis j'avance sur le projet, et ne me documente que si nécessaire pour résoudre un problème précis
si je rencontre un sujet que j'aimerais approfondir, j'ouvre un onglet dans mon navigateur pour le lendemain matin

Quelques ordres de grandeur :

Un tutoriel doit prendre quelques heures (au maximum une journée)
Le temps passé à le mettre en pratique en faisant quelques modifications/amélioration ne doit pas dépasser le temps passé à le suivre (donc durée totale "tutoriel + mise en pratique" < 2 journées)
Une fois le projet démarré, se documenter sur un outil/concept doit prendre (en moyenne) moins de 50% du temps de travail (ce ratio doit évaluer en faveur du développement au fur et à mesure de la maîtrise du sujet)

Selon le sujet à apprendre, ces ordres de grandeur varient:

Plus d'apprentissage pour un nouveau langage de programmation (par exemple, Python)
Plus de mise en pratique pour un nouvel outil (par exemple, Mercurial)
Environ 50/50 pour un framework (par exempe, Django)

Et vous?

quelle est votre méthode? Avez-vous des astuces à partager?

Django FileField et ImageField, upload_to et shell python

2009-02-19T19:30:00+01:00

Le paramètre upload_to des FileField et ImageField

Le champ upload_to permet d'indiquer où sauver un fichier de type django.core.files.File par rapport au MEDIA_ROOT spécifié dans les settings.

Ce champ peut être une chaîne de caractères, ou un callable.

Chaîne de caractères pour upload_to

Pour notre example, prenons le modèle suivant:

class MonModele(models.Model):
    fichier = models.FileField(upload_to="chemin")

Dans ce cas simple, tous les fichiers seronts sauvés dans le répertoire <MEDIA_ROOT>/chemin/.

Si on upload un fichier nommé MonFichier.txt, le chemin complet (sans le MEDIA_ROOT) sera chemin/MonFichier.txt.

Il est par ailleurs possible d'utiliser une syntaxe strftime comme indiqué dans la documentation du module time.

Pour stocker un fichier avec la date et l'heure:

class MonModele(models.Model):
    fichier = models.FileField(upload_to="chemin/%Y%m%d_%H%M%S")

Et le résultat sera chemin/2009-02-19_18:40:03/MonFichier.txt, ce qui n'est pas vraiment ce à quoi on s'attendait.

En effet, cela créera un répertoire par fichier, au lieu de stocker la date et l'heure dans le nom du fichier.

Pour arriver à nos fins, il nous faut utiliser une fonction pour le calcul du chemin de stockage du fichier.

Fonction pour upload_to

Utiliser une fonction pour le calcul du chemin de stockage permet:

de modifier le nom du fichier lui-même, et pas seulement son répertoire de stockage
d'utiliser des informations spécifiques à l'instance du modèle pour lequel on stocke le fichier

Il nous faut par contre respecter les contraintes suivantes:

la fonction aura deux paramètres: self, l'instance, et filename, le nom du fichier uploadé
il n'est plus possible d'utiliser directement la syntaxe strftime

Voici le code qui va stocker un fichier avec la date et l'heure (et prendra la date et l'heure automatiquement ajoutée au champ DateTimeField avec le paramètre auto_add_now):

class MonModele(models.Model):
    date = models.DateTimeField(auto_now_add=True)
    def upload_path(self, filename):
        return 'chemin/%s_%s' % (self.date.strftime("%Y%m%d_%H%M%S"), filename)
    fichier = models.FileField(upload_to=upload_path)

Ce coup-ci, on obtient bien un fichier chemin/2009-02-19_18:40:03_MonFichier.txt, comme prévu.

Tester un modèle avec FileField dans l'interpréteur Python

Pour pouvoir tester un modèle avec un FileField dans un intepréteur Python (python manage.py shell), il y a quelques précautions à prendre, comme commencer par "sauver" le File, comme indiqué sur la page suivante.

En effet, pour que le modèle soit correctement instancié, il faut:

créer une instance du modèle
la sauver (dans notre cas, afin que la date soit automatiquement stockée, et devienne accessible dans upload_path)
ouvrir le fichier à "uploader"
créer un django.core.files.File à partir de ce fichier
sauver ce fichier pour pouvoir ensuite le tester

>>> from mysite.models import *
>>> mm = MonModele()
>>> mm.save()
>>> mm.date
datetime.datetime(2009, 2, 19, 19, 4, 49, 538465)
>>> from django.core.files import File
>>> f = File(open("MonFichier.txt"))
>>> mm.fichier.save(f.name, f, save=False)
>>> mm.fichier
<FieldFile: chemin/20090219_190449_settings.py>

Pour "sauver" le fichier, il faut fournir à la méthode save le nom du fichier (f.name), le fichier lui-même (f), et un paramètre spécifiant si on veut sauvegarder le fichier dans la base de donnée ou pas.

Si nous ne voulions pas accéder à date qui est stockée automatiquement, il aurait été inutile de sauvegarder l'instance de MonModele (mm), et il aurait alors fallut remplacer le code de upload_path de la sorte

def upload_path(self, filename):
    return 'chemin/%s_%s' % (self.date.strftime("%Y%m%d_%H%M%S"), filename)

par

def upload_path(self, filename):
    import time
    return 'chemin/%s_%s' % (time.strftime("%Y%m%d_%H%M%S"), filename)

Django svn et mod_wsgi, attention au piège!

2009-02-17T22:34:00+01:00

Scénario

Notre cher utilisateur biboul se décide à installer la version de développement de django, que nous appellerons django-trunk, comme indiqué sur la page How To Install Django.

Il lance donc les commandes suivantes:

biboul@laptop:~$ svn co http://code.djangoproject.com/svn/django/trunk/ django-trunk
biboul@laptop:~$ ln -s `pwd`/django-trunk/django /usr/lib/python2.5/site-packages/django
biboul@laptop:~$ ln -s `pwd`/django-trunk/django/bin/django-admin.py /usr/local/bin

Il a bien entendu

configuré son serveur apache pour utiliser le module WSGI
testé avec le script wsgi "hello world" que la configuration était bonne
modifié le script wsgi de manière à utiliser son application django mysite

Le problème

Lors de la première requête à son application mysite, une belle "500 Internal Server Error" s'affiche, avec les messages d'erreurs suivants dans le fichier /var/log/apache2/error_log:

...  mod_wsgi (pid=5803): Target WSGI script '/opt/tcs/tcs.wsgi' cannot be loaded as Python module.
...  mod_wsgi (pid=5803): Exception occurred processing WSGI script '/opt/tcs/tcs.wsgi'.
...  Traceback (most recent call last):
...       File "/opt/tcs/tcs.wsgi", line 6, in <module>
...           import django.core.handlers.wsgi
...  ImportError: No module named django.core.handlers.wsgi

Mais pourquoi donc, alors qu'un import django.core.handlers.wsgi fonctionne correctement, que ce soit dans l'interpréteur ou dans le shell django?

La réponse

Tout simplement parce que le répertoire django-trunk (dont notre cher utilisateur biboul a fait un lien symbolique dans le répertoire*site-packages*) n'est pas accessible à un utilisateur différent, si il n'est pas dans le même group.

Or, par défaut et sur la plupart des distributions Linux, les processus apache sont lancé avec un utilisateur limité (www-data, www ou encore apache).

La solution

Un simple chmod 755 des répertoires parents au répertoire django-trunk est suffisant pour régler ce problème.

Une autre solution, plus propre et sécurisée, serait de placer le répertoire django-trunk dans le répertoire /opt, et de modifier les liens symboliques pour utiliser ce nouvel emplacement.

30 ans, et toutes mes dents

2009-02-15T23:06:00+01:00

30 ans aujourd'hui.

Il reste encore une petite heure dans cette première journée de mes 30 ans. Et je commence un blog.

Je jette dans ce tout premier billet les motivations pour ce blog (qui restent pour l'heure très vagues):

Avoir un aide-mémoire
Structurer mes pensées et divagations
Ajouter ma pierre à l'édifice

Quelques règles pour les futurs billets:

Travailler sur la concision et la clarté
Une écriture claire, simple et directe
Pas de billets inutiles

A bientôt pour la suite.