Faz alguns meses, e decidimos, eu e o Emanuel Zabka, implantar o TDD no desenvolvimento na empresa em que trabalhamos. Academicamente é falado muito em refactoring e mudanças de requisitos, mas na prática, eu nunca havia notado a quantidade de modificações que um mesmo código/classe/arquivo é modificado num curto período de tempo e a longo prazo.

Os testes me ajudaram a enxergar, não só as dependências do sistema, como também, acoplamentos desnecessários; a qualidade dos códigos; do design do projeto; e, consequentemente, diminuiu muito os bugs mais corriqueiros, como validação de campos. Mesmo tendo várias coisas boas, há coisas ruins, como aumento do tempo de desenvolvimento – o que, apesar de nunca ter medido, diminui o retrabalho e tempo utilizado no futuro em correções de bugs -, aumento da complexidade da arquitetura – a fim de manter uma maior coesão com baixo acoplamento, entre outros menos relevantes.

Unit Test

The basic concept of unit testing is write more code which will test the main code we’ve written, by “throwing” sample data at it and examining what it gets back.

Harry Fuecks

Enfim, uma boa definição de testes unitários é esta supracitada. São escritos mais códigos para testar o código principal, utilizando dados de testes para analisar o comportamento e o retorno do código sendo testado.

CakePHP

• Framework de desenvolvimento rápido pra Web com PHP
• Utiliza padrões MVC e ORM
• Extensível para desenvolvimento, manutenção e deploying.
• OpenSource / Comunidade muito ativa e amigável
• Orientada a Objetos
• Mais detalhes sobre o CakePHP

SimpleTest

• Praticamente mesma coisa que JUnit, JMock e PHPUnit.
• Guiado através de asserções
• Possibilidade navegação em requisições HTTP para testar interface gerada (HTML)
• OpenSource
• Orientada a Objetos
• Mais detalhes sobre o SimpleTest

CakePHP e SimpleTest

• Startup (criação do arquivo, casos de testes básicos) dos testes unitários automaticamente
• Customizações no template de Report (Web com template padrão)
• Rápida execução de testes individualizados
• Rápida execução de grupos de testes (execução de vários testes unitários sequencialmente)
• Pode-se usar Mock para objetos internos do CakePHP ou da aplicação
• Pode-se testar aplicação toda (APP + Plugins)
• Pode-se testar somente a aplicação (APP)
• Pode-se testar plugins separadamente
• Pode-se testar em modo batch
• Integração dos dois frameworks

Convenções e Padrões

Para o SimpleTest não há padronização no nome dos arquivos, mas o CakePHP estabelece um a partir da convenção das classes utilizados por ele. Ex: respectivamente as classes de controller e model de um Post:

PostController

tests/cases/controllers/post_controller.test.php

Post

tests/cases/models/post.test.php

• O nome da classe contida no arquivo é derivado a partir do nome do mesmo.
• Esta classe deve extender a classe CakeTestCase ou CakeWebTestCase
• A assinatura dos métodos que contém asserções (métodos de teste) devem iniciar com “test”, como em testPostControllerAddPost().
• Métodos que são executados como eventos:

  start()

  Primeiro método chamado. Executado quando se iniciam os testes

  end()

  Último método chamado. Executado quando se concluí todos os casos testes

  startCase()

  Executado antes do caso de teste começar a ser testado (lembrando que um teste pode ser composto de um ou mais casos de teste)

  endCase()

  Executado depois que o caso de teste foi testado por completo

  before($method)

  Anuncia o início de um método de teste

  after($method)

  Anuncia o término de um método de teste

  startTest($method)

  Executado antes de um caso de teste iniciar

  endTest($method)

  Executado depois que um caso de teste termina

Mais detalhes sobre as convenções

Fixtures

Fixtures são uma forma de utilizar dados de teste. São matrizes de dados que correspondem à registros em um banco de dados.
Cada Model possui uma Fixture, que irá não só ter os dados como a representação dos campos que compõe a tabela do banco, pois a partir destes dados o framework irá:

1. Criar uma tabela prefixada (por padrão) de “test_suite_” no banco de dados para cada fixture necessário (ou seja, cada model utilizado).
2. Inserir os dados de teste na tabela de teste
3. Executar os testes em cima destes registros
4. Remover os dados da tabela de teste
5. Remover a tabela no banco de dados.

Ou seja, assim é garantido que os dados serão sempre os mesmos e que não comprometerá a base de dados atual com sujeira, podendo-se executar
estes testes a qualquer momento atrás de problemas. Testes que envolvem banco de dados com índices únicos, chaves primárias ou outras constraints
estão livres de erros (erros não propositais) durante os testes.

Veja mais sobre Fixtures

Asserções

• assertTrue($x)
• assertFalse($x)
• assertNull($x)
• assertEqual($x, $y)
• assertIsA($object, ‘ClassName’)
• assertIdentical($x, $y)
• assertPattern(’/REGEX/’, $x)
• expectError();

Se você se interessou, para mais detalhes sobre os testes unitários no CakePHP, recomendo a leitura deste post da Debuggable: Unit Testing in CakePHP Part 1 – Introduction to Unit Testing

Agradecimentos especiais a André Leitzke e Viviane de Souza por terem me ajudado com a caracterização e descrição do framework!

Para mais informações http://www.tchelinux.org/2009. As palestras serão:

VIM-de a mim, produtividade

Uma palestra que mostra maneiras para um edição de texto efetiva e rápida usando o vim.

jQuery – Introdução

Apresenta o porquê do jQuery ser um excelente framework para desenvolvimento rápido com javascript.

Se alguém tiver assistido a alguma palestra, favor dar um feedback!!!

• Certeza de encontrar todas as incidências
• Ficam visualmente destacadas (com :set hlsearch)
• Testar substituições
• Verificar a ortografia atrás de erros de digitação
• Encontrar variáveis ou funções não utilizadas, só declaradas
• Encontrar rapidamente algum termo
• Verificar a existência de algum termo

Além da conhecida / (barra) para buscar, existe o :vimgrep. É dele que quero falar.

Vimgrep

Comando

:vim[grep][!] /{pattern}/[g][j] {files}

• Busca inscidências de pattern nos files listados.
• pattern pode ser uma expressão regular ou não
• A exclamação (!) ignora as alterações já feita no arquivo atual
• g procura por todas as inscidências, não só a primeira, em cada arquivo
• j pula para o primeiro resultado ao executar o comando
• files podem conter wildcards, como *, ? e **
• Os resultados são abertos na quickfix list

Exemplos

:vimgrep! /$var/ arquivo.pl

Pesquisa pela primeira inscidência de $var no arquivo.pl

:vimgrep /texto/ *.rb

Busca por texto em todos os arquivos com a extensão .rb do diretório atual (para descobrir qual o diretório atual, use :pwd. Para mudar :cd dir)

:vimgrep /TeXtO/ *.py dir/*.py

Busca com case-sensitive em todos os arquivos .py do diretório atual e dos dentro do diretório dir/.

:vimgrep /minhaFuncao/g **/*.c

Busca recursiva dentro da árvore de diretórios do diretório atual cuja extensão seja .c

:vimgrep /< \([^ ]\+\)[^>]*>.\+< \/\1>/ index.html

Busca usando expressões regulares também são permitidas!

Navegando na QuickFix List

• :copen
• :cfirst
• :cprevious
• :cnext
• :clast
• :cclose

Como nosso foco é a eficiência, podemos criar mapeamentos para andar pela quickfix list!

map <F9> :copen<CR>
map <F10> :cclose<CR>
map <A-j> :cnext<CR>
map <A-k> :cprevious<CR>

Exemplo de uso do vimgrep

Conclusão

Esse recurso não parece ser muito abordado por ai, mas é extremamente importante. Seja criativo e descubra onde melhor usar o :vimgrep! Tenho certeza de que vai lhe ajudar! E quando encontrar, comente ai!

Inaugarado o blog da F1 Soluções, que não é a empresa na qual trabalho, mas é do mesmo sócio e ainda tenho grande participação no processo de desenvolvimento de software da mesma, eu resolvi postar algumas coisas lá. Fiz, então, meu primeiro post sobre engenharia de software. O post se chama Filosofando sobre Engenharia de Software.

Críticas aqui ou lá, lerei os dois comentários. Até mais!

Baseado nisso e no comentário que recebi recentemente e inspirado pelo post de um amigo, vou fazer uma lista de coisas que proponho. São coisas simples, mas que facilitam na manutenção.

Umas das coisas que aprendi com Uncle Bob (Robert C. Martin), no seu livro Clean Code foi: escrevemos o código apenas uma vez, porém o mesmo é lido várias vezes. Então, não custa usarmos 5min a mais documentando alguma coisa ou escrevendo variáveis legíveis, que nos pouparão tempo mais tarde!

1. Clareza e objetivadade nos nomes das variáveis

É incrível como as pessoas conseguem dar nomes criativos para variáveis. O alfabeto tem tantas letras que formam tantas palavras, por que insistem em usar apenas 1 letra como nome de variável? Pior, Por que usar sempre as mesmas?

$d = 3;
$dias = 2;

A primeira variável simplesmente não diz nada. Olhando ela não se consegue ter noção nenhuma do que ela representa, o que é o 3? Do mesmo modo se aplica a segunda variável, sabemos que são 2 dias, mas 2 dias não nos diz nada também. Olhando assim, só sabemos a unidade de medida!

$dia_vencimento = 3;
$qtde_dias_para_pagamento  = 2;

Há quem reclame do tamanho das variáveis. Mas hoje em dia, que editor não auto-completa para você? Se o seu não, por favor, considere trocar =).

O que se deve cuidar ao se nomear uma variável, é não por algum nome que venha a ter mais de uma possibilidade de significado. Por exemplo:

$valor_frete_desconto = 11.3;

O valor acima citado, é referente ao desconto dado ao frete, ao valor do frete a ser descontado ou o valor do frete com o desconto? Eu não afirmo nenhuma hipótese à partir do nome dado. Se me perguntarem, eu diria que olharia o código para afirmar. Por tanto, seja CLARO E OBJETIVO.

$valor_frete = 13.4;
$valor_desconto_frete = 2.3;
$valor_frete_descontado = $valor_frete - $valor_desconto_frete;

Caso o desconto do frete seja aplicado com porcentagem:

$pct_desconto_frete = 10;
$valor_frete = 13.4;
$valor_desconto_frete = $valor_frete * ($pct_desconto_frete / 100);
$valor_frete_descontado = $valor_frete - $valor_desconto_frete;

A melhor coisa em relação às variáveis é justamente o fato de omitir o valor atrás de um nome inteligível. Por tanto, sempre que possível, esconda os valores, a legibilidade aumenta muito!

    $arr_usrs = array();
    for ($i = 0; $i < count($users); $i++) {
        if ($users[$i][3] == 4)
            $arr_usrs[] = $users[$i];
    }
    return $arr_usrs;
}

Pergunto:

• $arr_usrs é uma lista gerada à partir de que dados?
• O que é o índice 3 do array usado no if ?
• O que diabos quer dizer == 4?
• O que devo esperar que $arr_usrs contenha?

define("STATUS", 3);
define("ATIVO", 4);
    $contatosAtivos = Array();
    for ($i = 0; $i < count($contatos_do_usuario); $i++) {
        $contato = $contatos_do_usuario[$i];
        $status_do_contato = $contato[STATUS];
        if ($status_do_contato == ATIVO)
            $contatosAtivos[] = $contato;
    }
    return $contatosAtivos;

Acho que não preciso explicar o código, não é?

Outra coisa interessante, CUIDADO com as variáveis de duplo sentido.

$total = count($usuariosDoBanco);

$total recebeu o total de usuários do Banco de Dados ? o total de usuários de um determinado banco (BB, Santander, etc) ?

Sugestão:

$total = count($usuarios_cadastrados);

ou, para o outro caso

$total = count($clientes_santander);

Eu sei que muitas vezes é difícil escrever códigos de forma bonita, mas o esforço vale a pena! Além de ser um diferencial profissional, trabalhar no meio da zona é prejudicial a você mesmo!

Lembrou de algo? Tens outras dicas? Comenta aê!

Quando eu vou escrever em algum programa de qualquer suíte de escritório – openoffice, koffice, etc -, eu geralmente me preocupo mais com o negrito da palavra, com identação do parágrafo do que com o conteúdo em si. Isso é um pecado.

Meu primeiro instinto foi: vou escrever tudo no Vim, depois colo no Impress. Boa! Ok, mas e quanto às páginas?
Vou ter que por página por página? Ainda sim eu teria mais trabalho. Eu teria que refazer as listas para que ficassem com as “bolinhas” à esquerda. E teria que modificar todos os títulos para negrito?

Fui pro google e achei um plugin que já conhecia no resultado: VimOutliner. Ele dita uma sintaxe muito intuitiva para hierarquisar (existe esse verbo?) o conteúdo. Algo assim:

Título do documento
 
Tópico Nível 1
	Tópico Nível 2
	: Parágrafo com alinhamento justify
	; Parágrafo fica do jeito que foi escrito
	- Item de lista
	+ Item de lista numérica

O plugin vem com documentação e um shell script que instala automaticamente o plugin. O site tem toda documentação, é bem simples.

Em http://perens.com/FreeSoftware/Outline/ é possível encontrar vários scripts que convertem o documento para outros formatos. Um deles é o vo2odp.rb, um script em ruby para converter arquivos para o OpenOffice Presentation.

Pra fazê-lo rodar, eu sofri um pouquinho. Tive que instalar o ruby (obviamente) e o rubygems. Depois de instalado:

$ gem install builder
$ gem install rubyzip

Também alterei o script, segue o patch das modificações:

29,30c29,30
< require_gem 'builder'
< require_gem 'rubyzip'
---
> require 'builder'
> require 'zip/zip'

Copie o trecho acima em um arquivo, por exemplo: /tmp/patch_vo2odp, depois execute

$ patch /caminho/para/vo2odp.rb < /tmp/patch_vo2odp

Pronto, agora só escrever sua apresentação. Lembre-se que o plugin tem uma extenção própria, a .otl. Sempre que um arquivo for aberto com esta extenção, o Vim irá carregar o syntax highlight apropriado e algumas outras opções para melhor escrever sua apresentação.

Concluída a apresentação, você pode usar

$ ruby /caminho/para/vo2odp.rb apresentacao.otl apresentacao.odp

Abra com o OpenOffice e salve como .ppt. Pronto! Você acabou de fazer sua apresentação no PowerPoint pelo Vim.

Observações importantes

• O script não quebra as páginas dos slides automaticamente. É separado por capítulos de nível 1. Então, não escreva coisas muito longas dentro de um nível. Lembre-se que é uma apresentação e não um documento de texto.
• Quando aberto no OpenOffice, use o negrito, sublinhado, coloque imagens, etc. Crie seu layout e não pense nisso durante a criação do conteúdo. Escreva antes e formate depois

E isso ai! Gostou? Não? Comente! Dê dicas e sugestões!

Parece radical, mas a produtividade aumenta, de certo modo. Não só na hora de programar e testar, sempre que edito arquivos no Vim, tento não usar o mouse. Claro que sempre vai ter alguma aplicação que vai te obrigar a usar o mouse, mas se pudermos evitar, melhor!

Eu continuo com esta idéia. Coisinha bonita é para cliente final. Desenvolvedores devem trabalhar com ferramentas que proporcionam o melhor uso do tempo possível, pois o bom profissional é aquele que esbanja do ócio, eis o fluxo:

• Concluir as atividades rapidamente com eficácia e eficiência está diretamente ligado ao ócio, pois se ele tivesse feito algo mal feito, estaria corrigindo os bugs e não vendo vídeos no youtube.
• Com tempo livre, o cérebro humano fica mais descansado e mais propício a receber insights/intuições para resolver problemas difíceis, que – e estes merecem – precisam de mais tempo e necessitam ser bem planejados.
• Resolvendo problemas de forma criativa – talvez até inovadora -, faz com que se evite problemas futuros. Logo, se poupa tempo. Se poupando tempo, voltamos a cláusula anterior.

Parece utópico, mas eu acredito nisso. Eu acho que é possível. Basta saber onde conseguir ganhar tempo em atividades, automatizando com scripts, programas e etc, o tempo é consequência.

Todo Desenvolvedor Web já foi ou ainda é DBA. É inevitável aprender a utilizar banco de dados sem modelar os dados. Geralmente, para isso, é utilizado alguma ferramente gráfica que auxilia na visão do modelo. Não vou citar, mas existem várias para isso.

Porém, há um detalhe que muitos não se atinaram ainda. Me dei conta disso assistindo uma palestra no FISL10, na palestra do Leandro Dutra (se for parente, é primo de muitos graus :S) chamada O elefante ilustrado: modelagem literária e documentação automática em PostgreSQL e outros SGBDs livres.

SchemaSpy

O que é?

É uma ferramente que varre um banco de dados e gera um documentação em HTML nevegável. Ela gera gráfico de chaves estrangeiras utilizando o GraphViz (.dot), como se fosse uma dessas ferramentas que terminam com Designer.

Esses gráficos gerados, são visivelmente bonitos e dispostos. Ou seja, não é mais necessário sofrer arrastando caixinhas de modo com que fique bem arrumado. O programa tem um bom algoritmo para organizar. O que possibilita que o DBA, ou o desenvolvedor mesmo, use este tempo para repensar uma constraint, uma foreign key, etc.

O HTML gerado também tem abas que diferenciam os conteúdos: abas para relacionamentos, abas para tabelas auxiliares, abas para listagem de colunas/tabelas, etc. Mostra os campos, o tipo dos campos, os comentários, valores em comum e as CONSTRAINTS. Ou seja, uma solução completa para documentação de bancos de dados e modelos de ER. Vem junto o jQuery, que da uns efeitos e toggleia algumas colunas das tabelas de exibição.

Onde conseguir?

O site oficial deles é http://schemaspy.sourceforge.net. Pode ser baixado de lá. Apenas o driver jdbc para o banco de dados que for ser usado deve ser encontrado separadamente.

Quem usa ArchLinux, pode baixar os repositórios do AUR. Eu mesmo sou o mantenedor do pacote, então, qualquer dúvida ou problema, comente lá que tentarei responder/resolver o mais rápido possível. O link do repositório é http://aur.archlinux.org/packages.php?ID=28022

Como usar?

Para usar é muito simples. Depois de baixar o .jar, apenas execute

$ java -jar /path/to/schemaSpy.jar --help

Ou, se você instalou o do repositório do ArchLinux, basta usar:

$ schemaspy --help

Ele vai listar os parâmetros, é bem simples. Não vou me deter a isso. Qualquer dúvida comente no post abaixo.

Um exemplo de output pode ser encontrado na própria página do SchemaSpy: http://schemaspy.sourceforge.net/sample/

Sugestoẽs

Se existe algum defeito nele, com certeza é o template. O HTML gerado não é o mais bonito. Não obstante, me parece que o template não é customizável, para isso seria necessário hackear a classe que gera o template. Mas, quem sabe não é implementado algo nas próximas versões? Quem sabe VOCÊ não implementa?

Mas bem, falando em sugestões, aqui vai algumas:

• Integrar com a documentação do phpDocumentor, javaDoc ou outro similar.
• Versionar a documentação gerada para avaliação de crescimento da aplicação: poder comparar como era há certo tempo atrás e como está hoje.
• Programar os SQL’s utilizando algum editor de texto, fazendo você ganhar desempenho e analisar mais facilmente para comentários, constraints, triggers, procedures e views, que são geralmente mais complexas de serem vistas em programas gráficos.

Mais alguma sugestão? Críticas? Deixem nos posts abaixo!

E aquela palavra que você sempre escreve errada? Aquela função que você sempre esquece o nome?

Conheça algumas dicas para aumentar a produtividade e diminuir o trabalho dessas coisas rotineiras.

Lista de Abreviaturas

Sabe aquelas palavras que a gente insiste em escrever errado? Principalmente quem trabalha com e-mails, códigos e comentários em outras línguas tem dificuldades com certas palavras. Por exemplo,

vc -> você
q -> que
pq -> porque
nao -> não

Agora a pergunta que não quer calar: Porque não usarmos algo para evitar esse tipo de coisa? Às vezes nem notamos os erros, mas eles estão lá. Mantenha uma lista de abreviaturas no Vim. Cuide dela, adicione novas abreviaturas assim que vierem à sua cabeça. A sintaxe é simples, basta adicionar no seu .vimrc:

"" abbr ERRADO CORRETO, por exemplo:
abbr pq porque
abbr vc você

O Vim ainda possibilita que você crie sintaxes diferentes para arquivos diferentes. Então, seus arquivos .txt podem ter abreviaturas diferentes das de .py. Ou seja, se o nome daquela função python é muito longa ou você insiste em escrevê-la errada, ela merece uma abreviatura, no formato descrito acima (abbr ERRADO CORRETO).

$ mkdir -p ~/.vim/abreviaturas/
$ vim ~/.vim/abreviaturas/txt.vim

Adicione ao txt.vim as abreviaturas utilizadas para arquivos texto. Mesmo que poucas, coloque algumas. Um pouco de disciplina fará com que sua produtividade aumente. Tenha certeza.

Ao seu .vimrc, basta acrescentar:

autocmd BufNewFile,BufRead * source $HOME/.vim/abreviaturas/para_qualquer_linguagem.vim
autocmd BufNewFile,BufRead *.txt source $HOME/.vim/abreviaturas/txt.vim
autocmd BufNewFile,BufRead *.py source $HOME/.vim/abreviaturas/python.vim

O autocmd funciona mais ou menos igual a uma trigger. É um sistema de eventos, basicamente. Ou seja, ao abrir um arquivo novo (BufNewFile) ou um arquivo já existente (BufRead), se o nome do arquivo casar com a expressão (no caso, *, *.txt ou *.py) irá executar o código a seguir.

Vou falar mais sobre o autocmd em outro post, tem muitoooo pano pra manga, hehehe.

Templates de Arquivos

Quando se fala em programação é meio que como na arte. Não só porque programar é uma arte, mas porque nada se cria, tudo se copia. Tudo bem que, hoje em dia, com técnicas de encapsulamento, oop, etc, fica mais difícil. Mas sempre há coisas em comum entre os arquivos. Vamos começar com algo simples.

Template básico para javascript, onde será utilizado jquery.

$(document).onready(function(){
// code here
});

Simples, mas não é um saco ter que escrever isso sempre que abre um arquivo novo? Tome isso como regra: Faça uma, porém apenas uma vez. Não seria mais fácil abrir o arquivo e tcha-ram! Lá está o código que, em 90% dos casos, você irá utilizar?

Esse foi pequeninho, mas imagine um arquivo html. A trabalheira que é copiar todo o caçalho. E se você segue um padrão, pode usar inclusive o css junto. Observe:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

< !DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="pt" lang="pt-br" dir="ltr">
	<head>
		<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
		<meta http-equiv="Content-Style-Type" content="text/css" />
		<meta name="keywords" content="aqui,vai,as,keywords" />
		<link rel="stylesheet" href="/style.css" />
		<link rel="shortcut icon" href="/favicon.ico" />
        </head>
        <body>
        <div id="wrapper">
                <div id="head"></div>
                <div id="content"></div>
                <div id="footer"></div>
        </div>
</body></html>

E o css:

1
2
3
4
5
6
7
8
9
10
11
12

html * {
}
body {
}
#wrapper {
}
        #wrapper #head {
        }
        #wrapper #content {
        }
        #wrapper #footer {
        }

Imagine um designers, aqueles que fazem o psd e depois passam pra xhtml, tendo que copiar isso vezes e vezes para todos os arquivos que ele faz. Faça apenas uma vez e siga o padrão!

Usuários de django, ao criar um model, precisam escrever sempre os imports ? Se são utilizados sempre, porque não criar um template?

Agora você me pergunta, como carregar o template automagicamente no Vim ? Fácil! Utilizando nosso autocmd =). Do mesmo modo que fizemos com as abreviaturas, vamos criar os diretórios:

$ mkdir -p ~/.vim/templates/

Criei lá os arquivos com os templates que você acha útil.

autocmd BufNewFile *.html 0r ~/.vim/templates/html.tpl
autocmd BufNewFile style.css 0r ~/.vim/templates/cssstyle.tpl
autocmd BufNewFile jquery.*.js 0r ~/.vim/templates/jqueryjs.tpl

Agora, abra seu Vim e sinta a magia:

vim index.html style.css jquery.initscript.js

Executando comandos externos

g(un)zip

O manual do Vim tem um exemplo bem interessante, para abrir arquivos gzipados, editá-los, como se nada tivesse acontecido e salvá-lo no formato gzip de novo. Apesar de que aqui, não precisou acrescentar os códigos abaixo, ele já fez automático. Basta adicionar o .vimrc

augroup gzip
  autocmd!
  autocmd BufReadPre,FileReadPre	*.gz set bin
  autocmd BufReadPost,FileReadPost	*.gz '[,']!gunzip
  autocmd BufReadPost,FileReadPost	*.gz set nobin
  autocmd BufReadPost,FileReadPost	*.gz execute ":doautocmd BufReadPost " . expand("%:r")
  autocmd BufWritePost,FileWritePost	*.gz !mv <afile> </afile><afile>:r
  autocmd BufWritePost,FileWritePost	*.gz !gzip </afile><afile>:r
 
  autocmd FileAppendPre		*.gz !gunzip </afile><afile>
  autocmd FileAppendPre		*.gz !mv </afile><afile>:r </afile><afile>
  autocmd FileAppendPost		*.gz !mv </afile><afile> </afile><afile>:r
  autocmd FileAppendPost		*.gz !gzip </afile><afile>:r
augroup END
</afile>

Verificação por erro

Já deve ter acontecido com você: você salva o arquivo e quando vai testar, faltou um ponto e vírgula, ou escrever o nome de uma função errada, ou algo similar… um erro bobo, mas que não deixou seu código ser executado e exige reparo.

Para ajudar contra esse trabalho desnecessário (teste + correção + teste), que pode se repetir inúmeras vezes, você pode usar o autocmd para alertá-lo, utilizando ferramentas externas. Por exemplo:

autocmd BufWritePost *.pl !perl -c %
autocmd BufWritePost *.php !php -l %
autocmd BufWritePost *.java !javac -Xlint %

Use a criativdade

Utilize sua criatividade e seja mais produtivo na SUA rotina. Deixe as coisas serem automatizadas. Para mais eventos do autocmd, :help autocmd. Tem uma lista bem extensa. Leia a documentação e seja feliz =). Crítias, sugestões e CASES são bem vindos nos comentários =)