Embed code
Note: this content has been automatically generated.
that's the last one i thank you very much for um
hello everybody i would like to talk with you today about uh how
the container or doctor revolutionised the that ops i. t. landscape
and my talk will not be necessarily very technically i mean it would
be about doctor it'll be technically but without code examples because
i wanna show you or explain you more the principle of the
core concepts behind doctor and also the results of these concepts
that will change your uh they leave work if you if you working with doctor
um before we start that introduce myself my name is about him
oh i uh work for the company called eight years and if you would like to
find more about me you can best is to for me on the top
and or into it so then you can see my reporter isn't it see what i'm doing and we should was doesn't start starring
uh yeah i'm working for the company in case and we actually developing software
and this also today involves developing um clout infrastructures
because developing software and developing infrastructure is actually the same it's both software
on one hand it's softer that produces a code producer website application
on one hand you develop software produces an infrastructure which is also actually saying
you have to test it you have to have what you sure
once you have a have a repository of the continues to ration can you do that very and all those up a sort of stuff
then we also do some workshops in an area of docket
continues rationed and holding company does the clustering infrastructure
but at dive into doctor who viewed no was what grace
who of you used already doctor
what he already
so but nevertheless well what is the idea behind talk
or the principal idea behind doctor is to
have an application which is isolated complete that runs
everywhere isolated means that there are no conflicts
or whatever to other libraries that are on the system so there is no conflict
there are no dependencies to other libraries that are uh on the system so you're know
exactly what you're running complete means that the application that you're running brings everything
with it it it needs so everything that application needs is part of the the package
so and running everywhere means that the result or the container is really
running everywhere i mean everywhere means in on linux okay so
the other everything else doesn't matter no seriously and that means is wrought everywhere and and
and and i mean now it's basically only looks so it runs on everything system
yes some button colour parameters to talk right um but also this
running on windows since uh a couple of weeks enough
windows supporting a doctor already so we can really run native
windows applications on on the on the windows kernel
oh and uh we probably one day they will be also something with the mac but um
but why is the possible but i mean doctor is two years old you know
of that and why is it so popular i mean we we had a uh
the lars also it's called even solar containers that exists is two thousand five
in a very successful and and and people on as of our as far
as a systems uh use it we have a freebies the jails
it exist since the year two thousand or so we we have this container concepts um
in in the history of of of a unix is all the time to my
is is is doctor so successful in that in recent years and it's actually
the focus of doctor specifically to be user friendly to be easy to use
the city for developers and also with functionality to be very
easy extendable so you can really easy extends talker and
what new stuff in and you can extend with new functionality very easy much much easier than the other solutions
but understands advantage let's take a look at uh on how
doctor is is 'cause conception list you know from
the object oriented software development from the object oriented languages that there is something like an object
in the class and an object is nothing more than an instance of the class
but the same you can think of of images and containers in a doctor minor you have
an image which is represents class and if you instantiated make it run it becomes
a container because it's it's the actual instance running so a container is the white you you specific
my uh you specific drop for example or um yet so different instances of of this image
but each image itself contains of multiple layers on those layers can
be stacked together on each other on top of each other
so actually if you would take a look at what press image
it's not just the purpose image itself it contains a
underneath it contains p. l. p. h. p. layer that provides your peach
be a run time environment an underneath it it contains an uh
and stripped down the ins operating system in this case it will be unix or so are you going to
and so this is how you actually build your applications it's like a lady layer by layer
or image that extent other images and you can read mail more more complicated cushions
when we talk about talk or we actually mean various different things so we don't we actually need things like
the doctor demon which is responsible for starting the containers popping the containers
and running two containers but also is responsible to get the
images to build the images and we talk about soccer uh and
we need to the client like the command line client
yeah that is communicating with the demon and is responsible to trigger the demon
to tell it may start start the container and stop the container and
greater network whatever and we have also the the registry which is not part of
of the great self but is very uh tightly coupled to doctor because it's
provides a repository where the images that i create or someone
else creates i can make any use for my purposes
then next to the doctor functionality we have the the the common extensions
most of them are all this this example see uh provided
by right doctor incorporated itself but they're very closely coupled to doctor
and we're talking about uh composed local compose which is uh
allows you to create an application uh that is just of multiple containers we kind
of a complete compose multiple containers together to run them as a whole
and we have a machine doctor machine that isolates you to create
what the provision service so you can remote use machine do provisions server where
doctor will be installed and it's configures you can communicate easily with it
and swarm is actually responsible for if you have a multiple doctor votes
um but i can go to communicate with each others you can create a cluster of
multiple other instances and this is what is you know we use swarm to use
but one of them um main reason why doctor is
so successful is that the eco system around doctor
is providing hundreds and thousands of extensions or product that does specifically made for doctor
it extends the functionality of taco and provide new functionality that
would really um let me talk just on itself um
let's look of um a group of those tools that exist in the it was system so
we we need to better understand them we need to group them into into categories
and we have a good grief tools which is a which are responsible for august ration
august ration means if i have multiple containers on us or so in the containers if i have multiple
hosts a cloud environment okay i've on the machines and that won't deploy on those hundred machines containers
very easily those hundred machines need to communicate in some windows when critic another cluster many to orchestrate
my containers i need to orchestrate a witty containers executed actually and
so that tools like when it is like measles likes war
and or ranger that helped or for c. v. it the the orchestration of of containers across multiple
holes not multiple environments and then we have tools that are responsible for monitoring you containers
and logging so that you always know was no matter where it continues running that is correctly
the the data is locked correctly and that the state of the containers money toward
and then as to see their response before discovery and discovery is needed
if you have a a environment way of like hundred containers
michael services running and working together those containers need to communicate
to each other those continuously to find each other
'cause you can not just a run the container one node and run on on something on on the other note
uh and expect that they find each other and they can communicate with each other so you need tools
that facility with this and it example of those tools are for example onto the t. c. d.
as we keep our net flicks a rica that help you to uh
uh to achieve this goal very easily in context of doctor and then you have also tools that are
of course wages virtual networks we have a network inside a network so it you containers can communicate with each other
like it was a a bunch of individual network and there's also plenty of tools in this area and well
let's look before we go to next like let's look on the on the um
on the architecture of of of a doctor so we have here um
our and architecture of uh of taco so we have on the need we have the hardware and
then we have some linux stuff going on here so there's like the linux kernel functionalities
uh like names basis you so there's really something deep inside inside unix and then on
on each on the linux system we have the container running as i told you that the containers everything that's needs to run
it contains all those leaves libraries then you get for your application to run like the g. d.
n. like no g. s. like ruby libraries everything is there in the container and the demon
or actually i called a a rota doctor but is actually the
demon demon is not in the container it's just communicating
it's not communicating with the container itself or not directly it's it's
starting this containers managing those containers it sees if they
ever running into stops them and so it's kind of a sits inside of the containers not part of it and
this this allows uh some third party to coming to communicate with
the demon that that will then start and stop the containers
and one thing to note is that the actually the container all running on the one on the same colonel
you don't have a multiple kernels yeah you have one hardware one
unix kernel and all those containers are running on one kernel
and it hasn't very um big impact on performance opposed
it in this case because everything's running on a
on one single car isolated from each other it takes
zero ahead regarding the start the container it doesn't matter if you start your my s.
q. l. or or p. h. p. application without containers with containers it's zero overhead
because actually this is the same curl and the same ruffle here and
the second part is um because it's it's isolated another sorry not eyes
that because it's running on the colonel resource overhead is zero
or like a like an virtual machines where you haven't operating system and
operating system and operating system on one hardware where it's come zooms
and and and it's your resources here you have absolutely no resource
overhead so it does not consume more resources than single process
well that's
it'll why this this this dog architecture is is such a revolution or
such a big change in in how uh you develop your applications
before we die that is there are some things that really um intimate doctor
narrows down or so or restricts you when using so there is a case where
we're um document is ideal for and that's the case where you have um status containers so
the requirement for doctor is that the container status does not any state
or you create a container that has an external state so we can have something in that connect to the database
where the state is inside but your application itself is is status no we're talking here about i don't
know if if you know the twelve factor applications well factor apps the ring a bell so you should do
with twelve factor apps it's it's a it's a design principle how you develop application of the status and
because this restriction is in many cases um yeah oh well a lot of people this is um
the same him at the beginning it's very problematic it's very difficult to design and application
especially if you haven't exist application it's very very difficult to migrate or to move it into the state this one because you
have a lot of overhead you have a lot of uh things already in your application and it's very difficult to
uh to to migrate to make it status in many cases noble but it's only it's it's it's it's problem
and um this this um restriction is on the other hand that you'd huge advantage
and a huge advantage is that you have this so called atomic rule we containers so you have that in container
it's actually a thruway container this means that you start the container and if you want to stop it
you don't care you just stop it you remove it and it's gone so there is
no old libraries left anymore so there's nothing on your host operating system
but uh maybe leftovers the next time you start it doesn't work anymore in
if you update the next version it doesn't work anymore this is
uh not a problem anymore there's really no leftovers because it has no state you can just stop it you don't have to worry
and because it is posted you can start it because it has no state you can start it once twice three times you can run it on
one data centre you can write on two data centres you can run all over the globe
has has no state it's easy to scale up this huge advantage if you wanna have a publication it's not
only a scalable so is that you know can cope with millions of users but also that it was
also the application it's really resigned and this means you can start it and if it stops you started again
where you started on a new server which is a reliable so it's really improved the real real
the silence of implication worried but um and this is of course the result of the immutable container so we call it uh
the true we continue recording mutable that because it has no state and so this
so if we take a look or if you if you if you
using doctor for a while you know then you will uh ask yourself maybe you know how to stop actually
compared to other technologies you know how does it compare to the m. there because it's some sort
of a visualisation you know but how does it really compared to the empire anna how does maybe compared
unstable because you could you can isn't integration with it and if you if you if you
uh like doctor versus something on the internet you will find many articles and many results
how a doctor is compared to all those technologies but if you take a bit to close the
look on the slide you maybe see if you know this technologies you maybe see that
at that regroup the technologies we're talking about the we have a bunch of asian technology like
v. and we're like send key v. m. but is the vegetation technology we have
the figure ration management tools you know like uh and civil like soul stick cheek up strong now
those out configuration tools and also we have some who was like open steak nails done
more for orchestration and you see that actually doctors some somewhere in between so it
is we compares to things like the empire and also to the sensible but that compares
to uh to to mean different things so that the result is actually that
the documentation is not very focusing on on on the replay six ecology but it's a very
uh brodie range not very deeply itself but very broadly across multiple technologies
'cause its cover something from configuration management cover something for vegetation
it's not good in but relation compared to the younger or something because
we um has really really great functionality regarding visualisation but it has
something the core functionality of it is there and those many factors
of of soccer because it spends all but this much technologies
allows a completely different way how how people can read incorporate together all the break together because
this vied orientation that new world falls possible that are not possible otherwise and i mean
ruffles for for developers for operations teams for just about as big as for for work you
ace but um would not be possible otherwise well before we answer the questions well
what kind of what falls let's see what a typical work full day would be without uh
having talker so in a classical after the deployment software development world we have this
kind of work full so let me explain we have two teams here are responsible for
uh let's say developing and deploying application into
production making available fall for the customers
to visit the website for example we have on one hand we have developers and say okay i have application
i wanna have it running somewhere and have it the the ops people on the other
side just wonder straighter that are responsible for providing you the infrastructure uh so yup
occasion can run and so you you make you press okay i need hardware i hit
machine that has thirtieth uh thirty thirty two gigabyte of ram i have must
need machine has to uh as as the drives with the this i i ups rate
and stuff like this and then you get the machine one day when you
start configuring it because maybe it is already configured but anyway even if it's configured
you still need to do a configuration because you need to adopt a machine
or you specific purposes you need to install software you configure it and then you say okay i configured everything
and then there's someone from the of ops team or operations team looking in it and say we will
know is not allowed an outcome organisation and then it you start you start tweaking around so you start
looking around and see what is allowed how can i work around and if it's wide larger organisation
it's it's very strictly because you cannot install days you get here you have to use only this operating system because those
people wanna have also an easy life you know they want they don't wanna support like twenty five different operating systems
it would have one operating system you want to or a centre was or baby and they don't wanna like twenty
five different because you know i'm a baby and it's easy for you but then it's easier to maintain one
operating system it easier to for them to maintain only one set of libraries you know it's easy for them to
manage one j. v. m. instead of twenty so and that it's it's starting triggering and it it goes
on and on and on until one day everyone is happy and your applications find a running and then browse is
that and this is a very cumbersome up the approach because it takes a long time it's very hot
establish of work flow inside an organisation where different teams liberate with each other on the topic they're not very
familiar with because developers are not very familiar about the
infrastructure because they know that something like this exist
i didn't know exactly what it is and how to cope with this on the other hand the
operations people you don't know the application they don't know what is inside and how to
how to run and with the doctor approach or container push it's it's very easy no you
have the developer that graces application yet the developer that rates a container where his application
is running you tested it verifies it makes sure that his application is running this container and
is running in this container successfully after that it just ends or the container but it
helps people that operation people say look this containers running i give it to you make it
run for me and the present team just figures everything around the parameters around it
and can easily run the application because it doesn't have to know what is actually inside just has no
how to start the container it doesn't have to know how to start application how to connect
to the database how to do this how to do that that's really application specific stuff
it doesn't have to know what it just has no i'll have right should i continue my environment to make this
a container around and because because of this this rightful we
can say that doctor is creating a standardised interface
not only for the operating system and the container to communicate with
each other but it rains also a standardised interface between
a developer someone hand and operations people on the other hand how they communicate because if they could
we could each other they have clear interfaces and how they communicate because they always communicating
around the functionality docket provides and there is no mismatch and this is called the location of duties so we have
a really strict segregation if between the developers and the
operations and let's see it from a different perspective
uh on this topic so um we have here at classical
layout of uh our um infrastructure on the left
hand side we see um the classical view so we have the infrastructure hardware we haven't operating system
where the hyper wiser and and uh oh each type of wiser we have in the two machine running the end there whatever
and inside the stadium where we have an operating system and its operating system contains some libraries and then
with the separation and this is the same this is the same so we have actually
one two three four operating system that has to be manage on the other hand we have
this the doctor set up we have here infrastructure we haven't operating system we have hated
upper engine and on top of this we have the containers which actually like an operating system
because it's a doctor engine takes care of it and this is kind of you
know approach and and this this interfaces come into place because this and this other domain of
the operations people is that the domain but operations people operate a crate infrastructure the
maintain infrastructure to make sure that those things around uh yeah yeah it's this part and
here it's it's a bit less and this is the upcoming and on the other
hand we have here the developer domain and here the developer to the u. c. developer domain
and up to maine completely separated because here in classical what you as a developer yes
you have to know what is actually running on the operating system that is not under
your control you maybe have access to it but you have no control over it
at least in in in a large organisation we have we have two teams and this results
in conflicts this is the area way he has to communicate with the other side
without the language and the interface you have to communicate here with the they have and
and the all the the operations on on the same stuff without technically interfaces and
the the ops have a different view on this then the developers and this is normal and
here it's very clear there's that the separation between them too so finally we can say
that if we talk about containers we can say uh that the
developers are responsible for making the container run them responsible for
making the application in the container run well and operations people
are responsible will actually making the container run somewhere that
is uh the final thought about this so if we talking about
desegregation of duties between the deaths and the ops that's
still need something like that pops it is a really hyped worth you know and everyone is talking about that pops
and i'm telling you that we don't need it anymore i'm not telling but i'm asking the question do
we need any more but you know before we dive into this does that ops buzzword topic
let's find out you know what does this devil stuff mean no if we talk about their tops
and the definition that different things meant by this you know that pops or deaths doing up
stuff is actually what your your company things you have ups means you know because they think okay we
don't need also we have that ops they do everything is what but that's not quite true
now but then the second definition of their hopes is actually that means that uh you're developing or
someone also somewhere is developing the infrastructure just like
it's normal application just as normal code
it has a it has a builds estimate is that the u. i. system it is
a continues integration it has continued delivery is just nothing more than a normal
application and you have to develop it just a normal application and this results that
uh you're a dead hopes use actually the same tools as a developer
you have an i. d. you have a a continues tests and everything like this
and if the definition which is actually not a definition on the technology but
it's a definition on that that helps means that developers and operations timit closely
collaborating together as one t. not as a separate fumes of is actually
you can say it not as one person but as one people in that uh what works closely
together so developers learn from the ops what are they doing and know what are they doing
and their domain and on the other hand as well that ops normal to developers
are doing because they're operating actually in the same domain now ended operating in
separate separate domains the it together because we can assume that
the deaths and all use the same tools to get
work done and because they're using the same tools everyone from each side knows how to use those tools
and this is for example doctor is such a tool because it's used on one hand it used by that but all people
on the other hand it use also by the deaf people and to to highlight this example
let's take a look at the the uh the doctor run time environment so well
we have here a run time environment uh it's it's called the doctor
away container environment so we we have a container that actually
knows that it's running in the court that it's container it's knows that it's running on the docket demon because it coming in
can it can communicate with the doctor engine or the curry demon
and this is a great example for this for deaf son
ops using the same tools because this is our application it is
responsible or it is maintained and developed by the developers
because it contains your business data and business logic and this
is your business application that's developed and is uh containers
but i actually developed by the ops people and those containers are responsible for security
maybe securing the application or securing the whole infrastructure we don't know but
they use the same tools to achieve this goal they use a logging but you the same goals because
they're using using containers that are aware of of of soccer and that can maybe lock your application
without you even knowing it but it yeah actually i have not uh who was one tool that
use uh from both sides in a in a different context in it in a different manner
and the standards that interfaces cannot only be used from from that and obsolete also
is within the containers together so the containers can communicate with each other
and use information from one container in the other container
without having interfaces we help without i'm having
without being tightly coupled to each other so we have something like locking we can provide very easily looking for container that
is running someone a server that aggregates everything makes a really
pretty lot across you all infrastructure without the application
or without the continue even noticing that is log be locked and the same goes for archiving we don't have to
implement some archiving functionality normalisation which is no because it has
some interfaces and doctor how to archive docket containers
someone would do it for us and application doesn't have to care about this and this goes on for security for
august rating multiple containers to sell what what are the tools of for the uh the upstream
of the containers and the containers don't know what about it they just know that that
i don't even know that the containers that think they're running it in they all operating system and you can yeah is this goes in all
on an on so the summary we can say that even though well
doctor is a very very popular two or two in the recent
recent years on a um there's one yeah difficulty actually is that doctors often
used more by developers then by operations and it has some reasons
for that um because one of the reasons is that um operations people
ah used to use their tools they know they're the best
shells they annoy their shells in all very precisely how to configure linux they
know all this nifty details of linux kernel you know everything and
now with doctor never a big limitation in this is flexibility disability and
they have to to learn new tools they have to learn
uh to use new new functionality and this means that um the operations
people need to change how the working and a lot of those
people don't like change i mean a lot of actually all of all of us don't like changes if it's if it's too much
um then you have no control over the containers so if someone is building a container if it's you when you
have control of you container that someone else operations on of the controller would they don't know what it's inside
and for for many people this is a a big problem because if they don't know what's inside
how can they operated how can they make it run so this is uh
mm yeah this is a full thought of the operations environments it's
it's a problem uh or how many people have a problem with that
so so the conclusion can say that the containers provided better operation
of responsibilities between the operations and developers and that we have
or we have to take care that our container
that we create a status because if they don't statements we can we can we can make them run
but they will not run efficiently or the the waves problems with running and we have the possibility that
doctor on itself is um it's just an application better
decision so we which allies in our application
nothing more with some tools around it but in principle it's it's it's a very
limited functionality it's it's white inspectors limited and if we wanna use doctor efficiently
we have to rely on that party applications and third party tools and make use of them create
better locations especially if we're a moving into microsoft's
architecture where we where we have multiple containers
communicating with each other for multiple hosts then the drawback is that we have to learn new tools
i mean we as a developer at after soccer and all those talk a specific tools
and of course the operations people need to uh to learn those tools um on the other
hand the um the place i think few years old uh two years or something oh
it's it's it's very uh the first release was two years ago two and half years but
i think the the first public release of doctor was two dozen thirty the first
a a one zero releasable was to doesn't fourteen or something i'm not
sure but only a few years and we have a thousand hundreds
and thousands of of technologies around occur and how you can extend doctor
and how you need to extend docket to use it efficiently
and this is sometimes very very confusing are very difficult to pick the right tool i mean it's
difficult to find the right to and then if you find if you want is very difficult
pick the right to for your specific use case because all those tools that exist exists for
for for reason because they're different and it's it's sometimes it's very difficult to make a
a tool and also to stick with it because i know a lot of those tools
i going extinct in in months years and uh you don't wanna you know that
on i'm not from morse and last but not least there's that still up not yeah some
kind of a problem is that a lot of stuff the vendors not provide container
yet i mean there is something like a official containers in that in that document just
re joe called official but i mean they're not really official they're just officially him
managed by doctor incorporated but those are not official containers by the companies who rate is software
you know and off the we have software and operates to which is open source because
you can download you can start it there's not they're not many properties software i mean there is
no oracle database in in in the registry and not so many a commercially not open
source of the uh on on on the registry not yet at least and so this is
a bit of a problem for for at least a large corporations lotta conversations to
adopt doctor because they fear that there might be a um a problems yeah and that's it
for my talk i hope you have a good insight about the consequences of doctor and
how it will change your life or life if if you're working with it and how

Share this talk: 

Conference program

Jean-Baptiste Clion, Coordinator DevFest Switzerland
26 Nov. 2016 · 9:40 a.m.
How to convince organization to adopt a new technology
Daria Mühlethaler, Swisscom / Zürich, Switzerland
26 Nov. 2016 · 10:14 a.m.
Q&A - How to convince organization to adopt a new technology
Daria Mühlethaler, Swisscom / Zürich, Switzerland
26 Nov. 2016 · 10:38 a.m.
Animations for a better user experience
Lorica Claesson, Nordic Usability / Zürich, Switzerland
26 Nov. 2016 · 11:01 a.m.
Q&A - Animations for a better user experience
Lorica Claesson, Nordic Usability / Zürich, Switzerland
26 Nov. 2016 · 11:27 a.m.
Artificial Intelligence at Swisscom
Andreea Hossmann, Swisscom / Bern, Switzerland
26 Nov. 2016 · 1:01 p.m.
Q&A - Artificial Intelligence at Swisscom
Andreea Hossmann, Swisscom / Bern, Switzerland
26 Nov. 2016 · 1:29 p.m.
An introduction to TensorFlow
Mihaela Rosca, Google / London, England
26 Nov. 2016 · 2:01 p.m.
Q&A - An introduction to TensorFlow
Mihaela Rosca, Google
26 Nov. 2016 · 2:35 p.m.
Limbic system using Tensorflow
Gema Parreño Piqueras, Tetuan Valley / Madrid, Spain
26 Nov. 2016 · 3:31 p.m.
Q&A - Limbic system using Tensorflow
Gema Parreño Piqueras, Tetuan Valley / Madrid, Spain
26 Nov. 2016 · 4:04 p.m.
How Docker revolutionized the IT landscape
Vadim Bauer, 8gears AG / Zürich, Switzerland
26 Nov. 2016 · 4:32 p.m.
Closing Remarks
Jacques Supcik, Professeur, Filière Télécommunications, Institut iSIS, HEFr
26 Nov. 2016 · 5:11 p.m.
Rosie: clean use case framework
Jorge Barroso, Karumi / Madrid, Spain
27 Nov. 2016 · 10:05 a.m.
Q&A - Rosie: clean use case framework
Jorge Barroso, Karumi / Madrid, Spain
27 Nov. 2016 · 10:39 a.m.
The Firebase tier for your app
Matteo Bonifazi, Technogym / Cesena, Italy
27 Nov. 2016 · 10:49 a.m.
Q&A - The Firebase tier for your app
Matteo Bonifazi, Technogym / Cesena, Italy
27 Nov. 2016 · 11:32 a.m.
Hasan Hosgel, ImmobilienScout24 / Berlin, Germany
27 Nov. 2016 · 11:45 a.m.
Q&A - PERFMATTERS for Android
Hasan Hosgel, ImmobilienScout24 / Berlin, Germany
27 Nov. 2016 · 12:22 p.m.
Managing your online presence on Google Search
John Mueller, Google / Zürich, Switzerland
27 Nov. 2016 · 1:29 p.m.
Q&A - Managing your online presence on Google Search
John Mueller, Google / Zürich, Switzerland
27 Nov. 2016 · 2:02 p.m.
Design for Conversation
Henrik Vendelbo, The Digital Gap / Zurich, Switzerland
27 Nov. 2016 · 2:30 p.m.
Q&A - Design for Conversation
Henrik Vendelbo, The Digital Gap / Zurich, Switzerland
27 Nov. 2016 · 3:09 p.m.
Firebase with Angular 2 - the perfect match
Christoffer Noring, OVO Energy / London, England
27 Nov. 2016 · 4:05 p.m.
Q&A - Firebase with Angular 2 - the perfect match
Christoffer Noring, OVO Energy / London, England
27 Nov. 2016 · 4:33 p.m.
Wanna more fire? - Let's try polymerfire!
Sofiya Huts, JustAnswer / Lviv, Ukraine
27 Nov. 2016 · 5 p.m.
Q&A - Wanna more fire? - Let's try polymerfire!
Sofiya Huts, JustAnswer / Lviv, Ukraine
27 Nov. 2016 · 5:38 p.m.
Closing Remarks
27 Nov. 2016 · 5:44 p.m.

Recommended talks

Unknown author
3 Sept. 2012 · 1:51 p.m.