I had a lovely time at BARCamp. Like last year, it was a mind-expanding experience and encouraging on several fronts. This year we had more people, more energy, much cooler weather, a nicer venue (with clean bathroom!), and insanely large amounts of free food in addition to the obligatory free beer. For me, the best part was actually seeing familiar faces and getting to catch up with great geeks like Peter Chan, David Dalka, Peter Harkins, Justin Kruger, and of course the amazing Jason Rexillius. It especially rocked to finally meet my fellow DevChix, Jen Stander and Sarah Gray. I talked to a lot of interesting new people as well, like Rich the sound guy, Ben Collins-Sussman-SVN, Joi Podgorny, Conrad Albrecht-Buehler, and Atul, Aza, & Jono from Humanized.

Here are highlights from some of the presentations I attended:

Mass Customization: Next Generation of Software is Hardware -- Ziad Hussain

The dream is that ordinary people should be able to manufacture their own gizmos. We ought to have a Kinko's of fabrication -- a service that would allow users to design an item to be produced in full plastics and circuitry right away. Currently, some very interesting work is being done in producing cheap rapid-prototyping machines like RepRap and Fab@home. Geared to home users who can't afford commercial systems, these machines aim to democratize innovation.

Why most businesses fail, most businesspeople are miserable, and why you'll be different -- Sean Johnson

People seem to think that success requires either (1) working systematically for 50 years to get to the point where they can live the good life on a pile of money, or (2) hitting the jackpot on a business idea that rakes in the good-life piles of money right away. But what is the good life? Your dreams probably cost a lot less than you think. And in some cases, they are dreams you could be living right now.

Sean described ways to break free from standard business models in order to start happier, smarter companies. He discussed our tendency to put too much care on the validation of our peers as well as "VC money, a few hundred diggs, a write up on TechCrunch, etc." He encouraged us to, instead, design useful products that will help everyday people -- products that make money at every single sale.

Dynamic Mashups with RSS -- Aaron Williams

Kirix Strata is a data browser based on the Gecko engine, currently for Windows and soon to run on Ubuntu as well. Strata's aim is to make it easy to uncouple data from its context and render it usable. With a few clicks, Aaron demonstrated Strata's ability to import static HTML tables and RSS feeds into database form. He then showed us some database management features that remind me of Access and Excel. I was most intrigued by the Relationship Manager -- a GUI database editor which allows you to do wonderful things like visually join tables together.

Building Geo-Distributed Web Applications -- Jason Rexilius

Geo-distribution is a single app running simultaneously in multiple locations around the world. It could involve server clusters, network routing, multiple data centers/providers, or multiple carriers. Says Jason: Premature optimization is bad; ignoring your objectives is also bad. He gave us some interesting technical ideas on building web apps, encouraging us to think outside the database and leverage the right tools for the job.

Lisp -- John Quigley

John truly loves Lisp. I'm pretty sure his trembly, tender speech was the most passionate I've ever seen anyone get about any language. Lisp, he says, forgoes the syntax so you can get to the heart of the matter. It's a highly dynamic language that grows to meet your needs -- a programmable programming language for doing the impossible. Throughout John's presentation, he tried to help us see that Lisp was not some crazy language with a hideous syntax, but rather a gorgeous language with a very logical syntax.

The most interesting part was his explanation of the XML format and how it relates to Lisp. XML's tree design allows it to be both code and data, resulting in a very simple, flexible, and extensible tool -- the same is true of Lisp. An in-depth exploration of this idea can be found here.

For learning Lisp, John recommends Structure and Interpretation of Computer Programs, and two other books depending on your approach: Those wishing to take the practical path should read Practical Common Lisp (also available for free online). Those taking the academic path should read Paul Graham's ANSI Common Lisp.

DIY Beer - Tristan Sloughter

With beer in hand, Tristan gave us a beautiful talk on homebrewing.

Ingredients:

• Malts -- Barley that's been malted, sugar. Provides body, color, and some flavors (chocolate, coffee, smokey, etc)
• Hops -- A flower which provides bitterness (oils, measured in IBUs), hoppy flavor, and aromas like citrus and fruit
• Yeast -- A fungus which creates ethanol by eating glucose from the malt; provides subtle flavor/texture
• Other -- Irish Moss, insingglass, gypsum for clear color, Belgian candi, lactose, fruit, honey, coffee, spices, wormwood, pizza

Types:

• Ale -- Top fermenting. Temp 65-75, belgian ales up to 86. Most common & easiest.
• Lager -- Bottom fermenting. Temp 45-55. Harder to make and refrigeration. Mellow, crisp flavor.
• Lambic -- Uses wild yeast. You leave your fermenter open and let any yeast (such as from a barn) fly in. Dry, vinous, cidery, sour aftertaste (the taste of bad beer). You can actually buy "wild yeast" to make your Lambic.

Equipment -- You need a 4 gallon pot and a kit from, say, Northern Brewer. It's an initial $100 investment for the kit and another $25-40 for ingredients, but in the end you're only paying 50 cents a glass instead of $1.25 for beer of same quality.

The process of brewing beer is essentially boiling the malt, adding hops at some point (depending on how bitter the beer should be), plugging it with an airlock and waiting for 3-7 days. I was amused by the formula for measuring IBU:

(gallons of brew * 1.34) / (oz. of hops * Alpha Acid * (time of boil) / 2)

"Happy brew hacking," Tristan concluded. "It's just like programming -- have fun with it, try different things, get drunk."

Enterprise Searching -- Dieselpoint

A guy from Dieselpoint gave a nose-bleedingly intense and detailed talk on different methods of searching for data and why enterprise searching is such a complex problem. There were some major gems in his speech, though they were a bit hard to understand -- I wished the talk had been more simplified and BARcampy rather than Fortune-500-board-meetingy so that we could have all internalized it better. I was impressed by the huge role linguistics play in searching and the many creative ideas for improving search engine performance.

Groovy -- James Williams

Groovy is an agile, dynamic language for the JVM that can fully integrate with Java. It looks similar to scripting languages like Ruby and Python in the way they've pruned away a lot of the Java syntax. For example, printing Hello World is as simple as: println "Hello, World!" Groovy includes some extra features such as closures, dynamic collections, and builders, which allow you to build data types with a tree-based syntax. The point of Groovy is not really to replace Java but to give you an alternative to more quickly code prototypes, UI, one-off apps, and extensions.

Getting involved in FOSS -- Freddy Martinez

I was completely impressed by fellow underage kid Freddy and his impassioned talk on getting into open source. He made several points I can totally confirm, such as the importance of users groups and mentors. His mentor actually got him started in the community by saying: "I'm doing documentation work. Wanna help edit?"

How to protect your open source project from poisonous people -- Ben Collins-Sussman

In any community, attention and focus are your scarcest resources. You must protect them from people who distract, emotionally drain, or cause needless infighting. It's not just trolls who are problematic -- perfectionists can also derail forward progress. It's important to do something about those who complain without helping, insult the status quo, are unable to pick up on the mood or common goals of the project. Ask questions like: Is the person draining attention and focus? Is this dispute worth it? Is the person paralyzing the project? Is the dispute likely to finish soon?

Don't: feed the energy beast or get emotional. Do: initially give people the benefit of the doubt and look for the facts under the emotions. Know when to ignore or forcibly boot someone. Most importantly, address the behavior, and not the person.

Build your community on politeness, respect, trust, and humility. The community founders establish the culture, and in turn, the culture should become self-selecting. Pick a direction and limit your scope. When you're limited, it's easier to measure your progress, easier to get people to join, and easier to screen away people who shouldn't join. Example: SVN's scope was solely to create a compelling replacement for CVS.

Have well-defined processes as far as backporting bugs, accepting and reviewing patches, and admitting new committers. Document important design decisions, bug fixes, mistakes, and code changes. Have healthy code collaboration policies -- send commit emails and encourage email review. Do big changes on branches for easier review. Increase your project's bus-factor on components by spreading the knowledge and not allowing names in files.

Humanized: Tales from developing Enso -- Atul Varma, Aza Raskin, & Jono DiCarlo

The guys from Humanized really have an good grasp on interface design, and their talk was one of the most inspiring I've ever heard. There's actually a lot more to their Enso products than the unfortunate labeling of "Quicksilver for Windows."

One of their major concerns is the problem of modal interfaces. Modes are in their essence confusing because every time a mode changes, a user's habituated actions are no longer relevant and she has to break her train of thought to add yet another set of actions to her memory. Says Humanized, almost everything that frustrates users about interfaces is due to a mode. That's why good interfaces have as few modes as possible.

In Enso, users hold down a key to get into the universal quasi-mode. It involves visual feedback, but also kinetic feedback, which is more effective -- your brain remembers you're in that mode because your finger's down on that key.

Another thing Humanized believes in is building from scratch. They say the toolkit straightjacket, while providing consistency, kills innovation. You can't be better without being different. You can't different without taking the time to make your own stuff.

On design: People think the GUI is just picking a good shade of blue, so it's pushed back to the end. In reality, all programmers should act as interface designers right from the start. As soon as you design a program, you're designing an interface. To the user, the interface is the product.

On the curse of being a geek: No matter how good you get with computers, you still have to design your programs for normal people.