Skip to content

Blogging zum Spass oder fürs Geschäft?

Spötter halten Blogging für die konsequente Fortsetzung des Massenexhibitionismus, der auf Millionen von nutzlosen persönlichen Homepages gelebt wird. Aber es ist ein praktisches und einleuchtendes technisches Konzept. Durch Aktualität und insbesondere durch Vernetzung hat es viele Anhänger gefunden. Es ist nicht verwunderlich, dass der Blogging-Boom auch viele Blogger in Ihren Beiträgen beschäftigt. Immerhin ist Reflektion eine der positiven Eigenschaften von intelligentem Leben. Neben dem schleichenden aber unaufhaltsamen Erfolg der Blogs im privaten, journalistischen und kulturellen Bereich haben die Blogs im Unternehmensumfeld zugelegt. Leider komme ich nicht umhin, ebenfalls über dieses Thema zu berichten. (Und falls Sie noch nicht wissen was ein Blog ist, sehen Sie doch mal bei der Wikipedia nach). Im Jahr 1999 haben Rick Levine, Chris Locke, Dog Searls und David Weinberger mit ihrem Cluetrain Manifesto die Grundfesten der Unternehmenskommunikation erschüttert. Ihre Thesen legten dar, dass im Internet Zeitalter die Kommunikation sich nicht kontrollieren läßt. Dass die Mitarbeiter eines Unternehmens und zufriedene Kunden in elektronischen Medien die beste Werbung machen. Gewissermassen Peer-to-Peer Marketing, ganz ohne Unternehmensvorgaben. Genau betrachtet sind die ganzen Blogs in denen Mitarbeiter über Ihre Erkentnisse, Frustrationen und Hochs berichten die logische Konsequenz. Und dass immer mehr Unternehmen diese Art der Kommunikation akzeptieren, fördern oder gar erzwingen zeigt wie richtig die Visionen der Autoren waren. "Blogging zum Spass oder fürs Geschäft?" vollständig lesen

Fragmentierung

Windows User kennen die vielen Beschwörungsformeln die es so gibt, um ein Windows Laufwerk benutzbar zu halten. Tatsächlich sind Filesystemfragmentierung neben dem Vermüllen der Registry ein großes Problem bei der Performance von Desktop Systemen. Auf Servern sind die Auswirkungen und der Grad der Fragmentierung abhängig von den Zugriffsmustern. Übrigens ist dies nicht so sehr abhängig vom verwendeten Filesystem und Betriebsytem, diese Effekte finden sich in jedem Filesystem. Je nach Belastung des Filesystems entstehen Fragmente schneller oder langsamer. Besonders problematisch ist immer, wenn neben normalen Datenfiles noch grosse wachsende Files hinzuommen. Fragmentierung entsteht durch löschen/kürzen von Dateien. Normalerweise erholt sich ein Filesystem wieder, wenn die fragmentierten Files gelöscht werden. Dieses erholen kann aber nicht einsetzen, wenn viele der Files lange Zeit gespeichert werden. "Fragmentierung" vollständig lesen

Java File Persistence I

Um Daten in Enterprise Systemen persistent zu machen gibt es mehrere Ansätze. Bei dauerlaufenden, missionskritischen Systemen muss man darauf achten, dass die Daten zuverlässig gespeichert und wiedergelesen werden. Herausforderungen sind hier:
  • konsistente Daten, auch nach einem Programmabsturz oder Stromausfall
  • Online Datensicherung
  • Eventuell eingebaute Replikation
  • Wiederanlauf
  • Transaktionen mit weiteren Systemen
Am einfachsten sind diese Probleme in den Griff zu bekommen, indem man sich (mittels JDBC oder generell EJB CMP) auf Datenbanken verläßt. Diese gliedern sich sauber in den Transaktionsmanager ein, bieten Datensicherungsschnittstellen, erlauben automatische Replikation (Log Shipping) im Betrieb und sorgen durch ausgeklügelte Strategien beim Filezugriff für ein Maximum an Verlässlichkeit. Jedoch gibt es bei EIS auch immer wieder Fileschnittstellen. Die sind so beliebt, weil diese für große Datenmengen geeignet sind, weil diese einfach zu implementieren und zu debuggen sind, und weil es eine Schnittstelle ist die alle Anwendungen anbieten. Filetransfer über Platformgrenzen ist auch nicht wirklich eine Herausforderung. Fileschnittstellen sind leichtgewichtig und haben so oft einen Performance Vorsprung gegenüber RDBMS. Es sind aber Schönwetterschnittstellen. "Java File Persistence I" vollständig lesen

Datengrab von Delphi

Datenbanken (in vielen Fällen sind es auch Datengräber) haben sich über das letzte Jahrzehnt erstaunlich gewandelt. Besonder interessant ist ja der "Wettstreit" zwischen der echten Datenbank Oracle und dem Herausforderer Microsoft SQL Server. Persönlich bin ich ja nun nicht Vollzeit Datenbank Admin oder Programmierer. Trotzdem befasse ich mich eigentlich ständig mit der Produktauswahl, Dokumentation, Evaluierung (und eben auch der Benutzung) von DB Systemen. In unserer an den Kunden gelieferten Software setzen wir auf DB Systeme, und müssen diese eben auch ruhigen Gewissens gegenüber dem Kunden vertreten können. Groß geworden bin ich mit dem Microsoft SQL Server 7.0. Schon damals war die Installation ein Kinderspiel, sogar auf Failover Clustern. Bei Oracle war schon immer alles etwas hakeliger. Da passen die Beispiel Schema nicht in die Default Tablespaces (und diese sind natürlich auch nicht selbstvergrößernd). Die Java Clients streichen die Fahnen wenn sie in zu tiefen Verzeichnissen installiert werden, den ODBC Treibern muss man diverse Handle und Memoryleaks abgewöhnen, und alles dazu noch mit einem obskuren Namenskonzept für Oracle Home. Warum in den Oracle Fehlermeldungen so gut wie nie zu ersehen ist welches Argument nun falsch ist, welcher Wertebereich erwartet wurde und in welchem Kontet der Befehl interpretiert wurrde, daran ist man ja auch bei anderen Produkten gewöhnt. Ich zuck noch nicht mal mehr wenn ich nach "^ORA-" in Textfiles suche. "Datengrab von Delphi" vollständig lesen