The code listings in this book can be found under chapter01 directory at https://github.com/PacktPublishing/Hands-On-Enterprise-Application-Development-with-Python.

The code samples can be cloned by running the following command:

git clone https://github.com/PacktPublishing/Hands-On-Enterprise-Application-Development-with-Python

The instructions to run the code can be found under the README file in the individual chapter directories.

The code has been tested to run on a system that is running Fedora 28 and Python version 3.6.5, but it should be able to run on any system running Python 3.6.5.

Python is a dynamically typed, interpreted language that was initially well suited for scripting tasks that are boring and repetitive day-to-day tasks. But as the years progressed, the language gained a number of new features and the huge backing of its community, which propelled its development to make it a language that is now well suited to performing tasks that range from very simple applications, such as web scraping, to analyzing large amounts of data for training machine learning models that themselves are written in Python. Let's take a look at some of the major things that have changed over the years and see what the latest release of Python, Python 3, brings to the table.

Python as a language has evolved a lot over the years, but despite this fact, a program written in Python 1.0 will still be able to run in Python 2.7, which is a version that was released 19 years after Python 1.0.

Though a great benefit for the developers of Python applications, this backward compatibility of the language is also a major hurdle in the growth and development of major improvements in the language specification, since a great amount of the older code base will break if major changes are made to the language specification.

With the release of Python 3, this chain of backward compatibility was broken. The language in version 3 dropped the support for programs that were written in earlier versions in favor of allowing a larger set of long-overdue improvements to the language. However, this decision disappointed quite a lot of developers in the community.

In the days of Python 2, the text data type str was used to support ASCII data, and for Unicode data, the language provided a unicode data type. When someone wanted to deal with a particular encoding, they took a string and encoded it into the required encoding scheme.

Also, the language inherently supported an implicit conversion of the string type to the unicode type. This is shown in the following code snippet:

str1 = 'Hello'
type(str1)        # type(str1) => 'str'
str2 = u'World'
type(str2)        # type(str2) => 'unicode'
str3 = str1 + str2
type(str3)        # type(str3) => 'unicode'

This used to work, because here, Python would implicitly decode the byte string str1 into Unicode using the default encoding and then perform a concatenation. One thing to note here is that if this str1 string contained any non-ASCII characters, then this concatenation would have failed in Python, raising a UnicodeDecodeError.

With the arrival of Python 3, the data types that dealt with text changed. Now, the default data type str which was used to store text supports Unicode. With this, Python 3 also introduced a binary data type, called bytes, which can be used to store binary data. These two types, str and bytes, are incompatible and no implicit conversion between them will happen, and any attempt to do so will give rise to TypeError, as shown in the following code:

str1 = 'I am a unicode string'
type(str1) # type(str1) => 'str'
str2 = b"And I can't be concatenated to a byte string"
type(str2) # type(str2) => 'bytes'
str3 = str1 + str2
-----------------------------------------------------------
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: can't concat str to bytes

As we can see, an attempt to concatenate a unicode type string with a byte type string failed with TypeError. Although an implicit conversion of a string to a byte or a byte to a string is not possible, we do have methods that allow us to encode a string into a bytes type and decode a bytes type to a string. Look at the following code:

str1 = '₹100'
str1.encode('utf-8')
#b'\xe2\x82\xb9100'
b'\xe2\x82\xb9100'.decode('utf-8')
# '₹100'

This clear distinction between a string type and binary type with restrictions on implicit conversion allows for more robust code and fewer errors. But these changes also mean that any code that used to deal with the handling of Unicode in Python 2 will need to be rewritten in Python 3 because of the backward incompatibility.

Python is a dynamically typed language, and hence the type of a variable is evaluated at runtime by the interpreter once a value has been assigned to the variable, as shown in the following code:

a = 10
type(a)        # type(a) => 'int'
a = "Joe"      
type(a)        # type(a) => 'str'

Though dynamic interpretation of the type of a variable can be handy while writing small programs where the code base can be easily tracked, the feature of the language can also become a big problem when working with very large code bases, which spawn a lot of modules, and where keeping track of the type of a particular variable can become a challenge and silly mistakes related to the use of incompatible types can happen easily. Look at the following code:

def get_name_string(name):
    return name['first_name'] + name['last_name']

username = "Joe Cruze"

print(get_name_string(username))

Let's see what happens if we try to execute the preceding program:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 2, in get_name_string
TypeError: string indices must be integers

The program exited with a TypeError because we passed a string type to the get_name_string() method and then tried to access the keys inside a string, which is not the correct solution.

With the release of Python 3.5, the community added support for type hinting that was built into the language. This was not an effort to enforce a method, but was rather provided to support the users who may want to use modules that can catch errors that are related to a variable changing its type in between the execution flow.

The general syntax to mark the type of a variable is as follows:

<variable>: <type> = <value>

To mark the types in a method, the following syntax can be used:

def method_name(parameter: type) -> return_type:
    # method body

One of the examples of how to use type hinting in the program code is shown in the following code:

from typing import Dict

def get_name_string(name: Dict[str, str]) -> str:
    return name['first_name'] + name['last_name']

username = "Joe Cruze"

print(get_name_string(username))

When the preceding code is written in an IDE, the IDE can use these type hints to mark the possible violations of the type change of variable in the code base, which can prove out to be really handy by helping to avoid errors that are related to an incorrect type change when dealing with large code bases.

Every language has been developed to solve a certain type of problem that developers face while trying to build software for a specific domain. Python, being a dynamically typed, interpreted language, also has a set of use cases where it excels.

These use cases involve the automation of repetitive and boring tasks, quick prototyping of applications, and small applications focusing on accomplishing a specific goal, such as the installation of software, the setting up of a development environment, performing cleanup, and so on.

But is that all? Is Python good only for doing small tasks? The answer to this is no. Python as a language is much more powerful and can easily accomplish a large amount of increasingly complex tasks, such as running a website that scales to cope with millions of users using it in a very short span of time, processing large sets of incoming files, or training a machine learning model for an image-recognition system.

We are talking about achieving increasingly complex tasks using Python, but isn't Python slow compared to our traditional compile-time languages, such as C++, Java, and .NET? Well, that completely depends upon the context in which a person wants to use Python. If your aim is to run a Python program on an embedded device with only a limited amount of processing power, then yes, Python might be inadequate because of the sheer extra load that its interpreter will have on the processing environment. But if you are planning to use Python to run a web application on decently configured modern hardware, you might never experience any slowdowns while using Python. Rather, you might well feel a bit more productive while using it because of the sheer simplicity of its syntax and the ease of performing operations without writing hundreds of lines to achieve simple tasks.

So, let's see how Python fares in the enterprise environment.

Enterprise IT is complex, and an application that needs to be built for the enterprise will differ a lot from one that is built for a regular consumer. There are several factors that need to be kept in mind before developing an application for enterprise users. Let's take a look at what makes enterprise IT applications different from regular consumer offerings, as shown in the following list:

• Business oriented: Unlike an application that is built to solve the problems of individual users, an enterprise application is built to meet the specific needs of an organization. This requires the application to conform to the business practices of the organization, their rules, and the workflow they use.
• Robustness at scale: Most enterprises usually consist of thousands of employees who depend upon the internal applications to work and collaborate with each other. These kinds of use cases generate a large amount of data in various ways, and an application built for enterprise should be robust enough to handle thousands of users at the same time while also being able to crunch through a large amount of data that is distributed over a large network of nodes. During this time, the application should provide adequate mechanisms to deal with unexpected events that may happen for various reasons, such as attempts to breach security, the failure of nodes, power failure, and so on.
• Long-term support: An enterprise application needs to provide long-term support because enterprises usually don't want to move to newer applications as frequently as a regular consumer does. This happens because most enterprise applications are developed to integrate with the workflow of the organizations, and frequently changing an application will not only increase ownership costs for the enterprise, but will also cause a major disruption in the workflow for the employees of the organization.
• Ability to integrate: Most of the applications that are built for the enterprise won't be running as standalone applications. They will frequently need to interface with the other applications inside the organization. This gives rise to the need to provide a mechanism for easy integration of the application with others in the organization.

Python has been present in the enterprise ecosystem in quite a few forms; be it the automation of boring and repetitive tasks, being used as a glue between two layers of a product, or being used for building quick and easy-to-use clients for big server backends, the language has seen an increasing amount of adoption for various use cases. But what makes Python ready for the development of large enterprise applications? Let's take a look:

• Ability to build quick prototypes: The syntax of Python is very simple, and a lot of things can be achieved with very few lines of code. This allows developers to quickly develop and iterate over the prototypes of an application. In addition to this, these prototypes do not always need to be thrown away, and if the development is properly planned, they can act as a good base to build the final application upon.

  With the ability to quickly prototype an application, an enterprise software developer can see exactly how the requirements align in the application and how the application is performing. With this information, the stakeholders of the application can more accurately define the path for the application development, thereby avoiding midcycle architectural changes because something didn't work out the way it was expected to.

• A mature ecosystem: The mature ecosystem is one of the features of Python that deserve a lot of attention. The number of external libraries in Python has been growing at a rapid pace. For most of the tasks that need to be achieved in an application, such as two-factor authentication, testing code, running production web servers, integrating with message buses, and so on, you can easily look for a library with quite decent support.

  This proves to be of great help, since it reduces the amount of code duplication and increases the reusability of the components. With the help of tools such as pip, it is very easy to get the required library added to your project, and with the support of tools such as virtualenv, you can easily segregate a lot of different projects on the same system without creating a dependency mess.

  For example, if someone wants to build a simple web application, they can probably just use Flask, which is a microframework for developing web applications, and go ahead with the development of the web application without having to worry about the underlying complexities of dealing with the sockets, manipulating data on them. All they will require is a few lines of code to get a simple application up and running, as shown in the following code:

from flask import Flask
app = Flask(__name__)

@app.route('/', methods=["GET"])
def hello():
    return "Hello, this is a simple Flask application"

if name == '__main__':
    app.run(host='127.0.0.1', port=5000)

Now, as soon as someone calls the preceding script, they will have a flask HTTP application up and running. All that remains to be done here is to fire up a browser and navigate to http://localhost:5000. Then we will see Flask serving a web application without any sweat. All of this is made possible in under 10 lines of code.

With a lot of external libraries providing support for a lot of tasks, an enterprise developer can easily enable support for new features in the application without having to write everything from scratch, thereby reducing the chance of possible bugs and non-standardized interfaces creeping into the application. 

• Community Support: The Python language is not owned by any particular corporate entity, and is completely supported by a huge community backing that decides the future of the standard. This ensures that the language will continue to see support for quite a long time, and won't become obsolete any time soon. This is of great importance to organizations, since they want long-term support for the applications they run.

Given all of the preceding benefits of Python, developer productivity will get a boost when using the language while also reducing the total cost of ownership for the software if decisions are made in a well-planned way. These decisions involve how the application architecture will be laid out and which external libraries to use or to develop in-house. So yes, Python is indeed now ready to be used in the mainstream world of enterprise application development.

As we progress through the chapters in this book, we will need some way to implement what we have learned.

Imagine that you work for an organization known as Omega Corporation, which is a market leader for selling software products to companies and individuals. Omega Corporation needs a system through which it can track the bugs in its products. After a lot of brainstorming, they initiate a project codenamed BugZot, which will be their tool to track the bugs in their products.

Let's take a look at what Omega Corporation wants to achieve with project BugZot:

• Ability for users to report bugs in products: The users, be they internal or external, should be able to file bugs against a particular product of the organization, and while filing these bugs, the users should be able to select the release version of the product they are filing bugs against so as to provide increased granularity.

• Ability to control who can see the bug details: Since the application allows both internal and external users to file bugs, it is possible that internal users, such as quality engineers or internal IT teams, may file bugs against a product that has not yet been made available to the customers. This will mean that BugZot should be able to hide the details about the bugs that have a confidential status.

• Providing support for role-based permissions: BugZot should be able to support the concept of roles and permissions so that an unauthorized person cannot change the details of a particular bug. For example, we might not want an external customer to come and change the target release version for a bug, which is a task that should be done by product management.

• Support for file uploads: When a bug is filed, usually an error report or a log file from the product greatly helps to drill down to the root cause. This will mean that BugZot should be able to deal with file uploads and link the uploaded files to their respective bugs.

• Search functionality: A person using BugZot should be able to search for the bugs that are filed into the system based upon certain filter criteria, such as the identity of the user who filed the bugs, the current status of the bug, filing bugs against, and so on.

• Integration with email: When a bug changes state—for example, if a bug is moved from NEW to ASSIGNED—there should be an email notifying the people associated with the bug. This will require BugZot to provide integration with the email service provider of Omega Corporation.

• Ease of integration: Omega Corporation plans to extend the usage of BugZot at a later time by integrating BugZot with the various other internal applications they have. For this, BugZot should provide an easy way to achieve this integration.

Throughout the course of this book, we will be learning various concepts in Python and applying them to build BugZot, the bug-tracking system for Omega Corporation.

Gathering the software requirements before starting the development of an enterprise application can be a tedious task, and a failure to do so adequately can have severe consequences, such as increased costs due to delays that are caused by identifying requirements later in the development cycle of the application. Applications that lack the important features to improve the business process workflow will lead users to stop using the application in the worst case.

The requirement-gathering process is complex and tedious, and can take months to complete in an organization. Covering all the steps involved in the process is beyond the scope of this book. This section tries to give a brief description about some of the important steps in the process of gathering software requirements.

For an application inside an organization, there might be various users who are stakeholders, and can define the requirements of the application. These users can be broadly split into two categories:

• The workforce: These are the users who usually use the application to achieve a certain set of tasks. They are not concerned with all the features provided by the application, but rather what they focus upon is how well the application fits into their individual workflows. These users can provide requirements specific to what they work on, but may not be able to provide ideas about what they might require in the future, or what the other teams may require.

• The management: The management consists of people who understand the business process of the organization and have a much broader view of what the application should be able to do. These users may not be able to define the requirements of a particular use case, but can provide requirements considering what the application should do now and what future features might be needed.

Involving both kinds of stakeholders in the requirement-gathering process is important, and something that will define how well the enterprise application meets the demands of its users.

Once the users have been surveyed for what they would like to have in the application, the next step is to categorize these requirements. Broadly, the requirements can be categorized into two parts:

• Functional requirements: These are the requirements that define the features and functionality of the application. For example, BugZot has the following functional requirements:

  • Providing functionality for filing bugs by internal and external users
  • Providing support for roles and permissions
  • Providing functionality for dealing with file uploads
  • Integrating with the email system to send emails when a bug changes its status, and much more

• Nonfunctional requirements: These are those sets of requirements that do not affect the functionality of the software, but rather are implicit or explicit characteristics based on the functional requirements. For example, in BugZot, the following may be defined as some of the nonfunctional requirements:

• The application should provide security against common web attack vectors, such as XSS and CSRF
• The operational costs for the application should not exceed N% of the total budget
• The application should be able to generate backups in case a recovery is needed after a crash

Once the requirements are identified and categorized into functional and nonfunctional requirements, they then need to be prioritized according to their importance in the application. If this prioritization is not performed, it will lead to increased costs of development, delayed deadlines, and reduced productivity in the organization. Broadly, we can classify the requirements under the following categories:

• Must have: These are those requirements that are critical to the success of the application and that must be present in the application when it ships.
• Should have: These are those requirements that will enhance the functionality of the application but that need some further discussion about whether they should be added to the application.
• Could have: These are those requirements that are mostly enhancements, and the presence or absence of which won't affect the functionality of the application. These requirements can be taken care of in later updates to the application.
• Wish list: These are those requirements that are considered features that can be added at some later point in time, but which are not mission critical to the application. These features can be reviewed later for inclusion in the application update cycle.

Once the requirements have been identified, grouped, and prioritized, a document known as the software requirement specification is generated. This document describes the intended purpose, requirements, and nature of the software that needs to be developed.

The software requirement specification (SRS) will describe the following information:

• The intended purpose of the applications
• The conventions that are used in the document that are specific to the business process of the organization
• The features of the application
• The user classes who will be using the application
• The environment in which the application will operate
• The functional and nonfunctional requirements of the application

Once the SRS has been generated, it is sent for review and further negotiations. Once they are successfully completed, the application moves into the design phase, where an application mock-up is devised.

In this chapter, we briefly covered the changing programming landscape and explored how the Python ecosystem has changed over the years. We looked at how Python, given the fact that it allows quick prototyping, and has a vast array of well-supported libraries and an open community, is quickly rising to become the main choice for the development of large-scale applications in enterprises that require long-term support and easy integration with existing systems. 

We then went on to introduce the demo application, BugZot, that we will be building throughout the course of this book, and defined the functionalities that will be required from the application.

The last section of the chapter covered the requirement-gathering process for developing an enterprise application in a brief, looking at the different stakeholders, such as the hands-on users and the management users, and categorizing the requirements into functional and nonfunctional requirements. We also looked at the importance of prioritizing the requirements.

With the basic knowledge of the environment with which we are going to work on during the course of the book, we are now ready to take a deep dive into the first important aspect of the Enterprise application development which deals with how we layout the code base of our application in production which involves, how a particular set of objects are created and utilized in the application while focusing on the increased re-usability of the modules. The next chapter focuses on this important aspect which is also known as the Design patterns and cover the different types of patterns and how they can be used during the development of your application. 

1. Is it possible to perform operations such as concatenation on a str type and a byte type in Python 3?
2. Is the type hinting support introduced in Python 3 enforcing or not?
3. Beyond functional and nonfunctional requirements, are there any other kinds of requirements that also might need to be documented into the software requirement specification?

4. What are the major categories in which the prioritization of requirements can be done?
5. What are the next steps to take once the software requirement specification document has been generated? 

If you would like to go through the basics of Python programming once again before diving into the world of enterprise application development, Packt has a very good book that you can be refer to. You can get it at the following link:

• https://www.packtpub.com/application-development/learn-python-programming-second-edition