Instalar CouchDB no Ubuntu

Para instalar o CouchDB no Ubuntu você pode simplesmente rodar o seguinte comando:

sudo apt-get install couchdb

Se quiser ter a última versão:

sudo apt-get build-dep couchdb
sudo apt-get install libmozjs-dev libicu-dev libcurl4-gnutls-dev libtool

Baixe a última versão (.tar.gz)
http://couchdb.apache.org/downloads.html

Descompacte (hoje a versão mais nova é a 0.10.1)
tar -zxvf apache-couchdb-0.10.1.tar.gz
cd apache-couchdb-0.10.0

Instale
./configure
make
sudo make install

Com o couchdb instalado, rode para testar:
sudo couchdb
e abra no browser http://localhost:5984/_utils

Você pode encontrar mais detalhes na wiki do couchdb.

Prepared Statements MySQL

O que são prepared statements?

Prepared statment serve para setar uma consulta e executá-la várias vezes com parâmetros diferentes. São desenvolvidos para queries ad hoc, são mais seguros e mais eficientes. Segue um exemplo simples:

SELECT * FROM cidade WHERE idCidade = ?

O ? (ponto de interrogação) é chamado de placeholder. Quando a consulta acima for executada é necessário passar um valor, que será substituído pelo ? na consulta.

Por que usar prepared statements?

Existem numerosas vantagens em usar prepared statements em suas aplicações, por duas razões: segurança e performance.

Os prepared statements podem ajudar a aumentar a segurança, pois separam SQL lógico dos dados fornecidos pela aplicação. Essa separação ajuda a previnir uma série de vulnerabilidades conhecidas como Ataques de SQL Injection. Normalmente quando se recebe valores de uma aplicação em uma query ad hoc, você precisa ter muito cuidado com o dado recebido, para isso é necessário utilizar algumas funções de escape de caracteres, como escape de aspas simples, aspas duplas, barras, etc para garantir que nenhum usuário malicioso consiga injetar código na sua query. Quando se está utilizando prepared statments isso não é necessário, a separação dos dados permite que o MySQL automaticamente leve em conta esses caracteres e eles não precisam ser escapados por nenhuma função especial.

O crescimento de performance nos prepared statements podem vir de algumas características diferentes. Primeiro é a necessidade de parsear a consulta apenas uma vez. O MySQL vai parsear a consulta na primeira vez para checar a sintaxe e setar a consulta para ser executada. Então, se você executar a consulta várias vezes, ele não vai precisar ter esse trabalho novamente. Esse pre-parsing pode causar um aumento de velocidade se você precisar executar a consulta várias vezes, como por exemplo quando se precisa fazer vários INSERTs.
A segunda coisa que pode ser mais rápida é que os prepared statments podem utilizar um protocolo binário. O protocolo tradicional utilizado pelo MySQL sempre converte tudo em strings antes de mandar pela rede. O protocolo binário resolve esse problema, todos os tipos são enviados na sua forma binária nativa, o que economiza tempo de conversão da CPU e pode diminuir o tráfego na rede.

Quando você deve utilizar prepared statments?

Os prepared statements podem ser utilizados para uma infinidade de razões, mas não devem ser utilizados em toda sua aplicação. Algumas vezes podem ser mais lentos que uma consulta normal. A razão é que existem dois round-trips (“idas”) para o servidor, o que pode comprometer a performance para consultas que são executadas apenas uma vez. Cabe ao desenvolvedor decidir se compensará ter impacto na performance para ganhar mais segurança.

Considerações finais

Prepared statments são recursos muito bons de banco de dados quando utilizados adequadamente, podem aumentar performance e segurança.
Esse texto é uma tradução adaptada do texto de Harrison Fisk.
O artigo original pode ser encontrado em
http://dev.mysql.com/tech-resources/articles/4.1/prepared-statements.html

CouchDB

Um conceito interessante que conheci recentemente é o do NoSQL. Existem alguns bancos de dados orientados a documentos que estão sendo comentados com certa frequência pela comunidade. Fiz uma tradução sobre o CouchDB, em breve vou escrever sobre ele e também sobre o MongoDB.

O Apache CouchDB é um banco de dados orientado a documentos que pode ser consultado e indexado com MapReduce utilizando Javascript. O CouchDB também oferece replicação incremental com detecção de conflitos bi-direcionais e resolução.

O CouchDb provê uma API JSON RESTful que pode ser acessada por qualquer ambiente que permita requisições HTTP. Existem inúmeras bibliotecas de terceiros que fazem seu uso mais fácil da linguagem de programação de sua escolha. CouchDB tem um console de administração web que fala diretamente com o banco de dados usando requisições HTTP enviadas do seu navegador.

É escrito em Erlang, uma linguagem de programação robusta, funcional ideal para construir sistemas distribuídos concorrentes. Erlang permite design flexível que é facilmente escalável e facilmente extensível.

Por que as empresas perdem bons desenvolvedores?

A “implantação” do sistema neoliberal no Brasil (e em outros lugares do mundo) contribuiu para o aumento da competitividade entre as empresas e também entre os profissionais. A busca por uma melhor qualificação profissional se tornou constante, devido ao fato de que as empresas passaram a exigir profissionais com alto nível de conhecimento técnico e a concorrência cada vez mais acirrada.

Não é preciso ter muito conhecimento de economia ou política para se perceber que o capitalismo é um sistema que não tem como objetivo favorecer o trabalhador. Com todos os problemas do mundo, muitas pessoas se sujeitam a péssimas condições de trabalho para garantir o sustento de suas famílias.

O desenvolvimento de software é uma tarefa criativa que exige profissionais com alto grau de conhecimento técnico. Não é uma tarefa braçal, isso quer dizer que o desenvolvedor tem seu capital intelectual como instrumento de trabalho.
Devido a tamanha complexidade das tarefas, é muito difícil encontrar bons profissionais (desenvolvedores, programadores, analistas, engenheiros etc) comparado a outras áreas profissionais em que o mercado já possui certa saturação de mão de obra.
Isso faz com que o profissional de tecnologia da informação seja um pouco menos desvalorizado.

Algumas empresas (principalmente as pequenas) sofrem grande impacto quando um bom desenvolvedor recebe uma boa proposta de trabalho e troca de emprego (já presenciei essa situação algumas vezes). Para minimizar esse problema as empresas estão investindo (não que elas sejam legais, o problema é o custo gerado).

Fiz uma pequena lista com os principais motivos (ao meu ver) que levam um desenvolvedor a mudar de trabalho:

- Salário
O motivo mais óbvio e comum. Quando uma outra empresa oferece salário mais alto, é improvável que o profissional recuse a proposta, caso a empresa atual não ofereça uma boa contra proposta.
É incrível como as empresas “tem mania” de achar que conseguem realizar um trabalho de qualidade contratando apenas estagiários (para pagar menos).

- Desafios
Um programador vive de desafios (não confunda com “buxas”). Passar o mês inteiro fazendo formulários não é tarefa que motive a maioria dos desenvolvedores web. Se o profissional não sentir que seu trabalho é “diferente”, é útil, é legal, ele não vai se sentir motivado a continuar.
Existe grande diferença em trabalhar “estilo produção” fazendo meia dúzia de pequenos sites por mês e cuidar de uma aplicação de alta disponibilidade com milhares de acessos por hora.
Cabe a empresa proporcionar novos desafios a sua equipe (pois em outras empresas existem vários).

- Tecnologia
Um fator interessante, que muitas vezes as empresas não enxergam, é a tecnologia utilizada para desenvolvimento. Se o programador apoia o software livre, ele não vai gostar (vai odiar) programar em .NET por exemplo, assim como um desenvolvedor Rails não gosta muito de Java por exemplo. (sei que dizem que devemos ser poliglotas, mas isso é só um detalhe =p)

- Equipe e chefe
Ponto crucial que pode levar o profissional até a se demitir da empresa. Um bom desenvolvedor não gosta de trabalhar com desenvolvedores medíocres, ele quer trabalhar ao lado de outros bons profissionais.
Também não suporta a idéia do chefe mala que faz pressão, não ajuda e só “passa buxa”.
Esse problema se agrava, quando o desenvolvedor é contratado como estagiário a certo tempo e já adquiriu certa experiência que o faz não depender do emprego para aprender mais.

- Ambiente de trabalho
Outro fator fundamental é o ambiente, o local de trabalho precisa ser bom, ter ar condicionado, ter comida a disposição, cadeira confortável, o mais importante um PC (ou MAC) de qualidade.
O calor irrita e tira a concentração, isso faz com que a produtividade diminua.
Como diria o velho ditado “saco vazio não para em pé”, a empresa tem que fornecer comida como bolachas, frutas, suco, etc. Comida fornece energia para o programador ser mais produtivo.
Talvez o que mais faça um programador ficar irritado, é quando o computador é lento, quando demora “meia hora” para compilar o software ou carregar a IDE.

- Flexibilidade de horários
Algumas empresas insistem em achar que desenvolver software é como fabricar uma peça ou montar um carro. Desenvolver software NÃO É PRODUÇÃO!
Não adianta fazer com que seu colaborador “bata cartão” as 8h da manha em ponto e não saia antes das 18h. Estamos lidando com humanos e não com máquinas, o dia que a pessoa está com problemas ou não está motivada, a baixa na produtividade é inevitável.
O colaborador não deve se sentir em uma prisão, em que não pode ir 5min no “bar da esquina” comprar um refrigerente.