Самое простое в сравнении с другими классами, думаете танкам или целителям проще в pvp? Думаю, тоже непросто (но это зависит от игры конечно). И обращаю внимание на «максимальный ДПС» — т.е. вы относитесь к hardcore меньшинству, которые знают свой класс и стараются по максимум утилизировать его возможности (я не говорю, что это плохо, я сам такой же, просто для Северной Америки — это меньшинство).
Для казуального же игрока в целом играть dps намного проще, т.к. он может полностью игнорировать других игроков (не надо никого лечить, следить кого атакует босс и т.п.). Обращаю внимание на «может», это не значит что этого делать на надо, обычно это плохие игроки, но их не мало. В этом плане даже есть юмористический туториал: www.swtor.com/community/showthread.php?t=671988
Трудно найти что-то хорошее без троллинга, но вот вроде нашел ветку обсуждения самых больших изменений в WoW за всю его историю: us.battle.net/wow/en/forum/topic/3424682826
Например — отказ от троицы tank-healer-dps (по такому же пути пошел SWTOR и думаю другие игры, не особо много играю чтобы знать). Причина простая — играть танком или целителем требует определенных навыкой, знаний и просто ответственности (которую по понятным причинам большинство брать не хочет). Соответственно, если у игрока класс DPS (и это абсолютное большинство, ибо самое простое), ожидание в очереди на инстанцию может занять часы, которых у них нет. (Легко подтвердить просто погуглив «dps queue time»).
В Северной Америке высокая сложность игр наоборот отпугивает массового потребителя (именно массового, всегда есть меньшинство, которые играют только на самом высоком уровне сложности). В основном это связано с возрастными категориями — массовый потребитель здесь в возрасте около 30 лет, у которых есть работа, дети и другие заботы. Игры на высоком уровне сложности требуют вовлеченности и времени, многие хотят просто прийти с работы, войти в игру, получить некоторую прогрессию (в виде выполненных заданий, новых уровней и т.п.) за пару часов, и выйти.
В итоге много игр в процессе портирования для Северной Америки уменьшают свою сложность. Хороший пример — онлайновые игры в процессе эволюции которых разработчики уменьшали сложность все больше и больше (WoW, SWTOR, TERA etc). Я не говорю хорошо это или плохо, просто это факт, подтверждение которому можно найти на многих форумах, обсуждающих сложность игр и как под давлением большинства разработчики уменьшают сложность.
Забыл заметить, что НЕ обгонять фуры не получится, потому что это даже официально предусмотрено — у фур другой скоростной режим, иногда на 20 км/ч ниже чем у обычных машин на некоторых дорогах. Конечно, никто не запрещает плестись позади, но делать это на протяжении скажем 400-500 км как-то не очень. Впрочем, если ВСЕ машины будут автоматизированы, это наверное не будет большой проблем — просто по дорогам будут ездить длинные многокилометровые процессии, и каждый будет заниматься своими делами (правда без интернета придется запасаться фильмами и другими развлекательными материалами).
Как водитель проехавший не одну тысячу километров по хайвеям США, не могу не сказать, что идея как минимум плохая. Возможно, что на автобанах Германии это и возможно, но точно не в Северном Америке:
— животные на трассах (одна из самых частых причин аварий). Это даже тяжелее предугадать, чем поведение пешеходов, потому что скорости не сопоставимы с городскими
— двухполосные дороги много сотен километров длиной. Это значит, что будут обгонять и подрезать.
— black ice
— сильные ветра, фуры реально сдувает на другую полосу (Юта, официальный лимит скорости 135км/ч, так что все ездят 140-150, а ветра там ого-го, даже мой небольшой SUV сдувает)
— мощные ливни, при видимости буквально на 20 метров вперед
Все это решаемо с помощью соответствующих алгоритмов, но тогда фуры будут ездить очень медленно, и это означает, что нам, водителям обычных машин, придется еще тяжелее, т.к. придется делать больше обгонных маневров, да и думаю, что транспортным компаниям это тоже не особо понравится, что перевозка будет занимать намного больше времени.
ujson действительно в разы быстрее, но помимо того, что он не поддерживает некоторые аттрибуты, он также не совсем корректно делает дампы некоторых типов, например результаты генераторов (у меня была с ними некоторая дискуссия и в конце концов они добавили мой патч, но все-равно остались некоторые проблемы). Учитывая, что их компанию купила EA, я не особо верю в будущее этой библиотеки (статистика на гитхабе поддерживает мои подозрения), так что мы просто остановились на том, чтобы патчить эту библиотеку локально, не дожидаясь пока они сделают поддержку тех фич, которые нам надо.
Если следовать официальным скоростным лимитам в городе (в среднем 25 миль, зависит от штата, либо 50 км/ч в Канаде), то практически никогда не надо использовать экстренного торможения, если держишь дистанцию. Ни то, ни другое, конечно, не соблюдается, но возможно что робоавтомобили будут все правила соблюдать (думаю, это будет еще одна причина, почему многие не захотят их использовать — ездить по официальному лимиту в Калифорнии на хайвее в 60 миль в час практически нереально, слишком медленно, есть большой шанс попасть в аварию, т.к. скорость сильно отличается от скорости потока, которая в среднем 70 миль в час).
Вообще-то робоавтомобили будут ездить на желтый, ибо у них нет выбора. В Северном Америке другая система светофоров: мигающий зеленый — регулируемый пешеходами светофор, и здесь сразу за зеленым идет желтый и потом красный. Причем время переключения между цветами регулируется, и если полиция чувствует, что ей надо побольше денег заработать в этом месяце, они промежуток сокращают (сейчас идут судебные разбирательства насколько это законно). Обычно, желтый горит от полсекунды до пары секунд (если огромный перекресток). Но самая большая проблема, что никогда не знаешь, когда желтый загорится: либо надо ориентироваться по пешеходным сигналам, либо иметь шестое чувство. Так что проезд на желтый — это обычное явление в Северной Америке.
Netflix генерирует до 45 процента всего трафика в Северной Америке. У Firefox-а и так есть проблемы из-за его тормознутности, а если они еще перестанут поддерживать Neflix, это будет его смерть. Так что никакие петиции не помогут, у них просто нет выбора. И на самом деле, это же Open Source — если кого-то это перестанет устраивать, всего можно форкнуть, Debian же тоже использует Iceweasel, а не напрямую Firefox. Так что сторонники чистых решений ничего не потеряют, всегда есть выбор.
В свое время для своих команд я разрабатывал стандарты кодирования, включая как правильно использовать исключения. По итогу мы пришли к двум пунктам:
— использовать исключения только для исключительных ситуаций, а не для логики. Например, правильно — проверить существование файла и открывать его, иначе писать сообщение об ошибке (для ситуаций, когда файл может не существовать на диске, например, если мы используем данные, введенные пользователем). Неправильно — сразу пытаться открыть файл, и проверять существование файла обработчиком исключений. Конечно, это очень соблазнительно — все сконцентрировать в одном месте, однако это чревато для сопровождения, потому что будущие разработчики могут подумать, что в данной функции всегда предполагается существование файла. То же самое касается проверки кодов ошибок — если проверка является частью логики (например, для программирования OpenSSL это единственный вариант), тогда надо ее использовать. Если нет — тогда позволять возникать исключениям.
— исключения должны перехватываться только там, где мы знаем, что с ними делать. Писать в лог только для того, что бы что-то написать практически бесполезно, и в основном используется только для отладки. Правильное решение — это выкидывать исключения наверх до тех пор, пока мы не сможем сделать что-то полезное с ними. Например, мы ничего не сможем сделать с исключением «метод не найден» (потому что это косяк программиста), но мы сможем что-то сделать с исключением «нехватка памяти» (например, выгрузить что-то из памяти, освободить кэши, но для этого надо чтобы менеджер кэшей получил это исключение). Для кодов ошибок это не так тривиально, поэтому иногда приходится создавать собственную иерархию исключений.
Теперь конкретно по примерам Android NDK — изначально исключения не поддерживаются, надо специально менять mk-файлы. Также в основном примеры для C, в котором нет исключений. Проверка ошибки в вышеприведенном примере в идеале не нужна, вы правильно отметили, однако она нужна для отладки и в целом для облегчения жизни программистов: JNI — не самая удобная платформа для взаимодействия Java с native-кодом, особенно учитывая магию типа названий native-функций Java_<class_path_goes_here>_<method_name_goes_here>.
Поспорю насчет хорошого климата — в последний раз был там в июле, жара неимоверная, спасали только приезды в Сан-Франциско, холодные ветра с океана позволяли выключать кондиционер. Ну и как всегда, хорошо там где нас нет, кое-что в долине хорошо, кое-что не особо. Без машины никуда, еда и жилье дорогое, но с другой стороны, хорошие зарплаты позволяют об это не заботиться. Но посетить, конечно, надо, это мекка айтишников. Насчет жить и работать — советовал бы подумать, в том же Сиэттле тоже неплохо с работой, но климат лучше (если есть терпимость к дождям).
Не хочу участвовать в холиваре, скажу лишь, что полностью согласен с автором, и после долгих дискуссий с разработчиками jquery и nodejs, мы согласились на том, что javascript имеет свои недостатки, но работать надо здесь и сейчас, и просто нет выбора. Также должен отметить, что nodejs все более разрастается функционалом, и скоро (если не уже) будет поддерживать настоящую многопоточность. Если честно, мне просто неинтересна его судьба, но к сожалению я окружен фанатиками javascript-а и приходится быть в курсе.
Позвольте отметить пару вещей по самой статье. Во-первых, мне кажется, было бы лучше убрать упоминание о firebug-е, все современные браузеры имеют встроенные Developer Tools. Далее, Dart и Coffeescript — не самые лучшие альтернативы JavaScript. Думаю, они в конце-концов тоже умрут, т.к. никаких реальных революционных изменений они не приносят, синтаксис так себе, и в целом мое личное впечатление, что я бы не хотел программировать на этом — все те же бесконечные уровни вложенности с функциями обратного вызова, бедные по функционалу библиотеки и огромные цепочки вызовов, как в этом примере:
inputStream
// Decode to UTF8.
.transform(UTF8.decoder)
// Convert stream to individual lines.
.transform(new LineSplitter())
// Process results.
.listen((String line) {
print('$line: ${line.length} bytes');
},
onDone: () { print('File is now closed.'); },
onError: (e) { print(e.toString()); });
У меня много знакомых работало в EA (их офис буквально в паре кварталов от офиса, где я сейчас работаю). То, что описали для тестеров, практически один в один совпадает с ситуацией для программистов — контракты, бешеная загрузка, плохое управление. Зарплаты правда повыше, конечно. Но с точки зрения экономики это объясняется очень просто — оффлайн-игры живут очень недолго, соответственно, заработать прибыль можно только в первые дни и месяцы продаж. Поэтому лучше вложиться в маркетинг, продать как можно больше копий быстро, и «после нас хоть потоп». Вылизывать игру, которая проживет пару месяцов, просто реально нет смысла.
Онлайн-игры — это другой разговор, они живут намного дольше, но и тестирование там другое. Как минимум, есть публичное бета-тестирование. Лично мне кажется, что там ситуация получше, и у меня сложилось впечатление, что эти интервью брались в основном у тестеров оффлайн-игр.
Горы и лыжи в самом Ванкувере (точнее, в Северном Ванкувере), 20 минут езды из даунтауна. Тахо — это немного другое, я бы не сравнивал, и там всегда все забито (постояв там в пробке полтора часа я бы туда больше ни одним колесом) :)
Мне кажется, что столько букв было использовано, чтобы скрыть факт нелогичности перехода. JS не был создан «для интернета», он был создан в войне браузеров за 10 дней, чтобы обеспечить какую-то конкуретноспособность для компании Netscape. Ian скорей всего придумал оправдания для самого себя и поэтому написал такой большой пост, чтобы еще больше убедить себя, что он сделал правильный выбор.
Думаю, Lua. Мне очень не нравятся языки программирования со слабой типизацией (навскидку Lua, JavaScript, Basic, PHP), но просто особо нет выбора. Собственно, Python и был выбран изначально, потому что это полноценный язык программирования с большой библиотекой, а не набор костылей как PHP или «найди-ошибку-в-ворохе-кода-потому-что-я-неявно-привел-число-в-строку» JS/Lua. Но в конечном счете именно производительность оказалась решаюшим фактором, поэтому сейчас мы делаем минимальную работу на серверной стороне, и больше перекладываем на браузер (отдаем JSON, а всем рендерингом занимается JS).
2.7+ парсит pyconfig.h при запуске, что замедляет запуск и требует наличия этого файла (а он весит около 100кбайт) на запускающей платформе (http://bugs.python.org/issue9878). В 3.3+ они это пофиксили, но переходить на тройку мы вообще пока не можем, т.к. она требует обновленное ядро Linux и сопутствующих библиотек.
Я в команде разработки веб-интерфейса к встраиваемым системам. Использовать python не самая удачная идея, но это то, с чем приходится работать. Очень много проблем с производительностью и потреблением памяти. Я надеялся на PyPy, когда делал исследования в области улучшения производительности, но он себя показал не с лучшей стороны. Обходные пути есть, и использовать PyPy все-таки можно, но это только в далекой перспективе. К сожалению, когда это перспектива придет, уже не надо будет заботиться о производительности, т.к. все старые модели больше не будут поддерживаться.
Судя по всему это и есть андроид (и естественно, закрыли сырцы чтобы никто не смог подтвердить догадку на 100%, но рано или поздно это откроется, т.к. им придется открыть API). Остается только один вопрос — почему они не назвали его Chindroid или Anchina?
PyPy никогда не станет будущим (по крайней мере еще с десяток лет) питона по двум причинам, они еще косвенно были озвучены GvR (см. ссылку ниже):
— потеря совместимости с расширениями, написанными на Си (которые используют CPython API). Проблема думаю решается (перекомпиляцией и/или предоставлением совместимого API), но пока она существует.
— JIT имеет безумно долгое время запуска. Это обсуждалось на форумах PyPy, но они непреклонны, и сказали, что просто надо использовать долгоиграющие процессы.
К сожалению, скорость запуска еще очень важна, особенно для встраиваемых платформ. Несмотря на то, что по ссылке выше сказали, что скорость запуска соразмерима, это не правда. Я проводил собственные эксперименты с нашим оборудованием для бюджетного сектора (соответственно самые дешевые модели с самыми медленными процессорами ARM и без SSD), скорость запуска скрипта CPython — около 300-500 мс, PyPy — 2+ сек. Да, поддержка ARM в PyPy не особо, сами процессоры ARM не такие уж шустрые, плюс как я уже отметил, можно использовать демоны, но факт остается фактом. Опять-таки, несмотря на заявления разработчиков PyPy, он потребляет больше памяти (по-крайней мере, для специфических задач, как мелкие скрипты или CGI).
Сейчас CPython — более оптимизированное и компромисионное решение. Начиная с 2.7 они правда сделали громадную глупость, из-за которой мы пока тоже не можем на него перейти, но это не имеет отношения к PyPy.
Аналогично. Когда начались разговоры про проверки на лицензионность ПО, перешел на Линукс, как и многие мои знакомые. Для абсолютного большинства всех людей кого я знаю, причина ухода с winamp-а был переход на Линукс. Странно, что в опросе нет такой опции.
Да, и «пять лет назад» — это как-то маловато. Я и пять лет назад им уже не пользовался, потому что больше не работал в Windows.
Для казуального же игрока в целом играть dps намного проще, т.к. он может полностью игнорировать других игроков (не надо никого лечить, следить кого атакует босс и т.п.). Обращаю внимание на «может», это не значит что этого делать на надо, обычно это плохие игроки, но их не мало. В этом плане даже есть юмористический туториал: www.swtor.com/community/showthread.php?t=671988
Например — отказ от троицы tank-healer-dps (по такому же пути пошел SWTOR и думаю другие игры, не особо много играю чтобы знать). Причина простая — играть танком или целителем требует определенных навыкой, знаний и просто ответственности (которую по понятным причинам большинство брать не хочет). Соответственно, если у игрока класс DPS (и это абсолютное большинство, ибо самое простое), ожидание в очереди на инстанцию может занять часы, которых у них нет. (Легко подтвердить просто погуглив «dps queue time»).
В итоге много игр в процессе портирования для Северной Америки уменьшают свою сложность. Хороший пример — онлайновые игры в процессе эволюции которых разработчики уменьшали сложность все больше и больше (WoW, SWTOR, TERA etc). Я не говорю хорошо это или плохо, просто это факт, подтверждение которому можно найти на многих форумах, обсуждающих сложность игр и как под давлением большинства разработчики уменьшают сложность.
— животные на трассах (одна из самых частых причин аварий). Это даже тяжелее предугадать, чем поведение пешеходов, потому что скорости не сопоставимы с городскими
— двухполосные дороги много сотен километров длиной. Это значит, что будут обгонять и подрезать.
— black ice
— сильные ветра, фуры реально сдувает на другую полосу (Юта, официальный лимит скорости 135км/ч, так что все ездят 140-150, а ветра там ого-го, даже мой небольшой SUV сдувает)
— мощные ливни, при видимости буквально на 20 метров вперед
Все это решаемо с помощью соответствующих алгоритмов, но тогда фуры будут ездить очень медленно, и это означает, что нам, водителям обычных машин, придется еще тяжелее, т.к. придется делать больше обгонных маневров, да и думаю, что транспортным компаниям это тоже не особо понравится, что перевозка будет занимать намного больше времени.
— использовать исключения только для исключительных ситуаций, а не для логики. Например, правильно — проверить существование файла и открывать его, иначе писать сообщение об ошибке (для ситуаций, когда файл может не существовать на диске, например, если мы используем данные, введенные пользователем). Неправильно — сразу пытаться открыть файл, и проверять существование файла обработчиком исключений. Конечно, это очень соблазнительно — все сконцентрировать в одном месте, однако это чревато для сопровождения, потому что будущие разработчики могут подумать, что в данной функции всегда предполагается существование файла. То же самое касается проверки кодов ошибок — если проверка является частью логики (например, для программирования OpenSSL это единственный вариант), тогда надо ее использовать. Если нет — тогда позволять возникать исключениям.
— исключения должны перехватываться только там, где мы знаем, что с ними делать. Писать в лог только для того, что бы что-то написать практически бесполезно, и в основном используется только для отладки. Правильное решение — это выкидывать исключения наверх до тех пор, пока мы не сможем сделать что-то полезное с ними. Например, мы ничего не сможем сделать с исключением «метод не найден» (потому что это косяк программиста), но мы сможем что-то сделать с исключением «нехватка памяти» (например, выгрузить что-то из памяти, освободить кэши, но для этого надо чтобы менеджер кэшей получил это исключение). Для кодов ошибок это не так тривиально, поэтому иногда приходится создавать собственную иерархию исключений.
Теперь конкретно по примерам Android NDK — изначально исключения не поддерживаются, надо специально менять mk-файлы. Также в основном примеры для C, в котором нет исключений. Проверка ошибки в вышеприведенном примере в идеале не нужна, вы правильно отметили, однако она нужна для отладки и в целом для облегчения жизни программистов: JNI — не самая удобная платформа для взаимодействия Java с native-кодом, особенно учитывая магию типа названий native-функций Java_<class_path_goes_here>_<method_name_goes_here>.
Позвольте отметить пару вещей по самой статье. Во-первых, мне кажется, было бы лучше убрать упоминание о firebug-е, все современные браузеры имеют встроенные Developer Tools. Далее, Dart и Coffeescript — не самые лучшие альтернативы JavaScript. Думаю, они в конце-концов тоже умрут, т.к. никаких реальных революционных изменений они не приносят, синтаксис так себе, и в целом мое личное впечатление, что я бы не хотел программировать на этом — все те же бесконечные уровни вложенности с функциями обратного вызова, бедные по функционалу библиотеки и огромные цепочки вызовов, как в этом примере:
Онлайн-игры — это другой разговор, они живут намного дольше, но и тестирование там другое. Как минимум, есть публичное бета-тестирование. Лично мне кажется, что там ситуация получше, и у меня сложилось впечатление, что эти интервью брались в основном у тестеров оффлайн-игр.
Я в команде разработки веб-интерфейса к встраиваемым системам. Использовать python не самая удачная идея, но это то, с чем приходится работать. Очень много проблем с производительностью и потреблением памяти. Я надеялся на PyPy, когда делал исследования в области улучшения производительности, но он себя показал не с лучшей стороны. Обходные пути есть, и использовать PyPy все-таки можно, но это только в далекой перспективе. К сожалению, когда это перспектива придет, уже не надо будет заботиться о производительности, т.к. все старые модели больше не будут поддерживаться.
— потеря совместимости с расширениями, написанными на Си (которые используют CPython API). Проблема думаю решается (перекомпиляцией и/или предоставлением совместимого API), но пока она существует.
— JIT имеет безумно долгое время запуска. Это обсуждалось на форумах PyPy, но они непреклонны, и сказали, что просто надо использовать долгоиграющие процессы.
Более детально это обсуждалось на Stack Overflow: stackoverflow.com/questions/12867263/why-wasnt-pypy-included-in-standard-python
К сожалению, скорость запуска еще очень важна, особенно для встраиваемых платформ. Несмотря на то, что по ссылке выше сказали, что скорость запуска соразмерима, это не правда. Я проводил собственные эксперименты с нашим оборудованием для бюджетного сектора (соответственно самые дешевые модели с самыми медленными процессорами ARM и без SSD), скорость запуска скрипта CPython — около 300-500 мс, PyPy — 2+ сек. Да, поддержка ARM в PyPy не особо, сами процессоры ARM не такие уж шустрые, плюс как я уже отметил, можно использовать демоны, но факт остается фактом. Опять-таки, несмотря на заявления разработчиков PyPy, он потребляет больше памяти (по-крайней мере, для специфических задач, как мелкие скрипты или CGI).
Сейчас CPython — более оптимизированное и компромисионное решение. Начиная с 2.7 они правда сделали громадную глупость, из-за которой мы пока тоже не можем на него перейти, но это не имеет отношения к PyPy.
Да, и «пять лет назад» — это как-то маловато. Я и пять лет назад им уже не пользовался, потому что больше не работал в Windows.