USB2.0 PC Camera Driver - InfoScape

Depois de realizar muitas buscas sem sucesso, encontrei o driver compatível para a câmera de marca Infoscape.
Como alguns links estavam indisponíveis, então acabei disponibilizando no 4shared!

Segue o link para download abaixo: 

USB2.0 PC Camera Driver Setup

CEP's BRASILEIROS

- SQL com lista de CEP's brasileiros.

Atualizada em meados de 2009.
Não é a mais atual, mas já é um primeiro passo, concordam?
Vai que não pode consumir web service em seu sistema...resta-lhe colocar tudo dentro do banco!

Arquivo: ceps.zip

Sintomas da necessidade de um novo projeto

Venho por meio deste, fazer uma denuncia! Diante da situação do sistema encontrado na empresa “X”, torna-se necessária uma analise de criticidade do projeto de software adotado atualmente. O mesmo expõe vários sintomas que nos fazem acreditar que o projeto esta apodrecendo e embora ele ainda funcione corretamente por um tempo, vem se tornando uma bomba relógio.

O software citado acima possui as seguintes características:

Rigidez

Um projeto errôneo de estrutura da informação acarreta uma mudança em um módulo que provoca outras mudanças no formato cascata em módulos subseqüentes. No cenário atual, um erro “infantil” causa grande transtorno quando se torna necessária uma mudança em pequenos blocos de conteúdo no layout do sistema em questão. Conteúdos estáticos que poderiam ser resolvidos com uma simples “masterpage” e estilos CSS, alterados módulos a módulos.

Fragilidade

As falhas seguem e notamos que a falta de padrão de projeto é visível. Uma simples mudança de usuário, senha ou mesmo nome de base de dados implica em seguidos erros de conexão dentro do projeto, visto que para há varias formas a mesma e não há um arquivo de configuração único para armazenar tais detalhes.

Imobilidade

A falta de padrão peca em mais alguns detalhes do projeto. Vários desenvolvedores participaram de se desenvolvimento, cada um com o que eles próprios chamavam de POO e naturalmente desenvolveram tinham milhares de dependências ou mesmo, eram tão específicos que os impediam de ser reutilizados em outro projeto semelhante.

Viscosidade

Alterações em determinados módulos se tornam tão custosas que são evitadas ou até mesmo, se arruma um “jeitinho” para evitar uma refatoração de código que levaria um tempo considerável diante da situação atual, mesmo sendo uma opção válida para a situação.

Requisitos Variáveis

A falha na comunicação durante o levantamento de requisitos torna ainda mais difícil lidar com os requisitos variáveis do projeto. As idas e vindas de uma regra ou outra de negócio e a guerra de “egos” entre os stakeholders para atender ou não um requisito violam o projeto original, e tudo termina por alterações grosseiras de código para criar uma funcionalidade e atender uma especificidade de uma determinada área.

Gerenciamento de Dependências

Podemos notar que o projeto em questão convive diariamente com os quatro cenários acima, nos fazendo repensar a continuidade de seu desenvolvimento. A falta de planejamento e padrões durante o seu desenvolvimento tornou alguns dos mais importantes módulos desnecessariamente dependentes de outros menores.

OCP

O principio base desta técnica garante a criação de “módulos” que são extensíveis, sem serem alterados. Com um pouco de planejamento podemos adicionar funcionalidades ao código, sem alterá-lo, apenas adicionando novo código.

LCP

Garante que um objeto de uma classe base deve continuar a funcionar corretamente se o mesmo é instanciado através de uma classe derivada. Outro principio que deveria ser observado durante o desenvolvimento do projeto.

Túlio César Gaio

User Story Mapping

Como podemos definir tal técnica? É uma receita de bolo? Podemos dizer que é mais uma “bala de prata”? Ou um constante desafio, dependendo do contexto? Podemos dizer que o mais interessante é sua característica colaborativa que propicia uma discussão entre a equipe sobre as funcionalidades, incluindo uma ótica da experiência de uso dos usuários. Dificilmente destacaremos apenas vantagens de uma metodologia, embora em um cenário com premissas favoráveis, notam-se muitas vantagens em sua adoção.

Vale salientar alguns detalhes que se destacam em sua adoção. A técnica ajuda a equipe a escolher um conjunto de funcionalidades que sejam imediatamente valiosas do ponto de vista do negócio e ao mesmo tempo úteis para os usuários, desde que a equipe seja multidisciplinar ou tenha papéis bem definidos com poder para tomada de decisão. Ajudando na priorização e no planejamento de releases, obtemos detalhes sobre o usuário, freqüência de uso da funcionalidade e valor que ela tem para o negócio.

Os dois últimos itens acima merecem atenção especial, visto que, para projetos que temos uma prévia experiência sobre o assunto, seja ela fruto do conhecimento da equipe ou mesmo de outros projetos presentes no mercado, tais variáveis são mais simples de mensurar. Do contrário, em um projeto inovador, uma vez que o modelo ainda não está estável o suficiente, não existe dentro da equipe um consenso em relação a tais variáveis, tornando sua avaliação complexa e passível de outros métodos de análise, como pesquisas de campo, questionários, entre outros.

Ao realizar as etapas, algumas delas acarretaram discussões acaloradas. Ao realizar descrição das tarefas realizadas pelo usuário, ao adicionar informações quanto à freqüência de uso, a cada uma das tarefas das user stories, e na definição de valor para o negócio de cada user story, sendo essa de fundamental importância a participação de uma pessoa que tenha mais visão de retorno de investimento do sistema. Vale lembrar que toda equipe (e os stakeholders) podem participar destas etapas, o que naturalmente em alguns cenários torna o processo um pouco complicado de se chegar a um consenso, pois os interessados podem convergir o desenvolvimento de suas funcionalidades primeiro e sem critérios, o que necessariamente requer certa intervenção.

A idéia é contar uma história de como o sistema funciona, ajustando os cartões por criticidade verticalmente seguidos pela freqüência de uso horizontalmente, o que nos da uma visão muito clara e compartilhada do sistema como um todo, alinhando expectativas e idéias entre a equipe, afinal nesse momento no nosso mapa, sabemos as funcionalidades que não poderiam ficar de fora do release, principalmente quando estas representavam uma tarefa que fazia parte de um fluxo de uma atividade importante para os usuários.

Na definição de release o mais importante neste momento é a percepção de que todos compreendem melhor o produto que será desenvolvido. Esta visão compartilhada ajudará nas etapas posteriores de desenvolvimento do produto, quando novas idéias de funcionalidades apareceram e novos releases precisaram ser replanejados.

E finalmente e não menos importante tal técnica em sintonia com a abordagem ágil, ajuda a evitar o desenvolvimento de funcionalidades inúteis, e a manter a simplicidade da interface com o usuário. Como podemos perceber, a técnica oferece recursos para facilitar processos em metodologias ágeis, se fazendo presente e varias etapas destes processos. Mas não posso deixar de questionar: seria valido adotá-la em um processo tradicional? Seria possível usá-la isoladamente de qualquer abordagem? Creio que sim, e de forma empírica, aprender a lidar com as implicações que estariam por vir. Mas esta questão vale outra discussão!

Túlio César Gaio

Recomendações para utilização de Métodos Ágeis

Trabalho apresentado na primeira disciplina da pós-graduação, "Metódos Ágeis de Desenvolvimento de Software" ministrada pelo professor Marcio Sete.

Prezado Sr. Adriano,

Avaliando o atual cenário presente na ACME Air Lines (fictícia),  apresento-lhe uma abordagem no mínimo instigante, capaz de fazê-lo reavaliar princípios e práticas anteriormente adotadas que um dia já foram capazes de lidar com os processos muito bem definidos de sua empresa. Vale salientar que grandes empresas estão adotando tal modelagem e mudando paradigmas relacionados ao desenvolvimento de software.

Falo-lhe da Modelagem Ágil que vem ganhando credibilidade e espaço nas empresas, afetando positivamente o ciclo de vida dos projetos. Diante da complexidade dos projetos atualmente, tornam-se necessárias práticas que lidem com a realidade emergente dos processos e suas organizações. Portanto, a modelagem ágil dispõe de vários princípios, adaptando-se aos mais variados cenários, sendo possível a escalabilidade para projetos de pequeno, médio e grande porte. Incrementalmente e iterativamente, ela disponibiliza artefatos de valor para o projeto, tornando-o transparente, de visibilidade comunitária e bastante clara. Vale lembrar que o uso de frameworks e ferramentas CASE é de fácil configuração, naturalmente e sem excessos, tais recursos irão se fazer necessários, trazendo contigo informações importantes para o projeto em questão.

Modelagem ágil não é uma “receita de bolo” nem ao menos uma “bala de prata”, que seguida passo a passo trará o mesmo resultado a todos os projetos. Diferente do que se parece, ela apenas complementa os métodos existentes, pois não é completa. Abordagem essa que tem embasamento prático, de mercado e adotado por grandes empresas. Ela não funciona sozinha, depende de profissionais competentes para implementá-la, através de documentação simples e clara, se excessos ou milhares de ferramentas CASE.

Tal modelagem serve de apoio para outros processos, visto que provêm documentação de valor para o mesmo. Seus três objetivos pilares, garantem um melhor implantação e implementação de processos como XP, UP, SCRUM, entre outros. Com documentação compreensível, precisa, consistente e suficientemente detalhada para reforçar o desenvolvimento da Metodologia Ágil adotada.

Portanto, torna-se necessário explorar como podemos melhorar a modelagem em processos descritivos adotados na empresa, definindo como colocar em prática os valores, princípios e práticas de forma eficaz e leve, adotando se necessário, técnicas de modelagem através de uma abordagem ágil. Tais valores implicam na renovação de conceitos importantes para a modelagem ágil.

Primeiramente, a forma de comunicação deve ser reavaliada, para torná-la mais clara e objetiva, adotando métodos mais eficazes, ou seja, modos de comunicação mais ricos, que possibilitem uma interação e feedback mais rapidamente entre as pessoas, incluindo até mesmo o uso de ferramentas simples para tornar a informação publica e transparente. Contribuindo assim positivamente com fatores que afetam diretamente a comunicação, com pessoas trabalhando juntas física e temporariamente, transferindo direta e indiretamente informações através de uma conversa ou mesmo percebendo o ambiente a sua volta.

Outro ponto importante é tornar os modelos mais simples possíveis e iterativamente desenvolvê-los acompanhando gradativamente o projeto. Naturalmente ele refletirá mais precisamente a realidade do projeto e suas mudanças emergentes durante o ciclo atual de seu desenvolvimento.

Vale salientar que devemos nos esforçar para obter feedback rápido sobre o trabalho para garantir que ele reflita as necessidades dos stakeholders do projeto. Sendo assim, desenvolva o modelo em equipe, revisando-o com seu público-alvo e atualizando sempre que necessário. Preocupe-se também em tirar as idéias do papel, implementando o que foi planejado e entregando naquela etapa todos os produtos previstos para a iteração corrente. E durante o ciclo de desenvolvimento, não exite em levantar detalhes que possam prejudicar o andamento do mesmo, e de forma humilde e transparente repasse detalhes para resolver os possíveis impedimentos que surgirem.

Além dos supracitados, alguns princípios da Modelagem Ágil defendem atividades que precisam da compreensão e apoio dos stakeholders, assim como empenho da equipe responsável pelo desenvolvimento do projeto. Mudanças claras na visão de projetos dos mesmos se fazem necessárias e de grande valia. Destacando alguns não menos importantes, como, ter em mente que o software e o foco central da modelagem, portanto modele com simplicidade e propósito, criando vários modelos que agreguem valor ao projeto, focando sempre em obter um feedback rápido, maximizando o retorno do investimento dos stakeholders.

Sintetizando objetivos, valores e princípios, algumas boas práticas vem trazendo benefícios aos adeptos da modelagem ágil. São elas:

• Modelagem Incremental e Iterativa, onde a cada iteração do projeto, apoiando-se nos artefatos corretos e modelando apenas o necessário para cada etapa, obtém-se documentação clara e objetiva.

• Existe um equipe responsável pelo projeto, portanto, não assuma a responsabilidade sozinho, compartilhe idéias e juntamente com os responsáveis pelo projeto crie as documentações necessárias e torne-as publicas de forma transparente.
• Abuse da simplicidade. Crie conteúdo simples, seja objetivo para apresentá-lo e com ferramentas eficientes para a criação dos mesmos, sem excessos.
• Implemente o que está documentado, considerando inclusive os testes e prove que o planejado é possível.
• Não descarte totalmente as normas de modelagem se for possível, sem excessos e se possível reutilize recursos.
• Documentação
• Crie modelos realmente úteis, que agregam valor ao projeto e se necessário, crie os documentos previstos em contrato, atualizando-os somente quando necessário.
• Modele para se fazer entender e se comunicar, para descomplicar.

    De forma empírica, precisamos avaliar a situação do projeto dia-a-dia , e com flexibilidade nos adaptar as mudanças, sabendo exatamente quando ir além das próprias boas práticas.

    Sugiro adotar as seguintes atividades: modelagem inicial de requisitos, que é quando vamos identificar o escopo de alto nível e a pilha de requisitos inicial e fazer uma modelagem inicial da arquitetura, que é apenas uma visão arquitetural do projeto. Após este chamado Ciclo 0, partimos para as iterações, onde primeiro fazemos o chamado Model Storming, que deve ser rápido, envolver poucas pessoas e bem objetivo, serve para levantar uma questão pra resolver e desenhar um modelo que o resolve em um quadro branco ou papel. O próximo passo seria passar para a implementação (ideal ser dirigido a teste) com uma abordagem TFD. Uma outra atividade são as revisões de modelos e inspeção de código, este é considerada opcional, porém são praticas muito úteis, pois garantem a qualidade e dão um bom feedback.

A abordagem da modelagem ágil (AMDD) tem um fluxo de desenvolvimento de um modelo bastante simples e eficiente que vai de acordo com todo o pensamento ágil, no ponto em que ele prega que devemos fazer somente o necessário e que devemos ser flexíves, pois situações diferentes pedem medidas diferentes. O fluxo do desenvolvimento, começa com uma discussão sobre o assunto, e modelamos se necessário para entender o que estamos falando, caso seja necessário devemos fazer de forma simples com uma ferramenta simples, e partir para a codificação manual, ou realizar essa modelagem em uma ferramenta case que gere o código fonte. No caso da ACME a solução seria adotar a pratica de sempre modelar para entender, e codificar manualmente.

Vejo que a ACME se preocupa muito com documentos e mais documentos, "esquecendo-se" as vezes do que realmente importa, o que os interessados realmente esperam como produto final, a ideia é implantar a documentação ágil, na qual é concisa, precisa, consistente e detalhada. Vamos documentar somente informações que são menos prováveis de mudar, e descrever "coisas boa de saber", e para realizar essa documentação na abordagem ágil contamos com os modelos ágeis, que é composto por 8 tipos ou grupos de artefatos, um para escopos diferentes do “projeto”, e cada tipo é composto por inúmeros artefatos que nos auxiliam na documentação, vou citar alguns para que fique já como sugestão:

• Testes de aceitação, que é uma abordagem simples e eficaz, pois dificilmente alguma demanda entrará em produção com algum bug, pois passará por testes de caixa preta, por usuários como se fossem os finais, e em ambientes que simulam o de produção.
• Diagrama de Classe da UML, que é um dos principais diagrama da UML, muito útil para nós, pois ilustram as classes, interfaces e relacionamentos entre elas, nos dando uma visão geral do núcleo do sistema.
• Diagrama de Interface de Usuário, nos permite modelar as interações que os usuários têm com o software, conforme definido em um único caso de uso, bem como obter uma visão geral de alto nível da interface do usuário para sua aplicação.
• Diagrama de pacotes, para usarmos permitindo ter uma visão mais arquitetural, pois ele separa o sistema em modulos ou pacotes, e define os relacionamento entre eles.
• Diagrama de sequência, que iremos usar na modelagem de objetos, pois este diagrama “desenha” muito bem a sequência de processos, e mais especificamente as mensagens entre os objetos.
• Diagrama de Atividades UML, são normalmente utilizados para a modelagem de processos de negócios, modelando a lógica capturada por um único caso de uso ou cenário de uso, ou para modelar a lógica detalhada de uma regra de negócio.

Vale lembrar quais são as verdadeiras razões que realmente importam e justificam uma documentação em nossos projetos, que seria usarmos para definir um modelo de contrato, apoiar a comunicação de um grupo externo e que os envolvidos no projeto precisam de uma documentação.

Para finalizar no que se diz respeito ao gerenciar os requisitos, a abordagem BRUF, que temos utilizado é muito falha, o custo é altíssimo colocar os grandes requisitos em primeiro na ordem de execução. Com o gerenciamento ágil de requisitos definimos a ordem dos requisitos por prioridades, por o que realmente precisamos primeiro, e novos requisitos são colocados na fila para ser priorizados, e depois implementados nas iterações, que poderão ser desenvolvidos junto a uma abordagem de gerenciamento ágil de processos, como por exemplo, no SCRUM em seus sprints, mas isto fica para um segundo momento.

Atenciosamente,

Túlio César Gaio

Willian Douglas Gaio Gualberto

Belo Horizonte, 20 de Outubro de 2010.

UBUNTU 9.10 APACHE TOMCAT MOD_JK

Depois de muito buscar, consegui reunir informações para criar um ambiente que permitisse a integração entre o PHP + JAVA + LINUX, usando MOD_JK. Partindo de uma instalação inicial do Ubuntu 9.10.

Vale lembrar que para outras versões do Ubuntu até hoje, 16/11, se não me engano a Ubuntu 10.10, o mecanismo funciona com pequenas alterações entre as versões dos pacotes.

UBUNTU 9.10 APACHE TOMCAT MOD_JK

instalar apache2, php mysql
sudo apt-get install apache2 php5 php5-cli php5-gd libapache-mod-php5 mysql-server-5.1 mysql-client-5.1 phpmyadmin

instalar sun-java-jdk tomcat libapache2-mod-jk
sudo apt-get install sun-java6-jdk tomcat6 tomcat6-admin tomcat6-common tomcat6-docs tomcat6-examples tomcat6-user libapache2-mod-jk

editar .bashrc
sudo nano /home//.bashrc
export JAVa_HOME=
export PATH=$JAVA_HOME/bin:$PATH

* salvar arquivo

sudo a2enmod jk

sudo nano /etc/libapache2-mod-jk/workers.properties

workers.tomcat_home=
workers.java_home=
ps=/
worker.list=ajp13_worker
worker.ajp13_worker.port=8009
worker.ajp13_worker.host=localhost
worker.ajp13_worker.type=ajp13
worker.ajp13_worker.lbfactor=1
worker.loadbalancer.type=lb
worker.loadbalancer.balance_workers=ajp13_worker

* salvar arquivo

sudo nano /etc/apache2/mods-available/jk.conf

JkWorkersFile /etc/libapache2-mod-jk/workers.properties
JkLogFIle /var/log/apache2/mod_jk.log
JkLogLevel info
JkMount /JAVA ajp13_worker

* salvar arquivo

sudo ln -s /etc/apache2/mods-available/jk.conf /etc/apache2/mods-enabled/jk.conf

sudo nano /var/lib/tomcat6/conf/server.xml

* descomentar linha

... <Connector port="8009" protocol="AJP/1.3" redirectPort="8443">

* salvar arquivo

sudo nano /etc/apache2/sites-available/default

... <Directory /var/lib/tomcat6/webapps/ROOT>

# Options Indexes FollowSymLinks MultViews
Options None
AllowOverride None
Order allow,deny
allow from all

.. </Directory>

JkMount /JAVA ajp13_worker

* salvar arquivo

Reinicie os servidores web (apache e tomcat).
Digite no browser 127.0.0.1 (Para acessar o apache) e 127.0.0.1/JAVA (Para acessar o tomcat).
Atenção para a pasta JAVA, a mesma contém sua aplicação e pode ser customizada.

LISTA DE ESTADOS E CIDADES BRASILEIRAS

- Sql para criar uma tabela de estados e cidades brasileiras, devidamente relacionados.
- 27 estados
- 9714 cidades

Arquivo: cidades_estados.zip