Vintner Jared Brandt of A Donkey and Goat winery was a technical product manager before the first dot-com crash. He and his wife spent a year in France learning biodynamic wine production methods before returning to Berkeley to found their winery. Jared discusses their approach to winemaking in this evening talk at Pivotal Labs SF.
See all our talks at http://pivotallabs.com/talks
Vintner Jared Brandt was a technical product manager before the first dot-com crash. He and his wife spent a year in France learning biodynamic wine production methods before returning to Berkeley to found their winery.
Thanks to Sean Moon and Sam Coward Cedar now has colorized output on the command line:
If you’d like to display colorized output like this you can specify the appropriate custom reporter class using the CEDAR_REPORTER_CLASS environment variable. We do this in our Rakefiles, like so:
task :specs => :build_specs do ENV["DYLD_FRAMEWORK_PATH"] = BUILD_DIR ENV["CEDAR_REPORTER_CLASS"] = "CDRColorizedReporter" system_or_exit(File.join(BUILD_DIR, SPECS_TARGET_NAME)) end
You can set the environment variable in whatever way works for you. You can also set it to any reporter class you choose, so customize away.
And of course, Happy Holidays from Pivotal Labs!
“What tools can one use to track down JS memory leaks in IE 7/8?”
Is there a way to get MySql indexing to speed up queries involving greater and less than operators on date columns?
Postgres handles these operators a little bit better than MySql, but may not actually solve this problem.
Using millis instead of dates would give the DB the best chance of handling this scenario.
We are using Git’s subtree merge facility instead of submodules to stay synced to a different repository for part of our project. How do we push changes back to that repo?
See Tim Connor’s blog post “Git sub-tree merging back to the subtree for pushing to an upstream“. Early in that post is a pointer to an article describing the the subtree merge operation. Tim goes on to explain how to push your changes back through the chain.
Some cloud environments leave the names of temp files visible even when their contents are not accessible. Be sure to use obfuscated names for your temporary files!
The “Headless” gem allows you to easily set up an alternate “display” that allows programs to execute in a headless environment. See this blog post about how to use Headless to run Selenium tests on a CI box: http://www.aentos.com/blog/easy-setup-your-cucumber-scenarios-using-headless-gem-run-selenium-your-ci-server
Ccrb will bog down to painfully slow levels if more than a couple of CC Tray clients are pinging it repeatedly during a build.
Cron will not honor your .rvmrc file unless you do some work to set up the environment. If you set up your cron job like this:
0 6 * * * /bin/bash -l -c 'echo /home/someuser/.rvm/bin/rvm rvmrc trust ... && cd ...
the -l & -c parameters cause bash to load your environment as if your were logging in before running the specified commands. Someone also mentioned that rvm-shell can be used as a solution to this problem.
If you write:
class Thing < ActiveRecord::Base
has_many :posts
end
class Post < ActiveRecord::Base
default_scope select(column_names - ['body'])
end
Thing.includes(:posts).all does the following for the posts query:
SELECT id, fk_column_id, column1, etc, posts.*
FROM posts
WHERE (pages.fk_column>in IN(1,2,3))
It takes the default select scope, but also appends posts.* to the end of it.
This is caused by the :select find_option in the find_associated_records inside of association_preload.rb. This is what it is now:
:select => preload_options[:select]
|| options[:select]
|| Arel::SqlLiteral.new("#{table_name}.*")
It seems like the third || case is not needed, since that is the default for any select and it causes the above behavior.
Joseph Palermo has filed a ticket with Lighthouse about this…
Given the recent interest and discussions around pair programming, I thought that now would be a good time to write up my experiences doing dual-computer, in-person pair programming with Mavenlink at Pivotal Labs. Pivotal Labs is all about pairing and every team here pairs full time. Our standard setup is to have two developers at each workstation, with two mice and keyboards. On Mavenlink, we recently upgraded our workstations and decided to keep the older model around to try out dual-computer pairing, which we’ve nicknamed “Extreme Pairing.”
One commonly-expressed frustration with pair programming is that of wasted time while doing especially rote programming, research, documentation reading, or printout debugging tasks. People read documentation at different speeds, or want to try different Google searches in parallel, for example. Generally, the benefits of pair programming greatly outweigh the downsides, and we pair full-time to decrease the risk of failing to pair when it would retrospectively have been of great value due to knowledge sharing or bug prevention. However, in an effort to minimize these inefficiencies, the Mavenlink team has been exploring dual-computer pairing.
What follows is not Pivotal’s standard pairing setup. Everyone on this team has years of pair-programming experience and we have each developed our own intuition for which corners can be cut and which cannot. The following is recommended for advanced pairs only — it can make experienced pairs more effective, but may be hazardous for newcomers to the pairing environment! We never “Extreme Pair” when conducting interviews and revert to a more traditional setup in that context.
Each of our two pairing desks house a beefy i7 27-inch iMac and a slightly older 24-inch iMac, each with its own mouse and keyboard, and linked bidirectionally with Teleport. We sit centered around the larger iMac and use the second computer when we have separable tasks during pairing, such as research, running tests, or looking up documentation. We still do traditional pairing 90%+ of the time and focus on never falling into the traps of soloing: email checking, distractions, siloed knowledge, and untested code. Having the second computer has allowed us to split our focus when we can do so while still both maintaining understanding and ownership of everything that is going on. This is most effective and appropriate when:
More generally, any time a task requires focus on two different places at once, we split it up and assist each other. I think of this as synchronization in multi-threaded code – we split and rejoin on separable sub tasks, while both continuing to perform traditional pair programming when viewed from the scope of a story. We never work on separate stories and tasks that last longer then a minute or so. Smoothly moving from traditional pair programming to separately googling, debugging, or CSS tweaking keeps us agile and efficient while maintaining all of the very-real benefits that we find to exist with traditional pair programming,
“How can I test route redirects in Rails 3?”
Capybara (a Webrat clone for Rails 3) will do the job but we’re looking for something a little more direct. It may be possible to test this by checking location headers and disabling automatic redirects in tools might increase visibility.