Francesco Allertsen - Issue #80

In the past week, I have been looking more in-depth into the CPython implementation and its bytecode, and I have been very surprised that it’s not performing almost any optimization on the code.

This article is showing exactly this behavior with some trivial examples, and comparing the bytecode compiler of Python, Lua, and Emacs Lisp. All of them don’t do much optimization on the code, and apparently, for CPython, this is a decision they made “by design”.

This means that if you care at all about performance in Python, you need to be very careful about what code you write and how it’s going to be translated into bytecode. To translate this, it means that if you write a more readable (by humans) code, it’s probably going to be slower.

This is the very opposite of what I was used in C, where the compiler tries to optimize as much as possible your code, so even if you write very human-readable code with multiple variables and expressiveness, the compiler will automatically optimize it, while here it’s the exact opposite.

This is a very interesting project just released by Google. As developers, we often use an external library in our project to speed up our development time and to not always reinvent the wheel. But many developers don’t realize that the decision we make to use an external library we don’t know is that we don’t know if there is any malicious code hidden somewhere in the library or some security problems that we don’t know. Sometimes we have the source code of the library that we can inspect, but sometimes the libraries are commercial libraries that we can not even inspect and we just need to trust.

In a large company like Google, this is, of course, a huge liability, and the security team inside Google have been working on finding a solution to the problem. This open source project is their solution to the problem.

This is essentially a sandbox for C/C++ libraries, where you can specify different security policies for the library and the sandbox will ensure that those policies are enforced to the library.

I think more project should have security in mind, and hopefully more similar sandbox will come for also other programming languages because it’s going to become more and more important in the future.

The title sounds like a sensational title, especially in 2019, but this is actually true, and a very important example of things not to do in 2019!

You can read the article and the press release by Facebook, but essentially the problem was that in some system the password was logged in plain text, and the logs were searchable and available to most of the Facebook employees.

This is a very common problem in every company, most of the people don’t treat logs as potentially dangerous for security, although you can probably find a lot of security and privacy issues just looking through the logs of a company. It’s something that most of the developers don’t care too much about it, but hopefully, this is something that’s going to change in the future.

This is an article that gives me a lot of anxiety as a developer. Luckily I’m not a frontend developer, and I don’t need to deal with this kind of things.

Essentially what this article is about is that Google decided to drop a DOM API in the Google Chrome browser, and if you were using that API you were simply out of luck, and your web application would stop working.

This is something quite scary, and I don’t know if I like Google (or any single company) to have such control power over the web development, which is probably one of the most important parts for many companies. This is something that can not be fixed in a simple way or only in a few days, but in the future, this is a discussion that’s going to happen more and more often, and it looks like all the other parts of software development are less affected, it’s mostly for web development.