What I will blog about
Advice, recipes or strategies that could make your life a tiny bit more productive.
Target audience
Anyone using computers a lot
Blog posts
Maybe bitcoin is not going to the moon. Who knows wagmi ecetera.
This is a a curated list of blogs, videos, podcasts that are worth your
consideration if you're interested in crypto and you think I'm a credible source
to decide what is worth your consideration. I am going to continuously update
this post when I stumble on new material.
Pro-crypto list:
* Naval Ravikant and Chris Dixon on Tim Ferris show
[https://www.youtube.com/watch?v=DlNDYMNJ5zQ] (added 08/04/2022, Youtube)
Nay-crypto
read this post →Context: I'm currently working with a good friend and competent programmer who
hasn't written a lot of tests. this blog post is dedicated to you 🙂
Good tests should have the following attributes (among other things):
* readable
* break when the business logic being tested is broken (i.e. no false
positives)
* not break when the business logic being tested is not broken (i.e. no false
negatives)
Here are a couple of rules for writing good tests
Rule 1: Test the code, not the data
H
read this post →
I've noticed that developers and product managers alike are reluctant to write
high quality specifications. In this blog post I argue that high quality
specifications are still important and are not contradictory with an Agile way
of working. I'll first go into why agile is great and then speculate why we've
neglected the art of writing great specifications.
Every software starts with a vague idea of what it should do. Software
development is turning this vague idea into a very precise descri
read this post →
As a software engineer you are switching between production, Â staging and
development environments multiple times a day.
It's important to distinguish between these environments because you don't want
to accidentally delete a customer's account in your production environment
because you thought you were deleting things in your staging environment (when
in fact you were working in your production environment).
In web development – typically – the only way you can see the difference between
th
read this post →I recently had to fix a nasty bug in an Ionic application. It was painful.
As part of the trauma recovery process I decided to document the lessons learnt
fixing this bug.
Why was fixing the Ionic bug painful? Mainly because I've never worked with
Ionic before. When you're debugging in a tech stack you don't know you don't
know what's up or down and the ground on which you walk is constantly moving.
So here are some hard lessons I had to learn along the way. Hopefully you'll
learn them by rea
read this post →Well-written tickets are mana from heaven. Programmers love them because it
means that most of the work is already done. The hard part is over. They get to
ride through the gates of Rome in triumph (aka. coding-up well written specs).
Here is a non-exhaustive bestiary of  ticket types
The new feature ticket
You want your product to do something new. You need:
* a good summary title
* a user story
* acceptance criteria
Let's go through these.
A good title will help everyone refer to the t
read this post →Sometimes a while loop is what you need. When you do use the while-loop please
document the condition/expression. Below is a decent-enough example of how you
can nicely document the condition/expression
/**
* @param n the number of matches we need
* @param matcher the function to determine if there is a match
* @param list the list to search in
*/
const getFirstN = n => matcher => list => {
const res = []
let i = 0
// first condition is to exit when we have enough matches
co
read this post →The first version of my code was:
function user_should_see_priority_items (user={}) {
// why double negative? we want the default to be that user can see priority items so if should_see_priority_items is not defined then it should see priority items
return user.should_see_priority_items !== false
}
I wrote a comment because I found the !== false confusing.
But after writing the comment I still found the code to be confusing. Then why
not remove the reason for the comm
read this post →Before:
// Get a list of user ids from foo company
const userData = await database.client.db('main').collection('users').find(
{ email: /@foo/ },
{
projection: {
id: true,
},
},
).toArray();
const usersJSON = userData.map(user => user.id);
After:
const get_ids_of_users_from_company_foo = async () => {
return await get_ids_of_users_with_given_email_regex(/@foo/)
async function get_ids_of_users_with_given_email_regex(email_regex) {
return (awa
read this post →I like the concept of preconditions
[https://www.google.com/search?q=eiffel+precondition&sxsrf=AOaemvJ0R7uRlezRiPQ78yOPt8FBoRkZ9Q%3A1638566229122&ei=VYmqYbbjBpb-sAfF8aigBg&oq=eiffel+prec&gs_lcp=Cgdnd3Mtd2l6EAMYADIECCMQJzoHCCMQsAMQJzoHCAAQRxCwAzoNCC4QyAMQsAMQQxCLAzoTCC4QyAMQsAMQQxCLAxCkAxCoAzoKCC4QxwEQrwEQQzoECAAQQzoECC4QQzoFCAAQgAQ6BQguEIAEOgsILhCABBDHARCvAToKCAAQgAQQhwIQFDoGCAAQFhAeSgUIPBIBMUoECEEYAFCOAljoB2DwC2gBcAJ4AIABkQGIAZoEkgEDMi4zmAEAoAEByAEPuAECwAEB&sclient=gws-wiz]
in the Eiffel progr
read this post →Ever had a long method that you needed to refactor?
How do you start on it?
group things into sections.
Example:
const runServer = () => {
server.get('/foo',Foo)
cronJob1()
server.use(mw1)
server.get('/foo',Foo)
cronJob2()
server.use(mw2)
server.get('/foo',Foo)
cronJob3()
}
const runServer = () => {
const instantiate_routes = () => {
server.get('/foo',Foo);
server.get('/foo',Foo);
server.get('/foo',Foo);
};
instantiate_routes();
const apply_midd
read this post →Reformulating definitions can help you  find a simple implementation. What do I
mean?
Let's illustrate with an example from probability. Given the chance of winning
the lottery is 0.1%, what is the chance of winning the lottery at least once if
I play 10 times?
There is a complicated way to calculate this probability or a simpler way if you
reformulate the question:
* The probability of winning at least once = 1 - the probability of never
winning
Calculating the probability of never wi
read this post →I'm exploring ways to bridge the documentation-to-code gap. see the before and
after. WDYT?
Note: I use Ramda.JS and a function merge (implementation at the end).
// before
are_all_products_of_order_in_stock({order_number}) {
/**
* 1) grab all product ids of order
* 2) query another system to fetch all stocks for each product
* 3) filter all products from 1) that are not in stock
* 4) return true if list of out of stock products is zero
* 5) return false if list o
read this post →I frequently encounter problems that can be simplified if the child data
structures would include properties belonging to the parent data structure.
what do I mean? Example time!
Let's say I a run an e-commerce store and I want to know for all products the
amount of ordered products of a given status. The status of an ordered product
item is determined by the status of the order. In the example below there are 8
ordered products Y with the "ready" status (4 in order A and 4 in order B):
cons
read this post →Declarative code stands in contrast with imperative code. With declarative code
you say what you want. With imperative code you say how you want it done.
The most well-known declarative language is SQL. (Almost) everything you write
in SQL is declarative code.
When you write "SELECT name FROM recipes" in a database you let the database do
all the heavy lifting. You just write what you want (i.e. the name of all
recipes) and not how you want it (e.g., go over row by row in the recipes table
an
read this post →Do you know that uneasy feeling when you're debugging and just trying stuff out
without a plan aka programming by accident?
use that uneasy feeling as a trigger to stop and make a plan. Debugging a bug is
often complicated and sometimes a large effort. Don't always aim to fix it in
one go. Make  intermediate goals that will help you solve the bug. Some ideas to
think about:
reduce your search area:
1. remove code without making the bug disappear
2. use git bisect (google for more info)
3.
read this post →Note: article for programmers
When dealing code that has side effects you need to consider the consequences of
running your code twice with similar input parameters (i.e. lets call these
quasi-idempotent [https://en.wikipedia.org/wiki/Idempotence] operations). I had
a piece of code where I did not consider the consequences and I had a resulting
bug.
Example illustrating the bug:
Take this piece of code with a side effect (e.g., updating database):
await ConfirmationRequest
.up
read this post →Note: Meant for programmers. Excuse me for the typos and verbosity. It was a
long day and I want to go to bed.
Bugs suck. But they don't have to.
They can be a trigger for self-reflection. If you do a proper post-mortem you
learn a lot from them.
For example, I discovered a bug in my code today. I had a section of code meant
to fetch the corresponding message (aka. outgoing_message in the code below) to
an incoming message from someone. The code in question was:
// BAD
// ...
const [ outgoi
read this post →
When reading Practice of programming by Brian W. Kernighan and Rob Pike I came
across this advice:
> As a rule, try to handle irregularities and exceptions and special cases in
data. Code is harder to get right so the control flow should be as simple and
regular as possible.
I came across a piece of code I could apply it today!
Instead of this:
required_days_list = []
# ...lots of code where we append stuff in the list...
# in a senario where no products in database has delay, we can't appl
read this post →Heads up: blog post for programmers
You should rarely use more than 1 positional function argument. I'm not the
first to say this. However it seems not everyone agrees.
I've been playing with smart contracts this week and encountered this piece of
code:
const gameContract = new ethers.Contract(
CONTRACT_ADDRESS,
myEpicGame.abi,
signer
);
This piece of code bothers me because you need to pass in 3 positional
arguments.
That means you need to remember the order in which you pass in the
read this post →1. The problem
You're starting on a new project and your first major obstacle is making the
damn thing run. 9 times out of 10 the README is outdated and you waste a full
day making it work on your machine. Finally you make it work and your brain is
flooded with dopamines. A great feeling similar to when you get released from a
bear's death grip and realise that you're going to make it out alive. Your
frustration at this point is so high that you don't even think of updating the
README for the n
read this post →This is a short illustration why using default values can improve your code
//version 1
const { pending_actions } = orchestration_pathway_reference
if (!Array.isArray(pending_actions) ||
(Array.isArray(pending_actions) && pending_actions.length === 0)
) {
return 'Nothing to report'
}
You can do
//version 2
const { pending_actions = [] } = orchestration_pathway_reference
if (pending_actions.length === 0) {
return 'Nothing to report'
}
What is wrong with version 1?
* the code
read this post →GraphQL is an amazing API query language. It allows you to expose your data to
the front-end as a graph. That's extremely powerful because graphs are amazing
at representing relationships between your domain entities.
However you need to be careful. Given how much GraphQL does for you, you might
not realise how expensive some queries can be.
Time for an example
Query {
todos {
title
assigned_to: {
first_name
}
}
}
A naive implementation of the query resolver:
/*
Assume 2
read this post →There is a new bank in town.
By depositing your money in this bank you will get: 1) reassurance your deposits won’t be devalued by inflation…
read this post →Practice is overrated. Since I was kid I was told to practice.
Play more piano, write more essays, play more tennis.
Although these tellers…
read this post →Invest now to do more tomorrow. Intro How do "geniuses" do it? These are people that are 10 times more creative or more productive than…
read this post →tldr The mouse thaught people how to use a PC. Now, everybody knows how to use a PC so now its time to focus on knowing how to use your PC…
read this post →TLDR; You need documentation in your code Code is meant for humans to read and incidentally for machines to execute. I've explained why in a…
read this post →This quote is from Harold Abelson and I am obsessed with it ( I made a poster out of it for our offices ). Surprisingly, not everyone agrees…
read this post →Context: I use my inbox as a: way to alert me todo list The problem My inbox gets full quickly if I don't clear it up every day
I like to…
read this post →Problem Today I refactored a React component that allows: selecting from a list of options create a new option if you can't find what you…
read this post →Policymakers and economists seem to have the implicit assumption inflation behaves linearly.
They think the central bank will print more and…
read this post →TLDR; easily wrap your functions to leverage await/async (go to the end of this page) Context Node uses an event-driven model. What does…
read this post →