 My name is Rocky Mesa. I'm Gavin Wohl. And we're here to talk to you about FormBuilder, or hey, look what you can do with Wiggy and the tree model. We work at FusionBox. FusionBox is a Django web development agency in Denver. At FusionBox, one of our open source projects is Wiggy. Wiggy is a content editor that we made in response to some of the problems that our clients had, that we've been seeing with our clients. It's a drag-and-drop editor for tree structures. So a problem that we've encountered frequently is a client is asking us for the ability to dynamically create a form on their website without any programming. So they want to specify what fields they want, they want to specify validation for those fields, and they want to control what happens when the form submits. So we've actually built a bunch of these form builders for clients before, and every time we do it, we would run into some problems. So if you wanted to have different models for different types of fields, it doesn't work really well with just what Django gives you. If you want to have an input and a drop-down, those have different fields, but you have to put all the data in one model, and then it's kind of gross ordering. You can do that with something like the inlines and Django Admin Sortable, but it limits you to just having one model. And then on top of that, for example, one time we had a client that had a field that referenced an image, and they needed the image to be inside of the form so that they could refer to that image. So it's kind of hard to have non-form content inside your form when you can only deal with one model. And on top of that, when you're done, when you've made it, you can't really package it up and put it on PyPI because it's not extensible. If anybody wants to add a field type, they have to edit your original field model. But that was before Wiggy. Wiggy's data model is a heterogeneous tree. What that means is it's a tree where the nodes can be different types. That's implemented as a tree-beard tree of nodes, each with a generic foreign key to their content. In addition to the data model, Wiggy also provides the UI for manipulating that tree. We built a drag-and-drop editor to edit the tree data. So how does Wiggy help with this? Let's look back. Here's the reasons why it was kind of hard, and a good form builder would overcome these, ordering forms, mixing different types of fields, having non-form content, and being sensible. So if we look at ordering forms, Django TreeBeard gives us this, and Wiggy gives us an editor for it. So it's already done, we don't have to think about it. The generic foreign key allows us to reference any type of content, so we're now able to use a different model for each of our fields. Interespressing non-form content? Just like Gavin said, we can use any model, so we can add images and videos and Google Maps, and we just do it. Since the generic foreign key is able to reference any model, sometimes you want to limit that. So Wiggy provides a compatibility system that allows you to specify which tree relationships are possible. So if you want to add a new field type, you can write a model and then specify that it goes in a form, and now Wiggy is able to add that field to a form. So we went ahead and built a form builder with Wiggy, and you can see it right there. You've got different types of form fields, like choice field, form input, file upload, and you can just drag them and drop them. Interespressed non-form content. It's got a form wrapper widget, and that form wrapper widget has got a cool method called get form, which returns a Django form class. So you don't have... Everybody's familiar with Django form classes. You can just use that, but the user built that form instead of a programmer. And here's what it looks like on the front end. So the user has complete control over this form. Thanks, guys. We're out at... We've got a booth over there, and we've got these links. They should look at wiggy.g. There's a demo, and it's on GitHub. It's open source. It's on PyPI. Thanks, guys. Come talk to us if you have any questions. At DjangoCon US last year, I launched the B-Ware project. B-Ware is an umbrella project. I've been running in what I laugh and refer to as my spare time, in which I'm hoping to collect a bunch of useful graphical development tools for testing, coverage, debugging, the sort of things that we do in a day-to-day life as Python developers. The cornerstone of B-Ware at the moment is Cricut, a graphical tool for running your test suites, including Django test suites, and enable you to navigate the whole testing process. But since last year, I've been a little bit quiet. Well, what happened? I'm still passionate about graphical tools and having good tools for development, to support development, but I've hit a few road bumps. Most notably, I was using TKinter to develop these tools, and TKinter doesn't have a web widget or, you know, a web view widget, which is kind of a big thing to be missing in 2014. So I started looking around at my options. There are lots of options out there, but none of them really work out of the box really well with Python. QT works nicely, but it's huge, and the Python libraries have this really weird limbo-state licensing problem. WX Windows is really annoying to install. GTK's support for OSX is RunX Windows. Kivi does cross-platform, but it uses themes, and I really hate themes. So this was very rapidly becoming a yak for me. I've got things that I want to do, but I need a widget toolkit that meets my requirements. So about the start of this year, I started shaving that yak, and about a month ago, I publicly announced Toga. Toga is a cross-platform, 100% system-native, Python-native widget toolkit that's installable using PIP install Toga. What does all that mean? Well, it's cross-platform. I've got it running on OSX, I've got it running on Linux, on Ubuntu, and I've got some preliminary support for Windows as well. It's 100% system-native. It doesn't use a theme to pretend it's rendering system-native widgets. It uses system-native APIs to render system-native widgets. So a button on OSX is an NS button. It looks like, behaves like, acts like an actual NS button. On Ubuntu, it's a GTK.button. These are accessed either using the native Python APIs that exist or a C-type binding to the system binaries. But because the system binaries are always there, you don't have to compile anything to get them. It's also Python-native. Python-first and Python-native. And Python-native. Because I'm developing it in and for Python, it means the APIs feel Python-native. So you can do things like, have context managers. And, for example, if you've got a long-running action that is stimulated in response to a button press, most widget toolkits coming from a C heritage will tell you to spawn a thread or create a callable that's then put into a timer method that you inject into an event loop. In Toga, you just yield. Python gives us the ability to yield and a long-running event handler can yield back to the main event loop. There's no timers or callback threads required. It's a pure Python app, so there's no binaries to ship with it, nothing to compile, no compiler required, with one small caveat on Ubuntu and virtual environments. The installation process is pip install Toga and off you run. So how mature is it? Well, it's only had six months of spare-time development, but here is a simple Fahrenheit to Celsius calculator running under OSX. And here is the same user interface, running on the same code, running under Ubuntu. I've done the most work on OSX, so the widget support there is at the point where I can mock up the full cricket user interface using Toga. And the original source of MyAC, here's a really dumb web browser written in 35 lines of code. It's got a little bit of documentation. This example is part of that documentation. There's obviously a lot more to go, and there's a basic tutorial. Oh, and one more thing, writing a new GUI toolkit is all fine and dandy, but it really is a bit pointless if it doesn't support all the hot platforms that everyone is using today, and that includes mobile platforms. So I ported it. Here is the same Fahrenheit to Celsius calculator running off exactly the same source code, running natively on iOS. To be completely clear, I'm using iOS widgets on an iPhone from Python Source, using exactly the same Python Source that the desktop application used. Unfortunately, it doesn't work on Android yet, but I am working on it. I'd love to talk to anyone with Python on Android experience about what might be possible. There's also a template project out there if you happen to want to develop a Python app and not use Toga or use some other project out there. So if you want details or anything else about Toga, go see pyb.org. I'm going to fund some further development on this with the intention of turning it into something you can actually use for serious professional enterprise development. If you or your company think you might be interested in helping to fund that development, paying for commercial support maybe, or otherwise getting involved, please get in touch. Thanks very much. The unenviable position of following Russell. Very charismatic. So my name is Dan Watson. I'm going to be talking about a little library I wrote for interfacing with PGCrypto. PGCrypto is a Postgres extension that basically lets you encrypt data inside your database using AES or Blowfish ciphers. So why would you want to do this? I mean, the most common reason is you have some sensitive information that you want to encrypt in your database but still want to be able to search on in your ORM in Django. I also have a couple functions that might be useful if you need to deal with ASCII Armor, which is a OpenPGP message format that we're dealing with block ciphers. The Lola VoIPI, which is basically a collection of Python functions for dealing with PGCrypto, you can see if you're using PGCrypto the SQL, you just encrypt data using a key file or a key string and a cipher, and that's what you get back and basically doing the same thing in Python using PyCrypto and a couple utility functions in my library, you basically get the same data back. So you could also do the same thing with ASCII Armor, which is basically a fancy name for, again, OpenPGP message format. You can take that same encrypted data and call Armor on it and you get back this text string where you can actually store basically the binary data in a text field instead of a byte A or whatever you want to store it in. So using the PGCrypto.Armor function, it's basically the same, same message back. I guess the real meat of this is doing it in Django. You might have a Django model for an employee, say you want to store a social security number, salary, date hired, and you don't want these things to be human readable and you don't want to say transmit your key over the network when calling into Postgres. So here's an example model with some example data and you can see when you get back the model instance and try to access an encrypted field, it's decrypted kind of transparently. With Django 1.7, the Custom Lookups are awesome. If you haven't played with them, I highly recommend it. You can now query encrypted fields in the database as you would normal fields without having to pull them into Python first. So you can filter on social security number or you can do date hired less than and salary is greater than and you get back query sets. And you can see the SQL for that actually looks like all the decryption and conversion to ASCII Armor is done on the database side, so you don't need to do Python processing for it. That's pretty much all I have. If you're interested in talking about it, find me later. Here's a couple links for padding information, OpenPGP and PGCrypto. Thanks. So here we have some model in this case in NSF which is for the whole U.S. and how as for some other foundations on for the state of some model, like the state of Oregon and the state of some model in Brazil in the southeast part of the country. So here we have it's good, but it's okay. Here we have the second result of search for scholarships the user is searching for Alzheimer's disease and it has done more than 200 results of scholarships and research grants and on the left we have the facet and in the facet we have the multi-level, so each bold one is a category and inside of each one there is a for instance in that case a few thousand knowledge and we have four items of astronomical science and so on and each of these have one hierarchy so in for instance we can have on the left the health science and inside of the health science we have collective health then it's pretty medicine nursing and so on but in Portuguese everything is translated actually we have in Portuguese and everything is translated into English and we have the same hierarchy and this is the same idea the user can select many of them, many of the facets at the same time which is a problem and what I'm going to show you guys is the main changes we can do to your haste implementation in order to accomplish this kind of thing so for multi-level facets you can choose each one you want on all of them you can get a free flight showing you guys and implemented but for multi-level first we have like a facet A which is at the top of the category and inside of that we have a B, C and B and for that we have a map my search app and the search index is .py which is the common file for haste and we are doing the main one is the area which is the multi-level field and in the schema xml we have over declaration we are using the type of the standard map which is like for folder hierarchy usually in the sort of implementation they explain this like this but we are using in a different context so which is not a problem we are using that slash in the prepare area to make the hierarchy and we have all the the area search for query for filtering the user what he has selected for mode select we are using the DAG EX for exclusion in solar they have also in their documentation probably they don't have this in haste because these only work for solar and not for the other ones that the haste works with and for that we use the EX DAG for the clarity facet and when you are going to narrow it down you use the DAG the TAG with the same name in this case UIS and then narrow it down in this case I have cut voltage the search with area search exact B or area search exact B and then you get as it counts show exactly like the last part of the slide when you get the seven results also the other counts for the other areas in that facet and on the plane wall you do all these but using a surface in each view determine which one is Portuguese and which one is English and for that it's good because it's only English Portuguese but if you are from a UIS also feel like that it's good to be a mess so if you have a bad idea just come to me and talk more about it I'm Smith I work at Tivix small Django consulting company based out of San Francisco Jeff gave a really good talk I think on Tuesday on Ansible so I just wanted to build on that finding and best practices that I've been using so some background what's the need you know as a consulting company we get projects and we want to get up and running very fast as fast as possible anyway you know the project goes into production after months of development while the staging environments out of sync while someone knows which packages to install etc etc so that would be nice to not panic and then you know sometimes you have a code branch you just want to set up an entirely separate environment where you can run a branch with your code base and show it to the CEO or the client or whoever you know it is and I know if Roku supports it really well but you know if you're an AWS or Linux or Rackspace it's somewhat of a pain so while Ansible we really like the philosophy behind it it's agent-less so if you like fabric you'll definitely or you might like it batteries included you know tons of modules so you don't have to scholar or get help to find the right module you need or may need etc so they have a certain list of options you can write your own obviously lots of releases 7000 followers on github you know that's my unscientific way of finding out what's good or not chef has 3000 by comparison the company behind Ansible is raised $6 million so that you know it's only going to get better and better over time technically speaking why would you want to use it configuration management you know what packages my server needs things like those orchestration and deployment you could potentially just ignore orchestration and deployment just use it for configuration management along with fabric and I'll show you examples the core concepts there are lots of them so I'm just going to skip over in a nutshell the 3-1 3 are playbook, play and tasks at a very low level a task is the sort of granular thing that you see in yellow this is off from their video so some gotchas and best practices you know where do I put my Ansible code so we've gone with you know the directory structure on the left which you see you know high level there's a very good file author's license Ansible client in Django project name singular client or frontend code Django's your Django project and then there's Ansible directory underneath Ansible you'll see you know there's dev and staging and production those are basically the inventory files the big directory note there is the roles and that's the key you don't want one giant Ansible file you want to basically follow this kind of structure and have things in roles what's inside roles so yeah so that's the directory structure the middle one is basically the roles so Django, Python, USB, virtual and these are very composable roles so you could swap out USB for ginucon not a problem so just get the ginucon role you can swap out nginx or apache swap it out, virtual envir is its own role anything under Django will basically be very Django specific anything under virtual envir will be virtual envir specific if you're using flash you can ignore the Django role et cetera et cetera so you can basically build these roles and within these roles as you can see on the right under the USB role there are handlers, tasks, templates and wires I can't cover all of them but the main one is tasks the templates are basically very interesting there's the uisgi.ini template instead of having different templates in your code base for staging production et cetera you can have one template it's a ginger template as you can see and then use variables so what are some of the best practices user modules they have lots of modules I've mentioned some of them here pip and Django managed being the two ones what are the alternatives you could use the shell and command module and then go a while but then you'll end up doing basically all of these things so you might as well leverage the modules that they have they're pretty flexible here's the Django managed modules for example you can specify the app path, the virtual env the command and also the settings you want to use and as you can see I'm using variables here so there's almost nothing here that's specific to dev staging production or any other environment use variables there are group variables, there are environment variables there are lots of variables it'll save you a lot of time so if you're actually changing your code or anything all you have to do is add another file or two and then you're good to go so as you can see I've defined where my virtual env is it might be different from dev versus production so you can accommodate for that use templates don't have multiple files for your uvizgi or your apache or nginx settings, etc use templates and these are ginger templates and they get compiled and put in certain places in runtime, use facts this is a great ansible it's basically when it connects to a server it gathers facts so for example in your nginx settings you don't want to hard core the number of processes or listeners, it's just based on the server so if you're upgrading your server these will automatically change you can still leverage fabric so for example we want to have a fab bootstrap command where we bootstrap our local development system so you could still use fabric but underneath it's calling that big ansible command which you never want to call by hand the same thing you can deploy by fabric but it's hidden in your fabric file you still continue staying fab staging launch and it will launch through fabric launch through production this github repository there is really nice some other articles, there's analysis by Lyft why they're developed with stout stack sadly and that is the end and that's where the presentation is thank you very much I'm going to tell you about this thing called Hendrix it's a framework for deploying Django apps that was developed by these people right here at this company called realio.com where it is currently being used in production I'm here because they hired me to implement some asynchronous stuff and celery and when I got to work that guy Justin over there basically threw himself in front of me and was like don't do celery try this instead and I was like are you crazy so I did and now I'm converted and I think everybody should know about this thing so Hendrix it's basically Django plus twisted that's the idea with the name or so I've been told what is it it is essentially it goes in the pipeline where you normally use unicorn or you whiskey however you say that and it is a twisted wrapper for that process using green or whatever it is that you whiskey does it uses twisted to handle that whole thread pool et cetera if you don't know what twisted is from their web page it is an event driven networking engine written in python and it's really amazing the more I learn about it the more impressed I am so easier Django development and deployment with benefits why is it easier with little things like when you're running the dev server you don't have to do that if debug then serve my statics from here Hendrix has a nice little way of doing that you also don't need sim links for your admin anymore it just works now which is kind of nice and another bonus is that you get you can just make a self sign certificate and run SSL right there in the Django dev server very handy sometimes in production because twisted has its own thread management you don't need to do your like unicorn how many workers confile stuff like that so we have a little up start config that you can just it's actually made for ansible so it has like the template brackets and you just use it in ansible pops it in the right place and you can just do a typo right here it should be I think it's Hendrix start I don't remember it's basically an Ubuntu service thing there should be a pseudo in there too so but the good stuff is really what twisted brings to the table by running a Django app in Twisted at Django I've seen a lot of people with a lot of different ways for dealing with some of these problems that Hendrix really kind of has for me solved web sockets deferred threads that normally stuff that you don't want to run in the request cycle you can just defer it do it over here don't have to use celery all the time asynchronous IO for doing well let me just go through some examples web sockets real time communication you can do chat clients our chat servers you can do I did some games like it's super fun you can write to your e-mail and then you can go to the page and click on the Brem right there in socket call and you don't have to run note which is kind of nice sometimes here's a little example of doing a deferred thread like this is a pattern I see constantly where you want to send an email the right way to do that is usually to have celery do it so that the user doesn't have to wait for it but now you can just in a separate thread, go back to the user instantly. Yeah, so I still have an installed celery at Relio, strangely. This use case is where you have like, you have to go hit some API, it takes a second or two. You can basically set them all up instantly and then you're back to doing something else. It's a little callbacky, but it's something that you have to get used to once in a while. And the basic functionality, which is serving your web app, it's a little bit scary doing something totally that nobody else seems to be doing, but so far, so good. And one of the reasons that we wanted to show everyone is hopefully someone will find some problem with it before the wrong time for finding problems with things. In the future, it's still in development. We're kind of trying to solidify some conventions, get some tests going, prove that it really is a viable way to do things, because it really does seem too good to be true, and some little details are still being refined. We'll have the read me tidied up by end of day today, I promise, and oh good, I'm almost done. Pip install Hendrix, and that's it. Thank you. So I'm also from Tivix, and at Tivix, we've had a number of projects over the past year and a half where we've been using Django and AngularJS together to come up with single page apps. And so I wanted to take a few minutes to just sort of share some of our insights and what our experience was in putting that all together. So just wanted to say thanks to Nina for her talks on Django REST framework and AngularJS earlier this week, and we'll move on. If you wanna follow along, it's public slides, you can go and visit them now. So AngularJS and Django work really, really well together, really like it, but you really also need to keep their roles well defined and separated. We had started with a sort of mixed configuration where we had Django templates and pages actually driving the AngularJS implementation, and that was kind of messy and difficult to really organize and have working productively. We then progressed to a website where it primarily just consumed JSONP content from a TastyPy API, and that was better, but as I'm sure you're all well aware, JSONP has some rather significant limitations, so step in the right direction. But what we ultimately settled on was actually using Django REST framework to provide all the content and interactions between the website and Django. So you need to give them both their space, they will work together well, but don't mix those up too much or you're going to end up with StrangularJS, which is what we like to call it sometimes. So yeah, going forward, we're only using Django REST framework and AngularJS in that configuration. They are completely separate. We just have the calls back and forth. We do not have Django defining any templates up front. The single page app is just a collection of HTML files and assets that have been optimized. So how did we get there? We've been treating AngularJS as a platform, so think of it as like you're developing an iOS app. You don't go into developing an iOS app by saying, now how am I going to have Django generate my views and controllers and all of that? Think of them being completely separate. As a result, you need to utilize separate tools from Django and Python. So for us, we've been using Grunt quite extensively as well as Yeoman. Furthermore, if you're going to be building an API for mobile apps or for your website, just do that all upfront when you're going to put together your single page app. Don't put it off. Don't put off aspects of it. Make sure your API is all fleshed out. You've got validation and everything can be done from there. You'll really reap the benefits later when you do go to mobile and it's all ready to go. So this is a quick diagram of our stack that we utilize to develop and deploy Django REST framework. We use Nginx in combination with AngularJS, Yeoman, Bower. That all goes towards the end result, which is this nice and tidy set of assets. So during development, what we'll do is we'll use Yeoman to actually scaffold out the project. This is nice as a good way to avoid StrangularJS, which is to let Yeoman make opinions about how this should work upfront. Defer to its directory structure, utilize the Grunt job that it has set up, and just once again avoid mixing Django and AngularJS. Just keep them separate. We moved on to using GruntServe to actually manage them in parallel, and that got messy because we had cores, and we also had to write code that accommodated that. That wasn't great. So we're just serving it as static content on the same domain, and that works nicely. There are some caveats, but not a big deal. Deployment, once again, don't use Django to deploy it. Use Grunt and Gulp to actually build and deploy the assets and utilize those tools as much as possible to crunch it down. So if you want to check out some code we've written, we're at github.com slash tivix. We've written Django rest-off, which integrates the authentication tools with Django in a restful interface, as well as an AngularJS module that interfaces with all that nicely. So once again, there's the URL for the slides, and thank you for a great conference. After Eric's close talk, why Django sucks, Django still sucks. To my way of thinking, it sucks primarily because it still thinks of itself as an Apache plug-in rather than a Python library. This is evidenced most clearly by the configure method of the lazy settings object. So what is the unsettings project? It's an effort to change project-wide settings from a globally incorporated single entity, Django.com.settings, to a set of individually injected objects configurable with a diverse and flexible variety of patterns. Here's a quick example. This is how you send mail with Django, right? An exceedingly simple task that Django happens to handle beautifully. Here's the documented approach. Import send mail and call it with its common sense dependencies injected. Of course, when we try to do that, we get an error because we haven't supplied the back end as a card to the function. Now in Python, this is called type error, or maybe in some cases attribute error. But in this other language called Django, it's improperly configured. This already betrays the underlying thinking on the matter because Django doesn't and can't know whether I've actually configured an email back end. It only knows whether I've supplied it to the function. Fortunately, Django is Pythonic enough to allow me to specify my own back end as a quag. So I do. You can see here that I also specify a file path to avoid getting another improperly configured. This isn't documented, but it actually works in the sense that allows me to instantiate and obtain the back end object. However, even with a properly instantiated back end object, watch what happens. This is the end of the road. I can't tell send mail about default char set, and since I haven't run settings that configure, my logic is essentially being rejected at this point. I can go no further. Now I don't know about you, but I run into this problem constantly. It's especially burdensome for a project like Hendrix, which Jayman just talked about, because the Hendrix tries to import Django and feed it to its own APIs, which is a perfectly reasonable thing for a Python library to do. Now it might be an apt metaphor to think of on settings as the third and final phase of Django's puberty. Prior to magic removal, Django was a child. Starting at about 1.4, it experienced a sort of adolescence, and now it's truly coming of age, right? The first step is the custom off that user model that shows that Django cares about its people. Then migration shows that Django cares about its people's right to change our mind. On settings shows that the Django tribe does not treat its project as an Apache plug-in, but as a feature rich Python subculture. So what's the current state of on settings? In addition to myself, the project has two other active contributors, both of whom are very talented and thoughtful Pythonistas, Skyler DuVeen of WNYC and James Farrington at Slashroot. We've developed a decorator called Uses Settings. When applied to a function that uses the setting singleton, it allows injection of that setting as a quirk instead. Simple. Now how many of you have written parts of Django's internal APIs that use the setting singleton? A small number of us, right? Those of you that aren't raising your hands will experience no change of behavior whatsoever from the implementation of our decorator. Now for those of us that are raising our hands, the Uses Settings decorator is actually a relief of many of the pains of maintaining and testing APIs that require settings. Together we crafted a pull request of 78 commits that indicate our vision for the implementation of this decorator. Of these, we think eight are ready for review today. If these eight are merged, you'll be able to call, send mail, just as I tried to do, without raising an error. Now, the reasons that I think that this is really important is, of course it removes burdensome import logic, allowing you to send mail. Great. But it's also a signal to the Python community that says we are you. We're a Python library. We're a Python project and we appreciate the norms of the larger Python tribe. More importantly than that, it's a signal to new Django contributors that says your work belongs here and it won't be locked away behind our configuration drama. There's a lot of Python developers with incredible logic to contribute to our project. And if they know that contributing it to our project means that anytime they wanna use it, they have to negotiate with the setting Singleton, they might be less inclined to. And there's plenty of other projects where their logic can go. Now, there are a bunch of things that you all can do. I was on Alayna's Django news podcast about at PyCon. Give that a listen and you can learn more obviously that I can tell you in five minutes. Look at our poll requests to see what you think. Work on on settings at the sprints. I'll probably be working on it at least a little, although I'll probably also work on Hendrix. Think of Django as a community and a movement, not just a product. And see if that starts to subtly change your view on the matter. And lobby your core team. Not that long ago, this was what felt to me an awfully controversial idea but I'm now slowly hearing members of the core team, I think, tell me that they're coming around on it and starting to see that this is a viable way forward. I'm really hopeful that it is and I do intend to keep working on it. Numbers, the first and second phases of Django's puberty as I call it are some of the finest work by Russell Keith McGee and Andrew Godwin that I've seen in the open source movement. I'm Justin Holmes. My email address is justinatjustinhomes.com. My GitHub is github.com slash jmiles. This presentation was made with a little thing called Wheelman, which is a coffee script library for creating presentation through, persuasion through the scroll wheel for you to check that out as well. Thank you very much. So form factor. Form factor is a mobile data collection platform. What actually is that? It's a Django powered platform for easy collection and submission of data from any device. So think of a field worker who needs to, on their daily tasks, they have to submit a form. They go from house to house. Form factor would allow them to do that from any device which we'll get to. So how's it built? You build a form with Django. You define what your form is and then using a Rust framework through a set of APIs. Different forms are made available on any different platform and these are the keyword. They're being native forms. So simply define a form on your server with Django and then expose that and you'll have, using our iOS, Android and future JavaScript library, you'll see a native form render. So what was the challenge and why did we do this? Why not just simply create an HTML form and then simply render it in a web view on iOS and Android and the reason for that is we wanted that kind of native field. The real problem is these people need to submit data, right? So it needs to be as seamless as possible. It can't be kind of a janky experience which we've experienced on HTML5 and using phone gap and whatnot. So these are all native forms and we didn't want to reinvent the wheel. We're constantly building forms and as you guys know, building forms are hard. You have to have custom validation for each field and it takes a lot of time. So we wanted something out of the box that you could simply just define, build it once on the back end and then all the different clients listening will seamlessly update. This is a bit of the modeling. So as we were building this, we thought why call it forms? Because we wanted forms to refer to some other piece of data we have. So we thought a bit more generic and why not call it entity? A form is just a representation of that entity. So I'll get to a demo in the end but an entity is something you actually define. It's a thing, right? And then there's different entity attribute fields and these each are different types. So your text field, select field, related and your actual data is an instance. So these instances related to entities and then instance field will generic farm key to a entity attribute. So that was kind of a form factor platform I just discussed but a lot of the core of what we used to build it will be open sourcing and that will be Django app with that allows you to create new entities and then REST framework APIs allow you to create and edit these instances of these entities and then iOS and Android code base that are hooked up with these with API so you can simply just plug it in and start using it and then as you can see we have kind of a internal debate going on what we're gonna use for the JavaScript framework. And what you guys can use to use a simple contact form, right? If you had an Android application, iOS application, you could simply just pull in our libraries and pip install this form factor library and you're pretty much good to go. So it's really that simple. You could build your own form factor or whatever else you want. So quick demo of it. Though this is me actually defining an entity right here. So let's give person a first name and all your validation you can actually define right here and the mobile Apple dynamically picked that up. So now the entity ID is 27. So this is the simulator running. So there's our dynamic form that was just picked up. Simply submit it. No alert but it's there and you can change orders and it will pick it up in that as well. That's great. I hate to cut you off but we're over time. I need Jacob Birch. Okay. The Lawrence Journal World Offices in Lawrence, Kansas which is really, really close to the middle of the country and really close to the middle of nowhere. Simon Wilson, Adrian Holivardi and Jacob Kaplan Moss started what became Django. And actually exactly almost nine years ago, a little over nine years ago, Adrian actually made the work they had been doing for the Journal World open source, thereby sort of giving the birth to Django. To celebrate this event, we who are in Lawrence, Kansas are going to be throwing a birthday party. What that entails, we don't know and that's up to you, everyone in the room and everyone in social media who can sign up right now on DjangoBirchday.com. Let us know if you're interested in visiting Lawrence, see a little bit of history and having some fun. If we get a small amount of people, we'll have a little party, we've got a lot of people but they're a bigger party and probably have some talks along with it. So there's the information. You can talk to Frank, you can talk to me, you can talk to Jeff, you can talk to Flavio, all of us are here if you have any ideas for it and we hope to see you in Lawrence in about a year. That's it. Teamux and Teamacil. Teamux is, this is just a tool talk. Teamux is a terminal multiplexer. How many people have used Teamux? Wow, I don't even need to be up here. Well, for the other half. If you have, for those who haven't, if you've used GNU Screen, it's kind of similar to that. And then I'll explain Teamacil after I show Teamux. So, wow, it's so small. So, this is just my eye term. In Teamux, it just allows me to create windows and panes. You can't actually even see the power shelf at the bottom but you can have lots of different windows and each window can have panes. So, I can separate the screen into two panes. I can separate it into three panes, et cetera. And I can also do this on the, I can use it like you use new screen to connect to servers and your session, your SSH session on the server is maintained. So, for example, I can connect to, this is actually one of our production servers. And as soon as I, as soon as I SSH into it, whatever server I had or whatever session I had running before is still there. So, I can go and I can look at whatever I was looking at earlier and kind of, oh yeah, that's what I was working on. That's where the problem was, right? And I use, I just use eye term tabs, as you can see at the top, to kind of have, I use that for separate sessions only, only when I'm connected to separate servers and everything else can exist in Teamux. And then, Teamacil allows you to just kind of save Teamux configuration. So, if I wanna work on a particular project, I just say Teamacil and say I wanna work on my UREC project. Then, I hit say Teamacil UREC and it just opens up my, you know, my four pane tile layout layout. And you can just specify commands that get run in each pane. So, you know, get status, get branches, so I can remember what branches there were, a listing of the directory, et cetera. You can, you can specify whatever you want to run. And if I, let's see, since I can't, oh, so over on the left here is just what the, what a Teamacil configuration file looks like. It's just YAML. And so you, the important part is really the, so root is kind of the root directory, so it'll change directory into that directory in every pane. And then, you just have a list of panes. Oh, you can give it a layout, so if you have a complicated layout, for example, I bought a $300 4K TV that I've been using as a monitor. And it's really crappy in every way, except for the fact that it has 4,000 pixels. And so on that one, I have like this six or eight pane layout. And you just kind of, you can just put that in here and it's beautiful. But as you can see, it's just really simple. I just tell it what commands to run in each pane and it just does it. Thank you. Alrighty, so Carson Bates is a responsive image handler. And we built it at PBS Kits. So around January, we released a new version of our homepage. Pretty fancy, lots of pictures and everything. And it's responsive, so that's good. When you change the viewport, it takes pixel density and everything into consideration and readjusts the layout. So if you're on a mobile phone, it would really suck if you had to load all the source images, because that'd be several megabytes. So when you say it's responsive, you gotta take some of this other stuff into consideration. Pretty overwhelming stuff. So in the beginning, we were like, all right, we can use some of these solutions. But the first three, at least, you still have to stamp out those different sizes yourself. The front end piece of it, the JavaScript, and in the case of the picture element, the browser can take care of building the request. So it asks for the right size image. But you still have to make them. So my coworker, Miguel, is like, that's stupid. It is, so we built Bates, which is the backend in Django, that does a lot of that automatically. So the other two solutions are actually pretty good. Adaptive Images, it's built in PHP, and it uses a thin layer front end that sets cookie hints, so that the served image will be the right size for whatever user agent detection the cookie supplies. And resource it is also very good, I suppose, and then we used it. I think you have to pay for it. It's a platform as a service that suffers as a service. So here are some of the guiding philosophies for when we built our thing. We wanted to keep the markup as semantic as possible, and we want to not really break anything that you might have on your page, like jQuery and other frameworks and whatnot. And we wanted to be pretty agnostic about what you might want to use as a backend. So if you don't like Django, don't use it, use your own thing, that's cool. Just use the piece of JavaScript to make the request, or vice versa, if you want to write your own front end to do your user agent detection and whatnot, build those rules yourself, use the Django backend as your image breaker, cool. There's the GitHub project, you can check it out. I will lunge and give you a chance to copy it down. All right, so here's the Django backend, you just pip install baits, and here's the admin. There's a couple of things you need to configure. Like obviously you'd have to tell it where to fetch your images from. So there's the notion of origin, and then your image sizes. So that's just a width, a quality, so you can compress it if you want to. And there's a name, short name. So on the front end, the way you would use this is you would include JSONJS, and in your markup, your image tags, instead of setting your source attribute, you're gonna set something called data Carson source, and that URL is built from a combination of the namespace, which is the origin that you just set in the Django admin, and the other thing you just set, which is the, sorry, and the other part of this is the image path. So in other words, in your origin is where you specify the domain, in this case for PBS Kids, it's a kind of delivery network. But after that, what's the path that comes after? That's this part. So the other attribute Carson size is the image profile that you define in the admin. So, you know, script tag can include Carson, and there's a method called init in the Carson object. Right now it's in the pbs.kids namespace, but we're probably gonna factor that out. You just initialize it whenever you want to. In this case, it's on document ready, but whenever. Other, some other features that are in here, there are two built-in sizes, so that mezzanine is the source size, and none is just, I don't want to serve this image at all, because I wanna save bandwidth. Rules, so sometimes it's useful to determine the size of your image in data Carson size dynamically at runtime. So you can do that with a callback, it's just the function that you can supply to do that maybe based on some user agent detection or capability detection. Event hooks are nice, so when image is low, you wanna control how it's presented to the user, so maybe it's kind of faded in and whatnot. Carson done is the same thing before all of the images, so maybe you want them all to fade in at the same time when they're done loading. The trade-off is now you've gotten rid of browser prefetch, that optimization in your browser, where inspects source attributes and gets the images beforehand. We don't have that anymore, unfortunately. Run that better documentation, we're working on it. There's a get-up pages. Picture support, I'm out of time. Picture support and ad hoc sizes. Can't take it for questions, thank you. So tomorrow we have the sprints and people are generally advised not to run before they can walk, which is a shame when other people are sprinting and you want sprint too. So don't worry about what people say because like other people, you're probably full of good ideas and have solutions to problems and want to collaborate and contribute to what we're doing and we want you to. But too often people lack technical expertise or they lack the collaboration expertise or they simply lack the confidence to become involved. And these are barriers preventing participation. People want to commit, but they're not sure how. So the workshop that I'll be running tomorrow on the first day of the sprints, it will run all day, will cover the four key tools that you need to get started and the process itself. And generally I find that even people who are doing this for the very first time and they don't even need to be Python users will normally leave the workshop at the end of the day with a commit in Django's code base. Might be a very small one, but it will be something, you've got a very good chance of something getting in. I'll be there to help you. The other sprinters will be there to help you. Our colleagues in the Django project will also be online helping you. So if you've ever wondered what these sprints were about or you've wanted to commit to Django or another Python project, come along to this. We'll work at the speed of the slowest person which is usually myself. It's not rocket science because rockets are useless in this kind of endeavor. And it'll be fun and you don't need to worry about being the slowest person in the room or anything like that, just come along and have fun. If it's too slow for you, then you can just ignore it and I won't be in the least bit offended if you drop in or out. And you might be able to help people who are going a little bit more slowly than you. So it's all online anyway. You don't have to come to the sprints to do it. There's a tutorial there. There's a repository for it that you can help improve. You can come and find me on IRC or in real life. Drop me a line. Don't be afraid to commit. Thank you. I still have... I had two minutes left. So I'm going to use the rest of my allocation. Now forgive me if you've seen this before. I know some of you have, but I had one original idea in July, in May 2013. I'm still waiting for another one. I'm going to milk this one for all that it's worth because we have to work with what we can get. So, relationships. There are 7 billion other people in this world. Are you sure that you have chosen the right one for yourself? Because right now, there's probably someone out there with whom you would have been happier than the imperfect person you are having an imperfect relationship with right now. What's worse is that your chances of discovering the perfect person are almost nil. Simple arithmetic means that almost any choice you'll make is the wrong one. And also that you will fail in any attempt to make a better choice. So stop worrying about making the right choice. Instead, commit to what you have already chosen and develop it into the best possible relationship for you. And the same goes for your relationship with the software that you work with. Because there are 7 billion web frameworks and languages and platforms to choose from. And anyone that you choose will probably be imperfect and the wrong one. So stop trying to make the right choice and instead commit to the project you have already chosen. And help turn it into the best possible one for you. Thank you. Okay.