What's new in Django community blogs?

We’re launching a Django code school: Astro Code School

Jan 26 2015 [Archived Version] □ Published at Caktus Blog

One of the best ways to grow the Django community is to have more high-quality Django developers. The good news is that we’ve seen sharply increasing demand for Django web applications. The challenge that we and many other firms face is that there’s much higher demand than there is supply: there aren’t enough high-quality Django...

[Django CMS] Adding plugins inside plugins programatically

Jan 23 2015 [Archived Version] □ Published at Programmer blog under tags  add backend cms django html

I have a task to migrate a website. Old one is plain HTML and new one is Django CMS. I have a script that parses an HTML page from old website in to CMS page and places it into proper place.
Task is to migrate all the page content (that is a CMS TextPlugin) into an interlinked pages setup. Like we have text

<p>blah blah </p><a href="/page/url">Text</a><p> some other text</p>

And I need to change it into CMS LinkPlugin that is nested inside of the TextPlugin. It have become a common standard in the Django CMS world now. Note we need to have a LinkPlugin because of the requirement to interlink pages.
E.g. <a href="/page/url"> is a link to CMS Page object.

The solution is divided into two major parts. First we need to have the link plugin added to a placeholder of the text plugin. It must also be nested by the TextPlugin, like Django CMS admin web UI would do.  So our plugin would look somehow like this in the CMS Page admin:
And the second is modifying the Text Plugin instance itself with placing Link plugin placeholders instead of <a></a> tags we have there.
In this particular example we have a placeholder named "content" and a page containing only one TextPlugin with text in it. We need to modify that text.
First we need to create an instance of a CMSPlugin that is attached to a proper placeholder and is nested in our TextPlugin instance. Creating a Link plugin (an instance of a configuration for that CMS plugin in practice) is a next step to achieve this.
That will be the part 2 of this article. Coming soon.

Why I Love Technical Blogging

Jan 23 2015 [Archived Version] □ Published at Caktus Blog

I love writing blog posts, and today I’m setting out to do something I’ve never tried before: write a blog post about writing blog posts. A big part of our mission at Caktus is to foster and help grow the Python and Django development communities, both locally and nationally. Part of how we’ve tried to...

Why you should donate to the Django fellowship program

Jan 23 2015 [Archived Version] □ Published at Greg Taylor under tags  django programming python

Disclaimer: I do not represent the Django Software Foundation in any way, nor has anything below been endorsed by the DSF. The following opinions are my own, unsolicited rambling.

If you hadn’t been looking for it specifically, you may have missed it. The Django Softare Foundation is running a fundraising effort for the new Django Fellowship program. It sounds like they’re still trying to figure out how to get the word out, so I wanted to do what I could to tell you why you should chip in.

This particular blog post is going to focus on encouraging (peer-pressuring) commercial Django users in particular, though enthusiasts are welcome to read along!

Humble beginnings

Django is free and open source. Just provide the expertise and the infrastructure and you can build just about whatever web powered contraption you’d like. So you end up doing just that.

Your first stop is the Django tutorial, written and maintained by a community of volunteers (just like the rest framework itself). You stumble along, slowly at first. Perhaps you find yourself frustrated at times, or maybe things move along at a faster pace. In no time, you’ve got "Hello World!" rendering, and here comes a business idea!

One hundred lines of code turns into a thousand, then five thousand, and beyond. You start seeing signups, and revenue begins to trickle in. You toil away at your codebase, making improvements and dealing with the "accidental features" that crept in during one of your late night dev sessions.

You could have built your business on one of any number of frameworks, but you chose Django. You like how it’s a very productive way to build a web app. You appreciate how it’s not impossible to find Django developers to work with you. There are probably some things you don’t like, but you might not have the time to work on fixing them yourself. You’re just busy shipping and growing.

But it could be better still!

You’re happily using Django, it serves you well. There are a few things you’d love to see fixed or improved, but you don’t really have the time or expertise to contribute directly. As luck would have it, all of the Django core developers have day jobs themselves. Things would progress much more quickly if we had someone working full-time on Django…

Enter: Django Fellowship Program. The idea is to fund at least one Django developer to work for the DSF part or full-time for a while. During this fellowship, said developer sets aside some or all of their other responsibilities to focus on improving Django. The DSF, in turn, pays the developer a fair (but low rate) for their work.

As per the Tim Graham’s recent retrospective blog post, we’ve see some huge leaps forward for the project during these fellowships. These are periods of focus and rapid improvement that everyone (including your business) benefit from.

The only problem is that we’re not going to see the benefits of this program unless it gets (and stays) funded. A well-funded fellowship program could mean one (or more) developers working on Django full-time at any given point in time. That would be huge for the project (and you and I).

Why you should donate

As a business, we are donating to the fellowship program to see one of our critical components improved. Due to the fellowship application process, you can be assured that your money will be paying a capable, trusted developer to get things done.

Consequently, you can view a donation to the Django Fellowship program as an investment with an almost assuredly positive return. If you are making money with Django, consider making a (potentially tax-deductible) investment in what may be the foundation of your business.

At the end of the first full day of fund-raising, there are precious few commercial donors listed in the "Django Heroes" leaderboard. Let’s help change that!

If you don’t hold the purse strings at your business, get in touch with someone who does and tell them about this investment with near-guaranteed returns.

Don't put html, head and body tags automatically into beautifulsoup content

Jan 22 2015 [Archived Version] □ Published at Programmer blog under tags  beautifulsoup body head html no

Was making a parser recently with BeautifulSoup. Came to the final with rendering contents of the edited text. Like so:
text = "<h1>Test text tag</h1>"
soup = BeautifulSoup(text, "html5")

text = soup.renderContents()
print text
It renders those contents with a result wrapped into the <html>, <head> and <body> tags. So print output looks like so:
'<html><head></head><body><h1>Test text tag</h1></body></html>'
That's a feature of the html5lib library, it fixes HTML that is lacking, such as adding back in missing required elements.

The workaround is simple enough:
text = soup.body.renderContents()
This solution will return an inside of the <html> tag <body>.
Result is:
text = '<h1>Test text tag</h1>'

Caktus is looking for a Web Design Director

Jan 22 2015 [Archived Version] □ Published at Caktus Blog

Over the last two years Caktus’ design portfolio has rapidly been growing. We’ve taken on new projects primarily focused on design and have received community recognition for those efforts. We are happy to have grown our design capabilities to match the level of quality we demand from our Django developers. We have found it’s important...

Django Fellowship Program: A retrospective

Jan 21 2015 [Archived Version] □ Published at The Django weblog

For the past three months, I’ve had the privilege of serving as a "Django Fellow" during the pilot program. I’ve given a weekly summary of my activities on the django-developers mailing list, but the Django Software Foundation asked me to give a retrospective on this blog.

One year ago, Django didn’t have continuous integration with pull requests. It was up to the committer to run the tests locally or hope a contributor had run the tests on all the different database and Python versions that we support. Unfortunately, this resulted in frequent build breakages that would often go unfixed for days or even weeks. This hindered development and made subsequent breakages even more difficult to debug. Last spring (pre-fellowship), I wrote some Ansible playbooks in order to build a small cluster of Jenkins machines so we had enough executors to make pull request integration feasible. This has been a huge win, both for keeping the build green and for helping contributors test their contribution, as they often don’t have all the environments setup locally. During the time of the fellowship, I expanded our Jenkins cluster with some machines running Ubuntu 14.04 (existing machines were on 12.04) to enable testing with newer databases and versions of GIS dependencies. This helped to identify bugs with the newer dependencies and was also needed for testing some of the new contrib.postgres features coming in Django 1.8. I also added flake8 integration on pull requests to flag style warnings before they inadvertently get committed. Automating these checks is one less thing for reviewers to worry about during code reviews.

Also on the infrastructure front, I upgraded the djangoproject.com Web site from Django 1.6 to 1.7. Thanks to the work of many volunteers, we rolled out a new design for djangoproject.com. I helped to QA the new design before it went live.

In our ticket tracker, I’ve triaged around 10 new tickets each week, keeping the “Unreviewed” ticket queue from piling up to 40-50 tickets like has often happened in the past.

Moving on to our release process, Django has struggled with communicating about and issuing timely bug fix releases. Part of the problem was because only a small number of people (two) were able to issue a release. The Django team has remedied this issue by revising our policy on who can release Django. I issued a set of bug fix releases as well as security releases this month. Coordinating security releases by preparing patches and backporting them to all supported versions of Django is a time-consuming task that benefits from dedicated attention that the fellowship program provides.

As the release manager for 1.8, I sent weekly email updates on the status of release blockers and we hit our target for a feature freeze earlier this week and an alpha release last Friday. Rarely have Django releases stayed on their original schedule like this. All the major features that we targeted in our 1.8 Roadmap were completed. I spent a lot of time reviewing many of them. Take a look at the 1.8 release notes for all the great work we’ve completed. To ensure a timely release, I fixed release blockers (regressions or major bugs in next features) myself when no one else had time or interest to work on them.

We’ve also worked hard to fix issues on the stable 1.7 branch. So far the 1.7.x series of releases has fixed over one hundred regressions or bugs in new features.

On the code review front, I reviewed an average of fifteen patches a week from core developers and community members. I think that providing timely code reviews is one of the most important tasks of the fellowship program as it improves the project’s culture and prevents would-be contributors from abandoning us. I don’t think it’s a secret that this is something that Django has struggled with in the past. Consider this testimonial from Loïc Bistuer, who’s now one of Django’s team members:

When I started contributing to Django, patches - especially non-trivial ones - had a tendency to languish in the pull request queue. I eventually gave up on contributing altogether after some of my contributions remained unreviewed for months. Then Tim started dedicating a lot of time to Django and reviewed my contributions. The timely reviews and fast feedback loop acted as catalyst and together we've landed over a hundred patches including 4 major features for Django 1.7 in a matter of months. The churn rate on Django contributors has been very high historically and the Fellowship program is a direct answer to that; it's a great chance for Django and for everyone who relies on it.

I hope you’ll consider a gift to the Django Software Foundation to help renew the fellowship program and all the exciting work it enables.

Webinar: Testing Client-Side Applications with Django

Jan 20 2015 [Archived Version] □ Published at Caktus Blog

Technical Director Mark Lavin will be hosting a free O’Reilly webinar today at 4PM EST or 1PM PT on Testing Client-Side Applications with Django. Mark says testing is one of the most popular question topics he receives. It’s also a topic near and dear to Caktus’ quality-loving heart. Mark’s last webinar garnered more than 500...

IPython Notebook Essentials review

Jan 20 2015 [Archived Version] □ Published at All Unkept under tags  python

IPython Notebook Essentials review

Self-Hosted Server Status Page with Uptime Robot, S3, and Upscuits

Jan 20 2015 [Archived Version] □ Published at Ross Poulton under tags  code django geeky servers

For quite a while I've had a public "Status" page online for WhisperGifts via Pingdom. It basically just shows uptime over the past few days, but given my site is relatively low-volume and not ovely critical to my customers, the $10/month for Pingdom was actually one of my largest expenses after hosting.

So, I started looking for an alternative.

Today I re-deployed the WhisperGifts Status Page using a combination of Uptime Robot, Upscuits and Amazon S3.

In short, I have Uptime Robot checking the uptime of my site (including it's subsites, such as the admin and user pages). The statistics are gathered and presented by Upscuits, which is entirely client-side JavaScript hosted on S3.

My basic todo list for next time:

  1. Sign up for Uptime Robot. I'd been using them for ages on their Free plan as a backup to Pingdom; this gives 5-minute checks. Their paid plan gives 1-minute resolution.
  2. Add your sites, make sure they're being monitored correct.
  3. On the Uptime Robot dashboard, click My Settings. Open the section labelled Monitor-Specific API Keys and search for your Monitor. Copy the API key to a text file for later; repeat this step for subsequent monitors you want to include on your status page.
  4. Download the latest Upscuits release to your PC.
  5. In the public folder of the upscuits package, rename config.example.js to config.js. Paste your API key(s) inside it.
  6. Create an AWS bucket called eg status.mysite.com and enable website mode. Setup your DNS etc to point to this bucket.
  7. Upload the contents of public/ to your AWS bucket
  8. Visit your new status page and view your last 12 months of Uptime Robot statistics
  9. Close your Pingdom account saving $10 a month Profit!

For a small site like mine this has a couple of obvious benefits. It's free (or $4.50/month if you want higher resolution - still half the price of the most basic Pingdom plan); it uses a tiny amount of S3 storage which is as good as free, and doesn't involve running any server-side code. The included index.html is also easily customisable if you like, since it's just plain HTML (using the Bootstrap framework, by default). This is a big win over hosted solutions, IMO.

Create or Update with a Django ModelForm

Jan 19 2015 [Archived Version] □ Published at Chris Kief under tags  django get_or_create hacking modelform updateview

I recently had a use case where I needed to have a single form that could act as either a create or update form. The tricky part was that I wouldn’t know which one was necessary until the data was submitted by the user. To solve this, I started with Django’s generic UpdateView and overwrote … Continue reading Create or Update with a Django ModelForm

eGenix Talks & Videos: Advanced Database Programming

Jan 19 2015 [Archived Version] □ Published at eGenix.com News & Events

eGenix Talk "Advanced Database Programming"

At last year's EuroPython 2014 conference in Berlin, Marc-André Lemburg, CEO of eGenix, gave the following talk on database programming in Python. We have now turned the talk into video presentation for easy viewing and also released the presentation slides:

EuroPython 2014 - Advanced Database Programming

Advanced concepts in Python database programming.

The Python DB-API 2.0 provides a direct interface to many popular database backends. It makes interaction with relational database very straight forward and allows tapping into the full set of features these databases provide.

This talk covers advanced database topics which are relevant in production environments such as locks, distributed transactions and transaction isolation. We also give advice on how to deal with common problems you face when working with complex database systems.

Click to proceed to the talk video and slides ...

Related Python Coaching and Consulting

If you are interested in learning more about these advanced techniques, eGenix now offers Python project coaching and consulting services to give your project teams advice on how to implement complex database architectures in Python. Please contact our eGenix Sales Team for information.

More interesting eGenix presentations are available in the presentations and talks section of the library on our website.

Enjoy !

Charlie Clark, eGenix.com Sales & Marketing

Design Thinking vs Development Thinking

Jan 18 2015 [Archived Version] □ Published at TravisSwicegood.com

This morning I read an article on what the ideal operating system should look like. I devoured all all three parts and it got me thinking about my thought process and how I approach development. This post is a loose collection of those thoughts.

What Problem?

One thing that I’ve discovered about my thought process is how I approach problems. Too many times, it’s easiest to start from where I am right now and how I can modify the existing tool / code / product to do what I need. This provides a good starting point for context of what’s immediately possible, but not for solving the problem.

For example, let’s consider the text editor. The main purpose of a text editor is writing things down. You want to be extremely good at that if you’re going to be an editor that people want to use. Based on this description you can build an editor that’s a joy to use and makes the process of getting information into the editor easy and intuitive. There’s a problem with it: what happens when a user is done with new document that they’ve created? My original description did not include anything about saving or exporting the documents that are created.

Realizing that you’ve left saving out as a feature, you might write up a job story that looks something like this:

When writing a story I want to ensure that it’s been saved so that I can share the saved document with other people.

If you start from where you are, you might think to add a Save feature and tie that to a menu item, a keyboard shortcut, and maybe even a toolbar to provide multiple options to your user. This is a valid concern, but it overlooks one key thing. The user doesn’t care about saving, they just want it saved.

The user’s job is to write, not to save something. Explicitly saving something is a task. User’s aren’t interested in performing a task unless they have to. Auto-save is what the user needs. At this point in the process the only thing they need to know is that their work is saved. Instead of focusing on the job at hand and how this feature supports that job, adding a Save feature focuses on the task.

I’ve fallen victim to thinking that focuses on the task instead of focusing on the overall job, but I guard against it now. This causes me to think differently than a lot of developers: rather than focus on fixing one particular thing, I focus on what the underlying (or overarching?) problem or job is. This means I talk past people sometimes because I forget that we’re talking about different things.

How to fix a problem

On a recent open source project that I work on I opened a pull request that introduces a new higher level concept to the project in the service of fixing one discrete bug. To me, the discrete bug was a manifestation of the lack of that higher level structure. Without that common vocabulary, different parts of the code were touched by different developers at different times and there was a discrepancy between how the concept was represented.

To me, that larger problem was what needed fixing. To other developers, the bug needed fixing. Thinking about that larger problem, I tackled that and fixed the bug. Another developer on the project focused on the explicit problem and added the one-line fix to that code path that solved that one bug that manifested itself. On the surface, the one-line fix seems simpler because less code was involved (my fix was a little more than 30 lines). The one-line solution was only simpler when viewed as the task “fix this bug” not “fix the problem that gave rise to this bug.”

To be fair, both are legitimate ways to approach the problem. The one-line fix that focuses on the task at hand fixes the bug and avoids possible over-engineering that might happen by thinking about the bigger picture. It also runs the risk of having the same problem solved in different ways throughout the code base as each “just one-line” fix adds another branch into the complexity of the program.

Thinking like a developer vs like a designer

This all ties back to the story that started this post because of the way the problem was approached. Most developers I know would balk at the idea of creating an operating system, then starting by removing the file system and applications. “But where will I store my files and how will access them?!” I hear them all exclaim at once. Most designers I know would hear that idea, think for a second, then say “ok, so what replaces it?” followed closely by “and what was the user trying to do when they accessed those files?”

Designers tend to think in terms of solutions to general problems. Developers tend to think in terms of solutions to explicit problems. This is still a nascent revelation to me, but starts to explain to me while I’ve always felt slightly out of place in the development world.

It’s also making me question my description: am I still a developer with a bit of design knowledge or a designer that happens to program?

Mercurial Mirror For Django 1.8 Branch

Jan 17 2015 [Archived Version] □ Published at Thomas CapricelliThomas Capricelli under tags  admin bit django mercurial mirror

Another year, another alpha release for Django and … another “production” mirror for me and anybody else interested. Django has just released the first alpha for Django-1.8. As usual, I create the mirror as soon as the corresponding branch is opened (stable/1.8.x), but this is still alpha stuff for you to test, not anything stable you […]

Gunicorn dyno death spiral on Heroku — Part II

Jan 17 2015 [Archived Version] □ Published at The Harmonious Programmer under tags  django gunicorn heroku postgres python

After a lot of investigation, we’ve figured out there is an issue with NewRelic, Postgres and Gunicorn. I summarized the issue here: https://discussion.heroku.com/t/gunicorn-dyno-death-spiral/136/13 After discussing this with Graham Dumpleton over Twitter there is an issue with libpq. Below is a … Continue reading

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

Social Sharing


Tag cloud

admin administration adsense 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 blogging book books buildout business cache capoeira celery celerycam celerycrawler challenges cherokee choices class-based-views cliff cloud cms code codeship coding command community computer configuration continuous deployment continuous integration couchdb coverage css custom d data database databases db debian deploy deployment deployment academy developers development devops digitalocean django djangocon django-nose django-readonly-site django-rest-framework django-tagging django templates documentation dojango dojo dotcloud dreamhost dughh eclipse education email encoding english error events extensions fabric facebook family fashiolista fedora field file filter fix flash flask form forms friends fun gae gallery games geek general gentoo gis git github gnome google google app engine gunicorn hack hackathon hacking hamburg haskell heroku holidays hosting howto how-to how-tos html http i18n image imaging indifex install intermediate internet ios iphone java javascript jobs journalism jquery json justmigrated linear regression linkedin linode linux mac machine learning mac os x math memcached mercurial meta migration mirror misc model models mod_wsgi mongodb months mozilla multi-language 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 postgis postgres postgresql ppoftw presentation private programmieren programming programming &amp; internet project projects pycon pygrunn pyladies pypi pypy python python3 quick tips quora rabbitmq rails rant ratnadeep debnath redis refactor release request resolutions rest reusable app review rtnpro ruby science script scripting security server setup simple smiley snaking software software development south sphinx sql ssh ssl static storage supervisor svn sysadmin tag talk nerdy to me tastypie tdd techblog technical technology template templates template tags test testing tests tip tools tornado transifex travel tumbles tutorial tutorials twitter twoscoops typo3 ubuntu uncategorized unicode unittest unix usergroup uwsgi uxebu virtualenv virtualenvwrapper web web 2.0 web design &amp; development webdev web development webfaction whoosh windows wordpress work workshop znc