The Facebook Marketing Book, by Dan Zarrella
Facebook Marketing is not a book for programmers. For us, it's a very hard read and finishing it took some determination. Neither it is for startups that intend to be the next Zynga, as it offers little advice for those, specially with regard to monetization options. It contains, however, good advice for already established entities that want or need to use Facebook as a vehicle for engaging current and acquiring new clients that's specially valuable if you are new to the social networking environment. It also contains an overview on how to employ Facebook's functionalities as tools to promote your brand, for communicating and organizing social events and on what kinds of content you should generate to keep your Facebook assets alive. It offers some advice that's useful for hackers like me, on how to best model the social relations of a Facebook application to ensure it has chances of becoming viral.
You can find more about the book on O'Reilly's site and on its Amazon page.
Hold different
This time, inspired by eddieplan9, one for all iPhone4 users who have experienced reception problems due to the way they hold their phones.
Música em Scheme
Para quem não sabe o que está aí no alto, os blocos representam S-expressions de um programa em Scheme que toca determinados samples em momentos diferentes, segundo condições determinadas pelo próprio programa. O que vemos no vídeo é o programa sendo alterado durante a performance usando o Scheme Bricks.
O Plone Symposium e porque você devia ir
Eu sempre recomendo que coisas importantes recebam a devida atenção.
É por isso que não me incomodo muito em ver sites descartáveis sendo feitos com tecnologias como ASP, JSP ou PHP naquele modelo antigo que mistura apresentação com lógica. É como na construção de cenários - você não vai usar madeira se isopor e lycra resolverem. Concreto armado, nem pensar. Site descartável é como aqueles escritorios que são erguidos para vebder apartamentos na planta: ele só precisa ficar lá até vender unidades suficientes para começar a obra. Depois disso, vai ser derrubado. Ele nunca vai desenvolver uma goteira ou ganhar mais um piso.
Com sites, a situação é parecida.
Se seu site for só um cartão de visitas feito pra dar seu e-mail de contato ou telefone, tudo bem você montá-lo com qualquer coisa. HTML estático está bom demais.
Por outro lado, se você precisa viver com um site, é bom fazê-lo direito. É importante separar a aparência dele (que pode mudar radicalmente a qualquer tempo) do conteúdo (que tende apenas a aumentar) e de eventuais aplicações que rodem dentro dele (se seu CMS deixar você fazer esse tipo de coisa).
É por conta disso que eu gosto tanto do Plone. Ele traça uma linha muito nitida entre conteúdo e forma e, por conta de como é construído, em torno de um banco de objetos (e não um banco relacional, como a maioria dos concorrentes) ele torna ridiculamente simples fazer aplicações de workflow ou de gestão de conhecimento.
E quando eu digo ridículo, é porque, tipicamente, você só precisa gerar alguns diagramas UML e entregá-los a uma ferramenta que faz o resto.
Uma digressão rápida: no meu livro, guardar documentos dentro de um BD relacional, como faz o SharePoint, é motivo para justa-causa. Guardar ponteiros para um sistema de arquivos é apenas marginalmente melhor. Mas isso é material para outro artigo, não para esse.
E aí eu entro na parte realmente importante: se você tem problemas com sua intranet e gostaria que ela fosse mais manejável, compatível com mais navegadores (diga a verdade - é um porre quando a empresa padroniza em IE 6 porque fez a burrada de crira aplicações importantes que não rodam nem mesmo nas versões posteriores dele, quanto mais em navegadores mais modernos), que pudesse guardar seus documentos do Office (ou do OpenOffice, ou do iWork, se você tem Macs), que tivesse uma busca que funciona (porque você quer encontrar os documentos que colocou lá), que tenha undo sem nunca precisar de um restore do banco de dados (porque todo mundo erra de vez em quando) e que, no geral, envelheça mais graciosamente do que aquelas coisas com que você está acostumado, dê uma olhada no Plone.
Eu sei... Eu sou - e assumo - um fanboy do Plone. O dieblinkenlights é feito em Plone. Por vários anos o Plone pagou - não paga mais - minhas contas. O DBL é feito em Plone porque eu sou muito preguiçoso e não quero ter dores de cabeça com o site. Ele simplesmente funciona e tem sido assim desde que ele existe. E é assim que um CMS tem que ser.
Na semana que vem acontece em São Paulo o Plone Symposium South America. É a primeira edição do evento e vale a pena você ir. Vale a pena, não importando se você usa ou não Plone. Mesmo que você seja um usuário de Joomla, Drupal ou, coitado, de Sharepoint, vale a pena ir. Vale a pena para saber o que o outro CMS, aquele que você não usa, tem para oferecer.
Na pior das hipóteses, você sai com uma lista de features para serem implementados no seu que deve manter seu pessoal de desenvolvimento ocupado por algum tempo.
Mas, se você tiver mesmo sorte, você sai de lá um usuário de Plone.
Seus usuários vão agradecer.
Nota: este artigo também foi publicado no Webinsider, em http://webinsider.uol.com.br/index.php/2009/11/19/em-defesa-do-plone/.
