Чтобы далеко бежать нужны хоть какие-то деньги, а без денег и по уши в кредитах ни кто ни куда не убежит.
Сократить зарплаты в АйТи на 20-40-50% по максимуму это сейчас миссия государственной важности. Только так мы сможем победить короновирус и сохранить кадры. А из разницы может на бонусы к концу года останется. Не много конечно, жалкие гроши).
Интересно. Где про этот чип можно почитать, какие у него возможности и ограничения, в каких устройствах он поставляется, может-ли Assistant распознавать фразу без этого чипа? В новости пишут, что регулировка чувствительности будет через программу.
В чем проблема если программист напишет явно, что программа ни когда не остановится? В культурном обществе джентльменам принято верить на слово и к мистеру тайпчекеру это тоже относится — например.
Спасибо за ссылку. У вас скорее 0 + 0 = 0 :). Вот функция a -> Void, или иными словами 0^a ни чему же не противоречит?
Мне почему-то кажется, что Void, bottom и never это и есть 0, только разными словами (плюс-минус особенности языка, которые тут нас ни к чему не обязывают).
В тайпскрипте основные свойства можно даже показать:
type T32<T> = never extends T ? true : false; // true
type T33<T> = T extends never ? true : false; // Deferred
В хаскеле он выражается с помощью кастылей. Но это скорее следствие тех самых особенностей, чем теоретическая необходимость. Я бы не стал возводить в абсолют.
Всем и так понятно, что функция может никогда не завершиться, потому что это проблема останова, что любая функция может вернуть боттом.
В самом деле, статическая типизация не решает научных проблем, не страхует от всех возможных видов ошибок и не претендует на абсолютную истину. На мой взгляд, она больше про intentions, а не вероятности или теоретические возможности. Предполагается, что когда программист объявляет типы статически, то он выражает этим какие-то свои осознанные намерения. В награду за это получает подсказки со стороны софта, который может автоматические контролировать корректность различных утверждений (в рамках принятых соглашений и допущений).
Довольно типичная проблема при рефакторингах.
Было:
Функция может кидать исключение, оставаться в бесконечном цикле, завершать программу exit(0):
function error(message: string): never {
throw new Error(message);
}
На мой взгляд, это не столь редкие вещи в программировании и можно ожидать поддержки со стороны системы типов. По сути нужно проверять условие, что результат функции ни кто не ожидает.
Возможно ли реализовать данную функцию? Очевидно, ответ на этот вопрос — нет, т.к. Void — это тип с нулём возможных значений, поэтому невозможно написать ни одной функции, возвращающей значение типа Void.
Стоп, как это очевидно, и кто ж нам мешает? Пока функцию не вызовут, до возвращаемого значения не должно быть ни какого дела. Я уж не говорю об исключениях, когда язык их поддерживает. Статья вроде не про раст.
Востребуемость сильно зависит от ситуации. Можно в реальном времени наблюдать как закрывается множество востребованных раннее сервисов, просто потому что люди вынуждены держать дистанцию. С другой стороны стали резко востребованы те, про кого раньше вообще мало кто знал (производства медицинской спецодежды, например). Пройдет время и ситуация снова изменится. От уровня специалистов, работающих в каждой из областей, это не особо зависит.
Такой подход может работать если вы кустарь-одиночка в какой-то узкой нише. В большой компании вам потребуются союзники.
Опыт это знания + навыки. Навыки оттачиваются только практикой. Поэтому адепты вам не конкуренты. Джуниоры и синьоры могут примерно на одном уровне рассуждать о хороших практиках разработки в теории, но лишь вторые способны внедрять их на практике и осмысленно применять.
.
Возможно переводчик — юморист. Просто в оригинале чуть больше слов, а вместо «урок» используется «mistake». Например данный подзаголовок дословно выглядит так: «Mistake 1 — not saving your paychecks for a rainy day.»
(все остальные кстати выглядят аналогично). На самом деле автор сожалеет от том, что не додумался сразу о создании подушки финансовой безопасности на черный день.
С точки зрения работодателя незаменимый сотрудник это риск. Учитывается вероятность риска, а также сравнивается стоимость отработки последствий, если риск сработал, с затратами на его уменьшение или устранение. Если риск принимается, значит последствия от потери незаменимого сотрудника не столь велики, чтобы тратить на это дополнительные ресурсы. Логично? Такому сотруднику нужно снять лапшу с ушей и задуматься, о реальной оценке собственной значимости.
Если зарплата выше рынка вынуждает сотрудника вкалывать как папа Карло на месте, где должно работать трое, так же есть повод переосмыслить ситуацию. Возможно он уникален, но одно только это качество не делает его незаменимым. С точки зрения работодателя — когда на место будут наняты трое, либо позиция утратит актуальность — это лишь вопрос времени.
Зарплата выше рынка в долгосрочной перспективе это довольно ненадежный способ удержания незаменимых людей. Я имею ввиду то, что одной лишь зарплатой зазвездившийся персонал вы не удержите. Потеряв связь с реальностью, они отправляются налево даже просто ради новых ощущений.
Современные браузеры представляют собой ряд компромиссов, чтобы соблюсти интересы заинтересованых сторон. Хромиум это конструктор с множеством опций на уровне исходного кода, которые можно твикнуть. В хроме есть набор собственных фич, полезных и не очень. Существует ряд специфичных API, которыми вы скорее всего ни когда не пользуетесь (например Web Speach API). Есть вещи, без которых можно обойтись. Даже тупо выкасив всю телеметрию вы уже получите определенные преимущества.
В какой то момент открываются новые пути или возможности, и если вы ответственный человек, то незаменимость на текущем месте начинает быть обузой.
По большому счету, незаменимых людей не бывает, за очень редким исключением (кто нам заменит Пушкина?). В большинстве же случаев это манипуляции тщеславием, ролевые игры на производстве. Не нужно к этому относится слишком серьезно, рассчитывая как на свой основной козырь. Все может поменяться в любой момент.
Люблю путешествия на авто, часто езжу по незнакомым местам. Голосовые подсказки мега удобны — знаки, повороты, камеры, заправки. Особенно ночью, когда видимость ограничена. Громкость надо лишь отрегулировать.
Поддержу про голосовой ввод — вещь весьма специфическая. Меню рассчитаны, что оно поймет команду с первого раза без ошибок, даже не переспросив. Случались эпические ошибки недопонимания. Диалоги в несколько уровней вообще мрак. Ошибка по середине и начинай объяснять все сначала. Естественно это отвлекает от дороги. Поэтому пользуюсь очень редко.
<picture> предназначен для вывода разных изображений в зависимости от физического размера экрана (так называемый art direction). Допустим у вас есть картина «корова на лугу». Такая средних размеров корова на фоне большого прекрасного луга. На больших десктопных экранах можно показать картину целиком. Масштабирование для небольших экранов делает корову слишком мелкой и пользователь видит в основном только лужайку. Кому-то приходит идея обрезать картинку так, чтобы корова занимала большую часть картины, пожертвовав частью луга. Для совсем маленьких экранов можно оставить вообще лишь коровью морду. Или нет? В общем, это процесс творческий, плохо поддающийся алгоритмизации. Поэтому если вам нужен качественный результат, то работу выполняет дизайнер. Так появляется вторая, третья и так далее версии картины. Верстальщику остается лишь упаковать все варианты в <picure>.
Основное назначение <img srcset> — предоставить версии одной и той же картинки для экранов с разной плотностью пикселей. Появился примерно вместе с retina экранами. Плотность пикселей на дюйм, принятая за базовую в вебе — 96 dpi. x2 это 192, x4 384 и т.п. Размер файлов растет примерно в таких же пропорциях. Нет смысла для мелких экранов грузить файлы в большом разрешении, пользователь все равно не оценит качество, однако непременно отметит увеличение времени загрузки.
Одно другому не мешает. Есть большие качественные дисплеи с повышенной плотностью пикселей. Есть мелкие дешевые телефонные экраны. Это значит, что в общем случае нужны оба инструмента. Правда с ростом числа вариантов, которые вы бы хотели поддерживать, увеличиваются затраты. Поэтому на практике приходится всякий раз искать какие-то компромиссы.
Чтобы далеко бежать нужны хоть какие-то деньги, а без денег и по уши в кредитах ни кто ни куда не убежит.
Сократить зарплаты в АйТи на 20-40-50% по максимуму это сейчас миссия государственной важности. Только так мы сможем победить короновирус и сохранить кадры. А из разницы может на бонусы к концу года останется. Не много конечно, жалкие гроши).
a -> Void, или иными словами0^aни чему же не противоречит?Мне почему-то кажется, что Void, bottom и never это и есть 0, только разными словами (плюс-минус особенности языка, которые тут нас ни к чему не обязывают).
В тайпскрипте основные свойства можно даже показать:
В хаскеле он выражается с помощью кастылей. Но это скорее следствие тех самых особенностей, чем теоретическая необходимость. Я бы не стал возводить в абсолют.
Вот кратко в вики en.wikipedia.org/wiki/Bottom_type или популярно у Милевски в блоге bartoszmilewski.com/2015/03/13/function-types.
В самом деле, статическая типизация не решает научных проблем, не страхует от всех возможных видов ошибок и не претендует на абсолютную истину. На мой взгляд, она больше про intentions, а не вероятности или теоретические возможности. Предполагается, что когда программист объявляет типы статически, то он выражает этим какие-то свои осознанные намерения. В награду за это получает подсказки со стороны софта, который может автоматические контролировать корректность различных утверждений (в рамках принятых соглашений и допущений).
Довольно типичная проблема при рефакторингах.
Было:
Стало:
Ведь здорово, когда за такое можно получить по шапке не в рантайме, а еще на этапе кодинга?
www.typescriptlang.org/docs/handbook/basic-types.html#never
На мой взгляд, это не столь редкие вещи в программировании и можно ожидать поддержки со стороны системы типов. По сути нужно проверять условие, что результат функции ни кто не ожидает.
Стоп, как это очевидно, и кто ж нам мешает? Пока функцию не вызовут, до возвращаемого значения не должно быть ни какого дела. Я уж не говорю об исключениях, когда язык их поддерживает. Статья вроде не про раст.
3|
2| X ~ X ~ X
1| X X X X X
3| X
2| X ~ X ~ X
1| X X X X X
Такой подход может работать если вы кустарь-одиночка в какой-то узкой нише. В большой компании вам потребуются союзники.
Опыт это знания + навыки. Навыки оттачиваются только практикой. Поэтому адепты вам не конкуренты. Джуниоры и синьоры могут примерно на одном уровне рассуждать о хороших практиках разработки в теории, но лишь вторые способны внедрять их на практике и осмысленно применять.
Возможно переводчик — юморист. Просто в оригинале чуть больше слов, а вместо «урок» используется «mistake». Например данный подзаголовок дословно выглядит так: «Mistake 1 — not saving your paychecks for a rainy day.»
(все остальные кстати выглядят аналогично). На самом деле автор сожалеет от том, что не додумался сразу о создании подушки финансовой безопасности на черный день.
Если зарплата выше рынка вынуждает сотрудника вкалывать как папа Карло на месте, где должно работать трое, так же есть повод переосмыслить ситуацию. Возможно он уникален, но одно только это качество не делает его незаменимым. С точки зрения работодателя — когда на место будут наняты трое, либо позиция утратит актуальность — это лишь вопрос времени.
Зарплата выше рынка в долгосрочной перспективе это довольно ненадежный способ удержания незаменимых людей. Я имею ввиду то, что одной лишь зарплатой зазвездившийся персонал вы не удержите. Потеряв связь с реальностью, они отправляются налево даже просто ради новых ощущений.
По большому счету, незаменимых людей не бывает, за очень редким исключением (кто нам заменит Пушкина?). В большинстве же случаев это манипуляции тщеславием, ролевые игры на производстве. Не нужно к этому относится слишком серьезно, рассчитывая как на свой основной козырь. Все может поменяться в любой момент.
Поддержу про голосовой ввод — вещь весьма специфическая. Меню рассчитаны, что оно поймет команду с первого раза без ошибок, даже не переспросив. Случались эпические ошибки недопонимания. Диалоги в несколько уровней вообще мрак. Ошибка по середине и начинай объяснять все сначала. Естественно это отвлекает от дороги. Поэтому пользуюсь очень редко.
Основное назначение <img srcset> — предоставить версии одной и той же картинки для экранов с разной плотностью пикселей. Появился примерно вместе с retina экранами. Плотность пикселей на дюйм, принятая за базовую в вебе — 96 dpi. x2 это 192, x4 384 и т.п. Размер файлов растет примерно в таких же пропорциях. Нет смысла для мелких экранов грузить файлы в большом разрешении, пользователь все равно не оценит качество, однако непременно отметит увеличение времени загрузки.
Одно другому не мешает. Есть большие качественные дисплеи с повышенной плотностью пикселей. Есть мелкие дешевые телефонные экраны. Это значит, что в общем случае нужны оба инструмента. Правда с ростом числа вариантов, которые вы бы хотели поддерживать, увеличиваются затраты. Поэтому на практике приходится всякий раз искать какие-то компромиссы.