bagerman

1) shift+tab - влево. Если нужно вправо, кроме таба есть действие с не назначенной по умолчанию кнопкой. Ищется в настройках по названию "indent line or selection".
2) Зажать alt, и выделять зажатой левой кнопкой мыши.

1) Shift-Tab, если я правильно понял — уменьшает отступ слева на одну «ступеньку» (таб, 4 пробела, 2 пробела — смотря по настройкам для текущего файла)
2) https://www.jetbrains.com/idea/help/multicursor.html Я, правда, не знаю, зачем это может понадобиться, всегда хватало Shift+F6 (переименовать сущность) и column mode (Alt+Shift+Ins)

все это не обязательно должно быть во всех ide. sublime не просто так так популярен, а потому что предлагает уникальные возможности в плане редактирования кода.

Тут рецензия хорошей книги "Art of Unit Testing", плюс, несколько ссылок на доп-материалы. Книга не только расписывает плюсы-минусы тестов, но и объясняет, как лучше внедрять TDD в команды\проекты.

нужно писать TDD тесты.

Нет, нет такой вещи как "TDD тесты". TDD это одна из методик экстремального программирования (XP). Вам уже привели ссылку на книгу Кента Бэка на эту тему (к слову крайне рекомендую)

Суть этой методологии в том, что бы разбить работу над кодом на три этапа, которые называются циклом красный-зеленый-рефакторинг.

- Красный - перед тем как написать код, мы должны написать тест который ломается (обычно в консоли сломанные тесты подсвечиваются красным). Согласно этой методологии писать код вы должны строго тогда, когда у вас есть сломанные тесты. Если сломанных тестов нет, то и код писать не нужно.
- Зеленый - когда вы получили красные тесты, вы должны максимально быстро дописать код так. что бы тесты были зелеными. Скажем если вы написали тест который ожидает от функции, что она вернет строку "foo" то в коде у вас должно быть не больше чем сама функция и вывод строки "foo". Как только мы этого добились мы либо рефакторим, либо добавляем еще красных тестов что бы потом дописать код. Конечно настолько примитивные вещи делать по такому циклу избыточно, и у Кента Бэка описывается понятие "длины шага", то есть сколько работы мы можем делать на каждом этапе. Вы всегда должны подключать здравый смысл словом.
- Рефакторинг - на предыдущих фазах мы не загонялись о том насколько наш код красив, насколько мы соблюдали принципы DRY и т.д. так что это фаза отчистки кода. Мы можем делать ее на каждой итерации, а можем раз в пару часов, но важно делать это как можно чаще. На этом этапе мы устраняем дублирование как в коде приложения так и в тестах. Важно отметить что хорошей мыслью будет не рефакторить одновременно и код и тесты, ибо у нас должен быть источник правды. Если мы почистили тесты и при этом они начали фэйлиться, то значит мы что-то сломали пока числити. И наоборот. А если менять и то и то между запусками тестов то не понятно кто виноват.

Обычно TDD практикуют используя unit-тесты (что логично, ибо они выполняются достаточно быстро что бы выполнение тестов не заставляло нас заваривать чай), что подразумевает собой то, что мы тестируем один юнит (один класс или объект), а все его зависимости должны подменяться на моки (фэйковые объекты, которые нужны что бы проверить как наш объект взаимодействует с другими, об этом тоже много написано). Но никто не запрещает использовать интеграционные/функциональные тесты и при этом практиковать TDD (так например делают чуваки практикующие BDD), а Кент Бэк это дело называет ATDD.

Собственно TDD дает нам следующие преимущества:
- вы не тратите время на проектирование системы в микроскопических масштабах, это эволюционный подход, архитектура приложения постоянно меняется и эволюционирует вместе с требованиями. Все требования формализуются в виде тестов.
- код всегда покрыт тестами (пусть и не на 100%, обычно хватает и 20% что бы можно было жить, все зависит от сроков жизни проекта и требуемого уровня надежности)
- если вам становится трудно писать тесты (например много зависимостей, сложно мокать) - то это должно навести вас на мысль о не правильной архитектуре и инициировать более глубокий рефакторинг. А при наличии тестов это не так уж и страшно.
- необходимость покрывать тесты увеличивает потребность в соблюдении всяких принципов типа SOLID и т.д. так как иначе мы начинаем писать тесты очень не эффективно и опять же возвращаемся к тому что с архитектурой что-то не так.

updated

тут в комментариях уличили в том что я не указал минусы и область использования методологии...

Минусы TDD проистекают из плюсов. Это эволюционный подход, который хорошо работает когда мы вносим изменения в систему маленькими порциями и всегда рефакторим наш код, что бы он большую часть времени был красивым и удобным к расширению. Если же вам в руки дали легаси проект и сказали отрефакторить, то TDD тут не подходит или подходит плохо. Но опять же такая задача ставится довольно редко, чаще - добавление функционала. И в этом случае мы возвращаемся к внесению изменений маленькими порциями и эволюционному подходу. Просто на это уйдет довольно много времени, но если сравнивать с "рефакторинг + добавление функционала + регрессионное тестирование" то в зависимости от ситуации TDD может дать как профит так и нет. Все зависит от сложности системы. На простых системах в этом нет смысла.

По поводу области применения... Тут есть несколько точек зрения. Как минимум TDD решает вопрос проектирования архитектуры, а не разработки алгоритмов. Этого мы достигаем тестами. Но опять же через юнит тестирование довольно не удобно разрабатывать определенные типы проектов: комиляторы, трансляторы, различные решения основанные на сложных алгоритмах (например алгоритмы сжатия, шифрования и т.д.), штуки завязанные на сетевом взаимодействии, например клиенты для протоколов. Для этих вещей больше подходят функциональные тесты или же их вовсе сложно покрыть тестами.

Экстремальное программирование: разработка через т....

habrahabr.ru/hub/tdd

Автор я конечно не Брюс Ли и не Крутейший какой-нибудь фронтэндер. Скажу так:
1. Детский инстинкт: все и сразу (забудь об этом)
2. Это упорный труд.
3. Обязательное удовольствие от изучения, работы.
4. Обязательное физическое развитие ( спроси у любого, он кивнет тебе)
5. Медитация ( это тяжело, но если поймешь тему все ключи будут в кармане)
6. Наконец же пойми себя, никогда не поздно это сделать. К чему ты тянешься, что любишь. Возможно ты до сих пор не знаешь себя.
7. Взлеты и падения: у всех они свои и ты не один такой. Нужно уметь пережить такие моменты.
8. Я видел много веб-программистов у которых стаж с 2006 года(делай свои выводы)
9. Не теряй времени, иногда кажется что ещё все впереди и времени фигова туча, на самом деле это мираж.
10. Не грызи слишком себя, иногда это совсем не нужно.

В-нулевых: revealing module сильно устарел на данный момент, пора юзать настоящие модули, лучше всего — ES2015.

Во-первых, как правильно отметил Алексей Уколов, чтобы явно указать зависимости и предотвратить конфликты.
Во-вторых, чтобы вместо jQuery можно было передать, например, Zepto, а вместо window — какой-то другой скоуп, например, в nodejs нет window.
В-третьих, это дает возможность минификатору сжать внутри этой функции window (и остальные аргументы) до одной буквы.

Что же до undefined, то в sloppy-режиме (без 'use strict') можно переопределить undefined, как будто это простая переменная. Чтобы получить настоящий, неиспорченный undefined в функцию не передают один аргумент, непереданный аргумент по дефолту имеет значение undefined. Вот такие ужасы можно творить:

(function () {
    var undefined = 'wtf';
    console.log(undefined);
}())

У вас неверная установка в каждом пункте.

>> Нужно работать. Минимум 8 часов
Можно работать и семь, и шесть часов. Ищите инструменты, которые сделают вас эффективней. Смените ИДЕ, редактор, браузер, утилиты. Например, можете ли вы писать код без подключенной мышки или тачпада?

>> Нужно спать. Минимум 8 часов
Это слишком много, 7 хватит с головой. Лучше ищите оптимальное время, когда ложиться. Для меня это с 23:00 до 06:00, плюс-минус полчаса

>> Нужно кушать полезную и разнообразную пищу, приготовленную из свежих продуктов.
Гречка, рис, овсянка, орехи, творог со сметаной, фрукты, раз в неделю мясо. Все это продается недорого.

>> Нужно заниматься спортом.
Чередуйте приседания и отжимания по утрам, занимает 20-30 минут. Бегайте по вызодным. Не нужно быть качком, чтобы быть в форме. Бросьте пить и курить.

>> Нужно время на самообразование.
Английский нужен 2-3 раза в неделю. Каждый день -- это излишек, мозг не запомнит. Книжку на ночь 30 минут вполне.

>> Очень хочу создавать свои проекты
Проверьте себя, чем занимаетесь первый час, когда садитесь утром за комп. Скорее всего, читаете Хабр и соц. сети. Этот час уделяйте своим проектам. Составьте план, как решать задачи максимально и просто по принципу: 1 день, 1 час, одна задача.

Занимаюсь подобными вопросами около 10 лет (прошёл программу талантов крутейших IT корпораций США / Германии, сам преподавал) , вот из моего опыта
1) В порядке зависимостей - сначала JavaScript потом JQuery
2) Бить на малые куски. Порядок не имеет значения если хватает охвата оперативного запоминания. Если замечаете что не хватает бейте на блоки до получаса на каждую тематику и потом ротируйте
3) Внедрить интервальные повторения (читайте на хабре в т.ч. об инструментарии)
4) Внедрить перцептивное обучение (изучать успешные кейсы/примеры даже если пока не понимаете почему они стали успешны)

Ребята, кто знает как работает наш мозг.

никто

Как отлично запоминать прочитанный материал?

Совершенно не важно как вы поделите время на каждый предмет. Главная фишка усвоения - практика. Нужно постоянно что-то программировать на JS и JQ и все результаты постоянно коммитить в гит. И тогда всё пойдет.

Ну если в двух словах, то компиляция - процесс получения программы (исполняемые машиной команды) из исходного кода на неком языке программирования.

Трансляция - преобразование исходного кода программы из одного ЯП в другой. Обычно компиляторы (например для C/C++) транслируют исходник в программу на асемблере, и уже потом ее компилируют.

Что касатеся транспайлера (Transpiler) - это тот же транслятор с той лишь разницей, что у результата примерно тот же уровень абстракции, что и у исходного текста (ну например транслятор из Java в C++).

Ссылки:
Source-to-source compiler
Compiler
Translator