Research Log of Web Science Students

Computer Science is not simply programming

Posts Tagged ‘ProjectriX

Consolidating halfway

leave a comment »

We won’t be submitting our paper to PCSC.

For one, Google App Engine failed us.

Second, the tests we conducted were inconclusive. I also had doubts over it. So what if our system/integration testing was successful? That only proves that we coded the system well. But that doesn’t prove anything about the effectiveness of our learning system, which tries to posit a better alternative to learning.

I guess somewhere along the way I lost track of the motivations for this project. Well today I am setting out with a renewed focus.

While I’ve been talking about all this time how our app will be an alternative/supplement to formal learning, now the project will assume a futuristic setting: Informal learning has now been accepted, and the debate now is whether using Hardwire is better than using a scattered set of online software to learn. This is where the Hardwire becomes a mashup. It brings together all your online learning tools under one hub.

All the efforts now of our testing will go to proving that learning using Hardwire’s features is more effective than say for example using Diigo, Google Docs separately as part of conceptual learning framework. The test we thought of this afternoon is simple: Simulate the learning process in Hardwire and see the results. Specifically, a teacher makes a course ( a set of modules with prerequisites among them) or a module. Student learns that module and uploads his/her work products. Student has/her projects assessed via Projectrix. Also happening in parallel is another student learning a topic via his preferred method using software on the web. After this the students will be gaged as to who learner more using what method.

To be able to measure this, Sir Rom said that a set of parameters or some metrics should be used to assess learning using online tools. My first reaction was, “Where would I get those metrics?” to which he replied that I had to look for a paper that actually does that.

That’s that for the testing and paper writing.

Another goal of mine is to have Hardwire somewhat ready for production. Here are some of the features/improvements I’d like to work on immediately:

1. Refactor code smells
2. Pulling resources from social bookmarking sites and via Drag and Drop functionality make a course/module.
3. New layout.

Advertisements

Written by Jose Asuncion

January 19, 2010 at 1:09 pm

Posted in Hardwire

Tagged with , ,

Google App Engine: NoClassDefFoundError on run

leave a comment »

Everytime I try to run my project, I get the following error message:

Exception in thread “main” java.lang.NoClassDefFoundError: com/google/appengine/tools/util/Logging at com.google.appengine.tools.development.DevAppServerMain.main(DevAppServerMain.java:82)

What could be the problem? I’ve tried reinstalling Eclipse and reconfiguring the Build Path for a couple of times now, but no avail.

Thanks!

(This is actually a repost from my stackoverflow post, just in case this will get crawled on by people who also develop on GAE.)

Written by falloutkee

November 28, 2009 at 1:07 pm

Pulling Google Spreadsheets data to Projectrix

leave a comment »

I’ve been searching for existing implementations for this until I encountered David Burger’s post:

http://david-burger.blogspot.com/2009/03/display-google-docs-spreadsheet-data-on.html#comment-form

It made me hungry (okay, lame) but I’ll try it out in a bit. This might solve our problem of sending a request to Google Spreadsheets to return an ATOM feed. I also found another way, albeit more complex, using JSON (which I don’t yet have any idea about):

http://blog.uxebu.com/2009/04/30/jsonp-for-google-spreadsheets/

Another task pending is to try out the Jericho HTML parser (as suggested by Jeune).

Will update you if either works. 🙂

Written by falloutkee

November 25, 2009 at 4:16 pm

Rubrics using Google Spreadsheets

leave a comment »

We almost gave up on using Google Spreadsheets for the rubric creation–until our last project planning. What we were planning to do is to create our own rubric creator using GWT–but I think there’s no way for us to implement the collaboration function (similar to that of Google Docs) given the timeframe.

So now, this is our current plan on how to implement the rubric:

(1) Make Projectrix create a new Spreadsheet — Done by Dan before.

(2) Insert rubric headers — The new rubric will include a scale for the top row (incrementing from left to right) and any additional row will be a new criterion.*

(3) Make Projectrix access the ATOM feed of the Spreadsheet (like in our sample rubric: http://spreadsheets.google.com/feeds/list/tigT9uc4x8-o7e4d7NrVd2w/od6/public/basic)

(4) Use open source ATOM parsers (here’s a running list: http://java-source.net/open-source/rss-rdf-tools) to parse the ATOM feed

(5) Insert the parsed text to the empty table** in Projectrix.

* Google Spreadsheets API provides steps on how one can update Spreadsheet rows (follow: http://code.google.com/apis/spreadsheets/data/3.0/developers_guide_protocol.html#UpdatingListRows)

** The rubric table in Projectrix is entirely independent from the Spreadsheet–the only role of the Spreadsheet is to provide the rubric table with its contents. But without the text from the Spreadsheet, the rubric will actually work–albeit defeating the purpose.

Projectrix won’t save the contents of the Spreadsheet until it’s published. We’ll be doing the same action selections as iRubric (Create, Modify (for unpublished rubrics), and Duplicate).

My priority task is to find out solutions for points (3) and (4). Will update on which parser we’ll be using prolly later today or tomorrow.

Written by falloutkee

November 24, 2009 at 6:27 am

Projectrix + Gadgets (a videocast)

leave a comment »

Dan and I discussing Gadgets (by Pamela Fox)–a way to pull XML data from Google Spreadsheets.

Written by falloutkee

October 20, 2009 at 8:56 am

Posted in ProjectriX

Tagged with , , ,

Introducing Drop.io

with 2 comments

I must say it is REALLY HARD (note: ALL CAPS) to look for an online repository that is free, has an open API, good support, and an active user base. Good thing I discovered Drop.io (which I hope to be my last pitstop in my race (search) for a repository for Projectrix.)

Simply put, Drop.io is like the Bit.ly of file sharing–upload your files, and it will create a short URL (customizable) of your files. Pretty neat, eh?

Here’s a rundown of what I like (and kinda not like) about Drop.io:

It’s API Client is in Javascript

– That means all I need to do is to include the script in the JSP file–I won’t have to deal with the Spring MVC for a bit.

    <html>
      <head>
          <script type="text/javascript" src="[PATH TO THE API CLIENT]"></script>
      </head>
      <body>
        <script>
           var api = new DropioApiClient("[YOUR API KEY]","[FULL PATH TO YOUR XD RECEIVER PAGE]");
           // do stuff with the api here
        </script>
      </body>
    </html>

You are allowed to do 2000 API calls from your given API key

– While this may actually be a downside, for student researchers like us, this is a fair deal. We can do an upgrade anyway once this gets deployed.

It’s secure

– A concern raised by Jeune after learning that the API key will be hard coded in the javascript file is security. Turns out the API key will only be used to track the third party application and check if it is a legitimate one. Creation of each “drop” (that’s how they call your uploads) given the following code will return a token (a.k.a. a session key – Jeune).

var api = new DropioApiClient("[YOUR API KEY]");
    api.createDrop({name:"somedrop",privacy_type:"VIEW"},receive_response);
    function receive_response(response,success) {
      if( success )
        alert("Your drop is: " + response.name);
      else
        alert("Error creating drop: " + response.message);
    };

Maximum upload life is 1 year

– While we can store ratings in Projectrix forever, we cannot do anything about this–the least for now.

The files are not crawlable [sic]

– This is not of our concern as the ratings in Projectrix is what we want to be crawled on. [sic]

Wide and active user base and support groups

– Development of Drop.io, and third party applications that make use of it are growing (and are very active). Therefore, there’s a growing number of people who can help us out.

Written by falloutkee

October 5, 2009 at 2:01 pm

File repository (updated)

leave a comment »

After we have successfully implemented the upload feature of Projectrix for the Google App Engine (as described in Shogi Software, where it utilizes Apache Commons’ FileUpload), we were informed that we need to look for another service (i.e. Drop Box) that will handle the file storage for projects such as Machine Problems, etc. Other media like videos will make use of YouTube. So far, we have devised 2 plans on how to implement this:

[ONE] Search for Drop Box API (which I believe does not currently exist) or any workaround like this.

or

[TWO] Look for another file repository that has an open API.

The reason why I want a file repository that has an open API is for efficiency and a better user experience as no one would want to switch back and forth to the main window from the repository site. A seamless upload really is the way but for now, we’ll settle with links.

UPDATE: Thanks to Ma’am Weng for introducing to us Box we can now implement what we want for the upload. Box has a lot of support for developers and a lot of applications have already used Box as their file repository. In its developers wiki are the Web services available. Will tinker it in a bit.

Written by falloutkee

September 24, 2009 at 2:34 am