Язык программирования. Какой изучить?

Yosic, кстати JavaScript я смотрю ща перспективен. кое что на нем писал такое , прикольно мне понравилось

lgfedor,

кстати JavaScript я смотрю ща перспективен. кое что на нем писал такое , прикольно мне понравилось

Да он всегда был так перспективен Он идет как вспомогательная часть на клиенте для WEB. Я не встречал проектов, где был нужен чистый javaScript разработчик, всегда должен быть Primary Java, C/C++ или, что-то другое серверное и JavaScript для клиентской части, чисто javaScript мало смысла клиент и сервер всегда тесно связаны.
Про Java и Андроид, раз у вас уже есть опыт на C/С++ то мой совет - берите ставьте SDK и пробуйте, смотрите примеры и доки в инете и оно само пойдет если есть интерес.
Alexandra1989, Идите работать тестировщиком в тот же EPAM, а там пойдете на внутренние курсы по разработке хоть на той же Java и там вам дадут основы бесплатно,а дальше уже посмотрите ваше это или нет.

Скорее всего уже писали, так что может повторюсь.

Для начала надо определиться с чем именно хотим работать, я бы выделил следующие подходящие для новичка области:
- QA, или в простонародье Тестировщик: функциональное(ручное) по сути требует общей грамоты ПК и английский, остальному научат. Автоматизированное тестирование требует уже начальных навыков программирования.
- Front-end web: востребованы люди с знанием HTML, CSS и JavaScript, можно начать с первых двух и стать UXD разработчиком и постепенно перейти к JavaScript разработчику, что пристижнее и бабла поболе чем у первого
- Back-end web: всякие PhP, ASP.NET , ASP.NET MVC, Ruby и прочая хипстота. Требуются хорошие навыки программирования, самостоятельно можно поднятся на уровень джуниора за год-два.
- Mobile: начиная от нативных(написанных на родном SDK платформы), заканчивая кроссплатформерными SDK приложениями, играми.

Когда определитесь, можно уже разговаривать более детально. Если есть вопросы могу ответить в личке.

Yosic:

Да он всегда был так перспективен Он идет как вспомогательная часть на клиенте для WEB. Я не встречал проектов, где был нужен чистый javaScript разработчик, всегда должен быть Primary Java, C/C++ или, что-то другое серверное и JavaScript для клиентской части, чисто javaScript мало смысла клиент и сервер всегда тесно связаны.

Направление называется front-end разработка, в основном для вакансий чистый JS + знание разных библиотек и фреймворков. Ситуация такова, что на client-side (в браузере) приложения зачастую более сложные чем серверная часть.

M.Jelly,

Направление называется front-end разработка, в основном для вакансий чистый JS + знание разных библиотек и фреймворков. Ситуация такова, что на client-side (в браузере) приложения зачастую более сложные чем серверная часть.

Я прекрасно знаю как это называется. А реальная ситуация такова, что если у вас клиентская часть более сложная чем серверная(и такое бывает как раз не зачастую, а редко), то тут 2 варианта, либо у вас навороченный интерфейс к очень простому функционалу, что само по себе странно, либо у вас реальные проблемы с архитектурой системы. Лично я бы не делал ставку только на javaScript, гораздо выгоднее владеть серверными и клиентскими технологиями одновременно. Я вообще слабо представляю, как можно делать что-то в интерфейсе не зная как там это отрабатывает на сервере если это не банальный выбор данных.

del

Yosic:

А реальная ситуация такова, что если у вас клиентская часть более сложная чем серверная(и такое бывает как раз не зачастую, а редко), то тут 2 варианта, либо у вас навороченный интерфейс к очень простому функционалу, что само по себе странно, либо у вас реальные проблемы с архитектурой системы. Лично я бы не делал ставку только на javaScript, гораздо выгоднее владеть серверными и клиентскими технологиями одновременно. Я вообще слабо представляю, как можно делать что-то в интерфейсе не зная как там это отрабатывает на сервере если это не банальный выбор данных.

На клиенте может быть полноценный MVC например, с огромной кучей логики как над представлением, так и над данными. Часть данных подгружается сразу, часть уже асинхронными запросами или через веб сокеты в процессе выполнения и т.д. Сервер в этом случае выступает как API над данными + выполняет какой нибудь data maining. Это каноничное single page application. Вариаций архитектур очень много, но идея в том, что бы как можно сильнее отделить клиент от сервера. Делается это потому, что это просто быстрее и визуально намного красивее. Нет перезагрузки страниц, на клиенте можно менять логику независимо от сервера и на сервере независимо от клиента, главное быть в рамках API. И проще работать в команде, где хотя бы один человек занимается киентом, а один сервером, чем делать все это самому. А вот что бы клиентская часть быстро работала и имела хорошую архитектуру, нужен очень грамотный специалист, ибо как показывает практика в 60% случаев будет все очень плохо, ибо JavaScript это просто дикий язык. Что уже говорить когда нужен Canvas или WebGL.

Yosic, Я не спорю с тем, что уметь и сервер и клиент это выгоднее, но зарплаты чистого front-end сравнимы с большинством back-end (исключаем тут область, где кластеры и паралелизм, а имеем ввиду среднестатистические задачи на PHP, RoR, Python), и как показывает практика, человек который занимается только front-end'ом знает и умеет больше (ну и не психует, что JS говно), чем универсальный разработчик. Поэтому выгоднее принять в команду хорошего фронтендщика и не отвлекать других от их специализаций. Разделить работу над сервером и клиентом в команде довольно легко, достаточно сделать вменяемый API (ну ведь клиенты мобильных приложений как то пишутся теми людьми, которые не пишут серверную часть). А вот практика генерировать шаблоны веб-приложений на сервере, и отдавать их по запросам, это мне кажется прошлый век уже , да и я не занимался никогда таким, так как сразу начал заниматься single page app. И я не хочу сказать, что сервер должен быть простым, там может быть что угодно, вплоть до тысяч серверов, адовой логики и прочего, но все это можно (и нужно) спрятать под лаконичный API, с которым может работать и front-end разработчик, и мобильные разработчики.

Yosic, А, понял. Я по правде обхожу стороной enterprise, так как не люблю специфику таких проектов, отчасти из-за рассказов друзей о очередном проекте для Большого Зеленого Банка, отчасти что хватает пока задач и денег в любимых сферах, а это интерфейсы Рискну предположить, что в enterprise решениях не заморачиваются с оптимизацией UI на клиенте, а у нас в продуктах это одна из основных вещей, нужно делать очень быстрые и нелагающие интерфейсы, без перезагрузок страниц и как можно меньшим числом запросов к серверу.

С недавнего времени начал интересоваться Clojure и пробовать писать разные серверные штуки, но пока задачи не превышали по сложности систему обмена сообщений между сереверами в кластере, но может быть и до highload дойдет.