Donnerstag, 18. Juli 2013

Fotoalbum im Picasa publizieren und nicht im G+

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

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à 




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

~

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 "F
eatureXXX 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 

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 

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:
Die Kategorie sowie Log-Level kann hier konfiguriert werden.
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=false
Erledigt.

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