• Вопросы на собеседовании по javascript
    +1
    Ваш вопрос звучал без уточнений:
    можно пример функции, которая не является «классом», если ее вызвать через new?
    И таких функций много в JS, которые нельзя использовать в качестве конструктора.
    Если не хочется, чтобы ф-ю вызывали в качестве конструктора, можно сделать и так:
    function F () { if (this instanceof F) throw TypeError('F() is not a constructor'); }
    

    isNaN — это функция не JavaScript, это функция на языке реализации движка JavaScript, а это две большие разницы. Так как она не реализована на JavaScript, ее свойства нельзя отнести к особенностям и возможностям языка
    Допустим я понял, что вы имели в виду в первом предложении. Но вот выделенное мне не очень ясно. Можно ли сказать тоже самое про остальные объекты/функции, описанные в спеке?

    Правильным ответом с вашей стороны должна была стать стрелочная функция:
    Ну вот видите, сами ответили на свой вопрос. Раз знали ответ заранее, значит решили потроллить автора :)

    Хотя про ES6 не было речи, стрелочная функция — хороший пример и хорошая отправная точка для обсуждения с кандидатом ES6 (и ES7, если интересуется будущим языка).

    function F() {}
    F.prototype = null;
    console.log((new F).__proto__ instanceof Object); // false
    

    instanceof ищет прототип конструктора в цепочке прототипов объекта, сам же прототип в примере выше будет объектом:

    typeof (new F).__proto__; // "object"
    Object.prototype.toString.call((new F).__proto__); // "[object Object]"
    


    Object.create(null) — особенный случай.

    console.log(Object.create(null).__proto__ instanceof Object); // false
    
    Использовать аксессор Object#__proto__ в этом случае не корректно, доступа к нему там просто нет. Поэтому и undefined. И мы всё же обсуждаем создание объектов конструкторами, поэтому правильнее:

    function F () {}; F.prototype = Object.create(null);
    var proto = Object.getPrototypeOf(new F);
    typeof proto; // "object"
    Object.prototype.toString.call(proto); // "[object Object]"
    


    F.prototype = function() {};
    console.log(typeof (new F).__proto__); // "function"
    
    Вы забыли про (new F).__proto__ instanceof Object; // true

    (кстати, вспомнил ещё вопрос из этой серии: объяснить почему
    Object instanceof Function === Function instanceof Object; // true)

    Неверные объяснения, как я понимаю, тоже являются уловкой и проверкой на внимательность самих проверяющих — если проверяющий согласился с таким объяснением, значит сразу в отбраковку обоих :)
    Меня бы ответ автора на 5-й вопрос устроил. Я бы, пожалуй, уточнил, что надо поменять (используя прототип), чтобы сравнение было истинным. Впрочем, с многими остальными ответами не всё так плохо. С ремаркой: если не придираться к терминологии, некоторым пробелам, путанице с неявным преобразованием (спеку почитает). Мы же понимамаем, что эти вопросы не для сеньора с серьёзным практическим/теоретическим бэкграундом? :) Хотя, как я уже писал и соглашусь с остальными, такого рода вопросы слишком оторваны от реальных задач и более уместны для квизов (just for fun).

    Ну и поясните пожалуйста, почему (с практической т.з., т.е. создания объектов)
    говорить, что «свойство prototype работает только на конструкторах» — глупота.
  • Вопросы на собеседовании по javascript
    +2
    Если все «классы» — это функции, можно пример функции, которая не является «классом», если ее вызвать через new?
    isNaN.

    prototype функции — это Object
    Да?
    По вашему примеру:
    function F () {}; F.prototype = ['bar'];
    typeof F.prototype; // "object"
    F.prototype instanceof Object; // true
    

    ;-)

    Это просто функция. Если вызвать ее, как Array.prototype.push('foo'), ничего хорошего не случится. Чтобы быть «методом», ее нужно вызывать, как [].push('foo'). Хотя с точки зрения системы типов это все равно функция, в prototype — это пока не метод.
    А если вызвать Array.prototype.push.call([], 42)?

    А ваш же тест 2.2 говорит, что равны. Да, говорить, что «prototype работает только на конструкторах» — глупота. Если заменить объявление на s = function() {}; s.prototype.foo = 42;, s.foo не станет равно чему-то осмысленному.
    Вы наверное не поняли, вопрос был на внимательность; в идеале, если кандидат сразу отметит, что определять свойство prototype в том объекте нет никакого смысла и это уловка.

    Переменная x была создана в глобальном контексте — т.е. она член window. При запуске функции this = window. То есть это условие верно.
    По вашему, var lolka = 123; console.log(window.lolka); выведет 123? Я вас разочарую :)
    Выполните свой код в глобальном контексте.

    P.S. Вопросы, имхо, больше для Quiz'а, а не для собеседования.
  • Собеседование на должность JavaScript разработчика
    0
    Ещё вариант, без join & split:

    Скрытый текст
    Array.apply(null, Array(10)).forEach(function (_, i) { console.log(i); });
    
  • Форматирование цены, или как я input переписывал
    +2
    Это к тому, что не надо за пользователей решать, как им будет удобнее путём запрета почти всего, к чему они привыкли при редактировании. Поддерживаю то, что не надо блокировать paste и тем более contextmenu.
  • Форматирование цены, или как я input переписывал
    +2
    Есть один сервис приёма платежей, в котором сделали всё, чтобы пользователю было неудобно вводить номер карты: разделили на четыре инпута и запретили paste. Да ещё и добавили с полдюжины ненужных обязательных полей, которые каждый раз надо заполнять заново.
  • Всё, что вы должны знать о прототипах, замыканиях и производительности
    0
    Небольшое уточнение: __proto__ — это геттер/сеттер в прототипе объекта (Object.prototype.__proto__), а не самого объекта.

    var o = Object.create(null);
    o.__proto__; // => undefined, потому что мы не имеем доступа к Object#__proto__
    // но
    Object.getPrototypeOf(o); // => null
    
  • Тест на крепкого JS программера
    0
    var make = (function () {
      var nums = [];
      return function add (n) {
        return typeof n === 'function'
          ? nums.reduce(n)
          : (nums.push(n), add);
      }
    })();
    
  • Разработка приложений для Chrome: обзор
    0
    Олег, несколько вопросов, по планам «когда» (ориентировочно), если есть такая инфа:
    1. Релиз Chrome Mobile Apps на андроид
    2. Dart VM в Chrome Apps
    3. Полная поддержка ES6 (destructuring assignment, fat arrow functions, «class» sugar etc.). Я понимаю, что это больше к v8 вопрос, но ФФ стэйбл уже давно это поддерживает. И хотелось бы уже это видеть в v8 хотя бы в packaged apps.
  • Habrastorage 2.0
    +5
    Согласен, аудитория продвинутая. Убрать кнопку «Загрузить файлы» и навесить клик на облако.
  • Горизонтальное масштабирование PHP приложений. Часть 1
    0
    Конечно, большинство бенчей — синтетика, имеющая мало общего с продакшном. На оф. сайте Редиса бенч показывает 75K rps. Да даже запас в 20К rps достаточно большинству проектов.

    По остальному, как видно, тюнинг одного только редиса тянет на отдельную тему.
  • Горизонтальное масштабирование PHP приложений. Часть 1
    +1
    Redis… в отличие от memcached поддерживает постоянное хранение данных, и более сложные типы данных. Redis не поддерживает кластеризацию, так что использовать его для горизонтального масштабирования несколько затруднительно

    В этих более сложных структурах и есть профит редиса. Во-вторых, видел бенчи редиса на commodity сервере в 300К RPS.

    Вообще, статья не зачёт. Дальше «а файлы требующие серверной обработки пусть отсылает тяжелому Apache» можно не читать. Где про FastCGI/FPM, HHVM, грамотный тюнинг сервера, бд, правильная архитектура приложений (в которой кэширование по-умолчанию)? — с этого надо начинать.
  • Дросселирование ввода на AngularJS с помощью debounce
    0
    $timeout это обычная обёртка над setTimeout (+Promise), коллбэк которого всё-равно вызывает $apply
  • Дросселирование ввода на AngularJS с помощью debounce
    +2
    По оптимизации я бы добавил вот ещё что: если приложение начинает разрастаться (сотни вотчеров), лучше автокомплит выделить в отдельный компонент (директиву) со своим скоупом и использовать $scope.$digest() (который обновит только скоуп компонента) вместо $scope.$apply(), который обновляет состояние всех скоупов, начиная с корня ($rootScope).
  • 45 Типсов-Триксов и Практик JavaScript
    0
    Object.create появился только в ES5. Знать как написать naive polyfill вполне полезно.
  • 45 Типсов-Триксов и Практик JavaScript
    0
    п. 20 не ошибочен. Автор говорит об удалении из массива, а не объекта. Конструкцию for (key in object) не используют для перебора массива.
  • Бенчмарк HTTP-серверов (С/C++) в FreeBSD
    –2
    Ну почему же громкие слова? Как раз-таки я посчитал ваше утверждение "Node.js — не хайлоад-решение" — весьма смелым. Я с этим не согласен и, уверен, парни из PayPal тоже. Нода не для тяжёлой логики (и вообще чего-либо CPU-intensive), это да.

    Ваша мысль понятна, для вас хайлоад определяется тяжеловестностью выполняемой логики (которую выполняют, как правило, бэкэнды). Это логично. Но вот возьмём два 8-ядерных commodity-сервера: на одном Java/C[++] обрабатывает какую-нибудь длинную очередь HD-видео от 100 клиентов, загружая под 100% все ядра; на другом крутится Нода с 7 форками (с лёгкой логикой, вроде отдачи из кэша), крутится хорошо, на 40K RPS, тоже загружая под 100% сервер. Первое — хайлоад (что очевидно), а второе тогда что, если не хайлоад?

    Как тогда, по-вашему, называть, допустим, отдачу статики 15 млн. пользователям ежедневно? Ну вот нету ничего тяжелого в проекте (к примеру всякого рода t.co/bit.ly, хостеры картинок и т.п.).

    То, что грамотное горизонтальное маштабирование позволяет использовать %language% — это понятно. Также понятно, что для тяжёлой логики есть JVM / .NET / компилируемые языки.

    Во-вторых, скорость работы и стабильность для конечного пользователя — критически важный показатель для такой системы как PayPal (всё-таки не хостинг картинок с котиками). Ежедневно через систему проходят платежи на сотни млн. $.

    Факт того, что PayPal переводит эту часть (фронты) на Ноду, вполне говорит нам, что она production ready && highload ready.
  • Бенчмарк HTTP-серверов (С/C++) в FreeBSD
    –1
    PayPal — хайлоад? Как прокомментируете перевод фронтов (для начала) с JVM на Node.js. Ещё из списка: Ebay's ql.io, Linkedin, Wallmart, Trello, Groupon и ещё. Что для вас хайлоад? Сотня млн. запросов в день, норм? А несколько сотен?

    П.С. Разница в 3х между, к примеру, nginx и node.js — всё-таки это как Формула 1 и, скажем, средний спорткар, но не троллейбус :).
  • Хватит быть милым и умным
    0
    Это конечно хороший паттерн (в определённых случаях), но он мало что изменит, если алгоритм неоптимальный (как в случае автора).
  • Хватит быть милым и умным
    +1
    Лично я не вижу ничего смешного в конструкции:
    proxy.guid = fn.guid = fn.guid || jQuery.guid++;

    Посмотрите на гитхабе код хотя бы топ-50 проектов на JS, везде есть специфичные для JS конструкции. Да к примеру connect, express, которые используются во многих хайлоад проектах. Или Kraken @ PayPal (который переводит все свои фронты с jvm на node.js).

    Ваши тесты — это сродне убрать соломинку из стога сена (в ущерб лаконичности) на фоне разницы минимум на порядок между ES5 Array[[prototype]] ф-ями forEach, map, reduce etc. и простым лупом. И что теперь, не использовать их?

    Я сначала хотел спросить, чего ради вы ратуете за отказ от сахара, но потом увидел
    2. Понятен абсолютному большинству программистов большинства популярных языков;
    Может тогда питонистам отказаться от лямбд? А что делать тем, кто пишет на Clojure? :)

    В каждом языке есть свои конвеции хорошего и понятного кода и желательно придерживаться в первую очередь их и только потом весьма абстрактной общей понимаемости.
  • Хватит быть милым и умным
    0
    Потому что, допустим, для поиска на клиенте по массиву в 30К+ городов есть смысл перенести поиск в воркер или использовать одно{двух}уровневый хэш или поиск чанками асинхронно (чтобы не блокировать UI) как фоллбэки. И это и есть своё кастомное решение, а для автокомплита по 100 тегам достаточно и

    return list.filter(function (item) { return item.indexOf(query) != -1; });
  • Хватит быть милым и умным
    0
    Автору следовало бы понять ещё на этапе выбора компонента, что для поиска совпадений по 26К городам надо писать свой поиск, а не пользоваться компонентом, предназначенным для общих случаев, поиска по небольшим массивам (тэги и т.п.).

    И поиск этот можно сделать как очень быстрым (поиск по 30К+ городам ~1—3 мс), так и не блокирующим UI (async или webworkers).

    Все дальнейшие выводы автора о языке и других компонентах основываются на не соответствии его ожиданий (очевидно, полагаясь на опыт в других ЯП), документации (которую довольно часто не читают) и особенностях (WAT?) JS.
  • Насколько долго можно делать браузерную игру, не имея огромного бюджета в кармане
    0
    Вы молодцы. Лишь очень немногие проекты, которые делаются на энтузиазме, доходят хотя бы до альфы (а это только начало).

    Присоединюсь к мнениям выше, что потрачено на проект 80 т.р. + 62.5 человекомесяца (10000/160) * некая усреднённая з/п. Конечно, это весьма условно и есть ещё много факторов, но это хотя бы даёт (в первую очередь вам) представление о затратах.

    Удачи в развитии проекта. Через тернии к звёздам.
  • Совершеннолетие JavaScript
    0
    Если не смотреть на конкретный пример выше, то перегрузка операторов для объектов может иметь вполне определённый профит. К примеру, в Дарте:

    class Point {
      num x, y;
    
      Point(this.x, this.y);
    
      operator +(Point point) => new Point(x + point.x, y + point.y);
    }
    


    ES7 WIP: Value Objects Operators Overloading
  • Совершеннолетие JavaScript
    +12
    … CoffeeScript. Последний уже начинает вытеснять JS

    Вы несколько преувеличиваете :)
  • Совершеннолетие JavaScript
    +2
    [slideshare] JS Responsibilities by Brendan Eich
  • Сделай свой AngularJS: Часть 1 — Scope и Digest
    0
    Отличный материал для понимания «магии» ангуляра (в первую очередь, принцип работы digest-цикла и вотчеров). В идеале, читать после начала работы с ангуляром, чтобы понимать о чём речь.

    Ждём продолжения.
  • Vanilla JS vs jQuery 2.0
    0
    забывая, что речь о jQuery 2.0.
    Версия мало имеет значения, главное — экосистема, стабильность, преемственность API и далее по списку в моём предыдущем комменте (уже 3-й раз повторил :)

    естественно, но вот код, который написан на нем, как правило, «хорошими знатоками» js… мягка говоря, качественным не назовешь.
    &
    Доводилось видеть… допускает ошибки в js
    Да всем, на всех языках программирования, доводилось видеть всякое. Это же не повод экстраполировать.

    В общем, вывод очевиден: дело-то совсем не в инструменте (jQuery), а в не очень опытных падаванах. Чем выше популярность языка, тем чаще встречается «всякое». Суть претензии к jQuery в том, что это «всякое» может вполне себе работать, но тут ведь только от падавана зависит желание учиться как делать правильно (и, в идеале, под присмотром коллег-мастеров).
  • Vanilla JS vs jQuery 2.0
    +1
    Да, и в контексте вашей версии истории, главный косяк-то в руководстве «аутсорс»-конторы, которое не сумело определить, что товарищ-то пока ещё не совсем опытный для позиции «ведущий фронтендер». Когда в проекте грамотный тимлид и ведущие по своей части, степень бардака резко снижается.
  • Vanilla JS vs jQuery 2.0
    +2
    Nice try.

    k12th всё правильно написал в комментарии выше. Это уже уровень стратегии развития проекта. Стабильность, популярность, экосистема, поддержка и кол-во спецов на рынке гораздо важнее сэкономленных килобайтов (тем более это всё относительно и со временем сойдёт на нет). Единственное, с чем соглашусь, что подключение увесистого jQuery UI ради одного компонента — моветон, если есть возможность найти аналогичный jQ/standalone-компонент.

    Далее вы начали уже мешать архитектуру, фреймворки и UI. А jQuery — это база для кросс-браузерного UI (не путать с jQ UI).

    Так что же теперь думает Ваня о своих чудесных предшественниках? и считает ли он их программистами?
    Если плагины хорошие, грамотно написаны и поддерживаются, то всё неплохо, как минимум. Гораздо хуже было бы, если
    drag & drop, слайдеры, скролеры, карусели, зумеры, табы, дейтпикеры, маски…
    представляли из себя велосипеды не самого лучшего качества, которые никто кроме самих авторов поддерживать не может (и уже не будет). Есть, конечно, вариант, что эти самописные компоненты будут грамотно написаны, оттестированы и заопенсорсены (+ появятся контрибьюторы, соответственно и поддержка). 1) Вопрос: сколько на это потребуется времени? (а время — деньги) 2) Вероятность такого поворота, в контексте вашей версии истории, близится к 0 (пока не придёт Ваня :).

    на профессиональном уровне освоил javascript на предыдущей работе, разбирается во многих его особенностях, отлично знает концепции многих фреймворков, из-за чего начал искоса поглядывать на jquery
    Никто из коллег фронтендеров не смотрит искоса на jQuery (бывают, конечно, споры / ворчание, но всё же...). Наоборот, все прекрасно понимают его вклад в развитие и аргументы, изложенные выше. Главное понимать, где его использование будет уместно, а где нет.

    Если веб-приложение тормозит, jQuery стоит в конце списка, где может быть проблема.

    P.S. Есть хорошее английское выражение — «It depends ...». Всё зависит от требований, проекта, браузеров, команды, сроков (!) и т.п. Если проект делается под нормальные браузеры и сроки вменяемые, сами с удовольствием и по возможности делаем standalone-компоненты, там где это уместно.

    Мне лично нравится концепт модульности небольших компонентов/либ проекта Component (что это такое, список плагинов, github) — своего рода unix-way для фронтенда (по большей части), но он пока только набирает обороты.
  • Vanilla JS vs jQuery 2.0
    +1
    1. var $ = document.querySelectorAll.bind(document) — сильно ограничен в возможностях, т.к. выборка будет всегда с корня; есть ещё такой вариант:
    var $ = Function.prototype.call.bind(HTMLElement.prototype.querySelectorAll);
    // use:
    var somediv = $(document.body, 'div')[10];
    var spans = $(somediv, 'span');
    

    2. jQuery силён своей экосистемой, поддержкой и стандартами. Время, когда большая часть браузеров будет нормальными, совсем скоро, соотвественно и ядро jQ будет весить совсем немного (как Zepto ±).
  • Опубликованы исходники эмулятора x86 на JavaScript
    +4
    Atwood's Law: any application that can be written in JavaScript, will eventually be written in JavaScript.
  • Что нас ждет в Microsoft Kinect 2.0?
    0
    Можно оценить по видео.
  • HeadHunter на Android: наконец-то!
    –2
    А вы не пробовали сделать на HTML5 стеке + какой-нибудь PhoneGap / Appcelerator? В этом случае убиваете 2-х зайцев: и мобильная версия сайта, и приложения могут выглядеть и работать почти одинаково. И стратегически выгодно, что разработкой и поддержкой занимается свой же отдел фронтенда.

    Хотя, конечно, ФБ недавно добавил ложки дёгтя со своим «HTML5 wasn't ready», но парни из Sencha приняли челлендж и сделали довольно шустрый HTML5-клиент.
  • Разработка ПО: факты против мифов
    +1
    Сколько книг написано и будет написано… основной сутью всё-равно остаётся, что во главе угла стоит человеческий фактор (peopleware), а инструменты/методологии вторичны.
  • Ещё один препроцессор для JavaScript
    +6
    Тогда посмотрите Typescript, он ES6-совместим, да собственно и сам ES6 не за горами (а в ноде с 0.11 с флагом --harmony — уже).

    Хотя опыт написания своего препроцессора со своей версией блекджека в любом случае останется полезным :)
  • Загрузка файлов в AngularJS
    0
    Специфика Angular UI позволяет юзать .value, потому что у него нет единого предопределённого дефолтного конфига, т.е. подразумевается, что разработчик определит ui.config в конфигурационной части приложения (где-нибудь рядом с app.config).

    В вашем случае, нельзя никак поменять часть дефолтного конфига (ну кроме как в исходнике :). Достаточно поменять .value на .constant, чтобы была возможность редактировать конфиг oiFileConfig на этапе конфигурирования в app.config (в котором доступны только провайдеры и константы).

    Ещё было бы неплохо вынести тексты ошибок в сам конфиг, чтобы можно было менять их.

    В остальном, спасибо за модуль — определённо в закладки ;-)
  • Распространенные заблуждения в управлении проектами
    0
    Не вижу связи с модой. 95-й, это не 82-й. Конечно фактор «быть в то время и в том месте» играет немаловажную роль. Но и немаловажную роль играет кто и как делает проект: не только техническую часть, но и маркетинг, продукт, стратегия, дальновидность инвесторов. Яху был основан в 95-м, Гугл в 98-м, ФБ в 2004.
  • Распространенные заблуждения в управлении проектами
    0
    До Фейсбука ничего подобного не было в англоязычном сегменте сети

    Classmates.com — 1995 год. Хотя это и аналог одноклассников, никто им не мешал ещё занять и нишу универов (за 9 лет-то).
    Поэтому таки реализация — всё.
  • Сравнение производительности JS-библиотек
    0
    Почему для тестов не использовали проверенный годами benchmark.js (в основе jsperf.com)?

    Во-вторых, использовать методы getElements{ByTagName, ByClassName /*, etc */} можно просто ради интереса (зная что они возвращают «live» NodeList/HTMLCollection, которые малопригодны для чего-то сложнее простых операций выборки/перебора и своих велосипедов). Но тогда где querySelector{All}?

    На данный момент, большинство либ и селекторных движков по типу jQuery работают по одинаковому принципу ± свои оптимизации. Если мы видим значительную разницу в скорости (порядки), значит используются свои обёртки, другие подходы (например просто ф-я, которая парсит селектор, выбирает и возвращает тот же live NodeList/HTMLCollection) или недопустимые хаки (модификация оригинального DOM), но тогда мы теряем в удобстве и скорости разработки, которую даёт jQuery, что гораздо важнее.
  • Элон Маск скоро представит проект новой системы пассажирских перевозок Hyperloop
    +1
    Мне кажется в переводе и источнике некорректные данные, в том числе и видео (автор видео какой-то NMANewsDirect, не ясна связь с проектом Hyperloop).
    Вот статья в NY Times (15.07.2013), в которой цитируется слова Элона Маска (сентябрь 2012) о поездке из Сан-Франциско в Лос-Анджелес за 30 минут, что говорит о скорости ~1200 км/ч (между СФ и ЛА ~600 км).

    Потом, опять же, из статьи можно предположить, что стоимость линии от ЛА до НЙ (4700км) будет начинаться с 47+ млрд. $ (ЛА -> СФ (600км) — 6 млрд. $). Относительно окупаемости: штат Калифорния прорабатывает план по ЖД-линии между ЛА и СФ на 60 млрд. $ (и это скорее всего из бюджета только штата), а уж соединение восточного и западного побережья вполне реально будет поддержано и на федеральном уровне.