1. Foren
  2. Kommentare
  3. Internet-Forum
  4. Alle Kommentare zum Artikel
  5. › NPM: Über 250 Node-Module wegen…
  6. Thema

Was hab ich mich schon mit NPM geärgert!

Neue Foren im Freiraum! Raumfahrt und freie Software haben jetzt einen Platz, die Games tummeln sich jetzt alle in einem Forum.
  1. Thema
  1. 1
  2. 2

Neues Thema Ansicht wechseln


  1. Re: Was hab ich mich schon mit NPM geärgert!

    Autor: lottikarotti 23.03.16 - 21:46

    Einen Packagemanager zu verwenden heißt nicht zwangsläufig, dass man nur öffentliche Repositories nutzt. Außerdem kannst du dir, wenn es der Kontext erfordert, immer noch alle Pakete manuell herunterladen und auf ewig irgendwo abspeichern. Gäähn.

    R.I.P. Fisch :-(

  2. Re: Was hab ich mich schon mit NPM geärgert!

    Autor: lottikarotti 23.03.16 - 21:48

    Wenn du viele Anwendungen mit total unterschiedlichen System-Konfigurationen auf einem System laufen lassen musst, wird's Zeit für Docker.

    R.I.P. Fisch :-(



    1 mal bearbeitet, zuletzt am 23.03.16 21:48 durch lottikarotti.

  3. Re: Was hab ich mich schon mit NPM geärgert!

    Autor: wasdeeh 23.03.16 - 21:51

    RipClaw schrieb:

    > Entwickler sollten meiner Meinung nach mal von ihrem Elfenbeinturm
    > runterkommen

    Was Packagemanager bzw. Build-Tools für Webprojekte betrifft, ist das wohl des Pudels Kern.
    Ich fühle mich die letzten Jahre wie in Groundhog Day, was das Wiederholen von Fehlern von z.B. der ersten Maven-Versionen betrifft.

  4. Re: Was hab ich mich schon mit NPM geärgert!

    Autor: Sinemat 23.03.16 - 22:09

    RipClaw schrieb:

    > Das sind beides keine kleinen Projekte bei denen jemand seine Freizeit
    > opfert. Das sind riesige Projekte bei denen viel Geld fließt.

    Ich durfte vor zwei Jahren einige Leute aus dem TYPO3-Core kennenlernen, wenngleich ich auch kein Fan des CMS bin.
    Dort wurde zumindest gesagt, dass nach der Arbeit an TYPO3 gearbeitet wird. Ebenso sind die Gelder, die für die Teams als Budget fließen nicht so hoch, wie man es vielleicht erwarten würde.
    Angesichts dieser Tatsachen sind deine Aussagen eher frech.

    Ich habe die Daten nicht mehr im Kopf, aber die TYPO3 8er LTS sollte erst im Frühjahr 2017 erscheinen. Daher sidn die Anforderungen in meinen Augen nicht unverschämt.
    Ebenso lange sollte die 6.2er laufen. Dass die Anforderungen an moderne System damit wachsen, sollte klar sein, niemand möchte mehr mit 5.2 programmieren.

    Ein kleiner Schwank aus meinem Leben als Entwickler:
    Der Admin eines Kunden sollte mir eine virtuelle Maschine aufsetzen. Ich beschrieb ihm, was ich gerne hätte. (14.04, PHP 5.6)
    Seine Antwort: "Dann nehme ich gleich eines meiner Images, das sollte passen"
    Ergebnis: Ubuntu 10.04, PHP 5.3
    So habe ich externe Admins kennengelernt.

    Es bereitet keine Freude aufgrund falscher Specs etwas umschreiben zu müssen, obwohl festgelegt wurde, was als Mindestanforderung bereitstehen sollte.

    Zwischen der Migration von Node 0.1x auf 5.x hatte ich nur ein paar kleinere Probleme. Nichts gravierendes, was man nicht hätte lösen können.
    An einigen Dingen war auch der CentOS-Server Schuld ...

    Docker würde viel vereinfachen

  5. Re: Was hab ich mich schon mit NPM geärgert!

    Autor: RipClaw 23.03.16 - 22:09

    lottikarotti schrieb:
    --------------------------------------------------------------------------------
    > > Also statt das die Entwickler das ganze bei sich Pflegen und mit dem
    > > Programm ausliefern sollen die Admins das machen ?
    > Was hat denn nun das grundlegende Konzept eines Packagemanagers damit zu
    > tun, wer für die Pflege verantwortlich ist. Bei uns laufen intern ca. 10
    > unterschiedliche Anwendungen, die im Kern viele Module teilen. Diese Module
    > beziehen sie über ein privates Package-Management. Seitens der
    > Softwareentwicklung ist das ein klarer Vorteil.

    Ich glaube wir gehen hier von unterschiedlichen Umgebungen aus.

    Ich habe viel mit Webservern zu tun die in einem RZ stehen und auf denen soll ich dann z.B. einen Chat zum laufen bringen der in NodeJS geschrieben ist oder ich soll auf einer Kiste das aktuellste Redmine zum laufen bringen weil der Kunde es so haben will.
    Dann darf ich sehen wie ich z.B. Ruby 2.1 mit der aktuellen Rails Version drauf bringe oder ein NodeJS 0.8 baue weil der Chat nicht weiterentwickelt wurde aber der Kunde ihn unbedingt haben will.

    Bei dir ist es eine Firmeninterne Entwicklung. Da sind die Voraussetzungen ganz andere.

  6. Re: Was hab ich mich schon mit NPM geärgert!

    Autor: RipClaw 23.03.16 - 22:13

    lottikarotti schrieb:
    --------------------------------------------------------------------------------
    > Wenn du viele Anwendungen mit total unterschiedlichen
    > System-Konfigurationen auf einem System laufen lassen musst, wird's Zeit
    > für Docker.

    Das ist auch wieder so ein Spielzeug für Entwickler das in der freien Wildbahn nur in Spezialfällen zum Einsatz kommt.

    Mir werden z.B. Server mit Plesk als Adminoberfläche vor die Füße geworfen. Nichts was ich da wirklich beeinflussen könnte.
    Ich kann dann nur versuchen die neuste PHP Version auf die Kiste zu prügeln und in die Verwaltung von Plesk zu integrieren.

  7. Re: Was hab ich mich schon mit NPM geärgert!

    Autor: RipClaw 23.03.16 - 22:34

    Sinemat schrieb:
    --------------------------------------------------------------------------------
    > RipClaw schrieb:

    > Ich habe die Daten nicht mehr im Kopf, aber die TYPO3 8er LTS sollte erst
    > im Frühjahr 2017 erscheinen. Daher sidn die Anforderungen in meinen Augen
    > nicht unverschämt.

    Auf das LTS achten die meisten Kunden nicht wirklich. Da wird die neuste Version genommen egal ob LTS oder nicht.

    Und

    Das krasseste was ich mal mit Typo3 erlebt habe war das mir einer eine Kopie vom typo3conf, der Datenbank und den Upload Verzeichnissen vor die Füße geworfen hat und ich sollte das zum laufen bringen. Von den Entwicklern gab es anscheinend keine Angabe welche Typo3 Version hier verwendet wurde da die Entwickler anscheinend via One Click Lösung bei irgend einem Hoster das Typo3 draufgeworfen haben.

    Ich durfte dann jede Typo3 Version ausprobieren die plausibel erschien bis endlich die Seite lief.

    > Ebenso lange sollte die 6.2er laufen. Dass die Anforderungen an moderne
    > System damit wachsen, sollte klar sein, niemand möchte mehr mit 5.2
    > programmieren.

    Sagt auch kieiner aber man sollte Entwicklerversionen so kennzeichnen da kein Mensch darauf kommt das bei sich installieren zu wollen wenn er nicht die Absicht hat sich eine Entwicklerversion zu holen.

    Ich kenne genügend Kunden denen ich erst lang und breit erklären muss das die 8.0 eine Entwicklerversion ist und nicht für den täglichen Gebrauch gedacht ist.

    > Ein kleiner Schwank aus meinem Leben als Entwickler:
    > Der Admin eines Kunden sollte mir eine virtuelle Maschine aufsetzen. Ich
    > beschrieb ihm, was ich gerne hätte. (14.04, PHP 5.6)
    > Seine Antwort: "Dann nehme ich gleich eines meiner Images, das sollte
    > passen"
    > Ergebnis: Ubuntu 10.04, PHP 5.3
    > So habe ich externe Admins kennengelernt.

    Tja da hast du dann wohl einen von der Sorte "Ich kann Linux booten" erwischt.
    Bei mir hättest du genau das bekommen was du angefragt hättest.

    > Es bereitet keine Freude aufgrund falscher Specs etwas umschreiben zu
    > müssen, obwohl festgelegt wurde, was als Mindestanforderung bereitstehen
    > sollte.
    >
    > Zwischen der Migration von Node 0.1x auf 5.x hatte ich nur ein paar
    > kleinere Probleme. Nichts gravierendes, was man nicht hätte lösen können.
    > An einigen Dingen war auch der CentOS-Server Schuld ...
    >
    > Docker würde viel vereinfachen

    So viel nun auch wieder nicht. Du denkst immer in Einzelanwendungen aber in vielen Fällen muss das auch im Massenhosting laufen und da kannst du nicht Docker Container für jeden Kunden anlegen und jede Website anlegen.

  8. Re: Was hab ich mich schon mit NPM geärgert!

    Autor: Sinemat 23.03.16 - 23:13

    RipClaw schrieb:
    > So viel nun auch wieder nicht. Du denkst immer in Einzelanwendungen aber in
    > vielen Fällen muss das auch im Massenhosting laufen und da kannst du nicht
    > Docker Container für jeden Kunden anlegen und jede Website anlegen.

    Es reicht ja wenn Massen-Hoster ihre Docker-Container bspw. per YAML/XML/JSON/GUI/CLI etc. konfigurierbar halten. Dann kann man sich danach richten.
    Es gibt ja bereits Vorreiter. wichtig ist Beratung. Vom Kunden kann man nicht verlangen etwas aus unserem spezifischen Aufgabenbereichen zu wissen. (Leider, dann wäre es manchmal wesentlich einfacher)

  9. Re: Was hab ich mich schon mit NPM geärgert!

    Autor: gadthrawn 24.03.16 - 08:18

    lottikarotti schrieb:
    --------------------------------------------------------------------------------
    > Package-Manager im Allgemeinen (npm, Composer, NuGet, pip, ..), haben aus
    > Sicht der Softwareentwicklung große Vorteile, denn sie vereinfachen nicht
    > nur den Installationsprozess von "Programmen". Sie ermöglichen es,
    > Abhängigkeiten von seinen Repositories fernzuhalten, eigene Pakete an
    > zentraler Stelle zu platzieren, Abhängigkeiten auf fixe Versionen zu
    > pinnen, Deployment-Prozesse schlank zu halten ..

    Ich hasse die Teile. Bei unseren Projekten mit 3rd Party Komponenten liegen bei einem Projekt auch alle zum Bau benötigten Sachen. Wird bei irgend einer Alt Software etwas nötig-kein Problem, kann man neu installieren. VMs eignen sich da nicht ganz so schön ( wenn du mal etwas 10 Jahre altes hat und merkst, das es den VM Anbieter von damals nicht mehr gibt oder das die VM auf eine neuere v Version migriert werden müsste...).
    Nunja. Paketmanager erschweren die Archivierung. Nicht mehr da? Pech gehabt. Paketmanager in der Form durch etwas neues abgelöst -was natürlich nur neue Sachen drin hat - Pech gehabt.
    Nuget findet man die Pakete im Datei System und kann dir suchen. Und den neuen Ort als Quelle angeben. Im Grunde baut man damit Repositories neu, Stadt einfach einen Installer zu s sichern.
    Oder kurz- paketmanager sind für mich Müll.

  10. Re: Was hab ich mich schon mit NPM geärgert!

    Autor: robinx999 24.03.16 - 09:13

    Nein ich bin kein Webentwickler, aber es stört mich schon wenn es jetzt Programme gibt die man haben möchte die man ausschließlich so Installieren kann.
    In meinem Fall halt Castnow. Ein Kommandozeilen Tool mit dem ich Video / Musik Dateien an einen Chromecast schicken kann und dort werden sie abgespielt. Zusätzlich kann das Tool mittels ffmpeg Dateien die der Chromecast nicht versteht on the fly transcodieren.
    Und ja eigentlich würde ich es nicht als Webtechnologie bezeichnen, aber das Programm wurde Trotzdem in Node.JS geschrieben und als einfacher Nutzer darf man dann Node.JS installieren und muss es außerhalb seines Paketmanager mit einem Anderen Paketmanager installieren und so etwas finde ich alles andere als Ideal.

  11. Re: Was hab ich mich schon mit NPM geärgert!

    Autor: hanswurst85 24.03.16 - 09:39

    Ich versteh' die ganze Aufregung nicht. Nutzt man die offizielle NPM-Registry begibt man sich in eine Abhängigkeit. Punkt. Mussten wir auch erst schmerzhaft lernen. Eine private registry aufzusetzen ist allerdings auch kein Hexenwerk, und die Vorteile sind eben auch nicht von der Hand zu weisen: Benötigte Module sind dann auf Halde verfügbar, externe Abhängigkeiten somit gelöst und der Pflegeaufwand hält sich in Grenzen. Bis auf das einmalige umstellen auf die private registry ändert sich auch nichts im Entwicklungsprozess.

  12. Re: Was hab ich mich schon mit NPM geärgert!

    Autor: lottikarotti 24.03.16 - 09:57

    > Das ist auch wieder so ein Spielzeug für Entwickler das in der freien
    > Wildbahn nur in Spezialfällen zum Einsatz kommt.
    Es kommt dort zum Einsatz wo es gebraucht wird und ich kenne einige Projekte die erfolgreich Docker einsetzen.

    > Mir werden z.B. Server mit Plesk als Adminoberfläche vor die Füße geworfen.
    > Nichts was ich da wirklich beeinflussen könnte.
    > Ich kann dann nur versuchen die neuste PHP Version auf die Kiste zu prügeln
    > und in die Verwaltung von Plesk zu integrieren.
    Ich habe wirklich größtes Mitleid mit dir, aber das ist kein Problem vom Packagemanagement.

    R.I.P. Fisch :-(

  13. Re: Was hab ich mich schon mit NPM geärgert!

    Autor: lottikarotti 24.03.16 - 10:03

    > Ich glaube wir gehen hier von unterschiedlichen Umgebungen aus.
    Also sind deine Umgebungen das Problem?

    > Ich habe viel mit Webservern zu tun die in einem RZ stehen und auf denen
    > soll ich dann z.B. einen Chat zum laufen bringen der in NodeJS geschrieben
    > ist oder ich soll auf einer Kiste das aktuellste Redmine zum laufen bringen
    > weil der Kunde es so haben will.
    Unsere Systeme stehen auch alle samt in einem Rechenzentrum. Dort haben wir vor Ort Ansprechpartner und können die Systeme jederzeit so konfigurieren lassen wie wir es brauchen.

    Wir hatten bisher noch nie ein Problem irgendwelche Softwaremodule zum Laufen zu kriegen und unsere Infra ist mittlerweile unheimlich komplex.

    > Dann darf ich sehen wie ich z.B. Ruby 2.1 mit der aktuellen Rails Version
    > drauf bringe oder ein NodeJS 0.8 baue weil der Chat nicht weiterentwickelt
    > wurde aber der Kunde ihn unbedingt haben will.
    Wie sagte Gary Vaynerchuck (Zitat): "Technology doesn't care about individuals.".

    > Bei dir ist es eine Firmeninterne Entwicklung. Da sind die Voraussetzungen
    > ganz andere.
    Das war nur *eines* von vielen Beispielen.

    R.I.P. Fisch :-(

  14. Re: Was hab ich mich schon mit NPM geärgert!

    Autor: Andre S 24.03.16 - 10:06

    gadthrawn schrieb:
    --------------------------------------------------------------------------------
    > lottikarotti schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Package-Manager im Allgemeinen (npm, Composer, NuGet, pip, ..), haben
    > aus
    > > Sicht der Softwareentwicklung große Vorteile, denn sie vereinfachen
    > nicht
    > > nur den Installationsprozess von "Programmen". Sie ermöglichen es,
    > > Abhängigkeiten von seinen Repositories fernzuhalten, eigene Pakete an
    > > zentraler Stelle zu platzieren, Abhängigkeiten auf fixe Versionen zu
    > > pinnen, Deployment-Prozesse schlank zu halten ..
    >
    > Ich hasse die Teile. Bei unseren Projekten mit 3rd Party Komponenten liegen
    > bei einem Projekt auch alle zum Bau benötigten Sachen. Wird bei irgend
    > einer Alt Software etwas nötig-kein Problem, kann man neu installieren. VMs
    > eignen sich da nicht ganz so schön ( wenn du mal etwas 10 Jahre altes hat
    > und merkst, das es den VM Anbieter von damals nicht mehr gibt oder das die
    > VM auf eine neuere v Version migriert werden müsste...).
    > Nunja. Paketmanager erschweren die Archivierung. Nicht mehr da? Pech
    > gehabt. Paketmanager in der Form durch etwas neues abgelöst -was natürlich
    > nur neue Sachen drin hat - Pech gehabt.
    > Nuget findet man die Pakete im Datei System und kann dir suchen. Und den
    > neuen Ort als Quelle angeben. Im Grunde baut man damit Repositories neu,
    > Stadt einfach einen Installer zu s sichern.
    > Oder kurz- paketmanager sind für mich Müll.

    Ich stimme voll und ganz gut, ist eine neumodische Art zu programmieren die aber soviel Konfigurationsaufwand und Wartungsaufwand nach sich zieht wie vglw. klassisch die Open Source Libary runterzuladen und kurz in das Projekt zu pasten / includen, das der Vorteil dahin ist.

    Der einzige ?Vorteil? sind die kontinuierlichen Updates die möglich sind, mich aber eher in den Wahnsinn getrieben haben anstatt einen grossen nutzen zu haben weil ich die meisten änderungen in Paketen garnicht benötige aber erstmal Dependency Probleme nach sich ziehen und das nur weil ich ein neues Paket hinzugefügt habe, ein Composer Update ziehe und sich ein nicht beabsichtigtes Paket mit erneuert weil ich vergessen hab die Version fix zu setzen.

    IdR. kann eine Libary in einem Programm auch so bleiben sofern dort keine Sicherheitsbedenklichen probleme aufgetaucht sind die gefixt werden müssen aber da bin ich mit dem guten alten automatischen (bei konflikten auch manuellen) Git-Merging defintiv besser dran, ausserdem weiss ich dann Bescheid was tatsächlich geändert wurde statt das das Paket "irgendwas" behebt, verändert oder macht und ich mich dann wundere warum die eine Funktion des Programms / der Website plötzlich nicht mehr geht und ich erstmal debuggen darf welche Funktion jetzt deprecated ist, geändert wurde oder andere Parameter hat.

    Vielleicht bin ich Altmodisch aber ich komme ohne das Zeug besser klar und brauche im Vergleich auch nicht viel länger für eine Umsetzung als jemand der mit Paketmanagern daher kommt.



    2 mal bearbeitet, zuletzt am 24.03.16 10:11 durch Andre S.

  15. Re: Was hab ich mich schon mit NPM geärgert!

    Autor: lottikarotti 24.03.16 - 11:09

    > Ich stimme voll und ganz gut, ist eine neumodische Art zu programmieren die
    > aber soviel Konfigurationsaufwand und Wartungsaufwand nach sich zieht wie
    > vglw. klassisch die Open Source Libary runterzuladen und kurz in das
    > Projekt zu pasten / includen, das der Vorteil dahin ist.
    So ein Blödsinn. Beispiel PHP: Mit einer Zeile wie..

    $ composer require nikic/fast-route monolog/monolog php-di/php-di phpunit/phpunit

    ..habe ich vier Abhängigkeiten -und- deren Abhängigkeiten vollständig installiert. Ein passender Autoloader kann mit einer Zeile direkt in mein Projekt eingebunden werden:

    require(__DIR__ . '/vendor/autoload.php');

    Das war's. Aufwand minimal. Konfiguration gleich 0. Gleiches gilt für npm.

    > Der einzige ?Vorteil? sind die kontinuierlichen Updates die möglich sind,
    > mich aber eher in den Wahnsinn getrieben haben anstatt einen grossen nutzen
    > zu haben weil ich die meisten änderungen in Paketen garnicht benötige aber
    > erstmal Dependency Probleme nach sich ziehen und das nur weil ich ein neues
    > Paket hinzugefügt habe, ein Composer Update ziehe und sich ein nicht
    > beabsichtigtes Paket mit erneuert weil ich vergessen hab die Version fix zu
    > setzen.
    Ebenfalls Blödsinn. Ein großer Vorteil ist, dass man Abhängigkeiten auf eine fixe Version pinnen kann. D.h. man ist von zukünftigen Releases eines Pakets nicht negativ beeinträchtigt und kann jederzeit ältere Versionen eines Pakets nutzen und selbst entscheiden wann man auf eine neue Version migriert. Dazu ist lediglich eine Zeile erforderlich: "express": "4.13.4".

    Diese muss man aber gar nicht selbst eintragen, denn beim Installieren der Pakete kann man npm anweisen, die Versionsnummer automatisch in die Konfiguration einzutragen:

    $ npm i express --save-exact

    Außerdem hält das dein Git-Repository schlank. Statt dass jeder seine Abhängigkeiten 1:1 in seinem Git-Repository bereitstellen muss, reicht eine simple composer.json / package.json.

    > IdR. kann eine Libary in einem Programm auch so bleiben sofern dort keine
    > Sicherheitsbedenklichen probleme aufgetaucht sind die gefixt werden müssen
    > aber da bin ich mit dem guten alten automatischen (bei konflikten auch
    > manuellen) Git-Merging defintiv besser dran, ausserdem weiss ich dann
    > Bescheid was tatsächlich geändert wurde statt das das Paket "irgendwas"
    > behebt, verändert oder macht und ich mich dann wundere warum die eine
    > Funktion des Programms / der Website plötzlich nicht mehr geht und ich
    > erstmal debuggen darf welche Funktion jetzt deprecated ist, geändert wurde
    > oder andere Parameter hat.
    Das mag im kleinen Rahmen alles machbar sein. Aber sobald ein Projekt eine gewisse Komplexität erreicht, die Anzahl der Abhängigkeiten die 100er Marke knacken und 20 Entwickler am Projekt beteiligt sind, ist das nicht mehr ohne enormen Aufwand möglich.

    > Vielleicht bin ich Altmodisch aber ich komme ohne das Zeug besser klar und
    > brauche im Vergleich auch nicht viel länger für eine Umsetzung als jemand
    > der mit Paketmanagern daher kommt.
    Es geht auch nicht darum schneller zu sein. Wer das Konzept immer noch daran misst, hat es einfach nicht verstanden.

    Es hat einen Grund weshalb sich solche Systeme als de-facto Standards etablieren.

    R.I.P. Fisch :-(



    3 mal bearbeitet, zuletzt am 24.03.16 11:12 durch lottikarotti.

  1. Thema
  1. 1
  2. 2

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Sie müssen ausserdem in Ihrem Account-Profil unter Forum einen Nutzernamen vergeben haben. Zum Login

Stellenmarkt
  1. IT-Sicherheitsadministrator (m/w/d)
    Mainova AG, Frankfurt am Main
  2. Mitarbeiter im Service Desk (m/w/d)
    Techniklotsen GmbH, Bielefeld
  3. Berater Krankenhausinformationssystem (KIS) Neueinführungen (m/w/d)
    Helios IT Service GmbH, Berlin-Buch, deutschlandweit
  4. Experte / Inhouse Consultant Cyber Security Product Governance (m/w/d)
    DRÄXLMAIER Group, Vilsbiburg bei Landshut

Detailsuche


Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Spiele-Angebote
  1. 34,49€
  2. 11,99€
  3. 27,99€
  4. 14,99€


Haben wir etwas übersehen?

E-Mail an news@golem.de


Kosmologie: Die Raumzeit ist kein Gummituch!
Kosmologie
Die Raumzeit ist kein Gummituch!

Warum das beliebte Modell von den Kugeln im Gummituch in die Irre führt - und wie man es retten kann.
Von Helmut Linde

  1. Indische Regierung Wir haben noch "kein 5G-Netz, was Corona verursachen könnte"

Klimaschutz: Verbrennerkauf - warum der Verkehrsminister recht hat
Klimaschutz
Verbrennerkauf - warum der Verkehrsminister recht hat

Bundesverkehrsminister Volker Wissing (FDP) warnt vor dem Kauf neuer Autos mit Verbrennungsmotor, weil fossile Brennstoffe keine Lösung sind - auch nicht als E-Fuels.
Ein IMHO von Andreas Donath

  1. Elektroauto VW e-Up ab Mitte Februar wieder bestellbar
  2. Elektromobilität Renault will ab 2030 in Europa nur noch E-Autos anbieten
  3. Hengchi 5 Evergrande baut sein erstes Elektroauto

Einführung in MQTT: Alles läuft über den Broker
Einführung in MQTT
Alles läuft über den Broker

MQTT eignet sich hervorragend für Sensoren und IoT-Anwendungen. Wir geben eine Einführung in das Protokoll für Machine-to-Machine-Kommunikation.
Von Florian Bottke

  1. Ohne Google, Android oder Amazon Der Open-Source-Großangriff
  2. Internet der Dinge Asistenten wie Alexa und Siri droht EU-Regulierung