- Date: Oct 14, 2016
- Location: Maan Coffee (Gongti)
- Organizer: Evgeny Demchenko
It was the first time we've tried to use a Lean Coffee format for our Python meetup and it worked pretty well. We've used 8 minutes base time box and at the end of it decide to extend for 4 more minutes or move on to the next subject via a "Roman vote". We've manage to cover 10 topics in about 1.5 hours which is pretty efficient.
"Lean Coffee is a structured, but agenda-less meeting. Participants gather, build an agenda, and begin talking. Conversations are directed and productive because the agenda for the meeting was democratically generated."
Each person can write a topic (or multiple topics) on an index card (example: "What's the best way to filter lists in python?"), then we "dot-vote" on all topics (5 votes limit per person), prioritize and have a time-boxed discussion on each topic in order of priority.
We do this for 1.5 hours and try to get through as many topics as we can and then sitch to a regular informal chat like we usually do. :)
Some topics were pre-submitted on our Meetup Trello board.
While it's possible to do functional programming in Python, the language was not created with functional use cases in mind.
If you really want to write the whole application in a strictly functional way, it's possible to do in Python, but it would be a better idea to actually use a real functional language.
At the same time, classes are often over-used and functional programming provides a lot of advantages by removing the problems of state and increasing simplicity.
It's a good idea to try to combine both OO and functional approaches in our applications, and try to use functions as much as possible for the logic of the application while still using classes for use cases where classes are perfectly suitable (like Domain modelling).
A good way to describe this is presented in The Clean Architecture in Python talk by Brandon Rhodes.
Microservice architecture is becoming a bigger trend every year and there's a [big discussion on what frameworks to use for it in Python[(https://news.ycombinator.com/item?id=8421493).
The most common opinion is that "batteries included" frameworks like Django are more suitable for monolithic applications while microservices require something light-weight like Flask/nameko/web.py/etc.
It does make sense from the performance perspective, at the same time, it's possible to make an argument for the opposite: that Django is actually more suitable for rapidly developing small services rather than large monolithic applications because it's actually hard to scale to a very large codebase. And the performance difference in a distributed architecture (where I/O is the biggest bottleneck) is actually not that significant, but the developers productivity when using Django can be the key when building up new services quickly.
At the same time, a non-intrusive framework like Flask allows to easier scale a large codebase and keep the framework away from the business logic as long as the application is build using a Clean Architecture.
There are pros and cons of using ORM or Raw SQL in Pyhon applications.
Some OO advocates (including Uncle Bob) think that ORM is a bad practice, others suggest that ORM is very practical.
It might be a good idea to use ORM most of the time because it solves a few important issues:
- Abstracting the database from the code
- Providing a convenient Data Persistence layer in the code
- Allowing to write DB queries in a readable "pythonic" way
- Simplifying data modelling and validation
But in cases where queries get really complex (or slow) it's still possible to fall back to Raw SQL through the ORM when it's better to express a certain query in SQL.
Sometimes when an application is dealing with structured data (ex: read from CSV file) but it's not core domain entities and rather local data manipulation / business logic (within the same module for example) it can be hard to choose the right data structure to use in this case, because:
- Creating classes seems to be an overkill
- Dictionaries feel unreliable (too dynamic) and not as clean to deal with in the code
Dictionaries are perfect to map things of one type (keys) to other things on one type (values), this is what they are for. And not to use as data objects. Also, dict/JSON can have performance issues in data-heavy workloads.
Classes are good for important domain entities, but for local computation or simple data transfer objects namedtuple can be a perfect solution. It makes code more readable and has a high-performance of a tuple.
Of course, it's important to know that, like tuples, namedtuples are immutable, so if you need to change their state it's better to use classes.
Coming from strongly-types languages to Python it can be scary or at least counter-intuitive to not have type checking during compile time which can catch a lot of very silly errors that should not get out into a production application.
The solution for this is implemented in Python 3.5 via Type Hints.
It provides a standard syntax for type annotations, opening up Python code to easier static analysis and refactoring, potential runtime type checking, and (perhaps, in some contexts) code generation utilizing type information.
Of these goals, static analysis is the most important. This includes support for off-line type checkers such as mypy, as well as providing a standard notation that can be used by IDEs for code completion and refactoring.
While this is not as powerful as static typing these optional type annotations give us a perfect balance between static and dynamic languages and allow us to enjoy advantages of both in Python and helps to scale large codebases in a dynamically typed language.
In JavaScript world similar benefits are achieved by TypeScript language.
It's also important to remember that the real answer for making sure errors don't get out to production code and applications work as expected are Unit Tests, type checking is just gravy. ;)
Behavior-driven development (or BDD) is an agile software development technique that encourages collaboration between developers, QA and non-technical or business participants in a software project.
BDD focuses on obtaining a clear understanding of desired software behavior through discussion with stakeholders. It extends TDD by writing test cases in a natural language that non-programmers can read. Behavior-driven developers use their native language in combination with the ubiquitous language of domain-driven design to describe the purpose and benefit of their code. This allows the developers to focus on why the code should be created, rather than the technical details, and minimizes translation between the technical language in which the code is written and the domain language spoken by the business, users, stakeholders, project management, etc.
BDD scenarios use The Gherkin language to express the requirements in a domain language while still making it structures and possible to be executed as an "acceptance test".
In Python BDD can be used via tools like behave, pytest-bdd, Robot Framework and others.
Python programmers rarely talk about design patterns, most common arguments are that patterns are built-in language features or provided by the frameworks, plus, we avoid building large application.
In statically typed languages like Java patterns are extremely important in order for the code to be maintainable and to keep flexibility, but in Python it's not necessary.
But even though the patterns are "built-in" into the language it's still important to know the pattern and choose which one to apply in what context. Using the design patterns allows us to better structure our code and make it easier to maintain.
More on this in Python Patterns 1 talk by Brandon Rhodes.
When it come to ERP-like software there're 3 options:
- Build in-house (from scratch)
- Purchase a commercial product
- Open source (customized for business needs)
It seems like the OSS option is not very popular and Chinese companies are more likely to go with a commercial product or build one from scratch in case the company is getting pretty big.
But overall it sounds like OSS is a good idea for most use cases, it's feature-full enough to save a lot of development effort and flexible enough to customize for specific business needs without having to adapt the whole business process to the framework.
A popular OSS ERP project is Odoo.
Machine learning is becoming a huge trend and Python ecosystem is very well suited for ML problems as it has great tooling (like scikit-learn) and the dynamic nature and simplicity of the language allow to rapidly prototype ML solutions and get quick results with the minimum amount of code.