Я умею в LaTeX и люблю LaTeX, но чтобы сделать технологию более доступной коллегам, остановился на AsciiDoctor. Но LaTeX — технология более продвинутая, конечно, если есть смелость перелезть через входной барьер.
Да вот не секрет, что некоторые посетители конференций JUG Ru Group ворчат на то, что состав спикеров из года в год «один и тот же». Действительно, «верхушка айсберга» из состава спикеров всем известна и у всех на виду, но то же время «Угадай спикера» явственно демонстрирует, какое огромное количество народу уже успело выступить на джуговских конференциях, и какая есть огромная «подводная часть айсберга» из спикеров, которые менее заметны широкой публике, но чьи доклады не менее ценны.
Думаю, было бы интересно к следующему разу дополнить эту викторину информацией о докладах, с которыми тот или иной спикер выступал, чтобы викторина превратилась в познавательную программу для раскапывания докладов, которые можно было бы из архивов посмотреть.
Ой, со Стачки видеозапись без слайдов!
Лучше всего про статанализ я рассказал на Гейзенбаге: более полное раскрытие темы, лучше слайды, качественнее видеозапись.
Это надо сделать как и Delete, в основном на это плюются
DELETE ... WHERE ... одним запросом есть. С такими операциями другая проблема: на них невозможно реализовать клиентский триггер. Ведь мы же поддерживаем навешивание на таблицы клиентских триггеров — on(Pre|Post)(Update|Insert|Delete). При операциях по одной записи они работают, но при bulk-операциях — они не могут быть вызваны для каждой записи. Не всем пользователям это можно быстро объяснить.
Странно, почему вам не подошел старичек Hibernate
Потому что круг задач другой. Вообще я пришёл в Java из ERP-систем, история с Hybernate это про другое. Hybernate это ORM, прекрасно, но нам для быстрого пиления проектов типовых бизнес-систем важно иметь в одном флаконе: идемпотентные миграции, проектирование Database-First, тестирование, кроссбазданческость, срединный слой для аудита/распределения доступа.
для изменеия сущности — надо ее достать из базы (два раундтрипа select + update), вставка тоже за собой тянет (insert + select)
Есть такое дело! Но вставку можно оптимизировать, т. к. современный SQL позволяет делать INSERT....RETURNING одним запросом, и, сколько я помню, в Челесте insert с какой-то версии так и работает.
Поменять одно поле в 100-а записях — еще та попаболь
Ну в смысле, организовать из API вызов UPDATE foo set bar = '....' WHERE ....? Да, есть такое, но это можно заимплементить на уровне библиотеки тоже (это пока не сделали, но я знаю, как сделать).
В целом, Celesta достаточно производительна, сколько мне известно она работает на приложениях с нагрузкой порядка 200 rps на ноду. Претензии пользователей к производительности иногда бывают, мы их решаем. С другой стороны, у всего есть область применения. И для какой-то супер-производительной работы наверное Celesta не очень подходит, т. к. изначально создавалась под задачи быстрой разработки бэкенда для бизнес-приложений.
Тестировать базу моками тоже считаю дикостью и приверженец интеграционных тестов
В Java есть отличная штука — TestContainers (не знаю, делались ли попытки интегрировать её с .NET, мне кажется что это возможно) Во время запуска тестов она стартует в контейнерах настоящие базы данных на время теста и даёт к ним API, как если бы это были просто объекты в памяти. Не знаю, как бы мы разрабатывали Celesta без этой технологии, потому что благодаря прогону одного большого набора тестов на четырёх разных реальных базах данных мы гарантируем interoperability между базами. А те, кто пользуется CelestaTest, уже гоняют тесты бизнес-логики на быстром embedded H2, который не надо даже устанавливать, он подключается через зависимость.
Почему так сразу? Я не говорю, что автомиграции — это «серебряная пуля», но при осмысленном использовании — довольно удобный инструмент. При развитии бизнес-системы 9 из 10 изменений схемы — это добавление новых полей, расширение размеров существующих полей и обновление кода представлений, что является примитивной мишенью для автоматических миграций (а автомиграции умеют много больше). По сути, вы получаете ряд преимуществ разработки со schemaless-базой данных, не получая при этом их недостатков. Да, приходится думать о том, как развивать схему в таком ключе, чтобы автомиграция справилась без посторонней помощи. Но вам в любом случае приходится думать о чём-то подобном: даже если мы выполняем миграции при помощи специальных тулов, рекомендуется отвязывать обновление схемы от обновления приложения, так чтобы приложение было способно работать с разными версиями схемы, так что всегда приходится ограничивать себя.
Если вы отдаляете пользователя от SQL — библиотека в проигрыше
А если не отдаляю — то в проигрыше пользователь! Вернее так: в инженерии не бывает абсолютного выигрыша и абсолютного проигрыша, выигрыш в одном даётся проигрышем в другом. Если вы пишете на нативном SQL, вы выигрываете в доступных функциональных возможностях. Но вы проигрываете, сильнее привязываясь к базе данных и лишаясь возможности быстро её сменить (даже обновиться на новую версию той же БД), лишаясь возможности легко тестировать ваш код, лишаясь поддержки платформы в части централизованного контроля и аудита доступа / модификаций.
Какие-то аггрегации на клиентской части, для меня это вообще дико.
Вы про CelestaSQL materialized views? Кажется, в статье довольно чётко написано, что агрегации происходят именно что на стороне СУБД.
Концепция курсоров для меня не расскрыта, что они делают?
Это кодогенерируемые классы доступа к данным базы данных. Отвечают за чтение/запись данных, см. пример кода `@Service DocumentService` в статье.
Увы и ах. Доктор переносит всё только в HTML. decktape уже, управляя безголовым хромом, записывает снимки страниц в PDF.
Кстати, decktape способен таким образом конвертировать не только RevealJS слайды, но вообще слайды из кучи других презентационных фреймворков.
И ещё, кстати, ставить браузер не надо. Пакет puppeteer тащит автоматом безголовый хром за собой. Ну и в принципе если это всё происходит на CI, то хлопот не так много.
А вообще, кто уже делает слайды в техе, те молодцы и им тут делать нечего, я считаю ))))
Ну, тут всё зависит от задачи: где велосипед удобнее, где — Камаз. Я давно не пользовался Офисом365: скажите, параллельная работа (как в Google Docs) над слайдами возможна, или всё ещё надо делать Check Out / Check In?
А ничего, что статьи в гите лежат открытом в доступе до публикации?
Вдруг они заиндексируются поисковиком, а потом при публикации на хабр оно заблокируется по «антиплагиату»? Ведь по правилам хабра, размещать тут репосты нельзя, а если статья уже в открытом гитхаб-репозитории лежит, то она как бы тем самым уже в веб запощена. Или нет такой проблемы? хотелось бы кстати от НЛО услышать мнение на сей счёт)
Пожалуйста за статью ) Презентация выглядит или так (HTML) или так (PDF). Открываешь либо браузер, либо Acrobat Reader в полноэкранном режиме, кликер в руку и жгёшь :-)
Каких-то мультиэкранных фишечек (слайд-заметки, следующий слайд на другом экране), конечно, нет, ибо это всего лишь браузер или всего лишь Acrobat Reader.
Посмотрел Вашу статью. Да, мы явно сходимся по убеждениям насчёт презентаций) И внезапно узнал, что есть MarkConv для конвертации из гитхаба в хабр. В следующий раз попробую!!!
> А почему вы используете его, первый же более распространенный?
Наверное потому, что AsciiDoctor более распространён у нас в компании в принципе.
Для написания слайдов, наверное, нет большой разницы между Markdown и AsciiDoctor. А для написания документации (задача, под которую к нам «зашёл» AsciiDoctor) — разница есть в пользу последнего, например, структурирование таблиц в AsciiDoctor гораздо более продвинуто.
Мне кажется, выгрузка в powerpoint тут не возможна — по той же причине, что невозможна выгрузка в Word из LaTeX ) Но и зачем? не видел ещё ни одной конференции, которая бы отказалась принять слайды в формате pdf.
Да, можете прямо за основу взять проект github.com/inponomarev/csa-hb — клонируйте его со всеми потрохами, всё должно работать. Если чего не заработает — пишите, помогу, чем смогу)
Я умею в LaTeX и люблю LaTeX, но чтобы сделать технологию более доступной коллегам, остановился на AsciiDoctor. Но LaTeX — технология более продвинутая, конечно, если есть смелость перелезть через входной барьер.
Думаю, было бы интересно к следующему разу дополнить эту викторину информацией о докладах, с которыми тот или иной спикер выступал, чтобы викторина превратилась в познавательную программу для раскапывания докладов, которые можно было бы из архивов посмотреть.
Лучше всего про статанализ я рассказал на Гейзенбаге: более полное раскрытие темы, лучше слайды, качественнее видеозапись.
DELETE ... WHERE ...одним запросом есть. С такими операциями другая проблема: на них невозможно реализовать клиентский триггер. Ведь мы же поддерживаем навешивание на таблицы клиентских триггеров — on(Pre|Post)(Update|Insert|Delete). При операциях по одной записи они работают, но при bulk-операциях — они не могут быть вызваны для каждой записи. Не всем пользователям это можно быстро объяснить.Потому что круг задач другой. Вообще я пришёл в Java из ERP-систем, история с Hybernate это про другое. Hybernate это ORM, прекрасно, но нам для быстрого пиления проектов типовых бизнес-систем важно иметь в одном флаконе: идемпотентные миграции, проектирование Database-First, тестирование, кроссбазданческость, срединный слой для аудита/распределения доступа.
Вы посмотрите на 2bass, может, понравится)
Есть такое дело! Но вставку можно оптимизировать, т. к. современный SQL позволяет делать INSERT....RETURNING одним запросом, и, сколько я помню, в Челесте insert с какой-то версии так и работает.
Ну в смысле, организовать из API вызов
UPDATE foo set bar = '....' WHERE ....? Да, есть такое, но это можно заимплементить на уровне библиотеки тоже (это пока не сделали, но я знаю, как сделать).В целом, Celesta достаточно производительна, сколько мне известно она работает на приложениях с нагрузкой порядка 200 rps на ноду. Претензии пользователей к производительности иногда бывают, мы их решаем. С другой стороны, у всего есть область применения. И для какой-то супер-производительной работы наверное Celesta не очень подходит, т. к. изначально создавалась под задачи быстрой разработки бэкенда для бизнес-приложений.
В Java есть отличная штука — TestContainers (не знаю, делались ли попытки интегрировать её с .NET, мне кажется что это возможно) Во время запуска тестов она стартует в контейнерах настоящие базы данных на время теста и даёт к ним API, как если бы это были просто объекты в памяти. Не знаю, как бы мы разрабатывали Celesta без этой технологии, потому что благодаря прогону одного большого набора тестов на четырёх разных реальных базах данных мы гарантируем interoperability между базами. А те, кто пользуется CelestaTest, уже гоняют тесты бизнес-логики на быстром embedded H2, который не надо даже устанавливать, он подключается через зависимость.
Почему так сразу? Я не говорю, что автомиграции — это «серебряная пуля», но при осмысленном использовании — довольно удобный инструмент. При развитии бизнес-системы 9 из 10 изменений схемы — это добавление новых полей, расширение размеров существующих полей и обновление кода представлений, что является примитивной мишенью для автоматических миграций (а автомиграции умеют много больше). По сути, вы получаете ряд преимуществ разработки со schemaless-базой данных, не получая при этом их недостатков. Да, приходится думать о том, как развивать схему в таком ключе, чтобы автомиграция справилась без посторонней помощи. Но вам в любом случае приходится думать о чём-то подобном: даже если мы выполняем миграции при помощи специальных тулов, рекомендуется отвязывать обновление схемы от обновления приложения, так чтобы приложение было способно работать с разными версиями схемы, так что всегда приходится ограничивать себя.
А если не отдаляю — то в проигрыше пользователь! Вернее так: в инженерии не бывает абсолютного выигрыша и абсолютного проигрыша, выигрыш в одном даётся проигрышем в другом. Если вы пишете на нативном SQL, вы выигрываете в доступных функциональных возможностях. Но вы проигрываете, сильнее привязываясь к базе данных и лишаясь возможности быстро её сменить (даже обновиться на новую версию той же БД), лишаясь возможности легко тестировать ваш код, лишаясь поддержки платформы в части централизованного контроля и аудита доступа / модификаций.
Вы про CelestaSQL materialized views? Кажется, в статье довольно чётко написано, что агрегации происходят именно что на стороне СУБД.
Это кодогенерируемые классы доступа к данным базы данных. Отвечают за чтение/запись данных, см. пример кода `@Service DocumentService` в статье.
OMG, нет! Этот «свой пост против WISIWG» я писал Atom-е c Markdown-плагином. И выкладывал в закрытый репозиторий на гитхабе, чтобы коллеги поревьюили.
Кстати, decktape способен таким образом конвертировать не только RevealJS слайды, но вообще слайды из кучи других презентационных фреймворков.
И ещё, кстати, ставить браузер не надо. Пакет puppeteer тащит автоматом безголовый хром за собой. Ну и в принципе если это всё происходит на CI, то хлопот не так много.
А вообще, кто уже делает слайды в техе, те молодцы и им тут делать нечего, я считаю ))))
Лично мне удобнее наш вариант из-за
Ну и в принципе оно как-то спокойнее, что все исходники твоих документов — у тебя, а не неизвестно в каком формате в облаке.
Но, ещё раз повторюсь: всё зависит от задачи. Если у вас нет массовых слайдов с кодом, например, то гугл-докс — отличный выбор.
Вдруг они заиндексируются поисковиком, а потом при публикации на хабр оно заблокируется по «антиплагиату»? Ведь по правилам хабра, размещать тут репосты нельзя, а если статья уже в открытом гитхаб-репозитории лежит, то она как бы тем самым уже в веб запощена. Или нет такой проблемы? хотелось бы кстати от НЛО услышать мнение на сей счёт)
Каких-то мультиэкранных фишечек (слайд-заметки, следующий слайд на другом экране), конечно, нет, ибо это всего лишь браузер или всего лишь Acrobat Reader.
Наверное потому, что AsciiDoctor более распространён у нас в компании в принципе.
Для написания слайдов, наверное, нет большой разницы между Markdown и AsciiDoctor. А для написания документации (задача, под которую к нам «зашёл» AsciiDoctor) — разница есть в пользу последнего, например, структурирование таблиц в AsciiDoctor гораздо более продвинуто.
Да, можете прямо за основу взять проект github.com/inponomarev/csa-hb — клонируйте его со всеми потрохами, всё должно работать. Если чего не заработает — пишите, помогу, чем смогу)