The Collapse of the Middle Class

Включаю телевизор, а там лекция такая динамичная и увлекательная. По унивеситетскому каналу. О крахе среднего класса в США. Сравниваются статистические данные за 1973 и 2003 годы. За тридцать лет, америка поменялась радикально. "Средний класс" вместо сбережений имеет теперь в основном долги. Сравнивается типичная семья, двое родителей и двое детей. Раньше, в основном, один родитель не работал. Теперь работают оба. Но денег, за вычетом фиксированных расходов (кредит за дом, страховки, счета, оплата childcare), теперь остаётся меньше в абсолютном выражении. И никаких резервов в случае потери работы или проблем со здоровьем! Да, очень похоже. Даже за те семь лет, что я здесь, заметны негативные изменения. Ухудшился трафик и сильно выросли цены на жильё. Мне, конечно, скажут, что в России с жильём ещё хуже... Но эта лекция была не про Россию. Это про США. Тут свои проблемы. Если интересны подробности, наберите заголовок в Гугле.

MPlayer

Наконец-то появился нормальный видео-плейер. Играет почти все возможные форматы, например FLV. Свободный. С исходными текстами. С мощной командной строкой, которая позволяет делать всевозможные преобразования. Многоплатформенный. Без назойливой рекламы, бессмысленных "защит" и ненужных "альбомов". Просто плейер, который играет. Есть версия для Windows, Linux, и для моей Nokia N800. Причем на последней он играет несравненно лучше родного плейера. Последний год я замечаю постоянно, что свободный софт, будучи найден, обычно превосходит качеством и удобством софт коммерческий. Очередное тому подтверждение.

Шок капитализма

Недавно, а именно в 90-летие ВОСР, ехал я по ночному хайвею и от скуки перебирал fm-каналы. Везде был какой-то тоскливый музон, то стенож, то пилёж, и вдруг я услышал некий осмысленный текст, не рекламый, типа "just ninety-nine ninety-nine" и не "support comes from you and blah-blah-blah foundation...", а содержательный, с ощущением интеллекта, что само по себе сразу навеяло на мысль о некоторой оппозиционности и альтернативности. Оказалось Alternative Radio (см. одноименный .org). И хотя финансирование у него всё равно "comes from you", но в тот вечер журналистка Naomi Klein с презентацией своей книги "The Shock Doctrine" приятно меня поразила. Я не ожидал этого здесь: оказывается есть люди, способные подвергнуть критике процесс Всемирной Либерально-Демократической Революции. Вообще-то журналистка не здесь, а в Канаде (а не поехать ли мне в Канаду?). Услышанный текст я пересказывать не буду. Но мне очень понравилось. Всё очень убедительно ещё и потому, что я своими глазами видел многое из описанного в процессе развала СССР. Только один пример. Window of opportunity. Недавнее цунами в Азии прошлось по мелким прибрежным рыбацким поселениям лишив их не только близких, но и средств промысла. Недавно избранное правительство позаботилось о них, поселив в лагеря для пострадавших, подальше от берега. И даже поставило вооружённую охрану, не подпуская к побережью. А затем быстро провело приватизацию побережья. Те, кто мог бы предъявить свои права сидели взаперти, оплакивая родных, а крупные туристические фирмы быстро всё поделили. И вот я о чём подумал. Нам часто говорят о преимуществах либеральной экономики. Но гипотеза либерализма не доказана. Совершенно не очевидно, что население выиграет, если освободить экономику и дать ей развиваться независимо и бесконтрольно. Мой опыт говорит, что скорее наоборот, поскольку цели населения и цели экономики не совпадают. И уж совершенно не понятно, как либеральная экономика связана с "демократией". Развитые демократии обычно формируются в результате долгой борьбы различных групп за свои права, формируя некий консенсус в противоречивых интересах сторон. Возникают всякие механизмы защиты бизнесов, потребителей, культуры, населения, и пр. Эти механизмы явно противоречат "свободной экономике" в её радикальном понимании, и они сидят как ком в горле у монополий, которым бы хотелось их отменить, но они не могут, ибо общественное мнение будет против. Чтобы отменить, нужны обстоятельства чрезвычайные, и если они произойдут вдруг (или будут организованы), это window of opportunity можно использовать, чтобы быстро перетянуть одеяло на свою сторону, пока все заняты внезапно нахлынувшей проблемой. Вот читал я программу наших "правых". Чем они правые? Проголосовал бы не будь они "правые". Нет, не верю я в либерализм. Это такой очередной традиционный развод лохов. Учёное слово, за которым скрывается экономический беспредел и деньги как высшая ценность. А вот что я не понял, это связан ли факт передачи с 90-летием ВОСР. Совпадение или нет? Update: совпадение. Вчера вечером они опять вещали. 94.9 fm, после восьми.

Ratatouille

Мультик вышел на DVD. Я купил диск, мы с дочкой смотрели, нам очень понравилось. Потом с удивлением нашли в морозилке забытый пакет с тем же названием. Оказывается это такое французское овощное рагу. Летняя еда бедных фермеров, которая готовится из свежих овощей. Баклажан, помидоры, и прочая всячина жарятся в оливковом масле. Фильм приятно смотрится и очень приятное послевкусие. Хочется поесть чего нибудь вкусного, приготовленного с умением и любовью! Несбыточная мечта.

OOPs - продолжение.

Начало: 1, 2, 3, 4.

Приведу один пример на "ядро" "объектной модели". Иногда подобную конструкцию называют "провайдером". Пример, конечно, дурацкий, но простой и для иллюстрации пойдёт.

Допустим мы делаем электронную таблицу, нечто вроде "экселя". Некий PM (или как они там ещё называются? системные аналитики?) написал спек, в котором раcписал "объектную модель". И написано там, что есть объект таблица, у него есть коллекция рядов, каждая из которых есть коллекция клеток, а уж клетка хранит одно значение, которое может быть константой или формулой.

Замечательно, сказали мы, и, не мудрствуя лукаво, написали как сказано. Всё просто и тривиально. После чего пришёл PM и сказал, что заказчик просит ещё коллекцию колонок, и каждая колонка - тоже коллекция клеток. Ну ладно, сказали мы и добавили. Хотя
это в нашей модели уже не так тривиально. После чего, заказчик захотел извлекать клетку прямо из таблицы используя две координаты. Тоже можно сделать. Сделали.

После чего заказчик сказал, что всё медленно и требует много пямяти. Таблица расходует слишком много пямяти на одну клетку, даже если там просто число. Поскольку число мы храним как величину типа "object" в объекте типа "cell", и указатель на него лежит в массивах внутри объекта "строка" и объекта "столбец". Ещё у нас в каждой клетке могут быть массивы указателей на зависимые клетки.

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

Во вторых множество указателей между объектами заставляют сборщик мусора Java или .NET делать сложную работу по маркировке этих указателей, при этом он ходит по всей этой памяти, проверяет все ссылки, короче вы поняли.

Только мы всё это зашипили, как новая беда. Новый PM, пришедший в вашу группу, взамен старого ушедшего с повышением, сказал, что мы должны перейти на интерфейсы вместо классов и потому мы сделаем новую версию "объектной модели", причём мы будем поддерживать обе сразу, смешано и одновременно: "Вот вам challenge проявить вашу technical excellence."

И как весь этот огород сделать? Очень просто. Надо сделать "провайдер". Или "ядро". Это внутренний объект. Про который не знает ни заказчик, ни PM. Который хранит состояние вашего реального объекта. А реальный объект у вас один - таблица. Всё остальное, все эти строки, столбцы и клетки - её составные части. Как клетки вашего организма - ваши составные части. То, что заказчик просит то извлечь клетку так, то сяк - показатель, что клетка - часть таблицы.

Ключевое слово здесь - "зависимость", "dependency". Клетки зависимы, а таблицы нет. Границы между данными надо проводить по направлениям с наименьшим зависимостями.

Итак, есть объект, хранящий все данные нашей таблицы, и внутренними методами, скажем, извлечь значение элемента, поместить значение, и т.д. Все объекты нашей пользовательской "объектной модели" будут очень простые и одинаковые, они хранят указатель на этот объект и параметры, которые необходимы для вызова его методов. Например, пользовательский объект клетка будет хранить её координаты.

Псевдокод:

internal class TableDataProvider {
  ...
  public object get_value(int x,int y);
  public void put_value(int x,int y,object value);
};

public class Table {
  private TableDataProvider data;
  public Row get_row(int y){ return new Row(data,y); }
  public Column get_column(int x){ return new Column(data,x); }
  public Cell get_cell(int x,int y){ return new Cell(data,x,y); }
};

public class Row {
  private TableDataProvider data;
  private int row;
  internal Row(TableDataProvider d,int y){ data=d; row=y; }
  public object get_cell(int x){ return new Cell(data,x,row); }
};

public class Column {
  private TableDataProvider data;
  private int column;
  internal Column(TableDataProvider d,int x){ data=d; column=x; }
  public object get_cell(int y){ return new Cell(data,column,y); }
};

public class Cell {
  private TableDataProvider data;
  private int row;
  private int column;
  internal Cell(TableDataProvider d,int x,int y){ data=d; column=x; row=y; }
  public object get_value(){ return data.get_value(column,row); }
  public void put_value(object value){ data.put_value(column,row,value); }
};


Тривиально, не правда ли? Что в этом хорошего?

1. Мы отделили пользовательский интерфейс от внутреннего. Теперь первый можно менять или сделать их несколько с разными версиями, работающие одновременно с теми же данными. И внутреннее представление можно менять и не трогать пользовательские интерфейсы.
2. Все многочисленные объекты объектной модели создаются и существуют только пока они нужны пользовательскому коду и после этого уничтожаются. Они все будут эффективно собраны сборщиком мусора 0-го поколения.
3. Явно видна и понятна стоимость решения. Хотите легкой в обучении и browseable объектной модели - вот её стоимость - несколько операторов new. Хотите эффективности? Давайте добавим get_value/put_value в объект table и немножко сэкономим.
4. Все внутренние вычисления делаются внутри провайдера, пользовательские объекты тут вообще ни при чем.
5. Возможны любые shortcut-ы, как вниз так и вверх. Например, можно добавить метод/свойство получающий объект "таблица" из любого объекта.

Как же мы храним данные внутри TableDataProvider? В массивах и хеш-таблицах. Желательно как value-type, без создания множества объектов, и без "boxing". Это уменьшит расходы памяти и упростит работу сборщика мусора. Можно создать специальные индексы для данных, и разместить данные в соответствии с "access patterns". А если ваша таблица будет настолько большой, что вы захотите запихнуть её в базу данных, переделайте провайдер и всё.

Rainy Day

Тропа на гору Si в дождливое воскресенье.

Скучно без Баша.