pular para o conteúdo [1]

Artigos sobre Front-End e Programação web

Front In POA: Anotações das Palestras

| 0 Comentários

Aconteceu no dia 08 de novembro mais um evento Front In POA. O Evento contou com participantes renomados na área e conhecidos em eventos de Front-End aqui no Brasil.

A organização mandou muito bem ao escolher os assuntos das palestras, ficaram bem variadas, porém nunca fugindo do foco principal do evento que era o desenvolvimento Front-End. Reuni aqui algumas anotações feitas por mim e alguns slides utilizados no evento.

Site oficial do evento: http://frontinpoa.com.br/2014/

Repensando o uso do jQuery

Vinícius Almeida
@vimoding

jQuery é a biblioteca JavaScript mais utilizada no mundo. Porém são raros os debates sobre formas de tirar o melhor proveito da sua API. Vamos começar a mudar esse cenário falando sobre a forma que escrevemos código em cima dos ombros desse gigante.

  • De um tempo para cá começou se contestar o uso do jquery. Pessoal começou procurar alternativas ao jquery. Pelo tamanho da biblioteca, por exemplo.
  • Hoje em dia quase não se fala dos benefícios do jquery. APIs
  • É a mais utilizada no mundo ainda
  • Má fama dos plugins jQuery
  • Escrever componentes na forma de plugins
  • Repetir menos a chamada dos plugins. Usar —-data atributos— para isso. Utilização dos data atributos para inicializar valores no HTML ao invés de iniciar no método data()
  • Usar os data atributos a nosso favor.
  • Usamos colchetes pra pegar os data atributos do html.
  • No lugar de passar true, false… no js passar no html.
  • A vantagem é que temos componentes que se inicializam automaticamente. Assim elevamos o nível do nosso código.
  • mètodo .one()

Link recomendado pelo Palestrante: In search of the perfect JavaScript framework

Slides da palestra:

Saindo da caixa: Um novo workflow para produção de projetos Web

Renatho de Carli
@renatho

Os processos utilizados pelas empresas ainda estão muito focados nos entregáveis tendo como consequência uma forma de trabalho que não faz muito sentido. Entenda como o front-end pode ser utilizado como base para se construir um workflow de produção mais inteligente, lógico e que suporte as necessidades atuais de mercado.

  • Algo diferente da forma que trabalhamos hoje. Tem que sair da caixa pra entender as vantagens desse novo modo de trabalho.
  • As pessoas (cliente) esperam cada vez mais entregas com prazos menores
  • Ajustar preço do projeto à quantidade de desenvolvedores.
  • Processo de desenvolvimento hoje. E o mais usado. 1º Arquitetura da informação. 2º Criação do Design. 3º front-End. 4º Beck- End. Passar o desenho para o Browser(HTML), por cor no desenho (CSS) fazer interação funcionar (Beck-End);
  • Por que se trabalha nesse formato? A maioria trabalha nesse formato porque não conhece outro. Acham que é o padrão do mercado. Normalmente não fazem um estudo do processo de desenvolvimento;
  • Alguns problemas por esse formato de trabalho:
    • Falha na comunicação, falta de integração, falha de comunicação entre equipe e cliente. Profissional não conhece outra setor (designer e beck)
  • Um novo modelo (blue sky).Temos uma margem maior de erro. Podemos errar mais.
  • HTML, CSS, JS. O html já exatamente o que se vai ter nas telas(wrireframe). Então porque não se fazer o wireframe já no HTML. O CSS já é o design.
  • Separação em módulos (conceituais). Não tem o porquê ter uma serie de entregas, que vão se replicando…
  • Mais responsabilidade, pois design vai fazer layout junto do front. Mais envolvimento entre os integrantes.
  • —-Modulo design in the browser—– desenvolver o design direto no navegador. Modulo wireframe in the browser Mais agilidade, não tem que refazer o trabalho. psd para html.
  • Menos conflito entre designer e desenvolvedores.
  • O designer usa o css no lugar do photoshop.
  • Mais organização. O arquiteto da informação já pode dar nome aos módulos.
  • Atomic design pode ser agregado nos outros módulos;
  • Uma coisa que não se deve fazer. Usar classe com o nome de botão amarelo. Não usar. CSS é estilo isso muda. por nome semântico;
  • Módulo de checklist. ter um checklist padrão. Tem várias ferramentas pra isso. web developer checklist. O ideial é você criar a sua
  • html5boilerplate—–
  • Desafio maior pra usar modelo blue sky é mudar a mentalidade. Sair da zona de conforto. Se fosse começar hoje usando isso seria melhor, mas como conhecemos o outro método…

Dados sobre dados: Micro Data e Open Graph

Leonardo Souza
@leobetosouza

Como que um pouquinho de metainformação pode ajudar seu projeto.

  • Nome de quem escreveu já é um meta dado, meta informação…
  • Semântica do HTML pode ser estendida.
  • Já foi usado: microfirmats, rdfa, microdata, open graph
  • Microdata nada mais é que chave e valor.
  • Microdata usamos hoje.
  • Dados linkados, linked data. schema.org
  • HTML5 microdata api
  • Open graph protocol. Criar title só para face por exemplo, title para seo e nessa microda passa o titulo que quer que apareça para o face ao compartilhar.
  • Microdatas não está no cotidiano dos desenvolvedores.

Slides da palestra

O melhor da monitoração de Web Performance

Davidson Fellipe
@davidsonfellipe

Como encarar os desafios da área de web performance e conhecer quais são as melhores ferramentas para auxiliar o desenvolvimento de páginas rápidas e mantê-las rápidas. Além disso, fazer a integração de algumas dessas ferramentas de uma forma fácil para melhorar a compreensão desses indicadores para toda a equipe de desenvolvimento.

  • Para comparar performance temos que ter uma métrica pré definida.
  • Página que aparece por muito tempo branca afeta diretamente a experiência do usuário
  • web performance é user experience
  • 94% do carregamento da página está relacionado à parte do client-side
  • Coisas básicas, concatenar arquivos CSS no header, cache expires…
  • Reduzir request (data-uri, cancatenar CSS, JS, sprites)
  • Usar o pagespeed module
  • Ferramentas que podem ser utilizadas: http://yslow.org/, https://developers.google.com/speed/pagespeed/insights/
  • Link recomendado http://browserdiet.com/pt/, O guia definitivo de performance front-end
  • Automatização para teste de performance usar o plugin pagespeed grunt.
  • Mensure performance

Slides da Palestra:

Javascript ilegível: como um conjunto de decisões afeta seu código

Rafael Specht da Silva
@rafael_sps

Uma abordagem sobre padrões de desenvolvimento javascript: estilo, organização, legibilidade de código e “melhores práticas” (também conhecidas como superstições). Às vezes, pequenos detalhes na concepção de um projeto vão determinar como ele vai crescer. Essa palestra visa discutir e comparar alguns destes ressaltando suas vantagens.

  • Faça seus códigos de forma clara e limpa. Isso facilita a manutenção
  • Escreva seus código pensando em quem dará manutenção
  • Se for para colocar comentários óbvios ou que não dizem nada, melhor não por
  • Coloque nomes em EventHandlers, mais fácil para debugar o script usando as ferramentas do desenvolvedor, pois mostrará o nome
  • “Finja que o programador que trabalha com você é um psicopata que sabe onde você mora”, ou seja, escreva bons códigos…

Slides da plestra:

Design orientado a Código

Giancarlo Vorga Jung
@cntrlx

Hoje em dia, um desenvolvedor front-end precisa manjar de tudo, desde Javascript até Gestalt, entretanto, é possível para um designer adaptar seu processo criativo e suas dinâmicas de trabalho para a web sem precisar embrenhar-se em anos de estudo em linguagens de programação e arquitetura de software. Na talk, serão apresentadas conceitos chaves de programação, rotinas e técnicas que podem ser usadas no dia-a-dia de um designer que tenha pouca, ou nenhuma experiencia, com desenvolvimento web.

  • Dificuldade de relação entre Design e Front-Ends
  • Quem trabalha com web precisa saber programar?
  • Por onde começar Treehouse mais avançado e Coacamy mais basico.
  • Dificuldade em emular programas da adobe, por exemplo, no Linux.
  • Quando o Designer conhece o basico de HTML e CSS ele consegue deixar camadas, grupo de camadas mais organizado para o Front.
  • Usar programas, papel, quadro branco para fazer wireframes
  • devtools do Chrome, firebug boas ferramendas para o aprendizado de designers verem como as coisas funcionam.
  • Gestalt – teoria da boa forma
  • Projeto E
  • Dreamweaver mais atrapalha do que ajuda. (hehe)

O que o front end pode aprender com o Rails

Lucas Mazza
@lucasmazza

O Rails completou 10 anos de vida e diversas lições desses 10 anos podem nos ajudar a construir as fundações para os próximos 10 anos do mundo de front end. Vamos refletir sobre alguns aspectos que ajudaram a stack do framework a evoluir durante os anos e como podemos aplicar isso no mundo de CSS e JS para melhorar as nossas aplicações.

  • Open Source não é só programar. Lucas participa reportando bugs e atualizando a documentação (entrevista antes da palestra)
  • Coisas que a comunidade Rails aplica podem ser aplicadas na comunidade JavaScript também
  • Rail e JavaScript tem dificuldade e soluções semelhantes
  • São inúmeras as APIs

Slides da palestra:

#CSS { styles: oh-yeah; }

Átila Fassina
@atilafassina

CSS é uma linguagem declarativa extremamente permissiva e democrática. Ela dificilmente joga exceções, e permite que um iniciante crie coisas desde os primeiros passos. Mas isso não quer dizer que CSS seja fácil, muito menos que não existem boas práticas. Nesta talk, vamos aprender boas práticas, features pouco usadas que poderiam poupar algum trabalho e até alguns hacks

  • CSS é simples, fácil?
  • bruce lee morreu não treinando, mas tentado estilizar um select
  • (Essa foi muito boa haha)

  • CSS denora um dia pra aprender mas demora uma vida inteira pra dominar.
  • Informações fora do documento :pseudo-classes
  • conteudo que não existe no documento ::pseudo-element
  • Combinações, use os seletores > + ~
  • border-radius com mais de quatro valores existe
  • Não carregar fontes para “bold” ou “italic” (perda de performance)
  • uso de ::before pra forçar carregamento da font foi uma solução em um projeto
  • FontForge para editar arquivos de fonte….
  • Propriedade will-change das CSS(cria stack context no elemento diz ao navegador qual conteúdo otimizar), otimiza processamento nas modificação. Então ponho will-chand em tudo? não né… As vezes otimizar tudo na verdade é não otimizar nada. Não tem como otimizar tudo de uma só vez. Will chante não é instantâneo. Demora um pouco. O ideal se for usar no click de um elemento por exemplo melhor por no hover… Atualmente só funciona no Opera e chrome.

Slides da apresentação:

Componentes
 para a web

Jean Carlo Emer
@jcemer

Uma visão crítica sobre o hype da vez. Esta palestra tem como norte tirar o ruído e fundamentar (inclusive com exemplos) o
 que realmente importa neste papo de componentes.

  • Coleção de padrão. Encapsular, compor e reusar na plataforma web
  • Mais fácil usar classes para estilizar do que criar novos elementos
  • A partir dos componentes podemos criar sistemas mais complexos. Compor pequenas partes para chegar ao maior.
    (Cusstom elements templates shadow dom html import) = components web.
    Derrubando web components, não se assuste…
    Definir elemento não é nada novo. Isso ja era possível no IE6
    esquema.org pra garant que buscadores vão entender melhor.

  • Polymer divulga uso dos web components (projeto do Google). Exemplo: Elemento select que um comportamento diferente do padrão do navegador. Pra que reinventar elementos que já existem?
  • Pra que reinventar elementos, select por exemplo.
  • Por o template no JS não no HTML
  • Não mexer em coisa que nã é tua. Tirar controles de vídeo por exemplo.
  • Iframe tem ainda porque é a unica maneira ainda de isolar código externo.
  • Web componentes ainda não estão prontos para serem usado.
  • Estude outras coisas antes de web components (Shadow DOM , módulos js…)
  • Link para leitura: Why Web Components Aren’t Ready for Production… Yet

Slides da palestra:

Progressive enhancement na prática

Luiz Corte Real
@srsaude

Não sabe o que é progressive enhancement? Ou sabe mas não consegue colocar na prática? Nesta palestra, veremos progressive enhancement numa abordagem prática e abrangente, analisando exemplos de sites reais com problemas comuns. Vamos desmistificar a ideia e ver por que todos deveriam segui-la para construir aplicações mais robustas, acessíveis e fáceis de manter.

  • O problema não é o IE6 nos sites desconfigurados. Pessoa com leitores de tela, problemas motores, baixa visão, mobile… Temos um problema sim.
  • Fazer o site todo bonito depois resolver problemas porque layout quebrou num browser, etc, etc… da uma depressão graceful degradation não é legal. O melhor é começar por cenários mais limitados
  • Primeiro o dever depois o prazer.(Melhoria progressiva)
  • Começar pelo HTML semântico.
  • No CSS começar com aquelas propriedades que funcionam em navegadores mais antigos, propriedade que ainda não tem suporte, etc
  • É muito mais fácil ir evoluindo o layout, pois funciona para todos desde o começo.
  • Mobile first não é apenas para os front, é para todo o projeto.
  • Depende de JavaScript para funcionar? Então cria no JavaScript.
  • Muito importante pensar na sua aplicação offline
  • ====HOODIE web offline—— http://hood.ie/
  • Resumo design mobile first
    • Design mobile-first
    • HTML semântinco funcional…
    • Melhorar com css, fazer media com min-width, recursos mais básicos do CSS, pensar nos navegadores mais antigos primeiro.
    • JS não obstrutivo, pensar nos navegadores antigo primeiro.
    • —-offline first para aplicações web—-

Link dos slides da palestra

Offline Web do jeito certo com Service Workers

Sérgio Lopes
@sergio_caelum

Se você já tentou usar a Application Cache API para suportar offline na Web, deve ter sofrido bastante. A nova especificação dos ServiceWorkers promete revolucionar o desenvolvimento Web com melhor controle de offline e outros truques que veremos nessa palestra.

  • APP cache é chato, limitado e complicado
  • maravilhoso mundo do service workers, é uma api javascript. Tem que ter um ponto de entrada para registrar o funcionamento offline (service workers)
  • Usando workers usuário fecha a a baba mas não o script, como ocorre hoje em dia
  • CACHE API fazer cache de coisas offline
  • Com Service Workers podemos montar scripts para cachear página de acordo com nossas necessidades
  • Evento onactivate é utilizado para ativar o Workers .
  • Service Worker só funciona em HTTPS por causa da criptografia
  • Service Workers não tem ainda uma documentação concluída
  • Para testar podemos usar o Chrome Canary habilitando algumas funcionalidade
  • Esse é o futuro da Web

Slides da palestra

Siga-me no Twitter: @kadunew ou assine nosso Feed e fique por dentro de todas atualizações aqui do blog.

Deixe uma resposta

Campos obrigatórios *.



*

Topo