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!
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.
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).
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.
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.
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.
My basic todo list for next time:
publicfolder of the upscuits package, rename
config.js. Paste your API key(s) inside it.
status.mysite.comand enable website mode. Setup your DNS etc to point to this bucket.
public/to your AWS bucket
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.
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:
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.
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.
Charlie Clark, eGenix.com Sales & Marketing
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.
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.
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.
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?