У меня просто сложилось ощущение, что крупные корпорации вроде Гугла достаточно активно проводят тренинги по эйджизму тоже. И кажется, что эта тема тоже набирает обороты. Тут ведь термин «меньшинство» очень широкий, может быть расовое, а может и возрастное.
Немного добавлю из опыта работы с внешними рекрутерами, они часто обслуживают запросы своего начальства «заработать много денег» в большей мере, чем запросы меня, как работодателя. Им выгодно продать мне кандидата, который меньше знает (проще найти), но больше просит (выше комиссия). Некоторые заходят в этом очень далеко. Без претензий к конкретным рекрутерам, у них такая работа и такие KPI.
Именно об этом и речь в статье. Дискриминируют все, независимо от пола и рассы и, как правило, неосознанно. Полезно об это знать, чтобы иметь правильную картину мира, и, если нужно, корректировать процессы в компании.
А вы не думали, что нам насаждают это… А что, если женщин меньше в ИТ потому, что они просто не хотят в ИТ идти? И статистика просто подтверждает это?
Статистика из исследований выше говорит, что женщин в IT меньше, чем женщин желающих и могущих работать в IT. И из этого уже возникает вопрос «почему так?»
Но ведь это приведет к тому, что брать будут кого угодно, лишь бы был этот процент.
Когда проблему решают так в лоб, это становится еще одной проблемой, согласен. Тут статистика полезна, чтобы понять, нормально ли работает найм в компании: если вдруг выяснится, что без прочтения в топку отправляются 15% резюме, это означает, что рекрутер неэффективно тратит деньги компании.
По своему опыту скажу… но только по той причине, что они отсутствовали по 3-6 лет на работе
Это интересный опыт! У меня на работе, по данным примерно сотни человек, девушки даже до декрета в среднем просили и получали меньше при равных прочих данных. Было бы очень интересно собрать похожую информацию по российскому IT.
ИМХО, это не главная идея статьи, главное — обширная статистика о подсознательной предвзятости и стереотипах, там как раз с фактами и исследованиями, а нежелание говорить плохо, про конкретных людей (кто ей сделал плохо и что?) я могу понять. Если не осилили все, рекомендую бегло прочитать подборку исследований в середине статьи.
When-оператор в общем виде он не предполагает строгой проверки на этапе сборки, даже в случае с перечислениями. Например такой вариант абсолютно корректен синтаксически
var someEnumValue = SomeEnum.VALUE;
when (someEnumValue) {
in SomeEnum.values() -> doAction()
someFunctionThatReturnsEnum() -> doAnotherAction()
}
Более того, он останется корректным, даже если убрать первое условие и оставить только вызов функции someFunctionThatReturnsEnum. Справедливости ради стоит отметить, что Котлин в таких случаях все-таки вежливо попросит сделать явное перечисление, но если мы не сделаем этого, или перечислим не все варианты, код останется корректным. Полнота проверяется компилятором, если when используется как выражение, а не как оператор, но тогда в нашем примере мы получим ложную ошибку и просьбу добавить else ветку, потому что компилятору «не известно» что SomeEnum.values() уже является полным вариантом.
Собственно, исходный посыл и был в том, что так писать не надо :)
Она не хороша и не плоха, она другая, более гибкая, позволяет сделать больше, но и позволяет сильнее ошибиться тоже. С ней больше не возможна простая строгая проверка на полноту как в случае с switch/case + enum, и кому-то это важнее. Остальное вопрос вкуса, на мой вкус — конструкция удобная.
Из практических применений делегатов нам больше всего понравился lazy (по правде говоря на него и приходится 99%), но он и правда очень удобен для вьюх, когда надо проинициализировать какой-то объект, зависящий от контекста, и при этом инициализация тривиальна, и захломлять ею onCreate/onCreateView не хочется. Например так
val radioButtons: List<RadioButton> by lazy { some_radio_group.getButtonsList() }
some_radio_group — это прямая «ссылка» на вьюху через Kotlin-X, но она нам не нужна, а нужно только ее содержимое. Аналогично инициализируем все объекты строк, анимаций и т.п, если они переиспользуются в активити/фрагменте несколько раз.
С проблемой отсутствия консистентности на стыке с нативным кодом очень согласен, досаждает регулярно, и получается не так красиво, как должно быть.
По традиции соглашусь с первым и поспорю со вторым :)
Рынок труда устроен именно так, к счастью или к сожалению, и умеение держать баланс — это сугубо личное. Мое мнение — пять но плохо, хуже чем один но хорошо, но один досконально, хуже, чем два хорошо. В нашем случае эксперимент показал, что Котлин к продакшену готов, поэтому все новые модули мы теперь пишем на нем, так метаний между языками становится меньше, а знания платформы с любым языком в нашем случае остаются одинаковыми, что Котлин, что Джава живут поверх одной JVM и одного Андроида.
Никто не мешает, но идти против приниципов принятых платформой (язком, фреймворком, операционной системой — не важно) обычно не просто не так удобно, но еще и не так продуктивно, особенно если разработка идет в команде. Поэтому да, каждый отвечает сам за свои действия, но влияние среды все-таки надо учитывать, и менять среду, если есть такая возможность.
Удивитесь, но фанат я довольно сдержанный. Я думаю, вопрос тут в том, команда ли принимает решение, или отдельный человек. Когда «новые» технологии насаждает начальник или просто один ретивый участник наперекор остальным, обычно бывает плохо, но я ни разу не работал в команде, которая была не рада получить более удобный инструмент после совместного обсуждения. Когда-то давно мы переезжали с WinForms на WPF для Windows разработки всем отделом, после той истории мне написал сотрудник другого департамента, и пожаловался, что у них одно старье, и что он не знал, что в компании так можно.
Именно! Но приходится в итоге рассказыать отдельно, что во-первых «старый» понятный стиль, не отменяли, а во-вторых в ФП вообще-то не должно быть сайд-эффектов вообще.
Согласен, плохо выразился. Имел ввиду, никаких новых инструментов или библиотек для упрощения написания имеющихся unit/unstrumented-unit тестов. Под Спек пришлось бы заново переписать значительно.
В качестве примера у нас был кусок кода, где товарищ решил использовать фунциональные конструкции как замену if/else просто потому, что они теперь есть, и он был уверен, что для Котлина не рекомендуется пользоваться «устаревшими» способами управления потоком исполнения. Ну и новый мощный аналог switch/case часто эксплуатировали. У JetBrains в документации четвертый пример не очень красивый, он явно сделан для демонстрации того, что может синтаксис, но кто-то принял это зай гайд и получились примерно такие контрукции.
when (x) {
-1 -> ...//some fallback here
validate(x) -> print("ok")
anotherOptionToValidate(x) -> ...//some action again
else -> processSomeError(x)
}
такой вариант читаемости уже не добавляет, и нужно держать в уме, что код выполняется не только по правую сторону от стрелок, но и по левую, когда функции validate и anotherOptionToValidate содержат сайд эффекты получается просто ужасно.
А Сucumber уперся во что-то специфическое, не в закрытость классов для расширения?
Чтобы решить проблему с тем, что Mockito не работает с такими классами, есть обходной пусть: можно создать конфиг файл, который сделает все котлин-классы открытыми для мокито, но только для тестов.
Нет желания напихать побольше, есть желание получить доступ к технологии, которая потенциально станет основой Андроид разработки в самое ближайшее время, как и желание освоить новый язык и сделать код на проекте чище и лаконичнее. Когда менеджмент разрешает программистам выбирать технологии, это всегда положительно сказывается на командном духе, обратное тоже верно, команда, застрявшая на старых технологиях, начинает терять мотивацию.
Соглашусь с первым утверждением, а со вторым не очень. Для людей, которые пишут проект второй-третий год подряд на Java 7, возможность выйти из зоны комфорта, выучить новый язык, получить доступ к нормальным удобным конструкциям из мира функуционального программирования, это не просто прихоть, это — возможность вложить силы и время в саморазвитие. Не у всех есть возможность регулярно после работы по вечерам осваивать новые технологии. А так уже завтра на рынке труда они будут чуть-чуть более востребованы как специалисты.
У меня просто сложилось ощущение, что крупные корпорации вроде Гугла достаточно активно проводят тренинги по эйджизму тоже. И кажется, что эта тема тоже набирает обороты. Тут ведь термин «меньшинство» очень широкий, может быть расовое, а может и возрастное.
Когда проблему решают так в лоб, это становится еще одной проблемой, согласен. Тут статистика полезна, чтобы понять, нормально ли работает найм в компании: если вдруг выяснится, что без прочтения в топку отправляются 15% резюме, это означает, что рекрутер неэффективно тратит деньги компании.
Это интересный опыт! У меня на работе, по данным примерно сотни человек, девушки даже до декрета в среднем просили и получали меньше при равных прочих данных. Было бы очень интересно собрать похожую информацию по российскому IT.
Более того, он останется корректным, даже если убрать первое условие и оставить только вызов функции someFunctionThatReturnsEnum. Справедливости ради стоит отметить, что Котлин в таких случаях все-таки вежливо попросит сделать явное перечисление, но если мы не сделаем этого, или перечислим не все варианты, код останется корректным. Полнота проверяется компилятором, если when используется как выражение, а не как оператор, но тогда в нашем примере мы получим ложную ошибку и просьбу добавить else ветку, потому что компилятору «не известно» что SomeEnum.values() уже является полным вариантом.
Собственно, исходный посыл и был в том, что так писать не надо :)
some_radio_group — это прямая «ссылка» на вьюху через Kotlin-X, но она нам не нужна, а нужно только ее содержимое. Аналогично инициализируем все объекты строк, анимаций и т.п, если они переиспользуются в активити/фрагменте несколько раз.
С проблемой отсутствия консистентности на стыке с нативным кодом очень согласен, досаждает регулярно, и получается не так красиво, как должно быть.
Рынок труда устроен именно так, к счастью или к сожалению, и умеение держать баланс — это сугубо личное. Мое мнение — пять но плохо, хуже чем один но хорошо, но один досконально, хуже, чем два хорошо. В нашем случае эксперимент показал, что Котлин к продакшену готов, поэтому все новые модули мы теперь пишем на нем, так метаний между языками становится меньше, а знания платформы с любым языком в нашем случае остаются одинаковыми, что Котлин, что Джава живут поверх одной JVM и одного Андроида.
Никто не мешает, но идти против приниципов принятых платформой (язком, фреймворком, операционной системой — не важно) обычно не просто не так удобно, но еще и не так продуктивно, особенно если разработка идет в команде. Поэтому да, каждый отвечает сам за свои действия, но влияние среды все-таки надо учитывать, и менять среду, если есть такая возможность.
такой вариант читаемости уже не добавляет, и нужно держать в уме, что код выполняется не только по правую сторону от стрелок, но и по левую, когда функции validate и anotherOptionToValidate содержат сайд эффекты получается просто ужасно.
Чтобы решить проблему с тем, что Mockito не работает с такими классами, есть обходной пусть: можно создать конфиг файл, который сделает все котлин-классы открытыми для мокито, но только для тестов.