pixel
Seite wählen

NETWAYS Blog

Python – Generator

Wer schon einmal eine etwas größere Datei, bspw. 1Gb, mit dem Editor VIM geöffnet hat, der weis, wie lange dies dauern kann. Das kommt daher, dass diese Datei zunächst komplett in den Arbeitsspeicher geladen werden muss. So ähnlich verhält es sich, wenn in Python eine Variable “befüllt” wird, welche anschließend Speicherplatz im Arbeitsspeicher belegt. Bei der heutigen Hardware stellen 1 Gb große Variablen kein Problem dar, aber was passiert wenn diese deutlich größer sind und zusätzlich eine gute Performance benötigt wird? In diesem Fall empfiehlt es sich, auf einen Generator zurückzugreifen. Ein Generator liefert lapidar gesagt die Ergebnisse einer Funktion “häppchenweise” und nicht als riesiges Stück zurück. Syntaktisch unterscheidet sich ein Generator von einer “normalen” Funktion nicht großartig, wie hier zu sehen:

def a_function():
  yield x
  yield y
  yield z

Bei der Funktionsdefinition wird lediglich das Schlüsselwort return durch yield ersetzt. Der große Unterschied zu einer “normalen” Funktion dabei ist, dass sich die Funktion mit yield nicht sofort beendet. Somit erhält man, vereinfacht gesagt, ein Objekt (Iterator) als Rückgabewert, über das man iterieren kann.

Zur besseren Veranschaulichung eines Generators werde ich eine exemplarische Datenbankabfrage aufzeigen:

Hinweis: Ich habe eine Beispieldatenbank genommen.

“normale” Funktion
SELECT-Statement und anschließende Rückgabe des gesamten Ergebnisses:

def select_list():
    result = []

    db = mysql.connector.connect(host='127.0.0.1',
                                 user='thomas',
                                 password="4nD3r5on",
                                 db='employees')

    cursor = db.cursor()

    cursor.execute('select * from employees')

    for row in cursor:
        result.append(row)

    return result

Die Funktion “select_list()” liefert eine Liste zurück:

print(select_list())

[...]
(10016,'1961-05-02','Kazuhito','Cappelletti','M','1995-01-27'),
(10017,'1958-07-06','Cristinel','Bouloucos','F','1993-08-03'),
(10018,'1954-06-19','Kazuhide','Peha','F','1987-04-03'),
[...]

“generator” Funktion
Im Gegensatz zum obigen Beispiel wird keine Liste mit den Werten befüllt, sondern jeder Wert einzeln durch yield zurückgegeben:

def select_generator():
    db = mysql.connector.connect(host='127.0.0.1',
                                 user='thomas',
                                 password="4nD3r5on",
                                 db='employees')

    cursor = db.cursor()

    cursor.execute('select * from employees')

    for row in cursor.fetchmany(1000):
        yield row

Die Funktion “select_generator()” liefert keine Liste zurück, sondern einen Generator:

print(select_generator())

<generator object select_generator at 0x10ba165d0>

Durch anschließendes Iterieren des Generatorsobjektes werden die gewünschten Werte ausgegeben:

for row in select_generator():
        print(row)

[...]
(10016,'1961-05-02','Kazuhito','Cappelletti','M','1995-01-27'),
(10017,'1958-07-06','Cristinel','Bouloucos','F','1993-08-03'),
(10018,'1954-06-19','Kazuhide','Peha','F','1987-04-03'),
[...]

Wo liegt nun der Vorteil eines Generators? Das zeigt sich erst bei Benchmark-Tests, welche im folgenden Beispiel die Performance der jeweiligen Funktion aufzeigt. Die SELECT-Statements sind bei beiden Beispielen dieselbigen, werden aber nicht ausgegeben, es wird nur eine Variable initialisiert:
select_list()

print('Memory (Before): {} Mb'.format(
    psutil.Process(os.getpid()).memory_info().rss / 1000000))
    
t1_start = perf_counter()
test_list = select_list()
t1_stop = perf_counter()
    
print('Memory (After) : {} Mb'.format(
    psutil.Process(os.getpid()).memory_info().rss / 1000000))

print("Elapsed time: {0} seconds".format(t1_stop-t1_start))

select_generator()

print('Memory (Before): {} Mb'.format(
    psutil.Process(os.getpid()).memory_info().rss / 1000000))

t1_start = perf_counter()
test_generator = select_generator()
t1_stop = perf_counter()

print('Memory (After) : {} Mb'.format(
    psutil.Process(os.getpid()).memory_info().rss / 1000000))

print("Elapsed time: {0} seconds".format(t1_stop-t1_start))

select_list():

Memory (Before): 11.776 Mb
Memory (After) : 124.960768 Mb
Elapsed time: 8.311030800000001 seconds

 

select_generator():

Memory (Before): 11.698176 Mb
Memory (After) : 11.718656 Mb
Elapsed time: 4.869999999934649e-07 seconds

Die Zahlen sprechen für sich. Beim Generator bleibt der Verbrauch des Arbeitsspeichers so gut wie unverändert, da dieser beim Ausführen des Codes nicht “alle Werte speichert”, sondern jeden einzelnen Wert ab dem Schlüsselwort yield zurückgibt. Dadurch ergibt sich auch die immense Geschwindigkeit.
An dieser Stelle ist noch zu erwähnen, dass alle Vorteile eines Generators verloren gehen, wenn man diesen in ein Liste umwandelt.

Quelle: https://media.giphy.com/media/yUrUb9fYz6x7a/giphy.gif

Philipp Dorschner
Philipp Dorschner
Developer

Philipp hat im Jahr 2017 die Ausbildung zum Fachinformatiker – Systemintegration bei NETWAYS Professional Services begonnen. Während der Ausbildung bekam er ein immer größeres Interesse am Programmieren. Das führte dazu, dass Philipp nach erfolgreich bestandener Ausbildung die Kolleg:innen aus Professional Services nicht nur als Consultant sondern auch als Entwickler tatkräftig unterstützt. Neben seinem Interesse an der Informationstechnologie, macht er Sport im Freien oder liest bei schlechtem Wetter auch gerne mal ein Buch zu Hause.

Go – Automatische Package Updates

Durch die Einführung des GO-Module, welches ein eigenes Dependency Management für das GO-Ökosystem ist, erleichtert es dem Programmierer, die importieren Go-Packages im Projekt aktuell zu halten. Dabei muss der Programmierer diese Updates immer manuell auslösen, was über folgende Befehle gemacht werden kann:

go get -u ./...
go mod tidy

Dabei wird der aktuelle Stand aller importierten Packages heruntergeladen. Das Problem hierbei ist – wie oben erwähnt – dass der Programmierer dies manuell auslösen muss. Bei einem Projekt ist das kein Problem – sind es aber mehrere Projekte, können womöglich manche Updates vergessen werden oder es ist dem Programmierer nicht bewusst, dass Updates anstehen. Aus diesem Grund bietet sich eine Automatisierung an, genauer gesagt handelt es sich hierbei um den Dependabot.

Was kann der Dependabot?

Der Dependabot selbst ist auch ein Dependency Management Tool, welches in GitHub integriert werden kann. Dependabot sucht automatisch nach Manifestdateien und prüft dort die eingetragenen Versionen der Package-Abhängigkeiten. Wurde ein Update gefunden, erstellt Dependabot automatisch einen Pull Request, um die Packages zu aktualisieren.

Um eine Integration in GitHub zu erhalten, muss lediglich eine dependabot.yml im Ordner .github des Repositories angelegt werden:

.github/dependabot.yml

In dieser Datei kann nun das Verhalten des Bots konfiguriert werden:

version: 2
  updates:
  - package-ecosystem: gomod
    directory: "/"
  schedule:
    interval: weekly
    time: '10:00'
  open-pull-requests-limit: 10
  • package-ecosystem: In diesem Fall gomod. Kann je nach Programmiersprache angepasst werden
  • directory: Der Ort der Manifestdatei. In diesem Fall die go.mod
  • schedule.interval: Der Zyklus, wie oft auf Updates geprüft werden soll
  • open-pull-requests-limit: Limitiert die Anzahl der Pull Requests, die Dependabot für das jeweilige Repository erstellt

Die komplette Liste an Konfigurationseinstellungen kann auf der Projektseite von Dependabot gefunden werden.

Anschließend überprüft Dependabot alle Abhängigkeiten und erstellt selbstständig Pull Request mit den aktuellen Packages:

Der Pull Request kann im Anschluss gemerged werden und der aktuelle Stand der Packages ist gesichert.

Du möchtest mehr dazu wissen?

Wenn ich mit diesem Blog das Interesse an Versionsverwaltungssoftware geweckt habe, kann ich nur die NETWAYS-Trainings empfehlen. Dort werden die Grundlagen einer Versionskontrolle für Softwareprojekte auf Basis von Git beigebracht.

 

Bildquelle: Dependabot-Core
Philipp Dorschner
Philipp Dorschner
Developer

Philipp hat im Jahr 2017 die Ausbildung zum Fachinformatiker – Systemintegration bei NETWAYS Professional Services begonnen. Während der Ausbildung bekam er ein immer größeres Interesse am Programmieren. Das führte dazu, dass Philipp nach erfolgreich bestandener Ausbildung die Kolleg:innen aus Professional Services nicht nur als Consultant sondern auch als Entwickler tatkräftig unterstützt. Neben seinem Interesse an der Informationstechnologie, macht er Sport im Freien oder liest bei schlechtem Wetter auch gerne mal ein Buch zu Hause.

Dynamische Formulare in Icinga Web 2

In meinem letzten internen Projekt der NETWAYS durfte ich ein Icinga Web 2 Module bauen, welches ein dynamisches Formular verwenden soll. Konkret sollte es mehrere Dropdown-Menüs geben, welche den Wert des vorherigen Dropdown-Menü evaluiert und anhand dessen, ein neues Dropdown befüllt. Dabei kann man zwei Herangehensweisen benutzen, welche ich im Folgenden erläutere.

Die klassische (schlechte) Herangehensweise

Die erste Möglichkeit, die mir in den Sinn kommt, ist, dass man sich über AJAX verschiedene Actions in Icinga Web 2 aufruft. Diese wiederum besitzen einen Code, der den Wert des zuvor ausgewählten Wertes evaluiert und das weitere Dropdown befüllt. Da Icinga Web 2 einem MVC (Modell, View, Controller) Muster folgt, wird ein Controller- für die Steuerung und ein View-Script für die Darstellung benötigt. Des Weiteren wird für den AJAX Request eine eigene module.js Datei benötigt, in der der JavaScript Code hinterlegt ist. Darüber hinaus müsste man noch CSS einbinden, damit das Formular auch noch schön dargestellt wird.

Alles im Allem, eine sehr sehr aufwendige Herangehensweise!

Die richtige Herangehensweise

Wie oben erwähnt, handelt es sich bei Icinga Web 2 um ein MVC, somit ist es auch möglich, bestimmte “ConfigForm-Views” zu erstellen, die bereits alle benötigten Sachen zur Verfügung stellen: CSS, JavaScript und HTML. Das beste daran ist, dass dies super einfach zu implementieren ist und das Framework die ganze Arbeit von der “schlechten Herangehensweise” übernimmt.
Man kann einer Configform die Klasse autosubmit mitgeben, dadurch erhält man ein Verhalten wie ein AJAX-Request. Im Folgenden ein kleiner Ausschnitt eines solchen ConfigControllers:

<?php
    namespace Icinga\Module\Testmodule\Forms\Test;
    use Icinga\Web\Form;
 
    class TestForm extends Form 
    {
      public function init()
      {
        $this->setName('form_test_form');
        $this->setSubmitLabel('Save Changes');
      }

      public function createElements(array $formData)
      {
          // Load cars
          $this->addElement(
              'select',
              'car',
              array(
                  'label' => $this->translate('Car'),
                  'multiOptions' => [
                      '' => '(select option)',
                      'audi' => 'Audi',
                      'vw' => 'VW'
                  ],
                  // 'autosubmit' acts like an AJAX-Request
                  'class' => 'autosubmit'
              )
          );

          // Select model
          if (isset($formData['car']) && $formData['car'] === 'audi') {
              $this->addElement(
                  'select',
                  'model',
                  array(
                      'label' => $this->translate('Model'),
                      'multiOptions' => [
                          '' => '(select model)',
                          'A1',
                          'A6'
                      ],
                      'required' => true,
                  )
              );
          } elseif (isset($formData['car']) && $formData['car'] === 'vw') {
              $this->addElement(
                  'select',
                  'model',
                  array(
                      'label' => $this->translate('Model'),
                      'multiOptions' => [
                          '' => '(select model)',
                          'Golf',
                          'Polo'
                      ],
                      'required' => true,
                  )
              );
          }
      }  
    }

Wenn man nun noch das View-Script einbindet erhält man eine Form, die wie folgt aussieht:



Durch das Framework von Icinga Web 2 ist es möglich, sehr schnell ein Modul nach eigenen Wünschen zu erstellen. Wem ich damit nun Lust auf ein bisschen Programmierung gemacht habe, dem kann ich die bereits vorhandenen Trainingsunterlagen auf Github empfehlen! Oder Ihr besucht eine unserer verschiedenen Konferenzen, bei der man auch mal detailliertere Einblicke wie z.B. Icinga Web 2 Modul Programmierung erhält.

Philipp Dorschner
Philipp Dorschner
Developer

Philipp hat im Jahr 2017 die Ausbildung zum Fachinformatiker – Systemintegration bei NETWAYS Professional Services begonnen. Während der Ausbildung bekam er ein immer größeres Interesse am Programmieren. Das führte dazu, dass Philipp nach erfolgreich bestandener Ausbildung die Kolleg:innen aus Professional Services nicht nur als Consultant sondern auch als Entwickler tatkräftig unterstützt. Neben seinem Interesse an der Informationstechnologie, macht er Sport im Freien oder liest bei schlechtem Wetter auch gerne mal ein Buch zu Hause.

Request Tracker – Dark Theme und SearchResult

Bei der neuen Version des Request Tracker 5 wurde – meiner Meinung nach – ein tolles neues Feature implementiert und zwar das sog. Dark ThemeDabei wurde die Hintergrundfarbe verdunkelt und die Textschrift aufgehellt, wodurch eine bessere Lesbarkeit in dunklen Umgebungen gewährleistet wird. In diesem Zuge musste die RT-Extension SearchResult auf das neue Dark Theme angepasst werden. SearchResult ist eine RT-Extension die es möglich macht, Tickets nach bestimmten Kriterien farblich hervorzuheben, wie z.B. bei Ablauf des Due Date, um somit möglichst schnell einen Überblick über den aktuellen Status eines oder mehrerer Tickets zu erhalten.

Hinweis: Im folgenden Blogpost gehe ich davon aus, dass die Grundinstallation des Request Tracker bereits vorhanden ist. Falls dies nicht der Fall ist und Probleme oder anderweitige Fragen zum Request Tracker auftauchen, einfach bei NETWAYS nachfragen. Wir helfen gerne 🙂

 

An dieser Stelle ist zu erwähnen, dass die Aktualisierung netterweise von RedBridge gesponsert wurde, vielen Dank hierfür 🙂

 

Um dies zu verdeutlichen, oben das Light Theme und unten das Dark Theme:

Im Folgenden ein kleiner Exkurs wie das Dark Theme sowie SearchResult installiert bzw. aktiviert werden:

 

Dark Theme:

Durch Hinzufügen der Option innerhalb der RT_SiteConfig.pm  und anschließendem Neustart des Webservers, wird das Dark Theme aktiviert:

# cat /opt/rt5/etc/RT_SiteConfig.pm
[...]
Set($WebDefaultStylesheet, "elevator-dark");
[...]

 

Neustart des Webservers (in diesem Fall Apache):

systemctl restart apache2

Kommt keine Fehlermeldung, wurde das Dark Theme erfolgreich aktiviert.

 

SearchResult:

Um die Extension SearchResult Extension zu aktivieren wird diese zunächst aus folgendem Repository geklont und anschließend installiert:

Klonen des Repository

# git clone https://github.com/NETWAYS/rt-extension-searchresult
# cd rt-extension-searchresult/

 

Installation von SearchResult

# perl Makefile.PL
# make
# make install

 

Konfiguration von SearchResult

# cat /opt/rt5/etc/RT_SiteConfig.pm
[...]
Plugin('RT::Extension::SearchResult');
Set($SearchResult_HighlightOnLastUpdatedByCondition,[
{
"conditions" => { "groups" => [ "admins" ] },
"color" => "purple",
"icon" => "fa-exclamation-triangle",
"tooltip" => "Customer replied. Action required."}]);
Set($SearchResult_HighlightOnDueDate,[
{
"conditions" => { "due" => 0 },
"color" => "red",
"icon" => "fa-question-circle",
"tooltip" => "Due date reached. Action required."},
{
"conditions" => { "due" => 3 },
"color" => "yellow",
"icon" => "fa-question-circle",
"tooltip" => "Due date soon. Plan ahead."},]);
[...]

Damit die Änderungen übernommen und aktiviert werden muss wie im obigen Beispiel der Webserver neugestartet werden. War dies erfolgreich, wird die Oberfläche des Request Tracker wie folgt dargestellt:

Philipp Dorschner
Philipp Dorschner
Developer

Philipp hat im Jahr 2017 die Ausbildung zum Fachinformatiker – Systemintegration bei NETWAYS Professional Services begonnen. Während der Ausbildung bekam er ein immer größeres Interesse am Programmieren. Das führte dazu, dass Philipp nach erfolgreich bestandener Ausbildung die Kolleg:innen aus Professional Services nicht nur als Consultant sondern auch als Entwickler tatkräftig unterstützt. Neben seinem Interesse an der Informationstechnologie, macht er Sport im Freien oder liest bei schlechtem Wetter auch gerne mal ein Buch zu Hause.

Warum wir in den NETWAYS-PostgreSQL-Trainings eigentlich nur “psql” nutzen

Wieder einmal PostgreSQL Schlung (Fundamentals und Advanced) durchgeführt.
Wieder einmal wurde nach GUIs gefragt.
Wieder einmal haben wir uns dann letztlich doch fast auf psql beschränkt.

Warum ist das so?

 

GUI vs. TUI – the eternal battle

GUIs werden i. A. als “benutzerfreundlicher” dargestellt.

Ich persönlich wiederum finde es ganz schrecklich, dauernd zur Maus greifen zu müssen, um irgendeine Aktion auszulösen, für die die Entwickler keinen oder einen grauenhaften Shortcut konfiguriert haben… für mich sind GUIs also eher weniger benutzerfreundlich.

Mir ist auch klar, dass es beileibe nicht jedem Menschen so geht, und die Gewöhnung spielt dabei sicher auch eine enorme Rolle.

“The usual suspects”: die üblicherweise genannten Gründe pro GUI/TUI

GUI:

  • intuitiver zu bedienen
  • “gewohnte” Optik
  • bessere Übersicht über Ergebnisse von Queries

TUI:

  • steht vom Funktionsumfang dem GUI kaum nach
  • funktioniert auch bei langsamer Verbindung (“Zug”)
  • kann gescriptet werden

Es gibt aber einige durchaus schwerwiegende Gründe, warum ich bei Trainings so einen großen Wert auf psql lege.

“The killer arguments”: warum psql elementar ist

Die Lernschwelle ist bei GUIs unnötig hoch

  • Jedes GUI sieht letztlich (ein wenig) anders aus und es gibt einfach zu viele
  • Um eine erste Verbindung herzustellen, muss im GUI erst ein Server definiert werden, mit jeder Menge Parametern, u.a. einer Netzwerkverbindung
    • dafür muss aber erst ein Konfigurationsparameter (listen_addresses=) gesetzt werden, was wiederum erst deutlich nach dem ersten “Reinschnuppern” behandelt wird…
    • Im Terminal hingegen (wo ich ja gerade den DB-Server installiert habe) komme ich per psql direkt an die DB (wenn ich der OS-User postgres bin…)
  • Objekte anschauen (“Erste Schritte”):
    • TUI: nach Eingabe von psql kann ich einfach z.B. \dt eingeben und bekomme alle Tabellen gelistet, \d nachnamen zeigt mir instant die Tabellenstruktur, dazu Indexe, Primär-/Fremdschlüssel etc. an
    • in allen GUIs muss ich dafür erst durch einen Baum klicken, in pgAdmin4 z.B. Servergruppe -> Server -> Datenbank -> Schemas -> ‘public’ -> Tabellen

Die (online-)Trainings-VMs sind nur per ssh und Webinterface erreichbar

  • um da per GUI dranzukommen, müssten also die Teilnehmer erstmal Software auf ihren (privaten oder dienstlichen) PCs installieren…

Viel entscheidender ist aber m.E.:

psql ist für den PostgreSQL-DBA, was vi für den U\*\*X-Admin ist:

  • auf jeder PostgreSQL-Maschine verfügbar
  • minimalistisch, aber gleichzeitig unglaublich leistungsfähig
  • ich muss das sowieso zu nennenswerten Teilen beherrschen, z.B.
    • für den Fall, dass mir die Firewall einen Streich spielt
    • wenn ich mal als Superuser in die DB will/muss (max_connections= ausgeschöpft)
    • um Dinge zu scripten

Wenn mir jemand erzählt, er oder sie sei UNIX-Admin, dann aber einen nano benutzt, bin ich sofort (zurückhaltend ausgedrückt) skeptisch.

Ähnlich ist es mit psql. Ich muss (als DBA) sowieso wissen, wie ich damit z.B. Objekte anzeigen, DDL einspielen, ggfs. mal eine Stored procedure umschreiben etc. pp. kann. Wenn ich die Software also sowieso (halbwegs) beherrschen muss, kann ich sie doch auch gleich benutzen? Ich sehe nur wenige Szenarien, in denen ein(e) DBA von einem GUI profitieren würde.

Ein(e) AnalystIn hingegen wird die DB wahrscheinlich eher direkt an ein Reporting-Tool oder M$ Excel anbinden wollen.

Bleibt der/die (SQL-) EntwicklerIn. Ja, fair enough, da sehe auch ich gewissen Charme (üblicherweise F5 drücken, um das SQL im Fenster (erneut) laufen zu lassen). Auf der anderen Seite ist derselbe Effekt in psql durch Eingabe von \e zu erreichen, und da kommt ein vi. Der ist ja bekanntlich minimalistisch, aber… 😉

Und ob man DDL jetzt per GUI erzeugen sollte, darüber scheiden sich ja auch die Geister… IMHO eher nicht.

Fazit:

“I never leave the house without it!”

psql ist der vi(m) der PostgreSQL-Welt. Unfassbar flexibel und leistungsfähig, immer verfügbar und dadurch absolutes “Pflichtprogramm”.

P.S.

Ich habe mal jemanden kennengelernt, der eine U\*\*X-Consulting-Firma betrieb und lt. eigener Aussage nur Menschen anstellte, die den ed beherrschen. So weit würde ich dann auch nicht gehen… 😉

P.P.S.

Vielleicht hat die Abneigung gegen TUIs was mit Oracles SQL*Plus (TM) zu tun? Wäre absolut nachvollziehbar, das fasse ich auch nur mit der Kneifzange an…

 

Über den Author:

Gunnar “Nick” Bluth hat seine Liebe zu relationalen Datenbanken Ende des letzten Jahrtausends entdeckt. Über MS Access und MySQL 3.x landete er sehr schnell bei PostgreSQL und hat nie zurückgeschaut, zumindest nie ohne Schmerzen. Er verdient seine Brötchen seit beinahe 20 Jahren mit FOSS (Administration, Schulungen, Linux, PostgreSQL). Gelegentlich taucht er auch tiefer in die Programmierung ein, so als SQL-Programmierer bei der Commerzbank oder in App-Nebenprojekten.
Philipp Dorschner
Philipp Dorschner
Developer

Philipp hat im Jahr 2017 die Ausbildung zum Fachinformatiker – Systemintegration bei NETWAYS Professional Services begonnen. Während der Ausbildung bekam er ein immer größeres Interesse am Programmieren. Das führte dazu, dass Philipp nach erfolgreich bestandener Ausbildung die Kolleg:innen aus Professional Services nicht nur als Consultant sondern auch als Entwickler tatkräftig unterstützt. Neben seinem Interesse an der Informationstechnologie, macht er Sport im Freien oder liest bei schlechtem Wetter auch gerne mal ein Buch zu Hause.