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).
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!
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.
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.