The Story of Live-Noting

Like a lot of people, I've got this thing I do when I attend conferences, meetups, classes, and tutorials: I take notes. My open source based ones are mostly written in RestructuredText and I've kept in a particular folder since at least 2006.

Putting notes in a DVCS

On September 13, 2009, I uploaded these notes to Github.com. I did that because I wasn't pleased with the workflow I established of moving items to Dropbox for backup. I use DVCS all the time and I figured why not just put my notes where I put my code? So I added my notes as a Github repo.

DVCS Notes Based Management System?

For a while I tried to use the Github folder README.rst trick to make a navigations system for my notes. But Github isn't designed for making a README into a dynamic custom content navigator, and it would make a silly feature request. I would rather the Github team work on Mercurial integration or other practical things before they honored a request to turn their system into my own custom Notes Management System. Eventually I just gave up on it and moved on.

Sphinx + Read The Docs!

In early July of 2011 I had a wicked fun thought. What if I turned my notes into a Sphinx project and posted it on readthedocs.org? Most of my content is in RestructuredText and I've gotten really fast at rolling out Sphinx documentation. The 'hard' part would be converting the few README.rst files into index.rst files, but on the flip side I could use fancy Sphinx directives.

I'm not exactly sure when I started down this path, bit this commit log entry leads me to think I had it working on or around July 8th. What that would mean is that every time I pushed up a change in my notes, within minutes readthedocs.org would publish the content to the world in lovely HTML markup.

The result?

Pydanny Event Notes

Here's a screen shot of the front page

PyCon Australia 2011 Test Drive

For the 2011 PyCon Australia I gave my new process a serious whirl. I found if I created the page before the talk and entered some basic data like author and title and tied it to the index then I could constantly check the quality of my output while taking my notes. It made my notes seem a bit more exciting and alive. I even tweeted about it cause I thought it was fun, and people around the world seemed to enjoy the effort I was putting into my notes.

Because I was committing constantly in order to get updates on readthedocs.org as soon as possible, I also adopted the habit of super-short pull request messages. That's because the content I'm writing overrides the need for verbose comments. So when you see me writing "moar" it's because every minute or so I'm doing something like:

$ git commit -am "moar"
 $ git push

Kiwi PyCon 2011

I did my rapid note taking again at Kiwi PyCon and it was fun. The downside was that sometimes I get rather critical in my notes and I had a couple speakers come up to me later to clarify their positions. This makes it a bit challenging because I want to put down my thoughts, but if my thoughts impact another person, what should I do? Especially since if my negative notes on someone turn up in a search it can negatively impact the speaker way beyond a single talk. This is now always on my mind when I take notes, and I'm trying to figure out a good way to handle this going forward.

In essence, I don't want to constrain what I write but I also don't want to write something that will haunt someone else later. Even with a caveat and all that stuff, it can still be problematic. There is a difference between me ranting about something and me taking notes, and the written word is such that things are all too often taken out of context.

Food for thought indeed.

DjangoCon 2011 and the invention of the term 'live-noting'

At the start of DjangoCon 2011 someone tweeted that they were planning to 'live-blog' the event. Suddenly I realized that what I was doing had a name for it, and that was 'live-noting'. So I tweeted that was what I was doing and it seemed to catch on.

Not only that, but I got asked if I would accept pull requests. After a good two seconds of deep thought, I responded that I would only consider corrections and clarifications, not new material. I received not just one, but two pull requests from good friends and left the conference pretty happy.

On top of that, I managed to get featured on the front page of http://readthedocs.org! (Thanks Eric)

Kenneth Love also took notes in a similar fashion: readthedocs.org/docs/djangocon-2011-notes

PyCodeConf 2011

I had the excellent fortune of being an invited speaker to Github's PyCodeConf. While I gave my talk, my lovely fiancée, Audrey took notes of my talk and submitted a pull request. Her contribution was the first time I accepted content I did not write, and I'll say right now she's the only one for whom I will accept such content. On the other hand, If you take notes when I present let me know and I'll link to them from my own notes.

Josh Bohde also took notes at the event in a similar fashion readthedocs.org/projects/joshbohde-event-notes and even as I write this post he shares the featuring of our notes on the frontispiece of readthedocs.org:

Closing Thoughts

I often use my notes as reference, and if you follow the commit logs you may even see me comment or clean up things I wrote down years ago.

The graphs and stats of this effort is really interesting. Fortran? And a total of
Five contributors!

All of this makes taking notes a lot more fun. I enjoy finding ways to enhance and improve my process, and find it exciting that others are following a similar pattern of effort. My hope is to make 2012 the Year of PyCon, where I find a way to go to a Python related conference on six continents (Antartica is too cold for my tastes) and take notes everywhere.

Going forward, should I document how I built this out? Would my steps and patterns be useful for others?

Conference Talks I want to see

I'm writing this the day after Github's pycodeconf ended. That was an amazing conference, and I'll be blogging it soon (I'll also be writing about PyCon Australia, PyCon New Zealand, and DjangoCon US). With all this conference experience very current in my head, things I've seen and done at them, and the deadline for PyCon US submissions coming up, here are some talks I really want to see happen in the next six months. If not at PyCon US, then please consider these for other forthcoming events!

Note: Couldn't do my preferred 'linkify' as well as I liked thanks to bad hotel internet. I'll clean it up later.

Advanced SQL Alchemy Usage

I think the uber-powerful SQL Alchemy ORM needs the same sort of treatment me and Miguel Araujo gave on Advanced Django Forms Usage. Not a 30 tutorial or overview or 'State of', but tricks and patterns by someone who has used it frequently on more than one project. Multiple projects is important because the speaker should have had the chance to try multiple approaches. Start with something simple like a TimeStampModel all model classes might inherit from, then go into deeper and and more complex technical detail. Finish the talk with something crazy hard from SQL Alchemy that is hard to explain. If that causes you to open a bug/documentation ticket, then you'll know that you've done the talk right.

Advanced Django Models Usage

Following the same pattern as my SQL Alchemy idea above, start with something simple like a TimeStampModel (including South migration of fields), then go into complex looks with Q objects, good patterns for Managers, Aggregation, Transactions, and then finish it with the craziest, hardest thing you can find. When putting together the closing material causes you to open tickets for broken core code/documentation, then you know you've done it right.

Python Code Obfuscation Contest

This certain-to-be-controversial talk idea would be where the speaker would solicit Pythonistas to submit a single arcane Python code module that would have to display the text of "Although that way may not be obvious at first unless you're Dutch." There would be a 'Expert' category which would forbid the eval/exec functions. The "Anything Goes Category" would allow use of eval/exec. The conference talk would be where the speaker announces the winners and comments on the brilliant insanity of submissions.

Django + Flask + Pyramid: A demonstration of useful things you can do with WSGI

At pycodeconf Armin Ronacher showed how with WSGI, he can run Django, Flask, Pyramid all from same server from the same domain. This surprised a lot of people, including me, and I want to see more of what Armin was talking about. I don't want any theory. I don't want anything obscure. I just want meaty bits I can implement the day after I hear the talk.

Zen of Python

Richard Jones gave his version of the talk at PyCon AU, and I want to hear other opinions about it. I'm happy to hear an expert give his view, and I would also be delighted to hear how a beginner (or relative beginner) feels about it.

Websites and OO Design Concepts: A Tutorial

For beginners, I would love to see a talk on a list of OO theories, and as each list item was discussed, examples designed in the context of a web site, how to do things right, plus identified anti-patterns would be presented. The web angle would be a good way to get the incoming Python web crowd to attend and identify with raised issues.

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.

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

I'm going to Pycon Australia!

I'm flying across the pacific! To a new continent!! To Sydney, Australia!!!

Okay, take a deep breath...

My girlfriend, Audrey Roy, is going to be giving a keynote speech at Pycon Australia. I'm going with her because, well, we travel everywhere together. To make the trip even more awesome, there was some last minute room in the schedule and the organizers of the conference offered me a speaking slot.

When and where will we be?

Pycon Australia will be from August 20th and 21st, with sprints the 22nd and 23rd, all at the Sydney Masonic Center at 66 Goulburn Street. Register and hang out with us!

What will we be presenting on?

Audrey's keynote is still in the works.

As for me, I'll be giving the new and improved version of my (in)famous Confessions of Joe Developer talk, of which the 'old slides' are here. You'll get to hear me confess about my shortcomings in public and in return I'll pass on tricks I've learned to convince people to believe that I know what I'm doing.

What will we be sprinting on?

I'll be leading the sprint on Packaginator, the framework behind Django Packages. The goal will be to finally launch Python Packages. Python Packages won't replace PyPI, it will simply provide a new window into what our wonderful Python community has produced. And I'm excited to work have our wonderful host, Richard Jones, as a resource for questions about PyPI API questions and systems sure to arise.

Audrey has told me she may assume her role as co-lead of Packaginator or work on another one of her great ideas (she created the idea for Django Packages - I just tagged along).

Will Pyladies host a workshop or hackathon in Sydney?

Audrey tells me there has been some interest from the Australian Python community in running a Pyladies event around Pycon Australia. She's put out a call-to-action and wants to do something the day before or the day after Pycon Australia. Please contact Audrey at audreyr@pyladies.com if you want to know more or volunteer.

Please come and say hi!

There will be lots of people there, and I'm asking everyone in greater Australia and nearby nations and planets interested in Python to register and meet us!