Currently, image search engines (notably Google Image Search) locate and rank pictures based on the text describing them on a web page. This can lead to some very hit-or-miss search results — typing in “mcdonalds”, for example, gives you a wide range of images, many of them with little visual relevance to the McDonald’s fast food chain. (Irrelevant, that is, unless it turns out you actually are looking for photos of fat giraffes.)

The new system proposed in the Google paper ranks images based not on text, but on the common “visual themes” found in each search result. In the McDonald’s example, the VisualRank system would see that the company’s famous golden arches are a common visual theme, and prioritize pictures that feature the arches prominently. Tests of this new system returned 83 percent fewer irrelevant search results than Google Image Search, according to the VisualRank paper. (In the “search graph” below, the two large images in the center are ranked the highest because they feature the common visual themes in a search for “mona lisa” most prominently.)

If Google can deliver on its promises, VisualRank could bring a sea change to applications like product search, where customers are often want to find and compare specific products, but may not know the exact words to describe them. There are already product comparison startups, such as Like.com, that use visual search. But Google’s plan to the image ranking process is much more ambitious, which is probably why Munjal Shah, chief executive of Riya (which owns Like.com), told the Times that Google’s goals are “largely impossible.”

Whether or not that’s true is a debate better left to computer scientists. But wagering against Google’s search technology has been a sucker’s bet in the past.

Andrew Binstock and Donald Knuth converse on the success of open source, the problem with multicore architecture, the disappointing lack of interest in literate programming, the menace of reusable code, and that urban legend about winning a programming contest with a single compilation.

Knuth enthuses about Ubuntu and FVWM, sees little future in multi-core programming, and regrets that literate programming isn’t more widely liked. He also forswears unit testing, but the right to skip the testing phase is kind of something that you have to earn.

“Have you been surprised by the success of open source since that time?

Donald Knuth: The success of open source code is perhaps the only thing in the computer field that hasn’t surprised me during the past several decades. But it still hasn’t reached its full potential; I believe that open-source programs will begin to be completely dominant as the economy moves more and more from products towards services, and as more and more volunteers arise to improve the code.

For example, open-source code can produce thousands of binaries, tuned perfectly to the configurations of individual users, whereas commercial software usually will exist in only a few versions. A generic binary executable file must include things like inefficient “sync” instructions that are totally inappropriate for many installations; such wastage goes away when the source code is highly configurable. This should be a huge win for open source.

Yet I think that a few programs, such as Adobe Photoshop, will always be superior to competitors like the Gimp—for some reason, I really don’t know why! I’m quite willing to pay good money for really good software, if I believe that it has been produced by the best programmers.

Remember, though, that my opinion on economic questions is highly suspect, since I’m just an educator and scientist. I understand almost nothing about the marketplace.”

Read full interview script. Very very interesting read.

Souce: InformIT through Wired

“We are taking open to a whole other place,” Balogh said. “We are rewiring Yahoo from the inside out with a developer platform that will open up the assets of Yahoo in a way never done before, making the consumer experience social throughout and provide hooks to developers.” He noted that Yahoo has 10 billion latent connections across its properties, such as mail, messenger and fantasy sports.

Balogh discussed the technical architecture–known as YOS, or Yahoo Open Strategy–including an application platform that will allow developers to create apps for consumers to keep their data protected and to chose what data to share and with whom. In addition, Yahoo will unify all profiles for users and developers, which will allow the company to leverage the 10 billion relations and 500 million users to create the social graph of relationships and to manage the event stream.

“We are not creating another social network. We will rewire the entire experience to make it social. We don’t think of social as a destination but as a dimension,” Balogh said. Along with Google and MySpace, Yahoo is a member of the OpenSocial Foundation, which is developing a specification for building social applications.

The underpinnings of Yahoo’s effort include development tools, an application platform, a social platform that unifies all profiles throughout Yahoo (again, like Facebook or MySpace, this is a social graph that lets users make connections and view events) and the total rewiring of properties to make all this possible.

Yahoo’s new architecture, called YOS (Yahoo Open Strategy) proves that the Internet is made of tubes (Source: Yahoo)

The heady plans are smart but, quite likely, come too late.

“The role of an architect in software development has come under attack of late. On software projects, the title Architect is often ambiguously defined and the value provided by architects is not easily quantifiable. The perception that architects live in an “ivory tower” disassociated from the realities of delivering a software solution contributes to some of the animosity toward those of us with the title.

This article presents a defense of the practice of architecture in software development. It defines the qualities of an effective architect and describes the skills required to succeed in this profession. The article examines widely held perceptions of architects and some of the mistakes that architects make which contribute to negative perceptions. Ultimately, the intent is to show the value good architects bring to a software development effort.”

We do need Architect, if only everyone understood and agreed on what an architect does.

What do architects really do? What are their roles and responsibilities?

1. Defining the architecture of the system
All the usual technical activities associated with design. Understanding requirements, qualities, extracting architecturally-significant requirements, making choices, synthesizing a solution, exploring alternatives, validating them, etc.; For certain challenging prototyping activities, the architects may have to use the services of software developers and testers.
2. Maintaining the architectural integrity of the system
Through regular reviews, writing guidelines, etc. and presenting the architecture to various parties, at different levels of abstraction and technical depth.
3. Assessing technical risks
These role is in support of project management, but on very technical risks, managers may not have the expertise to identify and
4. Working out risk mitigation strategies/approaches
5. Participation in project planning
6. Proposing order and content of development iterations
For many effort estimation aspects, or for the partition of work across multiples team, managers need the assistance of architects.
7. Consulting with design, implementation, and integration teams
Because of their technical expertise, architects are drawn into problem-solving and fire-fighting activities that are beyond solving strictly architectural issues.
8. Assisting product marketing and future product definitions
The architects have insights into what is feasible, doable, or science fiction and their presence in a product definition or marketing team maybe very effective. As you see, beyond item #1, many activities involve some other party: project management for example, and are not merely focused around the architecture, the design, the architectural prototype.

We need also to keep in mind that the good architects should bring a good mix between domain knowledge, software development expertise, and communication skills. Once we identify (and possibly refine) the long list of what we expect the architects to be doing, the next question is: how do we keep a good balance between all these activities. How do we avoid the temptation to always, day after day, week after week, solve the most urgent problem, or the most interesting problem, or extinguish the latest fire? (The squeaky wheel syndrome) Or conversely bring forward the question: do we have the right people with the right expertise in our current software architecture

Your thoughts? Please share your comments!

References

Kruchten, P. (1999). The software architect, and the software architecture team. In P. Donohue (Ed.), Software architecture (pp. 565-583). Boston: Kluwer Academic Publishers