​​Использование Avocode для верстки сайтов.

Avocode – это продукт от компании Source, созданный специально для измученных верстальщиков. Сами Source называют его “Мост между дизайнерами и разработчиками”. Работать это будет так: дизайнер нарисовал макет, кликнул по кнопке в плагине, и макет улетел прямо в Avocode к верстальщику.

​​Что использовать для верстки+программирование — IDE или текстовый редактор?

Если учесть что в большинстве нормальных проектов верстка делается в шаблонизаторе... то однозначно IDE. Что Sublime Text, что TextMate, что Adobe Brackets, что Atom, VSCode - они все конечно прекрасны, но....никто и никогда не заменит IntelliSense, инспектирование кода и доки. Да и всего остального. Это если у Вас одностраничный сайт визитка, можно не заморачиваться, и то, я бы с этим поспорил...а если страницы минимум две, и они генерятся на backend'е или даже на frontend'е - однозначно IDE. И уж тем более если Вы не один работаете. Если же стоит CVS и нужно сделать буквально мелкую правку на коленке, где Вы однозначно понимаете что ничего не отвалится (опечатка например в string, хотя уж лучше просто отредактировать предыдущий коммит), можно и любым из популярных текстовых редакторов поправить и отправить коммит.

​​Актуальные языки для удаленки

Определенно PHP/JS(Vue, React, Angular)

Java/.Net -чаще всего в офис. Удаленка конечно есть, но это прямо очень стремно, учитывая сферу применения.

Python (django) - удаленка есть, но её мало. Плюс проекты чаще всего буржуйские, которые аутсорсит фирма из условного Ростова, Краснодара, Ярославля итд (т.е. нормально платить не шибко будут).

Если выходить на запад, то python неплох для клиентов из США, Канады, Австралии. Но это уже от тебя зависит, получишь ты или нет. Что касается asp.net то плохой вариант. Ибо .net в США используют для автоматизации каких-то предприятий, где надо находится в офисе и понимать, что и как делать, а не условно сидеть на заднице. Плюс в США часто местные фирмы (где индусы по происхождению сидят в начальниках берут заказы и передают их своим братьям)

​​Стоит ли учить Jquery в нынешнее время?

Стоит. Каждой задаче свой инструмент. Если ангуляр и реакт вошли в моду, это не значит, что способы упрощённой манипуляции домом из неё вышли. Если тебе кто-то говорит, что jQuery - костыль для людей, не умеющих нативно перебирать ноды или писать xmlhttprequest - скажи им, что компьютер - это костыль для людей, не умеющих жить без гугла и социалок. jQuery всегда будет популярен. Он упрощает простые обмены данных, классов в пределах DOM, умеет работать с ajax и значительно упрощает синтаксис.

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

JQuery самая популярная JS библиотека, даже если вы ее специально учить не будете, по-любому будете сталкиваться с ней.

​​Граница между front-end и back-end?

1. Создание UI/UX, разметки, стилизации и логики фронта - это фронт-эндер.
2. JS и архитектура фронт-приложения.
3. Чтобы правильно создать архитектуру, нужно понимать все возможные интерфейсы взаимодействия с бэком. Затем, оформить их для обмена данными с бэком.
4. Для этого - нужно знать: какие протоколы обмена данными с сервером предоставляет браузер, какие используются форматы передачи данных, логика функционирования общения с бэком: "запрос-ответ" (в разных режимах: запрос/поток, синхронно/асинхронно, и т.д.) и как их все вместе правильно использовать.

Чтобы там не говорили, бэкэнд может оставаться полностью черным ящиком только для верстальщика, и то с оговорками. Фроентэнд разработчик, даже с джун уровня, уже активно работает с получением отправкой данных, интерактивными интерфейсами и тп. Понимать как и почему некоторые штуки там работают нужно. Хорошо даже уметь быстро что-то простое сделать. Я не говорю становится фулстеком в полном смысле этого слова, НО. По хорошему: фронтендер мидл и выше уровня можно с натяжкой назвать фулстеком, просто с большим перекосом на фронт часть. Просто даже серверлесс направление, заставляет в той или иной степени понимать процессы происходящие на той стороне.
Ну и в любом случае, в случае активной практики и развития, вы сами столкнётесь с тем, что иногда нужно даже лезть и писать какие-либо свои простые скрипты.

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

​​Требования к современной верстке:

1. Media queries; знание mobile first верстки;
2. Адаптивная и кроссбраузерная (да в 2к20 иногда приходится поддерживать IE, к тому же в Mozilla и Safari все может выглядить иначе) верстка;
3. Flex box;
4. CSS grids;
5. SASS/SCSS/PostCSS (и плагины к нему);
6. Шаблонизаторы ( pug, nunjucks) и сборщик Gulp;
7. Знание современных HTML тэгов;
8. Базовые знание JQuery и отличные знания и понимание "ванильного" JS и ES6+ Javascript стандартов;
9. Паттерны верстки;
10. Понимание и использование на практике Bootstrap сетки и самого CSS фреймворка.

​​Как происходит процесс верстки на React?

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

есть несколько вариантов:
1. создание UI - библиотеки компонентов, из которых уже разработчики строят что им нужно. Это требует грамотного подхода, но если сделано как надо - то весьма удобно. Разработчик в идеале вообще ни одного html тега не пишет - везде просто компоненты из библиотеки. на элементы и на лэйаутинг. Ответственный за библиотеку уже там внутри пишет стили, верстку, обновляет под дизайн и так далее.
2. каждый разработчик создавая компонент сразу продумывает и полностью создает верстку для него.
3. разработчики пилят что-то работающее но выглядящее как мечта кубизма, потом это отдается верстальщику, который уже стизилует, поправляет теги, делает чтобы было хорошо-красиво.

во всех вариантах тот кто отвечает за верстку должен конечно знать JSX и хотя бы базовое представление о том как компоненты рендерятся в DOM-дерево.

​​JavaScript тесты от learn.javascript.ru

На странице вы можете протестировать свои знания JavaScript, выбрав один из тестов.

- Язык JavaScript(Только сам JavaScript, без браузерных и иных расширений)
- DOM, работа со страницей(Элементы, их содержимое, координаты, обработчики событий)

​​Отправка файлов с сайта на почту | SMTP скрипт

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

​​Что учить для создания мини CRM системы

Должно быть реализовано на любимом фреймворке
Backend часть
1. Авторизация в CRM системе
1.1 Поля для входа на форме (Email, пароль)
2. Модуль для отображения пользователей системы
2.0 Отображение списка пользователей
2.1 Возможность выставление прав пользователям, список (Администратор, менеджер)
2.2 Поля пользователя (email, пароль, статус)2.3 Удаление и редактирование пользователей
2.4 Смена статуса пользователям, Активный или неактивный
2.5 Редактировать список может только пользователи с правами администратор
3. Раздел отображение заявок
3.1 Вывод списка заявок
3.2 Поля у заявки (Имя клиента, Наименование заявки, наименование товар, телефон, время создания заявки, статус, комментарий, цена)
3.3 Смена статуса заявки (Принята, отказана, брак)
4. Раздел истории изменения заявок
4.1 Каким пользователям были изменены поля у заявки (Имя клиента, Наименование заявки, наименование товара, телефон, время подачи заявки, статус, комментарий, цена)
5. Добавить возможность выгрузки в CSV списка заявок, поля в CSV (Наименование заявки, товар, цена, телефон)

Frontend часть

1. Создать простую форму для отправки заявки
1.1 Поля формы (Имя клиента, телефон, комментарий, товар)
1.2 Список товаров (яблоки, апельсины, мандарины)

​​Для чего используются модули и пространства имен в TypeScript?

Зачем нужны Module и Namespace:

TypeScript появился еще до того, как в JavaScript, на котором он основан, появились какие либо модули, не то что нативные, даже эмуляций вроде commonjs или amd тогда еще не было. В те времена было в норме просто обернуть содержимое файла в замыкание, а потом либо просто подгрузить все файлы через тэг script либо просто соединить эти файлы в один. Наружу же высвечивалась одна единственная переменная, содержащая все публичное апи такого модуля, ее ложили или в глобальный объект или в другую такую-же переменную.
Конструкции module и namespace позволяют упростить создание таких переменных, избавив разработчика от написания однотипного кода. В этом плане они по сути делают одно и то же.
Сейчас это не рекомендованное использование, и стандартный плагин typescript к eslint с настройками по умолчанию запрещает эти конструкции.

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

module позволяют объявить виртуальные модули, о типах которых typescript не знает, например потому что они генерируются сборщиками вроде webpack. Яркий пример тут это css-модули или картинки, которые можно импортировать благодаря webpack, но typescript ничего не знает о их типах, поэтому нужно объявить их в глобальных декларациях

​​Когда использовать ООП?

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

ООП – это управление сложностью/декомпозиция.
если вы делаете разовую маленькую задачу, заморачиваться им нет смысла.

​​Почему верстка на div — не всегда хорошо?

Если все верстать дивами, то в крупном проекте можно потеряться.

Попробуйте использовать несколько из основных HTML5 Tag's такие как:
- header = шапка сайта
- main = оболочка для контента сайта
- footer = футер сайта
-- section = секция отдельных блоков
-- и т.д это тип основные

Дивы стандартные блоки, которые используются там, где нет возможности применить семантические теги. В любых иных случаях должны быть применены семантические теги. Это необходимо для поисковиков и для читабельности вашего кода. Таков стандарт html 5. Если вы не хотите соответствовать современным общепринятым стандартам, вы можете верстать хоть таблицами, но будте готовы к понижению позиций своего ресурса в поисковой выдаче, так же вряд ли кому то в дальнейшем понравится сопровождать ваш код.

​​Шпаргалка Wordpress #1

Ссылка на каталог: <?php echo bloginfo('template_url'); ?>

Шаблон для создания страницы:

<?php
/*
Template Name: lorem
*/
 ?>

Ссылка на изображение:

style="background-image: url('<?php echo bloginfo('template_url'); ?>/img/wallpaper.jpeg');"

Вывод статей: 

 <?php

$args = array(
 'numberposts' => 7,
 'category_name' => 'post',
 'orderby' => 'date',
 'order' => 'DESC',
 'include' => array(),
 'exclude' => array(),
 'meta_key' => '',
 'meta_value' => '',
 'post_type' => 'post',
 'suppress_filters' => true,
);


$posts = get_posts( $args );

foreach ($posts as $post){ setup_postdata($post);
 ?>

Контент


      <?php
   }

   wp_reset_postdata();

      ?>

​​Как закреплять основы javascript на практике?

1. Попытайтесь писать код без постоянно открытой документации или вообще оффлайн. Только Вы и Javascript

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

2. Берите большие проекты на GitHub, пытайтесь вникнуть в них, конечно сразу получатся не будет.

​​Практика построения объектов

Необходимые знания:

Базовая компьютерная грамотность, базовые знания HTML и CSS, знакомство с основами JavaScript (see First steps and Building blocks) и основами OOJS (Introduction to objects)

Цель:

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