Иногда приходит время остановиться и взглянуть по-новому на то, что ты делаешь. Что если прежние решения когда-то казались верными, а теперь создают проблемы? Наберитесь храбрости и начните с чистого листа. А я тем временем расскажу, как 8 лет назад компания QIWI сделала коммерчески правильный выбор при запуске продукта, но в 2015 пришлось многое переделать.
Имеется многогигабайтный файл, содержащий массив целых чисел от 1 до 10000. Элементы расположены хаотично с повторениями. Необходимо его отсортировать. Принять во внимание ограниченность в ресурсах.
В предыдущей части мы показали, что в клеточном автомате могут возникать волны, имеющие специфический внутренний узор. Такие волны могут запускаться из любого места клеточного автомата и распространяться по всему пространству клеток автомата, перенося информацию. Соблазнительно предположить, что реальный мозг может использовать схожие принципы. Чтобы понять возможность аналогии, немного разберемся с тем, как работают нейроны реального мозга.
"О" большое — это отличный инструмент. Он позволяет быстро выбрать подходящую структуру данных или алгоритм. Но иногда простой анализ "О" большого может обмануть нас, если не подумать хорошенько о влиянии константных множителей. Пример, который часто встречается при программировании на современных процессорах, связан с выбором структуры данных: массив, список или дерево.
В начале 1980-х время, необходимое для получения данных из ОЗУ и время, необходимое для произведения вычислений с этими данными, были примерно одинаковым. Можно было использовать алгоритм, который случайно двигался по динамической памяти, собирая и обрабатывая данные. С тех пор процессоры стали производить вычисления в разы быстрее, от 100 до 1000 раз, чем получать данные из ОЗУ. Это значит, что пока процессор ждет данных из памяти, он простаивает сотни циклов, ничего не делая. Конечно, это было бы совсем глупо, поэтому современные процессоры содержат несколько уровней встроенного кэша. Каждый раз когда вы запрашиваете один фрагмент данных из памяти, дополнительные прилегающие фрагменты памяти будут записаны в кэш процессора. В итоге, при последовательном проходе по памяти можно получать к ней доступ почти настолько же быстро, насколько процессор может обрабатывать информацию, потому что куски памяти будут постоянно записываться в кэш L1. Если же двигаться по случайным адресам памяти, то зачастую кэш использовать не получится, и производительность может сильно пострадать. Если хотите узнать больше, то доклад Майка Актона на CppCon — это отличная отправная точка (и отлично проведенное время).
Использование монги в production — достаточно спорная тема.
С одной стороны все просто и удобно: положили данные, настроили репликацию, понимаем как шардировать базу при росте объема данных. С другой стороны существует достаточно много страшилок, Aphyr в своем последнем jepsen тесте сделал не очень позитивные выводы.
По факту оказывается, что есть достаточно много проектов, где mongo является основным хранилищем данных, и нас часто спрашивали про поддержку mongodb в окметр. Мы долго тянули с этой задачей, потому что сделать "осмысленный" мониторинг на порядок сложнее, чем просто собрать какие-то метрики и настроить какие-нибудь алерты. Нужно сначала разобраться в особенностях поведения софта, чтобы понять, какие именно показатели отслеживать.
Как раз про сложности и проблемы я и хочу рассказать на примере реализации мониторинга запросов к mongodb.
В сегодняшней статье поговорим о неотъемлемой составляющей большого числа современных веб-проектов — о фреймворках.
Роман Ивлиев на примере множества проектов портала banki.ru, а также заказной разработки в студии крупных проектов Онтико. Рассмотрим следующие темы и поищем ответы на вопросы:
Банки.ру — проект с 10-летней историей. В разные времена banki.ru испытывали разные нагрузки. Портал перестраивался под новые требования как логически, так и технологически, что-то мы меняли в авральном режиме, что-то — эволюционным путём. Сейчас средняя посещаемость примерно 2 миллиона просмотра страниц, т.е. проект уже не маленький, но ещё и не совсем большой.
Эта статья — расшифровка доклада Романа Ивлиева (CIO Banki.ru) на обучающей конференции HighLoad++ Junior, которая прошла пару месяцев назад в Москве в рамках фестиваля “Российские интернет-технологии”.
В этой статье мы хотим поговорить об оптимизации, её своевременности, и о субоптимизации, о том, что далеко не всегда лучшие практики разработки нагруженных систем идут на пользу бизнесу.
Посмотрим примеры и поищем ответы на вопросы:
В заключение Роман Ивлиев расскажет про несколько примеров из жизни banki.ru в части замены технологических решений в области высоких нагрузок, и что из этого вышло.
— Андрей, вы знакомы с трудами Michael Feathers, например, «Working Effectively with Legacy Code»? В книге акцентируется внимание на важности тестирования и выделяется одно из ключевых отличий legacy от не legacy-кода — это наличие тестов. Вы согласны с этим мнением? 
Какой язык использовали для написания самых первых программ для самых первых компьютеров с хранимой программой?
Почему?
Насколько легче писать программы на ассемблере, чем на двоичном машинном языке?
Можно цифру? Во сколько раз легче?
Примечание переводчика: в перерывах между холиварами про JS предлагаю обсудить несерьёзную, пятничную тему:
Кто не любит эмодзи? Активно используя их в мессенджерах и почтовых приложениях, я решил проэкспериментировать с тем, как можно применить их с умом в повседневной разработке приложений. Хотя поначалу это была просто шутка, эмодзи действительно оказались полезными в ряде случаев. Как так?
Мы, программисты, читаем много текста — будь то код, логи, комментарии к коммитам, документация или что-либо еще. Эмодзи бросаются в глаза, и их гораздо легче найти на простыне текста, чем обычную строку. Быстрее поиск — выше продуктивность. Хотя даже если на вашей продуктивности это никак не скажется, пользоваться эмодзи — весело! Вот некоторые вещи, которые я опробовал на практике:
Наша команда, аналогично с автором статьи, уже почти как год перешла со Scala на Kotlin в качестве основного языка. Мое мнение во многом совпадает с автором, поэтому предлагаю вам перевод его интересной статьи.
Прошло прилично времени с того момента как я не обновлял блог. Вот уже как год я перешел со Scala, моего основного языка, на Kotlin. Язык позаимствовал много хороших вещей, которые мне нравились в Scala, сумев при этом избежать многих подводных камней и неоднозначности, которая есть в Scala.
Ниже я хочу привести примеры, которые мне нравятся в Scala и Kotlin, а также их сравнение в том, как они реализованы в обоих языках.
