По пункту 2 это всегда попаболь. Есть конечно Hibernate Envers, https://hibernate.org/orm/envers/, но иногда это не то, что нужно.
Если дизайнить такую штуку с нуля — то нужны «срезы» — коллекции непротиворечивых на некоторый момент времени записей, например если госпожа Иванова осуществляла платёж в прошлом году, а в этом — она уже госпожа Петрова, то в отчётах за прошлый год она должна отображаться как по-прежнему как Иванова.
В данном примере можно версионировать данные в той же таблице и выдать клиенту ещё один ключ. Что-то типа натурального — CLID например. А дальше аккуратно смотрим: платежи всё такое, что делал конкретный живой человек, привязываем и к СLID, и к ID, который PK. Агрегаты при этом работают нормально — но считать их нужно исключительно по CLID. В остальных местах — честная связка по PK, чтобы показывать версию записи, актуальную именно на нужный момент времени.
Действительно, на вкус и цвет все фломастеры разные :)
Пример с одной из предыдущих работ стажировок (уже 24 года назад, оказывается)
• Имя таблицы описывает роль таблицы (т.е. что она хранит)
• Таблицы именуются в единственном числе, поскольку обычно 1 строка = 1 запись, но могут быть варианты, когда в одной строке таблицы хранится массив объектов — тогда имя во множественном (t_geopoints например)
• Если таблица – это отражение связи многие-ко-многим, то её имя формируется из связываемых таблиц с указанием роли
• Все таблицы имеют префикс T_
• Все представления имеют префикс V_
• Поля, которые совпадают с зарезервированными словами, имеют постфикс _C (ещё в паре мест я видел обязательный префикс С_ и обязательный постфикс _COL)
• Имена колонок PK формируются как имя таблицы без префикса, плюс постфикс _ID
• Имена колонок FK формируются как имя таблицы, куда ходить, без префикса плюс постфикс _FK
Вроде бы простые правила, но случаются и проблемы:
• Суровая таблица вроде T_CUSTOMER_CNT_CONTACT_PERSON, и имена колонок, ограничений и индексов уже перестают соответствовать ограничениям БД на длину идентификаторов пофиксено в Ora 12.2. В PgSQL – 63 символа, что неожиданно тоже немного. А если вдруг нужно добавить ещё одну промежуточную таблицу, и то, что написано выше – это только часть нового идентификатора…
• Что делать, если в одну и ту же таблицу нужно ходить два и три раза, например, при возможных ролях пользователя: исполнитель, пользователь подтвердивший действие, пользователь подписавший запись – то тут в имя колонки ещё нужно впихнуть роль
• А ещё бывают составные первичные и соответственно внешние ключи
• Мелочи, но неприятно – при построении схемы БД это вот всё не лезет ни на какой экран и уже нужно клеить 12 (или 28) листов A4 чтобы хоть что-то обсудить
Я страюсь использовать более естественную (для меня) схему наименований:
• Первичный суррогатный ключ – id, если вдруг натуральный – то честное наименование такового
• Колонка FK – роль внешней таблицы в контексте фиксируемого факта, причём по возможности – глагол. Запросто может не совпадать с именем таблицы, куда нужно ходить, для примера из предыдущего пункта – executed_by, approved_by, signed_by. Тогда в запросе получается что-то типа
… FROM t_document doc JOIN t_employee signer where doc.signed_by = signer.id JOIN t_employee appr ON doc.approved_by = appr.id…
И я бы с удовольствием вообще не писал первичный ключ в запросе, если бы синтаксис SQL такое позволял.
• Постфиксы в колонках — только если нельзя придумать загуглить синоним, который точнее, чем чем зарезервированное слово, описывает роль хранимого атрибута. Т.е t_employee.date — плохо, а t_emloyee.birthdate — хорошо. t_payment.timestamp — плохо, потому что непонятно, это дата/время нажатия пользователем кнопки «оплатить», дата/время начала (или окончания ?) обработки в платёжной системе, или вообще дата импорта записи из внешнего лога. Пока правильно назовёшь, десять писем заказчику напишешь. Ну и бонусом — при таких упражнениях немного английский подтягивается :)
Мне бы ваш график :) По жизни сова, естественный период бодрствования — с часу дня до трёх ночи, нормальная производительность с восьми вечера до двух где-то. Мучаюсь всю жизнь, и что с этим делать — непонятно. Джетлаг пробовал только в обратную сторону — минус четыре часа, и это ужас-ужас, после чего возврат к «как обычно» — за пару дней и с удовольствием.
Интересно, а длинноволновая радарная триангуляция летящего самолёта (для которой вся ЭМ-невидимость не очень работает) это бред, или таки можно использовать? Ну то есть три (лучше-больше) радара с известной геопозицией, облучают некоторую зону, если там есть хоть что-то — все имеют отклик. По задержке прихода оного — вполне можно вычислить местоположение объекта. Для GPS вот получается с точностью в метры. С учётом того, что боевой самолёт — вполне материальная тушка в 30 — 40 (а то и 100+) тонн и мгновенно он вектор скорости поменять не может, его (их) наверно можно отделить как от статики, так и от высокочастотных помех?
Ещё стоит вспомнить, что киллер-фичей МК-52 (а может быть и ещё каких-то на той же системе команд) было ППЗУ. Потому что на всём остальном при выключении питания нужно было начинать набирать программу заново, и батареек надолго не хватало. 52 вообще не очень простая машинка, по слухам тех времён у него была спецкомплектация для работы на космических кораблях и станциях ;)
Как же я был счастлив, когда мой МК-61 угодил в гарантийный ремонт третий раз, что по правилам Советского Союза позволяло получить деньги назад в полном объёме, добавить и купить 52
ЛПР обычно просто не до этого. Поскольку практики успешных исков на x — xxx млн. рублей за разные виды ущербов от физика к юрику в РФ нет, соответственно, репутационные или прямые финансовые потери от реализации рисков утечки — ничтожны, и любой риск-аналитик говорит, что проще (==дешевле) таковые принять.
Есть и другие методы — например получение фактов просмотра конкретных экранов конкретным человеком непосредственно из трафика. Вот только у безопасников обычно не так уж горит, чтобы всем вот этим заниматься, хотя первых особо эффективных обычно ловят меньше чем через месяц от начала пилота, проверено на реальных банках ;)
Мы вот тоже, после некоторого количества неудач, решили, что раз мы нанимаем программиста — он таки должен уметь программировать! И сделали класс с заготовками методов, заданиями в виде JavaDoc и тестами TestNG, которые проверяют результаты.Первый метод — реализовать тело FizzBuzz, далее задачки чуть хитрее (но все из практических ситуаций), в пределах стандартной библиотеки Java. Кандидату предоставляется ноутбук с IDEA, изображение дублируется на проектор в переговорке. Вопросы задавать можно, гуглить тоже. Обычно кандидаты справляются за 15-40 минут.
Интересен не столько достигнутый результат (все тесты зелёные), сколько способ решения задачи / кодирования. Если предложенный вариант решения мягко говоря странен — начинается дискуссия по возможным улучшениям и/или краевым случаям, что позволяет оценить опыт кандидата и количество косяков в production, которые от него можно ожидать.
Экономит просто ТОННЫ времени и нервных ресурсов на собеседованиях и неплохо отделяет тех, у кого код на кончиках пальцев, от заучивших ответы про устройство HashMap.
Число 238 написано три раза, шрифт Roboto 40, пикселизовано в GIMP с размером пикселя 10.
Все три изображения — разные.
Как узнать, какой конкретно способ пикселизации был использован при подготовке замазанной картинки, если учесть, что я не буду пикселизировать один и тот же номер 100500 раз?
Получается же два неизвестных, и очертания цифр, и алгоритм разбрасывания пикселей (ну, не алгоритм, но его seed)?
Добавлю пять копеек — а если поплавать в тёплом море и поесть вкусную местную еду — то ехать не раньше 15 сентября, поскольку уже не так жарко. Примерно месяц бархатный сезон, потом начинает холодать.
Я тоже долго выбирал… и в итоге купил этот, 5491. Для сценария кодим-кодим-кодим — компилируем и поднимаем толстый war — вполне подходит, перегреваться не успевает. Плюс охлаждающая подставка за две тысячи — и полёт нормальный в итоге. Аналогов за такие же деньги на конец 2018 попросту не было. Но у меня специфический профиль нагрузки — ресурсов нужно много, но на короткое время (до одной минуты)
Ацетилен-кислородный резак. Быстро и с гарантией. Причём можно даже не доставать из полки — порезать всё насквозь на ломтики, главное не накапать в тапочки расплавом ;)
Нужен или не нужен конспект? И нужно ли его писать? — It depends, как говорят англичане. Проблема в том, что люди все разные (впрочем, на этом ресурсе в силу его направленности есть определённый перекос*). Кто-то прекрасно воспринимает информацию со слуха, и ничего не понимает, читая книгу. Такой человек даже для обдумывания чего-либо затевает дискуссию, так как для того чтобы думать — нужно говорить слова ртом. Есть и прямые противоположности — «в книге же всё понятно написано, что вы меня своей болтовнёй отвлекаете», или «со слуха не воспринимаю, мне нужно посмотреть глазами». Кто-то не воспринимает текст от слова «совсем» — не в устном, не в письменном виде, ему бы потрогать ну или хотя бы нарисовать связи в графическом виде. Разные мы все :) Ну а лекции в существующем виде — неизбежное зло, поскольку студенты все разные, а понять материал должен каждый. По-хорошему, при приёме в институт нужно тестировать на способы восприятия (и тесты там несложные), и выдавать каждой группе материал в наиболее «усвояемой» форме. Но кто же этим будет заморачиваться в текущих условиях…
*осознанно выбравшие работу с компьютером обычно больше визуалы, чем всё остальное. Способность молча общаться в мессенджере с соседом по рабочему месту — она на неподготовленных аудиалов сильное впечатление производит, да…
Двухходовка: сначала банковским переводом на счёт «до востребования» в Сбер (правда идти может до трёх дней), потом в офисе сбера снимаем у операциониста со счёта (НЕ с карты) сколько надо. Если это самое надо больше 300-400К — лучше заказать деньги заранее.
Я правильно понял, что каждый кадр обрабатывался независимо, а потом из них собирался видеопоток? Если да, то есть существенный резерв для улучшения — анализ нескольких кадров с выделением смещений объектов, поскольку на каждом кадре размытие случайное, а если сформировать несколько «статических фотографий» одного и того же объекта (убирая смещения, повороты и масштабирования) то можно именно рассчитать оригинальные пикселы. Нейросеть же скорее их «придумывает» исходя из того, что она видела на похожих фрагментах.
Ну, с Бруно и Галилелем в своё время не слишком удачно вышло, хотя сейчас то всё очевидно. Если кто начинал с ОО-* (проектирования, разработки) — то по-другому вроде как и не удобно уже, неправильно и вообще враждебно :).
На мой вкус реляционный подход универсальнее, а если ещё и все связи изначально проектировать как n:n, то сломать структуру новыми бизнес-требованиями практически нереально, как и добиться достойной производительности потом, так что каждый раз компромисс.
Помимо понятия «фактов» я использую ещё и «бизнес-сущности»: всё, что в требованиях (сценариях) существительное — бизнес-сущности, глаголы — факты. У фактов кстати всегда есть timestamp — действие происходит однократно и в конкретный момент времени. Бизнес-сущности зато должны иметь версии (была госпожа Иванова, стала — Петрова, и отчётность в прошедших периодах не должна уехать).
Если дизайнить такую штуку с нуля — то нужны «срезы» — коллекции непротиворечивых на некоторый момент времени записей, например если госпожа Иванова осуществляла платёж в прошлом году, а в этом — она уже госпожа Петрова, то в отчётах за прошлый год она должна отображаться как по-прежнему как Иванова.
В данном примере можно версионировать данные в той же таблице и выдать клиенту ещё один ключ. Что-то типа натурального — CLID например. А дальше аккуратно смотрим: платежи всё такое, что делал конкретный живой человек, привязываем и к СLID, и к ID, который PK. Агрегаты при этом работают нормально — но считать их нужно исключительно по CLID. В остальных местах — честная связка по PK, чтобы показывать версию записи, актуальную именно на нужный момент времени.
Пример с одной из предыдущих
работстажировок (уже 24 года назад, оказывается)• Имя таблицы описывает роль таблицы (т.е. что она хранит)
• Таблицы именуются в единственном числе, поскольку обычно 1 строка = 1 запись, но могут быть варианты, когда в одной строке таблицы хранится массив объектов — тогда имя во множественном (t_geopoints например)
• Если таблица – это отражение связи многие-ко-многим, то её имя формируется из связываемых таблиц с указанием роли
• Все таблицы имеют префикс T_
• Все представления имеют префикс V_
• Поля, которые совпадают с зарезервированными словами, имеют постфикс _C (ещё в паре мест я видел обязательный префикс С_ и обязательный постфикс _COL)
• Имена колонок PK формируются как имя таблицы без префикса, плюс постфикс _ID
• Имена колонок FK формируются как имя таблицы, куда ходить, без префикса плюс постфикс _FK
Вроде бы простые правила, но случаются и проблемы:
• Суровая таблица вроде T_CUSTOMER_CNT_CONTACT_PERSON, и имена колонок, ограничений и индексов уже
перестают соответствовать ограничениям БД на длину идентификаторовпофиксено в Ora 12.2. В PgSQL – 63 символа, что неожиданно тоже немного. А если вдруг нужно добавить ещё одну промежуточную таблицу, и то, что написано выше – это только часть нового идентификатора…• Что делать, если в одну и ту же таблицу нужно ходить два и три раза, например, при возможных ролях пользователя: исполнитель, пользователь подтвердивший действие, пользователь подписавший запись – то тут в имя колонки ещё нужно впихнуть роль
• А ещё бывают составные первичные и соответственно внешние ключи
• Мелочи, но неприятно – при построении схемы БД это вот всё не лезет ни на какой экран и уже нужно клеить 12 (или 28) листов A4 чтобы хоть что-то обсудить
Я страюсь использовать более естественную (для меня) схему наименований:
• Первичный суррогатный ключ – id, если вдруг натуральный – то честное наименование такового
• Колонка FK – роль внешней таблицы в контексте фиксируемого факта, причём по возможности – глагол. Запросто может не совпадать с именем таблицы, куда нужно ходить, для примера из предыдущего пункта – executed_by, approved_by, signed_by. Тогда в запросе получается что-то типа И я бы с удовольствием вообще не писал первичный ключ в запросе, если бы синтаксис SQL такое позволял.
• Постфиксы в колонках — только если нельзя
придуматьзагуглить синоним, который точнее, чем чем зарезервированное слово, описывает роль хранимого атрибута. Т.е t_employee.date — плохо, а t_emloyee.birthdate — хорошо. t_payment.timestamp — плохо, потому что непонятно, это дата/время нажатия пользователем кнопки «оплатить», дата/время начала (или окончания ?) обработки в платёжной системе, или вообще дата импорта записи из внешнего лога. Пока правильно назовёшь, десять писем заказчику напишешь. Ну и бонусом — при таких упражнениях немного английский подтягивается :)Как же я был счастлив, когда мой МК-61 угодил в гарантийный ремонт третий раз, что по правилам Советского Союза позволяло получить деньги назад в полном объёме, добавить и купить 52
Интересен не столько достигнутый результат (все тесты зелёные), сколько способ решения задачи / кодирования. Если предложенный вариант решения мягко говоря странен — начинается дискуссия по возможным улучшениям и/или краевым случаям, что позволяет оценить опыт кандидата и количество косяков в production, которые от него можно ожидать.
Экономит просто ТОННЫ времени и нервных ресурсов на собеседованиях и неплохо отделяет тех, у кого код на кончиках пальцев, от заучивших ответы про устройство HashMap.
Все три изображения — разные.
Как узнать, какой конкретно способ пикселизации был использован при подготовке замазанной картинки, если учесть, что я не буду пикселизировать один и тот же номер 100500 раз?
Получается же два неизвестных, и очертания цифр, и алгоритм разбрасывания пикселей (ну, не алгоритм, но его seed)?
*осознанно выбравшие работу с компьютером обычно больше визуалы, чем всё остальное. Способность молча общаться в мессенджере с соседом по рабочему месту — она на неподготовленных аудиалов сильное впечатление производит, да…
На мой вкус реляционный подход универсальнее, а если ещё и все связи изначально проектировать как n:n, то сломать структуру новыми бизнес-требованиями практически нереально, как и добиться достойной производительности потом, так что каждый раз компромисс.
Помимо понятия «фактов» я использую ещё и «бизнес-сущности»: всё, что в требованиях (сценариях) существительное — бизнес-сущности, глаголы — факты. У фактов кстати всегда есть timestamp — действие происходит однократно и в конкретный момент времени. Бизнес-сущности зато должны иметь версии (была госпожа Иванова, стала — Петрова, и отчётность в прошедших периодах не должна уехать).