eugene159

Самые первые ОС были очень простыми и там было очень мало функционала и приложения представляли из себя простой исполняемый файл. Который пользователи каждый клал куда захотел и оттуда использовал. Затем, с каждым годом ОС становились сложнее, у них появился графический интерфейс, разветвленный системный API, появилась своя файловая структура и многое-много другое. А за ОС потянулись и приложения - они стали сложнее, появились файлы конфигураций, библиотеки, системные библиотеки, появилась необходимость размещать много файлов по разным местам - появились установщики приложений, а в ОС появился централизованный интерфейс для удаления приложений, появились деинсталляторы, которые правильно удаляли все раскиданные приложением файлы по разным местам. И с каждым годом все усложняется и усложняется. Да, какие-то приложения вполне адекватно работают в "портативном режиме", но многим приложениям требуется полноценная установка. Например, без полноценной регистрации в реестре офисный пакет будет не очень удобно использовать, т.к. не будет файловых ассоциаций, плагинов для браузеров и прочего. Антивирусы устанавливают в систему свой сетевой фильтр и сервис мониторинга. Или, например то же самое автообновление не сможет обновить какое-то приложение, т.к. оно банально не найдет правильно установленной версии. Так что лучше используйте полноценную установку приложений в новой ОС.

https://qna.habr.com/q/440609

Обычный план такой:

1 - Установить через npm
2 - Проверить через webpack-bundle-analyzer , что в итоговый билд попадают только те модули этой библиотеки, которые используются
3 - Если попадают лишние, можно попробовать изменить импорты на более конкретные , например "jquery-ui -> jquery-ui/folder/module.js", но это зависит от файловой структуры библиотеки

Подробнее про tree shaking - тут

Fork, SmartGit, SourceTree, и прочие гуевые клиенты гита.
https://git-scm.com/downloads - вот тут ищите.

flex-grow задает поведение дочерних элементов, когда ширина контейнера больше, чем общая ширина дочерних элементов, грубо говоря как они будут занимать появившееся пространство
flex-shrink задает поведение, когда ширина контейнера меньше общей ширины дочерних элементов, грубо говоря, как будут вести себя дочерние элементы, когда места на всех не хватает, кто как будет ужиматься

До меня уже всё сказано. БП разбирают ещё чтоб визуально убедиться что компоненты , например конденсаторы чувствуют себя хорошо и не вздулись.
А видеокарты вообще лишний раз разбирать не рекомендуется если нет явного перегрева. По тестам заводские термопрокладки работают лучше чем то чем вы их хотите заменить (если вы не собираетесь лепить вместо них топовые дорогущие).
В ролике про воздуходувки не рекомендуют продувать компрессором. Это не так. Нужно выбрать необходимое давление. а если что-то отвалилось, то и к лучшему. значит эта деталюшка либо с браком , либо уже отгорела и была на грани. Такие детали обычно бывают причинами поломки и гибели других компонентов. 0,6 очка в компрессоре и всё ок. Практикуем давно, полёт нормальный.

Разве я не прав? Вот зачем делать комп ИДЕАЛЬНО ЧИСТЫМ? Как будто новый. Зачем разбирать комплектующие?

eugene159, вы абсолютно правы. Затраченные на такую тщательную чистку усилия и время не оправдывают, в итоге и объективно, конечный результат. По своему опыту, чистка системного блока 1-2 раза в полгода, это оптимальное решение - блок внутри постоянно остается чистым и, при этом, не тратится большое количество времени на последующие чистки.

Зачем при чистке ПК вычищать пыль НАЧИСТО?

Ради эстетического удовольствия.

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

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

Да хоть такое

Т.к. вы работали с MODX, то рекомендую посмотреть на October CMS. Много адептов чахнущего MODX переходят, как раз на October. На последнем, к слову, есть много разных магазинов, не в пример, 2-3 решениям на MODX:

1. Shopaholic
   
2. JKShop
   
3. Mall
   
4. OctoCart
   
5. OctoCommerce
   
6. EasyShop
   
7. MicroCart
   

Но всерьез рассматривать стоит, пожалуй, только Shopaholic и Mall. Далее буду приводить примеры для Shopaholic.

1. Удобное создание вариаций товаров.
Сейчас поясню. До этого я работал с Modx. Там очень проблематично сделать вариации товаров. Надо либо создавать разные ресурсы (страницы) с одним и тем же названием, описанием и пр., но с другой ценой и какой-то характеристикой (например, цветом). И потом, чтобы изменить описание одного товара, надо проходить по всем его вариациям (страницам) и менять. Это очень неудобно. Либо писать какие-то костыли для создания вариаций (и потом как-то привязывать эти костыли к плагину магазина, который отвечает за добавление в корзину, оформление заказа и т.д.).

Фанаты MODX очень сильно любят его как-раз за дерево ресурсов. Но на сегодня это объективно устаревший формат структурирования контента. В случае с интернет магазином он не даст гибкости в размещении товаров в разных категориях при необходимости (т.н. Wildcard URLs). В Shopaholic каждый товар имеет т.н. офферы, которые могут преопределять основные данные, указанные в описании товара.

Так выглядит редактирование товара:



так выглядит редактирование оффера:



А есть еще плагин Flat Offer Editor for Shopaholiс, который редактирование офферов предлагает в таком виде:

2. Связь с 1С. Чтобы можно было загружать товары на сайт из 1С. А при продаже товара отправлять с сайта данные - остатки (кол-во товара ведь уменьшилось) и пр. документы (счет-фактура, например, и т.д.).

Импорт товаров из 1С возможен через CSV или XML. Двустороннего обмена пока что нет.

3. Удобство при создании расчета доставки (СДЭК, Почта России...) из разных городов.
В том же Modx для этого надо покупать и настраивать доп. плагины.
Может, в какой-то CMS эта особенность есть "из коробки"? Или с бесплатными плагинами.

Есть отдельный плагин CDEK for Shopaholic, а есть плагин ApiShip for Shopaholic, у которого "под капотом" несколько десятков интеграций. Первый плагин вот так сравнивали с аналогичным для MODX в чатике сообщества в телеге:

4. Модуль оплаты. В Modx здесь та же история, что и с расчетом доставки - надо покупать и настраивать дополнительные плагины.

Во-первых, есть бесплатный плагин Omnipay for Shopaholic с двумя сотнями интеграций, но придется немного покодить. Если вести речь об установке буквально в один клик, то есть готовые интеграции с 11-ю системами экваринга, среди которых есть (PayPal, Stripe, Yandex Kassa, ROBOKASSA, Sberbank, PayKeeper и пр.).

Рассматриваю также варианты каких-либо готовых сборок на CMS (может, сама CMS не очень хорошо подходит под описание здесь. Но вот сборка на ней - да). Пусть даже платные. Главное - чтобы не очень дорого.

Средняя стоимость топ 30 популярных плагинов для популярных e-commerce движков, а ткже MODX + miniShop и October + Shopaholic по состоянию на июнь 2019 (лично собирал статистику):

1. Magento - 199/723$
   
2. Prestashop - 105€
   
3. WooCommerce - 82$
   
4. OpenCart - 36$
   
5. MODX (miniShop) - 23$
   
6. Shopaholic (на сегодня) - 16$
   

Как говорится, думайте сами, решайте сами. =)

Договорённость использовать в протоколе HTTP кодировку ISO/IEC 8859-1 позволила сильно упростить его использование, а как следствие разработку браузеров и web-серверов. Но в этой кодировке есть только латинские символы, так что любые другие приходится кодировать. Браузеры и сейчас не "понимают" ссылки с кирилицей, просто они умеют отображать в строке состояния декодированный вариант.

jQuery - это про императивное программирование. jQuery - это про то "как" манипулировать dom элементами. Итог - смесь dom и бизнес-логики. Это невозможно разделить.

Angular - это про декларативное программирование. В Angular мы не говорим "как", мы говорим "что" мы хотим сделать с dom и он делает это. Что позволяет отделить бизнес-логику от манипуляций с dom.

Соответственно вся эта история не про jquery vs vanilla, а про императивное vs декларативное программирование для работы с dom. Большинство этого не понимает и спорят о jquery vs vanilla, хотя всё это одно и то же, до тех пор пока у вас не появляется какая-то штука, которая меняет парадигму работы с dom с императивного на декларативный. Внутри этой штуки можно использовать хоть vanilla, хоть jquery. Без этой штуки - у вас каша, хоть с vanilla, хоть с jquery.

Собственно об этом написано в википедии:

AngularJS is built on the belief that declarative programming should be used to create user interfaces and connect software components, while imperative programming is better suited to defining an application's business logic.

Остальные фреймворки про то же самое. Это и стало причиной стремительного роста популярности javascript фреймворков.

www.liquidapsive.com - здесь можно наглядно посмотреть и покрутить на разных экранах.
Резиновая и адаптивная - они в принципе друг друга не исключают.