Utrecht (NL) Python meetup summaries¶

Qstars IT and open source - Derk Weijers¶

Qstars IT hosted the meeting. It is an infra/programming/consultancy/training company that uses lots of Python.

They also love open source and try to sponsor where possible.

One of the things they are going to open source (next week) is a “cable thermal model”, a calculation method to determine the temperature of underground electricity cables. The Netherlands has a lot of net congestion… So if you can have a better grid usage by calculating the real temperature of cables instead of using an estimated temperature, you might be able to increase the load on the cable without hitting the max temperature. Coupled with “measurement tiles” that actually monitor the temperature.

They build it for one of the three big electricity companies in the Netherlands and got permission to open source it so that the other companies can also use it. They hope it will have real impact.

He explained an open source project he started personally: “the space devs”. Integrating rocket launch data and providing an API. Now it has five core developers (and got an invitation to the biggest space conference, two years ago!)

Some benefits from writing open source:

• You build your own portfolio.

• You can try new technologies. Always nice to have the skill to learn new things.

• You improve your communication skills (both sending and receiving).

• You can make your own decisions.

• You write in the open.

• Perhaps you help others with your work.

• You could be part of a cummunity.

• It is your code.

How to start?

• Reach out to other communities.

• Read and improve documentation.

• Find good first issues.

• Be proactive.

• Don’t be afraid to ask questions (and don’t let negative comments discourage you).

When working on open source, make sure you take security serious. People nowadays like to use supply chain attacks via open source software. So use 2FA and look at your deployment procedure.

Learning Python with Karel - EiEi Tun H¶

What is Karel <https://github.com/alts/karel>)? A teaching tool/robot for learning programming. You need to steer a robot in an area and have it pick up or dump objects. And… in the meantime you learn how to use functions and loops.

Karel only has a turn_left() function. So if you want to have it turn right, it is handy to add a function for it:

def turn_right():
    turn_left()
    turn_left()
    turn_left()

Simple, but you have to learn it sometime!

In her experience, AI can help a lot when learning to code: it explains stuff to you like you’re a five-year-old, and that’s perfect.

If you want to play with Karel: https://compedu.stanford.edu/karel-reader/docs/python/en/ide.html

JSON freedom or chaos; how to trust your data - Bart Dorlandt¶

For this talk, I’m pointing at the PyGrunn summary I made three weeks ago. I liked the talk!

Practical software architecture for Python developers - Henk-Jan van Hasselaar¶

There are several levels of architecture. Organization level. System level. Application, Code.

Cohesion: “the degree to which the elements inside a module belong together”. What does it mean? Working towards the same goal or function. Together means something like distance. When two functions are in separate libraries, they’re not together. It is also important for cognitive load.

Coupling: loose coupling versus high coupling. You want loose coupling, so that changes in one module don’t affect another module.

You don’t really have to worry about coupling and cohesion in existing systems that don’t need to be changed. But when you start changing or build something new: take coupling/cohesion into account.

Software architecture is a tradeoff. Seperation of concerns is fine, but it creates layers and thus distance, for instance.

Python is one of the most difficult languages when it comes to clean coding and clean architecture. You’re allowed to do so many dirty things! Typing isn’t even mandatory…

He showed a simple REST API as an example. Database model + view. But when you change the database model, like a field name, that field name automatically changes in the API response. So your internal database structure is coupled to the function at the customer that consumes the API.

What you actually need to do is to have a better “contract”. A domain model. In his example code, it was a Pydantic model with a fixed set of fields. A converter modifies the internal database model to the domain model.

You can also have services, generic pieces of code that work on domain models. And adapters to and from domain models, like converting domain models to csv.

Finding the balance is the software architect’s job.

What is the least you should do as a software developer? At least to create a domain layer. Including a validator.

There was a question about how to do this with Django: it is hard. Django’s models are everywhere. And you really need a clean domain layer…