Проектирование, потоки?
Спроси что такое гринлеты, Twisted, Tornado, в чём отличие мультипроцессинга от потоков, в чём их отличия в модулях Python(тест пройден если человек скажет что GIL работает в обоих случаях, а сами модули имеют одинаковый набор функций).
Про проектирование достаточно сложно говорить. Попроси придумать простейший Singleton и объяснить какие альтернативы этому решению есть. Скажет что-то про мета-классы, про то, что сами по себе модули являются синглтоном — тест пройден.
Спроси что такое кольцевые зависимости. Дай пример кода с такой проблемой и попроси решить её или аргументировать почему выхода нет. Тест пройден если человек переместит все run-time используемые импорты в конец файла или перепроектирует систему, предложив вариант без кольцевых зависимостей.

Я не буду давать ссылок, потому как не использую руби, но дам пару советов:
1) Учите английский
Новые технологии редко появляются в России, а если и появляются, то вся документация сначала делается на английском.
2) Учите английский
Вся хорошая документация пишется на английском и много где публикуется. Хорошая русская документация сейчас публикуется только в блогах и на хабре. Больше нигде её не найти, а если и найти, то она жутко старая и не обновляющаяся.
3) Учите английский
Даже если и найдёте русскую документацию к RoR 3(вообще, RoR 3 на столько нова, что её почти никто ещё и не использует), то на ваши вопросы с радостью ответит гугл, но только на английском языке.
4) Учите английский
Никто не захочет поддерживать ваш код, если он будет содержать классы «MojCatalogTovarov». Поберегите нервы и себе, и другим.
5) Учите английский
Многие вопросы уже сто раз обсуждены в различных коммьюнити и легко гуглятся, но только на английском языке.
6) Учите английский
Ведь всё-равно придётся.

Я достаточно часто рассказываю о том, что такое IDE, и вообще на эту тему в своём блоге(http://blog.soulrobber.ru/).
Но если нужно «здесь и сейчас», то:
1) Удобство интерфейса. Минимализм. IDE это не Word, 90% времени программист должен наблюдать редактор и дерево каталогов, файлов проекта. См. TextMate, Vim, Emacs.
2) Скорость. Она характеризуется показателями скорости работы анализатора кода(автокомплит часть его) и редактора.
3) AI анализатора кода. Он должен уметь подхватывать символы из модулей, импортируемых в коде.
4) Разная подсветка кода(в т.ч. фон редактора, гаттера, курсора etc). Жизненно важно иметь 2-3 стиля подсветки: тёмная, светлая, в стиле «zenburn».
5) Модульность. Скриптинг и остальное — костыли и попытки сделать нормальную систему, но лучший вариант пока представлен только в TextMate.
6) Инструменты дебага приложения. Как минимум — gdb и хоть какая-нибудь интеграция. Лучше — подхват живого приложения с его помощью. Без инструмента дебага твоя IDE будет просто редактором. Мало IDE смогут называться таковыми если убрать из них инструмент дебага.
7) Конкретно, поддержка языков(это только те, что нужны мне): C, C++, Python, Ruby, PHP, XML, HTML, CSS, JS, HAML, SASS, Django Templates, Makp, genshi, Lisp. Это вместе с так называемыми «lint'ами». Для html поддержка ZenCoding.
8) Рефакторинг(ну это вытекает из анализаторов кода, но на всякий...).
9) Поддержка вложенных терминалов как закладок.
10) Поддержка CVS, DCVS.
11) Удобные комбинации клавиш. Я должен быстро переместиться в дерево файлов(одним сочетанием клавиш), сменить бранч(1-2 сочетаниями), автоапдейтнуть, найти нужный файл без лишнего нажатия(просто жмакая кнопку arrow down), открыть, сделать изменения, открыть консоль(одной кнопкой или сочетанием), сделать пару операций, вернуться в файл, дописать что-нибудь, сделать коммит(не менее легко, чем остальные вещи), сменить бранч обратно и автоапдейтнуть, а затем сделать пуш.

Собственно, список я могу продолжать вечно, но я знаю что ты не сделаешь и 1/1000 от функционала текущих IDE. Ну не будут такие вопросы появляться у человека, который будет делать IDE, которая будет популярна.
Я использовал огромное число IDE и редакторов, пришёл к некоторым концепциям и выводам, думаю начать разработку своей IDE, но пока не рвусь, т.к. времени не много на это дело, да и дело-то не самое благодарное.
Пока я пришёл к выводу, что лучше всего использовать TextMate или Vim. Не Emacs, т.к. я с ним наигрался и пришёл к выводу, что Vim удобнее, хотя Lisp мне милее вимскрипта.
Однако, есть ещё одна вещь — Sublime Text 2. Обзор можно посмотреть здесь: blog.soulrobber.ru/2011/01/30/sublime-text-2/
Это кроссплатформенный аналог TextMate. Увы, проприетарный и платный, но есть бессрочный триал-режим.

Сейчас на рынке труда больше востребована Java. Не только сейчас, но и в прошлом, и в будущем данная платформа будет популярна и будет продолжать пользоваться спросом.
Вопрос в том, чего ты хочешь: работать на большую фирму, где джава применяется для определённого проекта и продолжать работать с ней ИЛИ устроиться в небольшую «контору», в которой ты можешь быть выше «рангом», разрабатывать средние и небольшие проекты.
Во втором случае однозначно пайтон, при этом не джанго, а Pyramid или Pylons. Моё личное мнение — применение Java на средних и небольших(малых) проектах — зло, а джанго не самый удачный веб-фреймворк.
Холиворщикам: всё это моё личное мнение, на личном и не только опыте, и переубеждать меня не надо.

Во-первых, парадигма функционального программирования всего-лишь говорит о том, как писать программы. Цель данной парадигмы — оформлять программы как математические функции.

Конечно, за этим стоят какие-то большие цели, кто-то считает что это единственный верный способ программирования, кто-то поклоняется данной парадигме как богу. Но данные люди, простите за столь грубое высказывание — дураки. Истина находится «между». Иначе говоря, функциональное программирование позволяет сделать код более компактным, красивым, быстрым, но использование только этой парадигмы, игнорируя остальные — только вред.

Важно понять что требуется от языка. Как я вижу, требование одно — большая скорость при небольших ресурсах, которые не будут увеличиваться(я правильно понял?).
Если всё так критично(100 и 1 раз оцените задачу!), то выбор не велик: C, C++.
Если хочется вкусить функциональщины, то можно попробовать Haskell, CL(Common Lisp). Но я повторюсь, если в задаче есть слово «функция», это ещё не значит что нужно использовать «функциональное программирование».