Django community: RSS
This page, updated regularly, aggregates Community blog posts from the Django community.
-
Django under the hood: django REST framework - Tom Christie
(One of the summaries of a talk at the 2014 django under the hood conference). Tom Christie will give a two-part talk. The first is about django REST framework, the 3.0 beta will be out tomorrow. The second part is about API design in general. REST framework 3.0 They made a few fundamental changes in 3.0. Why did they do this? For instance for serializers. Serialization is from an object to a serialization format like json. It is is the deserialization that is the hard part: you have to do validation on incoming data and transform it if needed and convert it to an object. How it happened till now: serializer = ExampleSerializer(data=request.DATA, ...) serializer.is_valid() # serializer.object exists now This .is_valid() performs some validation on the serializer and it also instantiates an object. In 3.0, the validation still happens, but it only works on the serializer, not on an object. It returns validated data instead of an object. The validated data can afterwards be saved to an object explicitly. Another change is that there's a separate .create() and .update() method to split out the behaviour regarding creating new database objects or updating existing ones. The previous version determined itself whether … -
Django under the hood: Django ORM - Anssi Kääriäinen
(One of the summaries of a talk at the 2014 django under the hood conference). Anssi Kääriäinen is the "guardian of the ORM", he knows where all the bits and pieces are. He'll explain especially how QuerySet.filter() works. What is the Django ORM (object relational mapping)? It is a: Query builder. Query to object mapper. Object persistence. The operations the django ORM does are higher level than SQL by design. It doesn't have .join() and .group_by() operations exposed as an ORM operation. It'll do them behind the scenes, but you can't call them directly. Now about filters. For instance: Book.objects.filter(author__birth_date__year__lte=1981) This grabs the books with an author with a birth date's year that's 1981 or earlier. That year in the query isn't in django by default. Something new in django 1.7 are model transforms. This allows you to add such a specific year loookup: @some_registration_decorator class YearTransform(models.Transform): lookup_name = 'year' output_field = models.IntegerField() def as_sql(self, compiler, connection): # Some nice code that returns a bit of SQL Book.objects.filter(author__birth_date__year__lte=1981), what does it mean? Book is the model class. objects is the manager (models.Manager) filter is a method on the manager. It returns a models.QuerySet. It results in a models.sql.Query, which is … -
Django under the hood: django migrations - Andrew Godwin
(One of the summaries of a talk at the 2014 django under the hood conference). Andrew Godwin wrote south, the number one migrations framework for django. It is superseded by django's new built-in migrations, also written mostly by Andrew, hurray! The original idea was tho have a schema backend and hooks in the django ORM. The actual migration code would live outside of django in south2. In the end, everything is now in django. The original distinction between "schema backend stuff" and "the actual migrations" is still there in the code, however. The schema backend is relatively simple and straightforward; the migration part is hard and hairy. The migration part contains: operations, loader/graph, executor, autodetector, optimiser, state. He'll talk about some of them here. What about the old syncdb? It is a one-shot thing: you add tables and then you add the foreign keys. When migrating, you have dependencies. You cannot add foreign keys to tables you haven't added yet. There is automatic dependency-detecting code, now, but that was added quite at the last moment in the 1.7 beta 2... Basic dependencies means the obvious stuff. Some examples: Like creating a model before adding a foreign key to it. Most … -
Django under the hood: internationalisation - Jannis Leidel
(One of the summaries of a talk at the 2014 django under the hood conference). Jannis Leidel tells us about django internationalisation (or should that be internationaliZation? Well, Jannis confessed to changing it to an S on purpose :-) ) Jannis used to maintain django's translations a few years ago. Now he works on the mozilla developer network website, which has translations into more than 30 languages. He showed a picture of the Rosetta stone. That stone turned into a tool to transmit the previously-unknown egypt hyroglyphs to our times. It was the vessel that brought lots of Egypt culture to the present time. Isn't what we do with our Django websites something that similarly can transfer knowledge and culture? But there is a problem... 56% of the web is English. 5% is a native speaker. Only 20% of the world population has a basic knowledge of English! Another example? 0.8% of the web is Arabic. 4% is a native speaker. 0.1% is Hindi, with 5% native speakers. Multilingual and multicultural... There are huge differences. The future is a global web, with lots of fresh new internet users coming online in the coming years. Users that don't speak English and … -
Django under the hood: model _meta - Daniel Pyrathon
(One of the summaries of a talk at the 2014 django under the hood conference). Daniel Pyrathon talks about django's Model._meta and how to make it non-disgusting. He worked on it via the google summer of code program. His task was to "formalize the Meta object". The Meta API is an internal API, hidden under the _meta object within each model. It allows Django to inspect a model's internals. And.... it makes a lot of Django's model magic possible (for instance the admin site). What's in there? For instance some real metadata like "model name", "app name", "abstract?", "proxy model?". It also provides metadata and references to fields and reletaions in a model: field names, field types, etc. Which apps use it? The admin. Migrations. ModelForms. ... other developers. Developers have always used it, even though it is not an official API! Developers shouldn't be using it as it is internal. You really need it however for things like django-rest-framework. So... There's a big need for a real, public API. There is an important distinction between fields and related objects. A field is any field defined on the model, with or without a relation. Including foreign keys. Related objects are … -
Django under the hood: python templating - Armin Ronacher
(One of the summaries of a talk at the 2014 django under the hood conference). Armin Ronacher is the maker of many non-Django things such as Flask and Jinja2. His initial thought was "why are we even discussing templates in 2014"? In 2011 everyone started making single-page applications. But a year later it turned out not to be too good an idea: the cloud is much faster than your mobile phone. So server-side rendering is hip again. Django in 2005 had one of the few available template languages that were any good. It got imitated a lot, for instance in Jinja2. Which is fast. He doesn't really like looking at his own Jinja2 code. For him, it is pretty early Python code and it could be so much nicer. Feature-wise Jinja2 hasn't changed a lot in the recent years. There are a couple of problems, but they're not big enough to warrant a fix, as any fix will invariably break someone's template. The template language is mostly the same, but Jinja2's and Django's internal design differs greatly. Django has an AST ("abstract syntax tree") interpreter with made-up semantics. Jinja2 compiles into python code ("transpiles" he calls it). Rendering is mostly … -
Django under the hood one-day conference this friday
Hurray, tomorrow morning (friday) I'll go to Amsterdam for the first one-day django under the hood conference. The tickets sold out quickly, but I convinced the company where I work (Nelen & Schuurmans) to sponsor the event, so we had three tickets reserved for us :-) If, by this evil strategem, I managed to snatch away your ticket: I'll provide a little bit of atonement by providing summaries of all the talks. (I'll tag them with djangocon to keep them together with my other django summaries). We as Nelen & Schuurmans use a lot of Django, so we're happy to do a bit in return by sponsoring the conference. We're certainly not a pure IT company, as our main focus is water management. 40 of us are experts in ecology, water management, hydrology etcetera, 12 of us are programmers. And most of our work is done with Python and Django. That makes us one of the biggest Django shops in the Netherlands, which is fun for a company mainly associated with water :-) I'm looking forward to the talks tomorrow. The conference aims at giving us a better understanding of Django's internals so that we'll hopefully contribute more to Django's … -
We've Won Two W3 Awards for Creative Excellence on the Web!
We’re honored to announce that we’ve won two W3 Silver Awards for Creative Excellence on the Web. The awards were given in recognition of our homepage redesign and DjangonCon 2014. Many thanks to Open Bastion and, by extension, the Django Software Foundation for selecting us to build the DjangoCon website. Also many thanks to our hardworking team of designers, developers and project managers that worked on these projects: Dan, Daryl, David, Michael, Rebecca, and Trevor! Here’s a quote from Linda Day, the director of the Academy of Interactive and Visual Arts (the sponsors of the award): “We were once again amazed with the high level of execution and creativity represented within this year’s group of entrants. Our winners continue to find innovative and forward- thinking ways to push the boundaries of creativity in web design.” We’re particularly humbled to learn that there were 4,000 entries this year and to be in the company of winners like Google, ESPN, Visa, and Sony and the many other wonderful companies that received recognition. We’re looking forward to continuing to build great web experiences! The official press release: http://www.prweb.com/releases/2014-CaktusGroup/11/prweb1234567.htm -
Python desktop application development - Therry van Neerven
(Summary of a talk at a python meeting in Eindhoven, NL. I also gave a presentation (just the slides)). He's the author of the "sendcloud client", a desktop app of the company he works for. It steers a barcode scanner and prints out packaging slips. Why a desktop app? They wanted to make it look like a native windows app. But especially, they wanted to do two things that a browser app cannot do: printing without a dialog and scanning barcodes! So they needed to. Why in python? He wanted to learn more about python. And python allowed him to work quickly. There are quite a lot of libraries that helped him a lot (examples: requests, pywin32, pyusb). There are a couple of GUI frameworks for python. Some don't look too good, others are nicer. Kivy is a nice one. As is PyQt/PySide. PyQt might mean some licensing costs. Kivy has less features and it is not native looking. Kivy does have a more innovative UI as it is build on PyGame. It also supports android and ios. Tip by Therry: if you're interested, simply get your hands dirty. Try out something! Important for desktop applications is to "freeze" your … -
Using Amazon S3 to Store your Django Site's Static and Media Files
Storing your Django site's static and media files on Amazon S3, instead of serving them yourself, can make your site perform better. This post is about how to do that. We'll describe how to set up an S3 bucket with the proper permissions and configuration, how to upload static and media files from Django to S3, and how to serve the files from S3 when people visit your site. S3 Bucket Access We'll assume that you've got access to an S3 account, and a user with the permissions you'll need. The first thing to consider is that, while I might be using my dpoirier userid to set this up, I probably don't want our web site using my dpoirier userid permanently. If someone was able to break into the site and get the credentials, I wouldn't want them to have access to everything I own. Or if I left Caktus (unthinkable though that is), someone else might need to be able to manage the resources on S3. What we'll do is set up a separate AWS user, with the necessary permissions to run the site, but no more, and then have the web site use that user instead of your … -
[Scaling Celery] Sending Tasks To Remote Machines!
Celery:Celery is an asynchronous task queue/job queue based on distributed message passing. It hasCelery Application/Client/Producer: It adds tasks to the queue. Celery Worker/Server/Consumer: It executes the tasks given to it.Broker: It is just a transport mechanism which connects the above two.For simple tasks you can setup them in the same machine. But, if you have a lot of jobs which consume lot of resources, then you need to scale them. In this tutorial lets move our celery workers into a remote machine keeping producer and broker in same machine.What You Should Know:You should know how to setup up Celery and how to Create celery tasks: @app.task def add(x, y): return x + y Put that task in a queue: add.apply_async(args=[1,2])Run a worker to consume the task: celery worker -A my_app -l infoSending Tasks To Another Machine:On Machine A:1. Install Celery & RabbitMQ.2. Lets configure rabbitmq so that Machine B can connect to it.# add new usersudo rabbitmqctl add_user <user> <password># add new virtual hostsudo rabbitmqctl add_vhost <vhost_name># set permissions for user on vhostsudo rabbitmqctl set_permissions -p <vhost_name> <user> ".*" ".*" ".*"# restart rabbitsudo rabbitmqctl restart3. Create a new file remote.py with a simple task. Here we have broker installed in … -
Django Templating Language - Part IV
OK, for this exercise, assume I have a database table (in SQLite3) that contains student names and roll numbers. Let's look at this in steps.Import everything you need in views.py:import sqlite3from django.template import Template, ContextCreate a data structure that will hold your records:class Student (object): def __init__ (self, name, rno): self.name = name self.rno = rnoDefine your view and in it extract all records of student:def display (request): conn = sqlite3.connect ("/path/to/db/dbname.db") cur = conn.cursor () cur.execute ("select * from student") students = [] # Will store student records for row in cur: students.append (Student (row[0], row[1])) # Append to list 'students' an object of the class 'Student'Now it's time for the ol' Template/Context magic: t = Template ("/path/to/html/file/stud.html") c = Context ({'students':students}) html = t.render (c) return HttpReponse (html)But we're not done yet! We don't have the HTML file in which we define how the data is to be structured:<html> {% for student in students %} Roll … -
CSRF Token
I don't believe I didn't cover this before. Many of you (in fact all of you) must be getting a 'CSRF Token missing' error when you submit data using the POST method. First of all let me tell you what CSRF is.CSRF stands for Cross Site Request Forgery. When data is submitted using the GET method, it just gets encoded in the URL. But when it is submitted using the POST method it is sent directly to the servers. During this transfer if there is some bot snooping on that site, it can intercept the data and send it's own, infected data to the site.Anyway, coming back to Django, the solution to that error lies in Django's Templating Language. I myself am still trying to understand it. In the meantime, I found a temporary fix.NOTE: This is a temporary fix for development websites, and should not be deployed on production websites.Sorry for sneaking that on you like that. But it had to be done. You'll understand once I tell you how to (temporarily) fix it.Open settings.pyLook for a tuple named MIDDLEWARE_CLASSESYou'll see django.middleware.csrf.CsrfViewMiddleware inclulded in it.Comment that line out.Now do you see why this is so dangerous, even though it fixes the error? … -
Django Templating Language - Part III
We're finally here! We've already seen how to extract stuff from databases. Now let's put that to good use. Before we begin, let me explain two concepts here: Template and Context.Template is the front end, the looks of the page. This will mean the HTML (+CSS+jQuery+whatever else) code you write.Context means what you want to put in that page. In the earlier post, we had used the variable {{ name }}. Context will tell Python what value to pass to that variable.First things first. Let's import the necessary stuff.from django.template import Template, Contextfrom django.shortcuts import renderfrom django.http import HttpResponseNow what I do is pass HTML code as string to Template make it render it. While this is a neat method, I'm sure there are others out there that I don't know. So please comment so that I'll be able to learn other (maybe more efficient) ways to render templates.The way to do this would be to use file handling. So, in views.py:def showName (request): f1 = open ("/path/to/file/something.html") code = "" for i in f1.read (): code += iHope you understand what I did there. I opened a file called something.html, and returned everything in that file … -
Django Templating Language - Part II
Now let's look at some in-built tags. These will help you arrange data efficiently on your page. These are a lot like XML. However, the syntax is different and it is easier to manage.If you've noticed, it says Django Templating Language. Thus, as with every other language, this one also has control structures. Let's look at a few.(Note: We're still learning the language, and even at the end of this post the code will print raw data. I swear, we're really close to rendering data from Python. Just hang tight for one more post.)FOR:This simulates a for loop. It is useful when extracting data from a database and rendering on the page, especially when you don't know the number of rows that will be returned. This will simply iterate over the list and render everything.<html>{% for row in rows %} <b><i>{{ row }}</i></b><br>{% endfor %}</html>Let's look at this code step by step. First of all, let's map the for here with that in Python.In Python:for i in lstThus, i is row, the variable that we will use to iterate over the list of rows that the database returns. lst is rows, the list over which we need to iterate. You … -
Django 1.6
Hi all! Today let's explore Django's newest version. This won't be in incredible detail, however. The post would be too long. We'll just see an overview. Even as we speak the developers are working on versions 1.7 and 1.8Let's start at the top. Django 1.3Django 1.6Project directory structureThe structure is the same as we explored earlier. Once you open the project directory, you can see the list of apps, __init__.py, manage.py, settings.py, and urls.py.The structure here is slightly different. Once you open the project directory, there is another folder with the same name as your project. The manage.py is here too. Inside the other directory are all the apps and settings etc. While this provides a certain level of independence and atomicity, I personally am disappointed with this. I liked the older one better, and the new one takes some getting used to.SettingsThe settings file contains all settings imaginable, with the ability to add your own.The default settings file shipped with 1.6 is spartan and contains only those settings that an app absolutely needs to run. Rest all need to be added, e.g. TEMPLATE_DIRS, STATIC_DIRS etc.WSGI (Web Server Gateway Interface)No additional wsgi fileShipped with a default wsgi file (wsgi.py) to … -
Webcast: Creating Enriching Web Applications with Django and Backbone.js
Our technical director, Mark Lavin, will be giving a tutorial on Django and Backbone.js during a free webcast for O’Reilly Media tomorrow, November 6th, 1pm EST. There will be demos and a discussion of common stumbling blocks when building rich client apps. Register today! Here’s a description of his talk: "Django and Backbone are two of the most popular frameworks for web backends and frontends respectively and this webcast will talk about how to use them together effectively. During the session we'll build a simple REST API with Django and connect it to a single page application built with Backbone. This will examine the separation of client and server responsibilities. We'll dive into the differences between client-side and server-side routing and other stumbling blocks that developers encounter when trying to build rich client applications. If you're familiar with Python/Django but unfamiliar with Javascript frameworks, you'll get some useful ideas and examples on how to start integrating the two. If you're a Backbone guru but not comfortable working on the server, you'll learn how the MVC concepts you know from Backbone can translate to building a Django application." Register at O’Reilly Media. -
Win Free Copies of “Web Development with Django Cookbook”
Readers would be pleased to know that I have teamed up with Packt Publishing to organize a Giveaway of my book Web Development with Django Cookbook. Three lucky winners stand a chance to win an e-copy of the book. Keep reading to find out how you can be one of the lucky ones. Book OverviewImprove your skills by developing models, forms, views, and templatesCreate a rich user experience using Ajax and other JavaScript techniquesA practical guide to writing and using APIs to import or export data How to Enter?All you need to do is head on over to the book page and look through the product description of the book and drop a line via the comments below this post to let us know what interests you the most about this book. It’s that simple. PrizeWinners will get an e-copy of the Book. DeadlineThe contest will close on the 1st of December, 2014 at 00:00 GMT. Winners will be contacted by email, so be sure to use your real email address when you comment! -
uwsgi and uid
So recently, I moved home for this blog. It used to be on AWS EC2 and is now on Digital Ocean. I wanted to start from scratch so I started on a blank new Ubuntu 14.04 and later rsync'ed over all the data bit by bit (no pun intended). When I moved this site I copied the /etc/uwsgi/apps-enabled/peterbecom.ini file and started it with /etc/init.d/uwsgi start peterbecom. The settings were the same as before: # this is /etc/uwsgi/apps-enabled/peterbecom.ini [uwsgi] virtualenv = /var/lib/django/django-peterbecom/venv pythonpath = /var/lib/django/django-peterbecom user = django master = true processes = 3 env = DJANGO_SETTINGS_MODULE=peterbecom.settings module = django_wsgi2:application But I kept getting this error: Traceback (most recent call last): ... File "/var/lib/django/django-peterbecom/venv/local/lib/python2.7/site-packages/django/db/backends/postgresql_psycopg2/base.py", line 182, in _cursor self.connection = Database.connect(**conn_params) File "/var/lib/django/django-peterbecom/venv/local/lib/python2.7/site-packages/psycopg2/__init__.py", line 164, in connect conn = _connect(dsn, connection_factory=connection_factory, async=async) psycopg2.OperationalError: FATAL: Peer authentication failed for user "django" What the heck! I thought. I was able to connect perfectly fine with the same config on the old server and here on the new server I was able to do this: django@peterbecom:~/django-peterbecom$ source venv/bin/activate (venv)django@peterbecom:~/django-peterbecom$ ./manage.py shell Python 2.7.6 (default, Mar 22 2014, 22:59:56) [GCC 4.8.2] on linux2 Type "help", "copyright", "credits" or "license" for more information. (InteractiveConsole) >>> from … -
uwsgi and uid
So recently, I moved home for this blog. It used to be on AWS EC2 and is now on Digital Ocean. I wanted to start from scratch so I started on a blank new Ubuntu 14.04 and later rsync'ed over all the data bit by bit (no pun intended). When I moved this site I copied the /etc/uwsgi/apps-enabled/peterbecom.ini file and started it with /etc/init.d/uwsgi start peterbecom. The settings were the same as before: # this is /etc/uwsgi/apps-enabled/peterbecom.ini [uwsgi] virtualenv = /var/lib/django/django-peterbecom/venv pythonpath = /var/lib/django/django-peterbecom user = django master = true processes = 3 env = DJANGO_SETTINGS_MODULE=peterbecom.settings module = django_wsgi2:application But I kept getting this error: Traceback (most recent call last): ... File "/var/lib/django/django-peterbecom/venv/local/lib/python2.7/site-packages/django/db/backends/postgresql_psycopg2/base.py", line 182, in _cursor self.connection = Database.connect(**conn_params) File "/var/lib/django/django-peterbecom/venv/local/lib/python2.7/site-packages/psycopg2/__init__.py", line 164, in connect conn = _connect(dsn, connection_factory=connection_factory, async=async) psycopg2.OperationalError: FATAL: Peer authentication failed for user "django" What the heck! I thought. I was able to connect perfectly fine with the same config on the old server and here on the new server I was able to do this: django@peterbecom:~/django-peterbecom$ source venv/bin/activate (venv)django@peterbecom:~/django-peterbecom$ ./manage.py shell Python 2.7.6 (default, Mar 22 2014, 22:59:56) [GCC 4.8.2] on linux2 Type "help", "copyright", "credits" or "license" for more information. (InteractiveConsole) >>> from … -
Django 1.7 et écriture de tests, petites explorations
Je me suis enfin lancé dans l’écriture d’une app django gérant les badges (ou les succès si vous préférez). L’objectif étant de pouvoir réécrire de zéro histoires de rôlistes. L’idée était de tenter de faire une vraie app django, en mode réutilisable, histoire que peut-être des gens puissent trouver intéressant de l’utiliser. Je me suis retrouvé avec deux problèmes concernant mes tests : Souvent on gagne un badge quand on a créé suffisamment de chose (comme des checkin, des billets de blogs ou des contributions diverses). Sauf que je ne voulais pas créer dans mon app des models ne servant à rien, juste pour pouvoir en créer lors de mes tests. Je voulais pouvoir créer des badges se gagnant sur un critère du style ‘être venu un certain nombre de fois sur une URL.’ Donc mettre en place des décorateurs sur des vues. Mais là encore, je ne voulais pas avoir à créer des vues dans mon application rien que pour les tests. Au final, en lisant un peu de doc, j’ai réussi à faire ce que je voulais. Tester un décorateur sans créer des vues inutiles dans son app. Je savais déjà comment forger des requests avec la RequestFactory. … -
Shout-out to eventlog
If you do things with the Django ORM and want an audit trails of all changes you have two options: Insert some cleverness into a pre_save signal that writes down all changes some way. Use eventlog and manually log things in your views. (you have other options too but I'm trying to make a point here) eventlog is almost embarrassingly simple. It's basically just a model with three fields: User An action string A JSON dump field You use it like this: from eventlog.models import log def someview(request): if request.method == 'POST': form = SomeModelForm(request.POST) if form.is_valid(): new_thing = form.save() log(request.user, 'mymodel.create', { 'id': new_thing.id, 'name': new_thing.name, # You can put anything JSON # compatible in here }) return redirect('someotherview') else: form = SomeModelForm() return render(request, 'view.html', {'form': form}) That's all it does. You then have to do something with it. Suppose you have an admin page that only privileged users can see. You can make a simple table/dashboard with these like this: from eventlog.models import Log # Log the model, not log the function def all_events(request): all = Log.objects.all() return render(request, 'all_events.html', {'all': all}) And something like this to to all_events.html: <table> <tr> <th>Who</th><th>When</th><th>What</th><th>Details</th> </tr> {% for event in … -
Shout-out to eventlog
If you do things with the Django ORM and want an audit trails of all changes you have two options: Insert some cleverness into a pre_save signal that writes down all changes some way. Use eventlog and manually log things in your views. (you have other options too but I'm trying to make a point here) eventlog is almost embarrassingly simple. It's basically just a model with three fields: User An action string A JSON dump field You use it like this: from eventlog.models import log def someview(request): if request.method == 'POST': form = SomeModelForm(request.POST) if form.is_valid(): new_thing = form.save() log(request.user, 'mymodel.create', { 'id': new_thing.id, 'name': new_thing.name, # You can put anything JSON # compatible in here }) return redirect('someotherview') else: form = SomeModelForm() return render(request, 'view.html', {'form': form}) That's all it does. You then have to do something with it. Suppose you have an admin page that only privileged users can see. You can make a simple table/dashboard with these like this: from eventlog.models import Log # Log the model, not log the function def all_events(request): all = Log.objects.all() return render(request, 'all_events.html', {'all': all}) And something like this to to all_events.html: <table> <tr> <th>Who</th><th>When</th><th>What</th><th>Details</th> </tr> {% for event in … -
Passing parameters to Django admin action
This post will show how to pass parameters to custom Django admin actions. This post assumes that you have an idea of Django actions. Django provides a default admin action which is 'Delete selected rows'. Changelist page for all the models registered with admin has this action available. This action allows to select multiple rows and delete them in a single POST request. Problem statement We want to allow following Django action from admin. There is a model called Instrument. It has a field price Allow selecting multiple rows for this model and update the value of price for selected rows. Price should not be hardcoded. Admin should be able to enter the price. We should be able to achieve something like: Solution Setup the project first. Setup project Start a Django project inside virtual environment /tmp $ mkvirtualenv custom-actions (custom-actions)/tmp $ django-admin.py startproject actions (custom-actions)/tmp/actions $ python manage.py startapp instruments Writing the model in instruments/models.py class Instrument(models.Model): name = models.CharField(max_length=100) price = models.IntegerField() def __unicode__(self): return self.name Add instruments to INSTALLED_APPS Run syncdb (custom-actions)/tmp/actions $ python manage.py syncdb Register this model with admin in instruments/admin.py from django.contrib import admin from .models import Instrument admin.site.register(Instrument) You should be able to … -
Travis and coveralls for private repo
Before we begin, i recommend you to read this first Continous integration with travis and coveralls.io for Django apps. Here is how .travis.yml example file looks like: language: python python: - 2.7 install: - pip install -r requirements.txt - pip install coveralls script: coverage run manage.py test after_success: coveralls Setting up coveralls for private repositories requires you to add just one more file .coveralls.yml. 1) Create a .coveralls.yml and make sure it resides in your project's root directory. 2) Add the following to this file: service_name: travis-pro repo_token: **** service_name is to specify where Coveralls should look to find additional information about your builds. You can get the repo_token from your repository's page on Coveralls, if you have the admin privileges. This is to tell which project on Coveralls your project maps to. Make sure your repo_token remains secret and do not add this to your public repository. 3) Add the file, commit it and make a git push. 4) If everything is OK you should see some thing like the below in your travis build: Submitting coverage to coveralls.io... Coverage submitted! Job #22.1 https://coveralls.io/jobs/54864565 Thats it now get a coverage badge from coveralls and add this badge in your …
