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

Хотелось бы получить отзывы о веб-приложении, чтобы определить приоритеты, куда дальше развивать этот mvp:

Data Commandr: conceptoriented.com

Data Commandr это приложение для работы с таблицами. Общая цель в том, чтобы сделать работу с таблицами существенно легче, особенно в плане сложных преобразований и вычислений. Например, имеется штук 10 исходных таблиц (csv или загруженных баз данных), и надо их как-то комбинировать, группировать, агрегировать и т.п., и получить новую таблицу. Предполагается, что это могут быть довольно сложные преобразования так что обычные тулы либо не потянут, либо потребуются знания на уровне SQL. Хотелось бы сделать такие операции с таблицами данных доступными для обычных пользователей, т.е. не сложнее Excel. Типичное применение это создание отчетов, но это актуально также и для других задач, например, миграция данных. Это приложение основано на новом подходе, когда новая колонка может определяться как формула через другие уже существующие колонки таблиц. Собственно, через оценку этих формул и происходит преобразование данных.

Было бы интересно оценить этот mvp с двух точек зрения:

1) С т.зр. разработчика: может косяки какие очевидные сразу заметны в реализации и дизайне? Если что, то передний конец сделан на angular 2, а задний конец на Яве.

2) С т.зр. пользователя: может такое приложение кому-то быть полезным, и если в принципе да, то чего не хватает в первую очередь? Может есть какие другие применения. Например, я сейчас думаю сервер адаптировать для обработки потоков данных (stream analytics).

Заранее спасибо всем, кто ответит.

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Тупо показуха. Кто не разбирается — тот и не разберётся. Кто разбирается — тому эта приблуда триста лет не нужна, есть гораздо более простые и понятные инструменты.

СНАЧАЛА надо разбираться в потребностях, а уж потом творить под них проект. Выкинь каку.

чем это лучше чем pandas для тех же задачь?

я так понимаю что для тех кто программирование мне владеет

у тех таких задачь не стоит обычно, они в екселе

Ну если говорить о том, как устроена обработка в 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.

чем это лучше чем pandas для тех же задачь?
Если реализовать как фрейморк, то лучше тем, что все операции описываются как функции. Data Commandr основан на функциональной модели данных.
надо их как-то комбинировать, группировать, агрегировать и т.п., и получить новую таблицу. Предполагается, что это могут быть довольно сложные преобразования так что обычные тулы либо не потянут, либо потребуются знания на уровне SQL.
Можно ли эффективно «группировать и комбинировать» данные из нескольких источников, не понимая базовых принципов работы с множествами (фиг с ней с алгеброй, понимания на пальцах хотя-бы)? А можно ли понимая эти принципы споткнуться об SQL?
Можно ли эффективно «группировать и комбинировать» данные из нескольких источников, не понимая базовых принципов работы с множествами (фиг с ней с алгеброй, понимания на пальцах хотя-бы)? А можно ли понимая эти принципы споткнуться об SQL?

Все суть DC в том, что он не требует понимания работы со множествами поскольку множеств и операций со множествами там нет — это другая модель данных.

Почти все широко используемые подходы к преобразованию данных (включая языки запросов) основаны не операциях со множествами. Чтобы вывести новые данные, надо взять существующие таблицы и применить к ним операцию. В Data Commandr данные выводятся по другому. Чтобы вывести новые данные в DC, надо взять существующие колонки и применить к ним операции. Формально у нас получается граф операций над колонками (а не таблицами). В DC нет никаких join или group-by, а есть множество колонок в разных таблицах, которые имеют свои определения в виде формул. Пользователь просто добавляет новые колонки и дает им определения. Это как в Эксель, но только вместо ячеек формулы имеют колонки.

В DC нет никаких join или group-by, а есть множество колонок в разных таблицах, которые имеют свои определения в виде формул.
Покажите разницу на очень простом примере, пжл: Есть две таблицы — прайс лист (item_id, item_price) и отгрузки (item_id, quantity, total_amount). Вы знаете, что в большинстве случаев товары продаются с какой-то скидкой, и хотите посчитать среднюю скидку (в % от прайсовой цены) по каждой проданной позиции.

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

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

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

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

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

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

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

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

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

Это у вас называется «в DC нет никаких join»

formula: { [id] = [itemid] }
Теперь две таблицы связаны.

А это у вас называется «никаких group by»

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

Вы конечно можете всерьез думать, что объяснить костыль с несколькими полумагическими аккумуляторами (откуда в формулах взялся нигде ранее не определенный out?) проще, чем простую функцию (сумма, среднее — это дети в школе учат) над результатами группировки, но у меня лично есть в этом огромные сомнения.

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

Пока, кроме DATA COMMANDR LOADING ... ничего не грузится, ждал 10 минут, подожду ещё столько же, если не загрузится, то .... ну в общем понятно.

Перегрузил страницу пару раз для проверки. Где-то 2-3 секунды на загрузку страницы (сервер в штатах, браузер в Германии). Это я не в плане оправдания, а просто проверить, что приложение все еще живое. Попробуйте заново перегрузить. (Не знаю, но может старый коннект уже мертвый.) Если не идет, надо будет подумать, как уменьшить приложение. Говорят, в Angular можно как-то по частям загружать, но я не знаю как. Может еще проблема с куки быть, но он должен сказать, если что не так.

Похоже Apache все-таки умер под нагрузкой (REST сервер на Tomcat живой). За ~5 часов он пассивно отдал ~400MB через ~200 запросов. Даже если это много, зачем умирать? Через час другой починю. Наверное лучше поставить нормальный nginx, а то к Apache httpd нежный какой-то. Всем спасибо за клики и пардон за сбой.

Запустил заново. Все работает.
Apache сервер умер из-за этого:
AH00326: Server ran out of threads to serve requests. Consider raising the ThreadsPerChild setting

Эм.... Не хочу огорчать, но все еще не работает :(

Да, тоже заметил. Процесс бежит, но не отвечает. Не ясно, в чем проблема, не было еще такого. Пересадил на nginx. Надеюсь не подведет.

ліниво довго розбиратися, так навскидку: поки що воно однозначно не user-friendly.
Починаючи з етапу імпорту csv (неможливість задати column seperator, проблеми з юнікодом), закінчуючи лінійками прокрутки в області перегляду таблиці, підказками за межами екрану etc.
А коли допилите до нормального стану, стане схожим на query builder в Access або Power Query в excel.
Смисл ?

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

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

Смисл ?

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

Постановка high level вижина напомнила мне мой полтора года назад (MVP вот тут до сих пор висит) — только у меня было с упором на pivot tables/charts, агрегация-метрики вот это все. Не повторяй эту ошибку — формулировка проблемы слишком широкая, слишком много «если».

Да вот кстати еще одна аппа с похожим месседжем: fieldbook.com

Давай посмотрим с другой стороны. «Непродвинутый» юзверь далекий от IT который не умеет пользоваться Access/Excel/SQL (пусть и через визуальный билдер) — но при этом понимает что ему надо приготовить данные — есть ли вообще такие люди? Ищут ли они что-то подобное? Надо проверять. Очень может оказаться, что такие люди хотят эээ задать вопрос — и получить ответ. Их текущий юзкейз — это создать запрос в IT отдел, чтобы там красноглазики пошуршали и выдали ответ в виде отчета. Серьезно думаешь эти люди сядут осваивать yet another Excel?.. Чтобы зацепить эту аудиторию, народ пытается сделать что-то вроде «гугл для баз данных» вот например www.thoughtspot.com

Это все не значит что тема не годная! Все равно прийдешь к тому, что стоит запускать не швейцарский нож, а простой но полезный инструмент, который решает — для начала — одну понятную юзерам задачу (в идеале — «в два клика»).

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

уточнение в точку ) конечно, результат должен быть структурирован как отчет или конкретный ответ.

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

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

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

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

Более реальный путь это через эко-ниши каких-то фирм или продуктов, например, salesforce или ecommerce продуктов, где эта или другая универсальная штуковина затачивается под конкрутную среду и/или задачу.
Уже теплее, имхо :-)
забудь про end-user-ов как конечных кастомеров (на какое-то время), и перепакуй что есть в нечто B2B, которое сможет купить company. В моем случае это получились решения для встраиваемого репортинга-аналитики в веб-приложения, полет нормальный (там рыба есть). Кстати, фича search-driven reporting туда так и не перекочевала пока что — спроса практически нет (но может и появиться, если эта штуку продавят в мейнстрим).

А MVP пусть висит, собирает фидбеки. Если фидбеков вообще нет, может стоит и убить чтобы не отвлекало.

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

все эти search-driven-для-данных циркулируют в том или ином виде с 2009-2010. Концептуально тема старая, дьявол как обычно в деталях и юзер экспириенсе конкретных реализаций. Кстати, в PowerBI тоже есть — просто как одна из фичей — natural language queries (Q&A).

Предполагается, что это могут быть довольно сложные преобразования так что обычные тулы либо не потянут, либо потребуются знания на уровне SQL
Попробуйте привести конкретный пример, когда «тулы либо не потянут».
Что касается знаний SQL. Для работы в Вашей системой ее изучать потребуется? Не будет-ли это изучение сложнее, чем изучения нескольких базовых операций SQL? Просто не думаю, что «интуитивно понятными» действиями в действительности можно реализовать «сложные преобразования и вычисления». Посмотрите, что в этом плане можно сделать том-же Access’e. А поскольку интеграция Access <->Excell весьма тесная, то подумайте, как Вы будете конкурировать с этой парой.
Попробуйте привести конкретный пример, когда «тулы либо не потянут».

1) Связывание таблиц (join). 2) Агрегирование (group-by).

В результате обычно приходим к жесткому компромиссу: либо это делает все, но обычные пользотели не понимают и не используют (получает тул для технарей), либо пользователи довольны, но работа сводится к ограниченному числу простых паттернов. Примеры «тул не потянет» легче всего найти в программах для визуалльной аналитики (коих море, но можно взять Qlikview или Tableau), в которые данные должны быть уже загружены в «правильной» форме, поскольку внутренние возможности очень ограниченны.

Что касается знаний SQL. Для работы в Вашей системой ее изучать потребуется? Не будет-ли это изучение сложнее, чем изучения нескольких базовых операций SQL? Просто не думаю, что «интуитивно понятными» действиями в действительности можно реализовать «сложные преобразования и вычисления».

Изучать систему конечно потребуется, но примерно на уровне Excel (это конечно гипотеза, которую надо проверять). Т.е. если человек может освноить Excel, то значит сможет изучить Data Commandr (DC). Чтобы сделать что-то в Эксель, надо понять, как писать формулы, например, A1=B3*C5. Чтобы сделать что-то в DC, надо понять, что колонка это формула от других колонок, Amount=Price*Quantity.

Все проблема в формулах, которые должны собирать данные из разных таблиц. Собственно, специфика (USP) этой системы в том, что это можно сделать, причем в довольно общем виде. Пока мне не знаком подход, где бы это было возможно (кроме довольно кривых попыток в Microsoft DAX). DC основан на операциях с колонками, тогда как большинство других (мне известных) подходов и систем основаны на операциях с таблицами. Извествно (по Эксель), что написание формул для пользователей гораздо проще, чем операции с таблицами (join, group-by и т.п.)

Посмотрите, что в этом плане можно сделать том-же Access’e. А поскольку интеграция Access <->Excell весьма тесная, то подумайте, как Вы будете конкурировать с этой парой.

Для обычного пользователя (бухгалтера) Access слишком сложный, а Excel простой но ограниченный (он не для работы с таблицами). Гораздо ближе по духу Microsoft Power BI со своим языком DAX, где они тоже попытались обобщить формулы Excel на случай таблиц. У них не очень получилось, но DAX это одно из лучших что я знаю.

На самом деле DC в нынешнем виде пересекается, например, с airtable.com — самое быстрорастущее SaaS приложение за 2016.

а Excel простой но ограниченный
Что может делать Data Commandr, чего не может делать Excel?

Видел табличку excel в которую вбивались данные, потом там жмакалась кнопка(в excel), она формировала несколько отчетов, и рассылала их на разные почтовые ящики. Это к ограниченности excel.

Что может делать Data Commandr, чего не может делать Excel?
Если коротко, то то же, что и SQL.

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

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

Мда. Молодежь.
В году так 2003, мы с начальником верстали бюджет корпорации в Excel. 1C несправлялся. Я до сих пор в «захватi» от возможностей Excel 2000. Что и говорить за теперешние версии с PowerQuery/Pivot аддонами.
Лично я на екселе не вижу ограничение в плане создания сложных трансформаций.
Может Вам следует присмотреться к екселю повнимательней ?

Хм. Только что открыл в браузере — грузится и работает.
А что говорит? Начинает грузиться и не заканчивает? Или вообще не коннектится? Или обрывается?

Просто не конектилось. Похоже, как на хероку, когда они останавливают инстанс, если никто не пользуется. А потом, при первом конекте, стартуют его :)

Видимо N человек одновременно кликнули. Это VM на Azure Cloud, 2 Cores, 8 GB. Не знаю, много это или мало, но видимо мало, если он начал отказывать. А может Apache надо как-то лучше сконфигурировать (он раздает большие Angular файлы).

А может Apache надо как-то лучше сконфигурировать (он раздает большие Angular файлы)
Да, надо — поставить nginx чтобы он отдавал статику, а запросы к бекенду отдавал apache.

Мои пять копеек:
— с т.зр. разработчика — сайт не грузится
— с т.зр. пользователя — сайт не грузится

Грузится с т.зр пользователя или т.зр. разработчика?

Т. зр. браузера автора не волнует :(

Підписатись на коментарі