Здравствуй, Хабрахабр. В этом посте я расскажу о построении системы автоматизации для малого оффлайнового бизнеса, расположенного в городе, вот уже который год находящемся на отметке около 1 млн. человек и именуемом Ростов-на-Дону.
Если вам интересно узнать как это было, что из этого вышло, а также (кто знает?) применить некоторые практики и к своему делу, то все как обычно — прошу под кат, господа.
Есть такая профессия — производство автоматизировать. Аббревиатура АСУ ТП означает «автоматизированная система управления технологическим процессом» — это система, состоящая из персонала и совокупности оборудования с программным обеспечением, использующихся для автоматизации функций этого самого персонала по управлению промышленными объектами: электростанциями, котельными, насосными, водоочистными сооружениями, пищевыми, химическими, металлургическими заводами, нефтегазовыми объектами и т.д. и т.п.
Фактически, каждый человек, живущий не в лесу и пользующийся благами цивилизации, использует результаты труда предприятий, на которых функционируют АСУ ТП.
Иногда на эту тему проскакивают статьи и на хабре. Обычно они не пользуются особой популярностью, но всё же я хочу написать несколько обзорных статей об АСУ ТП в надежде рассказать хабравчанам что-то интересное (а возможно, кому-то даже полезное) и привлечь на хабр больше своих коллег :-)
Читать полностью »
Можно предположить, что большинство инцидентов, регистрируемых в Service Desk, являются типовыми. В таком случае представляется как вполне возможным, так и небесполезным, автоматизировать процесс не только регистрации, но и диагностики инцидентов, чтобы Служба поддержки получала не только диагностическую информацию, но и наиболее вероятный диагноз, который осталось бы только подтвердить (или отвергнуть, если система ошиблась).
Эту концепцию – диагностику инцидентов «на лету» – мы и предлагаем вам обсудить.
Для диагностики инцидентов на лету необходимы:
Читать полностью »
По результатам последней переписи нас примерно 150 мегабайт. Пусть волеизьявление каждого занимает 2 кило. Получается
обьём всех результатов соответствует примерно 300ам гигабайтам. т.е. 60 DVD болванок. Это кстати в самом неоптимизированном варианте, который например подразумевает полное написание имён и адресов голосующих. Если же всех их пронумеровать…
Читать полностью »
Примерно год назад я начал разрабатывать блок управления автомобильным двигателем с нуля.
Позвольте рассказать, почему эта идея до сих пор кажется мне реалистичной.
Читать полностью »
ЦОАСУ (англ. GOMA — Goal oriented management automation) — это “Принципы, модели и методологии для анализа, проектирования и интеграции целеориентированных социально-экономических автоматизированных систем управления”. Задача ЦОАСУ — достичь максимально возможного уровня автоматизации; в идеале — полностью заменить людей машинами. Используя принципы ЦОАСУ люди способны создать системы подобные Скайнет или Матрице.
Читать полностью »
В этой статье я представлю свое видение того, на каком этапе развития находится САПР для проектировании крупных промышленных предприятий сегодня, с какими трудностями приходится сталкиваться при внедрении и какие тенденции намечаются в этой отрасли.
Читать полностью »
Так уж сложилось, что у нас в компании ведется учет работ по тестированию в небезызвестных GoogleDocs. Поскольку таким учетом занимаюсь я один, то это идеальный вариант. Плюс еще есть возможность без труда поделиться с наработками с коллегами и не нужно заботиться об актуальности версий — все сохраняется моментально.
Это основные причины выбранного варианта работы. Но, как известно, у любой монеты две стороны. Минус такого подхода состоит в том, что большие проекты трудно обрабатывать и составлять вменяемые отчеты по тестированию (для этих целей, безусловно, подходят системы управления тестами).
Совсем недавно я столкнулся с Google Script. Это инструмент, позволяющий намного эффективнее работать с документами в облаке. Я решил, что он подойдет для задачи автоматизированного составления отчетов по тестированию. И вот что получилось.
В документе в виде таблицы я веду описания пользовательских сценариев для тестирования приложений. Не претендую на подробное описание, однако самая критичная информация там имеется, а именно: раздел, к которому относится сценарий, название самого сценария, шаги сценария, статус пройденного сценария, комментарии и ссылка на страницу с описанием ошибке в баг-трекере. Набор статусов у нас обычно ограничен «Реализовано», «Дефект», «Отложено». На некоторых проектах могут добавляться и другие, но не суть. Выглядит это следующим образом:
Очевидно, что такие сценарии не удобно вести на одной странице — есть смысл разбить на несколько листов (например, по этапам или релизам).
Необходимо максимально упростить жизнь тестировщика при составлении отчетов тестирования. Идеальным будет вариант, где можно посмотреть сводку по разделам и проекту целиком, а так же не только получить список ошибок и ссылки на них, но и посмотреть на общую картину.
В качестве решения я выбрал таблицу, разделенную по разделам. Каждая строка соответствует сценарию тестирования и окрашена в соответствующий цвет (для дефектов — красный, для готовых задач — зеленый, для остального — желтый). При этом подводится статистика для каждого из разделов отдельно (сколько ошибок, сколько успешных сценариев, сколько других, то же самое в процентах) и для всего проекта целиком.
Вот такой вид отчета для сценариев:
Вот что получилось для статистики:
8 сентября были первые выборы на которых я работал, причём даже не наблюдателем, а целым ПРГ (член избирательной комиссии с правом решающего голоса). Выборы на моём участке проходили с использованием КОИБов — чудесных таких машинок, которые затрудняют вбросы (пачкой бюллетень туда не засунешь, а по одному не дадут наблюдатели) и выдают результат, распечатанный на бумажке по одному нажатию кнопки. Отличная, в теории, вещь. Но, как знают все, кто следил за результатами выборов, подсчёты результатов с участков, оборудованных КОИБами заняли практически всю ночь после выборов — то есть как в старые добрые времена с ручным пересчётом. Вот почему так произошло и что с этим можно сделать я и хочу рассказать.
Чуро Чудо избирательных технологий
Читать полностью »
Плагин позволяет собрать несколько CSS или Javascript файлов воедино.
Я согласен, что подобных программных решений очень много, например Minify, YUI Compressor или конкантенатор из Pagespeed service от Google. Но для шаблонизатора Smarty мне подобного не попадалось, и я решил написать свое и попроще.
Плагин работает довольно просто: когда один из включаемых файлов изменяется, он создает новый выходной файл и возвращает к нему путь.
Читать полностью »
