Link direto para o Youtube.

#1 http://grails.org/screencast/show/24

#2 http://grails.org/screencast/show/25

#2 Overrun http://grails.org/screencast/show/26

#3 http://grails.org/screencast/show/27

Recomendo que assistam todos os vídeos e espero que gostem

[Java]
http://blog.caelum.com.br/entendendo-o-serialversionuid/
http://blog.caelum.com.br/os-7-habitos-dos-desenvolvedores-hibernate-e-jpa-altamente-eficazes/
http://www.urubatan.com.br/orientacao-a-objetos-e-facil-as-pessoas-e-que-complicam/
http://www.rponte.com.br/2008/11/01/algumas-boas-praticas-com-jsf-e-richfaces/
http://www.objectzilla.com.br/2009/02/15/aprenda-java-ee-6-agora/
http://www.objectzilla.com.br/2009/02/24/aprenda-java-ee-6-agora-2/
http://www.objectzilla.com.br/2009/03/22/aprenda-java-ee-6-agora-3/

[Testes]
http://andrefaria.com/2008/08/22/junit-4-em-60-segundos/
http://www.urubatan.com.br/test-infected-to-the-bones-tornando-os-testes-mais-divertidos/
http://jeveaux.com/2009/palestra-testes-de-unidade-com-junit/

[Metodologia]
http://blog.aspercom.com.br/2008/05/03/3-qualidades-3-tipos-de-debitos/
http://www.akitaonrails.com/2008/12/18/tradu-o-d-vida-t-cnica
http://josepaulopapo.blogspot.com/2008/11/behavior-acceptance-test-driven.html
http://blog.improveit.com.br/articles/2008/08/06/palestra-de-modelagem-%C3%81gil-de-manoel-pimentel-na-tdc-2008
http://blog.improveit.com.br/articles/2008/08/01/documenta%C3%A7%C3%A3o-%C3%81gil

[Arquitetura e afins]
http://josepaulopapo.blogspot.com/2008/10/arquitetura-software.html
http://blog.fragmental.com.br/2008/05/18/objetos-nao-sao-atributos-funcoes/
http://architecture-journal.blogspot.com/2008/05/arquitetura-de-software-no-brincadeira.html
http://blog.fragmental.com.br/2008/05/22/domain-driven-design-e-simples/
http://josepaulopapo.blogspot.com/2008/04/qualidade-cdigo-manutenibilidade.html
http://diego-pacheco.blogspot.com/2009/01/o-papel-do-arquiteto-de-software.html

Com certeza teremos muitas coisas legais misturadas com dicas para iniciantes, assuntos avançados e  coisas/praticas que não devemos seguir

Segue os primeiros links com algumas coisas legais de jQuery:
http://i18n.2kminterativa.com.br/jquery/jquery-getting-started-pt_br.html
http://visualjquery.com/
http://pedromenezes.com/os-40-melhores-plugins-da-jquery-para-facilitar-a-vida-do-desenvolvedor-web
http://pedromenezes.com/programar-plugins-jquery-produtividade
http://www.sastgroup.com/jquery/240-plugins-jquery
http://www.dirceupauka.com/excelentes-truques-e-dicas-para-jquery
http://code.google.com/p/checkboxtree/
http://www.datatables.net/

Espero que gostem!

Normalmente não me pronuncio acerca de questões eleitorais, mas diante do momento que estamos vivendo, não diremos, nas palavras do Pr. Piragine, “em quem votar, mas em quem não votar”…

Referência: http://blogdosubira.wordpress.com

Quem é esse Sinatra?
Para quem não saber Sinatra é uma linguagem de domínio específico (DSL – Domain Specific Language) para a criação rápida de aplicações web escritas em ruby. Ele mantém uma característica mínima definida, deixando livre o desenvolvedor para utilizar as ferramentas que melhor lhe servir em sua aplicação.

BDD? Cucumber?
BDD ou Behavior Driven Development(Desenvolvimento Guiado por Comportamento) é uma técnica de desenvolvimento Ágil que encoraja colaboração entre desenvolvedores, setores de qualidade e pessoas não-técnicas ou de negócios num projeto de software. O foco em BDD é a linguagem e interações usadas no processo de desenvolvimento de software.

O Cucumber foi criado para permitir que você execute a documentação de funcionalidades de uma aplicação, escritas em texto puro (também conhecidas como “estórias”). Com o Cucumber, isto é uma especificação executável que você pode discutir com seu cliente e então usá-la para verificar o comportamento correto dos testes. Por trás dos bastidores, você faz isto funcionar criando “steps”, que são expressões regulares que executam código em Ruby.

Webrat
Webrat é uma ferramenta fantástica que permite escrever rapidamente testes de aceitação expressivos e robustos para uma aplicação web Ruby. Ele nos fornece entre outras coisas:

• Simulador de browser de alto nível;
• Suporta vários frameworks web Ruby;
• Suporta os mais populares frameworks de teste;
• Fornece uma API para verificar o HTML gerado usando CSS, XPath, etc.

Depois de feita as devidas apresentações vamos colocar a mão na massa. O primeiro passo é criar o diretório de nosso projeto.

1
2

$ mkdir sinatra-cucumber
$ cd sinatra-cucumber

Vamos acessar a pasta do projeto que acabamos de criar e executar os comandos abaixo para criar a pasta onde iremos definir nossas features.

1
2

$ mkdir features
$ touch features/ola.feature

Obs.: Para quem não conhece o comando touch apenas criou um arquivo vazio.

No arquivo ola.feature escreva o seguinte código:

1
2
3
4
5
6
7
8
9

# language: pt
Funcionalidade: Ver páginas
  Como um usuário qualquer
  Eu quero acessar as páginas do sistema
  Para ter acesso a seu conteúdo
 
  Cenário: Página principal
    Dado que acabei de acessar o sistema
    Então Eu devo ver o texto "Olá, pessoal!"

Vamos executar o cucumber e ver o que acontece.

1

$ cucumber features/ola.feature

Como era de esperar o teste não passou. Vamos em seguida criar os testes para nossa funcionalidade mais antes iremos criar uma tarefa rake para otimizar a chamada do Cucumber.

1

$ touch Rakefile

O código para nossa tarefa rake que será executada com o comando “rake features” é o seguinte:

1
2
3
4
5
6

require 'rubygems'
require 'cucumber/rake/task'
 
Cucumber::Rake::Task.new(:features) do |t|
  t.cucumber_opts = '--format pretty'
end

Agora sim podemos continuar.

1
2

$ mkdir features/step_definitions
$ touch features/step_definitions/ola_steps.rb

No arquivo ola_steps.rb teremos o seguinte código:

1
2
3
4
5
6
7

Dado /^que acabei de acessar o sistema$/ do
  visit("/")
end
 
Entao /^Eu devo ver o texto "(.+)"$/ do |texto|
  response_body.should =~ Regexp.new(Regexp.escape(texto))
end

Estes dois passos simples fazem uma solicitação a url do nosso aplicativo pelo Webrat e verifica se a resposta contém o texto que estamos procurando.

Abaixo segue as configurações que fazem a integração realmente acontecer. Vamos configurar o ambiente do Cucumber para usar o Webrat.

1
2

$ mkdir features/support
$ touch features/support/env.rb

O conteúdo do arquivo env.rb deve ser o seguinte:

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

require 'spec/expectations'
require 'rack/test'
require 'webrat'
 
Webrat.configure do |config|
  config.mode = :rack
end
 
class MyWorld
  include Rack::Test::Methods
  include Webrat::Methods
  include Webrat::Matchers
 
  Webrat::Methods.delegate_to_session :response_code, :response_body
 
  def app
    Sinatra::Application
  end
end
 
World do
  MyWorld.new
end
 
require File.dirname(__FILE__) + '/../../ola'

Agora que temos nosso cenário montado podemos escrever nossa aplicação web com essas simples linhas abaixo:

1

$ touch ola.rb

1
2
3
4
5
6

require 'rubygems'
require 'sinatra'
 
get '/' do
  "Olá, pessoal!"
end

Agora vamos executar mais uma vez o Cucumber e ver os testes passando para ficarmos felizes.

1

$ rake features

Bom pessoal, o objetivo foi cumprido e espero que tenha ficado claro como é fácil desenvolver em Sinatra usando BDD com Cucumber e Webrat. Sei que o exemplo foi bem simples e abaixo segue o código fonte do projeto e alguma referências para você conhecer mais do assunto.

Código fonte

http://github.com/igocoelho/sinatra-cucumber

Conheça mais
Livro de Sinatra em Português
http://sinatra.tailorfontela.com.br/

Aplicação simples com Sinatra
http://pomoti.com/aplicacao-simples-com-sinatra

BDD com Cucumber, Selenium e Rails
http://www.slideshare.net/cmilfont/bdd-com-cucumber-selenium-e-rails

Introducão ao BDD com Cucumber, RSpec, Webrat e Selenium – Parte I
http://jefferson.eti.br/?p=96

Introducão ao BDD com Cucumber, RSpec, Webrat e Selenium – Parte II

http://jefferson.eti.br/?p=105

Introducão ao BDD com Cucumber, RSpec, Webrat e Selenium – Parte III

http://jefferson.eti.br/?p=139

Screencast Ruby on Rails: Introdução a RSpec e Cucumber
http://vimeo.com/7108280

O Ruby Tracker funciona examinando o projeto e verificando quais gems são utilizadas e principalmente quais versões. Quando for preciso autalizar qualquer gem você será informado quais outras também devem ser atualizadas e para qual versão.

Segue abaixo um vídeo demonstrando melhor o uso da ferramenta:

assert(boolean, message)
assert(person.name == “John”, “Name was expected to be John.”)
assert(item.errors.invalid?(:price))

assert_equal(expected, actual, message)
assert_equal(person.name, “John”, “Name was expected to be John.”)
assert_equal(“can’t be empty”, product.errors.on(:price))

assert_not_equal(expected, actual, message)
assert_not_equal(person.name, “Mary”, “Name was Mary and it should not be.”)
assert_not_equal(“is not a number”, product.errors.on(:price))

assert_raise(Exception, message) { block… }
assert_raise(ZeroDivisionError, “Cannot divide by zero!”) { 100 / 0 }
assert_raise(ActiveRecord::RecordNotFound) { Product.find(bad_id) }

assert_nothing_raised(Exception, message) { block… }
assert_nothing_raised(ZeroDivisionError) { 100 / [0,1].max }
assert_nothing_raised(ActiveRecord::RecordNotFound) { Product.find(good_id) }

assert_nil(object, message)
assert_nil( product, “Expected product to be nil.” )
assert_nil( Wine.find(:first, :conditions => ‘id = 1000’) )

assert_not_nil(object, message)
assert_not_nil( product, “Product should not be nil.” )
assert_not_nil( Wine.find(:first, :conditions => ‘id = 1’) )

assert_valid(activerecord_object)
same as: assert(object.valid?)
assert_valid(@person)
assert_valid( Wine.find(1) )

flunk(message)
always fails immediately; same as: assert(false, message)
flunk(“Quantity should not be greater than 100”) if quantity > 100
flunk(“Either user or account should be valid”) unless user.valid? || account.valid?

Advanced Assertions

assert_match(pattern, string, message)
assert_match(/^\d,\d{3},\d{3}$/, “1,000,000”, “Should match this format.”)

assert_no_match(pattern, string, message)
assert_no_match(/\d{3},\d{2}$/, “1,000,000”, “Should not match this format.”)

assert_in_delta(expected_float, actual_float, delta, message)
assert_in_delta(100.0, price, 20.0, “Price should be between 80.00 and 120.00”)
assert_in_delta(2, length, 1, “Length should be 1-3 feet.”)

assert_instance_of( klass, object, message )
assert_instance_of( User, person, “person should be an instance of User” )

assert_kind_of( klass, object, message )
assert_kind_of( User, person, “person should be a kind of User” )
assert_kind_of( Class, User, “User should be a kind of Class” )

assert_respond_to( object, symbol, message )
Instances only respond to instance methods, classes only respond to class methods
assert_respond_to( person, :full_name, “No response to full_name” )
assert_respond_to( User, :custom_find, “No response to custom_find” )

assert_throws(expected_symbol, message) { block… }
assert_throws(:done, “Array should be empty”) { throw :done if [].empty? }

assert_nothing_thrown(message) { block… }
assert_nothing_thrown(“Array should not be empty”) { throw :done if [1].empty? }

Rare Assertions & DEFAULT EROR MESSA GES

assert_same( expected, actual, message)
same as: assert_equal(expected, actual)
assert_same( person.name, “John”)

assert_not_same( expected, actual, message)
same as: assert_not_equal(expected, actual)
assert_not_same( person.name, “Mary”)

assert_operator( object1, operator, object2, message )
same as: assert( object1.operator(object2) )
assert_operator( 1000, :<, 2000, “Expected 1000 to be less than 2000” )
assert_operator( user, ld_enough?, Time.now(), “User should be old enough”)

assert_send([receiver, symbol, arg1, arg2], message)
same as: assert( receiver.message(arg1, arg2) )
assert_send([product, :decrement_inventory, qty], “Decrement should succeed”)

From: /activerecord/lib/active_record/validations.rb

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

@@default_error_messages = {
:inclusion => “is not included in the list”,
:exclusion => “is reserved”,
:invalid => “is invalid”,
:confirmation => “doesn’t match confirmation”,
:accepted => “must be accepted”,
:empty => “can’t be empty”,
:blank => “can’t be blank”,
:too_long => “is too long (maximum is %d characters)”,
:too_short => “is too short (minimum is %d characters)”,
:wrong_length => “is the wrong length (should be %d characters)”,
:taken => “has already been taken”,
:not_a_number => “is not a number”,
:greater_than => “must be greater than %d”,
:greater_than_or_equal_to => “must be greater than or equal to %d”,
:equal_to => “must be equal to %d”,
:less_than => “must be less than %d”,
:less_than_or_equal_to => “must be less than or equal to %d”,
:odd => “must be odd”,
:even => “must be even”
}

Referência:
http://www.nullislove.com/2008/02/20/testing-in-rails-part-10-assertions/

Mag+ from Bonnier on Vimeo.

Podemos ver que a Mag+ lança um novo olhar sobre o que as revistas do futuro podem se parecer.

Clique aqui e confira o post no Lifehacker.

Jerry Weinberg: Os 10 Mandamentos da Programação sem Ego

1. Entenda e aceite que você irá cometer erros;
2. Você não é o seu código;
3. Não importa quanto “Karatê” você sabe, sempre haverá alguém que sabe mais que você;
4. Não reescreva código sem orientação;
5. Trate as pessoas que sabem menos que você com respeito, consideração e paciência;
6. A única constante no mundo é a mudança;
7. A verdadeira autoridade nasce do conhecimento, não da posição;
8. Lute pelo que acredita, mas aceite a derrota com elegância;
9. Não seja “o cara na sala”;
10. Critique o código ao invés da pessoa – seja gentil com o programador, não com o código.

Dare Obasanjo: Os 10 Sinais de Que Seu Projeto Está Condenado

1. Tentar fazer muita coisa na primeira versão;
2. Criar uma funcionalidade crítica usando uma tecnologia não comprovada;
3. Competir com um projeto interno que já existe e que tem ótimo retorno ou tem patrocinadores poderosos;
4. A equipe tem menos pessoas que o necessário;
5. “Problemas complexos requerem soluções complexas”;
6. Prazos irreais;
7. Mudanças descontroladas no escopo do projeto;
8. Sindrome do segundo sistema “Second System Syndrome”;
9. Não ter estratégia de entrada no mercado;
10. Ficar travado em um problema que você não sabe como resolver.

Omar Shahine: As 10 Dicas Para Trabalhar na Microsoft(ou em qualquer outro lugar)

1. Processo não é substituto para raciocínio;
2. Saia do seu escritório;
3. Use seu produto(o que seus clientes irão usar);
4. Conserte as coisas que estão quebradas ao invés de reclamar por elas estarem quebradas. Ações falam mais que suas reclamações;
5. Faça um problema difícil parecer fácil. Não faça problemas fáceis parecerem difíceis;
6. Use a ferramenta de comunicação correta para o serviço;
7. Aprenda a cometer erros;
8. Mantenha as coisas simples;
9. Adicione valor sempre;
10. Use o produto dos outros.

Michael McDonough: As 10 Coisas que Nunca me Ensinaram na Escola de Design

1. Talento é um-terço na equação do sucesso;
2. 95 por cento de qualquer profissional criativo é trabalho;
3. Se tudo é igualmente importante, então nada é muito importante;
4. Não pense demais sobre um problema;
5. Comece com o que você sabe; então remova o que você não sabe;
6. Não esqueça seu objetivo;
7. Quando você joga seu peso para os lados, você geralmente cai da balança;
8. A estrada para o inferno está cheia de boas intenções; ou, nenhuma boa ação sai impune;
9. Tudo isto vai aparecer no final;
10. O resto do mundo importa.

Andres Taylor: As 10 Coisas que Aprendí em Dez Anos como Proffisional em Desenvolvimento de Software.

1. Orientação a objetos é mais difícil do que você pensa;
2. A parte difícil no desenvolvimento de software é a comunicação;
3. Aprenda a dizer não;
4. Se tudo é igualmente importante, então nada é importante;
5. Não pense demais sobre um problema;
6. Mergulhe realmente fundo em algo, mas não fique preso;
7. Aprenda sobre as outras partes da máquina de desenvolvimento de software;
8. Seus colegas são seus melhores professores;
9. Tudo isto vai terminar no programa em produção;
10. Algumas pessoas são idiotas.