jessenoller.com

Check out the post I just threw up on the PyCon 2011 blog over here — the short ver­sion is that we got over 200 talk pro­pos­als! This is awe­some, and makes the pro­gram committee’s job that much harder. If you want to help out, ping me at jnoller at python dot org.

Check out the post I just threw up on the PyCon 2011 blog over here — the short ver­sion is that we got over 200 talk pro­pos­als! This is awe­some,...

Why is it, that when­ever I think things will calm down, they do the exact opposite?

Well — you should know by now that the PyCon 2011 Call for Pro­pos­als is up — we’re accept­ing main con­fer­ence talks, poster ses­sions and tuto­ri­als, all at once. The main con­fer­ence pro­pos­als are due by Novem­ber 1st — so I’d rec­om­mend get­ting those talks in! Also, you should know that we’ve announced our first keynote speaker — Hilary Mason! Really, really look­ing for­ward to that.

Over on the sprints side — Brian Curtin has done sev­eral blog posts — the first details the “get­ting started with Python-Dev” guide he’s been shep­herd­ing for the project. I’d rec­om­mend tak­ing a look — you can send feed­back to sprints@python.org. The sec­ond is a note on the fact we have our first com­pany donat­ing actual funds to the project (via the PSF) — Trad­ing Tech­nolo­gies. This is awe­some news.

If you want to do a sprint — and you want some money to help out, please, please, please send an appli­ca­tion to sprints@python.org — we cur­rently do not have any sprints lined up in the near future (We are spon­sor­ing the ?http://www.pymntos.com/ sprint occur­ring tonight — they’re port­ing Mute­gen to python 3). If you need help, or want help send­ing out a call for a sprint, con­tact us too. Our goal is to help every­one get sprints up and off the ground.

Also, if you want to help out with the sprints project — please let me know. We need blog­gers, writ­ers and other peo­ple to help fur­ther “the cause”.

Finally, I’ve been spend­ing the major­ity of my time once again blog­ging for my employer (Nasuni) — if you’re inter­ested, I recently did a series on “The Cloud” (focus­ing on Pri­vate vs. Pub­lic clouds), while Rob (my boss) did a fan­tas­tic post on the real cost of a giga­byte in the cloud:

• Pri­vate vs. Pub­lic Cloud 1: The five key attrib­utes of the Cloud.
• ?Pri­vate vs. Pub­lic Cloud 2: Defin­ing Pub­lic ver­sus Pri­vate Clouds.
• ?Pri­vate vs. Pub­lic Cloud 3: Which option is best for you?
• What is the (real) cost of a giga­byte in the cloud?

Why is it, that when­ever I think things will calm down, they do the exact opposite? Well — you should know by now that the PyCon 2011 Call for Pro­pos­als...

I’ve just started send­ing out notices to all the mail­ing lists and sites — the Pycon 2011 Call for Pro­pos­als is now open. You can check it out here — we’ve got a brand new web­site, and a rock­ing group of vol­un­teers. I encour­age any­one who thinks they might be inter­ested in sub­mit­ting a talk pro­posal and volunteering!

I’ve just started send­ing out notices to all the mail­ing lists and sites — the Pycon 2011 Call for Pro­pos­als is now open. You can check it out here —...

I’ve obvi­ously been quiet here on my per­sonal blog — as every­one who reads reg­u­larly knows I’m neck-deep in a pretty excit­ing startup call Nasuni as well as doing other projects, like the PSF Spon­sored sprints thing. That com­bined with twit­ter means my time for other addi­tional long-form con­tent is min­i­mal. So here’s a small roundup of inter­est­ing things:

Nasuni

Yup, still run­ning Python and Django! We’re actu­ally pretty proud to be a spon­sor for Djan­go­Con 2010 com­ing up in Sep­tem­ber — I’ll be attend­ing, so I hope to see all the famil­iar Django faces I know, and meet some new ones.

I’ve been blog­ging semi-regularly for the Nasuni blog itself — my posts are focused on product-things more than any­thing else. Here’s a small list of posts which I’ve done:

• The Road to Release — Fea­ture Pre­views — this is actu­ally my lat­est one, and the first in a series where I’ll be show­ing off some of the new fea­tures we’re adding in the lat­est release.
• Look­ing at Open­Stack, a Rack­space and NASA ini­tia­tive — For those of you who don’t know, Rack­space and NASA announced Open­Stack — the awe­some part? It’s all python — I had the swift com­po­nent (which pow­ers Rackspace’s cloud­files sys­tem) of Open­Stack run­ning pretty quickly. I’d rec­om­mend snag­ging the code from launch­pad and tak­ing a look. Swift (the stor­age com­po­nent) uses event­let — and Nova (the com­pute part) uses Tor­nado and Twisted.
• Stor­age Switzer­land Test Dri­ves the Filer — This is a response to an arti­cle writ­ten about the prod­uct — I actu­ally used it to pre­view some of the work going into the next release of the Filer.
• Thanks to Django — This piece goes into some detail about our use of Django, it’s one of our ways of say­ing thanks. I still need to rework it so we can send it over for the Django Suc­cess Sto­ries page.
• Thanks to the Sup­port­ing Cast — This is an ear­lier thank you post — but to the other peo­ple who have helped out a ton, includ­ing Greg New­man, Lin­coln Loop, and Revsys.
• The Donut Solu­tion — This was a fun one, mainly to show that yes — we’re lis­ten­ing hard to cus­tomer feed­back, and we’re improving/iterating quickly. Also, I get to show off UI improvements.
• Finally — The Nasuni Blog team — this is the rosetta stone for the authors of the blog, describ­ing who we are. I didn’t write this piece, but it’s good read­ing to fig­ure out who is who.

If you’re inter­ested in Nasuni — or cloud stor­age in gen­eral — I’d encour­age you to sign up for the RSS feed. We’re try­ing to keep the infor­ma­tion use­ful out­side of “just us” (despite my urge and predilec­tion to churn­ing out com­pletely product-related posts) — and if you ever have feed­back, drop us a line.

PSF Spon­sored Sprints

The project con­tin­ues on — we’ve funded two sprints so far, and have sev­eral more com­ing down the pike. We’re always in need of vol­un­teers to help us do things like the man­u­als and site maintenance/content author­ing. Here’s some highlights:

• The call for appli­ca­tions is open — The call for appli­ca­tions is open — and now I sus­pect we won’t be clos­ing it. Orig­i­nally, I thought we’d have to do things in waves of apply-approve. As time has pro­gressed, I no longer think this is the case.
• Mon­treal Python Pack­ag­ing sprint wrap up — the wrap up report for our first sprint!
• Europy­thon core sprint report - another wrap up report for the core sprint we pro­vided funds to.
• Just added the loca­tions page — we now have people/companies offer­ing up space for sprint­ers! Check it out!
• Finally - Sprints at PyOhio — PyOhio is going on this week­end, if you’re in the area you should really go check it out! Cather­ine has gone above and beyond with the entire “become a con­trib­u­tor” effort going on.

Please! If you’re think­ing about hold­ing a sprint - send us an appli­ca­tion! Heck, even if we’re not spon­sor­ing it, we’ll help pro­mote you via the blog, and the sprint cal­en­dar we have up. A lit­tle fact? The sprints we’ve funded so far, and that are on deck for fund­ing are all out­side of the US, which is both awe­some, and surprising!

PSF Board

Some of you prob­a­bly know that I’m cur­rently on the board of direc­tors for the PSF — things progress well here, but I mainly wanted to call out the excel­lent blog Doug Hell­mann has been author­ing for PSF news. You should really be watch­ing that because yes — we do do things, and hope­fully over the next year, we’ll be doing more awe­some things.

I’ve actu­ally got a big­ger post in the works for what I think the ulti­mate mis­sion of the PSF is/should be as well as “how do you get money from us” as well. Must find the time!

I’ve obvi­ously been quiet here on my per­sonal blog — as every­one who reads reg­u­larly knows I’m neck-deep in a pretty excit­ing startup call Nasuni as well as doing other...

The Google Test­ing Blog has a good post up right now by James Whit­taker called “There, but for the grace of test­ing, go I” — it’s a good read, and a per­ti­nent one for any of you/us who feel strongly about quality.

Even though I’ve spent more time then not on “the other side” of the table (Devel­oper, noun — “focus on mak­ing soft­ware (ergo, bugs)”) I find that James’ words ring pretty loudly for me still, espe­cially his part on risk analysis:

I am thank­ful that the vast major­ity of bugs that affect entire user pop­u­la­tions are gen­er­ally nuisance-class issues. These are typ­i­cally bugs con­cern­ing awk­ward UI ele­ments or the occa­sional mis­fir­ing of some fea­ture or another where workarounds and alter­na­tives will suf­fice until a minor update can be made. Seri­ous bugs tend to have a more local­ized effect. True recall class bugs, seri­ous fail­ures that affect large pop­u­la­tions of users, are far less com­mon. Testers can take advan­tage of the fact that not all bugs are equally dam­ag­ing and pri­or­i­tize their effort to find bugs in the order of their seri­ous­ness. The futil­ity of find­ing every bug can be replaced by an inves­ti­ga­tion based on risk.

I’d rec­om­mend James’ post amongst the oth­ers there on that blog — it reminded me of an old rant of mine “The cost of (not) test­ing soft­ware”. Any­one in the busi­ness of mak­ing some­thing is also in the busi­ness of mak­ing bugs. It’s impor­tant for us to keep that in mind when we deal with our day to day job — and when we think about our cus­tomers. It’s also impor­tant for us to keep that in mind when crit­i­ciz­ing or drag­ging any per­son or com­pany or code through the muck.

The Google Test­ing Blog has a good post up right now by James Whit­taker called “There, but for the grace of test­ing, go I” — it’s a good read, and...

Back in May, Guido assigned me “single-use” BDFL pow­ers when decid­ing on the state of PEP 3148. I had been work­ing on and off with Brian since his orig­i­nal pro­posal to the stdlib-sig mail­ing list.

Tonight, I “offi­cially accepted” the PEP Brian’s put a lot of work into. You can check out the PEP itself, or play with the code over here. The credit goes to Brian, and the small army of peo­ple who gave him feed­back includ­ing Jef­fery Yasskin who spent a fair amount of time iter­at­ing and expound­ing on things.

Below, is a snip­pet from one of my orig­i­nal emails to python-dev on my rea­son­ing for sup­port­ing the library, and also adding in the “con­cur­rent” namespace.

Baloney. A young library pro­vid­ing some syn­tac­tic sugar which uses
prim­i­tives in the stan­dard library to imple­ment a com­mon pat­tern is
fine for a PEP. We’ve hashed this out pretty heav­ily on the stdlib-sig
list prior to bring­ing it here. By the same argu­ment, we should shunt
all of the recent unittest changes and improve­ments into space, since
golly, other peo­ple did it, why should we.

This is some­thing rel­a­tively sim­ple, which I would gladly add in an
instant to the mul­ti­pro­cess­ing pack­age — but Brian’s one-upped me in
that regard and is pro­vid­ing some­thing which works with both threads
and processes hand­ily. Take a look at multiprocessing.Pool for exam­ple
- all that is some sugar on top of the prim­i­tives, but it’s good
sugar, and is used by a fair num­ber of people.

Let me also state — “my” vision of where futures would live would be
in a con­cur­rent pack­age — for example:

from con­cur­rent import futures

The rea­son *why* is that I would like to also move the abstrac­tions I
have in mul­ti­pro­cess­ing *out* of that mod­ule, make them work with both
threads and processes (if it makes sense) and reduce the
mul­ti­pro­cess­ing mod­ule to the base prim­i­tive Process object. A
con­cur­rent pack­age which imple­ments com­mon pat­terns built on top of
the prim­i­tives we sup­port is an objec­tively Good Thing.

For exam­ple, how many of us have sat down and imple­mented a thread
pool on top of thread­ing, I would haz­ard to say that most of us who
use thread­ing have done this, and prob­a­bly more than once. It stands
to rea­son that this is a com­mon enough pat­tern to include in the
stan­dard library.

In any case; con­sider me a strong +1 to adding it.

With that done, I am back to being only the benev­o­lent dic­ta­tor of my lawn, which is mostly dead.

Also, for added fun — check out the PyCon AU talk Brian did!

Back in May, Guido assigned me “single-use” BDFL pow­ers when decid­ing on the state of PEP 3148. I had been work­ing on and off with Brian since his orig­i­nal pro­posal...

I’m not an active user myself (I’ve never had the need) but Numpy and Scipy are two of <b>the</b> key mod­ules peo­ple cite as their rea­son not to use or port (or sup­port) Python 3 (due to lack of port­ing). Accord­ing to this announce­ment to Numpy-discuss, this will very quickly no longer be the case. Numpy has been ported to Python 3, and Scipy is fol­low­ing quickly (in progress). These are cor­ner­stone libraries for the com­mu­nity — more will follow.

This is great news; most of all, I’m look­ing for­ward to pick­ing through the col­lec­tive knowl­edge of their port­ing effort to see if there infor­ma­tion which can be given/provided to other port­ing efforts. You can see their Python3 port­ing notes here.

And a quick plug — the PSF Sprints project will help fund sprints focused on port­ing libraries to Python 3 — go here.

I’m not an active user myself (I’ve never had the need) but Numpy and Scipy are two of &lt;b&gt;the&lt;/b&gt; key mod­ules peo­ple cite as their rea­son not to use or...

I’ve put up the first offi­cial Call for Appli­ca­tions over on the Python Sprints blog — go check it out!

I’ve put up the first offi­cial Call for Appli­ca­tions over on the Python Sprints blog — go check it out!

Oth­er­wise known as “from psf import sprints”.

Awhile ago, I started won­der­ing if there was a way that the Python Soft­ware Foun­da­tion (the PSF) could reach out, and help encour­age python devel­op­ment a lit­tle bit more than it cur­rently does (it actu­ally does a lot of stuff). I then spent a fair amount of time think­ing about core con­tri­bu­tion, and ways of get­ting peo­ple not just to become con­trib­u­tors to say, python-core, but also to the “ecosys­tem” of big-P-Python. It’s part of my job now that I vol­un­teered to be on the PSF Board.

Then, a few weeks ago, I asked the ques­tion — “Why aren’t you con­tribut­ing (to python)?” — that post alone got my lit­tle blog here about 30,000 hits in around 48 hours. Pretty impres­sive for navel gaz­ing (not even con­tro­ver­sial navel gaz­ing, at that). In the days fol­low­ing that post, I’ve had a lot of pub­lic and pri­vate dis­cus­sions with peo­ple about var­i­ous ways to help improve things, what could work, what wouldn’t work, etc.

One thing has been stuck in my head — sprints — sprints are places where a bunch of pro­gram­mers and hack­ers of all skill lev­els, sit in a room and work on a par­tic­u­lar code domain, it could be a web­site, it could be python bugs, it could be a mod­ule, library, or any­thing, really. The point is get­ting a bunch of peo­ple together in a room, feed them, water them and enable the hacking.

And finally — there’s Python 3.

Python 3 is a bit of an inter­est­ing ani­mal — and while it is the future of the lan­guage, and a much brighter one at that, the rate at which peo­ple are port­ing to Python 3 is a lit­tle slower than many of us would like. Port­ing libraries to Python 3 can be rel­a­tively sim­ple, but it can also be bor­ing, tedious and require men­tor­ship and guidance.

Given these itches of mine — I’ve decided to try to find (or at least, start the for­mu­la­tion) of a cure. A few weeks ago, I approached the rest of the Python Soft­ware Foun­da­tion board, and pre­sented them with a “spon­sored sprint” pro­posal. The short ver­sion being that the PSF would spin up a com­mit­tee which would accept and eval­u­ate sprint pro­pos­als from the world as a whole, and give each sprint a rel­a­tively set amount of money.

The sprints them­selves are rel­a­tively focused — Python-core, the Python web­site, docs, bugs — and finally, port­ing Python 2 libraries to Python 3.

So — all of that said, I’m offi­cially pub­licly announc­ing the new pro­gram. I’m still work­ing on ini­tial com­mit­tee mem­ber­ship, and putting together things like the mail­ing list, but I will soon be announc­ing a call for appli­ca­tions. Below, you will find the full pro­posal — please feel free to post com­ments, or send me pri­vate email (jnoller at python dot org) about ques­tions or con­cerns. If you want to help — please please con­tact me — I can not pos­si­bly make this a suc­cess on my own.

Oth­er­wise known as “from psf import sprints”. Awhile ago, I started won­der­ing if there was a way that the Python Soft­ware Foun­da­tion (the PSF) could reach out, and help encour­age...

Over the past year or two, I’ve been in a pile of dis­cus­sions sur­round­ing attempt­ing to increase the num­ber of con­tri­bu­tions to Python (as a project and ecosys­tem) — specif­i­cally around bug fixes/patch reviews, fil­ing bugs, point­ing out doc­u­men­ta­tion issues, web­site con­tent, etc. Many of these con­ver­sa­tions seem rel­a­tively insu­lar (peo­ple already involved talk­ing about how they get work done, and how easy it is) or rel­a­tively hand-wavy (“let’s make it bet­ter! *crickets*”).

We all know that the fact is that there are plenty of areas for any­one (both pro­gram­mer and not) to con­tribute to the Python project/ecosystem, this is actu­ally true for most, if not all, open source, and open com­mu­ni­ties out there. While I am look­ing at this through the myopic lens of Python-core, the same dis­cus­sion could be applied anywhere.

In the dis­cus­sions I’ve had on mail­ing lists, and in pri­vate con­ver­sa­tions with peo­ple about why they don’t con­tribute, I’ve found a set of recur­ring issues cited by peo­ple who could be con­trib­u­tors, roughly speak­ing these are:

• Don’t know how (doc­u­men­ta­tion issue)
• Don’t know where (site lay­out, orga­ni­za­tion issue)
• Don’t want to fight/argue with the “but this is the way we’ve always done it” peo­ple (per­cep­tion issue)
• For many issues, see check­out (svn), build (learn a “new” build sys­tem), run tests/write tests, gen­er­ate patch, file bug, defend bug as a “high bar” (process/tool issue)
• Don’t feel that they’ll be val­ued (per­cep­tion issue)
• Can’t invest the time to learn the tool chain(s) (make, ReST, regrtest, svnmerge/svndiff, sphinx, etc) (I got nothin here)

And so on.

What inter­ests me more than the things I’ve listed about (which is a dis­til­la­tion of months of dis­cus­sions) is what, if any­thing, pre­vents you, my reader(s) from con­tribut­ing to the fol­low­ing areas:

• Fil­ing bug reports (includ­ing the stdlib and documentation)
• Fil­ing patches for bugs/improvements (includ­ing the stdlib and documentation)
• Fix­ing issues/sending patches on web­site content
• Propos­ing new web­site or doc­u­men­ta­tion content
• Con­tribut­ing to web­site maintenance
• Con­tribut­ing to the Documentation

And any­thing else you can think of. What I’m ask­ing for, is for you to give me thoughts, ideas and feed­back on how we can lower the bar and reduce the fric­tion of any of this so that you too can help out. Every­thing is fair game, even “I find the method of argu­ing for PEPs to cause lower intesti­nal irri­ta­tion” (although, I hope to get more con­struc­tive com­ments than that).

Here’s the rea­son I’m asking/reaching out — I firmly, and totally believe that every sin­gle per­son who uses Python today can become a con­trib­u­tor to the project and ecosys­tem beyond that of a user. While it is true that philo­soph­i­cally, every­one who uses Python is con­tribut­ing, I would like to see if we can make it so that even the most “basic” user feels that they can file a bug, sub­mit a patch, fix the doc­u­men­ta­tion, fix/add web­site con­tent, etc.

Much like I think any­one can, and should be empow­ered to con­tribute back to the “Python Project” — I believe the cul­ture of “every­one con­tributes” is an impor­tant one. Cit­ing the won­der­ful keynote from PyCon 2010 by Anto­nio Rodriguez (video here), I main­tain this is should be a goal for every­one, not just com­pa­nies — but open source projects as well.

There are lots of things we can change/fix/improve — but before we can do that, we have to be able to iden­tify the “bugs” in what we have now. Do we need a giant flow­chart with flash­ing text (I joke!) or do we need sim­pli­fied “how do I…” text to the web­site? Everything’s fair game (except “just put it on github”).

So, do you have any thoughts? If you don’t feel com­fort­able air­ing them pub­licly, you can email com­ments to jnoller at (gmail.com|python.org) as you see fit. I promise not to share any iden­ti­fi­able infor­ma­tion, but I reserve the right to share the feed­back you pro­vide, albeit anony­mously. I also promise to ask mean­ing­ful ques­tions so I can squir­rel out more detail if needed.

Over the past year or two, I’ve been in a pile of dis­cus­sions sur­round­ing attempt­ing to increase the num­ber of con­tri­bu­tions to Python (as a project and ecosys­tem) — specif­i­cally...