Я уже рассказывал про сервис мониторинга запросов к PostgreSQL, для которого мы реализовали онлайн-коллектор серверных логов, чья основная задача — одновременно принимать потоки логов сразу с большого количества хостов, быстро их разбирать на строки, группировать в пакеты по определенным правилам, обрабатывать и записывать результат в PostgreSQL-хранилище.



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

Мы погрузились в недра профайлера и обнаружили некоторые особенности работы с Buffer в Node.js, знание которых может сильно сэкономить ваше время и серверные ресурсы.

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

Но есть ситуации, когда без «крепкого словца» не обойтись. И чтобы не потерять свой имидж культурного человека, мы предлагаем вам целую коллекцию «mild curses» — легких ругательств и идиоматических выражений на английском языке, которые не считаются матами, но при этом помогут выразить всю палитру эмоций. Поехали!

TL;DR Встроенные средства macOS позволяют выполнить некоторые атаки на Wi-Fi-сети. В статье описывается, как с помощью встроенного в Macbook Wi-Fi адаптера AirPort и macOS похекать Wi-Fi.

Обычно для аудита безопасности Wi-Fi-сетей используется классическая связка: виртуалка с Kali Linux + внешний USB адаптер типа Alfa AWU-blabla1337. Но оказывается, что с помощью macOS и встроенного адаптера Broadcom тоже можно делать грязь.

Содержимое статьи:

• Мониторный режим на встроенном адаптере
• Расшифровываем WPA трафик
• Ловим хендшейки и PMKID
• Собираем под макось пацанские тулзы: hcxtools, hashcat, bettercap
• Брутим хеши на онлайн-фермах и локально

Это телевизор с диагональю 50” и 37 RGB точками адаптивной фоновой подсветки по верхней и боковым сторонам экрана. Как сделать аналогичную адаптивную фоновую подсветку для любого экрана или ТВ — тема избитая, но вполне актуальная по ряду причин.

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

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

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

Дальше я приведу несколько наборов слов, сгруппированных по типовым ошибкам. К каждому слову будет приложена транскрипция, приблизительная транскрипция на русском и ссылка на более детальную информацию в словаре. Так как большинство IT компаний все-таки работает с Северной Америкой, то транскрипции будут из US English.

Disclaimer: Эта статья была начата еще летом. Не так давно на хабре был всплеск статей на тему поиска работы за рубежом и переезда. Каждая из них придавала моей пятой точке некоторое ускорение. Что в итоге заставило меня перебороть свою лень и сесть написать, а точнее дописать, очередную статью. Часть материала может повторять статьи других авторов, но с другой стороны, у каждого свои фломастеры.



Итак, перед вами часть третья, и на данный момент последняя, о похождениях блудного попугая программиста. В первой части я уехал жить и работать на Кипр. Во второй части я пытался устроиться в Google и переехать в Швейцарию. В третьей части (вот этой самой) я устроился на работу и переехал в Нидерланды. Сразу скажу, что про поиск работы будет мало, так как его фактически не было. В основном будет про обустройство и жизнь в Нидерландах. В том числе про детей и покупку дома, что не было подробно описано в недавних статьях других авторов.

До недавнего времени во всех проектах фронта разработчики Dodo Pizza Engineering использовали tslint – полезный инструмент, который подсказывает, когда ты накосячил в коде допустил неточность, помогает поддерживать код в одном стиле и сам исправляет многие замечания. Но тут tslint взял и умер. Под катом я расскажу, почему так вышло, как перестать лить слёзы по умершему и перейти на инструмент eslint, а также покажу кое-что очень интимное.

*FAANG — акроним 5 крупнейших tech компаний (Facebook, Apple, Amazon, Netflix and Google), предоставляющих одни из самых хороших возможностей для разработчиков, которые мечтают/планируют/хотят приобщиться к волне IT-эмиграции.

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

К сожалению, на практике подобный процесс поиска работы часто заканчивается неудачами. Сайты со списком вакансий — один из самых низкоэффективных способов, по крайней мере в США.

Под катом я поделюсь практическими рекомендациями, которые помогут «твикнуть» систему и существенно увеличить шансы на получение предложения от топ-компаний в сжатые сроки.

Однажды, на одном интервью меня спросили, что ты будешь делать, если обнаружишь неработающий сервис из-за того, что на диске закончилось место?

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

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

Интервьюер прервал меня на последнем слове, дополнив свой вопрос: «Предположим, что данные нам не нужны, это просто дебаг лог, но приложение не работает из-за того, что не может записать дебаг»?

«окей», — ответил я, «мы можем выключить дебаг в конфиге приложения и перезапустить его».
Интервьюер возразил: «Нет, приложение мы перезапустить не можем, у нас в памяти все еще хранятся важные данные, а к самому сервису подключены важные клиенты, которых мы не можем заставлять переподключаться заново».

«ну хорошо», сказал я, «если мы не можем перезапускать приложение и данные нам не важны, то мы можем просто очистить этот открытый файл через файл дескриптор, даже если мы его не видим в команде ls на файловой системе».

Интервьюер остался доволен, а я нет.

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

Всем привет. Это перевод статьи из книги RedHat RHCSA RHCE 7 RedHat Enterprise Linux 7 EX200 and EX300.

От себя: Надеюсь статья будет полезна не только начинающим, но и поможет более опытным администраторам упорядочить свои знания.

Итак, поехали.

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



Этот инструмент микровиртуализации доступен в OpenSource. Если ваши задачи требуют мульти-тенантной изоляции, (ну, например, вы решили сделать собственное облако), Firecracker — это то, что надо.

Василий Пантюхин, архитектор Amazon Web Services, расскажет об архитектуре Firecracker, о том, как он используется AWS Lambda, сравнит его с альтернативными решениями и приведет примеры интеграции.

Дисклеймер: всё, что ниже — это личное мнение Василия, и оно может не совпадать с позицией Amazon Web Services.

Я должен признаться. Я ненавижу docker. Всей своей душой. Это самая ужасная софтина, которую я видел за последние 10 лет.

С одной стороны, я очень уважаю одноименную компанию. Ребята из Docker Inc. реально популяризировали контейнеризацию. Теперь о ней не знает только ленивый. С другой стороны, ничего принципиально нового они не изобрели — контейнеризация на момент, когда Docker "выстрелил", уже существовала более 30 лет (начиная от chroot, вспомним еще jails и zones, ну, и наконец-то — namespaces & cgroups).

Круто, что docker реально ускоряет разработку во множество раз. Если вести ее правильно, то даже без потери в качестве. В любом случае, docker здесь, от него не деться и приходится им пользоваться.

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

Disclaimer: все написанное ниже является личным мнением автора и может как отражать реальность, так и не отражать реальность. Материал строго провокационного характера и основной целью является не унизить или обидеть кого бы то ни было, а скорее заставить людей включить голову и осознать масштабы глубин (с).

Не смогли пройти мимо и перевели ко Дню программиста комикс Джулии Эванс об утилите Strace. Полезный инструмент, который помогает отслеживать системные вызовы и доставку сигналов между процессами и ядром Linux. Читайте и вдохновляйтесь. С наступающим, друзья!

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

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

Команда TestMace снова с вами. На этот раз мы публикуем перевод статьи о преобразовании кода TypeScript, используя возможности компилятора. Приятного чтения!

Введение

Это мой первый пост, и в нём мне бы хотелось показать решение одной задачи с помощью API компилятора TypeScript. Чтобы найти это самое решение, я долгое время копался в многочисленных блогах и переваривал ответы на StackOverflow, поэтому, чтобы уберечь вас от такой же участи, я поделюсь всем тем, что я узнал о таком мощном, но слабо документированном наборе инструментов.

Вступительное слово

Я выступил с этим докладом на английском языке на конференции GopherCon Russia 2019 в Москве и на русском — на митапе в Нижнем Новгороде. Речь в нём идёт о bitmap-индексе — менее распространённом, чем B-tree, но не менее интересном. Делюсь записью выступления на конференции на английском и текстовой расшифровкой на русском.

Мы рассмотрим, как устроен bitmap-индекс, когда он лучше, когда — хуже других индексов и в каких случаях он значительно быстрее них; увидим, в каких популярных СУБД уже есть bitmap-индексы; попробуем написать свой на Go. А «на десерт» мы воспользуемся готовыми библиотеками, чтобы создать свою супербыструю специализированную базу данных.

Очень надеюсь, что мои труды окажутся для вас полезными и интересными. Поехали!

HighLoad++ существует давно, и про работу с PostgreSQL мы говорим регулярно. Но у разработчиков все равно из месяца в месяц, из года в год возникают одни и те же проблемы. Когда в маленьких компаниях без DBA в штате случаются ошибки в работе с базами данных, в этом нет ничего удивительного. В крупных компаниях тоже нужны БД, и даже при отлаженных процессах все равно случаются ошибки, и базы падают. Неважно, какого размера компания — ошибки все равно бывают, БД периодически обваливаются, рушатся.



С вами такого, конечно, никогда не случится, но проверить чек-лист не трудно, а сэкономить будущих нервов он может очень прилично. Под катом перечислим топ типичных ошибок, которые совершают разработчики при работе с PostgreSQL, разберемся, почему так делать не надо, и выясним, как надо.


О спикере: Алексей Лесовский (lesovsky) начинал системным администратором Linux. От задач виртуализации и систем мониторинга постепенно пришел к PostgreSQL. Сейчас PostgreSQL DBA в Data Egret — консалтинговой компании, которая работает с большим количеством разных проектов и видит много примеров повторяющихся проблем. Это ссылка на презентацию доклада на HighLoad++ 2018.

При запуске Node.js-приложений в контейнерах Docker традиционные настройки памяти не всегда работают так, как ожидается. Материал, перевод которого мы сегодня публикуем, посвящён поиску ответа на вопрос о том, почему это так. Здесь же будут приведены практические рекомендации по управлению памятью, доступной Node.js-приложениям, работающим в контейнерах.

Итак, за примерно год (май 2017 — февраль 2018) я, программист C++, нашел-таки работу в Европе. Я десятки раз откликался на вакансии в Англии, Ирландии, Швеции, Нидерландах и даже в Португалии. Я раз двадцать беседовал по телефону, скайпу и прочим системам видео связи с рекрутерами, и несколько меньше — с техническими специалистами. Я ездил в Осло, в Эйндховен и три раза в Лондон на финальные интервью. Все это подробно описано здесь. В итоге я получил один оффер и принял его.



Оффер этот был из Нидерландов. Работодателям в этой стране относительно просто пригласить работника из-за рубежа (не из Евросоюза), поэтому бюрократической волокиты немного, а сам процесс оформления занимает всего несколько месяцев.

Но всегда можно самому себе создать сложности. Что я и сделал, чем затянул свой переезд еще на месяц. Если интересно почитать о хлопотах (нет, не сильно приятных) связанных с переездом IT семьи в Западную Европу — добро пожаловать под кат.