Grösseres open Source Projekt starten

[ComFreek]

[...] sondern vielleicht einfach einen einzelnen Bug verbessern und einreichen

Und bevor ich 10 systemweite Abhängigkeiten kompilieren und installieren muss, nehme ich lieber eine VM, deren Image in 10min geladen ist und in 5min provisioned Ich habe mal die schlechte Erfahrung bzw. wurde regelrecht davon gebrandmarkt gemacht, dass ich allein für das Installieren und Kompilieren aller Abhängigkeiten (nebenbei) > 1 Woche benötigt habe. Dort war leider alles von vorn bis hinten kaputt. Als ich schließlich alles in einem Provisioning-Skript zusammengefasst habe, dauerte das unbeaufsichtigte Kompilieren nur noch 10min. Wie du richtig sagst, zuzüglich VM Basisimage Download.

Während ich bei meinen Floss-Beiträgen noch auf keinen VM/Docker-Zwang gestoßen bin, würde ich einen (nicht weltbewegenden) Bug in so einem Fall sicher nicht mehr selbst ausbessern.

Umgekehrt bekomme ich Bedenken bei README Aussagen à la "Windows/Mac OS Support experimental/untested" und "You need to compile [insert >= 10 libaries] yourself [...]" oder "In case of error XYZ during compilation, do..."

Zurück zum Thema:

Thema Client / Server kommunikation auf Java Basis - ohne Cloud ,ohne Javascript -
statt Browser - JavaFX.

So ganz verstehe ich das nicht. Die "Cloud" besteht doch gerade aus Servern. Könntest du einen konkreten Anwendungsfall erläutern?

 

[sheel]

1 Woche benötigt habe

Das sind dann die angesprochenen Fälle, wo es Sinn macht

 

[melmager]

Naja ich bin in einem Alter wo ich "Cloud Gedöns" nicht so prickelnd finde.
Bei mir geht es eher um eine kleine Anwendung für ein Handwerksbetrieb und da ging es eher um das Thema
Stundenzettel / Arbeitsnachweis in elektronischer Form und welche Geräte lagern auf welcher Baustelle.
Da habe ich mir doch gedacht wenn schon - warum nicht gleich in Echtzeit ? Und der Server ist eh schon da
Also warum Geld ausgeben für ein Cloudservice.
Möglichkeiten sowas umzusetzen:
Tabelle auf Client - und abends im Büro werden Daten ausgetauscht. (das wird es wenn es nicht anders geht)
Basierend auf einen Browser - beim Server (ich bleibe mal bei Java) Tomcat / JSF
- keine Laufenden kosten aber auf Clientseite Javascript (Angular oder ähnlich)
Oder wo ich drüber gestolpert bin: Gluon Mobile - Java FX auf dem Client - Nachteil das ist darauf ausgelegt das man deren Cloudservice bucht (siehe oben) aber die grundidee - weg vom Browser und FX (also Java pur) auf dem Client das hat was - schwärm
So zum konkreten Teil: Am Client wurde ein Button gedrückt - Bohrhammer verbleibt auf Baustelle
(mal eine stark vereinfachte Darstellung) Die Action wird an den Server übermittelt und in der Bestandsliste (actionlistener) im Büro wird ein Bohrhammer ausgebucht.
Normal ist ja das Action und der Listener, der drauf reagiert im gleichen Programm agieren. Ich möchte einfach die räumliche Trennung. Aber immer mit Java.
siehe ersten Satz im ersten posting

 

[sheel]

Mir kommt es so vor, dass wir nicht von der selben Definition von Cloud reden.
Es hilft dabei auch nicht, dass viele Stellen wo man das Wort hört/liest Marketingergüsse sind, die von Leuten geschrieben wurden, die auch keine Ahnung haben.

"Cloud"-Verwendung im originalen Sinn ist nichts, was die Benutzer eines Programms auch nur irgendwie merken. Und das bei irgendeinem Softwareprodukt als Vorteil aufzulisten, so wie es sehr viele Firmen machen, ist komplett sinnbefreit.

Um mal von deinem Server auszugehen: Die mietest dir bei einem Hoster
a) entweder eben einen ganzen Server (bzw. evt. eine VM, in der du Root-Zugang hast - meistens kommt man nicht auf den rohen Server), mit x Speicherplatz und y Leistung, mit dem du machen kannst was du willst. Zugang per SSH. Kaputte Festplatten usw. werden vom Hoster ausgetauscht, Strom und Internetzugang bereitgestellt usw., aber der Rest in deine Sache.
b) oder du mietest dir eine "Plattform" für zB. Webseiten mit PHP, Webseiten mit Tomcat, reiner Speicher der per SFTP zugreifbar ist, einen SMTP-Zugang zum Mailsenden, und/oder ähnliches. Beim PHP-Websietenbeispiel bekommt man dann zB. einen SFTP-Zugang bei dem man Dateien bereitstellen kann, PHP wird am Server ausgeführt, und die Dateien sind per HTTP von Clients aubrufbar. Wenn PHP etc. nicht läuft ist das in dem Fall auch das Problem des Hosters, und nicht deins.
c) oder ein fertiges lauffähiges Programm, zB. bei wordpress.com kann man sich einen Wordpress-Blog anlegen. Man muss sich nicht um den Server kümmern, man muss sich nicht um PHP kümmern, man bekommt einfach den Bllog mit Limits für Speicherplatz und Traffic.

Was würde diese Sachen jetzt zur Cloud machen? Nur eins: Es gibt keine direkten Limits, sondern höherer Verbrauch erzeugt einfach höhere Rechnungen (falls es was kostet). Der Hoster sorgt dafür, dass du für deine Sachen immer genug Leistung hast. Von hinten nach vorn im Detail:
c) Man hat ein Uploadlimit von 1GB für Bilder gratis (Beispiel), jeder weitere verbrauchte GB koste xy Cent im Monat. Wenn man Bilder löscht geht der Geldbetrag auch wieder runter. Die Blogbesucher merken überhaupt keinen Unterschied, ob da jetzt ein einzelner Server oder eine "Cloud" am Werk ist. (Außer, dass man sich bei sehr großen Bildersammlungen evt. denken kann, dass da keine inzelner Computer reicht).
b) Wenn man an die Limits von Speicher und/oder Traffic seiner PHP-Webseite kommt, mmuss man entweder aufhören Dateien zu adden und mit einer verlangsamten Seite leben, oder der Hoster gibt dir eine größere Festplatte und/oder mehr Anteil am Internetzugang des Rechenzentrums. Kostet natürlich. Vorgehen auf Hosterseite wie bei a:
a) Hier an das zB. Speicherlimit zu kommen wird damit gelöst, dass dein Dateisystem nicht mehr auf der Festplatte liegt, sondern eine Art "Netzwerklaufwerk" ist, bei dem mehrere Geräte voll mit Festplatten zusammen den Inhalt liefern. Der Hoster hat ziemlich viel davon, und wenn dein derzeitiger Verbrauch noch weiter steigt, werden dir noch ein paar weitere Festplatten irgendwo zugeteilt. Kostet natürlich wieder mehr. Und wieder merken die Benutzer deiner Webseite etc. am Server gar nichts davon, wie viel Festplatten da beteiligt sind.

...
Nochmal wiederholt, "Cloud" ist einfach die automatisierte Zuweisung von Resourcen je nach Verbrauch. Das ist der einzige Unterschied zum normalen Server/Hosting.
Was irgendwelche Programmbenutzer sehen und machen können hat damit nichts zu tun. Und als PHP/Javaprogrammierer einer Serveranwendung kann dir das auch egal sein. Einen Unterschied machts erst dann, wenn du dich um das Betriebssystem, Dateisysteme usw. kümmern musst

...

Beispiel Owncloud usw. (ein reines PHP/Mysql/Apache-Konstrukt): Irgendwo auf einen Server installieren und über den Browser Files syncen hat absolut nichts mit Cloud zu tun.
Wenn man noch ein paar Server aufsetzt, bei denen die gsamte Festplatte per SMB/NFS als Netzlaufwerk erreichbar ist, das am Hauptserver per GlusterFS zusammengefasst einrichtet damit alle Server zusammen wie ein einzelner Ordner ausschauen, und Owncloud die Dateien dort hinspeicher lässt, dann wirds schon besser. Dazu noch automatische Messungen, welche deiner x Ownloudbenutzer wieviel Speicher brauchen, und fertig ist die Cloud.

 

[melmager]

@sheel Natürlich ist hinter dem Word Cloud viel Marketing Sprech
Was schon mal nicht stimmt ist die Aussage das durch Cloudeinsatz (in welcher Form auch immer)
Kosten gespart werden.
Was ich auch sehe ist das es eine dynamische Ressource ist, was aber auch ein dynamischen Preis folgen lässt.
Was auch der Grund ist warum ich das nicht so prickelnd finde. Lustigerweise sind bei einigen
Serveranbietern ein Cloudserver teurer wie ein vergleichbarer root Server - soviel zu Marketing
MobileFX nutzt übrigends MBaas. (no comment)

Gut ettliches im IT bereich kapiere ich eh nicht - aber dat ist mein problem
Dazu gehört auch warum Client / Server Anwendungen mit http Protokoll arbeiten und viele auch
als Frontend ein Browser einsetzen was dann meist zum Javascript Zwang führt.

Zurück zu meiner Idee:
Auf der Internetverbindung möchte ich mit XML arbeiten. Ja ich weiss Json ist kleiner im Overhead - aber auch nicht so flexibel wie xml. Und mal erlich wir leben in Zeiten wo Kinofilme gestreamt werden und da reden wir über KB unterschiede. Die Button Action wird also in XML gewandelt
dann übermittelt und auf der andren seite dafür gesorgt das der Listener die Daten bekommt.
Ein paar Ideen werde ich von rest übernehmen nur das es nicht auf das http protokoll aufsetzt.
Und das die Gegenrichtung auf dem gleichen Weg arbeitet. Gleiches Protokoll egal welche Richtung und nicht HTML hin und Json oder Post zurück.

Am wochenende werde ich mal ein entwurf machen und drüber nachdenkenob die grundidee machbar und pratikabel ist

 

[sheel]

Lustigerweise sind bei einigen Serveranbietern ein Cloudserver teure

Weil es beliebig viele Manager etc. gibt die sagen "oooh, Cloud, das ist noch viel besser als so ein alter Server" und dafür auch gern mehr bezahlen

Und mal erlich wir leben in Zeiten wo Kinofilme gestreamt werden und da reden wir über KB unterschiede.

...allerdings hat nicht jeder Geld für Server, die sowas auch mit vielen Kunden machen können. Und 1KB für Millionen Anfragen pro Minute ist auch was

 

[ComFreek]

Ein paar Ideen werde ich von rest übernehmen nur das es nicht auf das http protokoll aufsetzt.

D. h. du möchtest einen Dienst oberhalb der Transportschicht (TCP oder UDP) aufsetzen? Die Kommunikation erfolgt dann über Öffnen eines Sockets zu der IP (ggf. über den Hostnamen per DNS) und Senden des rohen XMLs als Bytefolge.

Idealerweise abstrahierst du mit einer weiteren Schicht auch darüber, ob nun XML verwendet wird oder nicht. Dann kannst du es später auch austauschen.

als Frontend ein Browser einsetzen was dann meist zum Javascript Zwang führt.

Weil du für Java immer deine Java VM benötigst. Wenn du kein Tablet mit einem "richtigen" Betriebssystem wie Linux/Windows/Mac OS hast, sondern eher ein app-basiertes wie Android, kannst du nicht einfach ein generisches Java FX Programm ausführen, sondern musst es erst in eine App konvertieren. Die App musst du bei jedem Update neu ausliefern (lassen).
Im Gegensatz dazu laufen Websites fast überall und du kannst deine Website vollkommen transparent aktualisieren - bis auf Cacheeffekte, die du jedoch kontrollieren kannst.
Das Problem an JS kann ich nicht nachvollziehen, was genau sind da deine Gründe?

 

[melmager]

Kalauerkiste auf:
F: "Was hast du gegen JS"
A: "Nichts wirksames"
Kalauerkiste zu.

Im Ernst ich habe wirklich nichts gegen JS, aber wenn es möglich ist das ein Programmierer NodeJS ausser
Funktion setzt weil er ein Programmschipsel löscht - tritt schon mal ein das generelle Problem auf wenn
LIBs zu Laufzeit nachgeladen werden müssen und die Quelle im Internet liegt; man kann nie sicher sein ob man das bekommt was man erwartet. Das hat mich dann doch ins Grübeln gebracht.
Ok man kann auch mit LIBs arbeiten die local vorhanden sind, aber dann hat man ein Problem wenn der Server ein andres Release wie das lokal installierte braucht - dann muss halt jemand Handanlegen - Frei nach dem Motto irgendwas ist immer
ganz davon ab (was jetzt nix mit JS zu tun hat) das die Browser immer noch nicht untereinander Kompatibel sind.
Und JS setzt auch ein OS voraus auf dem Potenziell auch Java installiert sein könnte . bzw im Falle von Android
die Grundlage ist - Ok IOS ist da Außen vor - was mich nicht wirklich stört.

Das Hauptproblem ist doch das es immer eine Lib braucht die unterschiedliche Systeme an eine gemeinsame API
anzupassen. Das hat mich ja an MobileFx von Gluon so begeistert. Die schreiben eine Zwischen Schicht (LIB) und als Programmierer hast du nur noch die FX Api - egal ob Rechner, Android oder IOS.

Unter dem Strich hat man die Wahl: (und das unabhängig der Sprache)
Man holt alles was man braucht aus dem Internet - inklusive von dritt Beteiligten und hofft das beste
oder man setzt Lib X bzw App Y voraus und mault rum wenn der Release nicht passt und muss dafür sorgen das
am Client neu Installiert wird. Der ewige Kampf - nicht gut gegen böse, sondern dynamisch vs statisch.

Bei MobileFX könnte ich auch mit Rest arbeiten und hätte so den "Man in the Middel" (formerly known as Cloud)
aussen vor - bzw FxPorts werde ich mir auch mal genauer ansehen. Aber zu meiner Persönlichkeit gehört auch eine Portion "Bockigkeit" - sprich ich möchte einfach mal sehen wie weit ich mit meiner Vision komme

D. h. du möchtest einen Dienst oberhalb der Transportschicht (TCP oder UDP) aufsetzen? Die Kommunikation erfolgt dann über Öffnen eines Sockets zu der IP (ggf. über den Hostnamen per DNS) und Senden des rohen XMLs als Bytefolge.

Idealerweise abstrahierst du mit einer weiteren Schicht auch darüber, ob nun XML verwendet wird oder nicht. Dann kannst du es später auch austauschen.

Jepp TCP Socket und darauf ein String Stream - und der wird dann mit StAX verarbeitet - die Richtung wird es gehen.

 

[ComFreek]

Im Ernst ich habe wirklich nichts gegen JS, aber wenn es möglich ist das ein Programmierer NodeJS ausser
Funktion setzt weil er ein Programmschipsel löscht

Ist doch bei jeder Programmiersprache so? Du kannst natürlich etwas Radiation Hardening betreiben

LIBs zu Laufzeit nachgeladen werden müssen und die Quelle im Internet liegt; man kann nie sicher sein ob man das bekommt was man erwartet.

Das ist ein guter Punkt! Zum Beispiel gibt es bei Google Fonts eine ellenlange Diskussion, warum Google denn Schriftarten maßgeblich aktualisiert, obwohl es keine versionierten URLs gibt. Die aktualisierte Schriftart hat nämlich einfach von heute auf morgen das Aussehen vieler Website verändert.
Aber sonst habe ich CDNs mit Versionierung eigentlich recht zuverlässig im Gedächtnis.

Und JS setzt auch ein OS voraus auf dem Potenziell auch Java installiert sein könnte

Nicht wirklich, du brauchst nur einen Browser.

 

[melmager]

Mann ist das doof wenn man NULL Plan hat
Also ich bin über ReactiveX bzw RxJava gestolpert.
Ist fast das was ich eigendlich wollte (nach ersten Überblick)
jedenfalls bin ich erst jetzt auf die Reaktive Programmierung gestossen.
Scheinbar (da bin ich mir noch nicht sicher) setzt die Kommunikation da auf Rest auf. Hat aber auch Scheinbar einen reinen TCP Port.

Und ein lächeln kam auf als ich gelesen habe das RxJava2 das "MayBe" Konzept einführt.
- da bin ich wohl auf ein April Scherz gestossen

So kann mir mal einer in ein paar Sätzen erklären was OpenShift ist.
Jo ist ein "Cloud Dingsbums" nutzt und hat was mit Jenkins / Kubernetes am Hut
Wie auch immer das zusammenhängt

Es gibt viel zu lesen und auszutesten