Für alle die noch Ihre Rechnungen noch mit Word oder ähnlichem schreiben, Ihr könnt euch hier registrieren.

https://www.salesking.eu/

Wir werden wöchentlich neue User zulassen, bitte habt etwas Geduld.

Ansonsten könnt Ihr unseren Twitter Stream oder Blog verfolgen.

Ja … und wir sind der Meinung, es ist sogar essentiell auf diese Weise zu starten.

Dass diese Meinung in der Web2.0 Startups keine große Verbereitung hat, findet man schnell heraus indem man diverse Webservices einmal ohne Javascript besucht.

Doch warum gehen wir diesen, zugegebenermaßen steinigen Weg? Es ist doch so einfach die in Ruby on Rails oder anderen Frameworks verfügbaren Javascript-Helferlein zu verwenden? Nicht zuletzt sind solche Javascript Code-Generatoren ja auch für den Erfolg vieler Frameworks verantwortlich.

Die kurze Antwort:

Wir wollen die Kontrolle über unser Javascript behalten!

Die lange Antwort :

Unauffälliges / Unobstrusive Javascript

Es soll dem User nicht auffallen wenn er die Seite ohne Javascript benutzt. “Wer hat denn schon JS ausgeschaltet?”, ist meist die Gegenfrage. Jede größere Firma, welche halbwegs auf ihre interne Netzsicherheit achtet, wird/sollte JS ausgeschaltet haben. Ein weiterer Vorteil dieser Restriktion ist übrigens, daß die Mitarbeiter sich auf Ihre Arbeit konzentrieren, da das Internetz keinen Spass mehr macht.
Auf mögliche JS basierte Angriffe will ich hier nicht weiter eingehen, Google hilft aber gerne weiter:

http://www.google.de/search?q=Javascript+angriff

Spagetti Code und enge Kopplung vermeiden

Ist die Soße, in diesem Falle JS, erst einmal auf den Nudeln, ist es so gut wie unmöglich sie wieder von den Spagetti zu trennen. Die enge Kopplung von zwei intelligenten Sprachen, bzw. das Generieren von JS mittels PHP, Ruby, Java; macht die folgenden Punkte so gut wie unmöglich:

• JS Fehler finden / Debuggen
• JS Sicherheitslücken finden
• JS Schnelligkeit und Effizienz Testen / Profiling
• Austausch der Soße(JS) je nach Client (IE / mobile Webbrowser / iPhone / ..)
• Wiederverwendung von JS z.B. in einer komplementären Adobe Air Anwendung oder Widgets

Wem diese Punkte nicht reichen, ein weiteres Beispiel:

Bevor CSS in seiner heutigen Anwendung(komplette Trennung von CSS / HTML) populär wurde, schrieben wir es einfach mit in die jeweiligen HTML-Elemente. Kam dann der Kunde und wollte neue Farben, war es ein Heidenspass 150 HTML Dateien anzupassen.

Wie Kontrolle behalten?

Der einzig richtige Weg ist: Lerne Javascript und du wirst es lieben!

Auch ich habe mit den tollen JS Helfer in Rails und cakePHP angefangen, ohne einen blassen Schimmer von der Materie zu haben. Das Ende vom Lied war ein dreckiger Haufen Code und x vertane Stunden mit drei Fragezeichen über meinem Kopf. Das waren übrigens, vor zwei Jahren, die ersten Versuche den SalesKing zu bauen.
Nachdem 3 Versuche und drei Monate Arbeit im Müll gelandet waren, habe ich mich tiefer mit jQuery und Javascript beschäftigt. Es ging nicht von heute auf morgen, doch ein halbes Jahr später hatte ich meine Javascript-Angst überwunden, unter anderem durch das Ormigo Dschungelcamp und Teemow.

Das populärste Javascript-Müll Beispiel ist übrigens seit langem in WordPress, zu finden, die „Artikel schreiben“ Seite enthält 14 Javascripte. Chaos deluxe und keiner weiß warum es noch funktioniert!!!

Unsere Vorgehensweise

Wir sehen in JS den Zucker auf dem Kuchen. Im Gegensatz zu Schokostücken, kommt dieser erst nach dem Backen zum Einsatz.

Der Programmier-Ablauf sieht grob wie folgt aus:

1. Programmieren der Basisfunktionen ohne JS, dafür mit vielen Zwischenseiten.
2. Testen
3. Einbinden der Basis JS Scripte
4. simple ergonomische Verbesserungen z.B. Show/Hide funktion für vormals sichtbare Elemente
5. erweitern des (php/ruby) Code um Schalter zur Erkennung ob es sich um JS-initierte Abfragen handelt (xhr-requests)
6. erweiterte JS Funktionen z.B. direkte Auslieferung von vorherigen Zwischenseiten (z.B. Löschen Dialog) in einer Thickbox. Oder konsumieren vom xml/json Rückgabewerten aus nr. 5.
7. JS Tests / Packing

Wir machen ein Startup!!! 

Ole, ich und ein (noch) ungenannter Dritter haben  uns im Oktober letzten Jahres dazu entschlossen ein von mir vor ca. zwei Jahren initiiertes Projekt zu neuem Leben zu erwecken … den SalesKing …  eine webbasierte Software zur Verwaltung von Rechnungen / Kunden / Produkten und mehr.

Wer jetzt denkt der SalesKing war zu diesem Zeitpunkt schon begraben, irrt. Er war nur leider eines von vielen Projekten und bekam einfach nicht die Liebe die er verdient hatte.  Wir nutzen diese erste Version noch immer noch, doch erwarten schon ungeduldig die Auferstehung in neuem Gewand.

Die erste Version wurde von mir in php mit dem CakePHP Framework programmiert, doch genau da lagen die Gründe warum ich es nie veröffentlicht habe. Das Qualitätsmanagement in Bezug auf automatisiertes Testen ist einfach besch… Es gibt in PHP-Programmierer-Kreisen einfach keine ausgeprägte Testkultur und somit lassen die verfügbaren Tools schwer zu wünschen übrig. In der neuen Version setzten wir deshalb auf RubyOnRails.

Nach 4 Monaten kommen wir nun der privaten Beta Phase immer näher. Trotz dem zeitlichen Druck werden wir versuchen wieder etwas mehr zu bloggen und euch natürlich über den SalesKing auf dem neuesten Stand halten.