Parece que estamos perto do Rails 2.0. O David Heinemeier Hansson(DHH), criador do Rails, anúnciou no blog oficial do Ruby on Rails a liberação do Release Candidate 2 da versão 2.0.

Basicamente, ele disse que esta versão corrige mais alguns bugs, e provavelmente se trata do último passo antes do aguardado Rails 2.0. Portanto, novamente segundo ele, a menos que surja algum problema grave, teremos o Rails 2.0 na próxima semana, ou, no máximo, na semana seguinte.

Agora só nos resta aguardar ansiosos por esta nova versão. E caso queira ler a informação diretamente na fonte, basta ler o post sobre o Ruby on Rails 2.0 Release Candidate 2 no blog oficial do Ruby on Rails.

A pergunta acima, apesar de ser um pouco provacativa, introduz uma discussão interessante. A maioria dos desenvolvedores, ou aspirantes a desenvolvedores, afirmam categoricamente que dominam o HTML, mas será que isto é mesmo verdade?

Pois bem, é óbvio que alguns poucos realmente o dominam, eu, pelo menos, conheço dois, mas a verdade é que a grande maioria conhece superficialmente esta tão subestimada linguagem. Em geral, ou conhecem um subconjunto relativamente pequeno do HTML, ou então conhecem apenas a sintaxe da linguagem, sem saber exatamente como usá-la, o que ao meu ver é ainda pior do que o primeiro caso.

Contudo, como a maioria dos browsers é muito pouco rígido quanto a corretude do HTML, muitos erros grotescos acabam sendo ignorados, e o browser indulgentemente apresenta a página da melhor forma possível. Como consequência, os desenvolvedores, principalmente os iniciantes, acabam construindo a noção de que conhecem bem o HTML e que ele se trata de uma linguagem fácil, chegando até mesmo a estranhar o fato de alguém estudar o assunto mais profundamente.

Eu afirmo isso sem me excluir, pois, apesar de saber da importância deste tópico, posso, na mais autoindulgente das hipóteses, me considerar apenas mediano no HTML. Digo isso pois conheço uma quantidade razoável dos seus elementos, além de saber o básico sobre o seu uso, como, por exemplo, que ele só deve ser usado para estruturar o conteúdo, e não para definir a apresentação, que é tarefa do CSS.

E por falar em CSS, o que eu disse acima também se aplica a ele e ao XHTML, embora a maioria não se considera tão proficiente nestas duas tecnologias. Isso é claro considerando os que sabem da existência do XHTML.

Entretanto, o objetivo aqui não é de maneira alguma criticar os desenvolvedores que não conhecem profundamente o HTML, até porque eu faço parte desta parcela, além de sequer ser um desenvolvedor ainda. O que eu pretendo aqui é despertar em alguns de vocês a consciência recém-adquirida por mim de que o HTML é mais do que algumas poucas tags jogadas de qualquer maneira em um arquivo .html. Ele merece sim atenção, além de um estudo um pouco mais extenso do que um breve tutorial.

Eu estou fazendo a minha parte, uma vez que estou lendo no momento o Use a Cabeça! HTML com CSS & XHTML. Aliás, este é um livro excelente, e a sua tradução não compromete a compreensão do texto, portanto eu o recomendo.

Sendo assim, vamos conhecer de verdade o HTML, XHTML e CSS. Isto é um bem que fazemos a nós mesmos, pois são estas tecnologias que formam a base da Web, e se quisermos atuar neste ambiente temos a obrigação de conhecê-las. Quem sabe assim nós contribuimos para uma Web menos caótica. Não custa sonhar.

Pois é, o Rails Core Team liberou mais uma versão do Rails, e novamente trata-se de um release de manutenção e segurança.

Dessa vez foi corrigido um bug relacionado a sessões, portanto, a menos que você esteja tomando contra medidas específicas a este bug, deve atualizar para a versão 1.2.6.

Sendo assim, para atualizar a sua instalação do Rails, siga os passos abaixo, conforme instruído no blog oficial do Ruby on Rails:

1. Execute o comando gem install rails na janela de comando do seu sistema
2. Configure a RAILS_GEM_VERSION para 1.2.6 em config/environment.rb
3. Execute o comando rake rails:update:configs em uma janela de comando.

Para maiores informações, basta ler o post anunciando o Rails o 1.2.6 no blog oficial do Rails.

Nada melhor que o humor para exemplificar um conceito, no caso o SQL Injection:

Caso não consiga ler as legendas, clique na tirinha para visualizá-la no seu tamanho original.

Este ano já pode ser considerado o mais movimentado da comunidade Rails no Brasil. Já tivemos o RejectConf SP’o7, ainda teremos o Rio on Rails 2007 e o Rails for Kids 2007, e agora mais um evento é confirmado: o Minas on Rails’07.

O encontro será realizado no dia 1 de dezembro, das 9 horas até 19 horas, no auditório do campus Aymorés do Centro Universitário UNA. Entre os palestrantes estão Eustáquo “TaQ” Rangel, Ronaldo Ferraz e Vinicius Manhães Teles.

A inscrição custa R$20 e inclui, além das palestras, uma camiseta do encontro e o coffee break. Para maiores informações sobre a programação das palestras ou sobre o evento de forma geral, basta consultar o site oficial do Minas on Rails’07.

Portanto, se você é de Minas Gerais, ou mesmo de outros estados, e quer saber mais sobre Ruby ou Rails, ou simplesmente quer ouvir o que tem a dizer algumas das referências nacionais no assunto, não deixe de comparecer a este encontro.

Na última semana, durante uma aula de Engenharia de Software 2, foi levantada uma questão interessante: quem tem culpa quando um sistema dá errado?

Durante o debate, um dos alunos, provavelmente um desenvolvedor, defendeu a idéia de que a culpa é sempre do usuário, que, em sua infinita imaginação, sempre consegue utilizar o sistema da maneira errada.

Como exemplo, foi citado uma aplicação que possuia um formulário para busca contendo datas, sendo que, por algum motivo qualquer, não se poderiam fazer buscas sobre ocorrências anteriores a 1985, pois isto resultaria em um erro. Acontece que os usuários do tal sistema frequentemente se esqueciam deste detalhe, persistindo em realizar buscas informando datas inválidas. E por mais que os desenvolvedores os lembrassem desta limitação, o problema permanecia, levando a conclusão, por parte do aluno, de que o problema está no usuário.

Já o professor, sabiamente, afirmou que se o usuário erra, é porque o desenvolvedor permitiu que tal erro ocorresse. Por exemplo, no caso mencionado acima, o mais apropriado seria que fosse impossível entrar com uma data inválida, ou simplesmente verificar a entrada e não processá-la se for o caso, gerando assim uma mensagem para o usuário. Portanto, neste caso, se o usuário errou, é porque o desenvolvedor errou antes.

Mas, apesar de concordar com o professor neste exemplo, devemos considerar que é apenas uma situação isolada. No geral, embora seja uma das funções do desenvolvedor evitar erros do usuário no uso do sistema, é evidente que ele não é o único culpado quando as coisas dão errado.

Responsabilizar apenas uma das partes é sempre uma atitude extrema e preguiçosa. A responsabilidade pelo sucesso ou fracasso de qualquer sistema depende tanto de quem o desenvolve como de quem o utiliza. No entanto, o relacionamento entre os usuários de uma aplicação e os seus desenvolvedores é bastante complicado por “culpa” de ambas as partes.

Do lado dos desenvolvedores, a noção de que o usuário é sempre o culpado é bastante comum. A verdade é que é sempre mais fácil delegar a culpa a outra pessoa, e como nesta situação há basicamente apenas dois papeis envolvidos, só sobrou mesmo o usuário para culpar. Portanto, não espero ouvir de um desenvolvedor algo do tipo “O sistema saiu do ar devido a um erro que eu cometi”. As pessoas, em geral, são orgulhosas e não têm muita auto-crítica, e não seria diferente com quem desenvolve software.

Já da parte do usuário, por estar muitas vezes consciente desta posição dos desenvolvedores, eles acabam se sentindo acuados e constantemente vigiados, de forma a serem responsabilizados pele erro mais recente do sistema. Isto, somado ao fato de sempre haver a suspeita, nem sempre infundada, de que um novo sistema pode significar demissões, acaba fazendo com que ele veja o desenvolvedor como uma ameaça ao seu emprego, ou pelo menos à sua posição na empresa, o que obviamente prejudica bastante a relação entre eles.

A verdade é que existem sim usuários menos capazes, e é natural que eles utilizem o sistema de forma menos produtiva, no entanto, se este tipo de usuário causar de fato um erro no sistema, é porque este erro não foi evitado antes pelos desenvolvedores. Até porque, inaptidão não é uma característica presente unicamente nos usuários. Ou, em português claro, também existem desenvolvedores ruins.

O que nós temos que entender é que mesmo que não sejamos desenvolvedores ruins, qualquer aplicação que formos desenvolver em uma empresa irá falhar se não contarmos com a colaboração daqueles que a usarão. Ninguém entende melhor do que o usuário o que o sistema deve realmente fazer, incluindo algumas sutilezas que jamais seriam imaginadas por nós. E são justamente estas sutilezas que resultarão em erros no futuro, caso nós não soubermos como vencer a barreira invisível que existe entre nós e os usários. Afinal, seja lá o que estivermos desenvolvendo, muito provavelmente será utilizado para informatizar o trabalho que este usuário desenpenha na empresa, e ninguém melhor do que ele mesmo para nos dizer como funciona este trabalho.

No fim das contas, para fazermos bem o nosso trabalho precisamos da cooperação do usuário. Portanto, é necessário darmos o primeiro passo e mudarmos de atitude, para que assim o mesmo aconteça do outro lado, possibilitando a ambos um melhor desempenho nas tarefas que somos pagos para fazer.

O Carlos Eduardo, dono da e-Genial, está organizando uma maratona de palestras online sobre Ruby e Ruby on Rails, cuja renda será totalmente doada para uma instituição de caridade chamada Cotolengo.

O evento, que se chama Rails for Kids 2007 , acontecerá no dia 15 de dezembro, e terá ao todo 10 palestras, cada uma com uma hora de duração, sendo todas elas ministradas através do Treina Tom.

Para a participação no evento será cobrada uma taxa de R$25, sendo que, como foi dito acima, o total arrecadado com as inscrições será integralmente doado ao Cotolengo.

Entre os palestrantes estão vários nomes conhecidos do cenário Ruby/Rails nacional, como, por exemplo, Fabio Akita, Carlos Brando e Vinicius Manhães Teles. Além disso, o Rails for Kids irá contar também com a presença de um convidado internacional: Carl Youngblood.

Para maiores informações visite o site oficial do Rails for Kids 2007. Como poderão ver, o evento terá uma ótima grade de palestras, sendo assim, trata-se de uma ótima oportunidade de aprender um pouco mais e ainda ajudar alguém.

Por fim, é interessante dizer que os vídeos das pelestras serão disponibilizados para download para aqueles que se inscreverem, portanto, caso alguém não possa assistir a todas as palestras no dia 15, ainda assim poderá baixá-las e assistir depois.

As inscrições para o Rio on Rails foram abertas há algumas horas atrás, e, como as vagas são bastante limitadas, quem quiser ir deve se cadastrar logo para garantir a presença no evento.

Após preencher o formulário de inscrição no site do Rio on Rails, você deve ligar para o SENAC e confirmar o pagamento, que é no valor de R$50 e só pode ser feito com cartão de crédito Visa ou Mastercard. É importante ressaltar que a inscrição só será realmente efetuada após a confirmação do pagamento junto ao SENAC.

No site do encontro foi disponiblizada a grade de palestras, a qual eu reproduzo abaixo:

9:00

Palestra:
Tomando a pílula vermelha - Bem-vindo ao desenvolvimento web sem dor com Ruby On Rails

Palestrante:
Demetrius Nunes.

10:00

Palestra:
Brazilian Rails

Palestrantes:
Marcos Tapajós, Celestino Ferreira Gomes e André Luiz Kupkovski.

11:00

Palestra:
Projeto Lucidus - Produtividade ao extremo com XP e Rails

Palestrantes:
Vinícius Manhães Teles, Alexandre Novello, Felipe Barreto, Rafael Fraga Walter, Luciano Pelegrini, Elmar Müeller, Ricardo Gomes, Marcos Tapajós e Leandro Mello.

14:00

Palestra:
Mr. M - Desvendando as Mágicas do Rails

Palestrante:
Fabio Akita.

15:00

Palestra:
Domain Specific Languages - Estendendo o Rails para produtividade máxima

Palestrante:
Ronaldo Ferraz.

16:00

Palestra:
Behaviour-Driven Development (BDD) - Com RSpec e RSpec on Rails

Palestrante:
Danilo Sato.

17:00

Palestra:
Flex + Rails além de seu desktop

Palestrante:
Carlos Eduardo.

Vejo vocês lá.

Há poucos dias atrás foi criado no fórum do GUJ(Grupo de Usuários Java) um tópico sobre a necessidade de profissionais de TI cursarem uma faculdade.Foi uma discussão bastante interessante, onde muitas pessoas expressaram a sua opinião sobre o assunto, inclusive eu. E, depois de reler todos os posts do tópico e pensar um pouco mais a respeito, decidi ampliar a minha resposta a esta pergunta.

Como disse lá no GUJ, a necessidade de um curso superior para profissionais de TI depende basicamente do que a palavra necessidade se refere neste caso. Ou seja, necessário para o quê exatamente?

Se for em relação aos conhecimentos adquiridos durante a faculdade, fica difícil responder, pois isso varia muito de instituição para instituição. Algumas delas agregam bastante conteúdo aos alunos, e outras fingem que ensinam alguma coisa. De qualquer forma, em ambos os casos, o aluno pode adquirir todo este conteúdo por conta própria, dependendo obviamente do perfil da pessoa. Alguns tem capacidade de aprender através de livros, por exemplo, e assimilar todo o conteúdo visto na faculdade, ou até mais. Mas há também aqueles que precisam ter aulas para aprender, o que justifica cursar uma faculdade. De qualquer forma, nenhum dos dois é melhor que o outro, são apenas perfis de pessoas diferentes.

Já em relação ao mercado de trabalho, atualmente é muito difícil conseguir um emprego em TI sem curso superior, mas não é impossível. Eu mesmo conheço pelo menos uma pessoa que conseguiu um bom emprego na área sem ter concluído a faculdade. Na verdade, esta pessoa começou a graduação assim que conseguiu o emprego, por exigência da empresa. Portanto, a faculdade costuma facilitar as coisas, mas não ter cursado ou completado uma não impossibilita ninguém de ter uma carreira em TI, apenas dificulta as primeiras contratações.

Ainda sobre o mercado de TI, temos também que considerar o objetivo profissional de cada um, o que nos faz perceber uma exceção do que foi dito acima. Um desenvolvedor, por exemplo, pode fazer uma faculdade para facilitar a sua entrada em uma empresa, ou então para aprender parte do conteúdo que precisará(não se engane, faculdade alguma ensina todo o conteúdo necessário), no entanto, isto não se trata de uma exigência para este tipo de profisisonal. Contudo, há casos de carreiras que de fato exigem uma vivência acadêmica, como, por exemplo, um professor universitário, que dificilmente terá menos do que um mestrado.

Sendo assim, a resposta para esta pergunta é a mesma de outras tantas perguntas relacionadas a TI: depende. Depende do perfil da pessoa e dos seus objetivos profissionais. Mas o que realmente importa aqui é sabermos que nenhum pedaço de papel qualifica(ou desqualifica) uma pessoa. Um bom profissional, não só de TI, é construído através da experiência e da constante dedicação em se aprimorar na sua área.

Já vimos de forma resumida como funcionam as variáveis no Ruby e também como gerar saída de dados com puts, print e printf, no entanto, até o momento, isto não nos serve muito, já que todo dado que quisermos armazenar e/ou exibir teriam que ser inseridos por nós diretamente no código. Sendo assim, para tornar as coisas um pouco mais interessantes, veremos agora como ler dados do teclado através da janela de comando no Ruby.

Usando o método gets

O gets é um método que lê e retorna a próxima linha do fluxo de entrada padrão, que, por padrão, refere-se à janela de comando. Sendo assim, ele nos permite, entre outras coisas, ler um dado digitado pelo usuário através da janela de comando. Veja abaixo um exemplo:

print "Digite o seu nome: "
nome = gets
puts "Seu nome: " + nome

Algo interessante a ser dito sobre o gets é que mesmo que você não armazene o seu retorno em uma variável, o Ruby automaticamente irá inserir este valor na váriavel global $_. Além disto, se chamarmos o método print sem especificar nenhum argumento, ele automaticamente irá exibir o valor de $_. Veja a seguir este recurso em funcionamento:

gets
print # É o mesmo que print $_
teste = gets
print # É o mesmo que print $_

Como vimos, o gets armezena em $_ o valor que ele retorna, tanto no primeiro caso, onde não armazenamos explicitamente este valor em uma variável, como no segundo, onde o armazenamos na variável teste. No entanto, é importante mencionar que o uso do $_ está gradualmente sendo abandonado pela comunidade Ruby.

Lendo mais de uma linha com readlines

Existe também o método readlines, que nos permite ler várias linhas na janela de comando de uma só vez. Para isto, basta digitar cada linha, e separá-las pressionando a tecla Enter, o que irá inserir um caractere de nova linha(\n) entre cada linha digitada. Para encerrar a entrada dos dados, basta inserir o caractere de fim de arquivo representado por Ctrl + C, na última linha, sendo que nesta linha não pode estar presente nenhum outro caractere. Além disso, é importante saber também que o readlines retorna as linhas digitadas na forma de um array, sendo cada linha um elemento deste array.

puts "Faca um resumo da sua vida: "
resumo = readlines
puts "nResumo: nn"
puts resumo