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?
https://github.com/jisaacks/GitGutter
Bonus: there’s a vim version! https://github.com/tpope/vim-fugitive
Twitter have release a js plugin for typeaheads:
http://twitter.github.com/bootstrap/javascript.html#typeahead
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:
visit ('/articles/#(article.slug}')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..
(Davis Frank)
(Andrew Bruce)
Host wanted for tonight’s Extreme Tuesday. Acquire within. Talk to Gavin, Andrew, Edgar, or anyone else involved.
Volatility is what Pivotal Tracker uses to measure the consistency of your team’s work output. You can use that number to help you estimate the first approximation to answer the eternal question, “Will I make the deadline?”
You’ve scoped out 100 points worth of stories for the Next Big Release™. Pivotal Tracker shows your velocity is 10 points per week. Your annual review is in 3 months and on-time delivery of this high profile project will figure prominently.
Then the CEO walks over to your desk and asks, “Will I make the launch date, 10 weeks from now?”
What do you say?
Hopefully, you answered with “none of the above.” Velocity is just one measure of how your project is performing. Staking your career on it would be foolhardy. The second answer is honest, yet hopelessly vague. The third reply is why many people still think Agile is a way to duck your responsibilities as a software professional. There is hope, however; We can use Pivotal Tracker’s tools to make a better (albeit imperfect) estimate.
Velocity, week over week, varies; sometimes a lot, sometimes a little. It depends on the project. Ideally, each iteration would have the same mix of stories, bugs and chores and Velocity would be very consistent. Steady velocity is a good thing™. In the real world, however, all sorts of things crop up; Your head-count goes up (or down), business priorities shift (or pivot), deferred technical debt demands payment, quality assurance files a slew of bug reports, user testing reveals flaws in product, visual design changes. The real world creates volatility in your Velocity.
A simple measure of this is standard deviation, which Tracker constantly computes for your project. Using that metric, you can decide what you should watch or change in order to meet your goals. Let’s go back to our example and look at the velocity charts in Tracker.
Assuming that we have a normal distribution of weekly velocities, the first sigma (±35%) will fall into the range of 10±3.5 points each week. That is, there is a 70% probability that your project will deliver all 100 points somewhere between 8 and 16 weeks. Why so much spread? 40% volatility is a big number! In the worst case scenario, where every iteration delivers only 6.5 points, it gets you to your goal in 100 ÷ 6.5 ≅ 16 weeks.
By now, you’ve had your meeting with the CEO. You’ve shown him the stories left in the backlog, the volatility of the project, and the range of estimates for delivery. This is the beginning of a conversation. If you’re team is not comfortable with the worst case scenario, something must change and, really, you have only two choices; you can reduce volatility or you can reduce scope. You will probably need to do both. Alas, there is no simple formula here. This is where skill, experience and insight will come into play. Here are some suggestions:
This article should give you a lot to think about. Good project management is hard work. When projects are just getting started, everything feels fine, and later you start to wonder when everything went to hell. Remember, volatility kills.
Rails link remote.
Get HTML into the Dom? Without the callback? (no id)
This Friday celebrating start ups in SF w/food trucks at lunch time.
Come meet Engine Advocacy – startups' voice in government.
Bring your friends, enjoy great food, and learn about becoming
an Engine member.
Engine's Startup Block Party
February 15, 2013
11:00 am – 2:00 pm
Bluxome St., between 4th and 5th
We want to use PostGIS 2.0 but Heroku's docs on the matter say it's in beta and "subject to change". Has anybody used it in production? Does anybody know of a production-quality alternative?
The ci_reporter gem suppresses stdout and stderr by default, so you won't see puts results in Jenkins' console output.
Setting your environment variable CI_CAPTURE to the string "off" will stop suppressing the output.
In addition to the regular Tuesday event. Same time, 6:15 – 9:00.
This Friday celebrating start ups in SF w/food trucks at lunch time.
Come meet Engine Advocacy – startups' voice in government.
Bring your friends, enjoy great food, and learn about becoming
an Engine member.
Engine's Startup Block Party
February 15, 2013
11:00 am – 2:00 pm
Bluxome St., between 4th and 5th