Ultimamente tenho visto um grande movimento de tecnologias NoSQL pipocando na comunidade de desenvolvimento. Conversando com o @dcrec1, ele soltou uma frase bem interessante:
“parece que o povo tem medo de ir crescendo sabe, ja querem pegar a arma mais poderosa logo de cara”
Falávamos de como a tecnologia NoSQL virou febre, e tem sido utilizada muitas vezes de forma indiscriminada. Não quero dizer que a tecnologia é ruim (longe disso, sou fã de NoSQL, que inclusive pode ser uma das abordagens para solucionar problemas de escalabilidade).
Antes de adotar alguma solução NoSQL, vale a pena refletir sobre alguns pontos interessantes: (antes de mais nada, isso é uma reflexão, YMMV, IMO, então não corte os pulsos, etc)
Não adianta você tentar usar um banco NoSQL se a sua aplicação precisa de um monte de relatórios de projeção de dados; um banco relacional vai tornar a tarefa bem mais agradável (e rápida, talvez)
Não adianta você tentar usar um banco baseado em java se você nunca sequer brincou com código java. Não que você vá ter que mexer no código, mas normalmente cada linguagem tem seu ambiente e jeitão de executar tarefas; (o mesmo vale pra erlang, python, etc) Esse conhecimento pode vir a fazer falta em um momento de crise! (a regra perde sentido caso você possua um programador 7 por perto).
Um grande risco em projetos greenfield com soluções NoSQL é a falta de cultura em torno das novas ferramentas. Você sabe responder estas questões de bate-pronto? (Sim, eu sei, RTFM, mas pense "na hora da dor de barriga"....)
Essas perguntas, por mais inocentes que pareçam, podem ser respondidas com facilidade no caso de bancos SQL tradicionais, que possuem toda uma cultura em torno dos procedimentos de operação e manutenção.
Por fim, mesmo que sua resposta tenha sido negativa à essas questões, ainda assim pode ser que um banco de dados não relacional seja adequado para atender perfeitamente as suas necessidades!
Se você tem testes e um domínio de objetos rico, fica muito mais fácil evoluir a “camada” de persistência da sua aplicação. Será que vale a pena adiar a implantação do banco NoSQL da moda (que de fato simplifica e muito a vida do desenvolvedor) e continuar com o bom e velho MySQL | Postgres | XptoSQL?
Os bancos SQL estão de fato com os dias contados?
Eu acho que não! A melhor ferramenta é aquela que você domina, não é?
Continuo acreditando fortemente no uso complementar de ambas tecnologias.
E você?
Após 48 horas de pouco sono, muito café e bastante hacking usando Node.js, nossa equipe conseguiu entregar o projeto do Node.js Knockout, o Umeboshi Server. Mais tarde, pretendo escrever a minha experiência na competição, mas, agora, eu gostaria de pedir que você, meu caro leitor, participasse da votação e avaliasse não só o meu projeto, mas também vários outros projetos realmente impressionantes da competição.
Neste semestre vou terminar meu curso de Graduação na FATEC-SP. Como todo bom nerd, vou escrever minha monografia no Vim, utilizando o LaTeX para formatação e geração dos pdfs.
Para facilitar a correção de erros ortográficos, o Vim incluiu, a partir da versão 7.x, um corretor ortográfico interno. Para habilitá-lo, basta incluir os comandos abaixo no arquivo ~/.vimrc:
:set spell :set spelllang=pt-BR
Mas neste momento, provavelmente não temos o arquivo de dicionário que o vim necessita para fazer as verificações, portanto precisamos obter uma lista de palavras e em seguida gerar o arquivo do dicionário para o Vim.
Primeiramente, vamos obter a lista de palavras.
A lista de palavras que eu uso, foi obtida do projeto Aspell. O Aspell é o corretor ortográfico que substituiu o Ispell. Mais informações sobre ele podem ser obtidas aqui.
Para obter os dicionários em pt-BR basta instalar o pacote aspell-pt-br, no Debian (no Ubuntu o pacote deve ter o mesmo nome). Depois de ter instalado o pacote com
sudo apt-get install aspell-pt-br
obtemos a lista de palavras executando o comando abaixo:
aspell -l pt-BR dump master > lista_de_palavras.txt
com a lista de palavras disponível, precisamos gerar o arquivo de dicionário do Vim. Para isso, basta abrir o Vim e digitar:
:mkspell pt-BR lista_de_palavras.txt
O comando acima gera um arquivo chamado pt-BR.latin1.spl no meu caso, pois meu sistema utiliza o encoding Latin1. Agora basta mover o arquivo .spl para o diretório ~/.vim/spell/. E teremos o corretor ortográfico assim que o próximo arquivo for aberto.
Para aprender os atalhos do corretor ortográfico e obter mais informações, digite o comando abaixo no modo de comando no Vim:
:help spell
Por hora é só.
The word prototype is formed by two greek words, protos (first) + typos (impression). We know how important it is to use prototypes as a first impression of our products and systems, as suggested by the origin of the word.
If I can’t picture it, I can’t understand it
Albert Einstein
When we think about web systems prototypes, we normally imagine high fidelity prototypes or at least computer made prototypes which are interactive so they can be used in usability tests.
There are many tools to build prototypes:
However, before making a high fidelity interactive computer based prototype, we can draft this prototype. This draft will serve as a tool for very useful discussions about the product and its features. And to build this type of prototype there’s no better tools than pencil and paper. It’s cheap, fast and very easy to use!
I’ll finish this post with some examples of prototypes draw on paper, and they’ll give you an idea on how powerful they are.
Powered by Twitter Tools
Compartilhe!
Powered by Twitter Tools.