Techniques: From code to data and back to code

Lets create a series of fields:

{
  container.add(new Field("name", "text"));
  container.add(new Field("surname", "text"));
  container.add(new Field("something", "text"));
}

But wait we can just collect all the actuall info and then have the data so the code 'is not repeating':

fields = [
  { title: "name", type: "text" },
  { title: "surname", type: "text" },
  { title: "something", type: "text" },
];

But wait we can use code so the data 'is not repeating':

fields = [
  ...[ "name", "surname", "something" ]
       .map(i => ({ title: i , type: "text" }))
];

But wait we can use data so the code 'is not repeating':

fields = [
  { titles: [ "name", "surname", "something" ], type: "text" },
  { titles: [ "birth", "death" ], type: "date" },
].flatMap(magic);

But if you really thing about it, and ignore any "non-programmers", who are those guys anyway, the first one is what actually what happens, and by definition has no limitations because it's actually the thing itself, like C. And then you add some sugar and you are also modern:

{
  container.add(
    field.text("name"),
    field.text("surname"),
    field.text("something"),
    field.date("birth"),
    field.date("death").optional,
  )
}

done_

Decline of Thought: Tailwind CSS

Top "css library" of 2020s, tailwind css with the its message "Rapidly build modern websites without ever leaving your HTML" and with the sample code in the home page:

<figure class="md:flex bg-slate-100 rounded-xl p-8 md:p-0 dark:bg-slate-800">
  <img class="w-24 h-24 md:w-48 md:h-auto md:rounded-none rounded-full mx-auto" src="...">
  <div class="pt-6 md:p-8 text-center md:text-left space-y-4">
    <blockquote>
      <p class="text-lg font-medium">...</p>
    </blockquote>
    <figcaption class="font-medium">
      <div class="text-sky-500 dark:text-sky-400">...</div>
      <div class="text-slate-700 dark:text-slate-500">...</div>
    </figcaption>
  </div>
</figure>

This cannot be a real think, this is a joke. What is this mess that is presented as the example. The code does not even fit in the pre tag they have. This is a classic example of a taking a good idea that solves well a very specific problem in some specific situation and assuming that it can be expanded to solve the universe.

In our case this good idea is creating some small classes to describe a common css property that is not bound necessarily with the rest of the context and it is independent of the rest of the rules, eg. a class named center that just sets the text align to the center (and even this can be argued that has an effect in the around paddings and margins and if they have to be symmetric)

And the bad idea, the whole tailwind css main gimmick, that with infinite classes and dumping everything in the html file will solve everything. When in reality you solve nothing and contribute just in the reduction or readable code. Which is an other common insane idea, that you should be able to write code very fast even if it not readable. This is true only for prototyping, in the lifetime of a peace of code you have 1 write in the beginning and 1 read with a possible 1 write/change after that, so with very complex math we know that the the reads is always greater that the writes.

The irony is that the same web devs cults that support the idea of readability and use it to make fun of the old school c programmer, but when they find their own "c macros" (see. tailwind) they are all about that life. Fuck off losers.

done_

Html: Write the tags of your dreams

Lets say we want to write some quick html and js thing to test something. We want a text field and a button to login with a username and if logged, some text with the username saying hello.

Ok, we skip all the html, head and body tags and we just write this:

<login>
    <input type="text">
    <button onclick="login()">Log in</button>
</login>

<hello>
    Hello <username>
</hello>

We add and a script tag in the end and we are done (and it works, this is not a joke)

It may not be obvious but we are not following the law of the "Valid custom element names" and if we then define some components with these name you are going to get the "Failed to execute 'define', 'hello' is not a valid custom element name".

Very important check, image this check not being there all the bad things that could happen. Like when you try to create a component "icon" but there is no hyphen there, so you spend all day trying to figure out if "a-icon" or "icon-" is the least ugly of the two, and then you are unable to sleep thinking that there must be some other way to cheat the system... there must be... Thank you whatwg.

done_

Techniques: Multiple localhost sessions

Lets assume you have an web app with some sort of login system, and you are testing things on a local web server bound to "localhost" and you want to test multiple logged in users at the same time.

We start by creating multiple "domains" pointing to the localhost via the /ets/hosts file:

127.0.0.1  localhost1
127.0.0.1  localhost2
127.0.0.1  localhost3
127.0.0.1  localhost4
127.0.0.1  localhost5
127.0.0.1  localhost6
127.0.0.1  localhost7
127.0.0.1  localhost8
127.0.0.1  localhost9

Because the session and local storage is instanced per domain name (or even the cookies for the old school) using the localhostX will each be isolated.

Then you fight with your web server that definitely will not like requesting http with something different than localhost, but you can win.

And then you fight with the OAuth callback redirect url and... you lose the fight... and you go back to the firefox containers.

done_

Techniques: Patch files

Create a patch file:

• Locate the file we want to change, eg. path/file.json
• Create a copy of the file and edit it in the same directory, eg. path/file.new.json
• Create the diff file by running the program diff, eg.

  diff -u path/file.json path/file.new.json > file.json.diff

• Ensure or change the first lines of the diff file in order to point to the desired files, eg. path/file.json to build/path/file.json
• Apply the patch by running the program patch, eg.

  patch -p0 < file.json.diff

Notes:

• Both programs, diff and patch, should be part of the core programs on any linux distribution
• The -u option specifies that the created file is of unified type
• The -p0 options specifies that the full paths inside the first lines of the diff file should be used

done_