Some recent happenings in KARL-land:
- We are wrapping up a major improvement to the calendar tool. We introduced a concept of sub-calendar “layers” that can aggregate events from other communities. More visibly, we completely re-did the UI with a new Weekly view and lots of Ajax sprinkling.
- We also did most of the work to re-implement the entire form system using io.formish. (repoze.bfg.formish to be more precise.) Big reduction in code and test code. Still have a lot to think about on form controller patterns. Those going to PyCon can hear Chris’s recounting of form controller torture in a panel he’s on about form frameworks.
- Along with our friends at Six Feet Up as hosting partners, the KARL team is now operating KARL sites for five organizations. KARL has a unique approach to customization, the inverse of the traditional Zope approach. In KARL, a customization package is the starting point, and that pulls in the main software. Or, doesn’t. We just rolled out changes to thin out the size of each customization package.
- Chris Rossi has been working on a web interfaces to a number of admin activities, including integration with Six Feet Up’s Zenoss monitoring.
- KARL has a number of periodic admin jobs, for things such as processing incoming/outgoing mail, pulling in feed content, etc. To date we had been running these as cron jobs. However, we had cases where hundreds of crons got piled up. In the latest updates, we converted these to Supervisor-managed jobs. Risk involved, so we’ll see how it goes.
- And finally, we are going to work with Six Feet Up to install solid-state disks. Our initial test shows that an SSD alone, with no code refactoring, will completely eliminate our performance concerns on LiveSearch. As well as benefit other catalog-constrained screens, possibly. We’ll report back once we live with them for a while.
All in all, KARL (like BFG) is humming along nicely. Just to emphasize: KARL isn’t a framework. It is an out-of-the-box product with a strong opinion. By making such a deliberate choice to not boil multiple oceans, KARL gets to be very compact, very fast, and very stable.
That’s the key takeaway for people working on larger projects that have dynamic performance needs. Unless your needs fit into Product X’s bulls-eye, you’re probably better off not beating Product X into submission. Instead, we need an approach where assembling your own custom application, leaving out the parts you don’t need, is more feasible.
Not only is this a win for custom apps, IMO it’s actually a win for Product X. Instead of having reputation beatdown when it doesn’t excel at Every Possible Thing, it can just say: “We’re good at X. If you want X, you want us.” Then, focus scarce resources and reputation on being the best possible X.