Если вы сегодня увидели похожую ошибку при попытке пуша в GitHub, то вы не одиноки.
GitHub, случайно, хост ключ обновили сегодня.

Надо перегенерить ключи и добавить хост потом в разрешённые — ssh-keygen -R github.com

https://github.blog/2023-03-23-we-updated-our-rsa-ssh-host-key/

Анонс новых митапов на последнем @almaty_js

Ребята, я пока что тестирую, донатить не обязательно.

Но спасибо всем, кто уже совершил пожертвование 🤝

Я считаю, что если я прошу пожертвования, то я должен выдавать контент стабильно и качественно, поэтому работа ещё в процессе.

Вчера вышел эпизод Kolesa Podcast записанный с моим участием.

Для меня это был первый опыт записи в подкасте и мне очень понравилось то, как легко и быстро у нас прошла запись этого эпизода.
Старался не торопиться, чтобы люди что-то поняли 😀
Этот эпизод больше направлен на людей, которые только хотят войти в IT и на ранних этапах своей карьеры, но не смотря на это есть моменты, когда я уходил в исторический обзор и вспоминал про времена jQuery и становление фронтенда в Казахстане.

Спасибо Кристине Абдраимовой и Вадиму Манченко за возможность поговорить на такую интересную тему.
Отдельная благодарность моим подписчикам и друзьям за поддержку в соц.сетях и на YouTube.

Смотрите эпизод по ссылке — https://www.youtube.com/watch?v=Fded-9B6Pwg

Аудиоверсии доступны в Apple Podcast и Яндекс.Музыке.

💡 Про бремя знаний

За последние 10 лет я сделал разные пет/фан-проекты:

1. Расширения iNikolayev и kNurtas, которые меняют картинки на странице на фотографии Игоря Николаева или Кайрата Нуртаса;
2. Telegram бот для проверки баланса на карточке ONAY (отключен, т.к. разработчики закрыли доступ к API на проверку);
3. Telegram бот для быстрого (инлайн) перевода с казахской кириллицы на казахскую латиницу;
4. Telegram бот для Almaty Bike (пока что не работает, т.к. я не активный пользователь системы);
5. Telegram канал с парсингом новых казахстанских доменов;
6. Твиттер бот с курсом тенге по данным Нацбанка;

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

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

Мне важно было получить моментальный фидбек от пользователей или просто удовольствие от разработки, изучая что-то новое (например, Geospatial Queries запросы в Almaty Bike боте, чтобы достать ближайшие к пользователю станции).

Сейчас у меня в голове крутятся несколько проектов, разной степени проработанности и сложности, но меня что-то останавливает от их реализации.

И, как мне кажется, это то, что я называю «бремя знаний» — мне мешают мои же знания, которые я получил за последние 11 лет о том, как разрабатывать и запускать продукты.

Я насмотрелся «хороших» подходов к разработке и теперь не могу начать делать что-то, пока у меня не будет условной доски в JIRA, где будут все задачки. Дизайны не будут лежать в Figma. CI/CD настроено и отлажено.

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

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

📩 Виды резюме, которые я ненавижу (у разработчиков)

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

С одной стороны, это экономило время, т.к. до собеседований доходили кандидаты ± подходящие для собеседования, с другой стороны — мне приходилось смотреть на кучу непонятных, пустых или нерелевантных резюме, которые каким-то образом попадали в выборку от наших рекрутёров. С теми рекрутёрами, что проводили в банке достаточно много времени, у меня получалось наладить работу так, что ко мне попадали только релевантные резюме, но с новыми рекрутёрами всегда приходилось проходить этап, когда присылают резюме не подходящих кандидатов, ещё и в формате doc/docx 😀

Я выделил следующие виды резюме, которые мне не нравятся:

Резюме для всего

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

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

Классическая ситуация: у кандидата указан опыт в 10 лет, из них 1 год опыта в IT и 9 лет опыта мерчендайзером.

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

Резюме без информации

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

Компания ABC — Разработчик — 04.2020 - 04.2023

И добить эту ситуацию может описание для позиции: «Писал код»

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

Резюме, где очень много информации

Один раз мне попалось резюме, где кандидат перечислил задачи из JIRA, которые он делал. Прям так и написал:

JIRA-1234 — Кнопка «Войти» на странице авторизации
JIRA-1235 — Кнопка «Выйти» в меню

И так далее.

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

Идеальное резюме

Для меня, идеальное резюме — это то, которое даёт понять, что за кандидат стоит за ним.

Я выделяю следующие важные пункты резюме:

1. Актуальный опыт работы — не забывайте отправлять самое свежее резюме рекрутёру.
2. Технологический стэк по последним позициями — если наша вакансия срочная, то нам важно найти человека, который быстро поймёт или уже работал с нашим стэком.
3. Нормальное описание вашей работы — какие цели были выполнены, какие фичи (крупные) были реализованы, цифры (уменьшил размер бандла на 200кб) очень хорошо усиливают резюме.
4. Nice to have: короткий блок «Обо мне» и ссылка на ваш GitHub, где есть что-то. Если у вас пустой GitHub или вы вообще не активны на нём, то лучше не тратить время и не добавлять ссылку на него.

И обязательно проверьте резюме на наличие ошибок (как минимум, грамматических).

Ваше резюме — это ваше лицо.

Картинка в слайде передаёт моё состояние.

Сегодня на CodeFest пришёл послушать Нам Максима с докладом про переход проектов из аутсорса в инхаус.

Совсем скоро я вернусь с полезными постами в канал и сделаю несколько объявлений, но пока есть такая новость:

12 октября, силами AlmatyJS и Altel Digital, пройдет Hacktoberfest 2023 Central Asia, часть глобальной инициативы DigitalOcean, ILLA Cloud и Appwrite по распространению Open Source.

Я большой фанат открытого кода и для меня всегда было приятно, когда у кандидатов на собеседованиях был хоть какой-нибудь вклад в OSS проекты, поэтому я, впервые за долгое время, решил выступить с докладом «Как перестать бояться и сделать первый PR».

До встречи на митапе!

https://events.mlh.io/events/10428-hacktoberfest-2023-central-asia-almaty

Сегодня на сцене Hacktober Fest Никита Баев.
Никита - руководитель центра компетенций Front в Береке банк, co-founder AlmatyJS, founder Nikita paper company и разработчик с опытом более 10 лет, выступает с докладом «Как не бояться и сделать свой первый PR»

🥷🏼 Список вещей, которые должен знать Senior

Недавно набрёл на статью Камиля Фурнье о вещах, которые должен уметь Senior разработчик кроме разработки.

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

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

Я выбрал несколько пунктов, с которыми часто сталкиваюсь в работе:

1. How to take negative feedback gracefully

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

2. How to tell someone they’re wrong without making them feel ashamed

Комьюнити разработчиков, зачастую, очень душное и токсичное из-за чего может сложиться впечатление, что “нормально” вести себя так и в рабочих коммуникациях и это даже работает в некоторых компаниях/командах.

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

3. How to help someone get promoted

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

4. How to communicate project status to stakeholders

И не только стейкхолдерам 🥩. Зачастую разработчики, даже опытные, не могут проактивно и в полной мере сообщить статус проекта, с какими трудностями сталкиваются и когда будет релиз. Держите в курсе и будьте открытыми, вам за это платят деньги.


А что для вас является признаком хорошего Senior разработчика?

Остальные пункты по ссылке — https://www.elidedbranches.com/2021/06/an-incomplete-list-of-skills-senior.html (Web Archive)

Третье выступление с нашей конференции Hacktoberfest Central Asia!

Никита Баев, Руководитель Центра Компетенций в Bereke Bank, рассказал о том, как перестать бояться и сделать первый PR. Это, можно сказать, пошаговая инструкция для начинающих и не только о том, как начать контрибьютить в Open Source. Плюсы, минусы, подводные камни - про все это в выступлении Никиты.

Смотреть

🙋🏼 Всем привет, на связи Никита.

Чтобы быть к вам ближе и давать более релевантный и полезный контент — хотелось бы узнать, что вам интересно и какой контент вы бы хотели видеть в этом канале.

Ответьте на опрос выше, можно выбирать несколько тем сразу.
Если вы не нашли нужную тему или у вас есть другие предложения по работе, то можете написать их в этой форме.

🎄 2023 заканчивается

Так как это мой “экспертный” канал, то хочется подвести мои “профессиональные” итоги года.

График коммитов на GitHub очень ярко показывает самое главное изменение в этом году — впервые в жизни я перешёл на менеджерскую роль в «Bereke Bank», чтобы развивать Центр Компетенций по разработке фронтальных систем.

Это большой вызов для меня, т.к. последние 11 лет я большую часть времени уделял только разработке и работа с людьми занимала малый процент моей работы, а теперь наличие свободных слотов в календаре удивляет меня 😁

Было печально покидать Smarter Contact в начале третьего квартала, но я рад тому, что мне довелось поработать с таким комплексным продуктом и прекрасной командой. Безусловно, это уникальный опыт работы для меня.

Между делом помог команде abr tech сделать важные улучшения продукта abr+ и вывести бронирование в ресторанах (которое я просил сделать ещё в 2020 году) на самые загруженные рестораны сети.

Это было непростой год, полный перемен и новых вызовов. Смотрим в светлое будущее в 2024 году и никогда не останавливаемся.

Всех с наступающим Новым годом!

🏦 Откуда берётся ваша зарплата

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

Знаете ли вы, сколько денег принесла форма, которую вы разработали в прошлом месяце? Насколько увеличились или уменьшились регистрации, когда вы поменяли цвет кнопки «Регистрация»?

По моему опыту, разработчик чаще всего не знает ответа на эти вопросы, потому что с его точки зрения это не имеет никакого значения. Он получает зарплату за то, что работает, и не имеет прямой зависимости или влияния на доход компании.

Пока был в отпуске решил, разобрать почту и наткнулся на статью от Swizec Teller с размышлениями на тему, откуда формируется бюджет на оплату зарплат разработчикам.

Автор зафиксировал три бюджета: продажи/маркетинг, R&D и обслуживание (maintenance).

Так как среди подписчиков достаточно мало интеграторов и деврелов, пока что опущу обсуждение первого бюджета.

Но можно сказать, что вам повезло, если вы получаете зарплату из R&D бюджета, ведь это означает, что для компании вы — это инвестиция. Каждый день вы решаете вопросы развития продукта, придумываете очередную “прорывную” фичу или изучаете новую технологию, которая поможет сократить время загрузки продукта.

Результаты вашей работы могут быть видны через пару месяцев, если не больший промежуток времени. К слову, поэтому работодатели и не любят рассматривать резюме *“попрыгунчиков”*, которые меняют работу каждые полгода-год, если не чаще. Разработчик мог даже не увидеть результат своей работы и то, как она повлияла на продукт, но уже ищет новую работу.

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

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

Багфиксинг проектов, где в коде есть jQuery или Backbone, поддержка приложения на Objective-C, чтобы оно могло работать с обновлённым API без изменения кодовой базы, редактирование HTML файлов напрямую через FTP, т.к. исходники были утеряны или не переданы разработчиками.

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

Стабильность систем — это то, что нужно компании, потому что тогда можно сэкономить на обслуживании и потратить больше денег на R&D, но код устаревает, браузеры и телефоны обновляются, сервера перестают поддерживать и т.д.

Работу по обслуживанию легче оценить, можно даже заключить SLA (соглашение об уровне обслуживания) и замерять, насколько эффективно и качественно выполняется работа по обслуживанию и решать, сколько платить сотрудникам.

Это важная работа, но для компании это никогда не будет приоритетной работой, так как она не приносит деньги напрямую.

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

@drugoi_dev

📚 Certified SAFe 6 DevOps Practitioner

В декабре проходил обучение по DevOps практикам в рамках Agile SAFe и как результат обучения сдал экзамен Certified SAFe 6 DevOps Practitioner.

В выделенных командах обсуждали текущее состояние доставки ценностей до клиентов, построили DevOps радар и подумали, как можно улучшить и ускорить процессы.

Это не только про kubernetes, ansible и другие девопсерские слова, большую часть времени мы уделили именно внедрению практик built-in quality, улучшению потока ценности и сокращению flow time.

🤛🏼 Конфликт в команде нужен, но какой?

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

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

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

Деструктивный конфликт, напротив, подрывает доверие и сплоченность команды.

Конфликт — это не обязательно открытая конфронтация отдельных участников. Лично для меня конфликт может заключаться и в том, что член или члены команды ведут себя токсично, создавая нездоровую атмосферу в команде. Что ведёт к тому, что новые сотрудники не могут влиться в команду и уходят.

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

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

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

Дополнительно рекомендую прочитать статью от Максима Горбатюка (@mgorbatyuk_dev), которую он написал пару лет назад, где очень глубоко рассмотрен вопрос конфликта в IT — https://mgorbatyuk.dev/blog/management/2022-05-08-conflicts-in-it/

🧓🏼 Олды не вспомнят, ньюфаги не поймут

На глаза попалась заметка с заголовком Only 90s Web Developers Remember This

Забавно, что не смотря на то, что я был очень далёк от разработки в 90-х, но многие из техник, которые перечислены я хорошо помню и даже использовал, когда начинал писать код в 10-х годах.

К сожалению или счастью, такие вещи, как DHTML и пиксельные шрифты прошли мимо меня, но я очень хорошо помню:

<marquee> — для создания эффекта «бегущей строки».

1x1.gif — для создания отступов и сдвига других элементов на странице до появления этих ваших flexbox и grid.

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

Самая грустная потеря из интернета прошлого — «кнопки» в футере (да и не только) страницы с различными каунтерами. Кто-то из вас даже вспомнит zero.kz.

Остальные древние технологии по ссылке — https://zachholman.com/posts/only-90s-developers/

@drugoi_dev

📅 Дайджест за Январь 2024

Начал новую практику для себя: собираю интересный контент за месяц и публикую в виде некоего дайджеста.
Формат и наполнение будут меняться.

https://drugoi.dev/digests/2024-01/

@drugoi_dev

⚡️ AlmatyJS Light #4 — Call For Papers

Всем привет!

Мы готовим новый AlmatyJS Light и хотим видеть вас в числе наших спикеров. Будет здорово, если вы расскажете о теме, которая вас заинтересовала, или поделились своей последней болью в разработке. Ждем ваших идей!

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

→ Заполняйте форму и делитесь знаниями с сообществом: https://forms.gle/NrYUHRcBSRGrbfNPA

→ Ограничение по времени доклада: 10 минут + 10 минут на вопросы;

→ Дедлайн подачи заявок: 01.03.2024 (1 марта 2024);

#анонсы

@almaty_js