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.
159 lines
8.2 KiB
159 lines
8.2 KiB
11 months ago
|
<!DOCTYPE html>
|
||
|
<html lang="en">
|
||
|
<head>
|
||
|
<meta http-equiv="X-UA-Compatible" content="IE=edge">
|
||
|
<meta http-equiv="content-type" content="text/html; charset=utf-8">
|
||
|
|
||
|
<!-- Enable responsiveness on mobile devices-->
|
||
|
<!-- viewport-fit=cover is to support iPhone X rounded corners and notch in landscape-->
|
||
|
<meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1, viewport-fit=cover">
|
||
|
|
||
|
<title>Julio Biason .Me 4.3</title>
|
||
|
|
||
|
<!-- CSS -->
|
||
|
<link rel="stylesheet" href="https://blog.juliobiason.me/print.css" media="print">
|
||
|
<link rel="stylesheet" href="https://blog.juliobiason.me/poole.css">
|
||
|
<link rel="stylesheet" href="https://blog.juliobiason.me/hyde.css">
|
||
|
<link rel="stylesheet" href="https://fonts.googleapis.com/css?family=PT+Sans:400,400italic,700|Abril+Fatface">
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
</head>
|
||
|
|
||
|
<body class=" ">
|
||
|
|
||
|
<div class="sidebar">
|
||
|
<div class="container sidebar-sticky">
|
||
|
<div class="sidebar-about">
|
||
|
|
||
|
<a href="https://blog.juliobiason.me"><h1>Julio Biason .Me 4.3</h1></a>
|
||
|
|
||
|
<p class="lead">Old school dev living in a 2.0 dev world</p>
|
||
|
|
||
|
|
||
|
</div>
|
||
|
|
||
|
<ul class="sidebar-nav">
|
||
|
|
||
|
|
||
|
<li class="sidebar-nav-item"><a href="/">English</a></li>
|
||
|
|
||
|
<li class="sidebar-nav-item"><a href="/pt">Português</a></li>
|
||
|
|
||
|
<li class="sidebar-nav-item"><a href="/tags">Tags (EN)</a></li>
|
||
|
|
||
|
<li class="sidebar-nav-item"><a href="/pt/tags">Tags (PT)</a></li>
|
||
|
|
||
|
|
||
|
</ul>
|
||
|
</div>
|
||
|
</div>
|
||
|
|
||
|
|
||
|
<div class="content container">
|
||
|
|
||
|
<div class="post">
|
||
|
<h1 class="post-title">Commented Links for 2020-07-26</h1>
|
||
|
<span class="post-date">
|
||
|
2020-07-26
|
||
|
|
||
|
<a href="https://blog.juliobiason.me/tags/links/">#links</a>
|
||
|
|
||
|
<a href="https://blog.juliobiason.me/tags/datomic/">#datomic</a>
|
||
|
|
||
|
<a href="https://blog.juliobiason.me/tags/advice/">#advice</a>
|
||
|
|
||
|
<a href="https://blog.juliobiason.me/tags/developer/">#developer</a>
|
||
|
|
||
|
<a href="https://blog.juliobiason.me/tags/google/">#google</a>
|
||
|
|
||
|
<a href="https://blog.juliobiason.me/tags/racism/">#racism</a>
|
||
|
|
||
|
<a href="https://blog.juliobiason.me/tags/logging/">#logging</a>
|
||
|
|
||
|
<a href="https://blog.juliobiason.me/tags/delete/">#delete</a>
|
||
|
|
||
|
<a href="https://blog.juliobiason.me/tags/product-manager/">#product manager</a>
|
||
|
|
||
|
<a href="https://blog.juliobiason.me/tags/syntax-highlight/">#syntax highlight</a>
|
||
|
|
||
|
<a href="https://blog.juliobiason.me/tags/highlight/">#highlight</a>
|
||
|
|
||
|
<a href="https://blog.juliobiason.me/tags/rust/">#rust</a>
|
||
|
|
||
|
<a href="https://blog.juliobiason.me/tags/modules/">#modules</a>
|
||
|
|
||
|
</span>
|
||
|
<p>Datomic Internals, Developer Advice, Racism@Google, Logging, Code To Delete,
|
||
|
Being a Product Manager, Syntax Highlight, Rust Module System.</p>
|
||
|
<span id="continue-reading"></span><h2 id="unofficial-guide-to-datomic-internals"><a href="https://tonsky.me/blog/unofficial-guide-to-datomic-internals/">Unofficial guide to Datomic internals</a></h2>
|
||
|
<p>Database internals are always curious, to say the least. And Datomic is also a
|
||
|
curious database, as everything is immutable. </p>
|
||
|
<p>But understating internals is always good to understand where the database
|
||
|
fits and how to take most of it.</p>
|
||
|
<h2 id="advice-to-myself-when-starting-out-as-a-software-developer"><a href="https://blog.pragmaticengineer.com/advice-to-myself-when-starting-as-a-software-developer/">Advice to Myself When Starting Out as a Software Developer</a></h2>
|
||
|
<p>When you're working in the field for too long, it is easy to forget how it was
|
||
|
when you started.</p>
|
||
|
<p>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.</p>
|
||
|
<h2 id="google-ad-portal-equated-black-girls-with-porn"><a href="https://themarkup.org/google-the-giant/2020/07/23/google-advertising-keywords-black-girls">Google Ad Portal Equated “Black Girls” with Porn</a></h2>
|
||
|
<p>Oh, are you saying Google is racist? That's impossible! That's "the algorithm"
|
||
|
fault! Google is good, it gives me free email!</p>
|
||
|
<p>You see how "giving things for free" and "open source" (and then not listening
|
||
|
to users) is purely a marketing plot?</p>
|
||
|
<h2 id="good-logging"><a href="https://henrikwarne.com/2020/07/23/good-logging/">Good Logging</a></h2>
|
||
|
<p>Logging is always important -- personally, I think logging (and good logs) are
|
||
|
more important than debugging -- but knowing <em>how</em> and <em>what</em> to log is the
|
||
|
key for properly dealing with it.</p>
|
||
|
<p>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.</p>
|
||
|
<p>Personally, I leave a lot of <code>debug</code> messages in some places, as "scars" of a
|
||
|
battle. Maybe some future developer will see that sequence and think twice
|
||
|
before jumping in.</p>
|
||
|
<h2 id="write-code-that-is-easy-to-delete-not-easy-to-extend"><a href="https://programmingisterrible.com/post/139222674273/write-code-that-is-easy-to-delete-not-easy-to">Write code that is easy to delete, not easy to extend.</a></h2>
|
||
|
<p>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.</p>
|
||
|
<p>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 <em>exactly</em> 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.</p>
|
||
|
<p>"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.</p>
|
||
|
<h2 id="22-principles-for-great-product-managers"><a href="https://reeve.blog/blog/principles/">22 Principles for Great Product Managers</a></h2>
|
||
|
<p>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".</p>
|
||
|
<h2 id="syntax-highlighting-is-a-waste-of-an-information-channel"><a href="https://buttondown.email/hillelwayne/archive/syntax-highlighting-is-a-waste-of-an-information/">Syntax highlighting is a waste of an information channel</a></h2>
|
||
|
<p>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.</p>
|
||
|
<h2 id="clear-explanation-of-rust-s-module-system"><a href="http://www.sheshbabu.com/posts/rust-module-system/">Clear explanation of Rust’s module system</a></h2>
|
||
|
<p>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.</p>
|
||
|
|
||
|
</div>
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
</div>
|
||
|
|
||
|
</body>
|
||
|
|
||
|
</html>
|