Der Zwiebelflüsterer

Cool, die finale Version der Aptana IDE ist heut morgen (lokale Zeit *g*) erschienen. Obwohl ich die schon seit knapp einem Jahr nutze und regelmässig Updates beziehe, ist der letzte Meilenstein wohl ein klein wenig an mir vorbeigeschlüpft.

Die Sau wird heute Abend doch direkt mal auseinander genommen und besabbert .

Hochgradig clever. Hoch attraktiv. Hochgradig belastbar.

Nein, das ist nicht Teil einer Kontaktanzeige, sondern wir suchen Mitarbeiter im Bereich der Softwareentwicklung (Webkrams wie PHP,(x)HTML, etc.). Festangestellte, Praktikant(in)en, Freischaffende. Egal, hauptsache was im Köpfchen (damit man zum Team passt) und attraktiv (damit man im Team nicht auffällt).

Nähere Details zu zusätzlichen Qualifikationen finden sich hier.

Ehrlich, Fitnessclubs sind im Sozialgefüge manchmal wie Schulen. Ist mir gestern mal so aufgefallen.

Beispiele:

1. Gesichtsbekanntschaften
   Na, wer kennt das noch. Man rennt relativ regelmässig durch das Gebäude (oder die Halle) und erwischt irgendwann den Blickkontakt zu irgend jemanden. Männlich oder Weiblich, völlig egal. Dieser Blick der sagt: ey, ich kenn dich. Aber mehr nicht.
   Und das passiert dann über mehrere Monate hinweg. Diese klassischen “Gesichtsbekanntschaften”. Nichts halbes, nichts ganzes. Und irgendwann, wie gestern, wechselt man spontan ein paar Sätze und merkt, das der gegenüber ja auch reden kann und eigentlich genauso ist wie man es sich vorgestellt hat.
2. Falsche Blicke
   Sport, Umkleidekabine. Dort ist es fast wie im Knast: wer die Seife fallen lässt, hat die sprichwörtliche Arschkarte. Änlich hier, wer die Regeln des Blickverkehrs nicht kennt, wird sich bei einem “falschen” Verhalten wünschen, länger gepaukt zu haben. Falscher Blick auf halbnackt haut -> wochenlange Hämme seitens der Kumpanen. Oder noch besser, direkt eine in die Fresse, wenn das Blickopfer jemand ist der Probleme mit seiner Sexualität hat.
   Nicht im Club. Gestern. Ein hochattraktiver Kerl (acuh aus meiner Sicht, jahaaa!). Zieht sich neben mir halt um. Leict größer als ich, Muskeln wo ich Speck habe und sehr geile Tattoos. Letztere waren das Problem. Tattoos kann man sich ja nicht mal eben im Augenwinkel anschaun, also muss man etwas länger hinblicken. Naja, der Kerle merkte es ….
   Wenn Blicke töten könnte, wäre ich jetzt eine Budhistische, wiedergeborene Kuh in Indien.
3. Neid
   Was in der Schule das Gruppenduschen ist, ist im Club die nicht gemischte Sauna.
   Passive Blicke, Vergleiche mit seinem eigenen Gehänge, Unterdrücken der Tagträume mit brahlen Blondinnen, die einem unter der Dusche (oder der Sauna) begleiten und wer sich als erstes raus bewegt, hat verloren .
4. Hassobjekte
   Es gibt mindestens eine Person, die man nicht mag. Egal warum. Ob es ein Vorfall ist der schon seit Jahren zurückliegt oder einfach unsympathisch sind.
   Das wird man nichtmehr los

Aber im grunde genommen ist es toll, und wenn man es nichtmehr hat, will man die zeit im Leben hin udn wieder zurück haben =).

Die SZ druckt, die GEZ mahnt, heise berichtet und ich hab den Artikel vorsorglich mal aus dem google-Cache gezogen. Für alle die es interessiert, warum die GEZ ihre stasinistische Macht spielen lässt .

Raab: Also im Moment könnte ich ein wenig Training vertragen, habe aber Knieprobleme. Meine Gegner sind inzwischen echte Kampfschweine … Leistungssportler mit Approbation und Philosophiestudium, die nur noch einen Bruchteil der deutschen Bevölkerung repräsentieren. Da wird’s für mich immer schwerer.

via Spiegel Online

Na wenn Stefan einen repräsentativen Teil der Bevölkerung bei Schlag den Raab haben will, sollte er definitiv Rentner zu seiner Show einladen. Damit kann dann auch gleich die Graue Panther-Mehrheit der öffentlich rechtlichen Sender zu Pro Sieben bewegen. Das wäre doch mal ein cooler Generations-Wissens- und Leistungsvergleich .

Jipii, es war wohl eine der kürzesten, strategischen Entscheidung die ich in meiner kurzen Zeit bei uns hier bei INVIAS erlebt habe, aber es ist passiert: gestern haben wir uns  darauf geeinigt, künftig nur noch activecollab als zentrales Projektmanagementsystem zu nutzen. Nach nur einem ca. 1-wöchigen Probelauf der 1.x-er Version, sowie vorheriger monatelanger Nutzung der letzten Open Source-Version  (v0.7.x), war das doch mal ein tolles Erlebnis .

Warum jetzt ac statt den kostenlosen oder kostenpflichtigen Alternativen? An frei verfügbaren Systemen nutzten wir bisher dotproject und Mantis. dotproject war aber mit seiner in die Jahre gekommenen Benutzerführung, dem fehlendem Ticketsystem und der fragwürdigen Programmarchitektur für uns kein Kandidat für eine dauerhafte Zusammenarbeit. In den letzten Jahren klappte es zwar, aber spätestens wenn man sich mehr in den Bereich Produktentwicklung (statt abarbeiten der täglichen Blowjobs) bewegt, schränkt es die Kommunikation zwischen Team und Kunde ziemlich ein.

Naja, und Mantis gab es bei uns nur, weil dotproject kein (vernünftiges) Ticketsystem bereitgestellt hat.

Also fuhren wir seit geraumer Zeit 2 Systeme, zusätzlich zur Planung und Abrechnung, wodurch die Ressourcen-Koordination nicht unbedingt einfacher wurde.

Naja, und davon mal abgesehen ist ActiveCollab vom Preis/Leistungsverhältnis definitiv für kleinere und mittelgroße Unternehmungen erschwinglich, im Vergleich zur Konkurrenz. Diese beginnt meist in einem höheren 4-stelligen Preis (pro Lizenz), bei eigenständig laufbaren Produkten und 2-stelligen monatlichen Abos bei ASP-Services.

Nichts gegen APS Services, wir finden sie ja auch toll. Aber wir haben nunmal gern 100% Kontrolle über unsere Daten sowie die unserer Kunden. Da kommt und das Lizenzmodel von ActiveCollab nunmal sehr entgegen.

Die Eclipse IDE ist ja schon eine geile Sache. Was macht die Sache aber noch spannender? Genau, wenn man jederzeit auf seine Eclipse IDE-Instanz zurückgreifen kann. Von überall her. Das ginge zum einen über das einrichtene eines Remote Desktops, oder aber z.B. mit einem Projekt aus der AlphaWorks Schmiede von IBM.

Damit lässt sich eine zentrale Eclipse IDE-Instanz wunderbar in einem Browser öffnen. Find ich toll und praktisch .

1 Raum, 12 Leuchten, 7 Schalter. Ich hasse Schnellschusslösungen :/

Ruby ist eine nette Sache. Irgendwie. Oder um es mit den Worten von Derek Sivers zu sagen:

Programming languages are like girlfriends: the new one is better because *you* are better

Nun, ok. Einerseits kann man sagen das solche Sprüche von ziemlich einsamen, einsamen, einsamen Mitmenschen kommen. Andererseits … es stimmt.

Und je interessanter etwas wird, desto mehr stören einen eventuell die Kleinigkeiten. So wie mich gerade, als ich über eine kleine Hürde in Ruby/Rails/ActiveRecord stolperte.

gem kennt jeder, oder? Schon, klar. gem ist einerseits ein netter Manager um diverse Ruby-Module(?) fein zu verwalten. Andererseits ist gem auch der rechtmässige Befehlsnachfolger von require_gem. Und hier kommt was, woran man sich so als eingefleischter PHP-Entwickler gewöhnen muss: beide Befehle, obwohl der eine auf den anderen aufbaut, und auch interpreterseitig die entsprechenden Hinweise kommen, gem anstatt require_gem zu nutzen, vollführen völlig unterschiedliche Operationen.

• require_gem “gem_name” “*version”
  … sucht nach einem Modul gem_name, initialisiert/aktiviert und lädt es. Wurde dazu noch *version mit angegeben, wird die spezifische Version des Moduls aktiviert und geladen.
  Aktiviert bedeutet hier, das der interne Pfad zu einem bestimmten Modul einer bestimmten Version gesetzt wird.
  Laden dagegen bedeutet, das einem Skript die derzeit aktivierte Version von gem_name dann tatsächlich zur Verfügung gestellt wird.
  Toll. Und so einfach, nicht?

  Beispiel (anhand meines aktuellen Falles):

  require_gem "activerrecord", "=1.15.5"

  Modul ActiveRecord in Version 1.15.5 wird aktiviert, dessen Inhalte dem Skript zur Verfügung gestellt. Yipiii.
  Aber, dieser Befehl ist derzeit (Stand 0.9.4(gem)) veraltet und wird durch tolle “Warning: require_gem is obsolete. Use gem instead.”-Meldungen signalisiert.

  Also ran an …

• gem “gem_name” “*version”
  gem macht nun … nicht ganz das gleiche. Und das war ein Punkt der mich etwas wuschig machte. gem aktiviert nur das angeforderte Modul (in Version X), stellt dieses aber dem Skript nicht bereit. Ärgerlich, aber das Leben ist nunmal kein Ponyhof. Also ran an Google zur Lösungsfindung und vóila, da war sie nach kurzer Zeit schon.

  Da ist schön (mit Hilfe der offiziellen Doku natürlich) erklärt, was Sache ist. Also fehlt .. hmm, ein zusätzliches require, richtig?
  Also ran an die Wurst:

  gem "activerecord"
  require "activerecord"

  Hinweis: Ich habe hier mal die Versionsangabe weggelassen. Ohne diese, wird auf die (wohl?) aktuellste Version im lokalem gem-Archiv zurückgegriffen.

  Nun, das zustzliche require ist irgendwo verständlich, so geht die gem-Moduleinbindung nichtmehr an der Ruby-Kernmethodik vorbei, sondern bindet stattdessen durch diese Aufteilung, diese in dem Prozess (seitens des Anwenders) lediglich mit ein. Aber klappen tut es trotzdem nicht so recht.

  Was hab ich da vergessen? .. *wussel* .. *such* .. aaahh, da steht es ja. Die Bezeichnungen von gem_name und die der ruby-Datei unterscheiden sich :/. Ja toll.

  Ergo noch ein …

• require “filename”
  Damit sieht der Originalcodeschnippsel

  require_gem "activerecord" "=1.15.5"

  Nun, nach der evolutionären Weiterentwicklung nun so aus:

  gem "activerecord" "=1.15.5"
  require "active_record"

Also eigentlich find ich das eine sehr interessante Herangehensweise, immerhin muss das gesamte Projekt von vornherein mit mehreren Testcases umschlossen sein, um bei solchen Änderungen dann den Überblick über eventuell auftretende Probleme behalten zu können.

Derek Sivers hat vor einiger Zeit beschrieben, wieso er von Rails wieder zurück zu PHP gesprungen ist. Es ist keine grundsätzliche Entscheidung gewesen, so das er nie wieder mit Rails zu tun haben will. Aber sein schönes (doch leicht verstörend beschriebenen) Beispiel (zuviel liebevolle und sexuelle Beschreibungen zu Programmiersprachen ) beschreibt einen Hauptaspekt, wieso wir bei INVIAS z.B. noch kein Rails einsetzen: es ist einfach nicht machbar.

Es wäre für uns Unsinnig von einem Gleis auf ein anderes zu springen, nur weil es gerade (jaja, 2+ Jahre) Hip ist. Alle unsere Projekte basieren auf einem technischen Standard, der sich hauptsächlich durch PHP geprägt hat. Und PHP ist nicht (nur) schlecht. PHP ist skalierbar und performancefreundlich, wenn man die Umgebung vernünftig konfiguriert. Es hat sicherlich seine Probleme. Die OO-Fähigkeiten ab der 5.x-Version mal vernachlässigt, konnte man aber auch schon mit früheren Versionen vernünftigen Programmcode schreiben. Wie Derek es schon so schön ausdrückte:

It’s not the language (entirely). It’s you, dude.

Aber natürlich ist es notwendig, nicht von der täglichen Arbeit eingemauert zu werden und seine Löffel aufzusperren und zu lauschen, was in der Welt vor sich geht. Und wenn sich die Gelegenheit bietet, auch mal stark zu experimentieren. Immerhin ist das arbeiten mit einer anderen Sprache oder einem andeen team wie ein Auslandsstudium: man kann nur etwas lernen, aber nicht verlernen. Aber bitte geschmeidig .