Сергей

input[type="checkbox"] + input[type="text"] {
  display: none;
}

input[type="checkbox"]:checked + input[type="text"] {
  display: inline;
}

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

$("родитель в котором твои item").each(function () {
var blockCount = Math.floor($(this).width() / $(this).find(".твои итемы").width());

че то типа этого: https://jsfiddle.net/dnz4364b/1/

https://www.mail-tester.com/

https://habrahabr.ru/company/mosigra/blog/113876/
https://habrahabr.ru/company/xmlshop/blog/114014/
https://geektimes.ru/post/258762/
https://geektimes.ru/post/254122/

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

когда вы оставляете заявку вы всегда указываете цену , сами, САМИ.

Это какая-то разновидность нотации Бэкуса-Наура, по-моему. Запись вида

X:
    A
    B
    C

Следует читать как "X - это А или B или C". Когда два определения идут подряд - это значит, что они следуют друг за другом. Те определения, которые определяются через другие - это нетерминалы, те, которые понятны сами по себе - терминалы. Всё это работает рекурсивно. Короче, примерно вам даст понять вот это https://ru.m.wikipedia.org/wiki/Форма_Бэкуса_—_Наура

Ну и читать это так: идентификатор(identifier) - это последовательность символов, которая может быть не цифрой(identifier-nondigit) или начинаться с идентификатора(рекурсия) и продолжаться не цифрой, или начинаться с идентификатора и продолжаться цифрой(digit)
Дальше идёт углубление - что такое identifier-nondigit, что такое digit и тд.

Github Flow за 5 минут.

1. Создал ветку для фичи/фикса
2. Сделал в ветку несколько коммитов
3. Отправил пулл риквест
4. Обсудил с коллегами пулл риквест и при необходимости внес правки
5. Прогнал ветку через тесты.
6. Влил в master
7. Выкатил master на продакшн

Если фича ветка долго не мержится и начинает расходиться с master веткой, то вливаем master в фичу ветку и продолжаем.

Если кто-то из команды хочет руками потестить новую фичу, то может сделать
git checkout -b new-feature origin/new-feature
И потестить руками локально на своей дев машине.

Update: Если sql база, то пишут миграции. Можно посмотреть в любом фреймворке что это и как использовать. После каждого git pull пробуем накатить миграции через консоль (можно хук для гита написать) и если есть новые миграции, то они применятся к локальной базе. Если nosql база типа mongo, то ничего не надо, они schemaless.

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

Начнём с того, что это не VR (Virtual Reality), а AR (Augmented Reality). Если правильно назвать, то сразу легче гуглится :) Например первый же запрос выдал.

nth-child

1. Создание собственного плагина

Preferences → Browse Packages... → в папке User создаём файл default_syntax.pyсо следующим содержимым:

import sublime, sublime_plugin
class DefaultSyntaxCommand(sublime_plugin.EventListener):
	def on_new(self, view):
		view.set_syntax_file('Packages/HTML/HTML.tmLanguage')

Сохраняем. Теперь по умолчанию новые файлы будут открываться с синтаксисом HTML, где работает Emmet.

2. Apply Syntax

Многофункциональный плагин для работы с файлами с автоопределением синтаксисов. В примере показано, что необходимо сделать, для того, чтобы новые файлы открывались в синтаксисе HTML.

Скачиваем ApplySyntax → перезагружаем на всякий случай Sublime Text → Preferences → Package Settings → ApplySyntax → Settings - User → задаём параметру “new_file_syntax”: вместо false значение — путь к файлу синтаксиса без расширения, для HTML это HTML/HTML. В итоге строка будет выглядеть так:

"new_file_syntax": "HTML/HTML",

Сохраняем файл, отныне все новые файлы должны открываться в синтаксисе HTML.

3. AutoSetSyntax

Демонстрация

Пример, когда синтаксис автоматически определяется как Python, ежели мы начинаем новый файл со слова import.


Установка и настройка

Скачиваем плагин AutoSetSyntax через Package Control → Preferences → Package Settings → ApplySyntax → Settings - User → в открывшийся файл вставляем следующий код:

"syntax_mapping": {
    "Packages/Python/Python.sublime-syntax": ["import"],
},

Не путайтесь в JSON-синтаксисе, следите за правильной расстановкой кавычек, скобок и запятых. Например, мой файл AutoSetSyntax.sublime-settings выглядит следующим образом:

{
    "syntax_mapping": {
        "ANSIescape/ANSI.tmLanguage": ["^\\s*\\[SideBarGit@.*\\] git l\\b"],
        "Packages/PHP/PHP.sublime-syntax": ["<\\?php", "<\\?="],
        "Packages/Python/Python.sublime-syntax": ["import"],
    },
    "working_scope": "(?x)^(text.plain | source.diff)\\b"
}

Сохраняем файл → после введения инструкции import синтаксис нового файла должен определиться как Python.

Что означает написанное

• syntax_mapping — переопределяет синтаксис, если будет введено определённое сочетание
  
• Packages/Python/Python.sublime-syntax — путь к файлу синтаксиса, начиная с Packages,
  
• import — текст, после введения которого переопределяется синтаксис. Допускается задавать в данном значении не только обычный текст, но и регулярные выражения. Например, значение для PHP — ["<\\?php",]. Обратите внимание, что слэш, экранирующий метасимвол вопросительного знака, необходимо тоже экранировать.
  

4. Дополнительные ссылки

API Sublime Text 3,
Документация плагина ApplySyntax,
Настройка автоматического определения синтаксиса д...,
В Sublime Text 3 не работает подсветка Babel скрип...,

Спасибо.

вы путаете инверсию контроля и инверсию зависимости. Давайте по порядку кратенько.

Зачем нам нужны контроллеры или различные представления данных

Зачем нам в принципе контроллер? Что он делает? Для упрощения не будет воспринимать контроллер как "один объект" и вместо этого представим себе его как целый слой. Так же заменим слово "модель" словом "приложение".

Задача контроллера - принять и обработать запрос и выдать ответ. По сути в контексте WEB наш HTTP запрос и ответ это представление, которое хочет получить клиент (браузер, мобильное приложение, SPA, что угодно). HTTP - это интерфейс пользователя (UI) для нашего web-приложения.

Например что бы независеть от реализации клиента и что бы было удобно мы передаем даты в формате iso 8601 (пример: 2016-07-14T19:40:12Z). Это удобно что бы быть независимым от реализации клиента или сервера. Но это не удобно для нашего приложения. В приложении скорее всего нам удобнее всего работать с объектом типа DateTime. То есть приложение использует абсолютно другое представление.

Мы могли бы прямо в приложении конвертить DateTime в iso 8601 но тогда мы делаем наше приложение привязанным к одному конкретному представлению, которое хочет получить клиент. К примеру по каким-нибудь причинам известным только темным богам, вам вдруг понадобится быстро прикрутить интеграцию с другим сервисом и те же данные гонять уже в RFC2822. И стало быть уже приложению нужно париться о еще одном представлении.

Мы могли бы сделать какие-то адаптеры у приложения, и дергать их в зависимости от потребностей, но тогда опять же наше приложение все еще знает о представлении, которое ему собственно не нужно. То есть у нас есть зависимость приложения от его UI что... похоже на "не лучшую идею". И тут на помощь приходит Inversion of Control.

Что такое Inversion of Control

Тут название само говорит за себя. Допустим у нас был объект A который дергал объект B, причем объект A по сути и не должен ничего знать об объекте B потому то это не его дело. Принцип инверсии контроля говорит нам о том, что в таких ситуациях именно B должно вызывать A, таким образом меняя направление потока управления. Это позволяет нам уменьшить связанность и повысить зацепление компонентов нашей системы. Так же сделав это у нас может появиться объект C который так же будет дергать объект A. Если говорить о UI - мы просто можем сделать несколько реализаций UI.

То есть если еще упростить - фреймворк должен дергать ваш код, а не код дергать код фреймворка. Тем самым мы снижаем связанность одного от другого.

Роутер и контроллеры как реализация UI

Что бы отвязать приложение от логики формирования представления, вынесем это все в отдельный "слой" и назовем этот слой - контроллеры. Точнее это будет как цепочка адаптеров. Один адаптер (фронт-контроллер по сути) получает Request и делает какие-нибудь вещи с ним. Например проверяет можем ли мы вообще делать подобный запрос. Другой адаптер вызывает роутер и выясняет какой дальше адаптер вызвать. Если следующий адаптер не вызван - надо вернуть 404-ую ошибку. Если же все пошло хорошо - мы вызываем еще один адаптер, который уже будет конвертировать HTTP запрос в какое-то действие приложения (вызов метода приложения по сути).

Так а инверсия зависимости это что?

Инверсия зависимости - очень похожа на инверсию контроля но действует чуть по другому. Проще всего будет вглянуть на картинку:



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

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

Нужно ли соблюдать принцип инверсии зависимости в случае контроллеров?

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

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

Это уже вопрос реализации IoC. Конкретно вы хотите получить что-то вроде Dependency Injection. Вы можете забрать зависимости из аргументов метода экшена. или аргументов конструктора контроллера.... или просто использовать контейнер зависимостей внутри контроллера.... это совершенно не важно. Контроллеры это то место где высокая связанность на компоненты фреймворка более чем допустимы.

С другой стороны у вас теперь роутинг совмещает обязанность маршрутизации и разруливания зависимостей. Сами понимаете что это как-то нарушает прицип единой ответственности. Этим может заниматься Controller Resolver какой-нибудь.

Параметр arFilter может содержать вложенные фильтры. Ключом массива вложенного фильтра должно быть число. Например:

$arFilter = array("NAME" => "A%", array(..<здесь пары "поле" => "фильтр">...), "IBLOCK_ID" => $IBLOCK_ID);

Вложенность фильтров теоретически не ограничена.
Так же условия фильтра могут объединяться не только по условию "И", но и "ИЛИ". Для этого в качестве фильтруемого поля надо указать "LOGIC". Может принимать два значения: "AND" и "OR". По умолчанию - "AND". Например выберем маленькие зрелые и большие не зрелые апельсины:

$arFilter = array(
    "IBLOCK_ID" => $IBLOCK_ID,
    "SECTION_CODE" => "orange",
    "INCLUDE_SUBSECTIONS" => "Y",
    array(
        "LOGIC" => "OR",
        array("<PROPERTY_RADIUS" => 50, "=PROPERTY_CONDITION" => "Y"),
        array(">=PROPERTY_RADIUS" => 50, "!=PROPERTY_CONDITION" => "Y"),
    ),
);

CIBlockElement::GetList()

Уже отвечал на подобный вопрос, но про Битрикс, а найти не могу. Расскажу как делаем мы.

Вот структура:

Как видите сам wordpress в репозитории не хранится, (как и плагины, которые из списка зависимостей ставятся на новой машине в пару кликов).

Верстка лежит в src (используется scss и jade) и собирается в папку static - из которой вся статика подключается и в вордпрессе. HTML файлы собираются в папку _v.

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

Если нужно добавить новую страницу - верстальщик верстает в jade, потом программист сольёт его изменения, соберет проект, возьмет из папки _v нужный шаблон и натянет его на wp.

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

UPD: Про ветки. Всегда есть master и markup (верстка) + могут быть ветки отдельных программистов / фич и т.д. В мастер изменения сливает только тимлид/техлид/самый-главный-программист.