Django community: RSS
This page, updated regularly, aggregates Community blog posts from the Django community.
-
Djangocon: banking with django, how not to lose your customers' money - Anssi Kääriänen
(One of my summaries of a talk at the 2018 European djangocon.) He works for a company (holvi.com) that offers business banking services to microentrepreneurs in a couple of countries. Payment accounts (online payments, prepaid business mastercard, etc). Business tools (invoices, online shop, bookkeeping, etc). Technically it is nothing really special. Django, django rest framework, postgres, celery+redis, angular, native mobile apps. It runs on Amazon. Django was a good choice. The ecosystem is big: for anything that you want to do, there seems to be a library. Important for them: django is very reliable. Now: how not to lose your customers' money. Option 1: reliable payments. Option 2: take the losses (and thus reimburse your customer). If you're just starting up, you might have a reliability of 99.9%. With, say, 100 payments per day and 2 messages per payment, that's 1 error case per day. You can handle that by hand just fine. If you grow to 10.000 messages/day and 99.99% reliability, you have 5 cases per day. You now need one or two persons just for handling the error cases. That's not effective. Their system is mostly build around messaging. How do you make messages reliable? The original system … -
Djangocon: want more woman in tech? Start with Django Girls - Sara Heins
(One of my summaries of a talk at the 2018 European djangocon.) She lives in Kansas, USA. Kansas is great for women in tech, there are many initiatives. The one she is most enthousiastic about is django girls. "We are raising our girls to be perfect and we're raising our boys to be brave". If a woman applies for a job, she fulfills 100% of the demands, if a man applies, he fullfills on average 60%... Why does programming make girls brave? You are going to mistakes and you're going to fix them. How do you get more girls to try it? One of the best ways is to organize a django girls workshop. There are some qualifications you don't need. You don't need to be perfect. You only have to be brave :-) You don't need to be a savvy event planner. There's lots of info on github. There are pre-made websites. Lots of resources. You don't need to have a large budget. Qualifications you do need: You need to be able to solve problems. You need to be open to learning new things. You need to want to constantly improve. You'll be busy with it for half a … -
Djangocon: don't look back in anger, the failure of 1858 - Lilly Ryan
(One of my summaries of a talk at the 2018 European djangocon.) Full title of the talk: "don't look back in anger: Wildman Whitehouse and the great failure of 1858". Lilly is either hacking on something or working on something history-related. "Life can only be understood backwards; but it must be lived forwards -- Søren Kierkegaard" So if you make mistakes, you must learn from it. And if something goes right, you can party. The telegraph! Old technology. Often used with morse code. Much faster than via the post. Brittain and the USA had nation-wide telegraph systems by 1858. So when the first trans-atlantic cable was completed, it was a good reason for a huge celebration. Cannon, fireworks. They celebrated for three weeks. Until the cable went completely dead... Normally you have a "soft lauch". You try out if everything really works for a while. But they didn't do this in case. They could only imagine succes... Failures aren't necessarily bad. You can learn a lot from it. But at that time you didn't have agile retrospectives. An agile retrospective at that time was probably looking over your shoulder while you sprinted along the highway, chased by highway robbers... Now … -
Djangocon: an ode to OAuth - Akos Hochrein
(One of my summaries of a talk at the 2018 European djangocon.) A show of hands. Who use a password manager? 90% of the hands went up. Who uses at least two? Some 40%. Passwords are irritating. There have been initiatives to "outsource" passwords. Openid, oauth, oauth2.0. On to OAuth2.0. It started at twitter. They started with OpenID, but that only handled login, not access to resources. In the end, oauth2.0 came out. (Note: he said "openid connect", but that's build on oauth2.0, so he must have meant plain "openid" if I'm correct. But it might mean that I'm not totally correct in this summary, or I heard it incorrectly). There are multiple ways to work with oauth2.0. He showed the "authorisation code grant". I can't visualize his diagram here, look at the video for that. There are some terms: Resource owner. Client: you, behind your browser. Authentication server: this is where you will log in ("log in with facebook/google/etc") and where the Resource server: this is where the data is. Akos works at prezi. The backend is actually a django site. But there were many customizations to auth, sessions and user objects. At one point, they wanted to make … -
Djangocon: it's about time - Russell Keith-Magee
(One of my summaries of a talk at the 2018 European djangocon.) Handling time and timezones is complex and painful. It starts with leap years. Every four years, there is a leap year. Except every 100 years. Except except every 400 years. The latter two rules are from the gregorian calendar, which replaced the julian calander in 1582 (at least, in parts of the world...) When did the "october revolution" happen? Well, either 25 oct or 7 november 1918. Russia still had the Julian calender at that time :-) Year? Well, some countries use years based on the lunar cycle... Or they count from a different starting point. In IT we had the Y2k problem. In 20 years time there'll be the 32 bit epoch overflow. It already crashed the AOL mail servers (!) years ago. In python, there's the time module. It represents how your computer thinks about time. It isn't terribly useful if you actually want to do something with it that you're going to show to the user. The datetime module is the one you'll probably want to use. But do you use a date or a datetime? A date doesn't have a timezone. The day Hawkings … -
Djangocon: friday lightning talks
(One of my summaries of a talk at the 2018 European djangocon.) The stenographers - Sheryll and Andrew The stenographers are the ones that provide LIVE speech to text subtitles for the talks. Wow. They use "shorthand machines" for steno. It is like a piano where you press multiple keys to form words. On wednesday the speakers talked 46000 words... How fast do people talk? Anything between 180 and 250, though 300 also occurs. The handiest are speakers that speak in a regular tempo. And not too fast. They ask presenters for notes and texts beforehand. That helps the software pick the right words. Pytest-picked - Ana Paula Gomes Say you have a codebase that has tests that take a long time. You've just changed a few files and don't want to run the full test before the commit. You could run git status and figure out the files to test. But you can do it automatically with pytest-picked. It is a small plugin, but she wants to improve it with better guessing and also with support for testing what changed on a branch. How to build a treehouse - Harry Biddle A talk about building actual treehouses! One of … -
Djangocon keynote: 23 years without a 'proper job' - Rachel Willmer
(One of my summaries of a talk at the 2018 european djangocon.) Rachel has used django since it was created, but this is her very first djangocon. She hasn't had a "normal" salaried job for 23 years. She's been freelancing, self employed, some contracting to the Scottish government, had her own company, etc. So here are some tips for those that think about such a life. We as programmers are very lucky. We're very flexible. We can work anywhere we like at anytime we like. As a bus driver, you have to show up when the bus timetable says.... We have lots of freedom, we 'only' have to arrange it so that who we work for agrees to it. She has a side project, https://luzme.com, for searching for low ebook prices. Side project? Not really. She uses it to try out new techniques. Firebase, django channels, etc. Fun! And it helps her learn a lot more than when she would have just followed tutorials. Ok, back to you. You want to do something for yourself. Perhaps your own company? If that is what you want, you have to learn how to run a company. You have to learn how to … -
Djangocon: organizing conferences for learners, how we did it in Namibia - Jessica Upani
(One of my summaries of a talk at the 2018 european djangocon.) For Jessica, it all began at PythonNamibia2015. She went there, not because she wanted to learn python, but because she was bored. And the conference was free. It had all changed by the end of the conference! Thanks to the organizers that inspired a lot of people there to become active with python. In 2017, she helped organize a 'computer day'. Talks and panel discussions, poster presentations, software project presentations and workshops. It was aimed at kids! Especially the panel discussions were aimed at the newcomers: trying to transfer experience. In 2018, there were separate workshop days, amongst other an introductory python course. There are some differences from organizing a conference for adults: You need to write letters to parents! Convincing them to send their kids to the conference. Behaviour. You need to follow the behaviour of the kids. They're less well-behaved than a room of adults. Adults sit still, kids move around and look for attention. The one giving the presentation needs to be a good teacher, otherwise they won't be able to keep the kids' attention. Different expectations. Kids expect fun and games, they don't expect … -
Djangocon: ORM, the sequel - Katie McLaughlin
(One of my summaries of a talk at the 2018 european djangocon.) SQL. The "language to talk to databases in a structured way". The ORM. Object Relational Mapper. The magic that makes it all work in django (even though there's no magic in there). The talk is about the experience of experienced programmers that, for the first time, have to dive into a django project. She used http://glasnt-orm.us.aldryn.io/ ("unicodex") as an example. So. There's a missing icon on the sample page. You have to debug/fix that as an experienced-programmer-without-django-experience. You're used to SQL, but not to the django ORM. You get a tip "use the shell". Which shell? "The c shell? bash?". No, they mean manage.py shell. With a bit of _meta and some copy/paste you can get a list of the available models. You could do the same with manage.py dbshell, which would dump you in the sql shell. List the databases and you get the same answer. Pick a promising table and do a select * from unicodex_codepoint. You can do the same in the django shell with: from unicodex.models import Codepoint Codepoint.objects.all() The rest of the presentation was a nice combination of showing what happens in SQL … -
Djangocon: taking channels async - Andrew Godwin
(One of my summaries of a talk at the 2018 european djangocon.) Channels, started in 2015 as "django-onair", had its 1.0 release in 2017. It used twisted, ran on python 2.7, and django runs synchronously. Python 2.7 undermined it. Python 3 has asyncio support, 2.7 has not. Because of that, channels had to be too complex. The design was wrong. Now, there's channels 2.0. It requires python 3.5+. Native asyncio! Much simpler to deploy, also. It was quite a big rewrite: 75% was changed. A big challenge was that django had to become partially asynchronous. The regular django ORM, views, middleware, url routing is still synchronous. Parallel to that, there's channels (ASGI) middleware and so. Two separate worlds. But still, there are a few contact points. Towards the ORM, for instance. So he needed two functions, sync_to_async and async_to_sync, to move between the two worlds. They took two months to write! Synchronous code has to run in threads. The ThreadPoolExecutor does most of the hard work. Both async and sync code are useful. Channels lets you write your code as both. Async is hard, so you don't want to have to be forced to use it. Channels' two functions make … -
Djangocon: growing old gracefully, on being a career programmer - Carlton Gibson
(One of my summaries of a talk at the 2018 european djangocon.) He's a longtime django user. "The web framework for perfectionists": yes, that's him. He has also build lots of backends for IOS apps. For that, he used django REST framework. He got involved on the mailinglist and on stackoverflow. Now he's a core team member of django rest framework. He also started maintaining django-crispyforms and so. And now he's the "django fellow". So far, so good. He has a job. Nothing million-euro-making, but fine. The problem: he's getting older. There was a post on hacker news: "before you're 40, make sure you have a plan B". You might get into problem when searching for django jobs: "you're older, so you're more expensive, so we'll take a younger person". You also might have a family, so moving (especially working abroad) is harder. There's a common path: become a manager. But he won't do that. He's a good programmer, but not a good manager. He wants to stay productive and creative. So what if you just want to keep programming? He has some generic strategies: Look outside the tech bubble. The software tech bubble. "Software is eating the world", so … -
Djangocon: protecting personal data with django (because it's the law) - Will Hardy
(One of my summaries of a talk at the 2018 european djangocon.) Will is a software developer with a law degree. Now that we have the GDPR, his law degree is suddenly very relevant. GDPR takes effect on 25 May 2018. What is the GDPR? It is a law that regulates the use of personal data. You'll probably have had lots of emails from companies telling you that they'll be good with your data and asking whether they're still allowed to use it. He encourages you to read the actual regulation. The first part is quite readable. The actual articles are quite detailed, but only the first 34 are relevant for us. He thinks we have a professional duty to be on top of this. We have to know about it. As programmers, we're in the front line. We might be the ones that can best advise the company on how to comply. We ought to know the details. If you help your company, you're valuable to your company, so... He has three categories in his talk: terms, rights, tasks. Terms Terms in the legal world aren't defined as rigorously as in software standards. "Personal data is any information relating … -
Djangocon: on the look-out for your data - Markus Holtermann
(One of my summaries of a talk at the 2018 european djangocon.) We have piles of data in our databases. We want to search in there. What is "search", actually? "Try to find something by looking or otherwise seeking carefully and thoroughly". On the one hand, there's "try". On the other hand "careful and thorough". So: search is hard. What about searching in django? In a very basic sense, you already search if you do get_object_or_404(Article, pk=12)! And if you don't find it, you return a "404 Not found". Searching text is more complicated. Text is unstructured data. So you'd have something like get_object_or_404(Article, text__icontains=search_parameter). This is not efficient for your database: WHERE text ILIKE `%your search parameter%'. There is an index in postgres that's much more efficient: trigrams. These chop up your text into various pieces of string that are 1, 2 or 3 characters long. See https://www.postgresql.org/docs/current/static/pgtrgm.html It is not included in django, but you can write a custom index for it. The code fitted (readable!) on one slide. When we talk about searching text, we often mean full text search. Word order doesn't matter, for instance. And the exact verb form also doesn't matter. In linguistics there … -
Djangocon: automated spell checking in django projects - Jakob Schnell
(One of my summaries of a talk at the 2018 European djangocon.) We are humans and we make typos. So there are typos in our code. The two common places for typos are documentation and the user interface. Documentation is normally only provided in a single language and it are large text files, so spell checking is relatively easy. Django documentation is often build with Sphinx. For that, there is a sphinx extension: sphinxcontrib-spelling. You can even integrate it in your CI as a post-build check. There will be words that are correct for your project but that aren't in the regular dictionary: for that there's a local "wordlist" you can use. For code (and our GUI), it gets more complicated. You would have to read python code, css code, html code, javascript code... hard. But there is a solution! Translations. Once your project gets bigger, you probably want to start translating it. Once you have set up your translation mechanism (gettext), you have all your strings gathered into one place: the .po files. Hurray, now we can do spell checking. Gettext is the standard mechanism in Django to deal with translations. You'll see lines like from ... import ugettext … -
Djangocon: strategies to edit production data - Julie Qiu
(One of my summaries of a talk at the 2018 european djangocon.) She works at the catalog team of "spring", a clothing website. Internal tools are often not available. There are always edge cases. Time-sensitive changes are sometimes needed ("right now"). You could just do a quick SQL query in the database. Normally, a colleague will look over your shoulder and double-check what you're about to type. But when it is friday afternoon and your highest-paying client wants a last-minute change.... They do have a collections of horror stories... Here are some strategies: Develop a review process for manual edits. What they've done is to create a spreadsheet. You'd have to write in there your name, the sql code, what you want it to do, who you want to review it. Only after the review, you are allowed to run it on the server. The advantage is that it is easy to implement and that you get an audit trail. You also teach engineers what is the right thing to do. A disadvantage is that you still can get mistakes. And it is fine for smaller changes, but not really for elaborate SQL and long-running queries. Write scripts and run … -
Djangocon: slow food digest better (maintain an old project) - Christopher Grebs
(One of my summaries of a talk at the 2018 european djangocon.) Full title: "slow food digest better - or how to maintain an 8.5 year old python project without getting lost". Christopher had to maintain such a project - and actually liked it. It was https://addons.mozilla.org, actually. It started out as a quickly-hacked-together php project. Now it an almost modern django project. The transition from PHP to the django version took almost 16 months. During that time there were bugs, translation errors, downtime: irritating. The site went fully live in january 2010. The big advantage of the move to django was that lots of tests were added at that time. The site wasn't anything special. Mostly django. Still quite some raw SQL from the old system. Celery for some tasks. Mozilla at one time had the "Firefox OS" for mobile phones. For that, they build the "firefox marketplace". The work was based on the addons.mozilla.org code, but with some weird hacks based on which site it was running... During that time the addons.mozilla.org website itself was pretty much left alone. In 2015 they had to re-animate the old codebase. At that time it was running django 1.6, barely, as … -
Djangocon: thursday lightning talks
(One of my summaries of a talk at the 2018 european djangocon.) Recording this conference with python and gstreamer - Peter Körner He's part of the CCC video team. Most of it is explained on https://c3voc.de/wiki He showed diagrams of their wonderful setup, but I cannot possibly write that down :-) The code is at https://github.com/voc/voctomix You're welcome to ask them questions! Cosmic ray research - Arne de Laat Arne used to work in astronomy on a project to do research on particles that result from supernova explosions. These particles can reach our athmosphere ("cosmic rays"). HiSPARC, high school project on astrophysics research and cosmics. Simple measurement stations, build by the schools, to detect those cosmic rays. One particle that hits the athmosphere hits other particles, so it results in multiple speed-of-light other particles. So if you detect a bunch of them at almost the same time at several nearby locations, you can more or less work out the direction of the explosion. See http://data.hisparc.nl/ for a sample. How to propose a talk - Lacy Williams Henschel The first thing you need is an idea. What have you learned recently? What do you have a strong opinion on. What used … -
Djangocon: writing code.... evolve it instead - Emma Gordon
(One of my summaries of a talk at the 2018 european djangocon.) Emma is member of the Cambridge programmers' study group. One of the topic there at one time was machine learning. Cool. But she started thinking about computers learning to write code theirselves. What would that mean for us, programmers, regarding job security? Automation/mechanisation has eliminated lots of jobs already. Self-checkouts at supermarkets. Agricultural mechanisation. Will the same happen to programmers? IBM created a huge computer called "Watson" that could win at some game show (jeopardy). Machine learning, natural language processing, etc. What is interesting about that, for Emma, is that "Watson" could be used for "reading" medical journal papers. The computer could amass knowledge (especially of edge cases) which a human doctor could not do: how many papers can you read per week? Same with legal stuff. Human doctors and lawyers won't be replaced, but parts of their jobs could be done/assisted by computers. So what about us, programmers? Code is text. You could look at genetic algorithms. Random search, guided random search. It takes its inspiration from biology. You could generate random strings and hope they'll match this talk's title (for instance). You need a "fitness function" … -
Djangocon: a different form of navigation - Chaim Kirby
(One of my summaries of a talk at the 2018 european djangocon.) We use forms a lot. He's not going to talk about regular forms, but about using forms for navigation. Many people have lots of data nowadays. Or have to work with it. Or have to program code for people that work with lots of data. Chaim works in healthcare. He showed a demo of riskscape: 150GB, 130 million records, 47 fields. The demo showed a form where you could select a few criteria ("only give me people with type 2 diabetes") and pick an action (show number of cases on a map). Then it started to get interesting. Click on an area and then create a graph according to age group. You could also click several items on the homepage that resulted in a map or graph with a pre-populated selection. Technically: A form's data propagates through pages. You can pre-populate a form so that you can use it as an URL (from a dashboard, for instance). This is done with django-modelqueryform. It generates forms that act as a power search based on a model's Meta. To carry the form context between pages you have to render the … -
Djangocon: it's not a bug, it's a bias - Anna-Livia Gomart
(One of my summaries of a talk at the 2018 european djangocon.) If you have a bad experience with a program, is it a bug of can there be a bias in the software? Apple's Siri, at first, had answers for questions like "where do I hide a body?", but it didn't have an answer for "where can I get an abortion?"... Are algorithms neutral or can they be biased? You can have biased programs, biased users and biased data. Programs are made by programmers. Programmers are humans. Humans have experiences. Experience is often colored... We, as programmers, can read the algorithms. So it is our role (or our duty) to critique them. Look at computer games. Often there is "procedural rhetoric" in it: some worldview or agenda that is embedded in the game's enviroment or rules. Facebook has a definition of "friend". So in fact they're re-defining "friend"... A problem you often have: normalcy. As designer/programmer/manager, you have certain assumptions. These might not be true for the user. "Everyone lives in a EU city and has 4G". "No-one has a last name called Null". "Everybody reads English perfectly". An important bias: the negativity bias. Negative reviews are notice much … -
Djangocon: building real-time apps with django - Iacopo Spalletti
(One of my summaries of a talk at the 2018 european djangocon.) The web isn't a pure request/response web anymore. There's real-time web now. There are lots of tools (yeah!), but you also get lots of complexity (booo!). Django channels is a framework to use django in the non-http world. Websockets, but not only those. Channels (version 1) is out now for three years, version 2 came out a few months ago. The talk assumes version 2. Some concepts: Asynchronous. For us, this means event-driven. A problem is that asynchronous code is normally harder to understand because of its non-linear nature. But... channels hides most of the complexity for you. ASGI. A protocol spec (like WSGI), independent of channels. It is ASGI all the way down. You can nest them. Protocol server. This implements the ASGI spec for a specific protocol. It interacts with the connection. It bridges the network and the application. For channels, this often is 'daphne'. Routing. Maps incoming messages to consumers. It is nestable and composable. Scope. A "scope" is created for every connection. It holds the data of the connection. Channel. IPC mechanism ("Inter Process Communication"). FIFO "at-most-once" queue. Consumers. The core abstraction to build … -
Djangocon: can packaging improve django deployments? - Markus Zapke-Gründemann
(One of my summaries of a talk at the 2018 european djangocon.) Markus started created websites at the end of the 1990s. He calls himself an open source software developers. Open source is how he learned programming, so he likes giving back. How can packaging make deployments easier, faster and more reliable? He showed a django project structure, modified for packaging it with python. Extra files are MANIFEST.in, setup.cfg, setup.py. And the actual project code is in a subdirectory, as that's what setup.py likes. If you have apps, he suggests to put them in an yourproject/apps/ subdirectory. Many people use requirements.txt files to list their dependencies. They only use setup.py for libraries or apps that they publish. But why not use the setup.py also for projects? There's an install_requires key you can use for mentioning your dependencies. Note that if your setuptools is new enough, you can put everything into setup.cfg instead of having it all in a weird function in setup.py. This includes the dependencies. Your setup.py will now look like this: from setuptools import setup setup() As we're deploying a project (instead of a library), we can even pin the requirements to specific versions. He mentioned bumpversion to … -
Djangocon: representing hierarchies in relational databases - Jacob Rief
(One of my summaries of a talk at the 2018 european djangocon.) Jacob works with django since 2011 and he created and maintains a couple of django apps. One of the projects he took over maintenance of is django-treebeard. django-treebeard can be used to create hierarchical structures in your relational database. A tree structure. Like the structure of a company. Or nested categories in a shopping website. There are four common solutions to get a hierarchical relation in your database: Adjecent list. Basically you add a parent foreign key to your model. Traversing the tree has bad performance, as you have to recurse through every "level" to find all parents or children of a node. It gets worse if you also want to filter. You can Materialized path tree. You give every node a special "path" field. The first element is A, its children are AA, AB, AC. One level down AAA, AAB, ABA, ABB, ABC, etc. Now if you want to find the children of 'AAB', you search for all items with a path that starts with 'AAB'. (You have to exclude the current node, though). As long as you have a good index, the performance is good. If … -
Djangocon: creating solid APIs - Rivo Laks
(One of my summaries of a talk at the 2018 european djangocon.) Our applications are increasingly also used by other computers. But the APIs they use are ironically aimed at humans: at the programmers that have to program on your API. "API" means "application programming interface", but it might be better to say "application programmer interface" as you really have to focus on the programmer that has to do the programming! What makes an API good? Documentation. Familiarity. Lack of friction. Documentation This is often overlooked. But it is the first point of contact of your API, so it gives the first impression. An important deciding factor. It takes lots of work to write good documentation, but the effort is worth it. Look at your documentation as a "sales page" for your API. What do you want on your sales page? Here are some suggestions: How do I access it? Do I need authentication? How? What is the root URL? General info on encodings and formats. Make it explicit. Pagination. Document the common errors (error codes) you can get. Code for getting started. It gives your users a warm feeling if their first try works right away. When you document … -
Djangocon: making smarter queries with advanced ORM resources - Mariana Bedran Lesche
(One of my summaries of a talk at the 2018 european djangocon.) There are details in django's ORM/model/query documentation that you often skip over. But there are very useful things in there. Recently she had to work on an old PHP project where she had to write SQL by hand. And some of those raw SQL statements, she couldn't get working right away with django. So she went back to the harder sections of the documentation. When should you use the advanced methods? For instance when the regular optimizations don't give enough results: Good indexes on your tables. Paginated requests. select_related, prefetch_related are there. You limit the output with values, values_list, only and defer. You use a database cache. You use the assertNumQueries on tests to figure out if too many queries are made. Mariana comes from Brazil, where they have a law that says that all non-secret goverment information should be made available. There's the https://brasil.io project that tries to make the data available in useful datasets (as the source data isn't always in a useful format). That's where she got her sample data from: info on companies and their owners. Owners can be regular persons, other companies or …
