A idéia de fazer isso veio por conta de um amigo, Claudio Cordovil, que tem reclamado constantemente de requisições minhas para um dos jogos do Facebook. Infelizmente alguns jogos disparam requisições para nossa lista de amigos e não temos controle sobre isso, porém temos cono controlar o que queremos e não receber de nossos amigos.
"Pensar apenas ou desejar somente nunca levou ninguém a lugar nenhum. É necessário também a ação"
Mostrando postagens com marcador Assuntos Gerais. Mostrar todas as postagens
Mostrando postagens com marcador Assuntos Gerais. Mostrar todas as postagens
domingo, 18 de novembro de 2012
Bloqueando Applicativos Indesejaveis no Facebook
Tenho andado meio sumido do blog mas estou voltando com mais um vídeo, dessa vez algo um pouco fora do contexto de desenvolvimento mas que irá agradar muitas pessoas que sofrem por não saber como bloquear as requisições e convites para jogos e aplicativos no facebook.
A idéia de fazer isso veio por conta de um amigo, Claudio Cordovil, que tem reclamado constantemente de requisições minhas para um dos jogos do Facebook. Infelizmente alguns jogos disparam requisições para nossa lista de amigos e não temos controle sobre isso, porém temos cono controlar o que queremos e não receber de nossos amigos.
A idéia de fazer isso veio por conta de um amigo, Claudio Cordovil, que tem reclamado constantemente de requisições minhas para um dos jogos do Facebook. Infelizmente alguns jogos disparam requisições para nossa lista de amigos e não temos controle sobre isso, porém temos cono controlar o que queremos e não receber de nossos amigos.
quarta-feira, 4 de abril de 2012
Configurando o ColdFusion Builder
Da série de vídeos ColdFusion, integrando o ColdFusion Builder com o Server.
quinta-feira, 29 de março de 2012
Instalando o Adobe ColdFusion (Zeus)
Dando continuidade a série de vídeos sobre IIS e ColdFusion, finalmente o vídeo para instalar o Adobe ColdFusion.
Nesse vídeo como tem o tempo do loading aproveitei para falar sobre assuntos como licenciamento, versões e novidades da nova versão Zeus.
Nesse vídeo como tem o tempo do loading aproveitei para falar sobre assuntos como licenciamento, versões e novidades da nova versão Zeus.
segunda-feira, 26 de março de 2012
Adobe Shadow - Novidades para Mobile Dev
Para quem trabalha com desenvolvimento web em mobiles, já deve ter notado quanto tempo se perde em ter um ambiente de testes, muitas vezes temos que colocar o aparelho dentro da rede local e algumas empresas acham que o celular pessoal do desenvolvedor vem no pacote de desenvolvimento.
Tirando esses fatos corporativos e de falta de noção para com a realidade, o processo de testes dentro dos aplicativos normalmente é afetado pelos emuladores, que muitas vezes apenas simulam o tamanho de tela. Mas como saber se o resultado esperado será o mesmo no produto final?
Recentemente a Adobe publicou um prodto novo no Labs (http://labs.adobe.com), o Shadow, com certeza um nome novo será dado a ele, mas o importante mesmo é o que o programa se dispoém a fazer.
A instalação é dependente de três etapas, uma instalação no desktop, uma instalação no brwoser e um App no smartphone. Ná instalação desktop, processo normal NNF para windows e Mac. No browser, a instalação de uma extenção para o Google Chrome é necessária e só funciona nele. No smartphone você precisa ter um IOS ou um Android.
O que eu achei mais legal é o fato de você usar o navegador normalmente, ir alternando abas e o conteudo ser atualizado em tempo real, ou seja a emulação é quase perfeita, só faltando o teste final no navegador do aparelho para garantir que no final de tudo certo.
Ficou curioso? então da uma olhada e teste você mesmo.
http://labs.adobe.com/downloads/shadow.html
Tirando esses fatos corporativos e de falta de noção para com a realidade, o processo de testes dentro dos aplicativos normalmente é afetado pelos emuladores, que muitas vezes apenas simulam o tamanho de tela. Mas como saber se o resultado esperado será o mesmo no produto final?
Recentemente a Adobe publicou um prodto novo no Labs (http://labs.adobe.com), o Shadow, com certeza um nome novo será dado a ele, mas o importante mesmo é o que o programa se dispoém a fazer.
A instalação é dependente de três etapas, uma instalação no desktop, uma instalação no brwoser e um App no smartphone. Ná instalação desktop, processo normal NNF para windows e Mac. No browser, a instalação de uma extenção para o Google Chrome é necessária e só funciona nele. No smartphone você precisa ter um IOS ou um Android.
O que eu achei mais legal é o fato de você usar o navegador normalmente, ir alternando abas e o conteudo ser atualizado em tempo real, ou seja a emulação é quase perfeita, só faltando o teste final no navegador do aparelho para garantir que no final de tudo certo.
Ficou curioso? então da uma olhada e teste você mesmo.
http://labs.adobe.com/downloads/shadow.html
sexta-feira, 16 de março de 2012
Instalando o Internet Information Service (IIS) e como configura-lo com o Adobe ColdFusion - Parte 02
Dando seguencia a série de vídeos para iniciação dos Web Developers o segundo vídeo esta online. O resultado de todos os outros vídeos você confere em http://www.youtube.com/user/rafabandbr/featured
quinta-feira, 15 de março de 2012
iOS 5.1 já está disponível para download
Durante o evento no qual a Apple lançou oficialmente o novo iPad, a empresa disponibilizou, juntamente com a versão do Siri em japonês, a nova versão do sistema operacional móvel, o iOS 5.1, que traz novidades para os donos de iPhone, iPad e iPod touch.
De acordo com as notas da versão do update, as fotos do serviço de compartilhamento de fotos do iCloud podem ser apagadas individualmente, um pedido dos usuários que precisavam passar por um processo um tanto quanto trabalhoso para reinicializar o compartilhamento de fotos, que só poderia ser feito no site doiCloud.
O atalho de câmera na tela bloqueada, que era acessado com dois cliques com o botão home, agora fica permanentemente visível quando o iPhone 4S, iPhone 4, iPhone 3GS ou iPod Touch de quarta geração estiverem bloqueados. Além disso, ainda sobre a câmera, o app homônimo foi renovado no iPad, e ganhou um recurso de detecção de rostos.
O áudio no iPad foi melhorado ao executar programas de TV e filmes e o controle de reprodução de podcasts foi aperfeiçoado, e um problema que poderia deixar as ligações sem som no iPhone foi corrigido. Por fim, a empresa afirma que o resolveu um problema que poderia afetar a autonomia da bateria dos produtos, além de outras melhorias e correções.
A atualização tem 177MB e pode ser feita a partir do próprio dispositivo em Geral > Atualização do Software ou via iTunes, que também ganhou uma nova versão, e atualmente encontra-se na versão 10.6.
Instalando o Internet Information Service (IIS) e como configura-lo com o Adobe ColdFusion
Após algum tempo chegamos a conclusão que o blog é uma ferramenta muito legal para compartilhar códigos. Mais quando o assunto é passo-a-passo tenho minhas dúvidas.
Por conta disso, estamos selecionando alguns vídeos de uma série de ações básicas para desenvolvimento web direto da nossa divisão de treinamentos. O resultado você confere em http://www.youtube.com/user/rafabandbr/featured
No primeiro video de uma série estamos demonstrando como instalar o IIS para trabalhar com o Adobe ColdFusion.
Por conta disso, estamos selecionando alguns vídeos de uma série de ações básicas para desenvolvimento web direto da nossa divisão de treinamentos. O resultado você confere em http://www.youtube.com/user/rafabandbr/featured
No primeiro video de uma série estamos demonstrando como instalar o IIS para trabalhar com o Adobe ColdFusion.
quarta-feira, 7 de março de 2012
O Barato sai Caro
Quase 30 mil blogs do WordPress foram infectados em uma nova onda de
ataques orquestrada por uma gangue de cibercriminosos para distribuir
antivírus falsos. O alerta é de pesquisadores da empresa de segurança
Websense.
Os ataques resultaram em mais de 200 mil páginas infectadas que redirecionam os usuários para sites que mostram verificações falsas de antivírus. Isso faz parte de uma campanha de distribuição de AVs falsos que vem acontecendo há meses, disseram os pesquisadores.
Falsas verificações de antivírus não são novidade. Na verdade, há alguns anos atrás este tipo de engenharia social foi um dos principais métodos de distribuição de scareware aos internautas.
No entanto, muitas gangues de cibercriminosos, desde então, começaram a se focar em ataques de download automático (drive-by) que exploram vulnerabilidades do navegador e de plug-ins para fazer o download automático e instalar malware.
O grande número de páginas infectadas nesta campanha é uma indicação de que esses golpes continuam funcionando, disse Elad Sharf, pesquisador sênior de segurança da Websense Labs. "Sites vulneráveis são uma fonte rica de oportunidades para os criminosos."
Mais de 85% dos sites comprometidos são dos EUA, mas os visitantes estão no mundo todo. "O ataque pode ser específico para os EUA, mas todo mundo está em risco quando visitar estas páginas comprometidas", disse Sharf.
Muitos dos blogs comprometidos nestes ataques recentes rodam versões desatualizadas do WordPress, tinham plug-ins vulneráveis instalados ou senhas administrativas suscetíveis a ataques de força bruta, disse David Dede, um pesquisador de segurança da Sucuri Security. "Parece que os crackers estão tentando de tudo ultimamente."
Pesquisadores da Sucuri também têm acompanhado essa campanha de distribuição de scareware e descobriram que um plug-in para WP chamado ToolsPack foi instalado em muitos dos blogs comprometidos. Este plug-in se disfarça como uma coleção de ferramentas de administração do WP, mas na realidade contém um backdoor que os atacantes usam para manter o acesso não autorizado aos locais afetados, disse Dede.
Não tenho nada contra as tecnologias open source, porém o fato de muitas empresas estarem usando esses produtos como plataformas reais é realmente preocupante. O Open Source se destina a estudos de tecnologias e suas aplicações, na maioria dos casos são betas que vão se atualizando ao longo dos anos.
Empresas que veem esses produtos prontos como fonte de renda colocam em risco o cliente e seus afiliados os sugeitando a perda de dados, malwares e viros de todos os tipos.
Isso fica facil para a pessoa mal intenciona uma vez que ela já tem o código fonte e pode explorar todas as falhas conhecidas, é mais uma questão de tentativa e erro do que talento tecnológico.
Os ataques resultaram em mais de 200 mil páginas infectadas que redirecionam os usuários para sites que mostram verificações falsas de antivírus. Isso faz parte de uma campanha de distribuição de AVs falsos que vem acontecendo há meses, disseram os pesquisadores.
Falsas verificações de antivírus não são novidade. Na verdade, há alguns anos atrás este tipo de engenharia social foi um dos principais métodos de distribuição de scareware aos internautas.
No entanto, muitas gangues de cibercriminosos, desde então, começaram a se focar em ataques de download automático (drive-by) que exploram vulnerabilidades do navegador e de plug-ins para fazer o download automático e instalar malware.
O grande número de páginas infectadas nesta campanha é uma indicação de que esses golpes continuam funcionando, disse Elad Sharf, pesquisador sênior de segurança da Websense Labs. "Sites vulneráveis são uma fonte rica de oportunidades para os criminosos."
Mais de 85% dos sites comprometidos são dos EUA, mas os visitantes estão no mundo todo. "O ataque pode ser específico para os EUA, mas todo mundo está em risco quando visitar estas páginas comprometidas", disse Sharf.
Muitos dos blogs comprometidos nestes ataques recentes rodam versões desatualizadas do WordPress, tinham plug-ins vulneráveis instalados ou senhas administrativas suscetíveis a ataques de força bruta, disse David Dede, um pesquisador de segurança da Sucuri Security. "Parece que os crackers estão tentando de tudo ultimamente."
Pesquisadores da Sucuri também têm acompanhado essa campanha de distribuição de scareware e descobriram que um plug-in para WP chamado ToolsPack foi instalado em muitos dos blogs comprometidos. Este plug-in se disfarça como uma coleção de ferramentas de administração do WP, mas na realidade contém um backdoor que os atacantes usam para manter o acesso não autorizado aos locais afetados, disse Dede.
Não tenho nada contra as tecnologias open source, porém o fato de muitas empresas estarem usando esses produtos como plataformas reais é realmente preocupante. O Open Source se destina a estudos de tecnologias e suas aplicações, na maioria dos casos são betas que vão se atualizando ao longo dos anos.
Empresas que veem esses produtos prontos como fonte de renda colocam em risco o cliente e seus afiliados os sugeitando a perda de dados, malwares e viros de todos os tipos.
Isso fica facil para a pessoa mal intenciona uma vez que ela já tem o código fonte e pode explorar todas as falhas conhecidas, é mais uma questão de tentativa e erro do que talento tecnológico.
segunda-feira, 23 de janeiro de 2012
iBooks 2, da Apple, impactará empresas. Veja 5 mudanças
Atualização do software de livros eletrônicos da Apple promete mudar muita coisa além dos livros didáticos nas escolas.
A Apple lançou na última quinta(19/1) o update iBooks 2, que expande seu famoso aplicativo, explorando recursos como itens em 3D e vídeos, e abre caminho na App Store para livros didáticos interativos. Os esforços têm como objetivo fornecer aos estudantes materiais dinâmicos e interativos de aprendizado.
Apesar de o foco ser o mercado educacional, o iBooks 2 também terá um impacto sobre as pequenas empresas.
Veja abaixo algumas maneiras como o iBooks 2 bem-sucedido pode influenciar seu negócio:
A Apple lançou na última quinta(19/1) o update iBooks 2, que expande seu famoso aplicativo, explorando recursos como itens em 3D e vídeos, e abre caminho na App Store para livros didáticos interativos. Os esforços têm como objetivo fornecer aos estudantes materiais dinâmicos e interativos de aprendizado.
Apesar de o foco ser o mercado educacional, o iBooks 2 também terá um impacto sobre as pequenas empresas.
Veja abaixo algumas maneiras como o iBooks 2 bem-sucedido pode influenciar seu negócio:
- Criação de conteúdo A Apple lançou um aplicativo gratuito chamado iBooks Author, que, segundo ela, permite criar “livros lindos em tela cheia; animações interativas, fotos, diagramas, vídeos; navegação rápida e fluida; marcação de texto e anotações. O app não é apenas para livros didáticos, uma vez que a Apple sugere que ele é ótimo para “livros de receitas, de história, de imagens, e mais”. A ferramentas inclui templates, funciona pelo meio de gestos de mouse de arrastar e soltar, e permite que widgets sejam incluídos nos livros para habilitar galerias de fotos, vídeos, slideshows e objetos 3D. Para as empresas, essa pode ser uma ótima ferramenta para a criaçõa materiais profissionais e manuais de treinamento – ou, se a sua companhia fornece conteúdo, uma nova maneira de gerar e vender suas mídias, utilizando todo o potencial de distribuição de conteúdo da Apple.
- Treinamento de funcionários Se o iBooks 2 for bem-sucedido, à medida que os educadores migrarem os livros de papel em direção à mídia digital, espere que outros tipos de treinamento venham a seguir. A mudança provavelmente será parecida com mudar de apresentações com projetor para slideshows no PowerPoint. Uma vez que você viu uma apresentação no PowerPoint, um conjunto de transparência não é mais comparável. Qualquer treinamento que sua empresa fornecer provavelmente terá o formato com o qual os seus funcionários recém-saídos da faculdade estarão familiarizados. Ter as ferramentas para combinar isso tudo em um formato facilmente digerível será conveniente. Precisar se voltar para informações estáticas e tediosas será um trabalho extra.
- Demanda por tablets Os tablets estão em ascensão, e usá-los como livros didáticos será mais uma forma pela qual todo estudante acabará usando um deles. Espere por ofertas semelhantes dos rivais da Apple, e que os tablets eventualmente tornem-se um material escolar padrão. Da mesma maneira que quase todo estudante universitário precisa de um notebook atualmente, em breve eles todos precisarão de tablets. Uma vez que estiverem no ambiente de trabalhado, e tendo sido treinados em um tablets, eles vão esperar usar um tablet para as tarefas diárias. As empresas não deveriam pensar em "acomodar os tablets", mas em adotá-los como uma importante ferramenta de trabalho.
- Demanda pela Apple O iPad atualmente domina o mercado de tablets, com mais de 70% de participação no mercado. A concorrência está melhorando e lançando mais opções, mas é possível que essa liderança inicial da “maçã” continue ainda por algum tempo. Como aconteceu com o mercado de músicas, a Apple pode permanecer no controle, e se isso acontecer, espere por uma maior demanda pelos produtos da Apple nas empresas. Primeiro o iPhone e então o iPad eram vistos como "itens de entrada”, induzindo os usuários para o ecossistema da Apple e fazendo-os querer mais produtos da fabricante. À medida que os estudantes forem expostos aos produtos da Apple quando crianças, eles vão crescer esperando usá-los no trabalho também.
- Funcionários melhores? Por que mudar do papel para a mídia digital? Para a Apple e suas rivais, há certamente um ganho financeiro nisso. A partir de um ponto de vista pedagógico, será que um tablet vai ser uma melhor ferramenta educacional do que um livro de papel?
- Talvez uma mudança na ferramenta e a adição de multimídia não faça diferença. A adição de áudio, vídeo, imagens e widgets poderia fornecer uma experiência passiva pela qual os estudantes apenas assistem às luzes flamejantes e os objetos em movimento e não aprendem nada.
- No entanto, esperançosamente a capacidade de transmitir informações no formato mais rico possível vai encorajar os estudantes, melhorando sua educação ao facilitar para eles a absorção de informações. E com mais estudantes se formando e entrando para o mercado de trabalho, as empresas terão uma reserva mais forte para escolher suas contratações, o que beneficia todos os tipos de negócios.
sábado, 17 de dezembro de 2011
HTML 5, Flash, Flex, Air e Outras Drogras - Parte 2
No post anterior falei um pouco sobre essa guerra de flash, flex, air, html 5 e outras drogas que o mercado está nos impondo e empurrando garganta abaixo.
Mundo Desktop
Deixando o universo Mobile, temos o mundo dos desktops, onde passamos muito tempo no trabalho, escola, cursos e até em casa. É um mundo dominado pelas telas grandes, muita memória e espaço em disco. Com isso o flash player passa a ser quase que imperativo nesse mundo chegando a 99% das maquinas em todo mundo. A utilização dele é algo que em alguns casos chega a ser imperceptível, mas ele esta lá.
Ao contrário do mundo Mobile o Flash é o manda-chuva dos plugins para desktop. O legal é que se formos observar o nosso desktop é cheio desses plugins, são os plugins de audio, video, o flash, o java, aquele que você usa para organizar o desktop e por ai vai. Esse carinha a Adobe não deu para o pessoal do Apache, porém libera o fonte para projetos voltados a novas distribuições, assim como acontece com o plugin do Java.
O pessoal fanático por HTML 5 diz que o flash vai morrer, será? Para algumas coisas com certeza, principalmente para aquelas constrangedoras, como um banner rotator que não mostra os banners, ou uma propaganda do silverlight feita em flash.
A verdade dos fatos é que morrer é muito definitivo e o HTML 5 teria que se tornar um padrão real antes de mais nada. Como assim um padrão? O HTML 5 esta no W3C como um RASCUNHO de Projeto http://dev.w3.org/html5/spec/Overview.html e para ajudar as grandes novidades que ele oferece ainda não são suportadas 100% pelos principais navegadores do mercado exemplos disso podem ser vistos e testados em http://html5demos.com/.
Com base nisso existem alguns detalhes de mercado, onde você faz o seu banner? Em um plugin que está em 99% das maqunas no mundo ou em um padrão que está em cerca de 30% dos navegadores e nem todos esses 30% implementão o que você usa?
Não estuo dizendo para ignorarem o HTML5, ele é legal porém lembre-se que o usuário do seu site pode ainda estar rodando um windows XP com internet explorer 6, então a utilização desse recurso deve ser dosada e tratada para cada situação. Da mesma forma que não se deve fazer um site 100% em flash, não se deve fazer um site 100% em HTML 5, a dosagem depende de muitos fatores.
Nesse intervalo do primeiro post para este realizei vários testes para ter base no que estou falando. O HTML 5 não tem condições para competir com o Flash Player. Vamos aos fatos!
Uma das ferramentas em HTML mais usadas no mundo se chama GMail, e se engana quem pensa que essa maravilha do HTML é feita com HTML 5. O GMail trabalha com FRAMES, como mostra a imagem a seguir.
Para piorar as coisas para o lado do HTML 5 essa mesma maravilha tem uma função, que eu particularmente acho muito legal, que é o upload assincrono de arquivos, aquele recurso onde você seleciona o arquivo e ele vai sendo enviado enquanto você digita seu e-mail com direito até a barra de progresso, HTML 5? Não mesmo dessa vez é Flash Player, o mesmo que os adoradores do apocalipse dizem que vai morrer em 21/12/2012... Ops essa é outra história... quiz dizer os adoradores do HTML 5 dizem que vai morrer, mais uma vez, imagem na tela.
Então onde o HTML 5 se aplica? Onde o Flash não se aplica? O HTML 5 se aplica aos novos sites que focam em smartphones, tablet e novas versões dos navegadores. O flash se aplica a todo o resto, porém com doses de sabedoria.
Não se deve fazer um site 100% em flash, se eu quero acessar seu site do meu smartphone, posso ter que parar numa lanhouse por falta do plugin do flash, mas com certeza não ver o banner do seu site no meu smartphone seria muito bom.
Eu particularmente, tenho usado o flash player no backend dos sistemas atraves do Flex e Air, funciona muito bem e como o blackend é algo que me obriga a conhecer os usuários, eu posso falar "atualiza o plugin do flash" caso algo não funcione, porém em um site fica dificil ligar ou mandar um e-mail para alguém que eu nem sei quem é.
Resumo da ópera? O Flash Player tem mais chances de se tornar o novo HTML do que o HTML 5 se tornar um padrão real e funcional em todos os navegadores. Enquanto esse dia não chega a melhor opção se chama JQuery e HTML5 Fix.
O JQuery é um conjunto de códigos javascript que cria um novo padrão resolvendo problemas de compatibilidade entre navegadores e tem até uma versão mobile.
O HTML Fix é um projeto que esta hospedado no google e visa em fazer funcionar de forma padronizada as tags e atributos do HTML 5 que muitos navegadores não suportam.
Mundo Desktop
Deixando o universo Mobile, temos o mundo dos desktops, onde passamos muito tempo no trabalho, escola, cursos e até em casa. É um mundo dominado pelas telas grandes, muita memória e espaço em disco. Com isso o flash player passa a ser quase que imperativo nesse mundo chegando a 99% das maquinas em todo mundo. A utilização dele é algo que em alguns casos chega a ser imperceptível, mas ele esta lá.
Ao contrário do mundo Mobile o Flash é o manda-chuva dos plugins para desktop. O legal é que se formos observar o nosso desktop é cheio desses plugins, são os plugins de audio, video, o flash, o java, aquele que você usa para organizar o desktop e por ai vai. Esse carinha a Adobe não deu para o pessoal do Apache, porém libera o fonte para projetos voltados a novas distribuições, assim como acontece com o plugin do Java.
O pessoal fanático por HTML 5 diz que o flash vai morrer, será? Para algumas coisas com certeza, principalmente para aquelas constrangedoras, como um banner rotator que não mostra os banners, ou uma propaganda do silverlight feita em flash.
A verdade dos fatos é que morrer é muito definitivo e o HTML 5 teria que se tornar um padrão real antes de mais nada. Como assim um padrão? O HTML 5 esta no W3C como um RASCUNHO de Projeto http://dev.w3.org/html5/spec/Overview.html e para ajudar as grandes novidades que ele oferece ainda não são suportadas 100% pelos principais navegadores do mercado exemplos disso podem ser vistos e testados em http://html5demos.com/.
Com base nisso existem alguns detalhes de mercado, onde você faz o seu banner? Em um plugin que está em 99% das maqunas no mundo ou em um padrão que está em cerca de 30% dos navegadores e nem todos esses 30% implementão o que você usa?
Não estuo dizendo para ignorarem o HTML5, ele é legal porém lembre-se que o usuário do seu site pode ainda estar rodando um windows XP com internet explorer 6, então a utilização desse recurso deve ser dosada e tratada para cada situação. Da mesma forma que não se deve fazer um site 100% em flash, não se deve fazer um site 100% em HTML 5, a dosagem depende de muitos fatores.
Nesse intervalo do primeiro post para este realizei vários testes para ter base no que estou falando. O HTML 5 não tem condições para competir com o Flash Player. Vamos aos fatos!
Uma das ferramentas em HTML mais usadas no mundo se chama GMail, e se engana quem pensa que essa maravilha do HTML é feita com HTML 5. O GMail trabalha com FRAMES, como mostra a imagem a seguir.
Para piorar as coisas para o lado do HTML 5 essa mesma maravilha tem uma função, que eu particularmente acho muito legal, que é o upload assincrono de arquivos, aquele recurso onde você seleciona o arquivo e ele vai sendo enviado enquanto você digita seu e-mail com direito até a barra de progresso, HTML 5? Não mesmo dessa vez é Flash Player, o mesmo que os adoradores do apocalipse dizem que vai morrer em 21/12/2012... Ops essa é outra história... quiz dizer os adoradores do HTML 5 dizem que vai morrer, mais uma vez, imagem na tela.
Então onde o HTML 5 se aplica? Onde o Flash não se aplica? O HTML 5 se aplica aos novos sites que focam em smartphones, tablet e novas versões dos navegadores. O flash se aplica a todo o resto, porém com doses de sabedoria.
Não se deve fazer um site 100% em flash, se eu quero acessar seu site do meu smartphone, posso ter que parar numa lanhouse por falta do plugin do flash, mas com certeza não ver o banner do seu site no meu smartphone seria muito bom.
Eu particularmente, tenho usado o flash player no backend dos sistemas atraves do Flex e Air, funciona muito bem e como o blackend é algo que me obriga a conhecer os usuários, eu posso falar "atualiza o plugin do flash" caso algo não funcione, porém em um site fica dificil ligar ou mandar um e-mail para alguém que eu nem sei quem é.
Resumo da ópera? O Flash Player tem mais chances de se tornar o novo HTML do que o HTML 5 se tornar um padrão real e funcional em todos os navegadores. Enquanto esse dia não chega a melhor opção se chama JQuery e HTML5 Fix.
O JQuery é um conjunto de códigos javascript que cria um novo padrão resolvendo problemas de compatibilidade entre navegadores e tem até uma versão mobile.
O HTML Fix é um projeto que esta hospedado no google e visa em fazer funcionar de forma padronizada as tags e atributos do HTML 5 que muitos navegadores não suportam.
HTML 5, Flash, Flex, Air e Outras Drogras - Parte 1
Resolvi aproveitar o sábado de sol para fala sobre o tumulto no mercado web sobre Adobe com o Flash, Flex, Air e o HTML 5. Não vou puxar sardinha para o lado de ninguém, porém vou montar um cenário para cada uma das plataformas.
A cerca de mais ou menos um mês a Adobe anunciou descontinuar o plugin do flash para Mobile, o mercado entendeu descontinuar o Flash e muitos falaram "HTML 5 ganhou".
Flash Player Mobile
Em primeiro lugar, vamos pensar o seguinte, esse plugin comia bateria dos poucos celulares que rodavam o plugin e não previa a virada de mesa dos smartphones sem teclado como o iPhone. O mercado mobile para o flash era pequeno por conta disso e ficou ainda menor com o iPhone que aproveitou o conceito de Apps para matar o plugin, com isso os números da Adobe para mobile não foram nada bom.
Não preciso explicar o gráfico, certo? Esses números eu peguei no próprio site da Adobe, e representa a penetração do Flash Player Mobile no mercado e a previsão até 2015. Então com isso a gente pode dizer que foi uma decisão sábia focada na resposta do mercado e não tem absolutamente nada a ver com o HTML 5.
HTML Mobile
Partindo para o HTML, não estou falando do 5, focado em Mobile temo um cenario favoravel a plataforma, nem todos os celulares e smartphones tem flash player, mas todo celular e smartphone tem navegador, que muito provavelmente aceita HTML.
Nesse ponto temos vários celulares com suporte a html e com a tela pequena toda navegação se torna vertical e os desafios de renderizar ficam a cargo dos navegadores que tem como trabalho transformar texto em visual e interpletar um pouco de javascript. No caso dos smartphones existem algumas diferenças por conta de recursos como o acelerômetro, multi touch e geolocalização, o que na maioria dos casos se resolvem por acesso nativo a API do aparelho pelo browser que os desenvolvedores realizam acesso pelo javascript de API's ao meu ver ainda muito pesadas como o JQuery Mobile. O lado bom dessa história para o HTML é que existem pelo menos 18 navegadores que vem instalados nos smartphones e outros a serem instalados, a lista consegui em http://en.wikipedia.org/wiki/Mobile_browser, dando ao usuário final as 2 opções: usar o que tem ou trocar e isso o flash player nunca terá como opção.
Então de forma clara e objetiva, sim o HTML é uma boa opção para mobiles, porém ainda temos outra opção de aplicativos mobile que são aqueles instaláveis, baixados, comprados na Apple Store, Android Market. Nessa hora é onde entra a comparação HTML 5 com o Air Mobile.
Air Mobile
Em primeiro lugar o que é o Air Mobile? Ele não é o Flash Player Mobile descontinuado e sim um ruimtime que possui um SDK que permite criar aplicativos nativos para plataformas específicas.
Pontos positivos para ele começam com o fato de que o desenvolvedor que conhece Flex e ActionScript consegue criar aplicativos instalaveis para iPhone, iPad, iPod, Android e Playbook sem saber nada dessas plataformas, o que para a empresa é abrir um mercado com INVESTIMENTO ZERO no profissional.
Por ser um complilador para multiplos dispositivos alguns recursos ativos e específicos acabam ficando de fora o que dependendo do aplicativo pode ser um problema, mas dependendo do recurso pode-se criar uma extenção nativa ou ANE (ActionScript Native Extenssion) que é um recurso novo no SDK do Flex e até agora nos testes que eu tenho feito resolvem boa parte dos problemas.Uma coisa que achei muito legal no ANE é que ele não se limita a gerar extensões nativas ao mobile, mas também ao desktop, as isso é assunto para outro post.
Um caso legal para o Air Mobile é pensar nas possibilidades geradas em termo de negócio e produtividade, o mesmo App se montado seguindo uma metodologia de skins, bibliotecas, orientação a objetos, pode ser fácilmente distribuido em versão web, desktop e mobile simplesmente mudando a forma de compilação.
Pontos negativos do Air mobile? Bom o principal e não estou puxando para o lado da Adobe é o fato do projeto ter sido doado a Apache Software Foundation, ponto negativo porque a comunudade de desenvolvedores Adobe esta acostumada a reportar problemas e aguardar novo releases e correções, indo para a Apache o Air e o Flex vão ficar nas nossas mãos, se tem um problema vamos resolver e isso não é muito a cara do profissional que esta mais acostumado a reclamar do que colocar a mão na massa e resolver.
Acredito que essa mudança vai exigir alguns anos de adaptação, mas por sorte a Adobe se comprometeu a continuar no projeto até final de 2012 e entregar todos os componnetes em modelo spark, o que me deixa aliviado.
Então quando usar o Air Mobile? Quando ele ganha do HTML 5?
O primeiro ponto para o Air esta no fato dele se tornar um aplicativo nativo, ou seja, você tem um ícone no smartphone com o seu app e não tem que acessar o browser e buscar nos favoritos.
O segundo é o acesso a alguns recursos que dependendo do aplicativo podem fazer diferença, se vocÊ cria um e-commerce pode ter um aviso de entrega, disponibilidade em tempo real com direito a saber se o cara recebeu e abriu a informação, se for uma loja física o app pode rodar em background e apitar que você esta perto da loja
O terceito e na minha opinião o mais importante, você pode restringir e quantificar a utilização do app, se é um ERP não é muito legal garantir acesso a qualquer um e o app instalado é uma forma de garantia uma vez que podemos gerar um token de acesso
HTML 5 Mobile
No HTML 5 mobile temos muitas coisas que o Air mobile faz, a única diferença é que não instalamos o aplicativo, pelo menos era o que eu pensava, mas ao publicar este artigo o amigo Janderson @jandersonfc informou que já tem como se resolver isso através do appcelerator, mas continua o fato dele ser acessado via web. Boa parte do que foi dito sobre o html se aplica ao HTML 5 a diferença fica nas novas tags que fazem coisas que o Flash Player faz a mais de 10 anos.
Pontos positivos? Se não precisa instalar é só acessar e usar o usuário não tem o impacto de fazer download do app para usar, não gasta o espaço em disco do aparelho, só consome a sua internet, se estiver num wifi sem muitos problemas, mas se tiver que depender do 3g é chorar e esperar. Outro problema que se tem no HTML 5 é a questão de padronização. No mercado existem pelo menos 18 navegadores que vem instlados como padrão nos celulares e smartphones e outros montes a serem instlados, a conseguência disso é que cada um nterpleta o código ao seu bel prazer, e o que seria uma coisa simples passa a ser um trabalho de condicionais do tipo "se for navegador X faz assim se for navegador Y faz assado", isso tem se resolvido com as libs de javascript, mas mesmo elas tem esse problema e sem contar que muitas vezes não são planejadas para as baixas velocidades que temos aqui no Pais.
Então vem a mesma pergunta. Quando o HTML 5 ganha de um App instalvel?
Assim como no Air vou tentar passar três vantagens do HTML 5 em relação aos aplicativos instalávies.
O primeiro é muito claro, se o seu aplicativo atende vários usuários então acessar o app é mais lógico do que baixar e instalar para só depois usar.
O segundo foca um pouco mais no custo, no momento em que você tem um aplicativo em HTML 5 é só gritar pela janela perguntando se alguém conhece que você provavelmente vai ouvir um "eu sei". A falta de regras, padrões do HTML 5 faz que cada dia mais pessoas usem ele.
O terceiro aspecto de vantagem é que dependendo da forma com que o código seja feito e quais bibliotecasa sejam usadas, o mesmo app mobile poderá funcionar em um navegador desktop tratando apenas algumas questões visuais.
A cerca de mais ou menos um mês a Adobe anunciou descontinuar o plugin do flash para Mobile, o mercado entendeu descontinuar o Flash e muitos falaram "HTML 5 ganhou".
Flash Player Mobile
Em primeiro lugar, vamos pensar o seguinte, esse plugin comia bateria dos poucos celulares que rodavam o plugin e não previa a virada de mesa dos smartphones sem teclado como o iPhone. O mercado mobile para o flash era pequeno por conta disso e ficou ainda menor com o iPhone que aproveitou o conceito de Apps para matar o plugin, com isso os números da Adobe para mobile não foram nada bom.
Não preciso explicar o gráfico, certo? Esses números eu peguei no próprio site da Adobe, e representa a penetração do Flash Player Mobile no mercado e a previsão até 2015. Então com isso a gente pode dizer que foi uma decisão sábia focada na resposta do mercado e não tem absolutamente nada a ver com o HTML 5.
HTML Mobile
Partindo para o HTML, não estou falando do 5, focado em Mobile temo um cenario favoravel a plataforma, nem todos os celulares e smartphones tem flash player, mas todo celular e smartphone tem navegador, que muito provavelmente aceita HTML.
Nesse ponto temos vários celulares com suporte a html e com a tela pequena toda navegação se torna vertical e os desafios de renderizar ficam a cargo dos navegadores que tem como trabalho transformar texto em visual e interpletar um pouco de javascript. No caso dos smartphones existem algumas diferenças por conta de recursos como o acelerômetro, multi touch e geolocalização, o que na maioria dos casos se resolvem por acesso nativo a API do aparelho pelo browser que os desenvolvedores realizam acesso pelo javascript de API's ao meu ver ainda muito pesadas como o JQuery Mobile. O lado bom dessa história para o HTML é que existem pelo menos 18 navegadores que vem instalados nos smartphones e outros a serem instalados, a lista consegui em http://en.wikipedia.org/wiki/Mobile_browser, dando ao usuário final as 2 opções: usar o que tem ou trocar e isso o flash player nunca terá como opção.
Então de forma clara e objetiva, sim o HTML é uma boa opção para mobiles, porém ainda temos outra opção de aplicativos mobile que são aqueles instaláveis, baixados, comprados na Apple Store, Android Market. Nessa hora é onde entra a comparação HTML 5 com o Air Mobile.
Air Mobile
Em primeiro lugar o que é o Air Mobile? Ele não é o Flash Player Mobile descontinuado e sim um ruimtime que possui um SDK que permite criar aplicativos nativos para plataformas específicas.
Pontos positivos para ele começam com o fato de que o desenvolvedor que conhece Flex e ActionScript consegue criar aplicativos instalaveis para iPhone, iPad, iPod, Android e Playbook sem saber nada dessas plataformas, o que para a empresa é abrir um mercado com INVESTIMENTO ZERO no profissional.
Por ser um complilador para multiplos dispositivos alguns recursos ativos e específicos acabam ficando de fora o que dependendo do aplicativo pode ser um problema, mas dependendo do recurso pode-se criar uma extenção nativa ou ANE (ActionScript Native Extenssion) que é um recurso novo no SDK do Flex e até agora nos testes que eu tenho feito resolvem boa parte dos problemas.Uma coisa que achei muito legal no ANE é que ele não se limita a gerar extensões nativas ao mobile, mas também ao desktop, as isso é assunto para outro post.
Um caso legal para o Air Mobile é pensar nas possibilidades geradas em termo de negócio e produtividade, o mesmo App se montado seguindo uma metodologia de skins, bibliotecas, orientação a objetos, pode ser fácilmente distribuido em versão web, desktop e mobile simplesmente mudando a forma de compilação.
Pontos negativos do Air mobile? Bom o principal e não estou puxando para o lado da Adobe é o fato do projeto ter sido doado a Apache Software Foundation, ponto negativo porque a comunudade de desenvolvedores Adobe esta acostumada a reportar problemas e aguardar novo releases e correções, indo para a Apache o Air e o Flex vão ficar nas nossas mãos, se tem um problema vamos resolver e isso não é muito a cara do profissional que esta mais acostumado a reclamar do que colocar a mão na massa e resolver.
Acredito que essa mudança vai exigir alguns anos de adaptação, mas por sorte a Adobe se comprometeu a continuar no projeto até final de 2012 e entregar todos os componnetes em modelo spark, o que me deixa aliviado.
Então quando usar o Air Mobile? Quando ele ganha do HTML 5?
O primeiro ponto para o Air esta no fato dele se tornar um aplicativo nativo, ou seja, você tem um ícone no smartphone com o seu app e não tem que acessar o browser e buscar nos favoritos.
O segundo é o acesso a alguns recursos que dependendo do aplicativo podem fazer diferença, se vocÊ cria um e-commerce pode ter um aviso de entrega, disponibilidade em tempo real com direito a saber se o cara recebeu e abriu a informação, se for uma loja física o app pode rodar em background e apitar que você esta perto da loja
O terceito e na minha opinião o mais importante, você pode restringir e quantificar a utilização do app, se é um ERP não é muito legal garantir acesso a qualquer um e o app instalado é uma forma de garantia uma vez que podemos gerar um token de acesso
HTML 5 Mobile
No HTML 5 mobile temos muitas coisas que o Air mobile faz, a única diferença é que não instalamos o aplicativo, pelo menos era o que eu pensava, mas ao publicar este artigo o amigo Janderson @jandersonfc informou que já tem como se resolver isso através do appcelerator, mas continua o fato dele ser acessado via web. Boa parte do que foi dito sobre o html se aplica ao HTML 5 a diferença fica nas novas tags que fazem coisas que o Flash Player faz a mais de 10 anos.
Pontos positivos? Se não precisa instalar é só acessar e usar o usuário não tem o impacto de fazer download do app para usar, não gasta o espaço em disco do aparelho, só consome a sua internet, se estiver num wifi sem muitos problemas, mas se tiver que depender do 3g é chorar e esperar. Outro problema que se tem no HTML 5 é a questão de padronização. No mercado existem pelo menos 18 navegadores que vem instlados como padrão nos celulares e smartphones e outros montes a serem instlados, a conseguência disso é que cada um nterpleta o código ao seu bel prazer, e o que seria uma coisa simples passa a ser um trabalho de condicionais do tipo "se for navegador X faz assim se for navegador Y faz assado", isso tem se resolvido com as libs de javascript, mas mesmo elas tem esse problema e sem contar que muitas vezes não são planejadas para as baixas velocidades que temos aqui no Pais.
Então vem a mesma pergunta. Quando o HTML 5 ganha de um App instalvel?
Assim como no Air vou tentar passar três vantagens do HTML 5 em relação aos aplicativos instalávies.
O primeiro é muito claro, se o seu aplicativo atende vários usuários então acessar o app é mais lógico do que baixar e instalar para só depois usar.
O segundo foca um pouco mais no custo, no momento em que você tem um aplicativo em HTML 5 é só gritar pela janela perguntando se alguém conhece que você provavelmente vai ouvir um "eu sei". A falta de regras, padrões do HTML 5 faz que cada dia mais pessoas usem ele.
O terceiro aspecto de vantagem é que dependendo da forma com que o código seja feito e quais bibliotecasa sejam usadas, o mesmo app mobile poderá funcionar em um navegador desktop tratando apenas algumas questões visuais.
sexta-feira, 28 de outubro de 2011
Agora é LEI: Provedores tem que garantir pelo menos 20% dos 100% que pagamos a eles
As operadoras de telefonia terão de cumprir regras mais rígidas (finalmente) para
garantir melhor qualidade nos serviços de banda larga fixa e móvel
A Agência Nacional de Telecomunicações (Anatel) aprovou hoje (28/10) índices obrigatórios de velocidade mínima e velocidade média de internet rápida para reduzir o tormento de milhões de consumidores que recebem apenas 10% da velocidade contratada.
Pelas novas regras, as companhias terão de garantir 20% de velocidade mínima (ainda que a gente pague por 100%) e 60% de média no prazo de 12 meses (o que jamais teremos como confirmar), antecipou à Agência Estado o ministro das Comunicações, Paulo Bernardo, antes do anúncio oficial da Anatel. Dentro de 24 meses, esses porcentuais subirão para 30% e 70%, respectivamente. Em 36 meses os índices alcançarão 40% para velocidade mínima e 80% para velocidade média. E ai quando nossos netos tiverem netos, talvez a garantia seja plena.
As velocidades terão de ser cumpridas no período de maior tráfego de dados, que ocorre das 10h às 22h. “Serão usados os mesmos parâmetros para banda larga fixa e móvel. As empresas terão que fazer grandes investimentos”, ressaltou Bernardo. Em outras palavras as empresas terão que pegar parte dos US$ 61.00 por mega e investir, será que eles conseguem? Se a gente levar em conta que outros paises no mundo cobram entre US$ 4.00 e US$ 7.00 por mega e conseguem entregar até 90% do serviço contratado, acho que algumas empresas terão lucro menor na casa de 300000000000000% (o número inicial é meramente representativo, o valor esta nos ZEROS)
Os regulamentos de qualidade da telefonia fixa e da telefonia móvel cumprem determinação da presidente da República, Dilma Rousseff, que fixou em 31 de outubro o prazo para que a Anatel aprovasse as novas regras, que serão aplicadas, inclusive, no Plano Nacional de Banda Larga (PNBL).
Pelas novas regras, as operadoras também terão de cumprir requisitos mínimos de disponibilidade mensal do serviço. No caso da banda larga fixa, a internet terá de estar disponível 99% do período, para a internet móvel, o índice será de 98%. O que será o verdadeiro desafio, já que o mínimo de garantia foi para 20%. apesar que devo confesar que a internet fica lenta na casa de 10Kbps mas não chega a cair.
Além disso, no caso da banda larga móvel, a taxa de queda do acesso deve ser inferior a 5% no mês, o que será muito facil de garantir, afinal ninguém passa 100% do tempo online no celular.
Os regulamentos também trazem outras novidades, relacionadas à publicidade e à transparência do serviço. As empresas terão, por exemplo, a obrigação de tornar disponível em seus sites um software de medição disponível da velocidade da internet. Obviamente devidamente programado para mostrar a velocidade sempre acima dos 20%, porque como alguns bebuns falam na lei seca "não sou obrigado a prodizir prova contra mim mesmo".
As prestadoras e a própria Anatel deverão dar publicidade aos dados coletados em seus portais na internet e as operadoras terão ainda que elaborar uma cartilha informativa com todas as metas de qualidade, que devem ser entregues a todos os assinantes dos serviços. Ou seja espere sentado!!
Por fim, foram fixadas ainda metas relacionadas ao número de reclamações dos consumidores. Conforme os regulamento, o volume de queixas de usuários não poderão ser superiores a 6% da base total de clientes nos 12 primeiros meses de vigência das novas regras. O que na pratica quer dizer: Sabe aquelas 3 até 4 horas que você fica no telefone saltando de atendente em atendente? Pois bem agora eles irão desligar o telefone na sua cara com maior frequencia!
Em 24 meses esse porcentual cairá para 4% e, depois desse período, será de 2%. O que indica que ou você se contenta com o que tem ou gasta uma fortuna em ligações para reclamar
A Agência Nacional de Telecomunicações (Anatel) aprovou hoje (28/10) índices obrigatórios de velocidade mínima e velocidade média de internet rápida para reduzir o tormento de milhões de consumidores que recebem apenas 10% da velocidade contratada.
Pelas novas regras, as companhias terão de garantir 20% de velocidade mínima (ainda que a gente pague por 100%) e 60% de média no prazo de 12 meses (o que jamais teremos como confirmar), antecipou à Agência Estado o ministro das Comunicações, Paulo Bernardo, antes do anúncio oficial da Anatel. Dentro de 24 meses, esses porcentuais subirão para 30% e 70%, respectivamente. Em 36 meses os índices alcançarão 40% para velocidade mínima e 80% para velocidade média. E ai quando nossos netos tiverem netos, talvez a garantia seja plena.
As velocidades terão de ser cumpridas no período de maior tráfego de dados, que ocorre das 10h às 22h. “Serão usados os mesmos parâmetros para banda larga fixa e móvel. As empresas terão que fazer grandes investimentos”, ressaltou Bernardo. Em outras palavras as empresas terão que pegar parte dos US$ 61.00 por mega e investir, será que eles conseguem? Se a gente levar em conta que outros paises no mundo cobram entre US$ 4.00 e US$ 7.00 por mega e conseguem entregar até 90% do serviço contratado, acho que algumas empresas terão lucro menor na casa de 300000000000000% (o número inicial é meramente representativo, o valor esta nos ZEROS)
Os regulamentos de qualidade da telefonia fixa e da telefonia móvel cumprem determinação da presidente da República, Dilma Rousseff, que fixou em 31 de outubro o prazo para que a Anatel aprovasse as novas regras, que serão aplicadas, inclusive, no Plano Nacional de Banda Larga (PNBL).
Pelas novas regras, as operadoras também terão de cumprir requisitos mínimos de disponibilidade mensal do serviço. No caso da banda larga fixa, a internet terá de estar disponível 99% do período, para a internet móvel, o índice será de 98%. O que será o verdadeiro desafio, já que o mínimo de garantia foi para 20%. apesar que devo confesar que a internet fica lenta na casa de 10Kbps mas não chega a cair.
Além disso, no caso da banda larga móvel, a taxa de queda do acesso deve ser inferior a 5% no mês, o que será muito facil de garantir, afinal ninguém passa 100% do tempo online no celular.
Os regulamentos também trazem outras novidades, relacionadas à publicidade e à transparência do serviço. As empresas terão, por exemplo, a obrigação de tornar disponível em seus sites um software de medição disponível da velocidade da internet. Obviamente devidamente programado para mostrar a velocidade sempre acima dos 20%, porque como alguns bebuns falam na lei seca "não sou obrigado a prodizir prova contra mim mesmo".
As prestadoras e a própria Anatel deverão dar publicidade aos dados coletados em seus portais na internet e as operadoras terão ainda que elaborar uma cartilha informativa com todas as metas de qualidade, que devem ser entregues a todos os assinantes dos serviços. Ou seja espere sentado!!
Por fim, foram fixadas ainda metas relacionadas ao número de reclamações dos consumidores. Conforme os regulamento, o volume de queixas de usuários não poderão ser superiores a 6% da base total de clientes nos 12 primeiros meses de vigência das novas regras. O que na pratica quer dizer: Sabe aquelas 3 até 4 horas que você fica no telefone saltando de atendente em atendente? Pois bem agora eles irão desligar o telefone na sua cara com maior frequencia!
Em 24 meses esse porcentual cairá para 4% e, depois desse período, será de 2%. O que indica que ou você se contenta com o que tem ou gasta uma fortuna em ligações para reclamar
sábado, 3 de setembro de 2011
Google anuncia descontinuação da API Flash do Google Maps
Em anuncio no blog, o Google anunciou que sua API para o GoogleMaps estabilizou e nenhuma nova funcionalidade será produzida e que apenas Bugs críticos e falhas de segurança serão corrigidos.
O motivo é a baixa utilização da API e de recursos que a mesma disponibiliza. Outro fator que legou o Google a descontinuar a API é o fato da evolução da API para JavaScript ter crescrido e se tornado viavel, ainda que muitos recursos válidos para a API em Flash só sejam alcançados através de bibliotecas de terceiros.
Para quem quizer consrir o texo na integra, segue o link http://googlegeodevelopers.blogspot.com/2011/09/maps-api-for-flash-deprecation.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+GoogleGeoDevelopersBlog+%28Google+Geo+Developers+Blog%29
O motivo é a baixa utilização da API e de recursos que a mesma disponibiliza. Outro fator que legou o Google a descontinuar a API é o fato da evolução da API para JavaScript ter crescrido e se tornado viavel, ainda que muitos recursos válidos para a API em Flash só sejam alcançados através de bibliotecas de terceiros.
Para quem quizer consrir o texo na integra, segue o link http://googlegeodevelopers.blogspot.com/2011/09/maps-api-for-flash-deprecation.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+GoogleGeoDevelopersBlog+%28Google+Geo+Developers+Blog%29
quarta-feira, 17 de agosto de 2011
Porque não se usa Plataforma WEB para Processamento de Dados
Noite sem sono é bom para escrever e ver o que as pessoas andam falando. Agora a pouco vi uma pessoa na lista de ColdFusion, questionando o porque não se deve usar plataformas web para processamento de dados.
Bom com isso me lembrei dos tempos de segundo grau e faculdade, quando os professores falavam do assundo, e eu me esforçava para não dormir e tentar acompanhar o raciocínio.
Por sorte consegui entender e vou tentar passar o cenário da forma mais clara possível.
Quando se fala em "Processamento de Dados", estamos falando do ato de pegar dados recebidos, seja qual for o meio e processa-los para gerar informação. Com isso você vai pensar "Isso eu faço com ColdFusion, Railo, PHP, ASP, ASP.NET, JSP, etc...", e você esta certo em pensar isso.
Por outro lado, linguagens como as que eu mencionais e outras voltadas a internet possuem um fluxo de processamento próprio, todas elas vão depender de uma especificação em comum, devem estar associadas a um servidor web e serão obrigatóriamente executadas através de um navegador.
Para se processar dados temos como fluxo primário um arquivo de lote ou batch que deverá seguir um padrão que deve ser estabelecido, analisado e testado de forma a não ter necessidade de modificações que afetem versões anteriores e que levem o menor tempo possível para serem processados.
Com os dias de hoje onde tudo gira em torno de tecnologia, esses dois conceitos acabam se perdendo e tendo que ser relembrados a todo momento.
Quando se desenvolve um sistema, seja ele Mobile, Desktop ou Web, temos que realizar algo chamado analise de sistema, é onde se pensa em todo o sistema, como ele vai funcionar, quantos usuários simultaneos teremos, consumo de bande etc. Com a pratica de pastelaria de mercado, essa etapa que pode levar entre um mês até seis meses é simplesmente ignorada, e é iniciado o processo de remendos, onde a cada problema no desenvolvimento, cria-se uma forma de contornar o problema.
Essa prática, normalmente geram projetos de baixo custo e alto risco ao usuário final e aplicamos o antigo ditado popular "o barato, sai caro".
O processamento em lingaguem web não deve ser feito para não existirem erros externos como o servidor web parar, a conexão cair e coisas do tipo, a diferença é simples: O que é melhor? Mudar o canal no controle remoto da sua TV ou todas as vezes levantar do sofá para faze-lo? Ambos levam o mesmo resultado, mas em um dia de muito frio, ou quando se estiver impossibilidado de levantar do sofá por qualquer motivo, você vai pensar "Porque não me preocupei com o controle remoto".
Imagine que os dados a serem processados estão dentro de uma base em um ambiente seu, porque acessar uma página web para recuperar dados dentro do seu servidor? Porque parar o processamento quando a internet cair, se seu acesso todo é local e pior, porque consimir banda para acessar dados locais? É como tirar o carro da garagem para visitar o visinho da esquina.
Uma vez entendido o porque não fazer, vem a pergunta: E o que eu devo usar para processar os dados?
Para as pessoas que trabalham com hospedagem compartilhada e precisam fazer esse processo, a melhor opção é criar uma stored procedure na sua base de dados para realizar o processamento de dados, se seu banco de dados não tem esse suporte só posso dizer "O barato sai caro".
Para pessoas que tem servidores próprios, como VPS, Dedicados, Semi-Dedicados, Clouds etc, a melhor opção é criar um programa para ser instalado no servidor que vai fazer esse processo, afinal o banco de dados, deve apenas, validar e armazenar e não processar dados.
Com relação a linguagens para se fazer isso, as opções são muitas, mas se sua praia é web as melhores opções são: o ActionScript 3 utilizando o Adobe Air (para todas as linguagens), Java (para programadores jsp, java e ColdFusion), C ou C++ (para programadores PHP ou ColdFusion) ou .NET (para programadores .NET ou ColdFusion).
Bom com isso me lembrei dos tempos de segundo grau e faculdade, quando os professores falavam do assundo, e eu me esforçava para não dormir e tentar acompanhar o raciocínio.
Por sorte consegui entender e vou tentar passar o cenário da forma mais clara possível.
Quando se fala em "Processamento de Dados", estamos falando do ato de pegar dados recebidos, seja qual for o meio e processa-los para gerar informação. Com isso você vai pensar "Isso eu faço com ColdFusion, Railo, PHP, ASP, ASP.NET, JSP, etc...", e você esta certo em pensar isso.
Por outro lado, linguagens como as que eu mencionais e outras voltadas a internet possuem um fluxo de processamento próprio, todas elas vão depender de uma especificação em comum, devem estar associadas a um servidor web e serão obrigatóriamente executadas através de um navegador.
Para se processar dados temos como fluxo primário um arquivo de lote ou batch que deverá seguir um padrão que deve ser estabelecido, analisado e testado de forma a não ter necessidade de modificações que afetem versões anteriores e que levem o menor tempo possível para serem processados.
Com os dias de hoje onde tudo gira em torno de tecnologia, esses dois conceitos acabam se perdendo e tendo que ser relembrados a todo momento.
Quando se desenvolve um sistema, seja ele Mobile, Desktop ou Web, temos que realizar algo chamado analise de sistema, é onde se pensa em todo o sistema, como ele vai funcionar, quantos usuários simultaneos teremos, consumo de bande etc. Com a pratica de pastelaria de mercado, essa etapa que pode levar entre um mês até seis meses é simplesmente ignorada, e é iniciado o processo de remendos, onde a cada problema no desenvolvimento, cria-se uma forma de contornar o problema.
Essa prática, normalmente geram projetos de baixo custo e alto risco ao usuário final e aplicamos o antigo ditado popular "o barato, sai caro".
O processamento em lingaguem web não deve ser feito para não existirem erros externos como o servidor web parar, a conexão cair e coisas do tipo, a diferença é simples: O que é melhor? Mudar o canal no controle remoto da sua TV ou todas as vezes levantar do sofá para faze-lo? Ambos levam o mesmo resultado, mas em um dia de muito frio, ou quando se estiver impossibilidado de levantar do sofá por qualquer motivo, você vai pensar "Porque não me preocupei com o controle remoto".
Imagine que os dados a serem processados estão dentro de uma base em um ambiente seu, porque acessar uma página web para recuperar dados dentro do seu servidor? Porque parar o processamento quando a internet cair, se seu acesso todo é local e pior, porque consimir banda para acessar dados locais? É como tirar o carro da garagem para visitar o visinho da esquina.
Uma vez entendido o porque não fazer, vem a pergunta: E o que eu devo usar para processar os dados?
Para as pessoas que trabalham com hospedagem compartilhada e precisam fazer esse processo, a melhor opção é criar uma stored procedure na sua base de dados para realizar o processamento de dados, se seu banco de dados não tem esse suporte só posso dizer "O barato sai caro".
Para pessoas que tem servidores próprios, como VPS, Dedicados, Semi-Dedicados, Clouds etc, a melhor opção é criar um programa para ser instalado no servidor que vai fazer esse processo, afinal o banco de dados, deve apenas, validar e armazenar e não processar dados.
Com relação a linguagens para se fazer isso, as opções são muitas, mas se sua praia é web as melhores opções são: o ActionScript 3 utilizando o Adobe Air (para todas as linguagens), Java (para programadores jsp, java e ColdFusion), C ou C++ (para programadores PHP ou ColdFusion) ou .NET (para programadores .NET ou ColdFusion).
sexta-feira, 3 de junho de 2011
Carrinho de Compras - Parte 2.1 (Integração com PagSeguro do UOL - Retorno Automático)
Como eu tinha prometido vamos continuar com a série "Carrinho de Compras", quem não viu o primeiro post Carrinho de Compras - Parte 1 e Parte 2 recomendo dar uma olhada apenas para ter uma idéiade como nosso carrinho funciona e em que ponto estamos.
Ontem finalizamos o envio de dados para o PagSeguro do UOL e hoje (que rufem os tambores), vamos falar do Retorno Automático do PagSeguro.
Para isso, precisamos primeiro saber como ele funciona e definir nossa URL DE RETORNO e o TOKEN. Esse procedimento, tenta evitar dores de cabeça de pessoas comprando sem estar na sua loja. Como vimos ontem, o pagseguro, só pede um form com submit sem nenhum tipo de validação.
A validação acontece, quando o PagSeguro gera a "pergunta", que no caso chamamos de Retorno Automático. Uma observação, nesse caso seus testes devem ser online, pois vamos usar a session da sua aplicação para verificar e validar dos dados a serem confirmados com a URL de Retorno.
Para este processo vamos criar um novo componente e vamos chama-lo de PagSeguroRetorno.cfc. Este compoennte será usado na nossa página de retorno, e irá disparar ações de confirmação dos dados da compra.
PagSeguroRetorno.cfc
Iniciamos o processo com nossas váriaveis que serão manipuladas pelo componente.
setReturn
Criamos um método setReturn, que será responsável por receber o retorno do PagSeguro e manipular este resultado de acordo com nossa necessidade. Nesse momento, apenas nos preocupamos com guardar a informação. Para evitar um monte de linhas, realizamos um loop sobre a estrutura de dados recebida, guardando os dados na estrutura result.
confirm
Finalmente, de posse dos dados, realizamos a confirmação. Para isso, enviamos um post com o comando Validar e nosso Token, junto com os dados da compra.
Lembrando que aqui estamos tratando de um exemplo, no mundo real, antes de informar a validação, verificamos o id da nossa transação no e-commerce e se o carrinho é igual ao que temos no site, para só então verificarmos se os dados conferem com a informação do PagSeguro, guardando as informações adicionais.
retornoPagSeguro.cfm
Este código, deve ir na sua página de retorno, a mesma que você informou para o PagSeguro. Nesse momento, verificamos se recebemos algum retorno de POST e em seguida, iniciamos nosso componente PagSeguroRetorno.cfc informando o retorno que recebemos e confirmando a transação.
Bom é isso, espero ter ajudado alguém com este tutorial e agora só volto na próxima quarta-feira, falando da integração com Pagamento Digital do Buscapé.
E finalmente, para quem cansou de ler, esta tudo pronto para download no link http://www.flagnet.inf.br/downloads/shoppingCart-part2.1.rar
Ontem finalizamos o envio de dados para o PagSeguro do UOL e hoje (que rufem os tambores), vamos falar do Retorno Automático do PagSeguro.
Para isso, precisamos primeiro saber como ele funciona e definir nossa URL DE RETORNO e o TOKEN. Esse procedimento, tenta evitar dores de cabeça de pessoas comprando sem estar na sua loja. Como vimos ontem, o pagseguro, só pede um form com submit sem nenhum tipo de validação.
A validação acontece, quando o PagSeguro gera a "pergunta", que no caso chamamos de Retorno Automático. Uma observação, nesse caso seus testes devem ser online, pois vamos usar a session da sua aplicação para verificar e validar dos dados a serem confirmados com a URL de Retorno.
Para este processo vamos criar um novo componente e vamos chama-lo de PagSeguroRetorno.cfc. Este compoennte será usado na nossa página de retorno, e irá disparar ações de confirmação dos dados da compra.
PagSeguroRetorno.cfc
1: <cfset Variable.COMMAND = "validar">
2: <cfset Variables.VALIDATOR_URL = "https://pagseguro.uol.com.br/pagseguro-ws/checkout/NPI.jhtml">
3: <cfset Variables.TOKEN = "SEU_TOKEN" />
4: <cfset Variables.dsEmail = "EMAIL_CADASTRADO_PAGSEGURO" />
5: <cfset Variables.result = structNew()>
setReturn
1: <cffunction name="setReturn" access="public" returntype="void" output="false">
2: <cfargument name="data" type="struct" required="true">
3: <cfset var arrForm = listToArray(arguments.data.FieldNames)>
4: <cfloop array="#arrForm#" index="currentItem">
5: <cfset Variables.result["#currentItem#"] = arguments.data[currentItem]>
6: </cfloop>
7: </cffunction>
confirm
1: <cffunction name="confirm" access="public" returntype="void" output="false">
2: <cfhttp url="#VALIDATOR_URL#" method="get" resolveurl="false" charset="iso-8859-1">
3: <cfhttpparam name="Comando" type="url" value="#Variables.COMMAND#">
4: <cfhttpparam name="Token" type="url" value="#Variables.TOKEN#">
5:
6: <cfloop collection="variables.result" item="currentItem">
7: <cfhttpparam name="#currentItem#" type="url" value="#variables.result[currentItem]#">
8: </cfloop>
9: </cfhttp>
10: <cfswitch expression="#trim(cfhttp.FileContent)#">
11: <cfcase value="VERIFICADO">
12: <!--- Verifique se a TransacaoID não foi previamente processada --->
13: <!--- Verifique se o email recebido (VendedorEmail) é o seu email --->
14: <!--- Verifique se o valor do pagamento está correto --->
15: <!--- Processe o pagamento salvando os dados em seu banco de dados --->
16: <cfset FileWrite("#getDirectoryFromPath(expandPath('*.*'))#FORM_TRUE#DateFormat(Now(), 'yyyy-mm-dd-hh-mm-ss')#.htm", value)>
17: </cfcase>
18: <cfcase value="FALSO">
19: <!--- A Requisição não foi confirmada pelo PagSeguro e pode ser uma compra falsa --->
20: <cfset FileWrite("#getDirectoryFromPath(expandPath('*.*'))#FORM_FALSE#DateFormat(Now(), 'yyyy-mm-dd-hh-mm-ss')#.htm", value)>
21: </cfcase>
22: </cfswitch>
23: </cffunction>
Lembrando que aqui estamos tratando de um exemplo, no mundo real, antes de informar a validação, verificamos o id da nossa transação no e-commerce e se o carrinho é igual ao que temos no site, para só então verificarmos se os dados conferem com a informação do PagSeguro, guardando as informações adicionais.
retornoPagSeguro.cfm
1: <cfif structKeyExists(Form, "FieldNames")>
2: <cfset objPagSeguroReturn = createObject("component", "PagSeguroRetorno")>
3: <cfset objPagSeguroReturn.setReturn(form)>
4: <cfset objPagSeguroReturn.confirm()>
5: </cfif>
Bom é isso, espero ter ajudado alguém com este tutorial e agora só volto na próxima quarta-feira, falando da integração com Pagamento Digital do Buscapé.
E finalmente, para quem cansou de ler, esta tudo pronto para download no link http://www.flagnet.inf.br/downloads/shoppingCart-part2.1.rar
quinta-feira, 2 de junho de 2011
Carrinho de Compras - Parte 2 (Integração com PagSeguro do UOL)
Como eu tinha prometido vamos continuar com a série "Carrinho de Compras", quem não viu o primeiro post Carrinho de Compras - Parte 1, recomendo dar uma olhada apenas para ter uma idéiade como nosso carrinho funciona.
Hoje a idéia é falar da integração com o PagSeguro do UOL através do nosso ColdFusion. O primeiro desafio é documentação em ColdFusion, que por ser uma linguagem extremamente fácil e produtiva, as pessoas acabam esquecendo de criar documentação, meu objetivo é mudar isso radicalmente.
Para a integração, vamos precisar de dois manuais no site do PagSeguro. O primeiro é o da integração com Carrinho Próprio e o segundo que é o Retorno Automático de Dados
Apenas lembrando que a mágica depende da configuração correta na sua conta PagSeguro, se você ainda não o fez ou quer revizar vamos aos passos:
Para este post vamos fazer o modelo de enviarmos todos os dados, até porque você provavelmente nesse ponto, já esta com o usuário logado no seu e-commerce e cadastrado. Lembre-se, esse é o momento de finalização da compra, então você já deve verificar seu estoque e estar com tudo pronto.
Para facilitar nossa vida, vamos criar um novo componente chamado PagSeguro.cfc, que espero que ajude na integração da maioria dos projetos. Os métodos que percebi são:
Ao iniciar nosso processo, criamos algumas váriaveis que serão controladas pelos nossos métodos antes do envio. Algumas delas, já definimos um valor padrão, para evitar falhas ou necessidades de formas de uso na programação.
É importante lembrar que um componente deve ser simples a ponto de não termos que "adaptar" nossa programação ao funcionamento dele.
setCart
Algumas observações e curiosidades para o nosso setCart. De cara algo diferente no atributo type da nossa cfargument. O tipo requerido para o nosso carrinho se chama ShoppingCart, que é o mesmo componente CFC que criamos no post anterior, isso nos facilita um pouco a vida, pois estamos manipulando algo que esta de acordo com nossa especificação inicial.
Muitos podem achar que o post sai do nada, porém antes de começar essa maratona, desenhei todo o fluxo UML para o nosso projeto. O único motivo dos arquivos estarem todos juntos é para facilitar o entendimento e ajudar vocês a executarem o projeto em seu próprio servidor local.
Na verificação do login, repare que não faço uso de isDefined ou structKeyExist, isso, porque defini o cfargument com a propriedade default="", que faz o nosso cfargument funcionar como um cfparam, cria a variável que você pediu com um valor padrão, caso ela não exista. Com isso, verificamos se a quantidade de caracteres é superior a zero e se o valor que temos em mãos é um e-mail.
A técnica do len(trim("STRING")) é baseada numa regra da lógica boleana que diz "Todo número diferente de zero verdadeiro". Cuidado com as entrelinhas, 1 e -1 são verdadeiro apenas 0 é falso.
A função isValid do ColdFusion é uma das mais legais e menos conhecidas, vale a pena dar uma olhada na documentação, para as possibilidades!
setType
Esse método, é apenas para dar opção para quem não desejar usar o Carrinho Proprio, e não afeta em nada nosso envio.
setCoin
Este é mais um para a lista de não temos muito o que fazer, mas vai que o UOL resolver colocar pagSeguro recebendo em outras moedas, esperança é a última que morre.
setExtras
Esse método é para evitar problemas entre acressimos e descontos. Na documentação do PagSeguro para o campo extras eles falam "Utilize este campo para acrescentar ao pedido um valor adicional, caso necessário. Exemplo: você pode incluir o valor da embalagem de presente. Você também pode enviar um valor negativo neste campo, caso deseje oferecer um desconto ao seu cliente.".
Pensando nisso, o método recebe o valor e um boleano informando se é desconto ou não. Isso evita que você tenha que fazer a conversão de desconto
setClient
Esse método, pode ser melhorado, e seguir o padrão de componentes, para endereço, pessoa e telefone, além de validar algumas informações como e-mail, mas nesse caso, ele só irá servir para guardar as informações que serão enviadas ao PagSeguro.
setShipping
Mais um da série, não tenho nada a dizer. A única observação é o tipo "UC" que estamos criando especialmente para o nosso PagSeguro.cfc. Se o nosso tipo de envio for "UC", não informaremos o tipo, fazendo com que o PagSeguro pergunte ao usuário, como ele deseja receber.
parseCurrency
Esse método privado pega o valor e coloca em conformidade com a especificação do PagSeguro "Valor ... sem vírgulas ou pontos. Para um produto que custa R$ 1,00 você deverá informar 100 (somente números)."
send
Por último e talvez mais importante, a nossa "fronteira final" que é o envio dos dados para após a operação termos o nosso retorno automático.
Muitos podem pensar de cara em usar o cfhttp para envio dos dados, mas no caso do pagSeguro, o objetivo é ser uma ferramenta simples a ponto do usuário que só sabe html, também possa usar. Para o mundo ColdFusion o CFHTTP soa até natural, porém em linguens como .NET, PHP e Java a coisa não é tão simples.
Por conta disso, o envio é feito por um formulário simples o que gera algumas dores de cabeça com pessoas fazendo compras sem passar pelo seu site. A solução proposta pelo pagseguro é a utilização do token, que eu recomendo trocar pelo menos uma vez por mês ou ao dia dependendo do volume da acessos do seu e-commerce. Depois se vocês desejarem, podemos fazer uma ferramenta com essa finalidade.
A programação do método send é algo que se pode chamar de realmente simples. Ele vai gerar o nosso formulário, que nesse caso estou chamando de "frmPagSeguro", e executando o submit dele via javaScript. Isso esta sendo feito, para evitar o exemplo onde um simples "exibir código fonte" pode colocar toda a transação a perder.
Com isso estamos integrados ao PagSeguro, a página pagSeguro.cfm mostra, como o envio fica realmente simples.
pagSeguro.cfm
Agora vem a pergunta: "E o retorno automático?". Bom esse mistério será desvendado no post de amanhã.
E finalmente, para quem cansou de ler, esta tudo pronto para download no link http://www.flagnet.inf.br/downloads/shoppingCart-part2.rar
Hoje a idéia é falar da integração com o PagSeguro do UOL através do nosso ColdFusion. O primeiro desafio é documentação em ColdFusion, que por ser uma linguagem extremamente fácil e produtiva, as pessoas acabam esquecendo de criar documentação, meu objetivo é mudar isso radicalmente.
Para a integração, vamos precisar de dois manuais no site do PagSeguro. O primeiro é o da integração com Carrinho Próprio e o segundo que é o Retorno Automático de Dados
Apenas lembrando que a mágica depende da configuração correta na sua conta PagSeguro, se você ainda não o fez ou quer revizar vamos aos passos:
- Criar uma conta no PagSeguro
- Se for usar a conta em produção, é bom validar os dados.
- Lembre-se de configurar o Frete, no menu Preferências/Frete
- Defina o link para o Retorno Automático de Dados, e gere o Token no menu Preferências/Retorno automático de dados
Para este post vamos fazer o modelo de enviarmos todos os dados, até porque você provavelmente nesse ponto, já esta com o usuário logado no seu e-commerce e cadastrado. Lembre-se, esse é o momento de finalização da compra, então você já deve verificar seu estoque e estar com tudo pronto.
Para facilitar nossa vida, vamos criar um novo componente chamado PagSeguro.cfc, que espero que ajude na integração da maioria dos projetos. Os métodos que percebi são:
- setCart: vai ser o método responsável por receber os dados a serem enviados ao PagSeguro;
- setType: para informar o tipo do carrinho, seja próprio, ou PagSeguro
- setCoin: serve para informar o tipo de moeda, hoje o pagSeguro só trabalha com Real
- setExtras: será utilizado para valores adicionais ou descontos
- setClient: irá servir para informar os dados do fulano que esta fazendo a compra
- setShipping: informaremos o tipo de envio do produto
- parseCurrency: esse método irá converter o valor para o padrão PagSeguro
- send: esse método irá realizar a mágica de enviar os dados para o PagSeguro
1: <cfset Variables.ACTION = "https://pagseguro.uol.com.br/checkout/checkout.jhtml" />
2: <cfset Variables.dsEmail = "EMAIL_CADASTRADO_PAGSEGURO" />
3: <cfset Variables.tpCart = "CP" />
4: <cfset Variables.tpCoin = "BRL" />
5: <cfset Variables.tpShipping = "UC" />
6: <cfset Variables.vlExtras = 0 />
7: <cfset Variables.userData = structNew()>
8: <cfset variables.cart = ArrayNew(1) />
É importante lembrar que um componente deve ser simples a ponto de não termos que "adaptar" nossa programação ao funcionamento dele.
setCart
1: <cffunction name="setCart" access="public" returntype="void" output="false">
2: <cfargument name="cart" type="ShoppingCart" required="true">
3: <cfargument name="nmLogin" type="String" default="" required="false">
4: 5: <cfif len(trim(arguments.nmLogin)) and isValid("email", arguments.nmLogin)>
6: <cfset Variables.dsEmail = arguments.nmLogin />
7: </cfif>
8: <cfset variables.cart = Arguments.cart.list()>
9: </cffunction>
Muitos podem achar que o post sai do nada, porém antes de começar essa maratona, desenhei todo o fluxo UML para o nosso projeto. O único motivo dos arquivos estarem todos juntos é para facilitar o entendimento e ajudar vocês a executarem o projeto em seu próprio servidor local.
Na verificação do login, repare que não faço uso de isDefined ou structKeyExist, isso, porque defini o cfargument com a propriedade default="", que faz o nosso cfargument funcionar como um cfparam, cria a variável que você pediu com um valor padrão, caso ela não exista. Com isso, verificamos se a quantidade de caracteres é superior a zero e se o valor que temos em mãos é um e-mail.
A técnica do len(trim("STRING")) é baseada numa regra da lógica boleana que diz "Todo número diferente de zero verdadeiro". Cuidado com as entrelinhas, 1 e -1 são verdadeiro apenas 0 é falso.
A função isValid do ColdFusion é uma das mais legais e menos conhecidas, vale a pena dar uma olhada na documentação, para as possibilidades!
setType
1: <cffunction name="setType" access="public" returntype="void" output="false">
2: <cfargument name="type" type="string" required="true">
3: <cfset var lValidTypes = "CP,CBR">
4: <cfif listContainsNoCase(lValidTypes, arguments.type)>
5: <cfset Variables.tpCart = arguments.type>
6: <cfelse>
7: <cfset Variables.tpCart = listFirst(lValidTypes)>
8: </cfif>
9: </cffunction>
setCoin
1: <cffunction name="setCoin" access="public" returntype="void" output="false">
2: <cfargument name="coin" type="string" required="true">
3: <cfset var lValidTypes = "BRL">
4: <cfif listContainsNoCase(lValidTypes, arguments.coin)>
5: <cfset Variables.tpCoin = arguments.type>
6: <cfelse>
7: <cfset Variables.tpCoin = listFirst(lValidTypes)>
8: </cfif>
9: </cffunction>
setExtras
1: <cffunction name="setExtras" access="public" returntype="void" output="false">
2: <cfargument name="value" type="numeric" required="true">
3: <cfargument name="isDiscount" type="boolean" default="false" required="false">
4: 5: <cfif arguments.isDiscount>
6: <cfset Variables.vlExtras = arguments.value * -1>
7: <cfelse>
8: <cfset Variables.vlExtras = arguments.value>
9: </cfif>
10: </cffunction>
Pensando nisso, o método recebe o valor e um boleano informando se é desconto ou não. Isso evita que você tenha que fazer a conversão de desconto
setClient
1: <cffunction name="setClient" access="public" returntype="void" output="false">
2: <cfargument name="nmPerson" type="string" required="true">
3: <cfargument name="dsEmail" type="string" required="true">
4: <cfargument name="nbPostalCode" type="string" required="true">
5: <cfargument name="dsAddress" type="string" required="true">
6: <cfargument name="dsDistrict" type="string" required="true">
7: <cfargument name="dsCity" type="string" required="true">
8: <cfargument name="cdState" type="string" required="true">
9: <cfargument name="cdDDD" type="numeric" required="true">
10: <cfargument name="nbTelephone" type="string" required="true">
11: <cfargument name="nbAddress" type="string" required="false" default="S/N">
12: <cfargument name="dsComplement" type="string" required="false" default="">
13: <cfargument name="cdCountry" type="string" required="false" default="BRA">
14: 15: <cfset Variables.userData.nmPerson = arguments.nmPerson>
16: <cfset Variables.userData.dsEmail = arguments.dsEmail>
17: <cfset Variables.userData.nbPostalCode = arguments.nbPostalCode>
18: <cfset Variables.userData.dsAddress = arguments.dsAddress>
19: <cfset Variables.userData.dsDistrict = arguments.dsDistrict>
20: <cfset Variables.userData.dsCity = arguments.dsCity>
21: <cfset Variables.userData.cdState = arguments.cdState>
22: <cfset Variables.userData.cdDDD = arguments.cdDDD>
23: <cfset Variables.userData.nbTelephone = arguments.nbTelephone>
24: <cfset Variables.userData.nbAddress = arguments.nbAddress>
25: <cfset Variables.userData.dsComplement = arguments.dsComplement>
26: <cfset Variables.userData.cdCountry = arguments.cdCountry>
27: </cffunction>
setShipping
1: <cffunction name="setShipping" access="public" returntype="void" output="false">
2: <cfargument name="shipping" type="string" required="true">
3: <cfset var lValidTypes = "UC,EN,SD">
4: <cfif listContainsNoCase(lValidTypes, arguments.shipping)>
5: <cfset Variables.tpShipping = arguments.type>
6: <cfelse>
7: <cfset Variables.tpShipping = listFirst(lValidTypes)>
8: </cfif>
9: </cffunction>
parseCurrency
1: <cffunction name="parseCurrency" access="private" returntype="String" output="false">
2: <cfargument name="value" type="numeric" required="yes">
3: 4: <cfset var strResult = LSCurrencyFormat(Arguments.value, "none")>
5: <cfset strResult = trim(REReplace(strResult, "[^[:digit:]]", "", "ALL"))/>
6: <cfreturn strResult>
7: </cffunction>
send
Por último e talvez mais importante, a nossa "fronteira final" que é o envio dos dados para após a operação termos o nosso retorno automático.
Muitos podem pensar de cara em usar o cfhttp para envio dos dados, mas no caso do pagSeguro, o objetivo é ser uma ferramenta simples a ponto do usuário que só sabe html, também possa usar. Para o mundo ColdFusion o CFHTTP soa até natural, porém em linguens como .NET, PHP e Java a coisa não é tão simples.
Por conta disso, o envio é feito por um formulário simples o que gera algumas dores de cabeça com pessoas fazendo compras sem passar pelo seu site. A solução proposta pelo pagseguro é a utilização do token, que eu recomendo trocar pelo menos uma vez por mês ou ao dia dependendo do volume da acessos do seu e-commerce. Depois se vocês desejarem, podemos fazer uma ferramenta com essa finalidade.
1: <cffunction name="send" access="public" returntype="string" output="no">
2: <cfargument name="idTransaction" type="string" required="false" default="">
3: <cfsavecontent variable="returnVal">
4: <cfoutput>
5: <form id="frmPagSeguro" action="#Variables.action#" method="post">
6: <input type="hidden" name="encoding" value="#Variables.ENCODING#">
7: <input type="hidden" name="email_cobranca" value="#Variables.dsEmail#">
8: <input type="hidden" name="tipo" value="#Variables.tpCart#">
9: <input type="hidden" name="moeda" value="#Variables.tpCoin#">
10: 11: <cfif len(trim(arguments.idTransaction))><input type="hidden" name="ref_transacao" value="#arguments.idTransaction#"></cfif>
12: <cfif Variables.tpShipping NEQ "UC"><input type="hidden" name="tipo_frete" value="#Variables.tpShipping#"></cfif>
13: <cfif Variables.vlExtras NEQ 0><input type="hidden" name="extras" value="#parseCurrency(Variables.vlExtras)#"></cfif>
14: 15: <cfloop from="1" to="#ArrayLen(variables.cart)#" index="i">
16: <input type="hidden" name="item_id_#i#" value="#variables.cart[i].idItem#">
17: <input type="hidden" name="item_descr_#i#" value="#variables.cart[i].nmItem#">
18: <input type="hidden" name="item_quant_#i#" value="#variables.cart[i].qtItem#">
19: <input type="hidden" name="item_valor_#i#" value="#parseCurrency(variables.cart[i].vlItem)#">
20: <cfif variables.cart[i].flFreeShipping>
21: <input type="hidden" name="item_frete_#i#" value="0">
22: <input type="hidden" name="item_peso_#i#" value="0">
23: <cfelse>
24: <input type="hidden" name="item_peso_#i#" value="#variables.cart[i].nbWeight#">
25: </cfif>
26: </cfloop>
27: <cfif NOT structIsEmpty(Variables.userData)>
28: <input type="hidden" name="cliente_nome" value="#Variables.userData.nmPerson#">
29: <input type="hidden" name="cliente_email" value="#Variables.userData.dsEmail#">
30: <input type="hidden" name="cliente_cep" value="#Variables.userData.nbPostalCode#">
31: <input type="hidden" name="cliente_end" value="#Variables.userData.dsAddress#">
32: <input type="hidden" name="cliente_num" value="#Variables.userData.nbAddress#">
33: <input type="hidden" name="cliente_compl" value="#Variables.userData.dsComplement#">
34: <input type="hidden" name="cliente_bairro" value="#Variables.userData.dsDistrict#">
35: <input type="hidden" name="cliente_cidade" value="#Variables.userData.dsCity#">
36: <input type="hidden" name="cliente_uf" value="#Variables.userData.cdState#">
37: <input type="hidden" name="cliente_pais" value="#Variables.userData.cdCountry#">
38: <input type="hidden" name="cliente_ddd" value="#Variables.userData.cdDDD#">
39: <input type="hidden" name="cliente_tel" value="#Variables.userData.nbTelephone#">
40: </cfif>
41: </form>
42: </cfoutput>
43: <script type="text/javascript">1:2: var objForm = document.getElementById("frmPagSeguro");3: objForm.submit();4:</script>
44: </cfsavecontent>
45: <cfreturn returnVal>
46: </cffunction>
Com isso estamos integrados ao PagSeguro, a página pagSeguro.cfm mostra, como o envio fica realmente simples.
pagSeguro.cfm
1: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
2: <html xmlns="http://www.w3.org/1999/xhtml">
3: <head><meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
4: <title>Confirmação de Compra</title>
5: </head>
6: <body>
7: <cfsetting showdebugoutput="false">
8: <cfset aCart = session.shoppingCart.list()>
9: <table border="1">
10: <thead>
11: <tr>
12: <th>Cód</th>
13: <th>Nome</th>
14: <th>Valor</th>
15: <th>Quantidade</th>
16: <th>Sub-Total</th>
17: </tr>
18: </thead>
19: <tfoot>
20: <tr>
21: <td colspan="5"><strong>Valor Total:</strong><cfoutput>#lsCurrencyFormat(session.shoppingCart.getTotal())#</cfoutput></td>
22: </tr>
23: </tfoot>
24: <cfoutput>
25: <tbody>
26: <cfloop array="#aCart#" index="cartItem">
27: <tr>
28: <td>#cartItem.cdItem#</td>
29: <td>#cartItem.nmItem#</td>
30: <td>#lsCurrencyFormat(cartItem.vlItem)#</td>
31: <td>#cartItem.qtItem#</td>
32: <td>#lsCurrencyFormat(cartItem.vlTotalItem)#</td>
33: </tr>
34: </cfloop>
35: </tbody>
36: </cfoutput>
37: </table>
38: <form method="post">
39: <input type="submit" name="go" value="Confirmar Compra"/>
40: </form>
41: <cfif structKeyExists(form, "go")>
42: <cfset objPagSeguro = createObject("component", "PagSeguro")>
43: <cfset objPagSeguro.setCart(session.shoppingCart)>
44: <cfset objPagSeguro.setClient("Rafael Bandeira Rodrigues"
45: , "rafael_rodrigues@flagnet.inf.br"
46: , "00000000"
47: , "R. Onde eu moro"
48: , "Bairro"
49: , "Rio de Janeiro"
50: , "RJ"
51: , "21"
52: , "3333-3333")>
53: <cfoutput>#objPagSeguro.send()#</cfoutput>
54: </cfif>
55: 56: </body>
57: </html>
E finalmente, para quem cansou de ler, esta tudo pronto para download no link http://www.flagnet.inf.br/downloads/shoppingCart-part2.rar
Assinar:
Postagens (Atom)

