Пользователь
Разработчики, которые используют Go, сталкиваются с задачей выжать максимальную производительность из каждой строки кода. Но что делать, если оптимизировать уже нечего, а увеличивать скорость всё равно надо?
Меня зовут Никита Галушко. Я старший программист-разработчик в отделе высоконагруженных систем и оптимизации ВКонтакте. В статье поделюсь, какие хитрости помогут использовать Go на полную мощность.
В какой-то момент моей карьеры меня перестало радовать ПО которое я разрабатывал.
Больше всего мне нравилось работать с низкоуровневыми деталями и сложными алгоритмами. Но после перехода на пользовательские приложения эта часть работы почти исчезла. Теперь программирование казалось мне просто перемещением данных из одного места в другое с помощью уже готовых библиотек и инструментов. Знания, которые я получил раньше о программном обеспечении, уже не были такими полезными.
Ищете работу backend разработчика и хотите быть на высоте на собеседовании?
Подготовка к вопросам для backend разработчика на PHP и Go может оказаться непростой задачей. В этой статье мы разберем некоторые вопросы для Senior Backend разработчика, которые помогут вам пройти собеседование и произвести впечатление на потенциального работодателя.
Почему Важно Готовиться к Вопросам для Backend Разработчика?
Собеседование для backend разработчика включает в себя проверку технических знаний, навыков решения проблем и умения работать в команде. Заранее подготовленные ответы на популярные вопросы помогут вам чувствовать себя увереннее и показать свои лучшие стороны.
DISCLAIMER: посыл этой статьи не в том, что «PostgreSQL — гавно, не используйте PostgreSQL». Посыл в следующем: «Может быть я чего-то не понимаю в этой жизни? Пожалуйста, объясните, может быть я изменю своё мнение!»
Привет, Хабр! Представляю вашему вниманию перевод статьи "Everything you need to know about Node.js" автора Jorge Ramón.
В наши дни платформа Node.js является одной из самых популярных платформ для построения эффективных и масштабируемых REST API's. Она так же подходит для построения гибридных мобильных приложений, десктопных программ и даже для IoT.
Я работаю с платформой Node.js более 6 лет и я на самом деле люблю её. Этот пост главным образом пытается быть путеводителем по тому, как Node.js работает на самом деле.
Я давний читатель HABR‑а (кажется, с 2011 года), хотя читатель пассивный: даже не был зарегистрирован. Мне казалось, что сотрясать воздух занятие достаточно бессмысленное, а сказать что‑то новое мне особо и нечего. Но последние пару лет на HABR‑е появляется все больше и больше статей, которые условно можно охарактеризовать фразой «как вкатиться в IT». Возможно, я необъективен, но меня не покидает ощущение, что почти все статьи по этой тематике похожи друг на друга. Не дословно, конечно, но общим направлением мысли. Очень редко встречаются статьи где есть конкретика; все больше общие избитые банальные рецепты, которые, надо признать — чересчур универсальны и не могут служить руководством. Особенно
для тех, кто живет в провинции, где нет серьезных разработчиков и где, увы, негде получить необходимый опыт. Можно я расскажу о себе? Мой опыт не универсален, но это реальный опыт. Я не строю иллюзий, что это кому‑то пригодится, но если кого‑то хотя бы подбодрит — уже неплохо.
Чтобы не мусолить и не создавать ненужной интриги, скажу сразу: мне 62 года. Профессиональный стаж программиста 37 лет (с 1987 года). Вероятно, половина
читателей HABR‑а младше 37 лет, с чем я их искренно поздравляю — у вас еще много времени. Образование — высшее техническое (с углубленным изучением
математики). По основной специальности, правда, работал не долго.
Компьютеров в те годы было немного. Да, были «Синклеры», «БК» и еще целый ряд других. Народ вовсю паял свои машины, но у меня руки всегда росли не из того места, так что это увлечение прошло мимо. Тем не менее, мне повезло: КБ, где я работал по распределению, получило машину СМ-4 (клон PDP-11).
Кроме меня и еще одного парня примерно моих лет в КБ не нашлось никого, кому это было интересно. Правда, парню все это быстро надоело и я остался одни на один с этим чудом позднего Советского Союза.
Пару недель назад я прочитал о запавшем мне в душу челлендже по обработке миллиарда строк, поэтому захотел решить его на Go.
Я немного опоздал, соревнования проводились в январе. И на Java. Меня не особо интересует Java, зато давно интересует оптимизация кода на Go.
Этот челлендж был очень прост: обработать текстовый файл названий метеорологических станций и температур, и для каждой станции вывести минимальное, среднее и максимальное значение. Чтобы упростить задачу, было ещё несколько ограничений, однако я проигнорировал те, что относятся только к Java.
Началось все как у всех, с поиска работы. Изначально планировал собрать информацию об аккредитованных компаниях, чтобы в дальнейшем к ним устроиться. При поиске обнаружил, что у HeadHunter уже реализован поиск по данному критерию. Супер, но я планировал собрать контактные данные, решил ознакомиться с API HH.
Примерно шесть лет назад я написал пост о том, как пишу HTTP-сервисы на Go, и сегодня я снова хочу рассказать, как пишу HTTP-сервисы.
Тот пост оказался довольно популярным и вызвал обсуждения, повлиявшие на то, как я делаю это сегодня. И спустя годы ведения подкаста Go Time, обсуждения Go в X/Twitter и поддержки подобного кода я решил, что настало время обновить информацию.
(Если вы педант и скажете, что Go не совсем 13 лет, то я отвечу, что начал писать HTTP-сервисы на Go версии .r59.)
В этом посте рассматривается широкий спектр тем, связанных с созданием сервисов на Go
Один из самых частых вопросов в нашем сообществе разработке игр на Go — это с чего начать.
В этой серии статей мы будем изучать движок Ebitengine и создадим RPG в процессе.
Если вы пишете свой язык программирования, то вы наверное слышали о type inference. В этом цикле статей, без лишней теории, мы наглядно разберем как это работает и реализуем свой на Rust.
Прочитав статью, вы узнаете, как можно прогнозировать погоду с точностью до двух градусов на 3 месяца вперед, причем здесь преобразование Фурье и машинное обучение
Привет, чемпион!
Летом прошел чемпионат на Kaggle - "American Express - Default Prediction", требовалось предсказывать - выйдет ли пользователь в дефолт или нет. Табличное соревнование в 5К участников с очень плотным лидербордом.
Вот ведь парадокс, все умеют решать табличные соревнования, все знают, что бустинги "стреляют" точнее всех, но почему-то все равно не все могут забраться в топ лидерборда. В чем проблема?! Мы с командой все-таки смогли забрать серебро? и сейчас я расскажу, как можно было выиграть медаль в этом чемпионате.
Под этим термином понимаются такие структуры данных или алгоритмы, результатом которых является не детерминированное «да» или «нет», а вероятностные ответы, например, «точно нет» и «возможно». Как правило, такие структуры позволяют существенно сэкономить вычислительные ресурсы в задачах, где допустимо получить примерный ответ.
В этой статье я сделаю обзор таких структур данных и расскажу, какую пользу они могут принести на практике. К базовым вероятностным структурам данных можно отнести фильтр Блума, HyperLogLog и Count-Min Sketch.
Всем привет! Меня зовут Анатолий, я лидирую команду машинного обучения в онлайн-кинотеатре more.tv. В своей работе мы активно прототипируем и внедряем сервисы на основе обучения с подкреплением. Этот раздел машинного обучения всё ещё продолжает стоять особняком в индустрии, однако ситуация начинает постепенно меняться. Два года назад я впервые разработал контекстуальных бандитов для решения задачи ранжирования. По сравнению с мейнстримными listwise, pairwise и pointwise подходами, результат лично меня удивил. Конечно, как и всё, что делается в первый раз, было сделано с не очень большим пониманием дела.
Однако, уже было понимание того, что RL - парадигмально иной раздел машинного обучения, требующий, в каком-то смысле, перестроения способа мышления. Полученный результат заставил меня более детально разбираться с теоретическими основами обучения с подкреплением и различными постановками задач.
Я более чем уверен, что мой пример не является аномалией или каким-то выдающимся случаем. Умея разрабатывать RL, каждый сможет существенно улучшить качество имеющихся ML/DL моделей, которые уже хорошо зарекомендовали себя в проде, или разработать собственное перспективное sota-решение для нового сервиса. Мне всегда было интересно разобраться в том, какие новаторские способы применяются в ML за пределами мейнстримных библиотек и сервисов. К примеру, в первую очередь я ознакомился не с функциональностью chatGPT, а с её разработкой по исходной статье.
Возможно, я “подсмотрю” интересное решение, которое смогу применить в своём рабочем проекте? А если и не получится, то получу опыт и расширю кругозор. И как же было забавно наблюдать, что RL подходы, описанные в оригинале статьи о разработке chatGPT, я уже применил на практике вместе со своей командой в наших бизнес-задачах.
Уже много времени прошло с момента публикации наших последних языковых моделей ruT5, ruRoBERTa, ruGPT-3. За это время много что изменилось в NLP. Наши модели легли в основу множества русскоязычных NLP-сервисов. Многие коллеги на базе наших моделей выпустили свои доменно-адаптированные решения и поделились ими с сообществом. Надеемся, что наша новая модель поможет вам поднять метрики качества, и ее возможности вдохновят вас на создание новых интересных продуктов и сервисов.
Появление ChatGPT и, как следствие, возросший интерес к методам обучения с подкреплением обратной связью от человека (Reinforcement Learning with Human Feedback, RLHF), привели к росту потребности в эффективных архитектурах для reward-сетей. Именно от «интеллекта» и продуктопригодности reward-модели зависит то, насколько эффективно модель для инструктивной диалоговой генерации будет дообучаться, взаимодействуя с экспертами. Разрабатывая FRED-T5, мы имели в виду и эту задачу, поскольку от качества её решения будет во многом зависеть успех в конкуренции с продуктами OpenAI. Так что если ваша команда строит в гараже свой собственный ChatGPT, то, возможно, вам следует присмотреться и к FRED’у. Мы уже ранее рассказывали в общих чертах об этой модели, а сейчас, вместе с публичным релизом, настало время раскрытия некоторых технических подробностей.
Появление новых, более производительных GPU и TPU открывает возможности для использования в массовых продуктах и сервисах всё более емких моделей машинного обучения. Выбирая архитектуру своей модели, мы целились именно в ее пригодность к массовому realtime-инференсу, поскольку время выполнения и доступное оборудование — это основные факторы, лимитирующие возможность создания массовых решений на основе нейросетевых моделей. Если вы уже используете в своем решении модель ruT5, то подменив ее на FRED-T5 вы, вероятно, получите заметное улучшение значений ваших целевых метрик. Конечно, в скором будущем мы обучим еще более емкие варианты модели FRED-T5 и проверим их возможности — мы планируем и дальнейшее развитие линейки энкодер-декодерных моделей для обработки русского языка.
В сфере высокочастотной торговли зачастую борются за любое уменьшение сетевой задержки, ведь это дает возможность получить информацию об изменении цены инструмента раньше остальных и отправить заявку на исполнение быстрее конкурентов по более выгодным условиям. Нередко можно встретить такие решения, как отказ от промежуточного сетевого оборудования в виде сетевого коммутатора, который мог бы обеспечить использование торгового подключения несколькими серверами сразу. Но зачем подключать каждый сервер напрямую к инфраструктуре биржи, если можно платить за один аплинк и подключить его в классический ToR(Top-of-rack) коммутатор? Конечно для уменьшения сетевой задержки, ведь современный сетевой коммутатор внесет лишние 200-500 наносекунд задержки.
Конечно можно обратиться к low-latency коммутаторам, базирующимся на FPGA матрицах, таким как серия Cisco Nexus 3550 Fusion (в прошлом Exablaze ExaLINK Fusion) или Arista 7130 Series (в прошлом Metamako MetaMux).
Точное определение времени и его синхронизация чрезвычайно важна в мире высокочастотной торговли.
Конечно же, синхронизация времени важна в общей инфраструктуре компании, думаю многие из вас встречались хотя бы раз с проблемами, вызванными некорректным временем на сервере, выполняющим ту или иную роль. Например, возможно некорректное формирование бэкапов, задержка в обработке запросов, некорректная интерпретация валидности сертификатов, ошибки аутентификации и авторизации и т. д. Тут на помощь придет NTP (Network Time Protocol) протокол, который широко распространен повсеместно, а далеко не только в HFT отрасли. Наилучшая точность синхронизации времени с помощью NTP будет порядка 1мс и то, в случае если NTP сервер находится в локальной сети с вашим сервером, а также оптимально настроен, например, дает опрашивать себя достаточно часто. Для среднего случая, когда NTP сервер будет использоваться из интернета, вы сможете добиться 10-100 мс точности, а если сетевой путь до источника времени будет совсем не идеален (зачастую колокация биржи может предоставлять только IPSec туннель в качестве доступа до вашей биржевой инфраструктуры), то и сотен миллисекунд.
Решение же торгового алгоритма об отправке заявки на биржу может и не опираться на абсолютное время.
