Tip:
Highlight text to annotate it
X
GEIR ENGDAHL: Hello, everyone.
My name is Geir Engdahl.
I used to be geir@google.com, and now I'm geir@skylib.com.
And I'm geir@skylib.com now because I believe that the way
we consume stuff today is broken.
And I'll tell you why I think it's broken and what I intend
to do to fix it.
But first, let me ask you a little question.
What do these objects have in common?
And I'll give you a little bit of time to think while I
introduce these objects.
The first one is a bicycle rack.
And then we have "The Art of Computer Programming" by
Donald Knuth, which I'm sure some of you are familiar with.
We have a waffle machine.
We have the complete series of "'Allo 'Allo" DVD
set in a big box.
We have a keyboard, some ice skates, a precision saw, a bar
code scanner, a string cutter, and something that we call a
"takke" in Norway.
It's for making a traditional treat, lefse.
We have a set of screwdrivers, and last but not least, a
sewing machine.
AUDIENCE: It's all stuff that you get [INAUDIBLE].
GEIR ENGDAHL: That's great.
Yep, besides the fact that you can borrow all of these things
for free on SkyLib in Oslo right now, that's exactly what
I was looking for.
They are occasionally being used, but
usually collecting dust.
So what usually happens when we need something like this is
we go to the store, buy it, a new object is created.
And we use it once.
And then it goes on to spend the rest of its miserable life
collecting dust on some shelf, or in a
drawer, or even worse--
in the garage.
I showed this slide to a different audience a couple of
weeks ago, and there was an American there.
And he immediately exclaimed that this
wasn't even a bad garage.
It could have been way worse.
And he's right.
You can see this continuous strip of floor all the way to
the door at the back.
So you know you can tell the state of a garage by the
rock-climbing difficulty of the simplest routes to the
door in the back.
So there is lots of interesting things you can do
with garages, but apparently storing a car in it is falling
out of fashion.
Because a study this year found that 3/4 of American
households cannot fit a car in their garage because of all
the clutter that's there.
This is what I'm going to be talking about today.
First, I'm going to tell you a little bit about my personal
motivation for creating SkyLib.
Then I'll go on to talk about SkyLib.
And I'm not going to say too much about it
because SkyLib is live.
You can go there and try it if you want to.
And then I'll move behind the scenes and give you some of my
experiences with using Google technologies
to build this product.
This is the grim reaper slide, the fire and brimstone thing.
We are using more resources than the Earth
can sustainably produce.
So we have this new holiday--
it's not a public holiday, but it's a day that's celebrated
every year.
And the strange thing about this day is
it moves every year.
It's called Global Overshoot Day, and it's the day where
we've used up all the sustainable capacity of Earth.
It keeps moving forward.
I believe it's in August now.
Once it reaches July 1, we'll be at two planets of
consumption versus we only have one planet.
So it's a little bit of a paradox how we managed to get
to this point.
But to explain it, you can think about a forest.
You can chop down more trees than are regrown every year
for quite a number of years until you run out of forest.
One other thing that we can take away from this chart is
that not only is our footprint increasing, it's actually
accelerating.
If you look at the carbon intensity of our economy, the
last 40 years, the amount of carbon emitted per GDP has
been going down by about 0.7% a year.
And you would think that with the recent focus on
sustainability and climate change that that number would
be accelerating, that we'd be better at using technology to
create goods and services in a more efficient manner.
But the last 10 years have seen no
change in carbon intensity.
It's actually the same as it was 10 years ago, so it's kind
of stagnated.
And the top two reasons for that is one, we've been moving
production to China and places where the carbon intensity of
production is higher than it used to be
in the Western world.
And the fossil resources that we are using to fuel our
economy are getting dirtier and harder to get.
It used to be you'd put a straw in the sand and oil
would just flow up.
Now you're digging oil out of the ground, and the tar sands
of Alberta is getting harder to get at.
And the amount of emission per barrel is increasing.
And as you can see here, the carbon footprint is the
largest single component of this total.
So where is that coming from?
Well, the traditional way to look at it is to look at it by
fuel source.
So we'd have this diagram.
There'd be coal, there'd be oil, there'd be some natural
gas, deforestation and cement making, and agriculture.
But I like to turn it around and look at the other end of
the pipeline from the consumer point of view, because I think
that's more useful in terms of figuring out what you can do
yourself to decrease the footprint.
Here you can see that from the consumer point of view, the
household carbon footprint, the largest
component is from mobility.
That's your car, getting around, transportation.
But there's also a large component, in the lower left
here, that's manufactured products.
And that is the embodied energy and carbon footprint
associated with the manufactured products that we
buy and use.
And that's not including food and clothes.
They have their own separate things.
So that's about 1/7 of the total.
So when people ask me if I'm trying to save the world, I
say, no, I'm only trying to save 1/7 of it.
The other 6/7, someone else will have to deal with--
which isn't entirely correct, because I do care about the
mobility part too.
A couple of years ago, I made this.
This is a traveling salesman solver for Google Maps.
You see Google is present.
And I think it's one of the examples where you get all the
incentives right, because you're saving time, you're
saving money, and you're saving the environment when
you're driving around to multiple locations, visiting
them in the right order.
Back to stuff and the carbon footprint of stuff.
This is a chart that Hans Rosling would love.
It contains a lot of information.
And you can see on the x-axis the carbon intensity per
dollar of each of these product categories.
So you see to the far right here, you have the things that
give the most pollution per dollar spent.
You have red meat.
I actually did the math for Norway, where if you buy, say,
$100 worth of gasoline and you light it on fire, you would
pollute less than if you bought $100
worth of the red meat.
So this is a very, very efficient way of polluting.
And the size of each circle here is the total amount for
each product group that's emitted.
So that's the amount of money that we spend on each group
multiplied by this carbon intensity.
And the largest circle here is one of the white
circles on the left.
It's auto vehicle manufacturing and parts.
That's not driving your car around.
That's producing the car.
Actually, the second largest here is tools and supplies.
And there's also a large white circle with
appliances and equipment.
So those are the circles that are more interesting to me
when it comes to SkyLib, because I think there are lots
of underutilized items lying around in these categories.
So let's dive into an example of this.
When we are looking at--
actually, don't panic here.
C is a beer, but don't panic because the beer does really
well in this sense.
It has a very low carbon footprint per dollar.
You see 1 liter of beer ends up at about 0.6 kilograms.
And how much is beer?
Where I come from in Norway, it's $10 per half a liter.
So you can safely spend your money on beer, and that's
going to be better than most other things you can do.
But it's interesting because you see how this life cycle
analysis works.
One of the things that surprises a lot of people is
that the transportation component is not very large.
Because we hear a lot about these products that travel
far, and that's obviously worse than having products
that travel short, but it's actually a small portion of
the total for many different categories of products.
So if you look at the biggest part here, it's manufacturing.
And the biggest component of that is power supplies.
So that's powering the factory, usually with
electricity.
But that electricity comes from a mix of power sources
where there's a lot of fossil fuel.
You have grains, because to make beer, you need grains.
And the farmer has a diesel-powered tractor, uses
fertilizer, et cetera, et cetera.
And there's a brewing process.
And there's a chemical reaction going on to produce
that alcohol, which has a CO2 byproduct.
There's some trucking.
And that's not the trucking to get the finished product to
the market.
It's moving the ingredients to where they are put together.
So it's earlier in the production chain.
And then you have all the packaging.
You have glass, aluminum, and metal.
And you have a variety of smaller things.
So they're not very large, but they do add up.
Transportation, mostly by truck, a little bit by air and
rail, but not very large.
And then there's a pretty big thing on the trade side.
And that's lighting and electricity for the fridge and
the store where the beer is waiting to be bought.
And there's also a warehouse component on that.
But in total, the beer does pretty well.
So now you can imagine me having learned all this.
We're spending way too much resources.
We're polluting way too much.
And everything that we do has a carbon footprint, and my
computer breaks down.
So I have the choice of tossing it out and buying a
brand new one, or I can try to fix it.
Naturally, I try to fix it.
It turns out the hard drive is the component that went down.
So I order a new one, and what better to replace it with than
an SSD disk?
So I get my SSD disk in the mail.
And I'm halfway through the process of replacing the disk,
removing all the little screws in my MacBook Pro, and I meet
this tiny devil of a screw with a different pattern.
And a little googling later reveals that it's a T6 Torx
screw, and I need a T6 Torx screwdriver.
Notice, again, the use of Google technologies.
So I go on a quest to try to find this screwdriver.
It turns out to be pretty hard to find.
The first store I go to, the man who helps me look through
all the screwdrivers in the store sums it up when he says,
I guess you're just not meant to open
that computer of yours.
So thank you, Apple.
But I didn't give up.
I went to the next store, and I found a set of screwdrivers
where one is the right screwdriver.
So I know that screwdrivers, too, have a carbon footprint
associated with them.
And I know that I'm only going to use one of the screwdrivers
in this kit of screwdrivers--
once.
So I tried to reason with the guy selling the screwdrivers.
And it went a little bit like this.
So I wasn't very successful.
But the idea of SkyLib was born.
So I went home and I did a little exercise that you can
do as well.
You grab your favorite map, and you draw a circle around
where you live.
The radius of this circle is 200 meters, so that's your
immediate neighborhood.
And then you try to count or estimate the number of
households inside that circle.
And then you multiply by the number of items that each
household has.
Now, the average household has how many items?
Any guesses?
AUDIENCE: [INAUDIBLE].
GEIR ENGDAHL: Any other?
So by the time a child reaches the age of 7, he has an
average of 500 toys.
Or has received that number of toys.
So you're a little bit on the low side, although these
numbers are from the United States.
So they may be different for Europe.
It's about 10,000.
So within this circle, we have about 1.5 million items.
And if you go online and you look at the biggest product
catalogs out there, that's 1.7 million items.
And they have pretty much anything that
you can think of.
And I'm sure there's a lot of overlap here, but I also think
that you can see that there's a huge resource sitting here.
And most of those items are not used daily.
So sail out to SkyLib.
What SkyLib does is it makes your stuff searchable.
The problem with the inventory on the last slide is it's not
searchable.
If you want to find your T6 Torx screwdriver, you need to
walk around the neighborhood and knock on people's doors,
and it's socially awkward, at least for us Norwegians.
And they may not know whether they have a T6 screwdriver or
not, because they didn't index their stuff properly.
So SkyLib uses a bit of mobile magic here to accomplish the
indexing of your stuff.
It's not that your phone is actually going to crawl around
and map the stuff, but you can walk around and use the bar
code scanner function on your cellphone, scan bar codes, and
the app looks up various databases online, tries to
find all the information it can about the product, and
puts it in your private inventory.
It's very important that we find as much information as
possible, because that makes it more searchable for others.
If you're adding a kit of screwdrivers, it's a bit
tedious to list all the different types of
screwdrivers that are in there.
So this should be done preferably for you.
If the information that we find automatically is
incomplete, then we ask the user to edit it.
But then all subsequent users get to benefit from that added
information.
When you add an item, you choose who can see it.
So it could be just your friends, could be friends of
friends, that way you reach a lot more people and you still
have some degree of trust.
It could be everyone.
Most of the items that are shared on SkyLib today are
shared with everyone.
And it's about 1,000 items, mainly in the Oslo area in
Norway that are shared.
You can share just with yourself.
I know quite a few people who could use a search engine for
their stuff.
You can share with different groups.
You can create a group for the building you live in.
Or your employer, workplace can have a group for your
sports club or whatever.
And you can also--
yeah, those are the modes.
Now that we've indexed the stuff, we can search it.
And this works pretty much like your
favorite search engine.
You enter the search query what you're looking for, and
you get a list of results.
With SkyLib, it's incredibly important that you find what
you're looking for within a short distance
of where you are.
Because if you have to travel 500 kilometers to pick up that
book, that's actually worse than creating a new book.
So the carbon footprint of an average book is about
equivalent to driving a gasoline powered car 130
kilometers.
It gives you an idea of the radius.
Preferably your neighbor has this, so you can walk 50
meters and get it.
Oh, and if you're searching on the cell phone, in the app, it
uses your present location.
So if you're traveling like me, if you're in a different
city, and suddenly you find out that you need a camera
tripod or something to take good pictures, then it'll
actually find the one that's closest to where you are.
So to the behind-the-scenes part.
SkyLib runs on Google App Engine.
I'm using Java on App Engine, so you have
the Java Duke here.
It's actually shared on SkyLib for some reason,
this Java Duke doll.
So if you want to borrow it, you can.
The reason I went with Java is it's the language that I'm
more familiar with among the three languages
offered by App Engine.
You have Python, you have Go, and you have Java.
And the other reason is I can reuse some of the data objects
written in Java on the Android application,
because that's Java too.
Now, the reason I went with App Engine is because of its
scalability.
So in 2011, a terrible earthquake and
massive tsunami hit Japan.
One of the things that tsunami did was it knocked out the
power plant at Fukushima.
And there was a lot of fear about radiation in that area.
And the days following the event, the disaster, I was
looking for information about radiation values.
And I couldn't find them in a format that was useful to me.
It turned out there were measurements of radiation, but
they were hidden inside PDF files that were generated in
Japanese every 15 minutes.
And these were measurement stations in elementary schools
around Japan.
So this German dude, a German engineer--
his name is Marian Steinbach, he scraped those PDFs and made
CSV files of the measurements.
And then I took those CSV files, put them into a MySQL
database on my personal home page server, and
plotted them on a map.
And you can actually click on each of the measurement
stations, and you can see the historical values.
Again, notice the use of the Google Chart API here.
Now, when I was done building this, and it only took a few
hours, I sent an email to Marian Steinbach thanking him
for the data.
And he tweeted about it.
And then 20 minutes after that, I get an email from my
host, Bluehost telling me they have closed my account due to
excessive loads.
So it turned out it wasn't just me who was looking for
this kind of information.
A lot of people were interested.
And this is one of the situations where App Engine
really excels, because it scales with traffic.
It automatically spawns new server instances for you when
you see more traffic.
But a lot of developers are initially disappointed when
they go to App Engine.
Because when you're developing your app and you're developing
it on your own box with the MySQL server running on that
same box, and there are 20 records in your database, and
there's only one person hitting it, and that's you, it
feels a lot snappier on your one box than
on Google App Engine.
And that's because even though there are only 20 records in
your data store on App Engine, it has all the infrastructure
to scale to 20 billion records.
It has the load balancing, and the data store isn't running
on the same machine as your business logic code.
So there are actually remote calls going back and forth.
And I think these two images illustrate the difference
between speed and scalability here.
Because with only one passenger, the Formula One
race car is a lot faster than this huge, bulky ship.
But with thousands of passengers at the same time,
it doesn't move at all.
And the bulky ship does, but with one
person, it feels slow.
That's not to say that I haven't done a lot of
performance tuning to try to get App Engine to be faster,
because that's one of the things that you will be doing
as a developer on App Engine.
You will spend a lot of time on this.
And one of the things that developers in general are not
that used to is struggling with startup time.
Because when you're deploying your Java app in normal
circumstances, you have your deploy script, it starts
running the program.
And that startup time can be pretty long if you have those
massive frameworks that manage your data and web
templates or whatnot.
On App Engine, because it scales, and because it spawns
instances when you need them, server instances, that startup
time becomes crucial.
Because let's say you have zero instances running,
because your app hasn't gotten very popular yet.
Then the first guy who comes to your service is going to
have to wait for your program to start, for the Java Virtual
Machine to start.
And it takes some time.
And if you look at the chart here, there's only a tiny bit
of that time that's the actual processing
in the user's request.
Most of it is startup time.
There is a way to solve this.
You can specify that you always want at least one
machine running.
And you can do that with the free quota that's provided on
App Engine.
You have to enable billing to do this, but you don't
actually have to pay, because you'll be right under the free
quota with one machine running all the time.
But whenever you need extra instances, whenever a new
server instance starts, a user dies.
It dies in the sense that he has to wait for this new
machine to spin off.
It's something that I haven't been able to figure out
how to solve yet.
What I'm doing right now is I have two machines running at
all times so this doesn't happen very often.
But for this automatic scaling to work well, it would be nice
to never send new users to new machines until they've
actually done all the startup.
AUDIENCE: So you're saying there's no way to delay
getting [INAUDIBLE].
GEIR ENGDAHL: Yes.
It's an open issue on the App Engine right now.
The other problem that I've been struggling a lot with
when it comes to App Engine is sometimes App Engine is slower
than it usually is.
So it doesn't have much downtime, but it does have
some slow time.
And if your startup time is 20 seconds, during those slow
time periods it can increase to 40, 50,
and maybe 60 seconds.
There's a hard limit on each request of 60 seconds.
So if instance startup time is more than 60 seconds, they
don't start at all.
And that translates that slow time into actual downtime for
your application.
So there are a number of things that you can do to
speed up startup time on App Engine.
Getting rid of the heavy frameworks is a hard sell when
you've written all the code.
But if you're just starting out, something that you should
consider when picking framework, if it looks like
the figure here with lots of different boxes and lots and
lots of features, it could be slow when it comes to startup.
I'm using a security framework called Apache Shiro.
And it's a very lightweight framework, actually.
But it does use reflection as a Java language thing for
initialization.
And that was super, super slow on App Engine.
They added alone 10 seconds of startup time on good days.
So replacing that configuration by INI files
with configuration that's explicit in your code takes it
down to less than a second.
So avoid reflection.
So here's my Christmas wish list.
Number one, user-facing requests should not be sent to
cold instances.
And number two, improve Java instance startup time.
And I actually have a suggestion for how to do this.
Because you don't actually have to
improve the startup time.
You just need to increase the request limit, if that's
possible, for startup requests.
Not the regular requests, but if startup requests could take
more time, then Java developers can use their heavy
frameworks that they're used to.
And as long as the first issue is solved, no users will be
killed in the process.
And Google recently introduced this awesome full text Search
API that holds a lot of promise.
It can do a lot of cool things for App Engine.
And I'm using it.
But as long as there's a hard request limit on the number of
requests to it per day at 20,000, it's not very useful.
Because every time you index something and put it into that
full text search API, you use one request.
And there's no batch way of doing that.
So SkyLib contains more than 10,000 items now.
If I need to re-index that for any reason--
say I want to add a field or something--
then first I have to remove each document, which takes one
operation, and then add the new version of that document.
And then I've blown my request quota for that day.
So those three things would make a very
merry Christmas indeed.
And if there's no Google Santa in the room, it would be great
if this could be forwarded to the Google Santa.
And then some sources that I want to show.
So if people are interested, they can actually look at the
data for the slides.
That's about it.
Next time you need something, one of the usual suspects of
dust collection, remember that SkyLib exists.
And if you can't find what you're looking for, make sure
that you put it in the cache SkyLib after you've used it.
Thank you.
[APPLAUSE]
GEIR ENGDAHL: Now, questions.
Yes?
AUDIENCE: One question.
[INAUDIBLE].
GEIR ENGDAHL: It's simple.
I was at Google before.
And the reason I left Google is actually I felt homesick.
I wanted to go back to Norway.
So I didn't have this idea then.
But I think, yeah, that's a great point.
Because with Google's resources, obviously it's
easier to get that critical mass of users that is
necessary to make this whole thing useful.
Yeah.
AUDIENCE: Did you consider using Amazon [INAUDIBLE]?
GEIR ENGDAHL: Yes, I did consider the other providers.
But given my background, I always felt that
Google is the best.
And actually, there's a difference between App Engine
and Amazon as platforms.
Amazon, you do much more of the configuration on your own,
and it doesn't auto-scale.
You actually have to request the extra instances yourself,
and you have to deploy to them, and you have to do a lot
of things that you get for free with App Engine.
I'm not a sorry type of guy.
So I want to do coding, but I don't want to do maintenance
and deployment scripts and all that.
And with App Engine, you have the
deployment in a web interface.
It's really simple.
You can do traffic experiments.
You can direct half traffic to the new version.
You get lots and lots of stuff for free.
AUDIENCE: So Skylab is available on Android and on
the computer.
What are the [INAUDIBLE] for SkyLib?
GEIR ENGDAHL: Yes, so SkyLib is available on the web at
skylib.com and in the Google Play Store.
I'm building an iPhone app, because people are nagging me.
It's not that I particularly like Apple.
But yeah, so the iPhone app is the next step.
AUDIENCE: [INAUDIBLE].
GEIR ENGDAHL: Yes, so the plan to get the critical amount of
users is to focus on a very small geographical area.
So I pick the battleground, which is going to be likely
around university campus in Oslo, and the student housing
areas, where people live close, they live on limited
budget, and they have the technology, and they're pretty
tech savvy.
AUDIENCE: [INAUDIBLE].
So basically when I [INAUDIBLE]
I can try to [INAUDIBLE].
So as background, before I joined Google about a year ago
I basically [INAUDIBLE].
One thing that I [INAUDIBLE]
is that I tend to forget.
I tend to forget that people have borrowed stuff from me,
and I tend to forget that I actually [INAUDIBLE]
give it back.
And if the Android app [INAUDIBLE]
someone who might borrow and to remind me to bring back.
Or if I go through [INAUDIBLE]
an interest in certain things, it can tell me, by the way,
they have one of those things [INAUDIBLE].
GEIR ENGDAHL: Yes, that's one of the main features.
A lot of people borrow from others, or they lend to
others, and then they forget about it.
So it's kind of like giving away the things.
Well, SkyLib does have a record of your transactions
within the system, so you can see who's borrowed.
AUDIENCE: [INAUDIBLE].
GEIR ENGDAHL: Right.
Yeah.
So this isn't--
AUDIENCE: [INAUDIBLE].
I want to borrow something from somebody [INAUDIBLE].
GEIR ENGDAHL: Yes, this hasn't been done yet.
I'm working out how the borrowing should really work
in practice to be the best it can.
One of the things is a limit on how long
you can borrow something.
And when you have that, you have the opportunity to give
reminders and try to make the exchange part easier.
I have focused on the search part for now, mainly because
I'm just one person developing it, and there hasn't been that
many transactions yet.
So I think there have been about 20 non-me
transactions so far.
But yeah, I think that's one of the next things that I will
be working on, the transactions themselves, and
making it safe and very convenient and helping you
remember what you should do.
AUDIENCE: [INAUDIBLE].
GEIR ENGDAHL: Yeah, actually that's a super idea, I think.
AUDIENCE: The social part of it's [INAUDIBLE].
GEIR ENGDAHL: Yeah, I think the messaging is good.
And hopefully--
I haven't looked into this, but maybe it's easy to
integrate with Google Talk and have some sort of widget.
Yeah, that's a great suggestion.
AUDIENCE: Beyond that, [INAUDIBLE]
Facebook could I say I added this item to SkyLib?
GEIR ENGDAHL: I'm planning for that.
The only integration right now is with log in.
You can log in via your Google account and your Facebook
account, and it pre-fills some of the information about you,
like your name and picture.
But that's coming.
That's just limited development
bandwidth from my side.
All right?
AUDIENCE: [INAUDIBLE]
mentioned [INAUDIBLE]
in the beginning about the [INAUDIBLE]
the way the time [INAUDIBLE]
a lot of the either you put online yourself [INAUDIBLE] or
you have put it out there.
Do you have a [INAUDIBLE]
user like I can know and with time it would be interesting
for me to see my household.
[INAUDIBLE].
GEIR ENGDAHL: Yeah, there is a simple inventory thing right
now, but it can be made a lot better, I think.
Right now, it's just a list of your things.
AUDIENCE: [INAUDIBLE].
GEIR ENGDAHL: And it would be super cool if in a few years
you'll have some sort of indoor navigation thing, so
the phone will know where you were when
you indexed the thing.
AUDIENCE: [INAUDIBLE].
GEIR ENGDAHL: I know libraries do this, but they have some
sort of bar code on the side of the book.
So I don't know if it would work yet.
But maybe it can be done.
Because you have the Google Goggles thing, where it does
recognize--
AUDIENCE: [INAUDIBLE].
GEIR ENGDAHL: Or put it in your Google Glass, and then
you can just walk around and look at the--
AUDIENCE: [INAUDIBLE].
GEIR ENGDAHL: All right?
Well, thank you for showing up.
And thank you for making great technology.
And keep moving the world forward.
[APPLAUSE]
[MUSIC PLAYING]