Python Combat Guide
This book is 100% complete
Completed on 2020-05-24
About the Book
Python Combat Guide
Is a practical guide, to setup projects from zero, or to improve existing ones.
Across 179 pages DIN A.4, provides comprehensive tips and trick, nice todo and don't-do-this.
Is a very practical guide, covering many aspects, talking superficially about many things interesting things to know like using Docker, Jenkins, Puppet, Infrastructure as code, Blue/green, canary deployment, git... and going in deep to some good practices, with a lot of source code samples.
Explain how to setup Unit Testing with pytest from the scratch, PyCharm and does some practical TDD with examples.
What is it?
A very practical hands on manual for companies working with Python 3 (and Python 2).
I explain my experience working in several actual projects, different sizes.
Like the title suggest is a Combat Guide: read it and start crushing it!.
Is the Master Class that your best friend working in a multinational will teach you to help to improve how you and your Team work.
Having in consideration SysAdmins, it explains how to move from Procedural code to OOP.
I use practical examples, and compare Bash and Python for different scenarios, and I show pytest Unit Testing from the scratch.
Probably you'll love it if you know Java or PHP cause in 5 hours will enable you to write code in Python.
I also provide a very simple Flask Web Application, so you see how easy it is.
Special Covid-19
I release this guide during coronavirus quarantine, in Ireland.
This is a technical guide, intended to serve to all level of Developers and to SDMs (SDM - Software Development Managers).
Also useful for Team Leads and Project Managers..
It is not a basic manual, however I want to give a chance to non-tech people to learn how to program in Python, so they can get a good life or in the case of the scientists and academics that lost their jobs in the universities and need to go back to the market. Many of them use tools like Jupyter Notebook with Python, so they only need a Master Class to empower them to work in modern projects, with Git, Unit Testing, nice good practices, Team work...
What is not?
A typical manual to learn Python for beginners.
If you're looking for this, this is not your book.
Is focused on writing CLI programs, Crons and does not cover Django.
Is the code in gitlab?
Yes, most of the code is in gitlab, so you can download and just run it.
However is better to follow the book, as there are some errors intended, in order to show what not to do, and without reading the book you'll not understand it.
Even if you didn't buy the book, feel free to download the source code in gitlab:
About the Author
Table of Contents
- Dedication - p.2
- Thanks - p.2
- About this Combat guide - p.9
- About the author - p.9
- Disclaimer - p.9
- About coronavirus - p.10
- For the very beginners - p.10
- Hacker Rank - p.11
- About Floating point / decimals and Locale (international users) - p.12
- Why Python versus Bash (reasons for SRE) - p.13
- OOP vs Procedural code (SRE) - p.13
- A practical sample of OOP for the SRE world - p.15
- Why not Python 27? - p.19
- Few differences between Python 2 and 3 - p.19
- print() - p.20
- Use a printing method instead of calling directly print() - p.21
- Use of raw_input in classes - p.21
- Floats - p.21
- Things I don’t like from Python - p.22
- Tools - p.22
- IDE: PyCharm Professional - p.23
- CVS: GIT - p.23
- Unit Testing: PyTest - p.23
- Google Docs and google drive - p.24
- Working with GIT - p.24
- Gitlab - p.24
- Commit messages - p.24
- Commit messages for Gitlab - p.25
- Branches - p.27
- Branching Strategy - p.28
- Git flow - p.29
- GitHub flow - p.31
- Production branch with GitLab flow - p.32
- Environment branches with GitLab flow - p.33
- Release branches with GitLab flow - p.34
- Merge/Pull requests - p.35
- Feature branches - p.36
- Closing or Linking issues using comments in GitLab - p.36
- Removing feature branches after merge - p.37
- Have always backups from Master - p.37
- Git rebase - p.37
- Fetch - p.38
- Pull from the repo - p.38
- Pushing to the repo - p.38
- Keep an eye to new changes in commits through the Log section - p.39
- Never ever submit to the repo local changes you want to test - p.39
- Never commit Debug Lines - p.39
- Development Environment - p.40
- Use Linux - p.40
- Coding - p.41
- General Style - p.41
- PEP-8 - p.41
- MT Notation - p.41
- Short Code in Methods is preferred - p.43
- About ‘ or “ (apostrophe or double quote) - p.43
- Return - p.44
- Error code in return - p.45
- Predictability in return: Return always the same - p.45
- Files - p.45
- Operators - p.46
- Tabs or spaces - p.46
- Space to breath - p.47
- Too much compressed code - p.47
- Use parentheses, Luke - p.49
- Do not use Global variables - p.50
- Declare variables on top of the Method - p.50
- Class Names - p.54
- Class Constants - p.54
- Comparing with constants - p.55
- Properties - p.55
- Properties and variables defined on top of the Method - p.55
- Functions and Methods - p.56
- Do not print inside classes, use the capacity of Python to return more than a parameter
- instead - p.56
- Warning: Do not repeat Method of Function names - p.57
- Function/Method Parameters with a default value (Keywords) - p.57
- Keyword Argument for a Method/Function - p.58
- Type Hinting and Annotations - p.61
- Lists, Arrays, Dicts, Tuple - p.62
- Mixed power of Lists, Dicts - p.62
- Dynamic grow - p.63
- “in” very important check to do - p.63
- Convenience of having a method for checking “in” - p.63
- Default dict, to save memory - p.64
- Sort a List by key - p.66
- Arrays and index -1 - p.66
- Expect the unexpected - p.66
- Use getters and setters - p.67
- Use update_ for methods that update Objects, not get_ - p.68
- Jumps of line \n to the end - p.69
- If / else - p.70
- Else in loops - p.71
- Careful String evaluations - p.71
- Calling variables by name in Methods or Functions - p.72
- If for text properties - p.72
- Avoid repeating code - p.73
- Comments - p.74
- Python doc - p.74
- Document - p.74
- No dead code - p.75
- We avoid Magic Methods - p.75
- Avoid using yield, avoid using lambdas - p.76
- Avoid using list comprehensions - p.76
- Avoid using Regular Expressions, unless you know what you are doing - p.76
- Creating Web Services with Flask - p.77
- Files for holding Data Structures and Databases - p.78
- Collation - p.78
- Data types in the Database - p.78
- Prefixes: MT Notation - p.80
- Expect the Unexpected - p.82
- Corner cases and assumptions - p.82
- Do no escape to shell to run a program, if you can do it from Python - p.82
- Try to have Common Libraries for the Common Tasks - p.83
- Bug fixing - p.84
- Focus, make sure you don’t do mistakes - p.84
- Better Quality than Quantity - p.84
- Cross Testing - p.84
- Check the Logs - p.85
- Methodology - p.88
- Methodology serves a purpose - p.88
- We are modern heroes - p.88
- Deploying to Production - p.88
- Create a Deploy or Launch or Change Request Document in the issue tracker - p.88
- Deploying to Production using immutable Docker Containers and/or Microservices - p.89
- Running in Production - p.91
- Check for Log Errors regularly in Production Servers - p.91
- Profiling - p.91
- Forensics / Postmortem analysis - p.91
- Do not use Database Stored Procedures - p.91
- Webservices and API are good, microservices are not always the wisest choice - p.92
- Blue green Deployment vs Canary, and Rolling Upgrade - p.93
- Managing the Team - p.95
- Managing takes time - p.95
- Synchronizing the knowledge of the Team - p.95
- Demos and Share the Pain - p.95
- Be always fair - p.96
- Automated Code Testing - p.98
- Unit Testing Framework - p.98
- Tests are not optional - p.98
- Run the Unit Tests - p.98
- Run tests frequently - p.98
- Do not reuse other Tests - p.98
- Importance of running Tests (Unit Testing Tests) - p.99
- Emails in the Tests - p.100
- Testing Infrastructure as Code - p.101
- Managing the Team - p.101
- Allow to learn and creativity - p.101
- New members join the Team - p.102
- Kick Off Meeting - p.102
- Concentrated advice for my Team - p.102
- Methodology for the Development, Presentations, Documents and Demos - p.103
- Prepare Demos: name Objects and Variables - p.103
- Prepare Demos: prepare it in advance and test that everything works - p.103
- Take care of the details - p.103
- We don’t avoid confronting problems - p.104
- We document and write Functional Analysis - p.104
- Checking the Functional Analysis before starting programming - p.105
- We reply the emails - p.105
- We do Stand up Meetings - p.105
- Exercises for Candidates / New Recruitments - p.105
- Tools to discuss remotely (screener) - p.106
- First, the FooBar exercise - p.106
- Second, Power of 2 exercise - p.106
- What we take in consideration from the candidate? - p.106
- Being nice - p.107
- Fair Questions for Developers - p.107
- Working with pytest Unit Testing - p.107
- Installing pytest in Ubuntu - p.108
- Installing pytest for Python2 - p.108
- Installing pytest for Python3 - p.108
- Running the Tests in a Virtual Machine like VirtualBox - p.108
- Running the Tests in a Docker container - p.108
- Location of the code samples and tests - p.109
- Writing the first test - p.110
- Using classes for testing - p.110
- Testing a real class - p.112
- Extending our first test - p.113
- Extending a bit more and getting errors - p.114
- Fixing our Test using TDD - p.117
- Advantages and disadvantages of having everything in one single method - p.119
- Reusability - p.121
- Adding improvements discussed - p.122
- Creating unit testing for DiskUtils - p.123
- Adding pytest to PyCharm Community Edition - p.125
- Code Coverage - p.128
- Adding Dependency Injection - p.131
- Stubs and Mocks and Monkeypatching - p.136
- Putting all together - p.141
- Exercises - p.148
- Refactors - p.149
- Fixtures - p.149
- Fixture to patch timesleep - p.150
- Pytest config file conftestpy - p.152
- Testing Exceptions - p.154
- Catching an expected Exception - p.154
- Code Coverage on Exceptions - p.154
- Tricks and Appendix - p.160
- A mix: Unit Testing on actual Hardware - p.160
- Convert a Python program to a Cron - p.161
- Class FileUtils - p.165
- Class SmtpUtils - p.171
- Exercises - p.174
- Different ways of doing things - p.174
- Exercises - p.177
- CTOP.py A sample of a program that includes all these lessons - p.178
Authors have earned$8,922,802writing, publishing and selling on Leanpub,
earning 80% royalties while saving up to 25 million pounds of CO2 and up to 46,000 trees.
Learn more about writing on Leanpub
The Leanpub 45-day 100% Happiness Guarantee
Within 45 days of purchase you can get a 100% refund on any Leanpub purchase, in two clicks.
See full terms
Free Updates. DRM Free.
If you buy a Leanpub book, you get free updates for as long as the author updates the book! Many authors use Leanpub to publish their books in-progress, while they are writing them. All readers get free updates, regardless of when they bought the book or how much they paid (including free).
Most Leanpub books are available in PDF (for computers), EPUB (for phones and tablets) and MOBI (for Kindle). The formats that a book includes are shown at the top right corner of this page.
Finally, Leanpub books don't have any DRM copy-protection nonsense, so you can easily read them on any supported device.
Learn more about Leanpub's ebook formats and where to read them
