Olá Carlos,
estou baixando este episódio e já estou ansioso para escutá-lo.
Tomei a liberdade de criar um post sobre este episódio no blog que estou criando.
Um abraço,
Diego Alencar

@Diego - Fique à vontade de falar sobre o podcast. Grande abraço e boa sorte em seu novo blog!

[...] ouvindo neste exato momento o episódio #5 do Rails Podcast Brasil, com o Carlos Brando e com o Fábio Akita. Eles estão tratando de um assunto muito importante que [...]

Nesse ponto que eu sempre “discordei” do Rails, ele embute o Javascript na página, o que não é accessível, seria melhor se ele usasse Js não-obstrusivo, todo código Js fora do HTML, comportamento, assim como CSS fora do HTML, estilo. Muito bom o episódio!

Legal Bernardo. Eu concordo com vc, mas existem alternativas para isto no Rails. Embora eu também ache que isto deveria ser nativo.

Essa questão de Javascript Unobstrusive eu pessoalmente prefiro dividir assim: quando faço aplicações para intranets, coisas que serão usadas apenas em ambientes controlados, realmente eu não me preocupo nem um pouco com isso. Agora, se o site for público, onde qualquer pessoa, em qualquer plataforma, com qualquer browser possa acessar daí essa questão passa a ser importante. O problema é: qual framework Javascript é o melhor pra usar? Prototype+Scriptaculous? +LowPro? JQuery? YUI? Tá difícil O ideal era finalmente criarem um padrão na W3C para compensar esses defeitos todos.

Coloquem esse episódio no feed! O itunes aqui só está vendo até o 4…

Valeu!

Hmm… vou precisar pedir ajuda para o Rodrigo Urubatan…

Opa, Carlos, o que aconteceu com o CarreiraTI? hehe Era o seu startup!

Então Hugo, eu tivo problemas com a troca de servidor, e estou com outros planos para o carreiraTI, então ele deve voltar logo, mas bem diferente… espero… rs

@Akita

Eu já tive sérios problemas com javascript Unobstrusive dentro do ambiente que eu achava controlado Existem pessoas que agem de má fé dentro da própria empresa… Acho que até nesses casos é bom ter cuidado.

Um abraço!

@Glaucio

Eu mesmo já tive problema com isso.

Como vai Carlos, tudo bem? Respondendo a pergunta feita no podcast, a Milk-it é uma empresa de desenvolvimento de softwares em plataforma web, e que deseja ser uma Fábrica de Software Também prestamos consultoria e outsourcing, no mais, http://www.milk-it.net/servicos lhe dará mais respostas..!

Obrigado!

Blz Carlos Júnior. Faltou dar uma pesquisada antes do podcast mesmo! Sucesso para vcs!

Ah, e gostei do nome, rs!

Agora, é a terceira vez que tento terminar de ouvir o podcast! Esse ficou gigante! Mas ta muito massa.
E cadê a musiquinha de fundo?
Abraços,

Cairo Noleto

muito bom os podcasts!!!

Qualidade ótima!!!

Continuem assim!

Cairo, realmente este ficou grande. Mas é muito díficil gravar apenas uns 15 ou 20 minutos… e olha que quando começamos combinamos em ser rápidos, mas os assuntos vão aparecendo no meio do caminho e quando eu vou ver, lá se foi pelo menos uma hora… rs

Mas é isso aí, ouvir o podcast em pedaços, hehe

15? 20 minutos? Isso é uma musica, e não um podcast! Eu acho que o tamanho ideal é de +/- 60 minutos.

Eu gostei muito sobre o Heroku, o legal tambem é que podemos compartilhar o desenvolvimento da aplicação, criando usuarios e administrando isso tudo!

Eu só acho que falta algum ftp ou coisa do genero pra sincronizar com projetos que eu queira passar pra lá (Se tiver, por favor, me digam como posso fazer funcionar!).

Abraços,

Cairo Noleto

Hmm… verdade. Se pudessemos criar algo e jogar lá via git por exemplo, e ainda ter a interface para alterar via web seria bem legal mesmo. Mas acho que não é assim que funciona…

Mas a idéia é boa!

E outra, o Heroku ainda é beta, vi numa thread do rail-br que ele vai ser pago (Foi atraves da thread que eu conheci) após a fase beta.

Talvez essa funcionalidades sejam acrescentadas conforme o feedback…

Pessoal, achei esse um dos melhores podcasts. Talvez porque esteja falando de assuntos que agradam.
Só queria comentar que é muito legal ver as pessoas tomando ciência que não existe aplicação decente sem testes. Eu sou um maníaco por testes e não consigo pensar em fazer algo sem ser com testes e vou um pouco além preferindo fazer com TDD. Atualmente fui contaminado pelas várias apresentações do Danilo Sato sobre RSpec e estou usando BDD e tenho gostado bastante.
Carlos, acho que num outro podcast você comentou sobre não conseguir fazer TDD e queria apenas dar os meus pitacos. Fazer TDD é algo que depende muito de disciplina. No início pode parecer mais complicado mas com o tempo você acaba vendo as vantagens de se fazer isso. Eu sempre falo que o TDD é mais do que um teste, é uma forma de pensar num designer bem simples para a sua aplicação.

Se você conseguir escrever os cenários de testes antes e depois for fazer a aplicação apenas para passar nos seus testes certamente você escreverá o mínimo de código e com isso terá menos chances de errar.

Se você tiver ciente que o TDD pode te ajudar te sugiro forçar um pouco a barra que com a prática você vai ver que é muito mais simples do que parece.

Nas diversas consultorias que eu fui a principal dificuldade que eu sempre vi está ligado a falta de domínio do ferramental de testes. Acho fundamental conhecer bastante a estrutura de testes para tornar o trabalho mais ágil (não é Ágil !). Para você ter uma ideia dificilmente encontro alguém que conheça ou já tenha usado Mock Objects.

Não conheço a sua experiência com testes e com TDD, então pode ser que esse não seja o seu caso, que seja apenas falta de costume mesmo. Só estou comentando a minha experiência mesmo.

Acho que foi o Akita que comentou sobre uma taxa de testes de 1:1.2 ou algo parecido com isso e confesso que acho muito pouco. Não conheço a aplicação em questão mas pela minha experiência com essa taxa é difícil exercitar todas as partes do código. No meu projeto atual a taxa é de 1:2.6.

Bem, acho que já me meti bastante aqui.

Um abração e parabéns aos dois.

Poxa Tapajós, é legal saber que vc está gostando do poscast.

Quanto ao lance de testes, é o seguinte, eu simplesmente não consigo fazer o teste antes. Não é que não faço testes, eu faço sim, mas depois de criar o meu código. O problema com este tipo de testes é que ele é meio condicionado. Na maioria das vezes vc cria apenas o teste para verificar se o método retorna o esperado e pronto. Não se testa excessões e etc…

Tanto é que no refactoring de testes que eu fiz esta semana, a maioria dos casos eram onde não havia cobertura de testes era nos códigos de tratamento de excessões ou algum if que fazia o método retornar algo fora do básico.

Em breve nós vamos começar um novo projeto, e desta vez eu prometo que vou começar tentando focar em testes, e escrevendo testes antes. Depois eu conto como foi… rs

Abraço!

Acabeu de ouvir o podcast agora e gostei bastante.

Algo que eu achei legal vocês terem mencionado é o memcached, já que eu pensava ser algo bem complexo, quase místico, e pelo que ouvi não parece ser tão complicado de usar.

Parabéns novamente aos dois.