<Additional information about your API call. Try to use verbs that match both request type (fetching vs modifying) and plurality (one vs multiple).>
-
URL
<The URL Structure (path only, no root url)>
-
Method:
Latency Comparison Numbers (~2012) | |
---------------------------------- | |
L1 cache reference 0.5 ns | |
Branch mispredict 5 ns | |
L2 cache reference 7 ns 14x L1 cache | |
Mutex lock/unlock 25 ns | |
Main memory reference 100 ns 20x L2 cache, 200x L1 cache | |
Compress 1K bytes with Zippy 3,000 ns 3 us | |
Send 1K bytes over 1 Gbps network 10,000 ns 10 us | |
Read 4K randomly from SSD* 150,000 ns 150 us ~1GB/sec SSD |
from random import choice | |
from string import ascii_lowercase, digits | |
from django.contrib.auth.models import User | |
def generate_random_username(length=16, chars=ascii_lowercase+digits, split=4, delimiter='-'): | |
username = ''.join([choice(chars) for i in xrange(length)]) | |
if split: | |
username = delimiter.join([username[start:start+split] for start in range(0, len(username), split)]) |
For a good while, I've been interested in the topic of automatically generating and routing views. For my last project, I built a haphazard implementation which ran using an elaborate scheme of mixins and decorators. A veritable monstrosity, it was - and the cognitive load of working with it wasted over a month of my time, allowing the project to slowly descend into limbo. I eventually ended up re-writing the heaps of class-based views by hand. Even though making good use of inheritance helped me tremendously, it was still a chore, and my interest in a tool that would save me some boilerplate code for standard CRUD apps remained.
When I first got a glimpse of the Django REST Framework, I was quite impressed by the browsable API; a quick look at the documentation got me hooked onto the concept of ViewSets and Routers. A few days ago, I decided to finally get my feet wet with the DRF and use it in my latest project. I honestly believed that it would b
public static float convertPixelsToDp(float px){ | |
DisplayMetrics metrics = Resources.getSystem().getDisplayMetrics(); | |
float dp = px / (metrics.densityDpi / 160f); | |
return Math.round(dp); | |
} | |
public static float convertDpToPixel(float dp){ | |
DisplayMetrics metrics = Resources.getSystem().getDisplayMetrics(); | |
float px = dp * (metrics.densityDpi / 160f); | |
return Math.round(px); |
I'm going to cover a simple, but effective, utility for managing state and transitions (aka workflow). We often need to store the state (status) of a model and it should only be in one state at a time.
# YOU MAY WANT TO CHECK THIS OUT: https://github.com/douglasmiranda/ddpt/blob/master/{{cookiecutter.django_project_name}}/{{cookiecutter.django_project_name}}/config/local.py | |
# If you don't do this you will have to add the host IP in INTERNAL_IPS = ('127.0.0.1',) | |
# And it will change, then you will have to change INTERNAL_IPS again. | |
def show_toolbar(request): | |
if request.is_ajax(): | |
return False | |
return True |
/* | |
##Device = Desktops | |
##Screen = 1281px to higher resolution desktops | |
*/ | |
@media (min-width: 1281px) { | |
/* CSS */ | |
I really liked @tjvantoll article Handling Failed HTTP Responses With fetch(). The one thing I found annoying with it, though, is that response.statusText
always returns the generic error message associated with the error code. Most APIs, however, will generally return some kind of useful, more human friendly message in the body.
Here's a modification that will capture this message. The key is that rather than throwing an error, you just throw the response and then process it in the catch
block to extract the message in the body:
fetch("/api/foo")
.then( response => {
if (!response.ok) { throw response }
return response.json() //we only get here if there is no error
})