We Need Space

There’s a question I get asked a lot.

“How do I find a space to hold my user  group meeting/event/conference?”

I’m not a professional event planner but I’ve got some experience in this area after having planned three Barcamps and helping out with Philly ALT.NET, Conshohocken.rb, and some of the other (un)conferences in and around Philadelphia.

Unfortunately, the answer to the “how do I find space” question is still, “depends on who you know”. That makes things really hard. Unnecessarily hard.

What I think the city, and arguably other cities could use, is a central booking site or directory where free/cheap spaces are listed, along with their availability, contact information, caveats/requirements, and equipment. User group leaders would then be able to easily check availability and cross reference their needs. Projector? Check. Room for 30? Check. The list of data points to collect for each space wouldn’t be that long either:

Address & Room Number
Available Dates/Times
Equipment (Projector? Vending machine?)
Food allowed?
Cost
Contact / Resource
Adult Supervision required? (Does the space maintainer have to be there?)

Where would all the space and location data come from? I imagine this could happen in one of two ways. A hard way and an easy way.

1) The hard way: Find a grant. Put someone on this full time. Have them schlep around the city meeting and greeting everyone with a partially available conference room or classroom.
Pros:

  • Full time curation. More likely to stay up to date.
  • Some money and wiggle room for basic marketing.

Cons:

  • Funding. This isn’t really a money-making venture.

2) The easy way: Borrow the weworkinphilly model. Open the site and let folks with access to spaces add theirs to the listing. They would be in charge of keeping availability data fresh and being (or delegating) the main point of contact.
Pros:

  • Ready to go out of the gate.
  • May fill out spaces faster.

Cons:

  • Data more likely to go stale unless everyone maintains their spaces.

Regardless of how a directory like this might come together I think it would be a big benefit to user groups, free or low cost conferences, and ad hoc meetings. Making it easier for people to find space to talk and collaborate benefits everyone, however indirectly.

There are plenty of goatchas I’m forgetting so I’d appreciate feedback!

Build Your Own AppHarbor & Notes

On Saturday, April 9th I gave a presentation for building your own AppHarbor-like git push deployment system for .NET projects. I tried to screen record as best I could. The audio came out quite good except that I didn’t repeat a few audience questions so you can only hear me answering some anonymous chatter. The screencast is presented below along with a zip file containing my step-by-step notes, my sample rakefile.rb build script, and my sample post-update hook for the git repo. Much thanks to Alex Hung for hosting the video for me!

Philly CodeCamp 2011 on Vimeo.

Associated Notes & Files: Gitserver Files

Announcing MVCMelee!

MVC Melee

Today my friend Sara Chipps and I are announcing the creation of the MVC Melee! The contest will be a 48 hour competition where teams of ASP.NET MVC developers will have 2 days to come up with a rad web application idea and put it in action. The public will judge. Prizes will be given. Bragging rights will be secured.

What the what?

MVC Melee is based on the Rails Rumble which has been going on for a couple years now. It’s a wonderful competition which has produced some amazing web sites. I tried last year to get a team together but couldn’t make it happen. After the rumble was over I wondered why we didn’t have a similar competition in the MVC space? Sara concurred and the MVC Melee was born! The Rails Rumble folks have been very supportive so far which has been great!

How’s it work?

The rules are pretty straight forward. We’ve launched an informational site with the details of the competition, FAQ, etc. Naturally there is a twitter account too. Teams should be 1 to 4 people and any resources you use for your site should be free. The constraints are very heavily based on the Rails Rumble rules but modified where applicable. This is our first time out so we have to be a little conservative about what’s allowed to be used. Future melees may be easier to open up to additional libraries such as home brew MVC frameworks.

Lets get it on!

We anticipate registration will open around May 1st so start thinking about web site ideas and team candidates! Aesthetics and usability are part of the judging criteria so think about having a designer on the team who can sling Photoshop and CSS like a ninja.

I’m REALLY looking forward to see what folks can come up with in 48 hours! Help us spread the word and join the melee!

Free Events: The No-Show Problem

This past weekend Roz Duffy, Kelani Nichole, and I hosted our second Barcamp Philadelphia at the University of the Arts. It was, by just about any measure, a success.

One issue we’ve struggled with over the past two years is whether or not to charge an entrance fee. The spirit of barcamp, in one sense, is a free exchange of ideas. Anyone is able to come, anyone is able to speak, and everyone can afford it. Because it’s free.

The downside of organizing a free event is that someone has to pay for it, especially if you want to provide some basic amenities like food, drinks, and additional nice-to-have’s like t-shirts. This stuff isn’t cheap. And finding sponsors willing to pony up their hard-earned revenue, especially in this economy, isn’t easy.

This year’s Barcamp Philly was a pretty hot ticket. We worked really hard to make it a great event. In fact it was so popular that we “sold out” of tickets a full month before the date! A waiting list quickly started and eventually we re-opened registration to let those folks who waited patiently in the doors. In the end we had about 365 registrations and folks were still writing to ask if they could come or be wait-listed. We didn’t want to turn anyone away but we also had to contend with capacity issues at the University of the Arts based on our estimates.

On Saturday we had about 260 registered users attend. (give or take) Don’t get me wrong, I’m THRILLED with that number. And to be fair, we had about 20 or so legitimate last-minute cancellations. That still leaves about 80 people who were no-shows.

That’s unacceptable to me. Planning these things isn’t a science. We have to try and decide how many t-shirts to order, how much food to buy, and how many classrooms and spaces to reserve. Then we have to ask other people to pay for it. When you don’t show up we end up with extra and waste. Not only that but we reserved a space for you that we could easily have given to someone who probably WOULD have shown up but couldn’t because you didn’t tell us you weren’t going to come.

I don’t want this post to sound angry because I had an amazing time yesterday and I’m proud of the event we put on. But this particular scenario annoys the heck out of me.

For next year I’d like to consider some alternative incentives for attendance. Randy Shmidt had a suggestion this morning that was echoed and validated by Becky Clawson:

Let people sign up for free. And if they don’t show, charge them.

This would effectively keep Barcamp Philly a free event and at the same time motivate folks to get out of bed and attend… unless they want to lose their $$$. Can you tell Randy has some experience with alternative pricing models?

Don’t get me wrong. Barcamp Philly 2009 was very successful and I couldn’t be more proud of the results. I just want to find a way to improve on what we’ve got and shoot for accurate planning figures!

I’m curious to hear what others think of this idea and hear other suggestions.

Hornget, Why I think it needs binaries

Today I learned about the Hornget project which is lead by Paul Cowan. Hornget attempts to solve the elusive “package manager for .NET” problem by creating a packager system for open source .NET projects.

An interesting choice the Horn project team made was to keep the repository (not the design pattern, the actual place where the project meta data is stored) building from source and eschew binary packages altogether. Paul actually makes a very compelling case for this choice in his presentation at DSL DevCon.

While I agree that having the build from source option available is a good idea, I don’t think it should be the default option. Or at least, I think that a binary install option of equal weight should be available.

The Horn dependency and package system is based, at least in part, on the Gentoo Linux Portage manager. When Gentoo first showed up on the linux scene I started using it as my linux desktop and server of choice. The Portage system has awesome dependency resolution and listed the latest and greatest versions of packages like KDE, Gnome, and all the STABLE versions my favorite applications. I highlight stable because that’s what I like to use – the stable version – especially for important or production situations.

The thing I hated about Gentoo was waiting for packages and their dependencies to compile. Most small applications built fast. Most large ones, like x-org, Gnome, and KDE didn’t. The process usually went something like this: Start build, go to bed, wake up the next day and hope there were no build errors.

Now to be fair, there are no packages in Horn that will take all night to build. However…

log4net Build Failure
log4net Build Failure

This is what happened when I tried to install log4net from source. The build failed. This happens more often than people may think. And it’s why I think a “install from binary” option is needed.

Pauls argument for building from source via his presentation goes something like this:

  1. All developers like to use the bleedingest edgiest version of a software package so we all download from trunk and compile.
  2. Because of this, we have dependency issues during builds because the source from a dependent package may be out of date. Thus, that package also needs to have the freshest source pulled and built. (ie, dependency checking and resolution)

I agree that these are issues. But only when building from source. The question then becomes, do most developers use the latest trunk builds of open source projects like Nhibernate, Castle Windsor, and MVCContrib?

Having spent a lot of time on both the MSDN and ALT.NET side of the developer camps, I’m comfortable saying that a lot of people don’t want to build from source. They don’t want to use the latest bleeding edge version. They just need the package to work stably and reliably. Horn pulls the source from the repository itself where the project is hosted. (so far only svn is supported but git is on the way) There is no gateway to be sure packages are stable and feature complete. Just because something builds doesn’t mean it’s ready to be tagged as the next version.

This raises some more questions which I haven’t been able to answer myself yet: Who decides what packages are inside of Horn right now? Presumably Paul and his team are playing things a little close to the vest right now, adding prominent open source projects to their repository, and making sure they build correctly.  And that’s the right thing to do. But who decides when the next version of a package is ready to be included in the repository? Does the original developer team have a say? If they commit each night and the Horn build “checker” doesn’t fail does this mean that a new build of a project is available each day? In the future, will I be able to add my own open source project to the Horn repository? Will I have any control over how often it’s versioned?

I’ve actually been thinking a lot about this problem over the last couple of months and I think I have a solution which I’ll detail in a future post.

For now, however, I really do wish the Horn project team well. I’ve already joined the Google Horn Developer Group to follow the goings on and will hopefully be able to inject some opinion about adding binary support.

Give the Horn project a look. It very well could be the future of .NET package management for community and open source projects!