xssfox

I’m currently waiting for my bike parts to arrive today, but in the meantime I thought I was explain to y’all the plan.

JSON is my road bike. I use it to get to many things. It now gets very regular use, sometimes short rides, sometimes ride that I consider long. JSON is a vintage road bike, I don’t know when it was manufactured or by whom. Given it has Suntour 7 derailleur I’m guessing mid 80s. While these bikes are amazing (please try one), given the age they do come with some design problems. The biggest has to be braking. While I like to keep things fairly original on the bike, given that I doing more and more city and busy area riding I want to make the bike a little safer.

Now the brakes work just fine on JSON. The major problem comes with where the brakes are. If your not familiar with road bikes, those curved down parts of the handlebars are called the drop bars. The idea is that when you want to ride fast you “ride in the drops” - that is move your hands to the bottom of the handle bars to get a lower position. In contrast if you want a more comfortable ride you might ride on the “tops” or like the picture below is doing riding in the “hoods”. The hoods in a modern road is the combination gear shift and brake controls - well the hood is actually just the cover on top….

I however don’t have a modern bike, so I can’t ride on the hoods. Even if I did ride on the sides I don’t get enough lever force to correctly apply the brakes. This means that if I want to brake I have to be in the drops. When I’m riding around the city or busy path ways I’m often sitting upright to get better visibility and stability at the lower speeds. At the moment I have to choose between being in the drops for braking, or upright for visibility and flexibility - often I end up riding in an awkward halfway position with one hand in drops and one hand not.

But how do you install an extra set of brakes when there is only one cable? That’s where the inline part works, but lets first look at how a normal set of brakes work.

I’ve tried to create a crude diagram of brake fundamentals for bowden tube brakes. A bowden tube is, well a tube. It has a wire running down it. If the tube is fixed in place at either end you can push and pull the wire and the wire will push and pull from the other end. The final part is some pivot points, so when you pull on the brakes it pulls some wire out of the tube, that pulls the wire down on the brake end which squeezes the brakes together. Ok I get how bowden tubes work, what does this have to do with inline brakes….

For inline brakes the brake levers connect the outside of the bowden tube. The actual cable is unimpeded and the other brake will work as normal. Hence the inline part. In this diagram the left bowden tube is physically attached to the lever arm behind, and while the right part of the bowden tube outside is connected lever arm on top.

When we squeeze these levers together like you would on a brake the two bowden tube segments pull apart, widening the gap between the two bowden tubes.

The wire has to remain the same length however it now has further to travel, so this causes the wire to pull on the brakes…. hopefully bringing the bike to a stop. I’ve kept the wire the same length in these diagrams. I’ve also left the bowden tube the same length as well as that can’t shrink - so if we created a gap in between the tubes, where does that length go? We’ve effectively lengthened the bowden tube. In the real world the bowden tube gets slightly pushed aside, you do need to account for the movement in the bowden tube when it comes to routing and taping the tubes.

Installing these takes up handlebar space. I’ve already moved my phone mount to the stem, however I might need to rethink my bike light.

Finally, lets talk brake callipers. While braking on JSON is fine, I do want to make it better. Especially when I loan out my bike to someone else to ride. It currently has its original single pivot brakes, and the springs are a bit worn. Coupled with wheels that are over due for trueing it can lead to a fairly mushy experience if your not used to it.

That’s the plan.

Last Sunday around noon I realised that I shouldn’t be sitting mindlessly browsing the internet when Melbourne for once had half decent weather. Normally I’d go out for a run however my body needed some good recovery time so I decided to go on a walk. (narrator: this adventure did not end up being good recovery time). I slapped on some sunblock and a hat and set off.

The rough plan was to go on maybe a 5-10km/~1hr walk. Enjoy the sunshine and river. That sort of thing.

Walking lets you take in the sights better. You get to see a lot detail than just jogging past. There’s no pressure, you can stop to take a picture or enjoy a lizard friend crossing your path.

I however became more and more frustrated at the amount of litter I walked past. Right next to the river.

I eventually found a cement mix bag blowing in the wind. That was it. I was going to take that bag and pick up every bit of litter I could find along the way. I was walking, I had all the time in the world, I may as well do something good.

It didn’t take long however to fill the bag. By that time I had reached the Collingwood Children’s Farm (I must stress, that this is a farm in which children learn farming. They do not farm children there). I found a staff member and traded the concrete bag filled with rubbish with a new cardboard bag. In hindsight I should have tried to keep the concrete as it held a bit more, but I need to dump the rubbish and this was the easiest way.

Now I probably should have turned back then, however I was enjoying being outside and the weather. So I kept on going, picking up rubbish, jumping into creeks to fish stuff out, digging out stuck cans and bottles from garden beds.

Along the way I found some interesting things:

• 4x Bicycle rims
• North Melbourne Rec center pass (seems to be Mifare Classic)
• A credit card
• A surprising amount of clothing
• Two different shoes
• A full bottle of hair conditioner
• Hand pump paint sprayer
• Menu log delivery bag
• Scaffolding tag

I think the things that disappointed me most though were:

• Energy gel packets (these are used for refuelling runners and cyclers on the go)
  • It was always the same brand - so maybe it’s just one arsehole that runs or rides a lot
• Dog litter bags
  • I don’t think I’ll ever understand this. People pick up after their pets, then leave the bag near the footpath. This is literally the worst.

The bags of rubbish kept on filling and I kept on going. Where I could I favoured bins I could sort recyclables out - however some councils seem to only have general waste bins. Better in landfill than in the river though. I ended walking 20km over 4 hours.

Probably the worst section was from Flemington Bridge area where the M2 covers the track. I had to walk past so much rubbish because I couldn’t fit it in my bag. I suspect this section could do with more public bins however my guess is that most of the rubbish is from motorist yeeting their rubbish from their cars. That appeared to be a common thing as anywhere road related had significantly more rubbish.

I don’t think it’s all doom and gloom for the future though. I found surprisingly few shopping bags in my travels. I was expecting to find more plastic bags along the way to increase how much litter I could carry between bins. Guessing the plastic bag bans have worked well then. A lot of what I did pick up was bottles and cans. With Victoria finally introducing the container return scheme today (1st November 2023 as I write this post) I’m hoping to see a huge improvement. Coffee cups however… I think we need to consider a ban on those.

For me this was an unplanned adventure. A lot of people got in touch with me after asking me to go watch Beau Miles. I since have, and their videos are worth a watch. He’s a little more planned with collecting rubbish and I think I should start thinking about improving my rubbish collecting strategy.

The plan that isn’t so much a plan

I don’t really do these long walks often. But maybe I should? Maybe next time I should consider:

• Garden bags for collecting more waste (ideally I want to grab these second - things like pool salt come in them are generally used once)
• Snacks and water - While there was water on the track, I didn’t eat or drink anywhere near as much as I should have
• Support bike with trailer - maybe I could run behind a bike with a trailer to hold more stuff - this is a bigger project though
• Maybe focus on a really bad area rather than a really long walk
• Plan out where to return rubbish to - ideally being able to recycle

If I’m just going out for a walk I may as well pick up some trash along the way. Maybe I’ll do this again sometime.

I’ve recently been able to sit down and do some more backend work on some SondeHub backend code. Some of these changes I wanted to ensure didn’t cause any problems or issues to end users. To help build confidence that the changes would ok I started looking at Python unit testing solutions. I’ve only done minimal unit testing in Python before some time ago, but with a quick read of the unittest python docs page I was up and running.

I’m not going to bore you with the details here, but I wanted to share some of the features I found quite useful to test some bits of our code.

The first is MagicMock(). This lets you quickly mock out a method. The advantage to using MagicMock over your own method is that you can quickly assert a bunch of conditions to check if the method was or wasn’t called and with the correct arguments. An example usage of this might be:

import boto3
from unittest.mock import MagicMock

sns = boto3.client("sns",region_name="us-east-1")

# Mock sns.publish
sns.publish = MagicMock(return_value={"meow":"meow"})

sns.publish(TopicArn="blah", Message="blah")

# check to see if it was called
sns.publish.assert_called()

The mock library also contains patch which works very similar to MagicMock, but you can use it as decorator. When used this way you don’t need to worry about cleaning up or resetting the mock for every test. You can also use the wraps argument to call a real method while still retaining the ability to trigger assertions.

@patch('time.sleep', wraps=time.sleep)
def test(PatchedTime):
    time.sleep(10)
    PatchedTime.assert_called()
    PatchedTime.assert_called_with(2)

test()

Speaking of assertions, it’s sometimes handy to test that methods are called with the correct arguments in the correct order. Python unittest makes this fairly easy allowing a list of calls to be checked using assert_has_calls

from unittest.mock import MagicMock, call, patch

es.request.assert_has_calls(
    [
        call(json.dumps({}),"flight-doc/_search", "POST"),
        call(json.dumps({}), "ham-telm-*/_search", "GET"),
        call(json.dumps({}),f"ham-predictions-{date_prefix}/_bulk","POST")
    ]
)

With unittest I was able to create a few core tests for functionality along with write tests for the new functionality I was building (yay test driven development!). Even with the patchy cell coverage along my train ride was able to quickly iterate over a few designs without the need for manual testing against a live backend. I know that this hasn’t been an in depth look into Python’s unittest functionality, however I hope it sparks someones interest in giving it a go.