makedevpro

Приветствую!
Был в Вашей ситуации год назад примерно.
Изучайте javascript, чистый, на хорошем уровне. Все остальное тлен - изучаются за несколько дней при реальной работе и jQuery, и bootstrap, git и т.д.
Не слушайте советов начинать с jQuery - это путь в быдлокодство без хорошего знания js. Туда же и фриланс, там не будет повода развиваться.
Учите javascript, работу с DOM, соглашайтесь на тестовые задания от работодателей. Далее сложная цель устроиться на первую свою работу, не теряйте время на веб-студии, сейчас в тренде SPA - научиться backbone, angularJS намного проще на реальном проекте. Через полгода такого опыта вы будете востребованным специалистом с хорошей зарплатой. Удачи!

Верстальщик преобразует графический макет (Photoshop или иной) в набор HTML + CSS + картинки. Иногда к свёрстанному макету может подключить типовые библиотеки Javascript, например, slider для картинок, или всплывающие подсказки (tooltip), или диалоговые окна (dialog/popup).
Знания и навыки:

• работа с графическими программами, чтобы понять, как собран макет
  
• знание HTML, HTML5, CSS, CSS3, понятие про веб-шрифты, спрайты и другие технологии
  
• пригодятся знания по HTML-фреймворкам, например, Twitter Bootstrap или Semantic UI
• навыки кроссбраузерной вёрстки, чтобы в разных браузерах выглядело и работало одинаково
  
• навыки отзывчивой вёрстки, чтобы можно было использовать на устройствах с разными возможностями и разрешениями
  
• знание типовых решений javascript, чтобы реализовать простейшие вещи, заложенные в макете
  

Фронтенд-разработчик делает так, чтобы макеты, полученные от верстальщика, были наполнены реальными данными. Если приложение построено как client-side (то есть вся основная логика загружается в виде огромного javascript в браузер, а данные запрашиваются с сервера по AJAX; это называется "толстый клиент"), то фронтенд-разработчику потребуется следующее:

• знание HTML, HTML5, CSS, CSS3, понятие про веб-шрифты, спрайты, Comet и другие технологии
• глубокое знание Javascript, включая использование готовых фреймворков, библиотек и написание расширений для них, что подразумевает объектно-ориентированное и событийное программирование
  
• знание AJAX, CORS и навык создания тестовых затычек на стороне сервера, чтобы можно было разрабатывать приложение пока бакенд не готов
  

Если фронтенд строится на стороне сервера, то дополнительно потребуется знать используемый серверный язык программирования (например, Python, Ruby или PHP) и используемый фреймворк (Django, Ruby-on-Rails, Yii). На практике бывало такое, что фронтендер просил в нужной части проекта сделать var_dump от структуры данных, которую надо показать и перечислить серверные методы, которые надо вызвать по нажатию предполагаемых кнопок.

Зачастую фронтенд-разработчик может и сам закодировать эти серверные методы, если не требуется углубляться в серверную логику (отношения в данных, конкретная бизнес-логика, хранение данных, кэширование, очереди, крон-задачи). Я лично таких очень ценю.

И моё личное мнение - фронтенд разработчику не помешают базовые знания про UML. Иногда с ними так тяжело обсуждать обмен данными по AJAX. У них это какой-то непрерывный поток магической энергии, волшебным образом преобразующийся в буковки на экране пользователя, а вот для бакенда это набор отдельных операций, иногда ещё и асинхронный. Диаграммы последовательностей ни читать, ни писать многие не умеют. Таймлайны составлять не умеют.

-----------

Написал дополнение: copist.ru/blog/2015/08/29/layout-designer-vs-front...

Если коротко, то верстальщик это HTML+CSS, а фронтэндщик это HTML+CSS+JS+ легкое погружение в бекенд с целью написания заглушек для тех же ajax-запросов.

Оукей. давайте возьмем ваш пример с fl.ru + чаты.

mongodb - хипстерская база данных. Для проекта типа fl.ru я бы пожалуй не использовал оную (не потому что монга отстой а потому что я лично не вижу в использовании оной смысла в контексте проекта типа fl.ru. Нам не нужен шардинг, реплекация реализуется нормально на любой нормальной RDBS, документоориентированность не нужна, хотя при грамотном подходе можно было бы реализовать неплохие агрегированные коллекции и оптипизировать селекты... Для себя не нашел у монги ни одного плюса перед RDBS типа PostgreSQL). В любом случае если вы не оставляете выбор - тут у нас будут храниться все данные. Придется потратить время на то что бы избавиться от желания что-то заджойнить и реализовать map/reduc-ы для обновления связанных коллекций. Но зато это будет так по хипстерски!

То есть если у вас есть куча однотипных запросов с кучей джойнов данные для которых обновляются редко а выборки происходят часто, то тогда можно вооружиться монгой а делать коллекции как агрегации этих выборок. Если вы вставляете референсы и пытаетесь эмитировать джойны в монге то значит вы сделали не правильный выбор основного хранилища данных). Правда денормализовать данные можно и с RDBS....

sphinx - поисковой индекс. То есть если мы должны реализовать вменяемый поиск (например по описанию вакансии) - то стоит его заюзать. Сфинкс не самый дружелюбный зато один из самых быстрых поисковых индексов. Хорошо интегрируется с MySQL и подобными и если сравнивать с ElasticSearch из коробки чуть лучше дружит с русским языком. Но опять же у эластики свои плюшки. Некоторые оной заменяют монгу так как по большинству фич в плане хранилища данных они совпадают.

redis - мы там вроде чатик делали. Помимо того что redis это хорошее key-value in-memory хранилище, которое к тому же может обеспечить нам надежность хранения данных (мэпится на файловую систему еще), оно так же поддерживает pub/sub. То есть чисто теоритически мы можем не добавлять в стэк штуки типа ZeroMQ и прочие *MQ для реализации авторизации и связи приложения чатика и основного приложения (вдруг у нас чатик будет написан на go/node.js/erlang).

memcache - вот тут стоит подумать нужен ли он если у нас есть редиска. Раньше для жирного кеша выбор был очевиден - memcached, так как reddis в те времена не поддерживал кластеризацию. Сейчас же по возможностям редиска далеко впереди. Так что даже то что memcached чуточку быстрее (но жрет больше памяти и не поддерживает авторизацию к примеру из коробки) не должно стать поводом для использования оного. Но я если честно redis в кластерах не использовал и ничего говорить не могу, а memcached испытан годами.

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

Советую Ruby on Rails. Скопирую свой старый ответ:

Я начинал с Django, но однажды наткнулся на рельсы и этот туториал , и влюбился в них.

Почему Rails?

— Быстрая разработка. В Rails это поставлено на первое место, и вместе с тем, рельсы неплохо масштабируются.
— Экосистема. Для рельсов целая туча гемов на все случаи жизни. Авторизация, аутентификация, шаблонизаторы, пагинаторы, работа с изображениями..
— Тестирование. Наверное, в экосистеме рельсов самое продвинутое тестирование:) Просто попробуйте такие гемы как RSpec, Capybara, FactoryGirl
— Язык. После более простого питона, я немного побаивался руби. Хорошо написанный код читается как текст на английском, в особенности при использовании DSL.

Я бы рекомендовал Node JS + Angular JS + HTML5 + CSS. Быстродействие + Асинхронность. Да и в изучении лёгок. Заказов может и не много по такой связке, зато это перспективное направление.

За то, что, код можно прочитать в слух, и код от этого не потеряет ясность.
За то, что англо-русский словарь нужен для именования переменных
За то, что именование переменных и выбор общего алгоритма — едиснтвенное о чем приходится думать.
За то, что при программировании на Ruby 99% уходит на проектирование поведения, и 1% на программирование
За то, что по первой строке ошибки можно определить где и в чем ошибка
За то, что интеграционные тесты можно писать на русском, от чего заказчик обливается слезами умиления и расстается с деньгами
За то, что вызывает ООП головного мозга
За то, что технилогический уровень, и технологическое качество на голову выше программы ВУЗ-ов
За то, что высокий порг вхождения по IQ на нет сокращает количество быдлокодеров
За то, что разработка вызывает просто животный восторг граничащий с оргазмом
За то, что разработкой в кайф реально можно заниматься по 16 часов в сутки и не сломать себе мозг
За то, что на форуме тебе не скажут: лол ты нуб иди читай маны днище!!111адинадин
За то, что, возможно, ваше изящное решение еще никто не использовал
мне на работу пора, а так я могу очень долго писать

1. Админка для Rails приложения есть в самом Rails — scaffold.
2. Я против использования ЦМС в средах с высокой абстракцией, тем более когда речь идет о средах с настолько высоким уровнем вложенного функционала как Rails. Поясню.
Вам нужен набор для рисования — ЦМС-стайл (в него входит, карандаши 65536 уветов, краски 16м цветов, фломастеры, аэрограф, кисти из 100500 видов шерсти животных, чертежная доска, студия по улице набережная д17, кв 33 с пассивным и активным освещение, заказанная выставка в Париже с открытой датой, 5 предоплаченных лотов в любом из аукционных домов Кристис, Сотбис, Бонхамс на выбор, оплаченные билеты на самолет.
Но если вам нужно рисовать на стене соседнего дома, абстрактные картины баллончиком, то все это вам не нужно вообще.
Не смотря на то что это все называется емким словом: «Искусство», вам этот ЦМС… ммм… не совсем подходит.
Вам не нужны оплаченные билеты на самолет, вы больше времени потратите если будете их сдавать в авиакассу, чтобы вам не названивал оператор:«Вы чо ваще, собираетесь лететь, не?». Вам нужена пара гемов, подъемник и балончик с краской. Зачем ради этого городить ЦМС я не понимаю. Вам достаточно написать в Gemfile

gem 'spray-paint'
gem 'lift'

и эти гемы есть, вы же не единственные кто пытается заниматься рисованием баллончиком с краской.
Тем более что прикручивать spray-paint и lift к ЦМС всеравно придется. А проблемы есть, и в цмс и без нее, и размер их одинаков, и никуда эти проблемы не денутся.

3. последний магазин который я использовал содержал:

gem 'devise' # аутентификация
gem 'haml-rails' # HAML вместо HTML
gem 'sass-rails' #sass вместо css
gem 'coffee-rails' #coffeescript вместо javascript
gem 'postmark-rails' # рассылка почты
gem 'russian' # потому что мы русские
gem 'paperclip' # для обработки картинок
gem 'delayed_job_active_record' # для отложенных задач
gem 'delayed_paperclip'    , '2.4.5.2', :git => 'git://github.com/tommeier/delayed_paperclip', :branch => 'fix_312' # для отложенной обработки(ресайза) картинок
gem 'rufus-scheduler' # типа крон, только внутри рабочего rails приложения
gem 'twitter-bootstrap-rails' # чтобы сверстать все, включая админку
gem 'aws-sdk' # для выгрузки картинок на S3
gem 'quiet_assets' # чтобы логи не шумели

админка генерируется через rails g scaffold…
ничего лишнего, всего достаточно