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

Хабр - не жалобная книга, я знаю. Но тут история про код, с примерами, разбором антипаттернов и всё такое, поэтому я рискну.

Всё началось, когда я узнал про конкурс красоты кода от Сбера. Я как раз хотел поучаствовать в каком-нибудь эпичным конкурсе, а тут как раз он мне и подвернулся, тем более что я - тот человек, которому есть что рассказать про красивый код. Я даже целую статью запилил о том, как писать красивый и понятный код. Так что что я решил, что в данном случае мои шансы на победу - в отличие от остальных конкурсов - всё же больше 0%. Кроме того, я хотел выступить на конференции PiterPy (спойлер: хрен мне), чтобы рассказать там про красивый код и всё такое, поэтому участие в конкурсе и сравнение результатов было бы классным подспорьем.

Пролог

- Глянь, статью на Хабр подготовил.
- Эм... а почему заголовок на английском?
- "Предметно-ориентированное проектирование, Гексагональная архитектура портов и адаптеров, Внедрение зависимостей и Пайто..."

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

--

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

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

Меня зовут Дмитрий Кочнев, я разработчик в команде интернет-платежей и в этой статье расскажу о том, какой путь проделала компания в этом направлении, какое положение дел сейчас и какие планы. Статья написана в формате мини-историй, каждая из которых может стать отдельной статьёй с большим количеством подробностей, если к ней возникнет интерес с вашей стороны.

Здравствуйте! В этой статье, я постараюсь кратко рассказать о четырёх достаточно известных способах хранения деревьев с указанием преимуществ и недостатков. На идею написать подобную статью подтолкнул не раз слышимый мною вопрос: "А как это будет в Hibernate?", то есть как реализовать какой-либо из способов хранения дерева с использованием ORM Hibernate. Сразу замечу, что данная статья не является каким-либо призывом использовать именно реляционные БД для решения задач связанных с деревьями, так как понятно что реляционные базы не заточены конкретно для целей хранения\обработки таких данных. Для иерархии подходят и используются графовые базы данных. Поэтому эта статья будет полезная тем, кому необходимо по каким-либо причинам реализовать хранение дерева именно в реляционной БД. Необходимо также отметить, что и ORM Hibernate также не содержит каких-либо готовых решений из коробки для хранения\обработки деревьев по крайней мере на данный момент, поэтому реализация таких решений практически полностью ложиться на плечи разработчика. В примерах далее для полной и целостной картины, кроме сущностей(entity), рассмотрим кратко и такие базовые операции, как получение всех потомков с уровнем вложенности, получение всех родителей с уровнем вложенности, а также операции добавления, удаления и перемещения узла в дереве. В качестве примера дерева послужит структура папок на файловой системе, которая будет отражена в таблицах(е) БД. На такие моменты, как инициализация сущности(entity) не будем акцентировать внимание, полагаю что рассматривать это не имеет смысла, так как алгоритмы обхода дерева известны и описаны во многих книгах и публикациях и будут мало кому интересны. В любом случае мои реализации обхода дерева представлены на GitHub и с ними при желании можно ознакомиться.

Внезапно уехавшие могут пребывать в паническом шоке. А дальше что? Уехал, и? А что если затянется на года? Даже если есть деньги, в какой стране можно остаться надолго?

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

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

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

Продолжаем вкусно готовить asyncio

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

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

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

Уже три года, как мы постепенно передаем солюшн-архитектуру в команды разработки. Приходится часто объяснять, как сделать архитектурное решение коллегам, которые раньше подобными вещами не занимались. Отсюда родилась идея этой статьи – поделиться опытом, который сложился у меня и моих коллег за 10 лет практики. Важная часть этого опыта – шаблон архитектурного решения с пояснениями как его заполнять и почему именно так. По сути, шаблон - это структура необходимых знаний. Если вы нашли ответы на все вопросы шаблона, значит вы продуманно подошли к созданию архитектуры. А еще, сделали хороший документ, с которым удобно работать.

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

Статья будет полезна:

• Аналитикам, тимлидам, программистам, которые уже делают или собираются делать архитектурные решения;

• Архитекторам, чтобы улучшить качество выпускаемых документов;

• Главным архитекторам с целью посмотреть «а как там у них».

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

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

Этот пост является версией моей же англоязычной статьи "How to avoid gotchas in Go", но слово gotcha не переводится на русский, поэтому я буду использовать это слово как без перевода, так и немного непрямой вариант — "наступать на грабли".

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

В языке Go есть несколько таких gotchas и есть немало хороших статей, которые их подробно описывают и разъясняют. Я считаю, что эти статьи очень важны, особенно для новичков в Go, поскольку регулярно вижу людей, попадающихся на те же грабли.

Но один вопрос меня мучал долгое время — почему я сам никогда не делал этих ошибок? Серьезно, самые популярные из них, вроде путаницы с nil-интерфейсом или непонятного результата при append()-е слайса — в моей практике никогда не были проблемой. Каким-то образом мне повезло обойти эти подводные камни с первых дней своей работы с Go. Что же мне помогло?

И ответ оказался довольно прост. Я просто очень вовремя прочёл несколько хороших статей о внутреннем устройстве структур данных в Go и прочих деталях реализации. И этого, вполне поверхностного на самом деле, знания было достаточно, чтобы выработать некоторую интуицию и избегать этих подводных камней.

Вопросы код-ревью меня интересуют очень давно. Много раз возникали те или иные проблемы то с качеством кода, то с климатом в коллективе. И действительно, code review — это если не единственное, то одно из самых главных мест для возникновения конфликтов в коллективе разработчиков.

И вот недавно при подготовке к очередному выпуску подкаста "Цинковый прод" я узнаю, что Google опубликовал свод правил по проведению Code Review, битком набитый ценными мыслями. Весь материал довольно объемный и не влезет в одну статью, поэтому я постараюсь выделить наиболее интересные (мне) мысли.

Итак, поехали