PyCon DC 2004
PyCon DC 2004 was held March 24-26, 2004, (plus four days of sprints beforehand) at George Washington University in Washington, DC. The 364 registrants were a 40% increase over previous conferences. One person even came on the last day and paid the full registration ($300) fee in spite of being offered a discount, so eager was he to support Python.
This was the second attendee-run conference put on by the DC crowd. They organized it using the ultimate in iconoclast project management tools, a wiki ("the people's organizer"). MoinMoin was supplemented by a mailing list and IRC. Steve Holden, who introduced himself by saying "my name is not important", also said, "I'm responsible for this mess". Behind this classic British understatement lies a capable leader, a veteran of PyCon DC 2003. The organizers burnt the midnight oil for several months doing the thousand and one little tasks necessary to make the conference run smoothly: making this year's food better than last year's (including options for vegetarians), providing Net access within GWU's wireless policy, approving papers and scheduling tracks, running a registration Web site, scouting out low-cost hotels and restaurants, coordinating with the sponsors and more.
A few things didn't go off as planned. The paper review schedule wasn't coordinated with the registration schedule, necessitating the extension of the early-bird registration discount. Insufficient attention was given to the Open Space sessions and Lightning Talks. The GWU caterers didn't return messages as responsively as last year. Nevertheless, the show started on time, enough registrars were on hand to prevent check-in from becoming swamped, the speakers were easy to see and hear, the schedule (printed on a color printer) was easy to read and two rooms were available throughout for sprinting and BOFing.
The Python Software Foundation (PSF) was responsible financially for the conference and ran it as a fundraiser. It was extremely successful; the preliminary estimate I heard was "five figures". The reason for this was the unexpected surge in registration during the last month, due to Trevor Toenjes' marketing efforts, which netted a hundred more registrants than anticipated. The PSF now is deciding how to spend this money to pursue its mission: holding Python's intellectual property and keeping it freely available, supporting Python development and related open-source projects and promoting Python to the unconverted. Possible ideas include grants toward more action-oriented events (for example, non-conference sprints, software-project meetings) and promoting Python to project managers (mid-level managers who are somewhat clueful technically). But it will take some time to decide because the PSF is run by volunteers with their own day jobs. One of their ideas already has been implemented, though: this year's sprints were underwritten by the PSF. Guido's time machine strikes again.
Last year, Guido presented Tim Peter's "Zen of Python". This year it was on the back of everybody's T-shirt. I also learned about this little-known module in the standard library:
$ python Python 2.3.3 (#1, Apr 6 2004, 18:13:12) [GCC 2.95.4 20011002 (Debian prerelease)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import this The Zen of Python, by Tim Peters Beautiful is better than ugly. Explicit is better than implicit. Simple is better than complex. Complex is better than complicated. Flat is better than nested. Sparse is better than dense. Readability counts. Special cases aren't special enough to break the rules. Although practicality beats purity. Errors should never pass silently. Unless explicitly silenced. In the face of ambiguity, refuse the temptation to guess. There should be one-- and preferably only one --obvious way to do it. Although that way may not be obvious at first unless you're Dutch. Now is better than never. Although never is often better than *right* now. If the implementation is hard to explain, it's a bad idea. If the implementation is easy to explain, it may be a good idea. Namespaces are one honking great idea -- let's do more of those! >>>
Of course, this harkens back to the Import This! challenge of Python10 (2002). Now you can. this.py is a nice little ROT-13 puzzle for the YAPyH's out there. Those holding out for this to replace self someday, however, may be disappointed.
So what is a sprint? A sprint is a group of people hacking together on the same software project. Some sprints require a minimum level of experience; others are open to anybody who wants to get involved. Sprinters can contribute in a wide variety of ways, not only coding (new features, troubleshooting, regression tests) but also user documentation, developer documentation, squashing bugs, brainstorming design ideas, doing a teach-in, preparing promotion materials and so on. Having several sprint groups in the same room means that whenever you need help on some esoteric topic you can shout, "Is there somebody here who's an expert on ___?", and likely there is.
2003 had twice as many sprint groups as last year. There were sprint groups for the Python core, Zope, Twisted, Chandler, Plone, Docutils and Guido van Robot (a language for teaching programming fundamentals). One side benefit of sprinting is the opportunity to see Python luminaries at work, often on projects different from what they are known for.
I participated in the Docutils sprint. I had a longstanding grudge with reST: its inability to output an HTML fragment exactly corresponding to the input text, without the HTML header and style crap around it. David Goodger, Docutils maintainer and sprint coach, said this was a symptom of a larger problem: the inability to extract the parsed parts of a document individually for any custom application. He teamed me up with Reggie Dugard, a sprinter with no experience but a keen desire to get involved. I helped Reggie design a function to return the parts, and he later finished the implementation. Other Docutils sprinters worked on output formats, integration with Epydoc and MoinMoin and a syntax for flagging indexable entries in the text.
At least one sprint group already has their sights set on EuroPython and is essentially doing a revolving sprint. They'll reconvene at the next available conference and continue where they left off, then go to the next conference and so on. Some projects apparently are getting most of their development done in these sprints. That inspired those of us in Seattle to try to host a regional sprint later this year. Our wiki link is below if you'd like to participate.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- SuperTuxKart 0.9.2 Released
- Doing for User Space What We Did for Kernel Space
- Google's SwiftShader Released
- Parsing an RSS News Feed with a Bash Script
- Rogue Wave Software's Zend Server
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide