Interestings
Binding and CapybaraWebkit
If you have seemingly random undefined is not a function in your Capybara Webkit specs, checkout your binding of event handlers. The native bind doesn’t like to work in CW, so try Underscore’s instead.
If you have seemingly random undefined is not a function in your Capybara Webkit specs, checkout your binding of event handlers. The native bind doesn’t like to work in CW, so try Underscore’s instead.
A cool pattern for including Javascript in your app based around controller_name/action
http://viget.com/inspire/extending-paul-irishs-comprehensive-dom-ready-execution
At some point in v7 (possibly 7.1) Teamcity created a formatter which is much nicer to use
http://confluence.jetbrains.net/display/TCD7/Build+Script+Interaction+with+TeamCity
an example is that there is now a FlowId which lets you output from multiple processess/threads and let Teamcity deal with the demuxing.
Two weeks ago, JRuby 1.7.0 was officially released. Here are a few reasons why you might want to upgrade:
Bug fixes
JRuby 1.7.0 fixes many compatibility issues with ruby 1.9. Also, JRuby 1.6.8 is no longer being maintained so fixes from 1.7.0 are not getting backported.
Support for invokedynamic
JRuby 1.7.0 supports the invokedynamic instruction, a new feature in Java 7 which allows the compiler to use duck typing. This means dynamic languages on the JVM will be compiled to faster code.
Kernel#exec
JRuby 1.7.0’s exec function is now a true system exec that replaces the current process, while previously it spawned a new process and waited until the process exited.
I just upgraded my project from 1.6.8 to 1.7.0. It was fairly easy – I took about a day to upgrade our project.
Install jruby-1.7-0.
It’s as simple as:
$ rbenv install jruby-1.7.0
If ruby-build complains that definition not found, you’ll need to upgrade ruby-build.
Note that if you’re using ruby 1.8.7, you’ll need to install that separately since JRuby 1.7.0 by default uses ruby 1.9.3.
Drop the new version into your project .rbenv-version file.
Bundle
$ bundle
Some gems may fail to install because JRuby 1.7.0 by default doesn’t enable C extensions since they are deprecating this feature. You can turn it back on with the command line option -Xcext.enabled=true – add this to your .rbenv-vars file.
Tweak
$ rake spec
If you’re lucky, everything will pass and you can skip straight to step 4.
Otherwise, here’s a list of the changes I made to port our project over. This is by no means an exhaustive list, so please feel free to comment below.
An interesting change in JRuby 1.7.0 is that Java exceptions no longer inherit from ruby Exception. This means that they will not be caught by a standard global rescue. I.e., executing the code below will print ‘Rescued’ under 1.6.8 but will blow up under 1.7.0.
begin
java.lang.Integer.parse_int("asdf")
rescue
puts "Rescued"
end
If you’re doing a global rescue from Java code, you’ll need to change your code to specifically catch a Java exception class or explicitly rescue Exception (at your own risk).
Error: Unable to access jarfile start.jar. In our case, the fix was to change the Kernel#exec call to Kernel#system instead.Profit!
Once we finished tweaking it, our application loaded and behaved normally.
You may want to experiment with enabling invokedynamic. It’s turned off by default because some versions of the JDK 7.0 are not fully compatible. To enable it, add -Xcompile.invokedynamic=true into your .rbenv-vars file.
Unfortunately, on my project, we’re sticking with Java 6 due to our dependencies, so no invokedynamic for us – but let me know how that works out if you try it.
(DWF )
Return Object of course
Finally fixes the hamcrest dependency conflict.
Roboelctric users BEWARE: See the recent mailing list thread “Setup for non-maven” users if you are going to upgrade.
(Alexander Murmann)
(Sarah Mei)
A VMware Fusion instance originally created as a side project may grow in importance and need to be housed on a production (i.e. ESXi) server.
Rather than undertaking the painful process of re-creating an instance, it’s easier to migrate the .vmdk files to the ESXi server.
In this example, we’re migrating a Windows 7 instance (named w7_64bit_base_10-12-11_updated_IE9) to our ESXi server (server name: esxi2) (new instance name: windows7_2). First, we log into the ESXi server and create a temporary holding directory, then copy the Fusion .vmdk files over:
ssh root@esxi2
mkdir /vmfs/volumes/datastore1/windows7-tmp
exit
scp ~/Documents/Virtual Machines.localized/w7_64bit_base_10-12-11_updated_IE9.vmwarevm/*.vmdk root@esxi2:/vmfs/volumes/datastore1/windows7-tmp
ssh root@esxi2
cd /vmfs/volumes/datastore1/windows7-tmp
vmkfstools -i w7_64bit_base.vmdk -d zeroedthick windows7_2.vmdk
We’ll then need to create a new instance. For this, we use vSphere:
Now move the .vmdk file into place:
ssh root@esxi2
cd /vmfs/volumes/datastore1/windows7-tmp
mv -i windows7_2*.vmdk ../windows7_2/
exit
You should be able to boot
Clean up the old files:
ssh root@esxi2
rm -r /vmfs/volumes/datastore1/windows7-tmp
exit
You’ll need to make sure that inbound ssh is enabled on the ESXi server.
In the case of Windows, you will need to manage the licensing (e.g. re-activating).
It would be more efficient to keep one terminal session logged into the ESXi server rather than continually ssh’ing in & exiting.
John Kastler provided the crucial vmkfstools command.
While working on LicenseFinder, Matt Parker, Ian Lesperance, and David Edwards contributed a patch to rubygems.org to show gem licenses on gem pages. That patch has now been merged. https://github.com/rubygems/rubygems.org/pull/458
If you browse to a gem version page on rubygems.org, you’ll see a new “Licenses” section. At the moment, this will show “N/A” for most gems, but as people begin to push up new versions of their gems, and as more gem authors set the licenses metadata in their gemspec, you’ll start to see gem licenses.
Gem::Specification.new do |s|
#....
s.licenses = ["MIT", "BSD-3"]
#....
end
Exceptional purchased Airbrake
APIs are different, is there a clear winner?
No clear winner — errbit is an open source solution that uses the airbrake gem.
https://github.com/errbit/errbit
The only logical explanation we have for the bug with update_attributes failing silently is that we migrated without restarting. We speculate that some dynos had cached the old schema and never got the update (before restarting).
If you use the CSS text-transform: uppercase property on some content that you wish to test with have_content, then:
expected there to be content "NOV" in "NOV 8, 2012 — DEC 8, 2012"
We’re working on a feature where a user can reply to emails. We want to trust the “From:” field to identify the user, but aren’t sure how to set everything up properly.
We’re using SendGrid’s “Parse API” to receive the emails, and it tells us that we get an spf ‘permerror’ when sending from pivotallabs.com, but not from regular gmail.com or hotmail.com. What gives?
SPF only authenticates the envelope domain, so headers can’t be trusted. DKIM has the option to auth specific headers, so you may be able to trust DKIM.
https://groups.google.com/forum/?fromgroups=&pli=1#!topic/ruby-capybara/C0O7nP2YG1A
An easel. A marker. Sometimes the most effective and immediate way to capture thoughts and collaborate is also the most tactile, visual, and simple. But easels and markers have their limitations: information is difficult to digitally preserve, and they don’t scale to large teams. In 2005, agile software development and consulting company Pivotal Labs faced this very design and collaboration challenge in its client development projects, and began building a software tool that could match the wide-frame scope and immediacy of tracking a project’s progress using markers and an easel. “We were trying every week to come up with very concrete, fine-grained, real verifiable things to build, that made sense to a customer who was in a room and made a very incremental, but concrete step forward for the project,” explains Dan Podsedly, VP and General Manager, Pivotal Tracker at Pivotal Labs. “Week after week, we wrote those lists of stories on a big huge piece of easel paper stuck to the wall, and developers would cross off those stories as we got to them, and the product owner would check things off that were verified. It was very tactile and visible, and created a lot of energy and focus — everyone knew what we were working on, what we had done, and had a sense whether we were making progress or not. But we didn’t have any software tools that allowed us to capture the same sort of lightweight, visible qualities.”
The team built Pivotal Tracker, a collaboration tool designed from the ground-up to serve the needs of its agile development teams and clients. “We were simply trying to capture that simplicity — the radiation of information of a big, colorful list stuck on the wall in a place that everyone could see it,” says Podsedly. “We wanted to capture that sense of visibility — where you could always see, out of the corner of your eye, the big picture of where you were at in the project on that day.” Within two weeks the company was already using Tracker to collaborate on client projects. It wasn’t only Pivotal’s internal development teams that quickly saw Tracker’s value. Before long, the company found itself inundated with requests from clients that wanted to continue using it after their development projects wrapped up. “It was a side project,” says Podsedly, “but it started to get really popular with clients who wanted to continue to use it after our project with them was complete.” Due to the demand, Pivotal Labs announced a public-facing version of Tracker in 2008. Adoption soared, and by 2011, “it was clear that we had to turn it into a product because otherwise there would be no way to keep building and supporting it when there were thousands of companies that relied on it,” Podsedly explains.
Pivotal Tracker is more than a project management tool: it reflects the nimble approach to software development Pivotal Labs is known for. It’s not merely a way for teams to communicate about their progress, but instead a real-time monitor of the project’s health, at both a micro and macro scale. “It becomes like an EKG,” says Drew McManus, VP of Product at the company. “A doctor can walk into a hospital room, glance at a monitor, and get an immediate impression of how a patient is doing and an understanding of where they need to focus attention,” he says. “For product managers, Tracker’s the same. It’s a reflection of the health of the project.” A core component of Pivotal’s methodology is in its stories, the many minute tasks that comprise the entirety of a development project. Each story represents an incremental piece of the much bigger puzzle. Working on projects at such an atomic level can be imposing to some product managers at first, but the benefits of the approach are quickly revealed, explains McManus. “Product managers who haven’t worked this way are used to going to teams and saying something like, ‘okay, we need a store with a shopping cart,’” he says. “Using stories in Tracker forces a level of specificity and granularity that ensures that you’re not going beyond the absolute requirements. In Tracker, ‘I need a store with a shopping cart’ might translate into 50 stories that say things like, ‘as a shopper, when I click on an add to cart button, the number of items in my cart goes up and the number of items in the inventory goes down.’ That’s a very specific thing that the developer can implement, and knows when it’s done.” “It’s a very discrete chunk of work,” he says, “so you don’t end up with people running off and building a bunch of stuff you didn’t ask for, instead you end up with a pretty accurate estimate, because estimating ‘when I click a button it does this’ is easier than building a store with a shopping cart.” This process yields dividends over the life of a project, McManus explains, enabling “a kind of transparency that leads to better accuracy, better estimation, and fewer misunderstandings.”
Tracker isn’t simply geared toward achieving laser-like focus on a specific tasks. What makes the tool uniquely effective is that it enables such focus, while still reflecting the progress of a project at the macro scale. “What we try to do with Tracker is make it possible to work within the detail, without losing sight of everything that’s around it,” says Podsedly. “Everything is inline and on one page, offering a radiation of multi-layered information that you can see without ever leaving that page.” This key aspect of Tracker’s designs hearkens back to the product’s inspiration. “Much like when you’re in a room and have lists on the wall,” he says, “you always see an overall view of the project, no matter what you’re doing. You never ever lose visibility of what’s going on.” Tracker reflects a philosophy to product development that emphasizes rapid iteration, flexibility, ongoing communication, and the collaborative methodologies of pair programming. “We often refer to Tracker as a repository for starting points for conversation,” says McManus. By breaking projects down into discrete stories, and enabling team members to work within the detail while communicating in real-time, Tracker reduces the risk of miscommunication, misallocated resources, and scope creep. “You get away from projects where the team has been working furiously on something that probably isn’t necessary, or putting a lot of time into building architecture for a feature that may not be the most important,” McManus says. “By having Tracker as the single plan or record, it makes it absolutely clear what should be done and what shouldn’t be done.”
Breaking large projects into discrete stories provides real-time metrics of a project’s ongoing health at various levels of granularity. It also equips teams and product managers with the power of prediction. Tracker allows users to track the pace and patterns of productivity in the aggregate, over a period of time. This velocity allows teams to identify issues of process, and get a reasonably accurate estimate of how much a new or changed feature will add to the project’s lifecycle. “When you’re working on a project every day, you encounter opportunities to increase scope,” says Podsedly. “Somebody wants to add a new feature, the boss wants to do something he read about in a magazine. With Tracker, you say, ‘let’s write a story for that, let’s put it in the backlog and estimate it,’ and you can see immediately the milestones moving down according to dates.” Teams and managers can make informed decisions on how a new feature will affect the overall timetable of the project. Podsedly explains this “turns the conversation from ‘us versus them’ to a question of, ‘how do we, together, get that line to move back up?’ And generally, that’s in the form of de-prioritizing something else. Tracker makes that so easy that these conversations actually happen and they shift to being a constructive approach to managing scope on an ongoing basis.” With its ability to project future velocity, Tracker enables teams to make informed decisions and quickly shift priorities.. “The most accurate assessment of how much work you’ll get done is how you’ve done recently,” says Podsedly. “Tracker allows you to look forward and see how much you will do in coming weeks.” It also allows teams to reflect on their workflow and change strategies. “You want to see a nice, smooth velocity chart, because that means that you’re performing consistently,” McManus says. “If your velocity swings up and down from week to week, that’s another important thing to bring up with your team and ask, ‘are we estimating things properly? Was there some misunderstanding of these features that ended up taking much longer or less time than we thought?’” Despite its predictive power and ability to drill into the detail, Tracker still honors the simplicity and visibility of the low-tech collaboration tools that inspired it. Rather than replacing conversation, Tracker creates new opportunities for collaboration and communication. At a fundamental level, Tracker reveals an incredibly simple yet powerful principle. “Tracker allows you to plan,” says Podsedly, “and drives open, honest communication among teams.”
New with Rspec 2.12, rspec mocks now have the ability to call through to the original implementation.
example:
banana.should_receive(:split).and_call_original
asserts that banana.split was called, and also executes banana.split
See http://yehudakatz.com/2010/12/16/clarifying-the-roles-of-the-gemspec-and-gemfile/
tl;dr
ACCORDING TO YEHUDA … if you are maintaining a GEM
git rm –cached Gemfile.lock
echo “Gemfile.lock” >> .gitignore
git add .gitignore
git ci -m “Remove Gemfile.lock — cf. http://yehudakatz.com/2010/12/16/clarifying-the-roles-of-the-gemspec-and-gem”
(this advice may be controversial)
http://aws.typepad.com/aws/2010/10/keeping-customers-happy-another-new-elastic-load-balancer-feature.html