На сколько мне известно, использование id или class влияет на поиск элемента в DOM и соответственно на производительность. Так как предполагается, что id уникален в пределах документа, то при поиске по id, браузер останавливает поиск как только находит нужный элемент, а при поиск по классу он производит поиск пока не проверит все элементы в DOM, даже если нужный элемент был единственный, и найден в самом начале. Поэтому использовать нужно и то и другое, в зависимости от ситуации.
Вот например: EmberConf 2015 — Видео плейлист с конференции EmberConf 2015.
Уже ясно что это видеоматериал, и если ты, в данный момент читаешь со смартфона, то не очень удобно будет его просматривать
P.S. Там написано, что это видео, не обратил внимания. Но идея все равно хорошая )
Предлагаю помогать автору писать комментарии к тем или иным статьям/библиотекам и т.п., на которые ведут ссылки. Многие ведь заходят и читают что там, и после этого вполне смогут оставить свое мнение в личку автору. Это снизит нагрузку с автора, а остальным читающим действительно легче будет ознакамливаться с материалом по комменту к ссылке.
Спасибо за минусы, приму их как знак внимания. Обосную тем кому все таки интересно. Во-первых плохой тон обращаться к свойствам напрямую — это одно из фундаментальных правил программирования. Например, тут или тут тут мнение авторитетов. Во-вторых, работать можно не только в одиночку — и когда работаешь в команде, то сложно отвечать и контролировать чужие действия, а если команда находится в разных городах, а то и часовых поясах, то еще сложнее. Поэтому если ты используешь чье-то свойство, то лучше избегать прямого обращения к нему, а пользоваться геттерами и сеттерами, потому-что «хозяин свойства» в любой момент может что-то изменить или зарефакторить и в этом случае, он не обязано спрашивать чье-то мнение. Сюда же можно добавить то, что даже когда сам начинаешь проект, то должен понимать, что статика может меняться много-много раз, и для того чтобы не править всё и везде, легче править в двух местах — в геттере и сеттере.
//где-нибудь в базовой вьюхе функция которая является и сеттером и геттером.
frg: function (name, el) {
!this.domElements && (this.domElements = {});
return el ? (this.domElements[name] = el, el) : this.domElements[name];
}
// Использование наследуемых вьюхах:
// в сеттер надо передать два параметра: название и сам элемент.
// сеттер так же возвращает закешированный элемент
this.frag('my-block', this.$('#my-block')).css({display: 'block'});
// геттер получает один аргумент и возвращает из кеша элемент
this.frag('my-block').css({display: 'block'});
Иногда статичное свойство может измениться, и тогда придется искать его, и править по всему проекту. А в случае с методом, придется изменить свойство только внутри метода, который его возвращает.
Поскольку мир IT настолько велик и разнообразен — то придумывать индивидуальные задачи порой очень трудно
Причем тут мир IT? Вы работаете в конкретной области, и ищите конкретного специалиста, который будет выполнять конкретные задачи. Придумать задачу, когда все конкретизировано проще паренной репы. Если вы засечете время, то заметите, что на придумывание задания, которое соответсвует этой конкретной работе, уйдет не более 15 минут, скорее даже меньше. Но это избавит от утомительных собеседований, которые на 80%-90% трата времени.
Но поскольку с данной библиотекой мне работать не приходилось, касательно нее я ничего спросить не мог
А зря, бегло глянув в код, можно понять как человек работает, и если код визуально понятный, то можно вникнуть и понять ход мысли программиста.
На мой взгляд функции на бумаге и тому подобное позволяет интервьюеру найти с вами общий язык
С чего вы взяли что вы находите общий язык? Вы часто интересуетесь о том, удобнее ли соискателю написать в IDE или на бумаге, и оба соглашаетесь в том, что на бумаге программировать куда удобнее?
В общем не думаю, что вопросы такого типа должны сильно смутить квалифицированного разработчика
Но лучше, наверное, спросить квалифицированного специалиста, не смущают ли его такие вопросы, а не думать за него.
Вы так и не согласились с тем, что как и другие специалисты, интервьюверы тоже бывают плохие и хорошие, подготовленные и не подготовленные. И как и других специалистов, плохих интервьюверов гораздо больше чем хороших.
P.S. У меня к соискателям еще одно требование: рассказать смешной анекдот или шутку. Но это так, чтобы понять, как в коллектив вольется )
Хочется отметить, что провальные собеседования не заслуга одних лишь соискателей. Если бы собеседующих можно было категоризировать как разработчиков, то бОльшая часть интервьюверов была бы джуниорами, а то и хуже. Скажу от имени более-менее квалифицированного специалиста, который был по обе стороны барикад: это оскорбительно, когда по дороге на интервью ты собираешься с мыслями о том, как проектировать системы, как оптимизировать узкие места, как граммотно организовать работу и как управлять командой разработчиков, приезжаешь, а тебя спрашивают: «что выполняет эта функция» — написанная на бумаге? Это очень оскорбительно, черт возьми! Собеседование и набор персонала — это ответсвенное задание, а большинство относятся к этому более чем легкомысленно. Неужели так трудно придумать задание из текущей работы? Да таких заданий можно напридумывать хоть для каждого претендента в отдельности. Надо только мозгой шевльнуть и тогда легко сможешь определить людей знакомых с нужным стеком технологий, с теми кто быстро осваивает новые технологии, с ходом мысли разработчиков и всем остальным, что необходимо для того чтобы взять на конкретную работу конкретного человека. При всем этом съэкономить время и нервы себе, и соискателю.
ES6 Module Transpiler is an experimental compiler that allows you to write your JavaScript using a subset of the ES6 module syntax, and compile it into AMD or CommonJS modules.
Как-то надо было срочно решать поставленную задачу, а много времени на изучение существующих решений не было. Самое популярное что было на слуху — Require.js, но с ним я споткнулся, что привело к написанию скорее не велосипеда, а наворотов к нему. На самом деле, у меня обертка над Require.
Кроме того, я отношусь у группе людей, которые любят изобретать велосипеды, чтобы быть в тонусе :--)
Но вопрос в другом: как долго можно работать в таком режиме? неделя? месяц? год? всегда?
Уже ясно что это видеоматериал, и если ты, в данный момент читаешь со смартфона, то не очень удобно будет его просматривать
P.S. Там написано, что это видео, не обратил внимания. Но идея все равно хорошая )
Довольно стройно и элегантно
Причем тут мир IT? Вы работаете в конкретной области, и ищите конкретного специалиста, который будет выполнять конкретные задачи. Придумать задачу, когда все конкретизировано проще паренной репы. Если вы засечете время, то заметите, что на придумывание задания, которое соответсвует этой конкретной работе, уйдет не более 15 минут, скорее даже меньше. Но это избавит от утомительных собеседований, которые на 80%-90% трата времени.
А зря, бегло глянув в код, можно понять как человек работает, и если код визуально понятный, то можно вникнуть и понять ход мысли программиста.
С чего вы взяли что вы находите общий язык? Вы часто интересуетесь о том, удобнее ли соискателю написать в IDE или на бумаге, и оба соглашаетесь в том, что на бумаге программировать куда удобнее?
Но лучше, наверное, спросить квалифицированного специалиста, не смущают ли его такие вопросы, а не думать за него.
Вы так и не согласились с тем, что как и другие специалисты, интервьюверы тоже бывают плохие и хорошие, подготовленные и не подготовленные. И как и других специалистов, плохих интервьюверов гораздо больше чем хороших.
P.S. У меня к соискателям еще одно требование: рассказать смешной анекдот или шутку. Но это так, чтобы понять, как в коллектив вольется )
Лучше пусть эти баги будут мои.
Меня пугают выражения experimental в продакшне
Кроме того, я отношусь у группе людей, которые любят изобретать велосипеды, чтобы быть в тонусе :--)