flashpixx

Du verwechselst hier das Coding mit dem Projekt. Primär liegt es in der Planung, wie lange das Coding dauert. Du gehst hier, wie mir scheint, von Coding aus und das ist der falsche Ansatz. Das ist wohl auch besser, denn wie sollte das funktionieren? Denn wenn Du einen eigenen Server implementieren solltest, dann hättest Du hier einen SMTP Server implementieren müssen. Wir kommen hier immer mehr in die wirklich wichtigen Details. Wenn Du dateibasiert arbeitest, dann entstehen hier ganz große Probleme (wie gesagt, wenn das eine Programm die Datei noch nicht fertig geschrieben hat bevor Dein Programm anfängt zu lesen). Nur weil das nicht direkt zu Deinem Auftrag gehört, ist dies nicht zu vernachlässigen, denn wenn Dein "Programm" zwar nach Definition arbeitet, aber im Realbetrieb nicht richtig funktioniert, dann wird dies letztendlich bei Dir wieder landen. Genau an diesem Punkt würde ich Dir im Fachgespräch einige Fragen stellen. Wenn ich den Thread noch einmal auf mich wirken lassen, dann dann würde ich sagen, die Entscheidung für Perl ohne OOP ist, dass es Dir persönlich mehr liegt. Dies kann Dir im Projekt sprichwörtlich den Kopf kosten. Überlege Dir evtl noch einem sehr gut, ob Du Dir im Moment mit der "nicht-OOP" Variante nicht eher Probleme einfängst. Nein das sind keine wichtigen Dinge, das ist ein bisschen handwerkliche Formatierung. Vom Konzept her kann ich das direkt automatisiert erledigen lassen. Dann kann ich dies mit Hilfe von XSLT und einer XML Beschreibung erledigen lassen. Schematisch gesehen ist das dann: Urspungsdaten => XML Baum => XSLT + XML Beschreibung => Zielformat Das sind auch Details und würden nach der Idee, die ich Dir jetzt gegeben habe, in der Punkt "XML Beschreibung" sich unterscheiden. Sorry, aber das Du hier an Argumenten für Deine strukturierte Analyse anführst, sind alles Details, die innerhalb eines gutes Konzeptes in einen Punkt zusammen fassen kann. Nein das stimmt nicht. Du verhedderst Dich Detailargumenten (siehe Datumsformatierung), anhand der OOP wäre dies das Objekt Datum + das Objekt Formatierung was sich letztendlich in das Objekt Zielformat abbilden lassen. Sorry, aber aber ich komme immer zu dem Schluss, dass hier massive Punkte innerhalb der Planung nicht stimmen.

Warum eine Datei, wenn Du eine Mail hast, dann kannst Du diese direkt aus dem Mailserver verarbeiten z.B. via Procmail. Dann brauchst Du gar keinen Dienst + Cronjob !? Email kommt über den Server und wird dann von Procmail erkannt und an Dein Programm weiter gegeben. DTE ist kein allgmeiner Begriff. Da müsstest Du schon mal mehr Infos liefern. Ist das eine CSV, binäres Format o.ä. Wenn DTE und XML größtenteils gleich sind, warum dann nicht aus den Daten einmal den XML Baum aufbauen und ihn dann einmal via XSLT in die DTE und einmal in die ZielXML transformieren? Vorteil davon ist, die Struktur des Baums kann validiert werden, die Transformation ist extrem flexibel gehalten und kann bei Änderungen sehr effizient geändert werden und zusätzlich ist die Validität bezüglich XML und Inhalt gesichert. Warum nicht: Empfang => MTA => Procmail => Transformierung durch Dein Programm => Procmail => MTA => Versand Kein Cronjob, direkte Verarbeitung bei Empfang, keine Probleme mit Locking, da die Mail direkt und immer vollständig durch das System geht.

Der Punkt 3.4 ist nicht in Deinem ersten Antrag enthalten, es geht nur bis 3.2 (im ersten Posting) Wie schon gesagt, nimm es rein, wenn es feststeht, wenn Du es evaluieren musst, dann mache einen Punkt mit 1-2 Stunden für die Evaluation der Programmiersprache. Wo ist das Problem !? Diese Aussage bestreite ich, es geht ja in erster Linie nicht um das Coding, sondern das Konzept. Genau dieses hatte ich erwartet. Wie unten geschrieben, sind reguläre Ausdrücke für Baumstrukturen fachlich eine schlechte Wahl. Du musst hier fachlich begründen, warum Du eben Perl nimmst und nur weil Perl reguläre Ausdrücke gut umsetzen kann, ist das kein Grund. Ich nehme C++ mit libxml2++ und schon kann ich direkt auf der Baumstruktur Deiner XML arbeiten und ohne, dass ich reguläre Ausdrücke erstellen muss. Das mit dem Interpreter kann man erst einmal so stehen lassen. Bei Perl ist häufig der Hang zu sehr unverständlichen Codekonstruktionen, d.h. unter Umständen ist der Code wesentlich schwerer wartbarer als ein OOP Konzept. Nein das sehe ich sehr skeptisch, denn im Grunde müsstest Du auch die Entwicklung der regulären Ausdrücke als Code abbilden, denn sie sind entscheidend für die Funktion des Systems. Außerdem wäre hier die Frage auch wieder nach der Einsetzbarkeit, denn wenn Du z.B. XML nach irgendwas transformierst, dann brauchst Du gar kein Programm, denn mit Hilfe von XSLT kann ich das vollständig in XML beschreiben und mit dem Sax-Parser z.B. direkt auf der Kommandozeile umwandeln lassen. Alternativ würde man hier sagen, dass man eben ein kleines Programm drum herum baut, dass eben via DOM / Sax und XSLT die Daten transformiert, d.h. das Programm öffnet die Daten XML und die Umwandlungs-XML und liefert das umgewandelte Ergebnis. Aber das würde keine Projekt im Umfang von 70h rechtfertigen. Nur weil Du UML nicht magst, ist das kein Grund. Eine entscheidende Frage in diesem Zusammenhang bleibt, wie stellst Du fest, ob die XML Datei valide ist bzw. der Struktur (inhaltlich) entsprichst, die Du erwartet. Wenn man davon ausgeht, dass zwei unterschiedliche Systeme mit der Datei arbeiten, können hier Inkonsistenzen auftreten. Wenn ein System die Datei schreibt und das andere schon beginnt diese zu lesen, dann musst Du feststellen, dass hier keine Fehler auftreten. Bzw. was passiert, wenn z.B. diverse schließende Tags in der XML Datei fehlen, dann musst Du eigentlich prüfen, ob das Dokument valide. Dateizugriff kann man prüfen, aber mit regulären Ausdrücken kannst Du nicht einfach prüfen, ob die XML valide ist bzw. ob sie inhaltlich korrekt aufgebaut ist. Validität kann der Parser prüfen und Inhaltsprüfung kann ich via DTD oder WSDL machen. Wenn Du mit RegExpr arbeitest, kannst Du je nach Struktur der XML Datei Probleme bekommen. Die zentrale Frage, ohne hier tiefer in die Theorie zu gehen, ist warum Du eine Baumstruktur mit einem endlichen Automaten parst. Ich kann hier von der Theorie her Beispiele konstruieren, die Du nicht mehr mit einem regulären Ausdruck verarbeiten kannst. Die Frage ist also somit, warum erfindest Du das Rad neu, wenn Du mit einer fertigen Bibliothek den kompletten Parsingprozess fertig bekommst und nur den Inhalt verarbeiten musst. Mit XPath z.B. kann ich mir direkt die Inhalte der Knoten liefern lassen bzw. durch diese iterieren. Sorry, aber das ist für mich vom Konzept her eine schlechte Wahl und das Argument "ist nicht gewünscht" ist auch fachlich nicht haltbar. Wenn es so umgesetzt werden soll, dann müsstest Du aber ggf eine alternative in der Dokumentation aufzeigen. Allgemein: Auch wenn nur eine "begrenzte" Funktionsweise umzusetzen ist, bedeutet das nicht, dass man hier am Konzept spart. Gerade für XML Verarbeitung gibt es eine große Anzahl an Technologien, die ein wesentlich strukturiertes Konzept mit sich bringen. Für mich hat das "rumfrickeln mit regulären Ausdrücken" eher einen sehr negativen Beigeschmack, denn es klingt danach, als hättest Du noch nie mit XML gearbeitet, deswegen würde ich bei so etwas XPath / XSLT oder mindestens DOM / Sax erwarten. Du überführst letztendlich eine XML Datei in eine andere Struktur und das kann man konzeptionell sehr schön abbilden und auch mit Hilfe der OOP modellieren. Ich kann diese Transformation sogar mit entsprechenden Tools schon fast, ohne selbst eine Zeile Code schreiben zu müssen, generieren. Für mich sind da im Antrag noch viele Punkte, die ich extrem kritisch sehe.

Ich beziehe mich auf "Somit habe ich kurze Wege zu den Ansprechpartnern ...", rein formal lege ich Dir Wege als geographische Wege aus und dann erklär' mir mal bitte den Zusammenhang zu Deinem Projekt Es gibt mehrere Möglichkeiten: Entweder hast Du vom Betrieb eine feste Vorgabe welche Sprache verwendet werden soll, d.h. diese Information gehört das Projektumfeld oder eben Du musst einen Punkt aufnehmen und die Sprache evaluieren. Beides fehlt bei Dir. Du solltest fachlich richtige Termini verwenden: Dienst (Informatik) Systemdienst Netzwerkdienst Nein die Plattform ist schon relevant und auch die Komponenten, die Du einsetzt. Versuch mal ein unter Linux kompiliertes C/C++ Programm auf einer Sun Sparc laufen zu lassen oder unter FreeBSD. Da Du keine Info über die eingesetzte Technik lieferst, kann ich alles mir hinzu dichten. Darum musst Du schon in den Antrag schreiben, in welche Richtung Du arbeitest. Wenn Du z.B. Java als Sprache verwendest (verwenden musst), dann wirst Du was die Portierbarkeit der Anwendung angeht, flexibler sein, bei C/C++ sieht es schon schwieriger aus (aber z.B. mit Hilfe der Boost auch ohne weiteres möglich, setzt aber dann OOP als Konzept voraus. siehe unten). Diese Information, wenn Du jetzt weißt, dass Du Perl verwendest, gehört in den Antrag. Aber ich stelle hier direkt die Frage, warum Perl. Perl ist eine Interpretersprache, d.h. man schleppt immer den Interpreter mit. Für einen Dienst, der ggf. gut in der Leistung skalieren muss, sollte man keine Interpretersprache verwenden. Warum nicht C++, D, o.ä.? Gerade bei Perl wäre eine zentrale Frage, warum keine OOP Sprache? Ich könnte wenn ich bei den Interpretersprachen bleibe auch Java, PHP oder Python einsetzen, wobei mir Java und Python direkt die OOP mitliefern. (das wären später Fragen, die z.B. im Fachgespräch kommen könnten). siehe Strukturierte Analyse und das Zitat: Warum nutzt Du eine Technik, die durch eine andere Technologie abgelöst wurde? Du entwickelst also in meinen Augen eine Software nach einem veralteten Modell. Was rechtfertigt dieses Vorgehen? Wie gehst Du z.B. damit um wenn der Dienst auf Nebenläufigkeit, verteilte Strukturen (Webservices, asynchroner Datentransfer) erweitert werden muss? Diese Fragen sind für mich vom Konzept her sehr wichtig, denn Software soll letztendlich auch wartbar / erweiterbar sein. Warum wird also mit einer veralteten Strukturierungstechnik gearbeitet, wenn man es konzeptionell auch anders lösen kann? Gerade diese Punkte sind für mich entscheidend bei dem Projekt. Z.B. bei einer XML Datei kann man via Document Object Model oder Simple API for XML die Daten vollständig oder eventbasiert verarbeiten bzw. durch XPath direkt entsprechende Knoten im XML Baum anspringen. Durch entsprechende Objekte / Klassen kann man hier sehr strukturiert die Daten verarbeiten (teilweise muss man dafür schon selbst keinen Code schreiben, sondern anhand von Modellen der Daten, den dazugehörigen Code automatisch generieren lassen). D.h. hier hast Du schon einige Punkte, die gegen Dein Konzept sprechen. Wie würdest Du das z.B. im Fachgespräch erklären?

Sprachlich ganz dringend überarbeiten, Wörter wie "herausziehen", gehören nicht in den Antrag, ebenso "ich"-Formulieren. Welche "Wege" für das Projekt notwendig sind, das spielt auch keine Rolle. Warum ein "konsolenbasiertes Verarbeitungs-Tool" (auch hier die Wortwahl noch einmal überdenken). Warum muss bei einem solchen Vorgehen überhaupt noch ein Mensch ein Programm starten? Ich werfe mal das Wort "Dienst" in den Raum. Man kann das Problem auch voll automatisieren und nur bei Fehlern das System eine Nachricht genieren lassen. Programmiersprache(n) wird / werden nicht evaluiert oder genannt und das Zielsystem als "Linux" zu bezeichnen ist zu wenig Information, denn ist das eine Sparc, x64, x32 o.ä. spielt für die Entwicklung schon eine Rolle. Welche zusätzlichen Bibliotheken werden für die XML Verarbeitung eingesetzt, ich hoffe, dass überhaupt welche eingesetzt werden. Ich werfe mal Begriffe wie Use-Case, UML in den Raum, das sich alles unter Punkt 3 wieder finden sollten. Im Moment klingt es sehr nach der Entwicklung eines Shell-Skriptes und das reicht fachlich nicht.

Das Script, das die Daten entgegen nimmt kann Linebreaks entsprechend konvertieren und einfügen / ersetzen.

Im Normalfall hat jede Datenbank / Programmiersprache Datumsfunktionen z.b. if (date("month", tabelfield) == 02) alternativ geht es auch andersherum if (between(tablefield, 02-01-2003, 02-28-2003)) entweder extrahiert man den Monat aus dem Tabellenfeld und prüft darauf, oder man prüft auf einen Datumsbereich, d.h. vom ersten Tag des Monats bis zum letzten Tag. Die konkrete Umsetzung ist von dem System abhängig. Grundsätzlich gilt, dass man keine Redundanzen innerhalb der Datenbank speichert, das führt sehr schnell zu Inkonsistenz des Datenstamms.

Aufgrund der Meldung würde ich sagen, dass im Jar File das Manifest fehlt

Die Fehlermeldung ist doch klar und deutlich

Das stimmt zum Teil schon, aber man muss sehen wer die Reports designed. Wenn man davon ausgeht, dass dies ein normaler Anwender ohne entsprechende Kenntnisse macht, dann ist CR durchaus eine sinnvolle Möglichkeit.

Ich kenne List & Label und Chrystal Reports. Sind in meinen Augen beide gute gemacht, wobei ich persönlich lieber XSLT + XML:Fo verwende.

Was willst Du genau machen!? Mails senden geht via Simple Mail Transfer Protocol aber Du musst eben einen Mail Transfer Agent haben, bei dem Du die Mails einlieferst. Einen eigenen MTA aufsetzen wird so nicht funktionieren, weil MX Records zu der Domain benötigt werden, die auf eine nicht dynamische IP zeigen, da Mails sonst von den gängigen Hostern wegen Spam abgelehnt werden. Du musst Dir für Java eben Bibliothek besorgen, die Dir eben SMTP Verbindungen ermöglicht.

Wieso? Sehe ich jetzt nicht das Problem, denn Data Manipulation Language wäre unter Postgres für eine SP: select myproc( parameter )

Hypertext Transfer Protocol

Wörterbuchkompression

Wie man Fragen richtig stellt: eine Anleitung wie man Fragen erfolgreich in Usenet, Mailing Listen und Webforen stellt.

Eine SP kann in Postgres auch ein Resultset liefern, d.h. man kann den Select innerhalb der SP ausführen und das Resultset liefern, wobei dann die SP eine ID o.ä. übergeben bekommt. Wäre halt die Frage was man genau braucht. So wie ich die Frage ja verstehe wird nur genau ein uint Zahlenwert erwartet, nämlich die Anzahl und das kann ich in eine SP auch machen die dann einen uint liefert. Die SP kann ich dann innerhalb des selects, den man eh ausführt verwenden um z.B. dann zu jedem Mitarbeiter die Anzahl als eigenständige Spalte zu liefern. Natürlich geht das auch mit einem Subselect.

Warum baust Du nicht einen passenden View, den Du dann im Grunde wie eine Tabelle handhaben kannst (alternativ ginge auch eine Stored Procedure)

Wenn das Kommentar mit // beginnt und nur bis maximal zum Ende der Zeile geht, kann man es mit Hilfe eines regulären Ausdrucks entfernen, bei Blockkommentaren wie /* ... */ geht dies nicht mehr, da die Sprache eine Dyck-Sprache ist und nur durch eine Kontextfreie Grammatik verarbeitet werden kann.

Du möchtest vielleicht erst einmal eine Suchmaschine Deiner Wahl verwenden und dort mal nach "Android Widget" o.ä. suchen. Es gibt dafür unzählige Tutorials

Ein einfacher Scan über den IP Range reicht um Deinen Server zu finden.

Einen eigenen Server online zu betreiben ohne das notwendige Wissen zu besitzen ist fahrlässig. Sollte der Server nicht sicher betrieben werden und damit als offenes Relay oder Server für illegale Inhalte missbraucht werden, haftest Du. Nicht-Wissen schützt nicht vor Strafe. Miete Dir entsprechenden Webspace und lege dort Deine Daten ab.

Umwandeln geht nicht, Du musst die GUI, wie schon geschrieben, mit "Android Widgets" erstellen. Tutorials dafür findest Du im Netz

Das Problem ist, so wie Du es schilderst, kann ich es nicht sinnvoll bewerten, denn einmal sprichst Du relativ viel von Programmierung, was dann definitiv nicht zu Deinem Ausbildungsberuf passt, auf der anderen Seite kann man dadurch aber auch sicherlich was kaufmännisches machen, nur dafür musst Du mal einen Antrag vor formulieren. Die Geheimhaltungsvereinbarung kannst Du ja trotzdem beachten. Ich denke mal ohne jetzt Details zu kennen, das man aus dem Problem für beide Berufe ein Projekt machen kann, der Kernpunkt ist dann wirklich der Antrag

Das fällt eher unter den Bereich des FIAE. ein reines Programmierprojekt ist für den Ausbildungsberuf im Grunde am Thema vorbei. Mach mal einen groben Projektantrag, wie Du Dir das vorstellst, dann kann man sich ein besseres Bild machen