Projekt Fibu/WaWi System für Linux - Programmierer gesucht !

Dieses Thema im Forum "Member Talk & Offtopic" wurde erstellt von devilz, 26.08.2004.

  1. devilz

    devilz Pro*phet
    Administrator

    Dabei seit:
    01.05.2002
    Beiträge:
    12.244
    Zustimmungen:
    0
    Ort:
    Hessen
    Projekt Fibu/WaWi System für Linux - Wer macht mit ?

    Also ...

    ich suche für ein Projekt Programmierer (qt/mysql/etc) die Interesse haben an einem Warenwirtschaftssystem für Linux mitzuarbeiten.

    Die Idee ist LEIDER aus dem Problem entstanden, das es keine vernünftige Software in diesem Bereich gibt.

    Zwei Projekte versuchen diese Nische bereits zu füllen, aber leider sind das keine alternativen zu Lexware, WinOffice Pro & co. !
    (Zum einen gibt es Tudo - http://www.bemme.de welches mehr als Umständlich ist und zum anderen LX-Office - http://www.lx-office.org was auf einer Webserver Lösung realisiert wurde.)

    Es fehlt einfach eine WaWi/Fibu Lösung für den Mittelstand der einfach ist und trotzdem alles beinhaltet damit ein 1-2 Mannbetrieb damit arbeiten kann.
    (Keine Webserver Lösung und vielleicht statt mysql auf Flatfiles basierend)

    Vielleicht haben einige Interesse an dem Projekt ?

    Kontakt am besten per PN oder eMail (sven_at_unixboard.de)

    gruß dev


    PS : Am besten wäre ein Port von WinOffice Pro - Demoversion gibts hier -> http://www.bitspaper.net/bpstore/software/ShowSW.aspx?id=1
     
  2. Anzeige

    Schau dir mal diese Kategorie an. Dort findest du bestimmt etwas.
    Registrieren bzw. einloggen, um diese und auch andere Anzeigen zu deaktivieren
  3. #2 atomical, 26.08.2004
    atomical

    atomical castor transporteur

    Dabei seit:
    11.11.2003
    Beiträge:
    133
    Zustimmungen:
    0
    Für diese Größenordung fehlt mir leider die Praxis und auch die Zeit :rolleyes: - aber ein paar Anmerkungen hätte ich, da ich jobmäßig häufig mit den Problemen der kleineren Unternehmen und ihren Fibus / .. in Kontakt komme ...


    ... auch in kleineren Betrieben kommt - wenn es denn gut läuft - schnell mal ein Arbeitsplatz dazu - die Daten sollen natürlich gemeinsam genutzt werden ... warum also nicht auf ein existierendes Datenbanksystem zurückgreifen, wo die für Mehrplatzfähigkeit erforderlichen Mechanismen gleich mit drin sind?

    ... in einer FiBu / WaWi macht man fast alles mit Tastatur - also sollten auch alle Funktionen per Tastatur erreichbar sein (ncurses alike ;) - vielleicht sogar ein Frontend auf dieser Basis :finger: ) ... auf jeden Fall würde ich es nicht von irgendeinem Toolkit oder gar von einer DE abhängig machen ...

    ... wenn man die Trennung Oberfläche zu eigentlichem Programm sauber hinbekommt hat man imho eher Chancen, als Projekt ernst genommen zu werden


    .... /me wird sich (war sowieso geplant) - wenn Zeit ist - mal mit ncurses beschäftigen ich meld mich dann wieder :devil:
     
  4. #3 lordlamer, 27.08.2004
    lordlamer

    lordlamer Haudegen

    Dabei seit:
    15.05.2003
    Beiträge:
    703
    Zustimmungen:
    0
    Ort:
    hamburg
    hallo!

    ich hätte interesse da ich sowas auch schon fürs web im kleinen mache: webkalk.linuxdelta.de . wäre toll wenn du mir deine planungen mal zuschickst und so. vielleicht kann man ja webkalk und das dann zusammen verbinden bzw auf der selben db aufbauen?! naja meld dich mal.

    frank
     
  5. devilz

    devilz Pro*phet
    Administrator

    Dabei seit:
    01.05.2002
    Beiträge:
    12.244
    Zustimmungen:
    0
    Ort:
    Hessen
    Also als Basis wird qt/mysql verwendet.

    Ich habe schon grobe Entwürfe in dieser Richtung ....

    Soll nichts großes werden, aber jeder der Lust hat mitzuwirken ist willkommen.

    gruß dev
     
  6. #5 lordlamer, 27.08.2004
    lordlamer

    lordlamer Haudegen

    Dabei seit:
    15.05.2003
    Beiträge:
    703
    Zustimmungen:
    0
    Ort:
    hamburg
    ja und lust habe ich. könnten ja unsere erfahrungen austauschen. kann dir ja auch diesbezüglich webkalk vorstellen und wie ich das aufgebaut habe. wäre es für dich auch denkbar das mit meinem webkalk vielleicht in verbindung zu bringen?

    mfg frank
     
  7. etuli

    etuli Betrunken

    Dabei seit:
    12.04.2003
    Beiträge:
    278
    Zustimmungen:
    0
    Verstehe auch nicht, warum man das System durch QT auf KDE beschraenken sollte.
     
  8. devilz

    devilz Pro*phet
    Administrator

    Dabei seit:
    01.05.2002
    Beiträge:
    12.244
    Zustimmungen:
    0
    Ort:
    Hessen
    Es geht darum das ich das Programm möglichst einfach halten möchte.
    Und da KDE nunmal DAS DE für Linux ist, wird das nunmal darauf basieren.

    LX-Office basiert z.B. auf nem Webserver, DA haste das was du suchst.
     
  9. etuli

    etuli Betrunken

    Dabei seit:
    12.04.2003
    Beiträge:
    278
    Zustimmungen:
    0
    Ich sage nicht, dass eine verteilte Client/Server Loesung besser ist. Sie hat Vorteile, wie auch gravierende Nachteile. Jedoch heisst das nicht, dass nicht eine GTK Loesung in Frage kommt, oder?

    Zumal ... es ist schwer Entwickler fuer eine Software zu finden, die nach den Wuenschen eines Unternehmens gefertigt wird.
     
  10. #9 lordlamer, 27.08.2004
    lordlamer

    lordlamer Haudegen

    Dabei seit:
    15.05.2003
    Beiträge:
    703
    Zustimmungen:
    0
    Ort:
    hamburg
    was würde dagegen sprechen wenn man es auch übers web machen könnte zusätzlich zur desktopversion? dann ist man halt nicht so gebunden.

    wie hast du dir das mit der db vorgestellt und was soll die software nun wirklich alles machen können?

    mfg frank
     
  11. etuli

    etuli Betrunken

    Dabei seit:
    12.04.2003
    Beiträge:
    278
    Zustimmungen:
    0
    Wie gesagt. Beide haben Vorteile. Aber es faengt schon mit der zu verwendenden Sprache an. Fuer die QT Variante wirst du vermutlich C++ verwenden. Fuer die Web Variante PHP, oder Java.

    Dann ist der Aufbau der beiden Anwendungen grundverschieden. Die Desktop Anwendung ist ein einzelnes Programm, welches auf Ereignisse reagiert. Die Web Anwendungen ist Aktionsbasiert. Besteht dann entweder aus einzelnen Artefakten die bestimmte Teile der Anwendungslogik implementieren, oder aus einer Anzahl von koordinierenden Objekten, welche Anfragen verarbeiten.

    An die Web Anwendung werden anderen Anforderungen gestellt. Die Darstellung funktioniert essentiell anders als bei Desktopanwendungen. Du brauchst ein Session-Management, ... .

    Das einzige, was die beiden System wirklich gemein haetten waere, waere der Problembereich und entsprechende Objekte. Da koennen dann Entwicklungen fuer beide Varianten genutzt werden. Aber sonst eher weniger. Letztendlich wuerde es zwei Systeme geben, die zwar das gleiche koennen, aber grundsaetzlich verschieden funktionieren. :)

    mfg
     
  12. thorus

    thorus GNU-Freiheitskämpfer

    Dabei seit:
    03.11.2002
    Beiträge:
    757
    Zustimmungen:
    0
    Ort:
    Passau, Niederbayern
    Ich würde vorschlagen, alle Funktionen in einer Library unterzubringen und dann Frontends dazu zu entwickeln.

    Nun, warum.. ganz einfach: Verschiedene Distributoren setzen auf verschiedene Desktop-Environments. Während beispielsweise SuSE eher KDE bevorzugt, ziehen Sun, IBM und andere eher Gnome vor. Da kleinere Unternehmen auf jeden Fall auf Support angewiesen sind, sollte man ihnen in diesem Zusammenhang nicht die Grundlage für Support wegnehmen. Sie haben sich für eine Firma entschieden und meistens wollen sie, denke ich mal, da auch bleiben. ;)
    Denn wozu QT installieren, wenn man ein Desktop-Environment hat, das auf GTK aufbaut?
    Und die Verwendung eines anderen Toolkits stiftet auch nur Verwirrung bzgl. des Designs.

    Alternativ könnte man statt der Library auch einen Daemon implementieren, den man dann beispielweise per TCP/IP ansprechen kann. So könnte man auch sehr unproblematisch Java-Clients oder ähnliches implementieren.
    Aber eine solche Lösung ist denke ich nur für größere Firmen relevant.

    Ich arbeite zur Zeit während den Sommerferien in einer Softwarefirma, die u.a. Verwaltungssoftware für Versicherungen herstellt. Da kommt aus den genannten Gründen eine solche Trennung zwischen Server und Client zum Einsatz.
    Denn das Problem bei den Versicherungen ist, dass nicht auf allen Clients Windows läuft, aber beispielsweise Java-Clients weitgehend plattformunabhängig einsetzbar sind.
     
  13. etuli

    etuli Betrunken

    Dabei seit:
    12.04.2003
    Beiträge:
    278
    Zustimmungen:
    0
    Jein. Die Library selbst muesste dennoch in verschiedenen Implementierungen vorliegen. Brauchen tust du dazu dann erstmal ein (Software-)Design, welches sowas beruecksichtigt. PHP4 und C++ zu vereinigen etwa ist Schmerz. Reiner Schmerz. Man muesste sich schon im Vorweg auf die spaeteren Umsetzungen einigen. PHP5 und C++ waere schon eher denkbar. Kommt aber auf das Objektmodell des Problembereichs an. Kenne mich in Finanzbuchhaltung grob geschaetzt garnicht aus.

    Die Library wuerde dann vermutlich auch sehr allgemein werden. Grundlegende Verwaltung der Informationen halt, um ja keine moegliche Anwendung auszuschliessen.

    Sehe ich aehnlich.

    Ist die Frage, ob sich da lohnt. Das gtk-gnutella Projekt arbeitet schon seit geraumer Zeit an einer Trennung von Core und GUI. Und wenn ich da den Aufwand sehe ein geeignetes Interface zu abstrahieren, lohnt sich der Aufwand bei dieser Anwendung eher nicht.

    mfg
     
  14. JoBi

    JoBi Eroberer

    Dabei seit:
    17.07.2003
    Beiträge:
    63
    Zustimmungen:
    0
    Ort:
    Regensburg
    Warum nicht die Programmlogik soweit wie möglich in die Datenbank verlagern? Das würde die Programmierung eines jeden Fontends vereinfachen.
    PostgreSQL würde diese Möglichkeit bieten, Stored Procedures zu verwenden und läuft äußerst stabil.

    Gruß, Jobi
     
  15. Anzeige

    Vielleicht findest du HIER Antworten.
    Registrieren bzw. einloggen, um diese und auch andere Anzeigen zu deaktivieren
  16. #14 lordlamer, 27.08.2004
    lordlamer

    lordlamer Haudegen

    Dabei seit:
    15.05.2003
    Beiträge:
    703
    Zustimmungen:
    0
    Ort:
    hamburg
    sehe ich auch ähnlich das sich das mit dieser libary nicht so lohnt. das meinte ich auch garnicht so. ich würde da halt 2 projekte draus machen dann. also einmal webbasiert und einmal gui dann. ich finde es auch garnicht so schlimm das es in qt programmiert ist. es soll ja nicht eine so grosse software werden. und für den anfang find ich es auch voll ok und weiss auch net wo das problem liegt.

    mfg frank
     
  17. #15 thorus, 27.08.2004
    Zuletzt bearbeitet: 27.08.2004
    thorus

    thorus GNU-Freiheitskämpfer

    Dabei seit:
    03.11.2002
    Beiträge:
    757
    Zustimmungen:
    0
    Ort:
    Passau, Niederbayern
    An PHP hab ich dabei eigentlich nicht gedacht. Man könnte aber zwischen der Library und PHP noch ein Wrapper schieben. Die Frage ist aber, ob sich das wirklich lohnt...

    An das hab ich auch gedacht.
    Prinzipiell müsste die Lib ja nur Informationen holen, abspeichern und berechnen.

    Sowas wird beispielsweise von giFT oder mldonkey von schon Anfang an eingesetzt. Man will bei diesen Projekten hier einfach eine Fernwartung erlauben.

    Da muss man sich halt jetzt die Frage stellen, wie groß das Programm werden soll bzw. in welchen Unternehmen das primäre Einsatzgebiet ist.
    Sobald mehrere Personen einer Datenbank herumpfuschen ist das Management mit einem eigenen Daemon auf einem anderen Server viel unkomplizierter zu realiseren. Man kann beispielsweise einfacher und schneller Locks verwalten, damit keiner sich in die Quere kommt.

    Definitiv eine gute Idee, aber zwischen der DB und den Frontends ist trotzdem ein Lib nicht schlecht, da sonst wieder Code doppelt geschrieben werden muss.
    Außerdem sollte man auch dem User die Option lassen, ein anderes DBMS zu verwenden und da ist eine weitere Abstraktionsschicht sehr praktisch.

    2 Projekte? Und dann schön Copy&Paste machen, oder?
    Auch wenn es nur ein kleines Programm wird ist das die denkbar schlechteste Lösung. Sobald irgendwas geändert werden muss, müsste man das in beiden Trees tun, die dann wieder nicht exakt identisch sind, und, und, und...
    Das ist einfach ein logistisches Problem.

    Auch wenn es als kleines Projekt angedacht ist, sollte man eine gewisse Übersicht walten lassen. Du wirst dafür später sehr dankbar sein, falls aus dem Projekt mal mehr werden sollte.
     
Thema:

Projekt Fibu/WaWi System für Linux - Programmierer gesucht !

Die Seite wird geladen...

Projekt Fibu/WaWi System für Linux - Programmierer gesucht ! - Ähnliche Themen

  1. Eine Million Euro für Open-Source-Projekte

    Eine Million Euro für Open-Source-Projekte: Die Internet Foundation Austria will auch 2016 wieder zahlreiche Projekte mit bis zu 50.000 Euro sowie wissenschaftliche Abschlussarbeiten mit bis...
  2. Devuan-Projekt veröffentlicht erste Beta

    Devuan-Projekt veröffentlicht erste Beta: Das Projekt Devuan hat eine erste Beta-Version seines Forks von Debian ohne Systemd herausgegeben. Weiterlesen...
  3. Debian-Projekte zum Google Summer of Code 2016

    Debian-Projekte zum Google Summer of Code 2016: In insgesamt zehn Projekten schickt Debian 25 Teilnehmer zum GSoC 2016, vier weitere arbeiten im Rahmen des Outreachy-Programms. Die Projekte...
  4. Mehdi Dogguy zum Debian-Projektleiter gewählt

    Mehdi Dogguy zum Debian-Projektleiter gewählt: Mehdi Dogguy wurde zum neuen Debian-Projektleiter gewählt. Das ergab die jetzt beendete Wahl unter den Debian-Mitgliedern. Da er der einzige...
  5. Projekt LibreELEC gegründet

    Projekt LibreELEC gegründet: Die meisten Entwickler der Multimedia-Distribution OpenELEC haben anscheinend das Projekt verlassen und LibreELEC ins Leben gerufen. Grund für den...