I'd be committing a serious foul if I did not admit, in public, that it could not have happened without my Organizing Committee: Amy Hatfield, Kevin Sheffield, Adam and Rachel Broadbent, Eric and Denise Sarjeant, Frank Salinas, and the membership of the
SW Florida Regional Technology Partnership, and our beautiful flagship university, FGCU, and the many, MANY great contributors we have in and around this community. They all worked tirelessly to make this event the success that it was, and I can't even express
my deep respect and unmitigated awe for them without resorting to barbecue, so that's exactly what I plan to do.
We'll let you know when it's on again, and we'll see you all next year!
Graphics people, you misspelled Dave's last name - it's Noderer, not Norderer.
Much as I like CodeZone, I have to disagree with Shawn a little bit - there are also tremendous advantages to planning, developing, posting and maintaining your own User Group web presence:
For one, it gives members of your User Group a way to get some experience. A good many people in my Group (swfldev.net - come visit!) come from other disciplines, or are involved from the enthusiast's point of view. For example, I've got an Oracle DBA, a senior
director at a Rails shop, several guys who are trying to break into the career, and other people whose titles can't be construed in any way as ".Net developer". This gives them an access point, and lets them 'be the change they wish to see in the User Group.'
As much as CodeZone is sufficient for User Groups, it's already done. With our own web project, we get experience, and an investment of participation.
Secondly, and following from CodeZone being done, is that we don't get to innovate our web presence
unless we do it ourselves. In CodeZone, each person can select from column A, and arrange the parts of it like so, but with our own app, if we decide that what our site needs is a comprehensive Virtual Earth map of wi-fi hot spots in our area,
for example, the only way we can have one is if we control our own site. And in assembling all of the different expertises we need to make our site happen the way we all want it, we build community. There's no reason a graphic artist can't come hang out with
the geeks and help make their site look sweet. And if you helped build it, you own it. You'll come back.
Look, one reason most of us wanted to be developers at all is so that we could build something we're proud of on the web. For us, this is that opportunity.
Finally, and this is where the rubber meets the road for me, special occasions. We're doing a Code Camp - THE DAY AFTER TOMORROW. And we have rebuilt, and reconfigured, our site to handle the registrations and speaker proposals, and the venues that are supporting
us, and giving love to the community pillars who helped us out, etc. We're STILL not done working, and registration closes today, but you can bet we're keeping that Code Camp site for the next time, and the next, and the time after that, 'til kingdom come.
CodeZone couldn't have handled that.
I still love CodeZone. But we're builders, y'all. Don't take that away from us.
"If standards are the same for everybody, where's the value add for an IE or a FF, etc.?"
It's a false choice.
The standards only have to do with how a page is rendered. If all browsers had to do was render pages, the question would be a valid one. But it's a false argument - there are all kinds of things that a browser does Other Than render pages.
From a presentational developer's standpoint, I don't care if default line height is 1.2 in one browser and 1.0 in another, because if it's a problem, I'll set line height to the explicit number.
No, the problem isn't default line-height, the problem is that when I make an explicit style rule, that it hasn't made the same result across browsers. Padding: 10px should look like 10 pixels of padding in FF, IE6, IE7, IE8, Opera, Safari, etc., not 10px in
FF and Safari and 20 in the IEs.
Also, pick one, and force everybody to switch. No reason on Earth I can think of that IE7 wasn't a critical update at release. What you do when you don't make people switch, is to allow people to be contrarian about the fact that they don't have to switch,
and then they just don't. That may allow one set of developers to preserve code base, but it kills everybody else.
That results in more work for the presentation layer people, which is why those people don't take you seriously. And that's sad, because the more your latest browser gains acceptance and market share, the more presentation people can be confident that the code
they write is cross-browser compatible.