From 95894a8849f11fc3b1f26219ee9238bc797476cf Mon Sep 17 00:00:00 2001 From: Julio Biason Date: Mon, 30 Dec 2019 18:33:20 -0300 Subject: [PATCH 1/4] Further multilingual support --- config.toml | 2 + content/_index.pt.md | 6 +++ content/announcements/juliobiason.net-3.0.md | 39 ------------------- ...biason.net-4.0.md => juliobiasonnet-40.md} | 1 + content/code/_index.pt.md | 4 ++ content/code/on-unittests-and-layers-2.md | 2 +- content/presentations/_index.pt.md | 4 ++ content/reviews/_index.pt.md | 4 ++ content/reviews/books/_index.pt.md | 4 ++ 9 files changed, 26 insertions(+), 40 deletions(-) create mode 100644 content/_index.pt.md delete mode 100644 content/announcements/juliobiason.net-3.0.md rename content/announcements/{juliobiason.net-4.0.md => juliobiasonnet-40.md} (97%) create mode 100644 content/code/_index.pt.md create mode 100644 content/presentations/_index.pt.md create mode 100644 content/reviews/_index.pt.md create mode 100644 content/reviews/books/_index.pt.md diff --git a/config.toml b/config.toml index f163401..1502291 100644 --- a/config.toml +++ b/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 diff --git a/content/_index.pt.md b/content/_index.pt.md new file mode 100644 index 0000000..6663c55 --- /dev/null +++ b/content/_index.pt.md @@ -0,0 +1,6 @@ ++++ +sort_by = "date" + +paginate_by = 10 ++++ + diff --git a/content/announcements/juliobiason.net-3.0.md b/content/announcements/juliobiason.net-3.0.md deleted file mode 100644 index 0b8103c..0000000 --- a/content/announcements/juliobiason.net-3.0.md +++ /dev/null @@ -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. - - - -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. diff --git a/content/announcements/juliobiason.net-4.0.md b/content/announcements/juliobiasonnet-40.md similarity index 97% rename from content/announcements/juliobiason.net-4.0.md rename to content/announcements/juliobiasonnet-40.md index ef5dcf9..a44af59 100644 --- a/content/announcements/juliobiason.net-4.0.md +++ b/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"] diff --git a/content/code/_index.pt.md b/content/code/_index.pt.md new file mode 100644 index 0000000..36c4916 --- /dev/null +++ b/content/code/_index.pt.md @@ -0,0 +1,4 @@ ++++ +title = "Code" +transparent = true ++++ diff --git a/content/code/on-unittests-and-layers-2.md b/content/code/on-unittests-and-layers-2.md index 169b5bb..443fb27 100644 --- a/content/code/on-unittests-and-layers-2.md +++ b/content/code/on-unittests-and-layers-2.md @@ -13,7 +13,7 @@ about "Fast Test, Slow Test". 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": diff --git a/content/presentations/_index.pt.md b/content/presentations/_index.pt.md new file mode 100644 index 0000000..8fd8769 --- /dev/null +++ b/content/presentations/_index.pt.md @@ -0,0 +1,4 @@ ++++ +transparent = true +title = "Presentation Companion Posts" ++++ diff --git a/content/reviews/_index.pt.md b/content/reviews/_index.pt.md new file mode 100644 index 0000000..7393df5 --- /dev/null +++ b/content/reviews/_index.pt.md @@ -0,0 +1,4 @@ ++++ +transparent = true +title = "Reviews" ++++ diff --git a/content/reviews/books/_index.pt.md b/content/reviews/books/_index.pt.md new file mode 100644 index 0000000..c9c1dfb --- /dev/null +++ b/content/reviews/books/_index.pt.md @@ -0,0 +1,4 @@ ++++ +transparent = true +title = "Book Reviews" ++++ From 82742c77b05a47010e36df642eb4214729eaccf9 Mon Sep 17 00:00:00 2001 From: Julio Biason Date: Mon, 30 Dec 2019 18:48:01 -0300 Subject: [PATCH 2/4] Also break the tags/home into languages --- config.toml | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/config.toml b/config.toml index 1502291..495eff9 100644 --- a/config.toml +++ b/config.toml @@ -41,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 From c8468dc66762f8357bf680924bbebbdfb6f0f96b Mon Sep 17 00:00:00 2001 From: Julio Biason Date: Mon, 30 Dec 2019 18:48:53 -0300 Subject: [PATCH 3/4] New blog post: Artifact ejection --- .../code/microservices-artifact-ejection.md | 55 +++++++++++++++++ .../microservices-artifact-ejection.pt.md | 59 +++++++++++++++++++ 2 files changed, 114 insertions(+) create mode 100644 content/code/microservices-artifact-ejection.md create mode 100644 content/code/microservices-artifact-ejection.pt.md diff --git a/content/code/microservices-artifact-ejection.md b/content/code/microservices-artifact-ejection.md new file mode 100644 index 0000000..4145500 --- /dev/null +++ b/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? + + + +"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.) diff --git a/content/code/microservices-artifact-ejection.pt.md b/content/code/microservices-artifact-ejection.pt.md new file mode 100644 index 0000000..7877e3f --- /dev/null +++ b/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? + + + +"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.) From c8f593c0b747cf98dac10f41bc11027e8c48e8b7 Mon Sep 17 00:00:00 2001 From: Julio Biason Date: Mon, 30 Dec 2019 18:51:19 -0300 Subject: [PATCH 4/4] Updated theme with multilingual tags --- themes/terminimal-light | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/themes/terminimal-light b/themes/terminimal-light index 233094d..fb4dc98 160000 --- a/themes/terminimal-light +++ b/themes/terminimal-light @@ -1 +1 @@ -Subproject commit 233094db73eaa0772d2964d3d409643f08c0a207 +Subproject commit fb4dc98c110410db69be40dad262b85c4873b9e3