Irrelefante

Posts sobre desenvolvimento

Em defesa dos navegadores em consoles de videogame

Por alguma razão misteriosa na forma como eu tropeço em links na internet, eu me deparei com dois links que tocam no assunto ultra-específico de navegadores em consoles de videogame.

O primeiro, é esse baita trabalho de pesquisa por Declan Chidlow em documentar a interface desses navegadores, passando por curiosidades como o CD-i e o Apple Pippin até o PlayStation 2 e o Wii — e então pros consoles mais recentes.

Eu sempre gostei do fato do Wii e do 3DS terem navegadores. Eu nunca usei muito eles além da parte em que eles facilitam os hacks para homebrew de ambos os consoles. Porém, eu sempre achei curiosa a forma como a Nintendo e a desenvolvedora responsável por esses navegadores faziam um esforço em usar as capacidades específicas de hardware na navegação. No Wii, era o uso do sensor de movimentos pra controlar o ponteiro; no 3DS, o recurso de duas telas espalhava os controles pela tela de toque enquanto a de cima exibia o conteúdo da página.

Eu me deparei com o segundo link quase que por engano. Em um artigo sobre como construir sites principalmente em HTML melhorou as métricas de visitas de um site tem um link para outro artigo sobre a importância da simplicidade no desenvolvimento para a web. É nesse link que está essa pequena anedota de Terence Eden:

Há alguns anos, eu estava fazendo pesquisa de políticas públicas em um escritório de auxílio-moradia em Londres. São lugares singularmente desagradáveis. As paredes estão repletas de cartazes oferecendo serviços úteis para pessoas que fogem da violência doméstica. Os seguranças na porta demonstram uma indiferença cautelosa a quem entra. O ar é carregado de conversas tensas entre casais, abafadas pelo barulho de crianças gritando.

No meio, tem uma jovem sentada em uma cadeira de plástico rígido. Ela está cercada por sacolas contendo seus pertences. Ela não parece estar em um bom momento. Em suas mãos, ela segura um console de videogame – um PlayStation Portable. Ela o encara intensamente, bloqueando o mundo com Candy Crush.

Ou, pelo menos, era o que eu pensava.

Passando por ela, dou uma olhada em seu console e reconheço a tela em que ela está. Ela está conectada ao Wi-Fi do prédio e navegando nas páginas do GOV.UK sobre Auxílio-Moradia. Ela não está cortando frutas; está se munindo de conhecimento.

O navegador web do PSP é — para dizer o mínimo — [patético]. É lento, frequentemente fica sem memória e só consegue abrir 3 abas simultaneamente.

Mas as páginas do GOV.UK são escritas em HTML simples. Elas são projetadas para serem leves e funcionarem até em navegadores ruins. Precisam funcionar. Isso é para todos.

Desenvolvimento para a web pensando nessas situações sempre foi o que me guiou a desenvolver com HTML antes, scripts depois. Eu morei por muito tempo no interior, no meio do campo, sem acesso à infraestrutura de internet de boa qualidade. Existem limites do que essas conexões conseguem oferecer, e é o nosso trabalho como desenvolvedores esquecer que nossos MacBooks conectados à internet de alta velocidade podem fazer, e lembrar de tudo o que um Moto G de 2018 no interior de, sei lá, Minas Gerais, vai conseguir fazer também. Todo o resto de performance a gente pode usar para melhorar uma experiência. Mas ela já tem que ser boa o suficiente pro usuário com o pior hardware possível.

É um pouco do que me faz querer que o nosso gov.br fosse mais pensado para essa parte da população. A infraestrutura do gov.br é pensada para o melhor hardware possível — mas a parcela de quem vai acessar esses serviços usando o iPhone do ano é mínima.

Tudo isso pra dizer que eu lembro de ter feito um sitezinho na aula de programação no segundo ano do ensino médio e ter testado ela usando o navegador do Wii. Foi mágico usar o Wii Remote para apertar em botões que eu mesmo desenvolvi. Até hoje essas pequenas felicidades de programação me impulsionam pra seguir em frente.

Encanamento

Tava lendo esse artigo no Unsung sobre a estrutura de URLs do Flickr, e essa continuação com links sobre “design de URLs”.

Eu acho muito bonita a forma com que o Flickr, o Last.FM e o Letterboxd trabalham suas URLs. Eu gosto de digitar os endereços dos sites que eu visito — foi assim que eu aprendi a navegar na internet —, e esses sites permitem que a gente descubra as coisas mais bacanas misturando e explorando suas URLs. O que acontece se eu trocar uma geotag no Flickr, ou misturar os gêneros no Last.FM, ou até mesmo filtrar os filmes que meu amigo assistiu por país? Eu posso fazer toda essa descoberta só observando e trocando caminhos.

Enquanto eu tava redesenhando o meu site eu tava pensando nessa estrutura de URLs, e como eu queria possibilitar esse tipo de descoberta. Com o tempo, eu espero que esse site vire uma verdadeira “floresta” em que eu possa me perder em tags e links por aí. Pra isso, eu preciso reorganizar essas tags, criar um jardim, etc.

Mas uma dessas tarefas foi pensar em uma estrutura de URLs, e tendo lido recentemente o texto no Unsung eu me peguei reestruturando as URLs do site pra começar a possibilitar esse tipo de descoberta.

Por regra geral, os posts agora estão organizados assim:

/categoria/ano/mês/dia/nome-do-post/

As tags são fáceis:

/tags/nome-da-tag/

Uma hora eu quero fazer o /tags/ ser um mapa gráfico das relações entre as tags aqui do site.

Se você acessa uma página de categoria (ex. /notas/), você vê o arquivo daquela categoria. Anos, meses e dias também podem ser misturados para navegar por arquivos. Pra acessar os posts de dezembro, você pode navegar pra irrelefante.com.br/2025/12/, e assim por diante.

Eu gosto como fazer esses esquemas de URL, integrar com outros serviços e ver se tudo funciona de uma ponta à outra é como mexer no encanamento do site. E meu site é como minha casa. Até mexer no encanamento e saber que tá tudo bem é uma alegria.

defaults.css

Harry Roberts, o “CSS Wizardry”, criou um novo reset para a “web moderna” que eu tô interessado em testar por aqui. Eu uso o reset.css do Eric Meyer desde que eu comecei a desenvolver. Nunca usei o Normalize.css porque achava um exagero, mas o defaults.css do Roberts parece sucinto e é bem escrito. Achei bem bacana.

A web quieta

Brian Koberlein, em seu blog:

The quiet filter isn’t perfect. There are plenty of quiet sites that use Google Analytics just because it’s an easy way to see if anyone is reading. And some sites pass the test while still having a bombastic style. But the filter does reveal hidden treasures. Sites that are thoughtfully and personally written. There’s often intentionality to them that is refreshing to read. I find my own ideas are challenged more on these sites, and that’s a good thing.

The biggest downside of the quiet web is that it can be difficult to find. You can’t simply Google topics of interest. Instead, you have to dig a bit. Go down rabbit holes until you come across an interesting quiet page. It takes time and effort. It’s easier just to doomscroll on Twitter. But the effort is worthwhile. As you gather more of the quiet web into your readership, you will notice the negative effects of the traditional loud web more. And once you get used to the quiet web, you may never want to go back.

Sobre sites pessoais e a web social

Manuel Moreale, em seu blog:

I still believe the first approach is doomed to fail. Because the issue with social media is not the tech, but the people. If you let enough people congregate in the same space some issues will inevitably arise. Grifters are gonna grift, scammers will try to scam, hustlers will hustle, influencers are gonna try to influence, and business people will try to monetise everything. It’s no surprise that Meta is slowly entering that space with Threads. And I don’t see Meta starting a blog platform next, letting everyone share and connect via RSS. So that alone tells me which approach is more appealing to the exact same entities we’re trying to get away from.

Having said that I’m hopeful. I do think people are slowly starting to realise that you can get immense human value from the web outside of traditional social media. You have to work for it but it’s absolutely worth it.

Porque escolher a web como uma plataforma de jogos

Brandon Dillon, 2weeks:

It’s an exciting time to be working in the space. After a long quiet period following the death of Flash, there are fewer and fewer technical barriers to making great games on the web.

The web can be a really vibrant space for games (as it once was). To make it vibrant, people need better tools. We should have a game development toolkit tailored to the web, and Tweaks can be that toolkit.

História de um site

Shea Fitzpatrick fez um histórico de seu site pessoal, uma galeria que mostra a evolução e transformação de seus gostos e interesses sobre o que fazer com o seu cantinho da internet.

Eu sempre quis fazer algo assim para o meu site pessoal (esse aqui!), mas eu não guardo capturas de tela das várias versões que eu criei pra ele ao longo dos anos. Talvez seja a hora de começar a fazer isso.

(Adorei que compartilhamos o mesmo costume de desenvolver nossos sites no período de uma noite, eu só consigo desenvolver algo pro meu site pessoal ou pro Pão com Mortadela assim).