What's new in Django community blogs?

Continuously rebuild your project

[Archived Version] □ Published at Writing on django | David Winterbottom

New developers joining a project will often find that the project won't build cleanly on their machine, and hours of time will be sunk into setting up the project so work can start. This is sad and expensive for all concerned.

This is a particular menace in agencies (or anywhere with lots of small projects) where a large team of developers need to jump between projects. Tools like Vagrant and Docker can help but aren't the panacea they first seem to be [*].

Counter this by using continuous integration to build your project from scratch. Then any changes that break the build process (such as database schema changes not applying correctly) will be spotted early. New team members will ...


Django adding custom widget to Django Admin

Jul 29 2014 [Archived Version] □ Published at Programmer blog under tags  admin button custom django element

Sometimes you need to get out of standard behaviour of your Django admin. It means expanding its functionality with custom things. In our case we have a model that we want to add a custom html element. Button that must load something via AJAX from another place to be exact.
We have a typical Django polls application for simplicity. Here is its structure:

First of all we need to create a structure. So here comes our model:
# models.py
from django.db import models

class Poll(models.Model):
question = models.CharField(max_length=200)
pub_date = models.DateTimeField('date published')
We have to have our django application admin configuration to display that model:
# admin.py
from django.contrib import admin
from polls.models import Poll


admin.site.register(Poll)
It will look in Django admin like so:
You can see polls available here in admin. You can do all the typical things with Polls model. Add/Delete/Edit... Using standard Django features. Imagine we have something on that polls model that we need to expand. Say, we need a button to visit external site here, made like an additional edit field. Imagine we need to take something on external website. We can post something to that website from our filled django admin form. To do that we need to create a custom form field. I have not found any standard widgets to do that. It is required to write our own field and attach it to the Django admin form.
We do not need own field here. Just a widget. Widgets are standard Django types. It is possible to read wide description of them in the official documentation: Django Widgets. I wont discuss here best ways to implement this task and there might be better ones. However I have chosen a form widget for simplicity.

It is required to have a model expansion form and a custom widget in order to do so. Registration fo that for m in django admin setup is also required. Lets implement this.
Starting with a form and a widget:
# forms.py
from django import forms
from django.utils.safestring import mark_safe
from django.template.loader import render_to_string

from polls.models import Poll


class ButtonWidget(forms.Widget):
template_name = 'auth_button_widget.html'

def render(self, name, value, attrs=None):
context = {
'url': '/'
}
return mark_safe(render_to_string(self.template_name, context))


class PollsForm(forms.ModelForm):
button = forms.CharField(widget=ButtonWidget)

class Meta:
model = Poll
It is located in a newly created file - forms.py at the django app - polls directory. Here we have a custom written widget that inherits a typical default Django widget (forms.Widget). we have provided it a template - auth_button_widget.html and a custom render() method that provides extra context for that template.
Next comes the PollsForm class with a custom button field that uses that widget. Note here Meta for that model is specified, indicating we are adding that field to the Polls model add/edit form.
Template, residing in all django templates directory will look like so:
{# auth_button_widget.html #}
<a href="{{ url }}">Go Button</a>
We have our form and widget and a template to render that form element. Time to use that form.

Using this form means modifying our admin.py file and registering custom model admin there. It will use our custom form and a widget. Resulting admin.py will look like this:
# admin.py
from django.contrib import admin
from polls.models import Poll
from polls.forms import PollsForm


class PollsAdmin(admin.ModelAdmin):
form = PollsForm

admin.site.register(Poll, PollsAdmin)
Resulting change will add a custom form to edit or add the Polls model, containing our custom button field. It will look something like so:

Notice the button we have add here. Its just a simple HTML element that needs to be styled and animated by some CSS and JS. It can be done adding Media to our form widget. Resulting new widget will look like this:
# forms.py (partially)
class ButtonWidget(forms.Widget):
template_name = 'auth_button_widget.html'

class Media:
js = (
'js/admin_button_script.js',
)
css = {
'all': (
'css/admin_button_widget.css',
)
}

def render(self, name, value, attrs=None):
context = {
'url': '/'
}
return mark_safe(render_to_string(self.template_name, context))
Its a registration of static files to use in your widget. They will represent a scripting and styling for that field and will be included to the page of django admin form automatically.
For this to function you have to have django static files configured

Content of scripts and styles are out of the scope of this article. Main idea here is to highlight a proper way to add and write a custom widget from the backend perspective.

Comments, suggestions?


https://github.com/rosarior/awesome-django

Jul 28 2014 [Archived Version] □ Published at re.nooble under tags  apps django django projects

https://github.com/rosarior/awesome-django:


What do apps look like in VR?

Jul 27 2014 [Archived Version] □ Published at Eric Florenzano's Blog

What do apps look like in VR?

Jul 27, 2014

Let's assume that VR or augmented reality is the future. It's a leap to make that assumption, because who knows how the marketplace will react to VR, but let's make the assumption anyway because it's interesting. What do apps look like in this future VR world?

Maybe it works like apps do on the desktop, where there's an operating system interface, and apps have window boundaries that they have to fit within. This is the easier choice, since apps and websites already understand this concept and are able to be mapped into VR without a complete rewrite. Users are already understand how to interact with their computer in this way, so it's easy for people familiar with desktop computing to get going (and a lot of people are.) In fact, there is a cool demo of this working in Linux already.

This would be a bummer, if this is the way things go. While apps are easily mapped into this desktop environment, they're written without VR in mind. They don't take advantage of the third dimension: depth. They don't take into account your position or your head's tilt. (There's an argument to be made that they rarely even take advantage of two dimensions. Most apps and websites tend to primarily scroll in one direction.) In this scenario, the win is that you get more screen real estate to work with than you have with a monitor, and you get more spacial awareness than you have today using something like OSX's Mission Control. To me, this would be like Microsoft's first attempts at tablets, where they shipped it with a stylus and treated that as a mouse pointer. That is, it worked, and nothing needed to be rewritten, but it wasn't compelling enough for users.

Maybe this operating system interface will be written though, because whoever controls it will make a lot of money. A lot. Also we know by now that worse is better. But no, I think we're going to see it play out more like how games work on the desktop, and how both games and apps do on smartphones and consoles. Remember, VR is being driven primarily by gaming right now, so games will play a large role in setting expectations for how apps will work in VR. So let's add this second assumption to our list: apps in VR will take over the entire field of view, like games do.

Every computing platform that we use today has an understood interaction model. We have buttons you can tap, surfaces you can scroll with your mouse or finger, menu/tab/action bars, launchers, app windows, etc. Which of these things make the transition to VR, and what new interaction models need to be (re?)invented? For example, several Oculus demos are experimenting with letting users "click" on buttons by having the user "look" at the button with a pointer for a certain amount of time. This allows users to interact with the app without even using their hands. Even if this exact technique doesn't take hold (it's somewhat annoying to have to wait for a timeout in order to "click" on something), it's the experimentation that's happening that's exciting.

Notice that I put "click" in quotes. Because there's no clicking in that technique. Nor is there any tapping. We even have to invent new words to talk about this stuff!

Now in our hypothetical future we've got apps in VR and they take up the screen. Facebook bought Oculus, so let's talk about a Facebook property: Instagram. What does an Instagram app look like in VR? Is it a timeline in a narrow window, as it is today? Maybe clicking on a photo zooms in on it. Or maybe the timeline shows photos going down vertically, and all the comments are lined up horizontally without needing to tap into a detail view. Maybe photos aren't displayed linearly from top to bottom, but more like a huge Pinterest board projected inside a planetarium-like dome.

So the question of "What do apps look like in VR?" is not hypothetical, it's a real question that we're in the process of finding out the answer to. Maybe VR doesn't take off, or maybe worse really is better and the 3D desktop interaction model wins. But I don't think so. I think someone or some group is going to figure out how apps are supposed to look and work on VR, and that's going to be a big deal.


Django 1.7 release candidate 2

Jul 27 2014 [Archived Version] □ Published at The Django weblog

It's almost here!

Today we're pleased to announce the second release-candidate package for Django 1.7. This release has been quite a while in the making, and includes several major new features. There's a new built-in schema-migration framework, improved tools for validating and checking your projects, a complete refactor of the way Django identifies and loads your applications, and support for custom database lookups.

And that's just the biggest highlights; for a full rundown of features, see the in-development 1.7 release notes.

As with all pre-release packages, this is not for production use. But if you'd like to take some of the new features for a spin, or to help find and fix bugs (which should be reported to the issue tracker), you can grab a copy of the release-candidate package from our downloads page. And as always, signed MD5 and SHA1 checksums of the 1.7 release-candidate package are available.

Note regarding release keys

For many years, every Django package has been accompanied by signed checksums, for verification purposes; more recently, starting with the 1.6 release series, our uploads to the Python Package Index have been trying out the option to upload signed packages, and signing our release tags on GitHub.

Historically only two keys have been used for this signing; James Bennett's key, ID 0x3684C0C08C8B2AE1, and Jacob Kaplan-Moss' key, ID 0x69666DFEB00E963E. James' key is a 1024-bit DSA key, and is increasingly inappropriate for this type of use.

Moving forward, there will be two changes relevant to security-conscious users and distributors of Django:

  1. The list of authorized release keys is now formalized, and appears in the Django releasers file. Any key listed in that file is authorized to issue Django releases.
  2. James' old key has been deprecated and will no longer be used to issue releases; a new 4096-bit key, ID 0x2D9266A6808FE067, has been generated and signed by members of the core team and James' old key, and added to the releasers file. James' old key should be considered revoked for purposes of signing Django releases and security notifications. It is expected that in the not-too-distant future (likely after Django 1.7.1) that old key will also be formally revoked using a GPG revocation certificate, following a transition period of a few releases using the new key. This revocation will be publicly announced when it occurs.

Django 1.7 RC 2 is the first release using James' new key.


How to solve CORS IE font issues with Amazon Cloudfront

Jul 25 2014 [Archived Version] □ Published at Holovaty.com

I've been wrestling with this for a while, and I finally found a fix! Here's a quick post for developers searching for the solution...

The problem

If you use Amazon Cloudfront to serve web fonts (.ttf, .woff, .eot, etc.) from your Amazon S3 bucket (as I do for Soundslice), Internet Explorer will likely refuse to load the fonts, giving this error message:

CSS3117: @font-face failed cross-origin request. Resource access is restricted.

This happens because your media files on Cloudfront are on a separate domain than your site, and Internet Explorer doesn't like the cross-domain requests for security reasons.

The solution

The solution is to get CORS working with Amazon S3, then to get Cloudfront to forward the appropriate headers. Amazon only recently made this possible (less than a month ago, as of this writing), so there's not a lot of documentation on it.

Here's how, step by step:

First, go to the web interface for your S3 bucket, click "Properties," then "Permissions," then "Edit CORS Configuration." Enter this and save it:

<CORSConfiguration>
    <CORSRule>
        <AllowedOrigin>*</AllowedOrigin>
        <AllowedMethod>GET</AllowedMethod>
    </CORSRule>
</CORSConfiguration>

Note: if you're particularly security-conscious, you may want to lock this down more. In this example, I'm allowing access to all files from any origin. Here's a post with an example of a locked-down version of the S3 CORS settings.

Next, go to the web interface for your Cloudfront "distribution," and click "Distribution Settings," then the "Behaviors" tab. Select the behavior (assuming you have only one) and click "Edit."

For "Forward Headers," change it from "None (Improves Caching)" to "Whitelist." A "Whitelist Headers" section will appear. Add "Origin" to this list. This tells Cloudfront to take the "Origin" header into account when caching.

Here's a step that I'm not certain is necessary, but I did it anyway: next to "Allowed HTTP Methods," select "GET, HEAD, PUT, POST, PATCH, DELETE, OPTIONS" instead of "GET, HEAD".

Finally, rename your font files for good measure, so that Cloudfront treats them as new files. I did all of the above steps and was still getting the IE error, but when I renamed the font files, it started working. Cloudfront is really good at caching. :-)

That's it! Enjoy your fully working web fonts in IE, served by S3/Cloudfront.


Rethinking Web Frameworks in Python

Jul 25 2014 [Archived Version] □ Published at TravisSwicegood.com

Listening to @pragdave talk about Exlir’s pipes he was talking about how these two styles, while fundamentally the same, have vastly different readability:

"".join(sorted(list("cat")))

Try to explain that line of code to someone who doesn’t program. You start by telling them to just skip over everything until they hit the center, that’s the starting point. Then, you work you way back out, with each new function adding one more layer of functionality.

As programmers, we’ve taught ourselves how to read that way, but it isn’t natural. Consider this pseudo code:

"cat" | list | sorted | join

This code requires that you simply explain what | does, then it goes naturally from one step to the next to the next and the final result should be the joined sorted string.

Seeing that code example got me thinking about some of the discussions I’ve had with new programmers as I explain how Django works. I start explaining the view, to which I’m almost always asked “ok, how does the request know what view to execute?” I follow this up by moving over to URL route configuration. After that’s explained, I’m asked “ok, so how do requests come in and get passed through that?” And this goes on, until we’re standing on top of 20 turtles looking down at the simple Hello World we wrote.

In that vein, what would a web framework look like that started with the premise that a regular, non-programmer should be able to read it. Here’s an idea:

def application(request):
    request > get("/") > do_response()
    request > get("/msg") > say_hello()

So, you define an application function that takes a request, that request is then run through a get function with a route, and if that matches it would finally pass off to a final function that does something that would generate the response.

To that end, I’ve hacked up this simple script that uses werkzeug to do a simple dispatch. The implementation is a little odd and would need to be cleaned up to actually be useful, but I think I could be on to something. Just imagine this syntax:

request > get("/admin") > require_login > display_admin()

At this point, require_login can return early if you’re not logged, and display_admin could repeat the entire application style and be “mounted” on top of the /admin route and respond to request.path that is slightly different.

request > get("/users/") > display_user_list()
request > get("/user/<id>/") > display_user()
request > post("/user/<id>/") > edit_user()
# or...
request > route("/user/<id>/", methods=["GET", "POST"]) > handle_user()

Any thoughts?


Want to work for Eventbrite? (part 2)

Jul 23 2014 [Archived Version] □ Published at pydanny under tags  django django-rest-framework eventbrite python

For various reasons I had to change some things about my Eventbrite test. The new version is listed here and the previous blog post has been updated:

104, 116, 116, 112, 115, 58, 47, 47, 103, 105, 115, 116, 46, 103, 105, 116, 104, 117,
98, 46, 99, 111, 109, 47, 112, 121, 100, 97, 110, 110, 121, 47, 97, 56, 55, 100, 57,
54, 49, 54, 102, 49, 50, 55, 52, 48, 48, 97, 57, 55, 97, 52

Good luck!


Just Testing upLynk

Jul 23 2014 [Archived Version] □ Published at Nerdy Dork under tags  programming &amp; internet

So as of Monday I started a new job with upLynk/Verizon. I’m just learning about this system and going through tutorials. Here is my first test:

The post Just Testing upLynk appeared first on Dustin Davis.


Want to work for Eventbrite?

Jul 23 2014 [Archived Version] □ Published at pydanny under tags  django django-rest-framework eventbrite python

Join me, Andrew Godwin (South, Django migrations), Simon Willison (co-founder of Django, co-founder of Lanyrd), and many other talented people at Eventbrite. We have great challenges, the kind that inspire you to rise to the occasion. We need you to help us overcome them.

I should mention that Eventbrite is committed to giving back to the community. Most notably Eventbrite just contributed £5000 to the Django Rest Framework kickstarter, or about US$8500!! We're a frequent sponsor of events around the world. It doesn't stop there, as Eventbrite managers during the discussion of any tool outside our domain of running events will ask: "When can we open source this?"

As someone who loves working on open source, Eventbrite is the place to be. I say this because I know what we're planning to do in the future. If you join us, you'll find out sooner rather than later. ;)

What's Eventbrite like as a company? Well, we're rated in the top 20 of best places to work in the United States. We get full benefits, free lunch, educational opportunities, and much more. In addition, I have to say that my co-workers are friendly, intelligent, always learning, and love to do things the right way, even if it's the hard way.

Applying for Eventbrite Python positions

Sure, you could go to the official Eventbrite job site, but this method is a fun challenge that proves to us you have the basics down. All you need to do is pass this little test of mine. If you fail any portion of this test we can't consider hiring you.

  1. Can you work in San Francisco (USA), Nashville (USA), or Mendoza (Argentina)?
  2. Do you know Python? Sorry, we aren't looking for Foxpro coders. Experience with git-scm, CSS, JavaScript, Django, and MySQL definite pluses.
  3. Are you able to communicate in both written and verbal English?
  4. Are you a coder? I will throw away anything from a recruiter.
  5. Can you figure out how to contact me? Eventbrite doesn't believe in testing applicants with puzzle logic questions. Instead, we ask you meaningful technical questions or to solve a coding problem. With that in mind, use the following to contact me:
104, 116, 116, 112, 115, 58, 47, 47, 103, 105, 115, 116, 46, 103, 105, 116, 104, 117,
98, 46, 99, 111, 109, 47, 112, 121, 100, 97, 110, 110, 121, 47, 97, 56, 55, 100, 57,
54, 49, 54, 102, 49, 50, 55, 52, 48, 48, 97, 57, 55, 97, 52

hints: chr, problem solving, list comprehension

Note: This is the updated test that is identical to my next blog post.

Good luck!

http://pydanny.com/static/eventbrite_logo_gradient_v2.png


Contributing Back to Symposion

Jul 21 2014 [Archived Version] □ Published at Caktus Blog

Recently Caktus collaborated with the organizers of PyOhio, a free regional Python conference, to launch the PyOhio 2014 conference website. The conference starts this weekend, July 26 - 27. As in prior years, the conference web site utilizes Eldarion’s Symposion, an opensource conference management system. Symposion powers a number of annual conference sites including PyCon...


My First Docker

Jul 16 2014 [Archived Version] □ Published at TravisSwicegood.com

I’ve been told I should check out Docker for over a year. Chris Chang and Noah Seger at the Tribune were both big proponents. They got excited enough I always felt like I was missing something since I didn’t get it, but I haven’t had the time to really dig into it until the last few weeks.

After my initial glance at it, I couldn’t see how it was better/different than using Vagrant and a virtual machine. Over the last few weeks I’ve started dipping my toes in the Docker waters and now I’m starting to understand what the big deal is about.

Docker versus VM

I’ve been a longtime fan of Vagrant as a way to quickly orchestrate virtual machines. That fits my brain. It’s a server that’s run like any other box, just not on existing hardware. Docker goes a different route by being more about applications, regardless of the underlying OS. For example, let’s talk about my npm-cache.

Using this blog post as a base, I wanted to create an easily deployable nginx instance that would serve as a cache for npmjs.org. The normal route for this is to get nginx installed on a server and set it up with the right configuration. You could also add it to an existing nginx server if you have one running.

Docker views something like this npm-cache less as the pieces of that infrastructure (nginx and the server its on) and more as an application unto itself with an endpoint that you need to hit. Its a subtle shift, but important in a service-oriented world.

Getting Started

Docker has been described as Git for deployment, and there’s a reason. Each step of a deployment is a commit unto itself that can be shared and re-orchestrated into something bigger. For example, to start my npm-cache, I started by using the official nginx container.

The nginx container can be configured by extending it and providing your own configuration. I used in the configuration from yammer, created a few empty directories that are needed for the cache to work, then I was almost ready to go. The configuration needed to know how to handle rewriting the responses to point to the caching server.

Parameterizing a Container

This is where things got a little tricky for me as a Docker newbie. nginx rewrites the responses from npm and replaces registry.npmjs.org with your own host information. Starting the container I would know that information, but inside the running container, where the information was needed, I wouldn’t know unless I had a way to pass it in.

I managed this by creating a simple script called runner that checks for two environment variables to be passed in: the required PORT and the optional HOST value. HOST is optional because I know what it is for boot2docker (what I use locally). PORT is required because you have to tell Docker to bind to a specific port so you can control what nginx uses.

My runner script outputs information about whether those values are available, exiting if PORT isn’t, modifies the /etc/nginx.conf file, then starts nginx. The whole thing is less than 20 lines of code and could probably be made shorter.

Deploying with Docker

I got all of this running locally, but then the thought occurred to me that this shouldn’t be that hard to get running in the cloud. We use Digital Ocean a lot at Continuum, so I decided to see what support they have for Docker out-of-the-box. Turns out, you can launch a server with Docker already configured and ready to run.

With that, deploying is ridiculously easy. I started a small box with Docker installed, then used ssh to connect to the box, and ran the following commands:

docker pull tswicegood/npm-cache
export PORT=8080
docker run -d -e HOST=<my server's IP> -e PORT=$PORT -p $PORT:80 tswicegood/npm-cache

That’s it! Including network IO downloading the npm-cache, I spent less than five minutes from start to finish to get this deployed on a remote server. The best part, I can now use that server to deploy other infrastructure too!

Conclusion

Making deployment of a piece of infrastructure this easy is not a simple problem. I’m sure there are all sorts of edge cases that I haven’t hit yet, but kudos to the Docker team for making this so easy.

Check out Docker if you haven’t. The Getting Started tutorial is really great.


Building, Maintaining and Scaling Projects

Jul 15 2014 [Archived Version] □ Published at pydanny under tags  nasa whartonwc

These are the slides from the talk I gave today at the Wharton Web Conference.


July 2014 ShipIt Day Recap

Jul 14 2014 [Archived Version] □ Published at Caktus Blog

This past Friday we celebrated another ShipIt day at Caktus. There was a lot of open source contribution, exploring, and learning happening in the office. The projects ranged from native mobile Firefox OS apps, to development on our automated server provisioning templates via Salt, to front-end apps aimed at using web technology to create interfaces...


Deferred Tasks and Scheduled Jobs with Celery 3.1, Django 1.7 and Redis

Jul 14 2014 [Archived Version] □ Published at GoDjango Screencasts and Tutorials

Setting up celery with Django can be a pain, but it doesn't have to be. In this video learn what it takes to setup Celery for deferred tasks, and as your cron replacement. We will use Celery 3.1 and Django 1.7 both introduce changes you need to be aware of.
Watch Now...


django-planet aggregates posts from Django-related blogs. It is not affiliated with or endorsed by the Django Project.

Social Sharing

Feeds

Tag cloud

admin administration advanced ajax apache api app appengine app engine apple aprendiendo python architecture articles asides audrey authentication automation backup bash basics bitbucket blog blog action day book books buildout business cache celery celerycrawler challenges cherokee choices class-based-views cliff cloud code coding couchdb css d data database databases debian deploy deployment developers development digitalocean django djangocon django-rest-framework django templates documentation dojango dojo dreamhost dughh eclipse education email encoding error events extensions fabric facebook family fashiolista fedora field filter fix flash flask form forms friends gae gallery games geek general gentoo gis git github gnome google google app engine gunicorn hackathon hacking hamburg heroku holidays hosting howto how-tos html http i18n image install intermediate internet ios iphone java javascript jobs journalism jquery json justmigrated linear regression linkedin linode linux mac machine learning math memcached mercurial meta migration mirror misc model models mod_wsgi mongodb mozilla mvc mysql nelenschuurmans newforms news nginx nosql ogólne open source open-source orm osx os x ottawa paas performance philosophy php pi pil pinax pip piston planet plone plugin pony postgres postgresql ppoftw private programmieren programming programming &amp; internet project projects pycon pygrunn pyladies pypi pypy python python3 quick tips quora rabbitmq rails rant ratnadeep debnath redis release request resolutions rest review rtnpro ruby science script security server setup simple smiley snaking software software development south sql ssh ssl static storage supervisor svn sysadmin tag talk nerdy to me tastypie tdd techblog technical technology template templates test testing tests tip tools tornado transifex travel tumbles tutorial twitter twoscoops typo3 ubuntu uncategorized unicode unix usergroup uwsgi uxebu virtualenv virtualenvwrapper web web 2.0 web design &amp; development webdev web development webfaction whoosh windows wordpress work