Personal blog of Davorin Ruševljan.
For quite a long time, I used to think that riding a bicycle on snow is, while not strictly impossible, something extreme, like walking on the rope or trapeze act. Most of my bike riding is leisurely commuting over the flat streets of Zagreb, and I almost never go of the paved surfaces. I am 47 years old, and dexterity or sense of balance are by no means my strong points. Anyway, I was intrigued when few cyclist with much more experience told me that they commute even when there is snow.
So I decided to give it a try, and .. whoha!
Not only that it can be done, but it is in fact quite often fun, and very nice experience. There are risk of course, but I would say that for many types of snow surfaces, it is often easier to avoid falling from bicycle than from your own feet (ok, falling from the bicycle could have more serious consequences).
If you do not have experience of driving on off road and slippery terrain like me, but you would like to give it a snow try, here are some tips:
Fatter tyres with deeper profiles are better. Tyres with studs are way better on icy surface. Mine are Schwalbe Marathon Winter, 37x622. When driving on the snow, you are probably not going to break speed records, so take into account that you will be generating less internal heat. But do not over dress either, so that you sweat too much or fill stiff or restricted in your clothes. Taking an extra pair of gloves in case primary ones get wet is not a bad idea. Wear solid winter shoes with very good grip.
Before you sit on the bike
warm up properly, especially your back, shoulder and arms. If you are anything like me, your bike will slip from time to time, and until you get some hang of it, your body will be reacting with sudden panic movements originating from your back.
First ride, where and when.
Ideally choose a flat route that you know, free of other vehicles and pedestrians, with hard and even surface covered with 5-8 cm of fresh snow. Riding on such road should be easy-peasy, since wheel will be cutting almost completely through it, and you will be grinning all the way. Keyword here is even surface and fresh snow, uneven surface or semi melted or semi frozen snow will complicate things.
It sounds funny, but for me, mounting or dismounting the bike seem to be among the moves having the largest risk of falling. You have to balance on one foot on the slippery surface and swing your other leg. So try to find good, flat, not to slippery surface to mount and dismount, and do it carefully. Also this is the point where your solid winter shoes should come handy.
Be soft. Be very soft. Move yourself a little to the back and make sure that you are not heavily leaning on your hands. Your hands should not be stiff, but light and free to react quickly and with good control. Try to avoid panic responses when something throws you off course and respond quickly but with moderation. Concentrate on the surface before you, and try to spot troubling spots ahead of you. It takes some time to find a good speed. Generally you will not be moving fast, but it is important that you strike a good balance. Some speed helps you to cut through uneven terrain, but too much speed will not give you time to react when something throws you off balance. Also take into account that stopping will take more time and space.
Kinds of snow
What kinds of snow, say you, they are all white right? Wrong. Structure of the snow, underlying surface, all influence how will you get over it. The very same part of the road could become from very easy into very difficult in half an hour by some melting/freezing going on. The snow that was strong enough to support you would be collapsing under you, or snow that you were cutting through with ease will be now stiff like rock and throwing you in all directions. Learning to recognize, and read the properties of path in front of you will take some time, but also make the whole process interesting for a long time.
As general rule of the thumb, avoid surfaces that are under angle, since your wheel will not be able to support you like it does in normal conditions. Ice is fine, especially if you have studded tyres. Just try to avoid mounting and dismounting Narrow paths made by people walking can be very tricky since their profile is very often like a peak of a mountain, so you are constantly thrown left or right.
Remember that pushing your bike over troubling section is always an option. If you do not feel secure, dismount and walk.
Now go out and enjoy some snow!
It all started this Saturday (24th of November 2012), the gmail app on my T-mobile G1 (also known as HTC Dream: grand father of all Android phones) stopped to sync mails. When I tried to open some label, it told me there was an network error, which sounded funny since at the same time I was able to browse normally.
After waiting a day in hope problem would go away by itself, I have concluded that some action is needed. Web search indicated that there are such cases, and consensus was "yes, it does happen, clear gmail (or some other google application) data, and either the thing will fix itself, or you will enter your account info again, but eventually it should come to senses.
Well, I started deleting various google application data, but the problem was not going away, and I had less and less google services available. Finally I have reached the point where I had to reenter my account info or create a new google account, and to my despair, I was not able to do either. I was politely informed that there is network error, and that phone is unable to reach google servers. Needless to say, at the same time I was able to surf the net without problems.
At that moment I have decided to try something I should have done in the beginning, try to open gmail from the web interface. When I tried, it did open, but only after few warnings about invalid certificate for the google.com domain provided by google servers!
So my theory is that on Saturday google rolled out shiny brand new SSL certificate on its servers, but it forgot that validity of those certs can not be verified on old Android 1.6 devices, probably because root certificate needed for verification is not included on those devices. Which is not such big problem if user browses the web. He gets the warning, and can proceed (at his own risk) if he needs to. But probably the very same web browser component is used inside core google apps for android, and those apps just get exception when they try to get resource protected by new certificate, and proudly claim that google servers are unreachable as consequence. And anyone using those apps is doomed from that point on. Gmail, contacts, calendar, market, to name a few.
At that point I realized that my smart phone is not very smart any more. For a long time I was tempted to install CyanogenMod to my HTC Dream, but I was afraid that I migt loose my data and even brick the phone. Now when most of my data was inaccessible, and phone turned into bulkier equivalent of Nokia 3310 with poor battery life, installing CyanogenMod did not seem such a big risk, and new version of OS should be able to handle new certificates without problems, right?!
So there I was reading (very good) tutorials how to install CyanogenMod on HTC Dream. Procedure basically consisted of downgrading OS on the phone to the initial version which has exploit in it, downloading telnet client from the market and rooting the device through telnet, and then installing Cyanogen. So I have downgraded Android to ROM version 29, rebooted the phone, initial setup started, asked me to use existing account or create a new one, and you have guessed it by now, it was not able to contact the darned google servers! Only now I was not able to do even the simplest things with phone, It refused to do anything until registration process with google is completed.
I had faint hope that maybe it was my SIM card causing the problems now, so I purchased T-Mobile card with data plan for $4 and tried with it. Still not able to reach google servers and register. Then I found tutorial how to activate android without SIM card . It involved connecting phone to pc thorugh USB and adb utilities, triggering Wi-Fi control panel on the phone, where I turned the Wireless on, connected to the net over Wi-Fi, and then proceeded with activation now over the Wi-Fi connection. Which of course did not work either since activation could not reach google servers. So obviously downgraded version of Android was not able to deal with new certificates either (not a big surprise when I think of it now).
So, it seemed to me I was defeated, and I started to get used to idea of using Nokia 3310 for a while. Then occured to me that I might use the same trick that was used to trigger WiFi through ADB, to install Telnet client and start it on the phone - without going through activation and completing it. After some poking around I found a way to do it, telnet got installed, started, I connected to the localhost, rooted the device, and from that point on CyanogenMod installed like charm. Here are details how to root HTC G1 without activating it.
So now my 4 years old "grandpa" phone has newer version of Android OS, and it runs nicely, my emails and contacts sync! Phew!
There is nice tutorial how to root HTC Dream (also known as T-Mobile G1)
Unfortunately, this procedure requires that downgraded phone gets activated over the google servers, and at least as it seems now there are some problems with activating such old device, possibly related to google web site certificates
Here is the small modification of procedure described in tutorial how to root HTC Dream, which bypasses activation.
- Before you begin, and while your phone is completely operational go to Settings » Applications » and check Unknown Sources.
- On your PC download telnet client, save it locally on, and take note where you have saved it.
- setup ADB on your PC as described in this tutorial You are not done with this step until you can see your phone listed in output of "adb" devices command
- Now proceed with instructions on how to root HTC Dream, from the start until including step 3 of paragraph "Rooting the HTC Dream"
- Now instead of steps 5,6 enter following adb commands (modified for correct path to the telnet apk you have downloaded before)
- adb install Telnet.apk
- adb shell am start -a android.intent.action.MAIN -n koushikdutta.telnet/.TelnetActivity
- after this on your phone telnet should be started. Connect to localhost port 23. You should connect succesfully.
- return to and follow instructions on how to root HTC Dream from paragraph "Installing a Custom Recovery Image" till the end.
That should be it.
I really like version control systems, especially when they get me out of some of my careless deeds. Other that that I prefer if I can remain unaware of them, and that they do not compete with my brain cycles with other tasks.
Git is in many ways great, but unfortunately, it requires constant attention and care. You just need to have rather deep understanding of how it operates under the hood. There are some great cheat sheets - but they will get you only so far that you get yourself hooked into git. But if you rely only on them, pretty soon you will be shooting yourself in both feet while tightening the rope around your neck.
Some of the reasons while git can be demanding stem from its roots. Once upon a time Git was a VCS toolkit assembled of procedures to manipulate git database. So it was more designed to offer nice and complete API, rather than simple command line user interface. As more people with less knowledge of git started using it, git got friendlier command line, but some things remained. For instance, imagine you have been experimenting a bit changing some files in working directory, and then you decide you just want to throw all that away, and return to last commit. It is something conceptually simple, and in my work-flow occurs on regular basis. Yet to instruct the git to perform this simple operation you have to tell it:
git reset --hard HEAD
You can find this on number of cheat sheets, but I could not remember it if my life depended on it. I mean reset sounds like a serious verb (not necessary connected or limited to what I want to do), and takes one option (--hard), and one parameter (HEAD). What if I get some of that wrong, what in the git world is going to be reseted and to which effect? So I kept googling for it each time I needed to perform this operation. Until I found this great explanation of git reset command and things now finally make some sense to me.
What I wanted to say, is there is just no easy way with git. It demands its own time and understanding, sometimes even for simple operations. I definitely like git, but it surely finds its way to drain my resources.
Recently AMQP working group has promoted 1.0 version of its specification to final status. While small tick in version numbers from 0.9 to 1.0 might suggest a small incremental change, nothing could further from the truth. AMQP 1.0 is completely new and fundamentally different protocol than existing 0.x family.
What do I mean by fundamentally different? Well, to begin with, problem domain that 1.0 tries to solve is different. Existing amqp protocols describe messaging brokers, their behavior, how to connect to them, and how to control then (to certain extent). So there were exchanges, exchange types, routing keys, queues etc.
1.0 takes different route. It tries to define protocol that could be used to connect more or less any 2 messaging entities - called nodes in 1.0 terminology, and safely and predictably transfer messages between them. It defines how to achieve various message transfer semantics: "at least once", "at most once" and "exactly once". It also specifies how to resume interrupted transfers if they occur.
But what nodes do with those messages after transfer, well, that is completely up to them, and specification leaves this open. It could be that you are transferring a message to old style AMQP broker with exchanges and queues, and it would do probably same thing as before. It could be that you are sending a message to some JMS system, and effects of that message transfer would be according to the JMS semantics. Or you could be transferring a message to your in house optimized messaging entity, like for instance stock exchange trading system, which would in turn process that message as trading order, match it with other orders, execute, and distribute new price information further down the line.
So one look at this might be that by specifying less (since it does not specify broker behavior at all), 1.0 provides opportunity to apply it in larger number of situations. But keep in mind that at this time, this is still just an opportunity, not something that you can do right away. Someone would need to write JMS gateway (or write trading system that uses 1.0) before that.
I hope that after this 1.0 release, which could also be considered "core specification", AMQP group would get really busy on other specifications layered on top of it, which would deal with standard broker behavior and management of brokers.