Ankündigung

Einklappen
Keine Ankündigung bisher.

Debuggen mit Eclipse, Ausgabe nicht teilweise bis breakpoint

Einklappen

Neue Werbung 2019

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • #16
    MOD: Verschoben von PHP-Einsteiger
    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

    Kommentar


    • #17
      Zitat von MrChangelog Beitrag anzeigen
      Also 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.
      Dann 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. Grunt 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

      Kommentar


      • #18
        Zitat von derwunner Beitrag anzeigen
        Dann 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.
        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, und was weiß ich alles kann.

        Kommentar


        • #19
          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.
          Es 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


          • #20
            Zitat von derwunner Beitrag anzeigen
            Es ging mir dabei mehr ums Testen im Live System.
            Im Live-System wird nicht getestet.

            Zitat von derwunner Beitrag anzeigen
            Gibt ja hin und wieder Fehler, die man im Dev System nicht nachvollziehen kann.
            Dann betreibt man Debugging. Also man kopiert den Datenstand vom Live-System ins Test-System und testet dort ordentlich.

            Zitat von derwunner Beitrag anzeigen
            Oder irgendwelche speziellen Anforderungen, bei den man nur direkt auf dem Live Server arbeiten kann.
            Dann sind die Anforderungen Müll und sollten überdacht werden.

            Kommentar


            • #21
              Zitat von derwunner Beitrag anzeigen
              Dann arbeitest du anscheinend nicht an wirklichen Web Projekten.
              Was sind denn "wirkliche" Web-Projekte?

              Zitat von derwunner Beitrag anzeigen
              Selbst wenn man komplett lokal entwickelt, gab es bisher bei mir nicht einen Fall, wo man nicht mal FTP oder SSH gebraucht hätte.
              Bei uns nutzen wir FTP / SSH nur für "administrative" Zwecke (bspw. um Deployment-Prozesse einzurichten). Das Deployment selbst läuft voll-automatisiert; da wird manuell weder mit SSH noch mit FTP gefummelt.

              Zitat von derwunner Beitrag anzeigen
              Grunt 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
              Das 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.

              Zitat von derwunner Beitrag anzeigen
              Es 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.
              Hier muss ich hellbringer beipflichten: don't!
              [SIZE="1"]Atwood's Law: any application that can be written in JavaScript, will eventually be written in JavaScript.[/SIZE]

              Kommentar


              • #22
                Zitat von lottikarotti Beitrag anzeigen
                Das 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.
                Doch, finde ich schon. Webpack hat nichts, was man nicht mit Grunt + SystemJS (oder sonst irgendeinem Loader) hinbekommen würde.

                Kommentar


                • #23
                  Zitat von derwunner Beitrag anzeigen
                  Doch, finde ich schon. Webpack hat nichts, was man nicht mit Grunt + SystemJS (oder sonst irgendeinem Loader) hinbekommen würde.
                  Das hat niemand bestritten.
                  [SIZE="1"]Atwood's Law: any application that can be written in JavaScript, will eventually be written in JavaScript.[/SIZE]

                  Kommentar


                  • #24
                    Zitat von derwunner Beitrag anzeigen
                    Es 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.
                    Hast 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


                    • #25
                      Zitat von rkr Beitrag anzeigen
                      Hast 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.
                      Naja, 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.

                      Kommentar


                      • #26
                        Zitat von derwunner Beitrag anzeigen
                        Naja, 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.
                        Wenn das meine Codebase wäre dann würde ich daraus schließen, dass die Importfunktion einen groben Fehler hat und das DB-Design ggf. angepasst werden sollte. Der Fehler selbst lässt sich zu Testzwecken problemlos auf einem Testsystem reproduzieren. Die Bereinigung der Daten muss natürlich auf dem Produktivsystem erfolgen, aber nur wenn sichergestellt ist, dass die gewählte Methode keine Kollateralschäden verursacht. Im Idealfall lässt sich so ein Import einfach rückgängig machen ("rollback"). Das ist unterm Strich aber schon ein recht grober Schnitzer.
                        [SIZE="1"]Atwood's Law: any application that can be written in JavaScript, will eventually be written in JavaScript.[/SIZE]

                        Kommentar


                        • #27
                          Zitat von derwunner Beitrag anzeigen
                          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.
                          Ich sehe das ähnlich wie lottikarotti, denn das ist eigentlich ein Szenario, dass man spätestens bei einem Integrationstest prüfen sollte. Wenn das kaputte Standard-Funktionalität von Shopware ist, dann mach bei denen ein Ticket auf und beschreibe das Problem...

                          Grundregel bei TDD lautet: Wenn etwas nicht (automatisiert) getestet wird, dann muss man annehmen, dass es kaputt ist.

                          Kommentar


                          • #28
                            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


                            • #29
                              Zitat von derwunner Beitrag anzeigen
                              Schließlich ist es openSource und man kann sich jederzeit mit dem "es gibt ja keine Garantie darauf, dass es funktioniert" herausreden.
                              Shopware 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.

                              Kommentar


                              • #30
                                Zitat von rkr Beitrag anzeigen
                                Shopware 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.
                                Shopware hat es als openSource angeboten, damit sie beliebter werden. Nicht vorrangig, dass man den Community Input bekommt. Es gibt ja auch eine Premium Version davon, die man kaufen muss. Außerdem findest du auf GitHub nicht die fertigen Versionsbuilds. Die Builds gibts nur als Download auf der Herstellerseite. Bei GitHub findet man sozusagen nur die Entwicklerversion. Shopware bildet einen Hash über die PHP Dateien und ermittelt so die aktuell laufende Version. Dieser Job wird von einem Ant Build Task erledigt. Diesen führen sie jedoch nur Haus intern aus und erstellen daraus das ZIP.
                                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

                                Lädt...
                                X