Kevin Kelly, Founding Executive Editor of Wired Magazine and noted technologist will be at Pivotal Labs tomorrow (Thursday January 13th, 2011) at 6:30pm to talk about his latest book What Technology Wants.
For details look here.
“Does Active Record have batched insert? I need to dump 10,000 rows into the database in process and I don’t want it to take 45 seconds.”
The upshot: use a raw SQL INSERT statement.
For a day as interesting as today (1/11/11 anyone?) there were surprisingly few interesting things of note.
A pivot asks: “Anyone know anything about data warehousing & ETL?”
A handful of pivots raise their hands.
Another pivot asks: “How about Radiant CMS?”
More pivots raise their hands.
Should a before(:all) in Rspec raise an exception the return code coming back is 0. This breaks CI.
Rspec supports before(:suite) — this runs, just once, before all other befores.
In MongoMapper if you have a key (field) with type Hash, and set a default value, that default value points to a reference instantiated at class loading time. Instances inherit a reference to the same object (instead of a copy) which means any changes to to an instance with the default value propagate to all future instances using default. The immediate work-around is to wrap the value in a lambda, but within hours of reporting the bug there was a fix on HEAD.
splunk users meetup here (at Pivotal Labs in SF) on Wednesday January 12th. More details on meetup.com.
A global Rspec before(:each) defined in spec_helper.rb apparently does not have access to fixtures. One admittedly klunky workaround involves config.include a Module, and then a class_eval inside the included hook of the module. This has the unfortunate property that the before(:each) will run multiple times, once at every test level, instead of just once at the top level — though this can be fixed by looking at the length of ancestors in the included hook in the module and only doing the before(:each) if you are on the first level. Others argued that fixtures should be available in a before(:each) and that the problem is a load-order issue.
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.