Ankündigung

Einklappen
Keine Ankündigung bisher.

User helfen User - Programmieren

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

    Jemand eine Ahnung wie man einen Test in Django schreibt der mein SSL Certifikat auf gültigkeit überprüft?

    Kommentar


      schau mal hier rein: https://docs.djangoproject.com/en/2.0/topics/testing/tools/

      Kommentar


        Zitat von BennyQ
        yo nevermind. bin duhm. regEx mit einfachem \ hat geklappt. nur im if clause || anstatt && gemacht -.-
        RegEx beste Leben. Kannst so geilen Scheiß damit machen. Liebe das Zeug.

        Kommentar


          Naja, RegEx driften schnell in die Programmiermystik ab. Kaum wartbar, kaum nachvollziehbar. Benutze auch auch, aber bei "geilem Scheiß" is ein bisschen mehr Code und ein bisschen weniger RegEx-Magie meist sinnvoller imo.

          Kommentar


            Zitat von OrdentlichUndFromm
            Naja, RegEx driften schnell in die Programmiermystik ab. Kaum wartbar, kaum nachvollziehbar. Benutze auch auch, aber bei "geilem Scheiß" is ein bisschen mehr Code und ein bisschen weniger RegEx-Magie meist sinnvoller imo.
            rautiere.

            Kommentar


              Habe auch mal 'ne Frage zu Spring:
              Gibt es einen Grund, @Component und so zu benutzen? Habe das 'ne Zeitlang immer gemacht, weil das in Tutorials der Standard way-to-go war. Aber Beans (die alles, was sie brauchen, über den Konstruktor erhalten) inner Java Configuration zu definieren scheint mir nur Vorteile zu haben:
              - Die Beans sind von Spring entkoppelt
              - Die Instantiierungs-Strategie der Beans ist übersichtlich in einer Configuration definiert
              - Unittests funktionieren, ohne dass plötzlich ein ApplicationContext hochgefahren werden muss
              - Mockito entfällt, weil man auch einfach ad-hoc-Mocks für Beans schreiben kann (als anyome Implementierungen)

              Habe mal ein paar umfangreichere Programme auf Beans umgestellt und das Gefühl, das erste Mal wieder Kontrolle über den Programmablauf zu bekommen. Warum dieser @Component-Weg?

              Kommentar


                Zitat von OrdentlichUndFromm
                Habe auch mal 'ne Frage zu Spring:
                Gibt es einen Grund, @Component und so zu benutzen? Habe das 'ne Zeitlang immer gemacht, weil das in Tutorials der Standard way-to-go war. Aber Beans (die alles, was sie brauchen, über den Konstruktor erhalten) inner Java Configuration zu definieren scheint mir nur Vorteile zu haben:
                - Die Beans sind von Spring entkoppelt
                - Die Instantiierungs-Strategie der Beans ist übersichtlich in einer Configuration definiert
                - Unittests funktionieren, ohne dass plötzlich ein ApplicationContext hochgefahren werden muss
                - Mockito entfällt, weil man auch einfach ad-hoc-Mocks für Beans schreiben kann (als anyome Implementierungen)

                Habe mal ein paar umfangreichere Programme auf Beans umgestellt und das Gefühl, das erste Mal wieder Kontrolle über den Programmablauf zu bekommen. Warum dieser @Component-Weg?
                Hast du den Annotation basierten Ansatz praktisch durch ein POJO mit Xml-Config ersetzt? Finde den Annotation-Ansatz mit Component-Scanning einfacher und schneller. Solange Spring weiß, welche Klassen für DI gebraucht werden, macht es soweit ich weiß keinen Unterschied.

                Kommentar


                  Naja, keine xml-Config, sondern eine JavaConfiguration (sprich eine Klasse mit @Configuration-Annotation), die dann mit @Bean die Beans definiert (so dass diese nichtmehr über @Compnent zusammengesucht werden müssen):

                  @Configuration
                  public class MyAppConfig{

                  @Bean
                  public MyBean1 getMyBean1(){
                  return new MyBean1Impl();
                  }

                  @Bean
                  public MyBean2 getMyBean(MyBean1 bean1){
                  return new MyBean2Impl(bean1);
                  }

                  }

                  Spring wird die Beans hier korrekt verdrahten und, so nicht anders angegeben, als quasi-Singletons bereitstellen.
                  Das bringt mir all die Vorteile, die ich oben beschrieben haben: Übersichtlichkeit, klare Instantiierungs-Strategie, kein Autowiring in der Bean, die sich deshalb auch easypeasy ohne Mockito oder ApplicationContext testen lässt. Und ich sehe keine Nachteile, darum frage ich mich, warum das nicht sonderlich populär ist.

                  Kommentar


                    Weil das einfach mega unübersichtlich ist. Die große Stärke von Spring ist ja, die Beans bzw. Components per Classpath Scan automatisch zu ziehen. Daher ist die XML Konfiguration bei großen Anwendungen schon sinnvoll. Du musst auch nicht immer unbedingt den ApplicationContext mocken sondern kannst auch einfach mit der @InjectMocks Annotation arbeiten. Ist das ein Spring Boot Projekt? Oder klassisch Spring MVC?

                    Grundsätzlich geht man ja eher so vor: Du hast gewisse Spring Components, die ein Interface implementieren. Die Annotation ist an deiner Implementierung, dann kannst du später in einer anderen Component die außerhalb des Scopes liegt mit @Inject das Interface per DI anziehen. Dazu muss die Komponente in der du gerade bist keine direkte Abhängigkeit zu deiner Implementierung haben.

                    Kommentar


                      Ich bin gerade dabei ein Programm für meine Bachelorarbeit zu schreiben. Entweder bin ich einfach zu schlecht im programmieren oder das erstellen von Sudoku ist nicht so einfach wie ich gedacht habe.

                      Ich habe zwar einen funktionierenden Algorithmus der ist aber unbrauchbar, den sobald ihn auf Sudoku-Varianten erweiter funktioniert er nicht.

                      Kann mir jemand einen Denkanstoß geben ? Meine letzte Idee war ein treshold accepting algorithmus der aber auch nicht das gewünschte ergebniss bringt.

                      Kommentar


                        Was genau willst du machen?

                        Ein Sudoku Spiel programmieren? Oder eines Lösen? Zum Lösen würde ich mir mal SAT-Solver anschauen

                        Aber allgemein fehlen hier Infos um dir helfen zu können

                        Kommentar


                          Moin,
                          wir haben mehrere Hundert Linux-Geräte, auf diesen läuft eine Node.js Anwendung sowie eine eigene Chrome-Extension.
                          Jetzt brauchen wir die Möglichkeit, beides zu updaten.
                          Also der Nutzer soll dich Möglichkeit haben, automatische Updates zu aktivieren oder zu deaktivieren. Wenn nicht aktiv, soll nach Neustart bzw. zu einer festen Zeit nach Updates geprüft werden und bei Bestätigung das Update geladen werden.
                          Bei den automatischen Updates sollen auch nicht alle gleichzeitig geupdated werden, soll beispielsweise erstmal nur 100, und wenn die fertig sind, die nächsten 100.
                          Gibts für sowas irgendein Tool, was behilflich sein könnte?

                          Kommentar


                            Zitat von tob1
                            Weil das einfach mega unübersichtlich ist. Die große Stärke von Spring ist ja, die Beans bzw. Components per Classpath Scan automatisch zu ziehen. Daher ist die XML Konfiguration bei großen Anwendungen schon sinnvoll. Du musst auch nicht immer unbedingt den ApplicationContext mocken sondern kannst auch einfach mit der @InjectMocks Annotation arbeiten. Ist das ein Spring Boot Projekt? Oder klassisch Spring MVC?
                            Spring Boot. Warum findest du das unübersichtlich? Ich sehe sogar über die Call Hierarchy, welche Implemententierung verwendet werden (im Unterschied zu XML), und ich könnte die Spring Configuration Class, ähnlich wie die xml, auf in mehrere Config-Klassen aufteilen. Und ich würde denken, das ist übersichtlicher, als über Qualifier, Annotationen(@Component, @Primary etc.) und Profile herauszufinden, welche Implementierung jetzt tatsächlich verwendet wird. Ein Blick in die Config genügt!
                            Zu @InjectMocks: Das ist auf jeden Fall deutlich langsamer und wie ich finde auch deutlich weniger nachvollziehbar, als wenn ich den Mock einfach via "InterfaceA = new ClassA(){ public int method(String arg) {return 0;}};" erzeuge und im Bean-Constructor übergebe (falls ich eine vorhande Implementierung ClassA ähnlich dem @Spy kastrieren will, sonst kann ich natürlich auch einfach eine anonyme innere Classe von dem Interface erzeugen).
                            Ich bekomme mit @InjectMock ja nicht mal mit, wenn das scheitert! Und sinnvoll debuggen lässt der Test auch schwerer, weil man sich schnell in der Stackhölle des Mockito-Vodoos verliert.

                            Grundsätzlich geht man ja eher so vor: Du hast gewisse Spring Components, die ein Interface implementieren. Die Annotation ist an deiner Implementierung, dann kannst du später in einer anderen Component die außerhalb des Scopes liegt mit @Inject das Interface per DI anziehen. Dazu muss die Komponente in der du gerade bist keine direkte Abhängigkeit zu deiner Implementierung haben.
                            In diesem Fall sind die Components von Spring abhängig. Wenn ich einfach Beans erzeuge, haben sie erst einmal keine Spring-Abhängigkeit. Diese kommt erst in dem Projekt hinzu, das eine Spring Configuration Class hält und die Bean-Factories definiert.
                            Was meinst du mit "Dazu muss die Komponente in der du gerade bist keine direkte Abhängigkeit zu deiner Implementierung haben."? DI findet in meinem Fall ja auch statt. Oder kritisierst du, dass die Spring Configuration Class eine Abhängigkeit zur Implementierung hat?

                            Kommentar


                              Moin,

                              bin noch nicht so wirklich fit in C++ , habe aber gerade ein Problem. Ich habe zwei Klassen Mutter und Tochter. Die Tochter-Klasse ist ein Member der Mutterklasse.

                              class Mutter {

                              public:
                              int doSomething();
                              int doSomething2();

                              private:
                              Tochter tochter_;
                              }

                              class Tochter {
                              public:
                              int doSomethingElse();
                              void doSomethingElse2();
                              }

                              Jetzt möchte ich, dass die Funktion doSomethingElse() der Tochterklasse in tochter_ irgendeine allgemeine Funktion benutzen kann, in diesem Falle die doSomething() Funktion der Mutter-Instanz und mit dem Rückgabewert davon irgendwas anstellt. Mein Problem dabei ist jetzt, wie reserviere ich in der tochter_ Klasse einen Platz für eine nicht weiter definierte Funktion und sage dann, dass beim Aufrufen dieser Funktion doch bitte auf die Mutter-doSomething() zugegriffen werden soll?

                              Ich möchte also einen Pointer auf die doSomething() der Mutter an die tochter_ Klasse übergeben und diese dort benutzen.
                              Aber irgendwie bin ich ehrlicherweise zu dumm dafür und verzettel mich da, bin auch einfach noch zu ungeübt mit der Syntax. Habe schon quer gegoogled, aber das hat mich irgendwie noch etwas weiter verwirrt, daher jetzt hier die Nachfrage, vll kann mir ja jemand helfen.

                              Kommentar


                                Wenn die Tochter-klasse von der Mutter-Klasse erbt, dann sind alle public funktionen der Mutterklasse in der Tochterklasse verfügbar.

                                /edit: wenn du da keine vererbung möchtest schilder nochmal deine aufgabe, weil vllt wäre vererbung hier auch sinnvoll. ansonsten übergibst du bei der Tocherfunktion als parameter eine instanz der mutterklasse und callst die funktion dann dort.

                                Kommentar

                                Lädt...
                                X