perdian

Es gibt eine Java API - in der könnte man eventuell einfach mal nachsehen, was eine URI ist und wofür man sie verwenden kann. Dort steht dann unter anderem, dass man sie ganz einfach in eine URL überführen kann. URI fooAsURI = URI.create("foo/bar/"); URL fooAsURL = fooAsURI.toURL();

Darum schrieb ich ungetestet. Ein wenig Mitdenken ist durchaus noch gefordert. In diesem Falle muss es heissen: URI currentURI = currentDirectory.toURI();

Natürlich nicht. Ich gehe mal davon aus, dass du diese Methoden aus deiner eigenen Klasse heraus aufrufst. Und solange du eben diese Methoden nicht implementiert hat wird kein Compiler dieser Welt wissen, wo er danach suchen soll. Zu deinem Problem: Ein wenig von hinten durch die Brust ins Auge und ungetestet aber funktionieren könnte: File currentDirectory = new File(".").getCanonicalFile(); URL currentURI = currentDirectory.toURI(); URI targetURI = currentURI.resolve("foo/bar/sound_datei.mid"); File targetFile = new File(targetURI);

Bewerben natürlich! Was hast du denn zu verlieren? Wenn du keine Bewerbung schreibst hast du die Stelle nicht. Wenn du jedoch eine Bewerbung schreibst, dann ist die Chance die Stelle doch zu bekommen möglicherweise schlecht - aber immer noch besser als null.

Solange es rein textbasiert bleibt (also HTML oder RTF): ExamDiff http://www.prestosoft.com/ps.asp?page=edp_examdiff

Das heißt wahrscheinlich, dass du die (Übungs)Aufgabe bekommen hast sowohl einen FTP SErver, als auch einen Portscanner zu schreiben. Eine solche Aufgabe dient in der Regel dazu, dass du dir das dazu benötigte Wissen selbst aneignest und nicht dazu deine Fähigkeit bereits existierenden Code zu finden zu stärken. Daher als gutgemeinter Tipp: Beschäftige dich auch selbst ausführlich(!) damit. Das schließt in deinem Fall mit ein sich Wissen in den Grundlagenthemen zu beschaffen, die für genau diese Operationen notwendig sind (TCP Sockets, Input- und OutputStreams, etc.)

Sicher? Typenschild unter dem Laptop? Was gibt das BIOS aus? Zur Not aufschrauben und einen Blick reinwerfen. Ohne genaue Typenbezeichnung kannst du soviel bitten und hoffen wie du willst - es wird dir nichts bringen.

Mir leuchtet nicht so ganz ein, was der tiefere Sinn dahinter sein soll. Wieso willst du dein Projekt - so wie ich das sehe unnötigerweise - in mehrere Module in mehreren Programmiersprachen aufspalten? Die verschiedenen Module wirst du dann wieder über Interfaces eineinander binden müssen, das heisst viel (meistens dreckiger) Adaptercode. Solange es keine zwingenden Gründe gibt aus Sprache A heraus in Programm in Sprache B aufzurufen sehe ich keinen wirklichen Sinn hier drin. Natürlich! Was sollte dagegen sprechen? Du kannst in jeder Sprache Webanwendungen erstellen. Mir ist neulich irgendwo ein Stück Code über den Weg gelaufen, dass einen kleinen HTTP Server in LISP implementiert. Für produktiv zu gebrauchen würde ich das nicht gerade nennen aber war interessant den Ansatz zu sehen. Das hängt von den Rahmenbedingungen ab. Ist bereits viel C++ Code vorhanden, der einfach nur integriert und angesteuert werden muss? Ist das nötige KnowHow bei den Entwicklern vorhanden? Das sind nur zwei Punkte, man könnte noch eine ganze Reihe weiterer aufführen.

Und wie kommst du zu der Einschätzung, dass gerade die von dir genannten Sprachen überall wichtig sind? Es kommt hier sehr auf den Einsatzbereich an. Jede Sprache ist irgendwo sehr wichtig - sonst würde es sie nicht geben.

Ich kann mich da meinen Vorrednern nur anschließen: Von wenigen Stunden bis mehreren Monaten habe ich alles schon erlebt. Wobei das auch das entpsrechende Interesse und die Einstellung des Unternehmens verrät: In einer Firma, die es nicht für nötig hält potentiellen Arbeitnehmern innerhalb von wenigen Tagen nicht mal eine kurze Nachricht a la "Wir haben Ihre Bewerbung bekommen und melden uns wieder bei Ihnen" zukommen lässt, möchte ich erst gar nicht anfangen. Der restliche Ablauf dort wird entsprechend ähnlich sein.

Das heisst entschlüsselt genau was?

In der mod_jk Konfiguration nur bestimmte URLs zur Auslieferung an den Tomcat delegieren. Alles andere wird dann - wie sonst auch - vom Apache behandelt. Meine typische Konfiguration delegiert z.B. nur für *.yum und *.jsp an den Tomcat weiter, für alles weitere bleibt der Apache erste Wahl.

Dem wird wohl so sein. Nein, sowas ist mir noch nirgendwo unter gekommen. Das wäre auch praktisch gesehen recht ungünstig. Zum Lernen des Programmierens an sich bieten sich in der Regel andere Sprachen an, als zum täglichen Verwenden. Man hätte - gesetzt der Fall man würde tatsächlich bestimmte Sprachen als Ausbildungsstandard festlegen wollen - also zwei Möglichkeiten: Möglichkeit A: Sprachen, die sich leicht erlernen lassen und die die Konzepte von Programmierung sehr anschaulich rüberbringen (sehr gerne werden hierfür Sprachen aus der Pascalfamilie wie Pascal, Modula, Oberon) aber in der Praxis relativ selten eingesetzt werden. Möglichkeit B: Sprachen, die in vielen Projekten eingesetzt werden (z.B. die der C-Familie) aber bereits beim Lernen dazu verführen mit Tricks und Kniffen zu arbeiten und es einem dabei einfach(er) machen dabei das eigentliche Ziel - nämlich nicht Sprache X sondern das Konzept Programmierung zu verstehen - aus den Augen zu verlieren. Beide Möglichkeiten bieten Vor- und Nachteile. Doch welche ist besser? Das hängt von vielen Rahmenbedingungen ab. Nehmen wir als einfachsten Fall mal den Lehrer: Jemand, der Java in- und auswendig kann wird wahrscheinlich auch eine Möglichkeit finden in dieser Sprache die Grundkenntnisse gut zu vermitteln. Wenn dieser jenige jetzt aber beispielsweise Modula machen muss (weil es so im Lehrplan steht), aber noch nie damit gearbeitet hat wird es sicherlich schwieriger für ihn sein hierin alles genauso gut zu vermitteln. Und genau dieses Vermitteln ist aber einer der zentralen Punkte. Wer Programmierung einmal vernünftig gelernt bzw. beigebracht bekommen hat steht schonmal sehr weit vorne.

Da du sehr unpräzise beschreibst, was du eigentlich genau möchtest: Nein! Drucken von bestimmten Bereiches ist Sache des Browsers - nicht der HTML Seite selbst.

Also ziemlich sicher bin ich mir bei der Behauptung, dass du nicht nach deutschen Recht in den USA einkaufen kannst. Sonst müsste ja - rein theoretisch gesehen - jeder Händler, der international seine Waren abietet sämtliche Gesetze der Länder seiner Kunden in- und auswendig kennen und in seinen AGB mit einbinden. Die deutschen mögen solche bürokratischen Dinge lieben aber in anderen Ländern ist man da wohl nicht so extrem. Von daher: Wer von D in US einkauft wird sich an die dortigen Gesetze halten müssen. Wie die dort aussehen - das ist eine andere Frage, und auch wenn ich am Dienstag ins Land der unbegrenzten Möglichkeiten fliegen werde - da hab ich jetzt wenig Ahnung von

Ah, das tut einem ja beim Lesen geradezu körperlich weh! Noch ist Rechtschreibung nach Gefühl nicht wirklich zugelassen. Das Programm heisst immer noch Excel.

Dann ist die Software nicht flexibel genug, bzw. es wird nach aussen hin nicht richtig dargestellt. Letzten Endes läuft es auf einen Punkt hinaus: Ich muss die vom Kunden gewünschten Funktionalitäten in meiner Software abbilden können. Mit den neuesten Versionen geht dies in der Regel am besten, einfachsten und sichersten. Wenn ich mich dann selbst einschränke und mein System von vorneherein nicht so aufbaue, dass es mit den Anfoderungen mitwachsen kann und auch neue externe Libraries bzw. Plattformen "verkraftet", dann liegt ein Fehler im Design vor. Huch, und sowas bei IBM Nur kostenlos als Entwicklerversion, oder ist der produktive Einsatz hier auch schon mit eingeschlossen?

Das musst du mir erklären. In einem gut geführten Dienstleistungsunternehmen bekommt der Kunde überhaupt nicht mit, wenn auf eine neue Version gewechselt wird. Es wird eventuell eine geringe Downtime angekündigt, in der die Umstellung durchgeführt wird aber das wars auch. Den Kunden interessiert in der Regel nicht die Version der Software, die eingesetzt wird sondern nur, dass "es" funktioniert. Und minimal anderer Preisstruktur. Kennst du die Lizenzkosten für WebSphere im professionellen Bereich? Da geht einem der Hut hoch!

Er ist der einzige zertifizierte - das heisst nicht, dass die anderen die gleichen Funktionalitäten nicht auch bieten. Beim JBoss weiss ich z.B. definitiv, dass eigentlich alle Java EE 5 Funktionalitäten unterstützt werden (schließlich ist z.B. Gavin King führend im EJB3 Persistence JSR tätig). Sie haben eben nur noch nicht den Sun Zertifizierungsprozess durchlaufen (was aber auch nur noch eine Sache der Zeit sein dürfte). Dem normalen Entwickler sollte davon allerdings in der Regel nichts auffallen - die Funktionalitäten sind trotzdem vorhanden. Java SE ja - bis EE 6 auf den Markt kommt wird es aber wohl noch ein ganzes Weilchen dauern.

Ich bin ein großer Java EE Fan aber man muss hiermit auch nicht alles sofort erschlagen. In der Regel fährst du mit einer "einfachen" Applikation für eine ganze Weile sehr gut. Eine "richtige" Java EE Applikation erfordert eine ganze Menge von Erfahrungen, damit man sich nicht bereits am Anfang in den Details verläuft und viel zu viel Overhead mit einbaut, der eigentlich unnötig wäre und einen letzten Endes nur behindert. Dieses Erfahrung lässt sich sehr gut mir "einfachen" Applikationen sammeln. Dort kommt dann manchmal ganz automatisch die Feststellung "Das ließe sich jetzt mit EJBs viel einfacher gestalten". Und genau dann ist - meiner Meinung nach - der richtige Punkt sich intensiver damit zu beschäftigen. Java EE nur um seiner selbst willen geht meistens in die Hose. Nein, überhaupt nicht. Java EE ist eine Technologie bzw. eine Sammlung von verschiedenen Technologien und Spezifikationen unter einem Dach. Glassfish ist eben nur eine Implementierung hierfür. Das heisst wer sich genau an die Spezifikation hält, für den macht es prinzipiell überhaupt keinen Unterschied, ob die Applikation nun auf GlassFish, auf JBoss oder einem WebSphere läuft - das ist ja gerade der Witz an der ganzen Sache. Natürlich bietete jeder ApplicationServer auch eigene Services an, bzw. implementiert bestimmte Services auf eine ganz spezielle Weise, bei der Hersteller A objektiv besser ist als Hersteller B. Das sind aber eher Details. Als kleines Beispiel: Einer der von mir betreuten "lightweight" Java EE Applikationen (also ohne 'richtige' EJBs) läuft auf meinem Entwicklungsrechner einwandfrei "nur" mit einem Tomcat als Webserver. Auf den Livesystem steht aber ein Cluster von JBoss Rechnern für Session Replikation und anderen netten Features. Man muss sich also immer vor Augen halten: Was will ich eigentlich? Auf einem lokalen Testsystem ist es wichtig, dass der Server kurze Startup- und Shutdown Zeiten hat, damit nicht nach jedem Update erstmal fünf Minuten nur für Warten auf den Server draufgehen. Auf dem Livesystem ist die Zielsetzung eine andere - der kann ruhig am Anfang ein wenig brauchen solange er danach stabil läuft. Man muss sich hier das beste rauspicken.

Sorry, aber so eine Einstellung kann ich nicht nachvollziehen. Natürlich sollte man froh sein einen Job zu haben - gar keine Frage - aber das kann und darf nicht die Ausrede dafür sein sich vom Arbeitgeber alles gefallen zu lassen. Und zu diesem "alles" gehört auch ein schlechtes bzw. zu niedriges Gehalt zu. Auch Auszubildende leisten produktive Arbeit - sicherlich nicht in dem Maße, wie das ein "richtiger" Angestellter tut, aber dennoch leisten sie arbeit und tragen dazu bei am Ende des Tages ein qualitativ hochwertiges Produkt zu haben. Kein Mensch ist wie der andere und so ist auch kein Azubi wie der andere. Der eine kommt sozusagen blank und ohne irgendwelche Vorkenntnisse in den Laden hinein, der nächste macht die Ausbildung aber nur noch mehr oder weniger um ein Blatt Papier (=Abschlusszeugnis) zu erhalten, das ihm bei der Jobsuche viele Türen öffnet. Und wenn die Leistung stimmt und man merkt, dass man der Firma etwas bringt, dann halte ich es durchaus für gerechtfertigt diesen Standpunkt auch ruhig mit etwas mehr Nachdruck zu vertreten. Es nicht nur der Arbeitnehmer, der etwas vom Arbeitgeber will - das ganze ist ein geben und nehmen. Auch und gerade in Zeiten eher schlechter Wirtschaftslage. Auch und gerade als jemand, der in der Hierarchie ganz unten anfängt.

Kannst du das beurteilen? Kennst du seinen genauen Einsatzbereich und die Tätigkeiten, die er in seiner Firma ausführt? Wie kannst du dann die Behauptung aufstellen, dass er nicht unterbezahlt sei? Ich habe es mehrfach erlebt, dass sehr gute Auszubildende im Grunde genommen wie normale Mitarbeiter eingesetzt wurden. Sie haben exakt die gleiche Arbeit erledigt, die gleiche Motivation gezeigt, die gleiche Qualität abgeliefert nur eben nicht das gleiche Gehalt bekommen. Das das nicht der Regelfall ist ist mir klar, allerdings halte ich es in so einem Fall für durchaus gerechtfertigt über das Gehalt zu verhandeln und auch ruhig deutlich mehr dabei zu verlangen, als das der Durchschnittsazubi tun würde.

Ist - wenn ich das richtig im Kopf habe - die Weiterentwicklung von Suns ApplicationServer, jetzt aber mit Hilfe einer OpenSource Community. Den großen Vorteil, den ich darin sehe ist, dass die Informationen quasi aus erster Hand kommen. Man sollte meinen, dass Sun seine eigenen Technologieren noch mit am besten kennt. Java EE 5 zertifiziert ist das Ding inzwischen wohl auch, von daher auch eine Sache der persönlichen Preferenzen, wohin man nun tendiert. Aber mal ganz ab von der Frage welche Application Server: Was für eine Applikation entwickelst du? Gerade am Anfang ist es oftmals vollkommen unnötig sich den gesamten Java EE Overhead anzutun, in vielen Fällen reicht bereits eine "nierdrigere" Lösung wie Struts und Konsorten aus.

Ich wüsste nichts, was in ein paar Sätzen oder ein paar Bildern den tieferen Sinn von Verschlüsselung für mehr oder weniger Laien rüberbringt. Ich selbst kann diesem ganzen Sicherheitsfanatismus persönlich auch nicht besonders viel abgewinnen - man kann auch alles übertreiben. Aber darum gehts ja gar nicht. Also, wenn es für dich wichtig ist über einen sicheren Kanal zu kommunizieren, dann musst du eine Interessensabwägung durchführen: Ist es dir wichtiger sicher zu kommunizieren, oder wichtiger mit den Leuten, die dir wichtig sind überhaupt zu kommunizieren? Im ersten Fall musst dann eben den Leuten sagen "Sorry, aber wenn ihr nicht ${Programm} mit ${Verschlüsselung} verwendet dann möchte ich mit euch nicht mehr chatten/mailen/whatever. Das ist die harte Variante, wo sicherlich manch einer sagen wird "Dann eben nicht". Im zweiten Fall wirst du dann wohl oder übel die Einschränkung "unsicherer Kanal" in Kauf nehmen müssen - man kann bei den Leuten nur appelieren und die Fakten darlegen - aber wer nicht will, der will eben nicht.

Geronimo steht noch sehr am Anfang der Entwicklung und ist für mich von daher etwas vorsichtig zu betrachten. Für das Testen sicherlich einen Blick wert, aber für den Produktiveinsatz eher Vorsicht walten lassen. JBoss ist im Bereich J2EE, JEE, JavaEE (wie auch immer es gerade heißen mag) ApplicationServer immer noch der Platzhirsch schlechthin. Was mehrere Vorteile mit sich bringt: Die Software ist hinreichend ausgereift und wird von einer breiten Benutzerbasis verwendet und weiterentwickelt. Dadurch werden potentielle Bugs zeitig erkannt und auch sehr zeitnah gefixt. Dazu kommt eine breite Basis an Unterstützungsseiten, FAQs, Foren, etc. Für mich einige sehr überzeugende Punkte. Könnten sie es nicht hätten sie ihre Existenzberechtigung verloren. Allgemein zum Verständnis von JEE: http://en.wikipedia.org/wiki/Java_EE http://en.wikipedia.org/wiki/Application_server