In the afternoon I noticed that the Aphonopelma seemanni I keep was
out in the open, on top of the piece of cork underneath which she has
her burrow. I discovered that this large tarantula is a female the
28th of June,
2020 by inspecting her
exuviae (molt).
In the above photo you can clearly see the beautiful pattern on her
legs; I love the contrast it makes.
After I took the above photo I gave her two mealworms.
A question I often hear from teams - both new and established - is
“should we host our stack on
Kubernetes?”. Given all the buzz it gets
in the tech world a lot of people assume so.
I’ve been working with k8s for several years - often with very
powerful and complex platforms - and I think the truth is more
nuanced.
Here’s my attempt at untangling that decision. It’s geared toward
startups and self-sufficient teams in wider organisations with
responsibility for hosting their own products. It might also have
value to people in more traditional IT departments at larger
organisations.
In this tutorial, I will teach you how to write your own virtual
machine (VM) that can run assembly language programs, such as my
friend's 2048 or my
Roguelike. If you know
how to program, but would like to gain a deeper understanding of
what is going on inside a computer and better understand how
programming languages work, then this project is for you. Writing
your own VM may sound a little scary, but I promise that you will
find it to be surprisingly simple and enlightening.
A common perspective is that types are restrictions. Static types
restrict the set of values a variable may contain, capturing some
subset of the space of “all possible values.” Under this worldview,
a typechecker is sort of like an oracle, predicting which values
will end up where when the program runs and making sure they satisfy
the constraints the programmer wrote down in the type
annotations. Of course, the typechecker can’t really predict the
future, so when the typechecker gets it wrong—it can’t “figure out”
what a value will be—static types can feel like self-inflicted
shackles.
But that is not the only perspective. There is another way—a way
that puts you, the programmer, back in the driver’s seat. You make
the rules, you call the shots, you set the objectives. You need not
be limited any longer by what the designers of your programming
language decided the typechecker can and cannot prove. You do not
serve the typechecker; the typechecker serves you.
When I was learning about Continuum Mechanics for the first time,
the covariance and contravariance of vectors confused the hell out
of me. The concepts gain meaning in the context of Riemannian
Geometry, but it was surprising to find that one doesn’t need to
learn an entire subject to grasp the logic behind
co-/contravariance. An intermediate knowledge of linear algebra is
enough—that is, one has to be acquainted with the concept of vector
spaces and one-forms.
The duality of co-/contravariance arises when one has to define
vectors in terms of a non-orthonormal basis. The reason such
terminology doesn’t show up in engineering education is that
Cartesian coordinates are enough for most engineering problems. But
every now and then, a complex problem with funky geometrical
requirements show up, like one that requires measuring distances and
areas on non-flat surfaces. Then you end up with dual vector
spaces. I’ll try to give the basics of duality below.
Before Unicode, each script (or script family) had its own encoding,
or worse, lots of different incompatible encodings. Unicode is a
superset of almost all of them, so can be used for interchange.
HTML5 is not a new thing. We have been using several features of it
since the initial release(January
2008). As part of
#100DaysOfCode initiative, I have taken a close look to the HTML5
feature list again. See what I found? I haven't really used a bunch
of it so far!
In this article, I am listing down ten such HTML5 features that I
haven't used much in past but, found them useful now.
In the afternoon I discovered that the Hapalopus sp. Colombia
"large" I've kept since the 7th of April,
2020 had passed away. It
had molted recenly and looked
fine.
Earlier this week, the 10th, the little scorpion I kept,
Chaerilus sp. Java, also passed away. I also had this little one
since the 7th of April. As it was quite round I guess it
got stuck while attempting to molt. Or maybe the high temperatures in
the room; more than 30°C (86°F), were too much for the two of them.
So that leaves me with 9 tarantulas and zero scorpions. I am going to
move the 9 to a cooler place in the house, our bedroom, just to be sure.
I’ve been a big fan of Nassim Taleb’s Incerto. He wrote a series of
essays on life, where all the topics revolve around decision making
under uncertainty. I wanted to dig deeper on some of the more
technical concepts he alluded too, so last year I explored a few
textbooks on probability theory.
I was surprised with how elegant the field was. The most inspiring
idea to me was how the originators interpreted probability through
set theory. Not only is it a beautiful way to look at things, but by
seeing it this way, they could apply few axioms, leverage set
theory, and badabing badaboom they had a whole field’s worth of
discoveries.
In the afternoon I noticed that the Chromatopelma cyaneopubescens I
keep had molted. The common name for this tarantula is Green Bottle
Blue, GBB for short, after the colors the adults have.
The previous time this spider molted in my care was the
19th of June,
2020.
Much like the DMV, the PostgreSQL query planner is a powerful,
mysterious entity to whom we semi-blindly entrust our well-being. It
has the crucial responsibility of picking the most efficient
execution plan for every query. Here we’ll explore what data
Postgres takes into account when creating query plans, and how we
used that context to help the query planner come up with more
efficient plans for some of our most important query patterns.
I got into a discussion about monads recently. On a search to find
some resources to share, I realized that most essays explained them
with type signatures and rules. A missing ingredient to grok them, I
think, is to understand the intuition behind them. How could you end
up inventing monads?
As Python programmers, we write scripts. Many times they are quick
and dirty; never meant to be seen by others or even yourself after
accomplishing it’s task. However, in some cases the script is meant
to live on, perhaps being modified and shared regularly. It’s in
this case that we often want to create a GUI for the script. There
are a few options for Python which include Tkinter, PyQT/PySide,
wxPython, Kivy, PySimpleGui, and so on. These are all great
libraries which serve their respective purposes, but in a lot of
cases they can be overkill, requiring just as much code and thought
as the script it’s meant to wrap. This is where DearPyGui shines. So
to start, you need to get DearPyGui…
WebAssembly (wasm) allows code written in languages other than
JavaScript to run on browsers. If you haven’t been paying attention,
all the major browsers support wasm and globally more than 90% of
users have browsers that can run
wasm.
Since Rust compiles to wasm, is it possible to build SPAs (Single
Page Applications) purely in Rust and without writing a single line
of JavaScript? The short answer is YES!
On my quest towards building a GoLang Desktop application I found
some useful frameworks, Lorca and
Webview (which I wrote about
in my previous
post). These
frameworks create a window which GoLang can inject HTML, CSS, and
JavaScript to build the UI.
But I don’t want to write JavaScript(!) and deal with all the
complexities that comes with it like npm, webpack, typescript…
Fortunately, I can just compile GoLang to
WebAssembly
(WASM) and use that in place of JavaScript. WASM is a binary format
that can be executed natively in most modern
browsers.
My friend Juan Paucar directed me to a paper from the magnificent
Programming Languages and Systems 28th European Symposium on
Programming, ESOP
2019, related to
Codata. I have been very interested in codata, mainly because it
relates to data in a category-theory way, but, as usual, I didn't
understand many of the words involved. This paper helped me
understand a lot, and also helped me understand and shape my mind on
how to connect the worlds of FP and OOP. But, before that, we must
go on tour over a bit of theory.
At work, I’ve recently been asked to advise our engineers on how to
write blog posts. A lot of such articles are already
available. However, they tend to focus around two main themes:
The technical publishing platform e.g. Jekyll, Medium, etc.
Metrics e.g. readability score, SEO, etc.
Beyond that, everyone is on one’s own. But I believe that writing a
good technical article is as much art as engineering.
In this post, I’d like to try to address this gap: I’ve been writing
this blog for more than a decade. I hope I’ve learned some things
along the way, so here are my advices.
I’ve been continuing to write pages about CSS! Here are 6 more.
Two of them are about how to think about CSS in general (“CSS isn’t
easy” and “backwards compatibility”), which is something I’m still
trying to wrap my head around.
However, cloud-native software architectures are different from
traditional architectures in a variety of ways. As a result,
migration of a system into a cloud-native environment is not as
simple as a rehosting migration. This post introduces a generic
process that provides a useful set of questions to ask when planning
a Kubernetes migration. The answers to the questions can then be
used to make informed choices about how to use the various
deployment options available within Kubernetes.