knallisworld

Where is the beef?

Der Laufplan für die Diplomarbeit

Okt 27

Gepostet von knalli in Actually irrelevant!, Diplomarbeit.. ftw! | 2 Kommentare

Ich hatte eben in den alten E-Mails gesucht, da ich mal “aufgeschrieben” hatte, was man alles für die Anmeldung [sic!] zur Diplomarbeit benötigt. Ich stelle den mal kommentarlos zur Verfügung.

Hallo zusammen,

wer gedacht hat, das Anmelden zur Diplomarbeit wäre bei der FH easy, der hat die Rechnung ohne das Prüfungsamt gemacht. Leider steht folgende Todo-Liste NICHT online, wohl aber findet man aber Formulare auf dieser Seite http://www.studium.fh-koeln.de/service/formulare/u/01256.php – wer also schon mal eine Diplomarbeit geschrieben hat, der weiß wie der Hase geht.. der Rest steht nur dumm da.

Erstens: Der Antrag auf Zulassung
Weil es ein Amt ist, gibt es keine “Anmeldung”, aber einen “Antrag auf Zulassung”. Klingt komisch, ist aber so. Den “Antrag auf Zulassung zur Diplomarbeit und Kolloquium…” muss in _zweifacher_ Ausfertigung abgegeben werden.. und nein, das war noch nicht alles..

Zweitens: BAFÖG
Für diejenigen, die BaFög erhalten haben, müssen das zugehörige Formblatt abholen. Diejenigen, die kein BaFög erhalten haben, müssen aber auch ein Formular ausfüllen.. nämlich um zu unterschreiben, das sie.. ui, richtig.. kein Bafög bekommen haben. Warum? Die besten 30 Absolventen müssen weniger zurückzahlen. Eigentlich ja keine schlechte Sache.

Drittens: Alle Guten Dinge sind drei – Externe Arbeiten
Sollte man außerhalb der FH eine Arbeit schreiben – was ja durchaus vorkommen wird – so benötigt man ebenfalls das Formblatt “Betreuerin/Betreuer der Diplomarbeit aus der Industrie/Wirtschaft”.. da bei ist es völlig egal, ob der externe Betreuer wirklich in Industrie/Wirtschaft sitzt, man könnte auch schreiben “nicht aus der FH Köln”. Richtig geraten, dieses Formblatt muss auch _zweifach_ ausgefertigt abgegeben werden.

Der aufmerksame Leser, der gut im Kopfrechnen ist, sollte im schlimmsten Fall auf fünf Formulare gekommen sein, die auszufüllen sind.

Viele Grüße aus Köln,
Jan

Jegliche Form von versteckter Ironie, Sarkasmus oder bösen Witzen sind rein zufällig. Wirklich.

Java auf dem Mac

Okt 24

Gepostet von knalli in Apple, Java | Keine Kommentare

Mit dem jüngsten Java-Update hat Apple angekündigt, dass ihre eigene Java-Version als “deprecated” markiert wurde und das nach dem üblichen Support-Lifecycle eine Java-Entwicklung eingstellt wird.

Oder, mit anderen Worten:

  • OS X 10.6 “Snow Leopard” ist die letzte OS X Version, die ein vor-installiertes Java (JVM+JDK) besitzt und innerhalb der üblichen Apple-Updates aktualisiert wird;
  • Apple hat mit dem jüngsten Update einige Änderungen in der internen Java-Framework-Architektur gemacht, damit parallele JVMs (und auch Nicht-Apple-JVMs) besser erkannt werden können und (einfacher) aktiviert werden können (ein nahe liegende Grund ist bspw. das Testen einer Developer-JVM, was bisher entweder gar nicht ging oder nur mit großem Aufwand);
  • Apple macht damit in Zukunft genau das gleiche wie Microsoft.

Viel FUD kommt aber in einigen (Java-)Entwickler- oder Apple/Mac-Communities (oder auch der offiziellen Java-Mailingliste von Apple) auf, da die Ankündigung wahlweise als Java-Verbannung, “Jobs hates Java” oder sonstiger streng objektiven Aussagen interpretiert wird.

Zunächst einmal bedeutet das Wort “deprecated” nur, das beim Release der Schnittstelle/des Frameworks die “deprecated” Komponente eben zu einem späteren Zeitpunkt hinfällig wird. Damit ist also nicht etwa eine “veraltete [Java] Technik” gemeint. Also, Apple sagt nur, das ihre eigene entwickelte JVM eingestellt wird. (Genau das steht auch in den Release Notes.)

Zusammengefasst kann man als Java-Mac-Entwickler derzeit nur sagen:

  • Schade, dass man sich auf lange Sicht in Zukunft nicht mehr auf der sicheren Seite bewegt, das eine JVM (und sogar JDK!) auf dem OSX-System vorhanden ist. Auch dort wird man also in einigen Monaten Hinweise auf das Vorhandensein von Java oder automatische Installationsangebote wiederfinden.
  • Schade, dass es kein Vendor-Java gibt. (Es gibt Vorteile).
  • Schön, denn die Releasezyklen sind bestenfalls so gut wie von Sun (Oracle), nie besser. Und aus der Vergangenheit wissen wir, dass OS X teilweise Wochen bis Monate (und im Falle von Java 6 sogar Jahre) auf neue Versionen warten musste. Das wäre bei Sun nicht passiert.
  • Schön, denn die interne Grundlage mit dem jüngsten Update sorgt dafür, dass OS X’ Java-Framework-Komponente erst wirklich Non-Apple-JVM-tauglich ist.

Wirklich schlimm wäre es nur, wenn sich entweder keiner für eine (offizielle) Weiterentwicklung zur Verfügung stellt oder die einzige Weiterentwicklung nur mit X11 funktioniert. Beides würde dann tatsächlich das Aus bedeuten. Diese beiden Alternativen halte ich jedoch für unwahrscheinlich.

Zum Thema auch folgender Beitrag. Man beachte die beiden Kommentare von Ottinger und Gosling.

Und auch der hier, mit dem guten Hinweis auf die Apple Extension, die natürlich “in Gefahr” sein könnte. Für diejenigen, die die überhaupt benötigen.

ClickToPlugin

Sep 19

Gepostet von knalli in Empfehlungen | Keine Kommentare

Seit ein paar Wochen nutze ich jetzt bereits die Safari Extension ClickToPlugin. Dabei handelt es sich um eine erweiterte Variante der Extension ClickToFlash des gleichen Entwicklers.

Während die Safari-Extension ClickToFlash nur auf das Blocken von Flash abzielt, geht ClickToPlugin weiter und blockiert auch andere Plugins (daher auch der Name): Silverlight, Java, usw. Es wäre richtig zu sagen: ClickToPlugin beinhaltet ClickToFlash.

Gemeinsam haben beide, dass sie ( vor allem bei Flash) reine Flash-Videoplayer versuchen zu erkennen und bei Erfolg in entsprechendes HTML5-Markup umwandelt.

Dabei konnte ich in den letzten Wochen bemerken, dass es erstaunlich viele Flash-Videoplayer gibt, die eigentlich nur H.264-Videoquellen abspielen. Daraus folgt glücklicherweise, dass der Browser weit aus weniger Flash laden muss (auch auf Anforderung = Click), denn die meisten Videos werden direkt als “HTML5 <video>” abgespielt.

Die Quintessenz: Ungeachtet der [mutmaßlichen] vielen “Nicht-HTML5-Ready”-Flash-Inhalten muss man jedoch anmerken, dass die Anzahl wohl tatsächlich weitaus geringer ausfallen würde, wenn entsprechende Weichen mehr eingebaut würden.

Buugle – das Bundes-Google

Sep 19

Gepostet von knalli in Wort zum Sonntag | Keine Kommentare

WPvideo 1.10

“Schöne” Alternative zu Google ;) Der Autor ist übrigens der Macher von “Du bist Terrorist!”.

via netzpolitik

Flash Player 10.1 64-Bit

Sep 16

Gepostet von knalli in Adobe | Keine Kommentare

Und es geht weiter mit den Kuriositäten des 15. Septembers. Nach einer technisch brillanten (keine Ironie!) Webseite von Microsoft, gibt es den nächsten Knaller: Adobe veröffentlicht 64-Bit Preview-Versionen des Flash Players. Und heute nicht nur für Linux, sondern auch für Windows und sogar OS X. Wow.

Klar, das ist erstmal nur eine Preview. Vielleicht meint Adobe damit auch ein Release Candidate.

Und klar ist auch, dass das im Endeffekt nur bedeutet, dass wir die Bugs und Probleme jetzt nicht nur 32- sondern auch 64-bittig bekommen. Aber hey!

Beauty Of The Web?

Sep 15

Gepostet von knalli in Aktuelles, Internet Explorer, Technologie/IT | Keine Kommentare

Nun ja, Microsoft stellt seinen neuen Internet Explorer 9 Beta vor. Und da man heutzutage nicht einfach mehr ein Produkt vorstellt, gibt es dazu gleich eine komplette eigene Seite. www.BeautyOfTheWeb.com

Wie gut der Browser jetzt ist, werden wir in den nächsten Tagen merken. Zu der Seite sei gesagt: Rein technisch scheint sie voll aufneuen Technologien zu setzen bzw. ohne Flash und Silverlight auszukommen. Die Seite ist schnell und auch ohne IE benutzbar. Im Gegensatz zu Apple haben sie es auch tunlichst vermieden, irgendwelche Browser künstlich auszuschließen, oder sollte ich etwas übersehen haben?

Mit Silverlight war es wohl schwieriger, mit Flash wohl unmöglich, noch mehr Performance rauszukitzeln. Schließlich soll der Browser IE9 ja zeigen, wie gut er ist. Also, keine Plugins, sondern pure HTML-Magie. Und CSS-Magie. Und Javascript-Magie.

Ein Schlag in Adobes Gesicht.

BP und Google

Sep 11

Gepostet von knalli in Google | Keine Kommentare

BP, Google und der Zürcher «Tages Anzeiger»

Ein Kommentar zu der Geschichte einiger Presseorgane, dass Google uns ja (in Suchergebnissen) nur manipulieren würde, dass es nur erkaufte Imagepolitur wäre, u.ä.

Lesenswert.

The dangers of Ext.getCmp

Sep 9

Gepostet von knalli in JavaScript | Keine Kommentare

Ext JS Screencast – The dangers of Ext.getCmp

Sehr schöner Screencast, der die ExtJS Utility-Methode Exr.getCmp näher beleuchtet. Es zielt vor allem den Component Lifecycle an, das Vermeiden von statischen IDs.

Sehr schönes Statement, kann ich nur unterstreichen:

Do not create a function soup application, or you will get into trouble.

Ach, itemId und ref werden als alternative Pattern for Exr.getCmp vorgestellt. Joa, auch wieder was gelernt.

Open is not Open is Open.

Sep 9

Gepostet von knalli in Android | Keine Kommentare

Android Is As Open As The Clenched Fist I’d Like To Punch The Carrier

But who cares whether it’s great or it’s crap — isn’t the point of “open” supposed to be that the consumer can choose what they want on their own devices? Instead, open is proving to mean that the carriers can choose what they want to do with Android.

In einer idealen Welt würde man den fiesen Kindern das Spielzeug aus der Hand nehmen und Google würde das nur noch unverändert lizenzieren. Wäre wesentlich mehr “open” für den Endkunden als heute.

via dfb

[Howto] Maven: Wie man eine ausführbare Jar in eine Java-Webanwendung (War) via Webstart integriert.

Sep 4

Gepostet von knalli in Allgemeines, Empfehlungen, Java, Technologie/IT, Tipps | 1 Kommentar

Die Situation

Es bestehen zwei lauffähige, fertige Projekte in Maven, welche beide auch vollwertige Artefakte bilden können.

Zum einen die Webanwendung — nennen wir sie hier mal webportal — mit einem WAR-Artefakt, etwa für einen Tomcat. Ob das Artefakt als Snapshot oder Release gemacht wird, ob es nur generiert oder auch in ein Repository deployt wird, ist hierbei nicht von weiterer Bedeutung.

Zum anderen die normale Clientanwendung — nennen wir sie doch einfach userclient — mit einem JAR-Artefakt. Wichtig ist natürlich, dass hier eine startfähige Main-Klasse vorhanden ist. Dies sollte jedoch der Regelfall sein, daher nur der formale Hinweis.

Zusammengefasst, und der Auftrag an dieses Howto ist also: Wie konfiguriert und erweitert man den Buildzyklus in welchem Projekt an welcher Stelle am geschicktesten, um auf einfachem Wege die JAR-Datei userclient in die Webanwendung webportal als Java Webstart zu integrieren. Dabei ist es hilfreich, wenn man via pom.xml (und natürlich der Macht der Properties) die Versionen spezifizieren kann. Der gesamte Prozess von auswählen, signieren und ausliefern soll dabei automatisch und ohne weiteres Eingreifen des Entwicklers geschehen können. Idealerweise sollte das ganze auch optional sein — dazu gibt es dann mehr unter “Optimierungen und Verbesserungen”.

Den Rest des Eintrags lesen. »

Tags: , , , ,