CustisWiki - Новые страницы [ru]

Language Oriented Programming (LOP) в действии (Максим Мазин, ADD-2011)

2011-05-17T15:59:27Z

StasFomin:

Максим Цепков - отчет об ADD-2011/Пример разработки высоконагруженной реляционной базы данных

2011-05-17T13:36:03Z

StasFomin: Новая страница: «На [[Пример разработки высоконагруженной реляционной базы данных (Павел Белоусов, ADD-2011)|до...»

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

Для меня лично содержание доклада большого интереса не представляло, так как по своему опыту работы с базами данных я эти механизмы хорошо представляю. Это Этап решение проблем в тяжелыми запросами, блокировками и deadlock.Однако, доклад будет интересен тем, у кого такие задачи встают в первые.

Механизмы, упомянутые в докладе.

Избегание tablock
Чтобы избегать deadlock — стройте обработку с циклом по одному индексу.
Учите матчасть — индексы, блокировки, планы выполнения.

Максим Цепков - отчет об ADD-2011/Заднее чутье разработчика

2011-05-17T13:34:20Z

StasFomin: Новая страница: «Антон вырос от разработчика до менеджера проектов, это был его первый доклад на конференц...»

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

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

Основные места, в которых возникают грабли.

Пользователи — они могут портить даные из-за ошибок в системе.
Интеграция с внешними сервисами
Работа после наката обновлений

Сбои — потери — разгребание проблем.

Как избежать?

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

Кто отвечает за это? Разработчик. А то он будет и расхлебывать.

Что такое «заднее чутье»?

Источники: Люди, ПО, Железо, Процессы
Возможные проблемы
Решения для них
Проверка, что решения работают (например, из бэкапа — можно поднять систему). Это — важно.

Прототип системы: нужен минимум — диагностика. В первой боевой версии — желателен максимум защиты. И далее надо постоянно поддерпживать

Дальше много частных решений.

Таких как мониторинг или бэкапы.
Протокол взаимодействия при интеграции; Проверка по контрактам входа-выхода
Повторение запросов, рассчитывать протоколы на это.
Резервные каналы синхронизации. Ннапример, с мобильного девайса, когда штатно не получается.
Вести логи, уметь их передавать.
Изоляция внешней системы — шлюз.

Работа с пользователем.

Механизмы восстановления. Напрмиер при ошибочном удалении или редактирвоании
Предусматривать возможность срезать углы, позволяя нарушать правила. Например, сохранять неконсистентные черновики.
Сохранять простой вариант UI
Обработчик ошибок верхнего уровня. Пользовательская диагностика. Интерфейс пользователя дляы ошибок.
Глюки из-за проигнорированной ошибки: Кидайте исключения, а не код возврата. Проверяйте контракт.
Уведомлять разработчика автоматически, отслеживать действия пользователя.
Изолировать объекты разных пользователей (usec-spec)

Релиз

Автоматический накат по одной кнопке
Блокировать работу на время релиза.
Порча базы патчами: бэкапы до и после, сравнение базы до и после, альфа-тест на отдельной площадке.
Бета-тестирование — использование новой версии частью пользователей в продакшн, пока остальные на старой версии

Поддержка

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

Минимальный набор

исключения — throw
автоматический накат обновлений
автобекапы — и не забыть проверить, что восстанавливается
разделение доступа: база данных, ОС, сама система логины
при интеграции — логи запрос-ответ, промежуточные
контракты где уместно
уведомления о сбоях
аварийные каналы данных
инструментарий решения задач поддержки

В заключении была рекомендация книги Michael Nygard — Release It!

Максим Цепков - отчет об ADD-2011/Блиц Филиппова

2011-05-17T13:31:03Z

StasFomin: Новая страница: «Виталий [[Архитектура Mediawiki (Виталий Филиппов, ADD-2011)|рассказывал про внутреннее устройство...»

Виталий рассказывал про внутреннее устройство MediaWiki и возможности расширений. Мне эта тема интересна, так что я пошел послушать. К сожалению, доклад получился в формате потока информации, к тому же выдаваемой ровным голосом. Но информация для меня была ценной. Основное — про то, что в MediaWiki на базовом уровне заложено очень много механизмов для реализации точек расширения, что позволяет делать доработки, не правя основной текст и достаточно комфортно обновляя версии. Это же породило множество (более 1700) готовых расширений от различных авторов.

Архитектура Mediawiki (Виталий Филиппов, ADD-2011)

2011-05-17T13:30:08Z

StasFomin: /* Видео */

Максим Цепков - отчет об ADD-2011/Особенности масштабирования систем планирования и управления поставками

2011-05-17T13:23:46Z

StasFomin: Новая страница: «Системы управления поставками для крупных американских и некоторых европейских ритейлер...»

Системы управления поставками для крупных американских и некоторых европейских ритейлеров. Сырье — Вендор — Ритейлер — Покупатель. Товар вперед, по заказам. Без возвратной логистики. Очень интересный для меня доклад, поскольку наша компания, в числе прочего, занимается именно проектами управления снабжением магазинов для Спортмастера.

Сам доклад — очень удачный. Михаилу удалось в кратком докладе рассказать о бизнес-задаче управления цепочкой поставок, о технических сложностях ее решения и о методах оптимизации. Задача, по моему опыту, весьма сложная и то, что они деляют — впечатляет.

Бизнес-задача — снабжение магазинов на основании текущих остатков и прогнозов продаж.

Содержание SCM
- demand planing — предсказание объема продаж,
  - статистический долгосрочный прогноз
  - эвристический краткосрочный прогноз
- order management — реальные заказы, опираясь на прогнозы
- transportation — транспортная логистика
- исполнение
Прибыль ритейлеров — 1-4 % от оборота даже в успешные годы. Поэтому очень важна точность прогнозов.
Региональные центры дистрибуции, по 2 на штат. Заказ в магазины и пополнение центров дистрибуции. Тысячи магазинов, до 15 тыс. у одного европейского ритейлера
Прогнозирование — data mining. Эвристики, которые дорабатываются по прецедентам в процессе эксплуатации. Оно живет, но неудачи — опасны.

Особенности работы с заказчиком.

Процесс прогноза и заказа идет автоматом, но должны быть механизмы наблюдения, анализа и корректировки.
Процессы у заказчика — медленные. Например, получить одну нужную колонку в данных — 4 месяца.
Консервативность заказчика к технологиям. Поэтому Oracle + Java. Используют Groove для бизнес-логики не афишируя — все равно Java-платформа.

Система обеспечивает решение следующей задачи. Надо ежедневно получать данные о продажах, конвертировать, валидировать, загружать. Далее — обрабатывать, обеспечивая создание заказов и корректируя имеющиеся прогнозы, долгосрочный и краткосрочный. При этом время на обработку ограничено — после получения всех данных и до первой стадии бизнес-процесса обработки заказов, обычно на это 1-1.5 часа. А объемы данных большие, оценка — 2К маг * 50К товаров (продаж в день) * 500 дней = 50 млрд строк продаж. Реально 5-10 млрд.

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

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

Технологии.

Oracle 10g/11g RAC
Java 1.6 Jboss AS 4.2. Jboss используется исторически и как общая платформа с другими проектами.
Собственный Cache и grid-manager
Клиент JSP, JavaScript.
Для бизнес-логики используют Groove

Задачии оптимизации

Хранение больших таблиц
Быстрая загрузка
Оптимизация запросов
Оптимизация БД в целом
Оптимизация интерфейса
Оптимизация engines — расчетных частей

Большие таблицы — Partitioning. Если пара таблиц имеет одинаковый partitioning, то join это учитывает.

Загрузка — SQL*loader, с использованием различных ускоряющих приемов.

direct mode, отключение индексов, constraint, редкие commit, увеличение буфера
отключение redo-log,
параллельная загрузка по внешних процессов
Загрузка во временную таблицу, потом merge для разрешения ссылок. Разбивают на части.
flat table — монтировать csv-файлы как таблицы

Оптимизация запросов по планам решения. Реально оптимизатор — улучшается. Сейчас они удаляют хинты, написанные 3-4 года назад.

Oracle Grid Control. Вкладки мониторинга запросов — он показывает еще и динамический план: сколько записей в запросе и столько он уже вытащил. И известный способ — трассировка sql_trace, tkprof.

Оптимизация пользовательского интерфейса

materialized view, вынос в них тяжелых частей запроса, обновление по ночам или несколько раз в сутки
обеспечивают отклик 5 сек.
принудительная фильтрация ui как мера предосторожности — например, не показывать средние продажи по всему восточному побережью — запрос уйдет в БД и многим помешает.

Пакетная обработка — цепочка engines. Масштабы впечатляют — 10К одновременных тасков, 2M всего в таблице. И это — наиболее критичная задача.

В каждом engines — параллельно запускаем задачи обработки, для чего выделяем группы данных, обрабатываемых.
Oracle масштабировать дороже, чем Java/JBoss. Поэтому расчет на сервере приложений. 4-6 серверов Java на каждый сервер Oracle.
Проблемы ввода-вывода на уровне базы данных
Трафик между БД и Сервером приложений — меньше, чем проблема ввода-вывода самой БД — на сервер приложений идут агрегированные данные. Задержки по БД-app их не волнуют, потому что параллельно идет много задач, ограничение — целиком
Железо — в datacenter, тестируют, предпочитают стандартное, так как легче масштабируется.
Облака — использовать начинают. Но amazone — использует сервера общего назначения, а они — оптимизированные под БД. Так что пока осторожно.
Пишут запросы вручную, не через ORM.
Используют HP и др. storage device
Используют flash памиять, Увеличивают размер памяти.
В 11 Oracle используют сжатие данных на exologic и др — на storage

Максим Цепков - отчет об ADD-2011/Разработка приложений с использованием Windows Workflow Foundation

2011-05-17T13:22:25Z

StasFomin: Новая страница: «Это был [[Разработка приложений с использованием Windows Workflow Foundation (Максим Игнатов, ADD-2011)|рас...»

Это был рассказ про внутренний проект компании — сопровождение найма сотрудников на WWF. Сделан в свободное время (правило 20 %), реально используется. Доклад полезен для тех, кто хочет познакомиться с возможностями WWF, однако они представлены там на начальном уровне — это лично я и так представляю, тем более что часть иллюстраций были на примерах из документации.

Из практического — они реально работают с очень изменяющимся процессом и им успешно удается вносить изменения при наличии незавершенных процессов. Они не используют подписание сборок, чтобы для незавершенных циклов использовался старый вариант (и тут я с ними согласен), а применяют миграцию или предусматривают старый вариант просто в бизнес-логике, и то и другое работает.

Максим Цепков - отчет об ADD-2011/Фриланс

2011-05-17T12:36:22Z

StasFomin: Новая страница: «Мы с ним беседовали накануне в обед. Фриланс. Он становится коллективным. Коллективная раб...»

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

К сожалению, доклад, на мой взгляд, был несколько менее интересным, чем живое общение. Было много общих слов про возможности, которые дает фриланс, в то время как слушателям было бы более интересна конкретика, реальный опыт. Например, понятно, что фриланс в принципе дает возможность регулировать свое рабочее время. Но то, что можно обеспечить комфортный доход при в среднем 20 часах в неделю, и Стас некоторое время так работал, при этом когда нужны деньги можно дойти до 60 (и будет втрое больше) — это уже было после доклада, в общении. Но при этом есть работодатели, которые нанимают фрилансеров для экономии на зарплате, и требуют присутствия — это надо учитывать, и есть нюансы — требуют ли реального присутствия или просто доступности для каких-то консультаций. А еще — не смотря на гибкий график, эффективность часто меряется довольно жестко, через счетчик времени, и за этим следят. Так же как подходы к выборке задач — когда надо трезво оценивать трудоемкость, учитывая что часто хотят сэкономить, но иногда бывают подарки, когда деньги большие. По работе есть oDesk — интегратор фрилансеров. Еще важно, что фрилансер сам планирует свое развитие, это и возможность и обязанность. Так что в целом — это альтернативный способ работы, со своими плюсами, которых много, но за которые надо платить.

Максим Цепков - отчет об ADD-2011/Взаимоотношения заказчика и исполнителя на проекте

2011-05-17T12:34:50Z

StasFomin: Новая страница: «Дмитрий Завалишин на этой конференции рассказывал не про Фантом ОС (которая постепенно ра...»

Дмитрий Завалишин на этой конференции рассказывал не про Фантом ОС (которая постепенно развивается, это из разговоров в кулуарах), а про менеджерскую часть своей деятельности. Которая, думаю, весьма успешна — если остается время и силы на Фантом ОС.

Их компания занимается заказной разработкой, и Дмитрий обобщал опыт. Как он сказал, это первый его доклад по такой теме. В целом мои впечатления — это очень сокультурно нам, нашим мыслям. И — мы соразмерны по уровню, что редкость. В докладе был определенный экстремизм, хотя очень мне импонирующий — когда мы делаем не так (что бывает не часто), в меня скребут кошки. Хотя у них компании — несколько другая бизнес-модель, при этом проекты — сопоставимые с нашими, 20-30 человеко-лет. Они делают ставку на точные спецификации, исполняемые разработчиком. Мы так работали примерно лет 6-7 назад, а потом — сменили парадигму, приняв что квалифицированный разработчик сам способен сделать приличную часть постановки, если понимает бизнес-часть, а понимать ее в многолетних проектах он будет.

Дальше я оставляю практически все заметки в исходном виде.

Начало — традиционное, 80 % провалов.

Исполнитель не умеет вынимать требования
Заказчик не знает, что ему нужно
Проект реально сложен и действительно не поддается оценке заранее

Ответ программерский — виноват заказчик.

Заказ по умолчанию — «на сайте должен быть форум». Когда дальше работают аналитики — у него просыпается фантазия, он хочет многое. Только потом — у него нет денег, и вообще это ему не нужно. Они стараются урезать хотелки, направить на важное, решение реальных проблем.

Российский заказчик склонен снимать ответственность. Реально проект — совместная деятельность. Гарантировать от проблем не может никто.

Цели.

Счастье клиента
В срок
В бюджет

Бывают проекты только со счастьем клиента — сам проект провалился, зато дал заказчику альтернативное видение ситуации, с которым он развивается дальше.

Функциональность в списке целей отсутствует — потому как реально это самая гибкая часть. Всегда что-то уходит, что-то приходит, в общем случае не нужно ничего.

Заказчик должен сказать, как он будет на проекте зарабатывать деньги (или как проект сделает его счастливым, это синонимы!). Если уяснив бизнес-задачу поняли, что можно сделать проще — не скрывайте. Надо выйти в бизнес-минимум реализации, на котором можно пробовать.

Если клиент хочет неоправданно сложный проект — отказывайтесь.

Важно — нужны конечные пользователи, стейкхолдеры, а не только директор.

Ситуация: «директор посмотрел и сказал — все переделать» +30 % переработки. И Менеджер не может принять проект. Реально, это проблема Разработчиков — надо на входе понять, кому сдавать.

Но даже если пользователи принимать не будут — они потом будут пользоваться и вас материть — оно вам надо?

Лезьте в бизнес-схемы клиента. Понимайте зачем.

Узнайте бюджет. В России тяжело, вопрос про деньги «не приличный». Ты хочешь узнать, сколько у меня денег и потратить? Да, хочу — все равно проект будет дороже и дольше, и эти деньги мы потратим — так что скажи сразу, мы разумнее спланируем.

Коммуникации

единое понимание целей
единое понимание рисков
единое понимание точности оценки

Если про цели как-то есть, то 2 и 3 — реже.

Желательно

знать, что можно урезать
знать, что можно перенести попозже
иметь представление о приоритетах задач

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

Пример. Отложить оплату части проекта — на поддержку.

Бумажки

Vision одна страница в первые 2 дня. Вехи
Требования. В начале, 100 страниц, ревью с клиентом и разработчиком. Эскизы и usecase
Тест-план, если требования детальны может отсутствовать
План проекта. Реально работает при детализации 2-3 часа на задачу, но полезен даже если в нем 3 строки
Деплоймент-диаграмма — чтобы не было сюрпризов на сдаче

Важно. Клиенту требования надо структурировать по бизнес-областям. А программист часто хочет получить кусок на код, а остальное не слишком читать. Я: Это видение у нас было лет 5 назад. Работает и востребовано когда программисты не погружаются в бизнес-область. На их потоке проектов это оправдано.

Инструменты.

Трекинг процесса. Два ползунка — сколько съели объема (фич, например) и сколько бюджета.
Регулярные релизы, ревью с клиентом, прогоны.
Сначала сделать все, потом полировать. Все равно, треть не нужно — зачем его полировать. И нет риска застрять на полировке и не сделать минимального ядра.

Я: Это правильно — делать по фрагментам надо вчерне, а не до совершенства. Но делать, а не прототипы.

Что делать когда клиент не верит. Например, две задачи, он считает, что оно почти одно и то же, а стоимость — разная. У них разработчики в конце недели пишут лог (тайсминг) в свободной форме. Их можно предъявить, и нельзя подделать, это в крупном. А сейчас научились фиксировать время на баги. Это все можно показать клиенту, объяснить и убедить.

Архитектура и компоненты

Знакомый инструмент — лучше. Незнакомый инструмент снижает предсказуемость, а это важнее сроков.
Готовый код третьей стороны снижает стоимость, но повышает риск — если компонента не знакомая. Объясните это клиенту.
Клиенту никогда не нужно именно то. Ему нужно «нечто похожее». Если есть наработки — можно использовать готовое. Использование своего кода — снижает и цену и риск.
Интеграция с существующими системами — отдельный проект. Лучше не пытайтесь fixprice.

Больше — не есть лучше. Беда российских разработчиков — сделать больше. Нет, если за те же деньги — не вопрос. Но больше-то не нужно. А иногда и мешает. Плюс усложнили реализацию — усложнили использование. И это может выйти боком. А убить сделанное — только расстраиваться.

После 90 % бюджета получается нормальный продукт. Хороший — будет после еще 90 %. А третьи 90 % позволят сделать блестящим. Поэтому надо сделать вчерне за 30 % времени и бюджета — тогда есть шанс получить блестящее за остатки. Хотя у них не слишком работает.

Очень важно — постанализ по проекту.

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

Оценка одного «за три дня» — значит за 5-6. А другого — за 2 сделает что нужно, еще день будет развивать и надо остановить. Это можно понять только на опыте постфактум, и надо это делать.

Сравнение с инхаузом. В том числе — коэффициент года. Налоги. Инхауз обычно не считает затраты админов, которые часто закрывают деплоймент. Почитать документацию — тоже реальная работа.

Как выбирают подрядчика.

Опыт. Внятность по видам проекта
Адекватность. Решение задачи клиента, а не свою
Надежность как предсказуемость итогов. Очень важно.
Цена. Хотя это в разных проектах по-разному.

Вопрос — фикс или тм. У них в основном фикс. ТМ — мечта, но расслабляет. А еще при ТМ клиент тоже начинает париться на тему, что он действительно хочет.

Максим Цепков - отчет об ADD-2011/MongoDB

2011-05-17T12:27:33Z

StasFomin: Новая страница: «* MongoDB (Сергей Туленцев, ADD-2011) Слушал не с начала. Мой интерес к этой теме — представлять ...»

MongoDB (Сергей Туленцев, ADD-2011)

Слушал не с начала. Мой интерес к этой теме — представлять уровень развития NoSQL баз данных, их назначение — с тем, чтобы, возможно, начать применять в проектах. В общем, не секрет, что собственно реляционные возможности в реляционной базе данных во многих проектах используются ограниченно. Но их выбирают из-за высокого быстродействия в целом, а также из-за развитых механизмов управления транзакциями, резервного копирования, восстановления, репликаций. И NoSQL базы данных, обеспечив преимущество по скорости за счет своей более простотой организации сейчас наполняются теми механизмами, которые в реляционных БД, например, в Oracle — есть. Уровень зрелости сложно оценить по книгам, тут удобнее доклады тех людей, которые реально используют в своих проектах.

MongoDB очень удобно для прототипирования. Обеспечивает изменение структуры на лету. А еще можно использовать для динамических данных, настраиваемых при конфигурировании продукта. Например, сайт с опросами или CMS. По его оценке сайт для опросов — пара таблиц и 1200 строк, с mysql будет больше.

Очень быстрый доступ по keyvalue. Но не только так — есть 15-20 операций чтобы строить запросы, включая существование элемента в массиве, соответствие всех элементов заданному множеству и т.п. Для конкурентной работы — команда find and modify — документ ищем и сразу меняем, что задано. База данных — кластерная. И в кластер сразу заложено, что есть мастер и дубль, который в случае чего подхватит. А еще есть журнал и лог транзакций — на случай падения. Из инструментов отладки — встроенный профилятор, плюс логирование запросов. К сожалению, есть ограничение — 16М на документ.

При проектирвоании важно правильно расшарить данные, это ключ к масштабированию. Shard key — идентифицирует данные в кластере, он не изменяется — только копирование, а если для коллекции — надо сохранить на диск и загрузить, только так. Пример — user по email. Другой пример — пусть есть ленты пользователей. Можно расшаривать по постам (событиям). А можно — по пользователям. В первом случае лента — распределенная, запрос ленты пользователя пойдет на много серверов. А при падении сервера получается лента с дырками. Во втором случае — вся лента с одного сервера, это эффективно по нагрузке. При проблемах — система не работает с одного сервера. Еще пример с фотками. timestamp в ключе фотки приведет к тому, что все фотографии, загруженные в один момент времени, ложаится в один кластер — не эффективно, потому лучше timestamp+user или timestamp+hash.

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

Рекомендации по быстродействию — в целом понятные, известные и по реляционным базам данных.

Когда делаете начальный импорт, лучше заранее сделать нужное количество чанков — чтобы это не делать в динамике на импорте.
Cached Counter. Атрибуты-массивы, но нет операции, выдающей длину. Патерн — храним с каждым списокм counter.
Covered index — чтобы быстро получать данные из индекса.
специальные индексы — для более быстрого доступа именно к последним данным.
Держать часть документов (временные) только в памяти.
Индексация документов при записи: больше индексов — медленнее.

Интересно, что бывает использование совсем не по назначению — просто Server side jscript…

Максим Цепков - отчет об ADD-2011/Мастер-класс веб-разработка на GWT и mvp4g

2011-05-17T12:24:10Z

StasFomin: Новая страница: «* Веб-разработка на GWT и mvp4g (Антон Котенко, ADD-2011) Идеология GWT. И практика. Я многое знаю по...»

Веб-разработка на GWT и mvp4g (Антон Котенко, ADD-2011)

Идеология GWT. И практика. Я многое знаю по нашим внутренним семинарам, поэтому сначала записывал не столь плотно. Но потом, когда речь пошла о концепциях и их реализации — пошли интересные мысли и размышления. Вообще доклад очень концептуально нагружен, при этом к концепциям добавлены реализации — это очень хорошо. Разбираясь с GWT следует понимать, что многие решения, которые кажутся недостатками имеют серьезные обоснования и являются результатом компромиссов — и следует разбираться в истории, чтобы понимать логику. А саму технологию он оценивает как зрелую, это не погоня за модой, все разумно и динамично развивается.

Идеология GWT состоит в том, что пишем приложения на Java, а он на лету компилирует в Javascript с учетом конкретного броузера. Очень много вложено в прозрачную передачу броузер-сервер. Это имеет обратную гримасу — любой имеющийся кусок на JS, например, визуальный редактор или google maps можно обернуть в Java и и тогда использовать внутри GWT наряду с остальным. Единственное, кроссброузерным сам не становятся, это на вас.

Model-View-Controller концепция сменилась на Model-View-Presenter — вместо единственного действия «сохранить» активное взаимодействие, интерактив по событиям. Как следствие — появляется концепция Event Bus — шины событий, на которые предполагается подписка. Именно она обеспечивает интерактив, взаимодействие презентеров. При этом View ты можешь подменять, в том числе для целей тестирования, а интерактив презентеров сохраняется.

Еще интересное.

Deferred Binding — взамен reflection. Динамическое создание интерфейсов. Они сами используют это для кроссброузерных вещей, и примеры были об этом, но в принципе идея понятна — блоки кейсов под случаи, reflection во многом так используется. Это при компиляции (но по месту?)
Dependency Injection — через GWT Injection/Guice — в динамике. Централизация настроек фабрик и прочего. Я: вообще это важная концептуальная идея, в сторону конфигурационно-ориентированного программирования и решения проблемы настроек.
Remote Service — для общения с серверами, асинхронное.
Сейчас нет ориентации на не-java сервер, но можно через request-builder, например, с php.
Верстальщикам тоже надо использовать gwt, а не html-разметку. Конечно, они могут использовать html и самому обеспечивать кроссброузерность. Но gwt все равно делает div и прочее для своей обвязки, и получается не слишком комфортно — ни разработчику, ни самому дизайнеру, когда он смотрит результаты.
Есть проблема, что js-ошибка может покрешить все приложение. Но они дорабатывают, можно перехватывать и обрабатывать.

Дальше было про mvp4g — фреймворк. Заложено мультимодульное программирование, шина событий. Он многое облегчает и активно развивается. Код сильно проще полного gwt-кода. Система аннотаций для кода.

Максим Цепков - отчет об ADD-2011/Швейцарский нож аналитика — визуализируем логи одной строкой!

2011-05-17T12:22:30Z

StasFomin: Новая страница: «[[Швейцарский нож аналитика - визуализируем логи одной строкой! (Евгений Кирпичёв, ADD-2011)|До...»

Доклад был про анализ логов для диагностики поведения системы и собственный инструментарий для этого. Отчасти я это слышал на прошлом ADD в разговорах, потому пошел с середины доклада. Было много картинок и иллюстраций, что и как можно смотреть по логу в самых различных вариантах, как делать выводы. И какие графики для каких выводов подходят. Такая вот мозаика. Смысл же инструментария — в том, что можно смешивать самые различные логи, описывая формат, и рассматривать их композитно. И смотреть графики мониторинга в реальном времени, это важно. Среди интересных эффектов, которые дает такой инструмент — график duration, который строит инструмент, выделяя события начала и конца, причем эти события, в том числе, могут быть из разных тредов и разных машин. На то, чтобы работа шла в реальном времени, в том числе при большом объеме логов, и не мешала основным процессам, затрачено много усилий, однако в реальной жизни может потребоваться дополнительная настройка размеров буферов — которую можно детектировать по собственному логу инструмента, это тоже было показано. А вообще получился довольно универсальный инструмент, кто-то с его помощью показывал поведение детей-аутистов.

Максим Цепков - отчет об ADD-2011/Взаимодействие дизайнера и программиста

2011-05-17T12:21:03Z

StasFomin: Новая страница: «Взаимодействие — в веб разработке и в мобильной. [[Взаимодействие дизайнера и программист...»

Взаимодействие — в веб разработке и в мобильной. Доклад начался с достаточно понятных, общих тезисов. Таких как понимания скоупа, сотрудничество, соседство, лучше сидеть в одной комнате. Но потом перешло к конкретным практикам для дизайнеров. И это интересно.

Карта экранов. Напечатать все, развесить. Я: очень сильно пересекается с Мейденом (я его слушал на Software People) про супер-большую доску, на которой видно все.
Видеосценарии.
Именования файлов. Правильное и общее. Я: это как именование идентификаторов, нужно.
Механизмы массовых обновлений. Связано с именованием файлов.
Правила хорошего тона в фотошопе — надеюсь, я правильно нашел ссылку. Правила просты и для опытных людей — подразумеваемы, но их прочтение заставляет задуматься об уровне новичков и наборе сообщаемых сведений.
Дизайнеры должны представлять ТТХ устройств, под которые проектируют. Например, для мобильников. И есть нюансы. Пример. Дизайнер знал про высоту 320x480 — разделил на 6 квадратных частей 160*160. Но 20 пикселей — верхняя планка, дизайнеру не сказали, программист как-то адаптировал. Но элементы перестали быть квадратными и это привело к сильному нарушению дизайна.

Максим Цепков - отчет об ADD-2011/Веб-приложения на HTML5, как альтернатива нативным приложениям

2011-05-17T12:18:50Z

StasFomin: Новая страница: «Я пошел потому, что хотел больше узнать про тренды и концепции. А также в целом про личный о...»

Я пошел потому, что хотел больше узнать про тренды и концепции. А также в целом про личный опыт. А доклад — больше про технические детали, содержание самого html5. Во многом я слышал это на других докладах. С другой стороны, рассказ был с интересными деталями, за ним стоит много личного опыта и, что очень интересно — разработка реального проекта. Но я решил, что Виталий, который там был — адекватно воспримет.

Вернулся в конце на вопросы вовремя. Обсуждение механизмов кеширования наводит на любопытные мысли.

Похоже получается сделать web-приложение работающим как online, так и автономно, с синхронизацией с центральным репозиторием по кнопке. Это, в целом, демонстрировалось в реальном продукте. При этом кеширование запросов настраивается поверх работающего приложения, включая ответы скриптов. Еще важны локальные базы данных. Но, естественно, это не для любого приложения, есть ограничения на архитектуру. По-моему, сочетание технологий может дать некоторый технологический прорыв. Но пока еще есть технические ограничения — большинство больших броузеров не поддерживают html5 в нужном объеме, а вот на Safari iPhone уже все есть.

Максим Цепков - отчет об ADD-2011/Time Management для программиста

2011-05-17T12:15:36Z

StasFomin: Новая страница: «Доклад был про управление проектов мен...»

Доклад был про управление проектов менеджером. В целом — правильные, понятные и известные вещи. Известные — мне, из различных книг по организации разработки.

Не перебрасывайте между задачами. И не беспокойте — если сказал 2 дня — не дергайте внутри, но на стендап-митинге — слушайте как дела, сопоставляйте с планами.
Работайте с приоритетами. Люди часто делают то, что интересно, а не важно. В том числе внутри задачи. Не используйте сразу новый фреймворк в продакшн.
Проактивность. Не ждите проблемы, кризиса, а интересуйтесь. Например, когда будет следующая версия у соседней команды.
Декомпозиция, мелкие задачи — чтобы перекидывать оперативно.
Упущенное время — невосполнимо.
Фокус на результате. Пример. Попросил позвонить, узнать — результат в том, что дозвонился, а не раз позвонил и забыл.
И так далее…

Единственное — они находятся в противоречии с современными трендами по самоорганизации команд, автономности и творческому подходу разработчиков, но это — каждый выбирает для себя. Более того, я примерно представляю, где работает такой подход — он позволяет делать проекты силами не очень квалифицированных, начинающих исполнителей, которые при этом учатся. Но получив опыт те, кто не станут менеджерами — уйдут. А еще стиль доклада — авторитарно-директивный. Делайте так! А когда в этом стиле излагаются даже правильные вещи — они вызывают отторжение, увы! Потому что это такое зомбирование идеологическое, хоть и правильное. Я немного послушал и ушел.

Максим Цепков - отчет об ADD-2011/Интерфейсы

2011-05-17T12:12:50Z

StasFomin: Новая страница: «Я слушал только самый конец доклада, однако могу сказать, что [[Интерфейсы — битва за право...»

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

Что касается практических советов, то я услышал один — выделяйте роли, для которых проектируете интерфейс. Хорошо, если они выделяются в исследовании бизнеса, но даже если такой возможности нет, роли «с потолка» лучше, чем их отсутствие. Наверняка были и другие советы — раньше, чем я пришел.

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

Максим Цепков - отчет об ADD-2011/Fluxus

2011-05-17T12:10:54Z

StasFomin: Новая страница: «Часть этого слота я участвовал в обсуждении с предыдущим докладчиком. Поэтому пошел с сер...»

Часть этого слота я участвовал в обсуждении с предыдущим докладчиком. Поэтому пошел с середины посмотреть — о чем вообще доклад. И увлекся, хотя сами представляемые технологии вне спектра моих интересов. Однако, меня заворожило живое кодирование — с автопревью и изменением объектов. Не то, чтобы я такого не видел, но интересно.

А доклад был про язык описания трехмерных объектов, которые что-то делают на экране, например, визуализация под музыку. Язык на основе Schema, внизу OpenGL.

Максим Цепков - отчет об ADD-2011/Философия простоты, или еретическая лекция о программировании

2011-05-17T12:08:55Z

StasFomin: Новая страница: «[[Философия простоты, или еретическая лекция о программировании (Никита Прокопов, ADD-2011)|Ин...»

Интересный доклад. Основная мысль — о том, что программисты часто реализуют сложные решения по разным причинам. И часто — внутренне тяготеют к сложным решениям. А правильно — стремиться к простоте. Поэтому лекция — еретическая, против культа сложности программиста (используешь сложный редактор — крут).

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

Экстремизм в проблемной части не мешает предлагаемым решениям быть вполне конструктивными:

Вопросы Почему и Зачем
Забота о пользователе
Использовать шаблоны только когда они нужны, а не тотально по коду
Коллего-ориентированное программирование — думайте о своих товарищах

Да, многие решения очевидны. Только в реальном мире почему-то не слишком используется :(

Я: Решение могут быть в синтезе и за плоскостью, типа общезначимых конфигов, отделенных от конкретных систем в примере с конфигами и настройками. Об этом в докладе не было. Еще было достаточно много спорных примеров улучшения решений. Однако сам доклад — безусловно интересно слушать, он будет собственные мысли.

Максим Цепков - отчет об ADD-2011/Language Oriented Programming (LOP) в действии

2011-05-17T12:01:58Z

StasFomin: Новая страница: «Очень хороший и интересный доклад. Пр...»

Очень хороший и интересный доклад. Про концепцию не только реализации собственных DSL для классов задач, но, что интереснее, про реализацию расширений к языкам общего назначения, обеспечивающих те или иные типовые конструкции, применяемые при разработке в виде шаблонов. Смысл расширений — они позволяют скрыть громоздкие языковые конструкции, например, оформление определенных фрагментов кода в с блоками finaly и перехватом исключений. С помощью расширений можно комфортно использовать фреймфворки, которые требуют не только кода на Java, но, например, конфигураций в xml — описывая все на языке.

У JetBrains есть инструмент для реализации DSL и расширений — MPS. Получается компилятор и IntelliSense в редакторе. Пока поддерживается Java и интернет-стек — jscript, css, xml, а также можно делать автономные языки. Проект YouTrack делается на основе MPS, там ограниченная версия MPS используется, чтобы пользователь создавал расширения. Что важно, MPS обеспечивает контроль по синтаксису и по системе типов, а также проверяет совместимость различных расширений, если их хочется использовать совместно. Лицензия apache 2.0 — бесплатно для коммерческого использования.

Что еще интересно — концепция диалога для работы с MPS — проекционный редактор. Они отказались от графического представления. Выводится иерархия, псевдотекстовое представление, в котором можно редактировать отдельные элементы. По опыту, привыкание 2 недели — и позитивная обратная связь кончается.

В перерывах между докладами обсуждал с Мазиным идеи интерфейса YouTrack. Весьма интересно. Он говорит, что воплотили идеи Раскина — графически представляем, но описываем, правим и вводим текстом. Например, имеем набор дел, выбрали конкретное и командами меняем, а не gui. Программисты пользуются. hr они тоже учат их, но те предпочитают gui.

ADD 2011: Отчёт Русецкого Георгия/Nemerle.Peg

2011-05-17T11:39:00Z

StasFomin: Новая страница: «Доклад начался д...»

Доклад начался долгим рассказом про то, как докладчик делал какой-то опрос на хабре. Затем, ближе к теме, рассказал немного о парсерах, упомянул ANTLR — основной конкурент Nemerle.Peg (Peg — Parser Expression Grammar). Привёл для сравнения, статистику по количеству строк кода, необходимых для реализации парсера на ANTLR и Nemerle.Peg, по которой получилось, что последний в 4 раза лаконичнее. Дальше начался livecoding, от простых примеров написания парсера с использованием Nemerle.Peg до парсера JSON. Поскольку про Nemerle я знаю только то, что рассказал Чистяков на предыдущих докладах, понял только, что Nemerle.Peg действительно позволяет написать лаконичный и эффективный парсер.

ADD 2011: Отчёт Русецкого Георгия/Nemerle Deep Dive

2011-05-17T11:37:23Z

StasFomin: Новая страница: «Докладчик — ведущий программист проекта Nemerle Владислав Чистяков. [[Nemerle Deep Dive (Владислав Ч...»

Докладчик — ведущий программист проекта Nemerle Владислав Чистяков.

Доклад длился 3 часа, но, по-моему, почти всё, что было прочитано и показано на 2х последних докладах — специфика разработки, интересная тем, кто уже программирует на Nemerle. По словам докладчика, Nemerle — гибридный язык, отчасти императивный, отчасти функциональный, отчасти метаязык, расширяемый с помощью макросов. Создан как язык, на который несложно перейти программистам, разрабатывающим приложения на C#.

Ядро языка

Типы: C# и ML.

Выражения: ML

Операторы: C (C#)

Макросы: LISP

Поддерживается indent-стиль кодирования.

Макросы языка служат для:

Создания встроенного DSL
Расширения языка
Автоматизации программирования
Контроля за кодом

Существующие макро-библиотеки:

Computation Expressions
- Yield
- Асинхронное программирование
Xml-литералы (Nemerle.Xml)
Nemerle.Peg — быстрый парсер
Nemerle.Web.Reactive — расширения для создания web-приложений (c поддержкой MVVM)
Nemerle.Rails

Расширения:

Автоматическая реализация Dependency Properties в WPF
Record — автоматическое создание конструкторов
Автоматизация паттернов проектирования ООП (abstract factory, aggregate, proxy, singleton)
Позднее связывание (?)
Surround with
Lisp comprehensions
Regexp math

Во второй части автор рассказал про тип variant — аналог union в C. Основную часть оставшегося времени подробно рассказал про pattern matching — технологию, которая позволяет, если я правильно понял, реализовать двойную диспетчеризацию. Язык интересный, но неясны перспективы развития (поддерживается де-факто сообществом, но что будет завтра — непонятно). Вероятно, поэтому ничего не слышно про применение Nemerle в коммерческих проектах. По словам автора, язык будет развиваться. Посмотрим.

ADD 2011: Отчёт Русецкого Георгия/Техника и проблемы пэкеджинга бизнес-приложений для Windows

2011-05-17T11:36:07Z

StasFomin: Новая страница: «Доклад об ...»

Доклад об организации процесса разработки и выпуска готовых к развёртыванию пакетов программ.

Не зацепило. Были какие-то рекомендации, вроде:

планировать развёртывание вместе с проектированием приложения
не откладывать создание пакета на последний день
тестировать развёртывание

и т. п. В конце доклада продемонстрировал утилиту собственной разработки (на базе Excel 2010), позволяющую просматривать содержимое msi-пакета.

ADD 2011: Отчёт Русецкого Георгия/Эффективная разработка бизнес-приложений на Silverlight и WPF

2011-05-17T11:30:44Z

StasFomin:

Доклад оказался посвящён использованию фреймворка Prism 4 для разработки бизнес-приложений.

Отмеченные особенности Prism:

Модульный подход
Независимые расширения
Применение шаблона MVVM
Независимое тестирование (?)

Prism позволяет строить приложения с использованием компонентного подхода — из независимых единиц (модулей). Модули не ссылаются друг на друга. Prism использует подход Dependency Injection для инстанциирования модулей (и применят MS-овский IoC-контейнер Unity). Далее было интересно: докладчик порекомендовал начинать разработку приложения с UI (???), рассказал немного про связывание UI с модулями и конфигурацию контейнера Unity. Затем продемонстрировал приложение Asteros Contact, на примере которого рассказал о реализации Master-Details формы с использованием View Injection (честно говоря, не впечатлило). И, наконец, указал главный, по его мнению, недостаток MVVM — «всё взаимодействие идёт через ViewModel, на которую ложиться слишком много ответственности».

В общем, за исключением некоторых базовых вещей о MVVM и Prism — доклад ни о чём.

ADD 2011: Отчёт Русецкого Георгия/Разработка приложений с использованием Windows Workflow Foundation

2011-05-17T11:29:06Z

StasFomin: Новая страница: «* Разработка приложений с использованием Windows Workflow Foundation (Максим Игнатов, ADD-2011) Докладчи...»

Разработка приложений с использованием Windows Workflow Foundation (Максим Игнатов, ADD-2011)

Докладчик — Максим Игнатов, руководитель проектов компании e-Legion.

Windows Workflow Foundation (WWF) удобно применять при разработке приложений, автоматизирующих длительные бизнес-процессы (документооборот и т. п.). Для таких процессов характерны набор состояний, в каждом из которых процесс может находиться неопределённо долгое время и ограниченный набор переходов между этими состояниями. Состояние процесса сохраняется в БД. В компании докладчика WWF была применена для разработки приложения, автоматизирующего какие-то процессы в отделе персонала. Целью доклада было заявлено показ узких мест WWF и решений возникших проблем. Вначале докладчик рассказал про разработанную систему, затем немного рассказал про подходы к использованию WWF при разработке приложений.

Разделить процесс на подпроцессы
- Плюсы:
  - Часто проще соотносится с моделью данных
  - Менее тяжеловесный Workflow
- Минусы
  - Требуется логика маршрутизации к к нужным Workflow
Единый процесс на всё
- Плюсы
  - Не нужна маршрутизация
- Минусы
  - Модель размазана
  - Тяжеловесный Workflow

Далее был рассказ про возникшие при использовании WWF проблемы, связанные с миграцией сохранённых процессов при изменении Workflow. В целом, ИМХО, технология заслуживает внимания и изучения.

ADD 2011: Отчёт Русецкого Георгия/MongoDB

2011-05-17T11:25:50Z

StasFomin: Новая страница: «* MongoDB (Сергей Туленцев, ADD-2011) '''MongoDB''' — современная нереляционная документо-ориентиров...»

MongoDB (Сергей Туленцев, ADD-2011)

MongoDB — современная нереляционная документо-ориентированная база данных. Eё можно считать золотой серединой между реляционными DB и чистыми хранилищами key-value (как memcached).

Основные качества:

Документо-ориентированность (документы хранятся в JSON-подобном формате)
Индексы по любому или нескольким атрибутам
Удобная репликация с автоматическим failover
Богатый язык запросов
Поддержка Map/Reduce
Подсистема хранения файлов любого размера — GridFS
Автоматический sharding

Масштабирование:

Автоматическое (нужно выбрать shard key)
Определить распределение данных
Трудно изменить ключ после назначения

Данные разбиваются на блоки (chunks) размером < 64Mb или 100000 объектов. В фоновом режиме работает балансировщик.

Где использовать:

Статистика
Богатое key-value хранилище
Прототипирование
Динамические данные (CMS, опросы)

ADD 2011: Отчёт Русецкого Георгия/Улучшение взаимодействия между разработкой и тестированием

2011-05-17T11:24:28Z

StasFomin: Новая страница: «[[Технологии улучшения взаимодействия между разработкой и тестированием (Андрей Кощеев, AD...»

Доклад немного маркетинговый, про использование ПО от HP для управления процессом разработки. Добрую треть доклада рассказывалось про эволюцию процесса разработки с ростом компании. Сначала просто отдел разработки, затем появление отдела QA, в котором в свою очередь появляются подразделения ручного тестирования, автоматизации тестирования и т. п. В общем, делается вывод, что с ростом компании увеличивается сложность процессов => сложность управления компанией => нужна автоматизация. Были отмечены тенденции:

Agile
Самоорганизующиеся команды
Упрощение архитектуры
Автоматизация процесса

И описаны взаимодействия между участниками процесса разработки. Собственно, взаимодействия могут осуществляться с использованием ПО от HP, весь процесс разработки отражается там. Как результат — управление качеством на всех этапах разработки.

ADD 2011: Отчёт Русецкого Георгия/Свободные лицензии

2011-05-17T11:20:41Z

StasFomin: Новая страница: «Докладчик — Михаил Шигорин, участник ALT Linux Team. '''Цель [[Свободные лицензии — улыбнись тому...»

Докладчик — Михаил Шигорин, участник ALT Linux Team.

Цель доклада — прояснить текущее положение дел с лицензиями на ПО.

Софтверная лицензия включает в себя:

Договор оферты
Определённый объём прав
Определённые обязательства

Различные лицензии отличаются набором прав и ограничений.

Проприетарная

Можно купить
Нельзя свободно применять
Нельзя модифицировать
Нельзя распространять

Shareware

Отличается от проприетарной отсутствием запрета на распространение

Non-free/freeware

Разрешается использовать и распространять
Можно заплатить авторам (donation)
Нельзя модифицировать

Public Domain

Можно всё (однако, работает не во всех юрисдикциях)

С исходными кодами — вид СПО

Free/permissive

Минимальные обязательства (однако, не всёгда ясно, можно ли распространять ПО)

Free / Copyleft

Можно модифицировать и распространять только под той же лицензией

Докладчик отметил, что Open Source — всего лишь исходники, с ними могут не передаваться права («бесплатный != свободный»). Интересная аналогия Free Software с общественно-полезными сущностями (дороги и т. п.) Касательно отношения бизнеса к свободным лицензиям. По мнению докладчика, часто применяемая парадигма «закрыть, а то сопрут» неверна, спереть можно код, а не опыт и знания.

ADD 2011: Отчёт Русецкого Георгия/Взаимодействие дизайнера и программиста

2011-05-17T11:18:26Z

StasFomin: Новая страница: «Докладчик — Александр Черный, разработчик программ для iPhone. Его [[Взаимодействие дизайне...»

Докладчик — Александр Черный, разработчик программ для iPhone.

Его доклад — описание проблем, возникших у разработчиков с приходом дизайнера и описание, как они их решали. Честно говоря, скучновато. Автор приводит названия софтин, которые использовались для разработки внешнего вида интерфейса, говорит о специфических проблемах при разработке UI под iPhone (разрешения, шрифты, цвета и т. п.). Также даёт немного советов из собственного опыта по инструментам проектирования UI:

Бумажные заготовки
Трафаретки
Balsamiq mockups
Adobe

Считает, что дизайн по почте — отстой (подтверждаю, тоже был такой негативный опыт).

ADD 2011: Отчёт Русецкого Георгия/Time management для программиста

2011-05-17T11:17:15Z

StasFomin: Новая страница: «Пошёл на доклад, полагая, что будет док...»

Пошёл на доклад, полагая, что будет доклад о персональном time-management-е. Однако, докладчик рассказал об управлении рабочим временем с позиции менеджера. По докладу показалось, что автор придерживается авторитарного стиля управления. Часть обозначенных проблем и их решений банальны, тем не менее, есть интересные мысли/советы.

Проблемы:

Разноплановые работы
Работа под давлением
Ограниченность человеческих возможностей
Непредвиденные задачи
Тяжёлые задачи
Нелюбимые вещи (которыми приходиться заниматься)

Пожиратели времени:

Болтовня (устная и письменная)
Отсутствие краткосрочного планирования
Неточные цели (нет чёткой постановки задачи)
Много почты
Митинги
Рутина
Синдром откладывания

Принципы эффективной работы:

Быть в потоке
Расставлять приоритеты
Быть проактивным — видеть потенциальные проблемы и устранять их до проявления
Декомпозировать задачи
Ожидать форс-мажора
Фокусироваться на результате
Анализ и ревью своей работы

Советы:

Email
1. Сразу отвечать
2. Читать всё
3. Сортировать почту
4. Проверять присланную информацию
5. Помечать письма как задачи
6. Заполнять Out of Office
7. Представляться в письме
Телефон
1. Не бояться позвонить
2. Думать, прежде чем звонить
3. Записывать результаты обсуждений
4. Ограничивать во времени
5. Поддерживать телефонные контакты
Задачи
1. Должны быть прогнозируемы, выполнимы и т. п.
2. При планировании должен быть буфер времени или ресурсов
3. При делегировании исполнения ответственность не делегируется(?)
  Игорь Беспальчук Имеется в виду, что, делегируя, с себя ты ответственность не снимаешь.
4. Должен быть один ответственный за задачу
5. Использовать напоминалки
Планы
1. Реалистичность
2. Включение рисков
3. Не держать только в голове — записывать
4. Показывать планы другим (share plan)
5. Регулярно обновлять
Личностное развитие
1. Не бояться говорить «нет»
2. Не быть ленивыми, скучными — делиться с коллегами новинками
3. Не останавливаться в образовании
4. Постоянно практиковаться в навыках
5. Обучать других
6. Гармония (семьи и работы)

ADD 2011: Отчёт Русецкого Георгия/Интерфейсы

2011-05-17T11:15:13Z

StasFomin:

Докладчик — Ольга Павлова из Usability Lab.

Рассказ про проектирование взаимодействия. Мне показались знакомыми основные идеи, озвученные в докладе — читал их в книжке Алана Купера «Об интерфейсе. Основы проектирования взаимодействия». Укажу основные моменты доклада.

В начале процессе проектирования взаимодействия происходит выделение персонажей (ролей) и проектировании интерфейса взаимодействия для них. Персонаж — некий собирательный образ одного из пользователей интерфейса (кстати, по мнению Купера важен полный портрет — пол, возраст, образование, профессия, семейное положение и т. п. Этот персонаж даже получает собственное имя). Затем юзабилисты пытаются построить модель взаимодействия персонажа с разрабатываемой системой.
Ряд проблем при проектировании:

Избыток контролов
Тексты на интерфейсе (формулировки). Считает, что самовольные правки текстов — преступление.
Сообщения об ошибках
Интерфейсное хамство

Недоделанную работу показывать нельзя — можно отвратить пользователя. Если всё-таки приходится — нужно обставить это «ритуалами».
Бесконечные согласования неважных деталей интерфейса с заказчиком — зло. Но в процессе согласований можно получить и действительно важную для проектирования информацию (?)
Результаты обсуждения необходимо фиксировать в модели, а не в виде «бантиков сбоку».

ADD 2011: Отчёт Русецкого Георгия/Облачная инфраструктура AWS

2011-05-17T11:12:09Z

StasFomin:

Докладчик — Леонид Выговский.

Доклад посвящён крупнейшей облачной платформе — Amazon Cloud Service. Были кратко рассмотрена AWS, какие сервисы предоставляются, сколько чего стоит, выполнено сравнение с Google App Engine. AWS — пожалуй старейший облачный сервис (запущен в 2006 году — EC2, S3).

Доступны следующие основные услуги: IaaS (Infrastructure as a service http://ru.wikipedia.org/wiki/Infrastructure_as_a_service, предоставление инфраструктуры), PaaS (Platform as a service, предоставление интегрированной платформы для разработки, тестирования, развертывания и поддержки веб-приложений как услуги, http://ru.wikipedia.org/wiki/PaaS) и SaaS (Software as a Service, http://ru.wikipedia.org/wiki/SaaS). Платформы: *nix и Windows. Всё за деньги, хотя бесплатно доступна минимальная конфигурация.

Докладчик рассказал о территориальном делении амазоновских облаков на регионы и зоны, о доступных способах хранения данных в облаке и поделился соображениями о выборе конфигурации для создании отказоустойчивого решения. Оказывается, предоставляемый VPS instance — весьма ненадёжная штука, может быть потушен в любой момент, при этом пользовательские данные, сохранённые на HDD instance-а будут потеряны (?!).

Стас Фомин 21:56, 30 мая 2011 (MSD): Комментарий Леонида Выговского: «Instance on Demand может сломаться, что есть в любом хостинге. При определенных, заранее обговоренных, условиях может быть потушен instance снятый на аукционе (hot spot)»

Для большей надёжности рекомендовал использовать минимум 2 инстанса, инстансы в 2х различных зонах или 2х различных регионах (с соответствующем ростом надёжности). Надёжное хранение данных достуно с использованием Elastic Block Storage (EBS) или Simple Storage Service (и то и другое — платно, в отличие от HDD инстанса). Также, докладчик упомянул про службу балансировки нагрузки между пользовательскими инстансами (Elastic Load Balancer) и службу автоматического управления количеством запущенных экземпляров в зависимости от нагрузки. В целом, очень интересный сервис для хостинга приложений.

Из плюсов:

не нужна своя инфраструктура, её поддержкой и обеспечением надёжности занимаются специалисты Amazon-а.
полный доступ к запущенным в облаке экземплярам.
готовые средства для управления экземплярами — их масштабированием, нагрузкой и т. п.
высокая надёжность и отказоустойчивость (да, тут докладчик упомянул про недавний fail амазона в одной из зон ;)

Минусы:

буквально за всё приходится платить (трафик, процессор, память, место для данных, балансировка и т. п.)

ADD 2011: Отчёт Русецкого Георгия/Language Oriented Programming

2011-05-17T11:10:24Z

StasFomin: Новая страница: «Доклад читал человек из JetBrains — Макси...»

Доклад читал человек из JetBrains — Максим Мазин, один из разработчиков YouTrack, активно участвующий в разработке предметно-ориентированных языков для нужд JetBrains.

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

В качестве решения, JetBrains предлагает свой продукт — среду языко-ориентированного программирования Meta Programming System(MPS). Эта среда предоставляет удобные механизмы для разработки собственного DSL и создания с его помощью программ в современном IDE. В частности, багтрекер YouTrack разработан именно с использованием MPS. В качестве иллюстрации своих слов, докладчик показал небольшое расширения для языка Java, добавляющее конструкцию для синхронизации доступа к разделяемым ресурсам — synchronized.

Работает это следующим образом:

Исходный код приложения на разработанном языке (или с использованием расширения) обрабатывается препроцессором MPS, который осуществляет генерацию исходного кода, понятного компилятору языка общего назначения (в данном случае Java)
Осуществляется компиляция сгенерированных исходников

Говоря о препроцессоре, докладчик отдельно упомянул, что, несмотря на текстовое представление внедряемых в язык узлов, они не является текстом (?!). Каждый узел «живёт» в своей ячейке, отображаемой с помощью текстового представления, а проекционный редактор MPS занимается изменением непосредственно абстрактного синтаксического дерева. В настоящий момент реализован ряд расширений языка Java с использованием MPS:

Язык запросов к коллекциям
Язык работы с датами
Поддержка замыканий
Язык описания регулярных выражений

MPS — опенсорсный бесплатный продукт, поэтому с его использованием можно разрабатывать свои DSL для любых задач. На вопрос одного из участников конференции о языковых расширениях для .NET/C# — сказали, что если в JetBrains будет разрабатываться проект на .NET, очень возможно, что они появятся, но пока нет ;(.

Уже после доклада, на стенде JetBrains разработчики продемонстрировали работу с MPS (в докладе этого не было, только слайды). Продукт выглядит интересно, наверное, имеет смысл посмотреть-изучить.

Кстати, хотелось бы отдельно отметить работу стенда JetBrains на конференции. Там присутствовали разработчики основных продуктов компании: Resharper, YouTrack, dotCover, Teamcity, можно было задать вопросы, получить ответы и скидку на лицензии Resharper и Teamcity. Разработчик Resharpera в ответ на мой вопрос о разрабатываемой в компании замене ставшего платным Reflector-а, по секрету ;) сообщил о том, что их бесплатный декомпилятор dotPeek почти готов и вот-вот (в течение одной-двух недель) появиться на сайте компании по программе Early Access. Показал его в работе (почти один в один Reflector) и пообещал тесную интеграцию с 6 м Resharper-ом.

ADD-2011: Отчёт Виталия Филиппова

2011-05-17T11:06:45Z

StasFomin:

Сайт: http://addconf.ru/add_2011
Место проведения: Санкт-Петербург, гостиница «Карелия»
Время проведения: 29-30 апреля 2011

Общие слова: за организацию «плюс», местами даже «большой плюс». Конкретные плюсы:

Вкусная еда и бутербродики, повсеместно разложенные на столах, в процессе и вне процесса кофе-брейка. Очень удобно. Я, например, оба дня таки не осилил встать к началу, соответственно, пропустил оба завтрака и догонялся бутербродиками.
Несколько Йот, разложенных в разных местах, потому что интернет от гостиницы был ужасен — то ли миллион точек доступа на 6-ом канале, забивающих друг друга, то ли просто канал отстойный.

Стас Фомин 15:15, 15 мая 2011 (MSD): SSID «ADD» — это не от гостиницы, это грамотно разведенные по WiFi-каналам (мне аж диаграмму показали) штуки три роутера от DLINKа. Но сам входной канал был вроде от гостиницы, и с ним были проблемы. Плюс еще через это все почему-то не работало VPN-подключение — проблемы думаю, тоже на стороне гостиницы и провайдера, ибо настройки роутеров я смотрел, там ничего, кроме SMB на 139 порту не было закрыто.

Во всех залах всё отлично видно и слышно, потому что один большой, а в двух других стояло по два экрана и проектора, особенно это было актуально для длинного зала-«кишки».
Нормальная гостиница, всё отлично с размещением. Даже аэрохоккей в бильярдной был :) взрослый который, где шайба бешено летает, мы в него порубились.

Ещё такой плюс-минус ADD — это разношёрстность аудитории, приводящая, с одной стороны, к отсутствию целевой аудитории на многих докладах, но зато с другой, к очень интересным «случайным попаданиям». Можно считать фишкой.

День первый я слушал и мигрировал между залами нормально, а вот второй частично прошёл мимо меня, потому что:

Пилил свой «блиц» доклад, получившийся не совсем блиц (или совсем не блиц) про архитектуру MediaWiki с рассказом под длинный-длинный скроллящийся список, потому что в последний момент было уже не до презентации.
Уже в 18:00 надо было уходить, в 19:45 на Сапсан, а до вокзала ещё доехать надо.

ADD 2011: Отчет Глеба Тарасова

2011-05-17T11:05:43Z

StasFomin:

Application Developer Days 2: Отчет Кудрявцева В.Б/Эффективная разработка бизнес-приложений на Silverlight и WPF

2011-05-17T10:35:28Z

StasFomin:

Эффективная разработка бизнес-приложений на Silverlight и WPF (Александр Онуфриев, ADD-2011)

Чудовищно скучно и скверно оформлено, ушел почти сразу.

С доклада вынес одну вещь — нужно просматривать собственные слайды на проекторе. Цвета, вполне контрастные на мониторе, могут оказаться совершенно нечитабельными.

Application Developer Days 2: Отчет Кудрявцева В.Б/Разработка RealTime веб-приложений

2011-05-17T10:33:50Z

StasFomin:

Пузатый и дредастый докладчик рассказывал про связку socket.io + Node.js. Пришел не к началу, поэтому прикладную задачу не понял.

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

На клиенте:

socket.io, js-библиотека, которая сама умеет выбирать транспорт для эффективных запросов

На сервере

Node.js (серверный JavaScript)

Что умеет:

Скорость (исполняется на движке google V8)
Модульность (есть коннекторы к многим NoSQL базам, например)
Closures
Неблокирующий ввод-вывод
Доказанная надежность (по уверению докладчика)

Как альтернатива:

JBoss Netty (Java)
Erly Comet (Erlang)
Tornado (Python)
Coffee Script (код в стиле руби компилируется в JavaScript), вместе с Node.js

Application Developer Days 2: Отчет Кудрявцева В.Б/Философия простоты или еретическая лекция о программировании

2011-05-17T10:31:43Z

StasFomin: /* Проще для пользователя */

Доклад-напоминание о том, что нужно думать о тех для кого пишешь, и о тех, с кем пишешь, не усложнять им жизнь лишний раз.

Не все советы, к сожалению, применимы к нашим системам. Например ответ на сакраментальный вопрос «Кто кого использует — пользователь систему или система пользователя?» далеко не всегда очевиден.

Application Developer Days 2: Отчет Кудрявцева В.Б/Технологии улучшения взаимодействия между разработкой и тестированием

2011-05-17T10:27:42Z

StasFomin: Новая страница: «Дядька из HP [[Технологии улучшения взаимодействия между разработкой и тестированием (Андр...»

Дядька из HP рассказывал о том, как видится тестирование ПО огромной компанией, немножко рекламируя при этом свой продукт.

Интересного было немного, основное ощущение доклада — до них наконец-то дошло, что эффективное общение между разными участниками процесса создания ПО, автоматизация рутинных операция и повышение модульности архитектуры, помогает куда больше чем монструозные методологии и (средства их поддержки) типа ALM.

Application Developer Days 2: Отчет Кудрявцева В.Б/MongoDB

2011-05-17T10:03:15Z

StasFomin: Новая страница: «Интересный рассказ про MongoDB, продвинутую NoSQL базу. У автора до...»

Интересный рассказ про MongoDB, продвинутую NoSQL базу. У автора доклада на ней крутиться приложение типа [1] для ВКонтакте, в пике — несколько сотен запросов в секунду.

Application Developer Days 2: Отчет Кудрявцева В.Б/Особенности масштабирования систем планирования и управления поставками

2011-05-15T20:25:39Z

StasFomin: Новая страница: « Михаил Антонов, [http://www.magenta-technology.ru/ru/ Magenta Development] (Самара) Для меня [[Особенности масштабир...»

Михаил Антонов, Magenta Development (Самара)

Для меня доклад оказался самым интересным на конференции — полное совпадение:

тип заказчика (крупные ритейл),
близкий бизнес-процесс,
похожий стек технологий.

Компания, основной центр разработки которой находится в Тольятти, предоставляет услуги расчета планов поставок в розничные магазины ритейл-сети со складов (Distribution Center или РЦ в принятой у нас терминологии) или напрямую от поставщика.

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

Кстати, очень хвалили специализированные аппаратные решения для Oracle, типа Exadata. Впрочем, сразу была оговорка об их недостатках — если что-то сломалось починить без дорогостоящих и редких специалистов сложно. В конечном итоге, я так понял, большая часть используемого железа — это все-таки конвенциональные сервера.

На вопрос об облачных решениях ответил, что только начинают присматриваться, но уже вполне серьезно рассматривают такую возможность, в частности, Amazon,

Application Developer Days 2: Отчет Кудрявцева В.Б/NoSQL-практикум — CouchDB

2011-05-15T20:19:17Z

StasFomin: Новая страница: «Артур Орлов, независимый разработчик, кажется, из Узбекистана, [[NoSQL-практикум: Промышленна...»

Артур Орлов, независимый разработчик, кажется, из Узбекистана, рассказывал про систему, собирающую данные со счетчиков электроэнергии в домах и промышленных предприятиях.

Отзывы об ADD-2011

2011-05-15T18:33:32Z

StasFomin:

Application Developer Days 2: Отчет Кудрявцева В.Б/Пример разработки высоконагруженной базы данных

2011-05-15T17:11:07Z

StasFomin: Новая страница: « Автор [[Пример разработки высоконагруженной реляционной базы данных (Павел Белоусов, ADD-201...»

Автор рассказывал о собственном опыте работы над реальным проектом.

Задача состояла в обеспечении репликаций из нереляционной(иерархической) БД собственной разработки в реляционную с цель обеспечить приемлемую скорость выполнения некоторых запросов (auto-complete для пользователя, отчеты). В качестве реляционной БД был выбран MS SQL.

Данные в иерархическую БД вводят пользователи в процессе своей работы, там же используются запросы к реляционной БД. Поэтому для некоторых типов данные репликации должны проходить максимум за одну минуту.

Клещами из докладчика удалось выцепить что же за данные он реплицирует и хранит — компания занимается сбором и систематизацией информации в Web.

Система делалась быстро, и, я так понял, не очень аккуратно. О производительности не думали, поэтому с ростом объема данных появились проблемы:

запросы работали медленно

autocomplete отрабатывал за несколько десятков секунд

rebuild индексов занимал до 12 часов в день!

задержки репликаций стали исчисляться десятками минут.

Что же было сделано?

денормализация
посмотрели на запросы
- убрали лишние колонки
- убрали лишние JOIN
постарались избавиться от LIKE — применили полнотекстовый поиск
научились пользоваться профайлером, поставляемым с SQL-сервер
вспомнили про индексы
- узнали, что покрывающий индексы это хорошо!

И еще одно странное решение, мотивацию я так и не понял:

стали применять «грязные» чтения

За исключением последнего пункта, который сам по себе очень сомнителен, все остальные решения абсолютно стандартны. Я сначала даже удивился — зачем был нужен доклад, автором которого вполне мог быть Капитан Очевидность? Потом, однако, мне пришла в головы мысль, что всем этим приемам, которые знакомы каждому разработчику, решавшему проблемы с производительностью БД, нигде не учат.

Единственный путь — это учиться у коллег, параллельно читая книжки от которых, без должной поддержки, голова идет кругом. Так что доклад хороший и годный — может быть даст подсказку куда смотреть разработчикам, которые впервые сталкиваются с тормозами БД. Ну а я ничего нового для себя не услышал.

Application Developer Days 2: Отчет Кудрявцева В.Б/Вымирают ли клиентские приложения

2011-05-15T16:59:29Z

StasFomin: Новая страница: «Отлично [[Вымирают ли клиентские приложения? Браузер против клиента! (Роман Здебский, ADD-2011)...»

Отлично прочитанный маркетинговый доклад про разные технологии Microsoft для построение пользовательских интерфейсов. Если тема интересна — стоит посмотреть.

Роман зачем-то пытался убедить аудиторию, что проблемы выбора между HTML(5) и Silverlight не существует. Меня не убедил

Из того, что захотелось поиспользовать — делать отчеты сразу в Excel, чтобы пользователи получали данные при помощи REST-сервисов. Что это дает?

Экономим время на разработке GUI
Экономим время на выгрузке в Excel
Можно научить пользователей строить достаточно много отчетов самостоятельно, если дать им данные

Необъектные модели предметной области. Опыт CUSTIS (Максим Цепков, ADD-2011)

2011-05-15T16:55:37Z

MaksTsepkov:

Доклад на конференции Application Developers Days 29-30.04 Питер

Application Developer Days 2: Отчет Кудрявцева В.Б/Language Oriented Programming в действии

2011-05-15T16:46:07Z

StasFomin: Новая страница: «Докладчик из самой, вероятно, известной российской (условно) фирмы-производителя ПО [[Language ...»

Докладчик из самой, вероятно, известной российской (условно) фирмы-производителя ПО рассказывал про среду разработки DSL, которая называется MPS (Meta Programming System).

Application Developer Days 2: Отчет Кудрявцева В.Б/Необъектные модели предметной области

2011-05-15T16:40:16Z

Dunemaster:

Кажется, третий доклад Максима из серии про необъектные (не ООП-ориентированные) способы осмысления предметной области. Мне понравилось, так же как доклад на Agile Days.

Рекомендую посмотреть хотя бы один из серии, для расширения кругозора (в самом хорошем смысле это слова — нужно снимать ООП-шоры!), а также для понимания, что же такое Учетная Машина как идея.

Application Developer Days 2: Отчет Кудрявцева В.Б/Time management для программиста

2011-05-15T16:21:32Z

StasFomin: Новая страница: «Менеджер проектов из Luxoft [[Time Management для программиста (Михаил Гедзберг, ADD-2011)|рассказывал пр...»

Менеджер проектов из Luxoft рассказывал про свой опыт эффективного управления временем.

Проблемы (Challenges)

Разноплановые работы
Работа под давлением
Ограниченность человеческих возможностей
Непредвиденные задачи
Большие задачи, к которым тяжело подступиться
Нелюбимые вещи (которыми приходиться заниматься)

Пожиратели времени

Болтовня (устная и письменная)
Отсутствие краткосрочного планирования
Неточные цели (нет чёткой постановки задачи)
Много почты
Митинги
Рутина
Синдром откладывания

Принципы эффективной работы

Быть в потоке
Расставлять приоритеты
Быть проактивным — видеть потенциальные проблемы и устранять их до проявления
Декомпозировать задачи
Закладываться на неизвестное:
1. Иметь буфер по времени
2. Иметь буфер по ресурсам
Фокусироваться на результате
Анализ и ревью своей работы
1. Что я сделал сегодня
2. Что я мог сделать лучше

Советы:

Электронная почта
1. По возможности, прочитывать сразу
2. По возможности, отвечать сразу
  Неотвеченное письмо — это Waste, вполне в духе Lean
3. Читать всё
4. Сортировать почту
5. Сразу проверять присланную информацию (например, гиперссылки)
6. Помечать письма как задачи
7. Заполнять Out of Office
8. Заполнять подпись в Outlook
  1. Должность
  2. Контакты

Телефон
1. Не бояться позвонить
2. Составлять план обсуждения перед тем как звонить (Write before you speak)
3. Записывать результаты обсуждений (Write after you speak)
4. Ограничивать во времени
5. Поддерживать личные контакты, хотя бы иногда звоня по телефону

Задачи
1. Должны быть S.M.A.R.T:
  1. Конкретны
  2. Измеримы
  3. Достижимы
  4. Актуальны
  5. Ограничены во времени
2. При планировании должен быть буфер времени или ресурсов
3. При делегировании исполнения, ответственность не делегируется
4. Должен быть один ответственный за задачу
5. Использовать напоминалки

Планы
1. Реалистичность
2. Включение рисков
3. Не держать только в голове — записывать. Иметь при себе блокнот
4. Показывать планы другим (share plan) В тут я как раз вспомнил Блог:TechEvol/2011-05-06_TechEvol,_quo_vadis?
5. Регулярно обновлять планы

Личностное развитие
1. Не бояться говорить «нет»
2. Не быть ленивыми, скучными — делиться с коллегами новинками
3. Не останавливаться в образовании
4. Постоянно практиковаться в навыках
5. Обучать других
6. Гармония (семьи и работы)

ADD 2011: Отчет Глеба Тарасова/Построение 3D модели сцены по одному фотоснимку

2011-05-15T16:06:45Z

StasFomin: Новая страница: «[[Построение 3D модели сцены по одному фотоснимку (Дмитрий Вихарев, ADD-2011)|Построение 3D модел...»

Построение 3D модели сцены по одному фотоснимку. Чувак из ГУ ВШЭ рассказывал то ли свою курсовую, то ли диплом, где он обозревал технологию построения 3D-модели по одной фотографии. Технология интересная, но для этого достаточно просто 10 секунд показать как это работает.

ADD 2011: Отчет Глеба Тарасова/JDK 7 and Java SE 7

2011-05-15T16:05:49Z

StasFomin: Новая страница: «JDK 7 and Java SE 7. Думал расскажут про фишечки новой Java, в чем...»

JDK 7 and Java SE 7. Думал расскажут про фишечки новой Java, в чем она догнала С#. Хренушки, доклад был унылый и пустой.

ADD 2011: Отчет Глеба Тарасова/Автоматизированный ALM

2011-05-15T16:05:02Z

StasFomin: Новая страница: «Автоматизированный ALM. Унылая реклама н...»

Автоматизированный ALM. Унылая реклама непонятно какого продукта от Parasoft. Полнейший беспробудный отстой.