Das neue Konzept sieht vor, alles in miteinander verbundenen Blasen auf dem Bildschirm darzustellen. Dabei öffnet der Programmierer einen Quellcodeteil in einer Blase. Ausgehend von dieser können weiter Blasen geöffnet werden. Dort können z.B. die Implementierungen von Methoden der ersten Blase gezeigt werden. Damit besteht zwischen den zwei Blasen eine Beziehung, die auch visualisiert wird.

Wobei wir beim Thema währen. Bilder sagen schließlich mehr als tausend Worte. Das Entwicklerteam hinter der Idee hat ein Video online gestellt, in dem die Funktionsweise von Code Bubbles sehr schön gezeigt wird.

Wem nun das Wasser im Munde zusammenläuft und das neue Paradigma selber ausprobieren möchte, kann dies mit einer Beta von Code Bubbles für Eclipse tun. Laut Entwickler sollen die Code Bubbles mit jedem Eclipse-Projekt zusammenarbeiten. Weiterführende Informationen findet ihr auf den Projektseiten der Code Bubbles.

Ich finde diesen Ansatz durchaus interessant. Wie oft kämpf ich mich durch eine Vielzahl an Quellcodedateien, die auf diversen Tabs übereinander dargestellt werden. Da geht der Überblick
beim Browsen im Code oftmals schnell verloren. Weiterhin lenken Codefragemente, die nicht zur Problemlösung beitragen, aber durchaus Aufmerksamkeit bedürfen, oftmals vom eigentlichen Ziel der Arbeit ab. Mit Hilfe der Code Bubbles würden nur die Codeteile auf dem Bildschirm erscheinen, die auch aktuell relevant sind. Noch dazu mit einem visualisierten Pfad der Reise durch die Quellen und alles nebeneinander. Vorausgesetzt der Monitor ist groß genug

Leider habe ich kein Eclipse installiert und somit auch kein Projekt zur Hand, um die Betaversion der Code Bubbles ausprobieren zu können. Wie sieht das bei euch aus? Hat einer von Euch bereits Erfahrung sammeln können? Mich würde die Bedienbarkeit interessieren. Kann man sich an diese Art der Codebearbeitung schnell gewöhnen? Oder ist das absoluter Nonsens, der nur im Video primaprächtig aussieht?

Und genau da kommt das von Zack Rusin erstellte Git Cheat Sheet ins Spiel. Auf einer gut strukturierten Übersichtsseite, die locker als Desktophintergrund ihren Dienst verrichten kann, werden alle wichtigen Begrifflichkeiten, Konzepte und Befehle beim Umgang mit Git aufgezeigt. Ein hervorragendes Nachschlagewerk für den täglichen Gebrauch. Das Sheet steht als PNG und SVG zum Download bereit.

Danke an Kai für den Hinweis.

Mit dem SQL Server 2005 hat Microsoft die Datenbanksnapshots eingeführt. Ein Snapshot ist eine nur lesbare Kopie der Datenbank zum Zeitpunkt seiner Erstellung. Dieser Snapshot kann nun nach Änderungen an den Daten oder der Struktur der Datenbank genutzt werden, um den Ursprünglichen Zustand von Zeilen, Objekten oder der ganzen Datenbank wieder herzustellen. Oder einfach nur um zu gucken, was geändert wurde. Dabei könen pro Datenbank mehrere Snapshots angelegt werden.

Bevor wir nun Änderungen an unserer Datenbank vornehmen, muss ein Snapshot zum späteren Zurücknehmen der Änderungen erstellt werden. Einen Wizard dazu sucht man im SQL Server Management Studio vergebens. Hier ist etwas Handarbeit gefragt.

Als erstes benötigen wir den logischen Namen der Datenbankdatei. Dazu wird im Objektexplorer des Management Studios zu der gewünschten Datenbank gewechselt und von dieser die Eigenschaften per Kontextmenü aufgerufen. In dem Eigenschaftendialog wechseln wir auf die Seite Dateien und kopieren uns den logischen Namen der Datenbankdatei. Ebenfalls von Interesse ist der Speicherort im Dateisystem.

Mit beiden Informationen bewaffnet können wir uns nun in ein Abfragefenster begeben und mit folgendem T-SQL Befehl einen Datenbanksnapshot anlegen.

USE master;
GO
 
CREATE DATABASE AdventureWorks_DBSS_1330 ON
  ( NAME = AdventureWorks_Data, 
    FILENAME = 'C:\Program Files\Microsoft SQL Server\MSSQL10.MSLEARNING\MSSQL\Data\AdventureWorks_Data_DBSS_1330.ss' )
AS SNAPSHOT OF AdventureWorks;
GO

Danach steht uns der eben erstellte Snapshot als Abbild der Datenbank zur Verfügung. Der Snapshot verhält sich ähnlich einer normalen Datenbank im Objektexplorer und in T-SQL Skripten. So können wir die Daten direkt aus dem Snapshot per SELECT Statement abfragen und diese zum Vergleich der geänderten Daten oder zum Wiederherstellen einzelner Zeilen unserer eigentlichen Datenbank nutzen.

Ausgehend von unserem oben beschriebenen Szenario möchten wir aber nach umfangreichen Änderungen am Datenbestand und/oder der Datenstruktur die Datenbank auf den Zustand des Snapshots zurücksetzen. Das erledigt das folgende Skript:

USE master;
GO
 
RESTORE DATABASE AdventureWorks
FROM DATABASE_SNAPSHOT = 'AdventureWorks_DBSS_1330';

Datenbanksnapshots stellen eine sehr schnelle und einfache Möglichkeit dar sich Zustände von Datenbanken zu sichern. Darüberhinaus stehen diese Zustände für Abfragezwecke zur Verfügung. Als Krönung kann eine komplette Datenbank auf den Zustand eines Snapshots zurückgesetzt werden. Dabei ist zu beachten, dass das Zurücksetzen nur funktioniert, wenn nur ein einziger Snapshot vorhanden ist. Das liegt in der Datenspeicherung der Snapshots begründet.

Ein sehr schönes Feature wie ich finde, welches hervorragend für Entwickler und Supporter geeignet ist, die oft Datenbankänderungen schnell rückgängig machen müssen. Leider setzen Datenbanksnapshots einen SQL Server der Enterprise Klasse voraus. Was zumindest bei Entwicklern, dank der Developer Edition gegeben sein dürfte.

Auf der Twitter loves Open Source genannten Seite listet der Kurnachrichtendienst alle Projekte auf, an denen die Entwickler mitgearbeitet haben. In erster Linie sind dies einige Ruby GEMs wie simple_uuid, cache_money oder cassandra. Aber Twitter setzt nicht nur auf Ruby on Rails, sondern auch auf Tools, die in Scala, Java oder C/C++ geschrieben sind. Unter anderem findet man in der Liste auch eine Beteiligung an der Ruby Enterprise Edition samt Passenger. Diese Kombination setze ich übrigens erfolgreich auf meinem eigenen Server ein.

Es ist schön zu sehen, dass Unternehmen mit Open Source Großes leisten können. Und es ist umso erfreulicher zu sehen, dass einige der erfolgreichen Firmen der Community Teile ihrer Arbeit zurückgeben. Eine Win-win-Situation.

via

Diese Frage stellten sich auch die Entwickler von Engine Jard und haben kurzerhand eine neue Communityseite ins Leben gerufen, die Licht ins Dunkel bringen soll. Auf RailsPlugins.org sind bereits etliche Plugins mit entsprechenden Hinweise zur Lauffähigkeit auf Rails 3, Ruby 1.9, JRuby sowie zur Threadsicherheit gelistet. Jeder Entwickler kann seine eigenen oder seine genutzten Plugins auf der Plattform registrieren und die gemachten Erfahrungen zur Lauffähigkeit hinterlegen. Somit entsteht ein Nachschlagewerk für die Rails-Gemeinschaft.

Ein schönes und vor allem einfaches Projekt mit einem hohen Nutzwert, wie ich finde.

Was also tun? Die Instanz neu aufsetzen wäre eine Möglichkeit gewesen. Wichtige Daten sind dort nicht vorhanden, da ich die Instanz zum Entwickeln nutze. Aber es muss doch auch einen anderen Weg geben. Vergleichbares kann ja durchaus auch auf einem produktiven System passieren. Und ja – es gibt einen Weg seinem Benutzer wieder die sysadmin Rolle zu geben. Das Zauberworte hier heissen Einzelbenutzermodus und dedizierte Administratorverbindung.

Zur Wiederherstellung meiner Rechte benötige ich auf dem Rechner, auf dem der SQL Server läuft einen Zugang mit Administratorrechten. Ohne die habe ich keine Möglichkeit gefunden. Zuerst beende ich den Dienst der betroffenen Instanz und starte ihn danach im Einzelbenutzermodus. Das ganze geschieht von einer Eingabeaufforderung mit Administratorrechten aus.

net stop MSSQL$INSTANZNAME
cd C:\Program Files\Microsoft SQL Server\MSSQL10.INSTANZNAME\MSSQL\Binn>
sqlservr.exe -m -s INSTANZNAME

Der letzte Befehl gibt mir einige Statusmeldungen der SQL Server Instanz in der Konsole aus. Diese darf nicht geschlossen werden, da sonst der Serverprozess beendet wird. Also benötige ich für die Verbindung zum SQL Server eine zweite Eingabeaufforderung mit Administratorrechten. Von der aus verbinde ich mich mit der im Einzelbenutzermodus laufenden Instanz über eine dedizierte Administratorverbindung.

sqlcmd -A -S SQLSERVER\MSLEARNING

Über diese Verbindung habe ich administrativen Zugriff auf die SQL Server Instanz und kann per T-SQL meinem Benutzer wieder die Rolle sysadmin zuweisen.

EXEC master..SP_ADDSRVROLEMEMBER @loginame = N'DOMAINE\benutzer', @rolename = N'sysadmin'
GO
quit

Danach kann ich die beiden Eingabeaufforderungen schliessen, den SQL Server Dienst ganz normal starten und mich wieder über administrative Rechte mit meiner Benutzerkennung freuen.

Ich finde den Weg durchaus gangbar und vor allem schneller und schmerzfreier als eine Neuinstallation. Wenn ihr einen noch einfacheren Weg kennt, dann rein damit in die Kommentare. Die eingesparte Zeit kann schließlich jeder gut gebrauchen

Wer bereits jetzt einen Blick auf die kommende Version werfen möchte, kann sich ab sofort über die erste offizielle Beta von Ruby on Rails 3.0 freuen. Diese kann bequem per GEM installiert werden.

gem install tzinfo builder memcache-client rack rack-test rack-mount erubis mail text-format thor bundler i18n
gem install rails --pre

Aber Vorsicht: Laut Ankündigung im Rails Weblog hat RubyGems derzeit Probleme stabile und Vorabversionen von Rails auf dem gleichen System laufen zu lassen. Es empfiehlt sich also die Installation in einer virtuellen Maschine.

Mit der Beta Version können dann neue Webanwendungen erstellt oder alte auf Rails 3.0 portiert werden. Gefundene Fehler möchten die Entwickler gerne gemeldet bekommen, damit sie bis zur finalen Version von Rails 3.0 noch ausgebügelt werden können. Welche Neuerungen es nun im Detail gibt, verraten die offiziellen Release Notes.

Ich werde in den nächsten Tagen Rails 3.0 zumindest antesten. Produktive Webanwendungen bleiben aber vorerst auf Rails 2.3.5. Auch wenn ein Screencast von PeepCode zeigt, wie man seine Anwendung innerhalb von 25 Minuten auf Rails 3 aktualisieren kann.

Wer ist mutiger als ich? Wer wagt den Sprung ins kalte Wasser und wechselt bereits jetzt zu Rails 3.0?

Cubeon nutzt zur Kommunikation mit dem Trac-System XML-RPC. Damit Trac die Anfragen auch ordnungsgemäß beantworten kann, muss eine aktuelle Version vom Trac XML-RPC Plugin installiert werden. Das erledigt man am schnellsten durch das Herunterladen eines vorgefertigten PythonEggs und anschließendes Kopieren in den Plugin-Ordner vom Trac-System. Auf den Cubeon Seiten zum Trac Repository Connector finden sich Downloads für Python 2.5 und 2.6 Eggs. Einfacher geht es nicht mehr.

Als nächstes muss das Plugin in die NetBeans IDE installiert werden. Da die letzte öffentliche Version 1.0.3.6 einige Probleme mit aktuellen Trac-Versionen hat, muss man sich den letzten Entwicklungsstand installieren. Dazu lädt man sich das cubeon-dev-23-12.zip oder ein neueres von der Cubeon Projektseite herunter und entpackt die ZIP-Datei. Die enthaltenen NetBeans Plugins können danach in der IDE über Tools -> Plugins -> Downloaded installiert werden. Ein anschließender Neustart tut gut, ist aber nicht zwingend notwendig.

Als nächstes kann die Verbindung zum Trac hergestellt werden. Dazu öffnet man über Window -> Cubeon -> Task Repositories ein Fenster zur Verwaltung von Repositories. Dort angelangt kann über das Kontextmenü ein neues Task Repository registriert werden. Der Assisten fragt dabei alle wichtigen Information wie Typ, Alias, Host URL und die Login-Daten ab. Danach erscheint das Repository in der Liste der registrierten.

Aber damit allein sieht man noch keine Tickets. Dazu müssen Abfragen, analog zu denen aus dem Trac Webinterface, erstellt werden. Über das Kontextmenü zu einem Repository können neue Abragen angelegt werden. In dem Bearbeitungsfenster fragT das Plugin nach einem Namen für die Abfrage sowie den Filterkriterien. Dort stehen alle Filter aus der Trac Umgebung wie Status der Tickets, Meilensteine, Komponenten oder Typen zur Auswahl. Nach dem Speichern der Abfrage startet NetBeans die Synchronisierung und lädt alle zur Abfrage passenden Tickets herunter.

Tickets können dann direkt in der IDE bearbeitet und neue angelegt werden. Sämtliche Änderungen werden vorerst lokal durchgeführt und erst auf Wunsch mit dem Trac System abgeglichen. Das erlaubt die Arbeit auch ohne aktive Internetverbindung. Ein super Feature, wie ich finde.

Wer mit NetBeans und Trac arbeitet sollte sich das Plugin auf alle Fälle einmal ansehen. Der erste Eindruck ist schon recht gut. In den nächsten Tagen und Wochen wird sich die Praxistauglichkeit zeigen. Einzig die Verbindung zu einem HTTPS-Host mit einem privaten Zertifikat wollte nicht klappen. Vielleicht hat dazu jemand einen Tip für mich?

Das erste Webinar lautet “How to contribute to the Linux Community” und wird vom Kernel-Entwickler Jon Corbet gehalten. Wer am Webinar teilnehmen möchte, muss sich auf den Seiten der Linux Foundation dazu anmelden. Einmal registriert, wird man über künftige Webinare informiert. Und die Liste der bisher geplanten Vorträge ist beachtlich:

• “How to Work with the Linux community” von Jon Corbet
• “An Introduction to Git” von James Bottomley
• “Linux System Troubleshooting and Tuning” von Joe “Zonker” Brockmeier
• “Linux Administration 101” von Joe “Zonker” Brockmeier
• “A Linux Filesystem Overview” von Christoph Hellwig
• “Linux Virtualized Storage” von Christoph Hellwig
• “Btrfs: An Intro and Update” von Chris Mason
• “Linux Performance Tuning” von Ted Ts’o

Meine Registrierung ist unterwegs. Einige der Themen sind wirklich interessant für mich.

via

Der openSUSE Buildserver ist schon seit geraumer Zeit im Netz verfügbar. Jedoch habe ich bisher noch keine nähere Bekanntschaft mit der Buildumgebung gemacht. Bis heute. Endlich habe ich es geschafft für die nächste QSvn-Version den Bau von RPM-Paketen vorzubereiten.

Der openSUSE Buildservice organisiert seine Builds in Projekten und Paketen. Dabei kann jedes Projekt mehrere Pakete beinhalten. Jedes Paket baut ein RPM. Soweit die einfachste Struktur. Da das openSUSE Projekt den Buildservice auch zum Erstellen der eigenen Distribution nutzt, gibt es eine sehr große und ordentlich sortierte Liste öffentlicher Projekte.

Um eigene Pakete bauen lassen zu können, benötigt man als erstes einen Novell Login. Mit diesem kann man sich dann am Buildservice anmelden. Nach der Anmeldung hat man Zugriff auf das eigene Homeprojekt. In diesem kann man nun nach Belieben weitere Unterprojekte anlegen und Pakete hinzufügen.

Für die Entwicklung der nächsten QSvn-Version habe ich mir als erstes ein Development Projekt samt qsvn-Paket angelegt. Als nächstes musste ich die aktuellen Quellen als -src.tar.gz Paket hochladen. Anschließend braucht der Buildserver noch eine .spec Datei mit Angaben zum RPM-Paket. Wie so eine spec-Datei auszusehen hat, kann man in den SUSE Package Conventions nachlesen.

Nachdem die Quellen und das spec-File hochgeladen sind, bleibt nur noch die gewünschten Build Repositories für die verschiedenen Distributionen zum Projekt hinzuzufügen. Dabei stehen derzeit mehrere Versionen von SUSE, Fedora, Red Hat, CentOS und Mandriva zur Auswahl. Sind die gewünschten Repositories hinzugefügt, werden die Builds in eine riesige Warteliste eingefügt und sobald möglich gebaut.

Zum Bauen der einzelnen Pakete startet der Buildservice jeweils eine sauber, mit XEN virtualisierte Distribution. Danach werden die benötigten Pakete installiert und der Compilier- und Packvorgang gestartet. Somit ist sichergestellt, dass jedes Paket in einer sauberen Umgebung erstellt wird. Ohne Störeinflüsse von dritten ausgesetzt zu sein. Perfekt.

Die erstellten Pakete landen nach erfolgreichem Bauen in Paketrepositories und können von dort über die Softwaresuche ganz bequem auf den Rechnern der Anwender installiert werden. Und wer weiß, vielleicht landet somit das eigene Programm irgendwann in einer der offiziellen Distribution.

Ich finde den frei verfügbaren Service, den Novell dort aufgebaut hat, hervorragend. Zum Einen bringt es enorme Vorteile und Erleichterungen für den einzelnen Entwickler und zum Anderen haben Anwender eine zentrale Anlaufstelle zum Installieren von Software. Übrigens kann der Buildservice auch DEB-Pakete für Debian und xUbuntu erstellen.