TinyBmp: A small program for generating images

Ver este artículo en castellano aquí

We have recently bought a new LED display like those you can find in the train stations for keeping a control of the current release number (important when you are developing super-secret features). The screen contains a 21×7 matrix, so there is not too much to do.

The good news is that the screen supports rendering of bmp images, so I figured that creating a program for generating this kind of images could be fun, and that’s what you can find in TinyBmp:

It contains three different projects in C#:

  • A class library that does the magic.
  • A desktop windows app.
  • A console app, for automating the image generation every time we ship a release.

This is how the tool looks like:

And this is how the output looks like, a 21×7 image in bitmap format (bmp).

foo

I know that we can generate images with C# from text natively, but is not the greatest choice for low resolution problems because the numbers get disorted. In this aproach I’ve generated the number manually, having a 2×4 matrix for each number pixel per pixel.

This has some drawbacks, for example, 0 and 8 are represented by the same character, but I’m working on it.

You can find the code in https://github.com/rlbisbe/tinybmp under MIT license.

If you have any issue or improvement idea, please let me know, or if you hacked the code and found an improvement, send me a pull request!

DVCS: The ultimate tool for a hackathon

A hackathon is a social event for programmers and designers with a clear goal: Develop an app in a specific time (normally 24-72h) in the language or platform chosen by the host. Time is a key factor, and 5 minutes can turn a stable project into a complete mess.

In this case is very useful to have a version control system to track the changes done in a project, keeping those changes under control.

Last time I went to a hackathon, I saw the frustration of some of my teammates, who were using the new Team Foundation Services Preview, a great tool with a huge potential, but maybe not the best option for this scenario:

  • It needs a stable Internet connection; otherwise the checkin and checkout operations are unavailable.
  • It’s centralized, so every time a check-in is done, all the source code its integrated, so if the client detects changes in the servers, It will be necessary to get the last revision, make a local merge, and afterwards, commit the changes back to the server, wasting time.

With this in mind the version control system becomes a sync tool, rather than a control tool. This scenario, using a distributed version control system (DVCS) could be performed this way:

  • A member of the team is able to commit the changes of his code independently, in a separate branch, and keep the history of the changes.
  • The rest of the members can replicate the changes, using the local network, saving bandwidth and avoiding the usage of external servers.
  • The access may be limited, even in the same network only authorized users may be able to see the code and replicate the changes.
  • The merge operations are less frequent, integrating finished components; therefore we avoid risks like introducing new bugs. Also, tools like PlasticSCM’s Xmerge can detect refactored code helping a simpler integration.
  • All changes may be integrated at the same time the code is being created, independently.

Plastic SCM, as stated before, is a distributed SCM that allows all the discussed features, but also Git or Mercurial will do the job.

In an agile development, the right tool can make the difference between a standard app, and a winner app. On your next hackathon, try a DVCS, and if you try Plastic SCM, leave a comment with your feedback.

Hello world!

Welcome to the first entry of my english blog. 3 years after starting to blog in spanish, I thought that it could be a good idea to start translating some articles, and have this site for english readers.