- If your HTTP header’s
HTTP_CLIENT_IP is not equal to
HTTP_X_FORWARDED_IP, then rails 2.1 and above will consider it an IP spoofing attack and throw an exception! This is bad news for some traditional Apache->Mongrel setups. Solution is probably to change the apache HTTP headers, but we’re wondering exactly why this is a security problem for rails (and why they would break compatibility with the default apache setup from way back when)?
- Be careful when using
:case_sensitive => true AND a unique index at the database level. If your database is case insenitive, then rails will approve the uniqueness, but the database will fail the insert. Solution: be sure to use a collation type for the unique column that is case sensitive (such as binary in mysql).
- Rails 2.1+
:includes are way better than pre-2.1, but they are less compatible with conditions. Hence, rails falls back on the old style. Here’s when it might legitimately fall back:
User.find(:all, :include => :profile, :conditions => "profiles.gender = 'M'")
Because we reference the included table
profiles in the
:conditions, rails has no choice but to construct one giant query to fetch Users and their profiles, rather than a separate query. Here’s a case when it guesses wrong:
User.find(:all, :include => :profile,
:joins => "INNER JOIN comments ON comments.user_id = users.id",
:conditions => "comments.approved = 1")
Because the conditions references a table that is not
users, rails thinks it has to fall back to the old include style… but it’s wrong! Here’s how we tricked ActiveRecord into always using rails 2.1+ includes (note that we had to fix up a few queries that were referencing :inlcuded tables in :conditions to make this work):
One client decided that Web 2.0-style rounded corners are only needed in Firefox and Webkit-based browsers because they are “free” with CSS properties built in for those rendering engines:
-webkit-border-radius. Internet Explorer is going to be left in the 1.0 world, at least for now, due to the over head of managing rounded corners.
Feel free to promote your personal favorite rounded corner techniques in the comments.
Ask for Help
“We need to hide a flash widget without setting it to
display:none, which causes it to be loaded from the server again when
display:none is removed.”
Hit me with your div-hiding techniques!
- Move it off the screen with
- Shrink it down to nothing with
visibility:hidden;height:0;width:0 but watch out for any IE 6 minimum height/width issues
- Similar to the above, hide it with
Kent Beck gave a great ‘story-driven’ talk at RailsConf 2008 regarding Patterns, Test Driven Development, and XP/Agile/Responsible development. Go see it now at Blip.tv along with all the other big presentations from RailsConf.
Yeah, yeah. This was posted ages ago, but I just made it around to watching it tonight.
Two great quotes. First, re: TDD
Testing really isn’t the point. The point here is about responsibility. When you say it’s done, is it done. Can you go to sleep at night, do you know that the software you finished today . . . works. And will help. And isn’t going to take anything away from people.
Second, more generally about ideas:
Smart ideas are useless. Nobody else is going to be dumb enough not to try them – or rather, Everybody’s going to try them if it’s a smart idea. Ideas with punch are the ones that are really ridiculous…until you try them.
Like Mole. Mole sauce. Chocolate? Chicken? Phbbblblltt! HahahaHA!
- As suggested in 09/03, one project switched to using Solr for search indexing. We were warned that wide range queries might be slow (looking for a value between 1… 10000) could be very slow, but it is not, at least with 400K indexed documents. We’ll watch out for slowdowns as the number of indexes increases.
Ask for Help
“JSUnit tests do not show line numbers for assertion failures, which makes it hard to know which assertion failed. Suggestions?”
Have fewer assertions per test, or use the message argument, such as
assertEquals(foo, bar, 'foo should be the same as bar.').
“Is there any way to see test failure stack traces as soon as a test fails or errors? This would be especially nice for slow-running Selenium tests.”
A few Pivots remember hacking on
Test::Unit and Rspec to display failure details immediately, but more research is needed. Perhaps there’s a plugin?
“Design Adam’s beard!”
Pivot Adam is shaving is beard and is looking for facial hair suggestions. Over the years he has displayed many of the “standard” beards and mustaches, so it’s time to get creative. Look to The Quest For Every Beard Type for inspiration. Here is your canvas:
Ask for Help
“Is there something wrong with Net::SSH in the latest versions of Capistrano? I can’t deploy to localhost…”
Not that anyone knows of. Have you tried turning it off and on again? The power button… it’s the little glowing button on the front… the button on the front… Are you from the PAST?
“Is there a good ruby Gem or Plugin for working with the Google Charts API?”
One pair used gchartrb but abandoned it almost immediately. So far, it’s string << string << string.
Unfortunately not. Desert plugins should have an
I posted a few weeks ago gathering small tips from you regarding how you get and/or stay more Agile.
The goal is a list of short, pithy, sticky aphorisms to help both newbies get Agile and us stay that way. Think Agile Andy’s Almanack (or something).
I’ve thrown everything I got (a lot in person & email) together and categorized a bit. Please comment, add, delete, etc. As I said, I’m working on a presentation around this data and welcome your feedback.
Stick to Conventions
- Follow the local ground rules (indenting, naming, structure, etc.)
- Always take the next story (don’t let ‘fun’ or ‘hard’ get in the way of business priority)
Use the right tools
- Keep your hand on the manual (Keep browser tabs open for your language & API doc sites)
- Make mini actionable task lists for your story (Get inspired by GTD)
- Index cards are mini whiteboards
- Hardware, hardware, hardware (Big and/or dual monitors, 2 keyboards & 2 mice is better than 1 & 1)
Pair Programming Works
- Expect to Pair
- Pair appropriately
- When you’re not sure how to implement a story, pair with someone more senior
- When a task feels obvious, pair with someone more junior or new to the project
- Let the rookie type, give the wookie a toy (so he doesn’t)
- Rotate your pairs as often as practical
- 2 pairs are better than 1 on a project
- Always pair interview
Take a test drive
- Writers’ block? BEWS (Blank Editor Window Syndrome)? Write a test
- Find some untested code? Write a test.
- Find something you don’t understand? Write a test.
- Keep your tests as fast as is practical, or you’ll wait for CI to run them
- Write enough tests so that you can sleep at night
- Do the simplest thing that could possibly work – no architecture astronauts
- Check-in multiple times before a story is done (try for every hour or so)
- Kill dead code, commented out code, or write tests to cover it
- Make it green, then make it clean
- Tackle code debt with extreme prejudice
- Leave the code cleaner than when you got there (think o2 canisters on Everest)
- Every failing test is sacred
- Red builds are project cancer – fix first, figure out why, then blame (when appropriate)
Stay in sync
- Don’t stop talking – to your pair, your team or your customer
- Go to lunch together
Bruno Miranda posted a review of various agile project management tools including Mingle, VersionOne, TargetProcess, and Tracker. Check it out here.
We’ve let Bruno know that Tracker is actually under active development. One of the first new features that we’ll be rolling out soon is a REST API, followed by various usability improvements that will make it easier to work with larger projects.
We’re also looking for more suggestions on how to make Tracker better, especially in the area of higher level planning. Send your ideas to email@example.com, or post them on Satisfaction.
And if you haven’t tried it yet, the Tracker beta is fully open to the public, feel free to sign up.