Ohne Worte
Sonntag, 16. September 2007
Zugegeben, es ist viel zu lesen... Aber auch sehr interessant!Zugegeben, es ist viel zu lesen... Aber auch sehr interessant!Google SEO um jeden Preis
Samstag, 15. September 2007
Meine Seiten sind selten Suchmaschinen optimiert (SEO). Weder für Google, noch für eine andere Suchmaschine. Der Hauptgrund dafür ist, dass ich einfach keine Zeit habe. Nicht unwichtige Gründe sind außerdem, dass ich keine große Lust dazu habe, und dass es mir meistens relativ wurscht ist, wie viele z. B. diesen Blog lesen.
Auf der anderen Seite bin ich aber auch der Meinung, dass man mit SEO durchaus noch ein quentchen mehr an Besuchern rausholen kann. Das wichtigste auf einer Seite ist aber nicht die Optimierung, sondern vor allem, dass der Besucher am Schluss gerne auf der Seite war, und wieder kommt. Vielleicht sogar anderen davon erzählt, und darüber weitere Besucher kommen.
Somit achte ich vor allem darauf, dass es mir selber Spass macht, über meine Seiten zu surfen. Dass also z. B. die Navigation logisch ist. Der Inhalt einer Seite vor der Optimierung kommt, oder sich beides nicht stört. Falls Werbung notwendig ist, so achte ich darauf, dass Sie nicht übermäßig stört, und vor allem nicht im Weg ist, wenn man den eigentlichen Inhalt erfassen möchte...
Was ich aber wirklich unprofessionell finde, ist das anbringe von visuell versteckten Links. Also Links, die durch CSS oder ähnliches vor dem Besucher versteckt werden, aber von Suchmaschinen erkannt, und bewertet werden. Muss das unbedingt sein, so sollte man peinlichst darauf achten, dass es bei allen Browsern zu keinen Darstellungsfehlern. Ein nicht geglücktes Beispiel sieht man rechts auf dem Ausschnitt!
Der Ausschnitt zeigt einen Teil der Seite www.mainwelle.de. Markiert man nun auf besagter Seite die gesamte Seite mit Apfel+A, so bekommt man ein paar Links mit sehr kleinem Text zu sehen:
Hier wird also auf einer relativ populären Seite für vier weitere Seiten Werbung gemacht. Ich weiß nicht, ob das im Interesse der Betreiber, also Radio Mainwelle ist. Meine Anfrage per Email wurde bisher nicht beantwortet. Sollte da noch etwas kommen, so reiche ich das noch nach...
Folgt man den Links jedoch, findet man auf ein paar Seiten noch schlimmere Google Optimierungen. Die zwar auch relativ weit verbreitet sind, aber noch viel unschöner aussehen. Hier wurde am Ende der Seite recht viel Platz gelassen und anschließend diverse Suchbegriffe platziert. Sowas würde ich einem Kunden schon nicht mehr anbieten wollen:
Im Endeffekt muss natürlich der Kunde entscheiden, aber ich finde das nicht sonderlich schön. Wie weit das wirklich etwas bringt, sei auch mal dahin gestellt. Klar kann man damit Suchende einfangen. Nur was bringt das, wenn diese dann im Endeffekt die Seite sofort wieder verlassen, oder bei einem Shop nichts kaufen? Viele Besucher sind nicht gleichbedeutend mit viel Erfolg einer Seite! Auch wenn das scheinbar viel zu oft vergessen wird...
Auf der anderen Seite bin ich aber auch der Meinung, dass man mit SEO durchaus noch ein quentchen mehr an Besuchern rausholen kann. Das wichtigste auf einer Seite ist aber nicht die Optimierung, sondern vor allem, dass der Besucher am Schluss gerne auf der Seite war, und wieder kommt. Vielleicht sogar anderen davon erzählt, und darüber weitere Besucher kommen.
Somit achte ich vor allem darauf, dass es mir selber Spass macht, über meine Seiten zu surfen. Dass also z. B. die Navigation logisch ist. Der Inhalt einer Seite vor der Optimierung kommt, oder sich beides nicht stört. Falls Werbung notwendig ist, so achte ich darauf, dass Sie nicht übermäßig stört, und vor allem nicht im Weg ist, wenn man den eigentlichen Inhalt erfassen möchte...
Was ich aber wirklich unprofessionell finde, ist das anbringe von visuell versteckten Links. Also Links, die durch CSS oder ähnliches vor dem Besucher versteckt werden, aber von Suchmaschinen erkannt, und bewertet werden. Muss das unbedingt sein, so sollte man peinlichst darauf achten, dass es bei allen Browsern zu keinen Darstellungsfehlern. Ein nicht geglücktes Beispiel sieht man rechts auf dem Ausschnitt!Der Ausschnitt zeigt einen Teil der Seite www.mainwelle.de. Markiert man nun auf besagter Seite die gesamte Seite mit Apfel+A, so bekommt man ein paar Links mit sehr kleinem Text zu sehen:
Hier wird also auf einer relativ populären Seite für vier weitere Seiten Werbung gemacht. Ich weiß nicht, ob das im Interesse der Betreiber, also Radio Mainwelle ist. Meine Anfrage per Email wurde bisher nicht beantwortet. Sollte da noch etwas kommen, so reiche ich das noch nach...
Folgt man den Links jedoch, findet man auf ein paar Seiten noch schlimmere Google Optimierungen. Die zwar auch relativ weit verbreitet sind, aber noch viel unschöner aussehen. Hier wurde am Ende der Seite recht viel Platz gelassen und anschließend diverse Suchbegriffe platziert. Sowas würde ich einem Kunden schon nicht mehr anbieten wollen:
Im Endeffekt muss natürlich der Kunde entscheiden, aber ich finde das nicht sonderlich schön. Wie weit das wirklich etwas bringt, sei auch mal dahin gestellt. Klar kann man damit Suchende einfangen. Nur was bringt das, wenn diese dann im Endeffekt die Seite sofort wieder verlassen, oder bei einem Shop nichts kaufen? Viele Besucher sind nicht gleichbedeutend mit viel Erfolg einer Seite! Auch wenn das scheinbar viel zu oft vergessen wird...
Datenbank unter OSX designen
Dienstag, 11. September 2007
Heute in der Firma musste ich mal wieder eine Datenbank entwickeln. Alle paar Wochen oder Monate stehe ich dann vor der Aufgabe, welche Software ich dafür verwende.
Unter Windows und Linux war die Entscheidung meist relativ einfach. Es gibt viele Programm und die meisten sind ganz brauchbar. Irgendwie bin ich über die Jahre bei DBDesigner hängen geblieben. Die Software hat sich die letzte Zeit kaum geändert und ich weiß noch nicht mal, ob noch aktuelle Versionen entwickelt werden. Aber das Tool hat sich bewährt, und bot mir die Möglichkeiten, die ich brauchte.
Unter OS X hatte ich bisher keine gute Software gefunden. Ich gebe zu, ich habe noch nicht wirklich intensiv danach gesucht, aber auf die Schnelle wusste ich heute nicht, was ich verwenden sollte. Bei VersionTracker habe ich mich dann auf die Suche begeben, und bin irgendwann auf SQLEditor gestoßen.
SQLEditor ist eine solide Software. Man kann ähnlich wie im DBDesigner die Datenbank erstellen und Assoziationen modellieren. Anschließend kann man sich daraus SQL-Scripte erzeugen lassen, oder die Daten direkt in einer Datenbank erstellen.
Ersteres hat bei mir mit MySQL nur halb funktioniert. Zwar wurden die Datenbanken korrekt erstellt, bei den Assoziationen hat SQLEditor aber gepatzt. Diese konnten mit dem erstellten SQL-Script und MySQL nicht erzeugt werden. Für meine Zwecke sind die Assoziationen innerhalb von MySQL jedoch nicht notwendig, und ich bin soweit ganz zufrieden.
Das größte Problem ist aber der Preis. SQLEditor soll nach den ersten 30 Tagen $79 kosten. Das ist mir bei weitem zu viel für ein Tool, was ich so selten brauche. Ich werde mich also in einigen Wochen wieder auf die Suche begeben, und schauen, ob ich noch eine andere Alternative finde...
Unter Windows und Linux war die Entscheidung meist relativ einfach. Es gibt viele Programm und die meisten sind ganz brauchbar. Irgendwie bin ich über die Jahre bei DBDesigner hängen geblieben. Die Software hat sich die letzte Zeit kaum geändert und ich weiß noch nicht mal, ob noch aktuelle Versionen entwickelt werden. Aber das Tool hat sich bewährt, und bot mir die Möglichkeiten, die ich brauchte.
Unter OS X hatte ich bisher keine gute Software gefunden. Ich gebe zu, ich habe noch nicht wirklich intensiv danach gesucht, aber auf die Schnelle wusste ich heute nicht, was ich verwenden sollte. Bei VersionTracker habe ich mich dann auf die Suche begeben, und bin irgendwann auf SQLEditor gestoßen.
SQLEditor ist eine solide Software. Man kann ähnlich wie im DBDesigner die Datenbank erstellen und Assoziationen modellieren. Anschließend kann man sich daraus SQL-Scripte erzeugen lassen, oder die Daten direkt in einer Datenbank erstellen.
Ersteres hat bei mir mit MySQL nur halb funktioniert. Zwar wurden die Datenbanken korrekt erstellt, bei den Assoziationen hat SQLEditor aber gepatzt. Diese konnten mit dem erstellten SQL-Script und MySQL nicht erzeugt werden. Für meine Zwecke sind die Assoziationen innerhalb von MySQL jedoch nicht notwendig, und ich bin soweit ganz zufrieden.
Das größte Problem ist aber der Preis. SQLEditor soll nach den ersten 30 Tagen $79 kosten. Das ist mir bei weitem zu viel für ein Tool, was ich so selten brauche. Ich werde mich also in einigen Wochen wieder auf die Suche begeben, und schauen, ob ich noch eine andere Alternative finde...
1000
Sonntag, 9. September 2007
Mit diesem Eintrag hat mein Blog einen weiteren Meilenstein erreicht. Dieses ist der eintausendste Eintrag in meinem Tagebuch! Dreieinhalb Jahre hat es gedauert, um so viele Beiträge zu schreiben! Das ist eine lange Zeit und ich hätte niemals gedacht, dass ich jemals so viel schreiben würde.
Schauen wir mal, was die Zukunft bringt, und wie viel ich noch schreiben werde... So, und jetzt bitte weiter surfen, hier gibt es nichts interessantes zu lesen! Danke!
Schauen wir mal, was die Zukunft bringt, und wie viel ich noch schreiben werde... So, und jetzt bitte weiter surfen, hier gibt es nichts interessantes zu lesen! Danke!
Besucherrekord mit Yourcha
Donnerstag, 6. September 2007
Irgendwie hatte ich am 3. September einen absoluten Besucherrekord! Wie auf der Grafik zu erkennen, hat es 208 Besucher auf diesen bescheidenen Blog verschlagen. Natürlich wollte ich wissen, warum, und nach Analytics zu urteilen, kamen diese fast alle über Google und haben nach Yourcha gesucht! Ich würde mal behaupten, da hat jemand erneut Adressen gemietet und mit Werbe-Postkarten gespamt... Oder ähnliche Marketing-Maßnahmen genutzt... Manch einer lernt es eben nie!Vielleicht kann mir einer der zahlreichen und noch immer anhaltenden Yourcha-Suchenden mal kurz ein Kommentar hinterlassen, wieso er nach Yourcha gesucht hat. Würde mich jedenfalls freuen...
Für alle, die von Google kommen, hier meine gesammelten Yourcha-Artikel in chronologischer Reihenfolge. Ich stehe dabei weiterhin zu dem geschriebenen! Ich halte den Laden noch immer für
Subversion unter OS X
Donnerstag, 6. September 2007
Ich verwende nicht nur im Betrieb, sondern auch privat gerne Subversion. Warum muss ich wohl nicht weiter erläutern - das haben andere schon zur genüge getan.
Nun ist es so, dass unter Mac OS X Subversion nicht als Standard installiert ist und nicht mit den Entwickler-Tools mitgeliefert wird. Es gibt zwar von Apple ein Entwickler Dokument dazu, aber dort wird XCode und Apache verwendet. Nach meiner Meinung ist das ein viel zu großer Aufwand, um einfach nur den SVN-Client zu verwenden. Will man im Netz ein SVN-Repository hosten, kann sich der Aufwand aber lohnen.
An bekannter Stelle gibt es außerdem fertige Binär-Pakete. Ohne diese ausprobiert zu haben, ist die allgemeine Meinung im Netz aber wohl so, dass man die ganz gut nutzen kann. Nur gibt es dort eben nur relativ alte Versionen...
Wie ich also so weiter mit Google unterwegs bin, treffe ich auf die schlichte Seite von Martin Ott. Dort wird unter anderem ein Subversion v1.4.4 Paket angeboten. Das Paket konnte ich auch ohne Probleme runter laden und installieren.
Zum nutzen musste dann noch der Pfad angepasst werden, da das Paket die Programme unter /usr/local/bin/ installiert. Dieses Verzeichnis ist unter OS X normalerweise nicht im Pfad. Ich habe daher als root die Datei /etc/bashrc um folgende zwei Zeilen erweitert:
Nun ist es so, dass unter Mac OS X Subversion nicht als Standard installiert ist und nicht mit den Entwickler-Tools mitgeliefert wird. Es gibt zwar von Apple ein Entwickler Dokument dazu, aber dort wird XCode und Apache verwendet. Nach meiner Meinung ist das ein viel zu großer Aufwand, um einfach nur den SVN-Client zu verwenden. Will man im Netz ein SVN-Repository hosten, kann sich der Aufwand aber lohnen.
An bekannter Stelle gibt es außerdem fertige Binär-Pakete. Ohne diese ausprobiert zu haben, ist die allgemeine Meinung im Netz aber wohl so, dass man die ganz gut nutzen kann. Nur gibt es dort eben nur relativ alte Versionen...
Wie ich also so weiter mit Google unterwegs bin, treffe ich auf die schlichte Seite von Martin Ott. Dort wird unter anderem ein Subversion v1.4.4 Paket angeboten. Das Paket konnte ich auch ohne Probleme runter laden und installieren.
Zum nutzen musste dann noch der Pfad angepasst werden, da das Paket die Programme unter /usr/local/bin/ installiert. Dieses Verzeichnis ist unter OS X normalerweise nicht im Pfad. Ich habe daher als root die Datei /etc/bashrc um folgende zwei Zeilen erweitert:
PATH=$PATH:/usr/local/bin
export PATH
Windows Live ID
Dienstag, 4. September 2007
Wie zum Geier soll man seine Windows Live ID bestätigen, wenn man keine Registrierungs-Mail bekommen hat, und es keine Möglichkeit gibt, diese sich nochmals zuschicken zu lassen?
Ich sag dazu jetzt mal einfach nichts weiter...
Ich sag dazu jetzt mal einfach nichts weiter...
Windows-Zeiten
Donnerstag, 30. August 2007
Tja, die Windows-Zeiten sind bald vorbei. Ich bekomme auf Arbeit demnächst einen iMac... Yes!
Epic5 mit Termcap kompilieren
Dienstag, 28. August 2007
Es gibt immer wieder Dinge, die sind absoluter Schwachsinn - aber man macht sie trotzdem! Aus dieser Episode möchte ich heute mal vorstellen: Wir kompilieren Epic5 mit Termcap. Schwachsinn ist das deswegen, weil so gut wie jedes Linux-System bereits ncurses mit den Entwickler-Quellen installiert hat. Somit ist ein kompilieren normalerweise direkt möglich.
Trotzdem war das ganze ein Versuch wert und ich sage jetzt auch nicht, wie lange ich gebraucht habe, und wie langwierig der Weg zum Ziel war. Wichtig ist im nachhinein ja nur, dass es funktioniert. Also lasst uns beginnen:
Bevor es an das kompieleren geht, muss man sich die benötigten Dateien besorgen. Da wäre als erstes natürlich Epic5. Als nächstes brauchen wir noch Termcap.
Damit hätten wir soweit eigentlich alles, was man braucht. Na ja, fast jedenfalls. Bei mir ließ sich Epic5 so nicht kompilieren. Doch fangen wir am Anfang an. Termcap ließ sich problemlos kompielieren. Wer unter Linux schon mal ein Programm kompiliert hat, wird keine Probleme haben. Da ich das ganze jedoch nicht im System installieren wollte, habe ich einfach alle kompilierten Dateien in das Source-Verzeichnis von Epic5 kopiert. Damit Epic5 diese noch erkennt, muss das passende Makefile um die Dateien ergänzt werden. Interessant ist hier nur die Reihenfolge, da tparam.o vor termcap.o stehen muss.
Nun kommt aber der interessante Teil. Wir kompiliert man Epic5? Ich habe es ganz naiv probiert: Ich habe das Konfig-Script aufgerufen, und die Parameter an meine Bedürfnisse angepasst. Dieses bedeutet, dass ich IPv6 und Ruby Unterstützung gewählt, und Perl abgewählt habe. Damit Epic5 auch noch Termcap nutzt, musste ebenfalls das passende Option gesetzt werden.
Das Kompilieren wurde dann jedoch mit einem Fehler in term.c abgerbochen. Es gäbe wohl conficting types. Dieser Fehler ließ sich zwar relativ einfach beheben, indem in der Datei include/defs.h das Define HAVE_TPARM gesetzt wurde.
Leider brachte das wieder einen neuen Fehler zu Tage. Jetzt meckert er nämlich unter anderem, dass die Funktion tparm nicht existiert. Ich habe eine Ewigkeit gebraucht, um das Problem zu lösen. Ich habe mich dann mit Hilfe von Koders bei icecap bedient. In deren Source gibt es eine tparm.c-Datei. Diese habe ich einfach in das Source-Verzeichnis kopiert und anschließend das Makefile erneut angepasst, um die Datei tparm.o vor tparam.o zu linken. Und schon lief das kompilieren durch!
Das letzte Problem war nun, dass Termcap mein Terminal xterm nicht erkannt hat. Ich habe mich dann schnell in einer Screen-Session versteckt, und endlich funktionierte Epic5.
Trotzdem war das ganze ein Versuch wert und ich sage jetzt auch nicht, wie lange ich gebraucht habe, und wie langwierig der Weg zum Ziel war. Wichtig ist im nachhinein ja nur, dass es funktioniert. Also lasst uns beginnen:
Bevor es an das kompieleren geht, muss man sich die benötigten Dateien besorgen. Da wäre als erstes natürlich Epic5. Als nächstes brauchen wir noch Termcap.
Damit hätten wir soweit eigentlich alles, was man braucht. Na ja, fast jedenfalls. Bei mir ließ sich Epic5 so nicht kompilieren. Doch fangen wir am Anfang an. Termcap ließ sich problemlos kompielieren. Wer unter Linux schon mal ein Programm kompiliert hat, wird keine Probleme haben. Da ich das ganze jedoch nicht im System installieren wollte, habe ich einfach alle kompilierten Dateien in das Source-Verzeichnis von Epic5 kopiert. Damit Epic5 diese noch erkennt, muss das passende Makefile um die Dateien ergänzt werden. Interessant ist hier nur die Reihenfolge, da tparam.o vor termcap.o stehen muss.
Nun kommt aber der interessante Teil. Wir kompiliert man Epic5? Ich habe es ganz naiv probiert: Ich habe das Konfig-Script aufgerufen, und die Parameter an meine Bedürfnisse angepasst. Dieses bedeutet, dass ich IPv6 und Ruby Unterstützung gewählt, und Perl abgewählt habe. Damit Epic5 auch noch Termcap nutzt, musste ebenfalls das passende Option gesetzt werden.
Das Kompilieren wurde dann jedoch mit einem Fehler in term.c abgerbochen. Es gäbe wohl conficting types. Dieser Fehler ließ sich zwar relativ einfach beheben, indem in der Datei include/defs.h das Define HAVE_TPARM gesetzt wurde.
Leider brachte das wieder einen neuen Fehler zu Tage. Jetzt meckert er nämlich unter anderem, dass die Funktion tparm nicht existiert. Ich habe eine Ewigkeit gebraucht, um das Problem zu lösen. Ich habe mich dann mit Hilfe von Koders bei icecap bedient. In deren Source gibt es eine tparm.c-Datei. Diese habe ich einfach in das Source-Verzeichnis kopiert und anschließend das Makefile erneut angepasst, um die Datei tparm.o vor tparam.o zu linken. Und schon lief das kompilieren durch!
Das letzte Problem war nun, dass Termcap mein Terminal xterm nicht erkannt hat. Ich habe mich dann schnell in einer Screen-Session versteckt, und endlich funktionierte Epic5.
Serendipity 1.2
Montag, 27. August 2007
Wir haben gerade das Serendipity auf Version 1.2 aktualisiert. Auch mit der Shared installation war das Update ziemlich problemlos. Lediglich unsere lokalen Anpassungen mussten erneut eingefügt werden. Alles andere lief ohne Probleme. Jetzt die nächsten Tage mal ein bisschen mit den neuen Möglichkeiten von Serendipity 1.2 spielen...
Hallo, ich bin Sebastian!
