User: tmoertel

Or: sign state cryptographically

On: Top 10 Vulnerabilities in Web Applications

When your application's state-management strategy relies upon passing state back and forth between the server and the client, never trust any state sent from the client. The previous poster suggests that you validate from-client state against server-side session state, in the example verifying that the message to be updated is actually owned by the authenticated user in session state.

However, not all state can be validated in this way, and even when it can, it may not be practical to design validation tests for each and every item of state that can be received from the client.

Another approach is to cryptographically sign each package of state that the server hands to the client and then test that the signature is valid when the client returns the package to the server with a future request. This eliminates the need to use session state (which may not be possible in some apps) and also eliminates the need for item-by-item validation tests.

Accessibity, in a nutshell: do it

On: Constructing Accessible Web Sites

I'm surprised at how many people are complaining about having to make their web sites accessible. Why is this such a big deal? It's easy to do and helps not only people with disabilities but also you the creator of the web site.

Why? Here's the quick course:

On the web, the primary way that information is represented is in the form of HTML and XML documents.

Neither HTML nor XML was designed as a visual medium; rather, both are intended to represent information in a manner that is independent of presentation.

However -- and this is where the problems start -- almost all other media that designers and content creators have experience with (e.g., the ever-popular ink on paper) are visually oriented media, and so many designers and content creators approach web media with this bias.

As a result, all too many web sites are designed with the goal of looking a certain way instead of communicating the intended information clearly. This is an understandable error because with most other media (e.g., ink on paper), these two goals are one and the same. But it is still an error.

To correct the error requires nothing more than the following:

1. Make sure that the designers and creators clearly understand what is to be communicated, not merely how it looks.
2. Make sure that each piece of information to be communicated is represented explicitly, not relying upon a particular visual interpretation to convey its meaning. For example, if you want to represent the text "Chapter 1", use the plain text "Chapter 1"; do not use GIF whose pixels can be read as "Chapter 1" when visually interpreted. (If for some reason you are compelled to use the GIF rendering, annotate it (via ALT) with the text "Chapter 1" so that the underlying information is once again made explicit. Note, however, that unless there is a compelling reason to do otherwise, it is best to use the plain text. Being able to render text in your pet font is not a compelling reason.)
3. Then, once the information is represented clearly and explicitly, attach style sheets to lend the desired visual (and other) presentations to the information.

Even if your web site's audience does not include people with disabilities, there are many good reasons for making your site accessible:

• Information in an accessible site is readily available to web crawlers, indexing agents, and search engines. As a result, an accessible site is more likely to be properly scanned, categorized, and presented as a valid search result to people who may be interested in your site. In short, accessible web sites are easier to find. Therefore, if you want a larger audience, make your site accessible.
• Making your site's information explicit and independent of any particular presentation makes it easier to change your site's content and easier to change your site's design. It also makes it easier to delegate one or both of those tasks.
• Accessible web sites are also well-formed and valid (i.e., conform with the appropriate HTML and XHTML document type definitions). This eliminates a class of "browser errors" and makes accessible sites easier to process with automated tools such as machine translators, indexers, and so forth.
• Finally, it is often easier to build a great web site by separating the content from the presentation than it is to muddle these concerns and attempt to manage them as one. After you build a few web sites that enforce this separation, you'll never want to go back to the old way.

There you have it. When doing the right thing is easier, why not do it?

Are you sure you don't have it backward?

On: ICFP 2002 Contest Winners Announced

The trouble is, that functional languages, while they may be more powerful, are much harder to write well in, generally taking you far longer to get to the finished state you want.

Are you sure you don't have it backward about the amount of time it takes to write software in functional languages? Most of the people I know who are good programmers of both functional and imperative languages consider the former to be considerably more efficient when it comes to programmer time. My experience with functional vs. imperative languages has certainly shown this to be the case. Likewise, industry groups that have made investments in functional programming have found significant increases in programmer productivity.

But don't take my word for it:

• Prototyping Real-Time Vision Systems: An Experiment in DSL Design (1998) Abstract: We describe the transformation of XVision, a large library of C++ code for real-time vision processing, into FVision (pronounced "fission"), a fully-featured domain-specific language embedded in Haskell. The resulting prototype system substantiates the claims of increased modularity, effective code reuse, and rapid prototyping that characterize the DSL approach to system design....
• Four-fold Increase in Productivity and Quality: Industrial-Strength Functional Programming in Telecom-Class Products (PDF) Abstract: The AXD 301 ATM Switch is the flagship in Ericsson's line of Datacom products. A fault tolerant and highly scalable backbone ATM switch, AXD 301 has enabled Ericsson to take the lead in the migration of public telephony networks to becoming true multiservice networks, offering both quality voice and broadband data services on the same backbone.... This paper demonstrates how the development of such systems is supported by the Erlang/OTP technology. The Erlang [functional] programming language was developed by Ericsson specifically for the purpose of building fault tolerant, distributed and complex systems.... The paper demonstrates how Erlang supports the characteristics mentioned, while offering unusually high productivity.
• Haskell vs. Ada vs. C++ vs. Awk vs. ... : An Experiment in Software Prototyping Productivity: Abstract: We describe the results of an experiment in which several conventional programming languages, together with the functional language Haskell, were used to prototype a Naval Surface Warfare Center (NSWC) requirement for a Geometric Region Server. The resulting programs and development metrics were reviewed by a committee chosen by the Navy. The results indicate that the Haskell prototype took significantly less time to develop and was considerably more concise and easier to understand than the corresponding prototypes written in several different imperative languages, including Ada and C++.
• Functional languages in microcode compilers (ACM Digital Library). Abstract: This paper discusses the advantages of using high-level languages in the development of microcode. It also describes reasons functional programming languages should be considered as the source language for microcode compilers. The emergence of parallel execution in microarchitectures dictates that parallelism must be extracted from the microcode programs. This paper shows how functional languages meet the needs of microprogrammers by allowing them to express their algorithms in natural ways while allowing the microcode compiler to extract the parallelism from the program.

You can find more such papers by tracing references and by reasonable application of Google and CiteSeer.

From what I saw, it went like this . . .

On: ICFP 2002 Contest Winners Announced

I am at ICFP this week and was at the presentation of the contest results this afternoon. The judge's scoring method, iirc, went like this:

1. All of the robots were subjected to a battery of solo games and games against reference robots provided by the judges
2. The twenty highest-scoring robots went to the second round and played a number of games against each other.
3. The eight highest-scoring robots went to the third round and were subjected to further games.
4. Finally, the top two robots battled on symmetrical maps with each being allowed to start from the various starting points an equal number of times (to rule out starting-point bias).

The judges indicated that they would be posting more information later. The conference is still going on (in fact, ICFP is part of PLI, which is going on through 8 Oct), so give the guys a chance to get home and write something up. You'll get the details in due time.

Ability, luck, and language -- in that order

On: ICFP 2002 Contest Winners Announced

Programming ability almost always dominates all other controllable factors, including choice of programming language, when it comes to most programming tasks.

Simply put, programming languages are tools. Some tools make certain jobs easier than others, but tools only go so far. The rest is up to the programmer.

In the case of this year's ICFP contest, Team Radical Too did well because they had a good strategy that ultimately fared well in judging. Their robot performs a semi-exhaustive simulation of the possible moves up to a certain degree and then chooses the best move based on the simulation results. (It's a cool approach, and the source code is worth a read.)

It's a compute-intensive strategy, and my guess is that they selected selected C as their implementation language for this reason. They made the decision to sacrifice the high-level flexibility that other languages provide in order to have C's low-level control over how CPU cycles and memory are consumed.

Oh, and then there's luck

Despite how much we like to argue about programming ability and choice of programming language -- and competitions are perfect fuel for this particular fire -- we shouldn't read too much into the results of programming competitions. Luck plays as large role as any.

I returned, and saw under the sun, that the race is not to the swift, nor the battle to the strong, neither yet bread to the wise, nor yet riches to men of understanding, nor yet favour to men of skill; but time and chance happeneth to them all.

In the case of the 2002 ICFP Programming Contest, for example, I happen to know that several of the robots, including Team Radical Too's robot, will unwittingly commit suicide in situations where they have the opportunity to push another robot into lethal water that spans more than two board cells. In this situation, the attacking robot will push its victim into the water, killing it. The victim, although dead, appears on the game board the next turn (and is removed from the game on the turn after that). However, the attacking robot's logic fails to account for the fact that dead robots can remain on the game board for a turn before they are removed by the game server. It considers any robot on the game board to be alive -- including the now-dead victim, floating in its watery grave -- and hence fair game for attack. Seeing that there is water beyond the now-dead victim, the attacking bot will try to push it again, thus stepping into lethal water itself and effectively committing suicide. Oops.

Luckily, the judges didn't have any wide spans of water in the map used for the final showdown.

Indeed, chance happeneth to them all.

Yes, you can put form elems in tables

On: Opera 6.03 - The Wild Child of Browsers?

W3 validators say I can't put form elements in tables!!!! Hello?

You can put form elements in tables. What you probably did was hose up the element nesting by placing your FORM inside of your TABLE. If you look closely at the validator output, it will tell you where you hosed your nesting.

If you inspect the HTML 4 Transitional Document Type Definition, you would see that FORM elements may contain %flow; content -- which includes both inline elements and block elements like tables. So if you want to do it right, place your TABLE inside of your FORM, not the other way around, and then place the form elements inside the appropriate table elements.

Easy as pie.

See beyond mere trees

On: The Myth of Open Source Security Revisited v2.0

Let's cut back to the big picture. Pick any desirable characteristic of software -- resource efficiency, robustness, quality, and, yes, even security -- and guess what? The process by which the software was created largely determines how much of that characteristic the software exhibits. Good work, good code. Crappy work, crappy code. Not exactly a news flash.

Now -- and here's the important part -- take any software, developed by any process, and then consider any desirable characteristic. Do you get more of that characteristic by letting everybody see the source or by keeping it hidden away?

That's the argument for open source.

[As I responded to the author's original posting on Kuro5hin.]

The real limiting factor . . .

On: Are There Limits to Software Estimation?

The real limiting factor is not the estimating, itself, but knowing what to estimate. For example, imagine that you had the Holy Grail of estimating -- a perfect estimating function f. Given some work X to be performed, f(X) would tell you exactly how much effort the work would require -- perfectly, every time.

Now, what good is f? On most software projects, f wouldn't be worth much. Why? Because nobody knows what X is. X is a specification of the work to be done (i.e., software requirements), and most such specifications are woefully incomplete, imprecise, and erroneous.

That's why development processes that are repeatable and emphasize increased formalism allow for better estimates. They provide higher-quality X values, not to mention better approximations of f based on past performance. Therefore, if long-term estimates are important to your business, climb the formalism ladder.

On the other hand, good long-term estimates are often unnecessary. Many business need only to know where the project is now and to be able to change directions with reasonable efficiency when business needs change or realities are better understood. Witness the effectiveness of so-called agile development processes in turbulent business environments.

So, in the end, the only real lesson is to pick your software development (and estimating) process to support your business. Doing it the other way around usually doesn't work.

Re:Perl vs. PHP ?

On: When Making a Comprehensive Retrofit of your Code...

Could I possibly ask for a fairly realistic little example of something that Perl does well that PHP can't?

Middleware.

For example, most enterprise applications do something important -- trade shares, manage accounts, track patient records, etc. How it's done is governed by business logic -- the company rules, policies, regulations, procedures, and so on. Now, you can spread this logic across your web site (as one might do using PHP, which is tied to the web site). Or you can bundle it up into an independent application, keeping all of the business logic in sensible, cohesive compartments that run on an application server (e.g., using one of the existing Perl app servers or one you've rolled yourself via, say, POE). This not only makes the business logic easier to understand and manage but also makes the logic independent of and accesssible from any number of front ends that you might need. Simultaneous web, client-server, and even command-line interfaces become possible, and for enterprise projects, multiple simultaneous interfaces is often a requirement for backward compatibility with older interfaces.

In summary, for shallow web-only stuff, PHP is a reasonable tool. For stuff beyond web work, PHP is out of its design envelope. However, Perl works here just as well as it does for web work.

Perl is a *tool*

On: When Making a Comprehensive Retrofit of your Code...

Perl is for system administrators and system administrators-cum-developers, not real software development.

Baloney.

Contrary to what lots of people around here seem to think, especially those who like to make wide-sweeping declarations about what things are and what they are not, Perl is a tool. Nothing less, nothing more. Like all tools, it can be used to create well-engineered systems, and it can be used to create crap.

The community that grew up around Perl is all-welcoming and generally free of elitism. That's why a lot of newbie programmers and "system administrators-cum-developers" use Perl -- because they can without getting crapped on by others who think they know better. As a result, there is a lot of ametaurish-looking Perl code out there, but that's not a result of the language, that's a result of the all-inclusive set of people who use Perl.

Let's be clear: If you write code in any language and the code sucks, it's your fault, not the language's -- the language is just a tool.

Don't blame the problems of programmers on their tools.

I second that and add the following . . .

On: Home Server Rooms?

I have a similar setup in one small room: about 8 to 10 computers (varies depending on how many servers are on loan), 40-port HP ProCurve-4000M, three dedicated lines into the house, and lots of blinkin' lights. As the guy who sits in that room about ten hours a day, let me heartily second your recommendations and add the following:

• Racks are helpful for space management and organization. If you don't need or want the expense of computer rack units, restaurant shelving makes for a great homebrew rack system. It's attractive, easy to clean, and sturdy (get the kind with the diagonal cross-braces).
• A label maker is indeed a lifesaver. I have a handheld Dymo and it has prevented innumerable cable hunts. Get one.
• Noise is indeed the big challenge. My room is carpeted, which helps a lot, but even so high-speed server disks emit an ear-rending whine that over time bores into one's very soul. While I can live with the starship-like background hum that ebbs and flows as countless CPU and power-supply fans compete for air, the drive noise is too much to bear. With my old setup, I would occasionally notice that two drives spinning at slightly different speeds would cause an barely-audible throbbing at their beat frequency. Drove me nuts. I finally solved the problem by cheating -- I swapped out the noisy drives for quieter ones. I have a small graveyard of 9.1-GB "screechers" just waiting to be resurrected as storage for a server I can deploy at somebody else's site. ;-) Lesson: When you shop for drives that will be sitting beside you for months, always check the noise levels.
• Think about the electrical situation. More circuits == better. My house is old, and my lab has only one dedicated circuit. I've pretty much maxed it out and wish I had more. Regardless of how many circuits you have, beefy UPSes are highly recommended, especially ones that have voltage adjusting features to help ride out brownouts and other under-voltage conditions, which are particularly damaging to computer electronics and are likely if you have motors on the same circuit. If you need more uptime insurance, get a generator. My lab circuit is backed by a generator, but it's loud and annoying, so I recommend choosing UPSes that are big enough to ride out all but exceptionally long outages. Also, the power that comes from small generators tends to be noisy, so if you have one, make sure that your UPSes are good at filtering.

One fix . . .

On: Distributed Spam Detection

for abusers who report bogus signatures is to count the number of times each signature is reported and only consider a report valid after the count exceeds a threshold value. Real spam mailings would be reported many times each from distinct nodes and would be easy to distinguish from bogus signatures, which wouldn't be as widely reported.

Or in Haskell ...

On: Kent M. Pitman's Second Wind

... via list comprehension:

[ (x,y) | (x,y) <- zip [0..] someList, goodResultQ y ]

The "conservation" alternative

On: Slashdot Updates

Slashdot continues to grow: our traffic has increased by like 10% in the last few months, ...

The Slashdot bandwidth situation seems a lot like America's oil situation: Just about everybody seems content to use more and more of both.

But, rather than feeding this trend and turning to more-obnoxious ads to cover the increased bandwidth, why not turn to conservation-based approaches? In short, reduce the bandwidth consumed for each page.

For example, a quick glance at the typical story's HTML reveals a lot of bloat, most of which could be removed by taking look-and-feel instructions out of the HTML and placing them into stylesheets. More than 10 percent savings seems realistic. And, unlike banner ads that have harmful side effects (such as annoyed readers), reducing HTML bloat has positive side effects like reduced download times and increased accessibility.

So before turning to increasingly evil ads, why not try conservation?

Avoiding swap saves time

On: Run Mac OS X On Those Old Macs

The compression certainly takes some CPU time, but it's a lot faster than swapping to the hard drive. Hence the overall performance win.

Re:What's wrong with Haskell?

On: Esoteric Programming Languages

I happen to think that Haskell [haskell.org] is one of the semantically cleanest languages out there

I was going to say in my earlier post that Haskell had the cleanest syntax and semantics, but I figured that regarding the latter some smart-aleck (which I suppose is now going to be me) would respond with a comment like this: Oh, really? Care to provide the clean semantics for Haskell's run-time space-consumption characteristics? At present the semantics are often best described by, "run it, and see what happens," although after a while one does develop a feel for it (which is incorrect more than one would like).

For example, consider the expression,

foldl1 (*) [1 .. 1000]

which literally means

(...((((1 * 2) * 3) * 4) * 5) ... 1000)

and, by the way, is equivalent to your (fact 1000). Now, how much space is going to be consumed by its evaluation?

Humans can easily see that the expression can be evaluated left to right, treating the operator (*) as strict, and, with the list defined by [1..1000] being built lazily, it is possible to evaluate the expression in constant space:

= foldl1 (*) [1 .. 1000]
= foldl (*) 1 [2 .. 1000]
= foldl (*) 2 [3 .. 1000]
= foldl (*) 6 [4 .. 1000]
= foldl (*) 24 [4 .. 1000]
= ...

But is this what Haskell guarantees? Nope. An implementation might also do it like this:

= foldl1 (*) [1 .. 1000]
= foldl (*) 1 [2 .. 1000]
= foldl (*) (1*2) [3 .. 1000]
= foldl (*) ((1*2)*3) [4 .. 1000]
= foldl (*) (((1*2)*3)*4) [5 .. 1000]
= ...

In this case the accumulator in foldl builds up a linear chain of thunks, which is evaluated only after the entire list is consumed.

You and I can see that the second method is wasteful, but the language definition provides no guidance as to whether a Haskell implementation will choose the second or the more-efficient first. (In fact, GHC would until recently choose the second for this expression.)

Don't get me wrong. Haskell is, without a doubt, my favorite language. It's what I used for my entry in this year's ICFP Programming Contest, and I consider it the best hope for a truly great mainstream functional programming language. I love Haskell. But its lack of intuitive space-consumption semantics is a serious weakness.

And, regarding your fact example, it doesn't really show off Haskell's semantics as much as its syntax. Why not show the classic Fibonacci Series implementation, which highlights Haskell's non-strict evaluation semantics?

fibs@(_:fibs') = 1 : 1 : zipWith (+) fibs fibs'

Now, if that isn't a beautiful line of code, I've never seen one.

The fastest FFT library out there is in C, but the C code itself was generated by Haskell code

Actually, the FFTW code was generated by code written in O'Caml not Haskell.

Cheers,
Tom

What's wrong with Haskell?

On: Esoteric Programming Languages

Haskell is the cleanest language I've ever seen. Elegant whitespace handling, pattern matching, and concise yet clear notation.

Care to elaborate on what you think is wrong with it?

Back to basics

On: What's The Future of DRM?

I don't know what the future of DRM will be, but I know what it should be. It should be something that primarily promotes the public good. As such, it ought to reflect an exhaustive re-examination of the concept of a "copyright".

Originally intended to provide a public benefit -- to encourage and promote the widespread availability of information -- copyright law has been distorted to the point where it allows a powerful few organizations to control vast seas information, allowing access only those who can pay fees that are often unreasonable. Gone, too, are the days when we could realistically expect copyrighted material to be contributed to the public domain after a reasonable period of time. Our national concept of "copyright" is a perversion.

Before we legislate "rights management" into hardware, we ought to ask why we have these "rights" anyway. And if the answer isn't solely to promote the public good, we should do away with them.

Emacs, naturally

On: RSI, WIMPs and Pipes; What Next?

Might any of you have ideas on what form these input devices might take?

They might just take the form of Emacs.

I'm serious.

No, really.

Nothing gives me hand pain as quickly as using mice, especially ones with that wheely thing. Keeping my hands in good form over the "home row" of my keyboard -- and away from the mouse -- has virtually eliminated pain from my computing life. I spend half of my waking hours in Emacs, and I have come to love (and depend on) its there's-a-key-for-everything nature.

Dump the mice. Keep Emacs.

Hidden "features" like spyware, rights management?

On: More on the Replay TV 4000

Two questions:

1. What kind of information about users will these units gather and transmit back to ReplayTV?
2. Do these units incorporate any kind of "rights management" system that would infringe upon fair use or home-recording rights?

You *can* change font sizes in GNU/Emacs

On: VIM 6.0 is Out

On many platforms a font-change dialog is bound to Shift-Mouse1. You can also customize the default font programmatically. Here's one way, which I use to set the default font to 8-point Andale Mono:

(custom-set-variables
;; other customizations ...
'(default-frame-alist
(quote ((menu-bar-lines . 1)
(font . "-*-Andale Mono-normal-r-*-*-11-82-96-96-c-*-iso8859-1")))))

For other methods, check the manual.

A deeper look . . . and fundamental problems

On: How Would Crypto Back Doors Work?

It is impossible to prevent terrorists from using strong cryptography. Terrorists already use it and would continue to do so if it were illegal. However, if it were illegal, the number of messages that would be unreadable by law-enforcement personnel would be vastly reduced. Any remaining unreadable messages would provide strong evidence that the senders, and perhaps the intended recipients, are involved in some form of illegal activity, at the very least the illegal activity of using unapproved strong cryptography.

Thus the primary purpose of the proposed legislation is not to allow law-enforcement personnel to read terrorists' communications -- terrorists will continue to use unreadable, strong cryptography -- but rather to narrow the search space that law-enforcement personnel must examine when hunting for suspected criminals. One would presume that if a person were discovered to have used unapproved cryptography, such evidence alone would be sufficient to obtain warrants for full searches, wire-tapping, keyboard recording, and the like, and those additional measures would likely yield hard evidence of any additional illegal activities. Thus it is not necessary to decrypt the criminals' messages: The illegally encrypted messages alone are sufficient to reveal suspects, and then old-fashioned investigative methods are likely to be effective.

Of course, the effectiveness of this law-enforcement technique depends on having a practical and enforceable definition of "unapproved cryptography". The problem for law-enforcement personnel -- and law-abiding citizens who wish to protect their legitimate secrets -- thus becomes determining what constitutes an illegally encrypted message. It is well known that a message that has been encrypted with a one-time-pad cannot be distinguished from a string of random bits. Should the government also make access to true randomness illegal so that any string of bits that seems sufficiently random can be assumed to be an illegally encrypted message? Further, is it realistic to believe that covert channels and steganography are detectable?

If not, how will law-enforcement personnel detect illegally encrypted messages? And what if they can't? In that case, what real security have we citizens purchased by sacrificing our liberties?

Those are the questions I want my government to answer. Until they are answered -- and hard evidence provided to support the answers -- I must remain sceptical.

XML has *already* succeeded

On: XML in a Nutshell

I think you misunderstand the main application of XML. It's not simply a better HTML. Rather it is a simple way to represent information richly, in a format that preserves the underlying meaning. (SGML does this, too, but is much a heavier representation.) With XML you can define document types and schemas that define the syntax of documents, and you can then associate your own semantics with the document types to capture the meaning of your information. Thus can you represent your information electronically without diluting or distorting its meaning. The "win" is that XML conforms to your information, not the other way around.

All HTML documents, by contrast, are HTML documents. Does an H1 element represent a chapter title, a section title, a heading, or just a line of bold text separated from the rest? Who knows? The content and the presentation are mixed together in a one-size-fits-all syntax that forces you to throw away the underlying meaning of your information when you shoehorn it into HTML.

For example, I'm working on a web site to help people affected by breast cancer. The main value of the site is the information it contains, so you can be darn sure that I'm preserving the information's meaning. I'm not using XML as a better HTML but rather as a rich medium that captures all of my information's value. Once captured, the information is easily "extruded" into HTML for web presentation, simple HTML for Palm and hand-held devices, and typeset pages in PDF for offline reading.

Make no mistake about it, XML is already a winner.

Take 'em down a notch . . . ICFP style!

On: How To Deal With (Techie) Prima Donnas

Suggest to your local prima donna that he enter the ICFP Programming Contest. Muse aloud that, since he's such a brilliant programmer, he has a pretty good chance of winning. Tell him that the bragging rights ought to be priceless around the office, and I'm sure that he'll bite and actually enter.

Then, let the contest do the work for you. Watch as your prima donna gets functionally mauled and then garbage collected into oblivion by some of the most talented programmers in the world. Most likely, your elite coder boy won't even understand the challenge task. (Anybody remember the '99 task? Ouch.)

From that point on, subtle reminders of his contest performance will keep your boy in check. "Gee, I thought you would have managed to finish the first part of the challenge task, at least. You must have been sick or something. Well, there's always next year's contest!"

Try not to chuckle aloud when he mentions that he won't be entering next year because of vacation plans.

8 to 9 bars is optimum

On: Optical Feedback For Perfect Coffee

8 to 9 bars is where the best espresso extraction occurs. And good espresso is the ultimate coffee.

Many good espresso machines have high pressure pumps that can sustain 15+ bars, but the extra pressure is for headroom: The machines are engineered to deliver 8 to 9 bars of pressure to the compressed coffee puck, assuming proper packing. Higher pressure can leach undesirable flavor compounds from the coffee and is to be avoided.

For more, see David Schomer's "Factors in a Perfect Cup (of espresso)" or for deep coverage read Illy and Viani's Espresso Coffee : The Chemistry of Quality.