Очень хочется вбросить одну тему для обсуждения и мне кажется тут самое подходящее место:
Вот смотрите, в современном "ООП на классах" наследование уже отменили, слава богам всё поняли что создание сильной связи между родителем и наследниками это источник постоянных проблем.
А давайте пойдем дальше и подумаем над инкапсуляцией. Вот смотрите, инкапсуляция в "ООП на классах" реализуется как глобальные переменные внутри класса. И в дальнейшем каждый метод класса использует эти глобальные переменные, т.е. не является чистой функцией. Тут есть явное противоречие современным методикам программирования которые утверждают что глобальные переменные это плохо и bad practice.
Это наследие не очень хорошего обучения программированию в постсоветских вузах где теорию ООП объясняли не дольше одной пары в терминах инкапсуляции, полиморфизма, наследования а дальше сразу переходили к C++
Не понимаю я эти попытки заменить прекрасный синтаксис Erlang-а на синтаксис другого языка. В итоге получаются какие-то франкенштейны где синтаксис Эрланга так и светит наружу этих костылей
Есть ощущение что чат интерфейсы это шаг назад, возврат во времена когда с компьютерами можно было общаться только посредством командой строки. Как будто из времени Windows возвращаемся во время DOS
Мне кажется в комментариях не все поняли новость и решили что новость о технологии отравления. А новость о том что действительно очень большому кол-ву человек не нравится что их произведения украли. А значит такой большой объем недовольства вполне может во что-то вылиться. Например, возникнет какой-нибудь прямой юридический запрет и генеративным нейросеткам придается напрямую лицензировать образцы для обучения, что приведёт к их стагнации
Почему вымерли карменные плееры, электронные книги и фотоаппараты-мыльницы? Потому что никто не хочет таскать 4 гаджета вместо одного.
Вы преувеличиваете сложность переноски, дело тут в другом. В какой-то момент телефон стал лучше выполнять задачи этих устройств и отдельные устройства стали просто не нужны.
Поражаюсь тому какая невероятная концентрация ультра хай тек технологий собрана в 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 который позволяет получать все что нужно фронту не отвлекая бэк.
Очень хочется вбросить одну тему для обсуждения и мне кажется тут самое подходящее место:
Вот смотрите, в современном "ООП на классах" наследование уже отменили, слава богам всё поняли что создание сильной связи между родителем и наследниками это источник постоянных проблем.
А давайте пойдем дальше и подумаем над инкапсуляцией. Вот смотрите, инкапсуляция в "ООП на классах" реализуется как глобальные переменные внутри класса. И в дальнейшем каждый метод класса использует эти глобальные переменные, т.е. не является чистой функцией. Тут есть явное противоречие современным методикам программирования которые утверждают что глобальные переменные это плохо и bad practice.
Как вам такое противоречие?
Это наследие не очень хорошего обучения программированию в постсоветских вузах где теорию ООП объясняли не дольше одной пары в терминах инкапсуляции, полиморфизма, наследования а дальше сразу переходили к C++
Не понимаю я эти попытки заменить прекрасный синтаксис Erlang-а на синтаксис другого языка. В итоге получаются какие-то франкенштейны где синтаксис Эрланга так и светит наружу этих костылей
Есть ощущение что чат интерфейсы это шаг назад, возврат во времена когда с компьютерами можно было общаться только посредством командой строки. Как будто из времени Windows возвращаемся во время DOS
Мне кажется в комментариях не все поняли новость и решили что новость о технологии отравления. А новость о том что действительно очень большому кол-ву человек не нравится что их произведения украли. А значит такой большой объем недовольства вполне может во что-то вылиться. Например, возникнет какой-нибудь прямой юридический запрет и генеративным нейросеткам придается напрямую лицензировать образцы для обучения, что приведёт к их стагнации
Вы преувеличиваете сложность переноски, дело тут в другом. В какой-то момент телефон стал лучше выполнять задачи этих устройств и отдельные устройства стали просто не нужны.
Поражаюсь тому какая невероятная концентрация ультра хай тек технологий собрана в 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 который позволяет получать все что нужно фронту не отвлекая бэк.
Да вроде не было хейта. Все проблемы связаны с апгрейдом, негатива к старому коду и к его разработчикам не видно