Web-first strategies have become a viable strategy for many businesses and we see this more frequently adopted. Lately we have even seen a push for going mobile-first, bypassing the traditional web and other channels. Making the mobile channel the main focus is of course not a coincidence and not just a hype. The fact is that more and more of the Internet traffic is going via mobile and most of us are having iPhonish type of “smart” devices that enable both applications and mobile browsing.
Mobile First: most are doing it wrong!
The thing that bothers me, is that so many have not learnt from the web-first approach and doing just as wrong as they did when moving from print to web. Just look at media industry. I see more and more offers that promises to take your content mobile both for Apps and Mobile Web experience that are based on traditional print systems like InDesign. This is wrong in so many ways.
InDesign is not a dynamic content solution, it is made for laying out pretty print pages and send them to print. The solutions are not good at handling multi media, time to publish is expensive and time consuming. And the whole Social aspects are not even remotely available in such tools, it is made for paper.
Full Apps Experience
If you want to really go mobile first you need to enable the full Apps experience with a native interface and offline storage. This means a low latency and snappy experience for the consumer while still maintaining an efficient publishing process that makes economical sense.
In addition it is crucial that you enable your business model for the mobile world, being it a traditional subscriptions for premium content, retail purchases or simply booking a test drive of the latest and greatest car model.
You need to talk the language
In order for you to really enable a Mobile-first strategy your infrastructure needs to talk the language. APIs and interfaces needs to be easily available to enable developers to build Apps connected to your content in an efficient way.
Pardon the marketing but most systems today are not able to do this as they are purely Web CMS, most often meaning that they store XHTML in the content repository – which is not very much channel neutral as we know.
Mobile Web is not the Web
Handling content for Web is different than Mobile and handling Paper is again very different. For that reason your system needs to be able to differentiate the channels and translate the channel neutral content into channel specific enriched content. And this is only possible if you are truly managing your content in a neutral way. Just make sure you keep that in mind when you build your infrastructure, there are good systems out there and needless to say that I am happy to assist.
eZ Marketing: Solving the multi-challenge
As you know, I am with eZ Systems and our focus has been solving the multi-challenge which of course includes enabling a Mobile-first strategies. But don’t take just my word for it, listen to customers and partners to learn what they have to say.
Scoopshot has launched their mobile apps also in Estonia (they’ve been available in Finland for some time already). Scoopshot allows you to sell your newsworthy photos to media directly from your phone. Apps are available on iPhone and Android platforms.
Exove has helped Scoopshot in building their backend systems and mobile applications.
Eazybreak, the mobile lunch voucher company, has released an iPhone app to redeem lunch vouchers in a snap. The application, as well as the Eazybreak system, has been designed and developed by us.
The application shows your favourite restaurants, and you can also check the nearby restaurants based on your location. Redeeming a voucher takes only a couple taps and then you are ready to order your food. You just show your application to the cashier and then you’ve paid.
# wget http://www.djangoproject.com/download/1.3/tarball/
# tar xzvf Django-1.3.tar.gz
# cd Django-1.3
# sudo python setup.py install
After this, you can go through the first steps of the tutorial at http://docs.djangoproject.com/en/1.3/intro/tutorial01/ . When the tutorial tells you to “cd into a directory where you’d like to store your code”, do the following:
# cd ~/wsgi_source
# mkdir django-tutorial
# cd django-tutorial
# django-admin.py startproject mysite
When the tutorial tells you to launch the Django development web server, don’t.
If your goal is to develop something that in the end runs under Apache, you should also develop with Apache. There is a lot of discussion on the Internet about Django apps working fine with Django’s own development server, and then failing when installed on Apache.
To get your application running Apache, there are a few extra steps to do, and even after that you may end up with strange concurrency problems. There is an in-depth discussion about the problems related to running Django with a WSGI-script in Graham Dumpleton’s blog. The script below is copied from there.
Here you can find Django’s own documentation about the matter, but following that resulted in the dreaded “ImportError: Could not import settings ‘mysite.settings’ (Is it on sys.path?): No module named mysite.settings“-error.
Add a new virtual host to your Apache main configuration file at /etc/apache2/httpd.conf :
<VirtualHost *:80>
WSGIDaemonProcess localdjango processes=2 threads=15 display-name=%{GROUP}
WSGIProcessGroup localdjango
ServerName localdjango
WSGIScriptAlias / /Users/YOURUSERNAME/wsgi_source/django-tutorial/mysite/apache/django.wsgi
<Directory /Users/YOURUSERNAME/wsgi_source/django-tutorial/mysite/apache>
Order allow,deny
Allow from all
</Directory>
</VirtualHost>
Note the first two lines, which make Apache serve the Django requests in daemon-mode. This can possibly solve the multithreading issues that have been reported related to running Django on top of Apache.
Add a new entry in your hosts-file:
127.0.0.1 localdjango
Then, create the improved WSGI-script, and save it at /Users/YOURUSERNAME/wsgi_source/django-tutorial/mysite/apache/django.wsgi :
After this, you should be able to access your Django app from http://localdjango .
There’s one more thing to do before you can get started with the tutorial. Assuming you want to use MySQL during the tutorial, you need to install Python’s MySQL bindings:
One thing left to do is to set up a server to serve the static files needed by your application. The Django documentation suggests a few web servers, as well as gives an example on how to configure the same Apache virtual server to serve them. Since we want to emulate a production setup, however, we want the static files to be served from a separate server. Another Apache virtual server will do, so we don’t have to install another web server on a local development machine:
Add this to your Apache configuration file:
<VirtualHost *:80>
DocumentRoot /Users/YOURUSERNAME/wsgi_web/djangotutorial
ServerName localdjangostatic
LogLevel warn
<Directory "/Users/YOURUSERNAME/wsgi_web/djangotutorial">
Options Indexes FollowSymLinks
AllowOverride All
Order allow,deny
Allow from all
</Directory>
</VirtualHost>
Add this to your /etc/hosts:
127.0.0.1 localdjangostatic
Edit your settings.py, and change the following settings:
Create a symlink from the Django library to the web root:
# cd ~/wsgi_web/djangotutorial
# ln -s /Library/Python/2.6/site-packages/django/contrib/admin/media admin
Restart Apache again:
# sudo apachectl restart
That’s it. Go through the tutorial if you’re new to Django, or start developing your own application if not. Note that when the tutorial tells you to “restart the development server”, with your setup you just need to:
As a final note, Graham’s workaround may not solve all your problems, and apparently the Django developers say that you’re doing something wrong if you need it. This blog post was written during my first attempt to get Django installed on OS X, so there may be omissions or errors in the instructions.
We had an excellent seminar on Wednesday about designing and implementing iPad and mobile applications. The seminar featured Jarno Koponen from Futureful, Bertrand Maugain from eZ Systems, Norway, and Petri Rahja from Scoopshot. Besides our partners and customers, also our own people, namely Aki-Ville Pöykiö and Juha Jauhiainen from Exove Design had presentations.
Bertrand Maugain discusses about implementing content-driven applications to save time and cost.
Petri Rahja shows Scoopshot plans about their future pro application.
You may download the seminar slides as a PDF file. Please fill in the short query below, and after submitting you’ll get the link to the PDF under the form.
The first day of the first Drupal Business Days is now over. We had two really exciting presentations — Saila Laitinen, our sales director, talked about Fruitful Partnerships and Ecosystems, and Janne Kalliola, CEO, discussed on Growing Drupal Organisations.
As usual, we’ve uploaded the presentations to Slideshare.net. They are also available below.
Most of the instructions here can be found elsewhere on the Internet, but I couldn’t find a comprehensive step-by-step guide that covered everything needed. So, here goes; this should cover everything you need to do to get going with Python, when starting with a stock OS X Snow Leopard Apache:
Create a new virtual host for your Python applications. Add this to your /etc/apache2/users/YOURUSERNAME.conf :
<VirtualHost *:80>
ServerName localpython
DocumentRoot /Users/YOURUSERNAME/wsgi_web
<Directory /Users/YOURUSERNAME/wsgi_web>
Order allow,deny
Allow from all
</Directory>
WSGIScriptAlias /myapp /Users/YOURUSERNAME/wsgi_source/test.wsgi
<Directory /Users/YOURUSERNAME/wsgi_source>
Order allow,deny
Allow from all
</Directory>
</VirtualHost>
Add this to your /etc/hosts:
127.0.0.1 localpython
Restart Apache:
# sudo apachectl restart
Go to http://localpython/myapp , and you should see your “hello world”. If you don’t, something has gone wrong. The easiest way to start debugging is to check your Apache error logs at /var/log/apache2/error_log
More instructions can be found on the mod_wsgi site.