|
Konzept für eine Art Web-Shop mit App-Unterstützung
Hallo zusammen,
Ich habe mich lange nicht mehr blicken lassen, wäre aber um ein paar Denkanstöße dankbar. :wink: Folgendes Szenario:
Nun zum Konzept:
Kennt sich jemand von euch mit dem Thema aus und kann mir ein paar Tipps geben? Viele Grüße Matze |
AW: Konzept für eine Art Web-Shop mit App-Unterstützung
Tja für diese Problemstellung, gibt es sicherlich 100 verschiedene Ansätze.
Wenn Du das auf einem "normalem" Webspace aufsetzen willst, fallen aus meiner Sicht alle "coolen" Ansätze weg. Für die Webseite würde ich dann ggf. TMS WebCode ins Auge nehmen... Für die App natürlich FMX... ggf. mit einem Edge-Browser für die Webseite... Soweit zu Deinen Vorgaben... Ich würde es anders machen! Das geht dann jedoch nur dann wenn Du einen "richtigen" Server hast! Hierzu verweise ich auf  meinen vorletzten Blogpost.Ich würden einen Rest(full) WebService in Delphi als ISAP-DLL schreiben der in der Lage ist sowohl die Webseite zu betreiben als auch die Daten für eine native FMX-App bereitstellen kann. Die Intelligenz kann dann auf dem Service liegen. Für die Webseite würde ich wie im Blogpost beschrieben dann eine Kombination aus HTML und Delphi-Script zurückgreifen. TMS-WebCode würde natürlich auch in diesen Fall funktionieren. Grüsse Mavarik :coder: |
AW: Konzept für eine Art Web-Shop mit App-Unterstützung
Bei PHP fällt mir zuerst Laravel ein, für das Frontend könnte man z.B. Angular mit Ionic verwenden, das Ganze evtl. als PWA, dann hast Du für Website und App dieselbe Codebase. Die Lösung besteht damit nur aus OpenSource-Komponenten und läuft auf jedem OS.
|
AW: Konzept für eine Art Web-Shop mit App-Unterstützung
Zitat:
- Hacker auf meinen Server wegen Fehler in PHPAdmin - Hacker auf meinen Server wegen Lücke in Drupal - Hacker auf meinen Server - keine Ahnung was es jenes mal war. In jedem Fall war der Server nicht mehr zu retten. Daher werde ich NIE wieder PHP verwenden, auf meinem Server installieren oder ein PHP Tool verwenden... Mavarik PS.: Aber das soll keinen davon abhalten! |
AW: Konzept für eine Art Web-Shop mit App-Unterstützung
Und bei Delphi-Webgefrickel kann so etwas nicht passieren? PHP kam ja nicht von mir, es gibt ja auch noch jede Menge anderer Möglichkeiten, NestJS beispielsweise. Aber letzten Endes muss Matze sich sowieso erst einmal umschauen und sich dann entscheiden, welche Lösung er für geeignet erachtet.
|
AW: Konzept für eine Art Web-Shop mit App-Unterstützung
ich denk mal mit TMS WebCore (nicht WebCode wie Maverik/Frank schrieb), bist du eigentlich auf einem guten Weg, damit lässt sich auf Basis einer Programmierung der ganze Kram wirklich Multilattform einsetzbar machen, sofern alle Plattformen einigermaßen brauchbare Browser einsetzen. Es erspart dir den ganzen Kram, wie man native Apps in die ios bzw android Appstores bekommt und wenn du ein Update hochladen willst, musst du niemanden fragen, ob der das denn auch netterweise irgendwann mal freischaltet.
Php setzen wir zwar ziemlich oft dafür als Backend zwischen webserver und firebird db ein, weil das dann ziemlich einfach ist, darüber datenbankzugriffe zu machen, das passiert aber immer nur mit php script files, die zu 100% auf unserem eigenen Mist gewachsen sind und nicht irgendwelche lustigen frameworks, die zwar anfänglich alles sehr einfach aussehen lassen, am Ende dir aber die Erfahrungen von Maverick in Erinnerung rufen werden, wenn du den Kram verfluchst. So ein php script hat bei uns keine 50 Zeilen php code, bindet gar nichts externes ein und läuft daher sehr einfach und sauber. Ein eigener OAuth Mechanismus ist damit auch schneller selbst aufgebaut, als irgendwelche wahnsinnig tollen libs, die das alles eh schon können, aber oft auch sachen können, die man gar nicht haben möchte und der eigentliche Entwickler wohl auch irgendwann mal übersehen hatte ... . Das was TMS Webcore dann meiner Meinung nach wirklich sehr gut macht, ist das du bei Bedarf damit sogar mobile laufende offline Applikationen erstellen kannst. Ob du das am Ende mit Delphi machst oder mit Lazarus ist ziemlich egal, weil am Ende statt einer Windows Exe beim compile Javascript dabei rauskommt, und das dann eben im Browser läuft, lokal, egal ob online oder offline (bei einer php/isapi webanwendung ist das undenkbar, bei den meisten anderen für delphi verfügbaren frameworks ebenfalls, da muss auf irgendeinem server irgendwas laufen und nur das liefert dir results auf deinem device, wenn keine verbinding, dann keinerlei funktion. (ich hatte das mal in einem video hier gezeigt https://youtu.be/uVa9Y0-TyoA?t=5616)Das ist bei TMS Webcore überhaupt nicht der Fall und als Komponenten has du auf der Webcore Plattform alles mögliche auch schon drin. Webcore Apps kanns du übrigens auch auf dummen Webservern ablegen, für den Zugriff auf eine irgendwo unter deiner Kontrolle liegende db wird das schon ein wenig komplizierter, Wenn das aber windows fokus haben soll, ist das einfachste, dir dafür zB. einen eigenen Windows virtual server mieten, auf dem du dann installieren kannst, was du willst (mit allen vor und Nachteilen), kostet so ab 15 € im Monat, je nach anbieter und Leistung. Auf dem Weg geht sonst auch die von maverick vorgeschlagene isapi dll rest lösung, aber was am ende der beste weg ist und auch unter hoher last noch benutzbar ist, hängt weniger davon ab, was du da einsezt, sondern mehr davon, wie du das umsetzt. Scheisse programmieren kann man mit fast jeder Programmiersprache, aber in vielen Sprachen sind gute Lösungen umsetzbar. |
AW: Konzept für eine Art Web-Shop mit App-Unterstützung
Huhu Matze,
eine App die einfach nur eine Webseite kapselt funktioniert nur genau so gut, wie die Webseite. Wenn Du keine Online-Verbindung hast, in aller Regel gar nicht. Da muss man also ein klein wenig mehr machen. Für offline-Fähige Webseiten (sogenannte Progressive Web Apps) gibt es inzwischen genug API-Support auf allen Plattformen. Um eine PWA zu bauen bieten sich auch verschiedene SPA (Single Page Application) Frameworks an. Wenn Du was verlässliches, battle-tested haben willst schreibst Du die Seite dann in Angular oder React. Angular ist eher Komponenten-Orientiert und gibt als Framework viel vor, was Dich, denn entsprechenden Einarbeitungsaufwand vorausgesetzt, super produktiv macht. React ist eher ne Sammlung von Libraries und gibt wenig vor, Du musst also jedes mal für jedes Teilfeature das Du benötigst gucken, welche Bibliothek Du dafür benutzen möchtest und selber schauen wie Du es da in ein Gesamtbild reinbekommst. Wenn Du die Webseite / SPA hast, kannst Du sie mit Apache Cordova in eine App für iOS und Android verpacken. Wenn Du Desktop-Lösungen magst steckst Du die Anwendung dann in Electron rein. Authentication: Kauf bzw. Miete Dir was. Auth0, Okta, Azure Active Directory, Hosted Keycloak, irgend sowas. Wenn Du das selber machen willst kostet das massig Zeit. Wir reden hier jeweils von Wochen an Anpassungen an ggf. teuer lizenzierten Komponenten damit das am Ende das tut was Du brauchst. Und wenn Du Clientseitige Bibliotheken verwendest achte unbedingt darauf, dass sie OIDC-Zertifiziert sind. Zwingend! Das ist alles Security-Relevant. Ich habe bisher keinen Kunden gesehen der sowas selbst versucht hat und das hinterher sicher war. Das Protokoll ist nicht ohne und da reichen schon mini-Fehler um durch das Weglassen von "was unwichtigem" oder minimal falsch interpretierte Dinge auf einmal Scheunentore offen stehen zu lassen. Das ist ein Schweizer Käsemodell par excellence und jede noch so dünne Scheibe / Schicht sorgt dann am Ende dafür das ein Angreifer nicht mit 08/15 Standard-Attacken einfach mal durchkommt. Backend / API: Auch hier: Verlass Dich am besten auf millionenfach battle-tested Frameworks. Wir bauen APIs auf Basis von ASP.NET Core auf .NET 6 (ehemals .NET Core). Bringt wirklich alles mit was Du brauchst. Ne einfache REST-ähnliche API inkl. DB-Anbindung (egal ob MSSQL, Postgres, MariaDB / MySql), OAuth-basierte Anmeldung die normale Create/Read/Update/Delete Operationen für alle Tabellen, eine lebende API-Dokumentation etc. bereitstellt ist in maximal 2 Stunden fertig und kann sowohl auf Windows, Linux, macOS und auch Containerisiert für die Cloud (Docker, Kubernetes) deployed werden. |
AW: Konzept für eine Art Web-Shop mit App-Unterstützung
sorry, Sebastian, aber ich als alter Sack bin da mal so gemein, deine Antwort mal auf die wichtigsten Namen zusammen zu kürzen
Ist es korrekt, das dein Vorschlag also erst mal die Evaluierung und Bewertung dieser Technologien vorschlägt (ich hab nicht alle genommen, nur die ersten 16 die mir aufgefallen sind) PWA SPA battle-tested Angular React Apache Cordova Electron Auth0 Okta Azure Active Directory Hosted Keycloak OIDC ASP.NET Core auf .NET 6 (ehemals .NET Core). OAuth-basierte Anmeldung Docker Kubernetes Wenn dem so ist und das jeder alles so parat haben sollte, dann frag ich mal ganz offen, ob es nur mir so geht, das ich ohne den ganzen Kram bisher sehr gut klarkomme, einiges davon zwar kenne, aber gar nichts davon für existenziell wichtig und unersetzbar halte. Ist aber vielleicht auf die ursprüngliche Frage von Matze die bessere Antwort auf einen anderen Teil, ich hatte da eher den Teil "Wie gesagt wäre ein All-In-One-Tool (vgl. Xamarin) eine feine Sache." im Fokus und dachte mir (da wir ja im DelphiPraxis Forum sind) der TMS Ansatz kommt dem schon sehr nahe Deine Antwort geht dann ja eher in Richtung der daruf folgenden Frage "Oder welche Frameworks sind zu empfehlen?" wobei ich keineswegs sagen will, das die Sachen da alle unwichtig sind, sondern im Enterprise Umfeld sicher eine Existenzberechtigung haben, aber viellicht bin ich ja auch wirklich zu alt und zu faul, den ganzen Kram zu lernen und zu verstehen, solange ich mit dem was ich mache,eigentlich alles abdecken kann, was ich so brauche. |
AW: Konzept für eine Art Web-Shop mit App-Unterstützung
Hallo zusammen,
Wahnsinn, was für tolle Antworten in der kurzen Zeit von euch kamen. Vielen Dank dafür! Zugegeben, ich muss einiges erstmal recherchieren, da ich mit einigen Begriffen noch gar nichts anfange. Aber schon mal echt top, dass ich nun ein paar Ansätze habe. :thumb: Grüße Matze |
AW: Konzept für eine Art Web-Shop mit App-Unterstützung
Zitat:
Zitat:
Mir als altem Sack geht es total auf den Sack - um bei dem Wortspiel zu bleiben - das es jeden Tag ein neues XY gibt das angeblich viel besser ist und natürlich von Facebook oder google entwickelt oder verwendet wird, daher muss es ja gut sein... Ich will jetzt nicht mit der alten Laier kommen, dass man alles mit Delphi machen kann (auch wenn es so ist). Aber warum soll ich in einem Delphi Forum als Antwort geben: "Nimm doch C#" *grummel* Ich denke doch, wenn jemand in einem Delphi Forum diese Frage stellt, erwartet er auch eine Antwort wie es mit Delphi geht, oder? Mavarik |
AW: Konzept für eine Art Web-Shop mit App-Unterstützung
Zitat:
|
AW: Konzept für eine Art Web-Shop mit App-Unterstützung
Ich finde es schon sehr wichtig auch Themen aus anderen Welten zu beleuchten (C#, PHP, Python, ...),
damit man nicht nur in seiner eigenen Suppe kocht. Auch deshalb um Programmierer aus diesen externen Welten vielleicht ein bischen von Delphi zu begeistern und Wege zur Kooperation zu zeigen. Also "Programmier"-Globalisierung versus "Programmier"-Abschottung wäre meine Devise :-D |
AW: Konzept für eine Art Web-Shop mit App-Unterstützung
Zitat:
- Sind die altbekannten Technologien wirklich gut genug für so ein Vorhaben? - Bringen mir auf verteilte (Web- und App-) Applikationen spezialisierte Werkzeuge einen Vorteil? - Wie lange soll das neue Produkt am Markt bleiben? (Hoffentlich mehr als nur 3-4 Jahre?) - Finden sich dann in 5-7 Jahren noch Entwickler, die sich mit der altbekannten Technologie auskennen? - Kann ich junge Entwickler dann noch mit meinem Technologiestack überzeugen? - Wie wichtig ist das Produkt für mein Business? - Kann ich es mir leisten, das Ding mittelfristig wieder weg zu werfen und neu zu machen wenn die altbekannte Technologie doch nicht fliegt? Man sollte dabei auch noch folgendes bedenken: Wir haben hier kein einfaches Client-Server Setup. Sobald Du Dich im Web- und App-Umfeld bewegst arbeitest Du zwangsläufig an einer verteilten Architektur. Du hast Persistenz (DB, kann aber auch mal ne Messagequeue oder ein Eventstore sein), Du hast Services/APIs die zustandslos sein müssen (zumindest ab dem Zeitpunkt an dem Du eine einfache Basis-Ausfallsicherheit sicherstellen möchtest), Du hast Clients auf verschiedenen Plattformen und der Zustand des Gesamtsystems verteilt sich auf Persistenz, Netzwerk und Client-Anwendungen. Und nein, so ne App kann mal offline sein, Du kannst also nicht einfach alles in Transaktionen auf der DB packen um das konsistent zu halten. Du brauchst entweder verteilte Transaktionen (guter Rat: tu's nicht), oder, besser und korrekter, Du setzt auf eventual consistency (irgendwann wird's wieder konsistent werden, nur jetzt grad in dieser Sekunde noch nicht). Und Du musst das alles im Betrieb überwachen. Gibt es für alle diese Herausforderungen in Deinem Dir jetzt bekannten Werkzeugset Dinge, von denen Du mit Gewissheit sagen kannst dass sie auch bei zehntausenden Anfragen pro Sekunde auf Deinem System grundsolide ihre Arbeit verrichten? Bist Du Dir sicher dass die Sicherheitsschicht Deiner API nicht durch einen Angreifer in ein paar Sekunden ausgehebelt wird (und damit meine ich: Bist Du Dir wirklich sicher? Wie viele unterschiedliche Security-Firmen hast Du mit Penetration-Tests beauftragt um die Aussage zu belegen?). Und wenn Du Dich jetzt fragst: Ist das wirklich notwendig? Das ganze brauch ich doch nicht! Dann überlege: Du hast einen Shop mit Anbindung an ein Zahlungssystem. Welcher Schaden kann potentiell entstehen wenn jemand im Namen eines anderen bestellt, oder jemand mittels DNS-Spoofing Paypal mimt und Deinem System vorgaukelt etwas sei bezahlt dabei hat Paypal die Zahlungsinfos nie erhalten, oder jemand durch eine Lücke in der API die Versandadresse eines Kunden ändert und alle teuren Waren an eine Paketstation gehen und der Empfänger unbekannt ist? Und das sind nur die einfachen Angriffe. Für sowas haben professionelle Täter heute Scripte die sowas ausprobieren, da sitzt keiner manuell dran und versucht Dein System zu hacken - das System übernehmen die vollautomatisiert. Und dann sind die Antworten auf die folgende Fragen eigentlich sehr einfach: Will ich nicht lieber mein Produkt auf eine technologische Basis setzen, die genau für diese Herausforderungen spezialisiert ist? Sollte ich nicht für meine Webanwendung etwas benutzen, das heute State of the Art ist, und für das ich auch genau jetzt erfahrene Entwickler finden kann? Sollte ich nicht Technologien für meine API einsetzen, die genau dafür spezialisiert ist und mir dort massig Arbeit abnimmt? Sollte ich mich was Security angeht nicht besser auf Armeen von Security-Engineers verlassen als zu meinen, alles selber besser zu können? |
AW: Konzept für eine Art Web-Shop mit App-Unterstützung
:thumb:
|
AW: Konzept für eine Art Web-Shop mit App-Unterstützung
Vielleicht noch ein kleiner Nachtrag:
Wenn Du einen "Ich bestelle mein Mittagessen innerhalb der Firma" mit Paypalanbindung bauen willst und es nicht schlimm ist, das wenn auf der Kiste auf der das läuft mal ne Platte ausfällt das Ding mal bis zum Tausch nicht funktioniert, dann sind das selbstverständlich ganz andere Anforderungen und dann kann man sowas sicher auch nochmal in Perl bauen, wenn Du das beherrschst. Man darf nie vergessen das der pragmatischste Weg auch funktionieren kann. Aber Public internet und Apps sind dann eben doch was anderes. Da fällt mir übrigens noch was ganz anderes ein @Matze: Apple und Google verlangen auf in-App Verkäufe 30% vom Umsatz. Das gilt grundsätzlich auch für die Verkäufe von physischen Dingen. Wenn Du nicht groß genug bist um Sonderkonditionen auszuhandeln (Amazon, Zalando, eBay etc.) ist das echt ein Problem. Wir haben einen Kunden der das machen wollte (und der ist nicht klein, die Geräte die der verkauft fangen im unteren 5-stelligen Drittel an) und der ist aufgrund dieser Regelung von der Idee seinen Shop als App zu verpacken wieder ganz schnell abgekommen. |
AW: Konzept für eine Art Web-Shop mit App-Unterstützung
Das wäre IMHO ein weiteres Argument für eine PWA.
|
AW: Konzept für eine Art Web-Shop mit App-Unterstützung
Hype-Programming ist doch so hypermegageil ... da kommst nicht dran vorbei.
|
AW: Konzept für eine Art Web-Shop mit App-Unterstützung
Zitat:
als damals noch nicht ganz so alter Sack einem anderen damals auch noch nicht ganz so alten Sack (mir) auf irgendeiner Konferenz (gab es ja damals noch und man war persönlich da) gezeigt hast, wie du den Übergang von Turbopascal zu Delphi gemacht hast und große Teile von deinem Code in beiden Welten compilierbar waren. Fand ihr sehr faszinierend und überzeugend, daher auch nie vergessen. Seit der Zeit hatte ich ja einige Jobs im Delphi Umfeld und da wurde ja von diversen Anbietern wirklich jedes Jahr eine neue Sau durchs Dorf getrieben, die alles mögliche besser konnte. Ich hab mir das sehr oft im Kundenauftrag (gegen Bezahlung versteht sich) gerne immer mal zusammen mit denen angetan, aber so richtig die Palastrevolution gab es irgendwie nie. Immer wenn da jemand spezielle Ideen hatte, wie man dies das oder jenes umsetzen könnte, hab ich dafür ganz brauchbare Lösungen zusammengebaut, gerne auch mit Komponenten, aber selten mit komplett anderen Tools und Archtekturen oder Frameworks, von denen ich noch nicht mal die Buchstabenkombination kannte. Meistens lohnte es sich auch nicht, sich die zu merken, weil die im Jahr danach eh wieder Geschichte waren. Und im Bereich Web gebe ich sebastian auch recht, natürlich gab es dadurch völlig neue Anforderungen und Umsetzungen der selben, SOAP wurde irgendwann durch REST abgelöst, den XML Mumpitz hat irgendwann mal json mit weniger Bytes auch umgesetzt, aber das es im Hype von XML damals sogar eine XML Datenbank gab, mit der man eine kleine Datenmenge ohne echten Mehrwert in einer 10 mal größeren Datenbankdatei speichern konnte, ist an den meisten sicher berechtigt vorbeigegangen ... Ein Kunde hat damit aber mal sicherlich 2 Mannjahre (ohne das ich dafür bezahlt wurde, weil ich das auch nicht gemacht hatte) verbraten, weil sein Entwickler XML-DB für die zukunftssicherste Plattform hielt. Ich hab dann halt gegen honorar den Kram da wieder rausgeholt und in ein klassisches Datenbankmodell mit ein paar Ideen umgesetzt, die man auch in einfachen relationalen SQL Datenbanken umsetzen konnte und das Projekt war ziemlich zeitnah in der Produktionsumgebung einsetzbar, im Gegensatz zu dem anderen Kram. Ich bin nicht sicher, aber ich glaub, der Kram läuft da immer noch mit Firebird 1.5 und meiner Exe, weil der halt das macht, was der machen soll. Schnittstellen der DB an andere Systeme gab es damals schon und weitere wurden da auf jeden Fall im Laufe der Jahre dazu gebaut, aber nicht immer alles weggeschmissen. Es gibt viele Projekte, die ich mal als 80% Mainstream bezeichne. Das ist nicht High Tech sondern simples Handwerk. Die machen was die machen sollen, man muss auch heute noch keine compiler selber schreiben, weil der Quellcode schon seit Jahren mit mehr oder weniger Aufwand immer noch compilierbar ist und nicht alles besser wird, nur weil der Quellcode weggeschmissen wurde und durch einen neuen ersetzt wurde. Das IBExpert Pascal Quellcode Dateien benutzt, deren Zeitstempel noch aus dem letzten Jahrtausend stammen und seitdem nicht verändert wurden, kann ich ganz klar bestätigen, und bei 2 anderen ziemlich großen Projekten gibt es diverse hundert anwender, die das jeweilige Gesamtprojekt seit ca 10 Jahren mit uns begleiten. Sind war keine Webapplikationen, aber werden auch per remotedesktop an dutzenden Standorten ohne Probleme benutzt. Wenn es denn aber damals als Webapp gestartet wäre, dann hätte ich ähnlich wie Frank sicherlich die Werkzeuge, die ich kenne, daraufhin abgeklopft, was damit geht und ganz sicher auch kritisch hinterfragt, wofür sich das Werkzeug evtl nicht wirklich eignet, um zu eruieren, was ich dafür als Ersatz nehmen kann. Mit wäre aber nicht in den Sinn gekommen, erst mal 25 mögliche eierlegende Wollmilchsäue in allen Details zu evaluieren, um dann festzustellen, das 20 davon kompletter Müll sind, 5 zwar ganz gut, aber auch mängel haben usw. Nicht jedes Mainstream Projekt ist ein neuer facebook webserver und nicht jede webshop Anwendung muss alle apis auf diesem Planeten beherrschen. Im b2b Bereich ist eine paypal Zahlung gelinde gesagt Mumpitz, den Auftrag online aber schon mit bonitätsdaten aus dem Kundenstamm oder direkt über creditreform oder ähnlich abzugleichen, um gar nicht erst was zu fertigen, was der eh nich bezahlen wird, ist ein ganz anderer Prozess. Es muss aber nicht jeder Entwickler dabei alles mit einer zeile quellcode alles können, die ganzen Kraut und Rüben Apis zu verstehen ist ein ganz anderes Thema, diese nutzen zu können aber reine Fleissarbeit ich hatte erst vor wenigen Wochen das Vergnügen, die Ladestromregelung für mein Tesla Elektroauto so programmieren zu wollen, das der in erster linie dann lädt, wenn die sonne vom Himmel brennt und die PV Anlage Strom liefert. Eine Mini Exe (lazarus) liefert mit die Daten aus einer ziemlich miesen Api von PV Wandler und schreibt mir den kram in eine Datenbank rein, zusammen mit einer anderen exe (lazarus) die den Stromzähler ausliest, ob der eigenverbauch gerade hoch ist. Beides geht über usb ... (für die jüngeren: das sind Kabel die man da anschliessen muss ;-)) und wenn da genug strom über ist wollte ich eben dem auto mitteilen, das der Lader mal angehen soll oder auch bei wolken wieder aus. Eine Einarbeitung in die Tesla API ist gruselig, zum Glück habe ich aber eh einen serviceprovider im Einsatz, der mir dafür eine single line https api mit oauth anbietet (teslafi.com) über den ich dann aus dem was sich da in der datenbank berechne ergibt, welchen Ladestrom der da im Minutenakt anpassen soll. Das das ganze sogar mit einem fast 7 Jahre alten Tesla geht, finde ich sehr hilfreich. Resume ist aber: aus der Tesla api eine für normal denkende Menschen benutzbare zu machen, hat der typ hinter teslafi super verstanden. warum soll ich das besser können, also lass ich das. den hardware kram mit dem stromzähler und wandler nimmt man wie das ist, sind aber eigenständige teilprojekte oder services oder wie auch immer man das nennt. Am ende landet bei mir der kram in eine Datenbank, ich hab ein schönes protokoll und kann jederzeit meine Logik verbessern (und zum Beispiel dafür sorgen, das der beim Aufladen am Supercharger in Süddutschland nicht abschaltet, nur weil in Norddeutschland gerde wolken sind, der punkt fiel mir dann auch erst da auf, war aber während der Ladepause schnell angepasst). Nun denn, ist schon wieder "oppa erzählt vom krieg ...." ist aber so ähnlich wie frank das schreibt und ich das auch denke. Es gibt wenig was mit delphi/pascal/lazarus nicht geht, manchmal muss man seinen Werkzeugkasten erweitern , aber aus mmeiner sicht eigentlich nie wegschmeissen und durch 20 andere ersetzen. |
| Alle Zeitangaben in WEZ +1. Es ist jetzt 18:15 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz