jessenoller.com

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 obviously been quiet here on my personal blog - as everyone who reads regularly knows I'm neck-deep in a pretty exciting startup call Nasuni as well as doing other projects, like the PSF Sponsored sprints thing. That combined with twitter means my time for other additional long-form content is minimal. So here's a ...

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 Testing Blog has a good post up right now by James Whittaker called "There, but for the grace of testing, go I" - it's a good read, and a pertinent 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 ...

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 powers when deciding on the state of PEP 3148. I had been working on and off with Brian since his original proposal to the stdlib-sig mailing list. Tonight, I "officially accepted" the PEP Brian's put a lot of work into. You can check out the PEP itself, ...

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 modules people cite as their reason not to use or port (or support) Python 3 (due to lack of porting). According to this announcement to Numpy-discuss, this will very quickly no longer be the ...

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 official Call for Applications over on the Python Sprints blog - go check it out!