again on ebay: bidding on a used IBM S/390 Mainframe

Flattr this!

During my break and therefore during some browsing on ebay (Germany), i found an interessting auction on ebay:

IBM S/390, Mainframe 9672 + RS 6000 570 + Multiplexer

If i had the money and the room to leave the biest (the description says something around 1 ton), i had no doubt and would bed on this thing.
I had the luck to take part on the “IBM Summer Seminar” at ouf University two summers ago. So i got some infos about that kind of system.
So i hope that someday there will be an offer on ebay and i will have the possibilies to take that opportunity.

cotodo lebt :-)

Flattr this!

Collaboration ToDo List. Klingt irgendwie schön nach web 2.0.
Also das einchecken in Subversion hat auch recht schmerzlos funktioniert. Noch mal vielen Dank Stefan für die Tipp.
Noch mal in aller Klarheit:

https://www.innoq.com/svn/Sandbox/<user>

Momentan sitze ich mal wieder über meiner UML Skizze und versuche eine Art Service Struktur für meine Persitenten Objekte zu erstellen. So langsam finde ich gefallen daran, vor allem merkt man nach einer Weile, dass die Vorschläge aus dem Buch “Pro EJB 3. Java Persistence API” – (aPress) von Mike Keith und Merrick Schincariol ziemlich sinnvoll sind.

(Amazon Link)

Letztendlich geht es jetzt darum, die Funktionalität, die ich haben möchte soweit zu kapseln, dass sie sich mit dem vorgeschlagenen Design abbilden lässt.
Ich denke ich werde eh noch genug eigene Wege einschlagen – irgendwie liegt mir das im Blut :-).
Ich habe sogar ein Beispiel gefunden, wie man relative einfach DB Update von einer Programmversion auf die nächste mit JPA berwerkstelligen kann (Das war ein Punkt in unserer letzten Diplomandenrunde).

WSC: our Team in Australia

Flattr this!

Here are some Links about our Solar car racing team that is currently taking part at the 20th world solar challenge from Darwin to Adlaide!
More infos about SolarWorld No1. The official Blog and the webblog of Ralf Zweering with some additional pictures.

And there is even a headline at heise.de!
I wish our team all the best. It is an incredible piece of technology. We are now at the 5th place!

Subversion – how to do?

Flattr this!

Ich wollte grad versuchen mein bisherigen Projekt auf den innoQ subversion server zu schieben. Allerdings hat es bisher noch nicht so funktioniert.
Weder
http://www.innoq.com/secure noch
https://www.innoq.com (nach dem wiki sollte das ja nach innoq.de weitergeleitet werden)
noch https://www.innoq.de/secure gingen.
Bei letzterem kam allerdings ein authentification error.
Vielleicht kann mir ja jemand einen Tipp geben.

erster Eintrag erstellt!

Flattr this!

Mittlerweile konnte ich jetzt auch schon den ersten Eintrag erstellen. Das ganze schaut noch recht umständlich aus, weil noch so gar keine Frontends existieren:

public String addEntry(){
    User recipient = (User)em.find(User.class, 3);
    Entry important = new Entry();
    Calendar cal = Calendar.getInstance();
    cal.set(2007, 12, 15);
    Date end = (Date) cal.getTime();
    important.setSender(user);
    important.setRecipient(recipient);
    important.setPriority(1);
    important.setStatus(10);
    important.setTitle("start with ADAM&EVA");
    important.setDeadLine(end);
    important.setSendDate(new Date());
    important.setContent("no text");
    em.getTransaction().begin();
    em.persist(important);
    em.getTransaction().commit();
    em.close();
    return important.toString();
}

Es gibt – natürlich – den Benutzer mit ID 3 (als Empfänger) schon und auch user ist als Attribut der Klasse schon gesetzt.
Letztendlich wird der Eintrag auch abgespeichert – wenn man so will die erste wirklich sinnvolle Funktion :-).
Mittlerweile habe ich mich dazu entschlossen gemäß MVC alle POJOs für JPA im Package de.hausswolff.diplom.M zu speichern und im Package de.hausswolff.diplom.C die Controller (in dem Buch hießen diese Serviceklassen, also für Klasse User aus dem M Package wäre es dann halt UserService. Die Ausgabe in Form von normalen Servletts werde ich dann komplett in einem V Package bündeln.
Was mich noch ein wenig beschäftigt ist, dass ich ja gerne nach dem REST Prinzip vorgehen möchte und also unter /user/3/inbox/5 den Eintrag von Benutzer mit der ID 3, den er erhalten hat (inbox) mit der ID 5 erhalten möchte. Ich nehme mal sehr stark an, dass es dafür eine Java Lib gibt. Habe aber auch noch nicht großartig gesucht. Ich werde – sobald ich die 3-Tabellen Lösung zum Laufen bekomme (siehe letzter Eintrag – war leider ein wenig spät/früh gestern/heute ^^) – mal anfangen die neue Package Struktur als UML zu erstellen.

JPA YEEHA!

Flattr this!

Besser später als nie, hier also dann mal – nach laaaanger Zeit mal wieder – mein aktueller Status.
Mittlerweile bin ich ein ganzes Stück weiter und so fange ich sogar an, dem ganzen System von Persistence etwas abgewinnen zu können. Einzig die Frage bleibt, wieso JPA per default partout alle Feldnamen als groß schreibt. Naja das wird sich sicherlich auch noch klären. Aber zuersteinmal der Reihe nach:
Das – anfängliche Problem, dass ich ja einen Integer Primary Key brauche, aber auch zum Beispiel auch ein User Objekt anhand eines Namens (der ja nach meiner Definition auch eindeutig sein soll) erstellen will, ergab sich die Zwickmühle, dass es ein System geben muss, welche einem quasi einfache SQL Searches erlaubt… gibt es auch.
Anhand einer Präsentation, von Phillip fand sich dann auch eine recht kurze (und demnach schmerzlose) Lösung:

@Entity
@Table(name = "Users")
@NamedQuery(name = "findWithName", 
    query = "SELECT u FROM User u WHERE u.name = :Name")
public class User {
    ...
}

Das sagt der Klasse, dass sie, wenn ich eine Query namens (“findWithName”) ausführe, das nachfolgende SQL Statement benutzen soll und demnach auch den Parameter ‘Name’
Der Aufruf schaut dann so aus:

User user = (User) em.createNamedQuery("findWithName")
            .setParameter("Name", "TestUser").getSingleResult();

Nunja ein schöner, langer Aufruf. Aber immerhin wird mir ein User Objekt erstellt, wenn ein User mit Namen ‘TestUser’ existiert!
Kommen wir zum nächsten Punkt – mein Lieblingspunkt an diesem Morgen, weil das mich ziemlich viel Zeit und Schweizß gekostet hat (obwohls doch eigentlich so einfach ist) – die Kardinalitäten – ODER AUCH -” wie papern, wer n Eintrag an’nen User?”
Ich bin in mich gegangen und kam mit der Entscheidung aus mir (sagt man das so?), dass ich für jeden Eintrag, der von User A nach User B geschickt wird, ein Eintrag in der Datenbank erstellt wird. Also selbst, wenn User A an B und C die gleiche Aufgabe verteilen würde, würden zwei Einträge erstellt. Ich weiß, dass es dann recht unmöglich ist, zum Beispiel zwei User für eine Aufgabe vorzusehen und diese Aufgabe dann bei User B erledigt ist und bei User C noch offen – letztendlich ging es mir auch ersteinmal darum, die Abhängigkeiten hin zu bekommen.
Also erstmal die Veriante mit Stützrädern (zwei Tabellen) und dann hinterher (so morgen) schau ich mal, ob ich das auch freihändig schaffe (so drei Tabellen).
Letztendlich schaut das mit JPA ähnlich aus wie bei Willem und seinen RoR (gabs da nich mal n Lied mit RoR, RoR, RoR the Boat? aber ich glaube das war Row… egal).
Also vielleicht zuerst einmal die beiden Klassen und wie diese zusammenhängen:

Ja die Attribute laden quasi dazu ein, auf eine 3. Tabelle auszulagern ;-).
Es gibt also zwischen User und Entry exact zwei 1-zu-N Beziehungen:
1. Hat ein User genau eine Inbox mit N erhaltenen Entries
2. Hat ein User genau eine Outbox mit N versandten Entries
Da Willem nich Ruhe geben wollte, habe ich die Tabellen gleich mal Pluralisiert (okay ist auch sonst ne ganz gute Idee) und die IDs _id getauft.
Für JPA geht man nun wie folgt vor:

...
public class User {
    ...
    @OneToMany(mappedBy = "recipient")
    private Collection inbox;
    @OneToMany(mappedBy = "sender")
    private Collection outbox;
    ...
}
...

sagt einem, dass jeweils die Attribute (eigentlich die Items aus den Collections) inbox und outbox an das Attribut (und hierbei geht es wohl wirklich um das Objekt ansich) “recipient”/ “sender” gemapped werden.
In der Klasse Entry muss dann natürlich quasi “das Kind konfiguriert werden” (das klingt jetzt seltsam aber im Moment fällt mir nix gescheiteres ein):

...
public class Entry {
    ...
    @ManyToOne()
    @JoinColumn(name="recipient_id")
    private User recipient;
    @ManyToOne()
    @JoinColumn(name="sender_id")
    private User sender;
        ...
    }
...

Na gemerkt? ManyToOne anstatt OneToMany….ach war klar? Na,… okay :-).
Nun werden halt nur noch schnell die Feldnamen aus der DB Table angegeben und besagte Objekte erstellt ( recipient/ sender ). Geht ja eigentlich ganz schnell…
Das Setten/Getten probiere ich dann mal morgen und dann auch gerne mit 1+1+1 = 3 Tabellen. Gibt einem ja dann doch ein wenig mehr Möglichkeiten.
Das EJB3 Buch ist übrigens gut. Man liest, schreibt, sucht dann noch nen anderes Beispiel und dann versteht man es erst ;-). Nach und nachen rücken aber erster und letzter Schritt immer näher zusammen.
Ich wünsche allen eine erfolgreiche Woche.

after 1.508,4 km: we are back in the rhine-ruhr area!

Flattr this!

After five thrilling days on the road, with amazing sunny weather, we made our way back home.
We met some new peoples. Always nice to know new faces and get new impressions.

The Tip of the Trip is Hohenheim where we slept one night a took part on one day of the welcome week for the new students at the university of Hohenheim.
Just for the record:

98.jpg
isn’t it great?

More picture in my Picture Gallery. If you want to browse them, just drop me a line or send me an email!

So thank you very much to all the nice friends, that gave us a place to sleep for one (or two) nights. You are welcome in here in my place if you need a place to rest for one night :-).