Zuvor aber eine kurze Erläuterung des Captcha-Verfahrens. Sicher ist jedem schon mal aufgefallen, dass bei Online-Anmeldungen oder beim Verfassen von Blog- oder Forenkommentaren merkwürdige Buchstaben- oder Zahlenkombinationen eingegeben werden müssen, um den Beitrag oder die Anmeldung durchführen zu können. Dies wird verwendet, um automatisierte Anmeldungen oder Kommentarspam zu verhindern. Man geht bei dem Verfahren davon aus, dass Maschinen und Skripte diese Zeichen nicht lesen können und somit nur der persönlich vor dem Bildschirm sitzende Anwender die richtige Kombination verwenden kann. Dieses Verfahren hat sicherlich seine Berechtigung, ist aber auch nicht unumstritten in der “Community”.

Auf alle Fälle als störend wird die allgegenwärtige Werbung a’la Google Adsense empfunden. Sie wird vom Besucher registriert, aber in der Regel ignoriert. Der viel zitierte Kontext ist meist auch nicht gegeben, oder zumindest fraglich. Aber das ist ein anderes Thema. Zumindest ist es der Versuch des Blog- oder Seitenbetreibers seine technischen Kosten zu decken oder sogar davon zu leben. Letzteres ist sicherlich weltweit nur einer Handvoll Bloggern gelungen.

Adaptcha jedenfalls verbindet jetzt beide Aspekte miteinander und verspricht, dass das Captchaverfahren genauso sicher sei, wie sein Zahlen- und Buchstabenpendant, und dass die Werbung nie wieder ignoriert wird. Genau im Gegenteil: man muss sich mit der Werbung auseinandersetzen, da die Captcha-Antwort in der Werbebotschaft zu finden ist. Sogar kleine Werbefilme soll man einbinden können.

Auf den ersten Blick mag nun der geneigte Leser zum Schluss kommen: ja, das hört sich doch super an; endlich zwei sinnlose, nervende Sachen zu einem einzigen, meist nicht zum Layout passenden Etwas vereint. Jemand anderes mag einwerfen: was wollt ihr; die Sachen sind doch eh immer da, dann doch lieber nur an einer Stelle, als die ganze Seite verschandeln.

So ähnlich gingen dann auch letzte Woche gleich die Diskussionen los. Sie gipfelten in der Aussage eines Freundes, dass er mit uns nichts mehr zu tun haben möchte, wenn wir derartiges in unsere Seiten einbauen würden.

Damit wird aber auch die ganze Bandbreite der Wahrnehmung deutlich. Aus Sicht der Werbetreibenden mag dieses Verfahren sicherzustellen, dass der Benutzer die Botschaft nicht ignoriert. Der Betreiber einer Site muss zum Thema “Klicken” nicht tricksen. Und der Anwender? Der muss, ob gewollt oder nicht, die Information verarbeiten. Gut, dass er dies nur zum Zeitpunkt der Anmeldung oder dem Hinterlassen eines Kommentars tun muss. Alternativ bliebe ihm sonst nur das Ignorieren der gesamten Site.

Insofern stellt sich die Frage: handelt es sich bei Adaptcha um eine Revolution der Online-Werbung oder doch nur um ein YAWOL (Yet Another Way Of Loitering)?

Knapp eine Woche später haben die Jungs aus Münster zwei neue Kunden, die sich die IT-Mischung bestellt haben und ein Paket wurde sogar mit der Feldpost nach Afghanistan geschickt.

Das ist echtes Internet Startup Feeling – I feel so Web Zwo Null

Wir werden sie begleiten und ihnen versuchen, eine Checkliste zu erstellen, die es ihnen ermöglicht, ihre simple Idee auch simple seien zu lassen.

Lasst mich kurz die Ausgangssituation beschreiben, damit die anstehenden Aufgaben klar werden.

Also, unsere zwei Protagonisten haben eine einfache Web-Idee, die wenig Entwicklungsaufwand für den Start erfordert. Sie haben sich dabei dem sogenannten agilen Entwicklungsweg verschrieben. Aus ihren anderen Web-Aktivitäten haben sie die notwendige Technik parat, die eigentlich nur noch zum Zusammenspiel koordiniert werden muss. Somit sollte die technische Seite in der Tat das geringste Problem darstellen.

Aber zu einem Unternehmen gehört mehr. Und zwar Geld. Ausgerechnet das haben die zwei aber nicht, zumindest nicht in Form exorbitanter Budgets. Somit wollen sie das Bisschen, das sie haben, auch effizient einsetzen.

Sie müssen sich um eine Organisationsform kümmern, die einfach und preiswert ist, sie im Fall des Misserfolgs aber nicht in den Abgrund reisst.

Und dann sind da noch die tausend anderen Kleinigkeiten, die das Leben so prickelnd machen und für einen immer währenden Strom der Freude und Arbeit sorgen.

Aber dazu mehr im zweiten Teil unseres Reports.

Nachdem ich gestern über BusinessModelle und Finanzierungen geschrieben habe und diese Hürde genommen würde geht es weiter mit der Infrastruktur.

Gerade hier zeigt sich, ob es sich beim Startup um eine Klitsche handelt, die gerade so überleben wird oder ein Startup das für mehr zu haben ist.

Inhalt:

• Serversicherheit für Startups
• Ausfallsicherheit von Web2.0 Startups
• Entwicklungs-, Test-, Produktionsumgebungen
• Automatisierte Tests
• Automatisches Deployment

Hört sich vielleicht erstmal hochtrabend an, aber es wird sicherlich jeder verstehen auch die VC’s und Unternehmensberater – quasi “Unternehmensberater ready”

Serversicherheit

Angriffe von Hackern, Crackern oder was auch immer, ob von innen oder außen. Hierüber muss man eigentlich keine Worte verlieren, außer vielleicht, wenn der Server nicht erreichbar ist, dann sind die Einnahmen gleich NULL. Sei dies nun durch einen Angriff oder aus irgendwelchen anderen Gründen.

Ausfallsicherheit

“Hast du für dein Startup eine Verfügbarkeitsanalyse?” oder noch schöner “Wie lange dürfen deine Seiten offline sein” oft wird dann mit Begriffen wie NIE oder “das geht gar nicht” hantiert.
Aber eine Hochverfügbare Weblösung braucht dann gewisse standards, die sich Web-Startups so gut wie nie leisten können. Hochverfügbarkeit hat ihren Preis. Die Administratoren hierfür auch. Redundante Server, Redundante Switche, doppelte Stromversorgung, USV, Backup und und und.
Also muss man irgendwo abstriche machen. Entweder an der Verfügbarkeit oder man muss sich eine andere Lösung überlegen mit der man halbwegs Leben kann

Entwicklungs- und Testumgebungen

Einige der neuen Web2.0 Startups arbeiten mit RubyonRails. Der Vorteil dieses Frameworks ist die Geschwindigkeit mit der entwickelt werden kann und vor allem viele kleine Tools, die bereits im Framework enthalten sind, die man bei anderen Sprachen, wie z.B. J EE das Tools ANT, extra mit in die Entwicklungsenviroments einbinden muss.

Auch die Entwicklungs und Testumgebunden bringt Rails von Hause aus schon mit. So kann man jeweils eine Datenbank für Development, Test und Produktion anlegen und auch verwenden.

Rails bringt sogenannte Migrations mit, die passend zu jeder Datenbanktabelle eine Migrationsscript mitbringt mit dem man auf die entsprechende Datenbankversion migrieren kann und weitere Tests durchführen kann/sollte !

Rundum sauber und sicher ist es dann wenn man mit den entsprechenden automatisierten Tests arbeitet. Jedes Modul, jede Funktion hat seinen eigenen Test. Verwendet man externe Module, dann kann man in der Regel davon ausgehen, dass diese bereits ausgiebig getestet wurden. Oder einfach erneut die mitgelierten Tests starten. Vertrauen ist gut – Kontrolle ist besser.

Automatisierte Tests

Integrtionstest, Modultests sind mehr als wichtig. Denn jedes Modul sollte bevor es von der Entwicklungsumgebung über die Test auf die Produktion kommt aus

Automatisches Deployment

Das automatische Deployment also die Anwendung vom Testserver auf den Staging Server und dann auf die Produktion zu spielen kann ganz easy mit GIT und Rake bzw. Capistrano gemacht werden. Manche Leute kennen sich mit Git,Rake,Capistrano wirklich verdammt gut aus. Sind aber im wirklichen Leben unbezahlbar – Danke

Ohne jetzt gleich wieder damit zubeginnen was Rails ist.

Rails ist cool

klar ist Rails cool und die Entwickler sowie die gesamte Community ist cool. Aber auch hier ist der schnöde Mammon, der der alles bestimmt. Konferenzen und Schulungen kosten mehr als ich in der Woche zum Leben habe.
Aber die Community steht zusammen und das Railscamp ist ein Beweis dafür, dass es auch günstiger gehen kann. (Leider schon ausgebucht)

Rails ist teuer

Naja nicht Rails an sich ist teuer. Sondern die Entwickler sind teuer. Denn immerhin bekommt man in der Regel keine PHP Scriptkiddies, die sinnlosen Spaghetticode zusammenbauen und sich dann freuen, dass es funktioniert.

Als die Railswelle hier nach Deutschland schwappe waren es überwiegen die J EE Entwickler, die bisher ihre Anwendungen mit JSF, JSP, Servlets oder Struts gebaut haben, die auf den Zug aufgesprungen sind. Agile Entwicklung kannte man bis dahin schon. Aber dass es auch so einfach sein kann, war genial. Man stürtze sich auf Active Record, Objektorientierte Programmierung und Migrations, weil es genial war iterati zu Entwicklen.

Rails kann solide sein

Wer gut programmiert kann auch gute Railsapplikationen schreiben. Das Grundprinzip von sauberem und vor allem wartbaren Code gilt hier wie überall anders auch. Wenn die Basis stimmt, dann kann man mit Rails sehr sehr guten Code entwickeln, mit sehr weniger Aufwand. Aus diesem Grund ist …. Rails verdammt schnell.

Rails ist schnell

Mit Rails kann man schnell Ergebnisse erzielen. Aber man kann ich auch sehr schnell auch ins Abseites schiessen, wenn man grundlegende Konzepte der Softwareentwicklung besonders aber der OOP außer acht läßt. Dann kann man schnell seinen Server überlasten. (ganz nebenbei, das konnte mein Wordpress aber auch)

In einer Zeit wo Web zwo Null Startups auf der Bildfläche erscheinen und genauso schnell wieder verschwunden sind wie sie da waren, sollte man auf ein Pferd setzen, dass nicht zuletzt guten Code abliefert. Da hinkt das Pferdebeispiel, denn da kommt hinten immer nur Mist raus. Aber egal.

Wir haben mit unsere Social News Plattform Poppster auf Rails gesetzt und bisher keine Minute bereut, dass wir es getan haben. Logisch ist aller Anfang schwer, aber das gestern beschriebene Deployment steht (vielleicht postet Fritz hier auch was dazu), der Server läuft stabil. Jetzt können die User kommen. Aber gerade genau hier liegt das Problem. Woher kommen die User? Woher der Traffic? Und vor allem welchen Sinn hat Poppster?

Das erfahrt ihr wenn ihr weiterhin brav mitlest.

Die Antwort darauf versucht jeder Glücksritter im Web zu finden. Hier ist nun die Wahrheit…

Zunächst einmal werden werden wir hier öffentlich unser Seelenleben ausbreiten. Und Euch daran teilhaben lassen, wie man von NULL auf 100 mit einem Startup startet. Manchmal mit ein paar riskanten Aktionen, manchmal mit solider Infrastruktur, die ein Supergau, wie beim Yigg Relaunch vermeiden sollte. Vor allem aber werden wir auf die wichtigsten Faktoren bei vielen Internet Startups eingehen.

Das Geld, Knete, Kohle, Zaster oder Cash genannt.

Oft – viel zu oft- wird hier auf externe Geldgeber oder BusinessAngels zurück gegriffen, die dann wiederum das weitere Geschehen bestimmen.

Wächst das Startup zu langsam foppen sich die Gründer selbst, startet es zu schnell, dann kommt man in die Lage, dass man mehr Arbeit als Arbeitskräfte hat und so beisst sich immer wieder die Katze in den Schwanz.

Wir wollen zwar nicht alles anders machen, aber ein paar Feinheiten haben wir hoffentlich gelernt. …..