S0ER

Итак, конкурс на лучший пятничный юмор. Продолжи историю "Сидят в баре два программиста, один смеётся, второй грустный, бармен спрашивает почему ты такой грустный?" ... Ваши варианты в комментарии )

Статья об основах веб-архитектуры, подойдет для новичков. Содержит много упрощений, некоторые на грани ошибок. Например, слоистую архитектуру перемешали с луковой. Но в целом статья годная. https://www.freecodecamp.org/news/an-introduction-to-software-architecture-patterns

В этом месяце сложилась драматическая ситуация вокруг подписки PRO. По правилам самый активный контрибьютер месяца получает PRO. В этом месяце было минимальное количество правок и победа досталась очень легко... Но кому? С одной стороны mdlufy сделал 8 коммитов, а NimRoen сделал больше правок (точнее выиграл по количеству удалений) По правилам коммиты участвуют для получения stream и workshop, а активность при получении PRO. Поэтому в этом месяце подарочный сертификат PRO уходит NimRoen.

И еще один ответ на soer.pro

Ответил на вопроc на сайте soer.pro

На самом деле люди больше склоняются к концепции "один инструмент для всего", чего "для каждой задачи свой инструмент". Это происходит на интуитивном уровне, думаю, что этому даже есть какое-то разумное объяснение. Например, люди предпочтут один мощный смартфон взамен фотоаппарата, медиаплеера, телефона и портативной игровой приставке. Тоже самое с github, вместо хранилища "кода", он становится хранилищем "знаний" и это удобно, как по мне. Поэтому я решил подобрать несколько репозиториев которые содержат "знания", способные помочь на пути саморазвития. 1. Любимая тема всех разработчиков - какой путь изучения выбрать, есть целый репо, который содержит ответ https://github.com/kamranahmedse/developer-roadmap 2. Второй любимый вопрос - где взять литературу, и вот репо с бесплатными книгами (правда по архитектуре там нет, эта тема впринципе плохо раскрыта) https://github.com/EbookFoundation/free-programming-books/blob/main/books/free-programming-books-ru.md 3. По архитеутре можно глянуть пример дизайна системы (как раз архитектурный взгля) https://github.com/donnemartin/system-design-primer 4. 30-ти секундные сниппеты, примеры коротких кусков кода, которые могут пригодится на практике https://github.com/30-seconds/30-seconds-of-code 5. На закуску практические реализиации идей, по разным тематикам (можно построить свой клон одного из популярных проектов) https://github.com/codecrafters-io/build-your-own-x #ссылки #знания

Понедельник день тяжелый, давайте для разминки дам пару простых вопросов: 1. У нас есть два скрипта, запуск которых крутится в бесконечном цикле. Первый запускается раз в Х минут, второй раз в Y в минут, можно ли так подобрать X и Y, чтобы скрипты запускались хотя бы раз в день, но не запускались вместе. 2. Можно ли средствами крона запускать скрипт один раз в 9 минут, без пропусков и увеличенных интервалов?

"План, что и говорить, был превосходный: простой и ясный, лучше не придумать. Недостаток у него был только один: было совершенно неизвестно, как привести его в исполнение." Льюис Кэрролл

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

"У вас все ужасно, нужно переделать" - это классический паттерн поведения молодого специалиста, который только пришел в компанию. У всех есть история как условный "студент" после ВУЗа приходит на рабочее место, и начинает жаловаться, что используются старые технологии, методологии не соответствуют современным требованиям и т.д. Обычно более опытные коллеги понимающе улыбаются и ничего не делают, через некоторое время специалист притрется и поймет, что есть очень много причин почему система работает именно так, а не иначе, многие из них даже не заметны сразу. Но бывает так, что "новичок" попадает в струю, когда есть руководитель, который вместо разумного сдерживания порывов нового специалиста, поддерживает инициативу. В большинстве случаев это приводит к тому, что ничего хорошего не получается. И если повезет, то компания потеряет деньги, но не бизнес. А в худшем случае может развалиться и вся работающая система. Многие думают, что в реальной жизни опытный руководитель никогда не допустит такой ситуации. Но на практике любая смена руководства в точности повторяет этот паттерн. Приходит новая "метла" и начинает менять сложившуюся структуру. Это дорого, неэффективно, бессмысленно, но повторяется из раза в раз. Мой подход всегда сводится к эволюционным подходам, когда определяются новые вектора развития и постепенно корректируется существующая система. Это проще и для самой команды (понятно, что и как делать) и для бизнеса (не приходится разово вливать кучу денег). Но очень плохо с позиции имиджа "решенца проблем", многим кажется, что они и сами бы сделали ровно так же. И результат достигается как бы сам собой. Но это и есть профессионализм, когда система работает, развивается гладко, без громких факапов, когда команда работает в хорошем, спокойном темпе, а не бегает с выпученными глазами. Поэтому если все идет ровно - это и есть "правильно".