IPC 360: Camera IP boa e barata

Boa tarde senhores...

Acabei de encontrar, talvez, a melhor câmera IP que vi nos últimos tempos. E não falo na questão de qualidade ou valor. Mas sim no quesito configuração.

Esse é um dos pontos mais importantes pois já percebi que a maioria das pessoas que me pedem ajuda, não são conhecedoras de assuntos de rede. Por tanto, com certeza é a melhor opção.

Falo isso porque eu fiquei completamente surpreso com a câmera. Ela simplesmente se configurou sozinha. E quanto tive acesso à ela via rede interna, pensei: "agora é ver como é a configuração para a rede externa". Aí quando estava no 4G, fui acessar a camera por curiosidade e pronto: estava tudo funcionando... Sinistro.

Portanto, vamos ao que interessa... Essa é a câmera:

A camera é uma IPC 360. O valor dela na Santa Efigênia foi 250 reais.

Dentro da caixa veio a câmera, o cabo com o plug de energia (igual a de celulares android), o suporte para encaixa e umas buchinhas para perdurar na parede.

A configuração do aparelho chega a assustar do tanto que é fácil.
Primeiro é necessário baixar o aplicativo IPC 360 pelo Google Play.

Agora basta seguinte o passo a passo para configurá-la:
1) Acessar sua rede wi-fi com seu celular
2) Ligar a câmera na tomada. Ela ficará piscando com uma luz vermelha. Caso pisque uma luz verde ao invés de vermelha, significa que ela já foi configurada. Então será necessário resetá-la. Ela possui um orificio na parte traseira para o reset.
3) Se cadastrar através do aplicativo.Você receberá um e-mail para confirmação da conta. Quando receber esse e-mail e confirmar a conta, já estará
4) Adicionar a senha da sua rede wi-fi no aplicativo. Isso é necessário para configurar a câmera.
5) Entrar no aplicativo, e colocar para ele buscar a câmera automaticamente.
6) Com a câmera encontrada, irá pedir um nome para ela.. no meu caso eu coloquei como "Sala" pois ela fica na casa de casa.

A partir daí é só alegria. A câmera está configurada para acesso interno e externo.
Caso você se pergunte como isso é possível, eu explico: ela utiliza streaming para fazer o envio da imagem.
E o resultado é esse:

A imagem tem uma excelente qualidade e possui ângulo de visão de 180 graus. Da pra dar zoom nela sem perder a qualidade. Os botões em baixo são excelentes:

1. O botão de volume à esquerda, possibilita captar o audio do ambiente e é enviado direto para o celular
2. O botão de câmera, bate uma foto da imagem que está sendo transmitida.
3. O botão de microfone no meio é o melhor: permite que você fale e o aúdio é transmitido para a câmera e reproduzido. Então quem estiver no ambiente, ouvirá o que você fala.
4. O botão de vídeo, filma a imagem que está sendo transmitida.

Outra boa funcionalidade é que a câmera possui uma entrada para cartão de memória SD. Basta plugá-lo para que a câmera grave tudo. Apenas lembre-se de sempre desligar a câmera antes de colocar ou remover o cartão para não danificar o aparelho.

Essa é a tela que irá listar todas as câmeras que você possuir cadastradas.

Um dos botões mais praticos é o de compartilhamento. Com ele você consegue permitir o acesso de outras pessoas à sua câmera. Basta que a pessoa baixe o aplicativo IPC 360 e realize o cadastro. Quando você for compartilhar essa câmera, basta colocar o e-mail que a pessoa usou para se cadastrar e pronto. Aparecerá a camera no aplicativo da pessoa.

Essa a tela de capturas. Todas as fotos ou vídeos feitos atraves do aplicativos serão listados aqui agrupados pela data.

Essa tela salva todas as imagens que dispararam o alarme da câmera. Para quem não conhece, as câmeras IP's possuem um mecanismo de alarme. Quando acontece algum movimento na imagem da câmera, ela bate uma foto e notifica o responsável pela câmera. É muito útil para segurança.

Essa é a tela de configuração. Há várias configurações e é levar ir mexendo para aprender.
Cansei..
Falou valeu

Wildfly: entendendo suas extensões

A idéia desse post é explicar como funciona as "extensions" do JBoss Wildfly, que são módulos criados para implementar toda a spec Java EE e outras funcionalidades.

Desde a primeira versão Wildfly, o servidor sofreu uma grande mudança em sua estrutura interna que passou a contar com um core leve e extensões que são carregadas conforme necessidade ou por escolha do desenvolvedor.

• Infinispan: esse módulo é uma implementação de provider de cache de segundo nível. Segundo a própria documentação do Wildfly: "provê suporte a cache para serviços de alta disponibilidade: alta performance, cache transacional que pode operar com sistemas distribuídos e não distribuídos".
• ConfigAdmin: (ler sobre módulo OSGi) esse módulo aparece nos wildfly 7.X até a versão 8.0.0-Alpha2 e ao que tudo indica era o módulo que implementava a spec de OSGi. Segundo o site da JBoss, o módulo de OSGi foi externalizado e por isso deixou de aparecer no standalone.xml.
• Connector: não encontrei nada sobre esse módulo. Caso alguém saiba e queira comentar sobre...
• deployment-scanner: esse cara é mais uma funcionalidade do sistema do que necessariamente um módulo. Ele funciona apenas quando o servidor está sendo rodado no modo standalone. Sua função é verificar de tempos em tempos se houve alguma alteração dentro da pasta deployments (pasta padrão de deploy do wildfly no modo standalone) e então realizar o deploy das alterações. Esse link tem uns tópicos legais sobre o deploy no modo standalone
• EJB3: essa nem precisa falar nada né ? Mas pensando bem é sempre bom falar das versões da spec do EJB que foram implementadas em cada versão do wildfly. No JBoss 7.X o EJB segue a especificação versão 3.1, enquanto wildfly 8, 9 e 10 seguem a última versão do EJB que é a 3.2 (final release em maio de 2013). Mais novidades sobre a JSR 345 aqui
• JAX-RS: essa também não. Implementação da spec de webservices através de acesso RESTful
• JDR: acrônimo para JBoss Diagnostic Reporter: pode ser rodado através do jdr.bat ou jdr.sh que está na pasta bin do servidor. Coleta vários dados do servidor fazendo inclusive cópia de arquivos de configuração para análise e dos projetos "deployados". Utiliza por padrão a porta 9990 e o melhor é que pode ser utilizado com o servidor rodando ou parado (no entanto coletará mais informações com o servidor rodando).
• JMX: acrônimo para Java Management eXtensions. É utilizado, e muito útil (diga-se de passargi), para monitoramento e configuração de aplicações de forma remota. Com JMX voce pode "controlar" à distancia, mudar valores de configuração da aplicação sem precisar parar o servidor e tudo mais. É muito bom pra acompanlhar a aplicação de produção na pós-implantação
• JPA: esse tambem não precisa falar. No entanto algo interessante de saber sobre a JPA do JBoss é que até o jboss-7.X o padrão é a implementação do JPA 2.0 já que o servidor atende às especificações da plataforma Java EE 6. Já nos wildfly do 8 pra cima, o suporte é à JPA 2.1. Mas nada impede voce de dizer para o JBoss excluir esse módulo na subida da sua aplicação (através do jboss-deployment-structure.xml) e subir sua própria JPA 2.1 como dependencia do projeto.
• JSF: esse também despensa apresentações. No JBoss 7.X o jsf não é apresentado como um módulo de forma separada, ele faz parte do módulo web. Já nas versões do wildfly 8 pra frente, ele já possui o módulo separado chamado JSF. Aqui vale chamar atenção para as versões dessa spec que os jboss implementam. Desde o JBoss Wildfly 7.X a versão é de implementação do JSF é a 2.1.7. Já no wildfly 8, 9 e 10 (server Java EE 7 certified) a versão de implementação é a 2.2. Quando sair um wildfly Java EE 8 certified (provavelmente a versão 11), aí a implementação do JSF será a 2.3. No entanto a versão 8 da plataforma tem tambem a spec do MVC 1.0 que está extremamente interessante. Vale a pena olhar.
• logging: esse módulo é mais uma facilidade para o desenvolvedor que não precisa se preocupar com API's de log. O próprio servidor te fornece essa api. Se o desenvolvedor não quiser mudar as configurações padrões de log do servidor, basta adicionar nenhum arquivo de configuração. Nesse caso, as configurações padrões ficam definidas dentro do seu próprio standalone.xml. Caso queira personalizar a geração de log, basta por um dos arquivos de configuração abaixo (o servidor irá procurar os arquivos nessa ordem):
• logging.properties
• jboss-logging.properties
• log4j.properties
• log4j.xml
• jboss-log4j.xml
• mail: API de emails do Java. Segue abaixo as versões do servidor e as versões da API utilizadas:
• JBoss 7.X utiliza a versão 1.4.4
• Wildfly 8.1.0 utiliza a versão 1.5.1
• Wildfly 9.0.2 utiliza a versão 1.5.3
• Wildfly 10.X utiliza a versão 1.5.5 (última versão da API)
• naming: Esse subsystem de naming, serve para definirmos objetos para lookup JNDI e a partir do wildlfy 8 (naming versão 2) permite habilitar ou desabilitar lookup JNDI remoto. Nesse link da jboss dá pra olhar exemplo das 4 formas de definir lookups:
• Simple
• Object-Factory
• External-Context
• Lookup
• OSGi: mesmo do ConfigAdmin. Ainda estou pesquisando sobre, mas parece que os dois trabalham juntos.
• POJO: Habilita o deploy de aplicações contendo JBoss Microcontainer Services (suportado pelas versões anteriores do servidor
• remoting: é o sub-sistema de comunicação remota do servidor. Através dele o wildlfy faz os look-ups remotos e acesso a EJB's remotos.
• SAR: Habilita o deploy de arquivos .sar que eram suportados em versões mais antigas do servidor. Os arquivos sar são um compactado como um war ou jar que possui MBeans internos. SAR significa Service Archive
• Security: 
• Transactions: Implementação do JTA (Java Transaction API) com o JBoss 7.X implementando a versão 1.1 e o wildfly 8, 9 e 10 implementando a versão 1.2
• Webservices: Esse módulo utiliza o Apache CXF para suporte ao JAX-WS (Construção de webservices com SOAP). A última versão do wildfly até o momento (10.1.0.Final) utiliza o Apache CXF 3.1.6.
• Weld: Implementação do CDI

Aí você me pergunta... pra que eu preciso de saber sobre isso ?
É simples. Por 3 motivos que considero bastante importantes:

1) Migração de aplicação: Quando você tem que fazer a migração do servidor do Wildfly 8 para 10 (como já foi meu caso). É extremamente importante você saber quais as versões das Specs da plataforma EE, os servidores implementam. Isso vai dar uma boa ajuda na hora de migrar aplicação.
2) Otimização do servidor: Muitas pessoas sobem o servidor com standalone-full.xml e nunca ao menos se perguntaram qual a diferença entre o standalone.xml e o standalone-full.xml. E pior... caso você utilize o Spring ao invés do Java EE, voce pode criar seu próprio arquivo standalone customizado subindo apenas os módulos que sua aplicação irá utilizar. Dessa forma, o servidor não precisa carregar um monte de coisas que não serão utilizadas (sim, eu sei que vários serviços ficam no modo passivo)
3) Desenvolvimento da aplicação EE: Caso você opte por criar uma aplicação que utilize as especificações da plataforma EE e vá utilizar os jars disponíveis no servidor de aplicação, é necessário que você saiba quais as versões das API's serão utilizadas. A vantagem nesse caso é que seu artefato (war ou ear) ficará com um tamanho extremamente reduzido.