Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

schwern (1528)

schwern
  (email not shown publicly)
http://schwern.net/
AOL IM: MichaelSchwern (Add Buddy, Send Message)
Jabber: schwern@gmail.com

Schwern can destroy CPAN at his whim.

Journal of schwern (1528)

Wednesday January 09, 2008
07:59 AM

What should I do for OSCON?

[ #35338 ]

OSCON proposals are due in a few weeks, what should I do? I tend to undervalue my past work, or that nobody wants to hear about THAT again, and worry that my current stuff is incomplete. So some more objective suggestions are welcome.

"Simple Ways To Be A Better Programmer" was popular so I'll probably submit a tweaked version of that. Or maybe split it up into two tutorials, one about "code" and one about "people". I'm always surprised at how many people find the refactoring and effective version control stuff so... new.

I'm tempted to submit something like "Human Interface Design For Programmers" to run through how the basic principles of interface design provide a way to think about what is and is not good style and good APIs. There's too much "this feels right to me" going on resulting in a lot of non-productive arguments that cannot be resolved.

Something about testing, I guess. I've been reading Steve Krug's "Don't Make Me Think" and I'm very impressed that he wrote a book about the web without mentioning any code at all! Thus it is universal and timeless (uhh, in web years anyway). I've been pondering how to do that with testing.

I'm submitting a talk to a govt workshop in Norway about how CPAN illustrates a way to coordinate without centralizing. A grand talk on how CPAN works and why it's so damned awesome and why everyone else keeps screwing up their attempts at reimplementing it would be nice.

An idea I got from Josh Schachter that wasn't accepted at Pgh.pm might be fun at OSCON, "That Sucked". It's a "how I learned from failure" discussion, but if nothing else it's nice to have a bunch of gurus up on stage talking about how they fucked up, just like mere mortals. I'd love to run a session of that.

Something several people have asked me to do is a specific tutorial for a specific sort of newbie programmer. That being a tutorial on how to go from writing single file programs to multi-file distributions and all the necessary complexities that go along with it.

Uhh, what else? Not a whole lot of Perl in there.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • One thing which surprises a lot of developers after they've been doing testing for a while is discovering that testing doesn't just make their code more reliable, it makes them a better programmer. Your functions tend to do less, but do it better. You learn to decouple things. You learn that your function with 13 arguments might be poorly designed. You learn how to write less code and get more done. You learn how to refactor safely. You design better APIs. You learn first-hand the pain of violating t

    • Yes, something that shows the symbiotic relationship between tests and coding and debugging would be useful. Not sure how to formulate that.

      I'd never heard of the Liskov Substitution Principle [wikipedia.org], but after reading the Wikipedia article it sounds like it's related to the protocol good neighbor principle "be lax in what you receive, strict in what you output".
      • Liskov is something that confuses a lot of programmers because it's often explain in arcane ways. Condider the explanation from the Wikipedia link you provided:

        Let q(x) be a property provable about objects x of type T. Then q(y) should be true for objects y of type S where S is a subtype of T.

        Well, that's true, but since most of us aren't computer scientists, it can be confusing, particularly since many programmers don't realize that classes are merely types and operators are merely shortcuts for met

  • I like the idea of a "That Sucked!" talk/panel/discussion group/game show.
  • I like the "That sucked" idea, although it might be better as a BOF. The Perl track (although this doesn't have to be in that track) only gets so many slots. :(