Yearly Archives: 2013

Interestings

0 duration != no animation

UIView documentation for animateWithDuration:animations: says: "If you specify a negative value or 0, the changes are made without animating them." but specifying a zero duration is not the same as not using animations at all. Specifically, constraints still animate even if the duration is 0.

Despite Apple emerging victorious in the most recent battle with Samsung, it didn’t leave with the prize: the judge did not grant Apple a much-desired injunction that would keep a good chunk of Samsung’s roster off the playing field. In a bizarre twist of events, Nokia filed an amicus brief on Apple’s behalf for the judge to reconsider. Nokia is doing this in order to support innovation and prevent companies from stealing each other’s ideas.

While that sounds like an extremely noble gesture, there are probably some other consequences on Nokia’s mind. What is the real reason Nokia chose to intervene?

1. Microsoft’s Invisible Hand

Microsoft invested a lot in Nokia. Nokia also put a lot of faith in the Windows platform. In essence, it could be Microsoft that is pulling Nokia’s strings to step in. This could be a plea for attention, so Samsung would move farther away from near-Android exclusivity and give the Windows Phone OS a whirl.

Despite Apple, Microsoft, and Nokia trying to pick a fight with tech giant Samsung, they may still not have enough firepower. If Apple wasn’t able to wound Samsung on its own, Nokia – a shell of its former self – will likely not contribute to the effort in a significant way.

2. Slow Samsung Down

Should Samsung products be banned in the U.S., Nokia will have the opportunity to step in with its own products and rob Samsung of some of its significant market share. Similarly, it also helps Windows Phone OS take market share away from Android.

This could also be an attempt to mess with Samsung’s profit margins by delaying sales and product launches in a major consumer market.

3. For Future’s Sake

Nokia could also be gazing into the future and laying foundations to set a precedent that may benefit them. In the filing, Keith Broyles, Nokia attorney from Alston & Bird wrote:

“Nokia has recently been involved in numerous U.S. patent lawsuits, as both a plaintiff and defendant. Nokia is thus both a significant patent owner that might seek an injunction to protect its patent rights, and a manufacturer in an industry in which patent owners routinely issue threats of injunctions for patent infringement.”

It seems that Nokia may be trying to use this ruling as an example when and if they seek injunctions in the future. Not to say they need the help; Nokia has been in a lot of patent lawsuits themselves, and they usually win. They actually previously won against Apple, and have successfully defended themselves as well.

Final Thoughts

Nokia’s intervention could be just enough to tip the scales in Apple’s favor; however, it might prompt another competitor to step up on Samsung’s behalf. This could also lead to the great debate of whether patents are here to protect, or stifle, innovation. Regardless, a lot has already happened – this is the first time a competitor has backed another competitor in this sector, which means we’re seeing history being made.

Like many text editors, RubyMine supports bookmarks. A bookmark is a reference to a particular line in a file. They are visually indicated by an icon in the editor gutter. Bookmarks can be used as a form of navigation based on interested parts of a codebase. In this post, we’ll explore (using the Mac OS X 10.5+ keymap) the three types of bookmarks in RubyMine: anonymous, numbered, and lettered.

Anonymous Bookmarks

Anonymous bookmarks can be created with F3. They appear as a checkmark icon in the editor gutter.

Unfortunately, there are no default keyboard shortcuts to navigate anonymous bookmarks. Instead, use the Find Action command,command + shift + A, to search for the “Next Bookmark” and “Previous Bookmark” anonymous bookmark navigation commands. These commands will only navigate through anonymous bookmarks in the current file.

Mnemonic Bookmarks

There are two types of mnemonic bookmarks: numbered and lettered.

Numbered Bookmarks

You can have up to 10 numbered bookmarks: 0-9. To create a numbered bookmark, press control + shift + <number>, e.g., control + shift + 4.

To navigate to a numbered bookmark press control + <number>, e.g., control + 4.

Lettered Bookmarks

You can have up to 26 lettered bookmarks: A-Z. To create a lettered bookmark press option + F3, then choose a letter to use for the bookmark.

Deleting Bookmarks

All three types of bookmarks can be deleted by pressing F3 when on the bookmarked line.

Viewing Bookmarks

You can view all existing bookmarks with command + F3.

This dialog also allows you to delete, and navigate bookmarks.

Last Edit Location “Bookmark”

When editing, it’s common to stop for a second to view another part of the file (or a different file), and then navigate back to the original edit location.

Instead of using bookmarks to quickly navigate back to the original edit location, use the Last Edit Location command, command + shift + Backspace.

Experimenting with Bookmark Navigation

After trying out the different types of bookmarks in RubyMine, I find numbered bookmarks to be the most useful. They are both easy to create and navigate. Lettered bookmarks offer a greater number of possible bookmarks, but navigating them requires several commands. I think anonymous bookmarks could also be useful, if you create shortcuts for their navigation commands.

Why does Ford have an active program to reach out to app developers? What is changing in the dashboard to make apps a must-have for cars? In an interview with RadioWorld, Julius Marchwicki, global product manager for Ford Sync AppLink, talks about Ford’s outreach to developers and its app strategy. In Ford’s case, cars represent a real mobile consumer application platform.

You can’t draw in younger buyers with big engines anymore; the way to capture market share for new cars is to offer the latest in infotainment, right in your car. Apps give Ford access to providers and sources of content, from Pandora to HD Radio to satellite radio. This essentially moves radio from a transitory broadcast media to something more like a DVR for radio; you can access content you might have missed at a later time, or rewind a show to hear the beginning of it. In the future, other content like Weather, Traffic and Restaurant suggestions will also be delivered to your dashboard through Apps.

How does all this work? Not surprisingly, there’s a link between the radio and the smartphone. iOS devices connect using a USB cable; Androids connect wirelessly. Once connected, drivers can control the apps with buttons on the steering wheel, voice commands, or dashboard displays.

The AppLink program is worldwide, so while we often think about the US radio conglomerates and music companies, Ford is embracing partners in Asia and in Europe, where the company sells a large number of vehicles.

RadioWorld asked why Ford is focused on apps versus on developing a new radio. Marchwicki’s reply is telling: “One of the reasons why is we want to be able to, as a car company, keep up with changing trends in technology because it takes us so long to design and engineer a radio, and then build it into a car. By the time the radio in a car is built, it’s almost a year and a half old. With this technology, with Ford Sync AppLink, we can stay relevant.”

The end result for Ford is the ultimate in flexibility. When customers started asking for Spotify in addition to already supported Pandora, there was a very quick ramp-up to add new functionality to the platform. Furthermore, it will work on all Ford cars that support AppSync. Drivers can finally have their choice of content and say, if they drive a Ford, that there’s an app for that.

Three years ago, I quit my Rails consulting gig, bought a VW Bus and started traveling. I thought, if I was independently wealthy I would spend my life traveling, climbing and surfing. I loved that life. I was living the dream.

I didn’t write a line of code… for 6 months. Then, in the middle of winter, in Kentucky, I spent three days in the basement of a pizza shop. No running water, no heat…. but it had electricity and wifi. I spent three days hacking away, and I loved it.

At that point I realized that I needed to write code. It provided something my soul craved.

I think it’s the ability to CREATE that I love. I find taking an idea and turning it into reality… satisfying. Maybe if I could paint, compose music, or ice sculpt with a chain saw I’d do one of those things instead, but I can’t.

We faced challenges when first attempting to deploy images to our late 2012 iMacs with Fusion drives.

You may see this error:

“Workflow Aborted

The destination volume is too small.”

Our solution was to modify our workflow to include an additional step that split the Fusion drive before continuing.

10.8.3 DeployStudio Challenges

Before starting, make sure your NetBoot set is updated to 10.8.3. You’ll save yourself a world of agony.

Splitting the Fusion Drive

We found the easiest way to make it work was to use this script to split the Fusion drive, which we have named “split_fusion.sh”:

#!/bin/sh
#
# Copyright (c) 2013 Pivotal Labs
# Permission is hereby granted, free of charge, to any
# person obtaining a copy of this software and associated
# documentation files (the "Software"), to deal in the
# Software without restriction, including without limitation
# the rights to use, copy, modify, merge, publish,
# distribute, sublicense, and/or sell copies of the
# Software, and to permit persons to whom the Software is
# furnished to do so, subject to the following conditions:
#
# The above copyright notice and this permission notice
# shall be included in all copies or substantial portions of
# the Software.
#
# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY
# KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE
# WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR
# PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS
# OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR
# OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR
# OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
# SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
echo "force unmount"
diskutil unmount force /dev/disk2
echo "split_fusion.sh - v0.02 ("`date`")"
diskutil cs delete `diskutil corestorage list | grep "Logical Volume Group" | awk '{print $5}'`
echo "split_fusion.sh - end"
exit 0

Some notes about this script:

The important line is the “diskutil cs delete” line. That is the command which will split the Fusion drive. “cs” is an abbreviation for CoreStorage.

The “diskutil unmount” was a hack to get around a bug where 1/3 of the iMacs would not split the Fusion drive because it was unable to unmount it.

This script will work on machines that do not have Fusion drives.

If you have a RAID’ed machine, you probably won’t want to use this script; we believe it will destroy (i.e. separate into distinct physical volumes) your RAID partition.

This script will work on a DeployStudio network server; however, were not able to make it work with a bootable DeployStudio server FireWire/Thunderbolt drive (i.e. no network).

Modifying you DeployStudio Workflow

Copy the script into your DeployStudio’s scripts sub-directory. Make sure this script is executable.

Open DeployStudio Admin.

Click on Workflows

Click on “+” next to the Workflow timeline to view available icons.

Add “Generic” to the Workflow timeline by dragging and dropping “Generic” to the beginning of Workflow.

Add description, “Split Fusion”.

From the drop down at Command, select the script that you added in step 1, e.g. “split_fusion.sh”.

In a staff report released on February 1, the U.S. Federal Trade Commission (FTC) offered recommendations to protect consumers including just-in-time disclosures, privacy icons, and the creation of a privacy dashboard. This is important information for anyone seeking to improve mobile apps. While FTC recommendations don’t have the force of law, they reveal issues of concern to the FTC and following these guidelines can save time later if any of them become law.

Barry Benjamin and Jeremy Schachter, writing in Lexology, provided a detailed summary of the FTC report, which suggested that mobile app platforms, such as iOS and Android, provide the following elements:

Just-in-time disclosures. When an app is about to access some private information, a dialog box often appears to tell the user that it’s going to happen. These disclosures are most often seen with relation to apps that use geolocation: “This App Wants To Look At Your Location Information.” The user can then say yes or no.

Privacy icons. An icon appears when the app is accessing location information. The FTC thinks devices should display such icons.

A Privacy Dashboard. A privacy dashboard lets users periodically revisit earlier choices and decide if they want to change their minds. For example, if a consumer goes shopping at a mall out of town, they might allow its app to access their location information in order to receive offers, but now that they’re back home, there’s no reason for the app to have that information.

The FTC’s recommendations have implications for developers too. App developers are expected to know what information they are providing to third parties (such as ad networks), and furthermore what those third parties are doing with it.

Another important provision is the FTC’s recommendation of Do Not Track or DNT capability. Users should be able to tell their devices not to track them. The setting for this should be easy for users to find and work persistently across all apps. DNT should work at the platform level, but it also has implications for ad networks, which the article says “should work with platforms to ensure implementation of an effective DNT system for mobile.” Although many of the FTC’s recommendations will improve apps, it is unlikely that ad networks are going to jump right on board with DNT based solely on a recommendation.

I was pretty interested in refinements in Ruby 2.0, and after listening to the latest Ruby Rouges podcast where some serious doubts were raised about the viability of refinements I thought I’d build a little example of how I was thinking I could use it.

I failed first time out and I tried copying and pasting examples without success. After some time poking around I found a blog post about why this wasn’t working. Ultimately, refinements are sort of left in the language, but not fully supported and are marked as experimental.

Here’s what I wanted to achieve. Coming from Scala in my previous job, I thought I could use refinements as a proxy for implicit conversions. Here I refine the Fixnum class to allow it to respond to a to_currency message. When called it converts the Fixnum instance to a Currency instance.

All signs point to 2013 being a boom year for software – especially for custom application development. Digital engagement is the force driving increased budgets and staffing for app development, according to a blog post by Forrester’s Kyle McNabb in ComputerWorld UK. Customer expectations are higher than ever and are pushing companies to invest in app development. After all, as McNabb rightly states, a “mobile application isn’t just an app; it is an extension of the company and its brand.”

Growth and customer experience improvement take business priority. Some 70% of business leaders polled said they placed a high or critical priority on revenue growth, customer acquisition and retention, and addressing rising customer experience expectations.

eBusiness is king, but customer service is a close second. Over 40% of software and application delivery decision-makers listed their sales stakeholders, including eBusiness, as the primary drivers of their firms’ software strategy and investments. Customer service is also impacting the strategic software development agenda, underscoring the importance of customer engagement.

Not surprisingly, these trends are driving action in the area of app development, leading to increased investment in software development and staffing. Companies are realizing packaged apps and tools are not enough to accommodate rapidly increasing managerial and customer expectations. When an organization has many competitors, whether or not those companies have apps, points of differentiation are critical to business. A customized app can be just the solution, which accounts for why increasing numbers of companies are choosing to spend more to build a custom application: they want to differentiate themselves by offering a unique mobile experience that represents their brand.

2013 looks to be a prolific year for custom application development. These custom applications are driving key initiatives, like turning big data into actionable insights and increasing customer engagement. In another blog post, we discussed how cloud-based application development is making it easier than ever to experiment with new initiatives. Nearly every business needs to have a response to the mantra, “There’s an app for that.” The quest for creative apps that drive new kinds of customer engagement will continue to keep the app development engine humming.

We’ve since taken an alternative approach to the skip navigation technique, since this technique does not change keyboard focus to the targeted content. Instead, we ended up creating an aria landmark using the role attribute with a value of ‘main’. It looks something like this:

The role attribute can be set to a variety of values to help screen readers evaluate the structure of a page. Then the user can use a combination of hotkeys to navigate to these landmarks. In Safari with VoiceOver for example, one would press the VoiceOver keys + U to activate the Rotor, and be presented with a list of page landmarks (including ‘main’) that when navigated to, will immediately get focus and be at the beginning of the read order. JAWS, ChromeVox, and NVDA have similar behavior.

Using an ARIA landmark with a role of ‘main’ is a more robust and elegant solution than using skip navigation links. This technique is also well supported across user agents, and yields disproportionate gains in accessibility compared to development time, making it an easy win for more accessible content.

Terminal text editors often allow you to navigate in terms of basic text objects, such as, characters, words, or lines. For maximum speed, the commands for these simple navigations are usually available on home row keys; so you don’t have to use the arrow keys.

Unfortunately in RubyMine, performing these basic movements requires using the arrow keys. However, I saw this disadvantage as an opportunity to research alternative navigations. RubyMine may make simple movements tedious, but it adds many powerful code-based navigations. By being aware of programming constructs such as methods, and classes, RubyMine demonstrates the difference between IDEs and text editors. In this post, we’ll look at some of these unique navigation commands for OS X.

Navigating by Symbol

command + option/alt + O is for when you know what you’re looking for, but not where it is. This shortcut performs a fuzzy search of project symbols. It allows you to quickly find classes and methods.

Navigating by Method

When browsing an unfamiliar file, it’s common to want to move through it one method at a time. This allows you to quickly scan method signatures, and browse implementation. Use control + Up/Down to move forward and backward by method.

Navigating to a Specific Method

If you know the method you’re looking for, then navigating by method is too slow. Instead, use command + F12 to open a file structure dialog, then begin typing the method name to navigate to it.

Navigating to a Declaration

Navigating directly to a type declaration is one of RubyMine’s best features. This is often available in terminal text editors via ctags. However, I’ve never been able to successfully configure ctags to work as powerful as RubyMine’s version.

Press command + B when your cursor is on a class/module object to open its declaration. If you don’t want to open the declaration, use command + Y to quickly view it in a separate window.

Press command + B when on a variable to navigate to its declaration. Navigate to the declaration of the type of a variable with control + shift + B.

Navigating Class Hierarchies

If you’re interested in the subclasses of a particular class, press command + option/alt + B on a class object.

Use command + U within a class declaration to navigate to its superclass. Within an overridden method, command + U will navigate to its superclass definition.

Navigating to Related Files

RubyMine’s awareness of Rails allows you to quickly move between models, views, helpers, controllers, and their tests. When editing, use control + command + Up to be presented with a menu of related files.

Navigating Tests

When test driving a Rails project, it’s great to be able to quickly switch between test and non-test code. Use command + shift + T to move between a file and its corresponding test file (and vice-versa). In a split tab layout, for example, a vertical split between test and non-test code, command + shift + T will move between the splits.

Navigating Between Changes

Version control introduces an interesting way of navigating. In RubyMine, file changes are highlighted (in various colors) in the editor’s gutter. Use option/alt + shift + control + Up/Down to move between these changes.

Navigating Through Navigations

RubyMine even provides commands to navigate backward and forward through executed navigation commands. Use command + [/] to move through your navigation command history.

IDEs vs. Editors

A text editor doesn’t know what kind of text it’s editing. Code aware extensions are usually added on via plugins, distorting the editor’s basic purpose. An IDE, like RubyMine, with its powerful code-based navigations, really shows the advantages an IDE has over a basic text editor.

As a feature story progresses through the Tracker workflow, a lot of testing activities are also underway. Team members are collaborating to turn examples of desired behaviors into business-facing tests that guide development. Testers are performing manual exploratory testing on stories as they are delivered. Performance or security testing may be underway at some point in the development process.

A testing workflow?

To keep things simple, Tracker’s states are limited to Not Started, Started, Finished, Delivered, Accepted and Rejected. Only the “Accepted” and “Rejected’ states seem directly related to testing. Testing activities such as specification by example, acceptance testing, exploratory testing, load testing, and end-to-end testing aren’t reflected in the Tracker workflow, but they’re going on nevertheless. Testers, coders, product owners and other team members continually talk about how a feature should work, and what to verify before accepting a story as “done”. But details can still be overlooked or lost. If stories are rejected multiple times because of missed or misunderstood requirements, or problems slip by and aren’t discovered until after production release, testing activities need to get more attention.

We’re working on enhancing collaboration and communication in Tracker, with increased flexibility that will help with tracking testing activities. Meanwhile, how can Tracker users follow testing along with other development activities? It would be helpful to have a place to specify test cases, note plans for executing different types of tests, and make notes about what was tested. Accomplishing this requires a bit of creativity, but it’s possible to keep testing visible in the current Tracker workflow. Here are some ways we do this on our own Pivotal Tracker team.

Testable stories

First of all, we work hard to slice and dice our features into stories small increments that are still testable. We read the stories in the backlog to make sure we understand what each one should deliver, and how it can be tested. If I have questions about an upcoming story when we’re not in a planning meeting, I note it in a task or comment to make sure we talk about it. Iteration planning meetings are a good place for the team to start discussing how each story will be tested. Some teams get together with their business experts to help write the stories with this in mind.

We make sure we know how we’ll test all the stories in the upcoming iteration. There are a couple of different ways to get enough of this information into the story .

Using tasks and comments

Test cases and testing notes can be added to a feature story as tasks. They’re easy to see in the story, and can be marked as completed when done. We often include links to additional details documented in a wiki page, or to automate-able functional tests used for acceptance test-driven development (ATDD). As teammate Joanne Webb points out, sharing test cases before implementing a story clarifies requirements, and gives developers clues on problems to avoid introducing. In our experience, this shortens the accept/reject cycle for stories.

Comments are another good place to add information about requirements and test cases, especially since you can also attach files with additional information, screenshots, pictures of diagrams, and mockups. And if team members have questions they can’t get answered in person right away, comments provide a place to record a written conversation, and email notifications can alert the story owner and requester so they can answer questions.

Visibility and workflow through labels

We can find ways to record conversations about requirements, but how do we incorporate a testing workflow into the larger development workflow for a Tracker story?

Labels are a handy way to keep stories progressing through all coding and testing tasks. In our Tracker project, automating functional tests is part of development. The story isn’t marked finished until both unit tests and functional tests are checked in, along with the production code. Once a feature story is delivered, someone (usually a tester or the product owner, but it could be a programmer who didn’t work on coding the feature) picks up the story to do manual exploratory testing.

To make this visible, we put a label on it with our name, for example, “lisa_testing”. Not only do we conduct exploratory testing, we verify that there are adequate automated regression tests for the story, and that necessary documentation is present and accurate. Once we’re done testing a feature story, we put a brief description of what we tested in a comment, remove the “testing” label, and add another label to show the story is ready for the product owner to verify. This might be “lisa_done_testing” or “ready_for_dan”. Sometimes the product owner gets to the story first, and uses similar labels to show he’s in the process of testing or finished with his own acceptance testing. Once all involved parties are happy with the story, we can accept it. Using labels is a bit of extra overhead, but it gives us flexibility to continually improve our acceptance process.

Putting together a bigger picture

Some testing activities extend beyond one story, especially since we usually keep our stories small. It’s possible to write a feature story or chore for the testing activity. For example, you might write a story for end-to-end testing of an epic that consists of many stories and extends to more than one iteration. Writing a chore for performance testing, security testing, or usability testing may be useful.

However, as my teammate Marlena Compton points out, there are advantages to making sure testing is integrated with the feature stories themselves. If a story remains in delivered state for several days while we complete system testing related to it, the labels we put on the story convey the testing activities underway. Completing all testing before accepting a story helps ensure the stories meet customer expectations on the first day. As Elisabeth Hendrickson says, testing isn’t a phase, it’s an integral part of software development, along with coding and other work. Having our Tracker stories reflect that helps keep us on target.

As we do exploratory testing on a feature story, we might discover issues or missing requirements that don’t make the story un-shippable, but may need to be addressed later. We can create separate feature stories, bugs or chores for those, and link back to the original story via links or labels.

We track some testing information outside of Tracker, for example, on our team wiki. However, we find that tracking testing activities in Tracker helps ensure that they get done in a timely manner, and keeping tests visible helps ensure that stories meet customer expectations the first time they’re delivered. Integrating testing activities with coding tasks keeps our testing efforts aligned with other development efforts.

While we work to make Tracker more flexible for teams and testers, we hope these ideas help you make your testing more visible in the Tracker workflow right now. Check out our blog post http://pivotallabs.com/2013-update-new-features-new-api-new-design/ to get an overview of some of the plans for Tracker this year, and come back periodically for the latest news. We’d also love to hear how your team incorporates testing in agile development. Please leave a comment, or write to us at tracker@pivotallabs.com.