Привет, Максим. Спасибо за статью! Смотрю твой канал уже давно. Можешь подсказать, когда будут новые видеоролики по этичному хакингу, тестированию систем на безопасность?
Не понимаю бугурта автора по поводу собеседований. Если ты нормальный специалист с реальными знаниями, то найти/сменить работу будет очень легко. Я как раз недавно менял работу и не заметил никаких "унижений" на собеседовании. Приятно поговорили с приятными людьми, ну да, расшарили экран и показали код, спросили что там происходит. Ну где тут унижение? В итоге за 5 собесов у меня 3 оффера было и везде одно и тоже примерно. Спрашивали опыт, технологии, давали какую-то проблему, чтобы посмотреть на ход мыслей и пути её решения. Соглашусь, выборка небольшая, но раз 5 из 5 собесов прошли хорошо, то значит не всё так плохо?
А ещё в "Чистом коде" дядька говорил, что надо выделять 4 строчки на функцию. И вот спрашивается, как такое сделать с таким запросом)) Загадка от Жака Фреско
К сожалению, не всегда можно реализовывать чистый код. Особенно это касается больших проектов, где может быть мудреная архитектура. К тому же иногда мы просто завязываемся на архитектуру и код-стайл определенного фреймворка. Например, Django для бекэнда не Python. Вот лично на мой вкус там отвратительно выстроен процесс разработки
Честно говоря, двоякое чувство от вашего комментария. С одной стороны вроде как по делу, если мы говорим о некотором конкретном пользователе, с другой стороны не придумал пока)
Дело в том, что контейнеры очень любят падать и штука эта вообще не стабильная. К примеру, вы поднимаете свой Django проект в контейнере вместе с БД, всё работает отлично. Трафик и идёт, пользователи авторизируются, базёнка всё сохраняет. Но вдруг происходит какая то ошибка и тогда сразу контейнер завершит свою работу и падает, и все данные в БД и сама БД исчезают.
Контейнеры нужны только для того, чтобы изолировать программу от хоста со своими зависимостями. Благодаря этому контейнеры жрут мало ресурсов по сравнению с ВМ. Но обратная сторона медали - это скудное его наполнение, только самое необходимое (файловая система, плюс возможность создать процесс). А держать БД в контейнере - плохая идея, потому что он в целом не предназначен под работу с дисковой памятью, да и изоляция БД от хостовой системы не требуется, потому что дисковая память итак изолирована, сегментирована. Если контейнер упадёт, то вы потеряте файл БД и все данные, там хранящиеся.
Для решения проблемы устойчивости контейнеров как раз и придумали Kubernetes, который сам чуть что сбалансирует трафик, переподнимет, так же ещё можно сделать несколько реплик одного и того же приложения (для горизонтального масштабирования), можно задать количество потребляемых ресурсов на контейнер (RAM и CPU). Но Kubernetes также не решает проблемы БД (хотя потуги есть, например, StatefulSet)
Сервис API в контейнере - это самое популярное и правильное решение. Но рекомендуется выносить БД на отдельный сервер, куда сервис API будет слать данные и брать оттуда. Так вы обеспечите сохранность и нивелируете кучу рисков. Также на сервере рекомендуется создать крон для бекапирования БД(на всякий случай). Ну и в идеале конечно вообще сделать несколько реплик БД, которые живут на разных серваках, географически разделенных с бекапами, блекджеком и тд :)). Так обеспечивается 99.99% сохранения данных.
Также, желательно, на проде иметь Kubernetes, который и будет оркестрировать ваши контейнеры с сервисами. Для этого он представляет все возможности (внутреннюю сеть, неймспэйсы для изолирования, про реплики и балансировку описал выше)
Только что хотел это написать) Советую всегда БД на отдельном сервере разворачивать. Или в виртуалке, если учитесь и для себя делаете. Не нужно воплощать в жизнь плохие практики
Некоторые компании ещё предлагают технические должности выше Senior специально для тех, кто не хочет в управление, а хочет углублять свою техническую экспертизу. Например, СБЕР и Газпромбанк точно предлагают такие должности. И так как IT с каждым годом растет и опытные люди становятся опытнее, то уже во многих местах появились такие грейды, как: Chef, Principal Architect и тд.. Также ещё можно на должность Solution Architector`a метить, но тут каждая компания на эту должность по-разному смотрит
По моему ощущению, весь JS - сплошной антипаттерн (да не в обиду будет сказано). Потому что конкатенация строки с массивом взрывает мозг. Создание переменной из области видимости функции в глобальную видимость - это вообще за гранью добра и зла
Большое спасибо за статью! Недавно как раз начал изучать JS. Узнал про методы копирования объекта через Object.assign и JSON.parse(...), но мне показалось что и то и то работает криво.. А вот structuredClone теперь буду применять на практике
Архитектурные решения и качество кода должно определяться от специфики задачи. Если мы ядро ОС, драйвера или ПО для ракет пишем, то очевидно на первое место встаёт скорость. Но бизнес в основном любит скорость разработки и выкатывание фич как можно быстрее, поэтому так и популярен DevOps, сокращающий Time to market и сопутствующие в основном питоновские фреймворки в которых есть всё из коробки. Но про скорость тут вообще тогда говорить бесмысленно)) Т.к. память и процессоры дешевеют, появились облачные технологии, контейнеризация, Kubernetes, то куда бизнесу куда проще масштабировать инфраструктуру вширь, кидая на это всё миллионы долларов
У меня была похожая история, только бывали неприятные моменты, когда открываешь ПР, приходит человек на code review, и только в этот момент ты узнаешь о каких-то правилах. Которые, между прочим, ещё и могли меняться время от времени или выдумывались прямо на ходу
Впрочем, ничего нового. Корпорации на всё готовы, чтобы выудить максимум эффективности за минимальные деньги. Из статьи можно сделать вывод, что, видимо, необходимо менять свою модель поведения для того, чтобы склонить алгоритмы в свою сторону
Мне кажется, что в статье нет посыла "не пробовать что-то новое". А просто объясняются причины, почему в вечной гонке за счастьем может не быть финиша
Привет, Максим. Спасибо за статью! Смотрю твой канал уже давно. Можешь подсказать, когда будут новые видеоролики по этичному хакингу, тестированию систем на безопасность?
ахахахах, да, скоро будут выплачивать ЗП метаденьгами пока не останутся одни метаработники
Не понимаю бугурта автора по поводу собеседований. Если ты нормальный специалист с реальными знаниями, то найти/сменить работу будет очень легко.
Я как раз недавно менял работу и не заметил никаких "унижений" на собеседовании. Приятно поговорили с приятными людьми, ну да, расшарили экран и показали код, спросили что там происходит. Ну где тут унижение?
В итоге за 5 собесов у меня 3 оффера было и везде одно и тоже примерно. Спрашивали опыт, технологии, давали какую-то проблему, чтобы посмотреть на ход мыслей и пути её решения.
Соглашусь, выборка небольшая, но раз 5 из 5 собесов прошли хорошо, то значит не всё так плохо?
А ещё в "Чистом коде" дядька говорил, что надо выделять 4 строчки на функцию. И вот спрашивается, как такое сделать с таким запросом)) Загадка от Жака Фреско
К сожалению, не всегда можно реализовывать чистый код. Особенно это касается больших проектов, где может быть мудреная архитектура. К тому же иногда мы просто завязываемся на архитектуру и код-стайл определенного фреймворка. Например, Django для бекэнда не Python. Вот лично на мой вкус там отвратительно выстроен процесс разработки
Честно говоря, двоякое чувство от вашего комментария. С одной стороны вроде как по делу, если мы говорим о некотором конкретном пользователе, с другой стороны не придумал пока)
Дело в том, что контейнеры очень любят падать и штука эта вообще не стабильная. К примеру, вы поднимаете свой Django проект в контейнере вместе с БД, всё работает отлично. Трафик и идёт, пользователи авторизируются, базёнка всё сохраняет. Но вдруг происходит какая то ошибка и тогда сразу контейнер завершит свою работу и падает, и все данные в БД и сама БД исчезают.
Контейнеры нужны только для того, чтобы изолировать программу от хоста со своими зависимостями. Благодаря этому контейнеры жрут мало ресурсов по сравнению с ВМ. Но обратная сторона медали - это скудное его наполнение, только самое необходимое (файловая система, плюс возможность создать процесс). А держать БД в контейнере - плохая идея, потому что он в целом не предназначен под работу с дисковой памятью, да и изоляция БД от хостовой системы не требуется, потому что дисковая память итак изолирована, сегментирована. Если контейнер упадёт, то вы потеряте файл БД и все данные, там хранящиеся.
Для решения проблемы устойчивости контейнеров как раз и придумали Kubernetes, который сам чуть что сбалансирует трафик, переподнимет, так же ещё можно сделать несколько реплик одного и того же приложения (для горизонтального масштабирования), можно задать количество потребляемых ресурсов на контейнер (RAM и CPU). Но Kubernetes также не решает проблемы БД (хотя потуги есть, например, StatefulSet)
Сервис API в контейнере - это самое популярное и правильное решение. Но рекомендуется выносить БД на отдельный сервер, куда сервис API будет слать данные и брать оттуда. Так вы обеспечите сохранность и нивелируете кучу рисков. Также на сервере рекомендуется создать крон для бекапирования БД(на всякий случай). Ну и в идеале конечно вообще сделать несколько реплик БД, которые живут на разных серваках, географически разделенных с бекапами, блекджеком и тд :)). Так обеспечивается 99.99% сохранения данных.
Также, желательно, на проде иметь Kubernetes, который и будет оркестрировать ваши контейнеры с сервисами. Для этого он представляет все возможности (внутреннюю сеть, неймспэйсы для изолирования, про реплики и балансировку описал выше)
Вообще человек ответил по-хамски на хамское к себе же отношение. Он просто привёл примеры, а его уже американофилом называют
Только что хотел это написать) Советую всегда БД на отдельном сервере разворачивать. Или в виртуалке, если учитесь и для себя делаете. Не нужно воплощать в жизнь плохие практики
Некоторые компании ещё предлагают технические должности выше Senior специально для тех, кто не хочет в управление, а хочет углублять свою техническую экспертизу. Например, СБЕР и Газпромбанк точно предлагают такие должности. И так как IT с каждым годом растет и опытные люди становятся опытнее, то уже во многих местах появились такие грейды, как: Chef, Principal Architect и тд..
Также ещё можно на должность Solution Architector`a метить, но тут каждая компания на эту должность по-разному смотрит
Ниже уже более детально пояснили. Но в целом JS мне нравится своей простотой. На нём можно чё-то быстро налабать, и будеть работать
Верно, спасибо за уточнение
По моему ощущению, весь JS - сплошной антипаттерн (да не в обиду будет сказано). Потому что конкатенация строки с массивом взрывает мозг. Создание переменной из области видимости функции в глобальную видимость - это вообще за гранью добра и зла
Большое спасибо за статью! Недавно как раз начал изучать JS. Узнал про методы копирования объекта через Object.assign и JSON.parse(...), но мне показалось что и то и то работает криво.. А вот structuredClone теперь буду применять на практике
Архитектурные решения и качество кода должно определяться от специфики задачи. Если мы ядро ОС, драйвера или ПО для ракет пишем, то очевидно на первое место встаёт скорость. Но бизнес в основном любит скорость разработки и выкатывание фич как можно быстрее, поэтому так и популярен DevOps, сокращающий Time to market и сопутствующие в основном питоновские фреймворки в которых есть всё из коробки. Но про скорость тут вообще тогда говорить бесмысленно))
Т.к. память и процессоры дешевеют, появились облачные технологии, контейнеризация, Kubernetes, то куда бизнесу куда проще масштабировать инфраструктуру вширь, кидая на это всё миллионы долларов
У меня была похожая история, только бывали неприятные моменты, когда открываешь ПР, приходит человек на code review, и только в этот момент ты узнаешь о каких-то правилах. Которые, между прочим, ещё и могли меняться время от времени или выдумывались прямо на ходу
Колоссальная работа! Есть что узнать, даже будучи профессионалом!
Впрочем, ничего нового. Корпорации на всё готовы, чтобы выудить максимум эффективности за минимальные деньги. Из статьи можно сделать вывод, что, видимо, необходимо менять свою модель поведения для того, чтобы склонить алгоритмы в свою сторону
Вот это цепочка! Отличный реверс-инжиниринг. И часто так приходится ресёчить?