Если она плохо работает обращайтесь в техподдержку, шлите багрепорты, ставьте в копию администрацию школы и всякие департаменты образования.
Это не баг, это фича, проблема системная, а не ошибка интерфейса. И вообще - подход изначально странный, мы тут выкатим вам на всю страну - но если вам что-то не понравится - вы нам пишите, а сразу подумать - нее.
Когда все эти сферумы внедрялись - тоже был тихий ужас. Оно автоматом затягивало VK. Опять же всё заточено, один человек - одно личное устройство. А то что у людей один комп на всю семью, и один смарт на всю семью - тот, что у мамы, как-то не подумали. Единственный способ это нормально разрулить, а завести на одном компе разные аккаунты. Вопрос, кто из нормальных людей так делает?
А если говорить про косяки веб-интерфейса, то я как простой родитель, все опросы проходил. в поддержку писал. на всяких яндекс формах отметки делал. Тишина....
Как итог, несколько лет потребовалось, чтобы поправить пару самых тяжелых багов. Какие-то баги не правятся почему-то(например, отсутствие автовыбора региона, что так сложно прикопать в куку? через день у меня дневник разлогинивает, и нужно каждый раз выбирать область в web-версии, последние лет 5 - я методом скролла выбирал область, сейчас полез перепроверить насколько это долго, и там увидел поиск по региону, ура, столько лет потребовалось, чтобы добавить поиск по региону, я бы посмотрел бы глубже, регион надо сохранять на клиенте - можно, но зачем, видимо слишком много экранных форм за один раз, может быть ещё через 5 лет мы это увидим - а пока ребята страдайте или платите за приложение, там не разлогинивает).
Видимо web-версия живет по остаточному принципу....
я полностью согласен с вами, что полный откат назад невозможен.
я полностью согласен - централизованная система - штука хорошая, мне нравится как развивается проект "моя школа". Я там не совсем согласен, но в целом они прикольно начали. было б клево, если в один прекрасный момент дневник.ру выключили, а мою школу вместо нее включили б.
дневник.ру как оказалось не у всех, у Москвы свой дневник, у московской области свой. Так называемы МЭШ. Внезапно. И говорят, что оно лучше.
однако мне не нравится в дневнике.ру идеологически. то, что есть андройд-приложение, которое платное которое предполагает, что у каждого ребенка свое устройство и он в нем живет, т.е. пусть каждая семья платит ежемесячно денежку за возможность проверить домашнее задание. Если не хотите платить - вот вам web версия, которая косая, кривая, под телефон не заточена. Не хотите платить - страдайте.
системно процесс образования сломан, раньше было естественное физическое ограничение по передаче информации, сейчас ограничение ушло, но что с этим делать мы пока не придумали
получилось не очень кратко, но за ссылкой ещё больше букв и пара уточнений чуть ниже
Я не понимаю, как это, когда подготовленный к уроку учитель пришёл на урок и он не знает, что задать детям.
Я и не говорил, что учитель не знает. Очень уважаемый мной педагог моего ребенка говорила, что не хочет тратить на это время урока, лучше она его потратит на что-нибудь ещё полезное.
Повторюсь, педагог очень классный. Наверное, оно логично, в чем-то мысль понятна, я не согласен с таким подходом, и конкретно нам это было не удобно.
После школы ребенок идет в музыкальную школу, может идти на любой другой кружок. где-то время не совпадает и у ребенка окно от 40 минут до 2-х часов. Что ему в это время делать? Можно сделать уроки, но их нет, потому что даже если ДЗ будет выложено в дневник, у ребенка кнопочный телефон.
Усугублю, ребенок пришел из школы. ДЗ - нет, он не будет проверять каждые 5 минут, второй раз ДЗ он проверит, когда родители придут из школы. В итоге имеем то, что имеем, ДЗ начинается делаться ближе к ночи, а со временем оно перерастает в привычку. Старший ребенок, например, ходит весь день прокрастинирует, а ДЗ начинает делать в 8-9 вечера, потому что она привыкла делать уроки поздно и даже если уроки есть, собраться не может, это какой-то порочный круг. Я уже молчу про режим дня, прогулки, свежий воздух, нормальные часы сна, мы с малолетства гробим своих детей.
Ц - цифровизация нам в этом всем активно помогает, мы не становимся эффективней, мы постоянно тратим время куда-то не туда.
А ведь можно же иначе. Можно записать ДЗ на доске или вывести слайд - кому надо, переписываете или фотографируйте. Но по моему опыту так делают единицы из старой гвардии. Бывает такое - что ДЗ выкладывают сразу на неделю или месяц вперед.
Мы решали эти проблемы так - купили ребенку блокнот и учили его подходить к учителю и давать задание списать ему лично. Никто не отказывал. Но дети разные бывают, возможно, кто-то не пойдет. И учителя бывают загружены - могут отказать в этом вопросе.
происходит по-разному в зависимости от степени адекватности учителя.
Например, у младшего были дневники. Там они "шифр" писали. "П 25", что означает пропись страница 25.
Приходят молодые 19-летние учителя, у них по-другому. к второклассникам требования 5-6-клашек. там всё через электронные средства, а это ложится нагрузкой на родителя по достованию ДЗ непойми от куда каждый день.
Ведь нельзя просто так дат ребенку телефон и сказать, смотри ДЗ. он его не найдет. потому что 100-500 чатов, дневник.ру весь ограничениях, на этот день ДЗ поставить нельзя. поставим на понедельник, но в самом ДЗ напишем, что это к четвергу. Это ж надо додуматься, чтобы проскролить до следующей недели.
У меня трое школьников. очень много времени уходит, чтобы просто выписать домашку. в дневнике её даже распечатать нельзя, там другой паттерн, паттерн личного, каждый предмет выбирается отдельно и протыкивается.
А всё с родительского аккаунта, а потом учителя на собрании заявляют, что а чего это вы с детских аккаунтов не ходите, ну ка давайте ходите....
Бумажный дневник не запретили, а сняли с учителя обязанность его проверять, следить за тем, что в него что-то пишут, ставить оценки в дневник и за ведение дневника и так далее. А если обязанности нет, дневник вести можно, но зачем... А я скажу зачем - дневник - это навык ведения ежедневника. Ежедневник должен быть доступен всегда, а не где-то там в облаке на устройстве, в котором стоит родительский контроль. Цифровизация образования - это худшее, что с ним произошло за последние 20 нет. К сожалению, мы можем только ностальгировать. Отыграть назад не получится. Люди уже привыкли к расхлябанности. Если учитель что-то забыл задать, то он может скорректировать ДЗ в любое время. Если раньше и стационарный телефон - был роскошью, то теперь у каждого есть такая коробочка, а значит возможность отправить группе людей сообщение. Это в корне бьет по любому распорядку дня. Апогеем можно считать, например, присланное ДЗ в воскресение вечером, когда все заданные уроки были сделаны в пятницу и семья уехала, а потом, вернувшись поздно вечером обнаруживает, что спать ребенок ляжет сильно позже. К сожалению, многое молодые учителя так делают. Учителя по старше честно признаются - дз будет в субботу, а в будни после 3-х или даже 5. Что должен делать ребенок до этого времени - вопрос, уроки вечно уносятся на вечер, иногда на поздний вечер. На погулять времени не остаётся. В таких условиях лучшем решением это безобразие возглавить - дать людям хороший инструмент и не отменять бумажные носители. К сожалению этот момент проспали, на арену вышли региональные софтины, а потом когда ребята из дневника.ру захватили всё кругом, всех обязали перейти на это форменное безобразие. Дневник.ру ненавидят ВСЕ:
учителя - потому что он добавляет тучу "бумажной" работы
родители - потому что за него надо платить и он откровенно не удобен. Там упор идет на статистику - какой ты в классе, а не на удобство и качество приложения. Web-версия - вообще караул, больше на порно-сайт смахивает.
сами разработчики - потому что такое наплевательское отношение к своему результату работы я давно не видел.
сами дети - потому что их всё достало. Для меня руководители дневника.ру - злобные ворюги, их цель деньги, а не результат. Один платный просмотр дз чего стоит. Дружно хлопаем в ладоши. Привет другим деньго-стригам.
А последний месяц стало всё ещё хуже. ребята госслужащие стали через дневник.ру вмешиваться в составление расписания. Типа не ставь платные занятия вместе с бесплатными, а ещё лучше в их дневник платные не вносите вообще. Это привело к тому, что единственное правильное расписание написано на бумаге в коридоре школы. Дневников нет, в приложении половина уроков нет, а по факту они проводятся. По учителям и кабинетам в таком виде не разложить, а значит мы съехали с 5-дневки на 6-дневку. Внезапно.
Что с этим делать? Да ничего тут не сделаешь. Я учу своих детей по возможности писать дз в блокнотик, а если оно нужно раньше - подходить к учителю и просить дз сразу. Что поделать, если школа не хочет учить детей учиться(а министерство образование тоже в этом вопросе активно мешает). Приходится как-то самому корректировать образовательный процесс...
Я могу часами говорить - какое же дневник.ру дерьмо. извините, наболело.
Забавно, но я не понял - зачем ещё один мессенждер?
Посмотрите, сколько корпоративных мессенджеров наклепано в рамках испортозамещения. всякие пачки, экпрессы... их туча. Сделать мессенджер - не проблема, всё упирается в железо.
если хочется видеозвонки как-то отдельно от max и прочих, можно поднять свой мессенджер у себя дома. Из западного опенсоурсного это nextcloud talk. из нашего - труконф. кстати, поднял последний у себя на celeron 2011 года. звоню, маме, детям, жене. качество картинки огонь, работает лучше чем макс. а всё почему, потому что я там один и ни с кем особо не делю ресурсы.
Вы ненавидели писать тесты не потому, что они были бессмысленными. Вы ненавидели их потому, что они были сложными и не казались продуктивными.
Хорошо написано, потому что мне тоже часто бывает тяжело себя заставить. Потому что тесты - это часть кода и часть документации к коду, который ещё не написан. В целом было б прикольно, если б ИИ генерил бы какую-то шаблонку, по которой можно было б написать такие тесты. Ихмо, будет потрачено не мало времени для создания такого запроса для ИИ, чтобы шаблонка была б хоть сколько нибудь внятная. Уж проще самому сесть написать. Хотя, возможно, я отстал от жизни...
На проблему автогенериции тестов я бы поглядел бы под другим углом. До сих пор есть много разрабов, которые пишут тесты постфактум, потому что на ревью пришли и сказали, а где тесты, и вот они их пишут. А теперь ещё пишут при помощи ИИ. Как "посттесты", написанные руками, так и через ИИ - они являются мусором и фактически бесполезны, а чаще всего вредны, т.к. легко впитывают в себя классические антипатерны, например, хрупкость.
Это не проблема ИИ, это проблема уровня разработчика, а ИИ просто ухудшает ситуацию, потому что разраб сам не умел писать тесты, но попросил это сделать ИИ и получилось то, что получилось - т.е. одни сплошные проблемы.
Вообще-то были, назывались анонимные интерфейсы. Современные лямбды - технически - это тоже классы с одним методом, просто добавился легкий синтаксический сахар в угоду модной сейчас функциональщине.
Технически можно было б спроектировать такие API с дефолтными обработчиками.
Проблема в другом, классный механизм обрабатываемых исключений начали использовать неправильно. Подход, что все возможные исключения надо обрабатывать здесь и сейчас слишком активно стали использовать. ИХМО, проблема не в самом подходе, а в ООП-мышлении, а точнее в его отсутствии. А так же в отсутствии навыков проектирования и шлифовки кода у большинства разработчиков в том числе у разработчиков java API.
Пример, мне надо прочесть файл, может так случиться, что файла нет на диске и надо писать код обработки этой ситуации. Однако файл я читаю classpath-а, его не может не быть. Получается я должен написать код, который никогда не выполнится. Я даже тестами его покрыть не могу, но написать его обязан. Что мешало разработчикам API с файлами написать какой-нибудь декоратор, или дефолтный обработчик ошибок, или применить паттерн NULL-Object? Просто проектировщики java File API этого не учли.
Другой пример, появление библиотеки Spring Jdbc и классного класса JdbcTemplate, который решал проблему утечки коннекшенов к базе на серверах приложений в случае исключений при выполнении SQL запросов. Перво-причина - плохо продуманное SQL API. Это было ещё до 7-ой java, в 7-ой для решения этой проблемы ввели Closable.
Теперь про SneakyThrows - в хорошем проекте её нет, либо использование сведено к минимуму. Потому что уже давным давно написано 100-500 декораторов, которые уже решают эту проблему. Редкий-редкий случай, когда надо что-то руками обрабатывать. Либо это совсем легаси. И тут уже на весы становится простота и лаконичность кода, либо пилить ещё один декоратор с обработчиками. В этом плане SneakyThrows уже не кажется такой ужасной, но причина её поставить должна быть очень веской. Повторюсь, при грамотном подходе их будет мало либо вообще не будет по причинам описанным выше.
Красивая идея описать всё, как медицинское заболевание. Посмеялся, плюсанул.
А если серьезно, в одном из комментариев выше промелькнула мысль о том, что паттерны надо уметь применять, что есть задача, и есть её стандартное решение, которое опробовано практикой. А так же была другая мысль, о том, что сильно всё зависит от проекта, где-то надо делать проще, а где-то заложиться. Все эти мысли правильные.
Добавлю ещё 5 копеек, лет 10 назад в одном из выступлений архитекторов ПО встретил редкий термин "оси вариативности"(честно, не нашел откуда он его взял, но термин мне понравился). Вся суть в том, что должна быть какая-то чуйка, понимание бизнес-задач, когда и где нужно заложиться в плане универсальности(заложить абстракцию, сделать стратегию, т.д. и т.п.), а где лучше сделать проще. И от того, насколько мы угадали зависит сложность получившегося ПО. Либо всё клево, часть работы мы сделали заранее(и сэкономили итерацию рефакторинга), либо избыточная сложность усложняет тесты, усложняет реализацию фич и всюду мешается и приводит в конечном случае к не стабильности ПО.
Вот как раз "ООП головного мозга", является прямым следствием непонимания что будет делать ваше ПО. Лечить его нужно не функциональным стилем, а прокачиванием совсем других скилов...
По поводу того, а чем заменить. Да чем угодно. Есть много хороших штук.
Spring Data Jdbc - остановились на нем в связке с базой на PG. Используем на третьем проекте в течении нескольких лет. Да, и к нему тоже есть вопросы. Какие-то вещи делаем через лайф-хаки. Есть баги. Есть явные глупости. Но всё же. Если, вдруг, что-то он не сможет, всегда есть возможность написать кастомный RowMapper.
Посыл правильный - Hiber устарел. ему давно пора на свалку истории.
Но с аргументацией проблемы.
Например, я не понял, чем плох Entity (точнее, я знаю, что там не так, но в статье про это не говорится).
Чем плох flyway? Чем плох рефлекшен и рантайм? проверять качество работы c SQL кроме как в рантайм не где.
Про проблемы работы с вложенными сущностями - ничего нет.
Про проблемы работы с кешем 2 уровня - ничего нет.
Про проблемы работы с java классами - тоже ничего нет.
Дальше, критикуются генерируемые методы в интерфейсах, но это не Hiber и не JPA, это spring data. Это другой фреймворк, на базе его есть Spring Data JDBC или Spring Data Mongo. Ну кто-то написал дикий г-код, мы же не критикуем за это язык программирования?
Дальше, чем не угодили слои приложения. Отделяйте мух от котлет, в хорошей крупной системе слои приложения очень даже нужны. Да, пример из спринга - плохой с точки зрения. ну давайте будем честными, многое в спринге написано отвратительно. Он не ОПП, не SOLID, а лишь имитирует их. Ну и что. Странно...
Итого, чтобы не было недомолвок. Я считаю, что на spring data jpa можно собрать приятный достойный проект. Но очень много старой функциональности, которая уже сильно устарела и надо сильно думать, что из JPA стоит использовать, а что пора выкинуть. Лично мне не нравится JPA с точки зрения парадигмы. На своих проектах, где я влияю на выбор технологий, я стараюсь его не использовать.
>>Вынесение метода, нужного в одном месте конкретного сервиса, на уровень сущности, по-моему, лишнее.
Этот метод работает с данными сущности и на основе этого принимает какие-то решения, генерирует какие-то события. Вообще-то это называется инкапсуляция. В реальной жизни, эти методы не слабо так разбухают (хотя есть и достаточно компактные). Мы на эти методы пишем свои отдельные тесты, а на сервис свои.
Термин "умные объекты" здесь ввел не я, а один из комментаторов. Если есть умные объекты - должны быть и тупые. Что из них что, до конца не понятно, в какой момент тупой объект умнеет?
Мне ближе понятие обычных объектов, которые предполагают объектно-ориентированный стиль мышления. А ещё есть структуры данных и анемичные модели, которые автор этого термина называет антипаттерном.
А что вы понимали под умными объектами?
Чем ваш подход размещения бизнес логики в сервисе отличается от классического transaction script?
полностью согласен. Я запрещаю на своих проектах его совсем. Однако, повторюсь, не все проекты мои, не везде я лидер, статья больше - вариант компромисса с людьми, которым удобно, и они не готовы с ним расставаться.
Однако, всё же хочу отметить, если стараться, не усердствовать и следовать правилам(например, этим), а так же здравому смыслу, то в целом код получается достаточно элегантным.
>>пропагандирующему "просто другой подход, Entity - это умный объект, со своими методами".
Я его не пропагандирую, я на нем пишу. Года этак с 2010. Для полного погружения в тему советую почитать Фаулера, а этак же что-нибудь на тему DDD (кстати, там в комментариях, люди неплохие ссылки нагнали, т.к. у Эванса - во-первых, очень много воды, во-вторых, слегка устаревшие примеры, так сейчас уже никто не пишет, технологии сильно поменялись, в-третьих, прямо скажу, очень тяжелый язык повествования, я бы эту книгу догонял бы под конец, чтобы добавить мелкий штришки к общей мозаике).
Это немножко не тема данной статьи, но давайте, посмотрим ваш пример. Нужно уточниться. Я так понимаю, сервис синхронный. Предположим, это ещё и сервис высокой доступности.
Примерно код может выглядеть так.
import org.springframework.context.ApplicationEventPublisher;
@Service
@Transactional
@RequiredArgsConstructor
public class UserServiceImpl implements UserService {
private final GosUslugiClient gosUslugiClient;
private final UserRepository repository;
private final ApplicationEventPublisher eventPublisher;
public User checkFio(UUID userId) {
final var user = repository.findById(userId).orElseThrow(() -> new UserNotFoundException(userId));
// дергаем сторонний сервис
// предположим, сервис не доступен, ихмо тут клиент выкидывает
// эксепшен, а пользак или кто там снаружи, потом нажмет кнопочку ещё раз
// если ненайдено - пустой результат
final Optional<GosuslugiPersonDto> personDto = gosUslugiClient.findFio(user.snils());
// здесь передаем результат в доменную модель, которая сама
// решит, как с ними поступить, и на основе своих действий
// может сформировать одно или несколько событий
// есть у меня один проект, где я этот вызов оформил функцией,
// чтобы не получить GodObject из цетрального сервиса, т.к. там
// очень много интеграций, тогда получаем много сервисов-интеграций,
// который инжектят в себя клиент и условный UserService.
// Решение с функцией очень понравилось, т.к. ушел от тучи
// тупого кода, и всё на своих местах
final var event = user.verifyData(personDto);
repository.save(user);
// spring-event, чтобы обеспечить слабую связанность между сервисами,
// например, метод доменной модели формирует событие, что
// данные были обновлены (или не формирует, как повезет)
// мы публикуем это событие, а него могут быть сервисы-подписчики,
// которые, например, разошлют почту/смс - о том, о чем нужно.
// при этом, если мы не уйдем в асинхронность(или в реальные события
// - а там и до event driven development - один шаг),
// всё это будет в одной транзакции и если подписчик по какой-то
// причине развалится, то произойдет откат всей операции
// здесь очень один тонкий момент, какие вызовы нужно делать явно,
// а какие утаскивать в события:
// - перетащишь всё что только можно в сервис, там и до GodObject не далеко
// - будешь увлекаться событиями - получишь, тяжелую
// поддержку и непонимание разработчиков что произошло
// и в каком событии(потому что, чтобы такое поддерживать, нужно очень
// глубокое погруженые в бизнес-процессы, а тут через полгода приходишь
// на проект пару багов поправить и сам забыл, что там и где.).
// А цепочек из 2-х и более событий (когда обработчик события
// генерит свои события) вообще лучше не допускать
// для себя выработал подход, в события выносим то, что
// напрямую не меняет текущую модель, а является чем-то
// второстепенным
// например,
// -- результат вызова - нужно сохранить в модель, это в событие нельзя.
// -- вызов формирует какой-то запрос - а ответ, приходит асинхронно.
// Такое тоже в событие нельзя (или иногда можно, но очень аккуратно
// с полным пониманием процесса). Высокий риск, что асинхронный ответ
// придет до того, как будет закрыта основная транзакция, получим
// просто конфликт версий при закрытии транзакции, т.к. та же кафка шустрая
eventPublisher.publishEvent(event);
}
}
А теперь усложнимся, и вернемся к самому первому вопросу, на который я побоялся сразу развернуто отвечать, но раз вы проявили заинтересованность, то попробую крупными штрихами. Вы говорили, что дергаете сразу 4 сервиса. Это слишком много, если они все синхронные, то каждый из них под нагрузкой будет подтупливать. Например, в легком режиме, один сервис отвечает 0.5 секунды, но иногда он отвечает 10-15 секунд. Если таких 4, то мы уже получаем 40-60 секунд, а это как минимум слабая отзывчивость синхронного сервиса, как максимум таймауты.
А если вы дернули 3, а 4-й упал? получается, вы первые 3 дернули зря, т.к. просто забыли их данные.
А ещё могут быть интеграции, которые не считывают данные, а запускают какие-то процессы, а тут уже до SAGA рукой подать, а это то ещё усложнение системы в целом. Ихмо, если можно уйти от SAGA, то лучше от него уйти, и подальше, сложностей на проекте и так хватит, зачем ещё усложнять.
ИХМО, в этих случаях стоит пересмотреть общую архитектуру этих интеграций, например, разбивать их на этапы, с сохранением промежуточных результатов, что в свою очередь поменяет вашу статусную модель, и так далее... Кажется, я открыл ящик пандоры, тема очень глубокая...
нет, про доменные модели. Комментатор выше утверждает, что если объекты умные, то ломбок тут применять не нужно. по крайней мере вот эту фразу - "Если у вас другой подход (с иной логикой, которая подразумевает умные объекты, инкапсулирующие свое поведение) - ломбок не про это" я понял именно так.
>> Всю статью не покидало ощущение, что очередная борьба за качество кода.
так и есть.
>>Вызов был воткнут в класс нарушавший все буквы в SOLID . Буквально.
Ну и нормально. Есть другая крайность, тупое следование всем принципам. Я тоже иногда осознанно игнорирую что-нибудь из SOLID в угоду простоте, читаемости, качеству. Тут чуйка какая-то должна быть. Наверное, оно вырабатывается с опытом.
Кстати, она не плохо срабатывает во время дебатов внутри команды. По-обсуждаем, а потом получается сильно лучше, чем когда один писал.
>>В общем код на голову лучше чем там где борятся...
Однозначно да. А чтобы не бояться, нужно через TDD писать. Если код покрыт качественно тестами, бояться не чего. Другое дело, писать их тоже надо уметь.
Это не баг, это фича, проблема системная, а не ошибка интерфейса. И вообще - подход изначально странный, мы тут выкатим вам на всю страну - но если вам что-то не понравится - вы нам пишите, а сразу подумать - нее.
Когда все эти сферумы внедрялись - тоже был тихий ужас. Оно автоматом затягивало VK. Опять же всё заточено, один человек - одно личное устройство. А то что у людей один комп на всю семью, и один смарт на всю семью - тот, что у мамы, как-то не подумали. Единственный способ это нормально разрулить, а завести на одном компе разные аккаунты. Вопрос, кто из нормальных людей так делает?
А если говорить про косяки веб-интерфейса, то я как простой родитель, все опросы проходил. в поддержку писал. на всяких яндекс формах отметки делал. Тишина....
Как итог, несколько лет потребовалось, чтобы поправить пару самых тяжелых багов. Какие-то баги не правятся почему-то(например, отсутствие автовыбора региона, что так сложно прикопать в куку? через день у меня дневник разлогинивает, и нужно каждый раз выбирать область в web-версии, последние лет 5 - я методом скролла выбирал область, сейчас полез перепроверить насколько это долго, и там увидел поиск по региону, ура, столько лет потребовалось, чтобы добавить поиск по региону, я бы посмотрел бы глубже, регион надо сохранять на клиенте - можно, но зачем, видимо слишком много экранных форм за один раз, может быть ещё через 5 лет мы это увидим - а пока ребята страдайте или платите за приложение, там не разлогинивает).
Видимо web-версия живет по остаточному принципу....
Вот здесь филосовстовал по этому поводу https://habr.com/ru/articles/1022914/#comment_29835828
Там очень много букв, если кратко:
я полностью согласен с вами, что полный откат назад невозможен.
я полностью согласен - централизованная система - штука хорошая, мне нравится как развивается проект "моя школа". Я там не совсем согласен, но в целом они прикольно начали. было б клево, если в один прекрасный момент дневник.ру выключили, а мою школу вместо нее включили б.
дневник.ру как оказалось не у всех, у Москвы свой дневник, у московской области свой. Так называемы МЭШ. Внезапно. И говорят, что оно лучше.
однако мне не нравится в дневнике.ру идеологически. то, что есть андройд-приложение, которое платное которое предполагает, что у каждого ребенка свое устройство и он в нем живет, т.е. пусть каждая семья платит ежемесячно денежку за возможность проверить домашнее задание. Если не хотите платить - вот вам web версия, которая косая, кривая, под телефон не заточена. Не хотите платить - страдайте.
системно процесс образования сломан, раньше было естественное физическое ограничение по передаче информации, сейчас ограничение ушло, но что с этим делать мы пока не придумали
получилось не очень кратко, но за ссылкой ещё больше букв и пара уточнений чуть ниже
Я и не говорил, что учитель не знает. Очень уважаемый мной педагог моего ребенка говорила, что не хочет тратить на это время урока, лучше она его потратит на что-нибудь ещё полезное.
Повторюсь, педагог очень классный. Наверное, оно логично, в чем-то мысль понятна, я не согласен с таким подходом, и конкретно нам это было не удобно.
После школы ребенок идет в музыкальную школу, может идти на любой другой кружок. где-то время не совпадает и у ребенка окно от 40 минут до 2-х часов. Что ему в это время делать? Можно сделать уроки, но их нет, потому что даже если ДЗ будет выложено в дневник, у ребенка кнопочный телефон.
Усугублю, ребенок пришел из школы. ДЗ - нет, он не будет проверять каждые 5 минут, второй раз ДЗ он проверит, когда родители придут из школы. В итоге имеем то, что имеем, ДЗ начинается делаться ближе к ночи, а со временем оно перерастает в привычку. Старший ребенок, например, ходит весь день прокрастинирует, а ДЗ начинает делать в 8-9 вечера, потому что она привыкла делать уроки поздно и даже если уроки есть, собраться не может, это какой-то порочный круг. Я уже молчу про режим дня, прогулки, свежий воздух, нормальные часы сна, мы с малолетства гробим своих детей.
Ц - цифровизация нам в этом всем активно помогает, мы не становимся эффективней, мы постоянно тратим время куда-то не туда.
А ведь можно же иначе. Можно записать ДЗ на доске или вывести слайд - кому надо, переписываете или фотографируйте. Но по моему опыту так делают единицы из старой гвардии. Бывает такое - что ДЗ выкладывают сразу на неделю или месяц вперед.
Мы решали эти проблемы так - купили ребенку блокнот и учили его подходить к учителю и давать задание списать ему лично. Никто не отказывал. Но дети разные бывают, возможно, кто-то не пойдет. И учителя бывают загружены - могут отказать в этом вопросе.
происходит по-разному в зависимости от степени адекватности учителя.
Например, у младшего были дневники. Там они "шифр" писали. "П 25", что означает пропись страница 25.
Приходят молодые 19-летние учителя, у них по-другому. к второклассникам требования 5-6-клашек. там всё через электронные средства, а это ложится нагрузкой на родителя по достованию ДЗ непойми от куда каждый день.
Ведь нельзя просто так дат ребенку телефон и сказать, смотри ДЗ. он его не найдет. потому что 100-500 чатов, дневник.ру весь ограничениях, на этот день ДЗ поставить нельзя. поставим на понедельник, но в самом ДЗ напишем, что это к четвергу. Это ж надо додуматься, чтобы проскролить до следующей недели.
У меня трое школьников. очень много времени уходит, чтобы просто выписать домашку. в дневнике её даже распечатать нельзя, там другой паттерн, паттерн личного, каждый предмет выбирается отдельно и протыкивается.
А всё с родительского аккаунта, а потом учителя на собрании заявляют, что а чего это вы с детских аккаунтов не ходите, ну ка давайте ходите....
Бумажный дневник не запретили, а сняли с учителя обязанность его проверять, следить за тем, что в него что-то пишут, ставить оценки в дневник и за ведение дневника и так далее. А если обязанности нет, дневник вести можно, но зачем...
А я скажу зачем - дневник - это навык ведения ежедневника. Ежедневник должен быть доступен всегда, а не где-то там в облаке на устройстве, в котором стоит родительский контроль. Цифровизация образования - это худшее, что с ним произошло за последние 20 нет.
К сожалению, мы можем только ностальгировать. Отыграть назад не получится. Люди уже привыкли к расхлябанности. Если учитель что-то забыл задать, то он может скорректировать ДЗ в любое время. Если раньше и стационарный телефон - был роскошью, то теперь у каждого есть такая коробочка, а значит возможность отправить группе людей сообщение. Это в корне бьет по любому распорядку дня.
Апогеем можно считать, например, присланное ДЗ в воскресение вечером, когда все заданные уроки были сделаны в пятницу и семья уехала, а потом, вернувшись поздно вечером обнаруживает, что спать ребенок ляжет сильно позже. К сожалению, многое молодые учителя так делают. Учителя по старше честно признаются - дз будет в субботу, а в будни после 3-х или даже 5. Что должен делать ребенок до этого времени - вопрос, уроки вечно уносятся на вечер, иногда на поздний вечер. На погулять времени не остаётся.
В таких условиях лучшем решением это безобразие возглавить - дать людям хороший инструмент и не отменять бумажные носители. К сожалению этот момент проспали, на арену вышли региональные софтины, а потом когда ребята из дневника.ру захватили всё кругом, всех обязали перейти на это форменное безобразие.
Дневник.ру ненавидят ВСЕ:
учителя - потому что он добавляет тучу "бумажной" работы
родители - потому что за него надо платить и он откровенно не удобен. Там упор идет на статистику - какой ты в классе, а не на удобство и качество приложения. Web-версия - вообще караул, больше на порно-сайт смахивает.
сами разработчики - потому что такое наплевательское отношение к своему результату работы я давно не видел.
сами дети - потому что их всё достало. Для меня руководители дневника.ру - злобные ворюги, их цель деньги, а не результат. Один платный просмотр дз чего стоит. Дружно хлопаем в ладоши. Привет другим деньго-стригам.
А последний месяц стало всё ещё хуже. ребята госслужащие стали через дневник.ру вмешиваться в составление расписания. Типа не ставь платные занятия вместе с бесплатными, а ещё лучше в их дневник платные не вносите вообще. Это привело к тому, что единственное правильное расписание написано на бумаге в коридоре школы. Дневников нет, в приложении половина уроков нет, а по факту они проводятся. По учителям и кабинетам в таком виде не разложить, а значит мы съехали с 5-дневки на 6-дневку. Внезапно.
Что с этим делать? Да ничего тут не сделаешь. Я учу своих детей по возможности писать дз в блокнотик, а если оно нужно раньше - подходить к учителю и просить дз сразу.
Что поделать, если школа не хочет учить детей учиться(а министерство образование тоже в этом вопросе активно мешает). Приходится как-то самому корректировать образовательный процесс...
Я могу часами говорить - какое же дневник.ру дерьмо. извините, наболело.
за тему с Self-hosted - лайкнул. когда сделаете, посмотрю на вас повнимательней. Конкуренция с тем же труконфом не помешает. Желаю вам развития.
PS: у вас же будет версия сервера для arm64 ?
PS2: картинка с девушкой и ласточкой - прикольная.
Забавно, но я не понял - зачем ещё один мессенждер?
Посмотрите, сколько корпоративных мессенджеров наклепано в рамках испортозамещения. всякие пачки, экпрессы... их туча. Сделать мессенджер - не проблема, всё упирается в железо.
если хочется видеозвонки как-то отдельно от max и прочих, можно поднять свой мессенджер у себя дома. Из западного опенсоурсного это nextcloud talk. из нашего - труконф. кстати, поднял последний у себя на celeron 2011 года. звоню, маме, детям, жене. качество картинки огонь, работает лучше чем макс. а всё почему, потому что я там один и ни с кем особо не делю ресурсы.
где бы ещё живое устройство с авророй найти. простым смертным данная фича не доступна.
Хорошо написано, потому что мне тоже часто бывает тяжело себя заставить. Потому что тесты - это часть кода и часть документации к коду, который ещё не написан. В целом было б прикольно, если б ИИ генерил бы какую-то шаблонку, по которой можно было б написать такие тесты. Ихмо, будет потрачено не мало времени для создания такого запроса для ИИ, чтобы шаблонка была б хоть сколько нибудь внятная. Уж проще самому сесть написать. Хотя, возможно, я отстал от жизни...
На проблему автогенериции тестов я бы поглядел бы под другим углом. До сих пор есть много разрабов, которые пишут тесты постфактум, потому что на ревью пришли и сказали, а где тесты, и вот они их пишут. А теперь ещё пишут при помощи ИИ. Как "посттесты", написанные руками, так и через ИИ - они являются мусором и фактически бесполезны, а чаще всего вредны, т.к. легко впитывают в себя классические антипатерны, например, хрупкость.
Это не проблема ИИ, это проблема уровня разработчика, а ИИ просто ухудшает ситуацию, потому что разраб сам не умел писать тесты, но попросил это сделать ИИ и получилось то, что получилось - т.е. одни сплошные проблемы.
Но зато отчетик по покрытию кода будет красивый.
Вообще-то были, назывались анонимные интерфейсы. Современные лямбды - технически - это тоже классы с одним методом, просто добавился легкий синтаксический сахар в угоду модной сейчас функциональщине.
Технически можно было б спроектировать такие API с дефолтными обработчиками.
Проблема в другом, классный механизм обрабатываемых исключений начали использовать неправильно. Подход, что все возможные исключения надо обрабатывать здесь и сейчас слишком активно стали использовать. ИХМО, проблема не в самом подходе, а в ООП-мышлении, а точнее в его отсутствии. А так же в отсутствии навыков проектирования и шлифовки кода у большинства разработчиков в том числе у разработчиков java API.
Пример, мне надо прочесть файл, может так случиться, что файла нет на диске и надо писать код обработки этой ситуации. Однако файл я читаю classpath-а, его не может не быть. Получается я должен написать код, который никогда не выполнится. Я даже тестами его покрыть не могу, но написать его обязан. Что мешало разработчикам API с файлами написать какой-нибудь декоратор, или дефолтный обработчик ошибок, или применить паттерн NULL-Object? Просто проектировщики java File API этого не учли.
Другой пример, появление библиотеки Spring Jdbc и классного класса JdbcTemplate, который решал проблему утечки коннекшенов к базе на серверах приложений в случае исключений при выполнении SQL запросов. Перво-причина - плохо продуманное SQL API. Это было ещё до 7-ой java, в 7-ой для решения этой проблемы ввели Closable.
Теперь про SneakyThrows - в хорошем проекте её нет, либо использование сведено к минимуму. Потому что уже давным давно написано 100-500 декораторов, которые уже решают эту проблему. Редкий-редкий случай, когда надо что-то руками обрабатывать. Либо это совсем легаси. И тут уже на весы становится простота и лаконичность кода, либо пилить ещё один декоратор с обработчиками. В этом плане SneakyThrows уже не кажется такой ужасной, но причина её поставить должна быть очень веской. Повторюсь, при грамотном подходе их будет мало либо вообще не будет по причинам описанным выше.
предлагают один KPI, заменить другим. По мне все вы одинаковы.
Красивая идея описать всё, как медицинское заболевание. Посмеялся, плюсанул.
А если серьезно, в одном из комментариев выше промелькнула мысль о том, что паттерны надо уметь применять, что есть задача, и есть её стандартное решение, которое опробовано практикой. А так же была другая мысль, о том, что сильно всё зависит от проекта, где-то надо делать проще, а где-то заложиться. Все эти мысли правильные.
Добавлю ещё 5 копеек, лет 10 назад в одном из выступлений архитекторов ПО встретил редкий термин "оси вариативности"(честно, не нашел откуда он его взял, но термин мне понравился). Вся суть в том, что должна быть какая-то чуйка, понимание бизнес-задач, когда и где нужно заложиться в плане универсальности(заложить абстракцию, сделать стратегию, т.д. и т.п.), а где лучше сделать проще. И от того, насколько мы угадали зависит сложность получившегося ПО. Либо всё клево, часть работы мы сделали заранее(и сэкономили итерацию рефакторинга), либо избыточная сложность усложняет тесты, усложняет реализацию фич и всюду мешается и приводит в конечном случае к не стабильности ПО.
Вот как раз "ООП головного мозга", является прямым следствием непонимания что будет делать ваше ПО. Лечить его нужно не функциональным стилем, а прокачиванием совсем других скилов...
Разбирал почту, увидел комментарии, поэтому отвечаю только сейчас )))
Ниже есть замечательнейший комментарий, который заменяет почти всю статью. Я бы даже свапнул, комментарий в статью, а статью в комментарий. https://habr.com/ru/articles/860038/comments/#comment_27604776
По поводу того, а чем заменить. Да чем угодно. Есть много хороших штук.
Spring Data Jdbc - остановились на нем в связке с базой на PG. Используем на третьем проекте в течении нескольких лет. Да, и к нему тоже есть вопросы. Какие-то вещи делаем через лайф-хаки. Есть баги. Есть явные глупости. Но всё же. Если, вдруг, что-то он не сможет, всегда есть возможность написать кастомный RowMapper.
Замечание - просто огонь. Большушее вам спасибо за этот комментарий.
Посыл правильный - Hiber устарел. ему давно пора на свалку истории.
Но с аргументацией проблемы.
Например, я не понял, чем плох Entity (точнее, я знаю, что там не так, но в статье про это не говорится).
Чем плох flyway? Чем плох рефлекшен и рантайм? проверять качество работы c SQL кроме как в рантайм не где.
Про проблемы работы с вложенными сущностями - ничего нет.
Про проблемы работы с кешем 2 уровня - ничего нет.
Про проблемы работы с java классами - тоже ничего нет.
Дальше, критикуются генерируемые методы в интерфейсах, но это не Hiber и не JPA, это spring data. Это другой фреймворк, на базе его есть Spring Data JDBC или Spring Data Mongo. Ну кто-то написал дикий г-код, мы же не критикуем за это язык программирования?
Дальше, чем не угодили слои приложения. Отделяйте мух от котлет, в хорошей крупной системе слои приложения очень даже нужны. Да, пример из спринга - плохой с точки зрения. ну давайте будем честными, многое в спринге написано отвратительно. Он не ОПП, не SOLID, а лишь имитирует их. Ну и что. Странно...
Итого, чтобы не было недомолвок. Я считаю, что на spring data jpa можно собрать приятный достойный проект. Но очень много старой функциональности, которая уже сильно устарела и надо сильно думать, что из JPA стоит использовать, а что пора выкинуть. Лично мне не нравится JPA с точки зрения парадигмы. На своих проектах, где я влияю на выбор технологий, я стараюсь его не использовать.
>>Вынесение метода, нужного в одном месте конкретного сервиса, на уровень сущности, по-моему, лишнее.
Этот метод работает с данными сущности и на основе этого принимает какие-то решения, генерирует какие-то события. Вообще-то это называется инкапсуляция. В реальной жизни, эти методы не слабо так разбухают (хотя есть и достаточно компактные). Мы на эти методы пишем свои отдельные тесты, а на сервис свои.
Термин "умные объекты" здесь ввел не я, а один из комментаторов. Если есть умные объекты - должны быть и тупые. Что из них что, до конца не понятно, в какой момент тупой объект умнеет?
Мне ближе понятие обычных объектов, которые предполагают объектно-ориентированный стиль мышления. А ещё есть структуры данных и анемичные модели, которые автор этого термина называет антипаттерном.
А что вы понимали под умными объектами?
Чем ваш подход размещения бизнес логики в сервисе отличается от классического transaction script?
полностью согласен. Я запрещаю на своих проектах его совсем. Однако, повторюсь, не все проекты мои, не везде я лидер, статья больше - вариант компромисса с людьми, которым удобно, и они не готовы с ним расставаться.
Однако, всё же хочу отметить, если стараться, не усердствовать и следовать правилам(например, этим), а так же здравому смыслу, то в целом код получается достаточно элегантным.
>>пропагандирующему "просто другой подход, Entity - это умный объект, со своими методами".
Я его не пропагандирую, я на нем пишу. Года этак с 2010. Для полного погружения в тему советую почитать Фаулера, а этак же что-нибудь на тему DDD (кстати, там в комментариях, люди неплохие ссылки нагнали, т.к. у Эванса - во-первых, очень много воды, во-вторых, слегка устаревшие примеры, так сейчас уже никто не пишет, технологии сильно поменялись, в-третьих, прямо скажу, очень тяжелый язык повествования, я бы эту книгу догонял бы под конец, чтобы добавить мелкий штришки к общей мозаике).
Это немножко не тема данной статьи, но давайте, посмотрим ваш пример. Нужно уточниться. Я так понимаю, сервис синхронный. Предположим, это ещё и сервис высокой доступности.
Примерно код может выглядеть так.
А теперь усложнимся, и вернемся к самому первому вопросу, на который я побоялся сразу развернуто отвечать, но раз вы проявили заинтересованность, то попробую крупными штрихами. Вы говорили, что дергаете сразу 4 сервиса. Это слишком много, если они все синхронные, то каждый из них под нагрузкой будет подтупливать. Например, в легком режиме, один сервис отвечает 0.5 секунды, но иногда он отвечает 10-15 секунд. Если таких 4, то мы уже получаем 40-60 секунд, а это как минимум слабая отзывчивость синхронного сервиса, как максимум таймауты.
А если вы дернули 3, а 4-й упал? получается, вы первые 3 дернули зря, т.к. просто забыли их данные.
А ещё могут быть интеграции, которые не считывают данные, а запускают какие-то процессы, а тут уже до SAGA рукой подать, а это то ещё усложнение системы в целом. Ихмо, если можно уйти от SAGA, то лучше от него уйти, и подальше, сложностей на проекте и так хватит, зачем ещё усложнять.
ИХМО, в этих случаях стоит пересмотреть общую архитектуру этих интеграций, например, разбивать их на этапы, с сохранением промежуточных результатов, что в свою очередь поменяет вашу статусную модель, и так далее... Кажется, я открыл ящик пандоры, тема очень глубокая...
я видел что он есть, пока не понял, где для меня он может быть полезен. Выглядит - как какая-то очень редкая узкая вещь.
>> Вы про толстые ДТОшки?
нет, про доменные модели. Комментатор выше утверждает, что если объекты умные, то ломбок тут применять не нужно. по крайней мере вот эту фразу - "Если у вас другой подход (с иной логикой, которая подразумевает умные объекты, инкапсулирующие свое поведение) - ломбок не про это" я понял именно так.
>> Всю статью не покидало ощущение, что очередная борьба за качество кода.
так и есть.
>>Вызов был воткнут в класс нарушавший все буквы в SOLID . Буквально.
Ну и нормально. Есть другая крайность, тупое следование всем принципам. Я тоже иногда осознанно игнорирую что-нибудь из SOLID в угоду простоте, читаемости, качеству. Тут чуйка какая-то должна быть. Наверное, оно вырабатывается с опытом.
Кстати, она не плохо срабатывает во время дебатов внутри команды. По-обсуждаем, а потом получается сильно лучше, чем когда один писал.
>>В общем код на голову лучше чем там где борятся...
Однозначно да. А чтобы не бояться, нужно через TDD писать. Если код покрыт качественно тестами, бояться не чего. Другое дело, писать их тоже надо уметь.