Ich muss mal wieder auf MeinProf verlinken. Diesmal aber nicht, weil Spiegel-Online die Seite ans Pageview-Limit treibt und zum Glück auch nicht aufgrund weiterer Hochschulzicken.
Der Grund ist technischer und hat mit Ruby On Rails zu tun: MeinProf.de ist in den letzten Tagen auf technisch neue Beine gestellt worden und Jonathan Weiß hat einen Artikel darüber geschrieben: „Scaling Rails with Apache 2.2, mod_proxy_balancer and Mongrel„
Ich verstehe zwar nicht wirklich, was dort geschrieben steht aber ich weiß, dass zumindest unser lieber Hoster noch nach einer besseren Lösung für unsere Railsinstallation sucht. Bisher war unsere Suche nach guten Artikeln hierzu nicht erfolgreich — vielleicht ist dieser Ansatz besser?
Problemstellung: Ich möchte die Logfiles (m)eines Hosters auswerten, da mir seine Anzeige visuell nicht genügt.
1. Frage: Welche Software nehmen?
- Analog und Webalizer sind OpenSource, die Auswertung reicht mir aber nicht aus.
- WebStat ist zwar Freeware und erhält schnell ein Ergebnis aber auch hier ist die Auswertung mäßig.
- Wusage (25 $) scheint recht neu, leider keine Trial. Auch wenn das Demovideo gut aussieht, es gibt OpenSource-Alternativen…
- Mescalero wäre optimal: Man bekommt die Daten schnell rein und hat viele Ausgabemöglichkeiten. Leider mit 99 € zu teuer…
- Bleibt AWStats, das wie die beiden ersten ein Server-Script ist. Es hat eine gute Auswertung und wird häufig empfohlen/verwendet…
2. Frage: Wie AWStats 6.5 installieren?
Wer sich — wie ich — selten mit der Installation solch servernaher Software befasst, mag seine Probleme haben.
Wer lange genug sucht, findet aber zum Glück auch ein passendes Tutorial. Folgendes habe ich gemacht:
- Mein altes Xampp deinstalliert, das neue Xampp Basis / Win in der Version 1.5.1 installiert. (Über-Installation hat nicht geklappt/ausgereicht)
- Das Perl-Add-On für Xampp installiert, denn das Standard-Perl ist nur eine Lite-Version (Quelle)…
- Aus diesem sehr guten Tutorial die Schritte ab „AWStats Installation" durchgeführt. Wobei ich:
1) die Ordner classes, css, icon und js
in einen gemeinsamen Ordner „/htdocs/awstats" kopiert habe (in der AWStats-Config muss man entsprechend die Pfade anpassen
2) einen gesonderten Ordner „/xampp/logs/MYSITE/" für meine *.log-Dateien angelegt habe (auch hier Config nachziehen) und
3) meine Config-Datei im Format awstats.MYSITE.conf gehalten habe. Das hat den Vorteil, dass ihr mehrere configs anlegen könnt…
- Nach dem Tutorial noch wie im Comment unter 2.) beschrieben den Pfad in
awstats.pl korrigiert.
- Per Dos-Commendline getestet, ob alles stimmt:
C:\>C:\xampp\xampp\perl\bin\perl.exe C:\xampp\xampp\cgi-bin\awstats\awstats.pl -
config=MYSITE -update
Hier gebt ihr jetzt die verschiedenen Config-Umgebungen von oben an.
- Zum Schluss kann man über http://YOURSERVER/cgi-bin/awstats/awstats.pl?config=MYSITE (siehe auch) die Statistik sehen.
/Ende
Jetzt wünschte ich nur noch, AWstats könnte automatisch alle Files aus einem Ordner zur Statistik hinzufügen…
Dieses Wochenende fand das Ehemaligentreffen unseres Pfadfinderstammes statt.
Das allein ist noch nicht wert, das Andreas und ich in unseren Blogs dar�ber berichten.
Was es zu etwas besonderem macht, war der Inhalt:
Wir hatten 6.000 Dias digitalisiert und dann unsere Ehemaligen eingeladen, sie zu beschriften. Speziel daf�r hat Hyunmo Kang von der Universit�t Maryland uns eine neue Version von PhotoMesa programmiert, die — �hnlich wie damals PhotoFinder Kiosk — im Client-Server-Betrieb arbeitet.
Andreas hat schon geschrieben, dass wir f�r die Fertigstellung in der Nacht zuvor per Remote-Control eine Testumgebung f�r Hyunmo in unserem Heimnetzwerk eingerichtet haben. — Ein wirklich interessantes Unterfangen.
Mehr �ber das Projekt an sich, gibt es demn�chst in unserer Dokumentation zu lesen…
Interessant zu lesen ist der Artikel bei softwareCEO.com über McAffe's neue Softwareentwicklung.
Clean, cutting-edge UI design cuts McAfee's support calls by 90%
[via KISD-Mailingliste]
Viele der dort beschriebenen Methoden finde ich auch in Texten von 37signals wieder. Hierzu hatte ich bereits ein paar gute Links gesammelt.
Sehr zu empfehlen ist auch der Podcast mit Jason Fried (MP3), einem 37signals-Gründer.
Derek Sivers stellt in Frage, was sich bei vielen Bestellformularen als (schlechter) Quasistandard etabliert hat: Questioning what's REALLY needed in a system
Er sagt:
- Die Rechnungsadresse ist nur nötig, wenn man mit Kreditkarte bezahlt. Nicht aber beispielsweise bei einem Geschenkgutschein o.ä. Folglich erst die Zahlungsart abfragen.
- Postleitzahlen, Bundesstaaten u.ä. gibt es nicht in jedem Land. Folglich erst das Land abfragen und entsprechend darauf reagieren.
- Registrierung (Passwortabfrage) ist nur dann interessant, wenn Kunden mehrmals in einem Shop einkaufen gehen. Statistisch sind aber nur 15% der Käufer „Wiederholungstäter". Und ich behaupte, dass und diesen noch einige sind, die sich anschl. nicht mehr an ihr Passwort erinnern können. Folglich erst einmal das Produkt verschicken und im letzten Schritt erst fragen, ob man einen Account anlegen möchte.
- Die erste Zahl einer Kreditkartennummer verrät, welchem Anbieter sie gehört. Das wusste ich auch noch nicht. Folglich ist es klar, dass man sie die gesonderte Eingabe des Anbieters überspringen kann.
- Und aus den Kommentaren:
Geheimfragen wie der Geburtsname der Mutter sind quatsch. Passwörter sollten einfach auf Anfrage per eMail verschickt werden.
Heute habe ich wieder einen ganzen Tag damit verbracht in meiner Ruby On Rails-Demoapplication ähnliche Dinge abzufangen — es geht ohne Probleme. Ich frage mich, warum so viele Unternehmen einer so zentralen Sache wie dem Bestellvorgang so wenig Beachtung schenken.
Der Ansatz nach der Grundkonzeption einer Webanwendung sehr bald mit dem Interface zu beginnen, ist für Grafiker wahrscheinlich nicht so fremd. In den einigen Entwicklerkreisen wird er als sehr modern, gewagt und zukunftsweisend gesehen. Die chicagoer Agentur 37signal nennt das „getting reals" und schreibt schon eine ganze Weile darüber (siehe Wrinting-Spalte rechts). Schlagworte (PDF) wurden mal für eine Präsentation zusammengefasst.
Heute lese ich bei „Uncommon Sense (for Software)" einen sehr ähnlichen interessanten Artikel Building it Front-to-Back.
Seine Arbeitsbeschreibung
1. Excel für erste Daten
2. Photoshop
3. Feedback (erste Optik)
4. HTML, CSS + insb. JavaScript-Spielereien
5. Feedback (erste Interaktivität)
6. PowerPoint für genaues Seiten"design"
7. Feedback (Gesamtstruktur, Features)
8. Statische, klickbare HTML-Umsetzung
9. Feedback auf Basis dieser für den Endbenutzer fertigen Anwendung
10. Code-Umsetzung in den gewohnten Schritten
[via jadedpixel]
Das beste an WordPress ist im Grunde die hevorrangende Dokumentation. Zentrales Thema dieser Woche: Die Backup-Week.
Do It.
