Если вы не специалист по REST, то, вероятно, в своих ответах постоянно используете одни и те же HTTP-коды, в основном 200, 404 и 500. Если применяется аутентификация, то, возможно, добавляются 401 и 403; если есть переадресации, то 301 и 302, но на этом, скорее всего, список заканчивается. Но спектр возможных кодов состояний гораздо шире и он может сильно улучшить семантику. Хотя во многих обсуждениях REST упор делается на сущностях и методах, применение подходящих кодов ответов о состояниях может повысить удобство вашего API.

О чем статья: при разработке проектов, и, особенно, распределенных приложений, возникает необходимость использования некоторых частей приложения в качестве отдельных модулей. Например скомпилированные классы для gRPC, модули для работы с БД, и многое другое, могут применяться в неизменном виде в кодовой базе десятка микросервисов. Оставив за скобками копипасту, как "хорошую" плохую практику. Можно рассмотреть git submodules, однако, такое решение не очень удобно тем, что, во-первых, нужно предоставлять разработчикам доступ к конкретным репозиториям с кодовой базой, во-вторых, нужно понимать, какой коммит надо забрать себе, и в-третьих установка зависимостей для кода, включенного в проект как субмодуль, остается на совести разработчика. Менеджеры пакетов (pip, или, лучше, poetry), умеют разрешать зависимости из коробки, без лишних действий, и, в целом, использование менеджера пакетов значительно проще, чем работа с субмодулем. В статье рассмотрим, как организовать реестр пакетов в GitLab, а также различные подводные камни, поджидающие на пути к удобной работе с ним.

Для кого: статья будет полезна разработчикам, столкнувшимся с необходимостью организации приватного реестра пакетов, в качестве руководства по организации такого реестра в GitLab.

Всем привет! Меня зовут Илья Денисов, я занимаюсь backend разработкой уже более пяти лет и сейчас пишу на языке go. Сегодня я предлагаю вам поговорить о кэшировании. Постараюсь рассказать о базовых концепциях, а также затронуть ряд особенностей, неочевидных на первый взгляд.

Доброго времени суток, уважаемые хабровчане.

В этой статье я хотел бы провести экскурс в одну сферу, которую нельзя отнести непосредственно к IT, но, она - техническая и, возможно, для вас она будет интересна. И, параллельно с ней и на её примере, поднять популярную здесь в последнее время тему востребованности специалистов.

 А пост, собственно, пойдёт о средствах радиосвязи и навигации и вообще электронике на современных морских судах, об использующихся технологиях, стандартах и даже о преждевременно “похороненной” специальности.

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

 Остальным советую ознакомиться со всей статьёй полностью: это не только дополнит повествование, но и, надеюсь, станет кому-то хорошим примером одной давно известной истины.

Hello, World! Меня зовут Денис. Я IOS разработчик, пишу приложения для App Store. Хочу поделиться своим небольшим опытом на UIKit и SwiftUI.

Первый запуск

На WWDC19 Apple предоставила декларативный фреймворк SwiftUI. Новый фреймворк позволяет уменьшать время на написание UI-составляющей своих приложений.

Почти все разработчики так или иначе постоянно работают с api по http, клиентские разработчики работают с api backend своего сайта или приложения, а бэкендеры "дергают" бэкенды других сервисов, как внутренних, так и внешних. И мне кажется, одна из самых главных вещей в хорошем API это формат передачи ошибок. Ведь если это сделано плохо/неудобно, то разработчик, использующий это API, скорее всего не обработает ошибки, а клиенты будут пользоваться молчаливо ломающимся продуктом.

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

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

То есть перечислить самые универсальные и переносимые программные компоненты (кирпичики), которые могут пригодиться в практически любой сборке.

Привет! 

Эта статья по большей части будет полезна людям, которые только начинают погружаться в процессы работы команд, применяющих Agile. После общения со стажерами и джунами в компании сразу становится понятно, что помимо погружения человека в технические инструменты работы конечно важно объяснять и основные методы работы проектных и продуктовых команд, большая часть которых работает по Kanban или Scrum.  

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

Имея опыт администрирования Jira, настройкой проектов и досок для многих команд, а также работой на других проектах по Scrum и Kanban подходам, хочу поделиться простым языком терминами и процессами, которые применяются в командах.   

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

В первую очередь нужно сказать пару слов про Agile. 

Agile - это набор методик и подходов для гибкого управления проектом по разработке программного обеспечения. Есть написанный манифест принципов и ценностей, которые описывают этот способ разработки. 

Есть разные методики управления проектом: Kanban и Scrum. 

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

После определенных событий, произошедших за последние несколько месяцев, начал задумываться о замене телевидения себе и своим близким. Очевидно самый простой вариант это покупка ТВ приставки с Android на борту, однако взглянув на цены и предлагаемое железо, идея отпала.

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

В любом случае, вот краткое изложение некоторых из кардинальных "грехов", которые я совершил при использовании docker-compose.

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

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

Скрипты на Bash. Как много в этом слове. Любому разработчику рано или поздно приходится их писать. Почти никто не скажет "да, я люблю писать bash-скрипты", и поэтому этой теме уделяют мало внимания.

Я не буду пытаться сделать из вас эксперта в Bash, а просто покажу минимальный шаблон, который поможет сделать ваши скрипты более надежными и безопасными.

Прим. Wunder Fund: в этой длииинной статье вы найдете ряд полезных советов по работе с Docker, как общего характера, так и Python-специфичных. Хоть мы и давно используем Docker в работе, про некоторые советы мы подумали "а что, так можно было?". Советуем вначале пролистать статью, и отметить штуки, которые покажутся актуальными для вашей текущей ситуации.

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

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

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

Всем привет! Меня зовут Евгений Степанов, и я Python Full Stack-Developer в компании PVS-Studio. В этой статье вы узнаете, что нужно сделать, чтобы за полгода стать Python backend-разработчиком. После прочтения данной публикации у вас будет чёткий план, который останется только реализовать. Поехали!

Из каждой своей зарплаты вы отчисляете 5,1% на ОМС. Это довольно много. Если у вас зарплата в 100 000 рублей, то каждый год вы отчисляете 61 200 рублей. На этом моменте все начинают нервничать, понимая, что полис ДМС с куда более качественным лечением обойдётся как бы не дешевле. На самом деле надо просто понимать, что задачи у этих видов страхования кардинально разные. На свои отчисления ОМС вы в том числе платите зарплату хирургам и содержите больницы, куда вас могут привезти, если не повезёт и с крыши на голову упадёт кирпич. На эти же деньги получают медпомощь пенсионеры, люди с зарплатой в районе МРОТ и дети. Отсюда и кардинальная разница в качестве и задачах. По ДМС могут вытащить гвоздь, а по ОМС только загнуть, чтобы было удобно и не снижало качество жизни.

А ещё можно просто прийти и заплатить самому. Это тоже имеет смысл, когда мы говорим о процедурах, которые не покрываются в ОМС и ДМС. Например, лечение ожирения почти никогда не покрывается страховками, хотя это играет важную роль в здоровье пациента.

Стоматологию тоже можно оплачивать из трёх источников:

1. Заплатить самому. Вы получите настолько хороший уровень сервиса, который вы сможете оплатить. Только так обычно можно оплатить самые дорогие манипуляции и качественные конструкции.

2. Сходить по ОМС. Не всё так плохо, можно получить базовую медицинскую помощь, но в целом всё сводится к самой дешёвой вставной челюсти, чтобы хоть как-то жевалось. Для простых вещей может подойти.

3. Сходить по ДМС. Покрытие зависит от полиса и чаще всего не даёт возможности качественно протезироваться или применять дорогое оборудование и материалы. Но этот вариант хорошо покроет профилактику и лечение начальных форм кариеса.

Что именно стоит лечить по какой страховке, я сейчас расскажу. 

Возможно Вам доводилось слышать про протокол журнала событий syslog, в котором можно насчитать аж 8 уровней важности: emergency, alert, critical, error, warning, notice, info, debug. Наверняка Вы, как и я какое-то время назад, думаете, “зачем столько”? А что если я скажу, что количество уровней там просто идеально? И использовать можно все - даже debug - для продакшн. Во всяком случае, каждому из них можно придать формальный критерий. Это особенно иронично для меня самого, так как всего пару месяцев назад я написал статью в духе “зачем так сложно!”. Так что если Вам интересно посмотреть на пример технического “переобувания” или оценить строгий алгоритм ранжирования уровней важности событий в системе - прошу.

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