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

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



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

Источник: Dribbble

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

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

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

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



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

Дэн Абрамов, в мае прошлого года, писал в своём Твиттере о том, что он не понимает микрофронтенды. Он полагает, что задачи, которые они должны решать, уже решены средствами хороших компонентных моделей. «Может, микрофронтенды — это решение организационных проблем, а не технических? Например, когда две команды разработчиков не могут ни о чём договориться, в том числе — об инфраструктуре проекта», — размышляет он.

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

Когда я, изучив основы HTML и CSS в 2014 году, занялся разработкой сайтов, сложнее и страшнее всего для меня было создание их заголовочных частей. Тогда технология Flexbox была ещё достаточно новой, поэтому мы вынуждены были использовать старые методы — вроде float-позиционирования и техники clearfix. Сегодня мир фронтенд разработки стал совсем другим. А именно, технология Flexbox получила широкую браузерную поддержку, что открывает нам множество новых возможностей.



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

А именно, здесь я расскажу о том, как, используя Flexbox-макеты, создавать качественные заголовочные части сайтов. Я поделюсь некоторыми советами, а в итоге продемонстрирую мой проект, созданный специально для этого материала. Поэтому, если вам и правда интересна тема, которую я тут решил поднять, вам, определённо, стоит дочитать эту статью до конца.

Здесь я исхожу из предположения о том, что вы владеете основами Flexbox-вёрстки. Вот, на всякий случая, моя статья, написанная для тех, кто хочет узнать больше о CSS-свойстве flex.

Совершенствование продуктов с применением когнитивных искажений и моделей убеждения.

Несколько лет назад коллега из моей бывшей компании (BlaBlaCar) познакомил меня с игрой Mental Notes. Разрабатывая какую-либо функцию, мы вместе с несколькими менеджерами по продукту, дизайнерами и разработчиками делали «поведенческий анализ», во время которого старались понять, как и какие принципы поведенческой психологии можно применить в проекте.

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

Поиск таинственной математики, на которой основана фигура в iOS

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

---

В знаменитом интервью 1972 года Чарльз Имз кратко ответил на несколько фундаментальных вопросов о природе дизайна. Отвечая на первый вопрос, он определил дизайн как «план компоновки элементов для достижения определённой цели».

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

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

Давайте сыграем в игру. У нас есть два ряда знакомых всем пользователям iOS-иконок. На первый взгляд иконки сверху и снизу одинаковые. Но это не так. В одном ряду вы видите настоящие иконки, а в другом подделку.





Можете ли вы определить, где какие? Не торопитесь, посмотрите внимательно? Ну что, выбрали?

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

Дело в том, что поддельные иконки по форме — это квадраты с закруглёнными углами, ну и прямоугольник если говорить о серой подложке.

Но! В интерфейсе iOS нет ни одного квадрата с закруглёнными углами. Все элементы в iOS, это не квадраты и прямоугольники — это суперэллипсы!

Сегодня мы поговорим про секреты в дизайнах продуктов Apple. Что такое суперэллипс? В чём магия формы иконок? И почему HomePod — это суперяйцо.

Перевод статьи подготовлен в преддверии старта курса «C# ASP.NET Core разработчик».

---

В этой статье я расскажу, как вы можете добавить страницы на основе Blazor в существующее приложение Razor Pages.

Предисловие

Выход Blazor на золото должен произойти через две недели. Многие вещи в проекте еще подвержены достаточно резким изменениям, и последняя предварительная 9-я версия значительно усложнила взаимодействие между компонентами Razor Pages и Blazor: теперь невозможно передавать параметры из страницы Razor в компонент Blazor с помощью Html.RenderComponentAsync. Это может измениться в будущем, но вполне вероятно, что в .NET Core 3.0 он появится с этим ограничением.

Если вы все же хотите улучшить свое существующее приложение на основе Razor Pages с помощью Blazor-магии, одно из решений — полностью создавать свои страницы в Blazor. В этой статье я покажу, как вы можете добавлять Blazor-страницы в существующее приложение на основе Razor Pages, где одни части приложения создаются с помощью Razor Pages, а другие — с помощью Blazor Pages. Для обоих типов страниц используется одинаковый макет.

Тестировать полезно. Тесты позволяют в автоматическом режиме безопасно рефакторить код и гарантируют его работу. Тесты – это живая документация: если информация в Wiki или в Confluence может устареть, то тесты всегда актуальны. Также многие крутые практики связаны с тестированием. Например, самотестирующийся код или разработка через тестирование (TDD), когда тесты пишутся перед кодом, а некоторые практики DevOps и Extreme Programming применимы только в условиях хорошего покрытия проекта тестами.



Но написать простые тесты, которые будут помогать в написании кода и не срывать дедлайны, задача сложная. Она становится ещё сложнее, если учесть, что нам приходится тестировать вёрстку. Это не два JSON сравнить: здесь не работают простые подходы «вызову функцию, проверю результат» — тестирование UI сложнее. Как эффективно и правильно тестировать верстку и писать для неё тесты, чтобы они были полезны, а дедлайны не горели, расскажет Максим Соснов (crazymax11), ведущий разработчик в СКБ Контур.

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



В наши дни очень легко организовать разработку маленького React-приложения, или начать работу над ним с нуля. В особенности — при использовании create-react-app. Некоторым проектам, скорее всего, понадобится лишь несколько зависимостей (например — для управления состоянием приложения и для интернационализации проекта) и папка src, в которой, как минимум, имеется директория components. Я полагаю, что именно с такой структуры начинается работа над большинством React-проектов. Обычно, правда, по мере того, как растёт количество зависимостей проекта, программисты сталкиваются с ростом количества компонентов, редьюсеров и других входящих в его состав механизмов, предназначенных для многократного использования. Иногда всем этим становится очень неудобно и сложно управлять. Что делать, например, если больше неясно то, почему нужны некоторые зависимости, и то, как они сочетаются друг с другом? Или, как быть, если в проекте накопилось так много компонентов, что становится сложно найти среди них именно тот, который нужен? Как поступить в том случае, если программисту нужно найти некий компонент, имя которого забыто?

Автор статьи, перевод которой мы сегодня публикуем, предлагает React-разработчикам отойти от использования create-react-app (CRA) и создать собственный шаблон для React-приложений. Здесь речь пойдёт о преимуществах и недостатках CRA, а так же будет предложено решение, которое способно заменить create-react-app.

В течение июня Саша Инкин и я, Рома Седов, запилили в Твиттере челлендж.

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

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

Давайте начнем!

Доброго времени суток, друзья!

Представляю вашему вниманию перевод статьи «Webpack: A gentle introduction» автора Tyler McGinnis.

Перед изучением новой технологии задайте себе два вопроса:

1. Зачем нужен этот инструмент?
2. Какие задачи он выполняет?

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

Салют, хабровчане! Подготовили для вас перевод полезного руководства в преддверии старта курса «C# ASP.NET Core разработчик».

---

С каждым обновлением .Net Core Microsoft доказывает тот факт, что .Net Core является самым мощным, универсальным и полным фреймворком, доступным для разработки мощных десктопных, мобильных, облачных и веб-приложений. В отличие от десктопного или мобильного приложения, веб-приложение работает по общедоступному адресу, что является одной из причин, по которым безопасность веб-приложения имеет огромную важность. Хотя Asp.Net Core разработан с учетом лучших практик безопасности, тем не менее, все же существуют некоторые уязвимости, за которыми мы должны следить до и после релиза нашего Asp.Net Core приложения.

В этой статье мы рассмотрим несколько пробелов в безопасности Asp.Net Core веб-приложений и их возможные решения. Давайте начнем с перечисления некоторых важных моментов для обеспечения безопасности нашего .Net Core приложения.

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

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

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

Мы давно обходили вниманием тему браузеров, CSS и accessibility и решили вернуться к ней с переводом сегодняшнего обзорного материала (оригинал — февраль 2020). Особенно интересует ваше мнение об упомянутой здесь технологии серверного рендеринга, а также о том, насколько назрела необходимость в полноценной книге по HTTP/2 — впрочем, давайте обо всем по порядку.

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

Перевод статьи подготовлен в преддверии старта курса «Разработчик C#».

---

Одной из наиболее важных функций .NET Core 3.0 и C# 8.0 стал новый IAsyncEnumerable<T> (он же асинхронный поток). Но что в нем такого особенного? Что же мы можем сделать теперь, что было невозможно раньше?

В этой статье мы рассмотрим, какие задачи IAsyncEnumerable<T> предназначен решать, как реализовать его в наших собственных приложениях и почему IAsyncEnumerable<T> заменит Task<IEnumerable<T>> во многих ситуациях.

Ознакомьтесь со всеми новыми функциями .NET Core 3