May 31, 2014

Work by Keys and others propelled the American government’s first set of dietary guidelines, in 1980. Cut back on red meat, whole milk and other sources of saturated fat. The few sceptics of this theory were, for decades, marginalised.

I believe the word the author was looking for was margarinized.

March 5, 2013

Sandboxing is required by Apple to be on the Mac App Store. The technology has caused us and our users grief, cost significant development time, and likely lost our business users. This video shows one of the many bugs we hit after shipping Tumult Hype1.6, which was our first update to use Sandboxing. The bug appears erroneously as a permissions error when exporting as HTML5. It is caused when there is simply a space (or other escapable character) in the application path. Whoops!

February 26, 2013

If Apple wants to offer 4G in MacBooks, they can start whenever they want. Doing it properly will just take a bit more effort than adding a modem.

They can’t do it whenever they want. It requires new regulatory approvals as well as the much harder testing and certification with carriers (domestic and international). This would be required for each MacBook model.

Perhaps the Google Chromebook Pixel will force Apple’s hand to building it and dealing with all the red tape. Like Marco, I’d at least love for connection APIs to be in place. When tethering, I don’t relish that Software Update might be downloading big updates or Xcode is grabbing large docsets.

February 21, 2013

When Google’s Project Glass was first unveiled ten months ago, they wrapped up the announcement post asking the community, “What would you like to see from Project Glass?” Today revealed more about the unreleased product and continue the thread by begging for community involvement: “Using Google+ or Twitter, tell us what you would do if you had Glass, starting with the hashtag #ifihadglass.” Does Google not know what to do with the Glass?

Can you imagine if Apple announced the iPhone and said, “We’ve got a great always-on internet connected pocket sized device with a touch screen. What would you use it for?”

As Robert X. Cringely remarked in Triumph of the Nerds, for any new technology to gain acceptance, it needs a killer application. Most of the Glass’s features can be accomplished with a smartphone, and the convenience in the form factor is akin to a Pebble watch. By my read, Google has publicly admitted it doesn’t know what the killer app is for the Glass. Truly, the Glass is a solution in search of a problem.

This isn’t necessarily a death sentence. The PC itself didn’t have a killer application for many years until the first spreadsheet came along. With enough people excited (count me as one of them), perhaps an idea will emerge that puts Glass on the map before it is socially shunned out of existence.

Update: There’s been an argument this is a specific (and implied brilliant) marketing strategy. Google Glass won’t be given away for free. It is a consumer product, which will be sold. Sales happen when customers believe it will better their lives for more than the cost… so what is the value proposition which would make someone spend $1,500 for one? That’s essentially what Google is asking, but it is what they should be telling. That I won’t drop it on a roller coaster or when practicing Kendo isn’t reason enough. For a product in the shape of glasses, there’s a surprising lack of vision.

This is disappointing, because there will be a clock running on its life. If Google can’t find its value proposition/killer application soon enough, then customers will not buy it and developers will not spend time creating applications when there is no market. Given the lack of applications shown in the video, I’m a little surprised the glass site is so heavily consumer-targeted without any SDK information.

I’d love to try to answer the question what I’d do if I had a Glass. As noted the potential is staggering and few products have intrigued me as much as this. But my brainstorming is hits a wall when I think of practical constraints which need to be considered. What is the battery life? What is the resolution on the screen and camera? How accurate is the positioning information? What are the general latency characteristics of its sensors? And so forth. Creativity lives on the ground, not in the sky.

Apple doesn’t dictate experiences, but it does communicate uses for the product. Remember the original iPhone ads? Given how new the device and technology was, this seemed wise to me (say, compared to the iPod silhouette ads — everyone knows what a music player does). The Glass is in the same category — something entirely new.

December 30, 2012

“Make your own luck” is a great philosophy to have on the world. It emphasizes a forest-scoped perspective for being at the right time and places conducive to exciting new opportunities.

I’ve recently considered the less optimistic flip-side. If you said, “accidents happen,” a counter would be, “not if you are careful.” In other words, don’t make your own misfortune.

Unnecessarily increasing the probability of an accident invites bad luck. Perhaps it is weaving through traffic instead of staying put in your lane. Next thing you know, you’ve collided with a car in your blind spot. Or it could be leaving a hot kitchen stove unattended; the apartment is burning down.

In poker, when you’ve been getting terrible cards all night it becomes easy to convince yourself that a mediocre hand is worth playing. But this too is making your own misfortune. Others will be playing better hands and once you’ve hit middle set it is painful to let it go. But you’ll lose, and it is all because you put yourself in a situation where there was a difficult choice, and then chose wrongly. Put yourself in situations with easy choices.

This doesn’t mean being risk adverse, but making sure your priorities are straight. Is it worth increasing the chance of death to get to a party 5 minutes quicker? The principle applies to issues aside from safety as well.

When programming, you could have an easy performance win by multi-threading a critical section. But down the road you’ll be inviting dead locks and race conditions when another engineer begins working on the project and doesn’t have their head fully around the codebase.

It may be an art to understand complexity tradeoffs, or perhaps it just takes experience. But it could simply require reflection – how might you be making your own misfortune?

November 15, 2012

CSS Filter Effects are the new hotness in Safari 6 and iOS 6, and have been around since Chrome 18. The blurs, shadows, brightness/contrast, hue shifts, and saturation shifting will add a new dimension of visual oomph to sites. However, one aspect to be aware of is they do not render consistently across different browsers. The look you’ve fine tuned on Chrome may be hideous on Safari. Not only do Chrome and Safari render differently, but Safari renders differently than itself! That is, when applying a 3D transformation, the graphics accelerated rendering path will appear differently than the non-accelerated path. It is common to use a “-webkit-transform: rotateY(0deg);” as a way to hack Safari to the faster rendering path. Chrome does not suffer from this issue, and looks consistent across Mac and Windows. Interestingly, the effects with MobileSafari on iOS are nearly identical to Chrome.

Here’s the same effects (sepia, saturation, hue shift, brightness and contrast increase) viewed across different browsers:

If you’re only targeting one platform (or sure it will only use a specific rendering path in Safari), this should not be a problem. Otherwise make sure to test across the different browsers which support the effects. As of writing this post, Firefox, IE, and Opera still do not support them.

October 20, 2012

I recently gave a short talk at HTML5DevConf called “Best Practices for Building Tools that Output to the Web.” The session covered some of the assumptions you can’t make if the output of your tool is going to be used as part of a larger site. I also dived into some concrete decisions and implementations we used for Tumult Hype.

October 13, 2010

Automation is a bedrock of software engineering. Tools, scripts, tests, and even reports are vital glue that keep projects progressing forward. Because time spent on automation generally detracts from product work, it is considered an investment. Sadly, more often than not I see an erroneous equation applied to determine whether the investment will be worthwhile:

(manual repetitions * time) - (time to develop automation) = value

If the value is positive, the automation is a green light. Otherwise, is it really a waste of effort? There are many factors not being considered.

Automation is less error prone.
Processes are put in place to account for human error, so why add another layer where humans can go wrong? Computers won’t forget to strip symbols before deploying or test a feature used by thousands of people. Automating processes adds a known and reliable security blanket so engineering can proceed with confidence.

Automation can be run any time, without humans in the picture.
Need test results at 11pm? No problem. Your build engineer is out with the flu? The latest revision has already been built! If you need 100 runs through a test plan in a day, the computer won’t complain. Automation is tireless.

Automation can be run at a high frequency.
Just as high frequency trading has changed the stock market, the ability to run scripts and tests more often can have a transformative effect on your processes. Having a packaged build always generated means others in your company can easily live on the latest bits or send one-off builds to users to make sure issues are fixed. Running unit tests on every commit will allow you to immediately pinpoint what code caused a regression instead of having bugs piling up. Older bugs are more expensive; it takes engineers more time identify and ultimately fix when they aren’t as familiar with the code. The same principal can be applied to higher level/UI tests and performance testing.

Automation can build on itself.
Writing an automated test is only the first step. Once you have tests, you can write infrastructure to kick these off. Then write tools to aggregate results. Next is generating reports. Complete the circle by automating emails of the reports to yourself and managers. Each step along the way may have a different return, but they are paved by the previous steps. This ultimately leads to an invaluable end-to-end workflow.

Automation is more fun!
Who rejoices in manual labor? Developing automation is a challenging activity and a great way to engage those on your team who have been burnt out by boring repetition. Each time a script is run, they’ll smile in knowing they’ve saved themselves time and work. This encourages even more automation to be written.

The next time a simple equation is levied against automation, be sure these factors are also considered. Of course, for some domains automation is not appropriate or prohibitively difficult. It is less flexible when encountering ambiguous inputs and falls down at doing anything ad-hoc. Automation must also be maintained and kept up-to-date. All said, from my experience the teams with effective automation setup are also those in the least technical debt and can be bigger risk takers.

To wrap up, please observe this discussion between an engineer and his manager:

Kirk: Scotty, progress report?
Scotty: I’m almost done, sir. You’ll be fully automated by the time we dock.
Kirk: Your timing is excellent, Mister Scott. You’ve fixed the barn door after the horse has come home.

Note, the manager now realizes the value of automating as quickly as possible!

October 18, 2009

Programming is not mindlessly implementing specs nor is it determining the best big-O algorithm for a mathematical problem. Programming is art; turning raw code into an implementation of your ideas. Programming is what you do.

Software Engineering is what your company does. Software Engineering figures out the most efficient and profitable way to develop a product. Software engineering is as much about people, process, and schedules as it is about data structures and protocols.

Here’s the scene: you’ve just gotten a great idea on some new feature, and you’re discussing it with your [software engineering] manager. He’s1 enthusiastic, and then, like clockwork, the question comes:

“So, how long will it take to implement?”

The answer is two weeks.

From his perspective, three weeks will mean it is a large task with many variables, likely to take four. Telling him four weeks will make him question whether the project is worthwhile as there are other tasks you are needed to do. Five weeks will signal that you are incompetent. Bringing up the M-word (that’s “months”) will be a sure-fire way to lose his support.

If the feature is doable with one week’s hard work, you should still say two weeks. One week will set you up for coming in late — there may just be those variables you didn’t anticipate, or there could be another issue that comes up and sidetracks you. The extra padding can also give you time to refine your design as it develops and make a better demo. If you are able to finish in less than two weeks, you’ll look that much better.

Don’t worry, two weeks will work. Programming is art, and you’ve already got the picture in your head. A tight schedule will force you to improve your engineering by making the necessary tradeoffs without falling into a perfectionist trap. If you work really hard and stop checking facebook, you can work 12 hours a day for the next 14 days. This will give you 168 hours or the equivalent of a little more than 4 real weeks; plenty of time. Remember, you don’t need to deliver 100% of the feature in this period of time, only the easiest 80%. If the feature turns out great, you’ll have time to later refine.

Two weeks is also the average period between meeting times, so it is unlikely you’ll need to give an impromptu and risky demo. At this next meeting, you can impress your manager with the end result; it always looks good to show something. If the feature gets nixed, you will not feel that you have wasted a significant chunk of your life.

If other tasks on your plate will prevent you from immediately starting on your feature, you should not add this into the time estimate as the mentioned negatives will apply. Instead, split it up: “I can get started in two weeks, and it will take another two weeks after that.”

There are two main scenarios where you do not want to commit to two weeks:
1. A small project which should be measured in hours.
2. A large project which should use two weeks as milestone markers.

To wrap up, please observe this discussion between an engineer and his manager:

Kirk: Scotty How long will it take you to have everything automated?
Scotty: Oh, six weeks Captain, but yah don’t have six weeks so I’ll do it in two.
Kirk: Mr. Scott have you always multiplied your repair estimates by a factor of three?
Scott: Of Course Captain, how else would I keep my reputation as a Miracle Worker?

[1] Replace he/his with she/her if your manager is a woman.

May 30, 2009

From April 5th to May 2nd, I took the trip of a lifetime to Japan. Being there for such an extended time, I had a list of sites I wanted to hit, but often found the most joy from simply stopping at a tokyo subway station and wandering around; I’d often encounter shrines, museums, amazing restaurants, or just find myself in awe of the architecture. I created a site that has photos and video of my adventure:

The photo site is best viewed in Safari 3.2+. In looking around, I found no web galleries/albums adequate to convey my trip and also allow me to quickly lookup pictures. Most galleries are also pretty ugly too; just a simple grid of photos so I sought to make it the digital version of a bound album.