Working With Rails

Episode 117: Semi-Static Pages

by Ryan Bates | about 4 hours ago | Read more

Static pages can sometimes be a little awkward to add to a Rails app. See a couple different solutions to this problem in this episode.

One million integers?!

by Tobias Luetke | about 9 hours ago | Read more

This is a great general purpose interview tip:

If you don’t know how to answer a question because it’s way outside of your expertise simply give it your best guess and negate the question.

via youtube:

<object height="344" width="425"><param></param><param></param><embed src="http://www.youtube.com/v/k4RRi_ntQc8&#38;hl=en&#38;fs=1" height="344" width="425"></embed></object>

This can sometimes have pretty impressive results.

Mais uma turma de Ruby terminada em 05/07/2008

by Eustáquio Rangel | about 23 hours ago | Read more

Ontem terminou mais uma turma do curso de Ruby da Object Training, cuja foto pode ser vista aí em cima. Foi uma turma muito legal e quero agradecer a todos pela presença, pelas boas risadas e ótimo ambiente que tivemos. Espero que tenham aproveitado o curso e desejo um ótimo curso de Rails para todos que vão fazer.

Eu cheguei na Sexta em SP a convite do Mereghost, e fui conversar com uma galera muito legal a qual ele está incentivando para o uso de Ruby/Rails. Tomara que todos tenham aproveitado o papo, eu achei muito legal.

Eu, o Luiz Rocha e o Ronaldo Ferraz íamos gravar o Pão de Cast ao vivo, mas novamente a coisa não rolou. A esposa do Luiz passou mal (melhoras!) e o Ronaldo ficou enrolado com o Brasigo (carácoles, na Sexta à noite!) e vamos ter que gravar via web mesmo. Algum dia a gente consegue gravar ao vivo, já que agora está mais fácil pois o Ronaldo está em SP.

Agora é descansar algumas semanas. Apesar de ser bem legal, viajar todo Sábado cansa, ufa!

Salve os desenvolvedores - Diga não ao Internet Explorer 6

by Carlos Brando | 1 day ago | Read more

É normal no mundo do desenvolvimento de software discussões sobre qual tecnologia é melhor ou pior e normalmente isto gera muito flame war, mas existe uma coisa que todos os desenvolvedores (seja ele de java, ruby, php, …) concordam: o Internet Explorer 6 demorou para sumir da face da Terra. Por isto também entro na campanha [...]

The only important rule is ...

by Marcel Molina Jr | 1 day ago | Read more

“ The only important rule is that all sexual climaxes must be simulated, not real. ”

Austin AIR SEX Championships

Miyajima ferry

by Marcel Molina Jr | 1 day ago | Read more

Miyajima ferry

21st Century Schizoid Man b...

by Marcel Molina Jr | 1 day ago | Read more

21st Century Schizoid Man

King Crimson

Edison – Failure of t...

by Marcel Molina Jr | 1 day ago | Read more

Edison – Failure of the Year

Edge Rails: Solução de bug no método rename_column

by Carlos Brando | 3 days ago | Read more

Esta alteração trata-se na verdade de uma correção de um bug no método rename_column. Para entender qual era o problema precisamos de um cenário como exemplo. Primeiro criamos um migration: create_table “users“, :force => true do |t| t.column :name, :string, :default => ‘‘ end Ok, agora criamos um segundo migration onde vamos renomear a coluna name da [...]

Unit Testing iPhone apps with Ruby: rbiphonetest

by Dr Nic Williams | 3 days ago | Read more

Everything to love about Ruby: the concise, powerful language; the sexy testing frameworks; and finally, the people. Everything to love about Objective-C: hmmm; well…; and finally, its the only high-level language you can use to write iPhone apps. On iPhone 2.0, to arrive on the 11th of July, you cannot run RubyCocoa. But you can run it [...]

Announcing Reevoo Labs

by Luke Redpath | 3 days ago | Read more

Here at Reevoo, we’ve just (literally) gone live with our new open-source website, Reevoo Labs. Our old open-source site is moribund and now redirects to the new site.

The Immaturity of In Browser Testing

by Jay Fields | 3 days ago | Read more

Designing applications that behave the same in several browsers is a miserable job. Unfortunately, it's often a business requirement. If your application needs to behave flawlessly in multiple browsers, In Browser testing is probably a necessary evil.

I tend to use Selenium for In Browser testing; therefore, this entry is written from the perspective of a Selenium user.

Selenium is terrible for several reasons.

• There are several ways to drive Selenium, and none of them are particularly mature. Should you use SeleniumRC, Selenium on Rails, the in browser recorder, or some other half baked solutions? I don't have the answer. I've used all 3 of the named solutions and found them all to be problematic. Yes, the problems can be gotten around, but they are there and solving them costs time.
• There are several languages for writing tests. Should you use Java, Ruby, Python, Perl, etc? I have no idea. Having the choice might seem like a good thing -- until the person who was writing the majority of tests leaves and the next person to take on the Selenium suite decides he wants to use another language. The languages are also fairly clunky. I can't help wondering if a better solution would have been to create a DSL specific to the in browser testing space.
• I could have written this entire blog entry before most of the Selenium suites in the world would finish. In Browser testing is almost unacceptably slow. Selenium Grid sets out to solve this problem. So you should use that, right? Not exactly, it's not worth the effort unless you have a large suite, and it requires you to go down the SeleniumRC path, which may or may not be the right choice for you.
• Selenium suites quickly reach the size where their value is not proportionate to the amount of effort the tests require to maintain. Thinking about throwing your suite away? If you do you'll be joining a very large club of developers who decided to dump their Selenium suites. It is very hard to design a large Selenium test suite that provides value. I've heard of several suites that were thrown out and only one suite that was large and the team believed it provided value. I guess there's hope, 1 team managed to get it right.
• Browsers are buggy. While Selenium itself might justify it's value, spending a week figuring out what the latest bug in IE is starts to call in question the value of the Selenium suite. Of course, you can stop testing in IE, since only IE breaks the build, but if you need to deploy to an environment where users will be on IE... you're in a bad spot.
• Selenium is great for verifying that everything works as expected, but when a test breaks you get little information on what the problem is. Since the tests are running at such a high level, it's unlikely that you'll be able to easily identify the majority of defects based on the broken Selenium test. The broken test is a great tip that something is wrong, but you'll likely need to do some digging to figure out exactly what is wrong.

Of course, there is another point of view. There are several reasons that Selenium is a good tool.

• The only real way to know that your application runs in all browsers is to test it in all browsers. Selenium makes it possible to run the same tests regardless of browser.
• The only way to verify that all the pieces of your application integrate perfectly is to test against the entire application stack. Selenium provides a great tool for simulating user experience.
• Once you make a decision on what version to use and what language to use, writing tests is easy. Getting started with Selenium takes very little time, including time for learning.
• For those less than technical team members, the Selenium recorder can be a great tool for creating tests.
• Selenium also represents a tool that is helpful for both developers and testers.

The trick to using Selenium is knowing who (for), what (for), when, and why it's useful. For those that desire concise descriptions -- Selenium is best used by developers or testers when testing the most valuable (to the business) happy paths of a Javascript heavy web application that must function in several browsers.

When you begin to deviate from the above context, things begin to get problematic.

Selenium is undoubtably a tool that can be used by both developers and testers. The various ways to drive the tool ensure that both less than technical users and very technical users both have options. Selenium is best used for happy path testing because large suites can be both hard to maintain and prohibitively slow. Selenium is an appropriate choice for Javascript heavy applications since the tests run directly in the browser, ensuring expected behavior. Selenium is also helpful for mitigating cross-browser compatibility risks. The write once, run in several browsers model is a powerful one. You should chose Selenium when it can improve your confidence that the highest business value features are working correctly.

Despite it's problems it would be misleading not to mention that it probably is the best solution for In Browser testing, but there is surely room for improvement.

Edge Rails: Crie regras para o String#humanize

by Carlos Brando | 4 days ago | Read more

Já faz um certo tempo que Pratik Naik está tentando colocar este patch no Rails e parece que finalmente conseguiu. No arquivo config/initializers/inflections.rb você tem a opção de acrescentar novas inflexões para pluralização, singularização e outros: Inflector.inflections do |inflect| inflect.plural /^(ox)$/i, ‘\1en‘ inflect.singular /^(ox)en/i, ‘\1‘ inflect.irregular ‘person‘, ‘people‘ inflect.uncountable %w( fish sheep ) end Na [...]

As usual, Ruby is 100 times...

by Marcel Molina Jr | 4 days ago | Read more

“ As usual, Ruby is 100 times slower. ”

Mauricio Fernandez

100 yen in Hiroshima

by Marcel Molina Jr | 4 days ago | Read more

100 yen in Hiroshima

The Unanswered Question by ...

by Marcel Molina Jr | 4 days ago | Read more

The Unanswered Question

Charles Ives

IM

by Marcel Molina Jr | 4 days ago | Read more

IM

Paper Prototyping

by Marcel Molina Jr | 4 days ago | Read more

Paper Prototyping

Edge Rails: Array#second até Array#tenth

by Carlos Brando | 5 days ago | Read more

Que David Heinemeier Hansson (DHH) gosta de inventar coisas no Rails não é segredo para ninguém, mas algumas vezes ele meio que exagera um pouco. Veja por exemplo esta última adição que ele fez. No objeto Array hoje já temos o método first e last, então porque não ter também os métodos second, third, fourth e [...]

Microsoft to Aquire Powerset

by Kevin Clark | 5 days ago | Read more

There’s details here. Sounds like they’re keeping us intact, and there’s something to be said about having an additional 10k machines behind you.

We’ll see what happens.

Prettify Your Ruby Diffs

by Tim Pope | 5 days ago | Read more

You've probably noticed that Git puts additional context data in the hunk headers: the lines that start with @@ and specify the line numbers where the hunk fits. For example, in the Rails Git repository, git show 13e7849 reveals the following two lines:

@@ -39,12 +39,7 @@ module ActionController #:nodoc:
@@ -67,6 +62,12 @@ module ActionController #:nodoc:

The algorithm Git uses to choose these lines is simple: search backwards for the first line with something other than whitespace in the first column, and use that. This works great for C, but as you can see above, it's not quite as informative when it comes to Ruby. Lucky for us, it can be customized with a two step process.