Tutorials bonanza

Some of us are graduating soon so I thought I'd put some stuff together for us to keep out collective hacking skills together. For the past year or so I've been amassing a collection of tutorials from digg, of which I have actually gone through very few. Some of them are general computer science knowledge, but most do represent technologies which we have touched upon this semester and I thought I should share them in order to provide those of us who will soon be having a lot of free time something to keep our technological chops in good condition.

Top 12 Ruby on Rails tutorials


5 books every programmer should read

The Ajax toolkit framework for Eclipse

Over 140 Ajax tutorials

Python Tutorials (only because I know absolutely nothing about Python)

Computer Science Cheat Sheet

54 general programming exercises

Keep those coding skills up to snuff graduating class no matter what you're doing from here on out.

Echo2 and the REST Architecture

I was really impressed with the REST architecture as outlined by Phillip today. Especially with the ease of the way in which modules interact via HTTP get, put, etc commands. Instead of the big black box program that it was before splitting up the system into smaller black boxes which communicate via such simple procedures seems infinitely easier than the hidden communication channels that you had to hunt down before. When I first started out developing for Hackystat I felt like it was this big black doorless house that I was stumbling around in the dark looking for a way in. Eventually some of the hidden doors revealed themselves through the wood paneling, or I jumped through some windows, but under the rest architecture its only a bunch of outhouse shaped buildings that have clearly defined paths between them. From a developer standpoint this is infinitely better than how it was before.

I'm have a probable entry point for my TimerTask to intrude upon the Hackystat architecture, and once its working will finish the alert portion of the module. I still need to find a way to set a different time interval at which the emails get triggered for testing purposes though.

Working on the UI as I write this.

Peer UI Programming

The data gathering bug, which resulted in me gathering data for only my single user instance instead of gathering data for every user and consolidating them in a single daily project data instance, was a result of me not being logged in as the administrator of the project over which I was trying to gather data.

When logged in as the owner of a project the mail and all its formatting seems to work fine, although I will need more data in order to verify this. Right now have switched all efforts onto working on the alert implementation of the emailer which includes its own timer task implementation because the default Alert interface was dependent upon the default timer task, and therefore the default emailer which does not support html emails. Speaking of which I still need to figure out why the email does not display properly when viewed in gmail. As Robert says it is probably the external stylesheet and .gif links embedded. I will have to find a way to circumvent this eventually. With the TimerTask I need to figure out: 1) How to implement a second differential instead of a single set hour each day, 2) Where the alert makes calls to the actual Java code.

So the final to do list for the remainder of the semester looks like this:
1) Alert
2) Resolve Email issues
3) Fix the UI data gathering issues
4) Persist the data gathered from the UI

Wow I might actually finish this thing on time.

I have no idea what I'm going to talk about tommorrow.

Yay.

Houses that Open and Ghosts in the Shell

The open house event was fun and informative since up until now I've never been privy to any of the products and services that they provide to the DoD. Models and Simulation, Autonomous Agent systems and Data Mining are all things that I love reading about and hope I have a chance to work on at some point later, if not for a company then certainly from a personal research perspective.

An autonomous agent system for Hackystat would be interesting. Sending the agents out into the web, to crawl and collect data, which they send back to the central Hackystat repository. Would be cool to see in action. I especially liked the microwave emitter demo and their dispersion algorithm. I still would like to do something modeling systems of objects in their relationship to one another. Like the swarming or flocking presentations I've given in other classes.

Would any of it work for Hackystat, who knows. I haven't even taken an AI course yet =\. Remind me to ask the guys in the lab for a good AI book.

Still still still trying to track down the dpd bug. I think it might have something to do with the fact that sending a single project instance to the data gatherer returns data, but iterating over all the projects owned by a user returns the indication that every project has zero data. Hmmm. The interface I don't think is a bug rather than I need to implement the request hooks instead of just trying to pull the data from the main UI java class. Should shoot for getting this done by this weekend.

Golgotha Tenement Blues

Finally finally finally finished the html template after reducing the code to almost a quarter of what it was originally. I was making it much harder than it actually was and as a result of trying to gather too much metadata regarding the daily project data I revealed how little I actually knew about how the data was structured. Once I actually set out to see how the data was actually structured the answer to my formatting problems fell out immediately. Took way too much time figuring this out so now I really need to bust ass with regards to the UI. Hopefully I'll be able to figure out the data gathering problems quickly.

HTML Templating and Daily Project Data Collection

There seems to be an issue in the gathering of the daily project data with regards to gathering data for all user for a given day, as opposed to just data for the user logged in. Right now the data is gathered via the DailyProjectDataCache, which I'm thinking might not be the right implementation for this project. When the Daily Project Data instance is returned from the cache the code calls the getDrilldowns method, which returns the drilldowns for the indicated day.

What I don't understand is why the getDrilldowns method uses the 'User' parameter. Right now I'm only able to collect data for the user logged in, but when the DailyProjectDetails module uses this method and invokes it in the same way through the data cache, it is able to grab data for all users.

I've dug through almost every Sdt extension of the Daily Project Data abstract class and can't see ANYWHERE that the user parameter is used.

If anyone knows the answer please let me know.

I should be finished templating the HTML code tonight but I need all of the data from all users to populate it, or else the whole purpose of this project is meaningless.

Structure Review and Project Status of the ProjectStatus Module

I can say with confidence that the back end of the program is basically complete, with the exception of a few bits and pieces here and there. Most of the remaining back end has to do with the alert implementation.

What now remains to be done has almost primarily to do with the UI. The data flow of the UI and exception throwing pages. The alert enabling and the email entry. Persisting the email addresses entered and checking their validity also needs to be addressed. This persisting of the emails via JDOM and verifying their validity is probably the largest portion of the project that still needs to be addressed.

With the completion of the Java1.5 conversion complete i'll have more time to concentrate on these issues.

Class Cast Exceptions and Java 1.5

Well i'm slightly happy to note that all of the frustration earlier today was due to the Java 1.5 conversion. The whole time I had been getting a sneaky ClassCastException which didn't show itself until I put some output code directly into the DailyProjectDetails class. The idea was that the getDailyProjectDrilldowns method is supposed to return a List of a List of String[] (blog won't let me post angle brackets due to html rejection). However it turns out that this was only happening for MOST of the SDT's, with some of them returning god knows what. When the code would hit these SDT's which did not return the expected Types the code would bomb without any indication why.

Thus all efforts are now turned to the Java 1.5 conversion (which I should have been spending more time on anyway). After all it turns out that the SDT's the code was bombing out on were the ones i'm responsible for... =-(

Drilldown Issues

I wish subversion had a browser that cached all of your old versions, so that you could browse through your old code in case you changed something that you needed but didn't necessarily want to revert everything back to that previous version.

I didn't have a problem early getting the daily project details summary strings, but for some reason i'm having a much harder time getting the drilldowns. I can't tell if i'm trying to look at the wrong day's data, or if there is no data associated with this user for this particular day. Or if i'm just messing up on the data gathering side. Or maybe the project isn't getting loaded correctly for that particular user when hackystat gets deployed.

Now i'm just venting. I need to keep track of these issues and eliminate them one by one. If I could even determine that there is indeed data to look at before I try to manipulate it.

Use Cases and Data Compartmentalization

Meant to blog yesterday but fell asleep trying to think of what to write.

I refactored the package structure to resemble an MVC design architecture since I was having trouble separating the view from the data collection. I wanted to have the View able to call the sendEmail method while passing the information it had gathered from the UI (such as email addresses) without needing to touch the data at all. I refactored and moved files around to reflect the data flow more accurately, only to discover after doing so that this is not MVC after all.

At the moment all the view does is gather data from the UI and call some sendEmail method in the mailer. The mailer gathers this data from the view and calls some getEmailBody method in the data manager which returns a String representing the email body. What the mailer doesn't need to know is that this String getting returned is completely made up of html tags. In essence the mailer shouldn't have to touch the data at all either.

All of the data collection and formatting should only be occuring in the data manager. The only thing the data manager may need is the User name, in order to get the names of the projects owned by the user. These projects with their associated data, and the html template page, are the only things the data manager should require (I think). It should take care of all formatting and only need to return a String, which the mailer cannot discern from any ordinary emailBody String.

I think this method of comparmentalizing the data should work out well.

Oh yes and I really need to write a detailed use case for this new module design in order to eventually finish the UI.

Pair Programming and Summary Grids

The Pair Programming last night was extremely helpful. Much thanks again to Austen. Some of the items we discussed included:

1) HTML tag replacement and recognition. To dynamically generate the HTML page the module needs to recognize the specified HTML tags and replace them with the title followed by the data from the drill down lists.
2) The difference between how the summary strings are formed as opposed to the drill down data.
3) The typing of the List returned from the summary grid containing the drill down data and how to access it.
4) Issues regarding whether every sdt implements its drill down data uniquely.

Some miscellaneous things we went over included unit testing, proper java styles, and especially shortcuts and hotkeying things in eclipse. Which is just the greatest thing ever quite frankly.

This accessing and instantiating the drill down data remains the hardest thing left to do in the project. The remaining items to finish include:
1) Finish the UI/fix the UI bug(s).
2) Finish the new timer task implementation.
3) Figure out why gmail doesn't like linking to external style sheets.
4) Persist the entered email addresses and boolean "enable" value using JDOM.
5) I also need to update just about everything on the google project website.

At the very least I need to have at least a manual email generator which displays the drill down data in a formatted email finished by next week. I'm not sure what to package for the release this friday though.

3/3 - UI Work

Trudging through the UI, learning more and more jsp tags and incorporation of java code into the jsp pages in order to dynamically name the variables which the command will be pulling data from. Ultimately i'm moving in the direction of working on Persisting the data with JDOM which i'll hopefully get to today.

Going proves slow though.

Mood: Resilient