Раз уж зашла тема про эту строку, в вашей таблице 450 Мб -> 468,9 Мб, а коэффициент 99,3%. Что-то из этого не корректно, в совокупности с изменением размерности скорости действительно вызывает сомнения. Исходя из первой строки первоначальный файл весил 471,9 Мб (а не 450). Мне кажется просто стоит результаты бенчмарка чуть причесать, чтобы прям нельзя было за мелочи зацепиться. Это вполне логично, что заявления о том, что написан код, перфоманс, которого превосходит текущие технологии рассматривают под микроскопом и такие мелочи снижают доверие к результатам опубликованным автором.
Если с первым и вторым пунктом, еще можно согласится. То часть про тесты, если честно слабая: не вижу огромной разницы между двумя примерами. Но даже если так, то создание небольшой собственной обвязки вокруг либы тестирования может решить проблему лишнего кода тестов в java. Поднятие докеров опять же решаемо через скрипты сборке в гредле, к примеру. А вот приделать питон сбоку , как альтернативу современному зоопарку инфраструктурных сервисов идея интересная.
Но давайте вернемся к тестам, собственно вопрос, как с помощью подобного тестирования, вычислить покрытие кода тестами?
P.S. И хотя покрытие несколько раз выручало меня при поимке багов, в данном случае это вопрос требований к проекту, а не моей прихоти
Я б немного перформулировал, нет тех кто заинтересован в том, чтобы программисты НЕ gовнокодили программы, кроме самих программистов (ну должно бы быть так, чтобы они были заинтересованы, профессионализм там, ответственность за профессию и прочее забытое). Корпорациям на это все равно, они перекладывают затраты на пользователей: надо больше больше железа да, пожалуйста, - распределяем на стоимость услуги конечного пользователя. А как сделать так чтобы это купили, еще Голдратт в 80-90х придумал: впариваем ненужную им услугу за те же деньги и говорим им, что она очень нужна. Итого их заинтересованность нулевая. У государств по факту тоже, благодаря круговороту рост цен - рост зп у них растет ВВП - современный предмет гордости государства.
На примере вот что заметил, я в графике не силен, но почему то размытие появляется и на удаленных тайлах и на ближних, как будто в фокусе центральная часть только, это так задумано? Просто из моих скудных знаний о композиции и детализации в рисунках, как будто бы так не должно быть. Опять же с мобильного chrome заходил, может это тоже роляет. А статья зачетная, спасибо!
Знаете, какой аспект мне кажется не раскрытым. Сейчас за безопасность ваших данных продукт отвечает, как с серверной так и с клиентской стороны. Если клиентская часть уедет в сгененрированный код, кто будет отвечать за раскрытие данных на клиентской стороне? По факту сам клиент который нагенерил себе интерфейс, потому что больше некому. А если так то для предотвращения утечек с клиента, сгенерированный код надо прогонять через классические этапы безопасности, иначе никто не гарантирует, что ваш, к примеру, токен доступа к персональным данным не сольется на какой-то левый сайт, а для этого нужны навыки, превышающие стандартного пользователя. Так что тенденция интересная, но, на мой взгляд, довольно далекого будущего: или когда появятся сервисы безопасности, способные справлятся с бесконечным потоком льющегося в него кода, или же когда когда каждый пользователь будет обладать большими навыками, чем средней руки программист - ну тут тоже не ближайшего времени дело.
Вот на первом же примере можно поговорить об усложнении. Считается ли за излишнее усложнение кода введение в сортировку пузырьком счетчика перестановок и проход во втором цикле только неотсортированной части массива? Вот мой препод в универе так не считал и без них лабораторные не принимал, но как только вы добавите их в алгоритм, то легкость и предсказуемость кода этого примера резко снизится. Надо будет понимать зачем это "лишние" действия в коде присутствуют и на что влияют
Первый, ребята не с той стороны заходят, если вопрос подписок на сборки, то идти надо в сторону репозиториев эти сборки раздающих, ну например в maven central для java/kotlin и там просить создавать подписки, но я уверен эти репозитории тут же начнут интересоваться, а с чего бы им тогда бесплатно сборки хостить. И мы из опенсорса получим обыкновенный бизнес.
Второй, пока тебе не платят денег с тебя никто не спрашивает за качество и корпорации не могут тебе предъявить за уязвимости в твоем коде, или коде библиотек, которые ты использовал. Но, стану ли я, как корпорация платить за код, в котором возможно есть баги или уязвимости? А если и стану я бы потом хотел в судебном порядке предъявить тому, кто лишил меня пары миллионов
В заключении, если такая инициатива пройдет, то есть подозрение, что дело не выгорит, потому что корпорациям будет проще взять код в реп и самостоятельно собирать с учетом своих требований к безопасности - те заявленной фичи, чтобы чужой труд не использовался задарма ради получения прибыли мы так и не получим
Про Твиттер не знаю, если поделитесь источником, где указано, что именно так и поступили его создатели буду благодарен, хороший аргумент для споров с начальством по этому поводу.
И, поскольку вас забанили в редакторе кода и отобрали последний, доставшийся вам от деда, деревянный JDK, вы забили на решение, которое более 25 закалялось в боях
Подозреваю, что вы некорректно поняли мою причину отказа от AspectJ, посчитав, что я отказался от него из-за того, что не достиг полного понимания его работы в статьях и поленился исследовать его другими способами. Но фраза "Мне не хватило понимания:" относилась к моей оценке статей, на которые я ссылаюсь, а не к моему пониманию того, как работает AspectJ. Я провел исследование статей об AspectJ в интернете и обнаружил, что собранные мной материалы, не дают полного представления о том, как он работает, и заявил об этом в статье. Моя статья не про AspectJ, поэтому я не занимаюсь в ней его детальным описанием.
просто написали враппер вокруг (дайте подумать) — прямого вызова функции!
Так точно, именно это я и сделал! Потому что враппер вокруг прямого вызова функций с помощью небольшой магии позволяет мне сделать много интересных вещей - например написать простые обработчики ошибок, чтобы убрать по всему коду try-catch, чтобы снизить когнитивную сложность кода. Или добавить не функциональных требований к вызовам функций, не изменяя их кода, написанного не мной, с минимальным риском попортить функциональные требования для которых писалась эта функция. В статье приведен пример простейшего использования этого чудесного, на мой взгляд, механизма, который не заслужил достойного к себе внимания.
Либо я чего-то не понял, либо вы какой-то pipeline-фреймворк навелосипедили.
Да, вообще-то я ничего и не велосипедил. Целью статьи было показать как с помощью ссылок на методы можно повысить гибкость в программе на примере одной простой штуки, которую я собрал, не претендуя на какое-либо новаторство. Я вообще считаю, что ссылки на методы незаслуженно мало используются при проектирование кода. А в заключение заметил, что с помощью даже такой простой штуки можно много каких вещей наворотить вокруг.
Так и не понял при чем здесь AspectJ был
Он был в списке инструментов, которые я посмотрел, и отметил что он может и почему он мне не подходит не более того, а также подчеркнул, что несмотря на это существуют ситуации где его использование оправдано.
Он так назван, потому что вызов всей цепочки собранной тоже в нем. Возможно есть смысл разделить сборку и исполнение, ну и названия соотвествующие сделать. Спасибо за предложение.
Согласился бы с этим утверждением, если бы речь шла об AspectJ именно этот его недостаток привел меня к идее реализовать подобную механику. Однако здесь вызов основного метода и всех вспомогательных ищется точно также, как если бы он вызывался напрямую за счет ссылок на методы. В конечном итоге сложность не выше, чем если бы все эти методы вызывались бы просто последовательно из другого метода. А преимущество заключается в том, что сам MethodExecutor является объектом и к нему можно применить порождающие паттерны проектирования, сократив дубликацию кода.
Да, обе эти задачи решаются с помощью данной механики. Разделение слоев мы уже решили через единую точку входа и выхода из бизнес логики. А чтобы добавить вторую, нужны дополнительные организационные и технологические ухищрения: возможность конфигурации secondary adapter'ов (из терминологии гексогональной архитектуры) и отсутствие прямых вызов из сервиса в сервис или сервиса в домен
Не могу не согласится с автором статьи, по теме жути, которая творится при использовании Spring JPA/Hiber, но поддержу и комментаторов, проблема не в них, я как-то делал свой ORM - это лучший способ понять почему hiber делает так как делает. Сначала все просто, но потом начинаешь добавлять нужную функциональность, обрабатывать краевые случаи, оптимизировать производительность и вот у тебя уже такой монстр с теми же проблемами. А в реальности все дело в JPA, как в спецификации, так что при разработке следующего метода получения данных из БД я от него ушел и копнул глубже. А дальше как в старом анекдоте "чертова гравитация"
Информация
В рейтинге
4 695-й
Откуда
Москва, Москва и Московская обл., Россия
Дата рождения
Зарегистрирован
Активность
Специализация
Бэкенд разработчик, Архитектор программного обеспечения
Раз уж зашла тема про эту строку, в вашей таблице 450 Мб -> 468,9 Мб, а коэффициент 99,3%. Что-то из этого не корректно, в совокупности с изменением размерности скорости действительно вызывает сомнения. Исходя из первой строки первоначальный файл весил 471,9 Мб (а не 450). Мне кажется просто стоит результаты бенчмарка чуть причесать, чтобы прям нельзя было за мелочи зацепиться. Это вполне логично, что заявления о том, что написан код, перфоманс, которого превосходит текущие технологии рассматривают под микроскопом и такие мелочи снижают доверие к результатам опубликованным автором.
Дык в одной статье выручка, а другой прибыль. Это разные вещи.
Если с первым и вторым пунктом, еще можно согласится. То часть про тесты, если честно слабая: не вижу огромной разницы между двумя примерами. Но даже если так, то создание небольшой собственной обвязки вокруг либы тестирования может решить проблему лишнего кода тестов в java. Поднятие докеров опять же решаемо через скрипты сборке в гредле, к примеру. А вот приделать питон сбоку , как альтернативу современному зоопарку инфраструктурных сервисов идея интересная.
Но давайте вернемся к тестам, собственно вопрос, как с помощью подобного тестирования, вычислить покрытие кода тестами?
P.S. И хотя покрытие несколько раз выручало меня при поимке багов, в данном случае это вопрос требований к проекту, а не моей прихоти
Я б немного перформулировал, нет тех кто заинтересован в том, чтобы программисты НЕ gовнокодили программы, кроме самих программистов (ну должно бы быть так, чтобы они были заинтересованы, профессионализм там, ответственность за профессию и прочее забытое). Корпорациям на это все равно, они перекладывают затраты на пользователей: надо больше больше железа да, пожалуйста, - распределяем на стоимость услуги конечного пользователя. А как сделать так чтобы это купили, еще Голдратт в 80-90х придумал: впариваем ненужную им услугу за те же деньги и говорим им, что она очень нужна. Итого их заинтересованность нулевая. У государств по факту тоже, благодаря круговороту рост цен - рост зп у них растет ВВП - современный предмет гордости государства.
На примере вот что заметил, я в графике не силен, но почему то размытие появляется и на удаленных тайлах и на ближних, как будто в фокусе центральная часть только, это так задумано? Просто из моих скудных знаний о композиции и детализации в рисунках, как будто бы так не должно быть. Опять же с мобильного chrome заходил, может это тоже роляет. А статья зачетная, спасибо!
Я просто с мобильного телефона открыл - получилось через chrome
Знаете, какой аспект мне кажется не раскрытым. Сейчас за безопасность ваших данных продукт отвечает, как с серверной так и с клиентской стороны. Если клиентская часть уедет в сгененрированный код, кто будет отвечать за раскрытие данных на клиентской стороне? По факту сам клиент который нагенерил себе интерфейс, потому что больше некому. А если так то для предотвращения утечек с клиента, сгенерированный код надо прогонять через классические этапы безопасности, иначе никто не гарантирует, что ваш, к примеру, токен доступа к персональным данным не сольется на какой-то левый сайт, а для этого нужны навыки, превышающие стандартного пользователя. Так что тенденция интересная, но, на мой взгляд, довольно далекого будущего: или когда появятся сервисы безопасности, способные справлятся с бесконечным потоком льющегося в него кода, или же когда когда каждый пользователь будет обладать большими навыками, чем средней руки программист - ну тут тоже не ближайшего времени дело.
Вот на первом же примере можно поговорить об усложнении. Считается ли за излишнее усложнение кода введение в сортировку пузырьком счетчика перестановок и проход во втором цикле только неотсортированной части массива? Вот мой препод в универе так не считал и без них лабораторные не принимал, но как только вы добавите их в алгоритм, то легкость и предсказуемость кода этого примера резко снизится. Надо будет понимать зачем это "лишние" действия в коде присутствуют и на что влияют
Вижу 2 интересных аспекта:
Первый, ребята не с той стороны заходят, если вопрос подписок на сборки, то идти надо в сторону репозиториев эти сборки раздающих, ну например в maven central для java/kotlin и там просить создавать подписки, но я уверен эти репозитории тут же начнут интересоваться, а с чего бы им тогда бесплатно сборки хостить. И мы из опенсорса получим обыкновенный бизнес.
Второй, пока тебе не платят денег с тебя никто не спрашивает за качество и корпорации не могут тебе предъявить за уязвимости в твоем коде, или коде библиотек, которые ты использовал. Но, стану ли я, как корпорация платить за код, в котором возможно есть баги или уязвимости? А если и стану я бы потом хотел в судебном порядке предъявить тому, кто лишил меня пары миллионов
В заключении, если такая инициатива пройдет, то есть подозрение, что дело не выгорит, потому что корпорациям будет проще взять код в реп и самостоятельно собирать с учетом своих требований к безопасности - те заявленной фичи, чтобы чужой труд не использовался задарма ради получения прибыли мы так и не получим
Про Твиттер не знаю, если поделитесь источником, где указано, что именно так и поступили его создатели буду благодарен, хороший аргумент для споров с начальством по этому поводу.
Подозреваю, что вы некорректно поняли мою причину отказа от AspectJ, посчитав, что я отказался от него из-за того, что не достиг полного понимания его работы в статьях и поленился исследовать его другими способами. Но фраза "Мне не хватило понимания:" относилась к моей оценке статей, на которые я ссылаюсь, а не к моему пониманию того, как работает AspectJ. Я провел исследование статей об AspectJ в интернете и обнаружил, что собранные мной материалы, не дают полного представления о том, как он работает, и заявил об этом в статье. Моя статья не про AspectJ, поэтому я не занимаюсь в ней его детальным описанием.
Так точно, именно это я и сделал! Потому что враппер вокруг прямого вызова функций с помощью небольшой магии позволяет мне сделать много интересных вещей - например написать простые обработчики ошибок, чтобы убрать по всему коду try-catch, чтобы снизить когнитивную сложность кода. Или добавить не функциональных требований к вызовам функций, не изменяя их кода, написанного не мной, с минимальным риском попортить функциональные требования для которых писалась эта функция. В статье приведен пример простейшего использования этого чудесного, на мой взгляд, механизма, который не заслужил достойного к себе внимания.
Да, вообще-то я ничего и не велосипедил. Целью статьи было показать как с помощью ссылок на методы можно повысить гибкость в программе на примере одной простой штуки, которую я собрал, не претендуя на какое-либо новаторство. Я вообще считаю, что ссылки на методы незаслуженно мало используются при проектирование кода. А в заключение заметил, что с помощью даже такой простой штуки можно много каких вещей наворотить вокруг.
Он был в списке инструментов, которые я посмотрел, и отметил что он может и почему он мне не подходит не более того, а также подчеркнул, что несмотря на это существуют ситуации где его использование оправдано.
Он так назван, потому что вызов всей цепочки собранной тоже в нем. Возможно есть смысл разделить сборку и исполнение, ну и названия соотвествующие сделать. Спасибо за предложение.
Согласился бы с этим утверждением, если бы речь шла об AspectJ именно этот его недостаток привел меня к идее реализовать подобную механику. Однако здесь вызов основного метода и всех вспомогательных ищется точно также, как если бы он вызывался напрямую за счет ссылок на методы. В конечном итоге сложность не выше, чем если бы все эти методы вызывались бы просто последовательно из другого метода. А преимущество заключается в том, что сам MethodExecutor является объектом и к нему можно применить порождающие паттерны проектирования, сократив дубликацию кода.
Да, обе эти задачи решаются с помощью данной механики. Разделение слоев мы уже решили через единую точку входа и выхода из бизнес логики. А чтобы добавить вторую, нужны дополнительные организационные и технологические ухищрения: возможность конфигурации secondary adapter'ов (из терминологии гексогональной архитектуры) и отсутствие прямых вызов из сервиса в сервис или сервиса в домен
Спасибо. Рад, что у меня получилось объяснить идею простым языком.
Не могу не согласится с автором статьи, по теме жути, которая творится при использовании Spring JPA/Hiber, но поддержу и комментаторов, проблема не в них, я как-то делал свой ORM - это лучший способ понять почему hiber делает так как делает. Сначала все просто, но потом начинаешь добавлять нужную функциональность, обрабатывать краевые случаи, оптимизировать производительность и вот у тебя уже такой монстр с теми же проблемами. А в реальности все дело в JPA, как в спецификации, так что при разработке следующего метода получения данных из БД я от него ушел и копнул глубже. А дальше как в старом анекдоте "чертова гравитация"