MAMP-Virtual-Hosts mit iOS öffnen

Viele Coder entwickeln ihre Webseiten lokal mit MAMP bzw. MAMP Pro. Wer seine Projekte auch für mobile Endgeräte optimieren möchte, hat mit SquidMan nun die Möglichkeit seine Virtual-Hosts via iPad und co. aufzurufen. Mit dem Programm kann in wenigen Schritten ein Proxy konfiguriert werden. Dieser ermöglicht das spätere Betrachten lokaler Projekte auf iOS-Geräten. Doch der Reihe nach.

SquidMan installieren und Port einrichten

SquidMan Einstellungen
SquidMan Einstellungen

Unter squidman.net/squidman kann die aktuelle Version heruntergeladen werden. Nach der Installation, müssen die Programm-Einstellungen geöffnet werden, um den Proxy zu konfigurieren. Wichtig ist hier die Bestimmung des Ports: Sofern der vorgeschlagene Port 8080 bereits vergeben ist, muss er hier neu definiert werden.

Im Tab „Clients“ kann bestimmt werden, welche Benutzer auf den neuen Proxy zugreifen können. Es kann entweder ein ganzes Subnet freigegeben werden (10.10*) oder aber einzelne Hosts – rechts unten werden Beispiele gezeigt. Ich selbst habe mich für letzteres entschieden und die IP-Adressen meiner mobilen Endgeräte eingetragen. Die IP-Adresse des jeweiligen iOS-Devices ist unter den Wi-Fi-Einstellungen ersichtlich.

Nun kann SquidMan gestartet werden. Jetzt muss der Proxy nur noch bei den Clients eingerichtet werden.

Proxy bei iPad und co. einrichten

iOS Wi-Fi-Einstellungen
iOS Wi-Fi-Einstellungen

Man nehme das gewünschte iOS-Device zur Hand und öffne die Wi-Fi-Settings unter “Einstellungen”. Jenes WLAN mit dem auch der lokale Rechner verbunden ist, muss gewählt werden. Danach auf den blauen Pfeil neben dem Netzwerknamen klicken, um zu den erweiterten Einstellungen zu gelangen.

Hinweis: Unter dem Punkt DHCP ist die aktuelle IP-Adresse ersichtlich. Wer SquidMan nur für dieses Gerät freigeben möchte, kann diese Adresse verwenden um sie in den Proxy-Einstellungen unter „Clients“ einzutragen.

Weiter unten bei den Einstellungen kann ein HTTP-Proxy eingetragen werden. Hier den Punkt „Manuel“ wählen. Als Server muss die IP-Adresse des lokalen Rechners verwenden werden. Diese findet man unter „Einstellungen / Netzwerk„. Danach den Port eintragen welchen man vorher in SquidMan hinterlegt hat.

Der Zugang zum Internet sollte nun bereits möglich sein, die lokalen Virtual-Host-URLs allerdings noch einen Zugriffs-Fehler liefern.

MAMP-Einstellungen
MAMP-Einstellungen

MAMP Pro konfigurieren

Mit MAMP Pro ist es möglich unter „Hosts“ alle lokalen virtuellen Domains zu verwalten. Bei jenen Hosts die zukünftig auch über den Proxy aufrufbar sein sollen, muss allerdings noch manuell der IP/Port des lokalen Rechners eingetragen werden.


Fertig, hoffentlich!

Nun muss sowohl MAMP als auch SquidMan neugestartet werden. Bei mir war sogar ein Neustart des kompletten Systems notwendig. Danach sollte es euch möglich sein eure lokalen Virtual Hosts auch auf den mobilen Endgeräten zu betrachten.

Head JS – Scriptdateien parallel und asynchron Laden

„it’s becoming a core client side development tool for many“


Vor über fünf Jahren genügte noch ein einziges Java-Script-File, um einem ganzen Webportal Interaktivität einzuhauchen. Niemand redete damals über komprimierte Scripte, Framework-Plugins, die neueste JavaScript-Engine im Browser oder clientseitige Performance-Optimierungen. Durch den Siegeszug von Frameworks wie jQuery oder Mootools, dazugehörige Erweiterungen und immer umfangreichere Weboberflächen, wurde das Bild des Internets stark verändert – Und das ist auch gut so. Doch all diese Script-Wunder müssen erstmals vom Browser des Benutzers heruntergeladen werden. Damit dies schnell von statten geht, basteln die Hersteller an immer effektiveren Java-Script Engines. Doch auch jene, die sich Webworker nennen, müssen Zeit investieren, um ihre Projekte dahingehend zu optimieren. Genau an diesem Punkt setzt Head JS an.

Doch was passiert eigentlich beim Laden einer Website? Zuerst werden die im <head>-Bereich verlinkten Stylesheet- und Script-Files heruntergeladen. Abgesehen von ganz modernen Browsern, funktioniert dies nicht parallel, sondern nacheinander. Erst wenn alle Dateien geladen wurden, beginnt das Markup-Rendering und somit auch der für den Benutzer interessante Teil: Die Website erscheint. Schlaue Frontend-Entwickler platzieren deshalb ihre Script-Files an das Ende des Dokumentes. Durch das zuerst durchgeführte Rendering, erscheint es, als würde die Seite schneller laden, da die Script-Dateien erst heruntergeladen werden, wenn die Website schon sichtbar ist. Doch es gibt noch Optimierungsbedarf.

Head JS

Das Konzept von Head JS ist simpel und effektiv: Im Kopfbereich der Seite wird lediglich ein einziges Script-File eingebunden. Alle weiter benötigten Dateien werden parallel via Funktionsaufruf nachgeladen und in der gewünschten Reihenfolge ausgeführt. Der Vorteil liegt klar auf der Hand: Das Rendering der Seite startet sofort und die noch fehlenden Java-Script-Dateien werden, durch den gleichzeitigen Abruf, rascher vom Browser heruntergeladen. Es wird außerdem eine spezielle Funktion “gefeuert” sobald alle Dateien bereit sind. Durch diese ist es möglich, mitten im <body>-Bereich Scripte einzufügen, die erst dann ausgeführt werden, wenn beispielsweise die jQuery-Bibliothek geladen wurde.

Ein einfaches Beispiel zum Laden von drei Script-Dateien mit Head JS:

head.js("/path/to/jquery.js", "/google/analytics.js", "/js/site.js");

Doch Head JS macht mit seiner Größe von 2.30kb noch mehr: Es befüllt den <html>-Tag mit einer Vielzahl nützlicher Klassen (Browser-Typ, Fenstergröße, Funktionalität von einzelnen CSS3-Eigenschaften, Page-Routes und noch einige mehr). Außerdem wird versprochen, dass ausgewählte HTML5-Tags durch das “Kopf-Script” in allen Browsern funktionsfähig sind.

Meine ersten Praxis-Tests verliefen erfolgreich bis durchwachsen. Die Senkung der Seitenladezeiten, klappt durch den parallelen Aufruf in jedem Fall erfolgreich. Die neuen CSS-Klassen sind praktisch und machen so manches zusätzlich erstellte Stylesheet-File obsolent. Probleme gab es lediglich mit dem Internet Explorer: Das Nachladen des selectivizr-Script mit Head JS führte zu regelmäßigen Abstürzen oder Fehlermeldungen des Browsers. Auch Umdenken beim Ausführen von Scripten mitten im <body>-Bereich ist nun angesagt, vor allem wenn dies initial und später via Ajax-Call passiert.

Ein rascher Einstieg in diese neue Herangehensweise ist dank der informativen Website von Head JS gegeben. Ob Webworker zukünftig wirklich nur mehr ein einziges JavaScript-File direkt einbinden müssen und ob die Performance-Steigerung überall erfolgt, werden weitere Tests zeigen. Es wird laufend an Head JS gearbeitet und daher sollte man dieses Projekt im aktuellen Jahr bestimmt nicht aus den Augen verlieren.