ME & IT

Wachgeblieben!

Energiesparen ist IN. Und natürlich bietet OS X wie jedes andere moderne Betriebssystem auch reichlich Features um den Energie-Hunger von Desktop oder Laptop effektiv in den Griff zu kriegen. Es gibt allerdings einige Situationen, in denen es unerwünscht ist, wenn OS X sich mir nichts dir nichts schlafen legt, so zum Beispiel bei längeren Downloads oder aufwendigen Rechenprozessen.

Der sogenannte Standby-Modus lässt sich über die Systemeinstellungen selbstverständlich unterbinden, oft vergisst man jedoch diese Ausnahme-Einstellungen wieder zurückzudrehen.

Die bessere Lösung für mich ist ein Minitool namens Caffeine, das auf Wunsch automatisch beim Hochfahren von OS X startet und sich unauffällig als Kaffee-Tasse in die Menüleiste einnistet:

Ist die Tasse leer verhält sich der Mac wie gewohnt, füllt man sie hingegen durch einen schnellen Klick mit Kaffee auf schläft OS X von da ab nicht mehr ein. Ebenso schnell ist der Allzeit-Wach-Modus durch einen weiteren Klick wieder beendet.

Caffeine findet sich kostenlos im Mac App-Store oder auf den Seiten des Herstellers Lighthead.

XCode, iOS-Retina-Resourcen und das Problem mit Subversion

XCode tut sich manchmal etwas schwer mit Subversion. Man merkt eindeutig, dass GIT die von Apple favorisierte Versionsverwaltungs-Lösung ist. Viele Programmierer nutzen darum Subversion einfach über das Terminal statt aus XCode heraus. Probleme macht iOS-Programmieren oft dabei das Hinzufügen von Retina-Resourcen zu Subversion.

Ein Beispiel: Wir haben ein Bild namens MeinBild.png und die zugehörige Retina-Variante [email protected] . Das Kommando zum Hinzufügen der Retina-Version wäre

svn add [email protected]

Subversion wird jedoch durch das @ gestört. Für SVN signalisiert das letzte @ einer Zeile die Angabe einer Revision.

Die Lösung für dieses Problem ist bei Subversion-Kommandos einfach ein weiteres @ ans Ende des Dateinamens anzuhängen:

svn add [email protected]@

Die genannte Lösung ist detaillierter als hier auf StackOverflow diskutiert worden.

Falls SQLServer ReportingServices (SSRS) mal Leerzeichen verschluckt

Heute ist uns im Projekt aufgefallen, dass SSRS-Tabellenfelder und Textboxen gerne mal Leerzeichen verschlucken. Ärgerlich ist das bei fest formatierten Textbausteinen, wie sie bei Labeltexten häufiger auftreten. Das Problem liegt daran, dass Tabelleninhalte im Report als HTML gerendert werden. Darunter leiden Zeilenumbrüche zwar nicht, aber Spaces am Zeilenanfang oder Folgen von mehreren Spaces werden dabei einfach verschluckt.

Die Lösung ist es wie bei HTML üblich Non-Breaking-Spaces in den Report zu streuen. Diese kann man mit Tastencode ALT-0160 in Windows erzeugen.

Natürlich sind diese wieder alles andere als schön in der Datenbank mit den Labeltexten und unpraktisch beim Einpflegen der Texte.

Besser ist es also die Spaces im Report zu wandeln. Dies kann in der Expression der entsprechenden Control passieren mittels

=REPLACE(Feld.Value," ", " ")

Das zweite Space in der Expression wird dabei natürlich als ALT-0160 via Ziffernblock eingegeben.

Windows XP: 32 oder 64bit?

Heute stand die Installation von Eclipse auf einem Firmenlaptop an. Auf der Download-Seite galt es dabei direkt eine Entscheidung zu treffen: Will ich die 32 oder 64bit Version von Eclipse?

Das Betriebssystem des Rechners zu ermitteln ist ja noch trivial, wie aber erkennt man bei Windows XP welche Variante man fährt? Die nötigen Antworten liefert der Systemeinstellungs-Dialog (auch wenn das auf den ersten Blick nicht so scheint):

 

Findet sich hier unter System: kein Hinweis auf 64bit (a la "Windows XP Professional x64") handelt es sich noch um die 32bit Variante des Betriebssystems.

 

BBEdit Killerfeature: Copy as Styled HTML

Ich gebe es zu: Eigentlich habe ich BBEdit nur aus purer Neugier und wegen des stark reduzierten Preises gekauft. Ich hatte im Vorfeld schon viel Gutes über den Editor gehört, hatte die kostenfreie Lite-Variante Textwrangler schon lange im Einsatz, und wollte nun einfach mal spielerisch entdecken, was alles mit der Hilti unter den Programmier-Editoren möglich ist.

Eines der Features das ich dabei entdeckt und sofort favorisiert habe ist die Möglichkeit, Quellcode in der Art und Weise wie ich ihn optisch in BBEdit aufbereitet habe als HTML zu kopieren. Das ist wie geschaffen für Code-Passagen, die ich in meinem Blog zeigen will. Hier einmal ein Beispiel, dass ich unüberarbeitet eingefügt habe:

- (void) viewWillAppear:(BOOL)animated {
    self.searchlabel.text = self.searchterm;
    self.xmltextview.text = @"";
    [super viewWillAppear:animated];
}

Da BBEdit eine ganze Menge an Programmiersprachen und Markup-Typen erkennt, ist das eine ziemlich praktische Sache für mich. Ich bin ja mal gespannt, was ich noch so alles über die Zeit entdecke.

Ein Hinweis noch: Der Kauf über die Webseite scheint mir in diesem Fall eine bessere Wahl als der Kauf via AppStore zu sein: BBEdit hat in der Mac AppStore Variante nicht alle externen Tools mit an Bord und man muss sie so umständlich Nachinstallieren. Außerdem erhält man auf der Webseite bereits die Version 10, die aber im Mac AppStore noch nachgeliefert wird (hier ist derzeit noch Version 9.6.3 eingestellt).

MS SQL Server Datetime mal ganz zeitlos

Nach mehreren anderen Varianten habe ich heute endlich die vermutlich performanteste Routine zum Entfernen des Uhrzeit-Anteils aus einem MS SQL Server Datetime Ausdruck gefunden:

    select DATEADD(dd,0,datediff(dd,0,GETDATE()))

Der Trick dabei ist, dass SQL Server die Zahl 0 als ein fixes Bezugsdatum interpretiert. Das Beispielstatement

    select DATEADD(dd,0,0)

zeigt uns das interne Tag Null Referenzdatum 1. Januar 1900.

Die Datediff-Differenz zwischen diesem und dem aktuellen Datum sagt uns wieviele Tage seit dem 1. Januar 1990 vergangen sind. Addiert auf das Bezugsdatum 0 ergibt sich somit wieder das heutige Datum -- nur halt ohne Zeit.

Da nur Integer-Operationen genutzt werden statt komplexerer Umwandlungen ist diese Routine viel schneller als String-Format-Umwandlungen wie beispielsweise

    select convert(datetime,convert(varchar(8),GETDATE(),112))

Es bietet sich an unsere Rechenroutine als Funktion anzulegen:

    CREATE function [dbo].[getDateWithoutTime] (@mydate datetime)
    returns datetime
    as
    begin
        return DATEADD(dd,0,datediff(dd,0,@mydate))
    end

 

Image Cache Probleme von XCode 4 in den Griff kriegen

Gestern hatte ich schon darüber berichtet, dass XCode 4 und sein integrierter Interface-Builder manchmal Probleme mit dem Anzeigen von Images in der IDE haben. Das Problem war temporär durch Verschieben oder Umbenennen des Projektverzeichnisses zu lösen, so daß ich fehlerhafte Cache-Strukturen vermutet.

Heute habe ich herausgekriegt wie das Problem entsteht und wie man es lösen kann. Zunächst einmal liegt es weder an korrupten Projektdateien noch an einem ausstehenden CLEAN auf das Projekt oder Target. Das ist sicher schon mal beruhigend: Es ist nichts kaputtgegangen.

Den wahren Übeltäter habe ich gefunden als ich in die Xcode Preferences geschaut und dort das Locations-Menü inspiziert habe. Hier gibt es Einträge für "derived data", also "abgeleitete Daten" wie Builds, Logs und Indexes.

Und diese "Derived-Data"-Ordnerstrukur ist die Problemquelle. Hier werden Resourcen, die im XCode-Quellverzeichnis liegen, für die IDE in gewandelter Form temporär gecached. Der Interface-Builder zieht in der IDE seine Images aus diesem Ordner, nicht direkt aus dem Quellverzeichnis.

Manchmal wenn man nun Bilddateien verschiebt oder neu in XCode in Gruppen anordnet verliert XCode den Zusammenhang zwischen Cache und Quelle. Genau das ist der Zeitpunkt ab dem Bilder im Interface-Builder nicht mehr angezeigt werden.

Ein CLEAN löst das Problem nicht da es nur die Compiler-Caches leert.

Ein Kopieren des Projekts in einen neuen Ordner legt auch einen neuen Derived-Data-Ordner an. Jedoch bleibt auch der alte Derived-Data-Ordner bestehen, so daß beim Zurückkopieren in den alten Originalordner das Problem wieder auftaucht.

Mit dem Organizer kann man die Derived-Data-Ordner einer Anwendung anzeigen:

Und exakt hier kann man diese Caches auch gefahrlos löschen. Danach sind alle Probleme mit dem Interfacebuilder beseitigt und die Bilder werden wieder korrekt angezeigt. Alternativ können die zugehörigen Ordner auch mittels Finder oder Terminal aus den angegebenen Pfaden gelöscht werden.

 

Falls InterfaceBuilder mal Images verschluckt

Sollte XCode mal Eure Images nicht mehr anzeigen in NIBs (obwohl sie im laufenden Programm oder im Simulator normal zu sehen sind):

• Einfach Xcode schliessen,
• den Projekt-Ordner auf den Desktop kopieren,
• das Projekt aus dem kopierten Ordner öffnen.

Mysteriöserweise funktionieren die NIBs dann auch im Interfacebuilder wieder.

Das ganze scheint mir ein internes Caching-Problem des Interfacebuilders zu sein, und das egal ob in Version 3 oder 4. Ich denke das Problem tritt verstärkt dann auf wenn man das Projekt auf mehreren Rechnern in verschiedenen Ordnern bearbeitet und zwischen den beiden Maschinen ab und an hin- und herkopiert.

Das große UITextView-Rätsel

Eben durfte ich bei meiner Cocoa-Einarbeitung das große UITextView-Rätsel lösen.

Die Fragestellung dabei: Wie setzt man den Font einer UITextView-Control via InterfaceBuilder?

Hintergrund des Problems: Jedes andere Control-Element zeigt ein Fontfeld im Inspector. Der UITextView nicht. Klar ginge es programmatisch, aber das wäre ja geschummelt. Es sollte schon beim interaktivem Editieren des Nibs möglich sein.

Die Lösung ist so einfach, dass man kaum darauf kommen kann: Man betätigt einfach CMD-T sobald das TextView-Element selektiert ist. So wie fast überall in OSX.

Warum aber ausgerechnet diese Control das Font-Attribut nicht auch im Inspector anbietet bleibt weiterhin ein Rätsel.

Mehr und mehr Safari Extensions

Firefox ist zwar wegen der vielfältigen Extensions immer noch mein Hauptbrowser, aber ein Blick in die Safari-Erweiterungsgalerie zeigte mir gestern, dass auch hier eine Menge an Browser-Zusatzmodulen entstehen.

Zwei davon haben mir es besonders angetan: Einmal das neue ScribeFire, mit dem ich gerade diesen Blogeintrag erfasse, und desweiteren das großartige GCTidy, das die geocaching.com-Seite auf Vordermann bringt. Insbesondere die Fullscreen-Google-Maps-Darstellung kann hier voll und ganz überzeugen.