Transcript
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
[ Silence ]
>> Hi and welcome to Integrating
Passbook into your Ecosystem.
My name is Joelle Lam,
an Engineering Manager
at the Apple Store App Team,
also the Engineering Lead
of Apple Store Gift Card
in Passbook from WWDC
to its launch in October.
Last year iOS 6 announced
Passbook.
Passbook was this way you can
include your boarding passes,
your movie tickets and more on
your iPhone or your iPod Touch.
Now, us being the Apple
Store Engineering Team,
we knew we wanted to be part of
this, we knew we were missing
out if we didn't get involved
in the Passbook Ecosystem.
So, very quickly came Apple
Store Gift Card in Passbook.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
Now, I'm not from
the Passbook Team.
If anything I'm more
like you, I sat there
and watched the WWDC sessions,
I'm like an external
developer looking
onto iOS technologies asking,
"How do I enrich
the user experience?
How do I bring to life
some everyday things,
these everyday things that
used to exist in our pockets?"
OK. So, let's do
a quick overview.
We're first going to talk
about Apple Store Gift Card,
this is all about
pulling back that curtain
and showing you a little bit
about what we did
and why we did it.
Then we'll go into
leveraging existing systems.
I thought this was so important
because some of you guys are
out there, you have these huge
systems and you're wondering,
"Can I bring Passbook
to my Ecosystem?"
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
You have ASP downstream, how
many weeks do I have to prepare
for it, to talk to a DVA just
to get a database
let alone 3, right?
And then I have to do security
review just to get the ACLs
to talk to my security
systems or talk to my services.
So, leveraging existing systems
is all about bringing Passbook
to your Ecosystem no
matter how complex it is.
Then we'll talk about
determining complexity.
This is kind of an experience of
wisdom of what we think it talks
to determine the level of
effort to build your pass.
And finally, we'll do some
web services tips and tricks.
These tips and tricks are kind
of separated by complexity level
so they'll be something
there a lot of good meat
but something there for
every single one of you guys.
So, let's get started.
Apple Store Gift Card is all
about giving the people you care
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
about the products
you love, right?
If you look at this life cycle
of our gift card somebody
will go into the app
or on the website and
they'll purchase a gift card
and this gift card will then
get emailed to the giftee.
So, when we're delivering
that card,
we're actually delivering
an email with a link in it
which allows that person, the
giftee, to receive that card.
Finally, that card is
open to the Passbook
and the user can
look at the pass.
From there the Passbook can--
the gift card can be brought
into a store used
online and redeemed.
You can use it to
purchase something.
And if immediately when
that purchase occurs,
we send an update and the update
will actually update the path
and the giftee can now see
their new value in the pass.
Of course if they
have a value left,
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
they can continue
that cycle again.
OK. So, delivering the pass.
Apple Store Gift Card
is kind of a different--
a little bit of an advance pass.
You'll see that its flow and
giving a user pass is different
than what you would expect.
It doesn't actually
use a Companion App,
we use quite a few things.
So, if you get overwhelmed as
you're looking at our lifecycle
or as you're looking at
our flows, don't worry,
when we get to kind of
determining your complexity,
you will realize that you don't
need to do everything we did
but there'll be a lot of good
things you can carry away
from this, OK?
So, how many guys have the App?
Apple Store App?
You guys have it?
Good. Good, that's like
60, 70 percent, I like it.
How many of you don't?
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
You guys, OK.
[laughs] I'm impressed
though, that's honest.
OK? So, step one,
download the App.
Step one, open the App and
you get to look at the passes.
For me, I'm going to purchase a
pass for-- one of my coworkers,
Sonal, she's been working really
hard and she's kind of new
to Apple, she doesn't
have all the technologies,
all the products yet.
So, I'm going to
buy her an Apple TV,
I've picked out a
nice pass here.
110 dollars, you buy
her an Apple TV, right?
Then I'll put a nice little
message in there, say,
it's to Sona and from me.
And I'm telling her
to enjoy her Apple TV.
She's worked really hard.
OK, then once the order is
submitted, gift process,
an email gets sent out.
Just like every single Gift Card
email that we previously had.
Sonal will read this
and go, "Cool,
I got an apple TV,
this is so great."
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
She's going to open it up.
So, notice the add
to Passbook link.
So, click on it and be
brought to mobile Safari.
Now, this is our opportunity
to basically tag this pass
with the ten years Apple Stores.
You can use iBeacons now
if you prefer to do that,
but or you could use both.
So, that if she ever
forgets that she has this
and she walks near one of
our stores, she'll remember.
Then she clicks to
create the pass and be--
there it is, her Apple TV
ready for her to pick up.
OK. So, what were some
of the Apple Stores goals
in building this pass?
Passbook was an additional
avenue
to get in Gift Cards users.
It's not like I was able to
reimagine my backend systems,
I wasn't able to reimagine
the paper gift card, I mean,
if I had a choice,
I would do way
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
with the paper gift
card entirely.
But I didn't have a choice.
Those avenues had to
continue to coexist
with the Passbook avenue.
So, really, Passbook is
complimenting the entire system.
Existing avenues
shouldn't get harder, right?
And then a great fine that I
think that we stumbled upon.
Last year, when we were watching
the Passbook presentations,
we thought, "oh, oK, so we have
to make sure we have a Companion
App and somehow this has to work
with Apple Store App even though
the gifter is not the giftee"
and it occurred to me that
our Companion App is not
really acquired.
In fact, there's a
larger base of users
that have access to mail.
So, if you can detach
yourself from the requirement
of a companion app, you
actually have access
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
to much larger user base, right?
There's more of a chance
that they will see,
they'll see my Gift
Card then if it goes
to your mail then they have
download my pass because--
or downloaded my app,
not everyone has
downloaded their app,
right, as we saw here.
But everyone in here
has access to mail, OK?
So, no companion app
required, and then lastly,
integrating with
existing systems.
I couldn't touch or change many
of the systems that
I have below me.
So, we have to make sure
that we minimize our changes
and we'll talk about that
one little later, OK?
So, Sonal, she works
really hard, she doesn't go
to the mall a lot, but
now she's in the mall
and she's walking along and she
walks across the Apple Store.
And boom, her pass lights up
and says, "Hey, don't forget"
or sorry, she gets a lock screen
notice that says, "Don't forget
to use your-- go
get your Apple TV."
So, she goes in, she picks
up her Apple TV or her--
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
she picks up her Apple TV and
picks up her pass and says,
"Yes, I want to purchase.
And so you just can see
we use the QR code there.
Lucky for us, our point of
cell devices are iPhones.
So, we simply have to enable
that camera and scan
the QR code.
And lucky for you, AV Foundation
is going to do all that work
for you, you guys don't have
to think about shake factor
and a lot of things that we
have to be concerned about.
So, definitely take
advantage of that.
But let's say she
never gets to the mall.
Let's say she still wants
to get her Apple TV.
She still has to be able to
purchase on the web, right?
She has to be able to turn that
pass over reading clear text
to gift card and a pin
number and make the purchase.
So, we actually have to provide
the data both in the QR code
and on the back of the pass
in clear text, make sense?
Good, I see some of you nodding.
OK. So, using the pass,
you'll see this kind of theme
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
or reusing and leveraging
existing systems,
we reused the point of sale
devices, we didn't have
to replace them if you need to,
write an app Leverage
AV Foundation
to use optical scanners.
And then we have the
support, the web.
We even have to support
the phone.
Yes, people still use a phone.
But something that
surprised us, little it was,
it was a little bit--
at least the surprise
for me was the human factor.
Apple have some of the
greatest retail employees.
But as you know,
retail employees ebb
and flow based on the seasons.
So, when we first decided
to launch the Passbook,
we've trained a bunch of people.
But there was no guarantee
just a few months later
that the people that
we trained we're going
to be the people we would
go live with or launch with.
What I've learned from
this is how important it is
that we design and develop
even our point of sale devices
that only our sales
agents use to make sure
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
that it's almost impossible
for them to make a mistake.
So, what kind of mistakes
could they have possibly made,
it's just an optical
scanner, right?
Well, actually one of the
Apple employees they walked
into the Apple store
with their Passbook
and the sales agent was trying
to laser scan this QR code
and he's like, "Why
isn't this working?"
You just sitting there looking,
"Should I say something?"
Well, they are looking
at, you know,
they usually see this one
dimensional bar codes,
a two dimensional bar code
to a retail employee may
not be that different.
So, bottom line is target
user experience consistency.
If you're trying to be very
consistent for every user,
you'll realize you cannot
train every sales agent.
You just can't.
So, build into your
point of sale device.
The obvious thing
that the user should--
that the sales agent should
do out of a button there
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
that says check out with
Passbook, make it very clear
so nobody [inaudible] both the
sales agent and the customers.
OK, updating the pass.
This is the web services
portions, right?
This is the feedback loop
bringing to life your pass.
Once a redemption occurs,
if you can tell the user
that something has happened
it's so much more rewarding.
And I do it every time I go
in and if I have a gift card
and the sales agent
makes the purchase
and almost seconds later you
guys should try almost seconds
later the value updates
and you're like, "Oh OK,
what I just did actually
happened."
There's kind of event in a--
a satisfaction that occurs.
So, update your passes, use
Apple Push Notification service.
Super easy to do and bring
that feedback look all the way
around feedback to the user,
feedback to your sales agent.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
Apple Store Gift Card.
OK, let's move on.
[ Pause ]
Leveraging your existing
systems.
If you come from a
larger organization
or an organization even that's
been around for a while,
your systems architecture
diagram might look something
like this.
You start with an App
and this is the App
that we purchase with, right?
And it talks to our
applications and services layer.
And then it talks to our
order processor and then it--
the order is inducted by ASP,
it's probably written
to a database.
We notify our physical
gift card services.
Hey, we have a gift card
that we need you to generate.
And when that card gets
generated it probably writes
to a data base and then e-mail
gets sent out and on and on
and on and there's a lot
of boxes there, right?
That's really all you're
thinking about right now
and I would agree with you,
there are a lot of boxes there.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
So, the goal is to identify all
those boxes that do not matter.
Maintain only the
relevant boxes.
Maintain only the ones
you need to change.
So, then you're pushing into
this black box all the things
that are no longer relevant, and
you can push and push and push
and identify those things
you don't need to touch
until you end up
looking like this.
There are four interfaces
no matter how complex your
Ecosystem is, there are four
interfaces you must work with.
Number one, creating the pass.
This was-- we used
e-mail, right?
There is a link in the e-mail.
What is the interface in which
you generate or create and get
that pass to that user.
Number two, source of truth.
This is the system that knows
the ultimate value of your pass.
It's what your pass
primarily represents.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
Number three, redeeming
your pass.
The interface for redeeming your
pass, how do you use that pass?
And number four, this is the
call back for the update.
Once the pass has been
redeemed, how do you know
that there has been a change or
once the pass has been changed
in any way, how do you know
the pass has been changed?
So, four interfaces, right?
Then, you need to
identify the common factor
between all four of those.
The common currency,
for us I used GCN here
but it's a Gift Card Number.
All of these systems
that I must interface
with know what a
gift card number is.
So, if you have these
four interfaces,
you have the common currency.
You'll be able to bring Passbook
guaranteed to your Ecosystem.
OK, what are some common
currencies for you guys?
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
So, we use gift card number.
They might be club card number,
an Event ID, and Event ID
with the customer
ID and order number.
There are a lot of things but
just identify that shared piece
of information is probably
a primary key somewhere
in one of your data bases.
OK, so then six months later
when your boss is
giving a presentation
about how awesome your team
is because we integrated
with all these systems,
you can say, "Yeah,
but this is really what
I did, four interfaces.
OK, determining complexity.
Now, stepping back from
everything that we needed to do
to bring Passbook, to
bring this pass to Apple,
I think we can kind of impart
an experience or wisdom
of what it takes to determine
the level of effort required
to bringing a pass
to your system.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
I've identified five facets that
I think are really significant.
First one is value, uniqueness,
static versus dynamic,
scale and systems integration.
And on each of these facets
is kind of a sub scale
or scale within itself.
I'm using mountains
of science here.
I don't know, do you
guys snowboarder or ski?
Thought something you
guys do around here, no?
No? a little bit of
clapping out there.
OK so, the greens, you
guys know what those are?
The greens are for
people who kind
of don't know what they're
doing but still are courageous
and want to be out there.
And then hopefully at some point
they transition to intermediate
and intermediate is a little
bit harder, you need some skill,
you maybe took some classes and
then you move to the blacks,
the advanced category.
And the advanced is where you--
you're kind of parsing
through the snow
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
and you know exactly
what's going on.
I see some nodding.
So, there's a small scale.
There's a scale within
each one of these facets
and we're going to review them.
Value, value as a value
of your pass increases,
the complexity is
going to increase.
So, when you start with a
newspaper ad for instance,
a newspaper coupon might be free
because anybody can get to it.
And I know it might
have some value
because with redemption it
ends up adding value to you
but we really don't care
who's stealing that coupon.
Then a movie ticket, we
move up to the movie ticket.
It has more value.
You don't want people just
generating and stealing this,
you know, left and right.
You got to protect
it a little bit.
But at the same time if you got
out there, if you know big deal,
it wouldn't-- it wouldn't
be the end of the world.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
And finally, you kind of have
the gold vault of passes.
I was imagining boarding
passes would be in this.
You really don't want people
stealing them because they tend
to have quite a bit of value
and not only is the value
in one of the passes.
Not only is the value in all of
the boarding passes of that--
or that exist in Passbook.
But actually those services are
protecting all boarding passes
that exists very likely, right?
They have access to systems that
can see all boarding passes.
So, it's supper important
as you increase in value
that you spend more
time thinking about some
of the web services and tricks
we'll talk about later thinking
about reliability,
scalability and performance.
Uniqueness, a coupon can
be used my multiple people,
can be used multiple times.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
There's really no
sense of counting.
There's no sense of
checking that much.
You could almost put the
value within the pass itself.
So, that is much easier to do
than let's say a
membership card.
A membership card might be
used by a single household
or a single family but
it's used many times.
And your systems might
in the backend be doing some
really advanced statistics
and processing on every use.
But if you miss one
use, if for some reason,
you received an event that says
"Oh, I need to use this now
and you couldn't actually
serve all the data,
it wouldn't be a big deal."
And then there's the
quantified use category.
The quantified use is
all about taking score
and counting every single
use a gift card is perfect
for this, right?
A gift card, you actually
decrement that value.
You never want to
over decrement, right,
but unless you want to give
some things away for free.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
So, as a uniqueness increases--
sorry, as it becomes less unique
it's going to be more complex.
It's going to take a little bit
more time to build that pass.
Static versus dynamic.
I don't know how many of
guys have one of these.
The little blue social
security cards and they're
like there's nothing
on it except the number
and it looks really cheap.
Well, it's just a
piece of information
and the pass can be exactly
that can just be a
piece of information.
And the simpler it is if
it's just informational,
then it's much easier to write.
As you move up, maybe you're
changing one state or one field
in the pass [inaudible],
it might be an event
and you're kind of remind
somebody about an event
and it's going to get a
little bit more advanced.
But the multi-state pass where
you're updating multiple pieces
within the pass and I thought
a score board was a perfect
representation of this.
You're counting the
number of innings,
you're counting the
number of balls
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
or you're counting the
score, all these are kind
of dynamically updating
as needed.
The more states you have
to update on your pass,
the more time you need to spend.
OK, scale.
Scale is about the number
of passes that you have
or the number of locations that
you have or even the number
or points of sales
that you have.
So, it could just be that
you have a few passes.
You're maybe a mom and
pop shop and you're kind
of in the center category
where you have a few
passes not too big of a deal
or maybe you're chain,
you have even more passes.
Or you're a huge
enterprise and you have a ton
of passes you have to worry
everyday about reliability,
scalability and performance.
Another thing, another one
I mentioned was the point
of sales devices.
Let's say you're in a department
store and you're downstairs
and you're buying shoes.
And in the meantime
you're spouse is upstairs,
they're buying a shirt,
if you're using that pass
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
in both places you need to
make sure that data is correct
at the moment that pass is used.
OK, scale.
You with me still?
Systems integration, the last
one on the complexity scale,
the more systems you
need to integrate with,
the harder this is going to be.
So, if you can reimagine you're
Ecosystem, if you can say,
"I only need to support
the iPhone
or the iPod Touch"
it's much easier
to bring Passbook in, right?
But if you have to support
many electronic devices
like the desktop when Sonal
had to purchase on the web.
You're going to have to think
about a little bit more.
You're going to have
to make sure
that you cover all your bases
and you support those
users hopefully as richly.
And then of course the
most complicated one
when you still have the physical
gift cards to support you have
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
to make sure you keep
those users in mind.
OK, systems integration.
That was the last facet.
So, we said value,
static versus dynamic,
scale, what's the last one?
Come on you guys,
systems integration
and I think I missed
one but that's OK.
I'm glad you're still awake.
Don't assume, don't assume
that complexity equals
better because it doesn't.
You guys can have great passes
you can enrich the user's
experience with the
simplest of passes.
We were in Passbook
labs earlier and story
after story, people
are doing it.
So, I encourage you.
Create a pass.
Figure out what you
can do that enriches
that user's experiences.
OK, that was where
my summary slide was.
Web services tips and tricks.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
OK, reviewing the
pass asset sizes.
This is the green category
in which we're telling you
if you're in the basic area, you
should-- if you're in the basic,
you should do these 4 things.
So, review your pass
asset sizes,
adhere to if modified since,
implement logging endpoints
and expect dependency outages.
What does it mean to review
your pass asset sizes?
Performance and scalability
is super important at Apple,
often times before we have
a launch we'll test and test
and test until we know that
our systems will stay up.
And we were doing this in
QA over and over and over
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
and suddenly we were struggling,
we were getting these slow,
slow response time, it's taking
forever to zip up our files.
We looked a little
deeper and we found
out our asset sizes had changed.
They went from 4 kilobytes
to 280 kilobytes, what?
Right? What?
So, we have publishers
and they have the ability
to change our assets on a dime.
They decided they wanted
print quality and something
that wasn't going to
show them that quality.
So, what I highly recommend
you do, size your image assets,
make sure that they
don't exceed a limit
and log them as necessary.
Number 2, adhere to
if modified sense.
This is an RFC 2616, it
let's your clients make
conditional requests.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
Basically, let's say-- let's
say there's this awesome WWDC
exclusive party pass and if
anybody was going to have it
on my team, it'd be Alberto,
he is the partier of our team
and so he gets his great
pass, and he's probably--
he last updated at noon and
he's probably sitting here
and thinking I've heard this
presentation a thousand times.
He's looking at the
back of the pass, right?
And he's like, it shows
this pass by the way,
shows all the parties that
are happening and when,
which hotel rooms and so forth.
So, he's pulling down,
so he pulls it down.
He hasn't updated since
12, that request comes
over to our servers
and on the servers,
we look at that database
and say for this pass,
has there been any updates?
Has there been any
new parties added?
And if there has been,
scoop up all the contents,
make that PK pass file,
get it back to Alberto,
and Alberto is like,
"Yes, score,
there's another party" right?
And then five minutes
pass, he slips that pass
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
over and he pulls it down.
Request comes back to the
server, I look at the database,
and there's nothing new.
Sorry, Alberto, I'm
going to send you a 304--
I'm not going to spend any time
building your PK pass file.
I'm not going to
waste your bandwidth.
I'm just going to tell
you, you have the latest.
That's what adhere to if
modified sense and you can kind
of see this the request and
then the response starts,
you first respond with a 200
and if it's not modified
you return a 304.
OK, implement logging endpoints.
Implementing the logging
endpoints can sometimes be
forgettable, often times
our first kind of shot
at building these things as to
get all the basics down, right?
There are 5 endpoints
and you'll do the first 4
and you'll get those
knocked out.
But I highly recommend that you
make sure you've implemented
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
the log.
What will this do for you?
This will send you
human-readable information
about mistakes in
your implementation.
We spent so much time paying
people to give us feedback,
these usability studies.
We give them lots of money
to know more information.
But this is free feedback,
so why wouldn't we use it?
Implement the logging endpoint.
OK, number 4, expect
dependency outages.
If you have a service
out there, what happens
when that service goes down?
Are you in good shape because
you really put a load balancer
in front of it and
you actually have 2,
so it's no big deal
if one goes down.
If you can, try to make--
put multiple instances of
your web services out there.
For us, we talk to something
called Location Services.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
Location Services is-- it gives
us the 10 nearest Apple Stores
or it actually gives us
all the Apple Stores.
But we go to-- we go and
ask location services
when we generate a
pass, "Hey, you know,
where are my 10 nearest
Apple Stores?
We then can cache
that response locally
so that every time the request
comes in to build that pass,
we don't have to check
Location Services.
And where this is
super helpful is
when Location Services
goes down.
Did you need Location Services?
Could you have survived with
just putting in a long cache
so that if Location
Services goes down,
it's not that big of a deal.
It doesn't have to have
a 100 percent uptime.
And even better, show
this with the gray,
if you can have a fullback file.
So, we could just have a
fullback of all the locations
that Apple had at
the time of launch.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
At least we were able to serve
the user with something, right?
I mean how many of you want
to hear I couldn't get
my Apple Store Gift Card
because they couldn't
find the nearest stores,
it's just ridiculous, right?
So, pass should serve--
be served with the
bare minimum assets,
even when dependencies
are not responding.
And set up default back
up in data if you have to.
Do your best to serve
every request,
but don't create
unnecessary dependencies.
OK, tips in the intermediate
category.
Validating your origin.
It's not sufficient to simply
test, "Hey, is this pass valid
from a data standpoint?"
So, what I mean by that is
for us, we have gift card
and we could just for every
request, simply test, "Hey,
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
is this gift card number valid?
Does it have value?
But my recommendation is
that you step back a little
bit before even checking the
contents of the pass,
check who's the author.
Are you the origin?
The last thing you want to
be is a movie card generator
or a gift card checker, right?
If you check the signature
before you even serve the
request, you won't have
people out there building
or getting a valid gift card
for instance in our case,
and starting to tweak, right?
They're tweaking each of those
values to figure out the form
of your system and
understand it more.
If you sign the pass
first, if you sign the--
and I'm going to show
you how to do this,
the authentication token
first, you're going to see
that you can protect
yourself a lot more.
OK, so how many of guys remember
the authentication token?
Do you guys remember this?
A few of you, oh, that's
like 10 percent, 15 percent.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
OK, authentication token.
It's in the pass.json, and
it actually comes over on 3
of these requests, register
a device, unregister a device
and get the latest version.
That means on all 3 of these
request, if you know how
to check your signature,
you don't even have
to serve any part of that
request unless you know it came
from you.
How am I to do this?
Try using HMAC, pick a
message, any message, HMAC it,
append it to the
front, maybe sign
or maybe add a few characters,
some constants here and there,
so you know how to recognize it.
And now, put that in your
authentication token.
HMAC is super easy to do.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
It's available on practically
any language you're probably
going to write a web
service implementation in.
Ruby has a PHP, Python, Java,
it's available in the language
or some third party library,
Bouncy Castle is a
good example of that.
OK, validate significant
contents.
Anyone can create a
pass and with that said,
the pass itself cannot
be authoritative.
In fact, even if they
didn't create the pass
and it just hasn't
updated recently,
you may not have the latest
gift card value, right?
So, make sure you check
that source of truth.
Go back and check
gift card services
or whatever your
equivalent is, check it.
Number 3, leveraging caching,
cache as much downstream
information as possible.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
We talked about Location
Services.
We have the ability of
caching Location Services.
Cache or product
services, if for instance,
a pass is also represented by
associated product, cache that.
Cache your image services,
so if you use an image
service, like Scene7.
Take those images and
put them in local cache.
Do not fetch them
on every request.
I highly recommend
not to fetch them.
You can even cache your
encryption and decryption
of your authentication token.
And then the last one which I
think is kind of interesting,
consider caching
the PK pass file.
Remember that WWDC
exclusive party pass
that I was telling you about?
Well, if that's going around,
guaranteed Stefan [phonetic]
would have gotten it.
Now, Stefan, he knows everyone
and he's definitely going
to share with iMessage his pass.
So, he's going to say, "This
is all the people I know
at a queue listed,
yes, yes, OK."
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
Forming out the WWDC party
pass and all of them are going
to start requesting
updates all at once.
Now, if I was smart, and I
cache the entire PK pass file,
I could recognize based on
the parameters of the URL
that I just need to scoop up
my PK pass file, and serve it.
I didn't spend any time
zipping that pass file up.
Cool, huh?
OK. Four, in the intermediate
category, monitoring.
Be the first to know when
your service is down.
I hate it and hopefully, and it
happens rarely, but I hate it
when my boss comes in and says,
"What's going on with this?"
If you can know that your pass,
your web services have gone
down first, it's a huge win.
There is so many monitoring
systems out there, Site24x7.
They allow you to send
request, HTTP request,
and you can configure
everything.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
You can configure the post,
you can configure the headers
and then on the response,
you can check, is it a 200?
Is the pass-- is it a
correct response type?
So, monitor from
external systems and then
when systems go down,
you're going to get a text,
and you might be out but
you're the first person on it
because you know it happened.
Internal logging, this
one is really easy,
especially if you can add
log aggregation like Splunk.
But log things that matter
whether it's a logging endpoints
that came in.
The asset sizes we talked
about when you start
exceeding a level, log that.
Another one, if your
certificate is about to expire,
you guys get one year, right?
And sometimes we don't think
about these things a year
later, so start to log.
And then when you hit a certain
size or maybe get a daily digest
of the logs, you
get top 10 logs.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
This will help you monitor
and keep your systems healthy
without a lot of effort.
Of course there's internal
monitoring also, you can Nagios,
make sure those bits are up.
But think about monitoring,
so those were kind
of the intermediate items.
Tips for the advanced, the first
one I have is rate limiting.
Rate limiting is all about
making sure you don't
over serve the request
that are coming in
or unnecessarily serve the
request that are coming in.
So, if you have a
denial of service attack,
and you can identify, hey, this
pattern of request is too fast.
You can pull back, and you
can just let them drop.
And your whole system
can set up and continue
to serve valid requests without
kind of going down, kind--
attempting to serve all
these invalid requests.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
It protects you from a
denial of service attack
and a brute force attack.
You can rate limit on a serial
number, although be careful now
that sharing is going
to be prevalent.
You want to make sure it makes
sense for your pass type.
You can rate limit on an
IP, be careful with that
because probably a lot of
people have passes in WWDC
and the last thing you want
to do is shutdown
request coming from WWDC.
But think about rate limiting,
process asynchronously.
When a request comes
in, you want to serve
that request just
quickly as possible.
The more time you spend doing
downstream things and holding
that connection, the less
people you can serve,
the more systems you have to put
up to serve all the
incoming request.
So, if you go out and you
try to pre-warm your caches,
get all the information you can
as soon as possible right even
when your system starts up.
So, for example like I said,
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
gift cards can be
associated for--
with a product, and that's
how when you're purchasing
in the store, the strip
looks very similar
to the original gift card.
What I can do is I can go
to product services as soon
as I start up and I say,
"Give me all the gift
cards that are out there.
And give me all the related
strips that are out" then
when the request comes in,
I'm not wasting time getting
those downstream items,
I'm just pulling them
from my local cache.
Logs. Writing to
disk is expensive.
If you allow every log
that comes in especially
on the endpoint to
write to disk,
you could be in a
dangerous spot.
So, if you throw it in memory
and you have a write behind the
disk, you're going to be able
to serve that request
a lot faster
without impacting the
rest of your systems.
Using a queue for push
notifications and this is
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
that callback update, so when
you find out that the pass needs
to be updated, instead of
holding that connection for us
from gift card services,
we can just say, "Yeah,
we got the request and
we drop it in a queue."
And then later on as soon
our systems are ready,
we just serve it to Push
Notification Service.
We don't have to wait to find
out that Apple Push Notification
service received the request.
There's no need to,
just drop it in a queue.
Avoid holding those connections,
those connections open as--
make it as short of
a period as possible.
OK, 3, leveraging
auth token as storage.
If you don't want to do this
or you don't understand
this, don't feel bad.
This is super cool
though, so pay attention.
These impacts performance
reliability
but the basic concept is here.
On our request, Apple
Store pass services needs
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
to take the serial number I
got from the pass and I need
to crosscheck and get the
gift card and the pin.
Because remember the gift
card is my common currency
with gift card services, so I
have to go, I got to go look
at my database, and find the
gift card and associated pin.
That means before
I can even check
if the gift card has value,
I've had to hit my database,
and we know database, talk
into a database can be slow.
So, one of the things you can do
is embed your gift card and pin
or your common currency
or whatever information
that's relevant
to you inside your
authentication token.
OK, so how many of you guys
remember authentication
token now?
Little bit more, OK.
[laughs] If you embed gift card,
the gift card number and the pin
in the authentication token,
you actually don't have
to ask your database
what is associated
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
with that serial number.
You can go directly to
the source of truth,
your gift card services and
say, "Hey, what's the value?"
One last conversation with your
database, pretty cool, right?
So, take your authentication
token and remember that message
that I said, just
pick a message.
Well, pick the gift card
number, pick the pin.
Pick something that's
relevant to you.
It could be a product number.
It could be the URL
for your image strip,
so if you're building
different passes,
if you're building different
passes with different images,
you can actually embed the image
URL inside the authentication
token, so you don't have
to check your database
what image is associated
with that pass.
It's kind of cool.
OK. So, I said some other things
you can embed important dates
like expiriees in your
top 10 nearest location,
so I don't actually-- once I've
gotten the 10 nearest locations
for a pass, I never check
my Location Services again
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
because I have it there.
Four, distinguish
test and production.
This actually happened to us.
We're building in QA
our test environment
and we have Quality
Assurance is helping us out
and they're building
pass after pass,
every permutation you could
imagine, and someone said,
"what happens if we took
these test passes to a store?
They sure look real" and
in fact, they are real
because we signed them with
our pass type identifier
and the certificate we had.
So, we had to rethink that.
So, what you can do is take
that pass type identifier
that you embed in the pass.json
and you can create a new
pass identifier and test,
and just have a different
one for production.
Now, if you have
a companion app,
make sure your companion
app can work with both--
is entitled to work
with both of these,
but keeping the pass type
identifier, will make it so that
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
if somebody walks into your
store with a different pass
with the test pass, your
point of sale device
or whatever you're using to
redeem it can first check, "hey,
do I recognize this pass type
identifier" nicely say, "Hey,
you're using a test pass.
This is not going to work."
Very easy way to
distinguish between the two.
OK. Building and debug ability.
If something goes wrong in prod,
in fact when something
goes wrong in production,
how are you going to
find out went wrong?
This is a perfect example, I
get a text from a friend of mine
and they said, "Hey, I
walked by the Apple Store
and it didn't tell me that
Apple Store was right there."
So, I find out their
serial number,
and how do I really know what
were the 10 locations embedded
in their pass?
Well, if you planned
for it, you can make it
Request Timeout
The server timed out while waiting for the browser's request.
Reference #2.c6524817.1373787862.0
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
we had kind of the easy, the
intermediate, and the advanced.
Today, we talked about
Apple Store gift card,
we pulled that curtain
back a little bit for you,
showed you what we
did, why we did it,
leveraging existing
systems, 4 interfaces, right,
obtaining the pass, your source
of truth, redeeming the pass
and the callback update.
Determining complexity, we
went through some facets
that allowed you to
measure the level of effort.
Basically, you can go back
to your bosses and say,
"Hey, I thought about this.
I've looked at the Ecosystem.
I know the facets
that I need to think
about and we can do it too.
We can have a pass too."
And then some web services tips
and tricks, those
are all online.
You can go back through them.
Read them, understand them more.
Paul Marcos, he does
a lot of this for you.
He helps us prepare.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
He's our evangelist,
great access
or he has great information,
so if you have any
questions, contact him.
There's documentation online.
In addition, if you missed
it earlier on the What's New
in Passbook, it's recorded.
So, check that out.
I want to call out
Harnessing iOS to Create Magic
in Your Apps specifically.
This session as well
as the next session
and especially the
next session is again
about using standard
iOS technologies,
kind of as an external
developer,
but using those technologies to
enrich the users' experiences.
So, they do some really
basic easy things,
but it just changes
the life of your apps
from an external standpoint.
Thank you so much
for joining us.
[Applause]
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000