Drecks-PHP

  • zerm schrieb:

    Alex schrieb:

    Jetzt ist es offenbar schon soweit dass Kritiker des armen Juristen nur noch als eine Einheit wahrgenommen werden.

    Gehoere ich dann mit zu dieser Einheit? 60% meiner Posts sind glaube ich trollige Flamewars mit/gegen Amin :P

    Aendert aber nichts daran, dass "ihr" hier fast ausschliesslich Bloedsinn postet, in einer Trollqualitaet die ich lange nicht gesehen habe - Respekt!

    Wenn wir flamen und trollen hat das einen gewissen Anspruch an Qualität. Das macht es auch sinnvoll.

    Übrigens möchte ich bemerken, dass hier noch nicht einmal "C++" oder "Templates" gefallen ist. Also, um das abzurunden: Drecks-C++ mit Drecks-Templates.
    Es hat noch nie etwas gefunzt. To tear down the Wall would be a Werror!
    25.06.2016: [Swift] gehört zu meinen *Favorite Tags* auf SO. In welcher Bedeutung von "favorite"?

  • Alex schrieb:

    @zerm: Du bietest aber kein Produkt an - das ist hier der Unterschied.
    Andere wollen damit jedoch Geld verdienen. Sollen sie - nur wenn man in den Wald schreit, kommt auch ein Echo (ich lasse meine Theorie über schwarze Löcher die sich in den Urwäldern bilden jetzt mal weg :D ) .
    Man hätte alles wählen können als Überschrift. Aber es wurde ausgerechnet "Drecks-PHP". Ok - dann jedoch erwartet man kein PHP. Und findet man es doch, wirds einfach peinlich.
    Wobei - kann es noch peinlicher werden ? Denke nicht.
    Ein Jurist der nicht mal ein Impressum anbietet sagt schon alles aus.

    Die Projektseite ist gar nicht von mir. :-]

    Aber ich werde extra für dich darauf drängen, dass noch ein Impressum eingebaut wird.
    Es hat noch nie etwas gefunzt. To tear down the Wall would be a Werror!
    25.06.2016: [Swift] gehört zu meinen *Favorite Tags* auf SO. In welcher Bedeutung von "favorite"?

  • MCDan schrieb:

    Lucas de Vil schrieb:

    hns schrieb:

    (obwohl das gar nichts Neues ist - gab es nicht mal WebObjects???).

    Ist ewig her und war Java. :)

    Ich glaube das WebObjects in den ersten Version noch mit Objektive-C programmiert wurde und Apple erst später auf Java umgestiegen ist. Siehe auch de.wikipedia.org/wiki/WebObjects

    Ja, meine ich auch.

    Aber wir machen das schon etwas anders, wenn auch nuanciert: Bei WebObjects ging es ja vor allem, wenn ich mich recht entsinne, um alle drei Ebenen. Als Output hatte man also eine "menschenbedienbare" UI, eben HTML. Wie die Beispiele auf der Webseite zeigen, geht es uns aber eher um Dienste für Applikationen. Ob das eine Applikation auf einem OS X-Gerät ist, oder ob die jemand völlig Bescheuertes in einem PHP-Skript zusammenbaut, ist uns schnurz.

    Demgegenüber bieten wir ja nicht einfach eine Software nebst Entwicklungsumgebung für einen eigenen Server an, sondern "hosten" die Applikation bei uns. Uns ist halt wichtig, dass man im bereitgestellten Xcode-Template schnell seinen Dienst programmieren kann, wie man es von Objective-C kennt. Dementsprechend ist das auf der Webseite auch schon etwas veraltet, weil Parameter und Returnwerte mittlerweile ganz üblich und nicht mehr als Dictionary übergeben werden.
    Es hat noch nie etwas gefunzt. To tear down the Wall would be a Werror!
    25.06.2016: [Swift] gehört zu meinen *Favorite Tags* auf SO. In welcher Bedeutung von "favorite"?

  • MCDan schrieb:

    Lucas de Vil schrieb:

    hns schrieb:

    (obwohl das gar nichts Neues ist - gab es nicht mal WebObjects???).

    Ist ewig her und war Java. :)

    Ich glaube das WebObjects in den ersten Version noch mit Objektive-C programmiert wurde und Apple erst später auf Java umgestiegen ist. Siehe auch de.wikipedia.org/wiki/WebObjects

    Dann war ich damals™ schon zu spät dran. ^^
    «Applejack» "Don't you use your fancy mathematics to muddle the issue!"

    Iä-86! Iä-64! Awavauatsh fthagn!

    kmr schrieb:

    Ach, Du bist auch so ein leichtgläubiger Zeitgenosse, der alles glaubt, was irgendwelche Typen vor sich hin brabbeln. :-P

  • Lucas de Vil schrieb:

    MCDan schrieb:

    Lucas de Vil schrieb:

    hns schrieb:

    (obwohl das gar nichts Neues ist - gab es nicht mal WebObjects???).

    Ist ewig her und war Java. :)

    Ich glaube das WebObjects in den ersten Version noch mit Objektive-C programmiert wurde und Apple erst später auf Java umgestiegen ist. Siehe auch de.wikipedia.org/wiki/WebObjects

    Dann war ich damals™ schon zu spät dran. ^^

    Ah, ein 11-Monatskind.
    Es hat noch nie etwas gefunzt. To tear down the Wall would be a Werror!
    25.06.2016: [Swift] gehört zu meinen *Favorite Tags* auf SO. In welcher Bedeutung von "favorite"?

  • Jedem das seine liebe Leute, finde es echt schade dass der Thread durch unnötige Diskussionen so in die Länge gezogen wurde. Es gibt viele Technologien, du meisten davon werden für Zwecke vergewaltigt die offensichtlich nicht deren bestimmt sind/waren. Wir alle nutzen ObjC, das ist schön. Warum nicht offen für neues sein, und ja nicht alles was weit verbreitet ist und oft genutzt wird ist auch gut ;) ich denke dafür gibt's es viele Beispiele. Ich finde die Objective-Cloud ist ne absolut geniale Idee und bin schon gespannt auf den Start.

  • kimar schrieb:

    Jedem das seine liebe Leute, finde es echt schade dass der Thread durch unnötige Diskussionen so in die Länge gezogen wurde.

    Es gibt viele Technologien, du meisten davon werden für Zwecke vergewaltigt die offensichtlich nicht deren bestimmt sind/waren.

    Wir alle nutzen ObjC, das ist schön.

    Warum nicht offen für neues sein, und ja nicht alles was weit verbreitet ist und oft genutzt wird ist auch gut ;) ich denke dafür gibt's es viele Beispiele.

    Ich finde die Objective-Cloud ist ne absolut geniale Idee und bin schon gespannt auf den Start.


    Hab ich was verpasst?
    Ich bin gegen Signaturen!!!

  • Interessante sache.

    Verhalten sich die zugriffe auf die Services wie Apache oder eher wie Node?

    Ist zwar kein Dienst den ich wohl einfach so mal nutzen würde...aber dennoch interessant :)

    Achja noch ne Frage. Wie ist das mit speichern von Informationen in der Cloud? Die FAQ sagen ja, aber nicht während der Beta? Dabei ist doch das speichern von Informationen in den meisten fällen was essentielles :) Sind da schon Preise geplant bzw. Größen in den Paketen?

    Achja noch ne Idee mal in die Runde geworfen (falls wer bock hat sowas umzusetzen). Eine Art Google Analytics API für Apps ;D TestFlight suckt meiner meinung nach :-). Danke!

    So Far

    Nax
    Meine Beiträge :whistling: stehen unter der Beerware Lizenz!

  • Nax schrieb:

    Interessante sache.

    Verhalten sich die zugriffe auf die Services wie Apache oder eher wie Node?

    Ist zwar kein Dienst den ich wohl einfach so mal nutzen würde...aber dennoch interessant :-)

    Achja noch ne Frage. Wie ist das mit speichern von Informationen in der Cloud? Die FAQ sagen ja, aber nicht während der Beta? Dabei ist doch das speichern von Informationen in den meisten fällen was essentielles :-) Sind da schon Preise geplant bzw. Größen in den Paketen?

    Achja noch ne Idee mal in die Runde geworfen (falls wer bock hat sowas umzusetzen). Eine Art Google Analytics API für Apps ;D TestFlight suckt meiner meinung nach :-). Danke!

    So Far

    Nax

    Für Stateless-Services ist das eigentlich nicht essentiell. ;-)

    Um einen Einblick zu bekommen, was unsere Roadmap ist:
    - Nachrichten von curl an Methode versenden können. Gebongt.
    - Geordnete Infrastruktur für Server, Apps, Projekte usw. aufbauen. Gebongt.
    - Projektvorlage für Kunden machen. Gebongt.
    - Lokale Version des App-Servers bauen. Gebongt.
    - Projekt und lokale Version schöner machen, einfacher machen, schneller machen, bequemer machen. Heute fertig.
    - Automatisches Buildsystem bauen. Wohl Morgen fertig.

    Das alles nur für zustandslose Services: Nachricht rein, Retval raus. Wir wollen erst die komplette Infrastruktur aufbauen. Darin liegt die technische Herausforderung.

    Ab dann: Services erweitern. Hierauf spielt deine Frage nach der Persistierung an.
    - Kurzfristig: Lokales Filesystem.
    - MIttelfristig: CouchDB? Christian hat sich gerade verliebt.
    - Langfristig: Normale Core Data Anbindung.

    Um das klar zu machen: Gehen tut Core Data mutmaßlich schon jetzt out-of-the-box. Aber das nützt ja wenig, wenn das nicht ordentlich skaliert. Und dafür sind gerade bei Core Data (Eigentlich nur Core Data?) Handgriffe notwendig. Aber wir haben wegen eines ganz anderen Projektes in dem Bereich gute Erfahrungen.
    Es hat noch nie etwas gefunzt. To tear down the Wall would be a Werror!
    25.06.2016: [Swift] gehört zu meinen *Favorite Tags* auf SO. In welcher Bedeutung von "favorite"?

  • matz schrieb:



    Ja bitte ^^?
    ======================================

    Amin Negm-Awad schrieb:

    Nax schrieb:

    Interessante sache.

    Verhalten sich die zugriffe auf die Services wie Apache oder eher wie Node?

    Ist zwar kein Dienst den ich wohl einfach so mal nutzen würde...aber dennoch interessant :)

    Achja noch ne Frage. Wie ist das mit speichern von Informationen in der Cloud? Die FAQ sagen ja, aber nicht während der Beta? Dabei ist doch das speichern von Informationen in den meisten fällen was essentielles :) Sind da schon Preise geplant bzw. Größen in den Paketen?

    Achja noch ne Idee mal in die Runde geworfen (falls wer bock hat sowas umzusetzen). Eine Art Google Analytics API für Apps ;D TestFlight suckt meiner meinung nach :-). Danke!

    So Far

    Nax

    Für Stateless-Services ist das eigentlich nicht essentiell. ;)

    Um einen Einblick zu bekommen, was unsere Roadmap ist:
    - Nachrichten von curl an Methode versenden können. Gebongt.
    - Geordnete Infrastruktur für Server, Apps, Projekte usw. aufbauen. Gebongt.
    - Projektvorlage für Kunden machen. Gebongt.
    - Lokale Version des App-Servers bauen. Gebongt.
    - Projekt und lokale Version schöner machen, einfacher machen, schneller machen, bequemer machen. Heute fertig.
    - Automatisches Buildsystem bauen. Wohl Morgen fertig.

    Das alles nur für zustandslose Services: Nachricht rein, Retval raus. Wir wollen erst die komplette Infrastruktur aufbauen. Darin liegt die technische Herausforderung.

    Ab dann: Services erweitern. Hierauf spielt deine Frage nach der Persistierung an.
    - Kurzfristig: Lokales Filesystem.
    - MIttelfristig: CouchDB? Christian hat sich gerade verliebt.
    - Langfristig: Normale Core Data Anbindung.

    Um das klar zu machen: Gehen tut Core Data mutmaßlich schon jetzt out-of-the-box. Aber das nützt ja wenig, wenn das nicht ordentlich skaliert. Und dafür sind gerade bei Core Data (Eigentlich nur Core Data?) Handgriffe notwendig. Aber wir haben wegen eines ganz anderen Projektes in dem Bereich gute Erfahrungen.


    ja auf den ersten blick erinnert es an eine mischung von cloud9 (mehr debug and run als dev) und [Zitat Buch "...eine Art Grabbelkiste vorgefertigter Elemente."].

    CouchDB wäre natürlich ebenfalls i.o. sofern es da natürlich auch am besten ein integriertes Framework gibt :) (gibts da eigtl. was an sich open source oder so...nie geprüft...)
    Vom lokalen File system...ja irgendwie krieg ich gerade pickel am allerwertesten xD

    Gibts eigentlich bereits preisvorstellungen zu gelagerten kapazitäten?

    Die Frage der Bearbeitung von Anfragen like Apache or Node bleibt noch offen :-)? Hier wäre es gut zu wissen wie genau - Future und so ;D
    Meine Beiträge :whistling: stehen unter der Beerware Lizenz!