Pull to refresh
123
0
Дмитрий Толмачёв @beetleinweb

User

Send message
Увеличьте высоту строки и сократите межстрочное расстояние до нуля. Если не ошибаюсь, получите справа примерно то же самое, что и слева.
Простите, я может чего-то недопонимаю, но как ваш парсер «вывалит ВСЕ встречающиеся ошибки явным образом», не имея описания формата? Я как-то привык считать, что конфиг — это часть API. API должно быть явным образом описано, стандартизировано, иметь версию, описание должно иметь версию и должно быть сохранено в git (или типа того).

Наверняка вы имеет ввиду только ошибки YAML стандарта. Но опечатка в имени параметра этот фильтр пройдёт. И пропущенный обязательный параметр, и неправильное значение (вне диапазона, допустим) — это всё тоже пройдёт незамеченным.

Самое лучшее описание API — то, которое умеет читать какой-нибудь парсер. Который может проверить документ на соответствие описанному стандарту. Так вот я и спрашиваю — есть ли подобное для JSON/YAML?

А то, что описание API так или иначе надо поддерживать… Ну что тут поделаешь — да, можно смотреть на это как на усложнение работы. И не делать эту часть работы. Какое-то время. Но когда вы сами начнёте путаться в своих конфигах и их версиях — вы об этой невыполненной части работы вспомните. Вздохнёте глубоко… И начнёте её делать. Имхо.
Как у вас обстоят дела с валидацией конфигов? Судя по тому, что жалуетесь на опечатки — никак. А зря. И вот по этой причине я бы посоветовал вам оставаться на XML, и сделать XSD схемы для всех конфигов (и прочих документов, если есть).

Я может быть отстал от жизни, но для JSON/YAML общепризнанных стандартных форматов схем документов пока нет вроде бы.

Т.е. оставайтесь на XML, но сделайте конвертеры XML to YAML и обратно. Вручную правьте YAML. Храните и используйте — XML. Ну может быть за редким исключением, когда размер имеет архиважное значение, ужимайте в YAML. Хотя по-моему если использовать ZIP архивацию — вообще без разницы практически, будет ли предварительная стадия XML to YAML.

Такой подход облегчит вам экспорт-импорт и визуализацию на любые случаи жизни. XML всё-таки более распространён пока. Больше возможностей по трансформации в любые форматы — см. XSLT. Опять же — а есть ли уже что-то подобное для JSON/YAML?
— В формате генеалогических древ главное — чтобы совпали кодировки.
— UTF-8?
— Не… DNA-4.
Я вообще-то подразумевал в первую очередь постоянное слияние. Папа и мама съехались и стали жить на одном сервере. :)
Социальные сервисы типа вышеупомянутых — имхо, зло. Весь интернет должен быть социальной сетью, без деления на отдельные несовместимые между собой песочницы, старающиеся свой контент отгородить заборами. И отнимающие силы разработчиков, которые должны были быть потрачены на весь веб целиком, а не оазисы социальности в пустыне.

Но сама идея — объединять генеалогические деревья-«бонсайчики» при рождении ребёнка — по-моему, замечательная. Автор должен оценить. Можно через экспорт-импорт слияние реализовать. Ну и просто перекрёстным связям уделить больше внимания. Есть бездетные браки, есть крёстные-крестники. Наконец, просто друзья-подруги — на семейных фото иные встречаются чаще многих кровных членов семьи. Если есть возможность завести внешний IP (или пользоваться сервисом для динамического IP), то можно делать ссылки даже с одной домашней виртуалки на другую.

Фича хороша и для популяризации проекта. Она может редко используемая, но такая понятная, хорошо иллюстрируемая. Умильно-сентиментальная. Цепляюще-запоминаемая.
Да, вас тут ещё про Docker спрашивают. Ещё один совет до кучи — сначала сделайте переход на Linux, а потом уже пробуйте Docker. Docker под Windows — это проблемно, медленно и почти бесполезно, как мне показалось. А начать в любом случае лучше с простых виртуалок. Пусть будут как промежуточный шаг в направлении виртуализации-контейнеризации.
Делайте виртуалки сами, локально. Выкладывайте для тех потенциальных пользователей, кто не сразу решится на подвиг установки из девяти шагов. Используйте сами для тестов и как бекапы полностью работоспособной настроенной системы в какой-то стадии разработки — делайте снепшоты.

Виртуалки локально — это совсем несложно. И очень полезно для веб-проекта (и для любого, требующего сложного процесса установки и настройки). Я сам долго откладывал в своём проекте, потом жалел о том, что столько откладывал. Один раз разберитесь с установкой OS (может быть даже разных). Попробуйте конвертирование разных форматов виртуалок (VMware, Virtual Box) — люди любят разные фломастеры.
Если посмотреть какую-нибудь картинку, нагугленную по терму «столкновение галактик», то видно, что очень даже значительное количество звёзд меняют свои орбиты «на 90 градусов». И, как я уже говорил, начинает работать закон больших чисел — что-то где-то будет перехвачено, пролетит мимо… но хоть один да попадёт. Боюсь, вероятность низка, только когда орбиты очищены от мусора за миллионы лет. И возрастёт она не на 1-2 порядка, а гораздо больше.

Кстати, внешние планеты расположены в одной плоскости. А облако Оорта рисуется как очень толстый бублик, почти шар.

И кстати, плоскости вращения двух планетных систем вряд ли будут совпадать. Так что на перехват я бы ставки не делал.

Насчёт «других угроз» — при любой вероятности согласен. Меня вот угроза Роскомнадзора для разумной жизни на одной седьмой части суши гораздо больше метеоритной атаки волнует. Как-то актуальнее — на злобу дня.
Автор статьи видит опасность в изменении орбит каждого тела в облаке (да и как может быть иначе — была одна звезда в системе, а стало две). Я же как бы намекаю, что опасность может быть раза в два выше, поскольку не исключено появление второго облака.

Столкновение галактик, кстати — очень хороший пример (сам собирался его привести, но сократил). Да, столкновения звёзд при этом очень редки. Но зато насколько кардинально меняется форма галактик! Облака пластичны. Даже если бы они существовали независимо, всё равно — проходя друг сквозь друга, они бы полностью поменяли форму. Т.е. орбиты каждой пылинки поменяются.

А нам пока будет достаточно всего одной такой пылинки. Тут закон больших чисел начинает работать. Хоть одна да наверняка прилетит в такой ситуации, как пролетающая мимо звёздная система.

Впрочем, я надеюсь, что через тысчонку-другую лет земляне перестанут вздрагивать всей планетой от каждого пролетающего рядом камня. «Космическая ПРО», колонии на Марсе и далее, и наконец межзвёздная экспансия — хорошие лекарства от таких детских страхов. Эвакуация, потом прилетаем обратно и чистим завалы, как японцы после землетрясения. Это если отстреляться не смогли, если слишком плотная ковровая бомбардировка была.
Я «ненастоящий астроном», но по-моему у проходящей мимо звезды могут быть и свои планеты (в том числе свой газовый гигант), и свой пояс астероидов, свой пояс Койпера и, в конце концов, своё облако Оорта. Думаю, дальше можно не продолжать — если у вас есть фантазия, общую картину взаимного проникновения систем вы уже представили.
Кто ж заставляет их «выпадать» совсем? При чтении — в словарь. При разговоре — переспросить, попросить пояснить. Трудно ведь оспаривать предположение, что знание 3000 самых «частотных» слов сократит непонимание в разы.

Кроме того… Вы пробовали посмотреть на эти красные слова? Я плохо знаю английский, но я почти все из них угадал по смыслу. Часть просто похожа «по звучанию» (да, можно сильно обмануться, но не всегда же), некоторые состоят из двух известных слов, имеют знакомый корень (да, тоже можно ошибиться, но не так уж часто).

Я по диагонали иногда просматриваю английские статьи, и при моём очень бедном словарном запасе худо-бедно понимаю, о чём речь. Это при том, что узнаю треть слов примерно, а то и четверть… Может быть недостаток словарного запаса способствует развитию интуиции? И наоборот…
Первая мысль была такая же. Вторая мысль — «наверняка это кто-то уже сделал». И дальше — гуглим. Причем после «oxford 3000» гугл уже сам подсказывает «word list».
Там на гитхабе ещё кнопочка Raw есть, чтобы совсем уж легко сохранить как текст.

github.com/OliverCollins/Oxford-3000-Word-List/blob/master/Oxford%203000%20Word%20List.txt
В задаче про друзей ответ подразумевает, что по вертикали и диагонали матрицы — разные люди из разных подгрупп. Что обычно не так. Если матрица квадратная и симметричная, и по главной диагонали идут Y (каждый человек ведь друг самому себе?) то сравнивается обычно каждый с каждым из одной группы. В таком варианте будет ответ «1 круг дружбы», A и C друзья, B туда не входит. Откуда свалились D, E, F? И если уж они свалились, почему не построена матрица 6 на 6? Откуда я вообще должен был извлечь совершенно неочевидную и неправдоподобную информацию, что матрица сравнений неполная, а её квадратность, симметричность, и главная диагональ — не более чем случайные совпадения? Вам вероятность такого совпадения подсчитать? Я почти уверен, что матрицу составили для другой задачи, а условия этой писал человек, не разбирающийся в специфике кластеризации. Вряд ли это попытка специально запутать соискателя.

В задаче про пьяного у пропасти считаются все варианты для трёх шагов. И потом вероятность погибнуть… для четвёртого! А он его делал вообще? Может он лёг и заснул. Вероятность выжить — почти 100% (если во сне не ворочается).

Вопрос про муравьёв — от скорости многое зависит. Можно и в задний бампер въехать.

С яйцами вообще тупо. Ну спустись на первый, с него и начинай. Думаю, для нормальных яиц, не резиновых, на первом же этаже всё станет ясно. В задаче же не сказано, что надо потратить как можно меньше яиц. Если яйцо не разбилось — оно не считается потраченным. Подбирай и бросай дальше. Ну и при фантастической неразбиваемости — поднимайся на один этаж. Сколько бы их не было — потратишь всегда ровно одно.

В общем, мне всегда было забавно, когда люди с прямолинейным мышлением пытаются выдумать неординарные вопросы. Самое забавное, когда ты обходишь их условия, а они потом обижаются — «так нельзя!». Нельзя? Хм… Вы хотите найти людей с неординарным взглядом, или получить дубовый прямолинейный ответ, в точности подпадающий под шаблоны вашего мышления?
Обычно барабан вставляется на место резким движением, не дожидаясь его полной остановки. Или отпускается выжатый спусковой крючок, если барабан уже на месте, что также останавливает вращение в некий случайный момент. Гравитации не оставляют шансов.

В общем, тоже на первое место поставил бы здравый смысл (даже в таком не очень здравом деле). Тем не менее математически я эту задачу тоже решил. Результат забавный. Но самое интересное — третья попытка. А вообще, у настоящего программиста должен быть восьмизарядный, однобайтовый.
Гораздо важнее образования — обратная связь. Когда программист пишет плохой код, ему, как правило, потом не больно. Потом мучительно больно другому программисту, которому приходится в этом коде ковыряться. И когда пишет хороший код — слой масла на бутерброде редко становится толще вот прям таки сразу. Корреляцию сложно оценить. Она есть обычно, никто не спорит — но зависимость эта слабая, сложная, неоднозначная — много всяких факторов, задержка по времени очень существенная.

И про это народный программисткий юмор есть — «пиши код так, как будто его читает маньяк, который знает, где ты живёшь». И где-то на хабре читал недавно, автор жалуется — в компаниях обычно не разбираются, кто написал конкретный плохой код, кто автор бага. Даже не в том дело, что надо найти, чтобы наказать. Нет. Найти, чтобы сказать — «не пиши так больше, дорогой товарищ» (кажется, про нагрузочное тестирование тема была).

Никакое высшее образование этого не заменит и не изменит. Потому что эта обратная связь — лучший способ получить реальный, жизненный опыт, а не книжный.
Я стараюсь разделять свои функции на два типа — «логические» (не имеет ничего общего с логическими операциями) и «физические» (разумеется, ничего общего с физикой).

Я представляю себе как бы два разных читателя кода. Один — босс, ему вечно некогда, он вечно торопится. Ему надо только знать, что сделано. И не важно — как. А второй — технарь, вот ему важно знать, как именно сделана конкретная вещь. Но не важно, в рамках какой большой высокоуровневой задачи. От неё вообще должно быть как можно меньше зависимостей.

Я знаю, в разных умных книжках эти вещи по разному называются. «Бизнес-логика» и «низкоуровневая реализация», или ещё как-нибудь. Но практически все авторы имеют ввиду если не одно и то же, то нечто близкое. В больших сложных проектах уровней может быть и побольше, этакая фрактальная структура.

Так вот… О чём это я? А! «Логические» функции я стараюсь делать короткими. Это как тезисы доклада для босса. А вот «физические» — они могут быть и короткими, и длинными. Зависит от алгоритма, от предметной области — да мало ли от чего. Не всегда технарю удобно нырять по стеку всё ниже и ниже каждые 5 строчек. А босс редко спросит про детали. Ну 2, максимум 3 уровня — дальше он не полезет вникать.

И не важно, что обычно босс и технарь — это я сам. Такая вот шиза.
Виртуальной памяти может и хватит на несколько итераций, а вот терпения… Фильм хороший, но там время ускорялось в глубине. В реальности же явно будет наоборот. К нашему глубочайшему сожалению.
При этом стоит ещё пустить слух, что якобы «одна из этих инструкций на самом деле запрещает такую комбинацию, от которой нехилый приход, круче чем от LSD, но только на пару секунд… а при другой комбинации спирту получается в 3 раза больше, чем в кефире». Остальные слухи они сами придумают, если не дураки.
Кстати… Я бы ещё специально написал кучу инструкций, запрещающих подобную готовку — типа, «не вздумайте вот это с этим мешать, а вот это с этим, нельзя, рискованно, негативные последствия, вам станет плохо». Подумайте, почему. :)

Information

Rating
Does not participate
Location
Челябинск, Челябинская обл., Россия
Date of birth
Registered
Activity