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 минут, без пропусков и увеличенных интервалов?

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

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

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

На сайте soer.pro опубликовал 26-ое архитектурное видео по теме инверсии зависимостей и потока управления. Поговорил об инверсии, как о инструменте проектирования, а не практическом решени для организации кода. Думаю, получилось интересно.

Раз за разом спрашивают про SICP, стоит ее читать или нет? Мне эта книга нравится, но "читать" ее нельзя, ее нужно изучать, потому что она рассматривает огромную часть базовой теории, которая необходима инженерам-разработчикам. Эта книга не подойдет "новым-воротничкам", которые не рассматривают себя в будущем инженерами. На курсах учить SICP, тоже самое, что давать нотную грамоту в самоучителе игры на гитаре! Если вы хотите влезти в структуру и интерпретацию компьютерных программ, то только этой книги будет недостаточно для формированя полноценной базы. Это лишь часть теории программирования, которую лучше изучать в профильном ВУЗе, чем пытаться учить по книгам или на курсе. Я склонен считать, что курсы, которые делают программу по этой книге, пытаются усидеть на двух стульях - сделать вид, что они "фундаментальные" и одновременно "адаптированные к рынку". Книга хорошая, но ничего не даст тем, кто хочет "просто писать фронт".

На soer.pro ответил на вопрос. Чтобы прослушать войдите на платформу - Развитие / Вопрос-ответ / Все вопросы

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

У нас тут в комментах пошел вопрос о том как защитить API от левого подключения, при условии что API в анонимном доступе. Вопрос сложный, так как любая защита доступа строится на "секрете", а у анонимного доступа есть проблемы с созданием и передачей секретов. Из практики могу посоветовать сделать такую штуку как "сценарии угроз", где пропишите от чего вы хотите защищать приложение и как. Например: - защита от парсинга/скачивания данных - api квоты (ограничение на IP) - токен авторизации - обфускация - защита от воровства токена - хэширование или контрольные суммы - защита от роботов - ... - защита от накрутки - ... - защита от DDOS - ... Когда конкретно будут понятны "угрозы" тогда и методы защиты станут более понятным. Если есть какие-то угрозы, которые непонятно как "закрыть" то это тоже хорошо, потому что знать слабые места - тоже важно.