Workarounds needed until bug is fixed.
http://arstechnica.com/apple/2012/09/developers-claim-safari-in-ios-6-breaks-web-apps-with-aggressive-caching/
We just made this pull request to Timecop:
“Add Timecop#lens where time can go FASTER”
Create a new mock_type, :lens which will let time continue, like :travel, but the first argument is a scaling factor which will make time move at an accelerated pace.
https://github.com/jtrupiano/timecop/pull/42
Joe Moore and I are using FactoryGirl and Paperclip for file attachments. The factory for building our Attachment model looked like this:
factory :attachment do
supporting_documentation { fixture_file_upload('test.pdf', 'application/pdf') }
# ...
end
Yesterday our test suite began raising the following error:
Failure/Error: let(:attachment) { FactoryGirl.create(:attachment) }
Errno::EMFILE:
Too many open files - /var/folders/3q/_15370v96jlbnxsk3whsks5c0000gn/T/test20120920-4004-7c2o9y.pdf
It turns out that Rails’ fixture_file_upload method does not close the temporary file it creates. We found a suggestion to prevent leaking file handles by adding an after_create block that manually closes the file. We tested this fix by looping through the model spec 1000 times. More tests passed, but it eventually blew up with the same error.
Using fixture_file_upload needlessly exercises Paperclip’s file uploading functionality instead of just creating the models we care about for our application. Instead, explicitly set the attributes Paperclip needs:
factory :attachment do
supporting_documentation_file_name { 'test.pdf' }
supporting_documentation_content_type { 'application/pdf' }
supporting_documentation_file_size { 1024 }
# ...
end
…and all of our tests passed.
Conclusion: in model factories, set the Paperclip attributes directly and don’t use fixture_file_upload.
Our application is using Font-Awesome to display some of our icons. One of our modals that has its content loaded via Ajax is rendered in IE8 without any of these icons visible. Clicking any element that contains these icons will make them instantly appear.
Is there a known issue with IE8 not properly applying CSS :before rules to content fetched with Ajax? Or could it be a known issue with how it handles fonts? Any ideas?
http://www.eventbrite.com/event/4213815636/efbnen
If you are using ActiveAdmin, beware that the after_save callback gets fired both when the model gets saved, and when there are validation errors on the model.
It really behaves like a callback after the model save method gets called, regardless of its return value.
Let’s say you’re writing a RailsAdmin custom action, and you want to test it with a request spec.
If the test passes when guard is on, but fails when guard is off, then you’ve forgotten that the RailsAdmin initializer does not run when loading a rake task. It does run as part of bundle exec guard start.
This is a performance ‘optimization’ that RailsAdmin adds.
To turn it back on, so you can test custom actions:
task :default => [:load_rails_admin_initializer]
task :load_rails_admin_initializer do
ENV['SKIP_RAILS_ADMIN_INITIALIZER'] = ‘false’
end
Arrrgggggg me mateys! To your pairs you scabrous dogs!
On the project I’m currently working on we have a main portal that provides a user registration system and a generic billing mechanism. It also has several sub applications which need to know some information about the user and be able to publish billing events. With a fairly easy to articulate boundary, we thought it might make sense to be deliberate in how we organized our code – we came up with three main solutions:
Our Boulder office had been making some noise about Rails Mountable Engines for some time, gave a presentation in the SF office, and I had experience working with engines both in the dark times of engines in Rails 2.x and the markedly improved days of Rails 3.x, and even better still in 3.1+. We had need to scale one sub-component of one of the applications independently, but not entire apps as the primary usage of the system would be low-volume. We set off down the engines path…
It worked pretty well. Two months in to the project we had a retrospective specifically about how engines were working. We agreed that we had felt some pain, but overall they drove out interesting decoupling and that the cost to pull them out could potentially outweigh the little pain we might encounter in the future.
Then our team size doubled. We had multiple epics that had high priority and deadlines associated with them. We also needed to ramp up four new people which led me to reassess our choice of engines once again, not to mention that we eventually will be handing over the code to developers who haven’t seen much Rails.
The conclusion I came to was that engines had to go. Here’s the list of why:
None of this was impossible, or even difficult to solve. It’s just that it wasn’t intuitive, not what a well seasoned Rails developer was expecting out of the box. It would have been a waste of our client’s time to bring a whole new team up to speed on all that we had learned about engines, rather than having one big application.
This is especially true since the only semi-real-payoff was that it made us isolate our sub-application code from the portal code. I say “semi-real” because the boundary was artificial – the reality was that the sub applications needed to know about the user and his account, and anything we built out for billing was really a dependency of each of the apps. This was different from a great engine like rails_admin that really is a drop in and has no domain-specific dependencies. Here we had nothing but domain-specific dependencies and now, by removing engines, our code and our domain are back where they belong: together.
UPDATE *
Engines really are great and there’s lots of situations where they can be really powerful. Boulder Pivot, Stephan Hagemann, had these additional tips that I wanted to share with you.
Regarding RubyMine and running specs: there is a simple way to make RubyMine run all specs in all engines. It will make all engines modules with their own “RubMine root”, which fixes spec runs. http://pivotallabs.com/users/shagemann/blog/articles/2008-intellij-modules-in-rubymine-
Regarding migration duplication: You can have an engine or app that requires others run their migrations. Check out the migrations run by the main app in this sample app: https://github.com/shageman/the_next_big_thing
Regarding testing: If an engine is relying on some layout or style to be around, it should depend on it and include it (potentially by way of another engine).
I worked with Ian Lesperance and Paul Meskers this week preparing LicenseFinder for its 1.0.0 release. In addition to performing some much needed refactoring on the codebase, we also added the following new features:
license_finder, though we still offer an equivalent rake task (rake license_finder) if you want to use it for a CI build)While developing the integration test suite, we had the need to shell out and run bundle outside the context of the license finder bundle. It turns out that in order to do this, you have to wrap your system calls inside a block passed to Bundler.with_clean_env:
Bundler.with_clean_env do
`cd somewhere && bundle`
end
If you ever find yourself bootstrapping applications from a ruby script that you need to bundle, keep this little-documented bundler feature in mind.
At Pivotal Labs, one of the services we provide our clients is helping them interview and hire. Pivotal Labs and our clients place a strong emphasis on Agile development and its many aspects: Pair Programming, Test-Driven Development, rapid iterations, and frequent refactoring.
Below is the job description for a DevOps engineer with Case Commons. Case Commons’ mission is to transform public sector human services through user-centered design & technology. They’re pursuing this vision through the development of Casebook – the first collaborative, family-centered case management system for child welfare, enabling workers serving the most vulnerable families and children to be more effective and efficient via new web-based software tools.
Case Commons is hiring – here’s why you want to work there:
DevOps Engineer at Case Commons
We want to help kids who are at risk. We also want to help the people who are trying to help those kids. We accomplish these goals through web-based, user-centered software via our product, Casebook.
This is not your average informational or e-commerce Ruby on Rails application. It is a distinctive application with deep workflows, intricate modeling and statistical analysis. We’re as Agile as they come. Our platform is written utilizing 100% Open Source frameworks and tools.
To be considered, please click here.
www.casecommons.org
Keyboard commands are essential to using Adobe applications like Illustrator or Photoshop. Unfortunately, some of the most important, cross-application commands occasionally break —the ones that are the most ingrained, because they work the same way in Photoshop, Illustrator, and other apps. I’m looking at you, hold-the-space-bar-to-get-the-Hand-tool, and you command-and-space-to-Zoom-in, and yes you, command-option-space-to-Zoom-Out. They break randomly, with no explanation and no warning, and it’s as if someone pried the ‘e’ key off your typewriter: sure, you can write a novel), but it’s pretty inconvenient.
Every time these keyboard commands break I curse for a bit and then google around to try to find the solution. Support boards show similar complaints, but no definitive solutions. Wishful, cargo-culty suggestions abound including “reset your preferences”, “restart”, “quit Chrome”, “no—quite FireFox!”, some of which work occasionally, but none of which work for everyone.
It’s not the app that’s broken; it’s the document. Try creating a new document. (You may need to restart Illustrator or your whole machine).
I believe the keybindings break because the .ai file is corrupted. When I noticed that keyboard shortcuts were working on one file but not another, I junked the broken file (try reverting from a backup or copy-and-pasting your work into a new file) and was able to use my keyboard shortcuts again. I’m not sure how the file gets corrupted, but this is a start.
http://www.meetup.com/NYC-PyLadies/
A group for Python ladies of all levels of programming experience, in the NYC metro area.
Pyladies is an international mentorship group with a focus on helping more women become active participants and leaders in the Python open-source community. Our mission is to promote, educate and advance a diverse Python community through outreach, education, conferences, events and social gatherings.
PyLadies also aims to provide a friendly support network for women and a bridge to the larger Python world. Anyone with an interest in Python is encouraged to participate!