Monthly Archives: January 2007

Dayanita Singh

Many thanks to Sonia Faleiro for highlighting the work of Dayanita Singh, who appears to be one of the most prolific contemporary Indian fine-art photographers.

Singh is perhaps best known for her portraits of India’s urban middle and upper class families. These images of people working, celebrating or resting at home, show Indian life without embellishment. She explores another side of India – the place that she belongs to and understands. Her recent work has concentrated on another form of portraiture, of places rather than people. These photographs are taken in a diverse range of interior spaces: from the ballroom of an 18th Century palace to the humbler surroundings of a private home or from museums, libraries and seminaries to the specially constructed wedding ‘stages’ of the traditional marriage ceremonies. An abiding image of India is that of a teeming crowd of humanity. However, all but a few of Singh’s images are devoid of the human figure and they are typified by composure rather than restlessness. The work’s subtle formality is the product of intense and intimate observation, communicating a unique sense of time and place.

(Firth Street Gallery)

How does this actually work in practice? Consider this blurb about her seminal book Privacy:

What can a photographer in India capture on film other than disasters or the exotic? After many years spent documenting the poverty in her homeland, Dayanita Singh was preoccupied by this question. Her answer here is a return to the world from which she came, to India’s extended, well-to-do families and their fine homes. Both on commission and on her own, she photographed friends and friends of friends, creating a portrait of another society, complete with its traditional and post-colonial symbols of prosperity. The self-confident elite of India is nearly unrivalled in the West. Privacy provides great insight into a closed world characterized by tight family solidarity. Singh shows the people as they would like to see themselves, in the middle of splendidly decorated rooms and surrounded by possessions that represent their self-image. At a certain point in her work, Singh realized that even without their residents, the rooms were occupied by the invisible generations that had lived there before. The book closes with photographs of interiors, empty but still filled with spirits.

Her work has been displayed at several galleries both inside and outside India, including Firth Street Gallery, Ikon Gallery, and Gallery Chemould. I should have seen her art in 2005 when it was at the Isabella Stewart Gardner Museum, but I didn’t. You can read a review from Tiffinbox.

Posted in OPP, Photography | Leave a comment

Semester #2: Continuation of an International Theme

A new semester began last Tuesday with my XML and Related Languages course. Because of Martin Luther King, Jr. Day, the first Monday of the semester is after the first Tuesday, and tomorrow Software Development Methodologies will meet for the first time.

(Last semester went very well. I’m a much better student than I was ten years ago. I guess that’s what happens when I pick something that I’m good at rather than stubbornly picking mathematics classes. Oh what a quixotic four years those were.)

The internationalization discussion continues. For those who don’t know already, not everyone in the world who uses a computer knows (or wants to know) English. Internationalization refers to the practice of writing software that can be easily adapted to another locale. This involves a lot of different things: character sets; text direction; currency symbols; formats for dates, times, and numbers; spelling rules; etc. And sometimes even plain-old English speakers need to use accented characters.

My XML course is the second technical class in a row where character encoding has come up. You might remember that Perl has ample support for multiple languages. A developer can create variable names and values in almost any language. Similarly, XML allows almost any Unicode characters in elements, attributes, and values. I’m sensing a trend in these newer, widely adopted languages that form the basis of our information economy.

But once again, in my class there was a fair bit of confusion about terminology and concepts. I’m no expert, but I think I know what Spolsky says is the “The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets.” So here goes:

Every symbol you can use to create a word in a particular language is called a character. Some languages have few characters. Others, like Chinese, have many, many more. Hindi and Hebrew and Arabic have a set of base characters along with special ligature marks for vowel sounds (e.g., क = ka, कि = ki, को = ko, कु = ku, कै = kai, etc.) and for combining characters (न + द = न्द [nd] and प + त = प्त [pt]). Multiple languages often use many of the same characters; consider French, German, and Spanish. Don’t confuse characters with the typefaces or fonts that present characters. Switching from Arial to Courier doesn’t change the underlying meaning of a character, just its form.

A character set is the group of all characters from all languages that a given system can describe. Most character sets have relatively few characters — ASCII, for example, has 128 — while Unicode’s Universal Character Set has around 100,000 characters. There are lots of character sets because back in the olden days before widespread information globalization locales rarely interacted — or rarely interacted easily — and everyone did what was easy. (Sometimes, you really are going to need it.)

Intimately related to a character set is character encoding, which assigns a value to each character. Computers can’t read and don’t really understand characters, but they do very well with numbers and abstraction. Encoding maps characters to numbers and vice versa. Storing characters in memory or on disk is simply a matter of using the right value for the character.

This brings up a huge, earth-shaking gotcha. A computer byte — the basic unit of computer memory — can only hold 256 values, but Unicode allows for more than a million characters. For decades, programmers using Roman, Greek, and Cyrillic character sets saw no problem with this and stored their characters in one byte. Encodings overlapped but incompletely, and no one gave much regard to the future. In this modern multilingual computing world we need anywhere between one and three bytes to store all of the characters in the Universal Character Set.

The Unicode standard has two parts, one of which describes the characters unambiguously and the other which says how to map the numeric values to bytes. There’s more than one way to do this. Among these are UTF-8, UTF-16, and UTF-32. I don’t know all of the gory details of these encoding schemes, and I don’t think you would want to know either. But here’s what you should know: A character no longer is the same as a byte. It might be two bytes; it might be three or even four. In UTF-8 a special value in the first byte indicates that there are more bytes coming for this one character.

If you’re a programmer and live in the old “1 character = 1 byte” world, you might get lucky because ASCII is a subset of UTF-8. All ASCII documents are also UTF-8. The bad news, and it’s pretty bad, is that UTF-8 documents aren’t always ASCII, and in the future even fewer will be. If you treat all files as ASCII, you’re going to get it wrong . . . a lot.

Unfortunately, the way forward involves a chicken and egg problem. In a text document, how do you know the character encoding? Is the document ASCII or UTF-8?

This, my friends, is why I work with non-text formats that have specifications that give the answers to these questions (or allow you to assume ASCII).

Posted in Software Engineering | Leave a comment

Dude, you’re getting a Mac

Over the last couple of months, four of my coworkers became first-time Mac owners. It’s as if one day everyone drank the Kool-Aid and knew they needed a Mac.

For me, it happened a little like this. About a year ago I decided that I needed a laptop. I had dozens of litte reasons, but mostly I missed Lisa and had grown tired of being sequestered in my home-office to use the Internet.

Around that time, an Apple “evangelist” visited the office to spread the good word. I hadn’t used a Mac since college, didn’t know what Mac OSX looked like, and still had the general impression that they were flakey, slow toys rather than real computers that I might want to use. But there it was: beautiful and speedy with software that I wanted to use. It had a real operating system. It came with developers tools. It was going to run on modern Intel processors. Was I really starting to think about a Mac? (“Seriously? Seriously?” I asked myself.)

Over the next few months — I’m a real slow mover — I tried to think of every reason not to buy one, but they all proved unsound. (A fellow developer and Mac devotee called this phenomenon “Fear of a Mac Planet”) Even the price was comparable to the Dell I built online.

Now, it’s nine months later. Am I still happy? Oh, yes!

But I don’t like Safari’s RSS feed aggregator. To my fellow Mac users: Consider Vienna, a better news reader.

Posted in Computing | Leave a comment

People in Photographs

In case you’ve missed it, there’s a rather interesting debate happening about people in contemporary fine art landscape photography that started on Alec Soth’s blog and carried on in the comments and then really got going when Robert Polidori defensively defended his New Orleans photos and by extension his Havana photos and his Chernobyl photos and his . . . you get the point.

Alec posted back and now it’s on.

Posted in OPP, Photography, This is who we are | Leave a comment

Software Development as Ye Olde Craft Economy

My group at work has just started reading Implementing Lean Software Development by Mary and Tom Poppendieck. As with any other reading group, the communal experience encourages us to read something that we might not pick up on our own. Because the books are (hopefully) relevant to our vocation, discussing them together helps us find ways to apply what we learn. We haven’t started discussing this book yet, but already I am intrigued.

For the uninitiated, Lean Software Development applies the core principles of lean manufacturing (as embodied in the Toyota Production Sytem) to software development. In particular, the process attempts to eliminate waste, build quality into a product, and continuously improve the development process. The authors admit that software development isn’t the same as manufacturing automobiles or clock radios, but I’ve managed to suspend my disbelief and see how well the principles apply. Perhaps at a later time I will recap what I’ve learned from the book.

But for now I would like to go off in a tangential direction inspired by the authors’ brief history of organized manufacturing from its birthpangs in 18th century Europe, through the interchangeable parts revolution that exemplified the American System of manufacturing, continuing on to the Ford that used interchangeable semiskilled labor and parts, to lean manufacturing at Toyota. But it’s that earlier, pre-manufacturing period that interests me now and seems so applicable to software development: the craft economy.

Imagine a craft economy. It’s hard to do. Everything is made and then made again but slightly differently. Two craftsmen build two things using their own unique toolsets, and the results are often incompatible or just different enough to require learning how to use it and make it costly to fix when broken. When the craftsman needs a new tool, she typically goes to her own machine shop and builds it specifically for the purpose.

I’m not disparaging craft economies. Some — most? — of the world’s superlative things were produced by craft economies: the pyramids, Chartres Cathedral, illuminated manuscripts, Sputnik. And there’s something charming and old-timey about one-of-a-kind goods. But craft work is incompatible with modern production; primarily because it’s expensive to produce lots of individual things.

Is software development in the “craft economy” milieu?

By and large, every company is doing things differently. There are few standard practices, and what standard practices do exist — such as agile methodologies — are implemented quite deifferently. Software developers also have a dearth of tools to use; common wisdom says that it’s often easier to build your own toolset than to adapt existing offerings to the problem at hand. To be sure there are a few basic off-the-shelf tools that everyone uses — compilers, standard libraries, and code editors — but not every software group uses other essential tools: revision control systems (SCMs), rapid prototyping languages, automated testing systems, etc.

Most companies build components in-house for their own products but few commoditize these tools in ways that other development groups can use them. Of course, Java, COM, and vendor foundation classes do exactly this, but these are just a drop in the bucket of all the functionality a software developer needs to solve a particular task. There is a dearth of reusable code for purchase or free download.

Contrast software development with the manufacture of physical goods. Toyota and GM have a large number of vendors who build components that are to a great extent reusable by anyone: sheet metal, bolts, spark plugs, tires, radios, electronic control units, etc. Despite being rather sophisticated, radios from different vendors fit in the same hole (compilation), can easily be wired into any car (APIs), and have similar user interfaces. While there are specialized tools for specific tasks, for the most part, a wrench set is a wrench set is a wrench set. Tools vary in terms of price, durability, and the part they fit, but they are usally applicable to a wide variety of tasks.

In lean production, manufacturers avoid holding inventory, and parts arrive “just in time” for use. In software development and other knowledge work, teams are prized for their depth of knowledge and the expertise that they can apply to problems — not necessarily just novel problems. Groups need this experience because someday they may need to call upon it to resolve a problem almost identical to one they have already solved. Often extra frameworks are built into APIs needlessly because the engineer has a hunch what may be useful in the future, essentially storing knowledge in the product long before it is needed.

These thoughts should not be considered an indictment of software development. Clearly adopting some aspects of mass production (lean or otherwise) will translate into lower development costs; but should software engineering really be more like mass production than craft? Craft guild members experienced significant hardships when interchangeable parts gave birth to assembly lines, even rioting. Does the concept of a “software supply chain” make sense right now? What we call “software engineering” is still largely invention; the necessary conditions for software mass production may still be years down the road.

All things considered, I think the emergence of software mass production based on truly reusable components and a just-in-time supply chain is closer than most expect. Two factors will likely propel us there: open source projects and the net effect of business process outsourcing.

In my job I use a lot of open source software libraries . . . sometimes incorrectly called free software. (Free software definitely has lots of hidden costs: time spent learning an API’s syntax and capabilities, time spent interfacing two different products, time spent reviewing license agreements, etc.) These open source projects run the quality gamut, but the best provide first-class code that implements 90% of the functionality anyone would need for a given task. For my group that means reading and writing image and scientific data formats. Because using a library can easily save $100,000 in development costs (not to mention opportunity savings and the ability to bring new products to market quickly) the for-profit world is embracing open source, even if components aren’t really interchangeable yet. Some large companies, such as Adobe and Apple have placed discrete parts of their products into open source projects partly to encourage others to develop for their “platforms” and engender trust in their products.

Software project outsourcing currently accounts for a very small portion of overall software development. As software becomes more modular, it will be possible to shift even more small tasks to places where skilled or semi-skilled can do it more cheaply. (This is part of Thomas Friedman’s thesis in The World is Flat.) Furthermore, if companies like Infosys, Wipro, and Tata can hold onto the intellectual property from BPO projects, they have a perfect opportunity to create interchangeable software parts. Lots of small to medium-sized interchangeable components available at low or fixed cost: that sounds a lot like a supply chain to me.

What are your thoughts? Is there a software craft economy? Is mass production of software around the corner? Is software development too closely tied to invention or too different from making widgets to be comparable to manufacturing?

Posted in Book Notes, Software Engineering | Leave a comment

Color management mailing list

Color management is hard business. I think of myself as fairly savvy in this area, but it took me a long time to get the basics down. (I recommend Tim Grey’s Color Confidence and Fraser, et al‘s Real World Color Management, 2nd ed., for those who want a quick introduction and a thorough grounding.)

People who implement a color-managed workflow — including photographers who print their own images — may be interested in the ICC_Users mailing list.

Posted in Color and Vision, Computing | Leave a comment