Возможно повторюсь, но: 1. нормализация прежде всего: все списки в отдельной таблице и ссылки по id С ростом размера базы (кол-во таблиц, колонок, записей), приложение вам скажет спасибо. 2. если угораздило получить enum, незачем создавать доп. temp колонку: расширьте список на новое значение (+racing), замените в таблице значение колонки на новое (rasing->racing), удалите старый enum.
Надежда, вы молодец, что решились на статью. Сожалею, что суровые мужи наминусили вам в карму и за статью, и никто не удосужился объяснить причину.
Попробую угадать причину: - статья слишком базовая: масса ребят получают эту инфу и опыт при начальном знакомстве с XML/JSON. - кусочное описание: если уж повторять доку (лучше не надо), то вы описали один пример из массы, но остальное не упомянули. В доке структурировано и полностью. - смешивая XML и JSON хорошо бы описать разницу, хотя тоже, лучше не надо - инет забит этой инфой.
Резюмируя: Не огорчайтесь, наберитесь терпения, посидите на хабре чтоб понять аудиторию и характер статей. Со своей стороны поддержал статью и карму.
Думаю, часть решений может быть интересны. Все собираюсь поделиться, но не знаю с чего начать. За 30 лет в IT никогда не писал. :) Может посоветуете, с чего начать?
После похожих терзаний написал свою платформу data driven среды разработки. Начал в 2017, спустя 6 лет платформа вышла на плато надежной среды с необходимым функционалом backend и набором контролов frontend. Сейчас создаю ндежные веб-приложения, допольно сложные с т.з. архитектуры. Вывод - иногда легких путей нет.
Не спорю, для меня слегка навязчивы фразы, типа: "Без ИИ вы так и останетесь пещерным человеком, который с утра до ночи будет собирать ключевые слова и читать библиотеки данных самостоятельно." Да и скрытый мотив получить заказы довольно очевиден. Если ради заказов автор готов на негатив в свой адрес, его право.
Через последующее копирование HTML секций, передаче на интерпретацию compliance attorney (законнику) и созданию инструкций к выполнению. С PDF это ад. См. выше.
Возможно я делаю что-то не так, но таковы обстоятельства. Пример (моя боль) - законодатели публикуют законы в PDF и требуют их соблюдения. Для соблюдения нужно получить текст закона, понять и преобразовать в инструкции к выполнению. У меня таких PDF документов более 12 тыс. https://www.benefits.va.gov/WARMS/docs/admin26/pamphlet/pam26_7/ch04.pdf
Я, конечно, могу попытаться объяснить законодателям, что они ошибаются, но разумнее просто преобразовать PDF в HTML. И это ад.
Для нашей команды не столько в оркестраторе, сколько в диаграмме - прозрачность между бизнесом и разработчиками в описании процессов. Если в дальнейшем можно выполнять процессы на Camunda движке - гуд. Но основное - описание процессов.
Я должен заметить что с осадком прохожу мимо продукта PVS.
По работе нужен статический анализ кода (vendor management). 2+ лет назад обратился к PVS за trial или возможностью познакомиться с продуктом. Ответ был - "trial не дадим, ознакомиться не дадим, мы работаем только с большими клиентами". Ок, прохожу мимо.
Возможно повторюсь, но:
1. нормализация прежде всего: все списки в отдельной таблице и ссылки по id
С ростом размера базы (кол-во таблиц, колонок, записей), приложение вам скажет спасибо.
2. если угораздило получить enum, незачем создавать доп. temp колонку: расширьте список на новое значение (+racing), замените в таблице значение колонки на новое (rasing->racing), удалите старый enum.
Надежда, вы молодец, что решились на статью.
Сожалею, что суровые мужи наминусили вам в карму и за статью, и никто не удосужился объяснить причину.
Попробую угадать причину:
- статья слишком базовая: масса ребят получают эту инфу и опыт при начальном знакомстве с XML/JSON.
- кусочное описание: если уж повторять доку (лучше не надо), то вы описали один пример из массы, но остальное не упомянули. В доке структурировано и полностью.
- смешивая XML и JSON хорошо бы описать разницу, хотя тоже, лучше не надо - инет забит этой инфой.
Резюмируя:
Не огорчайтесь, наберитесь терпения, посидите на хабре чтоб понять аудиторию и характер статей.
Со своей стороны поддержал статью и карму.
Я бы оставил каждой задаче свой инструмент:
- бэкап шустро на локальный диск
- а затем копия бэкапа на удаленные носители.
Ведь, не у всех Ent. версия с компрессией бэкапа.
Некоторые сначала бэкапят, затем жмут, затем заливают на удаленные.
А зачем бесконечное перетягивание каната.
Может дать AI свободу использования и обязать авто-идентификацию по запросу?
Думаю, часть решений может быть интересны.
Все собираюсь поделиться, но не знаю с чего начать. За 30 лет в IT никогда не писал. :)
Может посоветуете, с чего начать?
После похожих терзаний написал свою платформу data driven среды разработки.
Начал в 2017, спустя 6 лет платформа вышла на плато надежной среды с необходимым функционалом backend и набором контролов frontend.
Сейчас создаю ндежные веб-приложения, допольно сложные с т.з. архитектуры.
Вывод - иногда легких путей нет.
Есть смысл упомянуть установку через docker/docker compose.
https://ghost.org/docs/install/docker/
https://hub.docker.com/_/ghost
В контексте статьи - на чужом железе (инфраструктуре).
Не спорю, для меня слегка навязчивы фразы, типа: "Без ИИ вы так и останетесь пещерным человеком, который с утра до ночи будет собирать ключевые слова и читать библиотеки данных самостоятельно."
Да и скрытый мотив получить заказы довольно очевиден.
Если ради заказов автор готов на негатив в свой адрес, его право.
Как SEO специалисту, вам должно быть не сложно заинтересовать аудиторию.
Ирония в негативной оценке вашей статьи читателями.
Все логично, и помидорство и философский пофигизм, но как-то скучно так работать.
Если меня проект не торкает, лучше сразу слиться.
В приведенном примере Moonbit скорее похож на Rust, особенно если CR/LF убрать перед aux вызовом. :)
И одного через край: 21 год с памперсами бегаем, и каждый год памперсы все ощутимее.
У знакомых аналогично.
Через последующее копирование HTML секций, передаче на интерпретацию compliance attorney (законнику) и созданию инструкций к выполнению.
С PDF это ад. См. выше.
Возможно я делаю что-то не так, но таковы обстоятельства.
Пример (моя боль) - законодатели публикуют законы в PDF и требуют их соблюдения.
Для соблюдения нужно получить текст закона, понять и преобразовать в инструкции к выполнению.
У меня таких PDF документов более 12 тыс.
https://www.benefits.va.gov/WARMS/docs/admin26/pamphlet/pam26_7/ch04.pdf
Я, конечно, могу попытаться объяснить законодателям, что они ошибаются, но разумнее просто преобразовать PDF в HTML. И это ад.
Вы создали раздел в статье, но забыли ответить на subj.
Для нашей команды не столько в оркестраторе, сколько в диаграмме - прозрачность между бизнесом и разработчиками в описании процессов.
Если в дальнейшем можно выполнять процессы на Camunda движке - гуд.
Но основное - описание процессов.
Сожалею, что не сохранил переписку.
Продукт полезный, но один ответ отбил желание.
Я должен заметить что с осадком прохожу мимо продукта PVS.
По работе нужен статический анализ кода (vendor management).
2+ лет назад обратился к PVS за trial или возможностью познакомиться с продуктом.
Ответ был - "trial не дадим, ознакомиться не дадим, мы работаем только с большими клиентами".
Ок, прохожу мимо.
Для работы с PDF контентом мне нужно переводить PDF в HTML.
Это ад.
Спас столько OCR с соблюдением разметки (FineReader в моем случае).
Для архивирования документов нужно переводить в PDF/A.
Это ад, и спасения нет.