Endlich Live: Tripmondo im Public Beta Stadium

[nhaack]

Hallo zusammen,

hier ist sie nun: http://www.tripmondo.com

Tripmondo ist ein privates Projekt in das ich eine Menge Freizeit investiert habe (zuviel wenn ihr mich fragt ). Obowhl noch mit einigen bugs behaftet und mit eingeschränkter Funktionalität bin ich soweit die Plattform freizuschalten. Ich habe jetzt etwa 9 Monate an der Site gebastelt. Da ich bis dato kein großer Programmier war, musste ich eine Menge von Allem lernen. Allerdings hatte ich für das Front-End und die Server Konfiguration tolle Unterstützung von Freunden.

Mittlerweile wurde wahrscheinlich alles zweimal programmiert und ich könnte sicherlich noch einen dritten Anlauf durchführen, da ich vieles mittlerweile anders machen würde. Aber wie sagte schon Shakespeare so schön "Things won are done, Joy's soul lies in the doing".

Tripmondo.com ist eine CMSMS basierte Aggregator-Seite, die Informationen zu Reise-Destinationen zusammenträgt. Sie versucht einen strukturierten Blick auf Reiseführer, Wetter, Attraktionen und Sightseeing Tips, videos, twitter, wikipedia, photos, events und anderen Quellen zu ermöglichen.

Wie gesagt, es handelt sich hier um einen öffentlichen beta-Test, somit kann es durchaus das ein oder andere Mal zu Problemen kommen (z.B. noch nicht auf Validität getrimmt etc).

Die Site versucht Informationen für Reisende zusammenzustellen, die wissen, dass es in den Urlaub gehen soll, aber vielleicht noch nicht wohin. Das Ganze ist noch sehr experimentell. So ist die Navigation größtenteils adaptiv und Context-abhängig. Zudem gibt es keine Hierarchy, wie durch die URLs suggeriert. Alles wird quasi Live zusammengewürfelt und aus XML/JSON REST APIs zusammen gezogen oder mit eigenen Datenbanken angereichert.

Hier ein paar Funktionen auf die ich besonders "stolz" bin:

-> Geocoding Service: interner Geocoder der auf einer DB mit ~5m Einträgen basiert und eine Suche nach Flughäfen (noch nicht angezeigt), nahegelegenen Orten oder Attraktionen ermöglicht. Reverse Geocoding und das Hinzuziehen der Google Geocoding API in Zweifelsfällen sind weitere Besonderheiten.

-> Der Trip-Explorer: er macht die meiste Arbeit und funktioniert mittlerweile recht zuverlässig. Nur bei kleinen Orten/Dörfern oder im tiefsten Asien hat er manchmal Probleme. Da gerade diese Seiten sehr Live-Daten intensiv sind, kann es hier manchmal doch noch zu recht nervigen Verzögerungen kommen.

-> Suche: Sie basiert auf der normalen CMSMS internen Suche, duchforstet aber gleichzeitig auch die anderen Datenquellen (soweit es geht). Sie wird durch den flexiblen Geocoder unterstützt um auch Typos bei Ortsangaben abzufangen.

-> Cloud-basierte Content- und Ad-Schnippsel: die Site kann context-sensitiv oder auf Tag-Basis Inhalte in Seiten einbauen. Zugleich wird die Conversion dieser Elemente überwacht, so dass die Site eigenständig Entscheidungen treffen kann um sich selbst zu optimieren (allerdings ist aktuell noch keine Werbung eingebaut).

Das größte Problem ist aktuell noch die Performance. Obwohl die Site auf einem dedizierten Root Server mit viel RAM und CPU läuft (und PHP/MYSQL caching), sorgt das Warten auf Antworten externer Server doch für manchmal zu lang empfundene Wartezeiten. Hier müsste man aber nochmals grundlegend in die Architektur eingreifen... das kommt dann später. Es ist also nicht so, dass CMSMS langsam läuft (eine nackte Installation läuft auf der Maschine wie Sau).

Ich bin gespannt wie ihr es findet. Was würdet ihr euch wünschen, was gefällt und was nicht?

Beste Grüße
Nils

[NaN]

Ersteinmal danke für die ausführliche Vorstellung Deiner Seite.
Das Layout ist auch gelungen. Einfach und übersichtlich.
Das Logo gefällt mir.
Die Validierungsfehler halten sich in Grenzen. Sind bis auf die IDs beim Submitbutton des Suchmoduls wahrscheinlich alles nur Tippfehler.
( wird z.B doppelt geschlossen oder anker link wird als inhaltsleer dargtestellt, was zwar stimmt aber irgendwie doch nicht valide ist...)

Hab die Seite zwar bisher nur überflogen, aber was all diese automatischen Funktionen angeht, bin ich wirklich beeindruckt.
Da muss ich mir echt mal mehr Zeit für diese Seite nehmen.

Gefällt mir.

Ich finde 9 Monate Arbeitszeit sind dafür durchaus zu verkraften

[nockenfell]

Wow. Da springt einem die Arbeit dahinter förmlich an. Tolle Arbeit hast du geleistet!

Wieviel von deiner Seite über verschiedene Destinationen kommt aus der eigenen DB und wieviel holst du von extern?

[nhaack]

Danke für das positive Feedback - Das tut echt gut nach der ganzen Arbeit.

Aus der eigenen DB kommt primär das Geocoding. Im Grunde auch die Reports und die Attractions, wobei diese als XML und FTP angeliefert werden, sie liegen nur in der DB weil ich dann viel mehr Sachen mit den Daten machen kann. So hatte ich hier erst leere Platzhalterseiten, über deren Alias ich dann die passende XML Datei ausgewählt habe. Bei über 3000 Artikeln wurde mir aber schnell klar, das dies 'ne Menge Arbeit ist und in exsessive File-Aktionen ausarten würde.

In der ersten Version lief alles über APIs, da aber inbesondere im Trip-Explorer allein bis zu 20 oder 30 geocoding Aktionen durchgeführt werden, hat dies dann in Summe bis 60-90 Sekunden gedauert bis die Seite da war, daher fiel die Entscheidung einen eigenen Geocoder zu programmieren und soviel wie möglich über eine DB laufen zu lassen.

Das führte zu neuen Problemen. Ich nutze z.T. die URLs zum Auflösen von Orten (mapping der URl auf GET Parameter), d.h. ich muss einen Stringvergleich gegen die Tabelle mit Ortsnamen führen. Bei der entsprechenden Anzahl an Einträgen kann das auch ziemlich lange dauern (jetzt war ich bei etwa 10 Sekunden Geocoding-zeit) pro Seite . Hierfür nutze ich nun verschiedene mySQL Indizes. Ich versuche, für einen Match alle notwendigen Daten bereits im index zu führen, somit muss der geocoder z.B. nicht direkt auf den Table zugreifen um einen Aufgabe zu lösen, sondern nur auf einen bestimmten Index. Auch wird der mySQL Cache intensiv genutzt.

Für das PHP Caching verwende ich eAccelerator. Das Ding hat unglaublich viel gebracht. Ich habe ein kleines Lasttest-Template geschrieben. Waren am Anfang nur etwa 1000 Berechnungen pro Minute drin waren, hat es zum Schluss für weit über 10.000 Berechnungen gereicht. D.h. allein das PHP Caching hat die Plattform etwa um den Faktor 10x schneller gemacht.

Über die Datenbank laufen die Funktionen Tracking/Monitoring, Travel-Reports, Attractions, Rating, Suche, Geocoding. Im Ganzen sind dies bestimmt an die 15 Plug-ins die diese Funktionen steuern.

Alles was den Geschmack von Social Media hat wird quasi Live-gezogen, wobei zur Entlastung der API Anfragen die Daten nicht mit jedem Request neu geladen werden, sondern unterschiedliche Cache-Lebenszeiten haben (Youtube z.B. länger als Twitter oder Webcams). Ergebnisse von relativ statischer Natur werden sehr lange vorgehalten (z.B. Wikipedia oder Google Geocoder... so schnell läuft 'ne Stadt ja nicht weg). Für diese ganzen Plattformen habe ich 12 Plug-ins geschrieben.

Das schöne ist, der Core ist absolut unverändert, alles wurde über Plug-ins und Smarty gelöst, ggf. noch URL Rewriting.

Aber zurück zur Frage, im Endeffekt ist die DB auch weitestgehend mit externen Daten bestückt. Sie umfasst ohne Indizes etwa 1 GB, wurde aber z.T. durch selbst generierte Daten erweitert oder mit anderen Quellen angereichert, so dass sie nun etwa 1,5GB groß ist. Man hätte das meiste weiterhin von extern holen können, aber die Scriptlaufzeiten würden dann zu lang für eine halbwegs vernünftige Usability sein (auch wenn ein Server nur eine 1/10 Sekunde für die Antwort braucht, bei 40 Abfragen sind das 4 Sekunden, dazu kommt der Download und das Verarbeiten). Wenn man also den Ursprung der Daten betrachtet kommt aktuell fast 95% der Daten von extern. Etwa 40% davon halte ich durch DB Tables permanent vor, etwa 50% liegen i.d.R. im Cache vor und 10% sind wirkliche Live-Daten.

Und nochmal zu den 9 Monaten... zweimal wollte ich zwischendurch wirklich fast aufgeben, doch ich dachte ich habe schon zu viel dafür gemacht um jetzt aufzuhören. Das war quasi mein Sommer ich hab natürlich auch mal das schöne Wetter genossen, aber viele Wochenenden schien die Sonne und der Mond ins Arbeitszimmer... und ich hab' beides mitbekommen... ich hab extrem viel gelernt aber so manchesmal hätte ich auch kotzen können (encoding... ENCODING... ICH HASSE ENCODING... aber jetzt komme ich damit klar... ).

Ich bin jedenfalls mittlerweile davon überzeugt, dass es kaum etwas geben dürfte, was man nicht mit CMSMS und ein paar Plug-ins bauen kann. An dieser Stelle auch nochmal ein ganz dickes THANK YOU DEVELOPERS - THANK YOU FORUM . Für das CMS, die Plug-ins, Code-Schnippsel, Diskussionen etc pp. CMSMS läuft auf ner ordentlichen Maschine wirklich sau schnell, sehr zuverlässig und stellt für eigene Erweiterung ein quasi Chaotentaugliches Content- und Verwaltungs-Framework zur Verfügung. Das ist Rock'n'Roll

Ach ja, folgende Module kamen zum Einsatz:

-> CGExtensions
-> CGFeedmaker
-> CGSimpleSmarty
-> CMSSimplepie

Beste Grüße
Nils

[cyberman]

Jetzt weiß ich, warum du so lange nicht mehr hier zu sehen / lesen warst  .

Geniale Seite - und ein perfektes Beispiel, was mit CMSms alles geht. Extern hat man zu oft den Eindruck, dass CMSms als Einsteiger-CMS betrachtet wird und mit anderen (ungenannten  ) CMS nicht mithalten kann.

Aus der eigenen DB kommt primär das Geocoding. Im Grunde auch die Reports und die Attractions, wobei diese als XML und FTP angeliefert werden, sie liegen nur in der DB weil ich dann viel mehr Sachen mit den Daten machen kann.

Läuft das über ein Modul oder nur über einen Tag?

Würde mich interessieren, ob man das Geocoding an ein Modul andocken kann (CompanyDirectory) ... Stichwort Dienstleisterverzeichnis .

[nhaack]

Hi Cyberman,

das Geocoding ist im Grunde so konzipiert, dass es mit allem möglichen verbunden werden kann. Wenn man die Geo-DB in den eigenen Server einspielt und das Plug-in verwendet sollte das eigentlich kein Problem sein. Es läuft alles über Tags (in der Tat habe ich für die Site nicht ein einziges Modul geschrieben).

Sehr viel wird halt auch mit Smarty gemacht. Mit einem Tag fahre ich meine Abfrage, in Smarty verarbeite ich die Ergebnisse und löse ggf. Fallback Szenarien aus und dann rufe ich damit weitere Datenbanken per Tag auf.

Der Workflow sieht im grunde oft so aus:

URL Parameter -> Smarty -> Geocoding -> Smarty -> weitere Tags und DBs -> Smarty -> anreichern mit weiteren Tags -> Smarty -> Ausgabe

Jetzt habe cih ja hoffentlich wieder etwas mehr Zeit, ich werde mich mal daran machen den Geocoder etwas aufzubereiten und hier vielleicht bereit zu stellen (oder vielleicht als Tutorial zum nachbauen).

Beste Grüße
Nils

[nicmare]

wow. da bin ich jetzt echt baff!!
leider hab ich noch keine zeit gehabt im detail hier zu lesen und dort zu gucken aber was ich bisher sehe ist der hammer.
und die performance ist auch sehr sehr gut. leider gibt es noch reichlich validierungsfehler.
respect!

[nhaack]

Jetzt weiß ich, warum du so lange nicht mehr hier zu sehen / lesen warst  .

Ja das stimmt schon - ich habe aber versucht das wichtigste mitzubekommen. Besonders darunter gelitten haben aber meine veröffentlichten Plug-ins, da gibt es schon Bug Reports und ich muss da echt mal dringend ran. Das ist mir schon unangenehm - jetzt brauche ich aber erstmal ein Coding Päuschen, dann fix ich das alles... (soviel ist es auch nicht... aber das ist das schlimme daran).

Würde mich interessieren, ob man das Geocoding an ein Modul andocken kann (CompanyDirectory) ... Stichwort Dienstleisterverzeichnis .

Sowas hatte ich bei der Entwicklung im Hinterkopf . Der Geocoder würde auf der Ebene eines oder einiger ausgewählter Länder sicherlich wesentlich schneller und zuverlässiger Arbeiten. Aktuell basiert der Datenstamm auf englischen Ortsnamen. Für z.B. nur DE alleine geht das auch noch detaillierter. Für Ortsnamen basierte Directories ist der Geocoder also ideal. Es lassen sich dabei auch prinzipiell noch mehr Zwischenebenen Anlegen (z.B. DE -> Bayern -> München -> Zentrum). Interessant wäre, hier eine Variante mit den Daten von openstreetmap.org zu bauen. Vielleicht kann man hier eine Art Musterlösung bauen.

und die performance ist auch sehr sehr gut. leider gibt es noch reichlich validierungsfehler.

Freut mich, dass die Site gut läuft. So langsam füllen sich auch die Caches, das macht es flotter . Das mit der Validierung nervt mich auch. Aber ich hab gedacht, ich kann nicht ewig dran rumdocktern .  Werde jetzt mal ein paar Wochen laufen lassen und dann nochmal ne Fix-Runde machen.

Beste Grüße
Nils

[cyberman]

Würde mich interessieren, ob man das Geocoding an ein Modul andocken kann (CompanyDirectory) ... Stichwort Dienstleisterverzeichnis .

Sowas hatte ich bei der Entwicklung im Hinterkopf . Der Geocoder würde auf der Ebene eines oder einiger ausgewählter Länder sicherlich wesentlich schneller und zuverlässiger Arbeiten. Aktuell basiert der Datenstamm auf englischen Ortsnamen. Für z.B. nur DE alleine geht das auch noch detaillierter. Für Ortsnamen basierte Directories ist der Geocoder also ideal. Es lassen sich dabei auch prinzipiell noch mehr Zwischenebenen Anlegen (z.B. DE -> Bayern -> München -> Zentrum). Interessant wäre, hier eine Variante mit den Daten von openstreetmap.org zu bauen. Vielleicht kann man hier eine Art Musterlösung bauen.

Klingt optimal - DE,AT,CH würde reichen ... aber gönn dir erst mal 'ne Pause  .

[SimonSchaufi]

auch von mir noch ein Lob!
Wie hast du das mit den zuletzt besuchten Seiten gemacht? Kannst du das veröffentlichen?

[nhaack]

Hi Simon,

das mit den zuletzt besuchten Seiten funktioniert wie folgt: Ich schreibe immer die aktuelle Seite in ein Array das in der Session liegt (Das Array enthält jeweils URL und Title). Danach gebe ich es rückwärts wieder aus. Wenn ich wieder in Hamburg bin werde ich den Code hier mal posten.

Beste Grüße
Nils

[nhaack]

Hi Simon,

hier einmal das UDT für den Usertrail (die UDTs habe ich ganz vergessen zu erwähnen ... das sind auch etwa 50-60)

UDT: create_user_trail

Code: Select all

// Create Class for Usertrail Element
$trail_position = new StdClass;
$trail_position->url = $params['url'];
$trail_position->title = $params['title'];
 
// is usertrail existing?
if (isset($_SESSION['trail'])) {
	$buffer = count($_SESSION['trail']);
	$found = false;
	// check if current page is already in the list
	for ($i=0; $i<=$buffer-1; $i++) {
	 if ((string)$_SESSION['trail'][$i]->title == (string)$trail_position->title){$found=true;}
	}

	// current page does not exist in trail
	if ($found != true) {
		// is trail already 6 Steps long
	   if ($buffer == 5) {
		 // delete first element
		 unset($_SESSION['trail'][0]);
		 $_SESSION['trail'] = array_values($_SESSION['trail']);
		 // add current page to trail
		 $_SESSION['trail'][] = $trail_position;
	   } elseif (($buffer < 5) AND ($buffer >= 0)) {
		 // trail is shorter than 6 elements or at least 0 elements large
		 $_SESSION['trail'][] = $trail_position;
	   }
	}

// usertrail is not yet existing   
} else {
     unset($_SESSION['trail']); 
     $_SESSION['trail'] = array();
     $_SESSION['trail'][] = $trail_position;
}

// return user trail as reversed array for smarty
$result =  $_SESSION['trail'];
$smarty->assign('trail', array_reverse($result));

Wie folgt im Template zu benutzen (Variabeln müssen selbst befüllt werden oder eigenen String angeben):

Code: Select all

{* Aktuelle Seite zum Trail hinzufügen *}
{create_user_trail url=$canonical title=$menu_title}

{if $trail != false}
  <p class="breadcrumb">You came this way:
    {foreach from=$trail item=item}
      {if $item->title != $trail[0]->title} » {/if}
      <a href="{$item->url}">{$item->title|truncate:30:"..."}</a>
    {/foreach}
  </p>
{/if}

Das Ganze ist noch etwas schlampig zusammengesetzt, sollte aber im Grunde zuverlässig laufen. Bei Rückfragen einfach melden.

Übrigens: Tripmondo war bei programmableweb.com "Mashup of the day" am Wochenende

Beste Grüße
Nils