На недавнем вебинаре getmatch я рассказала про сложности при устройстве на работу в США, если ты не инженер, отличия менталитетов и собеседований в двух странах. Эта статья — дополнение предыдущей, привожу ответы на вопросы в тексте.

Многие, кто уже пользуется explain.tensor.ru — нашим сервисом визуализации планов PostgreSQL, возможно, не в курсе одной из его суперсособностей — превращать сложно читаемый кусок лога сервера…


… в красиво оформленный запрос с контекстными подсказками по соответствующим узлам плана:


В этой расшифровке второй части своего доклада на PGConf.Russia 2020 я расскажу, как нам удалось это сделать.

С транскриптом первой части, посвященной типовым проблемам производительности запросов и их решениям, можно ознакомиться в статье «Рецепты для хворающих SQL-запросов».

Введение

Некоторое время назад передо мной поставили задачу разработать отказоустойчивый кластер для PostgreSQL, работающий в нескольких дата-центрах, объединенных оптоволокном в рамках одного города, и способный выдержать отказ (например, обесточивание) одного дата-центра. В качестве софта, который отвечает за отказоустойчивость, выбрал Pacemaker, потому что это официальное решение от RedHat для создания отказоустойчивых кластеров. Оно хорошо тем, что RedHat обеспечивает его поддержку, и тем, что это решение универсальное (модульное). С его помощью можно будет обеспечить отказоустойчивость не только PostgreSQL, но и других сервисов, либо используя стандартные модули, либо создавая их под конкретные нужды.

К этому решению возник резонный вопрос: насколько отказоустойчивым будет отказоустойчивый кластер? Чтобы это исследовать, я разработал тестовый стенд, который имитирует различные отказы на узлах кластера, ожидает восстановления работоспособности, восстанавливает отказавший узел и продолжает тестирование в цикле. Изначально этот проект назывался hapgsql, но со временем мне наскучило название, в котором только одна гласная. Поэтому отказоустойчивые базы данных (и float IP, на них указывающие) я стал именовать krogan (персонаж из компьютерной игры, у которого все важные органы дублированы), а узлы, кластеры и сам проект — tuchanka (планета, где живут кроганы).

Сейчас руководство разрешило открыть проект для open source-сообщества под лицензией MIT. README в скором времени будет переведен на английский язык (потому что ожидается, что основными потребителями будут разработчики Pacemaker и PostgreSQL), а старый русский вариант README я решил оформить (частично) в виде этой статьи.

Ранее мы уже разбирали последовательность запуска сервера на примере устаревшего Legacy. Настало время познакомиться с UEFI поближе.

Первая версия того, что сейчас известно как Unified Extensive Firmware Interface (UEFI), разрабатывалась в 90-е годы прошлого тысячелетия специально под системы на Intel® Itanium® и называлась Intel Boot Initiative, а позже — EFI.

Желание «обновить» процесс загрузки было ожидаемо. PC-BIOS, именуемый ныне Legacy, предлагает работать в 16-битном real mode, адресует всего 1 МБ оперативной памяти, а загрузчик вместе с таблицей разделов должен размещаться в первых 512 байтах накопителя. Более того, PC-BIOS передает управление первому найденному загрузчику без возможности возврата назад. При этом обработку случаев с несколькими операционными системами возлагают на плечи загрузчика.

Привет, Хабр! Меня зовут Паша Доронин и бóльшую часть жизни я работаю в индустрии переводов и локализации. Я долгое время проработал в компании Smartcat, где прошел путь от аналитика до менеджера по продукту. Несколько месяцев назад я переехал в Дублин и решил заняться дальнейшим развитием своей карьеры.

На этот раз я решил сменить схему поиска вакансий – раньше я просто смотрел на то, «что есть», и выбирал интересные варианты. Теперь же хотелось исходить из того, что хочу получить на новом месте я, и уже соответственно фильтровать объявления. За период активного поиска я связался с 17 компаниями из Европы и США, и устроился в AI-стартап Intento (недавно поднял новый раунд инвестиций). Вот что я понял по итогам этого процесса.

Пользуетесь ли вы структурами данных и алгоритмами в повседневной работе? Я обратил внимание на то, что всё больше и больше людей считает алгоритмы чем-то таким, чем, без особой связи с реальностью, технические компании, лишь по собственной прихоти, интересуются на собеседованиях. Многие жалуются на то, что задачи на алгоритмы — это нечто из области теории, имеющей слабое отношение к настоящей работе. Такой взгляд на вещи, определённо, распространился после того, как Макс Хауэлл, автор Homebrew, опубликовал твит о том, что произошло с ним на собеседовании в Google:

Google: 90% наших инженеров пользуются программой, которую вы написали (Homebrew), но вы не можете инвертировать бинарное дерево на доске, поэтому — прощайте.

Хотя и у меня никогда не возникало нужды в инверсии бинарного дерева, я сталкивался с примерами реального использования структур данных и алгоритмов в повседневной работе, когда трудился в Skype/Microsoft, Skyscanner и Uber. Сюда входило написание кода и принятие решений, основанное на особенностях структур данных и алгоритмов. Но соответствующие знания я, по большей части, использовал для того чтобы понять то, как созданы некие системы, и то, почему они созданы именно так. Знание соответствующих концепций упрощает понимание архитектуры и реализации систем, в которых эти концепции используются.



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

Экзамены английского языка вызывают у большинства разработчиков негативную реакцию. В сети или в курилке часто можно услышать утверждения о том, что TOEFL/IELTS проверяют не уровень владения языком, а умение соответствовать шаблонам. Разработчики цепляются за свой B1 или даже B2/C1, который им дали на внутреннем ассессменте в компании или при прохождении 10-минутного онлайн-теста. Далее, у нас есть 2 пути. Вы можете принять ваш уровень и не развиваться, думая что вам «не нужно», «не моё» и так далее. Можете найти 100 причин отрицать международные общепринятые тесты и даже обойти их при миграции. А можете согласиться с тем, что ваш уровень не достаточно хорош при объективной оценке по критериям, и подумать над развитием и пользе для карьеры разработчика. Статья будет именно про второй путь, а конкретно:

1. Развитие скорости чтения и использование правого полушария мозга вместо левого
2. Накрутка навыка письма через независимые эссе внутри Grammarly
3. Турбонакрутка разговорной речи через комментирование своих действий в играх (RPG/RTS)
4. Ускорение с помощью слепой печати
5. Контроль промежуточных результатов через TOEFL GO

Источник: unsplash.com

По словам Джеки Стюарта, трехкратного чемпиона мира по гонкам Формулы-1, понимание автомобиля помогло ему стать лучшим пилотом: «Гонщику не обязательно быть инженером, но нужен интерес к механике».

Мартин Томпсон (создатель LMAX Disruptor) применил эту концепцию к программированию. Если в двух словах, то понимание базового оборудования улучшит ваши навыки, когда речь заходит о разработке алгоритмов, структур данных и так далее.

Команда Mail.ru Cloud Solutions перевела статью, автор которой углубился в устройство процессора и рассмотрел, как понимание некоторых концепций CPU помогает принимать оптимальные решения.

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

Приветствую!

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

Всё это время я также наблюдал на разных ресурсах посты о «разработке ОС», которые в основном сводились к выводу «hello world» в QEMU, и сетовал на то, что не нужно путать ОС и «программу, которая может работать на голом железе». ОС это совсем не про работу на железе, это, в первую очередь, про синхронизацию и все такое прочее.

PGConfRu2019 Павел Молявин — «Готовим PostgreSQL в эпоху DevOps. Опыт 2ГИС»**

Всем привет! Меня зовут Павел! Я работаю в компании 2ГИС. Наша компания – это городской информационный справочник, навигационный сервис. Это очень хорошая штука, которая помогает жить в городе.

Прелюдия

Это третья из четырех статей в серии, которая даст представление о механике и дизайне указателей, стеков, куч, escape analysis и семантики значения/указателя в Go. Этот пост посвящен профилированию памяти.

Оглавление цикла статей:

1. Language Mechanics On Stacks And Pointers (перевод)
2. Language Mechanics On Escape Analysis (перевод)
3. Language Mechanics On Memory Profiling
4. Design Philosophy On Data And Semantics

Посмотрите это видео, чтобы увидеть демонстрацию этого кода:
DGopherCon Singapore (2017) — Escape Analysis

Вступление

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

Привет, меня зовут Сергеев Сергей aka gurugray. Сейчас я «Mentor FrontEnd Community» в компании ManyChat. Вы могли видеть мои лекции по релизному циклу и регламенту работ с системами контроля версий в Школе Разработки Интерфейсов Яндекса (ШРИ).

Меня часто спрашивают какие life-hacks или best-practices я использую при работе с Git'ом и репозиториями проекта.

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

В один день я просматривал различные видео на YouTube, связанные с персонажами программы Vocaloid (не совсем точное описание, но дальше буду называть просто вокалоидами). Одним из таких видео было так называемое PV из игры Hatsune Miku: Project DIVA 2nd. А именно песня relations из The Idolmaster, которую исполняли вокалоиды Megurine Luka и Kagamine Rin. Оба персонажа от Crypton Future Media. Порыскав по сети я понял, что никто так и не смог сконвертировать анимации из этой игры? Но почему? Об этом под катом.

Traefik — это обратный прокси-сервер с открытым исходным кодом, обеспечивающий простую работу с микросервисами и/или просто контейнерами с вашими приложениями.

Обратный прокси-сервер (reverse proxy, реверс-прокси) служит для ретрансляции запросов из внешней сети к каким-либо серверам/сервисам внутренней сети (например веб-сервера, БД или файловые хранилища) и позволяет:

• обеспечить сокрытие структуры внутренней сети и подробностей о находящейся в ней сервисах;
• осуществлять балансировку нагрузки (load balancing) между экземплярами одного и того же сервиса или серверами с одинаковыми задачами;
• обеспечить зашифрованное (HTTPS) соединение между клиентом и любым сервисом, в таком случае SSL сессия создается между клиентом и прокси, а между прокси и сервисом во внутренней сети устанавливается незашифрованное HTTP соединение, если сервис поддерживает HTTPS то можно организовать зашифрованное соединение и во внутренней сети;
• организовать контроль доступа к сервисам (аутентификацию клиента), а также установить файрвол (брандмауэр).

В статье будет описываться использование Traefik в Docker в качестве реверс-прокси для других контейнеров Docker, а также не контейнеризированных сервисов.

Долгое время Rust позиционировался исключительно как язык для системного программирования. Попытки использовать Rust для высокоуровневых прикладных задач зачастую вызывали усмешку у значительной части сообщества: зачем использовать инструмент в том качестве, на которое он не рассчитан? Какая польза от возни с типами и анализатором заимствований (borrow checker), если есть Python и Java со сборкой мусора? Но другая часть сообщества всегда видела потенциал Rust именно как языка прикладного, и даже находила его удобным в использовании для быстрого прототипирования — во многом благодаря его особенностям, а не вопреки им.

Я работаю Software Engineer в Farmers Insurance. Мой отдел занимается внедрением чат-бота в структуры бизнеса и его усовершенствованием для уменьшения нагрузки на службу поддержки компании. Сейчас один из моих проектов — анализ сообщений от клиентов и предсказание интента с помощью NLP алгоритмов. Я живу и работаю в Лос-Анджелесе. В Америку мы с женой Юлей переехали в октябре 2018 года.

Четыре года назад, я жил в Сибири, г.Кемерово. Работал Экологом в проектном институте. У меня были очень скудные познания в программировании и машинном обучении, но была четкая цель переобучиться и устроится работать программистом.

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

English article here.

Целевая аудитория

Вы разработчик, который хочет повернуть свою карьеру в сторону более совершенной модели DevOps? Вы являетесь классическим Ops-инженером и хотели бы получить представление о том, что означит DevOps? Или же вы не являетесь ни тем, ни другим и, потратив некоторое время на работу в области ИТ-технологий, хотите поменять работу и понятия не имеете, с чего начать?
Если да, то читайте дальше, чтобы узнать, как можно стать инженером DevOps среднего уровня за шесть месяцев! Наконец, если вы уже много лет занимаетесь DevOps, то все равно сможете почерпнуть много полезного из этого цикла статей и узнать, где находится отрасль интеграции и автоматизации в данный момент и куда она стремится в своем развитии.

Всем привет. Мы подготовили перевод еще одного полезного материала в преддверии старта курса «Разработчик С#». Приятного прочтения.

---

Поскольку недавно мне довелось составлять список лучших практик в C# для Criteo, я подумал, что было бы неплохо поделиться им публично. Цель этой статьи — предоставить неполный список шаблонов кода, которых следует избегать, либо потому что они сомнительны, либо потому что просто плохо работают. Список может показаться немного рандомным, потому что он слегка выдернут из контекста, но все его элементы в какой-то момент были обнаружены в нашем коде и вызывали проблемы в продакшене. Надеюсь, это послужит хорошей профилактикой и предотвратит ваши ошибки в будущем.

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

И последнее, но не менее важное: некоторые пункты (например, ConfigureAwait) уже обсуждались во многих статьях, поэтому я не буду подробно останавливаться на них. Цель заключается в том, чтобы сформировать компактный список моментов, на которые нужно обращать внимание, а не давать подробную техническую выкладку по каждому из них.

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

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

Выкладываем расшифровку прямого эфира с Илоной Папавой, Senior Software Engineer в Лондонском офисе Facebook: она рассказала как попасть на стажировку, что на них ждет стажеров, как показать себя и получить оффер и почему лондонский офис во многом превосходит офис в Долине.