Compilando Vim 7.3 para Ubuntu

Direto ao ponto:

1. Instale xorg-dev e libgtk2.0-dev. Sem isso, não rola o gVim.
2. ./configure --enable-gui=gtk2 --enable-multibyte --with-features=huge --enable-rubyinterp
3. make
4. sudo make install

Os executáveis vão estar em /usr/local/bin

Se quiser suporte ao Python, ao invés de usar --enable-rubyinterp, use --enable-pythoninterp. De qualquer maneira, você vai precisar dos headers de ambas as linguagens.

Como instalei o Ruby via RVM, ele encontrou o source do Ruby facilmente. Mas um aviso: o interpretador do ruby dentro do Vim vai ser sempre aquele em que o RVM estava quando você compilou, mudar a versão do Ruby via RVM não tem efeito nenhum no interpretador usado pelo Vim.

O tiuzão metaleiro TaQ apontou esse instalador que ele fez: https://github.com/taq/viminstall que é muito bom. Mesmo que você não queira usá-lo e quiser instalar tudo na mão, o script é uma ótima referência!

---
Editado:
1 - A opção para interpretador do Ruby estava errada: --with-rubyinterp deve ser --enable-rubyinterp.
2 - Adicionada referência ao instalador do TaQ.

Qual o real papel de um Arquiteto de Software

A questão apareceu em uma discussão da Tectura.

Comecei a escreve uma resposta, mas a coisa ficou tão longa que resolvi postar aqui =\

Versão para apressados:

0 - IMHO, acho que estamos respondendo na discussão como o arquiteto de agir, mas não o o quê (papel) ele deve fazer...
1 - Simplificando absurdamente um arquiteto de software cuida da arquitetura de sofware (duh, momento Homer)
2 - Infelizmente, Arquitetura de software NÃO é um conceito aceito universalmente, nem é um conceito bem definido, muito pelo contrário. Cada um fala o que quer sobre o assunto e ninguém está errado :)
3 - Um dos melhores trabalhos sobre o tema é de Bass et al.
4 - Segundo ele, uma das principais funções do arquiteto é cuidar das "ilities" do software e documentá-lo.
5 - Pessoalmente, acho que documentação de software é só uma tática para atingir "modificabilidade".
6 - Conclusão: se o raciocínio desses caras estiver correto e se a minha opinião estiver correta, o papel do arquiteto é garantir as "ilities" de software, e para isso, precisamos nos meter em tudo qto é buraco do desenvolvimento de software, da negociação ao código.
7 - Mas todos nós podemos estar errados ;)

Versão para pacientes:

Acho q estamos confundindo a resposta, ou talvez eu não tenha entendido bem a pergunta. IMHO, boa parte das nossas respostas estão indo no caminho "como um arquiteto de software deve se comportar" e não "o que um arquiteto de software deve fazer".

Digo, se ele é um ditador, um comunicador, um líder nato, se é up front, "ágil" ou whatever, isso é COMO ele faz, e não O QUÊ ele faz. (tá correto isso?).

Tentando colocar a questão de outra maneira: "O que (papel) um Arquiteto de Software faz?"

Resposta óbvia: "Cuida da arquitetura" (duh)

E aí caímos na questão do Guilherme Silveira: "Uma questão anterior ao papel do arquiteto é o que é arquitetura"

Consultando a wikipedia (http://en.wikipedia.org/wiki/Software_architecture e http://en.wikipedia.org/wiki/Software_architect) e mais algumas fontes (http://goo.gl/ucNC, http://www.sei.cmu.edu/architecture/start/community.cfm, por exemplo, mas vc pode procurar por mais) dá pra perceber rapidamente que não existe um conceito uniformizado sobre o que é a bagaça. Ou seja, cada um de nós tem uma concepção diferente do que é arquitetura, e nenhum de nós está errado, simplesmente pq não existe resposta certa aceita por todos.

Um trabalho sobre o assunto que é sempre citado é o de Bass et al, mesmo assim, se vc lê-lo atentamente, vai perceber alguns conceitos que vêm "from thin air" (ou seja, sem referência a outros trabalhos), embora sejam caras experientes com vários projetos de sucesso na bagagem.

Segundo esse trabalho, uma das preocupações do arquiteto é garantir as "ilities" de um software (http://en.wikipedia.org/wiki/Software_quality) e documentar a coisa toda.

Opinião pessoal, eu concordo com a parte de garantir as "ilities", mas acho que a documentação é só uma outra tática para se atingir "modificability" ou "manutenability".

E se isso está certo, desde "Time to Market" até "Performance" e "Usabilidade" são responsabilidade do arquiteto. Para poder garantir isso, então, o arquiteto deveria se meter desde a negociação do software até programação e interações com o usuário.

Por outro lado, podemos estar todos redondamente errados. Por quê? Bom, "arquitetura" de software e "arquiteto" de software são papéis que foram criados por similaridade metafórica com construção civil. Se você já trabalhou desenvolvendo software, sabe que essa metáfora é muito frágil. Ou seja, podemos estar tentando criar um papel que não faz sentido existir. Por outro lado, existe algo realmente de alto nível que precisa ser cuidado, e que está muito mais alto nível do que estamos acostumados a pensar.

Duvidando do óbvio: Gravidade?

Não sou nenhuma sumidade no assunto, aliás, sou uma porta de leigo nessa bagaça... mas... e se ao invés de vivermos um mundo redondo, estivermos na verdade em um mundo chato, mas com a gravidade torcendo o espaço sobre si mesmo?

Ruby 1.9.2 - diferenças com expressões regulares

O Ruby 1.9.2 veio com algumas poucas incompatibilidades com as versões anteriores. Duas delas me parecem um pouco "inconvenientes", a primeira comentei no post anterior. A segunda tem a ver com mudanças em expressões regulares.

Do ruby-lang.org (http://svn.ruby-lang.org/repos/ruby/tags/v1_9_2_0/NEWS)

* \d, \s, and \w are now ASCII only; use POSIX bracket classes and \p{} for Unicode semantics

O que significa que no Ruby 1.8.7, isso aqui funciona:

> irb -Ku
> "você" =~ /\w$/
=> 3

Mas não no Ruby 1.9.2:

> irb
> "você" =~ /\w$/
=> nil

Para que a coisa funcione corretamento no 1.9.2 é preciso usar "\p{Alpha}":

> irb
> "você" =~ /\p{Alpha}$/
=> 3

Perfeito, mas se você tenta a mesma solução no Ruby 1.8.7:

> irb -Ku
> "você" =~ /\p{Alpha}$/
(irb):1: warning: regexp has invalid interval
(irb):1: warning: regexp has `}' without escape
=> nil

Okay... nada que seja um absurdo, mas para quem trabalha com a língua portuguesa isso fica um pouco chato.

Ruby 1.9.2 primeiras experiências

A versão final do Ruby 1.9.2 foi liberada mês passado (agosto/2010), e só agora comecei a meter a mão na massa nele pra valer.

Logo de cara, já tive alguns problemas menores, mas importantes:

O primeiro foi no "require", a partir dessa versão o diretório atual não está mais incluído no $LOAD_PATH. O que significa que essa construção passa a ter problemas:

require File.dirname(__FILE__) + '/algum_subdiretorio/algum_ruby'

Para resolver isso, duas soluções:

A primeira é expandir o caminho:

require File.expand_path(File.dirname(__FILE__)) + '/algum_subdiretorio/algum_ruby'

A segunda, mais sensata, é adicionar especificamente o diretório "raiz" da aplicação ao $LOAD_PATH, como sugerido aqui)

$LOAD_PATH << File.expand_path(File.dirname(__FILE__)) + '/../lib'

require 'algum_subdiretorio/algum_ruby'

require 'outro_subdir_dentro_de_lib/outro_arquivo_ruby'

Com algum esforço, dá até pra criar um script pra arrumar isso automaticamente ;-)

Eu tenho todo o conhecimento do mundo...

Ontem estava no mercado com minha esposa e ela disse: "Queria fazer um molho de maracujá, como será que faz?"

Dei de ombros e continuamos pegando os refrigerantes, de repente parei e disse: "Peraí, eu SEI como fazer esse molho!".

Saquei o celular, abri o browser, Google, "molho de maracujá" e... bingo! Primeiro resultado já tinha a receita com todos os ingredientes. Compramos tudo e almocei um pelo pernil regado a molho agridoce.

Eu tenho todo o conhecimento do mundo...

...eu, e qualquer pessoa com acesso a internet. :)

Desde que comprei esse celular, e acesso a internet com ele, me pareceu que consigo fazer ou saber qualquer coisa que eu precise. Nós de gravata? Fácil! Receitas? Imediatamente! O que significa "nó cego"? Tá na mão! Algoritmos? Pra qualquer coisa que vc deseje...

Assinei o Safari (da O'Reilly), coloquei o Stanza e comecei a baixar livros gratuitos e comprar outros da Pragmatic Bookshelf (fazem meses que não leio um livro "físico"). E posso consultar toda minha biblioteca de conhecimento a qualquer momento.

Isso começou a me dar a impressão que consigo saber qualquer coisa que eu queira, de qualquer assunto, a qualquer momento.

Não bastasse isso, esse nossos pequenos e maravilhosos "gadgets" nos dão "super-poderes" (hmm... essa palavra ainda tem hífen?)

Memória fotográfica? Bom... o celular tem uma câmera e um gravador de som. Também tem uma agenda "buzina" meus compromissos.

Senso de direção? Viva o Google Maps e o TomTom.

Telepatia? Experimente SMS (boooommm... dá pra simplesmente fazer uma ligação :-p)

Pare um momento e pense como uma pessoa de 1980... "tudo isso é ficção científica!" =\

Acho que estou ficando velho...

Apanhando das expressões regulares no Ruby

Estava eu brincando com o Ruby 1.9 e tentando fazer uma expressão regular bem simples:

#encoding: utf-8
puts "isso é inaceitável".scan(/\w+/)

resultado:

isso
inaceit
vel

Uh-oh... =/ nada bom.

Procurei por todo lado, tentando achar o que eu estava fazendo de errado. Achei vários posts dizendo que isso deveria funcionar e ninguém com o mesmo problema que eu. Não sei o que fiz de errado até agora, se alguém souber, por favor me avise =/

De qualquer maneira, tentei resolver o problema sem sucesso. Então, na documentação do Oniguruma, achei um "paliativo":

#encoding: utf-8
puts "isso é aceitável".scan(/\p{Word}+/)

E o resultado:

isso
é
aceitável

Ótimo!

Além disso, fuçando lá vi várias outras classes bastante úteis, como "\p{Alpha}", "\p{Alnum}, "\p{Upper}" e "\p{Lower}" entre outros. É possível também negar a classe usando um "\P" (maiúsculo) como prefixo.

Java missed the boat?

Ontem eu estava dando uma olhada no JDK 7 para ver em que pé estava. Queria saber principalmente de closures que, a priori, iam ficar de fora.

Para minha surpresa (tá, tá... cheguei atrasado na festa), estava lá na página da Sun um pequeno artigo sobre closures de Dezembro de 2009 dizendo: "Vamos colocar uma versão de closures simplificada no JDK 7":

... It’s time to learn from the past debate and move forward. Sun will initiate the design and implementation of a simple closures feature, as outlined above, and add it to JDK 7 so as to enable broad experimentation. If all goes well then we’ll later submit a language-change JSR which would, in turn, be proposed as a component of the eventual Java SE 7 JSR. (ênfase minha)

Não entendi nada =/ Depois de tanto afirmarem que não ia, pra que a pressa agora? Colocar closures em Java vai ser um "puta trampo". Não pelos closures em si, mas muito da API deveria ser reescrita ou expandida.

Procurando um pouco mais achei um bug (ID: 5014235) na Sun Developer Network que acho que explica bem o que significa colocarem closures agora.

Closures are a great thing. Unfortunately, Java missed the boat in 1997. Since then, we've added a collections framework without closures (one of the prime uses), built graphics APIs around nested classes etc. We have tons of control constructs that could be defined using closures but aren't (assert and foreach, for example). So the advantage of adding closures now would be relatively small compared to the huge benefit you get if you add them from day one.

(ênfase minha de novo)

Resumo da ópera: o trampo de colocar vai trazer um benefício bem menor que o esperado, já que todos os lugares onde closure seria realmente bom já estão usando outros esquemas.

Se colocarem agora, para não tornar o código anterior incompatível, terão que adicionar vários métodos e maneiras "alternativas" de se fazer as coisas. Não sei vocês, mas acho que isso vai embananar o código, ora com closures, ora sem.

Não me leve a mal, adoro closures e acho que deveriam ser parte essencial de qualquer linguagem, mas colocar elas no Java agora vai dar um tremendo trabalho e quebrar a integridade conceitual da coisa (popular: "bagunçar o coreto").

Quer closures, gosta da JVM e de tipagem estática? Vai pro Scala que você vai estar mais bem servido e com uma linguagem conceitualmente consistente. De quebra, você ainda ganha type inference, currying, pattern matching, operator overloading (hmmm... na verdade é notação infix, mas dá na mesma), imutabilidade fácil e mais um paco de técnicas realmente úteis para programar.

Muito tarde para o Java.

Sobre a carreira

Eu estava revisando meu currículo esses tempos atrás e comecei a ver no que já trabalhei, não em tecnologia, mas os negócios em que trabalhei, e fiquei surpreso com a quantidade de coisa que 'entuia os meu norônio'. Olha que beleza:

Comecei dando aula de DOS, WordStar, Lotus-123 e QuattroPro, depois seguem aulas de Windows, Access e 3DStudio (versão DOS!).

Largo as aulas e vou dar manutenção em um sistema auxiliar de uma indústria de celulose e papel.

Pouco tempo depois começo a mexer com e-commerce e um portal.

Mais um ano e vou pra bioinformática mexer com análise de DNA.

Saio e vou trabalhar com e-government na Secretaria da Fazenda do Estado de São Paulo.

Na sequência engata um sistema para configuração de equipamento de medição remota, e o front-end de um e-banking.

Fico 2 meses parado e vou trabalhar com replicação de autorização em catracas eletrônicas, middleware para transferência de dados entre fabricantes de móveis, CRM, e um site para corrida de cavalos.

Nesse meio tempo correm em paralelo: mais aulas e mais sistemas para bioinformática.

Saio e vou trabalhar com logística, segurança pública e análise de recursos hídricos.

E agora, fazem duas semanas, tráfego de controle aéreo controle de tráfego aéreo.

...

De DNA a burocracia, de caminhões e cavalos a aeronaves. Tenho certeza que tenho alguma lição pra tirar disso, mas não sei qual :D

O mais engraçado é que, no final de cada sistema, eu (e todo mundo que tinha trabalhado no projeto) sabia mais que muita gente da área. Acho que é efeito colateral de quando você tem que esmiuçar tudo quanto é regra para poder fazer o software. Depois que passa o projeto a memória faz seu trabalho e lentamente você vai esquecendo tudo que aprendeu. Eu me divirto no processo, mas às vezes me parece um tremendo esforço em vão, já que vou esqueçendo tudo. =/

Ginger - Scratch you own itch

3 meses que não escrevo nada... não sei pq insisto em manter um blog :) Vai ver é pro meu ego ter algum lugar onde estravazar.

Já ouvi aquela idéia do "scratch you own itch"? Dizem que muitos produtos legais vêm disso, ou seja, quando o desenvolvedor fica incomodado o suficiente com algo e faz um programa pra resolver seu problema.

Bom, eu trabalho com Java 8 horas por dia (e Ruby nas outras 2 horas) e estou sempre reescrevendo os mesmos utilitários o tempo todo para todo projeto que entro. Então, resolvi "coçar minha coceira" e montar uma lib de uma vez com esses utilitários. Aproveitando para dar uma polida geral neles para ficarem bem bacanas.

Nasce então a "Ginger", uma pretensiosa biblioteca que promete acabar com todos os seus problemas (haha! Silver bullet!!! haha!). Brincadeira! Ginger ainda é pré-adolescente e vai levar um tempo até servir de algo. Mas ela está lá, para quem quiser apreciar e, principalmente, criticar.

Ginger hoje tem um objeto "DuckType", que facilita a parte de reflexão, e estou trabalhando em facilitar expressões regulares e manipulação de texto.

Acabou que me empolguei com umas idéias nessa parte e resolvi fazer umas experimentações. Acho que descobri um jeito de expandir expressões regulares para fazer algumas coisas "impossíveis" do tipo "encontre tudo que não for isso", e facilitar o uso de lookahead e lookbehind, que são sempre complicadas.

É isso aí, opiniões são bem vindas. :)

Sensatez não dá Ibope

(Edição: arrumando acentuação [você não odeia quando essa bagaça zoa com os acentos?])

Eu estava conversando com um colega hoje sobre esse artigo sobre Injeção de Dependência e comentando sobre a polêmica levantada. A conclusão foi "O artigo é bom, mas bem que o Uncle Bob podia ser um pouco mais imparcial; existem casos onde Injeção de Dependência é bom, ele poderia ter falado neles também". Só que se ele tivesse sido imparcial, provavelmente o artigo não teria tanta popularidade :) A gente instintivamente vai atrás de polêmica. Moral da história: "Sensatez não faz sucesso". Taí uma coisa realmente preocupante...