Wednesday
Nov232011

Better code searching with ack

Have you ever needed to find all references to a certain Apex class across an entire code base? If you're a Force.com developer, I'm sure you have. And what if you're not in the Eclipse-based IDE...perhaps you're using the Force.com Migration tool on the command line? I'm guessing you've used a tool like grep.

While grep is still the gold standard, recently I've been using another tool called ack in its place. The ack web site defines it as "designed for programmers with large trees of heterogeneous source code." I've found it to be significantly faster at searching through files, and also has a clean, simple way to search within only certain types of files.

Example

Let's say I installed the LinkForce app into a developer edition org and wanted to explore the code. After setting up this org's code in a new Eclipse project, I can navigate to the workspace directory on the command line and run the following:

ack Short_URL__c

So, again, the above command outputs a simple list of all files that reference that particular Custom Object.

That's pretty good, but let's imagine what I really want is to find custom code (Apex and Visualforce) that refers to that object. Rather than piping the output of a separate find command as an input, I can simply execute the following:

ack --type=apex Short_URL__c

I've configured a file type called apex that ack interprets as Apex Classes/Triggers and Visualforce Pages/Components. This way, I avoid superfluous search results like the definition of the Custom Object itself. ack natively understands many common file types, and can easily support any number of custom types.

Oddly enough, a blog post can't illustrate one of ack's greatest strengths: speed. If you search through large source trees often, you'll be amazed at how quickly the results are returned. The vast majority of my searches complete in less than one second.

Installation

The main ack web site has information about how to install the tool, and I actually used the AckMate plugin for TextMate since I'm a Mac user. In addition to enabling ack as the search tool within TextMate, it's possible to use that same script on the command line by creating a special symbolic link.

The Force.com-specific configuration I created can be found on GitHub as well.

The first line defines the apex file type as consisting of Apex Classes, Triggers, Visualforce Pages and Components. The second line defines another type simply called force for other metadata like Objects, Apps and Profiles. You can treat this as a starting point and break out more or less file types to include Workflows, Page Layouts, etc. Finally, the third line of the configuration specifies that search results will be presented one page at a time using a command line tool called less (which also supports color coding).

Conclusion

If you develop on the Force.com platform and find the command line more efficient, ack can really speed up your work. I'd encourage you to try it if you've never ventured beyond what Eclipse offers.

Friday
Oct282011

Citibank: Your touch targets are too small

If anyone from Citibank can read this, please refer to Luke Wroblewski's blog post detailing appropriate touch target sizes.

Citibank Online's mobile login

Compare this to the mobile app for Meebo, a popular multiprotocol IM client:

Meebo's login
Saturday
Sep102011

Building and distributing a Force.com ISV app

Last month, at Dreamforce 2011, I had the privilege of speaking to an audience of people thinking of building a commercial software product on Force.com. Since my company helps this specific market, I was asked to co-present with someone from Salesforce's marketing group that supports these people in their efforts.

This article is a summary of the material I presented. Here's a high-level outline:


  • Building Your Team and Your Knowledge

  • The Build Process: Technical and Licensing Concerns

  • Stories From The Field

  • OK, Let's Get Started

I represented the perspective of "someone who's been through it." To steer clear of legal issues, I'll omit details of the content presented by the other person. Here's a simplified version of my slide deck, with an explanatory article below.


Think Different(ly)

I began with a show of hands asking how many folks in the audience had an iPhone or an iPad. Luckily, I had a significant number, so I was able to use my analogy comparing Force.com development to iOS development. Both types introduce significant new elements.




































New element Force.com iOS
New programming language Apex Objective-C
New APIs/runtime Apex Standard Classes and Visualforce hosted in the cloud Cocoa on iOS
New UI conventions Salesforce.com CRM and Service apps set the tone Touch interface, Apple's HIG
New distribution models App Exchange App Store
New quality processes Security Review App Store Review

These new elements necessitate a shift in thinking from traditional Java or .NET development—one which starts in design, affects coding and extends into sales. Directly "porting" an existing application concept to Force.com would be no more successful than porting the entirety of Microsoft Excel to the iPhone. There's a different definition of what makes an app great.

Concrete Examples

Let's take the example of building a simple blog system that organizes Articles into one or more Categories: Force.com's object database causes the fundamental data model to include notable differences. The Categories are defined as a first-class attribute of the Article, rather than as a separate table (requiring yet a third junction table). Moreover, this structure allows the system to render an appropriate UI to assign an Article to multiple Categories without any custom code.

Force.com also includes a major difference at the user interface level: a native, out-of-box UI that matches Salesforce's CRM and Service apps. The interaction and visual design of most Java or .NET apps will start with a blank slate. The default UI may or may not be a great fit for your app, but in either case it's worth respecting the conventions to which Salesforce users are accustomed. Reducing friction for end users will drive adoption and word-of-mouth referrals.

Look Beyond Development

The Force.com platform is broad and deep; launching an app on Force.com is definitely standing on the shoulders of giants. Hence, it's possible that the engineering effort to build an app is actually less than you imagine. That said, most folks with a development mindset don't plan sufficiently for the work to distribute the app. Working through the Security Review process and listing on the App Exchange are activities that require time and planning.

It's natural to "go with what you know" and focus on simply building the app. Unfortunately, that's not the finish line. ISVs would be well-served to start planning for non-development activities sooner rather than later.

The Role of the PDO (Product Development Outsourcer)

Salesforce refers to my company as a PDO (Product Development Outsourcer)—we can design an application, handle the development and help a client through the work of launching onto the App Exchange. On the majority of our prior engagements, we've done the lion's share of the development.

Over time, however, the client team ramps up and takes over. As a corporate asset, the app is their intellectual property and it's critical to assemble a team with the skills necessary to be a successful software company over the long term. This includes not only development, but also related functions like customer support and product management.

Our model is not to become "embedded" as a vendor for many years. In fact, we're thrilled to hear success stories from former clients who no longer need our "training wheels."

OK, Let's Get Started

If you're an ISV that's ready and willing to head down this path, how do you begin? It's actually quite simple: our usual process is to meet with you and have you explain the long-term vision of your application. We need to understand your definition of success. Then, we'll discuss any tricky requirements in a little more depth, go back to our offices and reflect on everything we've learned. Finally, we develop an overall design concept of what it would look like to host your app within Force.com, and we share the concept with you to get feedback.

It's analogous to meeting with an architect to design a custom home, describing what you need, and seeing an initial sketch. Almost all the elements in the design are still negotiable, but the sketch gives you confidence the architect understands your end goal.


Architectural sketch

Most often, our initial sketch takes the form of a concept model. Once you're comfortable with what you see, we'll begin a formal planning process and design phase to capture and spec out all the specifics. After the design phase is complete, we scope the actual development work.

Conclusion

If I could choose to have the audience remember only one idea from my presentation, it would be this:


Prior experience building software will help you succeed on Force.com, but don't expect to do things the way you've always done them. Embrace the change.

If you're interested in discussing this topic further, please leave a comment or get in touch privately. I'd love to talk to you.

Sunday
Aug142011

A Tufte-style take on an infomercial graphic

A few weeks back, I attended Edward Tufte's one-day seminar on visualizing information. The course is a great overview of his theories on designing effective charts, graphs and any other type of imagery needed to explain complex data. I'd recommend attending if you do any design work or process numeric data.

The next weekend, I spotted the informercial for the Ab Rocket Twister on a TV at a restaurant. The volume was all the way down, so I had only the visuals to sell me on this product. The messaging was mostly the typical nonsense used to sell home weight loss machines, though they included one particularly egregious graph:

Double muscle activity!

I'm seeing things through Tufte-colored glasses now, so I decided to see how the Ab Rocket Twister's sales pitch holds up when subjected to his six Fundamental Principles of Analytical Design.

  1. Show comparisons. Well, we can see the Ab Rocket Twister generates 107% of the muscle activity of standard floor crunches. The text notes that's just over double, though the red bar looks to be about 3-4x as tall as the yellow bar. (3D helps muddy the waters.) Confusing matters further, "107%" apparently represents a 107% increase, or else it wouldn't be "double." 107% of 100 is only 107, whereas double would be 200.
  2. Show causality and explanation. By itself, this image shows essentially zero explanation of why these results are obtained. There are two pictures of a man exercising (one for each method), but that doesn't tell you why you'll get better results.
  3. Show more than one or two variables. We could assume that the experiments generating this data have controlled for other factors, but that's not stated. What about the possible effects of changing your diet?
  4. Integrate words, numbers and images together. Words, numbers and images all definitely appear here. However, it's hard to argue it's an effective integration. The scale of the bars is definitely suspect, and the concentric circles at the base of the bars strike me as particularly ridiculous. What is that designed to show?
  5. Thoroughly describe the evidence. Earlier in the commercial, it's mentioned that "university testing" generated this data. Unfortunately, there is a complete and total lack of information about how and where this testing was performed.
  6. Ultimately, the message stands or falls on the quality and integrity of the content. Is this information true? Perhaps, but the word "integrity" doesn't exactly spring to mind, especially given the aforementioned errors and generally cheesy production values displayed in the rest of the commercial.

Overally, this is clearly a weak information graphic. But how could it be improved? When I've made design mistakes similar to these in the past, it's most often rooted in not having enough hard data in the first place. In that case, a heavily "designed," full screen visual simply isn't warranted.

We only see one number in this data set, so one idea worth exploring is what Tufte refers to as a single-number semi-table. That being said, I still don't think I'll be ordering an Ab Rocket Twister anytime soon.

Sunday
Aug142011

Make a simple "torn" screenshot effect in Keynote

When I'm creating wireframes or mockups, I occasionally have the need to include a very long page that would require scrolling in the browser. However, I like to keep my mockups to a reasonable size to make them easier to consume. My solution is to "tear out" a redundant part of the page, and I've figured out how to achieve this effect in Keynote.

Here's a visual explanation of how I did this:

Making the core shape is suprisingly easy in Keynote. You can start out being sloppy, and then align the corner points to make perfect right angles by watching for the yellow guides to appear as you drag the points.