My first 12h (well 6.5h) solo race
I signed up for the Stamina12 race some time ago, wanting to try my luck at a solo 12h race. Due to various circumstances (family, job, selling house, lots of excuses) I did not actually train for this though. I had my training well thought out, but it just never materialized. A month before the race I seriously considered just selling my entry because I was so ill prepared, but in the end I decided to give it my best shot.
Well so I did, this saturday. I ended up number 68 out of 113 which, considering that I called it quits after 6.5 hours on the track, is not as absolutely terrible as I feared it would be.
So why did I chicken out early? Especially my upper body was simply "spent" and I started making really silly mistakes and taking falls where I should be perfectly able to ride safely. There were other factors (which I will get back to), but my own safety was the primary concern. I do not race for a living, I race because I like to.
I have raced before, just never a 12h solo. In the past, my main trouble has been with the bike, not with the body. This time I was better prepared than ever before - on the mechanical side - and I believe that my bike could have made it through the full race.
Here is a list of things that helped and stuff that I just got right:
- Hydration. I rode with two 750ml bottles on the bike, one with High5 4:1 Citrus and one with Summer Berries. This worked well as each lap took about 50 minutes, so I needed slightly more than one bottle of drink. I stayed hydrated the whole time (after about 2 hours I had one lap where I drank almost two bottles in less than 1 hour. It felt like I was not well hydrated, but after drinking extra, all went back to normal and I was fine).
- Clothes. I brought plenty. Shorts, shirts, anything. It was so good to be able to adjust after the first few laps. I even packed an extra pair of bike shoes, just in case I would lose the cleats off of the first pair.
- Brakes. The bike had almost new brake pads front and rear, but after six hours most of the rear wheel brake pad was gone so I would probably have needed to put on new pads, had I continued much futher. I had brought two sets of extra pads and the necessary tools so this would have been no problem at all.
- Power. Since I run my Edge 800 with backlight always-on, it goes through the battery a bit faster than the 15h claimed by Garmin. After 7 hours on the battery was down to about 10% but since I brought a fully charged "powermonkey", I could have charged the computer (while riding) over a couple of laps. This would have been no problem.
- Helosan. Or eight hour cream or vaseline or whatever you prefer to use to be able to continue to sit down and pedal. I brought it, I needed it after three hours and it absolutely saved the day. Some pain is ok and some pain isn't - this is one that is easily avoided.
- Glasses. To protect your eyes - always ride with glasses.
- Tools. For the first time ever, I raced without tools on the bike. Since a lap was less than 1h I figured that any adjustments or brake pad replacements etc. could be made in the pit. Since I run "flatless" (tubeless with sealant) a flat is very unlikely, so I chose to bet that I would not need tube, pump and tyre irons. The only "common" problem left is a broken chain - I chose to believe that this would be unlikely too. For this race, I was right on all accounts. I never needed a tool on the track and I was happy not to have to carry them around.
The following are issues I need to address next time:
- Train properly in advance. This should be obvious, but really, if I wanted to do better, I should have been in better shape.
- More diverse nutrition. I lived off of High5 "Citrus" and "Summer berries" 4:1, and switching between the two keeps me going for a long time while still feeling that the taste is ok. But after more than 6l of this stuff, I really wanted something else. Something milky or "soft" that does not upset the stomach too much. Maybe chocolate? I drank a "For Goodness Shakes" recovery drink (which contains milk powder) and it tasted absolutely fantastic at this time... Maybe I should just down one of those every four hours? I should bring coffee too - I really could have used a proper cup of coffee (not just nutrition with added caffeine).
- HRM. I train with an HRM strap every time and it works flawlessly. But after 1.5 hours in this race, the HRM transmitter gave up and I was left to my gut feeling at how hard I was pushing it. This was a setback as I really rely on the numbers when I know that I am pushing my limits. Things just feel differently in a race too, so having the numbers are fairly important to me in order to pace myself (keep the heart rate down - force myself to go slower than I intuitively would otherwise).
- Timing. I should stop the timer when in the pit and then I should use the "elapsed time" instead of the "time" field on the computer - that way, I would still see the elapsed race time when on the track, but when analyzing my laps post-race I would see the correct lap times instead of the lap+pit times.
- Chamois cream. Some people coat their shorts with this stuff before they ride. This is something I need to test, I think...
- Camelbak. I have a 3l (lobo) but I only just got it, have only ridden with it for a couple of hours, so I did not want to use it for the race. However, I did lose a bottle (without noticing) on a bumpy descent during one of the early laps and this would not have happened with a Camelbak of course. I need to figure out whether I want to ride with a Camelbak or continue with the one or two bottles on the frame (which have worked well for me so far).
- Pay attention all the time, not just most of it. I took a fall on a gravel road riding almost 40km/h very early on in the race, simply because I was not paying attention to where I was riding. It was a very stupid mistake which could and should have been avoided. I was lucky and got away with just cuts and bruises - but this race was in a forest and hitting a tree at that speed would not have been pretty.
The quick statistics of my race are:
| What | How much |
|---|---|
| Ride time | About 6hr 30min |
| Distance | About 70km |
| Vertical climb | About 1500m |
| Energy consumed | About 2000 kcal |
| Energy spent | About 3000 kcal |
| Placement | 68 of 113 |
For me this was a fantastic race. I would like to have done better (of course), but I gave it my best shot and I learned some valuable lessons. Next time I will do better.
Riding tubeless
About two years ago I lost patience with fixing flats during my training rides. I had at least one flat on every ride out, and some times much more. On a single four hour training session I once managed to use a full pack of patches and a spare tube, and I still ended up having to carry my bike to the metro to get home. This was too much - when I get a chance to ride, I want to spend my time riding.
The first solution to this problem that I tried, was adding a sealant. The first product I tried was the Schwalbe "Doc Blue" sealant. The idea is that you pour some of this liquid into your tubes and then ride as usual. When a thorn or nail or other object punctures your tire and inner tube, the sealant will seal the puncture and you will ideally never even notice that you had a flat. The sealant will work almost instantaneously, so the drop in tire pressure due to lost air will be insignificant.
This did not work well for me though. It "almost" worked - but it seemed that the object that punctured the tube would stay in the tire and continue working on the punctured tube so that the sealant would never effectively seal the puncture. During this process, the sealant would leak out of the inner tube and into space between the tyre and the tube. So, when I eventually ran out of air and had to fix the flat with a patch anyway, the tube would be soaked in sealant on the outside, and wiping the tube down to make the patch stick would just add to the inconvenience of having to fix the flat in the first place.
Using sealant seemed promising at this point, but clearly it did not work for me to just add it to the tube. I also did have a few "snakebite" punctures - due to running the rear tyre with low pressure and being careless when jumping obstacles. Of course the sealant could not fix those (typically these are 1cm long cuts in the tube). The solution to snakebites is to lose the tube - to run tubeless. Since it also seemed that the tube/tyre combination was what caused the sealant to be ineffective, I decided to give this a try. Since I am on a budget, I went for the cheap option; the first setup simply used regular non-UST tyres, Joe's no-flats rim strips inside my usual Mavic Cross Ride (non-UST) wheelset and the Joe's no-flats sealant.
This turned out to do the trick! Early on with this setup I experienced
a puncture during a race; I noticed the "pfffft" sound of a flat on my front tyre and after two
revolutions the sound was gone, the puncture sealed and I did not have to stop to inspect
the tyre for thorns. There was one problem with this setup though; regular tyres are not
meant for tubeless application so they generally have thin sidewalls that are not air tight.
The sealant will solve this problem to some extent, but not completely. All in all, I never
managed to get my set of Continental 2.2 Mountain King tyres to hold air between rides. They
would hold the air fine during a ride (because the sealant would constantly be
swirled around the inside of the tyre sealing any microscopic holes), but the next day they
would be flat.
The solution to this problem was to simply buy real UST tyres. Tyres meant to be run without a tube. These generally hold their air - well, I have three tyres mounted on rims and two out of three hold their air. That last one loses air over a week or so. To me, this is perfectly acceptable. I have not had a single flat for two years on my mountain bike. This is absolutely fantastic - it means that when I get out to ride, I actually get to spend my time riding.
The major downside to running "flatless" (tubeless with sealant), that I have noticed, is: Limited availability of tyres - there are only very few models available in UST variants. If you are very picky about tyre choice, this may not be acceptable to you. Personally, I am perfectly happy running with a 2.2 UST Mountain King on the front, and having the choice between either a 2.2 UST Race King (for dry days) or a 2.4 UST Mountain King (for muddy days) on the rear.
Another downside would be that it is a lot more complicated to change a tyre. You do not want to change tyres on your rims just because the weather changed - you only want to change tyres when they are worn out. You need to dispose of old sealant, dismount the tyre from the rim strip (which will often be sealed tight) without damaging the rim strip, get the new tyre to mount cleanly to the rim strip, inflate the new tyre so that it seals against the rim and of course add new sealant. My solution to this mess is to simply have two rear wheels mounted with each their tyre, complete with brake disc, bike computer magnet and casette. So, when the weather changes, I change the complete rear wheel - this is slightly more expensive than having just one rear wheel, but it is very convenient and completely solves the problem with tyre changes.
Packaging with the Solaris IPS
I needed to package some software for Solaris 11 and of course wanted to use the Image Packaging System, IPS, the new package management system that replaces the old SVR4 package format that Solaris 10 and previous releases used. To the casual observer, it looks like IPS brings "easy" package management to Solaris - it is now possible to quickly search for - and install - a package from the internet, and updates are easily retrieved as well. This seems to work smoothly - just like on Debian for example - which has had this functionality for more than a decade... Well, better late than never!
Since the system is not just new, but quite different from what it replaces, I started looking for primers and tutorials to figure out how to get started. A word of caution: IPS does things differently, and there are some tutorials on the net which attempt to fight IPS instead of working with it - this leads to complicated and silly ways of building packages the wrong way, and this will cause problems for your end users. What you really want, is to go to the official Oracle documentation and read the developer guide which is well written and does a very good job of explaining why IPS is different and walks you through an example of creating a package.
So far, I am fairly impressed with IPS - it is the first packaging system (and I have used quite a few - from DEC Unix and HP-UX to NetWare, Debian, Red Hat, Windows and what have you) where I did not have to script to create a user account. Scripting, by the way, is disallowed by IPS for the simple reason that you cannot validate a package if the installation executes scripts because you cannot (generally) validate the result of a script. Instead of using all the provided tools for generating manifests from older packages, I simply wrote the .p5m manifest files myself and generated .p5p repository archives from them. In the future I guess I should make sure the repositories are on-line, so that the users can get their software updates along with the operating system updates when they run pkg update.
Running - the beginning
I have been biking a lot the past few years, but I have not been running much. In fact, I have almost not been running at all. Because of the biking, I'm in reasonably good shape (resting heart rate in the 40s, body fat below 15% and so on) but I just cannot run. My legs just won't do it. It hurts, especially the days after a run. So, I decided to go ahead and start running regularly.
In order to fit everything into a tight schedule, what I can do is, that I can make two weekly runs - one in the morning and one in the evening, on a single day of the week. The run will be 8.4km in each direction (to and from work). That's it. Clearly, running twice a day on a single day of the week is not going to be an optimal training schedule by any stretch of imagination, but this is that I have to work with.
The reason for this post, is the rapid change I experienced over the first four weeks (four times two runs). I have put some key numbers in the table below.
| Run | Avg moving pace | Efficiency | Avg. HR | Pain following |
|---|---|---|---|---|
| 1A | 5:06 [min/km] | 13.1 [m/kC] | 161 [bpm] | - |
| 1B | 5:26 [min/km] | 12.7 [m/kC] | 159 [bpm] | Severe leg pain for 4 days |
| 2A | 4:51 [min/km] | 13.5 [m/kC] | 161 [bpm] | - |
| 2B | 5:10 [min/km] | 13.1 [m/kC] | 154 [bpm] | Some leg pain for 4 days |
| 3A | 4:44 [min/km] | 13.9 [m/kC] | 162 [bpm] | - |
| 3B | 4:56 [min/km] | 13.8 [m/kC] | 157 [bpm] | Only slight soreness for a day |
| 4A | 4:34 [min/km] | (N/A) | (N/A) | - |
| 4B | 4:43 [min/km] | 14.7 [m/kC] | 158 [bpm] | Nothing |
Personally I was very surprised to see the numbers change this much over just four training days (two sessions a day, one day a week, for four weeks). Due to illness I have had to skip two weeks, so it will be interesting to see how much damage that did, and how the numbers will progress from there. I would expect the average pace to stabilize first, and see the energy efficiency continue to grow further. I am curious by the way - what energy efficiency do you have as an experienced runner?
Making a roomba negotiate a doorsill
Having just become a Roomba owner, I was faced with the challenge of wanting the robot to negotiate a slightly large doorsill in a narrow doorway, as the robot should move form the livingroom to adjacent rooms. The manual says that you should lave at least 1 meter of open space from the front of the lighthouse - but this is difficult when the doorway itself is less than one meter. Second, the doorsill is a two-step construction with a 2cm climb followed a few centimeters later by a 1cm climb.
By default, the roomba could not reliably pass the sill. It frequently got stuck on the 2cm climb, and it bumped into the side of the door frame opposing the lighthouse.
Solution 1: Smooth the climb
To allow the robot to better negotiate the 2cm climb, smoothed it out a bit
with a ramp. This is a proof of concept - I will make one that fits better and
hopefully matches the colour of the floor or sill, but I needed a prototype
quickly.
Solution 2: Traverse closer to lighthouse
The robot cannot measure its distance to the
lighthouse as such (it has no laser based range finder, sonar or other means of
establishing distance aside from bumping into things or sensing "large objects
approaching"), so how does it decide which distance to keep to the lighthouse?
I could not find any documentation on this, so my best guess was that the
lighthouse is projecting an infrared beam from the top, at a downward angle
towards the opposing side of the door frame. The robot will then approach when
the beam has the right height, relative to the floor space of the robot. See,
this even worsens my problem - not only is the door frame too narrow already,
the lighthouse sits elevated on the doorsill while the robot is 3 cm below on
the floor, and will therefore traverse the doorsill even further away from the
lighthouse (since the lighthouse is elevated, the robot needs more distance to
the lighthouse for the infrared beam to reach the right height). The simple
solution is to glue two rubber spacers on the two back feet of the lighthouse, so that
it is tilted slightly forwards. This changes the angle of the infrared beam, and the robot
will find the right height of the beam closer to the lighthouse. I have no confirmation
that my theory behind this holds, but the solution works like a charm.
Autologin on (Oracle) Sun Unified 7000 systems
Having just received a Sun Unified storage system at work (basically two amd64 based servers and two disk shelves full of high capacity disks coupled with some read flash and fancy write optimized flash), I wanted to put the "dashboard" page from the web UI on a big screen on the wall so that everyone that walks by can see the current status of the system.
The system has an absolutely fantastic web based user interface. It
even supports the creation of "kiosk" users - accounts that are limited to
viewing only the dashboard. Just what I needed... However, there is no
(documented) way of actually having a kiosk session automatically log on to the
system, so that it could function like, well, a kiosk session.
The usual way of accomplishing this in a web interface, would be to allow the user to supply a &username= and &password= argument on the URL. It is simple and it works, and for a kiosk session that is locked down anyway, it is perfectly safe. This, however, is not possible on the 7000 series as the entire login page is not a form - it is a fairly empty piece of HTML that is then populated with DIVs by a lot of JavaScript.
Firefox, firebug and greasemonkey to the rescue! Using firebug I managed to figure out how to fill in the username and password values in the input fields and call the .click() method on the "login" button. To my surprise, even though the username and password fields were visibly filled in correctly, the click on the button prompted an error messaage saying I should "Enter a username". It seems someone really went out of their way to make sure that I would not get any real work done today...
After reading a lot of the JavaScript that was used to build up the login page, I could see that the "keyup" event was significant. It caused the input elemen .value to be assigned to some other variable which was then later used in other methods for the actual user authentication. Calling all those methods in the right order and even accessing them turned out to be a bit out of my JavaScript abilities.
In order to get the login code to run, I simply assigned the username of the kiosk user to the username input element .value, then create a UIEvent of type keyup and dispatch it to that element. Then the same is done for the password input, and finally the .click() method is called on the login button. This solved the problem in my test setup.
Then, a greasemonkey .user.js was created to automate this whenever the logon page would be shown. This, however, did not work. Of course, since the page is almost blank once it finishes loading and greasemonkey runs the JavaScritp that I supplied, there is no way my code can find the username and password entries - they simply do not exist yet. The JavaScript referenced from the nearly empty page must finish executing first. The solution - ugly but functional - is to delay the execution of my code by five seconds. This gives plenty of time for the page to materialize.
So, if you decide to purchase a Sun Unified 7000 series storage system and you want a kiosk user to access the dashboard, you can download the greasemonkey user script here.