GEIR ENGDAHL: Hello, everyone. My name is Geir Engdahl. I used to be [email protected],
and now I’m [email protected] And I’m [email protected] 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 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]