This procedure explains how to install MySQL using Homebrew on macOS Sierra 10.12
$ /usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"At this time of writing, Homebrew has MySQL version 5.7.15 as default formulae in its main repository :
| # Add this snippet to the top of your playbook. | |
| # It will install python2 if missing (but checks first so no expensive repeated apt updates) | |
| # gwillem@gmail.com | |
| - hosts: all | |
| gather_facts: False | |
| tasks: | |
| - name: install python 2 | |
| raw: test -e /usr/bin/python || (apt -y update && apt install -y python-minimal) |
| import re | |
| from django.conf import settings | |
| from django.core import cache as django_cache | |
| from mock import patch | |
| from rest_framework.permissions import SAFE_METHODS | |
| from rest_framework.response import Response | |
| class CachedResourceMixin (object): | |
| @property |
So in a recent project I had a very strange publishing bug where two models out of more than a dozen or so, were tossing out 404s where a detail page should be. We had just instituted a lot of caching pieces to the project, which turned out to be red-herrings and probably had something to do with how long it took to track down this bug. But for the sake of the internet and anyone else who finds their model's publish datetimes strangely cached despite their best efforts to get them to show up, here's some good advice:
Don't use the "queryset" model attribute for your view class, override the "get_queryset" function.
In code:
Over the last 3 years or so I've helped a bunch of companies, small and large, switch to Django. As part of that, I've done a lot of teaching Django (and Python) to people new to the platform (and language). I'd estimate I've trained something around 200-250 people so far. These aren't people new to programming — indeed, almost all of them are were currently employed as software developers — but they were new to Python, or to Django, or to web development, or all three.
In doing so, I've observed some patterns about what works and what doesn't. Many (most) of the failings have been my own pedagogical failings, but as I've honed my coursework and my skill I'm seeing, time and again, certain ways that Django makes itself difficult to certain groups of users.
This document is my attempt at organizing some notes around what ways different groups struggle. It's not particularly actionable — I'm not making any arguments about what Django should or shouldn't do (at least
1st November, 2012
Luckily we have got a beta access to Travis CI pro which allows you to build your private repos on github. I did some research for my work and we have decided to replace our Jenkins to Travis CI pro. I leave some notes here.
We have bunch of private repositories, mainly Ruby (rails and gems), on github that we want to continuously test. We currently maintain two CI servers: Buildbot for legacy project and Jenkins for recent projects. On this research, I simply ignored the legacy one and evaluated Travis CI pro as an alternative for Jenkins.
This tutorial guides you through creating your first Vagrant project.
We start with a generic Ubuntu VM, and use the Chef provisioning tool to:
Afterwards, we'll see how easy it is to package our newly provisioned VM
Install Homebrew
Install a few things with homebrew:
Notice that some packages give you information at the end, read it carefully. To recall that info use brew info like this: $ brew info postgresql
$ brew install python --universal
| from django.db.models.query import QuerySet | |
| from django.db.models import Manager | |
| from datetime import date | |
| class EventQuerySet(QuerySet): | |
| def published(self): | |
| return self.filter(published=True) | |
| def available_for_adding(self): |