Web engineer
Привет, из-за последних событий решил поделиться материалами по собеседованиям в зарубежные компании, которые сам собирал последние несколько лет. Описанное ниже - смесь из личного опыта, историй на различных форумах и анекдотов собранных через знакомых - поехали.
Довольно часто возникает необходимость визуально представлять результаты работы устройства в том или ином человеко-понятном виде (текст, картинка, видео). Если это устройство не является абсолютно автономным, то задача решается проще, мы не сильно зависим от источника питания. На просторах Хабра есть ряд публикаций, посвященных различным метеостанциям и другим устройствам с экранами, подключенных к постоянному питанию.
А вот если нам нужно собрать полностью мобильное устройство, работающее от аккумуляторов, то здесь проблема потребления питания может стать достаточно острой. Так, при сборке собственного планшета на базе Raspberry Pi 3 мне пришлось выделить под тачскрин отдельный аккумулятор, так как при использовании общего источника (Li-Po, 6000 мАмпер-часов) питания устройство могло проработать более часа, но при запуске какого-либо ресурсоемкого приложения резко возрастал ток потребления и устройство тупо отрубалось, так как аккумулятор просто не мог выдать такой ток.
Поговорим с нашим фронтенд-инженером Ильёй Алоновым про преимущества и недостатки JS Self-Profiling, посмотрим, как им пользоваться, и узнаем, какие есть подводные камни и как их обойти. Если интересуетесь перформансом веб-приложений — не проходите мимо :)
В конце июля 2016 года в корпоративном блоге Uber появилась поистине историческая статья о причинах перехода компании с PostgreSQL на MySQL. С тех пор в жарких обсуждениях этого материала было сломано немало копий, аргументы Uber были тщательно препарированы, компанию обвинили в предвзятости, технической неграмотности, неспособности эффективно взаимодействовать с сообществом и других смертных грехах, при этом по горячим следам в Postgres было внесено несколько изменений, призванных решить некоторые из описанных проблем. Список последствий на этом не заканчивается, и его можно продолжать еще очень долго.
Наверное, не будет преувеличением сказать, что за последние несколько лет это стало одним из самых громких и резонансных событий, связанных с СУБД PostgreSQL, которую мы, к слову сказать, очень любим и широко используем. Эта ситуация наверняка пошла на пользу не только упомянутым системам, но и движению Free and Open Source в целом. При этом, к сожалению, русского перевода статьи так и не появилось. Ввиду значимости события, а также подробного и интересного с технической точки зрения изложения материала, в котором в стиле «Postgres vs MySQL» идет сравнение физической структуры данных на диске, организации первичных и вторичных индексов, репликации, MVCC, обновлений и поддержки большого количества соединений, мы решили восполнить этот пробел и сделать перевод оригинальной статьи. Результат вы можете найти под катом.
Ночь. Стук в дверь. Открыть. Стоят двое. "Верите ли вы в Event loop, нашу главную браузерную цепочку?" Вздохнуть. Закрыть дверь. Лечь досыпать. До начала рабочего дня еще 4 часа. А там уже ивент лупы, лейауты и прочая радость…
В первой части мы говорили о первой загрузке и работе с ресурсами. Сегодня я расскажу о второй части оптимизации производительности фронтенда. О том, что происходит с нашей страницей, когда она загружена, на что уходит процессорное время и что с этим делать. Ключевые слова: event loop, paint \ repaint, layout \ reflow, composite.
Здравствуйте. Меня зовут Ник, я фронтенд разработчик (жидкие аплодисменты). Кроме того, что я пишу код, я преподаю в Школе программистов hh.ru.
Записи наших лекций от 2018-2019 учебного года можно посмотреть на youtube
В этом году у меня была лекция про оптимизацию производительности фронтенда, и я решил превратить ее в текстовый формат. Материал получился большим, так как лекция была длительностью 3 часа. Поэтому получился текстовый альманах.
Вот презентация для тех, кому неохота читать лонгрид, но при этом хочется иметь базовое представление о контенте.
Лонгридом можно пользоваться как справочником, чтобы не читать за один присест. Вот список тем, которые мы затронем:
using foobar = … реализует идиому RAII, позволяя писать намного менее многословный код, управляющий DisposableStack/AsyncDisposableStack, а также приведу пример неочевидного бага, в который попался я сам. По пути я также коснусь нескольких других нововведений Node.js, про которые, возможно, ещё знают не все. Весь код доступен в репозитории. 
Этот документ — часть документации по стилю Go в Google. Он не является ни нормативным, ни каноничным, это дополнение к «Руководству по стилю». Подробности смотрите в Обзоре.
Здесь приведены рекомендации по лучшим практикам применения требований «Руководства по стилю» для Go. Это руководство охватывает общие и распространенные случаи, но не может применяться к каждому частному случаю. Обсуждение альтернатив, по возможности, включено в текст руководства вместе с указаниями о том, когда они применимы, а когда — нет.
Полная документация руководства по стилю описывается в обзоре.
Всем привет! Меня зовут Илья Денисов, я занимаюсь backend разработкой уже более пяти лет и сейчас пишу на языке go. Сегодня я предлагаю вам поговорить о кэшировании. Постараюсь рассказать о базовых концепциях, а также затронуть ряд особенностей, неочевидных на первый взгляд.
В данной статье расскажу о планировщике Go. Основу материала взял из книги Уильяма Кеннеди Ultimate Go. Вначале поговорим о планировщике OS, после перейдем к планировщику Go и сравним их.
«Что самое крутое вы сделали за год, что пишете на Go», — вопрос из зала после первого доклада.
«Записал новую машину на жену», — остроумный комментарий к этому моменту в трансляции.
В конце мая в очень дружелюбной атмосфере состоялся YADRO Go To митап — в этот раз для тех, кто только думает или недавно начал писать на Go в коммерческих проектах. В этом посте мы собрали ссылки на записи, презентации и добавили пару слов о каждом выступлении, чтобы было проще выбрать, что посмотреть детальнее, а что — на быстрой перемотке.
Роб Пайк сказал, что простое лучше, чем сложное. Я бы добавил: простое лучше, чем прикольное. Ведь Go спроектирован, чтобы писать программы в простом стиле.
Сегодня я хочу поговорить про такие, казалось бы, очевидные вещи, как функции, интерфейсы и методы. Их особенности в Go. И правила, которые я выработал, чтобы писать их просто и понятно для коллег, для компьютера и для себя в недалеком будущем.
type Status uint32
const (
StatusOpen Status = iota
StatusClosed
StatusUnknown
)StatusOpen = 0
StatusClosed = 1
StatusUnknown = 2
Что спрашивают на собеседовании Golang разработчика? Асинхронщина? Контексты? Вторая часть статьи с вопросами и ответами, собранными на собеседованиях.
Напишем вместе HTTP-сервис на golang с нуля? Я уверен, что это довольно несложно. Для тех, кто каждую неделю этим занимается, моя статья не будет особенно интересна, но я все равно рекомендую взглянуть и оценить, возможно, ваши комментарии спасут кому-то жизнь. А может кое-какие из моих рассуждений спасут вашу.
Эта статья будет полезна тем, кто некоторое время назад начал осваивать язык программирования golang и уже достиг того момента, когда может попробовать окунуться в полный цикл разработки микросервисов на этом языке. Также она подойдет тем, кто решил сменить профильный язык, и по каким-то причинам его выбор пал на golang. Я не буду останавливаться на очевидных вещах вроде конструкций языка, парадигм конкурентности и прочего, но уделю время архитектуре приложения и постараюсь заострить внимание на моментах, в которых разработчик может допустить ошибку.
Это первая часть. Первые шаги в нашем нелегком пути. И в этой статье мы попробуем достичь следующих целей:
Как и многие языки, Go часто использует магию под названием хип (heap). Обычно, когда мы пишем наши джейсоно-гонятели, мы просто не задумываемся об этом, хоть и знаем, что это «где-то есть». Давайте попробуем заглянуть в кроличью нору поглубже и увидеть не только то, какими методами аллокатор Go старается облегчить программисту жизнь, но и то, из чего он состоит в целом.
Меня зовут Антон Киреев, я бэкенд-разработчик с опытом работы больше 11 лет. В настоящее время работаю техлидом в Авито. В жизни мне нравятся две вещи: приносить пользу своей работой и проводить свободное время с семьёй. Именно поэтому я люблю делать что-то быстро, но качественно, а потом отдыхать. Для этого я постоянно учусь и пытаюсь докапываться до сути вещей. Сегодня поговорим, как наша любимая Гошечка работает с памятью.
Привет! Меня зовут Павел Лакосников, я тимлид команды бэкенд-инженеров в Авито. Сегодня расскажу про свой любимый подход к разработке Trunk Base Development, сравню его с другими моделями ветвления и подсвечу его достоинства и нюансы.
Краткий обзор трёх моделей ветвления: Central Workflow, Git Flow, Trunk Based Flow, с акцентом на моего фаворита — Trunk Based Flow.
Обычно под требованиями и ожиданиями от тимлида подразумевают набор навыков, знаний и обязанностей. Его формализуют в виде матрицы компетенций и используют, чтобы объяснить, что должен уметь руководитель команды. При этом мало говорят о том, чего ждут и что хотят получить от тимлида люди, с которыми он постоянно взаимодействует на работе.
Меня зовут Евгений Рейх, я руководитель разработки кластера Goods Classified в Авито. Это около 100 человек, или 10 команд, в подчинении. Больше 15 лет я занимаюсь разработкой и руковожу командами в разных компаниях. На собственном опыте знаю, какие ожидания есть у коллег. К тому же я еженедельно провожу четыре-пять собеседований на руководящие должности в Авито и понимаю, что требуется от тимлида.
Текст основан на выступлении для Avito TeamLead meetup. Он будет полезен и действующим тимлидам, и тем, кто только собирается начать руководить командой.
Привет! Меня зовут Дима Вагин, я бэкенд-инженер в Авито. Сегодня расскажу, как мы работаем с БД PostgreSQL из Go. Покажу, какие библиотеки и пулеры соединений мы используем для доставки в код параметров подключения и как мы их настраиваем. А ещё расскажу про проблемы, к которым приводит отмена контекста, и о том, как мы с ними справляемся.