NYTimes writes:

Today there is a growing push for the nonprofit groups and banks that run such programs to reach deeper into the ranks of the poor, though there is little rigorous evidence juding whether the very poor benefit from microcredit, economists say.

Since 1988, the United States Congress has appropriated $2 billion for such programs. In new rules to take effect next year, it has put teeth into a requirement that half of American aid for these loans — defined as $1,000 or less in Europe and Eurasia, $400 or less in Latin America and $300 or less in the rest of the world — go to the very poor living on less than $1 a day.

The new rules have stirred strong opposition from other donors and a range of microfinance institutions, which contend that the industry may grow faster and ultimately help more very poor people by aiming at a wider pool that ranges from people who are struggling but not poor to those much further down the economic ladder.

Researchers for Bangladesh's largest microlender, the Bangladesh Rural Action Committee, or BRAC, have found that people near the poverty line are the main users of microfinance and are more likely to get more and bigger loans and build successful microenterprises.

By contrast, BRAC has found that the very poor are more likely to drop out of microcredit programs.

But the group's leaders say the microcredit industry needs to try new approaches to help the poorest people. They have coupled small loans with skills training and grants of food.

Always-On writes (via AP):

Wind power and other alternatives to fossil and nuclear fuels have one major drawback - they depend on nature to generate electricity.

A Norwegian company, Norsk Hydro ASA, presented a project Tuesday to overcome the problem of storing electricity when the wind dies, the sea calms, or the sun doesn't shine

It built two 600-kilowatt wind turbines and connected them with a hydrogen generator and a fuel cell to provide electricity for 10 homes on Utsira, a tiny town of 240 people on a wind-swept island about 18 kilometers (11 miles) from the mainland. Utsira is 320 kilometers (200 miles) west of Oslo.

When it's very windy, not unusual for Utsira, the wind turbines will produce excess power to produce hydrogen fuel in a process known as electrolysis - which splits water into hydrogen and oxygen.

That fuel will in turn power a hydrogen combustion engine and a fuel cell to generate electricity when the wind is not blowing.

"It is the first full scale project of this type in the world," said project manager Paal Otto Eide, whose company is leading the 40 million kroner (US$5.8 million) effort.

Hydrogen is considered by many to be a pollution-free fuel of the future. It is being also being tested as a fuel for cars.

"Utsira is a demonstration of what we could imagine as a hydrogen community in the future," Eide said.

Ten of the homes on Utsira hope to switch away from the country's traditional power grid on July 1 for a test lasting up to three years.

Jon Udell points to a column by Sean McGrath:

Reuse is interesting.

We always strive for reuse in the software we create. Some of the functions we use are timeless and occur over and over again. Interest rate calculations, the number of working days between two arbitrary dates, that sort of thing. We put these general purpose functions into so called 'libraries'. We try to reuse these libraries of functions over and over again through the parameters they give us access to. However, in most non-trivial software projects, there are many more custom-designed functions than there are reusable functions.

Parameterization is interesting.

Take interest rate calculations as an example. It does not take a financial guru to realize that the key numbers that need to be parameterized are the rate, the principle and the term. Unfortunately, as functions get more complex and more domain-specific, it becomes harder and harder to identify what numbers should be parameterized. For example, in a financial application, which aspects of invoice generation need to be parameterized and which do not? In a manufacturing application, which numbers need to be fed into the parts-reordering function and which do not? If we get the parameterization wrong, we will pay for it in costly code changes down the line.

Code changes are interesting.

A software application is nothing more than a mega-squadron of numbers, flying through lots and lots of functions (also made of numbers) in close formation. A gigantic, high speed display of numerical acrobatics. Smell the kerosene.

Given that it is all just numbers, the split between numbers that are easy to change and those that are not, is something that is under our control. Indeed, the very idea that there are numbers which can easily be changed and numbers which cannot be easily changed, is an engineering invention. It is *us* - not the machine - that creates that distinction. We write programs in things called 'computer languages' and we distill out the numbers we need with things called 'compilers'. The rest of the numbers, we put into containers with names like 'databases' and 'XML' and 'configuration files' and 'registries' and so on.

The latter type of number is one we can change relatively easily. The former we cannot, due to rules of the game that we, not the machine, impose.

Given that the phrase 'code change' is almost synonymous with 'cost' we need to think very carefully about parameterization during software design. We need to get our programmers engaged with the idea.

Programmers are interesting.

In order to stay sane, most programmers concentrate on the part of the problem they are working on today. As a consequence, their view of what pieces of the functions under development need to be parameterized and which do not, tends to be a quite low level. Indeed, most of the items programmers will chose to parameterize will amount to double dutch to the business analysts.

Ask a Web services programmer to parameterize an application and the result might be that you can swap XML parsers without significant code changes or use a different transport protocol without code changes. Ask a business analysts to parameterize an application and they will most likely wish to be able to change business logic without significant code changes or add fields to databases without significant code changes. The two views of parameterization are equally valid but poles apart.