Задачки по программированию

Надо ли коммерческому программисту знать алгоритмы и структуры данных? Поможет ли в работе опыт спортивного кодинга? В целом — напрямую нет. Коммерческий код сильно отличается от олимпиадного, в нем бОльшее место занимают вопросы поддерживаемости, вообще необходимости определенных фич и их влияния на бизнес логику, читаемости кода, организации. Хороший олимпиадный программист совсем не обязательно будет хорошим коммерческим кодером. Ведь в задачах на алгоритмы не принято обсуждать условия, а все что нужно сделать единожды написать решение, не заботясь о поддерживаемости и читаемости. А хороший же коммерческий кодер получив задачу в первую очередь разбирает ее, задает вопросы по ней, может предложить вообще сделать немного другую задачу — и это правильно. Да и необходимые по ходу дела стандартные алгоритмы вшиты в фреймворки и библиотеки, которые должен уметь использовать коммерческий кодер.

НО. Решение задачек по спортивному программированию, это как тренажер для мозга. Оно может настроить необходимые нейронные связи, потренировать логическое мышление, заставить думать пошагово и расширять кусок на глобальный алгоритм. Я сам занимался олимпиадами всю школу и учебу в вузе, и хоть в чистом виде мне эти навыки почти не пригодились (ну несколько случаев конечно было), влияние на скорость решения задач помогает каждый день.

Поэтому если вы начинаете свой путь в программировании, важно понимать, что да, в коммерческой разработке важны немного другие вещи нежели в спортивном кодинге. И важно писать и собственные пет-проекты похожие на проекты реального мира (на 99% состоящие из скучных запросов к бд и сторонним апи). Но безусловно полезно, в качестве фитнеса для мозга, и набития руки зарегаться на codewars и leetcode и допроходить хотя бы до medium уровня

Требуются разработчики

Открыты пара мест для начинающих (и не только) веб-разработчиков.

Что делаем:
В основном кастомная веб/мобильная разработка. Некоробочные решения на фреймворках, в основном пишем на laravel + react/vue. Немного реже node.js, совсем изредка python, но при желании изучить дополнительные технологии — найдем где с пользой применить знания. Разрабатываем решения для екоммерца, финтеха, веб-сервисы для стартапов, системы учета и аналитики, интеграции, автоматизации процессов.

Кто нужен:
Ищем разработчиков разного уровня, ты либо уже опытный фуллстэк (предпочтительнее laravel+react), либо было бы интересно им когда-нибудь стать. Рассматриваем студентов и джунов, необходимо будет (если всего списка пока нет, но есть желание освоить - все равно пишите):
- написание api бэкенда. роутинг, mvc архитектура, crud операции, валидация запросов, аутентификация и авторизация
- базовые навыки верстки, простой фронтенд на js (ajax запросы), в идеале знакомство с react/vue
- работа с бд, как использование orm так и написание raw запросов
Тоесть в целом готовы начинать работать и прокачивать людей с уровня "могу написать todo-приложение"

Предлагаем:
- почасовая оплата
- нагрузка от 15 часов в неделю (чем больше можете — тем лучше), возможность совмещать с учебой, возможность подработки в летний период
- помощь опытных разработчиков, возможность профессионального роста и быстрого роста ставки

Отклики и вопросы — пишите @navlis23, по возможности прикладывайте гитхаб с примерами любого кода и описывайте свой опыт в программировании

Арсенал инструментов менеджера

Проблема всех управленческих решений в том, что они не универсальны. В одной ситуации решение будет работать, и тут же в чуть другой нет. Гарантий нет никаких, мы только влияем на вероятность того или иного исхода, и на адекватность каждого решения влияет много переменных. Поэтому важным критерием «мощи» управленца для меня всегда было разнообразие арсенала инструментов и возможных решений к каждой ситуации. Чем больше к одной ситуации человек знает подходов, тем выше вероятность, что он сможет выбрать более подходящий вариант, и не впадет в ступор когда действия «по привычному шаблону» упрутся в тупик

Потому управленцу важно расширять возможный спектр тактик и действий которые он может приложить к той или иной ситуации. Естественно в основном все это приходит с опытом, но и новичку можно ускорить процесс.

Что может помочь, а в идеале все вместе:
1) Ретроспективы. Задним числом мы все умнее всех, и это вполне можно использовать с пользой, а не только раздражаться от очередного умника рассказывающего о том "как же ты не догадался"). Потому после любых факапов, авралов, сдач проектов или этапов полезно подумать самому задним числом и понять, что можно было сделать, чтоб все возможно случилось лучше - обычно постфактум понимание вариантов всегда приходит, и важно обратить на них внимание, чтоб возможно использовать в будущем. Если осознанную ретроспективу не провести - опыт закрепится намного хуже. Важно, впрочем, не заморачиваться слишком сильно, и не ловить дизмораль, даже если найденное решение покажется очень простым. Ведь таким оно кажется только когда уже знаем итог, да и то что оно бы помогло - лишь предположение.

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

3) Чужой опыт. Хоть поговорка и говорит, что учиться намного лучше на чужик ошибках, по факту же большинство вещей все равно действительно доходит, только когда сам столкнешься и "проживешь". Однако, действительно сильно проще если до этого нас хотя бы предупредили как оно будет, адаптация пройдет проще, да и варианты возможных решений уже будут известны. Потому не забываем кроме личного опыта обращать внимание на чужие кейсы, выступления, работы. Книжки опять же можно почитать, в качестве рекомендации новичку к примеру: Питера Друкер «Эффективный руководитель»

Задачи не высечены в камне

Что обычно бывает когда нам прилетает новая задача от руководства или клиента? Вот нам скинули ТЗ или описали требования — в хорошем случае мы даже позадавали вопросы, и предположим даже, хоть как-то убедились в том, что верно все поняли и имелось в виду именно это. Ну и пошли делать, все просто. Но дьявол в мелочах, в большинстве случаев все будет ок, вот только та малая часть задач на которых "что-то пошло не так" легко сожрет большую часть времени и нервов. Я сам сотни раз тратил кучу ресурсов и сил "совершая подвиги" и доводя задачи ровно как было сказано, хоть и по ходу выполнения оказывалось, что это проблемно, сложно, и даже есть не сильно отличающиеся варианты в разы проще (но не они же обсуждались). Может иногда это и оправдано, но чаще - эти подвиги нафиг никому не нужны и не дают ничего хорошего.

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

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

Понедельник был день тяжелый

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

Плохого и откровенно тяжелого хватало, как и у всех, но об этом наверное ближе к итогам (байт на подписку, я знаю такое нравится), а пока больше о хорошем:
- Организационно в плане бизнеса план на следующий год сформировался, впереди наконец айти аккредитация и много чего еще. Часть процессов впрочем уже начато реализовываться. Дальше в постах буду освещать иногда и эти моменты, подписывайтесь, как говорится)
- У бизнеса появилось финпланирование и какие-то даже резервные и свободные деньги. Это действительно приятное чувство, когда в случае проблем, чтоб выплачивать зп тебе не надо лезть в свой личный карман. Настроены первые фонды, появляется первая аналитика. Спасибо Саше, разница в работе с операционным директором на лицо. Будет приятно настроить автоматизации уже для себя, когда видна польза это действительно другое дело
- В этом году открыл новое направление: провел несколько платных обучений, платное менторство, пока что бесплатные лекции. Еще не решил буду ли в следующем году продолжать и масштабировать это направление, но то, что в принципе не загнулось и что-то получилось - относится к хорошему
- Почти месяц хожу чипированный и доволен. Кто не в курсе, у меня диабет первого типа, контроль сахара в крови необходимая для меня штука. Кучу лет до этого для этого я прокалывал себе палец в среднем 3-5 раз в день и использовал тест-полоски, вроде ок, и цена расходников не так кусается. Теперь цена вопроса почти в 10 раз больше, но на себе убедился насколько же постоянный мониторинг круче. Долго все никак не собирался, да и не попробовав — разница кажется не такой уж и ощутимой и важной, а вот разница в цене ощутима сразу. Но один раз попробовав, вопросы к цене отпали, буду видимо ходить со встроенной в руку блямбой и радоваться, несмотря на затрачиваемые деньги

Так что если думаете стоит ли настраивать аналитики и мониторинги себе в проекты, рекомендация от меня — безусловно да, обращайтесь к нам разработаем все для этого:)

Преждевременная оптимизация

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

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

Вот моменты, которых советую придерживаться:
1) Постарайтесь посмотреть на готовые решения. Учитывая, что вы еще не профи, врядли вы делаете что-то принципиально новое, посмотрите готовые аналоги и решения:
- Причем как в глобальном плане, обратите внимание по какой логике работают похожие готовые сервисы, это поможет. Например если вы делаете интернет-магазин с множеством настраиваемых свойств товаров — посмотрите как управление ими устроено в готовых cms. Референсы даже с точки зрения пользователя — многое могут сказать про необходимую архитектуру.
- Так и в мелочах и отдельных фичах, посмотрите нет ли для вашей задачи готовой библиотеки, только обратите внимание на ее популярность и обновляемость. Если скачиваний много, проблемы регулярно закрываются, и пакет обновляется - скорее всего в нем продумано намного больше, чем вы сможете сделать с первого раза, а в мелочах можно допилить по надобности. Например если перед вами стоит задача настройки гибкой системы прав доступа пользователей, или даже добавление банальной механики сторис в приложение — это явно похоже на типичные задачи, к которым вероятно есть популярное готовое решение, поищите.

2) Если сделать оптимизацию после выполнения основной задачи, будет не дольше, чем делать ее сразу, и о ней прямо не просилось в задаче - не делайте ее. Запишите себе в список, сообщите о ней как о предложении своему руководителю или клиенту и оставьте до того как будет выполнена сама задача.

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

4) Дорогу осилит идущий, не пугайтесь незнакомого и объемного — пошагово и планомерно выполняйте подзадачи, выбирая в первую очередь простые и понятные решения. Документируйте свой код и учитесь формулировать отчеты о проблемах и обоснования выбранных решений — правильно заданный вопрос, уже половина ответа. А изящные решения, лучшие практики и идеальная архитектура придут с опытом, не волнуйтесь

Сапожник без сапог

Я делаю скрипты автоматизации кучу лет, от браузерных расширений в помощь менеджерам листающим доски объявлений, до автоматических бэкенд ботов или сложных erp систем. А вот внутренние решения в студии не приживались. Попытки написать скрипты чтоб какие-то циферки брались из одного место и красиво собирались и подсвечивались в другом конечно были и с точки зрения разработки вопросов не возникало. Однако по итогу не использовались, не несли ценности и быстро забрасывались. И на самом деле понятно почему. Нет смысла автоматизировать что-то, что вы без автоматизации не стали бы делать вручную. Нет смысла делать автоматизацию там, где нет собственно процесса. Конечно какие-то разовые скрипты вроде спарсить базу клиентов, настроить уведомления во время рекламы или чего-то такого писались и приносили пользу, но именно под разовые необходимости. А какой-либо автоматизации процессов не было, и проблема тут простая — просто не было самих процессов требующих автоматизации, в них не чувствовалось нужды.

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

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

С чем работаем еженедельно

Каждую неделю студия работает над приличным числом параллельных проектов, на прошлой 15 например. Объем и сложность со временем растут, держать все под контролем нелегко, но к счастью уже выстроилась система как делать это эффективно. Но об организации и процессы в другой раз. А сейчас о том, что обилие разноплановых проектов, дает кучу полезного опыта, баек и ситуаций, однако оформлять это дело в полноценные кейсы получается не так часто, как хотелось бы. Так что попробую формат попроще: еженедельный микрокейс из нашей постоянной текущей работы. Это будут технические детали, байки об управлении, а может какая-нибудь реализованная мелочь, посмотрим как получится, начнем

История с прошедшей недели: подходим к запуску клиентского проекта закрытой соцсеточки, в проекте много фич вроде многоуровневой рефералки, бонусов за активности и тд, но сегодня об отдельном виде входа, который используем впервые - мтс ID. От стандартного входа по смс отличие в том, что для абонентов мтс вход работает без вводов кода, с телефона подтверждаешь пришедший запрос на вход одной кнопкой - и на сайте происходит аутентификация, похожее есть например у сервисов яндекса. Звучит удобно, однако при входе по смс технически все максимально просто и понятно: вводишь на сайте код — он проверяется и, если все ок, фронтенд авторизуется и пользователь попадает куда надо, ввод кода тут — действие стартующее проверки. В новом же методе сайт сам должен пустить клиента когда тот что-то там подтвердил в телефоне. Нету действия на фронтенде, а значит сервер сам должен при наступлении несвязанного с сайтом события залогинить клиента и обновить фронтенд.

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

Очередной регулярный минирассказ с прошлой недели

Наконец добрался отписать что-то. Итак, история о недоделанных проектах: обратился клиент, с уже написанным проектом, где "почти все готово" и осталось добить пару моментов до запуска, с чем и надо собственно помочь. С прошлой командой доделать не получилось, какие-то проблемы, а запускаться нужно. Ситуация не редкая, не в первый раз сталкиваемся, для дооценки задач нужно развернуть то, что уже есть и проглядеть что и как работает. Начинаем развертку и становится ясно — гладко не пройдет, без тестовых данных сыплются ошибки, исправляешь одно — появляется следующее. Дампов и развернутого сервиса при этом нету, непонятно проблемы в коде или что-то исправляется инфраструктурой. Все конечно решаемо, но давать оценки в такой ситуации — не получится. Потому даже на развертку того, что есть приходится согласовывать рабочие часы, разворачивать проект на сервере клиента, и решать поочередно попадающиеся ошибки, чтоб можно было начать совместное тестирование с клиентом. Оказывается, что код после каких-то последних изменений не тестировался, уверенности в том насколько внутри еще неожиданностей — нет. При том визуально код неплох, сделано явно много, и не зная всех деталей разработки, изменений ТЗ, качества требований и деталей договоренностей говорить, что можно было сделать изначально лучше — я бы не стал. Скорее всего многие проблемы — следствие причин которые с наскоку не видны. Но и сервис в по сути нерабочем состоянии: кроме тех вещей о которых клиент был в курсе, выплывают ошибки по другим частям приложения, не работает то, что раньше вроде как работало, а какие то вещи просто не проверялись. Время и ресурсы на починку и доделку — труднооценимы.

Выходит ситуация: все, что мы можем — это поэтапная доделка сервиса по Т&M. То есть делаем док под список доделок, вносим туда, что уже найдено, и что находится по ходу продолжения тестирования и доработок. Прикидочно оцениваем сколько будет уходить на что, без гарантий, а только для понимания порядка цифр для возможности расставить приоритеты. Согласуем пачки работ например на 1-2 недели, оперативно держим в курсе статусов, сообщаем если где-то ориентиры оказываются неверны, предлагая варианты упрощения или замены. При том оплату получаем за фактические часы. Удобно, так как оценить проект с гарантией на полпути — было бы слишком рискованно, а клиент получает возможность хотя бы регулировать бюджет, получая прозрачные статусы и отчеты и в реальном времени принимая решения о том отказываться ли от каких-то частей проекта, или увеличивать бюджет доделки. Но и минусы для клиента тут очевидны: точный бюджет не получаешь, уверенности, что в имеющиеся деньги получишь то что представлял — тоже. Гарантий на это нет, а скорее всего (проект то не доделан не просто так) проблемы с доверием и гарантиями у клиента уже появились. И конечно возникает вопрос: так может выкинем все что есть, оценим с нуля и сделаем сразу красиво?

Мое мнение тут: если проект не был доведен до реального запуска, а с кодом можно хоть как-то работать — нужно добивать до запуска. Да уже с потерями, да всякое бывает, но это будет:
1) Дешевле. Возможно будут проблемы с техдолгом в дальнейшем — но решать их, когда гипотеза протестирована — намного лучше
2) Надежнее. Если проект как-то демонстрировался, и в нем с багами, но работало, и нуждается только в исправлениях хотя бы половина того, что вы хотели — доделка будет оптимальна. Далеко не факт, что при переделке до реального запуска анализ проекта с нуля станет лучше, чем первая попытка. Исправляя какие то ошибки первой версии можно наделать других, и что будет хуже без реального опыта — не понятно. Доделывать проекты до конца сложно, и раз уж да с проблемами, но к этой вехе уже подошли — лучше брать силы в кулак и добивать. Шанс на успех будет выше, чем пытаться сделать идеально с нуля. Другое дело переделки уже после запуска и работы— тут да, обсуждаемо
3) Быстрее. Даже обсуждать не стоит, да и проблемы с изначальной разработкой взялись не на пустом месте, то что в нее было вложено не стоит недооценивать, велик шанс так же ошибиться.

На прошлой неделе выкатили одну занятную штуку для постоянного клиента: учебную версию его же платформы. Идея проста, и я уверен, что это полезно и другим обладателям не коробочных разработок. Итак проблема: внутренняя разработка, чем бы это ни было, хоть erp, хоть crm, хоть как в нашем случае платформа регулирующая все от клиентских чатов до рейтинга сотрудников, в силу индивидуальности, имеет один минус — работе в ней новым сотрудникам придется обучаться с нуля. Документация пользователя для таких разработок не всегда полна, да и не решает вопрос полностью, а новые доработки в таком софте вносятся постоянно, так как живому бизнесу регулярно нужны изменения. Чаще всего сотрудников обучают "на пальцах": опытный работник показывает куда тыкать в боевых условиях, новичок запоминает. Эффективность — такая себе, редкие кейсы так сразу не показать, проверку обучения провести затруднительно, сотрудник тренируется на реальных данных — а это не безопасно.

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

Все про все занимает немного времени и денег, а на дистанции приносит кучу пользы, люблю функциональную простоту

Готовимся к нагрузке

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

До этого у нас уже были проблемы в пиковые моменты, так что на этот раз подготовившись уже с опытом, получилось успешно выдержать нагрузки в разы превосходящие прошлые. Базовые моменты которые можно сделать всем если вдруг у вас ожидается ажиотаж:
✅ Настройте мониторинги и уведомления, о проблемах и падениях всегда лучше узнавать автоматически.
✅ Проверьте явные моменты: долгие запросы в бд, наличие необходимых индексов, нет ли запросов в циклах, и нельзя ли где то запрашивать меньше данных. Первое узкое место это всегда база данных, так что сосредоточьтесь на проверке запросов к ней.
✅ Проверьте настройки инфраструктуры: на любом ее уровне там могут быть моменты требующие внимания, не используются ли случайно дефолтные настройки mysql у вас на проде? а нормальные ли таймауты в livenessProbe сервисов в кубике? вопросов тут много, потому оптимизация под нагрузки всегда сложный момент, но пробежавшись и улучшив хотя бы основные моменты вы точно сделаете лучше.
✅ Настройте кэширование информации со сложных запросов в бд, даже кэш на 1 минуту, в случае большой нагрузки даст громадный прирост к отказоустойчивости. Увеличьте время жизни кэша везде где это возможно, чем реже запрашивается информация из бд тем лучше.
✅ При возможности можно рассмотреть шардирование бд или распределение запросов чтения по репликам, хоть и врядли это уместно для мелких проектов.
✅ Не забывайте о фронтенде, убедитесь что он развернут по всем рекомендацим для продакшена, нет никаких ограничивающих факторов, например в случае фронтенда c ssr на ноде, что он поднят в несколько процессов через кубер/pm2.
✅ Если есть возможность проведите стресс-тесты (gatling в помощь), чтобы выявить и успеть исправить явные проблемы, чаще всего если нет проблем с обращениями к бд могут быть проблемы в настройке инфраструктуры, выявить и исправить их без тестов - проблематично.
✅ При возможности заранее увеличьте ресурсы, увеличивать ресурсы уже под нагрузкой будет очень неуместно, лучше выделить время в нерабочие часы. Даже автомасштабирование не работает мгновенно и можно накопить очередь запросов, так что для ожидаемых пиков лучше сделать это заранее.
✅ Подготовьте план на случай плохого сценария. В лучшем случае это автомасштабирование и распределение нагрузки лоад балансером, но для мелких проектов чаще всего настроить облачные ресурсы и само приложение готовым к этому бывает невозможно. Но даже для сервисов на классических простеньких серверах, можно придумать "план б" с отключением неприоритетных модулей, включением статических заглушек, и прочих возможностей.
✅ Ну и не совсем к вопросу нагрузок, но всегда уместно, у вас же настроены бэкапы?)

Безопасность и взломы

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

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

Как? Взлом это автоматический процесс, чаще всего работают атаки через набор уязвимых мест:
- Части кода популярных cms и систем. Сайты неоправданно писать с нуля, большинство из них написано на готовых cms состоящих из большого числа готовых модулей. К тому же всегда дополнительно устанавливаются разные готовые пакеты от сторонних разработчиков. Где-нибудь да проскочит уязвимость. А сайтов с этой уязвимостью выйдет сразу много.
- Банальный подбор паролей на все начиная с админки, заканчивая ssh доступом к серверу. Если глянуть в логи доступа сервера, то даже у самого мелкого сайта увидим и попытки ботов залогиниться в админку и кучу запросов напрямую к самому ssh. Так что использование небезопасных паролей чревато даже если кажется, что атаковать вас никому не надо, ботам все сгодится
- Человеческий фактор, фишинг, социнженерия. К этому методу относится все рассчитаное на неосторожность людей. От автоматически генерируемых сайтов похожих на вашу админку и рассылок с ними на почту, до утечек через старых сотрудников (привет, Петь, слушай у нас затерялись доступы, а Федору Иванычу нужно прайс поменять, скинь пожалуйста что у тебя оставалось). Методы и так всегда были популярны, а сейчас с развитием ии еще больше масштабируемы и автоматизируемы.

Можно ли защититься? Полностью — нет. Направлений атак слишком много, аудит безопасности всех модулей (сторонних и модулей ядра) невозможен, да и все равно остаются методы от которых технически не защититься. Но значительно уменьшить шансы на взлом и уменьшить возможные последствия — вполне реально и нужно делать.
- Регулярно обновляться. Версии основной cms, всех модулей и пакетов, софта на сервере. Да это тратит время и деньги и иногда требует адаптации, но точно увеличит стабильность
- Никаких легких или одинаковых паролей, в идеале еще и регулярно их менять раз в какой то период.
- Не открываем наружу ничего лишнего, ставим везде базовые инструменты защиты от брутфорса, закрываем стандартные порты
- Проводим обучения людей, следим за сменой доступов и минимизацией количества носителей критической инфы
- Ну и конечно настраиваем бэкапы во внешнем хранилище, полная защита невозможна, а потому пусть всегда будет план Б.

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

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

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

Короче подойдет всем, от только интересующихся, до уже практикующих. Но нужно понять количество и уровень желающих, чтоб разделить по группам удобного размера и все организовать. Так что, если вам было бы интересно — плюсаните в комменты, свяжусь уточню по уровню и интересующим вопросам и все организуем. Участие бесплатное, формат (оффлайн/онлайн) определится позже

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

Айти это сфера где "хочешь жить — умей вертеться", навыки в адаптации и обучении здесь ценятся всегда и всеми выше всего. Ситуации, технологии и условия меняются постоянно, за всем нужно успевать и решать проблемы. Потому многие вещи необходимость в которых в других сферах выясняется лишь при проблемах, у нас уже давно — норма жизни. Те же самые процессы обучения, внутренних наставничеств, передачи знаний. Для любой мало мальски окрепшей команды в айти известно понятие bus factor и понятно, что нужны процессы при которых сотрудника на проекте можно подменить, переключить, нужны процессы ввода в проекты новых людей, процессы их подготовки.

Необходимость же подобных вещей для например производства видимо не всем так очевидна, и ее приходится начинать регулировать чуть ли не на гос уровне регламентируя систему наставничеств и ее фиксирования в трудовых отношениях. Какая-то часть коллег руководителей из других сфер выдвинуло следующую мысль: нам в айти важность этих изменений не понять, так как у нас все на самом деле просто и сложностей на самом деле нет, вот и все. Мол, когда санкции вводились, производствам пришлось спецов из италии контрабандой везти и проблем огого было, а айти отделы все взломали или переключились на аналоги за две недели. Мол когда слесарь 6го разряда со станка по мобилизации улетает, его фиг заменишь, а у нас со стороны посмотришь и кажется кнопочки то нажимать любой дурак может. Я же лично считаю что мы как сфера адаптировались быстрее не потому что нам проще, а потому, что у нас такая необходимость была всю дорогу, и мы просто давно привыкли решать эти проблемы, знаем про необходимость настройки процессов на случай чего, и тренируемся меньше зависеть от воли случая. Но возможно я все же чего-то не понимаю и обучение сотрудников производств в разы сложнее обучения среднего айти специалиста? есть мнения?

Синдром менеджера

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

И вот самый главный навык менеджера это стойко держать это давление. Факторов много, но новички точно будут получать море критики со всех сторон, и естественным желанием будет защищаться и придумывать объяснения "почему не получилось". Это естественная реакция, но неверная, ведь главное правило управленца — всегда можно лучше. И в этом парадокс, так как вечный спрос с себя тоже давит. Хорошему менеджеру трудно меньше спрашивать с себя, а потому уйти в выгорание — вопрос времени. Вот так, если ты менеджер ты всё равно выгоришь, либо раньше не готовый к прямому давлению, либо позже не успевая восстанавливать ресурсы, но выгоришь 100%. Избежать этого получится разве что если от тебя на самом деле не так уж много зависит, и твоя роль действительно улыбаться на митингах и спрашивать людей как у них дела, и то не уверен. Так что действительно неплохой термин придумали, одобряю. Другое дело, что подобное это стадия роста, и да рост это больно, но необходимо. Так что, если у вас подобные трудности и вам станет легче — вы не одни, у всех так, не волнуйтесь все пройдет

Недели идут плотнее и плотнее, проекты пилятся, но новые задачи прилетают даже быстрее, чем сдаем текущие. 

Дел много, поэтому усиливаем команду и ищем новые руки и головы https://studio-alt.ru/blog/myi-snova-ishhem-razrabotchikov пишите.

Ну и раз уже пошло такое дело, порассуждаем заодно о происходящих изменениях в сфере. Когда я начинал, уровень входа в условную веб-разработку был ниже некуда. Даже нормально сверстать статичные веб-сайтики могло не так много народу, и вполне себе ценились не то что фронтендеры, а прямо верстальщики (при том самих инструментов верстки было меньше и были они проще). Сейчас — версткой не удивить никого, более того, кроме того что появилось куча альтернатив (вроде как собрать себе сайт самому на тильде не зная ничего технического), так с развитием ИИ задачи верстки вообще перестали по уму стоить хоть что-то. Нормально сформулированные промпты выдают отличные результаты, скорость выросла в разы, а учить и дотягивать народ "начинающий с нуля" становится все менее перспективным занятием. Похожие процессы сейчас и в типовых задачах программирования. По сути хороший менеджер (тот что норм умеет в декомпозицию и формулировки задач) вооружившись каким нить claude уже вполне себе заменяет себе руки джуна. Да пока с нюансами, но судя по скорости изменений — ненадолго. Так что выпускникам следующих годов и начинающим программистам все меньше стоит рассчитывать на "механические" навыки, и все больше становятся важны критическое и системное мышление, навыки декомпозиции задач, проектирования систем, внедрения изменений, работы с рисками и тд. Все важнее например будет становиться математика и логика, просто как тренажеры для мозгов, но уже не чтобы выделяться умением решать "особенные задачи", а как база, чтобы иметь возможность конкурировать с бездушными машинами, а точнее верно и на пользу дела ими пользоваться. 

Хорошие новости в том, что в принципе в этом нет ничего нового: умение видеть задачи в целом, системно разбираться в незнакомом, уметь выражать мысли, коммуницировать, ставить четкие метрики результатов и видеть те места на которые стоит обращать внимание, а где в целом вопрос стоит лишь в механических действиях — ценились абсолютно всегда. Разработчики с этими качествами ценились всегда, и спрос на них никуда не денется — будут нарасхват. А вот "механические" навыки потихоньку будут падать в спросе. Специализации тоже станет поменьше, много ли смысла в разрабе с глубокой привязкой к одной технологии например, если во всех llm эти знания вшиты ничуть не хуже, а хороший архитектор сможет с их помощью решать задачи без привязки к конкретному фреймворку? Конечно такое будущее еще не наступило, но тенденция уже заметна, требования к джунам — везде повышаются, стажеры "набиратели кода" все меньше кому нужны, увеличиваются требования к умениям аналитики и пониманию сути бизнес-задач для рядовых исполнителей, и эти процессы будут усиливаться. Будет интересно посмотреть к чему все придет, и как именно изменятся процессы разработки, но то, что новичкам нужно адаптироваться уже сейчас это точно. Так что тренируйте мозги и гибкое мышление, пригодится:)

На прошлой неделе стартовал телепроект по масштабированию бизнесов, в который я внезапно для себя вписался и даже прошел кастинг. Поделюсь немного ощущениями по итогам пары съемок и работы внутри:

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

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

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


В целом опыт определенно новый и интересный, и я надеюсь, что будет полезный. Выпуски выходят по субботам, первый был, ссылка в вк https://vk.com/wall13699865_286

Всем привет, дата встречи для кодеров определена

3 июня в 18:00. Спасская, 15. Вход в музей шоколада «Криолло»

выступят наши разработчики и я сам, упор в основном сделаем на начинающих разработчиков, но какие-то моменты думаю должны быть интересны многим

Темы:
* «Как не совершить базовые ошибки в разработке веб-приложений: немного о безопасности и о чем стоит подумать если вы начинающий разработчик»
* «CI/CD что это и зачем нужно»
* «Проектирование и разработка приложений. Как подходить к разбору сложных задач»

Зарегистрируйтесь пожалуйста, чтобы мы прикидывали финальное число людей https://forms.gle/sPHQHZSAVGJeNdhX7