notdefined11111100101, в 2017 году 1 апреля я завязал с играми вовсе. Просто перестал. Время посвятил освоению ИТ в новых направлениях; чтению; прогулкам.
Не жалею ни капли, только очень жаль потраченного ранее времени (годы!)
Кстати, в этом году я еще начал прикручивать крантик соцсетям. Тут сложнее, но подвижки есть.
Чего и вам желаю.
Что касается ноута… возможно, у вас огромные сложные проекты… у меня ноут на сильно урезанном мобильном i7 ~2012 года, 16г ram, правда MacOS. Pycharm CE актуальной версии работает и не жалуется, но у меня самый большой проект был на ~тысячу строк и десяток модулей, не так чтобы много.
Основная проблема в тепловыделении, иногда начинает орать вентиляторами, особенно на Chrome на некоторых сайтах.
Я думаю, юристы не будут рассматривать суть вопроса. Они будут проверять соответствие договору. Если в договоре явно указан алгоритм «делай раз/делай два», желательно со ссылкой на ГОСТ или международный стандарт, то это они и будут проверять. А вы будете им доказывать, что то, что вы сделали, соответствует тому, что должны были по договору. Именно соответствие договору. Если в договоре будет указано что-то неоднозначное, что можно прочесть так или иначе - вам придется доказывать, что ваше прочтение верно, а не иное (привлекая экспертов, например).
Чтобы договор был максимально однозначным в части, вас интересующей, лучше конкретные формулировки согласовать с юристами (нотариус, занимающийся заверением всяких выгрузок из интернет, подойдет).
Но вообще можно, к примеру, переводить архив в текстовый формат посредством Base64 и заверять этот ascii-текст электронной подписью как обычный документ. Юристам будет безразлично, что за буковки вы им показали. Будет важно, что рядом с буковками лежит электронная подпись, которая удостоверяет, что это те самые буковки, которые были подписаны, от и до.
Главное, чтобы в договоре было написано, что вы обязаны по договору предоставить именно текст с подписью согласно стандарту такому-то. А что там в этом тексте - хоть матерные частушки, главное - электронные подписи. Ваш контрагент принял текст с подписью как исполнение договора, выдал вам акт приемки, в котором приложение - этот текст и электронные подписи - всё.
Martyr1, если raid был из 4 дисков, то один был с контрольными суммами, а три с данными. Соответственно, если убрать с контрольными суммами - три диска с данными есть. Можно вычислить контрольные суммы.
Если из четырех убрать один из дисков с данными - можно попытаться вычислить недостающие данные, имея 2 диска и контрольные суммы.
Если один диск умер, а второй вы выбили из raid - всё. Восстанавливать не из чего.
Единственный шанс, что диск, который вы выбили из raid, вы не сильно испортили и там данные сохранились, а утрачены некоторые заголовочные данные.
Тогда можно попытаться вычитать их оттуда руками и скрестить с тем, что осталось на двух дисках.
Но лично я бы не взялся за это ни за какие деньги.
Люди делятся на тех, кто делает резервные копии и тех, кто еще не делает резервные копии.
Martyr1, а, прочитал. Полагаю, вы убили raid своими манипуляциями. Нельзя было трогать третий диск. Теперь, я полагаю, вы потеряли всю информацию на raid.
Наверно, при очень большом желании можно выковырять что-то руками, но это такое… к тому же понадобится массив сравнимой емкости (даже большей) и много времени, и это если очень повезет.
Элдор Суванов, да при чем тут ORM? Вы статью прочтите. ORM там существенной роли не играет - основная суть как раз между строк про ORM. Разобраны основные способы хранения деревьев в БД, ваш способ, как я понял, там первый. И разобраны запросы SQL для основных действий с этой структурой - получения предков, потомков, изменения и удаления. То, что оно привязано к конкретной ORM, вообще дело десятое.
Впрочем, вам тут уже накидали более-менее готовых образцов…
Думаю, едва ли кто-нибудь захочет глубоко погружаться в чужой API - с этим вам придется, видимо, потеть самому.
Что касается кода, разделите его на функции и отладьте каждую по-отдельности. Тогда будет легче найти место ошибки.
Ну и, вдогонку, не используйте однобуквенные и вообще короткие имена - совершенно же нечитаемо.
Пишите длинные понятные имена.
Фрагменты кода надо размещать в виде текста и оборачивать тэгом code для корректного отображения. Удобно делать кнопкой </> Это обязательно, см.п.3.8 Регламента.
Сюда же относится traceback, ввод и вывод в консоли и другая структурированная текстовая инфа.