Self hosting REST-сервиса

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

Чтобы иметь обоснованное представление об этом, предлагаю воспользоваться гайдом из 100 слов наиболее часто встречающихся в теме IT. Этот список наработан мною за 2 года работы с видео и статьями из таких изданий, как MIT, TechLife News, Bloomberg, Science Today, Harvard Business Review. 

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

Можно ли выучить английский по списку слов? Нет, конечно. Но по нему можно оценить в процентном соотношении, сколько из 100 вам уже известно. 

Важно: не воспринимайте перевод слишком буквально и попробуйте предложить свой, исходя из описания на английском.

Человека далёкого от клиентской разработки на Windows все эти термины определённо путают. И даже среди MS-сообщества регулярно возникают споры жив UWP или мёртв. Причем главный вопрос в этом споре - а что же такое UWP?

Вот уже года 3 Microsoft проводит "рефакторинг" в своём "королевстве".  Несколько устав видеть одни и те же споры в твиттере, и оставлять одни и те же комментарии на хабре, я решил расписать как же многочисленные UI-фреймворки MS соотносятся между собой. Кто из них больше мёртв. Возможно, кому-то это поможет в выборе технологии для будущего проекта.

Привет! Меня зовут Павел Лакосников, я тимлид команды бэкенд-инженеров в Авито. Сегодня расскажу про свой любимый подход к разработке Trunk Base Development, сравню его с другими моделями ветвления и подсвечу его достоинства и нюансы.

Краткий обзор трёх моделей ветвления: Central Workflow, Git Flow, Trunk Based Flow, с акцентом на моего фаворита — Trunk Based Flow.

Привет, Хабр! Недавно я выступал на Moscow Python Conf, где делился нашим опытом создания и использования CI/CD пайплайнов. В данной статье я расскажу об этих пайплайнах, раскрою их особенности и покажу, как они помогают нам быстро доставлять код и поддерживать высокий показатель Time To Market. Надеюсь, что наш опыт будет полезен и вам.

Привет всем! Меня зовут Юля, я фронтенд-разработчик, наставник на курсах по JS и React и организатор профессионального сообщества Tbilisi JS. В Практикуме я помогаю студентам на курсе «React-разработчик».

За время работы в разных компаниях и над разными проектами я поняла, что Git — это не только (и не столько!) знание самой технологии и конкретных команд, но и определённая культура взаимодействия, практики, подходы, договорённости. Всё это помогает участникам команды лучше понимать друг друга и работать быстрее и чётче.

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

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

Меня зовут Денис Исаев, и я руковожу одной из бэкенд групп в Яндекс.Такси. Сегодня я поделюсь с читателями Хабра описанием проблем, которые могут возникнуть, если не учитывать идемпотентность распределенных систем в своем проекте. Для этого я выбрал формат вымышленных историй о стажёре Васе, который только-только учится работать с API. Так будет нагляднее и полезнее. Поехали.

Обстоятельство первое. Всего теоретически IPv4-адресов может быть:
2³² = 2¹⁰*2¹⁰*2¹⁰*2² = 1024*1024*1024*4 ≈ 1000*1000*1000*4 = 4 млрд.
Ниже мы увидим, что довольно много из них «съедается» под всякую фигню.

1. Создаётся ключевая пара, состоящая из секретного (secret key, SK) и открытого (public key, PK) ключей.
2. При помощи секретного ключа выполняется ряд операций. Первая из них, создание открытого ключа, уже выполнена на первом шаге.
3. Выполняется на первый взгляд противологичное действие – секретный ключ уничтожается без возможности восстановления.