Признавайтесь, кто Хабр сломал?
Давно есть мысли публиковать сюда ошибки из больших (и не очень) айти компаний. Ошибаются все и с завидной регулярностью, просто об этом не очень принято говорить, а зря. То пятоситит, то токен на пушах забудут поменять. Тот же Сбер у меня пока №1 в рейтинге.
Если верить, что никто не делает ошибок, синдром самозванца тебя сожрёт :)
Давно есть мысли публиковать сюда ошибки из больших (и не очень) айти компаний. Ошибаются все и с завидной регулярностью, просто об этом не очень принято говорить, а зря. То пятоситит, то токен на пушах забудут поменять. Тот же Сбер у меня пока №1 в рейтинге.
Если верить, что никто не делает ошибок, синдром самозванца тебя сожрёт :)
Кисель в АйТи | AI, Python, технологии pinned «Оставайся, если хочешь услышать крутые истории, важные новости и полезные советы из мира IT. Делюсь только тем, что считаю важным и актуальным. Меня зовут Александр Киселев, я разработчик. Вот о чем я пишу: - Полезные инструменты/сервисы - Айтишные истории…»
Посетил тут небольшой митап от Астры. Уютненько, рядом с м. Таганская арендовали лофт с проектором. Были доклады про питон, закуски, пиво. Было нас человек 50 на вскидку.
Идея крутая. Даже удивило, что можно так заморочиться на такое маленькое мероприятие. Главный минус - доклады. Что-то про GIL, что-то про JSON-RPC, что то про хороший код, но в целом ни о чем.
Если знаете какие то интересные митапы, посоветуйте в комментах :)
P.S Никакого афтерпати не случилось. На этой неделе был релиз. А когда релиз, всего много и все срочно. Так что я выбираю сон 😂
Идея крутая. Даже удивило, что можно так заморочиться на такое маленькое мероприятие. Главный минус - доклады. Что-то про GIL, что-то про JSON-RPC, что то про хороший код, но в целом ни о чем.
Если знаете какие то интересные митапы, посоветуйте в комментах :)
P.S Никакого афтерпати не случилось. На этой неделе был релиз. А когда релиз, всего много и все срочно. Так что я выбираю сон 😂
👍5🐳2
#разработка #процессы #флоу
Во многих компаниях оценивают время на разработку по статье аналитика. Эта примерная оценка и закладывается в спринт. Иногда даже с хорошим запасом (х1.5-х2). И всё равно мимо. Потом выясняется, что для простой апишки (внезапно) нужно обмазаться легаси-кодом, к которому ни документации, ни комментариев. Потом что-то зависнет на другом отделе. Потом что-то придется переделывать, потому что на старте не уточнили. Хотели сделать за неделю, а сделали за месяц. Если повезло.
Да, обычно разработчики перед оценкой всё равно смотрят статью с тех. заданием, связанный код, возможные подводные камни, узнают детали у аналитика, но пока это не выделилось в отдельный осознанный шаг все вокруг (я тоже) сильно промахивались. Иногда чуть-чуть, а иногда очень даже сильно 🙂 Мне столько раз казалось, что ну вообще всё ясно и понятно, а потом приходилось страдать.
Цель этапа проектирования - разобрать задачу с технической стороны, погрузиться и детально продумать реализацию. Сюда входит декомпозиция на более мелкие задачи, PoC (если нужен), проектирование классов, поиск подходящих паттернов, а так же выделяются ограничения и возможные сложности. Всё это можно обсудить с командой, вместе подумать и найти самое удачное решение. По итогу мы получаем практически готовый план по разработке, которому можно следовать. Эти же статьи - отличная доп. документация для аналитиков, тестировщиков и конечно же разработчиков. Всегда можно вернуться и подробнее изучить контекст принятых решений.
Минусы тоже есть. Я выделяю два основных. На проектирование уходит время. И, конечно же, бывают расхождения реализации с документацией (можно тупо забыть обновить статью).
А как у вас построен этот процесс? Делитесь, очень интересно 🤓
Во многих компаниях оценивают время на разработку по статье аналитика. Эта примерная оценка и закладывается в спринт. Иногда даже с хорошим запасом (х1.5-х2). И всё равно мимо. Потом выясняется, что для простой апишки (внезапно) нужно обмазаться легаси-кодом, к которому ни документации, ни комментариев. Потом что-то зависнет на другом отделе. Потом что-то придется переделывать, потому что на старте не уточнили. Хотели сделать за неделю, а сделали за месяц. Если повезло.
Да, обычно разработчики перед оценкой всё равно смотрят статью с тех. заданием, связанный код, возможные подводные камни, узнают детали у аналитика, но пока это не выделилось в отдельный осознанный шаг все вокруг (я тоже) сильно промахивались. Иногда чуть-чуть, а иногда очень даже сильно 🙂 Мне столько раз казалось, что ну вообще всё ясно и понятно, а потом приходилось страдать.
Цель этапа проектирования - разобрать задачу с технической стороны, погрузиться и детально продумать реализацию. Сюда входит декомпозиция на более мелкие задачи, PoC (если нужен), проектирование классов, поиск подходящих паттернов, а так же выделяются ограничения и возможные сложности. Всё это можно обсудить с командой, вместе подумать и найти самое удачное решение. По итогу мы получаем практически готовый план по разработке, которому можно следовать. Эти же статьи - отличная доп. документация для аналитиков, тестировщиков и конечно же разработчиков. Всегда можно вернуться и подробнее изучить контекст принятых решений.
Минусы тоже есть. Я выделяю два основных. На проектирование уходит время. И, конечно же, бывают расхождения реализации с документацией (можно тупо забыть обновить статью).
А как у вас построен этот процесс? Делитесь, очень интересно 🤓
1👍2
#инструменты #ai
Не так давно думал, какие новые инструменты за этот год я стал использовать регулярно. В мой топ №1 входит запрос к ChatGPT "Какой паттерн чаще всего используется при реализации <формулировка вашей задачи>?"
Несмотря на то, что я паттерны люблю и помню (вроде), иногда удается получить очень вкусные решения или идеи для начала разработки.
Не так давно думал, какие новые инструменты за этот год я стал использовать регулярно. В мой топ №1 входит запрос к ChatGPT "Какой паттерн чаще всего используется при реализации <формулировка вашей задачи>?"
Несмотря на то, что я паттерны люблю и помню (вроде), иногда удается получить очень вкусные решения или идеи для начала разработки.
Я тут решил первый раз опубликоваться на Tproger. А зря, очень зря.
Оказалось это худшая площадка, где можно публиковаться, у меня просто глаз дёргается)
Пост провисел сутки на модерации и пропал в 404 ошибке.
Эта 404 ошибка даже не всегда отображается. При переходе в статью пустой экран.
Уведомления не отработали (там всё еще пусто).
Отредактировать пропавший пост не хватает прав (видимо потому что он в неподходящем статусе, но почему я должен догадываться?).
Кнопки перестают отвечать.
Данные, с апихи постоянно задваиваются-затраиваются (такое даже в пет-проектах на vue нормально работает).
Шел 2024 год, не всем компаниям по зубам была публикация статей на сайте... Я не знаю, как вообще у них получилось такое релизнуть.
Оказалось это худшая площадка, где можно публиковаться, у меня просто глаз дёргается)
Пост провисел сутки на модерации и пропал в 404 ошибке.
Эта 404 ошибка даже не всегда отображается. При переходе в статью пустой экран.
Уведомления не отработали (там всё еще пусто).
Отредактировать пропавший пост не хватает прав (видимо потому что он в неподходящем статусе, но почему я должен догадываться?).
Кнопки перестают отвечать.
Данные, с апихи постоянно задваиваются-затраиваются (такое даже в пет-проектах на vue нормально работает).
Шел 2024 год, не всем компаниям по зубам была публикация статей на сайте... Я не знаю, как вообще у них получилось такое релизнуть.
1🤷♂4
Этот год изменил всё :) На российском рынке труда FastAPI на конец 2024 года в итоге смог обогнать Django по количеству вакансий. Собрал статистику с HH и свои мысли о том, что будет дальше:
https://tproger.ru/articles/django-vs-fastapi-v-2025-godu--kakoj-frejmvork-vybrat-
https://tproger.ru/articles/django-vs-fastapi-v-2025-godu--kakoj-frejmvork-vybrat-
🔥2
Тут 19 декабря в 17.00 будет сходка в офисе Яндекса по итогом года для Python. Ловите ссылочку https://yandex.ru/pytup
Выглядит любопытно. Спикеры норм, еще и на офис поглядеть.
Интересно по какому принципу будут разбирать заявки. Еще и ответят только за три дня до мероприятия... Но заявку закинул, должно повезти)
Отпишитесь, кто пойдет. Можно будет там встретиться.
Выглядит любопытно. Спикеры норм, еще и на офис поглядеть.
Интересно по какому принципу будут разбирать заявки. Еще и ответят только за три дня до мероприятия... Но заявку закинул, должно повезти)
Отпишитесь, кто пойдет. Можно будет там встретиться.
Pytup: итоги 2024
Поговорим о том, что произошло с языком за год и посмотрим, оправдались ли наши ожидания от 3.12 и 3.13 с прошлого года
1👍1
Пишите код так, как будто поддерживать его будет склонный к насилию психопат, который знает, где вы живёте (с)
Любимая цитатка. В 1991 году понимали, как заставить человека писать читаемый код :)
Сложно представить, какие ужасы можно было наговнокодить в то время.
Не было удобного код ревью. Не было поисковиков. Про подсветку кода и линтеры можно было только мечтать.
Страшно, очень страшно. Если б мы знали, что это такое...
😁2
Монолит? Фу, ты что, в каменном веке застрял?
Печальное заблуждение. Думаю мы сами в этом виноваты. Обучающие курсы пытаются из этой темы выжать максимум продаж. Компании стараются быть в тренде и периодически выбирают такую архитектуру только потому что это круто и современно! Напишем в вакансии, что у нас ещё и хайлоад — чтобы совсем мощно звучало.
Реальность куда печальней. Ты окажешься на проекте с n-микросервисами, которые пять поколений разработчиков передавали друг другу как эстафетную палочку. Единого стиля разработки нет, у каждого сервиса свои костыли. Чтобы отладить баг, нужно поднять десяток контейнеров, а потом неделями разбираться, в каком сервисе что сломалось. Повезёт, если есть крутая команда, у которой будет время тебе помочь. Но есть риск продолжить писать костыли в соло.
Да, в монолите есть схожие проблемы, но они менее выражены. Один проект проще менеджерить и развивать, чем десять маленьких. В том числе и команде разработчиков, так как все обычно погружены в проект и знают, как он устроен.
Тем не менее мы живем в то время, когда монолит стал настоящим редфлагом. Простое, понятное решение вдруг превратилось в признак устаревшего проекта. А ведь это просто один из подходов к разработке. Я бы даже сказал, что это классика, которая доказала свою жизнеспособность десятилетиями. Да, у него есть минусы, но и плюсов хватает.
Не архитектура должна подстраиваться под тренды, а бизнес-задачи должны определять выбор инструментов. Помни: лучший код — это тот, который решает проблемы, а не создаёт новые :)
Реклама. Киселев А.С. ИНН 503015075801. erid: LjN8KD7v1
Печальное заблуждение. Думаю мы сами в этом виноваты. Обучающие курсы пытаются из этой темы выжать максимум продаж. Компании стараются быть в тренде и периодически выбирают такую архитектуру только потому что это круто и современно! Напишем в вакансии, что у нас ещё и хайлоад — чтобы совсем мощно звучало.
Реальность куда печальней. Ты окажешься на проекте с n-микросервисами, которые пять поколений разработчиков передавали друг другу как эстафетную палочку. Единого стиля разработки нет, у каждого сервиса свои костыли. Чтобы отладить баг, нужно поднять десяток контейнеров, а потом неделями разбираться, в каком сервисе что сломалось. Повезёт, если есть крутая команда, у которой будет время тебе помочь. Но есть риск продолжить писать костыли в соло.
Да, в монолите есть схожие проблемы, но они менее выражены. Один проект проще менеджерить и развивать, чем десять маленьких. В том числе и команде разработчиков, так как все обычно погружены в проект и знают, как он устроен.
Тем не менее мы живем в то время, когда монолит стал настоящим редфлагом. Простое, понятное решение вдруг превратилось в признак устаревшего проекта. А ведь это просто один из подходов к разработке. Я бы даже сказал, что это классика, которая доказала свою жизнеспособность десятилетиями. Да, у него есть минусы, но и плюсов хватает.
Не архитектура должна подстраиваться под тренды, а бизнес-задачи должны определять выбор инструментов. Помни: лучший код — это тот, который решает проблемы, а не создаёт новые :)
Реклама. Киселев А.С. ИНН 503015075801. erid: LjN8KD7v1
🔥4👍2💯2
OpenAI выпустили новую модель o1 pro, которая будет доступна на новом тарифе ChatGPT Pro за 200 баксов.
По бенчмаркам o1 pro справляется с кодом всего на 10% лучше o1.
Пока выглядит не очень вкусно. Даже учитывая безлимитные запросы ко всем доступным моделям. Да и в целом не понимаю, что может оправдать такую цену🍴
По бенчмаркам o1 pro справляется с кодом всего на 10% лучше o1.
Пока выглядит не очень вкусно. Даже учитывая безлимитные запросы ко всем доступным моделям. Да и в целом не понимаю, что может оправдать такую цену
Please open Telegram to view this post
VIEW IN TELEGRAM
1🔥3
Forwarded from Типичный программист
Какой материал вам понравился больше всего?
Anonymous Poll
28%
Django vs FastAPI в 2025 году: какой фреймворк выбрать
36%
Гайд: как настроить API для распознавания документов за 30 минут
35%
Как пополнить кошелёк Steam в России в 2024 году
🔥3
Ого, залетел тут в список лучших статей за ноябрь на Tproger Навалите голосов за Django vs FastAPI, будем выигрывать мерч 💃
Please open Telegram to view this post
VIEW IN TELEGRAM
👏3
Давайте поговорим про “спортивное программирование” 😓
Все эти Leetcode, Codewars, Яндекс.Контест и т.д. В целом всё сводится к бесконечному решению разнообразных задач. Но есть одно большое НО.
Проблема номер один - читаемость и поддерживаемость кода не является критерием решения задачи. Человек, который долгое время сам для себя решал задачи потом начинает производить на свет в каждом своём МР что то в стиле:
Попробуй разберись, что он хотел этим сказать… Но ведь работает, правда? А еще и эффективнее на 0.01мс, чем обычный цикл! Ох уж эти lambda-filter-reduce программисты😘
Проблема номер два - большую часть из решенных задач ты забудешь. Если ты год назад смог написать какой либо алгоритм, не факт, что через год ты его легко напишешь снова.
Эффективнее было бы вложить это время в пет-проект на незнакомом стеке, потыкать незнакомые паттерны, запроектировать всё это дело и довести до ума. По ходу всегда возникают проблемы и их решение - как раз то, что пригодится в дальнейшем для стандартного роста Junior → Middle → Senior → Архитектор/Тех.Лид.
Выбор оптимального стека и хорошая архитектура - самые важные решения. Для этого нужен определенный кругозор. И тебя будут осуждать в первую очередь за то, что проект превратился в неподдерживаемое говно, а не за скорость твоего кода. Заниматься оптимизацией нужно точечно и только тогда, когда это реально необходимо.
Так что ко всем этим решалкам задач стоит относиться как к отдельному хобби. Да, может быть полезно, но не факт. Если нравится, то почему бы и нет. Просто не нужно питать илюзий, что это лучшая и универсальная таблетка для роста скиллов.
Все эти Leetcode, Codewars, Яндекс.Контест и т.д. В целом всё сводится к бесконечному решению разнообразных задач. Но есть одно большое НО.
Проблема номер один - читаемость и поддерживаемость кода не является критерием решения задачи. Человек, который долгое время сам для себя решал задачи потом начинает производить на свет в каждом своём МР что то в стиле:
result = reduce(lambda acc, x: acc + [x**2 if x % 2 == 0 else x**3], filter(lambda y: y > 0, map(lambda z: z * -1 if z < 0 else z, range(-10, 10))), [])
Попробуй разберись, что он хотел этим сказать… Но ведь работает, правда? А еще и эффективнее на 0.01мс, чем обычный цикл! Ох уж эти lambda-filter-reduce программисты
Проблема номер два - большую часть из решенных задач ты забудешь. Если ты год назад смог написать какой либо алгоритм, не факт, что через год ты его легко напишешь снова.
Эффективнее было бы вложить это время в пет-проект на незнакомом стеке, потыкать незнакомые паттерны, запроектировать всё это дело и довести до ума. По ходу всегда возникают проблемы и их решение - как раз то, что пригодится в дальнейшем для стандартного роста Junior → Middle → Senior → Архитектор/Тех.Лид.
Выбор оптимального стека и хорошая архитектура - самые важные решения. Для этого нужен определенный кругозор. И тебя будут осуждать в первую очередь за то, что проект превратился в неподдерживаемое говно, а не за скорость твоего кода. Заниматься оптимизацией нужно точечно и только тогда, когда это реально необходимо.
Так что ко всем этим решалкам задач стоит относиться как к отдельному хобби. Да, может быть полезно, но не факт. Если нравится, то почему бы и нет. Просто не нужно питать илюзий, что это лучшая и универсальная таблетка для роста скиллов.
Please open Telegram to view this post
VIEW IN TELEGRAM
1❤7🔥5