Celso Martinho

Getting things done - Part II

April 21, 2008

I've posted about personal productivity and GTD recently (in Portuguese) and got a lot of feedback, either from the Blog or other means (thanks all, really). So after a lot of testing and fiddling I think I finally settled with a nice setup which works for me. This post will try to describe it, in English just because the target audience is broader.

First of all a few notes.

Some of this stuff, if not all, might not work for you. Each person has it's own set of characteristics and requirements and, while for some a simple Moleskine or a set of index cards is enough, for others no, not really. So let's start with that, my characteristics.

I'm completely E-Mail centric, it's my primary form of communication and collaboration, it stands above the phone, paper or even real person-to-person interaction. Scary, but true. So consequentially my E-Mail client, now OSX's Mail.app, is undoubtedly my desktop soul mate. My life depends heavily on the complicity I have with this beast. I only used 3 clients in my whole life: elm, mutt (elm on dopes) and Mail.app (SMTP clients that is, I'm excluding UUCP and Fidonet). It took me ages to leave mutt behind even when "powerful" graphical clients were already widely available (like Evolution or Thunderbird). I still use it occasionally. So, when shit like this happens, I stress, a lot. I get hundreds of messages per day, not counting spam.

One other tool I use to communicate professionally is IM. In my case I use the OSX version of the SAPO Messenger (the best XMPP out there, trust me). IM is very ineffective in what comes to GTD, I'll explain this later. Work also comes in other transports: SMS, voice and paper. (No, twitter messaging still doesn't qualify as work, sorry).

My life is mobile. I'm constantly moving from one place to another and my laptop isn't always there. It's meetings, travelling, late night phone calls, weekend interruptions, you name it, it's my sad life. My mobile phone is also one my most important instruments for personal task management and messaging and It has been carefully hand picked since my first Ericsson GA628. I now use an iPhone.

I have multiple contexts in my job. I'm a founder, a manager, a programmer and a sys-admin. These different contexts force me to constantly evaluate my priorities and re-organize my time, my most important (and finite, unfortunately )resource. Also, in each context I have different states. For instance, I might have taken the morning off to fix some bugs and I'll be in a state of concentration and sequencial work, or I might be closing small late tasks and the IM is blinking, my CEO is sending me SMSes and I have a boring meeting in 10 minutes (not related).

Based on this reality, I had several requirements for my setup:

APIs. Sooner or later I'd want to do something funky with my data. Some XML/REST based API for whatever service I'd choose was needed.
Mobility. As I said. I currently use an iPhone which has a decent browser and all but I was aiming a richter integration. A subset of Mobility is Synchronization.
Tight E-Mail integration. IM would be nice.
Syndication. RSS and iCalendar, mainly.
Support for different contexts and status.

And the solution:

Hiveminder:

The core tool I ended up choosing was Hiveminder (thanks to those who referenced it to me). Feature wise Hiveminder is unbeatable. It's Web based and has everything you'd expect from a GTD application plus it provides RSS/Atom and iCalendar feeds, a mobile version of the website (with some iPhone goodies), Twitter integration, Jabber/IM integration (through a jid-bot), SMTP/E-Mail integration and a well documented and simple web API (with OAuth support). Also it supports contexts, groups, scheduled tasks, tags, reports, tinyurls and a small language to add tasks they call braindump.

But the sell point lies in the pro version with their IMAP interface. For a mere well deserved $30 USD/year, Hiveminder provides a virtual IMAP mailbox view to your tasks. But it's not just the fact that you can see your task as normal E-mail messages that's great. What's killer about it is that it has virtual IMAP folders which can be used to mimic real Hiveminder actions as you drag messages to them. For instance, say you a task called "Pay bill" in your Inbox, if you drag this message to the /Actions/Hide for/Days/03 days/ folder, you're actually manipulating the task's properties and delaying the task for 3 days. You have virtual folders to Complete and Hide tasks, groups and special braindump folders for advanced usage.

Add this to the fact I can define personal E-Mail addresses (as many as I want) inside Hiveminder to create specific tasks with specific properties. Think of them as buckets, each one with associated braindump. For instance, I can have zpto1@my.hiveminder.com which is use to create tasks under the tag "work" and another zpto2@my.hiveminder.com for tasks under the tag "personal". Creating a task is as easy as sending (or forwarding) an E-mail to these addresses.

So why is this great? Well, read my characteristics and requirements again. This single feature is a three in one solution. 1. I can still be E-mail centric and manage all my tasks using Mail.app, my E-Mail client. I use Mail.app to create, complete, modify and categorize tasks. 2. Mobility solved. My iPhone (and most modern 2G/3G phones) has a very rich E-mail client, with IMAP. 3. Synchronizations solved. And offline operations too. It's just E-Mail messages and IMAP operations queued and waiting for connectivity.

In fact I don't use the Web version of Hiveminder at all.

Zero Inbox:

Ok, so managing tasks is easy and sleek now. But I still had to figure how to tame my enormous flow of daily E-Mail messages in a productive, integrated and organized way.

Short story short, the Zero Inbox is a simple concept: keep your inbox empty. This may seem trivial (some of my colleagues said to me they've been doing this for years) but it's not that easy if you get an average 50 work related messages a day (I did the math, yes). Problem is, most work related E-Mails require feedback or action. In other words, they require two of your most valuable resources: time and attention. And neither are abundant. Logically if you have no way to handle them as they arrive, they'll just stack up. My last Inbox (the root, not the folders) had a pile of 25.000 messages for the year of 2007, god knows the percentage of unanswered E-Mails it contained and the cause-consequence effects it had on my professional life.

Your Inbox is your desk. If it's not clean it will hunt you with a feeling of personal chaos, and you'll never catch up again until you take expensive drastic measures.

There's lots of advice on how to keep your Inbox zeroed. 43folders has a whole series of related articles on the subject that you can read, they're very popular. I'd suggest you take 50 minutes of your time just watch this video from Merlin Mann.

I followed some general advice and married the concept with Hiveminder. So here's my strategy. To keep my Inbox empty I have to take one of 3 actions for each incoming message:

If it's trash (ie: spam or a result of a cronjob) delete it immediately.
If it's just informative, read and archive. Archiving means moving the messages to the /Archive folder for eternal disregard (ok, and for Spotlight searches too).
If it requires an action (be it just answering the message or doing actual work first) I'll either do it immediately because I have time or, and this is the innovative part, just forward the E-mail to one of Hiveminder's E-Mail addresses, and it will auto-magically create a task with the message's subject. After forwarding the message, I'll just archive it and take it off the Inbox.

The delete/archive/forward decision is simple and fast. It won't steal your concentration from other threads and it's resource inexpensive.

The other tip I have for your regarding E-mail is to change your auto-check to 1 hour periods or more. Receiving an E-mail is an attention sucker. Just the fact that my Dock's icon shows some number of unread E-Mails is enough to lit my curiosity sensors. Which leads me to the next subject:

Instant Messaging

I use IM for ages, both personally and professionally. In the context of work IM is anti-GTD. It's useful for the initiator but very ineffective for the receiver. The sender uses IM to satisfy real-time, casual needs and finds in IM an easy way to get the "victim"'s attention. Now, again, attention may be something the teens have in excess (specially for the oposite sex) but it's not so for most hard working (and married) guys like me. IM is an attention sucker and a concentration assassin.

The other thing I find amusing about the IM is the person's "status". The status is ment to indicate if a person's available to talk, or if he's busy, or away. In the early days of IM this was sort of honored by our tech savvy friends it's true. But today, please, for gods sake, either just remove this stupid property or reduce it to 3 standard messages: "Available to flirt", "Busy but tolerant" and "Bug off, die far!". Anything in between isn't working these days, really.

So what happens when your attention gets frequently requested? You'll be unable to do any kind of sequential work or work that requires a great deal of time and focus. If you pretend to do any of the last follow my advice: turn off your IM client or turn yourself invisible (oh yes, this "state" works fine too).

Having said this, one last thing: use XMPP. It's the only standard open IM network and protocol available. </pub>

Hiveminder supports a XMPP/Jabber based bot. You can add it to your buddylist and "talk" with him and list, modify or create new tasks. It's geekish but I don't use it, I don't find it productive or handy because the only way to interact with it is by typing text and commands and/or using copy&paste for descriptions.

Mail.app is my world.

Geek tool

Geektool is a small OSX application which can be used to display system logs, shell command outputs, etc. in your Desktop space. Pretty nice. I use it to display my Hiveminder tasks, both work and personal, in my background, using the output of the todo.pl command. The todo.pl is simple script, provided by Hiveminder and inspired by Gina Trapani's todo.txt website, which connects to their API, logs in, and just dumps my tasks.

Having my task list on the screen, in a non-intrusive way (it's part of the background image), is very handy. I just need to hit the exposé's "Desktop" shortcut to get a hold of them, it's the perfect complement for the IMAP folder.

Calendar

Hiveminder exports both RSS and iCalendar feeds. Fact is, I don't need them. They work fine though. Maybe the iCalendar feed is useful to you if you have an iPod. I never used iCal to do task management, it sucks at it, I just use it for what it's supposed to do best (and indeed does): manage my time.

Mac Act-On

Mail Act-On is a must-have Mail.app plugin. It associates mail rules to keystrokes. This is great to use with the Hiveminder's virtual IMAP folders. After a few rules configured I can now complete or delay tasks with a simple keystroke. So fast. Now I don't even need to drag the message into the correct folder with the mouse. Check my rules:

Support

So far Hiveminder's support has been great. I've sent them two E-mails and had an answer back in a few days. On of them was a feature request for the IMAP interface (I asked the to include a X-Hiveminder-Tags header for easy filtering based on the task tags) and it was implemented in 24h. No complaints here.

Summary

This setup worked for me. I've been using it for 3 weeks now and it's been very productive. I actually kept my Inbox near zero levels and got everyone feedback or created tasks out of their messages. I highly recommend it.

Tags: gtd hiveminder solution

Video do PTMail

April 20, 2008

Ok, alguém me vai matar por isto amanhã. Mas estive a ponderar e sinto que há legitimidade para tornar este vídeo público: Primeiro porque tenho créditos, muitos créditos, no que diz respeito a expor situações embaraçosas dos meus queridos colegas e amigos de trabalho. Segundo porque já lá vão mais de 4 anos, e todos sabem que na Internet 4 anos são na realidade 12, é muito tempo.

Este vídeo representa um marco na cultura interna do SAPO. Foi o nosso primeiro mega-projecto, que envolveu tempo, recursos e custos consideráveis para essa altura. Tratou-se de construir a nova plataforma toda baseada em produtos Opensouce (ie: Qmail, Horde, Debian Linux, etc, etc.) e que viria a suportar o E-Mail da Telepac e do próprio SAPO, e que ainda hoje existe.

Foram 18 meses de projecto e de trabalho árduo em que não faltaram muitas discussões, muita pressão também do status-quo da época (e dos fabricantes e fornecedores do legacy), mas também muito trabalho em equipa, profissionalismo e diversão. Enfim, vejam.

versão com fullscreen no player

Tags: video ptmail

Takeoff 2008

April 20, 2008

Hoje estive na Takeoff 2008. Boa iniciativa sobre empreendedorismo, que sem fanfarras nem mega-produções conseguiu reunir um bom painel e uma audiência jovem e francamente interessada pelo tema. Muitas caras conhecidas também (entre sapos, ex-sapos e colaboradores do sapo, quase parecia uma reunião de direcção). A repetir.

Fiquei sensibilizado com o convite para ser orador. Afinal de contas eu já não me considero empreendedor, pelo menos não no sentido de começar startups, há uns anos valentes desde que ajudei a fundar o SAPO e o mail.pt. Mas enfim, a minha vivência e o facto de lidar no meu dia a dia com pessoas brilhantes e novos empreendedores de alguma forma me dá formação e me permitirá passar uma mão cheia de conselhos.

Fica aqui a minha apresentação, a quem interessar, essencialmente sobre a história do SAPO e a sua criação. O vídeo do PTMail segue num post a seguir.

Tags: takeoff

Booting up sapo.cv

April 17, 2008

update: Apparently this post had some unexpected echo all over the blogs. Thanks all for your feedback, we're proud. My friend Pedro was crazy and kind enough to translate the post to english.

Ontem lançámos o SAPO Cabo Verde. A sensação de ter um SAPO fora de Portugal é no mínimo estranha, é um misto de orgulho e de medo, em que a segunda das sensações advém certamente do facto de nunca termos pensado muito nisto, na hipótese de actuarmos fora do rectângulo. É o tal síndroma que nos persegue, aos Portugueses em geral, para aí desde o tempo em que deixámos de pensar que somos grandes.

O projecto já cozinhava há uns largos meses. Não vou aqui discutir nem as razões nem os objectivos, alguém o fará por mim, vou só falar de tecnologia. Tecnologicamente falando, instanciar o SAPO fora de Picoas foi um desafio muito interessante. Uma coisa é escalarmos dentro do mesmo Datacenter mas outra coisa é sair do útero, distribuir conteúdos em pontos do globo distintos e distantes e reutilizar a mesma tecnologia mas em contextos diferentes e com características diferentes da nossa realidade mantendo ao mesmo tempo uma arquitectura global.

Ainda é cedo para falar. Posso estar a mandar foguetes antes do tempo e sair-me o tiro pela culatra, mas de qualquer forma achei relevante fazer este post e partilhar convosco a nossa experiência:

SOA

Nos últimos 2-3 anos andámos a queimar pestanas e a limpar a casa para conseguir montar uma arquitectura de sistemas baseada em serviços, vulgo SOA. E conseguimos. O nosso BUS de serviços está de pé e com uma vasta oferta de conteúdos que usamos e reutilizamos quer internamente quer com parceiros ou público em geral. Mas o BUS é mais do que um HUB de APIs, faz mais do que isso. Faz transformações de um formato para outro de qualquer método (ie: RSS para JSON), logging, controle de acessos, proxying, caching, gera documentação e código para todas as linguagens com base nos contratos dos serviços, é um mundo. E é só por causa deste valor todo que suportamos o fundamentalismo do seu incansável e convicto mentor em relação às guerras de SOAP vs REST. Em 2008 vamos colocar o nosso BUS em Opensource, está decidido.

E foi quando deixámos de apregoar SOA para efectivamente o praticar que conseguimos realizar projectos como o SAPO Mobile, que não é mais do que um "cliente" rico do portfolio do BUS (ok, é mais do que isso, mas é para perceberem). O services.sapo.pt é hoje uma peça fulcral na forma como concebemos e montamos os nossos projectos e permitiu-nos não só baixar drasticamente a complexidade dos desenvolvimentos bem somo os tempos de produção dos mesmos. Cabo Verde não existiria nos moldes actuais se não fosse estes esforço silencioso e quase inglório (porque durante muito tempo não representou output para a empresa) que a tecnologia do SAPO teve durante os últimos anos.

Broker

O Broker é outro dos "building-blocks" do SAPO. Foi escrito e re-escrito de raíz por nós (embora a primeira versão tenha sido baseada no Mantaray) e é um dos nossos projectos Opensource. Basicamente e sem entrar em muitos detalhes é uma nuvem gigante de agentes que está presente no Backend de todos os servidores do SAPO, distribuida, e que permite a qualquer aplicação a troca de mensagens e eventos, de forma completamente assíncrona (fire and forget) e em tempo real. Cada evento viaja dentro de um tópico (ou namespace). Os "clients" podem ser produtores ou consumidores de eventos (think pubsub, think uma rádio a emitir numa determinada frequência e um sem número de ouvintes que a sintonizam).

A Homepage do SAPO é completamente dependente do Broker. Cada um dos frontends da Homepage tem um agente que o gestor de conteúdos notifica (através do Broker) cada vez uma zona da Homepage precisa de ser queimada. A Homepage também produz eventos de Broker no browser, com chamadas da AJAX (ie: cada click que se faz numa notícia).

A beleza do Broker é aquilo que eu chamo de "decoupling". Imaginem mashups de eventos em vez de feeds. Imaginem que alguém no SAPO quer montar um serviço que incrementa um contador por cada vez que alguém pesquisa por "Cabo Verde" na Pesquisa do SAPO e que cada vez que um JID do SAPO Messenger, que é colaborador da empresa, faz login dispara-lhe uma mensagem de IM com o número de pesquisa feita por esse termos até à data. O exemplo é estúpido, é da hora, mas o ponto é: Qualquer pessoa no SAPO pode fazer este serviço, não depende de ninguém, não depende da malta da Pesquisa, nem do SAPO Messenger. Basta-lhe consumir os tópicos apropriados que já estão na nuvem e que estão documentados e cujos eventos está a ser gerados, em tempo real, pelas plataformas do SAPO.

Neste momento já temos mais de 100 tópicos a gerarem notificações e com um tráfego agregado na nuvem de mais de 1000 eventos por segundo. A regra de ouro é, qualquer serviço novo que realize uma acção relevante (ie: Alguém faz o upload de um vídeo no SAPO Vídeos, alguém faz login no SAPO Mail) deve produzir uma mensagem e publicar num tópico no Broker.

O Broker é crucial para a nossa escalabilidade e fiabilidade (o decoupling permite-nos na prática reduzir o número de dependências das aplicações e as característica de assincronismo e fire-and-forget reduzem o risco de falta de recursos e performance).

Este é daqueles produtos que temos de advogar mais. O tempo é escasso e é-nos difícil passar a mensagem para fora mas não hajam dúvidas: se procuram um framework de messaging entre aplicações, espreitem isto.

Cabo Verde tem uma nuvem própria de eventos a correr "lá" e partilha uma série de tópicos com Portugal (ie: O gestor de conteúdos reside cá).

CDNs

Durante anos tive a Akamai à perna a tentar vender-me soluções de CDN. Mas por muito que se goste da Akamai (e gosto) a solução nunca fez grande sentido. Na realidade não há muitos problemas de descentralização da entrega de conteúdos quando as maiores redes de acesso ADSL, Cabo e Móvel são da mesma empresa.

Mas entretanto a realidade alterou-se. Não só a rede de acesso cresceu muito e tornou-se complexa sendo necessário encontrar formas de estarmos mais próximos da last-mile, como o Cabo se separou, como entretanto o SAPO se internacionalizou e passou a ter mais do que um Datacenter em mais do que um País. O próprio perfil de conteúdo alterou-se drasticamente. Há 5 anos atrás não havia vídeo na Internet, só para dar um exemplo.

O SAPO Vídeos é o nosso serviço mais exigente no que diz respeito a entrega de conteúdos. Neste momento está a gerar quase 2Gbit/s de largura de banda em média durante todo o dia. Quando construímos a plataforma pensámos muito sobre a melhor forma de resolver o problema dos altos débitos e do futuro crescimento do serviço. E acabámos por construir uma solução de CDN caseira baseada em arquitectura de rede, NAS, DNS e Squids invertidos.

Esta mesma solução permitiu-nos levar o SAPO Vídeos para Cabo Verde, optimizando a entrega local dos vídeos (através da nossa CDN) mas mantendo o "core" do serviço (gestão, master dos vídeos, webUI) em Portugal, Picoas. Isto quer dizer que, com alguma magia de DNS (ver mais abaixo) em Cabo Verde os mesmos vídeos de http://videos.sapo.pt/ são servidos a partir do Datacenter da CV Multimédia por forma a não abusar de um muito limitado link internacional que o País tem.

Bricolage, gestão de conteúdos

O Bricolage é um gestor de conteúdos (enterprise-class for all you suits) Opensource e nesta tecnologia estão assentes alguns dos nossos Websites mais importantes, incluindo as Homepages de Portugal e Cabo Verde, o DN e o JN, entre outros. Workflow, autorizações, versioning e XML é com o Bric. Poucos sites precisarão de um canhão destes, a curva de aprendizagem não é pequena. É impróprio para cardíacos.

Mas depois de feito o deployment e de uma boa formação das equipas editoriais, esta besta é poderosa e de confiança.

A Homepage do SAPO em Cabo Verde é editorialmente gerida a partir do Backoffice alojado em Picoas, numa infra-estrutura partilhada com a Homepage de .pt. Os frontends em Cabo Verde são notificados (via broker) quando há conteúdo novo e isso despoleta um processo de actualização e re-processamento das páginas.

Imagens, CSS e conteúdo estático

As nossas farms de Imagens e de conteúdo estático (ie: http://h.s.sapo.pt/ http://js.sapo.pt/) possuem réplicas exactas e locais em Cabo Verde (http://h.sapo.cv http://js.sapo.cv). A replicação é feita com rsync. As farms estáticas são processos de lighttpd (dois por máquina para aproveitar os Xeon) em Linux e com epoll e cabeçalhos de Expires gigantes. Em testes conseguimos esgotar as interfaces de Gigabit de um destes servidores. A carga? 2. Uptime do nosso static1 (de 3):

root@static1:/servers/lighthttpd/etc# uptime
 01:08:13 up 553 days, 11:36,  1 user,  load average: 0.01, 0.01, 0.00
root@static1:/servers/lighthttpd/etc# ps ax |grep lightt
 2019 ?  S 429:53 /sbin/lighttpd -D -f /servers/lighthttpd/etc/httpd1.conf
 2039 ?  S 370:24 /sbin/lighttpd -D -f /servers/lighthttpd/etc/httpd2.conf

Rsync

O rsync é um dos nossos canivetes suíços dentro do SAPO. É usado para replicar árvores inteiras de conteúdos, para fazer a passagem de projectos para produção que estejam distribuídos por vários servidores, para gerir repositórios de pacotes Debian, para replicar a nossa farm de Web thumbnails, etc, etc. É muito eficiente porque faz cópias incrementais e comparativas e porque prima pela simplicidade e pela performance. Comporta-se muito bem também em cenários de conectividade remota. Só para terem uma ideia, há pessoas corajosas o suficiente para fazerem backups de servidores e dos seus computadores pessoais com rsync.

Cabo Verde depende muito dos nossos processos integrados de passagem para produção e replicação de conteúdos, que passam necessariamente pelo rsync.

Monitorização e Métricas, Nagios e Cacti

Desde sempre que usamos o Nagios para monitorização e alarmes e o Cacti para métricas de sistemas, mais dois produtos Opensource de qualidade. Em Cabo Verde usámos a mesma aproximação e estamos activamente a tentar ligar as duas instâncias (quatro) para termos uma visão integrada de tudo, do SAPO como um todo. Em teoria é bem possível, não só porque o software é Opensource mas porque é baseado em sondas, scripts e SNMP.

DNS patch

Os nossos DNS primário e secundário correm em cima de djbdns. Adicionámos-lhe um patch (com contribuições poderosas do nosso Über Sysadmin japc) que basicamente nos permitem dar respostas diferentes para ponto geográficos diferentes. Como base de dados de georeferenciação usa a GeoIP. Very nice.

Já estão a adivinhar não? Se alguém em Cabo Verde pedir um ficheiro de .js a http://js.sapo.pt/ o DNS encarrega-se de lhe resolver o nome para um IP dos nossos servidores em .cv (que também respondem a js.sapo.pt) e o conteúdo é servido localmente. Se alguém fizer o mesmo noutra parte qualquer do mundo, o DNS resolve para o IP de Picoas. Este conceito é aplicado em inúmeros cenários do projecto.

Instanciação e Templating

Outra mudança de mindset para nós foi a de passarmos a pensar nas plataformas dos projectos como sendo sistemas capazes de correr em contextos diferentes com comportamento diferentes mas sempre com uma base comum, um chapéu. E capazes também de se instanciarem, total ou parcialmente, fora do seu habitat natural, neste caso Picoas.

Isto na prática exigiu de nós um cumprimento mais rigoroso de um conjunto de boa práticas que nem sempre foram a regra: Usar sempre templating (ie: smarty, mason, template-toolkit) e CSS, prepararmos-nos para o multilingue, configurações dinâmicas dos serviços (por contexto, ie: bases de dados, memcacheds, etc), modularização e reutilização de componentes web (ie: mashups), repensar os procedimentos de passagem de desenvolvimento a produção (a contar os cenário de multi-hosting, multi-site).

libsapojs & Widgets

Outro projecto que fizemos em 2007 e que nos ajudou em Cabo Verde foi a nossa library de Javascript. No fundo estamos a falar do mesmo, reutilização de componentes e distribuição. Os Widgets que desenvolvemos em Portugal ficam, através dos procedimentos de passagem a produção e replicação, automagicamente disponíveis em todo o universo SAPO, tal como um mapa do Google num blog se auto-actualiza sob o comando do seu dono.

Em suma:

Estes são só alguns exemplos do tipo de preocupações que tivemos quando começámos a pensar no Internacional. Conselhos? Sim, alguns:

1. Uma boa arquitectura de sistemas é crucial para a evolução de qualquer projecto de TI. Nós, por questões históricas e heranças (legacy de mergers and stuff), aprendemos isto a bater com a cabeça na parede. Custou-nos mais. Não facilitem. Facilitem em tudo mas uma má arquitectura num projecto que quer crescer é um tiro no pé no médio-longo prazo.

2. Especifiquem por excesso, raciocinem top-down. Pensem à frente do tempo. É preferível perder 2 dias a colocar gettext nos templates, mesmo que não se use ainda, do que depois perder 1 mês a fazer refactoring de tudo para acomodar os novos requisitos. Definam um conjunto de boas práticas e cumpram-nas religiosamente. As áreas de negócio vão ficar irritadas por causa do famigerado time-to-market mas arranjem uma firewall e percam tempo no início, não durante. Eu sei que isto é uma lapalissada mas tem que ser dito.

3. APIs são ouro, são a cola da Internet. Estruturem e façam interfaces para tudo, e anunciem-nos, mesmo que não usem. Seja RSS, XML, JSON, SOAP, Microformatos, o que for. Desde que seja um formato estruturado, até sou capaz de suportar WSDL. HTML scrapping ou logins para aceder a uma schema mutante de Mysql é que não, por favor. Produzam matéria prima, mesmo que seja inútil, e publiquem-na, de preferência de forma assíncrona para o caso dos eventos. Alguém algures, dentro ou fora da organização pode reutilizar esse material para construir um novo serviço, "decoupled" dos plataformas e dos autores das fontes, como deve ser.

5. Simplifiquem, não compliquem. O ser humano é complicado por natureza, temos uma tendência natural para nos metermos em alhadas e depois racionalizar tudo com explicações estapafúrdias. Para quê usar um SQL se o schema não é relacional? O filesystem é das bases de dados mais robusta e testadas do planeta, funciona impecável para queries do tipo chave/valor. Para quê um "full blown Apache Webserver" quando na realidade o que nos interessa é performance HTTP? Talvez um lighty seja mais adequado. Balanceamento Layer4, não será um simples perlbal mais eficaz e robusto do que um dispendioso e obscuro equipamento de rede? Etc.

Para fechar, fica aqui o testemunho de que é possível construir uma arquitectura de um Portal Web completamente distribuída, modular, reutilizável e flexível com produtos Opensource e prata da casa. Não se assustem nem se deixem levar à primeira pelos discursos dramáticos dos consultores e dos fabricantes (so called carrier-grade). A nós deu-nos muito gozo montar isto, agora é deixar amadurecer, aprender um pouco mais, e lançarmos-nos a maiores vôos.

Tags: sapo cabo verde

iPhone 3G specs

April 09, 2008

I just love headlines. Evidence of infineon's SGOLD-3H chip support has been found in the latest iPhone beta firmware sent to selected developers. The specs for the chip can found here and pretty much define the max specs to be expected for the iPhone 3G. Or not, but everyone loves a good grounded rumour. The most important features are:

Support of cameras up to 5 MPixel
Support for video telephony, streaming, recording and playback
2 x MMC/SD interfaces, SDIO capable
Multimedia extension interface (MMIC-IF) for support of high end graphic accelerators
2 bi-directional digital audio interfaces (I2S) to connect audio companion ICs and Bluetooth modules
HSDPA - category 8 (7.2 Mbit/s)
Option to switch off HSDPA to save power

Tags: iphone 3g specs

Paul Graham worships Steve Jobs

April 06, 2008

I didn't see this coming. Paul Graham, one of my favorite essayists, puts Steve Jobs on his personal list of heroes, just before Isaac Newton.

Quoting: "People alive when Kennedy was killed usually remember exactly where they were when they heard about it. I remember exactly where I was when a friend asked if I'd heard Steve Jobs had cancer. It was like the floor dropped out. A few seconds later she told me that it was a rare operable type, and that he'd be ok. But those seconds seemed long. I wasn't sure whether to include Jobs on this list. A lot of people at Apple seem to be afraid of him, which is a bad sign. But he compels admiration. There's no name for what Steve Jobs is, because there hasn't been anyone quite like him before. He doesn't design Apple's products himself. Historically the closest analogy to what he does are the great Renaissance patrons of the arts. As the CEO of a company, that makes him unique. Most CEOs delegate taste to a subordinate. The design paradox means they're choosing more or less at random. But Steve Jobs actually has taste himself—such good taste that he's shown the world how much more important taste is than they realized."

I found this surprising and amusing. We all love Apple for it's design and innovative products (well, I do anyways) but calling Stevie a hero is a bit of a stretch, I say. Now calling Fake Steve Jobs a hero would be more appropriate.

Read the rest here.

Tags: paul graham steve jobs heroes