I recently had the need to think about and articulate a few things about the security characteristics of an API, and I realized that my decisions are sort of ad-hoc: I really need to write them down. While security can be bypassed by determined hackers, an API should always have some basic guards in place. So here are my principles of API security.

1. Authorized caller

An API should accept only authorized callers.

  • If it is an API with known clients, then it can secure based on IP address
  • If clients are unknown, such as a mobile app, then the API should include tokenized authentication headers constructed using an algorithm

2. User restricted

If an API is acting on behalf of a user, then the database and API should restrict itself to actions authorized for that user.

3. Server secured

An API should never depend upon a client for any security.

  • It should not depend on a client to parse a receipt to determine what products were purchased
  • It should not deliver secure data and depend on the client to know when to show or hide that data

4. Secure logging

An API should never store confidential information in a log, such as passwords, email addresses, etc… Your logging functions should filter out that information before storing it.

There are plenty of other things you can do to increase the security of an API and its data, such as encrypting certain data or implementing certificate pinning. It goes without saying that an API should sit on an SSL server, and you should never store passwords – only a hash of the password. But I feel if you follow these 4 general API security principles, your API projects will be successful, and you won’t be getting those high priority bug tickets because Bob can somehow see Joe’s data!

Forest Flight is my first iPhone game. It’s localized in 10 different languages.

Fly your bug through five forests, avoiding or shooting down spiders and bats. Earn up to 3 simultaneous shots and use 1 huge shot per level.

Swipe up to fly up and back, swipe down to fly down and forward. Tap to shoot, and press and hold to fire a Big Shot.

Unlock levels when you finish the previous level, or purchase Chaos to unlock all levels, use up to three Big Shots per level, and play trillions of Chaos levels on Easy, Medium or Hard, created with the unique, built-in Randomizer Engine.

Includes the ability to disable sound effects or music for quiet play, and localization in 10 languages.

View in the US App Store

For support, enter your question or comment below.

My former Intuit Innovation Lab boss, Jana Eggers, posted a tweet today about the IBM Watson X Prize. No surprise there since she’s the CEO of Nara Logics, an AI platform company here in Massachusetts. The X Prize is to encourage the use of AI to help solve society’s big problems. I spent a few minutes googling around to see what people were saying were society’s big problems, and some of the ideas around using big data for solving some of these things.

The problems and solutions I read about were interesting, but not related to my own areas of expertise. However, I did realize something that was, and it all goes back to what I learned in the iLab. I know how to approach a problem, even a seemingly insurmountable one, in ways that may have been overlooked.

So I don’t understand AI systems, although I did once write a learning algorithm to solve a magazine’s puzzle – a brute force path approach that remembered bad paths, so was less likely to try it again. (It did solve the puzzle in about 30 seconds on an old PC.) To me, AI is maybe looking for correlations in data? I realized it’s something we humans do all the time, just slowly and with only a little bit of data.

In the iLab, we looked for surprises – things that were wrong in the data. Everybody will choose the bank with the best rates … but they won’t switch. Estimating is about getting the prices correct using the most up-to-date databases … except it’s the data flow that’s hard, not the prices.

It got me to thinking about AI. Could it look for high-certainty conclusions that were wrong in real life? Could it model what we did in the iLab, such as finding “Creative Rainbow” approaches to resolving problems? I’ve taught creativity techniques that can be done by anyone, even us non-creative engineer types. Could those be taught to a system? What solutions do humans try today to solve some of these problems on the small scale? Could those solutions be applied to society at large? Maybe it’s not about finding solutions, but about applying solutions. Perhaps the AI can find analogues in the successes of other societal transformations, and suggest those analogues as methods for applying the small-scale solutions.

Could Pokémon Go solve poverty?

Maybe the X Prize will go to the team that can teach a computer how to look at data with a creative camera.

Ask me about Unit Testing and I’ll probably say, “nice to have”. Unit tests are very nice to have … but sometimes the project schedule doesn’t include time to build the unit tests — which often take nearly as much time as writing the functional code. But when I have time, I really like good unit tests.

I’ve never found a PHP unit test framework that I like, so I roll my own. It’s evolved over time from “call functions and see if they fail” to “test all scenarios and track complete coverage”. Here’s the basic framework I use:

  1. All PHP files can conduct their own unit tests by simply executing them from the command line, e.g.
    • ]# php Project.php
  2. A script will run all unit tests
    • ]# ./unitTests.sh
  3. All PHP functions declare their usage so that coverage can be tracked

A “hello world” class of mine looks something like this:

require_once('unitTests.php');
class HelloWorld {
  function findWorld() {
    unitTestCoverage(__METHOD__);
    return "Earth";
  }
  function findGalaxy() {
    unitTestCoverage(__METHOD__);
    return "Milky Way";
  }
}
// Unit Tests
doUnitTests_HelloWorld();
function doUnitTests_HelloWorld() {
  // Only run tests when executed from the command line
  if (!(php_sapi_name() == "cli")) return;
  // Only run tests when it's THIS file that's executed from the command line
  global $argv;
  if (pathinfo(__FILE__, PATHINFO_FILENAME) != pathinfo($argv[0],PATHINFO_FILENAME)) return;
  // Create coverage arrays
  global $__localAllCoverage, $__localCoverage;
  $__localAllCoverage = [
    "HelloWorld::findWorld"
    ,"HelloWorld::findGalaxy"
  ];
  $__localCoverage = [];

  echo "HelloWorld.php unit tests\n";

  $msg = "findWorld test";
  $hw = new HelloWorld();
  if ($hw->findWorld() != 'Earth') {
    unitTestFailed($msg,[$hw]);
  } else {
    echo "Success $msg\n";
  }

  $msg = "findGalaxy test";
  if ($hw->findGalaxy() != 'Milky Way') {
    unitTestFailed($msg,[$hw]);
  } else {
    echo "Success $msg\n";
  }

  $diff = array_diff($__localAllCoverage,$__localCoverage);
  if (count($diff) != 0) {
    unitTestFailed('Tests did not have complete coverate.',[$__localAllCoverage,$__localCoverage,$diff]);
  }

  echo "\n\033[32m Success! \033[0m \n";
  exit(0);
}

And the unit test functions in unitTests.php look like this:

function unitTestCoverage($__f) {
  if (!(php_sapi_name() == "cli")) return;

  // Running unit tests!
  global $__localCoverage;

  if (!in_array($__f,$__localCoverage)) {
    array_push($__localCoverage,$__f);
    echo " .. {\033[94m" . end($__localCoverage) . "\033[0m} .. ";
  }
}
function unitTestFailed($msg,$data) {
  foreach ($data as $d) {
    print_r($d);
  }
  echo "\n \033[31m FAILED $msg \033[0m \n";
  exit(1);
}

In my script that runs every unit test, I check for the failure exit codes:

#/bash/bin

cd www/api/classes

files[0]=HelloWorld.php

for i in "${files[@]}"
do
  php $i
  if [ $? -ne 0 ]
  then
    echo -e "\n\nFAILURE in ${i}\n"
    exit 1
  fi
done

echo -e "\n\nALL TESTS PASSED!\n"

exit 0

I hope you like this framework as much as I do! It has ensured full unit test coverage and cut way down on bugs that get to a test or production stage.

I’ve finally removed the BlackBeltVB.com website, but kept the domain name. You can download all the examples here.

BlackBeltVB.zip

03With iOS 8, getting the right launch screen has become a real pain. If you support only iOS 8, and you don’t need iPad, or everything is Portrait or some such, you’re fine.

With one of the apps I work on for Five Pack Creative, I need to support Landscape-only, iPad and iPhone, iOS 7 and 8. And man, getting the Launch screen correct has been tough. There are several choices — launch image catalogs, a launch nib/xib, and launch filenames. For Landscape, both types of device, both iOS versions, I’ve only found one approach that works for sure.

First, for iOS 7, you need to use the filenames approach. If you have any entries in your Info.plist related to launch screens, delete them. Just use the standard filenames.

  • Default.png : 320×480 rotated — not used, but it’s the base filename
  • Default@2x.png : 640×960 rotated — for the iPhone 4, 4s on iOS 7.x
  • Default-568h@2x.png : 640×1136 rotated — for the iPhone 5, 5c, 5s on iOS 7.x
  • Default-Landscape.png : 1024×768 — for the iPad 2 and Air
  • Default-Landscape@2x.png : 2048×1536 — for retina iPads

Don’t use an Asset Image Catalog for iOS 7!! Just create a folder, then add those screens to your project, creating a Group for the Folder as they are copied in. The folder will be created under your project. This is IMPORTANT — don’t just drag in individual screens. It’ll work, but not when you have another target, e.g. a free version and a paid version of your app. You’ll need the exact same filenames with different images for the various versions of your app. Putting them in differently-named folders before adding the entire folder (and create a group) works best. DON’T use Folder references — iOS can’t find your launch images if they are under a folder reference — it must be a group.

Now, for iOS 8, you’re going to use a Launch.xib file and asset images. I’ve seen places where people assert that you can use filenames, manually editing your Info.plist. I guess that approach works for them, but I couldn’t get it for my specific situation. Using their solutions prevented iOS from properly detecting an iPhone 6 — it ran it in scaled iPhone 5 mode.

Create a new launch screen (File, New File, User Interface, Launch Screens). Add that to your target settings (Project, Targets, General, Launch Screen File). Select the XIB and add an ImageView to the View. Size it to match the View, then make sure you have the proper Size Class selected before adding Constraints. You want Regular/Regular (iPad Landscape).

ConstraintsWith the ImageView selected, select the class using Editor/Size Class/Regular Width/Regular Height. At the bottom of the Interface Builder screen, you should see “wRegular hRegular”, indicating the size class you are editing. Add the constraints by Ctrl-Drag from the ImageView to the View. Hold the Shift key to select multiple items — Leading, Trailing, Top, Bottom. That should create your constraints with zero as the constants. Don’t worry about the View (frame) height and width — your size class images will take care of all that.

So now you need images for your ImageView. You are going to use some of the same ones. First, if you don’t have an image asset catalog for your specific target, add one (File/New File/Resource/Asset Catalog). Add a new set (click the + button) and call it Launch.

Okay, now for the really cool part, and where it all comes together easily. When you added the Launch image set (not to be confused with a Launch Image Source setting in your Target — we could have called it “Monkeys” instead of “Launch”), you’ll see 3 spots for images (1x 2x 3x) and underneath, “Universal”. Over on the right sidebar, you should see Devices, Width, Height, etc… Change Devices from Universal to Device Specific, and select iPhone, Retina 4-inch and iPad. Change Width to Any & Regular.

Now you should have two sections: iPhone and iPad, and two rows of boxes.

Launch-assets

All you have to do now is fill the boxes with the appropriate images, and you’re done! The [* *] and such have specific meanings. The documentation is very good for this — https://developer.apple.com/library/ios/recipes/xcode_help-image_catalog-1.0/chapters/CustomizingImageSetsforSizeClasses.html.

  • 1x [* *] iPhone is a landscape 480×320 — same as Default.png, but not rotated.
  • 2x [* *] iPhone is Default@2x.png, not rotated
  • Retina 4 2x [* *] iPhone is Default-568h@2x.png, not rotated.
  • 3x [* *] iPhone is 2208×1242.
    • The [+ *] versions are exactly the same — but you have to copy it into both!
  • The iPad files are 1x Default-Landscape.png, 2x Default-Landscape@2x.png — for both rows.

Now go back to the ImageView on your Launch.xib and give it the filename Launch.

Woo hoo! Everything works, and all your devices come in with the correctly detected resolutions and launch screens. Note that you can check the resolution like this:

CGSize uiSize = [UIScreen mainScreen].bounds.size;
if (uiSize.height > uiSize.width) {
  // iOS8 returns bounds based on orientation
  CGSize rotatedSize = CGSizeMake(uiSize.height, uiSize.width);
  uiSize = rotatedSize;
}
switch ((int)uiSize.width) {
  case 736:       // iPhone 6 Plus   736 x 414
  case 667:       // iPhone 6        667 x 375
  case 568:       // iPhone 5s/5     568 x 320
  case 480:       // iPhone 4s/4     480 x 320
  default:       // iPad
    break;
}

I enjoy watching “reality documentaries” such as Alaska: The Last Frontier, Mountain Men, Yukon Men and Ice Lake Rebels. But I really don’t like “fake” shows, especially when they go out of their way to seem real.

That’s why I stopped watching Dual Survivor. Without Cody Lundin, the show lost its credibility in my eyes. I usually watch a show or two, then do some research to find out how legit it is.

Alaska: TLF and MM are, as far as I can tell, solid and real. I haven’t researched Yukon Men yet.

Today, I researched Ice Lake Rebels. The first thing I checked was the “remoteness” factor. The show portrays the people as far from civilization, far from help and resources. I was disappointed to see that they were within walking distance (or rowing if the lake wasn’t frozen) of a fairly large city. They can probably hit the Canadian equivalent of a 7-11 for a box of Twinkies. Check out the picture below – that island at the top right is the one on the show.

image

The city of Yellowknife is right there. In this case, I don’t think less of the people on the show, unlike the apparently very fake and scripted Alaskan Bush People. But I do think that the producers are being a bit deceptive. Some shots are high views of the island, and the developed mainland next to it are blurred, obscuring the docks and boats and buildings.

That’s NOT good television… but I am still watching the show. The Rebels clearly face some real dangers and some tough conditions. But I’m watching a bit more… skeptically than before.

EDIT
I did quit watching quite a while ago. It took a couple more shows for me to decide Ice Lake Rebels most likely wasn’t real.

I think scripted reality shows belong on network/dramatic television, NOT on purported “science” channels like Discovery, History or TWC. ILR has been replaced with Prospectors on TWC for me. 🙂

Overwhelmed I’ve been driving organizational change in Scrum implementation for more than a year in two companies, and I’ve reduced the focus of change to 4 steps. And in keeping with Agile principal #10, I won’t be writing a long preamble :-).

1. Effective Scrum Masters

A Scrum Master is a process expert, a coach, a disciplinarian, and great at managing their own time.  If you want to know if a person will be a good SM, look at their Inbox. Is it one or two pages, or is it a hundred pages with thousands of unread messages?

My time management process can be boiled down to just a few principals and techniques:

  • 24 hour response on all emails
  • If it’s read but still in my Inbox, then I have an action to take
  • In meetings, my notes will result in actions: either paper notes with a ☆ star, indicating something to do, or electronic notes that I email to myself
  • Schedule a no-duration appointment so that I am reminded of actions to take

Using this technique, I’ve kept my Inbox clean, my notepads blank, and an expectation with my colleagues that I respond in a timely fashion to questions and requests.

Your Scrum Masters must be effective time managers. They are responsible for coordinating Sprints and ensuring planning gets done correctly. They must track implementation of retrospective items. They need to make sure dependencies are resolved, schedule Sprint Review/Demos far in advance. And they are often doing it for multiple teams, or otherwise doing other project work of some kind.

Your Scrum of Scrums Master must be an expert at this, coaching and keeping watch to ensure the Scrum Masters keep up with the work.

2. Principled Scrum

Organizations are different. Their needs vary. Managers want different types of information, results, and plans. Some people will be all for Scrum, others will resist it. You’ll have Q/A on your teams… or maybe not.

It’s okay – adjust how your organization implements Scrum, vary from the “orthodox” methods — but never compromise on Agile Principles. Your Scrum Masters need to know the Agile Manifesto and the 12 Agile Principles. That way, whenever a change is suggested or challenged, you can check it against Agile. Changes are fine, they’re great, they’re desired and expected: just don’t compromise on Agile or you’ll end up back where you started.

3. Acceptance Criteria is King

Nothing slows a team more than stories that lack good acceptance criteria. For the teams I coach, I have one test I use to see if the acceptance criteria is good:

  • How will you know if the developer did the work correctly?

What, exactly, are you going to do? What will you type/run/examine? Can you actually DO the test, or does it require other steps not in the story?

If you, as a Product Owner, as a Developer, cannot absolutely show that the story is working, by executing the steps in the Acceptance Criteria, then it’s not a Done story, and/or the acceptance criteria is flawed. Here are some flawed acceptance criteria items that I’ve seen get into a Sprint:

  • As a Thing, I get built
  • As a Platform Feature, I get refactored
  • As an Engineer, I researched and documented a design
  • Code is written and reviewed

Your acceptance criteria should be detailed: enough so that a developer can execute it or a tester can run it. Browse to the site, enter login credentials, click on the new feature, shows the new stuff. Without this detail, engineers cannot create good definitions of done and the team cannot estimate the size of the story. And worse: developers and product owners will have meeting after meeting to understand what needs to be Done.

4. Interfacing with other teams

Probably the biggest challenge I’ve seen to date is figuring out how to work with requirements outside of your own Scrum team. Within the team, it’s pretty simple to setup priorities for stories: just get them into the Sprint in the right order. It’s easy to track dependencies on stories: you know every day at the Daily Scrum whether there’s a story or task at risk. But what about between teams – both other Scrum teams and non-Scrum teams?

I call this Dependency Tracking. Or sometimes Dependency Management – something with the word “dependency” in it. Other teams have dependencies on you, and you have dependencies on other teams. Stuff they need to do must get done in time for your Stories, and vice versa.

There are three steps to perfect dependency tracking:

Dates: Every request, every dependency must have an actual date : When will it get resolved? When can you give me a date that it will get resolved? When can you give me a date where you’ll be able to give me a date? Never accept anything other than a solid date. And don’t accept dependency resolution dates too close to the end of your sprint. Aim for the middle.

Tracking Tickets/Tasks: Even when you are given a date, don’t absolutely trust it. Create a tracking task or story that’s due just before the dependency, and put it In-Progress: that way you’ll see it at every Daily Scrum. A tracking task is basically “Make sure that X dependency will be resolved as promised on mm/dd.”

Proactive Communications of Changes: Your team will often be a dependency for other teams: you must make sure that anyone dependent on one of your stories gets notified if you aren’t going to make your committed dates. As a Scrum Master, you need to track which of your stories are dependencies, and when they are expected to be Done. If they aren’t going to be Done by the committed date, inform the stakeholders! Stuff happens, people understand that. Let them know if a ticket will be late, and give them the new date. That way everyone has an opportunity to re-prioritize and ensure their teams aren’t sitting around blocked by your dependency.


Questions? Suggestions? What’s the key to effective Scrum in your organization?

 As I’ve worked building the Cartera OfferLink app on iOS, I’ve learned a little about Apple’s Push Notification service. One thing that I wanted to do from the start was avoid sending a notification when someone might be sleeping! Every once in a while, I’ll get a text message early, like 6am. I’m a late sleeper, and the BUZZ! that my phone makes will always wake me.

I really don’t like that.

So I decided early on that I’d do the best I could to avoid sending messages at inappropriate times. I know you can change your phone settings to avoid notifications at certain times, but the default – and most folks devices are set to the default – is to just deliver the message when it arrives, buzzing and binging and waking you up.

What I did with OfferLink is send the current time, local to the phone, to the server, along with its data requests. Then I calculate the seconds offset from the server and the phone’s time. This gives me the current time zone of the phone as of that request.

It’s not a perfect system – the user could fly around the world to a different time zone, and get a notification before the app refreshed its data and told the server its new time zone. But it should be a good 80/20 solution – solving for 80% of users.

// (pseudo code for handling the time zone)
localTime = time();
remoteTime = localTime + tzOffset;
if (hourOf(remoteTime) > 8 && hourOf(remoteTime) < 22) doNotify();

Please be kind to your users – handle push notifications in such a way that you don’t annoy them.

Or wake them up.

 Thought I’d take a second to recommend Blitz.io – a cloud service to load test an application or API. I found it via NovaNet after a quick Google search. (Note – I’m hoping for some free extra credits at Blitz indicates they’ll give if you blog about them.)

But hey, I might have blogged anyway – it’s VERY cool. I was able to immediately test my API and get a response time and likely capacity.

So I signed up, then ran a few more tests. I modified my app slightly to accept recognition that it was being hit by a load test, so that PUT data to my REST API would go into development database rather than my production DB. It took maybe a minute or two to update, and BAM – I could run a quick (free) load test of 10 users for 6 seconds.

Neat. I’m waiting for a company response to see if we have a load test mechanism. If not, I’m going to let our enterprise operations team know I’m going to load test, get a good time to run it, and just nail the server and see how it does.

I remember writing my own load testing application back in the day, and now I’m happy to highly recommend Blitz.io – it’s an Easy button.