среда, 1 февраля 2017 г.

Froncubator | Как изменились курсы за это время


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

Потом мы оставили курс "HTML Верстальщик" и "Frontend разработчик". Верстальщики должны были учиться 2-3 мясяца, получить основные знания по html, css и в конце могли уже сверстать сайт любой сложности. Вот только грустно мне было отпускать их с такими знаниями и я решил расширить курс, аж до 6 месяцев, где мы начали изучать основы JavaScript, научились пользоваться Gulp, ставить node.js и поднимать простой сервер на локалхосте для работы с внешним API. В общем чуваки отлично так угарели. Поэтому мы переименовали курс с "HTML Верстальшик" на "Начинающий Frontend-ер".

В это время на курсе "Frontend разработчик" училось нууу типа 2.5 человека. Проблема была в том, что он не был таким кричащим и ярким что ли, не очень было понятно, что там, зачем это, и что это может дать фронтендеру, который уже работает в этой области и самостоятельно обучается. Из-за плохого фидбека и того, что курс стал очень похож на начинающего фронтедера, мы решили его закрыть и переделать (всех 2.5 человек мы перевели на новый курс бесплатно). Назвали "Продвинутый frontend-ер" хотя на самом деле и это не правда. В ближайшее время мы переделаем название курса на "FullStack Javascript (продвинутый frontend)". Зачем? Чтобы объяснить этим, что на самом деле происходит на этом курсе.

И так, о чем же он и что там теперь? Это курс в котором мы начнем с того, что разберемся как структурировать свой проект так, чтобы потом не сломать голову. Поймем как писать хороший код на AngularJS 1 и Vue.JS. Будем работать с Socket.io чтобы получать данные в реальном времени. Перелезем на backend, который будем писать с помощью node.js. Научимся настраивать ubuntu/debian vps для своих проектов. Будем активно работать с фреймворком ExpressJS и использовать в качестве БД - MongoDB. Научимся делать десктопные приложения с помощью Electron (от GitHub). Сделаем кроссплатформенное мобильное приложение на PhoneGap. А самое главное вы осознаете, что важнее всего - это довольные пользователи и заказчики, а не количество выученных самых новомодных фреймворков и подходов к разработке. Вы поймете разницу между разработчиком и чуваком, который используют в коммерческих проектах библиотеки и фреймворки версии "0.0.2 Beta".

пятница, 20 января 2017 г.

Two Way Binding, зачем мне это, когда есть jQuery?

Давайте поговорим про Two Way Binding, что это за херня ваще?
Вот представим, что вы знаете основы JS и в основном используете jQuery. Все же ок, вас все устраивает. А теперь представим случай, когда кнопок, инпутов, переключалок и фильтров на вашей странице так много, что становится тяжело все это отслеживать. Теперь с конкретными примерами.

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

Рабочий прототип с jQuery можете скачать вот тут
https://jsfiddle.net/philsitumorang/9axr7w59/

А этот же пример с angularjs вот тут
https://jsfiddle.net/philsitumorang/rbk83hgd/

Вот у нас есть список пользователей, который пришел к нам с сервера в формате JSON.
Мы хотим вывести его с помощью jQuery где-то в нашем <body>
Выглядеть это будет примерно так:

Какие же проблемы нас ждут дальше. Главная проблема это интерактивность в нашем проекте. Теперь нужно навешивать на определенные классы события, типа click, чтобы что-то менялось.
Давайте будем нажимать на кнопку с классом .set-status чтобы менялся текст и его реальное значение в кнопке



// Почему через .on()? Потому что этот ивент у нас валяется просто где-то в $(document).ready и мы хотим, чтобы событие срабатывало тогда, как jQuery увидит элемент с классом .set-status
Вот примерно такое кол-во кода надо написать, чтобы поменять текст внутри div, при клике в зависимости от статуса пользователя. Также нужно было бы добавить ajax запрос, чтобы послать на сервер изменение статуса пользователя, а можно это все собрать в одну кучу и отправить одним запросом (тут все зависит "От"), в любом случае это дополнительное действие, нужно либо обходить снова элементы пользователей в html или работать отдельно с массивом, который мы перешлем. Короче, нет синхронности между данными и тем, что мы видим на экране, мы ее как бы эмулируем руками.

В данном случае если где-то что-то меняется и это нужно отобразить, мы должны лезть в html через jQuery и менять значения вручную и если что-то поменялось в массиве или объекте с данными о пользователе, это автоматически не поменяется во view (в html)

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

Если наступила вот такая вот боль, особенно когда ф-ционал меняется, когда верстка меняется, вы можете потерять те классы к котором вы привязывались в jQuery, значит пора переходить на что-то более серьезное, чем jQuery и Vanila JS. (С опытом вы будете сразу понимать и анализировать то, какой фреймворк вам подойдет в проекте)

Один из самых распиаренных и популярных фреймворков для таких целей был AngularJS он до сих пор очень популярен и работает хорошо! Принцип примерно такой (возьмем тот же пример с пользователями):

// исходник с контроллером user-controller.js
// и наш шаблон user-template.html

После того как мы все настроили в шаблоне, мы больше вообще не переживаем за связь между html и нашим js кодом. Как только мы получим в $scope.users массив с данными он тут же автоматически отобразится в шаблоне, а если мы решим удалить одного из пользователей мы сразу же увидим это на экране. Если решим что-то переверстать, то просто будем выводить эти данные в другом месте, теперь мы точно знаем и видим разницу между данными и версткой.

Добавим еще обработчик click в наш исходник

По этому принципу работают и другие современные фреймворки, просто у них другая реализация внутри, для тех кто не хочет вникать в кишки разницы нет кроме удобства использования подобных инструментов. Кому-то удобно это все делать с помощью ReactJS или VUE, а кто-то возможно работает с KnockoutJS и не хочет вникать в эти "уникальные" и "непохожие" друг на друга фреймворки.

В данный момент froncubator.com использует angularjs (1-й версии), сложные по структуре проекты мы делаем на нем же. Если нам нужны небольшие интерфейсные элементы используем vueJS.

froncubator.com курсы для frontend разработчиков
https://vk.com/froncubator наша группа в vk

Последовательность верстки

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

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

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

Еще мы можем посмотреть на bootstrap и то как они адаптируют верстку под разные разрешения. Если вы погуглите что-то типа "bootstrap templates demo", то можно найти большое кол-во шаблонов сверстанных с bootstrap, обычно если сайт верстается с помощью bootstrap, то стараются учитывать адаптивность. Это можно использовать как референс, чтобы иметь представление о том, как должен выглядеть сайт в мобильном разрешении. На самом деле не страшно если вы херанете большую часть графики, бекграундов, анимации и огромных лого в мобильной версии. Во-первых, чтобы продумать крутой дизайн, нужен дизайнер, а во-вторых, чем больше графических элементов, тем жирнее, страшнее и тормозит. Если вы все же решили использовать графику (я имею ввиду большие картинки и огромные иконки), то проверьте размер картинок, возможно их стоит обрезать или уменьшить, может быть немного переделать.

Вот, я все узнал и собрался верстать. Я обычно начинаю с фона, основного контейнера, и шапки. Верстаю сверху вниз. Иконки и картинки нарезаю по необходимости. Все сразу стараюсь не резать, потому что бывают ситуации при которых некоторые иконки не являются векторными, поэтому мы не можем их увеличить в 2 раза. А зачем нам вообще их увеличивать в 2 раза? Потому что retina размажет стандартный размер картинки и он будет херовым. Чтобы retina display показывал красоту, ему нужно скормить картинку в 2 раза больше по размеру, чем то, что нарисовано на макете и будет в верстке. Также вы можете использовать SVG формат, а не растровый, тогда картинка по размеру будет намного меньше и вы сможете ей задать любой размер, SVG будет всегда четкой. Если в макете вы не видите векторных слоев с иконкой, спросите у дизайнера, возможно у него есть иконки в векторе.

Когда я приступил к верстке, я не думаю о JS или о том, как будет все это выглядеть в мобильной версии, я просто знаю, что мне нужно сверстать так, чтобы блоки могли ложиться друг под друга и не наслаиваться, по возможности. Когда я сверстал большую часть макета или весь, тогда уже начинаю определять при каких разрешениях экрана сайт начинает выглядеть как говно. Определяем, что где-то там в середине есть большой блок и при разрешении 900px все идет по пизде, значит мы решаем для себя что (допустим в 980px) у нас должен стоять @media screen and (max-width: 980px) {}

Можем создать 1 отдельный css для медиа кверис и назвать его, например mobile.css. Получается, что один предел при котором все рушится мы нашли, можем адаптировать все с запасом. Начинаем уменьшать отступы, уменьшать размер шрифта, возможно где-то даже картинки придется убрать. Потом уменьшаем еще, если нам удается уменьшить размер экрана без проблем еще пикселей на 200(это просто условно), то все классно, ставим еще один @media screen and (max-width: 780px) {} и в нем снова переопределяем свойства классов, чтобы все выглядело OK. Посмотрите обязательно, какие разрешения используются в bootstrap, там есть понятие о размерах для мобилок, для планшетов и т.п. А еще погуглите разрешения для верстки, какие "средние" размеры экранов существуют, чтобы иметь представление о том, на каком устройстве скорее всего просматривают ваш сайт.

Когда mobile.css становится постепенно похож на фарш и нам тяжело его поддерживать, мы можем начать выносить эти @media в отдельные css исходники для разных страниц, просто чтобы не запутаться.

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

Еще случается, что нет просто сил сегодня делать рутину, т.е. писать кучу html и css, хочется сделать что-то посложнее, ну ок, чтобы не терять время беритесь за JS. Представим другую ситуацию, хочется сделать рутину и вообще нет сил думать, значит верстаем.

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

Старайтесь смотреть на проект с точки зрения заказчика и клиентов, не нужно упарываться ради красоты кода и респектов среди разработчиков. Если вы не успеваете сделать все, то сделайте самое основное, чтобы сайт смотрелся хорошо. Остальной функционал вы сможете потом доделать позже, иначе может получится, что у сайта есть охуительно-красивая менюшка, а остальной контент выглядит через жопу. Лучше чтобы в общем все было хорошо, а анимации на менюшке и супер-сложные интерфейсы допилите позже. Йо!

froncubator.com курсы для frontend разработчиков
https://vk.com/froncubator наша группа в vk

Как выбрать фреймворк? (frontend)

Сейчас начало 2017 года, а фреймворков становится все больше и больше), а еще больше становится статей на тему "Как выбрать фреймворк" или почему тот или иной фреймворк самый пи$датый на свете. Так вот, для начала нужно запомнить самое важное - Все супер популярные фреймворки продвигают большие компании с маркетологами, почти каждый разработчик, который выкладывает в public свою библиотеку или фреймворк хочет, чтобы его инструмент использовался другими людьми и компаниями. Это не означает что все мудаки и хотят денег и славы, нет, не всегда. Просто это означает, что каждый человек и каждая компания преследует какие-то свои цели. Компании типа google продвигают подобные вещи, чтобы заслужить доверие у разработчиков. Это хороший способ, чтобы привлечь себе кадры (ты ведь начинаешь думать, что там работают норм.пацаны), еще это отличный способ подсадить тебя на свои инструменты, чтобы потом сообщить тебе, что в их облаке или платформе все интегрировано с этим фреймворком и стоить это будет 20$ в месяц (теперь на 10 минут работы меньше делать, за 20-ку, класс!!). Чем больше сообщество вертится вокруг инструмента, тем больше бесплатных тестировщиков получает команда разработчиков. Они сразу же сообщают о багах, даже сами фиксят иногда баги и отправляют разработчикам. И вот это самый страшный момент.

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

Идем в гугл или на github (или переходим по ссылке с офф.сайта библиотеки) смотрим на кол-во звездочек. Набролось > 500-1000? Это отлично можно продолжать дальше. Смотрим на дату последнего коммита. Если не больше 1 месяца назад, значит ок. Идем в раздел Issues. В этом разделе смотрим на кол-во отправленных вопросов/багов и на их дату (если присылают часто, значит людям все еще интересен проект). Переходим во вкладу Closed (закрытые/пофикшеные баги), если ребята закрывают их хотя бы в течении недели, значит работа идет и если у вас что-то еба№ет, есть большая вероятность, что вам помогут. Обязательно погуглите, узнайте кто вообще пользуется этим фреймворком, что пишут, что говорят. Давайте так, программирование это не про психологию и философию, где нужно видеть хорошее, так что ищите минусы, ищите плохое и сомневайтесь. Потому что самые страшные вещи происходят, когда вы уже обмазались этим всем и назад дороги нет.

Представим теперь реальную ситуацию - фреймворк свежий, крутой, никто из известных и больших еще не пользовался им, обещает много и пи;дец какой няшка, хочу! Если это ваш проект, вы его сами спонсируете, дохода с сайта нет, пользователи не будут гнобить вас если что-то сломается, Оооокей, берете ставите, развлекаетесь, все хорошо. А если это коммерческий проект, самый популярный случай - вы сидите на зарплате в компании и у вас есть возможность принять участие в выборе инструмента. Перед тем как все это внедрять, даже по чуть-чуть обязательно затестите все это вне коммерческого проекта, посидите неделю другую поковыряйте его, реализуйте похожий ф-ционал в новой библиотеке/структуре/фреймворке вы должны точно быть уверенным, что вам станет удобнее работать, что все будет работать, что в команде все понимают на что идут и что некоторые вещи все равно придется самим додумывать.

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

Новый фреймворки обещают нам, что мы будем мало работать и много делать, а так же, что все будет супер производительно и мы даже можем об этом не беспокоится - сука ложь ваще!)

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

Ну и понаписал же я тут, жесть... Как выбрать то фреймворк? Простые правила:
У вас большая команда фронтендеров, а вы не готовы диктовать условия и правила игры, тогда берите AngularJS 1(не 2, потому что в марте уже выйдет 4))) или ReactJS, почему? Потому что эти фреймворки большие, они диктуют правила, команда играет по правилам и получает предсказуемый результат, если не играет и лажает, сразу видно где.

У вас есть команда, вы крутой ниндзя и вас любят и слушают, да у вас вообще все хорошо, не знаю зачем вообще вы это читаете)). Берете минимум, может у вас есть свои инструменты, своя структура проекта или вы в состоянии договорится как будете работать (это отличный вариант). Так что выбираете просто по опыту. Главное не быть принципиальной сукой! Всегда задавайте себе вопрос "А что если?". А что если никто не поймет и будет тупить? А что если все разъ:бется и кто будет чинить это кроме меня? А что если я забыл протестировать все это? и т.д.

У вас маленькая команда, которая вас слушает или вы один. Всегда стоит потестить большие фреймворки, они сложные, интересные, это пригодится для общего развития (главное сильно не упарываться, все равно во фронте все умирает за 1 год). А в реальности 1 человек делает не супер здоровенные проекты (можно сломаться физически/психически/морально) поэтому берите либы(библиотеки) берите все то, что не можете реализовать сами, берите те паттерны, которые вы понимаете и которые действительно упрощают код. Чтобы понять можете ли вы это реализовать я использую вот такой способ - Для начала я верю, что могу реализовать все сам на vanila js, а потом считаю сколько примерно времени у меня бы ушло на это + тесты + переделки и фиксы, допустим вышло около 2 недель или больше, значит я считаю что реализовать я это не могу т.к. для меня и для моих сроков это очень долго. Ищу уже реализованную фичу в гугле и так же тестирую ее как писал выше (по звездочкам на гитхабе и т.п.). И вот в какой-то момент ты уже собрал для себя пакет гов#, пакет потрясающих исходников, с опытом уже понимаешь, что тебе нужно для работы, чтобы реализовывать ф-ционал быстрее.

Ну и немного критериев для выбора инструмента: Скорость разработки, Скорость поиска и фикса багов, Общее субъективное впечатление и самое главное результат. Самое важное чтобы фичи работали, а подра№; "пооптимизировать" скорость всегда успеете.

Также не забывайте, что фреймворк не может делать ВСЕ хорошо, поэтому некоторые вещи на нем могут тормозить или быть неудобными в реализации. Выносите этот ф-ционал отдельно (вне инструмента) если это решит проблему. Если вы выбрали один жирный инструмент это не значит, что теперь вы должны действовать как фанатик.

Короче-чоъ, это тема на которую можно бесконечно говорить, VanilaJS наше все.

froncubator.com курсы для frontend разработчиков
https://vk.com/froncubator наша группа в vk

Первый пост, пост про боль!

Недавно я заценил angular 2 (меня заставили...). На самом деле в одном серьезном проекте решили попробовать. Ну так вот, FFffuucck! Через боль, но я разобрался и легче от этого не стало. Давайте по порядку, ну т.е. вообще про боль фронта я расскажу.

В то время, когда я только начинал верстать у нас был prototype.js, а jQuery был в стадии бета или типа того, короче сырой и тормозил. Мы вообще старались пользоваться JS-ом только в крайнем случае. Требования росли с каждым годом, хотели чтобы все работало без перезагрузок страницы, поэтому часто нужно было упаковывать все в скрытые блоки и по клику или каким-то ивентам их показывать, позже начали активно юзать ajax.

Вот с этого момента начался активный треш и угар. Аякса-хуякса стало так много, что мы стали забивать реализовывать вывод данных в шаблонах бекенда (впадлу). Поэтому мы намазывали jQuery + Ajax везде где только можно и выводили то, что получали с бека на фронте. Так чем же это кончилось? Говном!

Потому что намазывать структуру с помощью говнокодерских скриптов как раньше, теперь стало тяжело. Разработчики начали придумывать способы того, как собрать код так, чтобы его можно было легко поддерживать и расширять и блаблаблабла фронтендеры узнали о том, что такое паттерны проектирования, потом еще блаблаблабла и у нас появились фреймворки, которые Реально помогли писать код быстрее и не отвлекаться на всякую ерунду. Вот одни из этих фреймворков: backbone, потом knockout и angularjs и это было просто оху*ть как круто! Боль прошла, мы вообще больше не переживали на счет того, что нужно разобрать кучу инпутов на переменные забирать их из верстки и отправять на backend (и наоборот). А так же фреймворк диктовал нам правила игры и мы перестали спорить по поводу того, где и в каком исходнике, какой кусок кода писать.

Все четка, все крутатэ! Но (как же блять без НО) тормозит, а тормозило все потому что нельзя все обмазать фреймворком даже там, где это не нужно и жаловаться на это. Те кто очень не хотели вникать в angularjs (1 версии) просто засирали его тем, что он дико тормозит и что vanilajs лучше всех. Типа того что лопата лучше, чем трактор. Поэтому angular2 учел все пожелания хейтеров (почему блять хейторов, а не тех кто реально любил angular 1, не знаю...) и сделал так что теперь там нет тех самых удобных плюшек (которые тормозили), а сказал - вот есть отличная сторонняя либа, которая работает быстрее нашей из первой версии ангуляра. Сука, только она не удобная! Она не такая. Чтобы ее использовать нужно написать в 4 раза больше кода чем раньше. Выглядит это совсем не красиво, приходится искать свой способ реализации, чтобы было удобно и красиво (я не нашел такой способ до сих пор). Так же в angular2 используется новомодный webpack для сборки по умолчанию и TypeScript, чтобы придать важности, когда ты пишешь код для сраной кнопки, которая показывает popup. TypeScript строготипизированный он подходит для тех проектов, когда важно быть в курсе типов всех объектов и их ключей(или просто захерачить тип :any, когда нет совести), но далеко не каждый проект нуждается в строгой типизации на клиенте.

Что я думаю про angular 2 в данный момент - это мешок с болью. В этом мешке у меня есть такие боли как: typescript, webpack, rxjs.

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

Если вы думаете перейти на него сейчас 04 декабря 2016, не стоит. Подождите еще, пусть пройдут конференции с best practice по 2-ке, они еще 100500 раз все изменят. Не стоит выступать в качестве тестировщика на коммерческом проекте! Что используем мы во Froncubator в данный момент - AngularJS 1 (когда хотим правил игры и удобства), VueJS - когда нужно быстро запилить компонентов! Йо!

P.S. Сейчас 18/12/2016 они решили не релизить 3-ю версию (только вторая же вышла), а сразу хуйнуть 4-ку, в марте angularjs.blogspot.ru

froncubator.com курсы для frontend разработчиков
https://vk.com/froncubator наша группа в vk