Ich kann mit keiner der PHP Funktionen (system, exec, shell_exec) mein command ausführen.
Ich vermute, dass das nichts hier im Smalltalk zu suchen hat und wuerde Dich bitten, dass Du ein neues Thema erstellst.
Um das eben schnell gegen zu antworten: Fuehrst Du die PHP Datei in einer Shell aus oder per HTTP call? (wie gesagt: neues Thema erstellen)
Das passiert halt, wenn sein eigenes Projekt down gegangen ist und nichts auf die Reihe bekommt dann ist man halt Mad... xDD
Er war auch davor so.
- klasse hört sich nach ner guten Demokratie im späteren Verlauf an.
Krass wie Du immer alles ins lächerliche ziehst. Wenn ich ein Projekt gründen will, dann mache ich das logischerweise weil mich das auch interessiert. Ich suche ja wohl kein Team für etwas, was mich absolut garnicht juckt (Roleplay oder DM; wie er geschrieben hat).
___
Ich bin hier wirklich ja schon sehr inaktiv in diesem Forum aber Deinen Müll lese ich eigentlich in jedem Thread. Es tut mir leid, aber anders kann man es schon gar nicht mehr sagen. Man meint, Du bist ein so negativ eingestellter Mensch, dass Du immer und jeden kritisieren musst. Vorallem bei Serverwerbungen bist Du wie eine Zecke. Kaum eine neue Werbung, direkt sieht man nen GUCCI Beitrag. Was ist eigentlich Dein Problem?
Sind wir mal ehrlich, Du interessierst Dich eh nur für Deinen Post Counter hier im Forum und neue Projekte gehen Dir eigentlich nur am Arsch vorbei. Bitte, hör doch einfach auf zu nerven. Ich könnte von jedem Deiner Beiträge kotzen.
Hi. Sag mal, wer hat das mit dem Build Service bei euch eingerichtet?
Kann man diesbezüglich einige Informationen erhalten? Wie ihr das umgesetzt habt bzw.
ob es auch alternativen dazu gibt? City of SA hat das ja auch, fand ich damals schon schick.
Fuer die Plattformen I Love Crime und City of SA habe ich den Build Service entwickelt. I Love Crime wird noch auf die neue Version (die auch COSA einsetzt) umsteigen wenn ich dazu die Zeit finde.
Alte Version (relativ simpel und unspektakulaer):
Ein WebHook bei GitHub ruft eine Seite vom Build Service auf und sagt es liegen neue Aenderungen vor. Das Backend auf dem Server registriert das, zieht sich den neuen Quellcode und compilet das Script, parst den Compiler Output, schreibt dich im TS wenn er fertig ist und installiert gleich das Script aufm Testserver, so dass man nur noch /restart machen muss. Die Version ist entstanden, als es mir auf den Sack ging als mein Script sehr gross wurde und ich einen Timebug nach jedem Upload einer Aenderung bekommen habe. Das System wurde in PHP noch geschrieben.
Neue Version (viel komplexer als 1.0):
Ist mittlerweile in Ruby on Rails geschrieben worden und benoetigt kein Backend, da Rails ein Job-Processing-System hat wo Aufgaben wie das Compilen gleich mit uebernommen werden koennen. Im Endeffekt funktioniert der Anfang genauso wie bei 1.0: Webhooks triggern einen Build Request beim Build Service, der Build Service spawnt einen Docker Container (mit einem vom mir gebauten Image in dem der PAWN Compiler installiert ist) packt dort die Dateien rein und ruft den Compiler auf. Nach dem Ergebnis werden Fehler & Warnings analysiert und du bekommst ne Push auf dein Handy wenn er das Script dann aufm Server installiert hat und ob der Compile Prozess erfolgreich war. Um immer zu wissen, welche Revision/Buildnummer/Commit Du aufm Testserver testest, setzt der Build Service von sich aus ein paar Defines, die Dich eben das alles ueberpruefen lassen. So fragt man sich halt nie "hab ich eben mein Script compilet oder habe ich vergessen das Script hochzuladen?". Was auch noch sehr cool ist, dass Du Dir den Build Prozess live ansehen kannst. Hier ein Beispiel: https://build.city-of-sa.de/projects/city-of-sa/builds/1667
Wenn Du auf "Builds" klickst, laedt das ganz schoen lange aber nur weil ich Pagination vergessen habe einzubauen und seit Mai nichts mehr dran gearbeitet habe 
Was auch noch ganz praktisch ist, dass wenn Du mehrere Entwickler hast, musst Du ihnen keinen Zugriff auf Includes oder andere Dateien geben. Der Build Service ist faehig aus mehreren Repositories die Dateien zusammen zu fuegen, so dass nur mit dem kompletten Set an Dateien das Script compilet werden kann. So kann man den Zugriff beschraenken und Mitentwickler koennen zwar den Teil releasen, auf den sie Zugriff haben, aber nicht alles und somit ist das Script fuer jeden unbrauchbar. So hatte ich das auch bei COSA gemacht. Hatte 2 Entwickler und da ich keinem mein Script einfach so gebe und wir auf einen Vertrag verzichtet haben, hab ich denen halt einfach Zugriff auf das Hauptscript, aber nicht auf das Repository mit all den Includes und anderen Systemen gegeben. Sollten sie den Teil nun releasen ists mir eigtl relativ egal 
(mal von dem Fakt abgesehen, dass das Script eh nicht unter Windows compilierbar ist)
Die neue Version kommt auch mit Branches klar und somit koennen mehrere Entwickler an einem Script arbeiten, ohne sich in die Quere zu kommen. Muss das noch machen, dass man fuer jeden Entwickler einen eigenen Testserver angeben kann, wo nur immer wenn sie compilen, ihr Script deployt wird.
Ein paar Bilder:
Der neue Build Service sollte mal ein eigenstaendiges Projekt werden, das von mehreren genutzt werden kann. Da ich aber dann theoretisch Zugriff auf andere Scripte haben wuerde, glaube ich nicht, dass das viele aktiv nutzen wuerden. Im Bereich SA:MP haben wir ja leider keine Open Source Politik.
Der Besitzer des Zertifikats hat das Zertifikat zurueck gezogen und das vermutlich aus einem guten Grund. Deshalb sollte eine Verbindung nicht hergestellt werden, da es scheint, dass sein Zertifikat gestohlen wurde.
es muss s[128] heißen
Ich moechte mich beteiligen.
Hast Du jemals mit Rails gearbeitet?
Du brauchst mir nicht erklaeren wo der Unterschied zwischen Ruby und Rails ist. Dennoch stellt sich mir die Frage, wieso Du Dich auf Ruby beziehst waehrend ich dauernd von Rails spreche? Du hast damit eine komplett neue Diskussion angefangen. Ja, Ruby (die Sprache) ist nicht auf Web ausgelegt und deswegen gibt es halt Rails was wiederum perfekt auf das Web angepasst wurde. Wenn Du das als "fiesen Trick" bezeichnest, dann ist das halt so 
Wenn ich ueber Ruby on Rails rede seit Post #1 und dann Benchmarks kommen von Ruby <=> PHP macht das genauso wenig Sinn. Und ich habe mehrmals bekraeftigt, dass ich mich auf RoR beziehe.
Hä? Ich rede seit beginn meines ersten Posts von Ruby on Rails. Wtf? Sobald Du aber anfaengst irgendwelche Sachen zu vergleichen oder Benchmarks zu liefern, dann macht es nur Sinn, diese auf RoR zu beziehen so wie ich es in jedem meiner Posts gemacht habe weil kein Mensch in der Ruby-Welt WebApps mit RubyCGI schreibt. Ausserdem macht es bei Projekten schon eher Sinn mit einem Framework zu arbeiten. Das gleiche gilt fuer PHP. Oder das Projekt macht ein Yet-Another-PHP-Framework.
RubyCGI ist natuerlich schlechter aber man muss schon hart am Sack sein um damit eine produktive Webseite zu schreiben. Dann kannst Du natuerlich Deine Benchmarks herziehen und dann gewinnt auch PHP.
Aber ganz ehrlich, was nuetzt ein Benchmark, der Hello World vergleicht? Garnichts.
//Edit: Ein bisschen ausgefuehrt
Bis auf Redmine
GitHub, Travis, Gitlab... sollte Dir als jemand, der in einer Firma entwickelt, ein Begriff sein 
das Ruby (und da spreche ich von der Sprache) nicht für das Web entwickelt wurde
Habe ich das je behauptet? Keine Ahnung warum Du jedesmal mit diesem Argument kommst wenn das rein garnichts zur Diskussion beitraegt. Es geht doch um den Vergleich PHP <=> Ruby on Rails und nicht um PHP <=> Ruby...
Da macht auch ein Framework keinen Unterschied,
Doch, Frameworks machen einen Unterschied. Du kannst kein <?php echo "Hello World"; ?> mit einer Rails App vergleichen... Das ist genau das, was Dein Bericht macht, der lustigerweise sogar noch bestaetigt, dass sich ein z.B. Laravel als PHP Framework nichts mit RoR schenkt. Natuerlich mag es Benchmarks geben, die zu gunsten von einem anderem PHP Framework sind. Aber deswegen heisst es nicht, dass RoR langsamer ist als jedes PHP Framework. Es kommt rein auf die Programmierung des Frameworks an.
Aber zu behaupten, dass PHP effizienter ist wenn es auf grosse Applikationen kommt, ist Quatsch.
//Edit: Satzbau
wird der Code auch nur einmal geparst (OPCaching ).
Hatte ich ueberlesen gehabt - hattest Du bereits oben erwaehnt.
Here is a chart of a very simple "hello world" application. Below you can see just how fast pure PHP is when it comes to requests — remember, it’s a language designed for the web. However, once you start to introduce the popular full stack web frameworks, the performance drops, and the requests per second gets closer to the Ruby on Rails number. In fact, a popular web framework Laravel performs worse than Ruby on Rails. As a result most benchmarks are useless, because there’s so much more to the performance and speed of an application than the language or web framework. For example, the database system, caching mechanisms, and network delays can add a 10x to 100x slow down. So how the application is design is far more important than the language or web framework behind it.
Man sollte sich hier erstmal die Frage stellen, was Du vergleichen willst. Wenn ich nur ein "Hello World" Programmm schreiben will, dann macht es natuerlich keinen Sinn ein ganzes Framework wie Rails herzuziehen...
Klar, keine Frage. Eine Rails App zu hosten ist deutlich aufwendiger und schwieriger als ein paar Dateien in /srv/www/htdocs zu schmeissen (oder /var/www unter Debian/Ubuntu/whatever). Dementsprechend auch ohne eigenen Server kostspieliger. Aber fuer die, die einen V-Server betreiben und ein UCP schreiben wollen, kann das ganze auch auf Rails Basis passieren.
Wie ich bereits schon sagte: Der Code wird 1x geparst, was bei PHP nicht der Fall ist. Du kannst den Benchmark maximal auf die Command Line reduzieren aber nicht sobald Rails ins Spiel kommt.
das wir bei einem analogen Ruby on Rails Setup wahrscheinlich Probleme bekommen würden.
Das mag ich bezweifeln.
Ich finde PHP ist eine sehr schöne Sprache. Ich kann mich dem Hype um den ganzen Hass gegen PHP absolut nicht anschließen.
Es ist letztendlich geschmackssache. Und ich habe keinen "Hass" gegen PHP.
Erstmal sollte festgehalten werden, dass das Rails Framework den Code einfach einmal prozessiert und dann im Speicher behaelt was bei PHP nicht der Fall ist. PHP ruft den Interpreter immer und immer wieder auf und parst alles und das wird auch bei groesseren Anwendungen langsamer. Auf der Command Line kann es schon sein, dass PHP schneller ist. Im Web Bereich merke ich allerdings nichts davon, da der Code einmal durchlaeuft und dann im Speicher gehalten wird. Somit dauert lediglich der erste Request nach dem Starten des Webservers "laenger".
@Developer anscheinend verstehst Du entweder nicht den Unterschied zwischen Ruby on Rails und Ruby oder Du verwendest einfach die Begriffe falsch. Ich habe nie behauptet, dass Ruby asynchron ist. Ich habe nur gesagt, dass das Rails Framework in mehreren Threads arbeitet und Du problemlos Variablen zwischen diesen austauschen kannst. Und damit meine ich nicht ueber Sessions sondern 1:1 die gleichen Objekte. Zusaetzlich gibt es noch ActiveJob. Natuerlich ist Ruby nicht fuer das Web ausgelegt aber dafuer Rails. Deswegen macht der Punkt einfach keinen Sinn. Das Rails Framework steht einem PHP Framework nichts nach.
Dann lass einfach dieses Thread nutzen.
zu Rails:
Ja mag sein, trotzdem kann das Rails Framework auch nur soviel optimieren wie Ruby eben zulässt und da Ruby nicht für die Webentwicklung erstellt wurde ist es nicht für den Betrieb als Webserver/Interpreter geeignet. Rails versucht das eben nur zu umschiffen und eben doch möglich zu machen. Es ist wie gesagt alles ein für und wieder, Ruby ist halt einfach nicht fürs web "gemacht".
Dann nenn mir bitte etwas, was sich nicht in Rails umsetzen laesst, zugleich aber in PHP moeglich ist.
zu node.js
Einfach weil es flexibler ist und eben "non blocking" also asynchron.
Ist Rails auch. Es laeuft in mehreren Threads und Variablen koennen ueber Requests hinweg ausgetauscht werden.
Wenn man alleine vor sich hin programmiert ist es alles kein Problem, da interessieren Conventions nicht, da gebe ich dir recht. Aber sobald du in den Businessbereich gehst werden die Anforderungen wesentlich strenger.
Es geht nicht um die Conventions in Frameworks. Es geht mir primaer um die von PHP eigenen Conventions. Darauf bezog sich mein Vergleich mit den Klassennamen.
Der Artikel bezieht sich ausserdem auf generelle Sprachen und nicht auf Web Frameworks. Das faengt schon damit an, dass CSS oder C++ vor Ruby steht. Die Statistik ist fuer diese Diskussion nicht gerade zweckerfuellend, da es eigentlich am Thema vorbei geht. Ich beziehe mich rein auf das Web Framework. Das C++ vor Ruby steht ist ja wohl keine Frage.
zu 1. Es war kein Angriff, sondern nur die Aussage das der Schritt von PHP zu Ruby kein wirkliches "weiter kommen" ist.
Das habe ich auch nicht behauptet. Web Technologien sind ueberall gleich und an keine Frameworks gebunden. Das ich "endlich weg von PHP" schrieb, ist eine persoenliche Praeferenz und bezog sich nicht auf meinen "Fortschritt" in der Web Entwicklung. Ich habe auch nicht behauptet, dass PHP mich nicht weiterkommen laesst.
zu 2. Ja natürlich, sieht man ja z.B. Redmine, trotzdem ist der Ruby Stack einfach nicht fürs Web optimiert bzw. ursprünglich gemacht wie eben PHP. Ich will nicht behaupten das PHP das Gelbe vom Ei ist, bei weitem nicht, es ist eben nur fürs Web optimiert und dafür entwickelt.
Ja das stimmt, aber das Rails Framework. Deswegen verstehe ich ehrlich gesagt den Punkt "nicht fuers Web optimiert" nicht.
ogar ehr mit node.js statt mit PHP/Ruby/Python usw. schreiben.
Wieso?
Was fuer ein Battle? Ich wollte mich nur mit Dir unterhalten und Meinungen austauschen, deswegen sage ich ja nicht das Du keine Ahnung hast oder voellig falsch liegst. Seit Post #1 geht es um Scripting Sprachen und was man verwenden sollte. Ich beharre ja nicht darauf das der Typ jetzt Rails Entwickler wird.
Naja, Conventions in PHP... Da faengt es schon mit der Inkonsistenz der Benennung von Funktionen und Klassen Methoden an. Je enger die Conventions greifen, desto mehr wirst Du eingeschraenkt, das ist richtig. Wobei ich das nicht als Nachteil von Ruby o. Rails sehe sondern eher als Vorteil weil man sich in anderen Apps schnell wieder einarbeiten kann. Ich kann natuerlich nicht beurteilen wie Laravel das handhabt - will mich generell auf Conventions beziehen.
Bezueglich den Jobs: PHP Entwickler werden aber haeufiger gesucht als Rails Entwickler, weil Rails noch zu unbekannt ist aber langsam mehr und mehr an Beliebtheit gewinnt was zugleich die Bezahlung foerdert.
