Хм, а в чем проблема с лишними знаками препинания? Любой нормальный редактор их автоматически проставляет.
А вот сложность yaml - вполне объективная, можно смотреть по объему кода для разбора или по объему документации. Сложность редактирования (вернее, простота допустить ошибку) - тоже вполне объективная. В Json опечатка приведет к нарушению синтаксиса. А вот в yaml опечатка приводит к изменению семантики, что гораздо грустнее. Ну и так далее.
Да вообще не стоит пытаться в тимлиды вытаскивать разработчиков. Пусть идут через техлидов в архитекторы и так далее. А на менеджерские позиции лучше брать кого-то или с профильным образованием или с менеджерским опытом. А если разработчик хочет стать менеджером - пусть и начинает с позиции начинающего (с зарплатой тысяч в 50, так как и пользы с него примерно столько же). В противном случае некомпетентность так и будет тотальной на всех уровнях. Управление людьми, управление процессами, мотивация, лидерство - это все достаточно сложные компетенции и области знаний, которым надо учиться и развивать и достаточно длительное время. Хотя, будем честными, учат менеджменту довольно фигово.
Хм, базовая проблема обозначена вообще в первом абзаце: "тимлида назначило руководство. Чаще всего ими становились опытные архитекторы или разработчики". Но вместо того, чтобы бороться с изначально неверным подходом, зачем-то его стали прикрывать тряпочкой.
Это как лечить запущенный пульпит ударными дозами нурафена. Боль, конечно уйдет. Зубы - тоже.
Ну, таблица для тестов может и в памяти жить, в чем проблема? Если для тестирования используются искусственные данные (а в юнит-тестах обычно так и есть), то все данные будут в памяти и так. Транзакция до завершения может и пишет в журнал, но его тоже можно развернуть в памяти, делов-то. Все это достаточно просто решаемые вопросы, причем решать их умели еще лет 20 назад.
И нет, если у вас бизнес (не аналитики, а именно бизнес) знает про БД, то тут какие-то проблемы. Впрочем, в указанном примере вообще нет (и не может быть) решения, только eventually consistency, саги и так далее. Где и как будет реализована сага - бизнесу вообще без разницы (
Во-первых, откуда в указанном примере сеть и диск? Сам тест пишется на sql, выполняется внутри БД и на диск ничего не пишет. Во-вторых, что за "классическое понимание"? Единица тестирования - хранимая процедура, ее и тестируем, в чем проблема? В-третьих, то, что описано как "бизнес-требование" - таковым не является, описана техническая реализация. Нужно ли именно такое - не понятно, тем более в системе уровня "логика в БД". Ну и так далее....
Хм, а в чем проблема в unit-тестах для хранимых процедур? Открываем транзакцию, заполняем фикстурой (тривиальный insert из таблицы с тестовыми данными), вызываем процедуру, проверяем утверждения, откатываем транзакцию. Это довольно просто пишется, быстро работает, легко модифицируется.
Ну, в kotlin добавили tailrec для этой задачи. Но глубокая рекурсия и в C++ штука опасная и требует аккуратности. Но тут, вроде бы, говорили про Go, а не про C++.
Хм, вроде бы Scala умеет оптимизировать хвостовую рекурсию в JIT, хотя и exception там есть. В Koltin тоже есть tailrec. Да и не так часто встречается хвостовая рекурсия. Inlining в JIT тоже есть и работает.
Судя по графикам по городам, стоимость жилья таки растет даже в долларах с инфляцией? Или Adjusted значит что-то другое? Впрочем, указанный график по ценам в Питере не очень похож на мои воспоминания по ценам )
" Формально то оно может и правильнее, но на практике такое сравнение абсолютно бесполезно, потому что содержимое кадра будет полностью разное", о, спасибо, вот с таким комментарием стало понятно!
Эээ, при чем тут шумы? Оптические характеристики не зависят от шумов, только от оптической схемы. А она не меняется при кропе (при включении режима кропа на полном кадре, разумеется). Ссылки на калькулятор тут не при чем, так как там не про цифровой кроп, а про другую оптическую схему. Если я в фотошопе делают кроп у готового кадра на ФФ - у меня не меняется ни боке, ни ГРИП, ни выдержка. А кроп-режим в фотоаппарате с полным кадром ничем не отличается от кропа в фотошопе.
Вот да, и HOCON и Json5 - лучше и json и, тем более, yaml. Но пока не так популярны (
Хм, а в чем проблема с лишними знаками препинания? Любой нормальный редактор их автоматически проставляет.
А вот сложность yaml - вполне объективная, можно смотреть по объему кода для разбора или по объему документации.
Сложность редактирования (вернее, простота допустить ошибку) - тоже вполне объективная. В Json опечатка приведет к нарушению синтаксиса. А вот в yaml опечатка приводит к изменению семантики, что гораздо грустнее.
Ну и так далее.
А что в нем хорошего? Плохо читается, плохо редактируется, сложный.
Какой-нибудь json, конечно, тоже не идеален - но проще и удобнее.
Да вообще не стоит пытаться в тимлиды вытаскивать разработчиков. Пусть идут через техлидов в архитекторы и так далее. А на менеджерские позиции лучше брать кого-то или с профильным образованием или с менеджерским опытом. А если разработчик хочет стать менеджером - пусть и начинает с позиции начинающего (с зарплатой тысяч в 50, так как и пользы с него примерно столько же). В противном случае некомпетентность так и будет тотальной на всех уровнях.
Управление людьми, управление процессами, мотивация, лидерство - это все достаточно сложные компетенции и области знаний, которым надо учиться и развивать и достаточно длительное время.
Хотя, будем честными, учат менеджменту довольно фигово.
Хм, базовая проблема обозначена вообще в первом абзаце: "тимлида назначило руководство. Чаще всего ими становились опытные архитекторы или разработчики". Но вместо того, чтобы бороться с изначально неверным подходом, зачем-то его стали прикрывать тряпочкой.
Это как лечить запущенный пульпит ударными дозами нурафена. Боль, конечно уйдет. Зубы - тоже.
Ну, таблица для тестов может и в памяти жить, в чем проблема? Если для тестирования используются искусственные данные (а в юнит-тестах обычно так и есть), то все данные будут в памяти и так. Транзакция до завершения может и пишет в журнал, но его тоже можно развернуть в памяти, делов-то.
Все это достаточно просто решаемые вопросы, причем решать их умели еще лет 20 назад.
И нет, если у вас бизнес (не аналитики, а именно бизнес) знает про БД, то тут какие-то проблемы. Впрочем, в указанном примере вообще нет (и не может быть) решения, только eventually consistency, саги и так далее. Где и как будет реализована сага - бизнесу вообще без разницы (
Во-первых, откуда в указанном примере сеть и диск? Сам тест пишется на sql, выполняется внутри БД и на диск ничего не пишет.
Во-вторых, что за "классическое понимание"? Единица тестирования - хранимая процедура, ее и тестируем, в чем проблема?
В-третьих, то, что описано как "бизнес-требование" - таковым не является, описана техническая реализация. Нужно ли именно такое - не понятно, тем более в системе уровня "логика в БД".
Ну и так далее....
Хм, а в чем проблема в unit-тестах для хранимых процедур?
Открываем транзакцию, заполняем фикстурой (тривиальный insert из таблицы с тестовыми данными), вызываем процедуру, проверяем утверждения, откатываем транзакцию.
Это довольно просто пишется, быстро работает, легко модифицируется.
А сколько относительно рынка добавляли? И сколько человек в команде?
Я бы предпочел возможность искажения stack trace при оптимизации рекурсии отсутствию возможности к просмотру трейса.
Ну, в kotlin добавили tailrec для этой задачи. Но глубокая рекурсия и в C++ штука опасная и требует аккуратности.
Но тут, вроде бы, говорили про Go, а не про C++.
Хм, а по сравнению с чем проблемы с оптимизацией в JIT?
Так stacktrace есть во всех указанных вариантах, и в Scala и в Kotlin и в Java.
Хм, вроде бы Scala умеет оптимизировать хвостовую рекурсию в JIT, хотя и exception там есть. В Koltin тоже есть tailrec. Да и не так часто встречается хвостовая рекурсия.
Inlining в JIT тоже есть и работает.
А почему, кстати? Какие именно ограничения?
А, понятно, это неочевидно.
А почему взят такой странный источник данных по Питеру и Москве?
Судя по графикам по городам, стоимость жилья таки растет даже в долларах с инфляцией?
Или Adjusted значит что-то другое?
Впрочем, указанный график по ценам в Питере не очень похож на мои воспоминания по ценам )
А еще же была линейка DR DOS (совместимые с MS DOS, но с улучшенными возможностями) и PalmOS.
" Формально то оно может и правильнее, но на практике такое сравнение абсолютно бесполезно, потому что содержимое кадра будет полностью разное", о, спасибо, вот с таким комментарием стало понятно!
Эээ, при чем тут шумы? Оптические характеристики не зависят от шумов, только от оптической схемы. А она не меняется при кропе (при включении режима кропа на полном кадре, разумеется).
Ссылки на калькулятор тут не при чем, так как там не про цифровой кроп, а про другую оптическую схему.
Если я в фотошопе делают кроп у готового кадра на ФФ - у меня не меняется ни боке, ни ГРИП, ни выдержка. А кроп-режим в фотоаппарате с полным кадром ничем не отличается от кропа в фотошопе.