Neues iX Special Heft "Programmieren Heute"

Ich habe seit einigen Tagen das neue Heft der iX Special Reihe in meinem Besitz.
Darin geht es um aktuelle Programmiersprachen sowie neue Techniken in der Softwareentwicklung.

Das Heft ist mit rund 13€ etwas teuer, doch dafür sind für Entwickler reichlich Tools auf der enthaltenen DVD.
Dort findet man z.B. die Visual Studio 2008 Express Editions, Eclipse und weitere Entwicklungsumgebungen.
Auch andere Entwicklertools sind enthalten und machen den Kauf gerechtfertigt.

Leider muss ich auch etwas Kritik üben.
Anstelle von neuen Artikeln finden sich aus den regulären iX Heften genommene Artikel wieder.
So ist ein alter Artikel im Heft über LUA sowie einem Vergleich zwischen Java, C#/ASP .Net, Ruby und PHP wieder zu finden.
Dies ist leider sehr schade.
Trotzdem war der Kauf keine schlechte Idee.
Somit muss ich nicht immer die Visual Studio 2008 Express Versionen für C#, C++ und Web Edition herunterladen.

Insgesamt muss man sich entscheiden ob man eine ordentliche Zusammenfassung der iX Artikel + DVD für 13€ kaufen möchte oder nicht.
Ich kann den Kauf jedem empfehlen, der eine kleine Tool Sammlung an Entwicklerwerkzeugen sucht und auch eine Artikel lesen will.

jsync, jFileLib, jConfigLib und jLogLib endlich aufgeräumt

Nachdem sich im laufe der Zeit einige Unklarheiten im Code angesammelt haben, habe ich am frühen morgen damit begonnen die genannten Teile endlich mal aufzuräumen.
Darunter fällt lediglich ein ordentlicher Clean up der Klassen sowie der interne der Libs.
So war die jFileLib mit dem FileReader mal eine Kombination zum lesen von Textdateien sowie von Ressourcedateien wie .jar Archiven.

Nachdem ich dort nun aber Klarheit verschafft habe, kümmert sich die Klasse nur noch um Textdateien.
Später wird eine eigene Klasse für Binärdateien folgen.
Einige Methoden aus jsync, lesen und schreiben von Binärdateien, werde ich auch noch in jFileLib auslagern.

Somit kann ich auch in Zukunft besser mit Dateien hantieren.

Die Programmiersprache D

Ich habe schon zum Release der Version 1.0 von der Sprache gehört.
Konnte mich aber damals noch nicht so ganz damit anfreunden.

Nachdem ich nun einen Artikel in der I'X Spezial "Programmieren Heute" gelesen habe, habe ich mich doch sehr gefreut wie toll diese Sprache eigentlich ist.
Insgesamt ist es ein Mix aus C, C++, Java, C# und vielen anderen Sprachen.

Die Vorteile der Sprache sind vor allem auch eine Speicherverwaltung(Garbage Collection) sowie Entwicklung mit Modulen ala Java(packages).
Dies ist für mich ein sehr interessanter Teil.
Somit entfällt das lästige inkludieren von Header Dateien und die Speicherverwaltung ist ebenfalls vorhanden.
Natürlich hat man hier auch die Möglichkeit die Speicherverwaltung selbst zu übernehmen, was ich aber für eine schlechte Idee halte.
Natürlich gibt es auch Gründe für eine manuelle Speicherverwaltung.
Nur leider sind es immer Speicherlöcher oder eine schlechte Speicherverwaltung, die ein Programm eher unbrauchbar oder gar zu einer Gefahr für den Anwender machen kann.

jsync Optimierungen sowie Netzwerkfähigkeit

Nachdem jsync sich nun schon eine Weile in einem recht guten Stadium befinden, wird es Zeit noch mehr Optimierungen zu machen.
Leider ist jsync immer noch sehr lastig was den Speicher angeht.
Hier habe ich schon durch diverse Optimierungen zwar Einsparungen machen können, doch insgesamt bin ich damit noch nicht ganz zufrieden.

Auch wenn jsync mit drei Threads, die auch drei unterschiedliche Pfade mit mehren Gigabyte abgleichen, "nur" rund 200 MB Ram benötigt, bin ich doch etwas unzufrieden.

Ich möchte es im besten Fall soweit reduzieren, dass man keine 100 MB RAM dafür benötigt.

Auch ist noch das Thema Netzwerkfähigkeit ein großes Problem.
Aktuell kann ich mit jsync nur lokale Datenträger verwenden.
In der heutigen Zeit ist dies aber nicht mehr sehr vorteilhaft.
Viele Benutzer wollen vielleicht auch auf einem FTP Server ihre Daten sichern.
Und hier bin ich bereits am überlegen, wie ich dies am besten umsetze.
Aktuell könnte ich eine Netzwerk Library für Java verwenden.
Da ich aber so sparsam wie möglich sein möchte, werde ich ggf. eine eigene minimale Implementierung erbringen müssen.

Aber dies werde ich noch genauer prüfen.

jsync prüft nun Speicherplatz sowie neue Option

Nach langer Zeit gibt es mal wieder kleine News.
jsync prüft nun ob im Ziel genügend Platz vorhanden ist.
Sollte dies nicht der Fall sein, wird die Verarbeitung übersprungen.

Des weiteren bekommen jsync nun die Option useHashing.
Wird diese Option per false deaktiviert, wird nicht mehr der Hash der Datei überprüft.
Somit fällt sehr viel Zeit weg, die zum lesen beider Dateien benötigt wird.
Es wird dann nur noch die Größe sowie das Datum der letzen Modifizierung der Datei geprüft.

Dies ist zwar schneller aber auch unsicherer.
Dies sollte man nur machen wenn man wirklich sicher sein kann, dass die Dateien nicht mit einem Programm o.ä. verändert wurden.

Diese Option nutze ich bei mir auch, da es bis zu 6 Stunden dauern kann, bis ca. 300 GB mit einer externen Festplatte ab geglichen wurden.
Somit kann man sich viel Zeit sparen.

Die aktuelle Version wird morgen dann ins SVN gespielt und kann dort dann bezogen werden.
Die aktuellen Tests laufen sehr gut.
Die aktuelle Laufzeit bei der gleichen Datenmenge beträgt nur noch 50% da nun keine größeren Tests mehr gemacht werden müssen.

jsync auf dem besten Wege zur neuen Version

Nachdem ich nun mehrere Tage und Versuche gebraucht habe, den Verbrauch des Speichers von jsync zu mindern, kann ich mit stolz ein neues Resultat liefern.

Bisher habe ich jsync nur über Rekursion durch die Verzeichnisse laufen lassen.
Der Nachteil dabei ist, dass diese Art der Verarbeitung sehr Speicherlastig ist.
Dies liegt daran, dass ich pro Verzeichnis Ebene eine Liste von Pfaden habe.
Sobald bei der Verarbeitung ein Ordner gefunden wird, wird in diesen gesprungen und wieder eine Liste mit Pfaden erstellt.

Dies habe ich mit einem einfachen Mittel gelöst und damit auch eine neue Option eingeführt.
Die neue Option unter der Sektion options trägt den Namen "useFileListSync".

Dabei wird der Ablauf von jsync im Fundament stark verändert.
Anstelle des Durchlaufs per Rekursion, wird nun eine Datei in einem Temporären Ordner angelegt.
Der Pfad zu dem Ordner ist über die Sektion folders mit dem Schlüssel tmp konfigurierbar.
In diesem Ordner wird dann die Datei mit der Zuordnung von Quelldatei und Zielordner angelegt.
Dabei werden absolute Pfade gespeichert gespeichert.

Damit sich die Threads bei der Arbeit nicht in die Haare kommen, bekommt jede Datei einfach die Thread ID als Namen + .txt.
Die Dateien können in dem aktuellen Zustand noch bearbeitet werden, was aber nicht erlaubt sein soll.
Dies werde ich dann noch anpassen.
Insgesamt liegt der Verbrauch des Speichers von jsync nun bei 160 MB bei 2 Threads die größere Dateien hashen sowie abgleichen oder ggf. neue Dateien kopieren.

Somit ist mein Ziel aber noch nicht ganz erreicht.
Als nächstes würde ich einen Verbrauch von unter 100 MB anpeilen.
Ab dies auch klappt, ist noch abzuwarten.

Ansonsten ist die kommende Version sehr stark optimiert um den Verbrauch stark zu reduzieren.

jsync bekommt neue Option

Nachdem sich die aktuellen Optionen schon als Vorteilhaft erwiesen habe ich eine Option eingebaut, die ich mit der Zeit ausarbeiten werde.
So haben viele Linux Programme einen Parameter -v für verbose.
Damit kann man sich extra Ausgaben geben lassen, damit man Zusatzinformationen erhält.

Als Beispiel bei jsync wäre dies eine Ausgabe beim verarbeiten des aktuellen Verzeichnis oder des aktuellen Ordners.
Dies teste ich gerade über meinen Home-Server.
Dieser enthält dann noch eine größere Sammlung an Freigaben mit Filmen, Musik, virtuellen Maschinen sowie Backups für meine Rechner.

Insgesamt wird dies aber einen Nachteil haben.
Das loggen solcher großen Sammlungen wird die Logfiles entsprechend wachsen lassen.
Deshalb ist dies eine Option die im aktuellen Status eher mit Rückhaltung genutzt werden sollte.

Ansonsten plane ich diese Option noch für erweiterte Informationen.
Die Option trägt dabei den Namen verboseInformations und bekommt auch einen true/false Wert.
Per Default wird dieser false sein, damit er nicht die Logs bei großen Datei Anhäufungen sprengt.

Damit ich aber auch möglich gute Erfahrungen mit jsync machen kann, werde ich in der nächsten Zeit mein Windows 7 für Tests verwenden.

jsync wird speicherschonender

Nachdem ich bei meinen Durchläufen im Schnitt bei rund 400 MB + lag, habe ich mich entschieden den Speicher verbrauch bei jsync etwas zu verringern.
Aktuell habe ich dafür eine Testversion erstellt, die nicht mehr so stark mit File Objekten arbeitet.
Nun basiert die Verarbeitung mehr auf Listen mit den absoluten Pfaden zu den entsprechenden Dateien.

Die File Objekte werden dann immer nur erstellt, wenn diese auch wirklich benötigt werden.
Dies hat sich schon als Vorteilhaft angesehen.
So liegt der Verbrauch bei der gleichen Datenmenge im Schnitt bei rund 100 MB.
Natürlich gibt es durch die Rekursion auch noch einen starken Verbrauch.
Ansonsten arbeite ich auch nicht mehr mit statischen Arrays sondern mit Listen.
Der Vorteil dabei ist, dass ich nach der Abarbeitung eines Pfades, diesen einfach entfernen lassen kann und somit wieder Speicher freigeben kann.

Die nächste Version wird erst in den kommenden Wochen erscheinen, da ich aktuell viel um die Ohren habe und vor Weihnachten noch einige Referate sowie Klausuren habe.

Es gibt im SVN für jsync auch einen aktuellen Branch(0.75) der den letzten Stand enthält.
Diesen zu erstellen hat mir sehr viel Arbeit und nerven gespart, da ein anderer Versuch eher in die Hose ging als ich versuchte von Rekursion auf Iteration durch eine Liste mit Dateien zu gehen.
Dies war noch mehr Speicher intensiv, da ich dort gleich alle Dateien in die Liste gepackt hatte.
So wie es aktuell ist, ist es gut genug.

Windows Aufgabenplanung macht das Leben leichter

Ich habe vor einigen Tagen mal feststellen dürfen, was für eine geniale Aufgabenplanung man bei Windows hat.
Während ich Tasks, unter Unix auch Cronjobs genannt, unter Debian immer per Skript im cron.* Verzeichnis anlegen müsste, kann man mit ein paar einfachen Klicks einige Tasks einrichten.

Da ich immer meine Daten gesichert wissen will, habe ich mir einen einfachen Einzeiler gebastelt, der mit xcopy einfach meine gesamten virtuellen Maschinen auf meinen Samba Server verschiebt.

Der simple Befehlt sieht wie folgt aus.

xcopy "d:\virtual\*.vdi" "\\MIDGARD\vm" /J /Y /R /U

Wie man sieht, kann man mit einem einfachen Wildcard mit der Endung .vdi die VMs für Virtual Box sichern.
Diese werden einfach auf den Server Midgard unter die Freigabe vm geschoben.

Dies dauert auch nicht lange, da es über ein Gigabit Netzwerk doch recht flink geht.
Der Task war mit wenigen Klicks für eine wöchentliche Ausführung für Sonntags um 18:00 Uhr eingerichtet.

Dieser Komfort ist doch was tolles.

Wieder mal News von mir :)

Nach einiger Zeit des Microbloggens über Twitter möchte ich mal wieder einen Eintrag in meinen Blog packen.

Ich habe in letzer Zeit leider wenig Zeit, weshalb ich auch nicht mehr so viel blogge wie früher.
Aktuell konzentriere ich mich wieder mehr auf meine Ausbildung sowie das lernen für selbige.

Ansonsten gibt es auch nicht extrem viel neues.
Ich habe in den letzten Tagen mal wieder an jsync gearbeitet und auch gleich ein Update in das SVN Repository eingespielt.

Leider haben meine Tests auch noch ein paar Schwächen in der aktuellen Architektur gezeigt.
So benötigt jsync aktuell sehr viel Speicher, wenn man eine größere Verzeichnisstruktur synchronisieren will.
Dies liegt leider an der Rekursion die für das durchlaufen der Verzeichnise genutzt wird.
Ebenfalls muss jsync doppelte Arbeit leisten, einmal alle alten Dateien löschen und dann im zweiten Durchlauf die neuen einspielen.

An dem Speicherproblem werde ich aber dringend arbeiten müssen.
Dagegen sollte eine Umstellung von der Rekursiven auf die Iterative Abarbeitung helfen :)
Dies versuche ich gerade in Tests umzusetzen um hoffentlich sehr viel Speicher zu sparen.

Wenn alles gut geht, kann ich somit sehr viel Speicher einsparen womit jsync auch für etwas betagtere Rechner brauchbar wird.

Ansonsten reift es schon sehr gut und hat auch schon einen guten Stand.
Ich muss jsync nur noch beibringen über Netzwerke zuarbeiten.
Somit kann man später auch über das Internet auf einem eigenen Repository arbeiten.

Ich hatte hier an das FTP Protokoll gedacht, was sich dazu gut anbieten könnte.
Ich werde hier aber nicht das Rad neuerfinden.
Hier werde ich wohl auf vorhandene Möglichkeiten setzen.

Mit etwas Glück kann man jsync bald auch über das gute Internet nutzen, was den Nutzen sehr steigern würde :)