Jeden Tag ein kleines Programmierpuzzle gibt es wie letztes Jahr wieder im Advent of Code Adventskalender:
http://adventofcode.com
Jeden Tag ein kleines Programmierpuzzle gibt es wie letztes Jahr wieder im Advent of Code Adventskalender:
http://adventofcode.com
Docker ist doch kein •••••••••.Zitat:
Zitat von WeTa
Docker ist doch ein •••••••••, aber nur auf Windows.Zitat:
Zitat von WeTa
Volle Zustimmung. Ich hab mal eine Woche damit zugebracht, einen Docker-Container zusammenzubauen, der ein Buildsystem für C#-Projekte auf Basis von GitLab CI und Visual Studio 2017 Community Edition zur Verfügung stellt. Es ist eine wahnsinnige Quälerei und ich hab ihn wenige Tage, nachdem er produktiv war, wieder durch eine vollwertige VM ersetzt.Zitat:
Zitat von WeTa
Könntet ihr wenigstens kurz elaborieren, was Docker ist, wenn ihr schon darüber schimpft ?
Irgendwo zwischen chroot und Minimalvirtualisierung. Du kannst dir Container bauen, die den gleichen Kernel nutzen, wie das Betriebssystem, aber ansonsten vollkommen voneinander isoliert sind. Eigenes virtuelles Dateisystem, eigener RAM, ggf. eigener Netzwerkstack. Im Vergleich zu echten VMs ist das ressourcensparend genug, dass man jedem Programm seinen eigenen Container geben kann. Die Hauptvorteile sind, dass man die Containerimages für extrem viele Programme fertig konfiguriert runterladen kann und dass das im Serverbetrieb sehr viel sicherer ist, als alles direkt im gleichen Kontext laufen zu lassen. Wenn jemand eine Sicherheitslücke in meinem Datenbankserver findet, dann kann er sich höchstens in dem Container austoben, in dem die Datenbank läuft und reißt nicht gleich die ganze Maschine mit.
Zusätzlich gibt es auch noch recht komfortable Lösungen, um Docker Container automatisch auf die Knoten in einem Cluster zu verteilen und viel viel mehr. Das würde den Umfang dieses Posts jetzt sprengen.
Das Problem mit Docker unter Windows ist, dass die Container keine grafische Oberfläche haben, sondern man alles (inklusive der Softwareinstallation) über PowerShell oder CMD machen muss. In der Theorie mag das funktionieren, in der Praxis ist es ein furchtbares Gefrickel.
Jemand schonmal in VBA programmiert? Vorneweg, hört niemals darauf, wenn jemand sagt, das Ding kann OOP. Irgendwie kann es das, aber nur in einer grausam-frickeligen, überhaupt nicht durchsichtigen und pervers verdrehten, Gehirnzellen-zerstörenden Variante. Wäre H.P. Lovecraft Programmierer gewesen, er hätte OOP in VBA erfunden.
Man kann in VBA - wie mit jedem anderen GUI-Toolkit ja auch - Buttons (etc.) eine "Methode" (Anführungszeichen sind absichtlich eingefügt worden) zuweisen, was aufgerufen werden soll, wenn man draufklickt.
In Microsofts VBA-Welt muss diese "Methode" aber ein Unterprogramm einer Prozedur sein. Aber was ist, wenn man eine echte Methode innerhalb des Objekts aufrufen will? Tjoar, ähm... geht nicht. Es ist nicht möglich, es gibt schlicht keinen Befehl dafür. Wie, du willst nach dem Button-Druck irgendwas an dem Objekt verändern? Pech gehabt, geht heutzutage nur in gefühlt 99,9% aller Sprachen mit OOP, aber nicht in VBA... Also darf man irgendwelche Workarounds benutzen die Programmierer besonders (un)glücklich machen, etwa globale Variablen... Und in allen VB-Foren dieser Welt bekommst du verwunderte User, die fragen, weshalb man sich überhaupt mit Klassen beschäftigen soll, wenn eh alles so gut in Prozeduren läuft...
(EDIT: Nur der Vollständigkeit halber: "Me" (Äquivalent zu "this" in Java und "self" in Python) lässt sich per Parameter auch nicht übergeben, sodass der Umweg über eine Prozedur, die besagte Methode am Objekt aufruft, auch nicht klappt. :gah2:)
Ich installier mir jetzt Python und darauf irgendein Excel-Binding...
---
Trotz des Rants grade wünsch ich jedem Frohe Weihnachten und einen guten Rutsch ins Neue Jahr! :)
VBA darf man nicht mit VB verwechseln. Das sind im Grunde zwei unterschiedliche paar Schuhe, auch wenn beide die selbe Syntax teilen und da liegt die Falle: Während VB doch objektorientiert ist, ist VBA für prozedurale Entwicklung gedacht. Es gibt zwar in VBA sowas wie Klassen und Objekte aber es gibt keine Vererbungen oder keine Interfaces.
Nein, es ist eine Prozedur. Die nennen sich nur Unterprogramm. Methoden werden in zwei Arten unterteilt:Zitat:
In Microsofts VBA-Welt muss diese "Methode" aber ein Unterprogramm einer Prozedur sein.
- Unterprogramme: Sie haben keinen Rückgabewert
- Funktionen: Sie haben einen Rückgabewert
Ich verstehe nicht, was du meinst. Das geht doch.Zitat:
Aber was ist, wenn man eine echte Methode innerhalb des Objekts aufrufen will? Tjoar, ähm... geht nicht.
Das ist nicht korrekt. Wie auch in allen anderen OOP-Sprachen, muss das Objekt existieren. Also muss es auch irgendwo instanziiert und gehalten werden. In anderen OOP-Sprachen spricht man von Klassenvariablen oder Klassenmember und du kannst pro Modul solche Variablen/Member anlegen, die auch nur im Modul sichtbar sind und nicht global.Zitat:
Wie, du willst nach dem Button-Druck irgendwas an dem Objekt verändern? Pech gehabt, geht heutzutage nur in gefühlt 99,9% aller Sprachen mit OOP, aber nicht in VBA...
Wie gesagt, VBA ist keine richtige objektorientierte Sprache. VBA wird auch nicht wirklich von Softwareentwicklern verwendet, sondern überwiegend von Endanwender, die sich damit irgendwas zurecht frickeln und sich auch gar nicht mit Objektorientierung auskennen. Wir haben da inzwischen auch einige Projekte am Laufen, weil unsere Kunden die Aufforderung bekommen, ihre Prozesse, die sie überwiegend mit Excel-Makros gelöst haben, in eine standardisierte und dokumentierte Software zu überführen und was man da sieht, ist echt gruselig.Zitat:
Und in allen VB-Foren dieser Welt bekommst du verwunderte User, die fragen, weshalb man sich überhaupt mit Klassen beschäftigen soll, wenn eh alles so gut in Prozeduren läuft...
Microsoft prüft gerade, ob sie Python nicht als offizielle Sprache in Excel einführen wollen:Zitat:
Ich installier mir jetzt Python und darauf irgendein Excel-Binding...
https://www.bleepingcomputer.com/new...uage-to-excel/
Gleichfalls. :)Zitat:
Zitat von Manuel
docker/wordpress ist ein •••••••••.Zitat:
Zitat von WeTa
Ich verzichte freiwillig auf 10% Gehalt, wenn das heißt, dass ich NIE WIEDER mit einem User reden muss.
Alle User müssen brennen. Dasselbe gilt für IT. My life is strictly a developer only space now.
Der Ton hier ist genau der gleiche wie im IRC-Channel unserer Sysadmins.
Docker ist überall ein •••••••••. "sudo apt-get install •••••••••" <- installiert Docker. Es gibt 2 Arten von Entwicklern: Entwickler noch nichts gescheites mit Docker gemacht haben und Entwickler die Docker scheiße finden.Zitat:
Zitat von WeTa
Stattdessen kann ich normale LXC-Container mit Orchestrationsoftware (um schnell mal einen Dev-Container zu bauen) empfehlen; hat sich einigermaßen bewährt.
wer ist eigentlich auf die enorm kluge idee gekommen, dass C-c in GUI Kopieren ist und auf CLI Prozess killen
Ich verlasse mich nie mehr auf irgendwas, was ich im Internet lese.
Internet: Python ist gut! Tatsächlich leider: Python ist nicht gut.
Internet: Perl ist nicht gut! Tatsächlich aber: Perl ist gut.
Und jetzt soll ich mich auf das verlassen, was ich von dir im Internet lese?
http://cherrytree.at/misc/smilies/032gruebel.gifZitat:
Zitat von DFYX
sollten wir in this.next() besprechen
Ne stimmt nicht. Python ist gut.Zitat:
Zitat von WeTa
boah weiß nicht
(*_*)Zitat:
virtualenv is a very popular tool that creates isolated Python environments for Python libraries. If you're not familiar with this tool, I highly recommend learning it, as it is a very useful tool, and I'll be making comparisons to it for the rest of this answer.
It works by installing a bunch of files in a directory (eg: env/), and then modifying the PATH environment variable to prefix it with a custom bin directory (eg: env/bin/). An exact copy of the python or python3 binary is placed in this directory, but Python is programmed to look for libraries relative to its path first, in the environment directory. It's not part of Python's standard library, but is officially blessed by the PyPA (Python Packaging Authority). Once activated, you can install packages in the virtual environment using pip.
pyenv is used to isolate Python versions. For example, you may want to test your code against Python 2.7, 3.6, 3.7 and 3.8, so you'll need a way to switch between them. Once activated, it prefixes the PATH environment variable with ~/.pyenv/shims, where there are special files matching the Python commands (python, pip). These are not copies of the Python-shipped commands; they are special scripts that decide on the fly which version of Python to run based on the PYENV_VERSION environment variable, or the .python-version file, or the ~/.pyenv/version file. pyenv also makes the process of downloading and installing multiple Python versions easier, using the command pyenv install.
pyenv-virtualenv is a plugin for pyenv by the same author as pyenv, to allow you to use pyenv and virtualenv at the same time conveniently. However, if you're using Python 3.3 or later, pyenv-virtualenv will try to run python -m venv if it is available, instead of virtualenv. You can use virtualenv and pyenv together without pyenv-virtualenv, if you don't want the convenience features.
virtualenvwrapper is a set of extensions to virtualenv (see docs). It gives you commands like mkvirtualenv, lssitepackages, and especially workon for switching between different virtualenv directories. This tool is especially useful if you want multiple virtualenv directories.
pyenv-virtualenvwrapper is a plugin for pyenv by the same author as pyenv, to conveniently integrate virtualenvwrapper into pyenv.
pipenv aims to combine Pipfile, pip and virtualenv into one command on the command-line. The virtualenv directory typically gets placed in ~/.local/share/virtualenvs/XXX, with XXX being a hash of the path of the project directory. This is different from virtualenv, where the directory is typically in the current working directory. pipenv is meant to be used when developing Python applications (as opposed to libraries).
As of writing, pipenv has not seen a release on Pypi since November 2018, and there are no commits on GitHub since November 2019. The documentation website pipenv.org is down (#4137), and users are posting issues asking whether pipenv is dead
tooling so anstrengend wie bei javascript
Perl ist wegen den ganzen CPAN-Modulen und der immer noch relativ guten Geschwindigkeit ganz brauchbar aber ein größeres Perl-Projekt bei dem mehr als 3 Personen Code schreiben würde ich heute nicht mehr anreißen (den ganzen Wahnsinn um $_, @_, Skalar/Listenkontext,... und den 1000 Möglichkeiten um genau die gleichen Standardroutinen zu implementieren würde ich mir nicht ohne guten Grund antun). Vielleicht Ist Raku/Perl 6 in der Hinsicht besser; hat zumindest mal vielversprechend ausgesehen.
Ja, was Großes würde ich damit auch nicht anfangen, aber ich glaube das ist jetzt meine Lieblings-"Kurz was scripten"-Sprache.
Ich muss aber auch sagen, dass Python keinen Spaß macht. Ja, es ist für gewisse Use-Cases wahnsinnig schnell, aber das Tooling ist echt einfach nur grauenhaft, insbesondere wenn man Python als Abhängigkeit von irgendwas in ein anderes Projekt einbindet und nicht ein reines Python-Projekt macht. Da wäre etwas wie Composer eine Million mal angenehmer zu benutzen als Pythons obskurer Salat aus venv, pip, pro-Projekt-Runtimes und weiteren Dingen, die mich nicht interessieren, wenn ich einfach nur einen in Python geschriebenen PDF-Renderer mit seinen Abhängigkeiten in meiner C#-Anwendung verwenden will.
Ich habe das Gefühl, dass Python so eine polarisierende Sprache ist. Entweder geht man voll darin auf oder man findet sie furchtbar.