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

Сделал зеркало для тех кому удобнее читать в телеге

https://t.iss.one/this_week_in_react

Почему директории utils и helpers это свалка?

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

С ростом проекта, количество функций в этой директории растет. Также растет и количество разработчиков в проекте. Функций появляется все больше и больше. Зачастую никто не следит за структурой этих модулей и вполне возможно появление дублирования кода.

Как это решить?
Забудьте о директориях utils и helpers. Эти названия никак не доносят суть содержимого. А из правил чистого кода мы помним, название должно быть однозначным и отражать назначение.
Следует задуматься, почему вообще появилась необходимость в вынесении функции?
Почему они используются в таких разных частях проекта?

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

Такой библиотеке нужно дать осмысленное однозначное название, написать документацию и тесты. Причем собрать в этой библиотеке весь связанный код. Например, вынести все функции работающие с датами во внутреннюю библиотеку lib/datetime. Префикс lib/ позволит избежать конфликтов имен, а также можно будет использовать простые и понятные имена. Конечно же, можно сделать npm scope, чтобы упростить будущую публикацию в npm. Например, @lib/datetime.

Чем это отличается от lib и helpers?
- весь код, выносится в полноценную библиотку с осмысленным названием, документацией и тестами
- lib явно описывает содержимое: это библиотека
- рефакторинг, публикация или удаление этой библиотеки становятся тривиальными задачами

Не так давно в чатах обсуждали (снова) чем отличается фреймворк от библиотеки.

https://dev.to/ben/whats-the-difference-between-a-library-and-a-framework-3blo

В двух словах:
- В случае фреймворка, вы встраиваете свой код в его архитектуру
- Но библиотеку вы самостоятельно встраиваете в собственную архитектуру

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

https://foobarbaz.club/why-i-stopped-using-snapshot-testing-with-jest/

Ребята, вы давно просили видео с презентации React SPB Meetup об atomic design и feature slices, но нам запороли запись.
Поэтому я вынес ключевые слайды с комментариями в отдельный канал.

https://t.iss.one/joinchat/AAAAAFcbHfDlRV0eK8kt8w

У меня каждая директория описывает либо одну сущность, либо их набор.

features/ — набор сущностей
features/name — одна сущность
./pages/ — набор сущностей

с файлами похожая штука
./reducer.js — одна сущность
./actions.js — набор сущностей

Вложение директорий определяется вложением сущностей.

— как понять, что есть сущность, а что нет?
— нужно определиться, можно ли с “этим” работать не погружаясь в детали. Можно ли к “этому” обращаться как единой цельной структуре?

страница регистрации сущность? Мы можем ее заимпортить как цельную сущность — да. Можем изменить именно эту страницу — да. Страница цельная сама по себе — да.

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

Тем временем, я ухожу из коммерческой разработки на JavaScript.
Возможно, здесь будет больше постов о js и rust

@artalar подкинул статью: https://daneden.me/2018/01/05/subatomic-design-systems/

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

@sredov раздобыл такой подход: https://medium.com/ge-design/ges-predix-design-system-8236d47b0891

В его основе лежит @AtomicDesign

Нашел очередной бандлер пакетов.

Эта штука позволит собрать почти любой package: javascript, typescript, reasonml, wasm и в несколько таргетов node, web, bin.

pika имеет минималистичный API и расширяемую систему плагинов.

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

https://github.com/pikapkg/pack

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

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

Так что тс отправляется в мусорку. Флоу может быть и можно использовать. Из перспективных типизаций вижу только полноценные языки поверх жс: elm, reason, или ещё что.

События - это не команды.
Событие - это не намерение что-то сделать, а оповещение о том что случилось

В componenDidMount компонента не нужно, пожалуйста, тригерить экшен "loadData", правильнее стрегерить "componentMounted"

Факты, в отличии от намерений, не указывают что делать, а лишь оповещают систему о том что произошло, а уже дальше каждый (модуль) сам решает что с этим делать

Что используете в проде с react?

▪️ 34% (158) Классы

▫️ 40% (184) Хуки

▪️ 14% (67) ХОКи

▫️ 9% (44) recompose
🔠 Можно выбрать несколько вариантов
👥 453 (310) - всего голосов

На днях меня позвали пообщаться о расте в подкаст "Цинковый прод".
Высказал немного своего мнения.
Подписывайтесь, ребята интересные темы задвигают.

https://soundcloud.com/znprod/010-rust-i-rifmy-pochemu-funktsionalnoe-vazhno-kogda-indeksy-reshayut-go-i-realnyy-mir

Сколько времени тратить на личные проекты?

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

Каждый день мне не хватало времени. Я не успевал записать хотя бы одну идею, а их рождалось очень много. Со временем, я научился формулировать каждую идею в 2-3 предложениях. Стал выписывать их в тетрадки. В какой-то момент количество тетрадей перевалило за третий десяток. Пришло осознание, что я делаю что-то не так: я только придумываю новые идеи, но не реализовал ни одной. Надо это менять.

Казалось бы, возьми любую идею и реализуй. Но не всё так просто. Даже самая простая идея, потребовала бы для запуска серьезных финансовых вложений, не говоря уже о навыках. Тогда я познакомлся с кучей подходов по созданию и управлению проектами: SMART, SCOPE-PAK, PMBoK и т.д. Но ни один не приносил результатов. Да, я составлял план и пытался оценить свои возможности. Да, я оставлял только самое необходимое от каждой идеи. Да, я устанавливал минимальные сроки для реализации каждой вехи.

Я думал, что достаточно хорошо описать проект, составить план, а дальше всё пойдет как по маслу, само собой. Найти единомышленников будет легко, ведь идея глубоко расписана и распланирована разработка. Инвесторы будут в восторге от бизнес-плана с покрытием всех рисков. Реальность дала о себе знать на первой встрече с представителем группы инвесторов: "План, покрытие рисков, желание, это всё конечно хорошо, но где опыт? Откуда нам знать, что Вы действительно сможете реализовать тот план, который описали. В вашем послужном списке нет сильных навыков управления компанией".

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

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

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

Так сколько же времени тратить на личные проекты, чтобы выйти за рамки наёмного работника. Чтобы понять это, невозможно обойтись без определения своих целей. Может быть Вы счастливы приходя в офис и получая свою зарплату. Зачем в этом случае отправлять в неизведанные воды?
Если Вы каждый день просыпаетесь с мыслью, что жизнь не такая, как Вам хотелось бы — пора менять свою жизнь.

Начните делать то, что приблизит Вас к вашей цели. Тут всё просто, есть две категории дневных дел: полезные и развлекающие. Нужно избавиться от людых занятий, которы отдаляют Вас от своей цели. А также необходимо сбалансировать полезные дела и развлекающие, отдых невероятно важен для прогресса. Если нехватает времени в сутках, попробуй вставать в 6-7 утра, а ложиться в 22-23. Утром мало отвлекающих факторов, мозг ещё свеж и чист, можно начать планировать свой день или выполнять работу по личным проектам. Если сложно проснуться и заставить себя работать, поход в спортзал приведет организм в тонус.