Маленькая ветка в ЖЖ Вассермана. Профессионального историка, между прочим.
Решение о публикации фальшивок подтверждает характеристику, когда-то данную Анатолием Чубайсом: отмороженный. Давно данную, ещё до президентства.
Здесь статья Мухина. Осмысление истории у Юрия Игнатьевича малоправдоподобное, но писать он безусловно умеет. На факты всегда смотрит под оригинальный углом зрения. Данная статья очень сильная. Попал в верхний отдел позвоночника.
суббота, 1 мая 2010 г.
четверг, 22 апреля 2010 г.
о фундаментах
Отсюда:
They say a house is only as good as its foundation, and we believe the same holds true for web applications like Google Docs. With our old foundation, we could continue delivering most features you wanted quickly, but over time it became clear that some just weren’t possible. So we decided to rebuild the underlying infrastructure of Docs to give us greater flexibility, improved performance and a better platform for developing new features quickly.Aга, я даже знаю что это за новый фундамент такой. Покойтесь в мире, Closure Tools.
воскресенье, 4 апреля 2010 г.
вы ненавидите HTML?
А помните, была такая IDE — Delphi? Вот что мне напомнил веб-фрэймворк Ваадин: никакого языка разметки или таблиц стилей — процедурный язык программирования, интерфейс пользователя верстается наглядно, с помощью мастера. Вроде и сам занимаюсь клиентскими веб-приложениями, вроде давно известны мощные продукты (привет Гуголу) в этой области, но факт существования такой IDE заставляет по-новому взглянуть на положение дел в отрасли. Новая платформа уже не стучится в дверь, она уже пришла. Хотите в Quake в браузере сыграть?
среда, 31 марта 2010 г.
Великая Война / Барбаросса
Новый и первый вменяемый сериал по ВОВ на ОРТ. Для тех, кто, как и я, проживает без телевизора, показывают по серии в неделю. Режиссёр Валерий Бабич. Авторы сценария — широко известные в узких кругах Исаев и Драбкин. Смотрел с удовольствием. Качать с пока легальных файлообменников и уже нелегальных торрентов.
суббота, 13 марта 2010 г.
про Федору
Вывел компы в эфир. Оказывается, вместо точки доступа за $200 (карточка + недо-комп с линуксом) можно воткнуть в мега-комп карточку за $20 (линукс там уже есть) и настроить с ней точку доступа.
КарточкаD-Link DWA-510 — это сети g, а не n, но WPA2-PSK у неё есть. Как было замечено, первый результат в Google по запросу «WPA2-PSK»: «Взламываем WPA2 PSK ...». Пусть где-нибудь на Гриде пароль и можно поломать, но проще начать с соседей: в комнате ловятся 4 чужие сети (Академгородок, понимаешь!). Две из них сидят на одном и том же канале и глушат друг друга. Одна защищена WPA-PSK, остальные WEP. Можно у себя поднять FreeRadius над WPA2-EAP, такое и за десять лет не сломают, но неохота ковыряться.
DWA-510, которая мне досталась, построена на чипсете RaLink, а бывают другие варианты. Позвонил в Квесту и Техносити, но только в ВИП-компьютерс согласились просветить чипсет карточки перед покупкой. Вставляем LiveCD в привод и
Это то, что надо.
Для настройки точки доступа нужен пакет hostapd. Во времена былинные приходилось дополнительно пересобирать ядро, а сейчас пакет включен в репозиторий... Федоры 12, а не 11. Проапгрейдить дистрибутив легко. То есть было бы легко, если бы сначала прочитал ресурс обновляем Федору используя yum. Вместо этого я выкачалDVD-дистрибутив (не помешает) и проапгрейдился с него. Дистрибутив вышел в конце прошлого года, с тех пор Федора 11 на локальной машине обновлялась, здесь скопилось много новых пакетов, которые оболочка модернизатора менять на свои, старых версий, не решается. Встала лишь малая часть пакетов Федоры 12, остальное пришлось заменять вручную.
Разобрался как убрать графический загрузчик: сообщения в текстовой консоли вселяют больше уверенности, чем безликий progress bar. Графический загрузчик включается параметром ядра rhgb (Redhat Graphic Boot). Нет параметра — нет загрузчика. Заодно добавил параметр vga=792 — консоль может и должна выглядеть красиво. Как оказалось, сделал это зря.
Через неделю начал шуметь копеечный вентилятор на старенькой NVidia GT7300, и я заменил её на валявшуюся без дела Radeon X1950 Pro. Новая карточка в три-четыре раза мощнее, чем старая, но геморроя с ней в линуксе больше на порядок. Потому что это — ATI. Для неё есть (сюрприз!) аж три драйвера: от самой ATI, от Новелла, и свободный. Первый даёт лучшую поддержку для 3D, но сделан для старых иксов. Для Федоры 12 — не вариант, к тому же в линуксе я не играю. Второй, говорят, глючит. Третий — самый стабильный для 2D, но у меня с ходу не завёлся. Нагуглив проклятия линуксоводов всех стран компании Nvidia, я уже собирался сбыть карту с рук на барахолке, как вдруг наткнулся на совет выкинуть опцию vga=792 из параметров ядра. Опция грузит модуль фрэймбуфера, тот конфликтует с radeonfb (о чём пишет) и вроде бы выгружается, да, оказывается, не совсем.
Ну а без vga=792 тишь (карточка тихая) и благодать. И тебе фильмы смотри без тормозов, и тебе в консоли разрешение 128 столбцов на 43 строки. Очень нравится в линуксе то, что если проблема решена, то она решена на годы. Способ настройки сетевой карточки на стороне винды подробно изложен на форуме убунту. Ниже конфиги Федоры — может кому понадобятся?
Для Федоры 14:
Карточка
DWA-510, которая мне досталась, построена на чипсете RaLink, а бывают другие варианты. Позвонил в Квесту и Техносити, но только в ВИП-компьютерс согласились просветить чипсет карточки перед покупкой. Вставляем LiveCD в привод и
#lspci | egrep -i network
05:02.0 Network controller: RaLink RT2561/RT61 rev B 802.11g
Это то, что надо.
Для настройки точки доступа нужен пакет hostapd. Во времена былинные приходилось дополнительно пересобирать ядро, а сейчас пакет включен в репозиторий... Федоры 12, а не 11. Проапгрейдить дистрибутив легко. То есть было бы легко, если бы сначала прочитал ресурс обновляем Федору используя yum. Вместо этого я выкачал
Разобрался как убрать графический загрузчик: сообщения в текстовой консоли вселяют больше уверенности, чем безликий progress bar. Графический загрузчик включается параметром ядра rhgb (Redhat Graphic Boot). Нет параметра — нет загрузчика. Заодно добавил параметр vga=792 — консоль может и должна выглядеть красиво. Как оказалось, сделал это зря.
Через неделю начал шуметь копеечный вентилятор на старенькой NVidia GT7300, и я заменил её на валявшуюся без дела Radeon X1950 Pro. Новая карточка в три-четыре раза мощнее, чем старая, но геморроя с ней в линуксе больше на порядок. Потому что это — ATI. Для неё есть (сюрприз!) аж три драйвера: от самой ATI, от Новелла, и свободный. Первый даёт лучшую поддержку для 3D, но сделан для старых иксов. Для Федоры 12 — не вариант, к тому же в линуксе я не играю. Второй, говорят, глючит. Третий — самый стабильный для 2D, но у меня с ходу не завёлся. Нагуглив проклятия линуксоводов всех стран компании Nvidia, я уже собирался сбыть карту с рук на барахолке, как вдруг наткнулся на совет выкинуть опцию vga=792 из параметров ядра. Опция грузит модуль фрэймбуфера, тот конфликтует с radeonfb (о чём пишет) и вроде бы выгружается, да, оказывается, не совсем.
Ну а без vga=792 тишь (карточка тихая) и благодать. И тебе фильмы смотри без тормозов, и тебе в консоли разрешение 128 столбцов на 43 строки. Очень нравится в линуксе то, что если проблема решена, то она решена на годы. Способ настройки сетевой карточки на стороне винды подробно изложен на форуме убунту. Ниже конфиги Федоры — может кому понадобятся?
### WiFi D-Link DWA-510: с помощью визарда system-control-network
статически задать адрес IP:
адрес 192.168.130.1
маска подсети 255.255.255.0
остальное не трогаем
### WiFi D-Link DWA-510: /etc/hostapd/hostapd.conf
ctrl_interface=/var/run/hostapd
ctrl_interface_group=wheel
macaddr_acl=0
auth_algs=1
ignore_broadcast_ssid=0
wpa=2
wpa_key_mgmt=WPA-PSK
wpa_pairwise=TKIP
rsn_pairwise=CCMP
wpa_passphrase=ваш очень длинный и не угадываемый по словарям пароль
# Most modern wireless drivers in the kernel need driver=nl80211
driver=nl80211
# Customize these for your local configuration...
interface=wlan0
hw_mode=g
# канал надо выставить подальше от соседских
channel=1
ssid=яркое и запоминающееся название вашей сети
### WiFi D-Link DWA-510: избранное из iptables линуксового сервера
# линуксовый сервер == файервол == точка доступа == статический ip 192.169.130.1
# виндовый клиент == статический ip 192.169.130.2
# чтобы пакеты сервера снаружи не отличались от клиента, в mangle:
-A PREROUTING -i wlan0 -j TTL --ttl-set 64
# маскарадим в nat:
-A POSTROUTING -s 192.168.130.0/24 ! -d 192.168.130.0/24 -j MASQUERADE
# в filter:
-A INPUT -s 192.168.130.0/24 -i wlan0 -j ACCEPT
-A INPUT -s 192.168.130.1/32 -i lo -j ACCEPT
-A FORWARD -s 192.168.130.0/24 -i wlan0 -j ACCEPT
-A FORWARD -o wlan0 -j REJECT --reject-with icmp-port-unreachable
-A FORWARD -i wlan0 -j REJECT --reject-with icmp-port-unreachable
-A OUTPUT -s 192.168.130.1/32 -j ACCEPT
### /etc/dhcp/dhcpd.conf
default-lease-time 600;
max-lease-time 7200;
option subnet-mask 255.255.255.0;
option broadcast-address 192.168.130.255;
option routers 192.168.130.1;
option domain-name-servers 85.118.224.121,89.31.118.1;
authoritative;
subnet 192.168.130.0 netmask 255.255.255.0 {
interface wlan0;
range 192.168.130.3 192.168.130.100;
}
### /etc/sysconfig/dhcpd
DHCPDARGS=wlan0
Для Федоры 14:
### добавить в /etc/rc.d/rc.local строчку
echo 1 > /proc/sys/net/ipv4/ip_forward
при установке выключить сервис NetworkManager и включить сервис network
### Radeon X1950: избранное из /etc/X11/xorg.conf
Section "Device"
Identifier "Radeon"
Driver "radeon"
VendorName "ATI Technologies Inc"
BoardName "RV530 [Radeon X1650]"
BusID "PCI:1:0:0"
EndSection
воскресенье, 14 февраля 2010 г.
История с GWT
Если кто не знает, GWT — это не только компилятор Явы в Яваскрипт, но и библиотека виджетов, сериализация-десериализация RPC клиентом и на сервере, плагин для IDE Eclipse, собственные (native) методы на Яваскрипте. Компоненты более-менее независимые, главное там — компилятор. Хочешь — используй стороннюю библиотеку виджетов, хочешь — иную IDE (Идея рулез). По сравнению с GWT проект Google App Engine выглядит брендовой песочницей. С помощью GWT сам Гугол построил интерфейс Adwords и «Волну». Есть аналогичный набор инструментов для компилирования сырого Яваскрипта в оптимизированный Яваскрипт, о котором хорошо написал Илья Кантор. Между прочим, после оформления Closure Tools в отдельный проект и создания «Волны», я было решил, что Гугол не считает коммерчески обоснованным далее скрывать код инструментов разработки на сыром Яваскрипте. Однако судя по косвенным признакам, Google Bazz написан скорее с помощью Closure Tools, а не GWT, и хоронить Closure Tools рано.
Пример работы GWT со спрайтами. Кратко, суть спрайтов в том, что много мелких картинок собирают в одну, чтобы уменьшить число HTTP запросов для отрисовки страницы (пример). Когда рисуют страницу, средствами CSS кусочек картинки-агрегата подставляют фоном к нужному элементу, и выглядит это точь-в-точь как оригинальное единичное изображение. На практике: собираете мелкие картинки в графическом редакторе, копаетесь в получившемся винегрете, высчитывая координаты составляющих кадров, переносите данные в CSS, проверяете в браузере. Для команды специально обученных верстальщиков это просто. А если потом нужно добавить ещё одну картинку, повторям снова. Ну, вы поняли. В GWT это выглядит следующим образом:
1. утилитой генерируем интерфейс для стилей (назовём его Style)
2. вручную набиваем другой интерфейс: ресурс, где связываем интерфейс стилей со стилями, а произвольный геттер с исходной картинкой.
или в шаблоне GWT UIBinder (отдельная тема)
компилятор сам сгенерирует нужные параметры классу .logo, чтобы он отображал картинку, а картинки соберёт в одну. У выходных файлов (картинка, CSS) имя составлено как хэш-функция от содержимого, что позволяет кэшировать их в браузере навечно.
На пробу выполнил четыре шага для единственного спрайта. Каково же было моё удивление, когда в файербаге:
увидел, что компилятор встроил картинку в файл CSS! Трюк, возможный в Лиске, но не в ie6/7, для которых генерируются свои CSS. Если специально обученные верстальщики могут полениться сравнить: встроенная картинка в случае FF или картинка-агрегат, то компилятор выбирает оптимальный вариант. Внимание разработчиков GWT к деталям производит впечатление.
Это была преамбула, а теперь — амбула. Проект — SaaS с адвордовским пользовательским интерфейсом. Как в теме поста, надо научить дружить историю браузера с GWT. История — это «вперёд», «назад» и перезагрузка страницы (либо её загрузка по урлу). GWT работает с историей на низком уровне, а надо привязать её к архитектуре MVP. Известно два варианта: один изложен в предыдущей ссылке а другой — GWT Presenter (сторонняя библиотека под GWT). Второй сейчас используется в проекте. На низком уровне, история оперирует токенами. Токен — это кусок урла, который идёт после знака ’#’. Изменения токенов отслеживается.
Подробнее про GWT Presenter. Веб-приложение разбито на страницы. Хотя GWT приложение и помещается на одной странице, GWT Presenter разбивает его на места (Places), по которым можно перемещаться с помощью навигации, меняя токены. Грубо говоря, каждому месту соответствует своё представление (view), которое управляется презентатором (presenter). Похоже на странички.
Токены используются для того, чтобы:
1) попасть в нужное место
2) хранить состояние презентатора, чтобы по внешней ссылке или при обновлении странички попасть в нужное состояние приложения.
Пример 1:
Переход из списка элементов к редактору элемента. Презентатор списка выставляет презентатору редактора идентификатор (здесь 2010:3) и вызывает его revealDisplay(), что приводит к обмену событиями по системной шине:
...: «Презентатор, покажись!»
Презентатор: «Я показался!»
Место: «Это мой презентатор? Ага, я показалось!»
Местный управляющий: «Какое-то место показалось... давай токен.»
Место: «Презентатор, давай своё состояние.»
Презентатор: «Идентификатор сейчас ’2010:3’»
Место: «Ясно, значит токен будет ’#settings/lifecycles/edit/;lid=2010:3′. Возвращаю токен.»
Местный управляющий: «А что, в истории по-другому? Ладно, заношу токен в историю.»
Пример 2:
Переход в редактор по ссылке из браузера. Ссылка ведёт на страничку с токеном
Происходит обмен событиями по системной шине:
Местный управляющий: «Чёрт, история поменялась. Запросили место для ’settings/lifecycles/edit/’!»
Место: «Это что, про меня, что-ли? Щас обработаю. Презентатор, твой идентификатор теперь ’2010:*’, понятно?»
Презентатор: «Угу, законфигурировал.»
Место: «Презентатор, покажись!»
... далее см. пример 1...
Место: «Я показалось»
... опять см. пример 1...
Пример 3:
Перенос изменения состояния презентатора в токен (и историю браузера), чтобы при обновлении странички состояние осталось прежним. Пользователь меняет значение фильтра с 2009 на 2010 год, и начинается обмен сообщениями по системной шине:
Презентатор: «Я поменялся!»
Место: «Это мой презентатор? Я поменялось!»
Местный управляющий: «А тебя сейчас видно? Ага, понятно. Давай токен.»
Место: «Презентатор, фильтр теперь какой?»
Презентатор: «Вот, 2010»
Место: «Ясно, значит токен будет ’#settings/lifecycles/;year=2010′. Возвращаю токен.»
Местный управляющий: «А что, в истории по-другому? Ладно, заношу токен в историю.»
Если сравнить работу GWT Presenter’а с каркасом веб приложения, выходит, что компоненты маршрутизации (routing) и декодирования запроса/кодирование ответа представлены в целом неплохо. Обратная маршрутизация неявно подразумевает, что место для презентатора, который покажут, уже создано. Недостатки: использование сообщений/обработчиков сверх меры. При переходе по ссылке (см. Пример 2) нужное место можно вообще находить синхронно. Обработка похожих сообщений («я появился», «я показался») почти совпадает друг с другом. Ещё про недостатки:
Пример 4:
На страничке (в одном месте) расположены два списка: список пользователей и список ролей. Оба списка можно фильтровать: пользователей по флагу активен/неактивен, а роли по статусу админ/просто пользователь. Логично сделать два отдельных презентатора, каждый из которых наследует функциональность базового презентатора списков. А архитектура GWT Presenter ставит презентатор и место в соответствие один-к-одному. В результате здесь требуется добавить избыточный презентатор, который будет делегировать передачу состояния от места к презентаторам пользователей и ролей и наоборот, а самое неуклюжее — передачу события «я поменялся» на системную шину, потому что место не желает следить за событиями чужих презентаторов.
То, что в данный конкретный момент времени каждый презентатор относится только к одному месту, выглядит разумным. Это требование соответствует отношению много-к-одному. Так было бы удобнее, чем в текущей реализации.
В конце мая пройдёт традиционная конференция Google IO, на котором заявлены аж два доклада по архитектуре GWT приложений. Будем надеятся, докладчики просветят в области архитектуры, типичной для GWT приложений. Пока что буду переделывать GWT Presenter. Попробовать что-ли обратные вызовы?
Пример работы GWT со спрайтами. Кратко, суть спрайтов в том, что много мелких картинок собирают в одну, чтобы уменьшить число HTTP запросов для отрисовки страницы (пример). Когда рисуют страницу, средствами CSS кусочек картинки-агрегата подставляют фоном к нужному элементу, и выглядит это точь-в-точь как оригинальное единичное изображение. На практике: собираете мелкие картинки в графическом редакторе, копаетесь в получившемся винегрете, высчитывая координаты составляющих кадров, переносите данные в CSS, проверяете в браузере. Для команды специально обученных верстальщиков это просто. А если потом нужно добавить ещё одну картинку, повторям снова. Ну, вы поняли. В GWT это выглядит следующим образом:
1. утилитой генерируем интерфейс для стилей (назовём его Style)
2. вручную набиваем другой интерфейс: ресурс, где связываем интерфейс стилей со стилями, а произвольный геттер с исходной картинкой.
public interface Resources extends ClientBundle {
Resources RESOURCES = GWT.create(Resources.class);
@Source("layout.css")
Style style();
@Source("images/appLogoSmall.png")
ImageResource appLogoSmall();
}
3. Возвращаемся в стили и прописываем там спрайт:@sprite .logo {
gwt-image: "appLogoSmall";
position: relative;
top: 18px;
}
4. Используем генерированный класс во время выполнения программы, ссылаясь на метод
Resources.RESOURCES.style.logo()
или в шаблоне GWT UIBinder (отдельная тема)
<ui:with field='res' type='za.co.jigsaw.saas.gwt.resources.client.Resources'/>
<!-- Здесь навесим логотип: -->
<div class='${res.style.logo}>
компилятор сам сгенерирует нужные параметры классу .logo, чтобы он отображал картинку, а картинки соберёт в одну. У выходных файлов (картинка, CSS) имя составлено как хэш-функция от содержимого, что позволяет кэшировать их в браузере навечно.
На пробу выполнил четыре шага для единственного спрайта. Каково же было моё удивление, когда в файербаге:
url(data:image/png;base64,iVBORw0KGgoA...
увидел, что компилятор встроил картинку в файл CSS! Трюк, возможный в Лиске, но не в ie6/7, для которых генерируются свои CSS. Если специально обученные верстальщики могут полениться сравнить: встроенная картинка в случае FF или картинка-агрегат, то компилятор выбирает оптимальный вариант. Внимание разработчиков GWT к деталям производит впечатление.
Это была преамбула, а теперь — амбула. Проект — SaaS с адвордовским пользовательским интерфейсом. Как в теме поста, надо научить дружить историю браузера с GWT. История — это «вперёд», «назад» и перезагрузка страницы (либо её загрузка по урлу). GWT работает с историей на низком уровне, а надо привязать её к архитектуре MVP. Известно два варианта: один изложен в предыдущей ссылке а другой — GWT Presenter (сторонняя библиотека под GWT). Второй сейчас используется в проекте. На низком уровне, история оперирует токенами. Токен — это кусок урла, который идёт после знака ’#’. Изменения токенов отслеживается.
Подробнее про GWT Presenter. Веб-приложение разбито на страницы. Хотя GWT приложение и помещается на одной странице, GWT Presenter разбивает его на места (Places), по которым можно перемещаться с помощью навигации, меняя токены. Грубо говоря, каждому месту соответствует своё представление (view), которое управляется презентатором (presenter). Похоже на странички.
Токены используются для того, чтобы:
1) попасть в нужное место
2) хранить состояние презентатора, чтобы по внешней ссылке или при обновлении странички попасть в нужное состояние приложения.
Пример 1:
Переход из списка элементов к редактору элемента. Презентатор списка выставляет презентатору редактора идентификатор (здесь 2010:3) и вызывает его revealDisplay(), что приводит к обмену событиями по системной шине:
...: «Презентатор, покажись!»
Презентатор: «Я показался!»
Место: «Это мой презентатор? Ага, я показалось!»
Местный управляющий: «Какое-то место показалось... давай токен.»
Место: «Презентатор, давай своё состояние.»
Презентатор: «Идентификатор сейчас ’2010:3’»
Место: «Ясно, значит токен будет ’#settings/lifecycles/edit/;lid=2010:3′. Возвращаю токен.»
Местный управляющий: «А что, в истории по-другому? Ладно, заношу токен в историю.»
Пример 2:
Переход в редактор по ссылке из браузера. Ссылка ведёт на страничку с токеном
#settings/lifecycles/edit/;lid=2010:*
Происходит обмен событиями по системной шине:
Местный управляющий: «Чёрт, история поменялась. Запросили место для ’settings/lifecycles/edit/’!»
Место: «Это что, про меня, что-ли? Щас обработаю. Презентатор, твой идентификатор теперь ’2010:*’, понятно?»
Презентатор: «Угу, законфигурировал.»
Место: «Презентатор, покажись!»
... далее см. пример 1...
Место: «Я показалось»
... опять см. пример 1...
Пример 3:
Перенос изменения состояния презентатора в токен (и историю браузера), чтобы при обновлении странички состояние осталось прежним. Пользователь меняет значение фильтра с 2009 на 2010 год, и начинается обмен сообщениями по системной шине:
Презентатор: «Я поменялся!»
Место: «Это мой презентатор? Я поменялось!»
Местный управляющий: «А тебя сейчас видно? Ага, понятно. Давай токен.»
Место: «Презентатор, фильтр теперь какой?»
Презентатор: «Вот, 2010»
Место: «Ясно, значит токен будет ’#settings/lifecycles/;year=2010′. Возвращаю токен.»
Местный управляющий: «А что, в истории по-другому? Ладно, заношу токен в историю.»
Если сравнить работу GWT Presenter’а с каркасом веб приложения, выходит, что компоненты маршрутизации (routing) и декодирования запроса/кодирование ответа представлены в целом неплохо. Обратная маршрутизация неявно подразумевает, что место для презентатора, который покажут, уже создано. Недостатки: использование сообщений/обработчиков сверх меры. При переходе по ссылке (см. Пример 2) нужное место можно вообще находить синхронно. Обработка похожих сообщений («я появился», «я показался») почти совпадает друг с другом. Ещё про недостатки:
Пример 4:
На страничке (в одном месте) расположены два списка: список пользователей и список ролей. Оба списка можно фильтровать: пользователей по флагу активен/неактивен, а роли по статусу админ/просто пользователь. Логично сделать два отдельных презентатора, каждый из которых наследует функциональность базового презентатора списков. А архитектура GWT Presenter ставит презентатор и место в соответствие один-к-одному. В результате здесь требуется добавить избыточный презентатор, который будет делегировать передачу состояния от места к презентаторам пользователей и ролей и наоборот, а самое неуклюжее — передачу события «я поменялся» на системную шину, потому что место не желает следить за событиями чужих презентаторов.
То, что в данный конкретный момент времени каждый презентатор относится только к одному месту, выглядит разумным. Это требование соответствует отношению много-к-одному. Так было бы удобнее, чем в текущей реализации.
В конце мая пройдёт традиционная конференция Google IO, на котором заявлены аж два доклада по архитектуре GWT приложений. Будем надеятся, докладчики просветят в области архитектуры, типичной для GWT приложений. Пока что буду переделывать GWT Presenter. Попробовать что-ли обратные вызовы?
понедельник, 23 ноября 2009 г.
сериализация декорированных функций
Попробовал написать декоратор для библиотеки отложенных вызовов Ника Джонсона (вот оригинальное имя, да?) в Гугол Апп Энджине. С ходу не вышло, pickle не хочет сериализовать декорированную функцию. Брет Кэннон посоветовал использовать пиклевый протокол. К примеру, __reduce__() может возвратить строку, указывающую на функцию. Надо удостовериться, что между вызовами __call__ и __reduce__ состояние объекта не изменит параллельная нить.
Пока что даже хитрый модуль decorator не сериализирует декораторы (вот пример использования в АЭ). Этот модуль, между прочим, затратно применять для отложенных действий в АЭ -- он использует exec(), что окупается при компилляции, но навряд ли окупится в ситуации частой загрузки инстанса рабочей среды.
Пока что даже хитрый модуль decorator не сериализирует декораторы (вот пример использования в АЭ). Этот модуль, между прочим, затратно применять для отложенных действий в АЭ -- он использует exec(), что окупается при компилляции, но навряд ли окупится в ситуации частой загрузки инстанса рабочей среды.
суббота, 26 сентября 2009 г.
facebook автодополнение
Народ сходит с ума по фэйсбуковкому автодополнению. Фэйсбуковское автодополнение -- это тема. А возможно, даже и тренд. Вот одно такое для GWT:
http://demo.raibledesigns.com/gwt-autocomplete/
красиво
http://demo.raibledesigns.com/gwt-autocomplete/
красиво
суббота, 2 февраля 2008 г.
Иволгинский дацан. Чойра дуган.

Здесь краткая компиляция истории Иволгинского дацана. Полный текст доступен по адресу: История Иволгинского дацана
В 1922 году на II духовном Соборе буддистов СССР в г.Улан-Удэ разработан новый административный принцип организации Буддийской церкви, тогда же Комитетом бурят-монгольской культуры была выработана и опубликована программа обновления ламаистской религии. В 1928 году состоялся III духовный собор, где, помимо прочего, Галсанов Хайдуп был избран и.о. председателя Центрального Духовного Совета буддистов Восточной Сибири. После революции в Бурятии функционировало 47 дацанов и дуганов, а при них порядка 10 тысяч человек — служителей культа.
Однако, в 30-х годах строения разрушили, а лам с учениками — разогнали или посадили. В частности, Галсанов Хайдуп 28 ноября 1931 года Коллегией ОГПУ приговорен к 3 годам высылки по ст.58-2 УК РСФСР (Контрреволюционные преступления: вооруженное восстание или вторжение в контрреволюционных целях на советскую территорию вооруженных банд, захват власти в центре или на местах). Реабилитирован 02 ноября 1989 года Прокуратурой РБ.
Летом 1944 года Галсанов с представителями ламства и верующих собрали средства в Фонд обороны. Несколько человек поехали в Москву сдать деньги (350 тыс. рублей). Галсанов получил благодарность от Сталина, добился аудиенции. Сталин потребовал бумагу за подписью шестнадцати человек, чтобы разрешить религиозную деятельность. Старые ламы не разрешили молодым подписывать, боялись за них. В Верхней Иволге было много пришедших из тюрем старых лам, которые отсидели по 10 лет. Они подписали бумагу. Сталин разрешил.
Примечательно, что в опубликованных воспоминаниях нет содержимого письма с 16 подписями. Ответ Сталина тоже не документирован. Что он разрешил? В каких словах? И в наше время (январь 2008) жалуются:
«без разъяснений и с разночтениями в правовых актах употребляются термины: «религиозная деятельность», «культовая и иная религиозная деятельность», «деятельность религиозного объединения», «богослужения и другие религиозные обряды и церемонии» и пр.» (Актуальные вопросы хозяйственной деятельности...)
Вскоре после этого нарком Госбезопасности БМАССР пишет: «Буддийское духовенство активизировало антисоветскую и ламско-религиозную работу среди населения. Ламство стало активно заниматься нелегальной религиозной деятельностью, совершая религиозные обряды и молебствия с массовым привлечением верующих.». Нарком перечисляет факты пожертвований от мирян ламам. Во-первых, хотя Сталин и разрешил, юридического основания под деятельность лам-священников и лам-медиков не подвели. Например, баранов им жертвовали тоже нелегально, да ещё и из колхозного имущества. Подобная ситуация власть не устраивала. Во-вторых, за бродячими ламами трудно присматривать. Нарком, несмотря на «антисоветский» характер деятельности, пересадить лам не предложил. Вместо того он предлагает открыть (два!) буддийских храма.
За этим последовало постановление Совнаркома БМАССР от 2 мая 1945 г. за №186-ж об открытии буддийского храма «Хамбинское Сумэ» в улусе Средняя Иволга.
Совет Народных Комиссаров БМАССР постановляет:
1. Удовлетворить ходатайство групп верующих об открытии буддийского храма «Хамбинское Сумэ» в улусе Средняя Иволга.
2. Передать помещение бывшего молитвенного дома Маани религиозной общине под буддийский храм «Хамбинское Сумэ».
3. Представить настоящее постановление в Совет по делам религиозных культов при СНК СССР на рассмотрение.
Местные власти предложили строить на Лысой Горе (сейчас именно там стоит буддийский центр Римпоче Бакша), но ламы отказались. Иволгинские ламы (бывшие ламы Янгажинского дацана) хотели, чтобы строили ближе к ним. Колхоз «им. Сталина» отказал в хорошей земле. Пришлось строить в болотистой местности, где дацан стоит и поныне.
Габжа лама Сартул-Булакского дацана Лубсан Нима Дармаев был членом Центрального Духовного Совета. 15 апреля 1943 арестован НКВД БМАССР по ст.58-1 УК РСФСР (Контрреволюционные преступления: измена Родине), а через полтора месяца освобождён. Собирал средства в Фонд обороны, ездил в Москву. В мае 1946 года совещание представителей верующих буддистов и лам выбирает его председателем Временного Центрального Духовного Управления буддистов – Пандидо Хамбо ламой. Тогда же обсудили и приняли патриотическое обращение ко всем верующим буддистам и духовенству на старомонгольском языке. Вот отрывок в переводе Гармаевой Х.Ж.:
«Ом! Да Будет Благоденствие!
Благословением благодетельного ламы, Трех Драгоценностей и бхагаванов, татхагат, архатов истинно совершенных, всех будд и бодхисаттв трех времен десяти сторон света, мы все, почитающие буддийскую религию, преисполненные добродетелями верующие, избавившись от нисваниса, живем счастливой жизнью, которая (представляет собой) высшую ступень (развития) человечества и преклоняемся счастливым стопам преисполненного солнцем великого Сталина, ставшим вождем — олицетворения сущности тела, мысли и всех познаний ради пользы всех (живых существ), одержавшего победу над дьявольскими черными и желтыми фашистскими врагами, превратив их в прах.»
Немногие тексты могут сравниться по силе с этим обращением. Полностью прочитать его можно здесь: История Иволгинского дацана
На съезде также было принято «Положение о Буддийском духовенстве в СССР».
На фотографии — первый дуган дацана. Из постановления Совнаркома БМАССР (выше) видно, что изначально существовал какой-то молитвенный дом. Одни источники утверждают, что дом для дугана куплен на собранные деньги в декабре 1945 года. Другие источники говорят, что дом был пожертвован бурятской семьёй. Возможно, пожертвован ещё в качестве молельного дома? Уже в 1947 году было решено перенести дуган на новое место. В течение полугода был поставлен дуган и к нему новая пристройка. В 1948г. был достроен второй этаж. В ноябре 1948 г. Хамбо лама Дармаев из Закамны привез позолоченный ганжир (навершие на крыше) и хорло с двумя ланями (наверху террасы). До 1951 года дом стоял одиноким. Тогда выделили землю для монастырского комплекса и только в 1952 году её обнесли оградой. После 70-х годов в дугане размещалась библиотека. С 1994 г. после образования дисциплины Чойра (Цаннит) он преобразован в аудиторию для занятий по буддийской философии.
Иволгинский дацан. Хурдэ

Это комментарий к фотографии из сделанных в Иволгинском дацане.
По традиции, Посетители обходят территорию дацана по часовой стрелке. По периметру стоят хурдэ, молитвенные барабаны. Барабаны при этом надо крутить. Тоже по часовой стрелке.
Внутри барабана, по его оси — свиток с мантрой (молитвой). Когда хурдэ крутят, то мантра «читается». Текст на санскрите. Католическая церковь отдыхает со своей латынью. Большие хурдэ содержат большие свитки, на которых мантра написана многократно. Снаружи барабана написан текст молитвы. Кто умеет читать — тот знает что он крутит.
Посетителю следует запастись мелочью. Ещё одна традиция — класть монетку в положеном месте. Положеных мест много. Стойка с барабанами усыпана мелочью. В храм приносят и еду (например, конфеты). Между прочим, (на фото не вошёл) слева от барабанов стоит ящик для милостыни, куда можно опускать купюры.
Подписаться на:
Сообщения (Atom)