MOD: Verschoben von PHP-Einsteiger
Ankündigung
Einklappen
Keine Ankündigung bisher.
Debuggen mit Eclipse, Ausgabe nicht teilweise bis breakpoint
Einklappen
Neue Werbung 2019
Einklappen
X
-
The string "()()" is not palindrom but the String "())(" is.
Debugging: Finde DEINE Fehler selbst! | Gegen Probleme beim E-Mail-Versand | Sicheres Passwort-Hashing | Includes niemals ohne __DIR__
PHP.de Wissenssammlung | Kein Support per PN
-
Zitat von MrChangelog Beitrag anzeigenAlso ich nutze Git in NetBeans und hatte nie ein Problem damit. FTP und SSH habe ich da nie gebraucht und was Grunt ist weiss ich nicht.
Kommentar
-
Zuletzt geändert von hellbringer; 16.05.2018, 14:33.Zitat von derwunner Beitrag anzeigenDann arbeitest du anscheinend nicht an wirklichen Web Projekten. Selbst wenn man komplett lokal entwickelt, gab es bisher bei mir nicht einen Fall, wo man nicht mal FTP oder SSH gebraucht hätte.
Kommentar
-
Zitat von hellbringer Beitrag anzeigen
Ich hab das Deployment allerdings noch nie in der IDE gemacht, sondern immer direkt auf der Shell. Somit ist es mir egal, ob die IDE FTP, SSH, uns was weiß ich alles kann.
Kommentar
-
Zitat von derwunner Beitrag anzeigenEs ging mir dabei mehr ums Testen im Live System.
Zitat von derwunner Beitrag anzeigenGibt ja hin und wieder Fehler, die man im Dev System nicht nachvollziehen kann.
Zitat von derwunner Beitrag anzeigenOder irgendwelche speziellen Anforderungen, bei den man nur direkt auf dem Live Server arbeiten kann.
Kommentar
-
Zitat von derwunner Beitrag anzeigenDann arbeitest du anscheinend nicht an wirklichen Web Projekten.
Zitat von derwunner Beitrag anzeigenSelbst wenn man komplett lokal entwickelt, gab es bisher bei mir nicht einen Fall, wo man nicht mal FTP oder SSH gebraucht hätte.
Zitat von derwunner Beitrag anzeigenGrunt ist ein NodeJS Task Runner, ähnlich Webpack, nur die Oldschool Variante. Die junge Generation benutzt halt Wepback (und Gulp) und die etablierte eher Grunt. Siehe www.gruntjs.com
Zitat von derwunner Beitrag anzeigenEs ging mir dabei mehr ums Testen im Live System. Gibt ja hin und wieder Fehler, die man im Dev System nicht nachvollziehen kann. Oder irgendwelche speziellen Anforderungen, bei den man nur direkt auf dem Live Server arbeiten kann.[SIZE="1"]Atwood's Law: any application that can be written in JavaScript, will eventually be written in JavaScript.[/SIZE]
Kommentar
-
Zitat von lottikarotti Beitrag anzeigenDas hat nichts mit den Generationen zu tun, sondern mit der stetigen Weiterentwicklung der Prozesse / Workflows im Frontend-Bereich. Webpack ist kein Grunt (oder Gulp) in blau sondern drei Level weiter.
Kommentar
-
Zitat von derwunner Beitrag anzeigenDoch, finde ich schon. Webpack hat nichts, was man nicht mit Grunt + SystemJS (oder sonst irgendeinem Loader) hinbekommen würde.[SIZE="1"]Atwood's Law: any application that can be written in JavaScript, will eventually be written in JavaScript.[/SIZE]
Kommentar
-
Zitat von derwunner Beitrag anzeigenEs ging mir dabei mehr ums Testen im Live System. Gibt ja hin und wieder Fehler, die man im Dev System nicht nachvollziehen kann. Oder irgendwelche speziellen Anforderungen, bei den man nur direkt auf dem Live Server arbeiten kann.
Kommentar
-
Zitat von rkr Beitrag anzeigenHast du mir da mal ein Beispiel? Ich kann dem so nicht zustimmen. Wenn deine Tests in einem Livesystem andere Ergebnisse bringen (wenn auch nur potentiell) als in deiner Dev-Umgebung, dann sind deine Testfälle kaputt. Es ist ja gerade der Witz am (automatisiertem) Testen, dass man vor dem Deployment weiß, dass der Code funktioniert. Wenn es in einer Live-Umgebung dann zu Problemen kommt, die in der lokalen Testumgebung nicht aufgefallen sind, dann muss man die lokalen Tests eben um diese speziellen Szenarien erweitern.
Kommentar
-
Zitat von derwunner Beitrag anzeigenNaja, funktionierender Code und das was der User draus macht sind immer noch zweierlei verschiedene paar Schuhe. Bestes Beispiel Shopware: Durch irgendeinen Aritkelimport hat man verwaiste Artikel. Artikel und dessen Varianten setzen sich ja in Shopware immer über 2 Tabellen zusammen. Blöd nur, wenn der Fremdschlüssel auf etwas verweist, was es nicht gibt oder doppelt gibt. So, da niemand Artikel im Testsystem importiert kann man faktisch das nur live erleben und den Fehler in der DB beheben, sprich den Schlüssel umbiegen.[SIZE="1"]Atwood's Law: any application that can be written in JavaScript, will eventually be written in JavaScript.[/SIZE]
Kommentar
-
Zitat von derwunner Beitrag anzeigenBestes Beispiel Shopware: Durch irgendeinen Aritkelimport hat man verwaiste Artikel. Artikel und dessen Varianten setzen sich ja in Shopware immer über 2 Tabellen zusammen. Blöd nur, wenn der Fremdschlüssel auf etwas verweist, was es nicht gibt oder doppelt gibt. So, da niemand Artikel im Testsystem importiert kann man faktisch das nur live erleben und den Fehler in der DB beheben, sprich den Schlüssel umbiegen.
Grundregel bei TDD lautet: Wenn etwas nicht (automatisiert) getestet wird, dann muss man annehmen, dass es kaputt ist.
Kommentar
-
Naja, das ist immer so eine Sache. Klar haben Sie es mit Unit Tests getestet. Aber es schließt einfach beim Import nicht jeden Unfug aus, den man in einer CSV Datei machen kann. Ob man da was mit einem Bug Report oder ähnlichem erreichen wird, ist fraglich. Schließlich ist es openSource und man kann sich jederzeit mit dem "es gibt ja keine Garantie darauf, dass es funktioniert" herausreden.
Die Rede ist von diesem Shopware Import / Export Plugin. Das hat schon für einigen Frust gesorgt...
Einen wirklichen Rollback oder sowas gibt es da nicht. Das wird Zeile für Zeile verarbeitet und in der Datenbank überschrieben. Einzige Möglichkeit zum Rollback ist ein Backup wieder einspielen, wenn man vorher eins gemacht hat. Außerdem löscht es auch keine Artikel, die nicht im Import vorhanden sind, jedoch in der DB vorhanden sind. Es ändert nur und fügt neue Artikel(varianten) hinzu.
Link zum Plugin: https://store.shopware.com/swagef36a...rt/export.html
Kommentar
-
Zitat von derwunner Beitrag anzeigenSchließlich ist es openSource und man kann sich jederzeit mit dem "es gibt ja keine Garantie darauf, dass es funktioniert" herausreden.
Kommentar
-
Zitat von rkr Beitrag anzeigenShopware hat aber ein Interesse daran, dass ihre Komponenten funktionieren. Und, ob du es glaubst oder nicht: Viele Firmen stellen deswegen ihre Software als OSS ins Github, weil sie Feedback von Nutzern erwarten.
Allein das zeigt mir schon, dass sie nicht so das große Interesse an openSource haben.
Ein weiterer Fact: Plugins, die im Store angeboten werden, die angeblich openSource sein sollen, finden keine Möglichkeit zu einer Verlinkung zum Repo auf GitHub oder Sourceforge.
Kommentar
Kommentar