I suck.

I keep getting frustrated when dealing with silly issues like SVN not working. Gotta just push past em.

Slow progress

Through a combination of conflicting priorities (work, health, etc.), stumbling blocks in my methodology, choices of technologies, and occasionally laziness, I have made little progress since my last post. I’m going to take a fresh crack later today and either blow through some stumbling blocks or do an end run around them to do something else productive.

My biggest problem is the most basic of pieces. I had never envisaged the building blocks of my project being so hard. At first I thought the building blocks would be easy and the later stuff hard. This is what it’s all about though. This is where the important stuff is. Now that I’m in the thick of trying to create things that are easy for other people to use to build complex visualizations, I begin to understand. I have more and more respect every day for the great ones like Tufte who understand all of this stuff in and out and the people who use his and other works to create the wonderful applications and visualizations that we all use.

ServiceProxies

As I was working on the service layer for the API I realized that I was making things more complicated than necessary. My chosen MVC framework includes what is known as a ServiceProxy class. Instances of this class are registered with the main application management class (the Facade) and are used to control access to data in any form. I was implementing a single ServiceProxy class which would detect a users choice of service( Flickr photos, google email, local address book contacts) and instanciate an internal reference to a separate service class and make calls to that class. This causes two problems: it allows only one service to be used at a time; it requires an extra layer of abstraction. I am now refactoring this functionality so that developers using my API and framework will simply create an instance of the ServiceProxy class and customize it to provide access to their services. As the class was intended to be used 🙂

Thread barriers and Flickr

Tonight I made an update to the engine that brings me a big step closer to an at least theoretically sound API. I worked on my interfaces for service calls to internet based data suppliers. To test them, I implemented a sample service class based on Flickr Images. It makes a call to the Flickr API and pulls any images tagged “capstone” from my account, adds them to a local data store in the form of ImageDataTypeVO’s (one of the base data type classes I will be providing), and then feeds them to the 3d engine for rendering into a flock (I’m currently skipping the whole relational and behavioral sections of the engine for testing purposes).

One interesting problem I came across was when the Service class should notify they engine that it had data. Unfortunately if I just said render the data every time an image was found, it might double render some of them. So I used what is known as a thread barrier to control when the notification would occur. I learned of thread barriers from a co-worker recently and this was a good opportunity to implement one. The basic idea of such a thing is to keep track of a number of tasks (threads) and only do something once all of the tasks are finished. As I found this extremely useful, I plan on adding this to my framework and making it a documented feature of the API.

My Personality according to analysis of this blog:

Typealyzer.com

INTJ – The Scientists

The long-range thinking and individualistic type. They are especially good at looking at almost anything and figuring out a way of improving it – often with a highly creative and imaginative touch. They are intellectually curious and daring, but might be physically hesitant to try new things.

The Scientists enjoy theoretical work that allows them to use their strong minds and bold creativity. Since they tend to be so abstract and theoretical in their communication they often have a problem communicating their visions to other people and need to learn patience and use concrete examples. Since they are extremely good at concentrating they often have no trouble working alone.

Flickr API

Tonight I completed some work towards getting a useful interface for adding data sources. As I have been blocked for a bit on getting an external module integrated, I attempted to use my current service interfaces inside the main appliction to connect to Flickr and download a set of images.

I was able to successfully implement the Adobe Flickr API for Actionscript and use it within my own service proxy class to query the Flickr API, download a set of images, and store them in my own Image value object. The next simple step will be to actually use those objects to generate objects using the 3d generator.

Break from API: Time spent on flocking and 3D

I took a break in the last two weeks from working on the API (because I was hurting my head a bit) and worked on flocking and 3D manipulation instead. I took a look at the old flocking models I learned of in my undergraduate work and worked out an adaptation of them for 3D space. This flocking model traditionally employs three factors: cohesion, alignment, and seperation. Cohesion keeps objects together spatially, alignment determines how closely they mimic each others paths, and seperation pushes them away from each other. In addition to adapting each of these factors to a 3D environment I added an extra factor. This extra factor draws all of the objects to a central location independent of the flock.

My intention for flocking in Paradigm is to allow users to break their data groups into discrete sets that flock together (or not) in the way the user defines for them. By adding the extra centralizing factor, the engine can keep related sets of data near a defined location in 3d space. The other three factors will determine how dispersed the objects are and how similarly they behave. In theory a user could set all factors to 0 and allow the children of the flock to roam freely, or restrict them all to stay within a “foot” of each other.

I also did some work on learning about and implementing methods to texture and light the objects in the environment. I now understand how to load most colors, shaders, and textures onto objects. Implementing these will give users and developers more control over the look and feel of their visual representations of data.

Update on API

Over the last two weeks I have been on the bench at work and have therefore had some time to work on my capstone. Not as much as I’d like as I’m still trying to get back into the swing of things, but at least some. I’ve put maybe 12 (out of 20 scheduled) hours into the data API portion of the project and must say that I’m a little disappointed in my progress. I’ve made some excellent progress in establishing my object types (video, photo, text, etc.) and how people will extend them to create their own. I then started in on the actual mechanism by which my plugin authors will be able to create new services for Paradigm.

My vision is that a data plugin author will be able to implement a set of interfaces that I have written to authenticate and request data from whatever service they wish. This data would then be stored locally in the appropriate data format through those interfaces and accessible to the other portions of the Paradigm engine. The graphical plugins for Paradigm would then tell the engine how to format that data.

Initially I had intended to allow users to simply drop what is known as a SWC (a compiled SWF, or Flash movie) which contains their plugin’s “classes” into Paradigms plugin folder and have the engine use them. There are two ways to do this. Inside the SWC, the user could simply have their classes free floating or they could integrate them into a “module”. I did not want to go the module route at first because it increases the complexity for plugin developers. However, it would appear that my chosen programming environment, Flex, and language, Actionscript 3, do not allow non-module classes to be loaded at run-time.

Unfortunately I did not anticipate this and this is therefore a bit of a setback. I now have to learn more about module use before I can move forward with actually writing the data api service engine. I will be posting more about my adventures in modules soon.

New work schedule

Develop, document, and implement data API’s (20 hours)

Design and develop relational data manager (16 hours)

Design and develop behavior manager (16 hours)

Design and implement a visualizer component (20 hours)

Design and implement a basic user interface (12 hours, partially finished already)

Design and implement data model modification UI (8 hours)

Debug entire application and review systems abilities (20 hours)

Formalize documentation of API’s and application user interface (16 hours)

Prepare and deliver capstone defense (12 hours)

Total of 140 hours of work

At 8 hours per week (max I think I can promise to myself with Cynergy work and personal fitness training on the plate, but might be able to do more) This will take 17.5 weeks, or approximately 4 months. I might thus be able to finish up by the end of February.

I’m going to officially start this schedule this week. I was supposed to start last week, but urgent business project got in the way.

Still not done…

and I have been duly smacked for it. I’ll try to make some progress this week despite work.