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:

• 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.

And now to open the floor to questions...

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.

Python Packages sprint on Sunday 4/10/2011

Want to help Python? Want to encourage PyPI to focus on being the best package index system possible and not a catalog/ratings/documentation engine? Then sprint with us on Packaginator this weekend because...

We need your help!

In my last blog post I mentioned Packaginator which will power the forthcoming Python Packages site. The purpose of this site is to do for Python what Django Packages does for Django. We aren't quite ready for launch, and the purpose of this post is to list what tasks remains. There is an enormous amount of outstanding work, and we want to launch as soon as possible so...

Before I begin, Python Packages will have some dramatic differences from Django Packages:

• The 'Add Package' controls won't exist. The only way to get a package into the site is to put your package onto PyPI.
• At launch only approved moderators will be able to create new grids and grid features.
• Only approved moderators and package owners will be able to edit the target repo URLs and add/edit/remove packages on grids.
• Users will still be able to click the "I use this" button. 

Please join us!

We invite you to sprint with us on Sunday, April 10, 2011. We are sprinting on Python Packages / Packaginator from the Los Angles OS Hackathon this weekend but also invite remote sprinters to join us from across the globe.

How to participate

How to contribute to Packaginator is really well documented and I beg you to read that before commencing any sort of work. We don't use IRC to communicate, instead relying on our convore channel at http://convore.com/packaginator.

Because we can, have, and will reject pull requests, I need to reiterate a few things:

• Run the test suite before you submit your pull request
• Keep your pull requests small and focused
• Be familiar with PEP-8 and keep your code simple

Important: Because we are "this close to launch", for Sunday we aren't the least bit interested in dramatic architecture revisions, model changes, obfuscating our settings, new design, different layouts, or adding Haystack. We'll consider those afterwards.

Tickets

Priority tickets are the real choke points that we want to overcome. We could use help on all of them:

• Low hanging fruit tasks
• Challenging tasks
• Priority tasks

When you start a ticket, please let us know in http://convore.com/packaginator so we can mark it as assigned in the Github issue tracking system or warn you if it is already being worked.

Launch

We hope to launch this sunday or in the immediate days afterwards, and for that Jacob Kaplan-Moss, Jacob Burch, and Noah Kantrowitz  have graciously volunteered their time to do the engineering work.

Django Dash Lessons Learned

Our experience with Django Dash 2010 was that it was an wonderful exercise in classic Django development, cowboy/cowgirl coding, and drinking copious amounts of caffeinated beverages. The result, Django Packages, is something we are happy with, are continuing to improve, and hope will improve the community.

Lesson: Fixtures are a must

Django gives you this amazing Admin control panel. As soon as you get your models in place and are entering test data, start creating fixtures. For the dash we named them initial_data.json and loaded them into the individual app directories. This meant that every time we blew away the database we got a reload with records in place. Sometimes this means you have to hand-edit JSON (or YAML if you swing that way), but the alternative is to waste time re-entering the same data again and again. Don't forget to change the names of your test fixtures before you launch!

From the command-line how to save a fixture pydanny-style:

./manage.py dumpdata package > apps/packages/fixtures/initial_data.json

One nice thing about fixtures is that when you do have the time/need, you can use them to help you write tests. And it makes development easier for contributors.

Lesson: Research ahead of time

In the days before the contest, we researched to see if our target repos (Github, ;BitBucket, and Google Project Hosting) each had an API and a python library to speak to that API. Github has both an API and python library, Bitbucket has an API but no library. And as far as we can tell, Google Project Hosting lacks both API and library (someone please tell me I'm wrong about Google Project Hosting lacking an API).

This meant that when we commenced coding we knew which code base to work with - we weren't trying to look up this or that random package.

We did the same thing for rendering charts.

Lesson: Get it working then optimize

Looking at some of the code makes us wince a bit. But we got it working. Now we can go back and do some code cleanup, maybe use an XML parser instead of regex to try to scrape content from PyPI, and generally feel better about ourselves.

Lesson: Plan out system architecture in advance

In retrospect it was really amusing, but the night of launch the site was serving via the Django runserver command. We were so dead tired and neither of us are crack system administrators that we did what we had to do to score the contest launch point. The next day Audrey got the site running underApache, and next week we'll be giving someone else system access to increase reliability. Next year for the contest we'll probably use something like this or get continuous integration running in the first hour.

Lesson: Don't be afraid to chat with others after the contest starts

Share your ideas, selected packages and frameworks with your competitors. The break from coding helps clear the mind and they might counter with a better idea/package/framework you can use.

Announcing Django Packages!

I'm part of a two person team that just launched that BETA site for http://djangopackages.com, a site that is designed to list all the Django Applications, Frameworks, and Packages created by the Django community. While there are already a few places to look for these things, it is quite easy to argue that they are challenging to navigate, don't give any hard metrics, or are woefully incomplete/unstable/closed. Our goal was to provide an attractive, easy-to-navigate, easy-to-add-data, stable site and share it with the world.

Also, this was our entry into Django Dash 2010, and was the culmination of a few days of brainstorming over paper, a lot of research, and two days of feverish coding/designing. The project was feature complete to our specifications at 5pm the second day, and the rest of the time was spent adding in UI tweaks, usability enhancements, and trying to deploy our creation.

Since then, we've cleaned up a the UI, improved the design, and got the site stable. The code is open source and on github, so fork and contribute!

Design Consideration: No 'Like' button or 'Rate my app' rating systems

We wanted hard metrics. So the package numbers are pulled from the repo sites such as Github, Bitbucket, and Google Code. Otherwise things get weighted funny. Sure, this system can be monkeyed with, but its a good metric for now. We've had suggestions from Django core developers of coming up with a quality check system, things like pypants and/or a formalized approval system.

Design Consideration: Grids

Early on we wanted to duplicate and improve upon the Django CMS Comparison page. There is also a version for Forums, but it would be nice to have a current one for blogs! In addition, recently I heard that 'tag clouds are the mullets of web 2.0'. This really struck a chord in my soul. Since we had metrics on packages, why not compare those metrics, and use those comparisons, which we call 'grids', instead of tags? In fact, we extended our idea and instead of traditional tabs we use grids in the top navigation area as seen below:

Design Consideration: Categories

The site groups packages into three categories, 'Apps' which are individual django applications. 'Frameworks' which are aggregates of apps and python modules. And 'Projects' which are implementations of Apps and Frameworks. We've thought about adding 'Tools' but weren't sure if there was anything that fit that concept, and we are leery about allowing regular Python efforts into the fold.

Design Consideration: Regex vs XML

Slurping data out of Github was easy, especially since I used python-github2. Bitbucket has a RESTful API as well that serves out JSON. I think Google Code does as well. PyPI does not and DOAP on PyPI seems to give little that is useful, so I was forced to do screen scrapes of version numbers and downloads. I'm much faster with Regex and string methods than XML juggling, and speed was of the issue this weekend. I'm not sure what benefit there is to redoing it in HTML5lib or lxml, since what I have works and appears to be stable.

Design Consideration: Leave caching and optimization for later

Besides a tiny bit of memory based template caching on the home page, there is/was no optimization. In time I plan to cache many things using a proper key/value store like redis or memcached. Perhaps not before more design and usability work is done.

Why scared of rabbits?

You wouldn't understand unless you live on the Kansas prairie.

Note: if you have any suggestions, issues, problems with Django Packages please use our issue tracker!

Register for Pycon 2010 already!

Update: I registered for Pycon at the early bird price but did not pay yet. Fortunately, the Pycon site lets you hold the price at the lower amount. Which means later this month when I get paid for some work I did back in the autumn I'll be able to pay for my registration at the early bird price!

The Pycon folks want early registrations because it helps them plan out resources and staff needs, not to mention the visceral thrill of watching attendance numbers go upwards. So help them out and register.

If it helps, I'll be presenting. Twice. I'll be giving A Long Pinax Tutorial with James Tauber. And I'll also be giving A Short Pinax Tutorial (also with James Tauber) during the regular conference.

For once I'm not planning to fill up on tutorials myself. I'll be too keyed up over my own presentations. So I just plan to take James Bennett's Django in Depth Tutorial.

I'll be there for all four days of the sprints. Of course, I'll be focusing on Pinax and Django material.

Of course I'm hoping that NASA has a major presence at Pycon this year. Python related technologies really seemed to take off this year for the agency, both in usage and publicity. Maybe we could have a space themed party or something?

Finally, I'm hoping to get another Capoeira Roda off the ground. We did Capoeira at DjangoCon and it was a blast. Any Atlanta folks want to see if we can get a local school to give us guidance and instruction?

DC Sprints location is changed!

Cosi seemed great. Decent food, internet, pleasant seating.

Except they blocked the really useful ports. SSH, Git, you name it.

So we have switched to the Arlington Central Library, just two blocks away.

http://www.arlingtonva.us/departments/Libraries/about/LibrariesAboutCentral.aspx

DC sprints location is official!

All the details can be had by following this link:

http://groups.google.com/group/NOVA-DUG/web/dc-branch-of-the-eurodjangocon-09-sprints

I'm rather excited by this event. It is the first in what I hope becomes a DC tradition of doing 'local mirrors' of python conference sprints with involvement from all the area python groups. This way, more people get to contribute, our community works better together, and the networking opportunities can abound.

On the other hand, I wish I had found more time to organize this event. And that I had found a good location inside of Washington, DC. I suspect this first effort will have a low turnout, but I won't mind being pleasantly surprised. ;)

My hope is that this year alone we might be able to exploit similar efforts in 2009 for the Euro Pycon, DjangoCon, and Plone Conferences.

With that in mind, I'm going to insist that these local mirror sprints be completely framework and tool neutral. For starters, under the hood, aren't we all just doing python? Plus, I'm of the very firm belief that any major system with initiative has things to teach, be it lessons learned or neat ideas. For example, Jacob Kaplan-Moss uses zc.buildout, which grew out of the Zope community. And while we might not have the ability to listen in on actual conference sessions, think about the chances we'll get to look at each other's tools and methods.

Second Annual President's Day Sprint

We did this two years ago at Chris Shenton's place, where we sprinted on a Plone application. Last year we skipped it. This year we are doing it again. We being myself and perhaps Alex Clark, Katie Cunningham, Chris Shenton, and a few other locals to the DC area - essentially members of ZPUG-DC. Perhaps we can get non-locals in on it too! You can do whatever you want.

Originally I hoped to meet in a single, central location, but its clear that getting anywhere the day before the inauguration is not going to happen. So instead we are going to find local places that serve coffee and do our work there. Hopefully we'll gather in groups to provide moral support. Katie Cunningham plans to do it in a Vienna, VA Cosi's - so if you are in Northern Virginia, consider joining us there!

Things I plan to do:

1. Work on simplegraph. I plan to finish my forms integration to make it easier for end users. If that happens quickly then I'll add in capability to have more than one form.
2. Work on pinax. I want to finish doing a code merge.

What about you? Well, you can sprint on anything you want. Core python, Plone, Zope, Django, Pinax, PHP, whatever. Odds are we'll be spread out over the DC metropolitan area so I'm thinking we will have a central IRC channel entitled #sprintdc2009.

See you tomorrow!