Category: Programming

This morning I have made a decision about the development of GITI v2, I want it to be something that someone other than me would want to use, not that I expect anyone other than Guy to actually try to.
Version 2 – it looks so much less minute written out doesnt it? It should be. Version 2 of GITI is a major overhaul of the way GITI operates (thinks?). Everything is based on the command system now, which was originally developed as a way to lighten the work required for implementing navigation. One thing I have given consideration to is the way that everything just sort of flows together now in this version because of the implementation of the command system. I want to keep that fluidity and simplicity of design on the end-user side also. I have decided that GITI will no longer use static styles, an external style sheet will be broght in via the header document.
A few minutes ago I just really looked at version 2 for the first time, what started as a UI upgrade has turned into much more. The goal was to kill the framesets and move on to a more open space, well… that part is done, but it resulted in something unexpected, I now have space to play! I began noticing my newly found space a little while ago when I looked at the Add New page of the education module. That page doesn’t use a restriction on the table width like the other pages do, so it was just a wide document, then the new plan hit me. The next thing to go (after framesets), is visible tables. The document looks so much better without the need to be cramped, this gives me room to add a thing or two. One thing version 1 had been lacking in almost every aspect is the ability to do more than just add one item at a time and then return it to you. The complexity of the deprecated schedule module is an example of what can happen in GITI with a little imagination. The class schedule is automatically genereated for me when I enter the class information, I don’t have to propogate each day, or create an entry for every day of the semester, I just select the class days, choose the meeting times and submit it to GITI, everything else is taken care of. One thing about this particular module that is also very nice is that it doesn’t need to be given a database entry for every day that an event must occur, it is treated as a reoccuring event and GITI intelligently uses the information it has about the event to display it when appropriate and not when it isn’t. One more fine point which makes the schedule module an example of what GITI should be is the option to exclude days from a range of a reoccuring event without actually having to specify more than one range. Ain’t that cool? To the expert web developer/programmer this may seem like a trivial accomplishment, but because GITI is my first real project it pretty much thrills the hell out of me, and im proud of what it can do. Unforuntately, the other modules aren’t anywhere near that smart. The education module is about as close to as dumb as dirt as it can get, it cant even generate regularly scheduled assignments, a feature I have many times wished I had taken the time to write. I think a lot of this comes from the part where I actually need the education module functioning, but everything else is safe to let die. As I state that I must ask myself why I haven’t updated the To Do and Note modules, and even better… Why is Note and GITI Doc seperate? I should be able to combine the two and get GITI Doc to support independant documents that don’t need to be called from another module.
My simple modules remain simple, but they are too simple to be useful. In addition to their shortcomings, there is also the limit of usablity. What end user wants to write a date in the format 2005-09-01 when dating a note?

GITI is a pain in the ass to operate when I am not at home, this indicates that I rely too heavily on the admin side of things for it to work properly, consider revising.
The schedule tool is the paitient of ridicule today, I tried reactivating an invitation that I cancelled last night using the Interface, but it just isn’t possible. I am moving away from the raw unfiltered database lifestyle in the current stable (LOL!) version of GITI, so I actually have the chance for things to go hidden from me. I need to establish some sort of rules for how schedule should operate for ‘Once’ events (standard schedule), ‘Week’ events (events that repeat weekly for a period of time and ‘Invite’ events (not real events, invitations to an existing event, entered as a new event). There must be some uniformity and control to it. At the moment the project is about to fall on its ass because I have just been making notes about problems and not actually taking care of the problems.
I guess I should mention that I did finally get the invite moved back to its correct status (from CAN to NO), which in this case is a little weird, because originally that field was based upon whether or not an event was complete, but now NO = Accepted Invitation, YES = Completed event, CAN = Canceled. Its all a bit confuzzling (yes Guy, I stole your word!).

Today I for some reason decided I wanted to work on GITI v2 (maybe because I would like to use it in about 11 days), and I think I’ve finally decided upon a functionality. I am discovering tonight that I have learned a lot since GITI’s original creation, this includes about PHP, my usage and expectations of a personal information manager (PIM), as well as about GITI itself. That may sound strange, me learning about something I created, but its true. There are things I didn’t realize about why I did things the way I did at first, but now that I am diving back into the old code and looking it over again and trying to adapt it for v2, it is becoming much clearer to me. Tonight I managed to complete the transition to the database driven menu system (at least its core), now I just need to add all of the commands, and finally adapt all of the modules and their functions to use the new system. I think this will be a difficult task, but at the same time will make me more familiar with my own code. Hopefully along the way of correcting issues with the code that make it incompatible with v2 I might actually find time to structure the code so it makes sense. On my long-term plan is an intention to rewrite all of the v1 code so that it makes more sense.
I have been becoming very confused with GITI lately, there are so many new functions I want to add, then there is the burden of actually getting v2 100% running (burden for now, but once functional, im sure it will be more than worth it). I have given consideration to things like a ceramics module (keeping piece-by-piece info, firing schedules, etc) and even things as bizare as a mood-tracker that would affect a status indicator on my blog (dont know why anyone would ever need to know my moods?).
One of my main conceptual problems at the moment is the ability to access the course list. I can do it like I used to and it still be making it simpler, but I really want to take it a step beyond that. There is a side-bar that I haven’t used for anything yet in the class/education module that I could probably put a small class list in, as well as move the current “active class activities” include to. At the moment there is just so much going on in my mind with GITI as well as everything else, its getting hard to keep up with my thoughts.
The new journal module (previously itemjournal) is now fully functional and is coming in quite handy for those little notes, and thoughts that I need to throw down somewhere. In a way it is kind of like having a way to use digital post-it notes on a per-item basis. I don’t currently intend to transistion the old journal module to v2, it will die in v1, but I intend to convert all of the current content to the new module, then have the new module to take on the same name as the old module (for both its file as well as its table).
why am i going into so much detail here? its not like any of you are GITI developers or even care what I do with GITI, although I know what some of you wish for me to do with GITI.

Tonight while playing with MovableType (my primary blog engine/publishing platform) I realized something kind of interesting, without much effort or technical screwing, MT manages to allow fairly intelligent editing of a document. Months ago when I was creating some features in GITI’s background (creating them, sort of, but not linking them) I created a module called “GITI Doc”, which for now will take plain text (including HTML) and strip out things like carriage returns, tabs, etc and replace them with the appropriate code. This allows for direct copying from a word proccessor application. While this is useful for document storage, it doesn’t do much for document creation. I think it would be kind of cool to actually have GITI Doc to be able to do basic document editing things and eliminate the need for sending files back to my server when I am working on documents on systems that don’t belong to me (such as the UNCC labs). One possible solution to the problem itself is for me to always have one of my systems with me, another would be to have GITI or something else web-based that is already on my server for that task.
One concern that I have is that this type of thing already exists, in the form of “publishing tools”, such as MT, and Wiki sites. I don’t want to have to end up recoding something that someone else has already written, it would be kinda nice to find something that is fairly simple and already written and just integrate it with GITI (without mixing code). Another concern of writing it myself is that I won’t be able to create all of the functionality I want. I think it would be kind of cool to be able to have my documents have a table of contents (based on anchor names) created from the paragraphs. That is something that is more Wiki-like I believe. The third concern stems from one of my desired results of this utility. I would like to be able to publish my documents automatically to my website (once it is finished), but at the same time I look at all of my old papers and things and I realize that I really think badly of my own work, so once this thing would be completed, that part would still be 100% irrelavant.
I guess that brings me to something else… I really want to make a lot more stuff in GITI be availible publicly. One of the things I have been wanting to experiment with is having my schedule for each day availible via the web. Maybe not the detailed version, but a marking of availible/unavailible for most things, or like “In Class” when I am scheduled to have class time. All of the logic for most of these ideas already exist in GITI’s private parts.

My pet project GITI is back under the knife again, but I haven’t really let anyone in on the details of whats been happening, so here we go:
1. GITI now has the capacity to facilitate 1-way invitations to schedule events. I hope to add an outside functionality for people who know me to be able to file an appoinement/schedule request to request a slot on my calendar. In concept this seems like it will be easy, and I suspect it will be, same form, new method for submitting.
2. Invite contacts to existing event. this is a new feature that was created after seeing how simple it was to complete. This feature works on the backend, but I am still working on the details for the front-end and user interface parts.
3. System-wide journaling. This needs a lot of work, especially where the journals may become a little long, but I know have the capability to add journal information to each and every item in GITI. This seems a little odd on the surface, but it really helps with remembering what happened when and being able to get thoughts together, especially on items that are academicly linked.
4. Modules that are inactive DO NOT appear on GITI Summary anymore. I finally got sick of seeing empty boxes saying “no ____ to complete”, so now the unused little shits aren’t appearing. Because of this change I am also considering something else, which I will mention below.
ok, now that ive blabbed about what ive done, now its time to go into my plans for GITI’s future:
1. GITI Command – think like a small text box, at the base of the GITI v1 menu bar, or at the bottom corner of the footer include for v2. This functionality will take advantage of my over-anal addressing scheme that resembles an object-oriented programming structure. I intend to have the box read GITI addresses, and pass them through a SELECT/CASE structure. Im thinking about making it a double-pass possibility, so that I could use full GITI addresses (root.giti.schedule.add) if I want, or I can pass only the local address (schedule.add) and have it to ammend the interface address, so it comes out like this: “root.giti” + “$command”, where $command == “schedule.add” and the whole command comes back as $command = “root.giti.schedule.add”, which would equate to a valid case. Another thing I thought about for v2 is the ability to have it to know what module it is in, so I could be on a schedule page (lets say “schedule.view”) and have it to accept the command “add”, so then $command = “root.giti.$module.$command” or “root.giti.schedule.add”.
2. New GITI v2 navigation concept. I am having an extreamly difficult time keeping things straight in the v2 menu now that I am driving it from the GITI database. One thing I have given thought to is using the above mentioned GITI Command functionality to propel navigation, since all of the tables already include info for the GITI addressing structure. This will be a very firm step towards GITI becoming modular.
3. Change GITI’s menu ownership from ‘system’ to $user – this will ultimately result in a great flexibility in being able to ignore unused modules or turn others on at will. While this will require a slightly higher number of entries in the database, it will in the end make the thing more flexible. With the way I am conservatively writing GITI you would think I was working with a system with 2MB of RAM or so. Keep in mind, GITI still uses under 1MB of database storage, a very tiny database. The server and technology are capable of much more than I throw at them.
4. Modernize Schedule and Todo! – A lot of the new stuff for Schedule had already been written, I just haven’t implemented it, because im waiting to retire the old forms and things, and create them as GITI module files instead of as independant functionality files.
5. Rewrite GITI EMail functionality (this is unlikely to happen) – the GITI email stuff currently will log me into SquirrelMail in an insecure method, not very impressive, and I can also send email from a fairly featureless text-box composition form. This module needs to either be killed or majorly overwritten.
I think I might post some new screenshots soon, now that things work better. At some point I should probably remember to un-neuter v2 (put its scripts that do stuff back in place) so I can test it fully.