This is not a trivial one... obviously for later.

Overview

It would be a good show if our site detected mobile user agents and provided a better targeted experience for those devices.

Tasks

• Decide on a mobile detection scheme. This may include the ability to manually select mobile vs. standard in case user-agent detection ever makes a mistake (in the wide world of ever new devices)
• Design layout of mobile experience. Because this experience should be target, it may be reasonable that our current one-page site becomes multiple pages for mobile (or rather has a really good navigation scheme for what would be a really long page for a mobile device).
• Implement design in mobile.css
• Implement user-agent detection and mobile/standard switching scheme

I think gondor supports some sort of worker or task concept. If so, that should be used to periodically refresh the meetup data for the home page. Currently, the first user to hit the page after cache expiry takes the hit.

It's on Julia's design, we don't have it yet in the code. Probably something simple, like this [1]. Will probably go to the groups private gmail address when a site visitor submits.

UPDATES:

• For now, will just submit against the home-page URL and return to that page with a message (using the django messages framework), and the form at the bottom will be reset.
• Also need to investigate how caching works on a page with a form and a message after form submission.

[1] https://bitbucket.org/ubernostrum/django-contact-form/

Recording suggestion from Andrew so that I don't lose it...

It would be nice if the map icon was clickable so that people could get directions to the venue right there from the page. Not sure if
it's a quick fix or not. Might need to change that from a LatLong to a ImageMapType or something. I think the LatLong is just a
base class with limited functionality?"

In our provision.sh, we have the commands:

aptitude purge -y chef chef-zero puppet puppet-common
aptitude dist-upgrade -y

Are these needed for some reason? They add a fair amount of time to the provisioning, so if they're not required, I'd just remove them.

In the Vagrantfile, the line for the synced folder:

    if OS.unix?
      pykcdotdev.vm.synced_folder "./",  "/vagrant/", type: "nfs"

causes the following issue:

Bringing machine 'pykcdotdev' up with 'virtualbox' provider...
==> pykcdotdev: Importing base box 'debian/jessie64'...
==> pykcdotdev: Matching MAC address for NAT networking...
==> pykcdotdev: Checking if box 'debian/jessie64' is up to date...
==> pykcdotdev: Setting the name of the VM: pykcdotdev
It appears your machine doesn't support NFS, or there is not an
adapter to enable NFS on this machine for Vagrant. Please verify
that`nfsd` is installed on your machine, and try again. If you're
on Windows, NFS isn't supported. If the problem persists, please
contact Vagrant support.

Just removing the type specification from that command resolves this, I believe.

Our VM is using Python 3. We need to make the app work with Python 3. Also: how do you get virtualenvs working in ansible with python3. Please. @lgw4 this is your fault. :)

Gondor actually has a pretty nifty log viewer, but we have to know to go look at it if there are ever errors on the site. Therefore, we should configure it to email me (and whoever else wants to be notify) if things ever go horribly wrong on the site.

Action items:

• Create model to keep latest meetup data, in case meetup is ever down or we exceed rate limit (seems unlikely, but I somehow just did it)
• Model could mean Django ORM (SQL) or persistent redis data. TBD
• Create model to override event photo with custom photo URL
• Setup admin interface behind login so that data can be manually updated if need be, and the event photo overrides can be managed.
• Add Django-style backend interface [1] that abstracts away the usage of the meetup API vs. model fallback. This should make our views resilient to any issues with meetup.com's availability or our rate limit.

[1] http://charlesleifer.com/blog/django-patterns-pluggable-backends/

So says Zackh

When issuing vagrant provision on an existing VM, I get the following failure. Can we make the Run migrations task resilient to re-runs?

==> pykcdotdev: Running migrations:
==> pykcdotdev:   Rendering model states... DONE
==> pykcdotdev:   Applying admin.0001_initial...
==> pykcdotdev: :stderr: Traceback (most recent call last):
==> pykcdotdev:   File "manage.py", line 11, in <module>
==> pykcdotdev:     execute_from_command_line(sys.argv)
==> pykcdotdev:   File "/home/vagrant/virtualenvs/pythonkc/local/lib/python2.7/site-packages/django/core/management/__init__.py", line 338, in execute_from_command_line
==> pykcdotdev:     utility.execute()
...
==> pykcdotdev:   File "/home/vagrant/virtualenvs/pythonkc/local/lib/python2.7/site-packages/django/db/backends/sqlite3/base.py", line 316, in execute
==> pykcdotdev:     return Database.Cursor.execute(self, query)
==> pykcdotdev: django.db.utils.OperationalError: table "django_admin_log" already exists
==> pykcdotdev: 

So says Zach