У меня есть пара саксесс-стори, не смотря на мой возраст :)
Несколько лет назад я занимался написанием ботов и просто утилит в виде юзерскриптов. И разрабатывал скрипт с кучей полезностей для vk.com. На базе этого скрипта получил несколько интересных знакомств и ценный опыт.

Так вот, ближе к делу. Однажды ко мне в личку постучался 19летний парень. Оказалось, что он очень сильно впечатлён самой возможностью «расширять сайты» и добавлять функционал. Он попросил меня рассказать ему, как это делается. У парня было только школьное образование, ни в ВУЗ, ни в ПТУ он не поступил, работы не было (на это были причины личного характера).
Его обучение началось с javascript. Я взял его в «команду» — помогать мне со скриптом. Со своей стороны я объяснял ему основы программирования на конкретных примерах: алгоритмическое мышление, циклы, условия, простые алгоритмы, и т.д.
Самое главное, что все эти понятия были наглядными. Имея в запасе минимальное понятие о API джаваскрипта, не представляя, что такое CSS и HTML, человек, тем не менее, мог видеть результат своих экспериментов, и этот результат приносил какую-то пользу, а не был очередным хеллоу-вордом.

Сейчас товарищ работает javascript-программистом в некой Московской фирме. Помимо джаваскрипта человек интересуется всеми сопутствующими технологиями — серверсайд языки, вёрстка, десктопные приложения, алгоритмы и далее по списку.

Как показывает опыт, основанный на экспериментах на друзьях, следующий паттерн работает для большинства заинтересованных:

1. Определить, что именно зацепило человека (с какими технологиями его начать знакомить в первую очередь)
2. Познакомить его с базовыми понятиями (циклы, переменные, условия, составление алгоритмов)
3. Дать ему в руки инструмент для экспериментов — простой язык, на котором можно писать полезные для самого человека вещи, с незамысловатым API.
4. Показывать человеку реальный пример кода (исправлять его код) и объяснять досконально ход своих мыслей при разработке или проектировании. При этом, сначала вы будете отвечать на вопросы «как?». Постепенно их нужно полностью сводить к вопросам «почему?». Вопрос «как» человек должен решать сам.
5. Максимально сократить цикл идея-реализация-результат. Это очень важно! Это топливо для мотивации.
6. Главный вопрос — какую идею реализовывать. It depends. Лучше всего, чтобы обучаемый сам придумывал, какую проблему он будет решать. Если мотивация не строится на мысли «мне срочно нужны деньги, поэтому я стану программистом» или прочими мыслями о будущем, то написания «шаблонных» программ будет идти в ущерб мотивации.
7. Как только человек научится ваять код самостоятельно — он начнёт выходить за рамки вашего обучения. Тут важно научить человека получать информацию (да, не все умеют пользоваться гуглом и стэковерфлоу. И про книги не забываем)


Это субъективно, но для меня такой подход работает. Я веб-программист, и «подопытные» тяготеют к этим технологиям.
Но в целом — никто не любит сухую теорию. Видеть и «щупать» результат — бесценно :)

PUT должен быть идемпотентной операцией, т.е. несколько одинаковых последовательных пут-запросов на один урл (и с одинаковыми параметрами) не должны создавать новых объектов.

POST, в свою очередь, может создавать новые объекты при последовательных запросах на один урл.
Другими словами, POST нужно использовать для обращения к «производящим фабрикам».

Первая подручная статья, в которой это объясняется: на английском.

И да, PUT можно сравнить с INSERT… OM DUPLICATE KEY UPDATE.
POST — это чистый INSERT.

Добавлю свое мнение (имею опыт разработки как энтерпрайзов, так и стартапов):

Spring Framework.

• Отлично подходит для крупных проектов, и проектов, которые необходимо будет длительно поддерживать.
  
• Желательно иметь 1 хорошего специалиста по спрингу, иначе скушает много времени на построение правильного процесса (все же это энтерпрайз-технология).
  
• Стандарт для энтерпрайза де-факто.
  

Grails.

• Пишется на груви (джава с сахаром + динамика), что объективно приятнее
  
• Отличное решение для прототипов и веб-CRUD систем.
  
• Имеет набор стандартных практик и кучу плагинов
  

Play 1.2
Концептуально это такой же фреймворк, как и Grails.
Главное не путать его с Play 2 (scala-фреймворк, переработанная архитектура. На джаве писать можно, но не удобно)

• Похож на греилс, но основноя язык — джава
  
• Низкий порог входа
  
• Использует стандартные джава-решения для связанных технологий (SQL ORM = Hibernate, к примеру)
  
• Подходит для прототипов
  
• Стейтлесс по умолчанию
  

Резюмируя — Спринг отлично подходит для средне-больших проектов, потенциально долгоживущих. Греилс и Плей — отлично подходит для прототипов и тестирования идей, а также для чистых веб-прослоек без страшной бизнес-логики.
Если вы хотите «попробовать идею в полевых условиях», я бы брал Play 1.2/Grails + AngularJS. Это позволит запилить прототип значительно быстрее, чем на том же Спринге.

Есть несколько разновидностей тестов. Если вы бэкэнд-разработчик, то вас, в первую очередь, будут интересовать два вида:

1. Юнит-тесты
2. Интеграционные тесты

Юнит-тесты — тесты, направленные на тестирование отдельных частей класса. Чаще всего это методы. Иногда — отдельные ветки методов (всегда справедливо для god objects).
Самый важный пункт: для юнит-тестирования не нужно поднимать контекст приложения! Вы тестируете логику отдельного юнита, а не связку классов. Поэтому, очень часто для юнит-тестирования использую мок-фреймворки (как пример — мокито). Это нужно для того, что не писать руками -заглушки связанных классов.

Что покрывается юнит-тестами? В первую очередь покрывайте бизнес-логику (сервисы, классы-менеджеры). После — контроллеры. Можно покрыть DAO-слой (опять же, если там есть сложная логика)0.

Как пишется юнит-тест? Вы берёте набор входных параметров, мокаете классы-зависимости, передаёте входные параметры в тестируемый метод и проверяете выходные параметры. Если в методе есть условия — необходимо попасть во все ветки.

Писать ли отдельный тестовый метод для каждой ветки? Это зависит от вашего стиля и от того, планируете ли вы рефакторинг в ближайшем будущем. По-хорошему, стоит выделять отдельные крупные ветки в отдельные методы, особенно для god objects.

Интеграционные тесты — это тестирование нескольких взаимосвязанных классов. К примеру, класс бизнес-логики + DAO-класс.
В случае интеграционного теста вам придётся поднимать контекст приложения (обычно для этого создаются отдельные конфигурационные файлы). К тому же, будет неплохо настроить транзакционность на уровне отдельных методов (для того, чтобы не чистить базу руками после изменений).

Нужны более глубокие подробности — пишите :)

Отвечу вопросом на вопрос: вы думаете статья по актуальной теме кому-нибудь помешает?