metux

Um welche Datenvolumen und Änderungsraten gehts eigentlich ? Wie hoch ist die im Desasterfall tolerierbare downtime ?

Venti: a new approach to archival storage

Warum unbedingt ***-Zeugs ? Tätes eine Asterisk nicht auch ? (gibts übrigends auch als fertige ready-to-go appliance)

Frag doch mal bei den gängigen Großhändlern an.

Wenn sie nicht zu groß sind (max. 1/2 Seite) würd ich sie direkt in den Text einbetten.

Da wäre es durchaus hilfreich, mal andere Tracker-Systeme, zB. Bugzilla, Redmine, Trac, usw, zu evaluieren. Diese haben idR. einen gewissen Ticket-Workflow, mit dem man die Bearbeitungszustände abbilden kann. Bei Redmine ist das aktuell noch sehr rudimentär, aber das werd ich mir vorraussichtlich im Q2 mal eingehend vornehmen (evtl. sogar eine generische Workflow-Engine dafür andocken, mit der auch komplexe WF's abbilden kann).

Was spricht denn dagegen, Doxygen entsprechend auszubauen ? Wäre mir neu, daß doxygen damit Probleme hat ;-o

Warum kopierst Du alle Strings um, anstatt einfach den Index weiterzuzählen?

Nunja, TFS für Sourcecode zu verwenden halte ich für keine sonderlich gute Idee.

Ruf am besten mal bei xtivate an und schau was sie dir anbieten: Impressum - xtivate Als Firmware reicht vielfach OpenFiler voll und ganz aus, wenns komplexer wird (HA, udgl.) würd ich openE oder collax empfehlen. Wer selbstbauen will, kann sich natürlich auch die Distro seiner Wahl (meinetwegen auch Gentoo ;-)) installieren.

Nein, diese zwischendurch-Commit gehören dann in eine temporäre Branch, die später nochmal mit interaktivem Rebase wieder aufgeräumt wird (dh. also evtl. commits zu logisch konsistenten Einheiten zusammenfassen und ggf. unnötige Änderungen wieder wegräumen). Wichtig zu verstehen ist, daß ein VCS nicht einfach nur eine Bearbeitungshistorie ist, sondern auch eine längerfristige Dokumentation des Entwicklungsverlaufs (dh. man kann später jederzeit nachschauen was warum geändert wurde). Insofern ist es auch wichtig, die History möglichst linear zu halten, damit zB. Operationen wie bisect gut durchlaufen können.

Via commit-hook ? Ein wenig tricky daran ist, daß man vorraussetzt, ein commit gleich den bug komplett fixt. Bei kleineren Bugs ist das sicher voll ausreichend, aber bei komplexeren Problemen (insbesondere wenn wir nicht nur bugs im engeren Sinne, sondern auch feature-requests udgl. mit einbeziehen) könnte das schnell für ein wenig Durcheinander sorgen.

Um welche Art Messungen/Daten gehts denn ? Bei statischer Lungenfunktion (Voumen/Fluß) kann ich Dir ein wenig weiterhelfen. (hab das vegangene Jahr an einem klinischen Meßcomputer für solche Dinge gearbeitet, der dann für klinische Studien jeweils angepaßt wurde).

Reklamationserfassung ? Das sind Informationen die direkt für den Kunden/User gedacht sind ? Dazu bietet sich ein entsprechendes Changelog-File direkt in der Codebase an (daraus kann man ja andere Dokumente automatisch generieren). Informationen die für den Tester sind, würde ich grundsätzlich im Ticket erfassen, bevor es an den Tester weitergegeben wird. Dieser sollte dann auch bei Bedarf entsprechend die Testpläne anfassen. Die Changes im VCS sollten jeweils in sich konsistent sein (also genau eben ***NICHT*** einmal pro Tag oder vor der Pause committen !) und den Zweck der Änderung kurz und knapp beschreiben. Gehört ins Ticket. Für sowas gibts doch Ticketsysteme. Ja, aber bitte Doxygen-Kompatibel und nur die wichtigen Dinge, die nicht ohnehin selbsterklärend sind. Ahja, und die Änderungen kommentiert man nicht im Sourcecode, sondern im VCS. Und vorallem enorm teuer ! hmm, da gäbs auch noch Redmine, Trac, Bugzilla. In der commit-Message im VCS, damit man das dann automatisch verknüpfen kann. Aber *NICHT* im Sourcecode. Unterschiedlich. Hängt stark von der Projektgröße und der Release-Dichte ab. Jain. Ich habe bisher noch keine Toolumgebung gesehen, die alle benötigten Workflows direkt abbilden konnte. Ergo muß man sich da vieles Projektspezifisch selbst zusammenstellen/-bauen.

Die Exonas-Kisten wären vielleicht noch einen Blick wert.

Interessant bei einer solche Studie wären neben den bereits erwähnten Migrations- und Schulungskosten die lanfristigen Wartungs- und Betriebskosten gegenüberzustellen. Da, wie Du schreibst, bei Euch die IT-Abteilung aufgelöst wurde, wäre auch die Frage zu beantworten, wer das System langfristig dann pflegen soll (internen MA ggf. schulen ? externer Dienstleister ?).

Da denk ich doch gleich an Doxygen ... An der Stelle würd ich Dir raten, Dich neben der eigentlichen Dokumentationsgeschichte auch mit den Dahinterliegenden Workflows zu beschäftigen: wie arbeiten die Leute aktuell und wie könnte man es besser machen (unter Zuhilfenahme Deiner zu entwickelnden Tools). Dabei dann vielleicht auch mal eine vorsichtige Schätzung wagen, wieviele Resourcen damit zukünftig eingespart werden könnten.

Also ich weiß ja was die IHK da haben möchte, aber als Unternehmer würde ich das bei einem Kandidaten äußerst positiv bewerten.

Nun, ich kenne da einige, die zB. 3 Mio Accounts mit Zimbra betreiben. MS-Exchange kann da einfach nicht mithalten. Sendmail trifft man in der Praxis häufiger, besonders bei etwas komplexeren Setups in der klassichen Unix-Welt. Gerade wenn andere Systeme wie UUCP andocken will, geht das ganz gut.

Du meinst, sowas wie patches ?

* Man kann schön im VS clicken und bunte (wenngleich auch nichtssagende) Reports rauswerfen * Wird zusammen mit mit VS verkauft, und ggf. kommen auch ein paar Jungs in guten Anzügen mit vielem bunten Papier vorbei * Es rechtfertigt eine eigene Planstelle nur für die reine Administration * Man kann viele schöne enterprisige Dinge, die jeden Bürokratieapparat das Wasser im Mund zusammenlaufen lassen * Eingebauter Überarbeitungsschutz für die Benutzer, weil immer genügend Zwangspausen

Ihr meint sicher einen professionellen application service provider, der entsprechende Datensicherheit und 24/7-Verfügbarkeit vertraglich garantiert. (letzteres ist mit TFS alles andere als trivial - das Ding neigt inherent zu Inkonsistenzen und Datenverlusten)

Nunja, "beim mergen fehler macht" ist ja ein grandioser Euphemismus. Ich finds übrigends sehr spannend, mal ***'s eigene Papers zu lesen, in denen zuweilen auch von Branching abgeraten wird, weil's doch viel zu kompliziert ist. Einen ähnlichen Tenor schlagen teils auch die Blogs der TFS-Entwickler an. Ja, *** hat begriffen, daß TFS ziemlich, äh, suboptimal ist (immerhin !). Gut, der Fairness halber muß man sagen, daß die Workflow-Engine (so man sie beherrscht und richtig configuriert) schon eine gute Sache ist, aber das VCS-Anhängsel ist halt ziemlich miserabel. Bei *** selbst denkt man ja schon eine Weile darüber nach, sich mehr an SVN zu orientieren. Vom Regen in die Traufe ... ;-o

SVN repos kann man auch ganz gut remote mit git sichern.

Ich kann Dir einen guten Therapeuten empfehlen.