Оценка результата программиста

Типовая ситуация

Требуется выполнить определенную работу. Есть "специально обученные" люди для её выполнения, которые собственно и отвечают за это.

Естественно работу отдаем им, так как никто не хочет брать лишнюю работу. Работу берет человек и выполняет её за N часов.

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

Возникает резонный вопрос: почему на выходе "одинаковых в профессиональной оценке" людей разный результат?

Что-то не то с оценкой результата и мотивацией в организации.


Я считаю что программист должен оставаться программистом, и делать качественно даже ту работу, которую он никогда не делал.

Яндекс Деньги. Привязка карты. А нужна ли?

Решил тут привязать к Яндекс Деньгам карту, чтобы использовать Яндекс Карту как транзитную, оказывается это нерабочий кейс.

Вот ответ поддержки:

>>>

Если к Вашему счёту привязана карта другого банка, то Вы можете оплатить что-нибудь в интернете через Яндекс.Деньги с баланса этой карты. При этом баланс карты и кошелька не объединяется, просто при каждом платеже (только когда Вы выбираете оплату с карты и вводите CVV-код) деньги списываются именно с карты, привязанной к счету.

Пополнить кошелек с карты можно тут: https://money.yandex.ru/topup/card/carddetails.xml
По этой ссылке можно перевести деньги с кошелька на карту: https://money.yandex.ru/direct-payment.xml?form-state=to-card

При оплате картой Яндекс.Деньги, средства должны быть на балансе Яндекс.Кошелька.

>>>

То есть нельзя оплачивать покупки Яндекс Картой с автосписанием средств с привязанной.

Смысл ясен. Плюсы Яндекс карты стали еще более неочевидны.

Zimbra и Ubuntu 16.04

Насколько известно все переходят на SystemD систему инициализации.

В принципе это правильно, но при обновлении Zimbra и Ubuntu 14.04->16.04 столкнулся с тем что старый upstart конфиг от Zimbra нормально не встает.

Пришлось переписать на SystemD сервис.

Проблема выложенного  на github в том, что не стартует сервис logger.

Проблема изза того, что при старте генерится perl класс, который использует внутренние пакеты Zimbra, на которые в переменных нет ссылки.

Решается это подгрузкой переменных среды.

Короче выкладываю рабочий результат. Пользуйте.

[Unit]

Description=Zimbra Collaboration Suite

After=network.target remote-fs.target time-sync.target syslog.target

Conflicts=sendmail.service exim.service postfix.service

[Service]

Type=forking

User=zimbra

Group=zimbra

ExecStart=/bin/bash -c ". /opt/zimbra/.bashrc && /opt/zimbra/bin/zmcontrol start"

ExecStop=/bin/bash -c ". /opt/zimbra/.bashrc && /opt/zimbra/bin/zmcontrol stop"

ExecReload=/bin/bash -c ". /opt/zimbra/.bashrc && /opt/zimbra/bin/zmcontrol restart"

TimeoutSec=500

[Install]

WantedBy=multi-user.target

Такие программисты

Не выдержал... Как же меня бомбит от таких постов на нормальном ресурсе Habrahabr.

Начну пожалуй 

1. "Проблема — «непоследовательное» наследование" - это не проблема. Проблема в коде, который просто недостоин существования в 2017 году. Научитесь писать модульно и вы забудете об этом навсегда.

   "При настройках студии "по умолчанию" важен порядок подключения зависимых скриптов" - не умеете готовить не пользуйтесь.

   Если для сборки проекта используете средство интегрируемое, через костыль (а плагин - это костыль), то как бы может быть разобраться как средство работает в своей среде и насколько ему начхать на ваши Solution и Project в терминах Visual Studio.

   Используйте хотя бы paths в tsconfig.json для маппинга проектов.

2. "Проблема — глобальные переменные" - проблема в руках. Никто в 2017 году не использует глобальные переменные. А если ваш проект экспортирует, то это не должно быть проблемой.

3. "Обратите внимание на длинные относительные пути. Они тут нарочно, чтобы показать, что такое случается" - случается, если используешь не модульную систему. И более скажу, использование регистрозависимых путей может привести к веселым последствиям )) особенно когда будешь собирать под другой системой )

4. "Переписать весь наш код на использование импортов за один подход не представляется возможным. " - сколько не оттягивай процесс, все равно вернешься.

5. Интегрирование чего то куда то ради интегрирования это бред.