Links for 2020-05-162020-05-16 #links #gleam #java #python #code #images #troff #nroff #typesetting #vim #documentation #porn industry #testing #covid #second order thinking #metrodome #diagrams #react #react native #windows #macos #bytecodes #secrets #word generator #firebase #privacy #blogging #sharring #material design
Gleam, Java From a Python View, Code Images, UNIX TypeSetting Tools, History of VIM, Writing Documentation, Fighting COVID with Porn, Thinking Beyond Problems, A Metronome, Diagrams in Python, React Native for Windows (and Mac), Secrets in Python Bytecodes, Word Generator NeuralNet, Firebase Blunders, Standups, Sharing as a Dev, Material Design.
Gleam is another language focused on the BEAM (Erlang) VM. And the new version brings a lot of stuff that makes me really curious about using it in the future.
Not that I'm converted from Python to Java -- I can see I'm productive with Java, but the fact is, I'm not having fun being productive with it. Sure, it gets the job done, but it lacks something.
Even with that, I think this post brings a lot of things that are actually... interesting... in recent Java releases, and does a good job in breaking that feeling that Java sucks.
I used Carbon before but I keep forgetting when I need it the most.
People believe Vim to be unfriendly, but what happens is that the lineage of it comes from a long way, always improving and changing. Understanding why Vim is designed the way it is is one way to understand it -- and, as anything in history, to avoid repeating the same mistakes again.
Yes, another post about "the tools of the ole age" --
troff is used to build
man pages -- but there is something about the simplistic approach on due the
typesetting that is really interesting.
This articles pushes towards better written communication due the fact that most of us are working remotely, but I have to push that this should be the norm, not the exception.
Documentation can be used for a long time after a developer leaves the project or the company, and keeping it up-to-date can ease the onboarding of new developers. So no, it's not just because we jumped into the remote working era that documentation must be a priority: It should be way before that.
Ah, the kind of news headlines that you won't expect to see.
But the thing boils down to the fact that the porn industry had to deal with HIV and now makes HIV testing a common, periodic thing. And with COVID-19, a virus that has no cure (yet), and something that we'll have to learn to live with, doing something similar is almost required.
Obviously, porn stars are just a small set of people compared to the general population, and thus way more expensive, but we really need to start thinking about this.
A psychological article, for a change, and something most developers can learn from: Instead of focusing on the problem of "this", also thing on what the issues the solution will create.
I think I saw this application running in the last year PythonBrasil, and here is the link for the Flatpak of it.
It's a great tool to time stuff, and it is also nice that it is a desktop application with responsive layout.
I'm a sucker for this kind of stuff -- so much that
dot is part of my usual
development tools. But writing diagrams in Python... that's a freaking awesome
way to do it.
And now we have React Native for Windows and Mac. While the suspicion that this may again be a bust, at least React Native has some market presence to maybe make this work.
The same problem people have with compiled applications -- which can be easily
be extracted using
strings -- exists with Python bytecode files.
Security is hard. Keeping users information from leaking is a full time job and can happen no matter what database/storage you use -- the standards for 90% of the installs is "make it easier for developers to start working, and later they can secure it" instead of the other way around it. So this is not a Firebase issue at all.
The troubling bit, though is this "A December 2019 report shows that Google scrubs these vulnerable database URLs from its search results. However, they are still indexed by other search engines like Bing."
How the fuck assholy you have to be that you hide the wronging of people using your product, just because you have, basically, the monopoly on search engines? Sure, using that information may help bad actors accessing random people -- people that have no direct contact with the tool besides using something someone else built -- but heck, cancel the damn account till they learn how to protect people data instead of just hiding the problems under the hug. "But that would cause people to stop using our product!" Then your product have a design problem and you should fix it.
But, again, hiding it under the hug is no solution. At all.
I freaking hate these kind of posts: "Here, thing does work. We should get rid of it." This goes one step further and points what people are going with the thing and still points that thing is broken. Heck, why can't we point why something exists and try to teach people on how to do it properly?
Nope, complaining that it is broken is way easier.
"You do not really understand something unless you can explain it to your grandmother. If you can't explain something to a six-year-old, you really don't understand it yourself." is one of Richard Feyman's famous quotes.
I do like to post opinions on my blog. I do like to do presentations. Mostly 'cause, when I'm explaining, I'm learning. I may think something is worth explaining and do some research on how to better explain it.
Also, sometimes I write things I learnt down so I can remember it better later.
That's why some of those "Month of blogging" exist.
Ok, maybe the title is a bit too bait, but there is one point that really caught my eye:
"We are representing Google, whatever that might mean."
I do have my problems with Material design -- in my opinion, its natural evolution would eventually get to the interfaces we have right now, so it's basically a step back -- but that really is something.
This post was built with the help of