The source content for blog.juliobiason.me
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

81 lines
3.7 KiB

+++
title = "Links for 2020-04-21"
date = 2020-04-21
[taxonomies]
tags = ["links", "docker", "docker-compose", "mongodb", "postgresql",
"assignment", "haskell", "youtube", "google", "ide"]
+++
Visualizing You Docker Compose, MongoDB vs PostgreSQL, Assignment Statement,
How to Understand Systems, Learning Haskell, Losing Your YouTube Account, IDEs
For Students
<!-- more -->
# [Nautilus: A Docker Compose Charting Tool](https://nautilusdev.com/)
Not sure if you're designing your Docker Compose properly? This tool can draw
every container, their names, volumes and so on.
# [Comparison of JOINS: MongoDB vs. PostgreSQL](https://www.enterprisedb.com/blog/comparison-joins-mongodb-vs-postgresql)
Ok, short summary: Yes, MongoDB doesn't have joins and you have to do them
yourself. You can write your own (very long) aggregations to make it work like
joins in relational databases, but the speed is atrociously slow.
Now, why am I sharing this? 'Cause one of the points of using MongoDB (or any
other NoSQL database) requires denormalizing your data first. It takes more
space due duplication, it can lead to some inconsistencies, but you need to
keep thins in mind when using those database -- and sometimes, it is exactly
what you need.
# [How to avoid the assignment statement](http://loup-vaillant.fr/tutorials/avoid-assignment)
Surely using other languages than C can give you a lot of control over this
kind of stuff, but the suggestions here are valid for any languages.
And before you think it's because "assignment statement considered harmful",
no, that's not it. It's just some tricks into doing things that will give you
less headaches in the future.
# [Systems that defy detailed understanding](https://blog.nelhage.com/post/systems-that-defy-understanding/)
Instead of "How to avoid problems" or "How to fix common issues", the author
explains how to _understand_ what you're dealing with. And I can get behind
this: Before you fix something, you need to understand how the system works.
(Maybe that's why I like Contracts so much: It describes what a system
consumes and what it produces and what every thing in the final product means.
This reduces the chance of being misunderstood.)
# [What I Wish I Knew When Learning Haskell](http://dev.stephendiehl.com/hask/)
While most of "Thinks I Wish I Knew" posts actually mean "Stupid things I did
in So and So that I shouldn't", this is actually a very complete introduction
to Haskell.
# [YouTube Accidentally Permanently Terminated My Account](https://medium.com/@alexhowlett/youtube-accidentally-permanently-terminated-my-account-4b5852c80679)
While this was solved and the account reinstated, this kind of report just
shows the perils of not controlling your platform: In a whim, everything you
have could vanish.
I don't mean "You need to buy your own hack, put your own blades, and lease
your own internet connection to have a site on the web", but when the policies
over your content are not managed by yourself, you're about to get a lot of
pain.
# [Stop Making Students Use Eclipse](https://nora.codes/post/stop-making-students-use-eclipse/)
I kinda make this same point some time ago: While it is nice and dandy that
you can press a button and make a code run -- or make a full deployment --
when you're actually learning a language, those things are actually a problem
than a solution.
Sure, creating a build is hard and making a deployment even harder, but when
people who are learning to code are not taught how those things work, 'cause
they can "just press a button", they will never learn. Without exposing them
to the hardship of what is to make code -- and building and deployment are two
facets of this -- they can never learn how to make a CI/CD, for example.