Browse Source

Merge branch 'release/20191230.2'

master 20191230.2
Julio Biason 5 years ago
parent
commit
d5f7e4c339
  1. 9
      config.toml
  2. 6
      content/_index.pt.md
  3. 39
      content/announcements/juliobiason.net-3.0.md
  4. 1
      content/announcements/juliobiasonnet-40.md
  5. 4
      content/code/_index.pt.md
  6. 55
      content/code/microservices-artifact-ejection.md
  7. 59
      content/code/microservices-artifact-ejection.pt.md
  8. 2
      content/code/on-unittests-and-layers-2.md
  9. 4
      content/presentations/_index.pt.md
  10. 4
      content/reviews/_index.pt.md
  11. 4
      content/reviews/books/_index.pt.md
  12. 2
      themes/terminimal-light

9
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

6
content/_index.pt.md

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

39
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.

1
content/announcements/juliobiason.net-4.0.md → 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"]

4
content/code/_index.pt.md

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

55
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.)

59
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.)

2
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":

4
content/presentations/_index.pt.md

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

4
content/reviews/_index.pt.md

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

4
content/reviews/books/_index.pt.md

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

2
themes/terminimal-light

@ -1 +1 @@
Subproject commit 233094db73eaa0772d2964d3d409643f08c0a207
Subproject commit fb4dc98c110410db69be40dad262b85c4873b9e3
Loading…
Cancel
Save