The PyCon tutorial on Django in Depth was ending. I had been sitting next to my friend Barbara and we got up to go when I heard a feminine voice ask: "Are you bshaurette?" I turned and it was like I got punched in the gut.
It was the first time I met Audrey. I remember every detail of how she looked at that moment. The clothes she was wearing, the part in her hair, that her eyes met mine, and that they didn't turn away. I was immediately captivating, but fortunately remembered to act like a gentleman. I tossed in a casual invitation to her to join us for lunch, which I pulled off even though my heart was pounding. Thankfully she accepted.
Life has been pretty much awesome ever since.
That was the day I met the love of my life.
Reposted from Two years ago today.
Showing posts with label pycon. Show all posts
Showing posts with label pycon. Show all posts
Friday, February 17, 2012
Monday, February 13, 2012
Working on the Aú sem Mão
One of my resolutions for 2012 is to perform an Aú sem Mão/aerial/no handed cartwheel. Ideally, I would be able to do it before PyCon US, and would perform it during the Capoeira Open Space.
Speaking of the Capoeira Open Space, have you signed up yet to participate? Your skill level or athletic ability doesn't matter, just come and have fun!
I'm getting there.
I can do a butterfly kick badly, mostly because I don't arch my back enough. My hope is to get my head down further and my legs up higher. The end result is Aú sem Mão, right?
Because I haven't done it before. And there is no time like the present. :)
Speaking of the Capoeira Open Space, have you signed up yet to participate? Your skill level or athletic ability doesn't matter, just come and have fun!
How I'm training
- Losing enough weight to make jumping easier without losing strength/endurance.
- Practicing a lot of Capoeira. Especially on my non-workout days
How I'm doing
I'm getting there.
I can do a butterfly kick badly, mostly because I don't arch my back enough. My hope is to get my head down further and my legs up higher. The end result is Aú sem Mão, right?
Why am I trying to do this?
Because I haven't done it before. And there is no time like the present. :)
Sunday, February 12, 2012
Capoeira at PyCon!
For several years I've wanted to have a Capoeira event at PyCon US. Think of it: a lively blend of martial arts, music, dance, and nifty moves all done with and for a large crowd. Well, this year it looks like it may happen! PyCon is giving us a room and my own teacher, Contra Mestre Xingu will be in town. We would love for you to join!
The only hindrance is before I can make this happen, I need just twenty (20) people to express interest in participating; either learn some beginner friendly moves, play in the Roda, or just play instruments.
We aren't going to make you do crazy tricks, in fact, anyone can do Capoeira. It doesn't matter if you've never done anything athletic, or you won the gold medal in Olympic gymnastics. Just fill out the form and we'll see you there.
Updates to this event will be tracked at the PyCon Capoeira Open Space
The only hindrance is before I can make this happen, I need just twenty (20) people to express interest in participating; either learn some beginner friendly moves, play in the Roda, or just play instruments.
We aren't going to make you do crazy tricks, in fact, anyone can do Capoeira. It doesn't matter if you've never done anything athletic, or you won the gold medal in Olympic gymnastics. Just fill out the form and we'll see you there.
Sign up for Capoeira at PyCon!
Updates to this event will be tracked at the PyCon Capoeira Open Space
Wednesday, February 8, 2012
Python Web Summit Questions needed!
I've been fortunate enough to land a moderating spot at the invitation only March 8th Python Web Summit that takes place at PyCon US 2012. The panel I'll be moderating is the somewhat contentious issue of code reuse across different Python frameworks. I'm working on some questions, but I would love input from the entire Python Web Community.
If you've got questions to ask, or ideas to suggest, please post them on this google moderator link.
If you've got questions to ask, or ideas to suggest, please post them on this google moderator link.
Wednesday, January 25, 2012
How to justify attending PyCon sprints
Sad that the PyCon sprints fall on business days? Wishing you could stay but the boss/client won't let you and demands you back so 'you can work'? This is how you make it so that the sprints are something your management is demanding you attend every sprint ever.
Rinse and repeat.
Then, when you attend the PyCon sprints, follow through on what you said you were going to do. Sure, it might be more fun to work on project 'spam' even though your company uses project 'lumberjack', but if you prove how much you got done during the sprints, next year the boss will be much more encouraging. Even if a good boss says to go do what you want, at least spend some time sprinting on work related technology.
Also, once you get approval to go, consider sending your boss to this old rant of mine.
Don't forget to register for PyCon! Early bird rates end today (January 25th, 2012) which means today is the last day to get involved in the extremely unofficial PyCon Early Birds program!
- Make it foremost in your mind that the wonderful thing about the PyCon sprints is that the odds are that anyone who knows anything about whatever you are doing in Python will be there.
- Write up a list of the things that you are finding challenging, hard, or impossible to do with Python.
- Now go to the boss and say something like:
"Because the experts and leaders of the open source tools we are using are going to be there, I want to attend PyCon sprints. All my time at the sprints will be focused on sitting around them and working on our tools. I'll focus on things that directly impact our agency / company / organization, specifically things I wrote down on this list."
- If the boss says,
"Why not just use IRC or email?"
Then you say something like,"Well, IRC/email is not the same as sitting next to these people. I'll be so much more productive there!"
Rinse and repeat.
Then, when you attend the PyCon sprints, follow through on what you said you were going to do. Sure, it might be more fun to work on project 'spam' even though your company uses project 'lumberjack', but if you prove how much you got done during the sprints, next year the boss will be much more encouraging. Even if a good boss says to go do what you want, at least spend some time sprinting on work related technology.
Also, once you get approval to go, consider sending your boss to this old rant of mine.
Don't forget to register for PyCon! Early bird rates end today (January 25th, 2012) which means today is the last day to get involved in the extremely unofficial PyCon Early Birds program!
Monday, January 23, 2012
Join the PyCon Early Birds program!
First off, I want to say that me and my fiancee will be attending PyCon US this year! Hooray! Can't wait to see old friends and make new ones. I'll be chairing one of the Panels at the PyWeb Summit on March 8th. We're absolutely delighted to see all the great talks, hang out in the hallway, and just be in the middle of Python for well over a week.
Now on to the extremely unofficial PyCon Early Birds program!
PyCon early registration ends on January 25th. If you register at the early bird rate that gets you the benefit of joining the elite PyCon Early Birds group. Being a member of the PyCon Early Birds gets you all sorts of incredible rewards and benefits.
Of course, PyCon has tons of other reasons to sign up besides the PyCon Early Birds program. Amazing tutorials, talks, and sprints, plus great hallway tracks, a vendor room filled with great schwag, poster sessions, and startup row. Sponsorship levels are unbelievably high, and since the event is non-profit that means the money just goes right back into the community - starting with PyCon itself. This year is going to be AWESOME!!!
So what are you waiting for? Sign up for the Pycon Early Birds before it's too late!
Now on to the extremely unofficial PyCon Early Birds program!
PyCon early registration ends on January 25th. If you register at the early bird rate that gets you the benefit of joining the elite PyCon Early Birds group. Being a member of the PyCon Early Birds gets you all sorts of incredible rewards and benefits.
- Most importantly, you get some serious bragging rights.
- A custom ribbon that says 'Early Bird' that you get to attach to your conference badge.
- A discounted rate from the regular ticket rate as according to the registration page.
- The confidence of knowing you have a ticket before they sell out.
- A tasty and rather edible store-bought cookie provided by myself and Audrey Roy.
- If the PyCon Early Birds program gets enough members, I'm going to challenge PyCon chair Jesse Noller to stump me with Yoga poses! There's no way he'll even consider accepting a challenge like this unless the PyCon Early Birds membership roster is big enough. So join and help me find out if his Bikram will beat my Capoeira!
- Other incredible things that are in the works!
Of course, PyCon has tons of other reasons to sign up besides the PyCon Early Birds program. Amazing tutorials, talks, and sprints, plus great hallway tracks, a vendor room filled with great schwag, poster sessions, and startup row. Sponsorship levels are unbelievably high, and since the event is non-profit that means the money just goes right back into the community - starting with PyCon itself. This year is going to be AWESOME!!!
So what are you waiting for? Sign up for the Pycon Early Birds before it's too late!
Saturday, January 21, 2012
Tips for speaking
Last year I wrote a blog post called My tips for speaking. In the face of SCALE 10X and other events coming up, this is my refactoring of that talk.
My experience in giving talks? I've been presenting on the job since 1999. I've been presenting at conferences since autumn of 2008. This past year (2011) I gave a lot of talks, helped others with their talks, and did a number of cooperative talks where I shared the stage with another person. I've learned a lot, from my own mistakes and those of others. Since I like to share, here we go.
In terms of presenting, Steve Jobs was no mere mortal. He got away with wearing black in front of a black background. His slides were frequently dark. And he held up tiny objects in front of literally billions of people. He did all of this and got away with it.
You. Won't.
Steve Jobs was billionaire leading a multi-billion dollar company. His presentations were highly choreographed affairs where every detail from lighting to audio to who got to attend was tightly controlled.
For example, Steve could wear black because of amazingly proficient stage lighting techniques. Carefully watch a high definition video of him showing off the latest product while in a black sweater and you'll see that he's literally standing in a column of light. Odds are most conferences don't have spotlights or fancy lighting, and even if they do - the stage crew are not being promised a bonus for doing it right and financial ruin if they fail.
What this means is be very, very careful about using the attributes of Steve's talks for inspiration or arguments on how you are going to do a talk.
Bring several presentation shirts to the conference so you can be sure that what you are wearing shows up in front of the background. Be a little classy and wear a polo shirt instead of that t-shirt. If the background is the same as your shirt, go and change. If you don't have a shirt that works, go buy one or wear your jacket.
The reason being is the same as why Newscasters don't wear some colors on video. They don't want to look like floating heads and hands. It happens to them, it happens at technical conferences, and it will happen to you.
I said it last year and I'll say it again: High contrast slides please. If a designer, manager, friend, or spouse tries to stick colored backgrounds or text into your slides, politely remind them that what shows up nicely on the monitor or laptop will absolutely fail to be appreciated by the attendees of the talk. Social media and IRC will be filled with comments about the unreadable colors of your slides.
Remember, unlike Steve Jobs, you have no control over the AV team or whatever the conference venue provides when it comes to projectors and screens. So play it as safe as possible.
I really prefer the black text on white background. The people in the vision community (arts, theatre, animantion, and eye doctors) all agree with me.
This past year I've had technical people (all with jobs outside the vision community) quote some interesting material about the validity of white text on black background, but I personally find it hard to read those slides if I'm in the back. Also, if the room is brightly lit, the letters are barely visible.
The happiest alternative I've seen was at a Mongo event, and was a certain shade of dark blue with bright yellow letters. However, I think like the black background, it would be suspect in the wrong light.
One last note: Don't use color gradients in your slides. Please.
I'm giving a talk today at Southern California Linux Exposition 10x called Intro to Python. It's inspired by folks like Raymond Hettinger and David Beazley. And the big thing I'll be doing is avoiding the command-line like the plague.
This is because the command-line is treacherous in front of an audience. Conference networks are notoriously prone to going down at the wrong moment. Same goes for laptops, especially when connecting to projector hardware it's never touched before.
Also, you know what it is like typing with someone looking over your shoulder? Imagine that times hundreds, or thousands when your video is being uploaded so people around the world can view it.
So either use something like PLayer Piano to record a command-line session in a docstring, or do what I do and use slide transitions to mock typing.
In 2011 I watched a guy fumble through a talk with beer in hand, a personal hero of mine blearily try to get through his talk after a late night of drinking, and a couple people try to present after all-nighters.
Respect your audience and take care of yourself before the talk. Get some sleep, eat well, and drink moderately. This will really help you get invited to more events.
In the past I've said I don't practice much. If at all. Ahem...
It has been pointed out to me that I practice. A lot. Maybe not in front of a mirror, but I'm constantly going through my slides and coming up with things to say. I'll go through all my slides one-by-one and mouth what I'll be saying, and work out the timing of things. Which means that while I haven't been projecting my voice, I have been practicing.
In 2011 I did the curious thing of actually trying to practice on a couple presentations. And I have to say that I've seen a huge amount of improvement. I certainly felt more confident and I feel like the talk goes better! For example, A talk I gave at PyCon AU 2011 that had some issues after a lot of practice went smashingly better at DjangoCon 2011.
Your talk should have a flow, a pace as it were. And lots of interruptions will cause you to lose your chain of thought, or cause the audience to lose focus. If someone asks a question during your talk, ask them to wait until the end.
If they keep asking questions or giving comments, ask them nicely to talk to you after your presentation. People are decent and will respond nicely to your request.
Early bird registration closes on January 25th. Sign up for it beforehand and you'll have enough money for a really good dinner with drinks. What are you waiting for? Go do it!
My experience in giving talks? I've been presenting on the job since 1999. I've been presenting at conferences since autumn of 2008. This past year (2011) I gave a lot of talks, helped others with their talks, and did a number of cooperative talks where I shared the stage with another person. I've learned a lot, from my own mistakes and those of others. Since I like to share, here we go.
You aren't Steve Jobs
In terms of presenting, Steve Jobs was no mere mortal. He got away with wearing black in front of a black background. His slides were frequently dark. And he held up tiny objects in front of literally billions of people. He did all of this and got away with it.
You. Won't.
Steve Jobs was billionaire leading a multi-billion dollar company. His presentations were highly choreographed affairs where every detail from lighting to audio to who got to attend was tightly controlled.
For example, Steve could wear black because of amazingly proficient stage lighting techniques. Carefully watch a high definition video of him showing off the latest product while in a black sweater and you'll see that he's literally standing in a column of light. Odds are most conferences don't have spotlights or fancy lighting, and even if they do - the stage crew are not being promised a bonus for doing it right and financial ruin if they fail.
What this means is be very, very careful about using the attributes of Steve's talks for inspiration or arguments on how you are going to do a talk.
What to wear
Bring several presentation shirts to the conference so you can be sure that what you are wearing shows up in front of the background. Be a little classy and wear a polo shirt instead of that t-shirt. If the background is the same as your shirt, go and change. If you don't have a shirt that works, go buy one or wear your jacket.
The reason being is the same as why Newscasters don't wear some colors on video. They don't want to look like floating heads and hands. It happens to them, it happens at technical conferences, and it will happen to you.
Black text on white background
I said it last year and I'll say it again: High contrast slides please. If a designer, manager, friend, or spouse tries to stick colored backgrounds or text into your slides, politely remind them that what shows up nicely on the monitor or laptop will absolutely fail to be appreciated by the attendees of the talk. Social media and IRC will be filled with comments about the unreadable colors of your slides.
Remember, unlike Steve Jobs, you have no control over the AV team or whatever the conference venue provides when it comes to projectors and screens. So play it as safe as possible.
I really prefer the black text on white background. The people in the vision community (arts, theatre, animantion, and eye doctors) all agree with me.
This past year I've had technical people (all with jobs outside the vision community) quote some interesting material about the validity of white text on black background, but I personally find it hard to read those slides if I'm in the back. Also, if the room is brightly lit, the letters are barely visible.
The happiest alternative I've seen was at a Mongo event, and was a certain shade of dark blue with bright yellow letters. However, I think like the black background, it would be suspect in the wrong light.
One last note: Don't use color gradients in your slides. Please.
Cheat at the command line!
I'm giving a talk today at Southern California Linux Exposition 10x called Intro to Python. It's inspired by folks like Raymond Hettinger and David Beazley. And the big thing I'll be doing is avoiding the command-line like the plague.
This is because the command-line is treacherous in front of an audience. Conference networks are notoriously prone to going down at the wrong moment. Same goes for laptops, especially when connecting to projector hardware it's never touched before.
Also, you know what it is like typing with someone looking over your shoulder? Imagine that times hundreds, or thousands when your video is being uploaded so people around the world can view it.
So either use something like PLayer Piano to record a command-line session in a docstring, or do what I do and use slide transitions to mock typing.
Be rested, fed, and sober for your talk.
In 2011 I watched a guy fumble through a talk with beer in hand, a personal hero of mine blearily try to get through his talk after a late night of drinking, and a couple people try to present after all-nighters.
Respect your audience and take care of yourself before the talk. Get some sleep, eat well, and drink moderately. This will really help you get invited to more events.
Practice, practice, practice
In the past I've said I don't practice much. If at all. Ahem...
It has been pointed out to me that I practice. A lot. Maybe not in front of a mirror, but I'm constantly going through my slides and coming up with things to say. I'll go through all my slides one-by-one and mouth what I'll be saying, and work out the timing of things. Which means that while I haven't been projecting my voice, I have been practicing.
In 2011 I did the curious thing of actually trying to practice on a couple presentations. And I have to say that I've seen a huge amount of improvement. I certainly felt more confident and I feel like the talk goes better! For example, A talk I gave at PyCon AU 2011 that had some issues after a lot of practice went smashingly better at DjangoCon 2011.
Push questions and comments to the end
Your talk should have a flow, a pace as it were. And lots of interruptions will cause you to lose your chain of thought, or cause the audience to lose focus. If someone asks a question during your talk, ask them to wait until the end.
If they keep asking questions or giving comments, ask them nicely to talk to you after your presentation. People are decent and will respond nicely to your request.
Sign up for Pycon US!
Early bird registration closes on January 25th. Sign up for it beforehand and you'll have enough money for a really good dinner with drinks. What are you waiting for? Go do it!
Thursday, December 29, 2011
Resolutions for 2012
- Go to a Python related conference in
North America, South America,Europe,Asia, Africa, Australia, and New Zealand. Attend at least one JavaScript related conference or event.- Upload all my outstanding pictures to Flickr!
- Make Consumer Notebook profitable.
Find more ways to make Audrey Roy happy.- Pull off an Aú sem Mão during a Capoeira Roda.
- Attend my first Capoeira Batizado.
See a place in the USA I've never been.- Work out at least three times a week.
Drop to a 32 waistVisit friends and family back east. Been over a year since I've seen my sister!Blog once a week. That is at least 52 blog entries!Visit a Theme park.- Learn how to surf or snowboard.
Implement something in node.js, backbone.js, and handlebars.js- Take a high level Python class from the likes of Raymond Hettiger or David Beazly.
Teach some Python or Django.- Have a beer with Thomas, Andy, Andy, Tony, Garrick, Bernd, and the rest of Ye Aulde Gange.
- See my old DC area friends such as
Eric, Chris, Steve, Beth, Sarah, Daye, Renee, Kenneth, Leslie,Whitney, Dave, and many others. Visit my Son.
Tuesday, December 27, 2011
2011 Resolution Summary
Items that are crossed out are completed.
- Travel to Europe again. Travel to Asia or Africa.(Went to Australia instead. Which was an very, very acceptable substitute.)
- Visit a Disney park.
See a place in the USA I've never been.- Drop the waist size 2 inches and
not break any bones. Go to Pycon and present or teach.Go to DjangoCon and present or teach.Present at LA DjangoContinue my Muay Thai and Capoeira studies, get back into Eskrima, learn some more BJJ, andpractice the forms I know.- Work out at least three times a week.
- Go back east and teach martial arts for a day.
Finish some outstanding legal proceedings.Launch a site that does cool stuff and somehow brings in money.(Consumer Notebook)- Get to the point with LISP where I can do cool stuff in it without needing a textbook. (I seem to have spent this time working on JavaScript instead).
- Blog once a week. That is at least 52 blog entries! (almost there!)
Explain why I wrote Diversity Rocks.
Sunday, December 4, 2011
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.
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?
Here's a screen shot of the front page
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:
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.
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
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:
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?
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?
Tuesday, August 23, 2011
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:
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
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:
- 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.
- Development team managers don't take LinkedIn references seriously because how often we see them gamed.
- Code gives us a body of work employers (including me) can use in order to help evaluate your skill and ability levels.
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
Wednesday, June 29, 2011
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!
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!
Monday, May 23, 2011
I love this girl!
In every person's life there are those incredibly memorable experiences that stick with you forever. The entirety of PyCon 2010 is for me that experience. You see, PyCon 2010 saw me introduced to the lovely, talented, and brilliant Audrey Roy.
Moments after I heard her lovely voice for the first time, we looked into each other's eyes. After that moment, I spent every waking moment of the conference finding excuses to spend time with her. Fortunately for me, most of her tastes for talks and social events matched my own. Within days we were dancing in each other's arms.
By the end of the PyCon we both knew we had something special. So after the conference we both flew back and forth across the country every two weeks for months to keep seeing each other. My phone bill skyrocketed. I became intimately familiar with Skype. It was crazy and magnificent. Finally, on May 5th of 2010 I moved out West to be with her for good.
Audrey may seem shy at first, but she has a fierce heart (FYI, she played Ice Hockey for years and did the bargaining for my car). She has a degree in Electrical Engineering and Computer Science from MIT. She supports me in everything I want to do. If you enjoy Django Packages and follow Open Comparison, she came up with the idea. We cook and eat healthy, and besides our differences on seafood/mac-and-cheese we are a food match. She loves my family and they adore her. She is a talented visual artist in any medium she attempts. As a developer, she learns unbelievably fast and produces high quality code in languages such as Python, C++, JavaScript, Objective-C, and anything else she touches. She hacks the Linux kernel so she can use her preferred peripherals. Her role in the technical community continually grows, and recently she launched the PyLadies advocacy group.
An incredible thing about Audrey is that she makes me a better person. I didn't see this at first, but my good friend and mentor Steve Holden pointed it out. She doesn't just bring me joy, she makes me a more tenacious, honest, and compassionate person.
Life is never perfect, but thanks to Audrey and the Python community that brought us together, life is just plain good.
 |
By the end of the PyCon we both knew we had something special. So after the conference we both flew back and forth across the country every two weeks for months to keep seeing each other. My phone bill skyrocketed. I became intimately familiar with Skype. It was crazy and magnificent. Finally, on May 5th of 2010 I moved out West to be with her for good.
Audrey may seem shy at first, but she has a fierce heart (FYI, she played Ice Hockey for years and did the bargaining for my car). She has a degree in Electrical Engineering and Computer Science from MIT. She supports me in everything I want to do. If you enjoy Django Packages and follow Open Comparison, she came up with the idea. We cook and eat healthy, and besides our differences on seafood/mac-and-cheese we are a food match. She loves my family and they adore her. She is a talented visual artist in any medium she attempts. As a developer, she learns unbelievably fast and produces high quality code in languages such as Python, C++, JavaScript, Objective-C, and anything else she touches. She hacks the Linux kernel so she can use her preferred peripherals. Her role in the technical community continually grows, and recently she launched the PyLadies advocacy group.
 |
| Airborne girlfriend! |
An incredible thing about Audrey is that she makes me a better person. I didn't see this at first, but my good friend and mentor Steve Holden pointed it out. She doesn't just bring me joy, she makes me a more tenacious, honest, and compassionate person.
Life is never perfect, but thanks to Audrey and the Python community that brought us together, life is just plain good.
Thursday, May 19, 2011
A couple great Pycon 2011 Talks
Yes, this should have been posted months ago... Anyway, so many great talks at PyCon 2011, here are two great ones! Being an eternal beginner, I try to hit both entry level and advanced talks.
How to write obfuscated Python
Why waste your time with one decorator when 10 of them attached to a function, each named as descriptively as 'X' or 'G' will make your code delightfully hard to interpret? Also included such goodies as 'object = str' which I borrowed for my own Python Worst Practices. In my opinion, Reverend Johnny Healy gave the funniest and obscure talk of the conference, and yet somehow managed to export some useful knowledge in the process.
The Data Structures of Python
Alex Gaynor gave a great 'beginner' talk here. As he went over the basic types in Python, and while he presented well, I wondered if this talk was for me. My hubris was that I thought the talk was beneath me. Then Alex dove into some more sophisticated material like namedtuples and collections and yet again I was reminded how periodically going over the 'basics' is a good thing. Alex kept his talk to a reasonable pace, giving enough time for people to take notes and truly understand what he was teaching. If the whole crazy programming thing doesn't work out for him, he might want to consider becoming an educator.
How to write obfuscated Python
Why waste your time with one decorator when 10 of them attached to a function, each named as descriptively as 'X' or 'G' will make your code delightfully hard to interpret? Also included such goodies as 'object = str' which I borrowed for my own Python Worst Practices. In my opinion, Reverend Johnny Healy gave the funniest and obscure talk of the conference, and yet somehow managed to export some useful knowledge in the process.
The Data Structures of Python
Alex Gaynor gave a great 'beginner' talk here. As he went over the basic types in Python, and while he presented well, I wondered if this talk was for me. My hubris was that I thought the talk was beneath me. Then Alex dove into some more sophisticated material like namedtuples and collections and yet again I was reminded how periodically going over the 'basics' is a good thing. Alex kept his talk to a reasonable pace, giving enough time for people to take notes and truly understand what he was teaching. If the whole crazy programming thing doesn't work out for him, he might want to consider becoming an educator.
Tuesday, April 5, 2011
PyCon 2011 Sprint Report
I love sprints. I've yet to participate in a sprint where I didn't learn something that made a difference in my programming career. Off the top of my head some of the things I've learned include distributed version control, picking the right Python tool, JQuery, SQLAlchemy, Bazaar, Git, Mercurial, the true importance of unittests, and Python's built-in zip function. And the PyCon 2011 sprints were no different.
PyCon 2011 was different in that this time I was going to co-lead a project, specifically Django Packages and the hopeful launch of Python Packages.
Note: The goal of Python Packages is not to replace PyPI, but rather serve as a resource to find, evaluate, and compare packages used in the every day life of a Python. In my opinion, PyPI should be dedicated to listing and serving packages - anything else (comments, ratings, documentation, etc) just adds complexity to the project and diffuses the focus of their team.
It all started with us being the second-to-last in line at the PyCon sprint announcements. At the microphone I forgot to mention a few things so I was worried that our attendance would suck. I tried to take it in good humor, but doubt worried at my gut. My co-lead, Audrey Roy, was confident that if no one showed, then we would have fun with just the two of us hacking away.
To our delight and surprise, turnout was good with about ten (10) people showing up. And thanks to lessons learned at DjangoCon 2010 and our tricks to getting more sprinters and helping sprinters deliver code, the number of participants kept growing. In the end we had twenty-four (24) new contributors to the project, which was simply amazing.
Test coverage had been mediocre on Django Packages, but after a show stopping bug got into production (someone changed a commonly used function to a property), we did a huge amount of work to not only increase test coverage but also refactor tests to be simpler and actually test rather than just increase coverage numbers. The improved quality and quantity of test coverage gave contributors the confidence to refactor and simplify some of the 'brilliant code' that I had written during the first month of the project.
We also got a bit draconian about accepting pull requests but documented how to get pull requests accepted. That might sound mean but if stopping one person's bug allowed ten (10) other people to maintain productivity then everyone is happier. Also, it allowed us to coach some of the new Python developers coming from other languages on their work. Which was awesome because we saw people's work evolve in a day from rank beginner material to competent Pythonista submissions. To think we had some part in helping people improve is one of the best things we got out of the sprint.
And the results?
The biggest thing, which we got into place on the second evening of the sprint, is that Django Packages is now an instance of Packaginator. Packaginator is a framework for launching package comparison sites for Python based tools. After a bit more work to happen this coming Sunday (4/10/2011), we'll be able to trivially deploy Python Packages, Pyramid Packages, Plone Packages, and Flask Packages - all of them able to support patches from Packaginator without causing the maintainers of those sites to hate our guts. We should also will have the hooks to support things like Vim Packages, Ubuntu Packages, Fedora Packages and more quite shortly.
Packaginator handles repos much better and now supports Bitbucket, Github, and Launchpad out of the box. SourceForge may happen very soon. Google Project Hosting, when Google implements Project Hosting API (cause we refuse to screen scrape pages for MetaData) will be handled shortly thereafter. Thanks to the work of the 'repo men' adding a new repo is now much easier, and we hope people submit new ones to handle things like Trac and other repo systems.
Our documentation went from passable to incredible, and our installation story is awesome. You want people to participate in your project? Then learn you some RestructuredText and Sphinx and host your documentation on Read the Docs. Read the Docs is awesome and I need to blog about why all Python docs should move there.
There was a huge amount of template cleanup - and the grid X-Y access can be rotated. We haven't turned on that feature yet, but you'll see it shortly.
Conclusion
The sprints were awesome. I learned a lot about running projects and managed to get into some new coding tricks (zip() comes to mind) into my brain. That this project is helping the open source world made it even better. And the best thing of all is I got to make over twenty new friends - all of whom worked with us towards a single common goal.
PyCon 2011 Contributors
PyCon 2011 was different in that this time I was going to co-lead a project, specifically Django Packages and the hopeful launch of Python Packages.
Note: The goal of Python Packages is not to replace PyPI, but rather serve as a resource to find, evaluate, and compare packages used in the every day life of a Python. In my opinion, PyPI should be dedicated to listing and serving packages - anything else (comments, ratings, documentation, etc) just adds complexity to the project and diffuses the focus of their team.
It all started with us being the second-to-last in line at the PyCon sprint announcements. At the microphone I forgot to mention a few things so I was worried that our attendance would suck. I tried to take it in good humor, but doubt worried at my gut. My co-lead, Audrey Roy, was confident that if no one showed, then we would have fun with just the two of us hacking away.
To our delight and surprise, turnout was good with about ten (10) people showing up. And thanks to lessons learned at DjangoCon 2010 and our tricks to getting more sprinters and helping sprinters deliver code, the number of participants kept growing. In the end we had twenty-four (24) new contributors to the project, which was simply amazing.
Test coverage had been mediocre on Django Packages, but after a show stopping bug got into production (someone changed a commonly used function to a property), we did a huge amount of work to not only increase test coverage but also refactor tests to be simpler and actually test rather than just increase coverage numbers. The improved quality and quantity of test coverage gave contributors the confidence to refactor and simplify some of the 'brilliant code' that I had written during the first month of the project.
We also got a bit draconian about accepting pull requests but documented how to get pull requests accepted. That might sound mean but if stopping one person's bug allowed ten (10) other people to maintain productivity then everyone is happier. Also, it allowed us to coach some of the new Python developers coming from other languages on their work. Which was awesome because we saw people's work evolve in a day from rank beginner material to competent Pythonista submissions. To think we had some part in helping people improve is one of the best things we got out of the sprint.
And the results?
The biggest thing, which we got into place on the second evening of the sprint, is that Django Packages is now an instance of Packaginator. Packaginator is a framework for launching package comparison sites for Python based tools. After a bit more work to happen this coming Sunday (4/10/2011), we'll be able to trivially deploy Python Packages, Pyramid Packages, Plone Packages, and Flask Packages - all of them able to support patches from Packaginator without causing the maintainers of those sites to hate our guts. We should also will have the hooks to support things like Vim Packages, Ubuntu Packages, Fedora Packages and more quite shortly.
Packaginator handles repos much better and now supports Bitbucket, Github, and Launchpad out of the box. SourceForge may happen very soon. Google Project Hosting, when Google implements Project Hosting API (cause we refuse to screen scrape pages for MetaData) will be handled shortly thereafter. Thanks to the work of the 'repo men' adding a new repo is now much easier, and we hope people submit new ones to handle things like Trac and other repo systems.
Our documentation went from passable to incredible, and our installation story is awesome. You want people to participate in your project? Then learn you some RestructuredText and Sphinx and host your documentation on Read the Docs. Read the Docs is awesome and I need to blog about why all Python docs should move there.
There was a huge amount of template cleanup - and the grid X-Y access can be rotated. We haven't turned on that feature yet, but you'll see it shortly.
Conclusion
The sprints were awesome. I learned a lot about running projects and managed to get into some new coding tricks (zip() comes to mind) into my brain. That this project is helping the open source world made it even better. And the best thing of all is I got to make over twenty new friends - all of whom worked with us towards a single common goal.
PyCon 2011 Contributors
- Aaron Kavlie
- Adam Saegebarth
- Alex Robbins
- Andrii Kurinny
- Audrey Roy
- Brian Ball
- Bryan Weingarten
- Chris Adams
- Daniel Greenfeld
- Eric Spunagle
- Evgeny Fadeev
- Flaviu Simihaian
- Gisle Aas (Repo Man)
- Jacob Burch
- James Pacileo
- Jeff Schenck
- Jim Allman
- John M. Camara
- Jonas Obrist
- jrothenbuhler
- Nate Aune
- Nolan Brubaker
- Preston Holmes
- Stuart Powers
- Szilveszter Farkas (Repo Man)
- Tom Brander
- Vasja Volin
Friday, April 1, 2011
Announcing Garbaginator!
While working on Packaginator at the PyCon 2011 sprints we discovered some serious issues in the way that Django handles garbage collection. After a huge amount of work, we managed to isolate and fix the problem. This 'fix', as it were, was only possible by doing a very sophisticated 'hack' of critical internal components of the Django Web Application framework. We also discovered that similar issues occurred in other existing Python application frameworks such as Pyramid, Flask, Web.py, Web2Py, Grok, Twisted, Tornado, Google App Engine, and Rails.
Since then the Packaginator community has been fiercely debating what we should do with our newly created set of hacks. After a lot of arguments going both ways we've decided to come up with our own application framework and release it to the world under the GPL license.
This brand new application framework ignores the lessons learned from all the other Python frameworks and embraces the cutting edge concept of Not-Invented-Here. It focuses less on features and enhancements over existing systems and much, much more on the critical concept of formal Garbage handling.
Some of the critical modules include:
Note: This was an April Fool's Day Joke
Since then the Packaginator community has been fiercely debating what we should do with our newly created set of hacks. After a lot of arguments going both ways we've decided to come up with our own application framework and release it to the world under the GPL license.
This brand new application framework ignores the lessons learned from all the other Python frameworks and embraces the cutting edge concept of Not-Invented-Here. It focuses less on features and enhancements over existing systems and much, much more on the critical concept of formal Garbage handling.
Some of the critical modules include:
- RubberGloves (for handling dirty objects)
- Django-Garbaginator
- Flask-Recycling
- Pyramid-Garbaginator
- Web.2.py Garbaginator Bridgerator ('cause people always get Web2Py and web.py confused with each other so we bridged them together)
- BlueBream
Check out the home page at: http://garbaginator.cartwheelweb.com
Fork Garbaginator on GitHub: https://github.com/cartwheelweb/garbaginatorNote: This was an April Fool's Day Joke
Thursday, March 24, 2011
PyCon 2011 Tutorial Report
As mentioned many times in previous entries of this blog, with Brian Rosner I taught the Pinax Solutions tutorial. We had some last minute people sign up so turnout meant nearly every seat in the room was taken. The second-half being a workshop seemed to go smashingly well. That said, one person had serious problems with getting things running and they left the tutorial without having anything running. I'm not sure how to deal with that besides having a spare laptop setup for that invariable bad laptop that always seems to show up.
The next day I took Noah Kantrowitz' (Re-)Introduction to C for Python developers. It was my first time every trying to code in C, and it was done by solving problems on this day. He dumped us right in the deep end, which was awesome for the first exercise but then I got a bit lost. I think he should have shown the answer code after everyone got a chance to try to solve things. He finished up the second half of things with some incredibly good content that made me want to use C a lot. I hope he gives this tutorial again next year since I think with a little fine tuning it will be a showcase class.
I kept my eye on a few tutorials, and was pleased to see that all the introductory Python classes were full. That is a good sign because more beginners means a stronger community.
The next day I took Noah Kantrowitz' (Re-)Introduction to C for Python developers. It was my first time every trying to code in C, and it was done by solving problems on this day. He dumped us right in the deep end, which was awesome for the first exercise but then I got a bit lost. I think he should have shown the answer code after everyone got a chance to try to solve things. He finished up the second half of things with some incredibly good content that made me want to use C a lot. I hope he gives this tutorial again next year since I think with a little fine tuning it will be a showcase class.
I kept my eye on a few tutorials, and was pleased to see that all the introductory Python classes were full. That is a good sign because more beginners means a stronger community.
I'll get you next time, Wesley Chun!
At the start of this month I laid out the Great Pycon Ribbon Game. PyCon ribbons are given to people based on their contribution to the conference. Give a tutorial, present a speech, volunteer to do grunt work, sponsor the event, be Guido van Rossum, and more each gives you a special colored ribbon you get to attach to your conference badge.
Last year I had the most of anyone except for Wesley Chun. He's one of my favorite instructors, is an author and Google App Engine advocate, and a good friend. To my five ribbons he had seven. He clearly beat me and deserved the win.
This year when I issued my ribbon challenge he immediately said that he was giving up. He had too much work and family things going on. I gave him my regrets and planned to totally crush everyone's ribbon count at the conference. I was sure I could duplicate my five ribbon effort from last year and no one else would be able to match me!
So imagine my surprise when Wesley Chun had seven, SEVEN ribbons on his badge. He beat me this year. Worse, I managed only four this year. So he didn't just beat me at the game, he opened the lead.
I'm a good loser. I don't begrudge him. Well, maybe not too much.
Next year I'll issue the challenge again. I hope you join us, since win or lose the wonderful thing about this competition is that PyCon and the community benefits.
Last year I had the most of anyone except for Wesley Chun. He's one of my favorite instructors, is an author and Google App Engine advocate, and a good friend. To my five ribbons he had seven. He clearly beat me and deserved the win.
This year when I issued my ribbon challenge he immediately said that he was giving up. He had too much work and family things going on. I gave him my regrets and planned to totally crush everyone's ribbon count at the conference. I was sure I could duplicate my five ribbon effort from last year and no one else would be able to match me!
So imagine my surprise when Wesley Chun had seven, SEVEN ribbons on his badge. He beat me this year. Worse, I managed only four this year. So he didn't just beat me at the game, he opened the lead.
I'm a good loser. I don't begrudge him. Well, maybe not too much.
Next year I'll issue the challenge again. I hope you join us, since win or lose the wonderful thing about this competition is that PyCon and the community benefits.
Tuesday, March 8, 2011
The Great PyCon Ribbon Game!
Here is my challenge for attendees of PyCon 2011 - try to win as many volunteer badge ribbons as possible. Whoever gets the most ribbons at PyCon 2011 can claim the title "King of PyCon Badge Ribbons" and I'll write a special blog post for you, your employer/company, and your favorite non-obscene thing.
Rules:
Rules:
- You have to earn the badge ribbons. You have to give tutorials, make presentations, volunteer left and right, and be a great sport. Stealing ribbons is out. So is trading for them.
- Only real badge ribbons are valid. You can't write your own and tape them onto your badge.
- You must proudly affix the ribbons to your badge.
- Cheaters will be lambasted verbally. You deserve what you get.
Friday, February 25, 2011
My tips for speaking
I've been presenting on the job since 1999. I've been presenting at conferences since autumn of 2008. I've got some tricks I've picked up over the years. I'll be using these tricks (and more) at PyCon, so you'll be able to see and judge them in action.
Black text on white background
Remember the old days of Geocities when people had purple backgrounds with yellow text? Or dark green backgrounds with white text? Or crazy fonts? We make fun of that sort of thing now. Unfortunately, I've seen presentations done that way in the recent past and so have you.
Yup, background colors that look great on a laptop or monitor screen often lose something in the transition to a projector. You can't predict what the venue will give you in regards to quality/brand of projector, so why take unnecessary risks?
So I stick with the classic of what people have been doing forever. I choose the lightest possible background, the darkest colored text, and I use the default font of the slide software. Maybe its not fancy or artistic, but my message isn't obfuscated by forcing people to squint to see slides reinforcing what I'm saying.
Fear the command line!
The sucky thing about giving a tutorial is that you have to touch the command-line. And something invariably goes wrong. If you do have to use the command-line remember the following tips:
Listening to someone read the content off a slide is dull. I try to say anything BUT what is on the slide. When I do it speak the content of a slide exactly its because I'm purposefully breaking my pattern to make a point. Or to be silly because I'm getting tense.
What you should be doing is using the slides to remind yourself of your next point. Think of them as notes for your speech, not the speech itself
Bullets are dangerous
Bullets are live ammunition. Even in small quantities they can kill a talk. They can put an audience to sleep, cause them to start checking twitter, or even leave. So I use bullets very sparingly in presentations (classes can be different) because of their potency. Because of their inherent silliness I tend to use bullets in self-deprecating humor.
A better tactic than bullets is to create a subject header on a number of slides and put a single bullet under that subject header. So instead of one (1) slide about 'Python' with bullets of 'Monty', 'Guido', and 'Spam', I like to have three (3) slides each with a header of 'Python' and the content simply being 'Monty', 'Guido', and 'Spam'.
Sixty seconds per slide
If you wait too long your slide will become boring to the audience and their brains will drift. This ties right into the problem with bullets. Keep things moving along.
Be rested, fed, and sober for your talk
Skip the late night party and get a good night's rest. The day of the talk eat food that makes you feel physically better.
In January I went to a talk where the speaker was presenting on a technical matter with beer in hand. Maybe he thought it was hip, but his talk sucked. He got out of sync with his slides and stumbled around his own thoughts. Not only was the talk of poor quality but it was disrespectful of the speaker.
Needless to say, the audience was very grumbly about the 45 minutes they wasted.
That was a terrible shame because his slides were pretty good. I bet if he had been sober that talk would have rocked.
If people ask questions during the talk, ask them to wait until the end
They'll break your pace, rhythm, and timing. If they can't wait until the end then they now fall under my definition of heckler and are not worth answering anyway.
Be nice to people who come up to you after a talk
You never know who is that new person who comes up to you. Maybe they are planning to blog about you or write about you in the press. Maybe they are a possible business or job lead. Maybe they are someone who wants to throw a gajillion dollars at you. Be nice to them and you'll find out. Try to find time to talk to everyone, even if for just a minute each.
Black text on white background
Remember the old days of Geocities when people had purple backgrounds with yellow text? Or dark green backgrounds with white text? Or crazy fonts? We make fun of that sort of thing now. Unfortunately, I've seen presentations done that way in the recent past and so have you.
Yup, background colors that look great on a laptop or monitor screen often lose something in the transition to a projector. You can't predict what the venue will give you in regards to quality/brand of projector, so why take unnecessary risks?
So I stick with the classic of what people have been doing forever. I choose the lightest possible background, the darkest colored text, and I use the default font of the slide software. Maybe its not fancy or artistic, but my message isn't obfuscated by forcing people to squint to see slides reinforcing what I'm saying.
Fear the command line!
The sucky thing about giving a tutorial is that you have to touch the command-line. And something invariably goes wrong. If you do have to use the command-line remember the following tips:
- White background and black text and increase the size of the text. I don't care if you prefer to code with a black background with tiny green letters - your audience simply won't be able to follow you as easily. Since I heard a Walt Disney Animation Studios technical lead have the same opinion, I now feel empowered enough to complain after any talk featuring an unreadable shell.
- Try to fake the command-line. I've heard player piano is a great tool for doing that and will save you from that minute of silence when you try to figure out what you did wrong.
Listening to someone read the content off a slide is dull. I try to say anything BUT what is on the slide. When I do it speak the content of a slide exactly its because I'm purposefully breaking my pattern to make a point. Or to be silly because I'm getting tense.
What you should be doing is using the slides to remind yourself of your next point. Think of them as notes for your speech, not the speech itself
Bullets are dangerous
Bullets are live ammunition. Even in small quantities they can kill a talk. They can put an audience to sleep, cause them to start checking twitter, or even leave. So I use bullets very sparingly in presentations (classes can be different) because of their potency. Because of their inherent silliness I tend to use bullets in self-deprecating humor.
A better tactic than bullets is to create a subject header on a number of slides and put a single bullet under that subject header. So instead of one (1) slide about 'Python' with bullets of 'Monty', 'Guido', and 'Spam', I like to have three (3) slides each with a header of 'Python' and the content simply being 'Monty', 'Guido', and 'Spam'.
Sixty seconds per slide
If you wait too long your slide will become boring to the audience and their brains will drift. This ties right into the problem with bullets. Keep things moving along.
Be rested, fed, and sober for your talk
Skip the late night party and get a good night's rest. The day of the talk eat food that makes you feel physically better.
In January I went to a talk where the speaker was presenting on a technical matter with beer in hand. Maybe he thought it was hip, but his talk sucked. He got out of sync with his slides and stumbled around his own thoughts. Not only was the talk of poor quality but it was disrespectful of the speaker.
Needless to say, the audience was very grumbly about the 45 minutes they wasted.
That was a terrible shame because his slides were pretty good. I bet if he had been sober that talk would have rocked.
If people ask questions during the talk, ask them to wait until the end
They'll break your pace, rhythm, and timing. If they can't wait until the end then they now fall under my definition of heckler and are not worth answering anyway.
Be nice to people who come up to you after a talk
You never know who is that new person who comes up to you. Maybe they are planning to blog about you or write about you in the press. Maybe they are a possible business or job lead. Maybe they are someone who wants to throw a gajillion dollars at you. Be nice to them and you'll find out. Try to find time to talk to everyone, even if for just a minute each.
Subscribe to:
Posts (Atom)
