DEV Community: Paolo Lulli

Code Your Way Out

Paolo Lulli — Wed, 11 Jan 2023 17:15:46 +0000

We are taught that code reuse is good.

Depending on big famous library X is better than reimplementing the features from scratch.

As it turns out, sometimes it is true, some other it's not, and you are better off reimplementing your own solution, provided you have a good understanding of the problem you are going to address.

This is true for common features as it is for Security.
It's true for the 1-user app as it is for scalable systems for 1 billion users.

Reuse, dependency on features we don't fully understand are bad, and usually come back and bite us badly:

https://kevwe.se/weekly/202302

Technology Choices

Paolo Lulli — Mon, 19 Dec 2022 16:51:22 +0000

Every choice has consequences, and technology is no exception.

To influence our future, it is good to have more choices or - arguably - better choices available.

The technology we choose has the power to influence the future, in terms of depending on some entity rather than some other; or even depending on someone else at all.

When you want a page to be beautiful and snappy, you have also to ponder whether depending on a CDN is a good thing. You have to ponder cautiously if depending on a full ecosystem of build tools and frameworks is actually something that will keep working years down the line or if it'll keep increasing costs for you.

Also, are you going to still be around for fixes when dependencies will break your application ?

Shiny packages might be a luxury you can't really afford, if you calculate the costs in the right way.

https://kevwe.com/weekly/202251

The Storm

Paolo Lulli — Tue, 13 Dec 2022 17:28:17 +0000

Everything is connected, in life like in technology, connections can be a good thing, an opening for new possibilities.

But not all connections are good.

It could be a gateway for issues you would not expect.

As the world is much bigger and nuanced than you would have expected as a younger version of yourself, the single computer in the basement is now open to the wider ocean and its storms.

This is not a metaphor, and the storm is coming for real.

As people grows in age and experience, so our industry must grow past its adolescence and mistakes, before being ready to traverse The Ocean.

For the weekly links: https://kevwe.com/weekly/202250

The Third Way

Paolo Lulli — Sun, 04 Dec 2022 17:51:31 +0000

Between delegating everything to a random Cloud provider and managing your entire physical infrastructure in-house, there is a wide middle ground where you can fine-tune how much control you are willing to give out, and how much is instead needed on your part.

This kind of tuning is no longer possible if you give up on the competences, in the ability to understand what is going on.

Giving up on everything means we are headed for new Middle Ages: Digital Middle Ages.

For the Weekly links: https://kevwe.com/weekly/202249

On Sustainable Technology

Paolo Lulli — Tue, 29 Nov 2022 07:18:30 +0000

The software world is peculiar in a number of ways.

Not so much about user than about who builds software.

There is plenty of alternatives to build things, and in general this is good, in that you're allowed to pick instruments that better suit you or the final result.

But sometimes it's not about fair alternatives.

There is hidden complexity, hidden costs for the adoption and - ultimately - hidden security challenges.

User fronting technologies are particularly affected by the "cool factor". Everyone want to look good, everyone has great time selling eye candy to the customers, but most of the time it is not entirely understood what that means.

We seem to care more about the external look of an application than what it really does with our data.

And the reality is: you want printed quality fonts of arbitrary family, single page application that do not reload the page, seamless experience on any screen size and ratio... you can get it, of course.
Just, this means you're bringing in telemetry from occult CDN 'freeware' providers.

You are violating user data, to the benefit of unknown third parties with those huge bundles that you force the users to download.
You are forcing a state onto the clients, that gets soon out of hand when things go wrong.

Good luck ringing a million users asking: "please refresh your local cache", will they really be happier like that?

It could be this is what you need, but again I think than in a very high percentage of cases all the user really need is a readable font, an accessible layout and websites that do not weigh more than 1M at the first access.

Everything more than that very quickly becomes just a sustainability issue.

For the weekly links: https://kevwe.com/weekly/202248

Db of Mass Destruction

Paolo Lulli — Fri, 18 Nov 2022 15:35:52 +0000

For very long time there has been the illusion that people could just store their important data in social account.

As it is more and more evident, maybe this is not the smartest choice.

Most peple is not supposed to know the inner workings of the internet, like most people is not supposed to know how an engine works.

But while, in order to be able to start a car you should at least have the notion that indeed, it needs a motor, we would not want to hide from people that sometimes a database is a technology that can help.

And also, that gifting away private data to social networks is not that unlike running into a tree

https://kevwe.com/weekly/202247

How to Share a directory with the Guest System in KVM

Paolo Lulli — Sun, 13 Nov 2022 19:14:11 +0000

https://kevwe.com/blog/Share-a-directory-with-the-Guest-System

Fear of Hypervisors

Paolo Lulli — Sun, 13 Nov 2022 19:12:51 +0000

Not unlike how Lucretius described the Superstition springing out from the fear of
thunder and lightning, the Cloud was born as a religion out of the Fear of Hypervisors.

We adore the Cloud and the elastic scalability out of ignorance and misunderstanding.

We can't see, therefore we cannot understand, the magic of KVM and Libvirt.

We can't see, and therefore do not understand what overcommitted resources actually mean.
(Spoiler: it means you can pay 10x your actual physical resources usage)

The thunder gods gave us disposable instances, scalable magic and other heavenly clouds.

Tough, the Original Sin of the Shared Responsibility Model
is still there: we won't be saved from someone else alone taking care of our own data.

We delegate but still are responsible for our customers data.

We won't be saved by ignorance as, when the thunder gods will decide to unplug humanity,
we will need to re-learn it all again.

It has happened before, and it will happen again.

For the weekly links at: https://kevwe.com/weekly/202246

Get Your Own Cassandra Cluster in 1.618 hours

Paolo Lulli — Wed, 02 Nov 2022 17:29:44 +0000

All you need

2N+1 linux machines (virtual?), with N>=1
a command line
a sheet of paper

Install the build system

Apache Cassandra needs a Java sdk installed. The latest supported version is Java 11. I read that upcoming support for latest Java version will be soon here, but we stick to Java 11 that is supported by now.

In order to have Apache Cassandra working on Java 11, it needs to be compiled with it, or you will have to run it with Java 8.

In order to install Java, you might want to do it like this, possibly from a root account:

mkdir -p /opt/java
curl -LO https://download.java.net/openjdk/jdk11/ri/openjdk-11+28_linux-x64_bin.tar.gz

tar vxzf openjdk-11+28_linux-x64_bin.tar.gz
mv jdk-11 /opt/java
cat> /opt/shared/java/load-jdk-11.sh

! /bin/bash

export JAVA_HOME=/opt/java/jdk-11
export PATH=${JAVA_HOME}/bin:${PATH}

The full article: https://kevwe.com/blog/get-your-own-cassandra-cluster

A Nightmare called YML

Paolo Lulli — Mon, 24 Oct 2022 14:32:23 +0000

I started working as a professional developer around year 2000.

At that time, XML was the last trend, everyone and his cousin was migrating legacy config files and data to use XML.

People was writing parsers to marshall and un-marshall XML into objects in-memory.

Java was much slower and verbose at the time, the RAM was very costly, and everyone wanted to migrate databases to a bunch of XML files, because it seemed like a cool thing to do.

Everyone wanted to query data with XQuery, make the fancy prints with XSLT and maybe validate with XSD for the fun of it.

Corba was a thing of the past, and now we could finally break our heads on WSDL and the S in SOAP that the legend says it stands for: Simple.

One hour of implementation and a team for six months performing painful XSD validations: a good standard for the industry.

If you wanted to look smart in job interviews, you just had to name a lot of things with J in it: EJB, J2EE, JDO, JDBC, JNDI!

In a few years, the revolution was about to happen, Spring project promised to get rid of all the mess in J2EE and costly application servers. The solution was simple: just type in a bunch of XML files, and you fulfill the enterprise specs without the intended application server.

Nowadays we're much more loose, a decade of Rest webservices have totally spoiled us: life is finally quite easy, we don't need so much head scratching on the backend: there is the frontend for that.

Just give them some Json response and let them complicate their lives with the latest coolest vulnerable Node module, and they will get back to you in a month of two.

Infrastructure as a code: if you ask me, a very good idea. Git is a gift from the gods, even more if you have been using CVS, SVN, PVCS or other monsters from the past. Only hearing the names scares the hell out of me!

The only problem I witness today is a scary proliferation of products based on YML.

If you ask me, YML has taken the bad enterprisey parts of XML, and joined them with the casual attitude of nowaday's API designers: code first, explain (maybe) someday. Provide some structure, but not too much.

And as bad as XML was - and still is - you can actually reformat it like you want. Validation is a pain, but it's not left to your human discernment of spaces vs tabs. You don't have to count the dashes and the spaces on each line to make some sense out of it: we had enough of strange syntaxes editing SGMLS DTDs (see: monsters as above) and just wanted few simple, machine-enforceable rules.

In a nutshell, the good part of XML is that it was never really meant for humans, while YML is supposed to be "helpful" and "friendly".

I don't know why, but this looks pretty much like a mistake, and in my mind the proper adjective seems rather: "hostile", and if I can convert it to Json instead, or anything else, I'd rather go for it.

I see that the line of thinking in YML could be considered similar to Markdown: comfortable to type, structured, easy to read, apart that Markdown structure is sound and mostly makes sense for a human, while still being parsable from code. On the other hand YML structure mostly sucks for a human, while it's quite brittle and fragile for parsers too.

I have to admit I've never incurred into the Norway problem, because YML files started to bite me so much earlier, and when copy-pasting around, I just assume I must have done something wrong, like adding an invisible space somewhere, then I have to start typing everything from scratch.

Put in perspective, I think that in a decade or so, and with an ever aging population of technologists, someone will eventually come up with a Manifesto that argues the true agility consists in avoiding stupid keyboard shortcuts and whitespace hacks.

I expect someone to come up with talks that illustrate to the wider public the Total Cost of Ownership of a code base relying on positional semantics that, given somewhere an extra whitespace, implodes on itself.

The links for this week:
https://kevwe.com/weekly/202243

The API Economy

Paolo Lulli — Tue, 11 Oct 2022 15:55:57 +0000

The focus on new languages and new technologies sometimes has left behind the need for data interchange and durability.

Do not keep reinventing new ways to do do the same things if fewer application are then able to speak to each other:

the net result is a loss.

Favor technologies that are contract-based: be explicit about the spec, and loose about the implementation details.

We want to build APIs that last longer than the languages they're implemented with.

We want our applications to be an investment, not just a temporary luxury: something that lasts.

Below The links of the week:

https://kevwe.com/weekly/202241

Avoiding the Bloat with Microservices

Paolo Lulli — Sun, 09 Oct 2022 21:37:43 +0000

When we implement microservices, the first tought is to reuse what we know well from the Old World.

In fact, reuse is a good thing.

But we should not miss the opportunity for smarter pieces to fill in.

Smarter technologies, niche libraries that help get the job done with less legacy.

A lot can be achieved with small microservices that get the job done, and done well.

I am thinking small Go services wherever Java is simply too much:

https://kevwe.com/weekly/202240