|
Speakers
Charlie Arehart Jo Belyea-Doerrman Tim Buntel Raymond Camden Christian Cantrell Sandra Clark Joey Coleman Sean Corfield Robert Diamond Michael Dinowitz Steve Drucker David Epler Joseph Flanigan April Fleming Ben Forta Shlomy Gantz Mark Gorkin John Hamman Hal Helms Simon Horwith Larry Hull Jeff Houser Chafic Kazoun Matt Liotta Tom Muck Rey Muradaz Nate Nelson Samuel Neff Jeff Peters Bogdan Ripa Neil Ross Margarita Rozenfeld Stephen Shapiro Michael Smith Geoff Snowman Jeff Tapper Dave Watts
|
|||||||||||||||||||
| 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | 32 | 33 | 34 | 35 | 36 | 37 | 38 | 39 | 40 | 41 | 42 | 43 | 44 | 45
Back To Interview list In this CFUN-04 Interview, Rey Muradaz discusses his talk, which has the intriguing title: "How NOT to Fusebox." Michael Smith: Rey I hear that you are talking on "How NOT to Fusebox" at CFUN- 04. So what *will* you be talking about? Rey Muradaz: In a nutshell, I'll be discussing the concepts to keep in mind when implementing Fusebox in a team environment. The presentation is mostly oriented towards team/project leads and managers, but anyone working in a group environment should be able to benefit from it. If nothing else, you might learn some lessons from the stories of my colleagues about how to dodge bullets. MS: Would those be the famous silver bullets? RM: No, just regular corporate bullets that will get you somewhere painful if you don't CYA or do planning. MS: For anyone who doesn't know already, what exactly is Fusebox? RM: To borrow from the official site (http://www.fusebox.org), Fusebox is a framework for building web-based applications. Fusebox got its name because the architecture is similar to the way an electrical fuse box is designed. A Fusebox application is made up of multiple self-contained circuits which handle specific areas of functionality. Each circuit contains handlers for fuseactions, and each fuseaction is made up of one or more individual fuse files which are executed to complete the requested action. It's currently in version 4, though many Fuseboxers are still using version 3 successfully. MS: It is just for team development or can single programmer shops get benefit from Fusebox? RM: As someone who does a lot of solo development, I can personally attest to the benefits of Fusebox even for those who are "playing by themselves". For independent developers, Fusebox brings (at least) two great benefits--ease of maintenance (you don't have to relearn your spaghetti code six months later when you go back to see your client), and code reuse (the fuses/fuseactions you build are often modular enough to be recycled from project to project). And of course, for teams, Fusebox makes the interaction of the players significantly easier and more effective, as well as facilitating functional specialization, so you can make the most of the skills of each member, as I discuss in my presentation. MS: So do you have to be a Fusebox shop to find the presentation useful? RM: Good question, Michael. The short answer is no. While this will certainly be useful to FB folks, anyone who's considering implementing FB will find my experiences a helpful case study to compare to their own situation. Beyond that, a number of the general concepts we'll be discussing apply to *any* team development environment, so if you feel like your team isn't the well-oiled machine you'd like it to be, you're likely to find something in the presentation to help get things on track. MS: But you *are* targeting manager-types? RM: That's the audience that will find this most immediately relevant, but if there's anyone who's a little further down the food chain who's been trying to get the powers-that-be to implement FB and is looking for some good arguments to bolster their case, they'll definitely get some help here as well. And if you've always hated FB, and want to come and shoot holes in my arguments for using the methodology in a team environment, you're welcome too. MS: Is there anyone who *shouldn't* come? RM: IMH(?)O, anyone coming to CFUN will benefit at least a little from my presentation. But seriously, what you won't get from me is hands-on technical information about using CF or FB. There will be no code samples in this presentation (at least none you'd want to replicate). But who comes to conferences for hands-on information anyway? MS: Yes, that is a very humble opinion there! Sounds like this session will have a lot of learning that you can't get from a book. Thanks for talking with me. |