Получил в подарок от жены к 23 фев. Заказали как только вышел пост, на следующий день уже привезли.
Легко читается (учитывая техническую сложность вопроса), чувствуется что написана с душой. Радует обилие деталей, личных примеров и тестов, особенно ценен личный опыт автора. Есть некоторые ассоциации с книгой "Паттерны программирования игр: Роберт Нистрем", где автор также делится своими наработками.
Сам пишу на C# (Unity), но всегда интересны подкапотные детали и особенности работы. Если переживете что не знаете C++ - не волнуйтесь, примеры хорошие, написано доходчиво. Но базовое понимание синтаксиса все же будет плюсом.
Из последнего интересного, что сработало для меня - это разбиение задачи на 2-3 составляющие, но не до таких мелких деталей (немного в другой плоскости).
Вместо:
"упаковать текстуры в атласы, так как обновилась юнити и старый SpritePacker уже не работает"
Делаем:
Что вообще нужно сделать (пункты из головы - все на "бумагу")
как это было устроено на проектах
что изменилось в обновлениях юнити
какие нюансы я помню
каков результат? для чего это делаю?
[Это самое важное] Собственно осмысленно потраченное время на изучение этих вопросов. Т.е. ты заранее предполагаешь что на это уйдёт не 5 минут а .. (2 часа, день, два)
И только здесь эта задача переходит к процессу решения.
В зависимости от размеров задачи - пункт 1 можно пропустить, а если задача и так мелкая - то и 2ой будет лишним.
А если что-то большое (обычно оно выявляется на 2ом этапе), то появится и 4ый - занести важное в документацию, чтобы в будущем, можно было подсмотреть подсказку или хотя бы ход мыслей (так как технически - информация всеравно устареет). Суть в том, что мы заранее себя подготавливаем к тому, что на запись информации тоже нужно время.
Тогда по завершению - нет ощущения что 3 дня что-то делал, а что именно - не понятно.
Если бы справлялись, то не было бы споров об архитектурах, ведь если подняться от 1:0 хотя бы на уровень инструкций, а там уже и до простого ЯП - то получаем те же самые проблемы как и в обычном языке.
Азбукой морзе - тоже можно общаться, но это лишь способ передачи информации, а не ее конструкции.
В Run-cat - как раз не хватает загрузки оперативной памяти.
А так идея с двумя иконками - вполне удобно. Только что бы без наведения можно было узнавать статус (не важно - в виде процентов или какой-либо анимации, но с цветами - все же тяжелее будет восприятие)
Отличная книга! Спасибо за ваш труд!
Получил в подарок от жены к 23 фев. Заказали как только вышел пост, на следующий день уже привезли.
Легко читается (учитывая техническую сложность вопроса), чувствуется что написана с душой. Радует обилие деталей, личных примеров и тестов, особенно ценен личный опыт автора. Есть некоторые ассоциации с книгой "Паттерны программирования игр: Роберт Нистрем", где автор также делится своими наработками.
Сам пишу на C# (Unity), но всегда интересны подкапотные детали и особенности работы. Если переживете что не знаете C++ - не волнуйтесь, примеры хорошие, написано доходчиво. Но базовое понимание синтаксиса все же будет плюсом.
Отличная статья! Спасибо за выжимку опыта.
В целом именно это и интересует - запуск Дискорд на своем сервере (через docker). Звонки как я понял, уже работают у них.
А так смотрю что чего-то схожего больше и нет по сути.
Достойно отдельной статьи!
Stoat интересно выглядит, кто-то пробовал?
Довольно хорошо написано, как для статей про MVC, где обычно любят излишне усложнять.
Также понравилось что показали какую именно проблему это решает.
Интересно будет почитать продолжение, спасибо.
Спасибо, статья полезная!
Но хорошо бы как-то обуздать ИИ кашу, особенно к концу, приходится просто скроллить одно и то же..
Ничего себе здесь перекличка)
Интересно как так, что человек, якобы разбирающийся в устройстве Android - не знает что подобные разрешения, есть у половины приложений на маркете.
Кроме специфичных - доступа к камере, контактам и т.п. (это понятно из назначения приложения)
Из последнего интересного, что сработало для меня - это разбиение задачи на 2-3 составляющие, но не до таких мелких деталей (немного в другой плоскости).
Вместо:
"упаковать текстуры в атласы, так как обновилась юнити и старый SpritePacker уже не работает"
Делаем:
Что вообще нужно сделать (пункты из головы - все на "бумагу")
как это было устроено на проектах
что изменилось в обновлениях юнити
какие нюансы я помню
каков результат? для чего это делаю?
[Это самое важное] Собственно осмысленно потраченное время на изучение этих вопросов. Т.е. ты заранее предполагаешь что на это уйдёт не 5 минут а .. (2 часа, день, два)
И только здесь эта задача переходит к процессу решения.
В зависимости от размеров задачи - пункт 1 можно пропустить, а если задача и так мелкая - то и 2ой будет лишним.
А если что-то большое (обычно оно выявляется на 2ом этапе), то появится и 4ый - занести важное в документацию, чтобы в будущем, можно было подсмотреть подсказку или хотя бы ход мыслей (так как технически - информация всеравно устареет). Суть в том, что мы заранее себя подготавливаем к тому, что на запись информации тоже нужно время.
Тогда по завершению - нет ощущения что 3 дня что-то делал, а что именно - не понятно.
Если бы справлялись, то не было бы споров об архитектурах, ведь если подняться от 1:0 хотя бы на уровень инструкций, а там уже и до простого ЯП - то получаем те же самые проблемы как и в обычном языке.
Азбукой морзе - тоже можно общаться, но это лишь способ передачи информации, а не ее конструкции.
В одной из статей (здесь же на Хабре) прочитал хорошую фразу, которая как мне кажется - ёмко описывает ваш комментарий:
"Мысль изреченная есть ложь" (Тютчев)
Примерная суть в том, что в языке - крайне не достаточно конструкций, чтобы явно изложить свою мысль.
Если ещё по библиотекам и синтаксису - то можно отметить структурные (вложенные) корутины и их удобный синтаксис. В Java подобного синтаксиса нет.
Постепенно приходит понимание, но первое время - да, листик висел с этими it, this.. А так, в первую очередь, стараешься что бы читалось осмысленно.
Я бы выделил ещё scope функции в Котлин, очень удобно и хорошая вариативность в использовании.
scopes: let, run, with, apply, also
Идея супер!
В Run-cat - как раз не хватает загрузки оперативной памяти.
А так идея с двумя иконками - вполне удобно. Только что бы без наведения можно было узнавать статус (не важно - в виде процентов или какой-либо анимации, но с цветами - все же тяжелее будет восприятие)
Статья супер, давно так не зачитывался, спасибо!
Прям блаженство среди "ии генерации".
Хорошая выжимка опыта, спасибо!
Ждём продолжения и технических деталей.
Да явно же, через ИИ прогнали всю эту простыню.
Недавно писали, что уже сутки без поломок)
А так - да, верно, этот момент надо учитывать, особенно если инструмент для работы.
Так как мне для личных заметок и БД, то по соответствию функциональности и текущего состояния - пока что вполне приемлемо.