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.
95 lines
4.3 KiB
95 lines
4.3 KiB
4 years ago
|
+++
|
||
|
|
title = "Commented Links for 2020-07-26"
|
||
|
|
date = 2020-07-26
|
||
|
|
|
||
|
|
[taxonomies]
|
||
|
|
tags = ["links", "datomic", "advice", "developer", "google", "racism",
|
||
|
|
"logging", "delete", "product manager", "syntax highlight", "highlight",
|
||
|
|
"rust", "modules"]
|
||
|
|
+++
|
||
|
|
|
||
|
|
Datomic Internals, Developer Advice, Racism@Google, Logging, Code To Delete,
|
||
|
|
Being a Product Manager, Syntax Highlight, Rust Module System.
|
||
|
|
|
||
|
|
<!-- more -->
|
||
|
|
|
||
|
|
## [Unofficial guide to Datomic internals](https://tonsky.me/blog/unofficial-guide-to-datomic-internals/)
|
||
|
|
|
||
|
|
Database internals are always curious, to say the least. And Datomic is also a
|
||
|
|
curious database, as everything is immutable.
|
||
|
|
|
||
|
|
But understating internals is always good to understand where the database
|
||
|
|
fits and how to take most of it.
|
||
|
|
|
||
|
|
## [Advice to Myself When Starting Out as a Software Developer](https://blog.pragmaticengineer.com/advice-to-myself-when-starting-as-a-software-developer/)
|
||
|
|
|
||
|
|
When you're working in the field for too long, it is easy to forget how it was
|
||
|
|
when you started.
|
||
|
|
|
||
|
|
I can't find anything wrong with the tips, but they feel a bit... bland. I
|
||
|
|
mean, honestly, the tips here are something that should be in every developers
|
||
|
|
list anyway, beginner or pro.
|
||
|
|
|
||
|
|
## [Google Ad Portal Equated “Black Girls” with Porn](https://themarkup.org/google-the-giant/2020/07/23/google-advertising-keywords-black-girls)
|
||
|
|
|
||
|
|
Oh, are you saying Google is racist? That's impossible! That's "the algorithm"
|
||
|
|
fault! Google is good, it gives me free email!
|
||
|
|
|
||
|
|
You see how "giving things for free" and "open source" (and then not listening
|
||
|
|
to users) is purely a marketing plot?
|
||
|
|
|
||
|
|
## [Good Logging](https://henrikwarne.com/2020/07/23/good-logging/)
|
||
|
|
|
||
|
|
Logging is always important -- personally, I think logging (and good logs) are
|
||
|
|
more important than debugging -- but knowing _how_ and _what_ to log is the
|
||
|
|
key for properly dealing with it.
|
||
|
|
|
||
|
|
Some of the points are quite common, like screaming logs, although the
|
||
|
|
solution is not using WARNING or INFO, but actually figuring out how to
|
||
|
|
properly set the log level for each modules -- and using modules -- feels more
|
||
|
|
correctly.
|
||
|
|
|
||
|
|
Personally, I leave a lot of `debug` messages in some places, as "scars" of a
|
||
|
|
battle. Maybe some future developer will see that sequence and think twice
|
||
|
|
before jumping in.
|
||
|
|
|
||
|
|
## [Write code that is easy to delete, not easy to extend.](https://programmingisterrible.com/post/139222674273/write-code-that-is-easy-to-delete-not-easy-to)
|
||
|
|
|
||
|
|
That's one thing I totally agree: it is better to write code that's easy to
|
||
|
|
delete than to reuse. But simply going into copying things over and over so
|
||
|
|
you can delete one thing without breaking the other is not actually the
|
||
|
|
solution.
|
||
|
|
|
||
|
|
I'd just adding abstractions, to the point functions are so simple they exist
|
||
|
|
without any business logic; these logic pieces are then put together in other
|
||
|
|
functions, describing _exactly_ what the business rule is:
|
||
|
|
get_info_from_server, change_info_in_some_way, and so on. If the rule change,
|
||
|
|
you just delete the abstraction in the middle of the larger function.
|
||
|
|
|
||
|
|
"But that still doesn't solve it!" Well, if the business rule changed, then
|
||
|
|
you can either delete the larger function and write a new one to follows the
|
||
|
|
new rule or simply drop -- or add -- any of the abstractions.
|
||
|
|
|
||
|
|
## [22 Principles for Great Product Managers](https://reeve.blog/blog/principles/)
|
||
|
|
|
||
|
|
I didn't even get to half of the list and I was "yup, I had a hard time with a
|
||
|
|
manager that didn't do that" and "I remember when they did that and it was
|
||
|
|
awesome".
|
||
|
|
|
||
|
|
## [Syntax highlighting is a waste of an information channel](https://buttondown.email/hillelwayne/archive/syntax-highlighting-is-a-waste-of-an-information/)
|
||
|
|
|
||
|
|
Once again, "I can get behind the sentiment, but not the implementation".
|
||
|
|
Surely, having information about types, or some parameter, in the syntax helps
|
||
|
|
a ton, but the fact is that it depends on situation. At some point, the type
|
||
|
|
may be more important than the parameter, or vice-versa, or worse, it may give
|
||
|
|
focus to something that is not important at that time. Putting all that
|
||
|
|
together, at the same time, would be a nightmare -- or a fruit salad
|
||
|
|
of colours that would make reading the code and finding what matters completely
|
||
|
|
impossible.
|
||
|
|
|
||
|
|
## [Clear explanation of Rust’s module system](http://www.sheshbabu.com/posts/rust-module-system/)
|
||
|
|
|
||
|
|
Rust module system is a bit different from everything else, and the
|
||
|
|
exploration I did gave me some insights about it -- mostly, exactly what the
|
||
|
|
post says.
|