Design Patterns in the JDK

Definitely important and useful to know: http://www.javacodegeeks.com/2011/03/design-patterns-in-jdk.html

HTML5-Boilerplate

So Tobi, damit du es nicht vergisst:

• HTML5 Rocks: Jede Menge Beispiele...
• HTML5-Boilerplate: Ein HTML5-Pattern für Basics...

ServiceLoader für einfache Plugins

Das dynamische nachträgliche Laden von Klassen mittels Javas Reflection ist ziemlich hacky. Der ServiceLoader nimmt einem da glücklicherweise Arbeit ab:

package serviceloader;
public class ServiceProcessor {
    public void printServiceImplementations(){
        ServiceLoader sl = ServiceLoader.load(Service.class);
        int cnt = 0;
        System.out.println("found Services:");
        for(Service s : sl){
            System.out.println("\t* "+s.getMessage());
            cnt++;
        }
        System.out.println(cnt+" Service(s) found");
    }
    
    public static void main(String[] args) {
        new ServiceProcessor().printServiceImplementations();
    }
} 

Dieses Beispiel lädt Klassen, die folgendes Interface implementieren:

package serviceloader;
public interface Service {
    String getMessage();
} 

Die Implementation könnte so aussehen:

package serviceloader;

public class ServiceImplementationOne implements Service{
    public String getMessage() {
        return this.getClass().getName();
    }
} 

Die Klassen, die dieses Interface wiederrum implementieren, müssen in einer Datei im Verzeichnis "META-INF/services/" eingetragen werden. Der Dateiname muss dem vollständig qualifizierenden Namen des Interface entsprechen, hier also "Service" (falls das Interface Bestandteil eines Packages ist entsprechend ".Service"). Darin befindet sich zeilenweise eingetragen die vollständigen Klassennamen:

serviceloader.ServiceImplementationOne # default Service
moreServices.ServiceImplementationTwo
moreServices.ServiceImplementationThree 

Liegt alles zusammen als Jar-Files in einem Ordner sollten der jvm über die Option "-classpath" die Position der Jar-Files mitgeteilt werden:

java -classpath moreservices.jar:serviceloader.jar serviceloader.ServiceProcessor 

Naja, und die Ausgabe sieht dann so aus:

found Services:
   * serviceloader.ServiceImplementationOne
   * moreservices.ServiceImplementationTwo
   * moreservices.ServiceImplementationThree
4 Service(s) found 

Ungünstig ist sicherlich, dass neue oder andere Klassen dem ServiceLoader nur über das Textfile im Jar mitgeteilt werden können. Noch flexibler sind die Plugin-Mechanismen von Netbeans oder Eclipse die dann auch Hot-Deployment und Überwachung bieten. Dafür sind diese Mechanismen aber auch ungleich komplexer. Für schnell mal ein bisschen Plugin-Fähigkeit-Gehäcke ist der ServiceLoader eigentlich eine angenehme schlanke Lösung.

Tobot@jabber.org

Der Chatbot ist wieder offline und war als Experiment zur Einarbeitung in Smack gedacht.

"Smack is an Open Source XMPP (Jabber) client library for instant messaging and presence. A pure Java library, it can be embedded into your applications to create anything from a full XMPP client to simple XMPP integrations such as sending notification messages and presence-enabling devices."

Jemand fragte mich auch nach dem Source-Code (tut mir leid, sehr hässlich ohne syntax-highlighting):

import org.jivesoftware.smack.*;
import org.jivesoftware.smack.packet.Message;

public class Smacko implements ChatManagerListener {
 public static void main(String[] args) throws XMPPException, IOException {
  new Smacko();
 }

 public Smacko() throws XMPPException, IOException {
  // open database with saved answers, names, etc.
  // Create the configuration for this new connection
  ConnectionConfiguration config = 
   new ConnectionConfiguration("jabber.org", 5222, "jabber.org");
  XMPPConnection connection = new XMPPConnection(config);
  connection.connect();
  SASLAuthentication.supportSASLMechanism("PLAIN", 0);
  connection.login("tobot", "nearly forgot to remove the password here");
  
  // prints all contacts
  // Roster roster = connection.getRoster();
  // Collection entries = roster.getEntries();
  
  System.out.println("\n\n" + entries.size() + " buddy(ies):");
  for(RosterEntry r:entries){
   System.out.println(r.getUser());
  }
  
  ChatManager chatmanager = connection.getChatManager();
  chatmanager.addChatListener(this);
  
  new Thread(){
   @Override 
   public void run() {
    while(true){
     try {
     Thread.sleep( 1000000 );
     System.out.print( "." );
     } catch ( InterruptedException e ) { e.printStackTrace(); }
    }
   }
  }.start();
 }
 
 @Override
 public void chatCreated(Chat chat, boolean arg1) {
  //System.out.println(chat.getParticipant());
  chat.addMessageListener(new MessageListener(){
   public void processMessage(Chat chat, Message message) {
       System.out.print(".");
          try {
     chat.sendMessage(answer(chat, message));
    } catch (XMPPException e) {
     System.out.println("Error Delivering block"+e.getMessage());
    }
      }
  });
 }
 
 public String answer(Chat chat, Message message){
  String text = message.getBody();
  if(text == null) return "Hi";
  // remove all regex-metachars and some 
  text = text.replaceAll("[\\[\\]\\(\\)\\{\\}\\|\\?\\+\\-\\*\\^\\$\\.!\"#%&',/:;<=>@_`~\\\\]", "");
  // restliche Antwortlogik
 }
 
}

Abkürzungsverzeichnis für Latex

Um in Latex ein Abkürzungsverzeichnis zu bekommen nutzen die meisten das nomencl-Package. Man definiert querbeet im Dokument die Abkürzungen z.B. wie folgt:

Massive Multiplayer Online Game (MMOG) \nomenclature{MMOG}{Massive Multiplayer Online Game}

Das Abkürzungsverzeichnis wird dann mit makeindex erstellt. Ich verliere dabei leider die Übersicht, welche Abkürzungen ich bereits definiert habe und müsste ständig nachschlagen.

Das acronym-Package gestaltet das schon ein wenig besser. Mittels:

\acro{acronym}{definition}

definiert man eine Abkürzung. Über:

\ac{acronym} oder alternativ auch \acl{acronym}, \acs{acronym}, \acf{acronym}

ruft man die Abkürzung wieder auf. Dabei sorgt das acronym-Package dafür, das der Begriff mindestens einmal lang ausgeschrieben wird mit der Nennung der Abkürzung.
Schön ist dann natürlich, das glossaries beides kombiniert und noch ein paar zusätzliche Optionen hat (u.a. kann man mehrere Verzeichnisse definieren, z.B. für Abkürzungen, Symbole, Definitionen, etc.). Da glossaries noch relativ neu ist musste ich das Paket manuell installieren (in MikTeX ist es wohl schon drin), z.B. wie folgt:

• glossaries.dts.zip auf ctan runterladen
• das ganze ins tex-Verzeichnis entpacken (für mich wäre das sudo unzip glossaries.dts.zip -d /usr/share/tex-mf)
• texhash ausführen

Für die Erstellung der Verzeichnisse kann man makeindex nutzen (makeindex -s [sourcefile].ist -t [sourcefile].glg -o [sourcefile].gls [sourcefile].glo), insbesondere bei mehreren Verzeichnissen ist die Nutzung des mitgelieferte perl-scripts makeglossaries komfortabler (perl makeglossaries [sourcefile]).

Scala Basics

Eine heise-Artikel bzgl. Grundlagen für Scala

GridCOMP

"Um Softwareentwicklern den Umgang mit der Komplexität des Grid zu erleichtern, hat das Projekt GridCOMP ein Framework entwickelt. Es verbirgt Detailstrukturen des Grid, etwa Hardware-Komponenten, Betriebssysteme, Zugangsbedingungen und Sicherheit sowie anderes mehr. Es regelt die Anpassungen, sodass sich der Programmierer darum nicht kümmern muss." von heise -- bestimmt interessant

Java - Logging Zukunft und EventBus

Ausblick auf die Logging-Zukunft und Einführung in den EventBus

Datenrettung mit Knoppix - heise Themen-Special

Jut, det merk'sch mir mal. Vll nochmal irgendwann nützlich:

Ein Themen-Special im Software-Verzeichnis zeigt [...]

Linux-Unix cheat sheets

Linux-Unix cheat sheets - The ultimate collection