Links for 2020-05-31

Running Things in Python, Emacs, Everything That Can Go Wrong, Why We Believe that Rewrites Go Right, Copyleft, Analogies for Technical Debt, Leading Projects, Microservices in Rust, Cities as Roads, Complaining about Stallman.

The many ways to pass code to Python from the terminal

This is a curious post. Although I've been using Python for a long time, some of those were completely unknowns to me -- for example, making a zip file and running it directly with the interpreter.

Emacs - Productivity Tricks/Hacks

Although I don't usually use Emacs -- I'm a Vim user myself -- I can't stop myself from sharing a post about Emacs that suggests using Evil, the Vim keybinds emulation mode.

And the suggestion of using Helm is something that I really need to add on my Emacs configuration.

Postmortems

A Discord place for posting things going wrong.

I've been mentioning this for a year already: Most presentations we do, when we go in public, is to talk about the things the go perfecting fine -- you just do a build, it will never fail; just write the code, you won't find a corner case; just create something, everything will be fine -- and that's not the real life.

Postmortens is a forum exactly for describing things going wrong. And there is a lot more to learn from things going wrong than from perfect steps that does not reflect reality.

Why do we fall into the rewrite trap?

Yes, everybody, at this point, heard about the "Refactor, Don't Rewrite". And this is just more of that.

But there are some things that really caught my eye¹: First, "Contempt Culture", the idea that something is bad because it's old and bad and the new thing is good because it's new. I mentioned this on my "Things I Learnt The Hard Way in 30 Years of Software Development", but "right tool for the job" is mostly a way to push an agenda and the right tool is mostly the tool your team knows the best.

Also, instead of just going through "Rewrite BAD!", it actually list some situations when doing a rewrite is the right option -- and I won't spoil, but it does seems really the right situation.

Toward Copyleft Equality for All

A lot of the things in this post would be just for me to repeat things I pointed in other posts: Companies are using the Free Software label just as marketing, working on new features and charging for it, while leaving the bugfixing part to the community, for example.

Here, the thing is a bit more complex, and I'm not sure if I can have an concrete opinion about what is being said. Basically, the idea of "copyleft" -- using copyright to make sure the code will still be available and accessible to everything -- has been been subverted with the "dual licensing".

In one hand, companies should be able to let the code be available and still charge for it, but the way they have been using free software seems to be only as a marketing plot. "Look, it's free software!" but listen to the community, let them point the destiny of the project, making sure contributing is easy, nothing of that makes part of those projects.

Technical Debt Is like a Tetris Game

This may be the best Technical Debt analogy I ever seen: It is a game of Tetris.

In the start, everything is clear and it is simple to fit the pieces. But, if you don't take the time to clear things from time to time, it will get more and more chaotic till you lose.

If this isn't an explanation that everyone understands why you need to stop from just piling up pieces and try to clear the field from time to time, I really don't know what will.

How to Lead a Project - as a Software Engineer

A list of things software engineers should take care when they become project leaders.

I can attest that the general concept here works, 'cause that's what I did when I was technical leader in projects.

Building a Microservice with Rust

Ok, the fact that I love Rust may be related to me wanting to share this, but you have to agree that the post is really complete, showing all the hops and jumps you need to do to make a microservice in Rust.

city roads

This is a cool project: Instead of drawing a city using its geographical limits, draw it using their roads.

Burning the House That Richard Stallman (RMS) Built: An Open Letter to GNU Maintainers Who Opposed RMS

Let's complain about those complaining?

Another one of those "Leave rms alone!" kind of posts. This time, whoever works for Microsoft -- which is extremely weird for this kind of post for not calling it Micro$oft -- are the real pirates and who works for Red Hat have as bad character as them.

Honestly, there is no denying in the work Richard Stallman did to promote free software. But, at the same time, we can't ignore that, for years, GCC got stuck on its architecture 'cause any changes were denied and we can't deny that this "tantrum" in improving GCC is what gave Clang the space it got -- just remember that Apple used GCC to build macOS and iOS binaries. And we can't ignore that just one day before the pressure for rms to leave the FSF reached critical levels he was still saying that there was no problem in an underage girl to have a sexual relationship to an old man.

This kind of though -- "But he did lots, and can say and do whatever he wants" -- it's the most pure teenage thought of no worrying about the consequences. "Oh, look at the consequences in the history of Microsoft against free software! But don't look on what rms is saying and how his posture hurts important projects and the community, 'cause he's my friend".

The community has grown up -- not only in numbers, but also in its mental age -- and now we are asking when important figures will be hold responsible for whatever they say and whatever they do.

... and it is really weird for a post like this that attacks Microsoft and Red Hat, but says absolutely NOTHING about what Google has been doing with the term "open source".

This post was built with the help of

• newsbot
• Ed S
• HN Tooter
• codesections
• Starfish