Congratulations to my friends Nate Westheimer and Kyle Bragger, who officially launched BricaBox today. I've watched BricaBox go through a few iterations and they have done a good job of both improving the platform and incorporating feedback from users - I like that they launched with a BricaBox dedicated to suggestions and feature requests and that it's a public conversation.
BricaBox gives you tools to easily create sites that incorporate different kinds of content from diverse sources. Big deal, that's called a web page, right? The difference is that BricaBox knows about the attributes of different kinds of data and is aware of display context. In other words, if you add an address to an item BricaBox will display the address as normal in a text listing, but can also correctly display it in a map context because it understands that the address has a geospatial component. BricaBox doesn't throw away metadata.
In addition to better understanding your data, BricaBox makes creating custom apps much easier. Say you want to create a contest site around a marketing campaign where people can submit, vote, and comment on photos as well as place them on a map. Ranking should happen dynamically based on voting. The design needs to be fully custom. Users need to be able to create accounts and sign in and you need different administrative levels of permission. The deadline is in two days. This would be very difficult to pull together, even from the various widgets available around the web, but BricaBox makes this easy. That's powerful.
BricaBox gives you tools to easily create sites that incorporate different kinds of content from diverse sources. Big deal, that's called a web page, right? The difference is that BricaBox knows about the attributes of different kinds of data and is aware of display context. In other words, if you add an address to an item BricaBox will display the address as normal in a text listing, but can also correctly display it in a map context because it understands that the address has a geospatial component. BricaBox doesn't throw away metadata.
In addition to better understanding your data, BricaBox makes creating custom apps much easier. Say you want to create a contest site around a marketing campaign where people can submit, vote, and comment on photos as well as place them on a map. Ranking should happen dynamically based on voting. The design needs to be fully custom. Users need to be able to create accounts and sign in and you need different administrative levels of permission. The deadline is in two days. This would be very difficult to pull together, even from the various widgets available around the web, but BricaBox makes this easy. That's powerful.
An important purchase for every young startup.
Fantastic.
Being a MySQL user has felt increasingly untenable. MySQL is a fantastic product but MySQL AB (the company) has done a stunningly poor job of leading the community. MySQL's amazing adoption rate has come almost in spite of MySQL AB's best efforts.
From trying to enforce bizarre takes on licensing, partnering with asshats, having core technology bought out from under them by their competitors, the awful enterprise / community split, to not addressing serious performance and concurrency issues. Seriously guys, we don't even need you to lead, just get out of the fucking way, we're excellent drivers.
As Don MacAskill from SmugMug wrote, ""support (fixing InnoDB's concurrency problems) is increasingly at odds with the business (releasing a commercial binary-only Enterprise release)."
Persisting as a MySQL user in the face of all this has felt a bit like (cliche warning) continuing to tune up my violin on the deck of the titanic. But, to mix a deadly cocktail of metaphors, just when I was afraid that MySQL AB might overdose on FAIL,
here comes Sun with the adrenaline shot and all i can think is thank fucking god. I've never been so happy to see Jonathan Schwartz's ponytail (and btw, doesn't Schwartz look just a bit like Travolta in Pulp Fiction?).
Totally clutch adrenaline shots to the chest aside, I'm a big fan of Sun, with the usual caveats. I believe they are seriously committed to open source and will bring some hard-core talent to bear on MySQL. They have some brilliant engineers (just two among many others) and the company has made a lot of changes for the better under Schwartz.
I expect some people will be unhappy about this, but lots of people whose opinion I value are happy - Brain "Krow" Aker, Mike Kruckenberg, Tim O'Reilly, Jeremy Zawodny, Kevin Burton, and Don MacAskill all seem optimistic. Jeremy Cole's reaction is also mostly positive and he has excellent specific suggestions for Sun.
From trying to enforce bizarre takes on licensing, partnering with asshats, having core technology bought out from under them by their competitors, the awful enterprise / community split, to not addressing serious performance and concurrency issues. Seriously guys, we don't even need you to lead, just get out of the fucking way, we're excellent drivers.
As Don MacAskill from SmugMug wrote, ""support (fixing InnoDB's concurrency problems) is increasingly at odds with the business (releasing a commercial binary-only Enterprise release)."
Persisting as a MySQL user in the face of all this has felt a bit like (cliche warning) continuing to tune up my violin on the deck of the titanic. But, to mix a deadly cocktail of metaphors, just when I was afraid that MySQL AB might overdose on FAIL,
here comes Sun with the adrenaline shot and all i can think is thank fucking god. I've never been so happy to see Jonathan Schwartz's ponytail (and btw, doesn't Schwartz look just a bit like Travolta in Pulp Fiction?).Totally clutch adrenaline shots to the chest aside, I'm a big fan of Sun, with the usual caveats. I believe they are seriously committed to open source and will bring some hard-core talent to bear on MySQL. They have some brilliant engineers (just two among many others) and the company has made a lot of changes for the better under Schwartz.
I expect some people will be unhappy about this, but lots of people whose opinion I value are happy - Brain "Krow" Aker, Mike Kruckenberg, Tim O'Reilly, Jeremy Zawodny, Kevin Burton, and Don MacAskill all seem optimistic. Jeremy Cole's reaction is also mostly positive and he has excellent specific suggestions for Sun.
Dear Jonathan (and Sun), please take Jeremy Cole's advice - I promise to buy Sun support and hardware.
Charlie, Nate, and I went to the ITP winter show last night. Charlie was talking about one of the projects, a game, where the player stands on a 4' x 8' stage and responds to instructions on a screen such as, "run in place" or some other gesture. To the player, it's a game with rewards for tasks, etc. What the player doesn't realize is that the gestures they are performing are not random but have a narrative sequence, specifically the story "Rumplestiltskin." Anyone watching the game (on a different screen) sees a performance of Rumplestiltskin in pantomime. This sounds like a (bad) metaphor for a lot of sites - a user thinks they are connecting with friends, but actually they're just driving page views and advertising revenue.
"Hey, have you seen backstabbr.com?"
"Yeah, total Rumpelstiltskin site."
"Hey, have you seen backstabbr.com?"
"Yeah, total Rumpelstiltskin site."
I thought I would carry the anti-stealth torch down into our development cave and write a few words about the technology we are using. Charlie asked me to be nice and I promised to try.
Charlie and I share some strong opinions about what we do not want to do in our business, such as being all league of super-secrecy assholes and slinging around NDA's. Similarly, our technical strategy can be defined as much by what we are not going to do as by what we are going to do. For example, we are not interested in re-inventing proven technology such as writing our own fucking compilers, xml parsers, or web frameworks. No. Please go directly to FAIL. We are not trying to win a nobel prize in web 2.0. Nor are we here to solve difficult academic problems. Academia will have to stagger along without our assistance for just a bit longer.
Make no mistake - our technology is going to be fucking great, but it's not our business, it's in service of our business. It's a vehicle not a destination. If we do a good job on the tech side, my hope is that most people will not notice or think about our tech. I hope instead that people notice the great content and can focus on what they came to the site to do.
So what are we planning to use? We are going to use a dynamic language to take advantage of rapid development cycles and prototyping. We're using a variant of the battle-proven LAMP stack which for us means Linux*, Apache, MySQL, and Perl (* the L may actually end up being FreeBSD or OpenSolaris). You can check out some other software components we're considering at ohloh.
"Why aren't you doing it in VisualBasic-on-Vicodin or Super-New-Lang++??" Because those languages suck and they don't scale. Obviously.
Regardless of what technology we choose, in the end it's going to come down to disk I/O, most often around the database. Our performance will likely be determined by how well we avoid touching the disk (through caching strategies) and by reducing resource contention through distributing the load across as many spindles as possible.
Our architecture is also based on a reliable template - lightweight caching reverse proxys in front, proxying to the heavier app servers, which in turn are driven by the databases. We will aim for a shared-nothing architecture - decouple everything, push the state out to the client, compress, minify, and cache the static content, eventually pushing it out to a CDN.
Far more important than our choice of technology is how we execute on the following:
Choosing a particular technology is certainly a very important decision, but I feel like it's a bit of a "color of the bike shed" question - it is just one component in a much larger strategy.
So back-seat drivers: welcome aboard! Exits are located here and here. Please argue among yourselves and once you all decide what color we should paint the bike shed, please let us know.
Charlie and I share some strong opinions about what we do not want to do in our business, such as being all league of super-secrecy assholes and slinging around NDA's. Similarly, our technical strategy can be defined as much by what we are not going to do as by what we are going to do. For example, we are not interested in re-inventing proven technology such as writing our own fucking compilers, xml parsers, or web frameworks. No. Please go directly to FAIL. We are not trying to win a nobel prize in web 2.0. Nor are we here to solve difficult academic problems. Academia will have to stagger along without our assistance for just a bit longer.
Make no mistake - our technology is going to be fucking great, but it's not our business, it's in service of our business. It's a vehicle not a destination. If we do a good job on the tech side, my hope is that most people will not notice or think about our tech. I hope instead that people notice the great content and can focus on what they came to the site to do.
So what are we planning to use? We are going to use a dynamic language to take advantage of rapid development cycles and prototyping. We're using a variant of the battle-proven LAMP stack which for us means Linux*, Apache, MySQL, and Perl (* the L may actually end up being FreeBSD or OpenSolaris). You can check out some other software components we're considering at ohloh.
"Why aren't you doing it in VisualBasic-on-Vicodin or Super-New-Lang++??" Because those languages suck and they don't scale. Obviously.
Regardless of what technology we choose, in the end it's going to come down to disk I/O, most often around the database. Our performance will likely be determined by how well we avoid touching the disk (through caching strategies) and by reducing resource contention through distributing the load across as many spindles as possible.
Our architecture is also based on a reliable template - lightweight caching reverse proxys in front, proxying to the heavier app servers, which in turn are driven by the databases. We will aim for a shared-nothing architecture - decouple everything, push the state out to the client, compress, minify, and cache the static content, eventually pushing it out to a CDN.
Far more important than our choice of technology is how we execute on the following:
- Data Model - the design of the database will be a major factor as will the degree to which we de-normalize and duplicate data for performance gains.
- Algorithmic approaches to optimization - one of my favorite hobby horses. Optimization is not only about optimizing the code that is the biggest bottleneck. Instead of spending an hour optimizing a loop iteration for a 25% speed increase (which, don't get me wrong, can be significant), realizing that instead of looping over an array and performing slow_ass_function() on every item, you can skip the loop if condition x is met and get a 200% performance increase. Code optimizations, while important, generally lead to modest performance increases, while smart algorithmic optimizations often achieve order of magnitude performance increases.
- Caching at every level - at the browser, static content on the server side, database, and in the code.
- Efficient content delivery - compression, minification, and eventually CDN.
- Cost-effective content delivery - we won't come out of the gate with F5's blazing (as much as I love them and can't wait until we legitimately need them). We will conserve our cash and ramp up more gradually by starting out with software-based load balancing.
- Testing and coverage - code quality should be more quantified than "uh it works for me."
- Development process - if our development process doesn't scale, we'll be just as screwed as if our architecture didn't scale. Communication, avoiding regression, measurability, and low-friction collaboration are very important. Maintainability is also crucial - keeping the codebase under control and trying to avoid trading instant (coding or feature) gratification for technical debt.
Choosing a particular technology is certainly a very important decision, but I feel like it's a bit of a "color of the bike shed" question - it is just one component in a much larger strategy.
So back-seat drivers: welcome aboard! Exits are located here and here. Please argue among yourselves and once you all decide what color we should paint the bike shed, please let us know.
