Here are a few interesting things I stumbled across while reading the Rails book recently:
Use debug(object) to dump an object to the screen in a template.
Here's how to use the debugger to debug your web app. First, "gem install ruby-debug". Then, start the server via "./script/server --debugger". Now, add "debugger" in your code.
Use "rake --tasks" to see the full list of rake tasks available.
Use "rake --describe task" to describe a particular task.
David Heinemeier Hansson said this on page 261, "Learn to cope with the panic attacks of unexplained errors."
To create a new, struct-like class, use "Rating = Struct.new(:name, :rating)".
ActiveSupport adds a ton of useful methods to the String class that alleviate some of the pain associated with Ruby strings. (I like the way Python treats characters and string slices a bit better.) For instance, it adds .from and .to for slicing.
Use "config.active_record.schema_format = :sql" to configure Rails to dump the schema to schema.rb in SQL instead of Ruby.
Use "config.action_view.field_error_proc" to configure how Rails outputs fields when there is an error.
Friday, February 26, 2010
Ruby: Using "should not" in Cucumber
Cucumber lets you write tests like 'I should not see "such and such"'. Generally, you write the test, watch it fail, write the code, and then watch it pass.
Having used Cucumber for several months, I've been bitten by "should not" several times. It's very easy to misspell something, and the "should not" test will pass even though it shouldn't. I've even seen tests that test for "should not" even though the test should have been removed with the feature they were testing which was long gone. After all, you can write 'I should not see "practically anything"', and it'll almost always pass ;)
My experience is that it's much more robust to do something like:
Having used Cucumber for several months, I've been bitten by "should not" several times. It's very easy to misspell something, and the "should not" test will pass even though it shouldn't. I've even seen tests that test for "should not" even though the test should have been removed with the feature they were testing which was long gone. After all, you can write 'I should not see "practically anything"', and it'll almost always pass ;)
My experience is that it's much more robust to do something like:
Given ...By using "should see" and "should not see" side-by-side, your test becomes much more robust.
Then I should see "blah"
Given ...
And I reload
Then I should not see "blah"
Tuesday, February 16, 2010
Ruby and Firefox: Two "Oh My Gosh" Moments
First of all, The Ruby Toolbox is amazing! I no longer have to read a bunch of Ruby mailing lists just to know which tools are useful and which tools aren't. There's so much stuff already there that (out of ignorance) I thought I would have to build from scratch.
Second of all, did you know that hitting Cntl-Shift-t in Firefox (at least on my Linux box) opens up the last tab that you closed? That was a weird thing to stumble upon.
Second of all, did you know that hitting Cntl-Shift-t in Firefox (at least on my Linux box) opens up the last tab that you closed? That was a weird thing to stumble upon.
Friday, February 12, 2010
Ruby: Behavior Driven Development
Yes, dear? ./script/cucumber features
Using the default profile...
Loading db/seeds.rb with RAILS_ENV: test
...............................................................................
...............................................................................
...............................................................................
.......................-------...--------......................................
...............................................................................
...............................................................................
............---......----......................................................
...............................................................................
...............................................................................
...............................................................................
...............................................................................
.............................................----........-----.................
...............................................................................
...............................................................................
...............................................................................
...................................................-------.....................
.
191 scenarios (191 passed)
1308 steps (1308 passed)
1m25.563s
Yes, dear? ./script/spec spec
...............................................................................
...............................................................................
......................
Finished in 7.475893 seconds
180 examples, 0 failures
Wednesday, February 10, 2010
Python: Asynchronous Network and Web Frameworks
If you dig asynchronous network and web frameworks like Twisted, Tornado Web, Stackless, Gevent, and Concurrence, check out Nicholas PiĆ«l » Socket Benchmark of Asynchronous Servers in Python. It's one of the best blog posts I've ever seen on the subject!
Labels:
asynchronous,
concurrency,
python,
tornado web,
web
Friday, February 05, 2010
Software Engineering: The Dunning–Kruger Effect
From Wikipedia:
The Dunning–Kruger effect is a cognitive bias in which "people reach erroneous conclusions and make unfortunate choices but their incompetence robs them of the metacognitive ability to realize it". The unskilled therefore suffer from illusory superiority, rating their own ability as above average, much higher than in actuality; by contrast the highly skilled underrate their abilities, suffering from illusory inferiority. This leads to a perverse result where less competent people will rate their own ability higher than more competent people. It also explains why actual competence may weaken self-confidence because competent individuals falsely assume that others have an equivalent understanding. "Thus, the miscalibration of the incompetent stems from an error about the self, whereas the miscalibration of the highly competent stems from an error about others."
Subscribe to:
Posts (Atom)

