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.

Anuncios

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?”

Bits Pics: Visualizing the Web’s Icons

The data visualization above shows the “favicons” of nearly 300,000 Web sites on the Internet. Favicons are small images used to identify a Web site in the browser.

The sizes of the icons are based on the amount of traffic each Web site receives, using data from Alexa.com, a traffic and Web metrics site.

The project, which I came across via Gizmodo, is the work of two programmers, David Fifield and Brandon Enright. They work for a company called Nmap that makes open-source security programs.


By NICK BILTON

Favicon Data visualization

The data visualization above shows the “favicons” of nearly 300,000 Web sites on the Internet. Favicons are small images used to identify a Web site in the browser.

The sizes of the icons are based on the amount of traffic each Web site receives, using data from Alexa.com, a traffic and Web metrics site.

The project, which I came across via Gizmodo, is the work of two programmers, David Fifield and Brandon Enright. They work for a company called Nmap that makes open-source security programs. Leer más “Bits Pics: Visualizing the Web’s Icons”

The Newbie’s Guide to Test-Driven Development

Nikko Bautista

Testing your code is annoying, but the impact of not doing so can be orders of magnitude more annoying! In this article, we’ll use test-driven development to write and test our code more effectively.

What is Test-Driven Development?

Since the dawn of the computer era, programmers and bugs have battled for supremacy. It’s an inevitable occurrence. Even the greatest programmers fall prey to these anomalies. No code is safe. That’s why we do testing. Programmers, at least sane ones, test their code by running it on development machines to make sure it does what it’s supposed to.

Test-driven development is a programming technique that requires you to write actual code and automated test code simultaneously. This ensures that you test your code—and enables you to retest your code quickly and easily, since it’s automated.

How does it work?

Test-driven development, or TDD as we’ll call it from now on, revolves around a short iterative development cycle that goes something like this:

1. Before writing any code, you must first write an automated test for your code. While writing the automated tests, you must take into account all possible inputs, errors, and outputs. This way, your mind is not clouded by any code that’s already been written.
2. The first time you run your automated test, the test should fail—indicating that the code is not yet ready.
3. Afterward, you can begin programming. Since there’s already an automated test, as long as the code fails it, it means that it’s still not ready. The code can be fixed until it passes all assertions.
4. Once the code passes the test, you can then begin cleaning it up, via refactoring. As long as the code still passes the test, it means that it still works. You no longer have to worry about changes that introduce new bugs.
5. Start the whole thing over again with some other method or program.


The Newbie’s Guide to Test-Driven Development

Testing your code is annoying, but the impact of not doing so can be orders of magnitude more annoying! In this article, we’ll use test-driven development to write and test our code more effectively.


What is Test-Driven Development?

Since the dawn of the computer era, programmers and bugs have battled for supremacy. It’s an inevitable occurrence. Even the greatest programmers fall prey to these anomalies. No code is safe. That’s why we do testing. Programmers, at least sane ones, test their code by running it on development machines to make sure it does what it’s supposed to.

Test-driven development is a programming technique that requires you to write actual code and automated test code simultaneously. This ensures that you test your code—and enables you to retest your code quickly and easily, since it’s automated.

How does it work?

Test-driven development, or TDD as we’ll call it from now on, revolves around a short iterative development cycle that goes something like this:

  1. Before writing any code, you must first write an automated test for your code. While writing the automated tests, you must take into account all possible inputs, errors, and outputs. This way, your mind is not clouded by any code that’s already been written.
  2. The first time you run your automated test, the test should fail—indicating that the code is not yet ready.
  3. Afterward, you can begin programming. Since there’s already an automated test, as long as the code fails it, it means that it’s still not ready. The code can be fixed until it passes all assertions.
  4. Once the code passes the test, you can then begin cleaning it up, via refactoring. As long as the code still passes the test, it means that it still works. You no longer have to worry about changes that introduce new bugs.
  5. Start the whole thing over again with some other method or program. Leer más “The Newbie’s Guide to Test-Driven Development”

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”

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”