Я смотрю на кусок кода. Возможно, это худший код, что мне когда-либо встречался. Чтобы обновить всего одну запись в базе данных, он извлекает все записи в коллекции, а затем отправляет запрос на обновление каждой записи в базе, даже тех, которые обновлять не требуется. Тут есть map-функция, которая просто возвращает переданное ей значение. Есть условные проверки переменных с очевидно одинаковым значением, просто поименованных в разных стилях (firstName и first_name). Для каждого UPDATE’а код отправляет сообщение в другую очередь, которая обрабатывается другой serverless-функцией, но которая выполняет всю работу для другой коллекции в той же базе данных. Я не упомянул, что эта serverless-функция из облачной «сервис-ориентированной архитектуры», содержащей более 100 функций в окружении?

Как вообще можно было такое сделать? Я закрываю лицо и явственно всхлипываю сквозь смех. Мои коллеги спрашивают, что случилось, и я в красках пересказываю Worst Hits Of BulkDataImporter.js 2018. Все сочувственно кивают мне и соглашаются: как они могли так с нами поступить?

Ищете красивую цветовую палитру для сайта? Недавно установили дома RGB-подсветку, или хотите покрасить комнату в новые цвета? Или купили клавиатуру с цветной подсветкой и хотите использовать её по полной? В какой бы ситуации вы ни оказались, наверняка постоянно настраиваете цветовые схемы.

Будучи программистом, я быстро написал несколько строк кода для генерирования случайных цветовых палитр. Сразу почуяв, что такой подход может дать не лучшие результаты, я за пару минут реализовал кнопку «перезагрузки» палитры. Мне представлялось, что для получения прекрасной схемы просто нужно немного удачи и терпения.

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

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

Тема модульного тестирования не так проста, как может показаться. Многие из нас, разработчиков, приходят в модульное тестирование под давлением клиентов, сотрудников, коллег, своих кумиров и так далее. Мы быстро понимаем его ценность, и, закончив технические приготовления, забываем об общей картине, если вообще когда-либо её понимали. В этой статье я вкратце расскажу о том, чем является и чем не является модульное тестирование как в целом, так и в PHP, а заодно опишу, какое место занимает модульное тестирование в сфере QA.

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

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

Умение писать код, который легко отлаживать, начинается с понимания, что вы ничего не помните о ранее написанном.

Принципы SOLID — это стандарт программирования, который все разработчики должны хорошо понимать, чтобы избегать создания плохой архитектуры. Этот стандарт широко используется в ООП. Если применять его правильно, он делает код более расширяемым, логичным и читабельным. Когда разработчик создаёт приложение, руководствуясь плохой архитектурой, код получается негибким, даже небольшие изменения в нём могут привести к багам. Поэтому нужно следовать принципам SOLID.

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

Чтобы понять принципы SOLID, нужно чётко понимать, как использовать интерфейсы. Если у вас такого понимания нет, то сначала почитайте документацию.

Я буду объяснять SOLID самым простым способом, так что новичкам легче будет разобраться. Будем рассматривать принципы один за другим.

Я 10 лет разрабатываю ПО, участвовал в нескольких open source-проектах и в многочисленных не-open source-проектах, работал в больших и малых командах, и везде мы использовали Github в качестве репозитория версионирования.

За это время я перепробовал разные рабочие процессы, и хочу поделиться советами, как построить эффективный и прагматичный рабочий процесс по созданию и сопровождению качественного ПО, который можно применять в любом проекте.

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

Прежде чем заняться реализацией runtime и изучением стандартной библиотеки, необходимо освоить абстрактный ассемблер Go. Надеюсь, это руководство поможет вам быстро овладеть нужными знаниями.

Вы наверняка это слышали: «Хороший код является самодокументированным».

Я больше 20 лет зарабатываю написанием кода, и слышал эту фразу чаще всего. Это клише.

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

Она истинна? Да.

Означает ли она, что вы никогда не должны комментировать код? Нет.

В этой статье мы рассмотрим разные аспекты комментирования кода.

В былые времена люди использовали \a для генерирования неприятных «гудков» из спикеров системных блоков. Это было особенно неудобно, если хотелось генерировать более сложные звуковые последовательности вроде 8-битной музыки. Поэтому Джонатан Найтингейл написал программу beep. Это была коротенькая и очень простая программа, позволявшая тонко настраивать звучание из спикера.

С появлением X-сервера всё стало куда сложнее.

Чтобы beep могла работать, пользователь должен был либо быть суперпользователем, либо являться владельцем текущего tty. То есть beep всегда будет работать у root-пользователя или у любого локального, но не будет работать у не-root удалённого пользователя. При этом любой терминал (например, xterm), подключённый к X-серверу, считается «удалённым», и поэтому beep работать не будет.

У Go есть некоторые замечательные свойства, которым посвящён раздел «Хороший». Но когда речь заходит о применении этого языка не для создания API или сетевых серверов (для чего он и был разработан), а для реализации бизнес-логики, то я считаю Gо слишком неуклюжим и неудобным. Хотя даже в рамках сетевого программирования найдётся немало подводных камней как в архитектуре языка, так и в реализации, что делает Go опасным, несмотря на его кажущуюся простоту.

Книга «Безопасность в PHP» (часть 1)
Книга «Безопасность в PHP» (часть 2)
Книга «Безопасность в PHP» (часть 3)
Книга «Безопасность в PHP» (часть 4)

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

1. Для случайного выбора опций из пула или диапазона известных опций.
2. Для генерирования векторов инициализации при шифровании.
3. Для генерирования непредсказуемых токенов или одноразовых значений при авторизации.
4. Для генерирования уникальных идентификаторов, например ID сессий.

Книга «Безопасность в PHP» (часть 1)
Книга «Безопасность в PHP» (часть 2)
Книга «Безопасность в PHP» (часть 3)

Связь через интернет между участниками процесса сопряжена с рисками. Когда вы отправляете платёжное поручение в магазин, используя онлайн-сервис, то совершенно точно не хотите, чтобы злоумышленник мог его перехватить, считать, изменить или заново повторить HTTP-запрос к онлайн-приложению. Только представьте себе последствия того, что атакующий считает куку вашей сессии или изменит получателя платежа, товар, платёжный адрес. Или внедрит в разметку, отправляемую магазином в ответ на запрос пользователя, свой HTML или JavaScript.

Книга «Безопасность в PHP» (часть 1)
Книга «Безопасность в PHP» (часть 2)

Межсайтовый скриптинг (XSS) — пожалуй, самый типичный вид уязвимостей, широко распространённых в веб-приложениях. По статистике, около 65 % сайтов в той или иной форме уязвимы для XSS-атак. Эти данные должны пугать вас так же, как пугают меня.

Книга «Безопасность в PHP» (часть 1)

В списке десяти наиболее распространённых видов атак по версии OWASP первые два места занимают атаки с внедрением кода и XSS (межсайтовый скриптинг). Они идут рука об руку, потому что XSS, как и ряд других видов нападений, зависит от успешности атак с внедрением. Под этим названием скрывается целый класс атак, в ходе которых в веб-приложение внедряются данные, чтобы заставить его выполнить или интерпретировать вредоносный код так, как это нужно злоумышленнику. К таким атакам относятся, например, XSS, внедрение SQL, внедрение заголовка, внедрение кода и полное раскрытие путей (Full Path Disclosure). И это лишь малая часть.

У меня есть для вас непростое задание. Когда в следующий раз начнёте новый проект, постарайтесь обойтись без PHP-фреймворка. Я не собираюсь перечислять недостатки фреймворков, и это не проявление синдрома неприятия чужой разработки: в этом руководстве мы будем использовать пакеты, написанные разработчиками нескольких фреймворков. Я всецело уважаю инновации в этой сфере.

Генераторы классные. Они облегчают написание итераторов, определяя функции вместо создания целых классов, реализующих Iterator. Также генераторы помогают создавать ленивые списки (lazy list) и бесконечные потоки. Главное отличие функции-генератора от обычной функции в том, что обычная может возвращать только один раз (после этого её исполнение прекращается), а функция-генератор в ходе исполнения способна выдавать несколько значений. При этом в перерывах между возвратами исполнение генератора ставится на паузу до следующего запуска. Поэтому генераторы могут использоваться для создания списков с лениво генерируемыми значениями, то есть каждый элемент в списке вычисляется только в момент востребованности.

В этой статье мы с нуля разработаем React-приложение, обсудим домен и его сервисы, хранение, сервисы приложения и представление (view).

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

Привет, я Тони Альбрехт (Tony Albrecht), инженер в Riot. Мне нравится профилировать и оптимизировать. В этой статье я расскажу об основах профилирования, а также проанализирую пример С++-кода в ходе его профилирования на Windows-машине. Мы начнём с самого простого и будем постепенно углубляться в потроха центрального процессора. Когда нам встретятся возможности оптимизировать — мы внедрим изменения, а в следующей статье разберём реальные примеры из кодовой базы игры League of Legends. Поехали!