State of REST
Django REST Framework has clearly broken away with a ton of momentum, and with good reason. It's a solid framework, and the tools it provides right out of the box — serialization, validation, nested relationships — are splendid. It even provides basic authentication and authorization baked right in, which works great in the very simple cases.
However, when you start encountering slightly more complicated API permission setups, things start to get messy.
There's a big tectonic shift when trading in your traditional request-response-Django site for a frontend-framework-API-Django site. Your application logic used to reside almost entirely server-side, but now it's split — half server-side, half browser-side. And the trick with browser-side code is it runs in a completely untrusted environment. So we're faced with a much more complicated security situation to batten down.
You need different authentication strategies: session auth, JWT token auth, API keys, signed URLs, and combinations thereof. You have different permission strategies: table-level, row-level, column-level, and combinations thereof. It gets real complicated.
I'll show how to use the tools at our disposal — Django groups and permissions, REST Frameworks's permission classes, third-party libraries — to cobble together a passable security setup for your API. You'll get plenty of code samples, detailing the kinds of setups we put together for our site and the custom tooling we built to do it.
We'll end by talking about how our tools can serve us better in the future. If Django is going to have a strong place in the future of the web, we need strong tooling for building APIs. This is how we'll get there.
Why is burnout such a bad thing?
When I see that question on paper, the answer seems obvious. But in nearly a decade in this community, I've seen people run themselves into the ground without realizing that they can - and should - take the time to rest. Why? Well, the short answer is that, if you don't take a break once in a while, the quality of your work suffers. But the long and more involved answer? Well, as a wise man once said,
"Life moves pretty fast. If you don't stop and look around once in a while, you could miss it."
Burnout leads to exhaustion, and that leads to terrible performance. And no one wants to be known for performing terribly - we all have too much pride for that. History is full of examples of times when exhaustion led to disaster - remember the Exxon Valdez? Imagine your open source project taking a header like that. I'm actually going to get a little science-y here and cite a few studies, in particular a recent one from Washington State University that shows how sleep-deprived people have an impaired ability to take in new information.
Of course, you can get plenty of sleep and still be burned out. If your waking hours are consumed with community work, your relationships can suffer, and your sanity will erode pretty quickly.
After nearly a decade in the Python and Django communities, I've experienced periods of overwork that have made me hate everything I was doing. I have a lot of good anecdotes, stories that will probably sound familiar to everyone in the room. Luckily, I've also learned some tactics for stepping back and recovering. It can be done, and it's easier than people think. What you're going to hear from this talk is just plain common sense. But sometimes when you're mired in work with no obvious way out, you need to hear it from someone else. So I'm giving everyone permission to let go. (And no, I promise, there will be no 'Frozen' references in my slides.)
But how do you let go? And when?
Burnout is pretty easy to recognize if you know what to look for. Are you staying up every night reading pull requests ... and is that your primary method of interaction with other human beings? Your user group may only meet once a month, but is that group still responsible for the bulk of your email? Do you secretly blame them for your inability to get to inbox zero? Is the only travel you're doing for conferences? Have you given up on vacations and just decided to see the world one PyCon or DjangoCon at a time?
The biggest indicator of burnout in the community is how you feel about the community around you. When you find yourself starting to cringe every time you get a new Twitter follower, it may be time to start saying no to things.
The most important piece of advice I have is to stop looking at what other people are doing. We all know that person who seems to have a hand in every project, but you can't judge your own performance by what you imagine theirs to be. You don't know how they may be scrambling behind the scenes.
And remember that just because you're invited into a conversation doesn't mean that you have to contribute to it - sometimes listening is enough. Emails can sometimes go unanswered - so can phone calls! Think about what's most important in your life, and start directing your energy towards those things instead.
Don't write so much code in your free time. Take a few nights off, go outside - there's a lot to see out there!
Your collaborators WILL understand. Especially if you announce your intentions to the world. Send an email, tweet it out, let people know you need some time off. You'll be surprised how much understanding you'll get and how well people will respect your boundaries (you just need to set them).
Everyone has seen plenty of articles about how to design data storage solutions well - but nobody is getting up there and talking about how bad their storage design is.
Rather than just listen to more things to do and vague reasons why, come and see some truly awful examples of storage design, and the lessons we can learn from it. What happens when you end up reimplementing indexes? Why shouldn't you turn off durability? Why not make a table for every user? And how can you render templates purely in the database?
All this, and more, as we delve into the realm of datastores and examples both historic and current that you can learn from, and hopefully come away with a better idea why the rest of us design things the way we do.
The goal of everything we do is the same – how can we produce something useful for the citizens of Texas that enable them to be better participants in their state government?
Our News Apps team is responsible for the building and maintaining of editorial-focused data explorers. Django's ease of use has made it possible for us to architect both robust back-end systems for managing the government data sets that power these apps, and to build compelling interfaces to the data for our users to find their own stories.
More details on the three projects we'd discuss:
The Government Salaries Explorer is our most popular explorer. This project manages the payroll data we've collected of more than 300 thousand public employees, providing a peak behind the curtains into how tax dollars are being spent. It required a system that could standardize the many different formats a public agency may release its payroll information to us, but also remain easy to use for all members of the team so updates happen in a timely fashion.
The Texas Legislative Guide was our spin on a legislative bill tracker. Instead of placing all the focus on the bills themselves, we instead created a platform for our reporters to provide context on the many topics and issues that come up during a legislative session. While we still have the capacity for users to search for bills, the site's bigger focus is on the potential changes this session's legislation may have on the state.
And finally, our upcoming revamp of our Public Schools Explorer will be a Django app. This project is currently in it's very early stages, but it's on track to be released by DjangoCon so there will be plenty to show by then! The challenge – how can we take Texas Education Agency data and turn it into something usable for the citizens – and parents – of Texas? We are building an interface that makes it easy to compare and districts and campuses to one another, opening up state data that has always been public but frustratingly trapped within complicated web forms and paper printouts.
While this proposal is more focused on "what we did with Django" vs. "how we did it" – although that will be touched on as well – I believe the work we've produced is a testament to the impact we've been able to have on the state and its citizens thanks to the support of a system that works well for us.
What are Django's important design decisions?
Maximizes for the 90% case, but allows for uncommon cases
Emphasis on documentation and testing
"Configuration over convention" and "Explicit is better than implicit"
What are the benefits of each choice?
Good high-level documentation
Easy access to quality libraries
An invitation to explore.
What challenges are a consequence of these choices.
Do I need all of Django?
What is Django and what is Python?
The mixed bag of "Configuration over convention"
What does Flask do differently?
How does Ruby on Rails differ and which parts are harder or easier to teach.
Common mistakes when teaching Django
How Django lends itself well to a Constructivist teaching approach, especially Jerome Bruner's "Spiral Curriculum".
WHAT: Inclusion Defined
Not about morality
Inclusion vs. Diversity vs. Political Correctness
WHY: Why does this matter?
Inherent limits on community membership: not ALL 7 billion humans will join AND contribute
Inclusion lets you maximize the number of contributors
HOW: How do I DO this better?
Check your assumptions
Zen of Python on Inclusiveness
Errors should never pass silently
Check for exceptions
Discuss errors when they occur
In the face of ambiguity, refuse the temptation to guess: how much does the ambiguity matter?
Get out of your bubble
Flip the Demographics
Understanding The Power of Privilege
Your Personal Privilege Matrix
"Turn Your Sadness Into Kindness"
What if you feel you can't?
If your heart's not really into it or you feel it's "too hard", be honest with yourself and just hang around others like you. An insincere effort often does more harm than good.
Recognize that this behavior may leave you isolated from a large (and growing) portion of the community.
It's up to all of us
Just as systems tend towards entropy, if you leave a community alone it tends towards toxicity. Good communities require continual effort. - Jacob Kaplan-Moss
"I came for the framework but I stayed for the community.“ Many people make this statement when asked "Why Django?“. The Django community can change lives and has changed many lives, including my own. I’d like to share Django Tales with you, stories of inspiring women whose lives were changed by learning Django and becoming involved in the community. But what is it that makes the Django community so special and awesome? What do we all love about Django and its community? There is no doubt that the Django community is great but we’re not done yet! There are things we can improve. So what can we do better? And how can you help improve our community? How can you help people become part of our community? If you’re curious about the answers to those questions and would love to hear inspiring Django Tales, then this is the right talk for you :)
Some things I will talk about:
The "Your Django Story“ interview series on the Django Girls blog
Why Django Stories?
How Django can change lives: Stories of awesome whose lives were changed by learning Django
What’s awesome about the Django community?
We’re not done yet! What can we do better?
How can you help people become part of the community/make our community better?
This talk is an introduction to using the Requests, Beautiful Soup, Selenium, and PyAutoGUI modules in order to automatically grab data from the web or interact with desktop applications.
Attendees will learn:
How to download files and pages from the web
How to use CSS selectors to find content in a web page
How to control a web browser from Python using Selenium
How to programmatically control the keyboard and mouse
The content from this talk is derived from Al Sweigart's book, Automate the Boring Stuff with Python, which is freely available under a Creative Commons license at http://automatetheboringstuff.com
While the front-end of theatlantic.com was written in PHP up until its recent rewrite, we have relied on a robust Django-powered admin to manage content for nearly two years. At the time when we began coding the redesign we had already developed an adequate solution for curating content into modules on our site: a combination of Grappelli’s drag-and-drop sortable inline feature and django-nested-admin, a project we wrote for nested InlineModelAdmins. However, it soon became clear that our current system would not meet the needs of editors managing The Atlantic’s new responsive and visually-striking homepage. The workflow employed by the editors with our sortable nested inlines—edit, save, preview; adjust, save again, preview; …—would have been too burdensome.
So why Knockout.js? I evaluated most of the popular options. Though I initially adopted AngularJS, I later abandoned it because, while it is a fine framework, it is not ideal for integrating with DOM elements that live outside angular. I stumbled through quite a few angular controllers and directives (violating their best practices every step along the way) before changing direction. Knockout, by comparison, turned out to be absolutely perfect for the task at hand.
This talk will discuss what was involved in using Knockout to build two-way data binding with django formsets, and how we implemented sorting with drag-and-drop functionality, inline editing of html, and image uploads and cropping. It will also touch briefly on the challenges we faced making everything testable, and feature a live demo of updating theatlantic.com homepage using our new modular Django CMS.
Django is a comprehensive web framework that provides well-defined concepts such as request, response, middleware and view that make our lives as perfectionists with deadlines much easier. What many of us are not aware of is the rich collection of utilities and tooling around these concepts that are part of the famework. Decorators, helper functions and context managers that are used internally but can make life as a developer much easier as well.
Introduction (~ 2 mins)
A little bit about me.
Why am I talking about this?
Django's Hidden Treasures (~ 4 mins)
The reason for this talks.
What do I consider hidden treasures?
Which Django modules are interesting?
Are they documented and were do I find it?
Examples of hidden treasures:
A quick introduction of the module.
What's a possible use case for it?
How does it solve it?
Where is it used in the Django?
cached_property (~ 2 mins)
import_string (~ 2 mins)
lazy, LazyObject and lazy_property (~ 3 mins)
decorators module (~ 4 mins)
update_wrapper and wraps (technically not Django)
django.views (~ 4 mins)
Wrapping up (~ 2 mins)
Django documentation links.
Some suggestions for further investigation.
I'll take you through the most effective performance lessons we've learned and show you how you can implement them (with example code).
TWO-PASS CACHING WITH CLASS-BASED VIEWS
By far, this is one of the most effective performance optimizations we have done in terms of HTTP response time.
Using class-based views, we are able to do two-pass caching. On the first pass of the view, we render everything that's not specific to the user. No AJAX calls needed to get user specific content on the page. I'll show you how.
DATA CACHING STRATEGY
I'll review how we use multiple levels of data caching to greatly improve the amount of time it takes to rebuild the entire cache.
DB READ REPLICAS FOR PERFORMANCE / CUSTOM BACKEND FOR FAILOVER
Read replica databases are great for performance. You've set up a few read replicas and implemented a fancy new database router which sends read queries to the read replicas (round robin) for any data that doesn't need to be up-to-the-millisecond fresh (e.g. blog posts, product descriptions).
You're sitting back and relishing in the improved performance when one of your database read replicas goes offline. Now what? I'll show you how we implemented a custom database backend to handle this gracefully.
This is less of a performance optimization and more of a set of rules we try to stick to. I'll review some snafus we've had and how we avoided future production issues while keeping the site at 99% uptime.
Developers are trained to communicate to things with a goal in mind. When you're talking to something like, say a computer, you type in your code and it responds by giving you back what you want. Nine times out of ten, it works perfectly. Why, then, is it so difficult to do this same thing when talking to a client about a project, updating a superior on your progress, or pitching an investor your million-dollar idea? Because talking to people requires a special set of skills - namely, empathy and a little bit of storytelling. In an industry filled with brilliant minds, great ideas and mass disruption, so few of the best and brightest know how to tell their compelling story. The takeaways from this workshop will be learning how to value the listener and use vulnerability to improve your social connection.
This talk will take you through the difficulty of broken communication - I, myself, stutter and have great difficulty in saying the simplest things - to discovering how to reframe your perceived weaknesses. None of us are perfect, but sometimes those things that we feel are our weak points are the exact things that we can use to our advantage.
Many developers want to write better code, but simply don't know how to write units tests for:
Code that calls other code (i.e. code with dependencies)
Methods that have no return value
Code that throws exceptions
Mocking provides a valuable tool for solving these problems. In this talk, we'll discuss the scenarios in which Mocking is useful, the strategies for addressing each of the cases above and write simple, clean unit tests using the built-in Mock library.
The goal of this talk is to make views and HTTP as clear as daylight. This talk is for you if you're confused about:
how function views compare to class-based views
when to use generic class-based views-
the difference between class-based views and generic class-based views-
or when to use any of these
This talk will start with an introduction to HTTP and how Django handles HTTP. We will then look at each kind of view in Django, focusing on how each works and why Django implements it that way. This will allow us to look at the advantages and shortcomings of each type of view. Finally, with a full understanding of Django views, we will be able to easily determine when to use each type of view.
Table of Contents:
What is HTTP, anyway?
Django's HTTP Request/Response Cycle
What is a callable?
History of View Functions
Classes and Generics
(or How I Learned to Stop Worrying and Love Non-Compliance)
Class Based Views
(or As DRY as the Sahara)
Generic Class Based Views
(or Oh For The Love of Graph Theory)
(or 1-Size fits no-one)
Fixing Your Views
When to Use What
This talk will explain the new Meta API, and look at Daniel Pyrathon's django-mailer as an example of using Meta in the real world.
Talk outline: What is meta programming - Reflection in Python - What this means in Django History of Django's Meta The new Meta API - Daniel's GSoC project - API walkthrough So why bother? - How Forms use meta - How Admin uses meta - django-mailer: GMail in contrib.admin * Other options? - A teaser of other places where this could be used.
This presentation will teach the audience the basics of GIS and GeoDjango. Once you know how to set up a Django project, putting a map on your webpage hasn't been easier. During my talk, I will show you how to navigate through the GeoDjango documentation as well as other handy tools such as Mapbox and Leaflet. In addition, I will show the audience two GeoDjango examples – a project about my Study Abroad trip and an interactive campus map! The overall objective is for the audience to know that GeoDjango exists, how to use it, and to promote creativity for their next project!
Wagtail was launched in February 2014, shortly after its first implementation for the Royal College of Art. It has been enthusiastically received by Django developers around the world, and now powers sites for small businesses, UN agencies, and global brands in tech, political and entertainment sectors. Tom will explain why his agency decided to build a new CMS, share some lessons learned in running a growing open source project, and outline Wagtail's roadmap to version 2 and beyond.
I have two English degrees, and I’ve identified some concrete ways this makes me a better developer. This talk will discuss how we can take lessons from literature to write more readable code, make better tests, and create more usable websites.
I’ll compare Two Scoops of Django to Strunk and White’s The Elements of Style, that familiar freshman comp text, to explore how they are more alike than they are different. We’ll discuss the importance of readability, creating a “story arc” in your tests through good user stories, how variables names have characterization, and the importance of whitespace and good formatting to everyone. I’ll also compare PEP8 to the MLA Handbook; there’s a reason both disciplines have a style guide!
There's no single standard toolkit for deploying Django sites. In our years of consulting, we've seen lots of deployment systems in the wild and where they break down or cause pain. Independent of the system you use (Salt, Ansible, Fabric, Chef, Docker, etc.), there are a few principles a good deployment should follow:
Deployments don't take the site down or interrupt active users on the site.
Deployments don't involve more than one step or are completely automated.
Deployments are fast.
A failed deployment never takes down the current running version of the code.
Rolling back to a previous deployment is a single step.
By following these principles, deployments go from being error-prone, nerve-wracking experiences to trivial non-events in your daily development cycle. This talk will walk you through the steps necessary to create a better deployment process.
We talk about testing, code quality, and coverage. But why? Because we want to spend less time dealing with technical debt and more time creating new technical debt (aka new features). Many times, we think we made the obvious smart decision only to regret it later; you discovered you’re damned if you do, damned if you don’t. Should you write a monolithic app or tangle of microservices? They’re all terrible worlds we’ve made for ourselves. Having maintained, inherited, and created several large Django projects, I hope to share my experience so you don’t have to go through the same pains I did.
We’ll start off with a few minutes covering basics like testing, coverage and how they relate to the long term health of a project. Now, everyone knowing the same terminology, we move on to learning to recognize the many early warning signs and smells of excessive technical debt. The most important thing, and most of the material is about setting up the organizational structure for dealing with technical debt: code review, continuous integration, rotating developers (no silos), tradeoffs, making sure you have processes for onboarding new developers, and strategies for documentation. It’s changes like these that end up keeping things moving, not writing “better” code.
Finally, we’ll wrap up with a few minutes talking about Django specific tips: don’t customize the admin, tricks for naming things, signals, organizing tests, and more. Much of this comes from my time at The Texas Tribune, where we needed Django projects launched the next day, all while maintaining a 6 year old Django project.
This is the general outline I'm working from so far. I think this could change slightly as I develop the talk, but this outline conveys the general theme.
Introduction and display of basic django-debug-toolbar usage (2 min)
Things the admin does well (3 min)
Makes development very fast
For many use cases, it "does the right thing" automatically. For example, modifying the HTML in a callable won't cause new queries.
What can sneak up on you (5 min)
Having lots of related items visible in the list view
Overriding queryset for additional select_related and prefetch_related options
What to avoid in callables (3 min)
Queries that will be executed on every row
The default widgets for many-to-many and foreign key fields (3 min)
What widgets to use to replace the defaults based on how many options you have in your database
Custom aggregates in the list view (i.e. custom querysets) (3 min)
When this is a good idea
When this is too slow and you need other options
More general performance improvements through caching (3-5 min)
Django's caching framework
Caching with third-party packages / tools
Custom caching with Redis
Questions (Remaining time)
On the road to senior developer, one has to learn multiple languages. This often seems like a series of massive obstacles wherein each new language resembles a new beginning. However, developers may often underestimate the extent to which procedural knowledge from one language transfers to a new language. In this talk, I will demonstrate that the process from Red Hat Technical Account Manager to Django Girls workshop participant to OpenShift developer was a series of procedural knowledge transfers, wherein the obstacles to learning reduces with each new technology that is learned. I will provide specific examples, from using editors to troubleshooting issues, and conclude with practical recommendations on which language to start with and how to create a coherent plan for transitioning from one language to another.
Among the topics are:
A survey of the new Django 1.8 PostgreSQL features.
Using migrations with PostgreSQL in interesting ways.
Real-life applications of the new field types.
Basic model design for good performance on PostgreSQL.
This will be a moderated Q&A with a panel of Django authors. Questions will be collected in advance from community suggestions. There will also be time for some questions from the audience.
The panel will include:
Andrew Pinkham - author of "Django Unleashed" Mark Lavin - co-author of "Lightweight Django" Tracy Osborn - author of "Hello Web App" Peter Baumgartner - co-author of "High Performance Django"
I'm a web developer at the Planetary Rings Node, part of the NASA Planetary Data System. Our tiny shop is devoted to archiving, cataloging, and distributing scientific data sets relevant to planetary ring systems. Our base of operations is the SETI Institute, where a research community is busy searching for and studying life in the universe.
At the Rings Node I develop and maintain an outer planets space mission data search tool called OPUS which is built with Django. It lets users search data, browse images, and access its API via http. I'll talk about some of the reasons for OPUS, some of the challenges we faced in building it out and porting it - from a hot mess of php - to what it is today, and I'll talk a little about our plans for the future.
And we'll see some pretty pictures of the outer planets. :-D
Callisto (http://projectcallisto.org/) is an online reporting system designed to provide a more empowering, transparent, and confidential reporting experience for college sexual assault survivors. It's absolutely essential that we keep our user's data secure. So essential, in fact, that we couldn't leave it up to developers alone. We'll go over what Django settings, libraries and practices we used to ensure that on the development end. Then we'll walk through the process of obtaining, undergoing, and acting on a formal security audit from a professional security firm. You'll find out what they were looking for, what we missed, and how we fixed it, and how you might approach similar challenges for your companies and applications.
Free software advocates talk about two types of "Free": Free as in freedom, and Free as in beer. While Free (as in freedom) software is unquestionably better for users and developers alike, Free (as in beer) software doesn't pay the bills.
Talk to any prominent open source developer, and amongst the success stories, you'll also hear some consistent troubles - that they've got great ideas and grand plans, but no time to execute; that they're about to burn out due to the pressues of maintaining their project; or that they've had yet another mailing list discussion with someone who doesn't understand they're a volunteer. All of these problems stem from a fundamental disconnect: the discrepancy between the clear demand for a software product, and the ability to convert that demand into time needed to service that demand - and that means money.
This talk will have four parts:
Why Write Documentation
Read the Docs
The beginning of this talk will cover why you should write documentation. Every talk to developers about documentation I feel needs this part, because when you talk about docs people are inherently skeptical. Once people get on board that docs are important, you can cover more interesting concepts.
Then we will walk through the concepts around semantic documentation writing. Similar to Semantic HTML, this allows you to mark up your documentation with metadata that gives you a lot more power and flexibility around the display and authoring of documentation.
Then we’ll have a basic introduction to Sphinx. This will talk about the power that Sphinx gives you to write documentation, and examples of how to use it. We will also cover the semantic power of Sphinx, playing on the previous section to understand it in practice.
Then at last we’ll cover how to host your documentation on Read the Docs. This will make your documentation beautiful with a custom theme, and allow you to host multiple versions and formats of your docs.
The talk will include a basic demo of creating a basic documentation project, and getting it hosted on Read the Docs during the talk. All of the software will be running locally, so the demo won’t require an internet connection.
The Django documentation and tutorials are excellent. But, what happens after you've built your "Polls" application? Finding the next step can be difficult. It's hard to go from "Polls" to "Instagram" and still stay motivated and excited about your Django journey.
This talk discusses public data as a good next step. Public data covers every topic imaginable, is readily available (you can even make the government send it to you), and having a ready made dataset lets you focus on exploring certain parts of Django (templates, views, url routing, models and the ORM API) while leaving other parts for later.
In the tradition of the Lawrence Journal-World, many journalist/developers have built Django applications driven by public data. We'll take a look at some of these for inspiration and look at places to get public data. We'll see that one of the neatest things about using public data is that you can build some really cool and useful applications which will help you stay motivated when the Djangoing gets tough.
We'll also walk through a live example of an application built for the San Antonio Express-News that uses the city of San Antonio's restaurant inspections. We'll see that the models and views for this application are a good next step--not too hard, but still challenging--as you continue learning the Django data management pipeline.
We'll look at creating a full security program for a startup-sized company, one that can start quite small, but can be iterated on continually, and grown to match the growth of your business. This talk uses the conceit of a five day program, to be completed in a one-week sprint, but the steps could easily be scaled down to just a few hours, spread out, or otherwise modified to fit your time and organization.
Day 1 - Training: for a security program to work, it needs to be everybody's responsibility, not just a select few. So your first step in creating a security program is to establish a minimum bar for secure coding techniques. Luckily, basic secure coding is easily explained and taught, and there are great free guides and resources that can form the backbone of a simple, easy training program. On Day 1, you'll pull together these guides and create a training manual.
Day 2 - Secure Development Lifecycle: now we know how to write good code, but how do we ensure that best practices are followed? As we learn lessons about our own product and its security posture, how do we make sure those learnings are captured, retained, and applied in the future? The answer to these questions lies in creating a Secure Development Lifecycle, which is just a fancy name for procedures and checklists that capture your best practices, and help remind you of them as you ship new features. On day 2, you'll write those checklists, adopt some lightweight process, and being tracking your product security.
Day 3 - Incident Response: sooner or later, something will go wrong. When it does, will you be able to respond? Trying to make up an incident response process when something's already on fire is an unpleasant experience, and you can avoid it with a little bit of preparation. On day 3, you'll develop a basic IR plan, run a table-top exercise to try it out, and be ready to respond if and when something goes bump in the night.
Day 4 - Governance, Risk, and Compliance: there's an alphabet soup of security standards: ISO, SOC, SIG, PCI, HIPAA, FIPS, FISMA, FedRAMP... oh my! At small scale, most of these are formal attestations probably aren't worth the investment. However, at larger scale these ways of formally proving security standards start to become increasingly important. Completely ignoring formal risk programs can get you into a bind if you decide to pursue them later. Thus, on day 4 you'll lay the groundwork for a formal GRC program, making sure you're ready to start down this path once your business grows to that point.
Day 5: Brag about it! At this point, you've got a security program far better than most startups (and better than many established businesses). This is great! Security is increasingly a concern even for non-technical customers, and now that you've got a good story to tell, you should tell it! On day 5, you'll lay out that security story, publicly, and make sure your customers know about all your hard work.
Ricardo Ferraz Leal "Leveraging Neutron Sciences with Django"
Grant Jenks "Python Sorted Containers Module"
Tracy Osborn "Hello Web App Kickstarter Campaign"
Dan Dietz "Fabric Bolt"
Andrew Godwin "Channels Everywhere"
In 15 minutes, plus Q&A time, Postgres expert Josh Berkus will explain the essentials of making your database performance "good enough" that you can ignore it and move on to other things. This will include:
Why database configuration is less than 20% of performance
The 14 settings most people need
Why connection pooling is essential
Avoiding bad hardware
DB performance for the public cloud
Stupid things your app does which kills performance
Enjoy this fast-paced roundup of PostgreSQL performance essentials.
We have ethical responsibilities when coding. We’re able to extract remarkably precise intuitions about an individual. But do we have a right to know what they didn’t consent to share, even when they willingly shared the data that leads us there? A major retailer’s data-driven marketing accidentially revealed to a teen’s family that she was pregnant. Eek.
What are our obligations to people who did not expect themselves to be so intimately known without sharing directly? How do we mitigate against unintended outcomes? For instance, an activity tracker carelessly revealed users’ sexual activity data to search engines. A social network’s algorithm accidentally triggered painful memories for grieving families who’d recently experienced death of their child and other loved ones.
We design software for humans. Balancing human needs and business specs can be tough. It’s crucial that we learn how to build in systematic empathy.
In this talk, we’ll delve into specific examples of uncritical programming, and painful results from using insightful data in ways that were benignly intended. You’ll learn ways we can integrate practices for examining how our code might harm individuals. We’ll look at how to flip the paradigm, netting consequences that can be better for everyone.
Elasticsearch has many use cases, some of them fairly obvious and widely used, like plain searching through documents or analytics. In this talk I would like to go through some of the more advanced scenarios we have seen in the wild. Some examples of what we will cover:
Trend detection - how you can use the aggregation framework to go beyond simple "counting" and make use of the full-text properties of Elasticsearch.
Percolator - percolator is reversed search and many people use it as such to drive alerts or "stored search" functionality for their website, let's look at how we can use it to detect languages, geo locations or drive live search.
If we end up with some time to spare we can explore some other ideas about how we can utilize the features of a search engine to drive non-trivial data analysis.
React has become increasingly popular over the past year and is already used in large-scale products and companies such as Facebook, Instagram, Khan Academy, Hipchat and Netflix. This rapid success can in part be explained by React's performance qualities as well as its clean, predictable development workflow. To boot, its learning curve is very short despite it introducing a pretty radically different way of approaching front-end web development. Overall, React tends to greatly appeal to Django developers as both tools share the same philosophies of elegance and practicality.
In this talk I will present how React and Django can work together to build powerful, easier-to-maintain web applications with confidence. I will start with a brief introduction of React's key concepts: the Flux architecture, the virtual DOM, JSX and the React component life-cyle. I will then explain how React can integrate with Django-powered backends and discuss some advanced topics such as server-side rendering, isomorphic JS, animations, testing, production environments and integration with asset pipelines. Numerous code samples will illustrate the various concepts presented. By the end of this talk, members of the audience who are unfamiliar with React will have a good grasp of its functioning and of its benefits; those already familiar with React will also have learned several useful tips applicable to their Django projects.
There are only two hard things in Computer Science: cache invalidation and naming things. -- Phil Karlton
This quote finds its way into many-a-talk about caching systems (including my own), and sometimes we as developers will recall it when we spend an hour to name that one nebulous variable. But why is something so difficult as nomenclature also thought of as too simple to actually talk about?
In this talk, I'll review what has been written in the last few decades on naming, go over the easy parts of right or wrong as defined in PEP8 and other style guidelines, and finally suggest some patterns and anti-patterns found in in today's Django and open source environment for us to adopt (or avoid!) in our everyday naming of variables, libraries and other "things".
Getting Started with Selenium
Waiting on actions
Unittesting with QUnit
Tests and assertions
Universities and other enterprises often deploy a complex mix of systems for managing identities and permissions for students, faculty and staff. Standard LDAP, Google Apps for Education/Enterprise, Student Information Systems, hiring systems, CAS/Single Sign-On, and more must all work together without conflicts or delays. At the California College of Arts, we've created a Django-based system to help end-users and staff create and manage identities, passwords, groups, permissions, and more. Scot Hacker will demonstrate the system and provide a tour of its strictly decoupled internals. The system is unusual in that it uses almost no data modeling of its own, relying instead on communication via python-ldap, Google and Workday APIs, and old-school file shuffling to negotiate communications with other systems.
The performance of your application affects your business more than you might think. Top engineering organizations think of performance not as a nice-to-have, but as a crucial feature of their product. Unfortunately, most engineering teams do not regularly test the performance and scalability of their infrastructure. Dustin Whittle shares the latest techniques and tools for performance testing modern web and mobile applications. Join this session and learn how to capacity plan and evaluate performance and the scalability of the server-side through Siege, Bees with Machine Guns, and Locust.io. We will dive into modern performance testing on the client-side and how to leverage navigation/resource timing apis and tools like Google PageSpeed and SiteSpeed.io to understand the real world performance of your users. We will cover how HTTP2 and modern browsers change the game for performance optimization with new best practices. Take back an understanding of how to automate performance and load testing and evaluate the impact it has on performance and your business.
We all are constantly learning new technologies and strategies to be more effective at our jobs, or just because they interest us. How do you balance the need to stay on top of the latest and greatest changes in our industry with making a product? How do you take a new hire with amazing potential and help them learn everything they need to know, while shipping at the same time?
Shipping code as soon as possible isn't a cutthroat business decision. It helps people learn faster, be more effective, feel more valued, and keeps them centered on the right goals.
How do you balance learning with shipping code? Is there any reason they have to be separate? Too often we feel that these are discrete tasks.
Benefits of learning technology by applying it to real world problems are: - Fixing a real world problem - Learning something that is immediately useful - Remembering it better than if you had learned the theory
Dangers to consider include: - Not everyone learns the same way - Real world problems can be vastly more difficult than you expect, unless you've already solved them - Revealing embarrassing legacy code and decisions earlier than you'd like
We all like pretty graphs, but determining what to collect and actually collecting the data are often pushed down the road because of the complexity. Learn about simple ways to collect and use metrics from day one. You'll learn about:
What to collect
How super easy it can be
Techniques for collecting today, but using tomorrow
Processing your metrics out of band to not slow down your code
Tips for scaling in large systems
Visualizing your metrics with Graphana
Through the past years is being noticeable the interest of our industry in increasing the diversity as whole. People are getting more conscious of the importance of having a balanced team and how it is beneficial to be so.
This talk is not about gender war, of how one gender is better than another. Is about how having that balance the productivity and innovation can increase to make it a sucessful team.
Dmitry Filippov "Django assistance in PyCharm"
Paul Bailey "End the Holy Wars of Formatting"
Eduardo Rivas " Sublime Text