mkmister

Компиляторы-транспиляторы-трансляторы (типа Coffee, LESS, Jade), тест-раннеры, стайл-чекеры и линтеры (mocha, chai, karma, (js|es)lint, jscs), плагины для таск-раннеров (grunt-contrib-watch, gulp-jade) — все это обычно ставится как --save-dev, потому что нужно только тем, кто контрибьютит в этот проект, работает с его кодом.

Библиотеки и фреймворки (expressjs, jquery, backbone), на основе которых работает ваш код, без которых ваш код не запустится у его потребителя — ставятся как --save.

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

Источник: https://habrahabr.ru/post/282764/

Докер - виртуализация приложения. Приведу пример.

Вы разрабатываете некое веб-приложение на java, и вам его нужно тестировать под java7, java8 и под tomcat 7, tomcat 8.

Вы можете купить 4 компьютера, поставить на них 4 варианта, протестировать. Затем все поставить заново для следующего теста. Неудобно, долго, дорого.

На помощь приходит виртуальная машина - вы можете купить 1 компьютер, на нем завести 4 виртуалки, каждую из них настроить, сохранить образы. После тестирования просто восстанавливаете исходное состояние из образов.
Гораздо дешевле, чем раньше. Но каждая виртуальная машина требует процессоры, память, кучу места на диске под операционку. А ведь отличается по сути всего 2 компонента.

На помощь приходит докер. Один комп, одна операционная система. 4 докер контейнера с нужной версией java и томкат. После тестирования контейнер можно удалить и развернуть заранее подготовленный.
Дешевле и быстрее, чем все вышеперечисленное. Потому что операционка одна, нет лишних расходов на CPU и память. Ужиматься дальше практически некуда.

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

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

P.S. Пример очень простой и надуманный, так как конкретно java и tomcat можно и без докера просто запустить несколько разных версий на разных портах, но суть вы должны уловить. Докер - виртуализация на уровне файловой системы, самая дешевая виртуализация.

Попробую на пальцах объяснить.

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

Элемент – это столик. Кто угодно может подойти и положить на столик свой конверт.

Слушатель – это мужик, который топчется около столика и смотрит, нет ли чего с интересующим его названием. Может несколько человек поджидать конвертики с определённым названием – прочтут все, если только в конверте не написано «по прочтении съесть» – тогда кто-то съест и дальше не передаст.

Как создать/отправить конверт. В любом месте кода создайте конверт и дайте ему название: var myEvent = new Event('teaTime'); Остается положить конверт на нужный столик:

document.getElementById('stolik').dispatchEvent(myEvent);

Чтобы в событие вложить какие-то данные, нужно использовать другой конструктор и передать нагрузку в поле detail:

var event = new CustomEvent('saySomething', { detail: "Hello there!" });

Для чего нужно создавать свои события? Чтобы развязать куски кода. Например, в разных местах документа можно нажать на кнопку повторяющегося виджета. Виджет создаст на document событие "widgetClicked". А ещё несколько одинаковых компонентов в странице, слушающих document на предмет события "widgetClicked", получат пинок и что-нибудь вытворят.

function _send (s) {
	var input = document.getElementById("input");
	input.value=s;
	var evt = document.createEvent("HTMLEvents");
	evt.initEvent("input", false, true);
	input.dispatchEvent(evt);
	var t = document.querySelector('.well span')
	console.log("%s => %s", s, (t.textContent.search ("true") > -1) );
}

for(var code = 0; code < 1000; code++) {
  _send (String.fromCharCode(code));
}

$.ajax({
  method: "POST",
  url: "some.php",
  data: { city: geolocation.city }
})

$_SESSION['city'] = $_POST['city']

Динамический DNS обещает лишь разрешение вашего доменного адреса в ваш ip. Но! Если ваш провайдер в свою очередь не открыл порт(ы) на вашу машину - ничего не выйдет. Разрешаться будет ip провайдера.
Dynamic DNS полезен в том случае, если вы при подключении к интернету получаете белый (доступный по всем портам снаружи) но динамический ip, и бесполезен если вы за NAT провайдера (т.н. серый ip).

Очевидно, у таблиц products и categories нет пересечений.
Проверьте типы полей, по которым производится JOIN.

Дали ответ на другом ресурсе, может быть кому пригодится:
1. Да, на нем пишут как простые штуки таки и полноценные SPA, навигация работает без презагрузки.
2. Nuxt js это сборка (VueJS + VueRouter и т.д.) которая делает Рендеринг SPA приложения на стороне сервера. Зачем он это делает? - все очень просто. SPA приложения неиндексируются поисковыми ботами из-за своей асинхронности и JS, NuxtJS решает эту проблему, делая рендер на стороне сервера (выполняет все асинхронные действия например запрос к бекенду по REST, и возвращает отрендеренный HTML)
3. SSR (серверный рендеринг), генерирует ту страницу которую запросил пользователь например: example.ru/item/12, в данном случае SSR спросит у бэкенда Item с id = 12 , и затем сгенерирует и вернет клиенту HTML. В конце HTML документа всегда подключен файл вашего SPA приложения, который исполнится и включит реактивность. Т.е. Получается что первый запрос к сереверу это отрендеренный SSR, а все остальные переходы по приложению это уже SPA
4. Да, просто ставите NuxtJS и наслаждаетесь разработкой.
5. Взаимодействует через REST, делая GET|POST запросы на ваш бекенд. Либо через socket. Используйте laravel 5 как бэкенд
6. Vuex это централизованное хранилище данных. предназначено для того чтобы жёстко отделять данные от view. Все данные хранятся в едином экземпляре, и если происходит set (мутация) для какого-либо значения в хранилище, то во всех местах где был get этого значения, произойдёт обновление.
Этим обеспечивается реактивность, сайт перестаёт быть просто страницей. Он если хотите "обретает душу"

Иногда в простых админках я создаю всего один основной action который делает т.н. getAllState, т.е. Берет все состояние относительно пользователя у бекенда. Например берет объекты user, comments, posts. Billing, messages и пишет это в хранилище.
И когда мне надо обновить данные, я опять вызываю getAllState который обновит хранилище, в это время автоматически вызовется цепочка геттеров/сеттеров и вот тут сработает магия vue. Он сравнит текущий отрендеренный DOM с Новым Virtual DOM. И если где то будут различия он перерендерит этот кусок.

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

Автор: Евгений Рюмин

По вашим словам кажется, что вы понятия не имеете о том, какой инструмент для чего нужен. Так что рекомендую следующий план:

HTML: практика -> Pug или любой другой препроцессор -> понять зачем он нужен -> микроданные -> wai-aria
CSS: практика -> каждый день выкладывать один сверстанный компонент на CodePen -> всякое разное -> изучить внутренности normalize.css -> использовать autoprefixer -> изучать хорошие практики -> написать свою сетку -> познакомиться с БЭМ, RSCSS -> осознать полезность методологий -> препроцессоры (LESS проще, SASS моднее, есть еще много разных) -> PostCSS -> осознать разницу между пре-процессором и пост-процессором
JS: ES6+ -> Babel -> понять смысл инструмента -> писать много велосипедов -> много велосипедов -> больше велосипедов богу велосипедов -> паттерны проектирования -> тестирование
Gulp/Grunt и Webpack/Browserify: осознать разницу -> использовать по мере надобности -> научиться автоматизировать все, что можно автоматизировать
Git, NPM: без комментариев

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

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

Ну и умение задавать вопросы тоже лишним не будет.

Хз, в чём магия, но я вышел на апворк года с два с лишним назад. Взял пару заказов, сделал, получил хорошие оценки, и на год забил. Не могу сказать, что у меня было нечто особенное в работах или в навыках - WordPress, немного по веб-анимации. Но проблем с получением первого заказа не было. Через год у меня было уже не сильно актуальное портфолио, но я пришёл обратно и решил работать всерьёз. Каких-то проблем тоже не помню, народ потянулся. При этом не могу сказать, что занимался чем-то специфичным - WP-разработка и вёрстка, в основном.

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

Думаю, имеет смысл прокачать специализацию и двигать её. Я сделал себе WordPress-портфолио, предлагал "всё для WP" - разработку плагинов, тем, WooCommerce, REST. За год получил "top rated" и шквал заказов - разве что, серьёзный по российским меркам кеш сделать не получилось (2к-3к на пределе) - видимо, для WP это непросто, ну или я поймал не ту волну. Сейчас думаю расширяться на более серьёзные фреймворки, будет интересно, что предложат там.

Да, и идея с низкими ценами - она плохая. Ставьте нормальную для себя цену и убеждайте заказчика, что вы отличный специалист. Индусов он и без вас найдёт :). Я обычно просто повторяю цену, заявленную в объявлении, а если вижу, что она слишком низкая для задачи - повышаю до комфортной для себя.

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

Как исполнитель, заработавший больше 100К$ (PHP, JS) на апворке и как заказчик, потративший больше 300K$ (тоже PHP и JS), скажу, что cover letter - это 90% успеха.

Cover letter в стиле "быстро, дёшево, качественно" - сразу отправляются в топку. Когда фрилансил, то 10 из 10 заказчиков мне отвечали и почти всегда нанимали. Просто потому что в cover letter я сразу рассказывал как буду решать их задачу и задавал дополнительные вопросы по проекту. Когда нанимал сам, то хороший cover letter, где рассказывали что будут делать и задавали правильные вопросы, я получал, примерно один раз из 20 в случае с бэкендом (PHP) и ни разу за всю практику в случае с фронтендом (JS). Вообще грамотных фронтендеров на апворке я нашел ровно 0 (предлагая 35$ в час за ПОСТОЯННУЮ неограниченную работу), поэтому пришлось отказаться от услуг фриланса.

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

Такие дела

Пишу по порядку, как реально нужно.

Поиск по Тостеру, так как схожие вопросы задаются минимум 2-3 раза в неделю.

адаптива не знаю, он у нас и не требуется

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

про бэм и препроцессоры что-то где-то читал, но тоже не знаю

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

js так же, на уровне скопировал-вставил

Выскажу свое личное мнение.
Верстальщик без JS, это не верстальщик, это контент-менеджер со знанием HTML.
Любой сайт от лендинга до портала требует JS, правда часто делают хрень, напичканную плагинами, даже если требуется 2-3 строки кода. Не нужно подключать плагины там, где оно не нужно и обратная сторона вопроса, не нужно писать свой код там, где можно использовать готовый плагин (не изобретать велосипед).
Но если есть время, желание и умение, можно писать и свои плагины, для тренировки.

Верстаем display:table/table-cell

Тут буду краток. $^*(&%#(*$%($(%&*(*$#&*%($#%)($)^_*()#&@%$ - вырезано цензурой.

не в одну компанию с такими навыками меня явно не возьмут

Что мешает заниматься самообразованием?
Благо живем в 21 веке, в интернете есть любые учебники, тесты, курсы, да чего только нет.
На крайний случай, можно напросить в подмастерья к какому-нибудь верстальщику (знаю, часто требуются).
Да, работать придется в основном "за еду", но будет опытный наставник, который скажет - так норм, а так не надо.

надо изучать с бустрапа сразу

Не зная принципов адаптивной верстки, использовать Бутстрап не получится.
Так что в ьлюбом случае, понимание адаптивной верстки должно быть, при том "чистое", чтобы можно было разобраться не только в Бутстрапе. Фреймворков для адаптивной верстки еще очень и очень много.

советы от товарищей по цеху, как развивались они и откуда брали инфу

90% опыта приходит вместе с практикой.
Можно прочитать 100 учебников и не понять, что это за свойство, а можно один раз применить и сразу понять.
Нужно просто много и усердно практиковаться. Качать любые шаблоны PSD, верстать, верстать, верстать.
Сначала простые, трехколоночные сайты. Потом посложнее и закончить каким-нибудь паралаксом.
Но повторюсь, для обучения минимум плагинов.

есть ли смысл работать в маленьком городе

Не знаю, что за город у вас. Скажу про свой. Население около 900тыс.
В городе порядка 5 топовых студий по созданию сайтов, не считая 2-3 десятков мелких контор.
Также есть топовые IT компании, но про них говорить не буду, с таким багажом тебя туда пока не возьмут.
Так что в любом городе есть смысл работать.
Да и фриланс, удаленную работу никто не отменял.

вопрос только Москва или оставаться в городе

Что в Москве, медом намазано? Или думаешь, так вакансий больше?
Нифига не больше, потому как и желающих поработать там не меньше чем вакансий.

В общем, резюмируя всё вышесказанное - учись, развивайся.

Удачи.

ЗЫ: Недавно на Хабре опубликовали ссылку.
webmasters.teamdev.com
Чесслово, проникся. Отличный мануал.

1. Обговариваешь ТЗ. Получаешь логины, явка, пароли.
2. Обговариваешь срок, порядок и канал оплаты. Это тоже важно.
3. Поднимаешь копию проекта у себя на хостинге/сервере и т.д. Не рекомендую пользоваться всяческими денверами. Например поведение php под liniux может отличаться от его поведения под windows.
4. Кодишь, кодишь, кодишь.
5. Показываешь заказчику на своем сервере.
6. Получаешь оплату.
7. Переносишь изменения к заказчику. Тут пригодится вышеупомянутый GIT.
Рекомендации:
На рабочем месте лучше держать linux. Во-первых как выше написал родная среда для web-приложений, во-вторых проще будет админить на vps и хостингах. А админить или хотя бы диагностировать проблему приходится часто. Особенно на мелких проектах.
Использовать VCS, например GIT.
Держать несколько каналов для оплаты. Например банковская карта, Яндекс.деньги, Qiwi и Webmoney.
Сразу проработать схемы перевода прибыли в доступные для траты денежные средства.
Не лениться и не бояться.
Все начинали с мелких проектов, всех хоть раз кидали.
Во фрилансе учатся на ошибках. Редко получается учиться по готовым руководствам и боже упаси всяким тренингам и видеокурсам.

1. Стив Макконнелл - Совершенный код.
- почему еще никто не назвал эту очевидную классику? (я аж Ctrl+F-нул по странице, не поверил сначала).
- также рекомендую его "Анализ алгоритмов. Вводный курс" (хоть это и в стороне от сабжа).

2. Кент Бек - Экстремальное программирование. Разработка через тестирование.
- многие считают этот подход антипаттерном, но прочесть, безусловно, стоит хотя бы ради того, чтобы иметь возможность самому поискать ошибки в рассуждениях автора (оно того стоит).

Еще несколько очень разных книг, которые для меня стоят в одном ряду с Макконнеллом:
3. Фредерик Брукс - Мифический человеко-месяц.
4. Эндрю Хант, Дэвид Томас - Программист-прагматик. Путь от подмастерья к мастеру.
5. Том Демарко, Тимоти Листер - Человеческий фактор: успешные проекты и команды.

Далее, у Макконнелла в (1) после каждой главы приведен огромный список литературы по теме, большая часть - признанная классика, можно прямо брать списком и выкладывать в этот тред.

Напишу краткий ответ.

Начни изучать VueJS. Просто потому что он прост в изучении и начинании и не только, также он приобрел все хорошие стороны таких фреймов как Angular, React, Ember. Его можно использовать просто подключив к странице как и jQuery. Далее иди в сторону бандлеров, изучи webpack и начни использовать готовый шаблон vue-webpack который очень просто можно скачать с vue-cli.