Controlador de temperatura da água utilizando Arduino

Este tutorial tem a intenção de mostrar como construir passo a passo um dispositivo capaz de controlar a temperatura da água por meio de uma conexão bluetooth, utilizando o Arduíno.

O mesmo foi desenvolvido na disciplina “CEA580 – Microprocessadores e Microcontroladores” do curso de Engenharia de Computação na Universidade Federal de Ouro Preto – UFOP, em conjunto com os meus amigos Wisley e Rafael.

Requisitos para construção do projeto

Lista dos Materiais usados:

  • Arduíno Uno ATMEGA 16U2
  • Fios para as ligações entre os componentes
  • 2 Módulos Rele 5V
  • Display 16×2 com backlight
  • Módulo Bluetooh HC05
  • Sensor de temperatura DS18B20 (específico para água)
  • Plug Fêmea (para ligar o Ebulidor)
  • Ebulidor para esquentar a água
  • Cooler para resfriar a água
  • Protoboard
  • Software para celular

Bibliotecas necessárias:

  • Arduíno
    • “OneWire.h” (Para o sensor de temperatura)
    • “LiquidCrystal.h” (Para o display)



Primeiramente a montagem do circuito começa pela inclusão do display onde alguns pinos do mesmo são ligados em portas do Arduíno pré definidas pelo projetista. O display possui alguns pinos específicos para o seu funcionamento inicial.

A descrição da pinagem do display segue na tabela abaixo:

Pinagem Display

O Arduíno utilizado no projeto possui limitações de portas, onde é necessário o uso do display em funcionamento de 4 bits. Devido essa limitação os pinos do display utilizados foram:

Pinos do Display Função Pinos Arduíno
1 Fonte de alimentação VCC 5V
2 Fonte de alimentação GND
3 Controle de contraste GND
4 Habilita/desab. Seletor de Registrador Pino 7
5 Leitura/Escrita no LCD GND
6 Habilita Escrita no LCD Pino 6
7 Dado 0 Não utilizado
8 Dado 1 Não utilizado
9 Dado 2 Não utilizado
10 Dado 3 Não utilizado
11 Dado 4 Pino 5
12 Dado 5 Pino 4
13 Dado 6 Pino 3
14 Dado 7 Pino 2
15 Alimentação da luz de fundo do LCD Uso de resistência
16 Alimentação da luz de fundo do LCD GND

As resistências utilizadas no pino 15 do display são para deixar a luminosidade do fundo do display definida.

Módulo Bluetooth

O modulo Bluetooth possui pinos abaixo descritos e suas seguintes ligações com o Arduíno seguindo a tabela abaixo:

Pinos Função Pinos Arduíno
VCC Alimentação Vcc 3,3 V
GND Alimentação GND
TXD Comunicação de Dados Pino 0 (Rx)
RXD Comunicação de Dados Pino 1 (Tx)
KEY Não Utilizado
LED Não Utilizado

Sensor de temperatura

O sensor de temperatura utilizado foi o DS18b20 que possui 3 pinos sendo os pinos vermelho e preto para alimentação e o amarelo de dados. Seguindo o Datasheet do sensor, o pino de dados deve ser ligado um resistência de 4.7 kΩ em paralelo com o VCC e o pino de dados também é conectado a porta 8 do Arduíno.

Módulo Rele

São utilizados dois módulos rele, onde possui 3 pinos sendo o pino Vcc e GND para alimentação e um pino IN que é o pino de comando para o acionamento do rele, um modulo rele é utilizado para o acionamento do circuito de aquecimento onde o pino IN desse relé  é ligado na porta 9 do Arduíno e o pino IN do rele de resfriamento é ligado na porta 10 do Arduíno.


O software utilizado para fazer a conexão com o celular através do bluetooth foi desenvolvido utilizando a plataforma MIT App Inventor 2, segue uma screenshot da aplicação desenvolvida:


Circuito básico no Arduíno


O código para Arduíno

Código no github



Custo dos componentes

Os preços em média dos componentes utilizados no projeto:

  • Arduíno Uno: R$35,00
  • 2 Módulos Rele 5V:  R$15,00 Unid.
  • Display 16×2 com backlight: R$18,00
  • Módulo Bluetooh HC05: R$45,00
  • Sensor de temperatura DS18B20: R$29,00
  • Plug Fêmea: R$3,50
  • Ebulidor: R$25,00
  • Cooler: R$15,00
  • 2 Protoboards: R$25,00 Unid.
  • Cabos: R$20,00 (65 Unid.)

Preço total do projeto: R$270,50



[mini] Hello, Rust! #1.5 – Random links

Previous post.

I’ve collected a few links and resources about the language in those last days. So this is just a small “flush” from my personal links and notes into an organized post.

  • Rosetta is a nice place to compare several programming languages, and to discover new ones too. However, I’ve found out that it is a poor place to learn about Rust in general, because most of the code in there is written in versions of Rust pre-1.0, which means that many of them don’t (won’t) compile with the current version family of Rust (1.x).
  • a pretty typical Hacker News thread. Nice comments about Rust (despite of the topic being about Golang).
  • well, Rust intends to be programmable for the Web a day. After all, Mozilla sponsors it…[1]. I don’t expect Rust to be like Rails or Python in the future in the field of web programming; instead, it will become probably something along the lines of Go.
  • this article introduces a few features about the Rust compiler. It is a good read for a typical C++ programmer. Some things in the language won’t work as expected.
  • a glance about Rust evolution over the years.
  • this guy did a series of posts about Rust, something like what I’m doing right now. However, this is from pre-1.0 — older versions of Rust [2].
  • autocompletion for your favorite text editor. It is in beta stage and does not work with a simple ‘git clone’, so I’m skipping it for now. You can test ‘cargo’ (see the previous post) with this crate, for example, to search for it or to build a release from it.
  • a tool to manage  multiple versions of rust. Ruby users might find this familiar (rbenv, rvm).
  • an [pretty tipical] awesome list of resources about Rust.

Thanks Francisco and Vinicus for a few of those links.


  • [1]: technically, it is not because of this fact; however, it contributes too.
  • [2]: also, I probably won’t write too many posts as him, as the objective is just to get an overview of the language.

Filed under: Sem categoria Tagged: challenge, Links, mini, rust

Hello, Rust! #1 – Cargo: the package manager

Continuation of this post.

Post #0 was verbose, but from now on I’ll try to go straight to the point. Comments either too verbose or out of scope will usually be placed on footnotes, like this one [1], so it’s up to you to choose if you will read them or not.

Cargo is the de-facto — and standard — rust package manager. it is not only a package manager, but a “build manager” too. So let’s analyze what this means:

(i): build manager

Think of it as C/C++ cmake, or make, or Scala’s SBT (Simple Build Tool). You can put your project metadata and its build dependencies on a file which cargo can read and do cool stuff about it. This file is Cargo.toml.

I remember seeing this TOML thing before:

It is like a JSON or a YAML file; or, even better for our analogy purposes, like a ‘.ini’ file. The contents of this file are just key/pair values, divided in sections (or subsections, if you want to call them this way).

The default Cargo.toml file that is created for me after I create a new Rust project with

cargo new --vcs git --bin sudoku

is simply

name = "sudoku"
version = "0.1.0"
authors = ["Thiago Perrotta "]

Note that the ‘authors’ value was extracted from my ~/.gitconfig file. So,

cargo build

will do pretty much what you expect. By default, it builds an executable in DEBUG mode. If you want a production version of your program, just add ‘–release’ to the previous command. Let’s look at our current directory structure now:

$ tree
├── Cargo.lock
├── Cargo.toml
├── src
│   └──
└── target
 └── debug
 ├── build
 ├── deps
 ├── examples
 ├── native
 └── sudoku

The build created the ‘target/debug’ directory. If you opted for the production version, a ‘target/release’ one would be created instead. Both can coexist at the same time. Now, if you run ‘cargo build’ again, it will finish faster than before, because there is nothing new to compile. I suppose cargo uses a mechanism similar to GNU Make, where compilations are done only if the source code is newer (in time) than its dependencies.

Okay, cargo looks like a good friend. We can do cargo {new, build, clean} and it looks enough. A tab complete on zsh or bash, however, will reveal several more subcommands that might be useful later on.  A few examples include:

  • cargo run ==> if you’re in a hurry (think of this as ‘scala main.scala’, instead of ‘scalac main.scala’)
  • cargo doc ==> we don’t have documentation yet, just a hello world
  • cargo test ==> yaaay, (unit?) test
  • cargo bench ==> this is like Golang…benchmarks
  • cargo publish ==> hmmmm…it looks like a way for us to create our own packages and maybe, later on, put them on a public repository (such as <== analogous to npm)

OK, let’s stop for now. Oh, just one more: ‘cargo search’ (!). A quick example…’cargo search regex’. It returns a few results. If you want to explore more, run ‘cargo –list’ to see all available commands.

(ii) package manager

I already said a few bits about it in the previous section: by being able to interact with the server, cargo also acts as Rust package manager. You can search for packages, download them, add them as build dependencies of your project, possibly specifying the version you want, and so on.

You can also use the same cargo command-line tool to publish packages to the official repository. It is really simple, just a matter of ‘cargo login’ first, then figuring out how to update your package ;-)

For me, it looks better than python’s pip and comparable to ruby gems and node’s npm, but it is still too early to make any judgements.

Wrapping up

Okay, so cargo looks really simple yet efficient. It reminds me of ‘lein’ for clojure and ‘sbt’ for scala: it seems to have sane defaults so the rust programmer probably won’t struggle configuring the build system — now, this doesn’t mean that he won’t struggle with the compiler…well, I guess we are set up now and can live by ourselves without an IDE, at least for managing our future project.

Next post.


  • [1]: see? Also, I’m a learner, so I’ll describe the things the way I expect them to be. However, my description won’t always be 100% correct. So pay attention if you intend to use any of this information in production.

Filed under: Sem categoria Tagged: challenge, package managers, rust

A fantástica Rust e o meu novo emprego fantástico

Minha camisa do orgulho Rust

Esse não é o primeiro post no meu blog onde menciono Rust, mas a partir de agora, as postagens sobre essa linguagem fantástica devem se tornar mais frequentes. Rust é uma linguagem de programação de sistemas e o que eu tenho para dizer, em uma linha, sobre Rust, é que eu acredito em Rust.

Muitas linguagens para diminuir erros e aumentar a produtividade foram criadas, mas elas costumam ser mais lentas. E para se sobressair e causar hype, uma abordagem de marketing recente foi criar novas linguagens afirmando que elas são linguagens de programação de sistema, apesar de serem tão produtivas quanto as linguagens mais lentas. Essas ditas linguagens de programação de sistema costumam (1) depender de um Garbage Collector e (2) produzir binários gigantes. O problema #1 as torna uma não-opção para mim e eu deixei minha crítica registrada em um texto separado. O problema #2 as impede de serem utilizadas em projetos embarcados, onde costumamos utilizar linguagens de programação de sistemas de verdade, como C.

Enfim, Rust é a linguagem de programação de sistemas que, não só afirma ser uma linguagem de programação de sistemas, como também, de fato, é uma linguagem de programação de sistemas. E ela tenta aumentar sua produtividade de duas formas:

  • Fornecendo construções comuns em linguagens de alto nível.
  • Aumentando a segurança, diminuindo o tempo que você iria passar depurando problemas.

Entretanto, para aumentar a segurança, Rust move muitos erros, que antes aconteciam em tempo de execução, para tempo de compilação. E para escrever código Rust que compile, você precisa aprender alguns conceitos que não são tão comuns. Logo, os erros diminuem, mas o tempo que você passa batalhando contra o compilador aumenta. Em outras linguagens, você ia gastar esse tempo escrevendo testes. Escrever testes ainda é legal, mas você não vai escrever testes para garantir segurança de memória e coerência de threads, porque o compilador garante isso para você. E, como o compilador garante isso para você, você vai gastar muito menos tempo ponderando se seu código faz sentido ou não, o que também aumenta a produtividade. Um depoimento que eu gosto, é o seguinte, feito por Mitchell Nordine:

I’ve found that Rust has forced me to learn many of the things that I was slowly learning as “good practise” in C/C++ before I could even compile my code. Rather than learning by trying to solve segfaults, debugging my pointer messes, etc, Rust tells me at compile time why what I’m trying to do is probably not a wise choice.

Se você simplesmente não se importa em produzir código correto, então outras linguagens ainda devem oferecer uma produtividade melhor. Claro que outra complicação na curva de aprendizado de Rust vem do fato que ela também não quer abrir mão de performance.

Eu não consigo levar a sério, linguagens que não levam performance a sério. E eu não consigo considerar o uso de linguagens que dão significado a espaço em branco (ex.: blocos definidos por identação, como em Python, mas tem até coisa pior em Haskell) ou ao estilo de capitalização dos nomes (i.e. se começar com maiúscula, é uma classe). Enfim, pela primeira vez, apareceu uma linguagem que conseguiu me fazer deixar C++ de lado. E Rust acerta muitas vezes, então a propaganda feita varia de acordo com a combinação anunciante/ouvinte.

Emprego novo

GitHub Orgs

E, para combinar com a linguagem fantástica, tenho a declarar que eu consegui um emprego fantástico, no projeto MaidSafe (que é um projeto fantástico que merece seu próprio post). Estarei trabalhando de home office e ainda irei trabalhar com assuntos que me excitam: Rust, software livre e redes descentralizadas.

Eu amei a descrição do emprego feita por um twitteiro aleatório:

“surely the most dev hipster job out there right now. @maidsafe. programming in rust, blockchain distributed ID”

Uma nota rápida: tecnicamente, eu estou trabalhando para mim mesmo, oferecendo serviços de consultoria, e o projeto MaidSafe é meu cliente. Só esclarecendo, pois não posso fazer afirmações de que trabalho para o projeto MaidSafe no sentido clássico (e é basicamente assim com o resto dos funcionários).

Eu queria ir com mais calma e terminar mais projetos antes de assumir tamanha responsabilidade, mas minha vida é simplesmente muito maluca para que eu preveja seu futuro.

Para ser honesto, o pessoal da MaidSafe é bem amigável e compreensível (pelo menos até agora), e me deu bastante liberdade para ter horários flexíveis que vão me permitir terminar projetos paralelos e continuar trabalhando no meu fantástico estágio envolvendo bindings de JavaScript para as bibliotecas EFL (tem até um rascunho de um post sobre isso que estou postergando em terminar e publicar já faz muito tempo).

E alguém importante para que eu conseguisse esse emprego foi o Francisco Lopes, por ter me convencido a fazer a entrevista, e fazer logo, aumentando minha confiança. Logo, eu devo a ele um ou quatro copos de cerveja, que pretendo pagar em algum dos encontros da lista de C/C++ Brasil.


Arquivado em:computação, pt-BR Tagged: maidsafe, off, rust

No tópico de Garbage Collector

Você quer que sua linguagem tenha Garbage Collector. Isso é uma mentira.

Você quer que sua linguagem tenha gerenciamento automático de memória. Isso ainda é uma mentira, mas pelo menos é uma mentira menor.

Você quer que sua linguagem tenha gerenciamento automático de recursos, não importando se eles são memória, file descriptors, socket descriptors ou qualquer outro. Isso NÃO é mentira.

Gerenciamento de memória (e outros recursos) seguro, automático, barato, performático e sem Garbage Collector é possível, como a linguagem Rust vem provando. Rust é a linguagem formidável que realmente se preocupa com performance e é capaz até de detectar race condition em tempo de compilação.

Problemas de usabilidade com Garbage Collector

Garbage Collectors não possuem semânticas fortes o suficiente para permitir destrutores. O mais próximo que existe são os finalizers, que possuem uma lista bem grande de possíveis problemas.

É justamente devido ao Garbage Collector e aos finalizers que você está tendo mais trabalho, tendo que gerenciar blocos finally após cada tratemento de exceção. Na verdade, eu também não acredito em tratamento de erros usando exceções (leia o link para não entender errado!).

Outros problemas com Garbage Collector

O uso de um Garbage Collector diminui a utilidade do seu programa. Se seu programa possuir requisitos de tempo real, baixa latência, sistemas embarcados, uso eficiente de bateria ou alguns outros relacionados, Garbage Collector se torna indesejável.

Uma crítica inicial a Garbage Collector é que seu programa congela aleatoriamente, prejudicando a responsividade, mas esse problema é até mais prejudicial no caso do programa ter requisitos de tempo real, pois nenhuma garantia de tempo máximo gasto com coleta de lixo é oferecida. Foram então, criados algoritmos de GC que rodam em paralelo e algoritmos incrementais de GC, permitindo o uso de GC nesses cenários, mas outros problemas persistem. Primeiro, que uma solução dessas continua a consumir mais recursos.

Outra crítica a GC é que ele é um consumidor exagerado de recursos. Se o algoritmo é paralelo, você já depende de uma segunda thread. A depender do algoritmo adotado, você já vai precisar do dobro de memória RAM que uma versão do programa sem GC. E o programa estará usando mais memória que o que precisa na maior parte do tempo, então não podemos chamá-lo de “leve”. Tudo isso contribuindo para o mal uso da bateria do dispositivo.

Mais uma crítica ao GC é que, quando ele executa, vai caminhar aleatoriamente na RAM, navegando de ponteiro em ponteiro, poluindo a cache da CPU e impedindo que você crie um programa de baixa latência, onde responsividade é importante (i.e. jogos).

Um tweeteiro aleatório me deixou ciente de um diagrama legal que pode facilmente lhe fazer pensar que talvez “C++ sempre vença no desafio de performance”. Acho tal gráfico relevante para o tema:


Eu não tenho nada para concluir de verdade. Só criei essa seção para ter a oportunidade de usar uma frase: C++ foi minha escola.


É legal ver a cara de “WTF” do Alexandrescu ao escutar o Stephan T. Lavavej falar “I don’t think garbage collection can ever solve it”.

Arquivado em:computação, pt-BR Tagged: C++, programação, rust

[mini] Novidades do AUR4


Daqui a algumas semanas esse link estará quebrado e se transformará em:

Eu ainda tenho que testá-las…mas, notei o seguinte:

  1. Co-maintainers: mais de uma pessoa vai ter permissão para atualizar os PKGBUILDs. Isso é bastante útil, principalmente para os projetos mais relevantes atualmente de lá (dropbox, chromium-pepper-flash, etc).
  2. Gerenciamento dos PKGBUILDs e da infraestrutura foi toda migrada para o Git. Vamos ver se um dia os repositórios oficiais também farão isso. Por enquanto eles utilizam subversion ainda. Talvez subversion não seja tão ruim mesmo, essa mentalidade de achar que git é bom para tudo não necessariamente está correta, certo?
  3. Keywords: os maintainers poderão incluir palavras-chaves arbitrárias associadas aos seus pacotes, para ajudá-los a serem mais facilmente encontrados nas buscas. Por sinal, as “categorias sumiram. O que é bom, já que ninguém usava aquilo direito mesmo.

Update (2015-06-18): Sobre [2], isso é um big deal. Significa que tudo que passar pelo AUR vai ficar permanentemente gravado, cada pacote com o seu próprio histórico de commits. Existe uma interface web cgit onde esse histórico pode ser visualizado — isto é, analogamente aos pacotes oficiais! No que diz respeito à infraestrutura, isso é uma enorme evolução.

Ademais, mal passaram umas 2–3 semanas e olha só (AUR –> AUR4):

  • Pacotes: 56975 –> 14493
  • Pacotes órfãos: 15872 –> 89

Em primeiro lugar, muitos pacotes foram migrados. Cerca de 25%. Comparado com outras distribuições, e considerando que esse é um repositório não-oficial, isso é muita coisa, e mostra que existem vários maintainers ativos por aí — houve um dia em que eu achava que o Arch era muito pequeno em termos de comunidade, mas não é e está aí a prova. Na verdade, eu acho o tamanho do mesmo bastante ideal, nem tão grande (o que evita algumas coisas como help vampirism) e nem tão pequeno.

Mas enfim, e em segundo lugar: isso é um enorme cleanup do AUR. Muitos pacotes que não eram mantidos agora vão simplesmente sumir ou, pelo menos, não ser migrados. Isso é bom porque aumenta a qualidade dos pacotes do AUR, no geral — já que menos pacotes desatualizados e eventualmente ruins / não funcionando estarão no AUR4.

Ver o AUR evoluir assim é muito legal e me dá gosto de ter escolhido o Arch como distribuição e comunidade principal. Quando algum dia a coisa explodir, ainda temos o {G,F}untoo, mas ainda vai demorar bastante para isso acontecer.

makepkg not war

Filed under: Sem categoria

[mini] Journal #21: Javascript, Jquery e afins (“Review”)

Eu sou novo nesse negócio de webdev. Considerando uma época não tão distante, comecei com javascript, depois vi um pouco de coffeescript, e então finalmente nodejs. Isso no ano passado. Agora voltei a ver um pouco essas coisas. Algumas conclusões/comentários gerais até então:

  • A parte de prototypes de javascript é muito bonita (em termos de design de linguagem de programação / expressividade), mas fora isso javascript é como um todo relativamente ruim de se trabalhar. São muitos detalhezinhos, as coisas eventualmente podem bugar por simples besteiras.
  • O DOM (Document Object Model) é algo muito bem feito. Parabéns pra quem inventou isso.
  • Coffeescript é (relativamente) inútil. Melhor continuar com javascript mesmo.
  • Jquery é algo maravilhoso! Toda a dificuldade de se trabalhar com javascript e de manipular é resolvida com essa biblioteca. É simplesmente fantástico. Estou falando isso e olha que só o estou usando faz 3 dias. Super recomendado aprendê-lo!
  • O brackets é a melhor ambiente que mexi para trabalhar com webdev. Bônus: é open-source e é disponível para Linux.
  • O JsFiddle é o melhor site para compartilhar snippets de webdev, principalmente javascript.
  • A documentação da MDN (mozilla developer network) é excelente!
  • O “web console” do firefox é muito bom para debug. Ainda não tenho uma opinião forte para dizer se ele é melhor, pior ou tão bom quanto o do Chrom{e,ium}. Mas…tá ótimo! E mais: nem precisa do firebug.
  • curl continua sendo a melhor ferramenta para debugar HTTP em geral.
  • Decore o atalho Ctrl-U. Super útil.
  • Wappalyzer é ótimo para descobrir o que alguns sites utilizam. O que = javascript, server e css em geral. Quais frameworks, ferramentas, toolkits, etc.

Filed under: Sem categoria Tagged: javascript, journal, jquery, webdev

Coleções para MongoDB – parte 2

Muitos meses atrás, eu fiz um post com algumas poucas dicas para conseguir bases para testar a API do MongoDB. Após esse tempo, eu adquiri novas estratégias para alimentar uma base de dados para começar a brincar com o MongoDB. Esse post é a continuação que detalha essas novas dicas.

um projeto que mantém uma base de dados com os trajetos dos taxis de New York. Esses dados estão salvos no formato CSV e eu fiz um script para baixar (~50G) e converter esses dados para MongoDB. O script depende do bash para funcionar.

Um pouco apelação, pois os dados não são muito relevantes, mas eu fiz um script em Python para transformar a base de dados dos pacotes do ArchLinux instalados em uma base do MongoDB.

Uma outra fonte de dados interessante é a base de dados que o projeto DataViva mantém e pode ser importado via csv. A base de dados contém informações interessantes sobre, entre outros (visite a página!), salários. Vale a pena, também, visitar a página principal do projeto DataViva.

E, como última dica, há também as bases de dados que o curso OpenIntro Statistics utiliza. OpenIntro Statistics é uma iniciativa nobre de oferecer material de ensino de qualidade para qualquer um com acesso a internet. O meu atual professor de probabilidade e estatística desistiu do material anteriormente adotado ao descobrir essa iniciativa.

Arquivado em:computação, pt-BR Tagged: MongoDB

v0.14 Projeto MOD

Por Magnun

Todo músico que entende um pouco de tecnologia já se irritou com a necessidade de comprar diversos hardwares para melhorar o som produzido pelo seu instrumento. Mas e se existisse um hardware único que pudesse programado e atualizado de forma a atender todas as suas necessidades? Então, agora ele existe…

De forma sucinta, o projeto MOD é um processador de sons digitais 100% customizável, com suporte a diversos instrumentos (não somente instrumentos de corda) e foi idealizado pelo brasileiro Gianfranco Ceccolini. Atualmente o Projeto MOD roda sobre GNU/Linux (Kernel RT) e está em fase de pre-venda no site do projeto pelo valor de U$349 (mais frete). Veja alguns vídeos de demonstração na seção de vídeos do Portal MOD e na página do Kickstarter.

Prestem muita atenção nas vírgulas sonoras e viradas deste episódio, pois todas foram feitas por usuários do MOD.

Para não perder nenhum episódio siga-nos nas redes sociais (Twitter e Facebook) ou inscreva-se (Feed, Podflix, iTunes e Pocket Casts). Você quer colaborar com o Hack ‘n’ Cast? Sugira um tema, nos ajude a produzir uma pauta ou participe conosco! Basta entrar em contato por E-mail, Facebook ou Twitter. E agora temos a nossa lista de discussão no Google Groups!

Tá Mas e Daí?

Claro que ao primeiro ver esse projeto pode não parecer grande coisa, mas vamos explicar melhor. Imagine um “pedalzinho” (similar aos pedais de efeitos de guitarra que você está acostumado a ver) mas que por dentro funciona como diversos pedais intercomunicados da maneira que você quiser. Não entendeu? Veja a imagem abaixo:

Conexões MODImpressionado? Mas isso não é tudo, agora imagine que cada “plugin” (nome dado a cada “caixinha” de efeitos/distorções) pode ser atualizado ou instalado via internet. Melhora ainda, você pode programar seus próprios plugins! E no final, ainda temos a característica social. Cada plugins que você escreve, ou pedalboard que você monta pode ser compartilhado com a comunidade e instalado em um único clique. Veja esse link para ver os diversos pedalboards compartilhados atualmente e este link para os diversos plugins existentes.

Não satisfeito? Então vou jogar a pá de cal em todos os outros pedais/pedaleiras existentes. O Projeto MOD roda sobre GNU/Linux (mais especificamente o Arch Linux), utiliza como servidor de apresentação o NGINX e como servidor de aplicação o Tornado (Python). O MOD visa ser a última pedaleira que você precisará comprar, pois todas as novas funcionalidades (efeitos, distorções e etc) serão entregues via atualização de software (inclusive de maneira social) e quando da necessidade de upgrade de hardware, todo o projeto elétrico do projeto MOD foi feito pensando em possuir partes intercambiáveis. Além disso uma das premissas do projeto MOD é rodar 100% sobre Hardware Aberto e utilizar apenas Software Livre!

Para empolgar, que tal um vídeozinho?


A trajetória do MOD começou em 2008. Movido pela insatisfação com os pedais/pedaleiras existentes e pela imposição de upgrades quando precisa-se de novos efeitos, Gianfranco Ceccolini resolveu projetar uma pedaleira digital que desse mais liberdade para os músicos. Gian se associou à Angoera Sistemas Eletrônicos e ambos começaram a trabalhar no primeiro protótipo, baseado em um DSP.

Primeiro Protótipo

A primeira tentativa de protótipo utilizou inicialmente como hardware base um SHARC da Analog Devices porém, após dificuldades com o uclinux, tomou-se a decisão de mudar o hardware base para Blackfin (também da Analog Devices). Entretanto, o Blackfin não suportava o ponto flutuante e não havia nada nativo que auxiliava a produção de efeitos sonoros.

Projeto MOD - Primeiro Protótipo

Primeiro Protótipo

O desenvolvimento seguiu em ritmo lento até 2010, quando o projeto foi contemplado pelo Programa Prime e o primeiro protótipo foi finalizado.

Segundo Protótipo

Por influências do PureDyne o time de desenvolvimento se focou em trocar o DSP por uma arquitetura baseada em PC e GNU/Linux. Coincidentemente este foi o ano em que começaram a surgir as placas Mini-ITX.

Projeto MOD - Segundo Protótipo

Segundo Protótipo

Com as mudança de arquitetura (DSP para x86) e de software (controlador para Sistema Operacional) as possibilidades se tornaram infinitas e o projeto deixou de ser um simples pedal para ser uma pedaleira, ou seja, uma grafo de efeitos interconectados.

No início de 2012, já com uma nova versão do protótipo funcionando, o Hacklab, empresa de desenvolvimento de software, com vasta experiência em desenvolvimento web e software livre, juntou-se à empreitada. Nasceram a interface de construção de pedaleiras, o MOD Social e o MOD Cloud.

Neste protótipo ainda era utilizado uma conexão USB Serial para realizar a interface de configuração da pedaleira. Posteriormente a conexão USB Serial foi trocada para rede TCP/IP e com o auxílio do Hacklab foi criada uma nova interface mais amigável, visualmente agradável e bem executada, além de estar disponível para acesso via todos os tipos de dispositivos que possuem um navegador baseado em Webkit. Após algumas melhorias surgiu o “primeiro” produto, o MOD Quadra.

MOD Quadra

O MOD Quadra surgiu em 2013 e, em setembro deste ano, este produto foi lançado oficialmente durante a ExpoMusic Brasil. A repercussão foi excelente, centenas de curiosos, jornalistas e músicos passaram pelo estande do MOD e ficaram muito entusiasmados com o que viram. Em outubro do mesmo ano, o MOD Quadra começou a ser comercializado e o que era uma ideia virou, finalmente, um produto!

Projeto MOD Quadra

Projeto MOD Quadra

Créditos Das Viradas e Vírgulas Sonoras

Todas as vírgulas sonoras e viradas utilizadas nesse episódios foram obtidas no site do portal MOD (MOD Social) sob a licença Creative Commons.

Musicas: Toda a trilha sonora deste episódio é composta por canções do album Okay! Okay! da Banda Break The Bans, que está disponível sob a licença Creative Commons by 4.0.


Journal #20: Ah, communities :)

TL;DR Coldplay – Talk @ YouTube

Eu sempre quis escrever um post sobre isso, principalmente depois de ter lido o livro do Jono Bacon [1] faz provavelmente mais de um ano. Essa é mais uma historinha sobre uma dia aleatório em uma comunidade aleatória.

Warning: quando eu escrevo em português aqui, eu geralmente adoto um estilo de escrita onde eu tento ser o mais preciso possível [3]. No entanto, é virtualmente impossível ser 100% preciso aqui sem criar um ensaio de 10 páginas: existe um compromisso entre precisão e tamanho do texto. Portanto, para deixar o texto menor do que eu gostaria, pode ser que eu não me expresse tão bem como eu queria. Se você não entender algum parágrafo ou achar que ele foi escrito de forma corrida…sim, ele foi mesmo, então sinta-se à vontade para pedir clarificações.


Esse post está cheio de internas, mas espero que isso não o torne tão chato. Mas, vamos lá.

Eu sou mais um mero mortal que ama o conceito de comunidades. Amo tanto isso que coloquei como um dos meus interesses no meu LinkedIn: “Community Management”. O que é isso? Uma descrição muito clichê seria: “atitude de líder, postura social consciente, blábláblá”. De verdade, basta você imaginar um grupo de pessoas razoavelmente grande com algum interesse em comum — isso é uma comunidade. Tem comunidade de tudo que é gosto. Religião é um tipo de comunidade. Política é outro [4]. Emacs x vim users, linux distro users, empresa júnior, competidores de algum esporte, seus amigos da faculdade, seus colegas de turma de física. Ah, não há limites para formar grupinhos de interesse em comum. [5]

Se você aceitou e entendeu o conceito de comunidade, vamos para o passo 2. “Community Manager” é uma pessoa que é mais ou menos responsável por regular uma dada comunidade. O que é ‘regular’? Acho que podemos definir isso como “manter a comunidade em harmonia”. Já ‘harmonia’ é um pouco mais difícil de definir, mas eu diria que ‘respeito’, ‘saber ouvir{,ler}’ e ‘boa aura’ fazem parte dela.

So what? Um community manager deve possuir uma cabeça boa{,aberta,flexível} o suficiente para poder entender os sentimentos e/ou pensamentos dos membros da sua comunidade. Eventualmente ocorrerão conflitos de interesses, isso faz parte da natureza humana, mas o que importa de verdade é o outcome (resultado) desses conflitos — e, em particular, como o C.M. vai intervir em relação a eles.

Okay, mas esse post não é sobre community managers; é sobre communities.

Ah, communities

Tem uma multitude de assuntos para escrever aqui, mas vamos nos focar em alguns poucos para não deixar a coisa muito longa.

Comunidades são muito legais. Eu estou sempre procurando uma nova e tentando fazer parte de uma. Não, não estou falando de comunidades no sentido de ‘grupos de orkut’ (ou de Facebook), mas sim no sentido de ‘grupos de interesses’. Eu gostaria de destacar, em especial, e antes de discutir sobre algumas coisas, uma comunidade de que faço parte e de que me orgulho bastante por isso: a comunidade do Arch [Linux]. (Leia [6] se você não sabe o que é isso)

Eu devo fazer parte [7] dela mais de um ano, creio; mas eu gosto muito dela em especial porque ela também é uma metacomunidade; isto é, uma comunidade que se importa com o conceito de comunidade. Não é objetivo aqui ficar falando do Arch, mas eu diria que [8] e [9] resumem a coisa. Leia [9] por favor. Veja os “helpful links” de lá também, caso você nunca os tenha visto. Todo usuário de alguma rede social / da internet deveria ler essas páginas pelo menos uma vez na vida.

Em outras palavras: ela possui um código de conduta, e espera-se que a maioria dos membros o sigam. O código não é nada demais, é uma mistura de bom senso com esforço — esforço no sentido de não esperar tudo de bandeja e/ou que outras pessoas resolvam os seus problemas por você, i.e. CORRA ATRÁS –, só que isso tudo é documentado. A boa da coisa é que potenciais novos membros, caso “violem” esse código de conduta (violar é bem informal aqui), são usualmente avisados de maneira educada quais são as expectativas deles. Assim, um exemplo básico: criar flame wars ou bikeshedding ou incitar qualquer tipo de preconceito é extremamente desencorajado — pra não dizer proibido [10]. Tópicos no fórum ou em qualquer outro canal oficial que tratem sobre isso são usualmente retaliados — socialmente falando –, de modo que os seus autores passam a saber imediatamente qual regra violaram, e por quê.

Claro, dado um exemplo como o que eu acabei de dar, bastante “óbvio” que é contra a conduta social da comunidade, é tratado de forma diferente do que um tópico menos óbvio. Iniciar flame wars gratuitamente tem um custo de contravenção muito maior do que (por exemplo) criar tópicos duplicados sem antes ter pesquisado antes.

Mas enfim, e daí? E daí que eu já tive a oportunidade de ver atitudes ótimas nesse contexto e acho que isso é uma super experiência de vida [11]. LEIA [11] e [12]! Já vi várias “violações de condutas”, algumas com boas intenções (“sem querer”) e outras com más intenções (“trolls”). Já vi diversas formas de lidar com essas violações. Algumas super eficientes e outras super babacas.

Pronto, cheguei onde eu queria.

Nota.: note que eu falei que algumas partes iam ficar incompletas, senão o post ficaria gigante. Então, por favor não ache estranho se eu quebrei a continuidade do parágrafo anterior.

Conflitos de interesses

A motivação para escrever esse post foi um episódio que aconteceu em uma das comunidades de que participo; no caso, a comunidade da minha faculdade. Em um grupo em uma rede social famosa [13] sobre ela, grupo esse voltado principalmente para discutir sobre assuntos de professores e matérias e fatos afins (às vezes nem tão afins assim) sobre o cotidiano da faculdade, apareceu um post de propaganda.

De verdade, vários posts, sobre a mesma propaganda, (pro)vindos da mesma pessoa. No entanto, para dar um pouco de contexto, essa pessoa é ligeiramente popular entre os grupos de alunos do centro acadêmico, então não é um estranho (ou uma propaganda, for that matter) qualquer. Isso faz alguma — mas não tanta assim — diferença em como podemos interpretar o resultado da coisa.

O que aconteceu foi que, desde uns dias atrás, essa pessoa começou a divulgar, massivamente e todos os dias, propaganda sobre o serviço que ela oferece. Se fosse uma pessoa aleatória com essa insistência toda, eu provavelmente tomaria uma dessas atitudes, ou talvez todas elas simultaneamente: (i) pedir para parar de enviar spam, (ii) bloquear, (iii) report as spam to the group admin, (iv) sarcasmo como retaliação, (v) unfollow all notifications/updates/posts, dependendo do contexto. De fato, eu já fiz isso em um grupo de intercâmbio, onde tinha um cara que não parava de ficar promovendo o site dele — não vou citar o nome para não promovê-lo. É extremamente chato isso — e adblock vai sempre ganhar a guerra.

Eu acho aceitável fazer propaganda uma vez ou outra caso a pessoa seja aleatória, mas toda hora não dá. Realmente não dá…por sinal, em nossas listas de e-mail, isso também ocorre com certa frequência. Tem gente que fica divulgando o mesmo curso de software de modelagem 3D lá mais de um milhão de vezes. É chato e só serve para alimentar o marketing negativo da coisa. Eu jamais — exceto em casos de necessidade — apoiaria e/ou me matricularia em um curso desses, só por causa do marketing [14]. Pega muito mal. Falando em pega muito mal, tem uma operadora de celular que acha que ‘pega bem’, mas ela também só pega mal com as propagandas dela. Mas okay, vamos voltar ao assunto principal:

Eu achei esse tópico extremamente interessante, porque ele levantou várias questões sobre “a arte de comunidade”. Vejamos:

Eu disse que o cara é conhecido. E digo mais: em um primeiro momento, a propaganda dele fez um bom efeito sobre mim, eu consumiria serviço dele, pelo mero fato de ter achado a propaganda boa — assim como o serviço também. Só que…como eu disse, é extremamente chato ficar repetindo a mesma coisa toda hora, e criar um tópico novo todos os dias para ficar se promovendo — mas, note, se promover, em si, é uma atitude OK — até certo ponto. Existe um certo ponto em que o efeito se inverte: você passa a achar o serviço uma porcaria, simplesmente por causa do marketing ruim.

Eu vou dizer como a história iria acabar: [15] eu provavelmente bloquearia o cara e ponto. Talvez comentando antes o quanto a coisa me incomodava. Mas tá. Só que a história foi diferente — e é por isso que eu estou escrevendo esse post.

Aconteceu o seguinte: esse cara criou um tópico pedindo para as pessoas criticarem os posts dele caso ele estivesse sendo chato ou algo do tipo. Eu tenho que dizer: essa é uma atitude linda. Eu não sei se ele fez isso porque alguém reclamou antes (provavelmente foi isso) ou porque ele simplesmente resolveu fazer isso do nada, mas de qualquer forma isso é uma atitude ótima e eu parabenizo o cara. Deixou de ser bloqueado por mim por causa disso :)

Mesmo que alguém tenha reclamado, ele poderia ter xingado a pessoa, ou ignorado ela. Enfim, poderia ter feito qualquer atitude babaca. Mas eu achei o ato de criar um post pedindo críticas uma atitude madura. Bem, também é um marketing, obviamente, e o pouco conhecimento que eu tenho de economia me permite dizer que isso é uma bela estratégia (mesmo que seja apenas um side effect de um outro ato) — teoria dos jogos curtiu isso.

Bem, é isso. Mentira, não é só isso. Mas acho que até aqui já bastava para o post. Por quê? Ora bolas, é um exemplo de como as coisas podem ser diferentes, como as coisas podem terminar bem, em vez de simplesmente resolver tudo na ignorância. Mas tem mais.

A intenção do post do cara era levantar críticas, mas ele só recebeu elogios. Recebeu uma porção de likes. Como eu disse, o marketing é a alma do negócio. Mas isso em si é OK e não tem nada demais. O problema foi quando…

…a primeira crítica apareceu. Mas a crítica foi extremamente razoável e bem intencionada. O cara falou que se incomodava com o spam todos os dias aparecendo na timeline dele — e sim, eu também me incomodo com isso.

Só que o problema foi que a maior parte das pessoas da comunidade levou isso — de alguma forma, NÃO SEI COMO, que aura invisível é essa que puxa e incita as pessoas a criar conflitos desnecessários, oh céus — para o lado pessoal, e começou a achar que essa primeira crítica foi desnecessária e exagerada, e começou a surgir uma onda de achar que o autor dessa crítica era um babaca.

Assim, por quê? Obviamente isso está errado, qualquer observador decente externo a esse sistema diria que essas pessoas estão equivocadas, e estão mesmo.

Experiência própria, principalmente mas não apenas por causa do Arch:

Como resolver conflitos de interesses:

  • Não coloque o coleguinha na defensiva.
  • Não chame o coleguinha de babaca.
  • Não critique se você não gosta de ser criticado.
  • Faça críticas construtivas, explicando o seu ponto, mas sem atacar outra pessoa.
  • Seja educado.
  • Tenha respeito.

Essas community guidelines são bem básicas e deveriam estar documentadas em todo lugar, principalmente buried into the brains de todas as pessoas que são fácil e/ou sensivelmente ofendidas.

O final do tópico ficou assim: o cara que criticou ficou se defendendo, é um direito dele, ele fez a crítica dele, e de forma decente. E mais algumas pessoas continuaram a retaliar e dizer que ele é um babaca por causa da atitude dele e etc — lembre-se, o cara que fez a propaganda é carismático nos círculos dessa comunidade. Bem, FELIZMENTE, algumas outras pessoas concordaram com o cara que criticou, quer dizer, não necessairamnete concordaram com ele, mas acharam um exagero a atitude das pessoas que o criticaram.

Liberdade de expressão é delicado em alguns contextos. A palavra ‘democracia’, então, é um taboo por si só e é extremamente mal utilizada por aí.

Wrapping up

Está bem, eu só queria registrar isso e comentar um pouco sobre o assunto. Como eu acho que as coisas deveriam se resolver? E o que eu aprendi com a comunidade do Arch para comentar sobre o assunto?

  1. Se você quer criticar, faça uma crítica boa. Foi o que o cara da primeira crítica fez. Eu observo que muitas críticas não são boas por aí, então é importante guardar esse ponto.
  2. Se você quer criticar a crítica, por favor leia e releia o ponto 1. até você entendê-lo.
  3. …Profit! Sério, é só isso. Respeito mútuo e diálogo bastam para manter a harmonia. As pessoas não precisariam depender de community managers in the first place se elas por si só já se autocontrolassem e não tentassem descontar o estresse e/ou a tensão e/ou a bad vibe delas nas outras.

Por favor, pense duas vezes antes de apertar a tecla <ENTER>. E é só isso. Eu prezo pelo bem estar e pela boa interação das pessoas na internet, e acho que as pessoas hoje em dia, por estarem atrás de um teclado, são mais hostis do que precisavam ser. Talvez seja a solidão. E é por isso que eu amo (i) o reddit, (ii) o Arch, e (iii) o Bad Voltage. São 3 exemplos de super comunidades, de pessoas que (usualmente) seguem todas as coisas boas que eu escrevi aqui e evitam fazer todas as coisas ruins que escrevi aqui. Será que é tão difícil assim? Tolerância, meus amigos.

Obrigado por ler. 2703 palavras.


  • [1]:, super recomendado se você usa alguma rede social. O contexto do livro é sobre comunidades open source (linux e afins), mas ele é super bem escrito, e o Jono Bacon é um cara muito legal que também tem um podcast muito legal com outras pessoas também bastante legais [2]
  • [2]:, com discussões decentes e cheias de maturidade. OK, volte ao primeiro parágrafo agora. Mas queria eu que todas as discussões que eu vejo por aí fossem que nem as desses caras.
  • [3]: e isso geralmente dá bastante certo, e é provavelmente o motivo número um que me motiva a escrever nesse espaço
  • [4]: já a política brasileira é uma calamidade mesmo, bjs
  • [5]: também temos a comunidade das pessoas que vão dominar a lua, assim como outros astros, dessa e também de outras galáxias. Eu faço parte dela, mas prometo não fazer isso.
  • [6]:, é uma distribuição de linux voltada para usuários avançados, ou seja, é uma comunidade técnica, e bastante peculiar. Uma comunidade sensacional, yay
  • [7] “Fazer parte” é utilizado de forma informal. Pra fazer parte de uma comunidade, seja ela qual for, basta você se sentir representado por ela e/ou se sentir parte dela. Basta. “Status” não é realmente necessário.
  • [8]:
  • [9]:
  • [10]: uma comunidade decente não precisa de regras: só precisa de “encorajamento”/”motivação” de boas práticas e “frowning upon” em relação a más práticas. Probidir/banir/agir de forma autoritária é um caso extremo e raramente necessário, exceto em relação a eventuais trolls. [12]
  • [11]: isso não é um exagero. Parece que é cada vez mais raro as pessoas pararem para analisar uma situação sem levar as coisas para o lado pessoal, e de forma empática e/ou agnóstica e/ou neutra, sem favorecer ou desfavorecer nenhum ponto de vista em particular. Isso é muito ruim, será que é tão difícil parar para analisar uma situação de forma objetiva um pouco? Somos (ou deveríamos ser) seres racionais.
  • [12]: muitas vezes, o mero fato de “frowning upon” já é visto como “ser chato”. Quando as pessoas são reprimidas por algum motivo por alguém que está tentando instaurar ordem (muitas vezes, mas não sempre, o community manager), muitas vezes esse alguém é retaliado: caxias, certinho, chato, estraga-prazeres. Já vi tudo quanto é nome, alguns inclusives bem feios. Que o “chato” continue sendo chato, pois então, e forte: porque, psicologicamente, esse tipo de resposta da pessoa que foi reprimida é extremamente previsível e fraca (AKA usualmente irracional) e serve como mecanismo de defesa natural, apesar de (também) ser extremamente banal. É difícil aceitar estar errado.
  • [13]: até parece que você não sabe a qual rede eu me reFiro
  • [14]: você raramente verá um usuário do Arch tentando convencer ativamente outra pessoa a usar o Arch.
  • [15]: vários parágrafos seguidos começando com “eu”…damn, linguagem subjetiva

Filed under: Sem categoria Tagged: communities, journal, people