При изучении Angular очень часто упускают или уделяют недостаточное внимание такому понятию, как проекция контента. Это очень мощный инструмент для создания гибких и переиспользуемых компонентов. Но в документации о нем упоминается лишь пару абзацев в разделе Lifecycle hooks. Попробуем исправить данное упущение.

Queue (очередь) — структура данных на диске или в оперативной памяти, которая хранит ссылки на сообщения и отдает их копии consumers (потребителям). Queue представляет собой Erlang-процесс с состоянием (где могут кэшироваться и сами сообщения). 1 тысяча очередей может занимать порядка 80Mb.

Binding (привязка) — правило, которое сообщает обменнику в какую из очередей должны попадать сообщения.

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

Рис. 1. OpenVPN vs WireGuard, тест Ars Technica

WireGuard — свободный и открытый протокол виртуальных частных сетей, призванный заменить IPsec и OpenVPN. В январе 2020 года после полутора лет доработки кода всё-таки состоялось долгожданное событие — Линус Торвальдс принял VPN WireGuard в основную ветку Linux 5.6.

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

Недавно мне пришлось столкнуться с необходимостью достать текст из офисных документов (docx, xlsx, rtf, doc, xls, odt и ods). Задача осложнялась требованием представить текст в формате xml без мусора с максимально удобной для дальнейшего парсинга структурой.

Решение использовать Interop сразу отпало по причине его громоздкости, во многом избыточности, а также необходимости устанавливать на сервер MS Office. В результате, решение было найдено и воплощено на внутреннем проекте. Однако, поиск оказался настолько сложен и не тривиален в силу отсутствия каких-либо общедоступных мануалов, что мной было принято решение написать в свободное от работы время библиотеку, которая решала бы указанную задачу, а также создать написать что-то вроде инструкции, чтобы разработчики прочитав ее смогли, хотя бы поверхностно, разобраться в вопросе.

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

1. Для платформы .Net не существует какого-либо готового решения для работы со всеми перечисленными форматами, что заставит нас местами кастылизовывать наш солюшн.
2. Не пытайтесь в сети найти хороший мануал по работе с Microsoft OpenXML: чтобы разобраться с этой библиотекой придется изрядно покрасноглазить, покурить StackOverflow и поиграться с отладчиком.
3. Да, мне все таки, удалось приручить дракона.

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

Работа с xlsx и docx

В этой статье Максим Шестаков, DevOps Engineer в студии Plarium Krasnodar, делится опытом сборки и доставки пользователям приложений для iOS, который накопился в процессе отладки CI/CD.

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

Юлия Волкова хочет проверить идею в реальности и пробует переложить на машину создание тестов на основе кода, причем без использования дополнительных инструкций или контрактов. О том, какие открытия приносит путешествие в мир метапрограммирования, AST, синтаксического анализа и токенизации, и чего это все позволило добиться в автогенерации тестов, Юлия расскажет на Moscow Python Conf++. А пока я расспросил, откуда появилась сама идея — автоматизировать тестирование, что лежит в основе прототипа и с чем еще предстоит справиться.

Привет, я Юрий Буйлов, занимаюсь разработкой в CarPrice, а также внедряю практики DevOps, микросервисы и Kubernetes. Хочу рассказать про Kubernetes в духе пиратства — только не про управление большим красивым кораблем на парусах, а, скорее, про флот маленьких неприглядных рыбацких лодочек, местами ржавых, но очень быстрых, шустрых и опасных.

Будет интересно тем, кто разрабатывает или переводит инфраструктуру на микросервисы, внедряет DevOps поверх Kubernetes и всячески идет в cloud native. Расскажу про наш путь, в конце статьи поделюсь нашими наработками окружения для микросервисов — дам ссылку на шаблон, который будет удобен для разработчиков и тестировщиков.

Эта статья — по видео выступления на конференции @Kubernetes Conference by Mail.ru Cloud Solutions, если не хотите читать, можно посмотреть.

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



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

Например, можно сообщить браузеру о том, что он не должен позволять использовать API Geolocation, передав ему следующий заголовок:

Feature-Policy: geolocation 'none'

У использования заголовка Feature-Policy есть, с точки зрения безопасности и производительности, множество плюсов. Но мне сейчас особенно нравится то, как Feature-Policy можно использовать для того, чтобы сделать более заметными проблемы производительности сайтов, которые обычно легко проглядеть. Это можно сравнить с чем-то вроде «линтинга производительности». В частности, речь идёт о выявлении проблем с изображениями, используемыми в веб-проектах.

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



В статье, перевод которой мы сегодня публикуем, представлен обзор 7 опенсорсных инструментов для мониторинга безопасности облачных систем. Эти инструменты предназначены для защиты от хакеров и киберпреступников путём детектирования аномалий и небезопасных действий.

Аутентификация в ASP.Net (Core) — тема довольно избитая, казалось бы, о чем тут еще можно писать. Но по какой-то причине за бортом остается небольшой кусочек — сквозная доменная аутентификация (ntlm, kerberos). Да, когда мы свое приложение хостим на IIS, все понятно — он за нас делает всю работу, а мы просто получаем пользователя из контекста. А что делать, если приложение написано под .Net Core, хостится на Linux машине за Nginx, а заказчик при этом предъявляет требования к прозрачной аутентификации для доменных пользователей? Очевидно, что IIS нам тут сильно не поможет. Ниже я расскажу, как можно данную задачу решить c минимальными трудозатратами. Написанное актуально для .Net Core версии 2.0-2.2. Скорее всего, будет работать на версии 3 и с той же вероятностью не будет работать на версии 1. Делаю оговорку на версионность, поскольку .Net Core довольно активно развивается, и частенько методы, сервисы, зависимости могут менять имена, местоположение, сигнатуры или вообще пропадать.

Что такое Kerberos, и как это работает, кратко можно прочитать в Wiki. В нашей задаче Kerberos в паре с keytab файлом дает возможность приложению на Linux сервере (на Windows, само собой, тоже), который не требуется включать в домен, пропускать сквозной аутентификацией пользователей на windows-клиентах.

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



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

Материал, перевод которого мы сегодня публикуем, посвящён рассказу о 10 React-компонентах.

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

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

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

Правило #1: Организуйте стабильный доход

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

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

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

Почему GCP?

При написание телеграмм ботов столкнулся с вопросом, как быстро и бесплатно сделать так, чтобы бот работал постоянно. Варианты с Heroku и Pythonanywhere имеют слишком маленькие лимиты, если у вас более одного бота. Поэтому я решил воспользоваться GCP. Платформа предоставляет бесплатно 300$ на год + огромные скидки при использование этих средств(до 94%).

Как захостить вашего бота?

Шаг 1. Регистрация на GCP

Переходим на сайт GCP и нажимаем Get started for free.

Зачем это необходимо

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

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

Привет, Хабр!

Это вторая часть из серии статей "Учимся разворачивать микросервисы". В предыдущей части мы написали 2 простеньких микросервиса — бекенд и шлюз, и разобрались с тем, как их упаковать в docker-образы. В этой же статье мы будем организовывать оркестрацию наших docker-контейнеров с помощью Kubernetes. Мы последовательно составим конфигурацию для запуска системы в Minikube, а затем адаптируем ее для деплоя в Google Kubernetes Engine.

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

Начало

Посмотрев на календарь, я понял, что уже 2020, а посмотрев на свою сборку, которая была с 2018 года, я понял, что пора её менять. В этой статье мы разберем структуру проекта, плагины (минимальный набор функционала) и их новые возможности, которые добавились за такое большое время. Мы разберем все моменты, чтобы новичок мог себе скачать эту сборку и начать с ней работать.

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

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

В преддверии 14 февраля самые активные из 500 разработчиков и ИТ-специалистов «М.Видео-Эльдорадо» составили список мест для техническо-романтических свиданий, куда они уже ходили со своими половинами или планируют заглянуть по случаю праздника.



Под катом подборка лучших вариантов, притом не только в Москве.

Я работаю в КОРУС Консалтинг СНГ 3 года, и за это время поучаствовала в проектировании девятнадцати B2B сервисов. Проектирование взаимодействия ассоциируется обычно с Axure, InVision, Moqups, Framer, (вставьте ваш любимый вариант), но мои инструменты — это HTML, SCSS и AngularJs. Я расскажу, как обычная практика сохранения HTML-шаблонов выросла в альманах полноценных макетов, и как группа верстальщиков во главе с арт-директором проектировала взаимодействие с интерфейсами всех продуктов КОРУС Консалтинг СНГ на протяжении шести лет.

И почему это работало.