У меня нет ссылок на онлайн конвертеры. Но если тебе надо до пикселов сохранить оригинальный дизайн
то можно распечатать документ в картинки (там есть специальный виртуальный принтер) и дальше уже
их конвертить в pdf чем угодно. Тогда контент будет сохранен.
1) 5 Мегабайт это ниочем. Это какой-то учебный размер на котором можно учить школьников.
По идее все данные ложаться в страничный кеш и мы могли-бы исключить влияние дисков.
2) Со своего опыта работы с реляционками. Мне никогда не удавалось добиться гарантий
времени отклика для запросов которые содержали orderby, group, distinct. Эти ключевые
слова - враги стабилизаци времени отклика. Хотя можно стабилизировать план но трудно
стабилизировать сами данные. Вы никогда Не знаете как пойдет бизнес. Сколько завтра
зайдет строк за день. Сегодя 1000. Завтра 100 000 а через месяц зайдут миллионы. И время
отклика не линейно от объема. (Это бизнес думает что оно линейно) а мы то знаем
что там не то что полином а там бывают всякие эффекты. График - ломаная линия выходит.
Как работает этот disctinct on. Напомните пожалуйста. Выбирается самый последний imei по дате
с атрибутами?
SELECT distinct on (imei) * FROM locations WHERE imei IN (…) order by imei, dt desc
Может индекс здесь и помогает чорт его знает. Но я-бы "двигал" этот запрос в сторону key-value.
Взял IMEI. Получил все его последний снапшот. И все. И никаких исторических сканов. История
пускай будет но нам нужно нечто быстрое как редис.
3) Игры с ребилдом индекса я вообще никак не могу комментировать. Это не supportable система.
Нужно делать так чтобы индекс был стационарный и все нормально работало.
4) Вы используете IN (867232054978003, 867232054980835...). Это динамический запрос? Может
сделать с bind-variables и может лучше дернуть 20 раз по 1 EMAI с готовым запросом чем каждый
раз вызывать оптимизатор для 1 запроса с 20 EMAI. Это я не знаю ответа. Надо просто
поставить эксперимент.
Карлиндоу Мэрлифи, твой метод похож на Атаку на основе подобранного открытого текста.
Ищи зависимости. Действительно ли 1 символ (или байт) шифро-текста соотвествует тому
что показывает Чарльз.
Мне кажется у всего гибкого есть одна большая проблема. Механические повреждения. Каждый раз когда ты сгибаешь что-то сильно - то синтетика гнется а кристаллическая решетка металлов ломается. В ней появляются микро-трещины. Для кабелеей например который идут к наушникам появляется шорох и треск. Это как раз такие микро-трещины рвут электический контакт. Тоже самое скорее всего будет относиться к дисплеям типа E-Ink и прочее. Они обязаны в себе содержать электрические проводники.
Anonymous, хорошо. Для человека лучше брать распределение Гаусса. С мат-ожиданием
в точке 00:30 (пол первого ночи) и со средним квадратическим отклонением 97%
(три сигмы) где-то в один час. Раз уж ты так решил. Типа один сеанс работы человека
не превышает час. Обычно.
Карлиндоу Мэрлифи, сохрани его в файл (безо всяких попыток рассматривать его текстом).
И потом открой этот файл в Hex редакторе. Обычно по первым 4-8 байтам можно определить
тип содержимого. Например если первые байты равны
CA FE BA BE ....
То это бинарник Java-class файла. Если первые байты в ASCII коде равны %PNG то это
картинка. И так далее.
Но в общем это вопрос не ко мне а к тебе. Если ты решил поиграть в юного криптоаналитика
то будь готов работать с неизвестной двоичной информацией где всякие декодеры Лебедева
тебе никогда не помогут.
Надеюсь ты понимешь что в pom-based проекте Idea вообще не главная. Она - вторичная. Главное чтоб maven сценарии отработали. И еще главное - выбрать правильный архетип. Тебе точно нужен archetype-web?
Тут на самом деле только одна задача. Детектирование фона. Она интересна и ее можно пообсуждать.
Особенно если это мусорное ведро было снято не на хромокее а просто на какой-то рандомной подложке.
А остальное - это скрипты. Отцентрировать. Сделать 3 копии каскадом.
А во вторых непонятно что такое честная оценка модели? Ты привел две гистограммы и одна из них явно ошибочная. Потому что сильно большие различия. Такого быть не должно. Ты делал shuffle для всей совокупности?
У меня был Intel Atom 32х бит тоже 13 года. Я родителям покупал. Вместе с Window-XP.
Нормально там и youtube можно было смотерть.
Давайте будем честны. Ну не игровая эта платформа Debian. Тем более что если искать
дрова по состоянию на 2013 год то найдете то что как раз и было 10 лет назад в статусе
поддержки игр.
Есть известный доклад Алименкова на тему JMS и он там где-то рекомендует вместо пересылки по MQ толстых файлов - складывать их в любое key-value хранилище и передавать по MQ только линку на файл.
С моей точки зрения это правда имеет смысл но только в том случае если чтение файла - опционально. Тоесть потребитель может захотеть читать файл а может и нет.
то можно распечатать документ в картинки (там есть специальный виртуальный принтер) и дальше уже
их конвертить в pdf чем угодно. Тогда контент будет сохранен.