Pull to refresh
8K+
6
Дмитрий Соколов@Assador

Web-разработчик

3,8
Rating
3
Subscribers
Send message
Вообще, да. Так логичнее. Поправил сам скрипт, закоммитил, поменял описания в статье и на сайте. Спасибо.
И, кстати, в вашем примере без ключа -p скрипт пишет в лог также суммирующую информацию, так что пайпить уже не комильфо. Вот, кстати, вопрос, надо ли писать в лог эту инфу…
Именно. После редактирования (при необходимости) log.txt, просто пишем

$ cat 'log.txt' | xargs rm

Ну или, если не собираемся просматривать и редактировать список файлов, можно и в одну строку:

$ ds-findorphaned -prR -d "~/maybe_orphaned_images" -f ".*\.jpg$" -D "~/search_here, ~/and_here" -F ".*\.php$" | xargs rm

Но я бы не стал. Как я уже писал, неупоминаемость файлов — лишь один из признаков ненужности. Так можно удалить что-нибудь нужное.
Можно. Но смысл записи в лог как раз в том, чтобы перед удалением файлов просмотреть этот список и убрать оттуда строки с файлами, которые удалять не надо.
Ну, если с учебниками сейчас действительно такая петрушка (я как-то давно не смотрел их; сейчас уже достаточно спецификаций и конкретных практических находок), тогда беру свои слова обратно.
Да, хороший ресурс. Есть ещё классная программа, Gpick, которая делает то же самое, но и гораздо больше. Не онлайн — минус, богатые возможности — плюс. Я сам создаю палитры новых дизайнов, начиная с неё.
У меня есть другое мнение на этот счёт: теория цвета бесполезна.
Мне одному кажется, что сама статья в результате и приводит к теории цвета, только путём собственных исследований? :) А по сути — отлично!
Сейчас быстро глянул. Есть учебники по HTML5. Зачем начинать с учебников 2000-х? Но даже если так, надо быть в танке, чтобы не знать о новых спецификациях. Интернет-то зачем? w3.org — и вперёд. Да я-то не против поста, ради бога, просто имхо это выглядит, как «а ещё я на машинке умею…» Тогда уж надо пробежаться по всем нововведениям с начала 2000-х. А это уже и получается полноценный учебник :) В итоге получаем следующее: для учебника начало как-то бессистемно и с середины, а для отдельного поста маловато. Впрочем, полезной информации мало не бывает, почему нет…
Всё хорошо, но, простите, пост о том, что небо синее, а трава зелёная. Любой, даже начинающий, верстальщик должен это знать. А если нет, то, может, стоит начать с учебника?
Но я понять вообще не могу где может быть в сайтах вложенность больше 7-10…
К сожалению, бывает. Правда, обычно удаётся клиента образумить. Но, опять же, я написал, что сайты просто натолкнули на мысль. К сайтам это малоприменимо.
И давайте определим, КАРТА САЙТА — xml или html представление?))
Вне зависимости от представления. Структура разделов. Основная. Естественно, бывают ещё разные небольшие менюхи.
Да, в примере было лень выдумывать длинную «рыбу». Всё это делалось не под конкретный проект. Просто довольно часто встречаются такие меню. Как я уже писал в статье, я веб-разработчик. Вы бы видели, какие карты сайта порой предоставляют заказчики. Понятно, что конкретно эта реализация для сайтов не слишком-то подходит. Скорее, это всё — просто результат отвлечённых размышлений о том, как можно визуализировать удобнее подобные деревья. Сейчас с ходу пример не нарою, но для второго примера постараюсь подобрать вполне конкретный вариант.
Что ж я вечно промахиваюсь и отвечаю в корень ветки… :) Дублирую сюда:
Сравниваем классическое представление и «новое». В классическом виде это все подается в группировках, по приоритетам людей (по спросу) — GroupBox, радиокнопки и чекбоксы.
Понимаете, идея была именно в представлении меню, а не поиска-фильтра-сервиса. То, что я сверху накрутил фильтр, наверно, и вводит в заблуждение. Наверно, зря объединил в статье две разные вещи — идею представления меню с большой вложенностью, но с немногими братьями и этот фильтр. Для идеи представления именно меню чекбоксы и радиокнопки как-то ни к чему.
Понимаете, хранение данных удобное для программиста редко когда бывает удобно так же для конечного пользователя
Тут-то как раз удобство программиста ни при чём. Я и XML отлично читаю. Но в принципе, с тем, что сам пример не слишком удачен, согласен. Я и в статье написал «Дерево для иллюстрации данной статьи не слишком удачное». Подберу дополнительно ещё один пример понагляднее. Благо достаточно просто подсунуть другой XML-файл.
Сравниваем классическое представление и «новое». В классическом виде это все подается в группировках, по приоритетам людей (по спросу) — GroupBox, радиокнопки и чекбоксы.
Понимаете, идея была именно в представлении меню, а не поиска-фильтра-сервиса. То, что я сверху накрутил фильтр, наверно, и вводит в заблуждение. Наверно, зря объединил в статье две разные вещи — идею представления меню с большой вложенностью, но с немногими братьями и этот фильтр. Для идеи представления именно меню чекбоксы и радиокнопки как-то ни к чему.
Понимаете, хранение данных удобное для программиста редко когда бывает удобно так же для конечного пользователя
Тут-то как раз удобство программиста ни при чём. Я и XML отлично читаю. Но в принципе, с тем, что сам пример не слишком удачен, согласен. Я и в статье написал «Дерево для иллюстрации данной статьи не слишком удачное». Подберу дополнительно ещё один пример понагляднее. Благо достаточно просто подсунуть другой XML-файл.
Курение) и (Дети) => Если выбрать Курение — то сразу отпадают все что с детьми…
А если человек передумает? Потом к «детям» будет сложно вернуться. Сначала убрать «курение» и т.д.
Например в данной выдаче «дороговизна» без реальных цифр бессмысленна. А для курящих, для некурящих, смешанный — можно упростить до [checkbox] «У нас не курят». Тут какая — та не состыковка (путаница). «Смешанный» — один курящий зал — это о том, что одно помещение из 5 в котором курят или все вместе сидят и курильщики и не курильщики?))
Это просто пример для иллюстрации самого принципа визуального представления древовидной структуры — дерева, у которого мало братьев одного уровня и глубокая вложенность. Рестораны — только пример! :)
И как я понял это не меню, а фильтр.
Опять же. Это — и то, и другое. Просто визуальное представление дерева на примере фильтра.
А. Или вы имеете в виду что-то столбцов, обозначающих уровень вложенности, в каждом из которых вертикально расположены братья на этом уровне? И с перемоткой по горизонтали? Если так — тоже вариант. Почему нет? Просто мне показалось так интереснее.
Не совсем. Кто сказал, что родительский больше не нужен? К примеру, человек может выбрать «живую музыку», а потом решить, что ему, в общем, всё равно, какая именно — живая или нет, и выбрать просто музыку. Кроме того. С этим тоннелем, имхо, нагляднее представлены также все братья родительского элемента. А списком получится просто простыня (прошу прощения за тавтологию :)
Случайно ответил в основную ветку. 10-15 ещё не беда. Можно заменить текст пиктограммами. А вот уже этак с 20-30 — читайте статью внимательнее: «Таким образом достигается цель — при дереве, в котором немного братьев одного уровня (в окружность много не влезет), мы имеем практически неограниченные возможности представления очень развесистого, глубокого дерева без потери наглядности.»
10-15 ещё не беда. Можно заменить текст пиктограммами. А вот уже этак с 20-30 — читайте статью внимательнее: «Таким образом достигается цель — при дереве, в котором немного братьев одного уровня (в окружность много не влезет), мы имеем практически неограниченные возможности представления очень развесистого, глубокого дерева без потери наглядности.»
Может, я неправильно понял… Вы имеете в виду обычное представление? Построчное, как в файл-менеджере? Если да, то я же написал, в чём по моему мнению проблема. Не в высоте самого списка, а в ширине. Либо, если подразделы выделять не отступами, а ещё как-то, то всё равно вся наследственность выглядит не наглядно. Представьте себе глубину вложенности эдак в 20 уровней.
М… Может, вы и правы. Вообще, аналогия с высотой тут как-то неочевидна. Я имел в виду под ветвистостью именно разделение на разные ветви, а не их количество. Но скорее соглашусь с вами.

Information

Rating
1,341-st
Location
Москва, Москва и Московская обл., Россия
Date of birth
Registered
Activity