In Rails, User.find_by_name(“myName”) will run sql like “SELECT users.* from users where users.name = ‘myName’”
We have found that it is occasionally producing “SELECT users.* from users where users.name = 0″.
This is invalid and will give a database error. Help!
(Daniel Grippi)
http://www.meetup.com/NYC-
http://www.meetup.com/
I’ve been experimenting with functional programming (FP) languages for a little while now and their acceptance is generally increasing amongst the wider developer community. This is the first post in a series of articles I hope to do that explore FP, what it is and what we could learn from this trend.
Functional programming languages are by no means new. LISP often thought of as one of the first programming languages was developed in 1958. IPL a sort of assembler like symbolic language appeared in 1954. The foundations of FP are embedded in mathematical constructs much older than the concept of an electronic computer.
But for all intents and purposes they sort of disappeared into obscurity, replaced by procedural languages like C or Object Orientated (OO) like C++ or Java. Partially because they were impractical – some of the constructs used by FP languages performed worse than their imperative counterparts. In a time when CPU power was scarce, this was not an option.
Thanks to Moore’s law this has changed somewhat. Computers now are certainly more powerful then they were when the first LISP interpreter appeared. But the ever scaling MHZ peak has slowed. New CPUs come with more cores, not more cycles. To take advantage of these improvements we need to look to parallelization and FP languages are inherently suited to this kind of work.
I am not alone in recognizing this. IBM released this article recognizing the rising trend. ThoughtWorks has identified Scala and Clojure in its technology radar and recognizes momentum building behind several FP languages: http://www.drdobbs.com/mobile/thoughtworks-eyes-seismic-shift-in-progr/240009675. Spend any time on Hacker News and you’ll regularly see links on the topic.
I feel like FP is an idea whose time has come and I’m very excited by the new languages, ideas and technologies that are appearing. Hopefully Pivotal Labs will someday join me on this journey.
The 3.0.x and 2.3.x lines are affected. It’s a mega security flaw in JSON parsing. Upgrade your old apps now. 3.1.x and 3.2.x lines unaffected. Read more here: https://groups.google.com/forum/?fromgroups=#!topic/rubyonrails-security/1h2DR63ViGo
Talk about Software Development and Agile.
(PM and DK)
helpers for emails in capybara, allows you to open a specific email, make assertions and even click links!
https://github.com/dockyard/
(Josh Knowles)
View & manager stories across multiple projects built by our former client IntentMedia - https://github.com/
(Dimitri Roche)
:g
:[range]g//cmd
Example: :g/Hello/d
This will act on the specified range, by executing the Ex command cmd (An Ex command is one starting with a colon (‘:’)) for each line matching . Before executing cmd, “.” is set to the current line.
(Thanks John Barker)
Last week an article that touched on a popular stereotype of the nocturnal programmer was published at Business Insider. Articles like this are always popping up from time to time and they tend to cause some controversy among programming communities–probably because one programmer’s dream work environment is another’s distracting hell.
I wish I had some deep insight into why the internet is overrun with articles like this about what makes for a productive programmer. I think simply that the nature of writing software is not well understood. What we do is tough to categorize. It’s not like classical engineering, we’re not calculating the tensile properties of metals and then building a bridge or an airplane. It’s not art. Maybe programming is a craft.
Articles like this that chase after some enigmatic insight into the secret of programmer productivity remind me of a lot of specious advice for fighting writer’s block. Lock yourself in a room, naked, with nothing but a typewriter. Pay someone to slap you when you stop writing. Whenever I come across this kind of advice I’m reminded of this canonical Chuck Close quote:
“Inspiration is for amateurs; the rest of us just show up and get to work. If you wait around for the clouds to part and a bolt of lightning to strike you in the brain, you are not going to make an awful lot of work. All the best ideas come out of the process; they come out of the work itself. Things occur to you. If you’re sitting around trying to dream up a great art idea, you can sit there a long time before anything happens. But if you just get to work, something will occur to you and something else will occur to you and something else that you reject will push you in another direction. Inspiration is absolutely unnecessary and somehow deceptive. You feel like you need this great idea before you can get down to work, and I find that’s almost never the case.”
I imagine most anecdotal accounts of productivity tricks boil down to this: “this is what keeps me putting one foot in front of the other.”
A bunch of us in the NYC office have a goal to get more blog posts under our belt this year. (Why, you ask?) To that end, we’ve begun an “iron blogger” group this month. The concept is simple: you buy in with twenty bucks and if you write a blog post by the deadline, you get it back. If you don’t, your cash goes to the group. There’s more than just a small financial incentive, though; there’s social pressure, but also the excuse to just ship whatever half formed ideas you have in your drafts folder (he laughed, nervously.) The point is to write–to write poorly, even!–to screw up and miss deadlines and live to write again. In other words, the purpose of iron blogger is to encourage us to keep putting one foot in front of the other.
Once you’ve launched a product, “metrics” can be a powerful tool in measuring engagement and product issues. From the engineering side, devs have a hard time believing if a metric is valid or misleading. From the biz dev/marketing side, it’s hard to understand the technology enough to know what kinds of questions can be asked. I’ve gone up the learning curve on implementing, understanding, and actioning metrics and have noticed that people have a hard time getting started. This post is the first in a series on metrics, and I hope they give you the kick you need to get started.
Today I want to focus on the funnel, a strange analogy for describing websites and conversions. If you bought a funnel that only delivered 10% of the water you poured in, you’d ask for a refund. Yet, that’s how we describe the attrition that occurs as users/customers engage with your product. Funnels are important for two reasons: they force you to think about which interactions are most meaningful, and they help you understand where your assumptions aren’t valid.
At Profitably, we built a financial dashboard for small businesses. Our historical analysis offering was off the mark, so when the time came to tackle forecasting we wanted to build something more engaging, but also build in a way that allowed us to iterate quickly.
We took inspiration from the wizards in TurboTax to collect the information we needed from a business owner to deliver a useful customer forecast. Even though we were worried about the amount of information we [thought we] needed, we were encouraged by Twitter’s dramatic results from the introduction of gradual engagement for sign up (+29% conversion). This flow also enabled us to create a rather linear process from start to finish: no registration step, just enter the name of your company and click Get Started. Someone that successfully completed the wizard would see a detailed forecast for customer growth…end of the funnel.
We had talked with lots of small businesses before building to understand what they had been doing instead, but you can only get so far with conversations and mockups. Beyond these qualitative tactics, behavioral analytics gave us the ability to dive into this funnel and come out with hard numbers. Here’s what the initial KISSmetrics funnel looked like early in the release process:
Man, that is sobering. I had reached out to every person that went through to get a sense of their business and what problems they were hoping we could solve. But, to be honest, there was a lot of work staring us in the face just from looking at that [looooong] graph. Here are my thoughts on each step, and how we reacted:
Those are just the micro/optimization-focused thoughts and actions. After implementing some tactical fixes, we saw the funnel conversion go from 13% to something in the 65% range (5X). I’ll leave how we improved that funnel on a macro scale and took the product to a much better place for a different post. For now, I’ll leave you with something I try to remember when thinking about making a product better:
“Product development is about figuring out the single most important problem that exists right now and doing that and only that” (Jason Freedman).
By forcing yourself to identify the funnels that are most important to your product, you’ll force yourself to explain why people are falling out. You’ll also give yourself a quantitative feedback loop to confirm that new features actually keep people in.
Kim Dowd, Jake Burton-Denmark and I have been working together on a project for the last few months. Throughout the project we’ve adopted and iterated on the following sketching technique (credit to David Sherwin who exposed us to this approach). We use it for kicking off new features or revising existing ones and we apply it to all sorts of tasks, from developing big, broad feature sets all the way to small specific interactions where the solutions might seem obvious at first.
HERE’S HOW IT GOES:
The designer that picks up the user-story from Tracker briefly explains the context of the story, its background, and the constraints involved.
In this case the story was: “A Physician can indicate that a patient is leaving the ER.”
An example requirement is: “She can indicate what happens with the patient next.”
The context was stated as: “Typically, she does this after looking at the results of tests, and recent vital signs.”
We play music and set a timer for five minutes.
For this story we choose to play Tycho.
Once the timer is running, each of the designers on the team (3 of us) grabs paper and a Sharpie and spends the next five minutes sketching out wireframes and flows for three potential solutions that meet the story’s requirements.
It’s important to remember to only use broad strokes and not get into the details of the wireframe. We are just looking to get an idea across, not to draw a perfectly accurate wireframes.
Each sketch is no bigger than about 1/4 of a letter sized piece of paper. The small canvas forces us to stay general and prevents us from deep-ending on the details.
Once the five minutes are up, we always seem to need an extra 30 seconds to finish :)
After five and a half minutes of sketching, we each walk the team through our sketches. It is important to keep it brief, not more than four minutes each, tops. We find it useful to point out the advantages and disadvantages of each of our suggestions.
As we go around, one of us takes notes of questions that come up, missing requirements that need further clarification and anything that would requires user feedback (these then go to a separate running list of things that need user validation).
CHOOSING THE RIGHT SOLUTION
You’ll find that sometimes all participants come up with more or less the same solutions. In this case we say “Great!” (apparently the solution is obvious and no one on the team identified a problem with it). Other times, we’ll each go in completely different directions. This typically means we need more clarification around the goal of the feature in order to decide which direction makes the most sense. This is when it gets interesting.
Usually what we find is that each of us has made an assumption about the requirements (e.g., “I think the form should only be 2 fields” vs “I think the form should be long” or “I think the user needs access to this other page while filling out the form” vs “I think the user has all the information they need in their head while filling out the form”). When this happens, it usually means that in order to choose the right design we need further clarification.
The owner of the story will then collect all of the sketches and questions and is responsible for collecting the information needed to pick and execute the appropriate design.
WHY WE FIND THIS SO USEFUL:
A NOTE FOR SOLO DESIGNERS:
You’ll find it challenging to do this exercise when there is only one designer on the team. If this is the case, you can bring in external designers, from other teams or people from your community, etc. and go through this process with them. Another alternative, which we haven’t tried at Pivotal yet, is to work with non-designers on the project such as PMs or developers.
This is process is working really well for us and the results for our clients are great. I’d love to hear if you implement this process, how you find it and ways in which you do it differently. If you have other processes you use, please share them in the comments.
Design starts with systematic thinking and then shifts to incremental changes. No matter where a project starts, at some point the design systems’ integrity will degrade to the point that you need to look at the whole thing fresh. Welcome to the Big Design Refactor. In the beginning, you had a beautiful, functional design system. And then you had to watch, helplessly, as it degraded under the weight of a thousand tiny changes. It’s maddening, and a big reason many designers are allergic to Agile methodologies.
What can you do? Understanding and accepting that this design-system degradation is an affordance of differently-sized design and development cycles is the first step towards making peace. Once you realize and accept this change, it’s much easier to deal with. Plan on it. Talk about it with your team. Designers need not work at developers tempo. Rather, they should strive to stay in-rhythm with development, working at their own pace, and making sure their beats and decision-points intersect with development at regular intervals.
As the designer, it’s your job to keep an eye on the health of the graphic system. Just as the developers incur and pay down their technical debt, you’ll manage your design debt. How? Mention that the graphic system is starting to break down. All the while, you’re still doing your work. Keep solving the tactical problems, keep delivering value. At some point, the balance shifts: you’re no longer plugging little leaks or engaging in preventative maintenance. The system is undermined; the cracks are starting to show. Now’s the time to have a talk with your team. You’re going to need a few weeks to work on this. You’re going to need the development team to find something design-light and backend-heavy to focus on for a week or two. Hold a design retro. Get their feedback, and their buy-in, and their good ideas. And now you’ll have a break from the tactical work of patching up design as features iterate. You’re a Pure Designer again, working in your idiom, experimenting and sketching and building a new design system.
When I’m in the midst of a Big Design Refactor, I’m spending most of my day in Adobe Creative Suite. I’m pulling the product team over ~4-7 times a week to bounce ideas off of them. I’m pinging the development team ~1-2 times a week to consult on the technical implications of where I’m going. By the end of the week or two, I’m usually delivering a set of user stories accompanied by mockups. It’ll often take an IPM or two to get through all of them, and it’s important that they get implemented soon. Nothing feels more like waste than a heavy investment in design, followed by unacted-upon stories that go stale. This will kill trust between the design and product teams (in both directions); it’s downright poisonous.
Now, while the new design is being built by developers, I’ll occasionally hop back into Adobe Creative Suite for assets or newly-discovered UX tweaks, but most of my time is spent pairing with developers. I’ll also keep a close eye on acceptance. Pixel-perfection is rarely necessary, but miss an important UX point now and the error will become enshrined as part of the system.
Once the Design Refactor has been assimilated into the app—and it’s rare that 100% goes in, but 80-90% is the norm—it’s Tactical Incremental Fun Time! I’ll spend most of this time pairing on stories, picking of styling stories to solo on, and working on design problems revealed by user testing. At this point it’s probably 66% development and 33% Adobe apps. The debt clock is starting to tick again, and once the pain is noticeable, I’ll start making noises: “we’re ok for right this second, but we’re going to need a design refactor in the next 3-5 weeks”.
Design and development are activities that move at different speeds. Test-driven development and Agile project management allow developers to break work down into small stories and iterate on them. The unit of work for the “what” of the story is “what’s the smallest possible thing that delivers value to the user?” and the “how” of the story is “what’s the simplest possible thing that can work?”. These units of work tend to translate poorly to design, because effective graphic design is almost always a system. Changing arbitrary pieces tends to degrade the whole. Design adjustments that are close in size to development units-of-work can be made, but they inevitably undermine the graphic system, creating Design Debt. Debt is fine, if used responsibly, but it needs to be paid down at some point. (More on that another time.)
Developers work at a quick tempo. They use Agile’s small units of work to facilitate a supple workflow that responds gracefully to changing client needs.
The customer wants to re-prioritize a feature? No problem! Move it to the top of the backlog and we’ll get to it next.
Because they’re backed by tests, devs are free to move around the codebase and project, making changes where the customer likes, with the confidence that their test suite will protect them from breaking the app. Designers have no such safety net—which is one reason that developing meaningful automated testing for design is crucial to a mature Agile design practice.
The rhythm of design is slower. Design pulls together an information architecture, UX metaphors, visual styles, a typographic system, a color system. Visual rhythm, hierarchies, and scale combine into a whole graphic system—more than the sum of its parts. All these pieces interrelate, and changes cascade into other. While adjustments to individual design elements can happen quickly, feature-scale iteration doesn’t allow for changes to the system; those take more time.
Ideally, bring a cohesive graphic system to Inception. Accept that it will degrade over time. Make tactical adjustments to keep pace with agile development, and plan on overhauling the design system every quarter or so.