Personal tools
You are here: Home



 
Showing blog entries tagged as: programação

IRC para trabalhadores oprimidos

Para muitos, IRC é uma tecnologia quase esquecida.

IRC, para quem nunca soube (ou já esqueceu), é uma sigla para Internet Relayed Chat. Uma rede IRC é composta de servidores (nós) aos quais você se conecta usando um cliente IRC. Nessas redes você encontra usuários, que estão se comunicando em um ou mais "canais".

Essas redes de IRC têm um papel central em muitos projetos distribuídos. Uma das mais importantes é a freenode. É nos canais dela que os usuários e criadores de vários (na casa de centenas) produtos se encontram para trocar idéias, tirar dúvidas e sugerir alterações. É muito mais rápido do que perguntar algo numa lista de e-mails. Foi no canal "#httpd" (do pessoal do Apache) que eu resolvi um problema de configuração em que eu esbarrei hoje de manhã. Não é exagero dizer que as redes de IRC são um dos pilares do desenvolvimento de software de código aberto. Sem elas, a comunicação seria muito mais complicada.

É, por isso mesmo, um recurso extremamente valioso.

Infelizmente, por questões as mais variadas, muitas empresas bloqueiam as portas por onde passa o tráfego de IRC nos seus firewalls, isolando seus usuários. Quem trabalha nesses lugares acaba até mesmo esquecendo que redes IRC existem ou acaba com a falsa noção de que ninguém mais usa. Acaba sendo obrigado a resolver seus problemas pelas listas de discussão por e-mail. Lento, doloroso e ineficiente.

Para nossa sorte, o bloqueio das portas do IRC não quer dizer que esses proletários oprimidos precisem viver em isolamento, incapazes de se mobilizar: algumas dessas redes - a freenode entre elas - têm fronts HTTP. Para usar o front HTTP da freenode, você só precisa digitar o endereço http://webchat.freenode.net/ no seu navegador, escolher um nickname e um canal no qual entrar. Daí em diante, é como se você estivesse usando um cliente IRC no seu próprio computador. Para saber mais sobre como se usa o IRC (e etiqueta é importante), eu recomendo o IRC Primer.

De resto, se você está lendo isso de dentro de uma rede em que não consegue usar um cliente IRC de verdade, não pense duas vezes: saia explorando, aprenda e converse. Há um monte de gente lá esperando por você.

Read More…

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/.

Read More…

An Emacs cheatsheet as a mindmap

I have been using Emacs for some time now. It has a very steep learning curve, but its power and elegance make it my editor of choice for just about everything. So, inspired by this article, I decided to create my own Emacs cheatsheet. There are many Emacs cheatsheets, but all of them use a tabular format that is not, in my noob opinion, the best way to convey such information: you can interpret the Emacs commands as a tree-like keystroke structure and many important commands use two or more steps.

I started a mind-map for the keystroke trees with the commands I use the most (and some of the ones I find the most amusing). The plan is to make a navigable cheat sheet like the Mercurial and Git ones you can get here and here, plus some tips on what to add to your ~/emacs.d/init.el file.

You can get the very, very early version of the mind-map (in Freemind format) here or just look into the image that follows.

All the heavy magic is also missing, like the "smart paste" Marco Baringer does about 1:45 into the What is Ajax screencast that relates to the David Crane's Ajax in Action book (that I still don't know how is done).

Mind-map for a future Emacs cheatsheet

I would appreciate any advice from Emacs veterans and newbies alike, so, feel free to comment.

Read More…

Editor nirvana

To say GNU Emacs is merely a text editor is an understatement. Ever since I decided I would learn to use it (out of a never quite accomplished mission of learning Lisp once and for all), it impresses me almost on a daily basis.

Yesterday, while playing with my choice of screen fonts for the editor (something every bit as important as choosing one's text editor), I discovered two pop-up menu options, to increase and decrease font size. A little playing with Meta-X and I arrived a couple functions, "text-scale-increase" and "text-scale-decrease". A little more digging brought me to the key combinations "Control X Control plus" and "Control X Control minus" sequences. Usable, but I wanted something easier to type.

Few non-Emacs users appreciate the fact Emacs has no configuration file. What it has is a program, in its own Lisp dialect, that's executed every time the editor is started. Within this program I can define new functions, load external libraries and even write a credible implementation of vi. This time I made two simple edits to my init.el file that added two new key bindings:

(global-set-key (kbd "C--") 'text-scale-decrease)
(global-set-key (kbd "C-+") 'text-scale-increase)

The first one binds the "Control minus" key combination to the text-scale-decrease function (that decreases text size) while the second binds "Control plus" to the opposite text-scale-increase function. Easy enough for me. Now, every time Emacs starts, it has a couple bindings extra key bindings (on top of all other already added by loading external libraries, modules and so on) that make my life more convenient.

And this concludes my Emacs praise of the day. Thanks for coming.

Read More…