Когда нам нужно предоставить пользователю возможность графического редактирования содержимого на странице, пожалуй, чаще всего мы используем JavaScript для хранения данных и передачи их на сервер, и все споры ведутся вокруг способа отображения, внешнего вида редактора. Наш выбор простирается от простого HTML (с холстом или без) до встроенного SVG или использования Flash плеера.

Выбрать между этими вариантами не сложно: SVG подойдёт для схем или планов и другой векторной графики, холст больше подходит для фотографий или других изображений. Однако, оба этих элемента требуют «отделения» себя от страницы. Под «отделением» я имею ввиду то, что любой из этих элементов требует написания дополнительных сценариев для синхронизации вида с моделью.

Для небольших объектов, структура которых хорошо описывается деревом или списком (например, корзина покупателя или бизнес-процесс), использование HTML элементов для отображения и хранения данных могло бы упростить разработку и поддержку.

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

Наблюдая со стороны это тестирование, я накопил некоторый объём информации, который, как я думаю, будет небезынтересен.

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

В чем ее суть?

Проджект менеджер (ПМ) всегда видит, кто работает лучше, а кто хуже. Кто радеет за проект, а кто относится к работе формально. Кто постоянно выбивается из сроков, а кто успевает и еще тянет на себе отстающих. Кто постоянно предлагает какие-то улучшения, а кто ведет себя пассивно. Кто опаздывает на работу и на митинги, а кто проявляет постоянную пунктуальность. Кто пишет кривой код, а кто старается сделать свою работу качественной и считает для себя унизительным показывать коллегам некачественный код. Кто проверяет свою работу, стараясь минимизировать количество багов, а кто торопится, лишь бы отстреляться, а там хоть трава не расти.
«Добрый» ПМ редко или никогда не подходит к подчиненным и не указывает им на недостатки, не ругает за плохую работу. При этом, если что-то сделано хорошо, то большинство ПМов всегда рады похлопать сотрудника по плечу и сказать: «Ты молодец!»

К чему же приводит такая «доброта»?

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

Сегодня нас 150. Ровно год назад нас было 72. Невозможно? Реально. В нашем проектном портфолио — крупнейшие игроки мировых финансовых рынков. И это закономерно.

Есть несколько условий, выполняя которые, мы получаем уверенность в наших силах, в потенциале команды и в том, что мы всё сделаем:
1. вместе и
2. как надо.

1. Подбор персонала всех уровней.
Каждая компания нуждается в высококвалифицированных сотрудниках. Хорошо бы, чтобы их не пришлось долго обучать, тренировать, учить ценой ошибок… А хорошо ли? Всегда ли идеально подходящий работник готов отдаться новой работе на 110 процентов (100 процентов рабочего времени + частичка души)? Далеко не всегда.
Мы, безусловно, берем в команду опытных разработчиков, инженеров по качеству и других специалистов. Но мы также готовы открыть свои двери молодым талантам, сила воли которых позволяет им учиться в работе и в несколько раз продуктивнее работать уже через несколько месяцев практического обучения и работы. Это наше будущее, которым мы не хотим жертвовать :)

2. Профессиональное обучение и сертификация.