Задать вопрос
  • Что такое Less и Sass?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    Лень двигатель прогресса. Хороший пример - принцип DRY - Don't repeat yourself. Я весьма подозреваю что вы стараетесь соблюдать этот принцип когда делаете макеты или чем вы там занимаетесь. Так же я весьма уверен что вы хотя бы пытались чуть автоматизировать рутину своей повседневной работы. Так же у вас могли быть ситуации когда вы переиспользовали какие-то элементы. Мало ли.

    Так вот... CSS это тупая таблица стилей. Селектор и стили, ничего сверх умного тут придумать нельзя. Лет 5-10 назад было довольно модно держать один мегажирный CSS файл на 10К+ строк и радоваться жизни внося все больше изменений и т.д. Соответственно даже если вы соблюдаете всякие правила модульной верстки и все такое, у вас возникает несколько проблем:
    • организация стилей, то есть держать все в одном файле не удобно особенно когда проект длится годами
    • Дублирование стилей и селекторов. По мере развития проекта появляются какие-то снипиты которые можно реюзать. Так же у вас может появиться масса однообразных селекторов отличающихся лишь немного. При модульных подходах вложенности редко имеет место быть но все же имеет. Но не будем забывать что большинство фигачит селекторы просто так. В итоге если мы переместили блок или переименовали класс какого-то блока нужно отредактировать еще массу селекторов.
    • Привязка размеров и параметров к другим стилям, например у вас в стилях задана ширина блока, от нее зависят другие параметры, отступы для других блоков и т.д. Да, в css3 появился calc для этого но это было относительно недавно и только с недавних пор можно почти без опаски использовать эту штуку.
    • Таблицы стилей, как и HTML ориентированы на удобный разбор этого добра машиной, но не человеком. Человек же существо ленивое и как-то вот лень лишний раз скобку поставить или точку с запятой. Просто лень.


    Есть так же хорошее правило, или идея если хотите.... Если код можно сгенерить - его лучше сгенерить. То есть для решения всех выше перечисленных проблем придумали препроцессоры. Они как бы были и раньше всех этих scss/less/stylus но как-то не решали всех проблем и т.д. Что в итоге было предложено (перечисляю в том же порядке что и в списке выше).

    • У CSS есть такая штука как @ import. Но не очень круто импортировать сотню стилей в продакшене. Стоит сделать так что бы все стили были склеены при сборке проекта. Эта идея в итоге развилась и если разработчик использует это дело правильно, можно зайти в любой файл со стилями и увидеть список всего от чего зависят эти стили. Какие стили подключаются и т.д. Причем один файл с зависимостями может быть подключен в нескольких файлах а препроцессор сам разберется как и куда все вставлять сгенерив максимально оптимизированный по структуре файл. А разработчик получил четкую структуру файлов и возможность быстро найти где что и от чего зависит.
    • С селекторами проблему предложили решить наиболее логичным вариантом. Если у нас есть вложенные селекторы, то имеет смысл определять их внутри блока этого селектора. Это существенно упрощает поддержку стилей. Так же для управления снипитами и прочим добавили миксины - эдакие параметризованные или нет функции которые выплевывают шматок CSS. До появления штук вроде autoprefixer это был единственный способ писать поддерживаемые стили, использовать плюшки CSS3 и вообще новые плюшки и не сойти с ума от префиксов. Префиксы это только пример, там могут быть самые разные штуки позволяющие грамотно производить реюз стилей
    • Проблему зависимостей значений стилей друг от друга решили... собственно самым очевидным способом - переменные. Это удобно, легко поддерживать и в умелых руках это мощный инструмент. Нужно поменять базовые цвета - не нужно лазить по 100500 блоков и править значения руками, можно поправить переменные и все будет хорошо.
    • Насколько я помню SCSS/LESS не стремились решить эту проблему. Какие-то решения образовывались сами собой с течением времени. В плане минимализма и выразительности пожалуй сейчас самая крутая штука это stylus.


    Что в итоге произошло. В один прекрасный момент какие-то там рубисты придумали SCSS (они вообще не любят все что не в стиле ruby в плане минимализма и выразительности). Затем чуваки подумали и сказали, SCSS это круто но почему-то они используют синтаксис знакомый именно Ruby разработчикам а не обычные для CSS конструкции. В итоге реализовали LESS, причем его уже реализовали на javascript, что с наличием node.js позволило это все добро еще на одной платформе собирать. А так как под эту платформу и так плодили препроцессоры оно удачно вписалось.

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

    Личное мнение. На сегодняшний день я не вижу смысла использовать чистый CSS хоть на малых хоть на больших проектах. Вот вообще никакого.
    Ответ написан
    3 комментария
  • Windows10 и черный экран с курсором?

    Keffer
    @Keffer
    ICANN
    Если windows сорвало крышу (любой версии и по любой причине) ее нельзя восстановить. Ее можно только переустановить. Такая она от рождения убогая. И да, снос крыши виндам после обнов - вещь совершенно естественная и привычная.
    Ответ написан
    6 комментариев
  • Какой дистрибутив linux выбрать для домашнего сервера?

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

    Если подъём всей домашней серверной инфраструктуры сводится к клонированию приватного репозитория с докер- и компоуз-файлами и запуском всего одной строчкой, то переехать на новый сервер становится тривиальной адачей, а вся конфигурация и зависимости прозрачно задекларированы в докерр-файлах.

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

    Так что операционка на хосте - пофигу какая. В контейнерах можно тоже убунту или альпайн какой-нибудь. там уже не сильно важно, ведь каждый контейнер решает конкретную узкую задачу.
    Ответ написан
    Комментировать
  • Теория разметки диска при установке linux?

    bravebug
    @bravebug
    хотелось бы добавить по пункту 2, что это зависит от потребности.
    у меня такие разделы:
    /dev/sda2           	/         	ext4
    /dev/sda1           	/boot     	vfat
    /dev/sdb2           	/home     	ext4
    /dev/sda3           	none      	swap

    /dev/sdb2 - это 2ТБ со всеми так нужными мне данными.
    Если я захочу переустановить систему (хотя не делал этого с 2015го), я сотру данные всех разделов, кроме /dev/sdb2, а для него, не форматируя, выберу точку монтирования в /home
    Ответ написан
    4 комментария
  • Можно ли установить Linux на разные диски?

    @rPman
    нет никакой необходимости раскидывать систему по разным дискам (единственное для чего это имело бы смысл - это удобство переустановки и переноса пользовательских файлов между установками,т.е. windows way), даже swap раздел не обязательно делать, так как уже давно он может размещаться в файле. Даже /boot не требуется, если используется стандартная файловая система без нетиповых конфигов llvm/raid/bcache/... это актуально только для mbr, для gpt все же потребуется 1мб раздел biosboot это если тип загрузки legacy mbr, и вне зависимости от типа разбиения, если используется efi, то нужен раздел fat efiboot)

    Корень размещаешь на ssd, а hdd монтируешь в какой-нибудь технический каталог (я обычно завожу в корне что то типа /o, /g или /i, т.е. максимально короткое имя) и в дальнейшем при необходимости переносишь объемные каталоги с помощью симлинков на подкаталог внутри hdd, т.е. ручное управление размещением файлов

    Например кеши файлов пакетов npm или gradle как минимум занимают десятки гигабайт и не требуют быстрого доступа

    p.s. установи btrfs, в нем включается сжатие zstd, работает на столько быстро (поэксприментируй с уровнем сжатия) и хорошо что шокирует, плюс у docker есть поддержка снапшотов btrfs что еще ускоряет работу
    Ответ написан
    Комментировать
  • По какой причине может не стартовать контейнер в докере?

    Контейнер стартует и тут же закрывается.

    Потому, что по умолчанию там выполняется команда /bin/bash, которая без терминала тут же заканчивает исполнение.
    Контейнер вы запускаете в режиме демона (ключ -d)
    Будь там не bash а какая-то долгоиграющая команда, mysqld или nginx, всё бы работало дольше.

    Наверное, вам нужно запустить контейнер и «оказаться» в его шелле:
    docker run -it --rm ubuntu
    • -i интерактивный режим
    • -t подключает виртуальный терминал
    • --rm удалит контейнер сразу, как вы из него выйдете


    Вот два варианта запустить Ubuntu, чтобы контейнер остался висеть:
    docker run -d ubuntu tail -f /dev/null – тут команда-пустышка, которая будет выполняться бесконечно;

    docker run -t -d ubuntu – тут подключён виртуальный терминал и bash не вылетит, а останется работать.
    Ответ написан