The list of speakers for Ignite Phoenix is ready.

Be there.

One thing that seems often to come up in discussion of OO development is the size and number of your methods. I’m a fan of having small methods with matter-of-fact names, even if it means my class may seem to have “too many” of them.

Of course, “too many” is a fluffy concept. How many methods are enough? How many are too many? Abe Lincoln was once asked how long a man’s legs should be; “Long enough to reach the ground” was his answer. I’d argue that the right number of methods for your class is that amount needed for the class to get its job done.

That’s still not a satisfactory answer; one can inline code and drop methods, and the class will still work. But that comes at a cost; methods then tend to get larger, harder to read, and less cohesive.

A plausible approach is that if you think your class has too many methods, maybe your class is doing too much, and you need to refactor to more classes. Seems, though, that people resistant to a plethora of methods also abhor “too many” classes, and the reasoning in each case is roughly parallel.

In looking around for some opinions on this, I came across this remarkable ruby-talk thread from 2002: Small Methods – a ramble

(Side note: such threads are now extremely few and far between on ruby-talk. Reasons and consequences of that are a topic for another day.)

What’s interesting is that much of the argument for or against having many small methods is based on tools. Smalltalkers, using their code browser, found it easy to navigate among method implementation; those against the many-methods approach seem to find themselves manually scrolling through text files, and argue this is disruptive and tedious. This is fairly specious, given what any decent code editor can do, (Vim users: go check out rtags if you are not already using it. I imagine TextMate can do the same thing.)

In reading through the thread I found myself nodding along with Mike Thomas (msg #31114 ; “In my opinion, the editor is no ‘excuse’ for not factoring code properly.”) and Albert Wagner (#31115, “it is an attempt to reduce the visual complexity, so as to be able to grasp quickly what is going on in a method; i.e. , condense a snippet that is not duplicated anywhere else into a sort of language shorthand.”) And I like the “Watership Down” syndrome idea.

Naturally, one could argue that having large numbers of methods and classes just gives you more, not less, to track . Except you aren’t going to be storing all those methods in your head; a big win for OO design is that you don’t have to keep everything in your brain, you need to track a limited scope at some particular level of abstraction or detail. One should be able to get a clear, reliable high-level view of an app by looking at the high-level code; when you need detail, you jump to where this or that is implemented.

It isn’t until message #31214 that testing is mentioned. This is from 2002, before TDD and BDD really took hold in Rubyland. Smaller methods seem naturally to come from TDD. Or, conversely, if you have large, busy, methods they are almost certainly hard to test, or test correctly.

Interestingly, Brian Marick, who knows better than most about testing, comes out in favor of (somewhat) larger methods (#31170). His reasons are quite interesting, following earlier observations on communication, expressing intent, and how different tools influence thought. (And now I really want to know more about Stanley Fish’s “affective stylistics”.)

David A. Black follows with this observation:

Clarity is such a vexed thing. I believe people who say that they find Perl code clear. (I used to find it reasonably clear – I’m a little out of the loop right now :-) I also believe people who say they find it opaque, and I believe those people when they say they find code in some other language clear. (Which is to say, if a non-programmer said Perl was opaque, that wouldn’t “count” in the same way.) Clarity is annoyingly relative; it seems that what you find clear is what you’ve learned to find clear, and/or perhaps are cognitively predisposed to find clear.

I’m curious as to what others do, what heuristics Rubyists (or not) have for determining method size, number of methods, size and number of classes, and so on. What are some good resources for this?

What’s the method for clarity?

From 2007; re-discovered via reddit

Programming: You’re Doing It Completely Wrong

There’s this reFresh

but there’s also this reFRESH

The latter is apparently celebrating their 50th anniversary. Perhaps the “creatives” should try a little harder to find a more creative name.

The deadline looms for submitting proposal for an Ignite Phoenix presentation.

I confess I’ve not yet submitted mine. Party that’s because I’m in NYC more preoccupied with my friends and family than the usual geekitude, but also because I want to be sure I pick something I can cover in a crisp, informative, entertaining manner.

I have some ideas, and one in particular that is leading the pack, but I thought perhaps I should do some crowdstorming (or maybe it’s braincrowding or outbraining or socialcrowding or …) and ask whomever may be reading this:

What Should James Present at Ignite Phoenix?

Note that the talk needs to be short, as in ~5 minutes.

Wednesday, July 23, 2008

Social stuff: 6:15pm

Presentations: 7:00pm

Boulders on Broadway
530 W Broadway Road
Tempe, AZ 85282

Google map: http://rubyurl.com/SKAU

See http://www.refactorphoenix.com for details

This months general topic:

Relevance Linking Outperforms Popularity Linking; Arkayne.com Has The Numbers

Find out how technology like Amazon EC2, Django, and Ruby On Rails are pushing the performance of semantic link relevance past basic popularity ranking.

Paul Kenjora will explain how the Arkayne.com widget is leveraging these technologies to deliver a 2% – 80% click-through on suggested links for blog posts.

It’s going to change the way bloggers promote articles and its all getting started right here in Phoenix.

---

Refactor Phoenix is a monthly non-denominational gathering of desert geeks, dedicated to the open exchange of information in a casual environment.

We meet on the 4th Wednesday of each month.

If you’re a (coder|programmer|software engineer|hacker|developer), Refactor Phoenix is for you.

For more information, please see

http://www.refactorphoenix.com

or contact me at

james@happycamperstudios.com

(602) 714-1148

The $451.24 Denon AKDL1 Dedicated Link Cable

Right up there with the BiC Kugelschreiber Cristal Kugelschreiber Cristal schwarz review

Next Thursday, July 10, there will be the first Web Design & Development Meetup, at the Coffee Bean & Tea Leaf (16211 N Scottsdale Rd, Scottsdale, AZ 85254. That’s a block south of FLW.)

This might be especially interesting for those Refresher who liked the original Scottsdale location.

Plus, unlike Refresh, this gathering may actually focus on Web design and development instead of Web marketing, branding, and networking. (The latter are still all useful topics, just not the things I had hoped would be core to Refresh when I, with several others, got it rolling.)

I’ve noticed an increase in the use of folks adding a leading ’@’ character to user names (and even real names) in threaded discussion boards, mailing lists, and E-mail.

I don’t think any of the uses I’ve seen were meant to aid any sort of automated text processing; it appears to be a bad habit that perhaps makes sense on Twitter, but is merely line noise elsewhere.

Please consider: No Twitter Litter.

Wednesday’s Refactor was great. I want to thank Ray Niemeir and Brian Shaler for their terrific presentations.

Ray’s talk was filled with special insights; I was really struck by his observations on bubbles, and looking for The Fizz.

Brian did a great job explaining how to work with CS3 and AIR, and there was a ton of useful info on getting rolling, and especially with using a local database. Check out the code for the talk here.

At the end of the meeting we did another round of Lean Introductions, and this time the tag was to offer up a current trend and a topic for future Refactor.

Here’s what came up (trends and topics mixed together):

• JavaScript applications (e.g., in browsers or browser derivatives)
• Mobile computing
• Virtualization
• Spore creatures and the ideas underlying their creation and behavior
• Cloud computing
• Game programming
• Rhino
• Social computing & networking
• Scalability
• The realm of add-ons and “social media” sites
• Open Social

Mike Wolfson has offered to give a talk on mobile computing; that’s slated for August. Thanks, Mike!

If you have something you can give a talk or demo on, please step up. It needn’t be long; 10-15 minutes works fine. It needn’t be formal; a walk through of a project or some code would be great.

And be sure to keep the last Wednesday of each month free to catch the Valley’s tech talent sharing their insights and know-how.

Brian Shaler has stepped to and offered to give a talk/demo on an Adobe AIR desktop application at Wednesday’s Refactor Phoenix.

Brian knows his stuff; AIR looks quite cool (though this Kubunu dev is saddened by this set of sys requirements ); Boulders has beer and pool. So you have no reason not to attend.

In unrelated news, James feels partial shame at occasional outbursts of frustration concerning perceived geek lethargy.

The next Refactor meeting is this Wednesday, June 25. No one has offered to give a talk or demo or anything, and I don’t particularly want to have to whip up yet another talk, so there will be nothing formal that night.

The last time there was no particular presentation it ended up being me and five other people. Two of those others never (that I could tell) came back for another Refactor. Hooray for casual conversation.

It is, of course, disappointing to think that the only way to get deveopers together after work is to offer up some pre-planned “edutainment.” It’s even more disappointing to think that maintaining a reliable stream of worthwhile presentations will be tedious monthly chore of either goading people into giving a talk or assembling one myself.

I can assure you that the latter just ain’t gonna to happen, and I’m not fond of pestering people, either.

An interesting related phenomenon is the turn out for the Tempe Nerds lunches. Clearly folks are up for socializing, just not so much when it’s after work. (Side note: As best I can tell, Refresh Phoenix still gets a good crowd. I’ve stopped going since it become overly focused on Break Out Of Your Cube! and How To Be Entrepreneur 2.0! I have a completely unproven conjecture about the different social needs of Web designers and marketeers vs. developers and hackers.)

A primary goal of Refactor was the social element. I was really hoping to get together people who would otherwise not meet. A second goal was to get people introduced to technical topics that might be a bit outside their day-to-day endeavors. I think I’ve failed on that one, while Tempe Nerds appears to fulfill the first goal (though the mix seems more Refresh-y than hacker; however, there were actual developers at the lunches). So, all in all, the cost/benefit ratio for Refactor is questionable.

Ignite Phoenix is open for submissions

Drop by the submissions page and think about what you would do with your five minutes.

Please be sure to check out the presentation guidelines as well.

I had www.ignitephoenix.com up for maybe almost a year now since April of 2007, with nothing more than a plea for someone to step up and basically make it happen. Well, Jeff Moriarty and Roger Williams have taken steps to make Ignite Phoenix a reality.

It looks like it will be happening in August, at the offices of Jobbing.com (they host the monthly Phoenix Social Media Club meeting).

The best place to get info on all the details is www.ignite-phoenix.org

Subscribe to the RSS feed, and follow announcements on Twitter via @ignitephoenix.

What’s needed now are talk proposals. The idea is to have two sets of short talks; short, as in under 10 minutes; short, as in pecha kucha short, as in no time to be bored or boring.

Suitable topics can be almost anything. No sales pitches. But see here for details.

In between the talk sets there will be a break for discussion and socializing.

Learn more about Ignite in general, or see details on Ignite Portland, Ignite Paris, Ignite Boston, and Ignite Seattle

Spread the word, and thinking about what you would talk about if you had five minutes and an audience.