[DISKUSSION] Erbitte Feedback zu Tools und Technologien

[mlau]

Hallo Allerseits,

Ich sammle mir seit einer Weile "ideale" Tools und Sprachen zusammen und hätte gerne Feedback dazu.
Ziele sind:
- Alle Werkzeuge als SaaS, für Zusammenarbeit und Flexibilität
- Möglichst hohe Einheitlichkeit im kompletten Stack, von Datenbank bis Client
- Basis für eine handhabbare Strukturierung

So ist der Stand:

Tools

Cloud9 als IDE. Hat nicht den Funktionsumfang von zB WebStorm. Ich finde aber die gemeinsame Bearbeitung von Dateien in Echtzeit sehr interessant. Damit könnte man den Übergang von Einzelkämpfern zu echtem Teamwork schaffen
Und man hat 0 setup um an einem anderen Rechner zu arbeiten, kann seinen aktuellen Stand mit anderen teilen etc.
Präprozessoren mittels der entsprechenden Watcher, einfach mittels eines Bash-Alias.

Github für Quellcoderepositories.

Heroku als Host.

MongoLab über Heroku als Datenbankprovider, kann man auch von Cloud9 aus nutzen.

Sprachen

Full-Stack JavaScript. Da man um JS generell nicht herum kommt, ist die einheitlichste Lösung auch JS im Backend (NodeJS) zu nutzen.

Full-Stack JSON. Ensprechend der Einheitlichkeit ist die einzige genutzt Art von Datenstrukturen dann auch JSON.
Als Datenbank dann MongoDB. Zum einen weil hier JSON im Fokus steht. Zum anderen, weil die Validierung von Daten durch die Datenbank eine Verletzung der Separation of Concerns darstellt. Datenvalidierung, auch anhand eines Schemas, sollte durch die Anwendung geschehen.

Vereinheitlichung und Verdichtung der Syntax durch Präprozessoren. Also CoffeeScript für JS, Jade für HTML und Sass für CSS. Damit werden überall Blöcke durch Einrückung gebildet und die Syntax von CSS und HTML angeglichen. Und man kommt von der schrecklichen Syntax von HTML weg, schon dass ist es doch wert.
Generell sind die Varianten mit Präprozessor auch kompakter und bieten teilweise auch nützliche Funktionen.

Strukturierung und Integrität des Frontends durch AngularJS.

Dieses Setup benutze ich bereits so und es funktioniert.
Ich hätte aber gerne Feedback was ihr davon haltet, wie eure Erfahrungen mit diesen Technologien sind etc.

Falls für jemanden diese Stacks interessant klingen steh ich auch gerne mit Rat zur Seite, sozusagen um gemeinsam Erfahrung zu sammeln.

 

[Dormilich]

Datenvalidierung, auch anhand eines Schemas, sollte durch die Anwendung geschehen.

Sehe ich persönlich anders. Außerdem solltest du dann auch nicht MongoDB nehmen, das macht nämlich Validierung anhand der vorgegebenen Models.

Strukturierung und Integrität des Frontends durch AngularJS.

Ich persönlich mag Angular nicht besonders, hat irgendwie nicht mehr viel mit JS zu tun. Und (zumindest in Angular 1) die Vermischung von Angular-Logik mit HTML (ng-Attribute) läuft eigentlich der Trennung von Struktur (HTML) und Verarbeitung (JS) komplett zuwider.

 

[tsseh]

Cloud9 als IDE.

entwickeln in der cloud mag modern klingen, aber produktiv ist es meiner meinung nach nicht. und wer will schon seine quellen der cloud anvertrauen? klar kannst du auch deinen eigenen workspace auf deinem server zur verfügung stellen, aber das geht dann immer noch über c9 und du greifst von deinem arbeitsplatz über c9 auf deinen server zu - das soll die lösung sein?

Ich finde aber die gemeinsame Bearbeitung von Dateien in Echtzeit sehr interessant.

so funktioniert aber entwicklung nicht. du willst nicht in Echtzeit eine datei von jemand anderem sehen, sondern auf einem definierten stand aufsetzen und deine funktionalität entwickeln, ohne dass dir jemand dazwischen funkt. dafür gibt es versionsverwaltungssysteme wie clearcase oder git.
du branchst von einem definierten stand ab, entwickelst deine funktionalität und mergst sie zurück.
musst du dich mit anderen abstimmen, können alle aus diesem team zwischendurch ihre funktionalität auf einem integrationsbranch bei bedarf zusammenbringen und testen, von diesem dann wieder abzweigen und weiterentwickeln. am ende wird dann der integrationsbranch zurück auf den hauptbranch gemergt.
so setzt jeder auf einem funktionierenden stand auf und wird nicht durch fehler von anderen aufgehalten.

Da man um JS generell nicht herum kommt, ist die einheitlichste Lösung auch JS im Backend (NodeJS) zu nutzen.

mit sails hat man dann auch ein mächtiges backend-framework, ob das produktiver ist als php muss jeder für sich entscheiden. ich würde vermuten, dass man mit php im backend zur zeit noch besser fährt, weil es viele erfahrene entwickler auf diesem gebiet gibt.

Also CoffeeScript für JS, Jade für HTML und Sass für CSS. Damit werden überall Blöcke durch Einrückung gebildet und die Syntax von CSS und HTML angeglichen. Und man kommt von der schrecklichen Syntax von HTML weg, schon dass ist es doch wert.

für html und css mag das jeder für sich entscheiden, ich finde die Syntax von HTML nicht schrecklich, eher die von jade.
aber sein scriptcode in CoffeeScript zu schreiben der dann in js gewandelt wird, was dann letztlich auch ausgeführt wird - davon halte ich nichts.
ich habe auch noch nie den sinn/vorteil von CoffeeScript verstanden. meiner meinung nach ist das nur wieder ein versuch um leute im irrglauben zu lassen, jeden deppen als entwickler nehmen zu können und davon dann viele.

Strukturierung und Integrität des Frontends durch AngularJS.

ich bin großer fan von angular, ein brauchbares mvc framework, gut erweiterbar, modular aufgebaut und man kommt sehr schnell zum ziel, aber wie Dormilich schon sagte, "die Vermischung von Angular-Logik mit HTML" stört(e) mich auch ein wenig. wenn man Angular jetzt aber als template-engine ansieht, was es ja eigentlich ist, wird aus der vermischung von html und logik ein templatesystem für views.

 

[mlau]

Wow, danke, das ist schonmal eine Menge Feedback. Danke dafür.

Sehe ich persönlich anders. Außerdem solltest du dann auch nicht MongoDB nehmen, das macht nämlich Validierung anhand der vorgegebenen Models.

In MongoDB gibt es keine Schema. Man kann mit Mongoose Schemavalidierung machen, dass ist dann aber auch anwendungsseitig und nicht Teil der Datenbank.

Ich persönlich mag Angular nicht besonders, hat irgendwie nicht mehr viel mit JS zu tun. Und (zumindest in Angular 1) die Vermischung von Angular-Logik mit HTML (ng-Attribute) läuft eigentlich der Trennung von Struktur (HTML) und Verarbeitung (JS) komplett zuwider.

Ich würde eher Sachen wie JSPs als Vermischung von Logik und Struktur betrachten.
Klar ist es mit AngularJS keine reine Strukturbeschreibung mehr, es gibt auch "Template"-Anweisungen und welche zur Datenbindung, Formatierung etc.
Aber wirkliche Logik ist in Controllern gekapselt.
Oder meinst du hier etwas bestimmtes?

entwickeln in der cloud mag modern klingen, aber produktiv ist es meiner meinung nach nicht. und wer will schon seine quellen der cloud anvertrauen? klar kannst du auch deinen eigenen workspace auf deinem server zur verfügung stellen, aber das geht dann immer noch über c9 und du greifst von deinem arbeitsplatz über c9 auf deinen server zu - das soll die lösung sein?

Ich kann glaube ich nicht ganz folgen. Ja, man hat seine Quellen und seinen Arbeitsplatz bei c9.
Mir geht es hier nicht um modern. Ich bin auch ein Feind von dem Schlagwort "Cloud", für mich ist das SaaS mit einer Weboberfläche.
Und ich würde meine Quellen einem Dienstleister anvertrauen. Letztendlich will es ja auch wo hosten, und das nun nicht bei mir im Keller.
Meiner Meinung nach ist auch die Erfahrung eines Entwicklungsteams und dessen Beherrschung der Codebasis wichtiger als die Quelltexte, so gesehen würde ich diese nicht als Staatsgeheimniss behandeln.
Und sind sind die Quelltexte wirklich sicherer, wenn sie auf den Entwicklermachinen und einem eigenen Repository-Server liegen, in Zeiten wo Festplatten bereits mit infizierten Treibern ausgeliefert werden?

so funktioniert aber entwicklung nicht. du willst nicht in Echtzeit eine datei von jemand anderem sehen, sondern auf einem definierten stand aufsetzen und deine funktionalität entwickeln, ohne dass dir jemand dazwischen funkt. dafür gibt es versionsverwaltungssysteme wie clearcase oder git.
du branchst von einem definierten stand ab, entwickelst deine funktionalität und mergst sie zurück.
musst du dich mit anderen abstimmen, können alle aus diesem team zwischendurch ihre funktionalität auf einem integrationsbranch bei bedarf zusammenbringen und testen, von diesem dann wieder abzweigen und weiterentwickeln. am ende wird dann der integrationsbranch zurück auf den hauptbranch gemergt.
so setzt jeder auf einem funktionierenden stand auf und wird nicht durch fehler von anderen aufgehalten.

Wie gesagt gibt es trotzdem git-Repositories auf Github.
Die Echtzeitentwicklung gibt es normalerweise nicht, die wäre zusätzlich.
Man kann das auch als Pairprogramming betreiben. Oder eben wirklich zu zweit an einer Datei arbeiten, um sich gegenseitig zu helfen.
Grundsätzlich ist halt die Idee, dass man sofort Fehler oder Unsauberkeiten des anderen erkennen und diskutieren kann. Und dass Wissen effektiver geteilt wird. Indem man zusätzlich chattet oder miteinander spricht.
Wäre zumindest meine These.

mit sails hat man dann auch ein mächtiges backend-framework, ob das produktiver ist als php muss jeder für sich entscheiden. ich würde vermuten, dass man mit php im backend zur zeit noch besser fährt, weil es viele erfahrene entwickler auf diesem gebiet gibt.

Ich glaube sails passt nicht gut zu der Idee einer SPA (hab ich vielleicht vergessen zu erwähnen).
Meinem Konzept nach sollte der Server nur Services haben, keine Views.
Die Sache mit den erfahrenen Entwicklern ist ein gutes Argument gegen serverseiten JavaScript, würde ich aber erstmal gerne außen vor lassen.

für html und css mag das jeder für sich entscheiden, ich finde die Syntax von HTML nicht schrecklich, eher die von jade.
aber sein scriptcode in CoffeeScript zu schreiben der dann in js gewandelt wird, was dann letztlich auch ausgeführt wird - davon halte ich nichts.
ich habe auch noch nie den sinn/vorteil von CoffeeScript verstanden. meiner meinung nach ist das nur wieder ein versuch um leute im irrglauben zu lassen, jeden deppen als entwickler nehmen zu können und davon dann viele.

Ich finde es gerade gut das CoffeeScript vor Ausführung vorkompiliert wird, wegen der Performance.
Der Aussage, dass oftmals suggeriert wird, jeder könnte einfach programmieren, der stimme ich zu.
Dafür würde ich aber eher die Masse an visuellen Editoren verantwortlich machen, die suggerieren Programmierer würden die Komplexität von Softwareentwicklung nur vorgaukeln und eigentlich könnte das ja jeder -.-
CoffeeScript hat einfach eine kompaktere Syntax als JS und erzwingt sinnvolle Einrückung. Syntactic sugar wenn du so willst. Man sieht auf einer Seite Code mehr Funktionalität und weniger Boilerplate / Sprachkonstrukte.
Es versucht einem definitiv nicht das denken abzunehmen, im Gegenteil

ich bin großer fan von angular, ein brauchbares mvc framework, gut erweiterbar, modular aufgebaut und man kommt sehr schnell zum ziel, aber wie Dormilich schon sagte, "die Vermischung von Angular-Logik mit HTML" stört(e) mich auch ein wenig. wenn man Angular jetzt aber als template-engine ansieht, was es ja eigentlich ist, wird aus der vermischung von html und logik ein templatesystem für views.

Im Prinzip ist es eine Template-Engine mit Datenbindung. Oder eine Template-Engine die Teile eines Templates bei Datenänderung automatisch neu evaluiert.
Es geht schon über den Gedanken von HTML hinaus.
Aber ich denke es macht mehr Sinn als "Templates" implizit in jQuery-Code zu definieren, zumindest ab einer gewissen Komplexität.

 

[Dormilich]

Ich finde es gerade gut das CoffeeScript vor Ausführung vorkompiliert wird, wegen der Performance.

von der nicht viel übrig bleibt, weil es in JavaScript konvertiert wird …

 

[mlau]

von der nicht viel übrig bleibt, weil es in JavaScript konvertiert wird …

Für den WebClient gibt es keine Alternative und die Performance der v8 ist jetzt nicht so schlecht, oder?
Und um alle CPUs zu nutzen gibt es auch Strategien.

 

[Dormilich]

Ich wollte nur drauf aufmerksam machen, daß die Vorkompilierung nicht zwangsläufig die Performance gegenüber einem "normalen" JavaScript steigert (mal von ASM abgesehen).

 

[mlau]

Ich wollte nur drauf aufmerksam machen, daß die Vorkompilierung nicht zwangsläufig die Performance gegenüber einem "normalen" JavaScript steigert (mal von ASM abgesehen).

Ich wollte auch nur sagen, dass die Performance durch coffeescript nicht schlechter wird.

 

[tsseh]

Ich bin auch ein Feind von dem Schlagwort "Cloud", für mich ist das SaaS mit einer Weboberfläche.

und das schlagwort saas ist da positiver besetzt?
seit min. 10 jahren wird davon geredet, dass saas die zukunft ist. meiner meinung nach wird sich das nie durchsetzen. gerade jetzt, wo jede woche ein neuer artikel zur nsa affäre in den zeitungen steht.
klar ist das schon beeindruckend, wenn man sich mal google docs oder ähnliches anschaut, aber ich glaube kaum, dass das irgendeine firma verwendet.

Wie gesagt gibt es trotzdem git-Repositories auf Github.

was willst du damit sagen? ja die gibt es, für open source anwendungen super. wobei einige projekte dort einfach nur gespiegelt sind.

Man kann das auch als Pairprogramming betreiben.

noch son schlagwort

Oder eben wirklich zu zweit an einer Datei arbeiten, um sich gegenseitig zu helfen.

ich hab schon beides erlebt, du sitzt mit leuten im zimmer und weisst eigentlich nicht was sie machen und auf der anderen seite, dass du deren quellen zumindest soweit kennst, dass du im notfall auch mal einen fehler suchen kannst, wenn der eigentliche entwickler mal nicht da ist. dafür müssen die leute aber miteinander reden und probleme und design gemeinsam besprechen, und das macht man am besten vor EINEM rechner und einer tafel.

Ich glaube sails passt nicht gut zu der Idee einer SPA (hab ich vielleicht vergessen zu erwähnen).

doch, ein modell im backend wirst du ja trotzdem brauchen

Meinem Konzept nach sollte der Server nur Services haben, keine Views.

die views musst du ja nur sehr rudimentär nutzen

CoffeeScript hat einfach eine kompaktere Syntax als JS und erzwingt sinnvolle Einrückung.

ich kenne keinen, der eine sinnvolle Einrückung nicht auch ohne zwang verwendet. und gerade die blockung durch einrückung fand ich schon bei python immer abartig

Man sieht auf einer Seite Code mehr Funktionalität und weniger Boilerplate / Sprachkonstrukte.

mehr sehen und mehr verstehen sind 2 verschiedene sachen.