Привет, Хабр! В Netcracker мы уже давно используем микрофронтендную архитектуру, и с 2017 года начали разрабатывать собственный платформенный инструмент построения микрофронтендов.

Недавно на митапе мы показывали, как делать сложные приложения, разрабатываемые разными командами в разных релизных циклах и даже технологиях. В режиме live coding соединили Angular, React и Vue в одном SPA. Было много вопросов про Webpack Module federation. Поскольку мы уже переходим на этот фреймворк, здесь мы поделимся наработками, как сделать Angular host application + React/Angular/Vue microfrontends с возможностью независимого версионирования зависимостей.

Задача организовать VPN в Москве или Спб для работы с сервисами не доступными с зарубежных IP и шифрования трафика для доступа к ресурсам компании при использовании публичного WiFi заграницей.

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

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

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

Всем привет! Меня зовут Роман Бузько, я пишу на юридические и финансовые темы преимущественно на VC c 2015 года. Это мой первый пост на Хабре. Статья представляет собой обновленную версию нашей недавней публикации. На следующей неделе будет продолжение, когда пыль осядет и будет чуть больше ясности.

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

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

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

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

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

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

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

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

Context API — это механизм React, позволяющий передать одно пользовательское значение в поддерево компонентов. Любой компонент внутри определенного <MyContext.Provider> может прочитать значение из этого экземпляра контекста, не прибегая к непосредственной передаче значения в качестве пропа через каждый промежуточный компонент.

Контекст не является инструментом управления состоянием. Разработчику необходимо самостоятельно управлять значениями, передаваемыми в контекст. Обычно в этих целях данные хранятся в состоянии компонента React, и на основании этих данных конструируются значения контекста.

Первую часть публикации читайте здесь.

Как описано на странице «Согласование» в официальной документации, React пытается эффективно выполнять повторный рендеринг, по возможности повторно используя существующее дерево компонентов и структуру DOM. Если заставить React отрендерить тот же самый тип компонента или HTML-узел в том же месте дерева, React повторно использует имеющееся представление и при необходимости актуализирует его, вместо того чтобы перестраивать его с нуля. Это значит, что React будет поддерживать жизнеспособность экземпляров компонента до тех пор, пока вы будете запрашивать рендеринг этого типа компонента в том же самом месте. Для классовых компонентов повторно используется тот же самый реальный экземпляр вашего компонента. У функционального компонента нет такого же «настоящего» экземпляра, как у классового, но мы можем рассматривать <MyFunctionComponent /> как некий аналог «экземпляра» в том смысле, что «компонент этого типа отображается в этом месте и по-прежнему существует».

Подробности о том, как происходит рендеринг в React и как влияет на рендеринг применение контекста.

Я часто сталкиваюсь с недопониманием относительно того, как, почему и когда React повторно рендерит компоненты и каким образом применение контекста и React-Redux влияет на время и объем повторного рендеринга. С десяток раз понабивав на клавиатуре различные вариации ответов на эти вопросы, я подумал, что имеет смысл составить одно общее пояснение и при каждом удобном случае ссылаться на него. Учтите, что вся собранная здесь информация уже гуляет по сети и рассматривалась в ряде других замечательных статей и публикаций в блогах. Некоторые из них перечислены в качестве справки в конце оригинальной публикации, в разделе Further Information. Собрать разрозненные сведения в единую картину бывает нелегко, поэтому я надеюсь, что моя статья поможет кому-то разобраться в теме.

Цель этой статьи показать и объяснить многообразие дистрибутивов Линукс. Показать основные сходства (они же все почему то называются "Линуксы" или даже правильнее "GNU/Linux") и основные различия (если бы не было различий их бы столько не существовало).

Плюс рассмотрим несколько наиболее задаваемых новичками вопросов:
- Сколько их (Linux-дистрибутивов)? Зачем так много?
- Основанный на другом дистрибутиве" - не пиратство ли это?
- Платный Linux - Как можно продавать то, что по определению распространяется бесплатно?
- Что такое "отечественный Linux"?

• Организационные
  　Культура разработки performance-first
  　Бюджет скорости
  　Performance mantras
• Те, что можно использовать независимо от языка и его реализации
  　Смена языка или фреймворка
  　Смена алгоритма
  　Оптимизация алгоритма
  　Вынос инвариантов на уровень выше
  　Boolean short circuit
  　Досрочный выход из цикла
  　Предвычисление
• Для языков/фреймворков, в которых нет ленивых вычислений и приёма copy-on-write
  　Shortcut fusion
  　Ленивое вычисление
  　Copy-on-write
  　Оверинжиниринг
• Зависящие от железа
  　Разворачивание мелких циклов
  　Предсказание ветвлений (Branch prediction)
  　Доступ к памяти: направление итерации
  　Доступ к памяти: [i][j] vs [j][i]
• Для языков со сборкой мусора
  　Мутабельность
  　Zero memory allocation или GC-free
• Специфичные для JavaScript
  　Антипаттерн: накопление строк в массиве
  　Антипаттерн: Lodash _.defaults
  　Idle Until Urgent
  　Даунгрейд кода: ES6 → ES5
• Примеры из код-ревью

В 21 веке, кто-то боится экосистем, кто-то их ненавидит, кто-то боготворит. Каждому предстоит самому делать выбор готов ли он жертвовать безопасностью ради удобства, складывая все яйца в одну корзину. Я пользуюсь Тинькофф уже несколько лет. Начал со счёта для ИП, как андроид разработчик, попробовал многие сервисы для физических лиц... И хотел бы рассказать о том, как банк сам не даёт себя любить. Ну серьёзно, в доме 31 градус - работать просто невозможно, почему бы не осчастливить Хабр очередным личным опытом?

Украинский профильный ресурс DOU.UA опубликовал статью о нелегком пути релокации специалиста в США во время пандемии, где он также отвечает на дополнительные вопросы и комментарии.

Адам Леос — Senior Software Engineer в Roku. Пару лет назад он принял решение о релокации и в итоге выбрал своей целью США. Всего за три месяца Адам с нуля собрал все необходимое для подачи на визу О1, но потом в историю вмешалась пандемия. О том, с какими трудностями он столкнулся из-за карантина, как искать работу на американском IT-рынке, как получить большое количество офферов и выторговать самую выгодную компенсацию, разработчик рассказал в интервью DOU.UA

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

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

Кардинальным образом ситуация изменилась после того, как я прошел курс HowToCode.  В курсе описан системный и, как всё гениальное, простой и красивый подход к разработке, который сводит воедино анализ, проектирование, документацию, тестирование и разработку кода. Весь курс построен на использовании функциональной парадигмы и языка Scheme (диалекта Lisp), тем не менее, рекомендации вполне применимы и для других языков, а для JavaScript и TypeScript, к которым я постарался их адаптировать, так и вообще подходят отлично.

Эта статья - часть серии статей "Составляя ПО" про функциональное программирование и различные техники создания программ на JavaScript ES6+, начиная с азов. Оставайтесь на связи, много нового впереди!

Композиция: "Действие, заключающееся в составлении единого целого из частей или элементов."

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

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

Эта статья содержит рекомендации по написанию Dockerfile и принципам безопасности контейнеров и некоторые другие связанные темы, например про оптимизацию образов.

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

К счастью, большинство потенциальных проблем мы можем решить еще на этапе разработки.

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