Всем привет. В сентябре в OTUS стартует сразу несколько курсов по JS-разработке, а именно: JavaScript Developer. Professional, JavaScript Developer. Basic и React.js Developer. В преддверии старта этих курсов мы подготовили для вас еще один интересный перевод, а также предлагаем записаться на бесплатные демо-уроки по следующим темам:

• Разработка библиотеки компонентов на React + Storybook
• Разработка через тестирование в JS или как начать любить программирование
• Миграция реального проекта с Javascript на Typescript — боли и особенности

А теперь перейдём к статье.

---

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

Как один компонент получает доступ к информации (особенно к переменной состояния), которая находится в другом компоненте? Как один компонент вызывает функцию, которая находится в другом компоненте?

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

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

Несколько лет назад я читал на Хабре про скандал разраба Алексея Адамовского с компанией Xored. Липкий кейс, компания не заплатила человеку деньги, и для меня сразу стал очевиден главный враг в этой истории. Непонятно было другое. Адамовского наняли работать в новосибирском офисе компании, а он очень хотел поработать в пражском. За те же деньги. Кое-как уговорил их и уехал туда. В целом его право, но меня тогда очень задело другое — неужели человек настолько ненавидит жить в РФ, что готов смотаться отсюда на любых условиях?

Привет, Хабр! Меня зовут Артём и я тимлид в Skyeng. У моей команды разработки есть заказчик, он же продуктовый менеджер, он же просто Ваня. Ваня считает, что наша схема с оценкой задач не идеальна. Например, оценка в 2 дня ничего ему не даёт. Свою задачу на проде он увидит через неделю или дней 10. Или больше. Или меньше.

Сложно такое осознать, я думал, меня настигнет эта участь несколько позже, когда мне будет хотя бы 30+ и я буду каким-нибудь крутым разрабом в известной компании, но мне 26 и я в NoName конторе.

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

Реакт это все что вам нужно для управления состоянием вашего приложения.

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

Существует метод управления состоянием который лично я пытаюсь применять еще с тех пор как я начал использовать Реакт. И теперь, после релиза хуков (hooks) и улучшения контекстов (context), этот метод управления состояниями стало очень просто использовать.

Все мы любим Spring. Или не любим. Но по крайней мере знаем. Если вы Java-программист, то вероятно используете этот фреймворк каждый день в своей работе. Spring — это огромная платформа, которая предоставляет большой функционал. Тем не менее во главе угла стоят две вещи — это DI (Dependency Injection) и IoC (Inversion of Control). Концепции, которые были призваны, чтобы сделать наш код более читаемым и поддерживаемым. Но к несчастью, все оказалось не так радужно. Именно это мы сегодня и обсудим.

Я думаю, многие из Вас слышали мнение о том что кода в контроллерах быть не должно, и потому контроллер с методами в одну строку считаются «Best Practice».Я в свою очередь сомневаюсь в том, что польза от этого так уж велика. Если у Вас возникали похожие мысли, прошу под кат.

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

Среди тем предстоящей конференции TechLead Conf 2020 будет детальное обсуждение Domain-Driven Design и EventStorming. Помимо подготовки 2-слотового доклада Константина Густова о DDD, доклада Сергея Баранова об EventStorming и митапа, во время которого мы будем создавать DDD-радар, мы решили перевести статью об одном из самых популярных способов проектирования bounded context.

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

Привет, Хабр! Предлагаю вашему вниманию перевод статьи Implementing SOLID and the onion architecture in Node.js with TypeScript and InversifyJS автора Remo H. Jansen

В этой статье мы рассмотрим архитектуру, известную как слоистая (onion). Слоистая архитектура — подход к построению архитектуры приложения, придерживающийся принципов SOLID. Он создан под влиянием DDD и некоторых принципов функционального программирования, а также, активно применяет принцип инъекции зависимостей.

Предпосылки

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

Принцип разделения ответственности

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

Привет, друзья. Эта статья написана Георгием Могелашвили (glamcoder), который работает на позиции Lead Developer в Booking.com в Амстердаме и отвечает за архитектуру и координацию нескольких технических команд в отделе маркетинга, а по совместительству Георгий преподает в OTUS на курсе Team Lead 2.0.

---

-Почему ты хочешь стать тимлидом?
-В смысле почему?

Такой диалог можно услышать довольно часто. Ведь на самом деле работа тимлида кажется почетной, интересной и не особо пыльной. Да еще и платят больше. Красота, а не работа, ведь так?

В этой статье я постараюсь вас в этом переубедить и рассказать 5 причин, почему вам НЕ стоит становиться тимлидом.

Делюсь одной из своих библиотек которая называется First DI. Она уже много лет помогает мне решить проблему внедрения зависимостей в браузерных приложениях для таких библиотек как React, Preact, Mithril и другие. При написании First DI за основу была взята идеология DI библиотек языков C# и Java, такие как autofac, java spring autowired, ninject и другие. И точно так как библиотеки из этих языков First DI работает опираясь на рефлексию и интерфейсы Typescript.

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

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

В одном из предыдущих материалов мы писали о ЯП Sporth, разработанном для проведения музыкальных live-сессий. Сегодня расскажем еще об одном инструменте для «музыкального программирования» — языке Csound. И поговорим о его аналогах — SuperCollider и Pure Data.

TypeScript позволяет автоматизировать множество задач, которые, без использования этого языка, разработчикам приходится решать самостоятельно. Но, работая с TypeScript, нет необходимости постоянно использовать аннотации типов. Дело в том, что компилятор выполняет большую работу по выводу типов, основываясь на контексте выполнения кода. Статья, перевод которой мы сегодня публикуем, посвящена достаточно сложным случаям вывода типов, в которых используется ключевое слово infer и конструкция as const.

Web Audio API существует уже давно, и про него есть немало статей. Поэтому про сам API много говорить не будем. Расскажем, что Web Audio и Angular могут стать лучшими друзьями, если их правильно познакомить. Давайте сделаем это!

Зимой 2012-го коллега предложил мне, С++ программисту с пятилетним стажем, написать первое приложение под Android. Ещё через год я начал руководить небольшой командой мобильных разработчиков, и с тех пор размеры моих команд стабильно росли. Но в прошлом году, после 2 лет руководства отделом мобильной разработки, я снова сдул пыль с любимой IDE.



Давайте расскажу, как было на той стороне, почему я вернулся в разработчики в возрасте 30+ (спойлер) и не жалею об этом.

Спустя годы после выхода "Domain-Driven Design", идеи Эванса вошли мейнстрим. Разработка через моделирование должна была уменьшить неопределенность, позволить разрабатывать ПО за меньшее число итераций. Должна была, но ничего не вышло.

На собеседованиях и митапах я слышу

Мы пытались внедрить DDD, но у нас не получилось

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

Под катом: 5 способов провалиться на внедрении DDD

В последние годы я часто использовал Redux, но в последнее время использую MobX в качестве альтернативы управления состоянием. Кажется, что альтернативы Redux естественно превращаются в беспорядок. Люди не уверены, какое решение выбрать. Проблема не обязательно «Redux vs MobX». Всякий раз, когда существует альтернатива, людям любопытно, как лучше всего решить их проблему. Я пишу эти строки, чтобы устранить путаницу вокруг решений по управлению состояниями Redux и MobX.

О чем будет эта статья? Во-первых, я хочу вкратце вернуться к проблеме, которую решает библиотека управления состоянием. В конце концов, все будет хорошо, если вы просто используете this.setState() и this.state в React или его вариацию в другой библиотеке уровня представления или в среде SPA. Во-вторых, я буду продолжать давать вам обзор обоих решений, показывая последовательность и различия. И последнее, но не менее важное: если у вас уже есть приложение, работающее с MobX или Redux, я хочу рассказать вам о рефакторинге из одной в другую библиотеку управления состояниями.

У среднестатистической ИТ-компании есть требования, история таск-трекеров, исходники (возможно, даже с комментариями в коде), инструкции на типовые, важные и сложные случаи на проде, описание бизнес-процессов (от онбординга до “как пойти в отпуск”), контакты, ключи доступа, списки людей и проектов, описание зон ответственности — и куча других знаний, о которых мы наверняка забыли и которые могут храниться в самых удивительных местах.


Знания =/= документация. Это нельзя объяснить, это надо запомнить

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