Бывало, замечаешь в коде «нехороший» модуль или функцию и тут же тянутся руки их отрефакторить. Но как потом убедиться, что правки не сломали какой-нибудь сценарий в приложении или вовсе не положили продакшен? Этих ситуаций можно избежать, если в проекте есть тесты. 

Меня зовут Александр Моргунов, я техлид в Самокате. Пишу на TypeScript, React, ReactNative. В разное время писал тесты для фронтенда, бэкенда и мобилок. В этом посте хочется поговорить о том, как можно тестировать современные фронтенд-приложения и какие подходы к тестированию сейчас актуальны. 

Надеюсь, пост будет полезен для фронтендеров и тестировщиков, которые хотели бы свериться по дополнительным практикам для написания тестов. А бэкендеры смогут лишний раз посмотреть на схожесть и различия в тестировании для бэка и фронтенда.

Последние 4-5 десятилетий спрос на программистов вырос в сотни раз. По некоторым оценкам их количество удваивается каждые пять лет, и в результате программист с 5-летним опытом работы имеет стаж работы в отрасли больший, чем у половины всех ее сотрудников.

Эрик Дитрих* около 10 лет провел на должностях, где его основной функцией было написание кода. Еще 10 лет были связаны с управлением программистами, их обучением, консультированием организаций, практикой оценки кодовой базы, а в наши дни и контент-маркетингом. Но во всех этих ролях он в той или иной степени писал код. И, по своим расчетам, прошел больший путь, чем 94% работающих в отрасли. Получается некое противопоставление: программист со стажем, который общается с кучей новичков в программировании.

Специально для своего блога Эрик попытался обобщить весь свой опыт в виде кратких советов, которые он хотел бы дать молодым программистам. Под катом — наиболее важные, на взгляд автора, уроки и выводы из его 20-летней карьеры.

*Обращаем ваше внимание, что позиция автора может не всегда совпадать с мнением МойОфис.

Основная идея статьи - попробовать модифицировать популярное и полезное, но трудное физкультурное упражнение для выполнения обычным человеком серьёзного тренирующего объема с минимум негативных ощущений. А также как извлечь пользу для здоровья из просмотра футбольных матчей. Инструкция. Ссылки на бесплатное программное обеспечение.

Серия моих предыдущих статей о здоровье и его компьютерном анализе и просто о ЗОЖ и фитнесе-физкультуре:

Бег в 2023 г. С пятки или с носка? Измеряем ударные нагрузки. Android и акселерометр
https://habr.com/ru/post/714698/

Как быстро бег уничтожает колени. Опрос любителей и мнение профессионалов
https://habr.com/ru/post/709182/

Сделайте это и бегать будет легче, чем ходить. Упражнение для тренировки летящего бега, получите удовольствие от бега
https://habr.com/ru/post/705954/
65 тыс. прочтений.

Теория Информации и Machine Learning мне видятся как интересная пара областей, глубокая связь которых часто неизвестна ML инженерам, и синергия которых раскрыта ещё не в полной мере.

Начнём с базовых понятий Энтропии, Информации в сообщении, Mutual Information, пропускной способности канала. Далее будут материалы про схожесть задач максимизации Mutual Information и минимизации Loss-а в регрессионных задачах. Затем будет часть про метрику Фишера, геодезические и градиентные методы, и их связь с гауссовскими процессами.

Понятие Mutual Information (MI) связано с задачей прогноза. Собственно, задачу прогноза можно рассматривать как задачу извлечения информации о сигнале из факторов. Какая-то часть информации о сигнале содержится в факторах. И если вы напишите функцию, которая по факторам вычисляет число близкое к сигналу, то это и будет демонстрацией того, что вы смогли извлечь MI между сигналом и факторами.

Привет Хабр!

В этой статье будет разобрана работа Unreal Header tool, рефлексии, и немного затронем VM.

В этой статье я постарался разложить некоторые интересные на мой взгляд аспекты, касающиеся зубной эмали, процессов ре- и де- минерализации, а также роли зубной пасты в этих увлекательных процессах.

Материал я собрал, изучая такие сайты, как researchgate.net, sciencedirect.com, www.ncbi.nlm.nih.gov, escholarship.org и другие. Опираясь на эти данные, я занимаюсь разработкой оптимальной рецептуры гигиенической (т.е. не лечебную) зубной пасты, стараясь добиться оптимального баланса между абразивными, антибактериальными и реминерализирующими свойствами (плюс - еще желательно позаботиться об окружающих зуб тканях).

Зачем? 1. Потому что очень интересно; 2. Потому что не хватает этого баланса в современных не лечебных продуктах (лечебные должны работать в одну цель, там совсем иная история в этом плане).

О чём тут не будет: напоминания базовых конструкций языка и основных моментов о том, как с ними работать; подробного разбора, как работают исключения (писали тут и тут); как грамотно спроектировать ваш класс/программу, чтобы не наломать дров в будущем с гарантией исключений (разве что совсем чуть-чуть, хотя я сам и не очень-то тук-тук).

О чём будет: разные способы обработки ошибок в C++, несколько советов от сообщества и немного заметок о различных жизненных (и не очень) ситуациях.

В стандартной библиотеке языка программирования C++ существует много классов, наделенных если не абсолютно одинаковыми свойствами, то очень похожими.

Так, стандарт вводит отдельное требование BitmaskType, описывающее свойства, какими должны обладать битовые маски в стандартной библиотеке: для них должен быть определены операции «и», «или», «не», а значение 0 должно представлять пустую маску.

В стандартной библиотеке классов, от которых требуется соблюдение этого требования, очень много: std::chars_format, std::launch, std::filesystem::perms, std::filesystem::perm_options, std::filesystem::copy_options, std::filesystem::directory_options... Единственное, чем они отличаются — это набором возможных значений. Реализации же битовых операций над ними похожи как две капли воды.

В данной статье мы поговорим о том, как такое средство как метаклассы в некоторых случаях способно спасти программиста от написания простынь бойлерплейта.

В разработке программного обеспечения иммутабельным (immutable — неизменяемым) называется объект, который после своего создания не может быть изменен. Зачем вам может понадобиться такой объект? Чтобы ответить на этот вопрос, давайте проведем анализ проблем, которые могут возникнуть в результате мутации (изменения) объектов. Вернемся к основам того, что делает каждое приложение: создает, извлекает, обновляет и удаляет данные (CRUD-операции). Ядро любого приложения манипулирует объектами. Ответ на вопрос о том, работает ли приложение в соответствии со своей спецификацией, в первую очередь определяется правильностью обработки данных. Вам необходимо быть уверенными, что код работает правильно, каждый раз, когда он затрагивает какой-либо объект. 

Но что, если бы существовали объекты, которые не могли бы изменяться? Исходя из вышеизложенного, очевидно, что если объект не может измениться, то либо не будет кода, пытающегося изменить его, либо, если такой код все-таки написан, он не будет работать.

Если ваше приложение является многопоточным, иммутабельность должна быть фундаментальной частью вашей архитектуры, поскольку неизменяемые объекты по своей природе являются потокобезопасными и невосприимчивыми к состояниям гонки. Если ваше приложение использует data transport objects (DTO — объекты передачи данных), вам также следует серьезно подойти к иммутабельности ваших объектов. Предметом дискуссий остается лишь то, как наиболее эффективно реализовать и работать с иммутабельными объектами, поскольку C# не предлагает встроенной поддержки таких объектов. Эта статья предлагает ответ на этот вопрос.

Когда я взялась решать задачку по динамическому программированию — реализовать алгоритм, который рассчитывает расстояние Левенштейна — мне пришлось послушать пару небольших лекций и прочесть несколько статей (приведу их в конце), чтобы разобраться. Я решила попытаться пересказать алгоритм настолько просто, чтобы по этому объяснению можно было снять ролик для тиктока (когда он снова возобновит свою деятельность в РФ). Дальше — мало формул и много картинок.

Дженерики - мощная фича доступная во многих статически типизированных языках программирования. С их помощью можно писать код, который постоянно работает со множеством разных типов, делая упор на их общие особенности, нежели на сами типы. Они позволяют создавать гибкие и переиспользуемые компоненты без нужды в дублировании кода и жертвы безопасности типов.

Несмотря на то, что дженерики давно в C#, мне всё же удаётся найти новые интересные способы их применения. Например, в одной из моих предыдущих статей я написал об уловке, позволяющей добиться return type inference, что может облегчить работу с контейнерными union types.

Недавно, мне также довелось работать над кодом, использующим дженерики. Тогда передо мной встала нетипичная задача: было необходимо определить сигнатуру, где все типовые параметры опциональны и могут использоваться друг с другом в произвольных комбинациях. Первая попытка подступиться к решению заключалась в манипуляциях с перегрузками типов, однако такой подход оказался довольно непрактичным и не увлекательным.

После нескольких экспериментов, я нашёл способ решить проблему элегантно, используя подход схожий с паттерном проектирования fluent interface, который был применён не к объектам, а к типам. Мой подход предлагает domain-specific language, который позволяет разработчику построить нужный тип за несколько логических шагов, последовательно его "конфигурируя".

В данной статье я расскажу, что из себя представляет этот подход и как его можно использовать для того, чтобы сложные обобщённые типы писать просто.

Всем привет, это Денис Вебер.

Думаю, что каждый человек, когда-либо игравший в игры, хоть раз задумывался о том как они устроены. В этот раз я решил примерить на себя роль разработчика и попробовать создаю свою первую в жизни игру.

Как обычно, специально для тех, кому больше нравится формат видео, а не текст, видео я оставлю в конце статьи.

Здравствуй, Хабр!

Я хочу поделиться опытом в создании одной гиперказуалки. Сам я, правда, ещё совсем зелен и юн на этой тернистой тропе игроделания, но может кому-то станет интересно и он прочтёт цикл этих статей. Самого кода здесь не будет, а если и будет, то в очень мизерных количествах, в связи с чем вряд-ли эти статьи будут интересны людям, которые хотят применить главную основу программирования "Ctrl+C/Ctrl+V" да и так как я сам новичок то заядлым "про" тут тоже будет скучновато, а плюсом на них может наложиться дебафф "BloodFromTheEyes" от порой наинеумнейших решений наиглупейших проблем. Но всё же опыт есть опыт, так что расскажу что есть.

Статья о моих приключениях при разработке первой игры в 3D. Да, вы правильно поняли, я замахнулась на святое, и попробовала сделать Skyrim на Unity. Но делала это с любовью и от чистого сердца.

Предлагаю ознакомиться с ранее размещенными материалами по проекту StarLink (SL):

‣ Часть 35. Проблема StarLink и LEO группировок
‣ Часть 36. Ретроспектива частотных планов
‣ Часть 37. НеДовыход из бета-версии и проблемы с выполнением предзаказов
‣ Часть 38. Новый терминал StarLink UT-2
‣ Часть 39. Эволюция частотных планов StarLink в 2016-2020 годах
‣ Часть 40. Испанский «привет» СтарЛинку

Однажды я долго искал интересные 3D игры в Play Market и к своему сожалению не нашел почти ничего интересного.

Графика этих игр была слишком простая, освещение ужасное, текстуры слишком мыльные. Некоторые игры даже не дотягивали по качеству до игр для компьютеров и консолей 2000ых годов.

Мне показалось странным, сейчас в мобильные телефоны устанавливают мощные графические процессоры, а качество графики сомнительное.