Quellen:
Ich lese gerade http://blog.koehntopp.de/archives/2643-Ein-paar-Gedanken-zu-Foreign-Key-Constraints.html und bin über zwei Absätze gestolpert:
Technisch ist das eigentlich kein Problem, denn da dies alles in einer Transaktion geschieht tauchen beide Werte gleichzeitig erst zum COMMIT in der Datenbank auf, aber die Prüfung erfolgt leider per Statement und nicht per Transaktion. Ich muß also Entwickler als meinen Code passend strukturieren, egal ob das der Anwendungslogik gerecht wird oder nicht.
und
In MySQL ist die Nutzung von FK-Constraints überhaupt nur sinnvoll möglich, wenn die InnoDB Storage Engine verwendet wird. In MyISAM wird die Syntax für Constraint Definitionen zwar geparsed, dann aber nicht beachtet.
Fällt für mich eindeutig in die Rubrik: Good to know.
Nun, ich hab das Plugin in meinem Eclipse gefunden und benutzt. Funktioniert prima. Gibt sogar nen Export, damit man das über einen Ant-Task aufrufen kann. Sieht dann ungefähr so aus:
<?xml version="1.0"?>
<project name="FatJar MySuperDuperClass.jar (experimental)" default="main" basedir=".">
<!-- this file was created by Fat-Jar Eclipse Plug-in -->
<!-- the ANT-Export is in a very early stage, so this -->
<!-- is only experimental, ANT 1.6 or above is -->
<!-- required, feedback is always welcome: -->
<!-- http://sourceforge.net/projects/fjep -->
<!-- uncomment the following lines if using ANT outside Eclipse -->
<!--
<property name="fjepPath" value="plugins/net.sf.fjep.fatjar_0.0.31/fatjar.jar"/>
<taskdef name="fatjar.build" classname="net.sf.fjep.anttask.FJBuildTask" classpath="${fjepPath}"/>
<typedef name="fatjar.manifest" classname="net.sf.fjep.anttask.FJManifestType" classpath="${fjepPath}"/>
<typedef name="fatjar.exclude" classname="net.sf.fjep.anttask.FJExcludeType" classpath="${fjepPath}"/>
<typedef name="fatjar.jarsource" classname="net.sf.fjep.anttask.FJJarSourceType" classpath="${fjepPath}"/>
<typedef name="fatjar.filesource" classname="net.sf.fjep.anttask.FJFileSourceType" classpath="${fjepPath}"/>
-->
<!-- uncomment the above lines to use ANT outside of Eclipse -->
<target name="main">
<fatjar.build output="MySuperDuperClass.jar">
<fatjar.manifest mainclass="de.schwobeseggl.test.MySuperDuperClass"/>
<fatjar.filesource path="bin" relpath=""/>
<fatjar.jarsource file="lib/commons-cli.jar" relpath=""/>
<fatjar.jarsource file="lib/jbossall-client.jar" relpath=""/>
<fatjar.jarsource file="lib/junit.jar" relpath=""/>
<fatjar.jarsource file="lib/log4j.jar" relpath=""/>
<fatjar.jarsource file="lib/jdom.jar" relpath=""/>
</fatjar.build>
</target>
</project>
Schön und gut, das geht aber nur innerhalb von Eclipse. Auch wenn man obigen Hinweis folgt und die Zeilen einkommentiert, klappt es nicht, es kommt die Fehlermeldung:
BUILD FAILED /my/path/MySuperDuperClass/build.xml:42: fatjar.build doesn't support the nested "fatjar.filesource" element.
Doof. Die Lösung ist relativ einfach, aber erst nach langer Suche hab ich sie gefunden: Einfach ein loaderref=“${fjepPath}“ in jedes typedef rein. Somit wird aus:
<typedef name="fatjar.manifest" classname="net.sf.fjep.anttask.FJManifestType" classpath="${fjepPath}"/>
ein
<typedef name="fatjar.manifest" classname="net.sf.fjep.anttask.FJManifestType" classpath="${fjepPath}" loaderref="${fjepPath}" />
Ich hab des Öfteren Probleme mit Dateianhängen von E-Mails, wenn ich diese per Thunderbird abrufe. Meist fehlen an der Datei ein paar Bytes, so das diese „kaputt“ ist. Wenn ich allerdings über die Weboberfläche des Exchange meine Anhänge runterlade, dann sind diese in Ordnung. Liegt also an Thunderbird*. Oder so. In jedem Fall gibt es eine Lösung:
Quelle: http://gregs-obligatory-blog.blogspot.com/2007/12/thunderbird-exchange-imap-workaround.html
* Thunderbird macht es wohl richtig, d.h. RFC-konform, nur der liebe Herr Exchange meint es halt gut mit den Leuten: https://bugzilla.mozilla.org/show_bug.cgi?id=92111
Wieder was gelernt. Arrays kann man ja wie folgt initialisieren:
String[] allowed = new String[] {"text/html", "text/json"};Aber was ist mit Maps?
public class Router { public static final Map<String, Handler> routes; static { Map<String, Handler> map = new HashMap<String, Handler>(); map.put("/account", new AccountHandler()); map.put("/feed", new FeedHandler()); map.put("/opml", new OpmlHandler()); routes = Collections.unmodifiableMap(map); } }Find ich gut. Endlich weiß ich sowas auch. Noch schneller gehts mit:
public static final Map<String , Handler> routes = new HashMap<String , Handler>() {{ put("/account", new AccountHandler()); put("/feed", new FeedHandler()); put("/opml", new OpmlHandler()); }};
Die Klasse java.util.Calendar ist scheiße mächtig. Gerade beschäftige ich mich wieder ein bißchen damit und bin auf folgendes gestoßen
Was ist der Unterschied? Letztendlich machen beide etwas Ähnliches, nämlich das Erhöhen/Erniedrigen eines Datums um einen Wert. Bei roll() werden nur die „größeren“ Einheiten so gelassen wie sie sind. D.h. (laut API) das beim 31. August 1999 ein roll(Calendar.MONTH, 8 ) im 30. April 1999 endet (weil die Jahres-Einheit „größer“ ist als die Monats-Einheit). Der Tag wird nur deshalb verändert, weil der 31. April nicht existiert und so das Nächstbeste genommen wird.
Ein add(Calender.MONTH, 8 ) führt allerdings dazu, dass die nächst größere Einheit bei Bedarf angepasst wird, d.h. aus dem 31. August 1999 wird dann der 30. April 2000.
Ein Kollege merkt sich den Unterschied so: Wie beim Zahlenschloß. Das hilft nicht bei add(), aber bei roll() wird ja auch jeweils nur der eine Ring des Zahlenschloß weiterge“roll“t und der Rest bleibt unbeeinflußt.
Zusätzlich noch ein Hinweis: Calendar.MONTH ist null-basiert, d.h. geht von 0-11 und 2 ist der März. Ein Calendar.getInstance().getTime().toLocaleString() passt das allerdings „intern“ an und bei der Ausgabe ist dann der März wieder der 3. Monat des Jahres.
Damals™, als ich noch Student war, durfte ich mich mit dem Thema „Wie groß ist Windows“ im Rahmen einer Seminarbeit beschäftigen. Damals ging es nicht wirklich um die Inhalte, sondern eher um das Präsentieren. Nunja, inzwischen nimmt Windows 7 konkrete Formen an und ich vergleiche mal meine Prognose mit der Wirklichkeit.
Auf Seite 27 meiner Präsentation habe ich behauptet die Systemanforderungen wären:
Microsoft behauptet jetzt:
Naja. Zumindest beim Speicher lag ich einigermassen richtig. Ich bin aber auch sehr froh das es nicht so gekommen ist, wie ich prognostiziert habe. Deshalb schließe ich mit dem Zitat:
„Prognosen sind schwierig, besonders wenn sie die Zukunft betreffen.“
zugeschrieben Karl Valentin, Mark Twain, Winston Churchill u.a.
Ich beschäftige mich gerade mit EJBs. Und damit ich das alles verstehe, blog ich halt immer wieder bissle was 🙂
Was ist eigentlich eine EJB? Ich mach es mir einfach und übersetz einfach den passenden Teil aus der JSR 318 Abschnitt 2.3.1 Characteristics of Enterprise Beans
Die wesentlichen Teile einer Enterprise-Beans sind:
Dies ist eigentlich alles selbstverständlich und logisch, aber man muss ja mal klein anfangen 🙂
Was ein Spass bei LaTeX. Automatisch werden Inhalts-, Literatur und Abbildungsverzeichnisse durch folgendes erstellt:
\tableofcontents{}
\bibliography{thebibliography.bib}
\listoffigures
Somit hätten wir ein nichtnummerierte Verzeichnisse. Mag manchen Leuten reichen. Mir nicht.
Und hier gleich die Lösung:
\documentclass[bibtotocnumbered,bibliography=totocnumbered,liststotocnumbered,listof=numbered]{scrreprt}
\begin{document}
\tableofcontents{}
\appendix
\chapter{Anhang}
\section{Abkürzungsverzeichnis}
\begin{acronym}
\acro{XML}{Extensible Markup Language}
%usw.
\end{acronym}
\newpage
\begingroup
\let\chapter=\section
\let\addchap=\addsec
\listoffigures
\endgroup
\end{document}
Die Dokumentenklasse übernimmt das Nummerieren (sowohl mit den alten als auch den neuen Klassenoptionen), der Anhang wird mit \appendix eingeleitet und dann muss man nur noch so tun, als ob ein chapter eine section wäre.
Als Endergebnis sieht man dann sowas hier:
