Server-side/ Web 2.0

REST é a melhor escolha para seus próximos projetos de mobile/desktop/api

rest_sample

É difícil de acreditar que a transferência simples de objetos entre chamadas ficou bem popular nos dias de hoje. Lá em meados de 2007 quando eu estava tão focado em RTMP, eu mal pude enxergar que isso poderia se tornar a soma de todas as soluções do lado do servidor.

À exemplo disso, tiramos o fato que transferência do objeto está associado a cabeçalho da mensagem, corpo da mensagem, o paradigma do REST é desacoplar essas dependências e atingir o máximo de clientes possíveis, já que se trata de uma chamada simples com um retorno simples.

Por exemplo, qual a relação do REST com o SOAP, bastante utilizado na plataforma ASP.Net, como mencionei acima, REST tem um cabeçalho simples de mensagem específica, sendo apenas uma requisição HTTP que você faz e que o cabeçalho não é nada mais que o código processado da requisição para o servidor, avisando que a requisição chegou ou falhou, etc.

Já no padrão SOAP, defini-se o cabeçalho com padrões semânticos e sintaxes XML, como é o caso das especificações 1.0, 1.1 e a tangível 1.2 que em alguns casos clientes que requisitam esse padrão não tem suporte.

Como todos estão acostumados à verem apenas os pros da coisa, eu vou pelo lado contrário definindo pelas falhas em cada lado da moeda. Os pros, vocês dão uma Googlada para achar.

As falhas de comparação do SOAP é basicamente:

  • Tradução do serviço em um formato de mensagem específica em XML
  • Cliente precisa ter suporte as especificas DTD.
  • Padrão XML definido por namespace
  • Desenvolvedor acaba tendo que remover os namespaces quando vai fazer o parse ou envio.
  • Tipação das entidades é feita pelos namespaces.
  • Todo erro é do tipo 500 ( dificil de advinhar sem fazer uma interface própria)

Já no lado REST

  • Não possui especificação, A pode ser A desde que seja definido de primeira instancia, ou acabará como Z.
  • Segurança fraca, já que não requer uma tipação na requisição. Só que tudo depende de quem implementa, oAuth por exemplo é um excelente meio de segurança aplicada.
  • Tipação de objetos é inexistente
  • Liberdade de output em JSON,text, XML ou seu próprio tipo.

Esses tipos de comparação entre SOAP e REST é o mesmo que comparar carro e avião ou maçã e banana, dificil de imaginar que ambos competem entre sí, mas ambos possuem ambas particularidades que atendem a específicos requisitos, que se julgam necessário pela mão do desenvolvedor.

Porém, você pode discordar dessas comparações, e eu posso até concordar em seus argumentos, já que o que define um serviço REST é se ele possue cache, se possui autenticação se possui uma URI simplificada e o mais importante, qualquer cliente pode consumí-lo.

Salve guardo essas diferenças simples, porém importantíssimas para a definição do serviço, REST caiu no gosto popular do desenvolvedor moderno, já que o serviço é apenas o produto do meio para o produto final.

Quando gigantes do software como Google, Yahoo, Amazon, Facebook, Microsoft, adotam esse padrão de consumo de informações, milhões e milhões de start-ups pelo mundo também copiam a idéia e implementam, afinal produtividade e RAD nunca saiu de moda nesses últimos 10 anos.

 

Enterprise e APIs

É fato comprovado que Enterprise é mais lenta que o ritmo da internet, só que o provérbio não deixa por ressaltar “Antes tarde do que nunca“. Mais de 8 mil APIs tem sido criada para o mundo start-up, ao invés de grandes empresas darem apenas o SDK para outros desenvolvedores consumir seus serviços ou sua plataforma, eles também tem visto que a API é fundamental para a ploriferação de seus produtos.

API, não significa apenas REST API, existem vários tipos de API, tanto incorporadas dentro do próprio SDK como é o caso das DLLs, COMs, só que hoje em um ambiente mais aberto, com várias opções de clientes, o mais sensato é construir serviços e disponibilizados da maneira mais abrangente possível.
Plataformas que criam serviços REST

Tomando como base que tecnologia é apenas o produto do meio, hoje todas as linguagens de programação que tenham implementado o protocolo HTTP 1.1, podem criar serviços REST na internet, desde o C até o Javascript(nodejs), podem criar serviços REST para serem consumidos por outras linguagens clientes.

A internet em sí é um estado de transferência representacional ( REST na sigla em inglês), que transfere recursos por URI simples, quando você requisitou o link desse site, você fez uma chamada REST por meio de uma URI simples, acaba que você está usando um REST por trás dessa requisição, é muito mais simples do que você imagina.

E qual o objetivo do REST?

Tornar as coisas simples, cache de objetos se necessário, desacopláveis, simplicidade de requisição, definir que um erro 404 é um erro 404 ou que um erro 403 seja um erro 403 e o mais importante, multi pluralidade dos recursos que estão sendo manipulados através de comandos básicos a serem executados pela requisição.

Se você leu até aqui, parabéns, viu que as idéias jogadas no inicio do post, tendem a ser mais relevantes para você nesse ponto do artigo, já que você tem a certa noção que uma API em REST é certeza que será utilizável por diferentes plataformas da maneira mais internetizada possível.

4 Métodos mágicos

GET/POST você já fez alguma vez na sua vida de desenvolvedor web, até mesmo um webdesigner já deve ter feito um formulário de contato. REST trabalha com mais dois tipos de requisições além desses, por que afinal ele transforma recursos (objetos) em URI simples e uma maneira frágil e certa, simplificar através de métodos as requisições economiza na hora de criar rotas para as URL.

  • GET – Ler/Retorna uma lista de recursos(objetos) para o lado cliente
  • POST – Cria um novo recurso(objeto) na lista já existente
  • PUT – Atualiza/Sobrescreve um objeto da coleção, caso não exista o objeto, ele assume o papel do POST criando-o.
  • DELETE – Remove/Apaga o objeto da coleção que você possui.

Qualquer cliente pode conectar

Se você tem um serviço que qualquer linguagem de cliente possa conectar, as chances são de que seu serviço seja consumido por 99.9% dos desenvolvedores de sua plataforma, como mencionei acima, Get/Post é por padrão uma requisição simples que qualquer navegador ou linguagem que implemente HTTP pode fazer.
O recurso de saída

Geralmente quando se pensa em REST, grande parte pensa que só retorna formato JSON, de fato, mais de 90% dos serviços REST implementam esse retorno, só que não é toda regra que não tenha uma excessão, REST pode retornar o formato que você precisar, .dat, .xml, .txt, .html, .script, o retorno é definível na definição do serviço.

Em resumo só o fato de você retornar em TEXTO simples, ou um texto formatado como JSON, você abre as portas para a universabilidade e interoperabilidade de sua API.
Segurança sob acima de qualquer suspeita

A camada de segurança de um REST está sob o que você quer proteger, o caso mais comum é login e senha, onde o nível de segurança seria apenas de autorização, se você implementa um serviço, o mínimo que você tem que fazer é isso, e o caso ideal é implementar no servidor uma autenticação HTTP ou oAuth que é o mais comum em casos de API REST.

Ser ou não ser oAuth é uma questão adversa as usabilidades de seu serviço, se você está lhe dando com dados sensíveis como (cadastros de pessoas, contas bancárias, resumos financeiros), você precisa de uma autenticação oAuth e que sua API descanse em um protocolo HTTPS.
Como definir então API em formato REST?

Isso é assunto para os próximos 2 artigos que serão publicados aqui, mostrando como criar um REST em serviços JAVA usando o Jersey com padrão de design JAX-RS, implementando REST com PHP usando um framework simples o Slim Framework.

frameworks/ HTML 5/ HTML5 / CSS3/ JQuery/ Mobile/ Phonegap/ Web 2.0

Os mitos do desenvolvimento Front-end com HTML, CSS e Javascript

openweb

Eu já havia comentado em outro post aqui no blog sobre os 10 mitos de que tecnologias web não eram tão boas para fazer sistemas. Hoje me deparei com os slides de uma apresentação do Zeno Rocha que traduz tudo aquilo que eu escrevi em texto em imagens e razões para você acreditar que a semântica web está forte e cheia de recursos, navegue pelos slides e veja a variedade de possibilidades.

Sem mencionar que nos slides faltou só as soluções da empresa Sencha e o SDK da Blackberry para dispositivos móveis o Webworks.

Os sdks e bibliotecas para desenvolvimento Web amadureceram tão rápido em pouco mais de 2 anos que eu nem imagino o que estará por vir daqui a 2 anos à frente.

Dicas/ Dicas e truques/ Google/ HTML 5/ HTML5 / CSS3/ Web 2.0

Coloque seu site ou aplicativo web no modo turbo

rocket launch

Se você é fanático por performance e tem acesso shell/root ao seu servidor, vai aqui uma dica muito importante para optimizar todas as páginas que você serve para seus leitores/usuários.

Se seus serviços forem sob o teto do servidor Apache HTTP, então você precisa conhecer urgente o mod_pagespeed que acelera o processo de carregamento do aplicativo/sites a níveis de grandes sites como Google.com e facebook.com

Só para você ter uma idéia, meu site com todas as técnicas que abordei em meu arquivo .htaccess ele beirava os 6.5s para carregar por completo para você leitor. Depois que eu ativei o mod_pagespeed o tempo passou para 1.65s e o melhor de tudo isso, banda e processos foram economizados.

O que o mod_pagespeed faz na verdade?

Ele basicamente optimiza tudo que você deixou para depois e acabou esquecendo de fazer ou simplesmente não deu tempo devido a pressão sofrida no trabalho para liberar uma release.

Então através de filtros pré-definidos via String na sua configuração o mod_pagespeed cria diretivas de rápido acesso permitindo que você faça performance à baixo nível no servidor.

O mod_pagespeed é um santo remédio, porém você deve usa-lo com cautela, já que boa parte de seus filtros ainda são experimentos e nunca se sabe o que poderá causar de ruim para sua aplicação.

 

Pagespeed e derivados

Existem outros módulos no apache que é importante frizar bem para que você não continue achando que o pagespeed é o único salvador da pátria, outros módulos foram usados em meu problema, porém o pagespeed de fato teve um ganho muito mais considerado deixando ele agir sobre os arquivos estáticos.

Módulos que também usei e que são necessários para o pagespeed rodar.

Mod – rewrite

Mod – headers

Mod – deflate

 

Esses módulos podem ser instalados perfeitamente em seu servidor Apache usando os seguintes comandos.

 

Instalando o módulo rewrite.

a2enmod Nome_do_Modulo

 

O comando a2enmod, basicamente diz, Apache2 habilite modulo X, se você quiser ver todos os módulos habilitados em seu servidor Apache, basta ir em cd /etc/apache2/mods-enabled/

e dar um ls

 

Como instalar em um servidor Ubuntu/CentOS/Debian/Fedora

Baixe o módulo pagespeed diretamente aqui, links estão do lado direito.

Uma vez que você escolheu o pacote correto para sua distribuição linux, use o comando wget para baixar o pacote.

root@li437-29:~# wget https://dl-ssl.google.com/dl/linux/direct/mod-pagespeed-beta_current_amd64.deb

 

Como eu tenho um sistema operacional Ubuntu 64 bits usei o pacote acima.

Uma vez que o download completou, basta executar os seguintes comandos se você estiver no Ubuntu.

dpkg -i mod-pagespeed-*.deb
apt-get -f install

Se estiver no CentOS ou Fedora, execute

yum install at  (if you do not already have 'at' installed)
rpm -U mod-pagespeed-*.rpm

 

Depois disso, só habilitar o pagespeed no Apache, usando o comando a2enmod

a2enmod pagespeed

Pronto, seu módulo pagespeed está habilitado e pronto para executar, agora basta configurar os filtros que vem nele para melhorar o desempenho.

Por padrão o módulo é desabilitado justamente por que você precisa configura-lo antes de sair usando, afinal o Google não quer que seu site saia fora do ar antes mesmo de você coloca-lo em modo turbo.

Para isso, abra o arquivo de configuração do pagespeed que fica na pasta /etc/apache2/mods-enabled e use um editor que você esteja confortável em usar, eu uso o Vim, tem gente que gosta de outros e por ai vai. Para abrir é simples, vi pagespeed.conf

O arquivo vem basicamente assim.

# Turn on mod_pagespeed. To completely disable mod_pagespeed, you
# can set this to "off".
ModPagespeed on
 
# Direct Apache to send all HTML output to the mod_pagespeed
# output handler.
AddOutputFilterByType MOD_PAGESPEED_OUTPUT_FILTER text/html
 
# If you want mod_pagespeed process XHTML as well, please uncomment this
# line.
# AddOutputFilterByType MOD_PAGESPEED_OUTPUT_FILTER application/xhtml+xml
 
# The ModPagespeedFileCachePath and
# ModPagespeedGeneratedFilePrefix directories must exist and be
# writable by the apache user (as specified by the User
# directive).
ModPagespeedFileCachePath "/var/mod_pagespeed/cache/"
ModPagespeedGeneratedFilePrefix "/var/mod_pagespeed/files/"
 
# Override the mod_pagespeed 'rewrite level'. The default level
# "CoreFilters" uses a set of rewrite filters that are generally
# safe for most web pages. Most sites should not need to change
# this value and can instead fine-tune the configuration using the
# ModPagespeedDisableFilters and ModPagespeedEnableFilters
# directives, below. Valid values for ModPagespeedRewriteLevel are
# PassThrough, CoreFilters and TestingCoreFilters.
#
# ModPagespeedRewriteLevel PassThrough
 
# Explicitly disables specific filters. This is useful in
# conjuction with ModPagespeedRewriteLevel. For instance, if one
# of the filters in the CoreFilters needs to be disabled for a
# site, that filter can be added to
# ModPagespeedDisableFilters. This directive contains a
# comma-separated list of filter names, and can be repeated.
#
# ModPagespeedDisableFilters rewrite_images
 
# Explicitly enables specific filters. This is useful in
# conjuction with ModPagespeedRewriteLevel. For instance, filters
# not included in the CoreFilters may be enabled using this
# directive. This directive contains a comma-separated list of
# filter names, and can be repeated.
#
ModPagespeedEnableFilters rewrite_javascript,rewrite_css
ModPagespeedEnableFilters collapse_whitespace,elide_attributes
 
# ModPagespeedDomain
# authorizes rewriting of JS, CSS, and Image files found in this
# domain. By default only resources with the same origin as the
# HTML file are rewritten. For example:
 
# ModPagespeedDomain cdn.myhost.com
#
# This will allow resources found on http://cdn.myhost.com to be
# rewritten in addition to those in the same domain as the HTML.
#
# Wildcards (* and ?) are allowed in the domain specification. Be
# careful when using them as if you rewrite domains that do not
# send you traffic, then the site receiving the traffic will not
# know how to serve the rewritten content.
 
# Other defaults (cache sizes and thresholds):
#
# ModPagespeedFileCacheSizeKb 102400
# ModPagespeedFileCacheCleanIntervalMs 3600000
# ModPagespeedLRUCacheKbPerProcess 1024
# ModPagespeedLRUCacheByteLimit 16384
# ModPagespeedCssInlineMaxBytes 2048
# ModPagespeedImageInlineMaxBytes 2048
# ModPagespeedCssImageInlineMaxBytes 2048
# ModPagespeedJsInlineMaxBytes 2048
# ModPagespeedCssOutlineMinBytes 3000
# ModPagespeedJsOutlineMinBytes 3000
 
# Bound the number of images that can be rewritten at any one time; this
# avoids overloading the CPU. Set this to 0 to remove the bound.
#
# ModPagespeedImageMaxRewritesAtOnce 8
 
# You can also customize the number of threads per Apache process
# mod_pagespeed will use to do resource optimization. Plain
# "rewrite threads" are used to do short, latency-sensitive work,
# while "expensive rewrite threads" are used for actual optimization
# work that's more computationally expensive. If you live these unset,
# or use values 
SetHandler mod_pagespeed_beacon
 
# Uncomment the following line if you want to disable statistics entirely.
#
# ModPagespeedStatistics off
 
# This page lets you view statistics about the mod_pagespeed module.
 
Order allow,deny
# You may insert other "Allow from" lines to add hosts you want to
# allow to look at generated statistics. Another possibility is
# to comment out the "Order" and "Allow" options from the config
# file, to allow any client that can reach your server to examine
# statistics. This might be appropriate in an experimental setup or
# if the Apache server is protected by a reverse proxy that will
# filter URLs in some fashion.
Allow from localhost
Allow from 127.0.0.1
SetHandler mod_pagespeed_statistics
 
# Page /mod_pagespeed_message lets you view the latest messages from
# mod_pagespeed, regardless of log-level in your httpd.conf
# ModPagespeedMessageBufferSize is the maximum number of bytes you would
# like to dump to your /mod_pagespeed_message page at one time,
# its default value is 100k bytes.
# Set it to 0 if you want to disable this feature.
ModPagespeedMessageBufferSize 100000
 
Allow from localhost
Allow from 127.0.0.1
SetHandler mod_pagespeed_message
 
Allow from localhost
Allow from 127.0.0.1
SetHandler mod_pagespeed_referer_statistics

O que você precisa habilitar primeiro é o módulo.

 ModPagespeed on

Depois configurar onde ele vai guardar os caches

  ModPagespeedFileCachePath            "/var/mod_pagespeed/cache/"
  ModPagespeedGeneratedFilePrefix      "/var/mod_pagespeed/files/"

Coloque em um diretório de sua preferência.

Com apenas isso, você já vai notar uma significante mudança no carregamento de seu site ou App em 50%. Tem muita configuração para você fazer através de filtros.

Os filtros que utilzei foram esses.

 ModPagespeedEnableFilters combine_css

O filtro combine_css já diz, tudo ele combina tudo que você tem de CSS em um único arquivo.

Outro filtro que usei foi o minificador de Javascript.

ModPagespeedEnableFilters rewrite_javascript

Em caso de você esquecer de minificar seu código javascript, ele faz automático para você.

Outro bastante importante é a configuração das imagens, elas tem um peso absurdo quando o negócio é carregamento.

Eu usei os seguintes filtros.

 ModPagespeedEnableFilters inline_images,recompress_images,resize_images

Peço para carregar todas as imagens em inline, tudo junto, comprima elas e faça um resize caso necessário.

 

Claro que os filtros que eu usei são específicos para meu caso, embora ele vá servir também para vocês na maioria dos casos, recomendo ler os pro e contras de qualquer filtro que você habilite na documentação do Google pageSpeed, que por sinal é bem completa.

E depois disso tudo? Como faço para testar?

Existem diversas ferramentas on-line que analisam o conteúdo do site para você e diz onde está errando, inclusive no próprio site do Page speed, o Google disponibiliza o Page speed Insights, detalhando tudo que você precisa saber para corrigir os erros e melhorar a performance do site.

O mais legal do Pagespeed Insights é a possibilidade de você testar o carregamento em Desktop e Mobile.

Outra ferramenta que fiz bastante uso em meu problema, foi o Full Page Test da Pingdom, para ver se realmente o Pagespeed tinha afetado a performance do site.
No Google Page Speed Insights meu site carregou em 680ms quase 1 segundo. No Pingdom os resultados foram mais reais digamos assim. Carregados em 1.65s.

Sem tudo isso do Pagespeed meu site estaria sendo carregado em meros 5 ou 6 segundos, isso por que boa parte de seu conteúdo é texto.

É isso, escrevei outro post de como eu consegui reduzir o consumo de memória do servidor servindos 50 visitas /segundo nesse blog depois que mudei para servidores novos.
Foi uma grande aventura configurar o Apache e o MySQL para reduzir o consumo de memória.

HTML 5/ HTML5 / CSS3/ JQuery/ Web 2.0

Melhor IDE para desenvolvimento Web com JQuery,CSS,HTML5

Vez ou outra eu recebo um e-mail dos leitores do blog sobre a melhor IDE para desenvolvimento Web com padrões web (HTML5,JQuery,CSS).

Então decidi escrever esse post para tentar ajudar os atuais ou futuros que vierem perguntar.

Geralmente a resposta é mais ou menos assim.

Não existe MELHOR IDE, existe a IDE que lhe deixa confortável em programar e que respeite os padrões da equipe onde você está alocado ou trabalhando.

IDE’s dependem do projeto que você está fazendo e qual tecnologia está usando, quer ver um exemplo? Você está em um projeto que trabalha com ASP.Net e/ou C#, logo 99% dos casos você vai ver gente usando o Visual Studio(e/ou Visual Studio Express), ai eu pergunto, vale a pena sair de uma IDE que já é completa para você? Claro que não.

E assim, é a continuação, independente de seus gostos, a tecnologia que você vai adotar, interfere na IDE que você usa, então como os padrões Web são canteiro de obras para diversas empresas, as opções não faltam.

Sugiro você olhar entre cada uma dessas abaixo, a que melhor se encaixa em seu perfil, do projeto e da natureza do projeto, assim você não foca seu entusiasmo na ferramenta e sim no produto.

Adobe Dreamweaver CS5.5 – Até agora tem sido a melhor IDE para quem tem 4Gb de memória para cima, abaixo disso, você irá odiá-la.

IDE’s da Jetbrains (Webstorm,PHPStorm) – São bem baratas e bem eficientes para quem ja é da área há certo tempo, possui diversos recursos de auto complete e macros para quem não quer repetir as tarefas do dia-a-dia.

Eclipse + WTP – É gratis e quem está acostumado com o Eclipse e integra seus serviços com Java por exemplo, o Eclipse com o plug-in WTP sem dúvida é a melhor opção dessa área.

Eclipse + Aptana – Também é gratis e quem usa Ruby on Rails ou PHP e padrões Web, essa é uma excelente IDE, ajuda você a automatizar certos processos, inclusive com uma janela de terminal estilo linux, menos no windows.

Tem outra IDE que não é bem uma IDE completa, mais uma ferramenta de edição que tem me deixado perplexo pelo seu incrível suporte a HTML5, CSS3 e Javascript apenas, tirando o fato de ser super barata e leve, por exemplo, quem tem 1Gb de memória RAM, rodará ela facilmente.

O sublimeText, é mais voltado para quem já tem anos de exeperiência e já conhece muita coisa das linguagens (CSS3,JS e HTML).

Até breve!

HTML 5/ HTML5 / CSS3/ JQuery/ Web 2.0

10 mitos da incompatibilidade nos navegadores para HTML/CSS/JS

Quem anda de cabresto, sempre tende a olhar para baixo, excluindo a curiosidade de olhar o mundo exterior ao seu redor, depois que eu saltei da minha zona de conforto a 10 meses atrás, eu tinha a notória sensação de que eu descobria coisas novas a cada segundo, e as lembranças da zona de conforto me acomodaram mal, muito mal por sinal.
Uma das coisas que te deixam infeliz é a tal preguiça de inovar, justamente por que confortavelmente você acha que nunca precisa mudar, e nessa migração constante deparamos com mitos criados ou expurgados por quem não dá a mínima atenção em inovar e ser competitivo.

Quando eu comecei a estudar HTML5/CSS3/JS, eu tinha aquela sensação de mal estar adquirido, achando que nada prestava, tudo precisava melhorar, CSS então era a brincadeira de estica e puxa,Deus nos acuda!

Ao passar das semanas eu fui percebendo que os navegadores evoluíram bastante, frameworks e desenvolvedores de padrões web colaboraram para essas evoluções e no final percebi que quem estava atrasado na história era eu mesmo.

Então somei o que eu achava mito e decidi escrever esse post para você abrir sua mente e se liberar de seus medos.

10 Mitos da incompatibilidade nos navegadores

MITO 1 – HTML e CSS é feito para fazer sites e não sistemas.

Resposta: Então você nunca usou o Hotmail, Gmail, adWords, adSense na vida, você nunca usou itaú bankline, Bradesco on-line e por ai vai. o HTML e CSS é poli valente, funciona para tudo.

MITO 2 – Tenho que fazer vários ifs e elses para suportar N navegadores

Resposta: Não há necessidade, já que existem N frameworks no mercado que fazem a manipulação perfeita entre engines de navegadores, grande parte dos navegadores usam webkit/gecko e o único a usar um engine diferente é o IE com seu msie, porém na última versão 8, já vem com suporte a padrões web.

Frameworks que podem te ajudar a quebrar esse mito: JQuery, MooTools, EXT Js, Script.aculo.us, ProtoType.

Ou seja, alternativas é o que não falta para esse mito, já que todos peleijam em achar que irá voltar a época das cavernas por manipular DOM de cada engine de navegador.

MITO 3 – HTML5 é incompatível com navegadores

Respota: Desde quando HTML é incompatível com navegadores? HTML5 nada mais é que uma nova versão do HTML, existem alguns recursos como WebGL, Canvas, Audio, Video, codecs de audio e video que são específicos de cada navegador, que ao total 93% de todos os recursos que você vai usar em um único projeto é compatível com todos os navegadores.

Caso você ainda tenha problemas em achar que o HTML5 pode não rodar perfeitamente no IE7,8 você pode usar bibliotecas já prontas para isso. Uma delas inclusive é amplamente utilizada, a Modernizr.

MITO 4 – Não posso usar MVC em uma aplicação web feita em Javascript e HTML

Resposta : Mito detonado, no bom estilo caçadores de mitos, desde que javascript é javascript, e tudo é Objeto. Então eu manipulo qualquer objeto aplicando qualquer padrão existente, Aconselho você usar esse slides para te influenciar a pensar diferente.

MITO 5 – Não consigo criar interfaces com facilidade como no Flex

Resposta: É por que você não conhece o JQuery UI, YUI, Prototype UI, UKI, MochaUI, Livepipe UI, Alloy UI e GWT. Ou seja, alternativas para você criar interfaces não faltam.

MITO 6 – Aplicações Web feitas em HTML 5 e CSS3 não são cross-plataforma.

Resposta: Navegadores hoje são cross-plataformas, rodam no Linux, MAC, Windows, ios, Android e Windows Phone. Se sua aplicação fica na caixinha de areia do navegador então ela também será cross-plataforma, não tendo a necessidade absoluta de portar seu aplicativo para diferentes plataformas. Assim como no Flash Player ser cross-plataforma, é por que ele tira proveito dos navegadores.

MITO 7 – Aplicações feitas em HTML5 e CSS3 são lentas

Resposta: Uma vez que sua aplicação pronta, ela trafega muito mais rápido para o navegador do usuário do que seu SWF, já que não é compilável, é apenas lida.
O Flex compila o que você escreve em um SWF, esse SWF é binário, como uma imagem em JPEG ou PNG é. A diferença é que uma vez baixado ele se torna mais rápido por que não é interpretado. Já com HTML, CSS e JS ele é interpretado sempre que você manipula.

A grande vantagem está no tráfego de dados e na re-utilização do sistema, á que por padrão ele tem cache ativo. roda muito mais macio no navegador e não depende de plug-in.

MITO 8 – Em aplicações Web eu não consigo fazer Sockets, usar o AMF

Resposta: Você consegue sim, WebSockets são novidade, são feitos em js, veja o Node.JS. E AMF conheça o AMFJs.

MITO 9 – As IDE atuais são péssimas, produtividade ZERO

Resposta: Mito detonado também, existem N IDEs excelentes uma delas é as IDEs feitas pela JetBrains, compatíveis com os padrões do mercado e cheia de recursos, outras tão boas são para o Eclipse como o Aptana. E claro o Dreamweaver CS5.

MITO 10 – Meus aplicativos são re-escritos sempre que for criar uma versão mobile deles.

Resposta: Existem 2 posibilidades de você usar HTML, CSS e JS em aplicações Móveis, uma é usar os Media-Queries de CSS, fazendo o layout de suas aplicações responsivas. Ou criando um aplicativo específico para Mobile usando o mesmo HTML 5 e CSS3 feito para versão Web/Desktop.

Então se você chegou até aqui, é sinal que alguns mitos já passaram por sua cabeça e a dúvida pairava no ar. A minha sugestão é, ajude outras pessoas a se libertar desses mitos.

Dicas/ Negócios/ Notícias/ Web 2.0

47 mandamentos para agências digitais de acordo com a Grïngo

Adoro o bom humor da Grîngo, especialmente do André. Fora as super dicas que é verdade pura e material muito bom para diversos trabalhos de “aspirantes à publicidade”. O André falou certo o Brasil é a China na publicidade. hehe

Aprecie um bom material, raramente encontrado com uma pitada de humor informalizmo.

Adorei o slide 35 e 104 hahahaha rir muito.

Negócios/ Vídeo/ Web 2.0

Três tendências para 2010 no mundo de desenvolvimento

Por todo lado do mundo você ver, pessoas blogando suas tendências para o próximo ano. E como é de costume prevermos alguma coisa que pode ocorrer futuramente. Eu tenho as minhas 3 tendências que vão decolar em 2010, podem até empacar, risco é risco, mas nada tão bom quanto arriscar.

1 – Ele veio de mansinho, feito por um gigante e como é de praxe todo mundo dizer que um dia ela dominar o mundo. O Google Android é a plataforma de sucesso que garimpou muito nesse ano de 2009. O que consecutivamente para 2010 vai continuar o bom trabalho feito esse ano. Prova disso é a nova versão do Android 2.0. Fora diversas empresas já lançando seus celulares com o Android habilitado. Em 2008 eu falei para o Fabiel Prestes, acho que ele deve lembrar, quem dominar a desenvolver para ele. Está com emprego garantido para os próximos 5 anos. O momento é agora, ano que vem isso vai ser novidade. Já que a HTC acabou de anunciar seus novos aparelhos para o ano de 2010. Onde o Android já se integra para qualquer tipo de serviço de rede social. Afinal é google né!
Falando-se em desenvolvimento Mobile, o processo para aprovação de envio do seu aplicativo para o Android Market. É muito diferente da Apple. Onde já vi diversos desenvolvedores reclamando da lentidão de se aprovar um novo aplicativo. Isso o google fez bem diferente o que conquista o principal ator do espetáculo “O Desenvolvedor”.

2 – ORM – Nem precisa falar muito dele, suas siglas Object Relation Mapping, como o guia Wikipedia diz em bom tom:

Mapeamento objecto-relacional (ou ORM) é uma técnica de desenvolvimento utilizada para reduzir a impedância da programação orientada aos objetos utilizando bancos de dados relacionais. As tabelas do banco de dados são representadas através de classes e os registros de cada tabela são representados como instâncias das classes correspondentes.
Com esta técnica, o programador não precisa se preocupar com os comandos em linguagem SQL; ele irá usar uma interface de programação simples que faz todo o trabalho de persistência.
Não é necessária uma correspondência direta entre as tabelas de dados e as classes do programa. A relação entre as tabelas onde originam os dados e o objecto que os disponibiliza é configurada pelo programador, isolando o código do programa das alterações à organização dos dados nas tabelas do banco de dados.
A forma como este mapeamento é configurado depende da ferramenta que estamos a usar. Como exemplo, o programador que use Hibernate na linguagem Java pode usar ficheiros XML ou o sistema de anotações que a linguagem providencia.

Fonte Wikipedia.

ORM vai melhorar muito ano que vem. Como Hibernante é Nostradamus, todas as linguagens de programação voltadas para Web e desktop vão dar suporte a ORM. Onde já temos Java,ColdFusion,Ruby on Rails, Python e PHP. Haverá muito mais suporte e bem melhor do que as atuais já com suporte, o desenvolvedor já deve saber isso para ano que vem arrebentar.

3 – Vídeo. 70% dos videos na Web são criados para rodar na plataforma Flash Player, graças ao pessoal do On2 Technology (hoje Google). Quem domina o fator Vídeo, TV’s on-line, vai saber ganhar dinheiro e ter diversas ferramentas distintas para ensinar e interter. Dentre as tecnologias mais usadas para provê são servidores de transcoding para o formato de qualidade H.264,são o FFMPEG, FMIS, WoWza, FoxServer,Red5. Principalmente aqui no Brasil, onde os dois setores foram responsáveis por boa parte da fatia gastas em publicidade e assinaturas. Não é atoa que o Youtube é o site mais acesso no Brasil, cerca de 48 milhões de visitas únicas todos os meses.

Essas são nossas tendências para 2010. Ao nosso ponto de vista do mundo de desenvolvimento.

Dicas/ Microsoft/ RIA/ Web 2.0

10 maneiras de fracassar com seu aplicativo RIA

Durante a leitura mensal da newsletter do Architect Journal da Microsoft, percebi o link da palestra do Anthony Franco, presidente da EffectiveUI, mostrando 10 maneiras de como fracassar em um produto RIA.

Vale listar aqui alguns itens que foi abordado e concordamos:

  1. distribuindo conteúdo para seus usuários. Pense nele, mais não entenda-o literalmente.
  2. Agnósticos a tecnologia. Quem usa um aplicativo todos os dias não quer saber em que foi feito.
  3. Não deixe os desenvolvedores decidirem sobre o layout e UX da aplicação. Fracasso eminente.
  4. 70% dos projetos fracassam por que usuários ignoram qualidade ruim no que ver.
  5. O produto é mais importante do que o processo para desenvolve-lo. Essa foi excelente

Assista aqui. O Player do MIX09 é feito em SilverLight, então se você tem Mac e Windows pode assistir. Porém caso não tenha o plug-in do Silverlight, você precisa instalar.

Dicas/ Eventos/ Flex/ Notícias/ Web 2.0

Flex Mania 2009 – O evento aguardado por todos

É com grande euforia e alegria que anuncio oficialmente para toda comunidade a Flex Mania. É sem dúvidas e esta sendo um grande desafio planejar, elaborar e executar esse evento. Para mim está sendo um desafio bom de ser vencido.

Como tinha comentado após o aniverário de 5 anos da Flex-Brasil. Sobre o possível presente, este não é só meu presente. Mais de todos os 20 palestrantes inclusos durante os dois dias de evento ( 6-7 de julho) para com você.

Esse evento só será um sucesso se contarmos com todo seu carinho com a comunidade, apoio, divulgação e também sugestões para a atual e a próxima conferência.

Vocês podem visitar e aguardar anciosamente os dia do Evento. Visite www.flexmania.com.br

Algumas caracteristicas interessantes:

* 100% on-line
* Conteúdo de primeira linha
* 20 palestrantes com um extenso know-how
* Conteúdo de 17 palestras feito por Brasileiros
* 3 participantes internacionais com destaqui na comunidade por suas contribuições
* Inciamos com a experiência de adicionar 2 palestras diferenciadas dos tópicos Flex, já que é uma tendência para as próximas versões ter diversas tecnologias falando sobre RIA.

Muito Obrigado e aguardo o apoio de todos vocês na participação e divulgação.

Negócios/ Web 2.0

O ano em que novas APIs brasileiras vão entrar no mercado

Existem uma dúzia de posts falando sobre a falta de API’s para serviços de sites brasileiros. Eu me pergunto, onde estão esses serviços? Conta-se nos dedos ainda, sites que tem um bom serviço e que possam vir a distribuir o acesso via API.

Veja bem, a boo-box é uma empresa brasileira em uma forma de bolo americana, coisa linda de se ver. O que esses garotos estão fazendo, nada mais é que colocando de fácil acesso o uso dos dados de sites de comércio eletrônico brasileiros como (americanas,submarino,mercado-livre), facilmente acessado via API externa, coisa que até já fizemos uma para seus serviços em Actionscript 3.0; E o melhor você pode faturar grana.

Existem apenas dezenas não centenas de sites brasileiros que provê serviços ao público em geral, por que ainda existe o tal do mito que a Web brasileira é 1.0. O fato é que os desenvolvedores brasileiros, ou melhor falando de galo para galo, as empresas brasileiras ainda não enxergaram o potencial de negócios existente em deixar o desenvolvedor terceiro ou novos serviços agregar valor ao seu modelo de negócio.
É mais ou menos assim, você ilustra uma pequena história e os analistas de negócios começam a entender que será necessário evoluir, é a velha máxima, “Dividir para conquestar”.
Continuando com o tópico sobre comércio eletrônico, imagine que você vai a loja em sua cidade, entra, olha o produto que quer comprar, ou não, e sai sem precisar criar um vínculo com aquila loja.
Outro certo dia você volta, analisa outro produto e decide levá-lo, porém a loja requer que você mantenha um vínculo com ela, que você compartilhe seus dados com ela, é um preço injusto em certas ocasiões, já que você fica com receio de onde irá parar.
O certo pensar era que você poderia se vincular apenas a sua bandeira de cartão de crédito, deixar que ele tome conta de seus dados e a operadora do cartão de crédito assumiria o vínculo com a loja. Parece meio bizarro a idéia de primeiro momento, mais pare, pense e veja em sua volta que é justamente isso que acontece quando você compra um produto à vista na loja física, você opta por criar o vínculo com a loja.
Imagina se isso existisse em sua loja virtual preferida, onde você poderia ter seu próprio site onde manteria o vínculo apenas com a operadora de cartão e assim controlar tudo.
Agora no atual momento, isso é apenas sonho de um pobre desenvolvedor que tem idéias das quais são limitadas por políticas de portas fechadas para o mundo lá fora.
E falando-se em mundo lá fora, tem a seguinte regra “Engula ou será engolido”. É justamente o que vai acontecer se daqui a 1 ano as empresas que provêem serviços aos brasileiros não se adequarem a maneira que o mercado vai. Vai acontecer como existe já a ameça do Paypal explorar o mercado Brasileiro como os serviços pagseguro e pagamentodigital.
Não vai demorar muito para ambos, sentirem ameaçados pelo Paypal e começarem a lançar suas APIs, diferente deles o Paypal tem uma vasta API para todo tipo de linguagem de programação que você pensar.

Então penso eu na frase, “engula ou será engolido“, ser verdade. Será 2009 o ano em que as empresas brasileiras, não tão somente elas mais serviços do governo como Correios, Receita Federal, lançarem API’s para seu serviços na web?