Das letzte Event der Reihe in München ist nun vorbei. Ich fand die Vorträge sehr interessant. Ich kenne das Thema aus der Entwickler-Perspektive. Es ist aber hilfreich zu erfahren, wie ein Anwalt die mobilen Apps aus einem ganz anderen Blickwinkel sieht… Ein besonderes Highlight für mich war auch die live Vorführung auf dem iPhone (inkl. Hacking) vom Security-Experten Andreas Kurtz.
Hier aktualisierte Slides von meinem Vortrag:
UMTS und die HSDPA Erweiterung versprechen sehr hohe Datenübertragungsraten. Wie sieht es aber mit der Latenz bzw. Paketumlaufzeiten (Round Trip Time) aus? Diese sind entscheidend für eine schnelle Kommunikation mit dem Server, z.B. für eine Business-Anwendung.
Das theoretische Versprechen (dunkelblau) lag bei meinen Messungen an verschiedenen Orten recht weit von der Realität (hell blau).
Sie können die Paketumlaufzeiten aber auch selber hier ermitteln und auch gerne samt Mobilfunkanbieter als Kommentar posten.
Kleine Anmerkung zu Latenz (engl. latency) und Paketumlaufzeiten (engl. RTT - Round Trip Time): die Erstere steht für die Verzögerung auf dem einfachen Weg, die Letztere steht für den Weg hin und zurück. Wenn der Server blitzschnell ausliefert, dann beträgt RTT genau das Doppelte der Latenz.
Mehr zum Thema auch in meinem Vortrag bei Heise Roadshow.
A good concept: The 22 minute meeting (updated) « Scott Berkun
Thanks to all people attended my talk and the workshop at the JavaScript Conference 2012 in Düsseldorf, Germany.
Due to spontanity of my talk - I had to step in for a fellow JavaScript enthusiast, who has suddenly become ill - there are no slides. So instead of slides I am posting links to the frameworks I mentioned in the talk.
You can package a hybrid app for different platforms with
These are general purpose frameworks which are very lightweight and for this reason well suitable for mobile browsers:
$ based syntax
with much less footprint
In the workshop we’ve created a small, native-app-looking web app using iUI. The app shows a list of current orders. When the user selects an order, order details are loaded via AJAX request and a small form is shown. User can add additional comments then.
iUI is a minimalistic JavaScript and CSS framework. You can download it here or read documentation for the current version, which recently implemented theming.
I originally developed jetty-rackup to have a Ruby way web application deployment in a JVM environment (with JRuby).
While currently not using the jetty-rackup in any of the projects, I still maintain it. Thanks to Nik for the Jetty 7.0 port!
You can install the newest Version with:
jruby -S gem install jetty-rackup
or have a look at the updated README.
The old version is still available on rubygems.org and github as a branch.
After playing around a bit, I must say, I completely agree with Ian Bicking:
You can work fluidly across client and server!
If anything I think this is dangerous rather than useful. The client and the server are different places, with different expectations. Any vagueness about that boundary is wrong.
Ian is talking about different purposes of client and server validation (user experience vs. data integrity), different libraries available. I am also thinking about organizing your source code. While using require() is nice on node.js, you should concatenate all your client js libraries in one file, minify and gzip them.
Thanks to non-blocking IO, node.js is very promizing in the instant notifications/Comet area. But it is not clear, how it is superior to the well established solutions like orbited for Python.
I’ll better stay with Ruby on Rails or Python and Django for now.
Folien von meinem Talk bei der KarlsruheJS UserGroup.
Do you make your web apps look like Windows apps on Windows and OS X apps on OS X? No? Why would you do that on mobile then?
In his thorough blog post Mathias Meyer describes how important it is for every developer to know the challenges of running applications in production environment.
I support almost every statement, but have a different opinion on two (out of more than a dozen) advices.
Note: the original blog post and my notes are both about Linux environment.
And yes, I think enabling swap on servers is a terrible idea. Let processes crash when they don’t have any resources left. That at least will allow you to analyze and fix.
Sometimes some long running processes continuously grow in size.
Memory is allocated to the process, used for some purpose but will
never be accessed again. Once I observed the Apache parent process on Ubuntu 10.04
growing by small size on every graceful restart.
While it is a good idea investigate all the memory leaks or to restart processes
running amok (preferably automatically with monit after they cross some defined threshold),
sometimes you can perfectly live with such problems just swapping off.
I would not make the swap partition on server too large. For a server with 4 GB RAM I would create 2 GB swap; for a server with 8 GB RAM not more than 3GB.
Separate request logging from application logging. Data on HTTP requests is just as important as application logs, but it’s easier if you can sift through them independently…
I found it is much easier to filter a big log file containing everything with ack/grep and awk or even ruby one-liners than stitching information together from different log files sorting by time.
Some tricks:
use ack to filter with regular expressions - extract the stuff, which is interesting for your investigation
ensure your log files are rotated regularly - do not let them grow infinitely!
Use a custom logrotate configuration if needed. man logrotate and reading example
files in /etc/logrotate.d should give you enough inspiration.
cut the amount of stuff need to be processed with head and tail
or use tail -f if you are analyzing the problem that happens exactly at this moment
reduce width with cut. Even the default apache log (without virtual host information) contains
very long lines with a full user agent string and referrer at the end. If you are only interested in, say, first 100 character of each of the last 40 lines, use
tail -40 apache_custom.log | cut -c1-100
if you are only interested in the client IP and the url he has accessed - these are the second and the eighth columns of my apache log - you can use awk to extract that columns:
tail -40 apache_access.log | awk '{print $2 $8}'
see also how to display a block of text (which goes over multiple lines) with awk
use less to interactively view and search interesting content. You can filter the logs as described above and put the result into a temporary file. vim is less suitable because it is much slower on huge files, especially if the syntax highlighting is activated.
prepend with zcat to access (older) compressed log files like
zcat apache_error.log.2.gz | ack 'my regex'
automate - put the piped commands for frequent cases into a bash or ruby script or at least document it in a wiki
you can even run a prepared script through ssh without opening a session manualy
ssh -t myserver ‘/home/me/my-prepared-script’
As a developer you can always let the computer do the stupid work! Give your eyes a rest, let ack do the scan and reduce the amount of information you have to read! That way you have more energy to analyze the problem.
Werden Sie auch ab und zu wach und haben eine tolle Idee? Sind Sie schon mal mit einem Problem im Kopf schlafen gegangen und morgens war die Lösung da?
Mein früherer Kollege Stefan Lieser schreibt über die Idee der Morning Pages.
Hintergrundinformationen gibt es auch im Buch
“Pragmatic Thinking”
