Поражаюсь тому какая невероятная концентрация ультра хай тек технологий собрана в Starlink. И ещё больше поражаюсь управленческому гению команды менеджмента SpaceX: это просто невероятно собрать столько умных людей в одном месте и дать им возможность творить будущее
У меня сейчас на Kubuntu левый Win это английская, правый Win это русская. И это настолько удобно, что циклические переключения вроде Cmd+Space или Ctrl+Shift кажутся каменным веком. А вообще, очень плохо что развитие клавиатур останавливалось, по правильному для переключения раскладок должны быть отдельные кнопки
Ваша механика подписок никогда не работала, а вы всё тянете её и тянете. Делайте не подписки, а отписки. Я хочу по умолчанию видеть всё и постепенно удалять из ленты тех авторов и те хабы которые мне не интересны.
Ответил вопросом на вопрос потому-что ваш вопрос показался крайне токсичным и не конструктивным. Но правильно будет ответить по другому:
DDD и чистая архитектура по Мартину в своей сути предполагает чистые функции и разделение слоёв что вполне реализуется на любом C подобном языке. Автор комментария намекает на то что Go не Java и не надо в Go тянуть реализации подходов из Java. 100 слоёв абстракции и развесистые ORM это не Go-way. Для Go нужны свои решения, простые и лёгкие, более подходящие под философию языка
Большинство проблем реального скрама в формальных размерах спринтов. Одна неделя, две недели, даже месяц это всё слишком формальные оценки времени которые порождают много формальной бюрократии. Привяжитесь к версиями релизов/срокам релиза:
Вместо формальных еженедельных планирований и формальных отчётов кто что сделал за неделю у вас будут нормальные "живые" планирования следующего релиза.
У всех возникнет чёткая картина того что надо сделать чтобы получить результат. Результат(!!!), а не формальный отчёт о сделанных за неделю задачах. Сходите, прямо спросите у бизнеса, им результат нужен или отчёты о сделанных за неделю задачах (только спрашивайте у бизнеса, а у не наёмного менеджмента).
Пропадут все еженедельные переносы задач. Задача нужна к релизу? Ну и делай её до релиза. Размер и дробление задач перестают быть краеугольным камнем
Стори поинты конечно надо оставить, но только как предварительную оценку сделанную самим разработчиком. По закрытию задачи можно вписывать реальную оценку
Тут конечно некоторые менеджеры возмутятся: а как нам видеть прогресс? А как нам оценивать эффективность сотрудников? Да так же как и обычно, по субъективной внутренней оценке скорости/качества/вовлечённости. Конечно менеджеру чтобы так работать надо "быть в теме", быть достаточно квалифицированным и держать руку на пульсе проекта, а не появляться только на планированиях спринта. Если вы так не можете то welcome в отделы продаж и колценты, там формальные оценки любят.
Кажется произошла довольно типичная для современной журналистики ошибка: кто-то не понял пресс релиза и написал что МТС заключило какое-то эксклюзивное соглашение с Телеграм, а пользователи из плохо написанных новостей решили что Телеграм отдал всё данные МТС. Но если вчитаться то видно что МТС запустило рекламную платформу МТС Маркетолог одной из фишек которой является таргетинг по номеру телефона в Телеграм, причём таргетинг обезличенный
А что мешает сделать эндпоинт для получения списка нужных постов с нужным набором данных, где логика будет прописана не на клиенте, а на сервере?
Если у вас маленькая команда то ничего не мешает. А вот в крупных компаниях frontend и mobile делает отдельная команда, и получается неудобно на каждую фичу просить backend команду вставить новый endpoint.
У них там свой график и план релизов, и из-за бюрократии становится сложно согласовать изменения/просить добавлять новые фичи.
В статье о этом не написано, но самое главное достоинство GraphQL именно в этом. Это ещё один стандартизированный QueryLanguage который позволяет получать все что нужно фронту не отвлекая бэк.
После массового внедрения цифровой фотографии ценность каждого снимка близка к нулю. Так-же и массовая генерация артов уничтожит ценность работ цифровых художников
Настоящий композитный хайтек так и выглядит, его буквально прядут из углепастиковой или стеклопластиковой пряжи с добавлением эпоксидки. И композитные баллоны держат большое давление, баллоны, например под метан, делают из композита
Поражаюсь тому какая невероятная концентрация ультра хай тек технологий собрана в Starlink. И ещё больше поражаюсь управленческому гению команды менеджмента SpaceX: это просто невероятно собрать столько умных людей в одном месте и дать им возможность творить будущее
Вроде бы одновременное обновление в базе и в Redis решает проблему. Почему тогда указано что запись в Redis надо удалять, а не обновлять?
У меня сейчас на Kubuntu левый Win это английская, правый Win это русская. И это настолько удобно, что циклические переключения вроде Cmd+Space или Ctrl+Shift кажутся каменным веком. А вообще, очень плохо что развитие клавиатур останавливалось, по правильному для переключения раскладок должны быть отдельные кнопки
Ваша механика подписок никогда не работала, а вы всё тянете её и тянете. Делайте не подписки, а отписки. Я хочу по умолчанию видеть всё и постепенно удалять из ленты тех авторов и те хабы которые мне не интересны.
На графике с ноября 2021 довольно плавный рост без резкого прыжка в момент появления сертификатов https://gs.statcounter.com/browser-market-share/all/russian-federation/#monthly-202111-202311
Ответил вопросом на вопрос потому-что ваш вопрос показался крайне токсичным и не конструктивным. Но правильно будет ответить по другому:
DDD и чистая архитектура по Мартину в своей сути предполагает чистые функции и разделение слоёв что вполне реализуется на любом C подобном языке. Автор комментария намекает на то что Go не Java и не надо в Go тянуть реализации подходов из Java. 100 слоёв абстракции и развесистые ORM это не Go-way. Для Go нужны свои решения, простые и лёгкие, более подходящие под философию языка
Правильно ли я вас понял, что вы считаете что подходы чистой архитектуры применимы только при Java-like программировании?
Чтобы закрыть дискуссию дам пример такого запроса с JOIN:
Большинство проблем реального скрама в формальных размерах спринтов. Одна неделя, две недели, даже месяц это всё слишком формальные оценки времени которые порождают много формальной бюрократии. Привяжитесь к версиями релизов/срокам релиза:
Вместо формальных еженедельных планирований и формальных отчётов кто что сделал за неделю у вас будут нормальные "живые" планирования следующего релиза.
У всех возникнет чёткая картина того что надо сделать чтобы получить результат. Результат(!!!), а не формальный отчёт о сделанных за неделю задачах. Сходите, прямо спросите у бизнеса, им результат нужен или отчёты о сделанных за неделю задачах (только спрашивайте у бизнеса, а у не наёмного менеджмента).
Пропадут все еженедельные переносы задач. Задача нужна к релизу? Ну и делай её до релиза. Размер и дробление задач перестают быть краеугольным камнем
Стори поинты конечно надо оставить, но только как предварительную оценку сделанную самим разработчиком. По закрытию задачи можно вписывать реальную оценку
Тут конечно некоторые менеджеры возмутятся: а как нам видеть прогресс? А как нам оценивать эффективность сотрудников? Да так же как и обычно, по субъективной внутренней оценке скорости/качества/вовлечённости. Конечно менеджеру чтобы так работать надо "быть в теме", быть достаточно квалифицированным и держать руку на пульсе проекта, а не появляться только на планированиях спринта. Если вы так не можете то welcome в отделы продаж и колценты, там формальные оценки любят.
Довольно давно была новость о том что Kaspersky VPN первый из VPN кто присоединился к блокировкам. Попробуйте его
Кажется произошла довольно типичная для современной журналистики ошибка: кто-то не понял пресс релиза и написал что МТС заключило какое-то эксклюзивное соглашение с Телеграм, а пользователи из плохо написанных новостей решили что Телеграм отдал всё данные МТС. Но если вчитаться то видно что МТС запустило рекламную платформу МТС Маркетолог одной из фишек которой является таргетинг по номеру телефона в Телеграм, причём таргетинг обезличенный
Нет, таргетинг по номеру телефона для всех российских операторов, МТС тут в принципе не причём.
Если у вас маленькая команда то ничего не мешает. А вот в крупных компаниях frontend и mobile делает отдельная команда, и получается неудобно на каждую фичу просить backend команду вставить новый endpoint.
У них там свой график и план релизов, и из-за бюрократии становится сложно согласовать изменения/просить добавлять новые фичи.
В статье о этом не написано, но самое главное достоинство GraphQL именно в этом. Это ещё один стандартизированный QueryLanguage который позволяет получать все что нужно фронту не отвлекая бэк.
Да вроде не было хейта. Все проблемы связаны с апгрейдом, негатива к старому коду и к его разработчикам не видно
После массового внедрения цифровой фотографии ценность каждого снимка близка к нулю. Так-же и массовая генерация артов уничтожит ценность работ цифровых художников
Это вообще нормально что на обложке название книги написано с маленькой буквы?
Шикарно
Стыд = Страх ошибиться
Настоящий композитный хайтек так и выглядит, его буквально прядут из углепастиковой или стеклопластиковой пряжи с добавлением эпоксидки. И композитные баллоны держат большое давление, баллоны, например под метан, делают из композита
Вёревка могла намотаться позже, пока этот баллон плавал в море