From 6a6eb53adfc1a79859acf1108b33f93616fff540 Mon Sep 17 00:00:00 2001 From: Julio Biason Date: Tue, 26 May 2020 10:22:13 -0300 Subject: [PATCH] Links for 2020-05-26 --- content/links/20200526.md | 152 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 152 insertions(+) create mode 100644 content/links/20200526.md diff --git a/content/links/20200526.md b/content/links/20200526.md new file mode 100644 index 0000000..cefb295 --- /dev/null +++ b/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. + + + +## [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)