Class trudges along. I’ve already got another test coming up in EET 257 on Monday, a mere two weeks after the last one. I think I’m picking up the information on Boost Regulators (they let you step up an input voltage to a larger value) without using a transformer and are used in a lot of common electronics like cell phones and PDAs to power low-current “high” voltage circuits (12V-24V) from a low voltage power source (batteries anyone?). We’ve also been studying Buck Regulators (these step down a voltage and you get more current) this is basically what the power supply in your computer is doing. It takes the 120V rms from the outlet and switches it down to ±12V and probably uses a linear regular (or another switcher?) to produce the 5V lines.
In any case I’m finding the material easy to absorb, unlike that damned collector feedback common emitter amplifier. Other than that all my other classes are going well. We’ve got another phase writeup due in 430 and although this section was pretty light (we even finished a week in advance) that makes it so much harder to get everyone motivated to get started early (I for one seem to think its going to be no work at all and I want to wait until the last minute).
On the work front I’ve finished the foundation class(es) for the calendaring app I’ve been writing. I made a big logic change midway and that’s basically what took up the most of my time. Today I was able to model my academic schedule (in data structure format) and commit it to the mySQL DB and then pull it out in its entirety later. That’s quite a big feat when you figure that I’m pulling data recursively from 4 different tables and combining them into a fairly complex data structure. The real amazing thing is the amount of abstraction layers I had to write. I wrote the final one today which I aptly called “XtremeCalendar”. It implements some ideas I had been toying with and makes managing calendars thru the API a lot easier.
The next big task for me is to be able to pull data using my API and then format a calendar and present that data in a calendar-ish format. That’ll all be done in a separate HTML Calendar class that will depend heavily on the HTML Table class from PEAR. Once that gets nailed down (and I get way too familiar when date algorthms), I will probably write an ical_calendar class that will output the data structure to an iCal compatible format.
Later on I’d love to write an extension to the Calendar class or a seperate class altogether that will pull data from an iCal file into my data structure (shouldn’t be too hard since I based it off the iCal/vCal format. If everything goes according to plan I’ll have an app that can take on PHPiCalendar :). Most likely I’ll just write an administration thingie that will allow you to upload an iCal file that will be parsed into the data structure and passed thru my Calendar class into the mySQL db. That would probably be the least CPU intensive way to do it since the script wouldn’t have to decode the bastard every pass. Wooooo way too much rambling.