segunda-feira, 15 de novembro de 2010

Não sabe um caminho para seguir na programação? tente este aqui, parte 3/6


Continuando com a saga "Não sabe um caminho para seguir na programação? tente este aqui".


Técnicas Agile é o que você precisa para se organizar

Agile é um conjunto de práticas para desenvolvimento ágil de software. É uma 
definição bem curta e que define muito bem o que é Agile, mas não adianta você 
pensar que é só seguir essas regras que vou colocar que sempre o seu software 
vai sair no tempo esperado como em um mundo perfeito, pense que clientes são 
seres humanos e são extremamente indecisos.


Análise Inicial:

É feito uma análise inicial do problema para saber algumas coisas vitais para a realização 
do projeto, como, quantos e quem irá fazer parte da equipe daquele projeto, qual seria 
a prioridade do projeto, o que será entregue primeiro ao cliente, está fase é importante 
para a definição de como o projeto irá seguir em frente, porém é uma fase curta, 
não perca muito tempo nela.

Sprints:

A metodologia Agile faz que a equipe trabalhe com sprints curtos, cada sprint é de 
1 à 4 semanas, e o objetivo é terminar o sprint para o cliente possa dar o feedback,
se não for aprovado, fazer as mudanças necessárias pedidas pelo cliente. Para 
definir os sprints para a equipe possa saber o que deverá desenvolver, utilizamos algo
bem simples, papel e caneta, é isso ai, marcamos cada tarefa a ser realizada em 
um papel e colamos na parede, ou em um quadro, e cada membro da equipe 
será responsável por uma ou mais tarefas a ser entregue no final daquele sprint, 
a tarefa tem que ser entregue naquele período por ter sido combinada com o cliente, se
não for entregue comprometerá a conclusão do software ou site, e manchará a 
imagem da empresa com o cliente.
Qual seria a vantagem disto, se a equipe trabalha com sprints curtos de uma 
determinada área do sistema, ela provavelmente irá fechar aquela parte, ter o 
feedback positivo do cliente no final do processo e não precisará mais se 
preocupar com ela, enquanto se fizer um projeto inteiro para depois realizar 
as mudanças será prejudicial, por que o cliente vai demorar muito para ver o 
projeto dele, e se não gostar do resultado final, acarretando assim muitas 
mudanças até a entrega definitiva do projeto, essa com certeza é a maior
vantagem do Agile, desenvolvimento com sprints curtos.

Processo Final:

É a parte em que o projeto foi para produção e está em sua parte final de testes, 
para saber se foi feito da forma que o cliente pediu, dependendo do projeto ele 
pode entrar em produção antes, com algumas áreas ainda em desenvolvimento.

Extreme Programming(ou XP):

O XP é uma outra forma de desenvolvimento ágil, mas não vou afundo nela 

por que não sei muito a respeito, sei somente que é muito mais do que vou 
escrever aqui, mas basicamente é dois programadores trabalhando juntos em 
uma mesma tarefa e se revezando em quem é o piloto e o co-piloto da máquina, 
os dois pensam juntos para além de terminar a tarefa mais rápido, pode evoluir 
ela de forma mais fácil, mais sobre o XP no site da ImproveIt .

Essa forma de trabalhar faz com que o seu software saia muito mais rápido, melhor, 

com um número de bugs menor(por que é muito difícil alcançar 0% de bugs), e 
com o que o seu cliente imaginou, existe mais sobre esse assunto na internet, pesquise 
vídeos e textos falando sobre para você poder aplicar na empresa aonde trabalha, 
vamos fazer uma cultura sem estresse no nosso ambiente de trabalho.

O próximo post da saga "Não sabe um caminho para seguir na programação? 
tente este aqui" vai ser "Por que fazer teste ?", até o próximo post.
 

domingo, 14 de novembro de 2010

Não sabe um caminho para seguir na programação? tente este aqui, parte 2/6

Continuando com a saga "Não sabe um caminho para seguir na programação? tente este aqui".

A cultura por trás do Ruby on Rails

Vou começar falando um pouco de Ruby, mas antes tenho que falar do irb, que é um programa que vem com o Ruby e pode testar todos os seus comandos nele com resposta imediata, antes de colocar na sua aplicação,  ele possui um histórico de comandos, e quando é utilizado com o Rails carrega tudo que está na sua aplicação fazendo assim que você possa até acessar dados do seu BD, é uma ferramenta de grande ajuda no desenvolvimento já que vai poder testar tudo antes de colocar a vera na aplicação.
Agora vamos ao Ruby, é uma linguagem totalmente orientada a objeto(muitos vão pensar "como assim ?"), vou dar um exemplo clássico quando falam de Ruby, até um número é um objeto, dúvida ? Veja o exemplo.
 
no terminal com o ruby instalado:
 

irb(main):001:0> 5.times do |numero|
irb(main):002:1*   print numero, " "
irb(main):003:1> end
0 1 2 3 4 => 5
irb(main):004:0>
 
O número 5 foi utilizado para fazer um loop, e o print deu a saída de forma  organizada. 
Viu tudo pode ser um objeto em Ruby, fora que sua sintaxe é muito fácil de entender e legível, 
escrever um método é uma experiência bem agradável, veja este método:
 
irb(main):032:0* def quadrate(number)
irb(main):033:1>   number.times do
irb(main):034:2*     number.times do
irb(main):035:3*       print "*  "
irb(main):036:3>     end
irb(main):037:2>     print "\n"
irb(main):038:2>   end
irb(main):039:1> end
=> nil
irb(main):040:0> quadrate(10) # ou poderia chamar assim, quadrate 10
*  *  *  *  *  *  *  *  *  * 
*  *  *  *  *  *  *  *  *  * 
*  *  *  *  *  *  *  *  *  * 
*  *  *  *  *  *  *  *  *  * 
*  *  *  *  *  *  *  *  *  * 
*  *  *  *  *  *  *  *  *  * 
*  *  *  *  *  *  *  *  *  * 
*  *  *  *  *  *  *  *  *  * 
*  *  *  *  *  *  *  *  *  * 
*  *  *  *  *  *  *  *  *  * 
=> 10

Assim é feito um método em Ruby, fácil né ? Agora a explicação.
Linha por linha:

def quadrate(number) # primeiro o método recebe um parâmetro, como pode ser visto não precisa ficar declarando o tipo que aquele método vai receber, sendo assim variáveis também não precisam ser declaradas.

number.times do # é o primeiro loop da interação, ele vai fazer o loop de acordo com
a quantidade de números que você passar para o método. O primeiro loop gera a quantas
serão as colunas, o loop de baixo gera as linhas.

print "*  " # gera uma saída em apenas uma linha

print "\n" # pula a linha

Viu como é simples, é uma linguagem de alto poder, pode ser construído qualquer coisa
com ela, não é uma linguagem que só funciona bem com internet, também funciona muito
bem construindo programas para desktop, jogos, qualquer é só ter imaginação e pesquisar,
até um Linux baseado nela está nascendo que é o KoshLinux. Vou falar da cultura
Ruby mais abaixo.

Rails, é um framework para linguagem Ruby, sendo o mais utilizado hoje em dia,
feito por uma counidade enorme de usuários de Ruby está na sua versão 3, sendo
intitulado Rails 3, utilizando o conceito MVC(Model View Controller), por além de
deixar seu código bem organizado, ajuda em diferentes aspectos na construção de
um site, aumentando significavelmente a velocidade de construção, e nele vem
uma infinidade de recursos para o desenvolvimento da sua aplicação de forma ágil,
segura, e de fácil crescimento.

Agora que dei uma falada bem rápida na linguagem e no framework que serão o meu
foco neste blog, vou ainda falar muito de Ruby e Rails no próximos posts, dar exemplos
mais significantes, da sua usuabilidade, mas agora eu quero falar um pouco da cultura
Ruby on Rails, por que eu acho ela tão importante, não é uma exclusividade de Ruby,
a galera que escreve Python também tem a mesma cabeça que a nossa, e este
pensamento está sendo passado para as comunidades de outras linguagens, por que
essa parada de guerrinha de qual é a melhor linguagem é idiotice, somos todos
desenvolvedores e queremos um código bom, então a união é sempre melhor para
o desenvolvimento geral da classe.

O que seria um bom código, primeiro é um código testado, no rails estou sabendo do
RSpec para Models e Controllers, e o Cucumber e o Steak para Views, teste é uma
ótima prática pelo seguinte, se você estiver fazendo uma aplicação como vai saber se
o código que você ta fazendo vai quebrar ?
Vai esperar quebrar pra concertar, ou vai evitar à quebra antes ? Eu prefiro evitar à quebra,
imagina um site grande sem teste e uma alteração sua é vital para o site, ele quebra em
vários lugares e você não vê ? Vai testar página por página até verificar se tudo deu certo,
pra mim isso é trabalho de porco, mas ai é com você.

Segundo um código legível, que se define em algumas partes, uma é a escrita, a linguagem
mais usada no mundo é o inglês, as classes e métodos da linguagem que você
usa é inglês, então por que diabos você escreve seus modulos, classes, métodos e
suas variáveis em português ? Se escrever em inglês, fica mais fácil de entender e
não vai precisar de colocar comentário, por que se você já tem um método bem
descritivo não precisa de comentário, não da pra ficar nomeando métodos e
variáveis que podem abranger muita coisa, por que ai vai ter que escrever
comentário e é desnecessário, mas o pior de tudo isso é escrever resumindo,
"cod_cli", mas por que diabos não escreve "code", se presumi que se você está
na tabela "cliente" não precisa escrever cliente  de novo, então só precisa do
"code", não precisa complicar o que é simples de ser feito, existe casos muito
piores e muito disso vem preso com você da faculdade, e não se culpem
a culpa é de quem te ensinou que tem preguiça de escrever certo.

Outra boa prática é a otimização, não importa quanto você é bom sempre da pra
otimizar seu código, deixar ele mais agradável de ser lido, organizado, uma identação
boa é sempre bom para a equipe do projeto, se sua empresa tiver uma identação padrão,
é bem legal por que não vai ter confusão depois de como o código foi escrito.

Existe uma frase que define muito bem o que você tem que pensar quando está criando
o seu código, "Pense que o programador que vai vir mexer no seu código seja um
psicopata que sabe onde você mora", é radical mesmo, se você faz o código ruim vai ser
muito criticado, o que adianta se é foda, mas ninguém entende o que você faz, tem que
pensar que existe uma equipe com você.

Outra coisa que a cultura Ruby on Rails sempre incentiva é utilizar as técnicas de
desenvolvimento Ágil, que é um ótimo aliado para que sua aplicação fique pronta
o mais rápido possível, cobrindo todos os aspectos que seu cliente quer e
diminuindo as chances de bugs.

Pesquise as novidades que a área te oferece para criar sempre um bom código, por que
ser um bom programador não só fazer funcionar, pense nisto.

O próximo post é sobre da saga "Não sabe um caminho para seguir na programação? tente
este aqui" é "Técnicas Agile é o que você precisa para se organizar", vou falar de como
usar Agile é legal. Até próximo post.


quarta-feira, 10 de novembro de 2010

Não sabe um caminho para seguir na programação? tente este aqui, parte 1/6

Por que eu acho interessante este caminho, simples, envolve ótimas tecnologias presentes no mercado de trabalho e que só cresce em número de interessados, aumentando o número de interessados aumenta o número de desenvolvedores delas, assim elas melhoram cada vez mais com o passar do tempo.
Vou falar 6 assuntos que vai te interessar.
Linha de comando é um maior barato, use Linux.
A cultura por trás do Ruby on Rails.
Técnicas Agile é o que você precisa para se organizar.
Por que fazer teste ?
O que é NoSQL ?
Comunidades, não tenha medo delas, elas só existem para ajudar.


Linha de comando é um maior barato, use Linux

Se eu disser que o Linux é muito fod..., e pode usar que você não vai se arrepender, vou te convencer ? acho que não, mas já vou dando o alerta se você adora Windo...(não gosto de escrever palavrões e nem palavras escrotas no meu blog) é melhor parar de ler essa parte e ir pra outro post desta saga, não quero nenhum doido por Windo... me xingando mais tarde.
Agora sim, se você é desenvolvedor, vai ser muito mais respeitado no meio desenvolvendo no Linux, por que se você desenvolve no Windo... , ou tem muita coragem, ou gosta de sofrer. 
Mas vamos falar o que interessa, Linux é um ótimo ambiente de desenvolvemento por que é feito por uma comunidade que programa por que gosta, quer se desenvolver, não se contentam com coisas pequenas, não são viciados em trabalho e sim em desafios. Se você vier falar que "Linux só usa linha de comando", ou "é muito difícil", ou "eu não consigo instalar a Velox", ou "não da pra jogar no Linux", entre outras coisas, vou te dizer somente uma coisa, TA NA PROFISSÃO ERRADA, VAI TRICOTAR, mas parece ser algo bem mais difícil que usar Linux..
Não tem desculpa, existem milhares de sites que te ensinam o que você precisa para usar o Linux, fora que tem um site de busca muito bom chamado Google, conhece ? Então, é só procurar, e te garanto uma coisa você vai aprender muito e vai descobrir que Linux não é um quebra-cabeça, fora que você pode escolher a distribuição que combina mais com o seu perfil, ou criar a sua própria. 
A maioria dos sevidores na web são Linux, por que será né ? Será por que é um SO mais confiável ? É, por que depois que eu mudei pra Linux nunca mais pensei em vírus.
Não utiliza desfragmentador de disco, existe um sistema de arquivos que grava de uma forma inteligênte, utilizando melhor o espaço disponível.
Não tem aquelas mensagens idiotas de erros que não te ajudam em nada, e sim mensagens que te explicam o problema e na maioria dos casos baixa o pacote necessário para funcionar.
Programas menores e melhores, por serem feitos por pessoas que sabem do que precisamos, seus próprios usuários.
Atualizações quase que diárias, não só para corrigir bugs, como para melhorar o sistema.
Não vai ver tela azul do nada. 
Instala rapidinho e se da muito bem com outros SO's instalados com ele.
É de graça, então você não precisa ficar com aquele peso na conciência que comprou uma cópia pirata que não funciona direito.
E ai te convenci ? senão, faz o seguinte, pesquisa um pouquinho sobre Linux que você vai ver como é interessante, linha de comando não morde e faz um bem danado quando é bem utilizado, fora que o Linux tem uma parte gráfica muito interessante e fácil de usar, se você tem medo de migrar direto se para um pedacinho do HD pra ele, e vai mexendo de vez em quando, eu sei que você não vai se arrepender e vai descobrir quanta coisa legal ele tem para oferecer.
O próximo post vai ser bem legal vou continuar a saga "Não sabe um caminho para seguir na programação ? tente este aqui, parte 2/6" que vou falar de "A cultura por trás do Ruby on Rails", se você não sabe o que é não perca, vou explicar de uma forma bem legal o que é Ruby, o que é Rails, como eles trabalham juntos e o que é está tal cultura.
Até a próxima

domingo, 7 de novembro de 2010

Aprender um pouco de RSpec com o exemplo FizzBuzz


Vamos falar de teste, e de RSpec para ser específico, confesso que ainda estou no comecinho com RSpec mas o que eu já vi e entendi da pra ajudar quem ainda não viu nada, e como exemplificar é melhor que falar, vou fazer um exemplo chamado fizzbuzz que vi no dojo-rio a algumas semanas, naquela ocasião foi feito em Python mas como meu foco é Ruby, vou fazer com ele.

O exercício chamado Fizzbuzz é o seguinte, se um número for divisível por 3, escreve fizz, se o número for divisível por 5, escreve buzz, se for pelos 2, escreve fizzbuzz, se não for por nenhum deles, retorna o próprio
número.

Se você é aquela pessoa anciosa que não quer ver o passo a passo do problema e só quer a resposta, e continuar sem entender nada, vai logo pro final deste post.
 
Abra o terminal e instale a gem do rspec
sudo gem install rspec

Vá para seu diretório de projetos e crie um diretório chamado fizzbuzz e entre nele:
cd project && mkdir fizzbuzz && cd fizzbuzz
// com isso ele fará as 3 requisições uma depois da outra

Crie um arquivo chamado test.rb e salve. Este é o arquivo que vai ser lido quando rodar o spec.
gedit test.rb

Para verificar se o nosso ambiente de teste está funcionando faça:

describe "Teste" do
 it "para ver se está funcionando" do
 
1.should == 1
 end
end

E depois rode no terminal:
clear && spec test.rb --color --format nested
# o comando clear limpa a tela, e depois agente executa o camando do RSpec, ele vai adicionar cor e identar

Linha por linha:
describe "Teste" do # describe => declara o grupo de exemplos, é um bloco tem o (do) para abrir e o (end) para fechar esse bloco

it "para ver se está funcionando" do # it => declara o exemplo

1.should == 1 # should => é um método da classe Oject, se a espectativa retornar true ela passa, se retornar false o should mostra uma mensagem de falha

Agora voltando ao problema, a primeira coisa que você tem que pensar é existe 4 regras pra resolver, então
tem que começar pela que é teoricamente mais fácil, que é:
Se é divisível por 3, retorna fizz.

describe "Fizzbuzz" do
  context "é divisível" do
   
it "por 3" do
      fizzbuzz(9).should == "fizz"
   
end
  end
end

Se você for no terminal e rodar a spec vai acontecer isso:

Fizzbuzz
  é divisível
    por 3 (FAILED - 1)

1)
NoMethodError in 'Fizzbuzz é divisível por 3'
undefined method `fizzbuzz' for #<Spec::Example::ExampleGroup::Subclass_1::Subclass_1:0x7f7f950a5250>
./test.rb:4:

Finished in 0.040514 seconds

1 example, 1 failure

Mas é claro, não existe método fizzbuzz, então ta na hora de criar um outro arquivo, chamado "fizzbuzz" mesmo:
gedit fizzbuzz.rb

e chamar este arquivo no nosso arquivo de teste, o test.rb:
require "fizzbuzz"

e no arquivo fizzbuzz.rb

def fizzbuzz(numero)
  "fizz"
end

Passou, mas ainda não resolveu nossa primeira regra. Para resolver a primeira regra é bem simples.

def fizzbuzz(numero)
  if numero %3 == 0 # Se for divisível por 3, retorna a palavra fizz
    "fizz"
  end
end

Se você for curioso como eu, vai querer ver se realmente isso ta funcionando como o esperado, troca a palavra fizz por buzz:

Fizzbuzz
  é divisível
    por 3 (FAILED - 1)

1)
'Fizzbuzz é divisível por 3' FAILED
expected: "fizz",
     got: "buzz" (using ==)
./test.rb:5:

Finished in 0.036305 seconds

1 example, 1 failure

Bang !!! ... o teste esperava a palavra fizz, porém o método retornou a palavra buzz, volte com a palavra fizz e seguiremos nossas regras. Agora se é divisível por 5, retornar buzz.
Depois do primeiro bloco it adicione este bloco:

it "por 5 " do
  fizzbuzz(10).should == "buzz"
end

Se você rodar o teste vai ver que o primeiro teste passou e o segundo teve o seu retorno nulo, por que ele não é divisível por 3, e como não tem nenhum else ele vai retornar nulo.

Fizzbuzz
  é divisível
    por 3
    por 5  (FAILED - 1)

1)
'Fizzbuzz é divisível por 5 ' FAILED
expected: "buzz",
     got: nil (using ==)
./test.rb:10:

Finished in 0.039466 seconds

2 examples, 1 failure

Para resolver isso coloque a condição para ser divisível por 5.

def fizzbuzz(numero)
  if numero %3 == 0
   
"fizz"
  elsif numero %5 == 0
    "buzz"
  end
end

Agora passou, eu sei que parece chato para alguns, mas estou seguindo um esquema de dojo, então explico em detalhes cada passo, para realmente a pessoa entender como faz.
A próxima regra é para ver se é divisível por 3 e 5 ao mesmo tempo, retornar fizzbuzz.
Depois do bloco do it coloque este aqui.

it "por 3 e 5" do
  fizzbuzz(15).should == "fizzbuzz"
end

E o método vai ficar diferente, por que primeiro temos que testar se é divisível pelos 2 números, para depois testar as outras condições

def fizzbuzz(numero)
  if numero %3 == 0 and numero %5 == 0
    "fizzbuzz"
  elsif numero %3 == 0
    "fizz"
 
elsif numero %5 == 0
    "buzz"
  end
end

Agora para a última regra, verificar se não é divisível por nenhum dos 2 números. Abaixo do contexto coloque isto:

require "fizzbuzz"

describe "Fizzbuzz" do
  context "é divisível" do
    it "por 3" do
     
fizzbuzz(9).should == "fizz"
    end
   
    it "por 5 " do
      fizzbuzz(10).should == "buzz"
    end
   
    it "por 3 e 5" do
      fizzbuzz(15).should == "fizzbuzz"
    end
  end
 
 
context "se não for divisível por 3 ou 5" do
    it "retorna o mesmo valor" do
      numero = 7
      fizzbuzz(numero).should == numero
    end
  end
 
end
 
Fiz assim para ficar mais organizável e legível, agora é só adicionar este último else para finalizar o
processo.

def fizzbuzz(numero)
  if numero %3 == 0 and numero %5 == 0
    "fizzbuzz"
  elsif numero %3 == 0
    "fizz"
  elsif numero %5 == 0
   
"buzz"
  else
    numero
  end
 
end

Essa forma é a que eu vejo ser a mais simples, tem como otimizar mais este código, mas isso fica para outra hora, espero que eu tenha ajudado de alguma forma, até a próxima.
 

Como será este blog

Do que eu vou falar neste blog ?
Vai ser minhas experiências de vida com Linux, Ruby on Rails, RSpec, HTML5, CouchDB, MongoDb, na realidade o que eu me lembrar sobre programação, dicas, vou tentar seguir uma linha, como se tivesse dando aula, vou explicar o que eu souber de uma forma bem simples para aquela pessoa sem experiência consiga se dar bem na área. Vou falar de eventos que frequento, e de que eu quero fazer.
Espero que gostem !!!