Андрей

Сдается мне не полетит оно...

Вебсокеты и PHP... Батенька знаток в извращениях... :D

Все самое интересное в вебе уже лет десять как на фронт уехало, так-что что там ловить на бэке я не очень понимаю, кроме экзотических случаев все сводится к написанию еще одного REST-сервера с преферансом и барышнями. На чем писать - не суть как важно. Я могу сравнивать PHP и JS, т.к. с первого мигрировал на последний. Пару лет назад JS я откровенно недолюбливал, но жизнь заставила, я стал его изучать глубже и, внезапно, понял, простил и полюбил... После определенной практики мозг перенастроился на JS, теперь писать на PHP мне некомфортно, т.к. он как JS не умеет. Главное отличие PHP от JS в том, что первый синхронный, а второй асинхронный однопоточный. И с этим придется жить, так-как на бэкенде стиль программирования будет кардинально различаться. Например PHP без свистелок сохранять состояние между запросами не умеет, из-за этого куча накладных расходов. С другой стороны JS умеет, но толку от этого не густо, потому что на более-менее серьезном проекте придется масштабировать и, всё равно, использовать что-то для персиста стейта. С другой стороны если упал PHP, скорее всего это только один поток, а JS упадет - так все коннекты отвалятся, сколько есть. В общем плюсы и минусы есть у обоих, но для меня плюсы JS перевешивают его минусы.

Сейчас немало дистанционных вакансий. Я вот недавно так попал в команду, мне все нравится.

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

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

В конце 2015 года я задумался о том, чтобы свалить со стека php+jquery на что-то более адекватное современным реалиям. Т.к. года с 2011 ajax/spa неумолимо все больше доминирует над старомодным рендерингом средствами php, мой выбор пал на клиентсайд с JS.

До того времени (начало 2016 года) я к JS относился весьма скептически, т.к. еще свежи были впечатления от нездоровых приключений с js3 vs ie6 и иже. Тем не менее проштудировав материалы JavaScript Weird Parts и ролики Зоракса я, внезапно, понял, простил и полюбил JS.

По мере же погружения в прелести ES6+ я стал фанатом JS.

Моё стремление в сторону JS крепчало.

Из фреймворков я сначала позарился на Ember.JS, но что-то путное на нем слепить с наскоку оказалось задачей непосильной, хотя он, безусловно, крут.

Angular v1 мне сразу не понравился чисто интуитивно, как оказалось, это решение было верным.

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

Параллельно, впервые за 20 лет практики, я внезапно стал дистанционно "ходить" по собесам, и .... круто обламываться. Особо больно было в первые 2-3 раза. Сказались дурные привычки юности - стремление изучать только то, что конкретно приносит пользу здесь и сейчас, игнорируя "тупую", "бесполезную" теорию. Сыпался на таких мелочах, что стыдно вспомнить...

Еще очень сильно сказывалось то, что 20 лет я работал человеком-оркестром и мастером на все руки сольно в непрофильных конторах. Не было никакой конкуренции от слова совсем и никто не направлял меня мудрой и крепкой рукой в верное русло. Поэтому я болтался как щепка в бурю куда судьба пошлет. Мог и могу везде и всё, но ничего толком и всегда требуется прилично времени, чтобы разобраться да вникнуть.

В общем я осознал, что дальше так продолжаться не может и нужно кардинально сменить парадигму и стратегию. Записал себя в джуны и стал прилежно учить все подряд, что касается тематики фронтенда и JS в частности. Этот финт ушами почти даже не жахнул по моему самолюбию и самооценке, т.к. багаж прошлых заслуг все равно рулит и весьма существенно помогает. Какие бы новые языки не изобрели, какие бы новые навороченные фреймворки не нарожали - базовые принципы всё те же, а когда ими владеешь, то все остальное - дело времени и усилий.

Так вот, чтобы переформатировать мозги с пыхи на JS мне нужно было попрактиковаться несколько сотен часов. Я весьма ленив, поэтому сам себе задачки придумывать бросил сразу после школы и школьных олимпиад - наигрался. Тем не менее без практики никуда, поэтому я пошел на кодварс (пруф: https://www.codewars.com/users/iCoderXXI) и стал решать там всё подряд. Поначалу код был ужасен, но работал, постепенно мозг привык и качество кода стало расти. Параллельно стало сложно писать на пыхе, ибо кода получается существенно больше при аналогичном выхлопе. Подобный инцидент у меня случился году в 2006, когда я с клиппера мигрировал на пыху, потом было сложно писать на клиппере, ибо он убог. Пока я не знал пыхи, клиппер мне казался весьма недурным языком. :)

В общем материалов и приёмов пришлось освоить массу, на все про все у меня ушло более 1.5 лет в режиме 2-4+ часа ежедневных занятий. За это время я умудрился завалить порядка 10 собесов, пока, наконец, не выстрелило.

Тем не менее мне еще очень многому предстоит научиться, т.к., по сути, мой потенциал - это матёрый сеньёр/архитектор, а реально я пока мидл по части фронтенда. :) Рассчитываю за следующие пару лет устранить этот досадный разрыв.

Это я все к тому написал, что переучиться можно в любом возрасте (мне 36), было бы желание и упорство.

В общем я настоятельно рекомендую упор делать в JS/HTML5+/CSS3+ и React/Vue (хотя тут по вкусу, но на эти два "фреймворка" приходится существенная доля вакансий и заказов).

ВАЖНО! Если раньше не доводилось программировать, то в обязательном порядке параллельно с JS нужно освоить базовые знания/навыки в алгоритмах и структурах данных, а, так же, базовый уровень в информационных технологиях, иначе многое будет просто непонятно, будешь буксовать часами и днями на всяких глупостях.

P.S.: На htmlacademy курс мне нравится (я там подрабатываю наставником). Однако мне очень хочется, чтобы курсанты приходили несколько более подготовленные по части алгоритмов и структур данных.

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

Казалось бы, при чем тут математика? А при том, что как без нее вычислять?

Поэтому, что бы ни делал компьютер, играет ли он музыку, рендерит ли 3D, ходит ли в интернет, в конечном счете все сводится к вычислениям, а, стало быть, к математике. Дважды занавес.

Предположу, что JS ты уже знаешь, из чего следует что Node.JS тебе освоить будет намного проще, чем PHP. Правда вместо Express я бы, все же, рекомендовал Koa2, его пилят те же разработчики, но он сильно посовременнее.

Знать как следует язык программирования, безусловно, штука весьма полезная и нужная.

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

Поэтому окромя языка я бы настоятельно рекомендовал от души попрактиковаться в структурах данных, алгоритмах и паттернах. Тут, как говорится, нужно наработать минимум 1000 часов, чтобы навык ушел на уровень рефлексов и работал автоматически. А совершенствовать скиллы ты будешь всю оставшуюся жизнь, ибо нет предела совершенству.

По части именно JavaScript вот этот курс отлично мне поставил мозги на место в своё время https://www.youtube.com/watch?v=bzuelEN1Kg8&list=P... прям аж до просветления.

React рендерится в заданный элемент, можно разные компоненты рендерить в разные элементы. Нужно отчетливо понимать, что у React совершенно другая концепция, нежели чем у jQuery.

С jQuery ты, в основном, мутируешь DOM. С React ты конвертируешься пропсы и стейт в разметку. Поэтому требуется совершенно другой подход в разработке. В этом основная сложность.

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

Когда решил что основным ЯП у меня теперь будет JS, надо было переформатировать мозги, для этого сотню-другую часов интенсивно что-то кодить, не важно что, важно чтобы на JS и в хорошем темпе.

Тут, как раз, Кодварс подвернулся. Прокачался до 2.5 qyu и подзабросил, но эффект получил должный, теперь на php кодить не так комфортно (иногда совсем не так).

Чужие решения смотреть тоже интересно, иногда думаешь вот ведь круто, но в прод я бы такое не выпустил.

Сами алгоритмы с кодварс в реале вряд ли понадобятся, а вот составные их части очень даже.

в общем для меня кодварс оказался весьма приятным и эффективным способом привыкнуть к ЯП.

jQuery был хорош, но ничто не стоит на месте. Раньше фронтенд никто особо не воспринимал всерьез. Все считали, что фронтенд - это несколько скриптов, которые принципиально погоды не делают. Все изменилось с ростом популярность SPA, в т.ч. и благодаря бурному развитию JS.

В любом приложении очень важно прозрачно и понятно управлять состоянием, очень желательно делать это централизованно. Былой подход с участием jQuery делает это невозможным. Кто угодно может менять что угодно на странице, когда угодно, и приложение об этом ничего не знает без очень хитровыдуманных методов. Например в первом ангуляре для этого постоянно бегал по элементам и проверял что там изменилось, это называется "грязные проверки" (dirty checking). Мягко говоря это ни разу не оптимальный способ контроля состояния, но, на тот момент, вариантов особо не было.

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

В каких-то простых страничках с парой-тройкой функций jQuery даже сегодня может быть актуален, особенно если приложить усилия и делать грамотно.

Но что-то чуть более сложное уже требует совершенно иного подхода.

У каждого HR/техлида, который будет собеседовать, свои представления о прекрасном. Есть база, которую надо знать, иначе будешь плавать категорически, все остальное - по мере необходимости (имхо). Если с инглишем туго, то сожалею, хотя у кантора весьма недурной ресурс, да и есть платные качественные курсы по JS. Опять же зоракс на ютубе доходчиво объясняет базу.

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

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

Часто в требованиях проходит понимание ООП, умение применять паттерны проектирования. Имхо тема мутная, потому что без грамотного наставника можно здорово внетуда "научиться". Но, все же. Мне лично ближе JavaScript с обоих концов интернет-канала.

Опыт, сын ошибок трудных, приходит со временем.

JS - это как токарный 4D-станок с цифровым управлением. Одно дело - научиться им пользоваться, другое дело, делать с его помощью что-то конкретное и полезное, нужное. Это две совершенно разные, но тесно связанные задачи.

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

Все приходит со временем, по мере практики. Другого пути не существует.

И да, алгоритмику никто не отменял, иначе на ровном месте будешь буксовать. Поэтому идем бодро на любой из выше рекомендованных ресурсов и решаем задачки сотнями, смотрим на решения других и плачем. :)

Проще всего научиться на практике. Я нашел несколько годных скринкастов и повторял 1 в 1 за ведущим. Вообще всегда так делал с новым языком.

В процессе привыкаешь, пропадает страх и туман в голове, дальше уже можно делать шаг вправо-влево и что-то своё наверчивать.

Одна проблема в том, что реакт бурно развивается, и огромное множество материалов по нему уже устарели, т.е. ты будешь учиться тому, что уже не актуально. Поэтому ищи материалы не старше года, в идеале не старше 6 месяцев.

Во первых необходима годная архитектура приложения. Я за счет жеско opinionated структуры путей в своем нано-фреймворке на 90% снизил оверхед на "подумать" а где у меня что.

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

В третьих иммутабельность. Если ты меняешь в одно месте, а сломалось/упало в другом, то поздравляю, поциент, у вас мутабельность третьей степени и это фатально. Все что можно перевести в pure functions и immutable structures (тут с осторожностью, ибо можно выстрелить себе в ногу и уронить производительность ниже плинтуса).

Опять же, единственный source of truth спасает.

И самое главное, код надо писать так, чтобы он был понятен с первого взгляда, максимум со второго. Не надо в коде выеживаться и быть многословным. Код должен быть простым и лаконичным. Говоря что snake_case более читабельный, чем километровыйКамелКейс. Я, пожалуй, соглашусь, хотя использую в коде последний в основном.

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

По крайней мере в последние годы я с ходу понимаю что я там намудрил в проекте и через месяц, и через 6, и через 2 года. А раньше да, бывало через 3 месяца хотелось убить того ишака, который это написал, а потом вспоминаешь, что это был ты сам... :D

Еще момент - хорошо структурированные данные помогают писать более прозрачный код.

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

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

Так же спасает автоматизация и кодогенерация, но тут необходим опыт. Я с 2006 года до 2011 собрал много грабель как фуллстэк веб девелопер, с 2009 года присматривался к ряду фреймворков, не срослось - написал свой, с тех пор полет нормальный. Необходимые задачи он решает и по части архитектуры берет на себя примерно 80% нагрузки. За 5+ лет я его потихоньку допиливаю когда возникают новые ситуации.

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

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

Я этот взял wedgies.github.io/jquery-emoji-picker/demo.html

У него смайлики вшиты в CSS, не надо стопицот картинок подгружать.
Второй плюс в том, что он нормально работает со стандартными инпутами, не нужно никакой магии.
Единственное с чем пришлось конкретно загимориться (это никак с самим плагином не связанно) это отсылать эмоджи в subject'е мейлов, при том, что там кодировка ни разу не UTF (с легаси сложно спорить... :) )