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 von WeTa
Docker ist doch ein •••••••••, aber nur auf Windows.
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.
--
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.)
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!
Geändert von Manuel (25.12.2017 um 17:32 Uhr)
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:
- Unterprogramme: Sie haben keinen Rückgabewert
- Funktionen: Sie haben einen Rückgabewert
Ich verstehe nicht, was du meinst. Das geht doch.
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.
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.
Microsoft prüft gerade, ob sie Python nicht als offizielle Sprache in Excel einführen wollen:
https://www.bleepingcomputer.com/new...uage-to-excel/
Gleichfalls.Trotz des Rants grade wünsch ich jedem Frohe Weihnachten und einen guten Rutsch ins Neue Jahr!
--
docker/wordpress ist ein •••••••••.
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.
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?
--
sollten wir in this.next() besprechen
Ne stimmt nicht. Python ist gut.
boah weiß nicht
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.
Berechtigungen
Zitieren
