7.3 KiB
+++ title = "Links for 2020-05-26" date = 2020-05-26
[taxonomies] tags = ["links", "recutils", "git", "cobol", "paying", "open source", "free software", "contributing", "boring stuff", "accessibility", "great code", "steps", "joel spolsky", "culture tests", "microsoft", "oil companies", "marketing"] +++
GNU Recutils, Tips on Git, Simple COBOL Code, Paying for Open Source, Contributing to Open Source, Dealing With Boring Stuff, Accessibility, 12 Not So Great Steps For Great Code, Culture Tests, Microsoft Marketing.
GNU Recutils
So you want to keep a simple database, but don't want to go through the loops and hoops of creating a script to manage it? Worry no more, the solution is here!
Recutils is a set of tools that I wasn't aware it existed, but it keeps information in plain files, allow searching and has a schema.
5 Useful Tricks You Didn't Know for Git
While I'm not a huge fan of the short logs/changes (just "not a fan", not
saying it may be useful), the whatchanged and the other commands are pretty
damn useful.
A basic "game" in COBOL for learning
Ah, the good old days of COBOL. Haha, who am I kidding, they were never good, that's all we had!
But if you never saw a COBOL code, here is a taste of it.
Paying for Software
We have seen this discussion going around for some time, but it's worth repeating it: In an age of large usage of free software, we must remember that companies making money with it are not helping fund said software.
But it's also worth mentioning that not every free software needs support. Going "Open Source" is, sometimes, a marketing plot just to get visibility; I've seen companies making open source in which they never heard the points raised by the community itself and even just focused on new features, leaving the bugfix part to the community (and no, I'll not cite with company/software does this).
How to Contribute to Open Source Software
I have a presentation on the "Why and How to Contribute To Open Source Software" (it's in Portuguese, so I won't link it here), but here is a complete explanation on how to contribute with software -- and yes, there are more ways to contribute than just writing code.
I like how very "step by step" this post describes how to do it, even if it is focused on a major service and may not reflect all open source projects (I may even "steal" some of those for my presentation).
Help, I can't learn/do something because it is boring!
I've done my fair share of boring stuff -- I sadly remember when I have to go through 30+ AWS Glacier folders to restore one single file on each, with the interface not allowing me to open each folder in a new tab, so it was really boring: click, click, click, click, wait, click, click, click, rinse, repeat.
But, if I could, I'd automate the heck of it, and I probably should have taken some breaks -- which was hard, considering my boss sat in front of me.
Standards for Writing Accessibly
Some tips on how to write interfaces in an accessible friendly mode. And while you may think "Why should I worry about accessibility when only low-percent of users have a disability?", you may also wonder how many of those have a temporary disability, like they just came back from their LASIK surgery, they broke their arms in a ski accident and so on. Providing accessible content for people with disabilities may also improve your interface for those people -- and they would probably be grateful that they don't need to check your competitor.
The Joel Test: 12 Steps to Better Code
An old post by Joel Spolsky, but it is probably worth repeating. This is a checklist of things you should do for better code. But we need here to discuss if the whole list is actually good.
I've seen a lot of projects fail 'cause it misses something incredibly simple like specs, so devs keep running in circles, trying to figure out what actually needs to be built.
On the other hand, some things feel out of place, in my opinion:
- Having an up-to-date schedule is good for business, but it could also blind those people from the "most viable product". In my experience, having a schedule is ok only on high level, but most of the time is makes people focus on previously though deliveries and not on what is being built.
- Having the best tools money can buy is awesome for developers that like the latest shinning thing (and hey, I do like it too), but it's not totally necessary. You can have the "most ok tools" and still be a heck productive.
- Having testers is not something I'm fond. Not that there is something wrong with tests -- quite the opposite -- but I'd prefer to have test engineer/designer than testers. Why? Because it should be the developers testing the system, building automated tests when necessary and specially 'cause writing those would give more understanding of the whole.
- Having candidates to write code is bollocks; asking candidates on their thought process for solving a problem is a lot more effective. Sure, you could do both, but think about the time the candidate will take for writing the code, then thinking on how to improve it, while they can simply describe it for you. "But it's their time"; yes, and you're just being an asshole if you thing their time isn't worth shit.
Honestly, when I picked the link in my feed, I though "Hey, that's a good list of things to have". But then I started writing this and noticed how broken it seems.
The Pragmatic Engineer’s Developer Culture Test
Instead of the checklist above, I think this makes more sense, even if its results can only be verified in the long run -- and the Joel list seems more focused on the short.
It's way more focused on the culture part of the company, what culture the company is trying to build and such -- and as someone who suffered a lot under micro-aggressions without realizing, and without my boss realizing, it surely stroke a never there.
While Microsoft Was Making Its Climate Pledge, It Was Sponsoring an Oil Conference
This is from January this year, but I decided to share it 'cause it shows something a lot of companies do: "We Are The Good Guys" in marketing, "we don't actually care" in business.
I've read some other stories like this: Promote the Pride March, but ignore harassment on LGBT+ people inside the company; say you are here to help, but close repositories and make a contract with ICE. On and on and on.
Just to make the point clearer: This is not something "Microsoft" does, it what every big company does.
This post was built with the help of