Nikcet

Дискретная математика для программистов Хаггарда, Математический анализ Зорича (1 том), Курс алгебры Винберга, Матричный анализ и линейная алгебра Тыртышникова, Теория графов Оре, Комбинаторика Виленкина, Наглядная математическая статистика Лагутина.

Многое из дискретной математики можно усвоить по онлайн курсам Райгородского и Дайняка:
https://stepik.org/course/Дискретные-структуры-83/
https://www.coursera.org/learn/probability-theory-...
https://www.coursera.org/learn/kombinatorika-dlya-...

upd. самый лаконичный вариант без переборов:

function rangeSum(a,b) {return (b*b-a*a+a+b)/2}

console.log( rangeSum( 1, 3)); // 6
console.log( rangeSum( 20, 220)); // 24120

(старый ответ) Перебором всех значений подряд:

function rangeSum( from, to) {
  var i, sum = 0;
  for( i = from; i <= to; i++) {
    sum = sum + i;
  }
  return sum;
}

console.log( rangeSum( 1, 3)); // 6
console.log( rangeSum( 20, 220)); // 24120

Но если подумать, сумму можно вычислять без перебора:

function rangeSum2( from, to) {
  var m = to - from + 1;
  return from * m + ( m * m - m) / 2;
}
console.log( rangeSum2( 1, 3)); // 6
console.log( rangeSum2( 20, 220)); // 24120

Тривиального решения задачи нет. Ошибка многих начинающих (и меня тоже), то что физическое разрешение мониторов принимается за CSS разрешение.
На самом деле как подсказал DevMan мониторы с ретина дисплеем в большинстве случаев работают как FullHD мониторы с соотношением x/2, где x
физическая ширина монитора, в полном разрешение на таких мониторах работать в web затруднительно. Теперь ответы по существу:

1. В связи с чем вопрос как провести тестирование верстки сайта в 4K без монитора 4K программными средствами?

-- Отладчик бразуера Chrome. Открываем панель разработчика, включаем адаптивный вид, задаем дополнительный девайс
класса desktop с размерами 1920 * 1080. Примерно так и будет выглядеть сайт на ретине дисплее с физическим разрешением 3840
Так же хочу предупредить, что в режиме responsive, некоторые сайты отображаются неверно (Например Хабр полностью прилипает по краям, а в реальности как и Toster центрируется).
Поэтому надо задавать именно через устройство, а не вбивать значения в режиме responsive.
У этого способа есть фатальный недостаток, при таком разрешении сайт масштабируется в меньшую сторону,
что не позволяет разглядеть мелкие детали, а если увеличить масштаб до 100% показывается только верхний левый угол сайта, но нельзя прокручивать его по сторонам,
чтобы разглядеть во всех деталях. Поэтому этот способ подойдет только для обозрения сайта на больших разрешениях с "высоты птичьего полета".
-- Отладчик брузера Firefox на удивление именно он наиболее корректно отображает сайты на таких разрешениях и в отличии от Chrome позволяет прокручивать их по сторонам, чтобы разглядеть все детали. Пожалуй этот способ самый приемлимый.
-- Сайт ami.responsivedesign.is/# неплохой сервис, позволяет быстро сделать презентацию как выглядит сайт на разных устройствах, в том числе и на больших мониторах, но есть два недостатка:
1) Большой монитор мака отображает сайт в CSS разрешении 1600*992, а не 1920 * x, наверное это связанно с тем, что последнее обновление сайта было в 2013 году.
2) Некоторые сайты не грузятся (например Хабр), возможно это связанно с какими то скриптами
-- Сайт quirktools.com/screenfly
Тоже что и предыдущий пример. Немного удобней. Недостаток тот же. У меня отказался грузить некоторые сайты. Например хабр.
Как плюс можно отметить расшаривание ссылки, что может пригодиться для обмена мнениями с удаленным разработчиком или заказчиком.
-- https://www.browserstack.com
Предоставляет даже реальные устройства в Live режиме(или эмулированные?). Недостаток один -- платный. Правда есть триал, во время триала позволяют пользоваться устройствами 30 минут и не всеми браузерами.

2. Подойдет ли встроенный отладчик Chrome?

Подойдет, но не совсем, см п1. лучше использовать Firefox.

3.Сайт сверстанный на каноничном бутстрап выглядит как несчастная полоска в 1170 пикселей или viewport масштабирует сайт до читабельного размера?

Отображается как на мониторе 1920 * X . Выглядит вполне прилично. Конечно, если бы такие мониторы использовались в реальном разрешении сайты на бутстрап в развернутом окне выглядели бы как танковая щель.

4. Пользователем таких мониторов постоянно приходится масштабировать сайты?

Нет.

5. Может есть более удобный сервис тестирования верстки в больших разрешениях?

Самые удобные сервисы перечисленый в п1. Сколько я ни старался удобнее не нашел.

В заключение пара полезных статей по верстке в больших разрешениях:
Рассуждения об адаптации верстки для больших экранов, статья старая, но актуальность не потеряла:
https://web-standards.ru/articles/big-screens/

Тренды экранов на текущий момент:
https://www.openstat.com/counter:meta/trends/repor...

Адаптируем графику под Retina экран
https://habrahabr.ru/post/139682/
Статья правда написана 5 лет назад непонятно насколько сейчас она актуальна.

Оптимизация графики для Retina-экранов
https://habrahabr.ru/post/150071/

P.S. Отдельное спасибо DevMan за терпение.

Вдруг кому надо, фишка была в том что name не используется как id.
Нужно было дописать id=\"text_comment\"

echo "<input type=\"text\" name=\"zin\" id=\"text_comment\" maxlength=\"5000\"/> <input type=\"submit\" value=\"Написать\" class=\"ibutton\"></div>";

Если полностью прочитать Флэнагана, то этого должно хватить для базового понимания. Остальное придет с опытом.

Не принципиально, у меня Фленаган и еще пару. Всеравно понятно станет раза с 3его только.

Карта развития веб-разработчика
https://github.com/zualex/devmap
Дорожная карта WEB разработчика:
https://coggle.it/diagram/52e97f8c5a143de239005d1b...

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

Про курсы. Именно в веб-отрасли низкий порог вхождения. И многие поняли, что можно эффективно и ненапряжно преподавать азы за деньги. Появиласть туча курсов и их стали усиленно рекламировать - это вызвало огромный приток верстальщиков. Большая часть курсов вообще ничего не даёт, кроме сертификата, а ученики насмотревшись высоких зарплат на hh и умных слов в сертификате, лезут напролом во все компании.
Яндексу и Майлу такой сброд абсолютно не нужен, а вот квалифицированные кадры - очень нужны. Поэтому им легче открыть свои курсы (даже больше, Технопарки всякие) и готовить нормальных спецов, нежели отсеивать кучу мусора на собеседованиях. Как-то так

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

Блин, 8 лет верстать "по-дедовски")
Да за это время можно было стать Senior developer или даже выучиться на фуллстак и уехать в какой-нибудь Израиль работать за 4к $

Препроцессоры я познал за один день. Для CSS использовал сначала less, через месяц ушел на Stylus (советую именно его, так как всякие sass это вообще мрак. Работать в чужом проекте на sass - ад, тогда как stylus прост, при этом более функционален и намного интуитивнее).

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

Сборщик проекта. Для верстки, если выбирать между Grunt и Gulp - без сомнений Gulp. Я очень счастлив, что мне в тот момент подвернулась именно статья про Gulp. Работал с проектами на Grunt (их очень мало) - ну, это просто дерьмо, а не сборщик. Скорость сборки отличается в разы.

Webpack это конечно повыше уровень, юзать его для верстки не прагматично.

Флексбоксы в CSS изучаются только на практике, сидеть и запоминать это бессмысленно. 2-3 проекта с подсказкой по флексу и он плотно осядет в голове.

Вывод: надо просто не бояться нового. Берешь и применяешь новые технологии без страха и зазрения совести. Они быстро вольются в твою жизнь, а без них потом будет дышать тяжело и больно.

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

— uwebdesign.ru [Видео подкаст суровый веб]
— habrahabr.ru
— css-tricks.com
— css-live.ru

- Представление о MVC имею. Раньше писал пару проектов на CodeIgniter, но на нём на мой взгляд мало что есть из коробки, и много времени уходит на разработку.

С тех пор изобрели Composer, при должном желании прикручивается он и к CI в том числе :)

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

На русском - CodeIgniter, на не русском - Laravel, Symfony и другие.

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

Composer - решает 99% проблем, практически в любом фреймворке.

- Возможность работы с различными БД из коробки

Пока фреймворков без этой штуки не видел, но есть... Вы не поверите, Composer, что бы сменить/поставить "другой" ORM, если Вам "текущий" чем-то не подошел.

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

То о чем Вы говорите, это: Varnish, Nginx+SSI и т.д. кэширование "из коробки" есть в Symfony (т.к. если его отключить, страницы может генерироваться феерически долго)

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

По моему, любой современный фреймворк, если уже даже "Битрикс" небеизвестный до этого до этого дошел... некоторые фреймворки вообще скоро будут требовать PHP7, а не только "поддерживать".

- Проект будет ориентировочно крутиться на nginx+php5-fpm. Думаю практически все фреймворки смогут работать в этой среде, но вдруг...

Я пока таких "вдруг" не встречал. Если у админа голова и руки на месте - то никаких "вдруг" быть не должно. А вообще, у PHP версии 5.х, есть как минимум 3 основных "ветки", это <5.3, >=5.3 или 5.4+ и т.д., ещё кое-какие отличия были в 5.5 и 5.6, но не такие "разительные", подробности можно почитать в истории версий PHP. По этому, нужно конкретнее указывать версию, например, Laravel требует 5.6+

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

Это не возможность фреймворка - а навык программиста/админа.

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

1. Yii2
2. CMS + готовые модули CMS
3. Вы не забыли, что есть... composer?!

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

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

Не за что! Кнопка "Мне нравиться" - сразу под сообщением :D