Я, похоже, жил в каком-то другом мире. До меня всё доходило уже взломанным и со снятыми защитами. То же «Звёздное наследие», которое нельзя было переписать копированием файла, можно было переписать полным копированием диска. Хотя в оригинальной версии вроде в дискете были какие-то дырочки.
Несмотря на то, что многие защиты по современным меркам кажутся примитивными, всё равно нахлынул какой-то внутренний зуд, хочется разобраться, как оно раньше работало. А из моделей спектрумов, ничего более крутого чем относительно стандарный 128К c AY и дисководом я до сих пор в глаза не видел.
Мне ассемблерами/дизассемблерами на спектруме пользоваться не доводилось. Переводил инструкции в машинные коды по таблице в тетрадку и потом побайтово вводил.
Это просто обычай. […] Записанная в C мажоре музыка будет часто начинаться с C или заканчиваться на эту ноту или даже аккорд C мажор. Музыка, написанная в A минор, нередко будет начинаться с A или заканчиваться на эту ноту или аккорд A минор.
Это не то чтобы обычай — разница в тонике. Мелодия действительно не всегда начинается или заканчивается ей, но при этом все остальные звуки так или иначе тяготеют к ней (к до в до мажоре и к ля в ля миноре). Также если мелодия и не заканчивается тоникой, её хочется мысленно додумать — мелодия стремится в неё разрешиться.
Исходим из того, что на сервере все даты хранятся в базе данных в формате GMT (и это правильно).
Это правильно только для дат в прошлом или ближайшем будущем. Для дат в отдалённом будущем, например, «17 июля 2018 г., 15:00 по Москве» хранить только дату в GMT недостаточно, т.к. теряется привязка к местности и неизвестно, в каком часовом поясе эта местность будет находиться через 3 года.
Это очень круто. Совсем недавно мне тоже нужно было сливать произвольные массивы и я думал попробовать для этого Git, правда, дальше идеи руки не дошли. Два вопроса:
Можете ли привести пример, как выглядит ручное разрешение конфликтов с json?
Существует ли наряду с jsonmerge.js что-то типа jsondiff.js, которое бы на основе двух json генерировало бы дифф, который сам по себе был бы json-ом и мог бы быть как-то наложен на первый? По большому счёту, мне нужен дифф в каком-то простом формате, из которого можно было бы построить объектно-ориентированную модель разницы двух json-ов.
Если что, у меня запускается и со скайп-табом, и без. Просто между двумя вариантами никакой разницы. Вроде бы такое же было и при предыдущих обновлениях скайпа.
Я никого не собирался порочить, он и мой кумир тоже, можно сказать :-)
Я имел ввиду, что в блоге есть ссылка на гугл-плюс, можно написать ему сообщение и спросить, чем он занимается/зарабатывает на жизнь (не думал, что вы имели ввиду это).
Почему бы тогда не сделать указание контекста обязательным, если заведомо известно, что безопасное экранирование побьёт вывод? То есть, ситуация «без указания контекста» не имеет смысла в принципе.
В том-то и беда, что HTML-шаблонах бывает не только HTML, но и Javascript. И к нему никакие HTML-сущности неприменимы. К примеру, для js-строки нужно экранировать символ перевода строки, а для HTML-строки — открывающую угловую скобку. Если по умолчанию мы будем делать и то, и то, то по умолчанию будут «биться» и js-строки (заменой < на "), и многострочные HTML-строки (заменой перевод строки на "\n").
В любом случае придётся указывать контекст — сразу же или до первого бага.
Несмотря на то, что многие защиты по современным меркам кажутся примитивными, всё равно нахлынул какой-то внутренний зуд, хочется разобраться, как оно раньше работало. А из моделей спектрумов, ничего более крутого чем относительно стандарный 128К c AY и дисководом я до сих пор в глаза не видел.
Спасибо за перевод. Очень доступно.
Это не то чтобы обычай — разница в тонике. Мелодия действительно не всегда начинается или заканчивается ей, но при этом все остальные звуки так или иначе тяготеют к ней (к до в до мажоре и к ля в ля миноре). Также если мелодия и не заканчивается тоникой, её хочется мысленно додумать — мелодия стремится в неё разрешиться.
Здесь можно почитать: http://www.7not.ru/theory/06.phtml
Зачем перезаписывать файл полностью?
Это правильно только для дат в прошлом или ближайшем будущем. Для дат в отдалённом будущем, например, «17 июля 2018 г., 15:00 по Москве» хранить только дату в GMT недостаточно, т.к. теряется привязка к местности и неизвестно, в каком часовом поясе эта местность будет находиться через 3 года.
Я имел ввиду, что в блоге есть ссылка на гугл-плюс, можно написать ему сообщение и спросить, чем он занимается/зарабатывает на жизнь (не думал, что вы имели ввиду это).
Вот, кстати, несколько интересных загрузчиков (правда, не от него).
В любом случае придётся указывать контекст — сразу же или до первого бага.