Mocking XHRs in Capybara
How do you mock AJAX requests in Capybara tests?
How do you mock AJAX requests in Capybara tests?
We created a new migration that added a non-string column. After pushing to heroku and running the migration, the column shows up as string.
Ensures that a given process is only running once. Keeps scheduled tasks from overlapping. Uses lock PID files. https://github.com/rjackson/singleton_process
The list of security monitoring services continues to grow. In addition to the holepicker gem and the private beta code climate service, Gemnasium is now offering "Security on Steroids."
Software development has been revolutionized by Agile development practices, but designers struggle to adapt to the very same techniques—despite suffering many of the same challenges that led to Agile. What exactly are these problems? And how can Agilists and designers address them?
Agile development preaches “Done means Done”. When a story is accepted by the Product Owner, it’s ready to be deployed out into the world. What does “done” mean for design? Automated testing guarantees that on every story, developers will enjoy Acceptance Criteria: a concrete measure of what counts as “done”. Designers, on the other hand, rely on subjective criteria to determine when they’re done. In the best case, this means the product team—or often, the designer working alone—if only they had a partner to pair with! In the worst case this is purely subjective sign-off from the client. While agile developers have access to tools like velocity to plan their work, designers have structural difficulties in estimation, and are consequently less able to plan. Consequently, questions like “when will that feature be done?” are more easily answered by a developer than a designer. That’s not because designers are less responsible than developers. It’s because it’s harder to know when you’re done with design—but that’s of little comfort to anyone who needs to budget time and resources to manage the project. Because Acceptance Criteria—or an answer to the question “what does ‘done’ mean?”—for design is in different units of work than “done” for development, there’s an impedance mismatch in coordinating between the two. Breaking design into units of work with more discrete Acceptance Criteria helps coordinate design work with development work.
Agile Developers ultimately deliver user-facing code, but designers output thinking: solutions to design problems, traditionally expressed via mock-ups or assets. How should the two interact? Should design stay an iteration ahead of development? What does it mean when a developer discovers an interaction problem in a design they’re implementing? Should they stop work? Developers are the tip of the spear when it comes to experience design: in the process of building software, they’re often the first people ever to use it. Sometimes this means they uncover interactions on UX problems that the designers didn’t anticipate. If the necessary design changes cascade into other work, what should the designer do: stop work and refactor (and fall behind), or come back to it later?
Furthermore, it can be difficult to determine how much design is required for developers to complete their work. The best design deliverable is the Simplest Thing That Can Possibly Communicate the Design Solution, and this can vary from team to team and design problem to design problem. Under ideal circumstances, an experienced designer may be able to reasonably estimate how long it will take to 1) solve the design problem, 2) communicate the solution, and 3) iterate on the problem / solution once it’s usable and testable as working software. But. BUT! That’s asking a lot. And it absolutely shreds the question “how far ahead should design stay of development?”.
Let’s take stock: we’ve got gallant developers, accurately estimating stories and delivering working software, and the goofus designers, unable to tell you what they’re doing or when they’ll be done. Knowing “how much design is enough?” is hard. Knowing how much design to start with is hard. Reared in a culture that prizes individuality, that venerates Rock Star Designers, that applauds Working On It Til Its Done, that publicly shreds less-than-perfect work in Crit as a rite of passage, that (with the occasional exception) is alien to the notion of sustainable development—it shouldn’t be surprising that designers are uncomfortable. That starts to lead to discord on the team: designers hating agile; feeling rushed, feeling like they don’t get the benefit of iterative design; feeling that once they touch something, they don’t get to go back and refactor it. Let’s throw in a bit of rah-rah agile ideology, a few jargon-y IPMs and retros, promises that “we’ll come back and refactor that later”, and the creeping suspicion that this whole Agile thing is nothing but smoke, mirrors, and Kool-Ade. Is it any wonder that designers can be hostile to agile?
What can we do? Looking to the example that Agile Development sets, we can see several concepts that may help: Acceptance Criteria-delimited design stories. Meaningful estimation of work for design. A culture that values Sustainable Pace. Translating these ideas from development to design may do more than just help designers work more comfortably in Agile environments—it may help us practice better design.
The Lobot project is recruiting team members. Mostly that means that when scheduling permits, you’ll work on Lobot as a project. Contact Ken (the new PM), or Davis.
I have a module that creates methods dynamically, but I want Command-B to work for those methods.
before_save and after_save will happily take an on: :create option, and then completely ignore it. before_validation takes an on: :create option, and actually works, which is why it feels natural to put on: :create after a before or after save.
The right answer, apparently, is to use before_create or after_create.
We recently added the resque-pool gem which does alias_method on the resque worker shutdown? method to look at the pid of the process being shutdown. On Heroku this always evaluates to true.
Takeaway message don’t add resque-pool gem to your gemfile for an heroku application.
Weekly email of curated links from hacker news. Recommended by Rajan.
Ruby Science: https://learn.thoughtbot.com/products/13-ruby-science
Has anyone tried/prefer any particular iOS analytics tools? We’re looking at Google Analytics, Flurry, and Mixpanel. Per-user drill downs would be nice and all features we need are supported by all three (custom events with extra data and session tracking).
We’ve got a resque worker on Heroku that dies instantly without any error. When we created one in a rails console it looked as though it was receiving a shutdown signal.
Do us all a solid and remove those ghost devices from your bluetooth settings pane. This will make it easier for others to pair them up with a new workstation.
Do you use Sublime Text? Would you like to see a git line change indicator alongside your files?
Bonus: there’s a vim version! https://github.com/tpope/vim-fugitive
Twitter have release a js plugin for typeaheads:
Come take part in the the special new extended Pair Exchange event on Saturday from 12:30 – 5:30.
Lately I’ve been thinking about the risks associated with:
I’ve identified the key areas of risk as narrative and permalinks.
The narrative of your site/app can break in subtle and unexpected ways. It is difficult to guard against side-effects upon the narrative. This makes changes to domain terms high-risk. Specifically, a developer focused on the code can easily miss these side effects.
Here’s an obvious, and well guarded story:
Given I am a user When I visit the user's profile Then I see their latest activity
That one’s simple, if you move the latest activity to a sub-nav, this story will break (that’s a good thing). In this case, you could ask the product owner, “In the past, having a user’s activity visible on their profile page was desirable. Are you sure you want to lose that?”.
However not all narrative is this cut and dry. Consider this story:
As a user When I visit a member's profile I can see a list of pages the member is interested in.
Then, along comes a new unit of work, “Rename all pages to interests”. This seems reasonable, and so you finish the story. The test for the ‘pages’ the member is interested in continues to work, however the member profile ought to lose any reference to ‘pages’. The new domain term ‘interests’ should be used instead.
Now your tests are using misleading or confusing language. You need to update all your stories to use the new term. This can get onerous quickly, but it’s vital for consistency.
I’m yet to find a satisfying technique for mitigating this risk. It’s hard enough keeping the modelling clear of inconsistencies.
This same change to narrative also affects ‘curators’ of ‘pages’. They no longer curate ‘pages’, they now provide ‘interests’. Do we want the curators to go through this mental hurdle, or the strangeness of ‘managing an interest’ versus ‘my interests’? Suddenly a curator has a list of ‘interests which they maintain’ and a list of things they are ‘interested in’.
The best way to mitigate the ‘broken narrative’ risk is to stay strong on short, testable stories. Fast turnaround between development and acceptance is also valuable. The fast feedback cycle is less overwhelming for both developer and product. The chance to think about risks is stronger when the story is as uncomplicated as possible.
The risk of broken narrative is just another reason to avoid this internal desire to take ‘big bites’.
Permalinks and long lasting links, are any URLs for which permanence matters. E.g., the permalink to an article on your blog from some outside source. The risk of broken permalinks can be readily mitigated in your intrgration tests. To achieve this, you need to make sure that product is thinking actively about permalinking. Impart to the product owner that permalinks must be (as much as is possible) explicitly called out in stories.
Here is an example.
A story in your backlog calls for content that must be available in a permalink. You write a scenario like this:
Given I am a visitor And there is an article When I click on a permalink for the article Then I should see the article
The important term in this story is ‘permalink’ – whenever a step definition calls for a permalink, it needs to use a constructed link:
Do not use Rail’s (or your framework of choice) magic:
visit(article_url(article)) # won't capture intent
This way, if the permalink goes away, the test fails, and the intent is clearly captured.
To complicate matters, a moderately complex site usually has a swathe of references to the content you are about to move/refactor. The term is often used in abundance, E.g. ‘Post’ or ‘Job’ or ‘Activity’. The page might be accessed from several places, E.g. messages are available from the ‘User -> Messages’ nav item, the ‘”My Favorite Lolcats” group messages’ page etc..
Host wanted for tonight’s Extreme Tuesday. Acquire within. Talk to Gavin, Andrew, Edgar, or anyone else involved.