Один из самых частых вопросов в нашем сообществе разработке игр на Go — это с чего начать.

В этой серии статей мы будем изучать движок Ebitengine и создадим RPG в процессе.

Введение

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

И если в начале этого пути приходилось полагаться на божественные силы, которые, мягко говоря, не отличались надежностью, то в 20-м веке на помощь исследователям пришли технологии. С момента своего изобретения в начале прошлого столетия полиграф прошел не так много технологических эволюций, но стал значительно доступнее. Из «штуки из шпионских фильмов» он превратился в достаточно рядовое устройство, которое вполне себе встречается в жизни, например, на собеседованиях в крупные компании. Разберемся же, с чего все началось, как устройство выглядит сейчас, можно ли его обмануть, а главное — стоит ли пытаться.

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

Да вымереть не могут.

Откуда это всё пошло? Чем так условные «программисты» не угодили? И почему именно программисты?

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

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

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

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

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

Одним из самых больших разочарований, постигшим меня на пороге зрелости, явилось осознание факта – что даже абсолютная правота не является залогом победы в споре. Это знание изменило мой мир так же, как теорема Гёделя о неполноте изменила формальную логику. Я осознал, что вокруг меня существуют люди, которых невозможно переубедить, вне зависимости от убедительности аргументации и шаткости их позиции.

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

Сейчас я знаю ответ – переубедить сторонников лженаучных теорий невозможно. Но вовсе не потому, что они серьёзно заблуждаются. А в точности до наоборот – их невозможно переубедить, потому что они не заблуждаются вообще.

Привет, Хабр!

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

Начнем с бекграунда и причин.

Я – инженер машиностроитель (мой профиль – торцевые уплотнения вращающихся валов). Я начал работать в своей отрасли сразу после бакалавра, параллельно заканчивая магистратуру, и как только я начал работать, я стал стараться впитать как можно больше теоретических знаний по моей специальности из академических источников. Достаточно бысто я понял, что последняя серьезная книга по моей специальности на русском языке была написана в 1978 году. И спустя больше чем 40 лет технологии сильно поменялись, а вот их описание на русском языке отсутствовает. Зато я нашел на reddit людей работающих в штатах в моей же отрасли. Они мне насоветовали кучу классной литературы. Разумееется, она вся на английском, и русского перевода не имеет.

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

Конечно, перед началом обучения я прочитал много статей на хабре о том как люди учат языки. Некоторые из них поражали скоростью овладения материалом (что-то вроде с нуля до fluent за 4 месяца). Но одна вещь была неизменна – у всех был какой-то план изучения языка.

Вопрос выбора СУБД для российской компании или госоргана – вопрос не праздный, тем более сейчас – когда с момента ухода с рынка западных вендоров прошло уже полтора года и пора что-то решать. Но как не запутаться в номенклатуре СУБД и выбрать ту, которая лучше всего подходит? Без ложной скромности скажу: мы в «Кругах Громова» уже немного поднаторели в систематизации, поэтому надеемся, что наша шпаргалка для тех, кто хочет выбрать СУБД, окажется полезной.

Начнем с классики. СУБД делятся на несколько типов. Не будем описывать их подробно, остановимся только на их основном предназначении.

• Воспроизводить музыку и зацикливать её
• Воспроизводить звуковой эффект в определённых точках анимации
• Модулировать тон звука при каждом воспроизведении
• Перемещать их регулировать громкость звука в зависимости его местоположения в 3D-пространстве
• Управлять с помощью UI громкостью музыки и звуковых эффектов по отдельности

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

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

Введение

Всем привет! С вами Женя, разработчик Dodo Engineering и один из ведущих подкаста «Читаем вместе». Он посвящен IT-книгам. В каждом сезоне мы планируем читать и разбирать одну книгу. Уже подходит к концу первый сезон, который мы посвятили книге Fundamentals of Software Architecture. Она написана архитекторами для архитекторов, но разработчикам, особенно тем, которые интересуются, как создавать работающие системы, тоже может быть очень интересна и полезна.

Глава про архитектурные решения сильно нас зацепила, потому что в своей работе мы напрямую столкнулись с описанными в ней проблемами. 

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

Знакомо? Нам тоже. Но мы смогли победить эти проблемы.

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

Бюрократия семимильными шагами внедряется в процесс разработки. Людей в пиджаках интересуют лишь цифры, и это же относится к test coverage сервисов. Однако, покрытие зачастую (в том числе, благодаря создателям языка) не отображает полной картины мира. Так ли все плохо на самом деле?