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

Сейчас многие фреймворки имеют в своем арсенале CLI (Command Line Interface) и ангуляр – не исключение. Впервые с CLI-утилитами я столкнулся, когда пробовал EmberJS и тогда мне это показалось очень удобным инструментом, который довольно сильно экономил мое время. Но, к сожалению, из коробки CLI-утилиты подходят только для несложных, домашних проектов.

Использование их же в крупных production-проектах без допилки напильником почти невозможно. Поэтому на старте нашего проекта мы вынуждены были отказаться от его использования из-за особенностей нашей архитектуры. Почти год я периодически смотрел в сторону Angular CLI в плане его развития и огорчался, что мы не можем его использовать, так как это сделало бы вход в проект гораздо проще. Но в один прекрасный момент команда Angular выпустила @angular-devkit, который содержит в себе набор пакетов, используемых cli утилитой, и это дало нам возможность допилить Angular CLI под наши нужды. Репозиторий содержит на сегодняшний день с десяток пакетов, но в этой статье мы рассмотрим только те, которые относятся к schematics.

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

После перехода нашего продукта на Angular 2+ мы столкнулись с тем, что Ангуляр предоставляет свой механизм для описания анимации. Поскольку Ангуляр полностью владеет транзакциями DOM, то он может упростить описание анимации и мы решили попробовать отказаться от анимации на CSS. Да и в целом было интересно посмотреть, что из этого получится. За почти год разработки проекта мы так и не перешли обратно на CSS-анимацию, и я могу сказать, что можно вполне успешно жить с анимацией Ангуляра. В этой статье я расскажу, как использовать анимацию в проектах на Angular 2+ и о возможностях, которые до сих пор почему-то не описаны в официальном гайде.

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

По оценкам Минкомсвязи России, дефицит кадров в ИТ-отрасли оценивается в 350–400 тысяч специалистов — почти столько же, сколько работает в этой сфере сегодня. Анализ рынка труда (по данным hh.ru) в разрезе ИТ-профессий позволяет сделать вывод, что ежегодно потребность в ИТ-специалистах возрастает примерно на 25%. Так, в отношении значений 2016 года к 2015 году, прирост ИТ вакансий составил 28%. Об одном из способов решения вопроса нехватки кадров далее в нашей статье.

В своей статье я хочу поделиться с вами опытом использования нового Angular как основы для наших enterprise приложений. Речи о том, что новый Angular лучше, чем React, Vue или какая-то другая популярная сейчас библиотека, в статье не пойдет, хотя, конечно, я буду сравнивать его с конкурентами. Все решения имеют свои плюсы и минусы, и то, что хорошо подошло одному проекту, может устроить сущий ад в другом. Итак, прежде чем объяснить, чем нас зацепил новый Аngular, расскажу немного о том, что мы уже используем в разработке.

Наш основной проект имеет долгий путь развития и построен на уже устаревших технологиях — Marionette + Backbone + Coffescript. Пару лет назад мы поняли, что развивать проект в таком стеке стало довольно тяжело, и начали изучать альтернативы в экосистеме фронтенда и думать, как же нам мигрировать туда нашего «зверя».

В первой части статьи вы получили краткое представление о драйверах в привилегированном режиме. Настало время покопаться в нашей песочнице.

Если вам случалось писать большие приложения, вы, вероятно, использовали такие виртуальные машины, как VMWare, Virtual PC или что-то иное. Но задавались ли вы вопросом: как они работают? Эти удивительные, можно сказать, магические технологии увлекали меня довольно долгое время. Чтобы развенчать «магию» и разобраться в деталях, я написал «с нуля» собственную систему виртуализации – «песочницу». Решение этой задачи было довольно сложным делом. Реализация подобного продукта ставит множество вопросов, ответы на которые вы не найдете в Google, поэтому я хочу поделиться своим опытом с сообществом.

Каждый JS-разработчик рано или поздно начинает писать тесты и сожалеть, что не стал делать этого раньше. Поскольку за последние пару лет все постепенно перешли к компонентной разработке на основе React, Angular или, например, Vue, это дало очередной толчок для популяризации тестирования, так как компоненты обычно малы и тестировать их гораздо проще. В данной статье мы рассмотрим компонентное тестирование в React.

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

Рано или поздно, но вы, как и наша компания, можете столкнуться с ситуацией, когда количество используемых в вашем продукте сервисов, резко возрастает, да и все они к тому же оказываются очень «говорливыми». Произошло ли это из-за перехода на «хайповую» нынче микросервисную архитектуру или вы просто получили пачку заказов на небольшие доработки и реализовали их кучкой сервисов — неважно. Важно то, что начиная с этого момента, ваш продукт обзавелся двумя новыми проблемами — что делать с увеличившимся количеством данных, гоняемых между отдельными сервисами, и как не допустить хаоса при разработке и поддержке такого количества сервисов. Немного поясню про вторую проблему: когда количество ваших сервисов вырастает до сотни или более, их уже не может разрабатывать и сопровождать одна команда разработчиков, следовательно, вы раздаете пачки сервисов разным командам. И тут главное, чтобы все эти команды использовали один формат для своих RPC, иначе вы столкнетесь с такими классическими проблемами, когда одна команда не может поддерживать сервисы другой или просто два сервиса не стыкуются между собой без обильного уплотнения места стыка костылями. Но об этом мы поговорим в отдельной статье, а сегодня мы обратим внимание на первую проблему возросших данных и подумаем, что мы можем с этим сделать. А делать нам в силу нашей православной лени ничего не хочется, а хочется добавить пару строчек в общий код и получить сразу профит. С этого мы и начнем в данной статье, а именно — рассмотрим сериализаторы, встраивание которых не требует больших изменений в нашем прекрасном RPC.