Программинг микроконтроллеров → Простая автоматизация: программируемые реле Easy из песочницы
Здравствуйте, уважаемое сообщество!
На Хабре уже много сказано слов о различных устройствах автоматизации, начиная от простых Arduino, заканчивая промышленными многопроцессорными системами. Я же хочу закрасить очередное белое пятно на карте хабро-автоматики статьей о промежуточных устройствах — программируемых реле, на примере микропроцессорных устройств Easy производства корпорации Eaton (Moeller).
Прошло уже достаточно много времени с моего первого знакомства с данным типом устройств, но по-прежнему, эти «электронные малыши» остаются незаменимыми помощниками для реализации широкого спектра инженерных и бытовых задач.
На Хабре уже много сказано слов о различных устройствах автоматизации, начиная от простых Arduino, заканчивая промышленными многопроцессорными системами. Я же хочу закрасить очередное белое пятно на карте хабро-автоматики статьей о промежуточных устройствах — программируемых реле, на примере микропроцессорных устройств Easy производства корпорации Eaton (Moeller).
Прошло уже достаточно много времени с моего первого знакомства с данным типом устройств, но по-прежнему, эти «электронные малыши» остаются незаменимыми помощниками для реализации широкого спектра инженерных и бытовых задач.
Ruby → Создание EXE файла из ruby скрипта при помощи ocra на примере утилиты командной строки, посылающей XMPP (Jabber) уведомления из песочницы
Понадобилось мне, чтобы торрент клиент оповещал меня в QIP о закачке очередной порции добра.
Ринулся я искать подходящую утилиту с интерфейсом командной строки для отправки XMPP сообщений… и ничего не нашел — кругом клиенты, не заточенные для нужд автоматизации. Отсутствие очевидных кандидатов подвигло меня к написанию собственной утилиты.
Ринулся я искать подходящую утилиту с интерфейсом командной строки для отправки XMPP сообщений… и ничего не нашел — кругом клиенты, не заточенные для нужд автоматизации. Отсутствие очевидных кандидатов подвигло меня к написанию собственной утилиты.
Системное администрирование → Перспектива системного администратора и облачные сервисы из песочницы
Мы знаем, что с изобретением фабричного конвейера, который позволил автоматизировать ручной труд, произошло массовое сокращение рабочих мест, вместе с тем повысив общие требования к квалификации персонала.
С приходом облачных технологий ситуация повторяется.
В данной статье будет идти речь о перспективах профессионального развития Windows-ориентированного системного администратора.
С приходом облачных технологий ситуация повторяется.
В данной статье будет идти речь о перспективах профессионального развития Windows-ориентированного системного администратора.
Анализ и проектирование систем → Облачное ЖКХ: взгляд изнутри из песочницы
По мотивам недавнего топика.
По-идее, in a better world, правительство принимает постановление, потом ещё одно, президент даёт поручение, министры, губернаторы и мэры их исполняют и выпускают свои, выделяются деньги, нанимается команда профессионалов, и… через какое-то время появляется «Облачное ЖКХ». В облачном ЖКХ не только учет показаний приборов учёта (на что давил предыдущий автор), но и прозрачность, Интернет-кабинеты, оплату и разборки абонент устраивает сидя на диване с кредитной картой и видеокамерой, УК сокращают штат, РСО ремонтируют сети и устраняют утечки, информация прозрачна, доступна и собрана в одном месте, бухгалтерия доступна, деньги не воруют. Видя это, управляющие компании рады – они же автоматизировали столько работы, их не напрягают вопросами и скандалами жильцы – всё ведь видно и прозрачно, жильцы, довольные красивыми картинками говорят спасибо управляющей компании и голосуют «за» президента, однако…
In a better world…
По-идее, in a better world, правительство принимает постановление, потом ещё одно, президент даёт поручение, министры, губернаторы и мэры их исполняют и выпускают свои, выделяются деньги, нанимается команда профессионалов, и… через какое-то время появляется «Облачное ЖКХ». В облачном ЖКХ не только учет показаний приборов учёта (на что давил предыдущий автор), но и прозрачность, Интернет-кабинеты, оплату и разборки абонент устраивает сидя на диване с кредитной картой и видеокамерой, УК сокращают штат, РСО ремонтируют сети и устраняют утечки, информация прозрачна, доступна и собрана в одном месте, бухгалтерия доступна, деньги не воруют. Видя это, управляющие компании рады – они же автоматизировали столько работы, их не напрягают вопросами и скандалами жильцы – всё ведь видно и прозрачно, жильцы, довольные красивыми картинками говорят спасибо управляющей компании и голосуют «за» президента, однако…
Life is a bitch
Анализ и проектирование систем → Облачное ЖКХ
Занимаясь автоматизацией производства, разработчики сталкиваются со множеством проблем. Но две из них волнуют всех:
1. Передача данных с объекта.
2. Организация базы данных.
1. Передача данных с объекта.
2. Организация базы данных.
Программирование → Генерация списка IPv4 адресов на TCL и немного систем счисления
Не так давно потребовалось решать задачу массового обновления конфигурации устройств. Стандартная задача системного администрирования, если у вас в обслуживании больше одного устройства выполняющего однотипные функции. Для решения существуют как универсальные продукты, например из доступных redmine.nocproject.org, так и множество скриптов широко представленных на тематических форумах и порталах. Как раз на этот случай под рукой и должен был оказаться собственный написанный скрипт, но не оказался, поэтому учитывая что время для манёвров было, скрипт был написан заново, выполнен и положен на полочку, чтобы там в очередной раз затеряться.
Для написания был использован expect — expect.sourceforge.net, надстройка над TCL позволяющая обрабатывать и реагировать на ответы различных интерактивных консольных утилит, в частности, telnet. Учитывая что для TCL раньше писать не приходилось, код нуждался в повторном осмыслении. Ключевой момент скрипта это генератор списка IPv4 адресов для обработки, после внимательной оценки данный кусок программы удалось значительно, на мой взгляд, оптимизировать, по крайней мере сократить количество строк на треть и безболезненно добавить новый функционал. Причём все эти сокращения мало относились к специфики TCL, а касались принципиальных подходов к построению алгоритма в целом.
Я выделил этот код в отдельную утилиту, которую попытаюсь очень подробно разобрать далее по тексту — как было «до» и что стало «после», и почему не получилось написать сразу так как «после». Мне не всё в ней нравится до сих пор: смущают как алгоритмические проблемы так и проблемы TCL, например использование списков вместо массивов (что быстрее?, безопаснее?, идеологически вернее?), все сомнения тоже присутствуют в тексте, с надеждой на конструктивные комментарии.
Для написания был использован expect — expect.sourceforge.net, надстройка над TCL позволяющая обрабатывать и реагировать на ответы различных интерактивных консольных утилит, в частности, telnet. Учитывая что для TCL раньше писать не приходилось, код нуждался в повторном осмыслении. Ключевой момент скрипта это генератор списка IPv4 адресов для обработки, после внимательной оценки данный кусок программы удалось значительно, на мой взгляд, оптимизировать, по крайней мере сократить количество строк на треть и безболезненно добавить новый функционал. Причём все эти сокращения мало относились к специфики TCL, а касались принципиальных подходов к построению алгоритма в целом.
Я выделил этот код в отдельную утилиту, которую попытаюсь очень подробно разобрать далее по тексту — как было «до» и что стало «после», и почему не получилось написать сразу так как «после». Мне не всё в ней нравится до сих пор: смущают как алгоритмические проблемы так и проблемы TCL, например использование списков вместо массивов (что быстрее?, безопаснее?, идеологически вернее?), все сомнения тоже присутствуют в тексте, с надеждой на конструктивные комментарии.
Управление проектами → ВНЕДРЕНИЕ «ПОД КЛЮЧ»: взаимопонимание сторон
Всем привет!
Приглашаю ознакомиться ERP-программистов, аналитиков и консультантов с тезисами, применение которых может:
— упростить процедуры выбора и внедрения ERP-системы для производственного предприятия
— наладить взаимопонимание при общении первых лиц со стороны заказчика с менеджерами проекта со стороны исполнителя и прийти к доверительным отношениям внутри команды проекта
— сэкономить время менеджеров своей организации и снизить свои затраты на проект
Под термином в названии статьи «внедрение «под ключ»» подразумевается поставка и внедрение ERP-системы в полном соответствии с ожиданиями и требованиями клиента.
Обосновывается утверждение, что для того, чтобы сделать проект по внедрению ИС успешным и быстрым, от заказчика, кроме понимания целей такого проекта, желания их достичь и ресурсов для их достижения, потребуется потратить много собственного времени на участие в каждом стадии проекта в качестве полноценного его участника. Для облегчения понимания проектов внедрения ИС заказчиком проведена аналогия между заказным программным обеспечением (ПО) и обычным изделием – ковром, который тоже можно изготовить по индивидуальному заказу.
Приглашаю ознакомиться ERP-программистов, аналитиков и консультантов с тезисами, применение которых может:
— упростить процедуры выбора и внедрения ERP-системы для производственного предприятия
— наладить взаимопонимание при общении первых лиц со стороны заказчика с менеджерами проекта со стороны исполнителя и прийти к доверительным отношениям внутри команды проекта
— сэкономить время менеджеров своей организации и снизить свои затраты на проект
Под термином в названии статьи «внедрение «под ключ»» подразумевается поставка и внедрение ERP-системы в полном соответствии с ожиданиями и требованиями клиента.
Обосновывается утверждение, что для того, чтобы сделать проект по внедрению ИС успешным и быстрым, от заказчика, кроме понимания целей такого проекта, желания их достичь и ресурсов для их достижения, потребуется потратить много собственного времени на участие в каждом стадии проекта в качестве полноценного его участника. Для облегчения понимания проектов внедрения ИС заказчиком проведена аналогия между заказным программным обеспечением (ПО) и обычным изделием – ковром, который тоже можно изготовить по индивидуальному заказу.
Идеи для стартапов → Комплекс устройств для автоматической оплаты проезда на транспорте на основе системы дальней RFID-идентификации
Вот было бы удобно!
Есть ныне так называемые транспортные карты. Подходит контролёр, подносит к твоей карте считывающее устройство, и тогда сумма списывается. Но ведь можно было бы бесконтактно сделать! Мне видится это так:
1) Человек заходит в транспортное средство (автобус, например), садится. Где-нибудь у водителя стоит RFID-система дальней идентификации. Каждая карта привязано к одному конкретному человеку; соответственно, на каждой карте расположена RFID-метка.
2) Если человек не вышел после заданного таймаута после входа, значит, — он намерен ехать, и тогда автоматически сумма проезда снимается с его карты.
3) Если в считывающую систему ещё и GPS-модуль проинтегрировать, то система — в случае, если стоимость проезда варьируется в зависимости от того, до какой остановки едет пассажир — в момент пересечения автобусом очередного «чекпоинта» списывает с карты пассажира дельту (разницу в оплате).
4) Для пущей удобности нужно бы организовать возможность пополнения таких карт электронно (через терминалы, через интернет и т.п.)
5) Информация по каждому человеку — владельцу такой карты — пусть передаётся со считывающих систем в единый процессинговый центр. Юзер, авторизовавшись на соответствующем сайте, мог бы видеть отчёт по поездкам (по дате, по маршруту, по номеру транспорта (как по госномера, так и по номеру рейса), по длительности пездок) и, соответственно, по потраченным средствам.
Преимущества:
1) Убираем толкучку.
2) Невозможно обмануть систему.
3) Можно получать аналитические сведения о своих поездках.
А как вы, уважаемые друзья, считаете, жизнеспособна ли такая система?
Есть ныне так называемые транспортные карты. Подходит контролёр, подносит к твоей карте считывающее устройство, и тогда сумма списывается. Но ведь можно было бы бесконтактно сделать! Мне видится это так:
1) Человек заходит в транспортное средство (автобус, например), садится. Где-нибудь у водителя стоит RFID-система дальней идентификации. Каждая карта привязано к одному конкретному человеку; соответственно, на каждой карте расположена RFID-метка.
2) Если человек не вышел после заданного таймаута после входа, значит, — он намерен ехать, и тогда автоматически сумма проезда снимается с его карты.
3) Если в считывающую систему ещё и GPS-модуль проинтегрировать, то система — в случае, если стоимость проезда варьируется в зависимости от того, до какой остановки едет пассажир — в момент пересечения автобусом очередного «чекпоинта» списывает с карты пассажира дельту (разницу в оплате).
4) Для пущей удобности нужно бы организовать возможность пополнения таких карт электронно (через терминалы, через интернет и т.п.)
5) Информация по каждому человеку — владельцу такой карты — пусть передаётся со считывающих систем в единый процессинговый центр. Юзер, авторизовавшись на соответствующем сайте, мог бы видеть отчёт по поездкам (по дате, по маршруту, по номеру транспорта (как по госномера, так и по номеру рейса), по длительности пездок) и, соответственно, по потраченным средствам.
Преимущества:
1) Убираем толкучку.
2) Невозможно обмануть систему.
3) Можно получать аналитические сведения о своих поездках.
А как вы, уважаемые друзья, считаете, жизнеспособна ли такая система?
Разработка под Apple iOS → Скрипт сборки и публикации приложений для TestFlightApp
На этой неделе проскочило пару материалов (один, второй) про сервис тестирования iOS-приложений TestFlight (http://testflightapp.com). У ресурса есть много функций, но лично для меня он решил две задачи:
- рассылка приложения (или оповещения) по имейлам
- Over The Air загрузка на устройства тестировщиков и начальства без подключения к iTunes
Т.к. эти задачи делали некоторое количество головной боли и требовали рутинных операций, решил их автоматизировать. И как только собрался собирать на коленке веб-приложение, как под руку подвернулся TestFlight.
Веб-разработка → Регрессионное тестирование вёрстки. Идея автоматизации
Когда мы верстаем новые фичи, либо фиксим баги в небольшом проекте, нет проблем проверить, не поломали ли мы что-то работающее. Для этого достаточно просто его прокликать. Но так бывает не всегда: наш текущий проект насчитывает около 200 уникальных страниц и мы столкнулись с проблемой автоматизации регрессионного тестирования вёрстки. И если у программистов всё всем давно известно, методы тривиальны, да и ПО соответствующее написано, то нам, front end разработчикам, приходится ломать голову. Но мысли некоторые есть.
В контексте этого документа, я буду условно разделять все ошибки вёрстки на ошибки раскладки (связаные с позицией блока в документе) и оформления (как то цвет текста, фона и др.) Далее мы будем рассматривать ошибки раскладки.
При вёрстке мы используем подход вроде Object Oriented CSS. Таким образом, наша страница состоит из блоков, блоки могут быть как простые, не содержащие других блоков, так и составные, имеющие внутри себя простые блоки. Мы сделали свой код максимально некаскадным (за исключением некоторых наследуемых значений, вроде цвета ссылки, текста и шрифта), и, казалось бы, если мы аккуратно делаем девтест того самого блока, который подвергается изменениям, сломаться ничего не должно. Как бы ни так! Потому что:
В контексте этого документа, я буду условно разделять все ошибки вёрстки на ошибки раскладки (связаные с позицией блока в документе) и оформления (как то цвет текста, фона и др.) Далее мы будем рассматривать ошибки раскладки.
Из-за чего весь сыр-бор
При вёрстке мы используем подход вроде Object Oriented CSS. Таким образом, наша страница состоит из блоков, блоки могут быть как простые, не содержащие других блоков, так и составные, имеющие внутри себя простые блоки. Мы сделали свой код максимально некаскадным (за исключением некоторых наследуемых значений, вроде цвета ссылки, текста и шрифта), и, казалось бы, если мы аккуратно делаем девтест того самого блока, который подвергается изменениям, сломаться ничего не должно. Как бы ни так! Потому что: