download

Utilizando polyfill INTL no Ionic 2

Começamos um projeto novo aqui na Tegra e para ele decidimos utilizar Ionic 2 pelo seu desempenho em relação ao Ionic 1.

 

A ideia deste post é mostrar um problema comum que boa parte dos desenvolvedores estão passando hoje ao fazer build para iOS.

 

Os pipes padrões do Angular 2 utilizam a especificação INTL para fazer as formatações de data e número.
Segue a documentação da INTL:
https://developer.mozilla.org/pt-BR/docs/Web/JavaScript/Reference/Global_Objects/Intl

(mais…)

Leia Mais

Artesanato de Software

O Manifesto for Software Craftsmanship não é tão popular hoje em dia quanto o Agile Manifesto. Entretanto, acredito que os princípios defendidos pelo Craftsmanship são tão importantes quanto os do Agile. Visando apresentar o Artesanato de Software, bem como alguns outros princípios para os graduandos em Análise e Desenvolvimento de Sistemas da FATEC De Sorocaba, no dia 08/10/2014 apresentei, com o apoio da Tegra, a palestra Artesanato de Software que compartilho aqui agora:

 

Obrigado!

Leia Mais

Componentização, reutilização e Agilidade: Tegra Iglu

IgluAqui na Tegra nosso time de desenvolvimento e arquitetura de soluções é apaixonado por construir software. Mais do que simplesmente produção de soluções, todos na Tegra estão engajados para a construção das melhores soluções. Entretanto essas não são qualidades subjetivas e definidas exclusivamente por nossas equipes. A excelência de uma solução é baseada primordialmente pelas necessidades e objetivos de nossos clientes. Para que nossa equipe de negócios tenha condições de, junto aos clientes, propor as melhores soluções e se adaptar às singularidades de cada negócio, a equipe de desenvolvimento e arquitetura trabalha incansavelmente na construção de softwares que sejam flexíveis o suficiente para responder às necessidades desse negócio em um menor tempo possível, com o menor esforço possível o que resulta no melhor investimento possível aos nossos clientes.

Com essa mentalidade, com o aumento de complexidade das nossas soluções e com a alta demanda de nossos clientes foi que surgiu a necessidade de utilizarmos componentes de software reutilizáveis que proporcionassem a agilidade necessária para mudanças e customizações sem que fosse prejudicada a qualidade dos produtos finais, fator de extrema importância para nós.

Um componente de software pode ser compreendido como um elemento organizacional e estrutural de software que possua comportamento, responsabilidades e interfaces de comunição muito bem definidas. Um componente de software, como todo software, precisa ser testável, gerenciável e desenvolvido segundo as melhores práticas da Orientação a Objetos e padrões de projeto para que seja possível manter sua manutenibilidade e reutilização. Geralmente, mas não exclusivamente, um componente de software oferece funcionalidades não diretamente aos usuários da solução, mas para outros elementos de software que terão essa e outras responsabilidades. O conjunto de vários componentes é que forma a solução final.

A produção das soluções da Tegra, como dito anteriormente, são pautados diretamente pelas necessidades de nossos clientes e de seus negócios. Essa é uma preocupação de todas as equipes na Tegra e não seria diferente com nossos desenvolvedores e arquitetos. Assim sendo, todos os nossos componentes internos são produzidos e incrementados segundo as necessidades e demandas de projetos reais. Não desperdiçamos recursos para abstrair algo que não mostrou-se realmente necessário. De forma prática, para que determinada funcionalidade seja abstraída para nossos componentes ela deve ser observada e requerida em mais de um projeto. A partir do momento que uma função é requisitada por vários projetos entendemos que então ela está em condições de ser abstraída para nossos componentes reutilizáveis. Essas pré condições para componentização de software genérico é fundamental para que possamos direcionar nossos esforços para o que realmente possui valor ao negócio de nossos clientes.

O conjunto dos projetos de componentes internos da Tegra formam o Iglu. Um Iglu é uma construção de neve, construída por blocos rígidos de gelo formados pela neve soprada pelo vento. Esses blocos são dispostos de forma a depender um do outro para que todos se mantenham em formação. A forma arredondada dos iglus é importante pois a neve que cair sobre ele escorregará para os lados, impedindo a sobrecarga de peso e evitando o desabamento. A resistência de um iglu aumenta com o tempo. As tempestades e geadas colaboram para que os blocos de neve fiquem cada vez mais resistentes e grossos.

As características de um Iglu são semelhantes ao conjunto dos componentes genéricos e reutilizáveis que construímos a cada dia. Os nossos componentes são como os blocos de neve, que apesar de existirem singularmente, juntos formam um produto, uma solução muito bem estabelecida. Os nossos componentes são construídos de forma que possam ser incrementados facilmente sem interferir drasticamente nos produtos já construídos e a cada interação em que os componentes são incrementados eles se tornam mais coesos, mais testados e com funcionalidades requisitadas por mais projetos. Assim sendo, a cada novo ciclo de desenvolvimento nossos componentes ficam ainda melhores!

Uma das vantagens em se componentizar soluções em estruturas de softwares reutilizáveis é o de se manter o produto exclusivo de um negócio com código que expresse principalmente as regras daquele negócio. Mantemos uma camada de negócios em nossos projetos com o peso e tamanho respectivos ao negócio de forma que se o negócio apresenta muitas regras complexas, a camada do projeto poderá ficar maior. Mas se um projeto possui poucas regras, o projeto tende a manter-se mais simples e menor. Isso é possível pois hoje a maior parte de código referente à infraestrutura dos projetos já está abstraído no Tegra Iglu. Se considerarmos o Desenvolvimento Orientado ao Domínio (muito utilizado por nós), dizemos que nos projetos da Tegra, novos e já em andamento, conseguimos ter um enfoque maior na camada de Domínio da solução, pois nossas camadas de User Interface, Infraestrutura e de Aplicação já estão muito bem desenvolvidas.

Ao iniciar um projeto de componentização, em um primeiro momento pode se ter a noção de que está se envolvendo mais recursos do que o necessário ao projeto. Porém, com o desenvolvimento de forma incremental e consciente, como preconizamos na Tegra, sem perder o foco no que possui valor para o produto do cliente, estamos constatando na prática que os recursos estão sendo muito bem utilizados, muitas vezes até havendo economia pró ativa. Quando corrigimos um bug encontrado em algum componente, automaticamente esse bug é corrigido em diversos projetos. Ao mantermos as funcionalidades de um componente muito bem definida e testarmos essas funcionalidades unitariamente, conseguimos diminuir o trabalho com testes unitários em diversos projetos mantendo-os íntegros e com qualidade. O nosso maior esforço diariamente vem se tornando exclusivamente desenvolver, testar, integrar e entregar camadas de domínio, pois as demais camadas são providas pelo Tegra Iglu.

O Tegra Iglu é um projeto recente que vem sendo desenvolvido incrementalmente a cada interação da equipe de desenvolvimento e arquitetura da Tegra. Estamos constatando que os diversos componentes do Iglu cada vez se tornam mais maduros e coesos, bem como a criação de novas soluções se tornam mais simples e menos dispendiosas. Os projetos que já estão em produção têm se tornado mais simples de manutenir e consequentemente mais ágil de alterá-los caso um cliente solicite.

Estamos comprovando que é possível manter as melhores práticas de desenvolvimento, código e produtos de qualidade e inovação constante mesmo estando totalmente voltados para entregar valor aos nossos clientes ao final de cada iteração.

Abraço!

Leia Mais

Java Code Style (eclipse formatter e clean up)

java-coffee-beansUm ponto importante, mas que nem sempre é tratado com a seriedade que merece, é o code style dos projetos em que trabalhamos. Seja qual for a linguagem, escrevemos comportamentos para a máquina, mas quem mantém, altera e melhora esses comportamentos em formato de código são humanos. Assim sendo, nada mais importante do que pensar nisso quando estamos escrevendo código.

Graças as maravilhas do mundo moderno, os principais ambientes de desenvolvimento para a plataforma Java já podem formatar e limpar o código pra gente. No Eclipse, foco desse post, há duas funções básicas para isso: Code Formatter e Code Clean Up. O Clean Up além da formatação, faz mais algumas coisas no código, exemplo: declara variável como final quando possível, adiciona o this quando necessário, organiza imports, etc. Ambos são bastante configuráveis.

Eu fiz um clean up meu, com base no que acho necessário. Eu sugeriria altamente a todos que trabalham com Java também usassem essa função. Podem configurar um Clean Up com as preferências pertinentes ao projeto que estão trabalhando, ou que a equipe de desenvolvedores ache melhor. Se desejarem, um ponto de partida pode ser o caio-eclipse-cleanup.xml

Também fiz um formatter. O que fiz é praticamente igual ao Code Style do Google para Java. O que fiz foi alterar o espaço das tabulações de 2 para 4 e a versão target do Java de 1.5 para 1.7. Todo o formatador é configurável, mas o arquivo que estou usando também pode ser utilizado como ponto de partida: eclipse-java-google-style.xml

Para usar os arquivos que disponibilizei é simples, após o download os mesmos precisam ser importados para os workspaces onde serão utilizados:
Code Formatter:

  • Eclipse > Window > Preferences > Java > Code Style > Formatter > Import…

Code Cleanup:

  • Eclipse > Window > Preferences > Java > Code Style > Clean Up > Import…

No dia a dia eu uso muito os atalhos:

  • Ctrl + Shift + F: aplica a formatação definida no Formatter
  • Ctrl + Shift + O: organiza os imports

Com esses atalhos, aquele código escrito rapidamente para um teste, protótipo ou mesmo exercício da faculdade, não tem mais desculpas para não ficar formatado corretamente. Afinal, é muito rápido e fácil utilizá-los.

Para passar o Clean Up:
Selecione um projeto, um pacote, um arquivo .java ou mesmo ctrl + a no arquivo fonte, clique com o botão direito: Source > Clean Up.

É isso. Espero que o código, além de performático e muito bom para as máquinas, também fique ótimo para ser lido pelos programadores! Esse e mais conteúdo você pode encontrar em www.caiocarrara.com.br

Abraço!

 

Leia Mais

O paradigma BigData

Vemos por aí tanta gente falando sobre o tal BigData, então pareceu ser uma ótima oportunidade para fazer um post sobre ele!

Afinal o que é BigData?

Vamos primeiro analisar a motivação por trás dele, que levou ao surgimento do termo.

Cena do filme Matrix. No contexto de BigData, a informação circula constantemente por todos os lados.

Atualmente estamos vivendo a era das redes sociais, do conteúdo multimídia distribuído, da informação contextual e democratizada.

Os usuários geram conteúdo!

A informação não flui mais apenas em uma direção, do provedor de conteúdo aos usuários, agora os grandes geradores de informação são os próprios usuários. Diante desse cenário, temos um aumento significante no fluxo de informação, ao qual um serviço precisa dar vazão, e também da complexidade, pois já não existe só uma entidade controlando o conteúdo.

Agora é a vez da estatística!

Outra grande mudança foi no valor da informação. No paradigma BigData fazemos as seguintes perguntas:

  • Quantos usuários do Facebook estão postando sobre um mesmo assunto?
  • Qual a relação entre a faixa etária e os termos buscados no Google?
  • Que categoria de vídeo gera visualizações mais rapidamente no Youtube?

A resposta para essas e muitas outras perguntas são as que criam novas oportunidades de negócio, e para obter a informação necessária para respondê-las é necessário guardar todo tipo de informação que circula em um sistema, o que passa a ser inviável com as soluções existentes de banco de dados relacional, pois não será possível operar no fluxo e crescimento da ordem de Terabytes/segundo.

São muitos dados!

Para resolver esse problema, foi necessário pensar diferente, pensar NoSQL!

Para suportar um sistema da ordem de grandeza de TB/s, é necessário um banco de dados com propriedades naturalmente escaláveis, semi-estruturado (já pensou em adicionar uma coluna a uma tabela com 10 bilhões de registros?) e que possa ser fragmentado (vamos manter réplicas dos registros, não do banco todo!). Diante dessas características, o BigData foi aos poucos se moldando, cada vez se contrastando mais com os outros paradigmas, até se definir como um novo e único paradigma.

Por onde eu começo?

O Google foi o grande pioneiro nessa área,  a integração entre seus serviços de busca e propaganda levou aos primeiros modelos de implementação: a BigTable!

A BigTable pode ser vista como uma matriz esparsa tridimensional, ou como um simples JSON de 3 chaves: { “column family: column”, “row”, “timestamp” : “value” }. Essa configuração permite um emprego muito variado de estruturas, como por exemplo:

  • Rows são endereços de páginas, Column Families são tipos de tags presentes no HTML, as Columns são as tags, o Timestamp é a data de modificação, e o valor é o título da página.
  • Rows são posições de latitude, Columns são longitude, Timestamp é a data da última atualização, e o valor é a imagem de satélite em bytes.

Exemplo do Google de organização dos dados coletados por web crawlers.

Exemplo do Google de organização dos dados coletados por web crawlers.

O Google não foi bonzinho em abrir o código da BigTable, porém nossos amigos da Apache implementaram a descrição conceitual que pode ser encontrada neste artigo do Google LINK.

Enter Hadoop e HBase

Para não haver confusão (no meu dia-a-dia eu vejo muita confusão sobre isto!), vamos dar nomes aos bois!

A ferramenta HBase é responsável por implementar a BigTable em si, ela proporciona a mesma estrutura, column families, timestamps, exatamente como descrito pelo Google.

A ferramenta Hadoop é a que faz a magia acontecer. Para se ter um ambiente de BigData operacional, é necessário criar um cluster de no mínimo 4 máquinas, com um sistema de arquivos distribuído, com gerenciamento de replicação, fornecer uma plataforma de desenvolvimento de operações de Inserção, Busca, Remoção (em outras palavras, Map-Reduce) para assim permitir que o sistema seja escalável, fragmentado, replicado e dê vazão para a aplicação!

Ambos são disponibilizados gratuitamente pela Apache, implementados em Java, e fornecem a camada mais baixa de uma aplicação, que é a de gerenciamento do banco de dados em si. Ao se desenvolver uma aplicação BigData, é necessário desenvolver a camada DAO da sua aplicação, e possívelmente será necessário criar APIs para isso, pois cada emprego de BigData define sua própria organização dos dados!

Fechando

Bom agora já dá pra ter uma idéia do que diabos é BigData, como funciona, e por onde dar os primeiros passos, lembrando que BigData não é pra se fazer sistema de padaria! Sempre que estiver em dúvida em usar ou não BigData lembre-se dos seguintes termos: Volume (TB/s), Variedade (Dados semi-estruturados) e Velocidade (Clusters de várias máquinas).

Leia Mais

Algoritmo – Um noção sobre Custos

Cena do filme Rede Social

Hoje, vou falar um pouco sobre custos de execução dos algoritmos. A ideia é passar uma noção de como mensurar o custo de um algoritmo.

Vamos pegar o problema abaixo:

Some todos os números entre 1 e 100

A primeira abordagem para resolver o problema acima seria a implementação abaixo:

int total = 0;
for(int i = 1; i <= 100; i++ )
   total = total + i;

Obs: Graças ao Caio, conseguimos colocar código aqui no blog =)

Quanto custa para o computador executar o algoritmo acima ?

Imagine que para cada instrução executada o custo seja 1, por exemplo:

  • Criar a variável total com valor 0, custa 1
  • Criar a variável com valor 1, custa 1
  • Comparar com 100, custa 1
  • Somar total com i e atribuir a total, custa 1
  • Incrementar i, custa 1

Com isso, podemos dizer que a implementação acima tem custo 1 + 1 + 3 * 100 = 302. Porque:

  • 1 – Para criar a variável total
  • 1 – Para criar a variável i
  • 300 – Para cada loop do for temos um custo de 3 ( comparação, soma e incremento) e como são 100 loops teremos um custo de 300.

Agora vamos dificultar um pouco as coisas:

Some todos os números pares entre 1 e 100

Implementando:

int total = 0;
for(int i = 1; i <= 100; i++ )
   if ( i % 2 == 0 )
      total = total + i;

O custo do algoritmo algoritmo sobe para 502 agora, porque colocamos uma instrução aritmética ( i % 2 ) e uma de comparação ( i % 2 == 0 ), ou seja adicionamos 2 de custo para cada loop.

Melhorando…

Imagine que você está executando o algoritmo acima em um celular bem, mas bem velho e bem limitado, você precisa otimizar o algoritmo para somar os números pares. Depois de pensar muito você chegou nisso:

int total = 0;
for(int i = 2; i <= 100; i += 2 )
      total = total + i;

O custo do algoritmo acima é 1 + 1 + 3 * 50 = 152. Porque:

  • 1 – Para criar a variável total
  • 1 – Para criar a variável i
  • 150 – Reduzimos a quantidade de loops para 50, pois incrementamos de 2 em 2 a partir de 2 (papo de louco), mas o custo por loop ainda é 3, logo 3 * 50 = 150

Por quê entender custos?

Ao analisar a segunda implementação que tem custo 502, fica claro que o gargalo está no for e o jeito de melhorá-lo é diminuir o custo dos loops. Você só chega nessa conclusão entendo o custo de execução do algoritmo.

Gauss

Será que dá pra diminuir mais o custo ? 152 é o mínimo ?

Voltando para a oitava série, você deve se lembrar da história sobre Gauss ( todo professor de matemática conta, eu acho =P ).

Um dia na escola de Gauss ( que tinha 8 anos segundo a lenda ), a professora de matemática estava cansada para dar aula, então pediu para os alunos somarem os números de 1 a 100, isso iria ocupar um bom tempo deles. Para infelicidade da professora, em alguns minutos, Gauss aparece com a resposta, ele havia criado a fórmula da progressão aritmética.

Sn = (( a1 + an ) *  n ) / 2

Para conhecer mais: http://pt.wikipedia.org/wiki/Progressão_aritmética

Importância da matemática

Se implementarmos a fórmula de Gauss para os número de 1 a 100:

int total = ((1 + 100) * 100) / 2;

O custo é de 1 + 1 + 1 + 1 = 4. Porque:

  • 1 – Para a operação de soma
  • 1 – Para a operação de multiplicação
  • 1 – Para a operação de divisão
  • 1 – Criar a variável total e atribuir o valor

Agora implementando a fórmula para os números pares:

int total = ((2 + 100) * 50) / 2;

Veja que o custo continua mesmo. É a melhor solução para fazer a soma de um intervalo de números =) . Pois o custo não é sensível aos dados de entrada como nas 3 primeiras implementações, ou seja, se eu quiser somar um número de 1 a 1.000.000, ainda teria custo 4, já na implementação que utiliza o for o custo seria de 3.000.002.

A solução aritmética é sempre a melhor, por isso dê mais valor as aulas de matemática na escola e na faculdade.

O objetivo desse post é passar essa noção de custo e não explicar ao fundo como é mensurado o custo de um algoritmo, pois nem toda instrução tem custo 1, se quiser aprofundar no assunto indico o livro abaixo:

http://www.livrariasaraiva.com.br/produto/4061865

Para o dia a dia, o importante é ter uma noção, não precisa ser o expert em custos. Esse conhecimento é aplicado em outras áreas e não apenas programação, como em processos de produção ou até mesmo numa viagem de fim de semana.

Abraço!

Leia Mais

IOS – Trabalhando com cores em Hexadecimais

IMG_0007

Desenvolvemos um aplicativo mobile, no qual o usuário poderia consultar informações da sua empresa como desempenho das vendas e o atingimento das metas.

A ideia era fazer algo semelhante ao Google Now, distribuindo as informações em cartões:

Para deixar o conteúdo de forma customizável o aplicativo solicitava um xml do servidor do cliente. Através desse xml é montado os cartões e as informações dentro dele. Um exemplo está abaixo:

<cards>

<card>

<data>

<line>

<label>Venda</label>

<value>R$ 1.000,00</value>

</line>

</data>

</card>

</cards>

No xml acima não existe o atributo de cor em nenhuma das tags. Decidimos adicionar o atributo color nas tags label e value (da tag line), assim o cliente poderia customizar a cor das ‘linhas’.

No iOS trabalhamos com o UIColor para gerar as cores. Mas UIColor recebe como parâmetro 4 valores ( red, green, blue, alpha ) seria ruim adicionar esses 4 paramêtros na tag, ficando assim:

<line>

<label>Venda</label>

<value colorRed=”255″ colorGreen=”255″ colorBlue=”255″ colorAlpha=”1″>R$ 1.000,00</value>

</line>

Pensamos em trabalhar com cores hexadecimais que reduz os 4 atributos para 1 só. Removemos também o atributo alpha, ficando assim:

<value color=”#00FFD2″>R$ 1.000,00</value>

Agora precisamos dentro da aplicação interpretar o valor hexadecimal e criar um objeto UIColor.

Entendo a cor hexadecimal

Uma cor ela pode ser composta pela variação das 3 cores primárias.

 

Na cor hexadecimal, cada par representa a intensidade de uma cor primária, essa composição forma uma nova cor:

#00FFD2

Como a cor está em base 16 ( hexa ) precisamos converter para base 10 ( decimal ) assim poderemos usar na UIColor. Para entender mais sobre conversão entre sistemas numéricos veja este link: http://pt.wikipedia.org/wiki/Conversão_entre_sistemas_numéricos

Abaixo segue uma implementação em objective-c para conversão de base 16 para base 10:

Screen Shot 2013-12-05 at 7.59.17 AM
Pessoal, não achei um jeito de postar código aqui no blog, por isso a screenshot. Vamos melhor nos próximos posts.

Obs: Podemos converter qualquer caracter para número apenas subtraindo por outro caracter. Ex.:

O caracter ‘1’ pode ser convertido para o valor inteiro 1 fazendo isso:

‘1’ – ‘0’ = 1 (inteiro)

Isso funciona porque a representação decimal desses caracteres é 31 e 30, respectivamente, ou seja, quando fazemos ‘1’ – ‘0’, na verdade estamos fazendo 31 – 30.

Logo, podemos converter ‘A’ para 10 fazendo ‘A’ – ‘A’ + 10.

Agora sabendo como converter a cor hexa para decimal basta criar UIColor com os valores decimais.

Segue abaixo uma implementação para criar UIColor a partir de cor hexadecimal:

Screen Shot 2013-12-05 at 8.10.44 AM

Abraço e até a próxima!

Leia Mais