Ничего нового для себя в статье не прочитал, но с топиком соглашусь – вайбкодинг (с агентом и контекстом, а не просто а одном файлике или гонять между окошком гпт с редактором) возвращает любовь к кодингу в целом. Пока пользуюсь платным копилотом с сонетом, в vs code, нравится. Влёт генерирует тесты, докерфайлы, запускает сам это всё, смотрит логи, поправляет себя.
Интересно, насколько круче работает упомянутый выше курсор.
Я встречал в основном варианты, когда номинальным "начальником" выступает всё же ПМ. А ТЛ – первый среди равных. При наличии обеих ролей ПМ – точка входа для менеджмента, бизнеса, менее "технических" интересантов, других ПМ. А ТЛ – для архитекторов, программистов из других отделов. Отчего обязанности и ожидания разнятся от компании к компании. Хотелось бы в статье увидеть эту роль более очерченной, но увы, много реверансов в сторону "эти обязанности разделяются с ПМ, но на более высоком уровне" и без конкретики, об этом самом уровне. Еще сложнее получается с появлением техлидов, но это отдельная история.
Она написана около 50 лет назад. Читается легко, но я бы не сказал, что по ней можно составить представление о современных процессах в IT. Эту книгу мне напомнила прочитанная позже "Идеальный программист" того же дяди Боба, много воспоминаний о былом. Познавательно, но не более.
Под "стандартной сессией" автор наверное понимает обычный токен без вшитой в него информации. Аутентификация пользователя идет после запроса ко внешнему хранилищу (база, редис), затем мы получаем доп данные снова из хранилища. Истечение сессии тоже хранится где-то.
Jwt это подписанный на сервере payload по юзеру с некими стандартными полями для контроля протухания. Если хочется сэкономить на запросах в хранилище, это хороший вариант. Если же сам jwt токен начинают хранить в базе, и эти запросы все равно требуются (если хочется иметь возможность отменять рабочие сессии, например), то плюсы резко уменьшаются.
В нашей архитектуре подключать переиспользуемый код в виде библиотеки оказалось ошибкой. Проблема в том, что такая библиотека скорее всего будет развиваться параллельно с кодом, со сторонним сервисом, для которого она написана и т.п. Постоянно мониторить, какие сервисы нужно обновить при обновлении библиотеки (и страдать, если забыли) — та ещё боль.
Мне кажется, кроме перечисленных решений (копипаста и чуть большая связанность), есть ещё два: выделить библиотеку в отдельный микросервис со своим API, и, ИМХО, лучший вариант, отказаться от разделения тех микросервисов, которые делят общий код — скорее всего их разделение искусственно.
ES2015 (ES6) не только «утверждён», но и поддерживается в достаточном обьёме во всех современных браузерах. Так что на нём писать не только можно, но и нужно.
Information
Rating
Does not participate
Location
Санкт-Петербург, Санкт-Петербург и область, Россия
Ничего нового для себя в статье не прочитал, но с топиком соглашусь – вайбкодинг (с агентом и контекстом, а не просто а одном файлике или гонять между окошком гпт с редактором) возвращает любовь к кодингу в целом. Пока пользуюсь платным копилотом с сонетом, в vs code, нравится. Влёт генерирует тесты, докерфайлы, запускает сам это всё, смотрит логи, поправляет себя.
Интересно, насколько круче работает упомянутый выше курсор.
Рекомендую, если хотите красивые коммиты, а не "закоммитил в пятницу вечером, в пн разберусь" - команда добавляет в предыдущий коммит
Я встречал в основном варианты, когда номинальным "начальником" выступает всё же ПМ. А ТЛ – первый среди равных. При наличии обеих ролей ПМ – точка входа для менеджмента, бизнеса, менее "технических" интересантов, других ПМ. А ТЛ – для архитекторов, программистов из других отделов. Отчего обязанности и ожидания разнятся от компании к компании. Хотелось бы в статье увидеть эту роль более очерченной, но увы, много реверансов в сторону "эти обязанности разделяются с ПМ, но на более высоком уровне" и без конкретики, об этом самом уровне. Еще сложнее получается с появлением техлидов, но это отдельная история.
Я бы добавил Фаулера – либо Шаблоны корпоративных приложений, либо Рефакторинг
Она написана около 50 лет назад. Читается легко, но я бы не сказал, что по ней можно составить представление о современных процессах в IT. Эту книгу мне напомнила прочитанная позже "Идеальный программист" того же дяди Боба, много воспоминаний о былом. Познавательно, но не более.
Под "стандартной сессией" автор наверное понимает обычный токен без вшитой в него информации. Аутентификация пользователя идет после запроса ко внешнему хранилищу (база, редис), затем мы получаем доп данные снова из хранилища. Истечение сессии тоже хранится где-то.
Jwt это подписанный на сервере payload по юзеру с некими стандартными полями для контроля протухания. Если хочется сэкономить на запросах в хранилище, это хороший вариант. Если же сам jwt токен начинают хранить в базе, и эти запросы все равно требуются (если хочется иметь возможность отменять рабочие сессии, например), то плюсы резко уменьшаются.
Мне кажется, кроме перечисленных решений (копипаста и чуть большая связанность), есть ещё два: выделить библиотеку в отдельный микросервис со своим API, и, ИМХО, лучший вариант, отказаться от разделения тех микросервисов, которые делят общий код — скорее всего их разделение искусственно.