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

Сегодня мы рассмотрим три очень разных «консоли внутри картриджей» от трёх очень разных производителей. Для появления всех трёх систем существовали все технологические и стратегические причины, и они могут поведать нам интересную историю. Давайте начнём с самой загадочной системы — единственной из трёх, которая была нелицензионной и производилась не самим создателем консоли.

Aladdin Deck Enhancer

В начале 1990-х в офисе компании Codemasters, должно быть, находилась впечатляющая лаборатория исследований и разработок. Изначально компания была создана с целью разработки игр для домашних компьютеров Commodore, но спустя несколько лет открыла отдел по созданию нелицензионных игр и аппаратных дополнений к Nintendo Entertainment System (NES). Наверно, самым знаменитым продуктом компании, по крайней мере, в среде консольных игроков, было чит-устройство Game Genie ¹, но оно оказалось не единственным примером нелицензионного оборудования для NES.

Оверклокинг процессора или памяти — это понятно, но зачем разгонять подсветку монитора?



Речь пойдёт о стареньком 23-дюймовом Samsung SyncMaster BX2340 (выпущен в январе 2011) со светодиодной подсветкой. Со временем стал замечать, что работать за ним утомительно, а сосредоточиться всё сложнее. И даже не только работать, просто читать, например. Сам монитор остался тот же, но мне стало труднее. А за другими экранами работалось вполне нормально.

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

Работая более 20 лет в IT-индустрии, каждую новую разработку я начинал строить с проектного офиса. Более того, несколько раз мне приходилось объяснять руководству, зачем нанимать пиэмов. При наличии руководителей отделов, не так просто объяснить людям, которые не принимают непосредственного участия в разработке софта, что же именно будут делать менеджеры проектов. Приходилось преодолевать заметное сопротивление.

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

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

Big O нотация нужна для описания сложности алгоритмов. Для этого используется понятие времени. Тема для многих пугающая, программисты избегающие разговоров о «времени порядка N» обычное дело.

Если вы способны оценить код в терминах Big O, скорее всего вас считают «умным парнем». И скорее всего вы пройдете ваше следующее собеседование. Вас не остановит вопрос можно ли уменьшить сложность какого-нибудь куска кода до n log n против n^2.

Структуры данных

Выбор структуры данных зависит от конкретной задачи: от вида данных и алгоритма их обработки. Разнообразные структуры данных (в .NET или Java или Elixir) создавались под определенные типы алгоритмов.

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

Здесь мы будем использовать только массивы чисел (прямо как на собеседовании). Примеры на JavaScript.

Всем привет!

Я бэкенд-разработчик в серверной команде Badoo. На прошлогодней конференции HighLoad я выступал с докладом, текстовым вариантом которого и хочу поделиться с вами. Этот пост будет наиболее полезен тем, кто самостоятельно пишет тесты для бэкенда и испытывает проблемы с тестированием legacy-кода, а также тем, кто хочет тестировать сложную бизнес-логику.

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

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

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

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

Довольно часто спрашивают, есть ли аналоги аналитических (оконных) функций в MySQL. Примечание. На момент написания статьи таких аналогов не было, однако статья и ныне представляет собой академический интерес в плане разбора оригинального для MySQL подхода к использованию переменных.

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

Также в MySQL нет рекурсии. Однако с некоторой частью задач, которые обычно решаются аналитическими функциями или рекурсией, можно справиться и средствами MySQL.

Одним из этих средств является уникальный, нехарактерный для прочих СУБД механизм работы с переменными внутри запроса SQL. Мы можем объявить переменную внутри запроса, менять ей значение и подставлять в SELECT для вывода. Причем порядок обработки строк в запросе и, как следствие, порядок присвоения значений переменным можно задать в пользовательской сортировке!

Предупреждение. В статье подразумевается, что обработка выражений в предложении SELECT осуществляется слева направо, однако официального подтверждения такого порядка обработки в документации MySQL нет. Это необходимо иметь в виду при смене версии сервера. Для гарантии последовательности вычисления можно использовать фиктивный оператор CASE или IF.

Аналог рекурсии

Рассмотрим простой пример, который генерирует последовательность Фибоначчи (в последовательности Фибоначчи каждый член равен сумме двух предыдущих, а первые 2 равны единице):

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



Статья написана, в основном, по материалам блога, который ведёт Fabian Giesen.

При разработке высоконагруженых сетевых приложений возникает необходимость в балансировке нагрузки.

Популярным инструментом L7 балансировки является Nginx. Он позволяет кешировать ответы, выбирать различные стратегии и даже скриптить на LUA. 

Несмотря на все прелести Nginx, если: 

1. Не нужно работать с HTTP(s).
2. Нужно выжать из сети максимум.
3. Нет необходимости что либо кешировать - за балансером чистые API - сервера с динамикой.

Может возникнуть вопрос: а зачем нужен Nginx? Зачем тратить ресурсы на балансировку на L7, не проще ли просто пробросить SYN-пакет? (L4 Direct Routing).

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

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

С мыслью об отпуске вы решили сделать копию ключа и доверить её другому сотруднику. Однако вы понимаете, что это тоже не идеально. Удваивая количество ключей, вы также удвоили возможности кражи ключа.

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