Log in

So, I was tasked at work to expose our newly minted ActiveMQ server (5.4.2) for remote monitoring over JMX. Surprisingly, this has turned out to be quite an exercise in esoteric Java.

All in all ActiveMQ comes with a number of interesting options for monitoring its operation. It can be monitored in several ways: through the Web Console (which is automatically started by ActiveMQ and runs by default on port 8161 under /admin URL and through JMX. The JMX-based option is a more sophisticated one. That said it is also somewhat tricky to configure correctly. There are a number of conditions that have to satisfied for everything to work properly.

The first thing to understand is that there are two ways to expose ActiveMQ over JMX. The default (and the better one) is over Java's built-in platform MBeanServer, the other one is through the ActiveMQ legacy JMX connector. The Java platform's MBeanServer in addition to exposing all of the ActiveMQ's MBeans also exposes a number of very useful JVM parameters (threads, memory usage, etc.). This is what we'd like to focus on.

Note: Out of the box, ActiveMQ comes fully set up for JMX access on the localhost. It is only when we need to open it for remote access that things become tricky.  

$ACTIVEMQ_HOME/bin directory contains the main startup script for ActiveMQ: activemq. This is where we can make most of the configuration changes. However, instead of making the changes directly in this script, the very same changes can be made instead in the $HOME/.activemqrc file.

The script variable that controls JMX configuration is ACTIVEMQ_SUNJMX_START. All that is needed to enable remote JMX access is to define this variable either in the activemq script itself or in the $HOME/.activemqrc file instead, as such:

ACTIVEMQ_SUNJMX_START="-Dcom.sun.management.jmxremote.port=1099 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false"

It essentially defines 3 key properties for configuring Oracle's JVM MBeanServer.
  1. com.sun.management.jmxremote.port - the TCP port on which remote agents can connect.
  2. com.sun.management.jmxremote.authenticate - when set to false, it disables all JMX authentication routines.
  3. com.sun.management.jmxremote.ssl - when set to false, it switches off SSL communication.
Please note that com.sun.management.jmxremote.authenticate property is often omitted from JMX discussions on ActiveMQ.  The documentation typically focuses on enabling authenticated access instead. By default this property is true. And if when it is set to true, then JMX password and access files must be configured correctly.

By default, those files are located in the $JAVA_HOME/jre/lib/management directory. Their names are jmxremote.access and jmxremote.password.template. Some versions of the JDKs do come directly with the jmxremote.password file (instead of the template). If it does not exist, then the template file should be manually copied: jmxremote.password.template -> jmxremote.password. This is still not enough. The file must be manually secured to disallow read access. Otherwise an obscure error will occur:

Error: Password file read access must be restricted: /usr/lib/jvm/java-6-sun-

Java allows one to override the location of those password and access files for a given instance of a JVM through the following JVM properties:
  1. com.sun.management.jmxremote.access.file
  2. com.sun.management.jmxremote.password.file
Those can be configured as part of ACTIVEMQ_SUNJMX_START variable to point to the $ACTIVEMQ_HOME/conf/jmx.access and $ACTIVEMQ_HOME/conf/jmx.password files.

Note: these files still have to be secured with read/write access given only to the user starting the ActiveMQ process.

But is important to understand that securing JMX access to ActiveMQ is rarely needed. Most production deployments already run in a secure environment, where only dedicated personnel has VPN or other restricted access. Thus it is, more often than not, perfectly acceptable to simply allow any user to connect for monitoring. Which means that all that is needed to allow remote access is to configure:

ACTIVEMQ_SUNJMX_START="-Dcom.sun.management.jmxremote.port=1099 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false"

So, far we have covered ActiveMQ specific aspects of JMX configuration. There are still several system-wide things to take note of. The most important is the host IP address configuration rule:

The system server where ActiveMQ runs must have a correctly configured /etc/hosts file. What this means that the hostname value must be mapped to an actual network IP address and not to If the hostname maps to a, then Java will not allow remote access to work correctly.  You should also make sure that no firewall rules on the server prevent clients to connect to the JMX TCP port.

Tip: if your jconsole process for monitoring remote JMX-enabled Java processes still cannot connect, then it is a good idea to start it with the -debug flag to get an actual connection exception stack trace:

Tip: also, when debugging ActiveMQ, it is a good idea to start it in console mode as: activemq console - instead of in the background as activemq start. When it is started in the background, a lot of the errors are simply swallowed.

Happy Messaging!


So, I got a new laptop at work. A very nice four core beast, SSD, etc. And it also came with Windows 7. And suddenly, my web app would not work in Tomcat started from my IDE of choice – IntelliJ IDEA. I began getting the weirdest JSP compilation errors:

java.io.IOException: tmpFile.renameTo(classFile) failed  

So, I dug into Tomcat 6 source code, and it looks like a simple file rename call was failing. Sporadically. The app however continued to work just fine when launched directly from inside the Tomcat…

That was a brain teaser. Why would a file (JSP .class file) fail to be renamed? Well, after a bit of head scratching, one likely explanation left was that another process or thread was holding a reference to this file at the very moment it was being renamed. Well, which one was it?

I did find this Tomcat bug: 38713 But it looks like it was closed long time ago.

The bug did, however, prompt me to think more about concurrency… “What if it was Microsoft indexing service? Could it be the culprit?..” So I checked indexing configuration in Win 7 and it looks like ${user.home}/.IntelliJ10 directory was indeed included in the indexing scope. And that was it. Having excluded IntelliJ’s directory from indexing, the app began working again.

So, Java developers, do yourself a favor: examine your Win 7 indexing configuration (search for ‘Indexing Options’ in Win 7) and exclude your project, IDE, and any other directories where bytecode is generated from indexing. :-)


Сегодня, моему старому доброму другу, Сергею Чалому (http://sergechaly.livejournal.com), стукнуло 40. С ДНЕМ РОЖДЕНИЯ, СЕРГЕЙ! Боже, как летит время, мы познакомились когда ему, физику, не лирику, было всего лишь 21. Боже, как летит время...

Но все впереди. Я уверен.

Сергей, так держать, умница ты наша!!!

JSON serialization format is all the rage these days when it comes to making Ajax calls from the browser. And Jackson JSON-processor is probably the best and most popular serializer written in Java for converting domain objects into JSON. Hibernate is, of course, the most popular object-relational mapping framework. And the problem is that those three don’t play well together...

The main obstacle is lazily initialized object properties: whenever a graph of object is retrieved from Hibernate, it is necessary to limit the amount of data, thus some properties must be lazy-loaded. And this is where the things begin to break down. There is really no easy workaround: if the session remains open during JSON serialization, then Jackson is going to walk through your object graph and lazily instantiate every object, potentially loading the whole database in memory; if the session is closed, then the moment a "lazy" property is encountered the org.hibernate.LazyInitializationException is going to be thrown.

I was really surprised to discover that there has been really no acceptable solution to the problem yet. Some folks advocate building a DTO layer for doing the conversion in code, some suggest inspecting JPA/Hibernate annotations on entities and reject any property marked as FetchType.LAZY, which effectively kills object graph navigation as FetchType.LAZY is the dominant form of connecting entities together. The issue is well documented in Jackson JIRA Item 276.

So, I decided to dig into Jackson internals and come up with a solution. The main requirement was that the solution must not interfere with the domain model and be transparent. It should also satisfy the following criteria:

1.       Must transparently detect if a property is “lazy” and serialize it as “null”.

2.       Must not depend only on annotation mappings. If an entity is mapped in XML, that should be fine too.

3.       Must support byte-code instrumented Hibernate entities, i.e. the ones that allow making simple fields lazy (not just entity properties or collections).  

I’ve accomplished this by creating a custom Jackson SerializerFactory: HibernateAwareSerializerFactory. Here is its source code. I've put as many comments as I could, so it should be self-documenting.

import javax.persistence.Transient;
import java.beans.PropertyDescriptor;
import java.io.IOException;
import java.lang.reflect.Method;
import java.util.ArrayList;
import java.util.Iterator;
import java.util.List;

import org.codehaus.jackson.JsonGenerator;
import org.codehaus.jackson.map.JsonSerializer;
import org.codehaus.jackson.map.SerializationConfig;
import org.codehaus.jackson.map.SerializerProvider;
import org.codehaus.jackson.map.introspect.BasicBeanDescription;
import org.codehaus.jackson.map.ser.BeanPropertyWriter;
import org.codehaus.jackson.map.ser.BeanSerializerFactory;
import org.codehaus.jackson.type.JavaType;
import org.hibernate.bytecode.javassist.FieldHandled;
import org.hibernate.collection.PersistentCollection;
import org.hibernate.collection.PersistentMap;
import org.hibernate.proxy.HibernateProxy;
import org.springframework.beans.BeanUtils;
import org.springframework.core.annotation.AnnotationUtils;

 * This is the key class in enabling graceful handling of Hibernate managed entities when
 * serializing them to JSON.
 * <p/>
 * The key features are:
 * 1) Non-initialized properties will be rendered as {@code null} in JSON to prevent
 * "lazy-loaded" exceptions when the Hibernate session is closed.
 * 2) {@link Transient} properties not be rendered at all as they often present back door
 * references to non-initialized properties.
 * @author Kyrill Alyoshin
public class HibernateAwareSerializerFactory extends BeanSerializerFactory {
     * Name of the property added during build-time byte-code instrumentation
     * by Hibernate. It must be filtered out.
    private static final String FIELD_HANDLER_PROPERTY_NAME = "fieldHandler";

    public JsonSerializer<Object> createSerializer(JavaType type, SerializationConfig config) {
        Class<?> clazz = type.getRawClass();

        //check for all Hibernate proxy invariants and build custom serializers for them
        if (PersistentCollection.class.isAssignableFrom(clazz)) {
            return new PersistentCollectionSerializer(type, config);

        if (HibernateProxy.class.isAssignableFrom(clazz)) {
            return new HibernateProxySerializer(type, config);

        //Well, then it is not a Hibernate proxy
        return super.createSerializer(type, config);

     * The purpose of this method is to filter out {@link Transient} properties of the bean
     * from JSON rendering.
    protected List<BeanPropertyWriter> filterBeanProperties(SerializationConfig config,
                                                            BasicBeanDescription beanDesc,
                                                            List<BeanPropertyWriter> props) {

        //filter out standard properties (e.g. those marked with @JsonIgnore)
        props = super.filterBeanProperties(config, beanDesc, props);

        filterInstrumentedBeanProperties(beanDesc, props);

        //now filter out the @Transient ones as they may trigger "lazy" exceptions by
        //referencing non-initialized properties
        List<String> transientOnes = new ArrayList<String>();
        //BeanUtils and AnnotationUtils are utility methods that come from
        //the Spring Framework
        for (PropertyDescriptor pd : BeanUtils.getPropertyDescriptors(beanDesc.getBeanClass())) {
            Method getter = pd.getReadMethod();
            if (getter != null && AnnotationUtils.findAnnotation(getter, Transient.class) != null) {

        //remove transient
        for (Iterator<BeanPropertyWriter> iter = props.iterator(); iter.hasNext();) {
            if (transientOnes.contains(iter.next().getName())) {

        return props;

    private void filterInstrumentedBeanProperties(BasicBeanDescription beanDesc,
                                                  List<BeanPropertyWriter> props) {

        //all beans that have build-time instrumented lazy-loaded properties
        //will implement FieldHandled interface.
        if (!FieldHandled.class.isAssignableFrom(beanDesc.getBeanClass())) {

        //remove fieldHandler bean property from JSON serialization as it causes
        //infinite recursion
        for (Iterator<BeanPropertyWriter> iter = props.iterator(); iter.hasNext();) {
            if (iter.next().getName().equals(FIELD_HANDLER_PROPERTY_NAME)) {

     * The purpose of this class is to perform graceful handling of custom Hibernate collections.
    private class PersistentCollectionSerializer extends JsonSerializer<Object> {
        private final JavaType type;
        private final SerializationConfig config;

        private PersistentCollectionSerializer(JavaType type, SerializationConfig config) {
            this.type = type;
            this.config = config;

        public void serialize(Object value, JsonGenerator jgen, SerializerProvider provider) throws IOException {
            //avoid lazy initialization exceptions
            if (!((PersistentCollection) value).wasInitialized()) {

            //construct an actual serializer from the built-in ones
            BasicBeanDescription beanDesc = config.introspect(type.getRawClass());
            Class<?> clazz = type.getRawClass();

            JsonSerializer<Object> serializer;
            if (PersistentMap.class.isAssignableFrom(clazz)) {
                serializer = (JsonSerializer<Object>) buildMapSerializer(type, config, beanDesc);
            else {
                serializer = (JsonSerializer<Object>) buildCollectionSerializer(type, config, beanDesc);

            //delegate serialization to a built-in serializer
            serializer.serialize(value, jgen, provider);

     * The purpose of this class is to perform graceful handling of HibernateProxy objects.
    private class HibernateProxySerializer extends JsonSerializer<Object> {
        private final JavaType type;
        private final SerializationConfig config;

        private HibernateProxySerializer(JavaType type, SerializationConfig config) {
            this.type = type;
            this.config = config;

        public void serialize(Object value, JsonGenerator jgen, SerializerProvider provider) throws IOException {
            if (((HibernateProxy) value).getHibernateLazyInitializer().isUninitialized()) {

            BasicBeanDescription beanDesc = config.introspect(type.getRawClass());
            JsonSerializer<Object> serializer = findBeanSerializer(type, config, beanDesc);

            //delegate serialization to a build-in serializer
            serializer.serialize(value, jgen, provider);

And this point this custom SerializerFactory needs to be registered with the root Jackson ObjectMapper. If you're using IoC container (like Spring) to wire up your project infrastructure, it is best to create your own ObjectMapper to tweak it a bit:

import org.codehaus.jackson.map.ObjectMapper;
import org.codehaus.jackson.map.SerializationConfig.Feature;

 * This class extends {@code ObjectMapper} class of the Jackson framework to provide
 * minor customizations:
 * <ul>
 * <li>To set a custom {@link HibernateAwareSerializerFactory}</li>
 * <li>To relax Jackson handling of unknown class types</li>
 * </ul>
 * <p/>
 * <em>Note:</em> Due to the nature {@code ObjectMapper} class
 * those customization could not be done through the Spring Framework.
 * @author Kyrill Alyoshin
 * @see HibernateAwareSerializerFactory
public class HibernateAwareObjectMapper extends ObjectMapper {

    public HibernateAwareObjectMapper() {
        setSerializerFactory(new HibernateAwareSerializerFactory());
        configure(Feature.FAIL_ON_EMPTY_BEANS, false);

    public void setPrettyPrint(boolean prettyPrint) {
        configure(Feature.INDENT_OUTPUT, prettyPrint);

And this is it.

I do have a comprehensive integration testing suite in my project to test these classes.

The only issue that still needs to be address is bi-directional navigation. Jackson will run out of stack when it attempts to serialize bi-directional entities. So, it is important to mark one side of the association with @JsonIgnore annotation. After this is done, you should be able to serialize your “nurtured” domain model into JSON using Jackson without resorting to useless DTO layers or one-off solutions.

Scala Talk in Portland, ME

I will be doing a Scala programming language talk at the Portland (Maine) Java Users Group next Tuesday, June 15th: www.techmaine.com/civicrm/event/info

So, if you're in the vicinity, you should come, it will be a blast!

Shameless Plug #1

Here is a javaposse.com/java_posse_308_working_with_legacy_codebases link to a podcast from the Java Posse Roundup conference that I went to a couple of months ago. The topic of the discussion was "Working with legacy codebases" , and I was chairing it. :-) So, feel free to listen in, if the topic seems of interest. It was a productive discussion.

Перелистывал сегодня давно прочитанную книгу: «Freakonomics» Стивена Левитта и Стивена Дубнера... Она представляет собой компиляцию разных статистических курьезов. Читать – одно удовольствие. Мне сказали, что книга переведена на русский язык.

Одна глава заставила меня вновь улыбнуться. В ней авторы рассказывают об анализе огромной статистической базы «dating web sites», сайтов, на которых люди знакомятся друг с другом. Так вот эти сайты представляют собой настоящий кладезь информации о поведении и предпочтениях полов. Работают сайты просто: люди регистрируют свои данные, вешают фотографии, и приглашают друг друга на свидания. Приглашения работают, конечно, через сам сайт, что позволяет фиксировать, какие группы и факторы популярны, а какие нет. Дальше самое интересное.

Оказывается, что все наши самые смешные культурные стереотипы и предрассудки о мужчинах и женщинах подтверждаются статистикой. Например:

  1. Для мужчин, самым главным критерием для получения контактного сообщения является указанный размер годового дохода. И 4% мужчин указывают его свыше чем $200К, что является более чем в четыре раза выше средне статистического для страны (США). То есть, трое из четырех лгут.

  2. Для женщин, молодой возраст и допустимость краткосрочных связей – секрет успеха.

Женская зарплата, с другой стороны, не так важна, но лучше быть в серединке: мужчины не хотят иметь дело с малоимущими и сильно богатыми. Хуже всего – преуспевающей женщине юристу. Ну боязливы мужчины, что поделаешь. Вес мужчины – не важен, а вот, не дай бог, женщина полна! И как следствие, женщины указывают вес на 10 кг. ниже среднего по стране. Мужчины же указывают стопроцентный среднестатистический вес. Рост женщины же – не важен, ну а мужчине, лучше уж не быть коротышкой, и они охотно его преувеличивают. Мужчины ищущие долгосрочных связей, гораздо более популярны, чем те, которым по душе не привязываться на долго. С женской популярностью – все наоборот.

Кажется, жизнь сложна и многообразна, а вот она – голая статистика. Короче, настоятельно рекомендую эту книгу.

Забавно, статистика с сайтов говорит, что быть блондинкой для женщины и не иметь высшего образование равно тому, что бы быть образованной брюнеткой. И почему мы так любим их, блондинок?.. :–)


Сколько стоит мечта?

Не удаляясь в глубины бытия, прямой подоплекой финансового кризиса в Америке является снижение стоимости недвижимости. Именно это подрузамевается, когда говорится, что американские банки – де–факто банкроты. Активы (дома на балансе) – ниже пассивов. Банальность. Что делать? Предлагается два пути. Первый, обанкротить и перестроить банковскую систему, чтобы возобновитъ кредитование. Второй, “силой магии и волшебства” повысить стоимость активов. Второй вариант – это путь избранный администрацией Обамы.

Но сейчас, не об этом. Меня всегда поражала способность американцев капитализировать на своих стратегических преимуществах. Будь то географическая отдаленность от мировых конфликтов, стабилность валюты, или предприимчивость народа. Так вот, в кругах американских элит начинает набирать обороты интерестная идея о том, как поднять стоимость недвижимости, без прибегания к магии или волшебству. Идея проста и гениaльна: капитализировать на силе своей культуры. Основана она на следующих предпосылках.

  1. Иммиграция в Америку превышает спрос.

  2. Недвижимость падает в цене.

  3. Если удовлетворить неудовлетворенный спрос на иммиграцию путем покупки недвижимости, можно решить проблему низкой стоимости недвижимости.

Идея проста, как Рим... Если иностранец покупает дом/квартиру стоимостью минимум $200 тыс., то он, таким образом, получает вид на жительство. Не вдаваясь в детали, в этом и есть вся суть.

ОК. О чем идет речь. 1 мил. новых семей * 200К за дом = $200 бил. прямых инвестиций в американскую экономику. Понятно, что дом нужно обставить, купить машину, мед. страховку, то естъ плюс $100 бил. прямого потребительского спроса. В год.

Понятно, что такая встряска рынка недвижимости пробудит внутренний латентый спрос людей ждущих дна рынка. Вопрос лишь в том, найдет ли Америка 1 мил. людей способных купить дом за $200К налом, без кредитов и ссуд. А вот тут–то и выступают стратегические преимущества Америки. На мой взгляд, без сомнения, в мире найдутся 1 мил. богатых родителей готовых купить своим детям дом за $200К, чтобы они могли жить и работать в Америке. Я подозреваю, что этот спрос можно будет даже удовлетворить исключительно за счет развитых стран...

Забавно. Помнится, как в универе один из приезжих американских философов вопрошал: “Как оценить свободу? Как оценить мечту?”. Очень просто – в 200К баксов...


Мой хороший друг и просто большой умница, Сергей Чалый (

sergechaly ), затеял спор (sergechaly.livejournal.com/43329.html) с госпожой pigbig , преподавательницей социологии западного университета, знатаком гендерных исследований. Спор интересен сам по себе, и я рекоммендую его прочитать. Однако, сейчас я несколько о другом: о разгуле некомпетентости. Он повсюду: экономисти не понимают принципов экономики, менеджеры не умеют управлять, программисты не умеют программировать, философы не умеют думать. Говорить умеют все. Поговорим о философах.


Когда–то я учился на философском факультете Европейского Гуманитарного Университета в Минске, о котором храню самые теплые воспоминания. Это были далекие 90–е годы. Современная западная философия только начинала проникать в массы. Умы поголовно фанатели от Хайдеггера и Дерриды, экзистенциализма и постмодернизма, от всего нового. Это было круто. Затем я переехал в штаты и окончил философское образование уже там.

Первое впечатление после переезда: от постмодерна там никто особо не фанател. Пардон, были какие–то профессора по рассовым исследованиям, феминизму, литературной критике, но на философских факультетах ничего такого. Это было подозрительно.

Откровение номер раз.
Я был хорошим студентом, и один из профессоров философии (весьма уважаемый человек, окончил Гарвард и т.д...) предложил мне семинарское занятие один на один по проблемам современной философии (надо было готовиться к дипломной), ну и на одном из занятий я упомянул о Деррида. Он мне с улыбкой ответил, что пытался читать его несколько раз, но, кроме тривиальных утвержедний, не нашел там ничего внятного, и что для него совершенно очевидно, что человек просто пиарит себя напыщенным стилем. “Такое иногда срабатывает...” – добавил профессор.

Сомнения в душе. Откровение номер два.
Пошел послушать лекции в Гарвардский университет по европейской истории и культуре 18 века. После одной из лекций, студенты замучали лектора вопросами, он сказал, что спешит, но добавил, что в четверг вечером будет в “пабе Джона Гарварда” и предложил продолжитъ дискуссию там. Ну что ж, пиво, так пиво. Слово заслово, заговорили о Мишеле Фуко, о святом Мишеле то есть. И профессор, не моргнув глазом, сказал, что историография Фуко – это мусор, большинство суждений передергивание из контекста, а зачастую просто вранье. Обидно, говорил, что его слушают больше, чем настоящих историков.

Ну а потом, конечно, грянуло дело Сокала: http://en.wikipedia.org/wiki/Sokal_affair.

В 1996 году, Алан Сокал, профессор физики Нью–Йоркского университета, направил для публикации в один из самых престижных постмодернистских журналов, Social Text, свою работу озаглавленную: “Пересекая границы: на пути к трансформативной герменевтике квантовой силы притяжения” (не могу писать, не смеясь от названия; физики поймут). Текст состоял, цитирую Сокала, “из ассорти левoй фразеологии, вожделенных ссылок, грандиозных цитат, и полной бессмыслицы”. Короче, текст без слез от смеха читать невозможно, написан был он, надо сказать, с огромным юморком. Журнал опубликовал его. Более того, текст получил восхищенные отзывы! Через две недели, Алан Сокал раскрыл свой прикол. Это был эффект ядерной бомбы. Король оказался полностью голым.

Дальше, лучше. Алан на этом не остановился. В 1998 году он написал книгу “Интеллектуальные мошенники” (“Модный нонсенс” в США), в которой просто проанализировал многочисленные научные высказывания столпов постмодерна. Именно научные. А их там было уйма.

Зачем он это сделал? Потому что он настоящий ученый. А ученые ставят гипотезы, и подтверждают или опровергают их путем воспроизводимых эскпериментов. Как отличить зерно от плевла, галиматью от глубокой мысли? Взять и прочитать книжку? Можно. Но если там не видно мысли, а видно лишь одно высокопарное изощренное словонаписание? Варианта два: 1) либо читатель не может осилить глубину текста, либо 2) текст – подделка, порнография мысли. Сокалу улыбнулась удача: тексты метров постмодерна пестрили ссылками и рассуждениями на точные науки, на физику и математику, на дисциплины в которых Сокал разбирался. Так вот, с научной стороны, наши тексты оказались совсем плохи. Наши “глубокоумные” философы и социологи несли откровенную охинею. Почитаете его книжку, живот заболит от смеха.

Ну и зачем, скажите, понадобилось нашим “гигантам мысли” притягивать за уши все эти науки, в которых они не разбираются? От этого их тексты яснее не стали, а наоборот стали более туманными. А не для того ли, чтобы пустить пыль в глаза тем гуманитариям, которые и читают их книжки в первую очередь? “Какой вы умный, господин профессор, говорите мудрено и даже про квантовую физику знаете.” Короче, появляются серьезные основания выбрать вариант номер 2.

Дело Сокала серьезно подорвало позиции посмодерна в западной гуманитарной среде. Уничтожило оно и мой интерес. Удивительно, но, похоже, до наших родных просторов эта информация не дошла. Позвонил друзьям, поговорил, нет, оказывается, это все еще модно и важно. Жаль, очень хотелось бы, чтобы на родине люди начали дружить со своей головой.

Я набросал несколько пунктов, которые предлагаю использовать, как тест для оценки модных философских течений. Примером я решил использовать постмодернизм.


  1. Распознавание себе подомными.


    Понятно, что существуют такие научные тексты, которые простым смертным без специальной поготовки не осилить. Понятно также, что может существовать закрученная галиматья, которую тоже не понять. Однако, если специалисты–эксперты данного направления не могут распознать различие, это большая проблема для такого философского течения. Эксперимент Сокала, тому пример.


  2. Редуцируемость идей.


    Должно быть возможно найти специалиста, который сможет объяснить образованному человеку, базовую аргументацию идей данной теории. Чем меньше такая аргументация требует принять на веру, тем лучше. Я недавно купил серию видео лекций по квановой физике ( Modern physics for non-scientists), остался очень доволен, и, кажется, многое понял. Что касается постмодернизма, то пока что я нашел лишь популярную литературу, которая просто перечисляет утверждения, не вдаваясь в детали аргументации. Я не одинок в этом мнении...


  3. Тщательность.


    Автор обязан заботиться о точности того, что пишет. Если многие очевидные ошибки допускаются в аппелияциях к другим наукам, мы обязаны быть подозрительными. Постмодерн, как показал Сокал, полностью провалил этот тест. Ну да что там Сокал, послушаем “великого империалиста” Ноама Чомского: “Возьмите, к примеру, Деррида, одного из старых метров. По крайнея мере, я думал, что смогу понять его Грамматологию, и я попытался ее почитать. Что–то я смог разобрать, например, критический анализ классических текстов, которые я отлично знал и о которых сам писал. Я нашел его подход безалаберным, основанным на смешном передергивании текста, а аргументация была такова, что даже и близко не доходила до тех стандартов, к которым я привык с детства.”


  4. Аргументация.


    Автор должен аргументировать свои утверждения. Это кажется банальным, но подавляющее большинство того, что я читал у постмодернистов, просто требует принятия того, что утверждается. Их текст почти всегда напыщен и самоуверен. Да уж, “далек от стандартов”. Кто–то из мудрых сказал: “Неверно, всегда и везде и для всех, верить во что–то без дoстаточных доказательств”.


  5. Нетривиальность.

    Забавно, но то, что разбираемо среди постмодерна, невероятно тривиально. “Власть хочет контролировать наши умы, посредством мягких технологий”. Ага.. Что следующее? И ради того, чтобы сказать это, понадобилось столько писанины? А где детальный анализ? Где точные примеры и их разбор? Как с этим бороться? Да тот же Чомский пишет об этом в тысячу раз более точнее и интереснее!


  6. Практический интерес к предмету разговора.


    Замечено, что хотя посмодернисты очень сильно пекутся о ситуации на бумаге, они едва ли предпринимают какие–то практические действия по улучшению реального положения вещей. Со стороны они намопинают просто некую интеллектуальную тусовку. Это вам не левые интеллектуалы 19 века, это – богема.

Хорошая мысль – это тяжелая штука. Как вы думаете, какой стиль выберет философ, который знает, что не может сказать ничего толкового, но который очень хочет признания и славы? Ясный и понятный, или же запутанный и высокопарный, набитый неологизмами? Решайте сами.

Ну а если, кто–то ищет легкого хлеба на пути постмодерна, у меня и для вас есть кое–что полезное: Генератор постмодерновских текстов. Он сам сочиняет случайные, но довольно "нормальные" постмодерновские тексты. Глядишь, у какого–нибудь профессора и курсовую писать не придется. :–)

Забавно, помню, как в середине девяностых годов спорил в Минске с местными протестантами–пятидесятниками.

Спрашиваю: “А какие у вас есть доказательства существования Бога?”
Ответ: “Ну вот, мы на языцах говорить умеем”.
И дальше демонстрация многоязычия (без шуток): “бла, бла, бла, бамбарбия, киргуду”...

Вот так вот...


 По мировым новостным лентам прошел сюжет о том, как Путин "отшил" Майкла Делла (основателя и ген. директора Dell Inc.) на слете в Давосе. Краткое содержание таково:

Майкл Делл:

Делл сострил, сказав, что был удивлен тем, что Путин в своей предшествующей речи выступил против вмешательства государства в эконимику. Далее Делл расхвалил прогресс России в сфере ИТ. Далее Делл спросил, может ли мировой ИТ сектор чем-то помочь России более полно расскрыть свой ИТ потенциал.

Владимир Путин:

Путин достаточтно жестко ответил сказав, что никакой помощи России не надо, и что надо помогать инвалидам и бедным странам, а "мы и сами с усами". Путин далее подробно описал прогресс России в сфере ИТ. Вдогонку Путин слегка намекнул, что сила русского ИТ в программировании, а не в разработке железа (т.е. то что делает Делл), и что компьютеры может собирать каждый.

Русская версия разговора здесь: www.youtube.com/watch, английская версия здесь: www.youtube.com/watch

Не думаю, что после такого прямого ответа следующая крупная инвестиция Делла будет в Россию. Похоже, он понял, что с настоящими "крутыми парнями" ему иметь дело не следует. 

Теперь самое интересное: языковые особенности.

Понятно, что не все можно точно перевести с одного языка на другой. Но чтобы разница в семантике слова помощь/help привело к такому конфузу (а именно в этом и есть "весь фокус"), то это надо еще объяснить.

Дело в том, что в английском языке выражение "What can I do to help you?" совершенно не означает (при жестком переводе) "Сколько милостыни тебе подать?", а часто имеет совершенно противоположное значение: "Что я могу сделать, чтобы ты мне заплатил?". То есть, это выражение зачастую ставит спрашивающего "ниже" спрашиваемого, а не наоборот, как это может быть в русском языке. Делл просто зондировал почву, как подзаработать. Переводчик, конечно, не смог вживую передать эту деталь, ну а Путин, оскорбленный изумлением Делла в том общеизвестном факте, что Путин, действительно, против вмешательства государства в экономику, сразу бросился делать Деллу болевой прием.  "Хамит, острит, да еще и подачки предлагает!" Вот так вот.

Забавно, я помню, когда первый раз приехал в штаты, то удивлялся вывескам на дверях магазинов "Help Wanted": Неужели магазин так беден, что милостыню просит, ну а если нет, то что нельзя просто сказать: "Требуется уборщица!"?..