Links zur Corona Krise auf heise.de
bundesgesundheitsministerium.de/coronavirus.html
Link zur JHU Desktop Version
arcgis.com/apps/opsdashboard/index.html#/bda7594740fd40299423467b48e9ecf6
Link zur JHU Mobile Version
arcgis.com/apps/opsdashboard/index.html#/85320e2ea5424dfaaa75ae62e5c06e61
Wagyu Burger Rezept von Malte
Ihr kennt das vielleicht auch. Man nimmt ein Huawei Gerät zur Hand, weil man im Netz gelesen hat, dass es ein Firmware Update mit Verbesserungen gibt. Dann schaltet man das Gerät ein, aber es wird kein Update angezeigt. Weder über die Einstellungen noch über die App HiCare.
Das kann natürlich verschiedene Gründe haben. Updates werden auch bei Huawei – wie bei vielen anderen Herstellern – in Wellen ausgerollt. Dadurch vermeidet man natürlich auch, dass man gleich alle Geräte eines Typs weltweit lahmlegt wenn es denn doch noch einen Bug in der Software gibt.
Was aber definitiv ein Update verhindert, ist wenn keine SIM Karte im Gerät steckt. Offensichtlich prüft der Update Prozess zunächst auf eine SIM Karte bevor es nach dem Update sucht.
Leider wird dies aber an keiner Stelle angezeigt. Es wäre ja auch denkbar, nach dem Update Check eine Meldung anzuzeigen, die darauf hinweist, dass Gerät ohne installierte SIM keine Updates erhalten.
Ich konnte dieses Verhalten mittlerweile bei diversen Huawei Geräten wie P20 Pro / Mate 20 Pro und auch einem Honor 10 nachvollziehen.
Eine der meistgenutzten Anwendungen auf meinem Androiden ist neben dem unvermeidlichen RSS Reader natürlich eine gute Wettervorhersage App.
Hier hatte ich, vom iPhone kommend, das Glück, dass die beste Wetter App für das iPhone auch in der Android Welt verfügbar ist. Dabei handelt es sich um WeatherPro von der MeteoGroup, dass es im Übrigen für fast alle anderen mobilen Plattformen gibt, sogar für Windows Phone 7.
Das Programm hat ein sehr prägnantes blaues Design. Beim Start der Anwendung holt sich die App das aktuelle Wetter für die gerade eingestellte Stadt. Das dauert je nach Qualität der Internetverbindung schon mal einen Moment. Dafür wird man danach aber auch mit einer detaillierten Wettervorhersage für die nächsten 8 Tage belohnt.
Ab dem vierten Tag sollte man die angezeigten Daten naturgemäß nicht mehr für bare Münze nehmen. Auch die Meteogroup kann nicht zaubern und so weit in die Zukunft blicken.
Wählt man einen Tag aus, wechselt die Anzeige in eine detaillierte Tagesübersicht, welche das Wetter in 3 Stunden Schritten anzeigt. Gerade diese Anzeige ist eine der Stärken des Programms, da es eine Planung des Tages sehr erleichtert. Ist ab 16:00 Uhr Regen angesagt, macht man den Spaziergang an diesem Tag besser etwas zeitiger.
Neben diesen Temperatur- und Wetteranzeigen gibt es noch Bildschirme mit einem Satelitenbildfilm der Wolkenentwicklung sowie ein Regenradar. Das nutze ich aber eher selten. Bei diesen Ansichten wird der aktuell ausgewählte Ort deutlich markiert, so dass der lokale Bezug nie verloren geht.
Die Orte kann man bei WeatherPro sehr komfortabel suchen. Die Suche ist dabei sehr fehlertolerant und auch kleinere Orte werden gefunden.
Seit einem der letzten Updates gibt es endlich auch ein Desktop Widged das immer den Ort anzeigt der zuletzt in WeatherPro ausgewählt wurde.
Alles in allem habe ich festgestellt, dass die Vorhersagen in WeatherPro sehr genau sind. Natürlich kann sich Wetter auch mal kurzfristig ändern. In aller Regel treffen die Vorhersagen, die dieses Programm trifft recht genau zu, zumindest solange es sich auf die kommenden 3 Tage bezieht.
Das Programm gibt es im Android Market und es kostet angemessene 2,99 EUR.
Eigentlich habe ich das Dashboard von Mac OS X nie ernsthaft benutzt, aber als ich über den kleinen Timer von Nitram+Nunca gestolpert bin, habe ich meine Meinung geändert.
Das Ding ist so schick anzusehen und so intuitiv zu bedienen. Da kann man einfach nicht nein sagen.
Wenn der Timer abgelaufen ist, startet dezent ein Song aus der iTunes Library und erinnert an die abgelaufene Zeit.
[Update] Mittlerweile ist der Timer kein Dashboard Widged mehr, sondern eine normale App die über den Finder bzw. über das neue Launchpad gestartet werden kann. Der Timer ist als App im MacAppstore erhältlich und kostet 0,79 cent. Ein Preis der für den schicken Timer völlig in Ordnung ist.
Da im Moment das RAM extrem günstig ist, habe ich kurzerhand einen RAM Ringtausch bei meinen Mac Rechnern vorgenommen.
Dafür habe ich zunächst bei Crucial mal ein Pärchen 2GB DDR2 RAM Riegel für meinen weisses MacBook bestellt. Bei Crucial kann man das RAM für Mac Rechner über ein sehr komfortables Menüsystem ermitteln lassen. Damit ist man sehr sicher, dass man auch das passenden RAM für seinen Rechner bestellt.
Der Preis für eine DDR2 RAM Aufrüstung ist (Stand 12/2008) mit 47,60 EUR inkl. MwSt. und 7 EUR Fracht aus England für 4GB (2x 2GB DDR2 RAM) sehr günstig. Am 21.12. (Sonntag) bestellt, und am 24.12. morgens stand der UPS Wagen vor der Tür um das RAM abzuliefern.
Im weissen MacBook waren die beiden Riegel schnell eingebaut. Wie zu erwarten war, gab es keine Probleme mit dem RAM.
Nun sollte das alte RAM aus dem MacBook (2x 1GB RAM) in meinen Mac Mini wandern, der mit 2x 512MB doch etwas karg ausgestattet ist. 
Also musste wieder der Spachtel aus dem Keller geholt werden und die etwas diffizile Gehäuseöffnung stand mir bevor. Zum Glück gibt es bei MacNotes eine ausgezeichnete Anleitung wie man den Mac Mini öffnet um die Festplatte auszutauschen. Befolgt man die Anleitung, liegt auch das RAM offen und man kann probemlos die beiden Riegeln herausnehmen und gegen neue austauschen.
Es ist immer wieder eine kleiner Nervenkitzel wenn man den kleinen Mac wieder in seine weisse Keksdose drückt. Aber zum Glück ist alles gut gegangen und auch das alte RAM aus dem MacBook wurde im Mac Mini problemlos erkannt.
So, nun wo mein Mac Mini mit 2 GB RAM und einer 400GB Festplatte gut bestückt ist, kann eigentlich das Update für den kleinen Mac kommen 😉
Dieser Artikel beschreibt, wie man einen Tomcat Server unter Eclipse mit der Servers View verwalten kann.
Die folgenden Vorgehensweise wurde unter Eclipse 3.4.1 und Tomcat 5.5.27 getestet.
In der Server View wird zunächst ein neuer Server angelegt. Dabei gehe ich davon aus, dass ein passender Tomcat in der gewählten Entwicklungslinie (bei mir 5.5.27) bereits irgendwo im Filesystem bereitsteht. Ist dies nicht der Fall, kann man einfach ein Tomcat Archiv von http://tomcat.apache.org herunterladen und irgendwo im Filesystem entpacken.
Im Eclipse wählt man dann unter Window-Show View-Others… die Servers View aus. Mit der rechten Maustaste wird ein neuer Server angelegt.
Zunächst wechselt man auf die View „Servers“. Dort legt man mit dem Befehl „rechte Maustaste“ – „New“ – „Server“ einen Server an.
Ist noch kein passender Server installiert, muss zunächst eine Server Runtime angelegt werden.
Im nachfolgenden „New Server“ Dialog legt man den Server Typ – in unserem Beispiel ein Apache Tomcat 5.5 Server – und den Namen des Servers, sowie den Installationsort des Servers fest. Optional können auch sofort Projekte zum Server hinzugefügt werden. Die entsprechende Runtime für den Tomcat Server muss natürlich schon vorhanden sein.
Mit einen Doppelklick auf den Server gelangt man in den eigentlichen Konfigurationsdialog. Hier kann man z.B. den Port für den Server abweichend vorgeben.
Ganz wichtig ist das anhaken der Option „Serve Modules without publishing“, das vereinfacht später das Deployment. Siehe hierzu auch den folgende Abschnitt „Projekte zum Server hinzufügen“. Wir verwenden zum Start des Tomcat einzelne Kontext Dateien, auch das ist über ein Checkbox steuerbar.
Weiterhin, kann man über diese Maske auch direkt in die Launch Konfiguration des Servers verzeigen wo man die Parameter für den Start des Tomcat anpassen kann.
-Dcatalina.base="I:\testprojekt\.metadata\.plugins\org.eclipse.wst.server.core\tmp1" -Djava.endorsed.dirs="I:\apache-tomcat-5.5.27\common\endorsed" -Djava.io.tmpdir="I:\apache-tomcat-5.5.27\temp" -Dfile.encoding=ISO-8859-15 -Dlog4j.configuration=log4j.tomcat.xml -Dwork.dir=I:\apache-tomcat-5.5.27\logs -Xmx512M -XX:MaxPermSize=128m -Dcatalina.home="I:\apache-tomcat-5.5.27" -Dwtp.deploy="I:\testprojekt"
Durch die Anlage des Servers werden die meisten Einträge hier schon automatisch eingetragen. Es müssen nur die Werte ergänzt werden, die Ihr für euren Server spezifisch benötigt.
Auf dem zweiten Reiter des Konfigurationsdialoges kann man Webmodule zum Server hinzufügen oder auch wieder entfernen. Dabei werden nur WebProjekte im Sinne des Eclipse zum Deploy angeboten. Neben der Document Base, wird noch der Pfad hier angegeben. Dieser enthält als Defaulteinstellung zunächst den Namen des Projektes. Wir verwenden in den meisten Fällen Kurzformen des Projektnamens in Kleinbuchstaben.
Dadurch, dass wir im Server den Haken „Server Modules without publishing“ gesetzt haben, wird zur Laufzeit direkt auf den classes Ordner der Eclipse Installation verwiesen. Dadurch startet der Server deutlich schneller und man kann seinen Code in schnelleren Zyklen testen.
Hat man in seinem Projekt weitere Projekte referenziert (z.B. Framework Projekte die ausgelagert wurden) will man natürlich auch diese zur Entwicklungszeit nicht als JAR deployen, sondern einfach direkt das JAR File referenzieren. Diese Projekte muss man dann in den Project Properties (rechte Maustaste auf dem Webprojekt) im Unterpunkt „Java EE Module Dependencies“ eintragen. Das, im Zusammenspiel mit dem Haken „Serve modules without publishing“ führt dann zur Laufzeit dazu, dass die referenzierten Projekte im Classpath liegen und auch für den Debugger erreichbar sind.
Einzelne Server können dann über die Server View im Debug oder im normalen Run gestartet werden. Befindet sich der Server nicht im Zustand „Synchronized“ ist vor dem Start ein „Publish“ durchzuführen.
Es können natürlich immer nur Server parallel gestartet werden, die auf unterschiedlichen Ports laufen, aber das sagt die Fehlermeldung dann auch.
Im Prinzip kann sich also jeder Entwickler einen eigenen Server mit „seiner“ Module Zusammenstellung erstellen.
Diese Vorgehensweise zur Verwaltung der Server hat einige Vorteile. So ist z.B. die Konfiguration der Server von der eigentlichen Tomcat Installation klar getrennt. Man kann auch beliebig viele Serverkonfigurationen auf einer einzigen Tomcat Installation fahren.
Aber es gibt auch mindestens einen Nachteil. Durch die Art des Serverstarts, ist es erforderlich, dass alle JAR Files im WEB-INF/lib Verzeichnis des Servers liegen. Das führt zum einen dazu, dass dieselben JAR Files mehrfach in der Entwicklungsumgebung liegen, andererseits ist es dadurch aber auch möglich feingranular die verwendeten JAR Files für alle Server getrennt zu definieren.