Ну я больше в веб-разработке и больше в стартапах. Таких продуктов, как у вас, у меня в портфолио нет. Банковский софт - это вообще отдельная категория. Специфическая, я бы сказал. Поэтому я и не работал в банках, потому что там по понятным причинам все очень зарегулировано. И ни вдохнуть ни ... без разрешения кучи начальников и сб. Поэтому тут вы правы, признаю. В вашей сфере по-другому никак.
Я не писал про рефакторинг ради рефакторинга. Где вы это прочитали? Или в вашей картине мира есть либо крупный рефакторинг, либо нет никакого. У вас либо с планированием беда, либо с коммуникацией с вашим руководством, если вы не можете донести до него, что уборку тоже нужно включать в планы. Ну, либо вы работаете в структуре, где "я начальник, я лучше знаю". В таких условиях донести что-то до руководства очень сложно.
Вы же в квартире уборку делаете регулярно? Или как стало грязно, сразу ремонт планируете? Вот тут то же самое. Если планировать только глобальный рефакторинг, то он на моей практике наступал очень редко. Просто потому, чтобы выделить столько времени - будет страдать доставка функционала. А это психологически сложнее сделать, чем выделять время в задачах, в которых без причесывание придется костыли ставить. Ну и сама необходимость "большого" рефакторинга говорит о том, что либо изначально была негибкая архитектура, либо не выделяли времени вовремя, вот и накопилось, что нужно прям много переделывать.
На моей практике "причесывние* поэтапно намного эффективнее, чем глобальный рефакторинг в ущерб доставке функционала.
Ещё как зависит) Если, допустим, надо написать скрипт, обрабатывающий файл, который после обработки больше не понадобится, будет совсем неразумно тратить время на проектирование архитектуры и подбор фреймворка., который тут не нужен априори. Если же проект - что-то чуть большее чем одностраничное веб приложение или калькулятор, то конечно, имеет смысл посмотреть и в сторону фреймворков и паттернов и других умных слов, которые вы написали)
Ну, фреймворк как правило берут потому, что в нем уже реализовано большинство функционала, который вам надо будет реализовывать самостоятельно. И напишите ли вы лучшее - большой вопрос, все зависит от вашего опыта. Но у такого подхода есть как минимум 2 больших недостатка: уйма потраченного времени на написание велосипеда и время, которое будут тратить новички, в проекте, чтобы разобраться, что вы написали.
А чтобы условное устаревание используемого фреймворка вас на сильно беспокоило, слой бизнес логики надо делать независимым от фреймворка, чтобы переезд на другой фреймворк не съедал много времени. Ну и обновляться надо вовремя. И выбирать фреймворк стоит как жену, то есть тщательно и надолго.
Если у вас строго типизированный язык, то могу предположить, что с интерфейсами проще тестировать. Например, используя dependency injection. Но у меня контекста мало, поэтому это только предложение)
Такое часто бывает, если сроки диктуются сверху без учёта мнения и реальных возможностей исполнителей. Либо исполнители идут на поводу у руководства из-за боязни быть уволенными. Если убрать эти 2 фактора и считать, что у нас нормальные ребята, которые любят свою работу и стараются делать ее хорошо, всегда можно взять больше времени на причесывание кода. Больше скажу, адекватное руководство идёт навстречу, если уметь правильно обосновать затраты, а не в духе "у нас будет меньше Легаси". Все в ваших руках.
Одному всегда проще. А если тебе ещё до 35, так вообще легкотня кончено) Но ситуации разные, у кого-то есть близкие люди, не готовые к таким кардинальным переменам. Ну и не все готовы начинать жизнь с нуля, когда половина жизни уже позади. На такие кардинальные перемены и сил много надо, больше моральных.
Так в статье же указано, что можно использовать ту же самую сессию, что хранится в куках. Принципиально такой подход ничем не отличается от jwt. На клиенте хранится какой-то идентификатор сессии, который передается в заголовке.
Если мне нужно что-то кроме браузера, я ставлю то, что мне нужно и работаю, все то же самое, что в Винде и в Линуксе. Для моих задач все программы имеются и я не испытываю каких-то проблем. Если у вас есть какие-то программы для работы, которых на маке нет и нет никаких вменяемых альтернатив,х то этот инструмент вам не подходит. И это вполне нормально, на маке есть программы, которых нет на Винде, и это тоже нормально. Кому-то подходит одно, кому-то - другое.
вот и ответ почему быстро и аккумулятор держить
Да мне как пользователю пофиг, почему оно так. Мне важно, что оно быстро и аккумулятор держит дольше. Для меня это важно, и важно, что я могу задачи свои решать эффективнее и дольше без розетки.
Зачем туда ставить Виндоус? Маки - это не просто железо, это ещё и операционка и сопутствующие программы и сервисы. В этом как и сила мак, так и недостаток. Сила в том, что там все под арм архитектуру переписано: ось, все эпловские программы, драйвера, 90% стороннего софта, а что не переписано, очень хорошо работает под Rosetta. Эпл может заставить всех производителей софта это сделать. А своя операционка буквально подогнана под свой проц. Поэтому там так все и быстро, и аккумулятор долго держит. А вы предлагаете туда Винду засунуть, да ещё и с большинством программ, которые будут работать только через эмуляцию, и не как иначе. Ну это будет как минимум некорректное сравнение получится. Если уж сравнивать, то надо сравнивать на аналогичных задачах, а не пытаться Виндоус туда впихнуть.
Чтобы в Германии получать пенсию, на которую можно более-менее прилично жить, а не нищенствовать, надо работать там с молодости и получать неплохую ЗП до самой пенсии. А если своего жилья нет, то на пенсии придется туговато. Гос-во без жилья не оставит, вам выдадут соц. жилье, но ни о какой комфортной старости речи быть не может. Всегда стоит в первую очередь на себя надеятся, а не на пенсию
Не все семейные компании одинаково не полезны )) У меня был достаточно положительный опыт работы в 2х таких "семейных" компаниях. Правда помогали и входили в положение, когда понадобилось. Но одна в итоге покинула рынок РФ, а другая было не в РФ изначально. Может это как-то влияет.
Слушайте, начальный тезис о том, что вакансии пхп программистов висят месяцами, предложил не я, а топикстартер. Я лишь предположил, почему такое может быть.
Конкретно у меня был пример, когда долго искали человека, потому что требовался разработчик с глубокими знаниями сетей и конкретного продукта для виртуализации.
А по поводу долго висящих вакансий пхп программистов, это надо к топикстартеру идти за конкретными примерами. Даже если такие примеры есть, не думаю , что их большинство. И обсуждать надо предметно, а не абстрактные "вакансии, висящие месяцами". У каждой вакансии могут быть свои первопричины.
Так я не писал, что искал пхп разработчика. С чего вы такой вывод сделали? И я не писал, что искал несколько месяцев на одну позицию. Я лишь написал, что несколько месяцев - это недолго. Если есть специфические требования доменной области, то это вполне себе обычная ситуация
Ну я больше в веб-разработке и больше в стартапах. Таких продуктов, как у вас, у меня в портфолио нет. Банковский софт - это вообще отдельная категория. Специфическая, я бы сказал. Поэтому я и не работал в банках, потому что там по понятным причинам все очень зарегулировано. И ни вдохнуть ни ... без разрешения кучи начальников и сб. Поэтому тут вы правы, признаю. В вашей сфере по-другому никак.
Я не писал про рефакторинг ради рефакторинга. Где вы это прочитали? Или в вашей картине мира есть либо крупный рефакторинг, либо нет никакого. У вас либо с планированием беда, либо с коммуникацией с вашим руководством, если вы не можете донести до него, что уборку тоже нужно включать в планы. Ну, либо вы работаете в структуре, где "я начальник, я лучше знаю". В таких условиях донести что-то до руководства очень сложно.
Вы же в квартире уборку делаете регулярно? Или как стало грязно, сразу ремонт планируете? Вот тут то же самое. Если планировать только глобальный рефакторинг, то он на моей практике наступал очень редко. Просто потому, чтобы выделить столько времени - будет страдать доставка функционала. А это психологически сложнее сделать, чем выделять время в задачах, в которых без причесывание придется костыли ставить. Ну и сама необходимость "большого" рефакторинга говорит о том, что либо изначально была негибкая архитектура, либо не выделяли времени вовремя, вот и накопилось, что нужно прям много переделывать.
На моей практике "причесывние* поэтапно намного эффективнее, чем глобальный рефакторинг в ущерб доставке функционала.
Ещё как зависит) Если, допустим, надо написать скрипт, обрабатывающий файл, который после обработки больше не понадобится, будет совсем неразумно тратить время на проектирование архитектуры и подбор фреймворка., который тут не нужен априори. Если же проект - что-то чуть большее чем одностраничное веб приложение или калькулятор, то конечно, имеет смысл посмотреть и в сторону фреймворков и паттернов и других умных слов, которые вы написали)
Ну, фреймворк как правило берут потому, что в нем уже реализовано большинство функционала, который вам надо будет реализовывать самостоятельно. И напишите ли вы лучшее - большой вопрос, все зависит от вашего опыта. Но у такого подхода есть как минимум 2 больших недостатка: уйма потраченного времени на написание велосипеда и время, которое будут тратить новички, в проекте, чтобы разобраться, что вы написали.
А чтобы условное устаревание используемого фреймворка вас на сильно беспокоило, слой бизнес логики надо делать независимым от фреймворка, чтобы переезд на другой фреймворк не съедал много времени. Ну и обновляться надо вовремя. И выбирать фреймворк стоит как жену, то есть тщательно и надолго.
Все зависит от проекта. Чтобы построить сарай, не нужен Гауди.
Если у вас строго типизированный язык, то могу предположить, что с интерфейсами проще тестировать. Например, используя dependency injection. Но у меня контекста мало, поэтому это только предложение)
Такое часто бывает, если сроки диктуются сверху без учёта мнения и реальных возможностей исполнителей. Либо исполнители идут на поводу у руководства из-за боязни быть уволенными. Если убрать эти 2 фактора и считать, что у нас нормальные ребята, которые любят свою работу и стараются делать ее хорошо, всегда можно взять больше времени на причесывание кода. Больше скажу, адекватное руководство идёт навстречу, если уметь правильно обосновать затраты, а не в духе "у нас будет меньше Легаси". Все в ваших руках.
Одному всегда проще. А если тебе ещё до 35, так вообще легкотня кончено) Но ситуации разные, у кого-то есть близкие люди, не готовые к таким кардинальным переменам. Ну и не все готовы начинать жизнь с нуля, когда половина жизни уже позади. На такие кардинальные перемены и сил много надо, больше моральных.
Так в статье же указано, что можно использовать ту же самую сессию, что хранится в куках. Принципиально такой подход ничем не отличается от jwt. На клиенте хранится какой-то идентификатор сессии, который передается в заголовке.
Тот случай, когда комментарий в разы полезнее самой статьи)
У него уже был стимдэк, а вы предлагаете докупить ещё один комп. Зачем?
Это лишь значит, что разработчики pydantic неправильно понимают назначение assert. Иногда и в известных проектах такое бывает.
Главное, чтобы не сломалось в самый неподходящий момент)
https://docs.astral.sh/uv/reference/policies/versioning/
Uv до сих пор не production ready. Я бы два раза подумал, прежде чем использовать его в коммерческом продукте
Если мне нужно что-то кроме браузера, я ставлю то, что мне нужно и работаю, все то же самое, что в Винде и в Линуксе. Для моих задач все программы имеются и я не испытываю каких-то проблем. Если у вас есть какие-то программы для работы, которых на маке нет и нет никаких вменяемых альтернатив,х то этот инструмент вам не подходит. И это вполне нормально, на маке есть программы, которых нет на Винде, и это тоже нормально. Кому-то подходит одно, кому-то - другое.
Да мне как пользователю пофиг, почему оно так. Мне важно, что оно быстро и аккумулятор держит дольше. Для меня это важно, и важно, что я могу задачи свои решать эффективнее и дольше без розетки.
Зачем туда ставить Виндоус? Маки - это не просто железо, это ещё и операционка и сопутствующие программы и сервисы. В этом как и сила мак, так и недостаток. Сила в том, что там все под арм архитектуру переписано: ось, все эпловские программы, драйвера, 90% стороннего софта, а что не переписано, очень хорошо работает под Rosetta. Эпл может заставить всех производителей софта это сделать. А своя операционка буквально подогнана под свой проц. Поэтому там так все и быстро, и аккумулятор долго держит. А вы предлагаете туда Винду засунуть, да ещё и с большинством программ, которые будут работать только через эмуляцию, и не как иначе. Ну это будет как минимум некорректное сравнение получится. Если уж сравнивать, то надо сравнивать на аналогичных задачах, а не пытаться Виндоус туда впихнуть.
Чтобы в Германии получать пенсию, на которую можно более-менее прилично жить, а не нищенствовать, надо работать там с молодости и получать неплохую ЗП до самой пенсии. А если своего жилья нет, то на пенсии придется туговато. Гос-во без жилья не оставит, вам выдадут соц. жилье, но ни о какой комфортной старости речи быть не может. Всегда стоит в первую очередь на себя надеятся, а не на пенсию
Не все семейные компании одинаково не полезны )) У меня был достаточно положительный опыт работы в 2х таких "семейных" компаниях. Правда помогали и входили в положение, когда понадобилось. Но одна в итоге покинула рынок РФ, а другая было не в РФ изначально. Может это как-то влияет.
Слушайте, начальный тезис о том, что вакансии пхп программистов висят месяцами, предложил не я, а топикстартер. Я лишь предположил, почему такое может быть.
Конкретно у меня был пример, когда долго искали человека, потому что требовался разработчик с глубокими знаниями сетей и конкретного продукта для виртуализации.
А по поводу долго висящих вакансий пхп программистов, это надо к топикстартеру идти за конкретными примерами. Даже если такие примеры есть, не думаю , что их большинство. И обсуждать надо предметно, а не абстрактные "вакансии, висящие месяцами". У каждой вакансии могут быть свои первопричины.
Так я не писал, что искал пхп разработчика. С чего вы такой вывод сделали? И я не писал, что искал несколько месяцев на одну позицию. Я лишь написал, что несколько месяцев - это недолго. Если есть специфические требования доменной области, то это вполне себе обычная ситуация