Так и есть. В примере в статье функция ожидает получить конструктор, а не экземпляр. Поэтому в качестве типа указывается конструкция typeof , которая указывает на потребность получения конструктора класса, а не его экземпляра. Подробнее можно почитать об этом здесь
JSDoc сильно ограничен при сравнении с типизацией typescript. С помощью JSDoc нельзя сделать обобщенные типы, например. Если в двух словах, typescript позволяет очень широко охватить все возможные конструкции кода, что избавит вас от наиболее типичных ошибок, которые могут возникнуть без строгой типизации.
Простой пример: вы удалили функцию из объекта, а она используется по всему коду. Если вы внимательны, то пробежитесь по всем местам (придется еще найти и отфильтровать похожие названия других объектов, может быть). Иначе же в runtime получите ошибку. И хорошо, если сразу после правки. А Typescript сразу укажет на эту ошибку. И это только одна полезность из сотни.
Такой сервис будет очень полезен аналитикам, которые работают с Enterprise платформами анализа данных. Они не программисты, регулярки писать не умеют, но им надо. Отправил ссылку на сервис нашим.
В любом брокере. Можно даже с левериджем, благо скачки позволяют.
Плюсом:
1. Nintendo выпустила новую приставку формата iPad+джойстик и там будет Nvidea.
2. У них итак 70% рынка,
3. У AMD нет ни p/e, ни дивидендов, Nvidea — есть.
На этом фоне любопытно наблюдать за акциями NVIDEA. Они за год поднялись всего-то на 100 с небольшим процентов (до этого лет 10 находились на одной средней планке): https://www.google.com/finance?cid=662925
Но мы то с вами понимаем, что это ралли только началось ;)
Работаю с кодовой базой на TS порядка 1000 000 строчек, опыт есть (все — клиентский код).
В ваших утверждениях есть ряд ошибок:
1. «Debug».
Не нужно настраивать дебаг в IDE, пользуйтесь встроенным в Chrome отладчиком и отлаживайте прямо TS с включенными sourcemaps. Так правильнее, потому что IDE может потребоваться сменить, а браузер всегда и везде одинаков. По опыту, опять же, удобнее и быстрее в браузере отлаживать.
2. «А вдруг умерет?»
Нет. Один из принципов TS — не расходиться с будущим JS. По факту TS просто имплементирует будущие возможности JS, позволяя уже сейчас их использовать в браузерах (даже Async/await). Т.е. если и умрет, то только вместе с JS.
В конце концов, можете помочь его популяризации: документация на github на русском.
Мужики! Хелп! Я работаю в очень многообещающей компании, но они тут используют StarTeam CVS от Borland. (кто-нибудь про нее вообще слышал?). Как наставить компанию на путь истинный?
Typescript — это было бы действительно здорово. Он очень мощный, но слишком медленный — компиляция и релоад больших проектов занимает килотонны времени. Наиболее популярная IDE для Typescript — Visual Studio. Если вы сделаете для нее плагин, то отбоя от желающих не будет: в последнее время он бьет по популярности другие компилируемые языки (гугл тренды). Со своей стороны могу заверить, что в моей компании 10 разработчиков, для которых точно купят лицензию на такой хороший продукт, но только под Visual Studio (сам проект на Typescript + ExtJS).
Здорово. Как-то я при чтении доки упустил этот момент.
Правда есть одна непонятная вещь: разработчики рекомендуют разделять сервера, в которых хранится постоянная информация и те, что используются в качестве кэша (чтобы не убивать нужную информацию). Но там есть такая опция «volatile-lru» — удаляет по алгоритму LRU только ключи с TTL, поэтому можно в принципе кэш писать с TTL, и не разделять логически с постоянной информацией?
Я не понимаю, почему во всех статьях про Redis пишут, что это отличная замена Memcached и он хорош в качестве основного хранилища данных?
Во втором случае Redis ведь при исчерпании памяти свопится на диск, что ведет к тормозам. А если докупать сервера, то сравним объем HDD и RAM, из-за чего Redis потребует больше серверов для хранения.
В первом случае у Memcached есть неоспоримое преимущество: при исчерпании памяти для кэша автоматически удаляются самые старые кэши. Redis же в этот момент опять свопится на диск.
«10 коппеек в месяц» — этим. Считаю, что это важный пункт. Безвозмездный фандинг хорош только в случае проектов общественных (например, Роспил). Здесь форма сотрудничества иная: фонд Хабра имеет долю в проекте, получает дивиденды и распределяет их пропорционально инвестициям.
Идея прекрасна. Когда инвестор специалист в области, он лучший.
Все разработчики жалуются, что в книге мало технологий. Но, будь они там, её купили бы 2-3 тыс. кодеров. Из них 1 тысяча по незнанию критиковала тех. решения, другая — поражалась их превосходству над остальным вебом. Ни один не заразился бы примером.
Книга в ее настоящем виде дает лишь вдохновение в чистом виде. И, поверьте, этого достаточно, чтобы сотни тысяч пошли в темный лес технологий с верой в успех. Потому что, если вы стоите в темном лесу, даже самый четкий план к выходу не поможет вашим глазам его увидеть. Но вот факел, пылающий воодушевлением, укажет путь. Большое спасибо Н.Кононову за него.
Простой пример: вы удалили функцию из объекта, а она используется по всему коду. Если вы внимательны, то пробежитесь по всем местам (придется еще найти и отфильтровать похожие названия других объектов, может быть). Иначе же в runtime получите ошибку. И хорошо, если сразу после правки. А Typescript сразу укажет на эту ошибку. И это только одна полезность из сотни.
Плюсом:
1. Nintendo выпустила новую приставку формата iPad+джойстик и там будет Nvidea.
2. У них итак 70% рынка,
3. У AMD нет ни p/e, ни дивидендов, Nvidea — есть.
Но мы то с вами понимаем, что это ралли только началось ;)
В ваших утверждениях есть ряд ошибок:
1. «Debug».
Не нужно настраивать дебаг в IDE, пользуйтесь встроенным в Chrome отладчиком и отлаживайте прямо TS с включенными sourcemaps. Так правильнее, потому что IDE может потребоваться сменить, а браузер всегда и везде одинаков. По опыту, опять же, удобнее и быстрее в браузере отлаживать.
2. «А вдруг умерет?»
Нет. Один из принципов TS — не расходиться с будущим JS. По факту TS просто имплементирует будущие возможности JS, позволяя уже сейчас их использовать в браузерах (даже Async/await). Т.е. если и умрет, то только вместе с JS.
В конце концов, можете помочь его популяризации: документация на github на русском.
Ролик
Правда есть одна непонятная вещь: разработчики рекомендуют разделять сервера, в которых хранится постоянная информация и те, что используются в качестве кэша (чтобы не убивать нужную информацию). Но там есть такая опция «volatile-lru» — удаляет по алгоритму LRU только ключи с TTL, поэтому можно в принципе кэш писать с TTL, и не разделять логически с постоянной информацией?
Во втором случае Redis ведь при исчерпании памяти свопится на диск, что ведет к тормозам. А если докупать сервера, то сравним объем HDD и RAM, из-за чего Redis потребует больше серверов для хранения.
В первом случае у Memcached есть неоспоримое преимущество: при исчерпании памяти для кэша автоматически удаляются самые старые кэши. Redis же в этот момент опять свопится на диск.
Идея прекрасна. Когда инвестор специалист в области, он лучший.
Все разработчики жалуются, что в книге мало технологий. Но, будь они там, её купили бы 2-3 тыс. кодеров. Из них 1 тысяча по незнанию критиковала тех. решения, другая — поражалась их превосходству над остальным вебом. Ни один не заразился бы примером.
Книга в ее настоящем виде дает лишь вдохновение в чистом виде. И, поверьте, этого достаточно, чтобы сотни тысяч пошли в темный лес технологий с верой в успех. Потому что, если вы стоите в темном лесу, даже самый четкий план к выходу не поможет вашим глазам его увидеть. Но вот факел, пылающий воодушевлением, укажет путь. Большое спасибо Н.Кононову за него.