Базы данных (БД) существуют с первых дней программирования, а появились они ещё раньше. Это — неотъемлемые части любых приложений. Хорошо спроектированная БД — это один из важнейших компонентов, влияющих на производительность программных проектов. Из-за этого множество архитекторов программных решений исследовали массу подходов к управлению данными, пытаясь выяснить то, какие из этих подходов работоспособны в определённых сценариях, а какие — нет. Выбор подходящей архитектуры БД обычно сводится к выбору между SQL и NoSQL, между реляционными и нереляционными базами данных. А иногда в одном проекте используют и то, и другое.

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

Часть 3. Цивилизация пружин

Представьте на секунду, что вы очень азартный игрок, который только что попал в казино и не может выбрать, за какой игровой автомат ему сесть. Или один муравей из колонии, выбирающий по какому пути ему пойти на поиски пищи. Или даже вы – это целый маркетплейс, который думает, какую же цену, ему поставить на тот или иной товар!

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

Привет, чемпион!

Мы тут недавно потратили месяц на соревнование «UW-Madison GI Tract Image Segmentation» и не взяли золото. Золотую медаль не взяли, но теперь у каждого из нас есть первая бронза. И сейчас мы кратко расскажем про сработавшие подходы в сегментации. А еще расскажем, что можно было сделать, чтоб все-таки забрать золото. (Спойлер: мы были в шаге от золота ...)

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

Стоявшая передо мной задача: улучшить инфраструктуру и качество работы приложения, успевшего вырасти из MVP и стенда для одного клиента в популярный SaaS. Отсутствие отказоустойчивости и масштабируемости компонентов сервиса начало ощутимо мешать пользователям. Настала пора адаптировать приложение под кластерный режим.

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

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

Меня зовут Сергей. Я – использованный техлид. Долго думал, что я такой один – невезучий, потерявший всякий интерес к любимому делу, работающий от звонка до звонка. Оказалось, нет.

Нас таких много. Начало, первые счастливые годы, безумный интерес к своему делу – у всех техлидов похожи. Середина – пик, душевный подъём, работа без устали сутки напролёт – один в один. Послушаешь любого техлида про его золотые годы, и скажешь – «во-во, у меня так же было!». Красная нить тех счастливых времён – невероятная востребованность, от которой буквально кружится голова.

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

Ну а потом… Приходит умный эффективный дядя, который говорит: экой тут у нас талантище! Да зазря погибает в своём пыльном углу! Не годится. Не эффективно.

Надо его использовать.

Да, действительно, в этом посте не будет гайда, как поднять Celery в Django. Это статья для тех, кто уже пощупал Celery и хочет погрузиться в детали.

Мотивацией перевести эту статью были следующие вопросы, на которые я не знал ответа: при запуске создается процесс или поток? В какую очередь попадают отложенные задачи с ETA? А какие бывают очереди (спойлер: она не одна)? А в какой момент задача удаляется из очереди? Если я создам задачу с ETA=завтра_в_12:00, она ровно в этот момент и выполнится (спойлер: нет)?

Ответы на все эти вопросы в статье, велком!

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

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

Привет, Хабр! На связи снова Юрий Кацер, эксперт по ML и анализу данных в промышленности, а также руководитель направления предиктивной аналитики в компании «Цифрум» Госкорпорации “Росатом”.

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

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

В реальности большинство таких представлений — мифы: синьоры часто ищут работу дольше мидлов, соискатели активно пишут рекрутерам, а предложения им приходят им даже не через Телеграм, а через стандартные HeadHunter и Linkedin. Чтобы подтвердить это цифрами, мы провели исследование среди специалистов в базе нашего агентства. Здесь я хочу не только рассказать о его результатах и развенчать популярные стереотипы, но и попробовать объяснить, почему все-таки бизнесу так сложно заполучить нужного кандидата.

Спринт по трудоустройству 

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

Как выяснилось в результате нашего опроса (1500 респондентов) по базе айти-специалистов, почти четверть синьоров тратят на поиск работы месяц и больше, 47% — две-три недели. Результаты опроса в нашем телеграм-канале оказались даже более впечатляющими: у 38% синьоров на выбор работодателя уходит не меньше месяца. Для сравнения: большинство мидлов (42%) находят новое место за 1-2 недели.

На Хабре уже описывали историю создания Python. Но мы решили не просто пересказать события ещё раз, а увидеть их глазами Гвидо ван Россума: что он сам думал об этом всём? Мы порылись в архивных текстах и нашли ранние высказывания, которые помогают лучше понять, почему Python стал именно таким и что определило его популярность.

Все началось с того, что в декабре 1989 года голландец Гвидо (Guido van Rossum) — будущий создатель одного из самых популярных языков программирования — искал хобби-проект, которому можно было бы посвятить рождественские каникулы… Сам Гвидо вспоминал это время так:

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

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

Этот материал представляет собой глубокое исследование всего, что связано с Redis. В частности — речь пойдёт о различных способах организации хранилищ Redis, о постоянном хранении данных, о форках процессов.

В какой-то момент времени я превратился в педанта брюзгу. В фильмах малейшие нестыковки и провалы в логике портят мне весь просмотр. В чатах меня бесит it's вместо its. А в статьях про программирование... Всё плохо. За меня всё уже сказал @AlexanderAstafiev, я лишь процитирую:

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

Самое забавное, что, по моим ощущениям, везде я вижу одни и те же классы проблем. Я даже запилил сервис, где можно закинуть код и получить код ревью, и, собрав немного статистики, понял, что 50 типов ошибок достаточно, чтобы покрыть большую часть проблем в чужом коде. Но выборка у меня была небольшая, и я подумал: а что, если проверить много кода?

Всем привет! Долго собирался выложить данный пост и вот настал момент = )

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

Язык программирования: Python

Привет, Хабр!  Учить детей программировать с помощью мобильных игр – это уже классика. Собрала для вас подборку 12 игр и каждую протестировала. Есть варианты для дошкольников и школьников. Приложения работают в офлайн-режиме, поэтому можно отключить интернет и спокойно оставить малыша с телефоном. Он ничего случайно не купит и не зайдет, куда не нужно. И заниматься можно в любом месте, даже на даче с плохой связью! 

• Вызов super() в базовых классах
• Когда использовать миксины
• Использование относительного импорта
• Когда добавлять код в __init__.py
• Когда использовать экземпляр, класс и @staticmethod
• Скрытая функция conftest.py
• Поясняющая документация библиотек