MartinGrupinski

Ich melde mich auch mal zu Wort, da ich momentan in so einer Umschulung (allerdings zum AEler) bin.. Bei mir an der Schule ist Eigeninitiative das A und O. Die Dozenten sind weder motiviert, noch informiert und ich bin mir sicher, dass ein Großteil der Schüler (die im übrigen alle mit ner internen 1,x abschließen werden, weil die Klausuren lächerlich sind und meistens noch nichtmal beaufsichtigt werden) nach seiner Probezeit im Betrieb nicht übernommen wird. Die Programmierkenntnisse, die ich mitgenommen habe, waren die ersten geschätzten 12 Seiten eines 1000-Seiten-Java Buches (wortwörtlich war die switch-Anweisung das höchste der Gefühle, die uns auch noch ohne breaks beigebracht wurde, weswegen ich in einen Disput mit dem Dozenten einsteigen musste...) Das heißt, wenn du die falsche Schule erwischst, bleibst ALLES an dir hängen. Ich persönlich hatte das Glück, schon etwas Vorwissen aus ein paar Semestern an der Uni mitgenommen zu haben.. aber wir haben immernoch Systemintegratoren (jetzt kurz vor der Prüfung), die morgens statt des Zeittrackingprogramms selbst, die Installationsdatei starten, weil da am Ende das Häkchen "nach Installation starten" angewählt ist und das Programm folglich startet. Echtes Wissen nimmst du erst im Praktikum mit und da kann es dich schonmal überfordern, wenn du von den absolutesten Grundlagen Java in ein PHP-System mit Frontend-Verarbeitung, Datenbankanbindung und was weiß ich noch alles geschubst wirst - oder gar noch schlimmer, wenn du das nicht im Praktikum, sondern erst beim ersten Job erlebst.. Dass bei solch desolaten Schulen der Ruf des Umschülers generell in den Schmutz gezogen wird, ist kein Wunder. Dass die Chance, nach der Umschulung übernommen zu werden, darunter leidet, auch nicht. Ich denke aber, Qualität wird sich immer durchsetzen. Wenn du kannst, worauf du dich bewirbst, ist der Werdegang fast egal - dann muss die Bewerbung halt aussagekräftig genug sein. Gesucht wird auf jeden Fall genug.

Sind die Unterschiede tatsächlich so signifikant, dass es sicher am Aufgabenfeld/der Bezahlung liegt? Vielleicht liegts gar nicht am Job selbst, sondern am Umfeld? Ich hab die Aussage "Das Unternehmen ist nicht Münchner Umland" nicht ganz verstanden.. heißt es, ihr seid mitten in München oder ganz wo anders? Aber bei beidem könnte man ähnlich argumentieren: München selbst ist extrem teuer, da bewerb ich mich lieber im Ruhrgebiet, weil ich bei gleichem Lohn am Ende mehr übrig behalte. Bei nem Unternehmen in der Knüste fehlt vielleicht die Nähe zu ner größeren Stadt oder einfach das Leben selbst im Umfeld.

Oha.. das kann weg. Der Server war überhaupt nicht am laufen, da es ne Fehlermeldung gab, weil die $_SERVER-Variable nicht gesetzt war, weils halt als Daemon gestartet wurde.. was ich also gesehen hab, war, wie JavaScript Spass mit der HTML hatte und den Server "simulierte". Wie ich die Fehlermeldung übersehen konnte, ist mir ein Rätsel. Ich entschuldige mich fürs Vergeuden eurer Zeit und bitte einen Admin darum, das möglichst schnell zu löschen, da ich nicht denke, dass dieser Faux-Pas irgendwem anders helfen kann. Vielen Dank trotzdem Grüße, Martin

Das ist natürlich auch ein ganz guter Ansatz. Wär ich so auch nicht drauf gekommen.

Hallo zusammen, ich versuche gerade einen Websocket-Server aufzusetzen und ne Art kleinen Chat draus zu machen. Der Server selbst läuft mittlerweile, doch wenn ich mich mit zwei verschiedenen Browsern anmelde, sind die Browser nicht wie erwartet am selben Server angemeldet, bzw bekommt zumindest der eine Browser nicht die erwartete Nachricht vom anderen Browser. Ich finde meinen Fehler schon den ganzen Tag nicht, vielleicht hat ja jemand Lust mal drüberzuschauen und mir ggfs etwas Zeit zu sparen: WSS.php: (Die Datei, die als Deamonscript per Shell gestartet wurde) <?php require_once ($_SERVER['DOCUMENT_ROOT'] ."/Websockets/so/abstractwebsocketserver.php"); class WebSocketServer extends AbstractWebSocketServer { protected function process($user, $message) { $this->sendToAllConnectedUsers($message); } protected function connected($user) { // Do nothing: This is just an echo server, there's no need to track the user. // However, if we did care about the users, we would probably have a cookie to // parse at this step, would be looking them up in permanent storage, etc. } protected function closed($user) { // Do nothing: This is where cleanup would go, in case the user had any sort of // open files or other objects associated with them. This runs after the socket // has been closed, so there is no need to clean up the socket itself here. } } $server = new WebSocketServer("127.0.0.1", 11111); try { $server->run(); } catch (\Exception $e) { $server->stdout($e->getMessage()); } Ich denke, hier in der connected-Methode wird der Hinweis für mich sein - doch für alle Chatversionen, die ich finde, wurden keine Cookies verwendet - ich dachte, hier sollte vielleicht der user in den users-Array eingefügt werden, doch das geschieht schon in der connect-Methode der abstrakten Klasse. Den AbstractWebSocketServer habe ich von ghedipunk übernommen, zu AbstractWebSocketServer umbenannt und um die folgende Funktion erweitert: protected function sendToAllConnectedUsers($msg) { foreach($this->users as $user) { send($user, $msg); } } Die client.html: <html> <head> <title>WebSocket</title> <style type="text/css"> html, body { font: normal 0.9em arial, helvetica; } #log { width: 600px; height: 300px; border: 1px solid #7F9DB9; overflow: auto; } #msg { width: 400px; } </style> <script src="client.js" type="text/javascript"></script> </head> <body onload="init()"> <h3>WebSocket v2.00</h3> <div id="log"></div> <input id="username" type="text" /> <input id="msg" type="text" onkeypress="onkey(event)" /> <button onclick="send()">Send</button> <button onclick="quit()">Quit</button> <button onclick="reconnect()">Reconnect</button> </body> </html> und die client.js: var socket; function init() { var host = "ws://127.0.0.1:11111/WSS.php"; try { socket = new WebSocket(host); log('WebSocket - status ' + socket.readyState); socket.onopen = function(msg) { log("Welcome - status " + this.readyState); }; socket.onmessage = function(msg) { log("Empfangen: " + msg.data); }; socket.onclose = function(msg) { log("Disconnected - status " + this.readyState); }; } catch (ex) { log(ex); } $("msg").focus(); } function send() { var txt, msg, name; name = $("username").value; txt = $("msg"); msg = txt.value; if (!msg) { alert("Gib ne Nachricht ein."); return; } txt.value = ""; txt.focus(); try { socket.send(name + ": " +msg); log('Gesendet: ' + msg); } catch (ex) { log(ex); } } function quit() { if (socket != null) { log("Goodbye!"); socket.close(); socket = null; } } function reconnect() { quit(); init(); } // Utilities function $(id) { return document.getElementById(id); } function log(msg) { $("log").innerHTML += "<br>" + msg; } function onkey(event) { if (event.keyCode == 13) { send(); } } Wenn ich mich jetzt mit zwei verschiedenen Browsern auf die index.php begebe (die nur die client.html includet), sendet (und empfängt) der WebsocketServer nur im eigenen Browser, nicht im anderen. Was habe ich übersehen? Ich wälz das schon nen ganzen Moment und alle google-Suche führt nicht zum gewünschten Ergebnis. Es wird wohl was ganz dummes sein müssen, also seid bitte gnädig Danke im Voraus und lieben Gruß, Martin

Ich finds jetzt leider nicht mehr, wo ich bei JS drübergestolpert bin, kann aber gut sein, dass das, wie Whiz erwähnt hat, bei JS nur einmalig von nem Anfänger ohne Sinn übernommen wurde. Falls ichs nochmal finden sollte, werd ichs auf jeden Fall nochmal posten. Aber dass es da tatsächlich ne Begründung für PHP gibt, find ich grade wirklich faszinierend. Ich muss mir den Code vom Zend mal anschauen. Ich kanns mir grade nicht erklären, wie man programmieren müsste, damit es solch eine Einschränkung gibt. Aber vielen Dank schonmal für eure Zeit, die Frage beschäftigte mich jetzt schon ein paar Tage

Sowohl in PHP ist mir das untergekommen, als auch in JavaScript.. Hier zB in php.

Hallo zusammen, bisher habe ich keinerlei befriedigende Antwort darauf gefunden, wieso ich immer wieder über die Codezeile stolpere: var null = NULL; Wieso sollte man so etwas tun? Hat das irgendeinen verborgenen Sinn oder ist das nur darauf zurückzuführen, dass man gern alles, was man häufiger benutzt in Variablen verpackt? Oder spart man sich durch die Zeile lediglich den Druck auf die Shift-Taste? Vielen Dank schonmal, Martin

Um es wirklich zu lernen, würd ich dir empfehlen, ein Buch zwar für die Grundlagen zu nehmen, dass du überhaupt mal einen Einstieg bekommst, dir dann aber eigene Projekte auszudenken und es anhand derer zu lernen. Es ist ein riesiger Unterschied ob du in nem Buch gesagt bekommst, was du tun sollst und es dann abschreibst, oder ob du selber vor ein Problem gestellt wirst und es dann "selbstständig" (also mit viel gegoogle, Videotutorials, usw) löst. Ich persönlich bin aus Büchern nie schlau geworden, weil die Projekte darin zu abstrakt sind und einfach der Nutzen fehlt. Mein Lernprojekt war zB ein selbstgeschriebener Kalender, aber dafür braucht man halt erstmal die Grundlagen aus dem Buch... Viel Erfolg!

Hm, gute Frage, was ich damit eigentlich darstellen möchte. Im Endeffekt möchte ich halt irgendeine Darstellung des Projektes für die Projektdokumentation erstellen. Einen wirklichen Rahmen hat man da ja nicht vorgegeben - man braucht nur irgendwas "greifbares" für den Punkt "Planung". Ich habe sowas aber bisher nie machen müssen und bin jetzt etwas überfordert, was genau ich dafür am besten benutze. Selbst mit dem konkreten Hinweis, eher ein Sequenzdiagramm zu erstellen, kann ich viel zu wenig anfangen. Auf jeden Fall schonmal vielen Dank für den Tipp, dann les ich mich mal in die Sequenzdiagramme ein.

Och, da reih ich mich doch gerne ein. Falls jemand noch Prüfungsunterlagen für AEler rumliegen hat und sich die Mühe machen würde, würd ich auch nicht Nein sagen martingrupinski@gmail.com Vielen Dank schonmal, Martin

Wieso? Ich dachte jetzt eher an sowas: private static Connection con; public static void main(String[] args) { Main.con = ..bla } public static Connection getConnection() { return Main.con; } Dass du beim Testen nicht auf die echte Datenbank zugreifen solltest, sollte klar sein - aber ich wüsst nicht, was die "Dependency Injection" da dran ändern würde?

Ich versteh deinen Punkt nicht so ganz, muss ich gestehen. Natürlich ist es "richtiger", solche Dinge per Konstruktoren durchzureichen, doch auch bei statischen Methoden werden Fehler ganz normal im Stacktrace zurückgegeben. Wieso sollte das dadurch schwerer zu testen sein? Oder interpretier ich die Begriffe "Unittest" und "Dependency Injection" einfach falsch?

Schau auch mal deine Rückgaben durch.. zB willst du ein Statement zurückgeben (wofür eigentlich? Mach ne void draus..) , gibst aber immer null zurück. Auch wird in der connect-Methode der Fall, dass eine Exception geworfen wird, nicht auf die flag-Variable übertragen; connected wird da immer true sein. Das log-Level da plump als Warning anzugeben ist auch eher ungeschickt. Müsstest eigentlich von der Exception selbst den Log-Level beziehen können (da bin ich grad aber unsicher). Die ExistingName-Methode musst du dir auch nochmal anschauen, die macht überhaupt keinen Sinn. Erst packst du den Namen in die Liste, dann gehst du diese Liste in der Schleife durch und für jeden Namen, der nicht der eingegebene ist, fügst du einen neuen Datensatz in die Tabelle. Heißt, bei 10 Personen, 9 neue Einträge mit der neuen Person in der Datenbank. Beim nächsten Eintrag wärens schon 19 zusätzliche usw. Ich würd mir die ganze Connection statisch in die Main-Klasse packen, so dass du dann von egal woher über Main.getConnection() drankommen kannst. So musst du nicht verschiedene Connections erstellen und wirst zumindest in diesem Zusammenhang keine NullPointer mehr sehen. ..und ich muss Goulasz rechtgeben: Ein Insert und ein Update sind zwei grundlegend verschiedene Dinge, auch wenn das Statement als solches diese nicht unterscheidet. Deine Update-Methode sollte also Insert heißen, bei Updates gehts um Veränderungen von bestehenden Datensätzen, nicht um neue Einträge.

Leider kann ich nicht editieren.. hab nochmal drüber geschaut und bin jetzt eher bei der Version: Die LDAP-Informationen kommen erst später im Kontext des Frameworks, deshalb denk ich, dass sie für die API irrelevant sind. Und jede Mitteilung muss 2 User kennen, den Sender und Empfänger..