iamnearlythere

Updates in background processes are sweet

I’ve fallen in love with Google Chrome in most ways. Not that Chrome’s anything extra, it’s rather that it’s not.

Everything is slimmed down, it’s super fast and it feels like it got less than half of both the competitors GUI (in a good sense) and their settings.

One of the best things about Chrome is the sense of versions. Background: I grew up with IE6, which still harasses my workplace’s usage statistics, the same app that MS doesn’t bother getting rid of (maybe they do, but as far as I know, they’ve yet to implement the subtle updating process of Chrome in IE 9).

Except being a wonder for us developers, the hidden update is good because:

• You’ll never see the “Your app has been updated, please restart it/your system”. Take a minute and realize exactly how important this is to avoid if you’re targeting anything but a techie crowd. At best, you’ll annoy users, at worst you just lost them.
• No compatibility issues for the user (since developers are responsible for serving only the latest version).
• Your app challenges your competitors app. Your competitors app has to challenge both you and earlier versions of itself. This could be applied to the cellphone industry where most companies release every.. I don’t even know, it’s ridiculous.
• The release pattern is used successfully in web based apps. The web as a medium has won much simply by being able to provide background updates - new layouts can be pushed right away (don’t even get me started on ajax).
• If an update is seamless and invisible, you could make a rollback seamless and invisible.
• Minor changes are pushed out more easily, a hotfix could take 15 seconds to download but make a large part of your users more satisfied with your app.

Client - or co-worker?

When working with retailers, one must walk a thin line in order to keep the retailers interested by teasing them and promoting your services, while at the same time retailers must be given the time and information to seduce their clients in turn.

Are your retailers clients or co-workers?

Open source project owners: control yourselves!

I’m trying to follow the development of an open source CMS called Pimcore but having a hard time following its development process, the same thing goes for my favorite PHP framework, ZF.

Read my lips: provide statements in one medium, reflect it elsewhere

These are all sources for news:

• irc
• email lists
• twitter
• forum
• blog
• facebook
• github/jira
• wiki

and not least, in official sources quickly multiplies the difficulty of focusing in the right spot. The same thing goes for official sources concerning a submodule/sister of the main project.

Supply and demand

Everybody knows how to backup but the important thing is to know how to restore from that backup.

I’m thinking this POV often is missing when discussing documentation of software. The Wikipedia article on Software Documentation is focusing a lot on pigeonholing the different type of documentation that may exist so that no type is left out. That’s sometimes what I feel myself when trying to document a process - have I really made sure that this way of documenting is #1 or should I just go over the alternatives again?

Hold your horses. From now on, every inch taken towards documenting something must be questioned.

Who will read this?

What does the person willing to read this expect to extract from this enunciation?

• Find clues fast to write their own, compatible code.
• Understand possible bottlenecks or places where refactoring would help extending the software.

Is there any way to make this process automated?

• PHPDoc is perfect for me. Short comments are generated when typing - doesn’t conflict with a mind set on the job at hand. Supports generation of a more thorough “book” without any effort.

Can I write better code so that the comment becomes superfluous?

• Crystal clear, long names of variables and methods. Few arguments for each method (remember those parameter objects (Fowler)).

In which form does the documentation best fit its purpose?

• UML, wiki, PHPDoc, essays.. I’d say: only document after code is written and tested. This does not include the project plan/spec, but the long time, maintenance documentation.
  • Document in different scopes:
    
    • Overview. Why does it exist? Which dependencies are there? (OS/compiled modules/ram/libraries..) I often learn better from figures.
    • One simple and one advanced use case.
    • Detailed. This is connected to dynamic typed languages such as PHP & JS: type hinting is needed for method signatures. Easily applied with PHPDoc.

Make documentation as automated as possible. Invalid documentation is worse than spaghetti code because you believe you got everything under control and then… there’s a deadline and you’re toast.