кстати, исходники git-flow это изумительный пример кодинга на #!/bin/sh. для меня было открытием, что синтаксис sh позволяет писать достаточно сложные вещи весьма абстрактно и чисто — без многоуровневых вложенностей и обилия «закорючек», что свойственно многим системным скриптам.
Хочу вынести на суд широкой общественности идею системы премирования (мотивации) сотрудников.
Метафизика идеи заключается в привнесении рыночных отношений в производственные процессы.
По легенде, эта идея впервые была предложена в 1982 году Советским
имхо, вброс это.
сходил по ссылке из статьи:
В случае с Калининской АЭС то был просто большой лист ватмана, а не громадный жидкокристаллический дисплей.
если учесть, что трудилось там больше тысяч человек, то лист ватмана где, по легенде, отмечалось всё, что кто кому чего полезного сделал за неделю, должен был быть ну ооочень большим. и не репрезентативным, наверно, нифига. сколько ресурсов должно было тратится на поддержание такой «системы»?
Сразу же почувствовалась совершенно иная организация работ на стройке. Проводятся ежедневные штабы, разрабатываются недельно-суточные графики производства работ на основе общего графика. Установлен жесточайший контроль за выполнением графиков. Во всем этом чувствовались огромный талант и организаторские способности начальника УС КАЭС В. А. Саакяна. Резко увеличивается численность работающих. Были построены три военных городка, где разместили три стройбата. Приспособили базу УС КАЭС под зону для осужденных по неосторожности.
По изоляции мне нравятся больше интеграционные тесты, по тестируемому объекту — функциональные. У таких тестов очень большое покрытие кода, это и плюс и минус одновременно… они достаточно быстро проходят (3-4 минуты ~250 тестов)
как будто про нас. :) тоже с этого начинали. и щастье при первом рефакторинге. и разочарование, когда более-менее освоили метод, а количество тестов перевалило за сотню — запуск занимает какое-то неразумное время, при этом видно невооруженным глазом, что получаемая польза не оправдывает вложения.
чем крупнее кусок системы, охватываемый тестом, тем больше у него параметров состояния и тем меньше шансов проверить, пускай даже лишь существенные, их комбинации, ничего не упустив. при этом, чем больше глубина куска (по задействованным уровням системы), тем менее очевидны связи между этими параметрами, с точки зрения внешнего наблюдателя, коим является тест.
мне кажется, что «большое покрытие кода» интеграционными тестами — иллюзия. как раз о коде они дают лишь крайне поверхностное, оценочное представление. по сто раз дергают одни и те же куски, пропуская значимые граничные аспекты. отсюда эффективность. данный вид тестов хоть и хорош в начале, но в качестве основного средства tdd-разработки не особо практичен. вроде как хождение на четвереньках.
в то время (2007) рендер freetype оставлял желать лучшего. но эти проблемы как раз относились к низким, монтиорным, dpi. на высоких dpi пляски с antialiasing и cleartype не нужны. а на печати всё было достойно. не в последнюю очередь потому, что система рендера X всю свою сознательную жизнь ориентировалась на dpi (истоки которой можете поискать в 80x по словам «PostScript» и «Apple»), и только сейчас впала в маразм.
По мне, так уже сама абстракция над if-else кажется избыточной:
def wrapper(request, *args, **kwargs):
if not condition_func(request, *args, **kwargs):
return false_func(request, *args, **kwargs)
return view(request, *args, **kwargs)
Если много потрудится, то в пределе всю логику можно выразить в виде функций и их применения, только зачем? Ведь процедурный подход в python прекрасен.
Кстати, в django присутствует схожий по смыслу механизм — стек middleware. Поэтому, в качестве альтернативы пляскам вокруг декораторов, было бы любопытно посмотреть в сторону адаптации его механизмов, под нужны отдельных view.
при указании в win, dpi, отличного от дефолтного, во многих приложениях получал странный эффект — как будто окно отрисовывается в 96dpi, а затем масштабируется с указанным коэффициентом. по сравнению с этой живописью даже jpeg отдыхает. так что не надо нам таких коэффициентов.
я не понимаю, как это случилось. для xft и gnome2 размеры всю жизнь указывались именно в dpi, а cairo, которая используется основными gtk2 движками, чудесно подцепляла эти настройки. что ещё нужно? я не припомню, чтобы у приложений были проблемы с большими dpi. наоборот, лишь при dpi выше 100 всё начинало выглядеть достойно. проблемы были с маленькими dpi — кажется, 72dpi на старых элт-мониторах, — но это другая тема.
в gtk3 откуда-то вплыли коэффициенты масштабирования с базой 96dpi, единицы измерения типа «1024 * dots/inch» и прочий бред. совершенно непонятно, что они там курили. но сейчас убунта на высоких dpi в самом деле представляет собой полный шг. и ппц (подозреваю, что ноги сего технического чуда, растут откуда-то из недр движков css и javascript, которые позаимствованы gnome3 известно откуда).
Другую знакомую уволили в результате по статье «пьянство», хотя она вообще не пьет. Ей нельзя по здоровью. Но нашлась куча свидетелей, что она «неоднократно приходила на работу в хлам», а так же «постоянно упортебляла на работе».
… подавляющее большинство новых работодателей, звонит предыдущим, для проверки. Ну а там могут рассказать все что угодно. И думаю ЗП за 3 месяца покажутся полной фигней после 6-8 месяцев безуспешных попыток устроится на работу.
ну вот кошмарить то зачем? как раз это просто доказывается. сила в правде. нужно иметь лишь каплю упорства и при таком раскладе «предыдущие» будут хлебать баланду. хеппиенд. :)
серьёзно, во время недавнего кризиса ходили подобные байки. но как показала практика, та же куча свидетелей, предупрежденных об ответственности за дачу ложных показаний, с не меньшим усердием начинает свидетельствовать против работодателя. это ж не уголовники какие-то и нормально идут на сотрудничество. ведь даже самые упоротые осознают, что точно в таком же положении находится каждый из них.
у моих знакомых прямо обратная ситуация. компания российского масштаба, занимается бурением. сезонные работы, вахтовый метод. и работяг отбирают как космонавтов. не в последнюю очередь потому, что уволить неподходящего сотрудника по нашим законам крайне сложно. даже за пьянку. волокита, и месяцами длящиеся суды, отнимают кучу ресурсов. работяги, в общем-то, так же юридически неграмотны, как и офисные одуванчики. но упорны, и не столь наивны. вероятно потому, что деваться им больше не куда. в прочем, это уже полный офф.
маркет же. такие сервисы не про разработку, а про продажи (речь не обязательно о деньгах). можно предположить, что назначение ленты отзывов (она так называется — не комментов) это собирание казуального фидбека и информирования других пользователей о проблемах в приложении. т.е. подобие «жалобной книги». отсюда её нарочитая односторонность. если комменты разработчиков будут отображаться в общей ленте, то они так же станут формировать настроение потенциальных пользователей, превратив блок, фактически, в рекламную площадку. кроме того — новая фича может стать механизмом для рассылки отозвавшимся таггерированного спама.
зы: знаете, мне определенно нравится ход ваших рассуждений. «для простоты рассмотрим баланс в кассе нашей организации. вот приход, вот расход. не трудно заметить, что ни какой вашей зарплаты здесь нет — присутствует исключительно синтаксический сахар.» :)
нет ни какого строго смысла. конкретные термины отражают конкретные понятия — воспринимаются как есть и употребляются целиком. ну нельзя их делить на слова, дабы извлечь какой-то собственный смысл. иначе можно далеко зайти рассуждая, в строгом смысле, скажем, о морских свинках)
сходил по ссылке из статьи: если учесть, что трудилось там больше тысяч человек, то лист ватмана где, по легенде, отмечалось всё, что кто кому чего полезного сделал за неделю, должен был быть ну ооочень большим. и не репрезентативным, наверно, нифига. сколько ресурсов должно было тратится на поддержание такой «системы»?
офф: вот из другого источника helion-ltd.ru/part-10-kalininskaya-npp/:
может это «матафизика» чудо-мотиватора?)
чем крупнее кусок системы, охватываемый тестом, тем больше у него параметров состояния и тем меньше шансов проверить, пускай даже лишь существенные, их комбинации, ничего не упустив. при этом, чем больше глубина куска (по задействованным уровням системы), тем менее очевидны связи между этими параметрами, с точки зрения внешнего наблюдателя, коим является тест.
мне кажется, что «большое покрытие кода» интеграционными тестами — иллюзия. как раз о коде они дают лишь крайне поверхностное, оценочное представление. по сто раз дергают одни и те же куски, пропуская значимые граничные аспекты. отсюда эффективность. данный вид тестов хоть и хорош в начале, но в качестве основного средства tdd-разработки не особо практичен. вроде как хождение на четвереньках.
Если много потрудится, то в пределе всю логику можно выразить в виде функций и их применения, только зачем? Ведь процедурный подход в python прекрасен.
Кстати, в django присутствует схожий по смыслу механизм — стек middleware. Поэтому, в качестве альтернативы пляскам вокруг декораторов, было бы любопытно посмотреть в сторону адаптации его механизмов, под нужны отдельных view.
в gtk3 откуда-то вплыли коэффициенты масштабирования с базой 96dpi, единицы измерения типа «1024 * dots/inch» и прочий бред. совершенно непонятно, что они там курили. но сейчас убунта на высоких dpi в самом деле представляет собой полный шг. и ппц (подозреваю, что ноги сего технического чуда, растут откуда-то из недр движков css и javascript, которые позаимствованы gnome3 известно откуда).
ну вот кошмарить то зачем? как раз это просто доказывается. сила в правде. нужно иметь лишь каплю упорства и при таком раскладе «предыдущие» будут хлебать баланду. хеппиенд. :)
серьёзно, во время недавнего кризиса ходили подобные байки. но как показала практика, та же куча свидетелей, предупрежденных об ответственности за дачу ложных показаний, с не меньшим усердием начинает свидетельствовать против работодателя. это ж не уголовники какие-то и нормально идут на сотрудничество. ведь даже самые упоротые осознают, что точно в таком же положении находится каждый из них.
у моих знакомых прямо обратная ситуация. компания российского масштаба, занимается бурением. сезонные работы, вахтовый метод. и работяг отбирают как космонавтов. не в последнюю очередь потому, что уволить неподходящего сотрудника по нашим законам крайне сложно. даже за пьянку. волокита, и месяцами длящиеся суды, отнимают кучу ресурсов. работяги, в общем-то, так же юридически неграмотны, как и офисные одуванчики. но упорны, и не столь наивны. вероятно потому, что деваться им больше не куда. в прочем, это уже полный офф.
(2, 1, 1) = {{1}, {1, 1}, {2, 1, 1}} = {{1}, {1, 1}, {2, 1}} = {{1}, {2, 1}}
(1, 2, 1) == (2, 1, 1)
в чем подвох?)
зы: знаете, мне определенно нравится ход ваших рассуждений. «для простоты рассмотрим баланс в кассе нашей организации. вот приход, вот расход. не трудно заметить, что ни какой вашей зарплаты здесь нет — присутствует исключительно синтаксический сахар.» :)