— Я не продаю часы, — ответил я.

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

— Я обычно оцениваю работу под ключ. Часовой ставки у меня нет.

— У всех есть такая ставка, хотят они того или нет.

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

Потенциальный клиент не стал дальше на меня давить. А уже потом я, засыпая поздним вечером и переваривая события дня, хлопал себя по лбу со словами: «Надо было просто ответить, что он застал меня подобным вопросом врасплох и что я готов ответить на него чуть позже!».

Почему же я сразу не назвал своей часовой ставки?

Привет! Меня зовут Влад и занимаюсь Python backend-разработкой. Довольно долго я работал над большим продуктом, который объединял несколько команд разработки. В нем было много микросервисов, базовые фичи кочевали из одного в другой, и часто разработчики делали одни и те же инфраструктурные компоненты по-разному. А когда переходили с одного микросервиса на другой, им приходилось долго осмыслять кодовую базу нового решения.

Код полнился ошибками, а разработчики тратили время на их отладку и исправление. Так мы вживую воплотили печальную статистику: разработчики ПО в среднем тратят на написание кода лишь [52 минуты в день](https://www.software.com/reports/code-time-report), остальное — исправление ошибок и другие сопутствующие задачи.

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

Привет, Хабр! Меня зовут Катя, я IT-рекрутер в Авито, нанимаю разработчиков. В статье я разбираю все плюсы и минусы Weekend Offer, причем не только для эйчаров, но и для разработчиков, ведь такие ивенты мы организуем прежде всего для них. Также я раскрываю подробности процесса, каким я вижу его от лица рекрутера. Так что вы сможете заглянуть за кулисы WO)

Данная статья открывает серию из трёх материалов, каждый из которых представляет отдельный уровень изучения Kafka.

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

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

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

Срочно нужен человек — HR присылает резюме — быстренько интервью — берём. Через три месяца выясняется, что кандидат не подходит. Ещё месяц уходит на увольнение, потом снова поиск. В итоге полгода потеряно. 

Компания Trail of Bits уже несколько лет сотрудничает с репозиторием PyPI, помогая добавлять в проект новые возможности и улучшать стандартные параметры безопасности в экосистеме управления пакетами Python.

Как и когда использовать Celery — мой опыт на проде

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

Что такое интервальные повторения

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

То же самое относится и к предметам в школе или вузе: нескольких часов в неделю в классе или домашний заданий редко хватает для наработки крепкой базы знаний, особенно в таких предметах с большим объёмом фактов, как история или медицина. Под этим углом можно рассматривать даже ту часть своей жизни, которую мы не считаем связанной с обучением: не казались ли все эти подкасты и статьи с Hacker News полезнее, если бы мы могли вечно помнить полученную из них информацию?

Системы интервального повторения (spaced repetition) — один из самых проработанных решений этой проблемы. Это компьютерные программы, которые, по сути, показывают флеш-карточки с подсказками, на основе которых нужно вспомнить информацию, написанную на обратной стороне карточки.

Привет всем!

Как обычно это и бывает, я накопил критическую массу мыслей, и пора их как-то систематизировать, чтобы вы, мои замечательные читатели Хабра, могли что-то извлечь из моего опыта или поделиться своим :)

Я люблю и одновременно ненавижу статьи-обзоры в стиле «10 программ для {whatever}». Ненавижу — потому что их очень легко делать, вбил в гугл «программа для X», взял первые 10 ссылок, статья готова. Я называю такие статьи «лёгкий рейтинг». А люблю я их за то, что даже если 9 пунктов — чушь полная, то десятый, как правило, годный, я узнаю что-то новое, это что-то облегчает мне жизнь и позволяет мне быть более продуктивным.

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

Статья получилась ОГРОМНАЯ, и у меня был большой соблазн разбить её на сотню статей поменьше, чтобы в каждой ставить ссылки на свой телеграм-канал и получать гонорар за каждую по отдельности. Но я не буду. Пусть знания будут сгруппированы вместе. Welcome!

Привет, Хабр. Изучая безграничные просторы интернета интернета, заметил явное отсутствие обучающих статей на тему кастомизации админ-панели в /Django/, а уж поверьте. Её довольно старое для современных рамокстилизация — не приговор. И делается это буквально в пару кликов, без лишнего .css кода. На который как раз таки гайдов полно. Зачем засорять папку со статическими файлами лишним кодом, если можно сделать это в пару кликов.

Главное преимущества /Python/, заключается в том, то что пишется на других язык программирования в десять строк, можно написать на нашем любимом языке в две строчки. Поэтому варианты с самостоятельной кастомизацией, затрагивать не будем. Хотя данная библиотека, не ограничивает вас в написание своего кода для кастомизации. Всё написанное, лишь подключенная библиотека на /Python/ для /Django/.

Не выразить словами, как волнительно и, чего уж там, страшно презентовать редизайн Яндекс Карт!

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

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

Сегодня мы обновили внешний вид Яндекс Карт. Одно из главных изменений затронуло отображение дорог: они обзавелись детальной разметкой и сменили привычный жёлтый цвет на серый — как в реальной жизни. Хочу рассказать о процессе поиска дизайн‑решений и раскрыть, почему были сделаны эти и другие изменения, а их в редизайне довольно много.

Эпиграф:
Приходит чувак к музыкантам, в группу просится. Те у него и спрашивают: 
- А ты на гитаре играть умеешь? 
- Нет. 
- А на барабанах? 
- Тоже не умею. 
- Может ты поешь? 
- Не пою. 
- Зачем ты нам тогда нужен? 
- Знаете, я просто офигенный друг!

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

8 лет назад я исправил опечатку в чужом репозитории, а сейчас регулярно делаю коммиты в проекты, которые использую, и даже вошел в core team библиотеки с 27000 звёзд на GitHub

В этой статье покажу, что участие в Open Source проще, чем кажется. Расскажу, как регулярная работа с чужим кодом помогает быстрее разбираться в незнакомых кодовых базах, писать тесты и лучше документировать решения. А также объясню, почему публичная активность на GitHub выгодно отличает вас от других разработчиков, особенно в эпоху повсеместного использования ИИ.

Потому, что микро-сервисы часто оказываются не «микро», а «нано» сервисами.

Маленькими, изолированными сервисами под конкретную маленькую задачу. Они любят полакомиться чужими событиями. Но они не жадные: поймают одно событие, кинут три. Поодиночке они почти бесполезны. Про них можно слагать анекдоты: «Сколько надо сервисов, чтобы напечатать Hello World?». Поэтому нано-сервисов много, они плодятся как зайчики. Или как маленькие паучки, которые затягивают организацию своей паутинкой.

Систему нано-сервисов трудно спроектировать, легко уронить и невозможно поддерживать.

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

За 25 лет в разработке со мной произошло много занятных историй.

Мы сделали клиентов миллионерами, проводя тестирование на проде. Едва не получили дипломатический скандал, показав министру неполиткорректный экран.

Я общался «по понятиям» с боссом из 90-х с индийским колоритом. Корпел над секторами жесткого диска из-за пингвина-терминатора (да, это про Linux!). Физически ощущал запах сгоревшей премии дорогого сгоревшего железа.

Здесь нет вымысла – только ТруЪ истории и опыт, который я получил. Читайте, смейтесь и… никогда не повторяйте это дома.

Вас спрашивали «Кем Вы видите себя через 5 лет»? Меня тоже. За двадцать пять лет в IT я понял, зачем они так делают. Понял – это значит, что я «привык и научился пользоваться» (С). Но «неприятно удивлять» они меня не перестали.

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

Дисклеймер:

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

Категорически приветствую, дорогой Хабр! Меня зовут Сергей и я психолог. Но не нужно хлопать и говорить «я тебя так понимаю» или «сочувствую». Я искренне люблю свою профессию. Одна из главных причин этой любви – возможность прикоснуться ко множеству жизней и понять размышления человека, его майндсет, если позволите. А также, увидеть, к чему этот майндсет привел – к каким достижениям и, разумеется, трудностям.

И по моим подсчетам, за последние три года я пообщался (как бы сказали любимые здесь всеми HR-ы: «провел глубинное интервью») примерно с сотней айтишников всех мастей. И вот замеченные закономерности и выводы мне хочется обобщить в этой статье. Фактически, это будет набор жизненных историй, переживаний и размышлений, которые достаточно трудно узнать в таком количестве и на таком уровне откровенности, не находясь в роли психолога. Впереди вас ждет квинтэссенция самых сокровенных мыслей, желаний и неудач ваших коллег по цеху, которые вам никогда об этом не расскажут. Поехали!