Robin Clarke – Life and Tech

Git is the latest and greatest amongst version control systems.  Git is:

a free & open source, distributed version control system designed to handle everything from small to very large projects with speed and efficiency.

Every Git clone is a full-fledged repository with complete history and full revision tracking capabilities, not dependent on network access or a central server. Branching and merging are fast and easy to do.

Git is used for version control of files, much like tools such as Mercurial, Bazaar, Subversion, CVS, Perforce, and Visual SourceSafe.

But how do you persuade your boss, friend, co-worker, …. that it is so much better.  You can rant and rave about how quick, compact and cool it is till the cows come home, but they probably won’t be converted until they see it live in action, and that often takes time…  And in a slide show presentation you don’t want to wander off hacking at the console changing files and cd-ing directories just to show checking in/out a few files…

Along comes Git::Demo – a Perl module to allow you to write stories about Git, and then play them back to your friends, colleagues and bosses to your hearts delight, showing off the snazzy coolness of git.

A Git::Demo story is written in YAML (that’s like XML, but easier to write/read), and has characters:

characters:
- name: Bob
- name: Mary
- name: Jane
- name: Peter
It has events:
- type: print
  action: screen
  characters: ALL
  args:
  - Yippee - go-go-Git!
And those events can be print (prints to screen), “git”, or “file” events
- type: git
  action: remote
  characters: ALL_NOT origin
  args:
  - add
  - origin
  - ../origin
By writing a story of events carried out by the characters, you can show live (and with wallclock times) how quick and easy Git actions are, and you’re not just doing a “here’s one I did earlier” show: it’s happening live at that very moment, so if your viewer says “Wait a moment, what happens now if I …?”, you can pause the story, and do it right there and then.
Git::Demo is still pretty rough, and my sample scripts are short and not so cool yet… but I’m hoping that this will catch the eye of other Git-Lovers out there, and that some will help improve the code, and write more stories!
Have fun, and use Git! 🙂
				

We have two red-eared slider turtles.  For most of the year they live in our living room in a big aquarium, but for the winter they have to go into hibernation.  As the winter approaches, the light and temperature in the aquarium has to be reduced, and then around the beginning of December they have to go into complete darkness, at about 10C.  Last year we tried putting them into the cellar: our cellar was too cold (went down to just +1C, could have frozen…), my girlfriends parents cellar was too warm, and in the end our neighbours cellar had about the right temperature… but a lot of bother.

So this year I thought I’d find a technical solution.

• styrofoam and spray foam around a storage box to make a really well insulated box for the turtles.
• Two CPU water cooling blocks sandwiching a Peltier element (thermoelectric heat pump).
• From the cold side of the heat pump a water cycle through a copper pipe in the turtle box to cool the box
• From the hot side of the heat pump a water cycle through a radiator to cool the water
• A networked atmega processor to read the values from two thermometers (one in the cool water cycle, one in the turtle box), and turn the pumps and peltier element on and off.
• A Perl script to control it!

When I’ve got the logic and parameters worked out, I’m going to translate the logic of the Perl script to C and load it onto the atmega processor, but for starters Perl is a great helper because I can quickly prototype, try out and refine without having to recompile, and to be honest… I just don’t really like C as much.

And as a by-product of monitoring and controlling the system with Perl, I was able to easily store the data in an SQLite database, and use GD::Graph to create pretty graphs to see how healthy the system (and of course the turtles) is:

This is what it looks like:

XML is a ubiquitous format for data transfer, configurations, and so much more. Processing it can be easy, but it can also be a pain. As always with Perl, there is always more than one way to do it… So I’ve created a framework to test, and compare some of the modules available.

The modules I considered were:

XML::Simple
XML::Smart
XML::Parser (using Tree style)
XML::Twig

My tests take a given XML (a list of films as generated by Mediathek), parse out the individual film entries, and print them out to a csv file. I don’t actually need this, but it’s a typical functionality you might need when working with XML, and allows some good comparisons with both small and huge file sizes.

Considerations:

The main difference between the clever modules (XML::Simple and XML::Smart) and the more grass-roots (XML::Parser and XML::Twig) is the method they use to work through the XML. To be clever, the clever ones suck in the whole XML, analyse it, and create a good hash/array representation of the elements. This has the advantage of having an easy to use format to work with afterwards, but also requires sucking in the whole XML in one go: not a problem for small files, but it quickly becomes dangerous because the system will use 10-20 times the file size in memory: a 60MB file can easily consume 1GB in memory! XML::Twig by contrast works through the file element by element, and so its memory usage is very controllable: it is possible to parse hundreds of megabytes without the perl application expanding beyond 12MB in memory! On the other hand: the clever modules are much easier to use, and you don’t need to know anything about your XML to process it. That makes these modules much more attractive for small (e.g. configuration) files.

For the details of the implementation, please have a look at the code examples:

git clone git@github.com:robin13/rcl-ironman.git

My tests showed these relationships, though your mileage might vary – it depends a lot on the depth/complexity, and variance in size (big on Mondays, small on Thursdays?) of the XML you are dealing with.

By Speed (seconds to process a 66MB file)

XML::Parser   26.5
XML::Simple   76.0
XML::Twig    132.8
XML::Smart   394.9

By Usability (subjective) to implement

XML::Simple     Easy
XML::Twig       Usable
XML::Parser     Complex
XML::Smart      Not so smart...

By Memory consumption (system memory in kB used for a 66MB file)

XML::Twig        972
XML::Parser   506532 (using Tree style)
XML::Simple   628268
XML::Smart   1336604

To summarise:

If you want high performance: XML::Parser
If you want relatively easy, memory efficient parsing of huge files: XML::Twig
If you want easy-to-implement for small files: XML::Simple
If you want to have a bad deal: XML::Smart

What I left out:

Probably a lot of usable modules…  If you know of something important, please comment!
Input/Output: XML::Simple and XML::Parser can output XML too.  That might be important for you (e.g. config files)!
My code is proof of concept, not highly optimised: feel free to improve, or even add other modules to the tests.  Git makes that easy! 🙂