Ferramentas

Descomplicando a Instalação do MongoDB (Windows)

Em um post passado falamos sobre o MongoDB e suas diferenças entre os bancos SQL, mas como faço pra instalar? É difícil? Não! acompanhe comigo o passo a passo.

  1. Faça o download no mongo neste link ;
  2. Após o termino do download instale ou descompacte-o no local que preferir (Eu recomendo que instale em C:/mongodb)
  3. Bem, agora abra o cmd e navegue até [MongoDBInstalação]/bin
  4. Por ultimo execute o comando: mongod –dbpath=C:\mongodb –logpath=C:\mongodb\log.txt –install
  5. Nas variaveis do sistema, em PATCH, basta apontar o caminho [MongoDBInstalação]/bin

Prontcho! Agora só abrir seu prompt de comando e digitar mongo

Anúncios
Padrão
Desenvolvimento

Enriqueça Seu Html com Angular

Angular é uma framework desenvolvida pela mãe Google, por isso já devemos esperar por algo inovador e de qualidade (caso esteja pensando que o cara que fez este post é fanboy… ACERTOU!)

Sempre que falamos em aplicativos pensamos do lado server-side primeiro, qual linguagem utilizar? quais frameworks vão facilitar o trabalho? qual arquitetura é a mais adequada?… Mas e o front-end, que se f@d$? Não! pois com a framework da google é possível aplicar padrões e desenvolver seu front-end utilizando o tão conhecido MVC, criar novas diretivas (tags) e criar expressões no corpo da página

Continuar lendo

Padrão
Dicas, Ferramentas, Uncategorized

Instalar “na mão” é coisa do passado

Instalando um computador do zero e bateu aquele desespero só de pensar na quantidade de downloads e cliques em “Next >”?

O arquiteto inventou que você precisa usar uma ferramenta nova, que requer a instalação de outras 2 ou 3 outros pacotes? E errar um passo da instalação quer dizer fazer tudo de novo?

Bom, se você vive no mundo feliz onde um apt-get dá conta do recado, pode parar de ler por aqui. Mas no caso de usar Windows, como faz?

Continuar lendo

Padrão
Desenvolvimento

MongoDB – Banco de Dados Orientado a Documentos

Banco de dados relacionais vem sendo utilizados desde 1970, de lá pra cá aconteceram diversas mudanças no mundo da tecnologia, surgiram padrões de projeto, novas linguagens, métodos ageis, e inclusive mudanças de paradigma. A seguir apresento-lhes um novo tipo de banco de dados. Criado em 2007 o MongoDB é um jovem banco de dados que tem muito potencial a nos oferecer. Por mais que fique abismado, é meu caro, aqui não existe: “SELECT * FROM”, “CONSTRAINTS”, “JOINS”, “FUNCTIONS”, “TABLES”… pelo menos não exatamente com essas palavras.

Continuar lendo

Padrão
Desenvolvimento, Dicas

Informações sobre erros são suas amigas — então trate bem delas

A verdade inconveniente: programas falham.

Claro que bom planejamento, revisão e teste reduzem a quantidade e gravidade dessas falhas. Mas ainda assim: programas falham.

E quando isso acontece, no mundo selvagem que é o ambiente de produção, nas condições de falha que nunca se pensou a respeito, como fazemos para saber os detalhes que levaram a falha?

A resposta é: usamos boas práticas de logging e de tratamento de erros. E hoje falaremos sobre tratamento de erros, numa lista de DO’s (faça) e DON’Ts (não faça).

  • DO: planeje, desde o início, uma estratégia de logging;
  • DON’T: não exagere na estratégia — ter informação demais nos logs é quase tão ruim quanto não ter;
  • DO: trabalhe com um nível configurável de logging. Ex.: no início dos testes, coloque tudo no log (Verbose mode): erros, avisos, rastreio. Quando atingir produção, grave apenas informações de erro. Torne isso uma configuração simples da aplicação (a maior parte dos frameworks de logging considera isso);
  • DON’T: evite logar como erro coisas que fazem parte de um fluxo normal. Ex: o usuário entrou dados errados na tela de cadastro? Valide e trate ao invés de deixar um erro estourar;
  • DO: pense numa política de retenção de logs. Por exemplo: se em arquivo, estabeleça um tamanho máximo e a partir dele passe a truncar as entradas mais antigas;
  • DON’T: não perca informação relevante ao logar. Logar algo como “ocorreu um erro” é o equivalente a chegar no médico dizendo “doutor, estou me sentindo mal” e só com isso esperar um diagnóstico completo. Coloque nos logs toda a informação de contexto disponível: em que ponto do código ocorreu o erro? Em que processo de negócio houve o problema? Que usuário foi impactado? Quais os IDs dos objetos envolvidos nos erros?
  • DO: grave seu log no ponto mais “próximo” e robusto disponível. Logar no banco, por exemplo, pode não funcionar justamente nos casos de problemas de comunicação entre o servidor de aplicação e o de banco;
  • DON’T: não permita que erros ao logar impactem o funcionamento da aplicação. Uma falha ao gravar em log (com exceção de auditoria, mas isso é uma questão à parte) não deveria impedir a transação na qual o log falhou. Tentou gravar no Event Viewer e por algum motivo deu pau? A operação sendo monitorada funcionou mesmo assim? Deixa rolar — pior do que não ter informações sobre uma falha, é não ter informações sobre uma situação normal E ainda gerar uma falha por isso;
  • DO: considere monitorar (automaticamente) os seus logs. Falhas críticas lançadas em logs podem ser detectadas por monitores e alertar rapidamente a equipe de suporte;
  • DON’T: evite mostrar informações de troubleshooting (ex.: call stack) para o usuário da aplicação. Isso pode representar uma vulnerabilidade de segurança e não vai ajudar em nada (a não ser que o usuário seja um desenvolvedor da aplicação);
  • DO: pense em estratégias para manter o log “ao alcance” da mão. Por exemplo, logs em arquivo podem dar muito trabalho para se obter, já que eles normalmente se encontram numa pasta de acesso restrito nos servidores. Se for trabalhar com arquivos, por exemplo, considere o uso de um share ou de replicação de arquivo para fácil acesso por parte da equipe de suporte;

 

A lista acima claramente não está completa — prova é que mexi nela diversas vezes deste a primeira “postagem candidata”. E vários desses itens merecem maior detalhamento. Quem sabe falamos a respeito em outro post…

 

Padrão