picostitch
crafting (and) JavaScript

Tagged with #knowledgebase

HTML is getting more and more semantic it seems. I am seriously wondering what this means for building things like a blog, like this one here. It becomes more and more reasonable to write pure HTML, instead of markdown, doesn't it? Maybe I am just late and just learned about some HTML elements now. What a shame.

This is post #3 in the category "Browser Tools", focusing on understanding the loading times by charting them in a Waterfall chart. In part 1 and part 2 about Resource Timing I covered the attributes startTime, responseEnd, duration and initiatorType. Now I want to understand what happens after a resource starts loading and what do some attributes mean, like fetchStart, requestStart and responseStart, to mention the most relevant ones.

I never did android development, only the React Native side of things. Now while digging deeper, trying to figure out how to style a React Native picker on android (because the default is really ugly) I am reading into android docs. I found out how to break my app's rendering with one line of XML. Not true, five lines of XML.

This is post #2 about Resource Timing, with a focus on understanding loading dependencies. In part 1 "Resource Timing - The API" I covered the attributes responseEnd and startTime. Now I will try to show how the API can be used to see which resources block each other, which is the step to understand before optimizing site speed, a very essential step to know what is the right thing to optimize.

I had deleted a git branch locally, which I wanted to restore. It's totally easy. A tiny bit of knowledge upfront. There is something called the reflog, it's kinda like the hidden git history, that knows every change you did on the repo, every change, and it does NOT throw away anything.

[this is a draft]

Which unit to use, rem, em or even px (just to mention the most common units) when writing CSS seems to be an ongoing discussion. For people entering the space of web development the hurdle just gets higher, the complexity is continuously growing. There are more units than ever, I counted 21, there is more sites to learn from. It is not easy to figure out where and how to start.
I will try to analyze this a bit applying what I know and have learnt over the last 25 years of web development.

First search result for "CSS reset" is by the mighty Eric Meyer https://meyerweb.com/eric/tools/css/reset/ from quite some time ago. And looking up the source of his site I see the reset is not really included, also no modified version as far as I saw it. Next I came across https://cssreset.com/what-is-a-css-reset/ which nicely explains the whys and also states the cons. Unfortunately the latter article is missing a date, so I can't say how old this knowledge is. That's why I was so very keen on having all items properly dated on my blog.

In October 17, 1990 IMDb started as a unix script.
December 25, 1990 Tim Berners-Lee releases WorldWideWeb (later Nexus) on Christmas day, the first ever browser for the web.
August 6, 1991 Tim Berners-Lee responding to a thread on the alt.hypertext Usenet newsgroup, publicly announces the World Wide Web project for the first time. The History of the Web has so interesting stuff. Very worth a read. A great site to spend a lot of time on.

I was just filtering a list list.filter(someCondition) and I only wanted the first element in case there is one. Doing list.filter(someCondition)[0] fails when the filtered list is empty. So I am using slice(0, 1), which returns the first element if there is one, an empty list otherwise. Now I do list.filter(someCondition).slice(0, 1) and never list.filter(someCondition)[0]. Such small things.

There is nothing new about websites being backwards compatible. The HMTL Design Principles from the W3C are from November 2007 and they are not outdated!

I use docker images to provide the environment for development. My nodejs is installed only inside the docker image. That means I always map my working directory into the container. This means I don't need to send no build context to the docker deamon.

I still often type document.querySelector() or document.querySelectorAll() even though even before this was available in the browser the developer consoles, FireBugs or whatever they were called had a shorter version available $ and $$. Yep, it works almost exactly the same, just that one returns a NodeList the other an array. Just try it. It works in all browsers as far as I know, I tried Firefox, Safari, Chrome and Edge. See the image below for how it works in Firefox.

I always struggled with it. Actually I looked it up a couple days ago and until today I was under the assumption "than" was for time and ordering, I had been confused and wrong.

I read it multiple times already in Measure What Matters by John Doerr, that OKRs are flexible. I normally underline those things, but now I have to note it somewhere where I can find it again without physically needing the book. On page 54 he writes

This topic came up today when we discussed the #crewmeister API, and made me think. Until I remembered that we once in a project used to use the pure POST params, which are basically key-value pairs. And the question also reminded me of my PHP times, there the server-side knew how to handle a key which looks like user[0] and builds and array. But when I ran into that problem back then we used to use python and there we didn't have that.

In the last days I had to learn a lot about how to use, write and understand user stories. This talk by Mike Cohn is a pretty good kick start and summary for the hows and whys.

Don't promisify fs.exists since this does not play by the rules of node style callback params, where the first one should be err and then data. It seems this does return only the data, which promisify understands as an error and does throw right away. Instead do what the node js docs suggest too and use fs.access instead, like so: promisify(fs.access)(aPath, fs.R_OK). See it in action [here in the cosmowiki].

My laziness actually pulls me strongly towards #noEstimates. I guess it's because the "no" means I have less work to do. Which I could kind of back up with the argument Robert Weissgraeber gives at the beginning of his talk, which is that we should remove all unnecessary work, all waste.

My pet project ES6 Katas is a playground for learning, if you look in the repo you see lots of things moving around and changes made. Most of it is because I try to apply new learnings and try to get to a structure that really is what I consider good software. Lots of new bits of information I learn I try to apply there or at least play around with it and figure out what's a better way to do things. This often might end up in a forth and back of things and in not being able to decide what is right, and it looks like nothing moves forward, but that's just on the surface.

Unfortunately I missed Franziska's session at SoCraTes 2015 on this topic, but fortunately she wrote about it, make sure to also read through her commits backwards, of course :). Very nice and readable! An article "Kickstart your next project with a Walking Skeleton" she referred to, that explains the process too. While reading more and more of the [c2 wiki] I am asking myself where is the difference to a spike which Kent Beck defined as

In this talk, Uncle Bob starts to set the context for why our industry has a hard time catching up with the speed and also why it is so important that we do spend more time on mindfully constructing software. It's worth spending those 1,5h watching this talk, or less if you 2x the video speed :).

In order to keep all your meta data of your project in one place and only create files that actually just copy those data you can use projectz where you maintain data like title, description, author(s), badges, ... in one CSON file and with a special markup you can update fill in the templates files like README, package.json, ...

IDEs are awesome, but sometimes in my way and setting up test runners sometimes defeats the purpose of being fast with tests, which also means having feedback constantly and continuously.