Remembering the Future

REAL structured blogging is about tagging ENCLOSURES with standard metadata tags that enable anyone to find and subscribe to an easy to visualise and navigate downloadable enclosure file containing structured data,text,images,maps, and linked audio/video clips, with shopping basket and web services menu attached.

Topics: Microformats | RSS | Web2.0

averages are a very blunt instrument in engineering design. In engineering, averages are interesting and useful but we often need to go deeper. We need to know the limits - not the averages. What is the maximum system load? What is tha maximum document size? What is the maximum widgets-per-minute?

These are the key figures that drive the design of engineering solutions that really work rather than just work in the comfortable world of the average case. So the mantra is: explain things using averages, but engineer things using limits. The result will be (on average) better if you do.

Topics: Architecture | BestPractices

My observation is that the main technique Rails uses to improve developer productivity is code generation, even though Ruby's dynamic nature makes the code generation less obvious. The technique is also called metaprogramming, which simply means writing programs that write programs. Nevertheless, code generation is an old technique, and one I've used several times throughout my career to improve productivity.

. . .

However, to me what is important is simply that I'm expressing my intention in one place, and using a tool to generate other pieces of my system that can be determined from that one specification.

. . .

In my opinion, Rails applications feel like they require so much less code in great part because the generated code is hidden (but also because Ruby is concise in general). In our case at Artima, we see lots of generated .java files lying around in the midst of our project. On the other hand, we generate nice JavaDoc comments with our generated code, and so we get nice API documentation to look at if we want. If there's a problem or a question, we can go look at the generated code too. In Rails, it is just kind of magic. That makes it feel very lightweight, but if you ever encounter a problem with that magic, it might be more painful to solve it.

. . .

A database layer is often a good candidate for code generation, because these layers need to be updated whenever the database schema changes. If you only need to do something once, then writing a code generator is probably a bad idea. And even if you think you'll be doing this over and over, until you've done it several times by hand you probably don't know enough to automate. In our current architecture effort, we probably built about a dozen controllers by hand, and a dozen entities, before we felt we knew enough to automate.

I think programmers often don't like code generators that come from the outside, because like any framework they will often only take you 90% of the way you need to go. After that you start fighting the framework, which in a code generator often means you want to tweak the generated code. But that usually defeats the purpose of the code generator, which is to give you huge leverage. An exception are things like the scaffold generation in Rails, which is intended to just be a quick start that you edit and carry forward. Our in-house code generators are the kind where we aren't supposed to touch the generated code, and we solve the 90% problem because when we need to change the generated code, we change the code generator (since we wrote it, we can change it).

Topics: CodeGeneration | Programming | Design

1. Known-item
Known-item information seeking is the easiest to understand. In a known-item task, the user:

• Knows what they want
  
• Knows what words to use to describe it
  
• May have a fairly good understanding of where to start
  

In addition, the user may be happy with the first answer they find (though not always) and the task may not change significantly during the process of finding the answer.

. . .

2. Exploratory
In an exploratory task, people have some idea of what they need to know. However, they may or may not know how to articulate it and, if they can, may not yet know the right words to use. They may not know where to start to look. They will usually recognise when they have found the right answer, but may not know whether they have found enough information.

In this mode, the information need will almost certainly change as they discover information and learn, and the gap between their current knowledge and their target knowledge narrows.

. . .

3. Don’t know what you need to know
The key concept behind this mode is that people often don’t know exactly what they need to know. They may think they need one thing but need another; or, they may be looking at a website without a specific goal in mind.

This mode of seeking information occurs in a number of situations:

• Complex domains such as legal, policy, or financial. For example, a staff member may want to know how many weeks maternity leave they are entitled to, but may need to know the conditions surrounding that leave. We should read the terms and conditions of new products and services as there maybe important restrictions, but they are too often buried in legal garble that we don’t read.
  
• Any time we wish to persuade the user. For example, we would love people to know more about information architecture and usability, but they often don’t know that the concepts even exist. They may think they want to know how to make an accessible nested fly-out menu; we think they need to know more about organising the content properly.
  
• Unknown domains. For example, when someone is told by friends that he or she should check out a new service, product or website, but does not yet know why he or she would want to know about it.
  
• Keeping up to date. People often want to make sure they keep up to date with what is happening within an industry or topic, but are not looking for a specific answer.

. . .

4. Re-finding
This mode is relatively straightforward—people looking for things they have already seen. They may remember exactly where it is, remember what site it was on, or have little idea about where it was. A lot of my personal information seeking is hunting down information I have already seen. I don’t know how prevalent this is, but discussions with others indicate that I am not alone.

Topics: Design | Representation | Search

Each time an AJAX app fetches a resource, it could make note of the resource's Last-Modified and ETag headers. Later on when changing the same resource those headers would be sent by the AJAX app in the If-Unmodified-Since and If-Match headers respectively, along with the request. Effectively this is saying to the server "Only perform the operation if the copy of the server state matches what I saw last time"... That means Optimistic Locking for AJAX apps using plain old HTTP. Another nice part of this is that if the browser is doing a GET request, and the server state hasn't changed then the server will simply return a 304 Not Modified response. This skips the rendering of the view, and almost no data is sent along the wire to the browser. The browser will just render what it had cached locally, which as you can imagine is extremely fast all around.

Topics: Ajax | Rest | Techniques

Hot jobs this year don't necessarily offer high salaries and great perks. Instead, they're the ones most likely to be offshore-resistant, according to Foote Partners. These are the jobs that companies will keep in-house because they require business knowledge that takes time to acquire or expertise that isn't easily provided or managed from offshore.

Customer Facing

App developers

Web-apps programmers

Data-warehouse and business-intelligence specialists

ERP and CRM pros

Database developers and analysts

Help-desk specialists

Enablers

IT or business architects

Business analysts

Business technologists

Business-process modelers

Project managers

Infrastructure Jobs

Security

Data modelers

Network managers and engineers

Wireless engineers and administrators

Software engineers

Disaster-recovery specialists

System auditors and integrators

Storage administrators

Topics: Jobs

In English, when we say "the man rides the horse," our language forces us to think in terms of a subject, the man, and a verb phrase, "rides the horse." We get a clear visual image, but we pay a price. In Blackfoot language, the emphasis is on the physical feeling. It's a kinesthetic language, mostly verbs. So, in Blackfoot, to convey the same meaning, what's said is something like this: The way your body talks to you as you feel the movement of the horse beneath you -- that's the verb. The verb conveys the kinesthetic feeling of the horse under you. And then comes a bunch of verb modifiers which tell about the rest of the information in the sentence, such as details about the man, the speed of the horse, how long he's been riding, and, other things. The primary thing is the feel of the moving horse underneath you.

A second example is about the Blackfoot language itself. This comes from Leroy Little Bear. Leroy says there is no Blackfoot language -- it's just 800 variations on "to be." He makes it up out of root words as the experience flows through him.

The third example is again from Amethyst. She says there are no metaphors in Native languages. It only sounds that way when translated into English. In English, the meaning of the word is generally not connected to the way the word sounds -- mostly arbitrary assignments. Not so in the Algonquin language, of which the Blackfoot language is a member. Can you imagine a language in which the names of trees are assigned by the sounds that the leaves make in the fall of the year, when a gentle breeze is blowing?

. . .

Natives seemed to be describing a way of being, or a way of consciousnessing, or a way of knowing, which doesn't reduce, so to speak, or collapse a wave function. I know I've just made a big metaphor there, but [some light laughter].... but just to describe my experiences, it seemed as though you were describing a way of interacting or of being in life which doesn't create separation. And my understanding of quantum physics is that all of classical physics is about separation', quantum physics is about non-separation, and our effort to understand the link between the two comes to naught because we're trying to understand quantum physics from a point of view of separation. And so we're using separatist or a separating language to understand something which is essentially not separate.

Topics: Meaning | Language | Quantum