Можете ли вы доверять?

Еще одно достойное пополнение коллекции.
Ссылку, конечно же, неподготовленным людям открывать не рекомендуется.
Для безопасности латинские "с" и "о" в ссылке заменены на кириллические.
____
from: Capt. Sam Dennison cptden7@3moffice.co.cc
reply-to: denison_sa@live.com
date: Mon, Dec 12, 2011 at 2:54 AM
subject: б

Я капитан Сэм Dennison, U.S армии. Я на ходу в Афганистан из Ирака, у
меня есть некоторые пункты, которые я придется отправить к вам. Можете
ли вы доверять?
Будет ли объяснять дальше, когда я получаю ответ от Вас.

Пожалуйста, просмотрите эту ссылку: http://news.bbс.со.uk/2/hi/7444083.stm
Read more...

Плевательница

Я при себе

Ничего не разрешаю себе уничтожать. Все старые вещи при мне. Мне пятьдесят, а все мои колготочки при мне, все ползуночки, носочки, трусики, маечки, узенькие плечики мои дорогие. Тоненькие в талииньке, коротенькие в ростике. Дорогие сердцу формочки рукавчиков, ботиночки, тапочки, в которых были ножки мои, ничего не знавшие, горя не знавшие ножки. Фотографии перебираю, перебираю, не выпускаю. Ой ты ж пусенька. Это же я! Неужели? Да, я, я. Документики все держу: метричку, справочки, табель первого класса, второго, дневники, подправочки, все документики при себе, все справочки мои дорогие, пальцем постаревшим разглаживаю немых свидетелей длинной дороги.

Все честно, все документировано, ни шагу без фиксации. В случае аварии, какую книгу хватаете на необитаемый остров? Справки. Вдруг сзади – хлоп по плечу. А-а! Это на острове?!..

– Где был с января по февраль тысяча шешешят?..
– Вот справка.

– Где сейчас находится дядя жены?
– А вот.

– Где похоронен умерший в тышяшя восемьдесят брат папы дедушки по двоюродной сестре?
– Парковая, шестнадцать, наискосок к загсу. От загса десять шагов на север, круто на восток, войти в квартиру шестнадцать и копать бывшее слободское кладбище.

– Куда движешься сам?
– А вот направление.

– А как сюда попал?
– А вот трамвайный билет.

Все! Крыть нечем. Хочется крыть, а нечем.

– Лампочку поменял?
– Вот чек.

– Что глотнул?
– Вот рецепт.

– Почему домой?
– Вот бюллетень.

– Куда смотришь?
– Вот телевизор.

– Какая программа?
– «Время».

– А четырнадцатого откуда поздно?
– Вот пригласительный билет, галстук, букет.

– Так... плитка в ванной, унитаз.
– Вот чек.

– Карниз ворован?
– Вот чек.

– Обои ворованы?
– Чек.

– Это воровано?
– Чек.

– Воровано?
– Чек.

– Тьфу!
– Плевательница.

Ох и хочется крыть. А нечем!

– Как найти в случае?
– Вот папа, мама, дядя, тетя, дом, работа, магазин, больница... Все.

– А если?..
– Вот регистратура.

– А все-таки если?
– Вот, вот и вот.

– С другими городами?
– Ничего.

– Санаторий?
– Ни разу.

– По-английски?
– Ни бе ни ме.

– Где?
– Здесь.

– А если?
– Соображу.

– А непредвиденно?
– Позвоню.

– А самому захочется?
– Спрошу.

– А если мгновенно – ответ?
– Уклончивый. Да зачем вам трудиться? Вот список ваших вопросов, вот список моих ответов, причем четыре варианта по времени года.

– Заранее?
– Да.

– Сообразил?
– Да.

– Такой честный?
– Характеристика.

– А не участвовал в развратной компании шесть на четыре, девять на двенадцать с пивом, журналами, банями, парной?
– Грамота об импотенции, участковый врач, соседи, общественность.

– При чем состоишь? Воровал?
– Водоканал.

– Тьфу ты.
– Плевательница.

– Пока...
– Все.

С высоко поднятой головой хожу. Некоторые издеваются: справки – это все, что ты накопил к старости? – Все! Причем это копии. Оригиналы закопаны в таком месте, что я спокоен. И не только я. Глядя на меня, другие светлеют. Значит, можно, значит, живет. Всем становится спокойнее. Самые строгие проверяющие теплеют, на свою старость легче смотря. Один с дамой подошел:

– А где вас искать после вашей внезапной кончины, которая произойдет...
– А второе интернациональное, сто восемь – по горизонтали, шесть – по вертикали, от пересечения три шага на север, в боковом кармане свидетельство.

– Поздравляю, выдержал, готовьтесь к следующему.
– Отметьте.
– Идите.
– Число, час, печать. Здесь, здесь, здесь.

Чуть больше времени на выход. Зато не только свободен, но и спокоен, что действительно вышел, действительно пошел, действительно пришел домой и совершенно искренне лег спать.
Read more...

Java Day Riga 2011 - registration started!

Time: November 29th, full day event from 10-00 to 18-00.
Place: Tallink Hotel Riga, 24 Elizabetes, Riga, Latvia.
REGISTRATION (190 free tickets left at the moment of writing this)


SPEAKERS

Alexander Potochkin, Software developer at Oracle St. Petersburg
Sergey Kuksenko, Performance engineer at Oracle St. Petersburg
Martin Grebac, Principal Software Developer - GlassFish/Metro team & JAXB Lead at Oracle Czech

Jevgeni Kabanov, CTO of ZeroTurnaround
Jevgeni Kabanov is the founder and CTO of ZeroTurnaround, a development tools company that focuses on productivity. He wrote the first version of the ZeroTurnaround flagship product, JRebel, a class-reloading JVM plugin.

Jevgeni has been speaking at international conferences for over 5 years, including JavaOne, JavaPolis/Devoxx, JavaZone, JAOO, QCon, TSSJS, JFokus and so on. Jevgeni also started the first Java conference in Estonia, Geekout. He has an active research interest in programming languages, types and virtual machines, publishing several papers on topics ranging from category theoretical notions to typesafe Java DSLs.

Jevgeni is on the Expert Group for the JSR 342 (Java EE 7). He has started two open-source projects -- Aranea and Squill. You can follow Jevgeni on Twitter as @ekabanov. See http://lanyrd.com/people/ekabanov/ for conference history and schedule.

Alexey Shevchuk, Lead developer at Odniklassniki.ru

Martijn Verburg, London Java User Group
Aka 'the Diabolical Developer', A Dutch born Kiwi who's a Director at TeamSparq - a consulting and mentoring start-up in London. Outside of TeamSparq he herds Cats in various Java and open source communities and is constantly humbled by the creativity and passion found there. Currently he resides in London with by kick-boxing wife where he co-leads the LJC - London's Java User Group (a JCP EC member), runs a couple of open source projects & tries to find time for a pint at his local. You'll find him online moderating at the Javaranch or discussing (ranting about) subjects on the Programmers Stack Exchange site. He's also a regular speaker at conferences (TSSJS, Devoxx, JavaOne etc) on Java, open source and software development and is finishing off his first Manning title - "The Well-Grounded Java Developer" with Ben Evans.

Claus Ibsen, Principal Software Engineer at FuseSource.
Claus Ibsen is a software engineer and integration specialists from FuseSource (http://fusesource.com/). Claus is a full time committer on the open source integration framework Apache Camel (http://camel.apache.org) and author of the "Camel in Action" book (http://www.manning.com/ibsen). Claus is the most active contributor to Apache Camel and is very active in the Camel community. He hang out on the Camel mailing lists, irc-room and often blogs about Camel. At FuseSource he leads the development of Camel and provides consulting and support to customers. Claus is frequent speaker at FuseSource community day events on subjects related to Camel. Claus has spoken at JavaZone, CamelOne, JEEConf, DevNexus, TSSJS, SDC and Devoxx. Prior to joining FuseSource, Claus has worked with integration in all sorts for the last decade.

Sami Ekblad, Partner Manager at Vaadin

Евгений Щепотьев, старший программист компании JetBrains, магистр НИУ ИТМО,
участвует в разработке проекта YouTrack и предметно-ориентированных языков,
использованных в этом проекте.

TALKS

Project Lambda: To Multicore and Beyond, Alexander Potochkin, Software developer at Oracle
This session covers the primary new language features for Java SE 8—lambda expressions, method references, and extension methods—and explores how existing as well as future libraries will be able to take advantage of them to make client code simultaneously more performant and less error-prone.

Introduction to JavaFX 2.0, Alexander Potochkin, Software developer at Oracle
At last year's JavaOne conferencer, Oracle laid out a long-term roadmap for JavaFX to make it a premier rich client platform. JavaFX 2.0, a major update to the JavaFX platform, is a significant milestone in fulfilling this vision. Starting with this version, developers can create JavaFX applications completely in the Java programming language, using standard Java development tools. It also introduces several new features to the JavaFX platform: integration with Swing applications, hardware-accelerated graphics, the ability to embed Web content, stable media playback, and an improved UI controls library. This session explores key new features and discusses use cases and benefits for Java developers of using JavaFX.

Java Memory Model in details. Sergey Kuksenko, Performance engineer at Oracle
Детальное и простое объяснение зачем нужна Java Memory Model и как она работает. (Revised version special for JavaDay Riga)

Java Platform Performance BOF. Sergey Kuksenko, Performance engineer at Oracle
Сессия в формате «вопрос-ответ» про производительность Java SE (EE), в частности, про виртуальные машины, JIT-компиляторы, библиотеки классов и сборщики мусора. Могут быть покрыты вопросы тестирования производительности, бенчмаркинг, вопросы параллельного программирования и Java Memory Model.

JavaEE 7 - Development & The Cloud, Martin Grebac, Principal Software Developer - GlassFish/Metro team & JAXB Lead at Oracle Czech
Java EE is heading towards the cloud, and this session is going to talk about the recent planned improvements and changes to the JavaEE specification which enable cloud - specific features, such as scalability, elasticity, multitenancy, service provisioning, ... . That all in a standard - Java EE standard way. We're also going to cover the continued push for ease of development and cover many new or largely re-worked areas like JAX-RS 2.0, Concurrency Utilities and many others. And of course, included is information on Java EE Reference Implementation - GlassFish and it's latest developments.

Glassfish Metro. Martin Grebac, Principal Software Developer - GlassFish/Metro team & JAXB Lead at Oracle Czech
Metro is a high-performance, extensible, easy-to-use web service stack. It is a one-stop shop for all your web service needs, from the simplest hello world web service to reliable, secured, and transacted web service that involves .NET services. A lot of new features have been added to the Metro Web Services stack lately, ranging from a completely revamped transaction implementation to high availability for reliable messaging, significantly easier configuration, and many security improvements and additions. The Metro Web Services stack is part of the open source GlassFish community and provides the GlassFish SOAP implementation but can also be used outside GlassFish. This session provides a complete overview of and instructions on how to utilize Metro's Web Service Stack.

Использование Системы Мета Программирования (MPS) для создания веб-приложений на примере баг-трекинговой системы YouTrack. Евгений Щепотьев - старший программист компании JetBrains, магистр НИУ ИТМО
JetBrains Meta Programming System - среда мета-программирования с открытым исходным кодом, позволяющая легко создавать новые предметно-ориентированные
языки (DSL) и использовать их при написании пользовательских приложений. YouTrack - самостоятельный коммерческий продукт созданный компанией JetBrains при помощи среды MPS.

Зачем использовать среду мета-программирования для создания веб-приложения?
С какими трудностями сталкивается разработчик и какие преимущества получает?
Для чего следует и для чего не следует использовать МПС? Каковы сложившиеся традиции и шаблоны программирования?
В процессе разработки YouTrack был создан целый фреймворк, включающий в себя множество языков и вспомогательных инструментов, призванный облегчить написание подобных приложений в дальнейшем.

Enterprise Integration Patterns and DSL with Apache Camel. Claus Ibsen
Apache Camel, a very popular integration framework, builds on the principles of the EIPs (Enterprise Integration Patterns)
and DSLs (Domain Specific Language).

In this talk we show how integration can become much easier and accessible with Camel. By wiring together EIP patterns, processes and transports, integrating becomes as simple as building routes "lego style.", The wiring is done using the Camel DSL. We will cover some of the most used EIP patterns such as Splitter, Aggregator, Recipient List, Dead Letter Channel, Idempotent Consumer etc. And give pointers about tips and tricks along the way. This talk includes live demos that show how to build integration flows in DSLs: plain Java, XML and Groovy.

We will also show you how you can use Eclipse tooling to build routes using a graphical drag'n'drop environment, as well how to gain insights into running Camel applications, such as message tracing.

We will cover how Apache Camel is related to Apache ServiceMix, and why you should consider using Apache ServiceMix to host your integration applications.

In the end of the talk we take a look at the noteworthy new features of the latest Camel release, as well what we have planned for the upcoming releases.

Why doesn't Java have instant turnaround? Jevgeni Kabanov
In the dynamic languages it's a given. In .NET the problem is much smaller. But Java EE applications take from 15s up to 10 minutes to build & redeploy, after every change, no matter how small. IDE automate the process, but still require the wait. Why is that and how can it be solved?

In the recent years JRebel rose to prominence as the answer to this issue. Challengers like Oracle FastSwap and Javeleon are also on the market. And instant turnaround is one of the core attractions of the Play! framework, Grails and Tapestry 5. In this talk we will review the technical and conceptual challenges involved in solving this issue and the options available today, including the tools mentioned. We'll also cover some social aspects.

Do you really get class loaders? Jevgeni Kabanov
Class loaders are at the core of the Java language. Java EE containers, OSGi, NetBeans modules, Tapestry 5, Grails and many others use class loaders heavily. Yet when something goes wrong, would you know how to solve it?

In this session we'll take a tour of the Java class loading mechanism, both from JVM and developer point of view. We will look at typical problems that you get with class loading and how to solve them. ClassNoDefError, IncompatibleClassChangeError, LinkageError and many others are symptoms of specific things going wrong that you can usually find and fix. For each problem we'll go through a hands on demo with a corresponding solution.

We'll also take a look at how and why classloaders leak and how can you remedy that.

Как, используя Lucene, построить высоконагруженную систему поиска разнородных данных. Алексей Шевчук, Одноклассники
Lucene - это популярный движок для построения полнотекстовых поисков. Им пользуются Twitter, LinkedIn, Apple и ряд других немаленьких компаний. В 2009 году Одноклассники запустили первый поиск на Lucene, и за два года к поиску пользователей добавились еще 5 других поисковых сервисов. В докладе будет рассказано о том, как устроены эти поисковые сервисы.
Так же в докладе расскажем о системе, которая одновременно ищет во всех индексах, а так же использует информацию о пользователе чтобы улучшить релевантность выдачи. Система обрабатывает более 60 млн запросов в день, и на каждый ответ тратит в среднем 90мс.

Vaadin. Sami Ekblad
Description to be added.

Diabolical Developer. Martijn Verburg
The Diabolical Developer hosts this in(famous) session in which he challenges everything the modern Java developer holds to be good and true. The Java developer today stands in a sea of APIs, frameworks, best practices, software development methodologies, and more. The developers who sent mankind into outer space did not have all of this. Makes you think, doesn't it? The session takes you through practical steps (the right attitude, self-learning, using the right tools, sticking to Java 1.4, and the like) you can take to free yourself from the chains the industry has put on you. You will leave empowered and will get back to doing what you love the most, hacking Java code.
Read more...

Introduction to River

Innovative Community Day. Bangalore 2010. River Intro

"Listen to Gigi Read and Juergen Schmerder from SAP explaining what River is and how the participants of the Innovative Community Day 2010 in Bangalore can use it."



Project River Juergen Schmerder and Gigi read Innovation week-end TechEd LAs Vegas 2010

Read more...

"Какую бы программу вы ни писали, всё равно получается компилятор".

Вот, например, некто metaclass делится своими довольно характерными переживаниями по поводу:

"Пытаясь сделать приложение, для перенастройки которого под новые бизнес-процессы не требуется перекомпиляция, довел его до того, что в нем чуть ли не собственный язык программирования получился. В итоге в следующей версии забил и сделал то же самое в виде конечных автоматов на обычном языке программирования, компилируется это дело в обычную dll, и все на этом. Отладка проще, птичьего языка не нужно, парсеров не нужно, итд. [...] Обычно это делается с целью "отдать обслуживание и настройку" другим людям, знающим предметную область, но не программистам. В итоге получается только хуже. Предметники отказываются настраивать ("это работа программистов/админов/обслуживающего персонала"), а ИТшники хуже знакомы с предметной областью и им все-таки проще описание в виде кода, а не данных."

В связи с этим иногда бывает полезно повторять мантру "c'mon, guys, we're building an application, not a Christmas tree". Read more...

"Hall of API Shame: Boolean Trap" by ariya.ofilabs.com

The nice thing working for Trolltech was (among others) learning the principles behind the good API. The article Designing Qt-Style C++ API from Matthias 6 years ago is still a good reading till today. The content itself is now expanded into the wiki page API Design Principles.

The major premise behind a good API is rather straightforward:

the code is usually written once but read many times.

When writing the code, the developer has the time she needs to look at the API documentation and digest it. When someone else reads the code (for review or bug fix), she may not always have the API documentation handy. While this is just common sense, wait until you finish reading and see why this important fact is still overlooked these days.

Note: Qt is in C++, but surprisingly the same API design principles apply to the (wonderful) world of JavaScript, which is the focus in this blog post.

George Boole, inventor of the Boolean logic.

For this particular discussion, I’ll pick my favorite API design mistake: boolean trap. On this topic, the above API Design Principle wiki page says that

it’s almost invariably a mistake to add a bool parameter to an existing function

Let’s start with the textbook example: guess what this code means?

widget.repaint(false);

Without looking at the documentation, the usual suspect is don’t repaint the widget. Then, you look at the documentation and it refers the function argument as immediate, which is true if you want immediate painting or false for deferred painting. Thus, the correct behavior implied by the above code is actually repaint this widget later, which is miles away from your initial guess.

One possible solution to this problem is to use explicit function argument. In the C++ world, this can be solved using enum, e.g. widget.repaint(WidgetClass::Deferred). In the JavaScript world, the alternative is using an object literal such as,

widget.repaint({ immediate: false });

or the more verbose variant:

widget.repaint({ mode: "immediate" });

or just create a different function for that purpose:

widget.repaintLater();

There will be a concern of performance since an object is more expensive than just a simple boolean literal. Thus, profile your code carefully and set a sensible compromise if this above line is in your hot path. On the other hand, I also do believe that modern future JavaScript engines would be smart enough to optimize such usages that the speed penalty is negligible.

Another classic is the confusion during construction. Your user interface needs a bunch of sliders to allow the user to choose some values. Here is one line in the code for you to review:

var opacitySlider = new Slider(true);

Mysteriously, there are also lines similar to:

var volumeSlider = new Slider(false);

It turns out that true there means a horizontal slider and false means a vertical slider. Of course, the easiest way to clear this confusion is to actually name the object HorizontalSlider and VerticalSlider and get rid of the boolean argument. Heck, who knows someday you’ll need a diagonal slider!

You may scream, "Of course, I won’t be too idiot to make those rookie mistakes!". Well, in the following paragraphs I’ll give examples of actual boolean traps in the API of several well-known JavaScript libraries and frameworks out there (I try to be unbiased). Consider that there are millions of developers using the libraries in real-world web applications, imagine the exposure of the traps.

For each of this case, imagine you are doing a code review. Your amazing coworker wants to commit a patch and he consults you to check your opinion.

to be or not to be

This is the same as the textbook example, but coming from a real framework:

stackView.updateHeight(false);

Yes, that false again refers to immediate or not. To the untrained developer, the above line feels like don’t update the height. A real crazy one might even stretch it to update the width!

Here is another one. To facilitate easy iteration of child widgets, you can use next() function which would get you the next sibling. But then, the code looks like:

widget.next(true);

which actually does the extra magic (because of the true value) that the very first child widget will be returned if you hit the last one. In other words, true there stands for circular. An innocent value which does too much behind your back. Well, good luck trying to review that kind of code.

Another dangerous venture:

widget.destroy(false);

which potentially leads you to think don’t destroy this widget. You can’t be more wrong, the function actually still destroys your widget, but it leaves the DOM associated with the widget intact. Only if the argument is true then actually every related DOM pieces is also tore torn down.

optionally undecipherable

Now that we have the slider for the UI, we need to preset the value:

volumeSlider.setValue(90, false);

Another boolean horror! The documentation reveals that false there indicates that the slider should not animate the movement of its indicator from the old value to the new value. By default, it will show the animation but since we want to set the initial value, the animation will be distracting and needs to be off. How about writing it like this instead?

volumeSlider.setValue(90, { animation: false } );

There is this list view of all your customers. We want to find out who live in a certain city. Can you guess what the last optional argument refers to?

customerView.filter('address', 'sunnyvale', false);

Oh, apparently the API documentation refers it to caseSensitive! Just by looking at it, this is not obvious and it could mean an entirely different thing, anything from exactMatch to highlightMatchedLine. One possible workaround:

customerView.filter('address', 'sunnyvale', { caseSensitive: false });

the more, the merrier

While one boolean argument is already confusing, two boolean arguments can’t be more fun.

To handle layout, often there is a line of code that looks like:

cmp.setCentered(true, false);

Again, a trip to the API doc enlightens the reviewer that the function signature is actually setCentered(centered, autoUpdate). This is confusing as setCentered(centered) only is probably fine, it’s just like a property setter, but the interplay of the autoUpdate argument forces the brain to think harder.

Note that a pair of values like that, especially in the context of centering/geometry purpose, might provoke a different interpretation: center vertically and horizontally. This is arguably the most sensible one which comes to mind if one sees that code.

Here is another one:

menu.stop(true, false);

The boolean values there refer to clear the animation queue or not and go to the animation or not, respectively. They are not even remotely related. What is your best educated guess if you did not know this beforehand?

Of course, why stop at two if you can have more?

event.initKeyEvent("keypress", true, true, null, null,     false, false, false, false, 9, 0);

double negative

Now, coming back to property setter, this is one valid use of boolean argument, e.g. dialogBox.setVisible(true). However, care must be taken so that there is no such double negative. Especially for non-native speakers, double negative requires an extra careful measure to make sure that the right meaning is communicated.

If I wake you at midnight and ask you this question "if invisible is false, does that mean my component is shown or hidden?", there is a chance you answer it incorrectly.

Real-world examples of double negative follow:

volumeSlider.setThumbsDisabled(false); component.setDisabled(false); filter.setCaseInsensitive(false);

Would you be less confused if this is what you read instead?

volumeSlider.setThumbsEnabled(true); component.setEnabled(true); filter.setCaseSensitive(true);

The same principle applies to active vs inactive, modified vs unmodified, defined vs undefined, selected vs unselected, etc.

By now, hopefully you got the idea of various risky uses of boolean argument. Feel free to share your favorite freak-out moment as you encounter such a similar trap.

Most importantly, next time you design an API function, remember George Boole and don’t let him down!

Update: Some people on Reddit pointed out that they would not interpret widget.repaint(false) as do not repaint. First of all, it’s subjective. In some languages it can be understood as repaint not, which is effectively a negation. Also, the context might pollute, e.g. if there is fooWidget.show(false) (which means do not show) right before, then it may influence a similar conclusion for the repaint issue. I was also not clear that any crazy possible interpretations are just examples, substitute them with your own imaginations. The fact that everyone can propose a different interpretation is the premise: ambiguity begets insanity.

[source]

Read more...

User Interface Engineering: "Do users change their settings?"

By Jared Spool@ uie.com

September 14th, 2011

Back in the early days of PC computing, we were interested in how people used all those options, controls, and settings that software designers put into their applications. How much do users customize their applications?

We embarked on a little experiment. We asked a ton of people to send us their settings file for Microsoft Word. At the time, MS Word stored all the settings in a file named something like config.ini, so we asked people to locate that file on their hard disk and email it to us. Several hundred folks did just that.

We then wrote a program to analyze the files, counting up how many people had changed the 150+ settings in the applications and which settings they had changed.

What we found was really interesting. Less than 5% of the users we surveyed had changed any settings at all. More than 95% had kept the settings in the exact configuration that the program installed in.

This was particularly curious because some of the program’s defaults were notable. For example, the program had a feature that would automatically save your work as edited a document, to prevent losing anything in case of a system or program failure. In the default settings for the version we analyzed, this feature was disabled. Users had to explicitly turn it on to make it work.

Of course, this mean that 95% of the users were running with autosave turned off. When we interviewed a sample of them, they all told us the same thing: They assumed Microsoft had delivered it turned off for a reason, therefore who were they to set it otherwise. “Microsoft must know what they are doing,” several of the participants told us.

We thought about that and wondered what the rationale was for keeping such an important feature turned off. We thought that maybe they were concerned about people running off floppies or those who had slow or small disks. Autosave does have performance implications, so maybe they were optimizing the behavior for the worst case, assuming that users who had the luxury to use the feature would turn it on.

We had friends in the Microsoft Office group, so we asked them about the choice of delivering the feature disabled. We explained our hypothesis about optimizing for performance. They asked around and told us our hypothesis was incorrect.

It turns out the reason the feature was disabled in that release was not because they had thought about the user’s needs. Instead, it was because a programmer had made a decision to initialize the config.ini file with all zeroes. Making a file filled with zeroes is a quick little program, so that’s what he wrote, assuming that, at some point later, someone would tell him what the “real defaults” should be. Nobody ever got around to telling him.

Since zero in binary means off, the autosave setting, along with a lot of other settings, were automatically disabled. The users’ assumption that Microsoft had given this careful consideration turned out not to be the case.

We also asked our participants for background information, like age and occupation, to see if that made a difference. It didn’t, except one category of people who almost always changed their settings: programmers and designers. They often had changed more than 40% (and some had changed as much as 80%) of the options in the program.

It seems programmers and designers like to customize their environment. Who would’ve guessed? Could that be why they chose their profession?

(Big takeaway: If you’re a programmer or designer, then you’re not like most people. Just because you change your settings in apps you use doesn’t mean that your users will, unless they are also programmers and designers.)

We’ve repeated this experiment in various forms over the years. We’ve found it to be consistently true: users rarely change their settings.

If your application has settings, have you looked to see what your users do? How many have changed them? Are the defaults the optimal choice? Does your settings screen explain the implications of each setting and give your users a good reason for mucking with the defaults?

Read more...