Check Levi9 best QA positions to Backbase team!
×Закрыть
conceptoriented.org
  • Обещал выложить свой проект. Делаю

    Программа это набор узлов, каждый из которых имеет свое состояние. Узлы могут подписываться на события от других узлов. При соответствующем изменении состояния, узел оповещает подписчиков об этом. При получении события, получатель выполняет процедуру и может поменять свое состояние, о чем он оповестит подписчиков.

    Я понял, что есть еще много чего, но это определение (выше) само по себе верно или нет?

  • Обещал выложить свой проект. Делаю

    Ну значит я примерно правильно понял. Поведение системы зависит от состояния, которое может меняться в обработчиках событий, которые сами (автоматически) вызываются при изменении состояния (возможно из-за самих себя, что зациклит систему). Наличие выражений типа «а*а+б*б» ничего существенно не меняет, поскольку эквивалентно новой анонимной переменной (состояния), за изменением которой следит система.

    Один пример, это когда мы следим за состоянием переменной ошибки «error>0». Когда она становится больше 0, будет вызвана процедура. В обычном подходе процедура, которая ставит флаг ошибки, должна сама оповестить подписчиков об этом событии. А здесь система будет сама следить за состоянием. Что удобнее сказать трудно. По-любому у кучи разрабов в памяти при рождении прошит pub-sub паттерн, перепрошить который вряд ли удастся без насилия со стороны Билли.

    Там дофига есть об чем сказать.

    Что например? Остальное я так понял это оптимизация, например, анализ зависимостей событий. Ну и конечно (как я уже упомянул), как дать определенные гарантии корректности в плане синхронизации, но это уже классическая и большая проблем. Например, транзакции, ведь мы часто хотим изолировать небольшие изменения, чтобы система не «дергалась» по отдельной переменной, а только после нескольких операций.

  • Обещал выложить свой проект. Делаю

    Интересно. Я так понимаю, идея в том, чтобы вся система приводится в действие триггерами на значения переменных, которые следят за их изменением. А далее все сводится к асинхронному программированию. Подписки на условия переменных как базовый механизм в каком-то языке точно реализованы, но не могу уже вспомнить в каком.

    Но имхо в подобных подходах основная проблема не в том, кто является триггером событий (в данном случае это значения переменных), а в том, что потом все сводится к асинхронному программированию, и именно тут нет хорошей концепции. Если программа будет чуть сложней, чем игрушечная, то начнется асинхронный хаос.

    Поддержал: Denys Poltorak
  • Оцените новый подход к обработке данных — альтернатива map-reduce, SQL, pandas

    Да тот же самый. Джойны вы «заменили» какими-то линками, аггрегаты... хммм... такими же аггрегатами (вид сбоку).

    Join — операция на множествах. Link — операция на функциях. Это одно и то же?
    Агрегирование — функция применяется к множеству. Аккумулирование — функция применяется к одном элементу. Это одно и то же?

    Не очень понятно, а какая собственно проблема этим решается?

    Почему пользователи Excel не используют SQL? Ведь SQL такой крутой. Прикрутил его и далее пиши себе любимые join и group-by. Да бог с ними с эксельщиками. Попросите спецов написать пару запросов к 3 таблицами и половина из них наделает ошибок. Случайно? А теперь еще добавить туда агрегацию. А потом еще вычисления с аналитикой. А в конце заменить их на другую команду и попросить их что-то подкрутить. Будет интересно посмотреть на результат. Это с точки зрения практики. С точки зрения теории тоже есть серьезные вопросы, но это не для здесь.

    Если коротко, то проблема — сложность (а значит время, ошибки, деньги). Цель — упрощение. Чтобы нормальный здоровый человек мог написать что-то сложное, быстро, без ошибок, и его сменщик мог быть потом без ошибок это изменить.

    Ну хорошо, Bistro и этот подход не нужен. А какие тогда проблемы интересуют заказчиков? Что бы они хотели поменять или упростить или удешевить? Где лежать принципиальные проблемы? Куда смотреть? Чего бы вы хотели увидеть хотя бы примерно?

  • Оцените новый подход к обработке данных — альтернатива map-reduce, SQL, pandas

    В pandas только колнки одной таблицы можно так определить с помощью df.apply(lamda_fn). Это действительно очень удобно, и по сути совпадает с Bistro. Но это не поддерживает работу с несколькими таблицами — для этого используется join. И также pandas использует для агрегации group-by.

    В Bistro нет join. Вместо генерации новой таблицы используется линкование (операция link), т.е. колонка таблицы может ссылаться на записи другой — и это делается с помощью пользовательской функции.

    В Bistro нет group-by. Данные не надо группировать явно. Агрегирование (операция accu) выполняется также с помощью пользовательской функции, но она устроена по-другому. Она вызывается для каждого значения группы и обновляет текущий агрегат (потому называется функция аккумуляции).

  • Оцените новый подход к обработке данных — альтернатива map-reduce, SQL, pandas

    Column Store довольно старый подход, который сейчас уже существует у mysql, у оракла, у большинства активных игроков.

    Это относится к физической модели, т.е. как реализован уровень хранения данных. В большинстве column store все запросы по-прежнему пишутся на SQL-подбном языке (который потом может транслироваться в колончатые операции, но этого никто не видит), т.е. на логическом уровне это самая обычная реляционная СУБД (за некоторыми исключениями и фичами).

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

    наступает момент, когда от классических агрегатов можно будет отказаться, так как мы в любой момент за приемлемое время сможем получить актуальную информацию .

    Это уже другой вопрос. Они говорят, что агрегаты не надо хранить (постоянно), а можно по необходимости считать на лету. Но ведь все равно, чтобы подсчитать, надо определить что считать, т.е. указать запрос (а сохранять или следующий раз пересчитывать, это уже другой вопрос). Так что вопрос в том, как описывать агрегацию данных. Обычный подход это group-by или reduce. Суть их в том, что функция агрегации получает подмножество, а возвращает одно значение. Например, функция SUM может получить {1,3,5}, будет вызвана один раз и вернет 9.

    Bistro использует другой подход. Здесь эта функция получает одно (следующее) значение группы, и обновляет текущий агрегат. Например, для суммирования такая функция будет вызвана 3 раза (для каждого значения из {1,3,5}, и вернет {1,4,9}. Последнее значение будет результат.

  • Ведущий Data Architect в Tesla — о карьере в Киеве, переезде и работе в Кремниевой долине

    Да, похоже они двигатель охлаждают, причем (запатентовано: www.google.com/patents/US7489057), вроде прямо во вращающийся ротор заливают. (Я уж заподозрил, что они процессор на борту водой охлаждают.)

  • Ведущий Data Architect в Tesla — о карьере в Киеве, переезде и работе в Кремниевой долине

    Конечно, есть компоненты, которые нет необходимости делать самим, например, водяной насос или тормоза
    Machine learning и deep learning на Тесле это понятно для чего. Тормоза вроде тоже нужны. Но зачем на Тесле водяной насос?
    Поддержали: Діма Дрозд, Alex Blokha
  • Оцените веб-приложение для работы с таблицами — Data Commandr

    На самом есть две задачи:

    • Поиск нужных данных. Это актуально, когда люди просто не знают, какие данные вообще существуют, где они лежат, и как их получить. Это что-то вроде каталога или индекса данных. Проблема в том, что данные не текст и просто так их проиндексировать не получится. Нужно учитывать (семантические) связи и вообще понимать что такое данные. Ну например, есть много разных моделей данных и надо учитывать их специфику.
    • Выборка нужных данных в виде отчета. Здесь изначально примерно такая же ситуация как и в первой задаче — пользователь не в курсе что есть в наличие и где это лежить, но знает примерно что он хочет получить. Эта задача основана на первой. Надо сперва найти релевнтные данные, а потом выбрать из них то, что требуеся.

    Обе задачи используют schema matching для нахождения связей, а также другие методы, например, как распознать идентификаторы (первичный ключ), как найти ссылки (иностранный ключ), как найти иерархии (например, страна, город, улица) и т.п.

    На самом деле я сперва разработал Data Commandr на WPF на C#, и там такие функции имеются. Пользователь когда импортирует данные, то система сразу ему предлагает, как можно интегрировать и связать их с уже имеющимися данными. Ну а если связи и семантика есть, то далее построение отчетов уже существенно проще.

  • Оцените веб-приложение для работы с таблицами — Data Commandr

    Чтобы зацепить эту аудиторию, народ пытается сделать что-то вроде «гугл для баз данных» вот например www.thoughtspot.com
    Вот кстати эти www.tamr.com тоже делают что-то подобное уже довольно давно с 2013 года (тогда они назывались Data Tamr). Хотя за ними стоит Mike Stonebraker и были два раунда хороших инвестиций, чего-то особо значительного за это время я не увидел. Было пару значительных изменений продукта, что я понимаю как трудности со стратегией. Ну впрочем при таких финансах и поддержке, думаю не прогорят.
  • Оцените веб-приложение для работы с таблицами — Data Commandr

    Правильно "Dimensions«Почему же вас так пугают понятия из «прошлого столетия» фундаментальная база как и история приобретает ценность только со времем.
    Меня это совершенно не пугает и даже очень нравится. Вот просто продать это невозможно как и кучу других прекрасных технологий, созданных человечеством. Рынок занят огромным числом продуктов на все случаи жизни. А юзеры недовольны и требуют решения совершенно других задач: легче, дешевле, быстрее. Проще говоря olap и многомерные модели это не актуально (и я тут не причем — это рынок).
  • Оцените веб-приложение для работы с таблицами — Data Commandr

    Постановка high level вижина напомнила мне мой полтора года назад (MVP вот тут до сих пор висит) — только у меня было с упором на pivot tables/charts, агрегация-метрики вот это все.
    Классно сделано! Все правильно как по мне. Особенно в плане запросов на естественном языке, которые мы где-то в начале 2000-х делали. Меня аж ностальгия замучила. Хорошие были времена, когда зарождались self-service BI tools. Куча возможностей.
    Серьезно думаешь эти люди сядут осваивать yet another Excel?
    Нет (сейчас уже) не думаю. Только если их начальник заставит, т.е. надо идти через IT отдел энтерпрайз, а туда дороги нет (там своя специфика). Более реальный путь это через эко-ниши каких-то фирм или продуктов, например, salesforce или ecommerce продуктов, где эта или другая универсальная штуковина затачивается под конкрутную среду и/или задачу.
    Чтобы зацепить эту аудиторию, народ пытается сделать что-то вроде «гугл для баз данных» вот например www.thoughtspot.com
    О, это крутая тема. Гугл для данных у меня давно в списке как направление поскольку вся теория для этого есть, и я даже время от времени занимаюсь этим (и даже обсуждал с потенциальными пользователями). Надо подумать, может найти время и выкатить mvp для проверки. Например, в ооблаке выложить сервис для энтерпрайз, и в открытую для открытых данных (data markets). Система индексирует имеющиеся (закрытые или открытые) источники данных, а далее используется как точка управления и доступа ко всем данным (организации, отдела, или интернета).
  • Оцените веб-приложение для работы с таблицами — Data Commandr

    чем это лучше чем pandas для тех же задачь?
    Если реализовать как фрейморк, то лучше тем, что все операции описываются как функции. Data Commandr основан на функциональной модели данных.
  • Оцените веб-приложение для работы с таблицами — Data Commandr

    Ну если говорить о том, как устроена обработка в data frame (pandas, R, Spark SQL), то там все-таки в основе операции со множествами. Хотя лучше чем в SQL. Например, можно опеределить новые колонки через функции (df.apply), что очень удобно. Также очень удобно, что группирование отделено от агрегирования, т.е. сперва группируем, а потом этот объект используем для разных аггрегаций (в т.ч. с помощью функций). Но для связей таблиц надо использовать join.

    В DC нет join и нет group-by — там есть только функции. В принципе, этот подход можно реализовать как альтернативу pandas, но нужно время. Я реализовал это на Яве bitbucket.org/conceptoriented/dc-core и по сути это движок, который на сервере крутится за нынешним Data Commandr UI. Вполне возможно переключусь обратно на на бэк-енд на Яве, например, как альтернатива Spark или (что интереснее) как stream analytics.

  • Оцените веб-приложение для работы с таблицами — Data Commandr

    Еще одна попытка отформатировать.

    СОЗДАТЬ ТАБЛИЦЫ
    
    Create table:
    name=ITEMS
    
    Upload data (поставьте галку для авто-создания колонок, copy-paste):
    id,price
    1,10
    2,20
    3,30
    
    Create table:
    name=SALES
    
    Upload data (поставьте галку для авто-создания колонок, copy-paste):
    itemid,quantity,amount
    1,1,10
    2,1,10
    2,2,20
    3,1,10
    3,2,20
    3,3,30
    
    СОЗДАТЬ КОЛОНКИ
    
    Создать колонку в SALES, которая будет содержать ссылку из SALES в ITEMS:
    name: item
    data type: ITEMS
    column type: Дink
    formula: { [id] = [itemid] }
    Теперь две таблицы связаны. 
    
    Создать колонку в ITEMS для подсчета количества проданного:
    name: quantity
    data type: double
    column type: accumulated
    formula: out + [quantity]
    accu table: SALES
    accu path: [item]
    
    Создать колонку подсчета суммы денег:
    name: amount
    column type: Accumulated
    formula: out + [amount]
    accu table: SALES
    accu path: [item]
    
    Создать колонку для подсчета скидки в %:
    name: discount
    column type: Calculated
    formula: (([amount] / [quantity]) / [price]) * 100
    
  • Оцените веб-приложение для работы с таблицами — Data Commandr

    Еще раз то же самое, но уже с правильным форматированием:

    СОЗДАТЬ ТАБЛИЦЫ

    Create table: name=ITEMS

    Upload data (поставьте галку для авто-создания колонок, copy-paste):
    id,price 1,10 2,20 3,30

    Create table: name=SALES

    Upload data (поставьте галку для авто-создания колонок, copy-paste):
    itemid,quantity,amount 1,1,10 2,1,10 2,2,20 3,1,10 3,2,20 3,3,30

    СОЗДАТЬ КОЛОНКИ

    Создать колонку в SALES, которая будет содержать ссылку из SALES в ITEMS:
    name: item data type: ITEMS column type: Дink formula: { [id] = [itemid] }
    Теперь две таблицы связаны.

    Создать колонку в ITEMS для подсчета количества проданного:
    name: quantity data type: double column type: accumulated formula: out + [quantity] accu table: SALES accu path: [item]

    Создать колонку подсчета суммы денег:
    name: amount column type: Accumulated formula: out + [amount] accu table: SALES accu path: [item]

    Создать колонку для подсчета скидки в %:
    name: discount column type: Calculated formula: (([amount] / [quantity]) / [price]) * 100

  • Оцените веб-приложение для работы с таблицами — Data Commandr

    Ну вот сделал пример. Не используйте подчеркивание в именах. Тип данных по умолчанию, кроме где указано.

    СОЗДАТЬ ТАБЛИЦЫ

    Create table: name=ITEMS

    Upload data (поставьте галку для авто-создания колонок, copy-paste):
    id,price 1,10 2,20 3,30

    Create table: name=SALES

    Upload data (поставьте галку для авто-создания колонок, copy-paste):
    itemid,quantity,amount 1,1,10 2,1,10 2,2,20 3,1,10 3,2,20 3,3,30

    СОЗДАТЬ КОЛОНКИ

    Создать колонку в SALES, которая будет содержать ссылку из SALES в ITEMS:
    name: item data type: ITEMS column type: Дink formula: { [id] = [itemid] }

    Теперь две таблицы связаны.

    Создать колонку в ITEMS для подсчета количества проданного:
    name: quantity data type: double column type: accumulated formula: out + [quantity] accu table: SALES accu path: [item]

    Создать колонку подсчета суммы денег:
    name: amount column type: Accumulated formula: out + [amount] accu table: SALES accu path: [item]

    Создать колонку для подсчета скидки в %:
    name: discount column type: Calculated formula: (([amount] / [quantity]) / [price]) * 100

  • Оцените веб-приложение для работы с таблицами — Data Commandr

    Но ничего же не мешает из экселя приконнектиться к практически любому источнику данных, собрать нужные данные в плоскую денормализованную простыню, свернуть ее в pivot и получить такой себе OLAP-куб с нужными данными.
    «Собрать» из многих таблиц в одну это как, это что? «Денормализованную» это как, это что? «Pivot», «OLAP-куб» с «dimtnsions» и «measures» плюч VBA распугают всех пользователей. Это все понятия предыдущего столетия.
    Так что это далеко не расширенный калькулятор, а вполне себе взрослый инструмент.
    Эксель как концепция (электронные таблицы) это расширенный калькулятор: мы определяем выражения, каждое из которых возвращает единственное значение и зависят от других. Эксель как продукт конечно включает в себя все что угодно, что часто не имеет к концепции никакого отношения.
    уж если пипл не осилил эксель, по которому есть уйма литературы и howto видяшек, то надеяться что он осилит что-то более низкоуровневое — утопия...
    Не утопия, а гипотеза, которую надо проверить. Кроме того, вряд есть смысл нацеливаться на пользователей Эксель и предлагать им заменить это на DC — это действительно глупо, что с качеством продукта не связан, поскольку Эксель это религия и традиция (как Виндоус) и у него огромная инерция. Есть другие маркетинговые/технологические нишы и группы пользователей, где такая технология может найти спрос. Их надо пробовать. Ну например, airtable.com нашли же своих пользователей, не смотря на то, что то же самое можно сделать в Excel или Access. Ну или феноменальный успех QlickView и Tableau. Excel всегда имел простую и понятную визуализацию. Ну и что? Пришли QlickView и Tableau с их self-service продуктами и все их купили. Почему? Потому что проще.
  • Топик для поиска партнеров, кофаундеров и инвесторов и т.п.

    1. Из описания первых страниц я так и не понял, что это такое. Только взглянув на примеры до меня дошло (и понравилось).

    2. Идея массовая. Нужно двигать в SaaS (веб-приложение, хотя бы упрощенную версию). Там traction. Монетизация за счет рекламы, freemium, основного PRO-приложения. Тогда и покупателей или инвесторов можно найти.

  • Оцените веб-приложение для работы с таблицами — Data Commandr

    А коли допилите до нормального стану, стане схожим на query builder в Access або Power Query в excel.

    Все Query Builder‘ы так или иначе работают с join и group-by, которые нормальный пользователь (бухгалтер) не понимает какой бы UI их не прикрывал. В Data Commandr принципиально нет никакого Query Builder‘а — пользователь напрямую пишет формулы как операции на колонках. Но какие-то визарды для типичных операций конечно не помешают (в будущем), но все равно они будут генерировать определения колонок.

    Смисл ?

    Смысл сделать работу с данными доступной любому непродвинутому пользователю далекому от IT. То, что раньше делали эксперты на SQL, должен делать бухгалтер.

← Сtrl 12 Ctrl →