Написание потокового парсера для какого-нибудь простого регулярного формата вполне валидная бизнесовая задача. Мне в своё время пришлось писать парсер для .po, например. Потому что нормальной легковесной либы не нашлось :) Или вот быстрый glob pattern парсер в текущем проекте оказался нужен, а сторонние все или слишком перегружены, или не умеют в полный синтаксис. Взял и написал.
Потренироваться на json, чтобы не пугали потом такие задачи, весьма неплохо.
Считаю, что собрать себе минимальный app container из стандартных запчастей с капелькой рефлекшена — это вполне валидная задача для случаев, когда тянуть спринг с его монстрообразными зависимостями нецелесообразно. Я и сам два раза писал такой маленький DI с нуля на голой жабе для рестоподобных сервисов, и ещё один раз допиливал чужой, — которые потом вполне успешно использовались в проде по нескольку лет.
Писать собственный шаблонизатор — чуть более спорная затея. Для этого на свете есть достаточно удобные и при этом тонкие либы. А для HTTP сервиса всё-таки стоит брать jetty, встроенный совсем уж убогий.
Батенька, у меня ещё в универе был курс нейронок. Который я закончил в 2003, на минуточку. И соответствующая курсовая тоже была. Так что я знаю, о чём говорю, на техническом уровне, в отличие от вас, рассуждающего какими-то общими словами.
Вообще, теория по ним вся была готова ещё в 80-е, и с тех пор сильно ничего не поменялось. Современные сети, конечно, намного больше, чем те, которые использовались для задач OCR в конце прошлого века, но как принципиально были ограниченным инструментом, так им и остались. В последние годы доступных вычислительных мощностей стало некуда девать, вот они и полезли из всех щелей.
А с людьми нейронки сравнивать вообще некорректно. Думать они как не умели, так и вряд ли смогут в ближайшие лет этак 50.
Вот и выросло поколение, которое не понимает, как работают современные «ИИ» на глубоких сетях :(
Во-первых, они по определению не могут создать ничего нового. И это факт, как бы вам ни казалось обратного. Почитайте теорию, что ли. Понимаю, что это очень много скучной и нудной писанины, но один раз можно время потратить, чтобы избавиться от заблуждений.
Во-вторых, засудить их не получится, показав, из чего именно получается компиляция. Потому что внутренние слои глубоких сетей работают как «чёрный ящик» с обратной связью, эффективно перемешивая входные сигналы с внутренним состоянием. У Гугла были работы по доказательным и повторяемым генерациям, но это чертовски дорого, и работает только на конкретном сете. Для обученной на произвольном наборе сетки проследить за генерацией в общем случае нельзя.
В-третьих, эволюция — это отбор наиболее эффективных вариантов случайных мутаций. Но я что-то не припоминаю, чтобы в процесс обучения современных промышленных сеток намеренно вносились искажения, и производился такой отбор. В самих генерациях этого тоже не делается.
К счастью, до тех пор, пока ИИ не способен придумать ничего нового с нуля (а не бесконечно выдавать ремикс того, на чём обучен), кожаным артистам ничего особенно не грозит. Ну, может быть, помимо тех, кто промышляет исключительно ремиксами.
А вот продюсерам и лейблам действительно пора уже напрячься.
Когда ты молод, и за плечами у тебя ничего, кроме рюкзачка с макбуком, а вся жизнь ещё впереди, то из котла намнооооооого проще выпрыгнуть, чем когда тебе за сорок, семья, трудноликвидируемое имущество, болячки, и ещё престарелые родители на иждивении.
Квакают-то единицы, большинство пытается выживать за невозможностью свалить.
Вы бы хоть между отдельными вопросами перевод строки ставили. Но я попробую расчленить и ответить. Не обессудьте, если неправильно их пойму.
Да, у нас есть набор хорошо упакованных и параметризованных алгоритмов, которые могут работать с похожими данными из разных источников.
Мы не занимаемся аналитикой над данными в сыром виде, и вообще я много раз подчёркиваю, что задачи повторить SparkSQL изначально не стояло (да и зачем такой ерундой заниматься?). Аналитика вся производится над данными, которые уже подготовлены, и в инструменты аналитиков я лично не лезу. Что у них там кроме pandas, не моё дело.
У нас нет отдельного слоя абстракции, который надо было бы изучать. Есть простая система типов, и это всё, что есть user-facing.
Нечего оптимизировать. В отличие от аналитических БД с декларативными SQL, где ты пишешь ЧТО хочешь получить, и оптимизатор сам тебе выбирает КАК (и где чаще всего зарыта собака), в ETL процессах ты непосредственно пишешь КАК тебе надо получить ЧТО-то, а оптимизатора у тебя нет от слова совсем.
Примеры вряд ли будут показательными, они очень уж сильно завязаны на конкретные бизнес-кейсы нашего проекта. Большая часть из них вообще под NDA. Мы же продаём услугу по аналитике тем, кто не умеет ею заниматься...
Если останутся ещё вопросы, я на них с удовольствием отвечу.
(БТВ, если вам всего хватает в имеющихся инструментах, вам остаётся только позавидовать. В реальной жизни кейсы намного разнообразнее, чем вам кажется. В качестве подсказки — в бизнесе деньги решают всё. Иногда весьма неочевидный путь ОЧЕНЬ сильно дешевле.)
Я такое делал. Более того, вот в этой статье https://habr.com/ru/articles/330366/ заглавный скриншот сгенерирован именно таким баш-скриптом, дёрнутым через CGI. Точнее, даже несколькими скриптами.
Написал за два дня, и оно какое-то время держалось в проде, но с учётом того, что на каждый вызов дёргалось овердофига процессов, с ростом обрабатываемого объёма начало нещадно тормозить. Переписал в итоге на PHP.
В качестве упражнения для разминки мозгов делать подобное весьма неплохо.
Написание потокового парсера для какого-нибудь простого регулярного формата вполне валидная бизнесовая задача. Мне в своё время пришлось писать парсер для .po, например. Потому что нормальной легковесной либы не нашлось :) Или вот быстрый glob pattern парсер в текущем проекте оказался нужен, а сторонние все или слишком перегружены, или не умеют в полный синтаксис. Взял и написал.
Потренироваться на json, чтобы не пугали потом такие задачи, весьма неплохо.
Сходил посмотрел, сфоткал даже (жаль тут маркдаун в комментах не включён, а то выложил бы).
Системника под столом и в самом деле нет.
Нормально.
Считаю, что собрать себе минимальный app container из стандартных запчастей с капелькой рефлекшена — это вполне валидная задача для случаев, когда тянуть спринг с его монстрообразными зависимостями нецелесообразно. Я и сам два раза писал такой маленький DI с нуля на голой жабе для рестоподобных сервисов, и ещё один раз допиливал чужой, — которые потом вполне успешно использовались в проде по нескольку лет.
Писать собственный шаблонизатор — чуть более спорная затея. Для этого на свете есть достаточно удобные и при этом тонкие либы. А для HTTP сервиса всё-таки стоит брать jetty, встроенный совсем уж убогий.
Но в целом вполне зачёт. Полезное упражнение.
Батенька, у меня ещё в универе был курс нейронок. Который я закончил в 2003, на минуточку. И соответствующая курсовая тоже была. Так что я знаю, о чём говорю, на техническом уровне, в отличие от вас, рассуждающего какими-то общими словами.
Вообще, теория по ним вся была готова ещё в 80-е, и с тех пор сильно ничего не поменялось. Современные сети, конечно, намного больше, чем те, которые использовались для задач OCR в конце прошлого века, но как принципиально были ограниченным инструментом, так им и остались. В последние годы доступных вычислительных мощностей стало некуда девать, вот они и полезли из всех щелей.
А с людьми нейронки сравнивать вообще некорректно. Думать они как не умели, так и вряд ли смогут в ближайшие лет этак 50.
Вот и выросло поколение, которое не понимает, как работают современные «ИИ» на глубоких сетях :(
Во-первых, они по определению не могут создать ничего нового. И это факт, как бы вам ни казалось обратного. Почитайте теорию, что ли. Понимаю, что это очень много скучной и нудной писанины, но один раз можно время потратить, чтобы избавиться от заблуждений.
Во-вторых, засудить их не получится, показав, из чего именно получается компиляция. Потому что внутренние слои глубоких сетей работают как «чёрный ящик» с обратной связью, эффективно перемешивая входные сигналы с внутренним состоянием. У Гугла были работы по доказательным и повторяемым генерациям, но это чертовски дорого, и работает только на конкретном сете. Для обученной на произвольном наборе сетки проследить за генерацией в общем случае нельзя.
В-третьих, эволюция — это отбор наиболее эффективных вариантов случайных мутаций. Но я что-то не припоминаю, чтобы в процесс обучения современных промышленных сеток намеренно вносились искажения, и производился такой отбор. В самих генерациях этого тоже не делается.
К счастью, до тех пор, пока ИИ не способен придумать ничего нового с нуля (а не бесконечно выдавать ремикс того, на чём обучен), кожаным артистам ничего особенно не грозит. Ну, может быть, помимо тех, кто промышляет исключительно ремиксами.
А вот продюсерам и лейблам действительно пора уже напрячься.
Вы не злорадствуете, что делает вам честь. В отличие от комментатора выше.
Когда ты молод, и за плечами у тебя ничего, кроме рюкзачка с макбуком, а вся жизнь ещё впереди, то из котла намнооооооого проще выпрыгнуть, чем когда тебе за сорок, семья, трудноликвидируемое имущество, болячки, и ещё престарелые родители на иждивении.
Квакают-то единицы, большинство пытается выживать за невозможностью свалить.
Поскорее уж бы ядерную войну начали тогда, что ли. Отмучаемся хотя бы по-быстрому, варка лягушки надоела уже. Что тянут, непонятно.
Сколько %% интернета отвалится, если заблочить AWS по подсетям?
Что ж, видимо, скоро узнаем.
Ещё хуже, чем встроенный кейлоггер.
Автор мыслит в другой парадигме.
Process vs. state.
Schema-less vs. INFORMATION_SCHEMA.
Flow control vs. DAG.
Ну и так далее. Достаточно отличий в идеологии. Но SQL тем не менее остаётся SQL, так как он тупо удобен для конечных пользователей.
Очень сложно парсить ваши комментарии :\
Вы бы хоть между отдельными вопросами перевод строки ставили. Но я попробую расчленить и ответить. Не обессудьте, если неправильно их пойму.
Да, у нас есть набор хорошо упакованных и параметризованных алгоритмов, которые могут работать с похожими данными из разных источников.
Мы не занимаемся аналитикой над данными в сыром виде, и вообще я много раз подчёркиваю, что задачи повторить SparkSQL изначально не стояло (да и зачем такой ерундой заниматься?). Аналитика вся производится над данными, которые уже подготовлены, и в инструменты аналитиков я лично не лезу. Что у них там кроме pandas, не моё дело.
У нас нет отдельного слоя абстракции, который надо было бы изучать. Есть простая система типов, и это всё, что есть user-facing.
Нечего оптимизировать. В отличие от аналитических БД с декларативными SQL, где ты пишешь ЧТО хочешь получить, и оптимизатор сам тебе выбирает КАК (и где чаще всего зарыта собака), в ETL процессах ты непосредственно пишешь КАК тебе надо получить ЧТО-то, а оптимизатора у тебя нет от слова совсем.
Примеры вряд ли будут показательными, они очень уж сильно завязаны на конкретные бизнес-кейсы нашего проекта. Большая часть из них вообще под NDA. Мы же продаём услугу по аналитике тем, кто не умеет ею заниматься...
При том, что инструмент, построенный вокруг интерпретатора данного диалекта, используется для ETL.
И много ли вы знаете кастомных парсеров, которые, например, геометрические объекты и произвольный JSON поддерживают прямо в базовом синтаксисе?
Впрочем, предыдущие статьи вы, очевидно, даже не пытались читать.
Прочитайте предыдущую статью с FAQ https://habr.com/ru/articles/762862/
Если останутся ещё вопросы, я на них с удовольствием отвечу.
(БТВ, если вам всего хватает в имеющихся инструментах, вам остаётся только позавидовать. В реальной жизни кейсы намного разнообразнее, чем вам кажется. В качестве подсказки — в бизнесе деньги решают всё. Иногда весьма неочевидный путь ОЧЕНЬ сильно дешевле.)
Я бы тоже с удовольствием юзал какой-нибудь готовый инструмент, но увы.
Чем больше движущихся частей, тем выше вероятность отказа. И тем дороже стоимость владения.
Вот и я о том же.
А какие гарантии, что российский хостинг вдруг не свалится, как мтс-овское облако?
Я такое делал. Более того, вот в этой статье https://habr.com/ru/articles/330366/ заглавный скриншот сгенерирован именно таким баш-скриптом, дёрнутым через CGI. Точнее, даже несколькими скриптами.
Написал за два дня, и оно какое-то время держалось в проде, но с учётом того, что на каждый вызов дёргалось овердофига процессов, с ростом обрабатываемого объёма начало нещадно тормозить. Переписал в итоге на PHP.
В качестве упражнения для разминки мозгов делать подобное весьма неплохо.