Home

Powered by Django

Dynamic Inlines in the Django Admin

Date: Aug 03, 2016

I'm not sure how many of you know this, but in the interest of having a well-rounded life, I make a lot of things in my spare time. Over the years, I've been a costumer, a jeweller, a photographer, and a glass artist, among other things.

And I don't just mean dabbling - when I get interested in learning something, I throw myself into it almost to the point of fanaticism.

I make a lot of things. Which means I have a lot of things filling up my closets and drawers. There's only so much I can gift for birthdays and holidays. So lately I've opened up a shop on Etsy.

Opening shops in online marketplaces has meant keeping track of a lot of things around inventory. Etsy's listings manager is nice, but it doesn't really give me everything I want. For a while, I've been using a spreadsheet to keep track of my Etsy listings. But I'm also about to open a shop on Spoonflower. And I'm considering ArtFire. And I need a better way to manage the supplies I use. And I want to keep all this stuff in one place.

Naturally, because I'm a programmer, I'm building my own inventory manager.

I just started a day ago, so there's obviously a lot of work ahead - I hadn't given a lot of deep thought to what the account and item models needed to look like, so I've been making liberal use of migrations. (I should point out that I'm using Django 1.9. I love it - I've been mired in 1.3 for a while at work, used 1.6 for a few small personal projects, and made it onto 1.8 for some more recent work projects. I love the slight changes in the admin look, and finally having the built-in migrations is a dream come true.)

The items I'm storing use a base Item model with a lot of common fields like name, description, and price. But Etsy listings also use some values that are unique, such as Etsy-specific categories, when the item was made, a list of materials to use as search tags, and so on. Meanwhile, Spoonflower listings take a totally different set of parameters, such as material type, colors, and the type of repeat you want to use for your image.

For each marketplace (so far just Etsy and Spoonflower), I've added models for values that are only needed when the item is listed on that market.

class EtsyItem(models.Model):
    """
    Fields used when the item
    is listed on 'Etsy'
    """
    item = models.ForeignKey(Item)
    ...

class SpoonflowerItem(models.Model):
    """
    Fields used when the item
    is listed on 'Spoonflower'
    """
    item = models.ForeignKey(Item)
    ...

This structure does assume that an Item wouldn't be listed on multiple markets - I may leave it that way and just add functionality to allow one Item's basic values to be copied to another record, to be associated with a different market so that each listing is unique.

I did also consider subclassing the Item model, but I'm serious about wanting to keep everything in one place - I'd rather not have to manage items in an Etsy list versus a Spoonflower list, etc. Maybe I'll change my mind about that and rewrite this whole thing.

But in the meantime, keeping everything together under that Item model presented a challenge - how to add/display the marketplace-specific data for an Item in the admin? I wanted to be able to show the Etsy model as an inline for an item listed for Etsy, a Spoonflower inline for a Spoonflower item, and so on.

Here's what I did (and of course you can see this in the inventory/admin.py in the repository):

from .models import EtsyItem, SpoonflowerItem

class EtsyItemInline(admin.StackedInline):
    model = EtsyItem
    extra = 1
    max_num = 1

class SpoonflowerItemInline(admin.StackedInline):
    model = SpoonflowerItem
    extra = 1
    max_num = 1

I started with inlines for each of the custom models. Each Item should have only one of its respective inline objects - setting "extra=1" and "max_num=1" ensures that one instance of that inline will load but that no additional instances can be added to the page.

class ItemAdmin(admin.ModelAdmin):
    ...
    inlines = [
        EtsyItemInline,
        SpoonflowerItemInline,
    ]

But I still needed a way to prevent all of the inlines from being loaded. An Item sold on Etsy should only have the EtsyItemInline, an Item to be sold on Spoonflower should only load SpoonflowerItemInline, and so on.

The first thing I needed to do was make it clear which online marketplace an Item is being sold on. So I went back to the model. My base Item model has a ForeignKey relationship to a seller account, which is in turn associated with a market name - I added a method extra_fields_by_market() to return a string (the desired inline name, based on the market name).

class Item(models.Model):
    account = models.ForeignKey(SellerAccount)

    ...

    def extra_fields_by_market(self):
        extra_inline_model = ''
        if self.account.market:
            extra_inline_model = str(self.account.market)+'ItemInline'
        return extra_inline_model

Then back in the admin, I overrode get_formsets_with_inlines(). This method yields formset/inline pairs, which allows me to limit which inlines are displayed for a given object.

I was able to use it to display a specific inline only when it matches the market on a base Item:

class ItemAdmin(admin.ModelAdmin):

    ...

    def get_formsets_with_inlines(self, request, obj=None):
        for inline in self.get_inline_instances(request, obj):
            # hide/show market-specific inlines based on market name
            if obj and obj.extra_fields_by_market() == inline.__class__.__name__:
                yield inline.get_formset(request, obj), inline

The value of obj.extra_fields_by_market() is that string returned by the model - 'EtsyItemInline', 'SpoonflowerItemInline', etc. If that matches the name one of the defined inlines, that inline is returned.

I should also note the other condition - if obj. We don't know what market an Item will be listed on until after it's become an object in the database - this means a user would have to fill in the base Item fields, save, then come back to find the additional fields displayed as an inline.

If I were better at Javascript, I would have gone in a different direction immediately and had the inline load triggered by the account/market dropdown selection in the base Item.

I'll figure that out in a day or two, whenever I get a chance to turn my attention back to the project. Or I'll rewrite the whole thing a few times because I'm not quite satisfied with the data structure. But for now hopefully I've given you some new ideas for ways to manage inlines in your admins.

Powered by Django

Bonus Points For Project-Based Interviews

Date: Jul 27, 2016

I'm in the middle of a job hunt right now, and so I'm thinking about a lot of issues as they relate to questions I'm asking during interviews. How do these companies determine 'culture fit'? How do I know whether or not their culture is inclusive? Will I be taken seriously, will I be listened to?

But the question that's obviously giving me the most headaches is whether or not I'll come off sounding knowledgeable during an interview. That's natural, right?

After 15 years in this field, I still suffer a little from impostor syndrome, and nowhere does that show itself more clearly than when I need to stifle it the most - during an interview.

Classic Q&A-style tech interviews are such a challenge for me. I am not great at regurgitating facts out of the standard library documentation. That's especially true when I'm being interviewed by a man (or group of men) - there's an unfortunate dynamic there that makes me question whether or not I belong.

But you know, that's not how I use Python every day anyway. You don't really want to gauge how well someone has memorized the standard library docs. In day-to-day programming work, it's not about what you've memorized - it's about knowing what to look up, knowing what questions to ask.

What you really want to know is how they approach problems, and how well they solve them. But asking someone to write a function or debug some code doesn't work as well either. I've had tasks like that as an interviewee. They might seem simple, the kinds of problem-solving exercises that might normally only take a few minutes, but when you're being watched, knowing you're being judged and scrutinized, those simple problems can become monumental.

And that's also not a reflection of how problems get solved in the real world. In a real development environment, there's collaboration, often there's more flexible time.

What I really prefer are project-based interviews - what are sometimes called take-home assignments - where I can develop some code beforehand and then explain my decisions to an interviewer. I've had a lot of success with this type of interview - from both sides of the process. It makes the interview feel less like a pressure cooker and more like an opportunity to show you what I can actually do.

How it works:

Then on the day of the interview, spend some time going over the code and examine the decision-making that went into it.

I understand the argument that this kind of exercise takes up too much free time for the interviewee. But as said interviewee, my position is this:

As programmers (particularly in open source), we're expected to write code in our spare time to contribute to open source libraries and projects, so that we can be judged on the quality/amount of that code. We're expected to write tech blogs and contribute in all kinds of other ways. All of that is unpaid work, usually done in our free time.

But somehow a few hours writing a take-home assignment is too much time to spend? For not-the-right-job, yes, I agree that it would be too much. But for the right job? I would feel just as excited about writing that code as I would about any other open source contribution.

Powered by Django

Looking Ahead

Date: Jul 22, 2016

After nearly four years at my current company, I am looking for something new. I love my team, and I'd happily stay here longer (the challenges laid at my feet over the years have been exciting). But the business has made a decision to eliminate Python, sunsetting all the current projects by the end of this year, so I am beginning my search for a new software development opportunity.

Who I am and what I do

What's important to me

My favorite parts of dev work: Debugging, scripting, writing APIs, writing tests, deleting code, managing releases, optimizing data stores, writing documentation

The parts I could live without: Front-end work (I'm not opposed to writing CSS and JavaScript, they're just not my favorite things).

The nuts and bolts of my software development background are in my online resume, and I've got a lot of professional recommendations on LinkedIn.

Feel free to contact me at barbara.shaurette@gmail.com.

Bonus Points For Project-Based Interviews

Powered by Django

PyGotham 2016 - "Young Coders (or, 'How To Teach Python To Kids')"

Date: Jul 16, 2016

(Note: These are the slides and speaker notes from my 2016 PyGotham talk, "Young Coders (or, 'How To Teach Python To Kids')".)

This talk is for any Python programmer who's interested in passing their knowledge on to younger students. And I really do mean any Python programmer. Teaching experience is nice to have but it’s not required.

If you're here, you probably already have some idea why you should teach. Coding is today's literacy, and too many students are still not being exposed to it in school. As Python developers, we have a unique opportunity to share our skills in our local communities and give kids an experience that could make a huge impact on their lives.

Do you remember that sense of wonder you felt the first time you realized what you could do with code? You could help someone else discover that same sense of excitement, and start them down the path towards a lifetime of exploration.

And organizing a class could change your life. It's a great way to introduce yourself to interacting with young students and will help you get started in teaching and public speaking.

I’m going to talk a little bit about the 'what' - the things you need to set up a class, like hardware, venues, and probably the most important thing: financing.

But where I want to spend the most time is in telling you how, and convincing you that teaching kids is easier than you think. All you really need are the desire and a little Python experience.

Why should you listen to me?

I’ve been involved in the Python community for about a decade now, but I actually began my professional life as a school teacher. I was only at it for a few years before I realized that I could never move out of my parents’ house on that salary, so I made a change. tl;dr I’ve been a successful developer for a little over 15 years now. But I didn't know how much I missed working with kids until I got the chance to come back to it.

In 2013, PyCon organizers came up with this idea for a new program called Young Coders. So that year, I flew into San Jose with this curriculum that I had pieced together at the last minute. And along with Katie Cunningham and a team of enthusiastic volunteers, we taught our first one-day intro to Python for young students.

Since then I've been lucky enough to teach both kids and adults through organizations like PyLadies and DjangoGirls. Teaching has become a dual passion for me, alongside programming.

Also in the years since, Python classes for kids have sprung up all over - at regional conferences and in after-school clubs.

And Young Coders at PyCon has continued to grow every year. For the two years that PyCon was in Montreal, we had the curriculum translated into French, and a couple of developers from the community up there taught it to local school kids. Then a few months ago in Portland, we introduced a new intermediate class to go along with the original beginner class, and that was a huge success. Kids did their first real scripting, worked with APIs, built their first web sites - it was so exciting.

As glad as I am for my teaching background, it's my programming background that's made all of this possible. Any of you out there could do it just as well, you just need a few pointers to get started.

I want to keep that momentum going. I want to keep Young Coders growing beyond just a couple of classes at conferences every year. And I want to do that by convincing all of you to organize and teach classes in your own communities.

So what do you need to organize a class? (To be clear, I’m talking about a one-day workshop, so a short-term learning experience, not the long-term experience you would expect from a public school classroom.)

I’m just going to skim over this list, but at the end I'll be giving you an online resource that has very complete descriptions of each of these things.

How you decide to set up your classroom is going to depend on a lot of different factors.

But the one thing I want to recommend strongly is that you use Raspberry Pis, and there are two important reasons why.

One is consistency: It's going to be easier to teach when every student is working in the same environment. You won't have to waste time with installs, or debugging issues that are unique to a particular operating system.

The other is reinforcement: You want your students to have a programming environment that's all theirs, that they can take home, so that they can keep going when they leave your classroom.

There are also some maybe less important reasons - Raspberry Pis (or their operating system) come with a lot of software already installed. There’s Idle - if you’ve never worked with it, Idle is a Python interpreter that has a few extra bells and whistles to make learning easier.

They also come with pygame - in the first few years of Young Coders, we’d have the kids edit constants (things like background colors or player avatar sizes) to see how they affected the games. And newer Raspberry Pis come with mcpi, a library that you can use to interact with Minecraft.

All of this means you’ll be purchasing a lot of Raspberry Pis. But they’re very affordable, and peripherals like keyboards and monitors can be rented for a very low cost. And as I said I'm going to give you some resources to help you figure out financing/sponsorship.

And of course you’re going to want some students.

I would recommend enrolling students 12 and older. The age cutoff is often a point of contention for Young Coders classes. And it’s understandable - parents want to get their kids into coding classes early, and for good reason, but sometimes it can be hard to tell if the kids are ready.

Here’s the thing: Kids develop new cognitive skills as they grow. Even beginner Python requires some abstract thinking, and among childhood development researchers it's generally believed that that ability emerges at around age 12. Sometimes before, sometimes after.

Personally, I think researchers’ views on that are going to begin to change as we see more kids getting into computing at earlier ages. But for now 12 is the usually agreed-upon age at which abstract thought becomes possible.

So you can put an 8- or 10-year-old in a CS classroom and they may be able to mimic what you type, but whether or not they'll comprehend it is not as certain. For those younger kids who are still in their concrete thinking phase, visual learning environments like Scratch and Turtle and Hopscotch are terrific alternatives.

(Note: Earlier in the day, the team from Codester gave a terrific talk titled 'Opening the Magic Box: Creating transitional Python libraries and IDE tools' about developing curriculum for classrooms. They spent a lot of time talking about these stages of childhood development and about what kinds of CS exposure are appropriate for different age groups. They also presented some great ideas for developing your own curriculum if you’re interested in doing that. When the PyGotham videos come out, you'll want to look for that one, but in the meantime the slides are here.)

So where do you find these kids anyway?

You’re going to be tempted to fill your classes with kids who are the children of other programmers you know from your local community.

But I would implore you to consider doing something different. And if you remember nothing else from this talk, remember this part.

You have this unique opportunity to impact kids who might not otherwise get much exposure to computing. Try reaching out to organizations like the Boys & Girls Clubs of America, and Big Brothers/Big Sisters. In Austin we have a group called GirlStart that’s like an after-school/summer camp program for girls who want to focus on STEM skills. Your town probably has something like that too.

So focus on diversity, focus on kids from different economic backgrounds. It might take a bit of Googling and going a little beyond your familiarity to find organizations to work with, but it’ll be worth it - you could really open up new doors for some of your students.

So what soft skills do you need to teach?

You should be comfortable illustrating simple concepts. For example, when we introduce variables in the beginner class, we might describe them as bowls. A bowl can contain all kinds of different things, different values. You can put something in the bowl, then you can take that thing out and put something new in the bowl.

And you don't need to 'dumb down' or be cutesie to talk to kids. Just be clear, keep your explanations simple - they’ll get it.

That said, do keep your examples relevant. The first year we taught Young Coders, as I said I brought in this curriculum that included some materials from an adult beginner class I'd helped with. I had the kids looking at a list of Beatles names - as in, the music group, John, Paul, George and Ringo - and I wanted them to use an index to choose their favorite musician.

I was, of course, greeted by blank stares. A 12-year-old does not know who the Beatles are. Some of you probably don't. So I went back to the hotel room that night and changed that to a list of colors, and that's what we’ve used ever since.

When it comes to teaching materials, you are always free to use the Young Coders curriculum - that's been open sourced since day one. The materials we use at PyCon were originally cobbled together from a lot of different sources, but they've been refined and tried and tested over the years and we know they work.

They’re filled with lots of little ‘a-ha!’ moments, lots of gradual skill-building, lots of little wins along the way to keep the kids engaged.

They're formatted like a presentation - a slide deck with extensive speaker notes that you can use if you find yourself needing a hand when you’re explaining concepts. We project these slides from a computer that also has Idle installed (so that we can alternate between the slides and demonstrating coding tasks).

You’ll find those slides, along with some detailed classroom setup notes, in this GitHub repository. The latest version is in a folder labelled ‘2016’ - that’s been updated for Python 3. As recently as 2015, though, we were still using Python 2, so that’s also available if you’re interested.

Of course if you want to write your own curriculum, there are lots of books and websites to draw inspiration from. Just remember a few things:

There's a common misconception that kids come to programming classes wanting only to make games.

I've done a little work with my local chapter of CSTA (that’s the Computer Science Teachers Association), and one thing I hear repeatedly is that they can’t get girls from AP math to enroll in the AP computer science classes. The girls think it's only going to be about making games (and they’re usually right), but they want more variety.

It’s also been my experience with the classes I’ve taught - sure, kids want game content, but they’re interested in other things too.

So show them that you can do more with Python than just making games - I promise, once they start talking to their computers with Python, they'll be no less excited.

It’s go time! Day of the class! You’re standing at the front! Now how do you talk to the kids?

It’s not going to be like this, I promise.

Kids are nothing to be afraid of, especially in this context. In fact, getting up in front of a roomful of kids is waaaay easier than speaking to a room full of adults.

And a class like this won't come with some of the same challenges you’d have teaching a primary school class. By age 12, students are already well familiar with basic classroom comportment - they’ll know how to behave and what’s expected of them.

And, too, your students will be there because they WANT to be, not because it’s compulsory. They’re eager to learn this stuff, and they'll soak it all up. I promise.

(By the way, that is a scene from Kindergarten Cop 2, Dolph Lundgren, straight to DVD. Don’t ask me how I know.)

Be collaborative. Don't just read code examples at the students. Interact with them. Ask questions, even if it's just asking them to guess what the results of an expression might be. Engage with them directly. They’ll surprise you with some intelligent questions, and they might even teach you a few things.

They'll be excited to be there, but they can also lose focus quickly if you aren’t mindful of the pace of the class.

Don't sweat the small details. There's only so much you can teach in a few hours, and the kids will need time beyond the classroom to work with and absorb all these new concepts.

Keep your mind on the big picture: You're teaching kids how to communicate with their computers, and that can be really huge and mind-blowing to someone who's never done any programming before.

Your students are not going to walk away with a thorough knowledge of Python. And that’s fine, that shouldn’t be your goal. What you are doing is planting a seed.

  1. You’re showing kids how possible programming is
  2. And you’re motivating them to want to learn more

This is the site where you’re going to find all that information I mentioned earlier. If you navigate to the 'Teach' section, you’ll find details about all those physical resources, about how to get sponsorship money, where to find the kids, etc.

It’s a new site, just launched a few days ago, but it’s got pages and pages of teaching and organizing resources, along with an online version of the Young Coders curriculum, written in a tutorial format.

I wrote this talk as I was also writing the content for this web site, so if you read it and it all sounds a little familiar, that's why.

None of the site is that pretty - for any of it that looks nice or works well I have to give all the credit to Andrew Dupont, who did all the front end work. I am currently looking for a designer to work with to liven things up a bit. And I’m looking to port the tutorial to an iPython (or now, Jupyter) notebook, so if any of you are interested in collaborating on that, please get in touch with me.

There are going to be lots of additional resources added in the next few months - organizer tools, checklists, some things sort of similar to what DjangoGirls is using to help people organize their classes.

So if you're curious about something that you don't see up there, just ping me at @bshaurette - I'll do my best to get you an answer.

Powered by Django

Young Coders: Intermediate

Date: Jun 07, 2016

We've been putting on a Young Coders class at PyCon North America for several years now - it started in San Jose, continued in Montreal, and has morphed into something a little more challenging in Portland.

The original class is aimed at beginners. While we try to recruit kids from the local community, it's inevitable that every year we're going to get kids from the Python community, children of programmers who have already been exposed to Python in some capacity.

Last year, as we were going through the beginning material - typing math expressions and strings in Idle - I noticed one young student off on their own, writing complex functions, and I realized that we needed to offer more. For some of those kids, the beginner material was just too simple and sitting in that classroom was a waste of a day. So I spent some time in the year between conferences putting together new curriculum.

This year we offered two Young Coders classes - the beginner version we've always had, and an intermediate class for kids who already had a little Python experience.


What Went Well

Before I even talk about the class itself, I want to thank Taylor Meek and Andrew Dupont for stepping up and joining the teaching staff this year. You should thank them too - they were the real heroes of this year's Young Coders.

Rather than diving deeper into the intricacies of the language, my goal with the intermediate material was to teach students about the things they can do with Python. That turned out to be a good decision - the kids left with a real sense of excitement and purpose. They had something concrete, tools that they could use to go out and build interesting things.

We didn't do a lot with gaming. That wasn't my original intention, I just ran out of time and did not get much written. And I don't think I'll add much for next year. I feel like there are a lot of resources out there already, both books and web sites. I want kids to know that there are more cool things they can do with Python than just make games.

Our intermediate curriculum included:

Scripting introduced a lot of new concepts - opening/reading/writing to files, connecting to the internet and making requests, even making requests to APIs and learning about different kinds of data structures. But we walked through every line of every script step-by-step, so nothing went unexplained. And we went slowly enough that nothing was too overwhelming**.

** How to tell if a thing is overwhelming - if the kids look panicked, slow down; if they start to glaze over, you're good, just move on.

Running scripts also provided a lot of immediate gratification for the students - they could see Python doing things in real time, just by dropping in print statements to follow along at every step. They learned more about constructing Python expressions - we built on gradually more complex examples of dot notation and using class methods. And they learned a lot more about errors and how to handle them.

I want to point out here that I don't expect students will retain everything we cover in these classes. But that's okay - they get a little taste of a lot of things, they'll remember enough to know it was fun, and they now know where to find the resources to learn more.

Building a web site got even more complex, as we introduced a lot of topics not specific to Python, like what servers are, what the internet is made of, how data travels back and forth in requests and responses, databases and what they do, and frameworks and what they offer us.

We did skim over some of these subjects - some of them could take their own dedicated classes just to explain in detail. But we always provided lots of links back to resources in case any student wanted to explore in any particular direction and learn more.

Setup for both classes was a lot simpler this year. Preparation was key. (To recap, the classroom workstations consist of Raspberry Pis and peripherals - keyboard, mouse, monitor. The Raspbian OS includes Python 3 and comes with Idle installed.) I got a new RPi kit ahead of time and walked myself through configuration (which has gotten a lot easier over the years - we no longer have to do everything from the command line). Our kits included wifi dongles that were easily omitted from the beginner setup, added for the intermediate, and everything just worked.


What Didn't Go As Well

We had a fairly low turnout this year, in both classes. Registration numbers weren't particularly high to begin with, and then we had quite a few no-shows, both among students and volunteers/TAs. I suspect that we did not communicate enough with our students or volunteers beforehand, and to that end I'm thinking of putting together a mailing list to keep volunteers up to date throughout the year. We also didn't promote the classes very heavily leading up to the conference - they're always so well-attended that I didn't think we needed to, but next year I'd like to do some more outreach to the local community.

As it happens, the low turnout was a blessing in disguise. Katie had to leave sprints early, and I've been struggling with an inner ear infection and vertigo that would have made it impossible to stand all day. So we sent out a call to the local teaching community and got a couple of volunteers to take over - Andrew Dupont and Taylor Meek. The two of them handled the beginner class masterfully and with humor. I was feeling a little better on the second day, so the three of us partnered up for the intermediate class. (It's certainly possible to teach either class solo, but having multiple teachers helps balance the load and allows for more personal interaction with the students.)

We also ran into a few technical issues, but not as many as I expected. For the intermediate class, we used PythonAnywhere to walk the kids through building a web site. The browser that comes with the Raspberry Pis - Epiphany - was a little slow, and didn't function well with some of the features of PythonAnywhere. During the lunch break, we installed Iceweasel on most of the Pis, and that worked beautifully. (I did walk-throughs of all the web content on the RPi ahead of time and didn't encounter any problems, so I think we might chalk that up to slight differences in operating system versions.)

Distractions were a problem, but not in the ways you'd expect. Giving the kids an internet connection wasn't an issue - they used it to read documentation and look at some of the resources we gave them. The real distractions came from devices that the kids brought with them. You can ask students to put their phones away, but what can you do if they don't comply? Our best approach was to move fairly quickly and give plenty of personal attention, two things we wouldn't have been able to do with a larger class size.

And then there's presentation, a general problem we still haven't figured out how to handle perfectly. The classroom content is on slides in Keynote - I wrote them there so that we could use speaker notes not visible to the students. But when we need to tab over to Idle or a browser to demonstrate something new, it's a clumsy process to get in and out of presentation mode. That would be true whether we used Keynote, PowerPoint, SlideDeck, or any other formal presentation medium. I'd like to move the content to Jupyter (formerly IPython notebook), but then I think we lose the option of having presenter notes that are only visible to the teacher. So I'm still searching.

Oh, and the Class example I used when talking about objects and OOP: I should not have used a 'Ball' as my example object. Not with a room full of 12-year-olds.


I'll be making a few changes to the Intermediate slides, mostly adding things we realized we wanted as we were teaching. It might be a week or so from the time I publish this before I actually have all the changes in, but feel free to take a look now if you're curious. (I'll also be adding instructions for the iceweasel install.)

Young Coders 2016 (on Github)

Powered by Django

Dynamic Inlines in the Django Admin

Date: Aug 03, 2016 | Category: Django Django1.9

I'm not sure how many of you know this, but in the interest of having a well-rounded life, I make a lot of things in my spare time. Over the years, I've been a costumer, a jeweller, a photographer, and a Read More

Powered by Django

Bonus Points For Project-Based Interviews

Date: Jul 27, 2016 | Category: Personal

I'm in the middle of a job hunt right now, and so I'm thinking about a lot of issues as they relate to questions I'm asking during interviews. How do these companies determine 'culture fit'? How do I know whether or not their culture is inclusive? Will I be taken ...

Read More

Powered by Django

Looking Ahead

Date: Jul 22, 2016 | Category: Personal

After nearly four years at my current company, I am looking for something new. I love my team, and I'd happily stay here longer (the challenges laid at my feet over the years have been exciting). But the business has made a decision to eliminate Python, sunsetting all the current ...

Read More

Powered by Django

PyGotham 2016 - "Young Coders (or, 'How To Teach Python To Kids')"

Date: Jul 16, 2016 | Category: PyKids Python

(Note: These are the slides and speaker notes from my 2016 PyGotham talk, "Young Coders (or, 'How To Teach Python To Kids')".)

This talk is for any Python programmer who's interested in passing their knowledge on to younger students. And I really do mean ...

Read More

Powered by Django

Young Coders: Intermediate

Date: Jun 07, 2016 | Category: CS Education PyCon Python

We've been putting on a Young Coders class at PyCon North America for several years now - it started in San Jose, continued in Montreal, and has morphed into something a little more challenging in Portland.

The original class is aimed at beginners. While we try to recruit kids from ...

Read More

Powered by Django