Nun sind wir gerade dabei die Idee mit dem Bleistift aufzuspiessen und das ganze zu Papier zu bringen. Vielleicht ist es dann in einem Stadium, dass man sagen kann die Idee hat eine Chance oder die Idee wandert gleich wieder in den Papierkorb.

Was es genau sein wird werden wir vorerst nicht verraten. Es hat aber auf jeden Fall etwas mit Euch zu tun. Und es ist definitiv etwas das jeder brauchen wird, bisher aber noch keiner kennt.

Nein kein Twitter-Clone, kein neues Ebay und schon gar kein Google Killer.

Was das genau ist, bleibt unser Geheimnis. Aber so viel vorweg: es ist etwas Neues und es ist einfach (verdammt einfach!)

Server, Technik und Administrationsoberflächen

Davor haben wir aber erstmal noch mit der Technik zu kämpfen. Stichwort: Domainumzug. Aufmerksame Leser unseres Blog haben sicherlich festgestellt, dass wir umgezogen sind. Die Domain wurde umgezogen.
Soweit so gut.
Das neue zuhause des Blogs ein VServer, leider erstmal mit einer SuSE 10.3 – wer Suse kennt – ohne Worte. Für alle anderen, die nicht gerade seit über 8 Jahren mit SuSE Linux vertraut sind: SuSE macht alles anders als alle anderen und ändert dort, wo man eigentlich keine Änderungen erwartet.

Dazu kam dann noch eine sehr schöne Administrationsoberfläche, die sämtliche Rechte des Webservers so verbogen hat, dass man mit selbigen nichts aber auch gar nichts mehr anfangen konnte.

Neuinstallation des Linux

Dritte Neuinstallation des OS geglückt. (Nichts gegen virtuelle Server und die Möglichkeit, Images schnell einzuspielen). Jetzt noch ImageMagick (jeder weiss, welche Pein das sein kann), Ruby Enterprise Edition und Passenger installieren und es läuft alles – auf der staging area. Dem Production Server noch eine zweite IP-Adresse verpassen, den Apache auf diese aufmerksam machen und dem Deployment steht nichts mehr im Wege. Oder? Doch, das deploy-Skript muss noch geschrieben werden – und das über die stages hinweg

Fazit: Entwicklung einer Applikation ist nur ein Stück des Kuchens. Diese dann der Öffentlichkeit in der richtigen Art und Weise zu präsentieren, ist der andere Teil.

Was ist Mplace?

Das werdet ihr erfahren, wenn Mplace die ersten Schritte in Richtung Web2.0 Welt bestreitet. Also unbedingt den RSS-Feed des Blogs abonnieren oder uns bei Twitter followen.

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)?

Auf dem Railscamp hat Tamer seinen Kaffee mitgebracht und es war einfach der genialste Kaffee aller Zeiten. Schade nur, dass wir nicht sofort kaufen konnten.

Heute habe ich dann was über die Wirkung von Kaffee und Koffein gefunden.

(c) Sonntag Morgen

Leider habe ich z.Zt. weder Kaffee von Sonntagmorgen bei mir hier noch eine entsprechende Maschinen, aber ich habe mir sagen lassen, die Lieferungen wären schnell und effektiv.

Gleich mal testen und wehe wenn nicht. Dann schicke ich Euch Simon Peters aus Köln vorbei. Insider wissen werde das ist.

So und jetzt wollen wir wieder ernsthaft werden.

Wenn ich mich recht zurück erinnere habe ich auf dem Railscamp immer von der IT-Mischung gekostet.

IT-Mischung

Augen auf! Der Tieflandkaffee Robusta Indian Parchment enthält gut doppelt so viel Koffein wie ein Arabica und hat 10 % anregende Chlorogensäure. Eine ähnliche Konzentration hat sonst allenfalls Mate-Tee. Dazu mischen wir eine Prise Java (das ist auch eine Insel!).

Lecker, Lecker, Lecker ….

Aber beginnen wir dort, wo man beginnen sollte: am Anfang.

Betrachten wir so ein Unternehmen mal wie ein Projekt, was würden wir als erstes tun? Richtig, ein Ziel definieren. Diese Zieldefinition sollte eine Beschreibung der Idee sein und wie die Beteiligten ihre Rolle auf dem Weg zur Erreichung sehen. Damit hätten wir zumindest den Gegenstand unseres Handelns und uns selbst definiert. Dies muss nicht in einem Pamphlet biblischen Ausmaßes enden, wenn man in der Lage ist, alles in knackigen Worten in einen Absatz zu bekommen. Das Machwerk names Businessplan kommt später.

Wenn wir also wissen, was zu machen ist, müssen wir jetzt klären, wie wir es anstellen. Dazu sollte die zweite Phase unseres Projektes dienen: die Planung. Das umfasst, wie sich unsere zwei Protagonisten organisieren sollten (sowohl grundsätzlich, also als Firma, und bezogen auf die Aufgabe der Umsetzung der “technischen” Idee, also die Projektorganisation). Da der grundsätzliche Organisationsteil meist mit weitreichenden Folgen verbunden ist, sollte man hier wenn möglich jemanden zu Rate ziehen. Die Projektorganisation sollten beide hinbekommen, da sie aus dem Projektumfeld kommen.

So, wir wissen jetzt was wir wie tun wollen. Dann geht es jetzt an das Umsetzen. Für diese Phase gibt es, außer ein paar gut gemeinten Ratschlägen und der Hinweis zum Einhalten der selbstgesteckten Grundsätze, wenig zu sagen. Es wird die erste Nagelprobe der beiden werden. Und ob einfach wirklich einfach ist. Auf alle Fälle sollten die beiden getreu dem Grundsatz der “Getting Real”-Bewegung häufig und schnell etwas Online stellen.

Das führt uns aber zum nächsten Punkt (wenn wir davon ausgehen, dass die Testphase Bestandteil der Realisierung ist): der Transition (in gutem Neudeutsch). Also die Überführung der entwickelten Idee in den Betrieb. Jetzt wird der ein oder andere anmerken, dass wir doch kein großen IT-Projekt mit tausenden involvierten Mitarbeitern in Produktion bringen. Richtig, vordergründig würde man sofort an diese Größenordnung denken. Aber egal welche Größe ein Projekt hat, eine Transition sollte in jedem Fall durchgeführt werden. Fällt sie halt nicht so kompliziert aus. Einfach ist das Zauberwort. Bei agilem Entwicklungsansatz wird sich diese Transition sowieso in Portionen immer wieder wiederholen. Das trainiert.

Jetzt kann das Geldverdienen losgehen. Und auch das will mit Bedacht getan werden. Mir fällt zwar keine Phase mehr ein, aber sicher finden sich auch hierfür ein paar schlaue Worte.

Jetzt sollten wir doch den groben Fahrplan haben, oder? Ins Detail gehe ich dann in den Fortsetzungen. Und zwar Schritt für Schritt. Andere entwicklen in der Zeit zwar komplette, funktionierende System (siehe letzter Railsrumble), aber stehen dann da mit ihrem System und haben keine Organisation drumrum

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. …..

Aber woran scheitern die meisten Startups im Internet und warum können einiges Startups nicht Fuss fassen andere hingegen umso besser?

Zunächst ist es erstmal wichtig, dass man sich überlegt ob und wie man seine Brötchen verdienen will. In vielen Fällen ist “Werbung” das Schlagwort. Richtig abhängigkeit von Google, Yahoo und anderen Werbepartner und die User sollens dann richten, in dem sie auf die entsprechenden Werbeads klicken.

Ständig fallen aber Klickraten, sprich die Unternehmen, die auf “werbefinanziert” gesetzt haben verdienen weniger. Die Kosten werden aber durch den Erfolg des Internetauftrittes höher und höher. Es reichen dann nicht mehr nur einfache Praktikanten, sondern es müssen dann richtig IT-Fachkräft ran. Oftmals liegt hier der Stundensatz bei Freelancern jenseits der 100 Euro pro Stunde, nach oben hin, wohlgemerkt.

Die Kosten werden höher die Einnahmen geringer. Man muss kein Prophet sein um zu wissen, dass dieses Rechenexempel letztlich vor dem Venture Capitalist oder beim Auktionator landet. Bekanntes Beispiel hierfür ist wohl Townster, steht jetzt bei Ebay zum Verkauf, für knapp 22.000 Euro (genau genommen sind es: 22.222 Euro) soll das ehemalige Vorzeigestartup bei Ebay verkloppt werden.

Aber was steckt denn jetzt an mehr BusinessModell in Townster als vorher? Wie soll man mit Townster Geld verdienen? Onlinewerbung?

FAkt ist dass man mit einer Community Geld verdienen kann, wenn man den richtigen Ansatz wählt. Wenn man allerdings darauf hofft irgendwann einen Geldgeber zu finden und keinerlei BusinessGedanken an das Startup verschwendet ist in Deutschland nicht wirklich gut aufgehoben.

Die Lösung wäre dann schon eher einen VC oder BusinessAngel zu suchen, der einen Unterstütz, aber was ist dann die Idee noch wert? Der VC sagt wo es lang geht man opfert sich für die eigene Idee und der VC bestimmt die Marschrichtung? Ein Startup ohne VC zu starten bedarf wirklicher Motivation und durchhalte vermögen. Manchmal kommt die Familie zu kurz häufig wird man zum genervten Manager und wirft alle Ideale über Board. zuletzt streitet man sich und landet bei Ebay.

Nichts desto weniger glaube ich an meine Idee ….