О сложных системах простыми словами.

В шпаргалке на высоком уровне рассматриваются такие вещи, как протоколы коммуникации, DevOps, CI/CD, архитектурные паттерны, базы данных, кэширование, микросервисы (и монолиты), платежные системы, Git, облачные сервисы etc. Особую ценность представляют диаграммы — рекомендую уделить им пристальное внимание. Полагаю, шпаргалка будет интересна всем, кто хоть как-то связан с разработкой программного обеспечения и, прежде всего, веб-приложений. Буду признателен за помощь в уточнении/исправлении понятий, терминологии, логики/алгоритмов работы систем (в рамках того, что по этому поводу содержится в оригинале), а также в обнаружении очепяток.

Выражаю благодарность Анне Неустроевой за помощь в редактировании материала.

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

System Design (сборник на английском языке).

Это история про то, как не довести дело до конца, но получить уйму опыта, и вообще ни разу не обломаться.

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

Осторожно, очень много картинок!

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

Существует более сотни игровых движков, каждый из них содержит как минимум одну фичу которой нет ни в каком другом. Всех возможностей вместе нет ни в одном, и это прекрасно - иначе бы такой движок монополизировал рынок. Хм, Unreal5 ты ли это? Иногда полезно пробежать по release notes движка, чтобы оставаться в курсе последних новостей. Возможно вы разрабатываете свое решение и эта статья натолкнет вас на новые идеи. Готовы узнать что ваша любимая игры была сделана не на Unity, а на православном SDL?

За основу я взял оригинальный текст книги «The Backroom Boys: The Secret Return of the British Boffin» (автор Francis Spufford), о которой узнал случайно. «Backroom Boys» – в Британии индустриальной эпохи так называли гениальных инженеров, которые трудились в «продуваемых насквозь зданиях на задворках фабрик», и изобрели технологии будущего.

Одна из глав посвящена созданию Elite по воспоминаниям авторов – Дэвида Брабена и Йена Белла.

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

С моей стороны получился несколько вольный перевод, заранее прошу прощения за неточности. Буду благодарен за комментарии и правки. Для поклонников «Элиты» я размещу ссылку на сайт Йена Белла, где есть авторские материалы, исходники, порты для разных ПК, новелла «Тёмное колесо» Холдстока, и даже рок-опера по мотивам «Элиты», созданная братом Йена.

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

В этом посте описан мой топ-25 обязательных инструментов CLI, на которые я привык полагаться. Если тут нет вашего любимого - дайте мне знать в комментариях :)

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

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

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

Давным давно уже уже была написана статья о том что такое GVL (или GIL, кому как привычнее) и как он работает, однако с того времени некоторые вещи поменялись (к примеру, , а так же в Ruby 3.0 завезли Ractor'ы - новую абстракцию для реальной параллельной работы тредов. Мне стало интересно узнать что поменялось в планировщике ruby для реализации множества GVL. В этой статье я попытаюсь понять алгоритм, по которому GVL передается от одного треда к другому, как блокирующее IO позволяет продолжить работать другим тредам, а так же выяснить до сих пор ли операция добавления элемента в массив является атомарной операцией

Это история о том, почему вы никогда не должны замалчивать ошибки, когда вы внутри транзакции в базе данных. Узнайте, о том как правильно использовать транзакции и что делать, когда их использовать — не вариант. Спойлер: речь пойдёт об advisory locks в PostgreSQL!

Я работал над проектом, в котором пользователи могут импортировать большое количество тяжёлых сущностей (назовём их товарами — products) из внешнего сервиса в наше приложение. К каждому товару при этом загружается ещё больше разнообразных связанных с ним данных с внешних API. Нередка ситуация, когда пользователю нужно загрузить сотни товаров вместе со всеми-всеми зависимостями, в итоге импорт одного товара занимает ощутимое время (30-60 секунд), а весь процесс может порядочно так затянуться. Пользователю может надоесть ждать результата и у него есть право нажать кнопку «Отмена» в любой момент и приложение должно быть полезным с тем количеством товаров, которые удалось загрузить к этому моменту.

Все говорили – переходи на rust! Начинай пользоваться самым-самым языком, который самый любимый язык на stackoverflow и всё такое.

Я тяжело вздохнул и огляделся. Ну опять двадцать-пять. Ладно, давайте разбираться, как правильно покрывать всё ржавчиной.

Профессионально я программирую уже 17 лет. В далёкие-предалёкие времена я начал изучать программирование с x86 Assembly. Такой жестокий подход к изучению компьютера дал мне глубокое понимание того как работает процессор и что делают другие языки программирования. Учить новые языки для меня никогда не было проблемой. Я их просто учил. C, C++, шарпы, ГО, тысячи разных скриптов и фреймворков. Чего уж там, ещё один язык, можно и выучить.

Ага.

Только вот не с этой ржавой развалюхой. Я просидел две недели над официальным руководством, пялился в VSCode и не мог выдавить из себя больше чем fn main() {}. Ну какого же чёрта? Я просто закрыл глаза, открыл руководство на рандомной странице и начал его читать. И прикол в том, что я понял о чём там говориться. И тут до меня дошло… Руководство написано наизнанку. Начало и конец ничуть не лучше чем в Мементо Кристофера Нолана. Они как-то умудрились запутать в общем-то нормальное руководство. После этого всё пошло получше.

Ржавые шестерёнки заскрипели и начали крутиться. Программа пошла-поехала. Если хотите знать как я внедрил rust в продакшин, как я ему научился и что из этого вышло – добро пожаловать под кат. Реальные люди, коммиты, примеры и никаких todo-list и хеллоу-ворлдов.

Введение

https://www.deviantart.com/mrmarkchilcott/art/Warpig-662451056

Итак, ваш трактор отполирован до блеска, смазан, проведено ТО. Вы в костюмчике с иголочки стоите рядом, позвякиваете ключами и… не знаете толком куда же ехать. Внучатая племянница лучшей подруги двоюродной тети вашей мамы говорит, что лучше страны, чем Германия нет. Васек, товарищ детства, за бутылкой пива рассказал, что если куда и ехать, то в Эмираты. Там дорого-богато, а небоскребов сколько? Владимир Викторович, директор конторы, где вы в студенческие годы подрабатывали, считает, что где родился, там и пригодился, мол, страну поднимать надо. Направлений много, а жизнь одна. Давайте вместе вооружимся цифрами и попытаемся составить хотя бы отдаленно объективный список потенциальных мест дислокации на следующие N лет.

Или как обзавестись красивыми бейджиками для своего проекта за один вечер ненапряжного кодинга

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

В статье будет рассмотрена базовая настройка непрерывной интеграции и поставки для проекта библиотеки классов на .Net Core в GitLab, с публикацией документации в GitLab Pages и отправкой собранных пакетов в приватный фид в Azure DevOps.

В качестве среды разработки использовалась VS Code c расширением GitLab Workflow (для валидации файла настроек прямо из среды разработки).