The fainting surgeon
This morning I came across a funny comment.
On a post that highlights a subtle implication of the use of Java and as a teaching tool (picked up on another article, this one about Scheme), a guy named Stephen Fraser dropped this: "As I see it, a software engineer who hasn’t worked through SICP with Scheme, a basic editor and command line, is like a surgeon who has never dissected a frog and faints at the sight of blood."
I happen to agree with that. It's not as much a virtue of Scheme and SICP (both outstanding teaching tools), but a major conceptual failure of IDEs. By shielding the programmer from the complexities (and we can endlessly argue whether those are needed or not) of the typical Java framework or build tool, they make that complexity tolerable and thus create fertile ground for adding new complexities on top of it the already high pile of complexity, a layer that will, eventually, be mitigated by the next iteration of the IDE (or, if this specific layer of complexity fails to get much traction, by an IDE plugin).
And so, as we add layer upon layer of complexity, many of today's software engineers grow accustomed to be so removed from whatever they are actually doing (or, more precisely, what their IDEs are doing for them) that they risk being unable not only to see, but to accurately grasp the full depth of the stack they are standing upon. They become surgeons who can't say where the patient's lungs are located or what they do.
Mining the Social Web, by Matthew A. Russell
This book covers a lot of ground. It's, at times, a bit vertiginous in the amount of subjects and technologies it touches per chapter, and is not always easy to follow. It can also introduce so many interesting things that, by the time you finished becoming familiar with all of them, after wandering for hours on the web, jumping from interesting technology to interesting technology, you may have forgotten what took you to these places and wonder where you were in the book. Time spent reading it is, however, time very well spent. When you finish it, you will have at least a cursory familiarity with tools like OAuth, CouchDB, Redis, MapReduce, NumPy (and the Python programming language, albeit it will help you a lot if you know your way around Python before you start the book), Graphviz, SIMILE widgets, NLTK, various service APIs and data formats, and will be well equipped to explore those rich datasets on your own. The chapters are well compartmentalized and it's easy to pick chapters to read according to your needs. I know that, when I face the problems they tackle, I will do exactly that.
If you do any kind of analysis and visualization of social-generated data that's on the web, this book is a good pick. Even if your datasets are not from the web, you may find the parts on analysis and visualization very interesting.
You can find this book at the O'Reilly website or on Amazon.
Disclosure: I reviewed this book for the O'Reilly Blogger Review Program. If you have a blog and love to read, you should take a look into it. It's fun.
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.
"Erro no processo da assinatura digital após retorno do Applet Assinador. Tente mais tarde"
Certamente eu não sou a única pessoa a detestar a nossa Receita Federal. E não é nem pelos impostos, dessa vez. Eu sei que o trabalho deles é cobrar, que não são eles que inventam os números malucos com os quais eu tenho que viver.
Nos últimos dias troquei e-mails mal-criados com meu contador por conta de um problema com o sistema de procurações eletrônicas da Receita. Em teoria, é lindo. Eu tenho um certificado digital assinado pela Certisign. Esse certificado fica instalado no meu navegador e prova, se o site quiser e eu deixar, que eu sou eu. Isso é uma das formas que a Receita aceita como prova de identidade. Uma vez provado que eu sou eu, eu posso agir como representante de uma pessoa jurídica e criar uma procuração para que meu contador envie relatórios, preencha formulários, solicite informações e, no geral, me poupe de lidar diretamente com esse feudo do governo. Qualquer coisa que torne o governo mais eficiente (e barato) é boa pra mim. Se o preço de economizar uns 5 metros quadrados de agência e 30 minutos de um atendente é comprar um número primo, que seja.
O problema é que, há dias, estou tentando gerar a tal procuração nos dois notebooks que eu uso regularmente, ambos rodando Ubuntu Linux 10.10, um deles de 32 bits e o outro de 64. Sou sempre confrontado com uma mensagem "Erro no processo da assinatura digital após retorno do Applet Assinador. Tente mais tarde". O applet é um programa em Java. Eu tenho o Java aqui (1.6 da Sun/Oracle, um pouco mais novo do que o que a Receita pede). Tenho também o Firefox, que é uma coisa que a Receita pede. Tudo funciona até o momento em que eu assino a procuração usando applet e o certificado digital. Tentei mais tarde, tentei em dias úteis, mudando o prazo da procuração, horário comercial, 32 bits, 64 bits... Tentei tudo.
Hoje, por um outro problema completamente diferente, estava instalando um Windows em uma VM e, após uma calorosa troca de e-mails com meu contador (pela qual eu já pedi desculpas) resolvi tentar mais uma vez. Instalei meu eCPF (o nome comercial dado ao certificado) e o Java (da Sun/Oracle, como no Linux) e fui lá fazer a assinatura da procuração com o IE que estava instalado na VM. Funcionou.
Que m* é essa? A Receita está mesmo me obrigando a usar Windows? Se é assim, escreve logo no site que eu nem tento usar Linux. Não dê uma mensagem de "tente mais tarde". Diga de uma vez "não deu certo desse jeito", "tem algum problema no seu computador" ou algo parecido.
Com todo o suporte que o governo federal diz dar ao software livre é plausível que esse sistema nunca tenha sido testado com Linux? Com a distribuição mais popular dele?
Serei eu o único com esse problema?
