Удивительно, что такой крутой доклад вызвал так мало отклика и комментариев. Возвращаюсь к нему уже раз третий. Сам работаю техлидом, провожу собеседования. Очень полезно. Спасибо вам, правда.
К тому же, когда мы говорим про github, то редко подразумеваем закрытые данные — основной смысл эта площадка имеет при совместной работе над open source. А открытый код никуда не утечёт.
Формально да. Но в таком случае зачем в руководстве указано ставить именно CNAME своего репозитория? Всё же есть явное ощущение, что в планах было использовать его для аутентификации, благо технически это легко (они и так на этапе привязки проверяют, есть ли CNAME на гитхаб, так что ничего сложнее не станет) — но то ли забыли, то ли сломали.
Верно подмечено, однако аналогия некорректна в силу толстых нюансов:
1) У большинства хостингов или выделенные IP, или есть некоторый разброс адресов. Придётся искать конкретные хостинги, которые имеют только один IP. Довольно геморройное занятие.
2) Хостинги не бесплатны, в отличие от репозиториев на гитхабе. Поэтому занятие резко становится менее интересным. Да ещё и надо входить в каждую отдельную панель, закачивать файлы сотней разных способов… Совсем неинтересно.
3) Хостинги не заинтересованы в защите доменов, и не имеют возможности связаться с предыдущим владельцем хостинга. Видимо, гитхаб тоже не заинтересован, что печально, однако средство связи (узнать, у кого было привязано это имя ранее) у них есть.
4) Опять же, можно хотя бы проверять факт, был ли ранее привязан куда-то домен, и на основании этого запрашивать проверочную NS запись.
Думал написать свои мысли по этому поводу в статье, но не стал. Отпишу таки тут.
Не думаю, что тут виноват майрософт. У меня к нему давняя нелюбовь, но в последнее время они очень хорошо маскируются под хороших ребят. Прям хочется верить. Даже дико популярный в последнее время vscode чего стоит.
Скорее причина кроется в том, из-за чего собственно гитхаб отошёл майрософту. У них банально не хватало ресурсов ни на какие нововведения и фиксы. А сейчас они много новых плюшек выкатывают. Хотя странно видеть «реовлюционное нововведение» в виде встроенного в клиент гитхаба способа разрешения конфликтов, который уже есть в любой IDE… Но надо же с чего-то начинать, чтобы догонять.
Да и, хотя я пеняю в этом посте на их безопасность, основные важные вещи у них таки покрыты программой bug bounty. Есть у меня ощущение, что более адекватный человек из поддержки понял бы суть проблемы сломавшегося механизма (я думаю, он был, но сломался) — но мне не повезло. Писать ещё один репорт бесполезно, поэтому решил вынести это наружу.
Мы проблему решаем похожим способом — вот только у нас слишком много всего может меняться в ответах, поэтому мы написали свой сервис, в котором вместо статики мы используем режим обучения — сначала мок сервер является прокси к настоящим сервисам, а потом на основании накопленных данных превращается в быстрый мок сервер.
У вас какое-то слишком узкое понятие узости специалиста.
Как ни странно, в российских реалиях обычно называют фуллстаком не того человека, который полностью знает один некий стек от фронта до бэкенда — а того, кто знает несколько стеков.
А насчёт необходимости узких специалистов «редко и ненадолго» — это просто неправда с потолка.
Где-то ненадолго нужен администратор Oracle 11g? Или, может, Java разработчик? Может, SQL аналитиков нанимают на месяц? Или где-то ищут одноразовых специалистов по машинному обучению?
Нормальный бэкендер знает и свой язык и SQL, и не сделает указанной вами ошибки.
Нормальный фронтендер не затащит на фронт то, что нужно делать на бэке.
Плохой разработчик сделает и то и то и другое вне зависимости от того, узкий он специалист или fullstack.
Насчёт «бизнесу нужны фуллстеки» — здесь есть нюанс. Бизнес разный бывает. И именно фуллстеки нужны обычно там, где человек по факту занимает несколько вакансий. То есть, в небольшом бизнесе или в стартапах. Не говорю, что там работать это плохо — это тоже может быть интересно, в особенности на начальных этапах, когда ты только познаёшь, чем хочешь заниматься.
Но если бизнес большой, а продукт сложный — здесь нужны достаточно узкие специалисты. И, к сожалению, просто нельзя одновременно быть сениор разработчиком фронта, бэка, мобилки, девопсом и архитектором СУБД (у меня был такой опыт, но я не могу покривить душой и сказать, что я был хотя бы миддлом сразу во всех областях сразу). Просто потому что технологии сейчас развиваются с большей скоростью, чем человек может их освоить. Опять же, «освоить» это не значит «прочитать анонсы». Это значит — попробовать вживую. Да, можно хорошо разбираться в 2-3 технологиях, но дальше начинается деградация знаний, и ты действительно становишься универсальным миддлом. Я от этого в какой-то момент устал и ушёл. И очень доволен таким решением.
Хотя я не говорю, что соседние стеки знать не нужно. Я считаю, что сениор должен обладать как минимум полноценным пониманием взаимодействия компонентов своего продукта и умением его отладки — хотя бы чтобы знать, где возникают проблемы, а не вопить, что они «на другом конце». Но понимать тонкости — уже излишне и слишком трудоёмко. Нужно честно признать, что ты развиваешься в конкретном направлении, а в остальных ты в лучшем случае миддл. Затем принять это и не комплексовать. Всегда найдутся люди, которые в чём-то разбираются лучше — поэтому мы и работаем не в одиночку, а командой.
Да, есть какой-то классический (вроде бы) рассказ, где уволенный автор подобного софта для улучшения снимков занялся тем, что позировал на всех достопримечательностях — после чего оказалось, что он присутствует на каждом сделанном пользователя кадре…
Из официальной документации — «censorship of nipples» и «censorship of anus» — так что вряд ли я ошибся. Ну разве что там было что-то про РКН. Возможно, вы смотрите слишком мало хентая.
Не стал добавлять в статью, но в тему о том «как AI пенетрирует порно идустрию» — чудесная другая статья на хабре «Как AI вставляет Николаса Кейджа в фильмы и делает порно со знаменитостями». Мопед не мой, но рекомендую, если пропустили.
К тому же, когда мы говорим про github, то редко подразумеваем закрытые данные — основной смысл эта площадка имеет при совместной работе над open source. А открытый код никуда не утечёт.
Формально да. Но в таком случае зачем в руководстве указано ставить именно CNAME своего репозитория? Всё же есть явное ощущение, что в планах было использовать его для аутентификации, благо технически это легко (они и так на этапе привязки проверяют, есть ли CNAME на гитхаб, так что ничего сложнее не станет) — но то ли забыли, то ли сломали.
Верно подмечено, однако аналогия некорректна в силу толстых нюансов:
1) У большинства хостингов или выделенные IP, или есть некоторый разброс адресов. Придётся искать конкретные хостинги, которые имеют только один IP. Довольно геморройное занятие.
2) Хостинги не бесплатны, в отличие от репозиториев на гитхабе. Поэтому занятие резко становится менее интересным. Да ещё и надо входить в каждую отдельную панель, закачивать файлы сотней разных способов… Совсем неинтересно.
3) Хостинги не заинтересованы в защите доменов, и не имеют возможности связаться с предыдущим владельцем хостинга. Видимо, гитхаб тоже не заинтересован, что печально, однако средство связи (узнать, у кого было привязано это имя ранее) у них есть.
4) Опять же, можно хотя бы проверять факт, был ли ранее привязан куда-то домен, и на основании этого запрашивать проверочную NS запись.
Не думаю, что тут виноват майрософт. У меня к нему давняя нелюбовь, но в последнее время они очень хорошо маскируются под хороших ребят. Прям хочется верить. Даже дико популярный в последнее время vscode чего стоит.
Скорее причина кроется в том, из-за чего собственно гитхаб отошёл майрософту. У них банально не хватало ресурсов ни на какие нововведения и фиксы. А сейчас они много новых плюшек выкатывают. Хотя странно видеть «реовлюционное нововведение» в виде встроенного в клиент гитхаба способа разрешения конфликтов, который уже есть в любой IDE… Но надо же с чего-то начинать, чтобы догонять.
Да и, хотя я пеняю в этом посте на их безопасность, основные важные вещи у них таки покрыты программой bug bounty. Есть у меня ощущение, что более адекватный человек из поддержки понял бы суть проблемы сломавшегося механизма (я думаю, он был, но сломался) — но мне не повезло. Писать ещё один репорт бесполезно, поэтому решил вынести это наружу.
Как ни странно, в российских реалиях обычно называют фуллстаком не того человека, который полностью знает один некий стек от фронта до бэкенда — а того, кто знает несколько стеков.
А насчёт необходимости узких специалистов «редко и ненадолго» — это просто неправда с потолка.
Где-то ненадолго нужен администратор Oracle 11g? Или, может, Java разработчик? Может, SQL аналитиков нанимают на месяц? Или где-то ищут одноразовых специалистов по машинному обучению?
Нормальный бэкендер знает и свой язык и SQL, и не сделает указанной вами ошибки.
Нормальный фронтендер не затащит на фронт то, что нужно делать на бэке.
Плохой разработчик сделает и то и то и другое вне зависимости от того, узкий он специалист или fullstack.
Насчёт «бизнесу нужны фуллстеки» — здесь есть нюанс. Бизнес разный бывает. И именно фуллстеки нужны обычно там, где человек по факту занимает несколько вакансий. То есть, в небольшом бизнесе или в стартапах. Не говорю, что там работать это плохо — это тоже может быть интересно, в особенности на начальных этапах, когда ты только познаёшь, чем хочешь заниматься.
Но если бизнес большой, а продукт сложный — здесь нужны достаточно узкие специалисты. И, к сожалению, просто нельзя одновременно быть сениор разработчиком фронта, бэка, мобилки, девопсом и архитектором СУБД (у меня был такой опыт, но я не могу покривить душой и сказать, что я был хотя бы миддлом сразу во всех областях сразу). Просто потому что технологии сейчас развиваются с большей скоростью, чем человек может их освоить. Опять же, «освоить» это не значит «прочитать анонсы». Это значит — попробовать вживую. Да, можно хорошо разбираться в 2-3 технологиях, но дальше начинается деградация знаний, и ты действительно становишься универсальным миддлом. Я от этого в какой-то момент устал и ушёл. И очень доволен таким решением.
Хотя я не говорю, что соседние стеки знать не нужно. Я считаю, что сениор должен обладать как минимум полноценным пониманием взаимодействия компонентов своего продукта и умением его отладки — хотя бы чтобы знать, где возникают проблемы, а не вопить, что они «на другом конце». Но понимать тонкости — уже излишне и слишком трудоёмко. Нужно честно признать, что ты развиваешься в конкретном направлении, а в остальных ты в лучшем случае миддл. Затем принять это и не комплексовать. Всегда найдутся люди, которые в чём-то разбираются лучше — поэтому мы и работаем не в одиночку, а командой.