проблема золотой лихорадки не в том, что кто-то плохо копает, а в том, что люди выкупали участки земли с неизвестными данными. На этом участке могли оказаться самородки или жилы — а могли не оказаться. Могло не хватить сил найти их (если участок был большим или «ничейным»)
другими словами «золотая лихорадка» — это чистая лотерея с геологией (если ты не геолог-разведчик, прошедший эту долину в прошлые сезоны с оплаченной кем-то экспедицией)
Пока очень тяжело представить, зачем будет нужен такой API — и при каких условиях такого же эффекта нельзя будет добиться стандартными картинками.
Опыт разработки игр показал мне, что если есть два варианта — «рисовать за счет кода» и «выводить готовую картинку» — практически всегда лучше будет второй вариант. Рисование за счет кода хорошо только для динамических, меняющихся условий — для самой игры в целом, к примеру.
// Что мы реально подразумеваем под исследованиями, и как это помогает получать информацию для понимания вещей?
Модели, позволяющие описывать и предсказывать поведение объектов и систем наиболее удобным способом.
К примеру, алхимия. При всем уважении к её наследию, её базовые модели так и не смогли доказать свою работоспособность.
Или вот система эпициклов Птолемея. Хорошее, рабочее знание, позволявшее действительно рассчитывать орбиты планет. Но! Давалось это ценой таких адских вычислений, что система Коперника, даже если бы она была абсолютно неверна, была намного практичнее и удобнее для астрономических вычислений (потом оказалось, что она и совпадает с видимой реальностью)
В программировании есть похожий принцип — «ищите модели, которые упрощают и ускоряют код».
работая мобильным разработчиком и слушая разговоры других разработчиков, в том числе владельцев компаний, я заметил что цена мобильного приложения в оутсорсе для клиента начинается в среднем от минимум полмиллиона, а в среднем — миллион.
мне кажется, автор слишком ограничивает выбор. В небольших приложениях вроде мини-игр для хранения данных достаточно localStorage. Хотя это хранилище синхронное, оно очень быстрое и работа происходит в течение микросекунд даже на очень старых устройствах
Что касается поддержки — тут вступает в дело такой фактор, что если какой-то браузер не поддерживает localStorage, то у него все плохо и с поддержкой современных HTML5-игр.
да, то что даже при таком взрыве выжило 60 процентов — говорит очень в пользу безопасности дирижаблей. Жаль, что требования к инфраструктуре все еще остаются самым сильным сдерживающим фактором (как мне кажется)
// В языках с динамической типизацией одна и та же переменная может иметь разный тип
это да, от этого особенно часто страдаешь, работая с чужими библиотеками
вот на приеме от таких функций, любящих подсовывать разные типы объектов и надо ставить проверки — главное, что не во всех своих функциях писать
в JavaScript использование одного типа является крайне желательной практикой — это позволяет движку V8 проводить дополнительные оптимизации после «разогрева», да и уменьшает вероятность ошибок в коде из-за того, что вы описываете )
Null, None, null, undefined — все эти варианты возникают не сами по себе, а потому, что какие-то другие функции их возвращают, что тоже является слабым и спорным приемом программирования
Если использовать прием «не возвращать Null, None, null, undefined» — то и проверки не будут нужны так часто
В п.13 однозначо справедливым мне кажется только последнее замечание, с которого и надо было начинать — что reduce плох тем, что не обрабатывает массив, если он длиной в 1 элемент, а тупо возвращает этот элемент, если не указано initialValue
я полагаю и многие мои коллеги считали так же, что проверять входные данные во всех функциях — это антипаттерн, который ведет к раздуванию кода и проседанию перформанса. Этот антипаттерн будет особенно драматичен, если вы начнете рефакторить большую функцию, разбивая её на несколько меньших — получается, вам теперь и там нужно добавлять проверять входные данные.
проверять данные нужно в момент поступления их от пользователя и к пользователю — это да, это необходимо. Возможно, в ряде других случаев эта проверка тоже уместна — к примеру, при вращении катапульты в играх уместно ограничивать предельные значения углов поворота.
А если программист передает объект в функцию, в документации которой описан четко тип передаваемых аргументов — это не создатель функции виноват.
другими словами «золотая лихорадка» — это чистая лотерея с геологией (если ты не геолог-разведчик, прошедший эту долину в прошлые сезоны с оплаченной кем-то экспедицией)
Опыт разработки игр показал мне, что если есть два варианта — «рисовать за счет кода» и «выводить готовую картинку» — практически всегда лучше будет второй вариант. Рисование за счет кода хорошо только для динамических, меняющихся условий — для самой игры в целом, к примеру.
Модели, позволяющие описывать и предсказывать поведение объектов и систем наиболее удобным способом.
К примеру, алхимия. При всем уважении к её наследию, её базовые модели так и не смогли доказать свою работоспособность.
Или вот система эпициклов Птолемея. Хорошее, рабочее знание, позволявшее действительно рассчитывать орбиты планет. Но! Давалось это ценой таких адских вычислений, что система Коперника, даже если бы она была абсолютно неверна, была намного практичнее и удобнее для астрономических вычислений (потом оказалось, что она и совпадает с видимой реальностью)
В программировании есть похожий принцип — «ищите модели, которые упрощают и ускоряют код».
работая мобильным разработчиком и слушая разговоры других разработчиков, в том числе владельцев компаний, я заметил что цена мобильного приложения в оутсорсе для клиента начинается в среднем от минимум полмиллиона, а в среднем — миллион.
с помощью save scumming
а он показывает, что поддержка IndexedDB — даже хуже, чем localStorage
глобальная поддержка IndexedDB: 94.15 в лучшем случае
глобальная поддержка localStorage: 94.97%
но главный фактор конечно в том, что это инструменты для разных задач -localStorage достаточен для простых приложений
Что касается поддержки — тут вступает в дело такой фактор, что если какой-то браузер не поддерживает localStorage, то у него все плохо и с поддержкой современных HTML5-игр.
это было реализовано не везде
это да, от этого особенно часто страдаешь, работая с чужими библиотеками
вот на приеме от таких функций, любящих подсовывать разные типы объектов и надо ставить проверки — главное, что не во всех своих функциях писать
в JavaScript использование одного типа является крайне желательной практикой — это позволяет движку V8 проводить дополнительные оптимизации после «разогрева», да и уменьшает вероятность ошибок в коде из-за того, что вы описываете )
Если использовать прием «не возвращать Null, None, null, undefined» — то и проверки не будут нужны так часто
надо брать все, изложение у них разное, будет лучше усваиваться )
можно постепенно подниматься по временной линии до 80х
только избегайте книги «Как стать гением» от Альтшуллера — она и не про ТРИЗ, и не про то, как стать гением
я полагаю и многие мои коллеги считали так же, что проверять входные данные во всех функциях — это антипаттерн, который ведет к раздуванию кода и проседанию перформанса. Этот антипаттерн будет особенно драматичен, если вы начнете рефакторить большую функцию, разбивая её на несколько меньших — получается, вам теперь и там нужно добавлять проверять входные данные.
проверять данные нужно в момент поступления их от пользователя и к пользователю — это да, это необходимо. Возможно, в ряде других случаев эта проверка тоже уместна — к примеру, при вращении катапульты в играх уместно ограничивать предельные значения углов поворота.
А если программист передает объект в функцию, в документации которой описан четко тип передаваемых аргументов — это не создатель функции виноват.
Предыдущая версия остается на сайте на всякий случай, ссылка в статье обновлена
словарь также немного почищен