sábado, 7 de abril de 2018

Controle de versão de código distribuído na prática


Dando continuidade ao Post anterior, vamos praticar um pouquinho do assunto utilizando o GIT.

O Git é um versionador do tipo distribuído. De modo dar total praticidade ao assunto, vamos nos ater aos comandos do GIT. (detalhes de instalação deverão ser pesquisados na Internet, ok?

Vamos pensar no seguinte cenário: dois desenvolvedores resolvem trabalhar num projeto de um site. 

Como falamos no post anterior, cada desenvolvedor terá uma área de trabalho e um repositório local. 

Além desses repositórios ficou acertado entre os desenvolvedores que deveria existir um repositório central hospedado no github.

Bom, os desenvolvedores deverão ter instalados o Git em suas respectivas máquinas e cada ter uma conta no GitHub.

O primeiro passo é criar um diretório para colocar os arquivos desse projeto. Vamos chamar esse diretório de projetoSite (no meu caso criei o diretório em C:\Users\Hugo Neto\projetoSite). 

Feito isso, é necessário dizer ao Git que você quer transformar este diretório em um repositório, ou seja, que os arquivos ali inseridos deverão ter suas alterações controladas e versionadas pelo Git. Como fazer isso? Abra o terminal de seu computador, navegue até o diretório criado e em seguida utilize o comando “git init”. O git retornará a mensagem  abaixo:



Em seguida vamos nos imaginar como um dos programadores e criar a página inicial do site objeto do projeto com as características da figura abaixo. Vamos chamar essa página de index.html e vamos salva-la no diretório criado para o projeto.



A princípio, podemos imaginar que o arquivo jogado no diretório criado já está sendo controlado pelo Git. Entretanto não é assim que a coisa funciona. Para verificar quais arquivos estão sendo controlados/trackeados pelo Git devemos executar o comando git ls-files.






Repare que ao executar esse comando, o Git não retornou o arquivo que nós salvamos no diretório. Para que isto aconteça, é necessário executar o comando git status.

















Ao executar este comando, o git lista o arquivo que salvamos no diretório e informa que este arquivo está untracked, ou seja, que ele ainda não está sendo controlado pelo Git. Para que o Git comece a trackear o arquivo, é necessário executar o comando Git add

















Feito isso, ao executarmos o comando git status novamente, o Git listará o arquivo index.html como tracked. Nessa situação, podemos dizer que o arquivo encontra-se na área de trabalho do desenvolvedor. Após as alterações realizadas no arquivo, o desenvolvedor deve commitar essas alterações através do comando Git commit. Ao fazer isso, o desenvolvedor grava a revisão do arquivo no repositório local.















Repare que incluímos ao comando git commit a opção -m(mensagem) para descrever a alteração realizada. Note também que o git exibiu uma mensagem solicitando a identificação de quem está realizando o commit. Para informamos isso usamos os comandos git config as opções user.email “email@email.com.br”  e user.name=”seu nome”















Ao executar o comando novamente, o git comitará o arquivo para o repositório local. Ao executar o comando git status novamente, o git informará que não existem alterações a serem comitadas para o repositório.















Vamos fazer mais algumas alterações no arquivo. Verificamos que a palavra “incial” presente no título da página está incorreto. Vamos corrigir a palavra e verificar o status do nossa área de trabalho.




sábado, 17 de março de 2018

Controle de versão???


Controle de versão???

Impressionante o quanto evolui esse negócio de TI. Atividades ligadas a desenvolvimento de software que antes eram traumáticas e que demandavam bastante tempo, agora estão mais suaves e mais ágeis.

Mesmo quando trabalhamos sozinho, levando-se em conta que podemos ter que sustentar várias versões de um mesmo sistema, corremos o risco de sobrescrever algum código fonte.

Imagine quando trabalhamos em equipe e temos que lidar com várias pessoas fazendo sustentação ao mesmo tempo de várias versões desse sistema? Sem dúvida, uma situação no mínimo caótica.

Quem nunca sobrescreveu o código de algum colega por acidente que atire a primeira pedra. O trabalho em equipe também implica em dificuldade em responder questões do tipo quem, quando e quais alterações foram feitas no código fonte do sistema. Como recuperar código de versões anteriores a versão de produção e ainda como manter variações do sistema ao mesmo tempo. Foda, né!? As soluções de controle de versão surgiram para sanar esses problemas.

Como funciona?

As soluções são compostas basicamente de duas partes: Um repositório que armazena todo o histórico de evoluções do código, registrando toda e qualquer alteração feita sobre ele e um local conhecido como Área de Trabalho que contém a cópia do arquivos do projeto que é alterada pelos desenvolvedores. Cada desenvolvedor possui uma área de trabalho.

Para manter o repositório atualizado e a área de trabalho de cada desenvolvedor atualizada de acordo com as versões de código dos demais colegas de trabalho, é necessário realizar uma sincronização entre esse repositório(com código desenvolvido pela equipe) e a trabalho de cada desenvolvedor presente em sua área de trabalho.

Chamamos de COMMIT a operação de atualização do repositório e de UPDATE, a operação de atualização da área de trabalho.

Cada COMMIT gera uma nova revisão(tira uma espécie de foto) no repositório contendo as modificações feitas, a data e o autor dessas modificações.  

No exemplo que dei, existe um único repositório e várias áreas de trabalho o que confere a solução de controle versão, um viés CENTRALIZADO, mas existem também cenários nos quais podemos ter além de uma área de trabalho, um repositório para cada desenvolvedor, dando a solução um esteriótipo DISTRIBUÍDO.

As operações de sincronização entre a área de trabalho e o repositório local continuam as mesmas neste caso. Entretanto, para trabalhar em conjunto com outros desenvolvedores, é necessário haver o sincronismo entre os repositórios locais dos desenvolvedores envolvidos no projeto.

PULL(puxar) é o nome dado a operação de atualização de um repositório local(destino) com todas as alterações feitas em outro repositório(origem).

PUSH(empurrar) é a operação responsável por enviar as alterações do repositório local(origem) para um outro repositório(destino), ou seja, não existe um repositório local mais importante que o outro, embora seja interessante atribuir um desses repositórios com sendo central, de modo a organizar o fluxo de trabalho.

Para cópia de um repositório para a área de trabalho, utilizamos a operação CLONE(no caso de soluções distribuídas) ou CHECKOUT(no caso de soluções centralizadas).

As revisões registradas no repositório precisam ter uma identificação única. No caso de soluções centralizadas, cada revisão recebe um número sequencial, mas como isso é feito em uma solução distribuída? Nestes casos, um hash é utilizado como identificador o que torna improvável a repetição com um hash produzido por outro repositório.

Como dissemos inicialmente as soluções de controle de versão visam possibilitar o trabalho concorrente de vários desenvolvedores sobre os mesmos arquivos, evitando que um sobrescreva o código dos outros. Mas como isso é feito? Em parte, a existência da área de trabalho resolve esse problema, entretanto como é possível mediar os conflitos de alterações código feitas no momento da sincronização entre a área de trabalho e um repositório por exemplo? A solução de controle de versão combina as revisões cocorrentes em uma única resultante através de uma operação a qual chamamos de MERGE(mesclagem).

Explicação através de um exemplo:

Fulano  e Beltrano são desenvolvedores da empresa  X.

Quando chegam a Empresa para trabalhar, eles realizam cada um, uma operação de checkout em suas áreas de trabalho(Neste momento as áreas de trabalho deles encontram-se no mesmo estado).

Os dois desenvolvedores executam modificações no código fonte presente em suas áreas de trabalho.

Beltrano publica as modificações feitas por ela no repositório.

Quando Fulano tenta publicar as modificações feitas por ele no repositório, o controlador de versão recusa a publicação alegando que as alterações feitas por ele foram realizadas em arquivos desatualizados, visto que os arquivos alterados por Fulano já haviam sido atualizados por Beltrano antes.

Neste caso será necessário que Fulano antes de tentar atualizar o repositório, faça uma operação de UPDATE de modo a atualizar a área de trabalho dele com as alterações realizadas por Beltrano. (Nessa operação, o controlador de versão já mescla automaticamente as revisões feitas por Fulano e Beltrano).

Após conferir se a atualização e a mesclagem produziram o resultado desejado, Fulano envia as mudanças para o repositório. Beltrano resolve continuar a trabalhar executando novas alterações e não terá problemas com o controlador de versão, caso a versão do código área de trabalho dele não esteja conflitando com versões de código já enviadas por Fulano para o Repositório.

O exemplo se adequa perfeitamente a um cenário de controlador de versão centralizado. Vejamos como ficaria essa situação em um cenário de controlador de versão distribuído:

Roberto clona o repositório de Aline. Agora ambos partem do mesmo ponto.

Aline e roberto publicam suas alterações nos seus respectivos repositórios, sem interferir no repositório um do outro.

Para sincronizar seu repositório com as revisões publicadas por Aline, Roberto realiza uma operação de PULL cuja origem é o repositório de Aline. Isso não afeta a área de trabalho de Roberto.

A mesclagem das revisões realizadas por Aline e Roberto se dão na área de trabalho de Roberto através de uma operação de MERGE.

Após verificação do resultado,  Roberto envia as mudanças ao seu repositório. Em paralelo Aline publica outras alterações em seu repositório.

Roberto envia as revisões feitas por ele ao repositório de Aline, que as combina com o histórico de revisões já existente.

No próximo post, colocaremos isso em prática utilizando o GIT, uma solução gratuita de controle de versão de código disponível para instalação em diversas plataformas. Até lá

domingo, 20 de novembro de 2016

jQuery

Sou do tempo em que tínhamos que programar JavaScript na unha. Na época, chamávamos programação CORE esse tipo de programação. Com o tempo foram aparecendo o que o pessoal conhece com framework.

Vamos entender o porquê do uso de frameworks ter crescido e ganhado tantos adeptos nos últimos anos de desenvolvimento web.

Quando queremos criar sites responsivos, de fácil manutenção, entre outras funcionalidades, é muito difícil e trabalhoso de se fazer manualmente e é aí que entram os frameworks, facilitando o trabalho do desenvolvedor.
E é exatamente por isso que os desenvolvedores web gostaram tanto de utilizar frameworks.

jQuery é um excelente framework pois ele é rápido e leve, podendo ser criadas animações, manipulações de eventos, entre outras. O Ajax também é uma API muito fácil de usar e que é compatível com a grande parte dos navegadores. Sem dúvidas o jQuery definitivamente mudou o jeito de desenvolver na internet e mudou para melhor.
Muito utilizado por grandes empresas e projetos como Wordpress, Wikipédia, etc. Em resumo, objetivo do jQuery é tornar mais fácil o uso do JavaScript.

Resumo:

  • jQuery é uma biblioteca JavaScript.
  • jQuery simplifica muito a programação JavaScript.
  • jQuery é fácil de aprender


O que você deve saber antes de estudar jQuery:


  • HTML
  • CSS
  • JavaScript


jQuery também simplifica um monte de coisas complicadas de JavaScript, como chamadas Ajax e manipulação DOM.

A biblioteca jQuery contém os seguintes recursos:


  • HTML / manipulação DOM
  • manipulação de CSS
  • métodos de eventos HTML
  • Efeitos e animações
  • AJAX
  • Utilities


Adicionando jQuery às suas páginas Web

Existem duas maneiras de começar a  usar jQuery em uma página HTML. Você pode:

  • Baixar a biblioteca jQuery de jQuery.com
  • Incluir jQuery de uma CDN, como o Google

Ambas as versões podem ser baixados do jQuery.com.

Para chamar a biblioteca jQuery devemos referenciar a biblioteca através da tag script


       


Com jQuery você seleciona elementos HTML e executa "ações" sobre eles.

Sintaxe

sintaxe básica é: $(selector).ação()

Um sinal $ para definir um acesso  jQuery.
Um (selector) para "consultar (ou encontrar)" elementos HTML
Uma ação jQuery () a ser executada com o elemento (s)

Exemplos:

$(This).hide() - esconde o elemento atual.

$("P").hide()  - Oculta todas elementos do tipo Parágrafo.

$(".Test").hide - Esconde todos os elementos com a class = "test".

$ ("# Test").hide()- Esconde o elemento com id = "test".

jQuery usa a sintaxe CSS para selecionar elementos.

Você deve ter notado que todos os métodos jQuery em nossos exemplos, estão dentro de um evento do seletor Document:

$(Document).ready(function(){
   // métodos jQuery aqui ...
});

Isso é para evitar que qualquer código jQuery ocorra antes que o carregamento do documento seja concluído.

É uma boa prática que esperar que o documento seja totalmente carregado e pronto antes de trabalhar com ele.

Aqui estão alguns exemplos de ações que podem falhar se os métodos são executados antes que o documento está totalmente carregado:


  • Tentar esconder um elemento que ainda não foi criado
  • Tentar obter o tamanho de uma imagem que ainda não está carregado

seletores


  • seletores de consulta são uma das partes mais importantes da biblioteca jQuery.
  • seletores permitem selecionar e manipular elemento (s) HTML.
  • seletores são usados ​​para "encontrar" (ou selecionar) elementos HTML com base em seu nome, id, classes, tipos, atributos, valores de atributos e muito mais. 
  • baseado nos seletores CSS existentes, e, além disso, tem algumas seletores personalizados.


Todos os seletores em jQuery começam com o sinal de dólar e parênteses: $ ().

O seletor de elemento jQuery seleciona elementos com base no nome do elemento.

Você pode selecionar todos os elementos em uma página como esta:

$("P")

Exemplo:









If you click on me, I will disappear.
Click me away!
Click me too!




Quando um usuário clica em um botão, todos os elementos do tipo "P" ficarão ocultos.
Outros seletores ver http://www.w3schools.com/jquery/trysel.asp

Eventos

Todas as ações do visitante realizadas em uma página web que pode ser capturada pelo Browser são chamados de eventos.

Um evento representa o exato momento em que algo acontece.

Exemplos:
  • movendo a seta do mouse sobre um elemento
  • selecionando um botão de rádio
  • clicar em um elemento
O termo "disparado" é usado frequentemente com eventos. Exemplo: "O evento keypress é disparado, no momento em que você pressionar uma tecla".


No exemplo acima temos dois eventos o ready e click.

Sintaxe jQuery para métodos de evento

Em jQuery, a maioria dos eventos DOM tem um método jQuery equivalente.

Para atribuir um evento de clique a todos os parágrafos de uma página, você pode fazer o seguinte:

$("p").click();

Abaixo uma série de eventos jQuery:







Mais sobre jQuery http://www.w3schools.com/jquery/


domingo, 28 de agosto de 2016

Descomplicando uma sopa de letrinhas chamada Business Intelligence

Você faz parte de uma equipe de TI de uma empresa relativamente nova. Desenvolve um sistema de gestão para a mesma, visando a este apoiar as atividades dos colaboradores de outras áreas da Empresa.

Daí o gerente da área de vendas da Empresa pede um relação das vendas efetuadas nos últimos três anos. Mais tarde, esse mesmo gerente solicita a relação dessas vendas agrupados por Vendedor, de modo a calcular as comissões a serem pagas para esses vendedores. A Empresa vai crescendo, inaugurando uma filial a cada ano e consequentemente o volume de vendas, de vendedores e de dados sobre as vendas também.

Aquela relação solicitada constantemente pelo Gerente cresce exponencialmente dificultando a análise desta, além de onerar o Banco de Dados alimentado pelo velho e bom Sistema de Gestão mantido por você. Seu Gerente que muitas vezes não entende nada de TI, fala que vem recebendo uma série de reclamações sobre a lentidão do Sistema e fala pra você se virar de modo a resolver o problema.

Para complicar ainda mais, surgem novos pedidos de informações de vendas daquele e de outros gerentes de outras áreas da Empresa. Você então pensa: "Vou ter que extrair essas informações em horários de vale (momentos em que os usuários não estão utilizando o Sistema). A empresa começa a receber uma quantidade imensa de pedidos e resolve ampliar o expediente de trabalho de modo a atender esses pedidos. Extrair as informações fica cada vez mais difícil, mais demorado.

Os colaboradores da Empresa começam a reclamar da demora na entrega das relações solicitadas a equipe de TI. Chega um momento que você não consegue mais atender as solicitações dos colaboradores no tempo que as atividades da Empresa exige. Daí você pensa: "Tô fudido!" e se pergunta:"O que fazer?".

Ao mesmo tempo, aquele diretor que tomava as decisões baseado nas experiências dele  deixa a Empresa e no lugar dele, entra um camarada bem intencionado, mas que não possui experiência tão aprofundada quanto a do antigo diretor.

O novo diretor chega e demanda informações dizendo que a Empresa está perdendo vendas por falta de produtos em alguns momentos e em outros, tendo que fazer promoções por conta de muito produto em estoque. Daí você pensa:"Dá zero pra ele! Será que esse diretor não é burro?". E daí ele fala pra você: "Arruma uma solução, ô inteligência!"

Você então começa pensar num modo de resolver a situação. O diretor precisava se basear em informações para tomar decisões. Por mais que o diretor tivesse experiência, dependendo do cenário, as decisões por mais que pareçam estar corretas poderiam acarretar em consequências desastrosas para a Empresa.

A conclusão a que você vai chegar é que a empresa deveria adquirir uma inteligência de modo a evitar e prever problemas futuros para o negócios da Empresa. E é aí que o BI (Business Intelligence), surge.

Hoje em dia o pai Google tem solução pra tudo. Você digita  algo no google rezando pra que surja uma resposta. Entaum o Google mostra um monte de coisas.BI,OLAP,OLTP, DW, modelagem dimensional...  Pesquisando um pouco mais, eis que surge o nome de um camarada de sobrenome "Kimbal" que já vinha pensando sobre o assunto há muito tempo.

A primeira conclusão a que você vai chegar é que não devemos utilizar a base de dados do Sistema de gestão para extrair as informações para apoiar a decisões da empresa. Segundo a terminologia esses sistemas são conhecidos como OLTP (Online Transaction Processing ou Processamento de Transações em Tempo Real) são sistemas que se encarregam de registrar todas as transações contidas em uma determinada operação organizacional.

Bom, se você não pode usar o Sistema de Gestão da Empresa, e muito menos a base de dados que ele alimenta, como resolver o problema? A solução será utilizar ou desenvolver um outro tipo de sistema que proporcione a capacidade de ter idéias sobre os dados, permitindo analisá-los profundamente em diversos ângulos. Esses sistemas são classificados como do tipo OLAP (Online Analytical Processing).

Para modelar o Sistema de Gestão, você fez uso da metodologia de modelagem do tipo Entidade - Relacionamento. O tal do Kimball preconizou que para modelar uma base de dados para um sistema do tipo OLAP deveria se fazer isso de um jeitão meio diferente. Surge então modelagem dimensional, onde a ideia é criar um modelo que se destine à análise de dados. No que diz respeito à análise de dados, o que se espera do modelo de dados para um sistema OLAP é que:
  • Seja uma representação simples do modelo de negócios estudado;
  • Seja um modelo físico de fácil interpretação, de modo que usuários sem treinamento formal em TI possam entendê-lo;
  • Facilite a implementação física do modelo de modo a maximizar performance das consultas aos dados.
 Portanto, no modelo multidimensional, deixamos de focar a coleta de dados para nos ocuparmos com a consulta aos dados.

Isso não quer dizer que você deva esquecer a modelagem relacional. Tudo o que sabemos a respeito de modelagem relacional, vale novamente para a modelagem multidimensional.  Na modelagem multidimensional, teremos novamente que identificar entidades, tabelas, atributos, chaves primárias, integridade referencial e normalização. A principal diferença está em relação à normalização.

O modelo multidimensional usa sim normalização, mas considera apenas até a Segunda Forma Normal.

Damos o nome de modelo multidimensional ou modelo relacional em esquema estrela por causa da distribuição das tabelas no diagrama. Teremos sempre uma tabela central, que armazena as transações que vamos analisar. Esta tabela é chamada de tabela fato. Ao redor da tabela fato, temos as tabelas que chamamos de dimensões.



Todas as dimensões se relacionam exclusivamente com a tabela fato, daí a referência da estrela.

Traduzindo isso para o modelo proposto inicialmente, temos como resultado o modelo a seguir:



Este modelo é chamado de estrela porque a tabela de fatos fica ao centro cercada das tabelas dimensionais assemelhado a uma estrela. Mas o ponto forte a fixar é que as dimensões não são normalizadas.

No final das contas, o que nos importa é que a tabela fato armazena os indicadores que iremos analisar e as chaves que caracterizam a transação. Estas chaves são os elos de ligação com as tabelas de dimensão. Estas, por sua vez, armazenam as classificações que usaremos para analisar os indicadores. Cada dimensão registra uma entidade que caracteriza a transação e mais todos os atributos associados a esta entidade.

Algumas implicações sobre este modelo são descritas a seguir:

Característica 1 - Uma das candidatas a chave primária da tabela fato seria uma chave composta pelas chaves primárias de todas as dimensões.

Característica 2 - As dimensões devem conter todos os atributos associados à sua chave primária. Por exemplo: digamos que temos uma dimensão TEMPO no nosso modelo que monitora transações por dia. Neste caso, a dimensão conteria todos os atributos relacionados à chave dia: mês, trimestre, ano, dia da semana, semana do ano, etc. 

É por conta desta característica das dimensões que dizemos que o modelo multidimensional está na Segunda Forma Normal. Para lembrar um pouco da teoria sobre normalização, observe que as tabelas do modelo identificam as entidades descritas (não possuem tabelas aninhadas) e cada atributo não-chave da chave primária inteira.

Mas o modelo não atende à Terceira Forma Normal, porque, neste caso, suas tabelas precisariam respeitar os dois critérios que acabamos de descrever e ainda atender a mais um: que não existam dependências entre atributos não chave. Claramente isso não acontece com as tabelas de dimensão, que incluem até as hierarquias de atributos associados à chave primária.

Característica 3 - Os atributos de cada dimensão devem ser organizados em uma seqüência lógica que caracterize a(s) hierarquia(s) relacionada(s) à chave primária.

Dizemos que existe uma relação hierárquica entre dois atributos quando há entre eles uma relação de um para muitos. Uma hierarquia é caracterizada pelo encadeamento de dois ou mais atributos que apresentam relação hierárquica entre si.

Assim, no exemplo da dimensão TEMPO descrito acima, identificamos três hierarquias, como descrito a seguir: Dia, mês, trimestre, ano;

Além do modelo estrela existe uma outra estratégia de modelagem chamada modelo Floco de Neve (Snow Flake)



No modelo Floco, as tabelas dimensionais relacionam-se com a tabela de fatos, mas algumas dimensões relacionam-se apenas entre elas, isto ocorre para fins de normalização das tabelas dimensionais, visando diminuir o espaço ocupado por estas tabelas, então informações como Categoria, Departamento e Marca tornaram-se tabelas de dimensões auxiliares.

Considerações sobre ambos modelos

O Modelo Floco (Snow Flake) reduz o espaço de armazenamento dos dados dimensionais mas acrescenta várias tabelas ao modelo, deixando-o mais complexo, tornando mais difícil a navegação pelos softwares que utilizarão o banco de dados. Um outro fator é que mais tabelas serão utilizadas para executar uma consulta, então mais JOINS de instrução SQL serão feitos, tornando o acesso aos dados mais lento do que no modelo estrela.

O Modelo Estrela (Star Schema) é mais simples e mais fácil de navegação pelos softwares, porém desperdiça espaço repetindo as mesmas descrições ao longo de toda a tabela, porém análises feitas mostram que o ganho de espaço normalizando este esquema resulta em um ganho menor que 1% do espaço total no banco de dados, sendo assim existem outros fatores mais importantes para serem avaliados para redução do espaço em disco como a adição de agregados e alteração na granularidade dos dados, estes temas serão abordados em colunas posteriormente.

O recomendado é utilizar um modelo estrela, pois fornece um acesso mas rápido aos dados e mais fácil de se navegar, criando tabelas auxiliares para dimensões somente para dimensões especificas quando for estritamente necessário ou quando demonstrar um beneficio que justifique a perda de desempenho nas consultas, que também não é tão grande dependendo da forma que estas tabelas são construídas e a quantidade de registros que elas contiverem.

A modelagem dimensional é usada para modelar um banco que irá subsidiar sistemas do tipo OLAP. A esse tipo de banco de dados, damos o nome de DATA WAREHOUSE que nada mais é que um banco com dados extraídos de um banco de dados que subsidia sistemas do tipo OLTP.

Isto não quer dizer que um data warehouse possua apenas dados provenientes de um BD relacional. Um DW pode conter informações provenientes de planilhas, arquivos texto, webservices, entre outros.

Outro conceito importante é o que chamamos de Data Mart que são subconjuntos de dados de um Data warehouse.

Muito bem! Você modelou o DW da Empresa. Mas e os dados? Como popular as as tabelas fato e as dimensões? Qual estratégia utilizar para fazer isso? Daí surge o conceito de ETL do inglês Extract Transform Load (Extração Transformação Carga). São ferramentas de software cuja função é a extração de dados de diversos sistemas, transformação desses dados conforme regras de negócios e por fim a carga dos dados geralmente em um Data Mart e um Data Warehouse, porém nada impede que também seja para enviar os dados para um determinado sistema da organização. A extração e carga são obrigatórias para o processo, sendo a transformação/limpeza opcional.

Depois de falar de vários conceitos envolvidos na construção de um DW, segue um modelo com a finalidade de ilustrar um processo de BI.



Bom, é isso aí! Será que descompliquei a sopa de letrinhas? Cabe ressaltar que isso é um resumo que fiz para fixar os conceitos, mas há muito a se discutir sobre o assunto.

Até a próxima!





segunda-feira, 29 de agosto de 2011

Impactos de SOA na Metodologia de Desenvolvimento de Software

Impactos de SOA na Metodologia de Desenvolvimento de Software




Quando a gente pensa em SOA. Várias coisas mudam com relação a forma padrão de se desenvolver software.

Geralmente um sistema é desenvolvido a partir uma demanda de negócio e o cliente desse sistema tem na cabeça um série de telas que seguem a uma determinada sequencia de passos.

Baseado nessa sequência de telas o analista sistemas confecciona casos de uso( no caso de MDS baseada no RUP) ou use estories (no caso de MDS baseada em SCRUM) com o objetivo de traduzir essa visão do cliente.

A princípio essas telas manipulam as informações ali postadas e as grava num banco de dados.

Ainda nesse contexto um arquiteto de sistemas pensa na tecnologia que será adotada para se desenvolver o sistema e no padrão de desenvolvimento que os desenvolvedores deverão utilizar para a implementação deste sistema.

Bom, até aqui acredito que não existam novidades. Tudo o que foi feito baseou-se no processo de negócio apresentado pelo demandante do sistema e acontece em função do sistema que está sendo desenvolvido. Mais tradicional que isso, impossível!

Quando uma empresa adota o SOA deve-se pensar de uma forma mais corporativa, ou seja, os esforços de desenvolvimento não devem se limitar apenas ao sistema em questão, mas sim ao reuso desses esforços na construção de outros sistemas. Falei alguma novidade? Muitos dirão que não. Afinal de contas as aplicações de hoje são compostas por componentes.

Esses componentes estão muito voltadas para uma tecnologia específica. Como exemplo, podemos citar sistemas feito em java. Estes podem conversar perfeitamente com outras aplicações java. Entretanto criar uma interface capaz de fazer dois sistemas feitos utilizando linguagens de programação diferentes pode ser um grande desafio.

É possível? Obviamente sim. É a melhor forma? Dependo da situação pode ser, contudo existem formas mais inteligentes de se desenvolver esses sistemas e é aí que entra o SOA.



Isto posto, vamos imaginar o seguinte cenário: imagine se transformássemos os componentes que constituem um sistema em serviços multiplataforma reutilizáveis imaginando ainda que esses componentes venham compor vários sistemas. Essa não seria uma forma inteligente e mais barata de se desenvolver um sistema? A resposta é COM CERTEZA.

Entretanto é importante desenvolver esses serviços de forma inteligente com baixo acoplamento e alta coesão e para fazer isso o SOA utiliza-se de oito princípios que tentam responder alguns questionamentos:



• Como identificar os serviços a serem criados?

• Que características deve ter esse serviço?

• Qual tamanho deve ter o serviço em questão?

• Esse serviço deve atender ao processo como um todo ou deve atender a apenas uma atividade desse processo?



Falaremos agora sobre os princípios do SOA:



1. Toda interface de um serviço deve ter um contrato formalizado

2. Os serviços devem ter baixo acoplamento

3. Os serviços devem ser abstratos

4. Os serviços devem ser reutilizáveis

5. Os serviços devem ser autônomos

6. Os serviços não devem manter estado

7. Os serviços devem ter a capacidade de serem descobertos

8. Os serviços podem ser compostos

Muito bem, será que o foco deste texto é realmente externar os impactos que uma MDS tradicional. Na primeira parte falamos sobre as diferenças. Agora vamos tratar dos impactos. Basicamente falaremos sobre as etapas envolvidas no ciclo de vida do desenvolvimento de sistemas.

1. Etapa de planejamento (alto impacto)

2. Etapa de análise (médio impacto)

3. Etapa de design (Impacto alto)

4. Etapa de teste (baixo impacto)

É isso aí.

terça-feira, 26 de abril de 2011

XSLT

XSL é o acrônimo de eXtensible Stylesheet Language, e é uma linguagem de folhas de estilo para documentos XML.
XSLT significa XSL Transformations. Aqui aprenderemos como usar o XSLT para transformar documentos XML em outros formatos, como XHTML.

XSL consiste de três partes:
• XSLT - uma linguagem para transformar documentos XML

• XPath - uma linguagem para navegar em documentos XML

• XSL-FO - uma linguagem para formatar documentos XML

XSLT é uma linguagem para transformar documentos XML em documentos XHTML ou para conveter esses documentos em outros documentos XML.


Como funciona?


No processo de transformação, XSLT usa XPath para definir partes do documento de origem que deve corresponder a um ou mais modelos predefinidos. Quando uma correspondência é encontrada, XSLT transformará a parte correspondente do documento de origem no documento de resultado.

Vamos a um exemplo:






Empire Burlesque
Bob Dylan
EUA
Columbia
10,90
1985




Vamos ao arquivo XSL




     
     



     
      
           
         
       



 
Neste exemplo estamos transformando o arquivo xml em outro arquivo xml, mas nada impede de você transformar o documento xml em um arquivo html por exemplo.
 
No próximo post falarei sobre o XPath.
 
Grande abraço!

segunda-feira, 25 de abril de 2011

Os padrões ligados ao XML

Entaum,

Assim que comecei a ter  contato com SOA, encontrei um amigo de longa data ministrando uma palestra sobre o assunto. Dali fomos tomar um chopp e ele, como grande entusiasta de tecnologia, começou a explanar um caminho a seguir para se trabalhar com SOA.

A princípio, o que eu guardei da conversa dele foi que tudo utiliza XML. Sendo assim, ficou claro que quanto maior for o conhecimento de tecnologias correlatas ao XML, maior seria a facilidade de se trabalhar com SOA.

Isto posto comecei a estudar a sopa de letrinhas que me levaram a relembrar os velhos tempos de WEB, ou seja, conhecer HTML, CSS, JavaScript e alguma linguagem de script. Com o advento do .NET, foram grandes os esforços para ofuscar essas tecnologias que ainda existem e cujo conhecimento é de suma importância para o desenvolvedor WEB.

Com o XML não é diferente, existe uma série de padrões envolvidos no trabalho com o XML, cada qual com a sua função e utilidade.

Neste Post, farei um breve resumo sobre esses padrões que serão detalhados em outros posts. Vamos em frente

No post sobre XML verificamos que esta se trata de uma linguagem de marcação que foi criada para carregar e/ou transportar dados. Simples assim.

Mas digamos que você precise mostrar esses dados de maneira amigável. Como fazer isso? Você pode usar CSS, XSLT ou ainda XSL-FO para formatar esses dados e apresenta-los de forma elegante através de um navegador WEB.

Imagine agora a seguinte situação: você não quer mostrar todo o XML. Quer mostrar apenas uma parte das informações contidas neste. Como você faria isso? O padrão Xpath é a solução.

Xpath é utlizado dentro do XSLT para acessar os dados contidos em um arquivo XML. O Xpath possibilita atravessar um documento XML .

Para filtramos as informações contidas no XML é utilizado  o XQuery. O XQuery foi projetado para qualquer efetuar consultas sobre um arquivo XML.

Agora vamos supor que você necessite criar links e âncoras num documento XML. Os padrões XLink e Xpoint foram respectivamente criados com esse propósito.

Como fazer com que um programador confeccione um arquivo xml  que contenha as informações necessárias para você(tipos de dados, ordem dos elementos, etc)? O padrão XML Schema foi desenvolvido com essa finalidade.

Bom, este POST teve apenas o propósito de dar um gostinho dos padrões envolvidos no trabalho com XML. Obviamente, é importante detalhar esses padrões. Portanto, detalharei  os padrões aqui mencionados em outros Posts.

Fico aqui.

Abs

Hugo