Archive for January, 2010

setting up Processing.js

Posted in open source on January 31, 2010 by scottdowne

At the end of my last post. I mentioned I was going to start researching the bug, but it was apparent I needed to get Processing.js setup so I could run in off my box, thus able to change the source, and test it. The little test page wasn’t going to cut it for very long.

I am going to start by going through this walkthrough and report back in when I got it up and running, hopefully tonight as I have school tomorrow morning, and may not get a chance tomorrow.

Update. It didn’t take long at all to go through the example here. and this is what I came up with link. I didn’t have any problems, and it’s pretty straight forward.


Playing with Processing.js

Posted in open source on January 31, 2010 by scottdowne

My last blog entry, I started my initial project plan.

And today I’m starting the process of learning Processing.js.

  • get the basics of the syntax
  • how to run a program in a canvas tag
  • and understand the basic, mandatory methods used to run a program

Upon going to the Processing.js home page I saw a link at the bottom “Try out some Processing code!”. What this is, is a page that you can edit, and immediately view the results of your changes.

First thing I noticed is that it uses setup() and draw(), which seem to be pretty mandatory methods. setup() is pretty self explanatory, sets up the canvas, and is run once as soon as the canvas loads. The second method, draw() is called based on the interval set in frameRate(), which in the default case was set to 20, that’s in seconds. So, the example is running at 20 frames per second, or, a better way to put it, it’s calling the draw() method 20 times per second.

The first thing I did was change the frames per second to 2, my results were as expected, slow. Next I tried a large number, 99999, and it seemed fast, but not nearly as fast as I expected, so I tried 30, which I believe to be the frame rate used in TV, and it seemed to be as fast as 99999. I later noticed in the frameRate() method, that 60 was default, and if the local machine could not handle whatever is requested, it will simply not be achieved. I tried 30 and 60, and noticed a slight difference. But, obviously not as noticeable of a difference between 1 and 30.

I then noticed in the draw() method, there was background() and random(). I promptly changed the background(50) to background(random(9999), and it did not work well, as expected. There are not 9999 potential colours, and anything over 255 would default to 255. I then played around with stroke() and tried some random colours there too. I found out that stroke sets the colour that is to be used while drawing to the screen.

I also moved the background() method from draw() into setup(), and the results were logical. It didn’t remove the old lines, and they kept drawing blue lines to the screen until the screen was blue.

Then removed background() completely, by commenting it out with //. It defaulted to white.

Honestly, with my experience in other programming languages, this languages seems very straight forward and within about an hour I was done playing with it and ready to start researching the bugs I was assigned.

One final not about learning Processing.js, this is a great place to get detailed into on the methods used.

Initial Project Plan

Posted in open source on January 29, 2010 by scottdowne

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

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.


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.

January 26th

Posted in open source on January 27, 2010 by scottdowne

Blog time.

Today we talked about our potential project for OSD, and I’m excited about learning the language Processing. It’s basically a more creative language for programming media and art. I like it’s potential for neat, unique, 3D or 2D, physics, and games.

The project would be transferring the language to be usable inside an html script tag. The task would consist of converting functions written in Java into Javascript. Allowing digital art, media and games to be run in a browser, without the need of applet software being installed. I’m 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!

I feel my proficiency in Java is strong, but my proficiency in Javascript is slipping away, and add a new language I don’t even know. It’s got everything. Keeps me sharp, shakes off the dust, and pushes me into strange new lands.

This is what excites me the most, for now. But I’m up for anything, and any challenge.

This is all for now, up to my knowledge on the subject. If I take the project, I’ll be blogging more on it.

I believe I’ve got to read and listen to some articles this week. Been putting that aside, and then totally ignored it in favour of this blog entry!

week of Jan 18th

Posted in open source on January 21, 2010 by scottdowne

The article on Academic source code dust-up symptom of CS education ills really caught my eye. I’ve long been a critic of academia, mostly the testing of individual achievement. It’s really become a student’s focus of school, and it’s perhaps the part of school where you do the least learning.

The idea of learning in an open source environment is my white knight, and it’s why I’m taking OSD600. I have high hopes, and think the open source course at seneca should mirror the importance of the sys and prj courses.

Often have I mentioned my issues on academia to a prof in a casual discussion, only to hear “that’s just how it’s done”. It’s roots run deep. But on the other hand, is it school where we do our learning? or is it at home, on our own where we do our learning? A creative writing student at York university said to me “never let school get in the way of your education” and it’s soo true. School only shows us the door, it’s up to use to walk through it, and upon exiting, we must write a test on it. Tests have a valuable place, but the final grade portion should be from a large assignment, and a short interview with the prof about the assignment. Tests are best served as a personal marker for the student, the student exits the door, writes the test, and instead of failing or passing, the student can re enter the door, or enter the next door. That’s a start, anyway. Another student at OCAD said to me that they only write tests in their history class, and that anything that you learn by doing, or you create something, has no place for a test in memory. Programming is a highly creative skill, we learn by making mistakes, and fixing them, which happens to be a lot more fun than reading a boring textbook. OCAD’s solution to the lack of testing, is to interview and critique the student about their final works. If the student cheater and got someone else to create the work, it’ll show in the interview no doubt when the student has no clue how to talk about the work. This also gives OCAD the chance to bring in processional art critiques to help the student, making it a positive situatio, with rewards instead of punishments. Is cheating really a big a deal as it seems? Is testing and not sharing really the only options? Not at all. It’s safe to say testing and individual assignments are most valuable in the earlier semesters, and later semesters where the students that are still studying, have proven that they are there to learn. Then, roll out the group work, when my group members are more liekly to take it seriously, and at the very least, show up to class

It’s true, how in the article it says “it’s up to the students to take their learning seriously” what I think he means is it’s our job to make the change happen the way we want it to happen.

Finally, not everyone learns the same way, and it’s great to have options. Everything has it’s place, even horrible students and teachers, it’s all a learning experience.

Posted in open source on January 15, 2010 by scottdowne

I’m a little behind on some sort of welcome post, but here it comes anyway. In this blog, I’m going to be blogging on open source, to help me learn about it. My name is Scott Downe, and I’m a 5th semester student at Seneca College, in their computer programming and analysis program.

I’ll also use this blog to document my findings as I program in an open source environment.

I never saw myself using a blog, but it’s been two days, and I have three posts, so it must not be that bad. I also have a hard time getting into any sort of habit, good or bad. I can do something for as long as it needs to be done, and after that, I tend to move onto other things. So I don’t see myself blogging after I have done, what I set out to do, with this blog. So far so good though.

Posted in open source on January 15, 2010 by scottdowne

I just read the New York Times article on Firefox and Google, and I think, after reading this, I hold loyalty, bias, and faith towards Firefox. Mostly, it’s the addons I like, something Chrome, to my knowledge, doesn’t have yet.

It’s also interesting to hear about Google and Mozilla parting ways. Something I have not heard of until this article, or is it New York Times taking something that’s not final, and make it sound more dramatic. in this article, it definitely sounded like Mozilla and Google were at war to the same degree as Microsoft, or is it simply that their partnership is shrinking, as Mozilla grows, as it should.

It’s interesting though, that sometimes, it’s such a small feature that puts someone on the top of a market. When left with two almost identical products, it can come down to one or two little things that decides which one gets picked up by the user, makes the choice easier, and the competition is good for all industries.