Stefan Ukena's Blog

Ich mache gerade eine Marketing-Challenge für Indie-Devs: Vier Wochen jeden Tag einen Social Media Post veröffentlichen, um meine App SupaRechnung bekannter zu machen. Aber um die App geht es heute nicht. Heute geht’s um einen Rückblick auf die erste Woche:

• Wie oft und wo habe ich gepostet?
• Was war schwieriger als erwartet?
• Was hat mich überrascht?
• Hat es sich gelohnt und würde ich es weiterempfehlen

Wie oft und wo habe ich gepostet?

Mein ursprünglicher Plan war, täglich auf LinkedIn zu posten. Aber gleich am ersten Tag habe ich mich entschieden, das Instagram auch sein muss. Da bin ich jetzt @rechnungschaos. Und ein paar Tage später habe ich dann auch noch TikTok (@_stefan3000) mit aufgenommen.

Django 4.0 has been released, so it’s time to plan the upgrade from 3.x. Here are some important things to note about the upgrade:

• The latest 3.x-release is 3.2, which will receive security and “data loss” fixes until April 2024. Any 3.x-release before 3.2 will no longer receive updates or fixes. It’s time to upgrade to 3.2!
• Django 4.0 drops support for Python version <= 3.7. Django 3.2 still supports Python 3.6 and 3.7
• Django 4.0 drops a number of features that have previous been deprecated in 3.x. More details about these features can be found in the “deprecated” section of the previous releases: Django 3.0 deprecated features, Django 3.1 deprecated features
• If you are using DeleteView with custom logic in delete(), you should make yourself familiar with the new logic.

More links to the official docs:

I have updated the script to support a new parameter. Here is my use case:

Why this update? When I generate a PDF from a web-page, the resulting PDF often contains the current date at the very top, before all other dates. However, that’s not the date that I am interested in. I introduced a new before-parameter that will return the first date that is before the given date.

I have updated the previous post with the changes. (Maybe it’s time to publish this as a github project, but it still feels like overkill.)

The recent PyCharm release (2021.3) adds a feature that enables a new kind of remote development workflow. This seems to be similar to what VS Code has been able to do, but since I am using PyCharm, this is exciting. Basically, the new feature allows you to run PyCharm locally and connect it to a “PyCharm server” running remotely. The PyCharm server is a headless version of IntelliJ that you connect to using your local PyCharm (or rather a special version of a locally installed PyCharm IDE, I believe). Note that this is different from the existing workflow were you connect the local debugger to a remote session.

If you’re a remote team, or a freelance looking to do some pair programming with someone remotely, you used to be very limited in your choices. You could go old school on the terminal using ssh and tmux. But that’s only an option if you are comfortable with a terminal-based editor or IDE. If you are like me, and use a non-terminal based IDE, the easiest way was to use screen sharing, but that is very limited. You cannot easily hand over the keyboard and mouse from the “driver” to the “navigator”.

Here is a quick one-off script that I created to extract a date from PDFs. (Actually, this is an updated version. Maybe it’s not a one-off script after all?)

• The script will look for dates in common German formats, like 31.12.2021, 31. Dezember 2021, 31 Dez 2021.
• It will print either the first date it finds, or nothing
• It will print the date using ISO 8601 date part, e.g. 2021-12-31
• Using an optional second parameter, you can make sure the printed date is before a certain date

Requirements

The script uses two external libraries for PDF and date parsing: pdfminer.six and dateparser

In my quest to better understand rxPY, I have written some short example scripts that use different operators. I have published these on GitHub as rxpy3-examples. In order to keep the examples as short as possible, I had omitted implementing on_error and on_completed. I thought that simple examples would be bloated by this, but that was actually a mistake.

When I implemented these calls, I noticed that I had made a couple of mistakes in my previous implementation of the custom observable called dequeue:

There are so many todo apps, but none of them seems to have the ability to let me do this:

I want to be able to create a list of todo items – let’s call this list the should-do-list – and manually change the order of todo-items. Then I want to take this list, and create a new view of it. Let’s call this view the want-to-list. The want-to and the should-do list will always contain the same items, only the order of items is different. I want to be able to manually change the order on each list without impacting the order on the other list.

Today I reached out to the maintainers of rxPY for help on understanding the window_with_count-operator. I have trying to get this to work for a while now, and it just does not what I would expect. I have read the official rxPY-documentation, searched Stackoverflow, Google, and the project’s GitHub issues (because people are very helpful there in this particular project). I also looked at the tests, but those were confusing me even more. So I decided to ask for help by submitting a GitHub issue. Note: In general, I would assume that GitHub issues are the right place to ask for help. Many projects will automatically close questions, because issues are reserved for issues, like bug reports. However, in this case the project maintainers are actively answering questions there.

As I was adding a test for the examples/rx3_buffer_example.py I noticed that the endless while-loop was actually never called, because observable.connect() seems to be a blocking operation, until the stream finishes with on_error or on_complete.

To make this example testable, I changed the dequeue() from using an endless while-loop to emitting a list of items. The changes can bee seen in this commit.

In addition, I made a small change to the capture_stdout_as_list context-manager: I renamed the to_string()-method to __str__(), so that the context-manager’s result can be used in the test assertions using str(result) instead of result.to_string(). It does look a little nicer, and I guess that this could be called “more pythonic”.