quarta-feira, 13 de agosto de 2014

TI Imatura x TI Madura


Veja abaixo algumas diferenças entre uma TI Imatura e uma TI Madura.

TI IMATURA
  • Processos geralmente improvisados e conduzidos por pessoas experientes.
  • Processos gerenciais explícitos, formalizados, especificados e comunicados, todavia não são seguidos com rigor ou não são obrigatórios.
  • Gerentes e coordenadores de TI focados na solução de problemas imediatos (ação mais conhecida como “apagar incêndios” no dia a dia da área).
  • Aparecem conflitos frequentes e animosidade latente entre a TI e seus clientes ou usuários.
  • Planejamento superficial de projetos, com cronogramas e orçamentos não cumpridos, não baseados em estimativas realistas ou em indicadores de produtividade.
  • Prazos dos projetos impostos e não exequíveis, fazendo com que as funcionalidades e a qualidade do produto fiquem comprometidas.
  • A TI percebida como uma necessidade e não como um fator de agregação de valor ao negócio (é um mal necessário e não uma solução).
TI MADURA
  • As habilidades dos gestores de TI são identificadas.
  • Processos seguidos, padronizados, descritos e comunicados.
  • Existe cultura de planejamento e as atividades são realizadas de acordo com o planejamento acordado e aprovado.
  • São aplicados métodos claros e naturais nas tarefas, sem grandes complicações.
  • Existe o conceito de “lições apreendidas” e as evoluções na “forma de fazer as coisas” são discutidas, documentadas, registradas e comunicadas.
  • Os processos preveem melhorias contínuas considerando o custo benefício.
  • As regras, papéis e responsabilidades são claras para todos.
  • Há monitoração da qualidade dos produtos e dos serviços e a satisfação do cliente é avaliada constantemente (interno ou externo).
  • No planejamento, os cronogramas e os orçamentos são baseados em estimativas realistas, nas experiências acumuladas e em métricas aceitas pelo mercado.

quinta-feira, 31 de julho de 2014

MongoDB World 2014 - Vídeos




 






Já estão disponíveis os vídeos do Evento MongoDB World 2014 que ocorreu nos dias 23, 24 e 25 de junho no Estados Unidos.  Acesse o link abaixo para visualizar todos os vídeos.

https://www.mongodb.com/mongodb-world/presentations

sábado, 12 de abril de 2014

Depurando o AngularJS

Para os iniciantes em AngularJS, como eu, segue um dica que facilita o debug de aplicações desenvolvidos neste framework.


Trata-se de um plugin para o Chrome chamado Batarang.  Foi desenvolvido pelo Google e oferece uma interface visual para depurar suas aplicativos.

Você pode instalá-lo acessando o Chrome Web Store.  É só procurar no Google por Batarang, é o primeiro link que aparece.



quarta-feira, 9 de abril de 2014

Robomongo: MongoDB Management Tool

Robomongo é uma ferramenta que pode ser utilizada no lugar do shell do MongoDb.  Com ela é possível gerenciar vários bancos de dados, inclusive de servidores diferentes

Além de visualizar a maioria dos objetos do banco de dados, também é possível criar collections, índices, documentos, entre outros.   E ainda possui IntelliSense para os comandos.

Esta disponível para Mac OS, Windows e Linux

Enfim, uma ótima ferramenta e o mais importante, ela é open-source.  Veja mais informações no site do fabricante - Robomongo — shell-centric MongoDB management tool (MongoDB Admin UI)


Robomongo

sexta-feira, 27 de setembro de 2013

Instalar Node.js como serviço do Windows

Para instalar uma aplicação, rodando em Node.js, como um serviço do windows você pode utilizar o módulo WinSer.

Primeiro você deve instalar esse módulo no ambiente onde o interpretador do Node.js foi instalado, ou seja, na máquina onde a aplicação irá rodar.  Isso é feito através do Node Package Manager (npm). Abra o Prompt de Comando e digite:

 npm install winser -g

O próximo passo é criar o arquivo de configuração com as informações necessárias para a instalação do serviço.  Trata-se de um arquivo no formato JSON, localizado no diretório raiz da aplicação chamado package.json. Veja o exemplo abaixo:

{
  "name": "application-name",
  "version": "0.0.1",
  "private": true,
  "scripts": {
              "start": "node app.js"
             }
}  

A propriedade name será o nome do serviço listado no painel do windows.  Já a propriedade scripts.start contém a linha de comando que será executada pelo serviço para subir a aplicação.  No exemplo a aplicação é app.js.

Por último, basta executar o winser no diretório raiz da aplicação (mesmo local do package.json) e então sua aplicação será instalada como serviço do windows.

winser -i (instalar)
winser -r (remover)

Atenção!! Para essa operação o Windows pode exibir direitos administrativos.  Certifique-se de estar logado com esses direitos.

sábado, 21 de setembro de 2013

The Little MongoDB Book - Capítulo 5 - Quando Usar MongoDB

Capítulo 5 - Quando Usar MongoDB

Até você deve ter uma idéia de onde e como ele pode se encaixar em seu sistema já existente.  Há muitas tecnologias novas de armazenamento competindo hoje em dia, o que torna fácil ficar em dúvida de qual escolher.
Para mim, o lição mais importante, que não tem nada a ver com MongoDB, é que você não tem que confiar em uma única solução para lidar com seus dados.  Sem dúvida, uma única solução tem vantagens óbvias, e para muitos projetos, é uma solução de abordagem mais sensata.  
A ideia não é que você deva usar diferentes tecnologias, mas sim saber que você pode fazer isso.  Só você sabe se os benefícios da introdução de uma nova solução superam os custos de sua implementação.
Estou esperançoso de que você tenha visto o MongoDB como uma solução geral.  Muitos comentam que banco de dados orientados a documentos possuem muito em comum com os bancos de dados relacionais.  Portanto, vamos simplesmente afirmar que MongoDB deve ser visto como uma alternativa direta as bases de dados relacionais.  Diferentemente de outros bancos NoSQL, como por exemplo, do Lucene que melhora um banco de dados relacional fazendo a indexação completa de texto, ou o Redis para armazenamento de chave-valor, o MongoDB é um repositório central de dados.
Repare que eu não chamei MongoDB de um substituto para banco de dados relacionais, mas sim uma alternativa.  É uma ferramenta que pode fazer o que o outras ferramentas também fazem.  Algumas delas, o MongoDB faz melhor, outras nem tanto.  Vamos falar mais disso adiante.

Sem Esquema (Schema-less)

Um benefício frequentemente elogiado de um banco de dados orientado a documentos é que eles são schema-less.  Isso os torna muito mais flexíveis do que as tabelas de banco de dados tradicionais.  Concordo que o schema-less é um bom recurso, mas não o principal que devemos mencionar.
As pessoas falam sobre schema-less como se você de repente fosse começar a armazenar dados misturando-os “loucamente”.  Existem domínios e conjuntos de dados que realmente pode ser doloroso modelá-los em um banco relacional, mas não vejo isso como um caso extremo.  Schema-less é legal, mas a maioria dos seus dados vão ser altamente estruturados.
É verdade que ocasionalmente isso pode ser útil, especialmente quando novas funcionalidades forem introduzidas, mas pensando bem, isso também poderia ser resolvido no relacional através de uma coluna que permita valor nulo.
Para mim, o benefício real do schema-less design é a falta de configuração e a redução do desacordo com a OOP.  Isto é particularmente verdade quando você está trabalhando com uma linguagem estática.  Eu já trabalhei com MongoDB em C3 e Ruby, e a diferença é gritante.
O dinamismo de Ruby e sua popular implementação do ActiveRecord já reduz muito a incompatibilidade com o objeto-relacional.  Isso não quer dizer que MongoDB não é bom para Ruby.  Pelo contrário, acho que a maioria dos desenvolvedores Ruby veria o MongoDB como uma melhoria, ao passo que os desenvolvedores C# ou Java iriam ver uma mudança fundamental na forma como eles interagem com seus dados.
Pense nisso a partir da perspectiva de um desenvolvedor de driver.  Você deseja salvar um objeto? Resposta: Serializar para JSON (tecnicamente BSON) e enviá-lo para o MongoDB.  Não há mapeamento de propriedade ou de tipo.  Esta simplicidade definitivamente flui para você, ou seja, para o desenvolvedor final.

Gravações

Uma área onde MongoDB esta se especializando é a de log.  Há dois aspectos do MongoDB que o faz ser rápido ao gravar dados.  Primeiro, você pode enviar um comando de escrita e não aguardar uma resposta do MongoDB.  Em segundo lugar, com a introdução do recurso jornaling na versão 1.8, e melhorias feitas na versão 2.0, você pode controlar o comportamento de escrita no que diz respeito a durabilidade dos dados.  
Essas configurações permitem especificar quantos servidores devem confirmar a gravação do dado antes de retornar para a aplicação.  Isso pode ser configurado para todas as gravações ou pontualmente em situações específicas.  Isso nos da um grande nível de controle sobre o desempenho de gravação e da durabilidade dos dados.
Além desses fatores de desempenho, log é um desses conjuntos de dados, que muitas vezes podem tirar proveito das coleções schema-less.
Por fim, MongoDB tem algo chamado capped collection. Até agora, todas as coleção criadas implicitamente são coleções normais.  Podemos criar uma coleção limitada usando o commando db.createCollection sinalizando-a como limitada.
// limita sua coleção em 1 megabyte
db.createCollection('logs', {capped: true, size: 1048576})

Quando a coleção limitada atinge seu limite de 1MB, documentos antigos são automaticamente removidos.  Um limite para o número de documentos, ao invés do tamanho, pode ser definido usando max. Coleções limitadas têm algumas propriedades interessantes.  Por exemplo, você pode atualizar um documento, mas ele não pode crescer em tamanho.  Além disso, a ordem de inserção é preservada, assim você não precisa adicionar um índice extra para obter a classificação com base no tempo adequado.
Ressalto que, se você quer saber se sua escrita encontrou erros (ao contrário do padrão fire-and-forget), você deve simplesmente executar o comando db.getLastError().  A maioria dos drivers encapsulam isso quando configurados para safe write, ou seja, especificando {:safe => true} como segundo parâmetro do insert.

Durabilidade

Antes da versão 1.8, MongoDB não possuía durabilidade em um único servidor.  Isto é, uma falha do servidor provavelmente resultaria em perda de dados.  A solução era sempre. Recorrer a uma configuração multi-servidor (replicação).  Um dos principais recursos adicionados a 1.8 foi o journaling.  
Para habilitá-lo, adicione a linha journal=true no arquivo de configuração mongodb.config que criamos quando configuramos o MongoDB pela primeira vez (reinicie o servidor se quiser que seja ativado imediatamente).  Isso é um tipo de configuração que você provavelmente que você sempre vai querer que esteja ativada (isso será um padrão nas próximas versões).  Apesar de em algumas circunstâncias a performance de ter o jornaling desativado ser maior, é um risco que você pode não estar disposto a correr.  
Durabilidade só é mencionada aqui, porque muita coisa já foi feita em torno da falta de durabilidade de um único servidor do MongoDB.  Isso provavelmente vai aparecer nas buscas do Google por algum tempo.  Se encontrar informações dizendo que é um recurso não existente no MongoDB, desconsidere, pois se trata de um informação desatualizada.

Pesquisa Completa de Texto (Full Text Search)

Esse é um recurso que esperamos que venha a existir nas próximas versões do MongoDB.  Com seu suporte às matrizes, implementar isso seria muito fácil.  Atualmente para isso, você precisará de uma solução como o Lucene/Solr.  Naturalmente, isto vale também para muitas bases de dados relacionais.

Transações

MongoDB não possui transações.  Ele tem duas alternativas, uma delas é muito boa, mas com uso limitado, e a outra seu uso é complicado, mas flexível.
A primeira consiste de suas operações atômicas.  São ótimas opções, desde que realmente resolvam o seu problema.  Nós já vimos algumas dessas operações mais simples como o $inc e o $set.  Há também comando como findAndModify  que pode atualizar ou excluir um documento e devolvê-lo atomicamente.
A segunda, quando as operações atômicas não são suficientes, é a volta para a two-phase commit (gravação de duas fases).    Two-phase commit são realmente muito populares no mundo relacional como forma de implementar transações entre vários bancos de dados. O site do MongoDB tem um exemplo que ilustra um cenário mais comum (transferência de fundos).  A idéia geral é que você armazene o estado da transação dentro do documento real que está sendo atualizado e através disso realizar os passos de init-pending-commit/rollback manualmente.

Processamento de Dados

A primeira consiste de suas operações atômicas.  São ótimas opções, desde que realmente resolvam o seu problema.  Nós já vimos algumas dessas operações mais simples como o $inc e o $set.  Há também comando como findAndModify  que podem atualizar ou excluir um documento e devolvê-lo atomicamente.
MongoDB depende de MapReduce para a maioria das tarefas de processamento de dados.  Ele até possui alguns recursos básicos de agregação, mas para algo sério, você vai precisar do MapReduce.  No próximo capítulo veremos MapReduce em detalhe.  Por hora, você pode pensar nele como sendo uma forma muito poderosa e diferente para realizar o group by.
Uma das forças do MapReduce é que ele pode ser paralelizado para trabalhar com grandes conjuntos de dados.  No entanto, a implementação do MongoDB depende de JavaScript, que é single-threaded.  Portanto, para o processamento de grandes volumes de dados, é provável que você precise de outra coisa, como o Hadoop.  Felizmente, os dois sistemas realmente se complementam mutuamente - há um MongoDB adapter for Hadoop.
Uma das forças do MapReduce é que ele pode ser paralelizado para trabalhar com grandes conjuntos de dados.  No entanto, a implementação do MongoDB depende de JavaScript, que é single-threaded.  Portanto, para o processamento de grandes volumes de dados, é provável que você precise de outra coisa, como o Hadoop.  Felizmente, os dois sistemas realmente se complementam mutuamente - há um MongoDB adapter for Hadoop.
É claro que paralelização de processamento de dados não é algo que banco de dados relacionais se destacam.  Existem planos para futuras versão do MongoDB no intuito de melhorar a forma de trabalhar com grandes conjuntos de dados.

Geospatial

Uma característica particularmente poderosa do MongoDB é seu suporte para índices geo-espaciais.  Isso permite que você armazene coordenadas x e y dentro de documentos e então realizar consulta através de $near que encontrará documentos próximos de uma determinada coordenada, ou através de $within que encontrará dentro de um quadrado ou círculo.

Ferramentas e Maturidade

Você provavelmente já sabe a resposta para isso, mas MongoDB é, obviamente, mais jovem do que a maioria dos sistemas de banco de dados relacionais.  Isto é absolutamente algo que você deve considerar, porém o quanto isso é importante vai depender do que e como você esta fazendo.
No entanto, em uma avaliação honesta, você simplesmente não pode ignorar o fato de que o MongoDB é mais jovem e que as ferramentas disponíveis ao redor não são tão boas (embora as ferramentas em torno de grande parte dos bancos de dados relacionais são horríveis demais!). Como exemplo, a falta de suporte para número base-10 de ponto flutuante é, obviamente, uma preocupação (embora não necessariamente seja um show-stopper) para sistema que lidam com dinheiro.
O lado positivo é que existem drivers para um grande número e linguagens.  O protocolo é moderno e simples e o desenvolvimento está acontecendo numa velocidade estonteante.  MongoDB está em produção em tantas empresas, que a preocupação inicial sobre sua validades, já é coisa do passado.

Neste Capítulo

A mensagem deste capítulo é que MongoDB, na maioria dos casos, pode substituir um banco de dados relacional.  É muito mais simples e direto, é mais rápido e, geralmente, impõe menos restrições sobre os desenvolvedores de aplicativo.

A falta de transações pode ser uma preocupação legítima e séria.  No entanto, quando as pessoas perguntam onde é que o MongoDB esta em relação ao novo cenário de armazenamento de dados, a resposta é simples: bem no meio.

The Little MongoDB Book - Capítulo 4 - Modelagem de Dados

Capítulo 4 - Modelagem de Dados

Vamos mudar um pouco de assunto e ter uma conversa mais abstrata sobre o MongoDB.  Explicar novos termos e nova sintaxe é uma tarefa relativamente simples.  Mas ter uma conversa sobre modelagem de um novo paradigma, não é tão fácil.  A verdade é que a maioria de nós ainda esta descobrindo o que funciona ou não nessas novas tecnologias.  É uma conversa que pode ter um início, mas no fim você terá que aprender praticando.
Entre os bancos de dados NoSQL, os banco de dados orientados a documento são os que mais se assemelham com o modelo relacional.  As diferenças são sutis, mas isso não significa que elas não são importantes.

Inexistência de Joins

A principal diferença que você precisa saber é que o MongoDB não possui Joins.  Não sei realmente o motivo pelo qual um sintaxa Join não é suportada, mas que geralmente são vistos como não escaláveis.  Portanto, quando você precisar dividir seus dados horizontalmente, eles deverão ser “juntados” na camada de aplicação.
Para sobrevivermos em um mundo join-less (sem join), temos que implementar esse relacionamento entre documentos, diretamente na aplicação. Essencialmente, para isso precisamos realizar uma segunda consulta para obter os dados relevantes.  A definição do relacionamento não é tão diferente como no modelo relacional.  
Vamos dar um pouco menos de foco para nossos unicórnios e dedicar mais tempos aos nossos funcionários.  A primeira coisa a fazer é criar um funcionário (estou usando um _id explícitos para que possamos construir exemplos coerentes).
db.employees.insert({_id: ObjectId("4d85c7039ab0fd70a117d730"), name: 'Leto'})
Agora vamos adicionar alguns funcionários e atribuir Leto como seu gerente.
db.employees.insert({_id: ObjectId("4d85c7039ab0fd70a117d731"),
   name: 'Duncan',
   manager: ObjectId("4d85c7039ab0fd70a117d730")});

db.employees.insert({_id: ObjectId("4d85c7039ab0fd70a117d732"),
   name: 'Moneo',
   manager: ObjectId("4d85c7039ab0fd70a117d730")});
(Vale a pena repetir que _id pode ser qualquer valor único.  Como você provavelmente usaria o ObjectId na vida real, usaremos ele aqui também.
É claro, que para encontrar todos os funcionários de Leto, devemos executar:
db.employees.find({manager: ObjectId("4d85c7039ab0fd70a117d730")})
Não há nenhuma mágica aqui.  No pior dos casos, a falta de relacionamento ira necessitar apenas uma consulta extra (provavelmente indexada), na maioria das vezes.

Matrizes e Incorporados

Documentos

Só porque o MongoDB não possui relacionamento, não significa que ele não possua alguns truques na manga.  Lembra-se quando rapidamente falamos que o MongoDB suporta arrays na primeira aula deste documento? Acontece que isso é extremamente útil quando se trata de relacionamento muitos-para-um ou muitos-pra-muitos.  Como exemplo, se um simples funcionários pode ter dois gerentes, poderíamos armazená-los em uma matriz.
db.employees.insert({_id: ObjectId(    "4d85c7039ab0fd70a117d733"),
   name: 'Siona',
   manager: [ObjectId("4d85c7039ab0fd70a117d730"),
             ObjectId("4d85c7039ab0fd70a117d732")] })
É interessante saber que, para alguns documentos, manager pode ser um valor escalar, enquanto que para outros pode ser um array.  A consulta original funcionará em ambos:
db.employees.find({manager: ObjectId("4d85c7039ab0fd70a117d730")})
Você vai descobrir que matrizes de valores são muito mais convenientes que lidar com relacionamentos muitos-pra-muitos de tabelas.
Além de matrizes, MongoDB suporta também documentos incorporados. Vá em frente e tente inserir um documento com um outro documento alinhado, tal como:
db.employees.insert({_id: ObjectId("4d85c7039ab0fd70a117d734"),
   name: 'Ghanima',
   family: {mother: 'Chani',
            father: 'Paul',
            brother: ObjectId("4d85c7039ab0fd70a117d730")}})
Caso você esteja se perguntando, documentos incorporados podem ser consultados utilizando uma notação de ponto:
db.employees.find({'family.mother': 'Chani'})

DBRef

O MongoDB suporta algo conhecido como DBRef que é uma convenção suportada por diversos drivers. Quando um driver encontra um DBRef ele pode automaticamente localizar o documento de referência.  Um DBRef é composto pelo nome da coleção e o id do documento de referência.
Ele é especificamente útil quando precisamos fazer relacionamento entre documentos de coleções diferentes.

Desnormalização

Uma alternativa para o uso de relacionamento é a desnormalização de seus dados.  Historicamente, a denormalização foi utilizada para código sensíveis à performance, ou quando o dado precisa ser snapshotted (como em um log de auditoria).  No entanto, com a crescente popularidade do NoSQL, muito dos quais não possuem relacionamentos, desnormalização é cada vez mais comum na modelagem.  
Isto não significa que você deve duplicar pedaços de informação em todos os documentos.  No entanto, ao invés de deixar o medo dos dados duplicados conduzir suas decisões de design, considere modelar seus dados com base nas informações pertencentes ao documento.
Por exemplo, digamos que você esta desenvolvendo um aplicativo de fórum.  A maneira mais tradicional de relacionar um usuário específico a um artigo é através de seu userid dentro dos artigos.  Com este modelo, você não pode carregar os artigos sem relacionar com o usuário.
Uma alternativa possível é simplesmente gravar o nome e também o userid em cada artigo.  Você pode fazer isso até mesmo com um documento incorporado como user: {id: ObjectId('Something'), name: 'Leto'}.  Sim, se sua aplicação permite que o usuário mude seu nome, você terá que atualizar cada documento (o que pode ser feito com apenas um comando de update).
Adaptar-se a esse tipo de abordagem não é fácil para alguns.  Em muitos casos, nem sequer faz sentido.  Não tenha medo de experimentar.  Não é adequado apenas em algumas circustâncias, mas também pode ser o caminho certo a fazê-lo.

Qual você deve escolher?

Matrizes de ids são sempre uma estratégia útil quando se trata de cenários um-pra-muitos ou muitos-pra-muitos.  Seguramente DBRefs não são usados com muita frequência, embora você possa experimentar e brincar com eles.  Isso certamente deixa alguns desenvolvedores inseguros sobre como utilizar documentos incorporados versus referência manual.
Em primeiro lugar você deve sabe que o MongoDB limita o tamanho máximo de um único documento a 16 megabytes.  Sabendo deste limite, embora bastante generoso, lhe dá uma idéia de como devem ser utilizados.  Neste ponto, a maioria dos desenvolvedores apoiam as referências manuais para grande parte de seus relacionamentos.
Documentos incorporados são frequentemente aproveitados, principalmente, quando queremos que pequenos pedaços de dados sejam trazidos junto com o documento principal numa única consulta. Um exemplo que usei na vida real foi armazenar um documento accounts em cada usuário, algo como:
db.users.insert({name: 'leto',
    email: 'leto@dune.gov',
   account: {allowed_gholas: 5,
             spice_ration: 10}})
Isto não significa que você deva subestimar o poder dos documentos incorporados ou considerá-los como algo de menor utilidade.  Defina seu modelo de dados de forma que seus objetos não precisem de relacionamento.  Lembre-se que o MongoDB permite consultas e índices sobre campos de documentos incorporados.

Poucos ou Muitas Coleções

Tendo em mente que coleções não possuem esquema, ou seja, são schema-less, é perfeitamente possível construir um sistema usando apenas uma coleção com uma mistura de documentos.
Mas pelo que tenho visto, a maioria dos sistemas MongoDB são definidos de forma semelhante ao que você encontraria em sistemas relacionais.  Em outras palavras, se temos uma tabela no relacional, provavelmente teremos uma coleção no MongoDB (muitos-pra-muitos e relacionamento são uma exceção).
A conversa fica ainda mais interessante quando consideramos documentos incorporados.  O exemplo que frequentemente surge é de um blog, onde temos os comentários inconporados a cada artigo do blog.
Não há nenhuma regra rígida (além do limite de 16MB). Trabalhar com diferentes abordagens fará você ter uma noção do que fazer e do que não fazer.

Neste Capítulo

Nosso objetivo neste capítulo foi fornecer informações úteis para a modelagem de seus dados.  A modelagem de um sistema orientado a documento é diferente, mas não muito diferente do mundo relacional.  Você tem um pouco mais de flexibilidade e um certo constrangimento, mas para um sistema novo, as coisas tendem a se encaixarem melhor.  A única forma pra dar errado é se você não tentar.