S0ER

Почему так важно определить является архитектура монолитной или распределенной? Все просто - монолитные архитектуры хорошо растут "вертикально" и плохо "горизонтально", распределенные же архитектуры хорошо растут и "вертикально" и "горизонтально". Осуществить вертикальный рост всегда проще чем горизонтальный.

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

Как то на стриме спрашивали про то как найти проекты чтобы предложить свою помощь. Я смотрю трендовые репозитории вот здесь - https://github.com/vitalets/github-trending-repos

Для проекта Devs2Devs делал небольшой видос о том как обновлять форкнутый репозиторий с основным репозиторием (через upstream), а свою разработку делать в своем remote origin. Вероятно будет полезно тем кто будет участвовать в OpenSource проектах.

У меня есть платные видосы, которые размещены на сайте https://soer.pro - это стримы по архитектуре (более 20 часов видео), воркшопы, исходники проектов. Доступ к этим материалам теперь можно получить не только за деньги, но и через бартер. Принцип простой - "пишешь код, получаешь сертификат". Правила следующие: - нужно делать любые Pull Request к любому репозиторию на https://github.com/soerdev (любые - значит считается все: правка опечаток, верстки, написание кода, написание документации т.е. все что может быть оформлено в виде PR) - Единственное условие - Pull Request должен быть логически законченным (т.е. начал и бросил не пройдет) Если Pull Request принят, то далее идет следующий расчет: - за каждые 10 принятых PR - получаешь сертификат на 30 дней уровня "stream" - за каждые 20 принятых PR - получаешь сертификат на 30 дней уровня "workshop" раз в месяц самый активный участник получает сертификат на 30 дней уровня "PRO"

Опубликовал репозиторий gitlo на github - https://github.com/soerdev/gitlog Если есть желающие добавить информацию о своих проектах, то это можно сделать через pull request.

Когда-то слышал фразу: "ничто так не стимулирует к движению вперед, как ноль". Речь шла о статистике продаж в стартапах, на маркерной доске рисуется огромный "ноль", который напоминает о том, что первый шаг еще не сделан. Вспомнив эту фразу решил выводить статистику soer.pro только за сутки. До этого выводил просто суммарное значение показателей, но по ним не видно динамику.

В донатах иногда забавные комментарии встречаются: "Когда вы поженитесь с Димой Рожковым?" Вообще не понял к чему это, но, видимо, людей этот вопрос волнует ))))

Идея двигать OpenSource меня не покидает, поэтому решил сделать небольшой информационный сайт, где буду собирать всю информацию по проектам и видео, которые снимаю. https://gitlog.ru/

Анализ NPM (начало)

Планирую сделать несколько видосов по формальному анализу проектов. Для начала хочу поговорить про зависимости и развитие проекта, вот такой график "количество зависимостей / версия" для npm. Много чего интересного из него можно "вытащить".

Есть ли у вас проблема с доведением идей до реализации? Поясню о чем я, делая контент и развивая свои социальные проекты я реализую всего-лишь около 30% тех идей, которые у меня появляются. У меня есть много наработанного материала, который лежит и пылится, а я не могу снять по нему видео. Понимая, что распыляюсь, я пытаюсь сузить фокус, но все равно КПД остается низким. Не думаю, что это плохо, потому что лучше выполнить 30% от большой цели, чем 100% от маленькой. Смотреть на абсолютные цифры тоже надо. Мне просто интересно узнать если такая проблема у вас - если так же реализуете далеко не все, что задумали, то палец вниз, если реализуете более 75% своих целей, то палец вверх.

Запустил стрим - https://youtu.be/fVkx7JBvM1g

Принцип KISS

Принцип KISS - Keep it simple, stupid Принцип, который говорит о том, что простые решения работают и выполняют поставленные задачи, как правило, лучше сложных. Идея принципа в том, чтобы стремиться к "простому", избегая "сложного". Этот принцип интуитивно понятен - не делай "велосипеды", не используй лишнее, не додумывай задачу, не стремись к универсальному решению. Вот только частенько, делая все "по KISS", на выходе получается не элегантное, удобное решение, а глюкавый монстр. Почему так? Об этом я порассуждаю в своем следующем видео "Принцип создания хороших решений - KISS".

Очень интересно узнать какие пет-проекты вы для себя делаете (если у кто-то готов поделиться ссылкой на свой код, то смело кидайте в комментарии к тому посту). Я готов рассказать о ваших наработках на канале, если кто-то делает свои библитеки, то интересно было бы их использовать в своих проектах. В общем хочу зафиксировать ситуацию по состоянию на сейчас - кто и что делает. Потом буду переодически делать срез, чтобы понять появляются ли новые проекты. Как говорится "не стесняемся, подходим, рассказываем".

Запустил стрим https://youtu.be/2Bog1FpL1PU

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

Интересно не просто чтобы люди писали бесполезный код, а делали вещи, которые могут вылиться в свою собственную OpenSource разработку. Сейчас многие задаются этим вопросом - какой проект создать, чтобы он был полезным и развивал отечественный OpenSource. Мне кажется, что писать ToDo-лист в тысячный раз - это не интересно. А вот сделать какую-то библиотеку или отработать элементы фреймворка - это куда интереснее. Более того, хочется чтобы в итоге получилась синергия всех выполненных заданий, чтобы на их базе можно было получить какое-то более сложное решение. Я не видел в информационном поле людей, которые делали что-то подобное. Как правило встречается пересказ уроков, объяснения в тысячный раз базовых принципов, а чего-то по настоящему творческого и интересного нет.