Archiv ‘Web’

Sonntag, 15. April 2012

Instagram und der lächerlich-gefährliche JOBS Act

Mark Zuckerberg und seine mit Milliarden um sich werfenden VC-Fritzen im Silicon Valley täten gut daran, sich Betriebswirtschaftsweisheiten ihrer Vorfahren zu Gemüte zu führen:

In the old days, in the fifties and sixties for instance, you would never take a company public that wasn’t profitable at the time of the IPO, or didn’t have a multi-year track record of solid revenues.

Quelle: Why Obama’s JOBS Act Couldn’t Suck Worse

Aber jetzt kommt noch unser Obama und will mit dem JOBS Act ein Gesetz in Kraft setzen, welches Internet Startups aus der Pflicht für sauberes Buchhalten enthebt:

We needed Barack Obama and the congress to compromise the entire U.S. stock market because it’s too expensive for a publicly-listed company with billion-dollar ambitions to hire an accountant?

Tags: , , , , ,
Labels: USA, Web

Keine Kommentare | neuen Kommentar verfassen

Mittwoch, 11. April 2012

XING-Bilder grösser machen

Da ich keinen Sinn darin sehe, für eine XING Premium-Mitgliedschaft Geld auszugeben, habe ich ab und zu das Problem, dass ich erraten muss, wer mein Profil so alles besucht hat.

XING zeigt mir dabei die Besucher mit einem klitzekleinen Bildchen an, worauf ich die Person partout nicht erkennen kann. Wenn ich meine Neugier befriedigen möchte, muss ich eine XING-Mitgliedschaft kaufen.

Doch zumindest etwas Licht ins Dunkel lässt sich bringen, indem man etwas mit der Bild-URL spielt. Hier ein Beispiel:


https://www.xing.com/pubimg/users/1/6/c/2450328df.16473797,2.30x40.jpg

Hmmm! Löschen wir doch mal die Pixeldimensionen nach dem Komma. Oh:


https://www.xing.com/pubimg/users/1/6/c/2450328df.16473797,2.jpg

So sieht der Mitmensch also aus, der mein Profil besucht hat …

Mein Tipp an XING: Die verschiedenen Grössen der Bilder sollten einen variablen Bestandteil haben, der von aussenstehenden weder erraten noch hergeleitet werden kann. Beispielsweise mittels md5($imageSize . $internalUserId).

Tags: , , , , , ,
Labels: Web

Keine Kommentare | neuen Kommentar verfassen

Dienstag, 27. März 2012

E-Mail-Adressenformat von Firmen herausfinden

Gelegentlich stehe ich vor der Aufgabe, ein Mitarbeiter unter seiner E-Mail-Adresse auf der Arbeit zu kontaktieren, dessen E-Mail-Adresse ich nicht kenne.

Damit ich das Format der E-Mail-Adressen der jeweiligen Firma herausfinden kann, besuche ich dann jeweils die Web-Site. Manchmal werden die E-Mail-Adressen von leitenden Personen auf der Web-Site angegeben, anhand derer man anschliessend die Adresse der gesuchten Person herleiten kann. Ist dies nicht der Fall, gibt es aus Erfahrung noch ein anderer Ort auf der Web-Site, wo man heute garantiert eine E-Mail-Adresse findet: Bei den Stellenangeboten. Normalerweise ist bei einem Stelleninserat die E-Mail-Adresse der verantwortlichen HR-Mitarbeiterin angegeben.

PS: Leider verhindert Google meines Wissens die Suche nach E-Mail-Adressen auf einer bestimmten Web-Site, um es Spammern nicht zu einfach zu machen, an neues Adress-Material zu gelangen.

Tags: ,
Labels: Web

1 Kommentar | neuen Kommentar verfassen

Montag, 12. März 2012

Coop und MIGROS sind noch nicht bei Web 2.0 angekommen

Was fällt dem geneigten Web-Entwickler an nachfolgenden URLs auf, die auf Produkte in Web-Shops von Coop (Coop@home) respektive MIGROS (LeShop) verweisen?

Mein Deutschlehrer aus dem Gymnasium würde sowohl die Detailhändler als auch die Entwickler deren Web-Shops fragen: „Sind Sie eigentlich bescheuert?!“ Es scheint, als wären die technische Entwicklung der letzten 10 Jahre spurlos an diesen beiden Buden vorbeigegangen.

Zum einen wäre der Nutzen kurzer, einfacher deklarativer URLs für die Endkunden deutlich komfortabler – und würde wohl auch sozusagen kostenlos SEO mit sich bringen. Wie wäre es bspw. mit:

  • http://www.coopathome.ch/product/coop-mango-lassi-2.5dl/1234567890
  • http://www.leshop.ch/product/selection-lassi-mango/1234567890

Zum andere Frage ich mich über die Überlegungen der Web-Entwickler hinter den beiden Web-Shops, insbesondere desjenigen von coop@home: Was zum Teufel sollen all diese Variablen, die per GET übergeben werden?

  • xcm=coop_dev
  • cpgsize=24
  • layout=7.0-1_0_3_7_8_9_10_11_14_13_51_18_15_21_46_47_52_6_26
  • uiarea=16
  • cpgnum=1

Und was sagt mir diese ellenlange URL b2c_coop/catalog/updateItems/ eigentlich aus?

Wir sehen, es bleibt bei Coop & Co. noch viel zu tun.

Tags: , , , , ,
Labels: Web

1 Kommentar | neuen Kommentar verfassen

Samstag, 11. Februar 2012

Vom Nutzen einer PHP Debug-Klasse

Seit mehreren Jahren verwende ich eine Sammlung von selber entwickelten emeidi*-PHP-Klassen, um Web-Sites und -Applikationen zu entwickeln. Leider hege ich immer noch grosse Skrupel, diese Klassen via Github als Open Source Software freizugeben — einerseits weil sich im Quellcode doch der eine oder andere unschöne Bock findet, andererseits, weil die Klassen Sicherheitslücken enthalten könnten, die bei produktiven Web-Sites ausgenützt werden könnten. Hinzu kommt mein Amazon-API-Key, den ich kurzerhand in die emeidiAmazon-Klasse festkodiert habe …

Unverzichtbares Kernstück ist dabei meine emeidiDebug-Klasse, welche für die professionelle, effiziente Web-Entwicklung unabdingbar ist. Jede andere meiner Klasse instanziert beim Laden die emeidiDebug-Klasse, mit welcher ich im ganzen Programmcode nützliche Fehlermeldungen und/oder Informationen zum Programmablauf festhalte.

Auf produktiven Web-Sites gebe ich den Inhalt des Debug-Objektes natürlich nicht aus, aber auf dem Entwicklungsserver ist es eine grosse Unterstützung, wenn ich am Ende der ausgegebenen Web-Seite noch folgenden Code hinpflanze:

...
<?php print $klasse->debug->getHtml(); ?>
</body>
</html>

Im ganzen PHP-Code finden sich zur Befüllung dieses Objekts Konstrukte wie

$this->debug->add('Not dumping descriptions because length new ' . $lenNew . ' is smaller than lenght old ' . $lenOld,'error');

Teilweise gebe ich auf produktiven Web-Sites wichtige Warnmeldungen auch in das PHP Error-Log aus. Während ich das früher direkt mit error_log(); gemacht habe, benutze ich heute ebenfalls meine Debug-Klasse dafür.

Der Grund dafür ist simpel: Nicht nur möchte ich das gesamte Debugging über meine Debug-Klasse laufen lassen, nein, meine Debug-Klasse ist auch geschwätziger und hilft mir im Falle meines Testservers, das fehlerhafte Script zu lokalisieren.

Vor einigen Tagen fand ich auf meinem Testserver folgende Einträge in der php.err-Datei:

[06-Feb-2012 00:07:43 UTC] Not dumping descriptions because length new 1778 is smaller than lenght old 1780

Mittlerweile habe ich das ausgebende Script (es wird täglich per Cron-Job aufgerufen) lokalisiert und die Programmierung angepasst. Alt hiess es:

error_log('Not dumping descriptions because length new ' . $lenNew . ' is smaller than lenght old ' . $lenOld);

Neu heisst es:

$this->debug->add('Not dumping descriptions because length new ' . $lenNew . ' is smaller than lenght old ' . $lenOld,'error',true);

Der letzte der Funktion übergebene Parameter true weist meine Debug-Klasse an, einen Eintrag in die php.err-Datei zu machen. Dieser schaut folgendermassen aus:

[11-Feb-2012 16:57:16 UTC] Not dumping descriptions because length new 1778 is smaller than lenght old 1780 in /var/www/apps/weather2ics/weather2ics.class.php on line 95 for URI </bern>

Anhand dieser Informationen kann ich nicht nur die Datei und die verantwortliche Zeile auf einen Blick lokalisieren, welche den Fehler ausgibt, sondern sehe auch noch gerade die URI, mit welcher die Web-App aufgerufen wurde.

Tags: , ,
Labels: Web

1 Kommentar | neuen Kommentar verfassen

Mittwoch, 31. August 2011

Word HTML-Säuberer wordoff.py lokal ausführbar machen

Kürzlich stand ich auf der Arbeit vor der schmerzlichen Vorgabe, ein dutzendes Seiten umfassendes Word-Dokumenten nach Excel zu kopieren (das Dokument enthielt unzählige Tabellen im immer gleichen Aufbau). Anstelle jede Zelle mühsam einzeln nach Excel zu kopieren – was meine gesamte bisherige Ausbildung in Frage gestellt hätte – entschied ich mich dafür, das Word-Dokument als HTML abzuspeichern, den HTML-Code anzupassen und danach in Word zu importieren.

Bekanntermassen ist der von Word produzierte HTML-Code ungefähr so das schrecklichste, was ein Web-Entwickler jemals zu Gesicht bekommen wird. Zum Glück gibt es Web-Dienste wie WordOff, welche über ein Web-Form Word-HTML entgegennehmen, säubern und zum Download anbieten.

Da das Word-Dokument in meinem Falle aber die Bemerkung „Strictly Confidential“ enthielt, empfand ich dies dann doch eher als gewagter Stunt, der mir im schlimmsten Falle den Job hätte kosten können.

Ich entschied mich deshalb, den Python-Code für das Projekt von git herunterzuladen, anzupassen und danach lokal über das HTML-File laufen zu lassen.

Folgende Anpassung war in wordoff.py nötig:

...
def superClean(str):
    clean = stripAttributes(str)
    cleaner = stripSpans(clean)
    cleaner = stripDivs(cleaner)
    #cleaner = xenophobia(cleaner)
    cleaner = stripEmptyElements(cleaner)
    cleaner = stripEmptyElements(cleaner)
    cleaner = stripEmptyElements(cleaner)
    cleaner = reduceLineBreaks(cleaner)
    return cleaner

# Changes added by Mario Aeby, eMeidi.com
# Allows to execute the script locally on a command line
def main():
	file = open("word-to-excel.htm");
	str = file.read()
	
	print superClean(str)
	
if __name__ == "__main__":
    main()

Dies erlaubt, das Script folgendermassen auf der Kommandozeile aufzurufen (die Quelldatei muss derzeit leider in den Sourceode hardkodiert werden):

$ ./wordoff.py > word-to-excel-clean.html

Nicht schlecht. Wer weiss, vielleicht lässt der Entwickler diese Anpassung ja auch ins Projekt einfliessen, damit man es künftig sowohl unter dem Django-Framework als auch lokal in einer Shell ausführen kann.

Tags: , , , ,
Labels: IT, Web

1 Kommentar | neuen Kommentar verfassen

Samstag, 27. August 2011

Kurzanleitung git

Vor einigen Wochen habe ich einen Account auf Github eröffnet und teile dort nützliche und weniger nützliche Programmierwürfe aus meiner Hand.

Da ich meine PHP-Entwicklungen mit Subversion verwalte und Git deshalb äusserst selten verwende, habe ich mir folgende Kurzanleitung von der Web-Site kopiert, damit ich ein Projekt im Nu eingecheckt habe.

Zuerst erstellt man sich unter Create a New Repository ein neues Repository. Anschliessend führt man lokal folgende Befehle aus:

mkdir arbeitsjournal
cd arbeitsjournal
git init
git remote add origin git@github.com:emeidi/arbeitsjournal.git
git pull
touch arbeitsjournal.py
git add arbeitsjournal.py
git commit -m 'first commit'
git push -u origin master

Für alles weiterführende sei beispielsweise auf eines der vielen Git-Cheatsheets verwiesen.

Tags: ,
Labels: Web

Keine Kommentare | neuen Kommentar verfassen

Dienstag, 31. Mai 2011

Wieso man E-Mail-Adressen im Web nicht verschleiern sollte

Alle Jahre wieder erhalte ich Anfragen von besorgten Internet-Nutzern, wieso deren E-Mail-Adresse im Klartext auf Web-Sites erscheint. So könne sie doch problemlos von Spammern entwendet werden, worauf die Mailbox mit unerwünschten Mails überquillt.

Doch:

Spam is a problem for you–obfuscation makes it a problem for your users.

Quelle: Obfuscate no more: why your email address should go au naturale – Jason Priem

Schöner kann man es nicht ausdrücken: Indem ich Mail-Adressen verschlüssle (beispielsweise in der Form spam at emeidi dot com), schütze ich mich vielleicht vor Spam (dabei weiss jeder anständige Web-Entwickler, wie rasch man einen Spider entwickelt hat, der in HTML-Dumps nach „at“ und „dot“ Ausschau hält), aber garantiert auch davor, dass Personen auf gewohnte Weise mit mir Kontakt aufnehmen können — nämlich mit Klick auf meine verlinkte E-Mail-Adresse.

Stattdessen sollten wir unsere Mail-Accounts lieber auf Servern hosten, die gut funktionierende Spam-Filter im Einsatz haben.

Notabene: Natürlich gibt es andere, offenbar sehr gut funktionierende Methoden, die besser wirken — doch unter uns: Soll ich als Web-Entwickler wirklich mühsam Zeit aufwenden, um E-Mail-Adressen über meine ganze Web-Site zu verschlüsseln? Dadurch erhöhen sich höchstens der Wartungsaufwand und die Fehlerquellen.

Tags: , , , , , ,
Labels: Web

Keine Kommentare | neuen Kommentar verfassen

Samstag, 21. Mai 2011

Die Banker wirtschaften sich auch 2011 weiterhin selber in die Tasche

The fact that the stock more than doubled on its first day of trading — something the investment bankers, with their fingers on the pulse of the market, absolutely must have known would happen — means that hundreds of millions of additional dollars that should have gone to LinkedIn wound up in the hands of investors that Morgan Stanley and Merrill Lynch wanted to do favors for. Most of those investors, I guarantee, sold the stock during the morning run-up. It’s the easiest money you can make on Wall Street.

Quelle: Was LinkedIn Scammed? – NYTimes.com

Tags: , , , , ,
Labels: USA, Web

Keine Kommentare | neuen Kommentar verfassen

Dienstag, 8. März 2011

Wie man Login-Formulare lieber nicht gestaltet

Heute begegnete ich auf der Arbeit einem Support-Fall, dessen Erkenntnisse sich alle Web-Entwickler da draussen zu Herzen nehmen sollten: Eine Mitarbeiter konnte sich nicht mehr in eine intern programmierte Web-Applikation einloggen.

Jedesmal, wenn sie ihre Zugangsdaten in das Login-Formular eingegeben hatte und den „Login“-Knopf drückte, kehrte sie umgehend auf dieselbe Seite zurück, das Formular war aber wieder leer.

Als ich beigezogen wurde, entdeckte ich zwei vom Entwickler verschuldete Probleme:

  • Benutzernamen mit Gross-/Kleinschreibung. Offenbar ist die Authentifizierungsroutine der Applikation so programmiert, dass nicht nur das Passwort case-sensitive geprüft wird (sehr gut, macht Brute-Force-Attacken komplizierter), sondern auch der Benutzername (schlecht). Somit war „benutzer“ nicht identisch mit „Benutzer“ oder „BeNuTzEr“. Dabei sollte man den Endbenutzern erlauben, irgendwelche Schreibweisen des Benutzernamens zu verwenden.
  • Keine Fehlermeldung. Dem Benutzer wurde nach der Rückkehr zum Login-Formular nicht mitgeteilt, weshalb der Zugang zum geschützten Bereich verweigert wurde. Es ist für den Benutzer (wie auch für den IT-Supporter) sehr hilfreich, wenn die Web-Applikation möglichst genau sagt, wo das Problem liegt — und am besten die Fehlermeldung klar vom restlichen Seiteninhalt abhebt (bspw. mit einem roten Rahmen und einem hellroten Hintergrund). So könnte man ausgeben „Benutzer nicht gefunden“ oder „Passwort falsch“, was helfen würde, die Fehlerursache rasch und effizient einzuschränken. Selbstverständlich kann man argumentieren, dass die Applikation nur auf ein nicht näher spezifiziertes Login-Problem hinweisen sollte, um potentiellen Hackern nicht zu viele Informationen preiszugeben. Ich bin aber der Meinung, dass die Benutzbarkeit der Applikation höher gewichtet werden sollte als potentielle Angriffsvektoren. Gowalla ist ein gutes Beispiel dafür: Bei Login-Problemen erfährt der Anwender, ob der Benutzername überhaupt existiert oder ob das Passwort falsch angegeben wurde.

Wer diese zwei Ratschläge befolgt, wird seinen Kunden eine Menge schlaflose Nächte ersparen.

Tags: ,
Labels: Web

Keine Kommentare | neuen Kommentar verfassen