Merge branch 'release/20200526'

content/links/20200526.md

@@ -0,0 +1,152 @@
++++
+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.
+
+<!-- more -->
+
+## [GNU Recutils](https://labs.tomasino.org/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](https://densitylabs.io/blog/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](https://github.com/BasiliusCarver/TicTacTOBOL)
+
+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](https://www.paritybit.ca/blog/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](https://killalldefects.com/2020/01/26/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!](https://letterstoanewdeveloper.com/2019/09/23/help-i-cant-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](https://alistapart.com/article/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](https://www.joelonsoftware.com/2000/08/09/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](https://blog.pragmaticengineer.com/the-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](https://www.vice.com/en_us/article/xgqypn/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
+
+* [Jake Bauer](https://social.paritybit.ca/@jbauer)
+* [newsbot](https://mastodon.social/@newsbot)
+* [HN Tooter](https://mastodon.social/@hntooter)