funmachine


Deixe um comentário

An Open Web

Esta força toda que tem surgido em torno do movimento Open Web tem pouco a ver com uma perspetiva puramente técnica de desenvolvimento com tecnologia Web – HTML5 e JS e CSS, etc. É muito mais que isso. Para quem desenvolve para a web no dia a dia, percebe facilmente que ainda estamos muito longe de ter tecnologia completamente agnóstica que corre em qualquer dispositivo de forma nativa. Podemos correr web apps em qualquer browser, que por sua vez existem em qualquer SO, mas ainda estamos muito longe de ter uma integração ideal a nível dos recursos do SO.

Quem tentar criar uma aplicação puramente baseada em tecnologia Web, mas que possa correr, por exemplo, num ambiente desktop, percebe bem a questão….. Não existe forma fácil de, por exemplo, criar uma aplicação chromeless, sem fazer uso dos UIs do browser. Correr em modo Fullscreen não é solução e muito menos correr em frameworks como PhoneGap, que apenas permitem correr uma aplicação web dentro de um rudimentar widget web, com muitas limitações ao nível das funcionalidades suportadas, para não falar na limitação de performance.

Além disso, mais restritivo que desenvolver uma aplicação chromeless é desenvolver uma que faça uso dos recursos do sistema operativo, e apesar de haver grande progressos nessa área (FileSystem API, Local Storage API, etc) ainda estamos longe de ter acesso aos recursos que, por exemplo, as SDK windows, mac, android, iOS nos permitem.

Para mim, frameworks como PhoneGap são uma faca de dois legumes, como o grande treinador dizia… Por um lado prometem desenvolvimento rápido e cross-platform, o que é verdade. Mas por outro, correm a app web em cima de um widget rudimentar, que é disponibilizado pelas SDKs do iOS, do Android, etc., como uma simples view para criar interfaces web simples. Depois os developers passam o seu tempo a tentar otimizar a performance da app…

Por outro lado temos os browsers. Autêntica artilharia pesada. Conseguem alta performance, mas é muito difícil sair do contexto browser, ou seja, é difícil implementar uma aplicação chromeless. É possível integrar apenas os seus layout e render engines? Sim, podemos usar o Gecko, WebKit, etc e embeber num software nosso, mas não é tarefa fácil. Existe um projecto chamado CEF que não é mais que uma API para embeber o Chromium em virtualmente qualquer aplicação. Depois existe uma série de projetos para embeber o Gecko, o motor do Firefox, mas que infelizmente, são sempre abandonados… Por fim existe um projeto chamado Awesomium que é uma framework que permite tirar partido do browser (Chromium/WebKit) para criar aplicações windowless, mas sendo algo comercial e fechado, acabamos sempre sem saber bem em que versão do browser nos podemos basear, nunca temos a certeza que funcionalidades suportam no futuro nem quanto tempo demoram a integrar as evoluções do WebKit (se é que o fazem).

Agora, temos o renascer do gigante. A Mozilla, que tem grande responsabilidade pela web tal como a conhecemos, voltou em força e está atualmente a puxar novamente as fronteiras da web!

A Mozilla está em força com a iniciativa Open Web. Ao longo dos últimos tempos têm tentado estender os web standards para incluir uma série de APIs necessárias para desenvolver aplicações em sistemas móveis que realmente fazem uso nativo do SO. Vejam aqui uma compilação das APIs que estão a ser desenvolvidas.

O primeiro é o projecto Boot To Gecko – B2G , onde estão a desenvolver um sistema operativo mobile baseado no projeto Gecko e que tem como principal novidade as aplicações nativas em aplicações HTML5/JS. Desta forma podemos desenvolver aplicações usando tecnologia HTML5 e JS e ter acesso a um conjunto de recursos do sistema operativo, ou seja, a Mozilla quer tornar a Open Web como uma plataforma para um sistema mobile.

Depois temos a iniciativa Open Web Apps. A Mozilla finalmente vai lançar o seu Web Apps Marketplace, um local onde podemos encontrar, comprar e fazer download de aplicações Web. Um pouco semelhante ao Google Web Apps, mas com a inovação e “passo à frente” que tem sido a bandeira da Mozilla. O funcionamento é muito semelhante às Web Apps Chrome. Temos um MarketPlace onde podemos distribuir  e gerir aplicações Web. O passo à frente nesta iniciativa é o WebRT – Web Run Time:

“Desktop WebRT is a project to build a desktop web application runtime that provides webapps with a native-like look and feel along with platform integration APIs on Windows, Mac, and other desktop platforms.”

A ideia é que ao instalar a Web App existe uma funcionalidade do Firefox que instala a aplicação no sistema operativo nativo e depois podemos correr a aplicação nativamente. Esta ao ser executada corre como se fosse no Firefox, mas num ambiente chromeless.

Estou ansioso por verificar como está plataforma vai desenvolver ao longo do tempo, à muito que ando à procura de uma forma de desenvolver aplicação desktop usando tecnologias Web, principalmente na parte das UIs, com todo o poder dos browsers modernos actuais, e a iniciativa Open Web da Mozilla, particularmente o projecto B2G e WebRT prometem isso mesmo!


Deixe um comentário

Python + VirtualEnv

Tenho trabalhado ultimamente com a framework web Django e um dos maiores problemas com que tenho lidado ocorre quando por algum motivo preciso correr a framework noutro ambiente, por exemplo noutro PC. Ao contrário do desenvolvimento PHP, onde tipicamente temos uma stack estanque com todos os módulos PHP necessários, em Python e particularmente em Django, as coisas são um pouco diferentes. A verdade é que à medida que vamos desenvolvendo vamos também instalando uma série de módulos e dependências que depois precisamos de replicar se quisermos correr o ambiente de desenvolvimento sem problema. Mas nesse processo vários inconvenientes podem acontecer, caso a versão do Python usada originalmente para o projeto seja diferente da que temos instalada na máquina de destino, ou se alguns módulos tiverem também versões diferentes. Poderíamos simplesmente atualizar a versão do Python e dos módulos necessários para a que o nosso projeto utiliza, mas aí os outros projetos podem deixar de funcionar! Se, pelo contrário, deixarmos as versões que temos no sistema, então aí pode o projeto que queremos migrar não correr!

Claro que já muita gente se deparou com uma situação destas, e a solução para gerir este inferno de versões e dependências é utilizar Virtual Environments. A ideia é muito simples: utilizamos um software que cria virtual envs na nosso máquina é nos permite alternar entre eles. Enquanto estivermos com um virtual env activado, todos os módulos Python instalados ficam associados a esse virtual env. Simples!

Vamos então aprender mais um pouco sobre um dos softwares que podemos utilizar para criar Virtual Environments em Python, chamado (naturalmente) VirtualEnv.

Para instalar o VirtualEnv podem usar a ferramenta easy_install:

$ easy_install virtualenv

Depois de instalado com sucesso, podem criar um ambiente virtual com o seguinte comando:

$ virtualenv my_venv

Com este comando é criado um ambiente virtual já com as packages base Python, ou seja, todas as global site-packages Python que tinham instalado anteriormente são herdadas, incluindo o próprio Python!

Caso queiram criar um VirtualEnv “vazio” usem o comando:

$ virtualenv  –no-site-packages my_venv

Isto pode ser útil para, por exemplo, criar um VirtualEnv com uma versão diferente Python da global.

Depois de criado o VirtualEnv, podemos ativá-lo usando o comando:

$ source my-venv/bin/activate

Desta forma, estamos a trabalhar neste VirtualEnv. Qualquer tarefa Python que usem vai usar este VirtualEnv. Notem como aparece o nome do VirtualEnv na consola.

Agora queremos instalar uma package Python neste VirtualEnv. Para isso, com o VirtualEnv activado, simplesmente usamos o easy_install (ou outra ferramenta de instalação de packages Python):

$(my_venv) easy_install yolk

A assim o yolk é instalado no VirtualEnv “my_venv”.

Quando quisermos sair de um VirtualEnv, simplesmente usamos o comando:

$(my_venv) deactivate

Simples, não? Uma pequena nota: o yolk, entre outras coisas, serve para sabermos quais os packages Python que temos instalados. Se correrem o comando:

$(my_venv) yolk -l

são listadas todas as packages e suas versões que atualmente estão instaladas no ambiente virtual ativo, neste caso “my_venv”. Se nenhum ambiente virtual estiver ativo então são listadas as packages globais.

Ok, temos o nosso trabalho simplificado, podemos criar VirtualEnv facilmente, e se depois quisermos correr um projeto noutro ambiente de desenvolvimento, basta recriar o VirtualEnv. Além disso, há outra tarefa que fica simplificada – testar novas versões de packages! Basta criar um virtualenv novo e instalar as novas versões e verificar como o nosso programa funciona com as novas versões. A qualquer momento podemos voltar ao ambiente estável, bastando trocar de VirtualEnv.

Mas este processo de gerir as dependências do nosso projeto ainda não é perfeito! Recriar VirtualEnvs dá trabalho, temos que saber quais as packages instaladas e voltar a instalar tudo de novo! O yolk facilita o trabalho, mas ainda assim acho que precisa ser mais automático! A solução é simples também: vamos criar um script Python que trata de instalar por nós as dependências!

Criem um ficheiro Python com este código:

import virtualenv, textwrap
output = virtualenv.create_bootstrap_script(textwrap.dedent("""
def after_install(options, home_dir):
    subprocess.call([join(home_dir, 'bin', 'easy_install'),
                    'yolk'])
"""))
print output

Gravem o ficheiro, por exemplo, como main.py

No terminal, corram:

$ python main.py > install-venv.py

E depois corram o ficheiro Python resultante com o nome do VirtualEnv que querem recriar como parâmetro:

$ python install-venv.py my_venv

Et voilá! Este script trata de criar o VirtualEnv my_venv, com todas packages que quisermos instalar! (neste exemplo apenas yolk)


Deixe um comentário

Mobile Web Development

Lembro-me de discussões acesas de há uns anos atrás, sobre a guerra Web Apps vs. Native Apps no mundo mobile, e de como a perceção era de que o futuro seria Web App. Podemos discutir e listar todas as vantagens e desvantagens de um conceito sobre o outro e vamos encontrar sem dúvida vários argumentos onde podemos fanaticamente defender o nosso ponto de vista:

Browser:

  1. Um único esforço de desenvolvimento, contra desenvolver para uma série de plataformas (iOS, Android, W7, etc).
  2. Manutenção facilitada, um update no servidor e as mudanças introduzidas estão disponíveis para todos os utilizadores.

Nativa:

  1. Look and Feel nativo, permite fornecer uma experiência de utilização mais standard (e como isto tem importância num iAparelho).
  2. Disponível a partir das AppStores, que são pontos importantes de disseminação das aplicações.
  3. Acesso aos recursos dos dispositivos (acelerómetro, câmara, GPS, etc).
  4. Acesso e utilização Offline.

Esta lista está certamente bastante incompleta mas a ideia também não é espremer as vantagens de uma e outra abordagem.Na minha opinião, a solução Browser tem ganho cada vez mais pontos a favor, devido em grande parte à tecnologia HTML5 que veio preencher uns vazios que até então eram críticos:

  • Com HTML5 podemos ter aplicações offline, usando por exemplo local storage.
  • Podemos obter informações de localização.
  • Podemos criar o look and feel adequado ao dispositivo devido ao CSS3 e HTML5.

No entanto, as aplicações nativas têm tido um grande sucesso, e para mim existem três grandes razões, e que no fundo são as grandes diferenças atuais entre aplicações Browser e Nativas:

  • As AppStores que são um canal de distribuição enorme e massificado.
  • Os recursos do SO disponíveis são maiores e portanto podemos oferecer melhores experiências de utilização e funcionalidades até únicas, que nem sequer podem ser implementadas numa aplicação browser.
  • A aplicação está instalada, facilmente acessível através dos menus de apps dos dispositivos.
Apesar de no passado ter a minha opinião bem fincado, atualmente o mundo mobile está tão presente nas nossas vidas que as decisões não podem incidir sobre questões tecnológicas e fanatismos sobre web app contra native app, a verdade é que a questão é puramente de negócio e se queremos lançar uma aplicação mobile no mercado temos que perceber o contexto dessa aplicação. Apesar de um ponto de vista técnico termos que o fazer, não devemos nunca decidir por um dos lados só porque simplesmente “o que um lado nos oferece é suficiente”, ou porque “estou mais à vontade com tecnologias web”. É fundamental perceber o negócio onde a aplicação vai encaixar. Uma questão interessante é apontada neste post, onde é exposto o propósito de utilização. O autor defende que as apps nativas tem uma utilização lean-back ao passo que as browser têm uma utilização lean-forward, ou seja, numa aplicação browser nós estamos essencialmente a pesquisar e navegar em informação ao passo que numa aplicação nativa estamos numa experiência mais imersiva, aproveitando a integração do dispositivo com sensores, câmaras, etc. Para mim faz bastante sentido, apesar de cada vez menos estas diferenças serem sentidas.
Um pequeno exemplo que podemos analisar é uma loja online. Para mim faz tudo o sentido que seja desenvolvido sobre um conceito browser. Primeiro porque, à partida, já deve existir uma plataforma de suporte (a loja online) assente sobre tecnologia web. Depois porque implica um propósito de utilização de pesquisa, navegação por conteúdos. Depois existem uma série de razões de pormenor: não é necessário recursos do dispositivo, a experiência do utilizador também não é à partida o ponto mais essencial e com tecnologia HTML5 e CSS3 já estamos muito (mesmo muito) bem servidos nesse aspeto. No entanto, estará disposto um cliente a perder o potencial de captação que as AppStores, principalmente da Apple e Android, têm para oferecer? São milhares de pessoal que todos os dias pesquisam e navegam à procura de aplicações para os seus telemóveis ou tablets! Neste caso, poderíamos considerar também desenvolver versões nativas! E assim cai por terra a discussão inicial onde tentamos perceber as vantagens de um conceito sobre o outro! Isto leva-me a pensar em arquiteturas mais complexas, APIs e serviços Web onde no fundo temos que esquecer os clientes, podem ser qualquer coisa, browser, nativa, não interessa, o importante é fornecer recursos que estes possam utilizar para alimentar conteúdos e interações.
Concluindo, não penso que qualquer resposta dada esteja errada, seja Browser, Nativa ou as duas, com certeza somos criativos a enumerar argumentos de suporte. A questão não é certamente qual o melhor conceito de um ponto tão purista, a decisão tem que partir com o negócio, o utilizadores e um contexto de utilização em mente, só assim encontramos a melhor resposta. Só os utilizadores irão no futuro dar resposta a esta questão (se é que algum dia vão dar). No entanto é interessante verificar que ao longo destes anos as diferenças entre os conceito browser e nativo são cada vez menores, ainda existem com certeza, mas a linha que os separa é cada vez mais ténue.


Deixe um comentário

HTML5 – Aplicações Offline: AppCache

Antes de começar este artigo, podem fazer download deste projecto. É uma simples aplicação HTML5 que funciona de modo offline e serve para poderem seguir o artigo. No entanto, não precisam de usar o projecto para perceber o que a seguir vamos falar, apenas serve como uma referência e é um ponto de partida para fazerem as vossas aplicações offline.

O que é a AppCache

AppCache é um mecanismo do HTML5 que permite que o programador indique explicitamente ao browser quais os recursos da sua aplicação web que devem ser guardados persistentemente em cache, de forma que a aplicação funcione mesmo sem acesso à internet, isto é, que funcione em modo offline.
O processo para tornar uma aplicação offline é na sua essência bastante simples:

  1. Criar um ficheiro manifest .appcache onde indicamos os recursos que devem ser mantidos na appcache.
  2. Certificarmos que o servidor consegue servir documentos do tipo .appcache
  3. Incluir um ficheiro .appcache em cada página da aplicação, usando o atributo manifest da tag html.

O ficheiro manifest

O ficheiro manifest deve conter então todos os recursos que queremos colocar em cache, segue um exemplo:

CACHE MANIFEST
# ficheiros a colocar em cache
script.js
style.css
img/logo.png

Neste caso indicamos ao browser que script.js, style.css e img/logo.png são recursos que queremos disponíveis offline.
Podemos no entanto indicar outro tipo de regras no ficheiro com os seguintes headers:
CACHE: ficheiros a colocar em cache
NETWORK: ficheiros que nunca devem ficar em cache. O browser lança um erro se tentar carregar estes ficheiros em modo offline.
FALLBACK: Que ficheiro carregar não caso o browser em modo offline não encontre a página na appcache.

Se não indicarmos nenhum header no ficheiro manifest, como o exemplo acima, é considerada uma secção explícita, isto é, o header CACHE.

Vejamos então o seguinte exemplo:
CACHE MANIFEST
CACHE:
script.js
style.css
img/logo.png

NETWORK:
check.php

FALLBACK:
/ /offline.html

Neste caso, acontece o seguinte:

  • script.js, style.css e img/logo.png são enviados para a appcache, e dessa forma, disponíveis offline.
  • O script check.php não fica em appcache, deve ser sempre carregado da rede.
  • Caso o browser não consiga carregar a página em modo offline, é mostrada a página offline.html. A “/” antes de offline faz com que qualquer URL pattern corresponda ao procurar o ficheiro offline.html.

Criar ficheiro appcache para uma aplicação estática é trivial, mas a maior parte das vezes queremos que estes sejam dinâmicos, ou seja, dependendo da página que estamos a servir, os recursos que queremos offline podem variar, e podem ser tantos (p.e. a pasta de imagens) que se torna demorado escrever este ficheiros à mão. Para isso existem algumas ferramentas que criam ficheiros .appcache de forma automática. Por exemplo, esta ferramenta cria o ficheiro manifest baseado na página que estámos a visualizar no browser.

Adicionar o ficheiro manifest

Depois de criar o ficheiro manifest precisamos incluir em cada página que quisermos servir. Isto é importante, não podemos simplesmente incluir o manifest na nossa “Home Page” e não incluir nas restantes, pois nesse caso apenas a “Home Page” ficava em cache.
Para incluir o ficheiro manifest numa página, inserimos o seguinte na tag html da página:
<html manifest=”app.appcache”>

Servir ficheiros manifest

Agora precisamos por fim certificar que o nosso servidor consegue servir estes ficheiros com extensão .appcache. Uma forma simples de o fazer é criar um ficheiro .htaccess e adicionar a seguinte linha:

AddType text/cache-manifest .appcache

E é isto, agora o nosso servidor Apache consegue servir ficheiros .appcache. Atenção que se não se certificarem que os ficheiros .appcache estão a ser servidos, a nossa aplicação nunca vai funcionar offline.

Testar aplicações offline pode tornar-se frustrante porque assim que o browser coloca recursos em cache, eles não voltam a ser carregar do servidor, mesmo em modo online.
Existem apenas três caso em que browser tenta carregar novamente recursos que estão em cache:

  1. O utilizador limpou a cache.
  2. O ficheiro manifest foi alterado.
  3. A cache foi alterada via javascript.

Portanto, já testar alterações nos ficheiros em cache existe uma solução simples, alterar o ficheiro manifest! Basta uma pequena alteração como adicionar/editar um comentário.

 

 

AppCache Debug

Existem algumas formas para fazer debug da appcache:
No chrome, utilizar o “Resources Panel”, lá encontram informação sobre o estado da Application Cache.

No chrome, navegar até chrome://appcache-internals/, podemos então ver quais as aplicações que estão a utilizar appcache e até remover da cache.

No entanto fazer debug da appcache não é fácil, os recursos são muito limitado.
Existem também problemas com a appcache em si. Tem uma API muito limitada que não permite fazer muito, não existe forma, por exemplo, de saber se determinado recurso que estamos a trabalhar está em cache ou não, assim como não existe forma de limpar a cache programaticamente.
A appcache tem uma natureza transacional, isto é, ou está completamente carregada ou completamente vazia, desta forma é impossível parar o download e resumir, não existe controlo sobre o estado do download do recursos.
Outro problema é o facto de se utilizar um ficheiro manifest por página, sendo impossível criar grupos de recursos para colocar em appcache. (Existem alguns hacks no entanto, usando iframes)

Existe ainda muito mais para falar sobre appcache, como alterar a cache com javascript ou detectar suporte appcache nos browsers, mas para já ficamos por esta introdução base. Assim que houver mais assuntos para falar este artigos será actualizado!

Para testarem um exemplo podem fazer download deste projecto.


2 comentários

HTML 5 – As novas tags

Mais um artigo da colecção HTML5, desta vez sobre as principais tags HTML5.

HTML5 – Introdução

HTML5 – As novas tags

O DocType

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">

Isto é o doctype! Deve ser sempre a primeira linha de qualquer documento HTML e serve para indicar ao browser qual a versão do HTML em que o documento está escrito. Existem dezenas de doctypes, que podem fazer o browser “entender” o HTML de diferentes formas. Daí, é importante usar um doctype que faça o browser correr num modo standard. Por exemplo, o doctype acima – XHML 1.0 Strict – contem todos os elementos e atributos HTML, mas NÃO INCLUI elementos de apresentação ou obsoletos (como tag font). Frames também não são permitidos e o HTML tem que ser escrito como um XML válido.
Não existe nenhum problema em continuar a usar este tipo de DocType, mas porque não usar o novo DocType HTML5 que é mais pequeno, legível e faz os todos os browsers recentes correr em modo standard:

<!DOCTYPE HTML>

O elemento Header

Supõe que precisas criar um cabeçalho e algumas secções para uma página HTML:

</pre>
<div id="header">
<h1>O meu Site</h1>
 Não tenho a certeza o que escrever aqui...</div>
<pre>

Não existe nenhum problema em continuar a usar esta estrutura, é HTML5 válido de qualquer forma. Mas uma novidade do HTML5 é que fornece alguns elementos adicionais para usar como cabeçalhos e secções em páginas Web.

Vamos então começar por analisar o cabeçalho (a div com id header). Apesar de comum, está estrutura não representa nada, o browser não faz ideia que isto se trata de uma secção “header”, nos enquanto “programadores” é que reconhecemos este padrão como uma estrutura de cabeçalho. O HTML5 define um elemento <header>, na nossa página podíamos reescrever da seguinte forma:

<header>
<h1>O meu Site</h1>

 Não tenho a certeza o que escrever aqui...</header>

Navegação

Na génese dos documentos HTML está a navegação, afinal é por existir navegação numa página web que podemos navegar de umas páginas para outras, de documento em documento. Tipicamente, referimos a navegação de um website como um “menu”. A estrutura mais comum para criar um menu é recorrendo a listas HTML:

</pre>
<ul>
	<li><a href="#">Home</a></li>
	<li><a href="#">Blog</a></li>
	<li><a href="#">Acerca</a></li>
	<li><a href="#">Contactos</a></li>
</ul>
<pre>

Utilizar listas é válido, mas traz um problema, não existe forma de saber que determinada lista se refere ao menu do website. Imagem uma pessoa com dificuldades visuais, que usa um software text-to-speech para “ler” uma página web. O software carrega a página HTML e “lê” o site, permitindo que a pessoa ouça o que está escrito. Se não identificarmos o menu explicitamente, o software não tem forma conveniente de saber que existe um menu principal onde a pessoa pode navegar para diferentes secção do site. Se existir uma forma de identificar o menu de navegação do site, o software pode facilmente apresentar à pessoa quais os links disponíveis para navegar:

<nav>
<ul>
	<li><a href="#">Home</a></li>
	<li><a href="#">Blog</a></li>
	<li><a href="#">Acerca</a></li>
	<li><a href="#">Contactos</a></li>
</ul>
</nav>

Secções

O elemento <section> pode ser visto como um contentor para uma parte significativa de uma página web, da mesma forma que num livro, um capítulo engloba uma secção significativa do livro.
Usar o elemento <section> é uma forma eficiente de organizar e separar o conteúdo numa página Web. Por exemplo, em vez de criar uma lista de artigos independentes numa página web, ou englobar numa tag <div> sem qualquer significado, podemos usar o elemento <section>.

<section>
<div>
<h1>Title</h1>

Lorem Ipsum si dolore... ... ...</div>
</section>

Como podemos começar a perceber, tags como <nav>, <section> não têm por objectivo fornecer nenhumas funcionalidades novas, trata-se mais de permitir dar significado ao conteúdo que escrevemos.

Hgroup

O elemento <hgroup> representa o cabeçalho de uma secção. É utilizado para agrupar os vários elementos <h> (h1… … h6) que eventualmente fazem parte do cabeçalho.

<hgroup>
<h1>Lorem ipsum si dolore</h1>
<h2>Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Donec molestie. Sed aliquam sem ut arcu.</h2>
</hgroup>

Artigos

</pre>
<div>28 de Março de 2012
<h2>  <a href="#"> Nova Entrada </a></h2>
 Lorem ipsum si dolore... ... ..</div>
<pre>

Em relação a div com a class “entrada”, podemos perceber esta estrutura como um artigo numa página, um grupo de elementos que em conjunto formam um artigo num website, por exemplo, uma lista de posts num blog, ou uma lista de notícias, ou até mesmo um único post ou notícia numa página de um website.

Mais uma vez, não existe problema algum em utilizar esta estrutura, é HTML5 válido! Mas o HTML5 introduz um novo elemento que permite organizar de uma forma mais clara um artigo numa página:

<article>
<h4>28 de Março de 2012</h4>

Lorem ipsum si dolore ... ... ...</article>

A tag <article> permite organizar um artigo numa página.

Datas e Hora

O elemento <time> permite facilmente identificar datas dentro de documentos HTML5:

<time datetime=”2012-03-28″ pubdate=””>28 de Março de 2012 </time>

Existem três componentes da tag <time>:

●      Machine-readable timestamp

●      Componente de texto Human-readable

●      Uma flag opcional pubdate

O timestamp pode indicar a data (como no exemplo) mas também podemos adicionar a hora, desta forma:

<time datetime=”2012-03-28T13:32:56″ pubdate=””>28 de Março de 2012</time>

O componente de texto pode ser qualquer coisa, não precisa de indicar uma data específica, pode ser algo como: “Á 5 minutos” ou até mesmo nada! A flag pubdate pode significar uma de duas, se a tag <time> está dentro de uma tag <article> indica que o artigo foi publicado naquela data e hora. Se a tag <time> não está dentro de uma tag <article> significa que o documento foi publicado na data e hora especificado na tag.

Footers

Imaginem o seguinte rodapé:

</pre>
<div>
<div id="FooterTwo">© 2012 HTML5 - Basic Tags</div>
<div id="FooterTree">HTML5, para MTM - <a href="http://www.epb.pt">EPB</a></div>
</div>
<pre>

Tipicamente encontramos este tipo de rodapés em página HTML, mas mais uma vez o HTML5 define um elemento específico para rodapés <footer>:

<footer>
<div>
<div id="FooterTwo">© 2012 HTML5 - Basic Tags</div>
<div id="FooterTree">HTML5, para MTM - <a href="http://www.epb.pt">EPB</a></div>
</div>
</footer>

Normalmente o footer contem informações sobre quem é o autor do web site, links para documentos relacionados, informações de copyright, etc.
O tipo de elementos que podemos inserir dentro de um footer não é definido à partida, pode fazer sentido criar um footer como o de cima, ou então, em casos de footers com mais conteúdos, podemos por exemplo criar secção <nav> dentro do elemento <footer>.

Aside

O objectivo deste elemento é designar conteúdo que está relacionado mas não faz parte do conteúdo principal da página. Podemos ver o <aside> como as notas que por vezes aparecem nos livros ou website: referências para artigos relacionados, curiosidades sobre o conteúdo, etc. Todo isso está relacionado com o conteúdo, apesar de não fazer parte do mesmo.

<article>
Lorem ipsum si dolore... ...
<aside>
<h1>lorem ipsum</h1>
Lorem ipsum si dolore... ... ...</aside></article>

Dialog

O elemento <dialog> permite identificar conversações numa página web, pode portanto, ser particularmente interessante para criar comentários e respostas a comentários.
Dentro do <dialog> temos ainda disponíveis os seguintes elementos:

  • <dt> para identificar o autor
  • <dd> para identificar o texto em si

Abel SoaresAqui está um conversa usando o elemento dialogJonh SmithParece interessante

Figure

Inserir imagens numa página web é uma tarefa rotineira para qualquer pessoa que desenvolve aplicações web.
Mais complicado é identificar a imagem e o texto associado a esta.
O HTML5 define o elemento <figure> que nos permite inserir imagens e conteúdos associados neste elemento.

<figure>
<legend>Figure 12. Using the FIGURE element </legend>
 <img src="“figure_element.jpg”" alt="“The" width="“240”/" height="“140”" border="“0”" /></figure>

Associado ou elemento <figure> temos o elemento <legend>. Como o próprio nome indica é um elemento html onde podemos definir a legenda da imagem.

HTML5 – Introdução

HTML5 – As novas tags



1 Comentário

HTML 5 – Introdução

Vou tentar escrever vários artigos sobre features HTML5 que acho particularmente interessantes e creio que no fim teremos um guia bastante completo sobre HTML5.

HTML5 – Introdução

HTML5 – As novas tags

Para já, segue uma pequena introdução ao HTML5, começando por simplesmente responder à questão “mas afinal, o que é o HTML5?”.

O HTML5 não pode ser visto como uma única tecnologia nem uma simples evolução do HTML4.  Como podemos ler em HTML5 Rocks: “HMTL5 is not a single thing or a monolithic technology. It is a collection of features, technologies, and APIs that brings the power of the desktop and the vibrancy of multimedia experience to the web—while amplifying the web’s core strengths of interactivity and connectivity.”
O HTML5 fornece novas funcionalidades necessárias para o desenvolvimento de aplicações web modernas e a sua especificação tem sido um esforço de standardizar muitas funcionalidades suportadas por vários browsers, que os web developers têm usado há muito tempo mas que ainda não tiveram a oportunidade de ser standardizadas.
Um browser recente é tudo o que é necessário para começar a desfrutar das vantagens deste novo conjunto de funcionalidades que vieram para ficar e revolucionar a forma como vemos as aplicações web. Caso não tenham a certeza se o vosso browser suporta determinada funcionalidade HTML5, existem vários sites que podem consultar para verificar a compatibilidade do browser, por exemplo findmebyip.com ou caniuse.com Aplicações que antes exigiam o poder e funcionalidades avançadas encontradas nas plataformas desktop estão agora disponíveis em ambiente web, graças à nova versão do HTML, CSS3 e um conjunto de APIs Javascript que fazem parte do “pack” HTML5, abrindo portas a uma nova geração de web apps que conseguem alta performance gráfica e de animação, trabalhar offline e levar a colaboração entre utilizadores a um outro nível.
Nesta série de artigos sobre HTML5 optei por fazer a divisão entre as várias tecnologias que compõem o HTML5: as novas tags HTML, o CSS3 e as APIs Javascript. O próximo artigo é então sobre as principais tags HTML5.


Deixe um comentário

Cache no CakePHP

Sou um grande fã da framework CakePHP e tenho-na usado com sucesso em vários projetos. Apesar de ter uma arquitetura muito bem conseguida que beneficia um tempo de desenvolvimento muito curto, tal vantagem vem com o custo da performance da aplicação. Por isso, apesar de ser muito rápido e fácil desenvolver uma aplicação web com CakePHP, é sempre necessário estar atento para não infligir  facadas na performance durante a programação da aplicação, principalmente nas queries SQL. Além disso existem dicas genéricas para tornar os sites mais rápidos que obviamente também funcionam na framework CakePHP. A própria framework vem com alguns componentes que permitem melhorar a performance da aplicação, que são simples de configurar e permitem facilmente e sem esforço melhorar a resposta da aplicação web. Uma dessas ferramentas é o Helper Cache. Este Helper permite, de uma forma fácil, fazer cache de views e layouts gerados. Sempre que o utilizador faz um pedido, se o layout/view já estiver em cache, o CakePHP envia a página automaticamente, sem necessidade de executar o código que gera a view/layout.

Para configurar este Helper temos que fazer o seguinte:

  • Em app/config/core.php, descomentar a seguinte linha:
Configure::write('Cache.check', true);
  • No controlador onde queremos activar a cache, devemos incluir o Cache Helper:
var helpers = array('Cache');
  • No controlador, definir quando tempo dura a cache (em segundos, ou usando o formato strtotime() ):
var $cacheAction = "1 hour";
  • Se quisermos definir tempos de duração diferentes para cada view (ou só activar a cache para algumas views), devemos configurar a linha anterior da seguinte forma:
var $cacheAction = array(
'view/23' => 21600,
'view/48' => 36000,
'view/52' => 48000
);
  • Se existirem áreas na view que não queremos usar cache, então colocamos essas áreas entre os seguintes blocos:
<cake:nocache> </cake:nocache>

E é tão simples como isto 😉 Para mais informações neste assunto podem consultar a documentação oficial.