Поделюсь с вами кейсом ускорения работы одного сайта на WP + WooCommerce. Статья будет полезна джунам и миддлам кто разрабатывает сайты, кто занимается оптимизацией сайтов и кто хочет посмотреть на работу php кода "с высоты". Для себя из полезного можно узнать как связать вместе OpenServer, PhpStorm и xDebug
Существует много проекты в которых нужно сразу видеть результат переменных в момент выполнения программы. Например обработка нажатий клавиш от пользователя, навигация между страницами в GUI приложениях, обработка данных из форм на веб проектах.
В общем во всех проектах где есть цикл событий, хорошо бы видеть значения переменных, когда идет процесс отладки.
Для этого используют обычный print() но по стандарту ограничен одной консолью, или loggin() но его нужно относительно дольше настраивать, чем проект console-debugger, по причине того что нужно указывать файл, стиль вывода даны в файл, рейтинг обработки, в ручную запускать слежение за файлом, в ручную закрывать слежение за файлом, когда вам больше не нужен обработчик.
Я понимаю плюсы лорнирования но они не подходят для дебаггинга ...
Недавно я проходил собеседование и одним из вопросов, стал такой загадочный экземпляр:
"А какое главное преимущество системы типов Kotlin перед Java"?
Честно говоря, выделить какое преимущество считалось главным, оказалось неразрешимой для меня задачей: Nothing, отсутсвие Wildcard и First-Class Functions вместо Java-костыля с Functional Interface (имеется ввиду 8я версия Java) не заняли первых мест в личном топе интервьюера, который мне предложили угадать.
Оказалось что главное в Kotlin - возможность обьявить Nullable Type и Null Safety подход (Замечу, что по моему опыту собственные или библиотечные Optional или Maybe решают эту проблему, и пишутся за 10 минут на Java 7. А еще есть аннотации Nullable, позволяющие проверять поля в сompile-time. Короче, есть много способов заставить делать Null проверки в plain Java. Ну да ладно).
Но речь пойдет не о странных вопросах, связанных со вкусовыми предпочтениями интервьюеров относительно синтаксического сахара.
Дело в том, что Null Safety в Kotlin можно сломать, притом не выходя из под его безопасного купола в суровый дикий мир Java и Null-Referrences.
Как?
Long story short: ClassLoader ведет себя интересным образом при попытке загрузить статические поля классов рекурсивно ссылающиеся на классы друг-друга.
Под катом примеры кода и подробное объяснение того, как он обманывает проверки на Nullable. Я искренне надеюсь что специфические знания Java/Kotlin для статьи не нужны - я объясню все детали на ходу, и уложу расследование в 10 минут.
Привет, Хабр! Меня зовут Антон Шкредов, я QA Lead в SuperJob. В День тестировщика хочу поделиться историей о том, как около четырех лет назад мы с командой перешли от ручного тестирования к автоматизации UI и какой профит в итоге получили. Внутри подробности про усталость от ручных тестов, с чего начали автоматизацию, какие инструменты использовали, а также про сложности и бонусы от внедрения.
Если ваш Спектрум пылится на полке, эта статья подскажет, как дать ему вторую жизнь, а вам — новое хобби. Возможно, вы хотели бы встретить вызов: всего лишь ~40кб памяти, включая код программы. Реализовать хорошее приложение крайне затруднительно, так как вы столкнетесь не только с нехваткой памяти, медленным процессором, но и отсутствием нормальной отладки на уровне исходного кода.
С выходом интернет-адаптера Spectranet сообщество активно развивается, и я предлагаю вам почитать о том, как отлаживать Си для проекта, который вышел за уровень демки.
Вам когда-нибудь приходилось отлаживать и работать с кодом зависимых библиотек NuGet или .NET, которые не являются частью вашего решения? Сегодня отладка через них не так проста, как отладка ваших проектов, которые являются частью вашего решения. Начиная с Visual Studio 2022 Preview 3, мы добавляем новый узел «Внешние источники» в обозреватель решений, который значительно упростит отладку файлов внешних источников. Этот узел появляется во время отладки и отображает источники для управляемых модулей с загруженными символами, содержащими информацию о Source Link или Source Server. Вы можете легко просматривать эти исходные файлы и отлаживать их, при необходимости устанавливая точки останова.
Команда Visual Studio 2022 работает над тем, чтобы обеспечить личную и командную продуктивность. Отладка внешних источников - это возможность инструментов диагностики, которая является лишь одной из интересных функций, над которыми мы работаем.
Помехи, слишком большое количество SSID, трафик управления с ограниченным доступом и небольшая ширина канала могут замедлить работу Wi-Fi сетей. Покажем, как устранить эти проблемы.
В процессе переделки игрушки-осциллографа DSO138, как уже описывалось в предыдущей статье, возникла идея в DSO303 попробовать фокус с удвоением частоты дискретизации. В самом деле для STM32F303 теоретически максимально достижимая скорость дискретизации с точки зрения входа АЦП, а это определяется минимальным временем открытия УВХ, которое в нашем случае 1,5 такта х (1 / 72 МГц), или примерно 20,8 наносекунд, что дает 48 MSPS (миллионов отсчетов в секунду). Однако при параллельной работе 4-х АЦП на 6 МГц получается достичь только 24 MSPS из-за ограниченного быстродействия АЦП.
Представим себе, что мы рассматриваем правильно-периодический сигнал, который при этом еще и постоянен, т.е. не испытывает флуктуаций по частоте и амплитуде во времени. Возможно ли как-то оцифровывать его не в один, а в несколько проходов, тем самым увеличив эффективную частоту выборки?
На Али продается за очень недорого интересная игрушка – осциллограф под названием DSO138. Он снискал уже довольно большую популярность среди любителей электроники, но параметры этого приборчика, увы, позволяют его более-менее полноценно использовать только для отладки очень низкочастотных схем. Собственно, он и не позиционируется как инструмент, а скорее, как DIY-kit для начинающих электронщиков.
Собран этот «игрушечный» осциллограф на микроконтроллере STM32F103, и при достаточно грамотном схемотехническом решении цифровой части, наличии довольно приличного цветного дисплея 320Х240 точек, и не самом поганом аналоговом тракте, все, увы, гробится очень слабыми АЦП на борту 32F103. Заявленная полоса в 200 кГц может быть признана таковой только с очень большой натяжкой. Да, наличие или отсутствие сигнала с такой частотой он покажет, но вот реально посмотреть что-то сверх этого не получиться.
При этом есть у 103-й серии чуть более старший брат – STM32F303, по ножкам совместим практически полностью, но по интересующим нас параметрам существенно лучше, на борту 4 АЦП с частотой преобразования 5 МГц (6 МГц с 10-ти битным разрешением). При таком раскладе, если использовать все 4 АЦП параллельно с 10-ти битным разрешением, можно получить временное разрешение до честных 24 MSPS (миллионов отсчетов в секунду). Стоит микроконтроллер тоже недорого, на том же Али можно легко найти за опять же весьма умеренные деньги. Понятно, что идея поменять микроконтроллер возникла практически сразу после того, как я этот самый DSO138 и попробовал.
О том, что получилось в результате, и написана эта статья.
Зачастую разработчику, или даже пользователю, требуется посмотреть, что происходит внутри устройства. Обычно в таких ситуациях используют либо текстовой вывод в терминал (через голый UART или самописный протокол гарантированной доставки), либо пишут свои собственные системы логирования. Однако, всегда ли оправдан такой подход? Есть ли решение проще и производительнее? В данной статье мы рассмотрим одно из таких - библиотеку логирования uP7.
Давайте попробуем оптимизировать самый времязатратный этап разработки устройств на базе ПЛИС — отладку прошивки. В этой статье мы расскажем о принципе 20/80 при планировании времени, рассмотрим инструменты для отладки FPGA, вспомним Гордона Мура и Уинстона Черчилля (да-да), затроним отладку сложных распределенных систем и внешних интерфейсов, а в конце — разберемся с типичными ошибками и поделимся полезными практическими советами.
Для начала рассмотрим типовой цикл разработки и моделирования FPGA-прошивки:
Очередной «смешной случай из жизни» заставил немного понервничать.
Сопровождаемая нами программа имеет два окна: основное графическое и вспомогательное консольное. Свернутое при запуске консольное окно, как правило, нужно только при крахе системы, в нем выдаются стандартные сообщения об ошибках, и можно даже вызвать интерактивный отладчик, с помощью которого попытаться определить причину падения.
Однако при эксплуатации получилось не очень удобно. Дело в том, что если при крахе приложение снять, то, естественно, графическое окно исчезает, и пользователю, по крайней мере, сразу видно, что вся система рухнула. Правда и информация о крахе системы так же исчезает с одновременным закрытием и консольного окна. А вот если управление перехватывает отладчик в консольном (свернутом по умолчанию) окне, то графическое изображение на экране «замораживается» и при беглом взгляде может показаться, что все еще продолжает работать. Бывали случаи введения пользователя такой картиной в заблуждение. В конце концов, был найден компромисс: при исключении программа все-таки снимается, но вся информация, выдаваемая в консольном окне, дублируется еще и в файл протокола.
В нашей системе программирования так легко сделать, поскольку в системной библиотеке перед каждой выдачей очередного байта стандартного сообщения в стандартную консоль, идет проверка: а есть ли подпрограмма пользователя, которую нужно каждый раз вызывать перед очередной выдачей байта? Если есть – она вызывается с единственным параметром, этим самым байтом.
В данном курсе планируется разобрать основные особенности программирования на самой простой реализации assembler – TASM. Этих знаний лично мне вполне хватило, чтобы на отлично сдать ЭВМ в институте и закончить все лабораторные работы. Во многих уроках будет домашние задание по их мотивам.
Для начала давайте установим наш старенький компилятор.
Ссылка
Некоторые ошибки трудно воспроизвести на вашем персональном компьютере, но их легко воспроизвести на производственных или тестовых машинах. Это обычная ситуация, с которой часто сталкиваются профессиональные Java-разработчики. Для отладки таких проблем OpenJDK предоставляет два инструмента: remote debugging и jdb. Эта статья посвящена jdb.
Для приложений Java типичными производственными и тестовыми машинами являются серверы Linux без графического интерфейса, поэтому доступны только инструменты командной строки. И мы не можем использовать профессиональные IDE, такие как IntelliJ IDEA, Eclipse или Apache NetBeans IDE.
В таких сценариях мы можем использовать jdb. jdb - это отладчик командной строки, входящий в состав OpenJDK.
Это перевод руководства для начинающих. Очевидно эксперты все это знают и им не стоит тратит время на его чтение...
Представим, что в системе есть баг, но абсолютно непонятно, как его воспроизвести, а на поиск причин тратится куча времени, и ты чувствуешь себя детективом. Наверное, вам это знакомо?
Как-то в начале моей карьеры «проводник» в мир продуктовой разработки, помогая разобраться с ошибкой, говорил: «Чудес не бывает». С тех пор идёт восьмой год, а эта фраза частенько вспоминается в момент возникновения таких ситуаций, либо когда кто-то из коллег не может найти проблему и опускает руки.
Возможно Вам доводилось слышать про протокол журнала событий syslog, в котором можно насчитать аж 8 уровней важности: emergency, alert, critical, error, warning, notice, info, debug. Наверняка Вы, как и я какое-то время назад, думаете, “зачем столько”? А что если я скажу, что количество уровней там просто идеально? И использовать можно все - даже debug - для продакшн. Во всяком случае, каждому из них можно придать формальный критерий. Это особенно иронично для меня самого, так как всего пару месяцев назад я написал статью в духе “зачем так сложно!”. Так что если Вам интересно посмотреть на пример технического “переобувания” или оценить строгий алгоритм ранжирования уровней важности событий в системе - прошу.
Отладка — неотъемлемая часть профессионального программирования. К старту курса о Fullstack-разработке на Python делимся переводом о том, как отладка устроена в Facebook; в статье вы найдёте ссылку на разработанный FB плагин трассировки для LLDB, который преобразует необработанную трассировку в удобочитаемый формат.
Допустим, вы получаете уведомление по электронной почте о том, что сервис терпит крах сразу после развёртывания вашего последнего изменения кода. Сбой происходит только на 0,1 % серверов, где запущен сервис. Но вы работаете в крупной компании, поэтому 0,1 % равняется тысячам серверов, и эту проблему будет трудно воспроизвести. Несколько часов спустя вы всё ещё не можете воспроизвести проблему, хотя потратили целый день на её решение.
Перевод статьи "Why most unit testing is waste?"
Автор: James O Coplien, Перевод: Епишев Александр
1.1 Наши дни
Во времена FORTRAN, когда функция была функцией, иногда заслуживающей функциональных проверок, юнит-тестирование было одним из главных составляющих. Компьютеры производили вычисления, в то время как функции и процедуры представляли собой вычислительные блоки. В те времена доминирующий подход в дизайне предполагал создание комплексной внешней функциональности из более мелких кусков, которые, в свою очередь управляли еще более мелкими, и так далее, вплоть до уровня хорошо понятных примитивов. Каждый слой поддерживал находящийся над ним слой. В целом, у вас были большие шансы отследить, как функциональность на самом дне, так называемые функции и процедуры, были связаны с требованиями, выраженными в доступном человеку интерфейсе. Можно было рассчитывать, что хороший дизайнер поймет бизнес цель той или иной функции. Такими же возможными для понимания были и взаимосвязи в дереве вызовов, как минимум в хорошо структурированном коде. Вы могли мысленно смоделировать выполнение кода во время код-ревью.
