Tools

Hat man in Eclipse ein Project als General Project angelegt, und merkt im Laufe des Projektes, dass der Anteil an PHP im eigenen Projekt immer mehr überwiegt, dann liegt es nahe, das Projekt in ein PHP Project umzuwandeln.

Die Vorteile, die man durch die Umwandlung erhält, sind u.a. die Möglichkeit der Nutzung des PHP Explorers, in dem z.B. der gesamte PHP Core durchsucht werden kann oder in dem auch Fremdbibliotheken, wie PEAR durchsucht werden können.

Außerdem ist neben Code Assist für PHP nach der Umwandlung in ein PHP Projekt auch das Anzeigen der Outline einer PHP Datei möglich.

Diese Umwandlung eines "General Projects" in ein "PHP Project" ist in Eclipse über folgenden Weg möglich:

1. .project Datei im jeweiligen Projekt

Zeile mit "nature-Tag" suchen und folgendes einfügen:

Vorher

<natures>
</natures>

Nachher

<natures>
<nature>
org.eclipse.php.core.PHPNature
</nature>
</natures>

2. .buildpath Datei im jeweiligen Projekt

Vorher

<?xml version="1.0" encoding="UTF-8"?>
<buildpath>	 	
<buildpathentry kind="src" path=""/> </buildpath>
</buildpath>

Nachher

<?xml version="1.0" encoding="UTF-8"?>
<buildpath>
<buildpathentry kind="con" path="org.eclipse.php.core.LANGUAGE"/>
<buildpathentry kind="con" path="org.eclipse.dltk.USER_LIBRARY/PEAR"/>
<buildpathentry kind="src" path=""/>
</buildpath>

Fazit

Eigentlich wird hier nur die "Nature" des eigenen Projektes in der .project-Datei auf PHP umgeändert und zusätzlich in der .buildpath-Datei die PHP Core Library und in diesem Fall auch die PEAR Library mit ins Projekt eingefügt.

Durch diese kleinen Änderungen wird dann schnell aus einem "General Project" ein "PHP Project".

Zusatz

Diese Änderungen können natürlich auch für jede andere Sprache gemacht werden.

Für die Umwandlung in ein Java Project muss z.B. nur diese Zeile im "Nature-Tag" der .project-Datei eingefügt werden:

<natures>
<nature>org.eclipse.jdt.core.javanature</nature>
</natures>

Schon wieder einen guten Monat her, dass ich hier geschrieben habe, aber wenn man sich auch mit solchen, wie den folgenden Problemen rumschlagen muss, ist es ja kein Wunder, dass man nicht mehr zum Schreiben von Blogbeiträgen kommt. :)

Folgende Problematik:

In unserer neuen Android App benutzen wir einen REST-Webservice, der über SSL angesprochen wird. Soweit für Android auch kein Problem, nur benutzen wir auf Serverseite  ein SSL-Zertifikat von Telesec welches als Root Zertifikat auf Baltimore Cybertrust verweist.

Jetzt würde man denken, na und, ist doch egal, Baltimore ist doch, neben zB. Verisign (was von Google selbst benutzt wird) eine bekannte Zertifizierungsstelle und ein von dort abgesichertes Zertifikat wird jawohl als Standard in jedem Betriebssystem enthalten sein ...

Tja, dieser gemeldete Bug beim Android-Tem aus dem Juni 2010 sagt darüber etwas ganz anderes:

http://code.google.com/p/android/issues/detail?id=9269

So also auch in unserem Fall. Unsere Android-Anwendung hängte sich immer wieder mit einer internen Android Fehlermeldung über ein ungültiges Zertifikat auf Serverseite auf.

Wenn man mit dem HandyBrowser direkt auf die Seite unseres Webservice gesurrft ist, kam natürlich auch eine SSL-Fehlermeldung, diese kann man im Browser aber wegklicken, und die entsprechende Seite trotzdem besuchen.

Innerhalb einer eigenen Anwendung gibt es diese Möglichkeit so nicht, und da die Antwort auf das Baltimore Root CA Problem von Seiten Google erst ein Jahr später kam (siehe Issue oben) und die Antwort darin bestand, doch bitte Android 2.3 zu nutzen, da erst dort das Root CA von Baltimore eingebaut wurde, war für uns, die wir auch noch Handys mit Android 2.1 unterstützen wollen, erstmal guter Rat teuer.

Zum Glück hat sich ein findiger Entwickler aus Lichtenstein diesem Problem angenommen und dafür eine Lösung entwickelt, um das Problem zu umgehen.

Hier der Blogbeitrag, der beschreibt, wie man sich ein eigenes Zertifikat in einem selbst erstellten Keystore im Ressourcen Verzeichnis seiner Android-Anwendung ablegt, und wie man dieses Zertifikat dann benutzt, um über einen eigenen WebserviceClient seinen SSL-gesicherten Webservice zu benutzen.

http://blog.antoine.li/index.php/2010/10/android-trusting-ssl-certificates/

Ich werde im Folgenden unsere Umsetzung beschreiben und mich dabei stark an den hier genannten Artikel anlehnen, da dieser auch mir bei der Impementierung als Vorlage geholfen hat.

#################

Tutorial zur Erstellung eines eigenen Keystores und
Nutzung dieses Keystores innerhalb eines eigenen Android Webservice-Clients

Ich bin die nächsten 3 Tage auf der IPC in Mainz unterwegs und werde mir verschiedenste Vorträge über aktuelle Themen in der Webentwicklung anhören.

Die Webtechconferenz findet parallel zur IPC im gleichen Kongresszentrum statt und bietet auch einige interessante Vorträge.

Ob über die Zukunft von PHP (5.4), über Git, Testing, Sicherheit in der Softwareentwicklung, Frontendsachen wie HTML 5, Javascript und CSS 3, NoSQL-DBs, Frameworks bis hin zu DevOpsGeschichten wie Continious Integration oder auch der Entwicklung von mobilen Apps ist einiges dabei, was mich interessiert.

Ich werde zu den Vorträgen die ich besuche, versuchen zeitnah jeweils etwas zu schreiben.
Außerdem schau ich mal, dass ich die Slides der Vorträge, die mich interessieren hier zusammentrage.

Hier vorab schonmal die Links beider Veranstaltungen:

http://phpconference.com/

http://webtechcon.de/

Wie ihr sicher bemerkt habt bin ich momentan stark im Thema Mobile Apps drin und da kommt man natürlich an Android nicht vorbei.

Eine Sache, die sofort auffällt und auch ziemlich nervt, ist die Geschwindigkeit innerhalb der emulierten Geräte des Android SDK.

Egal welche Ausstattung mein Rechner hat und egal wieviel Ressourcen ich dem neuen Device zuweise (zB. ein Testdevice mit Android 3.2 und 1GB RAM), das erstellte Device ist einfach immer sehr langsam und dadurch extrem schlecht zu bedienen.

Das macht das Entwickeln und Testen zu einer nervigen Angelegenheit.

Abhilfe schafft hier der Einsatz einer Virtuellen Maschine, in die man dann eine Android-x86 Portierung installiert.

Ein guter Artikel inkl. Anleitung und was es zu beachten gibt, findet sich hier:

http://swe.fin-sn.de/blog/android-x86-virtual-box

Was für ein verrückter Bug.

Versucht man das Android SDK für Windows über die installer...exe zu installieren  (installer_r12-windows.exe) erkennt der Installer das auf meinem System vorhandene Java Development Kit nicht.

PATH zu JDK ist gesetzt und ich habe das JDK auch für andere Sachen schon erfolgreich im Einsatz. (zB. Eclipse).

Etwas Recherche förderte dann die mehr als merkwürdige Lösung zu Tage.

Einfach in oben gezeigter Maske nochmal einen Schritt zurück über (< Back), dann im vorherigen Schritt über (Next >) die Erkennung des JDK noch einmal durchführen und Siehe da:

Das JDK wird erfolgreich erkannt.

Also wie diese Magic funktioniert muss mir Google mal genauer erklären :).

Nachdem ich hier schon darüber geschrieben habe, wie man die Organisation von Softwareprojekten mit Hilfe der Ticket basierten Projektmanagementsoftware Trac verbessern kann, und wie man, bevor man dies tut, erstmal Trac und auch ein zugehöriges Versionierungssystem (in meinem Fall SVN) konfiguriert, soll es heute darum gehen, wie man denn Trac installiert.

Diese Reihenfolge ist reichlich merkwürdig, da natürlich die Installation als erstes kommt, aber irgendwie hat es sich ergeben, dass ich bei meinen ersten Trac-Installationen recht wenig dokumentiert hatte, nun aber wiedermal Trac neu auf unserem Server installiert werden mußte und ich im Zuge dessen auch endlich die Konsole mitgeloggt habe, um später die Installationsschritte besser nachvollziehen zu können.

Eines vorweg, mein oben verlinkter Artikel, in dem ich die Konfiguratioin von Trac schonmal beschrieben habe, basiert auf einer Trac-Installation, die einen Apache mit mod_python als Basis nutzt.

Hier dagegen soll es um eine Trac-Installation mit Apache und mod_wsgi gehen, d.h. ich beschreibe die Installation von modwsgi, anschließend gehts weiter mit Setuptools, danach kommt Trac (inkl. anlegen einer ersten Instanz) und anschließend zeige ich noch eine Basiskonfiguration eines Apache-VHosts für unsere erste Trac-Instanz, die dann auch gleich mit HTTP-Digest-Auth abgesichert wird.

Ich werde auch gar nicht so viel Worte verlieren, sondern die Konsole sprechen lassen, und nur kurz die einzelnen Schritte erläutern. Das heißt, ihr seht immer die jeweils notwendigen Befehle fett markiert und könnt diese einfach selbst ausführen. Ein gewisses Basiswissen im Umgang mit Linux setze ich hier aber voraus.

Also, auf gehts ...

Ja ja, das täglich Brot als Webentwickler, die lieben Logfiles.

Ich kann gar nicht mehr zählen wie oft und auf wievielen Servern ich schon:

tail -f /var/log/apache/access.log  oder  .../error.log  oder .../php.log eingegeben habe.

Und auch in der Windows-Welt beim lokalen Entwickeln will ich ziemlich oft wissen, was der Apache oder andere Tools gerade so an Logfiles ausspucken. Tail für Windows gibt es viele verschiedene und dies soll keine Liste mit unterschiedlichen Alternativen werden, sonder einfach nur ein Hinweis auf das Tool, mit dem ich am Besten klarkomme.

Tail for Win32 (http://tailforwin32.sourceforge.net/)

Gutes Tool, einfach zu bedienen und für meine Zwecke völlig ausreichend.

Nachdem wir unseren Server auf PHP 5.3 geupdatet hatten, fiel uns auf, dass einige Bereiche von Confixx nicht mehr richtig liefen. Unter anderem im Bereich Domains.

Jede konfigurierte Domain wurde mehrere Male hintereinander in einem Kunden-Account angezeigt (Benutzeroberfläche / Einstellungen / Domain-Seite, Tabelle Domainverwaltung).

Problem ist hier, dass Confixx <= 3.3.6 nicht mit PHP 5.3 umgehen kann.

Folgender Patch behebt aber das Problem:

http://kb.parallels.com/de/8078

Immer mal wieder kommt die Aufgabe, sich in einem Linuxsystem relevante Systeminformationen zur Hardwareausstattung, zur Kernelversion, zu den installierten Paketen usw. anzeigen zu lassen.

Um nicht jedesmal alle Befehle einzeln eingeben zu müssen, kommt hier ein kleines Shell-Script, was wesentliche Infos zusammenfasst und in eine Datei schreibt.

 #!/usr/bin/sh 

 rm  /tmp/systeminfo    
   
 echo -e "\n`tput smso`Platform info`tput rmso`" >> /tmp/systeminfo 
 uname -a >> /tmp/systeminfo 
 
 echo -e "\n`tput smso`Release info`tput rmso`" >> /tmp/systeminfo 
 cat /etc/*-release >> /tmp/systeminfo  
 
 echo -e "\n`tput smso`CPU info`tput rmso`" >> /tmp/systeminfo 
 cat /proc/cpuinfo  >>  /tmp/systeminfo 
 
 echo -e "\n`tput smso`Memory info`tput rmso`" >> /tmp/systeminfo 
 dmesg | grep -i memory >>  /tmp/systeminfo 
 
 #echo -e "\n`tput smso`Package info`tput rmso`" >> /tmp/systeminfo 
 #rpm -qa >> /tmp/systeminfo 
 
 cat /tmp/systeminfo  

Die Infos über die installierten Pakete sind hier auskommentiert, wenn man die mit haben will einfach de beiden Zeilen wieder mitnehmen.

Das cat zum Anzeigen der Systeminfo ist gleich mit drin am Ende.

Achja, und nicht wundern über die tput's, die sind nur zum Highlighting der Überschriften und dienen der Übersichtlichkeit.
 

Erscheint diese Meldung im error.log des Apache, wenn er nicht mehr starten will, bedeutet das, dass der Apache nicht ordentlich runtergefahren ist und sich ziemlich viele semaphore-arrays des Apache-Users angesammelt haben.

Diese kann man sich so anzeigen lassen:

ipcs -s | grep www-data

www-data ist der Apache-User. (Oder wie er halt sonst so heißt)

Löschen kann man diese überflüssigen Arrays so:

ipcs -s | grep www-data |  perl -e 'while (<STDIN>) {@a=split(/\s+/); print `ipcrm sem $a[1]`}'

Danach startet auch der Apache wieder.