Initial Project Plan

Porting processing to the canvas.

Processing is an open source programming language intended for programmers and artists to create programs in a visual context. A few links that are a good place to understand what it is.

home page
wikipedia
examples

For this project, I will be working with Processing.js. Basically, allowing Processing programs to be developed, and run directly in HTML, through the use of the HTML canvas tag, retiring Flash and Java applets. This way, users can browse the web, view animation, run games, look at digital art, all without having to download and install any additional plug-ins.

I mentioned a bit about this project on my last blog post. But I have officially accepted it as a project and to sum that up, I am a fan of Java, and java applets, because of how easy it is to distribute digital art through the web, and making that easier excites me not only as a programmer, but also as an artist. Maybe this will bring back my passion for art that has been beaten into submission!

The essence behind what I will be doing is debugging. This is the valuable bug tracking system used for Processing.js.

The processing process

The progress of this project can easily be followed through this blog, under the open source tag. I will be updating the blog atleast once a week, hopefully more with, what I have accomplished, what I have learned, my failures, problems and my goals as I see them. I will also have a wiki page here.

As easy as one, two, three

Over the course of this project, I will be working on three releases, 0.1, 0.2 and 0.3.

Release 0.1 will be to work on two bugs. Bug #133 and #230.
I hope to get both bugs fixed for the 0.1 release.

Release 0.2 and 0.3 will be more bugs to work on.

Debugging bugs

Bugs are something I enjoy, as they are like self contained puzzles. Debugging is not about learning a specific task, and doing that task every time you are presented with the problem that task solves. Debugging is more like a puzzle because it's always different. Once something is solved, it's no longer a puzzle, and the fun has been spoiled. Sure, it can be frustrating, and you never quite know what you're getting into, it could snowball into more than you expected, or it could be one line, or one word of code. It could be a simple matter of =+ instead of =.

If by each release, I have solved the bug's puzzle, I will have been successful in my mission.

The ingredients

In order to accomplish this mission, I will need to heavily refresh my JavaScript skills. It's been about a year since I last worked with it, and that was only an intro. I've been meaning to shake the JavaScript cobwebs out for a long time now, and this is a good way to do that. When I first learned JavaScript, oh so long ago, I used Seneca's INT222 website, and that's where I will start as I work on this project

I will also need to understand Processing. I expect I will be doing most of the Processing heavy learning through these two links.

learning
reference

My knowledge of Java is moderately good, what I know, I know well, what I don't know, I can easily learn as I go from the java api. I always found the java api to be a well documented source for learning java.

I have been in contact with my professor for this project, Prof David Humphrey and he has supplied me with some links to start with. He also has a blog which covers processing beyond what I know. A good place to start.

Collaboration of fellow students

There has been multiple Seneca students, past and present that have been working on this. If I need help, I can start by contacting another student through this blog posting.

It is my hope that by having this blog I will get in contact with others, and we'll see how that goes! This is quite new to me, and I'm taking it one step at a time, moving in bit by bit, chipping away, and getting my feet wet.

Problems of the future and beyond

There is little that I know about this, as I have not even compiled and ran a Processing program yet. I would also need to figure out how to submit my finished work, and have it approved and entered into the collective. One step at a time, starting with research, then reading examples, compiling examples, modifying examples, looking at past bugs and how they were solved, and the compiling and running the bug in question, recreating the bug and seeing it first hand.