Adobe AIR 101/ AIR 1.0/ AIR 1.1/ AIR 2.0/ AIR 2.7/ AIR 3.0/ AIR Mobile/ Flash Player

Adobe AIR perde o foco para criar Apps para dispositivos móveis

air_2_lg.jpg.adimg.mw.138

A Adobe hoje atualizou o Flash Player e Adobe AIR Whitepapers, que é um documento público mostrando as intenções da empresa desde sua mudança de foco nos últimos 2 anos.

Hoje ela acredita que suas plataformas Flash Player/ Adobe AIR continuaram fortes na arquitetura atual e abandorá todos os esforços na criação da próxima versão do Actionscript Next e Flash Player Next, que possivelmente seriam o Actionscript 4.0 e o Flash Player 12.

Ela voltará seu foco em novas VM como o V8 por exemplo do Google Chrome ou o Webkit amplamente utilizado por vários fabricantes de navegadores.
Com essas novas atualizações dos documentos, houve Buzz e ainda vai ter, veja alguns destaques de pessoas importantes dentro da empresa, e suas visões em relação à plataforma.

Já que a regra vale a máxima, Uma imagem vale mais do que mil palavras, quanto mais uma declaração como essa.

adobe_airmobile

 

Sim, nós não estamos promovendo o AIR para criação de apps para smartphones. Eu concordo que o AIR é ótimo com o Starling e o Feathers, já que você tem uma velocidade quase nativa.

 

Essa foi uma das declarações feita por alguns dos evangelistas da Adobe, em especial o Lee no Google Plus e está disponível para quem quiser ler, que hoje lidera a parte de evangelismo para Jogos.

Não é polêmica a declaração, só reafirma que o compromisso da Adobe não é só manter o foco na plataforma Flash/AIR em sí, mas dar ênfase à outra parcela de desenvolvedores que adotam o padrão aberto.

Na mesma discussão Mike Chambers reforça que o foco da Adobe para plataforma Flash é Jogos.

adobe_airmobile2

 

 

Não é que você precisa ficar desesperado por que o suporte ao Adobe AIR vai sumir do mapa e você não vai mais conseguir criar Apps usando o Adobe AIR, só para você saber quando e como usar o AIR em suas Apps, mesmo usando ele embedado na sua App.
Essa ficará para história de como destruir um eco-sistema enorme de desenvolvedores para concorrentes.

Apache Flex/ Flex/ Notícias/ Open-source

Apache Flex é uma tecnologia de interfaces que vai continuar revolucionando pelos próximos 10 anos

apache_flex_logo

Trabalhar em um grande projeto open-source é um desafio grande, em especial com o projeto Apache Flex que segue um forte legado de satisfação para quem desenvolve assim também para quem tem a solução criada por ele.

Faz aproximadamente 14 meses, desde que o projeto foi doado para fundação Apache e contribuições não param de chegar, só para você ter uma idéia é uma média de 140 emails recebidos por hora na lista de desenvolvedores, discutindo sobre vários aspectos o que a tecnologia ofereceu e o que ela está para oferecer.

Flex foi, é e provavelmente continuará sendo a melhor tecnologia de interfaces que o desenvolvedor já conheceu, sem tirar nenhuma palavra dessa sentença, o único erro da tecnologia foi ficar presa no tempo e na caixinha de areia do Flash Player.
Nesse artigo, eu quero apresentar para você, desenvolvedor Flex que vem acompanhando esse blog desde 2004 o que torna hoje o projeto Apache Flex um futuro tecnológico brilhante além de seu tempo. Eu já previa isso aqui.
Adobe Flex e seu passado

O Flex veio em um período que linguagens de interface eram o elo fraco de uma aplicação desktop ou web, e ele supriu essa necessidade, inspirando várias outras tecnologias de sua época, devido sua facilidade de criação e alto acabamento no resultado.

Se antes você escrevia em MXML/Actionscript e o produto final era um SWF que rodava em uma engine chamada Flash Player,  então competentemente ficávamos em nossa zona de convorto, sem esperar que alguma outra tecnologia pudesse fazer alarde e ultrapassar.

O Flash Player para ser popular precisa do navegador e o navegador para ser completo precisa ter suporte ao Flash Player, Isso era legal de se falar até 2008, só que antes disso, quem lembra do Shock wave, do real Player ? Todos estavam fadados ao desuso por que chegaram em uma zona de conforto que não viram que poderiam ficar para trás ao longo dos anos.

A era do Flash Player

É ai onde entra o fracasso atual do Flash Player em relação a esse aspecto.

Até hoje o Flash Player é odiado, melhor! É onde o flash player perde em popularidade, já que quando não se segue um padrão dos navegadores, que são a janela para a internet, a coisa começa a ficar estranha. Mais da metade de quem usa a internet no mundo dá a mínima para o player ou até desconhece seu uso, embora até 2009 seu uso estava presente em 98% dos navegadores.

De longe o Flash Player foi e foi até os dias de hoje o plugin mais famoso de todos os tempos, porém com seu sucesso, veio sua desgraça, uma vez que os navegadores viram que ele estava ofuscando seus brilhos, o que resultou em um ato colaborativo de vários CEOs do mundo em colocar de vez um ponto final no Flash Player

Quando Steve Jobs escreveu seus pensamentos sobre o Flash Player, foi a gota d’àgua de “se toca” para a Adobe atualizar e manter o Flash Player um estado de arte, só que ao invés disso o fracasso do CEO da empresa, respondeu apenas com alguns argumentos que não fizeram tanto alarde. Afinal a grande voz de Steve ecoou por toda a internet e tudo que era movimento relacionado ao padrão “Não open” saiu por dentro à fora e virou moda.
Infelizmente a tecnologia Flex estava atrelada apenas o Flash Player, o que acabou desmotivando a Adobe a encerrar a linha do Flash Player para dispositivos móveis para o Android, tanto é que hoje não existe mais oficialmente na Play Store, apenas a Blackberry com seu tablet “Playbook”, possuem ainda o Flash Player instalado.
Quando se perde o seu principal playground, você se desespera e desiste de uma tecnologia fantástica para o futuro de aplicações. Essa história é a mesma para várias outras empresas que ficaram presas em seu ambiente fechado e controlado e que acabou não entendendo que a internet anda a passos largos e de dificil controle.
Adobe Flex open-source

Foi ai que o Flex teve um final na história de participações da Adobe, sendo graciosamente doado para fundação Apache. Antes disso ela abriu o projeto, sendo open-source por vários anos, só que ninguém se interessava pelo projeto open-source, já que tudo era controlado pela Adobe, um envio de um simples bug para conserto, demorava vários e vários meses para ser solucionado. Algo precisava mudar.

No final de 2011 no apagar das luzes, A Adobe viu que não poderia deixar o produto morrer e doou para a fundação Apache, sábia decisão dela, afinal são mais de 1 milhão de desenvolvedores que usavam o Flex como principal tecnologia de front-end.

 

Nasce o Apache Flex

Ao contrário do que muitos achavam, o Apache Flex está vivo e muito ativo, com a recente doação final do Falcon e FalconJS o projeto começa a modificiar suas entranhas para não ficar dependente apenas do Flash Player, que esse pode ter seus (anos) contados.

Começamos incubados e já com várias releases, todas até hoje foram correções de bugs existentes e remoção de software proprietário que fazia parte do SDK, já que o projeto é sob licença apache, não se pode ter código de terceiro que seja necessário o pagamento para utiliza-lo.
Além de ser ativo, o projeto conta hoje com um time multi-disciplinar de diferentes partes do mundo, apenas um Brasileiro está no time, que é esse que escreve, porém você também pode fazer parte do time, basta colaborar ativamente para alguém te chamar e fazer parte da lista de committers, onde você pode submeter seus próprios patchs para correções e colaborações.

A última release 4.9 acompanhamos a atualização para o Java 7, assim o SDK continua progredindo junto com vários outros softwares open-source que o ajudam.

Futuros lançamentos

Hoje, estamos trabalhando no novo compilador, o FalconJS, é bem igual ao Falcon, que está em beta no Labs da Adobe, é o chamado comercialmente de “Actionscript compiler 2.0”.

A diferença é que com o FalconJS, você poderá escrever Actionscript/MXML e gerar Apps totalmente abertas ao HTML5/CSS3/Javascript, sem ficar mais dependente do Flash Player.

Queremos incluir esse novo compilador nas próximas releases da 5.x em diante. É um trabalho árduo, já que todo o compilador trabalha em um modo de dependência de objetos do Flash Player, o que é diferente do lado HTML que depende do Javascript e embora o Actionscript compartilhe da especificação ECMAScript, ambos possuem suas particularidades.

O que querendo ou não o Actionscript ainda é mais avançado que o Javascript, em especial para tipação, construtores de classes, etc.

Existe muito a se fazer, porém uma grande barreira foi quebrada, e até eu mesmo além de outros da equipe estávamos com pouca crença que o projeto saísse da mesmice de consertos, remendos e virassem um projeto base na fundação ao invés de ser apenas um protagonista incubado.

Qual o prazo para essas novas funções

Diferente de projetos que depende  de ações para serem valorizadas, o clico de release é mais lenta, as decisões são melhores tomadas, mas até o final de 2013 teremos um projeto sólido que pode ajudar muito desenvolvedor a migrar ou aperfeiçoar seus atuais projetos Flex.

Atualmente já temos em aplicações simples, escritas em Actionscript a saída em puro Javascript, em apenas 1 mês de testes, o que remete a um tempo bastante hábil para um projeto open-source sair do papel/idéia e virar realidade.

Muito do que foi aprendido e testado no FalconJS, veio do Jangaroo, é bom aprender com quem já está à um tempo no mercado. E boa parte das contribuições estão vindo do pessoal também do Jangaroo.

Apache Flex é um projeto cativante que vai continuar sendo utilizado e melhorado para os próximos 10 anos ou mais, desde que ele nunca mais cometa o crime de ficar atrelado apenas o Flash Player ou ao Adobe AIR, ele será multi-plural, você vai escrever e ficar dependente em Actionscript /MXML que continuaram sendo suas linguagens oficiais, só que ao invés disso o produto final passará a ser executado em várias plataformas, Desktop/Web/Mobile/Gadgets/etc. que aparecerem ao longo do tempo.

 

HTML 5/ HTML5 / CSS3/ JQuery

Criando apresentações de slides fantásticas com HTML5/CSS3/Javascript

igor

Terminando de aprontar os slides das minhas palestras no Campus Party 6 de São Paulo e eu queria usar uma forma diferente de apresentar, eu coleciono vários ppts de outras palestras, publiquei algumas no slideShare. Mais minha natureza inquieta pede que eu siga em frente e mude para outras alternativas mais abertas.

Pesquisando na internet logo vi que o HTML, CSS3 e Javascript tem muito à oferecer para quem é curioso, e descobri dentre várias opções essas 3 bibliotecas que vai lhe surpreender com o resultado final.

O grande inspirador foi o http://slides.html5rocks.com, e ai nasceram essas ótimas alternativas

RevealJS

Esssa foi minha escolha para as apresentações de slide no Campus Party 6, o RevealJS é feito apenas com HTML, CSS e Javascript, a grande diferença é que se utiliza novos artificios do CSS na versão 3 para animar em 3D e um pouco da ajuda do Javascript, o HTML é nato.

Um ponto positivo do RevealJS para quem é desenvolvedor, é que quando você está em uma apresentação e quer mostrar trechos de códigos, um ppt é um saco nesse quesito, o RevealJS tem uma dependência chamada highlight.js que ajuda nesse quesito.

E não se limite apenas à isso, quando você imprime a apresentação ela vem em um elegante formato PDF(apenas no Google Chrome) com os slides no mesmo formato que você ver, alinhados verticalmente.

ImpressJS

Quem lembra do Prezi? A idéia é justamente essa, só que não feito em Flash/as3, mas em puro CSS3 com efeitos de 3D e com a ajuda do Javascript.

DeckJS

É um pouco mais tímido em relação a efeitos hollywoodianos, mas atende o propósito de rodar em vários navegadores, inclusive no IE, coisa que o ImpressJS e o RevealJS não fazem, já que depende de efeitos 3D e no IE9 para baixo isso é complicado. Embora eles tenham um fallback, perde toda a graça sem os efeitos.

 

Dê adeus ao velho formato ppt em suas apresentações, de hoje em diante comece a usar html. E quem tiver notícias de outras bibliotecas como essas, só deixar o link nos comentários.

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.

Firefox OS/ Mobile

Firefox OS no Campus Party 2013

Firefox_mobile_mozilla

firefoxos

Durante o Campus Party 2013 a telefônica, juntamente com a fundação Mozilla estão organizando um concurso para desenvolvedores HTML.

Em resumo, o novo sistema operacional Firefox OS transforma seu smartphone em um web OS, onde todas as Apps são feitas em HTML/CSS/Javascript, você pode até criar uma versão do seu site para o sistema operacional, para saber mais como criar Apps em HTML para o Firefox OS eu sugiro que você visite os sites abaixo:

 

Durante o Campus Party quem tiver dúvidas sobre o Firefox OS e como montar o ambiente, podem me procurar que ajudarei.

Segue a release do concurso.

A Telefonica | VIVO, em parceria com a Mozilla, está promovendo na Campus Party SP um concurso de desenvolvimento de aplicativos para FIREFOX OS na Campus Party Brasil 2013.
Nessa versão, estamos contando com o apoio do Facebook tanto do ponto de vista técnico aos desenvolvedores quanto na premiação.
Além de Smartphones VIVO para os três primeiros lugares, o primeiro fará uma entrevista com engenheiros e conhecerá como é trabalhar no Facebook Brasil!
A inscrição começou a partir de 14/01 e pode ser feita preenchendo o formulário nesse link http://bit.ly/12zAH8p. A inscrição só é efetivada quando um e-mail de confirmação é enviado ao candidato.
Lembrando que somente podem participar desenvolvedores devidamente credenciados que irão participar da Campus Party Brasil 2013. Para mais informações o link dos termos do concurso é http://bit.ly/XIIlcc.
Dicas/ Notícias

Linode e o problema do Disk I/O

linode_logo

Quem tentou acessar o hoje o dia todo o blog, estávamos fora do ar, devido a um problema de hardware nos servidores da Linode. Embora isso tenha ocorrido com uma certa frequência entre os meses de setembro/outubro, já que era o problema de software, adotamos diversas técnicas

Porém, nas últimas duas semanas vocês quase não perceberam, mas caímos 8 vezes em um período de 13 dias, mesmo sendo um blog e com um volume de acesso grande, isso não confude quem está sempre de olho nos gráficos e os gráficos não mentem, a solução nesses últimos 13 dias era de sempre resetar a imagem e retornar do zero.

E nas últimas horas, tudo saiu do controle.

linode_disk_io

Mudamos bastante a estrutura do wordpress que é o engine do blog, criamos nosso próprio thema leve, criamos vários swaps e cache tanto do lado cliente quanto do lado do servidor. Resultado estamos consumindo apenas 26.5% dos recursos de disco e Swap de disco.

O Linode é um excelente cloud, só que peca nesse quesito, quando você atrasa algum pagamento como todo servidor de serviço, a cobrança é rápida e à galope, porém na hora de resolver problemas sérios como esses, a resposta costuma ser demorada nos passos da tartaruga.

Novamente reiniciamos a instancia e nossos recursos continuam usando apenas 26.7% do disco.

linode_usage

É grande assim? O software que roda não, mais os acessos sim, por exemplo mês passado em dezembro tivemos 312.459 pageviews contra 183.345 visitantes únicos. A média está sendo entre 130 mil visitas únicas e 150 mil visitas únicas.

Se você tem algum software no linode, conte-nos sua experiência nos comentários.

Fica a máxima, Uma googlada no assunto “linode disk I/O”, você vai ver que tem muita gente no mesmo barco e as vezes você fica tão fascinado pelo cloud, que acaba esquendo que não é nas núvens e sim no velho e bom hardware de VPS.

Notícias/ Phonegap

Campus party 2013 – Phonegap e depois do Flash Player

campusparty2013

E pela terceira vez consecutiva vou palestrar no Campus Party 2013, sempre na arena pitágoras as palestras desse ano vou falar de dois assuntos que tem dominado minha atenção nos últimos 14 meses, que é Phonegap e as reviravoltas da Adobe com o Flash Player.

O Campus party tem uma energia muito positiva e que todo desenvolvedor/geek/ fantático por informática é aconselhado ir sempre. Tem de tudo um pouco, esse ano eles inovaram mais ainda com vários desafios de programação, pitch para apresentação de sua start-up, é o lugar ideal para se começar o ano de 2013.

São várias arenas, e mais de 500 horas de atividades durante o período de 28 de Janeiro à 02 de Fevereiro.

Galileu (Astronomia, Hardware, Modding, Eletrônica, Robótica, Biotecnologia, Nanotecnologia e GreenTech)
Michelangelo (Design, Fotografia, Vídeo e Música)
Gutenberg (Mídias Sociais e Blog)
Pitágoras (Desenvolvimento)
Sócrates (Software Livre e Sistemas operacionais)
Arquimedes (Segurança, Redes e Hack)
Hypatia (Empreendedorismo)
Stadium (Games e Simulação)

As palestras serão no palco Pitágoras, sendo essas:

Criando Apps para várias plataformas e mantendo a lucidez ( 1 de Fevereiro as 21:20)
Descrição: Com tanta plataforma mobile disponível no mercado e o poder de compra do brasileiro aumentando vários ninchos de públicos foram nascendo.
Tendo mais da metade da população brasileira subindo de classe C para B, esses ninchos trazem um público totalmente novo para a plataforma móvel.
O Brasil hoje tem cerca de 25% de sua população usando smartphones de diversas marcas e consequentemente diversas plataformas.
Manter um App apenas para uma plataforma é o primeiro passo para cometer erro de estratégia, outro erro bastante comum é esquecer as escolhas de futuros
clientes de seu negócio que não usam a plataforma que você tem disponível para seu App.
Vamos ver juntos cada detalhe de como o PhoneGap pode ajudar seu time pequeno e com pouco recurso alavancar novas Apps para N Lojas em um intervalo de tempo
comercialmente viável. Compartilharemos cada acerto e erro que aprendemos em nosso dia-a-dia.


Depois do Flash Player, o navegador se tornou nossa segunda caixa de areia
( 1 de Fevereiro as 11:15)
Descrição: Com o avançado dos navegadores impulsionados pela frenética atualização que o Google Chrome possui, a internet ficou mais dinâmica, linda e mais aberta.
A Adobe mudou toda sua estratégia de negócio, abandando literalmente o Flash Player da plataforma Móvel e seguindo o futuro da escolha do mercado o HTML5.
Essa palestra é voltada para você desenvolvedor Actionscript 3.0/Flash/Flex que usou e usa até hoje seus conhecimentos para essa plataforma, Depois de passar 10 anos escrevendo software para o Flash Player, irei mostrar como você pode tirar proveito de toda essa mudança e reviravolta, adaptando-se as novas escolhas do mercado e usando seu conhecimento adquirido para implementar seus novos produtos com HTML5.

Mais detalhes você pode acessar aqui.

 

Phonegap

Chamando todos para conhecer o diretório de desenvolvedores Phonegap

2013-01-14_0007

phonegap_diretorio

Aqui vai meu pedido para todos os desenvolvedores de apps móveis com Phonegap, cadastrem-se no diretório de desenvolvedores e seja conhecido. A grande vantagem desses diretórios de desenvolvedor é empresas contratarem sua empresa ou você para criar Apps com a ferramenta, e até a própria empresa a Nitobi te indica para clientes locais no Brasil.

Esse é o caso da A RIACycle que acabamos de fechar mais 1 projetinho móvel através do diretório, e tudo que funciona nós indicamos. Porém a presença brasileira ainda é tímida, faça parte da lista e ajude-se a ser visto.

Você só é visto se faz propaganda, essa é sua hora de fazer seu jabá para o mundo todo aproveitando o canal dado pelo Phonegap. Quero ver aquilo ali ficar cheio de brasileiro.

Cadastre-se people.phonegap.com

Aproveite e cadastre-se no grupo de discussão Phonegap Brasileiro

Android/ ios/ Pessoal

Android Alerta: Cuidado com que o seu dispositivo envia quando está conectado

android_malware

android_malware

Quando se trata de celular, eu sou cético em sair instalando tudo que tem por ai, por mais gratuito e bem polído o aplicativo seja. Quando sobra aquele tempo eu investigo  um pouco a mais o que o app trás. E pasmem, Todos os Apps que eu baixo 2 em cada 5 querem os meus dados como ‘lista de contatos’, última localização válida, quais serviços estão sendo executados no exato momento.

Mesmo o Google com uma batalha de gato e rato e implementando novas coisas, mesmo assim tais Apps são só descobertos se você desconfiar.

Se você tem um Android, você tem a grande facilidade de monitorar isso com maior clareza, já que você é responsável pelos seus dados e toda fabricante (Apple/Google/Microsoft/RIM) afirma, você é quem deve dizer se deixa ou não acessar tais informações.

Ontem eu queria instalar um App grátis no meu Android, para manter a descrição intácta e preservar os autores, digamos que ela seja uma to-do-list. É sempre bom ficar de olho na concorrência e para minha surpresa, mesmo não pedindo autorização a lista de contatos a App tinha um serviço para tal coleta. Acreditem ou não o App faz duas instalações do aparelho, 1 que é o app propriamente dito e outra é o serviço.

Afim de estudar um pouco à mais essa perceção de captura de dados eu começei a debugar o Aparelho, mesmo com o .apk inacessível você consegue ver os serviços em questão e ver o que eles rodam.

Você pega o ADB e começa a dedilhar o que é exposto, mesmo assim não dá para saber muita coisa além do nome do serviço rodando que você também pode ver direto do Android.

Pesquisei como capturar o tráfego e o que estava saíndo do Android, e acabei com esse link que indico para você baixar e testar em seu próprio aparelho.

No final das contas, realmente o App copiava meus contatos apenas com e-mails, enviava minhas últimas coordenadas de GPS válidas e algumas variáveis métricas para saber que aparelho eu estava utilizando. Ficando apenas o ponto crítico e imoral de coletar meus dados pessoais.

Fiquem espertos com muita vantagem! Cabe a você fazer tais denúncias.