0% found this document useful (0 votes)
39 views

FSD-Module 1

full stack development notes

Uploaded by

sudhanva0703
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
39 views

FSD-Module 1

full stack development notes

Uploaded by

sudhanva0703
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 20

Module 1: MVC based web designing

Web framework, MVC design pattern, Django evolution, Views,


mapping URLs to Views, working of Django URLconfs and loose coupling,
errors in Django, wild card patterns in URLs.

Introduction about Full Stack Development:


Full Stack development is the process of developing both the front end and back end of
applications. Any application has a front end component (user facing) and a back end component
(database and logic).
Front end development: It is the visible part of web application which is responsible for user
experience. (ie) The user directly interacts with the front end portion of the web application.
Languages - HTML, CSS, Javascript
Front end libraries and frameworks - Angular JS, React JS, Bootstrap, jQuery
Back end development: It refers to the server side development of web application. It is
responsible for managing the database through queries and APIs by client side commands. The
back end portion is built by using libraries, frameworks and languages.
Languages - C++, Java, C#, PHP (server side scripting language designed specifically for web
development), python (it works quickly and integrate systems more efficiently).
Frameworks - Express, Django, Rails, Spring etc.

Javascript is essential for all stacks and it is dominant technologies on web.

Database: Database is a collection of inter related data which helps in efficient retrieval, insertion
and deletion of data from database and organizes the data in the form of tables, views, schemas,
reports etc.
Oracle: Oracle database is the collection of data which is treated as a unit. The purpose of this
database is to store and retrieve information related to the query. It is a database server and used
to manage information.
Mongo DB: Most popular NoSQL database is an open source document-oriented database. The
term NoSQL means non-relational. MongoDB is not based on the table like relational database
structure but provides an altogether different mechanism for storage and retrieval of data.
SQL: Structured query language is a standard database language which is used to create, maintain
and retrieve the relational database.
Popular Stacks:
MEAN stack- MongoDB, Express, Angular JS, Node.js
MERN stack- MongoDB, Express, React JS, Node.js
Django stack- Django, Python and MySQL as database
LAMP stack- Linux, Apache, MySQL, PHP

Introduction about Django:


Django is an open source web framework used for creating python based web applications.
It is highly customizable architecture. It was first publicly released in 2005. Since Django remains
as an open source no single company fully controls how Django is developed. Instead Django is
maintained by the non-profit Django software foundation.
Python frameworks - Django, Flask
Django - large, complex projects that require functionality and special features
Flask - small-scale web application projects.
Major features of Django:
 Templating
 Admin interface
 Object Relational Mapping (ORM)
 Testing framework
 Form handling and session management
 Role based permissions
What are the files created while starting a Django project?
 manage.py: a module that provides commands for editing and interacting with the project.
 _init_.py: an empty file indicating that the current directory contains a python project
 settings.py: the current project settings
 urls.py: the project URLs and this file is used to store all the links of the project and the
function call.
 wsgi.py and asgi.py: These files help the Django application communicate with the
webserver.
What are the files created while starting a Django App?
Just like for the Django Project, Django App also has a set of files. They are:
 _init_.py
 admin.py: is for setting the models into the Django administration. Not to create the admin
interface as it is pre-built.
 apps.py: This file is associated with the configuration of the apps. Usually, the default
configuration is enough, and rarely have to touch this file.
 models.py: holds the models of the web applications.
 views.py: This is an important file, and it holds all the views. The views are usually stored
as classes.
 urls.py
 tests.py: contains different test cases for the application. tests.py will be used to test the
application.
What is the terminal command to start a server in Django?
python mange.py runserver in the terminal to start a server.
Creating the Project:
create a new Django project called mysite.
$ django-admin startproject mysite
This will create a mysite directory in the current directory.
mysite/
manage.py
mysite/
__init__.py
settings.py
urls.py
wsgi.py

The outer mysite/ is a root directory is just a container for the project. Its name doesn’t matter to
Django; can rename it to anything.
manage.py: A command-line utility that lets to interact with this Django project in various
ways. Use manage.py to start the project webserver, migrate the database, and other
interactions.
The inner mysite/ directory is the actual Python package for the project. Its name is the
Python package name so need to use to import anything inside it (e.g. mysite.urls).
mysite/_init_.py: An empty file that tells Python that this directory should be considered a
Python package.
mysite/settings.py: Settings/configuration for the Django project. This file contains
information about the database connection, time zones, included packages, etc.
mysite/urls.py: The URL declarations for this Django project, a “table of contents” of the
Django-powered site.
mysite/wsgi.py: An entry-point for WSGI-compatible web servers to serve the project.
(WSGI-Web Server Gateway Interface)
How the Django architecture work:
It follows the Model-View-Template (MVT) architecture pattern.
Models- describe the data structure and database scheme
Views- retrieve data from the model, perform calculations on the data and contains what people
can see.
Template- control how data is presented to someone, including which Views to display and how
to format them.

Difference between Django app and Django project:


Django app- Is a single web application that was created for a specific purpose, such as storing
employee records or processing payments.
Django project- Is a collection of apps that in combination provide a full range of services and
functions of a website (both store employee records and process payments).

What kind of database does Django support?


Django officially supports MySQL, PostgreSQL, Oracle and SQLite.

Why Django?
1. It has extensive code libraries and enables developers to reuse chunks of code instead of
writing an entire application from scratch.
2. It comes with a number of in-built functions such as REST framework for creating APIs
integrate with various database and does not require any third party extension to operate.
3. The range of Django web applications include MVPs and prototypes, content management
systems, e-commerce, e-learning, mHealthplatform, collaboration software, online
marketplace.
4. Django is written in python and provides a set of tools and libraries to help you built web
applications quickly and efficiency.
5. Simplicity, Security, excellent documentation, extensive code libraries and the support of
fast-paced development.

Which Company using Django?


Instagram, Spotify, YouTube, NASA, Google, Mozilla, Pinterest uses Django for their
company website and for building the app.

As of today Django apps are extensively leveraged for projects involving AI, Machine
Learning and BigData.
Django is primarily used for back end development. It can be used for front end development
despite it is not its main focus.

Pros and Cons of using Django:


Pros:
1. Fast and efficient due to reusable code and libraries of readymade elements.
2. In built admin panel is generated automatically once you start the development.
3. Wide variety of application- the range of apps Django can built includes both large and
small solutions.
4. In built SEO (Search Engine Optimization) tools- enables to build a website and optimize
it for search engines on the go.
5. Supports Object Relational Mapping (ORM)- automatically translates python code into an
appropriate query language.
6. Security- regular security fixes ensures that Django stands up against cyber security
threats.
7. Convenient development environment- clean, simple and easy to understand.
Cons:
1. Resource intensive- consumes a lot of disk space and memory.
2. Too much for small scale project- with in-built libraries and all, Django may get too large
for small project.
3. Learning Curve- At least some python knowledge is necessary.
Deep knowledge of Django is required for correct implementation.
4. ORM is always on and cannot be disabled.
5. Requires explicit definitions and has no coding conventions.

When to use Django for the project?


1. Advanced customization
2. A marketplace or an online banking service
3. Large scale projects in need of constant updates.
_____________________________________________________________________________
Web developers wrote every page by hand. Updating a website meant editing HTML, a redesign
involved redoing every single page one at a time.
Mosaic- first graphical web browser developed by NCSA (National Centre for Supercomputing
Applications)
Protocol used- Common Gateway Interface (CGI) - dynamically generate HTML and it changed
the web forever.
CGI script contains a lot of repetitive “boiler plate” code, they make code reuse difficult and they
can be difficult for first time developers to write and understand.
PHP fixes this problem.
PHP has a problem, is a development language and it allows developers to create dynamic content
that will help interaction with database.
Django is a third generation web development framework. It assists in building and maintaining
web applications.
_____________________________________________________________________________

Web framework:
A web framework or web development framework is a set of resources and tools for
software developers to build and manage web applications, web services and websites as well as
to develop Application Programming Interfaces (APIs). It provides a standard way to build and
deploy web applications on the World Wide Web. It provides libraries for database access,
templating frameworks and session management and they often promote code reuse. It also target
development of dynamic website they are also applicable to static websites.
Web application frameworks software:
 Django
 Flask
 ASP.NET
 Express.js
 Ruby on Rails
 Angular
 jQuery
 Bootstrap

CGI Application:
Example: CGI script written in python to displays the ten most recently published books from a
database.

#!/usr/bin/python
(Specify exactly which interpreter will be used to run the script on a particular system. This is a
hardcoded path to the python interpreter for that particular system. The advantage of this is that it
can use a specific python version to run the code).
import MySQLdb
(MySQLdb is an interface for connecting to a MySQL database server from python. Using
python’s MySQLdb module for connecting to the database which is at any sever that provide
remote access).
(Python module names are case sensitive, even on case–insensitive file systems. Therefore
MySQLdb and mysqldb are two different modules/packages. Use import MySQLdb).

print "Content-Type: text/html"


print
print "<html><head><title>Books</title></head>"
print "<body>"
print "<h1>Books</h1>"
print "<ul>"
connection = MySQLdb.connect(user='me', passwd='letmein', db='my_db')
cursor = connection.cursor()
cursor.execute("SELECT name FROM books ORDER BY pub_date DESC LIMIT 10")
for row in cursor.fetchall():
print "<li>%s</li>" % row[0]
print "</ul>"
print "</body></html>"
connection.close()

 prints “Content-Type” line


 then blank line
 it generates an HTML unordered list
Nowadays web application grows beyond the trivial, there is number of problems arises:
1. What happen when multiple pages need to connect to the database?
Can’t duplicate database connectivity code in each individual CGI script.
Solution- To refactor it into a shared function.
2. Developers worry about prints the “Content-Type” line and remembering to close the
database connection.
It reduces programmer productivity and introduces opportunities for mistakes.
3. What happen when the code is reused in multiple environment, each with a separate
database and password?
Solution- Some environment-specific configuration becomes essential.
4. What happen when a web designer who has no experience coding python wishes to
redesign the page?
The logic of the page and the retrieval of books from the database would be separate
from the HTML display of the page. So the designer could edit the latter without
affecting the former.
Using Django:

# models.py (the database tables)


from django.db import models
class Book(models.Model): -----------------------------Book class represent entity
name = models.CharField(maxlength=50) ----name and pub_date are the attributes of the class
pub_date = models.DateField()

# views.py (the business logic) ---------------------used to connect templates and models


from django.shortcuts import render_to_response
from models import Book
def latest_books(request):
book_list = Book.objects.order_by('-pub_date')[:10]
return render_to_response('latest_books.html', {'book_list': book_list})

# urls.py (the URL configuration)


from django.conf.urls.defaults import *
import views
urlpatterns = patterns('',
(r'latest/$', views.latest_books),
)

# latest_books.html (the template)


<html><head><title>Books</title></head>
<body>
<h1>Books</h1>
<ul>
{% for book in book_list %}
<li>{{ book.name }}</li>
{% endfor %}
</ul></body></html>
• The models.py file contains a description of the database table, as a Python class. This is called
a model. Using this class, can create, retrieve, update, and delete records in the database using
simple Python code rather than writing repetitive SQL statements.
• The views.py file contains the business logic for the page, in the latest_books() function. This
function is called a view.
• The urls.py file specifies which view is called for a given URL pattern. In this case, the
URL /latest/ will be handled by the latest_books() function.
• latest_books.html is an HTML template that describes the design of the page.

Taken together, these pieces loosely follow the Model-View-Controller (MVC) design
pattern. Simply put, MVC defines a way of developing software so that the code for defining and
accessing data (the Model) is separate from request routing logic (the Controller), which in turn is
separate from the user interface (the View).

A key advantage of this approach is that components are loosely coupled. That is, each
distinct piece of a Django-powered Web application has a single key purpose and can be
changed independently without affecting the other pieces.

For example,
A developer can change the URL for a given part of the application without affecting the
underlying implementation.
A designer can change a page’s HTML without having to touch the Python code that renders it.
A database administrator can rename a database table and specify the change in a single place,
rather than having to search and replace through a dozen files.
Django’s History:
It helps to understand why the framework was created.
1. Write a Web application from scratch.
2. Write another Web application from scratch.
3. Realize the application from step 1 shares much in common with the application
from step 2.
4. Refactor the code so that application 1 shares code with application 2.
5. Repeat steps 2–4 several times.
6. Realize that the framework is invented.
This is precisely how Django itself was created!
Django grew organically from real-world applications written by a Web development team in
Lawrence, Kansas. It was born in the fall of 2003, when the Web programmers at the Lawrence
Journal-World newspaper, Adrian Holovaty and Simon Willison, began using Python to build
applications.
In summer 2005, after having developed this framework to a point where it was efficiently
powering most of World Online’s sites, the World Online team, which now included Jacob
Kaplan-Moss, decided to release the framework as open source software. They released it in July
2005 and named it Django, after the jazz guitarist Django Reinhardt.

Model View Controller framework:

Model: manage business-logic of data


Handles data representation, it serves as an interface to the data stored in the database itself
and also allows to interact with the data without having to get disturbed with all the complexities
of the underlying database.
View: manage the presentation or the layout of the application
As the name implies, it represents what to see in the browser for a web application or in
the UI for a desktop application.
Controller: connects Models with View and routes request
Provides the logic to either handle presentation flow in the View or update the Models
data. (ie) it uses programmed logic to figure out what is pulled from the database through the
Model and passed to the View, also gets information from the user through the View and
implements the given logic by either changing the View or updating the data through the Model.
Model View Template framework:

When an URL is visited, the view function will receive a request. It will query the database
defined in models.py and done all the necessary processing and render the response using template
files.
Django’s view actually acts as the controller function in typical MVC architecture
Templates have a similar role as view in MVC.

Model: This is the abstraction layer for structuring and manipulating the data of the web
application. It acts as an interface for maintaining data. This is the logical data structure behind
the entire application and helps to handle the database.
View: This layer encapsulates the logic responsible for processing a user request and returns a
response. It is a user interface to execute the logic and interact with the models. It is responsible
for displaying all or a portion of data to the user.
Django view function is a special type of python function that accepts a web request as input and
output a particular web response. It takes what is in the Django template file. Usually from HTML,
CSS, Javascript and render a webpage. Example of Django view response include HTML web
page contents, an image, and an XML document, anything that a web browser can render.
Template: provides a designer friendly. Syntax for rendering the information to be presented to
the user. It contains the static parts of the desired HTML output along with some special syntax,
also known as Django Template Language (DTL), describing how dynamic content will be
inserted.
MVC vs MVT:
Web application frameworks uses MVC architecture. MVC is popular as it isolates the
application logic from the user interface layer and different parts of the application can be
developed separately. Here the controller part is the software code that controls the interaction
between the Model and the View.
Django works on the concepts of MVT, it itself takes care of the controller part and no
need to worry much about how the data moves between the Model and the View.

How to create dynamic web pages with Django?


First View: Dynamic Content
Example of dynamic web pages: Displays the current date and time.
Because the contents of the page are not static rather the contents change according
to the result of a computation. This example doesn’t involve a database or any sort of user input,
just the output of the server’s internal clock.
To create this web page, write a view function it is a python function that takes a Web request and
returns a Web response.
This response can be the HTML contents of a Web page, or a redirect, or a 404 error, or an XML
document, or an image or anything. This view contains whatever arbitrary logic is necessary to
return that response. This code can live anywhere as long as it’s on the Python path.
Instead of putting the code somewhere, create a file called views.py in the mysite directory.
Program:
View that returns the current date and time, as an HTML document:
from django.http import HttpResponse
import datetime
def current_datetime(request):
now = datetime.datetime.now()
html = "<html><body>It is now %s.</body></html>" % now
return HttpResponse(html)

• import the class HttpResponse, which lives in the django.http module.


• import the datetime module from Python’s standard library. This module contains several
functions and classes for dealing with dates and times, including a function that returns the current
time.
• define a function called current_datetime. This is the view function. Each view function takes an
HttpRequest object as its first parameter, which is named request.
name of the view function can be anything

How Django finds this function?


• calculates the current date/time as a datetime.datetime object, and stores that as the local variable
now.
• constructs an HTML response using Python’s format-string capability. The %s within the string
is a placeholder, and the % sign after the string means “Replace the %s with the value of the
variable now”.
• View returns an HttpResponse object that contains the generated response. Each view function
is responsible for returning an HttpResponse object.

Mapping URLs to Views:


How Django use this code? (by using URLconfs)
An URLconf is like a table of contents for the Django-powered Web site. It is a mapping between
URL patterns and the view functions that should be called for those URL patterns. (using URL
call the code).
View functions need to be on the Python path
While executing django-admin.py startproject, the script created a URLconf automatically
(the file urls.py).
By default, it looks like,
from django.conf.urls.defaults import *
urlpatterns = patterns('',
# Example:
# (r'^mysite/', include('mysite.apps.foo.urls.foo')),
# Uncomment this for admin:
# (r'^admin/', include('django.contrib.admin.urls')),
)

• imports all objects from the django.conf.urls.defaults module, including a function called
patterns.
• calls the function patterns() and the result is saved into a variable called urlpatterns. The
patterns() function gets passed only a single argument—the empty string. This string is used to
supply a common prefix for View functions. The variable defines the mapping between URLs and
the code that handles those URLs.
If the URLconf is empty, Django assumes that it just started a new project and hence
displays the message.
Variable urlpatterns which Django expectes to find in the ROOT_URLCONF module.
By default everything in the URLCONF is commented out, the Django application is a
blank state.
Python path:
Python path is the list of directories on the system where Python looks when using the
Python import statement.
Python path,
['', '/usr/lib/python2.4/site-packages', '/home/username/djcode/'].
While executing the Python code from foo import bar, Python will first check for a module
called foo.py in the current directory.
The first entry in the Python path, an empty string, means “the current directory”. If that
file doesn’t exist, Python will look for the file /usr/lib/python2.4/site-packages/foo.py. If that file
doesn’t exist, it will try /home/username/djcode/foo.py. Finally, if that file doesn’t exist, it will
raise ImportError.
To see the value of the Python path, start the Python interactive interpreter and type import
sys, followed by print sys.path.
But no need to worry about setting the Python path—Python and Django will take care of
things automatically behind the scenes.
manage.py file does this.

Now, edit the file to expose the current_datetime View:


from django.conf.urls.defaults import *
from mysite.views import current_datetime
urlpatterns = patterns('',
(r'^time/$', current_datetime),
)
 imported the current_datetime view from its module (mysite/views.py, which
translates into mysite.views in Python import syntax).
 (r'^time/$', current_datetime), this line referred as a URLpattern, it is a Python
tuple.
first element is a simple regular expression and the second element is the view function to
use for that pattern.
^ and $ are important.
^ - require that the pattern matches the start of the string
$ - require that the pattern matches the end of the string
^time/$ - ensures that only the URL /time/ matches
The server is running at the address http://127.0.0.1:8000/, so open the Web browser and
go to http://127.0.0.1:8000/time/.
Get the output of Django View
Regular expressions:
Is a compact way of specifying patterns in text.
Symbol Matches
. Any character
\d Any digit
[A-Z] Any character, A–Z (uppercase)
[a-z] Any character, a–z (lowercase)
[A-Za-z] Any character, a–z (case insensitive)
+ One or more of the previous character (e.g., \d+ matches 1 or more digit)
[^/]+ All characters until a forward slash
? Zero or more of the previous character (e.g., \d* matches zero or more digits)
{1,3} Between one and three (inclusive) of the previous expression
How Django Processes a Request:
What happen while running the Django development server and make requests to web
pages.
 command python manage.py runserver imports a file called settings.py from the
same directory. This file contains all sorts of optional configuration for this particular Django
instance, but most important settings is ROOT_URLCONF. This ROOT_URLCONF setting tells
Django which Python module should be used as the URLconf for this Web site.
 when django-admin.py startproject created the files settings.py and urls.py
 When a request comes in (request to the URL /time/—Django loads the URLconf
pointed to by the ROOT_URLCONF setting). Then it checks each of the URLpatterns in that
URLconf in order, compare the requested URL with the patterns one at a time, until it finds that
matches. When it finds it calls the view function associated with that pattern, passing an
HttpRequest object as the first parameter to the function.
 The view function is responsible for returning an HttpResponse object.
To make Django-powered pages-write view functions and map them to URLs through
URLconfs.

How Django Processes a Request: Complete Details

The figure shows the complete flow of Django request and response
 When an HTTP request comes from the browser, a server-specific handler
constructs the HttpRequest passed to later components and handles the flow of the
response processing.
 Handler calls Request or View middleware. This middleware are useful for
augmenting incoming HttpRequest objects as well as providing special handling
for specific types of requests. It returns either a HttpResponse or processing
bypasses the view.
 Exception middleware is take care of the bugs.
 If the view function raises an exception, control passes to the exception
middleware. If this middleware does not return an HttpResponse, the exception is
reraised.
 But Django includes default views that create a friendly 404 and 500 response.
 Before sending to browser the response middleware postprocessing an
HttpResponse or cleanup of request-specific resources.

URLconfs and Loose Coupling


URLconfs- It takes View function.
Django- the principle of loose coupling.
If two pieces of code are loosely coupled, then changes made to one of the pieces will
have little or no effect on the other.
Example: Django’s URLconfs
In Django Web application, the URL definitions and the View functions are called loosely
coupled.
For example,
consider the View function which displays the current date and time.
want to change the URL for the application— say, from /time/ to /currenttime/
change to the URLconf, without having to worry about the implementation of the function.
If want to change the logic in the View function, do that without affecting the URL to
which the function is bound.
If want to expose the current-date functionality at several URLs take care by editing the
URLconf without affecting the View code.
404 Errors:
URL pattern - URL /time/
What happens if a different URL is requested?
http://127.0.0.1:8000/hello/
http://127.0.0.1:8000/does-not-exist/
http://127.0.0.1:8000/
“Page not found” message- because the requested URL is not defined in the URLconf.
It tells which URLconf Django used and every pattern in that URLconf.
“Page not found” is displayed only the Django project is in debug mode. (while creating
the Django project first time it is in debug mode)

Second View:
Dynamic URLs:
In dynamic Web applications, URL contains parameters that influence the output of the page.
Example:
Create a view that displays the current date and time offset by a certain number of hours.
/time/plus/1/- displays the date/time one hour into the future.

urlpatterns = patterns('',
(r'^time/$', current_datetime),
(r'^time/plus/1/$', one_hour_ahead),
(r'^time/plus/3/$', three_hours_ahead),
(r'^time/plus/4//$', four_hours_ahead),
)
To overcome the problem do some abstraction here.
Wildcard URL patterns
URL pattern is a regular expression. Use the regular expression pattern \d+ to match one
or more digits:
from django.conf.urls.defaults import *
from mysite.views import current_datetime, hours_ahead
urlpatterns = patterns('',
(r'^time/$', current_datetime),
(r'^time/plus/\d+/$', hours_ahead),
)

(r'^time/plus/\d{1,2}/$', hours_ahead),

Use single View function for any arbitrary hour offset. Do this by placing parentheses
around the data in the URL pattern which is want to save?

(r'^time/plus/(\d{1,2})/$', hours_ahead),

Add this to views.py


def hours_ahead(request, offset):
offset = int(offset)
dt = datetime.datetime.now() + datetime.timedelta(hours=offset)
html = "<html><body>In %s hours, it will be %s.</body></html>" % (offset, dt)
return HttpResponse(html)

• import the class django.http.HttpResponse and the datetime module.


• The view function, hours_ahead, takes two parameters: request and offset.
• request is an HttpRequest object, each view always takes an HttpRequest object as its
first parameter.
• offset is the string captured by the parentheses in the URLpattern. Captured strings will
always be strings, not integers.
• First call int() on offset. This converts the string value to an integer.
why to call int() on offset. Calculate the current time plus a time offset of offset hours,
store the result in dt.
The datetime.timedelta function requires the hours parameter to be an integer.
• construct the HTML output of the view function.
• Finally, return an HttpResponse of the HTML.
views.py file contains:
from django.http import HttpResponse
import datetime
def current_datetime(request):
now = datetime.datetime.now()
html = "<html><body>It is now %s.</body></html>" % now
return HttpResponse(html)
def hours_ahead(request, offset):
offset = int(offset)
dt = datetime.datetime.now() + datetime.timedelta(hours=offset)
html = "<html><body>In %s hour(s), it will be %s.</body></html>" % (offset, dt)
return HttpResponse(html)

Django’s pretty error pages


In the previous example remove offset=int(offset)
Type error message displayed at the very top “unsupported type for timedelta hours
component:str”
Because the datetime.timedelta function expects the hour’s parameters to be an integer.

You might also like