This is a story about trying to accomplish two unrelated things with one solution: making your child bilingual and avoiding having to fight every day about screen time. As you might know TV is highly addictive with young children and there’s some guesses that it hinders some aspects in early development, but more importantly it disconnects you from each other at an age where you’re establishing what type of relationship you might have, or at least what the default might be. Regardless of what those long-term studies conclude, not having to fight a tablet for a bit of quality time with my daughter seemed like a desirable thing.

Bilingualism was important to me for a few reasons. That’s what I grew up with and personally feel it’s often given me a huge advantage in life, both professionally but even more so on a personal level. Being able to read and comprehend natively in more than one language opens up entire new worlds for you to absorbe, learn from and enjoy. It also gives you access to form deep relationships with millions (or billions, depending on the language mix) of other human beings which would otherwise be much more challenging with a language barrier. It’s hard to overstate just how massive of an advantage it is, from personal experience. There’s also dozens of long term studies that link being bilingual with all sorts of great things ranging from strengthening cognitive abilities, increased creativity, better at multi-tasking and reducing the risks and effects of Dementia and Alzheimer’s.
I have so many great friends spread out all over the world in a big part because I could communicate with them at a comfortable level to form a deeper relationship, it feels almost unfair

So, it felt important and it felt like something that was basically free to acquire in an early age with the right set of conditions, and increasingly hard as time went by.
However, the conditions that led me to be bilingual, which were essentially growing up in foreign countries where I did not speak the local language and attended an international schools was not available to my daughter when she was born, and we weren’t keen on moving somewhere far away to enable this specific advantage.

But how does limiting screen time without making it a daily battle and being bilingual intersect you ask, 3 paragraphs in?
Well, when I was kid growing up in communist Poland, TV was not always fun. Often there would just be some really old cartoons in Polish that I could not understand, and I remember sort of watching it but mostly trying to figure out what else to do that would be more entertaining and switching to that as soon as something came up. In contrast, I remember whenever I could watch something that I understood well, and how my brain just lit up and would fight anyone to the death (and often tried) that would pry it away from me.
So here was my thought: what if any screen time my daughter had was boring enough that it would shave off most of the addictive aspect of it, and would still give her something good in return other than entertainment?

I think you see where I’m going with this

That’s how the “mostly unlimited screen time, but only in English” rule came to be. It was a gamble. It took some scary turns for a while as I learned first hand how incredibly damaging and evil YouTube is with little kids, there was some course correction to start to slowly reduce and drop screen time as she got closer bedtime.
As the years went by, one of the two goals had been pretty clearly accomplished: there was little or no fighting about screen time with our daughter, and she would often go days without watching anything. She also seemed to like to spend a lot less time than many other kids glued to TVs and tablets. But more importantly, I was not having to fight about it all the time, which I absolutely dreaded having to do.
This, I feel and felt early on, was a huge success.

The Bilingualism took some more time, though. There were signs here and there that English was easy for her to pick up, she would sometimes surprise you by understanding something she overheard, but there were lots of doubts about whether it had any meaningful impact on her or not. We sometimes read her books in English, but bedtime stories are such an intimate moment that things sort of kept on gravitating back to Spanish on their own.
However, in what felt out of the blue, one day she could just understand everything. She could also have conversations with a lot of confidence, even if it required spanglishing in there a word or three. This is about around age 5. I don’t know if it was the right age of maturity, or whether it was the change in school where there was a stronger focus on English and she made a friend that could only really speak English, but once she surfaced it, it all unravelled pretty quickly.
Friends and family that would often switch to English to say certain things that kids weren’t supposed to understand suddenly found that my daughter would understand them perfectly. She understood the plots of the cartoons and movies she would watch. You could read her books and she’d understand and enjoy them. It felt like a pretty big change overnight.
Now, for me personally, being bilingual has one particularly interesting aspect: some thought process are in one language, some are in others. I suspect that’s one of the reasons it has some cognitive advantages. So what made it seem like the second goal had been a real and lasting success was that I noticed that most of the time when she was playing on her own, it’s all in English. Her toys talk to each other in English, they fight with each other in English and they go on adventures in English.
I feel that’s a pretty big sign there’s internal thought processes happening in a second language.
It also made me realize how much of what kids watch on a screen actually influences how they play. If she spends a few days going to someone else’s house where they watch TV in Spanish, often her toys would switch languages for a little while before going back.

So, all in all I would say this has been a huge success that I’m very proud of and felt it was worth writing about and sharing. I learned a lot about the intersection of screen time and languages which I would not have guessed, at least in my very specific anecdotal experiment.
I also have to say that my inspiration for trying out long-term things like this came from the wonderful Francis Lacoste, who taught his baby sign language without neither of them being deaf and had such an amazing story out of it that he wrote a book about it.

Now, some smart readers will be thinking: there’s a problem with where this is heading. I know, I know. As her comprehension of the second language starts to equate her first language, screen time will be as attractive as if we hadn’t done any of this. I’ve already seen hints of this. She’s more often binging on specific cartoons, and she’ll sometimes prioritize watching TV over other things which wasn’t the case before.
I don’t have a plan for this next phase yet. Maybe the fact that screen time wasn’t such a major thing in her first 6 years will make it a bit less addictive?
We’ll see where this takes us, maybe I’ll think of a new hack soon enough.

After some blood, sweat and tears, we finally brought Stacksmith into the world, yay!

It’s been a lengthy and intense process that started with putting together a team to be able to build the product in the first place, and taking Bitnami’s experience and some existing tooling to make the cloud more accessible to everyone. It’s been a good week.

However, I learnt something I didn’t quite grasp before: if you find really good people, focus on the right things, scope projects to an achievable goal and execute well, releases lack a certain explosion of emotions that are associated with big milestones. Compounded with the fact that the team that built the product are all working remotely, launch day was pretty much uneventful.
I’m very proud of what we’ve built, we did it with a lot of care and attention, we agonized over trade-offs during the development process, we did load testing to do some capacity planning, added metrics to get hints as to when the user experience would start to suffer, we did CI/CD from day one so deployments were well guarded against breaking changes and did not affect the user experience. We did enough but not too much. We rallied the whole company a few weeks before release to try and break the service, asked people who hadn’t used it before to go through the whole process and document each step, tried doing new and unexpected things with the product. The website was updated! The marketing messaging and material were discussed and tested, analysts were briefed, email campaigns were set up. All the basic checklists were completed. It’s uncommon to be able to align all the teams, timelines and incentives.
What I learned this week is that if you do, releases are naturally boring 

I’m not quite sure what to do with that, there’s a sense of pride when rationalizing it, but I can’t help but feel that it’s a bit unfair that if you do things well enough the intrinsic reward seems to diminish.

I guess what I’m saying is, good job, Bitnami team!

I’m a stone’s throw away from reaching my 1 year anniversary at Bitnami, so it feels like a good time to pause a bit and look back.

After 8 years working at Canonical on a wide range of projects and roles, it was a very difficult step to take and was riddled with uncertainty and anxiety about leaving behind so many things I had poured my heart and soul into for so many years behind, and more than anything else a once-in-a-life-time epic team of people to work with.

A year in, I’m overwhelmingly happy I made that decision.

A lot of people expressed surprise I was joining Bitnami as either they hadn’t heard about them at all or they had but thought of them as a company that “made some installers or something”. However, Bitnami had been quietly but consistently growing in size, scope and revenue, all fueled by being organically profitable which is very rare nowadays in the tech world.

Fast forward a year later Bitnami is starting to move out of the shadows and some of what’s been cooking for a while is getting some well deserved time in the spotlight.

Of the things that are public, I would say they fall into two buckets: Kubernetes & Packaging open source applications.

Kubernetes

The Kubernetes community has been growing at a healthy and inclusive pace for some time now, some would say it’s the hippest place to be right now.

One of things that was attractive to me when changing jobs was the possibility of being able to use some new and interesting technologies more hands-on as part of my day-to-day job, and K8s was at the very top of my list. Shortly after I joined we made a company decision to go all-in on K8s and began setting up our own clusters and migrating over our internal services to it. Aside from the amount of buzz and customer requests we had, once we started using it more hands on it became obvious to us it would win over hearts and minds fairly quickly and we doubled down on being all-in  

Aside from all the knowledge we gained by setting up, maintaining and upgrading our internal clusters, Bitnami acquired a small but very relevant start-up called Skippbox which brought over further expertise in training, but even more interesting was a project called Kubeless.

Kubeless is a functions-as-a-service framework which has the advantage of having been built on top of K8s native objects, making it very easy to extend and interact with anything inside your cluster. That project has been a lot of fun to play with is a natural addition to our internal clusters to fulfill our stated goal of making it easy and enjoyable for our own development team to get deliver software to production.

It was a busy year, have I said it’s been a busy year? So, as well as all of that along came the Helm project. Once we heard “a packaging format for applications on K8s” we knew someone’s current iteration would be derailed  

We jumped in with Deis and helped get the project off the ground by applying our knowledge of how to package software to Helm and quickly produced the majority of the charts that the project launched with. It’s been getting a healthy string of contributions since then, which is as good as you can hope for.

Because humans are visual creatures, no matter how technical, on the heels of the launch of Helm we took the lead on a new project code-named “Monocular”, which is a web-ui to search and navigate existing Helm charts and even deploy them to your cluster with one click. An app store of sorts for K8s applications.

With all that K8s experience in our toolbelts, we started to realise there was a gap in how to consistently deploy applications across clusters. Why across clusters, you say? A very common pattern is to have at least a staging and a production environment, which in K8s you would likely want to model as different clusters. We happen to internal also provide a development cluster as we do so much development in the K8s and often need to test in larger machines or use some specific features that minikube doesn’t satisfy. The way to do that in Helm is essentially to copy and paste your yaml files, which for a small amount of clusters or apps is fine. For us, this quickly grew out of control and realised that we needed to instrument some amount of re-usability and flexibility when trying to use K8s features that Helm itself hadn’t exposed yet. It turned out, we weren’t alone. Our friends over at hept.io and box.com had similar problems and were in fact trying to address it in a similar way (given there were a few ex-googlers in our ranks, jsonnet was picked as the library to help with re-usability), and as such ksonnet was born. You can take  a look at it more closely if you’re interested, but in essence it takes json & jsonnet templates and compiles them down to native K8s yaml files that you can track and feed directly into your cluster.

Packaging open source applications

This is what is probably the most underrated aspect of Bitnami, as it’s probably not very obvious the scale at which we operate and there’s nobody else really to compare the company to.

Let me try and give you some hints at the scale at which we operate. At this exact point in time, you can find Bitnami-built assets as:

• Windows, Linux and macOS installers
• Amazon EC2 VMs
• Azure VMs
• Google Cloud VMs
• Oracle Cloud VMs
• Virtual Machines (OVA’s)
• Huawei Cloud VMs
• Deutsche Telekom VMs
• 1&1 VMs
• GoDaddy VMs
• Centurylink VMs
• Docker containers
• Eclipse Che containers
• Docker-compose templates
• Amazon Cloudformation templates
• Azure ARM templates
• Google deployment templates
• Kubernetes Helm charts
• ...and more on its way  

That is 20 different target environments! Even if you just built one applications for all those targets it would be an interesting problem in itself. However, there’s more  

Bitnami has a catalog of about 170+ open source applications of which we don’t always provide the full catalog to every environment as it doesn’t always make sense (not everything makes sense as a Docker container or a multi-tier application), and while I haven’t looked at the exact numbers it would likely average out over all targets at around ~110 apps. That is 110 x 20 = 2,200 assets to build. That on its own should feel daunting for anyone who’s tried to build an application for more than one environment. But wait, there’s more!
Bitnami’s missions is to make it easy for everyone to use open source software, and to try and reach more of “everyone” you need to support major versions of these applications (because not everyone has migrated to Python 3 yet :), so that ends up with around 4,400 assets. Mind. Blown. But you know how it goes, there’s always more!

Building these images and templates is an interesting and hard problem, but the hardcore last-level boss problem is in doing so in a way where you can keep building those continuously so they are actually up-to-date all the time. In order to do that you have to track a lot of software (eg., libssl, libc, openssh, php, java, rails, etc) packaged in different ways (ie., debs, rpms, gems, pip, etc), so you end up watching thousands of different pieces of software over all, some of which can affect every single image (hello openssl & heartbleed!).
To solve this problem there’s over a decade of code that’s been brewing, carefully structured metadata about how applications like to be configured in different scenarios, regression tests, tracking upstream releases and watching and matching CVEs. Over the last year there’s been a tight focus on taking all that work to streamline the tools to plan for continued growth as the landscape of software expands, and some refactoring to be able to shape it into a product that might be useful to others beyond our internal use.

Daunting problems end up being the most fun to work on and this has been no exception. This is why I joined Bitnami, to lead this effort and make open source software a bit easier to use and access every day.

Every Python programmer knows to avoid mutable default arguments:

def fn(mutable=[]):
    mutable.append('elem')
    print mutable

fn()
fn()

$ python test.py
['elem']
['elem', 'elem']

However, many are not clear that this is due to arguments being evaluated at import time, rather than the first time the function is evaluated.

This results in related quirks such as:

def never_called(error=1/0):
    pass

$ python test.py
Traceback (most recent call last):
  File "test.py", line 1, in <module>
ZeroDivisionError: integer division or modulo by zero

... and an—implementation-specific—quirk caused by naive constant folding:

def never_called():
    99999999 ** 9999999

$ python test.py
[hangs]

I suspect that this can be used as denial-of-service vector.

0m6 you’ve been h4ck3d!!1one!shift!!!1 đŸ’Š

About rel=noopener

What problems does it solve?

You’re currently viewing index.html.

Imagine the following is user-generated content on your website:

Clicking the above link opens malicious.html in a new tab (using target=_blank). By itself, that’s not very exciting.

However, the malicious.html document in this new tab has a window.opener which points to the window of the HTML document you’re viewing right now, i.e. index.html.

This means that once the user clicks the link, malicious.html has full control over this document’s window object!

Note that this also works when index.html and malicious.html are on different origins — window.opener.location is accessible across origins! (Things like window.opener.document are subject to CORS though.) Here’s an example with a cross-origin link:

In this proof of concept, malicious.html replaces the tab containing index.html with index.html#hax, which displays a hidden message. This is a relatively harmless example, but instead it could’ve redirected to a phishing page, designed to look like the real index.html, asking for login credentials. The user likely wouldn’t notice this, because the focus is on the malicious page in the new window while the redirect happens in the background. This attack could be made even more subtle by adding a delay before redirecting to the phishing page in the background (see tab nabbing).

TL;DR If window.opener is set, a page can trigger a navigation in the opener regardless of security origin.

Recommendations

To prevent pages from abusing window.opener, use rel=noopener. This ensures window.opener is null in Chrome 49 and Opera 36.

For older browsers, you could use rel=noreferrer which also disables the Referer HTTP header, or the following JavaScript work-around which potentially triggers the popup blocker:

var otherWindow = window.open();
otherWindow.opener = null;
otherWindow.location = url;

Don’t use target=_blank (or any other target that opens a new navigation context), especially for links in user-generated content, unless you have a good reason to.

Bug tickets to follow

• Gecko/Firefox bug #1222516
• WebKit/Safari bug #155166
• Microsoft Edge feature request
• Chromium/Chrome/Opera bug #168988 fixed

Questions? Feedback? Tweet @mathias.