Python Combat Guide
Minimum price
Suggested price

Python Combat Guide

A comprehensive manual about tricks, good practices and coding style for hands on Software Developer Managers and Developers

About the Book

Python Combat Guide

Is a practical guide, to setup projects from zero, or to improve existing ones.

Across 323 pages DIN A4, provides comprehensive explanations with code samples, 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 moving from Python 2.7 to Python 3).

I explain my experience working in several actual projects, different sizes and teach good practices.

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 Operations Engineers, SRE and SysAdmins, it explains how to move from Procedural code to OOP, and how and why to use Interfaces and Base classes (Parent) and children (subclasses).

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, a simple SQLITE3 example, a simple GUI TKinter LDAP application, Cron Jobs that send email...


Price is $5 USD, as minimum, and $20 suggested.

I decided to set the price to the minimum ($5), at least during covid, in order to help people that want to learn and improve. (this is not a manual for novices, but for people that actually know Python, SysAdmins, Architects and Managers)

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.

It is not a manual to learn specific Python language features in deep. Does not cover Python 3.7, 3.8 or 3.9 new features. Does not cover Django.

Neither explain Architecture Patterns like Event Queues or Microservices. Or how to write API's, there are many books for that.

It just go for pointing the effective way to build CMD Line applications, Crons, use Dependency Injection, and Unit Testing in a very professional way.

Also cover certain common sense aspects for working in Team, good practices, and some Scaling tricks.

So basically allowing SRE, DevOps and Managers to improve the way they run Command Line Appications, Server side scripting, Server Monitoring...

Currently I don't cover Google Cloud Python Engine or Amazon AWS lambda with Python, although I have plans to do it.

I think you will learn many useful things, but if you buy it and you are not satisfied, please feel free to return it. When you buy it you have a period of time to return it, which at the moment of this writing is 10 days. I only had one return, and it was a professional editorial that wanted to print the book in the States. But honestly, I like to keep all the rights and to be able to communicate with you and to update the book often. ;)

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

Carles Mateo
Carles Mateo

I’m Carles Mateo, since January 2020 working as Operations Engineer for Blizzard Entertainment in Cork, Ireland.

Previously worked as Cloud Architect and SDM for Sanmina, in Ireland and United States, where I created and I did lead a Python and C project for a Storage Manager for our 4U Cold Storage Servers 1PB and 2U SSD and 1U NVMe with NICs up to 2x100Gbps, which will restore redundancy in the RAID when a drive dies, very quickly, using ZFS and DRAID.

I also worked for Volkswagen IT, Winterthur Insurance (Axa), or BBVA Tickets and several CSP, Start ups, Online travel agencies, eCommerce…. in hands on positions leading teams and coding myself, in Software Development, SRE and Operations roles.

You can find information about me in my blog.

Bundles that include this book

Suggested Price
Bundle Price

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
  • Floats in Databases and Currencies - p.22
  • Things I don’t like from Python - p.25
  • Tools - p.26
  • 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
  • Printing in color to the Linux Terminal - p.182
  • Working with SQLITE3 - p.185
  • Thinking about the decision of designing Interfaces and Base Classes extended - p.190
  • The boring theory - p.190
  • Practical approach - p.191
  • Practical approach for SRE - p.198
  • A sample of a program that includes all these lessons - p.178

Authors have earned$10,052,337writing, 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

Write and Publish on Leanpub

You can use Leanpub to easily write, publish and sell in-progress and completed ebooks and online courses! Leanpub is a powerful platform for serious authors, combining a simple, elegant writing and publishing workflow with a store focused on selling in-progress ebooks. Leanpub is a magical typewriter for authors: just write in plain text, and to publish your ebook, just click a button. It really is that easy.

Learn more about writing on Leanpub