Merge branch 'release/20191230.2'

config.toml

@@ -15,6 +15,8 @@ taxonomies = [
 	# You can enable/disable RSS
 	{name = "categories", rss = true},
 	{name = "tags", rss = true},
+	{name = "tags", lang = "en"},
+	{name = "tags", lang = "pt"},
 ]
 
 generate_rss = true
@@ -39,10 +41,11 @@ author = "Julio Biason"
 logo_text = "JulioBiason.Net 4.1"
 use_full_hack_font = true
 menu_items = [
-    {url = "$BASE_URL", name = "Home"},
+    {url = "$BASE_URL", name = "English"},
+	{url = "$BASE_URL/pt/", name = "Português"},
 	{url = "$BASE_URL/announcements/about-me", name = "About Me"},
-	{url = "$BASE_URL/tags", name = "Tags"},
-	{url = "$BASE_URL/books", name = "Books"},
+	{url = "$BASE_URL/tags", name = "Tags (EN)"},
+	{url = "$BASE_URL/pt/tags", name = "Tags (PT)"},
 ]
 after_dark_title = "JulioBiason.Net 4.1"
 enable_post_view_navigation = false

content/_index.pt.md

@@ -0,0 +1,6 @@
++++
+sort_by = "date"
+
+paginate_by = 10
++++
+

content/announcements/juliobiason.net-3.0.md

@@ -1,39 +0,0 @@
-+++
-title = "Announcing JulioBiason.Net 3.0"
-date = 2015-02-18
-category = "announcements"
-
-[taxonomies]
-tags = ["meta", "blog", "pelican"]
-+++
-
-Short version: New blog URL, engine and layout.
-
-<!-- more -->
-
-Long version: For a long time already, I've been thinking about using a static
-blog generator. Not that there is anything wrong with dynamic blog engines (and
-I'm a long time [WordPress](https://wordpress.org/) user, without any issues,
-specially since my hosting company -- [Dreamhost](http://www.dreamhost.com/) --
-offers easy updates), but... I don't know, I think it's easy to automate some
-stuff when all you have are basic files, with no API to talk to.
-
-So, here it is. A new blog URL, so all old posts are still visible in their
-original paths (although this will be a problem in the future when I decide to
-launch a 4.0 blog, but that's a problem for the future); a new engine, as
-WordPress is not static, so I decided to go with
-[Pelican](http://blog.getpelican.com/), simply because I know Python (I know
-there is a huge community for [Jekyll](http://jekyllrb.com/), but I'm not a
-Ruby guy and I don't want to be a Ruby guy); and finally a new layout, as I
-took everything I've been playing with [Zurb
-Foundation](http://foundation.zurb.com/) and, since I'd automagically gain a
-responsive layout, I did just that. And yes, the
-[theme](https://bitbucket.org/juliobiason/pelican-fancy-foundation) is my
-creation -- and that's why there is a bunch of broken stuff. I'll be fixing
-them in the future, as I see them -- or someone reports them to me.
-
-PS: There is actually a hidden thing, some [things I don't want to deal
-again](http://juliobiason.net/2008/02/23/why-half-life-2-failed/), which could
-probably crippling me in what to write (hence why the content was so dull and
-boring in the last few months). Because static blogs don't have comments, I may
-feel fine in finally discussing them.

content/announcements/juliobiasonnet-40.md

@@ -2,6 +2,7 @@
 title = "Announcing JulioBiason.Net 4.0"
 date = 2018-11-28
 category = "announcements"
+language = "en"
 
 [taxonomies]
 tags = ["meta", "blog", "zola"]

content/code/_index.pt.md

@@ -0,0 +1,4 @@
++++
+title = "Code"
+transparent = true
++++

content/code/microservices-artifact-ejection.md

@@ -0,0 +1,55 @@
++++
+title = "Microservices: Artifact Ejection"
+date = 2019-12-30
+
+[taxonomies]
+tags = ["microservices", "artifacts", "connection", "ejection"]
++++
+
+As I was discussing about [artifacts in
+microservices](@/code/microservices-artifact-input-state.md), I guess I forgot to
+discuss some important point: How those artifacts are "ejected" from the
+microservice?
+
+<!-- more -->
+
+"Ejected", in this case, means "pass it to the next necessary stage", which
+can mean a lot of stuff (sometimes, more than one). Also, I needed some catchy
+word for it 'cause simply "produces" isn't that fashionable.
+
+For example, if your microservice is producing intermediate data -- say, it
+connects to an external service and retrieves information, which is then
+processed by different microservices -- then you probably want to use a
+message broker as the ejection route for the artifact. Using a message broker
+will allow another services to keep listening to the creation of those
+artifacts and do their thing -- producing new artifacts.
+
+Another possibility is that this microservice is the end of the production
+line and, thus, it just keeps the artifact in order to by consumed in a
+non-asynchronous way. For example, the microservice may produce elements that
+are later requested by a web request, so what its needs is to produce said
+artifact and keep it around, responding requests later.
+
+This, again, is akin to the way CQRS (command-query response segregation)
+works: You have one side of your microservice receiving data and processing
+its artifact, and another that allows querying the artifacts.
+
+You can even do both: When the artifact is produced, the microservice ejects
+it through a message broker to be processed by other microservices and still
+stores it internally to be queried. 
+
+There is even the possibility of the query part be just another microservice:
+It gets the artifact from another microservice and stores it, with no
+processing (if you don't count as "saves in a permanent storage" a
+processing). This is interesting 'cause the "query" part of the microservice
+is just another microservice, instead of being some sort of specialized
+microservice that produces, ejects and stores artifacts.
+
+When I mentioned we saved our artifacts in Firebase, we are basically building
+this split microservice: While we have microservices that produce the
+artifacts, the "storage and query" part is giving to Firebase -- but you can
+consider this as any other service.
+
+(This whole post is just to give some pointers on what I want to discuss next,
+which are some thoughts about self-healing microservices -- and what I meant
+by that.)

content/code/microservices-artifact-ejection.pt.md

@@ -0,0 +1,59 @@
++++
+title = "Microserviços: Expelindo Artefatos"
+date = 2019-12-30
+
+[taxonomies]
+tags = ["microserviços", "artefatos", "conexões", "expelir"]
++++
+
+Como eu estava comentando sobre [artefatos em
+microserviços](@/code/microservices-artifact-input-state.pt.md), eu acredito que esqueci
+de discutir um ponto importante: Como é que esses artefatos são "expelidos" do
+microserviço?
+
+<!-- more -->
+
+"Expelido", nesse caso, significa "passa para o próximo estágio necessário",
+que pode ser um bocado de coisas (algumas vezes, até mais de uma). E como eu
+precisava de um palavra capciosa para chamar a atenção, já que "produz" não
+tem nada de chamativo.
+
+Por exemplo, se um microserviço produz um dado intermediário -- digamos que
+ele conecta num serviço externo e busca uma informação, que é então processada
+por outros microserviços -- então você vai possivelmente utilizar um serviço
+de message broker (mensageria) para expelir o artefato. Usando um message
+broker irá permitir que outros serviços fiquem escutando a criação desses
+artefatos e que façam seu serviço -- produzindo novos artefatos.
+
+Outra possibilidade é que esse microserviço é o fim da linha de produção e,
+por isso, ele mantém o artefato consigo para ser consumido de uma forma
+não assíncrona. Por exemplo, o microserviço produz elementos que são pedidos
+depois uma requisição de um serviço web, e o que o microserviço precisa fazer
+é produzir o artefato e mantê-lo em si, respondendo requisições mais tarde.
+
+De novo, isso é semelhante a forma com que CQRS (command-query response
+segregation -- segregação de comandos e queries) funciona: Você tem um lado do
+seu microserviço que recebe dados e processa o artefato, e outro que permite a
+consulta dos artefatos gerados.
+
+Você pode até mesmo ter os dois: Quando o artefato é produzido, o microserviço
+expele o mesmo pelo message broker para ser processado por outros
+microserviços, e guarda o artefato localmente para ser pesquisado depois.
+
+Existe até mesmo a possibilidade da parte de pesquisa/query ser apenas outros
+microserviço: Ele recebe o artefato de outro microserviço e o armazena, sem
+qualquer processamento (desde que você não considere "salva num armazenamento
+permanente" uma forma de processamento). Isso é interessante porque a parte de
+pesquisa/query do microserviço é apenas um outro microserviço ao invés de ser
+uma espécie de microserviço especializado que produz, expele e armazena
+artefatos.
+
+Quando eu mencionando que nós salvamentos nossos artefatos no Firebase, nós
+estamos basicamente construindo esse microserviço separado: Enquanto nossos
+microserviços produzem artefatos, a parte de "armazenamento e pesquisa" fica a
+cargo do Firebase -- mas você pode considerar isso como qualquer outro
+microserviço.
+
+(Esse post é simplesmente para ter alguns ponteiros a mais para quando eu for
+discutir um pouco mais sobre o que eu penso sobre microserviços com auto-cura
+-- e o que eu quero dizer com isso.)

content/code/on-unittests-and-layers-2.md

@@ -13,7 +13,7 @@ about "Fast Test, Slow Test".
 <!-- more -->
 
 Just after posting about 
-[who one could see the layers through unit testing](./code/on-unittests-and-layers.md),
+[who one could see the layers through unit testing](@/code/on-unittests-and-layers.md),
 I finally watched a video of Gary
 Bernhardt (of the "DestroyAllSoftware" fame) about "Fast Test, Slow Test":
 

content/presentations/_index.pt.md

@@ -0,0 +1,4 @@
++++
+transparent = true
+title = "Presentation Companion Posts"
++++

content/reviews/_index.pt.md

@@ -0,0 +1,4 @@
++++
+transparent = true
+title = "Reviews"
++++

content/reviews/books/_index.pt.md

@@ -0,0 +1,4 @@
++++
+transparent = true
+title = "Book Reviews"
++++

themes/terminimal-light

@@ -1 +1 @@
-Subproject commit 233094db73eaa0772d2964d3d409643f08c0a207
+Subproject commit fb4dc98c110410db69be40dad262b85c4873b9e3