"Of Man, Women life and Computer Science".
Ok, so I dropped by at my parent's place to say "hi" - haven't seen them in a while now, living far away doesn't make things much easier but that's really not the point here - This is a NERD blog, let's keep it on that level.
So I said I dropped by at my parent's, and discovered they had a problem with Outlook express 6 in the office (it's a very small office, just the two of them working in there with one pc). Apparently, the mails once being sent refused to leave the "Outgoing mail" folder, for preferring the "Sent mail" one. After a short test, I realized that mails actually were sent out, but not moved to the "Sent mail" folder.
I enabled POP3 / SMTP logging (hey btw, didn't really know there was such a nifty functionality in there!) by Flagging the "Mail" option in the "Maintenance" page on the "Options" menu, but everything was working of course, because the mailing wasn't affected! So I started thinking about what could be wrong with Outlook. I googled for the same problem and it turned up that there is actually a bug in the .dbx file management that corrupts your email databases (the .dbx files), and it stated that those data bases could easily show off some problems if for an example Outlook (or the whole Windows) would crash unexpectedly. It stated that compressing the folders would clean up deleted emails (apparently Outlook doesn't do that straight away) , as well as fixing those problems that aroused. Also, it stated that Microsoft supports files up to 2 GB. Well, my parents had a 2 GB and something archive file for the "Sent mail" folder. Was that the problem? Of course it was!
Double-checking it by dragging the mail that still was in the "Outgoing mail" folder and dropping it in the "Sent mail" was quick and confirmed the theory.
Now, after this was fixed, I spent some time with my father and he suggested I could fix up the company's homepage (literally "it sucks"). I promised to do so, and already camed up with some ideas. Let me introduce you more into it :
They are running a merchandising brooking agency, oriented to ski-schools and sports in general (mostly winter-related like skiing for an example).
They would like to have a homepage where they could show examples of what they managed to produce. Of course, they would like to be able to add more as time passes by, and remove some if there would be too much (the current hosting company are true thievs, they pay 80 € a year for 200 MB!! But that is another story).
The way to present the images would be contextualized, meaning that you would have a list of
contexts to choose from and depending on which list you would had chosen you would get a set of images of products. Of course, one product could be posted in more than a group (being that different categories of customers may be intrested in the same kind of products or in products with special attributes), so it should be possible for them to "link" images to a specific group.
In short, the rational is that you could set up one group for each category of customers, meaning a set of pictures of relevant examples with specific attributes which customers from the category are mostly sensible towards.
Of course, I would like to do all of this in AJAX, and do it *now*. I don't want to learn how to install / use (surely helpfull) frameworks like Drupal / Joomla / blablabla, this is a too small project for making it too complicated. I can make my own library. Yes I know, I am masochist.
So first thing I camed up with a small prior-art of functionality to get an idea on how needs to be done. You know, use-case oriented design and such. The basic functionality groups are the following
- category management functionalities
- picture management functionalities
- grouping management functionalities
The next step is trying to get the logic that lies behind the functionalities described above "factorized", that is reduced to the minimal logic that is shared by all functionalites and that covers all the functionalites required by our use-cases. In geometry the same concept is referred to as a "base", meaning the minimal set of vectors which can produce all other vectors (all the vectors that are linearly dependent, that is), or a set of vectors which are linearly independent towards eachother. So what we are looking for now, following the "geometry" point of view, are the "basic logical units" which all the others (required by the functionalities) are made from.
Of course, this is not as easy as it sounds. And surely can't be achieved in one single step. Let's try. A first (very) high - level grouping is the following :
a) Working with lists - meaning adding items, removing them (in all three of the cases)
b) Editing contents - this could actually fit in point "a" as well, but considering that what we edit
here are set of attributes where each one mainly inherit from a specific nature (categories, pictures, groups in our case) it may be some of them requires some additional / specialized (or original) unshared functionality. Well to be honest there are two ways of handling this. The first way (the way we are going to do it) shows that editing a list's item is not a behaviour of the list itself but of the item of the list. So for an example you could have a list with alot of items each of them would have a different set of attributes to be edited (for example a list with an item apple,an item pie, an item car, and so on). If on one side this list is generic and very flexible, on the other hand it may turn out to be uncontrollable, and thus unmanage-able (did I write that correctly?).
The other way is actually to make the list item-specific by incorporating the item's editing into the list itself, and in this case you would have a list which could handle only one single type of items (the ones whose content is editable by the list itself). Now this kind of list is not flexible at all, but at least you know what you are working with.
c) Associating list items to groups - or, creating indexes, or, even better, creating a new list! out of other lists.
In my opinion lists are indexes. So we will call lists indexes from now on and forever.
Following this point of view, it turns out that the functionality we are requiring is based actually on three conceptual indexes :
- a Picture index
- a Category index
- a Group index
- a Picture index
- a Group / Category index
No comments:
Post a Comment