Bolo de Foobar

Pequenas coisas que incomodam em Ruby

2011-07-25T10:08:00.005-03:00

Ruby é uma linguagem maravilhosa, mas tem alguns poréns. O que eu vou citar é algo bem pequeno mas a linguagem está repleta de coisas do tipo.

> class Foo
>   def bar; @bar; end
>   def bar=(other)
>     puts "bar= has been called"
>     @bar = other
>   end
> end

Basicamente escrevemos um setter para um variável.

> foo = Foo.new
> foo.bar = 1
bar= has been called
=> 1

Ok, exatamente como esperávamos.

> foo.bar = foo.bar || 2
bar= has been called
=> 1

Ok, sem surpresas ainda.

> foo.bar ||= 2
=> 1

Ops, notem que bar= não foi chamado.

Portanto, ao contrário do que muitos pensam foo.bar ||= 2 é diferente de foo.bar = foo.bar || 2.

foo.bar ||= 2 só realiza a atribuição se bar não avaliar para uma expressão verdadeira.

É algo muito bobo e muito sútil, mas se o programador realizar alguma computação na atribuição, essa computação pode não ser executada em alguns casos.

Isso não é um grande problema, porém existem diversas coisas do tipo na linguagem. O Matz diz que a linguagem deve ter o comportamento que o programador espera, isso é bom porque a linguagem torna-se natural, mas e casos como esse, o que o programador espera?

Outra coisa decorrente é que isto dificulta outras implementações Ruby 100% compatíveis.

Um novo Object#tap

2011-01-27T16:28:00.007-02:00

Implementação atual de tap:

class Object
  def tap
    yield(self)
    self
  end
end

Mas o Daniel aqui discorda. Minha proposta é:

class Object
  def tap
    yield(self)
  end

  def tee
    yield(self)
    self
  end
end

Object#tap: altera a method chain
Object#tee: não altera a method chain (atual Object#tap)

Para Enumerable, nós temos Enumerable#collect, que funciona exatamente igual ao meu tap.

[1,2,3].collect {|i| i + i} => [2,4,6]

Porém não temos isso para objetos:

1.tap {|i| i + i } => 2

Object#tap executa um bloco na method chain sem altera-la.

[1,2,3].collect {|i| i * i }.tap {|a| puts a.size }.inject {|sum, i| sum + i } => 14 (escreve 3 na STDOUT antes do retorno)

Porém se você quer justamente passar um bloco apenas para alterar a method chain? Não deveria ser justamente essa a função de Object#tap?

[1,2,3].collect {|i| i * i }.tap {|a| a + a }.inject {|sum, i| sum + i } => 28

A origem do atual Object#tap vem do comando tee. Portanto, nada mais justo que:

class Object
  alias tee tap
  def tap
    yield(self)
  end
end

É preciosismo e a discussão é meramente teórica, já que podemos implementar este novo Object#tap com outro nome e evitar o alias, o que exigiria um refactoring de todo código que utiliza Object#tap. Possíveis nomes para meu Object#tap: get, come, become, go e grow. Viajei muito?

Use branches no Git!

2010-02-18T15:42:00.007-02:00

Apesar da ampla adoção do Git, ainda são poucas as equipes que utilizam com eficácia os branchs. Acredito que a culpa disso seja em grande parte pelo baixo uso de branches no SVN ou CVS. Talvez isso tenha até contribuido para criar um certo medo de branches.

Porém, existe ínumeras situações do dia a dia em que o uso de branches irá poupar muito trabalho, viabilizar experimentos ou organizar o desenvolvimento.

É fundamental compreender o uso de branches para que você possa compreender a sua correta utilização.

A diretriz que eu tenho seguido é simples: criar um branch novo para qualquer linha de desenvolvimento. Caso seja necessário o desenvolvimento em conjunto com algum outro desenvolvedor, faça um branch remoto. Fazer pequenos commits irá te ajudar na hora de selecionar um commit defeituoso e a procurar erros com git bisect.

Realize merges entre as linhas de desenvolvimento o máximo de vezes que for permitido. Quanto maior a divergência entre as linhas de desenvolvimento, maior será o número de conflitos e mais díficil será o merge. O momento do merge é um gargalo, pois os conflitos tem de serem resolvidos localmente, ou seja, apenas um desenvolvedor pode resolver os conflitos entre dois merges.

Desconheço qualquer forma de resolver conflitos que não seja local e isso me parece uma limitação grave, se alguém souber de algo ficarei muito contente se me explicar.

Nos primeiros dias que segui essa abordagem, apanhei um pouco do Git (um pouco mais do que o habitual), mas foram os momentos em que mais aprendi sobre o seu funcionamento. Comece nesse exato momento a utilizar branches, mesmo que o seu projeto esteja atrasado 28 dias, 6 horas, 42 minutos e 12 segundos *.

Apenas para o não ficar incompleto, seguem as receitinhas de bolo mais simples para criação e remoção de branches remotos.

Criando um branch remoto

$ git push repos src:dst

repos: Repositório
src: Branch de origem no repositório
dst: Branch de destino no repositório

Deletando um branch remoto

$ git push repos :dst

* Este é o tempo que falta para o mundo acabar quando Donnie Darko encontra Frank pela primeira vez.

Aumentando a segurança do SSH com 3 medidas simples (leiam a conclusão também)

2010-02-08T17:04:00.010-02:00

Aqui vão 3 dicas de fácil implementação e que com certeza aumentarão muito a segurança do seu servidor SSH. Ao alterar a configuração do SSH você deve reiniciar o servidor SSH para que a nova configuração seja carregada.

Arquivos

Configuração do servidor SSH:
/etc/ssh/sshd_config

Reiniciar o servidor SSH:
/etc/init.d/ssh restart

1. Restrinja o uso ao Protocol 2

O Protocol 2 é o padrão, porém, muitas distribuições vem com a configuração padrão Protocol 1,2. A release mais recente do Ubuntu, Karmic, já vem configurada para apenas Protocol 2, porém, muitas vezes temos um sistema que foi atualizado de releases mais atingas sem trocar os arquivos de configuração, portanto vale a pena você verificar quais protocolos o seu servidor SSH está aceitando.

/etc/ssh/ssh_config:
Protocol 2

2. Restrinja o acesso root

Existem diversos usuários que são criados automaticamente nas distribuições. Uma boa distribuição retira a senha destes usuários, impedindo a autenticação através de senha. Porém, muitos administradores configuram uma senha para o root.

A forma mais básica de um script de acesso à força bruta em um sistema funciona da seguinte forma: achar um IP que aceita uma conexão na porta 22 e tentar diversas senhas com o usuário root.

Impedir o login do root já cria uma dificuldade extra: qual usuário utilizar para se logar?

/etc/ssh/ssh_config:
PermitRootLogin no

3. Impeça a autenticação por senha

De nada adianta qualquer outra medida de segurança se as senhas utilizadas forem fracas. Com um pouco de sorte, um ataque de dicionário consegue quebra-las. Podemos implementar diversas políticas de criação de senha, atualização etc. Geralmente essas medidas tendem a piorar o problema, pois elas se sustentam exatamente no aspecto mais falho do sistema: o ser humano.

Impossibilitar a autenticação atavés de senhas e permitir apenas através de troca de chaves ou certificados nos trás dois benefícios: elimina a necessidade de memorização da senha e impede ataques de dicionário.

/etc/ssh/ssh_config:
PasswordAuthentication no

NOTA: É de extrema importância que você já possua ao menos um usuário com as chaves já configuradas e acesso previlegiado ao sistema, do contrário, ao reiniciar o SSH você ficará impossibilitado de se autenticar.

NOTA 2: Você deve configurar as chaves para cada máquina que irá se autenticar com aquele usuário. Isto pode gerar um pequeno trabalho para transportar as chaves públicas das suas máquinas para o servidor de uma vez só. Ex. desktop do trabalho e notebook de casa. É melhor configurar todas as chaves e só depois proibir autenticação por senha.

Conclusão

Estes 3 passos estão longe de ser uma solução completa de segurança, mas acho sejam o mínimo de segurança que devemos prover a qualquer máquina com servidor SSH na internet.

O melhor destas 3 iniciativas é que elas requerem muito pouco trabalho e dão um bom resultado. Isto é muito importante para equipes enxutas aonde uma única pessoa tem diversas roles ou é responsável por diversos servidores.

Outras medidas são o uso de TCP Wrappers, mudança de porta do SSH, knocking doors, lista de usuários que podem se autenticar e mais um infinito de soluções.

PS: Muitas pessoas acreditam que apenas alterar a porta SSH oferece alguma proteção, porém se esquecem que é extremamente simples construir um script que busque uma porta SSH aberta.

Desfazendo no VIm

2009-08-28T14:00:00.011-03:00

O que fazemos quando erramos, desfazemos o erro. Para isso serve a ferramenta undo, tão popular nos mais diversos tipos de editores. Hoje veremos o que o Vim nos oferece para desfazer e refazer a edições.

Desfazendo e refazendo

Desfazer uma ação é extremamente simples, mas pode haver algumas particularidades.

O comando u desfaz a última edição, enquanto o comando CTRL-R refaz a última edição desfeita.

    iFoo
    iBar
    iFooBar
    u            <- Desfazendo iFooBar
    CTRL-R       <- Refazendo iFooBar

Os comandos u e CTRL-R aceitam um count como argumento, portanto, podemos fazer 2u ou 4CTRL-R para desfazer 2 edições ou refazer a últimas 4 edições desfeitas.

Nota: CTRL-R difere de . pois o primeiro refaz a última edição desfeita, enquanto o segundo reexecuta o último comando de edição.

Listas

Listas são estruturas recorrentes em programação. Uma lista é um conjunto de elementos dispostos em um seqüência, aonde um elemento tem um elemento anterior e posterior associado a ele, exceto o primeiro elemento, que não possui o anterior e o último elemento, que não possui um posterior.

Um apontador nada mais faz do que apontar para um determinado elemento de uma lista.

Lista de edição

Uma lista de edição, é uma estrutura que contém as edições realizadas em ordem seqüencial. Os comandos u e CTRL-R simplesmente manipulam está lista para desfazer ou refazer as edições.

     Conteúdo -  Lista de edição
     |        - Alteração feita: iFoo
     Foo
     |        - Alteração feita: iBar
     Foo
     Bar
     |        - Alteração feita: iFooBar <-- Apontador
     Foo
     Bar
     FooBar

Utilizando o comando u:

     Vazio
     |      Alteração feita: iFoo
     Foo
     |      Alteração feita: iBar        <-- Apontador
     Foo
     Bar
            Alteração desfeita: iFooBar

Utilizando o comando u novamente:

     Vazio
     |      Alteração feita: iFoo        <-- Apontador
     Foo
            Alteração feita: iBar
            Alteração desfeita: iFooBar

Utilizando o comando CTRL-R:

     Vazio
     |      Alteração feita: iFoo
     Foo
     |      Alteração feita: iBar        <-- Apontador
     Foo
     Bar
            Alteração desfeita: iFooBar

Quero mais!

Depois que você pega o jeito, editar no VIm é uma delícia. Desfazer uma ação é extremamente freqüente e a tecla u em teclados QWERTY é facilmente acessada.

Undo é um assunto extenso dentro do VIm pois ele envolve a função básica de editação. Outros tópicos interessantes são: bloco de edição, arvore de edição e timeline de edição. Estes dois últimos serão abordados futuramente, pois são de ampla utilidade.

Para os mais impacientes ou curiosos, vocês podem obter TUDO sobre undo no help, pesquisando sobre undo ou no capítulo 32.

  :help undo
  :help 32

Shell no VIm com agilidade

2009-08-03T14:01:00.008-03:00

Muitas vezes você está editando no VIm e precisa executar algo no shell, pegar algum output ou simplesmente ir embora para casa. Hoje vamos ver algumas soluções que o VIm nos oferece para essas situações, mostrando porque ele é O editor.

Suspendendo o VIm

Para mim essa é a solução mais elegante que existe, porém ela é baseado no uso do Bash como shell e para mim a beleza consiste nessa junção Bash + VIm. Não sei como funciona e se funciona em outros shells.

Quando o Bash está com o Job Control ligado, ao inicializarmos um processo, ele ‘herda’ do Bash o tratamento de alguns sinais, um deles é o SIGTSTP. O tratamento do SIGTSTP suspende o processo, retornando o controle do terminal ao Bash. A maioria dos terminais mapeia o SIGTSTP para as teclas Ctrl-Z, mas isso é uma configuração do terminal, não do Bash. Você pode verificar a configuração do seu terminal utilizando:

$ stty -a

A beleza disto, é que o VIm não sobrescreve o tratamento do SIGTSTP herdado do Bash, portanto, você podê suspender o seu VIm! Com isso, você retornará o controle do terminal ao processo Bash pai do VIm. Você pode executar quantos comandos forem necessários e depois retornar o controle do terminal ao VIm utilizando o fg.

$ vim foo

Edição, edição, edição
Voltando para o Bash
Ctrl-Z

Tarefas que queremos executar no Bash...
$ rake db:migrate

Voltando para o VIm
$ fg
De volta ao VIm

Outro modo de obter um shell é através do comando :sh ou :shell.

:sh

Para retornar ao shell, Ctrl-D (EOF) ou exit.

O shell criado depende do valor da variável ‘shell’ do VIm.

:set shell

Executando dentro do VIm

Para executar um comando simples, como remover um arquivo, obter uma listagem de diretório, executar uma migration, basta utilizar :!.

:!ls

Você pode especificar um ponto para o qual deseja enviar a saída do comando.

:.!ls
:0!ls
:$!ls

Um atalho para :.! é !!.

Nota: !! é diferente de :!!, o segundo re-executa no shell o último comando executado anteriormente.

Criando uma sessão

Você está no meio de um trabalho pesado: 4 arquivos em edição, outros 10 na buffer list, um monte de marcadores, alguns lugares na stack.

Porém chegou a hora do seu merecido descanso, mas não quer perder o ambiente da edição. Deixar o computador ligado é uma solução, mas a energia pode acabar, sem contar o desperdício.

O segredo é salvar uma sessão do VIm e carrega-la posteriormente. Pode parecer complicado, mas é extremamente simples: :mks ou :mksession, você pode passar como argumento o nome da sessão, do contrário, o arquivo padrão é Session.vim.

:mks

O arquivo gerado nada mais é quem um aglomerado de opções e comandos do VIm. Portanto, para carregar de volta uma sessão, basta ‘executar’ o script com o comando :source ou :so.

:so Session.vim

O mais provável é que você vá carregar uma sessão a partir do terminal.

$ vim -S Session.vim

Por padrão, a opção -S carrega o arquivo Session.vim, portanto o comando abaixo tem o mesmo efeito.

$ vim -S

Conclusão

Parece que perdemos um pouco da cultura de ferramentas especializadas do UNIX. Hoje é normal quererem fazer tudo no seu editor preferido, na sua linguagem preferida etc. Eu acho isso uma bobagem que, em minha opinião, é fomentada por grandes empresas que espalham a todos que sua solução é completa: o desenvolvedor que sabe XYZ não precisa saber mais nada.

A relação disto com as dicas é indireta mas muito importante.

Perdemos um tempo considerável para achar uma solução pura no VIm, Ruby, o que for, mesmo existindo ferramentas UNIX próprias para a função. Hoje aprendemos como trocar agilmente do shell para o VIm e vice-versa, mostrando que faz parte do VIm colaborar com essas outras ferramentas.

Obtendo código fonte dos pacotes da sua distro

2009-07-22T18:55:00.020-03:00

Por que não baixar direto do site oficial?

O código do projeto pode diferir da sua distribuição. Isso pode acontecer por diversos motivos:

A distro pode não adotar a última release.

No Ubuntu, por exemplo, os pacotes são 'freezados' depois de uma release de uma versão e as atualizações geralmente são apenas para corrigir falhas de segurança e estabilidade. Apenas na próxima versão do Ubuntu você terá pacotes atualizados.
A distro pode alterar o código fonte para adequar aos seus propósitos.

De um modo geral, cada distribuição tem um foco específico, por exemplo, facilidade. É comum distribuições com ênfase em segurança aplicarem 'patches' próprios ou de terceiros.
A distro pode 'quebrar' um projeto em diversos pacotes.

Alguns módulos do Apache, por exemplo, que são distribuídos no código fonte oficial, estão espalhados em diversos pacotes no Ubuntu.

Através de arquivos .deb

Por padrão os arquivos deb ficam cacheados, basta copia-los para o local desejado e 'abri-los'. O local padrão de cache é /var/cache/apt/archives/. O aplicativo ar serve para abrir os arquivos .deb.

$ cp /var/cache/apt/archives/nome-do-pacote
$ ar x nome-do-pacote

Utilizando o APT para obter os pacotes

Para obter o código fonte do pacote não é necessário qualquer permissão, visto que nada será alterado no sistema, apenas iremos baixar o pacote. Este pacote pode diferir do que foi instalado, pois o código fonte é baixado de outro repositório assinalado por deb-src. Isto explica os diversos deb-src que podem haver na sua source list.

$ apt-get source nome-do-pacote

Com isso, obteremos 3 arquivos:

.orig.tar.gz: arquivo original;
.diff.gz: arquivo com as diferenças entre o original e a distribuição;
.dsc: arquivo que descreve o pacote do código fonte;

Sem parâmetros adicionais, apt-get source irá efetuar o download, descompactar os arquivos .gz e aplicar o diff. No final teremos um diretório com o código fonte que obteríamos caso fizéssemos um apt-get install ou um apt-get update (Isto partindo do pressuposto que os repositórios deb e deb-src estejam condizentes, o que acontece numa condição normal).

Por que utilizar o código fonte de um projeto?

Para a coisa mais preciosa que existe: estudar.

Bolo de Foobar

Pequenas coisas que incomodam em Ruby

Um novo Object#tap

Use branches no Git!

Criando um branch remoto

Deletando um branch remoto

Aumentando a segurança do SSH com 3 medidas simples (leiam a conclusão também)

Arquivos

1. Restrinja o uso ao Protocol 2

2. Restrinja o acesso root

3. Impeça a autenticação por senha

Conclusão

Desfazendo no VIm

Desfazendo e refazendo

Listas

Lista de edição

Quero mais!

Shell no VIm com agilidade

Suspendendo o VIm

Executando dentro do VIm

Criando uma sessão

Conclusão

Obtendo código fonte dos pacotes da sua distro

Por que não baixar direto do site oficial?

A distro pode não adotar a última release.

A distro pode alterar o código fonte para adequar aos seus propósitos.

A distro pode 'quebrar' um projeto em diversos pacotes.

Através de arquivos .deb

Utilizando o APT para obter os pacotes

Por que utilizar o código fonte de um projeto?