• Jaxb (XJC) генерация классов из XML Schema (XSD) с описаниями классов и полей в виде аннотаций. XJC плагин
    +1
    Если честно, не совсем понял. На сколько я вижу обе под одинаковыми лицензиями. Или есть разница? Если вам это правда нужно, я могу попробовать адаптировать на использование других имплементаций. Тогда хотелось бы подробнее понять потребность. Но это, полагаю, уже лучше в issue.
  • Jaxb (XJC) генерация классов из XML Schema (XSD) с описаниями классов и полей в виде аннотаций. XJC плагин
    +1

    Так а нет проблемы!
    Хотя в демо-проекте и указано sourceCompatibility = 1.8 это лишь чтобы не поднимать требования напрасно.


    Т.к. явно указаны зависимости как API, таки имплементации, нет никаких проблем. Тесты нормально проходят под openjdk 11: image


    Ворнинги от groovy это лишь запуск тестов, они могут быть спокойно проигнорированы, подробнее в его багтрекере баг GROOVY-8339, то есть это никак не относится к плагину и Jaxb.

  • Публикация логов в Elasticsearch — жизнь без регулярных выражений и без logstash
    0
    Groovy сам по себе отлаживать не проблема совершенно. Интересует как отлаживать то что мы внедрили таким изощрённым способом. Даже если подключиться дебаггером, там будет evaluate (execute) т.к. это фактически строка. Есть ли способ остановиться брэкпоинтом в коде?

    Суть в том что если я внедряю в приложение логгинг подобным образом, вероятно у меня нет контроля над его исходным кодом (купленное проприетарное). То есть я не могу всё запустить в любимой IDE.

    Второй вопрос здесь же — по примеру сделать скрипт легко, а если я пишу свой скрипт разбора и логгирование, а приложение стартует пару минут — поседеть можно отлаживать скрипт каждый раз перезапуская полностью. Есть ли возможность скрипт менять в рантайме?
  • Публикация логов в Elasticsearch — жизнь без регулярных выражений и без logstash
    +1
    Как вы отлаживаете код, написанный в XML для aspectj-scripting?
  • Обзор инструментария для нагрузочного и перформанс-тестирования
    +1
    Да, конечно. JMeter многое умеет, например тот же JDBC (БД). SMTP, LDAP, FTP, MOM, JMS и многое другое. Можно писать свои протоколы плагинами.
  • Индексы в PostgreSQL — 4
    0
    Спасибо большое за интересные статьи и что продолжаете, как обещали.
    Часть теории конечно вполне тривиальна, но здорово что всё вместе и последовательно.

    Я хотел спросить на счёт порядка определения своего класса операторов. Скажем в вашем примере, сначала для комплексных чисел используется дефолтный метод. Что если мы сначала создадим btree индекс по этому полю, а потом уже определим класс операторов:
    create operator class complex_ops

    Достаточно ли postgres «умный» чтобы не стать использовать для индексов, создававшихся с другими операторами вновь созданный?

    И если мы хотим чтобы старый индекс стал использовать новый класс операторов, его обязательно пересоздавать? Или есть другие возможности перестроения (REINDEX)?
  • Разбор задач викторины Postgres Pro на PGDay'17
    0
    Не могли бы вы пожалуйста пояснить подробнее про хранение NULL и что нужно было увидеть с помощью Pageinspect?

    Я пытаюсь разобрать приведённый вами пример:

    CREATE TABLE t1(x int, y int);
    CREATE TABLE t2(x int not null, y int not null);
    INSERT INTO t1 VALUES (1, 1)
    SELECT * FROM heap_page_items(get_raw_page('t1', 0)) limit 1;
    

    Вывод:

     lp     lp_off     lp_flags     lp_len     t_xmin     t_xmax     t_field3     t_ctid     t_infomask2     t_infomask     t_hoff     t_bits     t_oid     t_data           
     -----  ---------  -----------  ---------  ---------  ---------  -----------  ---------  --------------  -------------  ---------  ---------  --------  ---------------- 
     1      8160       1            32         4302       0          0            (0,1)      2               2048           24         (null)     (null)    0100000001000000
    


    INSERT INTO t2 VALUES (1, 1)
    SELECT * FROM heap_page_items(get_raw_page('t2', 0)) limit 1;
    


    Вывод:
     lp     lp_off     lp_flags     lp_len     t_xmin     t_xmax     t_field3     t_ctid     t_infomask2     t_infomask     t_hoff     t_bits     t_oid     t_data           
     -----  ---------  -----------  ---------  ---------  ---------  -----------  ---------  --------------  -------------  ---------  ---------  --------  ---------------- 
     1      8160       1            32         4303       0          0            (0,1)      2               2048           24         (null)     (null)    0100000001000000 
    


    Абсолютно одинаковые.

    Пробую вставит null значения:
    INSERT INTO t1 VALUES (null, null)
    SELECT * FROM heap_page_items(get_raw_page('t1', 0)) limit 1;
    


     lp     lp_off     lp_flags     lp_len     t_xmin     t_xmax     t_field3     t_ctid     t_infomask2     t_infomask     t_hoff     t_bits     t_oid     t_data           
     -----  ---------  -----------  ---------  ---------  ---------  -----------  ---------  --------------  -------------  ---------  ---------  --------  ---------------- 
     1      8160       1            32         4302       0          0            (0,1)      2               2048           24         (null)     (null)    0100000001000000
    


    И всё равно всё то же самое.

    На каком основании сделать какая из них занимает меньше места?

    P.S. Форматированный вывод, который выроятно будет удобнее смотреть: paste.fedoraproject.org/paste/z50hMUVlKZ4Idh0mgqTEBQ
  • Разбор задач викторины Postgres Pro на PGDay'17
    0
    На postgres 9.6, как минимум, команда просмотра заголовка для таблицы выдаёт ошибку:
    SELECT * FROM heap_page_items(get_raw_page('t1', 0)) limit 1;

    ERROR: block number 0 is out of range for relation «t1»

    Вероятно стоит добавить что для этого требуется в таблицу вставить хотя бы один кортеж.
  • TOP'ай сюда
    0
    Ещё darkstat для сети
  • Краткий обзор Dojo Framework Enhanced Grid или как быстро и просто организовать вывод данных в виде таблиц
    0
    Видео недоступно. Это можно поправить?
  • В поисках идеального мониторинга
    0
    Ссылка в статье https://habrahabr.ru/company/tcsbank/blog/248853/ не корректная, видимо имелась ввиду https://habrahabr.ru/company/tinkoff/blog/248853/.
  • Ускоряем восстановление бэкапов в PostgreSQL
    0
    В особенности если это используется для тестирования, рекомендую просто подготовить Docker образ, и откатываться к любой закоммиченной точке в течении единичных секунд.
  • Docker контейнер с данными на Postgres для интеграционного тестирования и лёгким расширением
    0
    Задача, в том числе, максимально упростить вход разработчика в приложение, чтобы все инструкции по сборке и запуску приложения, от многодневных попыток, как это было еще с год назад, сводились к:

    git clone …
    ./gradlew dockerRun
    


    При этом бы приложение бы сразу запустилось, но не с игрушечной базой (как обычно делают вроде in-memory H2 для тестов с парой записей), а с базой, на которой, в том числе гоняются интеграционные и перфоманс тесты на CI и чтобы воспроизвести можно было 99.9% проблем из продакшена.

    Более того, я для простоты этот шаг убрал, чтобы не засорять описание, но имея стабильную master ветку, я ещё прогоняю все имеющиеся там миграции на БД (c помощью flyway) в момент билда — так, чтобы эта база запускалась бы моментально.
  • Сравнение аналитических in-memory баз данных
    0
    Будет здорово, если напишете развёрнутую статью в продолжение сравнения.
  • Полная автоматизация среды разработки с помощью docker-compose
    0
    Я так понимаю это просто повтор перевода https://habrahabr.ru/post/322440/?
  • Сравнение аналитических in-memory баз данных
    0
    У CitusDB нет более-менее эффективных произвольных JOIN'ов. Хотят видеть только JOIN по одинаковым распределённым ключам.

    Простите, что значит нет?
    Ещё с версии 4.х эквиджойны есть для любых таблиц:
    CitusDB supports equi-JOINs between any number of tables irrespective of their size and distribution method. The query planner chooses the optimal join method and join order based on the statistics gathered from the distributed tables. It evaluates several possible join orders and creates a join plan which requires minimum data to be transferred across network.

    Или вы имеете ввиду что работают они медленно и оптимизатор плохо справляется с локальностью данных?
  • Сравнение аналитических in-memory баз данных
    0
    Да, прошу прощения, но всё-таки очень хочется спросить ещё про In-Memory-Data-Grid, или In-Memory-SQL-Grid. Вы их рассматривали? В частности, например проект apache ignite предоставляет не только программный интерфейс в стиле Data Grid computing, но обещают прямо ANSI SQL-99 совместимость и стандартный JDBC доступ.
    Очень интересно ваше мнение по этому поводу.
  • Индексы в PostgreSQL — 1
    0
    Даже наличие опциональной поддержки inmemory как отменяет использование индексов?? Причём как в памяти, так и для оставшейся на диске части? Некоторые базы, вроде Exasol, вообще делают их автоматически в памяти, как рассказывал tinkoff, большинству же остальных так или иначе они всё равно нужны от DBA.
  • Глубокое обучение для новичков: распознаем рукописные цифры
    0
    Обученная модель в переменной model.
    Если вам прислали картинку которую вы хотите классифицировать, в общем случае вам нужно привести её в тот же вид (сначала размерность и цветность 28*28 grayscale, затем в одномерный вектор, как в начале статьи). Затем, в простейшем случае вы можете просто вызвать метод predict.

    Для сохранения модели, чтобы не тратить лишний раз время на тренировку, имеются различные методы записи на диск и экспорта в JSON или YAML — https://keras.io/models/about-keras-models/
  • Индексы в PostgreSQL — 1
    0
    Базовые индексы и механизмы у вас очень хорошо рассказаны в DBA2 курсе. А вот про «новые», Бартунов и Коротков постоянно рассказывают на конференциях, прямо как затравки. Каждый раз думаешь «вау, как круто», но так чтобы понять, а главное приспособить в реальной жизни что-то кроме Btree или Gin даже и не понятно с какой стороны смотреть толком…
  • Сравнение аналитических in-memory баз данных
    0
    Спасибо, статья действительно очень интересная.

    А почему не тестировались CitusDB (в отличие от GreenPlum ставится поверх Postgres, то есть работает на свежих версиях, а не 8.4) и monetdb?
  • Индексы в PostgreSQL — 1
    0
    Спасибо за статью.

    А когда ждать продолжение про RUM и VODKA?
  • Уличная магия в скриптах или что связывает Groovy, Ivy и Maven?
    0
    3 Мб оверхеда, да ещё и выковырянных из другого проекта. Вы же, как я понял, всё равно используете maven-указаение зависимостей и его артефакты. Ivy (https://mvnrepository.com/artifact/org.apache.ivy/ivy/2.4.0) занимает всего 900Кб и готов к использованию. В том числе как зависимость проекта, в котором вы собираете единый артефакт.

    На сколько я понимаю, основной смысл использование в скриптах, эта же тема развивается в комментариях, что сложных случаев каких-то зависимостей не нужно. Так зачем тогда на столько усложнять и увеличивать объём артефакта более чем в 3 раза?
  • Уличная магия в скриптах или что связывает Groovy, Ivy и Maven?
    0
    Можете пожалуйста готовый пример предложенного решения привести, чтобы запустить то же самое с «чистым» groovy?
  • Версионирование артефактов сборки в Gradle используя git имена тегов, бранчей и коммитов
    0
    Спасибо, исправил
  • Версионирование артефактов сборки в Gradle используя git имена тегов, бранчей и коммитов
    0
    Конечно можно. И парсить вывод. А если бинарного git нет в PATH ещё поставить его или подтянуть зависимость. А потом прикритить логику парсинга имен бранчей, потом логику формирования версий. А потом добавить логику обработки dirty рабочей копии, а потом ввести чтение переменных окружения… А потом понять что этого кода в скрипте билда стало больше чем остального описания билда и вынести это в плагин градл. Ну или взять один из имеющихся.
  • Версионирование артефактов сборки в Gradle используя git имена тегов, бранчей и коммитов
    0
    Это не функции Jenkins никак, если у вас проект в другом месте. В лучшем случае, может быть плагин интеграции, который сможет решить часть проблем. Но в общем gitlab не так много хуков предлагает, чтобы сделать это так же удобным как с его CI. Если вам не предоставляется возможности рядом с коммитом отобразить статус билда из другой системы (исключительно для примера, с другими возможностями также) — то вы это из плагина не сделаете.
  • Automount afuse
    0
    Я внёс изменения в пример. Не считаю это критичным, но в общем вполне согласен что ваш вариант лучше.
  • Automount afuse
    0
    Ну на самом деле для Fedora Server давно обсуждается как минимум цикл в 6 релизов: https://fedoraproject.org/wiki/Server/Proposals/Server_Lifecycle и подобные разговоры у нас в рассылке всплывали с регулярным постоянством в прошлом. Везде есть свои плюсы и минусы и у всего есть своя цена.

    Однако полагаю это всё же уже оффтопик.
  • Automount afuse
    0
    Разумеется вы можете придумать дальше нужную вам схему, в том числе порт. Кстати в Linux нет проблемы использовать: в имени директории, соответственно вполне можно создавать и традиционный путь вроде root@server.xxx:2224. У меня ж пример, всё что может понадобится не предусмотреть, хотя замечание хорошее.

    А вот на пользователя директории для коннекта никто не ориентируется. По умолчанию берётся тот, кто прописан для хоста в ~/.ssh/config. А если нужно указать другого, то для этого случая я и описал в статье что можно использовать нотацию user@host.
  • Версионирование артефактов сборки в Gradle используя git имена тегов, бранчей и коммитов
    0
    На самом деле, с Jenkins 2.0, когда они у себя также внедрили концепцию пайплайнов (pipline), разрыв значительно уменьшился. На митапе в Яндексе в прошлом году, они очень активно рассказывали как это всем поможет. Теперь не обязательно все билды «накликивать мышкой». Раньше для меня это было просто бедой, хотя и можно было экспортировать конфигурацию в XML. Теперь можно нормально версионировать скажем с помощью того же GIT.
    Однако остаётся проблема что всё-таки это отдельно от кода, от проекта. Версионируется отдельно, релиз-циклы как-то надо согласовывать. Тестировать отдельно…

    Ну и опять же, gitlab и gitlab-ci имеют из коробки гораздо более плотную интеграцию. Тут вам прогресс билда, и просмотр лога, и артефакты сборки прямо на странице билда, и авторизация общая, тут же можно указать сколько хранить артефакты, чтобы место освободить, тут же и docker-registry свой предлагают (я правда не использую его, сторонним пользуемся. И к слову тут нет автоочистки образов, хотя обещают добавить по моей просьбе). Ну и много других приятных мелочей.
  • Automount afuse
    0
    Простите, не совсем понимаю что вы имели ввиду. Что лучше не монтировать автоматически потому что можно удалить не тот файл? Ну так и если по SSH если будете заходить — не исключена ошибка ввода не того имени хоста. А чем отличается уровень возможности ошибки при ввода хоста в строке подключения от строки файлового пути — не очень понятно.
  • Версионирование артефактов сборки в Gradle используя git имена тегов, бранчей и коммитов
    0
    varnav, честно говоря, тут в общем всё просто, но зависит от ваших специфических нужд. На хабре уже есть неплохие стати на эту тему, например Введение в GitLab CI.
    По моим впечатлениям, он просто потрясающий. А открытость его разработки заслуживает особого восхищения. Они очень быстро обычно реагируют на баги. Помню ездил на highload++ в этом году, просто к слову пожаловался в беседе что они не правят багу с раннером для приватного репозитория docker что я им ставил… Так они не только исправили в тчении ближайших пару дней, так ещё и написали мне об этом дополнительно.

    Однако мне для полного счастья всё же не хватает некоторых вещей. Например для для того чтобы удобнее работать с контейнерами вроде: #25047, #25000.

    Но это ж больше хотелки, понятно что они больше сосредоточены на энтерпрайзных вещах вроде kubernetes, автоскалирования в облаке…
    А с точки зрения начать использовать — действительно просто по туториалу сконфигурить.
    Если у вас есть какие-то конкретные вопросы, то буду рад помочь, а так чтобы на отдельную статью, просто и не знаю что писать…
  • Automount afuse
    +1
    Полагаю вы не вполне поняли для чего afuse и autofs.

    x-systemd.automount не делает ничего более, как формирует automount unit for filesystem.
    Это удобно для сетевых систем, прописанных в /etc/fstab, чтобы они сразу не монтировались, а только по мере доступа к ним.

    Но т.к. юнит формируется по строке из fstab, то вы должны будете прописать все ваши сотни серверов для возможности монтирования по sshfs! Это именно то, от чего мы хотели избавиться!

    Мы так или иначе прописываем одну строку для моунтпоинта автомонтирования (/mnt/remote в моём примере). Будет ли она работать с x-systemd.automount я не знаю, но смысл всё равно отсутствует — в сущности это ж псевдо система, и пока вы не обратититесь внутрь этой системы, да ещё и к директории с нужным именем, ничего удалённого здесь всё равно не монтируется.
  • Automount afuse
    0
    Ну тут действительно проблема в том что нужно отслеживать всё дерево, включая удалённые файловые системы. А с ними вообще будет беда по скорости.

    И наверное теоретически FUSE можно было бы реализовать, но как вы сами заметили, скорость будет вряд ли приемлемой.

    Для архивов в общем вполне не плохо справляются все среды, чтобы зайти в них, и Gnome и KDE. В консоли тот же Midnight прекрасно «заходит» в архивы.
    Да, это не вполне удобно, потому что решения разные, симлинки не сделаешь, нет интероперабельности… Но с другой стороны, в большинстве случаев такой доступ всё равно очень медленный и нужен лишь чтобы «быстренько взглянуть что там», ну или поглядеть пару небольших файлов вроде README. А с этим указанные средства вполне справляются. Если вам понадобилось содержимое архива полностью, то полное его извлечение будет на порядок быстрее с помощью последовательного чтения и использования родного архиватора.
  • Automount afuse
    0
    Autofs тоже хорошая штука, согласен. Я его тоже использовал.
    Из важных плюсов — умеет отмонтировать файловые системы по настроенному таймауту и это удобно.
    Из серьёзных минусов:
    • значительно сложнее в настройке. Работает на древнем automount
    • при этом далеко не тривиален в дебаге, если что-то не так работает как хочется. Вот например я ставил пару багов на него: bz#961312, bz#961299.
    • Последнюю закрыли не разбираясь, по таймауту :( Если посмотреть в багзилле кроме моих, то их тоже очень не мало, что тоже немного отталкивает.

  • Automount afuse
    0
    Нет, по умолчанию ssh достаточно! Есть конечно возможность его ограничить отдельным списком команд дополнительно, но мы сейчас не будем рассматривать эти случаи. А вообще работает даже с shared хостингами на ура.
  • Automount afuse
    0
    Кстати, вместо использования sshfs вы вполне также можете использовать автомаонтирование nfs с помощью afuse! Потребуются незначительные модификации скрипта-хелпера. Однако nfs требует экспорта файловых систем, вся прелесть sshfs в том что вы можете так монтировать любой хост, на который у вас есть ssh доступ, без каких-то дополнительных подготовок на нём.
  • Automount afuse
    0
    Если хост недоступен, разумеется вы не сможете читать его. Но, во-первых, это просто sshfs, поведение будет в точности такое же. К afuse это не имеет отношения.

    Но если вернуться к вопросу как оно будет себя вести, то при переходе в эту директорию команда просто подвиснет. В моём примере используется опция "-o reconnect", соответственно sshfs будет постоянно пытаться переконнектиться, и сделает это как только хост станет доступен, то есть вы увидите просто задержку. Если же хост стал полностью недоступен, вы можете просто убить соответствующий sshs процесс с помощью kill. Ну и отмонтировать конкретную директорию: fusermount -u somehost
  • Automount afuse
    0
    Да можно и так. И ещё десятком способов…