Review: Processing for Visual Artists

My first thought upon receiving a review copy of “Processing for Visual Artists” by Andrew Glassner was “hey, yet another Processing book?” Glassner is well aware of the ubiquity of Processing literature, however, and targets a specific gap, following his philosophy “that artists and designers are not interested in programming for its own sake, but only as a means to an end: creating expressive work”. This book is made for people who have never written a program before or don’t feel very comfortable in the world of code. Glassner invites the reader to peek over his shoulder to learn about his programming process using a friendly and informal style, which is motivating and makes the book easy and fun to read. And if you like to cook or play the piano (I do!), you’ll feel right at home with Glassner’s many real-world analogies.

The beginning of the book is basically a casual conversation between the author and the reader – master and apprentice –, showing the reader around, introducing computer science terminology, and most of all, taking away the fear of the seemingly steep learning curve. Glassner shows a lot of empathy towards someone new to programming, acknowledging that it will look overwhelmingly complex at first and be hard work, but that, just like learning to ride a bike or playing chords on a piano, the complexity will soon fade away, allowing even a novice programmer to create exciting work. He has three pieces of advice: there is no way you can break your computer with your program, type every code listing by hand (so it’ll sink in), and don’t be afraid of errors. In fact, Glassner left the errors he made when creating the example code right there in the book, so that, as the reader follows him along, he will see where and why an error was made and how it was fixed.

Anuncios

http://datavisualization.ch/opinions/review-processing-for-visual-artists
Review: Processing for Visual Artists The book’s author, Dr. Andrew Glassner,
is a writer-director, and a consultant in story structure, interactive fiction, and computer graphics. He started working in 3D computer graphics in 1978, and has carried out research at many respected labs.


My first thought upon receiving a review copy of “Processing for Visual Artists” by Andrew Glassner was “hey, yet another Processing book?” Glassner is well aware of the ubiquity of Processing literature, however, and targets a specific gap, following his philosophy “that artists and designers are not interested in programming for its own sake, but only as a means to an end: creating expressive work”. This book is made for people who have never written a program before or don’t feel very comfortable in the world of code. Glassner invites the reader to peek over his shoulder to learn about his programming process using a friendly and informal style, which is motivating and makes the book easy and fun to read. And if you like to cook or play the piano (I do!), you’ll feel right at home with Glassner’s many real-world analogies.

The beginning of the book is basically a casual conversation between the author and the reader – master and apprentice –, showing the reader around, introducing computer science terminology, and most of all, taking away the fear of the seemingly steep learning curve. Glassner shows a lot of empathy towards someone new to programming, acknowledging that it will look overwhelmingly complex at first and be hard work, but that, just like learning to ride a bike or playing chords on a piano, the complexity will soon fade away, allowing even a novice programmer to create exciting work. He has three pieces of advice: there is no way you can break your computer with your program, type every code listing by hand (so it’ll sink in), and don’t be afraid of errors. In fact, Glassner left the errors he made when creating the example code right there in the book, so that, as the reader follows him along, he will see where and why an error was made and how it was fixed. Leer más “Review: Processing for Visual Artists”

The Case For Open-Source Design: Can Design By Committee Work?

In celebrating the merits of free software and the excitement over this radical networked production method, an important truth is left unspoken. Networked collaboration shines in the low levels of network protocols, server software and memory allocation, but user interface has consistently been a point of failure. How come the networked collaboration that transformed code production and encyclopedia-writing fails to translate to graphic and interface design?

The following is an investigation into the difficulties of extending the open-source collaboration model from coding to its next logical step: interface design. While we’ll dive deep into the practical difference between these two professional fields, the article might also serve as a note of caution to think before rushing to declare the rise of “open-source architecture,” “open-source university,” “open-source democracy” and so on.


By Mushon Zer-Aviv

In celebrating the merits of free software and the excitement over this radical networked production method, an important truth is left unspoken. Networked collaboration shines in the low levels of network protocols, server software and memory allocation, but user interface has consistently been a point of failure. How come the networked collaboration that transformed code production and encyclopedia-writing fails to translate to graphic and interface design?

The following is an investigation into the difficulties of extending the open-source collaboration model from coding to its next logical step: interface design. While we’ll dive deep into the practical difference between these two professional fields, the article might also serve as a note of caution to think before rushing to declare the rise of “open-source architecture,” “open-source university,” “open-source democracy” and so on.

Osd Collab 500 in The Case For Open-Source Design: Can Design By Committee Work?

Leer más “The Case For Open-Source Design: Can Design By Committee Work?”

24 tips for web developers

by ian

I’ve neglected the development folks lately. Which is ironic, since I’ve spent the last six weeks buried in reverse proxies via nginx, Nutch and writing web spiders in Python.

To make up for it, here’s a list of random learnings I’ve had when I put on my development hat:

1. Learn the business case. Make sure you understand the purpose of the application you’re writing. It’ll help you make informed decisions on features and such.
2. Fight for simplicity. Once you know the business case, you can work with your client to keep the application simple. So do it.
3. A stupid specification doesn’t justify a stupid application. If you know the spec makes no sense, then work with folks to fix it. Don’t write crappy code based on the crappy spec and expect sympathy later on.
4. You’re an architect, not a hammer. In the same vein as #3.
5. Plan twice, write once. Oh. My. God. Before you write a loop within a loop within a loop, think! There’s probably a better way. Small changes in architecture can make life a hell of a lot easier.
6. Plan for scalability. When your client says “Oh, this will never need to handle more than 1000 records” they are lying. Always plan for ginormous scaling. Write your code so that it can someday run on a platform like Amazon EC2, at least.


example of Python language
Image via Wikipedia

I’ve neglected the development folks lately. Which is ironic, since I’ve spent the last six weeks buried in reverse proxies via nginx, Nutch and writing web spiders in Python.

To make up for it, here’s a list of random learnings I’ve had when I put on my development hat:

  1. Learn the business case. Make sure you understand the purpose of the application you’re writing. It’ll help you make informed decisions on features and such.
  2. Fight for simplicity. Once you know the business case, you can work with your client to keep the application simple. So do it.
  3. A stupid specification doesn’t justify a stupid application. If you know the spec makes no sense, then work with folks to fix it. Don’t write crappy code based on the crappy spec and expect sympathy later on.
  4. You’re an architect, not a hammer. In the same vein as #3.
  5. Plan twice, write once. Oh. My. God. Before you write a loop within a loop within a loop, think! There’s probably a better way. Small changes in architecture can make life a hell of a lot easier.
  6. Plan for scalability. When your client says “Oh, this will never need to handle more than 1000 records” they are lying. Always plan for ginormous scaling. Write your code so that it can someday run on a platform like Amazon EC2, at least. Leer más “24 tips for web developers”

5 Good Habits That Will Make You a Better Coder

We all want to grow in the things we do, and in the field of web development, one of the main areas that we spend a lot of time on is our code. This could include HTML, CSS, JavaScript, PHP, Python, ActionScript or any other language that you may choose to use for building websites.

In this article, I’ll share some practical steps that you can take to expand your skill set and become a better coder. I would like to propose five different habits that you can adapt in order to help yourself become more excellent at what you do.


by Matt Ward

5 Good Habits That Will Make You a Better Coder

We all want to grow in the things we do, and in the field of web development, one of the main areas that we spend a lot of time on is our code. This could include HTML, CSS, JavaScript, PHP, Python, ActionScript or any other language that you may choose to use for building websites.

In this article, I’ll share some practical steps that you can take to expand your skill set and become a better coder. I would like to propose five different habits that you can adapt in order to help yourself become more excellent at what you do.

Leer más “5 Good Habits That Will Make You a Better Coder”

7 Personality Types of Developers Today

Developers and programmers are meticulous individuals, and developers sometimes stand out even among themselves.

We introduced you to 7 types of designers in our article 7 Personality Types of Designers Today. Developers have peculiar traits and habits of their own. This article looks at 7 types of developers today and their defining characteristics.

“The best programmers are not marginally better than merely good ones. They are an order of magnitude better, measured by whatever standard: conceptual creativity, speed, ingenuity of design or problem-solving ability.”
—Randall E. Stross

Stereotyping is generally not good practice. But we’re not trying to squeeze individuals into categories. Rather, delineating these types can help you figure out where you stand and help you understand others.


Developers and programmers are meticulous individuals, and developers sometimes stand out even among themselves.

We introduced you to 7 types of designers in our article 7 Personality Types of Designers Today. Developers have peculiar traits and habits of their own. This article looks at 7 types of developers today and their defining characteristics.

“The best programmers are not marginally better than merely good ones. They are an order of magnitude better, measured by whatever standard: conceptual creativity, speed, ingenuity of design or problem-solving ability.”
—Randall E. Stross

Stereotyping is generally not good practice. But we’re not trying to squeeze individuals into categories. Rather, delineating these types can help you figure out where you stand and help you understand others. Leer más “7 Personality Types of Developers Today”