perdian

Ja, wenn du nicht unbedingt auf den SUN Client angewiesen bist: Wechsel das FTP Package. Die sun.* Klassen können sich jederzeit ändern und/oder aus dem JDK komplett verschwinden. Sicherer und nebenbei auch noch deutlich komfortabler ist ein "richtiges" FTP Client Package, wie z.B. Jakarta Commons NET http://jakarta.apache.org/commons/net/ oder direkt noch eine Abstraktionsstufe höher: Jakarta Commons VFS http://jakarta.apache.org/commons/vfs/

Nein, kannst du nicht. So sieht's wohl aus Das sauberste ist das ganze - genauso wie man es in der objektorientierten Programmierung tun sollte - in eine eigene Klasse auslagerst, die in etwa so aussehen könnte: public class StateInfo { public int value = 0; public void increment() { this.value++; } public int valueAsInt() { return this.value; } public String valueAsString() { return Integer.toString(this.value); } }

Dann solltest du dringend deine Suchtechnik optimieren. Eine Google Suche nach "JBoss deploy directory" liefert: http://jboss.org/wiki/Wiki.jsp?page=ExplodedDeployment

Sowas sehe ich eigentlich nicht so extrem. Ich muss schon im groben wissen, bei was für einer Firma ich mich bewerbe, allerdings gehören da nicht alles Details zu (wie Mitarbeiteranzahl, Aussenstellen, etc.). Dafür ist ein (eventuelles) Bewerbungsgespräch da, in dem nicht nur die Firma etwas über mich, sondern auch ich etwas über die Firma erfahren. Zudem ist es mir noch nie passiert, dass mich jemand in einem Gespräch gefragt hat "Und jetzt erzählen Sie doch alles, was Sie über uns wissen".

Dann versuch eine andere Formulierung, wieso du unbedingt jetzt (doch) in den IT Bereich willst. Mach dir bewusst, dass du deinen Gegenüber davon überzeugen musst, dass gerade du der richtige für den Job bist. Und je mehr knallharte Fakten du dafür liefern kannst, umso besser für dich. a) Virtual Basic gibt es nicht. BASIC ist eine Programmiersprache - kein Programm. c) Mit BASIC kannst du heute niemanden mehr überzeugen, dich zu nehmen. Im Gegenteil: Es zeigt - für mich - immer, dass du nicht mehr auf dem aktuellen Stand bist. Visual Basic (gerade im .NET Umfeld) bildet da eine Ausnahme. Aber wenn ich nur BASIC lese, dann denke ich immer noch an einen C64. d) Du solltest dringend versuchen solche Punkte in deiner Bewerbung auf eine fachlich solide Grundlage zu stellen. Wenn du keine bzw. wenig Ahnung hast, worüber du schreibst (und das ist bei dem BASIC Part weiter oben definitiv der Fall) dann lass es lieber ganz raus. Die Chance sich damit komplett zu blamieren wäre mir viel zu groß.

Ist es das? Ich habe diese Funktionalität weder jemals selbst genutzt, noch kenne ich irgendjemand, der auf diese Art und Weise ein Programm installiert (hat).

Was willst du denn jetzt genau wissen?

Ne, ist klar...

Ich habe es bei mir damals mit in die Begrüßung/Einleitung integriert, als in etwa so: "Die Firma F wurde 1848 gegründet und beschäftigt momentan ca. 10 Mitarbeiter. Die Schwerpunkte der Arbeit liegen bei X und Y, woraus aus die Anforderung entstand Programm P zu entwickeln, dass durch meine Projektarbeit umgesetzt wurde".

Ich bin mit WinCvs nie wirklich gut klargekommen, irgendwie ist die Konfiguration jedes Mal wieder ein Glückspiel. Daher mein Tip: Auch wenn's vielleicht ein wenig überdimensioniert erscheint aber Eclipse hat eine hervorragende CVS Unterstützung, die ich nicht mehr missen möchte, vielleicht probierst du das mal aus.

Oder mein persönlicher Favorit: http://httpunit.sourceforge.net/

Schwierig Natürlich ist es auch wichtig draufloszuhacken und zu sehen, was rauskommt - aber eben nicht nur. Ich gebe dir recht, ein Erfolgserlebnis zu haben (und am Anfang auch ruhig nur ein kleines) ist enorm wichtig um nicht komplett die Motivation zu verlieren. Aber auch hier muss man aufpassen: Wenn man sich einmal angewöhnt hat alles von den Strukturen her recht flach und einfach zu halten, dann ist es später schwierig(er) sich daran zu gewöhnen diese lockere Art wieder aufzugeben und - gerade wenn die Projekte und Applikationen größer werden - einer wirklichen logischen Struktur zu folgen. Da gibt es keinen idealen Weg, wo man sagen könnte "bis hierhin hacken, ab hier planen, verstehen und dann weiterhacken". Ich denke trotzdem, dass es wichtig ist sich auch in einem frühen Stadium schon mit den Konzepten hinter der Technik auseinanderzusetzen - auch wenn das bedeutet am Anfang deutlich mehr Zeit und Arbeit in das Lernen zu investieren. Meine Lernkurve, wenn ich an eine neue Sprache oder eine neue Technolgie herangehe setze ich schon am Anfang sehr hoch an - bevor ich vor einiger Zeit auch nur eine Zeile in ADA programmiert habe bin ich sehr intensiv erstmal verschiedene Tutorials und Dokumentationen durchgegangen. Als ich dann wirklich mit dem Coden angefangen habe, wäre manch anderer vielleicht schon dabei gewesen die erste kleine Applikation zu vervollständigen. Ich möchte eben nicht nur programmieren sondern auch entwickeln. Und da gehört eben noch deutlich mehr dazu als nur ein paar Befehle aneinanderzureihen, die nach einigem ausprobieren irgendwann doch das richtige Ergebnis liefern. Eine flache Programmiertechnik ohne tief in die Sprache und die Bibliothek zu gehen mag auf den ersten Blick gut funktionieren und schnell Ergebnisse liefern, aber bei folgender Struktur sind Probleme was wartbarkeit und auch das Verständnis angeht eigentlich schon vorprogrammiert (im wahrsten Sinne des Wortes): if(e.getSource() == btZiff2) { tfAnzeige.setText(tfAnzeige.getText() + 2); } if(e.getSource() == btZiff3) { tfAnzeige.setText(tfAnzeige.getText() + 3); } if(e.getSource() == btZiff4) { tfAnzeige.setText(tfAnzeige.getText() + 4); } Einen guten Entwickler macht für mich auch die Tatsache aus frühzeitig abstrahieren zu können und zu merken, wo eine erweiterte Struktur hinein muss, bzw. welche Teile man zu einem übergeordneten System zusammenfassen kann. Ich halte es für viel wichtiger dieses grundlegende Verständnis zu erwerben, als genau zu wissen, wie ich in Java (oder irgendeiner anderen Sprache) jetzt genau bestimmte Dinge umsetze. Solange das tiefergehende Verständnis nicht da ist, ist es immer viel mehr Raterei und Programmieren auf gut Glück (mal sehen, was passiert, wenn ich Option X einschalte) als wirklich ein geplantes und strukturiertes Programm. Natürlich gibt es dabei am Anfang weniger Erfolgserlebnisse, weil es ein theoretischeres herangehen ist, dafür kommen die Erfolgserlebnisse nach einer Einarbeitungszeit deutlich schneller und auf einem höheren Level. Es ist am Anfang mehr Arbeit und nicht für jeden genauso Spaß machend wie das direkte Loslegen - aber es zahlt sich aus und bringt einem wirkliches Wissen.

Sehe ich anders - es soll ja nicht darum gehen irgendwie einen funktionierenden Taschenrechner zu basteln sondern ein Programm zu planen und zu entwickeln. Natürlich kann ich den Rechner recht schnell dreckig zusammengebauen (siehe auch der Link, der gepostet wurde) - aber dabei habe ich keinen Lerneffekt! Es soll ja auch etwas dabei hängen bleiben, so dass man nach Bearbeitung der Aufgabe merkt "Aha, Konzept X war nötig, damit Funktionalität Y richtig funktioniert". Vielleicht sehe ich das ganze zu idealistisch, aber wenn bei einer Übungsaufgabe kein wirklicher Lerneffekt entsteht kann ich mir die Bearbeitung der Aufgabe direkt sparen (und ich würde eine Aufgabe auch dann gar nicht erst bearbeiten). Der Weg ist bei sowas das Ziel - wenn ich solch eine Aufgabe stelle und mit legt jemand eine gut strukturierte Lösung vor, die vielleicht nicht komplett ist, aber erkennen lässt, dass sich derjenige wirklich Gedanken dazu gemacht hat, dann ist mir das viel lieber als eine von der Funktionalität her komplette Lösung, die aber konzeptionell massive Lücken hat. Du hast doch die komplette Javadoc Dokumentation zur Verfügung. Wer hindert dich daran dort ein wenig rumzustöbern? Wenn man in etwa weiss, wonach man sucht kommt man da sehr schnell zu brauchbaren Ergebnissen. Die Daten eingeben wirst du in einem Textfeld (in Swing stehen dir da JTextField, JTextArea und JEditorPane zur Verfügung), da ist die Dokumentation genau dieser Klassen also schonmal Anlaufstelle Nummer 1. Hast du dort schonmal nachgesehen?

Natürlich! Das ist recht schwierig in ein paar Absätzen zusammenzufassen. Du wirst nicht drumherum kommen dich in die verschiedensten Bereich einzuarbeitten. Auf der einen Seite hast du die eigentlichen Taschenrechner Berechnungen - die sind relativ trivial und mit wenig Logik zu implementieren. Was du hier benötigst ist eine Menge von Eingabewerten und den Operationen, die du auf diesen Werten ausführen willst. Hierzu wirst du dir eine geeignete Datenstruktur konstruieren müssen, die sowohl die Werte, als auch die Operationen selbst kapselt. Damit benötigst du dann schonmal grundlegende Kenntnisse sowohl im Konzept objektorientierte Programmierung, als auch die Umsetzung in Java. Da gibt's ganz gute Tutorials zu, nur wirst du da nicht innerhalb von zwei Abenden weiterkommen. Sowas benötigt vor allem Zeit, ein wenig Nachdenken und vor allem den Willen sich mit dem ganzen Thema zu beschäftigen. Von nix kommt halt nix. Der nächste Schritt ist dann die Einbindung der Logiken in eine graphische Oberfläche. Auch hier wirst du dich zunächst mit den grundlegenden Theorien und Konzepten hinter einem GUI vertraut machen müssen. Wie funktioniert eine Oberfläche, was sind GUI Events, wie steuerst du selber das Aussehen deiner Applikation etc. Das sind teilweise recht abstrakte Dinge, teilweise aber auch schon ganz konkrete Dinge, z.B. wie wird ein Fenster in Swing oder SWT aufgebaut. Wie gesagt, das ganze ist nicht "mal eben" erklärt sondern benötigt schon eine gewisse Zeit an Theorie-Erarbeitung und -Einarbeitung. Wenn du in so einem frühen Stadium schon die Lust verlierst, dann würde mich wirklich mal interessieren, was du dir denn generell bisher an "Informatik" vorgestellt hast? Gerade Programmierung ist ein aufwändiges Feld, das viel Arbeit erfordert, bis man an einem halbswegs guten Kenntnisstand angekommnen ist. Und selbst dann ist es noch ein ständiges Weiterlernen. Thx nochmal für die letzten Antworten! GreeZ DarkNeon

Anders wird es nicht funktionieren. Wenn du nicht bereit bist dich intensiv mit der Materie zu beschäftigen, und das sowohl was die Konzentration, als auch was den zeitlichen Umfang angeht, dann wirst du nie besonders weit kommen. "Mal eben" ist sowas nicht zu machen.

Würde ich nicht empfehlen - oder du musst schon jemanden haben, der es sehr gut versteht, so etwas rüberzubringen. Jede Programmiersprache kannst du nur wirklich erlernen indem du sie benutzt - und intensiv benutzt. Bücher, Tutorials sind wichtig und helfen einem den Einstieg zu finden, aber wichtig ist es sich damit zu beschäftigen. Zu sehen, dass es funktioniert und nach und nach dahinterzukommen warum es genau so funktioniert, wie es funktioniert. Gib dir selbst eine kleine Aufgabe, ein Mini-Projekt sozusagen. Setze dir ein Ziel und versuche mit allen vorhanden Resourcen daruafhin zu arbeiten. Sag dir beispielsweise "Ich will eine Text-Übersicht aller vorhandener Dateien auf meiner Festplatte, mit Größe und letzten Änderungsdatum. Ein Mini 'dir' oder 'ls' sozusagen." Dann arbeite dich langsam vor und du wirst merken, dass du an verschiedenen Ecken immer wieder neue Informationen brauchst um weiterzukommen. Beschaffe dir diese Informationen und arbeite sie in dein Programm mit ein. Du wirst sehen, Stück für Stück wirst du so dein Wissen weiter ausbauen und immer wieder einen "Aha, so-geht-das-also Effekt haben".

Das ist deine Erfahrung mit deinem Berater bei deinem Arbeitsamt vor Ort. Welche anderen Erfahrungen hast du gemacht, dass direkt auf die Arbeitsagentur generell zu extrapolieren?

Stimmt, sehe ich ja auch jetzt erst. Na dann wird er noch ganz andere Probleme zu lösen haben. @OP: Wenn du nicht unbedingt mit reinem AWT arbeiten musst (und mir fällt kein triftiger Grund ein, warum das heutzutage noch so sein sollte) dann wechsle auf Swing. Welche Speicherfrage? Die Tatsache, dass ein Frame + ein Listener mehr Speicher verbraucht als ein Frame, der gleichzeitig einen Listener implementiert? Das sind Dinge, die man nun wirklich ignorieren kann - da gibt es in jeder Anwendung Bottlenecks, die deutlich schwerer wiegen, als die paar Bytes mehr an Bytecode, die im Speichern liegen.

Dafür braucht es keinen WindowListener - JFrame#setDefaultCloseOperation(WindowConstants.EXIT_ON_CLOSE) tuts auch. Vom Stil her alles andere als sauber und schön anzusehen. Wofür gibt's schließlich innere und annonyme innere Klassen? Bringt ein ganzes Stück mehr Übersichtlichkeit ins System hinein und wartbarer ist es auch noch. Dann hättest du vielleicht ein wenig früher anfangen sollen, dich mit der Materie zu beschäftigen. Was dir nämlich fehlt sind Grundlagen, die man nicht eben an einem Abend vermitteln und lernen kann - da gehört schon ein wenig mehr zu.

Ein guter Einstieg ist das Sun Swing Tutorial: http://java.sun.com/docs/books/tutorial/uiswing/index.html Sehr ausführlich, sehr gut verständlich und enthält eigentlich alles, was du brauchst um selbst mit dem Erstellen von Oberflächen zu beginnen. Also einfach reingucken und bei konkreten Problemen nochmal fragen.

http://www.galileocomputing.de/openbook/javainsel3/ lesen und verstehen.

... was aber streng genommen auch kein Compiler ist, sondern nur eine Sammlung von Tools, die u.a. - je nach Installation - auch den GCC enthält.

Doch, bekommst du. Internet Explorer -> Extras -> Sun Java Console

Also mit dieser Beschreibung garantiert nicht... ich hab nicht die geringste Ahnung, was denn nun genau nicht funktioniert. Wie werden deine Daten verarbeitet, wo gespeichert? Wenn du Hilfe haben willst, dann wirst du schon ein wenig konkreter werden müssen... so eine schwammige Beschreibung ist mir bisher noch nirgendwo untergekommen.

Natürlich! Mach dir klar, was du machst und was erwartet wird. AddParameter kann nur zwei Argumente als Parameter auswerten: Den Namen des Parameters, der gesetzt werden soll und dessen Wert - mehr nicht. Das liegt an der Funktionsweise des HTTP Protokolls. HTTP kennt weder Java, noch Objekte. Ein Calendar Objekt kannst du daher über HTTP nicht so, wie es ist übertragen. Mach dir klar, das HttpClient nur ein Java Aufsatz ist um schnell und komfortabel HTTP Requests zu erzeugen - nicht um Java Objekte oder Objektgraphen zu versenden. Erst wenn du verstanden hast, wie HTTP funktioniert, was das Multipart Format wirklich ist und was du mit dem HttpClient eigentlich wirklich machst wirst du eine Lösung für dein Problem finden. Vorher ist es nur Rumstochern im Sumpf. Du wirst also deine Datums-Informationen, um sie über HTTP versenden zu können, zunächst in eine Textform überführen müssen, die du dann wiederrum auf dem Server wieder auswertest un din Objekte zurücktransferierst, mit denen du dann wieder weiterarbeiten kannst.