How I: Use a common code repo to pivot quickly Video Lecture | "How I" by Google Developers - IT & Software

[MUSIC PLAYING]
STEFAN RITTER: Hi guys.
I'm Stefan, and I'm working
on multiple projects
at the moment.
One is buzzr.io,
one is fitguru.org,
and one is pickfeed.io.
And today I'm going to talk
about how I use a common code
base to pivot to all
these different ideas.
While working on
different startup ideas,
I quickly realized there are
common parts to each idea.
So I created an abstraction
called emptyApp,
which combines these five
features that I singled out.
The five features are a landing
page with an email sign up so
you can go online right away
and start collecting emails
from people who are interested,
a client-agnostic API
server that doesn't care
if the front-end is a web
app or a mobile app, and
then a front-end app, which
for me usually is the web
app, since I think the web is
the biggest
[INAUDIBLE] platform,
and then a user model, since
you need to save your users.
And the fifth thing would be
a login authentication scheme
with Twitter,
Facebook, G+, or email.
Let's look at the five
features in emptyApp
as they come from the repo
when your freshly install it.
So this is emptyApp's
landing page
where you can collect
users' email addresses who
might be interested
until you launch.
So if you just enter
an email address here,
you can link it up
to a Mailchimp list
and collect email
addresses that way.
But then emptyApp also gives
you real login functionality.
So for example, if we
try to log on like this,
this user doesn't exist.
So obviously we get
an error message.
But then if we go to Join,
we can create this user.
And then now you're logged in.
So if we try to go
back to the homepage,
emptyApp will automatically
log you back in.
And you're landing on
the logged in home page.
There's also a
logged out future.
So you can just log out
again, and you're back
logged out on the home page.
And then, of course, you
can do all this as well with
all the social media logins.
So here we have
Twitter activated.
And then we log back in.
All right, now I'm going to show
you these features in action.
So if we go to buzzr.io,
you can see when you first
land on the app
there's a landing page.
But then over here
you see we have links
to the Join, links to the Login.
And once we're here, we can
log in with our user account.
And we land on the
logged in home page.
All right, now let
me show you what
the emptyApp looks
like on GitHub.
So if you go to my username,
stefanritter/emptyapp--
so there's a link right here
so you can download and clone
the app.
There are little instructions
on how to do the setup.
So it comes with a
Grunt file, as well as
scripts to do the testing
and a supervisor script
to watch for server changes.
So if you download the app,
and then you want to start it,
what you do is you CD into
the emptyApp directory.
And then you just
run the start script.
And what it will do is start all
the tests, the Grunt watching.
And from that point on,
you can demo the app
on your local host.
It's a MongoDB database,
so the whole app
is written in JavaScript.
All my apps are written
100% in JavaScript.
Because you can use
JavaScript on the front-end,
on the back-end, as well as
to talk to your database.
So there's less mental overhead.
For the database, I use MongoDB.
MongoDB is schemaless, so you
can change fields on models
very quickly, which is very
important when you're pivoting
between extreme different ideas.
For the front-end,
I use AngularJS,
which has awesome
dependency injection.
So it's very easy to
throw around features
within your app--
also, again, important
when you're changing
and pivoting ideas.
And then for the
server, I use Happy.js,
which is a server
built specifically
for being an API server.
So it's very great to be a
front-end-agnostic server
back-end.
This is the Grunt task.
The Grunt task just watches
for file changes and checks
the code and tells
you if something's
wrong and runs all your tests.
This is the Karma tab, which
runs all the front-end tasks.
And then this is the
Server tab, which
watches for changes
in server code
and restarts the
server if it finds any.
This is what the
folder structure
looks like of the code.
There are three main folders
for you to watch out for.
There is the Client
folder, the Server folder,
and the Test folder.
It's quite self explanatory
what each includes.
But it's important to point out
that the client and the server
are completely separate.
So this is the
client-agnostic API server
I talked about previously
where the client could
be, in this case,
an AngularJS app.
But it could also just be
an iOS app or an Android
app that talks to your server.
And so what happens is if
you change something here,
Grunt will monitor
the change, and then
build the front-end code again
and inject it into the server.
So the server will serve
the updated app for you.
So the other thing we talked
about is the user model.
So if you look into
the Server folder,
you can see it comes with just
one model, which is the user.
The user model comes with
just the basic things
you need, like username,
display name, email,
[INAUDIBLE], and passwords.
The controllers are
also very simple.
Their authentication controller
handles all the login stuff
that we previously looked at.
There's a feed
controller that simply
serves the logged in homepage.
There's also a
little bonus here.
For real time chatting,
there's a Socket.IO set up.
So under Config, there's
a little Socket.IO setup
where you can then send real
time messages back and forth
to your clients.
And so this is how I
use my common code base
to create all these
different ideas.
You can check it out on GitHub.
It's on my user name, and then
the repo is called emptyApp.
Thanks for watching.