
Калининград
8 постов
Рубрика: Занимательные истории с Habr
Интересные факты и подводные в работе тимлида.
Уволился с позиции тимлида и снова стал разработчиком
• Автор статьи ушел с позиции тимлида и стал старшим фронтенд-разработчиком.
• Роль тимлида интересна, но имеет много недостатков, включая повышенную нагрузку и низкую прибавку к зп.
• Разработчик имеет больше свободы и меньше ответственности, чем тимлид.
• Оценка результатов работы на руководящих позициях сложнее, чем на исполнительных.
• Карьера в IT-индустрии может быть сложной и непредсказуемой.
• Автор считает, что тимлидство не всегда приводит к карьерному росту и повышению.
• Разработчик может достичь высоких руководящих позиций, если будет стремиться к этому.
• Важно выбирать путь, который соответствует вашим интересам и возможностям.
Немыкин.Продакшн - Java/Kotlin developer
#habr
А нормально, что у меня появляется желание питонистом стать?
Буквально в 10-15 строчек можно столько штук классных делать, невероятно.
Понятно, что это больше баловство и серьезный проект так не напишешь, но простота тем не менее присутствует.
Я за пару кликов и 30 строчек смог сделать mvp голосового помощника. Боюсь представить чего бы стоило мне такое на Java.
Не буду говорить, что Python сила, пока познаю только базу и строгая типизация с явным ООП для меня остаются мощью, но мысли такие и про змеиный проскальзывают.
Абсолютно уверен в том, что для входа в программирование и изучение базы это лучший язык, при этом долго новичкам на нем засиживаться не стоит ибо простота и «сахар» обленивают.
Всем добра и улыбки 🤙🏼
Python: язык, который слишком удобный, чтобы быть реальным
🐍 Python — это как волшебный чайник: ты просто говоришь, что хочешь, и оно происходит. Ну, почти. Иногда он всё-таки выбрасывает IndentationError, чтобы напомнить, кто тут хозяин.
Вот ты пишешь что-то вроде:
numbers = [x**2 for x in range(10) if x % 2 == 0]
И чувствуешь себя мастером магии, хотя по факту ты просто сгенерировал список. В любом другом языке ты бы уже завёл три переменные и написал три цикла, но Python говорит: «Спокойно, бро, я всё сделаю за тебя».
🧐 Почему Python — это круто?
1. Синтаксический сахар везде.
Хочешь однострочник? Пожалуйста. Хочешь кучу встроенных функций? Лови len(), sum(), map(), filter() — просто накидывай их, как топпинги на пиццу.
2. Код читается как английский.
— Что делает if x in list:?
— Ну… проверяет, есть ли x в списке.
— А дальше?
— Дальше ты гений.
3. Python работает без лишних вопросов.
— Слушай, а что будет, если я сложу строку и число?
— Python: «Не надо так».
— А если очень надо?
— Python: «str() и всё будет нормально, но это на твоей совести».
4. Код работает сразу… почти.
Python — это как тот друг, который обещает помочь с переездом: вроде всё сделано, но потом оказывается, что что-то не так.
🙃 Почему Python абсурдный?
1. Перфоманс? Какой перфоманс?
Пиши, конечно, хоть машинное обучение, хоть API, но помни, что внутри всё работает так же медленно, как ты в понедельник утром.
2. Динамическая типизация.
Ты живёшь в мире, где переменная x может быть числом, строкой, списком или вообще чем-то странным, и это нормально. До тех пор, пока не становится ненормально.
3. "Мы это упростили".
Всё, что слишком просто, обречено ломаться в самых сложных местах. Твоя модель данных может перестать работать, потому что Python внезапно решил, что float('NaN') != float('NaN').
😍 Как его любить?
Python — это как тот ребёнок, которого ты обожаешь, но иногда он приносит домой жабу и говорит: «Смотри, это мой новый друг!» И ты такой: «Окей, это странно, но ты всё ещё лучший».
Он помогает тебе писать быстро, разворачивать легко, а баги исправлять… ну, через пару стаканов кофе.
Мораль?
Python — это язык, где ты можешь чувствовать себя богом, но реальность напомнит, что всё это просто сахар. А сахар, как известно, вреден, если его слишком много.
Так что наслаждайся, но не забывай иногда смотреть на низкоуровневый код, чтобы не забыть, как работает мир.
Немыкин.Продакшн - Java/Kotlin developer
Подводить итоги года? Ставить цели? Зачем, если есть кофе и хаос?
🧑🎓 Все вокруг подводили итоги года, а я вспомнил об этом только сейчас. Кто-то запустил стартап, кто-то научился медитировать, а кто-то наконец-то разобрал балкон. А ты такой сидишь, листаешь эти посты и думаешь: «Ну, а я, видимо, просто жил. И то неплохо справился».
Да, я сам многому научился, многое преодолел, но это просто путь.
Ну а зачем, серьёзно? Вот ты подведёшь итоги. Что дальше? Выложишь в Инсту, чтобы похвастаться, как ты прочитал три книги и полгода ходил в зал? И что, лайки дадут сил? Спойлер: нет, ты всё равно забудешь это через неделю, потому что наступает январь, и всё снова идёт кувырком. Если и подводить что-то, только сухие и реальные цифры, дабы видеть динамику и отсутствие деградации.
😐 Почему подводить итоги бессмысленно?
1. Мир — хаос.
Ты мог бы планировать путешествие в Италию, а потом оказалось, что твой год — это бесконечные митинги и доставочная пицца на диване.
2. Цели — это просто стрессы под прикрытием.
Ты пишешь: «Стану продуктивным в 2025!», а потом в феврале внезапно обнаруживаешь себя с ноутбуком на кухне, обедающего дошиком и смотрящего в стену.
3. Мы живём ради мемов.
Если год не принёс ни одного хорошего мема, зачем вообще что-то считать?
🤔 Что делать вместо этого?
1. Прими хаос.
Слушай, ты уже выжил в 2024. Это достижение! Никаких планов. Просто кайфуй от того, что ты здесь и сейчас.
2. Цели? Это уже слишком.
Просто скажи себе: «Я сделаю хоть что-то полезное». Например, поменяю лампочку в коридоре, которая не горит с 2020.
3. Вместо итогов — хорошие моменты.
Вспомни смешную шутку, вкусный бургер, который ты съел, или тот день, когда твой код заработал с первого раза. Вот это реально важно.
🏖️ Так что не заморачивайся. Итоги года? Пусть подводят те, у кого слишком много времени. Цели? Пиши их на салфетке в кафе — вдруг пригодится, чтобы вытереть стол.
Живи, как будто завтра продакшн упадёт. Просто будь собой, и не забудь: хаос — это нормально.
Немыкин.Продакшн - Java/Kotlin developer
🧑🎓 В октябре я посетил митап для продуктовых бэкенд-разработчиков, посвященный интеграциям систем.
Интеграция систем представляет собой сложную задачу, сопряженную с различными трудностями: совместимостью, коммуникациями, процессами и многими другими аспектами. На этом мероприятии мы поделились интересными кейсами, накопленными в рамках Яндекс Go, а также получили ценные советы от экспертов, как избежать ошибок в своих проектах.
Митап включал в себя воркшоп и три доклада.
🏋️♀️ Практический воркшоп «Игра в стартап: баланс скорости и качества»
Практический воркшоп проводил Олег Ермаков — руководитель разработки Go New Ventures. В ходе этого мероприятия прошли через ключевые проблемы и стадии развития проекта: поиск ниши, расширение продукта и масштабирование команды. Тренировались в решении сложных кейсов и обсуждали, как технические решения влияют на развитие бизнеса.
Поскольку у меня уже есть опыт участия в стартапе, а также учитывая, что воркшоп проходил параллельно с лекциями, я не смог посетить его лично.
🚕 Первый доклад «Для чего использовать BDUI при интеграции сервисов: опыт Межгорода в SuperApp Яндекс GO»
Первым на повестке дня был доклад Вадима Белотицкого, руководителя разработки в Межгороде Яндекс Такси. Он поделился своим опытом интеграции внутреннего стартапа с родительским продуктом, рассказав, где можно развиваться независимо, а где, наоборот, стоит держаться ближе.
Вадим объяснил, что BDUI — это backend-driven user interface. Это означает, что основные компоненты пользовательского интерфейса описаны на бэкенде, часто на Kotlin-скриптах.
Такой подход обеспечивает гибкость и позволяет встраивать SuperApps. Приложение Яндекс Go состоит из множества подобных супер-приложений, таких как Такси, Еда и Маркет, внутри которых встроены MiniApps. Например, в Такси вы можете выбрать самокат или каршеринг.
Кроме того, этот подход позволяет адаптировать интерфейс в зависимости от геолокации пользователя. Если вы замечали, в разных городах отображаются разные приложения. Также он позволяет выпускать обновления интерфейса без обновления всего приложения через AppStore или GooglePlay.
Подробнее об опыте внедрения BDUI можно прочитать по ссылке.
🚕 Доклад «Интеграция с партнерами: как мы запустились в 100 городах, не размещая в них свои самокаты»
Второй доклад был посвящена интеграции с партнерами. Рома Детинин, руководитель группы разработки бэкенда клиентского продукта в Яндекс Самокатах, рассказал о трех внешних интеграциях, которые использовались в проекте. Главными из них были Urent и Велобайк 2.0.
Изначально для интеграции с каждым сервисом создавались сервисы-прослойки, их еще называют адаптеры. Такой подход мог приводить к неочевидным ошибкам, сложности интеграции двух разных систем и затратам человеко-часов. Однако для MVP такой подход был вполне обоснован, чтобы протестировать гипотезу и в случае успешных тестов оптимизировать или использовать более оптимальный подход.
В Самокатах выбрали второй вариант и разработали универсализированный протокол интеграции с внешними системами. Это позволило отказаться от адаптеров и обрабатывать внешние события в одном сервисе. Хотя протокол не был упомянут, насколько мне известно, в Яндекс любят использовать gRPC.
Доклад Интеграция систем с master-master взаимодействием
Заключительное слово было за Костей Князевым, техлидом команды серверной разработки маркетплейса лизинга в Яндекс Pro. Он рассказал о интеграции систем с master-master взаимодействием.
Мы рассмотрели тему интеграций, когда сущности в двух системах могут изменяться независимо, при этом данные должны быть синхронизированы. Обсудили проблемы, которые возникают в таких интеграциях.
Master-master взаимодействие — это подход, при котором каждая система или узел в распределённой архитектуре может одновременно быть и источником, и получателем данных, а также выполнять изменения, доступные для синхронизации с другими узлами.
Такое взаимодействие обусловлено тем, что Яндекс использует не свою CRM систему, в которой нет возможности менять исходники и наладить master-slave взаимодействие. Это приводит к следующим проблемам: необходимость сложных алгоритмов синхронизации и разрешения конфликтов, повышенные требования к сетевой инфраструктуре и необходимость высокой согласованности данных.
Представьте финансовую систему, где одновременно происходят изменения данных в двух офисах в разных странах. При использовании master-master архитектуры транзакции могут обрабатываться параллельно и синхронизироваться автоматически, обеспечивая доступность и актуальность данных в обоих офисах в реальном времени. Однако в один момент может произойти сетевой или иной сбой, и согласованность будет нарушена, что может привести к потере денег или конфликтам.
🧐 Митап был организован по всем канонам Яндекс, хотя темы мне показались не очень интересными.
📌 И помните, интеграция — это не просто соединение, это взаимопонимание.
#Немыкин_Продакшн@TrueRuslan_Blog
#Яндекс #Митап
Эмм, что-то я напутал видимо с днями, но пускай
Это день вылета.
В полдень выселились, но т.к самолет в 6, то было время еще погулять.
И мы пошли в синагогу. Остались очень довольны, приятное и атмосферное место, были там на экскурсии и послушали краткий обзор религии евреев. Проникся ей и даже начал читать Пятикнижие Моисеево.
После купили новый чемодан, потому что моему в аэропорту оторвали колесики и поехали в аэропорт.
Вот и конец этого путешествия. Эмоции остались классные, приятные воспоминания и хорошие впечатления.
Однозначно рекомендую посетить этот город.
Первую половину дня откисали после морей.
А в 16 часов пошли в Кафедральный собор на атмосферный органный концерт.
Вечером посидели в баре и пошли спать, ведь завтра вылет.