From now on I'll be blogging from http://pydanny.com.
See you there!
Showing posts with label django. Show all posts
Showing posts with label django. Show all posts
Sunday, February 19, 2012
Wednesday, February 15, 2012
Silicon Beach Hackercast
Near the end of January of 2012 I was at the 10th Southern California Linux Exposition (SCALE 10X). I gave an Intro to Python talk, helped man the awesome Python booth, and hung out with a lot of awesome people. One of those awesome people I got to spend time with was Andrew Cholakian, a Ruby and Clojure developer, and the organizer of LA Hacker News. We've been meaning to do something together, and at the conference we decided to do a broadcast together.
Jump forward a few weeks and Andrew came over to our place in the San Fernando Valley for a day of brainstorming, web site building, and broadcasting. We outlined a show and started to record.
Download Now!
The show was a lot of fun to do. We plan to do more of them, perhaps every few weeks. A better microphone is definitely in the works.
Jump forward a few weeks and Andrew came over to our place in the San Fernando Valley for a day of brainstorming, web site building, and broadcasting. We outlined a show and started to record.
Download Now!
Topics of Discussion
- Python at Scale 10X
- New clients asking you to complete the ‘last 10%’
- A rant about job titles
- Why is clojure blowing up?
Links
Art
Audrey was kind enough to illustrate the event for posterity:The Future
The show was a lot of fun to do. We plan to do more of them, perhaps every few weeks. A better microphone is definitely in the works.
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!
Wednesday, January 18, 2012
My SOPA boycott
I'm against SOPA and PIPA.
I believe that those bills will kill not just free speech, but also business within the USA. Innovation will wither. I'm also of the belief that those companies trying to get SOPA into place don't realize that no idea is new and if SOPA passes they'll be hammered with an increasing amount of takedowns and suits against them for anything they do. Litigation based on SOPA won't be as easily handled as the current status quo.
I've signed the petitions, I've posted on Twitter, Facebook, and Google. That isn't enough. I have to be willing to make a sacrifice. And in this case I'm going to make the sacrifice my vote.
My vote sacrifice is a boycott. It's directed at any politician, local or otherwise:
I believe that those bills will kill not just free speech, but also business within the USA. Innovation will wither. I'm also of the belief that those companies trying to get SOPA into place don't realize that no idea is new and if SOPA passes they'll be hammered with an increasing amount of takedowns and suits against them for anything they do. Litigation based on SOPA won't be as easily handled as the current status quo.
I've signed the petitions, I've posted on Twitter, Facebook, and Google. That isn't enough. I have to be willing to make a sacrifice. And in this case I'm going to make the sacrifice my vote.
My vote sacrifice is a boycott. It's directed at any politician, local or otherwise:
My Boycott:
- If you as a politician vote for SOPA/PIPA then you lose my vote. Regardless of whatever other opinions you have or party you belong to, you've lost me as a supporter.
- If SOPA/PIPA passes you can get my vote back by voting for what bill that destroys SOPA/PIPA is nominated.
- If SOPA/PIPA fails you can get my vote back by voting against whatever bills are resurrected to replace SOPA/PIPA.
- I will ignore party boundaries. I will vote against my normal grain simply to get you removed from office.
Why?
Like campaign finance reform, controls of freedom of speech often have unpredictable repercussions.
The terrible thing about these bills is that their supporters are bi-partisan. While it's wonderful to see political opponents working together, in this case, it's for a terrible cause.
So I'm going to cross political boundaries too. I'm going to say that as a registered Democrat I'm going to vote Republican if a Democrat candidate at any level votes for SOPA/PIP.
About Me
I don't use pirated software. I don't read, watch, or listen to pirated content. I purchase everything legally or use open source equivalents. I make a pretty decent salary and am pretty much in the direct center of what is called the 'middle-class'.
I'm also pro-business and a rather patriotic citizen of the United States. I believe in our nation and what it represents, and I know these bills are going to be a dagger in the heart of what our founding fathers gave us.
I'm also pro-business and a rather patriotic citizen of the United States. I believe in our nation and what it represents, and I know these bills are going to be a dagger in the heart of what our founding fathers gave us.
Finally, as I said, I'm a Democrat willing to vote Republican, Green, Libertarian, or whatever to make my point. That's my sacrifice. My vote and role in this nation that took my family in over 100 years ago is now in the hands of politicians.
What's yours?
What's yours?
Thursday, December 22, 2011
New Year’s Python Meme
I love these blog memes, so I give you my version of Tarek Ziade's New Year's Python Meme.
For python libraries, that would have to be Kenneth Reitz' python-requests library. I've used it for an amazing amount of stuff and blogged about it. It took the grunge out of doing HTTP actions with Python. The API is clean and elegant, getting out of your way. It embodies the State of the art for API design, which closely matches the Zen of Python.
For applications, djangolint.com is awesome. It has helped me out so much on several projects. I would love to see something like this implemented and maintained for modern Python.
All the Python friendly PaaS efforts that have emerged are changing the landscape for those of us who want to launch projects but don't want to become full time system administrators in the process. Heroku, DjangoZoom, DotCloud, ep.io, gondor.io, and others are making it possible for developers to focus on development not server tooling. Google App Engine paved the way and it is wonderful to see the rest of the universe catch up with material that more closely follow core.
Event based programming! I've touched on it for years, but this year I really got a lot more more into it thanks to Aurynn Shaw kickstarting me and Audrey Roy expanding my knowledge ever since.
I participated mostly as co-lead in the Open Comparison project, which amongst other things involved running the largest sprint at PyCon 2011. We maintained Django Packages and launched Pyramid and Plone versions of the project. We hope to launch a Python implementation in 2012.
I took a lot of notes this year at pydanny-event-notes - enough to make a book.
Like Nick Coghlan, that would be http://planet.python.org.
A tool python-requests, but for shell access. Something like Unipath, but kept up-to-date and with nicely written documentation on Read the Docs.
A PIL replacement that is maintained, works for all modern Pythons, and is close enough to the PIL API to not cause too much confusion.
Something like Django Lint but for Python 2.7.x/3.x.
An open source project that tracks test coverages across PyPI and publishes reports of the results via an API.
1. What’s the coolest Python application, framework or library you have discovered in 2011?
For python libraries, that would have to be Kenneth Reitz' python-requests library. I've used it for an amazing amount of stuff and blogged about it. It took the grunge out of doing HTTP actions with Python. The API is clean and elegant, getting out of your way. It embodies the State of the art for API design, which closely matches the Zen of Python.
For applications, djangolint.com is awesome. It has helped me out so much on several projects. I would love to see something like this implemented and maintained for modern Python.
All the Python friendly PaaS efforts that have emerged are changing the landscape for those of us who want to launch projects but don't want to become full time system administrators in the process. Heroku, DjangoZoom, DotCloud, ep.io, gondor.io, and others are making it possible for developers to focus on development not server tooling. Google App Engine paved the way and it is wonderful to see the rest of the universe catch up with material that more closely follow core.
2. What new programming technique did you learn in 2011?
Event based programming! I've touched on it for years, but this year I really got a lot more more into it thanks to Aurynn Shaw kickstarting me and Audrey Roy expanding my knowledge ever since.
3. What’s the name of the open source project you contributed the most in 2011? What did you do?
I participated mostly as co-lead in the Open Comparison project, which amongst other things involved running the largest sprint at PyCon 2011. We maintained Django Packages and launched Pyramid and Plone versions of the project. We hope to launch a Python implementation in 2012.
I took a lot of notes this year at pydanny-event-notes - enough to make a book.
4. What was the Python blog or website you read the most in 2011?
Like Nick Coghlan, that would be http://planet.python.org.
5. What are the three top things you want to learn in 2012?
- How to use whatever consistently maintained project that replaces PIL that works in Python 2.7.x and Python 3.x.
- Really advanced Python as taught by Raymond Hettiger.
- backbone.js
6. What are the top software, app or lib you wish someone would write in 2012?
A tool python-requests, but for shell access. Something like Unipath, but kept up-to-date and with nicely written documentation on Read the Docs.
A PIL replacement that is maintained, works for all modern Pythons, and is close enough to the PIL API to not cause too much confusion.
Something like Django Lint but for Python 2.7.x/3.x.
An open source project that tracks test coverages across PyPI and publishes reports of the results via an API.
Want to do your own list? here’s how:
- copy-paste the questions and answer to them in your blog
- tweet it with the #2012pythonmeme hashtag
Labels:
classes,
courses,
django,
django packages,
opencomparison,
plone,
pyramid,
python
Friday, December 16, 2011
Announcing Consumer Notebook!
Need a Python programming language book? Want to see a comparison of the ones I own and use? Check out my Must-Have Python Programming Books comparison grid.
Let's drill down and take a closer look at one of the items on the page, in this case Doug Hellmann's amazing The Python Standard Library by Example. The product detail pages include the ability to add pros and cons and attach said products to comparison grids and specialized lists like 'my wishlist' and 'my possessions'.
Speaking of wishlists, check out my own:
In order to add items, like footy pajamas, I click on the 'add' button and paste the Amazon (or BestBuy) URL into the form:
At this time we just handle Amazon USA and BestBuy USA. In the future we plan on adding more affiliate providers, including non-USA providers to support our non-USA friends.
It was the summer of 2010 and we were brainstorming ideas for a coding contest called Django Dash. The one we settled on was a listing and comparison site for Django called Django Packages. The result has been a very useful tool for the Django community. Eventually, with the help of several dozen people, we turned the code into the Open Comparison framework and launched Pyramid and Plone implementations. Time permitting this year, we plan to do Python, Flask, Twisted, Node, JQuery, and other implementations.
Since then we've wanted to do something similar, but in the context of products. And we wanted to do it right - elegant design combined with an ad-free space. So we cooked up Consumer Notebook, launching today!
We'll be adding features and enhancements in the months to come. We've acquired a community manager, and even have a blog. We would love for you to check out the site, share it with your friends and family, and send us your commentary, suggestions, and advice.
Let's drill down and take a closer look at one of the items on the page, in this case Doug Hellmann's amazing The Python Standard Library by Example. The product detail pages include the ability to add pros and cons and attach said products to comparison grids and specialized lists like 'my wishlist' and 'my possessions'.
Speaking of wishlists, check out my own:
In order to add items, like footy pajamas, I click on the 'add' button and paste the Amazon (or BestBuy) URL into the form:
At this time we just handle Amazon USA and BestBuy USA. In the future we plan on adding more affiliate providers, including non-USA providers to support our non-USA friends.
There's a lot more than that...
In addition to weekly infographics, comparison grids, lists, and products, Consumer Notebook also awards points, coins, badges, and a growing privilege set to participating users. We even implemented an energy bar which regenerates over time, designed to match the pace of human users and serve as one of the brakes on scripts and bots.Technology
I built this with Audrey Roy using Python, Django, JQuery, PostGreSQL, Memcached, and RabbitMQ. I'll be blogging in depth about the technical side in an upcoming post.Genesis
It was the summer of 2010 and we were brainstorming ideas for a coding contest called Django Dash. The one we settled on was a listing and comparison site for Django called Django Packages. The result has been a very useful tool for the Django community. Eventually, with the help of several dozen people, we turned the code into the Open Comparison framework and launched Pyramid and Plone implementations. Time permitting this year, we plan to do Python, Flask, Twisted, Node, JQuery, and other implementations.
Since then we've wanted to do something similar, but in the context of products. And we wanted to do it right - elegant design combined with an ad-free space. So we cooked up Consumer Notebook, launching today!
We'll be adding features and enhancements in the months to come. We've acquired a community manager, and even have a blog. We would love for you to check out the site, share it with your friends and family, and send us your commentary, suggestions, and advice.
Labels:
consumernotebook,
django,
djangodash,
opencomparison,
python
Friday, December 9, 2011
My BaseModel
When I build projects in Django I like to have a 'core' app with all my common bits in it, including a BaseModel. In that BaseModel I'll define the most basic fields possible, in this case a simple pair of created/modified fields built using custom django-extension fields.
You'll notice I also have core.fields defined. That is because (unless things have changed), django-extensions doesn't work with South out of the box. Hence the file below where I extend those fields to play nicely with my migration tool of choice.
Unfortunately, this all shows up as red marks when I run coverage.py reports. To deal with that I added in some tests. However, I'll readily I'm not super pleased with the tests below, but they are better then nothing, right?
I'll reiterate that I'm not happy with the tests. I'm open to suggestions.
I pretty much got the BaseModel from Frank Wiles of RevSys back in the summer of 2010. What I added was sticking all the common bits into the core app, getting the South migration to play more nicely, and adding tests.
Jannis and John both pointed out that django_extensions now has a TimeStampedModel that does what my BaseModel does. They also pointed out that django_extensions comes with built-in South migrations for it's CreationDateTimeField and ModificationDateTimeField fields.
Which means thanks we can safely just do this and not worry about migrations:
# core/models.py from django.db import models from django.utils.translation import ugettext_lazy as _ from core.fields import CreationDateTimeField, ModificationDateTimeField class BaseModel(models.Model): """ Base abstract base class to give creation and modified times """ created = CreationDateTimeField(_('created')) modified = ModificationDateTimeField(_('modified')) class Meta: abstract = True
You'll notice I also have core.fields defined. That is because (unless things have changed), django-extensions doesn't work with South out of the box. Hence the file below where I extend those fields to play nicely with my migration tool of choice.
# core/fields.py from django_extensions.db.fields import CreationDateTimeField, ModificationDateTimeField class CreationDateTimeField(CreationDateTimeField): def south_field_triple(self): "Returns a suitable description of this field for South." # We'll just introspect ourselves, since we inherit. from south.modelsinspector import introspector field_class = "django.db.models.fields.DateTimeField" args, kwargs = introspector(self) return (field_class, args, kwargs) class ModificationDateTimeField(ModificationDateTimeField): def south_field_triple(self): "Returns a suitable description of this field for South." # We'll just introspect ourselves, since we inherit. from south.modelsinspector import introspector field_class = "django.db.models.fields.DateTimeField" args, kwargs = introspector(self) return (field_class, args, kwargs)
Unfortunately, this all shows up as red marks when I run coverage.py reports. To deal with that I added in some tests. However, I'll readily I'm not super pleased with the tests below, but they are better then nothing, right?
# core/tests/test_fields.py from django.test import TestCase from core.fields import CreationDateTimeField, ModificationDateTimeField class TestFields(TestCase): def test_create_override(self): field = CreationDateTimeField() triple = field.south_field_triple() self.assertEquals(triple[0], 'django.db.models.fields.DateTimeField') self.assertEquals(triple[1], list()) self.assertEquals(triple[2], {'default': 'datetime.datetime.now', 'blank': 'True'}) def test_modify_override(self): field = ModificationDateTimeField() triple = field.south_field_triple() self.assertEquals(triple[0], 'django.db.models.fields.DateTimeField') self.assertEquals(triple[1], list()) self.assertEquals(triple[2], {'default': 'datetime.datetime.now', 'blank': 'True'})
Closing Thoughts
My pattern is also If I need more stuff in this BaseModel I extend it with another abstract class instead of changing it. That way I can be sure at least this part works really well and any additions are isolated in another class.I'll reiterate that I'm not happy with the tests. I'm open to suggestions.
I pretty much got the BaseModel from Frank Wiles of RevSys back in the summer of 2010. What I added was sticking all the common bits into the core app, getting the South migration to play more nicely, and adding tests.
But much of this is moot!
Note: I added this segment several days after my original posting because of the stuff in the comments. Thanks Jannis Leidel and someone named John - this is part of why I post.Jannis and John both pointed out that django_extensions now has a TimeStampedModel that does what my BaseModel does. They also pointed out that django_extensions comes with built-in South migrations for it's CreationDateTimeField and ModificationDateTimeField fields.
Which means thanks we can safely just do this and not worry about migrations:
# core/models.py from django.db import models from django.utils.translation import ugettext_lazy as _ from django_extensions.db.fields import CreationDateTimeField, ModificationDateTimeField class BaseModel(models.Model): """ Base abstract base class to give creation and modified times """ created = CreationDateTimeField(_('created')) modified = ModificationDateTimeField(_('modified')) class Meta: abstract = True
Wednesday, December 7, 2011
Made Up Statistics
At DjangoCon my good friend Miguel Araujo and I presented on Advanced Django Form Usage. Slide 18 of that talk mentioned some made up statistics. Here they are for reference:
With that out of the way, I'm going to make a bar graph out of my fictional data:
You'll notice that my bar titles could be stronger. I actually did that on purpose in case anyone tries to use that chart in real life. In any case, if you thought that was interesting, then read on. I have many more made-up statistics. For example, here are more numbers I've cooked up:
DevOps is the new hotness. I know because every other Python meetup features someone speaking on it - just like every other Ruby, Perl, and PHP meetup. Anyway... numbers:
Following the obvious logic flow (to me anyway) of DevOps to something else, let's go into Python environments, also known as the VirtualEnv vs Buildout debate, which adds up to an even 100% (making it good pie chart material):
The made up statistics in this post frequently touch on contentious topics. So let me add another controversial topic, this time the never ending template debate in Python:
I sometimes get asked how to best optimize a Django site. My answer is 'cache and then cache some more' but there are those who disagree with me and start switching out Django internals before doing anything silly like looking at I/O. My bet is this same thing happens with other frameworks such as Pyramid.
Of all the made up statistics in this blog post, I suspect this is the one closest to the truth of things.
Update: Alex Gaynor and Audrey Roy pointed out that the original line graph for this data was not appropriate. My weak defense was that I'm trying not to make things too serious but they stated that the line graph was so inappropriate it distracted from the rest of the post. Thanks for the advice!
Alright, let's conclude this article with some statistics I cooked up about frameworks in Python. I'm going to do more then just mention web frameworks, dabbling into other awesome things that the Python community has given us.
- 91% of Django projects use ModelForms.
- 80% ModelForms require trivial logic.
- 20% ModelForms require complex logic.
With that out of the way, I'm going to make a bar graph out of my fictional data:
You'll notice that my bar titles could be stronger. I actually did that on purpose in case anyone tries to use that chart in real life. In any case, if you thought that was interesting, then read on. I have many more made-up statistics. For example, here are more numbers I've cooked up:
Pydanny Made Up DevOps Statistics
DevOps is the new hotness. I know because every other Python meetup features someone speaking on it - just like every other Ruby, Perl, and PHP meetup. Anyway... numbers:
- 24.3% Python developers doing DevOps think they could have launched a PaaS (aka Heroku clone) before it got crowded.
- 46.3% Python developers doing DevOps spend all their time writing Chef/Puppet scripts and yet still claim to be Python developers.
- 14% Python developers are worried about so much of the backend being done in Ruby.
- 54% Python developers are just happy that there are many options now and don't care about the internal machinery that much.
This time, because I'm worried about the data being taken seriously, I've titled the bar chart in such a way that no one will reference it in anything important:
Pydanny Made Up Python Enviroment Statistics
Following the obvious logic flow (to me anyway) of DevOps to something else, let's go into Python environments, also known as the VirtualEnv vs Buildout debate, which adds up to an even 100% (making it good pie chart material):
- 77% of Python Developers prefer VirtualEnv.
- 13% of Python Developers prefer Buildout.
- 7% of Python developers rolled their own solution and wish they could switch over.
- 3% of Python developers rolled their own solution and are fiendishly delighted with how they have guaranteed their own job security forever. I know who some of you are and I can say with some confidence that when the Zombie apocalypse happens, no one is going to invite you into their fortified compounds. We hate you that much.
Pydanny Made Up Template Debate Statistics
The made up statistics in this post frequently touch on contentious topics. So let me add another controversial topic, this time the never ending template debate in Python:
- 70% python developers prefer non-XML templates
- 25% python developers prefer XML templates
- 5% python developers wonder why we don't just use the str.format() method and be done with it
- 50% python developers strongly disagree with my Stupid Template Languages blog post from last year.
Pydanny Made Up Python Web Optimization Statistics
I sometimes get asked how to best optimize a Django site. My answer is 'cache and then cache some more' but there are those who disagree with me and start switching out Django internals before doing anything silly like looking at I/O. My bet is this same thing happens with other frameworks such as Pyramid.
- 20% developers argue switching template languages.
- 80% developers argue using caching and load balancing.
- 100% Django/Pyramid/Flask/etc core developers argue using caching and load balancing.
Of all the made up statistics in this blog post, I suspect this is the one closest to the truth of things.
Update: Alex Gaynor and Audrey Roy pointed out that the original line graph for this data was not appropriate. My weak defense was that I'm trying not to make things too serious but they stated that the line graph was so inappropriate it distracted from the rest of the post. Thanks for the advice!
Pydanny Made Up Framework Debate Statistics
Alright, let's conclude this article with some statistics I cooked up about frameworks in Python. I'm going to do more then just mention web frameworks, dabbling into other awesome things that the Python community has given us.
- 23.6% of us get web.py and web2py confused with each other.
- 42% Python developers think Pyramid/Flask have awesome names that don't get mispronounced the same way Django does.
- 28% Python developers wish they could find a way to get some SciPy into their projects.
- 22% Python developers wish there was a PEP-8 wrapper for Twisted.
- 49% Twisted developers wish that Python had accepted their standard instead of PEP-8.
- 90% Python developers wonder what they were drinking when they renamed it to BlueBreem and wonder if it is sold over the counter in their municipality.
No chart? Getting this one to look meaningful was turning into a herculean effort. I invite others to render this data into something that look attractive and doesn't lose meaning. Come up with something impressive and I'll put it into a follow-up blog post.
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?
Sunday, October 9, 2011
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.
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.
Friday, September 23, 2011
Profiles: Breaking Normalization
In the summer of 2010 I either saw this pattern or cooked it up myself. It is specific to the Django profiles system and helps me get around some of the limitations/features of django.contrib.auth. I like to do it on my own projects because it makes so many things (like performance) so much simpler. The idea is to replicate some of the fields and methods on the django.contrib.auth.model.User model in your user profile(s) objects. I tend to do this usually on the email , first_name , last_name fields and the get_full_name method. Sometimes I also do it on the username field, but then I also ensure that the username duplication is un-editable in any context.
Sure, this breaks normalization, but the scale of this break is tiny. Duplicating four fields each with a max of 30 characters for a total of 120 characters per record is nothing in terms of data when you compare to avoiding the mess of doing lots of profile-to-user joins on very large data sets.
One more thing, I've found that most users don't care about or for the division between their accounts and profiles. They are more than happy with a single form, and if they aren't, well you can still use this profile model to build both account and profile forms.
Alright, enough talking, let me show you how my Profile models tend to look:
All of this is good, but you have to be careful with emails. Django doesn't let you duplicate existing emails in the django.contrib.auth.model.User model so we want to catch that early and display an elegant error message. Hence this Profile form:
Sure, this breaks normalization, but the scale of this break is tiny. Duplicating four fields each with a max of 30 characters for a total of 120 characters per record is nothing in terms of data when you compare to avoiding the mess of doing lots of profile-to-user joins on very large data sets.
One more thing, I've found that most users don't care about or for the division between their accounts and profiles. They are more than happy with a single form, and if they aren't, well you can still use this profile model to build both account and profile forms.
Alright, enough talking, let me show you how my Profile models tend to look:
from django.contrib.auth.models import User from django.db import models from django.utils.translation import ugettext_lazy as _ class Profile(models.Model): """ Normalization breaking profile model authored by Daniel Greenfeld """ user = models.OneToOneField(User) email = models.EmailField(_("Email"), help_text=_("Never given out!"), max_length=30) first_name = models.CharField(_("First Name"), max_length=30) last_name = models.CharField(_("Last Name"), max_length=30) # username field notes: # used to improve speed, not editable! # Never changed after original auth.User and profiles.Profile creation! username = models.CharField(_("User Name"), editable=False) def save(self, **kwargs): """ Override save to always populate changes to auth.user model """ user_obj = User.objects.get(username=self.user.username) user_obj.first_name = self.first_name user_obj.last_name = self.last_name user_obj.email = self.email user_obj.is_active = self.is_active user_obj.save() super(Profile,self).save(**kwargs) def get_full_name(self): """ Convenience duplication of the auth.User method """ return "{0} {1}".format(self.first_name, self.last_name) @models.permalink def get_absolute_url(self): return ("profile_detail", (), {"username": self.username}) def __unicode__(self): return self.username
All of this is good, but you have to be careful with emails. Django doesn't let you duplicate existing emails in the django.contrib.auth.model.User model so we want to catch that early and display an elegant error message. Hence this Profile form:
from django import forms from django.contrib.auth.models import User from django.utils.translation import ugettext_lazy as _ from profiles.models import Profile class ProfileForm(forms.ModelForm): """ Email validation form authored by Daniel Greenfeld """ def clean_email(self): """ Custom email clean method to make sure the user doesn't use the same email as someone else""" email = self.cleaned_data.get("email", "").strip() if User.objects.filter(email=email).exclude(username=self.instance.user.username): self._errors["email"] = self.error_class(["%s is already in use in the system" % email]) return "" return email class Meta: fields = ( 'first_name', 'last_name', 'email', ) model = Profile
Tuesday, September 13, 2011
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.
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.
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.
Labels:
australia,
classes,
courses,
django,
django packages,
djangocon,
NewZealand,
pyladies,
python,
training
Sunday, July 31, 2011
The Ultimate Django Tutorial Workshop
That is a big statement to make as a title of a class/workshop blog post. However, in this case I believe I'm fully justified because this is going to be awesome. Here's why:
1. The teachers are beyond incredible
In the course description it says I'm the teacher and I have lab assistants. In retrospect, what I should have said is, "Daniel Greenfeld is organizing a workshop taught by the people he respects and admires".
Think I'm kidding? Look at just some of the names of people I've got lined up to participate:
2. The teacher to student ratio is going to be really small
This is not going to be a room with a few instructors and umpteen students in it. If the class size gets big, I'm going to bring in more teachers. I'll cajole, plead, and do whatever I must to get them in the room. I don't want anyone left behind!
I want a ratio of 5 students to each teacher.
3. Class implemented with a lot of lessons learned
I've taught a bunch. So have a number of the instructors I've lined up. We know which parts of the tutorial are important to focus on, and which parts should be visited by students later on their own. This means you learn the critically important parts that get you kick-started as a Django developer.
One thing we'll try to squeeze in is deployment to one of the new Django hosts such as Djangozoom.com, Gondor.io, and ep.io. In fact, Shimon Rura, one of the co-founders of Djangozoom, participating as an instructor.
4. We're all volunteers
All the proceeds earned by the instructors for this course will be going to the Pyladies Sponsorship program. That is important for two reasons:
Officially the tutorial ends at 12:30PM and we should be done. Sometimes though we stumble on things and we don't finish with the rest of the class (like me in my last C programming class). But after a lunch break I'm planning on grabbing some space and working through the rest of the tutorial with anyone who didn't complete the class.
6. The tutorial opens DjangoCon
The tutorial starts on Monday, September 5, 2011 at 9:30 AM at the Hilton Portland and Executive Tower at 921 SW Sixth Avenue in Portland, Oregon, USA. If you do plan on attending DjangoCon and are new to the framework, what a great way to get started!
7. You don't have to attend DjangoCon itself to take the tutorial
Tickets for the event are being sold separately from the conference. So if you can't take off more than one day of school or work, this is a great way to capitalize on DjangoCon.
Convinced? Here is what you need to know and do to get signed up:
1. The teachers are beyond incredible
In the course description it says I'm the teacher and I have lab assistants. In retrospect, what I should have said is, "Daniel Greenfeld is organizing a workshop taught by the people he respects and admires".
Think I'm kidding? Look at just some of the names of people I've got lined up to participate:
- Jacob Kaplan-Moss, Benevolent Dictator For Life of Django
- Russell Keith-Magee, President of the Django Software Foundation
- Audrey Roy
- Jacob Burch
- Katharine Jarmul
- Corey Bertram
- Sandy Strong
- Jonas Obrist
- Christine Cheung
- Shimon Rura
2. The teacher to student ratio is going to be really small
This is not going to be a room with a few instructors and umpteen students in it. If the class size gets big, I'm going to bring in more teachers. I'll cajole, plead, and do whatever I must to get them in the room. I don't want anyone left behind!
I want a ratio of 5 students to each teacher.
3. Class implemented with a lot of lessons learned
I've taught a bunch. So have a number of the instructors I've lined up. We know which parts of the tutorial are important to focus on, and which parts should be visited by students later on their own. This means you learn the critically important parts that get you kick-started as a Django developer.
One thing we'll try to squeeze in is deployment to one of the new Django hosts such as Djangozoom.com, Gondor.io, and ep.io. In fact, Shimon Rura, one of the co-founders of Djangozoom, participating as an instructor.
4. We're all volunteers
All the proceeds earned by the instructors for this course will be going to the Pyladies Sponsorship program. That is important for two reasons:
- Your attendance will help Pyladies sponsor more women to learn Python in the future.
- The teachers are doing this because they want to do it. They want you to learn Django.
Officially the tutorial ends at 12:30PM and we should be done. Sometimes though we stumble on things and we don't finish with the rest of the class (like me in my last C programming class). But after a lunch break I'm planning on grabbing some space and working through the rest of the tutorial with anyone who didn't complete the class.
6. The tutorial opens DjangoCon
The tutorial starts on Monday, September 5, 2011 at 9:30 AM at the Hilton Portland and Executive Tower at 921 SW Sixth Avenue in Portland, Oregon, USA. If you do plan on attending DjangoCon and are new to the framework, what a great way to get started!
7. You don't have to attend DjangoCon itself to take the tutorial
Tickets for the event are being sold separately from the conference. So if you can't take off more than one day of school or work, this is a great way to capitalize on DjangoCon.
Convinced? Here is what you need to know and do to get signed up:
- Get a laptop running Windows 7, Mac OS X 10.5 or higher, or Ubuntu.
- If there is no Python installed, install Python 2.7.1. DO NOT INSTALL PYTHON 3!!!
- Make sure you have a grounding in Python. If you are new to Python you need to have finished at least half the chapters in learnpythonthehardway.org before you attend. If you come to this event with no prior Python experience you will be left behind.
- Buy a ticket!
Sunday, July 17, 2011
Python and Django class/hackathon!
The Los Angeles Python community (LA Django and LA PyLadies) is meeting in Santa Monica on July 23rd to teach Django and hack on all things Python on Saturday, July 23rd. The day will start with a Django class based on the official Django tutorial, then turn into a general hackathon, and finish up with lighting talks.
Leading the event is noted Pythonista Katharine Jarmul. As Katharine is giving the talk on web scraping at DjangoCon US, I'm hoping we can get her to give a lightning talk on the subject.
Learning Django
Sandy Strong will lead the effort to teach people the fundamentals of Django. Besides all things Django and devops, Sandy is presenting the testing talk at DjangoCon US. And if that isn't good enough for you, she won't be alone teaching - there will be a bunch of us developers experienced with Django there to to provide her with support.
Even if you already know Django, please come and hang out for the first half! You can either help out others or work on your own project.
Hacking Python and Django
The second half of the day will be about working on whatever you want. If you are new to Django and want to finish the tutorial, go right ahead. Or you can work on your own pet Django or Python project. In fact, I know that there will be work on the nascent Pyramid project intended to represent the entire Los Angeles Python community.
Lightning Talks
We'll finish with lightning talks. Several people who attended the day will get the chance to talk for 5 minutes or so about a project, tool, or cause they wanted to share. If they go too long we start applauding until they step down.
Social Hour
After another awesome day of Python in LA, everyone will cool down by hanging and chatting over drinks. If you're lucky, maybe you'll get to see me do a drunken one-handed cartwheel where I don't spill a drop of what I'm holding.
My role
I'll be there in my normal role of setting up tables and chairs, helping during the class portion, and hacking on some Packaginator stuff in preparation for the forthcoming August/September Packaginator sprints at PyCon AU, Kiwi Pycon, and DjangoCon US.
Sponsors
This is all possible thanks to the sponsorship of Mahalo, Cars.com, and the Python Software Foundation
Sign up!
Tickets are selling out really fast! Sign up now!
Leading the event is noted Pythonista Katharine Jarmul. As Katharine is giving the talk on web scraping at DjangoCon US, I'm hoping we can get her to give a lightning talk on the subject.
Learning Django
Sandy Strong will lead the effort to teach people the fundamentals of Django. Besides all things Django and devops, Sandy is presenting the testing talk at DjangoCon US. And if that isn't good enough for you, she won't be alone teaching - there will be a bunch of us developers experienced with Django there to to provide her with support.
Even if you already know Django, please come and hang out for the first half! You can either help out others or work on your own project.
Hacking Python and Django
The second half of the day will be about working on whatever you want. If you are new to Django and want to finish the tutorial, go right ahead. Or you can work on your own pet Django or Python project. In fact, I know that there will be work on the nascent Pyramid project intended to represent the entire Los Angeles Python community.
Lightning Talks
We'll finish with lightning talks. Several people who attended the day will get the chance to talk for 5 minutes or so about a project, tool, or cause they wanted to share. If they go too long we start applauding until they step down.
Social Hour
After another awesome day of Python in LA, everyone will cool down by hanging and chatting over drinks. If you're lucky, maybe you'll get to see me do a drunken one-handed cartwheel where I don't spill a drop of what I'm holding.
My role
I'll be there in my normal role of setting up tables and chairs, helping during the class portion, and hacking on some Packaginator stuff in preparation for the forthcoming August/September Packaginator sprints at PyCon AU, Kiwi Pycon, and DjangoCon US.
Sponsors
This is all possible thanks to the sponsorship of Mahalo, Cars.com, and the Python Software Foundation
Sign up!
Tickets are selling out really fast! Sign up now!
Labels:
classes,
courses,
django,
django packages,
opencomparison,
pyladies,
pyramid,
python
Saturday, June 25, 2011
Do not upload dev releases at PyPI
In my last blog post I mentioned that the plan was to release the django-uni-form 0.8.0 final in about six days. To my chagrin I was pointed at Tarek Ziade's post about not publishing beta releases on PyPI. So the django-uni-form team has now pushed up the 0.8.0 release of the library today, and removed the BETA from discovery via the web or pip.
Lesson learned: Until future notice from the distutils2 effort led by Tarek, if you are running a project that has any Stable releases, don't use PyPI to publish non-final versions.
Lesson learned: Until future notice from the distutils2 effort led by Tarek, if you are running a project that has any Stable releases, don't use PyPI to publish non-final versions.
Friday, June 24, 2011
Announcing django-uni-form 0.8.0 beta!
This has been a long time coming, but I am pleased to announce the release of the django-uni-form 0.8.0 beta. We plan to release the 0.8.0 final next Friday around the start of July 2011.
This is an enormous jump forward in the project, and I think you'll like what has been done and who contributed.
Some notable changes
Let's face it, over a year between releases is too long for any active open source project. I haven't done the incredible (and patient) django-uni-form community justice in supporting their issues and pull requests. This project has needed a much more active lead for some time. Fortunately, I found a new project in the way of Miguel Araujo.
Miguel Araujo shares my passion for good form generation and has a very deep understanding of Python, Django, and HTML. Also, his decisions on everything about this project either matches my own thoughts or he's been able to easily convince me why his concepts are sound. He is responsive to pull requests and issues, and his work is of high quality. So we should be seeing lots of releases and a better evolution of the system to match other advancements in the Django community.
So going forward Miguel will be the project lead for django-uni-form, and I'll be 'former project lead' and 'documentation donkey'.
The future of django-uni-form in the face of the forms refactor
Some people are wondering what place django-uni-form has in the face of the Django GSOC forms refactor by Greg Mullegger. Is the need for django-uni-form going away?
First of all, I actually have been pushing for a forms refactor in Django for some time. At the djangocon.us 2010 sprints Russel Keith-McGee, Django core developer and DSF president, asked my opinion on the design of a forms refactor. For the GSOC effort, I was delighted that the GSOC forms project followed the opinion that I preferred in how to doing things, and so I put in my non-binding vote for Gregor's approach. I'm rooting for you Gregor!
Second, while I think that while this library may change a bit to accomodate the eventual integration of Gregor's work, the need to be able to do guaranteed working Section 508 compliant layouts easily and more importantly make fancy layout changes in Python will keep this library alive and useful for a long time coming.
Whither goes the source code?
Finally, we'll be keeping the repo at https://github.com/pydanny/django-uni-form for the 0.8.x series so we have time to properly warn the community. When the forms refactor hits Django (prompting the necessary release of the 0.9.x series) we may be moving the library to its own github account.
Conclusion
I want to thank all the contributors, users, and anyone who gave me guidance or suggestions for this project. All the credit for this goes to you. I'm honored to have started something used by so many great people in so many wonderful ways.
This evolved from a Django beginner's shortcut filter to a rather sizable project with a great community. Due to my support of this project I learned git-scm, setuptools, JQuery, Sphinx, custom Django filters and templatetags, and more. I look forward to where it will go in the future with Miguel as lead.
This is an enormous jump forward in the project, and I think you'll like what has been done and who contributed.
Some notable changes
- As of this release, there is now a formal django-uni-form release on PyPI that fully supports Django CSRF tokens.
- Better error messages to help you debug. No more annoying Null messages on bad helpers!
- The Python code has been carefully cleaned and optimized. Much easier to read, debug, and it plain runs faster on form heavy sites.
- Various improvements to the templates to better match the parent Uni-Form library.
- Only compatible with Django 1.2 or higher and Python 2.6 or higher. If you need something to work with other earlier versions of Django/Python, then I suggest using django-uni-form 0.7.0. Or better yet, upgrade your site!
- Much improved documentation on the awesome readthedocs.org site.
- Tons of other things!
- Upcoming faster release cycles. More on that in the next section...
Let's face it, over a year between releases is too long for any active open source project. I haven't done the incredible (and patient) django-uni-form community justice in supporting their issues and pull requests. This project has needed a much more active lead for some time. Fortunately, I found a new project in the way of Miguel Araujo.
Miguel Araujo shares my passion for good form generation and has a very deep understanding of Python, Django, and HTML. Also, his decisions on everything about this project either matches my own thoughts or he's been able to easily convince me why his concepts are sound. He is responsive to pull requests and issues, and his work is of high quality. So we should be seeing lots of releases and a better evolution of the system to match other advancements in the Django community.
So going forward Miguel will be the project lead for django-uni-form, and I'll be 'former project lead' and 'documentation donkey'.
The future of django-uni-form in the face of the forms refactor
Some people are wondering what place django-uni-form has in the face of the Django GSOC forms refactor by Greg Mullegger. Is the need for django-uni-form going away?
First of all, I actually have been pushing for a forms refactor in Django for some time. At the djangocon.us 2010 sprints Russel Keith-McGee, Django core developer and DSF president, asked my opinion on the design of a forms refactor. For the GSOC effort, I was delighted that the GSOC forms project followed the opinion that I preferred in how to doing things, and so I put in my non-binding vote for Gregor's approach. I'm rooting for you Gregor!
Second, while I think that while this library may change a bit to accomodate the eventual integration of Gregor's work, the need to be able to do guaranteed working Section 508 compliant layouts easily and more importantly make fancy layout changes in Python will keep this library alive and useful for a long time coming.
Whither goes the source code?
Finally, we'll be keeping the repo at https://github.com/pydanny/django-uni-form for the 0.8.x series so we have time to properly warn the community. When the forms refactor hits Django (prompting the necessary release of the 0.9.x series) we may be moving the library to its own github account.
Conclusion
I want to thank all the contributors, users, and anyone who gave me guidance or suggestions for this project. All the credit for this goes to you. I'm honored to have started something used by so many great people in so many wonderful ways.
This evolved from a Django beginner's shortcut filter to a rather sizable project with a great community. Due to my support of this project I learned git-scm, setuptools, JQuery, Sphinx, custom Django filters and templatetags, and more. I look forward to where it will go in the future with Miguel as lead.
Sunday, June 12, 2011
Hollywood Hackathon on June 18th!
Alas, that isn't the formal name of the event, but I'm calling it that anyway. That name just rolls off the tongue, and just seems to embody my East Coast style distorted vision of the Los Angeles Python community.
Anyway, this is a day long event in Hollywood for Python developers of all skill levels to come and code like fiends with either really smart people or nice people like me. The PyLadies and SoCal Piggies are organizing this event, and they even got some PSF funding for things like tables, chairs, and t-shirts.
Which reminds me, please encourage the smart women of all ages in your life to attend! We'll have mentors just for them!
I'll be there to:
I'm just starting with Python, should I come?
Heck yeah! Hackathons (and sprints) are a great way to learn new skills or hone your technique by sitting alongside experienced developers who actually need your help. A lot of projects have what are called 'low hanging fruit', which are 'simpler' tasks saved for beginner developers to wet their teeth on.
Things I've learned at events like these include Git, Mercurial, JQuery, and a hundred other things that have made me a better coder.
What if I don't have a project of my own to bring? Should I come?
Heck yeah! There will be a number of projects around that you can join and contribute to in order to make the world a better place. There isn't a list up yet, but I'm hoping by Saturday there will be one.
What if I want to come and recruit people?
Absolutely not. This is not a job fair and we don't want unnecessary distractions.
What should I bring?
Your own functioning laptop with power cord.
How much does it cost and where do I register?
The event will put you back a measly $15 and that covers food and drinks for the day. Registration is here.
Anyway, this is a day long event in Hollywood for Python developers of all skill levels to come and code like fiends with either really smart people or nice people like me. The PyLadies and SoCal Piggies are organizing this event, and they even got some PSF funding for things like tables, chairs, and t-shirts.
Which reminds me, please encourage the smart women of all ages in your life to attend! We'll have mentors just for them!
I'll be there to:
- Help out as a general volunteer by setting up tables, manning registration, and answering questions.
- Assist a few friends on their open source projects.
- Work on the new Python LA website (powered by Pyramid).
- Finish the documentation of django-uni-form 0.8.0 if it isn't yet done.
- Maybe close some Packaginator tickets and pull requests.
I'm just starting with Python, should I come?
Heck yeah! Hackathons (and sprints) are a great way to learn new skills or hone your technique by sitting alongside experienced developers who actually need your help. A lot of projects have what are called 'low hanging fruit', which are 'simpler' tasks saved for beginner developers to wet their teeth on.
Things I've learned at events like these include Git, Mercurial, JQuery, and a hundred other things that have made me a better coder.
What if I don't have a project of my own to bring? Should I come?
Heck yeah! There will be a number of projects around that you can join and contribute to in order to make the world a better place. There isn't a list up yet, but I'm hoping by Saturday there will be one.
What if I want to come and recruit people?
Absolutely not. This is not a job fair and we don't want unnecessary distractions.
What should I bring?
Your own functioning laptop with power cord.
How much does it cost and where do I register?
The event will put you back a measly $15 and that covers food and drinks for the day. Registration is here.
Monday, April 25, 2011
We won first place at Startup Camp LA!
On a whim we (me and audreyr) decided to try out Startup Camp LA organized by Semantic Seed. This is one of those Silicon Vally style competitions to launch a minimally viable product along with a business plan and marketing pitch in the course of a weekend. We thought it would be a good excuse to hack on a project we've been cooking up in our heads over a year. So we booked our tickets via meetup.com and showed up at the new Nextspace Los Angeles location.
The organizers did a really good great job providing space, food, and lots of useful advice. I look forward to the next event that they run in the area.
Startup Camp LA Pitches
The first pitch was on Confidox, an exclusive recruiting site for lawyers with a focus on clean design, security, and good use of email/sms. The presenter, a professional attorney with great oratory skills, had mockups and a business plan ready to go.
Audrey gave our pitch, which is a site for recruiting developers that is created and maintained by developers. Developers are treated with dignity and respect, and not as replaceable components. We've talked to people on-and-off about this for over a year, and thought this would be a good opportunity to get things moving.
After Confidox and our proposal came a lot of other dreamers.
Then began the bargaining and voting for team placements. Voting was done with paper money. We received the second-highest amount of paper money and Confidox got third place.
Switching projects
As said, our recruiting idea got second place in votes. We got assigned two other people, one of them being the Confidox guy. This meant we got the most paper money total!
Rather than work on our project and have to educate the new guys on the developer ecosystem, we decided to switch to Confidox for the weekend. The scope was reasonable, the plan sound, and the mockups meant we had a specification to code against.
Development
"Ideas are cheap, implementation is hard."
From the start Audrey and I decided to not allow any scope creep. No social media widgets, banner advertisements, forums, branding, coupons, or anything that distracted from the business model. That would allow for a clean design and elegant implementation. We went to work, taking breaks to help hammer out the marketing pitch and socialize with the other teams. Our goal was a stable, functional prototype - something we achieved thanks to our mostly open source technology stack.
Technology Stack
Unless specified otherwise, everything is open source:
Audrey took charge of the group and kept us focused on the elegant, straightforward idea. She didn't just code, she also treated the business side as being equally important as the technical delivery (giving them constant feedback and coaching). Which meant we could both roll out a working prototype and nail the marketing pitch.
When it came down to it, we were a team. Everyone had purpose and everyone contributed. We communicated our idea and demonstrated that our prototype works.
Going forward
Confidox is not off the ground yet, we'll see where it goes. We certainly have a capable team.
This event was a success for us and our company Cartwheel. Also, with ancillary projects with large contributor basis such as Django Packages, Packaginator, and Django Uni-Form, me and Audrey have proven ourselves capable of just launching dynamic projects quickly that work and are used by real people for real work. We'll see what we can do with that proof.
Finally, if you want to learn our techniques for constructing Confidox and other efforts, come to our Los Angeles area classes.
The organizers did a really good great job providing space, food, and lots of useful advice. I look forward to the next event that they run in the area.
Startup Camp LA Pitches
The first pitch was on Confidox, an exclusive recruiting site for lawyers with a focus on clean design, security, and good use of email/sms. The presenter, a professional attorney with great oratory skills, had mockups and a business plan ready to go.
Audrey gave our pitch, which is a site for recruiting developers that is created and maintained by developers. Developers are treated with dignity and respect, and not as replaceable components. We've talked to people on-and-off about this for over a year, and thought this would be a good opportunity to get things moving.
After Confidox and our proposal came a lot of other dreamers.
Then began the bargaining and voting for team placements. Voting was done with paper money. We received the second-highest amount of paper money and Confidox got third place.
Switching projects
As said, our recruiting idea got second place in votes. We got assigned two other people, one of them being the Confidox guy. This meant we got the most paper money total!
Rather than work on our project and have to educate the new guys on the developer ecosystem, we decided to switch to Confidox for the weekend. The scope was reasonable, the plan sound, and the mockups meant we had a specification to code against.
Development
"Ideas are cheap, implementation is hard."
From the start Audrey and I decided to not allow any scope creep. No social media widgets, banner advertisements, forums, branding, coupons, or anything that distracted from the business model. That would allow for a clean design and elegant implementation. We went to work, taking breaks to help hammer out the marketing pitch and socialize with the other teams. Our goal was a stable, functional prototype - something we achieved thanks to our mostly open source technology stack.
Technology Stack
Unless specified otherwise, everything is open source:
- Python
- Django
- Ubuntu
- PostGreSQL
- JQuery
- Blueprint CSS
- Apache HTTP Server
- Tropo (commercial SMS messaging with free dev accounts and developer friendly API)
The Confidox pitch:
- Our group presented as a team. Marketing talked marketing, techs talked tech.
- A live prototype site with fully functioning authentication, registration, profiles, listings, search, and email/SMS notifications.
- Most pitches lacked even a buggy prototype.
- Presenting teams bickering during their presentations.
- Unbelievably, one slide presentation had music that the presenter had to shout over.
Audrey took charge of the group and kept us focused on the elegant, straightforward idea. She didn't just code, she also treated the business side as being equally important as the technical delivery (giving them constant feedback and coaching). Which meant we could both roll out a working prototype and nail the marketing pitch.
When it came down to it, we were a team. Everyone had purpose and everyone contributed. We communicated our idea and demonstrated that our prototype works.
Going forward
Confidox is not off the ground yet, we'll see where it goes. We certainly have a capable team.
This event was a success for us and our company Cartwheel. Also, with ancillary projects with large contributor basis such as Django Packages, Packaginator, and Django Uni-Form, me and Audrey have proven ourselves capable of just launching dynamic projects quickly that work and are used by real people for real work. We'll see what we can do with that proof.
Finally, if you want to learn our techniques for constructing Confidox and other efforts, come to our Los Angeles area classes.
Friday, April 22, 2011
I teach Python and Django
This is one of those blog posts where a developer announces that he/she is teaching for a whole week. The difference is that in this post I'm going to explain why I want to teach and why you should take my classes or send your staff.
I'm an experienced instructor.
I've taught a variety of things for over 20 years, including in alphabetical order: Best practices, Django, English, JQuery, martial arts, Pinax, Python, Selenium, soccer, and unit testing. I speak clearly, get across technical points well, and love the material. I also know how to provide an early foundation of knowledge and then expand upon it for maximum benefit.
I don't just dump knowledge into the heads of my students; I take the time to teach them common standards and best practices, so their code is extendable and maintainable.
I'm not alone.
Audrey Roy, co-founder of Cartwheel, leader of PyLadies and Django Packages, who has tutored and lab assisted at MIT will be teaching with me, meaning the teacher-to-student ratio is kept at 5:1 for our first offering.
I want you to surpass me.
After teaching various things for many years I've found it a point of honor and immense pride when a student shines better than myself. I'm not one of those teachers who holds something back so I can always have the edge. In fact, my ultimate goal is to make you better than me.
I rest on the shoulders of giants.
I'm sure the people I'm mentioning in this section are going to roll their eyes, but lets face it - they rock!
In any case, I've had the fortune of helping Steve Holden write Python 3 classes for the O'Reilly School of Technology. I've been exposed to the Django code bases of NASA, RevSys and Eldarion. While I can't share that work directly, I can take the abstract of their methods and turn it into lessons.
For the employers: Classes are a good way to find resources
Having trouble finding staff? Imagine instead you hire a talented developer from another language and send them to my classes. In a week's time for a fraction of the price they'll have been kickstarted into not just knowing how to do their job, but how to expand their knowledge so if they don't know something, they know who to ask.
Refresher courses are free for six months
Space-permitting, you can retake a class at no charge.
The course schedule
Our first classes are scheduled for May 16th to May 20th. We are offering:
- Three Day Python Crash Course (May 16th, 17th, and 18th)
- Two Day Django Crash Course (May 19th and May 20th)
One more thing, if you take both classes we'll give you a 10% discount after registration.
Subscribe to:
Posts (Atom)