Владимир Чернышев

Для меня главный недостаток — при копировании человекопонятного URL'а из адресной строки в буфер получаем не человекопонятный (закодированный) URL, причём гораздо большей длины (один символ кириллицы -> 6 символов URL'а), поэтому предпочитаю использовать транслит (система Б ГОСТ 7.79-2000, он же ISO 9-95)

Нужно понимать, что можно (грубо, есть нюансы) разделить языки на языки серверного веб-программирования (тот же php, ещё популярны python, ruby, java, c#, вообще любой язык «общего назначения» в принципе, хоть ассемблер) и клиентского (самый популярный, практически монополист — Javascript). Если вам нужно взаимодействие между посетителями сайта (включая посещение одним пользователем через разные компы/браузеры), то нужно, прежде всего, изучать серверные языки и, как правило, БД. Клиентский Javascript — когда будет реализована серверная логика (приложение будет делать то, что нужно) и начнёте думать об пользовательском интерфейсе (чтобы оно это делало удобно и/или красиво). Если же хотите, грубо говоря, делать локальные приложения, запускаемые из браузера, то про серверные языки можно не думать.

Вариант привлечения из соседних регионов рассматривали? То есть не на полную удалёнку, а, например, неделю работает дома, раз в неделю приезжает в офис. Для регионов удалённых км на 600 (ночь в поезде до Москвы, тот же Питер, с воскресенья на понедельник, например в поезде в Москву, с понедельника на вторник в Питер) довольно интересный вариант, имхо. Сам так катался полгода для встреч с заказчиком (правда раз в месяц, так и экономнее выходило, чем единый проездной и времени в дороге проводил меньше — 60+ часов в месяц на дорогу в офис на краю города vs 22-24 часа на дорогу в Москву и обратно :) )

Если бы была такая литература или другие материалы (не из серии «Как стать миллионером в Интернете за 24 часа»), то ей цены бы не было или была бы доступной всем, а вокруг нас был бы идеальный интернет.

P.S. Улыбнул п. 5 — обратитесь за консультациями в Microsoft, пускай объяснят как они разъяснили огромному количеству пользователей их ОС, что им нужна кнопка «Пуск» :), причём что в первых версиях Windows её не было, ну или Microsoft Office (если не мелочиться).

Основной задаче соответствуют практически все популярные (их уже перечислили) ЯП с соответствующими (их тоже) веб-фреймворками. Языки можно разделить на два больших класса: компилируемые (пускай и в байт-код) со строгой статической типизацией — Java, C# и интерпретируемые (пускай и байт-код :) ) с нестрогой динамической типизацией — Python, PHP, Ruby. Если раньше писали на Pascal, то первые вам, наверное, изучать проще будет, а на вторых, как правило, получается более компактный код (и, логично предположить, меньшее время разработки).

Лично я выбирал бы между Java и Python. От изучения C# воздержался бы в виду сильной привязки самого популярного фреймворка для него к конкретному семейству ОС (Mono не является аналогом .Net — они поддерживают пересекающиеся множества API, для кроссплатформенных нужно будет пользоваться только пересечением), от PHP в виду большого количества «унаследованных» особенностей и самого языка, и его стандартных библиотек, от Ruby — достаточно малое сообщество, имхо.

Ещё можно рассмотреть серверный Javascript (чтобы не изучать ещё один язык, а без JS вы вряд ли обойдётесь), но тут мне совсем сказать нечего, кроме как что есть node.js и ориентирован он на асинхронную модель обработки.

>Проблема усугубляется тем, что необходима работа со считывателями магнитной полосы и прочие хитрости.

Не сталкивался, но что-то мне подсказывает, что от серверной платформы тут практически ничего не зависит

Для каждой неактивной страницы с плеером невозможно, имхо, по определению. Какой из 100500 запущенных плееров/треков должна приостановить клавиша/команда/сообщение/сигнал/… «Pause»? Хорошо, если на активной странице приостановит, и то хлеб.

Никак не могу себя приучить к правильной (согласно TDD) работе: сначала пишем тесты, потом код, такой чтобы тесты не работали, а лишь потом его правим, чтобы заработали.

Сложности две:
— лениво писать тесты на тривиальный код (то есть кода ещё нет «на бумаге», но «в голове» уже он есть)
— лениво писать тесты, предусматривающие всё и вся, например, что методы доступа к СУБД вернут какую-ту ахинею, а не либо корректные данные, либо ошибку. Или, скажем, конструкция return new SomeClass() вернёт не экземпляр SomeClass.

Вероятно я написание тестов так до конца и недопонял, особенно что касается тестирования связанных объектов (например кобинации контроллер, модель, репозиторий)

На хабре разместить вакансию, где указать все требования, не пробовали? :)