OderWat? » Job

iWork’09 Numbers von der Shell (Terminal) aus nutzen…

oderwat — Thu, 03 Jun 2010 21:13:37 +0000

Ich weiss nicht wie es euch geht… aber ich muss für meinen Job öfters mal CSV oder XLS Dateien mit Scriptsprachen erstellen.

Um diese zu testen habe ich bisher immer die „Maus“ in die Hand genommen und die Dateien manuell in „Numbers“ (aus dem iWork Paket) geöffnet. Das wurde mir heute zu langwierig, deshalb habe ich geschaut wie man Numbers leicht aus der Shell nutzen kann. Das Resultat ist sehr einfach, aber vielleicht spare ich dem ein oder anderen das selber rumprobieren

Ich nun meine „~/.profile“ Datei um folgendes Alias erweitert:

alias "numbers"="/Applications/iWork\ \'09/Numbers.app/Contents/MacOS/Numbers 2>/tmp/numbers-errors.log"

Der Aufruf ist dann so simple wie ein:

> numbers test.csv

Die Redirection von stderr ist notwendig weil Numbers ansonsten bei mir einige Warnings ausgibt, die mir ansonsten die Shell vollsabbern.

Was PHP nicht weiss, macht es nicht heiss…

oderwat — Tue, 01 Jun 2010 15:56:12 +0000

Manchmal geht mir PHP auf den Geist… gerade Fehlersuche beendet und wieder mal einen Effekte gefunden, der mir auf Anhieb nicht einleuchtet:
error_reporting(E_ALL | E_STRICT); // $test=array(1,2,3); print("'".$test[6]."'\n"); // gibt warning (arrayindex) + leerstring // $test=false; print("'".$test[6]."'\n"); // leerstring, kein warning // $test=0; print("'".$test[6]."'\n"); // leerstring, kein warning // $test=‚test‘; print("'".$test[6]."'\n"); // gibt warnung (stringoffset) + leerstring ?>

Wieso bekomme ich für den Index-Zugriff auf „false“ oder dem Integer-Wert keinerlei Warnung ? …

Den Inhalt von PHP und Python Sources bei den Windows 7 Bibliotheken mit indizieren lassen…

oderwat — Tue, 04 Aug 2009 20:52:39 +0000

Seit Freitag letzte Woche arbeite ich nun ernsthaft mit dem “Windows 7″ RC (7100) und bin begeistert… nachdem ich Vista übersprungen und sogar Downgrades von Rechnern gemacht habe.

Gut gefallen mir u.a. die “Bibliotheken” in denen ich nun einige meiner Software Projekte abgelegt habe. Leider hat Microsoft den Klartextfilter nur für “.pl” (Pearl) “.sql” und “.js” automatisch aktiviert.

Auf der Suche wie ich auch z.B. für “.py” und “.php” Dateien den Wortindex erstellen lassen kann bin ich auf eine sehr einfach Lösung gestoßen:

1. “Systemsteuerung -> Indizierungsoptionen” aufrufen
2. Dort bei “Erweitert / Dateitypen” die entsprechenden auswählen und auf “Eigenschaften und Dateiinhalt indizieren” umschalten.

Also keine Raketentechnik notwendig …

Danach hat er bei mir den gesamten Index neu erstellt… und nun klappt auch die Suche nach Worten in diesen Dateien. Allerdings macht mein Eclipse das trotzdem noch besser..

Außerdem möchte man vielleicht noch “.diz” oder “.nfo” Dateien und ähnliches indizieren lassen… alles machbar.

MySQL 4.0, Timestamp(19) und Indizes…

oderwat — Thu, 25 Sep 2008 15:45:57 +0000

Heute bin ich über etwas gestolpert, was mir einige Probleme bereitet… Im Zuge einer zukünftigen Anpassung einiger Software, hatte ich vor einiger Zeit verschiedene MySQL Tabellen so umgebaut, dass in der 4.0 Version die Timestamp Felder mit 19 Zeichen Länge hinterlegt sind (ohne “set new = 1″).

Das funktionierte auch Klasse… Anstelle von “20080901121504″ bekommt man dann ein schönes “2008-09-01 12:15:04″ im SELECT angezeigt und wird dies unter MySQL 5 eben auch so bekommen. Damit muss man nicht für beide “Fälle” programmieren.

Damit konnte ich recht elegant meine Software auf die 19 Zeichen vorbereiten und die Kompatibilität der Timestamp betreffenden Programmbereiche für eine später Umstellung auf MySQL 5 sicherstellen!

Heute fand ich nach langem testen ein Problem, welches dieses ganze schöne Vorgehen völlig absurdum fährt:

MySQL 4.0 benutzt eine “TIMESTAMP” deren Feldlänge mit 19 angegeben ist nie als INDEX in einem Query!

Ich konnte es kaum glauben.. aber es ist nach mehrmaligem Testen eindeutig so!

Einfache Demonstration:

CREATE TABLE `test` (
`id` int(11) NOT NULL auto_increment,
`ts1` timestamp(14) NOT NULL,
`ts2` timestamp(19) NOT NULL default ‘0000-00-00 00:00:00′,
PRIMARY KEYÂ (`id`),
KEY `ts1` (`ts1`),
KEY `ts2` (`ts2`)
) TYPE=MyISAM;

INSERT INTO test (id,ts1,ts2) VALUES (NULL , ‘20080101120000′, ‘20080101120000′);

INSERT INTO test (id,ts1,ts2) VALUES (NULL , ‘20080901120000′, ‘20080901120000′);

Nun wird bei

EXPLAIN SELECT * FROM test WHERE ts1=’2008-01-01 12:00:00′

der Key “ts1″ benutzt…

bei…

EXPLAIN SELECT * FROM test WHERE ts2=’2008-01-01 12:00:00′

wird der Key “ts2″ nicht benutzt!

Wer Lust hat kann aus Key 1 mal einen timestamp(19) machen .. dann wird ts1 auch nicht mehr benutzt.

Das heißt… durch die Umstellung der TIMESTAMP’s auf timestamp(19) wurden diese in Queries welche eine TIMESTAMP im INDEX als Feld haben plötzlich gar nicht mehr verwendet. So etwas fällt auch unter Umständen nicht sofort auf, gerade wenn man solche mit mehreren Feldern verwendet.

Mag sein, dass dies einigen als “völlig Logisch” bekannt ist… für mich war es eine Erkenntnis die mich erstaunt hat. Ich hatte doch tatsächlich gedacht, dass das Darstellungsformat hier keine Auswirkung hat…