A ideia agrada-me. Como dizem num dos vídeos, em alguns casos as pessoas apenas usam o browser, e se não tiverem internet nem sequer ligam o computador. Isto é o padrão de uso de muitas pessoas que conheço. Única excepção: Office, mas porque não conhecem o Google Docs, porque o que fazem seria perfeitamente comportável pelo Google Docs. Outra excepção: anti-vírus, anti-spyware, firewall e os spyware e worms, mas aqui ficamos a ganhar.

A ideia agrada-me. É o computador como electrodoméstico a alimentar-se apenas da web. Zero de manutenção, muito pouco de configuração. O pouco que se destina a fazer, deve fazê-lo bem. E pelo facto de correr Webkit, é um grande win. Tudo o que tire market share ao IE é positivo, mesmo que seja belzebu a lançar um browser novo.

Para quem quer correr a tralha toda habitual, procure noutro lado. Não é para isso que se destina este OS. As pessoas não têm pouca necessidade de apps locais se as versões web funcionarem bem. Ver o caso do email: conheço pessoas que mesmo conhecendo clientes de email locais, preferem o interface do GMail. Idem para leitores de RSS. Com o Youtube deixou de ser tão necessário ter player locais, mais a confusão de codecs, para ver um vídeo recebido por email. A vida das pessoas que não vivem para os computadores centra-se na web há muito tempo, e este OS posiciona-se para ser o motor de um segundo computador. Para muitos funcioará bem também como computador primário. Que interessa ter as fotos catalogadas no computador, com backups, se servem apenas para alimentar o Facebook?

A questão de ter o Google a lançar isto é também positiva. É uma marca forte, em que as pessoas confiam e de que gostam. Ao contrário do que tentam fazer Gnome e KDE, não tentam imitar o Windows ou o OSX, evitando o problema do uncanny valley.

Penso que a Microsoft tem motivos para ter medo. A Apple tem alguns, mas menos: posicionam-se num segmento de mercado mais alto, além de já terem algo semelhante (o iPhone OS). Será que a haver resposta da Apple, será o afamado iTablet?

Me likes.

Já tinha tentado aprender Cocoa umas quantas vezes mas por falta de utilidade nunca avancei da fase do tutorial. Quando me voltava a dar vontade lá tinha que começar a aprendizagem do zero ou quase.

Desta vez está a ser diferente, a começar pelo uso que pretendo dar aos meus conhecimentos. Uma ideia de uma aplicação que não sendo revolucionária, pode ser útil. Pelo menos, está a servir para de uma assentada aprender 2 tecnologias de que sou um grande curioso: Cocoa/Objective C e Ruby on Rails.

A ideia em si é básica: um programa e serviço web para sincronizar as Stickies, a app de Post-Its que vem com o OS X. Sincronizar entre vários computadores e fornecer um interface web de onde se podem consultar e manipular as notas.

Desde já aviso que também uso o Evernote, mas falta-lhe a simplicidade dos Stickies. Uso o Stickies para notas a curto-prazo, relegando para o Evernote o armazenamento de notas a longo prazo.

A base de dados do Stickies não usa Core Data (um sqlite disfarçado que seria trivial abrir), mas num formato serializado do Cocoa que me deu algumas dores de cabeça a descobrir como as ler, mas que já está desvendado. Já consigo acrescentar/remover notas e gravar no mesmo formato sem problemas de maior. Já tenho o programa a correr num ícone na barra de menu, com uma janela de preferências, a habitual janela de About e o sempre mui útil “Quit”. Ainda não sincroniza, mas depois do trabalho deste fim de semana prolongado já não estou muito longe de o fazer com um simples serviço de “eco” para não complicar.

Para o lado servidor, ainda estou a zero mas tenho andado a ler nas calmas o “Rails for PHP Programmers” que me foi oferecido pelo meu amigo Sérgio. Na prática nunca viu o livro: como ele já não se encontrava na Codebits para receber o prémio pelo seu excelente “Nagalhães”, fui eu quem subiu ao palco para o receber e tive que escolher do então já pequeno monte de prémios 2 livros. Já havia muito pouca coisa e escolhi 2 de Rails. Para a próxima tens que ficar mais abaixo na tabela para teres mais escolha, ok?

Já andei a brincar com o Django (e gostei) mas este livro tem sido um mimo e apetece-me por em prática o que tenho aprendido.

E como temos a abeirar-se mais um fim de semana prolongado, de hoje a 8 dias espero ter para mostrar mais que uma simples foto…

O futuro das web apps?

Via DF.

Coisas que vejo no dia a dia no trabalho ou vou vendo nos sites que visito (claro que vou cuscar o source). Alguns problemas fundamentais, outros detalhes menores, mas que se podem encontrar sem ser preciso procurar muito.

Sem pretender ofender o trabalho de ninguém que também tenho a minha quota de azelhices (podem começar neste blog) e uma pessoa vai aprendendo com o tempo, não é verdade?

Inicialmente este texto era focado naquilo que se faz em Portugal, mas cedo abandonei a ideia. Há por aí HTML+CSS com muita qualidade a ser debitado por portugueses e também muita asneira feita por estrangeiros. Nem todos os bifes são o [http://en.wikipedia.org/wiki/Zeldman](Jeffrey_Zeldman) assim como nem todos os portugueses são o Chico que vende sites feitos no Frontpage.

#### HTML

- As tabelas continuam vivas e de saúde, infelizmente. Os velhos hábitos custam a morrer mesmo com soluções melhores. Há efeitos que é complicado fazer sem tabelas (alinhamentos verticais, por exemplo), mas não há desculpa para ainda se usar tabelas.
- Atributos das tags não delimitados, estruturas inválidas (elementos block dentro de elementos inline).
- Divitis: Quando o DIV é a resposta para todos os problemas, a pergunta não foi compreendida.

#### CSS

- Usa-se CSS, mas mal. Muitas vezes apenas para FAC (Fonts And Colors), ou corre-se tudo a DIVs com classes de nome “bold”, “titulo”, “link”.
- Não é necessário definir para todas as tags o font-family/font-size. Define-se uma vez para o body e basta para a maior parte das situações. Pelo menos façam uma regra “p, div, span, a, table, td, th” para aplicar num único sítio a fonte predominante em vez de repetir as propriedades da fonte para cada tag/id/classe.
- Selectores de contexto. Em vez de definir que os links dentro de um determinado elemento têm uma determinada formatação, corre-se tudo com classes e IDs compostos (a.sidebarContentGroupLink {}). O IE é muito mau, mas pelo menos compreende selectores de contexto simples (para o exemplo anterior, algo como #sidebar .group a {} ).
- IDs repetidos (hint: é para isso que as classes existem).

#### Flash

- Recurso a Flash e Javascript para coisas simples como menus e links de navegação, quando não mesmo para sites inteiros.
- Scrolling do conteúdo feito em Flash, cada qual com a sua implementação, usualmente avariada, em que as coisas não funcionam como se esperam normalmente.

#### Javascript

- Javascript da idade da pedra. window.layers, document.nomedoform.field, doc.write() em XHTML. O Google é vosso amigo, mas neste tema afastem-se dos primeiros resultados da pesquisa, a não ser que sejam um link para o [http://www.jquery.com](jQuery).
- Tal como indicado para Flash, as inúmeras macaquices que se vêem com o scrolling do conteúdo em Javascript, que não funciona, ou não funciona de forma intuitiva ou com lacunas (não suportar scrolling com a roda do rato, por exemplo).

#### Vários

- Frames! Argh!!!
- Confusão com o encoding dos caracteres. Envia-se latin1 quando o o header ou a metatag indicam UTF-8. Strings que são processadas por funções que não compreendem as sequências UTF-8 e e mutilam caracteres (hint: em php usar as funções mb_* em vez das simples como o substr, strlen, etc).
- site.com deve ir ter ao mesmo sítio que www.site.com. Acontece mais vezes do que julgam.
- Usar XHTML por tudo e por nada, sem se perceber o que se ganha em relação ao HTML4.
- Há várias tags que não são muito utilizadas mas são importantes. Label, optgroup, fieldset+legend, até mesmo os h1..h6.
- Não se usam [sprites](http://www.alistapart.com/articles/sprites). Continua-a a recorer ao velho script de pre-load de imagens (copiado do *I feel lucky* do Google…), ou deixa-se o utilizador esperar o carregamento da imagem do menu quando passa o rato por cima.
- UPDATE: em páginas com mais do que um formulário, carregar em Enter após se preencher os dados faz o submit do formulário errado, normalmente o primeiro da página.