[PUBLISHER] Merge #2

* PUSH NOTE : my-digital-workbench.md

* PUSH NOTE : about.md

* PUSH NOTE : Article, Software Complexity - Naming.md

* PUSH ATTACHMENT : naming.png

* PUSH ATTACHMENT : couch-in-what-room.png

* PUSH ATTACHMENT : toilet-in-what-room.png

* PUSH ATTACHMENT : toilet-bed.png

* PUSH ATTACHMENT : clarity-vs-relation.png

* PUSH ATTACHMENT : car-http.png

* PUSH ATTACHMENT : builders.png

* PUSH ATTACHMENT : base.png

* PUSH ATTACHMENT : arc.png

* PUSH ATTACHMENT : divide-and-name.png

* PUSH ATTACHMENT : compound-concepts.png

* PUSH ATTACHMENT : abstract-canvas.png

* PUSH ATTACHMENT : contexts.png

* PUSH NOTE : Article, Derisk.md

obsidian/_pages/about.md

@@ -0,0 +1,26 @@
+---
+share: true
+title: About
+image: '/images/pages/about2.jpg'
+filename: '_pages/about'
+rss: false
+date: 2020-01-02 15:02:54 -0200
+---
+
+Hi 👋 I'm Alex Oliveira. 👨‍💻 I make software. 
+
+For over 15 years, as an engineer, systems architect and engineering lead, I
+coded and led teams in:
+
+<ul class="no-bullets">
+  <li> 🛍 e-commerce platforms</li>
+  <li> 🏦 banking systems</li>
+  <li> 💳 credit card gateways/storage</li>
+  <li> 🗣 advertising services</li>
+  <li> 🚕 geolocated ridesharing apps</li>
+  <li> 🚌 transportation platforms</li>
+  <li> 💰 fintechs</li>
+  <li> 💻 software intelligence</li>
+</ul>
+
+I spoke at RubyConfs, Euruko, universities, and more.

obsidian/essay/_posts/2017-04-05-software-naming.md

@@ -1,14 +1,14 @@
 ---
-layout: post
+share: true
 title: "Software Complexity: Naming"
 date: 2017-04-05 15:02:54 -0200
+filename: "essay/_posts/2017-04-05-software-naming"
 tags: [software]
-redirect_from: software-naming
 # front_page_image: '/images/posts/black-boxes/cover.png'
 excerpt: "Code is written once but read many times. Good writing is, therefore, about optimizing for ease of reading."
 ---
 
-![The Magic Acid, or the art of naming](../images/posts/software-naming/naming.png)
+![The Magic Acid, or the art of naming](../../images/naming.png)
 
 > There are only two hard things in Computer Science: cache invalidation and naming things.
 >
@@ -41,7 +41,7 @@ To illustrate our first concept, let's start simple. Given the picture below, wh
 <br />
 <br />
 
-![A couch, what room does it belong to?](../images/posts/software-naming/couch-in-what-room.png)
+![A couch, what room does it belong to?](../../images/couch-in-what-room.png)
 
 <br />
 <br />
@@ -53,7 +53,7 @@ Judging from this furniture, this is very likely to be a **living room**. Based
 <br />
 <br />
 
-![A toilet, what room does it belong to?](../images/posts/software-naming/toilet-in-what-room.png)
+![A toilet, what room does it belong to?](../../images/toilet-in-what-room.png)
 
 <br />
 <br />
@@ -77,7 +77,7 @@ Pretty obvious, but now that we have some rules, let's try to apply them to this
 <br />
 <br />
 
-![What room has a toilet and a bed?](../images/posts/software-naming/toilet-bed.png)
+![What room has a toilet and a bed?](../../images/toilet-bed.png)
 
 <br />
 <br />
@@ -92,7 +92,7 @@ At home, we put together things that have the same function, purpose and intent.
 
 This is hard to read, so let's use a picture:
 
-![Clarity vs relation](../images/posts/software-naming/clarity-vs-relation.png)
+![Clarity vs relation](../../images/clarity-vs-relation.png)
 
 When components are related, it's easier to find a good name. When things are unrelated, it becomes increasingly difficult. The word relation here could be their functionality, their purpose, their strategy, their type, and others. Relation on its own doesn't mean much until we talk about criteria. Bear with me here, and we'll get to that soon.
 
@@ -126,13 +126,13 @@ public interface WhatIsAGoodNameForThis {
 }
 ```
 
-![](../images/posts/software-naming/car-http.png)
+![](../../images/car-http.png)
 
 **Example 2: Coupling through words**
 
 A common pattern is appending Builder and other Er-ending words in class names. SomethingBuilder. UserBuilder, AccountBuilder, AccountCreator, UserHelper, JobPerformer.
 
-![](../images/posts/software-naming/builders.png)
+![](../../images/builders.png)
 
 Judging by the name, we can interpret three things. First, the verb _Build_ in the class name implies that it's a function, when in fact it’s in the class title. Functions do stuff, classes embody entities and context. A function is not an entity, and without entities well defined the codebase quickly develops into procedural code because it’s sub-utilizing the class pattern’s original intention.
 
@@ -155,7 +155,7 @@ class Base
 end
 ```
 
-![](../images/posts/software-naming/base.png)
+![](../../images/base.png)
 
 Here, `Base` doesn't express meaning. It can configure and translate, as well as figure out whether a locale is available or not. It's doing a few different, unrelated things.
 
@@ -228,11 +228,11 @@ export default function() {
 
 Each one of these methods make total sense: they are all named after what an arc has. And what I love about the image below is how simple it is.
 
-![](../images/posts/software-naming/arc.png)
+![](../../images/arc.png)
 
 ### Method 1: Break Apart
 
-![Divide and... name](../images/posts/software-naming/divide-and-name.png)
+![Divide and... name](../../images/divide-and-name.png)
 
 <br />
 **When to use:** you cannot find a good name for a class or component, but you already have isolated concepts and want to find good names for their groupings.
@@ -254,7 +254,7 @@ When the code is hard, don't think about the whole first. Don't. Think about the
 
 ### Method 2: Discover New Concepts
 
-![Compound concept](../images/posts/software-naming/compound-concepts.png)
+![Compound concept](../../images/compound-concepts.png)
 
 **When to apply:** when a class is not simple or coherent.
 
@@ -286,7 +286,7 @@ After launch, our customers always referred to trips as `rides`. Soon we had pro
 
 **Example 3: levels of abstraction**
 
-![](../images/posts/software-naming/abstract-canvas.png)
+![](../../images/abstract-canvas.png)
 
 One person says, *move right leg then left leg then right leg*, other says *walk*. Both mean the same, but the latter is said to be more abstract.
 
@@ -322,7 +322,7 @@ Based on the document format, a variety of subsequent decisions will be made aut
 
 Every app has a different context, and every module within it, every class within them, down to every function. The word _User_ alone could mean user of the system, but also perhaps a database table, or a 3rd-party service credential. `lib/billing/user` differs from `lib/booking/user`, but they're still `user`.
 
-![](../images/posts/software-naming/contexts.png)
+![](../../images/contexts.png)
 
 Imagine that every container, such as a module, is a bucket. Within them, components are insulated from the outer world. You're free to name those classes whatever you want. It frees the mind from having to find esoteric names for common things.
 
@@ -354,7 +354,7 @@ In practice, they're lumped together in an unnatural grouping to provide reusabi
 
 **Base:** classes named _Base_ were a convention a long time ago in C# to designate inheritance when lacking a better name. For example, the parent class of _Automobile_ and _Bicycle_ would be _Base_ instead of _Vehicle_. In spite of Microsoft's recommendations to avoid that name (Cwalina, 2009), it infected the Ruby world, most notable via _ActiveRecord_. To this day we still see _Base_ as a class name for something that developers cannot find a name for.
 
-![](../images/posts/software-naming/base.png)
+![](../../images/base.png)
 
 Variations of _Base_ include _Common_ and _Utils_. The [JSON](https://github.com/flori/json/blob/65297fbae1e92e26fdde886fe156bac322977db2/lib/json/common.rb) Ruby gem _Common_ class has the methods _parse_, _generate_, _load_ and _jj_, for instance, but what does common really mean here?
 
@@ -378,4 +378,4 @@ With writing, we optimize for reading and the exercise in empathy can be exhaust
 
 Cwalina, Krzysztof. 2009. _Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries, Second Edition_. Boston: Pearson Education, Inc. 206.
 
-Evans, Eric. 2003. _Domain-Driven Design: Tackling Complexity in the Heart of Software_. Boston: Addison-Wesley Professional.
+Evans, Eric. 2003. _Domain-Driven Design: Tackling Complexity in the Heart of Software_. Boston: Addison-Wesley Professional.

obsidian/essay/_posts/2022-03-13-derisk.md

@@ -1,13 +1,14 @@
 ---
+share: true
+layout: post
 title: "Derisk"
-published: true
-date: 2022-03-13 16:00:00 -0300
+date: "2022-03-13 16:00:00 -0300"
+filename: "essay/_posts/2022-03-13-derisk"
 tags: [risk management, risks]
-redirect_from: /derisk
-# front_page_image: '/images/posts/black-boxes/cover.png'
-excerpt: "If I had to point out one skill that differentiates great makers, professionals and executives I worked with, it would be _deliberate derisking_.  Everybody does it to some extent, but rarely as a constant discipline. It drives success and, once in motion, molds thinking and triggers valuable practices in all areas of life."
+excerpt: "If I had to point out one skill that differentiates great makers, professionals and executives I worked with, it would be _deliberate derisking_. Everybody does it to some extent, but rarely as a constant discipline. It drives success and, once in motion, molds thinking and triggers valuable practices in all areas of life."
 ---
 
+
 If I had to point out one skill that differentiates great makers I worked with, it would be _deliberate derisking_. Everybody does it to some extent, but rarely as a constant discipline. It drives success and, once in motion, molds thinking and triggers valuable practices in all areas of life.
 
 In short, you derisk by identifying future, expensive problems early on and finding ways to circumvent them. It is asking yourself, how could this go wrong? It's asking yourself whether your wallet is in your pocket when you're leaving the coffee shop, or getting reviews on your paper before you publish it. It's thinking about knowns and unknowns before you invest your time. 
@@ -72,4 +73,4 @@ The earliest you derisk, the higher the chance of success. Any late derisking ge
 
 Derisking works alike in personal and work environments, and it's mildly baked into our everyday life to the point we automate it. You look before you cross the street despite the semaphores. You check your tires before traveling despite the sensors being green. You check the destination's weather despite it being summer. You set up Alexa to close windows automatically.
 
-Now make it deliberate.
+Now make it deliberate.

obsidian/my-digital-workbench.md

@@ -0,0 +1,9 @@
+---
+share: true
+---
+
+This is a test.
+
+Link test: [Article, Derisk]({% link  obsidian/essay/_posts/2022-03-13-derisk.md %})
+
+Link test with alt: [Display text]({% link  obsidian/essay/_posts/2022-03-13-derisk.md %})