Веб разработка она разная таки, кто-то по десять инстансов node.js пускает для веб разработки. Я бы в текущий момент не брал бы 13-ку с ретиной и 4гб памяти. Все таки, в целом это ноут на долго - процессора и прочего хватит на много лет, а в память вы упретесь быстро. Вот смотрите пример на 13-ке, открыто примерно 25 вкладок в хроме, терминал, скайп, sublime text - т.е. ничего тяжелого вообще - monosnap.com/image/guopQfHcjGDWCUMYn4Oc0to9uFKen1
Дык, ретины помоему меньше 8гб и нету. Но в любом случае 8гб. На 4-х даже просто в самой OSX не очень в последнее время комфортно работать, могу судить по моей 17-ке, правда она еще и без SSD. Ну, а учитывая, что память там распаянная и не апгрейднешь - то я бы брал сразу 16-ть сейчас, если позволяют финансы. Но 8гб в цлеом должно хватить, 16-ть мне лично хочется сугубо из-за xCode-а.
Это one man project, так что, пока речи о фронтэндщике не идет. Хотелось бы, если его подключать - то в самом конце, когда будет рабочий прототип - и только нужно будет UI допиливать. Т.е. на самом деле, netzke.org - что я нашел по первому совету, примерно что мне нужно. Но выглядит подзаброшенным.
Нашел netzke.org - вроде, что нужно провер extjs-а, но устарело - т.е. тутор на сайте, с последними рельсами и последним extjs-ом не работает. Может есть, еще что-то подобное?
Посмотреть, то я уже посмотрел. Но это как бы, чисто контролы - в чистом виде их используя абстрагировать от html/css/js не получится. Или я что-то не понимаю?
Печально, собственно я уже начинал догадываться, что это единственное решение, но хотелось верить в лучшее... А собственно у вас нету рабочего куска кода с такими эвристиками, опробованного в продакшене?
Как-то у нас не складывается :) Максимума — «всегда проверяйте возвращаемое значение» хороша, но не работает.
Никакой логики основной на исключениях нету, исключенние/ассерт — это способ аварийно завершить программу послав сигнал SIGABRT- после чего будет получен дамп. Это единственный способ получить какие либо данные c устройства.
Второй способ — это визуальные наблюдения тестера — если ассерта не будет, он может заметить, что при определенной комбинации дейсвий определенный визуальный сигнал не появился (лампочка не зажглась если утрировать).
Т.е. еще раз — либо SIGABRT, либо визуальные наблюдения тестера.
Но тестер обязательно рано или поздно пропустит это — поэтому нам нужно аварийно завершать программу в случае некорректных данных. Но только в дебажном билде. В релизном билде — лучше пускай лампочка не зажгется.
Это вводная.
Поэтому у нас два варианта — либо мы вставляем ассерт внутри getDocumentById — всегда зная что она не должна возвращать нулевое значение. И тогда в этом случае автоматом при определенной комбинации действий пользователя мы получим свое сообщение о ошибке в виде дампа. Либо мы надеемся что тестер сможет визуально определить что кусок с // do all business here" не выполнился и отрапортавать нам.
Ээээ, про логи я согласен, и согласен, что тестам должно быть без разницы. Вопрос в том как написать такие тесты. Можно примет?
Вот есть функция которая возвращает указательно на объект по некоторому ключу из мапы. Если мапы нету или объекта по данному ключу нету — в релизе возвращает нулевой указатель, в дебаге кидает экцепшин. В если в мапе по данному ключу есть объект возвращает его.
Мы знаем заведомо валидные и заведомо не валидные значения ключа.
Как написать тест, чтобы «без разницы, релиз это или дебаг»?
Ассерты которые пишут в специальный лог это как бы ок — но тогда тесты будут тестировать какую-то третью сборку. Т.е. есть дебажная в которой ассерты крашат приложение, релизное где ассертов нет и третья где ассерты пишут в лог.
Но тогда все же не понятно как писать тесты. Типа вызови вот эту функцию и посмотри, потом что в лог не добавилось записи?
Мы сейчас говорим о автоматических тестах все таки.
Да и проблема с тестами которые _должны_ вызывать ассерт? В дебаге — посмотри что в лог добавилась запись, а в релизе что не добавилась? Т.е. опять две реализации теста?
Второе предложение не понял. Сейчас ассерты в дебажной версии как раз и крашат приложения (на то они и ассерты).
Смотря что считать поведением. Дебажная сборка (ну может плохое название — назовем ее разработческой/тестовой) — это куча дополнительно визуальной информации, куча счетчиков начиная от fps и текстурной памяти, до графиков сколько тот или иной логический блок времени выполняется, внутренние логи, визальная дополнительная информация, доступ к функция не доступным для пользователям для облегчения тестирования и т.п. Ну и работает он по понятным причинам в разы медленней.
В релизной сборке этого ничего нет, все вырезается. Ассетов тоже нету в релизной сборке. Пускай лучше пользователю будет не доступен определенный функционал, чем будет крашется при его использовании.
Максима что проверки должны быть везде тоже хороша. Собственно тесты это и помогают проверить.
Но вопрос как такие тесты организовать, собственно остался открытым.
Хотя возможно я не понял вас — можно на примере вот функции которой я описал?
Вот есть функция которая при валидных значениях должна возвращать валидный указатель, а не при не корретных нулевой — в релизном билде. В дебажном она должна кидать исключение и крашить приложение.
Тем что много телодвижений нужно. Начиная от регистрации. Я хочу кнопку запостить запрос, от разработчика возможность запостить нужные мне 5-50 строчек кода, а мне возможность перевести ему деньги (через paypal ок).
Во первых — если говорить о классических паблишеров и издателей мобильных игр, то выше комментарии о том что 500к рублей много — это миф, если издателя вы таки сможете заинтересовать то такая сумма его не отпугнет ни в каком случае.
Более того, даже отпугнет те что маленькая… По ряду причин — во первых издатели вкладываются не столько в игру, сколько в существующую команду с опытом (пуска даже не игровым) — а поверить что команда из даже из 3-х проффесиональных разработчиков планирующих на фуллтайме разрабатывать игру (в иного варианта нет) — уложится в 500к в разработку игры которая имеет шансы выстрелить не поверит никто, даже если тут деньги на маркетинг не заложены.
Во вторых собственно разговор нужно начинать с выкладывания демки, с минимального промо сайта с видео и описания как вы будите зарабатывать деньги. Например если это дейсвительно красивый 3д экшен с вменяемо продуманной фремиум монетизацией (подтвержденной другими аналогичными играми) — то поверте найти 500к не проблема.
Берите свою красивую демку, заливайте на планшет — и начинайте ездить по конференциям, вот тот же сейчас проходит — www.wnconf.com/ru/
Если у вас реально красивый 3д экшен, и реально уже есть база (красивый GUI, и хоть какой-то красивый геймплей) — и дейсвительно, есть понимание как туда прикрутить онлайн + в идеале он будет фремимум — поверте, вы там заинтересуете многих.
Просто ходите и показываете всем. Собираете фидбэк. Middle Core геймплей (а 3д экшен от третьего лица это оно должно быть), с онлайном, с красивой графикой сейчас интересен практически всем.
