This month is going to be a busy one for me. I'm a newly minted father, and work is getting busy, but that's no excuse (if my wife is not reading this) to get some things done here around the site. Hopefully I can impress upon you a sense of where things are, and where I'd like them to be.
Right now, our big design flaws are:
- Themes. Themes add a decision tree when trying to see what htmlpage to choose from. It's very hard to determine which pieces of code are used where without tons of greping through the nodepack'ed xml files. It's also not super obvious which htmlpage choice we'd make when we have to fall back from the original choice of nodetype-displaytype-theme combo.
- The container system. We need an actual template system, and from all of the investigation I've done, I think it's going to be Mason2. This means either installing it manually or moving to Ubuntu to get it for free. Moving to Ubuntu means we have the advantages of doing that (newer perl, etc), and I've cut an exploratory branch. The downside is that I don't have a great way to test the app on a newer perl. Anecdotally it works fine, but I really need to expand the cucumber/watir-based stuff in qa/ to really have a great feel for it.
- The Everything::HTML namespace. If we can flatten the code down to not using globals that exist in a namespace (but rather globals that exist within an execution container), then we have a lot more code mobility and we can stop making increasingly hack-y choices. Part of this means pulling things out of Everything::HTML into Everything::Application. $APP, and $DB are perfectly fine because they don't change every pageload, and can be instantiated before the app does anything. In fact, they're the same inside of a script and inside of the webpage. However, whenever we do something in a script, we need to load up Everything::HTML and dummy up $USER and $VARS, and that doesn't make any sense.
- htmlcodes are too overloaded. Right now there is a huge combination between display subroutine-based htmlcodes, and things that we use as convenience subroutines. Once we move to Mason2, we get to place a lot of these inside of compile-able files for free.
- Nodes should be objects. I should be able to call $USER->getVars() instead of getVars($USER). If we can thin out and organize where a lot of our code lives, then we can get rid of the tons of duplication, and make it so that app is not as reliant on a dodgy execution context. Especially for things like maintenances. In the experimental pre-1.0 branch, they had a concept of nodemethods, which is where I'd like to go, but I don't want the code to live in the database. It's just silly to do so. We have a very open development process, and I feel very comfortable with templates, containers, htmlcodes, htmlpages, superdocs, and maintenances coming out of the database and becoming files on disk. It's going to be how we scale up to the next level of traffic, and get the most out of the resources that we have.
Okay, well, where does that put my efforts? I've been chipping away at the QA thing, and since I've decided on Mason, that lays out a lot of our architecture decisions to get there. My near term goals are these:
- Continue to modernize the platform. Perl-performance is very good right now, so I can focus on bridging some more of our technical debt. This means work on getting a good deal of QA stuff done. If we have 30 or so very good tests that create users, post writeups, vote on writeups, and send some messages I feel like that's enough to smoke test our app for Perl 5.14.
- Improve page-load performance. This means two things: Reducing the number of javascript files that get included, and putting them at the bottom, just inside of the body tag. This means playing with the preferences a bit, but it should be easy to tell it to not do certain things based on a JSON-based preference hash. I need to do some searching for inline javascript in places, but generically, I think it's mostly good.
- Play with the node-to-object thing. I still don't know what should live in the Everything::node namespace, but I'll figure it out after grinding my brain on it some.
How can I help? Great question. If you know Ruby, helping out with the cucumber/watir tests would be good. Also, by-hand testing of the QA environment in the beta branch is important.
Changes as I make them:
May 2
- Went through the entire codebase by the string 'HASH' and made it so that anywhere we are checking to see if something is a node (by "ref $NODE"), we instead use UNIVERSAL::isa($NODE, 'HASH'). This will detect its HASHiness, even if it is a bless()'ed reference. I even did it in places where it might not make sense, because I'd like to enforce that as a coding standard. uploadaudio,uploaduserimage, show content, settingsdocs, parentdraft, ednsection_globals
May 4
- Cleaning up the vote stuff, so that we no longer reference the invalid noVoteXP setting. vote (opcode), swapvote (opcode), exportable vars. Stripped it off of 3500 accounts.