🙊🙈🙉 Ещё остались люди, которые думают, что у middleware есть правильное и неправильное использование и при правильном все хорошо. Отличие мидлваров от цепочки ответственности в том, что в цепочке только одно звено берет всю ответственность, а в мидлварах в случае его правильного использовния все по очереди мутируют состояние, ну это тоже небезопасная практика. Это как взять сделать объект parameters и передавать его из функции в функцию по цепочке, каждая функция будет из объекта читать параметры, изменять и удалять, а потом передавать этот объект дальше. Если вы думаете, что никто в здравом уме так не сделает, то посмотрите в Node-RED это обычная практика программирования.
В кодовой базе Метархии теперь будем использовать void для консистентности возврата. Это системный код, в прикладном я не советую использовать void, он непривычен людям, лучше пишите длинный вариант.
Forwarded from Metarhia/NodeUA - Node.js Ukraine Community
Хорошее запоминание знаний, сигнатур методов, паттернов, алгоритмов, не делает вас автоматически профессионалом. Знания в современном мире под ногами валяются и что... значение знаний сильно преувеличено, а чем же тогда отличаются профессионалы? Только опытом и гибкостью ума, т.е. способностью переносить опыт из одной области в другую, проще в смежную, а чем выше профессионализм, тем более дальние области он может связывать. Например, перенос знаний между языками программирования — просто, между парадигмами — чуть сложнее, а вот брать из механики и электроники в программирование и обратно — это уже существенно сложнее, связывать архитектуру зданий и программ — еще сложнее, но гораздо более плодотворно, а ведь есть общие принципы у мифологии и эстетики, которые хорошо применимы в программной инженерии. Вот как вы отличаете красивый код? Как вы строите свой рассказ о шаблоне проектирования? Вас поймут и поверят только если вы обратитесь к символам и архетипам, человек так устроен, он не понимает явления иначе как через сказку, историю, миф о явлении, пусть даже в форме рационального, инженерного и научного повествования. Например, мы слышим про "блокировки" (locking api) и сразу возникают ассоциации, даже без зная теории, мы уже начинаем как-то думать про "объект" перекрывающий путь к "цели" (ресурсу), а слыша "конкурентность", "параллельность", "асинхронность" мы уже подсознательно начинаем представлять себе это в пространстве, в динамике, прям иллюстрации возникают, думать про это, как про электроны в полупроводниках совершенно непродуктивно, а как про конкретные вызовы api в платформе — слабо переносимо в другие проекты, вот мы и думаем про это единственным универсальным способом — разделяя общее на части, давая названия, создавая классификацию (объединяя в группы) и устанавливая связи между этими именами.
— Предлагаете переписать все с нуля?
— Просто переписывание не решит проблему, предлагаю переписать все два раза
— А можно делать это параллельно?
— Нет, только последовательно, первый раз мы поймем в чем проблема, а второй — уже сделаем хорошо
— Просто переписывание не решит проблему, предлагаю переписать все два раза
— А можно делать это параллельно?
— Нет, только последовательно, первый раз мы поймем в чем проблема, а второй — уже сделаем хорошо
Forwarded from Metarhia/NodeUA - Node.js Ukraine Community
🧑💻 Миф про разделение учебы, работы и жизни — максимально деструктивная позиция для вас, как профессионала и человека. Например, сначала обучился, а потом работаешь, но работаешь только на работе, а живешь только вне работы. Нет, дорогие мои, так не работает, это рецепт — как плохо учиться, а потом застыть в знаниях и ненавидеть работу, стараясь сбежать из нее в жизнь, и обкрадывать жизнь, вырезая из нее время работы. Я за то, чтобы все это максимально объединить, учишься всегда, работаешь всегда, живешь всегда. Никак не разорвать.
Каким должен быть хороший учебный проект? Для разработчиков информационных систем или data-aware (а это большинство программистов), систем где есть базы данных, пользовательский интерфейс, сервер приложений и взаимодействие по сети, модель предметной области и бизнес-процессы. Сюда прекрасно ложится и веб и энтерпрайз. Так вот, учебный проект лучше начинать не позднее чем через полгода после начала обучения и он должен быть сложный и желательно групповой, делаться несколько лет, постепенно с усложнением, включать не менее половины из: логирование, конфигурация, аутентификация и система прав, отложенные задачи, роутинг запросов, генерация отчетов, миграции, юнит-тесты, интеграционные и системные тесты, автоматическая сборка, телеметрия и сбор статистики, потоковое вещание, очереди, балансировка или оркестрация, интеграция с другими системами, интернационализация, резервное копирование и восстановление, распределенное хранение и обработка данных, коллаборативное редактирование, парсинг, система плагинов, многопоточность или асинхронность, многоуровневое кэширование, сессии, несколько разнотипных СУБД (например postgresql и redis), кодогенерация, обработка метаданных и метапрограммирование, многослойность, изоляция (запросов, пользователей, модулей и т.д.), межпроцессное взаимодействие и удаленный вызов процедур, транзакции и блокировки, рассылка почты и прочих нотификаций.
Forwarded from Metarhia/NodeUA - Node.js Ukraine Community
Если вы в чем-то уверены, то все вокруг вам подтверждает правильность вашей концепции, любой опыт и любое общение, будут только усиливать вашу веру. Посмотрите на ООПшников, функциональщиков, приверженцев статической типизации, противников статической типизации, любителей параллельного программирования с блокировками и адептов иммутабильных структур данных. Очень велик соблазн свести все к одному, но не просто к одному, а к своему, любимому способу, думайте...
Forwarded from Metarhia/NodeUA - Node.js Ukraine Community
Некоторые товарищи душнят и придираются к концептуальным примерам кода, поэтому буду показывать вам примеры кода, к которым сложно придраться, это одновременно и то, что я используюю в работе, достаточно концептуальные, интересные по приемам, простые и умещающиеся в слайды, но необычные штуки. Начинаем смотреть с примеров использования, они же тесты. Код тут: https://github.com/metarhia/metasql
Forwarded from Metarhia/NodeUA - Node.js Ukraine Community
💚 Активно использую стиль кода на базе следующих парадигм (не просто знаю или слышал, а предпочитаю в написании кода каждый день)
Anonymous Poll
3%
🖤 Неструктурное
24%
❤️ Процедурное
42%
💚 ООП и прототипное
38%
💛 Функциональное
15%
💙 Реактивное
3%
🤍 Автоматное
6%
💜 Метапрограммирование
3%
🧡 DSL языки
50%
❤️🩹 Пишу как попало
Forwarded from Metaeducation
— Учишься в ВУЗе на программиста? На какой специальности?
— Я специалист в области обхода двумерных матриц, сортировки массива пузырьком, могу выводить на экран коэффициентов многочлена любым способом: через std::cout, при помощи модуля crt, и даже через alert(), отлично знаю типы всех моих переменных
— Я специалист в области обхода двумерных матриц, сортировки массива пузырьком, могу выводить на экран коэффициентов многочлена любым способом: через std::cout, при помощи модуля crt, и даже через alert(), отлично знаю типы всех моих переменных
Я сторонник того, чтобы давать людям на собесах возможность листать доки, гуглить и даже спрашивать у нейронок. Что должен проверять собес? Эффективность, способность решать задачи, а не задротство, зубрежку и феноменальную память. Если вы начнете это делать, то внезапно для себя выявите, что даже при этом многие люди не справляются, полный интернет шедевров говнокода, оверинженеринга и архитектурного маразма. Еще мне важно, чтобы человек показал свое субъективное мнение, даже эмоциональную позицию по отношению к конкретным решениям и технологиям, именно это он будет проявлять в работе. А что сейчас на собесах происходит: эффект ивентлупа — люди вызубрили и могут наизусть рассказать фазы и красиво объяснить, а применить для принятия решений в коде не смогут, т.е. оно ничего не дает им в каждодневной работе.
Forwarded from Metaeducation
Please open Telegram to view this post
VIEW IN TELEGRAM
✨ Нужно всегда разделять прикладной и системный код (это минимум два слоя реальности), как и роли программистов, описал подробнее.
🧑💻 Прикладной программист пишет продуктовый код, занимается моделированием предметной области и автоматизацией процессов в ней. Прикладному программисту нужно знать node.js как инструмент, его возможности, концепции, преимущества и недостатки, но не нужно глубоко погружаться в код платформы, не нужно строить прослойку между node.js и прикладным кодом, не нужно изобретать фреймворки (внутри продукта), изобретать обобщенные инструменты и библиотеки, не имеющие отношение к предметной области. Если это происходит, то он выполняет две роли - системную и прикладную, они должны быть максимально отделены: отдельные репозитории, отдельное рабочее время и должность, отдельные цели и задачи. Чтобы писать системные вещи смотри вопросы в следующем разделе.
👨🔧 Системный (платформенный) программист пишет код, не связанный с предметной областью: фреймворки, сетевые протоколы, транслятор, компиляторы, интерпретаторы, библиотеки, занимается вещами, которые могут быть переиспользованы в сотнях и тысячах разных проектов. Это называется производство средств производства. Систем программисту нужно знать node.js гораздо глубже, не только, его возможности, концепции, преимущества и недостатки, но и недокументированные возможности и даже баги, особенности платформы, которые очень редко используются, потому, что он строит прослойку между node.js и прикладным кодом, а прослойка эта позволяет делать прикладной код более абстрактным и приближенным к предметной области.
🧑💻 Прикладной программист пишет продуктовый код, занимается моделированием предметной области и автоматизацией процессов в ней. Прикладному программисту нужно знать node.js как инструмент, его возможности, концепции, преимущества и недостатки, но не нужно глубоко погружаться в код платформы, не нужно строить прослойку между node.js и прикладным кодом, не нужно изобретать фреймворки (внутри продукта), изобретать обобщенные инструменты и библиотеки, не имеющие отношение к предметной области. Если это происходит, то он выполняет две роли - системную и прикладную, они должны быть максимально отделены: отдельные репозитории, отдельное рабочее время и должность, отдельные цели и задачи. Чтобы писать системные вещи смотри вопросы в следующем разделе.
👨🔧 Системный (платформенный) программист пишет код, не связанный с предметной областью: фреймворки, сетевые протоколы, транслятор, компиляторы, интерпретаторы, библиотеки, занимается вещами, которые могут быть переиспользованы в сотнях и тысячах разных проектов. Это называется производство средств производства. Систем программисту нужно знать node.js гораздо глубже, не только, его возможности, концепции, преимущества и недостатки, но и недокументированные возможности и даже баги, особенности платформы, которые очень редко используются, потому, что он строит прослойку между node.js и прикладным кодом, а прослойка эта позволяет делать прикладной код более абстрактным и приближенным к предметной области.
Forwarded from Metarhia/NodeUA - Node.js Ukraine Community
✨ К вопросам на собес по 🐢 #NodeJS 🚀 добавил еще 30 и их уже 100 там ✨ https://github.com/tshemsedinov/NodeJS-Interview-Questions
GitHub
GitHub - tshemsedinov/NodeJS-Interview-Questions: NodeJS ✨🐢🚀✨ вопросы для собеседований
NodeJS ✨🐢🚀✨ вопросы для собеседований. Contribute to tshemsedinov/NodeJS-Interview-Questions development by creating an account on GitHub.
Forwarded from Metarhia/NodeUA - Node.js Ukraine Community
⭐️ Нода стала невыносимо сложной ☠️ вот что я понял, пока писал все эти вопросы для собеседований. Основная задача фреймворков - это снятие сложности. Так вот они не справляются с этим вообще. Если человек пишет на фреймворке, то он находится под давлением сложности NodeJS, сложности JavaScript, асинхронного программирования + еще сложность фреймворка + сложность предметной области. Это совершенно невыносимо, друзья. В тех компаниях, где я CTO, архитектор или эдвайзор, я пытаюсь распределить эту сложность хотя бы по разным людям, поэтому разделил роли прикладного (продуктового) и системного (платформенного) программиста, но этого мало. У них ве равно есть достаточно большое перекрытие сфер компетенции, да и сами компетенции, даже разделенные пополам, уже переросли когнитивные способности среднего программиста. Вы заметили, что во всех проектах появляется прослойка между нодой и доменом? Сначала оно легковесное, а за год оно становится совершенно неподъемным, а будучи смешанным с продуктом это просто смерть для компании. Можно делить платформу и продукт на разные репы, можно делить команды, роли, рабочее время разделять, но если не внедрена культура открытого и свободного программного обеспечения, то сложность захлестывает. Вот берите этот свой платформенный код, свои библиотеки и фреймворки и выкладывайте их в Open source, они все равно не являются конкурентным преимуществом бизнеса. Так нет же, вы ссыте, и не хотите заниматься их поддержкой, постоянным обновлением, багфиксами, тайпингами, тестами, доками, комьюнити, не хотите, чтобы кто-то пришел и обругал весь ваш платформенный код за то, что он ужасен, не хотите открытого сравнения с другими библиотеками и фреймворками. Это что касается бекенда на Nodejs. Кто там занимается фронтом, скажите, что там у вас со сложностью, что с культурой?