Tag: "Web-Entwicklung"
Ein sehr guter, informatiker Artikel von Peter Kröner zum Thema HTML 5 und dessen aktuelle Situation bzw. Browser-Unterstützung.
Und mal wieder macht uns Microsoft künstlich das Leben schwer …
Via: praegnanz.de
http://www.noupe.com/tools/15-incredible-mac-apps-for-freelance-web-designers.html
Konnte zwar bisher nicht alle ausprobieren, aber was ich bisher von Pixelmator, Espresso und Coda gesehen habe, begeisiert mich einfach. Außerdem nutze ich schon Cyberduck schon länger und bin ebenfalls sehr zufrieden.
Besonders angetan bin ich von Pixelmator. Es orientiert sich an Photoshop, und steht ihm in der Funktionsvielfalt in vielen Bereichen nichts nach. Trotzdem wirkt die App nicht überladen und ist recht flott. Dank Core Image werden Bildberechnungen über die Grafikkarte erledigt, was ein zusätzliches Geschwindigkeitsplus einbringt. Für jemanden wie mich, der die Möglichkeiten von Photoshop gar nicht ausnutzen kann, aber dennoch ein gutes Bildbearbeitungsprogramm fürs Web braucht, sind die 59 Dollar sehr gut angelegt und vor allem verschmerzbarer, als Adobes Preis-, Produkt- und paranoide Kopierschutzpolitik.
Espresso und Coda wissen ebenfalls zu begeistern. Der Schwerpunkt von Espresso liegt bei XHTML und CSS, um schnell eleganten, modernen Quelltext zu schreiben. Coda geht mehr in die Entwicklerecke und bietet zahlreiche Features, z.B. einen integrierten FTP/SFTP/FTP SSL/WebDAV-Client mit diversen Veröffentlichtungsmöglichkeiten, SVN- und Terminal-Unterstützung sowie ein Plug-In-System.
Cyberduck ist ein FTP/SFTP/SCP/WebDAV/Amazon S3-Client, der es ermöglicht Dateien direkt auf dem Server zu bearbeiten. Leider kann es nicht mehrere Verbindungen gleichzeitig offenhalten, wie es WinSCP vormacht.
Die Fülle, aber vor allem die Funktionen und die Bedienbarkeit von Programmen im Webdesign-Sektor unter OS X, lässt Windows- und Linux-Konkurrenz dieses Marktes vor Neid erblassen. Was soll ich denn bitte mit dem GIMP, wenn ich Pixelmator habe?
Allmählich denke ich über einen Komplettumstieg nach. Allerdings eignet sich bisher kein Mac wirklich gut zum Spielen, daher bin ich vorerst auf beide Welten angewiesen. Bin aber gespannt, ob die neuen iMacs, endlich bessere GPUs spendiert bekommen – ein Mac Pro ist dann doch zuviel des Guten und dann noch der Preis …
Dromaeo hat vor kurzem ein neues Testverfahren eingeführt. Statt der benötigten Zeit für die Tests, wird nun gemessen, wie viele Durchläufe durchschnittlich pro Sekunde in einer fest definierten Zeit erreicht werden. Das macht die ganze Sache langwieriger, aber auch genauer und sagt wesentlich mehr über die Leistungsfähigkeit einer Javascript Engine aus.
Statt auf zwei unterschiedlichen Systemen zu messen, habe ich nun unterschiedliche Benchmarks gewählt: Dromaeo Javascript Test (Mozilla.org), SunSpider Javascript Test (Webkit-Team) und V8 Javascript Test (Google).
Testsystem: Intel Core 2 Duo E8400, 2 GB RAM, Windows XP SP 3
Ein Bild sagt mehr als 1.000 Worte. Chrome deklassiert alle anderen Browser, nur im hauseigenen V8-Test ist das aktuelle Webkit Nightly Build einen Tick schneller. Wie üblich sind die Entwickler-Versionen ihren aktuellen Final-Kollegen deutlich voraus, und die Javascript-Leistung des Internet Explorers, sofern er sich überhaupt testen lies, ist ein schlechter Scherz.
Ein blamables Ergebnis für Microsoft, das mit dem IE 8 auch nicht großartig besser werden wird. Wenn man sich in Redmond angesichts solcher vernichtenden Benchmarks nicht endlich im Zugzwang sieht, sind sie entweder blind und/oder blöd. Google treibt die Entwicklung mit großen Schritten voran, während nur Webkit bzw. Apple halbwegs mithalten kann. Mozilla.org und Opera müssen sich sehr anstrengen, um wieder Anschluss zu finden.
Und Microsoft? Tja, ich sehe nur zwei Möglichkeiten: den ganzen alten IE-Quellcode öffentlich verbrennen und komplett neu schreiben, oder man setzt in Zukunft auf Webkit/Squirrelfish bzw. Webkit/V8 oder Gecko/Tracemonkey.
Oder anders gesagt: Benchmarks von Squirrelfish, V8 und Tracemonkey mit Hilfe von dromaeo.com.
Testsystem: Intel Core 2 Duo P8600, 2 GB RAM), MacOS X 10.5.6 (MacBook Pro 15″ 2,4 GHz Late 2008)
Testystem: Intel Core 2 Duo E8400, 2 GB RAM, Windows XP Service Pack 3
Das Squirrelfish schnell ist, war ja schon bekannt. Aber das es V8 und Tracemonkey dermaßen in den Hintern tritt, hätte ich nicht gedacht. Auf die Antwort von Mozilla und Google dürfen wir alle gespannt sein.
Anmerkung zum Internet Explorer: leider konnte ich weder den IE 6 noch 7 dazu bewegen, überhaupt einen Benchmark durchlaufen zu lassen. Entweder meldete er Javascript-Fehler oder stürzte ab. Aus Tests von anderen Leuten, ist aber bekannt, dass er im Vergleich extrem langsam ist – im Schnitt etwa 10 – 15 Sekunden.
Während bei Safari der Taktenraten- und Cache-Unterschied sich noch halbwegs realistisch in den Ergebissen von OS X und Windows widerspiegelt, zeigt sich bei Firefox, dass Mozilla die Mac-Version noch weiter optimieren sollte.
Update: Nun mit Diagrammen statt Text-Ergebnissen.
Wie schon angekündigt, habe ich mit dem Umstieg auf Netbeans begonnen, Sapphire komplett neu zu schreiben. Der eigentliche Kern ist nahezu fertig und die ersten Module in Arbeit – ging alles wesentlich schneller als erwartet. Daher werde ich Ruby nicht mehr weiter entwickeln und die bestehenden Module umschreiben.
Dinge, wie die Mandanten-Fähigkeit noch in Ruby zu integrieren, obwohl sie im Sapphire-Kern schon implementiert sind, ist sinnlos. Außerdem ermöglicht es die neue Struktur wesentlich schneller und besser, Änderungen am Hauptsystem vorzunehmen. Das Portieren der Ruby-Module sollte relativ schnell und unproblematisch laufen.
Die wichtigsten Unterschied zwischen Ruby und Sapphire:
- Sapphire ist durchgängig objektorientiert, soweit es PHP 5 ermöglicht.
- Es werden ausschließlich Prepared SQL Statements über MySQLi oder PDO unterstützt.
- Die Fehler-Verwaltung läuft komplett über Exceptions (SPL und eigene).
- Bessere und nun vollständige Implementierung des MVC-Patterns.
- Alle Singleton-Patterns wurden entfernt.
- Mandantenfähig von Anfang an.
- Abstraktionsebene aller Superglobals.
- Alle assoziativen Arrays wurden durch Instanzen der Klasse Data ersetzt.
- Kleinere Änderungen an der Datenbank, u.a. für die Mandantenfähigkeit. (Ein Import-Script wie von Version 1 auf 2, ist nicht nötig.)
Insgesamt bin ich mit bisherigen Stand sehr zufrieden. Vieles ist im Vergleich zu Ruby einfacher geworden, ganz besonders der Modul-Manager – bei gleichem Funktionsumfang braucht er nur knapp die Hälfte des Quelltexts. Es ist nun wesentlich einfacher, zu überprüfen, ob ein Modul schon geladen ist und an dessen Funktionen heran zu kommen. Zusammen mit einem zukünftig implementierten Observer-Pattern und der Factory des Kerns, ist das die neue Modul-Schnittstelle.
lizenz
Alle Inhalte von madcatswelt.org stehen unter der Creative Commons-Lizenz.