We moved our family from the US (Maryland, just in case you didn’t know yet) to Belgium – no big deal. During the COVID-19 pandemic, in July-August 2020 – now we’re talking …
I wrote this post to document our journey. We were (and still are) extremely privileged to have been able to do this, in the conditions we did it. The journey is not over. I’ll update and continue to document it until we fall back into something more “normal” … [long post]
This year, my elder son graduated from Cub Scouts to Scouts (time flies very fast!) and I signed up to be a counselor for Programming (and Public Health) in his troop.
Today, February 1st, 2020, was Merit Badge Day and I taught 6 scouts what is programming and the basics of programming in Python (and Scratch – but they all knew that already) (and nobody chose Public Health …).
I am now sharing my presentation and a few tips and tricks. Feel free to re-use, improve and give me any feedback to make it better.
The Boys Life magazine has also a dedicated page with a lot of resources for this Merit Badge. One of the nice features is that scouts can see the same simple program coded in different programming languages, allowing to compare them. They can be the basis for some of their requirements too.
It was the first time I gave this Merit Badge and having 6 scouts is a good number. You’ll face some issues helping them start programming, especially if all of them are new to programming. Also, it’s interesting to have scouts of approximately the same age: they will have similar reactions and they will be at similar level of programming. I had 5 6-graders and one older scout: the older scout had already a higher level of programming (and he kindly helped younger scouts). Also, big mistake from first-time counselor: do not give them the WiFi password at the beginning of the session! 🙂 Ask them to pre-install Python (if they bring their Windows laptop) and only allow them on internet when coding … You’ll thank me later 😉
I went through Safety, History of programming and Programming today in about 1 hour and 20 minutes, which was a bit too long (despite the good interaction and participation).
Then I programmed with them a converter between degree Fahrenheit to degree Celsius. Typing with them and running the script line by line was a good way for them to understand basic programming concepts like variables, case-sensitivity, functions and branching. The files we used as examples and code are on GitHub. From no knowledge of Python to this temperature converter: about 1 hour.
Finally, I covered Intellectual Property and Career in 10-15 minutes. That’s a little bit short. We had no time to enter into too many details. But scouts will have the additional pointers at the end of the slides and this will be a good introduction already.
Final thought? It’s time consuming to prepare all this material (and I thank the other counselors who shared their material!) but it’s also very rewarding to see children (well, teens) discover programming! I encourage you to share things you like as Scout Counselor!
DISO1 – Data I Sit On, episode 1. This post is the first of a series of a few exploring data I collected in the past and that I found interesting to look at again … (I already posted about data I collected, see the Quantified Self tag on this blog)
Life is short and full of different experiences. One of the experiences I don’t specifically enjoy but is integral part of life is commuting. Although I tried to minimize commuting (mainly by choosing home close to the office) and benefit(ed) from good work conditions (flexible working hours, home working, etc.), a big change occurred when I took a new opportunity, in 2015, to work in the Belgian capital, Brussels.
From where I lived at that time, using public transportation was not a viable option, unfortunately: it implied roughly 2 hours to go one way and changing at least 2 times between bus, train and metro. Anyway Belgium is know for having lots of cars and I benefited from a company car. Since some time, I’m also interested in Quantitative Self so I started collecting data about my daily commute.
What I try to see is the seasonality of commuting (I would initially expect shorter commute time during school breaks), the differences between leaving for work after driving children to school or without driving them, … There is also an extensive literature on the impact of commuting on the quality of life …
So, how did I do that?
The route usually taken, between my home then (in Wavre) and my office then (in Brussels, both in Belgium), is 28km long and the fastest I ever saw on Google maps to drive this distance is about 20-25 minutes.
I took note of the following elements in whatever default note-taking app is there in my phone at that moment (Keep on Android, Notes on iOS). The first field in each row is the date in a %y%m%d format, i.e. year, month and day of month as zero-padded decimal numbers, 2 digits only for each. The second field is the start time in a %H%M format, i.e. hours (24-hour clock) and minutes also as zero-padded decimal numbers, 2 digits only for each. Start time is defined when I enter my car at home, in the morning. The third field is the arrival time (same format as start time), defined as when I stop the engine at work. The fourth and fifth fields are start and arrival times when I go back home, defined and formatted the same way, mutatis mutandis. Any missed start/arrival times is marked as “na” or “NA”. It corresponds, for instance, at times when I leave the office but I stop to meet a client (or more prosaically, to do grocery shopping) before coming back home. I may have missed one or two whole days at max. The data is on Github.
On a daily basis, the little game is to try to figure out which lane is the fastest, if there is a pattern in the journey that makes it faster (I think there is). However, there are so many little things to track in this game that I did not track these small differences. The journey is assumed to take more or less the same route.
At the end, the complete log is saved on my computer and analysed in R (version 3.3.2). The typical measures I’m interested in are departure/arrival times over time, commute duration over time, commute duration per month or per day of the week or per season, … for both the morning and afternoon journeys if applicable. Some funny measures should be the earliest I left for work, the latest I arrived at work, the earliest I left work, the latest I left work, the shortest journey ever (to compare to Google estimate) and the longest journey ever …
An unintended measure here is the amount of time actually spent in the office (on a side note, this is different than productivity – but I didn’t find any unambiguous or flawless measure of productivity so far …). Some interesting variations could be to see the average and median duration of my work days, the shortest day or longest day I had, … (I don’t know if my former employer would be happy or angry to see these results 😉 but note this doesn’t take into account the numerous times I worked from home, even in evenings after having worked the whole day in the office …).
In theory, the fastest I could go is at an average 84km/h (28km in 20 minutes, according to Google Maps, so this is according to traffic, not maximum speed limits). In practice, this is a whole different story …
In a bit more than a year of collected data:
the earliest I left home was 6.11 and the latest 10.11;
consequently, the earlier I arrived at work was 6.32 and the latest 10.36;
the shortest trip to work was 18 minutes and the longest one was 160 minutes (it was on March, 22, 2016, the day of Brussels airport bombing because the office is close to the airport – I still remember);
the earliest I left work was 12.34 (I assume half-day of holidays) and the latest 21.24 (I assume lots of work then);
consequently, the earlier I arrived back home was 12.59 and the latest 21.43;
the shortest trip back home was 7 minutes (there should be some input error here!!!) and the longest trip was 128 minutes (nothing surprising, here, with Brussels traffic jams).
Finally, the shortest stay in office was 242 minutes (4 hours and 2 minutes) – it was that half-day of holidays. And the longest stay in office was 754 minutes (12 hours and 34 minutes).
As always, these things are nice when rendered as graphs …
A first note it that none of these graphs show any seasonality in the data. At first, I thought I would go faster during school holidays – but it was more a feeling than anything else, as the data show. And although the time at work varied widely over time, the average time spent at work seems to be pretty constant over the year, I was surprised by this:
Finally, the time spent in car depending on the departure time is interesting:
Going to work was clearly split into 2 periods: leaving home (“Start Time”) before 8.30 and after 8.30. That’s because either I went early (and avoided the morning rush hour) or I drove the kids to school and drove to work at the end of rush hour. But although I tried to minimize the journey, the journey after driving the kids to school was still taking more time.
For the evening, going home became a shorter trip if I was able to delay it. And the later I come back, the shorter the trip. (However, if I didn’t drive the kids to school in the morning, the deal is that I would pick them up in the afternoon – fortunately, afterschool care is cheap in Belgium).
All this to come to the quality of life … I didn’t measure anything related to quality of life. I just remember that the first few weeks were very tiring. However, this commuting factor should be added to other tiring factors: learning a new job, adjusting to a new environment, etc. But there is a body of scientific work looking at the quality of life of commuting (I really like this paper as a starter [1], probably because it was published during that period): fatigue, stress, reduced sleep time, heart disease, absenteeism, BMI (weight), … are all linked – in a way – to commuting (either driving or just sitting in public transport).
[1] Künn‐Nelen, A. (2016) Does Commuting Affect Health?Health Econ., 25: 984–1004. doi: 10.1002/hec.3199
And a last point: privacy. This data is from 2015-2016. People who know me (even former colleagues!) know where I worked. And even without knowing me, you know when I leave home, when I leave the office, my pattern of organization, etc. Do I want that? Part of the answer is that I only post this data now, 2-3 years later. On the other hand, here is another free, small dataset!
Next steps? I’m continuing to track my journeys to work, even now we moved to the USA. For privacy reasons, I will not publish those data immediately. But it will be interesting, later, to compare the different patterns and try to understand at least some differences … It would also be interesting to give more time to this small experiment and, for instance, try to capture any impact on mood, productivity, … But this would become a whole different story!
After abandoning my Fitbit device in January because using it didn’t see improvement in my weight (see previous post), I was wondering if I could still measure my risk to develop cardiovascular diseases and other preventable chronic diseases (diabetes e.g.). So, still sitting at my desk (something I do for more than 8 hours a day in theory – probably more in practice), I looked into the ways to monitor my risk for these diseases …
I’ve been using several Fitbit devices since a few years and I decided to stop using them in 2017. My feeling (like many people experienced before) is that wearable devices don’t work. Yes, you’ve read correctly: I was a big supporter of wearables, following the adage “what you can’t measure you can’t manage”, but not anymore.
I wish you all a very happy new year 2017. This time of the year is when you usually do new resolutions. And, among others, I resolved to post more often new ideas and thoughts on at least one broad topics: quantified self.
As I moved to a new office, I met new colleagues and one of them brought her own coffee machine and placed it on her desk. It’s a bright red Nespresso machine, a kind of statement that the owner doesn’t drink the free coffee offered in kitchenettes on all floors:
Given that the company has a professional Nespresso machine downstairs (i.e. similar quality of coffee but with capsules of different shapes), I was wondering if this is really worth buying. The calculation is simple …
On one hand, the “public” Nespresso machine sells 1 capsule at 0.50€ and pours the water (through the capsule) in a cardboard cup.
On the other hand, the cheapest personal Nespresso machine you can buy in Belgium costs 199.00€. The cheapest personal Nespresso capsule you can buy costs 0.35€ (let’s forget for a moment you have to buy them in multiple of 10 and there are savings to be made if you buy large quantities).
Therefore the upfront cost of the personal Nespresso machine tells me it’s more expensive to have my own machine on my desk. But after how many capsules (i.e. cups of coffee) does it become cheaper to have my machine? The equation is easy: 199.00 + 0.35 * x = 0.5 * x (where x is the number of cups of coffee). Solving it tells me I need to consume 1,327 capsules from my machine in order to get my coffee cheaper than on the “public” machine. That is more than 3.6 years if I drink 1 coffee per day – only slightly less than a year if I drink 4 coffees per day (which is a lot).
Of course, this simple calculation doesn’t take into account electricity, water, cleaning cups or the cups themselves ; they are considered free in both situations (which they are, in practice). It doesn’t take into account neither the convenience of not having to stand up, go down a few stairs to the “public” machine. But, for the future, it doesn’t take into account neither the benefit of having moved more during office hours (more than just sitting the whole day).
So, given some assumptions, having my own Nespresso machine on my desk is probably not economically viable at a reasonable time horizon, unless I drink a lot of coffee and if I value the convenience of not losing a few minutes to go down to the “public” machine. But going downstairs for a coffee prevent me from sitting for too long at my desk and it allows me to meet other colleagues downstairs. I’ll keep this habit! 😉
Mid last year, Gartner mentioned “medical applications [of 3D printing] will have the biggest impact in the next two to five years“. With 3D printing you can already create a lot of physical artifacts and medical applications go from building medical equipments to prosthetic parts, but also blood vessels, bone, heart valve, cartilage, etc. Complete organs are not too far, with companies like Organovo already printing functional liver assays, prospects to restore a body by replacing or consolidating personalized parts seem interesting.
On the other side, restoring a body function by providing personalized molecules was a dream so far. Preventing body malfunction via similar systems is too.
I recently watched and read about Lee Cronin’s laboratory work and these dreams may come true, one of these days. In a TEDxGateway video in 2013, Prof. Cronin explained briefly how he did it. Last December, they published their method with a basic application in Nature Communications. What I also liked is that, beyond the technical capabilities, this research is based on common components (right) and free software that are available for everyone. And Cronin also insisted on compatibility between “recipes” and the possibilities to exchange them as well as source code – one day, will their software be released on Github like some of their 3D models as STL files?
Cronin also talks about pharmaceutical companies releasing blueprints for drugs that could save plenty of lives in emerging economies, for instance. In my opinion, this is however where the technology goes much faster than the ideological framework we live in: pharma companies will not likely suddenly release recipes for drugs that bring them money (no for-profit company in any other sector would, by the way) and the regulatory framework for healthcare is far from ready to accommodate these advances.
Prevention could also benefit from these advances. Synthetic vaccines are in production since two decades at least. If safety is the first argument often put forward in their favor, rapid prototyping and versatile production could one day become possible. It seems it was already tested for flu vaccines. Now imagine to move the “engineering” part in a computer, sending the recipe for the best-adapted vaccine directly to “vaccine printers” in regions where health hazards are likely to occur or as early as they occur … We would also face many corporate and regulatory hurdles. But it wouldn’t be the first field where technology would push broader changes …
With more than 2,400€ collected, our team – Bordet’s angels – can be proud, for a first participation! We are 12th of more than 100 Belgian teams. One key learning is that the gold, old paper display still works better than anything else to raise money.
And it was fun for me, a bit itchy in the end. But with the right trimming tools, this goes away very quickly. Thanks for all my supporters 😉 – your support is worth a thousand thank-you!
Jean-Etienne's blog 