Alex Online Today

some experience to be shared

By

cUrl unter Mac OS updaten/reparieren

Vorgeschichte: (Vermutlich) seit dem Update auf Mavericks funktioniert mein cUrl nicht mehr korrekt. Beim Ausführen von curl im Terminal erhalte ich folgende Fehlermeldung: “Bad CPU type in executable” (eventuell wurde mein eigenes build nicht durch Mavericks überschreiben)

Warum auch immer, folgendermaßen läd und installiert man cUrl neu:

1. Download der aktuellen Version von http://curl.haxx.se/download.html [Download der sourcen als .tar.gz
2. Navigiere im Terminal zu Downlaods: cd ~/Downloads
3. Entpacke den Download: tar zxf curl-7.33.0.tar.gz
4. Wechsel ins richtige Verzeichnis: cd curl-7.33.0
5. Build + install: make && sudo make install

–> Anschließend sollte curl wieder funktionieren:
6. Test: curl –version
—> curl 7.33.0 (x86_64-apple-darwin13.0.0) libcurl/7.33.0 OpenSSL/0.9.8y zlib/1.2.5

By

$PATH unter Mac OS X

Was ist $PATH
Die $PATH Variable definiert, in welchen Verzeichnissen ausführbare Dateien d.h. per Befehl ausführbare Programme, abgelegt sind, sowie die Reihenfolge in welcher diese Verzeichnisse nach ausführbaren Dateien durchsucht werden.
$PATH besteht aus Einträgen des Systems, die für alle Benutzer gleich sind (systemweit), sowie individuellen Benutzereinträgen (benutzerspezifisch).
Die $PATH Variable gibt es übrigens nicht nur unter OS X sondern auf quasi allen Unix und Linux Systemen und auch unter Windows. Die Funktion ist hierbei allgemein die Gleiche – nur wie und wo $PATH definiert wird ist unterschiedlich. Die folgende Anleitung beschreibt das Verhalten unter OS X 10.5 bis 10.8.

1. $PATH auslesen
Um $PATH zu auszulesen öffnet man ein Terminal Fenster (Spotlight –> “Terminal”) und gibt folgenden Befehl ein:

echo $PATH

Man erhält dann beispielsweise folgende Ausgabe:

/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/opt/X11/bin:/usr/local/git/bin:/usr/local/MacGPG2/bin:/usr/texbin

2. $PATH Syntax
Die Variable besteht aus einer Aneinanderreihung von Verzeichnispfaden, die durch einen Doppelpunkt “:” getrennt sind.
z.B. sind /usr/bin und /bin Standardverzeichnisse des Systems. Dort finden sich auch Programme wie “echo” -> wie wir es zur Anzeige von $PATH gerade verwendet haben. Wichtig ist folgendes – je früher ein Verzeichnis in $PATH auftaucht, desto höher ist seine Priorität.

Ein Beispiel:
Das Programm echo liegt standardmäßig im Verzeichnis /bin. Wird nun ein weiteres Programm mit dem Namen echo in /usr/local/bin abgelegt, so hat das Programm echo im Verzeichnis /bin immer vorrang, denn bei der Auführung wird beim Auffinden eines passenden Programms im $PATH die Suche abgebrochen. Wenn nun in Zukunft die Programme in /usr/local/bin vorrangig ausgeführt werden sollen, muss man $PATH ändern in etc/paths

3. $PATH systemweit anpassen
Seit Mac OS 10.5 Leopard wird $PATH durch das Programm /usr/libexec/path_helper verwaltet. path_helper wird durch /etc/profile beim Öffnen eines neuen Terminal Fensters ausgeführt.

1. Die Einträge der Datei /etc/paths
/usr/bin
/bin
/usr/sbin
/sbin
/usr/local/bin

2. Die Einträge in allen Dateien im Verzeichnis /etc/paths.d/
– Hier hinterlegen häufig Frameworks ihre Pfad-Einträge, z.B. von git oder LaTex
– Diese Einträge werden in Alphabetischer Reihenfolge hinzugefügt
– Eine Datei muss mit einer leeren Zeile enden

Die Dateien sind für gewöhnlich schreibgeschützt und die Verzeichnisse versteckt. Am besten man arbeitet im Terminal:
a) Navigation zu den Ordnern:

> cd /bin

b) Editieren mit vim (sudo für root Rechte)

>sudo vi paths

Nütliche Befehle in vim sind:
i Editieren der aktuellen Zeile
dd Löschen der aktuellen Zeile
i und dd werden mit esc beendet.
:q! Beenden (explizit ohne Speichern der Änderungen)
:wq! Beenden und speichern einer readonly Datei

4. Benutzerdefinierte Einträge in $PATH
Vor dem Öffnen eines neuen Terminal Fensters werden werden die Datein .profile und .bash_profile (in dieser Reihenfolge) im Benutzerordner (~) des aktuellen Nutzers ausgeführt. Es handelt sich um versteckte Dateien (beginnend mit ‘.’) weshalb man sie normalerweise im Finder nicht sieht. Um sie im Terminal anzuzeigen geht man folgendermaßen vor:
a) Navigation zum Benutzerverzeichnis:

>cd ~

b) Anzeigen aller Dateien

> ls -a

Um die Dateien zu bearbeiten, nutzt man am besten wieder vim
c) Bearbeiten mit vim (ohne root Rechte)

vi .profile

In diesen Dateien kann durch den Eintrag

export PATH=$PATH:/newpath

die $PATH Variable für diesen Benutzer erweitert werden. Den bestehenden $PATH stellt man für gewöhnlich vorne an.

By

Visualisierte Simulation mit JavaScript und Canvas Element

Simulationen lässt man für gewöhnlich auf großen Maschinen laufen, um in angemessener Zeit zu Ergebnissen zu kommen. Wenn jedoch die Visualisierung im Vordergrund steht – frage ich mich – warum nicht auch mal mit JavaScript im Browser durchführen.

Folgende Aufgabe war gestellt: (Quelle: Universität Karlsruhe/KIT Vorlesung Grundzüge der Informationswirtschaft 2011, Prof. Dr. Christof Weinhardt, Timm Teubner)

Auf einem Schulhof mit 400 Schülern breiten sich drei unterschiedliche Gerüchte über den Verbleib eines Lehrers aus.

(1) Der Lehrer ist krank und deshalb nicht da.
(2) Der Lehrer ist mit einer Schülerin nach Argentinien durchgebrannt. (3) Der Lehrer ist ein gesuchter Serienmörder und jetzt im Gefängnis.

Bilden Sie den Schulhof als Raster von 20  20 Feldern ab, wobei sich auf jedem Feld genau ein Schüler befindet. Jeder Schüler kann mit den Mitschülern auf den umliegenden acht Positionen reden, (so wie hier dargestellt) und tut dies auch! Jeder Schüler glaubt zu jedem Zeitpunkt an genau eine Version des Gerüchts. Zunächst sei die Verteilung zufällig und gleichverteilt.

Für die Verbreitung der Gerüchte von einem Zeitpunkt auf den nächsten gelten folgende Regeln:

  1. (i)  Ein Schüler glaubt zum Zeitpunkt t+1 an ein Gerücht, wenn zum Zeitpunkt t vier oder mehr seiner Nachbarn an dieses Gerücht geglaubt haben.
  2. (ii)  Gerücht zwei stellt eine Ausnahme dar: Hier genügen drei Nachbarn – das Gerücht wird als plausibler erachtet, weil die betreffende Schülerin ebenfalls abwesend ist.
  3. (iii)  Sollten zwei der Bedingungen erfüllt sein, dominiert (natürlich) das absurdere Gerücht (3 > 2 > 1).

Die visualisierte Lösung findet Ihr unter:

http://www.alexander-wolf.net/simulation.htm

 

Eingesetzt wurde ein Canvas Element zur Darstellung des “Schulhofes”. Dieser wird nach jeder durchgeführtem Simulationsfolge neu gezeichnet. Die größten Zeiteinbußen in der Simulation stellt auch dieser Zeichenschritt dar. Wenn man die Randhöhe des Schulhofes erhöht (z.B. auf 1000) lässt sich mit diesem Skript eine sehr hohe Auslastung im Browser erzeugen. Dann funktioniert auch die Darstellung nur noch bedingt.

By

Native oder Generische Smartphone Applikationen

Kurzer Beitrag entstanden für ein Wahlpflichtfach an der Hochschule:

Die Präsentation dazu findet sich unter: https://prezi.com/secure/f018296ac996c51af6a8fbc03a4066164c23c2de/

Was ist nativ, was ist generisch:

Moderne Telefone s.g. Smartphones verfügen über einen ähnliches Funktionsumfang wie Computer. Dies ermöglicht das Ausführen von Anwendungen, sowie das Aufrufen von WebApplikationen, und ausführen von Widgets oder Flash-Programmen.
Welche Fähigkeiten ein Telefon hat, hängt in erster Linie vom darauf ausgeführten Betriebssystem ab. Der Markt ist momentan sehr volatil, jedoch trifft man hauptsächlich auf folgenden Systemen für Smartphones:
Symbian (Nokia), BlackBerry (RIM), iOS (Apple), Android (Google), Windows Phone 7 (Microsoft), Windows Mobile (Microsoft), WebOS (HP/Palm).
Im 2. Quartal 2010 hat Symbian mit 43% noch immer den größten Marktanteil (wenn auch mit stark abnehmender Tendenz), dahinter folgen Blackberry/RIM mit 18%, Android mit 17% und iOS mit 13%1. Dies Verteilungen ändern sich jedoch noch stark und über die vergangenen Quartale war nur eine Tendenz weg von Symbian hin zu iOS und Android zu erkennen. Zu einem ähnlichen Ergebnis kommt auch die FAZ2:
Dort wird eine Statistik von Gartner herangezogen, die Nokia noch geringere Werte einräumt. Den Grund für die Verlagerung sieht die FAZ in erster Linie in der mangelhaften Software der Nokia Geräte.  
Dies dient nur zur kurzen Darstellung des Marktes, daraus entsteht folgendes Problem: Für alle Geräte stehen native Entwicklungsumgebungen bereit. Für Nokia wird mit Qt entwickelt, BlackBerry und Google setzen auf Java (jedoch unterschiedliche Frameworks), Apple Cocoa-Touch (Objective-C) und Microsoft, zumindest mit Windows Phone 7, auf Silverlight. Dies bedeutet, dass native Applikationen für jedes System einzeln entwickelt werden müssen, wofür spezielles Know-How und Ressourcen einzuplanen sind.
Alternativ können einfache Programme auch auch als Web Applikation über den Browser bzw. als Widgets in der Browserengine ausgeführt werden. Hierbei verringert sich der Entwicklungsaufwand zunächst, da theoretisch alle Browser ähnlich funktionieren. Das selbe gilt für Flash und Silverlight-Programme, wobei nicht alle Smartphones Flash bzw. Silverlight unterstützen und wenn, dann oft nur eine Mobilversion der entsprechenden Laufzeitumgebung installiert ist, was weitere Einschränkungen mit sich bringt. Ich gehe zunächst insbesondere auf die Möglichkeit ein, generische Apps als solche mit Webtechnologien (HTML, CSS, JavaScript) zu sehen. Diese sind von jedem modernen Telefon ,in Form einer mobilen Webseite, aufrufbar und lassen sich für viele Modell als Widget aufwerten (was sie einem nativen Programm schon sehr nahe bringt). Flash und Silverlight sind auf mobilen Plattformen momentan noch so wenig verbreitet, dass hier nur bedingt vom generischen Ansatz profitiert werden kann.

Warum sind native Anwendungen beliebt – Die Anwenderperspektive

Obwohl native Anwendungen bereits seit vielen Jahren theoretisch möglich sind, hat sich deren Verbreitung erst in den letzten drei Jahren richtig durchgesetzt. Hierbei spielen verschiedene Faktoren eine wichtige Rolle. Vorallem waren in der Vergangenheit viele Benutzer nicht in der Lage, richtige Programme auszuführen. Dies lag entweder an den Geräten, die keine Applikationen unterstützten, an technischen Hürden, es war mitunter einfach zu kompliziert, Programme auf die Telefone zu installieren, oder daran, das kein „richtiges“ mobiles Internet verfügbar war, was viele Anwendungen sowieso uninteressant machte. Allgemein war dadurch das Interesse an mobilen Applikationen so gering, dass sich auch die Erstellung kaum lohnte.
Ein wirklicher Schub an Anwendungen kam erst auf, als Apple und Google eigene Vertriebswege für Applikationen bereitstellten, den iTunes App Store und Android Market. Mittlerweile gibt es viele weitere Plattformen (z.B. Nokia OVI Store, RIM App World, …), die Stores von Apple (beinahe 325.0003 Apps) und Google (ca. 200.000 4 Apps) bieten jedoch nach wie vor die größte Vielfalt und haben die größten Umsätze, auch weitere Stores mit nativen Anwendungen wie der Windows Phone App Store (mit bereits 5000 Apps nach 1 Monat) weisen eine enorme Wachstumsgeschwindigkeit auf.
Zwar bilden sich auch für plattformübergreifende Applikationen langsam solche Märkte, sie sind jedoch noch weitgehend unbekannt oder befinden sich noch in der Konzeptionsphase. (z.B. der InMarket für Flash)
Die Beliebtheit nativer Applikationen hängt dabei vor allem von folgenden Kriterien ab:

  1. Geringe Komplexität für den Anwender
  2. Integration in das System
  3. Funktionen des Telefons verwenden

Zu Punkt 1: Insbesondere durch die Stores ergibt sich für Anwender die Möglichkeit, durch eine Suche über den Gesamtbestand an Anwendungen schnell und einfach jene zu finden, die er benötigt. Die Installation geschieht in der Regel über einen einzigen Klick direkt auf dem Gerät oder am PC, wobei das Programm dann automatisch auf das Telefon übertragen wird. Dort wird das Programm auf dem Startbildschirm platziert und kann immer wieder leicht gefunden und ausgeführt werden. Die Bezahlung erfolgt immer über den gleichen Kanal, den der Benutzer bereits kennt und dem er Vertrauen schenkt.
Zu Punkt 2: Native Applikationen können Bedienelemente des ausführenden Systems verwenden. Diese sind dem Benutzer bereits bekannt, so dass er sich schnell zurecht findet. Besonders bei mobilen Anwendungen, die oft nur wenige Minuten laufen und dem Benutzer schnell ein Ergebnis liefern sollen, ist eine komfortable Benutzung essentiell. Generische Anwendungen können diese Bedienelemente nicht nutzen.
Zu Punkt 3: Bei nativen Programmen ist es i.d.R. problemlos möglich, den Funktionsumfang des Smartphones komplett auszunutzen. Von der Integration der Telefonfunktionen wie z.B. Telefonbuch, Kamera, Positionsbestimmung profitiert der Benutzer enorm. Viele Anwendungsfälle lassen sich ohne diese Funktionalität garnicht umsetzen.

Native Apps Generische Apps
Einfach zu finden / zu installieren
(+)
Suche und Installation komplexer und sehr Systemabhängig
Einfach zu bedienen, da die GUI des jeweiligen Telefons verwendet werden kann. Bedienung stark von der Qualität der Entwicklung abhängig. Applikation sieht auf verschiedenen Geräten unterschiedlich aus.
Applikation kann auf Funktionen des Telefons zugreifen wie z.B. Adressbuch, Kamera und Positionsbestimmung Zugriff auf Telefon eigene Funktionen ist kompliziert, nur bedingt oder gar nicht möglich.

Die Entwicklersicht

Für die Entwicklung von mobile Applikationen sind insbesondere folgende Punkte interessant:

  1. Notwendiges Know-How
  2. Aufwand
  3. Funktionsumfang

Zu Punkt 1: Während Plattformübergreifende Applikationen meistens auf herkömmliche Entwicklungsumgebungen und Programmiersprachen aufsetzen, ist dies bei nativen Apps oft nicht oder nur teilweise der Fall. Ausserdem muss für jede Plattform spezielles Wissen aufgebaut werden, da sich die Entwicklung auf jeder Plattform enorm unterscheidet.
Zu Punkt 2: Während native Applikationen wie zuvor beschrieben die systemeigenen Oberflächenkomponenten verwenden können wie z.B. Menüleisten und Kartendarstellung, bieten Plattformübergreifende Applikationen diesen Komfort nicht. Ausserdem führt die unüberschaubare Zahl verschiedener Geräte zu unvorhergesehenen Problemen bei der Entwicklung plattformübergreifender Anwendungen. Plattformübergreifende Anwendungen in einer hohen Qualität zu entwickeln, ist durch die hier entstehende Komplexität oft wesentlich teurer, als das Entwickeln nativer Anwendungen für separate Systeme.
Allerdings bietet die Entwicklung abseits vorgegebener Pfade mehr Gestaltungsmöglichkeiten, während man bei nativen Applikationen oft an Vorgaben und Einschränkungen gebunden ist.
Zu Punkt 3: Im Gegensatz zu Plattformübergreifenden Lösungen haben native Applikationen wesentlich mehr Zugriffsmöglichkeiten auf die zugrunde liegende Plattform. Prinzipiell kann man sagen, je mehr verschiedene Systeme mit einer Anwendung bedient werden möchten, umso kleiner wird der gemeinsame Nenner an Systemkomponenten (Adressverwaltung, Kalender, Kamera, Positionsbestimmung, 3D-Beschleunigung, Bewegungssensoren, …) auf die man in der Applikation zugreifen kann. Einer nativen Applikation stehen immer alle diese Komponenten zur Verfügung.

Native Apps Generische Apps
– Spezielles Know-How muss aufgebaut werden
– Neue Entwicklungsumgebungen und Programmiersprachen
– Anwendung vorhanden Wissens
– Anteil neu zu erlernender Komponenten überschaubar
– Zeiteinsparung durch Verwendung vorhandener Darstellungskomponente des Systems
– Man ist eventuell an Vorgaben der Plattform gebunden (z.B. bei Apple)

– Oberfläche mit hoher Qualität leichter zu erstellen

– Oberflächen lassen sich mit Webtechnologien leicht selbst entwerfen

– Sehen auf jedem Endgerät unterschiedlich aus und sind unterschiedlich zu bedienen
– Qualität kann nur für Geräte gewährleistet werden, auf denen die Applikation getestet werden konnten

– Der volle Funktionsumfang der zugrunde liegenden Plattform ist verfügbar – Funktionen des Telefons lassen sich nicht oder nur bedingt in der Applikation anwenden.

Native Anwendungen – Marketing und Vertrieb

Da native Anwendungen meist über einen dedizierten Vertriebsweg zur Verfügung gestellt werden, ist der Aufwand des Vertriebes wesentlich geringer als der Vertrieb plattformübergreifender Anwendungen. Es muss weder ein eigener Vertriebskanal bereitgestellt, noch verschiedene Bezahlmodelle erdacht werden. Zwar zweigen die Dienstleister einen gewissen Anteil an den Einnahmen ab (bei Apple und Google sind das z.B. 30%) diese Kosten sind jedoch meist geringer als das Bereitstellen einer eigenen Vertriebs-Infrastruktur.

Im Marketing sind die Vorteile noch viel gravierender. Da sich für plattformübergreifende Anwendungen noch keine allgemein anerkannten Standards entwickelt haben, sind diese Anwendungen für den Benutzer oft wesentlich komplexer zu Beziehen und zu Installieren. Während z.B. bei einer iPhone App sofort klar ist, wo diese bezogen werden kann, wie sie bezahlt wird und auf welchen Geräten sie läuft, ist dies bei plattformübergreifenden Applikationen oft nicht eindeutig. Fragen wie „Und wo bekomme ich dieses Programm?“ oder „Läuft das auf meinem Smartphone?“ müssen für einen Kunden nativer Applikationen nicht geklärt werden. Die gesamte Energie des Marketings kann dann aufgewandt werden, um auf die generelle Verfügbarkeit und Funktionalität der Applikation hinzuweisen. Ausserdem stellte es sich in den letzen Jahren als wertvolle Abgrenzung zur Konkurrenz heraus, sagen zu können „Wir haben eine iPhone/Android/… Applikation“, über die wir unseren Service zur Verfügung stellen. Mittlerweile gehört das Bereitstellen nativer Anwendungen beinahe zum Standard.

Native Apps Generische Apps
Bekannte und etablierte Vertriebskanäle Keine etablierten Vertriebskanäle, gegebenenfalls müssen eigene Vertriebsstrukturen aufgebaut werden
Gewinnschmälerung durch Verkaufsplattform (i.d.R. 30%) Kosten fallen nur bei etablieren eigener Vertriebskanäle an, vorhandene Plattformen sind i.d.R. kostenfrei
>Kaum Benutzerunterstützung notwendig Benutzer müssen noch intensiv über das eigentliche Format informiert werden
Applikationen können selbst als Marketinginstrument verwendet werden Es muss explizit Marketing für die Applikation gemacht werden

Fazit

Empfehlenswert ist momentan, native Applikationen für die beliebtesten Systeme zur Verfügung zu stellen. Diese sind zwar in der Entwicklung zunächst mit einem höheren Aufwand verbunden, was sich jedoch sehr schnell relativiert, wenn man versucht mit plattformübergreifenden Methoden gleiche Qualität anzubieten. Im Marketing und Vertrieb spart man sich hingegen enorm viel Zeit und Kosten ein, denn hier muss dem Anwender durch die bestehenden Provider kaum Hilfestellung beim Einkauf und der Installation der Applikationen gegeben werden. Die gesamte Energie des Marketings kann sich auf die Bekanntmachung und den Inhalt des Programms konzentrieren, was für eine stärkere Wahrnehmung sorgt und die Wahrscheinlichkeit eines Flops verringert.

Quellen:
1 iX Developer 1/2011, Seite 8
2 http://faz-community.faz.net/blogs/netzkonom/archive/2010/11/10/smartphone-markt-nokia-stuerzt-ab-android-waechst-rasant.aspx
3 http://148apps.biz/app-store-metrics/
4 http://www.androlib.com/appstats.aspx