I got The Processing Book for Christmas and I finished it this morning.

It’s been a lot of fun going through the book and I learned a ton of different things. First off, book review:

The authors did exceptionally well at balancing six different topics:

• Programming
• The Processing API
• Introduction to Algorithms for Software Based Art
• Introduction to Software Based Art
• Synthesis sections which contain complex Processing examples
• Survey of existing art made with software

The programming stuff was pretty basic (just touched on higher level OO near the end) but the creators of Processing (who also wrote this book) did a good job at making the easy stuff easy. For example, unlike Java (which Processing is based upon,) you are not required to have a main function and all that jazz. You just wanna draw a rectangle?

Or you to get more complex you basically define a setup and draw method. setup gets called once and draw gets called for every frame. You don’t have to worry about the loop to call the draw method or all that jazz. It’s taken care of for you. So the following works fine:

I also thought the writers did extremely well introducing the API for Processing, but not stopping there. Too often technical books are just giant swaths of examples using the API. This book supposedly only goes over about half of the API, but I think they do well at explaining how to use the parts they’ve shown.

And then there is the algorithm stuff, which is what’s really the most important to me. A basic example would be the explanation of the easing technique, which is where something transforms to something else at a natural looking rate; think deceleration. I never would have though to do research on something like that. I plan on doing a post just showing examples of all the different algorithms, just for my own reference later.

They also do a really good job of pointing out creative ways to do things. Like that it’s interesting to use the location of speed of the mouse as something other than the location of something. Like maybe the faster you move your mouse the bigger something gets. Whatever. Stuff like that was peppered throughout the entire book, and then the reader is treated to a heavy dose of it in the Synthesis sections.

Next up, a little bit of introspection:

In college I never really had to read that much. I went to a technical school (LeTourneau University) so if I did do reading it was typically programming stuff, which meant fewer words than all those fictional works which I read before bed every night. The point is I’ve never had to be a fast reader. But since I’ve subscribed to the Iron Man feed I’ve gotten way better at knowing when and where to skim and where not to. I think this is what allowed me to finish the book in about four days. Check out what I made by the way! Make sure to press r and h to see the rgb and hsb breakdowns of the color the mouse is over. Pressing other buttons on the keyboard, right-clicking, and left-clicking should do some basic fun stuff too.

And lastly, just like I discovered during Thanksgiving, programming “bare metal” is a lot of fun! You may think, “Oh fREW, that’s not bare metal!” Look at it this way: if I want a button, I draw a square, manually run code that I wrote to check if the mouse is over the square, change the background of the square (for a mouse over) and then check if the mouse clicked the button; again, all my own code. So yeah, for graphics stuff there is a lot done for me, but for UI type stuff it’s pretty low-level. But it’s a lot of fun! Anyway, my hope is to make a really basic game with this stuff. Since Processing is just java stuff I don’t think I’ll have much trouble finding libraries to do what I need….

Anyway, hopefully this weekend I’ll do a post about the algorithms I learned, of which there are myriad. In the mean time I am going to do some research into this game idea….

Sorry about that guys, I didn’t use links to make it clear which book I was talking about. Usually I do that kind of stuff but the internet was sucky (fixed!) so it hurt to look up links. Enjoy?

I am just getting through chapter four of the Catalyst book and there are already a whole lot of things worth mentioning. My internet is currently at 50% packet loss because our wifi router is busted so this is pretty painful for me. So we’ll keep it short.

Moose

The book has a nice (very short) introduction to Moose. Not only is this good because Catalyst is now based on Moose, but also I would say you probably want your OO code to be based on Moose. There are times when you probably don’t want to use Moose, but there are also times when you don’t want to use strict. As a rule, use Moose for OO code.

CPAN

There is also a very good introduction to usage of CPAN. A lot of us think that CPAN is our programming platform. Knowing how to use it is extremely important. It includes not just finding stuff on CPAN, but also ascertaining the quality of those modules, and how to install them. Very good information for a perl programmer.

Tesing Methodology

In chapter 4 mst discusses how he writes tests (which can be slightly supplemented with his latest blog post) and it’s actually quite helpful. Some people write tests after writing their code and run the risk of forgetting to test at all (that’s me!) Other people are all hardcore TDD and write tests first, but that assumes that they have already thought through the interface for what they are writing. mst posits that it’s better to write your code, and “test” it from test files as you go. And test in this case means warns, Data::Dumps, whatever. After it works how you expect, you then take those warns and whatnot and translate them into ok’s, is’s, and cmp_deeply’s. It’s really much nicer than the alternative: build it all and see if it works. Try it!

Diffs

Lastly, I really like how they represent code as diffs instead of monolithic code. Writing large swaths of code doesn’t work that well in real life. It works much better to do tiny changes and make sure they still compile, do what you want, etc.

But the book certainly isn’t perfect! There are some weird code layout issues, (p34, 36, 39, etc) and I am pretty sure I saw at least one syntax error (END__ instead of __END__).

So far though, I would say that the book is better than most programming books. Really, a lot of programming books need to be more like this, instead of focusing entirely on the arcana of one framework they should help you be a better programmer overall.