Category: работа

Category was added automatically. Read all entries about "работа".

Серьёзно о главном

Тест Джоэла для моей нынешней работы

 Вопросы из теста Джоэла (макс. 12 баллов):

  1. Пользуетесь ли вы системой контроля версий? ДА
  2. Можете ли вы собрать продукт за один шаг? ДА
  3. Выполняете ли вы ежедневные сборки (билды)? НЕТ
  4. У вас есть база данных ошибок (багтреккер, Trac, Redmine, Jira)? ДА
  5. Вы исправляете ошибки перед написанием нового кода? ДА
  6. У вас есть актуальный план работ? ДА
  7. У вас есть техническое задание (спецификация требований)? ДА
  8. У программистов спокойные условия труда? ДА
  9. Используете ли вы лучшие инструменты, которые можно купить за деньги? НЕТ
  10. У вас есть тестировщики? НЕТ
  11. Пишут ли новые кандидаты код во время собеседования? ДА
  12. Проводите ли вы коридорное тестирование удобства использования программ? НЕТ

Итого: 8 баллов

Разбор ответов далее.

Collapse )
Codded

Подготовка к собеседованию, проверка работодателя программиста




Собеседованиепрограммиста, проверка работодателя

Собеседованиепрограммиста, проверка работодателя



Данный очерк собран по материалам статей



Первый рабочий день и… о боже, что я тут делаю?! Нет, ну серьезно кто вообще так пишет код?


Дружный коллектив? Мои коллеги вообще заметили, что я вышел на работу?


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


Знакомая ситуация? 


Обычно собеседование выглядит как односторонний допрос, где работодатель решает “да” или “нет”. Но это не так. Вы с работодателем в равных правах и в равном количестве имеете право задавать вопросы и речь не только о ДМС, карьерном росте и сорте чая на кухне. 


Ниже подборка вопросов, которые помогут вам понять, что перед вами: компания мечты или очередной потерянный месяц/год. 


Collapse )
Кот канарский полосатый толстый

Контролер Enatel SM36 мониторинг по SNMP

Попалась мне в работе старая модель 2012 года, в ней была версия SNMPv1, и другие версии включить не получалось. В итоге удалось настроить отправку трап. Контролер отправляет трапы текущих аварий постоянно с заданным интервалом, так что у вас будет целая куча одинаковых аварий! 

Настройка была следующей. Через утилиту SM36 Configuration в режиме эксперта устанавливаем настройки SNMP. Меню Network, поле Network Settings ставим Trap Mode: SNMP. Жмем W рядом с полем для записи в устройство этого значения. Внимание! Поле Gateway, DNS нельзя оставить пустым, укажите 0.0.0.0 если не используете. Далее ставим на вкладке SNMP:

  • SNMP Trap Version — SnmpV1 (v1 Style)
  • SNMP Trap 1 IP Address, SNMP Generiv Trap IP Address, SNMP Alarm Trap IP Address 1 = ip-адрес менеджера трап.
  • SNMP Trap Resend Timeout = 300 s, название путанное, на самом деле  этот параметр задает интервал периодической отправки трапов, тут выставили на 5 минут.

Далее нужно перезагрузить сетевой модуль, нажмите Reset Network Microcontroller. После этого текущие аварии (отражены в веб-консоли на странице Alarm Status) вы будете получать раз в 5 минут в своем SNMP-менеджере. Осталось настроить удаление дубликатов, чтобы лог не завалило быстро.

Для данной модели не получится применять принудительную синхронизацию, как мы это делаем для ENE-04 и Elteco. Она все делает в лоб, просто постоянно отправляя таблицу аварий в виде трапов с заданным интервалом.

Серьёзно о главном

Автоматическая публикация стабильных сборок

Мне не очень нравиться менять на сайте ссылку на последнюю стабильную версию продукта вручную, я это совсем не люблю.
Чтобы это хоть как-то автоматизировать я придумал следующее.
Ссылка постоянна, имя файла содержит токлько главный номер версии.
Jenkins умеет публиковать артефакты сборки через FTP или в общую папку Windows. Я настроил послесборочные шаги так, чтобы архив с последним обновлением выкладывался по FTP в одну и ту же папку. Папка именуется так "корень-FTP/каталог-продукта/last/update/", для установочного дистрибутива папка "../last/dist". Задача очищает папку перед загрузкой новых артефактов, потому там будет самая новая версия. Каталог доступный по FTP одновременно доступен и веб-серверу, потому на сайте я просто указываю этот путь с http, например "http://example.org/files/pub/product-name/last/update/product-update.zip".

Автоматическая публикация стабильной сборки
Для автоматической публикации стабильной сборки серверу нужно знать, какая из них стабильная.
Тут два варианта:

  1. собирать последний созданный тег из хранилища;

  2. собирать из специальной ветки stable.

Мне больше нравиться вариант 2. Настроено это так: права на запистьв в ветку stable, есть только у разработчика отвечающего за выпуск версий, когда разработчики выпустили новую версию и зафиксировали ее в тег, ответственный за выпуск сливает этот тег в ветку stable.
Jenkins в задача publish-stable по расписанию проверяет в хранилище ветку stable и как обнаруживает обновление запускает сборку, конечный шаг которой публикация артефактов.
Так разработчику даже в Jenkins не надо заходить для публикации сборки, и в логе SVN остается след о публикации сбоки, видно когда была опубликована и кто одобрил ее.

Серьёзно о главном

Разработка Android приложений на Python с KivyMD

Серьёзно о главном

ГОСТ-овский стиль управления. ЭТО РАБОТАЕТ! Разработка ПО.

Статья о том что же такое ТЗ и как оно отличается от полного списка требований. Находим различия.
ТЗ это задание, а не полный список требований.

Разработчикам ПО. ГОСТ 19, ГОСТ 34.

http://gaperton.livejournal.com/49867.html
Серьёзно о главном

Ушел с Python на NodeJS

Продолжение истории "Почему я перехожу с Python на NodeJS" ("Why I’m switching from Python to Node.js").
Почему после года переключение завершилось возвратом на Python.

Это я тоже думал, на чем лучше проект писать, как раз выбор был между двумя ими.

NodeJS использую иногда - хорош для небольших задач, он мне этим нравится.
Серьёзно о главном

Jenkins Pipeline: parallel создает новый workspace для того же узла

Решил запараллелить задачи одной из сборок. Наступил на грабли. Использовал node внутри parallel и оказалось задача в параллельном выполнении создает себе новый worksapce даже, если это тот же node.
Естественно уже нельзя работать при этом с файлами полученными в другом workspace, что я и делал.

Решение
1. Не указывать внутри задачи в parallel директиву node, тогда будет собираться на том же что выше по контексту.
2. Использовать stash/unstash
Кот канарский полосатый толстый

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

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

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

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

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

Есть и второй вариант организации хранения документов - это выеделение меток в храналище документации в соответствии с номером релиза. Например, если мы фиксируем релиз в метку 1.1.2 в храналище проекта, то для документации, по готовности, в хранилище документации создаем метку с таким же именем.

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

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