Esse post é para fazer uma retrospectiva do primeiro coding dojo de Ruby em Porto Alegre.

O dojo foi organizado pelo Cabral (@felipebcabral) aqui da Softa com o apoio do Carlos Villela (@cv) da ThoughtWorks Brasil e do Miguel Grazziotin (@Miguelgraz) do Dojo-POA (http://groups.google.com/group/dojo-poa). O problema foi escolhido e conduzido por este que vos escreve (@dbiazus).

Confesso que o problema escolhido não foi o mais adequado para um dojo, mas eu tive a melhor das intenções. A idéia era mostar para o pessoal uma estrutura clássica de implementação de linguagens de programação, a AST. A árvore abstrata de sintaxe (abstract syntax tree) é uma representação da estrutura sintática de código escrito em alguma linguagem formal.

O problema parece muito abstrato, mas foi inspirado por algo bem prático. A origem da idéia foi o post sobre a implementação do ARel, o motor relacional por trás da camada de banco de dados do Rails 3. O autor (@tenderlove) comenta que usando estruturas simples usadas em implementação de linguagens ele teve grandes ganhos no código utilizado. Então a idéia foi trazer parte desses conceitos para o dojo.

Imaginemos que queremos interpretar uma linguagem para manipular dados baseada em algebra relacional. Abaixo alguns exemplos de código:

1
2
3
4

π foo bar (baz ⋈ qux)
π foo bar σ corge = grault (baz ⋈ qux)
π foo bar σ corge = grault AND garply = waldo (baz ⋈ qux) 

Para interpretar o código faríamos um parser do zero, usando um pouco de expressões regulares. O resultado (para a primeira expressão do exemplo) deveria ser uma árvore em memória como a que está abaixo.

O pessoal que estava presente se saiu muito bem e chegamos a finalizar um analisador léxico e iniciar a parte de sintaxe, nada mal para um sábado de manhã. O código produzido está no meu perfil do github. Além disso fiquei muito contente pelo ambiente de desenvolvimento (com o meu editor favorito) ter ficado nos pontos positivos.

Abaixo os pontos positivos e nagativos levantados no final da manhã:

Pontos positivos:

• Café liberado pela TW
• Pãozinho de queijo show de bola
• Ambiente bacana
• Condução
• Autospec
• Ambiente de desenvolvimento (VIM)
• Horário
• Local de fácil acesso
• Bastante gente
• Almoço pós-dojo

Pontos negativos:

• Filtro de café pequeno
• Luminosidade da projeção
• O problema foi abstrato demais
• Ambiente de desenvolvimento (VIM)
• A quantidade de emails não lidos do Diogo
• Lembretes
• Notebooks (dispersão)

Permalink | Leave a comment  »

Olá! Hoje estamos lançando nosso site novo, agora mais informativo. Queremos mostrar um pouco mais o que pensamos e que tipo de empresa somos. O site será single page, com todas as informações na mesma página e cada parte com um visual diferente. O layout é do designer da casa, o Léo ‘no perdona errores’ Tartari.

O site celebra os 5 anos da Softa (na verdade contabilizados no início do ano, mas, sabe como é, o site fica sempre na parte de baixo da lista de prioridades =D). Quando começamos, éramos dois sócios: Diogo Biazus e eu, Juan Maiz. No início não tínhamos uma idéia específica do que fazer, mas sabíamos que era necessário empreender e criar uma empresa onde as pessoas fossem trabalhar motivadas. No nosso país o empreendedorismo ainda engatinha e a maioria dos profissionais busca trabalho no governo ou em grandes empresas, onde a grande quantidade de funcionários dilui as responsabilidades e a possibilidade de fazer a diferença individualmente. Nossas referências eram os textos de Paul Graham, E.F. Schumacher, Ricardo Semler e do pessoal da 37Signals, que recém havia lançado o Ruby on Rails.

Hoje somos 6 sócios, tendo entrado, nesta ordem, o Daniel Weinmann, o Pedro Axelrud, o Léo Tartari e o Felipe Cabral. Todos eles vieram agregar seus vastos conhecimentos em diversas áreas e estão ajudando a tornar a Softa uma empresa reconhecida pela qualidade, pelo atendimento primoroso e pela transparência e honestidade.

Nestes anos, desenvolvemos algumas dezenas de projetos, evoluímos bastante e lançamos nosso próprio produto, o Mailee.me, uma ferramenta de email marketing 2.0. Também contribuímos com a comunidade de tecnologia: organizamos o RS on Rails, apoiamos a PGCon e o FISL, fundamos o GURU-RS (Grupo de usuários Ruby do Rio Grande do Sul), palestramos em dezenas de eventos, realizamos um projeto no Google Summer of Code (através do Diogo, nosso expert em PostgreSQL), e agora estamos ajudando a organizar um grupo de Startups no estado.

O site irá ao ar ainda hoje. Fique atento ao hash tag #softa no Twitter.

Permalink | Leave a comment  »

Há algum tempo estamos colocando projetos no Heroku e estamos seriamente pensando em colocar novos projetos por lá, incluindo nosso novo site que está sendo produzido. Ocorre que para colocar uma aplicação Rails3, você precisa usar uma máquina virtual deles chamada "Bamboo". Veja os passos:

1. Criar sua aplicação Rails3 (suponho que você já tenha instalado o Rails3).

   rails new foo
   cd foo
   rails g controller Hello world

2. Cadastrar-se no heroku
3. Instalar o heroku

   gem install heroku    # Instala a gem do Heroku :D
   heroku list                # Lista suas aplicações lá. Isso só serve pra que você faça o primeiro login, pois ele vai te pedir email e senha.

4. Iniciar o repositório git e enviar

   git init                                                                     # inicia o repositório local
   git add .                                                                  # adiciona todos os arquivos. O Rails3 já gera um .gitignore :D
   git commit -a -m 'yo man!'                                        # comita tudo com a mensagem yo man
   heroku create --stack bamboo-ree-1.8.7 --remote foo  # cria um stack bamboo com ruby 1.8.7 com o nome "foo"
   git push foo master

5. Done.

   Aguarde a instalação da aplicação e copie o link que ele te apresenta. Acesse o link, mas com /hello/world

Feito! Se tiver dúvidas me contate via twitter no @joaomilho

Ah, no dia 4 de Agosto estarei falando sobre Rails3 (e se der tempo sobre Heroku tmb) na TargetTrust.

Permalink | Leave a comment  »

Como muitos já sabem o PostgreSQL 9.0 virá com um sistema de replicação nativo e as bases replicadas poderão receber comandos de leitura (hot standby). O interessante da replicação nativa é que ela é feita pelo log de transação, logo o custo para a máquina mestre é muito baixo, e o intervalo entre a efetivação das transações e a cópia destas é muito pequeno. Para ler em detalhes sobre como configurar a replicação já temos a documentação (em inglês) da nova versão. Mas aqui no blog vou mostrar um guia rápido (e em português) sobre como colocar no ar a replicação com o hot standby. 

Primeiro, baixar e instalar o segundo beta da versão 9.0. Os fontes podem ser obtidos em http://www.postgresql.org/ftp/source/v9.0beta2/. Para quem usa o MacPorts já existe um port chamado postgresql90. Para usuários de windows ou para quem preferir usar binários prontos a EnterpriseDB já disponibilizou o instalador de um clique em http://www.enterprisedb.com/products/pgdownload.do.

Após instalar o PostgreSQL 9.0 você vai precisar de duas instâncias do servidor para testar a replicação. Uma forma de fazer isso na mesma máquina é criando uma segunda pasta de dados e executando o serviço em uma porta diferente. Outra possibilidade é instalar em duas máquinas distintas e já testar pela rede mesmo. Nesse passo a passo vou fazer um exemplo com os dois serviços na mesma máquina.

Caso você queira repetir exatamente os passos que eu utilizei, disponibilizei abaixo um script de instalação do PostgreSQL 9.0 beta2 que pode ser executado diretamente na linha de comando com qualquer usuário que não seja o root. O script baixará os fontes e fará a instalação do PostgreSQL na pasta pgsql90 dentro da home do usuário que executá-lo:

1
2
3
4
5

wget http://ftp9.us.postgresql.org/pub/mirrors/postgresql/source/v9.0beta2/postgresql-9.0beta2.tar.gz
tar -zxvf postgresql-9.0beta2.tar.gz
cd postgresql-9.0beta2
./configure --prefix=$HOME/pgsql90
make install

Para informações sobre como configurar os serviços do PostgreSQL manualmente veja a documentação oficial (em inglês). 

Como já tenho um serviço do PostgreSQL escutando na porta 5432 vou usar as portas 5433 e 5434 para o mestre e para o escravo respectivamente. Antes de iniciar o mestre é importante configurá-lo para que ele possa enviar os logs de transação para o escravo. Para instalar e iniciar o serviço mestre já com as configurações necessárias criei outro script que pode ser copiado e colado no terminal:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

cd $HOME/pgsql90
mkdir mestre
./bin/initdb -D mestre
echo "
listen_addresses = '*'
port = 5433
wal_level = hot_standby
archive_mode = on
archive_command = 'cp %p /tmp/%f'
max_wal_senders = 1
" > mestre/mestre.conf
echo "
# configuracoes para replicacao e hot standby
include = 'mestre.conf'
" >> mestre/postgresql.conf
echo "
host    replication     all              ::1/128                trust
host    replication     all              127.0.0.1/32           trust
" >> mestre/pg_hba.conf
./bin/postgres -D mestre

Importante: os arquivos para replicar o log de transação são copiados para a pasta tmp, isso é uma configuração que só deve ser usada para pequenos testes na mesma máquina. 

O script irá bloquear o terminal e mostrar todas as mensagens na saída de erro padrão. Logo podemos manter esse terminal para ver as mensagens do servidor e abrir outro para prosseguir com o tutorial. Agora precisamos fazer uma réplica inicial do cluster de dados para usar como serviço "escravo".

Para iniciar a cópia devemos fazer usar o mecanismo de cópia que é utilizado para fazer o PITR, para mais informações veja a documentação em: http://www.postgresql.org/docs/9.0/static/continuous-archiving.html#BACKUP-PITR-RECOVERY

O script abaixo prepara a cópia escravo e já a inicia em modo de hot standby:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

cd $HOME/pgsql90
./bin/psql -p 5433 postgres -c "SELECT pg_start_backup('teste');"
cp -r mestre escravo
rm -f escravo/pg_xlog/*
rm escravo/mestre.conf
rm escravo/postmaster.pid
sed -e "s/mestre\.conf/escravo.conf/" escravo/postgresql.conf > escravo/postgresql.conf.new
mv escravo/postgresql.conf.new escravo/postgresql.conf
echo "
listen_addresses = '*'
port = 5434
wal_level = minimal
archive_mode = off
hot_standby = on
" > escravo/escravo.conf
echo "
restore_command = 'cp /tmp/%f %p'
standby_mode = 'on'
primary_conninfo = 'host=localhost port=5433'
trigger_file = '/tmp/trigger.pgsql.5434'
" > escravo/recovery.conf
./bin/psql -p 5433 postgres -c "SELECT pg_stop_backup();"
./bin/postgres -D escravo

Pronto, se você chegou até aqui deve ter duas instâncias do PostgreSQL executando em sua máquina. As duas estão dentro da pasta pgsql90 na home do seu usuário. Uma na porta 5433 e outra na porta 5434. As duas aceitam conexões, mas a 5434 é somente para leitura. Se você conectar na 5433 e executar qualquer comando para modificar o estado do cluster o comando será quase imediatamente replicado para a instância na porta 5434.

Qualquer dúvida ou correção nos scripts podem deixar nos comentários.

Permalink | Leave a comment  »

Permalink | Leave a comment  »

Pessoal, a nova moda aqui na Softa é aprender Haskell. E tenho que confessar que a linguagem é bonita mesmo. Haskell foi mais fácil no começo do que eu imaginava (ok, eu imaginava um monstro). E logo consegui fazer algo bem divertido, um mapeamento de algebra relacional para SQL. Implementei duas operações, a projeção (projection) e a junção natural (natural join). O código é apenas um exercício de quem está aprendendo a linguagem, portanto críticas e sugestões são muito bem vindas, e até desejadas :)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

import Database.HDBC
import Database.HDBC.PostgreSQL
import Data.List

type SQL = String

data Relation = Relation SQL
  deriving (Show)

sql (Relation sql) = sql

printTuples conn rel =
    quickQuery' conn ("SELECT DISTINCT * FROM " ++ (sql rel)) []

join rel1 rel2 =
    Relation ((sql rel1) ++ " NATURAL JOIN " ++ (sql rel2))

project fields rel1 =
    Relation ("(SELECT " ++ (intercalate "," fields) ++ " FROM " ++ (sql rel1) ++ ") a")

(π) = project
(⋈) = join

Outro detalhe divertido é usar os operadores da Álgebra Relacional (com caracteres unicode), como no seguinte código no ghci (que assume a existência de uma base teste e dos drivers HDBC para o PostgreSQL):

1
2
3
4
5
6
7
8
9

:module Database.HDBC Database.HDBC.PostgreSQL
:load relational.hs
let dept = Relation "dept"
let emp = Relation "emp"
let teste = (π ["empno", "ename", "dname"] (emp ⋈ dept))
conn <- connectPostgreSQL "host=localhost dbname=teste"
printTuples conn teste

[[SqlRational (7902 % 1),SqlByteString "FORD",SqlByteString "RESEARCH"],[SqlRational (7654 % 1),SqlByteString "MARTIN",SqlByteString "SALES"],[SqlRational (7521 % 1),SqlByteString "WARD",SqlByteString "SALES"],[SqlRational (7839 % 1),SqlByteString "KING",SqlByteString "ACCOUNTING"],[SqlRational (7876 % 1),SqlByteString "ADAMS",SqlByteString "RESEARCH"],[SqlRational (7782 % 1),SqlByteString "CLARK",SqlByteString "ACCOUNTING"],[SqlRational (7900 % 1),SqlByteString "JAMES",SqlByteString "SALES"],[SqlRational (7698 % 1),SqlByteString "BLAKE",SqlByteString "SALES"],[SqlRational (7566 % 1),SqlByteString "JONES",SqlByteString "RESEARCH"],[SqlRational (7499 % 1),SqlByteString "ALLEN",SqlByteString "SALES"],[SqlRational (7788 % 1),SqlByteString "SCOTT",SqlByteString "RESEARCH"],[SqlRational (7934 % 1),SqlByteString "MILLER",SqlByteString "ACCOUNTING"],[SqlRational (7369 % 1),SqlByteString "SMITH",SqlByteString "RESEARCH"],[SqlRational (7844 % 1),SqlByteString "TURNER",SqlByteString "SALES"]]

Permalink | Leave a comment  »

Em primeiro lugar, nunca confie em testes de performance alheios por isso durante o post vou dar as ferramentas para que o leitor reproduza os testes no seu ambiente se assim o desejar. 

Em segundo lugar a minha intenção não era fazer um teste abrangente, mas sim detectar diferenças de performance em um recurso bem específico: threads.

Antes de simplesmente jogar os resultados dos testes na tela, vejamos o que me levou a eles.

Aqui na empresa o Mailee trabalha fortemente com execução concorrente de código. A versão atual do nosso software de entrega implementa a concorrência com threads. Já considerei diversas vezes a migração para uma arquitetura multi-processo, idéia que ainda não foi descartada. No entanto, atualmente o trabalho para migrar para processos parece maior que o benefício, o que me fez pensar em otimizar o código e procurar uma boa implementação de threads em Ruby.

Os testes e o ambiente:

Bom, aos testes. O ambiente de testes utilizado foi um MacBook com processador Core 2 Duo de 2.4 GHz executando o Mac OS X 10.5.8, os resultados são a média de 10 execuções.

Realizei um teste para multi-threading limitado pelo IO (I/O bound) e um para multi-threading limitado pela CPU (CPU bound). Cada teste foi executado inicialmente com apenas um thread, e depois aumentando a carga de trabalho linear e uniformemente até 10 threads simultâneos. Abaixo o código dos testes:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

MAX_ITER=1000
MAX_THREADS=10
MAX_REPETITIONS=10

def benchmark fun, file
  File.unlink file if File.exists? file
  (1..MAX_THREADS).each do |thread_count|
    total_time = 0.0
    mean_time = 0.0
    (1..MAX_REPETITIONS).each do |repetitions|
      start_time = Time.now
      threads = []
      (1..thread_count).each do |i|
        threads << Thread.new do 
          (1..MAX_ITER).each { |j| fun.call(i, j) }
        end
      end
      threads.each{ |t| t.join }
      total_time += Time.now - start_time
    end
    mean_time = total_time/MAX_REPETITIONS
    puts "Mean time: #{mean_time}"
    File.open(file, 'a') { |f| f.write "#{thread_count} #{mean_time}\n" }
  end
end

BENCH_CPU = lambda { |i, j| x = (i+1) ** 10000 }
BENCH_IO = lambda { |i, j| File.open("thread.#{i}.log", 'w+'){ |f| f.write((1..100).to_a.join("-")) } }

benchmark BENCH_CPU, "cpu.dat"
benchmark BENCH_IO, "io.dat"

Resultados:

See the full gallery on Posterous

Conclusões:

É curioso observar que embora o MRI 1.9.1 tenha melhorado drasticamente sua performance para os threads IO bound, quando o recurso é CPU ele fica parelho e um pouco pior comparado ao MRI 1.8.7.

A performance do jruby no teste de CPU me decepcionou, mas a lentidão pode ser relacionada a JVM do Mac OS X.

Pelos resultados apenas desses dois testes eu ficaria com o MRI 1.9.1 ou com o Rubinius. Mas é importante ressaltar que a versão 1.0 do Rubinius não é compatível com o Ruby 1.9, mas sim com o Ruby 1.8.

E não percam a seguir:

Ainda pretendo publicar um teste comparativo usando o conjunto de benchmarks diponível em http://github.com/acangiano/ruby-benchmark-suite, mas isso fica para um post futuro. No meu próximo post pretendo apresentar testes similares feitos com um código semelhante porém utilizando processos ao invés de threads.

Permalink | Leave a comment  »

O Mailee tem uma cobertura muito legal de testes, o que nos ajuda bastante na hora de refatorar código e implementar novos recursos. Mas estamos num ponto  em que os testes demoram muito pra rodar, e isso é bem chato.

test: database: xxx_test<%= ENV['TEST_ENV_NUMBER'] %>

create database xxx_test2;

rake parallel:prepare

rake parallel:test

rake "parallel:test[functional]"

Permalink | Leave a comment  »

1
2
3
4
5
6
7
8

# load libraries
require 'rubygems'
require 'wirble'

# start wirble (with color)
Wirble.init
Wirble.colorize

Permalink | Leave a comment  »

Estamos testando a biblioteca gltail. Ela apresenta os logs da sua aplicação (rails, nginx, apache, postfix...) em uma interface unificada usando OpenGL. A implementação é bem fácil e ela consegue acessar os logs via SSH. Enjoy:

Permalink | Leave a comment  »

Para quem precisar publiquei no github o date range picker originalmente do filamentgroup traduzido. A diferença dele pro date picker do jQueryUI é que você pode escolher um período e não apenas uma data. Além disso ele tem uma série de atalhos, como "Hoje", "Ontem" e "últimos 7 dias".

O original está aqui:
http://www.filamentgroup.com/lab/update_date_range_picker_with_jquery_ui/

O traduzido aqui:
http://github.com/softa/Jquery-Date-Range-Picker-pt-br

Uso:
Olhe o arquivo demo.html que possui todas as dependências. O código é simples assim:

Veja em ação:

Permalink | Leave a comment  »

Aconteceu em 15.12.09 mais um encontro do Coding Dojo. Para quem se pergunta o que é: dojo (do=caminho, jo=lugar da prática) é o lugar onde se prática a disciplina. Nesse caso, a codificação, o desenvolvimento de linguagens e a troca de tecnologia. Este é o caminho escolhido.

A idéia foi criada porque os desenvolvedores são focados em trabalho e pesquisa, mas não tem um espaço de prática e/ou troca entre pares. Utilizando a metodologia dos dojos de artes marciais (ou o modelo que eles deveriam seguir). Compreendendo a ausência de competição, apoio mútuo, colaboração e diversão no aprendizado. A inclusão é realizada através do recebimento de todos níveis de programadores, até de quem não programa. Todos são convidados a participar do randori ou kake, que são programações realizadas em duplas que trocam constantemente. Se você não sabe nada, terá apoio do Sensei/Senpai(responsável pelo dojo), colegas, platéia, co-piloto(aite),etc.

Se você é programador, vale a pena! Vale a pena a troca de experiência, conhecer pessoas, métodos, tecnologias, linguagens novas. Se você é não é, vale a pena! Pelo método, pelo ambiente, pela diversão, pelo aprendizado de coisas novas.

Aprender coisas novas ou apenas exercitar não é a única coisa que o dojo oferece. Também a oportunidade de se expor, colocar o ego de lado e ir até o pc e tentar, mais nada além do que tentar. Você pode não conseguir nada, mas isso será só em matéria de código. Sempre se aprende alguma coisa quando nós nos expomos e é melhor ainda em um ambiente completamente salutar como o tatame macio de um coding dojo.

E no final….PIZZA! Por conta da Locaweb, organizadora do evento.

Comunidade do RS : http://groups.google.com/group/dojo-tche?pli=1

Coding dojo, regras e princípios: http://codingdojo.org/

Locaweb: http://www.locaweb.com.br

Permalink | Leave a comment  »

Em 01.12.09 foi realizado o Agile day (ano 2), pelo GUMA-RS. Assisti a 4 palestras de grandes nomes do movimento Agile no Brasil. O resumo da programação está em http://agileday2009.guma-rs.org/

Uma rápida avaliação geral: Todos palestrantes apresentaram ou case específico ou a metodologia comum para diversos cases que acompanharam. O foco se manteve no sucesso e as dificuldades que são encontradas no processo de criação de software através da metodologia ágil. O ponto em comum das histórias de sucesso é que se faz necessidade de uma equipe coesa e madura, tanto no seu inter-relacionamento como no seu intra-relacionamento, ou seja, a equipe além de ter alto nível técnico deve ter confiança em todos seus membros. Essa questão de inclusive foi levantado durante a sessão de perguntas do Manoel Pimental, da InfoQ e Visão Ágil. Todas as características de equipe apontadas como necessárias para obtenção de um ambiente favorável à utilização de metodologia ágil são características desenvolvidas nos melhores programas de desenvolvimento humano. Todos presentes ficaram de acordo.

As características humanas necessárias à equipe foram presentes em todas palestras, inclusive na palestra sobre integração e entrega continua do Carlos Villela da ThoughtWorks, que mesmo sendo técnica, focada na ferramentas e no processo de integração, a continuidade do processo requer comprometimento total da equipe. Como foi exposto: é mágico quando você apenas escreve algo em um post-it e colhe o resultado completo na semana seguinte.

Para compreender melhor o desenvolvimento de equipe e dos integrantes da equipe acho que é imprescindível os livros: A quinta disciplina, de Peter Senge. http://tiny.cc/zIUf8 Criação de conhecimento na empresa, de Nonaka & Takeuchi http://tiny.cc/cB8F2

Site do Guma-RS http://www.guma-rs.org/

Site do evento http://agileday2009.guma-rs.org/ 

Permalink | Leave a comment  »

Aqui está a palestra que dei no último mês, sobre BackgrounDRb

Os códigos estão no GitHub: http://github.com/softa/hello_drb_world http://github.com/softa/hello_backgroundrb_world

Permalink | Leave a comment  »

Aqui está a palestra que dei no último mês, sobre BackgrounDRb

Os códigos estão no GitHub: http://github.com/softa/hello_drb_world http://github.com/softa/hello_backgroundrb_world

Permalink | Leave a comment  »

Estamos há uma semana do evento, as inscrições na web estão abertas até dia 19 em http://pgcon.postgresql.org.br/2009/inscricoes.php Depois disso só as inscrições no local. Aproveitem e se inscrevam, é o maior evento de PostgreSQL na américa latina.

Permalink | Leave a comment  »

Permalink | Leave a comment  »

Semana retrasada tivemos uma oficina sobre o uso do Git na Softa.

Em primeiro lugar, gostaria de citar as duas principais referências que utilizei como guia:

• Understanding Git Conceptually
• Git Magic

O primeiro link dá uma explicação conceitual excelente sobre o assunto, enquanto o segundo aborda pontos mais avançados (magia negra). Para compreender o Git, e não apenas decorar comando, acho fundamental expor alguns conceitos iniciais:

• Repositório: É um conjunto de commits e um conjunto de referências aos commits, chamadas de “heads”. O repositório é criado com um comando git init (inicia o repositório em qualquer pasta) ou git clone (copia um repositório). Todos os arquivos necessários para o git ficam em uma pasta oculta na raiz do projeto chamada ”.git”.
• Commits: Cada commit é uma fotografia do estado dos arquivos no projeto em um instante de tempo. Os commits têm um nome, que é um hash sha1 e um apontador para o commit pai (o commit que deu origem a ele). Então sempre teremos um commit sem pai no repositório (o primeiro) e algumas vezes teremos commits com dois pais (resultados de merges). Logo, o repositório pode ser encarado como um grafo direcionado e acíclico de commits e manipular as versões do projeto é navegar nesse grafo.
• Heads: Aponta para um commit, é apenas um apelido para o nome sha1 do commit em questão. É importante observar que sempre temos um head chamado HEAD (em maiúsculas) que aponta para o último commit realizado.

Depois de ver essa parte conceitual podemos entender melhor alguns comandos clássicos:

• git log – mostra todos os commits de HEAD até o commit inicial.
• git status – mostra arquivos modificados desde HEAD.
• git diff – mostra todas as modificações nos arquivos do projeto desdeHEAD.

Para evitar um post excessivamente grande vou publicar a continuação desse artigo separadamente aqui no blog da Softa.

Permalink | Leave a comment  »

Permalink | Leave a comment  »

Durante o dia 29 de agosto aconteceu o 1° RS on Rails, e nós da softa fizemos parte da organização e ainda demos algumas palestras. Pra quem quiser conferir, elas estão todas no slideshare.

Permalink | Leave a comment  »