poxvuibr

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

Если вам скажут, что собака кусается, а собака потом укусит не себя, а вас — вы наверное очень рассердитесь, за то, что вас ввели в заблуждение ))

А поставишь пробуждения раз в секунду — жор CPU уменьшится, но будет слайдшоу по кадру в секунду.

А если поставить пробуждения раз в 30 милисекунд?

Ну так то SDL кроссплатформенная библиотека, такое должно везде собираться.

начнем с подключения SDL 2

Вот ссылка на то как подключить: <SDL.h> или <SDL2/SDL.h> . То ли у вас в туториале неправильно, то ли информация из ссылки протухла.

Далее мы инициализируем SDL 2 функцией SDL_Init(). Мы передали в нее SDL_INIT_EVERITHING

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

ноуп, этого они как раз не утверждали то, что им приписал автор.

Совершенно верно, как я написал позже, пример плохой.

Не говоря уже о том, что приводить утверждения ученых до появления научного мтеода — это СИЛЬНО не корректно

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

Да. Сейчас мнение [о том, что употребление жирных продуктов приводит к ожирению и проблемам с сердцем] скорректировано.

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

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

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

Ну, собственно, с точки зрения минздрава — да.

И вы думаете, что с точки зрения хирургов — тоже да?

Идеально — это «пациент не умер на столе»?

Вы думаете так хирурги определяют идеальную операцию?

В моем случае ТЗ пишу я САМ.

Если ТЗ учитывает особенности реализации проекта, то его очень тяжело написать. У вас много времени отнимает детализация?

А это, кстати, плохой врач?

С моей точки зрения, это очень хороший врач.

Ведь он же старается сделать операцию идеально.

Вот поэтому и хороший.

Ключевое слово «утверждала».

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

По аналогии — приписать медицине то, что она писала 5-10 лет назад о пользе, например, вызывания духов, и потом разоблачать всё это.

Гомеопатию в больнице уважаемые врачи с настоящим медицинским образованием могут порекомендовать не 5 — 10 лет назад, а вот прямо сейчас.

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

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

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

Ctrl + p, Ctrl + n, поиск по истории (Ctrl + r) вроде только в msys работают? Или что-то уже поменялось?

Это не мешает виму игнорировать ctrl-c :)

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

Что-то слабовато, берите и с ипотекой тогда уж — чтобы его совсем можно было на поводке держать.

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

А если у него нет ипотеки — тогда оформлять ее на испытательном сроке.

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

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

И тут опять шелл скрипт для конфигурации системы, только в докере. Что же с нами стало? Как так вышло то? Почему это опять хорошо?

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

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

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

Написано «алюминем» (əˈlo͞omənəm и некоторые так и говорят), а говорилка воспроизводит что-то типа «алуминийем».

А вы пишите aluminum и нормально всё будет ))

Я посмотрел описание 7drl, там написано, что это не о том, кто быстрее кодит. И у меня сложилось впечатление, что там нужно года полтора разрабатывать игрушку, а потом за неделю сделать для неё новый логотип и вот так можно победить.

Я чего-то не понимаю видимо. Было же известно, что есть место для 1300 билетов. Нельзя было перестать продавать билеты после того, как было продано 1300?

Когда размечешь, где копать, нужно выбрать один угол, нажать Enter, потом стрелками выбрать другой угол, потом нажать Enter ещё раз.

При этом, когда хочешь построить в выкопанной обрасти пол, нужно выбрать строительство пола, а потом с помощью клавишь u, m, h, k менять размер прямоугольника, двигать прямоугольник стрелками и потом, когда прямоугольни тебя устроит — нажать Enter.

При этом на экране высадки ты двигаешь область клавишами u, m, h, k а размер меняешь U, M, K, H а стрелками двигаешь другую область вообще.

В меню перемещения между пунктами то с помощью стрелок, то с помощью + и -, то вообще можно только букву выбрать.

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

А к дженкинсу Ansible чем прикручен?

В ней автоматически создаётся двумерный мир

Мир в Dwarf Fortress трёхмерный

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

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

Поясните пожалуйста, что имеется в виду под статическими гарантиями?

Ну, что будет, если подать на вход мусор? Что будет, если цифру заменить каким-то похожим символом? Что будет, если введённые цифры заведомо нереальны?

Вывод — был выбран инструмент для решения задачи, выбор был обоснован

Почему был выбран именно php, а не python, javascript, ruby, java, Go или C#?

В ваших рассуждениях есть логическая ловушка — если заменить один бин это уже не та же конфигурация.

Как не называй, суть не поменяется. Мне хочется, чтобы все тесты, требующие БД проходили на одном и том же экземпляре встроенного postgresql.

Создать базовый класс для тестов с одинаковой конфигурацией.

Это ничем не поможет. При необходимости незначительно изменить конфигурацию Spring всё равно будет поднимать БД ещё раз.

Как уже отмечено — иметь одну базу для всех тестов

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

Подумать над каким-то runtime созданием бинов

Наверное можно, но жутко неохота, хотя подозреваю, что этим и кончится)). Помогла бы какая-нибудь аннотация в Junit наподобие BeforeAll, только чтобы она была BeforeSuite или как-то так, но её по моему нет.

del

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

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

Единственное, что пока приходит в голову это поднимать встроенную БД ещё до запуска тестов и прокидывать её в конфигурации спринга.

Ну, насколько я понял, проблема была именно в FPS. Он там был ограничен то ли цифрой 15 то ли 20. Это давно было, сейчас наверное кап повыше. Вот я нагуглил вопрос на форуме, у человека, похоже та же проблема, что когда-то была у меня. https://forum.simutrans.com/index.php?topic=17368.0

Я в своё время не смог играть из-за того, что поезда передвигались рывками. Вас это не смущает.

Чем удобнее-то [гонять и отлаживать юнит-тесты локально]?

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

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

Вы пишите, что у вас интерфейс редактора на другой машине. Вы имеет в виду, что вы подключены к этой машине через VNC или какой-то другой тонкий клиент?

Как вы без запуска кода вручную будете искать причину и исправлять?

Писать тест, который воспроизводит кейс. Тест придётся запускать вручную, да, но это в общем нормально. Неприятно, когда вы глазами смотрите, соблюдены условия удачного прогона теста или нет. Хотя, повторю такая необходимость периодически возникает у каждого.

зачем коммитить код, который заведомо не проходит тесты, если есть возможность это проверить

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

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

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

Иронично, что в защиту своей точки зрения, вы даёте ссылки на сообщество lesswrong, созданное благодаря Юдковскому, который написал книгу Гарри Поттер и методы рационального мышления, в которой в значительной мере изложены принципы lesswrong.

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

Если принять гипотезу о том, что успех зависит от людей, то придется согласиться еще с одной – люди-то не меняются.

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

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

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

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

Далее то, что вы проверяете вручную, нужно потихоньку добавлять в интеграционные тесты, запуск которых нужно делегировать CI.

И тогда можно будет большую часть разработки проводить на локальной машине.

Я уверен, вы всё это понимаете, просто вам кажется, что легче разок прогнать кейс руками, чем его автоматизировать. Тоже самое с интеграционными тестами — дёрнуть их из консоли в общем-то не очень сложно, чего париться с CI. Да и со сборкой та же история — зачем мучаться с настройкой CI, когда можно собирать локально и закидывать не сервак.

Это всё путь в никуда, нужно сворачивать в какую-то другую колею.

Я редактирую код в PHPStorm, переключаюсь в браузер либо в консоль с ssh, проверяю работу кода.

А что вы делаете, чтобы проверить работу кода?

Ну и отсутствию ИДЕ, по функционалу хотя бы похожих на Эклипс\Студию, которые бы не стоили как фотошоп… хотя может я просто не нашел еще его, тогда был бы рад, если бы пальцем ткнули в ссылку.

PhpStorm сейчас стоит 89 долларов за первый год, 71 за второй и с третьего года стоит 51 доллар в год. В рублях это примерно 5800, 4600 и 3300 соответственно. Вот ссылка https://www.jetbrains.com/phpstorm/buy/#edition=personal .

Фотошоп стоит 3400 в месяц, а в год это 40800. Ссылка https://www.adobe.com/ru/creativecloud/plans.html

Легко убедиться, что фотошоп более чем в 10 раз дороже, чем PhpStorm. Так что бегите, покупайте уже сейчас, или дождитесь скидки, в Jet Brains это бывает часто. А если вы студент, то все IDE Jet Brains для вас попросту бесплатны.