Ответ на вопрос «почему бы и нет» опять-таки лежит в ТК РФ, где есть очень точный перечень причин для увольнения.
На мой взгляд, обсуждаемый пункт при его наличии в договоре уже говорит, что работодатель оставляет место для маневра своей левой пятки и строит отношения работник-руководитель на обмане.
Прикольная индульгенция для работодателей для подсовывания незаконных контрактов.
Собственно вопрос свелся к тому что важнее для каждого: выгода предприятия любой ценой и плевать на общие законы или все же подпись под незаконным контрактом никакой силы не имеет, поскольку контракт силы не имеет в силу своего противорения с законами.
На мой взгляд, если в контракте есть пункт о рабстве или согласии на опыты по превращению в человеческую многоножку, то подпись под ним ничего не значит. Если для кого-то значит, то выгода явно прощает все.
этот пункт договора не имеет законной силы. Думаю, каждый руководитель должен это знать.
Эта информация НЕ относится к перечню того, что указано в ФЗ о коммерческой тайне, кроме того ограничивает работника в законных правах, таких как право на обращение в суд, поскольку при иске о, например, взыскании зарплаты, величину этой самой зарплаты придется огласить третьим лицам, то есть нарушить договор.
Достаточно известный факт с легконаходимой судебной практикой по нему.
Касательно остального, то у такому работодателю просто не надо идти, коль он ставит свое величество выше законов. Тут стоит отсылка к обозначенной в статье книге.
Незнание зарплаты, кроме того, что это нарушение законов нашей страны, которые позволяют делиться этой информацией с кем угодно, делает самое главное — ставит работников в неравные условия с руководством. Руководство знает условия работы работников, а работники не знают всех условий работы.
В итоге получаем такое положение дел: каждый считает, что зарплата более-менее у всех одинаковая, а на деле у Коли, который клево говорит, но фигово работает, зарплата на 40% выше. Руководству же весьма удобно делать любые «непрозрачные» дела, пользуясь разобщенностью сотрудников. Да хоть откровенную дискриминацию по возрасту, полу, происхождению. Все думают, что на одной должности у всех доход более-менее одинаков, хотя на деле у одной категории работников доход может сильно отличаться, просто за «красивые глаза».
На мой взгляд, любые попытки врать про то, что разглашение зарплаты противозаконно — это грязный трюк и работодатель это чувствует, ведь как правило идет не объяснение в стиле «я, ваш руководитель, считаю, что это разобщит нас, как коллектив», а вранье про «разглашать свои зарплаты запрещено договором!».
Если побуждения руководства благородны и продиктованы заботой о коллективе, то зачем использовать подобные хитрые и нечистоплотные трюки?
Гораздо приятнее работать в компаниях, где зарплата формируется прозрачно.
Поясню: грош цена руководству, если оно не в состоянии объяснить, почему Ивана повысили в должности и зарплате, или почему у двух разработчиков зарплаты отличаются на 20%.
Неподдельная радость работать там, где не надо выбирать, с кем «сотрудничать» и где сам понимаешь, что Вася крут и заслуженно получил свою надбавку.
И отвратительно работать там, где руководство боится собственных работников и старается их разобщить.
Обязана продлить — звучит как принуждение к сделке. Довольно несправедливо. По Российским законам такое бы не должно было пройти. И думаю, что это верно — нельзя принуждать к сделкам.
Немного сноровки и выйдет и читать и видео смотреть в общественном транспорте. Я так уж лет 8 живу. И это одна из причин, почему в городе использую только общественный транспорт. С ним бесполезные часы дороги превратились в полезное время.
Но почему же, когда мы видим мастеров других дел, кому уже далеко за 40 или 50 или больше, то никто их умалишенными не называет? Обычно бывает восхищение их навыком, умением, тягой узнавать новое о своем мастерстве и с таким «багажом» опыта. Согласитесь, резчик по дереву в 50 лет не выглядит глупым. Как и сварщик высшего разряда, стеклодув или промышленный дизайнер.
Думаю, что мастерство в том и есть, чтобы расти и совершенствоваться. Без совершенствования работа превращается в ад.
У вас, вероятно, свои мотивы к такому резкому суждению, но поверьте, не у всех так. Моя семья, например, понимает, что постоянное обучение — это часть моей работы и именно это и делает работника со временем мастером своего дела. Жена моя часто спрашивает: «что нового у вас с go?» При том, что она ни разу не программист, а преподаватель языка.
Программирование может стать поперек горла, если «перерасти» его, если уже руки чешутся самому войти в управление, придумать продукт, найти сбыт, наладить предприятие. Это да.
Почему-то народ упорно не разделяет понятия «освоить синтаксис» и «изучить язык». Освоить синтаксис языка и его основы можно за одни выходные — это «да».
Но освоить Golang — это не так просто. Очень и очень часто я вижу код Golang, по которому сразу видно, на чем писал автор раньше: Java, PHP, C#… Попытки впихнуть чужеродные конструкции или абсолютное отсутствие мыслей о работе GC со своим кодом. Как итог получается рабочий и читаемый код на Golang, который жутко противоестественен и чаще всего медленный или опасный. Тут, как правило, и запихивание всего и вся в горутины, и изобилие типа interface, и использование unsave, и конечно же пренебрежение пакетом sync и количеством создаваемых ссылочных типов.
Нередко попадаются в руки «шедевры» на Golang, которые работают со скоростью PHP 5.6, если код переписать в лоб.
Это конечно лично мой опыт, но программисты, которые не допускают классических «гошных» ошибок (отлично перечислены «50 частых ошибок») получаются где-то через полгода, через год получается хороший разработчик на Golang.
На мой взгляд, легкость Golang обманчива. Он прост в основах, но не примитивен. Сделать на нем качественный продукт проще и быстрее, но с этим не справится «мясо».
У Роба Пайка была интересная мысль, что Golang похож на игру Го — простые правила, но в итоге вариаций партий в порядке больше, чем в шахматах, где правила намного сложнее. В Golang простые основы, но без умения программировать, без хорошей алгоритмической базы это не поможет неумелому «программисту».
У Golang хорошее будущее, поскольку он позволяем сместить акцент с освоение конкретного языка программирование, на изучение программирования в более общем смысле. Я не много времени трачу на сам кодинг, но продумывание api, архитектуры приложения и его алгоритмов — это тратит столько же времени, сколько и всегда. Программирование не становится примитивным от того, что язык программирования прост в своих основах.
Изначальное утверждение "Select может ждать на любом количестве каналов, не будет жрать процессор или требовать использовать костыли в виде Sleep или условных переменных."
Select НЕ ЖРЕТ процессор. Собственно это и показано в более корректном примере. Select отдельно, вычисления отдельно.
Ваш пример был или "не о том" или неверен, в том смысле, что он не опровергает утверждения о том, что select способен ждать любого количества каналов, не выжирая процессор и без sleep.
Но в GO мне не нужно вызывать Goshed, я не думаю о том, что сейчас делает планировщик, в каком из тредов будет исполнена моя горутина, будет ли она "украдена" другим тредом или нет.
Я думаю о том, какая часть кода когда должна отрабатывать, оставляя реализацию "под капотом" GO. Это принципиальное отличие. (пример, как по-другому делается приведенный вами код — ниже в комментарии).
Пример не совсем корректный. Вот так было бы лучше https://play.golang.org/p/rX7SbuOAKP
Одна горутина, один канал, один таймер. Select не нужно делать в бесконечном цикле.
Вы привели пример не ожидания нескольких каналов, в вычисления в бесконечном цикле, внутри которого есть каналы. Вычисление с циклом выносится в отдельную горутину и остается чистый select, который умеет ждать любое количество каналов.
Однако не 'в ручную'. В Go у тебя есть планировщик и правила переключения и вытеснения.
Вопрос про количество ошибок и времени вхождения остается открытым.
Вы сужаете 'эквивалентность' тут. Гошка дает управление конкурирующими горутинами и позаботится о переключении выполняющейся сейчас задачи. Программист может это сделать и в ручном режиме, но нет надобности: я знаю, что при отправке значения в канал, io операции, системном вызове или GC, планировщик позаботится о том, какую горутину выполнять следующей.
Получается, что в D управление конкурентностью 'ручное' и несколько менее изящное. Первое должно увеличивать число ошибок программистов на D при написании конкурентностью о кода.
Возможный в целом подход, но на мой взгляд более рискованный и в коде не смотрится естественно.
Полностью согласен. В примере надо было использовать композицию — единственно верная абстракция тут.
И наверное стоит использовать RWMutex. Непонятно мне лично зачем в примере статьи блокировка при получении значения. Вернее, зачем тут единая блокировка с изменением значения. Мы ж должны иметь возможность читать значение в любое число конкурентных горутин, если не происходит изменение значения.
На мой взгляд, обсуждаемый пункт при его наличии в договоре уже говорит, что работодатель оставляет место для маневра своей левой пятки и строит отношения работник-руководитель на обмане.
Собственно вопрос свелся к тому что важнее для каждого: выгода предприятия любой ценой и плевать на общие законы или все же подпись под незаконным контрактом никакой силы не имеет, поскольку контракт силы не имеет в силу своего противорения с законами.
На мой взгляд, если в контракте есть пункт о рабстве или согласии на опыты по превращению в человеческую многоножку, то подпись под ним ничего не значит. Если для кого-то значит, то выгода явно прощает все.
Эта информация НЕ относится к перечню того, что указано в ФЗ о коммерческой тайне, кроме того ограничивает работника в законных правах, таких как право на обращение в суд, поскольку при иске о, например, взыскании зарплаты, величину этой самой зарплаты придется огласить третьим лицам, то есть нарушить договор.
Достаточно известный факт с легконаходимой судебной практикой по нему.
Касательно остального, то у такому работодателю просто не надо идти, коль он ставит свое величество выше законов. Тут стоит отсылка к обозначенной в статье книге.
В итоге получаем такое положение дел: каждый считает, что зарплата более-менее у всех одинаковая, а на деле у Коли, который клево говорит, но фигово работает, зарплата на 40% выше. Руководству же весьма удобно делать любые «непрозрачные» дела, пользуясь разобщенностью сотрудников. Да хоть откровенную дискриминацию по возрасту, полу, происхождению. Все думают, что на одной должности у всех доход более-менее одинаков, хотя на деле у одной категории работников доход может сильно отличаться, просто за «красивые глаза».
На мой взгляд, любые попытки врать про то, что разглашение зарплаты противозаконно — это грязный трюк и работодатель это чувствует, ведь как правило идет не объяснение в стиле «я, ваш руководитель, считаю, что это разобщит нас, как коллектив», а вранье про «разглашать свои зарплаты запрещено договором!».
Если побуждения руководства благородны и продиктованы заботой о коллективе, то зачем использовать подобные хитрые и нечистоплотные трюки?
Поясню: грош цена руководству, если оно не в состоянии объяснить, почему Ивана повысили в должности и зарплате, или почему у двух разработчиков зарплаты отличаются на 20%.
Неподдельная радость работать там, где не надо выбирать, с кем «сотрудничать» и где сам понимаешь, что Вася крут и заслуженно получил свою надбавку.
И отвратительно работать там, где руководство боится собственных работников и старается их разобщить.
Думаю, что мастерство в том и есть, чтобы расти и совершенствоваться. Без совершенствования работа превращается в ад.
У вас, вероятно, свои мотивы к такому резкому суждению, но поверьте, не у всех так. Моя семья, например, понимает, что постоянное обучение — это часть моей работы и именно это и делает работника со временем мастером своего дела. Жена моя часто спрашивает: «что нового у вас с go?» При том, что она ни разу не программист, а преподаватель языка.
Программирование может стать поперек горла, если «перерасти» его, если уже руки чешутся самому войти в управление, придумать продукт, найти сбыт, наладить предприятие. Это да.
Но освоить Golang — это не так просто. Очень и очень часто я вижу код Golang, по которому сразу видно, на чем писал автор раньше: Java, PHP, C#… Попытки впихнуть чужеродные конструкции или абсолютное отсутствие мыслей о работе GC со своим кодом. Как итог получается рабочий и читаемый код на Golang, который жутко противоестественен и чаще всего медленный или опасный. Тут, как правило, и запихивание всего и вся в горутины, и изобилие типа interface, и использование unsave, и конечно же пренебрежение пакетом sync и количеством создаваемых ссылочных типов.
Нередко попадаются в руки «шедевры» на Golang, которые работают со скоростью PHP 5.6, если код переписать в лоб.
Это конечно лично мой опыт, но программисты, которые не допускают классических «гошных» ошибок (отлично перечислены «50 частых ошибок») получаются где-то через полгода, через год получается хороший разработчик на Golang.
На мой взгляд, легкость Golang обманчива. Он прост в основах, но не примитивен. Сделать на нем качественный продукт проще и быстрее, но с этим не справится «мясо».
У Роба Пайка была интересная мысль, что Golang похож на игру Го — простые правила, но в итоге вариаций партий в порядке больше, чем в шахматах, где правила намного сложнее. В Golang простые основы, но без умения программировать, без хорошей алгоритмической базы это не поможет неумелому «программисту».
У Golang хорошее будущее, поскольку он позволяем сместить акцент с освоение конкретного языка программирование, на изучение программирования в более общем смысле. Я не много времени трачу на сам кодинг, но продумывание api, архитектуры приложения и его алгоритмов — это тратит столько же времени, сколько и всегда. Программирование не становится примитивным от того, что язык программирования прост в своих основах.
Можно примеры из мира разработки на GO?
И видится мне мало сравнимы.
Select НЕ ЖРЕТ процессор. Собственно это и показано в более корректном примере. Select отдельно, вычисления отдельно.
Ваш пример был или "не о том" или неверен, в том смысле, что он не опровергает утверждения о том, что select способен ждать любого количества каналов, не выжирая процессор и без sleep.
Я думаю о том, какая часть кода когда должна отрабатывать, оставляя реализацию "под капотом" GO. Это принципиальное отличие. (пример, как по-другому делается приведенный вами код — ниже в комментарии).
Одна горутина, один канал, один таймер. Select не нужно делать в бесконечном цикле.
Вы привели пример не ожидания нескольких каналов, в вычисления в бесконечном цикле, внутри которого есть каналы. Вычисление с циклом выносится в отдельную горутину и остается чистый select, который умеет ждать любое количество каналов.
Вопрос про количество ошибок и времени вхождения остается открытым.
Получается, что в D управление конкурентностью 'ручное' и несколько менее изящное. Первое должно увеличивать число ошибок программистов на D при написании конкурентностью о кода.
Возможный в целом подход, но на мой взгляд более рискованный и в коде не смотрится естественно.
И наверное стоит использовать RWMutex. Непонятно мне лично зачем в примере статьи блокировка при получении значения. Вернее, зачем тут единая блокировка с изменением значения. Мы ж должны иметь возможность читать значение в любое число конкурентных горутин, если не происходит изменение значения.