Seit kurzem hat Google uns das Leben etwas komplizierte gemacht. Laut ihr (Google) sollten wir halt auf unsere einfache in Bedingung, simple und vor allem heißgeliebte Picasa-Web zu gunsten von G+ verzichten.
Nein, das machen wir nicht! ;)
Hier einpaar Schritte wie das geht. Und gleich kann man's als Tutorial für Fotoalbum publizieren verwenden.
Schritt 0: Das kriegt man schon irgendwie selbst hin
Fotoalbum vorbereiten und hochladen und auf die Webseite von Picasa gehen:
https://picasaweb.google.com?noredirect=1
und zum Album springen.
Schritt 1: Berechtigungen bearbeiten
Für alle die den Link kriegen freischalten: "Eingeschränkt, alle mit dem Link"
Schritt 2: Link kopieren und am Ende des Links ein Parameter &noredirect=1 anhängen
Schritt Z: Einen Spende-Click auf die Werbung unten, Link verschicken an Menschen die uns lieb sind und fertig.
~Finito
Donnerstag, 18. Juli 2013
Dienstag, 2. April 2013
Полезняшка : Generate Constructor using Fields
Man-o-man, wie häufig habe ich schon diese Konstruktoren geschrieben die einfach die Parameter auf Felder setzen. Das kennt doch jeder: this.hallo = hallo; Man-o-man!!! Und das geht doch so einfach:
In der Klasse, an der Stelle wo Konstruktor platziert werden soll:
ALT+SHIFT+S + O
voilà
In der Klasse, an der Stelle wo Konstruktor platziert werden soll:
ALT+SHIFT+S + O
voilà
Donnerstag, 28. März 2013
Полезняшка : In Groß-/Kleinschreibung umwandeln
Um im eclipse eine Zeichenkette in Groß- bzw. Kleinbuchstaben zu konvertieren braucht man lediglich:
Text selektieren und
Lower case: CTRL+SHIFT+Y
Upper case: CTRL+SHIFT+X
~
Text selektieren und
Lower case: CTRL+SHIFT+Y
Upper case: CTRL+SHIFT+X
~
Montag, 4. März 2013
git merging approach
Nach dem wir von einfachem svn auf coolen git umgestiegen sind. Ging am Anfang gar nichts mehr. Das Merging mit dem eGit-Plugin und mit dem alten Rangehensweise wie bei SVN - funktionierte an der Stelle nicht.
Bei svn war das ganze schön einfach: vor dem Entwickeln einmal updaten dann anpassen, dann wieder updaten falls in Zwischenzeit jamand an der gleiche Stelle was gemacht hat - mergen und letzendilch commiten.
Bei git ist natürliche Weise alles komplizierte, oder denke ich das nur so. Auf jedem Fall habe ich nach lange Suche keinen vernünftigen Tutorial gefunden, wie das normale Arbeitsablauf mit git funktionieren soll.
Nach langem hier-und-her habe ich für uns folgende Vorgehensweise identifiziert.
Über Feedback und Hinweise, dass es auch einfache gehen kann, werde ich mich freuen.
Übrigens, ich mache jetzt alles über Konsole, da eGit bei den ersten Versuchen nicht so richtig funktioniert hat.
Das Geheimnis des erfolgreichen Mergen mit git liegt im lokalen Branch!
Also so gehe ich vor:
10: Begin:
20: Aktuelle Version des Codes herunterladen (svn update)
git pull
30: Eigenen lokalen Branch anlegen (das kann auch später gemacht werden, aber auf jedem Fall vor dem ersten add/commit)
git checkout -b FeatureXXX (Name des Branches kann z.B. der zu entwickelnde Feature oder Bug sein)
40: (Optional) Alle branches anschauen und wo man gerade arbeitet, das wird mit * vermekrt.
git branch
50: Programmieren und Entwicklen und add und commit, und add und commit ...
git add -A
git commit -m "das FeatureXXX ist schon fast fertig"
60: Wenn man fertig mit dem Feture/Fix ist, dann letztes mal commiten und zurück auf den master (trunk) switchen
git checkout master
70: Noch mal von dem remote updaten, kann ja sein dass in der Zwischenzeit jemand was gemacht und commitet hat
git pull
Jetzt haben wir im lokalen master die aktuelle Version von dem Server und im Branch FeatureXXX unsere Anpassungen.
80: Jetzt wird gemergt, wichtig ist dass das Merging von dem master gemacht wird. Das kann mit git branch überprüft werden.
master branch, you can pruef it with "git branch")
git merge FeatureXXX
90: Im Eclipse nachschauen ob wir keine Konfikte haben, dafür ist eGit gut. Die Konflikte werden mit rotem Sternchen vermerkt. Wenn wir so viel Gluck haben, das keine Konflikte entstanden sind (kann natürlich auch daran liegen, dass keine sonst außer uns was gemacht hat :) ) Dann Pushen:
git push
100: Wenn Konflikte nach dem Merging entstanden sind, dann müssen diese manuelle behoben werden und dann wie üblich: add/commit/push
git add -A
git commit -m "FeatureXXX ist gemerget"
git push
110:END
Ich teste erfolgreich das Vorgehen schon seit 3 Wochen.
Hier noch ein gutes Tutorial für großere Teams:
http://nvie.com/posts/a-successful-git-branching-model/
Good luck
Bei svn war das ganze schön einfach: vor dem Entwickeln einmal updaten dann anpassen, dann wieder updaten falls in Zwischenzeit jamand an der gleiche Stelle was gemacht hat - mergen und letzendilch commiten.
Bei git ist natürliche Weise alles komplizierte, oder denke ich das nur so. Auf jedem Fall habe ich nach lange Suche keinen vernünftigen Tutorial gefunden, wie das normale Arbeitsablauf mit git funktionieren soll.
Nach langem hier-und-her habe ich für uns folgende Vorgehensweise identifiziert.
Über Feedback und Hinweise, dass es auch einfache gehen kann, werde ich mich freuen.
Übrigens, ich mache jetzt alles über Konsole, da eGit bei den ersten Versuchen nicht so richtig funktioniert hat.
Das Geheimnis des erfolgreichen Mergen mit git liegt im lokalen Branch!
Also so gehe ich vor:
10: Begin:
20: Aktuelle Version des Codes herunterladen (svn update)
git pull
30: Eigenen lokalen Branch anlegen (das kann auch später gemacht werden, aber auf jedem Fall vor dem ersten add/commit)
git checkout -b FeatureXXX (Name des Branches kann z.B. der zu entwickelnde Feature oder Bug sein)
40: (Optional) Alle branches anschauen und wo man gerade arbeitet, das wird mit * vermekrt.
git branch
50: Programmieren und Entwicklen und add und commit, und add und commit ...
git add -A
git commit -m "das FeatureXXX ist schon fast fertig"
60: Wenn man fertig mit dem Feture/Fix ist, dann letztes mal commiten und zurück auf den master (trunk) switchen
git checkout master
70: Noch mal von dem remote updaten, kann ja sein dass in der Zwischenzeit jemand was gemacht und commitet hat
git pull
Jetzt haben wir im lokalen master die aktuelle Version von dem Server und im Branch FeatureXXX unsere Anpassungen.
80: Jetzt wird gemergt, wichtig ist dass das Merging von dem master gemacht wird. Das kann mit git branch überprüft werden.
master branch, you can pruef it with "git branch")
git merge FeatureXXX
90: Im Eclipse nachschauen ob wir keine Konfikte haben, dafür ist eGit gut. Die Konflikte werden mit rotem Sternchen vermerkt. Wenn wir so viel Gluck haben, das keine Konflikte entstanden sind (kann natürlich auch daran liegen, dass keine sonst außer uns was gemacht hat :) ) Dann Pushen:
git push
100: Wenn Konflikte nach dem Merging entstanden sind, dann müssen diese manuelle behoben werden und dann wie üblich: add/commit/push
git add -A
git commit -m "FeatureXXX ist gemerget"
git push
110:END
Ich teste erfolgreich das Vorgehen schon seit 3 Wochen.
Hier noch ein gutes Tutorial für großere Teams:
http://nvie.com/posts/a-successful-git-branching-model/
Good luck
Mittwoch, 21. November 2012
JAR Dependencies auflösen
Ab und zu stehe ich vor der Versuchung einpaar schöne Bibliotheken in mein Projekt einzubinden.
Den Abhändigkeitsschwanz aufzulösen ist dabei eine richtige Herausforderung. Wenn das ein Maven Projekt wäre - dann hat man es gut. Wenn aber nicht?!
Heute war wieder so ein Versuchung. In einem überschaubaren Projekt wollte ich RESTEasy von JBoss für rest-ws verwenden. Wenn man allerdings über die Liste der mitgeschleppten Bibliotheken stolpert, 66 JARs samt 16MB, dann überlegt man drei mal.
Gut wenn man weißt das für den rest-ws Einsatz lediglich ein Paar von den JARs notwendig sind. Aber, wie kriegt man raus welche von den 66 tatsächlich erforderlich sind. Na gut, etwas Ahnung, dass z.B. JAX-RS das gesuchte Modul ist, müsste man schon haben.
Und die restliche JARs von denen das Modul abhängig ist, kriegt man mit einem kleinen Gradle Script herauskopiert:
und so wird der Script ausgeführt:
gradle -q copyJars
und was haben wir als Ergebnis? Es werden lediglich 13 JARs samt 2MB benötigt.
~
Finito
Den Abhändigkeitsschwanz aufzulösen ist dabei eine richtige Herausforderung. Wenn das ein Maven Projekt wäre - dann hat man es gut. Wenn aber nicht?!
Heute war wieder so ein Versuchung. In einem überschaubaren Projekt wollte ich RESTEasy von JBoss für rest-ws verwenden. Wenn man allerdings über die Liste der mitgeschleppten Bibliotheken stolpert, 66 JARs samt 16MB, dann überlegt man drei mal.
Gut wenn man weißt das für den rest-ws Einsatz lediglich ein Paar von den JARs notwendig sind. Aber, wie kriegt man raus welche von den 66 tatsächlich erforderlich sind. Na gut, etwas Ahnung, dass z.B. JAX-RS das gesuchte Modul ist, müsste man schon haben.
Und die restliche JARs von denen das Modul abhängig ist, kriegt man mit einem kleinen Gradle Script herauskopiert:
und so wird der Script ausgeführt:
gradle -q copyJars
und was haben wir als Ergebnis? Es werden lediglich 13 JARs samt 2MB benötigt.
~
Finito
Freitag, 16. November 2012
Auf HSQLDB über Tomcat zugreifen
Ziel
Ich wollte mir kleines Tomcat Projektchen mit HSQLDB zum Testen schnell einrichten. Da es letztendlich über zwei Stunden gedauert hat, und keine gute Anleitung im Netz zu finden war - schreibe ich Eine.
Umsetzung
Alles sehr simple. Mein Projekt trägt den stolzen Namen: Sausage
Schritt 1: context.xml und web.xml von dem Projekt anpassen:
~/Sausage/docroot/META-INF/context.xml
- -
~/Sausage/docroot/WEB-INF/web.xml
- -
Schritt 2:
Die hsqldb.jar ins ~/Sausage/docroot/WEB-INF/lib/ reinschmeißen. Und Sausage deployen.
Schritt 3:
Und hier der Java-Aufruf für den Datenzugriff:
- -
~
Finito
Ich wollte mir kleines Tomcat Projektchen mit HSQLDB zum Testen schnell einrichten. Da es letztendlich über zwei Stunden gedauert hat, und keine gute Anleitung im Netz zu finden war - schreibe ich Eine.
Umsetzung
Alles sehr simple. Mein Projekt trägt den stolzen Namen: Sausage
Schritt 1: context.xml und web.xml von dem Projekt anpassen:
~/Sausage/docroot/META-INF/context.xml
- -
~/Sausage/docroot/WEB-INF/web.xml
- -
Schritt 2:
Die hsqldb.jar ins ~/Sausage/docroot/WEB-INF/lib/ reinschmeißen. Und Sausage deployen.
Schritt 3:
Und hier der Java-Aufruf für den Datenzugriff:
- -
~
Finito
Mittwoch, 13. Juni 2012
Liferay 6.1 : Logging
Nach dem ich viel-zu-viel Zeit investiert habe um das Geheimnis zu luften - wo bei Liferay das Logging konfiguriert wird - hier die Auflösung. Eigentlich ist das ganz einfach, wenn man es kennt. Im Verzeichnis tomcat-7.x.x/lib/ext/META-INF müssen hierfür zwei Dateien abgelegt werden.
portal-log4j-ext.xml zum Beispiel so:
portal-log4j-ext.xml zum Beispiel so:
Zusätzlich fragt Liferay nach DTD, dass im gleichen Verzeichnis abgelegt werden soll. Die Datei log4j.dtd ist im portal-impl.jar unter META-INF/ zu finden.
Die Dateien log4j.jar und log4j-extras.jar sollen aus dem tomcat-7.x.x/webapps/ROOT/WEB-INF/lib ins tomcat-7.x.x/lib/ext verschoben werden, damit alle Logger-Klassen mit gleichem (globalen) Classloader geladen werden.
Weiterhin, damit es funktioniert, muss man dem Liferay beibringen die log4j-Files beim Deployen von Portlets für sich zu behalten, also nicht in die Applikationen zu kopieren. Leider ist das nicht die default Einstellung.
Hierfür soll der altbekannte portal-ext.properties angepasst werden:
auto.deploy.copy.commons.logging=false
auto.deploy.copy.log4j=falseErledigt.
Und das beste daran ist, jetzt kann ich den LogLevel Live konfigurieren, und zwar über das Control-Panel -> Server -> Administration -> LogLevel
Note: Anpassungen, die über Control-Panel getätigt sind, werden nicht im Datenbank abgelegt, also nach dem Neustart des Servers hat man wieder den LogLevel aus portal-log4j-ext.xml
Abonnieren
Posts (Atom)


