Importante: até a data de criação desta postagem, para o recurso getUserMedia() é necessário que esteja utilizando um navegador com suporte “beta” ao mesmo, como Google Chrome Canary ou Opera Labs Camera

Caso escolha o Google Chrome Canary, digite na barra de endereços about:flags, habilite a opção ”Enable MediaStream” e reinicie o navegador

Andei estudando sobre getUserMedia e resolvi compartilhar o que tenho aprendido.

Trata-se da maneira em que o HTML captura recursos de mídia locais como câmera e microfone.

Hoje em dia apenas alguns browsers possuem este recurso disponível (como mostrado no caniuse.com) mas, com certeza, é algo que em breve estará disponível em todos os navegadores, devido a chamada WebRTC (explicado no final do texto).

Exemplo de uso do getUserMedia()

No markup do documento:

1

<video id="cameraCapture">Seu navegador não suporta este tipo de tecnologia</video>

No final do arquivo, antes de </body> e dentro de uma tag <script> (o código está comentado para facilitar o entendimento):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

document.addEventListener('DOMContentLoaded', function(){

  // salvando o elemento #cameraCapture na variável video
  var video = document.querySelector('#cameraCapture');
  video.autoplay = true;

  // testando suporte do navegador ao getUserMedia
  navigator.getUserMedia = navigator.getUserMedia || navigator.webkitGetUserMedia
  if (navigator.getUserMedia) {

      navigator.getUserMedia('video', isSupported, handleError);
      // funcao executada caso haja suporte
      function isSupported(stream) {
          if (window.webkitURL) {
                  video.src = window.webkitURL.createObjectURL(stream);
          } else {
                  video.src = stream;
          }
      }

      // caso haja erro, sera tratado aqui
      function handleError(error) {
          console.error('Erro: [CODE ' + error.code + ']');
          return;
      }

  } else {
      // caso o navegador não suporte, tratar aqui
      console.log('Este navegador não suporta getUserMedia.');
      return;
  }

});

Você pode ver a demonstração do código acima clicando aqui. (caso esteja usando um dos navegadores que suportam getUserMedia).

Aplicações e maneiras de uso

A maioria dos exemplos que estão aparecendo pelo pessoal do chamado “Creative Programming” com uso do getUserMedia baseia-se em uma premissa: canvas.

Eles fazem toda a manipulação capturando a imagem da câmera, transportando ela para um elemento canvas e fazendo toda a manipulação do bitmap como se fosse uma imagem estática. Também começaram a aparecer exemplos utilizando webGL + getUserMedia, como este experimento do Paul Neave: HTML5 Webcam Toy.

Pensando desta maneira, é possível ter uma gama imensa.

WebRTC

WebRTC é um esforço/projeto aberto que tem como foco a realização da comunicação em tempo real (Real Time Communication) através de chamadas simples de APIs Javascript.

Este assunto é está sendo extremamente difundido hoje, mas desde outubro de 2012 o tópico é abordado (rtc-web.alvestrand.com / pessoas/empresas envolvidas).

Bem como disse no post abaixo sobre minha palestra no SampaJS, aqui está o vídeo da mesma.

Infelizmente a parte de perguntas e respostas não está no vídeo, onde acredito que sempre seja a melhor hora. O vídeo está escuro, a iluminação do local tinha que ser baixa para os slides ficarem visíveis, mas juro que sou eu :)

Espero que gostem.

Slides: Page Visibility - SampaJS

Um link foi amplamente divulgado sobre o processo de deploy automático usando git, feito por Thiago Belem.

Abaixo irei mostrar como faço meus deploys e também como é meu workflow, considero um pouco mais simples por lidar com menos configurações do git.

Requisitos

1. Conta no Github
2. Acesso SSH ao servidor de publicação
3. Ter a ferramenta do git instalada em ambiente local e servidor

Workflow

Git

Como dito no post O Que Uso, versiono meu código no Github e trabalho com, no mínimo, dois branches.

1. master
2. web (as vezes)
3. dev

Onde: O branch master fica com a versão estável do código, bug free.

O branch web, quando uso, fica com a versão atual publicada do projeto, mas na maioria das vezes utilizo o branch master para isso, uma vez que ele tem a versão estável da aplicação. As vezes eu também faço as vezes do ambiente de staging com este branch, publicando seu conteúdo em uma área restrita, para testes.

O branch dev é sempre o atual, onde todo o desenvolvimento é feito depois é feito o merge com o web ou master.

Como faço meu deploy

Temos as informações seguintes:

• Projeto: Presentations
• Domínio: example.com
• Pasta de publicação: presentations/

Antes de criar um novo branch, vamos criar um arquivo chamado pullTheContent.php (no caso do meu exemplo). O conteúdo deste arquivo deve ser o seguinte:

1

<?php `git pull`; ?>

Logo após, vamos fazer commit e push das informações.

1
2

[local] $ git add .
[local] $ git commit -am "Adicionando arquivo de deploy automático"

Considerando que o repositório git já está instalado e configurado corretamente, com apenas o branch master (que é o padrão), vamos criar o branch dev e configurar tudo.

Para criar o novo branch, faça:

1

[local] $ git branch dev

Nenhuma mensagem será dada como feedback, isso significa que seu branch foi criado com sucesso.

Para passar do branch master para o dev, você deve fazer:

1

[local] $ git checkout dev

Então, trabalho neste branch até que esteja pronto para ser considerado pronto.

É quando faço merge do branch master com o dev e faço push.

O próximo passo é criar um Service Hook no site do Github, da seguinte forma:

Acesse seu repositório via Github e clique em Admin (ao lado do nome do repositório)

Depois disso, no menu (do lado direito) existem 4 opções: Options, Collaborators, Service Hooks e Deploy Keys. Clique em Service Hooks e, logo depois, escolha Post-Receive URLs. Preencha o campo URL com a URL do arquivo PHP que criamos acima (que ficará na raiz da aplicação).

Feito isso, acessamos nosso servidor via SSH da seguinte forma:

1

[local] $ ssh usuario@example.com

Considerando que já está no servidor, vá até a pasta raiz da aplicação e clone o projeto do Github da seguinte forma:

1

[server] $ git clone git@github.com:username/repo.git

Pronto. Já temos o ambiente configurado e, toda vez que você fizer um push com atualizações em seu branch master, o Github irá executar o PHP do servidor, que por sua vez fará automaticamente um git pull, trazendo todas as atualizações.

Hoje li um post que Allen Cheung escreveu sobre o porque Javascript é prazeroso pra ele. Pedi autorização para traduzir para português e repassar, onde ele diz de forma didática, o porque. Fiz isso porque concordo plenamente com todo o post :)

Eu, provavelmente, sou um pouco tendencioso - ser um desenvolvedor front-end por alguns anos fez isso - mas eu realmente gosto de escrever Javascript. Recentemente me afastei da programação “pura”, mas eutive uma oportunidade na semana passada de voltar a algumas tarefas, e isso me lembrou o quão divertido é mergulhar em nossa(Square) base de código front-end.

Sim, Javascript pode ser surpreendentemente elegante mesmo que completamente enfurecedor, tudo isso na mesma linha de código; durante um bom tempo, era a piada da comunidade de programadores, o “primo pobre” que chega a ser mais feio que o mais bizarro do PHP e Perl. Hoje em dia, JS é uma linguagem sob os holofotes, e ter sido exposto gradativamente a mais desenvolvedores me faz feliz de ter ficado preso a linguagem, verrugas, pús e tudo mais. Aqui está minha tentativa de reunir exatamente o porque eu gosto de trabalhar com Javascript.

Velocidade

O engine de Javascript do Google, V8, faz com que seja possível uma execução rápida do código (tanto no browser quanto nos servidores), e isso melhorou caminho para complexidades e estruturas. Agora, enviamos centenas de kbytes de Javascript minificado para o cliente e esperamos que tudo rode suave. Além de animações aceleradas pelo hardware, aplicativos móveis estão rapidamente alcançando os nativos, em termos de aparência e experiência.

Além do mais, JS é realmente rápido de se escrever e testar. Escreva - salve - atualize(E se for uma página totalmente estática, nem é necessário um servidor); é um ciclo de desenvolvimento absurdamente ágil que nos deixa iterar proporções questionáveis de código muito mais rápido que em qulquer outro ambiente que trabalhei. Com o prontamente disponível (e rápidamente instanciável) console e debugger do webkit, que é um ambiente bem poderoso e produtivo (Então, novamente, eu sou das antigas e uso console.log muito mais do que deveria). Eu também estou me “aquecendo” para começar a usar o Jasmine para testes unitários; tem o conjunto perfeito de ferramentas para lidar com objetos modernos de MVC e ter centenas de testes executados em questão de segundos. Ainda melhor, ter uma solução completa de testes executado e completo é um capricho para melhores práticas com TDD.

Simplicidade

Javascript é uma linguagem “leve” por assim dizer. A lista de palavras reservadas não intimida e existe um conjunto de tipos também nada intimidador, uma vez que você passa pela infeliz fusão automática de “string-number”. JSON se transformou em um formato preferêncial de transferência, exatamente pela sua simplicidade, concisão e facilidade na leitura.

A web tem considerado o Javascript parte de sua linguagem nativa, e existem uma tonelada de outras ferramentas disponíveis, a maioria com setup mínimo. Minha questão favorita numa entrevista é colocar o candidato em frente a um computador com nada alem de um navegador e um editor de textos; não temos apenas o já mencionado navegador e console, mas também temos acesso a APIs, estruturas de dados para interfaces do usuário.

Ainda, eu não gosto de gerenciar versões de GEM, especialmente como pré-requisito para rodar minha instância de dev.

Liberdade

Com simplicidade vem o maior patrimônio do Javascript - a liberdade de programar do jeito que faça sentido pra você e os camaradas malucos que programam contigo.

Talvez, autores de frameworks querem manter os downloads pequenos, ou talvez eles estejam nessa filosofia compartilhada de manter as coisas simples, mas honestamente ainda não achei isso muito popular em libs/frameworks Javascript que os façam acreditar em seus sistemas, o mesmo com Rails, Django e CakePHP, configurando convenções estritas para seus respectivos frameworks (Sencha e Sproutcore são os únicos que me lembre agora. Cappuccino não conta). Os mais populares (ex. jQuery, Underscore.js, Backbone.js) além de serem completamente legíveis, mantidos e ter uma base de código limpa, limita seu escopo ativamente. Eles são projetados para fazer algumas coisas e felizmente são interoperáveis.

Um tema que surgiu sobre frameworks que eu tenho usado em ambos os lados (cliente e servidor) que é inevitável, eu reluto em lidar com convenções forçadas que quebram um ou mais problemas de interesse. Sou forçado a descer para camadas de abstração, buscando aquela atribuição da variável que eu desfaço novamente ao topo da pilha do software. Tanto corrigindo middleware no Pylons, controlando estruturas DOM em widgets GWT ou tunando alguns modals do Win32, ekes são significantes para começar mas oneram na sua cara, requisitos não tão convencionais.

Maleabilidade

Existe algumas verdades para a felicidade apagar um código: isso reduz a complexidade, arruma bugs e diminui o “footprint” da manutenção.

Então, de uma maneira estranha, sou feliz do jeito meio bagunçado que escrevo Javascript as vezes, mas isso tende a não durar muito. Por natureza, código front-end tem uma vida curta: páginas são reprojetadas, testes A/B melhoram em uma curta sucessão e minha dolorosa implementação de um carrossel pode não ter lugar num novo design. A natureza modular do Javascript me deixa refatorar um widget que não existe sen ter que provocar tipos hierárquicos e “desmetaprogramar” funções classe. É especialmente fácil quando tenho alguns testes dando apoio para o procedimento.

Sério, isso é tudo. Mais fácil para escrever que desescrever, Javascript é prazeroso.

Você pode ver o post original no blog de Allen Cheung.

Ontém participei da segunda edição do SampaJS e, pela segunda vez, tive um retorno ótimo do pessoal que prestigiou.

Agradeço ao Suissa pelo convite e aos patrocinadores.

Aqui, o link para os slides da minha apresentação e, assim que for disponibilizado, posto o vídeo.

Baseado no meu post anterior sobre minha migração do TextMate para o Sublime Text, resolvi fazer este post, dizendo o que uso.

O hardware que uso

Em casa eu tenho um MacBook Pro de 13” (i7) com 500GB de disco para desenvolver, 8GB de RAM. Tenho também um monitor Samsumg de 21” que está desligado (acabei de me mudar e ainda estou organizando minhas coisas). Também tenho um MacBook Pro 13” (Core 2 Duo) com 8GB ligado na TV da sala como media center e pra ensaiar apresentações. Mas meu grande companheiro é um Bose QuietConfort 15.

Para testes mobile tenho um iPad 2 16GB WiFi (iOS 5.1), um iPhone 4S (iOS 5.1) e um Nexus S (Android ICS).

Para leitura, tenho um Kindle e acho muito melhor ler nele que no iPad. Por questão da iluminação.

Softwares?

Antes de mais nada, Terminal.

Para trabalho, uso como editor o Sublime Text 2 (contei sobre minha migração do TextMate para o Sublime neste post).

Como servidor, o que mais uso é Apache e comecei a usar o NodeJS, não faz muito tempo.

Outra ferramenta que recomendo para programadores front end é o LiveReload. Se você usa mais de uma tela (e/ou uma tela, grande) ele agiliza muito e evita cmd(alt)+tab/cmd(ctrl)+r. Ele fica “escutando” a pasta que você especifíca e, quando o timestamp de algum arquivo muda, ele pede pro navegador atualizar a página automaticamente. Se você fizer alterações no CSS, ele altera de forma assíncrona.

Meu navegador principal é o Chrome Stable, o secundário é o Opera Stable, mas testo meus projetos no Chrome Canary, Firefox Stable e Aurora, Opera Next, Safari, Opera Mobile e o iOS Simulator do SDK da Apple.

Para recursos novos, uso o WebKit Nightly e alguns builds especiais que Opera lança (como o que habilita getUserMedia(), por exemplo). Utilizo também uma VM do Windows 7 no VirtualBox com Internet Explorer 7, IE 8, IE 9, Opera, Firefox e Chrome.

Para versionamento, Git. Tenho uma conta “Small” no github há um ano, que me da direito de ter 10 repositórios privados, 5 colaboradores privados e 1.2GB de hospedagem.

Utilizo Gyazo para screenshots (mas usava o cl.ly antes, que é uma boa opção pra quem nao tem hosting).

Para anotações, uso o Notational Velocity (que mantém tudo sincronizado entre meus devices, com uma conta no SimpleNote).

E-mail, utilizo GMail e, para as contas de meus projetos, Google Apps.

Assisto vídeos usando VLC. Música ouço no iTunes (com iTunes Match) e mantenho meus arquivos e documentos sincronizados com o Dropbox e Google Docs. Para armazendar fotos, ainda uso uma conta pro do Flickr que expira em uma semana, mas estou quase passando tudo pro Google+/Picasa.

Qual seria o equipamento “dos sonhos”?

A única coisa que eu gostaria de ter além do meu equipamento, é um Apple Thunderbolt Display. E, se um dia sobrar dinheiro, um MacBook Air dedicado para apresentações.

E acho que, melhor do que um equipamento dos sonhos, tenho uma “vista” dos sonhos, que é essa:

Este post segue o modelo do site usesthis

Depois de anos usando o TextMate, decidi olhar para outro editor. Tenho notado muita gente falando coisas muito boas sobre o Sublime Text 2. Foi então que comecei a dar atenção a este que hoje é meu principal editor. O TextMate estava bom, supria minhas necessidades. Estava afinado pro que eu preciso, com meus snippets e customs. Mas foi então que assisti a um vídeo/post do Andrey Tarantsov sobre o workflow usado por ele que me impressionou. Procurando mais informações, fiquei ainda mais impressionado e são estes fatores que irei dizer agora.

O que eu tinha

Eu usava o TextMate. Paguei €39 na época e é o mesmo preço até hoje. Isso da ~R$90,00. Eu tinha vários snippets com templates comuns que eu usava com alguma frequência. Fora customizações de fonte, espaçamento, linguagens e tudo mais. Mas havia um porém: sempre que eu atualizava algo em casa, não se propagava pro trabalho. Quando troquei meu computador e instalei tudo do zero, até hoje ficou um pouco diferente. Sei que existem maneiras de migrar tudo, mas na troca do computador eu queria começar tudo do zero em termos de instalação. Não queria que nada viesse “herdado”. Sem lógica, mas foi uma coisa minha.

O que me atraiu

Vendo o vídeo citado acima e algumas outras demos/vídeos/páginas falando sobre o editor, resolvi dar uma chance. Baixei o trial.

Tenho uma certa resistência com coisas novas, que podem substituir elementos do meu dia-a-dia, da minha rotina. Usei ele por um dia e tinha certeza que era isso que eu queria.

O fato de eu poder configurar tudo em um arquivo JSON-like é fantástico. E ele separa configurações do seu “core” e as personalizações que eu quero. Exemplo: ele usa como padrão 4 espaços para tabulações, mas eu gosto de 2. Ao invés de alterar uma configuração do editor, eu digo pro editor como eu gosto, sem mudar nada do padrão dele. Como se fosse um “user profile”. E isso funciona com tudo, de preferências do sistema até atalhos de teclado, passando por snippets, plugins e o que mais precisar.

Ele também tem uma feature ótima chamada “minimap”. Trata-se de uma miniatura do seu documento inteiro, que fica “fixed”, do lado direito. Ao lado da barra de rolagem (e também funciona como tal). Por ele você pode identificar “chuncks” de código num mero bater de olho.

A navegação dentro dos arquivos também é prazerosa. Você pode fazer a navegação no CSS, por exemplo, por elementos, apertando CMD+R e navegando em um “combo box” que se abre no topo do documento. Fácil assim.

Como uso hoje

A foto acima ilustra mostra como é meu workspace hoje no trabalho.

• iMac 21.5” (1920 x 1080)
• Dual Screen: Dell 17” vertical (1024 x 1280)

Como navegador de desenvolvimento, uso Chrome Stable, testando sempre com Chrome Canary, Opera, Opera Next, Opera Mobile, Firefox, Mozilla Aurora, Safari e WebKit Nightly e Internet Explorer 8 (+ compat. mode 7). Além de testar em iOS 5.1 e Android ICS.

O meu arquivo de preferências pessoais ainda é pequeno, mas o interessante é que no diretório do Sublime, eu deixei um link simbólico para o arquivo, que fica no Dropbox. Assim as alterações que faço aqui, se propagam para o editor de casa e vice-versa.

Meu arquivo de configurações pessoas, por exemplo, notem a simplicidade:

1
2
3
4
5
6
7
8

{
    "color_scheme": "Packages/Color Scheme - Default/Solarized (Dark).tmTheme",
    "draw_white_space": "all",
    "font_size": 15.0,
    "tab_size": 2,
    "find_selected_text": true,
    "word_wrap": false
}

Links

Se você quiser alguns links com referências sobre o Sublime, recomendo que siga minha tag no Delicious. Ainda tem pouca coisa, mas garanto que o que tem é extremamente útil.

Em tempo, preço que paguei pelo Sublime foi de US$ 59,00 (~R$105). Preço compatível com o do TextMate e acho que vale a pena depois de testar.

O mês é março e me parece que todo mundo resolveu acordar e dizer que localStorage não é bom para performance.

A mais nova “polemiquinha” é a de que localStorage é um inimigo da performance. Eu decidi fazer um post baseado em tweets que pessoas que sigo e sabem o que falam postaram. Pra ser mais exato, depois desta mensagem do Mike Taylor:

Honestly, are people *actually* abusing localStorage or is everyone just freaking out in the name of performance™?

— Mike Taylor (@miketaylr) March 8, 2012

Pensem neste post como se fosse uma história em quadrinhos (com H, porque realmente aconteceu). Eu ajeitei tudo na cronologia que me faz mais sentido.

Local storage is broken and there is no viable solution right now - the spec needs to mature - mzl.la/yb4IbP

— Christian Heilmann(@codepo8) March 5, 2012

Is localStorage bad for performance? A quick chat with @codepo8: netm.ag/wwxipM

— netmag (@netmag) March 5, 2012

localStorage vs. cookies - please help by running this benchmark. jsperf.com/localstorage-v…

— Nicholas C. Zakas (@slicknet) March 8, 2012

@johnallsopp @DamonOehlman @garazi @codepo8 As with most APIs, performance alone isn’t an issue, it’s how and when you use the API.

— Nicholas C. Zakas (@slicknet) March 8, 2012

New blog post: In defense of localStorage nczonline.net/blog/2012/03/0…

— Nicholas C. Zakas (@slicknet) March 8, 2012

img.dnl.bz/f33ea0.png /cc @miketaylr

— Daniel Filho (@danielfilho) March 8, 2012

Finalizando

É óbvio que não espero que ninguém construa uma solução fazendo uso massivo de localStorage, e ele não está aí pra isso. No meu ponto de vista, ele veio como uma melhoria significativa de recursos precários como, por exemplo, cookies.

Estou numa época de aprendizado e não espero abandonar essa fase tão cedo.

Como venho pesquisando muito sobre Front End e tentando me envolver mais com projetos open-source e, até mesmo, buscando novidades assim que o grupo de estudos da W3C define ou faz release de algum rascunho novo, resolvi fazer um post para ajudar quem também está querendo estudar e se envolver na comunidade de desenvolvimento.

1) O básico

Inglês. Se você quer ficar por dentro de tudo que está acontecendo neste momento, é imprescindível que, antes de mais nada, você tenha ao menos uma boa leitura. Os estudos e redações dos principais documentos são feitos por pessoas do mundo inteiro: India, Brasil, Reino Unido, Holanda, Bélgica, Estados Unidos etc.

Para os que não possuem um inglês tão afiado, ferramentas online de tradução podem ajudar bastante na hora de tirar uma dúvida. Quando necessário, faço uso do Google Translator.

Uma outra boa explicação é que, todos os códigos escritos no Front End são em inglês. HEAD, HEADER, BODY, SECTION, LI (list item), UL (unordered list), WIDTH, WEIGHT, POSITION, entre outras. Facilita (e muito) a compreensão de cada um dos itens acima quando se entende o que eles querem dizer.

2) Por onde começar?

Assumindo que você já tem um inglês bom o suficiente para ler documentações. Acredito que hoje, o melhor material de referência pra quem está começando seja o projeto ”Move The Web Forward”, que lista fontes e recursos.

Se você gosta de ler livros e quer focar em JavaScript, ainda recomendo primeiramente o livro ”Eloquent JavaScript”, do autor Marijn Haverbeke. No link, você pode ler o livro online ou baixar o mesmo, compactado.

Depois desse, recomendo “JavaScript: The Good Parts”, do autor e famoso “Douglas Crockford”. Este livro pode ser encontrado em português.

Relacionado a performance de páginas, recomendo a leitura do livro “High Performance Websites”, do autor “Steve Souders”. Autoridade nessa área, foi um dos criadores do Y!Slow (ferramenta de medição de performance de websites) enquanto trabalhava no Yahoo!, e atualmente, trabalha como “Web Performance Engineer” no Google.

3) Se envolvendo em projetos open-source

Para começar  a se envolver em projetos open-source, uma coisa é imprescindível hoje: saber utilizar git) e uma conta no github.

Para entender os fundamentos básicos, Roger Dudler fez um tutorial bem legal e educativo sobre o Git. Vale a pena.

Se ainda tiver alguma dúvida, não hesite em perguntar nos comentários. Ficarei feliz em ajudar :)

No dia 19 de novembro de 2011 fiz um talk, a convite do Suissa, na primeira edição do SampaJS, sobre “A Web Desconectada”.

Trata-se da especificação do HTML5 que torna o conteúdo de páginas e aplicativos online acessível, mesmo quando sem conexão de dados, via cache interno do dispositivo.

Vocês podem acompanhar a palestra sincronizada com os slides, ou se prefirir, apenas os slides.

No próximo dia 17 de março haverá a segunda edição do SampaJS, o qual tive o privilégio de ser convidado novamente. Desta vez, irei falar sobre uma das mais recentes especificações do HTML5, a Page Visibility.

As inscrições serão abertas em breve para um número limitado de participantes. Vocês podem me seguir no twitter, onde irei avisar assim que tivermos o formulário liberado.