Такой подход может работать если вы кустарь-одиночка в какой-то узкой нише. В большой компании вам потребуются союзники.
Опыт это знания + навыки. Навыки оттачиваются только практикой. Поэтому адепты вам не конкуренты. Джуниоры и синьоры могут примерно на одном уровне рассуждать о хороших практиках разработки в теории, но лишь вторые способны внедрять их на практике и осмысленно применять.
.
Возможно переводчик — юморист. Просто в оригинале чуть больше слов, а вместо «урок» используется «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 и т.п. Размер файлов растет примерно в таких же пропорциях. Нет смысла для мелких экранов грузить файлы в большом разрешении, пользователь все равно не оценит качество, однако непременно отметит увеличение времени загрузки.
Одно другому не мешает. Есть большие качественные дисплеи с повышенной плотностью пикселей. Есть мелкие дешевые телефонные экраны. Это значит, что в общем случае нужны оба инструмента. Правда с ростом числа вариантов, которые вы бы хотели поддерживать, увеличиваются затраты. Поэтому на практике приходится всякий раз искать какие-то компромиссы.
Какой смысл писать статью о том, что до тебя уже тысячу раз написали в любом учебнике «Язык… для начинающих»?
Думаю так люди развиваются. Читают учебник, потом пробуют применять, потом делятся мнениями в статьях, а потом кто-то даже пишет свой учебник. Без простых статей не будет и сложных. Написание технических статей и тех.перевод это практические скиллы, которые без практики не прокачиваются.
А что, если мне как раз не надо затронуть остальные переменные, которые ссылаются на этот массив?
Мне кажется, что раскрыв ответ на этот вопрос, у вас мог бы получиться конструктивный коментарий.
Просто на медиуме аудитория реагирует более адекватно. Там нет такого, чтобы каждый комментатор мнил себя крутым рецензентом со своей колокольни. Уровень подготовки читателей может быть абсолютно разным.
Возможно стоит разделять контент — для новичков, я учусь, для умников и т.п. Но вообще это не рокет сайнс, культурные люди могут догадаться и сами без подсказок.
Без базовых вещей закрыт путь к более сложным. На собесах часто попадаются ребята, рассуждающие про солид с эндофункторами, но не знающие базовых вещей — операции со строками, регэкспы и т.п. Ведь про такое у нас говорить не принято. Российское АйТи сообщество, при каждом случае стремящееся демонстрировать свою исключительность и илитарность на пустом месте, постепенно загоняет себя в мало привлекательную нишу.
Могу ошибаться, но заголовок оригинала «8 Common Data Structures in Javascript» лучше было бы перенести как "… на JavaScript". Материал носит скорее иллюстративный характер, помогающий знакомым с этим языком погрузиться в тему ADT на первых этапах обучения. Читайте Кнута и не используйте примеры из учеников в продакшене :).
"… в JavaScript" часть из описанных структур реализована нативно, поэтому нет особого смысла городить абстракции над абстракциями. В поисках же эффективных реализаций исписаны сотни страниц и конца этому пока не видно.
Сегодня мы определяем Touch-режим путем анализа реакции на события touchstart и mousemove:
Современные браузеры поддерживают Pointer Events API, где event.pointerType принимает значения 'mouse', 'pen' или 'touch'. Рассматривали-ли вы такой вариант?
Tcl/Tk запомнился лаконичностью и продуманностью. В эпоху апплетов для браузера делал на нем навороченные формы. Но индустрия выбрала сложный путь JavaScript и HTML.
Прошлая политика GitHub — открой исходники или плати — сильно подстегиаала open source разработку. Теперь GitHub-Microsoft смещает баланс в сторону closed source. Интересно каковы цели?
Полгода тому назад с WSL не получилось завести docker-compose из-за проблем с iptables, поэтому вернулся на легаси вариант где используется VirtualBox. Интересно есть ли у кого-нибудь положительный опыт?
Мне кажется им прилетит за такой выкуп). Мейнфреймы и кобол это один из бизнесов IBM.
Проблема не столько в старости (вон С тоже не молод), сколько в специфике их решений. По сути это то, как выглядит 100% vendor lock. Если вы допустим представляете, как работает компьютер — ну там директории, файлы — можете смело забыть. Они для всего придумали собственную терминологию, с длинными названиями и кучей неочевидных нюансов. Будто система проектировалась таким образом, чтобы без специального обучения и кансалта в ней стороннему специалисту было не разобраться. Мечта фрилансера — даже код обфусцировать не нужно.
Из-за того, что подготовка дорогая и конкуренции на рынке практически нет, это довольно интересная ниша в плане стабильности как для разработчиков так и для организаций которым это нужно. Вас не заменят, но и сами бежать особенно некуда.
Картинка медианная. Это значит, что она призвана отражать зарплаты основной массы. На самом деле было бы интересно увидеть расклад по опыту/тайтлам, но возможно это не входит в цели поста. Могу лишь предположить, что речь идет о разработчиках уровня junior и middle.
Все так и было, но лет 20- тому назад). Сейчас на PHP много разного e-commerce с деньгами и уже не так много специалистов. Java разработчиков наоборот штампуют конвейерами, да и область использования весьма разношерстна — от автоматизаторов тестирования до различных крутых энтерпрайзов.
Если верить графикам в статье, то при медианной зряплате менее 8$/час как в РФ, и среднемировых около 30$ за вами будут охотиться HR любых компаний, какой бы язык вы не выбрали. При таком прайсе даже индусам сложно конкурировать.
Такой подход может работать если вы кустарь-одиночка в какой-то узкой нише. В большой компании вам потребуются союзники.
Опыт это знания + навыки. Навыки оттачиваются только практикой. Поэтому адепты вам не конкуренты. Джуниоры и синьоры могут примерно на одном уровне рассуждать о хороших практиках разработки в теории, но лишь вторые способны внедрять их на практике и осмысленно применять.
Возможно переводчик — юморист. Просто в оригинале чуть больше слов, а вместо «урок» используется «mistake». Например данный подзаголовок дословно выглядит так: «Mistake 1 — not saving your paychecks for a rainy day.»
(все остальные кстати выглядят аналогично). На самом деле автор сожалеет от том, что не додумался сразу о создании подушки финансовой безопасности на черный день.
Если зарплата выше рынка вынуждает сотрудника вкалывать как папа Карло на месте, где должно работать трое, так же есть повод переосмыслить ситуацию. Возможно он уникален, но одно только это качество не делает его незаменимым. С точки зрения работодателя — когда на место будут наняты трое, либо позиция утратит актуальность — это лишь вопрос времени.
Зарплата выше рынка в долгосрочной перспективе это довольно ненадежный способ удержания незаменимых людей. Я имею ввиду то, что одной лишь зарплатой зазвездившийся персонал вы не удержите. Потеряв связь с реальностью, они отправляются налево даже просто ради новых ощущений.
По большому счету, незаменимых людей не бывает, за очень редким исключением (кто нам заменит Пушкина?). В большинстве же случаев это манипуляции тщеславием, ролевые игры на производстве. Не нужно к этому относится слишком серьезно, рассчитывая как на свой основной козырь. Все может поменяться в любой момент.
Поддержу про голосовой ввод — вещь весьма специфическая. Меню рассчитаны, что оно поймет команду с первого раза без ошибок, даже не переспросив. Случались эпические ошибки недопонимания. Диалоги в несколько уровней вообще мрак. Ошибка по середине и начинай объяснять все сначала. Естественно это отвлекает от дороги. Поэтому пользуюсь очень редко.
Основное назначение <img srcset> — предоставить версии одной и той же картинки для экранов с разной плотностью пикселей. Появился примерно вместе с retina экранами. Плотность пикселей на дюйм, принятая за базовую в вебе — 96 dpi. x2 это 192, x4 384 и т.п. Размер файлов растет примерно в таких же пропорциях. Нет смысла для мелких экранов грузить файлы в большом разрешении, пользователь все равно не оценит качество, однако непременно отметит увеличение времени загрузки.
Одно другому не мешает. Есть большие качественные дисплеи с повышенной плотностью пикселей. Есть мелкие дешевые телефонные экраны. Это значит, что в общем случае нужны оба инструмента. Правда с ростом числа вариантов, которые вы бы хотели поддерживать, увеличиваются затраты. Поэтому на практике приходится всякий раз искать какие-то компромиссы.
Думаю так люди развиваются. Читают учебник, потом пробуют применять, потом делятся мнениями в статьях, а потом кто-то даже пишет свой учебник. Без простых статей не будет и сложных. Написание технических статей и тех.перевод это практические скиллы, которые без практики не прокачиваются.
Мне кажется, что раскрыв ответ на этот вопрос, у вас мог бы получиться конструктивный коментарий.
Возможно стоит разделять контент — для новичков, я учусь, для умников и т.п. Но вообще это не рокет сайнс, культурные люди могут догадаться и сами без подсказок.
Без базовых вещей закрыт путь к более сложным. На собесах часто попадаются ребята, рассуждающие про солид с эндофункторами, но не знающие базовых вещей — операции со строками, регэкспы и т.п. Ведь про такое у нас говорить не принято. Российское АйТи сообщество, при каждом случае стремящееся демонстрировать свою исключительность и илитарность на пустом месте, постепенно загоняет себя в мало привлекательную нишу.
"… в JavaScript" часть из описанных структур реализована нативно, поэтому нет особого смысла городить абстракции над абстракциями. В поисках же эффективных реализаций исписаны сотни страниц и конца этому пока не видно.
Современные браузеры поддерживают Pointer Events API, где event.pointerType принимает значения 'mouse', 'pen' или 'touch'. Рассматривали-ли вы такой вариант?
Проблема не столько в старости (вон С тоже не молод), сколько в специфике их решений. По сути это то, как выглядит 100% vendor lock. Если вы допустим представляете, как работает компьютер — ну там директории, файлы — можете смело забыть. Они для всего придумали собственную терминологию, с длинными названиями и кучей неочевидных нюансов. Будто система проектировалась таким образом, чтобы без специального обучения и кансалта в ней стороннему специалисту было не разобраться. Мечта фрилансера — даже код обфусцировать не нужно.
Из-за того, что подготовка дорогая и конкуренции на рынке практически нет, это довольно интересная ниша в плане стабильности как для разработчиков так и для организаций которым это нужно. Вас не заменят, но и сами бежать особенно некуда.
Если верить графикам в статье, то при медианной зряплате менее 8$/час как в РФ, и среднемировых около 30$ за вами будут охотиться HR любых компаний, какой бы язык вы не выбрали. При таком прайсе даже индусам сложно конкурировать.