I find myself utterly in love with the creativity of people who can use CSS. Because, hey, I'm happy with black on white and everything in outline form and utterly utilitarian myself, but that doesn't make for gorgeous. (My heart flutters every time I see someone take a Core 2 style, and make it really pretty, because that's what they're there for.
My heart also bounces with
glee whenever someone mentions that it's easier to customize styles here than they are used to, because that's what all we did was for. Seriously, ba-dump-thump.)
Styles still not done, though. On my list, once I'm no longer focused on open-beta-blockers and the styles usability bugs being reported to us, is, in no particular order:
- sticky entry module
- custom text module
- hooks to let layout authors easily insert custom modules
- segment and arrange the wizard properly (subheaders, etc)
- pulling in information that's already available to us in other places, to be accessible using S2 (la la la la)
The one thing that I'm finding out is how easy it is to manipulate the S2 backend. Perhaps
too easy. I find myself wondering whether my methods are hackish/messy and will cause problems down the line later on.
(I'm already trying to stop myself from trying to redo the grouping stuff as hashes with lots of automagic rather than arrays. Imagine being able to do
property string{} module_customtext_group { grouptype= "module" }; and have it pick up the title/name/opts automatically instead of having to do a
set module_customtext_group... Feel like I missed my chance on that one, now I have to do the grouping manually all the time. Bleeeeeh. (but it works, I'm happy with it))
But before that, business statistics, which I am working with, with
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
pauamma. We've got some kind of framework hashed out, now just need to figure out how to do the selects for data collection (I say "just", but since that's the entire
point of what we're doing... hah!).
The biggest problem with the SQL is that we're basically going to go through all the user accounts for data, e.g, account types. How to do this without bringing the DB to its knees? Suspect I shall need to talk to friendly neighborhood database administrator soon-ish.
Stuff like -- group by looks the easiest syntax-wise, but has to load everything in the database in one go, and that probably won't be pretty. bin/maint/stats.pl splits users into blocks, and iterates over each of the rows a block at a time. Or could you combine the two, split into blocks, and groupby within that block? Ponder, ponder, beard-stroke, etc. (Thinking out loud, will wander over to IRC and try to find a good time to talk at some point).
It's April 20. I'm so
excited. Also, feeling the lack of time. (I do wish it was faster to get into the zone, though. I usually sleep Saturdays away, which leaves only part of Sunday to do code, and there's so much to do. Grr)
![[site community profile]](https://www.dreamwidth.org/img/comm_staff.png){kind=small}
![[livejournal.com profile]](https://www.dreamwidth.org/img/external/lj-userinfo.gif){kind=small}