Posts tagged IT
I wrote a small Lisp application and a JavaScript client gets some data from that application. All time stamps are returned as “Lisp” time stamps, i.e. an integer with seconds where zero equals Jan 01 1900.
In the JS client the time stamp is then converted to JS time stamps, i.e. millisconds where zero equals Jan 01 1970.
When testing the application I noticed that sometimes the displayed date is one day behind. For example in the data base I have Jan 05 1980 but in JavaScript I get a Jan 04 1980. But some other dates worked: A time stamp Jan 05 1970 was correctly converted to Jan 05 1970.
I had a look into the JavaScript code and found:
convA = function(ts) {
tmp = new Date(ts*1000);
tmp.setFullYear(tmp.getFullYear() - 70);
return tmp.getTime();
}
It’s likely the developer thought: “Well, it’s millisecond instead of second. Therefore I multiply by 1,000. But then I am 70 years in the future and I have to substract 70 years and everything will be ok.”
After thinking a while I came to the conclusion: Of course not!
The developer made the assumption that there are as many leap years between 1900 and 1970 as between ts and ts+70. Obviously that assumption does not hold for all time stamps. And therefore sometimes the resulting JavaScript date is one day behind.
So a better solution would be to substract all seconds between 1900 and 1970 from ts, multiply by 1,000 and treat this as a JavaScript time stamp. Perhaps best would be to do the conversion in the Lisp process and only deliver a JavaScript-like time stamp.
I am using Common Lisp for developing a web application. Several days ago a new part of this application didn’t worked as supposed and I spent a considerable large amount of time in finding the bug. It was a very simple problem with symbols where I mixed something up.
In the application the web server somewhen gets some JSON data from the browser. It is then converted to Lisp object using the CL-JSON package. This package converts JSON objects to a-lists and converts the member keys to symbols (see CL-JSON’s documentation. I then wanted to look something up in that a-list and failed.
I wrote a small test case to show the effect and explain what went wrong.
(ql:quickload '("hunchentoot" "cl-who"))
;; direct loading via ql only for demonstration purposes, normally I
;; would use a asdf:defsystem for that.
(in-package :cl-user)
(defpackage :my-app (:use :cl))
(in-package :my-app)
(defparameter *my-a-list*
'((foo . 100)
(bar . 200))) ;; in the real application this a-list is
;; generated by a JSON-to-lisp conversion by
;; CL-JSON; in CL-JSON the object member keys are
;; converted to symbols.
(defun get-value (key)
"Returns the value with KEY from *MY-A-LIST*."
(cdr (assoc (intern (string-upcase key)) *my-a-list*)))
(hunchentoot:define-easy-handler (web-get-value :uri "/get-value") (id)
(cl-who:with-html-output-to-string (*standard-output* nil :prologue t)
(:p (cl-who:fmt "Value of ~a is: ~a" id (get-value id)))))
(defun start ()
(hunchentoot:start (make-instance 'hunchentoot:easy-acceptor :port 4242)))
So on the REPL everything looks fine: MY-APP> (get-value "foo")
100
MY-APP> (get-value "bar")
200
MY-APP>
But when I used my web browser to give me these results as well I got something strange. For example here are some results when using curl: ~> curl http://localhost:4242/get-value?id=foo
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<p>Value of foo is: NIL</p>
I was puzzled: The value is NIL?
After some debugging I found out that the easy handler from Hunchentoot runs with *package* set to COMMON-LISP-USER (and not to MY-APP as I implicitly assumed). That means that assoc looked up COMMON-LISP-USER::FOO in the a-list where the keys are MY-APP::FOO and MY-APP::BAR. And this test fails. Therefore NIL is returned which is correct.
So I rewrote the get-value function to: (defun get-value (key)
"Returns the value with KEY from *MY-A-LIST*."
(cdr (assoc (intern (string-upcase key)
(find-package :my-app)) *my-a-list*))) Now the symbols are interned in the same package and everything went well: ~> curl http://localhost:4242/get-value?id=foo
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<p>Value of foo ist: 100</p>
~> curl http://localhost:4242/get-value?id=bar
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<p>Value of bar ist: 200</p>
Therefore I was reminded to think about packages when interning symbols. A good guide to symbols and packages could be found in this document: The Complete Idiot’s Guide to Common Lisp Packages.
Well, it seems Octopress/Jekyll would like to have a locale set for UTF–8 support. I followed this (text in German) hint and now my Dockerfile looks like this:
# dockerfile for octopress
FROM ubuntu:14.04
MAINTAINER krrrcks <krrrcks@krrrcks.net>
ENV DEBIAN_FRONTEND noninteractive
RUN apt-get update; \
apt-get -q -y upgrade
RUN /usr/sbin/locale-gen en_US.UTF-8; \
update-locale LANG=en_US.UTF-8
RUN apt-get -q -y install git curl; \
apt-get clean
RUN git clone git://github.com/imathis/octopress.git /opt/octopress
RUN curl -L https://get.rvm.io | bash -s stable --ruby
ENV HOME /root
RUN echo "export LC_ALL=en_US.UTF-8" >> /root/.bashrc
RUN echo "export LANG=en_US.UTF-8" >> /root/.bashrc
RUN echo "source /usr/local/rvm/scripts/rvm" >> /root/.bashrc;
RUN /bin/bash -l -c "source /usr/local/rvm/scripts/rvm; \
rvm install 1.9.3; \
rvm use 1.9.3; \
rvm rubygems latest; \
cd /opt/octopress; \
gem install bundler; \
bundle install; \
rake install"
RUN echo "rvm use 1.9.3" >> /root/.bashrc
WORKDIR /opt/octopress
EXPOSE 4000
CMD ["/bin/bash"]
After playing around with Docker and Octopress I put the whole /opt/octopress folder on my host machine and then restarted the image with the -v flag. Therefore I can edit the files on my host machine with my favorite editor and use the container only for producing the HTML files, for preview and for publishing.
The rake preview is a neat feature because the server always looks for changed files and produces the HTML files on the fly. That means I can edit the files in my editor and could see the resulting pages in a browser nearly the same time.
After my trouble with installing all the dependencies for Octopress I came up with the following Dockerfile for Docker. This follows the instructions from the Octopress homepage and uses RVM for managing the ruby dependencies.
# dockerfile for octopress
FROM ubuntu:14.04
MAINTAINER krrrcks <krrrcks@krrrcks.net>
ENV DEBIAN_FRONTEND noninteractive
RUN apt-get update; \
apt-get -q -y upgrade
RUN apt-get -q -y install git curl; \
apt-get clean
RUN git clone git://github.com/imathis/octopress.git /opt/octopress
RUN curl -L https://get.rvm.io | bash -s stable --ruby
ENV HOME /root
RUN echo "source /usr/local/rvm/scripts/rvm" >> /root/.bashrc;
RUN /bin/bash -l -c "source /usr/local/rvm/scripts/rvm; \
rvm install 1.9.3; \
rvm use 1.9.3; \
rvm rubygems latest; \
cd /opt/octopress; \
gem install bundler; \
bundle install; \
rake install"
RUN echo "rvm use 1.9.3" >> /root/.bashrc
WORKDIR /opt/octopress
EXPOSE 4000
CMD ["/bin/bash"]
Ich bin ein sehr intensiver Nutzer von Org-Mode, einem speziellen Modul/Modus für den Emacs-Editor (ich habe hier auf meiner Homepage auch einmal mit einer kleinen Seite dazu begonnen). Nun ja, was soll man sagen: Bei Emacs wird eine recht alte Version mitgeliefert. Ich wollte dann mal auch wegen einiger Funktionen die neueste nutzen. Also via git heruntergeladen und eingebunden und Peng, irgendwas funktioniert natürlich nicht mehr: Ich benötige pratisch täglich den Export von Org-Mode-Dateien nach LaTeX, der wollte aber nicht mehr. Nun kann ich zwar Lisp, aber das Emacs Lisp ist doch etwas speziell und die Debug-Möglichkeiten sind etwas … nun ja, altbacken. Kurzum: Das macht überhaupt keinen Spaß. Im Endeffekt habe ich dann herausgefunden, dass unter bestimmten Umständen Teile des alten, bei Emacs mitgelieferten Codes nachgeladen wird anstelle der neuen Distribution. Diese bescheidene Art von Emacs mit Modulen und Paketen umzugehen ist wirklich erschreckend. Was dafür wiederum total toll war: In der von mir verwendeten Org-Mode-Version war wohl ein Fehler, das ganze Ding über die Mailingliste geschickt und innert einem halben Tag war der Fehler von anderen Nutzern und von Carsten Dominik auch gleich gefixt. Grandiose Antwortzeit!
Nun, ich habe das Buch von Constanze Kurz und Frank Rieger, Die Datenfresser, gelesen. Hier eine sehr kurze Besprechung:
Die beiden Autoren wollen erklären, “wie Internetfirmen und Staat sich unsere persönlichen Daten einverbleiben und wie wir die Kontrolle darüber zurückerlangen.” Thematisch werden automatisierte Datenanalysen, der Wert der Nutzerdaten, die ökonomischen Mechanismen hinter sozialen Netzwerken und den Daten der Nutzer und einige Aspekte des staatlichen Einsatzes zur Datenanalyse vorgestellt und diskutiert.
Als wichtige Botschaft wird dem Leser mitgegeben, dass seine Daten für Unternehmen einen Wert darstellen und dass Angebote im Netz dazu dienen, diese Daten zu erlangen und zu monetarisieren; also Vorsicht vor Kostenlos-Angeboten, denn im Kern zahlt man auch für ein kostenloses Angebot, im Zweifel mit seinen Daten. Eine andere Kernbotschaft läuft darauf hinaus, dass Daten auch missbraucht werden können, sei es von staatlicher Stelle oder von zwielichtigen Zeitgenossen.
Das Bändchen mit 272 Seiten ist kurzweilig geschrieben, wechselt zwischen tatsächlichen Begebenheiten, Sachbuchdarstellung, fiktiven Geschichten und netzpolitischen und gesellschaftspolitischen Erwägungen geschickt hin und her. Der leichte und nicht in technische Details verliebte Sprachstil sowie die Art, wie technische Probleme dargestellt werden, macht es sicherlich auch einem Laien einfach, den Themen zu folgen und etwas hinter die Geschäftspraktiken und die Techniken zu sehen.
Das Buch leidet an mancher Stelle etwas, da die Kraft des Arguments nicht so richtig einschlagen mag. Beispiele sind insbesondere die Frage, wie man sich denn nun gegen die Datenfresser wehrt oder die Argumentation gegen die “Wer nichts zu verbergen hat…”-Ideologie. Das wirkt an der einen oder anderen Stelle zwar bemüht, aber nicht so kraftvoll, wie man sich das erhofft hat. Insbesondere ein schlüssiges Gegenkonzept hätte noch etwas breiter und prominenter ausgearbeitet werden können.
Auch werden zum Teil Gefahren und Befürchtungen recht abstrakt beschrieben, manchmal auch mit Hinweis, so etwas sei schon vorgekommen, aber man hätte es dann an der einen oder anderen Stelle doch gerne genauer gewusst.
Eher ein Buch zum Verschenken an Leute, die noch nicht so firm im Netz sind.
Constanze Kurz/Frank Rieger, Die Datenfresser, 272 Seiten, S. Fischer Verlag, 16,95 EUR.
Ein Nachtrag zu meinem Eintrag über den E-Postbrief. Da überall von “qualifizierter elektronischer Signatur” die Rede ist, möchte ich gern auf Folgendes hinweisen: Lässt sich der Benutzer ein Zertifikat zum zusätzlichen Verschlüsseln und Signieren erzeugen, so darf man sich ob der Güte dieses Schlüssels nicht täuschen. Es handelt sich dann nämlich nicht um eine qualifizierte elektronische Signatur nach Signaturgesetz. So leicht erlesbar aus der Leistungsbeschreibung E-Postbrief; dort heißt es unter den “Zusatzleistungen”:
"Persönlich signiert: Der Absender signiert die Nachricht zusätzlich mit seinem privaten Schlüssel. Da der private Schlüssel eine eindeutige Zuordnung zu einem Nutzer ermöglicht, erhöht dies den Grad der Authentifizierung.
Die eingesetzten Verschlüsselungsverfahren erfüllen allerdings nicht die Voraussetzungen einer qualifizierten elektronischen Signatur nach dem Signaturgesetz (SigG), so dass gesetzlich vorgesehene Schriftformerfordernisse nicht erfüllt werden."
Schade, so hat die Post noch eine Möglichkeit mit ihrem Produkt zu punkten verpasst und lässt den Ball ins Seitenaus rollen.
So, da kam er also mit viel Marketingaufwand: Der E-Postbrief der Deutschen Post. Wohl mit Absicht etwas vor der Einführung der DE-Mail, einer Initiative der Bundesregierung. Nachdem dann auch ein Werbeflatterer in meinem (normalen) Briefkasten gelandet ist, habe ich mir einen Selbstversuch gegönnt und die neue Plattform testen wollen. (Erinnern Sie sich übrigens daran, dass die Post, ich glaube sogar auch unter der URL epost.de schon vor Jahren jedem Bundesbürger eine lebenslang gültige E-Mail-Adresse versprochen hat? Nach einigen Jahren starb dieses E-Mail-Portal-Projekt. Werden schon Wetten auf das Ende des E-Postbriefs angenommen?)
Two of my code snippets for org-mode are not working with the actual master of the git repository. I have to check this and I am going to fix them when I find enough time for that.
Folgende Ereignisse finde ich ja sehr erhellend: Telepolis berichtete von einer Studie (Pollet und Nettle, 2009), in der anhand von Daten aus dem “Chinese Health and Family Life Survey” der Schluss gezogen wurde, dass die Zahl der Orgasmen einer Frau mit dem Einkommen des Partners ansteige:
“In a large representative sample of the Chinese population, we found evidence that women’s self-reported orgasm frequency increases with the income of their partner.” (Pollet und Nettle, 2009, S. 149)
Etwas später berichtete Telepolis, dass dem wohl doch nicht so sei. Was war passiert? Die Forscher Esther Herberich und Torsten Hothorn haben die Analysen mit den frei verfügbaren Daten nachgerechnet und erhielten andere Ergebnisse (Herberich et al., 2010). Ursache war, dass der in der von Pollet und Nettle (2009) verwendeten Software (SPSS 15.0) der Algorithmus zur Auswahl des besten Modells (verwendet wurde ein ordinal regression model) einen Fehler aufwies: Die Kriterien zur Modellauswahl (Akaike Information Criteion (AIC) und Bayesian Information Criterion (BIC)) wurden in der Standardeinstellung der Modellauswahl falsch berechnet, so dass die Kriterien eigentlich nicht verglichen werden konnten. In der Folge kam es zu einer verkehrten Modellauswahl für das beste Modell. Herberich et al. berechneten die Analysen mit R neu und kamen zu anderen Ergebnissen: So konnte das Modell durch die Aufnahme weiterer Variablen verbessert werden; und zwar derart, dass der Einfluss des Einkommens letztendlich nicht mehr signifikant war. In der Korrektur ihres Beitrages fassen Pollet und Nettle (2010) dies wie folgt zusammen:
The association in the CHFLS (Chinese Health and Family Life Survey, D.B.) data between partner wealth and self-reported orgasm frequency ist best explained by the fact that women with higher-income partners are healthier, happier, younger, and more educated than women with lower-income partners. The data do not support a direct effect of partner income on self-reported orgasm frequency, once other variables have been controlled for." (Pollet und Nettle, 2010, S. 149)
Zusammengefasst: (1) Erst durch das Bereitstellen der Daten konnte ein anderes Forscherteam die Anwendung der Methode prüfen und stieß auf die oben skizzierten Merkwürdigkeiten. Somit war es möglich, nach den Ursachen für die falsche Modellauswahl zu suchen. (2) Es zeigt sich, dass eine geschlossene, proprietäre Implementierung so ihre Tücken hat; wenn eine Gemeinschaft gegenseitig Kontrolle über Implementierungen von Modellen übt und sie verbessert, kann auch hier wieder ein System der gegenseitige Kontrolle wirksam werden, was zu einer höheren Qualität führen kann.
Literatur:
- Pollet, T. und Nettle, D. (2009), Partner Wealth predicts self-reported orgasm frequency in a sample of Chinese women, Evolution and Human Behavior, Volume 30, S. 146–151.
- Herberich, E., Hothorn, T., Nettle, D. und Pollet, T. (2010), A re-evalutation of the statistical model in Pollet and Nettle 2009, Evolution and Human Behavior, Volume 31, S. 150–151 (sowie der Online Appendix).
- Pollet, T. und Nettle, D. (2010), Correction to Pollet and Nettle (2009): “Partner wealth predicts self-reported orgasm frequency in a sample of Chinese women”, Evolution and Human Behavior, Volume 31, S. 149.