Quick conferences report: Presentations

My lovely Fiancée, Audrey Roy, was invited to be the opening keynote speaker at both PyCon Australia on Diversity in Python (video) and PyCon New Zealand on Python on the Web.

As for me, I managed to get talks into both of those conferences AND DjangoCon US. I co-presented on three of them, and I share all credit for success with my cohorts. The talks I gave at the conferences were (I'll post videos when they get up):

Confessions of Joe Developer (PyCon Australia, DjangoCon US)
The genesis of this talk was as a lightning talk at I gave at the Hollywood Hackathon. It is a talk about admitting that us mere mortals need to ask questions, take notes, and follow good practices in general. I gave it again at LA Django this summer, extending it to a full length talk complete with lots of technical content. At PyCon Australia I toned down the technical content because I was nervous, and while the response was positive, it  could have been much better. So for DjangoCon I ramped up the tech-talk and it worked much better. I've now given the talk 4 times, and I'm leaning towards retiring it.

 

Python Worst Practices (PyCon New Zealand)
This talk grew out of a SoCal Piggies lightning talk which I gave for the purpose of humor. Often we as Python developers are smug in the clarity of the language that we don't realize just how easily we can obfuscate code. In fact, I contend that Python is fully capable of a code obfuscation contest. This talk rejects a lot of crazy practices I've either done myself or had to debug from other people's work. For New Zealand I added a ton of content and tested things pretty diligently. The variable naming pages stumped some people I really respect and I was quite happy with that result.

 

Django Packages Thunderdome (co-presented with Audrey Roy, DjangoCon US)
Audrey did most of the work for this presentation. In this talk I helped review a horde of Django Packages across 7 different categories. It was nerve wracking because every part of our talk would get judged - but Audrey kept things really positive and made it clear we were providing constructive criticism. I think she got her message across to most people, and more importantly, it got a lot of people thinking about what ought to be normal community standards. I'll probably blog on those community thoughts and statements later, but I think Audrey (with help from me) accomplished what she aimed to do.

View more presentations from Audrey Roy

Advanced Django Form Usage (co-presented with Miguel Araujo)
Some time ago Miguel befriended me and helped resurrect the django-uni-form project. He graciously agreed to help me present on Django Forms and we decided to make the talk as sophisticated as possible. Previous Django form talks have been good, but focused on the fundamentals and we wanted to do something really different. This talk was hard because Miguel and I were on opposite sides of the planet, so we did a lot of github pull/pushes. In both doing research and presenting Miguel did an unbelievably good job and I hope he does more of this in the future. The response was extremely positive and I'm certain that our plan of getting our notes/work/transcript into Django core is well on it's way.

 

Ultimate Django Tutorial Workshop (DjangoCon US)
I got about 10 professional Django experts in a room, including Django core developers, and had them help me coach nearly 20 people through a modified version of the Django tutorial. Students seemed to learn tons, lots of socializing happened thanks to some happy accidents, and the experts got a chance to really see where the Django tutorial needs work. PyLadies organizer Esther Nam spent her sprint days working on something that ties the slides into the Django Tutorial - and for now I'm holding off on sharing my work until she says her work is done.

Summary
These were amazing opportunities to speak and will hopefully make a difference. I wouldn't have traded all of this for the world. It was a lot of work, and I doubt I'll ever go quite at this pace again. My plan is to do fewer talks and make them much better.

Responses to Github is my resume

Shortly after I posted Github is my resume the responses started coming in. They seemed to fill these categories:

"Github is a portfolio, not a resume!"

I think this is rather valid, being a much more accurate description of the role that Github and other social coding sites are having in getting developer jobs these days.  Two of the more choice responses in this category were posts by Gini Trapini and Andy Lester.

"In X years of hiring, I've never requested source code along with the resume!"

This comment raised the issue that personality, location, writing skills, etc were important. I agree that being able to not annoy your team into losing productivity is important, but it doesn't negate the frequent desire to be able to review the work of potential hires. Ignore the code at your own risk.

"Using only binary for calculations, how many ping pong balls fit in your car?"

A couple people said they prefer to ask programming questions or challenging problems in interviews to seeing portfolios of code. Personally, I think a few programming questions are okay but in my opinion 'challenging problems' all too often means sticking your interviewees with puzzles and trick questions that all too often have nothing to do with the day-to-day work of being a developer.

Github is my resume

I remember the first time I heard that statement - a couple years back Eric Florenzano said it to me on Twitter when I posted my resume publicly and asked for opinions. At the time I laughed at his statement, because it felt like naive arrogance to ditch the idea of a resume and 'traditional' social networking like Facebook and LinkedIn. How wrong I was...

Before I go any further, this isn't to say that education, job history, and references aren't important in getting jobs that utilize a lot of Python. They are important, but I think they go more towards shaping you as a person than getting a job. So if you want access to Python jobs (and possibly other open source languages), you need to be able to show working code. Why is this the case? I can thing of several reasons:

1. It is much harder to forge your style of code, comments, tests, and docs in a repo than it is to make false claims on a resume.
2. Development team managers don't take LinkedIn references seriously because how often we see them gamed.
3. Code gives us a body of work employers (including me) can use in order to help evaluate your skill and ability levels.

Let's summarize that into a bold statement:

Python employers want to review your code in a public repo.

That puts the pressure on you doesn't it? Now you've got to show working code. One extremely unethical way to do that is to copy/paste other people's code into your own repo and claim it as your own. The problem with that is real reviewers know good code doesn't just magically appear in gigantic chunks. Which I'll sum up with another statement:

Python employers are smart enough to read your commit log.

So as a beginner, what can you do? A lot of shops will want to see your code but if you put up your early code, doesn't that mean they'll see your ugly, mistake-ridden work? Yes they will - but if you keep at it with tutorial examples you are working, whatever pet project you cook up, or even submitting patches to various existing projects, they'll see how your code improves. I am much more inclined to hire a person able/willing to learn than a jaded expert who doesn't want to grow - which is why I always try to think like an eternal beginner. Which brings me to my third statement:

Python employers are willing to hire bright, hungry developers willing to learn.

Getting away from employment, let's talk a little about the Python development community. This community is a meritocracy with amazing foresight. Passion for code and/or natural talent is often recognized before skill is achieved - but only if you show the community you are learning. Get your code onto Github, or BitBucket, or SourceForge so it is seen, and keep at it! Try to commit every day and if that isn't possible, then once a week!

Because if you write code every day or every week, over time your code will get better, you'll also be able to demonstrate a consistent body of work, and your passion for software development will be obvious. Also, try to comment your code as much as possible.

One good trick is to put your ongoing notes in a repo. I do it myself at https://github.com/pydanny/pydanny-event-notes. My early notes are very, very different from my later notes. Often embarrassingly so, but to a Python employer I'm pretty certain they are a useful reference into just how I think.

Github, not LinkedIn

LinkedIn (and Facebook, Google Plus, et al) are a place to define your profile and nothing more. That profile should include a link to your code. Python employers will be looking your for links to your code, not for any sort of networking you do on those sites. Employers get annoyed by 'developers' who excessively network but have no links to code samples on Github or other similar sites. If you have no code to find then it means we can't see your work, your thought processes, or your passion.

One common technique you see by a lot of Python developers is posting quick links to their projects and efforts on Github using various social networks. You can and should do the same.

You make connections by showing you want to learn

The Ultimate Django Tutorial Workshop

That is a big statement to make as a title of a class/workshop blog post. However, in this case I believe I'm fully justified because this is going to be awesome. Here's why:

1. The teachers are beyond incredible

In the course description it says I'm the teacher and I have lab assistants. In retrospect, what I should have said is, "Daniel Greenfeld is organizing a workshop taught by the people he respects and admires".

Think I'm kidding? Look at just some of the names of people I've got lined up to participate:

• Jacob Kaplan-Moss, Benevolent Dictator For Life of Django
• Russell Keith-Magee, President of the Django Software Foundation
• Audrey Roy
• Jacob Burch
• Katharine Jarmul
• Corey Bertram
• Sandy Strong
• Jonas Obrist
• Christine Cheung
• Shimon Rura

Follow those links to their bios or talks and you'll see that they are the people speaking at DjangoCon.  The general idea is to get the people already speaking at DjangoCon or those who are extremely experienced in it to teach the class.

2. The teacher to student ratio is going to be really small

This is not going to be a room with a few instructors and umpteen students in it. If the class size gets big, I'm going to bring in more teachers. I'll cajole, plead, and do whatever I must to get them in the room. I don't want anyone left behind!

I want a ratio of 5 students to each teacher.

3. Class implemented with a lot of lessons learned

I've taught a bunch. So have a number of the instructors I've lined up. We know which parts of the tutorial are important to focus on, and which parts should be visited by students later on their own. This means you learn the critically important parts that get you kick-started as a Django developer.

One thing we'll try to squeeze in is deployment to one of the new Django hosts such as Djangozoom.com, Gondor.io, and ep.io. In fact, Shimon Rura, one of the co-founders of Djangozoom, participating as an instructor.

4. We're all volunteers

All the proceeds earned by the instructors for this course will be going to the Pyladies Sponsorship program. That is important for two reasons:

1. Your attendance will help Pyladies sponsor more women to learn Python in the future.
2. The teachers are doing this because they want to do it. They want you to learn Django.

5. It won't end at 12:30 PM

Officially the tutorial ends at 12:30PM and we should be done. Sometimes though we stumble on things  and we don't finish with the rest of the class (like me in my last C programming class). But after a lunch break I'm planning on grabbing some space and working through the rest of the tutorial with anyone who didn't complete the class.

6. The tutorial opens DjangoCon

The tutorial starts on Monday, September 5, 2011 at 9:30 AM at the Hilton Portland and Executive Tower at 921 SW Sixth Avenue in Portland, Oregon, USA. If you do plan on attending DjangoCon and are new to the framework, what a great way to get started!

7. You don't have to attend DjangoCon itself to take the tutorial

Tickets for the event are being sold separately from the conference. So if you can't take off more than one day of school or work, this is a great way to capitalize on DjangoCon.

Convinced? Here is what you need to know and do to get signed up:

• Get a laptop running Windows 7, Mac OS X 10.5 or higher, or Ubuntu.
• If there is no Python installed, install Python 2.7.1. DO NOT INSTALL PYTHON 3!!!
• Make sure you have a grounding in Python. If you are new to Python you need to have finished at least half the chapters in learnpythonthehardway.org before you attend. If you come to this event with no prior Python experience you will be left behind.
• Buy a ticket!

Amtrak Review

Audrey and I got invited to a wedding in the Pacific Northwest. And mostly to try something new, we decided to take Amtrak's Coast Starlight from Los Angeles' Union Station to Seattle, Washington's King Street Station.  There was some incredible awesomeness about the trip, and a lot that... wasn't so awesome.

No Internet (Bad)

Thanks to encroaching deadlines we planned to take advantage of Amtrak's wireless Internet, otherwise we would have flown. Each direction took 36 hours, which is basically two days. Which meant four working days on the train. Sure, we would have liked to have sat back and just enjoyed the journey, but for us that wasn't an option on this particular trip.

Unfortunately, both the ride there and the ride back lacked internet. In the first case the car with it wasn't part of the train. On the way back the car was part of the train but the Internet was nonfunctional. Which cost us nearly 4 days of work.

We did manage to use our cell phones for tethering, but coverage on rail lines is not that good. Each time we hit a town we connected and caught as much as we could. It wasn't ideal, but it worked. We're still trying to dig out from under work time lost.

What you should know is that more experienced Amtrak passengers all said that they've never had working Internet. There is always a problem on long journeys on the Coast Starlight. Which means don't use the train for business.

The Room (Okay)

We aren't big people and are fairly flexible and athletic. So the roomette we got was quite snuggly. Larger people or those unable to maneuver in tight spaces will probably be uncomfortable.

However, I think if I did this again I would get a bigger room. They have restrooms built in, but I think I would use external bathrooms so as to keep the room smelling nicer.

Food (Okay)

The breakfast eggs and dinner steak rocked. So did the ribs. The coffee was good. Everything else was mediocre at best.

The juices they served tasted like they lacked any connection to natural substances.

Room Attendants, Conductors, and Lounge Car attendant (Good)

The room attendants were amazing. They worked their butt off and got no sleep. I made sure to tip them well. The conductors were also extremely helpful. The first lounge car attendant, a guy named 'CJ' was incredible - he lacked a real lounge car and simply made do.

Diner Car Service (Unacceptably Bad)

The service in the Dining cars was uniformly bad. They were rude, obnoxious, and did their absolute best to avoid eye contact. One meal, when we waited two freaking hours for our food while others got seated and finished after we ordered, was unbelievable. If we asked about our food or drink refills we got snapped at. In retrospect, we should have gotten up and left - or filed a formal complaint.

After several attempts to weather the bad service we took all meals in our private roomette.

Scenery (Outstanding)

This is the part of things that was incredible. The Coast Starlight goes through some amazing scenery, from the beaches of Southern California to the incredible forests and mountains of the Pacific Northwest.  Pictures just don't do it justice - you have to see it sometime for yourself.

Conclusion (Okay)

The lack of Internet was annoying. The abominable dining car service was infuriating and Amtrak should give their dining car servers some basic lessons in proper restaurant hospitality.

Those things said, because the scenery was just that lovely, I might consider taking another multi-day train ride over a time when I wasn't trying to hit deadlines and would avoid the dining car at all costs.

Python and Django class/hackathon!

The Los Angeles Python community (LA Django and LA PyLadies) is meeting in Santa Monica on July 23rd to teach Django and hack on all things Python on Saturday, July 23rd. The day will start with a Django class based on the official Django tutorial, then turn into a general hackathon, and finish up with lighting talks.

Leading the event is noted Pythonista Katharine Jarmul. As Katharine is giving the talk on web scraping at DjangoCon US, I'm hoping we can get her to give a lightning talk on the subject.

Learning Django

Sandy Strong will lead the effort to  teach people the fundamentals of Django. Besides all things Django and devops, Sandy is presenting the testing talk at DjangoCon US. And if that isn't good enough for you, she won't be alone teaching - there will be a bunch of us developers experienced with Django there to to provide her with support.

Even if you already know Django, please come and hang out for the first half! You can either help out others or work on your own project.

Hacking Python and Django

The second half of the day will be about working on whatever you want. If you are new to Django and want to finish the tutorial, go right ahead. Or you can work on your own pet Django or Python project. In fact, I know that there will be work on the nascent Pyramid project intended to represent the entire Los Angeles Python community.

Lightning Talks

We'll finish with lightning talks. Several people who attended the day will get the chance to talk for 5 minutes or so about a project, tool, or cause they wanted to share. If they go too long we start applauding until they step down.

Social Hour

After another awesome day of Python in LA, everyone will cool down by hanging and chatting over drinks. If you're lucky, maybe you'll get to see me do a drunken one-handed cartwheel where I don't spill a drop of what I'm holding.

My role

I'll be there in my normal role of setting up tables and chairs, helping during the class portion, and hacking on some Packaginator stuff in preparation for the forthcoming August/September Packaginator sprints at PyCon AU, Kiwi Pycon, and DjangoCon US.

Sponsors

This is all possible thanks to the sponsorship of Mahalo, Cars.com, and the Python Software Foundation

Sign up!

Tickets are selling out really fast! Sign up now!

Normalization noitazilamroN

Since pretty much the start of my career as a developer back in the 1990s one skill I've carried from job-to-job has been an understanding of relational databases. Over the years I've worked with Foxpro, Access, Oracle, SQL Server, MySQL, Sqlite, and now PostGreSQL.

Interestingly enough, database normalization comes instinctively to me. I knew about complex SQL joins and unions and subqueries before I read anything about normalization. As I read up on normalization, it was rather exciting to discover that my natural instinct during database design was to hit the fourth or fifth normal form without thinking about it.  And since for most of my pre-Python career the number of records I dealt with was measured in the tens of thousands, normalization was a great tool. I was aware that my record sets were smallish, and good database design kept my stuff running fast.

Relational Databases are not a panacea that lets you overcome bad code.

It surprises me how many developers I've encountered over the years who complained about the performance issues of normalized data but didn't understand normalization. Instead, they refused to follow any sort of standard and every table seemed to duplicate data and every query requires complex joins for trivial data calls. And usually with sets of records in the count of tens of thousands, not millions or billions. The end result are projects that were/are unmaintainable and slow, with or without normalization.

NoSQL is not a panacea that lets you overcome bad code.

Which brings me to the current state of things. NoSQL is a big thing, with advantages of NoSQL being touted in the arenas of speed, reliability, flexible architecture, avoidance of Object relational impedance mismatch, and just plain ease of development. I've spent a year spinning an XML database stapled on top of MS SQL Server, years using ZODB, and about a woefully short time working on MongoDB projects. Like relational databases, the sad truth about XML, ZODB, and MongoDB is that there are problems. And just as with relational databases, the worst of it stemmed not from any issues with data systems, but developers and engineers. Like any other tool you can make terrible mistakes that lead to unmaintainable projects.

So for now, like most of the developers I know, what I like to do is as follows:

1. Create a well-normalized database preferably using PostGreSQL.
2. Cache predicted slowdown areas in Redis. 
3. Use data analysis to spot database bottlenecks and break normalization via specific non-normalized tables.
4. Use a queue system like Celery or even chronjobs to populate the non-normalized table so the user never sees anything slow.
5. Cache the results of queries against the specific non-normalized tables in Redis.

The end result is something with the rigidity of a relational database but with the delivery speed of a key/value database.  Since I work a lot in Django this means I get the advantage of most of the Django Packages ecosystem (at this time you lose much of the ecosphere if you go pure NoSQL). You can do the same in Pyramid, Rails, or whatever. Maybe its a bit conservative, but it works just fine.