Video #1 - Application Environments

Loading...

来自 University of New Mexico 的课程

Web Application Development: Basic Concepts

117 个评分

University of New Mexico

Web Application Development: Basic Concepts

117 个评分

This is the first course in a Coursera Specialization track involving Web Application Architectures. This course will give you the basic background, terminology and fundamental concepts that you need to understand in order to build modern full stack web applications. A full stack web developer is familiar with each "layer" of the software technologies involved in a web application, including data modeling and database technologies, the web server environment and middleware components, network protocols, the user interface and basic visual design and user interaction concepts. In this course we will learn by doing. We will start by learning the major components of web application architectures, along with the fundamental design patterns and philosophies that are used to organize them. You will build and continually refine a fully functional full-stack web application as we progress through the modules in this course. Along the way you will be exposed to agile software development practices, numerous tools that software engineers are expected to know how to use, and a modern web application development framework. This course is also available in Spanish. To join the Spanish version, visit this page: https://www.coursera.org/learn/apliweb.

从本节课中

Module #3 - Managing Data

A successful web application provides information t o users that is (1) useful, and also (2) easy to access and understand. This information is often collected from users, as well as from other information sources, and must be stored in a manner that allows it to be manipulated by the web application. The typical app roach is to store this data in a relational database. In this module you will learn some basic concepts associated with modeling the data in a web application, including h ow to specify the relationships between various data entities. We will also investigate ho w to hook a web application up to a back- end data store, along with good design techniques t hat will make it easier to use the data in your web applications by maintaining consistency th roughout the entire web stack.

Database Integration in Web Apps - An Overview0:27

Video #1 - Application Environments6:52

Video #2 - Database Configuration4:37

Video #3 - Database Management3:39

Video #4 - Blog App Databases6:25

与讲师见面

Greg Heileman
Professor and Associate Provost
Electrical and Computer Engineering
Manel Martínez-Ramón
Professor
Electrical and Computer Engineering

[MUSIC]

It's common for development teams to support a number of different application

environments as a part of their development activities.

Each of these environments might have a different configuration

depending on the task that it's being optimized for.

Let's start by considering the most common application environments for

developers to work in.

The development environment is the one configured for

an individual developer's computer.

This environment should be set up to make the developer's job as efficient as

possible.

In this environment,

you don't want developers spending a lot of time configuring database servers and

web servers, you want them writing the code that defines the application.

Thus, you'd like the development environment to be set up to manage

the mundane aspects of development, so that

developers can focus on the novel aspects of the application they're building.

The testing environment is set up to allow for testing of the application as a whole,

and this could mangle the database.

What I mean by this is that this database is set up to test the application's

functionality and make sure the application does what it's supposed to do.

So we often use fake data in this environment, it's loaded into the database

prior to testing and then the database is destroyed after running these tests.

The next is the staging environment.

This mirrors the production environment that's used for final testing.

You don't want to push your changes to the production environment when you're editing

code without first testing

that the changes work in an environment that mirrors the production environment.

So with this environment, you're testing that the deployment itself works.

Finally, there's the production environment itself.

This is the one that the application will be deployed in.

This is the environment that's used when you deploy your application for

the world to use.

Rails automatically set up applications to run in one of three prebuilt environments.

And you can also create your own environments if you want to.

The three that Rails provides include the development environment, and in this case,

classes are loaded on every requests, so this is useful for debugging.

Because of this, there's no need to restart the web server if you need to make

edits to your model, viewer or controller code.

You just make another web request and then the new classes are automatically loaded,

the ones that you've edited.

In addition, caching is turned off and there's a lot of

debugging information that's rendered in the web page if an error is encountered.

Rails also sets up a test environment, this includes a separate database.

And automated tests that are applied to this database.

So, the database is set up prior to testing and

destroyed after testing is completed.

The production environment that Rails sets up is optimized for

delivery of assets to the client, when you're running in the production mode.

It does this by turning on caching and handling errors more efficiently.

By default, when you type rails server at the command line,

it starts the application running in the development environment.

So this is what we've done so far.

If you'd like to start it in a different environment,

type rails server -e, where the e stands for environment.

You could also spell out environment and

then describe the environment you want it to run in.

So in this case,

it would run in the production environment if I issued this command.

Now the different environments are defined in the directory config of your Rails app,

at the root of your Rails app.

Look at config/environments and then you'll see three Ruby files, one for

production, one for development and one for testing.

Now, the different gems that are included in each environment are specified

in the Gemfile.

Let's take a look at these things in the blog application.

I've opened up an operating system command line window at the root

of my Rails blog app.

And if I'd like to see information about the app itself, I can type rake about.

And you'll see that it tells me right here that I'm running

in the development environment.

You can specify the Rails environment you want to run in when you execute rake or

Rails commands.

And here's how you do it, you type RAILS_ENV and

then you specify the environment that you want to run in.

And then the command you'd like to execute.

So I'm going to execute the same one, rake about,

but now I'm going to do it by running in the production environment.

And you see it'll tell me about the same,

except here it says that I'm running in the production environment.

One more thing I'd like to show you.

Open up IRB by doing rails console.

And you can always find the development environment you're

running in from within this console by typing Rails.env.

And here it tells you that you're running in the development environment.

In an editor, I've opened up my blog project, and if you go under the directory

config, and then under the directory environments, you'll see three Ruby files.

Let's take a look at the development one and you'll see all of the commands that

are used to set up your development environment here.

We can take a look at the production environment and you can read through all

the comments there and see the differences between these environments.

If you'd like to create your own environment,

you could start by tweaking one of these environments and

then store the new environment with a different name in this directory.

Let me take a look at the gemfile next.

At the top you'll see a list of gems that are going to get loaded into every

environment, and then down here, there's a group command.

And next to it, it says development and test.

So the gems within this block will only be loaded into the development and

test environments.

I'm back in an operating system command line window.

And I want to show you what happens when I type rails server.

One thing I want to show you is you don't actually have to type out server.

I can just say rails s and you'll see that it's going to open up the server,

the web server in development mode.

The entire environment, in fact, in development mode.

I'm going to Ctrl+C out of this and I'm going to show you that I can do this in

the production environment by typing rails s -e for environment and then production.

And you'll see that the Rails application will now start up in production mode.

Again, I'm going to Ctrl+C, and I could accomplish the same thing that I

just did by typing RAILS_ENV as I showed you before, specifying that I'd like

to run in the production environment and then just typing rails server again.

And you'll see that in this case, it's going to, again,

open up in the production environment.

So, you've seen now how you can run Rails in a variety of different environments.

And you've also seen how Rails is set up to configure the specific

elements of those environments.

探索我们的目录

免费加入并获得个性化推荐、更新和优惠。

Coursera 致力于普及全世界最好的教育，它与全球一流大学和机构合作提供在线课程。

© 2018 Coursera Inc. 保留所有权利。

通过 App Store 下载

通过 Google Play 获取