Showing posts with label django. Show all posts
Showing posts with label django. Show all posts

Thursday, April 6, 2017

ipython magic: effortless module reload

Seeing is huge.  Anything that you can do that lets you see what's happening in a system with more detail or more quickly will help you master that system.  Do you want to understand how your lawn mower works?  Remove the hood.

Python programming can be a pleasure, partly because it's simple to see what you're doing.  If you want to understand a little snippet, you just take it to the interpreter, run it, and get an output.  Edit it and get a new output.

Some effects are trickier to see because they are contextual.  That is, your snippet won't do the same thing if you paste it into the interpreter as it will in the environment where it's meant to live.  This is particularly true for me when I'm working with Django code, which often depends on a Django environment.

The Django shell (./manage.py shell) solves part of this problem.  The Django Extensions shell (./manage.py shell_plus if you've installed the Django Extensions app) can take you further.  But even then if you have code that depends on the actual location of a file, for example, you can't test it in the shell directly.

To get around that issue, I've typically done two different things in the past: 1) run the code in a test and use print statements or ipdb to get the information that I want, or 2) figure out how to reload the interpreter every time I update a module.

This post celebrates the fact that I just learned how to do 2 much more efficiently than before.  So here it is -- effortless ipython reload:


Monday, April 6, 2015

ajax post request: simple

An ajax post request can be as simple as any form in django. Just remember the csrf token!

Friday, February 6, 2015

Django in ipython notebook

Holy moly:

I've been using ipython notebook forever.  And I've been working intensively with django for many moons.  I just didn't know that they two could be married so easily.

Enter django_extensions .

For the details, check out this blog post:

http://opensourcehacker.com/2014/08/13/turbocharge-your-python-prompt-and-django-shell-with-ipython-notebook/

Saturday, January 24, 2015

Focusing on the fundamentals

I've been looking for the next text to go through.  Today I happened on what looks like a nice one, focused on a lot of fundamentals related to what I'm doing right now.  Here's the link:

http://chimera.labs.oreilly.com/books/1234000000754/pr01.html#_outline

Friday, January 23, 2015

Lite Custom Google Search Alternative for a django site

Right now I have a search bar that is a customized Google search.  It's basically an ordinary Google search whose results are narrowed to only the portions of Nnums that it has indexed.  Since indexing is incomplete and occasional, it's not a great way to search for a bit of data.

Here's a post on a simple way to search the models on your site:

http://julienphalip.com/post/2825034077/adding-search-to-a-django-site-in-a-snap

I think I'll have to try this out.

Friday, December 5, 2014

Django default settings

From appendix D of the djangobook:

Default Settings

A Django settings file doesn’t have to define any settings if it doesn’t need to. Each setting has a sensible default value. These defaults live in the file django/conf/global_settings.py.
Here’s the algorithm Django uses in compiling settings:
  • Load settings from global_settings.py.
  • Load settings from the specified settings file, overriding the global settings as necessary.
Note that a settings file should not import from global_settings, because that’s redundant.

Friday, November 28, 2014

cool tool in django: inspectdb

Say you have a legacy database and you want to put django on top of it.  One line will construct python models for the database structure:

python mysite/manage.py inspectdb > mysite/myapp/models.py
You can then clean up the result as explained in chpt 18 of the Djangobook: http://www.djangobook.com/en/2.0/chapter18.html

Thursday, November 20, 2014

adding commands to manage.py (if you don't like the shell < script.py trick)

Say you want to do something periodically that will affect your django environment (like check email).  You can schedule a task to do that using cron.  But that task needs to be run within your django environment.

One way to do that is to use

python manage.py shell < script.py

(or, if you have your permissions altered via chmod +x, 

./manage.py shell < script.py

)

It works.

If you want to get fancier, you can make a custom command for manage.py:

https://docs.djangoproject.com/en/dev/howto/custom-management-commands/

Wednesday, November 19, 2014

openshift

https://stackoverflow.com/questions/26871381/deploying-a-local-django-app-using-openshift

Thursday, November 13, 2014

csrf and request API

Notes to self on csrf protection in Django:

Django has built-in csrf protection if you use their decorators and form system.  In fact, by default you can't process a POST request without csrf protection.  Unfortunately, that protection acts as a wall against API POST requests not generated by the system.

The solution is simple: two views.  The view that you have to handle a GUI form needs the decorate.

A view that handles a curl or other programmatic request needs to be explicitly absolved of the decorator requirement.  Protection must come from authenticating each request instead of relying on a previous login--but that's not a hassle to an automated system.

from django.views.decorators.csrf import csrf_exempt, csrf_protect

@csrf_exempt
@csrf_protect

Any guess which view needs which decorator?

The form needs csrf protection because it is relying on a previous login.
The API authenticates every time and needs to be csrf_exempt.

Monday, November 10, 2014

The core of django authentication

You can find nice information here:
https://docs.djangoproject.com/en/dev/topics/auth/

and here:
https://docs.djangoproject.com/en/dev/topics/auth/default/

There is a lot to learn.  But for me the core of it is this:
  1. authentication comes built in by default with simple user objects that include username, password, and email
  2. if you have a username, a password, and an email address, you can set up a new user using
    from django.contrib.auth.models import User
    >>> user = User.objects.create_user('john', 'lennon@thebeatles.com', 'johnpassword') 
  3.  you can check the identity of a user in a view that receives a post request using
    from django.contrib.auth import authenticate
        username = request.POST['username']
        password = request.POST['password']
        user = authenticate(username=username, password=password)

Wednesday, November 5, 2014

nginx, postgresql, django, virtualenv

Nice tutorial here on Digital Ocean:
https://www.digitalocean.com/community/tutorials/how-to-install-and-configure-django-with-postgres-nginx-and-gunicorn

The instructions fell apart a bit once I got to the section configuring postgres.  Basically, when I expected to see a query about a role name it skipped that and started asking me about a password.

So for the configuration of postgres on Ubuntu, I recommend skipping over to https://help.ubuntu.com/community/PostgreSQL  .

After that I went back to the guide.

I found that since I was using python3 and because of a bug in 'pip' where it wants to install things globally, I had to change the

'pip install psycopg2' inside my virtual environment to
'pip3 install psycopg2' to get a local installation with python3.

Next, there is a depracated command in the tutorial that no longer works.
Replace
gunicorn_django --bind yourdomainorip.com:8001
with
 gunicorn myapp.wsgi:application --bind yourdomainorip:8001