Не вчитывался в подробности, потому что из заголовка ясно, что это правильный тезис.
У бизнеса есть желание быть уверенным в качестве ПО и ресурс. Если у бизнеса есть ресурс, то он может его потратить на повышение качества. Некоторые в бизнесе считают что юнит-тесты повышают качество. Главный вопрос настолько же повышается качество насколько затрачивается ресурс? Очевидно, что достичь 100% качества с помощью юнитов навозможно, но потратить 100% ресурсов да. Еще один отрицательный эффект в том, что чем больше тестов, тем меньше прирост качества. Внимательному менеджеру часто заметно, что тесты — отличная возможность разработчику перевести срывы сроков, размазав их на тестирование, поскольку часто оно больше времени зафакапленной разработки. Притом логически не верно поручать делать тесты тому кто мог породить ошибки, тем более что разработчики чуть ли не самый дорогой ресурс проекта. Есть и такой эффект, который инкриминируют гомеопатии, что при использовании вероятностной методики могла быть фатально не оказана своевременная помощь, также и зеленые лампочки на CI имеют успокоительный эффект, который может убаюкать перед запуском некачественного релиза. В итоге юнит-тестирование — онанизм перфекционистов, просто религия невникающих в общий смысл проекта как достижение не просто качества, а недорого и в сроки.
Надо только вместо последней инвалидной 5-дневки сделать полную 6-дневную неделю, тогда вообще все будет красиво. Считаем последнюю неделю влиянием злого духа Аримана испортившего совершенный год. За это каждый год будет набегать 3/4 дня и через 8 лет год нарастит неделю долга и в такой 8-ой раз год станет «совершенным», без последней недели, просто идеальным, в 360 дней. При этом вносить какую то нелепицу в жизнь надо будет реже, т.е. 1 раз в 8 лет, а не раз в 4 года. Кстати такая траурная неделя Аримана есть у зороастрийцев, только они не догадались, что 7-дневная неделя тоже кажется его происки.
Я так понимаю, что таски менеджить все равно должен в итоге ПМ. А если это все равно делает ПМ, то почему не taskjuggler+emacs+orgmode или MS Project? Я вот в Redmine так и не смог понять как сводить план, возможно это возможно, но в любом случае точно сложнее чем в той же оргмоде.
А почему не CouchDB? Скорость?
Мне кажется с каучуком по-удобнее — готовый rest-сервис и прозрачность работы из JS кода с клиента… Плюс есть подозрение что при больших базах каучук будет много надежнее.
Кажется в smtp не хватает такой довольно часто употребляемой штуки документооборота как удаление отправленного документа отправляющей стороной, в случае, если он еще не открыт/прочитан получающей стороной. Но реализация такого протокола ужесточит конечно и маршрутизацию письма. А еще правильнее конечно высылку конфиденциальной информации активировать запросом получателя, который будет на самом деле высылкой некоего контейнера открытого ключа куда отправитель и положит свое письмо. Во-первых прочтет только получатель, во-вторых не надо набирать адрес, в третьих быстро проверить такого получателя через свои базы ключей или какие то общедоступные. В общем в любом случае проблема регламента и порядка работы с клиентами. Видимо такой механизм должен быть как то принят законодательно, чтобы процесс был стандартный и тогда бы суд разбирался не с деталями реализации происшедшего, а законность отправки конфданных вообще как то иначе нежели по стандарту.
Да все проще. Есть среднерыночные расценки по каждой должности для данного региона. На собеседование солидные люди уже представляют, что они предлагают, а другие солидные — что соискают.
«Схемы формирования зарплаты» — придуманный способ обмана, все равно в долгосрочной перспективе отдача от человека величина постоянная.
Ну и сны…
«Если человек приходит и говорит «я написал mail.ru» (и доказывает это) — строки мы разворачивать не будем.»
Можно в цитатник.
А на самом деле прекрасные люди студенты изучившие джумлу, если они там реально разобрались с этим фаршем, то какой же у них потенциал!
Думаю, что было бы правильно не думать о деньгах при таких вопросах.
А, если рассматривать именно меня, то я вообще не думаю о деньгах при любых вопросах.
Кстати вот вам вопрос: вы считаете правильным пропорциональность зарплаты сотрудника и его знания/навыки?
Поиграем с вами в ребусы. Если ответите правильно, то думаю вам и так ясно, почему меня не заботит вопрос денег.
Лучшие люди скромные и застенчивые. Им меряться остотой ума и изящностью выражений не по природе. Тем более в такой загадочной области как ИТ, где требуется обстоятельность и вдумчивость, ни к чему этот эрудизм и стрессоустойчивость. Все эти барижьи стандарты принесли многочисленные манагеры толпами повалившие в ИТ, как только здесь появилось, чем легко поживиться. И отбирают к разделу бюжетов таких же как сами. По факту нормальному коллективу нужны пусть медлительные и ронимые, да обстоятельные и честные, ибо для результата реального, а не очередного распила с закрытием липовыми актами, и процесса не на один проект, так выходит лучше.
делайте контракты в коде, заметите раньше CI
Не вчитывался в подробности, потому что из заголовка ясно, что это правильный тезис.
У бизнеса есть желание быть уверенным в качестве ПО и ресурс. Если у бизнеса есть ресурс, то он может его потратить на повышение качества. Некоторые в бизнесе считают что юнит-тесты повышают качество. Главный вопрос настолько же повышается качество насколько затрачивается ресурс? Очевидно, что достичь 100% качества с помощью юнитов навозможно, но потратить 100% ресурсов да. Еще один отрицательный эффект в том, что чем больше тестов, тем меньше прирост качества. Внимательному менеджеру часто заметно, что тесты — отличная возможность разработчику перевести срывы сроков, размазав их на тестирование, поскольку часто оно больше времени зафакапленной разработки. Притом логически не верно поручать делать тесты тому кто мог породить ошибки, тем более что разработчики чуть ли не самый дорогой ресурс проекта. Есть и такой эффект, который инкриминируют гомеопатии, что при использовании вероятностной методики могла быть фатально не оказана своевременная помощь, также и зеленые лампочки на CI имеют успокоительный эффект, который может убаюкать перед запуском некачественного релиза. В итоге юнит-тестирование — онанизм перфекционистов, просто религия невникающих в общий смысл проекта как достижение не просто качества, а недорого и в сроки.
Мне кажется с каучуком по-удобнее — готовый rest-сервис и прозрачность работы из JS кода с клиента… Плюс есть подозрение что при больших базах каучук будет много надежнее.
Для Default таргета такой порядок:
Значит для Handler: Redirection
Rule list:
Internal ^/$ /index.php
Internal ^/(.+)$ /index.php?$1
Первое правило для корня сайта. Если кто то знает изящнее, пишите.
Не забудьте в хендлере для php в Common CGI options включить Error handler, чтобы шла страничка ошибок из CI.
Итог: забавный сервер, понравился.
«Схемы формирования зарплаты» — придуманный способ обмана, все равно в долгосрочной перспективе отдача от человека величина постоянная.
«Если человек приходит и говорит «я написал mail.ru» (и доказывает это) — строки мы разворачивать не будем.»
Можно в цитатник.
А на самом деле прекрасные люди студенты изучившие джумлу, если они там реально разобрались с этим фаршем, то какой же у них потенциал!
А, если рассматривать именно меня, то я вообще не думаю о деньгах при любых вопросах.
Кстати вот вам вопрос: вы считаете правильным пропорциональность зарплаты сотрудника и его знания/навыки?
Поиграем с вами в ребусы. Если ответите правильно, то думаю вам и так ясно, почему меня не заботит вопрос денег.