Explore
For Enterprise
Join for Free
Log In

Artes e Humanas
Negócios
Ciência da Computação
Ciência de Dados
Tecnologia da informação
da saúdesaúde
Matemática e Lógica
Desenvolvimento Pessoal
Ciência e Engenharia Física
Ciências Sociais
Línguas
Notas
Certificados

Explore todo o Coursera

Navegar
Pesquisar
For Enterprise
Entrar
Inscreva-se gratuitamente

Technical and Deployment Architecture (Part 1)

Loading...

Trabalho de conclusão de curso: aplicação web para fotos turísticas

Universidade Johns Hopkins

4.7 (19 classificações) | 304 alunos inscritos

Curso 6 de 6 no Desenvolvimento Web com Ruby on RailsDesenvolvimento Web com Ruby on Rails Programa de cursos integrados

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

Visualizar o programa do curso

Habilidades que você aprenderá

Ruby On Rails, Angularjs, Web Development

Avaliações

4.7 (19 classificações)

5 stars
14 ratings
4 stars
5 ratings

EA

Apr 15, 2017

Great Course Jim has really thought me more than enough to get my career started. All a student has to do is just study.

KT

May 04, 2017

Excellent course. Mr. Stafford is a very good teacher.

Na lição

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

Ministrado por

Jim Stafford
Adjunct Professor, Graduate Computer Science

Transcrição

[MUSIC]

In this lecture, we're going to be talking about Technical Architecture,

the capabilities and technologies that'll be making up our solution.

And we're going to be breaking that down into layers so it'll be easier to talk to.

We'll also address the Deployment Architecture.

How we're going to take things like the API and the database and deploy them

outside of the development environment and make them accessible by the Internet?

And how we have different options in how we're going to be deploying

our web client?

Now some people might think of this lecture as a bit of an alphabet soup.

We're going to be talking about a lot of capabilities and

technologies in a short amount of time.

But I would prefer to think of it as an organized walk-through of vocabulary

that's going to span the overall course.

And hopefully build an overall bounding context

to what you're going to be learning in order to build

an end to end full stock application that we're going to be able to access and

collaborate, and administer, dealing with photos, information in that.

When we go over to the technical architecture,

we'll be going over bottom to top as you see them laid out in this diagram.

And we will be covering about seven areas within the application before following up

with two areas of development and testing and then wrapping up with deployment.

Let start out by talking about where we're going to store things,

whether they'll be in a database or a file.

On the relation database side,

we have access to two databases, SQLite and Postgre.

SQLite comes with Rails but think of it as more of like an early learning database or

the database that you would use if your application have very low

dependency on SQL constructs.

PostgreSQL on the other hand is a fully supported production database

that you use during Course 2 when you deployed to Heroku,

except that in Capstone I'm going to promote that you use it during development

as well to lessen the transition between development and deployment.

To cut down on the amount of time that when you go to deployment you find out

I gotta fix this, I gotta fix that.

Why don't we have the same thing in both environments?

Our interface to the database is primarily going to be ActiveRecord that puts a very

nice Object/Relational Mapper in front of us, where we talk objects and

methods to our data.

There are times,

however, when we're going to want to drop down into SQL for complex queries.

Cases where we might build up snippets of where clauses and select clauses or

there are going to be times where we're going to want to do full scale just raw

sequel commands, like for the unions and things, to give us more power.

During the course of the semester we're going to be using the relational database

to store our core business objects and their relationships.

They could have been stored in Mongo but our choices would have been more limited,

and we have much more flexibility by storing them into the relational database.

We're not tied down since we don't know all the ways that we're going to want to

use the application.

We're also going to use our relational database to store user accounts.

Now we could have put our user accounts into either the relational database or

Mongo, however, there were certain gem choices made

that forces to stay into the relational database side.

We're also going to make use of the MongoDB No SQL Database as part of

the course.

Primarily as a content store and a persistent cache.

This of course consists of MongoDB and also we're going to

use Mongoid as the object document mapper as we did in course 3.

It provides a nice active record like interface to the back end document store.

We're not going to be making use of GridFS as we used in course 3.

And we're not going to need to drop down to the raw MongoDB Ruby API.

The Mongoid API is going to be good enough for

how we're going to use Mongo as a part of the course.

Now, as I said, we're going to use MongoDB for storing image content.

One of the primary obstructions for storing image content is a file.

And many of the gems that we had as a choice of using if we had used the file

obstruction, we could have used them right out of the box, and then you could have

done things a lot more seamlessly than we'll be doing in the course.

However, when you go from development to deployment in Heroku,

there is no such thing as an out-of-the-box writable

persistent store that's guaranteed to be there during the life of your application.

What you need to do is bring in sort of like an Amazon File Services and

things like that.

And rather than do that, I was like, we'll we have Mongo, why don't we just go in and

use it kind of like we did in course 3, where we were restoring files in there.

Except there was no need to bring in GridFS.

Because everything's going to be a bounded size under 16 megabyte document limit.

And they're not going to be infinite in size.

So rather than using GridFS,

you just use the BSON::Binary type and store it within a document.

Those documents were related to our relational database which

has the business object that we have a photo on file.

In Mongo we're going to store the actual content of the photo and

serve that out to our users.

Also going to use it as a persistent cache.

We're going to contact the Google geo code API in order to find positioning.

Well, we are metered in how many requests we make.

And Google advises us that we ought to cache the answers that come back.

And this is exactly what we're going to do inside of Mongo.

We're going to normalize our query parameters and use those as primary keys

into the cache, and then we're just going to store the resulting document so

that follow on calls, we're not having to go out to Google but

we can just grab what it said the last time.

Pretty neat, very easy.

On the browser side, we're not going to make direct use of any file storage.

However, we are going to use a module, the ng-token-auth module that's

going to store Current login information into the Browser Cookie Store so

that when we refresh the browser or come back another day, we're not going to

have to constantly re-authenticate ourselves with the application.

Let's take a look at some of the application frameworks and

languages that we'll be using during the scope of the course.

On the server side, of course we're going to have Rails.

And we're going to stick to version 4 in order to be consistent with the first

three courses that you've taken.

Even though version 5 has been out, it won't be a problem.

But if you're Googling and you find yourself on a Rails 5 documentation site,

please be aware that you might be looking at some Rails 5 specific extensions.

I find that not to be a problem much at all.

And if it did was a problem, it was more esoteric areas and ActiveModel.

But I don't see it being an issue.

On Web Servers, version 4 comes with WEBrick.

Version 5 is apparently switching to Puma.

It's just a different web server.

You can put WEBrick back in.

There are other web servers that we won't be discussing during class like in

the past I've used the Thin, T-H-I-N web server.

I liked it because on the platform I was developing on from command lined up and

running was fractions of a second, whereas WEBrick, in that particular

platform I was using on actually took tens of seconds to come up.

The actual servers themselves.

WEBrick is more development, single threaded, pretty mundane.

And when you deploy, I guess you can deploy the WEBrick.

But in this course I'm going to

try to get you use to being able to switch web servers.

So develop however you want to develop, WEBrick or Puma and

matter of fact if you're on Windows you're going to be forced not to develop in Puma.

But Puma is multi-threaded environment which obviously is a much better for

production.

But not necessarily for development.

Like for example, I find that if I'm debugging a live application server and

I put a byebug or a binding pry breakpoint in the server.

If I'm in WEBrick, everything seems sane.

It stops and continues and lets me stop it as long as I want and go around.

Whereas in Puma and that multi threaded environment, if I pause

the application server for more than about 30 or 60 seconds I

pretty much have to trash that session and restart a new one in order to continue.

It doesn't play as well with breakpoints.

But it starts up pretty quick and I typically use it

as a default because most of my debugging is in my unit testing.

One of the other things that we're going to be adding to Rails is the API to

the Rails-api gem.

And what that does is, it scales back Rails into a set of

gems that are geared more towards just being an API and

database server on the web.

It takes away, by default, some of the things that you're used to with views and

the asset pipeline but we can put them back and as a part of this course I'll

show exactly how to put them back into the overall framework as we need them.

We're also of course going to be using ActiveModel and Ruby which could

be infinite in what we talk about in this marvelously dynamic language.

On the client side, we're going to be making use of, of course, AngularJS

version 1.5 in order to stay consistent with what you covered in Course 5.

AngularJS is a Javascript framework and

it helps us build components that are going to manipulate

HTML with the use of CSS in order to give ourselves a nice client interface.

As we take a look at the languages involved in our full stack solution,

Ruby, Javascript, HTML, CSS, you're going to find yourself with plenty of

opportunities to make some tactical errors because you're thinking

that your fingers were thinking that they're in the previous language.

Don't be too hard on yourself, it happens to me all the time.

So if you spend a better part of the week working on the JavaScript side of

the house and then you go work to Ruby and start writing the Ruby with

a JavaScript-ish Syntax it may take you an extra couple of minutes to

remember some of your old tricks but you'll be fine.

I'm want to pause coverage of the technical architecture where

in this one we got the ball rolling, talking about the overall scope.

And the first two of the seven core application areas that'll be part

of the Capstone and those two areas being in the database in persistent storage and

application frameworks.

Up next, well we'll finish out the topics.

The seven core topics plus testing, development, and deployment.

Explore nosso catálogo

Registre-se gratuitamente e obtenha recomendações, atualizações e ofertas personalizadas.

O Coursera proporciona acesso universal à melhor educação do mundo fazendo parcerias com as melhores universidades e organizações para oferecer cursos on-line.

© 2019 Coursera Inc. Todos os direitos reservados.

Baixar na App Store

Baixar no Google Play

Coursera
Sobre
Liderança
Carreiras
Lista de cursos
Certificados
Certificados MasterTrack™
Notas
For Enterprise
For Government

Comunidade
Learners
Partners
Developers
Beta Testers
Translators

Conectar
Blog
Facebook
LinkedIn
Twitter
Instagram
YouTube
Tech Blog

Mais
Termos
Privacidade
Ajuda
Acessibilidade
Imprensa
Contato
Diretório
Afiliados