А исходный код бенчмарков — коммерческая тайна? Было бы интересно:
прогнать на оборудовании, похожем на клиентское :)
сравнить с рукопашной упаковкой в byte[], поскольку конкретно у меня — есть всего с десяток классов, которые нужно держать в памяти и сбрасывать на диск, но суммарно может быть под миллиард экземпляров
проверить, не окажется ли выгоднее хранить в JVM бинарные представления для объектов с десериализацией при обращении «по требованию», нежели честные экземпляры классов
проверить на объектах размером в 20, 40 и 80К, поскольку, к сожалению, таковые вполне могут случиться
А как для 2) получить при выборке, например, поста за прошлый год — ник автора, который был именно на тот момент? (для случая, если ник обновлять можно)?
Тут статью писать надо… Вкратце чем мне WB нравится больше
• когда SQLWB/J уже был и давно – у JetBrains даже похожего ничего не было. И я к нему привык уже.
• подсветка PK / FK в местном аналоге IntelliSense, как и возможность настроить режимы вставки – т.е. прям в DropDown колонок таблицы можно выбрать несколько и вставить одним движением, и в зависимости от настроек – отсортировано по алфавиту или позиции в табличке
• JOIN completion по Alt-J
• реформат кода, какой нужен мне (настройки)
• подсветка в тексте выбранного вхождения – вроде как в FF «Highlight all», только по мере выделения, удобно смотреть, где ещё есть то же поле
• выполнение текущего выражения по <Ctrl-Enter>, всех, начиная с текущего, от начала и до текущего
• выполнение SQL в виде Prepared Statement (со значками “?”)
• конвертация SQL statement в Java snippet и обратно
• возможность задать значение переменной и использовать его ниже по скрипту
• превосходный менеджер подключений, и возможность иметь открытые вкладки (восстанавливать) в соответствии с выбранным рабочим пространством. Особенно удобно, если есть пяток проектов с разными СУБД, к которым нужно время от времени возвращаться)
• авто-генерация Insert и всего остального
• настройка визуального отображения NULL в результатах запросов (и не только NULL)
• автоматическое обновление результатов выполнения запроса
• regexp фильтрация для объектов БД
• копирование данных в буфер обмена в читаемом виде (и с выбором того, что и как копировать, включая моноширинный шрифт и соответствующее выравнивание)
• глобальный поиск текста в БД и удобное представление – где и что нашлось
• макросы
• возможность включения SQL файлов друг в друга
• импорт БД в Excel, правка и заливка обратно (сильно помогает на тестах)
• экспорт во что угодно
• удаление с учётом ограничений
• сравнение баз данных
• копирование данных из одной БД в другую
• удобная навигация по зависимостям объектов
• GUI и терминальный клиенты
• возможность запуска скриптов в batch режиме
• ReadOnly режим
По пункту 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 попросту не было. Но у меня специфический профиль нагрузки — ресурсов нужно много, но на короткое время (до одной минуты)
• когда SQLWB/J уже был и давно – у JetBrains даже похожего ничего не было. И я к нему привык уже.
• подсветка PK / FK в местном аналоге IntelliSense, как и возможность настроить режимы вставки – т.е. прям в DropDown колонок таблицы можно выбрать несколько и вставить одним движением, и в зависимости от настроек – отсортировано по алфавиту или позиции в табличке
• JOIN completion по Alt-J
• реформат кода, какой нужен мне (настройки)
• подсветка в тексте выбранного вхождения – вроде как в FF «Highlight all», только по мере выделения, удобно смотреть, где ещё есть то же поле
• выполнение текущего выражения по <Ctrl-Enter>, всех, начиная с текущего, от начала и до текущего
• выполнение SQL в виде Prepared Statement (со значками “?”)
• конвертация SQL statement в Java snippet и обратно
• возможность задать значение переменной и использовать его ниже по скрипту
• превосходный менеджер подключений, и возможность иметь открытые вкладки (восстанавливать) в соответствии с выбранным рабочим пространством. Особенно удобно, если есть пяток проектов с разными СУБД, к которым нужно время от времени возвращаться)
• авто-генерация Insert и всего остального
• настройка визуального отображения NULL в результатах запросов (и не только NULL)
• автоматическое обновление результатов выполнения запроса
• regexp фильтрация для объектов БД
• копирование данных в буфер обмена в читаемом виде (и с выбором того, что и как копировать, включая моноширинный шрифт и соответствующее выравнивание)
• глобальный поиск текста в БД и удобное представление – где и что нашлось
• макросы
• возможность включения SQL файлов друг в друга
• импорт БД в Excel, правка и заливка обратно (сильно помогает на тестах)
• экспорт во что угодно
• удаление с учётом ограничений
• сравнение баз данных
• копирование данных из одной БД в другую
• удобная навигация по зависимостям объектов
• GUI и терминальный клиенты
• возможность запуска скриптов в batch режиме
• ReadOnly режим
Если дизайнить такую штуку с нуля — то нужны «срезы» — коллекции непротиворечивых на некоторый момент времени записей, например если госпожа Иванова осуществляла платёж в прошлом году, а в этом — она уже госпожа Петрова, то в отчётах за прошлый год она должна отображаться как по-прежнему как Иванова.
В данном примере можно версионировать данные в той же таблице и выдать клиенту ещё один ключ. Что-то типа натурального — 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)?