danilobatistaqueiroz

Essa lista foi criada baseada em centenas de séries completas tais como (todos os episódios de Friends, Simpsons, The Big Bang Theory, Small Ville, Walking Dead, Lost, CSI, etc)
Também foram usadas legendas de filmes, podcasts e canais do Youtube, tais como (todo os episódios de MrBeast, The Joe Rogan Experience, The Tonight Show, etc)
Letras de músicas, centenas de episódios de reportagens de Fox News, CBN.
São 1.800 seasons de séries. Mais de 300 séries completas. São quase 40.000 legendas com média de 20 minutos. O que equivale a 13.000 horas de streaming. Isso equivale a 36 anos de conversas o dia todo.

Foi gerada uma lista inicial com as 50.000 palavras mais usadas no dia-a-dia falado no inglês, dessa lista foram removidas as 15.000 palavras mais comuns do inglês, palavras essas que são facilmente encontradas em listas tal como a de Oxford online, e que qualquer um com um inglês intermediário entende. (inclui-se aí, palavras como as constituídas no verbo to be, work, make, números, cores, palavra

danilobatistaqueiroz

## Effective Java, 2nd Edition

by Joshua Bloch

*I, [Michael Parker](http://omgitsmgp.com/), own this book and took these notes to further my own learning. If you enjoy these notes, please [purchase the book](http://www.amazon.com/Effective-Java-Edition-Joshua-Bloch/dp/0321356683)!*

### Chapter 2: Creating and Destroying Objects

#### Item 1: Consider static factories instead of constructors
* An instance-controlled class is one that uses static factories to strictly control what instances exist at any time.

danilobatistaqueiroz

The heart of software

• Leaders within a team who understand the centrality of the domain can put their software project back on course.
• Software developer is like a researche, both have the responsability to tackle the messiness of the real world through complicated domain that has never been formalized.
• There are systematic ways of thinking that developers can employ to search for insight and produce effective models.

One. Crunching Knowledge

Ingredients of effective modeling

danilobatistaqueiroz

Kanban

Kanban [com K maiúsculo], foi criado por Taiichi Ohno (Toyota),
é um sistema de controle da cadeia logística de produção e do estoque de insumos que este sistema necessita.

O Kanban (JIT – Toyota) não é exatamente o Kanban (LeanKanban – David Anderson).

Kanban para desenvolvimento de software foi um conceito trazido por David Anderson, com contribuições de Corey Ladas (Scrumban) adaptado para o ecossistema de TI.

Quando falamos de Kanban em desenvolvimento de software, existem 3 elementos básicos:

danilobatistaqueiroz

To get optimal performance, make sure your queues stay as short as possible all the time.
Longer queues impose more processing overhead.
We recommend that queues should always stay around 0 for optimal performance.

Em cenários com muitos consumers e publishers, o ideal é centralizar a criação de exchanges e queues, removendo essa permissão deles e fazendo essa gestão por uma equipe de admin.

Para garantir a entrega das mensagens o correto é usar consumer ack, broker ack e durable queue com persistent messages.
Pode-se utilizar quorum queues dependendo do cenário.

danilobatistaqueiroz

#/bin/sh

speed="0.7"

mkdir "speed-${speed}x"

for f in *.mp3
  do ffmpeg -i "$f" -filter:a "atempo=${speed}" "./speed-${speed}x/$f"
done

danilobatistaqueiroz

{
    "type": "response",
    "@timestamp": "2021-09-12T22:53:33+00:00",
    "tags": [],
    "pid": 1216,
    "method": "get",
    "statusCode": 400,
    "req": {
        "url": "/api/monitoring/v1/elasticsearch_settings/check/nodes",
        "method": "get",

danilobatistaqueiroz

WORKING EFFECTIVELY WITH LEGACY CODE

To me, legacy code is simply code without tests. I’ve gotten some grief for this definition. What do tests have to do with whether code is bad? To me, the answer is straightforward, and it is a point that I elaborate throughout the book: Code without tests is bad code. It doesn’t matter how well written it is; it doesn’t matter how pretty or object-oriented or well-encapsulated it is. With tests, we can change the behavior of our code quickly and verifiably. Without them, we really don’t know if our code is getting better or worse.

Chapter 1 Changing Software

Four Reasons to Change Software: For simplicity’s sake, let’s look at four primary reasons to change software.

danilobatistaqueiroz

#!/bin/sh
set -o errexit

# create registry container unless it already exists
reg_name='kind-registry'
reg_port='5000'
running="$(docker inspect -f '{{.State.Running}}' "${reg_name}" 2>/dev/null || true)"
if [ "${running}" != 'true' ]; then
  docker run \
    -d --restart=always -p "${reg_port}:5000" --name "${reg_name}" \

danilobatistaqueiroz

Code is clean if it can be understood easily – by everyone on the team. Clean code can be read and enhanced by a developer other than its original author. With understandability comes readability, changeability, extensibility and maintainability.

---

General rules

1. Follow standard conventions.
2. Keep it simple stupid. Simpler is always better. Reduce complexity as much as possible.
3. Boy scout rule. Leave the campground cleaner than you found it.
4. Always find root cause. Always look for the root cause of a problem.

Design rules