terça-feira, 28 de abril de 2009

Web Analytics: Além da implementação

Excelente. O departamento de marketing finalmente adotou o uso de uma ferramenta de Web Analytics. Parece que, finalmente, a alta diretoria da empresa compreendeu a importância de mensurar as iniciativas Web.

Entretanto, parece que o processo parou na implementação. A ferramenta funciona muito bem, e milhares de dados são gerados diariamente. E é aí que você percebe que algo deve ser feito. Sua empresa é uma mera colecionadora de métricas? Caso a resposta seja positiva, parabéns. Você será o responsável por mudar isso.




Quando você parte para a obtenção de valor de sua ferramenta de Web Analytics, há grandes chances de se surpreender com alguns obstáculos impostos por sua própria empresa. Políticas internas e procedimentos podem ser muito inflexíveis. A tomada de decisões geralmente é um processo custoso, ou pior: às vezes não está claro quem deve tomar as decisões adequadas.

O processo de metamorfose de uma empresa que somente gera dados para uma empresa que os direciona pode ser longo e doloroso, especialmente quando VOCÊ teme ser caracterizado como o Agente de Mudanças, já que em muitas culturas organizacionais isso ainda é considerado como algo negativo. Analistas e administradores, em teoria, deveriam ser as pessoas mais próximas dos dados gerados e, portanto, os responsáveis pelo rumo destas informações, como coordenar projetos com outros departamentos, identificar oportunidades de crescimento, integrar as informações com sistemas back-end, desenvolver padrões e modelos de governança, fazer análises de custo benefício relativas aos esforços de marketing, etc. Saiba que seu plano de mudança vai envolver e impactar muitas pessoas e atividades.

Não há escapatória. Você deve encarar o fato de que suas iniciativas vão gerar alguns conflitos. No entanto, através de planejamento, é possível se precaver. Veja algumas sugestões para obter sucesso como um Agente de Mudanças na área de Web Métricas de sua empresa.

1. Mapeie as possíveis dependências

Para identificar mais facilmente os possíveis "gargalos", liste todos os processos em sua organização que podem impactar ou serem impactados pelos seus esforços de mudança. Tente focar no cenário atual - como as coisas realmente são e não como deveriam ser. Essa lista deve incluir planejamento de budget, processos de campanhas de marketing, características do website, dados de segurança, questões legais etc.

2. Identifique seus públicos internos

Pense nas pessoas que serão impactadas pelo seu novo plano de Web Analytics. Isso inclui toda e qualquer pessoa atingida, independente do grau de impacto. Pense inclusive nos executivos que deveriam receber os dados de análise e não recebem.

3. Defina os tipos de impactos das mudanças

Determine quais tipos de impactos possivelmente surgirão. Aproveite a lista de pessoas impactadas e as separe em categorias. Tipos de impacto podem incluir:

Mudanças de processos;
Eliminação de processos;
Mudanças relativas a controle ou autoridade;
Alterações no budget.

4. Transforme possíveis problemas em oportunidades

De acordo com o material que você reuniu até o presente momento, pense em como você pode reverter impactos negativos em positivos. Não pense somente em problemas, mas também em soluções. Com certeza, o buzz inicial gerado a partir do seu programa de mudanças será mais negativo do que positivo; pessoas são avessas a mudanças e se negam a sair da zona de conforto. Neutralize as reclamações com soluções.

5. Envolva públicos internos e stakeholders no seu planejamento

Agora que você já sabe onde estão as oportunidades e os prováveis focos de conflitos, já é possível informar ao público interno sobre as transformações que virão. Caso as mudanças signifiquem mais tempo para executar outras tarefas (às vezes mais relevantes!), aprofunde-se neste argumento. A otimização do tempo é sempre uma boa pedida.

6. Mantenha-se focado no resultado final, mas respeite o passo a passo

Embora você tenha objetivos ambiciosos a longo prazo, defina metas específicas, a curto prazo. Os resultados devem aparecer de forma gradual; pouco a pouco, as mudanças se tornarão parte integrante do processo, tirando o peso das suas costas. Quando isso ocorrer, pode-se dizer que a cultura da empresa está finalmente em transformação.

Ser um agente de mudanças não traz somente benefícios para sua empresa. Como profissional, é importante buscar novas aptidões e habilidades. O mercado valoriza profissionais capazes de se reinventar, principalmente quando estamos falando de Internet!

Boa sorte com seu plano de mudanças!


Por: Marcela Daniotti é graduada em Publicidade e Propaganda pela Faculdade Cásper Líbero e hoje atua na CLM Software como analista de marketing.
Confira no iMaster

segunda-feira, 27 de abril de 2009

Data da Páscoa, como calcular?

Pessoal,
Eu já tive que "escrever" um programa para contar os dias que faltam para eventos pré-agendados e feriados nacionais. Foi muito difícil descobrir quando era o carnaval, pascoa e corpus-christi... Navengando na grande rede achei este post do Márcio d'Ávila, confira...
A Páscoa
A apresentação mais interessante (e concisa) que achei para a data da Páscoa foi no material do prof.
Kepler de Souza Oliveira Filho, do Departamento de Astronomia e Astrofísica, Instituto de Física, da UFRGS:
A páscoa judaica (Pesach), que ocorre 163 dias antes do início do ano judaico, foi instituída na epoca de Moisés, uma festa comemorativa feita a Deus em agradecimento à libertação do povo de Israel escravizado pelo Faraó, o rei do Egito. Esta data não é a mesma da Páscoa Juliana e Gregoriana.
O dia da Páscoa cristã, que marca a ressurreição de Cristo, de acordo com o decreto do papa Gregório XIII (Ugo Boncampagni, 1502-1585), Inter Gravissimas em 24/02/1582, seguindo o primeiro concílio de Nicéia de 325 d.C., convocado pelo imperador romano Constantino, é o primeiro domingo depois da Lua Cheia que ocorre em ou logo após 21 de março, data fixada para o equinócio de Primavera no hemisfério norte.
Entretanto, a data da Lua Cheia não é a real, mas a definida nas Tabelas Eclesiásticas, que, sem levar totalmente em conta o movimento complexo da Lua, podia ser calculada facilmente, e está próxima da lua real.
De acordo com essas regras, a Páscoa nunca acontece antes de 22 de março nem depois de 25 de abril.
Cálculo da data da Páscoa
Com base nas regras, foram desenvolvidos ao longo do tempo diversas técnicas e algoritmos para o
Cálculo da Páscoa, ou Computus em inglês (calculation of the date of Easter), em cada ano do calendário cristão, em especial no Calendário Gregoriano utilizado no Brasil e muitos outros países latinos.
Relaciono a seguir as melhores referências que coletei a respeito:
Cálculo da Páscoa, verbete na Wikipédia em Português, apresentando tabela e algoritmos para cálculo da data da Páscoa em cada ano.
Computus, verbete na Wikipedia em inglês, apresentando história, teoria, métodos tabulares e algoritmos.
A Data da Páscoa, por prof. Kepler de Souza Oliveira Filho, Astronomia e Astrofísica, UFRGS; inclui uma tabela com as datas da Páscoa já calculadas para os anos de 1980 a 2024.
Como Calcular a Data do Domingo de Páscoa, por Arlindo Correa, 2001; inclui script que dado um ano, informa data da Páscoa, Carnaval, Dia da Ascensão, Pentecostes e Corpus Christi.
Cálculo do Dia da Páscoa, por prof. Roberto Cabral de Mello Borges, incluindo uma Tabela de dias da Páscoa, Carnaval e Corpus Christi de 1951 a 2078.
Cálculo do dia da Páscoa e de outras datas móveis, por José Luís Carneiro, 2009; inclui uma planilha para cálculo de datas móveis para baixar.
The Date of Easter e programa para cálculo de Datas da Quarta-feira de Cinzas (Ash Wednesday) e Domingo de Páscoa (Easter Sunday), em inglês, Naval Meteorology and Oceanography Command, Marinha dos Estados Unidos.
A Perpetual Easter and Passover Calculator, em inglês, por R.H. van Gent, Institute for History and Foundations of Mathematics and the Natural Sciences, 2003.
Datas móveis relacionadas
Dada a data da Páscoa, temos as seguintes celebrações, todas em dias da semana fixos:
Terça-feira de Carnaval ocorre 47 dias antes da Páscoa; celebração pagã;
Quarta-feira de Cinzas (Ash) ocorre 46 dias antes da Páscoa; início do período da
Quaresma (Lent) [1], [2];
Quinta-feira da Semana Santa ocorre três dias antes da Páscoa; celebração da ultima ceia de Jesus Cristo com os doze apóstolos;
Domingo de
Páscoa (Easter); celebração da Ressurreição de Jesus Cristo;
Domingo de
Pentecostes ocorre no 50º dia desde a Páscoa;
Domingo da Santíssima Trindade é o domingo seguinte ao de Pentecostes;
Quinta-feira de
Corpus Christi (Corpo de Deus) ocorre no 60 dias após a Páscoa; celebração da presença do corpo de Cristo na Eucaristia.

sexta-feira, 24 de abril de 2009

Garbage First Collector da Sun Elimina Amplamente a Baixa Latência/Alto Consumo

Postado por Charles Humble, traduzido por Ricardo Almeida em 24 Abr 2009 02:59 PM no InfoQ

O Garbage Collector da Sun chamado Garbage First (referenciado de G1) é o novo garbage collector de baixa latência planejado para substituir CMS no Hotspot da JVM.  É um coletor estilo servidor, dirigido a máquinas multi-processamento com muita memória. Existem duas grandes diferenças entre CMS e G1. Primeiro que o G1 é um coletor com compactação. Compactação, um processo o qual a vida de objetos são movidas para espaços de memória livre no fim da pilha (heap) de modo que outros espaços tornam-se uma área contínua de memória livre, é importante em aplicações de execução longa porque é inevitável que a pilha irá se fragmentar no decorrer do tempo. G1 compacta suficientemente para evitar completamente o uso de listas livres de granularidade fina para alocação, o que simplifica consideravelmente partes do coletor e sobretudo elimina questões de potenciais fragmentações. Bem como a compactação, G1 oferece pausas de coleta mais previsíveis do que pode obter com o coletor CMS e permite usuários configurar as pausas do coletor. Essa determinística forte dá ao G1 algumas características de um coletor de Tempo Real (Real-Time) verdadeiro, porém não é fortemente Tempo Real, uma vez que fatores como agendamento do Sistema Operacional ainda significam que pausas não podem ser garantidas. Para o desenvolvedor entretanto consideravelmente mais fácil de usar do que produtos Java de Tempo Real desde que o código existente é capaz de ter performance melhorada sem necessitar de qualquer alteração em código. G1 usa algumas técnicas interessantes, baseadas na marcação global de informação e outras métricas, para priorizar regiões para coleta de acordo com a eficiência da Garbage Collector. Um artigo InfoQ anterior fornece mais detalhes técnicos.

Em um podcast recente,, James Gosling destacou a importância do G1 para certos tipos de aplicações Java de larga escala, semelhante a intercâmbios financeiros, que são caracterizados por grandes quantidades de dados vivos na pilha e considerável paralelismo no nível de thread, e são executados frequentemente em processadores multi-core:

"...o segredo profundo sobre muito dessas aplicações Java é que eles não usam banco de dados realmente. Ao invés de banco de dados eles usam muita RAM e empurram o garbage collector igual maluco porque eles não podem se dar ao luxo de tocar o disco sempre. Quando você está fazendo muitos, muitos milhares de transações por segundo, é bom manter tudo na RAM, usando tabelas hash, obtendo muitos núcleos focados nas transações na medida do possível, e geralmente ter grande questões sobre latência de operação.""

Gosling fala da diferênça entre consumo e determinismo. Tipicamente um garbage collector é otimizado para um ou outro. Um garbage collector otimizado para consumo é ideal para executar tarefas de segundo plano muito longas, onde pausas para garbage collector não são um problema para terminar a tarefa de segundo plano o mais rapidamente possível. Inversamente, se você está trabalhando em um sistema iterativo semelhante a uma aplicação web, então uma baixa latência do garbage collector é geralmente a melhor escolha. Gosling mostra o ponto que essas diferenças também existem em outras partes da JVM e que geralmente a JVM é otimizada para consumo. Realmente:

""Isso acontece todo lugar onde existe algoritmos que reorganizam algo. Então ter uma tabela hash - todos pensam que uma tabela hash tem tempo constante de inserção e tempo constante de remoção, o que é falso. O tempo de inserção é constante até ter que recolocá-lo no hash e depois uma insersão vai levar um bom tempo.""

Permitindo usuários especificar que o garbage collection não consuma mais que x ms de tempo, o G1 pode tentar manter pausas de collection como pequenos e não frequentes como for necessário para a aplicação, mas não tão lento como to diminuir consumo ou aumentar desnecessariamente a pegada. Dado que o garbage collector tem uma das áreas onde o ganho lento de latência é mais visível, o G1 deve oferecer benefícios significantes para desenvolvedores Java Enterprise. Está disponível no release do Java 6 update 14 e o time do Hotspot da Sun está extremamente vivo para ter feedback e bug reports dos que adotam cedo.

quinta-feira, 23 de abril de 2009

"QI" emprega 64% dos funcionários em TI

Por isso que eu "cultivo" amigos... por que com toda a certeza devo muito à eles!
Segue a transcrição do
artigo.

Estudo realizado pela Impacta Tecnologia mostra que um bom colega vale mais do que mil currículos


Ter um bom currículo é essencial. Estar cadastrado nas principais redes sociais profissionais, também. Assinar serviços de recrutamento online, idem. Mas o que mais ajuda um profissional de TI no Brasil a arrumar um emprego é ter um bom e influente colega. O popular QI - quem indica.

É a conclusão que dá para tirar de uma pesquisa realizada pelo Grupo Impacta Tecnologia – no Brasil, 64% das contratações que ocorrem no setor de TI são fruto de indicações de outros funcionários. Entre outras formas de recrutamento, a de buscar por colaboradores em sites especializados em bancos de currículo apareceu em segundo lugar, com 49% das respostas.

O estudo mostra também que os profissionais de tecnologia estão permanecendo por menos tempo nas empresas. Em 2003, a quantidade de profissionais nas copanhias com menos de três anos de casa era de 21%, relação que saltou para 50% na mesma pesquisa realizada em 2009.

Outro dado é referente à formação de equipes. Segundo a pesquisa, 19% dos times de TI têm de um a três anos, mas a maioria das equipes nas empresas foi formada há mais de cinco anos.

O levantamento realizado pela impacta fez um comparativo entre o ano de 2003 e 2009. Foram realizadas 100 entrevistas junto a 100 empresas de médio e grande porte, escolhidas aleatoriamente no país.

por Bruno Ferrari, de INFO Online
23 de abril de 2009

segunda-feira, 20 de abril de 2009

Java x .NET

Tem blogs que merecem sempre uma visita diária, um deles é o do meu amigo André Dourado. Dentre as últimas notícias publicadas por ele... selecionei esta:

Essa é uma das respostas do Márcio Tierno no grupo UML-FATEC, sobre a eterna discussão sobre qual a melhor plataforma de desenvolvimento: Java ou .NET.

Sei que esse assunto de quem é melhor Java x .NET é quase como discutir sobre religião. Mas o problema sobre produtividade no desenvolvimento de software é uma questão de foco, ou melhor, o problema não é tecnológico e sim estratégico.

“Um pouco de números para tentar dar um pouco de prumo a essa discussão:

1 - 80% dos negócios do mundo rodam em cima de programas COBOL. Nem Java nem .NET vão decidir o futuro da humanidade, portanto.

2 - Nunca vi um sistema que não pudesse ser implementado em qualquer linguagem que seja. Portanto, a discussão Java x .NET não se decide na esfera técnica.

3 - Produtividade - não é criando grids para acesso direto a tabelas que se mede produtividade, mas sim no tempo total que leva para uma idéia sair da cabeça do usuário de negócios até se transformar em um sistema rodando no ambiente de produção, testado, aprovado e homologado. Numa “competição” Java x .NET, é certo que ambas as tecnologias chegariam empatadas “na margem de erro” caso se considerasse todo o ciclo de vida de um sistema.

4- Ainda em produtividade, só de 15% a 20% do tempo é gasto efetivamente em implementação. O grosso do esforço é gasto em levantamento de requisitos e testes.

Por falar em produtividade, só 30% do tempo do programador é gasto em desenvolvimento de fato, em média. O resto é perdido em debugging ou reescrevendo requisitos que foram mal-entendidos (e mal-explicados, por conseguinte). Pare e pense na sua rotina diária e veja se vc discorda desses números.

Assim, 20% X 30% = 60% do tempo total de um projeto em desenvolvimento REAL. Supondo que uma das duas tecnologias fosse 50% MAIS PRODUTIVA do que a outra (e nenhuma delas o é), o impacto final seria de 3% sobre o tempo total do projeto. Quase indetectável.

Assim, o desafio proposto perde a validade em si. Até porque ninguém vai sair “convertido” de um evento desses. Agora, um desafio de ponta a ponta, num prazo de algumas semanas, por exemplo, esse sim teria valia. Mas já não seria mais um desafio Java x .NET, mas, talvez, um desafio MDA x AMD (tipo Together) x Agile (S. Ambler), por exemplo.

4 - Decisões estratégicas - Há uns 20 anos, mais ou menos , o Natural/ADABAS ganhou um grande mercado do COBOL, porque era muuuito mais produtivo e fácil de mexer. Hoje quem tem Natural/ADABAS quer morrer, porque a Software AG está cobrando os tubos (zilhões de dólares) pela renovação das licenças e a tecnologia é “imigrável”. Paralelo com .NET, proprietário como Natural/ADABAS. Erro estratégico.

Outro exemplo: há 30 anos, C prometia ser o que Java promete hoje. Se alguém algum dia teve um sistema de negócios escrito em C, então deve ter uma boa história de migração urgente para contar. Paralelo com Java, “assembleísta” como C. Outro erro estratégico.

Então, amigos, tecnologicamente falando, Java e .NET se equivalem.

Não consigo imaginar um sistema corporativo (que é o que interessa, afinal) que possa ser feito em um, mas não no outro. Ou que saia muito mais rápido em um do que no outro.

Portanto, o cerne da questão é estratégico, não tecnológico.

E todos os xiitas são gentilmente deixados de lado nessas discussões.

De minha parte, entre Java e .NET, fico com arquitetura de software, MDA e Governança de TI.

Na guerra entre as partes, prefiro vender a munição.

Márcio Tierno (mtierno.rm): é atualmente responsável por toda a divisão de testes funcionais da Inmetrics. Atua na área há 16 anos, tendo trabalhado em empresas como Compuware do Brasil, IBM, Rational Software, BCP Telecomunicações, entre outras. Cursou Ciência da Computação na Unicamp, é certificado ITIL Foundations e Rational Requirements Mngt. Marcio já prestou consultoria e ministrou dezenas de treinamentos em Ger. de Projetos, Requisitos e demais disciplinas de desenvolvimento para empresas como Serpro, Xerox, BankBoston, Banco Itaú, Banco Votorantim, Cargill, Porto Seguro e outras de grande porte, no Brasil e no exterior.

sexta-feira, 17 de abril de 2009

Um pouco dos ultimos 3 dias...

Amigos separei uma listinha com um pouco do das notícias que eu abri para ler nos ultimos três dias. Segue a lista...
Espero que gostem.

Carreira quente: analista de negócios em tecnologia

Tenho Vários amigos que são Analistas de Negócio, achei um artigo interessante na COMPUTERWORLD para vermos como anda o mercado. Segue a transcrição da notícia.
17 de abril de 2009 - 07h00
Profissional deve compreender as reais necessidades do usuário de tecnologia e garantir eficiência das soluções.
No mercado de tecnologia, gestores e profissionais estão cansados de ouvir aquela velha máxima que diz “é necessário alinhar tecnologia da informação aos negócios”. Falar é fácil, mas para colocar isso em prática é necessário que as áreas de negócios e de tecnologia de uma organização se entendam muito bem, o que geralmente é um grande desafio. Para criar esse entendimento, existe um tipo de profissional específico no mercado: é o analista de negócios. Por meio de uma convivência intensa com a área da empresa ou cliente que demanda tecnologia, o profissional passa a conhecer toda a rotina de trabalho do usuário e consegue coletar dados para orientar o projeto, de forma que ele ofereça as melhores soluções. Na estrutura atual, o trabalho é realizado por profissionais oriundos tanto da área administrativa quanto da área tecnológica, mas que não estão 100% focados nessa atividade. “Atualmente, muitos gerentes de produtos, analistas de sistemas, profissionais de melhorias de processos, entre outros, fazem essa função, muitas vezes sem saber”, afirma Suzandeise de Almeida, diretora da unidade de São Paulo do International Institute of Business Analysis (IIBA). Um dos trabalhos do instituto dirigido por Suzandeise é promover a profissão no País com a denominação correta e difundir os padrões internacionais para a área. Internacionalmente, o IIBA possui um manual de melhores práticas, conhecido como Babok (Business Analysis Body of Knowledge). Para a diretora, o profissional da área deve ter habilidades de comunicação e entendimento de negócios de uma maneira geral. Para Tecnologia da Informação, formação técnica é um quesito muito valorizado, mas, segundo a executiva, as próprias empresas ainda não sabem muito bem o que exigir de quem vai exercer essa atividade. “Muitas vezes exigem-se profundos conhecimentos técnicos pouco usados no dia-a-dia do trabalho. Ainda assim, é uma carreira na qual vale a pena apostar, pois as organizações começam a descobrir sua real função”, afirma.

Conheça profissionais da área

Sandra Siqueira, coordenadora de sistemas do hospital paulistano Sírio Libanês, acompanhou um projeto de nutrição no qual o analista de negócios acompanhou, por algum tempo, o dia-a-dia do setor, documentando e até filmando as atividades realizadas. A partir dessa experiência, o analista pôde entender qual era a dinâmica de trabalho e mapear suas necessidades para, então, desenvolver soluções.
“Neste caso, pudemos observar uma mobilização rápida de departamento de tecnologia no atendimento às necessidades da área. Os próprios nutricionistas se sentiram mais valorizados e comprometidos com o projeto que envolvia sua área. Consequentemente, o tempo de resposta foi menor no desenvolvimento”, afirma Sandra.
A profissional afirma que o analista de negócios não pode ser confundido com um gerente de projetos ou um gestor de relacionamento, apesar de precisar ter habilidades comuns a esses dois profissionais. “O expertise em gestão é muito importante, mas esse profissional está muito mais preocupado em ir ao núcleo da real necessidade do usuário do que em controlar o processo como um todo”, comenta.
Cláudio Kerber, líder de uma equipe de análise de negócios na Ionics, empresa de automação para o mercado de combustíveis, acredita que o bom profissional da área consegue enxergar além das necessidades declaradas do usuário. “É necessário questionar por que o cliente pede determinada solução e atingir um diagnóstico. Nem sempre o que ele está pedindo é o que ele realmente necessita”, diz Kerber.
Para Kerber, o profissional tem que ter excelente capacidade de síntese, pois interage com muita gente e precisa reunir idéias para chegar a uma conclusão. “Além disso, precisa saber priorizar as necessidades dos negócios”.
Kerber diz que o profissional pode ser nativo tanto de gestão quanto de tecnologia. “O profissional de TI tem um pragmatismo que pode ser muito útil para a equipe, ao passo que o de gestão sabe enxergar bem o negócio. O ideal é juntar os dois tipos em uma equipe de análise de negócios”, complementa.

quarta-feira, 15 de abril de 2009

Comunidade “Manifesto Ágil”

Amigos;
Hoje em dia quem está focado em desenvolvimento tem que ter em mente a utilização de metodologias ágeis. Por isso eu faço parte e recomendo a comunidade criada pelo meu grande amigo André Dourado.
Segue a reprodução do post feito por ele em seu blog.
...............................................................
por André Dourado em 15 abr 2009
Comunidade no Orkut “Manifesto Ágil”

Criei uma comunidade no Orkut, que visa reunir os interessados nas metodologias ágeis aqui no Brasil, bem como servir como um canal na construção e disseminação de pensamentos e experiências sobre desenvolvimento de software, liderança de equipes e práticas ágeis.

Se você tem interesse em discutir assuntos relacionados a Agile, XP, SCRUM, Crystal etc, este é seu lugar. Participe. O link para a comunidade é:

É bom comer gordura, beber vinho e fazer sexo?


Hoje, navegando na grande rede, achei um post "
cultural" no Uhull SA





Três assuntos interessantes… gordura, vinho e sexo!!!

Sobre a GORDURA:

No Japão, são consumidas poucas gorduras e o índice de ataques cardíacos é menor do que na Inglaterra e nos EUA;

Em compensação, na França se consome muitas gorduras e, ainda assim, o índice de ataques cardíacos é menor do que na Inglaterra e nos EUA;

Sobre o VINHO:

Na Índia, se bebe pouco vinho tinto e o índice de ataques cardíacos é menor do que na Inglaterra e nos EUA;

Em compensação, na Espanha se bebe muito vinho tinto e o índice de ataques cardíacos é menor do que na Inglaterra e nos EUA;

Sobre o SEXO:

Na Argélia, se transa muito pouco e o índice de ataques cardíacos é menor do que na Inglaterra e nos EUA;

Em compensação, no Brasil se transa muuuuuito e o índice de ataques cardíacos é menor do que na Inglaterra e nos EUA;

CONCLUSÃO:

Beba , coma e transe sem parar,
pois o que mata é falar inglês!


Eu já parei meu curso…

terça-feira, 14 de abril de 2009

Parkour é para os fracos

Fiquei realmente impressionado quando vi isso no Bobagento, achei que tinham me fotografado andando de bicicleta ;)
















Catalogo de Patterns

Conforme falei no post Detalhando Design Patterns, os padrões de projetos podem ser separados quanto ao seu propósito. Segue catalogo de Pattern descrito pela GoF com uma pequena explicação.

Padrões de criação

# Abstract Factory
Provê uma interface para criação de famílias de objetos relacionados ou interdependentes. Remove a dependência entre o cliente, que usa os objetos, e a classe dos objetos produzidos, através de uma única interface e sem que a classe concreta seja especificada.

# Builder
Provê uma interface genérica para a construção incremental de agregações. Um Builder esconde os detalhes de como os componentes são criados, representados e compostos.A diferença entre o Builder e o Abstract Factory é que ele constrói objetos complexos passo a passo e o Abstract Factory constrói famílias de objetos, simples ou complexos, de uma só vez.

# Factory Method
Define uma interface para criação de um objeto, permitindo que as suas subclasses decidam qual classe instanciar. O Factory Method deixa a responsabilidade de instanciação para as subclasses.

# Prototype
Especifica os tipos de objetos a serem criados num sistema, usando uma instância protótipo. Cria novos objetos copiando de um modelo original, ou protótipo.

# Singleton
Assegura que uma classe tenha apenas uma instância e provê um ponto global de acesso a ela.

Padrões estruturais

# Adapter
Converte a interface de uma classe em outra, esperada pelo cliente. O Adapter permite que classes que antes não poderiam trabalhar juntas, por incompatibilidade de interfaces, possam agora fazê-lo.

# Bridge
Separa uma abstração de sua implementação, de modo que ambas possam variar independentemente.

# Composite
Compõe objetos em árvores de agregação (relacionamento parte-todo). O Composite permite que objetos agregados sejam tratados como um único objeto.

# Decorator
Anexa responsabilidades adicionais a um objeto dinâmicamente. Provê uma alternativa flexível para extensão de funcionalidade, sem ter que usar Herança.

# Façade
Provê uma interface unificada para um conjunto de interfaces em um subsistema. O Facade define uma interface alto nível para facilitar o uso deste subsistema.

# Flyweight
Usa o compartilamento para dar suporte eficiente a um grande número de objetos com alto nível de granularidade.

# Proxy
Provê Design para um controlador de acesso a um objeto.

Padrões comportamentais

# Chain of Responsability
Encadeia os objetos receptores e transporta a mensagem através da corrente até que um dos objetos a responda. Assim, separa (provê loose coupling) objetos transmissores dos receptores, dando a chance de mais de um objeto poder tratar a mensagem.

# Command
Encapsula uma mensagem como um objeto, de modo que se possa parametrizar clientes com diferentes mensagens. Separa, então, o criador da mensagem do executor da mesma.

# Interpreter
Usado para definição de linguagem. Define representações para gramáticas e abstrações para análise sintática.

# Iterator
Provê um modo de acesso a elementos de um agregado de objetos, sequencialmente, sem exposição de estruturas internas.

# Mediator
Desacopla e gerencia as colaborações entre um grupo de objetos. Define um objeto que encapsula as interações dentre desse grupo.

# Memento
Captura e externaliza o estado interno de um objeto (captura um "snapshot"). O Memento não viola o encapsulamento.

# Observer
Provê sincronização, coordenação e consistência entre objetos relacionados. 

# State
Deixa um objeto mudar seu comportamento quando seu estado interno muda, mudando, efetivamente, a classe do objeto. 

# Strategy
Define uma família de algoritmos, encapsula cada um deles, e torna a escolha de qual usar flexível. O Strategy desacopla os algoritmos dos clientes que os usa.

# Template Method
Define o esqueleto de um algoritmo em uma operação. O Template Method permite que subclasses componham o algoritmo e tenham a possibilidade de redefinir certos passos a serem tomados no processo, sem contudo mudá-lo.

# Visitor
Representa uma operação a ser realizada sobre elementos da estrutura de um objeto. O Visitor permite que se crie um nova operação sem que se mude a classe dos elementos sobre as quais ela opera.

Detalhando Design Patterns

Hoje vou falar um pouco de padrões de projetos ou em inglês Design Patterns.

Definição
A definição clássica para Pattern é a seguinte: "um Pattern descreve um problema que se repete várias vezes em um determinado meio, e em seguida descreve o núcleo da sua solução, de modo que esta solução possa ser usada milhares e milhares de vezes” [Christopher Alexander].
Patterns são soluções genéricas e reutilizáveis, aplicáveis em classes de problemas bem conhecidos. Soluções que um dia funcionaram, tornam-se receitas para situações similares (desde que estas soluções tenham sido projetadas com flexibilidade).
Também acarretam um vocabulário comum de desenho, facilitando comunicação, documentação e aprendizado dos sistemas de software

Histórico
A idéia de armazenar informação sobre padrões observados em um contexto pode ser atribuída ao arquiteto Christopher Alexander (arquiteto, matemético e urbanista).
 - Alexander define uma ordem para a aplicação de patterns;
 - É sustentada a teoria que patterns podem gerar arquiteturas completas.
 - No seu livro The Timeless Way of Building, mostra como patterns podem ser aplicados na construção de casas, assim como no planejamento de bairros e cidades.
 - Somente em 1995, a "Gangue dos Quatro" ou simplesmente "GoF" (Gang of Four) – Erich Gamma, Richard Helm, Ralph Johnson e John Vlissides -publicaram o primeiro catálogo de Design Patterns para programas orientado a objetos: Design Patterns – Elements of Reusable Object-Oriented software (GoF book).

Estrutura
Não existe um consenso dentro da comunidade de design patterns sobre como descrever um template de patterns. Diferentes autores preferem diferentes estilos para seus templates de patterns. Acho que estes 4 itens são necessários.
  • Nome - A identificação do Pattern é importante pois ele torna-se membro do vocabulário do projetista e de seus colegas. 
  • Problema - descreve quando aplicar o Pattern. Apresenta a classe de problemas em questão e seu contexto. 
  • Solução - descreve os elementos que fazem parte do design, seus relacionamentos, responsabilidades e colaborações. 
  • Conseqüências - os resultados e efeitos causados pela aplicação do Pattern. 

Organização
As Patterns podem ser separadas quanto ao seu propósito. Num próximo post vou detalhar o catalogo de Pattern descrito pela GoF.
  • Criacional:
    Diz respeito ao processo de criação de um objeto;
    Ex: Builder - separa a construção de um objeto complexo de sua representação, desta maneira um mesmo processo pode ser utilizado para criar diferentes representações.

  • Estrutural:
    Diz respeito a composição de objetos e classes;
    Ex: Composite - Compõe objetos em árvores de agregação (relacionamento parte-todo). O Composite permite que objetos agregados sejam tratados como um único objeto.

  • Comportamental:
    Caracteriza o modo como classes e objetos interagem e compartilham responsabilidades.
    Ex: Iterator - Provê um modo de acesso a elementos de um agregado de objetos, seqüencialmente, sem exposição de estruturas internas.
Espero ter esclarecido um pouco mais sobre padrões de projetos.

segunda-feira, 13 de abril de 2009

Um pouco de Acessibilidade web...

Segundo a wikipedia Acessibilidade Web refere-se a prática de fazer websites que possam ser utilizados por todas as pessoas, sejam portadoras de deficiências ou não. Quando os sites são corretamente concebidos, desenvolvidos e editados, todos os usuários possam ter igual acesso à informação e funcionalidade.

As necessidades que a "Acessibilidade Web" pretende abordar incluem:

Navegando hoje, me deparei com este artigo da Lêda Spelta publicado na imasters.com.br, confira!

Os mitos na acessibilidade web

No meu trabalho com acessibilidade web, tenho me deparado com mitos que, por não terem suas verdades decifradas, são reproduzidos e compreendidos no seu sentido literal, o que tem prejudicado bastante o nosso progresso. Eles não aparecem como narrativas de estórias, mas como afirmações pseudocientíficas, que confundem a mente daqueles que ainda não adquiriram um profundo conhecimento do assunto.

Após sete anos de convivência com esses mitos, creio que chegou a hora de sistematizá-los e compartilhá-los com todos aqueles que se interessam pelo tema. Cada mito apresentado será, primeiramente, confrontado com a realidade objetiva, que é, como veremos, muito diferente do que o mito afirma. Em seguida, tentarei explicitar o que entendo ser a verdade oculta encerrada no mito. Neste caso, como a verdade é sempre um temor, será chamada de "temor oculto". Finalmente, tentarei oferecer uma resposta a esse temor, que será chamada de "esclarecimento".

O que é um mito?

Os mitos são narrativas (este é o sentido da palavra original grega), que são reproduzidas (imitadas) até se tornarem coletivas.

Aristóteles, em sua Poética, nos diz que "O imitar é congênito no homem... e os homens se comprazem no imitado." Os mitos não se baseiam na experiência empírica nem científica, baseiam-se na intuição. E aí está a sua força, pois a intuição encerra sempre uma verdade. Porém a verdade do mito não está aparente, precisa ser decifrada.

Quando, por exemplo, digo que determinada mulher é uma Atena, não quero dizer (como no mito da deusa) que ela não foi gerada no ventre de sua mãe, mas dentro da cabeça de seu pai, de onde saiu prontinha, com armadura e tudo! Estou querendo dizer que ela é uma mulher guerreira, racional e bastante identificada com o modo de pensar masculino.

A verdade de um mito, portanto, não é literal, é simbólica. É por este motivo que muitos o confundem com mentira, ilusão, lenda e fantasia. Eles são exatamente isto, se forem considerados no seu sentido literal.

Os mitos na atualidade

Uma característica dos mitos modernos é que, ao contrário dos mitos gregos ou indígenas, eles não se referem à totalidade da existência humana, mas a temas específicos, como a sensualidade, a juventude, o corpo saudável, o poder etc. E, como sua base inconsciente não está na razão e sim na emoção, eles são largamente utilizados na propaganda e na política.

Mito I - "Acessibilidade Web é só para deficientes visuais."

Realidade: Pessoas cegas ou com baixa visão são terrivelmente prejudicadas pela falta deacessibilidade, pois, na maioria das vezes, elas não têm outra forma de obter a informação, a não ser através da internet. Mas não são elas as únicas que necessitam de acessibilidade.

Acessibilidade web é para...

  • ... Quem tem dificuldade para
    • ver a tela,
    • usar o mouse,
    • usar o teclado,
    • ler um texto,
    • ouvir um som,
    • navegar na internet;
  • ... Quem usa um navegador diferente;
  • ... Quem usa um equipamento muito antigo;
  • ... Quem usa um equipamento muito moderno;
  • ... Quem tem uma linha de transmissão muito lenta;
  • ... Quem está num ambiente ou situação que limita alguns dos seus sentidos ou movimentos, ou que requer a sua atenção.

Enfim, acessibilidade web é para todos!

Temor oculto"Imagina o trabalhão que vai dar, fazer acessibilidade para todo mundo!"

Esclarecimento: Quando seguimos uma diretriz de acessibilidade, estamos atendendo simultaneamente a vários tipos de necessidades. Por exemplo, atender a três tipos de deficiências não significa trabalho triplicado.

Note-se que este mito está tão profundamente arraigado em nossa cultura, a ponto de aparecer expressamente no Decreto 5296, o qual estabelece, em seu Artigo 47, que "No prazo de até doze meses a contar da data de publicação deste Decreto, será obrigatória a acessibilidade nos portais e sítios eletrônicos da administração pública na rede mundial de computadores (internet), para o uso das pessoas portadoras de deficiência visual, garantindo-lhes o pleno acesso às informações disponíveis."

Mito II - "Na prática, o número de usuários beneficiados com a acessibilidade é relativamente muito pequeno."

Realidade: A maioria das pessoas que conhecemos não tem nenhuma deficiência e nunca esteve em nenhuma das situações especiais descritas acima. Mas isso não quer dizer rigorosamente nada a respeito da quantidade dessas pessoas e situações. Por exemplo, quantos tailandeses você conhece que usam a internet? Será que você poderia concluir, então, que são muito poucos os tailandeses que usam a internet? Nossa visão da realidade é sempre distorcida, pois tendemos a nos aproximar e conhecer somente aquilo que nos é semelhante.

Temor oculto"Esse negócio de acessibilidade é muito investimento para pouco retorno."

Esclarecimento: Quando tornamos o nosso site acessível, além de atingirmos os usuários da internet que não nos podiam acessar devido às barreiras encontradas, também estamos criando condições para que novas pessoas se animem a usar a internet; ou seja, estamos ampliando o nosso mercado. Além disso, estamos aumentando a visibilidade do site para os buscadores web, pois, assim como as pessoas cegas, eles também só conseguem ler o que está em texto.

Mito III - "Fazer um site acessível demora e custa caro."

Realidade: Geralmente, afirmações como esta são proferidas sem nenhuma avaliação prévia. Contudo, só podemos saber se o tempo e o custo do nosso projeto são adequados, se levarmos em conta os benefícios alcançados.

Temor oculto"Não estarei empregando mal os recursos que tenho, ao fazer acessibilidade? Não vou ficar no prejuízo?"

Esclarecimento: Quebrar todas as escadas de um prédio para colocar rampas e todos os banheiros para torná-los acessíveis vai demandar um tempo e um custo adicionais; mas vai permitir o acesso por muito mais pessoas. Porém, se o prédio for projetado com rampas e banheiros acessíveis, o custo e o tempo de construção não serão maiores por isso. O mesmo acontece com os sites. Algumas adaptações são trabalhosas, mas o resultado vale a pena; e quando se trata de um novo projeto, o custo adicional geralmente não existe.

Mito IV - "É melhor fazer uma página especial para os deficientes visuais."

Realidade: Isto é melhor para quem? Os webdesigners terão trabalho dobrado, para criação e manutenção de duas páginas. Os deficientes visuais ficarão prejudicados, pois o que invariavelmente acaba acontecendo é que a página deles fica desatualizada. Sem falar naquelas páginas especiais, que já são projetadas com menos funcionalidades do que a das "pessoas normais". Além disso, o site continuará inacessível para todos os outros tipos de deficiências, necessidades ou situações especiais.

Temor oculto"A gente não vai conseguir fazer uma página acessível, que seja tão bonita e funcional como a nossa."

Esclarecimento: A partir de 1998, com a promulgação da Section 508 (lei americana de acessibilidade), as grandes empresas de software começaram a investir em acessibilidade. Atualmente, os recursos de acessibilidade disponíveis já nos permitem criar sites bonitos, funcionais e acessíveis. Obviamente, para se obter um bom resultado, a técnica de acessibilidade, como qualquer outra, precisa ser aprendida.

Mito V - "Um site acessível a deficientes visuais não é bonito."

Realidade: Pessoas cegas não têm condições de usufruir da maioria dos atributos visuais de um site. Porém, os elementos que tornam um site esteticamente bonito não atrapalham as pessoas cegas, se forem criados dentro dos padrões de codificação, das diretrizes de acessibilidade e se a página tiver uma boa arquitetura de informação.

Temor oculto"Só sei fazer sites bonitos usando tecnologias inacessíveis; de fato, não sei exatamente quais são os elementos visuais que atrapalham a acessibilidade. Por isso, quando tenho que fazer um site acessível, faço sempre o arroz com feijão."

Esclarecimento: Sites acessíveis a deficientes visuais podem ter imagens, fotos, vídeos, gráficos, etc, etc... Basta observar os padrões de codificação e as diretrizes de acessibilidade; e nenhuma delas proíbe essas coisas. Os testes com usuários, além de fazerem parte das boas práticas de um projeto, sempre ajudam a desmistificar essa questão.

Mito VI. - "Vamos por partes: primeiro fazemos o site, depois fazemos acessibilidade."

Realidade: Não dá para fazer tudo ao mesmo tempo, precisamos priorizar. Porém, inaugurar o prédio com escadas e depois quebrar tudo para colocar rampas não é priorização, é desperdício de tempo e recursos. E é exatamente isto que acontece com um site, quando deixamos a acessibilidade para depois. Vamos ter que refazer muita coisa que já poderia ter sido feita com acessibilidade, sem custo adicional.

Temor oculto"Não vamos conseguir fazer um site acessível, com o tempo, os recursos e a equipe que temos."

Esclarecimento: Como acontece com qualquer tecnologia, geralmente o primeiro projeto acessível demanda um tempo e um custo maior, porque precisamos de capacitar a equipe. Mas isto acontece apenas no primeiro projeto, além de ser um bom investimento em termos de ampliação do público alvo.

Mito VII - "A gente sabe o que é bom para o usuário."

Realidade: A gente aprende muito sobre o usuário com a experiência. Mas a gente só aprende tudo sobre o usuário, se a gente for o próprio usuário; ainda assim, agente vai ser apenas um dos vários tipos de usuários possíveis, deixando de fora todos os outros grupos.

Temor oculto"Não quero expor meu projeto às críticas do usuário."

Esclarecimento: Quanto mais cedo os usuários puderem dar seus "palpites" no projeto, menos alterações ele precisará depois e mais robusto ele será. Não tenha medo!

Um Grande Equívoco

Existe uma oitava assertiva, que não é exatamente um mito, nem se refere apenas à acessibilidade. Trata-se de uma convicção equivocada, proveniente da falta de conhecimento da repercussão da web, do seu impacto na vida das pessoas e na forma como a informação é veiculada nos dias de hoje. Apesar de não ser um mito, podemos detectá-la como um pensamento subjacente em quase todos os mitos descritos anteriormente. A assertiva é a seguinte:

"Meu site é direcionado a um público específico; ele não interessa a todos os grupos de usuários."

Para entendermos onde está o equívoco, precisamos analisar primeiro o que é "público específico" e o que são "grupos de usuários".

Normalmente, quando falamos que o nosso site se dirige a um público específico, estamos nos referindo ao conteúdo do site e estamos querendo dizer que tal conteúdo só tem interesse para uma determinada parcela do público em geral. Sabemos, por exemplo, que o público-alvo de um site de notícias, ou de um serviço público, é muito diferente do público-alvo de um site de tricot, ou de paleontologia. Contudo, isto é muito diferente do conceito de grupos de usuários, utilizado em acessibilidade e em usabilidade. Neste caso, estes grupos não se referem ao conteúdo da informação, mas às características de funcionalidade dos usuários. Muitas destas características foram descritas anteriormente, na análise do Mito I.

O equívoco acontece quando associamos grupos de interesses a grupos de funcionalidades. A experiência nos mostra que esta associação é muito mais tênue do que parece. Vejamos alguns exemplos:

  • Um homem com baixa visão que entra no site de um fabricante de automóveis, para escolher um modelo para a sua mãe.
  • Uma jovem surda que entra numa loja virtual de CDs, para escolher um presente para o seu namorado.
  • Um menino de 11 anos que entra num site direcionado à terceira idade, para pegar uma informação para a sua avó.
  • Uma estudante cega que entra numa livraria virtual, para comprar livros que serão escaneados por ela própria e lidos com o seu programa leitor de telas.

Portanto, quando restringimos o acesso do nosso site ao que julgamos serem as características do seu público alvo, estamos, na prática, usando a internet para limitar o nosso público, ao invés de ampliá-lo.

Veja o artigo original aqui!