Yearly Archives: 2013

Setting the CDPATH environment variable saves you having to cd to commonly-used parent directories. I usually put my main workspace directory in there to allow direct directory changes to project dirs, as well as ‘..’ to allow jumping to sibling directories.

Having recently switched from Ubuntu (again), where console niceties are the default, I was frustrated to find that bash didn’t complete my CDPATH entries. However, it’s easily fixed with Homebrew:

brew install bash-completion

This works: new bash shells will complete CDPATH. However, it slows shell load time down considerably. This problem is fixed in the latest bash-completion script, but it’s only compatible with Bash 4. OSX ships with version 3. Let’s upgrade it:

The Go language includes several unique features, many of which are found in other languages. The most interesting one however, is its support for concurrent programming. Instead of a traditional approach using locks and mutexes, concurrency in Go is based on communicating sequential processes. In Go, the paradigm is do not communicate by sharing memory; instead, share memory by communicating. Let’s take a brief look at two of Go’s fundamental concurrency constructs: goroutines and channels.

Goroutines

A goroutine is an independently executing function. The go statment is used to launch a goroutine.

In the above example, we execute the function greet in a separate goroutine. This goroutine executes independently of the program’s main goroutine. The main goroutine executes the entry point of every Go program, the main function in the main package.

Unfortunately, running this program results in no output. This is because the go statement returns immediately; the caller doesn’t wait. By the time the greet function was ready to output a greeting, the main goroutine had already finished and the program exited.

In order to receive the greeting, the two goroutines need to communicate. Goroutines communicate through channels.

Channels

A channel is a bidirectional or unidirectional connection between two goroutines, allowing them to communicate.

By using channels, we can receive a greeting from the greet function that's executing in a separate goroutine. In this version, greet sends the greeting to the shared channel; and main reads from it. The main goroutine, i.e., the goroutine executing main, will block until it receives a message from the shared channel.

Only the Beginning

There's a lot more to concurrency in Go. In future posts, we'll look at Go's other concurrency constructs and common concurrency patterns.

With over a million apps in Google Play, and slightly less than that in the iTunes App Store, design has been heralded as one of the crucial qualities that sets a mediocre app apart from an amazing one. Think about how Flipboard’s design sets it apart from the tons of other news aggregation apps for iOS: Flipboard can be navigated through like a magazine with its natural user interface, whereas most other news aggregation apps require scrolling. PC World still deems it the best social news aggregator on the iPad.

In traditional waterfall development processes, designers could only hope that the developer would be able to interpret their mockups and take the effort to make it pixel perfect – translating the mockup into the final product as adhering to all the design elements is incredibly difficult. Unfortunately, in many instances, the developer typically does not invest the time and attention to detail necessary to execute the design perfectly and compromises would be made to get the product shipped.

Today, design continues to go to great lengths to make things beautiful. They may want to be pixel perfect for a variety of reasons: to meet increasing user expectations, to create the best possible user experience, etc. However, similar problems in translation from designer to developer continue to obstruct the possibility of pixel perfection. For example, developers and designers don’t use the same tools to design – designers craft mockups in software like Photoshop, whereas developers build using programs like Xcode, Eclipse, and Visual Studio. However, pixel perfection is becoming a possibility because of two important growing trends: designers are learning to develop, and developers are learning to design.

When these two parties are on the same page, magic happens and product visions become realities faster and with higher quality.

Designers Learning to Develop

Simply launching an app is no longer enough. You are competing with hundreds of thousands of other apps for the user’s attention. As design becomes a more important feature due to increasing user expectations, new tools are enabling designers to quickly learn how to code UI/UX elements. Allowing a designer to speak the same language empowers both the designer and developer to communicate more effectively with the goal of achieving pixel perfection.

One tool that I have seen success with is Microsoft Blend, which supports languages like XML and HTML 5. In this example, a designer was able to learn the syntax and tool relatively quickly, with coaching from a developer, to become a self-sufficient code contributor. By working on the code directly, designers can tweak the code and drop it directly into the product, which takes some work off the developer’s plate. Designers can use the code to build static mockups, animations, and various other visuals.

Developers Learning to Design

Developers understand the value of beautiful-looking apps. They know that taking the time to create an engaging user experience is worth it, because these details provide tangible results. As the market is maturing, the world is starting to reward well-designed apps with millions of users. Don’t get me wrong; there’s still a place for straight-text RSS readers, but there is a growing number of users who appreciate well-designed experiences.

Developers are using their own tools to accomplish pixel perfection. For example, in one of our own recent builds, our developers coded in their own margins, visual references, and spacing based on the design specification that our designer provided. They coded in a module that overlays the design references over their layout (similar in concept to a layer in Photoshop). This is a departure from how apps are usually built: instead of trying to polish with what little time is left at the end of the project, the first thing that was coded were the design elements, such as the margins and spacing, onto the canvas.

When the product was complete, they removed the design specification guide layer. Essentially, they used Photoshop design mentality in their code to achieve pixel perfection.

The Way of the Future

Design is growing as a priority and a prerequisite to building a product that will engage users. Because designers are spending all this effort on making the mobile solution beautiful, it’s imperative that developers build it as specified. That means everything has to be perfect: overlays, pop-ups, animations, and other elements such as velocity (the speed of a rotating animation) and depth.

Developers will not only need to be more precise, but also willing to code to match designers’ mockups. Similarly, designers are now understanding how they can help out with developers’ productivity and previous problems with translating their mockups to the product.

Closing Thoughts

Now more than ever, the success of your product relies on compelling UI/UX. The future of improving design involves designers learning to code and developers learning to design. Creating a pixel perfect product is one way to increase the probability that you will achieve the desired reactions from your customers that use your product.

Near Field Communications (NFC) allows data to be transferred between mobile devices, or between a mobile device and an NFC-equipped sticker, simply by touching them together or bringing them within close proximity. NFC is capable of enhancing promotional campaigns, contributing to the customer experience, and facilitating payments.

For those unfamiliar, NFC is not really an alternative to Bluetooth. When a user bumps an NFC-enabled device with another one, the NFC initiates the process (e.g., turns on the Bluetooth in both devices), and the medium is responsible for the transfer of data. Essentially, NFC is responsible for turning the sharing medium (e.g., Bluetooth or Wifi Direct, depending on the size of the data) on and off, and saving the time and hassle it ordinarily takes to pair devices, enter passwords/verification, and the such. The process is much more seamless, and the common user wouldn’t even notice that a medium played a part in the transfer of data.

Let’s explore some more methods of how NFC can contribute to your business:

Peer-2-Peer Transfers

With apps like Smart Tags for BB10, users can create basic tags or scripts to share links, exchange virtual business cards, or directly input various other forms of information into friends’ phones. Earlier P2P initiatives, like BitTorrent, have given us an idea of how far content can spread when it has the right infrastructure; for example, when bestselling author Tim Ferriss was promoting his book The 4-Hour Chef, he uploaded exclusive content to share with users. The content was downloaded by over 2 million users and resulted in hundreds of thousands of clickthroughs to trailers and the purchase page.

This means items like mobile coupons, webpages with exclusive location-based information, and other types of promotional content can be spread much more quickly, and with much less friction, compared to non-NFC enabled file transfer methods, such as Bluetooth or e-mail (which require pairing and login, respectively).

Credit Card Payments

NFC is best known for its ability to transfer credit card information to facilitate mobile payments (mPayments). There is already a ton of coverage on this topic around the web, so I won’t delve too deeply into it, but it would have been impossible for me not to mention it at all.

For those of you who have not heard about it, NFC is already being used in programs like Mastercard’s PayPass. The beauty of NFC lies in its ability to speed up the payments and line queues while ensuring the payments go through, all with one tap of the customer’s mobile phone.

Smart Tags/Posters

The convenience of smart tags and posters is enhanced by smart triggers. Here’s an example of a smart trigger: visitors to your venue can tap an NFC tag to connect to a secured Wifi network, which means they don’t need your Wifi login. This maintains security while removing a barrier for visitors and streamlining the process, which enhances their experience.

Compared to QR codes or barcodes, NFC works more effectively because it is capable of storing more information. QR codes only work under ideal lighting conditions; however, NFC can be effective regardless of lighting. That means any outdoor promotional posters including NFC would be more effective during the night, or cloudy days, than promotional posters featuring QR codes.

Closing Thoughts

NFC-enabled devices are bringing a new layer of engagement to mobile technology. NFC enables you to craft more creative and reliable marketing promotions, enhance the customer’s experience, or facilitate payments. It’s now up to you to take advantage of it to be more effective and efficient with your business than ever before.

We are happy to announce the availability of Usersnap, the #1 screenshot tool for web development as a new third party add-on to Pivotal Tracker. Get annotated screenshots of the current browser content, directly delivered to Tracker.

Usersnap helps you to communicate effectively about issues and share feedback between developers, customers and quality assurance engineers.

Life is too short for puzzling bug reports. Get actionable reports today with Usersnap.

I’m happy to announce that Ginkgo, a BDD-style testing framework for Go, and its preferred matcher library Gomega are ready for public release. There’s a comprehensive feature list, on the GitHub READMEs and both projects have extensive documentation written up (Ginkgo and Gomega).

Here’s a quick taste of what a Ginkgo & Gomega test looks like, there are many more samples in the documentation:

Google’s Golang treats testing as a first-class citizen. Go has builtin support for writing and running unit tests in the Xunit style. Go, however, does not come with an assertion/matcher library. Nor does it provide any of the higher-level testing constructs that those in the BDD school of testing have grown fond of. Go’s authors have made it clear that these omissions are intentional.

After spending some time writing tests the Go way, I quickly came to miss all the things about BDD that make BDD-style testing so expressive and productive: descriptive tests that can act as effective documentation, simple shared test set up and teardown, nested contexts, etc… Thankfully, writing a solid full-featured BDD testing framework and matcher library for Go turned out to be relatively straightforward: a testament to Go’s flexibility!

Ginkgo and Gomega are heavily influenced by Cedar (BDD for Objective-C) and Jasmine (BDD for Javascript). If you’re familiar with either you’ll feel right at home with Ginkgo.

So Go forth and BDD! I’m looking forward to your pull requests – especially for any new Gomega matchers that you might find useful.

Helps

Environment friendly s3 compatible paper clip configuration

I would like a configuration that would store something about what env the attachment was stored in so that if the DB were copied from one env to another the assets still resolve using the original env. But new attachments are stored with respect to the new env

I started working at Pivotal Labs about one month ago and since then, many people have asked me “How are you settling in at Pivotal Labs?” and this question always throws me off because I’m not settling in. I’ve BEEN settled since day one.

Starting a new job usually means you have to navigate some new waters before really settling in and getting comfortable. For some companies, that might require weeks of training, reading manuals, and taking tests. It can be boring, tedious, or overwhelming. At Pivotal though, it’s a bit different.

My first day at Pivotal Labs was unlike any other first day I’ve experienced. I was immediately placed on a client project, experienced a short inception, and went straight to building the application. Because we pair 100% of the time, working on a real project on my first day was exciting and not very overwhelming. My pair walked me through the usual steps we take to get a project started, explained the development process, and then we went straight to coding. It was that simple!

Because of my collaborative nature, I’ve always enjoyed pairing.You have someone to bounce your ideas, someone to learn from, and overall working becomes a lot more enjoyable with a companion. I knew all of this already, but something I didn’t expect was how quickly I would settle into my role. Knowing that there’s always another pivot by my side to immediately answer all my questions helped take the stress and worry of needing to learn everything quickly as possible but I still immediately acclimated with the Pivotal way.

Pivotal is huge on getting everyone on the team involved with the entire development process. That means everyone takes part in the inception, iteration planning meetings, retrospectives, and outception. Because I always involved, I never felt lost or kept out of the loop, and I got to know the client.

Furthermore, I feel like I’ve grown as a consultant. Before working at Pivotal, I was always afraid to deal with people. I’m a bit of a people pleaser, and so I have a habit of overpromising and then regretting my decisions later. Within my first month, I’ve observed and learned that constant communication, honesty, and transparency can make difficult conversations a lot easier. The client is always aware of our progress. Because the client was in the office, the feedback loop was always short and we would rarely be blocked. If my pair and I were unsure about a story, we’d go directly to the client to ask them for clarification.

So what’s the takeaway? If you have a new employee, hold their hand and walk them through your processes. Sit with them, work with them on the same problem, and show them your expectations by example. Get them comfortable and up to speed as quickly as possible by pairing and working with them.

At Pivotal Labs we have a few basic rules for meetings. Number one: No Laptops Allowed.

At first this may seem counterintuitive and inefficient, especially for a software development firm. However, client and team members alike are pretty quick to convert once they experience the benefits of this simple rule, which has an immediate and profound effect on productivity and engagement.

We all know that the multi-function, connected devices we love are distracting, if not addictive. And of course weʼve all had the experience of missing something important during a meeting while sneaking a peak at an email or researching some random factoid that seemed crucial at the time. But thereʼs more subtle distractions that occur when a team member keeps a laptop open during a meeting, even when itʼs being used for something relevant to the work at hand.

Before I came to Pivotal, I used my laptop to take notes. Once I got here, I quickly learned that while this practice may have seemed beneficial to me personally (and therefore the wider team who could read my notes later), it was actually doing more harm than good. First, thereʼs simply the sound of typing, a small, but real distraction that interrupts the flow of conversation. Then thereʼs the barrier it formed between me and the other teammates – literally a physical barrier and psychological cue that I was not connecting. And finally, it was an invitation for others to open up their laptops, which becomes a slippery slope of divided attention.

Easier said then done, but the solution was in fact simple: remove the distraction and close the laptop. It took me some time to adjust, because as a product manager a big part of my job is being the center of information for the team, but I havenʼt looked back since.

At Pivotal, we emphasize that meetings are for teams to connect and engage in healthy communication. We keep staffing lean and our meetings efficient, so it is essential that everyone stays engaged to share their important perspectives on risks and opportunities for minimizing them. Our conference rooms always have an ample supply of index cards, pens, and markers, and a whiteboard, so if somebody has a useful diagram or thought, itʼs easy to share with each other instead of squirreling it away in Evernote and missing a chance to expand on a great idea.

Of course there are exceptions to every rule, and I want to emphasize that there are times when a laptop is welcome at a meeting, even here at Pivotal. Sometimes we use laptops to project designs, site builds, or Pivotal Tracker, or to dial in a remote team member. But we always use it to collaborate and work together, and with full awareness of the purpose. And with distracting notifications turned off to keep the focus on the meeting.

Interested in testing the laptop free waters? Try it out for just the first ten minutes of the meeting. There are few emails that can’t wait that long. More importantly, you will realize how much clearer the meeting is, and how much easier the conversation is to follow. And stay tuned for more tips and tricks from the product management team here at Pivotal.

Tami Reiss is a product manager at Pivotal Labs, where she helps clients create software that connects people and technology in new ways every day. She is fascinated by the emerging physical computing trend and is an avid cyclist. Follow her on Twitter at @tamireiss and read more of her blog posts here.

Over the last week, Abhinav and I have been working on some enhancements and cleanup of LicenseAudit. For those that don’t know, LicenseAudit is a tool to track bundler dependencies, and their licenses. It is build on top of the license_finder gem.

The majority of the work was on stabilizing the code which resolves the dependencies, but we also managed to squeeze in a few new features, too. Most notably, we now support gems. The long term goal is to allow gems to have badges (in the same vein as travisci and codeclimate) which will show the state of the licensing information of a repo.

The other major feature that was added is designed to help with the adoption of LicenseAudit. If your app has been using the license_finder gem and you have your dependencies database checked in, the first time we audit your project we will import the data from the dependencies.db file.