Octoboxy Project History
Pre-History
It all began when we wanted a custom photo gallery.
Towards this goal, we rebuilt the same site once each year for five years:
- Hand-coded HTML
- Adobe Lightroom galleries
- Drupal
- Wordpress + premium theme
- Wordpress + our theme
Making money is good, so on the side we built three versions of an eCommerce site, for a company that made t-shirts:
- Wordpress + free theme
- Drupal
- Wordpress + premium theme
By this point we'd seen that we were solving the same problems on both sites. We started thinking about a digital asset manager that could directly support our web properties.
First Versions
We called our project "Moonrise."
- 2.5K lines Python
- rendered photo assets using Photoshop
- indexed those rendered assets
The first working version was a glorified asset index. At the time we still thought exporters/importers to move assets into a Wordpress front-end was the way to go. But then it hit us: we were already using Django -- a web app platform -- for the developer interface on our glorified asset index. Why not build the whole frontend out of Django too?
We had no idea what sort of a monster project we were getting into.
- 12K lines Python
- photo gallery website
Some experimental projects happened here:
- Interlude: photo galleries for handoff to a publisher
- Interlude: color identity explored via Amazon’s Mechanical Turk
- Interlude: Lightroom plugin to maintain collections in our index
Making Ends Meet
The frontend and backend individually worked, but under the hood shared few connections. The next version was all about bringing them together.
- unified codebase: workstation and website
- taxonomy data structure
After this we began making smaller, feature-add versions, as opposed to megalithic redesigns.
- integrity testing
- more generalized model for a digital asset
- first version with wallpaper art
- documents are now assets
Starting with v1.8 we have a better idea when versions launched because each release got new wallpaper art, and image files have timestamps built in!
Fiindex
We were tasked to build a new, photo-based app to run lost-and-found operations at Burning Man.
The lost-and-found problem gave us opportunity to explore an excellent real-world use-case. Many parts of our system, most especially our taxonomy models, grew in complexity as a result.
Fiindex went through two versions:
- Fiindex v1 -- branched from Moonrise v1.9
- Fiindex v2 -- refreshed with Moonrise v2.1
Now Do It Better
Version 1.10 started out as a brush-up on the visual look of the system. Code-wise, it never deployed, but blurred seamlessly into a v2.0 where we rebranded the project.
Project Moonrise was now Octoboxy!
- 28K lines python
- website layer redesign
- branded: Octoboxy
Our system still had a lot of room to mature in every existing component.
- standardized cloud deployment
- multiple web properties on the same server
- improved background processing
- better sandboxing of faces
- new user model
At this point the core was more or less stable. It was time to tackle some bigger problems:
- eCommerce
- off-schedule improvements
- replication between deployments
- performance and stabilization
Third Time’s the Charm
To kick-off the next arc of our story we set out to fix every long-standing annoyance we had with system architecture.
Some of this was simple module renames with few semantic changes. But on another level, some whole modules got rebuilt. This became a megalithic redesign version, perhaps our largest one ever.
- a purifying light shown to every aspect of the system
- 36K lines python
New codebase was alive!
Now it became time to move in and try out the new features.
- "cloudshop" app: devguide and domains for sale
- new deployment strategy with OctoBase as a separate component
Check out our open-source spin-off: “OctoBase”
- Private app commission we can't talk about yet.
That brings us to present time, present space -- v3.3 is what's running this site.
Thanks for walking this journey with us!
~ the Octoboxy crew
