Couchbox

Jul. 27th, 2017 03:52 am
ermouth: (Default)

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

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

Снимок экрана 2017-07-27 в 2.26.24

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

Code follows data

Нативная CouchDB хранит в базах не только данные, но и код для predefined map/reduce запросов, по которым строятся высокоэффективные persistent индексы. Этот код, на JS или Erlang, хранится в документах рядом с данными и может распространятся между узлами в тех же потоках репликации, что и сами данные.

Couchbox, наша платформа, расширяет это всё механикой хуков, реагирующих на изменения документов в базе, и эндпоинтов – REST–концов, обрабатывающих входящие запросы через https. То-есть в те же специальные документы, где в обычной CouchDB живёт код функций индексов, для Couchbox-а можно добавить ещё и код функций хуков и внешних REST API эндпоинтов. Получается распределённая платформа приложений.

Особо примечателен факт, что с точки зрения установленного софта узлы не различаются вообще.

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

Файлы – это очень скучно

Важный момент, как именно код функций попадает в БД.

Код лямбд вообще не существует в виде исходных файлов. Он создаётся в специализированной среде разработки, основанной на CloudWall и Ddoc Lab. Выглядит это примерно так:

Снимок экрана 2017-07-27 в 3.52.11

То-есть, сорцы, из которых собираются лямбды, хранятся в PouchDB в браузерах разработчиков, реплицируются в CouchDB на какой-то из узлов, собираются, а затем распространяются по остальным узлам.

Деплой обновлений и скорость разработки

Такая архитектура расслаивается на три части по критерию обслуживания:

  1. Убунта, CouchDB, Redis, node.js и nginx – фундамент со временем между рестартами в месяцы. Для обновления или рестарта фундамента нужен доступ к каждому узлу через терминал.
  2. Couchbox – платформа приложений с временем между обновлениями сейчас в недели, скоро станет в месяцы. Разрабатывается на файловой системе в обычных IDE, для обновления на узлах нужен доступ через терминал.
  3. Код приложений, очень гибкий, может обновляться и дополняться с высокой частотой. Для разработки и отладки как клиентской (UI), так и серверной части (REST API) приложений не нужно ничего, кроме браузера. Код деплоится по узлам автоматом.

Общий объём кода, написанного в браузере для этой системы, перевалил за 100К SLOC и пока всё просто прекрасно. Стартскрин бэкэнда выглядит сейчас вот так:

Снимок-экрана-2017-07-27-в-4.29

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

И да, Couchbox is MIT licensed. Опенсорц наше всё.

ermouth: (Default)

Я не отслеживаю совсем события в авиамодельном мире – и, кажется, зря. Случайно наткнулся на русскую модель Як-130, 3-кратного чемпиона мира в классе “до 20 кг”.

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

Снимок экрана 2016-02-28 в 23.59.33

Это вот панель кокпита. Все индикаторы – живые ЖК-дисплеи. Дальше всё такое же.

Снимок экрана 2016-02-28 в 23.08.05

Снимок экрана 2016-02-28 в 23.07.32

Снимок экрана 2016-02-28 в 23.07.13

Кинематика шасси воспроизводит оригинал полностью. Круууть )

Снимок экрана 2016-02-28 в 23.59.07

Модель масштаба 1:4, с реактивными движками, здоровенная – 2.8 х 2.4м в плане. Весит она при этом 20 кг пустая, то-есть в 3.5 раза легче, чем смасшабированный в 64 раза реальный самолёт. Мне сначала показалось, что я ослышался.

Стало, конечно, интересно, как это сделано – потому что она выглядит металлической. Оказалось, что обшивка – сложная композитная конструкция, весьма похожая на Glare в А-380. Стекловолокно, смола, алюминиевая толстая (0.2мм?) фольга сверху.

В более нагруженных узлах – формованный углепластик, фрезерованный пластик, литой алюминий, сталь и – в стойках шасси – даже титан. Всё по-взрослому. Фанера всего в одном месте – рама шасси, и то обклеена углетканью.

Я по видео и публикации с картинками попробовал восстановить что сколько весит. Звёздочкой отмечена информация из статьи, всё примерно, конечно.

Обшивка алюминиевой фольгой, 4м2 х 0,2мм в среднем 2 кг
Фюзеляж с набором, воздуховодами, воздухозаборниками и фонарём * 5 кг
Крылья с механизацией, киль и стабилизаторы 3 кг
Шасси с механизацией и люками 1.5 кг
Привода, RC и аккумуляторы 1.5 кг
ТРД, агрегаты и крепёж, считал на тягу в 2х15кг 4 кг
Топливная система 1 кг
Кокпит 1 кг

Получилось 19 кг. Тягу выбирал из соображений, что в какой-то момент в видео модель летает и довольно бойко маневрирует на одном двигателе, и при жарком воздухе. Для этого надо иметь тяговооружённость хотя-бы 0.4-0.5. С учётом того, что модель летает 10-15 минут, а такие турбины кушают по поллитра в минуту на макс оборотах, получается взлётная масса килограммов в 30-35.

Сделано, как я понял, примерно за полгода. Спроектировано на компьютере, конструктор – Виталий Робертус, менеджер из Лукойла. Он, же, в общем, и физически изготовил, и пилотировал.

Меня такие истории нереально воодушевляют. Снимаю шляпу просто )

ermouth: (Default)

У меня тут в процессе образовался нереальной красоты одностраничный документик со схемой архитектуры FEED CMS. Сделано спецом под ч/б принтер. Всегда пёрся от таких описаний, мне несколько раз попадались на выставках всяких, как правило в буржуйском исполнении. Станки там разные, расходники, инструментарий.  Очень коротко и сухо, с картинкой в стилистике инженерной графики. Whitepaper с инженерным уклоном, да.

architecture

Ну и на ddoc.me заработали платежи, для буржуев only. Потому что оказывается, через paypal один российский резидент не может платить другому российскому резиденту не в рублях. А у меня там USD, не знают в Лондоне про рубли блин.

Теперь вот “жду удачу, удача близится, нависает удача гроздьями”.

ermouth: (Default)

Католический кодекс канонического права, билингва латынь-русский, PDF. Очень любопытное чтение.

Канон 85 – Диспенсация, то есть послабление в сугубо церковном законе, делаемое в особом случае, может предоставляться лицами, обладающими исполнительной властью в пределах их правомочий, а также теми, кто явным или неявным образом наделён властью давать диспенсацию в силу либо самого права, либо законного делегирования.”

Ещё там вёрстка очень аккуратная и структурированная, плюс можно здорово латынь подтянуть.

Снимок экрана 2015-05-26 в 0.18.48

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

На всякий случай – я не католик.

ermouth: (Default)

Поучаствовал в небольшой переделке дизайна заглавной CouchDB в части предложения контрибьютить. Слева – как было, справа – как стало.

Снимок экрана 2015-05-19 в 3.42.12 Снимок экрана 2015-05-19 в 3.42.33

По-моему, на две головы лучше, чем было.

ermouth: (ang)

Открыли публичную бета-версию обновлённого портала областного правительства, в продолжение их пресс-центра (ровно год прошёл, да). Сначала скриншотики, кликабельны

2
1

Теперь чем оно всё круто.

0. Скорость

Вся система целиком, до последней строчки – javascript, и при этом практически любая страница после первого захода видна менее чем через секунду после клика (в России, в 120мс пинга до хостинга). Всё потому, что как и на пресс-центре применено блочное кэширование и в 99% случаев страницы отдаются целиком из кэша в RAM, даже без обращения к БД.

1. Облачная распределённая платформа

Оно плотно интегрировано с пресс-центром, это не просто одна CMS и стилистика, это единая платформа в облаках. Из соображений усиления периметра безопасности платформа состоит из нескольких компонентов, связанных только по https – скажем, головной сайт не хранит и не обрабатывает данные форм и авторизации, это делает специальный ресурс. Также на фронтэнде невозможно авторизоваться в админку – её там просто нет.

2. Импорт данных

Эта платформа импортирует данные из других систем – телефонные справочники приходят в SQL-формате, ежемесячные обновления бюджета – в CSV, афиши – в JSON и т.д. После импорта данные приводятся в унифицированный внутренний формат, а потом отображаются в виде табличек, диаграмм, списков ссылок и т.д.

Особенно полезны для вдумчивого читателя интерактивные диаграммы бюджета. На секторы можно кликать. Смею предположить, что такое представление бюджета для народа – лучшее по простоте навигации из всех, что я видел. Оно основано на одной заброшенной австралийской инициативе 5-летней давности по раскрытию open data. Мы из этого сделали технологию, в которой данные обновляются в один клик.

3. Контроль устаревания

Все материалы имеют “срок годности” – дату, после которой система начнёт напоминать о необходимости обновления. Такой фичи я просто вообще нигде в CMS не встречал, а для большого госпортала она абсолютно необходима. На предыдущей версии портала нереальные завалы неактуального старья – и про то, что информация протухла редактор портала мог узнать только случайно.

Мы сделали механику для исключения такого рода бардака.

4. Обращения и вообще формы

Когда мы это всё начинали, планировалась авторизация через соцсети. Эта идея быстро отвалилась, потому что в принципе не позволяла сделать хоть сколь-нибудь квалифицированное обращение к власти, а мне хотелось, чтобы эта форма на каждой вообще странице была.

Использовать СНиЛС как на госуслугах – не вариант, это другой класс защиты персональных данных, мы бы не поместились в сроки и бюджет. Да и неудобный он до смерти, “интернет по паспорту”.

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

---

Вообще, работа проделана колоссальная – переработано почти 400 страниц информационного контента, урегулированы вопросы поставки обновлений из ведомств, масса данных уточнено. Ну и портал правительства, наконец то, для простого человека стал не бесполезен.

Началось всё вот с такой картинки:

image

Ну и да,  вся эта система управляется приложениями jquerymy. Внутри системы даже IDE есть простенький для горячей замены кода системы из браузера прямо, тоже на $.my.

Такие дела.

ermouth: (Default)

Нашёл вот прекрасное, ни по какому поводу сделал, ни для кого – не помню.

Клик – форма для набора режима работы:

Снимок экрана 2014-01-23 в 0.01.47

ermouth: (Default)

4 месяца назад я написал вот http://ermouth.livejournal.com/605837.html, там базовые архитектурные соображения про сабж. Там у меня есть пункт: ?– Каждое устройство хранения – торрент-узел. Знак вопроса с минусом – это значит мне было не очень понятно, как именно это делать технологически.

Так вот, оно стало понятно. http://www.bittorrent.com/intl/en/sync – оказывается, ещё весной 2013 появилась технология как пре-альфа. Теперь это полноценная бета под кучу ОС.

Снимок экрана 2014-01-09 в 22.20.59

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

В недавнем разговоре про прогнозы на 2014 я как раз предположил, что мы в 2014 увидим частные соцсети как первые версии полноценных клиентов.

Теперь для этого есть буквально всё. Ждём-с.

ermouth: (Default)

Движок двинаньюса написан на не самом быстром языке и работает на не самой быстрой БД – тем не менее показывает прекрасную производительность. Это при том что каждая страница содержит динамические подборки, выбираемые по тегам и “радиусу” на оси времени.

Производительность достигается за счёт того, что страницы двинаньюса собраны из блоков и кэшируются не страницы целиком, а отдельные блоки. То-есть подавляющее большинство страниц при сборке даже если и требуют обращения к БД, то буквально единственного. Остальные блоки берутся из кэша.

Кэш – в оперативной памяти, полностью синхронный. Используется просто очень большой javascript-объект, hash table. Главные ключи формируются из параметра вызова шаблонизатора блока.

Получается, что каждый экземпляр приложения (при многопоточной реализации) имеет свой полный экземпляр кэша. Это неэкономно, на первый взгляд, с точки зрения использования RAM. Тем не менее, при моих прикидках у меня получалось, что мне никогда не нужно будет больше гигабайта памяти на ядро процессора – и Амазон EC2 прекрасно подошел.

Главная фича – как блоки инвалидировать, как кэшу узнать, что блок пора пересчитать при следующем запросе.

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

В какие именно таблицы указателей помещать, решает конкретный шаблонизатор – на основании параметров, с которыми он был вызван. Например, если мы запросили вывод списка заголовков по теме Культура, только с картинками – результат будет положен и в таблицу тега “Культура”, и в таблицу признака “С картинками”, и в таблицу блоков, отрендерённых шаблонизатором “Список заголовков”. Это называется “полностью ассоциативный кэш”.

Теперь надо узнать, когда эти таблицы инвалидировать.

CouchDB имеет интерфейс, уведомляющий подключеного клиента о появлении или обновлении документа в той или иной БД. По такому уведомлению новый док загружается и кэшируется в RAM, а все блоки, на которые он мог бы повлиять, отмечаются как устаревшие. Это очень быстрая операция, потому что итератор просто обходит все объекты по нужным хэш-таблицам и сбрасывает признак готовности.

Физически объекты из памяти не удаляются – потому что они скорее всего будут вскоре заново сгенерированы и поверх переписаны, это раз. И потому, что удаление, скажем, 50К объектов (например, мы обновили какой-то часто используемый шаблонизатор) вызовет stall на время сборки мусора.

При таком подходе кэш неизбежно засоряется всякими остатками, которые никогда не освободят память, если ничего не предпринимать.

В однопроцессорной системе можно удалять по ttl, причём это вполне можно делать асинхронно. Но так как у нас система многопоточная (несколько одинаковых экземпляров js-процесса, по которым раскидываются запросы), гораздо проще по минимуму нагрузки эти потоки по очереди рестартовать – так и сделано.

С помощью этой же механики происходит рестарт потока при падении – оно очень живучее.

Со старта обслужено примерно 1.5М запросов к серверу, даже не чихнуло ничего.

ermouth: (ang)

Вообще, удивляет диспропорция наград и общественного признания между Тимом Бернерсом-Ли и Брендоном Айком.

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

Теперь связка js+браузер+WebGL становится платформой для игр. РПГ причём, реального времени – потому что стало хватать производительности. Пока это всё продукты кросс-компиляции с C++ в js – потому что бОльшая часть игр написана на C++ – но это не навсегда.

Это очень круто. И это огромнейший рынок. И это полностью контролируемый способ доставки приложения. И аппаратно-независимый.

Мечта короче для игровой индустрии. В этой связи прогнозирую оч серьёзный рост процента игр, отрелизенных для веба в ближайшие год-два-три.

Догоняющей на этом рынке будет, как обычно, Microsoft – IE не поддерживает WebGL, равно как и движок js в IE оч медленный.

ermouth: (Default)

Такая сложно формализуемая штука, особенно для айтишников. Лорд Кельвин говорил – “что нельзя измерить, то нельзя улучшить”. Не уверен, что каждый инженер эту фразу знает, но подспудно верит в неё, кмк, едва ли не каждый.

Вера эта ложная, и чем дальше в XXI век, тем всё сильней это проявляется. И дело тут вот в чём.

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

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

Read more... )
ermouth: (Default)

Проснулся сегодня – это в воскресенье то – ни свет ни заря. Сел читать интернетики и наткнулся на прекрасное совершенно:

samsung_v_apple_131_gallery_post

Это какой-то внутренний самсунговский док, iOS тут причём 3.0 или раньше. Очень хорошо видно, что дают вот эти характерные блики на иконках эппловских. При равном абсолютном динамическом диапазоне обоих скриншотов слева мы видим ощутимо более высокий визуальный контраст.

В сравнении рядом правый скриншот выглядит совершенно пластмассовым.

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

Хотел бы я увидеть этот highly confidential документ целиком.

ermouth: (Default)

$.my вместе с новым валидатором в полный рост реализует концепцию MVVM. Декларативное связывание реализовано даже круче чем в WPF где-то – контролы в UI “сидят” прямо на том-же объекте, что передан как данные и риалтайм его мутируют.

Обратное тоже верно – окружение формы может поменять данные под формой обычным яваскриптовым синтаксисом, сказать форме перерисоваться – и она перерисуется, отразив данные.

var data = {name:””, sex:””}; $(“#someform”).my(manifest, data); //init
data.name=”John”; $(“#someform”).my(“redraw”); // update

Соответственно, для всего остального кода значение объекта data будет меняться по мере изменения контролов.

MVVM как концепт, конечно, не без подводных камней. Вот сам Госсман, чувак который ввёл понятие MVVM пишет о некоторых “прелестях” MVVM в WPF. http://blogs.msdn.com/b/johngossman/archive/2006/03/04/543695.aspx

Оно, конечно, прожорливо, особенно если сохраняет undo-историю или подвязано к зеркальным контролам с частыми изменениями (слайдеры к примеру). Я это всё пронаблюдал, когда баловался с InfoPath и Silverlight.

jQuery.my, в отличие от WPF, для решения этой проблемы вводит дополнительный опциональный параметр связи между контролом и данными под ним – delay. И этот механизм подавляет на указанный период одинаковые события – байнд выполнится только по прошествии delay миллисекунд с последнего вызова. Если за это время был ещё вызов таймер сбросится и отсчёт начнётся снова.

Аккуратное регулирование этого параметра приводит к куче интерфейсных последствий. Вот пример http://jquerymy.com/s/delay078.html

Замечу, что код этого примера, манифест который всё рисует (включая html), содержательно занимает 9 строк.

{ params:{delay:3},	
  init:[
    {row:"550px", label:"150px", rowCss:"my-row pt8 pb8"}, 
    '<h3>Зеркально-зависимые контролы, 0.7.8</h3>',
    ["3 мс", "num#num", "sli#sli.w330.ml20"],
    ["100 мс", "num#num2", "sli#sli2.w330.ml20"]
  ],
  ui: {
    "#num":  {bind:"num",  watch:"#sli",  check:/^(100|\d{1,2})$/},
    "#sli":  {bind:"num",  watch:"#num"},
    "#num2": {bind:"num2", watch:"#sli2", delay:100, check:/^(100|\d{1,2})$/},
    "#sli2": {bind:"num2", watch:"#num2", delay:100}
}}


MVVM вопщем. InfoPath в браузере. Только там манифест, модель и схема данных раздельно жили, а у меня это единая конструкция.

jQuery.my

Jun. 22nd, 2012 03:13 am
ermouth: (Default)

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

Так вот, я сделал под это всё сайт. Ну, то-есть делаю. Туториал с примерами уже просто чумовой. Ну и публичная бета для экспериментов.

Всё на кривом инглише, сорри ) Форма на заглавной тыкабельна и сделана как раз с помощью $.my.

Снимок экрана 2012-06-22 в 2.40.29

Оно реально очень крутое – там элементарный синтаксис, 7 слов надо запомнить, чтобы начать делать формы интерактивные.

Пример, что на jQuery.my рисуется при навыке за полтора вечера – на картинке вот, кликабельно:

Снимок экрана 2012-06-22 в 2.42.08

Тут форма с кучей взаимосвязей, ограничений, сложной формулой расчёта – всё один instance jQuery.my.

Веб-деятели, enjoy! Ну и RT plz )


ermouth: (Default)

Вчера, после месяца обсуждений, мы подписали контракт на перелицовку портала ЖКХ.

В целом, если всё пойдёт как я прикидываю, портал ЖКХ станет выглядеть примерно так, как я нарисовал. Как будет выглядеть страница дома мы договорились, и даже прототип сделан, осталось только всё это вкрутить. Вот скриншотик с работающего прототипа:

image

Сейчас обсуждается схема, как будет выглядеть база знаний и механизм жалоб. Регистрация скорее всего будет вКонтактовская со временем на портале, на прототипе она уже сейчас такая.

Ещё будет прикольная фича, что любой пользователь сможет к дому приписать аварийный телефон. Ну или просто полезный. Максимально упрощенная форма – типа “55-15-18, электрик Вася”.

В силу того, что дома привязаны к координатам, эти телефоны смогут видеть и жители соседних домов.

Объявления по дому сейчас сделаны как лента комментариев вКонтакта к дому, и наверное такими и останутся пока.

Ну и самое для меня важное и знаковое.

У нас с заказчиком получилось договориться, что макеты и прототипы, после того, как их примет и использует у себя заказчик, становятся общественным достоянием.

У меня давнее убеждение, что финансируемые государством (читай – налогами) публичные проекты должны быть опенсорцными. И у меня впервые в жизни получилось сделать это вживую.

В общем, следите за новостями. Скоро можно будет тестировать альфа-версию.

ermouth: (Default)

Я вроде договорился с кем надо на некоторую перелицовку портала ЖКХ. Дел там полно – к примеру, там большой, но совершенно неюзабельный раздел базы знаний – к нему нужен человечий навигатор.

Структурировать его волевым решением и мозговым штурмом в узком кругу из 3-5 айтишников – занятие явно дурацкое. Тут это, воля народа надо )

В этой связи Френды из Архангельска и области, а поставьте плиз три галочки и допишите, про что я забыл, в опросе по ссылке:

docs.google.com/spreadsheet/viewform?formkey=dG1lRXBVQnlMeUdwTXQ4QlgzWlVXQXc6MQ

И да, КДПВ. Если всё пойдёт как задумывается, страница дома, нопремер, будет выглядеть примерно так (клик – крупнее):

house-with-info-1

ermouth: (Default)

Купил у Лебедева 5 килограммов книжек – 4 книжки Тафти и “Русскую модель управления” Александра Прохорова.

Потратил почти 400 бачей по курсу прошлой недели и ничуть не жалею.

zgcn2ulr

Русскую модель управления – она стоит всего 400 рублей – очень всем рекомендую. Ну и Тафти, конечно, но это уже не всем )

Завидуйте, да )

UPD. Только что промелькнуло, что Кудрин ушёл в отставку. Тряханёт завтра.

UPD2. Не фиг и тряхануло.

ermouth: (Default)

Я тут развлёкся и нарисовал работающий прототип выбора дома для портала ЖКХ. В общей сложности это у меня заняло примерно 6 часов.

Выглядит это так (клик перекинет на работающую страничку):

image

Адреса внизу – это куда я ходил, страничка помнит ваши последние дома.

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

Read more... )
ermouth: (Default)

Чуть меньше недели назад я тут написал грустный пост про правительственный дезигн. И пообещал в конце нарисовать, как должен на мой взгляд выглядеть портал ЖКХ (его современное состояние можно лицезреть по адресу gkh.dvinaland.ru).

Задача осложняется тем, что вряд-ли кто-то будет вносить серьёзные изменения в серверный код и надо использовать то, что уже есть. То-есть перелицовывать html и недостающий функционал добавлять по преимуществу уже в браузере.

Ну и конечно, смотрел я в первую очередь с точки зрения сценариев пользователя, а не инженера.

Всю неделю думал, порвал два баяна и вот что получилось в черновой итерации (тык на большие картинки – фуллскрин).

Так может выглядеть заглавная для неавторизованного пользователя:

image

То-есть было понятно, что основная дизайнерская задача – это максимально уменьшить количество кликов при выборе дома.

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

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

Ну и редактура нужна – та имперско-канцелярская велеречивость, что сейчас, ужасна местами до оторопи (например вот премерчег, смотрим на заголовок и breadcrumbs бгг)

Но основное – это стимулирование регистрации и удобный выбор дома. И вот что мне придумалось…

Read more... )
ermouth: (Default)

После того, как я в жёстких выражениях разобрал портал ЖКХ, со мной связался человек от заказчика – и сегодня я ездил в гости. И я понял, почему другой портал получиться просто не мог. И ничего там в сторону удобства не поменяется.

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

Есть небольшая проблема – там нет никого даже отдалённо похожего не то что на арт-директора, а даже на дизайнера. То-есть из разговора стало понятно, что 1 (один) человек, который работает в этой команде “дизайнером”, в самом деле занимается тем, что просто рисует psd-шки под нарезку из того, что ему скажут старшие товарищи. За смехотворную совершенно сумму в месяц.

И эти старшие товарищи, что задачу ставят, они аналитики, инженеры, проектные менеджеры, администраторы… Ну и получается что получается.

Мне сегодня показали, во что портал ЖКХ должен превратиться – и я пришёл в полное уныние. Это будет такая каша из виджетов с табами. Один в один msn.com – да только вот на портал ЖКХ не ходят за новостями, в отличие от MSN.

Меня всегда потрясало, что в компаниях с большим скоплением технарей, инженеров и людей околокомпьютерного профиля дизайн и эргономика не принимаются даже близко в качестве той самой печки, от которой надо плясать.

Нет совершенно понимания, что любую систему массового использования надо начинать проектировать вместе с дизайнером. То-есть, красивые тачки им нравятся, удобные стулья – тоже, и даже свитера у всех разные… А вот понимание того, что те-же законы, по которым они выбирают тачки, стулья и свитера, работают и на их вотчине, ещё не пришло.

Поэтому обращение вот с толстым намёком бгг

Уважаемые Алексей, Владимир и, возможно, Леонид! (С которым я, оказывается работал вот по этому проекту)

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

Во-вторых, хороший дизайнер понимает чаяния и нужды пользователя лучше, чем сам пользователь. А вот технарь (инженер, ок) понимает чаяния и нужды только другого технаря, обычный юзер для любого технаря – это немного недочеловек. Необходимое зло. Ну вы знаете.

В-третьих, дизайнер – это с самого начала красиво и удобно. Задача инженера – сделать быструю, надёжную и расширяемую систему, не разорившись при этом. А красиво и удобно – это не инженерная задача. Вам нужны серые стены, тишина, уникальные фичи и высокая плотность информации – а большинству людей нужно совершенно иное.

Так что начните тратить деньги на дизайн. Ну не должна власть выглядеть так бессмысленно, непривлекательно и быть такой неудобной. Может и не будут вам тогда резать бюджеты на порядок.

А я вам нарисую пока, как на мой взгляд должен выглядеть ваш портал с учётом той платформы, что сложилась. И через недельку отправлю. А дальше вы сами решайте.

Profile

ermouth: (Default)
ermouth

July 2017

S M T W T F S
      1
2345678
9101112131415
16171819202122
23242526 272829
3031     

Syndicate

RSS Atom

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Jul. 27th, 2017 04:39 am
Powered by Dreamwidth Studios