Инженер-программист
Завтра будет «праздник плюшевых мишек и конфет», а сегодня — один из настоящих «мужских» праздников — Всемирный день радио. Отмечать его стали совсем недавно, в 2011-м, а выбрали для этого 13 февраля, поскольку в этот день в 1946-м было создано Радио ООН. И поэтому сегодня мы хотим вспомнить об интересном техническом хобби — любительской радиосвязи.
Человеческое тело физически не способно пробежать марафон (42 километра) меньше, чем за 1 час 58 минут. Это вычислил в 1991 году американский физик Майкл Джойнер. Он принял во внимание три фактора: максимальный объем кислорода, который способен потребить атлет, темпы распространения молочной кислоты по мышцам и максимальную эффективность бега. 1 час 58 минут – при всех идеальных условиях, и идеальном спортсмене, который не расходует энергию в своем теле ни на что, кроме бега.
В первом Олимпийском марафоне, в 1896-м, победитель, Спиридон Луис из Греции, пробежал дистанцию за 2 часа и 58 минут. Люди долго не могли поверить, что кто-то может сделать это быстрее, чем за два с половиной часа, пока в дело не вступили кенийские бегуны, славящиеся своей идеальной комплекцией для преодоления больших дистанций.
Самое быстрое время, за которое спортсмен когда-либо преодолевал марафон, сейчас составляет 2 часа, 2 минуты и 57 секунд.
Но в 2014 году группа энтузиастов, назвавшаяся Breaking2, решила побить этот рекорд. И пробить двухчасовую границу, которую большинство тренеров и атлетов считают физически невозможной.
Чтобы описать суть проблемы, мне нужно рассказать, как вообще устроен HTML. Вы наверняка в общих чертах представляли себе, но я все равно коротко пробегусь по основным моментам, которые понадобятся для понимания. Если кому-то не терпится, сразу переходите к сути.
HTML — это язык гипертекстовой разметки. Чтобы говорить на этом языке, нужно соблюдать его формат, иначе тот, кто читает написанное, не сможет вас понять. Например, в HTML у тегов есть атрибуты:
<p name="value">Тут [name] — это имя атрибута, а [value] — это его значение. В статье я буду использовать квадратные скобки вокруг кода, чтобы было понятно, где он начинается и заканчивается. После имени стои́т знак равенства, а после него — значение, заключенное в кавычки. Значение атрибута начинается сразу после первого символа кавычки и заканчивается сразу перед следующим символом кавычки, где бы он не находился. Это значит, что если вместо [value] вы запишете [OOO "Рога и копыта".], то значение атрибута name будет [OOO ], а еще у вашего элемента будет три других атрибута с именами: [рога], [и] и [копыта"."], но без значений.
<p name="OOO "Рога и копыта"."></p>Если это не то, чего вы ожидали, вам нужно как-то изменить значение атрибута, чтобы в нем не встречалась кавычка. Самое простое, что можно придумать — просто вырезать кавычки.
<p name="OOO Рога и копыта."></p>
Здравствуй, читатель! Пару лет назад в статье про vfork() я обещал рассказать про реализацию fork() для систем без MMU, но руки до этого дошли только сейчас :)fork(). Проверять работоспособность буду на сторонней программе — dash — интерпретаторе, который использует fork() для запуска приложений.
Рад приветствовать вновь всех посетителей этого славного места в интернете, чтобы привнести еще один скромный вклад.
В этот раз, он касается уже довольно избитой темы, вокруг которой всегда ходят споры, а когда суть доходит до дела оказывается, что все её реализации либо заточены для конкретной задачи, конкретным человеком, в конкретных условиях, либо не работают совсем.
Всем привет.
С середины 2016 года мы проектируем и разрабатываем новое поколение платформы. Принципиальное отличие от первого поколения — поддержка API "тонкого" клиента. Если старая платформа предполагает, что на клиента при запуске загружается метаинформация о всем контенте, который доступен для абонента, то новая платформа должна отдавать срезы данных отфильтрованные и отсортированы для отображения на каждом экране/странице.
Высокоуровневая архитектура на уровне хранения данных внутри системы — постоянное хранение всех данных в централизованном реляционном SQL хранилище. Выбор пал на Postgres, тут никаких откровений. В качестве основного языка для разработки — выбрал golang.
У системы порядка 10м пользователей. Мы посчитали, что с учетом профиля теле-смотрения, 10М пользователей может дать сотни тысяч RPS на всю систему.
Это означает, что запросы от клиентов и близко не стоит подпускать к реляционной SQL БД без кэширования, а между SQL БД и клиентами должен быть хороший кэш.
Посмотрели на существующие решения — погоняли прототипы. Данных, по современным меркам у нас немного, но параметры фильтрации (читай бизнес-логика) — сложные, и главное персонализированные — зависящие от сессии пользователя, т.е. использовать параметры запроса как ключ кэширования в K-V кэше будет очень накладно, тем более пейджинг и богатый набор сортировок никто не отменял. По сути, под каждый запрос от пользователя формируется полностью уникальный набор отфильтрованных записей.
