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

AgileDays -2011:Отчет Заборова М.А.

2011-06-03T10:45:25Z

StasFomin:

Максим Цепков - AgileDays-2011

2011-06-02T16:58:30Z

StasFomin:

Автор отзыва

AgileDays-2011:Отчет Цыганкова Д.А.

2011-06-02T13:47:45Z

StasFomin: /* Lightning Talk */

Автор отчета

AgileDays-2011: Отчет Кудрявцева В.Б

2011-06-02T13:45:27Z

StasFomin:

Автор отчета

AgileDays-2011: Отчет Беликова Сергея

2011-06-02T13:40:58Z

StasFomin:

AgileDays-2011:Отчет Никитина В.В.

2011-06-02T13:27:03Z

StasFomin:

В целом конференция понравилась: место, инфраструктура, организация. Были, конечно, и недочеты, но их я уже записал в опросник организаторов. Очень порадовали два доклада и два тренинга Сергея Дмитриева (Норвегия) и Тимофея Евграшина (Украина) (о них скажу ниже).

Для меня основной положительной мыслью, которую я еще раз освежил в памяти, была такая: нам надо наращивать agile'вскую гибкость, самоорганизацию и взаимное доверие в командах.

AgileDays-2011: Отчет Гребнева Н.Ю.

2011-06-02T13:23:23Z

StasFomin: /* Lighting talk */

Автор отчета

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

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

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

Далее подробно по каждому докладу.

Особенности масштабирования систем планирования и управления поставками (Михаил Антонов, ADD-2011)

2011-05-27T18:43:18Z

StasFomin: /* Презентация */

Реализация Recommendation Engine средствами MS SQL (Глеб Луцков, ADD-2011)

2011-05-27T18:39:05Z

StasFomin:

Вымирают ли клиентские приложения? Браузер против клиента! (Роман Здебский, ADD-2011)

2011-05-26T15:29:26Z

StasFomin:

Системная архитектура вместо требований (семинар 2011-03-22, preview ReqLabs-2011)

2011-05-26T14:46:29Z

StasFomin:

Докладчик: Михаил Заборов
Дата: 22 марта 2011

Производительность и энергопотребление мобильных приложений на примере Windows Phone 7 (Владимир Колесников, ADD-2011)

2011-05-26T14:43:07Z

StasFomin:

Как сделать интернет-сайт на SharePoint и не передумать на полпути (Владимир Колесников, ADD-2011)

2011-05-26T14:41:51Z

StasFomin:

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

2011-05-25T15:27:19Z

StasFomin:

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

2011-05-25T09:39:20Z

StasFomin:

NoSQL-практикум: Промышленная автоматизированая измерительная система на CouchDB (Артур Орлов, ADD-2011)

2011-05-25T09:38:11Z

StasFomin:

Мобильная веб-разработка (Андрей Ребров, ADD-2011)

2011-05-25T09:17:13Z

StasFomin: /* Презентация */

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

2011-05-23T15:00:27Z

StasFomin:

Увеличиваем производительность MySQL в десятки раз используя HandlerSocket (Александр Календарев, ADD-2011)

2011-05-23T14:38:21Z

StasFomin: /* Аннотация */

Пример разработки высоконагруженной реляционной базы данных (Павел Белоусов, ADD-2011)

2011-05-23T14:32:52Z

StasFomin:

Построение 3D модели сцены по одному фотоснимку (Дмитрий Вихарев, ADD-2011)

2011-05-23T14:31:36Z

StasFomin:

Первый опыт внедрения WPF в сложной системе (С++ и COM) (Михаил Павлов, ADD-2011)

2011-05-23T14:29:36Z

StasFomin:

Nemerle Deep Dive (встреча ALT.NET, 2011-03-31)

2011-05-23T13:18:27Z

StasFomin:

Доклад: ~~"Nemerle must die"~~ «Nemerle deep dive» («Глубокое погружение в Nemerle»).

Докладчик: Чистяков Владислав, текущий maintainer, архитектор и идеолог языка Nemerle.

Рассказ о языке:

Ядро языка;

Вывод типов;

Мимикрия под C# в области поддержки ООП;

Поддержка функционального программирования:
Функции как первоклассные значения;

Алгебраические типы;

Сопоставление с образцом;

Гигиенические (LISP) макросы в Nemerle:
Что такое? С чем едят?

Как сочетаются с IDE и прочими технологиями?

Сложности разработки, отладки, сопровождения.

Развечание мифов;

Ограничения версии 1.0;

Что будет в Nemerle 2.0?

Примеры практического использования макросов, прикладные макро-библиотеки:
Nemerle.Xml — XML-литералы;

Nemerle.Peg — быстрый и гибкий генератор парсеров шаговой доступности;

ComputationExpressions:
Асинхронное программирование;

Yield внутри выражения;

Другие применнения.

Nemerle on Rails — миграции, автоматизация формирования ViewModel, движок рендеренга HTML «Spark»;

Nemerle.WUI.Reactive — реактивный Web-интерфейс на основе статически типизированного языка вместо скриптов;

Мелкие полезняшки:
Автоматизация реализации зависимых свойств в WPF

Record — автоматизация создания конструкторов

Автоматизация паттернов проектирования ООП (Abstract factory, Aggregate, Proxy, Singleton)

Late-binding — позднее связывание

Surroundwith — создание аналогов using и lock в мгновение ока.

Memoize

$-строки

Assertions

ListComprehension

Regexp match

StructuralEquality, LexicographicCompareTo, StructuralHashCode

.. и многое другое.

Nemerle.Peg — .NET генератор парсеров шаговой доступности (Денис Рысцов, ADD-2011)

2011-05-21T05:27:03Z

StasFomin:

«70% чего?» или различные метрики измерения тестового покрытия (Дмитрий Фазуненко, ADD-2011)

2011-05-21T05:26:38Z

StasFomin:

Object XPath Navigator (Андрей Майоров, ADD-2011)

2011-05-21T03:51:31Z

StasFomin: /* Аннотация */

Заднее чутье разработчика, или как избежать проблем эксплуатации? (Антон Белоусов, ADD-2011)

2011-05-20T10:49:46Z

StasFomin:

Фриланс — будущее IT-разработки (уже наступило?) (Стас Давыдов, ADD-2011)

2011-05-20T10:49:40Z

StasFomin: /* Аннотация */

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

2011-05-19T20:15:02Z

StasFomin: /* Nemerle.Peg — .NET генератор парсеров шаговой доступности */

Конференция проводилась 29-30 апреля 2011 в Санкт-Петербурге.

Гостиница (бизнес-отель «Карелия»): Весьма неплохая (на фоне отстойной гостинице в Ярославле, где проводилась ADD-2010, просто отличная). Правда, обещанный WiFi работал только в холле гостиницы, в номере не работал.

Организация: Общее впечатление: организовано на хорошем уровне, доклады читались в трёх секциях, места всем хватало (единственно — секция B располагалась в переходе между зданиями, не очень удобный зал). Обеды, кофе-брейки также без нареканий — всё на уровне. А вот качество докладов, на мой взгляд, хуже, чем на предыдущей конференции ADD.

Оптимизация LAMP-приложения на примере OpenX: разгоняемся до 1000 запросов в секунду (Александр Чистяков, ADD-2011)

2011-05-18T09:48:52Z

StasFomin:

Разработка программного обеспечения для маленьких (ADD-2011, Яков Сироткин)

2011-05-18T09:47:48Z

StasFomin:

ADD 2011: Отчет Василия Маслова

2011-05-18T08:10:14Z

StasFomin: /* Nemerle Deep Dive */

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

2011-05-18T08:08:52Z

StasFomin:

В статье Максим Цепков - отчет об ADD-2011/Заметки по докладам - полные заметки, которые я делал на конференции - сохранил для себя

Максим Цепков - отчет об ADD-2011/Разработка программного обеспечения для маленьких

2011-05-17T17:26:04Z

StasFomin:

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

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

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

Послушав некоторое время я ушел на другие доклады — поскольку примерно понял, о чем доклад и эти вещи мне известны. А потом вернулся, посмотрев других… Потому что приятно слушать со-культурного человека. Вообще этот слот — пример хорошего планирования. Якова поставили одновременно с Гедзбергом из Luxoft и каждый мог выбрать доклад по своей культуре, а технари — уйти на html5.

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

2011-05-17T16:17:05Z

StasFomin: Новая страница: «[[Взаимоотношения заказчика и исполнителя на проекте (Дмитрий Завалишин, ADD-2011)|Большой рас...»

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

Несмотря на то, что любой проект — совместное детище заказчика и разработчика, и никто не может сказать заранее, где возникнут проблемы, часто заказчик требует указания сроков и бюджета («Я не знаю, что мне нужно сделать, но мне нужны точные сроки и бюджет.»). Отсюда:

Цель разработчика — сделать заказчика счастливым за определённые срок и бюджет (при этом, как ни странно, не столь важна реализованная функциональность).

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

Кто клиент? А кто будет пользоваться? Часто это разные люди
Есть ли у него опыт заказной разработки?
Кто платит, кто ставит задачу, кто проверяет
Понимает ли он, зачем ему это?

В процессе разработки нужно активно взаимодействовать с заказчиком, стремясь достичь единого понимания целей, рисков, точности оценок. Крайне желательно знать, что можно урезать при необходимости, что можно перенести на потом (но при этом всё же сделать), то есть иметь представление о приоритетах задач. Также является важным документирование в процессе работы над проектом.

Vision — идея проекта (1 страница)
Требования (формируются в начале работы, страниц на 100, необходимо провести review с разработчиками и заказчиком), а также эскизы и use-cases.
Тест-план. По признанию докладчика, они сами обычно его не делают, если требования прописаны детально
План проекта
Deployment — диаграмма (чтобы не было проблем за день до сдачи, когда выясниться, что написанный софт не ставиться на оборудование заказчика)

Для контроля процесса разработки применяются различные инструменты. Некоторые из них, которые применяются в компании докладчика:

Трекинг прогресса разработки. Два прогресс-бара, один показывает готовность проекта по плану, другой — расход бюджета.
Регулярные релизы, ревью с клиентом
Сперва сделать вчерне всё, поскольку 30 % окажется не нужно, и нет риска застрять на полировке какой-нибудь фичи.

Если клиент не верит в предъявленные трудозатраты, можно:

Показать внутреннюю отчётность
Показать багтрекер
Распечатать код — по утверждению докладчика, он однажды так и поступил ;)

Что касается вопросов применяемой архитектуры и компонентов:

Знакомый инструментарий лучше, поскольку всё новое — непредсказуемо
Готовый сторонний код снижает стоимость и увеличивает риски
Повторное использование компонентов. Велика вероятность, что клиенту подойдёт ранее разработанное решение (его часть)
Интеграция с существующими системами — огромный риск

Сделать больше, чем просили — напрашиваться на проблемы. Особенно этого не любят западные заказчики («зачем вы сделали, то, что мы не просили, и кто за это заплатит?»)

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

Mac AppStore - спасение небольших разработчиков под Мак? (Сергей Кудряшов, ADD-2011)

2011-05-17T16:05:12Z

StasFomin: /* Примечания и отзывы */

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

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