A major theme, concept, or understanding here at “Ruby Fringe”http://www.rubyfringe.com amongst folks seems to be owning what you do. Not that it’s expressed this way – but I think a lot of what we’re discussing here comes down to owning your work, owning how you spend your time, owning your mistakes and growing from there. From Fail Camp to discussion on sales and business relationships to networking and how you spend your time, to the slogan on the back of the conference tags, “Ask me about my startup!”, this is about owning what you do and consciously running with it.

Quite frankly, it’s exhilarating. This is not a normal programming conference.

Zed Shaw literally just rocked the house by playing into his own sequencing software and winging some lyrics, guitar and harmonica.

So far the overwhelming blowout talk here was Nick Sieger’s of Sun Microsystems. He’s got the whole thing over here on his blog, with a complete discography of the great music he played.

While listening to this great primer on the history of Jazz and discussion of core concepts, some ideas collided in the back of my brain. I’m pretty familiar with a lot of it, but it’s been a while and I’ve been stuck in some of the same genre/idea ruts. I started thinking about some things I’ve been working on for my band, things I want to try, some of the concepts Nick was discussing and illustrating by playing us music and I suddenly had an explosion in my head and a near-complete song idea! I actually drew out a few bass clef staves and wrote some sheet music notes real quick to try when I get back home (or in a music shop on Queen St. on the way to the after party.).

Nick, in half an hour you just made up every single JavaOne conference I attended ;-)

First two talks were great (Jay Philips on Adhearsion, Dan Grigsby on hacking the market, basically). While on different topics altogether, both were plugging a common theme here: keep coming up with new ideas, set out on your own, and if you look for the niches and cracks you can fill in the market, you can exploit/hack those efficiencies to your advantage and really make it as an indie with a few friends and not work for the man, so to speak.

Which we already knew (or at least hope) is the case, but it’s awesome having these folks sharing their experiences, ideas, and methods of doing it themselves. It’s basically a lot of people who have that kind of “hack everything” mentality that is the focus of the HOPE/2600 folks and apply it to the question, “how can I set out for myself as a hacker and make a living?”

Also: the memcached talk was a totally excellent geek-out on caching.

Next talk is called “Living on the Edge,” and it’s about what’s going on in Merb edge development, but you see how it fits the broader theme by title.

There’s a great community here in Toronto, looking forward to meeting some New Yorkers and seeing if we have this kind of community back in NYC and Jerz.

More to come.

I’m going to break up the Rubyfringe blogging for a minute to stump on a topic that’s close to our hearts here at Zetetic.

When it comes to building a new web application our designing decisions related to user accounts should be driven by a common paradigm: a user object should represent a real life human being. That user object can then be associated with any number of other entities. Fun! Flexible!

You can see this at play in our time-tracking app Tempo: every user has only one account, and can be associated with any number of other people’s projects. It’s a simple many-to-many relationship, a social network relationship really, and it seems like an obvious and straight-forward design decision — but that’s not how a lot of web applications work.

Many really good systems out there have made the decision to build their web applications around companies or organization and not people. From there, people are users in the company (as in “assets” or “resources”), and are walled off from other people in other companies using the same web application. In some cases they even log into different sites! This can require a real flesh-and-blood human being to have multiple accounts, one for each company they work with that uses the system.

This paradigm can provide some conveniences (although none of them unique to it other than the feature of company-as-corral), but it can cause issues in the real world when flexibility is severely limited by the “company” wall. If Tempo followed this paradigm, our users, many of whom work with many different companies, client, and subcontractors, would be at a real disadvantage having to maintain numerous accounts and log into different sites just to summarize their full monthly billing!

Many folks who are independent subcontractors or consultants love to use Tempo because it allows them to work with many customers and partners without having separate logins. They can log in and report on all their time from one place.

Social networking applications, however cliché it is to laud their innovation nowadays, are really paving the way when it comes to recognizing that organizations and companies are just groups of people. They are defined by relationships between people, not a fixed hierarchical structure where the organization is the center of the universe and people are bolted on ad hoc (or grown like leaves on the company tree)!

Consider how useful it would be to add groupings or private channels to an asynchronous messaging system like Twitter. Everyone on Twitter has their own account. Allowing people to join groups would be easily implemented (scalability issues aside). Now imagine Twitter being based on organizations primarily, and having to have one account for each organization. Ugly, right? And unnecessary.