Привет, Хабр! Мы — Рома, Настя и Карина — бэкенд-разработчики Тинькофф, пишем код на Scala и горим желанием его популяризировать. Собираем и агрегируем новости из разных источников, включая Scala Times, блог Petr Zapletal и канал Scala Nishtyaki, добавляем дополнительные новости и собственные комментарии. Свою мотивацию черпаем из желания развиваться и делиться полученными знаниями. Приветствуем любую обратную связь! (づ ◕‿◕ )づ
В первой части мы рассмотрели примеры тестов, из которых не все одинаково полезны. Затем попытались определиться, что же такое качество ПО, и предложили "распрямлять" код и выводить программы из требований. Рассмотрели классификацию ошибок. Рассмотрели те задачи, в которых тесты хорошо себя проявляют.
Попробуем разобраться, что получится, если применить все эти соображения к тестам из первой части.
В первой части мы рассмотрели примеры тестов, из которых не все одинаково полезны. Затем попытались определиться, что же такое качество ПО, и предложили "распрямлять" код и выводить программы из требований. Рассмотрели классификацию ошибок.
Видя необоснованные надежды, возлагаемые на юнит-тесты, хотелось бы понять, что в действительности можно ожидать от тестов.
В первой части мы рассмотрели примеры тестов, из которых не все одинаково полезны. Затем попытались определиться, что же такое качество ПО, и предложили "распрямлять" код. Рассмотрели классификацию ошибок.
Теперь рассмотрим, как использовать типы, чтобы реализуемая программа сразу гарантированно соответствовала предъявляемым требованиям.
В первой части мы рассмотрели примеры тестов, из которых не все одинаково полезны. Затем попытались определиться, что же такое качество ПО, и предложили "распрямлять" код.
Теперь посмотрим, от каких ошибок защищают тесты, а от каких — другие инструменты из арсенала разработчика.
В первой части мы рассмотрели примеры тестов, из которых не все одинаково полезны. Затем попытались определиться, что же такое качество ПО, и как подходить к вопросу тестирования с системной точки зрения.
Теперь рассмотрим один из аспектов разработки, позволяющий уменьшить необходимое количество тестов — "прямолинейность" кода (как понятие, противоположное цикломатической сложности).
Сталкивались с тестами, которые толком ничего не тестируют? А тесты, которые что-то тестируют, но при этом всё равно постоянно возникают баги? Может быть, тесты, которые приходится каждый раз исправлять?
Несложно построить тест, обеспечивающий 100% покрытие, но при этом ничего не проверяющий и не гарантирующий. (См., например).
Проблемы юнит-тестов уже затрагивались на Хабре ранее:
В заметке рассматривается несколько разновидностей бестолковых тестов, а также некоторые ограничения самой идеи тестирования. А затем (в следующих частях) предлагаются разумные, на взгляд автора, меры обеспечения качества программ, включающие как уменьшение количества малополезных тестов, так и применение тестов там, где они уместны.
Привет, Хабр! Мы — Рома, Настя и Карина — бэкенд-разработчики Тинькофф, пишем код на Scala и горим желанием его популяризировать.
Мы собираем и агрегируем новости из разных источников, включая Scala Times, блог Petr Zapletal и канал Scala Nishtyaki, добавляем дополнительные новости и собственные комментарии. Свою мотивацию мы черпаем из желания развиваться и делиться полученными знаниями. Приветствуем любую обратную связь! (づ ◕‿◕ )づ
В данной статье рассматривается непопсовый метод тестирования чисел на простоту с использованием биномиальных коэффициентов. Авторы представляют алгоритм, позволяющий быстро и точно определить простые числа (но это не точно), ограничиваясь проверкой всего лишь половины биномиальных коэффициентов. Код реализации приводится на языке программирования Scala с использованием длинной арифметики. Результаты тестирования на большом наборе чисел демонстрируют эффективность и надежность предложенного метода.
В данной статье исследуется метод оценки параметров систем дифференциальных уравнений на основе неточных наблюдений. Автор проводит численный эксперимент с использованием языка программирования Scala для оценки реальных результатов и более подробного изучения предложенного алгоритма. Алгоритм оценки параметров включает подготовку данных, генерацию неточных наблюдений, использование численных методов для решения системы уравнений и оценку приближенных значений параметров. Эксперимент проводятся на системе Лоренца, и результаты оценки параметров сравниваются с реальными значениями. Заключение статьи делает выводы о применимости метода и его эффективности при оценке параметров систем дифференциальных уравнений на основе неточных наблюдений.
В данной статье рассматривается создание расширяемого алгоритма строкового калькулятора, который позволяет пользователю самостоятельно определять операции и константы, с которыми работает калькулятор. Основная цель статьи - предоставить описание процесса разработки и реализации такого алгоритма, а также продемонстрировать его гибкость и возможности для настройки под индивидуальные нужды пользователей.
Apache Flink является популярным фреймворком для обработки больших данных и аналитики в режиме реального времени. Одним из ключевых компонентов этого фреймворка является Table API, который предоставляет удобный и выразительный способ работы с данными в формате таблиц, аналогичный SQL.
Если вы разработчик, который хочет узнать больше о том, как использовать Apache Flink Table API для обработки потоковых данных, или если вы интересуетесь современными инструментами аналитики данных, эта статья для вас.
Привет, Хабр! Мы — Рома, Настя и Карина — бэкенд-разработчики Тинькофф, пишем код на Scala и горим желанием его популяризировать.
Мы собираем и агрегируем новости из разных источников, включая Scala Times, блог Petr Zapletal и канал Scala Nishtyaki, добавляем другие интересные новости и собственные комментарии. Свою мотивацию мы черпаем из желания развиваться и делиться полученными знаниями. Приветствуем любую обратную связь! (づ ◕‿◕ )づ
При описании модели данных, часто приходится создавать новые типы, в первую очередь, используя такие ключевые слова как class/struct/record. Я же предлагаю взглянуть на случаи, когда моделируемая сущность, описывается существующими, часто простыми типами, такими как целое число или строка. В статье хочу поделиться мыслями, которые привели меня к использованию специальных типов там, где часто используются встроенные: int, string и тому подобные. И как удобно (относительно) это делать. Примеры приведу на языках Scala, Go и C++.
Привет!
Меня зовут Александр Маркачев, я 3,5 года работаю на позиции Data Engineer в билайне и люблю открывать для себя что-то новое и интересное в работе. Так случилось и с темой, которой я сегодня хочу с вами поделиться — со spill-ами.
Под катом мы поговорим о том, что такое Spill-ы в контексте Spark, и почему именно для Spark это не такая уж сильно плохая штука. Рассмотрим, из-за чего Spill-ы в принципе возникают, разберем несколько видов Spill-ов (и даже вызовем их намеренно), а затем будем решать эту проблему.
Что такое spill-ы в Spark
Вообще, Spill — это термин для обозначения процесса перемещения данных из памяти на диск, а затем снова обратно в память. По крайней мере, именно так гласит официальная трактовка. Если проще, то дело вот в чем — когда у Spark не хватает ресурсов для обработки, он перемещает данные на диск.
В процессе обработки существуют разные участки — есть Executor Memory, есть Storage Memory, и когда эти участки оба целиком заполнены, то они начинают переполняться и вызывать утечку данных. Причем в отличие от утечки в C, Java или еще где-то, в Spark это преднамеренное действие для того, чтобы ваша задача не падала. Собственно, именно поэтому при нехватке ресурсов данные и «проливаются».
Можно ещё сильнее упростить аналогию.
В предыдущем посте о производных в Scala я объяснил суть идеи и показал, как мы можем извлечь из нее пользу, используя производные, предоставляемые библиотеками. В этот раз копнем глубже и реализуем нашу собственную деривацию с помощью Magnolia.
Примечание: Этот пост предназначен для пользователей Scala среднего (intermediate) уровня. Если же вы еще не знакомы с данной темой, я рекомендую начать с введения для начинающих.
Привет, Хабр!
Меня зовут Дмитрий Мулло, я сотрудник Группы «Иннотех».
В этой статье на несложных примерах рассматриваются понятия объектно‑ориентированного программирования, такие как «класс» и «объект», помогающие структурировать код приложения.
Привет, хабр!
Данная задача в разных вариациях мне давалась на нескольких собеседованиях несколько лет назад. Хоть мой дизайн и проходил, мне стало интересно реализовать это в коде с нуля. Сыроватый и сильно урезанный по функционалу MVP готов, ссылка на github будет под катом. Пока что мной запланировано 3 статьи - эта, по бэкенду и по фронту. Будет много кода на scala, много котов (cats effect), стримов (fs2), пара lock-free техник, scala js, и постараюсь сделать так, чтобы мозг от всего этого не взорвался.
Все, кому интересно - добро пожаловать под кат.
Привет! Меня зовут Сергей Грибков, я тимлид команды FM&RA в билайне, и в этом посте я хочу рассказать об одной фирменной особенности Scala под названием implicits. Это неявные параметры, неявные преобразования, неявные классы.
Почему неявные — потому что они не требуют прямого вызова, если мы говорим о методах, не требуют прямой передачи в метод, если мы говорим о параметрах, и так далее.
В Scala implicits широко распространены. Скорее всего, вы уже сталкивались с ними в различных библиотеках и фреймворках, например, Apache Spark.
Чтобы успешно использовать implicits в собственном коде и работать со сторонними библиотеками, требуется понимание принципов их работы. Поэтому давайте разберем, как всё устроено.
Итак, существует три основных категории implicits:
Частичная функция (в отличие от полной) — это функция, которая определена не для всех возможных входных данных. Частичная функция g: A => B — это функция, для которой существуют некоторые значения a в области A такие, что g(a) не определена. Scala имеет хорошую поддержку частичных функций.
