Technical and Deployment Architecture (Part 3)

Loading...

Del curso dictado por Johns Hopkins University

Capstone: Photo Tourist Web Application

18 calificaciones

Johns Hopkins University

Capstone: Photo Tourist Web Application

18 calificaciones

Curso 6 de 6 en SpecializationRuby on Rails Web Development

In this Capstone project for the Photo Tourist you will implement a Ruby on Rails web application that makes use of both a relational and NoSQL database for the backend and expose the data through services to the Internet using Web services and a responsive user interface operating in a browser from a desktop and mobile device. You will have a chance to revisit and apply what you have learned in our previous courses to build and deploy a fully functional web application to the cloud accessible to your co-workers, future employers, friends, and family. In developing the Photo Tourist web application, you will get to work with different data types and data access scenarios (e.g., fielded data display and update, image upload/download, text search, access controlled information) to provide your users the ability to show off their photos and information from trips they have taken and to seek out photos and information from trips taken by others. Using the application you develop, your users will be able to • Create an account • Upload and download photos to the site and make them accessible to others • Provide descriptions of trips and photos that others can read • Organize photos by location and trip, • Find photos based on location • Find photos based on text searches of descriptions • Locate the place where the photo was taken on a map

De la lección

Technical Architecture and API Development Setup

In this module, we will start your journey into being part of an end-to-end application development as a Rails/AngularJS fullstack developer intern. You will learn the technical architecture and software requirements of the targeted application you will be a part of developing. You will also get a chance to shake off any rust that may have accumulated on your Rails development skills. As a part of the technical architecture, you will learn of the various layers, technologies, libraries, and services used in the development, deployment, and operation of the targeted application. You will get an early sense that this course is "no joke" when it comes to challenges, but you will be shown a path through most of them. You may be able to skip the application installation until the end if you are using the same computer that you used in the first five (5) courses of the specialization. None of the new software installations are required for this module -- but are included in a single lesson for modularity. You will develop an end-to-end, API-to-Database, resource solution for ActiveRecord/RDBMS and Mongoid/MongoDB using Rails scaffold generator. You will establish a Git repository for this work, provision database and Rails resources on the internet for staging and production deployments, and deploy your solution to the Heroku to be accessible from the Internet. If you are a seasoned Rails developer and competent with ActiveRecord, Mongoid, and Heroku -- you may want to initially skip the review lectures, review the final Git commit for module one (1), and try your hand at the optional assignment at the end. Aside from the technical architecture lesson, this module is mostly a quick breeze through many of the topics of courses one (1) through three (3). A similar, small-scale review of courses four (4) through five (5) will be covered in the next module. Please enjoy! Also, if you have not done so already I recommend that you read the Course Overview description which provides additional context on what you will be doing in this course. To access, please click the Resources tab on the left navigation.

Course Introduction7:15

Module 1 Introduction3:44

Technical and Deployment Architecture (Part 1)11:22

Technical and Deployment Architecture (Part 2)14:31

Technical and Deployment Architecture (Part 3)14:15

Development Environment Setup4:56

Software Installation: MacOS13:49

Software Installation: Specifics for Windows29:39

Software Installation: Specifics for Linux and Docker15:49

Conoce a los instructores

Jim Stafford
Adjunct Professor, Graduate Computer Science
Computer Science, Whiting School of Engineering

[MUSIC]

Hello, welcome back.

In this topic, we're going to finish out the technical architecture,

talking about some of the remaining topics that aren't in the core application.

And we deal with testing and development.

And then we'll move on to some more deployment topics.

And the actual architecture of deploying the API and the database to the web.

And then some other options having to deal with the web client deployment.

And that will finish up our overall topics.

I'm sure you noticed as we were going through the technical architecture

that there was quite a few things that we were addressing

within our application that we have to pull together.

And the only sane way to be able to do that Is to be able to direct our

development towards our goal, and to be able to verify that our

application works as we work through the different levels and complexities.

And the way we do that is through testing.

Our testing is at three levels.

Model, think database when I say that, requests,

think the rest to API to the controller to the database when I say that.

Feature, think from button click

to API to controller end database and back when I say that.

We will be doing no mocks as a part of the capstone.

Everything will go from our point of testing down to the database and back.

The first two levels are handled pretty much by the RSpec core.

RSpec is a Ruby test framework with rich expression.

And when I say rich expression, think English.

There is a way that you can, through non-technical terms,

really talk about what the application needs to do under certain conditions.

And that can make up our acceptance test-planning.

This is what we need to do.

And we'll follow some of that acceptance test-planning as we get a little bit later

in the course, and

we pretty much get in the groove of how we're going to do our testing.

Very soon after acceptance testing we start to develop the details of test.

How it's going to pass,

under what conditions and how we're going to verify certain things.

And then with those written tests we go off and

we write implementations that are looking to pass those tests.

And then do a couple of gyrations to make sure that we.ve refined things.

Supporting our spec are a couple of libraries.

First of which, I'm going to talk about is factory girl.

Many times in the test you need an example object.

Give me an image, give me a thing, give me an address.

And you need some rules of how you're going to build things.

FactoryGirl is a factory of objects that allows us to describe or

define how those are going to get built.

And they can be as simple or complex as we want them to be.

Faker, it's a fun little library.

Random data is just fun.

You can think of, you make up team names, you make up addresses, you make up

thing names, or captions, It gives us sort of like a, instead of one, two, three,

or a, b, c, d, e, f filling p a page, it will make up data.

And it has lots of different types.

As I said, it's a fun library to kind of toss in.

So as you see, some nonsensical words, and some

things that I'm going to put up there, they were all generated through Faker.

Database cleaner, when we do our tests, we typically

want to have the database clean when we start, and the database clean when we end.

And we don't always know what things to clean, what things are there.

So Database Cleaner pokes into the database, understands what's there,

understands what it shouldn't touch, like migration data.

And has the ability to destroy all information that's in

there that we need to get rid of in order to conduct our tests.

Cabybara rise on top of RSpec and allows us to do the feature testing.

Which was the last one third of the layers that I have described earlier.

It is focused at Web UI Testing, which means it understands mouse clicks and

filling in fields, and things like that.

It is probably the hardest thing to get your head around,

because testing web UIs is difficult because of their asynchronous behavior.

When you make a request you don't know whether something's going to come

back in 1 second, 5 seconds or 25 seconds.

And whether you should be timing that out and failing, or you should be waiting

longer because the platform that you're running on operates at different speeds.

So, there are times where if you're dealing with a native app browser and

you're in your development environment and you're running at one speed.

Or you're dealing with a headless browser, check into a build server, and

you're running at much slower speeds.

I will admit upfront that it's probably one of the hardest things to get your

head around, but it does get better with practice.

As a I eluded to earlier, our tests are going to run in different environments,

in which there are about three different drivers that help support that.

The RackTest driver is the default driver of RSpec and Rails and

it's the driver that we're going to use when we communicate via the API test.

It has poor support for Vanilla HTML and

web services, but it has no support for JavaScript.

So in order to do JavaScript we are going to need the two drivers that we're going

to talk about next.

Everything runs in the same process.

So if you wanted to take advantage of database rollbacks as a part of your

cleanup, you could, with a RackTest driver.

One of the optional drivers to add in, or not so

much optional if you're going to be doing JavaScript, is the Poltergeist gem.

With that wraps around the PhantomJS native application that we're

going to have to install locally on our boxes by having Poltergeist and

PhantomJS installed.

We're going to be able to write Capybara RSpec test that talk about

going to a web page and making various button clicks.

And nothing is going to appear on our screen.

We may not author our tests that way, we may actually author it in Selenium.

However, when we check it in,

this is probably the most likely scenario which we're going to check things in in.

It does run much faster than Selenium, but we can't see it.

And so, when things go bad, what we have to do is rely on certain commands

that will product images of what is on this headless display.

Selenium on the other hand, the gem that allows us to talk to the core selenium and

selenium is a wrapper around, basically chrome and

Firefox, there is an actual browser involved.

So when we write a text using Selenium, we'll see a browser pop up and

buttons are clicking in mouse and everything is moving around the screen.

If we want to slow it down, well we can put breakpoints in our code,

and walk through that way.

But it provides a nice interactive way to see what our test is doing,

what's on the page, pause our tests using standard breakpoints,

inspect the page, and to be able to complete our tests.

We should all realize that testing your application is

a very important part of developing an application.

And testing is treated as a first place citizen within captcha.

I just want to say few quick word about the development, environment and tools.

We all should be aware that Rails Console on the IRB Shell there comes with it and

we used that to the great extent in courses one, two and three.

But there is also another optional shell that we can install

into Rails called the Pry Shell.

Which is very feature rich, we'll be able to do things like inspecting objects and

looking at source code to objects as we are stopped in various break points.

So thinking more about debuggers,

we shouldl all be aware of the Byebug debugger from the earlier courses.

Where we could define a Byebug breakpoint, rerun our application,

and it will pause at that point, and then we can step through our code,

look around at the state of our system while we're under test.

We can also integrated Pry into Byebug, so

that we have access to the Pry shell when we execute our tests.

And then on the browser side, we of course can take advantage of

Chrome Developer Tools, and Firefox Developer Tools, or any of the other ones.

But I'll be primarily using the Chrome Developer Tools

that allow us to look at the DOM elements, console logs, and

the network activity that's going between the browser and our API.

At this point, we pretty much finished describing the overall

context of the technical architecture that was going to be involved in the course.

And I'd like to get into more of the deployment aspects.

When we deploy our application to the web,

we're going to be deploying to two primary environments.

Heroku and mLab.

Heroku is going to deploy the both of the application.

the Rails application server, Image Magick, image manipulation software,

and Postgres through normal provisioning techniques.

mLab is going to require some separate setup, and

you went through that separate setup apart of course three.

Now, what we're also going to do is not only have a production

URI that we're accessing, but we also want to set up a staging environment.

So the thought is that only completed code,

only code that we want others to see, would go into production.

Whereas staging, or

we could have any number of staging environments, in our Heroku environment.

From a single git repository, I could decide to push it to staging,

staging, staging, and then we can look complete, I can then go to production.

When we deploy our angular code as a part of our web client application,

we have a few options.

The first option is the simpler option

where we deploy our web code as a part of our Rails application.

What we do is we enable Asset Pipeline, and we deploy the web

client within Asset Pipeline, like a standard Rails application.

Except when it talks to the server,

it talks to the external API, so the API really could be anywhere in the world.

We still have separation of architecture.

The nice thing about this is it's a single code base, single deployment,

very easy to manage up and down.

The bad parts are is we are within the asset pipeline.

And it doesn't exclude use of tools,

it just adds a unique aspect to it that may not be totally conducive

to some of the external web development tools that want to stay agnostic to Rails.

The other technique is more consistent with what you did in course five where

the restaurant app is deployed to Heroku and is exposing just the API, and then

we can deploy our web client to to let's say GitHub And do that communication.

We can enable that in the caption as well.

Nice thing about this is we does enable us to use a full suite of development tools,

building modules and dependencies, and all kinds of things.

However one of the down size is

we've gotta repeat a lot of the things that Asset Pipeline gave us for free.

A third way is a hybrid between the two.

Where we develop our application as an external application.

However, we finally package it up and publish it within the public folder

of Rails, and just use Rails as a web server, and then deploy that to Heroku.

In this third technique,

the Asset Pipeline is not involved, we are just the application.

Instead of being deployed at GitHub is deployed to Heroku within

the public folder.

Now we will cover all three techniques in the development area and

we will have a chance to have some practice for those three.

But when it comes time to developing the bulk of the code the application,

I'm going to revert my examples back to the simpler asset pipeline technique.

All the code will look and feel the same as if they were in any of the other three.

So you're free to try or use those other techniques.

However, my examples are going to stay in the Asset Pipeline, because its

much simpler in environment to work with, and share the examples between you and I.

That concludes our summary overview of the technical and deployment architectures.

Where we finished up topics of testing and development in the technical aspect.

And under deployment we looked at how we're going to deploy our API database and

some options to the web client.

Next, what we're going to do is go through some of the details of setting up

the development environment that's supports a lot of the things we talked

about in the technical architecture.

Explora nuestro catálogo

Inscríbete de manera gratuita y obtén recomendaciones personalizadas, actualizaciones y ofertas.

Coursera brinda acceso universal a la mejor educación del mundo, al asociarse con las mejores universidades y organizaciones, para ofrecer cursos en línea.

© 2018 Coursera Inc. Todos los derechos reservados.

Descargar en la App Store

Consíguelo en Google Play