perdian

Liest du eigentlich auch, was hier gepostet wird?

Nein, gibt es nicht - die verschiedenen Formate und verwendeten Streaming-Technoligien unterscheiden sich teilweise sehr stark und entsprechend gibt es kein One-fits-all Programm. Als Google-Stichworte: Für Windows Media: SDP Für Real Media: Streambox VCR

Was hast du denn bisher schon herausgearbeitet und wo genau hast du noch Probleme? Die komplette Aufgabe wird dir hier niemand vorbereiten, also ein wenig Arbeit wirst du schon selbst reinstecken müssen.

Vielleicht meinst du 'Popup', aber vielleicht formulierst du die Frage auch einfach nochmal - und diesmal so, dass jeder normale Mensch sie auch verstehen kann.

Du weisst aber schon, dass PHP eine serverseitige Sprache ist, die von Fenstern überhaupt keine Ahnung hat?! Nein, geht's nicht.

Ohne jemandem auf die Füße treten zu wollen, aber ich denke genau das dürfte der häufigste Grund sein. Wo "überhaupt nicht" vieleicht ein wenig extrem ausgedrückt ist, ich würde es vielleicht einfach als "zu spezialisiert" oder "zu wenig" bezeichnen. Wer sich beispielsweise als AE während der Ausbildung ausser mit PHP und ein wenig HTML keine zusätzlichen Kenntnisse aneignet brauch sich hinterher nicht zu wundern, wenn ihn auf dem Arbeitsmarkt niemand haben will, oder jeder Job, der einem angeboten wird sauschlecht bezahlt wird. Jeder Schüler glaubt, kaum habe er eine Internetseite erstellt, irgendein freies CMS eingebunden und mal eine MySQL Datenbank aufgesetzt er sei bereit sich auf ein großes Kundenprojekt zu stürzen. Das zu so etwas viel mehr gehört als nur hier und da ein wenig klicken und konfigurieren wird sehr oft unterschätzt. Zu einer Ausbildung, die einem später auch wirkliche Chancen auf dem Arbeitsmarkt eröffnet, das heisst anspruchsvolle Aufgaben, Eigenverantwortung und ein entsprechendes Gehalt gehört deutlich mehr als einfach nur das zu machen, was von einem verlangt wird. Ohne eine gehörige Portion Eigeninitiative geht es nicht. Um daher den Bogen wieder zurück zur Ursprungsfrage zu kommen: Es sieht auf dem Markt gar nicht so schlecht aus, wie man durch manch einen Erfahrungsbericht glauben könnte. Wer mit offenen Augen durch die IT-Welt geht und auch durchaus an (scheinbar) fachfremden Dingen Interesse zeigt, der wird sich auf absehbare Zeit keine Sorgen um (s)einen Job zu machen brauchen.

Sorry, hab beim Copy&Paste vergessen die Absender anzupassen. Ja, und? Das bestreitet hier niemand. Die Welt ist nunmal ungerecht. Lern damit zu leben, oder du wirst zu nichts anderem mehr kommen als dich über irgendwas aufzuregen.

Wir kennen weder die genaue Situation, noch den Prüfer, der genau diesen Kommentar gesat hat. Bei solchen Dingen bin ich immer vorsichtig mit Bewertungen von aussen. Erstmal muss es nicht tatsächlich genau so passiert sein, wie besagter vierter Azubi es berichtet hat. Und selbst wenn doch: Vielleicht hat er sich wirklich so verdammt dumm angestellt, dass dem Prüfer einfach nur der Kragen geplatzt ist? Das sind alles nur Menschen und bei manch einem Prüfling kann ich mir durchaus vorstellen, dass als Prüfer da hier und da das Temperament mit einem durchgeht. Aus eigener Erfahrung weiss ich, dass man diesen kausalen Zusammenhang nicht ziehen sollte. Nur weil jemand selbst Prüfer ist führt das noch lange nicht automatisch dazu, dass er seine eigenen Auszubildenden auch entsprechend auf die Prüfung vorbereitet bzw. ihnen die Inhalte vermittelt, die er selbst in Prüfungen verlangt. Natürlich, aber das ist auch Teil der Prüfung. Es geht eben nicht nur darum den Inhalt seiner Dokumentation nochmal vorzulesen - wäre das der Fall könnte man sich die ganze Prüfung sparen. Es geht auch um das Auftreten, die Fähigkeit jemanden von seinen Ideen und Methode überzeugen zu können. Und weil das noch ganz andere Fähigkeiten und Talente benötigt als dies in der schriftlichen Prüfung der Fall ist kann es eben gut passieren, dass jemand der 100% im schriftlichen Teil geholt hat in der Präsentation total versagt. An welchen objektiven Maßstäben machst du das fest? Nicht jeder legt bei der Beurteilung "gute Präsentation" die gleichen Maßstäbe an. P.S.: Sagt mal, gab es hier irgendwo Satzzeichen zum halben Preis, oder warum wimmelt es in manchen Beiträgen nur so von Frage- und Ausrufezeichen? Sowas macht einen Beitrag auch nicht richtiger.

Ja. In der Regel bietet dir deine depotführende Bank solche Funktionalitäten direkt im Online-Banking Bereich an.

*lol* Was hat das mit Java zu tun? Das ist ein absolut sprachunabhängiges Phänomen. Programm und Laufzeitdaten gehören nicht miteinander vermischt. Also was genau hat dich jetzt an der Sprache Java enttäuscht? Was könntest du unter C++/COBOL/ADA/... anders machen?

Ich habe ausser ein paar Grundversuchen noch nichts mit J2ME gemacht, aber auch hier wird es irgendeine Persistenzlösung geben. Sei es eine vom Gerät bereitgestellte Datenbank, in der die Werte gespeichert werden, oder andere Lösungen, aber auch dort wird es nicht in das Programm selbst geschrieben. Im Zweifel: In den entsprechenden Dokumentationen nachlesen.

Gar nicht. Selbst wenn das Betriebssystem den Zugriff auf die JAR Dati zulässt, aus der die Applikation heraus geladen worden ist, so wird - nachdem die Datei verändert und neu gespeichert worden ist - eventuell der ClassLoader nicht mehr in der Lage sein Klassen aus dem Archiv zu laden. Von daher: Finger weg! Ein schlechteres Design kann ich mir kaum noch vorstellen. Code und Daten gehören getrennt - genau deshalb wirst du deinen geplante Vorgehensweise auch nirgendwo sonst finden. Wieso sträubst du dich so gegen das Speichern der Daten einer externen Resource?

Und genau das ist oftmals ein Problem, da die Wahrnehmung hier sehr unterschiedlich ist. Was genau ist "benutzerfreundlich"? Wo für einen computerunerfahrenen Benutzer eine Dialogbox "sind Sie wirklich sicher?" vielleicht lebensrettend ist empfindet ein erfahrener Benutzer so etwas als Bevormundung und unnützes Gimmick. Doch was ist jetzt - ohne den genauen Personenkreis zu kennen, der das Produkt einsatz - objektiv gesehen benutzerfreundlicher? Ich weiss es nicht. Linux (und Unix allgemein) hat halt eine komplett andere Herangehensweise an die Dinge. Der Benutzer wird nicht bevormundet und es werden ihm nicht (wie unter Windows oftmals und unter Mac quasi immer) die Möglichkeiten des Feintunings genommen sondern im Gegenteil: Es wird von ihm erwartet, dass er sich mit genau diesen Details befassen will. Es ist kein Fehler im eigentlichen Sinne, dass Linux oftmals viel Konfiguration und viel Detailwissen erfordert - es ist ein entscheidendes Feature! Das kommt auch wiederum auf den Einsatzzweck an. Bei deinem Server, der 24/7 läuft und brisante Daten wie beispielsweise Krankengeschichten etc. speichert ist mir die ergonomie des Systems ehrlich gesagt komplett egal - hier interessiert mich die Stabilität und Sicherheit des Systems. Und so etwas beurteilen zu können ohne mit den Systeminterna bis zu einem gewissen Level vertraut zu sein und diese zu beeinflussen können ist praktisch nicht möglich. Richtig. Und das soll es auch gar nicht sein, weil genau dieser User nicht die primäre Zielgruppe ist. Ich denke das tut auch niemand. Im Gegenteil.

100%ige Zustimmung. Gerade im Zusammenhang mit "um mich zu gewinnen" finde ich folgende Beschreibung der Apache Software Foundation sehr passend: Quelle: http://jakarta.apache.org/site/understandingopensource.html

Ach ja? An welchen Dingen machst du so etwas fest?

Anwalt?! Arbeitsgericht?!

Das ist doch aber schonmal ein Punkt, wo du durchaus ansetzen kannst. Dein Chef ist letzten Endes derjenige, der beim Kunden für die Software geradestehen muss und auch derjenige, der dir dein Geld überweist. Von daher: Wer die Musik bestellt, der bestimmt auch was sie spielt. Wenn dein Chef will, dass das Programm so und so geschrieben und strukturiert wird, dann ist für dich als Angestellter ganz klar die Vorgabe: Machen! Ich habe mich in meinem altern Job auch oft tierisch darüber geärgert, dass mein Chef nicht mit meinen Lösungen zufrieden war. Und natürlich war ich im Glauben es besser und "richtiger" machen zu können, als er es gerne möchte (in dem Glauben bin ich übrigens immer noch). Aber wenn er mir sagt "Nein, ich möchte das so", dann mache ich halt mal die Faust in der Tasche und mache es genauso wie er es will - aus diesem Grund ist er Chef, weil er eben sagen darf, wie er es haben will. Wenn es sich dann hinterher rausstellt, dass es auf die Art und Weise deines Chefs schlechter war, nicht funktioniert oder voller Bugs ist kannst du immer noch sagen "siehst du - ich wollte es ja auch anders machen, aber durfte nicht". Bis dahin kannst du aber als Punkt bei genau diesem Thema anführen, dass du es genauso gemacht hast wie dein Chef sich das vorgestellt hat. Auch wenn es nicht mehr wirklich zum Thema passt: In der Regel ist genau das Gegenteil der Fall. In je mehr kleine (möglichst unabhängige) Teile du dein Programm aufsplitten kannst, desto besser ist es sowohl von der Wiederverwendbarkeit, als auch von der Wartbarkeit und der Möglichkeit zu debuggen. Ein richtig gutes objektorientiertes Programm z.B. zeichnet sich dadurch aus, dass eine einzelne Klasse praktisch kaum noch "wirkliche" Arbeit ausführt. Es gibt sogar ganze Aufsätze und Styleguides die nüchtern technisch vorschreiben "Mehr als X Zeilen Code pro Methode gibt Grund zu einem Refactoring". Da halte ich zwar persönlich recht wenig von, aber es zeigt den generellen Weg - erst im Zusammenspiel von mehreren Komponenten und Teilen wird ein Programm zu dem was es ist - eben mehr als die Summe seiner Teile. Ohne die genaueren Zusammenhänge zu kennen und daher eine wirklich kompetente Bewertung abgeben zu können möchte ich mich trotzdem dem Statement anschließen:

Und das fällt dir erst auf, nachdem du den Job angetreten hast? Hallo?! Sowas kann man vorher klären. Und? Seit wann habe ich als neuer Mitarbeiter automatisch das Recht über den kompletten Personalstamm bescheid zu wissen? Du hast echt Vorstellungen *kopfschüttel* Wo dich hoffentlich niemand nehmen wird *immernochkopfschüttel* Tja, warum wohl?

Erfahrungsgemäß tritt der "soll eventuell irgendwann (auch) laufen" Fall im Großteil der Anwendungsfälle überhaupt nicht ein. Aber unabhängig davon: Das schöne an der Servlet Specification (und der gesamten J2EE Specification) ist, dass sie unabhängig von der eigentlichen Implementierung ist. Das heisst wenn du heute mit einer Webapplication beginnst und diese im Tomcat deployst legst du dich damit nicht darauf fest, sondern kannst (immer gesetzt der Fall du programmierst gegen die Spezifikation und verwendest keine Tomcat Interna) ohne Probleme später wechseln. Ich benutze für die Entwicklung auch "nur" einen Tomcat, das Live-System hingegen ist ein Cluster von JBoss Maschinen. Klappt alles einwandfrei. Auch das ist eigentlich immer noch viel zu allgemein. Es ist für das genaue Deployszenario essentiell zu wissen, was an Services zur Verfügung stehen soll. Ansonsten bleibt dir nur die Möglichkeit den ApplicationServer mit allem auszurüsten, was er zu bieten hat (beim JBoss also inklusive HA Unterstützung, Clustering, etc). Das ist in der Regel ein vollkommen unnötiger Overhead und nicht zuletzt immer wieder eine - unnötige - potentielle Fehlerquelle. Was aber deswegen auch nicht automatisch heisst, dass die Webapplication deswegen auch im JBoss laufen muss. Zugegeben, ein eher exotisches Szenario aber es ist durchaus möglich die Webapplication in einer separaten Tomcat Instanz laufen zu lassen, und für den Zugriff auf EJBs eine (entfernte) JBoss Instanz zu kontaktieren. Du kannst ein Servlet durchaus ausserhalb eines Servletcontainers betreiben, allerdings wie schon gesagt: Das willst du nicht wirklich. Es ist ja gerade Sinn und Zweck eines Servlets "nur" den Zugriff und die Verarbeitung über HTTP zu kapseln - die eigentliche Businesslogik sollte nicht auf die Verwendung innerhalb eines Servlets ausgelegt sein. Und damit besteht in der Regel überhaupt keine Notwendigkeit ein Servlet ausserhalb seines dafür vorgesehenen Containers zu verwenden. Wenn man doch immer wieder vor der Problemstellung steht: Wo bekomme ich jetzt ein Servlet her sollte man eher sein Design überdenken als auf tefeukommraus zu versuchen einen Wrapper zu entwickeln/verwenden, der die Servlet API implementiert.

Warum? Wir haben - zum Glück - einen Markt, der bekanntlich von Angebot und Nachfrage regiert wird. Ich muss nur das richtige Produkt zur richtigen Zeit am richtigen Ort anbieten. Wenn ich als Arbeitgeber für mein Angebot "Miesen Job" trotzdem jemanden finde, der ihn genau zu den von mir gewünschten Bedingungen macht, was ist dann daran so katastrophal, dass direkt wieder der Weltuntergang projeziert wird? Es gibt eigentlich nur zwei Situationen, in die man bei solch einem Angebot als Arbeitnehmer kommen kann. A: Mir ist meine eigene Leistung so wenig wert, dass ich tatsächlich glaube mit einem niedrigen Gehalt zufrieden sein zu können. Die Lösung hier für ein besseres Gehalt: Selbstbewusster auftreten. B: Ich finde keinen anderen Job, der mir ein besseres Gehalt zur Verfügung stellt. Das mag sich für den einzelnen vielleicht sehr direkt und hart anhören, aber dann muss ich an meinen Kenntnissen und Fähigkeiten arbeiten - und zwar intensiv arbeiten. Der einzige Anreiz, den ich einem Arbeitgeber bieten kann um meinen höhreres Gehalt, Zusatzleistungen, eigenes Büro, whatever zu rechtfertigen ist Leistung. Ich muss ihm klarmachen, dass er zwar viel in mich investiert aber letzten Endes noch mehr durch meine Arbeit wieder rausbekommt. Als Möbelpacker kann man sowas direkt festmachen: Wenn ich zwei Kartons anstatt nur einem tragen kann schaffe ich in halber Zeit die ganze Arbeit und kann zum nächsten Kunden fahren - ich bringe also doppelt soviel Einnahmen in gleicher Zeit. In der IT ist es ähnlich, nur muss ich hier keine Kartons schleppen sondern Software entwickeln, Schulungen durchführen, whatever.

Gar keine. Deine Frage impliziert, dass beide die gleichen Funktionalitäten darstellen und man daher z.B. einen Tomcat durch einen JBoss substituieren könnte und andersrum. Dem ist nicht so. Es sind zwei verschiedene Produkte, die verschiedene J2EE Aspekte und Bestandteile implementierung und von daher ist diese Frage so nicht zu beantworten. Tomcat ist ein Servlet Container, JBoss ein Application Server. JBoss selbst implementiert übrigens nicht selbst die Servlet Specification sondern bringt zur Präsentation auch "nur" einen gebundleten Tomcat mit. Dann wird dir ein Servlet Container (Tomcat, Jetty, Resin, etc.) für den Anfang (und wahrscheinlich auch für den gesamten Lebenszyklus der Applikation) vollkommen ausreichen. Kannst du dieses "möglichst viele Möglichkeiten" ein wenig präzisieren?

Richtig, was aber mehrere Gründe hat: Für jemanden, der nicht aus der Branche kommt ist FI unheimlich allgemein und so gut wie nichts sagend. Dann kommt meistens diese Standard-Reaktion "Ach ja, der macht halt irgendwas mit Computern" und nicht selten irgendwann hinterher geschoben "mein Drucker funktioniert nicht, du machst doch sowas jeden Tag, also wo liegt der Fehler?". Wenn man hier jedoch sagt "Ich bin Software-Entwickler" dann ist das (für die meisten) schon viel spezifischer und es macht sich eine erste grobe Vorstellung breit. Bei IT Firmen oder anderen "internen" liegt die Situation ähnlich: Das wirklich schöne am FI ist ja gerade, dass er einem sehr weite Möglichkeiten bietet das eigene Tätigkeitsfeld zu erweitern bzw. festzulegen. Deswegen ist meine erste Gegenfrage, wenn ich mitbekomme, dass jemand FI ist auch immer "Aha, in welchem Bereich denn?". Und damit meine ich gar nicht mal die Unterscheidung AE/SI sondern der tatsächliche Einsatzbereich. Macht derjenige eher Entwicklung, eher Support, eher Wartung, eher Installation, und so weiter. Fachinformatiker ist für mich - im konkreten Umgang wie einem Gespräch - einfach zu unpräzise um das zu beschreiben, was ich tagtäglich tue. Nur, weil sie sich - nach bestandener IHK-Prüfung - FI nennen dürfen? Ich glaube ganz so einfach ist es auf dem Markt dann doch nicht.

Das kommt darauf an, was du genau machst. Wenn ich eine Bewerbung auf den Tisch bekomme woraus hervorgeht, dass der Bewerber z.B. Commiter oder Main-Entwickler bei einem bekannten OpenSource Projekt ist, dann kann das durchaus ein überzeugendes Argument für ein genaueres Ansehen der Unterlagen und/oder die Einladung zu einem Vorstellungsgespräch sein. Das ist genauso der Fall, wenn aus den eigenen Referenzen schon hervorgeht, dass - auch in der Ausbildung oder nebenher - ein größeres Projekt gestemmt worden ist. Genauso bezeichne ich mich nach aussen hin nie als Fachinformatiker. Das mag die genaue Berufsbezeichnung aber ist sowas von schwammig, dass niemand genau weiss, was für Spezialisierungen bzw. Schwerpunkt man dort nun vermuten kann.

Das ist wirklich schon heftig. Zieht man dann noch Steuern und Sozialabgaben ab könnte unterm Strich noch weniger netto rauskomme, als ich während meiner Ausbildung bekommen habe. Hast du denn mal probiert, dich auf andere Stellen zu bewerben? Es ist immer leicht gesagt "Ich finde eh nix anderes" und es wäre eine Schande hinterher irgendwann zu merken, dass es doch besser gegangen wäre, wenn man ein wenig die Fühler ausgestreckt hätte. Das ist immer eine Frage der Alternativen. Wenn sonst nichts zu bekommen ist, dann sind auch 19k besser als überhaupt nichts - gar keine Frage. Aber ich würde mich als Arbeitnehmer bei diesem Gehalt deutlich unterbezahlt fühlen, und entsprechend unmotiviert wäre mein Leistungsoutput. Das kann auch für einen Arbeitgeber nicht wirklich gewollt sein. Alternativen gibt es immer. Es kommt dir niemand entgegen und legt dir ein Super-Angebot von sich aus auf den Tisch, aber wenn deine Leistungen stimmen, dann findet sich auch was.