Каков наилучший способ беспроблемного увеличения параллелизма в Node.js-сервисе, который используется в продакшне? Это — вопрос, на который моей команде понадобилось ответить пару месяцев назад.

У нас запущено 4000 контейнеров Node (или «воркеров»), обеспечивающих работу нашего сервиса интеграции с банками. Сервис изначально был спроектирован так, что каждый воркер был рассчитан на обработку только одного запроса за раз. Это снижало воздействие на систему тех операций, которые могли неожиданно заблокировать цикл событий и позволяло нам игнорировать различия в использовании ресурсов различными подобными операциями. Но, так как наши мощности были ограничены одновременным выполнением лишь 4000 запросов, система не могла достойно масштабироваться. Скорость выдачи ответов на большинство запросов зависела не от мощности оборудования, а от возможностей сети. Поэтому мы могли бы улучшить систему и снизить стоимость её поддержки в том случае, если бы нашли способ надёжной параллельной обработки запросов.



Занявшись исследованием этого вопроса, мы не смогли найти хорошего руководства, в котором речь шла бы о переходе от «отсутствия параллелизма» в сервисе Node.js к «высокому уровню параллелизма». В результате мы разработали собственную стратегию перехода, которая была основана на тщательном планировании, на хороших инструментах, на средствах мониторинга и на здоровой дозе отладки. В итоге нам удалось повысить уровень параллелизма нашей системы в 30 раз. Это эквивалентно снижению затрат на поддержку системы примерно на 300 тысяч долларов в год.

Данный материал посвящён рассказу о том, как мы увеличили производительность и эффективность наших Node.js-воркеров, и о том, что мы узнали, пройдя этот путь.

Пол года назад я сама искала такую статью и теперь я очень хочу посоветовать себе в прошлом с чего можно начать.

1. Выбрать тему приложения

Не нужно долгих мук выбора, просто начните делать то, что вам пригодилось бы. Лучше что-то простое. Нужно понимать, что мы пока не стремимся быть Биллом Гейтсом. Это наше первое приложение, наш первый шаг.

Я уже как лет 7-8 болею спортом, потому идеей моего первого приложения было — база тренировок для поддержания себя в тонусе, с упражнениями для спины, рук, попы, ну и в целом, чтобы не скучно было.

2. На каком языке писать?

Я перепробовала несколько разных языков и разных SDK, мой выбор пал на Flutter и, собственно, язык на котором он обслуживается — dart, потому что:

• Dart — легкий в изучении язык. Вам не составит труда ознакомиться с ним, в интернете полно информации и уроков. Скорость выполнения операций на нем сравнима с Objective-C, Swift, Kotlin, Java, а с последним у них очень много общего.
• Flutter может компилировать и под Android, и под iOS. (Еще может в Fuchsia, но нам оно пока вряд ли нужно).
• Удобство в работе с виджетами, гибкость и простота в использовании.

Виджеты бывают двух типов: StatefulWidget и StatelessWidget.

Грубо говоря, те, которым можно задать состояние и те, кому нет.

Недавно на eBay мне попалась партия интересных USB-девайсов (Epiphan VGA2USB LR), которые принимают на вход VGA и отдают видео на USB как веб-камера. Меня настолько обрадовала идея, что больше никогда не придётся возиться с VGA-мониторами, и учитывая заявленную поддержку Linux, я рискнул и купил всю партию примерно за 20 фунтов (25 долларов США).

Получив посылку, я подключил устройство, но оно даже не подумало появиться в системе как UVC. Что не так?

Я изучил сайт производителя и обнаружил, что для работы требуется специальный драйвер. Для меня это была новая концепция, ведь в ядре моего дистрибутива Linux обычно есть драйверы для всех устройств.

Как говорится, если тебе не стыдно за свой старый код, значит, ты не растешь как программист — и я согласна с таким мнением. Я начала программировать для развлечения более 40 лет назад, а 30 лет назад и профессионально, так что ошибок у меня набралось очень много. Будучи профессором информатики, я учу своих студентов извлекать уроки из ошибок — своих, моих, чужих. Думаю, пришло время рассказать о моих ошибках, чтобы не растерять скромность. Надеюсь, кому-то они окажутся полезны.

Привет Хабр! Меня зовут Марина Могилко. Я уже четыре года живу в США и развиваю LinguaTrip.com — онлайн-платформу по бронированию языковых курсов. В основном мы помогаем с учёбой — выучить английский или поступить в зарубежный вуз, но периодически просят помочь и с работой за границей. Мы не занимаемся трудоустройством, но знаем, как попасть в хорошую компанию в США. В целом секрет прост — прокачайте профиль в LinkedIn, продайте себя через резюме и произведите хорошее впечатление на собеседовании. Как это сделать, рассказываем под катом.

Когда я составляла свое первое резюме, процесс отбора на очное интервью мне казался магией. Люди, принимающие решения, представлялись «черными ящиками», которые определяют: кандидат «интересен» или «неинтересен» — по непонятным критериям.

Статьи «Как составить резюме» отчасти были полезны, а отчасти путали и нагоняли страх: их авторы утверждали, что мое письмо может попасть в корзину, если не выдержана структура или ответственный сотрудник не увидел в нем ключевых слов за первые 5 секунд чтения.

Прошли годы, сейчас я сама участвую в найме фронтенд-разработчиков и просматриваю резюме вместе с другими тимлидами.

В этой статье я хочу рассказать:

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

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

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

Язык XML был изобретен в 1996 году. Едва он успел появиться, как возможности его применения уже начали понимать неправильно, и для тех целей, к которым его пытались адаптировать, он был не лучшим выбором.

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

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

Комбинация хорошо развитых навыков сделает вас уникальным, даже если по каждому из них вы далеко не гений

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

Как вы можете себе представить, вероятность стать игроком НБА очень низкая: всего есть 30 команд по 15 игроков в каждой, что дает в общей сложности около 450 человек — не так уж много, особенно если учесть, что в молодежный баскетбол играет более полумиллиона ребят. Несложные подсчеты показывают, что меньше чем один из тысячи становится профессионалом.


Источник: Томас Пуэйо

Так что давайте будем реалистами: вы не попадете в НБА, не станете ни президентом, ни величайшим писателем в мире, ни лучшим шахматистом, ни самым искусным оратором. Вы никогда не станете лучшим в мире в каком-либо конкретном навыке: всегда найдется кто-то, кто выкладывается больше, у кого лучше генетические данные, кому больше везет (или всё сразу).


Большинство людей (в синей области) слабо владеют конкретным навыком. Если немного постараться, вы быстро попадете в 10% лучших (зеленая область). Но как только вы присоединились к этой элите, двигаться дальше становится всё сложнее, потому что ваши конкуренты всё чаще — люди, глубоко преданные этому делу.

Пытаться стать лучшим в одном деле — не самый разумный путь к успеху. Лучше приложить усилия в освоении сочетания навыков. То есть, решением является комбинирование навыков — концепция, популяризируемая Скоттом Адамсом. Принцип ее работы следующий.

Переведено в Alconost

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

А теперь представьте как я офигел, когда мне в руки попал 1.3-мегапиксельный фотоаппарат 2000 года, использующий для хранения данных обычные 3.5-дюймовые дискеты. Реальность оказалась покруче любой фантастики…

Хочу рассказать молодым ребятам, как они могут повысить свои шансы быть нанятым на свою первую работу.

Я провел больше сотни собеседований и отсеял тысячи резюме. Каждый раз я искал технических специалистов (инженеры, программисты, тестировщики, физики, математики). Больше половины всех собеседований были со вчерашними студентами или со студентами последних курсов. Увы, почти всегда их резюме было совершенно не информативным.

Зачем я об этом пишу? Мой интерес прост – чтобы классные ребята находились легче, чем это получается сейчас :)

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

Такое случилось с основателем Allbirds Тимом Брауном. О его перспективном обувном стартапе мы уже рассказывали год назад. Экологически чистые, простые кроссовки из шерсти овец-мериносов, без пластика и всего остального, за $95. Но, на их беду, они отказались торговать своей обувью на Amazon. Предпочли развивать свой сайт и свой бренд (благо, получили на это больше $80 млн инвестиций). И вот месяц с лишним назад Amazon вдруг начинает выпускать точно такие же с виду кроссовки. С теми же «пёрками». Только по $45.

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

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

Здесь приведено 14 распространенных манипуляций. Анализируя свою жизнь, я могу сказать, что ощущал в разное время воздействия каждой из них, а некоторые методы «промывки мозгов» по отношению ко мне были по-настоящему эффективны. Думаю, это всем хорошо знакомые атаки. Я упорядочил их в некий список и попытался описать механизмы и причины, почему они, несмотря на тривиальность, являются довольно эффективными.

Я не рассматриваю элементарные воздействия такие, как подкуп, шантаж и запугивание. В этой статье меня интересуют лишь атаки, заставляющие нас жить в иллюзии.

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

Это не статья по психологии и не статья по философии, хотя бы потому, что в этой статье не будет приведено ни одной ссылки.

Всем привет! Меня зовут Максим Рындин, я тимлид двух команд в Gett – Billing и Infrastructure. Хочу рассказать про продуктовую веб-разработку, которую мы в Gett ведем преимущественно на языке Go. Я расскажу, как в 2015-2017 годах мы переходили на этот язык, почему вообще его выбрали, с какими проблемами столкнулись во время перехода и какие решения нашли. А о текущей ситуации расскажу уже в следующей статье.

Для тех, кто не знает: Gett — это международный сервис заказа такси, который был основан в Израиле в 2011 году. Сейчас Gett представлен в 4 странах: Израиль, Великобритания, Россия и США. Основные продукты нашей компании — это мобильные приложения для клиентов и водителей, веб-портал для корпоративных клиентов, где можно заказать машину, и еще куча внутренних админок, через которые наши сотрудники настраивают тарифные планы, подключают новых водителей, мониторят случаи мошенничества и многое другое. В конце 2016 года в Москве открылся глобальный офис R&D, который работает в интересах всей компании.

В статье показано, как создать нерекурсивную zip-бомбу, которая обеспечивает высокую степень сжатия путём перекрытия файлов внутри zip-контейнера. «Нерекурсивная» означает, что она не зависит от рекурсивной распаковки декомпрессорами файлов, вложенных в zip-архивы: здесь всего один раунд. Выходной размер увеличивается квадратично от входного, достигая степени сжатия более 28 миллионов (10 МБ → 281 ТБ) в пределах формата zip. Ещё большее расширение возможно с помощью 64-разрядных расширений. Конструкция использует только наиболее распространённый алгоритм сжатия DEFLATE и совместима с большинством парсеров zip.

• zbsm.zip 42 kB → 5.5 GB
  
• zblg.zip 10 MB → 281 TB
  
• zbxl.zip 46 MB → 4.5 PB (Zip64, менее совместима с парсерами)

Исходный код:

git clone https://www.bamsoftware.com/git/zipbomb.git

zipbomb-20190702.zip

Данные и исходники иллюстраций:

git clone https://www.bamsoftware.com/git/zipbomb-paper.git

Это первый пост из серии публикаций, в которых объясняется мое понимание архитектуры приложений для Flutter. Предупреждаю — это будет весьма самоуверенным.

Пока запланированы:

• Введение (этот пост)
• Основы Dart Streams
• RxDart: магические трансформации потоков
• Основы RxVMS: RxCommand и GetIt
• RxVMS: Службы и Менеджеры
• RxVMS: самодостаточные виджеты
• Аутентификация пользователя посредством RxVMS

Предисловие

Я в программировании уже около 20 лет. Начал мобильную разработку 4 года назад с Xamarin.Forms, ибо кроссплатформенность была единственной побудительной причиной для меня в качестве инди-разработчика. Xamarin.Forms буквально толкают тебя к использованию паттерна MVVM, так как определение UI ведется в XAML, и тебе необходим какой-то слой, чтобы склеивать UI с Моделью. В процессе работы с Xamarin я познакомился с ReactiveUI и был буквально покорен потоками и реактивными расширениями (Rx), сделавшими мои приложения более надежными.

В то время, как в Xamarin.Forms MVVM были "из-коробки", при переходе к Flutter я был удивлен, что в нем не было никаких похожих шаблонов проектирования. Я начал исследовать различные предлагаемые подходы, но ничего из имеющегося не удовлетворило меня в полной мере:

«Люблю спагетти-вестерны, ненавижу спагетти-код»

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

• Обсуждаем, почему спагетти-код не так уж и вкусен.
• Представляем новый взгляд на то, что же на самом делает код.
• Обсуждаем Frame Machine Notation (FMN), помогающую разработчикам распутать клубок из пасты.

Все мы знаем, как тяжело бывает читать чужой код. Это может быть из-за того, что сложна сама задача или потому, что структура кода слишком… «креативна». Часто эти две проблемы идут рука об руку.

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

Уродливость спагетти-кода заключается в его сложной условной логике. И хотя жизнь может быть сложно представить без множества хитрых конструкций if-then-else, эта статья покажет вам решение получше.

Уже три года я живу и работаю в Германии. В декабре прошлого года в нашем кабинете перегорела одна из ламп дневного света. Но не просто перестала светить, а как это часто бывает у люминесцентных ламп со стартером, стала постоянно гаснуть и включаться снова с характерным щелчком. Мои коллеги сразу же позвонили секретарю, та вызвала электрика. Через три дня секретарь сказала, что лампу поменяют нескоро, так как их нет на складе и нужно заказывать. Меня эта ситуация категорически не устраивала. Это моргание раздражало очень сильно.

У нас на этаже есть кладовая, где стоят точно такие же лампы. Только в эту кладовку люди ходят раз в неделю. Самое простое решение – заменить лампу в кабинете на лампу из кладовки. А когда придут новые, сделать нормально.

Вообще эту лампу поменять очень легко. У меня были такие лампы и дома, и на работе. Я, будучи админом, проворачивал этот фокус с подменой ламп много раз.

Я взял барный стул и попросил коллегу-немца подвинуться – лампа висела прямо над его рабочим местом. Нильс спросил, что я задумал, и я поделился с ним своей идеей. Он радостно воскликнул: «Классно, мы будем тебе очень благодарны, а то она уже всем надоела!», а потом шепотом добавил: «… но я бы не советовал тебе этого делать!»

Жил на свете такой человек – Стивен Кови. Однажды он решил написать книгу о личной эффективности. Теперь эту книгу знают все, она называется «Семь навыков высокоэффективных людей». Она считается классикой, постоянно переиздается во всех мыслимых странах мира, за годы существования продано несколько десятков миллионов экземпляров. Сам Стивен Кови настолько разобрался в личной эффективности, что его личными консультациями не преминули воспользоваться несколько президентов, в т.ч. США.

Книжка хорошая, объемная и вдохновляющая. Уроки и принципы, изложенные в ней, часто встречаются у более поздних авторов книг и курсов. Ссылки, правда, забывают сделать, ну да ладно.

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

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



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

• Какие есть варианты программного извлечения данных с веб-страницы?
• Плюсы и минусы каждого подхода?
• Как использовать облачные ресурсы для увеличения степени автоматизации?

Статья поможет получить ответы на эти вопросы.

После многолетнего опыта работы с php и js, я привык иметь в ошибках стектрейс и смотреть на место, где произошла ошибка прямо из эррор-репорта. Пересев на Go пару лет назад, я был несколько удивлен, что в Go другие правила и нужно угадывать стектрейс по какой-нибудь строке типа `invalid character`. А если она произошла на проде и не известно, как ее воспроизвести, то это превращалось в целый аттракцион.

Поскольку я уверен, что не один от этого страдал, то сделал пакет, который умеет так:



→ GitHub