• Кнут - "Искусство программирования", как осилить?

    Deerenaros
    @Deerenaros
    Программист, математик, задрот и даже чуть инженер
    Да как же это смешно... Звучит примерно так: имеется интерес освоить хирургию, да только я туп на анатомию и биологию, да и руки кривые, ещё и дрожат. Если не в ладах с математикой, то Кнут не поможет. И вообще, веб-программирование так же относиться к математике, как балет к кулинарии. Сидите смирно и не парьтесь на этот счёт, вероятность того, что Кнут вам чем-то поможет в работе исчезающе мала, тогда как навредить он может на раз-два: можно запросто поймать себя на создании велосипедов.

    Впрочем, варианты есть. Первое, что надо осознать - это дискретная математика. Начинается с арифметики, но вполне можно освоить её параллельно. Тут подойдёт что угодно, хоть учебник за первый-второй курс почти любой технической специальности. Алсо, у самого Кнута есть КонКретная математика. Вполне себе годная писанина, правда для того чтобы проще читалось таки надо иметь хотя бы базовые понятия из дискретной математики: поля с кольцами, да пару свойств. Глубоко копать не стоит. И если что, я предупреждал.

    Впрочем, вместо кнута рекомендую Кормена. Очень даже вещь в себе: её читают как на первом курсе, так и диссертации по ней пишут. И читается проще, и зубодробительной математики в ней нет.
    Ответ написан
    9 комментариев
  • Куда двигаться в веб-разработке?

    cyberyak
    @cyberyak
    Куда двигаться в веб-разработке? - Подальше от России
    Ответ написан
    Комментировать
  • Куда двигаться в веб-разработке?

    @rsi
    software engineer
    Перво наперво определитесь, хотите ли вы стать профессионалом или просто хорошо делать сайты. Я бы предложил выбрать путь профессионала.

    Во вторых определитесь, каким именно профессионалом вы хотите стать:
    1. web - мастером
    2. Front end
    3. Back end
    4. Desktop
    5. Другого направления


    Как только вы определитесь с направлением, делайте основной упор на изучение тонкостей свойственных именного этого направления.

    Здесь вам советовали сменить язык, не слушайте этих советов. Да Ruby имеет некоторые преимущества перед php, но имеет и недостатки. Не думайте, что если вы выберите Ruby (python) ваша жизнь измениться, вы не получите ничего, что не может вам дать php и на оборот, эти увеличенные зп и прочее миф, язык не важен. Помните, ЯП это всего лишь инструмент, вы конечно должны иметь инструмент, и должны знать свой инструмент в совершенстве, но умение программировать заключается не в этом. Да, плотник алкоголик, который зарабатывает на жизнь забивая гвозди, может хвалить свой молоток и всем рассказать, что молоток его кормилец, но согласитесь настоящий строитель умеет не только гвозди мотком забивать, не говоря уже об архитекторе, который молоток и в руках мог вообще не держать.

    И так предположим, вы выбрали свой путь, вы выбрали направление и выбрали инструмент. Теперь вам нужно работать в этом направлении (как над собой, так и в буквальном смысле работать). Читайте статьи, читайте книги (я всегда рекомендую только одну книгу - "Совершенный код", ее без преувеличивания должен прочитать каждый программист), изучайте новые фреймворки, технологии, отрасль постоянно движется вперед, вам нужно двигаться вперед еще быстрее, что бы хотя бы не стоять на месте. В процессе работы над проектами вы будете чувствовать нехватку знаний (вы упоминали js, ООП), устраняйте эти пробелы книгами (не стоит бояться 900 страниц, книги вы ничем не замените, их необходимо читать), статьями и конечно практикой. Не переживайте по поводу отсутствия высшего образования, оно не дает глубокого знания, никто не расскажет вам ни каких трюков, если у вас не будет толкового преподавателя. Но толковый преподаватель, это не обязательно учитель в универе, это может быть автор книги (например Макконел), автор хорошего инструмента (например Taylor Otwell), большинство очень известных и авторитетных людей генерирует тонну информации, книги, статьи, записи в соц. сетях, код, все это можно читать и это даст вам куда больше чем ВО. И да, мы с вами живем в уникальное время, время интернета, где нет расстояний, и это дает намного больше возможностей, чем нагуглить очередной костыль для jquery от школьника, вы можете общаться лично например со Страуструпом или тем же Тейлором, ни в одном учебном заведении России у вас не будет возможности поговорить с такими людьми.

    Подведя итог:
    1. Определите путь (хотя бы примерно)
    2. Определите специализацию (хотя бы примерно)
    3. Выберите инструмент (один основной язык, один основной фреймоврк, одну основную cms и тд)
    4. Изучите свой инструмент в совершенстве
    5. Пробуйте другие инструменты (да я сказал один яп, один фреймворк, но один вы должны знать в совершенстве, остальные должны попробовать)
    6. Расширяйте кругозор
    7. Работайте над собой
    8. Работайте
    9. Выберите наставников и учитесь у них


    Следуя этим советам вы увеличите свой скилл, сможете сами отвечать на вопрос заданный в заголовке и станете профессионалом. И помните путь профессионала, это постоянная работа (как буквально работа, так и работа над собой, если просто писать сайты 24/7 вы тоже профессионалом не станете), гораздо больше чем 8 часов в день, 5 дней в неделю.
    Ответ написан
    Комментировать
  • Сайт без перезагрузки страницы - шаг вперед?

    @IceJOKER
    Web/Android developer
    history api ( habrahabr.ru/post/123106 ) для смены url , или опираясь на location.hash (aka что-то вроде site.ru/#trololo).
    А насчет одного html документа - это по желанию, создавайте хоть 100500, и насчет body тоже по желанию, то есть можно и конкретный div менять, а не полностью body
    Ответ написан
    2 комментария
  • Цена на IT-технологии выросли из-за кризиса?

    @mamkaololosha
    в России, да и во всем мире - кризис
    Капитализм сам по себе - кризис. Если ты не будешь продавать лучше соседа, то у тебя будет кризис. Если придет на твой рынок китаец-монополист, то у тебя будет кризис. Если ты не увеличишь продажи на +130% за этот год, то у тебя будет кризис. У тебя покупают больше? Ок. Меньше? Будет кризис.

    Нефть подешевела в пять раз
    news.yandex.ru/quotes/1006.html тут ясно видно, что в 2, а не в 5.

    они страдают от дешевого бензина и обжерательством
    дешевых деликатесов

    Как там пропаганда в 60е-70е? Сейчас этим никто не страдает. В Германии подоходка 40% для тех у кого больше 50к евро в год.

    Но в России не смотря на дешевую нефть, нефтепродукты дорожают
    Это вам так инстинкт самосохранения сказал или кто? Вы же не нефтяник. Нас 140млн, много земли. Много всего нужно обслуживать.

    Дорожают они наверное по тому, что люди не превыкли и не хотят терять прежних доходов
    Доходы никто не теряет. Теряют ресейлеры. А то, что поколение 80-90х годов не пришло на завод это вы у себя спросите. Свободные слишком.
    Ответ написан
    Комментировать
  • Как быстро подтянуть свой уровень веб-разработчика, чтобы соотвествовать требованиям работодателей?

    5angel
    @5angel
    Фронтенд-лид
    Давайте обратимся к данной публикации, чтобы понять примерные тренды, потому что наиболее выгодный вариант – это все же фронтендер.

    Вкратце, полноценный клиентский разработчик должен знать:
    – html5/css3 + bootstrap
    – один-два препроцессора (less/stylus)
    – чистый js и пару-тройку клиентских библиотек или фреймворков (knockout/backbone/angular/react)
    – немного node.js, чтобы уметь пользоваться пакетным менеджером (npm) и билд-менеджером (gulp/grunt)

    Этот список покрывает большинство клиентских задач в средней студии или стартапе.

    В реальности, от разработчика требуется только одно – уметь быстро накостылять какую-нибудь фичу к релизу, который должен был быть вчера. Собственно, если внимательно посмотреть на список, который я привел, можно заметить, что все эти вещи направлены на максимально быструю разработку – тут костыль, там костыль – и в продакшн. Как бы ни пытались нагнать пафоса на собеседовании, в бою будет именно так.

    Другой вопрос – что со всем этим делать.

    Я обычно предлагаю попытаться начать свой маленький проект. Какой-нибудь простенький личный сайт, игру на js (тот же flappy bird или 1048 – много ума здесь не нужно). Посложнее – свою тему или библиотечку. Это будет хорошим практическим опытом, который не стыдно описать в резюме.

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

    Если говорить о личном опыте, то я неплохо подтянул js с помощью codewars – задачки начинаются от самых простых (преобразование строк, перебор массива), до очевидно тяжелых (собственные интерпретаторы и преобразование данных изображения).

    А вот попытка спихнуть на верстальщика UI/UX – это уже экономия со стороны отдельных контор, которые по какой-то причине не хотят нанимать отдельного дизайнера/проектировщика в штат или по контракту. Тут, к сожалению, придется мириться и смотреть статьи по теме – тот же GoodUI.
    Ответ написан
    10 комментариев
  • Как побороть свою лень?

    jlekapb
    @jlekapb
    .do
    -Определитесь с целью
    -Пишите списки дел на день
    -Попробуйте метод помодоро:
    https://ru.wikipedia.org/wiki/%D0%9F%D0%BE%D0%BC%D...

    Если тяжело усидеть 25 минут, начните с меньшего времени, например, 10 минут.

    ps. Если есть возможность, пишите каждый день, можно велосипеды :)
    Через месяц у вас появится привычка и будет легче, быстрее и продуктивнее.

    Главное - цель. Записывайте свои результаты и достижения: позже, перечитав их получите новые идеи и дополнительную мотивацию.
    Ответ написан
    Комментировать
  • Какие есть тематические сайты для front-end разработчика?

    jlekapb
    @jlekapb
    .do
    Рецепты на codepen.io и ему подобных :)
    Ответ написан
    Комментировать
  • Как повысить знания в области архитектуры веб проектов?

    @FoxInSox
    На работу устраивайтесь, а не "видео-уроки" смотрите.
    Ответ написан
    8 комментариев
  • Чем отличается верстальщик от front-end developer?

    copist
    @copist
    Empower people to give
    Верстальщик преобразует графический макет (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...
    Ответ написан
    2 комментария
  • Как сделать зафиксированный внизу подвал увеличивающимся по достижению конца длинной страницы?

    @aivenreach
    Держи - Jsfiddle.
    Чтобы изменить высоту футера, меняй значение переменной x.
    Чем оно меньше, тем выше будет футер.
    upd - обновил ссылку на jsfiddle.
    Ответ написан
    4 комментария
  • Как узнать уровень фронтенд разработчика?

    Petroveg
    @Petroveg
    Миром правят маленькие с#@&ки
    @tnorman уровень логики не ниже, чем на серверной стороне?)) Посмешили.
    Фронт-енд разработчик должен разбираться во фронт-енде, а не в PHP — фтопку PHP, вообще никакого PHP.

    Основы построения баз — да, поскольку появится возможность работы с базами напрямую. Понимать принципы общения с сервером и другими компьютерами, знать про HTTP-заголовки, политику безопасности и, в частности, политику происхождения документа. То есть знание XMLHttpRequest, CORS и (хотя бы) представление о WebSocket, WebRTC.

    Разбираться в клиентских технологиях — HTML, CSS, Javascript, SVG, canvas, многочисленные API, описанные в HTML. И если не знать про WebGL и API, то разбираться зачем это и к чему. Построение DOM, CSSOM, понимание узких мест и тенденций. Основные семантические конструкции и микроданные.

    Понимать box model, visual formatting model, stacking context, работу с формами и элементами, медиа-элементами. Знать, что такое кодировка и как жить с разными кодировками при необходимости, хотя это уже редкость.

    ООП соглашусь — наследование, инкапсуляция, понимание роли прототипов и умение их использовать. Знание основных паттернов и парадигм. Добавлю модель событий — просто знание (не жалкие 5 штук, а реальный охват, включая MutationObserver). Ну и регулярные выражения.

    AJAX? Если не брать в расчёт XML-RPC, SOAP, WSDL, то выделять это в отдельный вопрос не стоит. А вот event loop (включая tasks и microtasks), на который завязана модель событий и все асинхронные вызовы знать обязательно. Также быть в курсе, что такое promise, зачем они и как использовать.

    Знать основы проектирования, UX и построения UI. Очень много в работе фронт-енда основано на взаимодействии человека и интерфейса. Непонимание основ UX приводит к неприятным последствиям.

    Что же насчёт Backbone или других конкретных технологий — это вообще дело наживное и акцентировать внимание не стоит. Опыт приветствуется, но не является обязательным. ну только если проект не горит.
    Безусловно, знание технологий разработки нужно, но я бы тогда поставил на Node.js, Grunt/Gulp, AngularJS.
    Ответ написан
    5 комментариев
  • Как стажеру лучше понять JavaScript?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    в студию пришёл парень - стажер, недавно закончивший вуз.

    Ну да, один мой знакомый...

    Зайдя на learn.javascript.ru, я понял, что многие задачи, действительно, не для новичков.

    Ошибаетесь. Что тогда есть "для новичков"? на jquery плагины подключать? Если брать раздел "Функции и Замыкания", там основы основ. Просто если что-то не понятно - вперед гуглить. Встретил непонятное слово - гуглить, вики, словари, google translate и т.д.
    Ответ написан
    Комментировать
  • Есть альтернативы БЭМ?

    @Quilin
    Full-stack разработчик
    Странное ощущение, что это троловопрос. Тем не менее.

    Вы же понимаете, что методология БЭМ именования классов касается лишь постольку поскольку? Никто из тех, кто пользуется БЭМ в жизни не пишет все эти названия классов вручную, код на выходе может быть тяжеловесным, но та его часть, с которой работает разработчик - лаконичная и адекватная. Хотя, конечно, это зависит от вашего навыка проектирования и разработки. В самом Яндексе, уверяю, далеко не всегда код симпатичный и удобный.

    Если вы собрались переводить ваш сайт с одного подхода на другой, вы так или иначе встанете перед дилеммой: переписывать все или переписывать не все. Другой вопрос, что двойственный подход может стоить вам куда больше полной переписки.

    Исключительно в ваших силах не превращать все в выгребную кучу. Я, например, пользуюсь совершенно тривиальным подходом в верстке, который на достаточно серьезных проектах так и не скатился в тартарары.
    1. Побольше частичных представлений данных. Конечно, не на каждый чих, но на каждую более-менее абстрактную часть модели.
    2. На каждое частичное представление - свой css-файл.
    3. Каждый элемент взаимодействия с пользователем - свой js-компонент.

    Обычный todo-mvc превращается с таким подходом вот в такую структуру:

    todo/
    todo.view
    todo.css
    todo.js
    todo_test.js
    todoitem/
    todoitem.partial
    todoitem.css
    todoitem.js
    todoitem_test.js

    Каждое представление состоит из маленького куска верстки, редко больше 50 строк. Каждый css- и js-файл - аналогично. Последний проект, который я делал по такой схеме пережил два года, примерно 10000 коммитов верстки, представлял собой мастер оплаты, веб-приложение и три админки к нему, и до сих пор адекватно функционирует и изменяется.
    Ответ написан
    Комментировать
  • Объясните что такое полиморфизм простыми словами ?

    Deerenaros
    @Deerenaros
    Программист, математик, задрот и даже чуть инженер
    Да ладно, парни. Ну хватит уже, к чему такие сложности? Берём и читаем. Вообще совсем не обязательно читать про архитектуру и абстракции именно по своему языку, хотя javascript в этом плане родился уродом.

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

    Собственно, представим себе рядом стакан, кружку, чайник, кофемашину, велосипед и скейт. Что между ними всеми общего? Ну как минимум то, что они есть. То есть это - объекты, которые были созданы. Но как они были созданы? Скорее всего на заводе производителя по чертежам. Ок, чертежём назовём конструктор. Ну а класс? А что это такое? А его нет в нашей вселенной - эта сущность есть абстракция, что живёт лишь в наших мыслях. В реальном мире её нет и никогда не будет, такова уж физика - ей по барабану, что птицы и млекопитающие имеют дальних родственников - она лишь обеспечивает возможность естесственного отбора. А уж родственников друг другу находим мы, люди.

    С объектами и классами разобрались, а что же там с нашими стаканами и велосипедами. Мы уже поняли, что всё это объект, то есть грубо можно все объекты наследовать от какого-нибудь суперпредка, суперкласса, что и реализовано в некоторых языках. Но что другого общего между скейтом и стаканом, например? Конечно, можно углубляться и считать, что они все из молекул, и они все из твёрдых веществ. Однако это всё бред и СПГС, так что ответ прост - да ничего. То есть это совершенно разные объекты с совершенно разным функционалом. Более того - естесственно компьютерные модели и иерархии будут сильно отличатся от физик и химий. И это нормально, вопрос об адекватностях моделей ставиться лишь когда модель неадекватна, а до тех пор пилить можно что угодно, лишь бы работало.

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

    Однако что с остальным? У нас ещё абстракция, инкапсуляция и наследование. Ок, начнём с наследования, так оно наиболее близко. Вот что у нас общего между стаканом и кружкой? Ну в оба можно налить воду, но у кружки есть ручка чтобы держаться. То есть можно придумать некий общий класс - ёмкость. Однако что это за класс? Можно например за этот класс взять стакан, тогда все ёмкости по дефолту стаканы, а всё остальное - видоизменённые стаканы. Но кому-то больше нравяться кувшины, например некоторые чики насят их на голове, считая что это удобно. Ну и пусть носят, но как-то же решить надо, что главнее и идеальнее. Так вот - недостяжимый идеал и есть главный - это называется абстрактный класс. То есть ёмкость, что невозможно создать, для которого нет полного чертежа. А все чертежи, что дополнили до полного - есть наследованные классы от класса ёмкость.

    Тут мы подошли к абстракции. Вот такое иерархическое наследование приводит нас к, возможно главной, идее ООП. Вот мы взяли и выделили всё, куда можно налить воду в отдельный класс, нарисовали общий чертёж, но специально не доделали его, оставив зазор для будущих творцов, и назвали чертёж - ёмкость. Тысячи лет изобретатили всех миров создают свои ёмкости, одна лучше другой. Для разных людей - по разному, конечно. Но каждый раз группировать молекулы стекла определённым образом - непростая задача. Поэтому ремесленники пошли на хитрость, они создали тайный совет ремесленников мира и решили делиться друг с другом своими наработками. То есть создавать мелкие чертежи и объявлять классом, например, извлистой ручки в форме ленты Мёбиуса, например. Возможно такая ручка удобно только инопланетным существам, но чертёж создан и к нему можно ссылаться при создании своего чертежа. Таким образом мы абстрагируемся от низкоуровневой задачи "формирования ёмкостей посредством перемещения молекул" к "конструированию ёмкости посредством совмещения деталей, элементов". Это и есть абстракция.

    Но мы подошли к последнему пункту - инкапсуляция. Она неразрывна с абстракцией, и по сути благодаря ей она и работает. Инкапсуляция - это своеборазный клей (или синяя изолента), которым склеивают разные чертежи в один. То есть совмещение деталей для создания своей - это и есть инкапсуляция. Причём при совмещении мы можем не описывать детали этого совмещения (то есть члены класса могут быть приватными), таким образом помогая абстрагироваться тем, кто этот чертёж использует. Вот посмотрим на чайник - что это такое? Это стакан (или кружка) к которому снизу (а может внутри по середине?) приклеен нагревательный элемент. Пустив по нему ток, согласно инкапсулированному в нагревательный элемент закону Ома, будет выделяться тепло и нагреваться вода. А кофемашина? Это куда более сложное устройство, с множеством насосов, ёмкостей, шлюзов, измельчителей и чайников. И всё склееное клеем. А может синей изолентой. Это снова инкапсуляция.

    Таким образом, абстракция невозможна без инкапсуляции и наследовании, как невозможен полиморфизм без, собственно, наследования. Ну а полиморфизм невозможен ещё и без инкапсуляции, которая банально бесполезна без наследования и полиморфизма. Вот такие тут треугольники с пирогами. Жаль только про пирог наврали. И про день рожденье.
    Ответ написан
    3 комментария
  • PSD to HTML - как это делают?

    @lnked
    5$ очень низкая цена, за 5 баксов я бы максимум сверастал второстепенную типовую страницу

    Очень помогает в работе:
    https://projectparfait.adobe.com/
    Sublime Text + emmet
    Ответ написан
    Комментировать
  • Как/на чем заработать обычному верстальщику?

    Deerenaros
    @Deerenaros
    Программист, математик, задрот и даже чуть инженер
    Общие советы, что уже были даны:
    + учи js,
    + учи english хотя бы до intermediate,
    + генерируй портфолио,
    + какой же верстальщик без своего сайта? сделай его идеальным и храни там своё портфолио и контакты, по возможности ставь на создаваемые сайты свой копирайт со ссылкой на портфолио (конечно, если заказчик не возражает),
    + в свободное время потерзай какой нибудь backend (RoR или Django)

    От себя добавлю: бросай PHP и никогда о нём не думай, может он и становиться лучше, но ему никогда не избавиться от своего тёмного прошлого (и переменных со знака доллара, вот ужас!). Когда будет пара хороших отзывов, смело иди на фриланс биржи, вроде odesk. C RoR и хорошим, красивым, технологичным, кроссбраузерным фротендом там вполне можно иметь и по $100 в час.

    Ах да, учись быстро копипастить. Использовать плагины. Избавляйся от всяческих попыток напилить велосипед, даже если так будет быстрее и лучше. Со временем, это мастерство позволит тебе делать сайты со скоростью пулемёта. Тогда ты постигнешь тёмный дзен и получишь свою порцию печенек. Я на полном серьёзе, когда ты поднимаешь сервер за 2 минуты, ставишь на него Bootstrap за 1 минуту и подгоняешь его (натягиваешь вёрстку из заранее созданных темплейтов) за 5 минут, обвешиваешь нужными виджетами из js, html5 и css3 за 5 минут и через 15 минут после получения заказа отправляешь заказчику наступает странное чувство эйфории. Конечно, это непостяжимый дзен, как всегда, по закону Мёрфи, какая-нибудь библиотека отвалиться, что-нибудь заглючит, а где-нибудь поползёт вёрстка и дебаг займёт пару часов, но всё же, делать полноценный сайт за 3 часа - бесценно. Для всего остального есть MasterCard.
    Ответ написан
    48 комментариев
  • Сложно ли выучить javascript?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    под js уже есть готовые движки для 2D и 3D Игр.

    По поводу сколько может занять времени обучения... основы (синтаксис, логические конструкции, прототипное наследование) можно освоить за месяц два, но без каких-то основ в алгоритмизации это будет тяжело и думаю у вас уйдет пол года на осознание что вы вообще делаете. + еще пару месяцев для осознания как писать асинхронные функции не превращая код в неконтролируемое месиво. + по паре недель на все те технологии, которые могут вам понадобиться (на начальном уровне, штуки типа canvas, audio api и что вам там еще нужно).

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

    И это я еще не учитывал практики типа tdd/bdd, покрытие кода тестами (что особенно важно при разработке какого-то инструмента)... А еще есть коварные особенности различных браузеров (даже в одном браузере в различных версиях может быть много коварных проблем).
    Ответ написан
    Комментировать