Alicia will discuss the challenges she faced as an African American woman in becoming an iOS developer at the age of 51. As a self-taught developer, she created a mobile app dedicated to helping victims escape domestic violence and abuse. She has seen the best and worst of the tech community. As demonstrated by her app, she believes that the tech industry can improve and change lives if we open our arms, embrace change, and think about how women can change the way we see and create apps.
As the universe of IoT continues to grow at a rapid pace, our abilities to interact with these devices can be useful. As an added bonus, developing these skills can be fun too!
I’ll take you through my journey of developing my first Alexa skill in Python for Amazon Echo devices aptly named Happy Days. It is a random quote generator that delivers positive quotes. I’ll go over the skills of how to get Python to talk to Alexa and how to dump that code into Lambda for a seamless delivery between Amazon Web Services and the Alexa Skills Kit in just a little over 200 lines! Never developed an Alexa skill before? Don’t worry, I hadn’t either. I’ll provide plenty of resources to help get you started on a path you’ll never want to leave as an Alexa developer.
Building an Alexa skill helps:
Further develop your own skills in Python.
Gain familiarity with Amazon Web Services’ Lambda service which allows you to run code without provisioning or managing servers. BYOC - Bring your own code! (Python, Node.js, Java, and C#).
Gain familiarity with Amazon Web Services CloudWatch service which helps monitor and log activities with your Amazon Web Services resources which is helpful for troubleshooting.
Gain familiarity with the Alexa Skills Kit which is the platform behind Alexa development.
Learn about tools and resources you can take advantage of to ensure you have a meaningful development experience.
Learn how to “talk” to the Alexa Skills Kit through your Python code.
Helpful reminder that user experience is key!
The year is 2017. We have hoverboards, jetpacks, solar-powered cars, and also so many awful passwords that it’s become trivial for pretty much anyone to have their accounts compromised. We’ve got passwords for our passwords. Eight-year-olds with a dictionary and a set of dice can generate mathematically stronger passwords than most corporations that have your credit card details. We spend our days wandering through endless forests of requirements to come up with something that contains no more than twelve letters, a special character, the eye of a newt, and at least one uppercase letter, only to be emailed it back in plaintext if you forget it. And then it goes on a Post-It note on a monitor.
Do not despair - this talk is here to help!
From beginners to experts, all technical folk have the power to build a post-password future. Lilly, an engineer and historian, will guide you through the history of how we got ourselves into this state, and explain why major companies still think that the best way to keep your stuff secure is to poke their heads out of the tree-house and ask you for the secret word. She will then hand you strong technical tools to help your clients and colleagues understand why there are better things out there than “Welcome1!”, and help you work together to bring a small ray of sunshine into our password-saturated world.
00:00 Andrew Godwin
04:14 Simon WIllison
09:16 Katie McLaughlin
13:21 Dr. Russell Keith-Magee
18:00 Andrew Pinkham
20:27 Adam Fast
25:13 Josh Schneier
30:09 Kojo Idrissa
This talk will go through accessibility concerns on the web through example sites and code with both good and bad accessibility to experience what some users have to struggle with daily. We will cover well-known concerns such as low vision/color blindness and deafness, as well as attention issues and autism, and discuss the limitations and abilities of various alternative input devices that people with motor control issues rely on. Short and long-term fixes will be demonstrated and taught, with the overall goal being that the participants leave knowing how to find and solve accessibility problems.
Why Bother With Accessibility
Not only should you want everyone to be able to easily use your site, but having an accessible website comes with a variety of benefits. According to the U.S. Census Bureau, around 19% of Americans have a disability, which is a large potential audience for any site. Many companies also fall under accessibility laws they might not even be aware cover their products, with lawsuits becoming more prevalent in recent years, and showing a good faith effort to improve your products’ accessibility can help keep your company out of hot water. Accessible web development also tends to lead to better UX and a happier user base. And, another plus: It will save devs time and frustration when they’re working with the code, since good HTML is enforced.
Who This Talk Is For
Anyone who wishes to learn more about accessibility. While we won’t be going over the absolute basics of accessibility in detail, the examples and resources will be easy to understand for people with very basic knowledge of web development.
Spreadsheets are OFTEN terrible. They’re also everywhere! As one of the default forms of data exchange, learning to work with spreadsheets directly via Python can save time and effort. We’ll look at Openpyxl, a library that lets you do just that. We’ll look at at least two different (beginner-friendly)example cases: transforming one spreadsheet into another spreadsheet and converting a spreadsheet into JSON. I’ll also use my experience as a former accountant to highlight some of the issues around reading from and writing to a spreadsheet file and how you might deal with them. You MAY even learn to make new friends and grow the Python community! True Story!
You maintain an Open Source project with great code? Yet your project isn’t succeeding in the ways you want? Maybe you’re struggling with funding or documentation? Or you just can’t find new contributors and you’re drowning in issues and pull requests? Open Source is made up of many components and we are often better-trained in methods for writing good code, than in methods for succeeding in the other dimensions we want our project to grow. In this talk we’ll explore the different components of an Open Source project and how they work together. After this talk you’ll be well-equipped with a ideas and strategies for growing, cultivating, and nourishing your Open Source project.
For your project to succeed, all of its non-code components must be well-maintained. What are these different components and what methods can we learn to maintain them?
Build real relationships with your sponsors and determine ways how both sides can benefit from this relationship, don’t just ask people for money.
Establish a good communication system with your contributors: Keep them informed, listen to their feedback and input, make them feel heard.
Thank the people who worked on ticket triage or marketing, not just those who wrote code, in your release notes.
Make it easy for new contributors to get started: Write and maintain good documentation, answer questions in a friendly and timely manner.
Market and evangelize in the right places and at the right time: Give conference talks, organize sprints, keep your project’s Twitter account active, always curate new and interesting content on your blog or website.
Implement a Code of Conduct and enforce it if needed: Make your project a safe space to contribute for everyone.
With these methods and a half-dozen others, you’ll handle beautifully all the components your project needs to succeed.
Introduction - Who am I? What is this talk about?
What is Open Source?
Overview of the different components that make up an Open Source project
Growing, cultivating, and nourishing your Open Source project - Or how to make your project more successful
Cultivating new contributors
Keeping current contributors happy
Efficient and sustainable processes
Managing the pull request queue
The pillars of FP
Let’s start by looking at the core concepts that differentiate FP from the OO / imperative style most programmers are familiar with. Along the way I’ll introduce you to:
Immutable data structures. Having data structures that don’t change makes your code safer, especially when dealing with concurrency and parallelism, but they require you to approach solutions in a different way than you would with mutable data.
“Pure” functions. Pure, or idempotent, functions do not mutate state or cause other kinds of side effects. As a result, you are guaranteed that every time you call a function with the same parameters, you will always get the same value.
Recursion: While recursion is something most of us know about, it’s not something we tend to use often in imperative programming, and with good reason. Nonetheless, it’s a worth knowing about it’s various forms.
Function composition. When you have pure functions that handle only one task, you can build larger, more complex and more beneficial programs by composing functions together to form new functions.
First class functions: passing around functions as parameters and return values, just like any other object.
The holy trinity: map, reduce, filter. These three functions are the work horses of FP, helping us manipulate and transform data quickly and elegantly.
FP in python
Now, let’s take a look at how we can or cannot apply these concepts in python.
While most data structures in python are mutable, tuples are a built in immutable data structure that we have at our disposal. We’ll see that tuples have a solid place in python, but they’re not as easy to work with as we might like.
Recursion isn’t really well developed in python (on purpose) so let’s take a look at it’s pitfalls and how to avoid them.
Function composition is something you probably already do some in python and perhaps don’t even know it.
Filter is easy, we just call it “list comprehension”
Reduce. Let’s try to get beyond flattening nested lists and doing tricks with math.
Map. You probably don’t use this enough in python so let’s see if we can change that.
FP is great! Maybe.
Now that we’ve seen how FP can be used, we really need to decide if it should be used. Python is not a functional programming language, despite the tools it has. We’ve talked about some of the technical drawbacks to these tools, but we also need to decide if working in an FP paradigm is right for our work environment. We’ll look at some examples of where running into FP can be jarring and talk about the additional cognitive load on co-workers who aren’t used to seeing these tools in place.
I built Susy, a Sass grid system that can generate any grid technique you like — but I haven’t used it in years. I’ll show you how various grid systems work, and how to avoid using them. For those few cases where a grid really is required, we’ll talk about the best ways to roll your own, so you’re not relying on a bloated library to make decisions for you. We’ll also look at the new layout toys, from flexbox to CSS Grid, and how to get started with only a few lines of code.
When to use floats, CSS Grid, flexbox, custom properties, and other techniques.
How to make grid-math simple, and lose the grid-system.
How to make existing grid-systems work for you, when you’re stuck with them.
This talk is aiming right at professional or experienced amateur Django developers who want to learn about one of the core technologies used in modern web apps. We’ll do our best to make it accessible for all, but it’s going to be best to come in with working knowledge of web applications and a rough understanding of web servers.
We’ll be covering how uWSGI serves Python web applications, how it manages workers and processes, and how it works with the operating system to handle networking. Our goal is to show how this works both in code and through abstractions, recognizing that different audience members are going to grasp things in different ways.
The hope is that attendees will walk away with a working of knowledge of how their apps interact with the network and the operating system through uWSGI, and that a commonly-used but less-understood piece of software will become demystified.
Even though open-source collaborators and code reviewers are needed more than ever, the few git learning resources that focus on these subjects are not beginner friendly. This is a missed opportunity! As the DjangoCon US Website Chair, I review pull requests submitted to the website repo. This has given me the opportunity to develop a beginner-friendly, best practice GitHub workflow. I can jumpstart your collaboration and code review skills by sharing what I’ve learned with you. This talk is for anyone, but one of my goals in giving it is to encourage other women to take leadership roles.
Introduction: We read to know we are not alone
Is there something you would change in the world if you were a wizard?
Make vulnerability your cloak
Make determination your hat
Make code your wand
What do you care about?
We care about girls and women being enabled to choose their future
We care about increasing diversity in the trade we love
We care about arming children with the confidence that they can do anything
Why are we here?
We’re trying to use our programming skills to make that a reality. It’s a journey, one we invite you to join for whatever you feel strongly about. We were not the first, we were definitely not the best, and we won’t be the last. But sometimes, inspiring people to help is just as hard (or harder) than helping. We wanted to give this talk to show others that it CAN be done and YOU can make a difference - regardless of your skill level or experience.
1. The Use Case
Listening: “I’ve been wanting to teach Python for a while but we don’t have anyone.” - Girl Scout Leader
Acting: “I can do that!” - [Presenter 1] (even though she was pretty sure the ideal person was way more experienced than her)
Deliverable: The Hackathon - A Python challenge for both beginner and advanced coders. Two classes, 25 girls each, ages 10-18 years old.
2. A Master Plan
Check out our options: We reviewed existing resources, but didn’t find anything to meet our needs (list some of the good resources we found and were inspired by)
Make a decision: “Let’s write our own!” - [Presenters] (because nothing that’s out there fits in two hours…)
Have a Cool Learning Experience: Coding the game and taking our first stabs at writing the tutorial were great learning opportunities for us!
3. The Dream Team (AKA: Help!)
The Pair Programmers: Gaining perspective and tripling productivity, Megan and Jessica start figuring out what to teach and begin making the tutorial come to life
The Project Manager: Added for some very necessary skills - making things looking professional, doing a code freeze, checking our spelling, and making sure the presentation is consistent
The Coaching Team: With a common goal and united front, an all female team of software developers, engineers and IT managers unite to form a coaching group!
4. Go Live
Hot Fixes: The girls begin the tutorial and questions come rolling in. Confusion abounds. They don’t know what a Start button is! Nothing shows them their opinion matters like change, so we began live editing the tutorial! Being vulnerable, admitting imperfection, and not taking it personally evolved the tutorial in real time to fit our audience. It also gave the girls a sense of inclusion that was priceless; even though they weren’t writing the code to make the edits, their voice was heard and their suggestions were implemented in real time - a powerful way to build confidence!
Unexpected Popularity: The girls were engaged! Among raised and waving hands and the din of voices, we kept our cool and took each issue one step at a time. Frankly, we were all a little in shock.
Better than we imagined: We might have expected too little of ourselves, but when all was said and done - the girls felt successful, they were all engaged, and their parents were inspired to learn for themselves or keep their girls involved with code going forward!
Simplification: It was late and everyone was tired - make things simpler, have more milestones, include more affirmations
Organization: Planning pre- and post- tutorial huddles to get to know each other and set expectations, figuring out how to guide/redirect parents who were doing the tutorial for their child, investigate letting the girls try pair programming
Keep Building: We are still working to evolve our tutorial, make it more accessible, make it friendlier for our target age group, make it packaged to shared, and shopping it around to other tutorials as an expansion (we’re looking at you DjangoGirls ;) )
6. An Ever Expanding Universe
Sharing is caring: We did it and so can you! Expanding the number of contributors as well as the project scope will only make things better! So, we will share our code, share out tutorial, share our experiences, and share our enthusiasm with anyone who wants to make a change!
You have a lot of power, in the you code help create, in the people you mentor
Don’t wait for someone else, endowed with imaginary super coding/people skills, to help create the change you want -do what needs to be done
Don’t try to be a panacea, focus on a single thing and do it well
Contact us! Let us know if you’re interested in building something or want to do something similar to what we did
This talk will feature a few off-the-beaten-path applications of APIs. Since the combination of Django and DRF makes it so easy to get a simple API running, it becomes a very powerful, flexible, and expandable tool for a variety of uses. The only thing these applications may have in common is their need to share data across the web. Whether you have not yet tested the waters of Django Rest Framework or you are a DRF veteran, this talk will inspire you to think both big and small when considering its potential uses.
The Django documentation section on testing starts with this: “Automated testing is an extremely useful bug-killing tool for the modern Web developer.” Nobody can argue with that. Testing is an integral part of modern software development, and Ana’s talk will offer an in-depth overview of how the Django testing framework evolved; showcase some common techniques, tools, and best practices; talk about speed improvements; and guide you through a real-world example of testing a Django app. Testing is fun, isn’t it?
Welcome to the advanced class on community organizing. You’ve got a decent amount of members in your Meetup.com group, you hold events fairly routinely, maybe you’ve pulled in some legit speakers at your last conference or event … and you want to do more. This talk will focus on community organizing for growth and longevity by building out teams, improving communications, implementing processes, and most importantly will discuss how to maintain sanity in your work-life-volunteer balance. If you’ve ever had to answer the question “Oh, this ISN’T your full time job???” - this talk is definitely for you. If you’re just starting out organizing and don’t want to fall flat on your face, this talk will be very pragmatic for you.
You’ve probably heard the buzzword by now - “serverless”. It’s a new type of application architecture where traditional web servers are replaced by ephemeral cloud services. But what does it mean for the average Django user? Hint: lower costs, more scalability, more capabilities and less ops tasks to worry about!
First, this talk will explain what “serverless” really means for you, and provide an overview the advantages and disadvantages of event-driven server-less architectures.
Next, we’ll demonstrate how easy it is to migrate your existing Django CMS application to run on AWS Lambda by using the Zappa framework, including some real-world issues you might bump into.
Then, we’ll show how to implement some of the most common Django patterns as part of a server-less architecture - uploaded avatar image processing, batch and timed sending of email, and long running tasks like statistical aggregation.
Finally, we’ll show how to scale up your server-less application to trillions of events per year by distributing your app to dozens of data centers all around the globe, and do an ultimate cost analysis of your new system.
You’ll leave with new ideas on how to save money and stress on your existing applications and cool new ways to implement features in your next app!
Django’s User model is nice, but the fields it provides out of the box are minimal. We frequently need to associate our own custom data with a user, and luckily Django provides ways for us to add to its built-in User model. This talk will help novice Django developers understand which options are best when it comes to getting the most out of the Django User model.
I’ll start by talking about the built-in Django User model and what it has to offer.
Then I will identify scenarios when the User model might not be enough for a project, and why someone might want something with more flexibility. Then we’ll look at the different ways to get the most out of the Django User model. There are two main methods I’ll cover:
Extending the User model
Creating a custom User model
Extending the User model:
Extending the User model is handy when you only need to add a few extra fields. There are two main ways to do this: using a proxy model, and using a OneToOneField. I will cover the pros and cons of each, and give examples for implementing each.
Creating a custom User model:
With this method, you can substitute Django’s default User model with your own. Though more complex, a custom User model is particularly useful when you need to uniquely identify users by email address instead of by username. I’ll go into a couple more scenarios where a custom User model would be helpful, and show examples of implementation.
Lastly, I will show how each method works with the default Django admin, and how they can be managed there.
If you’re a beginner about to embark on a new Django project adventure, this talk is for you.
When I started my first Django project, I took the “Sure, I think I can figure that out” approach, which is fun! And also dangerous. But exciting! And also horrible because I caused myself a lot of trouble and barfed on my keyboard. (Metaphorically.) Oops.
My hope for this talk is to pass along lessons I learned the hard way, and save the world. Or at least prevent some frustration. :) We’ll talk about version control, structuring your project, and how to handle top secret stuff. We’ll also talk about throwing house parties without causing anaphylaxis, pregnant daddy seahorses, velociraptors, and friends. I promise all of that is related to Django.
00:00 Filipe Ximenes
05:42 Paul Bailey
10:53 Richard Latimer
19:14 James Bennett
24:11 Wayne Merry
28:54 Tim Allen
34:23 Vic Yang
35:26 Dan Dietz
Reproducible results can be the bane of a data engineer or data scientist’s existence. Perhaps a data scientist prototyped a model some months ago, tabled the project, only to return to it today. It’s now when they notice the inaccurate or lack of documentation in the feature engineering process. No one wins in that scenario.
In this talk we’ll walk through how you can use Django to spin up a Docker container to handle the feature engineering required for a machine learning project and spit out a pickled model. From the version controlled Docker container we can version our models, store them as needed and use scikit-learn to generate predictions moving forward. Django will allow us to easily bootstrap a machine learning project removing the downtown required to setup a project and permit us to move quickly to having a model ready for exploration and ultimately production.
Machine learning done a bit easier? Yes please!
Do you pride yourself on your post-it and Sharpie collection? Do you set appointments for yourself in your own calendar - that you actually show up for? Do you write to-do lists on your hand, since you’ll forget if the to-do isn’t right in front of your face? Do you own - and use - a label maker? Do you hate New Year’s resolutions because the whole idea of starting new habits on January 1 is an artificial construct?
People are weird. We all have some pretty particular ways we think, work, and get motivated. It’s hard enough when we’re just trying to focus on ourselves, but it gets even more complicated when we add other people to the mix. What happens when a whiteboard person has to work with a spreadsheet person - or even harder, lead a whole team of spreadsheet people?
This talk will focus on practical tips for working better with others - especially when you’re in a leadership or management position, although we all lead in different ways. We’ll start off with an overview of productivity and motivational styles, identifying how they influence the way we all think and work. Then, we’ll pinpoint how our own personal productivity and motivational styles impact us and those around us. After that, we’ll figure out how to look for clues about our colleagues’ working styles. Finally, we’ll talk about strategies for bridging our working styles with those of the people around us. You’ll leave with insights about what makes you tick, plus actionable tools to improve your leadership skills and enhance your working relationships.
As a Middle School computer science teacher, I know enough to be dangerous, but not enough to consider myself a “real” developer. As a member of the curriculum team at Code.org (a nonprofit dedicated to providing all students with access to CS education), I knew that our combination of rendered markdown files and Google docs was far from the most effective way to write and deliver curriculum. If only we could schematize our curriculum writing, I thought, we’d be able to write more consistent lessons with better support for teachers to see which lessons are aligned to which standards, or where a given concept was first taught.
When I brought this proposal to our engineering team everyone was excited about the idea, but there was no way we had the bandwidth to actually create it. Our small team of engineers are booked solid building tools for students to learn programming and for teachers to manage their classes. When it comes to the needs of our curriculum writers, we obviously need to come after the students and teachers. But wait, I know how to program. I did the “Two Scoops” tutorial. Why couldn’t I make the tool I had dreamed of?
Using Django and Mezzanine as a base, I gradually built a system that allows Code.org curriculum writers to write faster, more consistent, and better supported lessons at a massive scale. Along the way, I also dealt with the very real concerns of my engineering team. How can we be sure this will scale to our 10’s of thousands of teachers? What about our millions of students? How can we be certain that this doesn’t introduce new security vulnerabilities to our site? Are you sure you know what you’re doing here?
The answer to all of these problems was surprising simple, and has allowed me to address the needs of our curriculum team without taking the engineering team’s focus away from the customers that really matter - teachers and students.
After many months of development, CurriculumBuilder has become an essential internal tool for curriculum writing at Code.org, and continues to find new ways to solve problems that would otherwise go unaddressed. Not bad for a Middle School CS teacher who had never before written software used by others.
Communication is difficult. Whether between humans, machines, or a combination of the two, trying to translate meaningful information is a lossy process.
Converting programming languages to use the new Unicode standard is hard, but once it’s in place, you get this marvelous feature-add: emoji compatibility. No longer do we have to make faces with symbols or use platform-specific emoticons. Rejoice in the extended character set.
Emoji have a rich history as a way to allow the communication of ideas in a reduced amount of data. They date back to a time where this was important: SMS communications in Japan. However, as social networks feverishly try to clamber onto this bandwagon, their implementations of the standard create issues with miscommunication that aren’t possible with a 12×12 pictograph.
We’ll discuss the history of emoji, cross-platform adoption, the Unicode standard, and emoji accessibility in web applications. :sparkles:
Not only is Kubernetes a great way to deploy Django and all of its dependencies, it’s actually the easiest way! Really!
Deploying multi-layer applications with multiple dependencies is exactly what Kubernetes is designed to do. You can replace pages of Django and PostgreSQL configuration templates with a simple Kubernetes config, OpenShift template or Helm chart, and then stand up the entire stack for your application in a single command. In this presentation, we will walk you through the setup required to deploy and scale Django, including:
Replicated PostgreSQL with persistent storage and automated failover
Scalable Django application servers
Front-ends and DNS routing
The templates covered in this presentation should be applicable to developing your own Kubernetes deployments, and the concepts will apply to anyone looking at any container orchestration platform.
Refactoring major components of a live application with many users can be daunting. The stakes are even higher when the users are paying for your product. This talk covers how to approach building and incrementally deploying a complex refactor. Using a case study, I will walk through what makes major refactors so challenging, what you should avoid, and what can make them easier in the future.
When my daughter appeared on the scene in October 2017, my life was turned upside down.
As I was returning to work, I found that previous strategies for managing my time weren’t up to snuff and I needed to create new ones if I was to be effective at my craft. No longer did I have 15 minutes to “get in the zone” - I needed to get things done in any time available. I learned to carve milestones out of minutes (sometimes) and will share what did (and didn’t) work for me.
I also share stories about my general journey of becoming a parent that may be helpful to anyone thinking about becoming a parent (or just wondering what it might be like!).
Or you could just come to the talk for the cute baby pictures - they make everyone smile!
When it comes to web development in Python, Django isn’t the only game in town. Flask is a scrappy young framework that takes a very different approach – whereas Django ships with tons of features ready and eager to be used, Flask provides a bare minimum feature-set with rock-solid extensibility and incredible flexibility. This talk, given by a web developer who has experience with both frameworks, takes a good look at the pros and cons for both Flask and Django. If you’ve ever felt that Django is too hard to learn, or too inflexible, this is the talk for you!
What is Flask?
Django vs Flask
Example “hello, world” websites
Django ORM vs SQLAlchemy, Peewee, etc…
django.contrib.auth vs Flask-Login, Flask-Principle
Django Admin vs Flask-Admin
Django apps vs Flask Blueprints
Django REST Framework & comparisons to Flask
Which is better? Depends on your use-case
One of the most confusing parts of Django for newcomers (and some old hands alike!) is the handling of files. Among the 10+ settings, static vs user uploaded distinction, and plethora of deployment options it’s no wonder that many people end up cargo-culting their production settings.
The API overview
Go over the difference between static & media files
Run through the File abstraction and the various settings
Django Storage API, collectstatic etc
Production & Development configuration
Whitenoise/dj-static/Nginx for static files
Cloud storage providers for media & static files (S3 etc, mention some popular libraries such as django-storages)
Implement a storage engine together & the future
Implementation - practicing what we just learned to solidify understanding
Closing remarks and mention possible future Django developments
Abusive behavior can have profound effects on personal relationships but it can also make open source contributing and office life miserable. For those stuck in a team with co workers who exhibit toxic behavior, going to work every day can feel like going to a battlefield. Knowing how to identify and how to respond to unreasonable behavior is vital. In this talk we will look at the ways we can improve our office and FOSS communities by recognizing, managing and gracefully removing this toxic behavior.
What abuse looks like
How it affects those around it
Steps to take if you are the target of abusive behavior
How to manage toxic people in your project
As a trained linguist and former university language instructor, people often assume that my natural language* (spoken, signed, or written) learning analysis background made learning to code easier for me. They might say something like “That makes sense, they’re languages, right? They have syntax.” These casual comments seem true on the surface when talking about parts of speech and variable types. But once you dig deeper, it becomes clear that there are far more differences than similarities between these types of languages despite the shared name. However, many skills and methods I have utilized in learning languages and teaching languages as an adult to adults have served me well as a developer.
This talk first addresses key points of divergence between learning a natural language and a programming language. Perhaps most importantly, natural languages are meant for communicating with people and programming languages are meant for giving a computer directions.
However, many areas of overlap exist in learning and perfecting these skills; these shared aspects of learning are the primary focus of this talk. (* And, yes, that’s the same ‘natural language’ as in ‘natural language processing.’)
Over the last 10 years (and really, her entire life), Tracy’s struggled with anxiety while running her own business, navigating negotiations, and self-publishing several books. This keynote will go through recommendations for keeping your sanity in a dog eat dog world, reducing anxiety, feeling comfortable with negotiation, and above all, being the best advocate for yourself that you can be.
While some code happily lives on a single server forever, most big projects will have to cross the boundary into running both their application and storing their data across multiple systems. The basic strategies are well-known, but we’ll take a look at what to do as you cross the painful threshold where you can’t run your app as a monolith or store everything on a single database server.
Among other things, we’ll look at how to split up business logic and application code to run on different servers, how to scale to handle different kinds of web traffic (read-heavy, write-heavy, and long-connections/WebSockets), when and how to make parts of your code not run inline with HTTP processing, strategies for storing data across multiple machines, and how to structure your engineering team to best cope with all these changes.
We’ll also look at a few apparently innocuous decisions and the spiral of bad performance they lead to, and how to recognise some of these common problems so you can avoid them yourself in future.
Since being released by Facebook in 2015, GraphQL has gained a lot of hype for being the best thing since sliced bread and REST APIs. But what is all the hype about and how does GraphQL fare in the real world?
As a Django developer who has been using GraphQL in production since September 2017, I will discuss how we have addressed real-world concerns like performance and security. I will also highlight some of the joys of using GraphQL and why we have stopped writing REST APIs for new features.
If you have never heard of GraphQL or have never used the Graphene library, have no fear. There will be an overview of what GraphQL is, as well as a demo on how to incorporate it into a Django project using Graphene.
While it’s very common to enforce PEP8 code style with tools like flake8, it’s rare for Django projects to use any other types of tools for automated checks. However, linters and automated checks are a good way to enforce code quality beyond code style. Human-based code reviews are great, but if an experienced programmer leaves the organization, all quality-related knowledge they have will be gone. One way to prevent this is to make developers consolidate their knowledge as custom check tools. Instead of repeating to every junior programmer how they should code, experienced developers should write tools to do that for them. Having this kind of “executable knowledge” is great to ensure long-lasting good practices in organizations.
Thankfully, Python already has a number of extensible linters and check tools that can be used to consolidate knowledge. Also, Django has the System check framework, which can be used to write custom static validations to Django projects. In this talk, we’ll discuss existing linters and tools, what benefit they bring to Django projects, how to extend them and how to build custom ones. Combined with IDEs, pre-commit hooks, and CI tools, linters can validate code at programming time, commit time, or CI time, thereby ensuring good practices in all development workflow.
00:00 Kelsey Hawley
05:20 Eric Holscher
10:26 Laura Hampton
12:40 Jeremy Gatens
18:10 Buddy Lindsey
23:08 Nicholle James
28:30 Wayne Merry
33:16 Mike Hansen
38:12 Kenneth Reitz
Web applications have changed significantly over the years – from simple static pages, to sprinkling interactiveness with JQuery/AJAX, to full dynamic single page apps. Through each evolution, we’re adding more complexity, more data and more asynchronous behavior to our applications.
In this new world, where does the synchronous nature of Django’s request-response cycle fit in?
My talk will focus on the topics around asynchronous Django applications. I’ll be sharing some lessons we learnt while building and scaling an interactive web application within the confines of Django and django-channels.
This topic is interesting because there’s been a lot of interest with meteor-like frameworks that have synchronized state between the frontend and backend. My intention is to show the audience that you can accomplish the same end-result with Django, without the need to learn and deploy a brand new framework.
An outline I have in mind:
What does asynchrony mean, and why you need it.
Traditional methods of achieving asynchrony (delayed jobs using worker queues like celery, long-polling for messaging, etc.)
Why django-channels changes the game.
How to architect your state.
What are the available options for deployment.
Gotchas, and what to do when things go wrong.
Just a basic knowledge of Django is required, as the topics are transferable to other frameworks. We did not have to monkey-patch any of the drivers to achieve asynchrony, so what you’ll learn at my talk will apply cleanly to a stock Django.
Most web applications need to offer search functionality. Open source tools like Solr and Elasticsearch are a powerful option for building custom search engines… but it turns out they can be used for way more than just search.
By treating your search engine as a denormalization layer, you can use it to answer queries that would be too expensive to answer using your core relational database. Questions like “What are the top twenty tags used by my users from Spain?” or “What are the most common times of day for events to start?” or “Which articles contain addresses within 500 miles of Toronto?”.
With the denormalized query engine design pattern, modifications to relational data are published to a denormalized schema in Elasticsearch or Solr. Data queries can then be answered using either the relational database or the search engine, depending on the nature of the specific query. The search engine returns database IDs, which are inflated from the database before being displayed to a user - ensuring that users never see stale data even if the search engine is not 100% up to date with the latest changes. This opens up all kinds of new capabilities for slicing, dicing and exploring data.
In this talk, I’ll be illustrating this pattern by focusing on Elasticsearch - showing how it can be used with Django to bring new capabilities to your application. I’ll discuss the challenge of keeping data synchronized between a relational database and a search engine, and show examples of features that become much easier to build once you have this denormalization layer in place.
Use-cases I explore will include:
Finding interesting patterns in your data
Building a recommendation engine
Advanced geographical search and filtering
Reacting to recent user activity on your site
Analyzing a new large dataset using Elasticsearch and Kibana
There is an ongoing mantra within the developer community: that there are far more jobs available then programmers to fill them. Which should be an indication as to the wonderful potential for both business and those learning to code. Yet what often follows such statements are not words of joy but rather a list of frustrations related to the difficulty in finding and retaining enough skilled developers to fill these positions. The challenge is not in the number of newbies entering the field but the number who leave because they are not able to bridge the divide between bootcamps, online tutorials, books, videos, etc. to an employable developer who is able to contribute to the team. Kim has years of experience working with learners of various ages in helping them develop the skills they needed to be successful at whatever their chosen goal. She understands that for businesses to be successful, they must develop more effective and efficient ways of recruiting and retaining developers in order to meet organizational benchmarks. The developer community is a overwhelmingly generous one and a well designed mentoring or apprenticeship program could be one answer that business leaders and newbies are looking for.
The business costs associated with corporate hiring managers inability to recruit and retain skilled workers to fill current and future entry-level positions are increasing (Queen, 2014).
89 percent of organizational leaders stated that they are having difficulties filling open positions, which is causing them to either turn down orders, miss key deliverable deadlines or hire individuals from outside of the United States (Aho, 2015).
Aho, K. (2015). The robotics industry: creating jobs, closing the skills gap. Techniques, (7), 22. Retrieved from https://www.acteonline.org/techniques/#.VpMcQq6rR0s
Queen, J. (2014). Hire power: to close the skills gap, states are teaming up with industries that need, but can’t find, qualified workers. State Legislatures, (8), 16. Retrieved from http://www.ncsl.org/bookstore/state-legislatures-magazine.aspx
This talk is an opportunity for you to explore practical ways of improving the test code you write. Unit testing can be challenging, but with the right toolbox of techniques, it is much easier to write unit tests that not only enable high degrees of code coverage, but assurance on each action of your code.
Django provides an excellent test environment that facilitates testing across the whole of a project, however Django’s documentation and many online examples focus on integration tests. Any typical use of the Django test client is an integration test. Tools such as selenium also provide a frame work for usability tests, functional tests or integration tests. What is missing in this is a close look at unit tests. It is difficult to obtain high code coverage with integration tests alone.
This talk will build on Daniel Davis’ DjangoCon2015 talk “Why Unit Testing Doesn’t Have To Be So Hard”. That talk introduced the concept of using mocking to deal with the complexity of unit testing and gave a number of simple examples. In this talk, we will apply mocking, dummy objects and harnesses to unit test in the Django environment.
We will focus first on class based views. Django provides an extensive Generic Class Base View hierarchy of base classes and mixins. These define a series of methods that focus on various elements of the response process. For more complex applications, this system provides much of what is needed but often customizations are needed and these can take the form of subclasses overriding one or more methods, or perhaps mixins that are built to implement abstractions of these customizations.
In order to unit test these customizations, we want to place each individual method under test. To obtain strong assurance of code performance, we want to place under test each action of the code, plus its coupling with its base class(es). A test harness, mocks and dummy objects all assist in this process and we will explore examples of such. Mocks particularly facilitate our tests by us being able assert on what is passed on other method calls and on the super() call. Mixins are used to implement customization abstractions. Their methods can be unit tested making use of dummy subclasses.
Form classes also benefit from unit testing. Form classes may define clean methods for validation, and these clean methods can be called directly in unit tests for both valid and invalid data. Some modelform classes may implement business logic in their save() methods and these also highly benefit from unit testing.
Both forms and views often make use of the ORM. When performing integration testing, this often means setting up test fixtures, but for unit testing it might be much more efficient to mock out ORM calls such as filter(), all(), count(), etc. Sometimes code under test will chain these ORM functions and this also can be mocked.
We will then consider a more complex example of a view that makes use of an inlineformset. inlineformsets are more complex form objects, but various approaches can be used to unit test views that make use of formsets (along with unit tests of the formset itself).
We will close with some template unit testing.
The content of this talk is built on examples taken from real systems implementation. These should give many Django practitioners a boost in their day to day testing toolkit.
ViewSets will make your code shorter, more robust, and save you time during your development, if you let them. I have spent a lot of time dealing with writing view code, and dealing with all the urls, only to finally learn ViewSets. It immediately saved development time as well as making my code more simple.
Generally to make a new, basic, endpoint in DRF for a model it would take about 15 minutes. That includes creating a serializer, urls, views, and testing it the browser. Now that same endpoint is more easily understood and done, all the steps, in less than 5 minutes. Leaving you more time to worry about what your new app is supposed to actually do.
Everyone knows the story: armed with nothing more than a laptop and a dream, a couple of plucky geeks decide to take on the world: disrupting, innovating, and subverting their way to success. In just a few short months, they take a ramshackle collection of software and turn it into a money-printing factory that enables them to drive off into the sunset in gold-plated Lamborghinis.
But it isn’t always like that. In fact, it usually isn’t. Venture Capitalists (VC’s) make their investments betting that 15 out of 20 businesses they invest in will outright fail, 4 will maybe get a payoff, and 1 will be a massive success. We always hear about the 1 - the Facebooks, the Instagrams, the WhatsApps. But we very rarely hear about the 15 that don’t succeed. And that’s only counting the VC-funded companies - there are many other companies that never make it past hobby stage, or live a short, privately funded life on the back of consulting income before being quietly shut down.
This is a case study of one such a failure - TradesCloud. What went right? What went wrong? And what you can learn from TradesCloud’s mistakes if you’re contemplating starting a business of your own?
The talk will then explain how to use React in tandem with Redux to build a tiny website. We will demonstrate how to use tools like Webpack, fetch, Promises, and thunks to enhance React to solve the problems previously discussed.
Finally, we’ll end with a review of the material, and consider some of the topics being looked at by Facebook, Google and Microsoft.
Libraries as Systems to Concretize Abstract Thought
Understanding the Problem
Node, NPM, and Yarn
Converting ES6 with Babel or Bublé
Aside: Handling types with Immutable.js, Typescript, and Tern
Handling Modules with Webpack or Rollup
Polyfills for Behavior
Replacing XMLHttpRequest with fetch
Using Promises and thunks for asynchronous actions
React-Router for Single-Page Apps
Redux-Forms for User Input
Linting with ESLint
Testing in 2 minutes
React with Django
Review of Problems
Review of Solution Types
Break Down: Modules vs Syntax Transformations
Performance with InfernoJS
Web developers often find themselves in situations where server processing takes longer than a user would accept. One very common situation is when sending emails. Although simple and relatively quick task, it requires the communication with an external service. In this situation, it’s not possible to foresee how long that service will take to answer. Not to mention the many unexpected situations that can arise, such as errors and bugs. The solution to this problem is to delegate long lasting tasks while responding quickly to the user. This is the point where we need async tasks. There are some tools available that can assist in this job. In this talk, you will learn about the concepts, caveats and best practices for when developing async tasks. For this, I will use Python’s most popular tool for the task: Celery.
Setting the context (~3 min)
The architecture (~3 min)
Use cases (~2 min)
Tools available (~1 min)
Celery (~16 min)
Tests and debugging